Safe online transactions (Part
2)
Certificate authorities
In practice, this problem is solved by
one more level of indirection: the CA or certificate authority. A CA issues
digital certificates that identify a particular person or entity and the public
key used by that person or entity. In essence, a digital certificate is the
name (usually a domain name) and the associated public key encrypted by the
CA’s private key. You can check the validity of a certificate by decrypting it
with the CA’s public key.
But hold on, you may be asking, how do
Alice and Bob know the CA’s public key? Can’t Mallory just intercept this and
replace with his own public key? Technically yes, but in practice the CA’s
public key is provided as a certificate with the browser or as part of the
operating system. CA certificates are truly publicly published. You trust that
these certificates are valid because they’re delivered to you with your
operating system or browser.
Once Alice and Bob buy their digital
certificates from a particular CA, they can send them to each other with
impunity in essence by trusting the CA. Alice can check Bob’s certificate (and
discover his public key) by decrypting it with the CA’s certificate, and vice
versa. Once that’s done, they can send each other secure messages ad infinitum.
Online banking
Now imagine that Alice is you, 13th is
your bank, and you want to take a look at your accounts online and pay some
bills. You certainly don’t want Eve to see your account details, and definitely
don’t want Mallory to be fiddling with your transactions as you send then to
your bank. Before RSA and public key systems, this would have been nigh on
impossible: you would have had to securely agree on a large key with your bank.
In fact, the bank would have had to agree on(and store) a random-looking key
for all of its customers and keep them safe from prying eyes. The bank would
have a nigh-on impossible task keeping the world’s Eves and Mallorys from
joining as employees and accessing all those private keys.
But with public key cryptosystems,
this all becomes feasible. It is the basis of SSL (Secure Socket Layer) and TLS
(Transport Layer Security). The latter is the newer version of the former, but
everyone still uses the term SSL - although it does look a little different.
The first problem is that we normal people don’t (usually) have a
private/public key pair and a digital certificate that proves who we are (for a
start, certificates are very expensive), so we have to approach things
differently.
SSL explained
When you visit a hank’s website, the
bank’s server will automatically redirect von to its secure site using the
HTTPS protocol before you can log in. This results in your browser and the
hank’s site negotiating a secure channel using SSL. This negotiation goes a
little like this (note that I’ve simplified it greatly).
The browser sends a message stating
what the latest version of SSL it can support and a list of symmetric
algorithms it can use.
The web server sends back a message
with the version of SSL and the algorithm that will he used. It sends its certificate
as well.
The client verifies the certificate
using the known certificates that came with tile browser; in other words, it
checks that it has been signed by a trusted CA and that it hasn’t expired.
If the certificate is valid, the
browser generates a one-time key for the session, encrypts it with the servers
public key (it’s part of the certificate), and sends it to the server.
The server decrypts tile key then uses
that key together with the agreed symmetric algorithm for the rest of the
session.
Let’s take stock. Your browser is
certain that tile server is who it says it is (your browser is trying to access
YourBank.com, and the certificate says it’s valid for YourBank.com - anti the
CA agrees). The browser has generated a cryptographic key that will be used for
one time only: this particular session. It’ll be thrown away after you log out.
The key was Sent encrypted with YourBank.com’s public key, which only
YourBaiik.com can decrypt with its private ke3 There are a couple of other
messages sent that check your browser and the web server have agreed on the
same key (if anything went wrong, the session is dropped).
Once YourBank.com has presented you
with a login screen (which will be sent over IITTPS, if the batik knows what
it’s doing) and you’ve filled it in, it’ll know who you are. Your id and
password will have been sent encrypted over the secure channel that you’ve both
established. Eve and Mallory are completely out of the loop.
Spotlight
on... Hacking SSL
Recently, Rizzo and Duong
showed off a hack against SSL used with a block cipher. There are two main ways
to encrypt with a block cipher: encrypt the blocks separately (known as
electronic codebook, or ECB), or XOR the previous encrypted block with the
current block and then encrypt it (known as cipher-block chaining, or CBC). The
latter needs an initialisation vector (IV) - a random, block to XOR with the
first plaintext block. The block cipher SSL uses CBC with an IV.
When communicating with a
server, data passes back and forth as separate packets. Does the IV for the
first block of the next file or packet come from the last encrypted block of
the previous file, or do we start afresh with a new IV? SSL uses the first
option, which can lead to a small security hole. If the attacker is controlling
one side of the channel over which the encrypted data is flowing, he can inject
some specially constructed data into the stream using the previous IV. He
guesses at the contents of the previous block, constructs his attack block with
it, and if the resulting encrypted block Is what he expects, he was correct.
But how does he gain
control of one side? Rizzo and Duong used a Java applet that they injected into
a web page through a cross-site hack. It isn’t easy, but it shows that good
security is hard. SSL was considered good security. Note though that although
this hack has been proven, it doesn’t mean that SSL is broken for most
transactions on the web. Browser manufacturers are already fixing the problem.
DigiNotar
DigiNotar was a certificate
authority in the Netherlands. On July 19 2011, hackers accessed DigiNotar’s
systems. They created around 30 fake certificates for well-known domains,
including google.com, microsoft.com, and mozilla.org.
Consider what they could do
with a certificate for google.com. Well assume they are called Mallory and have
governmental powers so they can monitor all internet traffic. Alice tries to
connect to Gmail, but would in fact be setting up an SSL session with Mallory’s
server (Mallory’s certificate says it is google.com, and this Dutch CA proves
it). Mallory’s server would then set up a session with the real Gmail so he
became the man in the middle. At that point Mallory could read all of Alice’s
emails without her being aware of it.
It’s thought that Mallory
in this case was the Iranian government and that it was trying to gain
information about dissidents. The solution, once the bogus certificates were
discovered, was to renounce DigiNotar as a CA. Its trust was revoked and all
certificates it issued were made invalid.
