You linked to a post about a physical attack vector on an SoC which is entirely applicable to a Linux installation. The post is also dishonest and pushing misinformation, but you're misunderstanding it if you think Linux is better. Linux is far more vulnerable to the same attack.
Conversation
The mitigations implemented in the Trezor firmware against the attack wouldn't be present, and there would be drastically more attack surface. An attacker could much more easily gain code execution. An air gap doesn't remove online attack vectors at all.
1
It still needs to be kept updated too, and there would be massive attack surface simply for that. Simple update verification, full verified boot and downgrade protection with minimal state are important. The entire point is not having the attack surface of a general purpose OS.
1
1
I think you're just misinterpreting that post and drawing the wrong conclusions. It's about a hardware attack, and a general purpose computer running Linux is far more vulnerable to the same kind of attacks. It ignores the passphrase feature and is unnecessarily dishonest too.
2
1
It's far better to not have a general purpose OS when it's totally unnecessary. Only a tiny embedded application with thousands of lines of code, not millions, is needed. Running that tiny application on top of a massive general purpose OS would be a step backward in every way.
1
1
I completely agree with - this is the wrong conclusion. Hardware keys are the go to for maximum security. Your 'no' responses are incorrect for "implementation of software or device 100% Libre Software" and "can be independently reproduced and audited".
1
1
1
The comparison table is wrong when it comes to Nitrokey Start / Gnuk. Keys are encrypted, it is 100% libre software, can be audited, auditing isn't harder than GnuPG.
2
2
I mentioned the Trezor earlier particularly Model T where passphrase and recovery seed can be entered on it directly. It has a different model than a typical HSM since it doesn't store anything other than the seed which is combined with entered passphrases to derive wallets/keys.
1
It doesn't include any proprietary software and the whole thing is an open design that other people are able to build (and have successfully done so in practice). The primary purpose is for cryptocurrency wallets but it works well for U2F, GPG, SSH and various other purposes too.
1
There are definitely options beyond proprietary ones, including options with much different approaches than a traditional HSM storing the keys with / without encryption (ideally with a passphrase entered onto the device). I really like the approach pioneered for Bitcoin wallets.
1
1
Since that lets you generate keys on the hardware wallet, back up the high entropy recovery seed as a phrase, verify you backed it up correctly and then if you need to recover on a new device you can enter it directly onto a new hardware wallet without exposing it to a computer.
The traditional approach is good if you have existing SSH and GPG keys that need to be moved onto an HSM. I'll definitely prefer the deterministic wallet approach for new keys though. It's not that bad to migrate to new SSH keys but GPG tends to make rotating keys very painful.
1
Signing keys for firmware usually can't be rotated at all since they're burned into fuses so that's another case where a more traditional HSM is the best option since existing keys need to be migrated. Android app signing keys were similar, but they've finally added key rotation.
1
Show replies