 Hello, welcome back to our last lecture on public key infrastructures. You might have a feeling by now that PKI does not work exactly just as well as one would like. In particular, the case of X509. And in particular, after learning how a certificate revocation works or should work and doesn't really work, see the last mini lecture. Now in this last lecture I would like to talk about the substantial improvements that have been made to X509 over the last five to seven years. Let's take a step back in history because it can be both entertaining and instructive. The dangers of having this multi-CA root store where each CA is equal to every other CA, this famous forest of disjoint trees. Well these dangers were actually recognized pretty early. For example, Radia Perlman wrote a paper about it, or a longer paper that included it in 1999. Carl Ellison and Ruth Schneier wrote another one in 2000. And the consensus of these authors was always, the cryptography is not our problem. Our public key cryptography works pretty well. The big problem that we have are the operational practices like identity verification by a CA, which you may recall was initially done by insecure email. There are some better practices today. However, identity verification is still by far not as secure as you might want it to be. And attacks did occur. They are poorly documented, that is true, but they occurred as early as 2001 with a famous forged certificate for a Microsoft certificate. And they became a lot more widely known since 2008 when a number of small scale attacks were staged against CAs. Now, you might have heard of the term Diginotar, which was an important CA in the Netherlands. And there is a prelude to the story of Diginotar. In March 2011, a so-called sub-seller of the Komodo CA was hacked. In essence, a business that was kind of a franchise to Komodo, we can at least think of it as a franchise, and that could trigger the issuance of a new certificate. And they were hacked. And they reshoot about 10 certificates that we know of for high value domains. And this was actually found when people inspected the source code of browsers and suddenly found that, hey, all browsers are suddenly blacklisting a number of certificates in the source code. Why? Why are they doing this? Well, yes, because the CA was hacked. Why did they not use revocation? Think about it for a moment. I'll give you my poker face for a few seconds so you can stop the video and then return. All right, let's continue. The reason is, once a CA is actually hacked and compromised and you don't have a good idea of how much it has been compromised, it is safest to assume it has been completely compromised, which means all private keys have been compromised, including those that you need to create revocation lists and implement OCSP. Hence, browsers had no choice. In order to avoid attacks using those certificates, they had to blacklist certificates in their own source code. And that is how the entire thing came to the light, or at least it came to the light a little bit earlier than the browsers had intended to do, because Komodo had asked for a short period where the news about this hack was sanctioned. So these blacklist certificates could be rolled out in the browser source code. Interestingly, the attacker began to communicate with the public, claimed to come from Iran, and he is indeed, or they are indeed, assumed to have control over the CA's private keys. That was in March 2011. Fast forward a few months when the same thing happened to Diginotar. Diginotar to this day has the rather dubious distinction of being the most famous and successful attack against the CA. The attacker claimed to be the same one as in March, but this time he did it a little bit more extensively. There are at least 531 fake certificates that we know of issued for high value domains, including Google, Facebook, Mozilla. For good measure, the CIA and Mossad, but also Skype. There is some evidence that these certificates might have been used in a person in a middle attack in Iran. If you want, Google for the terms operation black tulip. And then look for a report by a company called Fox IT, which investigated how this entire hack could really happen, how the compromise happened. I promise you, during a rainy afternoon, that is highly entertaining literature. Diginotar became famous because it was the first time that a CA was actually removed from a browser root store for being compromised, in particular for being compromised and not having noticed very much in the first place themselves. Now enter a defense that has been proposed by Google and is now an internet standard. Certificate transparency. I'll give you the ideas. The fundamental idea of certificate transparency, as the name implies it's about transparency, is that you're going to log information about every certificate that has been issued. And you're going to log it with a number of distinct parties. The logs are implemented in a particular kind of data structure that is publicly readable, but is append only. Their goal is to have an audit trail. The logs do not care at all if the information they receive and log is correct. They're completely agnostic to it. All they guarantee you is that they are not going to delete or modify previous entries. And the information is publicly available. And every new entry that they add is going to be signed and timestamped. This makes it quite transparent who issues certificates to whom and when, if you can get the buy-in of CAs to log, which was possible in this particular case, because Google was behind the standard. Now the logs are going to talk to everyone. They are publicly available. So anyone can verify their content and their correct operation as well. And anyone can try and find if there is a rogue CA that is issuing certificates for a domain after the fact, after this has happened. The goal of certificate transparency is to detect that something has happened and to make it transparent who is responsible, but it is not a direct defense for clients. One little more information, of course, you would like to avoid that logs are somehow clustered in one particular jurisdiction. So the standard envisages that about 30 or 40 logs are going to be positioned around the globe by different parties in different jurisdictions. Now, how does certificate transparency work? Here are the key ideas. The technology is a lot more complex than that. That's also one criticism of it. But we're going to give you the most important ideas now. Two, be accepted into the Chrome browser store. Every CA must participate in certificate transparency. That's how the entire system was pushed into the market. And a CA must lock the issuance of a certificate with at least two locks to incorporate it. The locks are going to return a so-called signed certificate timestamp, proving that they have accepted the certificate for inclusion. The SCT technically does not say the certificate has already been included. It only guarantees it is going to include it within a short time span. The SCTs are intended to be forward to the actual domain operator. And clients, browsers, learn about SCTs via various methods. One is the most common, included directly in the certificate that has been issued. But there are different methods that can, in theory, be used. This gives you a proof and a proof that is going to be distributed across the world, across clients, that a certificate has been locked and hence it has been issued. It establishes an audit trail for the logging of certificates from all participating CAs. This transparency now allows you to have monitoring for certain events. For example, if you're a domain operator, you could go and monitor locks if some other CA issuance certificates for your domain. And of course, this is done for high value domains, particularly Google, Mozilla, Microsoft, these kinds of domains. Now, these are the parties to certificate transparency, the locks in the middle that provide the publicly auditable audit trail, an append-only lock of certificates. They also provide proofs of inclusion. Then we have a browser that who can verify the proof of inclusion, and we have a CA that issues certificates. These are the principle. The most common way how this works is the following. We begin in the upper right corner with a CA who issues a so-called pre-certificate. This is not a real certificate. It contains a kind of poison string that says I am not a certificate. But this certificate can be sent to the CT log, and it contains all the information needed to create the SCT. The SCT is sent back to the CA, who then goes and includes it in the certificate and issues the entire thing. So it can be deployed on a web server. And whenever a browser comes and accesses the web server or receives a certificate, there are certain transformations that can be done. And then the entire certificate and SCT can be validated. That's the mode of operation. Now, as I said, the technology is considerably more complex than I can describe here. In particular, you're going to add several more kinds of monitoring. That's the entire issue. How do I make sure the lock that I'm curing is indeed honest? And here, for example, you can have some kind of cross verification between locks, and you can have different monitoring and auditing tools, making sure that they do what they promise to do. There are several options. The last one that I described is the one proposed in the standard, which is to have two kinds of auditing. On the whole, certificate transparency, even though it was pushed into the market by a single company, Google was remarkably successful. We already have evidence from the last few years where it detected issuance processes by CAs that did not comply with the governance that was agreed on, and it showed its worth in being able to detect malicious activity or at least rogue activity. It has added transparency to the X519 process in the hope of detecting malicious behavior relatively early. The reinforcement it provides to X519 comes from the fact that it essentially turns PKI inside out. Rather than being an opaque process, the issue in the certificate is now in the public, and that means there is public pressure on CAs to do that job well. As it is designed, CT is also remarkably strong. There are a number of proposals to reinforce X519, by the way, and CT ranks right at the top as one of the strongest ones to be able to even thwart attacks by state-level attackers. This concludes our entire lecture on PKI. If you have a deeper interest in the topic, I suggest you take follow-up courses on the security of PKI, TLS, and internet security measurement. Thank you for your attention.