szszszsz
commented
4 years ago Hi! Sorry for the late reply! Yes, we are very much interested in cooperation and in creation of a standard API, which would be useful to a broader audience. Shall we discuss details over email?
Regarding the questions:
-
Yes, indeed this is a valid concern and needs discussion about UX. In the first version we plan to have one key per each origin, without cross-origin access. Resident/imported keys can have configurable range of allowed origins. Such configuration will be done on a single domain only, potentially configurable by user and confirmed by PIN.
-
FIDO2 already has encryption on the USB layer, so I understand that you would like to avoid here access of the stream by any other or malicious JS application, is that right? If so, I planned to reuse parts of the CTAP protocol for the communication, which is a base for the FIDO2 (so kind of CTAP over CTAP). It already has 4-byte channel ID, which both browser and device knows for given session, and it is not possible to access the channel without knowing it, or initializing the channel again. Initially I plan to use only one channel (no concurrent access without reinitialization). This would allow for a better performance, than the solution with the additional encryption. What do you think? I agree sharing the device's details will be useful.
-
For start I would work with P256 first, which is supported by most FIDO2 devices. Curve25519 would be nice to have. Same for HMAC SHA, and challenge-response. Later RSA is 2048/4096 support is planned.
I like what you guys are doing here! We made some improvements to OnlyKey WebCrypt recently to include FIDO2 transport (works on Firefox, Chrome, and mobile browsers). We currently only support RSA keys and I am interested in expanding this to ECC keys as well. Maybe we could collaborate here as this moves forward and create a standard API for web developers to use? It would make sense and we could have a node js library that makes it easy for web developers to integrate with their apps. That being said there are some things to consider with a web interface like this:
1) Threat model of phishing - It would be possible to trick a user into decrypting or signing something if they click a link and browse to a malicious page. The way we currently deal with this in OnlyKey WebCrypt is to only allow the apps.crp.to origin (restrict by rpid). Unfortunately, this also doesn't allow 3rd party developers to use this. I like the idea here to have keys configurable where you can set origin, but I think in some cases you may need multiple origins which complicates things. This is the first issue to solve.
2) Data in transit encryption - One thing we did with OnlyKey webcrypt is that there is first a NACL key exchange before doing anything else. This first message also sends the device the browser version, OS, and the device sends back its status and firmware version. The shared NACL secret is then used to encrypt any result the device creates, so if say a rogue app tries to grab the result before the legitimate app can it only gets an encrypted blob. This also protects against malware that may be on a system intercepting the USB data. This has an advantage over current FIDO2 apps but requires an additional message to do the NACL key exchange. This is something that could be included as a standard, this first message would set up shared secret and tell the web app if an OnlyKey is connected or if a Nitrokey is connected.
3) I didn't see mention of encryption types here, one thing that would probably be needed is a way of specifying the whether the key is Curve25519, P256, etc. and if building a way to specify ECC key types it may also make sense to include here HMAC SHA1 / SHA256. You could also derive HMAC secrets and use for challenge-response feature.
Let me know if there is interest in working together on this. I think there is a lot of potential here, especially if we get a standard API that is easy for developers to integrate with existing web apps.