Re: Application requirement for persistent key pairs
- From: Tim <Tim@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sun, 18 Jun 2006 12:22:01 -0700
Many thanks Doug for your reply. I have a couple of additional questions
regarding the modification of ACLs on the key container (which is the
preferred suggestion).
If a service is running as "ServiceAccoutA" and is using a key container of
"KeyContainerA" and a key import process creates the container and imports
the keys (which should be run as user "KeyUpdateA") is it best to first
retrieve the the DACL (using CryptGetProvParam a dwParam of
PP_KEYSET_SEC_DESCR and a dwFlags of DACL_SECURITY_INFORMATION) - remove all
ACEs and then explicitly add a read permission for "ServiceAccountA" and a
write permission for the account that should run the key import application
("KeyUpdateA")?
What is the default DACL created for a key container? Is it only the DACL
and SACL I need to modify in this way to secure the container adequately?
Thanks in advance,
Tim
"Doug Barlow" wrote:
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.
- References:
- Re: Application requirement for persistent key pairs
- From: Doug Barlow
- Re: Application requirement for persistent key pairs
- Prev by Date: Re: Determine AD group membership
- Next by Date: Re: Determine AD group membership
- Previous by thread: Re: Application requirement for persistent key pairs
- Next by thread: In XEnroll custom csp stopping with 0x8000FFFF.
- Index(es):
Relevant Pages
|
