Re: Alternative store vs. MY store
From: WT (wyt168_at_newsgroup.nospam)
Date: 09/19/05
- Next message: Anthony Hunter: "Updating security on a folder."
- Previous message: Byron: "Re: PKCS7 renewal request"
- In reply to: Jan Spooren: "Re: Alternative store vs. MY store"
- Next in thread: Sylvain: "Re: Alternative store vs. MY store"
- Reply: Sylvain: "Re: Alternative store vs. MY store"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 19 Sep 2005 12:13:40 -0700
Hi, Jan & Sylvain:
Thank you both for the clarification. Yes, I don't think copying the cert to
the MY store is really my concern but the private key sure is--I don't want
the private key to leave my alternative physical store--which is a USB flash
memory card.
So here is what I want to do with this implementation, I hope I can get some
suggestions and tips as to how to achieve each of the objectives:
1. store both the client cert and its associate private key on my USB memory
card.
2. copy the cert to the MY store when client authentication is required but
keep the private key on the memory card all the time.
3. perform some authentication such that only the apps on my "allowed" list
to access the cert and its associated private key.
So far I have done the implementation to copy the cert to the local MY
store. However, it seems to be really hard to perform any authentication on
the applications that want to use the cert if I still use the default CSP.
It looks like I need to provide my own CSP in order to achieve #3. So I have
implemented a custom CSP that wraps the default MS CSP, i.e. my CSP
intercepts the CP_xxx calls and in turn loads and calls the default MS CSP.
So far it looks like I can have the MS CSP handle the basic cert store
operation for the cert copied to the local MY store. However, since the
private key is on my flash drive, I will need to implement my own routines
to handle calls that involves the private key. Is this assumption correct?
My questions are as follows:
1. In order to handle operations involving the private key, what are the
CP_xxx functions do I need to implement in my custom CSP? I hope to leverage
as much the default CSP fucntionalities as possible. I have read the MSDN
article "The Smart Card Cryptographics Service Provider Cookbook" which has
an example of what CP_xxx fucntions are involved in client authentication.
Basically here is a list of calls made during a client authentication:
CryptAcquireContext
Acquire a handle to the default container on the card
Returns handle to default container context
2. CryptCreateHash
Get a handle to an SHA hash object
Returns a handle to a hash object
3. CryptSetHashParam
Called with the HP_HASHVAL parameter and no data
4. CryptSignHash
Call SignHash to get the size of the signature
Returns the size of the signature in bytes
5. CryptSignHash
Sign the hash
Returns the signed hash
6. CryptDestroyHash
Release the handle to the hash object
Is this all that needs to be modified?
2. I have also looked at the possibility of providing an alternative
physical store to be located on my flash drive by CertRegisterPhysicalStore.
My hope is that by creating a physical store on my flash drive and then hand
the handle to the physical store to the base CSP for it to take care of all
the business. The difference is that in stead of storing the private key in
the host registry somewhere (which I think is how it works for the MS base
CSP), the private key is stored in the physical store on my flash drive.
Will this scheme work?
Thanks in advance.
"Jan Spooren" <jspooren@nospam.nospam> wrote in message
news:ehd73%23buFHA.1572@TK2MSFTNGP10.phx.gbl...
> Hi,
>
>>> If that's the case, what's point of storing the cert in a smartcard? One
>>> reason of storing the certifcate on smartcard is that it never leaves
>>> the smartcard. The only way to access the certificate is through the
>>> CryptoAPI via the custom CSP, thus making it more secure than leaving it
>>> in the host's registry.
>>> Am I missing something here?
>>
>> the private keys never leave the card, the certs can leave it w/o
>> concern; actually they have to leave it to be inserted into cert store.
>
> As Sylvain pointed out, there is no point in requiring certificates to
> never leave the smart card, as they are really public in nature, and must
> be provided to authenticate.
>
> One of the reasons to store certificates on the smart card is for smart
> card logon: At the time of the logon screen, no user is logged on and no
> personal store is thererfore available. Also, requiring the smart card
> logon certificate of a certain user to be in a machine store would require
> you to first install it on each machine, before the user can logon to
> those systems.
> Therefore, a smart card has one key container with is marked as default
> container. When the user inserts the smart card in order to logon,
> Windows will open the default container on the smart card and retrieve its
> certificate. This certificate will then be used in the logon process.
> This mechanism allows you to logon with your smart card to systems that
> you have never logged on before.
>
> Most smart card software will have a service that detects smart card
> insertions and will copy the certificates from the smart card into the
> currently logged on user's store. This functionality allows you to use
> your certificates as well on a machine that you haven't used before,
> without having to copy the certificates into the certificate store, even
> if you don't have a roaming profile. [If you have a roaming profile, then
> the certificates are copied from your profile anyway...]
>
> Cheers,
> Jan.
>
- Next message: Anthony Hunter: "Updating security on a folder."
- Previous message: Byron: "Re: PKCS7 renewal request"
- In reply to: Jan Spooren: "Re: Alternative store vs. MY store"
- Next in thread: Sylvain: "Re: Alternative store vs. MY store"
- Reply: Sylvain: "Re: Alternative store vs. MY store"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
