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

Reply via email to