This project defines how clients can use standard hardware tokens with a PKCS #11 interface when using Secure Remote Passwords. The basis is a hack on top of PKCS #11 that was designed to never allow the private key to be taken off the token. The server-side does not have to change to accomodate this alternate formalism.
SRP #11 is a different formalism from the normal Secure Remote Passwords, but it only modifies the client-side computations. This means that it will work with an ordinary server. As long as the salt,verifier are generated by the SRP #11 code, it will also be able to validate with SRP #11; both are actions on the client side, which is where the PKCS #11 token is expected to be.
The value of using PKCS #11 is that the zero-knowledge proof can be initiated from a hardware-protected private key. Not only are you not leaving any traces on the server, but given a proper PKCS #11 implementation you are not even leaving sufficient credentials to authenticate on your client machine. This means that rogue drivers cannot get hold of your credentials, which would be common with plain passwords or other insecure mechanisms.
The protection of SRP #11 is currently an expectation that we are exposing to the security audience, with a kind request for review. As far as we can tell, and have documented in our design document, the extraction of the private key from PKCS #11 is not supported in any way, and so the PKCS #11 token would always be needed to be able to authenticate to a remote server. Since a server generates new random material on every authentication attempt, new authentications then cannot be completed after the token has been removed from the client machine.
The SRP mechanism is based on Modular-Exponentiation Diffie-Hellman, and so is SRP #11. There is some discussion about an Elliptic-Curve replacement, just as has been construed for other Diffie-Hellman aspects of our life.
We believe that the modifications made here represent a new angle on the question which follow-up mechanism founded on Elliptic-Curve Cryptography is the best suited. We would argue that alternatives that can achieve similar benefits over plain PKCS #11 are more interesting than ones that cannot.
This software is based on csrp by Tom Cocagne. It is also released under an MIT-styled open source license. I am grateful to Tom for having built such a suitable starting point for this work, and for sharing it with the public through a permissive license.
The work has been tested against the clean software implementation of PKCS #11 in the SoftHSMv2 part of the OpenDNSSEC project. If you test it against other implementations, including various USB tokens, then I would be happy to add your findings on those tokens here.