Relationship between Windows key container and Certificate

In fact, CSP mainly operates on the key pair in the container and has little to do with the certificate. There are two types of key pairs in the container: at_keyexchange, which indicates an encrypted key pair, and at_signature indicates a signed key pair. Due to exit restrictions in the United States, the maximum length of the key pair that can be encrypted in the ms csp is usually shorter than that of the signed key pair. Generally, an encrypted key pair is only used for encryption. A signed key pair is only used for signature. For some reason (such as generating a certificate request), an encrypted key pair can also be used for signature. I think of at_keyexchange and at_signature as two locations in the container. In the smart card CSP, you can write the certificate into the container, and the certificate corresponding to the encrypted key pair is written to the at_keyexchange location, and the certificate corresponding to the signed key pair is written to the at_signature location. It is determined that the public key of the certificate is the same as the public key of the key pair, rather than the extension of the key usage in the certificate. You can use the crypto API to find the key pair in the container corresponding to the cert_key_prov_info_prop_id of the certificate in the certificate library. Dwkeyspec in crypt_key_prov_info refers to the key pair type in the container. If the CSP implementation level limits whether the certificate can be encrypted and signed based on the extension of the certificate's key usage, the certificate should be read first. This operation is slow and it is estimated that the implementers are rarely used.

 

In fact, the at_keyexchange and at_signature key pairs of Minghua EKEY can both be encrypted and signed (cryptdecrypt and cryptsignhash are no problem, and no cryptimportkey has been tested, I don't know if it is a signed key pair and whether it can be successfully imported into the session key ). I don't have the same xcsp_eclib.dll version as yours. I used a slightly older version for testing. I tested the cryptdecryptmessage function and found that if it is a signature key pair, regardless of how the Key Usage extension of my certificate is set, decryption will always fail (the same is true with the CSP of MS ). The encrypted key pair can be used successfully. Although outlook may not use cryptdecryptmessage to decrypt CMS envelopeddata, I believe that in the end, it will call CSP's cryptimportkey to obtain the symmetric key and then decrypt it. Cryptdecryptmessage is a simple-key blobs that is passed to cryptimportkey. My test showed that the EKEY always uses an encrypted key pair for decryption. This may be because the structure of the simple-key blobs is faulty, leading to decryption failure, or a bug in the cryptimportkey of the ekey csp causes decryption failure. It seems that to make the Certificate both encrypted and signed, you must first ensure that the encryption key pair is used. You can use xenroll to create an encrypted key pair when generating a certificate request, the method for importing PKCS #12 files depends on the software used to determine the type of key pair to be created.