On 06/11/2012 11:06 AM, Ben Laurie wrote: > On Mon, Jun 11, 2012 at 1:56 AM, Nico Williams <[email protected]> wrote: >> On Sun, Jun 10, 2012 at 3:03 PM, Florian Weimer <[email protected]> wrote: >>> * Marsh Ray: >>> >>>> Marc Stevens and B.M.M. de Weger (of >>>> http://www.win.tue.nl/hashclash/rogue-ca/) have been looking at the >>>> collision in the evil CN=MS cert. I'm sure they'll have a full report >>>> at some point. Until then, they have said this: >>> >>>>> [We] have confirmed that flame uses a yet unknown md5 chosen-prefix >>>>> collision attack. >>> >>> Does this mean they've seen the original certificate in addition to >>> the evil twin? >> >> The evil twin has the nasty bits[*] in the issuerUniqueID field, which >> is weird, and the ID is not one likely to be generated by any CA. >> Would the original have it?? I don't see why the TS CA would have >> issued certs with issuerUniqueIDs under any circumstances, which is >> why it's interesting the the evil twin had any evil bits. > > Surely the whole point is that the collision is used to switch > <something> to issuerUniqueID in order to hide the stuff that would've > stopped the cert from working. I haven't looked, but I'm prepared to > bet it would not be hard to figure out what the original cert must > have looked like.
The <something> was almost surely ASN.1 structure for extensions, since it's right after SPKI structure and last field in TBSCertificate structure. The other options (issuerUID and subjectUID) are almost never used (seems that UIDs can't be part of CSR). Extensions and issuer/subject UID are at the same level in the ASN.1 tree. Thus if the hypothesis about MD5 collision is true, attacker needed to flip just one tag-length-value (TLV) tuple, any remaining bits flipped due to collision could be hidden inside the bitstring value of issuerUID. Here's what the "evil twin" headers probably looked like (starting with the place where issuerUID encoding begins): MS.der (the one we have): 81 82 03 78 00 6A 4C E0 ... for issuerUID - tag identifier octet 0x81, length encoded in 2 bytes (0x82), length 0x378 - 00 6A 4C E0 ... are the first bytes of value MS-evil-twin.der (one we don't have): A3 82 03 78 30 82 x y ... for extensions - tag identifier octet 0xA3, length encoded in 2 bytes (0x82), length must be the same 0x378 - "30 82 x y" stand for internal constructed sequence of extensions, followed probably again by "30 n" because every extension is sequence Starting with the tag identifier octet, the changes between the two are (counting bits from 1): - class is unchanged (context-specific, highest bits 10) - bit 6 (primary/constructed) flipped to 0 (primary); flipping from constructed has advantage of not having to fix additional TLV inside a constructed bitstring - octet 0xA3 encodes the [3] tag, constructed (constructed requires TLV to follow, like the 30 82 ...), [3] meaning this should be interpreted as extensions - octet 0x81 encodes the [1] tag, primitive, implicit from spec, interpreted as bit string 00 6A 4C E0 ..., [1] meaning it should be interpreted as issuer UID In the "evil twin certificate" the first extension would have probably been an extension with a string field which the signing software considers harmless. That would allow the signing to occur and "pad" that string field with other flipped bits that could otherwise screw the cert's interpretation. Still, that's quite a few bytes that need a fixed value around the place of collision in the "evil twin certificate". Second strange thing I noticed is that OIDs for the two signature algorithm fields differ: md5WithRSA (1 3 14 3 2 3) and md5withRSAEncryption (1 2 840 113549 1 1 4) - RFC 5280 says they must be the same. > Has anyone got the evil cert as a binary? I could probably reconstruct > it from the bazillion dumps out there, but I can't be bothered. It was attached to one of Marsh's posts, attaching DER-encoded again. Took me a while as well to realize that we have it already - the certutil.exe dumps on the web have byte order of signature reversed. Ondrej
MS.der
Description: application/x509-ca-cert
_______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
