Java Applet for mutual authentication with smart card

Question

I need to develop a java applet, for a mutual authentication between Tomcat 6 (server) and a SmartCard "IDGo 300" (client).

In order to do this I thought the following scheme:

1. Tomcat (server) send to SmartCard (client) the request of his digital certificate (signed by CA).

2. Client enters PIN and selects an available certificate on the smart card, then the Applet sends his certificate (signed by CA) to tomcat. tomcat verifies the digital certificate and if correct sends back his certificate.

3. The applet verifies the certificate of the server, and if the certificate is correct sends a confirm to server. The server gives full access to the client to use the web application.

Questions:

1. Is this scheme feasible?

2. I would like to manage everything through my applet and when the client disconnects the smart card he loses access to the server.

Answer 1

Yes. This is feasible. There is a standard way to achieve this: you use SSL with a client certificate. This feature of SSL already does exactly what you want, and it has been well-vetted, so I recommend you use it.

In this scheme, the client certificate and associated client private key is stored on the smartcard. The private key never leaves the smartcard. To prove the client's identity, the server sends a challenge and the smartcard signs it (and other stuff) with the client private key -- this is all built into SSL, so you don't need to implmeent it yourself, I'm just giving you some intuition for how the protocol works.

No Java applet is needed. All you need is for your browser to support PKCS#11. For instance, Firefox supports this.

If for some reason you do want to use a Java applet, you again want to check out PKCS#11, the Java Crypto APIs, and the Sun PKCS#11 cryptographic provider. See also this question.

Answer 2

IMHO first of all communications has to be over ssl between applet and server.

Secondly your protocol should have replay protection (just in case because ssl with it's DH negotiation provides it to some extent).

As to protocol itself after users certificate is retrieved by applet it should send encrypted and authenticated (by applet) verification request it may include things like session id, additional user credentials etc. ). This request should be encrypted with servers public key and authenticated with applets private key, (we will get double verification that the server is the only intended recipient and that applet is authenticated sender), after SERVER SIDE ONLY!!!! verification server should send response to applet again encrypted with applets public key and signed with servers private key, for the reasons mentioned before). It should be only informative and server should handle authentication decisions we should only provide a trusted path between smart card and server.

As to point 2 you can send information via our new protocol to server that the card was disconnected and user's authenticated session should be invalidated.

P.S. As to mutual authentication applet <-> server we can use some DH time renegotiation if you are concerned about private key extraction.