I have a code that constructs an RSA public key on MacOS with the help of the security framework. This works fine on 10.11/10.12/10.13, but today I found that this fails on 10.9. Below is the constructor of the class that wraps the key:
CRSAPublicKey(const unsigned char* pExponent, const std::size_t nExponentSize, const unsigned char* pModulus, const std::size_t nModulusSize)
{
static const SecAsn1Template kRsaPublicKeyTemplate[] = {
{ SEC_ASN1_SEQUENCE, 0, NULL, sizeof(ASN1_RSA_PUBLIC_KEY) },
{ SEC_ASN1_INTEGER, offsetof(ASN1_RSA_PUBLIC_KEY, m_Modulus), 0, 0 },
{ SEC_ASN1_INTEGER, offsetof(ASN1_RSA_PUBLIC_KEY, m_Exponent), 0, 0 },
{ 0, 0, 0, 0 },
};
ASN1_RSA_PUBLIC_KEY Asn1Key;
Asn1Key.m_Modulus.Data = const_cast<unsigned char*>(pModulus);
Asn1Key.m_Modulus.Length = nModulusSize;
Asn1Key.m_Exponent.Data = const_cast<unsigned char*>(pExponent);
Asn1Key.m_Exponent.Length = nExponentSize;
MacOS::CAsn1CoderReference pAsn1Coder;
OSStatus nStatus = SecAsn1CoderCreate(&pAsn1Coder);
// Check nStatus
SecAsn1Item DerKey;
nStatus = SecAsn1EncodeItem(pAsn1Coder, &Asn1Key, kRsaPublicKeyTemplate, &DerKey);
// Check nStatus
const void* pKeys[] = { kSecAttrKeyType, kSecAttrKeyClass };
const void* pValues[] = { kSecAttrKeyTypeRSA, kSecAttrKeyClassPublic };
MacOS::CReference<CFDictionaryRef> pParameters(CFDictionaryCreate(kCFAllocatorDefault, pKeys, pValues, 2, nullptr, nullptr));
// Check pParameters
MacOS::CReference<CFDataRef> pKeyData(CFDataCreate(kCFAllocatorDefault, DerKey.Data, static_cast<CFIndex>(DerKey.Length)));
// Check pKeyData
MacOS::CReference<CFErrorRef> pError;
m_PublicKey = SecKeyCreateFromData(pParameters, pKeyData, &pError);
// Check m_PublicKey - this fails with "The operation couldn’t be completed. (OSStatus error -2147415792.)"
}
I removed some check macros etc, but this should illustrate the call sequence. On 10.9 I get a null pointer from SecKeyCreateFromData with an error code -2147415792. I tried adding the kSecAttrKeySizeInBits but that did not help. Meanwhile SecKeyGeneratePair with the same pParameters works fine, so I assume the issue is with the actual data. Is the ASN.1 coding supported only from 10.10 or something like that?
UPDATE
I got messed up in my tests, this actually does not work on 10.11 as well, which seems to corelate with addition SecKeyCreateWithData.
UPDATE 2
Looking at cssmerr.h this error code seems to be CSSMERR_CSP_INVALID_KEY.
Since I did not find the answer anywhere I had to solve this myself so I hope this helps others.
I did not find a direct explanation for the behavior changes of SecKeyCreateFromData, but since the documentation states:
Constructs a SecKeyRef object for a symmetric key.
10.12 added a SecKeyCreateWithData which does not mention anything about symmetric keys, maybe they added some additional functionality into SecKeyCreateFromData as well and that could be why it was working for me on 10.12 and up.
Nevertheless, to obtain 10.9 compatibility I used SecItemImport with the same ASN.1 encoded sequence:
static SecKeyRef ImportPkcs1PublicKey(const unsigned char* pExponent, const std::size_t nExponentSize, const unsigned char* pModulus, const std::size_t nModulusSize)
{
static const SecAsn1Template kRsaPublicKeyTemplate[] = {
{ SEC_ASN1_SEQUENCE, 0, NULL, sizeof(ASN1_RSA_PUBLIC_KEY) },
{ SEC_ASN1_INTEGER, offsetof(ASN1_RSA_PUBLIC_KEY, m_Modulus), 0, 0 },
{ SEC_ASN1_INTEGER, offsetof(ASN1_RSA_PUBLIC_KEY, m_Exponent), 0, 0 },
{ 0, 0, 0, 0 },
};
ASN1_RSA_PUBLIC_KEY Asn1Key;
Asn1Key.m_Modulus.Data = const_cast<unsigned char*>(pModulus);
Asn1Key.m_Modulus.Length = nModulusSize;
Asn1Key.m_Exponent.Data = const_cast<unsigned char*>(pExponent);
Asn1Key.m_Exponent.Length = nExponentSize;
MacOS::CAsn1CoderReference pAsn1Coder;
OSStatus nStatus = SecAsn1CoderCreate(&pAsn1Coder);
// Check nStatus and pAsn1Coder
SecAsn1Item DerKey;
nStatus = SecAsn1EncodeItem(pAsn1Coder, &Asn1Key, kRsaPublicKeyTemplate, &DerKey);
// Check nStatus
MacOS::CReference<CFDataRef> pKeyData(CFDataCreate(kCFAllocatorDefault, DerKey.Data, static_cast<CFIndex>(DerKey.Length)));
// Check pKeyData
SecExternalFormat nFormat = kSecFormatBSAFE;
SecExternalItemType nType = kSecItemTypePublicKey;
MacOS::CReference<CFArrayRef> pItems;
nStatus = SecItemImport(pKeyData, NULL, &nFormat, &nType, 0, NULL, NULL, &pItems);
// Check nStatus
SecKeyRef pKey = reinterpret_cast<SecKeyRef>(const_cast<void*>(CFArrayGetValueAtIndex(pItems, 0)));
// Check pKey
CFRetain(pKey);
return pKey;
}
The trick here was to guess nFormat and nType, but luckily I found a table with the mapping in Apple open source sources and [CocoaCryptoMac] in Github. I already had the PKCS1 version for my key as seen in the snippet in the question the remaining job was just to set the format accordingly. This answer has a lot of valuable info on PKCS1/PKCS8. Also, initially I was not sure if pKeyData is the string or binary form of the key, since there are lots of examples that use the string form with the SecKeyCreateFromData function. I just tried out all the options until the binary version worked.
Related
How to add Subject Alternative Name in the certificate. Using wincrypt I have created and added the certificate to "MY" and "root" path where CN can be machine fully qualified domain name or hostname or IP. As Subject alternate name I want to add the following:DNS name=fully qualified domain name, DNS name=hostname and
DNS name=IP
How to do this?
I do not want to use openssl.
LPCTSTR cnName= fqdn;
DWORD cbEncoded = 0;
if (!CertStrToName(X509_ASN_ENCODING, cnName, CERT_X500_NAME_STR, NULL,
pbdata, &cbData, NULL))
{
_tprintf(_T("CertStrToName failed 0x%x\n"), GetLastError());
return 0;
}
if (!(pbdata = (BYTE *)malloc(cbData)))
{
_tprintf(_T("malloc Error 0x%x\n"), GetLastError());
return 0;
}
if (!CertStrToName(X509_ASN_ENCODING, cnName, CERT_X500_NAME_STR, NULL, pbdata, &cbData, NULL))
{
_tprintf(_T("CertStrToName failed 0x%x\n"), GetLastError());
return 0;
}
CERT_NAME_BLOB IssuerBlob;
IssuerBlob.cbData = cbEncoded;
IssuerBlob.pbData = pbEncoded;
CertCreateSelfSignCertificate(NULL, &IssuerBlob, 0, &KeyProvInfo, &Alg, 0, &EndTime, 0);
OpenandAddCertificateToStore(pCertContext, L"MY");
OpenandAddCertificateToStore(pCertContext, L"Root");
This creates and adds certificate to the store without SAN in the certificate
I tried passing extension list like below:
CertCreateSelfSignCertificate(NULL, &IssuerBlob, 0, &KeyProvInfo, &Alg, 0, &EndTime, &myExtns_list);
CERT_EXTENSION myExtn;
myExtn.fCritical = TRUE;
myExtn.pszObjId = szOID_SUBJECT_ALT_NAME;
myExtn.Value = myBlobdata;
CERT_EXTENSIONS myExtns_list;
myExtns_list.cExtension = 1;
myExtns_list.rgExtension = &myExtn;
char cb[20] = { "DNS Names=abc.com" };
BYTE *pbData = (BYTE*)cb;
CERT_NAME_BLOB myBlobdata;
myBlobdata.cbData = 20;
myBlobdata.pbData = pbData;
with this I could get the SAN as byte format in the left pane and the right pane shows my string "DNS Names=abc.com".
But my requirement is to show only the DNS Names in the SAN.
I'm assuming that your building of the extension data actually happened prior to your call to CertCreateSelfSignedCertificate (and, likewise, that your building of myBlobdata happened before using it).
The main problem is that you used one SAN entry (sort of) as the entirety of the SAN extension; which meant you lost some encoding wrappers. A secondary problem is that you used szOID_SUBJECT_ALT_NAME, which is the incorrect OID for Subject Alternative Name... you actually want szOID_SUBJECT_ALT_NAME2.
I want to add the following:DNS name=fully qualified domain name, DNS name=hostname and DNS name=IP
Adding an IP address as a DNS name is non-standard and is supposed to result in a match failure. You'd actually want to add the IP address as an IP Address SAN entry.
CERT_ALT_NAME_ENTRY entries[3];
entries[0] = { CERT_ALT_NAME_DNS_NAME };
entries[0].pwszDNSName = L"example.org";
// IPv4 Address 10.12.1.130
BYTE ip4Bytes[] = { 10, 12, 1, 130 };
entries[1] = { CERT_ALT_NAME_IP_ADDRESS };
entries[1].IPAddress = { sizeof(ip4Bytes), ip4Bytes };
// ::1, big-endian
BYTE ip6Bytes[16] = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1 };
entries[2] = { CERT_ALT_NAME_IP_ADDRESS };
entries[2].IPAddress = { sizeof(ip6Bytes), ip6Bytes };
CERT_NAME_BLOB name = { cbEncoded, buf };
BYTE extBuf[1024] = { 0 };
cbEncoded = sizeof(extBuf);
CERT_ALT_NAME_INFO info = { sizeof(entries) / sizeof(CERT_ALT_NAME_ENTRY), entries };
if (!CryptEncodeObjectEx(
X509_ASN_ENCODING,
X509_ALTERNATE_NAME,
&info,
0,
nullptr,
extBuf,
&cbEncoded))
{
// Whatever your error handling story is.
//
// Note I didn't do a 0 buffer or CRYPT_ENCODE_ALLOC; I just knew
// that my buffer would be big enough.
}
CERT_EXTENSION extension = { 0 };
extension.fCritical = 0;
extension.pszObjId = szOID_SUBJECT_ALT_NAME2;
extension.Value = { cbEncoded, extBuf };
CERT_EXTENSIONS extensions = { 1, &extension };
...
PCCERT_CONTEXT cert = CertCreateSelfSignCertificate(
0,
&name,
0,
&keyProvInfo,
&sigAlg,
0,
&certExpirationDate,
&extensions);
In CertUI that gives me the Subject Alternative Name value I expect:
DNS Name=example.org
IP Address=10.12.1.130
IP Address=0000:0000:0000:0000:0000:0000:0000:0001
In c++ code using pkcs#11 we are trying to find the private key and install corresponding x509 certificate in the token. But unable to find the key pair in token using modulus. Below is my code sample.
//Install certificate
const char bytes[] = "-----BEGIN CERTIFICATE-----" "\n"
....
"-----END CERTIFICATE-----" "\n";
BIO *bio_mem = BIO_new(BIO_s_mem());
BIO_puts(bio_mem, bytes);
X509 * x509 = PEM_read_bio_X509(bio_mem, NULL, NULL, NULL);
//
BIO *bio_out = BIO_new_fp(stdout, BIO_NOCLOSE);
EVP_PKEY *pkey = X509_get_pubkey(x509);
RSA *rsa_key;
DSA *dsa_key;
char *rsa_e_dec, *rsa_n_hex, *dsa_p_hex,
*dsa_q_hex, *dsa_g_hex, *dsa_y_hex;
rsa_key = pkey->pkey.rsa;
//IFNULL_FAIL(rsa_e_dec, "unable to extract rsa exponent");
CK_BYTE_PTR modulus, exponent;
modulus = (unsigned char *)malloc(256);
int mo = BN_bn2bin(rsa_key->n, modulus);
//EVP_PKEY_free(pkey);
// CK_RV result;
CK_OBJECT_HANDLE hObject;
CK_OBJECT_HANDLE hObjects[100];
CK_OBJECT_HANDLE_PTR hObject_PTR = NULL;
CK_ULONG count;
vector<CK_OBJECT_HANDLE> *handles = new vector<CK_OBJECT_HANDLE>();
//Object class attribute
CK_OBJECT_CLASS classValue = CKO_PRIVATE_KEY;
CK_OBJECT_CLASS keytype = CKK_RSA;
CK_ATTRIBUTE privKeySearchTemplate[] = {
{ CKA_CLASS, &classValue,sizeof(classValue) },
{ CKA_KEY_TYPE, &keytype,sizeof(keytype) },
{ CKA_MODULUS, &modulus, sizeof(modulus) },
};
//
//{ CKA_PUBLIC_EXPONENT, exponent},
// Read label and ID from private key handle
CK_ATTRIBUTE privKeyAttrsToRead[] =
{ { CKA_LABEL, NULL_PTR, 0 },
{ CKA_ID, NULL_PTR, 0 },
};
//WriteToLog(modulus, modulus_len11);
// Find all objects with the template specified
result = m_pPKCS11->C_FindObjectsInit(m_SessionHandle, privKeySearchTemplate, 2);
do {
// Find the next object
result = m_pPKCS11->C_FindObjects(m_SessionHandle, &hObject, 1, &count);
if (count != 0)
handles->push_back(hObject);
} while (count != 0);
result = m_pPKCS11->C_FindObjectsFinal(m_SessionHandle);
There are several bugs here:
{ CKA_MODULUS, &modulus, sizeof(modulus) }
like always, sizeof(modulus) is size of your pointer which is 4 or 8 based on your system. This should be size of your modulus which in your case is mo. In addition, use correct type here:
CK_KEY_TYPE keytype = CKK_RSA;
Another bug is here:
m_pPKCS11->C_FindObjectsInit(m_SessionHandle, privKeySearchTemplate, 2);
You are searching a template with 3 attributes, but you have set number of attributes as 2. Normally you need to write code like this to prevent such bugs:
m_pPKCS11->C_FindObjectsInit(m_SessionHandle, privKeySearchTemplate, sizeof(privKeySearchTemplate) / sizeof(CK_ATTRIBUTE));
Finally, you need to allocate enough memory for your modulus before using BN_bn2bin, unless you like to get memory exceptions. Allocating 256 bytes may not be sufficient.
Say, if I call GetProcessHeaps in my process to get a list of heaps that it uses. Having a heap HANDLE how can I tell if such heap was created with the HEAP_NO_SERIALIZE flag or not?
While not a definite answer, you can call HeapQueryInformation(HeapCompatibilityInformation) and if it returns 2 then it is serialized because MSDN says this about HEAP_NO_SERIALIZE:
The low-fragmentation heap (LFH) cannot be enabled for a heap created with this option
I don't know if there is even a undocumented API to get the flags but for debugging purposes you can access the internal heap structure directly:
void DumpHeapType_Win8_x86(HANDLE hHeap)
{
typedef struct {
UINT32 Unknown1[2];
UINT32 Sig;
UINT32 Unknown2[1];
void*Unknown3[2]; //LIST_ENTRY?
void*Unknown4[1+1+1+1+2];
UINT32 Unknown5[1+1+1+1];
UINT32 Flags;
} HEAP_HDR;
typedef struct {
UINT32 Unknown1[2];
UINT32 Sig;
UINT32 Unknown2[1];
void*Unknown3[2]; //LIST_ENTRY?
HEAP_HDR*pHdr;
} HEAP_THING;
HEAP_THING *pThing = (HEAP_THING*) hHeap;
if (hHeap && pThing->Sig == 0xffeeffee)
{
HEAP_HDR *pHdr = (HEAP_HDR*) pThing->pHdr;
if (pHdr->Sig == 0xffeeffee)
{
printf("Flags=%#x Serialized=%d\n", pHdr->Flags, !(pHdr->Flags & HEAP_NO_SERIALIZE));
}
}
}
void playwithheaps()
{
HANDLE hHeap;
DumpHeapType_Win8_x86(hHeap = GetProcessHeap());
DumpHeapType_Win8_x86(hHeap = HeapCreate(0, 0, 0)); if (hHeap) HeapDestroy(hHeap);
DumpHeapType_Win8_x86(hHeap = HeapCreate(HEAP_NO_SERIALIZE, 0, 0)); if (hHeap) HeapDestroy(hHeap);
DumpHeapType_Win8_x86(hHeap = HeapCreate(HEAP_NO_SERIALIZE|HEAP_GENERATE_EXCEPTIONS, 0, 0)); if (hHeap) HeapDestroy(hHeap);
}
On my Windows 8 machine this gives me the following output:
Flags=0x2 Serialized=1
Flags=0x1002 Serialized=1
Flags=0x1003 Serialized=0
Flags=0x1007 Serialized=0
but the heap structure layout might be different on other versions so you would just have to test carefully...
I'm trying to use the NCrypt.dll to encrypt some data, in C++, and I'm having trouble handling keys and algorithms.
I would like to use AES with the CBC chainging method but, can't get the NCryptEncrypt function to work (I keep getting an invalid buffer size thrown).
I have created and stored a key (in the key storage provider) using the NCRYPT_AES_ALGORITHM flag but, have no idea how to set the algorithm to use the CBC method.
secSt = NCryptCreatePersistedKey(phProvider, &keyHndl, NCRYPT_AES_ALGORITHM, keyname, 0, 0);
I've tried a few property settings and had no success so, I would like to know if this is even possible with NCrypt?
I know the Bcrypt encrypt function allows this and tried to convert my NCRYPT_KEY_HANDLE to a BCRYPT_KEY_HANDLE without success (so I reckon this is not possible).
You can apply the chaining mode CBC by using NCryptSetProperty and the BCrypt constant BCRYPT_CHAIN_MODE_CBC.
Note that NCryptEncrypt does not seem to support padding for symmetric keys (see description of parameter dwFlags in NCryptEncrypt). So I had to apply some poor man's padding of the clear text to get a multiple of 16 bytes. Without the padding, I also get the status code 0xc0000206 (STATUS_INVALID_BUFFER_SIZE).
// Clear text for testing
static const char* clearText = "The quick brown fox jumps over the lazy dog. 1234567890. ";
static const int clearTextLen = 64;
int main()
{
LPCWSTR keyName = L"NCryptTest";
SECURITY_STATUS status;
NCRYPT_PROV_HANDLE hProvider;
NCRYPT_KEY_HANDLE hKey;
// Open storage provider
status = NCryptOpenStorageProvider(&hProvider, NULL, 0);
// Get stored key
status = NCryptOpenKey(hProvider, &hKey, keyName, 0, 0);
if (status == NTE_BAD_KEYSET)
{
// Create key if it doesn't exist
status = NCryptCreatePersistedKey(hProvider, &hKey, BCRYPT_AES_ALGORITHM, keyName, 0, 0);
status = NCryptFinalizeKey(hKey, 0);
}
// Set the chaining mode CBC
LPCWSTR chainMode = BCRYPT_CHAIN_MODE_CBC;
status = NCryptSetProperty(hKey, NCRYPT_CHAINING_MODE_PROPERTY, (PBYTE)chainMode, wcslen(chainMode) * 2 + 2, 0);
// Encrypt the text
DWORD outlen = -1;
unsigned char* cipherData = new unsigned char[clearTextLen];
status = NCryptEncrypt(hKey, (PBYTE)clearText, clearTextLen, NULL, cipherData, clearTextLen, &outlen, 0);
// Cleanup
delete[] cipherData;
NCryptFreeObject(hKey);
NCryptFreeObject(hProvider);
return 0;
}
I have an application that tries to verify the mmc.exe (services) signature. (the context of the application I think is irrelevant) I am trying with winapi function which both fails with
WinVerifyTrust. I get TRUST_E_BAD_DIGEST when I am trying with verification from catalog, and
TRUST_E_NOSIGNATURE when trying from file info. it is very important to mention that my function succeeds on win7, XP but fails on win8.
this is the code snippet for the function
CATALOG_INFO InfoStruct = {0};
InfoStruct.cbStruct = sizeof(CATALOG_INFO);
WINTRUST_CATALOG_INFO WintrustCatalogStructure = {0};
WintrustCatalogStructure.cbStruct = sizeof(WINTRUST_CATALOG_INFO);
WINTRUST_FILE_INFO WintrustFileStructure = {0};
WintrustFileStructure.cbStruct = sizeof(WINTRUST_FILE_INFO);
GUID ActionGuid = WINTRUST_ACTION_GENERIC_VERIFY_V2;
//Get a context for signature verification.
HCATADMIN Context = NULL;
if(!::CryptCATAdminAcquireContext(&Context, NULL, 0) ){
return false;
}
//Open file.
cx_handle hFile(::CreateFileW(filename_.c_str(), GENERIC_READ, 7, NULL, OPEN_EXISTING, 0, NULL));
if( INVALID_HANDLE_VALUE == (HANDLE)hFile )
{
CryptCATAdminReleaseContext(Context, 0);
return false;
}
//Get the size we need for our hash.
DWORD HashSize = 0;
::CryptCATAdminCalcHashFromFileHandle(hFile, &HashSize, NULL, 0);
if( HashSize == 0 )
{
//0-sized has means error!
::CryptCATAdminReleaseContext(Context, 0);
return false;
}
//Allocate memory.
buffer hashbuf(HashSize);
//Actually calculate the hash
if( !CryptCATAdminCalcHashFromFileHandle(hFile, &HashSize, hashbuf.data, 0) )
{
CryptCATAdminReleaseContext(Context, 0);
return false;
}
//Convert the hash to a string.
buffer MemberTag(((HashSize * 2) + 1) * sizeof(wchar_t));
for( unsigned int i = 0; i < HashSize; i++ ){
swprintf(&((PWCHAR)MemberTag.data)[i * 2], L"%02X", hashbuf.data[i ]);
}
//Get catalog for our context.
HCATINFO CatalogContext = CryptCATAdminEnumCatalogFromHash(Context, hashbuf, HashSize, 0, NULL);
if ( CatalogContext )
{
//If we couldn't get information
if ( !CryptCATCatalogInfoFromContext(CatalogContext, &InfoStruct, 0) )
{
//Release the context and set the context to null so it gets picked up below.
CryptCATAdminReleaseCatalogContext(Context, CatalogContext, 0);
CatalogContext = NULL;
}
}
//If we have a valid context, we got our info.
//Otherwise, we attempt to verify the internal signature.
WINTRUST_DATA WintrustStructure = {0};
WintrustStructure.cbStruct = sizeof(WINTRUST_DATA);
if( !CatalogContext )
{
load_signature_verification_from_file_info(WintrustFileStructure, WintrustStructure);
}
else
{
load_signature_verification_from_catalog(WintrustStructure, WintrustCatalogStructure, InfoStruct, MemberTag);
}
//Call our verification function.
long verification_res = ::WinVerifyTrust(0, &ActionGuid, &WintrustStructure);
//Check return.
bool is_success = SUCCEEDED(verification_res) ? true : false;
// if failed with CatalogContext, try with FILE_INFO
if(!is_success && CatalogContext && verification_res != TRUST_E_NOSIGNATURE)
{
//warning2(L"Failed verification with Catalog Context: 0x%x %s ; Retrying with FILE_INFO.", verification_res, (const wchar_t*)format_last_error(verification_res));
load_signature_verification_from_file_info(WintrustFileStructure, WintrustStructure);
verification_res = ::WinVerifyTrust(0, &ActionGuid, &WintrustStructure);
is_success = SUCCEEDED(verification_res) ? true : false;
}
if(perr && !is_success && verification_res != TRUST_E_NOSIGNATURE)
{
perr->code = verification_res;
perr->description = format_last_error(verification_res);
}
//Free context.
if( CatalogContext ){
::CryptCATAdminReleaseCatalogContext(Context, CatalogContext, 0);
}
//If we successfully verified, we need to free.
if( is_success )
{
WintrustStructure.dwStateAction = WTD_STATEACTION_CLOSE;
::WinVerifyTrust(0, &ActionGuid, &WintrustStructure);
}
::CryptCATAdminReleaseContext(Context, 0);
return is_success;
I don't think any thing had changed in this function from win7 to win 8 so what could possibly go wrong?
UPDATE
I did notice that my function does work for task manager at win 8.
but again for the mmc it does not work.
It appears that your general approach is correct and the functions themselves haven't changed. However there are subtle changes; namely the data on which they operate has changed. The hashes stored for files on Windows 8, according to comments on CryptCATAdminCalcHashFromFileHandle, are calculated using SHA-256 hashes.
The SHA-256 hashing algorithm is not supported by CryptCATAdminCalcHashFromFileHandle, so you must update the code to use CryptCATAdminAcquireContext2 and CryptCATAdminCalcHashFromFileHandle2 on Windows 8; the former allows you to acquire a HCATADMIN with a specified hash algorithm, and the latter allows using that HCATADMIN.
(Interestingly, WINTRUST_CATALOG_INFO also points this direction with its HCATADMIN hCatAdmin member, documented as "Windows 8 and Windows Server 2012: Support for this member begins.")