CNG signature provider registration problem
I've written a DLL which implements a signature algorithm using the example code from CPDK as a base. I cannot get Windows 10 certificate UI to honor calling my DLL when it gets the certificate. DLL works normally if you use BCryptOpenAlgorithmProvider() with my algorithm name, (which is unique), DLL gets loaded. Thus I presume the provider registration is fine. The separate part to DLL is OID registration where I get algorithm name in string in certificate UI (thus OID lookup in registry works), algorithm names match, but it isn't called.
There is no example for this class of provider in CPDK, nor for its OID registration. But there is for other kind(s) of providers.
There is CRYPT_OID_INFO structure in API for OID->algo registration but it seems to take two different 'names', pwszName labeled as 'provider name' and pwszCNGAlgid labeled as 'AlgId string passed to BCrypt API'. Setting these to same string which is algo name doesn't do anything. Setting the latter to algo name and former to something else just makes that something else appear in the certificate UI. Again I'm referring to HashProviderOIDRegistration example from CPDK which could be working differently.
Worth mentioning is that this chain of trust uses the custom algorithm through, thus CA/subCA will also be signed by it. The authority also uses same OID for algorithm and public key.
Are CNG signature providers for the use of certificate UI? Have you registered OID Functions properly? Could It be the certificate UI doesn't find the proper provider?
That is unknown to me and I was hoping to find the answer here. Does certificate UI call CNG router by design?
I have included both your tips to no avail.
I'm not sure how CryptRegisterOIDFunction cohabitates with CNG. The way I understand it CNG routes by class and algorithm name. This is exactly how I'm able to open my provider DLL from some standalone client code using BCryptOpenAlgorithmProvider passing only my algorithm name.
From the DLL side this registration is done by exporting BCRYPT_SIGNATURE_FUNCTION_TABLE interface implementation. The mapping is done by "filling out" CRYPT_INTERFACE_REG struct, CRYPT_IMAGE_REG, CRYPT_PROVIDER_REG, and sending them to BCrypt API functions which in turn create the appropriate registry entries.
Why the need to re-register the DLL with CryptRegisterOIDFunction? What is the "name of the function", pszFuncName? I set that to exported symbol of a function that implements the BCryptVerifySignatureFn, no luck, the DLL isn't loaded from certificate UI.
I guess main thing that I want to know right now is if Cert UI uses CNG at all.
Sign in to comment