August 18, 2018

How the Nokia Browser Decrypts SSL Traffic: A "Man in the Client"

Over the past couple of days there has been some press coverage over security researcher Guarang Pandya’s report that the browser on his Nokia phone was sending all of his traffic to Nokia proxy servers, including his HTTPS traffic. The disturbing part of his report was evidence that Nokia is not just proxying, but actually decrypting the HTTPS traffic. Nokia replied with a statement (in the comments section of Pandya’s blog post, and to several news outlets):

We take the privacy and security of our consumers and their data very seriously. The compression that occurs within the Nokia Xpress Browser means that users can get faster web browsing and more value out of their data plans. Importantly, the proxy servers do not store the content of web pages visited by our users or any information they enter into them. When temporary decryption of HTTPS connections is required on our proxy servers, to transform and deliver users’ content, it is done in a secure manner.

Nokia has implemented appropriate organizational and technical measures to prevent access to private information. Claims that we would access complete unencrypted information are inaccurate.

We aim to be completely transparent on privacy practices. As part of our policy of continuous improvement we will review the information provided in the mobile client in case this can be improved.

You can find out more about Nokia’s privacy practices at http://www.nokia.com/privacy.

So, it turns out that Pandya was correct: Nokia is decrypting SSL traffic in their proxy servers. This is not disclosed in their privacy policy, and the somewhat vague assurance of things being done “in a secure manner” is not entirely comforting. Beyond that, the statement gave some other interesting clues. One clue was that this is a feature of the Nokia Xpress Browser, an app that is available for the popular Nokia Lumia phones that run Windows Phone 8. These phones are available from the major US carriers, whereas Pandya’s phone (the Asha) is mostly sold abroad. So I tracked down a Lumia phone, installed Nokia Xpress, and did my own investigation. Results after the jump.

[Read more…]

Understanding the HDCP Master Key Leak

On Monday, somebody posted online an array of numbers which purports to be the secret master key used by HDCP, a video encryption standard used in consumer electronics devices such as DVD players and TVs. I don’t know if the key is genuine, but let’s assume for the sake of discussion that it is. What does the leak imply for HDCP’s security? And what does the leak mean for the industry, and for consumers?

HDCP is used to protect high-def digital video signals “on the wire,” for example on the cable connecting your DVD player to your TV. HDCP is supposed to do two things: it encrypts the content so that it can’t be captured off the wire, and it allows each endpoint to verify that the other endpoint is an HDCP-licensed device. From a security standpoint, the key step in HDCP is the initial handshake, which establishes a shared secret key that will be used to encrypt communications between the two devices, and at the same time allows each device to verify that the other one is licensed.

As usual when crypto is involved, the starting point for understanding the system’s design is to think about the secret keys: how many there are, who knows them, and how they are used. HDCP has a single master key, which is supposed to be known only by the central HDCP authority. Each device has a public key, which isn’t a secret, and a private key, which only that device is supposed to know. There is a special key generation algorithm (“keygen” for short) that is used to generate private keys. Keygen uses the secret master key and a public key, to generate the unique private key that corresponds to that public key. Because keygen uses the secret master key, only the central authority can do keygen.

Each HDCP device (e.g., a DVD player) has baked into it a public key and the corresponding private key. To get those keys, the device’s manufacturer needs the help of the central authority, because only the central authority can do keygen to determine the device’s private key.

Now suppose that two devices, which we’ll call A and B, want to do a handshake. A sends its public key to B, and vice versa. Then each party combines its own private key with the other party’s public key, to get a shared secret key. This shared key is supposed to be secret—i.e., known only to A and B—because making the shared key requires having either A’s private key or B’s private key.

Note that A and B actually did different computations to get the shared secret. A combined A’s private key with B’s public key, while B combined B’s private key with A’s public key. If A and B did different computations, how do we know they ended up with the same value? The short answer is: because of the special mathematical properties of keygen. And the security of the scheme depends on this: if you have a private key that was made using keygen, then the HDCP handshake will “work” for you, in the sense that you’ll end up getting the same shared key as the party on the other end. But if you tried to use a random “private key” that you cooked up on your own, then the handshake won’t work: you’ll end up with a different shared key than the other device, so you won’t be able to talk to that device.

Now we can understand the implications of the master key leaking. Anyone who knows the master key can do keygen, so the leak allows everyone to do keygen. And this destroys both of the security properties that HDCP is supposed to provide. HDCP encryption is no longer effective because an eavesdropper who sees the initial handshake can use keygen to determine the parties’ private keys, thereby allowing the eavesdropper to determine the encryption key that protects the communication. HDCP no longer guarantees that participating devices are licensed, because a maker of unlicensed devices can use keygen to create mathematically correct public/private key pairs. In short, HDCP is now a dead letter, as far as security is concerned.

(It has been a dead letter, from a theoretical standpoint, for nearly a decade. A 2001 paper by Crosby et al. explained how the master secret could be reconstructed given a modest number of public/private key pairs. What Crosby predicted—a total defeat of HDCP—has now apparently come to pass.)

The impact of HDCP’s failure on consumers will probably be minor. The main practical effect of HDCP has been to create one more way in which your electronics could fail to work properly with your TV. This is unlikely to change. Mainstream electronics makers will probably continue to take HDCP licenses and to use HDCP as they are now. There might be some differences at the margin, where manufacturers feel they can take a few more liberties to make things work for their customers. HDCP has been less a security system than a tool for shaping the consumer electronics market, and that is unlikely to change.

Pseudonyms: The Natural State of Online Identity

I’ve been writing recently about the problems that arise when you try to use cryptography to verify who is at the other end of a network connection. The cryptographic math works, but that doesn’t mean you get the identity part right.

You might think, from this discussion, that crypto by itself does nothing — that cryptographic security can only be bootstrapped from some kind of real-world identity verification. That’s the way it works for website certificates, where a certificate authority has to check your bona fides before it will issue you a certificate.

But this intuition turns out to be wrong. There is one thing that crypto can do perfectly, without any real-world support: providing pseudonyms. Indeed, crypto is so good at supporting pseudonyms that we can practically say that pseudonyms are the natural state of identity online.

To explain why this is true, I need to offer a gentle introduction to a basic crypto operation: digital signatures. Suppose John Doe (“JD”) wants to use digital signatures. First, JD needs to create a private cryptographic key, which he does by generating some random numbers and combining them according to a special geeky recipe. The result is a unique private key that only JD knows. Next, JD uses a certain procedure to determine the public key that corresponds to his private key. He announces the public key to everyone. The math guarantees that (1) JD’s public key is unique and corresponds to JD’s private key, and (2) a person who knows JD’s public key can’t figure out JD’s private key.

Now JD can make digital signatures. If JD wants to “sign” a certain message M, he combines M with JD’s private key in a special way, and the result is JD’s “signature on M”. Now anybody can verify the signature, using JD’s public key. Only JD can make the signature, because only JD knows JD’s private key; but anybody can verify the signature.

At no point in this process does JD tell anybody who he is — I called him “John Doe” for a reason. Indeed, JD’s public key is a perfect pseudonym: it conveys nothing about JD’s actual identity, yet it has a distinct “owner” whose presence can be verified. (“You’re really the person who created this public key? Then you should be able to make a signature on the message ‘squeamish ossifrage’ for me….”)

Using this method, anybody can make up a fresh pseudonym whenever they want. If you can generate random numbers and do some math (or have your computer do those things for you), then you can make a fresh pseudonym. You can make as many as you want, without needing to coordinate with anybody. This is all easy to do.

These methods, pseudonyms and signatures, are used even in cases where we want to verify somebody’s real-world identity. When you connect to (say) https://mail.google.com, Google’s web server gives you its public key — a pseudonym — along with a digital certificate that attests that that public key — that pseudonym — belongs to Google Inc. Binding public keys — pseudonyms — to real-world identities is tedious and messy, but of course this is often necessary in practice.

Online, identities are hard to manage. Pseudonyms are easy.