5 ms·

How about an SD card in to which SmartCard, the size of a micro SIM card, can be inserted. The SmartCard holds a public key, and any files written to the SD car

How about an SD card in to which SmartCard, the size of a micro SIM card, can be inserted. The SmartCard holds a public key, and any files written to the SD card are signed and encrypted using that public key. Decrypting the files would be accomplished with the corresponding private key which is kept separate on a different hardware device and using a PC.

teh_klev 10y ago
I don't think you need new hardware for this. Just a place you can drop your public key on the camera. [edit] But then I hadn't thought about legacy devices. Minor nitpick: signed and encrypted using that public key You don't sign things with a public key, it's your private key you sign with.
- dogma1138 10y ago
  Public key crypto for data is also pretty darn inefficient just have an FDE for the storage many cameras come with pcie based storage interfaces. You can also always plug the camera to a laptop and use it as a capture device basically.
  - x1798DE 10y ago
    I don't know how inefficient it really is as implemented, I think generally you just generate an AES key or something, use it to encrypt the photo, then encrypt the AES key with the public key and flush it from memory. That's if you want "one-way" encryption (i.e. once the photo is taken you can't retrieve it again until the private key is present).
    - dogma1138 10y ago
      Yes, you usually have your symmetric key and your key encryption key, doing data at rest with public key isn't really efficient since then you need to store and protect the private key as long as the data encryption key is in use, so you usually use some key derivation algorithm for your kek which means that your kek is derived or otherwise protected by a password. The private key needs to be in memory as long as you are filming/camera is on since otherwise you can't really encrypt the data so you can't film.
      - x1798DE 10y ago
        I don't think that's true. You definitely don't need a private key, you create a symmetric key from whatever randomness source you have, held in memory while you are using it to encrypt the data. The first thing you do is encrypt the symmetric key with the public key, then the rest of the data is encrypted as you go using the symmetric key. If you want to decrypt the data, you need the private key corresponding to the public key that this was encrypted with, but that can be left at home, but you never need it before that, so you can leave it at home if you want and you won't be able to access it until you get home.
        dogma1138 10y ago
        The DEK needs to be available in memory while the data is being encrypted on the fly e.g. being recorded, if it's encrypted already it's useless.
        x1798DE 10y ago
        Yes, the symmetric key (generated on the fly) is in memory while the data is being recorded, this is the case for every encryption technique. In the public/private scheme, once the symmetric key is no longer needed, you discard it permanently and files are only accessible using the private key, which you never had. A symmetric key is 256 bits, an HD video is on the order of hundreds of millions to billions of bits, so even if your public key crypto system were 100,000x slower than the symmetric crypto system, it's still going to be negligible compared to the cost of decrypting the remainder of the data. See https://en.wikipedia.org/wiki/Hybrid_cryptosystem https://en.wikipedia.org/wiki/Hybrid_cryptosystem For this reason, public/private key systems for data at rest is probably not particularly ineffcient relative to your suggestion of a symmetric FDE, plus it has the additional benefit that if you want to operate without the ability to decrypt data at rest, you have that option (by leaving the private key at home, since you only need the public key to write new data).
- sirclueless 10y ago
  Re: your nitpick. It's true that TLS as implemented on the internet encrypts with a private key and decrypts with a public key, but this is not universal. Encrypted PGP communications, for example, work the opposite way. Encrypting with a public key is a common technique if you want to ensure that only one person or device can decrypt it, which is what is desired here. It doesn't prove authenticity, unless you also sign the message with your own private key, but that's not the goal -- protection of the message from unwanted actors (and yourself even under compulsion) is the goal.
  - teh_klev 10y ago
    I wasn't mentioning this nitpick from a TLS point of view, I raised it as a PGP thing which is more likely to be the use-case per the point of the article.
deckar01 10y ago
Technically you don't even need a second memory card. Some SD cards have suitable processors in them already. Edit: Google's Vault [0] is a custom hardware implementation of this concept. [0] https://techcrunch.com/2015/05/29/googles-project-vault-is-a-secure-computing-environment-on-a-micro-sd-card-for-any-platform/ https://techcrunch.com/2015/05/29/googles-project-vault-is-a...
mayaa 10y ago
So you cannot review what you shot immediately on the camera.

teh_klev 10y ago

I don't think you need new hardware for this. Just a place you can drop your public key on the camera. [edit] But then I hadn't thought about legacy devices. Minor nitpick: signed and encrypted using that public key You don't sign things with a public key, it's your private key you sign with.

dogma1138 10y ago
Public key crypto for data is also pretty darn inefficient just have an FDE for the storage many cameras come with pcie based storage interfaces. You can also always plug the camera to a laptop and use it as a capture device basically.
- x1798DE 10y ago
  I don't know how inefficient it really is as implemented, I think generally you just generate an AES key or something, use it to encrypt the photo, then encrypt the AES key with the public key and flush it from memory. That's if you want "one-way" encryption (i.e. once the photo is taken you can't retrieve it again until the private key is present).
  - dogma1138 10y ago
    Yes, you usually have your symmetric key and your key encryption key, doing data at rest with public key isn't really efficient since then you need to store and protect the private key as long as the data encryption key is in use, so you usually use some key derivation algorithm for your kek which means that your kek is derived or otherwise protected by a password. The private key needs to be in memory as long as you are filming/camera is on since otherwise you can't really encrypt the data so you can't film.
    - x1798DE 10y ago
      I don't think that's true. You definitely don't need a private key, you create a symmetric key from whatever randomness source you have, held in memory while you are using it to encrypt the data. The first thing you do is encrypt the symmetric key with the public key, then the rest of the data is encrypted as you go using the symmetric key. If you want to decrypt the data, you need the private key corresponding to the public key that this was encrypted with, but that can be left at home, but you never need it before that, so you can leave it at home if you want and you won't be able to access it until you get home.
      - dogma1138 10y ago
        The DEK needs to be available in memory while the data is being encrypted on the fly e.g. being recorded, if it's encrypted already it's useless.
        x1798DE 10y ago
        Yes, the symmetric key (generated on the fly) is in memory while the data is being recorded, this is the case for every encryption technique. In the public/private scheme, once the symmetric key is no longer needed, you discard it permanently and files are only accessible using the private key, which you never had. A symmetric key is 256 bits, an HD video is on the order of hundreds of millions to billions of bits, so even if your public key crypto system were 100,000x slower than the symmetric crypto system, it's still going to be negligible compared to the cost of decrypting the remainder of the data. See https://en.wikipedia.org/wiki/Hybrid_cryptosystem https://en.wikipedia.org/wiki/Hybrid_cryptosystem For this reason, public/private key systems for data at rest is probably not particularly ineffcient relative to your suggestion of a symmetric FDE, plus it has the additional benefit that if you want to operate without the ability to decrypt data at rest, you have that option (by leaving the private key at home, since you only need the public key to write new data).
sirclueless 10y ago
Re: your nitpick. It's true that TLS as implemented on the internet encrypts with a private key and decrypts with a public key, but this is not universal. Encrypted PGP communications, for example, work the opposite way. Encrypting with a public key is a common technique if you want to ensure that only one person or device can decrypt it, which is what is desired here. It doesn't prove authenticity, unless you also sign the message with your own private key, but that's not the goal -- protection of the message from unwanted actors (and yourself even under compulsion) is the goal.
- teh_klev 10y ago
  I wasn't mentioning this nitpick from a TLS point of view, I raised it as a PGP thing which is more likely to be the use-case per the point of the article.

deckar01 10y ago

Technically you don't even need a second memory card. Some SD cards have suitable processors in them already. Edit: Google's Vault [0] is a custom hardware implementation of this concept. [0] https://techcrunch.com/2015/05/29/googles-project-vault-is-a-secure-computing-environment-on-a-micro-sd-card-for-any-platform/ https://techcrunch.com/2015/05/29/googles-project-vault-is-a...

mayaa 10y ago

So you cannot review what you shot immediately on the camera.