this post was submitted on 27 Nov 2024
255 points (95.7% liked)
Technology
59772 readers
3191 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Yes, failing to safeguard keys is fatal, but that applies to everything. But if fs you're storing keys on is behind luks and they're readable by root only - you're as safe enough. There're also LSMs like selinux that can increase the complexity of attack.
I don't know about nitrokey specifically, but TPM is an option (not good enough, imo) and a simple luks encrypted usb. You could get some convenience by storing the key to unlock it somewhere on the encrypted root.
In general - you cannot stop a targeted attack no matter what, but staying safe from all the automated ones is doable.
They are stored behind luks and I think they are readable only by root. But bootkit can probably only infect UEFI from Linux that is running on that machine. And to interact to UEFI you probably have to be root, right?
I'll look into more options, either store keys on a seperate luks usb key or on a hardware securety key like Nitrokey. For
sbctl
there is already a roadmap feature for hardware security keys, I hope this comes soon :)