Update: this post has been updated based on suggestions by SRP designer, Tom Wu!
SRP is surprisingly unknown for what it offers, so I decided to do a writeup here to help spread the word on what SRP is and isn't, how to implement and what the caveats are.
SRP was designed by Tom Wu while he was at Stanford University. Details can be found from the page linked above, and the Wikipedia page is also informative.
This writeup assumes familiarity with hashes and Diffie-Hellman, but not a lot else.
What is the problem that SRP solves?To do anything important on the public Internet, we need secure communication channels. Stricter definitions are available, but the core of this is that we have secrecy (other people on the Internet can't listen in) and that we know who we are talking to (other people can't impersonate the endpoint we think we are talking to).
Often we use SSL, in the form of https, to deliver both. The SSL protocol negotiates a session with privacy, and through the use of X509 certificates, makes sure that we are talking to someone with a certificate that matches who we think we are talking to (what this means in the year 2012 is anybody's guess, though).
In addition, once we have setup this secure channel, most of the time we will then log in to a remote system (think gmail, for example). We do so by providing a username and a password.
And here's the interesting thing. The server has provided proof of its identity to us in a way that doesn't allow us to subsequently impersonate that server. However, as users, we are then asked to give that same server our full username and password! If we share passwords, this mean the operator of the server can now try to log in elsewhere with our credentials.
Zero knowledge proof of identity with key establishmentSRP rolls up most of the things above. As a user, we can prove to the other side that we are who we say we are (or at least, that we know the password we enrolled earlier). We never have to send the remote our password, not even when we are enrolling. Simultaneously, we get proof that the other side is one that we enrolled with in the past. Finally, we also get a secure session key to encrypt our communications.
And all this without certificates!
Compare this to SSH, where we first setup a secure connection, and then send our full password over that same session. Or CRAM-MD5, which allows us to prove who we are without sending over our password, but which does demand that the server have a plaintext copy of our credentials.
All pretty impressive.
Practical detailsWith our username, the server stores a 'verifier' of our credentials, plus the salt used to generate this verifier. As is usual, we deal with hashes of the password, and not the password itself. The verifier however is even further away from the password, and consists of the result of a one-way cryptographic operation on the hash.
Password + Salt -> Hash -> Verifier
We never need to tell the server our password if we don't want to, we can just send them a random salt and the verifier (which we can calculate) when we enroll. Quite often though, we'll provide the password just once, though, and have the server calculate the salt thence hash & verifier.
When we want to setup a secure authenticated session, we connect to the server and tell it our username. In return, it reminds us of the salt used in generating the hash.
The user now enters the password on his own computer, which subsequently calculates the hash based on the salt. This hash constitutes our secret key. The verifier stored on the other side performs the role of a public key.
Next, a modified Diffie-Hellman key exchange is performed, based on the public and private keys derived from our password. If the server verifier is indeed related to our client hash, both parties will end up with a shared secret which, once hashed, forms our session key.
A final message exchange based on the shared session key is then performed, and if the session key is in fact identical on client and server, this will prove that the verifier and user password match.
And we are logged in, and have an authenticated secure shared key!
DownsidesThere are a few downsides to the above. For one, we have to send out our username in plaintext at the very beginning of the session. An eavesdropper can derive from this who we are claiming to be.
Secondly, while the server is 100% assured we know the password associated with the username, we are in turn not 100% sure if we are connected to the right server. We only know we are connected to someone who has access to our username and password (knowing only the verifier is not enough).
The last bit basically means that if someone knows our username and password, he'd be able to impersonate the server you connect to, and transparently send everything on. But then again, if he knows your username and password, he could just log in as well.
If an attacker only knows the verifier, he can wait for a user to connect, and pretend to be the intended server. However, the attacker can't setup a transparent connection to the authentic server, so you'd have an authenticated connection to a server that does not have the contents of the original server.
Patent situationUpdate: this section has been updated after further research. The previously mentioned patent is predated by the publication of SRP by a wide margin, so it does not apply.
Various sources mention that there might be a patent issue with SRP, but there is nothing concrete to point to. There is a Stanford patent, but it has been licensed in such a way that it does not hinder SRP usage in any way. It might in fact protect it.
When the SRP RFC was initially written, two firms made IPR disclosures, but these have not been followed up on. When RFC 5054 was published, which also describes SRP, there were no further IPR disclosures.
SRP has by now seen quite some use, if there were any applicable patents out there that were still valid, we would probably have heard from them already. If anyone knows of specific patents that apply, please let me know. It would be good to put this to rest.
The balanceSRP is pretty cool, and delivers quite a lot of 'bang for the buck'. It is way better than many other solutions, which either require plaintext passwords on the server, or require us to hand over our password to the server every time we log in.
In particular, it appears SRP should have been used in WPA2 instead of what was used.
However, SRP falls short of having 'real' authentication. If an attacker knows the password, he can effectively pretend to be the remote server. And even though an attacker with the correct password was pretty powerful already, this is a downside.
The usecase for SRP is therefore for people who'd like to have better security than just passing around passwords, but don't want to go through the hassle of doing certificate administration.
A good article, but I must correct one piece of information. US patent 7076656 cannot cover SRP because it is dated eight years after SRP was invented. The correct patent number for SRP is 6539479 and has been made freely available worldwide by Stanford.ReplyDelete
Had a question on how to use SRP libraries that you authored some time ago..
The downsides you mention in the balance can be covered by using SRP over TLS/HTTPS. Frequently people state that SRP is an alternative to TLS and certs. I feel this hinders the adoption of SRP as people can think "we must use TLS for our insurance policy and credit card payment agreements so SRP is not for us". Yet heartbleed, or side attacks, or leaking passwords in error messages, or into logs, or encryption only to a DMZ only not all they way to the db server, and outsourced infrastructure management, and so many other reasons point out that TLS/HTTPS is not enough. Its the bare minimum with risks which SRP can protect against. Likewise SRP has risks of false servers which are nicely covered by TLS. SRP should be the default always and whether you deploy TLS/HTTPS is a routine decision where the answer is yes for any site which can afford to pay to maintain one. If you would be so kind as to edit the article not to say that SRP is for when you cannot be bothered to use certs you would help to stop the false impression that people should choose one over the other rather than using both by default.ReplyDelete