PRB: Private Key Operations May Fail on Windows NT 4.0 (286799)

SYMPTOMS

Private key operations, such as the CryptSignMessage(), CryptSignHash(), CryptImportKey(), and CryptDecrypt() APIs, may fail on Windows NT 4.0 in situations in which machine keys are used and the calls are made in a security context other than the interactive logged on user. These symptoms are seen even though CryptAcquireContext() is called successfully.

NOTE: This is not a problem on Windows 2000.

CAUSE

The problem lies in the "Protected Storage" service. CryptoAPI uses protected storage to store and access the public/private key pair.

When a thread creating a machine key runs under a user account with a loaded profile, only user accounts with loaded profiles can access the private machine key. For example, if the interactive user creates a machine key, the IUSR cannot use the private key unless IUSR's profile is loaded. This behavior contradicts the reason for creating a machine key.

RESOLUTION

There are two possible ways to avoid this problem:

The best solution is to make sure that the user account that creates the key does not have a loaded profile.
If the application is accessing an existing machine key (in other words, you don't have control of the key creation), you can load the user's profile programmatically before calling any crypto APIs. The LoadUserProfile() API can be used to accomplish this. LoadUserProfile() requires administrative privileges. Therefore, writing a Windows NT service to load the user's profile is the best approach.

MORE INFORMATION

Machine keys are created by a call to CryptAcquireContext with the CRYPT_MACHNE_KEYSET|CRYPT_NEWKEYSET flags followed by a call to CryptGenKey with the AT_KEYEXCHANGE or AT_SIGNATURE flag.

REFERENCES

For additional information, click the article number below to view the article in the Microsoft Knowledge Base:

238187 INFO: CryptAcquireContext() Use and Troubleshooting