SIP Sessions

SIP and Security: New Developments

One of the abilities that SIP has had since its very earliest days is the ability to use X.509 certificates to sign and encrypt messages being sent across the network. If you haven’t heard of X.509 before, don’t worry – you’re hardly alone.

X.509 itself is based on a really elegant class of algorithms called “Public Key Cryptography.” At a high level, here’s how public key cryptography works: there are mathematical functions you can apply to a large random number to generate two linked cryptographic keys. These keys have the very interesting property that something that has been encrypted by one key can be decrypted by the other, and vice versa.  In Public Key Encryption, you generally designate one of these keys “public,” and make it available to anyone who wants it. You designate the other key “private,” and keep it secret.

Once you’ve done this, there are a couple of very interesting things you can do with these keys: first, other people can use your public key to encrypt messages they want to send to you. But the only way to decrypt them is using your private key, which guarantees that no one else can read the messages (not even the person who encrypted them!). This is shown in Figure 1.

The other thing you can do is sign messages with your private key (proving that you generated the message), and anyone with your public key can verify that the message hasn’t changed since you created it. This is shown in Figure 2.

So, that’s all very nice from a security perspective – so why haven’t we seen more of this? Well, it turns out that the hard part of this isn’t the cryptography (in fact, every modern email client has the ability to do this); the hard part is getting your public keys to everyone. There have been a number of designs for public key infrastructures (PKIs) that are supposed to address this problem, but they haven’t been deployed for a number of reasons.

There’s one notable exception, though: web sites. Because e-commerce depends so heavily on the ability for customers to verify that a web site is who it claims to be (through the signing operation), and to send information like credit card numbers in a encrypted form (using the encryption operation), web sites pretty much have this all figured out.

That gives us just enough of a PKI to pull SIP up by the web’s bootstraps, and that’s exactly what RFC 4474 does. At a high level here’s how that works. Let’s say Alice wants to call Bob, and Bob wants to make sure it’s actually Alice calling before he answers the phone. So, Alice sends a SIP INVITE message to her proxy. The proxy makes sure that the caller is actually Alice, usually by asking Alice’s SIP device to prove it has a password of some kind. Alice’s proxy then adds a signature to the SIP INVITE, which says that the proxy has verified that the caller is, in fact, Alice. It also includes the address of its web server in this INVITE message.

So, when Bob gets the INVITE, he can use this web server address to ask Alice’s Proxy’s web server for the public key for Alice’s proxy. He knows he can trust the web server, because we already have a working PKI for web servers. So, Bob can then use the public key he got back from the trusted web server to verify that the proxy is who they claim to be, and that they’re in a position to vouch for Alice’s identity. The overall information flow for this set of operations is demonstrated by Figure 3.

And that, by itself, gets us a lot of the way to where we need to be. Bob now has cryptographic proof that the person calling him is, in fact Alice.

But this still doesn’t get us all the way to a fully-functioning X.509 service. For example, it doesn’t let Alice sign messages herself, and it doesn’t let her encrypt the actual SIP messages she sends to Bob. Sure, she can send them over TLS, but that only makes things encrypted between proxies – each proxy is still decrypting and re-encrypting the message at every hop. And those proxies can read any part of the message they want.

We’re just finishing up work in the IETF that’s about to change that. The document is called “Certificate Management Service for the Session Initiation Protocol” (or “SIP Certs” for short), and it uses RFC 4474 to do something even more clever.

What’s really neat about RFC 4474 is that it can be used for any kind of SIP request, not just INVITE requests. The SIP Certs work leverages this even further by counting on the ability of RFC 4474 to certify the identity of the entity sending NOTIFY requests. Here’s how we take advantage of that.

Let’s imagine that Alice wants to encrypt something to Bob using his own X.509 certificate. With the SIP Certs framework, Bob will use the SIP PUBLISH method to send his pubic key to what is called a Certificate Server. The certificate server makes sure the person sending the certificate is actually Bob, and then stores the public key so that anyone who comes along asking for it can get a copy. Later on, when Alice wants to encrypt something that only Bob can read, she asks Bob’s certificate server for Bob’s public key, and uses this to encrypt her message. This flow is shown in Figure 4.

 Figure 4: SIP Certficate-based Encryption and Decryption

Now, the step of asking Bob’s certificate server for Bob’s public key is actually a bit tricky, because Alice wants to make sure that Bob’s certificate server is actually Bob’s certificate server. And that’s where RFC 4474 comes back into the picture: just like the INVITE in the example above, the NOTIFY that contains Bob’s public key contains a signature from Bob’s certificate server, and a pointer to a web site that Alice can go to get a certificate to verify that signature. Which is all a very clever way to get back to leveraging the web Public Key Infrastructure to get a usable public key all the way out to Alice in a way that she knows she can trust that the key is actually Bob’s public key.

What’s really cool about this mechanism is that it can be used to sign things as well, as shown by the information flow in Figure 5. Alice simply publishes her own public key to her Certificate server, and then uses her private key to sign a message. Bob can verify Alice's signature by grabbing her public key from her Certificate server, and using it to validate the message he received.