The EdelKey project started in 2003 to study some possibilities and feasability to implement a remote key storage to remove the need to store cryptographic key on a local machine, and as a side effect allow mobility of users. one could call this "remote virtual smart card".
The intended solution is to provide a PKCS#11 module that accesses via a secure protocol to a remote server via a secure remote procedure call of the PKCS#11 functions. As a means to secure the protocol, SRP-6 with TLS was selected which became RFC 5054 in November 2007.
Some pieces of the puzzle are available. So far, no documentation is available. Some reports and presentations had been given on conferences meanwhile.
A initial patch for OpenSSL version 0.9.7d, implementing a draft version of the TLS/SRP protocol (not the final version of the RFC).
Features in first beta (2004-08-30):
the new options for the a_client, s_server commands,
the new srp command to create users, and
the new srp subdirectory of the cryto library.
A new ciphersuite group 'SRP'.
Several callbacks and functions for the SSL and SSL_CTX to allow an application (client and server) to provide and access to necessary data.
The modification also allows to use the TLS servername extension.
Changes in beta 2 (2004-09-07):
ON some platforms the 'srp' tool crashed after rewriting the database because of un-initialized variables.
Some definitions had been reorganized.
Changes in beta 3 (2004-09-25):
The SRP verifier base initialisation code has been rewritten, memory leaks removed.
C++ comments have been removed.
Various cleanup for things like unncessary stack declarations?
The SRP cipher suites have beed add at the beginning of the DEFAULT list. This doesn't create any harm because they are only selected if the necessary parameters are provided by the application, i.e. a username/password for the client, and a verifier interface for the server.
The cipher description function reports kSRP now.
The 'srp' utility still suffers from some debugging output and error messages.
Changes in beta 4 (2004-10-01):
Padding of values in u an k was not done correctly according SRP-6a
More memory cleaning for potentially sensitive values.
Removal of unecessary code (from older draft specs)
more C++ comments have been removed.
The srp tool tried to free data on the stack.
Minor changes to s_server/s_client
Code from the stable version has been included from s3_pkt.c
And lots of small cosmetics here and there.
Started to add code to ssltest.c
Adding a new routine to set a password without callback
Engine support, e.g., for the modulo exponentiation.
A patch enabling curl and libcurl to use the openssl srp patch mentioned above
Features in first beta (2004-09-25):
A new parameter --srp allows SRP authentication together with HTTPS. The username and password are given using the -u directive.
You may want to use a cipher suite of "SRP:!aRSA:!aDSA" (directive --cipher) in order to disable the ciphersuites that may return a server certificate, or to use the -k (unsecure) option to ignore certificates. Note, that the word "unsecure" is slightly misleading now, it only means "No certificate checking".
If SRP authentication is selected by the server, ssluse.c now accepts that no server certicate is returned.
The libcurl interface has an new type CURLAUTH_SRP for the CURLOPT_HTTPAUTH option.
Changes in beta 2 (2004-10-01):
Detection of non-available of the SRP enabled version changed.
CURLAUTH_SRP removed and replace by two new option CURLOPT_SRP_USERNAME and CURL_OPT_PASSWORD option.
SRP for the curl utility is now enabled by two parameters --srpuser and --srppass
Support for SRP had been implemented meanwhile first for GNU-TLS, and then for the development version of OpenSSL.
Errors, wishlist and roadmap
The 0.9.7 implementation has some errors:
The server does not return an empty servername extension.
The servername is not saved in the session cache. Discovered while looking at Nokia's PSK patch.
The apache patch used an internal data structure of the vhost module. (We didn't see the right API).
The 0.9.7 patches will not be further developped. The errors mentioned above are corrected for 0.9.8
The following parts were mostly done during summer 2005. Since 2006 some code gets included into the openssl main code.
The TLS servername extension code has been separated from the SRP, i.e.,
a separate patch only for the servername extension. Since january 2006, the openssl 0.9.9 development snapshots contain the servername support. Thanks to Bodo Möller for assistance, proof-reading and corrections.
The extension handling code have been largely simplified and concentrated.
The mod_ssl patch is also split into two pieces and adapted to Apache 2.2.0.
Contrary to what was indicated earlier, the encoding of the servername in the 0.9.7d version was ok and wrong for the 0.9.9 snapshots. A patch has been submitted. Furthermore, the parsing allows multiple server names. All but the first hostname are ignored.
The server name Apache 2.2.0 patch supports the servername extension and also allows to re-negotiate, if the virtual host has another SSL_CTX. This patch has been updated March 26, 2006. Thanks to Kaspar Brand.
The extension handling in OpenSSL is suffering from a big problem that was introduced when the second extension was added, the loop logic, the parsed values storage, and the following action is all in the wron order and used global storage.
The OpenSSL core team is unable to see this.
The SRP is simplified to a certain degree:
At least, the SRP code will no longer add source modules to the ssl library, but just modify existing ones.
The SRP interface in the ssl library has been largely simplified.
The SRP implementation uses the mult_exp routine from an RSA object; this allows to use a exponention function from an engine. This feature has been tested using a modified Bull PKCS#11 engine together with Mozilla's soft token.
And the documentation ...??
On the road again
In 2008, Tom Wu to over the work and made available a port of the patch for the openssl 0.9.9 development version. Tom's team made three remarks concering the code:
The "srp_lateuser" option computes the digest wrong on the server
side in 0.9.9, causing a handshake failure when verifying the Finished
MAC. This results from the "ssl3_digest_cached_records" call in
ssl3_get_client_hello (s3_srvr.c:1222). The SSL server resets the
digests when it receives the second ClientHello, whereas the 0.9.9 SSL
client and both sides in 0.9.8 and 0.9.7 do not.
0.9.9's DEFAULT ciphersuite does not include the "no certificate"
version of the SRP ciphersuites, only the RSA and DSS versions. That's
because it's DEFAULT ciphersuite string contains "!aNULL", and the
no-cert SRP ciphersuites have no authentication bit set. In 0.9.7 this
wasn't a problem because they used "!ADH".
A bug in SRP_user_pwd_set_sv_BN():
vinfo->v = v;
vinfo->v = s;
vinfo->v = v;
vinfo->s = s;
You might follow the work in OpenSSL ticket 1794.
The first patch needed a little bit of polishing in order to maintain ABI compatibility and there is also the point the EVP routines may return errors. Dne.
Since March 2011, the code has been integrated into the development branch. On March 14 2012, openssl 1.0.1 includes support for for SRP. time to do some documentation.
curl now supports srp together with GNU/TLS and OpenSSL.
Are there issues with patents? I don't think so.
What about client authentication in email clients for POP, IMAP or SMTP?
Without the students working at EdelWeb, nothing would exist today.
Driss Aboulfadl (Summer 2005), enhanced the PKCS11 tracing tool, and implemented an S/MIME signature through PKCS11 V2.20
Rémy Allais(Summer 2005), who restructured the openssl and apache patches, ported some of the openssl extensions to 0.9.8 and to apache 2.1.8,
and implemented a initial servername extension in Mozilla.
Christoph Renou (Summer 2004), who has implemented the alpha version of the openssl and mod_ssl patches and completed a PKCS 11 library.
Christiane Zaarour (Winter 2003/4) who has enhanced a PKCS 11 library tracing tool.
Vincent Leraitre (Summer 2003), who has designed and implemented an alpha version of a PKCS 11 library and a tracing tool.
Tom Wu was always available respond to our questions and to provide useful hints, and his interop tests with other implementations.