CAIP: Generic Credential Interaction Protocol (GCIP) #394
Conversation
|
Wow this is a really promising CAIP, although I have to recuse myself from deep review because I have dangerously little grasp on OS-level security and even the basics of WebAuthN qua protocol. Maybe @kdenhartog could review? @arein whom do we know that's implemented WebAuthN in a wallet already? |
|
@bumblefudge |
|
@bumblefudge do you have any updates? |
kdenhartog
left a comment
kdenhartog
left a comment
There was a problem hiding this comment.
Overall this looks like a pretty cool design, but I'm a bit skeptical now is the right time to standardize this. Do we have a commitment from multiple parties that they're interested in working on this? If not, defining this as a CAIP is useful in so far as it becomes a public docs repo like what EIPs are which isn't very useful here.
I think we should wait to see if multiple people are committed to implementing this so that we can work through interoperability/webcompat/security tradeoffs together rather than move this thing along further and then miss something because only one or two people were looking at it as it was being defined.
| ##### 2.2.3. Same-device trusted transports (Intent, ActionExtension, etc.) | ||
|
|
||
| In same-device and OS-mediated transports where the channel has strong integrity and identity | ||
| guarantees, the connection SHOULD be established with one RTT by performing `Connect` with an inline |
There was a problem hiding this comment.
Why SHOULD instead of MUST here? It seems like under a formal analysis this would make it harder to reason about the TOFU problem to assess security guarantees.
There was a problem hiding this comment.
I've been thinking about it.
We can change to MUST to reduce complexity, the thing is Signer actually are able to work in 2 flows, so I decided to keep it in case someone want extra security for clientData.
| ##### 2.2.2. Supported primitives | ||
|
|
||
| - **Key agreement**: ECDH over P-256, ECDH over X25519 | ||
| - **Key derivation**: HKDF-SHA256 | ||
| - **Encryption**: AES-256-GCM | ||
|
|
||
| GCIP uses two operational modes, depending on transport trust assumptions. |
There was a problem hiding this comment.
What's the reason for these cryptographic parameters? Typically on non-CPU accelerated instruction sets chacha20poly1305 (orxchacha20poly1305 may be used for better guarantees, but less widely used) operates at a faster rate than AES-256-GCM.
Do you plan to have any form of cryptographic agility via versioning for this?
There was a problem hiding this comment.
GCIP has version in block, all supported cryptography algos are connected to it.
I thought about chacha20poly1305, I have an approach to stick to WebAuthn algorithms where it's possible.
I'm still investigating if there is a convenient way to keep session-key in Android/iOS Keystores, which doesn't support chacha20 for now.
But in overall for now we don't have any blockers to support chacha20poly1305.
|
|
||
| ##### 2.2.5. Session key derivation | ||
|
|
||
| Each party generates an ephemeral ECDH key pair and exchanges public keys (during `Exchange` or |
There was a problem hiding this comment.
If both parties operate under an ephemeral ECDH generation you'll introduce a TOFU problem for the session. Is that an acceptable tradeoff that a person could MITM the session and tamper with the transaction requests made to the authenticator?
There was a problem hiding this comment.
For BLE, USB it's pretty hard to establish this attack.
For Android/iOS you can read - 5.5.4.
Also I have plan to introduce KeyRotation, but it won't help with 5.5.4. case.
| | `eid` | 0 | `null` | Absent (null) | | ||
| | `iv` | 0 | `null` | Absent for handshake request | | ||
| | `exchangeKey` | N | `clientPubKey` | Client's ephemeral P-256 public key (COSE_Key) | | ||
| | `data` | N | `plaintext` | CBOR-encoded method payload | |
There was a problem hiding this comment.
What's the reason for sending plaintext directly in the initial handshake request? That seems like it leaves it susceptible to tampering/interception issues
There was a problem hiding this comment.
First of all it's plaintext only for trusted env(Intent, ActionExtension) request.
- It's almost impossible(only by using complicated UI/UX) to make safe encryption for offline only applications for initial request. If I intercepted request by user's mistake and it can read GCIP blocks it highly likely can decrypt the request.
- Data in
connect.requestcan be considered like open by default:
2.1. Anyone can decompile app and see it there
2.2. For Android any app can see all installed applications with their domains, names, logos etc. - Also which is why I allow to start session in trusted devices with
exchange.request, so theconnect.requestwill be encrypted.
| - [GCIP KMP](https://github.com/Open-Store-Foundation/app/tree/main/lib/gcip) | ||
| - [Signer](https://github.com/Open-Store-Foundation/app/tree/main/apps/signer) | ||
| - [Wallet](https://github.com/Open-Store-Foundation/app/tree/main/apps/sample/wallet) |
There was a problem hiding this comment.
hmm it seems all of these are paid for services to charge for storage of the DApp so it can be integrity validated by the wallet. Am I interpreting the docs of this right and how is this planning to get DApps to do that so that the wallet can validate it? This seems like a metcalfe's law bootstrapping problem.
There was a problem hiding this comment.
Sorry didn't get your point here.
|
@kdenhartog I'm solo researcher right now I see our flow like:
|
|
@kdenhartog If you want we can have a call, do discuss it faster and I'll add summary after that. |
4 participants
CAIP for Generic Credential Interaction Protocol (GCIP)
Preview - https://github.com/Open-Store-Foundation/app/blob/main/lib/gcip/CAIP.md
Discussion - http://t.me/firebox_official
P.S. Will update image resources, title, commit name etc. after CAIP number will be defined.