G’day Corey,
I did not check your math, but is it possible that you are interpreting the
serial number conversion output as an unsigned integer representation? If so,
then I can understand your potential concern regarding the findings of your
analysis.
DarkMatter uses an EJBCA platform with the requisite setting for 64-bit random
serial numbers and our source of entropy is a FIPS140 certified HSM, so I too
was surprised by the findings you reported. However, during our investigation
of this potential issue, we have thus far discovered that the platform appears
to be compliant with the requisite standard, and the anomaly you are
highlighting is potentially due just to the integer representation you are
using in your calculations.
RFC5280 (section 4.1.2.2) defines serialNumber to be a positive INTEGER, and
X.690 defines INTEGER to consist of one or more octets and (specifically
section 8.3.3) says the octets shall be a two’s complement binary number equal
to the integer value. Using the two’s complementary representation means that
the output of the octet conversion is a signed integer, and it could be
positive or negative – the range of integers from 64-bit numbers being from
–(2^63) to [+ (2^63)-1]. But since the RFC requires only positive integers, the
64-bits of output from the CSPRNG function must eventuate only in positive
numbers, and negative numbers cannot be used. In two’s complement
representation, the leading bit determines whether the number is positive or
negative – for positive numbers, the leading bit will always be zero (if it’s a
1, then that represents a negative number which RFC5280 prohibits).
So our findings are that the platform is indeed using 64-bit output from an
appropriate CSPRNG for generating serialNumbers, and that the leading zero is
exactly what is required to indicate that it is a positive number in two’s
complement representation of the INTEGER, which is the requirement under
RFC5280. Therefore our findings indicate that the serial number generation
scheme used by DarkMatter in it’s certificate hierarchy does meet the
requirements set forth in the Baseline Requirements, section 7.1.
Regards,
--
Scott Rea
On 2/25/19, 12:50 AM, "dev-security-policy on behalf of Corey Bonnell via
dev-security-policy" <dev-security-policy-boun...@lists.mozilla.org on behalf
of dev-security-policy@lists.mozilla.org> wrote:
On Friday, February 22, 2019 at 4:28:30 PM UTC-5, Corey Bonnell wrote:
> Hello,
> Section 7.1 of the Baseline Requirements states that, "Effective
September 30, 2016, CAs SHALL generate non-sequential Certificate serial
numbers greater than zero (0) containing at least 64 bits of output from a
CSPRNG".
>
> An analysis of the 23 known certificates (4 root CA, 6 ICA, 1 Audit CA,
and 12 end-entity interoperability/test certificates) in the DarkMatter
certificate hierarchy currently listed in the inclusion request indicates that
the hierarchy is likely not compliant with this requirement. Specifically, all
23 certificates have an 8-octet (64 bit) serial number, but the most
significant bit (big-endian) of their serial numbers is 0. The probability that
all 23 known certificates in the hierarchy having exactly 64 bits of output
from a CSPRNG with a most significant bit value of 0 is 1 in 2^23, or 1 in
8,388,608, which would make this a highly extraordinary event. The far more
likely case is that each certificate's serial number does not contain the
requisite number of bits (64) output from a CSPRNG.
>
> A detailed breakdown is as follows:
>
> "subject CN", notBefore, "serial number", "highest bit index set (1-based
indexing)"
>
> "UAE Global Root CA G3", 2017-05-17, 47:0E:FF:0B:2E:B3:83:40, 63
> "UAE Global Root CA G4", 2017-05-17, 1E:86:4A:1C:01:B1:46:3F, 61
> "DarkMatter Audit CA", 2017-05-18, 7B:02:F9:F1:42:64:C1:42, 63
> "DarkMatter Root CA G3", 2017-05-18, 6A:E6:CC:D1:A8:29:7F:EB, 63
> "DarkMatter Root CA G4", 2017-05-18, 61:17:4D:F7:2B:EC:5F:84, 63
> "DigitalX1 High Assurance CA G3", 2018-06-28, 75:50:D6:6F:78:B4:BD:F5, 63
> "DigitalX1 High Assurance CA G4", 2018-06-28, 6E:E0:2C:70:C9:43:17:16, 63
> "DM X1 High Assurance CA G3", 2018-06-28, 7D:DE:FE:2D:9F:05:74:DE, 63
> "DM X1 High Assurance CA G4", 2018-06-28, 40:17:D7:B9:DD:ED:20:55, 63
> exped.ca.darkmatter.ae, 2018-07-05, 12:5E:AF:E7:93:49:9A:95, 61
> expeu.ca.darkmatter.ae, 2018-07-05, 2B:65:3C:DB:5C:7D:F6:56, 62
> exprd.ca.darkmatter.ae, 2018-07-05, 55:E4:A1:AE:7C:A3:64:14, 63
> expru.ca.darkmatter.ae, 2018-07-05, 74:EE:AC:88:24:3D:F9:E4, 63
> reved.ca.darkmatter.ae, 2018-07-05, 1A:E6:DA:22:59:06:AD:C1, 61
> reveu.ca.darkmatter.ae, 2018-07-05, 0D:B3:3E:12:5A:4A:11:DF, 60
> revrd.ca.darkmatter.ae, 2018-07-05, 0D:C6:08:0C:4F:B4:76:63, 60
> revru.ca.darkmatter.ae, 2018-07-05, 6F:5A:8C:4F:54:FC:3A:E2, 63
> valed.ca.darkmatter.ae, 2018-07-05, 1E:40:E3:2D:DF:21:95:59, 61
> valeu.ca.darkmatter.ae, 2018-07-05, 65:84:D9:1D:F5:CE:C5:89, 63
> valrd.ca.darkmatter.ae, 2018-07-05, 3F:53:0E:C5:7D:F5:83:C5, 62
> valru.ca.darkmatter.ae, 2018-07-05, 14:CB:73:81:18:20:C5:25, 61
> "DigitalX1 Assured CA G4", 2018-09-05, 6D:9F:01:8E:40:8E:5F:7F, 63
> "DM X1 Assured CA G4", 2018-09-05, 71:9C:24:E8:9A:D9:44:AB, 63
>
> Thanks,
> Corey
I would like to bolster my previous assertion that the serial number
generation scheme used in the DarkMatter certificate hierarchy likely does not
meet the requirements set forth in the Baseline Requirements, section 7.1.
A further analysis of all DarkMatter-issued certificates which were logged
to Certificate Transparency logs with a notBefore date of 2016-09-30 or later
was performed. This certificate corpus of 235 unique certificates
(pre-certificate and final certificate pairs are considered to be a single
“unique certificate” to avoid double-counting) is overwhelmingly comprised of
end-entity TLS certificates, but there are also several infrastructure-related
certificates (such as OCSP Response Signing certificates, etc.) included.
DarkMatter has asserted that all publicly trusted TLS certificates that they
have issued are logged to Certificate Transparency logs, so this set of 235
unique certificates includes the entirety of publicly trusted TLS certificates
issued by DarkMatter since 2016-09-30.
This analysis has revealed that all 235 unique certificates have a serial
number of 8 octets (64 bits) and a big-endian most significant bit set to 0.
Given that the probability of all 64 bits being output from a CSPRNG with a
most significant bit value of 0 for all 235 such certificates is 1 in 2^235, it
is extremely likely that these certificates do not contain the minimum number
of bits (64) output from a CSPRNG and are therefore mis-issued under the
Baseline Requirements.
A comprehensive list of the 235 unique certificates can be found here:
https://gist.github.com/CBonnell/1f01ccd93667c37800b67e518340c606
Furthermore, two of the intermediates issued to DarkMatter which chain to
QuoVadis/Digicert roots violate RFC 5280, section 4.2.1.10
(https://tools.ietf.org/html/rfc5280#section-4.2.1.10). Specifically, the
dNSName in the nameConstraints extension's permittedSubtrees field contains a
leading period (".ae"), which violates the hostname syntax specified in section
4.2.1.10. Therefore, these two intermediate certificates
(https://crt.sh/?id=23432430&opt=cablint,
https://crt.sh/?id=19415522&opt=cablint) are also mis-issued under the Baseline
Requirements.
I have sent a Certificate Problem Report to Digicert to notify them of
these findings, as these intermediates and DarkMatter-issued certificates chain
to roots under their control.
Thanks,
Corey
Scott Rea | Senior Vice President - Trust Services
Tel: +971 2 417 1417 | Mob: +971 52 847 5093
scott....@darkmatter.ae
The information transmitted, including attachments, is intended only for the
person(s) or entity to which it is addressed and may contain confidential
and/or privileged material. Any review, retransmission, dissemination or other
use of, or taking of any action in reliance upon this information by persons or
entities other than the intended recipient is prohibited. If you received this
in error, please contact the sender and destroy any copies of this information.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
