4

This question is a followup question to Storing plaintext passwords for cameras - Security concerns?. In that question, I posed what I thought was a simple question, which actually turned out to have various security holes. Thanks to the answers, I've been able to fix most issues, except this last one...

We're developing new cameras for use in monitoring and security of private homes.

One of the features of the service we're offering is the online recording service.

Where previously, one would be screwed if their camera was stolen (since the camera contained the storage medium upon which the footage was stored), with our online recording service, the footage is stored in the cloud and retrievable at a later moment.

The current security plan for the cameras and this online recording service is as follows:

  • There are 4 pieces of hardware involved: the camera, the client device (phone with app), our database and our recording service.
  • A camera requires (camera unique) default password for configuring the camera. This is only possible after a factory-reset (or when the camera is new). This default password is stored plaintext in our online database for support.
  • During initial configuration of the camera, camera adds public SSH key of the configuring device to its keystore.
  • Camera keeps a list of public SSH keys of authenticated devices. To register, a new device has to connect to the camera and request to be added. It provides its public key and perhaps some string for the admin to recognize the device. We will allow disabling of registration to prevent internet-scanners from making registration attempts to each camera (and thereby annoying each customer).
  • It's possible that we relocate the registration of public keys to the online platform instead, so that we can build upon this to make registrations for multiple cameras in one go easier. This however introduces an attack vector where an employee can add their own key into the list. Customers will have to pay good attention to who they allow to see their camera.
  • When an authenticated device reconnects to the camera, it checks for any new registrations, and may choose to add them. It's also allowed to revoke access. If a customer accidentally adds a bad device (like their ex's phone?) and has their access revoked, they can always factory-reset the camera with their physical access to the camera and reconfigure the camera.
  • For the online recording service, an authenticated device can ask the online recording service for its public key. The public key is then added as "view-only" in the camera. Like this, the recording service can be registered only by permission of the customer.

This brings a security hole:

It's possible for employees to view the camera feeds from any camera subscribed to the recording service.

A possible plan posted by one of the answerers on my previous question consisted of the following:

  • Encrypt the video stream with a session key.
  • Renew the session key every few minutes.
  • Encrypt the session key with each of the public keys stored on the camera.
  • Send encrypted session keys and encrypted stream to the recording service.

But this solution is not perfect: In the event that you set up an indoor camera, and a break-in happens, and both the camera and the single, only authenticated device are stolen, the video stream from the recording service is not decryptable. In this event, the only thing you have left is the encrypted session keys, the public key (if we store these on our servers) and the encrypted video stream data. The private key is lost, as is the SD card on which an unencrypted copy of the video stream could be kept.

Additionally, it's not possible for a device to view yesterday's footage if it was added today. This is also an undesired feature.

Is there any way to allow encryption of the video stream that is decryptable even if both camera and authenticated device is lost forever (and with it, the local recording on SD card as well as the private key on the authenticated device)?

Thus my question,

How to securely encrypt data with a public-private key encryption scheme, but also allow decryption if the private key is lost?

I realize this might be impossible to do - in that case, is it possible to allow recreation of the private key by remembering a secret (basically, something like using a key derived from the customer's plaintext password to encrypt a session key... of which we only store the salted, hashed value)?

Community
  • 1
Pimgd
  • 291
  • 1
  • 12
  • Can't you just encrypt the session key once more, with a fail-safe key, which is stored on the server and can be retrieved by the client (via calling your support and authenticating himself) ? Then he could decrypt all his video with this fail-safe key? – Falco Jan 09 '15 at 14:03
  • @Falco doesn't this open up the possibility of employees using the "fail-safe key" to view the encrypted streams? – Pimgd Jan 09 '15 at 14:06
  • Of course, if 1. Employees can access the fail-safe-keys and 2. These Employees also can access the privately stored encrypted video-stream of your customer. - You should save the fail-safe keys in a way that each access is logged and the user is informed per mail that it was accessed, and probably reset it after use and factory-reset of the camera – Falco Jan 09 '15 at 15:20
  • 2
    But your question essentially is "How can one decrypt customer video without their private key" - so that your employees have the potential for it is implied in the question. You could of course also give the fail-safe-key to your users as a printed password on a piece of paper, which they keep in a safe or something like this, like it's done with mobile phone unlock codes... – Falco Jan 09 '15 at 15:23

2 Answers2

9

There are a few ways to solve this situation.

One is to have the camera always encrypt one of the session keys to a camera backup key. The camera backup key is generated on account setup of the camera and a password is generated that is used to encrypt the backup key. This password is never stored on the camera itself. Your online storage would store the encrypted backup key, and you tell the user to print and keep the backup password somewhere safe but accessible in case they lose all their access client devices at the same time, like in a safe deposit box (SDB), the users' Dropbox, or grandma's house. You'll need to collect an agreement from the user that their data will be inaccessible if they lose this backup password and your staffs will be unable to help them with decrypting their videos.

If the user don't want to accept that agreement, you can suggest to the user that you can store the backup key in your high security data center. Ensuring high security on a small, low traffic data center that are dedicated for storing only users backup keys are much easier (and cheaper) than securing the high traffic data center that also need to scale to handle all the live videos. Now, this does mean that strictly speaking you or your employees you trust who manage this data center can decrypt any videos stored in your service at will, but in a properly secured high security data center, it should be very, very difficult to pull this off without raising an alarm and audit trails everywhere without involving collusion from a large number of your employees. The most difficult part is in designing a high security data center, this is not easy.

Whether to trust your security or not is a risk your user have to decide on, whether they want convenience with reasonable security or total security with potential risks. You may want to present this as an option to your user describing the trade off they'll need to take:

  1. I prefer absolute security. Company X will store my videos in a way that is impossible for Company X to recover if I lose access to all my access devices and backup password (...add detail why impossible really means impossible...). I am solely responsible for keeping the backup password secure and accessible only to myself. I agree to not hold Company X responsible for any data losses or breaches that may occur due to losing or leaking my backup password. (... add some tips for securing backup password...)

  2. I prefer convenience. Company X will store my videos in a high security data center, (... describe the steps taken to ensure that not just any one of your employees can view my baby's videos here ...). Under request by me or under appropriate subpoena by law enforcement, Company X can decrypt any videos I store on Company X's server. (... describe the legal agreements here...)

Deer Hunter
  • 5,297
  • 5
  • 33
  • 50
Lie Ryan
  • 31,089
  • 6
  • 68
  • 93
  • 1
    Can "High security on a small, low traffic data center" be owned by Company Y? I'll never get "we need a high security data center" past my manager, but "We can store the keys securely with company Y for $x/timePeriod" is far more likely to pull through. – Pimgd Jan 09 '15 at 14:24
  • 2
    @Pimgd: yes, that secure storage can be a different company. Just make sure you research their expertise very carefully because ultimately your company is the one that's responsible to your customers. If Company Y is a company that specialises in hosting highly sensitive information, off loading this expertise can actually be more secure, because their employees are probably more highly trained than yours on protocols and system designs for handling highly sensitive information. Also, collusion now will have to involve multiple companies, i.e. more chances for whistle blowers. – Lie Ryan Jan 09 '15 at 14:34
  • Especially if there's some way to make the storage easy to write to but hard to read from, this idea will be ideal. Even if the core of the idea is "keep another private key on hand, somewhere". – Pimgd Jan 09 '15 at 14:43
  • 1
    A possible option 1.5 would be to regularly export new customers keys to an airgapped computer or offline backup so that even if the secure internet facing server is compromised long term customers keys wouldn't be accessible to the attacker. – Dan Is Fiddling By Firelight Jan 09 '15 at 14:51
  • @DanNeely: generating the backup key at production time is certainly another possible solution. It does have a different trade off though. The pros is that initial setup is much simpler for the customer, the cons is that a production key cannot be changed once the camera leaves your production line, which may have some impact on security (e.g. if camera is resold, etc). – Lie Ryan Jan 09 '15 at 15:21
  • 2
    You could address the problem of employees viewing stream by adding SO MUCH RINGING BELLS that they won't even touch the backup-key container. If make your server's application to turn the primary key invalid upon backup-key usage, which by the way you want it to be, you are securing your customer from the theft event described above. Once the primary key is compromised, you OUGHT to dump it for good. If it was used by the customer because device theft, your client is aware of it. If it was used by prying employees, customers will know it and hell will break loose for the unlawful watchers. – DarkLighting Jan 09 '15 at 15:28
3

You can't.

If the private key is lost, then, essentially, you can only decrypt the data by recreating the key... organizations like the "TLA's" (FBI, CIA, NSA, etc.) are actively trying to do what you suggest. It is a hard problem, and that's why encryption works.

In your case, the better option would be to create a new public/private key, and to then stream the data with the new key. Old data is effectively unrecoverable at reasonable costs.

rolfl
  • 171
  • 1
  • 4
  • Even if the private key is created from a known secret? I found an image which basically throws "a large random number" into a key generation program - what about sticking a password (with zero-bytes padding if needed) into the key generation program? Additionally, streaming the data with the new key is not possible; the break-in in this case has already happened - the camera is gone, there's nothing to stream from. But having the footage would allow people to make an insurance claim, and/or identify the perpetrator. – Pimgd Jan 09 '15 at 11:58
  • Said image is http://upload.wikimedia.org/wikipedia/commons/thumb/3/32/Public-key-crypto-1.svg/250px-Public-key-crypto-1.svg.png from this wikipedia page: http://en.wikipedia.org/wiki/Public-key_cryptography – Pimgd Jan 09 '15 at 11:59