On Feb 15, 2016, at 6:27 AM, Medin, Steven <[email protected]> wrote:
If I grant the 1% probability (which I can't), that leads to maybe 10-15
attempts to get bingo. In my past practice, our guard would be raised for the
third set of requests from an external party. The manual processes, even with
a bribe/plant inside the CA, do work. One person cannot act alone at any part
of the process. No matter how persuasive, they can't force 10:19:36 AM Friday.
Granted, signing subordinate CAs does get procedural, but it doesn't get
time-precise.
About the 1%, we're talking about an air gapped process. Each additional
request faces logistics before it clears to get near the root that are
influenced by multiple people. During the attack that led to requiring serial
entropy, hundreds of requests were submitted per second to cause the proper
serial number to be received with the proper validity dates. The process
auto-approved requests within a predictable 6 seconds. To work, it needed to
converge the sequential serial number and the datetime values.
I asked about the HSM relevance to the serial number of a CA or OCSP responder
certificate. I agree with the reasons for hardware and that HSMs have better
pRNG than sound cards.
Yeah, I saw the 00 serial discussion as well. In my past, we issued sequential
small serial numbers for roots and subordinates, but lately larger and random.
I'm not coming at this defensively, rather to think about the true value added
and whether a small serial number in a root or subordinate will mandate rebuild
of a PKI in the future. If we do encode it as a rule, then any CA should know
better from that point forward, and problem solved, but I'm talking about the
idea that the only thing better than more is more more more.
Kind regards,
Steve
-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+steve.medin=verizonbusiness....@lists.mozilla.org]
On Behalf Of Jakob Bohm
Sent: Sunday, February 14, 2016 5:08 PM
To: [email protected]
Subject: [E] Re: New requirement: certlint testing
On 14/02/2016 21:58, Steve wrote:
While time isn't entropic and in its minutes and seconds there are
more variable bits than the 20 required by policies, the main
influences in a subordination process are air gap, limitations on the
number of rounds, and lack of control of the plaintext.
I read it as 20 *bytes* (160 bits) corresponding to the minimum supported
serial number size in some of the standards (and the maximum ditto in too many
versions of NSS).
Subordination occurs with paper contracts and security officers and
internal auditors and sneakernet. That produces both controls and low
predictability. In my experience, an outlying case would be where an
external candidate for subordination receives more than two sets of
certificates in response to requests.
This would not help against the attacks I was trying to guard against (more
below).
In every case where practical and possible and a volume of key use
events are occurring, serial entropy has a value. But in justifying
that you make two points I'd like to explore further:
- What low-round attacks could exploit creation of a two byte
sequential serial in a case where the submitter does not control the
entire plaintext? Or the serial number itself? Or the submission
process? The Playstation attack was not just 18 hour birthdaying, it
was discovery of a pliable and predictable CA issuance process. It
was watching the pace of sequential serial number progression for
weeks, nudging it even, to get near the target number near the target
date. It was flooding the system with auto-approved requests for
sequentially assigned serial numbers and predictable validity date/time when
that t-minus six seconds moment arrived.
Let's assume (for purposes of argument) that within the 10+ years lifetime of a
root, a major adversary discovers an unpublished attack which requires getting
the CA to sign a message whose hash matches some pattern, and that this can be
achieved with a reasonable probability (say 1%) by getting the CA to sign a
certificate with certain combinations of the requestable field values combined
with prediction within a small (but not zero) margin of the CA selected field.
Such an adversary could quietly observe the pattern of issued certificates
(which are public and can be observed with no active attack or active
requests), then pay/place someone in the margins of the CA organization to
place a calculated request at a time where the signing circumstances will be
fairly predictable (e.g. it will probably be signed within a given 2 hour
period, beginning 10 days after the request). Repeat as necessary until the 1%
bingo is hit.
- Why does HSM vs software keys matter? That's hypothetically, as all
subordinate keys are in HSMs. The subordinate exists already, signed
by either a root or senior subordinate. Its own serial (arcane use of
AKI
aside) isn't relevant to that which it signs. Same question goes for
inner sanctum vs fielded certs.
I was trying to emphasize that the private (and thus public) keys submitted for
signature were not generated from a lesser source, such as a CA operated web
server with software key generation, or from a too easily compromised (i.e.
large) part of the CA organization, or transported in a way subject to
interference.
This of cause because those public keys contain the largest amount of entropy
in the certificates, and the best place to introduce malicious bits of
non-entropy.
The key storage is not as important as the fact it was generated in a provably
secure and uncompromised way. A later compromise of the signed key is much
less a problem as far as attacks on the CA signature process is concerned.
Though it might be used in a much more difficult attack on the CRL or OCSP
signing process, by reporting (possibly
uncompromised) chosen certificate serial numbers for revocation.
Ultimately, yes, do the best things everywhere, no dispute whatsoever.
But among us, can we share an opinion that there comes a point on a
cold winter night when another blanket offers no value? Rationalizing
two byte serials in offline processes rather than encoding their
prohibition into audit isn't an attempt to keep us awake worrying,
it's more to prevent smothering us.
This was inspired by reports (in recent weeks, on this list, maybe even in this
thread, I don't recall right now) that some CAs had actually assigned low
(single digit even) serials to some of the initial certificates of the types I
mentioned.
Thus the exception was meant to allow current practice in cases where it is
obviously completely safe, but to reign in this to such obviously safe cases in
a way that can be routinely checked in both Mozilla monitoring and independent
official audits.
On Sun, Feb 14, 2016 at 1:48 PM Jakob Bohm <[email protected]> wrote:
On 12/02/2016 12:03, Medin, Steven wrote:
There's no requestor control of validityNotBefore for an offline CA
signing
event, and certainly none with an online CA since the Playstation attack.
There's limited control of toBeSigned: CAs will grab the asserted
subject DN, public key, and toss the decorations in the PKCS#10
away. They'll
amend
the DN as they see fit based on vetting and any omissions and set
validity
dates based on the moment the offline root is exposed to perform the
event.
They're bringing multiple humans together at an externally
unpredictable time (timezone even) and day.
Even though subordination can be external or beyond core PKI realm,
you can't get chosen plaintext or birthday with an offline CA.
RapidSSL was another story entirely and even though they were an
outlier, the 20-bit serial entropy that resulted was certainly
warranted at the end entity
tier.
-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+steve.medin
[email protected]
zilla.org] On Behalf Of Jakob Bohm
Sent: Thursday, February 11, 2016 1:23 PM
To: [email protected]
Subject: Re: New requirement: certlint testing
It remains an important security measure when signing anything
requested from outside, including 3rd party sub-CA certificates,
cross certificates for the roots of other CAs, certificates for more
remote parts of the
CA's
organization (such as certificates for the Symantec software
business
issued
by a Symantec owned CA) etc.
Note that the realistic variation in the validity dates (as seen from
someone already well enough posed to submit requests in the first
place) is a lot less than the 160 bit minimum of serial number entropy.
Just because the offline CA processes poses a significant slowdown of
any attacks, it does not entirely prevent attacks that require a low
number of "rounds", where each round submits 1 or more requests and
awaits the signed certs.
Hence my suggestion that as a prudent security measure, seemingly
random serial numbers should still be generated for any requests not
from the innermost circle of the CA operations "castle". Examples
that would be excluded would be self-signing the root certificate and
signing any locally hosted major subsystems generating their keys in
local high security hardware, such as some locally hosted subCAs and
some OCSP responders. However it would not be prudent for requests
generated or transmitted through less secure systems, such as
software-only OCSP responders or systems located off site (or just
outside the doubly secured inner sanctum of the building).
In Mozilla policy terms this would imply that Mozilla typically
cannot know if such CA-related certificates are securely on-site and
thus should not enforce the 160-bit randomness rules for certificate
types where this exception might apply.
However auditors *should* (perhaps in a future CAB/F BR) be required
to specifically check that any low-entropy-serial-number certificates
generated do in fact refer to such secure on-site systems. As these
will be low in number (perhaps less than 10), and each directly name
the system they refer to, this would be a simple case of traditional
by-the-numbers auditing:
"An automated log search (similar to the crt.sh tools but run against
more complete internal logs) listed the following certificates with
low entropy serial numbers: A.B, C.D, E.F and G.H, A.B is the root
cert, OK. C.D is the HSM in the OCSP responder on shelf 3 in rack 2
in the secure cage, OK. E.F. (revoked) was the HSM in the old subCA
on shelf 5 in rack 1 in the cage, which has been decommissioned and
securely destroyed as per audited document 234, OK. G.H is the HSM
of the current off-line EV subCA on shelf 1 in rack 1 in the cage,
that issues batches of end entity certificates in a daily ceremony
and updated revocation data in more frequent ceremonies, OK. All
accounted for and in line with the requirement, next item."
(Of cause the published audit would omit the specific locations of
those servers, that would be in an longer internal document available
only to insiders).
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This
public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej
29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion
message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
