Quote from: ben-abuya on June 22, 2011, 08:26:50 PM

Quote from: Gavin Andresen on June 22, 2011, 07:43:38 PM

The risk profile I care about is:

User's computer is completely compromised by a root-kit trojan, but they don't know it.

However, the user has access to some other device or service that they have setup in advance to be a "second line of defense" to prevent their entire wallet from being stolen.

Right, so by definition they don't have their wallet on the computer. IronKey has built in AES encryption. Imagine a smartcard or usb drive that had built in ECDSA encryption. The device could generate and store private keys and sign bitcoin transactions, but would be designed to never allow access to the private keys. The client just sends the unsigned transaction to the device and gets back the signed transaction.

This still has an weakness though. A rootkit could send the drive a transaction for your entire balance and have it sign it. So you need a screen on the drive that shows the amount and recipient address, and a physical confirm button.

The Ironkey also does RSA, it can be thought of as several devices in one, flash, smart card reader, smart card, all off a single USB bus.

The scenario we discuss here though doesn't require the flash component though it is of course interesting for other reasons.

As for the trusted input problem there are a few solutions, it depends on how deep you want to go to solve it.

To protect against user mode key l loggers in windows you can use the session 0 ui to collect the pin, only kernel malware would get past that.

You could use a secure PED (hard to do in a decentralized system)

You can use graphical pins, random layout (kind of like captchas)

There are a ton, first step IMHO is getting the keys off the host