Bitcoin Forum

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 (https://en.bitcoin.it/wiki/Two-factor_paper_wallet)
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 (https://en.bitcoin.it/wiki/Script).

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?

Yubikey uses symmetric crypto. The entity validating the Yubikey code knows the Yubikey's secret key and can therefore produce valid Yubikey codes for the person being validated. Even if Script was powerful enough to validate Yubikey codes (it's not), you'd have to publish your Yubikey secret key to the network, which makes it pointless.

:(

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?

That would be great to have a public key cryptography version of Yubikey

http://www.quora.com/Cryptography/Is-there-a-Yubikey-like-device-that-uses-public-key-cryptography

Right. Script has opcodes for some hashing and signing algorithms built in, but it's not powerful enough to implement other crypto algorithms (bignum math isn't possible, for example). It's possible to make Script Turing-complete, but I don't see this happening any time soon since it would be backward-incompatible, it introduces potential security problems, and there's not that much benefit to it.


There are hardware devices that securely contain private keys and perform signing, but I don't know whether any existing devices would be able to sign Bitcoin transactions. Especially since Bitcoin uses an ECDSA curve used almost nowhere else.

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.

German Privacy Foundations cryptostick may (uses pgp afaik)

http://www.privacyfoundation.de/crypto_stick/crypto_stick_english/

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

Not good enough ... we can do better than that.

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.

Perhaps the bitcoincard can be used as a signing device.

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.

In your opinion, would such a device be superior to other Hardware Bitcoin devices?
Would you buy it? For how much?

I see a lot of options here.

The killer feature is zero trust - you don't have to trust in the device's manufacturer, because you'll be using m-of-n signatures.
The scheme doesn't need any backups to the device itself - if it's lost, you still have n-1 other signatures, and can easily either move your funds to a traditional bitcoin address, or order another hardware authenticator and move the funds to a new m-of-n address with the new device.

I wouldn't trust a significant amount of coins to any of the other devices out there ... they're too experimental.
But this new device doesn't require you to trust your coins to it - it always increases your security, never decreases it.

I am quite interested in designing and developing this device.
I'm thinking of creating it as a completely open-source project, if possible.

If anyone is interested in teaming up to work on it, please post / pm me.

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.

I'm sure ripper234 wants a simple solution. This is not a solution for the general user that would want something specific and simple to use.

+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.

Also, if the device is USB-only and no Bluetooth, then it doesn't require charging or even a battery, which is a nice usability bonus.

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.

It might be cheaper to do this with old phones ... but would old 2nd hand phones be reliable enough?
Maybe.


At least two Bitcoin hardware devices are in production ... so people are overcoming this difficulty. Sadly AFAIK none of them has shown the security properties I described.


That might be a good first milestone.


I'm planning on a small monitor that can only display a Bitcoin address + amount. To my simpleton mind, that should be too much of an added cost ... but as I said, I'm no hardware engineer.


One major downside to the Android approach is that there is too much meat in it. The OS itself is huge, the original capabilities of the device including transmitting mobile signals ... how would you convince an end user that this device is safe?

I do agree that your points about difficulty and complexity are valid ones.

Did you see this? https://bitcointalk.org/index.php?topic=78614.0

Nice thread, thanks!

I think this has now been solved :-)
http://www.reddit.com/r/Bitcoin/comments/2mo165/multisig_done_right_launching_cosign_pages_and/cm6v8rl?context=3