Yubico's take on U2F key wrapping I've been reading up on Yubico's implementation of U2F. What I understand so far is that two things are calculated. So upon registration first you calculate a private key by 

$PrivateKey = HMAC(AppID+nonce,DeviceKey)$

This is then used to simulate the encrypted private key which is sent to the server in the U2F spec: 

$KeyHandle = nonce, HMAC(AppID,PrivateKey)$

with "normal" U2F, you send the encrypted private key and a public key to the server. When a user authenticates, he is sent his encrypted private key and a challenge, which is some value encrypted with the public key. If the user can decrypt the challenge by decrypting the private key and decrypting the challenge he has proven he is in fact who he claims to be.

Now this is where it gets fuzzy for me. 


The keyhandle is just a nonce and HMAC concatenated, how is this
turned into a private key?
How is the public key  derived as the private key is just a hash in
this case?
The $KeyHandle$ is not the public key, it's a value used to identify the public key that's been registered.  Essentially, it's an identifier of a specific pairing of that device with that server, with its own unique private/public key pair.

From the page you linked to, the $KeyHandle$ is not a sum but both values, the nonce and the MAC of the AppID and the generated private key.  When it's registered, it sends the $KeyHandle$ and public key to the server.  

When authenticating, the server sends that $KeyHandle$ back, so the device simply uses the nonce to regenerate the private key, verifies it with the MAC, then uses that to prove it knows the private key corresponding to the public key sent during registration.

The hash is just a large number.   ECDSA is used in UAF. When using modular exponentiation systems, the public key is often of the form $g^x mod$  $N$ where x is the private key, EC is similar in form.