Decrypt my World : CryptAcquireContext

"Invalid provider type specified" error when accessing X509Certificate2.PrivateKey on CNG certificates

alejacma — Tue, 22 Dec 2009 09:58:00 GMT

Hi all,

You may get the following exception when trying to access X509Certificate2.PrivateKey on a .NET 3.5 (or older) app:

"
System.Security.Cryptography.CryptographicException: Invalid provider type specified.

at System.Security.Cryptography.Utils.CreateProvHandle(CspParameters parameters, Boolean randomKeyContainer)
at System.Security.Cryptography.Utils.GetKeyPairHelper(CspAlgorithmType keyType, CspParameters parameters, Boolean randomKeyContainer, Int32 dwKeySize, SafeProvHandle& safeProvHandle, SafeKeyHandle& safeKeyHandle)
at System.Security.Cryptography.RSACryptoServiceProvider.GetKeyPair()
at System.Security.Cryptography.RSACryptoServiceProvider..ctor(Int32 dwKeySize, CspParameters parameters, Boolean useDefaultKeySize)
at System.Security.Cryptography.X509Certificates.X509Certificate2.get_PrivateKey()
"

When this happened to me, I used my CryptoAPI Tracer on the problematic app to find out which CryptoAPI was failing and causing that exception. This was the one:

"
CryptAcquireContextA (0x448)

IN
pszContainer
0078a948 "anycontainername"

pszProvider
00773fb8 "Microsoft Software Key Storage P"
00773fd8 "rovider"

dwProvType
0

dwFlags
0

OUT
hProv
NULL

RESULT
CryptAcquireContextA (0x448) FAILED
LastErrorValue: (HRESULT) 0x80090014 (2148073492) - Invalid provider type specified.
LastStatusValue: (NTSTATUS) 0 - STATUS_WAIT_0
"

So the certificate I was using was associated to Microsoft Software Key Storage Provider, which is not a CSP but a KSP:

CNG Key Storage Providers
"
Unlike Cryptography API (CryptoAPI), Cryptography API: Next Generation (CNG) separates cryptographic providers from key storage providers (KSPs). KSPs can be used to create, delete, export, import, open and store keys. Depending on implementation, they can also be used for asymmetric encryption, secret agreement, and signing. Microsoft installs the following KSPs beginning with Windows Vista and Windows Server 2008.
"

This is a CNG certificate! This is what CertUtil.exe returns on the private key of that certificate:

"
Key Container = ...
Unique container name: ...
Provider = Microsoft Software Key Storage Provider
Private key is NOT exportable
Encryption test passed
"

So certutil.exe knows how to deal with this kind of CNG certificates. I used my CryptoAPI Tracer on CertUtil, and this tool is using CryptAcquireCertificatePrivateKey instead of CryptAcquireContext to access the keys of the cert. CryptAcquireCertificatePrivateKey has specific flags to deal with CNG:

CryptAcquireCertificatePrivateKey Function
"
CRYPT_ACQUIRE_ALLOW_NCRYPT_KEY_FLAG
This function will attempt to obtain the key by using CryptoAPI. If that fails, this function will attempt to obtain the key by using the Cryptography API: Next Generation (CNG).
The pdwKeySpec variable receives the CERT_NCRYPT_KEY_SPEC flag if CNG is used to obtain the key.
...
pdwKeySpec [out]
CERT_NCRYPT_KEY_SPEC
The key is a CNG key.
"

.NET is not CNG aware yet (at least up to version 3.5 SP1). It uses CryptAcquireContext instead of CryptAcquireCertificatePrivateKey and CryptAcquireContext has no flags to deal with CNG.

A possible workaround to this may be to use CryptoAPI/CNG API directly to deal with CNG keys. That is what certutil.exe does. But if we want an easier and pure .NET solution which understands CNG, this will help to implement it:

CLR Security
"
Security.Cryptography.dll provides a new set of algorithm implementations to augment the built in .NET framework supported algorithms. It also provides some APIs to extend the existing framework cryptography APIs. Within this project you will find:
§ A CNG implementation of the AES, RSA, and TripleDES encryption algorithms
§ A CNG implementation of a random number generator
§ A class that allows dynamically creating algorithms both from this library as well as all of the algorithms that ship with .NET 3.5
§ An enumerator over all of the installed CNG providers on the current machine
§ Extension methods that allow access to all of the keys installed in a CNG provider, as well as all of the algorithms the provider supports
"

If you want to use CNG with this dll, you have to do the following:

1) Change .NET version to 3.5. As far as I know the dll requires us to move at least to that version.

2) Reference Security.Cryptography.dll in your project.

3) Include "using Security.Cryptography.X509Certificates;" statement (in C#, of course) to activate CNG extensions for standard X509Certificate2 class.

Then you may check whether the cert has a CNG key using the extension .HasCngKey() for X509Certificate2. If you have a CNG key, you can then instantiate an RSACng object using the extension .GetCngPrivateKey() for X509Certificate2. You can then i.e. decrypt with RSACng.DecryptValue().

I hope this helps.

Regards,

Alex (Alejandro Campos Magencio)

CryptographicException: Unable to open the access token of the current thread

alejacma — Wed, 30 Jul 2008 10:41:00 GMT

Hi all,

When working with RSACryptoServiceProvider, we may get an exception like the following:

System.Security.Cryptography.CryptographicException: Unable to open the access token of the current thread
   at System.Security.Cryptography.CryptographicException.ThrowCryptogaphicException(Int32 hr)
   at System.Security.Cryptography.Utils._GetKeyParameter(SafeKeyHandle hKey, UInt32 paramID)
   at System.Security.Cryptography.Utils.GetKeyPairHelper(CspAlgorithmType keyType, CspParameters parameters, Boolean randomKeyContainer, Int32 dwKeySize, SafeProvHandle& safeProvHandle, SafeKeyHandle& safeKeyHandle)
   at System.Security.Cryptography.RSACryptoServiceProvider.GetKeyPair()
   at System.Security.Cryptography.RSACryptoServiceProvider..ctor(Int32 dwKeySize, CspParameters parameters, Boolean useDefaultKeySize)
   at System.Security.Cryptography.RSACryptoServiceProvider..ctor(CspParameters parameters)

I've seen this exception i.e. when signing an XML with a certificate associated to a specific Cryptographic Service Provider (CSP).

Let's use my CryptoAPI Tracer script to get all CryptoAPI calls that .NET is making behind the scenes. This will help us to know exactly what's going on.

We can see in the logs generated by the script the call to CryptAcquireContext we make to get the key container of the certificate. We can also see the CSP associated to the certificate:

CryptAcquireContextA (0xd8c)

IN
pszContainer
00228620  "2e065b6c-027a-4746-bdf3-901a9980"
00228640  "66ea"

pszProvider
00205e60  "Third-party CSP"

dwProvType
PROV_RSA_FULL

dwFlags
0

OUT
hProv
0x228248

RESULT
CryptAcquireContextA (0xd8c) SUCCEEDED

Note: I won't use the real name of the third-party CSP where I detected this issue. This post is for illustration purposes only. I don't prettend to blame anyone in particular.

Then .NET makes the following call to CryptGetKeyParam to find out the size of a buffer which will hold the value of the algorithm of the key:

CryptGetKeyParam (0xd8c)

IN
hKey
0x230058

dwParam
KP_ALGID

pbData
NULL 

dwDataLen
0

dwFlags
0

OUT
dwDataLen
4

RESULT
CryptGetKeyParam (0xd8c) FAILED
LastErrorValue: (HRESULT) 0x80010125 (2147549477) - Unable to open the access token of the current thread
LastStatusValue: (NTSTATUS) 0xc0000034 - Object Name not found.

Note on IN parameters:

- This hKey value is the key handle.

- This dwParam value indicates that we want the algorithm of the key.

- This pbData value indicates that there is no buffer available yet.

- This pdwDataLen value is 0 because we want to find out the size that we need for the pbData buffer.

- dwFlags should always be 0.

This call is returning 4 in dwDataLen, which is correct as the ALGID will be 4 bytes long. But the API is also returning the error 0x80010125 (2147549477) - "Unable to open the access token of the current thread". CryptoAPI just passes the parameters to the CSP and returns the results. The call to the API is 100% correct, but the CSP is not honoring it. This is not a bug in .NET or CryptoAPI. This is a bug on the CSP.

If you are facing this issue please contact the CSP provider. At least in the case of the third-party CSP where we found the issue they were already aware of it. They immediately sent an upgrade to our customers which fixed this issue.

I hope this helps.

Cheers,

Alex (Alejandro Campos Magencio)

Threading issues with RSACryptoServiceProvider

alejacma — Mon, 30 Jun 2008 16:01:00 GMT

Hi all,

When using RSACryptoServiceProvider in i.e. ASP.NET you may get the following exception under a heavy load scenario:

"System.Security.Cryptography.CryptographicException: CryptoAPI cryptographic service provider (CSP) for this implementation could not be acquired".

We've seen in past posts (sample) how we can use my CryptoAPI Tracer script to take a look to the CryptoAPI calls that RSACryptoServiceProvider makes behind the scenes.

In this case we can see that RSACryptoServiceProvider constructor calls CryptAcquireContext API. The first call to CryptAcquireContext API fails with error NTE_BAD_KEYSET ("Keyset does not exist"). Then a second call is attempted to create the key set, but it fails with error NTE_EXISTS ("Object already exists"). So it seems the keyset is there, but it can't be accessed. Concurrency issues? Maybe. Check this article first to verify that we don't get these errors for another reason: CryptAcquireContext fails with NTE_BAD_KEYSET.

So we are having concurrency issues. Consider the application performs the following sequence in two steps:
1) Open a given named machine key container.
2) If open fails, create that named machine key container.

This sequence is not an automatic operation. If multiple threads are attempting to do the same sequence and assume 2 threads attempt to create the same named machine key container, the second call will fail with "key container already exists".

As we've seen this is what RSACryptoServiceProvider constructor does similar to any application calling CryptAcquireContext API twice.

If the application is always working with the same RSA key in a named key container, key containers must be acquired only once in the process using CryptAcquireContext. When multiple threads are using the same RSA instance for encryption/decryption, the instance methods are not thread safe.

At the CryptoAPI level we've already seen threading issues when dealing with key handles in applications. When calling CryptoAPI directly we have a lot more control when the key handle is obtained, the type of handle, how it is used and whether it is thread safe. e.g. After a RSA key handle has been obtained by using the CryptGetUserKey function, RSA operations are thread safe.

There is not much control when using RSACryptoServiceProvider as it doesn’t expose key handles.

These are some suggestions to minimize threading issues in ASP.NET:

1) Set CspParameters.KeyContainer name when creating an RSACryptoServiceProvider object. Never use the default one, NEVER! This is prone to store corruption. We talked about this already.

2) Explicitely call Dispose on the RSACrytpoServiceProvider object when possible. This way, we don't rely on the Garbage Collector to "eventually" release the CSP.

3) Set UseMachineKeyStore in CspParameters.Flags when creating an RSACryptoServiceProvider. This flag tells RSACryptoServiceProvider to use "machine location" for storing RSA public/private key pair instead of the "current user" location. This is equivalent to calling CryptAcquireContext API with CRYPT_MACHINE_KEYSET. Make sure all the threads using the RSA instance are running under the same account.

4) Don't set RSACryptoServiceProvider.PersistKeyInCSP to False. This will cause the key container to be deleted when RSA instance is released or garbage collected. If multiple threads are trying to access the same named key container, the state of that named key container could be in a temporary cleaned up state and it cannot be acquired.

5) Another option would be for us to instantiate RSACryptoServiceProvider once as part of Web Application initialization and then use that same instance for encryption or decryption under a critical section like lock (i.e. Mutex). This would also avoid reacquiring key container multiple times from the same process.

I hope this helps.

Regards,

Alex (Alejandro Campos Magencio)

CryptAcquireContext fails with NTE_BAD_KEYSET

alejacma — Tue, 27 May 2008 11:00:00 GMT

Hi all,

When we try to access a key container, CryptAcquireContext may return NTE_BAD_KEYSET (or error # 0x80090016 or -2146893802 or "Keyset does not exist") for the following two reasons:

1) key container doesn't exist. You may repeat the call to CryptAcquireContext, but this time using CRYPT_NEWKEYSET flag to create a new key container.

2) user doesn't have permission to open the key container. If you need to find out where the key container is in order to set additional permissions, this post may help: Key Containers: Basics.

Let's imagine for a sec that we are already calling CryptAcquireContext with CRYPT_NEWKEYSET flag after the first call to CryptAcquireContext fails with error NTE_BAD_KEYSET, and this second call fails with error NTE_EXISTS (or error # 0x8009000F or -2146893809 or "Object already exists"). First we try to open the container and we fail, then we try to create it and it already exists. NTE_BAD_KEYSET means in this case that the user doesn't have permissions to open the key container, and not that it doesn't exist.

I hope this helps.

Cheers,

Alex (Alejandro Campos Magencio)

CryptAcquireContext fails with ERROR_FILE_NOT_FOUND

alejacma — Thu, 22 May 2008 15:35:00 GMT

Hi all, welcome back,

CryptAcquireContext API will fail with error #2 or ERROR_FILE_NOT_FOUND if:

1) the user's profile is not loaded, as we saw in my post RSACryptoServiceProvider fails when used with ASP.NET.

2) AppData registry value in the following registry key is not present or is misconfigured:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

As we saw in the other post I mentioned above, private keys are protected by DPAPI (Data Protection API). DPAPI needs to find the Application Data directory where the Master Key is stored. DPAPI will read the directory from AppData value and will use the Master Key to protect CryptoAPI private keys or EFS private keys, for instance.

Note that similar errors may occur for the same reasons:

1. CryptProtectData API fails with ERROR_FILE_NOT_FOUND.

2. Encrypting a file/folder with EFS via Windows Explorer fails with "The system cannot find the file file specified".

Note that Security Bulletin MS04-011 changed the registry key where the path could be found. Previous one was in here:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders

I hope this helps.

Regards,

Alex (Alejandro Campos Magencio)

How to select which Smart Card reader to perform actions on

alejacma — Mon, 03 Mar 2008 14:40:00 GMT

Hi all, welcome back,

Most of the time we only have a smart card reader in our machine, and we only use one smart card to perform crypto operations. But what if we have several readers and cards, and those cards share the same CSP (Cryptographic Service Provider)? Can we select the one we want to use when working with CryptoAPI/XEnroll/CertEnroll?

Let's take a look to XEnroll, for instance: We can set WriteCertToCSP Property of the ICEnroll4 Interface to TRUE so the certificates will be written to the smart card in addition to being written to "MY" store when calling i.e. acceptPKCS7 method (Note: WriteCertToCSP is TRUE by default). But apparently we can't specify which card we want to write the cert to. So what happens if we have two cards with same CSP inserted at the same time? Well, in this case the CSP itself will be responsible of giving the user the possibility to choose the card it wants. When we enroll the cert, the CSP should show a dialog so we can choose the appropiate card.

As you sure know, XEnroll won’t work on Vista. Vista now uses the new certificate enrollment component CertEnroll (see Certificate Enrollment API for more info). But my comments still apply here: the CSP should help us to choose the card.

And what if we want to do the selection programmatically? Can that be done? Yes, we may be able to do it. If we want to select the card for the CSP then we should figure out which reader the card is in, and then use the "\\.\<Reader Name>\" format for the container name when calling CryptAcquireContext API, for instance. If we also know the container name we can use "\\.\<Reader Name>\<Container Name>\" (See the smart card white paper for more details on our MS Base CSP). The CSP should be able to work with the right card.

I hope this helps.
Cheers,

Alex (Alejandro Campos Magencio)

RSACryptoServiceProvider fails when used with ASP.NET

alejacma — Mon, 03 Dec 2007 12:00:00 GMT

Hi, welcome back,

I will talk today about a very common issue we face when we try to use .NET's RSACryptoServiceProvider class in ASP.NET.

When we try to create a new RSACryptoServiceProvider object in this scenario, we may get the following exception:

"System.Security.Cryptography.CryptographicException: The system cannot find the file specified".

By using my CryptoAPI Tracer script we can take a look to the CryptoAPI calls that .NET is making behind the scenes. Thanks to this script we will be able to see the exact API that is failing and the exact error (which most of the time .NET masks).

In our case, the API that fails is CryptAcquireContext, and it fails with error #2 (ERROR_FILE_NOT_FOUND). According to CryptAcquireContext documentation, this error means the following:
"
The profile of the user is not loaded and cannot be found. This happens when the application impersonates a user, for example, the IUSR_ComputerName account.
"

By default, ASP.NET won't load the user profile. Take a look to the parameters of the problematic CryptAcquireContext call as being shown in the log file that my script generated. If this API is not being called with CRYPT_MACHINE_KEYSET (to use the machine profile) or CRYPT_VERIFYCONTEXT (to use temporary key stores), it will try to access the key stores in the user profile, and it will fail because its not loaded.

Which options do we have here then?

1) If we need each user running your ASP.NET app to use their own key stores, we will have to load their user profile. We can do it with LoadUserProfile API. The only problem is that the privileges needed to execute this API are quite powerful for a standard user.

2) If we still need the user profile and don't want to give users enough privileges to run LoadUserProfile, there is a trick we can use: Service Control Manager (SCM) will automatically load the profile of the user that a Windows service uses to run. So we may create a dummy Windows service which runs with our user's credentials. This service won't need to do anything special, just stay alive. SCM will load the user profile for us and ASP.NET will be able to use it automatically once it gets loaded.

3) We may also use machine key stores instead of user's. We just have to pass CRYPT_MACHINE_KEYSET flag to CryptAcquireContext. In order to do that in .NET, we may use a code like this:

CspParameters RSAParams = new CspParameters();
RSAParams.Flags = CspProviderFlags.UseMachineKeyStore;
RSACryptoServiceProvider sp = new RSACryptoServiceProvider(1024, RSAParams);

Note. When we use machine key stores, any user in that machine may have access to those keys.

I hope this helps.

Cheers,

Alex (Alejandro Campos Magencio)

How to trace CryptoAPI calls (2)

alejacma — Fri, 09 Nov 2007 01:46:00 GMT

Hi, welcome back,

Let's try to understand a bit better what's going on my CryptoAPI Tracer script.

Let's take a look to one of the most important breakpoints I set on a CryptoAPI function:

bm Advapi32!CryptAcquireContextW ".printf \"\\n>>>>>>>>>>>>>>>>>>>>>>\\n\\nCryptAcquireContextW (%#x)\\n\", @$tid; .echo;.echo IN; .echo pszContainer; .if(poi(@esp+8)=0) {.echo NULL} .else {du poi(@esp+8)}; .echo;.echo pszProvider; .if(poi(@esp+c)=0) {.echo NULL} .else {du poi(@esp+c)}; .echo;.echo dwProvType; .if(poi(@esp+10)=1) {.echo PROV_RSA_FULL} .elsif(poi(@esp+10)=0x18) {.echo PROV_RSA_AES} .else {.printf \"%d\\n\", poi(@esp+10)}; .printf \"\\ndwFlags\\n%#x\\n\", poi(@esp+14); .if((poi(@esp+14)&0x0`F0000000)=0x0`F0000000) {.echo CRYPT_VERIFYCONTEXT(0xf0000000)}; .if((poi(@esp+14)&0x0`00000008)=0x0`00000008){.echo CRYPT_NEWKEYSET(0x8)}; .if((poi(@esp+14)&0x0`00000010)=0x0`00000010) {.echo CRYPT_DELETEKEYSET(0x10)}; .if((poi(@esp+14)&0x0`00000020)=0x0`00000020) {.echo CRYPT_MACHINE_KEYSET(0x20)}; .if((poi(@esp+14)&0x0`00000040)=0x0`00000040) {.echo CRYPT_SILENT(0x40)}; bp /t @$thread poi(@esp) \" .echo;.echo OUT; .if(poi(@esp-14)=0) {.echo phProv;.echo NULL} .else {.echo hProv; .if(poi(poi(@esp-14))=0) {.echo NULL} .else {.printf \\\"%#x\\\\n\\\", poi(poi(@esp-14))} }; .echo;.echo RESULT; .if(@eax=1) {.printf \\\"CryptAcquireContextW (%#x) SUCCEEDED\\\\n\\\", @$tid} .else {.printf \\\"CryptAcquireContextW (%#x) FAILED\\\\n\\\", @$tid;!gle}; .echo;.echo <<<<<<<<<<<<<<<<<<<<<<; G;\"; G;";

It looks a bit complex, but it's not so much. Some of the basics where already explained here.

Imagine we have the following API declaration in C:

int __stdcall myFunction(int a, int b, int c);

If I set a breakpoint on myFunction, and because we use __stdcall calling convention (the same as Win32 API/CryptoAPI functions), the stack will look this way just when we reach the breakpoint, before we run any code on myFunction:

return address <-- esp
a              <-- esp+4
b              <-- esp+8
c              <-- esp+c
xxxxxxxx
yyyyyyyy
zzzzzzzz

"esp" (stack pointer) register will be pointing to the address where we'll return after finishing executing myFunction. If we want to i.e. access the second parameter of the function, we can use the address esp+8.

When we finish executing myFunction and we return from it, "eax" register will contain the return value of the API and the stack will look like this:

xxxxxxxx       <-- esp
yyyyyyyy
zzzzzzzz

Now, if we want to access one of the parameters of the API we just called (i.e. because it's an out parameter), we have to remember that the information of the stack is not cleaned. So even if "esp" register points to "xxxxxxxx" now, the parameters of the API are still on the stack:

a              <-- esp-c
b              <-- esp-8
c              <-- esp-4
xxxxxxxx       <-- esp
yyyyyyyy
zzzzzzzz

So if we want to i.e. access the first parameter of the API we can use esp-c address.

Having said this, let's write the breakpoint above in a different way:

000 bm Advapi32!CryptAcquireContextW 
001 "
002     .printf \"\\n>>>>>>>>>>>>>>>>>>>>>>\\n\\nCryptAcquireContextW (%#x)\\n\", @$tid;
003
004     .echo;
005     .echo IN;
006
007     .echo pszContainer;
008     .if(poi(@esp+8)=0)
009     {
010         .echo NULL
011     }
012     .else
013     {
014         du poi(@esp+8)
015     };
016
017     .echo;
018     .echo pszProvider;
019     .if(poi(@esp+c)=0)
020     {
021         .echo NULL
022     }
023     .else 
024     {
025         du poi(@esp+c)
026     };
027
028     .echo;
029     .echo dwProvType;
030     .if(poi(@esp+10)=1) 
031     {
032         .echo PROV_RSA_FULL
033     }
034     .elsif(poi(@esp+10)=0x18) 
035     {
036         .echo PROV_RSA_AES
037     }
038     .else
039     {
040         .printf \"%d\\n\", poi(@esp+10)
041     };
042
043     .printf \"\\ndwFlags\\n%#x\\n\", poi(@esp+14); 
044     .if((poi(@esp+14)&0x0`F0000000)=0x0`F0000000) 
045     {
046         .echo CRYPT_VERIFYCONTEXT(0xf0000000)
047     }; 
048     .if((poi(@esp+14)&0x0`00000008)=0x0`00000008)
049     {
050         .echo CRYPT_NEWKEYSET(0x8)
051     };
052     .if((poi(@esp+14)&0x0`00000010)=0x0`00000010)
053     {
054         .echo CRYPT_DELETEKEYSET(0x10)
055     };
056     .if((poi(@esp+14)&0x0`00000020)=0x0`00000020)
057     {
058         .echo CRYPT_MACHINE_KEYSET(0x20)
059     };
060     .if((poi(@esp+14)&0x0`00000040)=0x0`00000040)
061     {
062         .echo CRYPT_SILENT(0x40)
063     };
064
065     bp /t @$thread poi(@esp)
066     \"
067         .echo;
068         .echo OUT;
069
070         .if(poi(@esp-14)=0)
071         {
072             .echo phProv;
073             .echo NULL
074         }
075         .else
076         {
077             .echo hProv;
078             .if(poi(poi(@esp-14))=0)
079             {
080                 .echo NULL
081             }
082             .else
083             {
084                 .printf \\\"%#x\\\\n\\\", poi(poi(@esp-14))
085             }
086         };
087
088         .echo;
089         .echo RESULT;
090
091         .if(@eax=1)
092         {
093             .printf \\\"CryptAcquireContextW (%#x) SUCCEEDED\\\\n\\\", @$tid
094         }
095         .else
096         {
097             .printf \\\"CryptAcquireContextW (%#x) FAILED\\\\n\\\", @$tid;!gle
098         };
099
100         .echo;
101         .echo <<<<<<<<<<<<<<<<<<<<<<;
102
103         G;
104     \";
105
106     G;
107 ";

000) We set a breakpoint on the UNICODE version of CryptAcquireContext API. This is the declaration of the API:

BOOL WINAPI CryptAcquireContext(__out HCRYPTPROV* phProv, __in LPCTSTR pszContainer, __in LPCTSTR pszProvider, __in DWORD dwProvType, __in DWORD dwFlags);

The following commands will be executed when the application calls this API and we reach the breakpoint:

002) We print the name of the API and the id of the thread which calls it.

005) We print the string "IN", and after that we'll print the values of the __in parameters of the API.

007-015) We print pszContainer parameter as a string of Unicode chars, after checking if it's NULL or not.

018-026) We print pszProvider parameter as a string of Unicode chars, after checking if it's NULL or not.

029-041) We print dwProvType parameter. If we know the type we print it in clear text, otherwise we just print its numeric value.

043-063) We print dwFlags parameter in Hexadecimal. If we know the values of those flags, we print them in clear text.

065) Now we want to know what happened after the API finished executing. We set a breakpoint at the return address where we will return after calling the API. If we don't want weird things to happen on multi-threaded applications, we have to specify on which thread ("$thread" pseudo-register) we are setting that breakpoint.

106) Once we've set the breakpoint at 065, we can continue the execution of the application.

Now, let see what happens when we stop on breakpoint set at 065:

068) We print the string "OUT", and after that we'll print the values of the __out parameters of the API.

070-086) We print phProv parameter. This is a pointer to hProv. If the pointer is not NULL, we print the Hexadecimal value of hProv, after checking if this value is NULL or not.

089) We print the string "RESULT", and after that we'll print the return value of the API, and the error if there was one.

091-098) We show if the API succeeded or not. If not, we also show the error value that the API returned.

103) Now that we know the result of calling the API, we can continue the execution of the application and trace more APIs.

I hope this helps.

Cheers,

Alex (Alejandro Campos Magencio)

RSACryptoServiceProvider fails when used with mandatory profiles

alejacma — Tue, 23 Oct 2007 13:27:00 GMT

Hi, welcome back,

I will talk today about a very common issue we face when we try to use .NET's RSACryptoServiceProvider (http://msdn2.microsoft.com/en-us/library/system.security.cryptography.rsacryptoserviceprovider.aspx) class with mandatory profiles (i.e. Citrix environment).

When we try to create a new RSACryptoServiceProvider object in this scenario, we get the following exception:

"System.Security.Cryptography.CryptographicException: Cryptographic Service Provider (CSP) for this implementation could not be acquired".

This behavior is by design for security protection.

RSACryptoServiceProvider calls CryptAcquireContext API (http://msdn2.microsoft.com/en-us/library/aa379886.aspx) behind the scenes to get a handle to a key container within a CSP (Cryptographic Service Provider). CryptAcquireContext will fail with NTE_TEMPORARY_PROFILE error when called from a mandatory profile.

Mandatory profiles are read-only user profiles. Since changes to the mandatory profile cannot be saved, PKI design doesn't allow this operation, and CryptAcquireContext prevents this scenario by failing.

Private keys are protected by DPAPI (Data Protection API) component of Windows. DPAPI component regularly creates new Master Keys in the profile to protect confidential information such as private keys. For security reasons, Master Keys will expire, which means that after a period of time, the hard-coded value being three months, a new Master Key is generated and protected in the same manner. This expiration prevents an attacker from compromising a single Master Key and accessing all of a user's protected data.

The Master Key regeneration is explained in the DPAPI white-paper at:

Windows Data Protection
http://msdn2.microsoft.com/en-us/library/ms995355.aspx

So, higher level components that depend on DPAPI to protect confidential information cannot be protected securely with read-only profiles.

More information about all this can be found here:

Cryptographic Keys and Certificates Cannot Be Used with Mandatory Profiles
http://support.microsoft.com/default.aspx?scid=kb;en-us;264732

How to troubleshoot the Data Protection API (DPAPI)
"DPAPI and Mandatory Profiles"
http://support.microsoft.com/default.aspx?scid=kb;en-us;309408

Cannot Gain Access to Microsoft Encrypted File Systems
http://support.microsoft.com/kb/243850/en-us

There are three possible solutions to this issue:

1) If you need to access some user’s private keys (i.e. when signing data) and you want to prevent other users from using its keys, the only way is configuring the profile as non-mandatory.

2) If you need a persistent RSA private key, then the only solution is to use CryptAcquireContext with the CRYPT_MACHINE_KEYSET flag (or RSACryptoServiceProvider with the CspProviderFlags.UseMachineKeyStore flag) for private key storage in this configuration. But this is not protected based on the user's password hash, so any user with access to the machine may have access to those keys.

3) If you don’t need persistent RSA private keys (i.e. when verifying signatures), you could use CryptAcquireContext with the CRYPT_VERIFYCONTEXT flag. This flag tells CryptoAPI to create the key container in memory and not in the user’s profile. And you won't need to worry about deleting the key container; you just release the handle with CryptReleaseContext (http://msdn2.microsoft.com/en-us/library/aa380268.aspx).

Additional info about CryptAcquireContext & CRYPT_VERIFYCONTEXT can be found here:

238187 CryptAcquireContext() use and troubleshooting
http://support.microsoft.com/?id=238187

The problem is that, at the moment of this writing, creating a temporary key container with RSACryptoServiceProvider is not possible. We may think of using CryptAcquireContext with CRYPT_VERIFYCONTEXT flag to get a handle to the key container within the CSP before using RSACryptoServiceProvider, but RSACryptoServiceProvider maintains its own cryptographic handle and it's not possible to give RSACryptoServiceProvider a handle to use. We have already requested .NET Framework developers to expose CRYPT_VERIFYCONTEXT for us, but I can't tell when we will get such a feature.

The way to i.e. verify signatures using temporary keysets in .NET would be to use CryptoAPI directly through P/Invoke (Platform Invoke), instead of using RSACryptoServiceProvider.

I hope this helps.

Cheers,

Alex (Alejandro Campos Magencio)

PS: In a near future I will post how we can easily see which CryptoAPI calls .NET is making behind the scenes. When a CryptoAPI call fails, .NET captures the error and it returns its own exception, which is not always self-explanatory as we've seen today. We will be able to see the failing CryptoAPI, and which error is actually returning. This way, if we see a "Cryptographic Service Provider (CSP) for this implementation could not be acquired" error, we will be able to see for instance that CryptAcquireContext is failing with NTE_TEMPORARY_PROFILE and that will give us some clues about what's going on there.