CODEWITHSUNDEEP
c#asp.netsslcryptographysmartcard
Stellar Sword
Stellar Sword

Reputation: 6226

SmartCard security, how do you authenticate the certificate as not fake?

I'm trying to develop an ASP.net site that reads the clientCertificate to ensure a smart card was used to access the website (trying to do away with username/password login).

The process I have in my mind is:

  1. User registers an account and C# records user's clientCertificate (public).
  2. The user can then log in the next time with that same clientCertificate, and they are now an authenticated user if hash valid.
  3. I will use the code below to ensure authenticity of certificate. The browser should deal with private keys and ensure the certificate was NOT faked.
  4. Based on Subject+certificate combination, C# assigns them their role-access.

The following code can be used for authenticity of certificate right?

X509Certificate x509Cert = new X509Certificate(Request.ClientCertificate.Certificate);
SHA1 sha = new SHA1CryptoServiceProvider();
byte[] hashvalue = sha.ComputeHash(Request.ClientCertificate.Certificate);
byte[] x509Hash = x509Cert.GetCertHash();
// compare x509Hash WITH hashvalue to ensure they are a match. 
// If not, possibly faked certificate, not a real smartcard???

Is this how SmartCard authentication process should work???

Upvotes: 3

Views: 4846

Answers (3)

Bruno
Bruno

Reputation: 122649

Client-certificate authentication is done during the SSL/TLS handshake.

It is usually done using a Public Key Infrastructure, whereby the server has a (fixed) list of trusted CA certificates which it uses to verify the client certificate (in the same way as clients to it for the server). Once the certificate is presented to your application after this stage, you will know that:

  • the client has the private key for that certificate (guaranteed by the Certificate Verify message in the TLS handhsake (the SSL/TLS stack will verify this for you, no need to implement anything);
  • the client has the identity described in the certificate, because you will have verified it against your trusted CA.

The verification against a trusted CA requires the user to be registered with that CA in advance. You can't just authenticate any certificate if it hasn't been issued by a CA you trust. (Mapping the certificate's subject to a local user ID is another matter: you could do this upon first connection if needed: have your own database or directory service to map the Subject DN to another kind of user ID in your application, for example.)

User registers an account and C# records user's clientCertificate (public). The user can then log in the next time with that same clientCertificate, and they are now an authenticated user if hash valid.

It sounds like you want to allow any certificate to be presented and use it for the initial registration, without necessarily resorting to a commonly trusted CA.

This is possible in principle, and I've done this to explore alternatives to PKI in Java.

To do this, you need to let any certificate through as far as the SSL/TLS handshake is concerned, and verify the certificate itself later. (You do need to use some form of verification.) You are still guaranteed with this that the client has the private key for the public key certificate it has presented.

Doing this requires two steps:

  • You need to be able to advertise the fact that you're going to accept any certificate, by sending an empty list of certification authorities in the Certificate Request TLS message (explicitly allowed by TLS 1.1).
  • Configure the SSL/TLS stack to trust any certificate (once again, when you do this, do not forget to implement your own verification system within your application, otherwise anything will really get through).

In .Net, while it should be possible to address the second point using a remote certificate validation callback, I have never found a way to alter the first point (this was also asked in this question).

In Java, the JSSE's X509TrustManager allows you to address both points.

Upvotes: 1

Ulises
Ulises

Reputation: 13419

If you just need to authenticate users with client certificates you should do this in IIS. You do not need to add any code at all to your application:

Specify Whether to Use Client Certificates (IIS 7)

Unless you need to link client certificates with database accounts or perform an additional validation step. But still for client certificate authentication I would stick with IIS settings.

Update: In case you need to manipulate the client certificate you can do:

X509Certificate2 x509Cert2 = new X509Certificate2(Page.Request.ClientCertificate.Certificate);

And then access its properties such as:

x509Cert2.Subject

However, leave the validation piece up to IIS. If the client presents a bad certificate your asp.net code will not even execute since IIS will reject it

Upvotes: 2

mikey
mikey

Reputation: 5160

See this thread, sir. You do not need to verify authenticity explicitly in your code. IIS will do it for you.

Does IIS do the SSL certificate check or do I have to verify it?

IIS even tries to check revocation lists (however, this is often disabled if the CRL is large). An OCSP responder should be used to validate in cases where the CRL is very large or latency in checking it is high http://www.axway.com/products-solutions/email-identity-security/identity-security/va-suite.

Upvotes: 2

Related Questions