[Mono-list] Https (Webservice) authentication using PKCS#11 tokens

Sebastien Pouliot sebastien.pouliot at gmail.com
Fri Feb 19 09:24:02 EST 2010


On Fri, 2010-02-19 at 15:00 +0100, Mathias Tausig wrote:
> Am 19.02.2010 14:17, schrieb Sebastien Pouliot:
> > [...]
> > 
> >> but I am
> >> facing a slight problem.
> >> In Mono's implementation of X509Certificate2, when the key is accessed
> >> via the PrivateKey property, the ExportParameter method of
> >> AssymetricAlgorithm ist invoked (see
> >> http://anonsvn.mono-project.com/viewvc/tags/mono-2-6-1/mcs/class/System/System.Security.Cryptography.X509Certificates/X509Certificate2.cs
> >> , line 213). When I implemented my Pkcs11RsaKey class, derived from RSA,
> >> I chose to throw a CryptographicException whenever ExportParamters(true)
> >> is called (since there is no possibility to actually read the private
> >> parameters off a token). But if I do so, X509Certificate2.PrivateKey
> >> returns null and the whole https - login process fails.
> >>
> >> Since you wrote the whole Cryptographic namespace, maybe you could shed
> >> some light, why this call to ExportParameters is neccesary.
> >> Do you see any workaround for this, apart from simply returning the
> >> public parameters from ExportParameters(true), as I have done now, to
> >> make it work as a proof of concept?
> > 
> > It's a FX design flaw. The cryptographic hierarchy is sound (mostly) but
> > some types (like RSACryptoServiceProvider) are short-circuiting the
> > logic (which is a CryptoAPI limitation - or at least a mismatch with the
> > FX design).
> > 
> > IOW it means that RSACryptoServiceProvider (with its limitations) is
> > unusable to some tasks (like SSL/TLS) unless you export the private key
> > and re-load it into a (more compliant) RSAManaged instance. Sadly that
> > does not play well with other, custom RSA instance.
> 
> OK, thanks for the explanation
> 
> > 
> > The fix is not overly complicated (i.e. detect if the instance is not a
> > RSACryptoServiceProvider and use it without the current hack) unless
> > your RSA implementation cannot provide [Decrypt|Encrypt]Value methods.
> 
> I think we have a small misunderstanding. My actual problem is within
> X509Certifiacte2, and I cannot change anything there (apart from
> patching and recompiling the whole framework, which would be a bit of an
> overkill). And since X509Certificate2.PrivateKey is not even virtual,
> overloading won't help me either.

There's no misunderstanding. X509Certificate2 needs to be fixed to work
in your use case (custom RSA). I can't think of any workaround (short of
re-compiling the assembly with the fix).

> ExportParameters(true) is called and I have the choice of either
> returning a bogus value, what might lead to problems in other areas, or
> throwing an exception, which results in the X509Certificate2 instance
> not beeing able to access its PrivateKey.
> And I still don't quite understand this call to ExportParameters(true).
> You are doing after you have already checked for the type and know, that
> it's neither a RSACryptoServiceProvider nor a RSAManaged.

That was too long ago ;-) but it looks like I wanted to get the
exception if no private key was present in a custom RSA|DSA
implementation (which is likely the right behavior - but I need to check
the tests to be sure). IIRC that's because the PublicOnly property is
not (or was not) defined in the AsymmetricAlgorithm type.

However your case is a bit different in that the private key is
available but not exportable. Again that's not something that is easy to
know in X509Certificate2 (maybe fx 3.5+, or the 2.0 service packs, made
this easier).

> 
> > This happens on some smartcards (I recall some of the G&D Starcos 2.3
> > about 10 years ago ;-) which insist on doing all padding operations
> > inside the card. Those cards (unless they have a PKCS11 mode or support
> > the special SSL padding*) are unusable for this purpose.
> 
> No, EncryptValue and DecryptValue work just fine (at least with the card
> I tried so far). But good to know, that there might be other troubles on
> the horizon.

Great!

Sebastien



More information about the Mono-list mailing list