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

[Sebastien Pouliot]

On Fri, 2010-02-19 at 10:30 +0100, Mathias Tausig wrote:
> Hy Sebastien (and everybody else)!
> 
> Am 16.02.2010 15:37, schrieb Sebastien Pouliot:
> > On Tue, 2010-02-16 at 15:17 +0100, Mathias Tausig wrote:
> >> [...].
> > 
> >> The best concept that I could
> >> make up so far, was to write a PKCS#11 wrapper and then subclass RSA.
> > 
> > Yep, that's the right thing to do.
> > 
> > Sebastien
> > 
> 
> I have done that now (and no, I have not written a PKCS#11 wrapper in
> the course of 2 days, I had already started the work before), 

hahaha, I share your pain :-)

> 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.

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.
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.

Sebastien

* that would require a much larger fix to get it working