4 ms·

I found it odd when she said > I was destroying the physical media, because you can’t encrypt SD cards. Does she mean they don't come with built-in encryption

by konradb 12y ago

I found it odd when she said > I was destroying the physical media, because you can’t encrypt SD cards. Does she mean they don't come with built-in encryption? I'm curious as to why you couldn't just save an encrypted file or encrypted container to an SD card. edit: aaah, camera. I got the wrong end of the stick. Thanks!

vidarh 12y ago
She is talking about the SD cards in her camera, presumably. I don't know if you can get cameras that supports encrypting the images as they're written, but it's not unreasonable that she wouldn't have one, and not unreasonable that she'd be reluctant to trust whether or not formatting/overwriting the SD card would be sufficient to prevent recovery.
- raverbashing 12y ago
  I guess some overwrites should be enough for i in $(seq 1 1000); do if=/dev/urandom of=/dev/sdc bs=$((1024 * 1024)) count=(SD size in MB); done
  - josephlord 12y ago
    Actually what if one of the blocks used for the critical data was deemed degraded and removed from the pool and replaced with a reserve before it was overwritten. No way to delete then although expensive to retrieve it might be possible. Depends on the capability of your opponent and the consequences if your guess is wrong.
    - raverbashing 12y ago
      Yeah, also block size, I'm not sure how big they usually are. 512 bytes should be ok (for a picture), if it's bigger I'd be more worried Might be easier to microwave the SD card
      - nitrogen 12y ago
        Flash uses pretty large block sizes (look up specs for write size and erase size for common flash media; it's often 4KB writes+128KB erases), and the wear leveling algorithm can unpredictably shuffle the writes around. Your final paragraph is probably the only safe way to know an SD card's internal flash is unrecoverable, followed by physical destruction.
  - abandonliberty 12y ago
    Securely erasing flash memory is surprisingly hard. >Whole-disk wiping techniques faired only slightly better with SSD media. In the most extreme case, one unnamed SSD model still stored 1 percent of its 1 GB of data even after 20 sequential overwrite passes on the entire device. http://www.theregister.co.uk/2011/02/21/flash_drive_erasing_peril/ http://www.theregister.co.uk/2011/02/21/flash_drive_erasing_... I wonder how hard it is on SD drives. Meanwhile this forum claims the NSA mandates physical destruction https://discussions.apple.com/docs/DOC-5521 https://discussions.apple.com/docs/DOC-5521
- dublinben 12y ago
  This sounds like a great unmet opportunity to create a camera for journalists that encrypts every picture to a public key that only your editor (presumably in a safe location) has the private key to decrypt.
  - marcosdumay 12y ago
    And instantly uploads it (or at least, as soon as the camera is plugged to a phone).
    - vidarh 12y ago
      That part you can handle with a Transcend or Eyefi wifi-enabled SD-card. The Transcend cards have also been thoroughly hacked so they can be fairly easily customized.
  - gglitch 12y ago
    Excellent idea. For journalists - or just for citizens who happen to be standing around in the wrong place at the right time.
  - MichaelGG 12y ago
    Some cameras have open-ish firmware so it sounds easy enough to add. Unfortunately, the big SLRs from Canon and Nikon have terrible firmware run by an organization that's stuck in the 80s or worse with the typical poor level of software hardware companies are known for.
    - anigbrowl 12y ago
      Actually Canon makes their SDK freely available and while they don't let you fork the operating system there's an open-source alternative called Magic Lantern that works very well on most of their DSLR range and adds a lot of functionality (as well as providing a lot of reverse engineering info on their hardware through the site). Canon hasn't officially blessed this, but they haven't obstructed them in any way. The main problem with adding encryption would be that photos and video can consume a lot of bandwidth, and the bandwidth inside a digital camera is limited, as is the processing power. It would make more sense to put the encryption directly on the media card, similar to the fashion in which Eye-fi cards include a tiny CPU and web server to automatically offload the content to a trusted network.
griffordson 12y ago
I assume she's talking about the media used by her cameras. As in, the cameras store the raw data on SD cards in an unencrypted format.
mrsteveman1 12y ago
They do actually, but it's part of a DRM system [1] rather than something that would be trustworthy for privacy and file security purposes. It's apparently still being used by some Windows Phone devices. More on topic though, while there may not be a "simple" or trustworthy solution using built-in encryption on cameras or SD cards, it should be possible to create a (small, or "prototype sized but usable") device to sit in the middle of the electrical connections of the SD slot on any camera, and a normal SD card. The device would transparently encrypt video footage or pictures sent to the card. Would be an interesting side project. I've used the Beaglebone's USB client and host ports, along with the Linux USB gadget drivers and LUKS, to do something similar to transparently encrypt USB sticks, it wasn't particularly fast (8-9MB/s) but it was usable :) [1] http://en.wikipedia.org/wiki/Secure_Digital#DRM_copy-protection http://en.wikipedia.org/wiki/Secure_Digital#DRM_copy-protect...
- nitrogen 12y ago
  Do you have a git repo or blog post with code/info about your Beaglebone passthrough setup? I wanted to do something similar a while ago but never got to it.
  - mrsteveman1 12y ago
    I may have written a tiny script to automate part of it at the time but I probably just did it all manually as it's quite simple. I haven't setup a blog for this sort of thing yet, but the minimum steps required to make it work is just a few high level commands: 1) Create a LUKS volume on a connected USB stick/drive (cryptsetup luksFormat /dev/sda1) 2) Open the LUKS volume with a standard name for step 3 to use (cryptsetup luksOpen /dev/sda1 securestick) 3) Load the g_mass_storage USB gadget module and point it at that LUKS device (modprobe g_mass_storage file=/dev/mapper/securestick) That's basically it, for testing it can be done very easily without scripting. The end result is a transparent encryption device for USB drives. Plug the beaglebone in to a laptop's USB port and it will show a standard USB mass storage device available for formatting and mounting, unaware that the actual storage is encrypted, and neither the password or LUKS master key will ever be in the laptops RAM (a useful property of this setup). This could of course be automated with some scripting, and made quite fancy (touchscreen keyboard to unlock the LUKS stick at boot time and load that gadget module properly). Some beaglebone distros load a gadget module at boot time with their own scripts, but it should be possible to automatically unload it where that is the case.

by konradb 12y ago

vidarh 12y ago

She is talking about the SD cards in her camera, presumably. I don't know if you can get cameras that supports encrypting the images as they're written, but it's not unreasonable that she wouldn't have one, and not unreasonable that she'd be reluctant to trust whether or not formatting/overwriting the SD card would be sufficient to prevent recovery.

raverbashing 12y ago
I guess some overwrites should be enough for i in $(seq 1 1000); do if=/dev/urandom of=/dev/sdc bs=$((1024 * 1024)) count=(SD size in MB); done
- josephlord 12y ago
  Actually what if one of the blocks used for the critical data was deemed degraded and removed from the pool and replaced with a reserve before it was overwritten. No way to delete then although expensive to retrieve it might be possible. Depends on the capability of your opponent and the consequences if your guess is wrong.
  - raverbashing 12y ago
    Yeah, also block size, I'm not sure how big they usually are. 512 bytes should be ok (for a picture), if it's bigger I'd be more worried Might be easier to microwave the SD card
    - nitrogen 12y ago
      Flash uses pretty large block sizes (look up specs for write size and erase size for common flash media; it's often 4KB writes+128KB erases), and the wear leveling algorithm can unpredictably shuffle the writes around. Your final paragraph is probably the only safe way to know an SD card's internal flash is unrecoverable, followed by physical destruction.
- abandonliberty 12y ago
  Securely erasing flash memory is surprisingly hard. >Whole-disk wiping techniques faired only slightly better with SSD media. In the most extreme case, one unnamed SSD model still stored 1 percent of its 1 GB of data even after 20 sequential overwrite passes on the entire device. http://www.theregister.co.uk/2011/02/21/flash_drive_erasing_peril/ http://www.theregister.co.uk/2011/02/21/flash_drive_erasing_... I wonder how hard it is on SD drives. Meanwhile this forum claims the NSA mandates physical destruction https://discussions.apple.com/docs/DOC-5521 https://discussions.apple.com/docs/DOC-5521
dublinben 12y ago
This sounds like a great unmet opportunity to create a camera for journalists that encrypts every picture to a public key that only your editor (presumably in a safe location) has the private key to decrypt.
- marcosdumay 12y ago
  And instantly uploads it (or at least, as soon as the camera is plugged to a phone).
  - vidarh 12y ago
    That part you can handle with a Transcend or Eyefi wifi-enabled SD-card. The Transcend cards have also been thoroughly hacked so they can be fairly easily customized.
- gglitch 12y ago
  Excellent idea. For journalists - or just for citizens who happen to be standing around in the wrong place at the right time.
- MichaelGG 12y ago
  Some cameras have open-ish firmware so it sounds easy enough to add. Unfortunately, the big SLRs from Canon and Nikon have terrible firmware run by an organization that's stuck in the 80s or worse with the typical poor level of software hardware companies are known for.
  - anigbrowl 12y ago
    Actually Canon makes their SDK freely available and while they don't let you fork the operating system there's an open-source alternative called Magic Lantern that works very well on most of their DSLR range and adds a lot of functionality (as well as providing a lot of reverse engineering info on their hardware through the site). Canon hasn't officially blessed this, but they haven't obstructed them in any way. The main problem with adding encryption would be that photos and video can consume a lot of bandwidth, and the bandwidth inside a digital camera is limited, as is the processing power. It would make more sense to put the encryption directly on the media card, similar to the fashion in which Eye-fi cards include a tiny CPU and web server to automatically offload the content to a trusted network.

griffordson 12y ago

I assume she's talking about the media used by her cameras. As in, the cameras store the raw data on SD cards in an unencrypted format.

mrsteveman1 12y ago

They do actually, but it's part of a DRM system [1] rather than something that would be trustworthy for privacy and file security purposes. It's apparently still being used by some Windows Phone devices. More on topic though, while there may not be a "simple" or trustworthy solution using built-in encryption on cameras or SD cards, it should be possible to create a (small, or "prototype sized but usable") device to sit in the middle of the electrical connections of the SD slot on any camera, and a normal SD card. The device would transparently encrypt video footage or pictures sent to the card. Would be an interesting side project. I've used the Beaglebone's USB client and host ports, along with the Linux USB gadget drivers and LUKS, to do something similar to transparently encrypt USB sticks, it wasn't particularly fast (8-9MB/s) but it was usable :) [1] http://en.wikipedia.org/wiki/Secure_Digital#DRM_copy-protection http://en.wikipedia.org/wiki/Secure_Digital#DRM_copy-protect...

nitrogen 12y ago
Do you have a git repo or blog post with code/info about your Beaglebone passthrough setup? I wanted to do something similar a while ago but never got to it.
- mrsteveman1 12y ago
  I may have written a tiny script to automate part of it at the time but I probably just did it all manually as it's quite simple. I haven't setup a blog for this sort of thing yet, but the minimum steps required to make it work is just a few high level commands: 1) Create a LUKS volume on a connected USB stick/drive (cryptsetup luksFormat /dev/sda1) 2) Open the LUKS volume with a standard name for step 3 to use (cryptsetup luksOpen /dev/sda1 securestick) 3) Load the g_mass_storage USB gadget module and point it at that LUKS device (modprobe g_mass_storage file=/dev/mapper/securestick) That's basically it, for testing it can be done very easily without scripting. The end result is a transparent encryption device for USB drives. Plug the beaglebone in to a laptop's USB port and it will show a standard USB mass storage device available for formatting and mounting, unaware that the actual storage is encrypted, and neither the password or LUKS master key will ever be in the laptops RAM (a useful property of this setup). This could of course be automated with some scripting, and made quite fancy (touchscreen keyboard to unlock the LUKS stick at boot time and load that gadget module properly). Some beaglebone distros load a gadget module at boot time with their own scripts, but it should be possible to automatically unload it where that is the case.