 Thanking you for coming to my talk. I know it is a bit difficult to attend the first talk the day, the night after the party. And I have had talks in which there were two people and three people because most of the people were sleeping over after the party. But yeah, so my name is Hosefa. I work with the Red Hat Product Security team. I am a part of various upstream security communities including Mozilla, LibreOffice, PHP, Samba, Python and a lot of others which I can't remember right now. And each year I come to DevCon and I talk about a security topic. And this year I am going to talk about two topics which are slightly unrelated but they are related to each other. I am going to talk about the recently discovered SKS keys for server flaws and I am going to talk about a little bit about PKI as well. So for people who don't know what PKI is or for people who don't know what SKS servers are, let us talk a little bit about public key cryptography. Modern internet and applications on modern internet are mainly possible because of public key cryptography also known as asymmetric cryptography, right? In which the sender and the receiver probably exchange public keys with each other. So we have the classic crypto example when Alice wants to send a confidential document with Bob, Alice will need a Bob's public key in order to encrypt, right? So this is the classic crypto example we have applicable when you visit our HTTPS website. You actually need the public key from the website in order to start the encrypted connection. Also applicable when you want to send a GPG encrypted email to somebody, you need the public key of the person in order to encrypt it, right? So this is basically what public key cryptography is. Now while the algorithms and everything are very good, there is just one factor to public key cryptography which is a little bit difficult to achieve and that is called trust. And what trust basically means that both public key cryptography and asymmetric cryptography really need trust. What trust basically does is trust links the public key to the entity. So when Bob wants to send an encrypted email to Alice, Bob will need Alice's public key but Bob will need to make sure that the public key really is of Alice, it is of Bob, right? I mean so when you send an encrypted email to somebody, you need to ensure that the public key actually depends to the person of the person you want to send the email to. Similarly, when you go to HTTPS www.google.com, how do you ensure that you are actually going to Google.com and you are not going to some man in the middle attacker website? So you do that by checking the certificate and certificate is nothing but the public key which contains some other information as well. And if your browser shows that the certificate, if the URL is green, it probably means that the certificate is trusted, right? So trust is very important in asymmetric cryptography. Without trust it is quite possible that man in the middle attackers can get in between, they can hijack your connections, they can read whatever data you are passing on the internet. There are basically two ways of achieving trust which is how it is done. One is by using something called as web of trust. So when you send a GPG encrypted email to somebody and when you download the public key of the person you want to send, how do you trust that this public key indeed belongs to the person whom you are trying to send an email? So for that we have something called web of trust which is used to solve one part of the problem. The second part of the problem is solved by using something called PKI which is public key infrastructure which includes certificate authorities and sub-certificate authorities and stuff like that. So we are going to have a brief look at both of them and we are also trying to see why both of these methods are flawed. So the web of trust was first introduced by Phil Zimmerman. I think in 1992 or 1990 or something like that. The idea is very simple. The idea basically says that we have a central place where we have everybody's public key which is basically known as a key server. So a key server is basically a central database or a database where you store everybody's public key. However, it leaves the trust decision in your hand. So though you download the public key from the key server, you need to decide whether you really trust the public key or not. There are a few ways of achieving the trust. One way of achieving the trust is you sign somebody's public key. So if you trust a person A and the person A has signed somebody's public key, it probably means that somebody's public key is also trust trusted. So that is why it is known as the web of trust in which you trust somebody and the person trusts somebody else and so on and so forth. And you basically go down the chain of trust and you reach the person whose public key you are basically interested in. And this kind of trust is achieved by signing the public key. So what you basically need to do is you need to go to the key server. You need to sign the key. And the key server will actually show you which key, if your key is uploaded on the key server, the key server will show you a list of people who have signed the keys. And if you have ever been to key signing parties, that is what basically happens, right? You meet people, you are supposed to check the identity cards, you are supposed to get the key fingerprints, you are supposed to put the fingerprints in a piece of paper, you are supposed to seal the paper, you are supposed to go home, open the seal and then you are supposed to sign the key. This is basically what is supposed to happen, though it doesn't happen that way, right? So as the chain goes, so you know probably it started in 1992, if you log into any one of the key servers, you see that they are thousands and millions of keys and they have been signed by a lot of people out there. So the basic concept is that there is a web of trust, everybody signs, everybody's keys, right? And when you want to use somebody's public key, you check whether you can go down the chain of trust and it links to somebody you actually trust, right? So PGP, which is a software which is often used for signing encrypted emails, basically relies on key key servers, right? And these key servers are designed in a special way. So there are a lot of key servers on the internet, you may probably have heard of PGP.mit.edu, which is probably the most commonly used key key servers. There are hundreds of key servers on the internet. The basic principle is that you use the key server for this discovery and distribution of public keys. The key server does not attest to the accuracy of the public key, right? So the key server will not tell you that this public key is correct or this public key indeed belongs to the person who has uploaded the key. It is left for the user to decide. Like I mentioned, the trust is achieved by signing people's public key and then you trace it back to somebody whom you trust. The key server was designed in a way that you can never delete any information from the key server. And this was basically done in order to ensure that malicious agencies are not able to temper with the keys which are uploaded. There have been a lot of cases since 1992 in which government agencies have actively asked key servers to delete keys from the key servers. There have been cases in which government agencies have asked key servers to replace the keys with malicious keys, right? So there have been a lot of cases like that. So the key servers were specially designed to be right only. Once you upload a key, you can never delete the key from the key server. And the key servers are basically based on the principle of propagation. So once in a while, the keys will propagate from one key server to the next because it is supposed to be distributed in the network. And the key servers will often compare with each other. And if there was a key which was deleted, the key will be restored. Like I mentioned, you could also sign keys on the key server. So if you sign somebody's key and if you want to revoke the key, how a revocation basically works is that you re-sign the key. And after re-signing the key, the re-signing has a flag which says that this re-sign is for revocation of the key, right? So you cannot basically delete the signature which you put on the key. You re-sign the key. And the z-signature has got a flag which says that this z-signature is basically for trying to revoke the key. So the basic concept is that the key server can never, never delete any information. So this led to a very interesting flaw which was reported to us last year. It has been assigned CVE 2019, 1, 3, 0, 5, 0. If you probably Google on the internet, you know, you can probably see a lot more information including ways to ZEPRA produce this. And this is also known as certificate spamming attack, right? And how it basically works is that a certificate, like I mentioned earlier, certificate attestations or signatures are used to show somebody that you trust a key. Like I mentioned, when signatures are revoked, the original signatures stays there. And you put a new signature on that and a new signature basically says that, you know, this signature is used to revoke my trust. And this is basically there because of the right only design. Now the problem is that you can technically have a signature, you can technically have a public key with too many attestations. It is possible to have a public key on the key server which has been signed a lot of times by a lot of people. The key servers can handle up to 1,50,000 attestations. So 1,50,000 people can actually sign a particular key on the SKS key servers. However, there is a problem with GPG. GPG is not able to handle more than a few thousand, right? So and in case you are wondering if SKS key servers are really popular, most of the key servers on the internet are SKS, right? So SKS is a very old software is written by a PhD student who wanted to do attestations. It is written in OCaml. There are very few people who understand the code. The code is not maintained for a very, very long time. They really easily wants to look at the code and see if they want to improve it, right? So we have a classic case in which we have a very old software written in a language which probably very few people understand, right? So what is the basic attack? The attack is very, very simple. But before that, the biggest problem with SKS key server is if one day if I create a GPG key and if the GPG key has got an email address called something at redhat.com and if I upload the key to SKS key server, the SKS key server does not check if the key actually belongs to him, right? So what I need to do is I need to create a key with the email address of my manager uploaded to the key server and then social engineer somebody to use that key, right? It is very, very simple because the key server does not check. And based on how things are, it's probably easy to social engineer somebody to sign my key as well. So the whole system is not very trusted, right? So how the SKS key attack works is that I choose a key which I want to spam, right? I signed a key with thousands of signatures and that should not be difficult at all, right? I just downloaded, I sign it with somebody's email address, I upload it and it is very, very easy. I download a public key which I want to attack. I sign it with thousands of signatures or I may even sign it and I may even revoke it and I upload it. Now the key is totally, totally unusable. So if somebody is using OpenGPG and if you do minus, minus refresh keys, so this key, your OpenGPG installation is totally not usable now because OpenGPG cannot handle more than a thousand keys, right? Now what is the actual attack vector? The attack vector is there are a lot of Linux distributions out there who sign their packages by using keys and these keys are uploaded to the key, key, key servers. There are a lot of other applications also which, you know, sign their packages and stuff like that with keys, right? So if you want to verify those packages, it's, if I, if I'm technically, if I'm able to spam security at ubuntu.org or security that opens suze.org, right? So these keys are totally unusable now. You will not be able to sign your messages which you send to these keys. So basically the attack can be used, can be done against any key. It can be used to render the key completely unusable. All the user has to do is the user has to import the key or if the key is already imported, the user will just need to do minus, minus refresh keys and your installation is basically gone. What is the solution? The solution is to use the new key servers. One of them which has popped up on internet is keys.opengpg.org which is very useful. It actually, when you upload your key, it actually sends an email back to you containing the email address which was on the key. You need to reply back to the email. So at least there is some kind of verification in which the OpenGPG server, in which the SK server will check if the key actually belongs to the person who uploaded it, right? And new keys need to verify the emails first, so these are two solutions which we have. So this is the web of trust, but PKI or the public key infrastructure which is more commonly used is not safe as well. And I want to raise your attention to a couple of flaws in PKI. So what PKI basically is is like when you go to Google.com, the certificate which Google.com uses is probably signed by one of the certificate authorities and the list of certificate authorities is imported in your browser, right? In case you don't know, a lot of these certificate authorities are controlled by government agencies, right? So the government agencies are basically free to do whatever they want. And like I said, when you want to use a certificate, you basically send it to a certificate authority or a sub-certificate authority. You need to pay some money, and they will do some basic verification which in most of the cases is not done. They sign your cert, right? And like I mentioned, a lot of these CAs and a lot of these sub-CAs are hosted by government agencies who have an agenda on their own. So it's not only the government agencies which are flawed, but it is some of the other private companies also. In 2011, we discovered an attack with a CA called Komodo, right? So if you're not aware, if you Google for Komodo CA authority, Komodo is a CA authority which was compromised in 2011. Their private key was leaked, and we don't know how many people's certificates were signed via Komodo. In 2011, again, DG Notar was compromised. DG Notar is a very important and well-known certificate authority. The person who hacked DG Notar, he issued a lot of wild card certs for Google.com, right? So again, we don't know since when the certificate authority was compromised, but somebody discovered it a couple of years after that. So this basically goes to say that the PKI model is not very good as well. There are a few alternatives which I would like to propose, and one new thing which is coming up is a blockchain-based PKI. There's also a distributed PKI which is similar to blockchain, which people are trying to propose, but I'm not sure how much time it would take. So yeah, that's most of my talk. If you have any questions, then I think we have around seven minutes, sorry. Certificate transparency is, yeah, I mean it's a good thing, but I'm not sure how useful or how widespread it is. And I'm not sure if it is going to replace PKI in the long run. Yes? Yeah, so the question is for the original SKS attack, did they fix the code? So the answer is no because the open PAP guys, they tried to contact the maintainer who actually wrote the code, but it seems the maintainer is not interested. And there are other people who are not interested in looking at the complicated code as well. So the code is not fixed. I think the only alternative is to switch to key source servers which are more secure than the SKS. No questions.