It is dramatically less secure. That's the reality, sorry. It has massive attack surface and the proposed usage of encryption loses the nice properties of the passphrase implementation. You could of course use software with a similar approach on it but it doesn't change the rest.
Conversation
If you feel this way and it fits your real world sec asumptions and models, enjoy ☺ It doesnt fit mine.
Trezor is beyond any doubt, an excellent technical solution. It makes it but an excellent, one point failure HVT target, with high ROI potential for an attacker.
1
twitter.com/DanielMicay/st
It's objectively far more secure against an online attack, offline attack or coercion than the proposed alternative. Running the Trezor firmware on hardware with an SoC more hardened against tampering would be a step up for offline attacks too.
Quote Tweet
Replying to @Ishan_Ishana @DusanDuda and 2 others
The proposed approach is objectively far less secure against an online attack, offline attack and coercion. A targeted attack on an individual is easier with a laptop. Your only argument is your theory that a supply chain attack on Trezor is more likely than $LAPTOP_VENDOR.
1
In terms of supply chain attacks, there's a trade-off between purchasing a specialized device with a tiny number of components and a far more complex general purpose device with much more exposure to a compromise. I don't think that has a clear cut answer.
2
1
It seems to me that you just want to be a contrarian by focusing solely on the niche of supply chain attacks and ignoring that it's not clear cut. Ignoring the far more realistic, basic threat models shared by everyone (online attacks, coercion) doesn't make much sense to me.
1
I am concentrating on the today's real world situation, running law proposals and determination and resources of the adversaries.
1
You can say that but I can't understand focusing solely on a sophisticated supply chain attack while ignoring far more accessible and realistic attack vectors. Laptops are much more complex (many components) and aren't tamper evident so there's a lower bar for those attacks too.
2
Ideally, there would be a wider variety of hardware choices using the same model, i.e. tiny attack surface, high entropy seed with a great recovery mechanism, any number of deniable passphrases each deriving different keys, on-device confirmations and passphrase entry, etc.
1
1
The security improvement against online attacks between it and a general purpose OS on a laptop is massive, and I think that's nearly always going to be the main attack vector with coercion close behind it. Being able to have a hidden wallet with no trace that it exists is good.
1
1
It's not the hardware details of a Trezor that are compelling but rather the very well designed security model and the solid open source firmware implementation. The hardware is very boring / simple and it's straightforward to make a custom Trezor since it's all off-the-shelf.
1
1
The drawback compared to some alternatives is that they don't use a secure element since they want the firmware to be open source so it can be audited and so people can make alternate hardware implementations. It would add a bit more difficulty for offline attacks vs. the seed.
There are no alternatives with a secure element preserving the rest of the security. The passphrase feature including on-device entry and on-device confirmation / recovery are much more compelling. Existing secure elements have drawbacks so there's not a clear cut answer to that.
1
1
Daniel, there of course is a clear cut. It is based in your OpSec FMECA, (or whatever you are used to). Whether you use normal OpSec cycle or specific adjusted, trust models..., you have to decide your def strategy based in sum of intel available, you wana consider.