Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[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 this issue Mar 23, 2024 · 2 comments

Comments

@othermaciej
Copy link
Contributor

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
Copy link

estark37 commented Apr 5, 2024

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants