Re: Alternative store vs. MY store
From: Sylvain (noSpam_at_mail.net)
Date: 09/20/05
- Next message: Sylvain: "Re: PKCS7 renewal request"
- Previous message: Anthony Hunter: "Updating security on a folder."
- In reply to: WT: "Re: Alternative store vs. MY store"
- Next in thread: Yan-Hong Huang[MSFT]: "RE: Alternative store vs. MY store"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 20 Sep 2005 00:30:36 +0200
WT wrote on 19/09/2005 21:13:
>
> I don't want the private key to leave my alternative physical store
of course, that's not a concern, nobody will copies the key (but the
holder ... if it appears as a basic file, it's another topic but you
will have to secure it anyway - may be by Password Based Cryptography,
e.g. dynamic encipherment of the key file by the holder password ... or
fingerprint if Microsoft wants to provide us an API).
> 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.
in order to have a configured USB device, you have manually acheive
these points - later a full CSP will allow direct enrollment (key
generation & certificate storage) on the device.
> 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.
"when required" is incorrect; your codes (CSP, even tailored USB driver)
are not aware of requests made by applications to the cert-store! you
must so start to copy your certs to the store, associate them with your
CSP (normal way, but which alternative exists ?) and then wait for an
indirect call to your CSP when one of your cert is involved in an operation.
this bring a first issue: smartcard insertion generates system event
that a daemon (previously called "synchronizer") may listen and use to
update the store; in your case you will have to build a daemon that
detects usb removable media insertion to handle the copy, it should be
possible, I don't know exactly how.
> 3. perform some authentication such that only the apps on my "allowed" list
> to access the cert and its associated private key.
your keys are accessed by your CSP only, so restriction (such as holder
authentication) will be performed by your code indeed; current MS CSP
uses to bring a "input PIN" dialog, you can of course provide your own
UI that suits your needs and policy.
> 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.
no way, indeed.
> 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.
that's incorrect. the MY store is a global repository for all user
certs, whatever the CSP that actually manages the private key associated
with the certs.
so MS CSP publishes into MY store and handles its keys, as your CSP will
publish into MY store and have to handle its keys.
what is true is that you can rely on a pass-thru CSP to let MS CSP
manage the operations that do not involved your keys (such as locking
the desktop).
> 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?
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
> 2. CryptCreateHash
> 3. CryptSetHashParam
> 4. CryptSignHash
> 5. CryptSignHash
> 6. CryptDestroyHash
>
> Is this all that needs to be modified?
according my understanding, yes.
according my experience .. don't know! I did try to (also) implement a
CSP based on a generic USB device (not a smartcard) and was blocked by
other problems related to device insertion (to bring up "open session"
dialog) and device withdrawal (to lock the desktop - instead of havind a
"unsafe removal" alert).
a simplest alternative will, may be, to use the new security interface,
but information comes quite slowly from Microsoft.
> 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?
Good question !
Sylvain.
- Next message: Sylvain: "Re: PKCS7 renewal request"
- Previous message: Anthony Hunter: "Updating security on a folder."
- In reply to: WT: "Re: Alternative store vs. MY store"
- Next in thread: Yan-Hong Huang[MSFT]: "RE: Alternative store vs. MY store"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
