Re: Application requirement for persistent key pairs

You do have a few options. You are correct, the CRYPT_MACHINE_KEYSET will
make key available to your service, as well as everyone else on the system.
You can import key pairs, and they will be persisted.

You can also import the key pairs with the CRYPT_VERIFYCONTEXT flag on the
CryptAcquireContext. That will make the keys usable, but will not persist
them. Then you can reload them each time your service needs them, and
protect their storage medium as you see fit.

Or, once imported, you can call CryptSetProvParam with PP_KEYSET_SEC_DESCR
and set the ACLs on the key file so that only your service account can
access the keys.

Doug Barlow
The Soft Pedal Shop
CSP Design & Development Consulting
http://www.SoftPedal.net
--
"Tim" <Tim@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:FC53C9F4-B202-4EA4-833E-83855448CA6F@xxxxxxxxxxxxxxxx
If an application deployed as a service which requires private key
operations
(assuming the application signs information that it produces) then I
believe
I need to CryptAcquireContext with the flag CRYPT_MACHINE_KEYSET as I will
not have a user profile for the key container?

If I name my container something appropriate for my application to access
and generate (or import) AT_EXCHANGE and AT_SIGNATURE key pairs, for use
by
the application, will these keys be persisted? I assume within
"C:\Documents
and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys"?

Hopefully the answer to the above is yes which leads to my final
question -
what protects these keys? If another application runs as the local system
and
it enumerates the containers (or finds out the container I am using from
my
code) can it simply gain access to the private keys through the CryptoAPI
and
possibly pose as my service?

Thanks for any help/guidance on this query.
Tim.


.

Relevant Pages

  • Re: Can Cryptoapi key container have several exchange/signature ke
    ... Any container may have of maximum one AT_KEYEXCHANGE and maximum one ... AT_SIGNATURE keypairs - and this must be obeyed by each CSP. ... >> key pairs to the key container by calling CryptGenKeyrepeatly? ...
    (microsoft.public.platformsdk.security)
  • Re: Application requirement for persistent key pairs
    ... Many thanks Doug for your reply. ... regarding the modification of ACLs on the key container (which is the ... You can import key pairs, ... and set the ACLs on the key file so that only your service account can ...
    (microsoft.public.platformsdk.security)
  • Re: Private key different; Public key same on Different Machines
    ... Okay, that clears things up. ... I didn't realize that there were two key pairs ... in the container. ... the Crypto API has always eluded me a little. ...
    (microsoft.public.dotnet.security)
  • Basic questions about CryptAcquireContext and thread safety
    ... As each server thread starts, CryptAcquireContext() is invoked with a NULL container name and the CRYPT_VERIFYCONTEXT bit in order to create a HCRYPTPROV for the thread. ... Is it safe to call CryptAcquireContext/CryptReleaseContext within the scope of a function, without disturbing or overwriting cryptographic information associated with other HCRYPTPROV handles in that thread? ...
    (microsoft.public.platformsdk.security)
  • Re: RSA Encryption without Session Keys - (I know its a bad idea)
    ... CryptAcquireContext. ... container which is gone when you call CryptReleaseContext, ... "Mounir IDRASSI" wrote: ... If you want to do encryption, you certainly have only the certificate ...
    (microsoft.public.platformsdk.security)