IDEA: Using U2F tokens as secure wallets

[sebastian]

I looked at the U2F specification, and found out that its using secp256r1 EC as their inner cryptography.
I dont know if this is compatible for bitcoin, but I actually got a idea:

Since U2F tokens work in Three different ways:
1: Either storing a EC private key onboard, exporting a public key, and a key identifier.
2: Or, creating a EC private key onboard, wrapping it with a device-specific key, and exports the public key, and encrypted private key.
3: Or, using a nonce to create a EC private key onboard, using a MAC with a device-specific key, and then exporting the public key and the nonce.

After this, authentication is done by signing a challenge along with other parameters, with the EC private key.


Even if theres lots of "useless" parameters inside the signed response, I got a idea, where you carefully create a transaction such as you can extract a "challenge" out of this, send it to the U2F token, and what you get back, is a completely signed transaction that you can transmit to the blockchain.
This MIGHT include generating special adresses using "Vanitygen", (that ends in like touch=1 or such) or actually wasting small amounts of Money (that is destroyed) to send these coins to invalid adresses, but so it match the response format of a U2F token.

To register U2F keys to the bitcoin network, it could be contructed by sending the data returned by the U2F token, in a transaction to be embedded in the blockchain. This would also waste Money, but by sending a minimum transaction, it would only be a couple of cents. A U2F-bitcoin-client then only needs to download the blockchain to be able to recover the wallet.
Since U2F keys are effectively Anonymous, you would need a way to identify which wallet is "yours".

This could be done by simply you provide a public "username" string, that you use along with the U2F key to load your wallet. The wallet would simply be embedded in the blockchain.

Abuse (for example spamming U2F registrations with identical usernames as other users, which means a U2F-bitcoin client has to try them all) is prevented simply because you have to waste Money to register a U2F key. Also by making U2F registrations indistingushable from normal transactions (for example by hashing the username), it would be hard for abusers to find these transactions.

This would mean you could get secure key storage for bitcoin for just about 20$.

If anyone would want to experiment with U2F tokens and bitcoin, here is a token:
https://store.yubico.com/store/catalog/product_info.php?products_id=112&osCsid=itvjqcbekqvd6gvkao9i91gns2

Any toughts?

[prismicide]

Hi,

For your information, HW1 hardware wallet is already capitalizing on parts of the U2F architecture by using the related USB connectivity that was introduced in Chrome for U2F devices. In fact, the team behind HW1 is the same one behind the Plug Up U2F Security key and smart card protection technologies are mostly the same.

So, if you are looking for a secure hardware wallet under 20$, you can buy HW1 USB smart card hardware wallets here :
https://hardwarewallet.com (Two units with shipment to USA = 0.101 TC / 38$)

Regards
--
Fred

[maxi_malism]

I know this is a bit of a bump, but i've been thinking about U2F recently and this is quite an interesting design idea.

For example:
1) Alice provides Webapp with her U2F public key
2) Bob provides Webapp with his U2F public key
3) Webapp constructs a 2-of-2-multisig address using both their public keys.
4) Now Alice and Bob can do business using the webapp. However, the webapp itself never has access to the private keys but only acts as a service provider.

If this design pattern is possible it will make it so much easier to develop single page applications that only provides the contract but doesn't hold any keys. Developers can focus more on the service and be less paranoid about security.

I recently bought a Ledger Nano S which is on it's way, i will try to find out if this works.

[maxi_malism]

Okay, so obviously U2F won't work because it's secp256r1, however UAF (similar fido alliance scheme, but for auth instead of 2-factor) uses secp256k1! This actually makes more sense, semantically, than U2F.

Apparently the challenge can be anything up to a sha516 hash in length, so signing bitcoin transactions should not be a problem. Unfortunately the FIDO spec uses nonces, which will fuck up the signature. I'm not good enough at cryptography or the inner workings of bitcoin to know if this can be circumvented somehow...

Obviously the hardware wallet makers should spearhead their own scheme for this somehow, but it would be cool to find a solution within the FIDO spec, since it is a bit more broad and endorsed by Google among others.

Any thoughts on if it's even possible to sign the hash with a nonce somehow?