|
|
|
date: Mon, 14 Jul 2008 07:46:04 -0700,
group: microsoft.public.platformsdk.security
back
RE: CSPs and Certificate Extensions
Hi,
I have encountered in the past similar problems and in order to investigate
them I developed a small .NET utility program that shows the detailed content
of the IE certificate store. You can download it from here :
http://www.idrix.fr/Root/Samples/StoreExplorer.zip
Here is a screen shot of how it looks like:
http://www.idrix.fr/Root/Samples/StoreExplorer.jpg
The problem you have is certainly coming from the fact that the "MY"
certificate store is populated wrongly by specifying AT_KEYEXCHANGE instead
of AT_SIGNATURE when calling CertSetCertificateContextProperty.
You should look at the source code the application responsible of putting
your CSP certificate into the IE store.
Cheers,
--
Mounir IDRASSI
IDRIX
http://www.idrix.fr
to reach : mounir_idrix_fr (replace the underscores with the at and dot
characters respectively)
"jantes" wrote:
> Is there an easy way (or any way) to view an installed certificate's
> extensions/external properties (eg CSP, container name, key spec)?
>
> The reason I need this is that I have written my own CSP and am using
> Microsoft CA to generate and install a cert linked to my CSP and then
> attempting to sign a Word document with the cert/private key. This fails if,
> when generating the cert, I specify the key for signature only (not key
> exchange). I have been logging the calls to my CSP and I can see that when
> the key pair is generated by the CA, AT_SIGNATURE is specified in the call to
> CPGenKey. But during signing in Word, CPSignHash is passed AT_KEYEXCHANGE -
> and this doesn't exist. I've tried specifying the key for key exchange only
> or for both and the signing process is successful.
>
> I can't work out why, when signing with the certificate, AT_KEYEXCHANGE is
> always passed to my CSP when the cert was created using AT_SIGNATURE. Need to
> see what's going on with the cert installation.
>
> Can anyone help?
date: Mon, 14 Jul 2008 10:25:01 -0700
author: Mounir IDRASSI am
RE: CSPs and Certificate Extensions
Thank-you, that's a very, very useful tool and I can know see that the key
spec associated with the installed certificate in the "MY" store is correctly
set to AT_SIGNATURE. This matches the calls that are made to my CSP that I
can see in my log - CPGenKey with AT_SIGNATURE. As it is the Microsoft CA
that is making these calls, the source code isn't available to me, so I can't
match it up, but it all seems to make sense.
That means the problem is occurring when the certificate is being accessed -
in this case by Microsoft Word. When I try to sign a document using the
certificate it fails, and when I look in my log file I can see that a context
is acquired to the correct container, but after the data has been hashed,
CPSignHash is called with the key spec set to AT_KEYEXCHANGE. Again, I don't
have access to the source code that is actually making the CAPI calls, so I
can't see what's actually happening externally to my CSP.
On the surface it looks like when Word accesses the certificate to sign the
document it doesn't use the key spec associated with it - a bug in Word? Has
anyone else seen this behaviour, or have any suggestions on what could be
causing the problem? Or another test I could try that might resolve this?
Thanks in advance for any help you can give.
"Mounir IDRASSI" wrote:
> Hi,
>
> I have encountered in the past similar problems and in order to investigate
> them I developed a small .NET utility program that shows the detailed content
> of the IE certificate store. You can download it from here :
>
> http://www.idrix.fr/Root/Samples/StoreExplorer.zip
>
> Here is a screen shot of how it looks like:
> http://www.idrix.fr/Root/Samples/StoreExplorer.jpg
>
> The problem you have is certainly coming from the fact that the "MY"
> certificate store is populated wrongly by specifying AT_KEYEXCHANGE instead
> of AT_SIGNATURE when calling CertSetCertificateContextProperty.
> You should look at the source code the application responsible of putting
> your CSP certificate into the IE store.
>
> Cheers,
> --
> Mounir IDRASSI
> IDRIX
> http://www.idrix.fr
>
> to reach : mounir_idrix_fr (replace the underscores with the at and dot
> characters respectively)
>
>
> "jantes" wrote:
>
> > Is there an easy way (or any way) to view an installed certificate's
> > extensions/external properties (eg CSP, container name, key spec)?
> >
> > The reason I need this is that I have written my own CSP and am using
> > Microsoft CA to generate and install a cert linked to my CSP and then
> > attempting to sign a Word document with the cert/private key. This fails if,
> > when generating the cert, I specify the key for signature only (not key
> > exchange). I have been logging the calls to my CSP and I can see that when
> > the key pair is generated by the CA, AT_SIGNATURE is specified in the call to
> > CPGenKey. But during signing in Word, CPSignHash is passed AT_KEYEXCHANGE -
> > and this doesn't exist. I've tried specifying the key for key exchange only
> > or for both and the signing process is successful.
> >
> > I can't work out why, when signing with the certificate, AT_KEYEXCHANGE is
> > always passed to my CSP when the cert was created using AT_SIGNATURE. Need to
> > see what's going on with the cert installation.
> >
> > Can anyone help?
date: Wed, 16 Jul 2008 09:49:01 -0700
author: jantes
RE: CSPs and Certificate Extensions
Hi,
I'm not an expert on Word, but for me, this resembles to a bug in Word.
Unfortunately, such a behavior is not uncommon in Microsoft products (I have
seen it before on other MS components..).
One thing that people tend to do to overcome such limitations is to do the
following :
- When asked about an AT_SIGNATURE key in CPGetUserKey or CPSignHash,
return a handle to it if it exists or an error otherwise.
- When asked about an AT_KEYEXCHANGE key in CPGetUserKey or CPSignHash,
return a handle to it if it exists. If it doesn't exists, look for an
AT_SIGNATURE key on the same container. If this one exists, return a handle
to it. Otherwise, return an error.
As you can see, if you implement this approach inside your CSP, the Word
call to CryptSignHash will succeed because you'll use the AT_SIGNATURE key
internally even if he has specified AT_KEYEXCHANGE.
I know it's an ugly workaround but this is something that exists on
production CSPs on the market and I'm not aware of any other (cleaner)
approach.
Anyway, I hope this will help.
Cheers,
--
Mounir IDRASSI
IDRIX
http://www.idrix.fr
to reach : mounir_idrix_fr (replace the underscores with the at and dot
characters respectively)
"jantes" wrote:
> Thank-you, that's a very, very useful tool and I can know see that the key
> spec associated with the installed certificate in the "MY" store is correctly
> set to AT_SIGNATURE. This matches the calls that are made to my CSP that I
> can see in my log - CPGenKey with AT_SIGNATURE. As it is the Microsoft CA
> that is making these calls, the source code isn't available to me, so I can't
> match it up, but it all seems to make sense.
>
> That means the problem is occurring when the certificate is being accessed -
> in this case by Microsoft Word. When I try to sign a document using the
> certificate it fails, and when I look in my log file I can see that a context
> is acquired to the correct container, but after the data has been hashed,
> CPSignHash is called with the key spec set to AT_KEYEXCHANGE. Again, I don't
> have access to the source code that is actually making the CAPI calls, so I
> can't see what's actually happening externally to my CSP.
>
> On the surface it looks like when Word accesses the certificate to sign the
> document it doesn't use the key spec associated with it - a bug in Word? Has
> anyone else seen this behaviour, or have any suggestions on what could be
> causing the problem? Or another test I could try that might resolve this?
>
> Thanks in advance for any help you can give.
date: Wed, 16 Jul 2008 17:27:13 -0700
author: Mounir IDRASSI am
RE: CSPs and Certificate Extensions
The problem with this workaround for CPGetUserKey is that you don't really
know if the key will be used for signing or for key exchange. You really
shouldn't use the key for key wrapping. I agree with mounir that it's
probably safe to do that for CPSignHash - but would not recommend this for
CPGetUserKey.
Laszlo Elteto
SafeNet, Inc.
"Mounir IDRASSI" wrote:
> Hi,
>
> I'm not an expert on Word, but for me, this resembles to a bug in Word.
> Unfortunately, such a behavior is not uncommon in Microsoft products (I have
> seen it before on other MS components..).
> One thing that people tend to do to overcome such limitations is to do the
> following :
> - When asked about an AT_SIGNATURE key in CPGetUserKey or CPSignHash,
> return a handle to it if it exists or an error otherwise.
> - When asked about an AT_KEYEXCHANGE key in CPGetUserKey or CPSignHash,
> return a handle to it if it exists. If it doesn't exists, look for an
> AT_SIGNATURE key on the same container. If this one exists, return a handle
> to it. Otherwise, return an error.
>
> As you can see, if you implement this approach inside your CSP, the Word
> call to CryptSignHash will succeed because you'll use the AT_SIGNATURE key
> internally even if he has specified AT_KEYEXCHANGE.
> I know it's an ugly workaround but this is something that exists on
> production CSPs on the market and I'm not aware of any other (cleaner)
> approach.
> Anyway, I hope this will help.
>
> Cheers,
> --
> Mounir IDRASSI
> IDRIX
> http://www.idrix.fr
>
> to reach : mounir_idrix_fr (replace the underscores with the at and dot
> characters respectively)
>
>
> "jantes" wrote:
>
> > Thank-you, that's a very, very useful tool and I can know see that the key
> > spec associated with the installed certificate in the "MY" store is correctly
> > set to AT_SIGNATURE. This matches the calls that are made to my CSP that I
> > can see in my log - CPGenKey with AT_SIGNATURE. As it is the Microsoft CA
> > that is making these calls, the source code isn't available to me, so I can't
> > match it up, but it all seems to make sense.
> >
> > That means the problem is occurring when the certificate is being accessed -
> > in this case by Microsoft Word. When I try to sign a document using the
> > certificate it fails, and when I look in my log file I can see that a context
> > is acquired to the correct container, but after the data has been hashed,
> > CPSignHash is called with the key spec set to AT_KEYEXCHANGE. Again, I don't
> > have access to the source code that is actually making the CAPI calls, so I
> > can't see what's actually happening externally to my CSP.
> >
> > On the surface it looks like when Word accesses the certificate to sign the
> > document it doesn't use the key spec associated with it - a bug in Word? Has
> > anyone else seen this behaviour, or have any suggestions on what could be
> > causing the problem? Or another test I could try that might resolve this?
> >
> > Thanks in advance for any help you can give.
date: Mon, 21 Jul 2008 10:20:22 -0700
author: lelteto
|
|
