4 ms·
Not to my knowledge, but similar approaches have existed for a long time now e.g. RSA SecurID [0]. One day I'm going to set up my Yubikey to perform a similar p
by seabee 15y ago
Not to my knowledge, but similar approaches have existed for a long time now e.g. RSA SecurID [0]. One day I'm going to set up my Yubikey to perform a similar purpose, but my motivation levels correlate with my paranoia :)
[0] http://www.rsa.com/node.aspx?id=1156 http://www.rsa.com/node.aspx?id=1156
- mike-cardwell 15y agoI have a yubikey myself. The smart card method is much better though. When using a smart card, it is impossible even for the owner (who knows the access pin) to read the actual key. The crypto operations involved in the authentication take place on the card it's self. The smart card is protected by a pin, and will wipe it's self if the pin is entered incorrectly too many times. You can even use a smart card reader with a hardware pin pad built in so neither soft nor hard keyloggers can intercept it.
- rdl 15y agoThe weak point is you still don't know what you're signing, who or what you're authenticating, etc. if you don't have a trusted display and do the entire transaction on trusted hardware. (your host may be compromised, and could show arbitrary data, proxy connections, etc.) Protecting the key does go a long way, but even with a secure passphrase input and smartcard key operations, there is risk. The ideal, IMO, would be some secondary hardware with a limited, secure OS which lets you put specific limits on how the key is used, showing a hash or identifying details of each transaction on the secure display, prompting you to verify each. E.g. to send a payment, the amount and payee (and date/sequence number) are shown on the secure display to verify before authorizing.