Subject: [saag] NSA bug in Windows 10

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 15 Jan 2020 09:59:15 -0500

I have been reading the reports in the press.

>From what I gather, the attack allows an incompetent or malicious CA to
craft a malicious certificate. It may also be possible for a CSR to be
crafted that could result in a CA issuing a bad EE cert.

>From the limited information I can find, it would appear that we don't
actually have much of a problem as the whole WebPKI is predicated on the
idea that CAs are trusted and they have pretty much infinite ways to defect.

Has anyone checked the Certificate Transparency logs to see if any bogus
certs matching the NSA pattern are recorded? I would expect not as we
require specific NIST curves that have specific names.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 15 Jan 2020 15:08:37 +0000

Phillip Hallam-Baker <[email-masked]> writes:

>certs matching the NSA pattern are recorded? I would expect not as we require
>specific NIST curves that have specific names.

Speculation: The universal standard for ECDSA is the NIST curves, with some
minor subset using the Brainpool curves, but in any case named curves.
However, the NSA being the NSA, I'll bet they use their own curves and not the
NIST ones [0], which were created in secret by some dodgy US TLA and then fed
to NIST.  So the reason for the NSA choosing to disclose the vulnerability may
be that it principally affects them and no-one else, which also means there's
not much chance of anything appearing in the CT logs.

Oh, and rumors that, since it's the NSA that's recommending the fix to a
Microsoft product, they've told them to double the security of their ROT13
implementation by applying it twice, are entirely false.

Peter.

[0] Suite B, which did use NIST curves, seems to have fallen by the wayside.

---

From: Dan Brown <[email-masked]>
Date: Thu, 16 Jan 2020 16:40:41 +0000

Based on what I hear others say online, I presume this bug resulted a
relying party using details of a received root certificate instead of a
details in the true trusted root certificate.

https://www.rfc-editor.org/rfc/rfc3280#section-6.1.1
item (d), (4) talks about parameters in the trust anchor certificate, and
the next paragraph talks about a "delivered ... trustworthy out-of-band".

If my presumption above is correct, then it seems that this part of RFC3280
was not followed in this bug, since the parameters were taken from an
untrustworthy in-band delivery.   That said, I wonder if RFC3280 adequately
emphasized this point? Could it have used a MUST?

Best regards, 

Dan 

----------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 16 Jan 2020 12:41:36 -0500

There is a paper I wrote circa 1995-96 on parameter substitution related
attack and developed a state machine for parameter inheritance for signature
verification in certificate chain and CRLs.

-----Original Message-----
From: saag [mailto:[email-masked]] On Behalf Of Dan Brown
Sent: Thursday, January 16, 2020 11:41 AM
To: Peter Gutmann <[email-masked]>; Phillip Hallam-Baker
<[email-masked]>; IETF SAAG <[email-masked]>
Subject: Re: [saag] NSA bug in Windows 10

Best regards, 

Dan 

----------------------------------------------------------------------
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this
transmission by unintended recipients is not authorized and may be unlawful.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 16 Jan 2020 20:02:14 -0800

> emphasized this point? Could it have used a MUST?

I remember reading something that involved taking an existing signature
made by a trusted root from a legitimate certificate issued by that root,
and re-using that signature with different domain parameters.  That would
seem to imply that the trusted root is properly being used, but the
validation code for the signatures in the chain was flawed.

-Ben

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 17 Jan 2020 06:54:25 +0000

Benjamin Kaduk <[email-masked]> writes:

>I remember reading something that involved [...]

Based on, admittedly, zero reading of stuff around this so far (trying to find
some time this weekend), I assume it's of the type covered here:

Digital Signature Schemes with Domain Parameters
https://lasec.epfl.ch/pub/lasec/doc/Vau04b.pdf

Or at least that's one possible vuln that you get from not checking domain
parameters.

Peter.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 17 Jan 2020 13:07:19 -0500

> validation code for the signatures in the chain was flawed.

OK so the attack seems to be

Root cert specifies Key A = {CurveA, PointA}

Root cert signs subordinate cert creating signature {CurveA, PointB}

Mallet can now generate a new signature {CurveM, PointB} which will
validate because the pathmath isn't checking the domain params, only the
curve point.

OMG we are doomed.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 17 Jan 2020 13:47:36 -0500

> Root cert specifies Key A = {CurveA, PointA}

In particular, the curve coefficients, the curve *generator* and the
root CA's public key (point).

> Root cert signs subordinate cert creating signature {CurveA, PointB}

The attacker creates a fake root cert with a different *generator*,
the simplest case is 'generator == public point, private key = 1'.

> validate because the pathmath isn't checking the domain params, only the

Mallet can generate any desired certificate chain with the new root
CA key.  No need to match anything pre-existing.  The new chains
will pass validation.

-- 
    Viktor.

---

From: Dan Brown <[email-masked]>
Date: Fri, 17 Jan 2020 18:54:27 +0000

> From: Benjamin Kaduk <[email-masked]>
> >
> > If my presumption above is correct, then it seems that this part of
> > RFC3280 was not followed in this bug, since the parameters were taken
from
> an
made
> by a trusted root from a legitimate certificate issued by that root, and
re-using
> that signature with different domain parameters.  That would seem to imply
> that the trusted root is properly being used, but the validation code for
the
> signatures in the chain was flawed.

Well, that attack does not match what I read.  

In what I read, a fake root cert is sent, and the receiver uses it.    Some
claim the bug is an incomplete match between the fake and real root cert,
but I claim the real bug is using the received cert at all. 

The receiver should just use the real root cert.  The receiver should keep a
full copy of the real root cert, to do this.  The receiver should discard
received root cert.   (But, perhaps, if the sender sends a root cert, then
the receiver may insist on an exact match, although such checks might allow
some kind of weak profiling attack - if there a multiple versions of the
real cert.)  Actually, the sender should not even send a copy C0' the root
cert, since C1, being allegedly issued by C0, should already identify C0
sufficiently, through the issuer field, no?  Who is the sender to tell the
receiver to trust C0'?

RFC 3280 is written as if the receiver did not have the real root cert C0,
but, for some reason has enough information about C0 to conduct a partial -
but secure if all the steps are done - match with a sent version C0' of C0.

To repeat, my view is that several claims of the fragility arising from the
excess of parameters in ECC certs is actually red herring. The fragility is
in RFC 3280, which seems to imply that the receiver does not keep C0' and
does some kind of secure, but partial match.  

By the way, new algorithms, from the land of PQC, are arriving soon, to a
PKI near you.  Off hand, I have no clue what parameters these new
algorithms. But I guess that they will ship with some kind of parameters,
since both the new algorithms and quantum computer are a moving target.
Instead of decrying parameters, just verify the signed parameters, use a
real root for the root parameters.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 17 Jan 2020 18:25:57 -0800

> but I claim the real bug is using the received cert at all. 

It seems that I had read too quickly or not read enough.
Thanks everyone for correcting me, and sorry for spreading confusion.

-Ben

---

From: Michael Richardson <[email-masked]>
Date: Sat, 18 Jan 2020 11:32:41 -0500

> sufficiently, through the issuer field, no?  Who is the sender to tell the

We had this discussion before, and while what you say is true for a majority
of live web/browser situations, it is not the whole story, and omitting C0
makes life very difficult.

We need the sender to send/include C0 for a great number of data-at-rest
situations, so we can consult and then pin C0.  We also need it for diagnostics.

The bug, is what you said: "the real bug is using the received cert at all"
The received bag of certificates need to be placed in an untrusted place, and
used only if they are validated by a trusted certificate.   The C0
certificate (being likely self-signed) clearly can never validate, so will
remain in the untrusted place.
(The middle place, for those who watched The Good Place)

    > does some kind of secure, but partial match.

I agree.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-