[j_s]

First you state: "Securing computer is lost cause." Then you give the constraints within which computing becomes "very easy to secure". As I previously stated: use a computer that fits within your definition of "very easy to secure" to setup the YubiHSM; after that, encryption using the HSM is theoretically secure to the degree the CPU accessing the plaintext is secure (this does not have to be the CPU the YubiHSM is plugged into).

The YubiHSM draws the line for "MITM-proof" (per your original comment) after initial key setup, in exchange for an order of magnitude reduction in price. The main difference between this and regular Yubikeys is the performance, things like supporting 16 concurrent connections. Yubico doesn't seem to use "MITM-proof" on their product page; is this basically a straw man? I guess it makes for an interesting discussion about the various theoreticals.

I am very much more interested in details on the tools you (as someone concered enough to ensure no one is misled) use to implement secure computing, most specifically how they have worked out for you in practice. Relatively inexpensive tools like Trezor and others with screens and buttons built-in may meet your criteria and suffice for personal use, but server-level performance isn't going to be there without a couple extra zeroes on the price.

[wav-part]

> As I previously stated: use a computer that fits within your definition of "very easy to secure" to setup the YubiHSM; after that, encryption using the HSM is theoretically secure to the degree the CPU accessing the plaintext is secure (this does not have to be the CPU the YubiHSM is plugged into).

Whats the point ? We already have a secure system.

Trezor is an ideal HSM. Chromebook C201 can make most secure (not sure if its enough) HSM laptop. And I dont think performence is a requirement.

I more suprised why people are using YubiHSM like devices to store root keys. I dont mean to shit on someoneelse's party.

[j_s]

I appreciate your willingness to voice your concerns and doing so probably has helped many (including myself) to better understand where the "cheap" YubiHSM2 fits into the market.

I would be interested to see a performance comparison between a Trezor and the YubiHSM, v1 and/or v2. I assume the Trezor compares within an order of magnitude to a regular Yubikey of the same vintage. Trezor may even make sense as a "getting started" tool for server security under light load, especially if 6 of them combined even come close to matching the performance characteristics of the YubiHSM2. Perhaps this is the next logical market for the Trezor manufacturer to pursue?

Yubico is very up-front about the limitations of their device once you get to the point of reading the YubiHSM1 manual (couldn't find v2):

https://www.yubico.com/wp-content/uploads/2015/04/YubiHSM-Ma... [PDF] section "2.14 Security Considerations"

Although the physical security is a part of the concept, it should be explicitly underlined that the main design objective for the YubiHSM is to protect symmetrical keys and other sensitive in transit and data stored on servers from being compromised by remote attacks.

...

As a kind of final word on this subject, the reader may wish to bear in mind the practical and theoretical attacks in this realm must be soberly considered both rationally and practically and should neither be exaggerated nor neglected. The intention with YubiHSM is not the right product for all authentication needs, but to provide the most cost efficient vs. security compromise consistent with the YubiKey philosophy.

[j_s]

Just spamming here a bit later to mention the ideal configuration may be Trezor/similar for a root CA cert, and using it to generate certs for an HSM providing production performance.