On 16 March 2016 at 16:00, Bryan Ford <[email protected]> wrote: > I finally had a chance to take a look at the latest version of the threat > analysis document. > > Months ago, I pointed out that the document presents a lopsided view of the > potential types of attacks, in general considering only attacks in which CAs > or log servers misbehave “in place”, while completely neglecting even to > mention the large class of attack scenarios in which an attacker steals the > servers’ keys and uses them to create secret “evil twins” of the CAs and/or > log servers elsewhere on the Internet (or off the Internet) in domains more > under the attacker’s control. In other words, the attacker leaves the > “normal” CAs and log servers that most of the Internet sees operating > completely normally and appearing to be honest, but creates and uses evil > twins of those CAs and log servers elsewhere for (basically undetectable) > attacks against target victims. > > As far as I can see, this entire class of threats is still not even > mentioned in the threat analysis document, let alone analyzed. This seems > to me to be a fairly serious omission for a document that is supposed to be > a comprehensive threat model analysis for CT. > > The currently-raging Apple vs FBI case represents a great example of such a > threat, as explained in my recent Freedom to Tinker blog post: > > https://freedom-to-tinker.com/blog/bford/apple-fbi-and-software-transparency/ > > In short, suppose the FBI were attempting to secretly (rather than publicly) > coerce Apple to sign their backdoored software update, and further suppose > that the iPhone in question used something like Certificate Transparency in > attempt to provide transparency to software updates. The FBI would not need > to, and probably would not want to, make Apple’s software update server > (i.e., “CA”) misbehave publicly, or to make the CT log servers on which > those updates are normally logged misbehave publicly - but they wouldn’t > need to. They could instead just commandeer the keys of the “CA” (Apple’s > update server) and any two CT log servers (e.g., any two that conveniently > happen to be in the US) - or just coerce the holders of those keys to > secretly produce signatures of the FBI’s choosing - to produce not only an > apparently correctly-signed software update but also the fake SCTs, signed > log-heads, or whatever needed to persuade the CT-enhanced iPhone that the > correctly-signed software update has also been “logged”. > > But of course the FBI need not and would not ever need to show those fake > signatures or logs to anyone but the iPhone in question, “in utmost secrecy” > (the FBI’s words). The target/victim of the attack in this case is held and > thus completely “captured” by the FBI: it will never have any opportunity to > gossip with the outside world to compare SCTs or log heads or anything. > Thus, the FBI has created a “evil twins” of both the CA (software update > server) and log servers in attacker-controlled territory while leaving the > public versions of those services completely untouched and apparently > working fine as far as everyone else sees, and CT completely fails to reveal > the existence of these evil twins or the “misissuance” (backdoored software > updates) they have been used to sign. > > If this working group has decided that threats of this form are not of > interest or too unlikely to happen (despite the events playing out right > now), then I do not have the time to keep arguing the point. But at the > very least, the threat model analysis document should simply pretend that > such attack scenarios do not exist at all.
I do agree that these attacks can be mounted, and are in fact already discussed in general in 6962 and 6962-bis (s7.3 for the latter). I have still not yet had the time to thoroughly review the threat analysis document, so I can't comment on it at this time. In general, it seems hard to defend against attacks that permanently separate their victims from the rest of the world - and it also seems hard to mount such an attack. _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
