 Okay, it's my honor to be here. So the topic of the talk is practical criminality of jason web token and gal wire caramel implementations So I myself secure engineers. So basically my job is conduct security views What it means to play the tackle roles in your academic papers So we are talking about two topics first one is Asian Web signatures security view and I will show you how tricky and complicated design can lead to unsaid implementation The second topic is kind of a low-level primitive Gal walk how to mode it widely use it use almost everywhere But then it's implementation a rally check and then I will show you to Auto tile box that may leak authentication key So Basically that there is no zero-day today all the bus will report it upstream and have been fixed A year ago or some summer buck were recently fixed So before we start the most important lesson that I've learned over the years is The encryption input is mostly under our control Why the decryption of signature verification input is always under tackle control And then we will use this observation over and over again to show how to exploit Crypto box So Jason Jason web token basically to the Jason Token, but it provides signatures or maybe multiple signatures. It has a CDH CVC as mark encryption It had different formats the format I will focus on today is very simple It has a header or payload and signatures and then in particular I will talk a square Gohose implementation, which is widely used by Google less encrypt and a square ink Okay, so when I started I have no idea what Jason grab token is so I just Read the RFC and this this this line really triggered me because it says that in the signature You embed the public key correspond to the signatures So basically what it means that a tackle can just generate a private Public key pair and then send the public key together with a signature With the hope that the receiver will extract the public key out and use that for signature verification This is the design level mistake by FC and let's see how It leads to unsafe implementation Sorry So gohose enabled that feature by default so any signatures have a public key embedded in it by default So just for fun instead of trying the public key I try to send a smart key and it it also accepted I don't even know what it means when you have a smart key together with the h-max So the next problem is I look at a CDH and implementation in gohose And then you know like the first step is to check well known attack invalid curve attack And then for elliptic curve and this curve you have to check where the public key is on your curve Otherwise the attacker can send you a public key on a different curve with a small Other and then it can use Chinese remainder theorem to extract the private key and then gohose doesn't have any check One of the reason is go implementation doesn't have a CDH So the developer has to do it themselves and you can guess that they miss this critical check Gohose also have CBC H-max the H-max is computed over the AAD nonce inside attack And the last pay attention to last component the last component actually makes the boundary between AAD and nonce unambiguous and Then I found a few integer of flow, but then I want to exploit it I don't know how to turn integer of flow in go into a remote execution, but how about H-max pipe path? So the idea is you want to you want to shift the boundary between AAD and nonce So assuming an attacker observe some 16-bind AAD some nonce and then some last cipher text What attacker can do is it will create a new set of AAD where if you pay attention Because of AAD Side is too big when you multiply by 8 it will be 64 because of integer of flow So basically the main idea is the attacker already create a new set of AAD new nonce new cipher text And then the H-max is the same So basically causing H-max authentication bypass The last topic in gohose is support multiple signatures I rarely seen a real practical use case actually use multiple signatures, but then it is in our RFC So the developer has to develop it. So if you look at the signature verification The it checked whether one of the signatures invented then the method just returned a payload and what's wrong with that? The problem is the signatures not only covers the payload, but also the protected header Entarity of the header So what the attacker can do is it's assuming that observe a valid signatures and a valid header and valid payload What it does it creates a new Invalid header and invalid signature and then it will send them together with the valid one Now the victim called a verify method it check whether one of the signatures valid Well, the second signature is valid because what the attacker observe on the wire So the so the victim will Wrongly assume that the first the first header is valid which may contain the revocation key Okay, so let's move on to Gawar counter mode. This is kind of a primitive low primitive That's that I also do a security review for so Gawar counter mode is kind of fragile There are fewer attack in academic But like when I first look at it seems that like people rarely look at its implementation So for recap the Gawar counter mode has encryption key and authentication key the encryption It basically just counter mode, but the counter is actually Increase every time modular to to 32. This is important and then we'll come back to it later The authentication Tag is basically if you look at the last equation forget everything. It's just a polynomial of Authentication key where the coefficient is the ciphertext. Okay So basically I look at one of the open SSL wrapper because we know don't want people to use open to sell directly So we write open SSL wrapper someone wrote it You know the safe open SSL allows you to configure what is the expected length of the authentication tag So the safe one is you say hey I want only 16 by authentic authentication tag Or maybe 12 by it depends on the applications But what the wrapper does is it get the authentication tag that it received on the wire and uses to configure The expected length of the authentication tag. So what it means is the attacker just send one byte Authentication tag then the wrapper will happily accept it. You may wonder why doesn't attack that just send zero by Well, basically open SSL just Prevent zero by authentication tag. So one byte works nicely Another problem is I said before the counter mode you actually work in modular to to 32 So if after 2 to 32 blocks the counter will be wrapped around Causing counter collisions and in counter mode if you have if you have counter collision and a blip plantax and in GCM If you have counter collision, you also leak the authentication key So this issue is different from the ivory you issue because it happened even if user use a different IVs and Then let's make I make a check for Open SSL construct and then basic answer and open JDK a miss this critical critical check And then it's especially danger in Java Cypher because you streaming API meaning you can encrypt last five by calling encrypt each chunk Okay, the last block I will talk about is the classic timing vulnerability open JDK So if you look at this it looks similar to the ash mark vulnerability Basically, it compared by by bite and if you see the first unmatched then it will throw an exception Okay, so okay, basically it allows you to buy past authentication once for particular Cypher text But I want more I want authentication key So let's remind up about Anton you forbidden IV attack This works on encryption input under user control only and then it's not it exploitable in practice And basically this already fixes in 2007 But I remain remind us that the encryption input is under attack control. So let's see how it can be exploit So the attacker choose collided IVs in decryption Basically the attacker send two pairs the first pay IV and C1 the second page IV in C2 and then C1 XR C2 is one in particular you just choose a very simple Simple payload IV is zero C1 is zero and C2 is one and Use using the timing attack the attacker can learn the authentication attack of these pair So I write that equation for you. So basically what it means is if you're x or the authentication tag together, then you have h square and then fighting a square root in In one of few is enough to find Fight edge. So basically what it means is if you just make a small mistake Similar to h mark one, then you basically leak the authentication key. I Have an extra book, but probably it's better for Questions. Thanks for your attention Okay, any questions for kwan? I guess not. Well, I guess you're gonna be around So if you want to talk to him in the coffee break you can do let's thank one one more time. Thank you