Update transparency scores for hardware wallets

[saivann]

Live preview: (Merged)

This is an attempt at providing appropriate transparency scores and texts for hardware wallets (TREZOR and BTChip) (see #564 #545) (@slush0 @btchip, feel free to give your comments)

At the same time, this pull request raises the bar a little for all wallets by giving all non-deterministic wallets a score title saying "Basic transparency" instead of "Good transparency", which better reflects that higher levels of transparency is possible.

[btchip]

That looks ok to me with one minor comment - you might want to change the "the device cannot be verified to be generating secure random seeds" part of checkpasstransparencyopensourcehardware because you might be able to review the random number generation algorithm for an open source product.

[saivann]

@btchip Thanks for your comment. Actually to my understanding, although you may be able to review the code, you still can't have any proof that the device is using said RNG or that it has a real secure source of entropy, right? In general, that's the idea I try to convey here.

[btchip]

Sure - you can only see if the developers are trying to harden it properly (f.e. by mixing several sources or applying some standard procedures) and use that to get a better idea of the quality of the RNG - AIS31 can be a starting point

[saivann]

@btchip I've just made it clearer that verifying the RNG depends on verifying that the device is using the right source code - which isn't possible, does that seem more accurate to you?

[saivann]

In the absence of critical feedback, this pull request will be merged on November 18th.

[btchip]

Yes, perhaps also mention that building + flashing your own firmware can improve the security in the open-source scenario

[saivann]

@btchip I was about to add a line and had a thought, although I'm no expert here but assuming this message will be seen by many non-technical users, isn't there also some risk of building the firmware with outdated / weak libraries and/or flash corrupted firmware? IIRC Trezor provides deterministic build instructions, but I have no idea how much users are likely to build the firmware with a different process.

[btchip]

Yes, this was more or less implied - people rebuilding the firmware should do so according to the provider instructions and check that they produce the same binary. If you think that's too confusing I'm perfectly fine to drop the suggestion.

[saivann]

@btchip I think I have a preference for keeping it short and implicit for now, my first guess is technical users will more likely think of building from source when reading "open-source" and "update your firmware" while other users will use the more simple and error-proof option - signed binaries (which should be watched to be matching the code in theory).