Re: Entropy of certificate serial number
On 06/04/2019 03.01, Lijun Liao via dev-security-policy wrote: > 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. No, not in practice. There are different levels of "not cryptographically secure". What you are talking about is preimage resistance - the ability to construct an input to the hash algorithm that produces a given, fixed, arbitrary output. There are no such practical attacks on MD5 or SHA-1. What the serial number entropy requirement seeks to mitigate are collision attacks, in particular chosen-prefix collision attacks. This is the attack that was used to break MD5. This means that you can construct two messages with the same hash, by modifying both, given a chosen (known, not modifiable) prefix for each message. Due to the Merkle-Damgård construction of MD5 and SHA-1, these collisions are also inherently arbitrary-suffix (after you get two partial messages to collide, you can append the same arbitrary data to both and they will still collide). The serial number entropy requirement effectively mitigates collision attacks, because the serial number is one of the first pieces of information in the certificate, well before any attacker-controlled data. In order to implement a chosen-prefix collision attack, you need to predict the serial number. If the serial number has at least 64 bits of entropy, then you would have to try to obtain around 2^63 colliding certificates on average to match a precomputed collision. Note that the birthday paradox does not apply here, because any given certificate can only be obtained for any given collision attempt; it doesn't matter if you compute 2^32 collisions and then try to get 2^32 certificates, because *each one* of those certificates has to be obtained for a *single* collision attempt embedded into it. Note that the practical SHA-1 attack that was demonstrated was even weaker than this, as it wasn't a chosen-prefix attack (each message has a different prefix), but rather an identical-prefix attack (each message has the *same* prefix, and the messages only differ in the collision-generating blocks). This is less powerful, but still sufficient for practical attacks, e.g. I bet you could combine it with the x.509 structure to yield useful conditional parsing, much like the demonstrated SHA-1 collision combined it with the JPEG structure to yield conditional parsing. The serial number entropy requirement also mitigates this weaker attack, of course. -- Hector Martin "marcan" (mar...@marcan.st) Public Key: https://mrcn.st/pub ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Arabtec Holding public key? [Weird Digicert issued cert]
On 11/04/2019 04:47, Santhan Raj wrote: On Wednesday, April 10, 2019 at 5:53:45 PM UTC-7, Corey Bonnell wrote: On Wednesday, April 10, 2019 at 7:41:33 PM UTC-4, Nick Lamb wrote: (Resending after I typo'd the ML address) At the risk of further embarrassing myself in the same week, while working further on mimicking Firefox trust decisions I found this pre-certificate for Arabtec Holding PJSC: https://crt.sh/?id=926433948 Now there's nothing especially strange about this certificate, except that its RSA public key is shared with several other certificates https://crt.sh/?spkisha256=8bb593a93be1d0e8a822bb887c547890c3e706aad2dab76254f97fb36b82fc26 ... such as the DigiCert Global Root G2: https://crt.sh/?caid=5885 I would like to understand what happened here. Maybe I have once again made a terrible mistake, but if not surely this means either that the Issuing authority was fooled into issuing for a key the subscriber doesn't actually have or worse, this Arabtec Holding outfit has the private keys for DigiCert's Global Root G2 Nick. AFAIK there's no requirement in the BRs or Mozilla Root Policy for CAs to actually verify that the Applicant actually is in possession of the corresponding private key for public keys included in CSRs (i.e., check the signature on the CSR), so the most likely explanation is that the CA in question did not check the signature on the Applicant-submitted CSR and summarily embedded the supplied public key in the certificate (assuming Digicert's CA infrastructure wasn't compromised, but I think that's highly unlikely). A very similar situation was brought up on the list before, but with WoSign as the issuing CA: https://groups.google.com/d/msg/mozilla.dev.security.policy/zECd9J3KBW8/OlK44lmGCAAJ While not a BR requirement, the CA's CPS does stipulate validating possession of private key in section 3.2.1 (looking at the change history, it appears this stipulation existed during the cert issuance). So something else must have happened here. Except for the Arabtec cert, the other certs looks like cross-sign for the Digicert root. Why still no response from Digicert? Has this been reported to them directly? 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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Arabtec Holding public key?
True, we don't know their intentions but we can at least assume they would need private keys to use said certificates with any properly implemented user agent. Ryan Hurst (personal capacity) On Thu, Apr 11, 2019 at 6:12 PM Peter Gutmann wrote: > admin--- via dev-security-policy > writes: > > >The risk here, of course, is low in that having a certificate you do not > >control a key for doesn't give you the ability to do anything. > > As far as we know. Presumably someone has an interesting (mis)use for it > otherwise they wouldn't have bothered obtaining it. > > Peter. > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Arabtec Holding public key?
admin--- via dev-security-policy writes: >The risk here, of course, is low in that having a certificate you do not >control a key for doesn't give you the ability to do anything. As far as we know. Presumably someone has an interesting (mis)use for it otherwise they wouldn't have bothered obtaining it. Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Arabtec Holding public key?
Unfortunately, the BRs make no stipulation on how Proof of Possession is done (https://github.com/cabforum/documents/blob/master/docs/BR.md#321-method-to-prove-possession-of-private-key). Most CAs, in my experience, simply treat the signature on the CSR as sufficient to demonstrate control of a given key. Specifically, they do not don't require any specific data to be included in the CSR so it is only linked with the metadata to be included in the CSR via the session they were both submitted in. This is, of course, doesn't prove the CSR was created for that particular request. For that to be true there would need either be a challenge created by the CA, included in the CSR by the requestor or the CA would need to require the CSR contain the same data is included in the session. While the matching of the data in the CSR to the data in the session allows for CSR replay, it does mitigate the risk. ACME takes this approach where they say (https://tools.ietf.org/html/rfc8555): The CSR encodes the client's requests with regard to the content of the certificate to be issued. The CSR MUST indicate the exact same set of requested identifiers as the initial newOrder request. My guess is that the CA in question does not have either check. The risk here, of course, is low in that having a certificate you do not control a key for doesn't give you the ability to do anything. Ryan Hurst (personal capacity) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Arabtec Holding public key?
在 2019年4月11日星期四 UTC+8上午7:41:33，Nick Lamb写道： > (Resending after I typo'd the ML address) > > At the risk of further embarrassing myself in the same week, while > working further on mimicking Firefox trust decisions I found this > pre-certificate for Arabtec Holding PJSC: > > https://crt.sh/?id=926433948 > > Now there's nothing especially strange about this certificate, except > that its RSA public key is shared with several other certificates > > https://crt.sh/?spkisha256=8bb593a93be1d0e8a822bb887c547890c3e706aad2dab76254f97fb36b82fc26 > > ... such as the DigiCert Global Root G2: > > https://crt.sh/?caid=5885 > > > I would like to understand what happened here. Maybe I have once again > made a terrible mistake, but if not surely this means either that the > Issuing authority was fooled into issuing for a key the subscriber > doesn't actually have or worse, this Arabtec Holding outfit has the > private keys for DigiCert's Global Root G2 > > Nick. I also found some other certificates have the same situations and same domain name： https://crt.sh/?ski=e8727721a7e63945d10041d9bef301c11eaa63b1 There are serveral certificates have same public keys and notBefore. All of them were issued by DigiCert SHA2 Secure Server CA. There certificates have different domain names and organizations. https://crt.sh/?id=907553401 https://crt.sh/?id=884275649 https://crt.sh/?id=924345151 Mirro ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
