Milan,
I've just had a look at this, and for the life of me I don't understand why I used CRYPT_MACHINE_CONTEXT in the first place. This is used to trick the CAPI into allowing us to import a plaintext key for use in the encryption classes. It would make far more sense to use a per-user key store.
I didn't want to use the default m_provRSA because that it a true user key - this was simply a wrapper key. But it can (and should) be created on a per-user basis.
The only exception to this would be if the library is being used as a standalone process (which is really what CRYPT_MACHINE_CONTEXT is for). So maybe that should be a cofiguration call on the constructor?
Cheers, Berin
Milan Tomic wrote:
Berin,
If you take a look into beginning of WinCAPICryptoProvider.cpp file ( _http://cvs.apache.org/viewcvs.cgi/xml-security/c/src/enc/WinCAPI/WinCAPICryptoProvider.cpp?rev=1.15&view=markup_ <http://cvs.apache.org/viewcvs.cgi/xml-security/c/src/enc/WinCAPI/WinCAPICryptoProvider.cpp?rev=1.15&view=markup> ), you will notice this line:
*if* (!CryptAcquireContext(&m_provApacheKeyStore, s_xsecKeyStoreName, provRSAName, m_provRSAType, CRYPT_MACHINE_KEYSET))
Well, the problem is that when some user doesn't have admin rights s/he can't acquire CRYPT_MACHINE_KEYSET and initialzation of XSEC fails (XSEC exception is thrown). Perhaps we should use m_provRSA instead of m_provApacheKeyStore in WinCAPICryptoProvider class or use some other flag than CRYPT_MACHINE_KEYSET for m_provApacheKeyStore.
More info in the MSDN about CRYPT_MACHINE_KEYSET:
_http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/security/cryptacquirecontext.asp_
_http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B238187_
Best regards, Milan