search

WebKit / explainers

Explainers from WebKit contributors
371 stars 28 forks source link

[Remote CryptoKeys] Problem statement explains why some alternatives are bad, but doesn’t explain why non-extractable keys are not sufficient #113

Open othermaciej opened 5 months ago

othermaciej commented 5 months ago

Implementations may execute cryptographic operations in the client, potentially exposing a user’s private key to JavaScript, which makes keys vulnerable to exfiltration.

If “in the client” here means in webpage code, this is true. But since this is an extension to Web Crypto, which has non-extractable keys, it should explain why those are insufficient. It seems like key issues from our POV (besides security implementation details) are inability to access a non-extractable keys stored in e.g. IndexedDB from another device; or from a native apps on the same device. The problem statement should say that.

estark37 commented 5 months ago

It's also, to my knowledge, impossible to store non-extractable Web Crypto keys in a truly persistent way, such as you would want for a long-term identity key. Is that part of the motivation for this proposal, too?

I believe https://web.dev/articles/persistent-storage is the best you can do for persistent storage, and that behavior differs by browser and is best-effort.

jonchoukroun commented 4 months ago

That's correct @othermaciej , by "in the client" we mean in webpage code.

We agree the explainer can be clearer on why the existing CryptoKey properties don't cover our use case. Basically, we can’t rely on the extractable: false property because these keys must satisfy 2 other properties: 1) they’re long lived, meaning they aren’t destroyed when a browser’s memory is cleared 2) they’re usable by other browsers and other applications (eg a decryption key used in Safari, Chrome, Mail.app, and Gmail.app).

We will open a PR to clarify the explainer.