You have no control over how an adversary accesses the drive, so no.
this post was submitted on 01 Jul 2023
1 points (100.0% liked)
Linux
1257 readers
56 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
However, if it's enough to erase the data if wrong key is entered AND the original operating system is running it should be possible. But I agree, that limitation doesn't really make sense in a security point of view.
Besides that, I believe that luks encryption with sufficiently complex password (and updates) is practically the same than empty drive for the attacker. More interesting setup would be to give out different data depending on which key is given, there was some windows-based software which could do that back in the day, I'm not sure if it's still around and don't remember the name for it right now.
It would at least add a layer of obfuscation if someone extorts a key from the owner.
If the decryption key is unavailable, the data is as good as wiped already, right? It's unreadable.
I'm guessing you're attempting to mitigate against a brute force attack. I think the 'stock' answer to that would be to ensure you're using a complicated enough pass phrase (I think the current best practice on this is >12 characters with the usual upper, lower, character, number combo can take thousands of years to crack, see here: https://www.security.org/how-secure-is-my-password/) or use a hardware token.
Doesn't LUKS lock out any attempts for 60 seconds after 3 attempts anyway? That's a huge blocker in the way for brute forcing. That's 180 attempts in an hour, 4320 a day, etc. It'll take a long time.
If you're truly looking to wipe, I think you'd need to execute something at the OS level once unlocked/booted to detect incorrect attempts (if attempt >3; then dd if=/dev/zero of=/dev/YourDevice bs=2M or similar).
Have a look at response 5.21 on why LUKS does not include the nuke option: https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions
Doesn’t LUKS lock out any attempts for 60 seconds after 3 attempts anyway? That’s a huge blocker in the way for brute forcing. That’s 180 attempts in an hour, 4320 a day, etc. It’ll take a long time.
The prompt running on (many) distributions boot has a time limit, but if you pull the drive and plug it into another host (or boot from USB) the limitation doesn't exist.
If you’re truly looking to wipe, I think you’d need to execute something at the OS level once unlocked/booted to detect incorrect attempts (if attempt >3; then dd if=/dev/zero of=/dev/YourDevice bs=2M or similar).
You could bake that into init scripts since the kernel is already running. On the same spot where the time delay triggers you could just wipe the drive instead of prompting to wait until receiving new password. But that still leaves the option to pull the drive physically into another host and do whatever you like with it since the wiping code on the drive wouldn't/couldn't execute.