SEA Hardware Support: ONLYKEY

[bmatusiak]

Hey GUN Developers!

I have been working with @onlykey to create 3rd party api support for hardware encryption to SEA and other web apps that uses P256R1 P256K1 CURVE25519 NACL key types

We currently have shared secret generation with P256R1 and CURVE25519 working on linux/mac/windows browsers so if you have a onlykey with the latest firmware, visit https://bmatusiak.github.io/node-onlykey/docs/ and give it a test and the source is at https://github.com/bmatusiak/node-onlykey

---

here is a small explainer

the current implementation has 2 parameters..

1st required parameter is "additional seed data" 2nd optional parameter "user presence keypress required"

"additional seed data" determines the epub key to use, and "user presence keypress required" adds more additional seed data changing the epub key to use

the api has 2 methods.. "derive key" & "derive shared secret"

using "user presence keypress required" with "derive key" DOES NOT NEED A KEYPRESS as only "derive shared secret" does

each domain or subdomain with same "additional seed data" will generate a different key

this allows different levels of security based on the developer or user needs

---

here is a current use example

create new user in gun, and get the keypair

now send the keypair's epub or pub as "additional seed data" to onlykey to "derive shared secret"

use SEA to encrypted the new user keypair with shared secret, and save it to the users graph

in the above example we do not need to fetch the onlykeys epub because we do not plan on generating a shared secret from the new user's priv-key

---

another example

BOB sends you a epub and ask for encrypted message

YOU take the BOB-epub, send it to onlykey(derive key) as "additional seed data" generating YOUR-epub YOU take the BOB-epub, send it to onlykey(derive shared secret) as "additional seed data" generating SHAREDSECRET

then take the un-encrypted message, encrypting message with SHAREDSECRET generating ENCRYPTED-MESSAGE

then you send BOB, YOUR-epub and ENCRYPTED-MESSAGE

BOB can now use your epub to create a SHAREDSECRET to decrypt the ENCRYPTED-MESSAGE

in the above example onlykey is completely transparent and BOB has no idea they used encrypted hardware, also YOU does not need to remember the "YOUR-epub" because it can generate it again from bob's epub

[amark]

Nice. If I use the same gun login on different sites (aka, same key) it'll still work, right? Or will the "per-domain" thing override that? I hope not.

I was wondering how you got the curves to be compatible with each other, that is brilliant!

[onlykey]

@amark The key generation on OnlyKey is based on a web apps domain or origin. You can use this method on an unlimited number or sites but the key generated is different for example1.com and example2.com. The reason is a security one, if the key generated was the same for different web apps than it would be possible to phish users. For example, I clone gun.eco and copy to hackergun.eco then trick users into logging in. Our implementation here works similar to say a FIDO security key, which must be registered at a site, then can be used to authenticate at only that site. The key has to then be registered at each site it is to be used but you can do this at an unlimited number of sites.

The difference with this implementation is that a FIDO security key only does authentication, it signs some data the server can verify to authenticate a user. Here we are doing ECDH instead of signing some data. So the web app can create a one time secret to encrypt/sign some data just for that user or create a shared secret that two users can both create to share encrypted data. There are some other features such as all of this exchange is encrypted in transit and the exchange occurs with a static webpage so none of the exchange need go over the internet, its USB-to-browser. Here is basically how it works:

• Web app sends a random NACL transport public key, an input public key (epub), the input key type, and additional seed data
• OnlyKey takes the origin of the web app (RPID), the additional seed data, and a local private key into a key derivation function HKDF. The output of this is a derived private that is unique to data input to the HKDF. ECDH is then completed with the derived private + input public key = shared secret.
• For the transport encryption OnlyKey also generates a random transport key pair, ECDH is completed, only the web app and OnlyKey have the shared secret which is used to encrypt the data in transit.

None of the implementation here is something that has never been done before. For example, derived private keys are also used for things like onlykey-agent and trezor-agent for SSH and GPG. The thing that is new is it has never been put together in a way where a hardware device can be used for encryption/signing with web apps in a secure way with phishing prevention features built-in. There also has not been any other implementations I know of that

Another alternative to mention is that if say BOB has a hardware key but ALICE does not they can still establish this shared secret where ALICE uses a passphrase in place of a hardware key.

One way I see this being used is a local app or private web site or web app that requires encryption. The web app can be a static web page that contains encrypted data. This encrypted data is only ever decrypted on local user's browser, no secrets sent over the internet. Authorized users see the decrypted webpage or app, everyone else can't.