[Bug 25431] Error names allow RSAES-PKCS1-v1_5 oracle attack against wrapped keys

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25431

--- Comment #10 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Mark Watson from comment #9)
> First, one general comment - I was mistaken in my earlier message in giving
> consideration at all to the case where an attacker can directly access the
> WebCrypto API in the origin in question. In all such cases, the attacker
> can, of course, simply decrypt arbitrary messages directly, using the API.

No, of course they can't - if the RSA-ES key is only permitted for unwrap, and
the wrapped key has structure.

> 
> The oracle attack is of importance when considering an attacker who can
> insert protocol messages and observe responses. But in this case the
> application Javascript has control of what is or is not revealed in such
> messages and can take care to follow approaches such as the TLS approach you
> cite.

No, they cannot.

Your assumption that this is only a remote attacker is NOT a reasonable threat
analysis of RSA-ES.

> 
> (In reply to Ryan Sleevi from comment #8)
> > (In reply to Mark Watson from comment #7)
> > > So, first, considering the issue actually in the subject line of this bug,
> > > if we change the specification so that padding errors and parse errors do
> > > not return distinct codes, then I believe the padding oracle attack of [B98]
> > > and variants is rendered infeasible for keys that have usage 'unwrap' and
> > > not 'decrypt' and where the wrapped key format has some structure: the
> > > chosen ciphertexts in the attack would not only need to result in correctly
> > > padded plaintext, but syntactically valid payloads. The chance of this for
> > > any given chosen ciphertext seems little better than random, rendering the
> > > attack infeasible.
> > 
> > Mark,
> > 
> > That's not a correct security analysis of B98. Structured results reveal
> > even *more* details about the nature of the failure. You have to permeate
> > the constant-timedness of the operations throughout the entire algorithm in
> > order to mitigate, as any short-circuits reveal whether or not it was
> > well-formed.
> 
> I'd be happy to be proven wrong, but I don't think what you say above is the
> whole story. The attack is based on the fact that the oracle reveals, when
> the padding check succeeds, that a chosen multiple of the plaintext lies
> within a known, simple, subset of the set of all possible plaintexts:
> specifically the subset with valid PKCS#1 padding. This is (roughly) 2^16
> smaller than the set of all plaintexts, because the first two bytes are 0x00
> and 0x02. If the oracle returns an error, little or nothing useful is
> revealed about the plaintext.
> 
> Now, it is clear that if the oracle instead reveals that a chosen multiple
> of the plaintext is both PKCS conforming *and* encodes a valid JWK or ASN.1
> structure then this success result reveals much more information about the
> plaintext. The set of possible plaintext values with both properties is much
> smaller.
> 
> However, multipliers with this property are much much harder to find. The
> _average_ amount of information revealed with each trip to the oracle is, I
> expect, much less, since most of the time you get a failure. I admit I don't
> have a proof of this, though. Do you have a proof of, or evidence for, the
> converse ?
> 
> Furthermore, it's not clear that the additional restriction of the possible
> plaintext set admits a practical exploitation except for the obvious one
> that the plaintext is a multiple of 125 (in the JWK case). It seems to me
> that a practical attack based on this would be something worthy of
> publication, not something we should assume / expect to exist.
> 
> Regarding timing attacks, I think some evidence is required to suggest that
> this might be feasible based on the RSA-ES WebCrypto primitive alone. Of
> course it is possible to design protocols that expose timing attacks as in
> the XML security case, where the attacker can force the victim to decrypt
> 1MB of data in the success case and none on the failure case. 

You're wrong.

It should be painfully obvious that RSA-ES with unwrap creates two forms of
oracles when dealing with structured data, that fundamentally CANNOT be removed
from this API.

The first is quite simple: If using RSA-ES to unwrap a JWK, then on a
successful padding check, the entire data will be provided to importKey, which
will perform a JSON parsing operation or an ASN.1 decoding operation. On a
failed padding check, importKey will not be called. That's a padding oracle,
plain and simple.

Now let's say you said that it would still call importKey, but with random
data. Because JSON/PKCS8 has structure, on a success case, every single octet
of the decrypted data would be accessed. However, because random data would
not, it would only access the first N octets up to an error. That's a timing
oracle, plain and simple.

Now, let's say you tried to be clever, and said only unstructured keys could be
used. Your random data stream is now a 'valid' key, so import succeeds and
returns a Key object if the padding check fails. You now get into the issues
described in the XML security paper - for which again, you've got both a
padding and timing oracle.


> > The distinction needs only be sufficient between "success" and "failure",
> 
> True - it is the success case that carries the exploitable information.
> 
> > and timing provides a clear source of this.
> 
> It's not clear that can't be mitigated for an attacker modifying / observing
> a network protocol.
> 

Your failure to consider the 'local access' threat here is perhaps why we
disagree on why this method is broken.


> > > Finally, for the second case of an attacker able to modify and observe
> > > messages but unable to insert arbitrary code onto the client, it would be
> > > sufficient for the JS application to avoid exposing a distinction between
> > > the success and failure cases, for example as per the TLS approach Ryan
> > > cited.
> > 
> > Timing is sufficient to expose this. Considering that different scripts
> > running in different origin have access to high resolution timers, I do not
> > feel comfortable at all saying that this is a non-issue if you "just use
> > TLS" (or related)
> 
> Well, I didn't say "just use TLS". And we are talking about a network-based
> attack. Client-side high resolution timers are relevant only if the
> application under attack exposes its messaging protocol locally to other
> origins (over postMessage or I guess some convoluted WebSockets thing over
> localhost).

No, I'm not talking about a network-based attack. I'm talking about the
fundamental security - regardless of network or not.


> > > I don't want to underplay the significance of the weaknesses with this
> > > padding scheme or suggest for a moment that one shouldn't always use
> > > RSA-OAEP instead if that is available. But it seems that support for
> > > RSA-OAEP is not going to be universal in browsers, at least initially.
> > 
> > That seems a premature conclusion.
> 
> Ok, good. If RSA-OAEP is universally supported then I'm not so concerned
> about whether RSA-ES is included or not.

This is *not* something that is in scope for this WG to dictate, as has been
noted before.

This WG simply documents ways to represent the algorithms. It is up to UAs to
implement.

> > It's true that support for *anything* is not going to be universal.
> > 
> > I have zero concerns with removing RSA-ES, and there seems sufficient
> > consensus to do so.
> 
> You don't have consensus at this stage.

Thank you for making it clear your support from a broken and insecure
algorithm. It is incredibly disheartening that you would continue to espouse
it.

This document serves primarily to document how, if RSA-ES is implemented, it
would look.

We can leave this algorithm in, but I think it will do a disservice to API
reviewers, as
1) It remains unlikely that any implementor will implement/ship, for all the
reasons documented here
2) It will confuse reviewers to document an unimplemented algorithm

Of course, we can simply defer that to REC status and we do the implementation
status for every algorithm, but I would hope it would be obviously
non-controversial to simply remove now.

> > This is, perhaps, the worst of all the options.
> > 
> > I do not support RSA-ES without further modifications to provide
> > meaningfully robust defense - changes that fundamentally alter the API and
> > it's reporting.
> > 
> > If you look at
> > http://www.nds.rub.de/media/nds/veroeffentlichungen/2012/07/11/
> > XMLencBleichenbacher.pdf , you can see a more practical application of the
> > attack to the API exposed. This has previously been discussed on-list.
> 
> That paper describes attacks that are based on more than just the weakness
> in RSA-ES. Other aspects of the XML security design are essential to the
> attacks.
> 
> What this proves is that it's possible for smart people to invent broken
> protocols with RSA-ES. That's not in dispute.
> 
> What I'm arguing against is the conjecture that it is so hard to design
> protocols with any practical application that we should not provide the
> primitive at all.

Noted.

As written, I still assert that it is impossible to design a "secure" usage of
RSA-ES with this API, which you seem to dispute. While proposals to change the
API could be explored, they would require dramatic altering to unwrapKey and
importKey, and such changes seem to provide very little value in light of
"secure" unwrapping/decryption alternatives.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Tuesday, 13 May 2014 16:14:21 UTC