Re: [jose] Secdir review of draft-ietf-jose-json-web-signature-31
2014-09-22 10:30:19
I need to re read Kaliski's paper from CT-RSA 2002 On Hash Function Firewalls
in Signature Schemes to see how difficult is difficult.
http://bookzz.org/book/2302665/6f0670
This is not exactly a new issue. I can see other ISEG discussions over the
years on this and related topics.
There seems to be a padding consideration for PSS that also acts as a
mitigation to prevent the recipient from interpreting the hash to be shorter
than was sent.
Having the correct security considerations will help implementers. The paper
above is referenced by a number of RFC, but I see some people did not consider
the mitigation effective as the other uses of PSS do not tie the MGF to the
signing hash as we did in JWA.
I am just getting on a flight, and will have a look at it tomorrow.
John B.
On Sep 21, 2014, at 9:31 PM, Richard Barnes <rlb(_at_)ipv(_dot_)sx> wrote:
On Sun, Sep 21, 2014 at 8:59 PM, John Bradley <ve7jtb(_at_)ve7jtb(_dot_)com>
wrote:
Also with PSS the attack is largely mitigated if the mask function uses the
same hash as the message. http://tools.ietf.org/html/rfc3447#page-29
JWA sec 3.5 requires SHA2 MGF functions for SHA2 message hashes with the
equivalent length.
If the same is done when SHA3 is added then I think PSS is not as susceptible
to a substitution attack as it might look on the surface.
Certainly, having to change the MGF makes things much harder for the
attacker. However, in principle an attacker with a sufficiently broken hash
algorithm could compute a preimage for the message *and* the MGF. As RFC
3447 says:
"it will be difficult for an opponent to substitute a different hash function"
... using "difficult" in the sense of "way harder than if we hadn't", not in
the sense of "just as hard as forging the signature".
--Richard
Sorry I just remembers that there was that mitigation for PSS.
John B.
On Sep 21, 2014, at 8:47 PM, John Bradley <ve7jtb(_at_)ve7jtb(_dot_)com>
wrote:
I like the general direction.
One question, wouldn't the recipient of a PSS signature detect the
substitution of SHA-284 with SHA-256 due to the different key length.
I was under the perhaps mistaken impression that the key lengths needed to
be the same and just the alg different eg SHA3 and SHA2 keys of the same
length.
If that is the case we probably have not defined any algs currently that may
be subject to this. That is not to say that we shouldn't warn people as new
algs are defined.
John B.
On Sep 21, 2014, at 8:32 PM, Richard Barnes <rlb(_at_)ipv(_dot_)sx> wrote:
I think I may have erred by trying to write a treatise on which algorithms
are vulnerable :) Here's some updated text, trying to be more concise.
Jim: Your points about SHA-256 vs. SHA-512/256 and SHA-256 vs. SHA-3 don't
really apply, since JOSE hasn't defined algorithm identifiers for
SHA-512/256 or SHA-3.
"""
# Signature Algorithm Protection
In some usages of JWS, there is a risk of algorithm substitution attacks,
in which an attacker can use an existing signature value with a different
signature algorithm to make it appear that a signer has signed something
that he actually has not. These attacks have been discussed in detail in
the context of CMS {{RFC 6211}}. The risk arises when all of the following
are true:
* Verifiers of a signature support multiple algorithms of different
strengths
* Given an existing signature, an attacker can find another payload that
produces the same signature value with a weaker algorithm
* In particular, the payload crafted by the attacker is valid in a given
application-layer context
For example, suppose a verifier is willing to accept both "PS256" and
"PS384" as "alg" values, and a signer creates a signature using "PS256".
If the attacker can craft a payload that results in the same signature with
SHA-256 as the signature with SHA-384 of the legitimate payload, then the
"PS256" signature over the bogus payload will be the same as the "PS384"
signature over the legitimate payload.
There are several ways for an application using JOSE to mitigate algorithm
substitution attacks
The simplest mitigation is to not accept signatures using vulnerable
algorithms: Algorithm substitution attacks do not arise for all signature
algorithms. The only algorithms defined in JWA
{{I-D.ietf-jose-json-web-algorithms}} that may be vulnerable to algorithm
substitution attacks is RSA-PSS ("PS256", etc.). An implementation that
does not support RSA-PSS is not vulnerable to algorithm substitution
attacks. (Obviously, if other algorithms are added, then they may
introduce new risks.)
In addition, substitution attacks are only feasible if an attacker can
compute pre-images for the weakest hash function accepted by the recipient.
All JOSE algorithms use SHA-2 hashes, for which there are no known
pre-image attacks as of this writing. Until there begin to be attacks
against SHA-2 hashes, even a JOSE implementation that supports PSS is safe
from substitution attacks.
Without restricting algorithms, there are also mitigations at the JOSE and
application layer: At the level of JOSE, an application could require that
the "alg" parameter be carried in the protected header. (This is the
approach taken by RFC 6211.) The application could also include a field
reflecting the algorithm in the application payload, and require that it be
matched with the "alg" parameter during verification. (This is the approach
taken by PKIX {{RFC5280}}.)
Of these mitigations, the only sure solution is the first, not to accept
vulnerable algorithms. Signing over the "alg" parameter (directly or
indirectly) only makes the attacker's work more difficult, by requiring
that the bogus payload also contain bogus information about the signing
algorithm. They do not prevent attack by a sufficiently powerful attacker.
"""
smime.p7s
Description: S/MIME cryptographic signature
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- RE: [jose] Secdir review of draft-ietf-jose-json-web-signature-31, (continued)
- Re: [jose] Secdir review of draft-ietf-jose-json-web-signature-31, John Bradley
- Re: [jose] Secdir review of draft-ietf-jose-json-web-signature-31, Richard Barnes
- Re: [jose] Secdir review of draft-ietf-jose-json-web-signature-31, John Bradley
- Re: [jose] Secdir review of draft-ietf-jose-json-web-signature-31, Richard Barnes
- Re: [jose] Secdir review of draft-ietf-jose-json-web-signature-31,
John Bradley <=
- RE: [jose] Secdir review of draft-ietf-jose-json-web-signature-31, Jim Schaad
- Re: [jose] Secdir review of draft-ietf-jose-json-web-signature-31, Richard Barnes
- RE: [jose] Secdir review of draft-ietf-jose-json-web-signature-31, Jim Schaad
- Message not available
- Re: Secdir review of draft-ietf-jose-json-web-signature-31, Tero Kivinen
- RE: Secdir review of draft-ietf-jose-json-web-signature-31, Mike Jones
- RE: Secdir review of draft-ietf-jose-json-web-signature-31, Tero Kivinen
- RE: Secdir review of draft-ietf-jose-json-web-signature-31, Mike Jones
- RE: Secdir review of draft-ietf-jose-json-web-signature-31, Tero Kivinen
- RE: Secdir review of draft-ietf-jose-json-web-signature-31, Mike Jones
- RE: Secdir review of draft-ietf-jose-json-web-signature-31, Mike Jones
|
|
|