cryptboot
tpm2-totp
cryptboot | tpm2-totp | |
---|---|---|
5 | 5 | |
199 | 149 | |
- | 7.4% | |
0.0 | 0.0 | |
5 months ago | about 1 month ago | |
Shell | C | |
GNU General Public License v3.0 only | BSD 3-clause "New" or "Revised" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
cryptboot
-
Setting up Secure Boot, but the wiki doesn't provide enough info I think
I just completely cheated by using cryptboot. Then it is as simple as cryptboot-efikeys create, then to enroll them into your eufi, cryptboot-efikeys enroll and finally to sign any efi executable (or any file), cryptboot-efikeys sign $FILE. There are other helper scripts, but I don't use them. Full documentation is on their GitHub: https://github.com/xmikos/cryptboot. Good luck!
- Authenticated Boot and Disk Encryption on Linux
-
Physical security tips & recommendations
Prevent evil maid by bringing your devices everywhere. Or you can just switch to GNU/Linux and add https://github.com/xmikos/cryptboot
-
Unencrypted boot partition risks
I think it was this one: https://github.com/xmikos/cryptboot
-
Cool new things on linux world for fresh installation and a bit of my usage different things.
Also, I am pretty sure that you can only have encrypted /boot if you use GRUB. The point of doing so is not really to make sure nobody reads it (there isn't anything interesting on /boot by default), but to make sure that nobody can tamper with it (ignoring the encryption vs authenticated encryption discussion). However, you still have to make sure nobody can tamper with GRUB itself. You might want to check out https://github.com/xmikos/cryptboot if this sounds interesting. Also, there are similar solutions that don't use encrypted /boot, for example booting from signed EFISTUBs, see https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface/Secure_Boot#Implementing_Secure_Boot. Also, I don't actually use this kind of setup personally (albeit I'd like to one day), and I am certainly not a security expert, so take this whole paragraph with a big grain of salt, and double check with somebody who actually knows what they are talking about.
tpm2-totp
-
TOTP tokens on my wrist with the smartest dumb watch
You need a TPM 2.0 compatible CPU, but something like this sounds really excellent: https://github.com/tpm2-software/tpm2-totp
This means your laptop itself would be your hardware device, the TOTP secret would be stored in the TPM and theoretically impossible to steal/copy. Of course this means you will probably want a mobile device (possibly a second laptop also) as a backup.)
- Can you detect tampering in /boot without SecureBoot on Linux?
-
Authenticated Boot and Disk Encryption on Linux
>But okay, you may extend my attack by saying that you exchange the motherboard between the victim and the attacker laptop, so that you don't need to replicate the chassis.
Modern computers has tamper detection and if you open them you'll need to type the BIOS password.
However, replacing the motherboard is going to replace the TPM. This is easily detectable with something like tpm2_totp in the bootchain.
https://github.com/tpm2-software/tpm2-totp
- Attest computer secure boot state to phone via time-based OTP and TPM
-
Does the TPM boost secure boot security?
You could also use TOTP for a kind of remote attestation (e.g., with your phone computing TOTP). In this setup, the CPU sends the timestamp to the TPM, and it returns the TOTP value. So instead of you looking at your phone to give the TOTP to a service provider to prove that you're in possession of your phone, the computer gives you a TOTP value to prove that it's in possession (inside the TPM, sealed to the boot chain hashes) of the TOTP secret, and you use your phone to verify this. A possible weakness (short of a full-blown TPM compromise) would be to send a bunch of forged timestamps to the TPM while your computer is running and store the resulting TOTP values, then tamper with Secure Boot and emit the precomputed TOTP corresponding to the current timestamp whenever you boot up your computer. But this would require running malicious code on your compute while you're logged in with the trusted boot chain.
What are some alternatives?
sbctl - :computer: :lock: :key: Secure Boot key manager
dotfiles - :unicorn: My personal dotfiles
mortar - Framework to join Linux's physical security bricks.
heads - A minimal Linux that runs as a coreboot or LinuxBoot ROM payload to provide a secure, flexible boot environment for laptops, workstations and servers.
btrfs-todo - An issues only repo to organize our TODO items
safeboot - Scripts to slightly improve the security of the Linux boot process with UEFI Secure Boot and TPM support
sbupdate - Generate and sign kernel images for UEFI Secure Boot on Arch Linux
decrypt-otpauth-files - Decrypt files created by OTP Auth
BangleApps - Bangle.js App Loader (and Apps)