What Ring Got Wrong With End-to-End Encryption
And What They Got Right, Too
We’ll dig into what they did, from usability through to the cryptographic choices they made, but if you’re impatient, here are the quick takeaways:
Summary of the Good
It’s incredibly encouraging that Ring has decided to add end-to-end encryption as a feature, and there are no apparent flaws in their design (though a few questionable choices).
Summary of the Bad
Ring doesn’t really want you to use this feature. They’ve held it back from their flagship products, made it hard to enable, and made you sacrifice critical functionality.
The Details
We were wildly excited when Ring announced that their end-to-end encryption was finally generally available and when they released a white paper and executive summary detailing how it works.
Unfortunately, despite press announcements about its availability and the January 11, 2021 promise date in their white paper, as of January 25, we are still unable to turn on the feature.
The page for enabling end-to-end encryption in the Ring app still says, “Coming Soon.” While that’s disappointing, we can still evaluate what they’re doing by looking at their whitepaper and the user experience in the app so far.
User Experience
For the user experience, the first thing we notice right off the bat is how hard Ring is trying to keep you from stumbling on these settings unless you already know where to look.
Going into device settings and account settings is futile. Instead, you have to go to the last menu item, the “Control Center,” to start your journey. From there, you click into “Video Encryption,” which has some bogus “settings” trying to convince you that your data is already sufficiently encrypted. These settings are misleading since the encryption they provide is the bare minimum and they don’t address privacy concerns at all.
Under “Video Encryption,” you have to click on “Advanced,” then on the only option under that, “End-to-End Encryption,” which currently takes you to a page telling you to come back later, but which I imagine in the future will have some sort of setup wizard to start the mobile device enrollment process.
End-to-end encryption is neither on by default, nor something they’ll prompt you about if you’re a new user. It is intended to allow them to tell the market they have end-to-end encryption. It is not intended to be easy to adopt.
Supported Devices and Features
Ring has further made it difficult to use by limiting both supported devices and functionality. Let’s start with devices.
If you focus on the Ring Doorbell line, you’ll immediately notice that only two of their seven devices are supported. What’s even more striking is that the two supported devices are from 2016 and 2017. Of the three Ring Doorbell cameras released in 2020, none are supported. And that’s even more surprising to me since the in-app news and notifications make a big point of calling out the security features as a selling point for the “Video Doorbell 3” and the “Video Doorbell 3 Plus.” Their “premium” doorbell product with “advanced security features” doesn’t support end-to-end encryption.
That’s hugely disappointing.
On the feature front, it doesn’t get much better. Some of the features you lose make a ton of sense, such as the loss of the ability to share links to videos for others to watch and the ability to share your account with other users.
I can think of several ways to add these features back securely (for example, by encrypting the video key with a passcode that you share out of band). Still, if you want private videos, these features probably aren’t critical. Also, Ring lets you download videos to your device, so someone using end-to-end encryption can still share a video if they want, just not through Ring.
There’s also the issue of supported clients. End-to-end encryption isn’t supported on the Amazon Echo Show, FireTV, FireTablet, or on their native desktop apps for Mac and Windows. In fact, only iOS and Android devices are supported. But we’re not complaining too much on that front either since you have to start somewhere.
The most significant loss of functionality is on the computer vision analysis features and, in particular, the motion verification and people-only modes. Before they added these features, we had motion detection turned off on our Ring Doorbell since cars going by and catching the sunlight at certain times of day would trigger the motion sensor repeatedly.
I can understand the problem here since they run the analysis of the videos on their servers, and without access to the video contents, their servers can’t render an opinion. It’s still a pretty big disappointment, though.
There’s one other limitation that I find curious, and that’s the restriction where only a single device at a time can view the live video stream. Ring doesn’t explain why this is a limitation. On the face of it, it should be trivial to share the current live stream key with however many devices want to look at it. Without that functionality, if someone rings the doorbell and my wife and I both look at our phones from different rooms to see who’s there, only one of us will be able to see the video while the other gets an error.
How It Works Under the Hood
The white paper and the executive summary both do a bit of hand waving and make the scheme, which is generally pretty simple, hard to understand fully without rereading sections. Or that was my experience. Below is a restatement of what they’re doing that should bring more clarity.
The Keys
There are two types of devices in play, the Ring devices, and the mobile phones. The first thing you have to do is to enroll an initial mobile device. When you do this, it locally generates three public/private key pairs:
- Account Signing Key Pair (RSA 2048bit)
- Account Data Key Pair (RSA 2048bit)
- Instance Key Pair (ECC 256bit P256)
Honestly, these names are not great for developing an intuition of what they’re doing. The Account Signing key pair’s primary purpose is to sign public keys so that a Ring device knows it is okay to encrypt to a given public key. And on initial setup, the Account Signing key pair does sign over the Instance and Account Data public keys before sending them to Ring.
The Instance key pair might be better called the Mobile Device key pair as the private key for it is stored in the phone’s secure enclave and never leaves the device.
The Account Data key pair might be better called the Decryption Backup key pair as its purpose is to allow a newly enrolled mobile device to decrypt older videos.
We’ll come back to what happens with these private keys in a minute, but to further develop our intuition about the scheme, let’s move on to what happens when a Ring device generates an encrypted video stream.
Encrypting Video Streams
There’s a setup process for turning on end-to-end encryption for a given Ring device like a Doorbell Camera. That’s explained below. Once it is set up, whenever it starts recording video, it first generates a random AES 128 key and then uses AES GCM to encrypt the video stream. (They do not explain how GCM is used here, so we don’t know how quickly integrity issues would be detected.)
The AES key for this new recording is itself encrypted to the public keys of each enrolled mobile device (each Instance Key) and to the backup key (the Account Data key). These are sent to Ring to hold. Enrolled devices need this encrypted AES key to decrypt video streams. Ring cannot decrypt these keys, which is why they do not have access to the end-to-end encrypted video streams that they store on your behalf.
Enrolling New Ring Devices
You can’t just turn on end-to-end encryption and expect it to be on for all your devices. Once you’ve enrolled an initial mobile phone, you have to separately turn it on for each Ring device that supports it and where you’re willing to make the privacy/functionality trade-offs that Ring demands. And if you have multiple mobile devices (spouse, tablet, etc.), you’ll need to enroll those as well.
A Ring device enrolled in E2EE gets its own key pair, which it uses to sign the symmetric keys that it encrypts. Ring doesn’t specify the type of key pair on this or how the signing interoperates with two different key types (elliptic curve and RSA), but we’ll assume this works in some reasonable way.
The idea is that a direct Wi-Fi connection is established between the enrolled mobile device and the Ring device to exchange signing keys. In this way, the Ring device knows the user’s public Signing Key and can validate other public keys that it receives from the Ring service in the future.
Presumably, the mobile device is also able to store the public key of the Ring device so it can validate the signatures of the encrypted keys, but this isn’t stated, and it’s unclear if any such signature validation happens.
Sharing Private Keys/Enrolling New Mobile Phones
The trickiest part of systems like these is in dealing with lost phones and new device scenarios. Ring seems to have ignored part of the lost phone scenario — the key revocation part — in their whitepaper and, I suspect, in their design and implementation as well. But they’ve worked on the key recovery and new device scenarios.
When setting up an initial device and after generating the three key pairs locally, the Ring app then randomly produces a ten-word passphrase from a 7,776-word dictionary. This passphrase is presented to the user, who must capture it somewhere like in a password manager. This passphrase will be required to enroll any future devices and to decrypt previously encrypted videos.
This passphrase is mixed with a salt and then used to generate a key that is derived from it. This is done twice with two different salts to make two different keys derived from the passphrase. The passphrase is then assumed to be kept by the user, and the app discards it.
These two generated keys are used to encrypt each of the Account keys —one encrypts the Account Signing Private Key, and the other encrypts the Account Data Private Key. Those encrypted private keys are then sent to the Ring servers.
So far, so good, and at this point, someone in possession of the passphrase could enroll a new mobile device, use the Account Signing Private Key to sign over their Instance public key, and use the Account Data Private Key to decrypt previously encrypted videos.
But for some reason, Ring made a few curious choices here.
Wait, they’re encrypting to the signing key?
First, the passphrase-derived key used to secure the Account Signing Private Key is encrypted to each Instance public key so that an existing device can get access to the Account Signing Private Key without requiring the passphrase. Ring likely holds the key so they can withhold it as needed to prevent a stolen device from getting access to the Account Signing private key — assuming they provide a way to mark a device as stolen in a future release.
Second, the passphrase-derived key used to secure the Account Data Private Key is also encrypted and stored with Ring, but this one isn’t encrypted to the Instance Keys on each device. Instead, it’s encrypted to the public Account Signing Key.
I can see no reason for this design choice.
It’s generally bad practice to use signing keys for encryption, but more than that, it makes it a weird multi-step process to get access to the Account Data key.
Consider the use case here: the Account Data key is needed whenever viewing a video that was created before the current mobile device was enrolled. The Account Signing key is only required when enrolling a new Ring device or a new mobile device. But what they’ve done is made it so the mobile device has to access the Account Signing Private Key to decrypt the Account Data key. And they did this against best practices. It certainly wouldn’t be any harder to encrypt the Account Data Private Key to each Instance Key as they do for the Signing Key. The server would still get to gate access. So why encrypt to the signing key?
Perhaps someone from Ring will let us know in the comments what we’re missing here.
Final Thoughts
I’m glad that Ring has brought end-to-end encryption to their customers. It’s a significant move on their part, and it sets the bar for the rest of the internet-connected camera industry. And I believe they’ll continue to set the bar as they hopefully evolve and improve the feature.
As it evolves, there are several key areas I’d really like to see them address:
- Bring support for end-to-end encryption to all Ring devices that are currently being sold.
- Don’t bury the feature or make people turn it on device by device. Make this a first-class choice for customers right up front.
- Develop the revocation story and allow a user to meaningfully revoke access to a device if it’s lost, stolen, or whatever. And while you’re at it, add a meaningful key rotation story because there doesn’t appear to be one.
- Apply engineering effort to the problem of reducing false positives in motion detection over encrypted data. We have a lot of interesting tools available now that can be applied to this problem. I hope Ring invests in this area so their customers don’t have to choose between a working product and privacy.
- Rethink how you protect and share the Account Data Private Key.
And in case anyone from Ring reads this, you might consider using proxy re-encryption to manage devices, share access amongst users, and manage the various keys, rotations, and revocations. It would solve quite a few problems. We also have some ideas on how you might bring back some form of intelligent motion detection and would be happy to spitball them with you.
UPDATE 2021-01-27
There are a few more things that we left out that make us go, “hmmm” with this. The lack of any discussion about how they generate keys, what type of keys they generate, their source of entropy, etc., on the Ring device is a head scratcher. As is the fact that the Ring device has to encrypt both with RSA and ECC. RSA makes no sense for low power devices. And using ephemeral keys there would be prohibitively expensive in the conventional way. Which begs a lot of questions about how truly secure the public key encryption of the video stream key is. I hope Ring shares more details to explain more of their approach to build credibility and trust in it.
