1

I am working on a group project to have encrypted data on a BeagleBone Black without WiFi (however we will be connecting it to the internet) where you have to type in a password to access it and if you get the password wrong three times it will delete all the data. However you can get around this by imaging the computer and brute forcing the image.

I was wondering if anyone knew how to stop that? Or if they knew another way stop the problem?

schroeder
  • 125,553
  • 55
  • 289
  • 326
dylanphippsyahoocouk
  • 11
  • 1
  • 1
    Full-disk encryption? – Polynomial Feb 26 '19 at 17:43
  • 1
    What is your specific threat model? Are you trying to prevent against a remote attacker, or someone who has physical access to the machine? – Dan Landberg Feb 26 '19 at 17:56
  • Using a trusted platform module (TPM) or equivalent and full disk encryption it may be possible. The beaglebone black doesn't have one built-in, but a quick search gives a few modules which can be added – Torin Feb 26 '19 at 19:49
  • Is the device on while being attacked? If so, JTAG can bypass any security measures you put in place. – forest Feb 27 '19 at 03:26

2 Answers2

1

If you don't want someone to steal the BeagleBone and bruteforce it, you can encrypt the whole disk and keep the key online.

You could write a custom program to send the password to your server, and have the server send back the key to decrypt the disk. If someone submits the wrong password a couple times, consider the computer stolen and erase the key. This way you can delete the key even before someone tries the wrong password.

ThoriumBR
  • 51,983
  • 13
  • 131
  • 149
0

While others have responded with valid methods such as full-disk encryption. I would not exactly say this prevents disk imaging. Equally, if an adversary has direct access over your machine with unlimited time and money; game over!

So, cloning the physical disk cannot be prevented using software, but mitigating the chance an adversary will successfully brute-force the master-password with limited resources (time and money) and hence access the decrypted contents can be reduced. If using LUKS consider increasing the number of rounds (iteration count) and key-size. So, we consider the following changes to the default LUKS deployment, remember these changes are done regarding your hardware with respect to your adversaries resources:

Regarding wiping all data on your drive after using LUKS consider overwriting the LUKS header rather than all data as this will be quicker. Arch Linux has fairly extensive documentation regarding overriding the header, but consider using something more extensive like DoD 5220.22-M or Gutmann method for overwriting the necessary portion of the LUKS header. Also, do consider the necessary risks when overwriting data on an SSD.

Hack.lu 2015 CTF Write Up: Dr. Bob (Forensic 150)

While some alternative methods could be deployed because the Beaglebone Black uses eMMC memory. They would be classified as secrecy through obscurity which is NOT something we aim for here. So, without deploying something like a TPM, LUKS will be a viable alternative. However, as I understand the LUKS header can be placed on a USB drive. This would allow you to boot the Beaglebone Black, and once decrypted remove the USB drive with the LUKS header and if anyone has physical access to the machine, they would need to extract the decryption keys from RAM (not viable on Beaglebone Black). Otherwise, if the machine is rebooted or powered off, it will be encrypted (as the decryption keys were stored in RAM) and the LUKS header is stored on a USB drive. Hence, nothing can be brute-forced without the USB drive.

safesploit
  • 1,847
  • 8
  • 18
  • LUKS _does_ use AES-256 in XTS mode by default, and as your link points out, there's no point in increasing the number of rounds if you already have more entropy than the key size. 512 bits is pointless, and at 256 bits you should be _decreasing_ the number of rounds if anything. – AndrolGenhald Feb 26 '19 at 22:38
  • @AndrolGenhald XTS mode gives about 384 bits of effective keyspace because it operates a bit like the Even-Mansour cipher construction. It would be 512 bits, but a meet-in-the-middle attack brings it to 384 bits. See [Is XTS basically the cheapest form of (secure) double-encryption?](https://crypto.stackexchange.com/q/30212/54184) on [crypto.se]. – forest Feb 27 '19 at 03:24
  • 1
    @safesploit The Gutmann erasure method is snakeoil and is completely useless on modern drives. In fact, erasure in general is not possible to do securely on eMMC storage. – forest Feb 27 '19 at 08:17
  • @forest I'd forgotten about the weirdness with XTS. Still, if LUKS is given 256 bits of entropy I wouldn't worry about it. – AndrolGenhald Feb 27 '19 at 14:12
  • @AndrolGenhald XTS does concern me in this manner, this is why I prefer to provide references as you've done. As I am trying to avoid leading people into a 'false sense of security'. I appreciate the clarification. – safesploit Feb 28 '19 at 15:12
  • @forest That is a valid point. I am hesitant when advising people about overwriting data on flash memory due to this. It becomes very emergent when Kingston and Samsung were both deploying their proprietary tools for overwriting data on their respective SSDs. Which does not inspire me with confidence when I am 'locked into a particular drive' because of security concerns that might emerge if I swapped. Thanks for the further elucidation. – safesploit Feb 28 '19 at 15:17
  • Thanks for the help I am thinking of using a full encryption with half the key on each beagle bone and thanks for the advice with LUKS – dylanphippsyahoocouk Mar 01 '19 at 12:44