How Ring Could Really Protect Its Users: Encrypt Footage End-To-End

Last week, we responded to recent changes Amazon’s surveillance doorbell company Ring made to the security and privacy of their devices. In our response, we made a number of suggestions for what Ring could do to be responsive to the privacy and security concerns of its customers and the larger community. One of our suggestions was for Ring to implement measures that require warrants to be issued directly to device owners in order for law enforcement to gain access to footage. This post will elaborate on this suggestion by introducing a technical scheme that would serve to protect both Ring’s customers and the wider community by employing end-to-end encryption between doorbells and user devices.

Introduction: The Cloud and User Notification

In traditional surveillance systems, law enforcement had to approach the owners of footage directly in order to gain access to it. In so doing, law enforcement informed owners of the fact their footage was being requested and the scope of the request. This also served as a de facto rate-limiting of surveillance requests: a certain amount of real-world legwork had to be done to gain access to private footage. Even then, the footage was most likely granted once, and subsequent requests would have to be made for more material.

With the advent of cloud storage, access to raw footage moved from individual, private surveillance systems to the cloud provider. Once on the cloud, law enforcement can go straight to the cloud provider with a warrant for user footage, without informing the user. And footage on the cloud also makes it available to cloud employees—who can access the footage without permission from the user.

End-to-End Encryption Can Protect Footage and Feeds

End-to-end encryption (E2EE) allows devices to communicate with one another directly with the assurance of security and authenticity. This means that a user can encrypt data in a way that only the direct recipient can decrypt, and no one else—including the cloud storage provider that she uploads to and the manufacturer of the device she uses—can see what was sent. All they’ll see is undecipherable “ciphertext.”

Usually, end-to-end encryption happens between two or more devices owned by different people, and is implemented in communication apps like Signal and WhatsApp. E2EE can also happen between two devices owned by the same person to share sensitive data. Backup software SpiderOak One and tresorit use E2EE to back up files to the cloud in a secure way, and password managers like Dashlane and LastPass use it to store your passwords in the cloud securely. The backed-up files or passwords will be retrievable by multiple devices the user owns, but not by any other device. Not only does this protect the communication from the employees of these services, it also means that data breaches like the one LastPass experienced in 2015 do not result in any compromise of the sensitive encrypted data.

Ring has already experienced its share of data breaches and hacks in recent months, and responded by blaming its users and downplaying the dangers. The data breach resulted in username and password information on 3,600 customers being divulged, which put these users’ footage in direct reach of hackers and the shadiest of data miners. Employees of Ring were found spying on customers through their doorbell cameras. Ring’s history of lax security has made it the subject of a number of lawsuits, and a salient target for future hacks. To turn the tide and show that it’s serious about security, the absolute best thing Ring could do is employ E2EE in its video feeds and AWS-based storage.

Not only would employing E2EE protect its users against their footage being divulged by a hack on user accounts or the AWS cloud, it would also implement just the kind of measure EFF calls for in ensuring law enforcement is required to request data directly from device owners. In E2EE schemes, the keys for the encrypted data are stored on users’ devices directly, and are not held by the service provider. If a member of law enforcement wishes to obtain footage from a user’s camera, they would have to ask the device owner to hand that footage over. This means that Ring would no longer provide law enforcement with a national video and audio surveillance system, since footage would have to be requested and delivered on an individual basis. It would be a return to the benefits that de facto rate-limiting of traditional surveillance systems provided, while retaining the convenience that Ring hinges its success on.

Moreover, this wouldn’t necessarily be a very difficult system to implement. E2EE video feeds have been implemented in open-source encrypted communication platforms like Signal already, and encrypting stored video files with end-to-end can easily be done with inclusion of libraries made for just this purpose. In fact, some services seem to specialize in helping businesses with exactly this transition, intending to facilitate compliance with privacy legislation like HIPAA and GDPR.

Implementation Scheme Suggestion

Readers not interested in specific technical suggestions can safely skip this section. The TL;DR: an E2EE scheme for home security systems can and should be implemented.

So, how would such a system be implemented? In specifying this implementation suggestion, specific details such as choice of algorithm or keysize is omitted. Best practices should be followed for these. The intention is not to provide a spec, but rather to give a broad overview of the various pieces of infrastructure and how they could communicate with the assurances E2EE provides.

Keybase provides a good template for how to ensure key material is not lost through user mismanagement, sharing key material between multiple devices and using physical artifacts like paper copies in combination with digital devices to provide a guarantee of secure key redundancy.

The doorbell device, upon first activation, would generate a new doorbell keypair. The public key for the doorbell can be shared with the smart device app where the feed and videos will be viewed via a direct connection in a shared trusted network setting.

Likewise, the first smart device app connecting to the doorbell will generate a keypair, and communicate its public key to the doorbell in the same shared trusted network setting. The user would also be prompted to back up their key with a paper copy, and tips on best practices in physical security could be communicated.

If the doorbell has a speaker, it can at this point read off the digest form of the doorbell public key concatenated with the digest form of the app public key it received. This is the equivalent of safety numbers in Signal, and could be presented modulo the diceware list to generate a series of words, for the sake of usability. This should be verified by the user on the smart device app. Otherwise, trust in the public keys will have to be derived from the trusted network setting in which they were exchanged.

If a secondary smart device is added to the account, it should be linked with the primary smart device. Since the secondary device does not yet trust the primary device, secure key discovery has to be performed. The primary device should generate a symmetric key, and display it to the user in the form of a code. It should then send a copy of the app keypair encrypted with the symmetric key to the secondary device, which will prompt the user to enter the code to decrypt and start using the keypair. Alternatively, the secondary device could derive the keypair from the paper copy.

Any additional devices added to the account can follow the same process to receive the app keypair.

At this point, trust is established between the doorbell and all connected devices’ apps.

Upon activation, the doorbell would begin recording video (and possibly audio). The video should be encrypted to a random, newly-generated symmetric key. This symmetric key should then be encrypted to the app public key, signed by the doorbell private key, and saved as a separate file. Both files should then be stored on the cloud. Upon access of the video, the app will then decrypt the symmetric key with its private app key, and use that to decrypt and view the video. To share the video, the app can decrypt the symmetric key and share that with the server or whoever is requesting access.

Live video can also be provided to devices by encrypting it to the app public key directly and signing it with the doorbell private key. Likewise, if a two-way communication is desired, the app can encrypt any audio sent back to the doorbell with the doorbell public key.

Why Ring Won’t Want To Implement This…

Ring brands itself as a security-focused company, despite its digital security record. It handles the footage of millions of customers. Given the benefits to its customers, use of E2EE would seem like a natural next step. We hope Ring takes this step for its customers—it would certainly be a welcome turn for a company plagued by recent bad press following its insecure practices. It would show a real willingness to protect its customers and their data. But unfortunately, Ring currently has a direct incentive not to implement this strong security measure.

In the spring of 2018, Ring began a partnership program with police departments across the U.S. This program has expanded dramatically since its introduction to over 900 departments. Ring has carefully cultivated these relationships, with the expectation of troves of information from Ring’s system being available to law enforcement. Additionally, these relationships are largely secretive, with agreements requiring confidentiality be maintained.

They’ve also expressed interest in implementing facial recognition for footage. In our post last week, we expressed serious concerns about this technology, including that it exacerbates racial bias and overpolicing. In order to perform identification using Amazon’s facial recognition infrastructure, Ring would need unencrypted access to user footage.

Privacy advocates and customers face an uphill battle to convince Ring to implement these features. In the past, Ring has been slow to take steps to address user security and privacy concerns. Their incentives are currently to maintain and expand the partnerships they’ve built, utilizing Amazon’s infrastructure to process the footage they possess. It will take Ring a significant reprioritization of their customers over their partnerships in order to take the next step forward.

…And A Competitor Just Might

Luckily, Ring isn’t the only game in town. The field of smart home-security systems is filled with competitors, such as Google’s Nest. These competitors, for whatever reason, haven’t been as willing or able to build out a mass surveillance system for police use. This leaves them unencumbered by the agreements and expectations Ring has tied itself down with. A competitor in the field could implement a system that provided E2EE guarantees to its customers, protecting their feeds and footage in a very comprehensive way—from nosy employees, malicious hackers, and police agents all too eager to have this mass of data at their fingertips.

Whoever ends up implementing this forward-thinking system would signal that they are ready to take the sensitive data of their customers seriously. This would be a big step forward for the privacy and security of not just device owners, but also the community as a whole.