Re: Apple: Non-Compliant Serial Numbers
> 1. How many of the 54,583 certificates are issued to Apple owned and > operated servers and services and how many not. All impacted certificates were issued to Apple entities > 2. What kinds of practical issues are delaying the replacement of > certificates on any such Apple operated servers and services, > perhaps with approximate percentages. A number of factors have impacted replacement timelines for the large number of disparate teams affected: - work required to migrate systems to an internal, enterprise PKI - QA and change control processes - prioritization of tasks - level of automation - freeze periods associated with existing operational schedules ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Entropy of certificate serial number
Hi Tim, Thanks for your reply. First to your questions: 1. The purpose of serial number is to identify the certificate, not to make it secure. It will be used in the CRL, OCSP, etc. as identifier. 2. Unfortually yes, you can change the SAN and some non-critical extensions to get the same hash value over tbsCertificate if the hash algo is not cryptographically secure. 3. Yes only SHA256 can be used in the new certificate, but what about those existing with SHA1? They still remain valid for given period of time. This may also happen for SHA256. 4. Remember that SHA256 is only 128 bit secure, not 256. So 159 bit is large enough. 5. Related to how the MD5 attacks you might be right. But theoretically, and also in practice, if you have enough bits to play and the hash algorithm is not cryptographically secure, you can find a collision with less complexity than the claimed one. So IMO the only reason to increase the entropy of serial number is not to increase the security, but to reduce the possibility to issue certificate with identical serial numbers, since not all CAs have mechanism to prevent from this. Best regards Lijun On Fri, 5 Apr 2019, 19:15 Tim Shirley wrote: > 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 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=8fen3GYDv5KnmIy2Xr-0e5uaoDeNGtjgffCW9PJ80w=5=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy > >> > > > ___ > dev-security-policy mailing list >
RE: Entropy of certificate serial number
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 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=8fen3GYDv5KnmIy2Xr-0e5uaoDeNGtjgffCW9PJ80w=5=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=8fen3GYDv5KnmIy2Xr-0e5uaoDeNGtjgffCW9PJ80w=5=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
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 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://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
Re: Entropy of certificate serial number
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://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
Entropy of certificate serial number
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://lists.mozilla.org/listinfo/dev-security-policy
