When does webcrypto exportable=false protect a secret key from adaptive chosen plaintext attacks?

Question

When an attacker injects javascript on a page that has a CryptoKey Object with exportable=true, he can export the key and send the bytes to his own server.

With exportable=false, the attacker can't directly send the bytes, but it can use the CryptoKey object as an oracle for adapative known plaintext attacks.

Under what conditions can the attacker recover the underlying secret bytes and send them to his own server ? That is, in which case is it useful to use non-exportable keys ? Does it differ between the webcrypto algorithms (AES-CBC, RSA-OAEP, etc.) ?

Note: since the attacker can inject arbitrary javascript, it controls the whole api usage: the plaintext, and for modes using an IV (AES-CBC for example), it also controls the IV.

Answer 1

To answer the original question:

With extractable: false you cannot simply export the key as it itself is encrypted. But if you have access to the CryptoKey in a secure context you can use it as an oracle, sure. But also not without caveats since the CryptoKey gets generated only for a specific Algorithm (eg. ECDSA-p-521) and whitelisted for what it can do (e.g. encrypt, decrypt..). So if your key was generated for encrypting only, you can only run CPA, not CCA, and vice-versa.

with that in mind we can answer the bountied details:

if you have access to the secure context (via xss should work, mitm would be harder since it normally breaks https), and get ahold of the cryptoKey used in that context you can pass it to the crypto.subtle.decrypt() etc functions. Keep in mind though, that you can only use the key for what it was designed to do, but yes the decrypt() function returns a plaintext promise which you could then forward to your attack server etc and use the infected context as an oracle.