Assumption: Yubikeys are harder to hack into than most PCs.

Can we use this assumption to construct a key storage scheme that is at least as secure as other systems, but is more convenient?

Idea: Store bitcoins at an address composed of three private keys, using a 2-out-of-3 scheme:
1. A strong password
2. A paper wallet, printed on your own computer using 2-factor paper wallets
3. A Yubikey!

The first two have been discussed before, so I won't elaborate on them.
The Yubikey address is a special kind of address, that requires usage of Scripts.

This joined address can receive Bitcoins, that can only be spent with 2 signatures out of the 3 above. The "Yubikey signature" is specifically a one-time password generated using a Yubikey, with a particular timestamp that matches the current blockchain time (to prevent replay attacks).

Advantages:
1. For this system to be cracked, you have to access to two out of the above 3 secrets. A paper wallet, printed on a clean, formatted computer which is subsequently wiped, especially using 2-factor auth, should be virtually impossible to obtain (store it in a bank vault). Your password can be accessed by a trojan, but the internal private key stored in the Yubikey cannot be retrieved, and its signatures are only valid for a very short time.

2. It is rather convenient to use. You can use this system even on semi-trusted computers ... the password element of the secret is basically just a sanity check ... even if it's compromised, the attackers can't do anything without physical access to your Yubikey or bank vault.

3. Yubikeys have 2 different password generation modes, triggered by either a short press or a long press on the key. You could have a system where a "short press password" is only allowed to transfer amounts of up to 100 BTC per day, and a "long press password" is required to manage this setting or transfer larger amounts of BTC. This way, a trojan working in real time can't snatch more than 100 BTC, despite snooping both password and OTP from the Yubikey.

Implementation
All of the above can, AFAIK, be implemented using Scripts.
More detailed specification of the protocol is left as an exercise to the reader.


Your thoughts?

Thanks for the feedback.

Is there another similar device based on public key cryptography?
If there were, would Script have been powerful enough? If not, why not?
Is it because it's not Turing complete, and thus it's not possible/feasible to run complex algorithms like verifying signatures?
Can this be feasibly changed in the near future?

Would it make sense to add a custom opcode that asks the client to validate an ECDSA signature?
Every Bitcoin client needs to have code for ECDSA validation, so it does't add a lot of complexity, nor does it open any security vulnerabilities.

Keeping Scripts Turing-incomplete is a very good idea.

You can use the yubikey for authentication with a third-party that owns a second private key for multi-signature transactions.

Yes you can do better than that by having an offline transaction signing device. Preferably one that displays the bitcoin address and the transaction amount.

It essentially is one. However, you would have to be able to put your own keys on there and have some protocol to have it sign stuff.

You don't need specific hardware. Just use a cheap second hand Android device. They flood onto the market at a fairly high rate. You can break its internet access by not giving it a SIM and switching off wifi, then do 2-factor signing using Bluetooth.

+1

Mike, what you suggest is possible, but it's not a turnkey solution.
I want something with the simplicity of a Yubikey.
It should support not just Bluetooth, but also USB (perhaps before Bluetooth).

I also want hardware level protection if possible. If the key is stored in a place on the hardware where the only output is ECDSA signatures, then it's absolutely secure.

I'm no hardware engineer though ... I need to understand how to model this device at the hardware level.

It's fun to dream but I think you guys need a reality check here:

1) Hardware engineering and manufacturing is a difficult, expensive business that relies on economies of scale.

2) Bitcoin is very small

Combine (1) and (2) means custom hardware for doing Bitcoin transactions is guaranteed to be very expensive, almost certainly more expensive than just re-using old phones, as phones have already achieved huge economies of scale. It's also far less likely to happen because the effort involved is much greater.

If you want to buy up old phones and reconfigure (or reflash) to a setup appropriate for Bitcoin usage, then re-ship to customers, that's something one or two people can do at low cost. Now you have your turnkey solution.

What's more, you really really want the superior hardware that phones give you. It's not safe to simply sign addresses without anything else. Otherwise your super-secure 3-factor coins or whatever, are secure until the time you want to spend them, and then you can be trivially fooled into sending your coins to somewhere other than where you think you're sending them (the virus on your host computer that motivates all this can rewrite the address). Doing ID verification using any existing proposal means having some kind of network access and processing power.

You could do all that with custom hardware too, but it increases the cost even further.

In the end, there's no point. How does malware get onto devices? By exploiting existing apps (ie, web browsers/chat clients/etc), and by convincing you to install it. If you have a dedicated phone that you never install software on and don't use any other apps with, it's as secure as a dedicated device. It's straightforward to make custom builds of Android that are cut down in this way and then reflash old devices with them.