4 ms·

source of quote: https://www.wired.com/2014/09/the-fbi-finally-says-how-it-legally-pinpointed-silk-roads-server/ https://www.wired.com/2014/09/the-fbi-finally-s

source of quote: https://www.wired.com/2014/09/the-fbi-finally-says-how-it-legally-pinpointed-silk-roads-server/ https://www.wired.com/2014/09/the-fbi-finally-says-how-it-le... additional: https://nakedsecurity.sophos.com/2014/10/10/fbis-warrantless-hack-of-silk-road-was-legal-prosecutors-claim/ https://nakedsecurity.sophos.com/2014/10/10/fbis-warrantless... > If the server uses full-disk encryption, and if it's well locked down, it would be nontrivial to secretly access and copy the server's data. OP's article mentions this, part of the reason they move out of the US is because RAM can be trivially read even if full disk encryption is used. Reading RAM still works in Iceland.

mirimir 8y ago
Thanks. > RAM can be trivially read even if full disk encryption is used I wouldn't say "trivially", but yes, it can be. But if you're that paranoid, you can embed key parts of the motherboard in alumina-filled epoxy. Its thermal conductivity is good, and you can add fins and fans as needed. You can even embed trip wires in the epoxy, to trigger system shutdown if tampered with.
- dylz 8y ago
  They're running on VMs, not bare metal, presumably, because their (new) server's reverse DNS is vps-*, and previously on Digitalocean. You can just dump the VM's memory space while unlocked, can't you? A lot of this seems like security theater, especially while still hosted behind Cloudflare.
  - mirimir 8y ago
    Oops. Yeah, here it does seem security theater. But still, it was a good writeup. I mean, dropbear and all. I have no clue why they're using VPS, after all that. I mean, if they're a real business, they ought to just setup a server, and ship it to Iceland. If the want the ease of VPS, it's easy to do secure KVM in a FDE server. Even with Docker containers within KVM, if you like.
    - philliphaydon 8y ago
      “If they’re a real business” - this is the sort of dribble HN is reduced to? A real business can’t run on a VPS?
      - hal009 8y ago
        I believe the point here is that they claim that they care about security, while their Icelandic VPS hosting provider can just dump the host server memory, which would include the encryption keys.
        philliphaydon 8y ago
        Then can’t we say that? “If they truly cared about security they wouldn’t use a VPS”. It just rubs me the wrong way the way it’s worded.
        mirimir 8y ago
        Yes, I should have been clearer. Sorry.
        harianus 8y ago
        This is a good point. We are moving to a dedicated server to resolve this issue.
        mirimir 8y ago
        Nice :) You probably know this, but anyway. If you're setting up FDE with dropbear on a remote server, it's best to build the installer on the machine.
      - mirimir 8y ago
        It's not that a "real business" that talks about FDE, and has moved to Iceland for better security, can't run on hosted VPS. But they're being disingenuous if they do so. But what I mainly meant is that a "real business" can afford to build secure servers, ship them to Iceland, and send trusted staff to set up and configure them.
- danieltillett 8y ago
  Anyone doing this commercially?
  - mirimir 8y ago
    I have no clue. Stuff like that has been standard in the banking industry for decades. I've done it in my workshop.
- auslander 8y ago
  Evil mastermind, supervillains level :) I dig around. So to remotely unlock LUKS, on bare-metal in datacenter, one can use custom initramfs, like https://github.com/mtth-bfft/dracut-dropbear-unlock https://github.com/mtth-bfft/dracut-dropbear-unlock But still "boot time SSH server's key is stored unencrypted, man-in-the-middle attacks can also be carried out to recover the encryption key at boot time". Ideas?
  - mirimir 8y ago
    The full quote: > Full-disk encryption doesn't protect you against someone with physical access to the machine: the encryption key can be recovered from RAM at runtime (e.g. cold boot attacks), and since the boot time SSH server's key is stored unencrypted, man-in-the-middle attacks can also be carried out to recover the encryption key at boot time. Consider this in your threat model. So yes, for "Evil mastermind, supervillains level" you gotta embed the RAM, and everything that would give adversaries physical access to the RAM, in alumina-filled epoxy. Or better, alumina-and-fiberglass-filled epoxy. The alumina gives you heat condictivity, and the fiberglass strength. Plus embedded trip wires to nuke the board if they're cut. It's also prudent to disconnect all ports from the board, except for the NIC, and embed everything that could be used to reconnect them. With that, it'd be very difficult to get anything from RAM. Attempts at physical access would destroy the system.
    - auslander 8y ago
      But is the storage hdd/ssd epoxied too? The ssh keys to do MITM are in cleartext on boot partition... FBI can put their box on your server's IP, and you'll happily connect, same fingerprint, and type unlock and passphrase.
      - mirimir 8y ago
        Sorry. Wasn't thinking clearly. I guess that you'd need to embed the SSD(s) too. But I wonder if there's a way to reproducibly generate SSH key pairs from hardware IDs. That way, there'd be no keys stored in /boot, and they'd be generated at each boot. So only your hardware would have the right keys.
- caprese 8y ago
  is anybody doing a solution for this? like some software that floods all the RAM and memory caches with erroneous data, and then the hardware solution of the epoxy trip wires.
  - mirimir 8y ago
    Whenever LUKS is decrypted, the key must remain available. Otherwise, the system can't access anything. If you search about recovering stuff from RAM, you'll find some approaches for obfuscating LUKS keys. But ultimately, they (or the way to access them) must be in RAM somewhere. I think, anyway. For the trip wires thing, you can just have them apply 5VDC to the wrong RAM pins. And then, if you wanted to recover the motherboard, you'd need to chip out stuff, and replace it. But it's probably only the CPU that'd be worth recovering. And maybe you'd want to embed that too, just in case.

mirimir 8y ago

Thanks. > RAM can be trivially read even if full disk encryption is used I wouldn't say "trivially", but yes, it can be. But if you're that paranoid, you can embed key parts of the motherboard in alumina-filled epoxy. Its thermal conductivity is good, and you can add fins and fans as needed. You can even embed trip wires in the epoxy, to trigger system shutdown if tampered with.

dylz 8y ago
They're running on VMs, not bare metal, presumably, because their (new) server's reverse DNS is vps-*, and previously on Digitalocean. You can just dump the VM's memory space while unlocked, can't you? A lot of this seems like security theater, especially while still hosted behind Cloudflare.
- mirimir 8y ago
  Oops. Yeah, here it does seem security theater. But still, it was a good writeup. I mean, dropbear and all. I have no clue why they're using VPS, after all that. I mean, if they're a real business, they ought to just setup a server, and ship it to Iceland. If the want the ease of VPS, it's easy to do secure KVM in a FDE server. Even with Docker containers within KVM, if you like.
  - philliphaydon 8y ago
    “If they’re a real business” - this is the sort of dribble HN is reduced to? A real business can’t run on a VPS?
    - hal009 8y ago
      I believe the point here is that they claim that they care about security, while their Icelandic VPS hosting provider can just dump the host server memory, which would include the encryption keys.
      - philliphaydon 8y ago
        Then can’t we say that? “If they truly cared about security they wouldn’t use a VPS”. It just rubs me the wrong way the way it’s worded.
        mirimir 8y ago
        Yes, I should have been clearer. Sorry.
      - harianus 8y ago
        This is a good point. We are moving to a dedicated server to resolve this issue.
        mirimir 8y ago
        Nice :) You probably know this, but anyway. If you're setting up FDE with dropbear on a remote server, it's best to build the installer on the machine.
    - mirimir 8y ago
      It's not that a "real business" that talks about FDE, and has moved to Iceland for better security, can't run on hosted VPS. But they're being disingenuous if they do so. But what I mainly meant is that a "real business" can afford to build secure servers, ship them to Iceland, and send trusted staff to set up and configure them.
danieltillett 8y ago
Anyone doing this commercially?
- mirimir 8y ago
  I have no clue. Stuff like that has been standard in the banking industry for decades. I've done it in my workshop.
auslander 8y ago
Evil mastermind, supervillains level :) I dig around. So to remotely unlock LUKS, on bare-metal in datacenter, one can use custom initramfs, like https://github.com/mtth-bfft/dracut-dropbear-unlock https://github.com/mtth-bfft/dracut-dropbear-unlock But still "boot time SSH server's key is stored unencrypted, man-in-the-middle attacks can also be carried out to recover the encryption key at boot time". Ideas?
- mirimir 8y ago
  The full quote: > Full-disk encryption doesn't protect you against someone with physical access to the machine: the encryption key can be recovered from RAM at runtime (e.g. cold boot attacks), and since the boot time SSH server's key is stored unencrypted, man-in-the-middle attacks can also be carried out to recover the encryption key at boot time. Consider this in your threat model. So yes, for "Evil mastermind, supervillains level" you gotta embed the RAM, and everything that would give adversaries physical access to the RAM, in alumina-filled epoxy. Or better, alumina-and-fiberglass-filled epoxy. The alumina gives you heat condictivity, and the fiberglass strength. Plus embedded trip wires to nuke the board if they're cut. It's also prudent to disconnect all ports from the board, except for the NIC, and embed everything that could be used to reconnect them. With that, it'd be very difficult to get anything from RAM. Attempts at physical access would destroy the system.
  - auslander 8y ago
    But is the storage hdd/ssd epoxied too? The ssh keys to do MITM are in cleartext on boot partition... FBI can put their box on your server's IP, and you'll happily connect, same fingerprint, and type unlock and passphrase.
    - mirimir 8y ago
      Sorry. Wasn't thinking clearly. I guess that you'd need to embed the SSD(s) too. But I wonder if there's a way to reproducibly generate SSH key pairs from hardware IDs. That way, there'd be no keys stored in /boot, and they'd be generated at each boot. So only your hardware would have the right keys.
caprese 8y ago
is anybody doing a solution for this? like some software that floods all the RAM and memory caches with erroneous data, and then the hardware solution of the epoxy trip wires.
- mirimir 8y ago
  Whenever LUKS is decrypted, the key must remain available. Otherwise, the system can't access anything. If you search about recovering stuff from RAM, you'll find some approaches for obfuscating LUKS keys. But ultimately, they (or the way to access them) must be in RAM somewhere. I think, anyway. For the trip wires thing, you can just have them apply 5VDC to the wrong RAM pins. And then, if you wanted to recover the motherboard, you'd need to chip out stuff, and replace it. But it's probably only the CPU that'd be worth recovering. And maybe you'd want to embed that too, just in case.