5 ms·

An encrypted disk would be kind of useless in such a device as it would require the user to login every time the device reboots, unless they intend for it to ne

An encrypted disk would be kind of useless in such a device as it would require the user to login every time the device reboots, unless they intend for it to never be rebooted. I’m not sure what you mean by network key in this case.

sneak 5y ago
No, you can have the initrd boot to a dropbear sshd that allows the operator to ssh in on reboots and provide the key.
- suifbwish 5y ago
  Wouldn’t that part of the disk then need to be unencrypted?
  - sneak 5y ago
    Yes, it does. It's pretty small, though, on the order of 100MB.
- andrewnicolalde 5y ago
  There are also options like the Zymkey[1] which is essentially an add-on TPM which can auto-decrypt the disk if it detects that the Raspberry Pi and SD card it is connected to have not changed. Not sure how difficult that would really be to defeat given enough effort though. [1] https://www.zymbit.com/zymkey/ https://www.zymbit.com/zymkey/
- fho 5y ago
  If you count on the device running "forever", or at least until you pick it up again, you could also just store the key on the device and delete/destroy it (the key) on boot.
  - asteroidp 5y ago
    Why in god's name would you pick it up later? Installing it in the first place was a huge risk. Removing it is just doubling down
- Severian 5y ago
  Something like dnscat2 would ultimately be better in my opinion. Have it connect once to get the disk key, decrypt, and end the process. Then have your device do it's thing, and once a condition is met, spin it back up, transmit the data (using small packet sizes and very large delays to possibly avoid IDS) and exfiltrate what's needed.
teddyh 5y ago
> An encrypted disk would be kind of useless in such a device as it would require the user to login every time the device reboots There is actually a solution for that (shameless plug): https://www.recompile.se/mandos https://www.recompile.se/mandos
- natpalmer1776 5y ago
  While I'm sure I could configure this on a system, the level of understanding required to actually create it honestly is fantastic. Is this something you created yourself, or was it a community project?
  - teddyh 5y ago
    Initial idea and C++ implementation (using TLS with X.509 certificates and explicit UDP broadcasts) was done in 2007 by another person. Redesign of the protocol (to TLS with OpenPGP keys¹ and DNS Service Discovery²), and re-implementation in Python and C, I did in collaboration with that person. In addition to ongoing maintenance, the relatively recent switch from TLS with OpenPGP keys to TLS with Raw Public Keys³ was done by me. The level of understanding required is something I would think that all system administrators worth their salt had at the time. I would think that the best way to acquire such knowledge is doing the Linux From Scratch⁴ exercise, even though I have not done it myself. 1. RFC 6091 2. http://www.dns-sd.org/ http://www.dns-sd.org/, RFC 6763 3. RFC 7250 4. https://www.linuxfromscratch.org/lfs/ https://www.linuxfromscratch.org/lfs/
    - Inhibit 5y ago
      That looks like an awesome project but I'm not sure building an LFS system would help developing a system like that. Possibly in understanding and configuring it. I still recall how to build a Linux system from go. Coding what you're working on up in Python/C would take a large unrelated amount of knowledge.
      - teddyh 5y ago
        The knowledge about how to write a program comes naturally when you know, in fine enough detail, both the problem which the program should solve, how to solve it, and the environment in which the program should run. In this case, writing a Python server program to respond to requests was relatively simple; Python provides built-in modules which makes writing servers easy. And when you know what the client program (i.e. the program running on the currently locked host) should do, and you know what environment the program has to operate in, the program more or less writes itself. The first version of the program used a simple UDP broadcasting method to a hard-coded port to find servers, which required some rudimentary networking knowledge, but only basic TCP/IP stuff. Later, both the server and client parts have gone through numerous refactorings which brought in many features (like a plugin system on the client side, and a D-Bus interface on the server side), but those were manageable chunks to add to an already mature and working system. But sure, in addition to the knowledge one could acquire from LFS, I also had some high-level knowledge of how TLS and its handshake worked, I knew that there was some way to use OpenPGP keys instead of X.509 certificates in TLS, and I knew a little about how DNS-SD worked. The rest I needed I read up on as I wrote the code.

sneak 5y ago

No, you can have the initrd boot to a dropbear sshd that allows the operator to ssh in on reboots and provide the key.

suifbwish 5y ago
Wouldn’t that part of the disk then need to be unencrypted?
- sneak 5y ago
  Yes, it does. It's pretty small, though, on the order of 100MB.
andrewnicolalde 5y ago
There are also options like the Zymkey[1] which is essentially an add-on TPM which can auto-decrypt the disk if it detects that the Raspberry Pi and SD card it is connected to have not changed. Not sure how difficult that would really be to defeat given enough effort though. [1] https://www.zymbit.com/zymkey/ https://www.zymbit.com/zymkey/
fho 5y ago
If you count on the device running "forever", or at least until you pick it up again, you could also just store the key on the device and delete/destroy it (the key) on boot.
- asteroidp 5y ago
  Why in god's name would you pick it up later? Installing it in the first place was a huge risk. Removing it is just doubling down
Severian 5y ago
Something like dnscat2 would ultimately be better in my opinion. Have it connect once to get the disk key, decrypt, and end the process. Then have your device do it's thing, and once a condition is met, spin it back up, transmit the data (using small packet sizes and very large delays to possibly avoid IDS) and exfiltrate what's needed.

teddyh 5y ago

> An encrypted disk would be kind of useless in such a device as it would require the user to login every time the device reboots There is actually a solution for that (shameless plug): https://www.recompile.se/mandos https://www.recompile.se/mandos

natpalmer1776 5y ago
While I'm sure I could configure this on a system, the level of understanding required to actually create it honestly is fantastic. Is this something you created yourself, or was it a community project?
- teddyh 5y ago
  Initial idea and C++ implementation (using TLS with X.509 certificates and explicit UDP broadcasts) was done in 2007 by another person. Redesign of the protocol (to TLS with OpenPGP keys¹ and DNS Service Discovery²), and re-implementation in Python and C, I did in collaboration with that person. In addition to ongoing maintenance, the relatively recent switch from TLS with OpenPGP keys to TLS with Raw Public Keys³ was done by me. The level of understanding required is something I would think that all system administrators worth their salt had at the time. I would think that the best way to acquire such knowledge is doing the Linux From Scratch⁴ exercise, even though I have not done it myself. 1. RFC 6091 2. http://www.dns-sd.org/ http://www.dns-sd.org/, RFC 6763 3. RFC 7250 4. https://www.linuxfromscratch.org/lfs/ https://www.linuxfromscratch.org/lfs/
  - Inhibit 5y ago
    That looks like an awesome project but I'm not sure building an LFS system would help developing a system like that. Possibly in understanding and configuring it. I still recall how to build a Linux system from go. Coding what you're working on up in Python/C would take a large unrelated amount of knowledge.
    - teddyh 5y ago
      The knowledge about how to write a program comes naturally when you know, in fine enough detail, both the problem which the program should solve, how to solve it, and the environment in which the program should run. In this case, writing a Python server program to respond to requests was relatively simple; Python provides built-in modules which makes writing servers easy. And when you know what the client program (i.e. the program running on the currently locked host) should do, and you know what environment the program has to operate in, the program more or less writes itself. The first version of the program used a simple UDP broadcasting method to a hard-coded port to find servers, which required some rudimentary networking knowledge, but only basic TCP/IP stuff. Later, both the server and client parts have gone through numerous refactorings which brought in many features (like a plugin system on the client side, and a D-Bus interface on the server side), but those were manageable chunks to add to an already mature and working system. But sure, in addition to the knowledge one could acquire from LFS, I also had some high-level knowledge of how TLS and its handshake worked, I knew that there was some way to use OpenPGP keys instead of X.509 certificates in TLS, and I knew a little about how DNS-SD worked. The rest I needed I read up on as I wrote the code.