If it were possible to do what you're suggesting, there's no reason you'd need to use the serial number for it. You could just as easily add that randomness in an additional SAN, or a certificate extension that the browser didn't care about. In fact, since the BRs require SHA-256 as a minimum hash algorithm, and you only have 159 bits to work with in the serial number field, there's only a 1 in 2^97 (158 billion billion billion) chance that would give you enough randomness to where there even exists a value you could set that would work (ignoring the challenge of finding that value.) I've not heard of any attacks where someone could start with an already-issued certificate and work backwards to find a collision, however.
The MD5 attack (https://fahrplan.events.ccc.de/congress/2008/Fahrplan/attachments/1251_md5-collisions-1.0.pdf) was predicated on the attacker knowing exactly what was going to be in the certificate outside of the bits they control, far enough in advance of it being issued to be able to do the collision calculations to determine what other inputs they could feed in to make the collision possible. That exact prediction of the contents of the certificate had to include the actual values of the "not before" and "not after" to the second as well as the serial number value. Any unpredictability in those fields makes that attack harder, and 64 bits of unpredictability makes it effectively impossible. That was the motivation behind the requirement as I understand it. -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-boun...@lists.mozilla.org] On Behalf Of Lijun Liao via dev-security-policy Sent: Friday, April 05, 2019 11:44 AM Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Entropy of certificate serial number With random serial numbers an adversary does not even need to guess the serial number. Consider the following attack, the adversary finds a certificate with weak hash algorithm. He adds his host to the SAN field, then he tries to find out a positive serial number up to 20 octets which results in the same hash of the tbsCertificate. Since the serial number octets are random, one cannot find out whether this is a modified certificate or not. Indeed in this case, higher entropy simplifies this attack. Best regards Lijun On Fri, 5 Apr 2019, 17:24 Alex Gaynor <agay...@mozilla.com> wrote: > Hi Lijun, > > Entropy is required in serial numbers to protect against weak hash > functions -- historically exploitation of MD5's weakness was possible > because CAs used sequential serial numbers, thus allowing an attacker to > pre-compute hash prefixes, because they could predict future data that > would be signed's prefix. The exact value of 64 comes out of a Microsoft > Root Program requirement that was later incorporated into the BRs, as I > recall. > > Cheers, > Alex > > On Fri, Apr 5, 2019 at 11:20 AM Lijun Liao via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> In the last days, the issue related to the 63 bit serial number by using >> the default configuration of EJBCA poped up in many forums. >> >> Could someone please explain why the BR requires the minimal entropy to be >> 64 bit? >> >> Best regards >> Lijun >> _______________________________________________ >> dev-security-policy mailing list >> dev-security-policy@lists.mozilla.org >> https://scanmail.trustwave.com/?c=4062&d=8fen3GYDv5KnmIy2Xr-0e5uaoDeNGtjgffCW9PJ80w&s=5&u=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy >> > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://scanmail.trustwave.com/?c=4062&d=8fen3GYDv5KnmIy2Xr-0e5uaoDeNGtjgffCW9PJ80w&s=5&u=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
