 All right, so we're ready just ready to start the third day of real-world crypto And our first session today is on wireless protocol security and our first speaker is David basin is gonna talk about 5g security So David all yours. Thank you So I need a clicker is this the Is this the right one? Somebody took the clicker. I'd love to give a talk, but we need Who took the clicker? Did you take it? Okay It's a pleasure to be here and to talk about work on model checking 5g security. This will actually be a talk within a talk the Outer talk will be on the importance of formal methods in particular model checking for security protocols And I'll introduce some techniques that may be new for some of you that I think can be very important for the real-world Crypto community the talk inside the talk will be an application of these techniques to 5g and The security standard within 5g The work I'm talking about is a large collaboration It involves different teams also in international cross countries One is the team of researchers who have worked together with me on the tamarin project And I list them here Tamarin is a model checker and I'll tell you a little bit about it and it's been under development for over eight years The second team which I'll talk about and there's some overlaps are those who have worked with me on the 5g on Modeling and reasoning about the 5g specification 5g is a huge specification We took a number of years to follow the formalization of that and that also took a fair amount of manpower So a big thanks to those people who work with me Also, I just like to mention that for some of the slides on tamarin I'd like to thank Kaz because there's slides that I bought borrowed from him Let's begin with security protocols and the need for formal methods. This isn't 5g. This is from the internet key exchange It's one of the phases. It's one of the modes The details don't matter. You don't need to understand it But I just point out a few features for example We have keys that are being used for encryption and these keys are being derived from various other keys So there's a key and then there's a driving key then an authentication key an encryption key, etc So we have all these nested hashes and you might ask yourself Clicker Okay, there we go we might ask ourselves why all of these nested hashes and Well, there are good practices and one good practice is use different keys from different things So you begin by driving a lot of keys Then if you look carefully you might see for example that these Diffie Hellman public keys These gdxg the y's are sometimes written in another order and these cookies against denial of service or sometimes also Change and you might ask yourself does argument order matter and there might be some people in the audience would say Yes, it's a good idea to change the order of things because this will prevent certain types of attacks like reflection attacks Where you play a message back to a party and he accepts it in a different step I would argue these are not the questions. We should be asking the fundamental question We should ask are what does this protocol actually do? What does this protocol actually achieve and in what environment so our environments have adversaries so against what Adversary does it have the properties we would like? These are the real questions not these questions that somehow motivate best practices about how to organize protocols But nevertheless protocol design today is typically approached as an art There are these best practices. There are committees within the itf w3c and other organizations that build protocols They often have to reuse existing protocols and the whole thing reminds me a little bit of the following story Some of you may know it so I have here a picture of a roast That's a big piece of meat and the story goes as follows when I made a roast I always started by cutting off the ends just like my grandmother did someone once asked me why I did it And I realized I had no idea it never even occurred to me to wonder It's just the way it was done eventually I asked my grandmother Grandmother why do you cut the ends off of a roast and she answered because my pan is small and otherwise the roast would not fit So this is to some extent how I see how I think protocols are being designed We have these best practices. We carry things out Sometimes we don't even question why The alternative would be protocol design as a science and here I mean in the root sense of the word science so that is discovering and knowing something that you can demonstrate and verify with a larger community and Formal methods is one way of doing this It's a way to build better protocols where we have very precise specifications of the system So the protocol of the environment i.e. the adversary which with which it interacts and also the properties and If we do this well, and we have supporting tools then we can debug verify and explore alternatives And I'm happy to say that There's been a lot of progress over the last 20 plus years in formal methods for security protocols and Tools have advanced to the point where we can apply these protocols with reasonable effort to protocols that really matter and Here I've listed in yellow some of the protocols that my team has worked on so protocols for entity Authentication 5g I'll be talking about that today. There was some great work at Oxford with cast cast Cramer's on TLS 1.3 And this is very exciting and slowly Companies are becoming tool users. I hope by giving such a talk I might motivate those of you who come from industry to consider whether such tools might help you in your work So where is the difficulty? I mean the problems are not easy It's not just like you snap a finger and you verify protocol So this is kind of a standard picture from verification 101 What we do is we have a specification of the system that sometimes called the model because you're making a model of the system It's some level of abstraction and you'd like to show that it satisfies certain properties And why is this difficult to do? Well for security protocols we have to first specify how the system operates and if you look at a typical standard whether it's a IETF standard some other standard often you have the problem that before formalization comes you must be precise and Protocol design documents are often incomplete and imprecise Often it's unclear what the adversary model even is So protocols are given without adversary models or there are statements like this protocol should not be subject to replay attacks That's like saying this program should not suffer from a buffer overflow. Yes, that's true, but it doesn't tell you what the program actually does Another problem is from the security properties what shall be achieved and here properties are often implicit or imprecise So example authenticate what does authenticate really mean there various ways you can make that precise and Finally, of course notion of satisfaction does a system meet its its requirements Here ideally we have proof and in the best possible case machine check proof because humans can get lazy or make mistakes And here we're up against undecidability So I'll be talking about verification a symbolic model and here even for very simple classes of protocols basic properties Like as a key of secret is undecidable and even if you restrict yourself to restricted cases where you can only have for example Finitely many interleaved runs of a protocol. You still have a problem an intractable problem So the weapon of choice that we've been working on that I'll tell you a little bit about is tamarin So tamarin is not an acronym. It's actually a monkey kind of a cute monkey And tamarin is basically our tamarin is basically a constraint solver That's how it solves constraints about what the adversary could do in a particular situation And then we turn that constraint solver into a fewer improver. So it's a constraint solver disguised as a theorem prover I'll say a little bit about what tamarin does. I won't say really how it works I won't talk about the algorithmic background to it. There would be a different talk for a different community But I'll just tell you a little bit about how you might use such a model checker and then we'll move to 5g So As is often the case in model checking you have the specification of the system This doesn't work all that well the specification of your system. That's called your model You have the property you negate your property and you would like to have a behavior that's consistent with the system So it's a system behavior that falsifies your property your property and in our case with tamarin We use constraint solving to find that and if we find such a behavior that's an attack and We get a representation of it. You could present that to the user for example as a message sequence chart if you would like and importantly If the constraints are inconsistent then no possible attack can exist And this means no matter how you interleave runs of the protocol Arbitrally many runs with the adversary there cannot be an attack and that constitutes a proof Of course, since the underlying problems are undecidable You might run out of time memory patients Etc and then tamarin allows you to go into an interactive mode where you can work with This theorem prover constraint solver to interactively construct a proof or to provide hints So sometimes you need auxiliary invariance or even possibly change the underlying proof strategy being used. That's called oracles Okay, how do you actually use this in practice? So protocols are specified using a specification language called multi-set rewriting Multi-set rewriting is a little bit like term rewriting for those of you who know it But rather than changing one term to another you change a multi-set Which you can think of as a bag of facts into another bag of facts and these bag of facts Represent the states of the different protocol participants think of them as each having a little protocol automata So what state are they in what do they know and also for example the state of the network? Which might contain information on messages being sent out received what the adversary knows etc So here's a little example so in multi-set rewriting our rules transform a left-hand side to a right-hand side And they can also be labeled with actions. These are it gives rise to a labeled rewriting system a label transition system There's a typical example of a rule the left-hand side says if We have input to our network so in represents input to the network of some K think of it as a key and In our multi-set some Protocol automata with some thread ID thread ID is in some step isn't its first step Then in that case our protocol would say well advance your step-to-step to and Output on the network and acknowledgment and also in your state record that you receive this key K Okay, so this would represent a transition from taking input off the network to recording in an outputting a response And this would be labeled with I thread ID have accepted K say as a key So this gives rise to a transition system with a trace semantics So now imagine we have a state of our system says this bag this multi-set of facts in this multi-set We have many facts, but among them are that Key is input to the network and some thread ID three is in step one Then we can match that with the left-hand side of this rule So key would be instantiate K would be instantiated with key thread ID would be instantiated with TID 3 etc Then this rule would say we can take these facts out and replace them with instantiated right-hand side of the rule So we match the left-hand side we replace it with instantiated right-hand side So we get a new state with ACK output on the network and this thread ID has advanced its state and recorded that it's gotten the key more over this transition is labeled that thread ID has accepted the key and This gives rise to a label transition and you can continue this because you'll have other rules available and you get a Trace which is a sequence of transitions and in particular the trace We ended what we understand by a trace the trace semantics is the sequence of these red parts here And that trace is important because we specify properties over traces We can say for example somebody is accepted a key and the adversary doesn't know it that might be something that we would specify That may be a security property so I showed you an example of a rule and In general in protocols you'll have multiple rules So for example have multiple roles and each role will have a role automata There might be a initiator role or a responder role a key server role This would be an example of the role automata for the client state machine for TLS 1.3 and here for each of these arrows here. We would have a multi-set rewriting rule Okay, so in general you'll have quite a lot of multi-set rewriting rules for complicated protocols We also have to specify our adversary so for our adversary what we want a network adversary Who's active sometimes this is called a doll of yaw adversary historically at least in the symbolic setting But as cryptographers here know a network adversary Seem strong they see everything they can they can interfere but actually we want to consider even stronger adversaries Who can for example corrupt long-term secrets corrupt your random number generator corrupt session state? This would correspond to different oracles in the computational setting. So here's an example of how you might specify session reveal Excuse me right so you can specify the adversary capabilities also by Multi-set rewriting rules. So here's how you would specify a session reveal So if there is a state where some thread ID has learned a key then that key can be output to the adversary and that transition will be labeled with thread IDs Key has been revealed to the adversary Okay, so again, so we spent we have rules for all the different protocol automata and we can also have rules for the behavior of the attacker Now the question is how do we specify properties the properties themselves are specified in a guarded fragment of first-order logic with time points It's essentially morally like a past time first-order temporal logic You can say if something has happened and something can't happen before or at other points in the trace so Here is an example of how you might specify that a key is secret It would be for all thread IDs for all keys. It's a two-sorted logic So one of the sources over time points for all time points I If a thread ID TID has accepted a key at time point I then there isn't another time point J where the adversary knows the key So K here means the adversary has learned the key at time point J Okay, so in this way we can specify properties and the property will hold if all possible Traces of the protocol satisfy that property Okay, so you specify good properties and then you want to see if when you negate them you can find traces that violate the properties That's how model checking works and again. These are interpreted over the red bits over the traces Okay, then at the end of the day there's a question. Well, what does Tamron really do? What's the magic of Tamron? So Tamron takes these specifications of the role automata of the adversary of the security properties and then it uses various constrained solving algorithms Which I will not go into which I will not describe further to try and see if there is a way that the different Protocol automata can somehow be run together with the adversary to attack the protocol And if it's not the case then we will have a proof that no possible attack can exist at all So let me now move from Tamron. There was kind of a quick high-level bluffers guide to what a model checker might do to analyzing 5G I'm gonna use my phone as a little prop. So 5G of course as you know is the new Standard for for a wireless communication. It's standardized by the 3GPP The the first full release of it at least that the first Full relief release of the basic 5G protocol was last year June 14th 2018 This is a protocol that is gonna have massive uptake. So right now most of you are using 4G So LTE maybe in some place of the world even 3G but for current cellular services We have about 5 billion mobile subscribers and we can expect that and more for 5G because 5G will also be used in able to Internet of things and things like this And you can expect that a large portion of the world's population will eventually have 5G access So the question is okay. Very good. This is a protocol. It's used for communication communication is critical. How is it secured and There are various parts of it that are security relevant And here I'll be talking about aka authentication and key agreement and what I'll be describing here You can find more about in a CCS paper So how does authentication key agreement work within 5G? So the idea is we have user equipment There's a bunch of acronyms here So the UE the user equipment which has a SIM now called a USIM a universal subscriber identity module I want to be able to use this for telephone calls and So I am Swiss and I have a phone registered in Switzerland with Swisscom So Swisscom is my home network and I come here in New York and according to my phone my serving network is T-Mobile So I don't have any security associated with T-Mobile But I have my home network I would like to set up an association in a secure channel with a serving network and 5G aka is about how you do that how the subscriber and the serving network authenticate each other and set up a key Okay, now of course in security you typically don't get security from nothing. So we have some set up assumptions Namely that on my USIM my my user subscript my My user equipment from the home network will share a symmetric key It will I'll have a permanent identifier called the soupy We also had soupies in previous versions of 5G like 4G. That's a subscriber permanent identifier the soupy is Privacy relevant And in 4G there were problems with MC catchers because as you go around say New York Your phone is often transmitting your soupy So you can you can hear that at various places if you if you're listening for it and you can track me as I go through New York So in 5G they said we want to get that right So we're going to conceal the soupy in something called a soup key We're gonna see that later So the soupy will be used to derive a soupy and that'll be derised in a randomized way such that that changes So presumably I cannot be traced as I go through New York. There's also a sequence number so it's a sequence number based protocol and I Will also my user equipment will also have the public key of the home network He sets the setup Let's look at how The protocol works. I will give you the main ideas I won't go into through every little micro step because there's a lot of detail here But I would like to give you the main idea of how it works First I will send to the serving network say here in New York My soupy, but I will mask it. I will encrypt it using the home network's public key So here this is just my terminology for asymmetric encryption It's randomized using some random value that I generate it's encrypted with the public key of the home network and I tell the serving network. Also, what is the identity of the home network? Okay, so here I have a little message sequence chart This shows the little setup assumptions who knows what and I'm going to send the soupy from the subscriber to the serving network And then the serving network now knows who the home network is So it says I'm the serving network and here is the soupy And then the home network can choose an authentication method There are several and I will tell you about aka and Here on this slide I have the successful case of aka and I'll also show you a couple failure modes and again I don't want to explain every little line of this, but I still want to give you the main ideas So it's a kind of a challenge response protocol where the home network will generate a random number Now just so you know these various f's are keyed Keyed one-way functions And there are also various other one-way functions such as challenge and the like in key seed Which is used for key derivation function and these have slightly different properties, but I won't go into those details for now so What would be what we do here is we use this shared key shared with the subscriber To make a Mac of the home network sequence number and also this random value And then we use another one-way function With to with this random value and the key to produce a random string And this random string will be used as a one-way function to conceal Excuse me a one-time pad effectively to conceal the the home network sequence number so we don't want to send sequence numbers in the clear and the pair of this so this Encrypted sequence number and the Mac is called Aten that will be sent over and then unpacked on the other side and then we calculate various responses that the different parties can expect And then from all of this data this key the randomness and the sequence number and this the serving networks name We generate a key seed and this will be used eventually by the serving network and the subscriber to derive a common shared key And we increment our counter for the home network Okay, this various data then is sent This is a secure channel between the home network and the serving network So the randomness this authentication information and expected response in this key seed function for driving a key Then the randomness in this authentication information is sent over to the subscriber And what does the subscriber do it first of all it unpacks the information Then it generates this one-time pad itself because it's given the randomness and it has this shared key Then it generates what it believes to be the sequence number for the home network that it can also compute Then it can also compute the Mac itself with this data that it generated and has and then it performs two checks And these checks are important the first check it does is that the Mac it Calculated is the same as the Mac it received so in other words It checks the authenticity of the information got over the air because the communication between the server and the subscribers over the air So it checks that it got something authentic that this was authentically generated by the home network and then it checks recentness it checks the It's sequence number of the user equipment. It shouldn't be greater than the sequence number of the home network as otherwise We would have a replay attack So it's important to remember these two checks Authenticity and freshness if both of the checks succeed then there are some steps Where it updates its sequence number to that of the home network. It computes a response. It can compute now this key seed Because it has all of the data that the home network Used for this key seed so it can compute the same key seed So it in the serving network can later on drive a common key. It sends the response To the to the serving network who checks that it's legitimate And if it's legitimate it sends it to the home network and the home network also checks that everything is legitimate And if everything succeeds So here we had the serving network sending this soup key to the home network and the home network says I now give you the serving network the soup pee so you know really Which subscriber you're talking to because until then The serving network hasn't authenticated the subscriber just has a soup key which is a pseudonym, but now it really has a soup pee So it can use that for billing and for other functions Okay, there are two failure cases The first thing we saw is that there's a failure mode where the Mac Checks, that's I the Mac checks, but the counter, but the message is not recent We have a problem with checking the counter this would happen when a message is being replayed now if that's the case And we have to synchronize And this is a problem with with protocols involving counters You have to effectively send your counter to the home network So the counter can read so the home network can resynchronize its counter So to do that what you do is again you want to take your sequence number You want to one-time pad it so you have to generate padding information and then you can pack that together and Send information on the synchronization to the home network now an important thing for you to remember is that this synchronization Information is sent when there is a Mac failure and it's sent with information that only the subscriber can generate because it depends on the Subscribers key so please keep that in mind So this was the case that we had we have to resynchronize Whoops, and then the second failure is when there's a Mac failure and we simply send an error message that there's a Mac failure in the protocol Aborts Okay, so that was a high level view of how the protocol works. This is the type of thing that What I've described here is actually spread out over 722 pages in in 3g pp documentation But now we can ask ourselves the question of is the protocol secure So stepping back and model checking first we make things precise and after we made things precise We have a precise understanding we can make things formal and check So here questions you might ask is the home network talking to a subscriber talking to user equipment with the valid use him or to an imposter Privacy so 4g had the problem with in seek emcee catchers But am I traceable as I roam through New York and if so how would that work? So here we use tamarin, but I have to say verification was really challenging Often it's the case where we have problems from practice and we're not ready to handle them at some point in time This motivates a lot of work So in particular it's a challenging protocol because it has state it has sequence numbers The state is fairly complicated It uses xors and operators So we have to be able to to adequately model different cryptographic operators and x or is fairly difficult to handle We we we formalize that Equationally and it makes it very difficult to integrate x or is very difficult to integrate into our constraint solvers our constraint solvers work Well with something which is called subterm conversion theories and this isn't one of them. So we had to go off and develop Theoretical basis for integrating x or Privacy requirements are also quite tricky. So to see if you're being tracked. Those are not trace properties They're hyper properties. They're two hyper properties. So you formalize privacy typically by observational equivalence And that's not a trace property for those of you who know about things like hyper properties It's a hyper property not required extending our tool not just to verify protocols with respect to trace properties But also observation equivalence and of course they can be unmountedly many sessions that are interleaved So this required a lot of work and we were able to use some very recent tamarin extensions Which are published in other papers for example observation equivalence and xor Okay, so how the formal analysis worked We formalized draft one point zero point zero of the standard And this required following the standardization body for about a year building base models and augmenting them with their different changes So keeping up with them. This is a methodology that seems to work fairly well For example the Oxford team with the cast Cramer's did this for for TLS one point three And you can really know as verification engineers so to speak follow standardization committees and give them feedback We had to work with the documents of the 3g pp and that was over 722 pages of documents And it required a little bit of interaction to make things precise to understand them The tamarin model for the protocol was 500 lines of multi-set rewriting rules the specification of the desired goals plus some additional lemmas which were needed to make that the The verifier terminate was over was roughly around a thousand lines with 124 lemmas So The specification didn't really it wasn't very clear about the adversary So what we often do with tamarin is if you don't tell us the adversary will figure it out for you Namely we'll first verify the protocol with a fairly weak network adversary, and then we'll add different compromise Capabilities you can actually have a partial order of adversaries. We'll try and find the strongest adversaries under which the properties hold And said another way we try and find out What compromise capabilities break the protocol okay said also took a bit of work to find the strongest adversary models and It was computationally intensive Doing a verification would take over five hours Okay, what we find out for authentication So what properties should hold well the standard itself specifies surprisingly few and weak authentication goals So we had to guess for ourself what authentication goals should hold and certainly what's important is that the Subscribers and the serving network. So here I am using a serving network in New York We agree on a session key. So we have authenticated keep the key agreement I know who the serving network is they know who I am and we have a common view of the key That wasn't explicitly stated, but when you state that it actually fails it fails for kind of a trivial reason That's actually pretty embarrassing Namely the last message sent from the home network to the serving network Where the here the soupy is sent and then the soupy is sent doesn't bind the soupy to anything at all So in a in a world where interleaved messages are possible It's possible for the serving network to get the wrong soupy And if this were to occur, this would be a real problem. It could result in billing the wrong subscriber for services What's interesting is the previous version of the standard did not have this flaw earlier versions did not have this flaw, but at some point somebody just left out some message and This very simple mistake came into the standard So protocols can help you with simple mistakes. They can also help you with very subtle mistakes Here was a case of catching a simple mistake. It's almost like type checking this type of stuff shouldn't happen There were a number of other problems, which you could debate if they're really problems or not The standard aims at only implicit authentication. So implicit authentication as well We we have agreement on the key and we know who each other are but only after the key is used So whether or not that's good or not depends on how the protocol will be composed with other protocols If it's always going to be composed with other protocols in the future Where you use the key before you rely on knowing who the partner is and that's okay. Otherwise, it's not okay I would argue you should always try and have explicit authentication It turns out it's very easy to get in this protocol with very minor modifications. No additional cryptography So I would argue that that's an improvement whether it's an improvement or not depends on how you actually plan to use the protocol What's also interesting is security and privacy. So here's some good things the session key is secret assuming There are no corrupted long-term keys Which I think is a fine assumption and you have a secure channel between the serving network in the home network There is no weak forward secrecy for the key seed function, but you wouldn't expect it because it's a symmetric key cryptography Protocols, that's okay The long-term key will remain secret when running the protocol. So this is all fine But there's something which wasn't fine and this was a real shock The soupy remains secret so this common MC catcher attack won't work assuming no corrupted SN or serving network or home network, but And this was really surprising that wasn't sufficient to ensure untraceability So please remember the first failure mode when the Mac was correct But a message was replayed So you have an active adversary who replays a who hears a message from the serving network to my user equipment and can later Replay it then I will always Have a response that you can identify and you can associate with me because only I can produce it And that can be seen by an external party I will always give the same response where I reach where I re-synchronized the the the sequence number And this is a response that only I can give so by looking at the response that I give in this failure mode You can actually track me as I go through New York and as I go through the world Okay, so the problem is So they got right the fact that the soupy isn't being sent in the clear But the error messages are actually enough to trace subscribers and this is this is a shock Right. This is one of the Features of 5g is that it should have improved Anonymity properties privacy properties and this absolutely fails and unlike the previous Issues that that I mentioned there is no easy fix to this to this problem So the current version of 5g has this problem and there are still ongoing discussions. It's not clear yet how to fix this So one of the nice things with working on formal methods is you can find attacks the attacks are real the attacks matter It generated a fair amount of media here. I have just some of the media in English and German in French, etc Had lots of interesting calls with Handset manufacturers and like The ideas that I mentioned are very general I focused here on 5g the story within the story But the outer story is you can really use this for many protocols that matter Here are some examples of the types of things that we can analyze in fact rather easily with with the tamarin tool Let me draw some conclusions for the outer story art versus science I think we can improve the way protocols are built understood and analyzed In particular the community has come a long way the formal methods community 20 years ago We were doing very simple Alice and Bob exchange a key now We can handle protocols at the scale of TLS 1.3 and 5g and I think standardization efforts should really be doing this They should be following the development of their protocols using these tools either themself or Together in collaboration with groups that that that enjoy working with formal methods Doing so as good hygiene it forces you to be explicit about your protocol your adversary and your property as I indicated You can find errors or produce proofs And that this is really a realistic effort to do of course The game isn't completely completely one We're always up against the problem of complexity complexity complexity the underlying problems are still undecidable It's always a question of how we improve the scope of our protocol of our of our tools What kinds of protocols can we model and how accurately how faithfully we can model them and Finally an important point and that's one of the reasons I'm here is education I think it's very important to get the message out to let engineers know you can use these tools and to work together in Training engineers. Thank you We have maybe time for one question. Okay, so I am one of the user of tambourine prouver, right? And you said about different kinds of adversary so How can you modify the capability of dollop y'all? So I gave you an example of session state reveal. You just add rules, right? Yeah, we had rules for that. Okay, because I was I was trying to have a wiki he Diffie helman Model and yeah, so for Diffie helman You would want to have perfect forward secrecy perfect forward secrecy is just secrecy where you have a long-term key reveal And a long-term key reveal could be formalized as a rule that after a session key has been established The long-term key can be output to the network. Okay. Thank you I have to ask so now that you've done the work to Formalize the protocol in 500 lines. Can we just throw away those 700 pages and just use your 500 lines to understand the protocol I Would say you should use both together so so the seven the 722 lines contain additional things for example Pages, thank you contain additional things for example data type definitions. So so, you know how big our strings and things like this There's some justification arguments for things You get some history reference to other standards. I think you need both so I think that that Informal or semi-formal documentation should be complemented with formal models And also I have to ask this model denial of service attacks, too That that's not in the scope of this model and we would have to discuss what what we mean So, I mean you can do some kinds of analysis of denial Service like say can they get you to perform? Can the adversary get you to appoint in the protocol to perform expensive cryptographic operations? You can analyze those types of things with these tools, but that wasn't here Okay, that was a fantastic talk and I guess we're gonna move on to another wireless protocol WP 3 which was actually not on the list of protocols analyzed and so we're gonna hear about dragon blood and attacks on WP3 Okay, good morning everyone. Thank you for the introduction So I will be talking about dragonfly and how it is used in WP3 on EAP PWD So I am Mati Vanouf and I did this work together with Al Ronin who will do the second half of the stock So let's first do a very quick introduction This is all related to Wi-Fi security and if you look at the history We first had web which is quite horribly broken in response They defined WPA based on a draft of the IEEE standard and finally we have the latest IEEE standard of WPA 2 But WPA 2 is vulnerable to offline dictionary attacks and recently there were also key reinstallation attacks against it And in response to all this they Recently standardized WPA 3 and they decided to use the so-called dragonfly handshake The dragonfly handshake is what we call a PAKE meaning it does authentication based on a password on Dragonfly previously was also used in the EAP PWD protocol And this is a protocol you use in certain in a low amount of enterprise networks Where you authenticate using a username on the password on this handshake provides the usual properties You have mutual authentication you negotiate a session key, but the more important thing is this does Defend against offline dictionary attacks in contrast to WPA 2 So how does the protocol work? Well, let's say we have a client here that wants to connect to an access point Then the first thing that needs to happen is that both parties need to convert their shared password Which is for example in ASCII or Unicode? They need to convert it to a group element P and this element can then be used in the actual cryptographic calculations And once this is done the handshake and execute the actual First phase of the messages on this is called the commit phase on To simplify it the commit phase essentially negotiates a new session key And in the second phase of the handshake we have the confirm phrase on and a high level This confirms that both peers negotiated the same key on they prove to each other that they indeed possess the same password But the big question here is how is the password converted to this group element P and Here the first remark is that the handshake can operate using both mod P crypto groups on elliptic curves But we will focus on elliptic curves here So the question becomes how can we convert a password into a point on the elliptic curve? So this is often called a hash to curve algorithm. And how can you do this? Well a naive way would be to take the shared password to combine it with the MAC addresses of the client on The access point and we can then take the resulting output from the hash function Uninterpreted as the x-coordinate of the point on the curve Now there's one problem here And this is that not all x-coordinates are actually on the curve because some of them do not have a corresponding Y value in fact half of the x-values Do not have a solution here for the y-coordinate So that's a problem. So how did they decide to handle this? well, they decided to add on if test here where they where they first check does the square root have a solution and If not, they will execute extra iterations and they will include the counter into the hash function here That calculates the x-coordinate. This means that in every new iteration. We get a new point x on the curve so Probably quite of you already see the problem here The problem is the password now the number of iterations now depends on the password being used And it also depends on the public MAC addresses What's actually quite surprising here is that the IETF on the CFRG they in fact warned about this timing leak But the designers didn't consider this series enough. They thought okay. This is a bit of a theoretical attack And we don't think it actually leaks the passphrase Unfortunately, we can abuse this side-channel leak to do a dictionary attack and I will now explain how this works so our threat model here is that Either we can set up a rogue access point and induce the client into connecting to us And we can also do it the other way around we can act as a malicious client on try to attack the access point So both of these threat models Are valid for our attack so Let's assume that we are for example attacking the access point and we're going to assume that we can use Timing measurements to determine how many Iterations the access point needs to convert the passphrase into a curve on the point In particular, I'm going to spoof the client MAC address a and I will measure that the access point needs two iterations Then of course what I can do is I can take my dictionary of passwords I go through them. I execute this algorithm on my own computer and I can then compare My offline computations with the one I measured and I can use this to exclude passwords Unfortunately making one single measurement is not enough to include to exclude all possible passwords So we need more information and our example here two passwords still remain possible So how do we get more information to uniquely identify the password? Well, if we go back to our algorithm here, we can see that the MAC address of the client Influences the execution of this algorithm. So what we can do is we can simply spoof a different client MAC address Aren't we effectively get an independent execution of our algorithm? So to come back here, we can spoof client MAC address B. We can again measure how many iterations does the target execute? We compare this to our offline results and we can keep doing this until we uniquely recover the password To give you an idea about the complexity of this attack if we want to brute-force the rock you password dump we would need On average about 17 MAC addresses to uniquely determine the password The takeaway message here is that the number of iterations that are executed for a set of MAC addresses Forms a signature of the password So one thing I haven't touched on yet is can we indeed measure these timing differences in practice? So here we did an experiment on a raspberry pi one and the reason why we picked a raspberry pi one is because it's CPU is similar to a common home router on even some professional access points and In this case, we attacked the EPWD protocol So this is for example used in I would say about three to four percent of iterum networks And here the attack was surprisingly effective when we make around 30 measurements per MAC address and we filter out noise using crossbease box test Then 30 measurements is enough to recover the number of iterations So that covers the case for EPWD, which was defined already several years ago when they standardized WPA 3 they did realize that They finally listed to the IETF on CR4G at least partly aren't they included counter measures So what they did with WPA 3 they tried to prevent timing leaks by always doing 40 iterations here Unsimply returning the first point that has a valid solution for the Y-coordinate Now that's not everything they did on top of it They also implemented this in blinded constant time to again try to prevent side channel leaks On top of that once the real passwords Has been converted into a group element here. They will execute the extra iterations of these Total of 40 iterations using a random password again. This was done to defend against possible side channel leaks Now the question is does that solve everything? The answer is unfortunately, no The reason why is if we take the resulting outputs here of the hash function This needs to be truncated to the size of the prime P. So if we use a 256 bit curve the What is returned here are the first 256 bits of the hash output Now the problem is if we use brainpool curves Then there's actually a high likelihood that this output here even when truncated will still be bigger than the prime of the curve That would introduce a small theoretical base in the calculation So we want to avoid this and how did they decide to avoid this? Well, they simply used rejection sampling unincluded on if test here so the question is Is it are our side channels now really soft and Some of you may already see it. We have a problem here. This code may now be skipped On the amount of times that this code of is skipped depends on our share shared passphrase now can we exploit this because we still because the extra iterations are executed based on a random password and The answer is yes Because the variance now depends on when the password element here was found to illustrate this if Our point P is found here in the first iteration Then all the extra iterations are performed on a random password on the variance is high While if this is found in the very last iteration then there are no extra iteration based on a random password on the variance is zero On top of that the average execution time also depends on On which iteration the password was found as well So both the variance on the average execution time still leak information about the passphrase And if we then again try to execute this attack in practice on a raspberry pi against an open source Wp3 implementation We notice that measuring this is a bit more difficult But still by performing 300 measurements per MAC address We can still determine we can still recover enough information to brute force the MAC address So that covers my part and now we all will talk about some more vulnerabilities. Okay. Thank you so now we're going to talk about cash attacks and We're going to use a relatively similar similar threat model But now we're only going to target the client and here we're going to assume that we act like a malicious access point and we're going to add the Extra assumption that we are able to run some code on the client device Now this code is going to run in user mode. It doesn't require any special privileges or permission So basically for example any app that you download on your smartphone is might be sufficient and it's only It's only required to be able to measure such micro architectural sectionals so why do we need this and If we want to be able to attack any step of curves the previous attack that was mentioned is not applicable the reason is that with this to use a Prime number that it is very very close to a power of two and then there's the negligible chance that we'll see this Random this rejection sampling Okay, so what can we do? We're now going to use a cash attack called flashing reload that isn't enabled us to detect the exact point in time where a specific code line was executed in this case and the code line that stores the Recovered point inside the variable Now this is going to happen in any and check that we make and we want to know in which iteration does it happen So in parallel we're also going to monitor the call to the hash function And this is supposed to give us a kind of timer that counts the different iterations now as this type of attacks is usually very noisy and will We'll only want to recover one bit of information Many if this first iteration was successful or not and to do it we use what's called Cash template attack and we're going to run several measurements And we're going to give a specific idea or number to each possible result And then we can look at the distribution of the results that we get in both cases if the first iteration was successful or not and it is easy to see that those distribution are very distinct and Basically all we need is about 20 measurements and a very simple linear classifier to be able to leak this one bit of information Now we say that we are able to leak information and password both with cash attacks and with timing attacks But the question is can we actually exploit it to recover the original password? So to try to test this what we did was to provide a full probabilistic analysis of the amount of different Measurements and computational steps that are required in order to recover the unique password out of different size of Dictionaries we then continued to implement this type of attack using GPU code and then try to see how much money it will cost us on AWS instances to actually recover the password and we can see that for example for and they have I been point and Database of password which include all of the password dumps ever leaked to the internet it will cost us about two cent in the worst case which is the Recovering of a password for the NIST curves and even if we go over a very large Password domain like an eight symbol. It's still something that's Relatively cheap for an attacker to do and again if this is your day job You'll probably buy your own GPUs and it will cost you much less than that Okay, so we are able to recover a password and now we went ahead and try to look at more Implementation specific vulnerabilities and now this might come as a shock to some of you But we were able to see several implementation that has bad randomness for example one implementation use the system time as the only entropy source and The interesting fact is is that for WP to this doesn't really matter It doesn't really affect the security over for WP 3. This is Catastrophic Hall and allow us to actually recover the password element another shocking Finding is that we are able to perform invalid curve attack several implementation Didn't verify the points that they received in the handshake and this basically enable us to Recover the session key and bypass don't dedication There are also several why face specific attacks and the simplest one is the NL of service and Doing the entire 40 iteration is something that's very computationally Expensive, and it's relatively easy to saturate the access point CPU and then cause it to respond to stop responding There is also the danger of downgrade attack basically in transition mode and both WP2 and WP3 network share the same password Now this is something that has been handled by the standard and during the handshake This done read will be detected and the connection will be dropped. However, this will only happen after a partial Completion of the WP2 handshake and this actually provides us all of the information that we need to do the previous dictionary attack and offline and recover the password and There are also several issues with the support for multiple curves and it's relatively easy to downgrade the chosen curve so we can force the The client and access point to use curves that are either Wicker in cryptographically or are easier to attack using side channels So after we've had of this funding we started a very nice and interesting process of disclosure with the Wi-Fi Alliance We tried to notify all of the involved parties as early as possible because we wanted to be able to try to influence WP3 standard the reaction was as followed. We started with a privately Backward compatible security guidelines and several patches that were distributed between the different vendors after we looked at those patches we were able to find the brain pool side channel that was shown previously and this led to another round of disclosure and that also includes several patches and Recently about two months ago. They were they updated the guidelines and they now prohibit the use of brain pool curves all together and If we look at the latest Guidelines in the way that we try to mitigate this type of attacks So there are several guidance that we try the Wi-Fi Alliance provides to the different vendors And one of the guidelines is very simple and straightforward Please implement your code without any side channels Another guideline says that if in some case the WP3 Transition mode does not meet the security requirements Then please separate your passwords and In the end what they say is that if you fail to implement those guidelines this might Result in an attack and a compromise of the network What I am not sure is how this can be checked For me at least it's not very easy to find side channels in different coding for the many different implementations But I'm not sure if this is going to be part of the certification process or not Even after all of this there are still some fundamental issues that were not solved The main one is of course This is something this kind of protocol is very hard to implement in constant time without any side channels And on lightweight devices doing those 40 iteration is something that might be too costly And we actually saw several implementation that didn't do the whole 40 iterations Fortunately and the IEEE has now updated a draft of the standard with several of the Our recommendations the most important one is to exclude the market addresses from the hash to curve calculation all together and Incorporate it in the later part of the protocol This allows the password element to be computed offline and it does not only make the protocol much safer It also makes it much more more efficient to implement Moreover and the switch from this hash to curve that we shown that was called hunting packing to a constant time hash to curve solution they explicitly for a bit use of many different groups and They have now a post position how to prevent cryptographic group downgrade attack There are some remaining issues in the new standard and I think maybe the most notable one is that unlike many modern protocols They do not hash and the transcript of the messages and incorporate it in the key derivation This raise many issues. It makes it much much harder to actually write a formal proof the protocol and it's raises many risks of Implementation issues for example the way that they prevent the cryptographic group downgrade attack is now dependent on Different checks that a programmer should make and if we simply incorporate the transcript in the key derivation It will be made implicitly Another problem is the way the downgrade to WPWP2 This is something that's currently not addressed in the standard at all. There is a possible solution to call trust on first use which basically means if I connect to a network and see that it's WP3 I will never agree to try to connect it with it with WP2 WP2 protocol. This is actually done by both Android and the network manager of Linux But as long as there's one single device that doesn't follow this guidelines We can always attack it and use it for the offline brute force attack Another remaining issue is that those new solutions are not backward compatible. This question How can they be adopted today? Maybe there will be WP3.1 But we're not clear how the reference is going to handle this and how they're going to prevent for example The risk for downgrade attack to the current original WP3 After all this you might ask yourself should we use WP3 The question right now I think is yes WP2 is trivial to attack so anything else is probably better And in conclusion we can say WP3 is vulnerable to such an LATX that might lead to password recovery The current countermeasures are very costly and very hard to implement There is a new draft For that solves many of the issues. We're not we don't know if it's going to be adopted or not But maybe most importantly those issues could and should have been avoided in the first place if the Standardization process would have been more inclusive. For example, we just seen One example with 5G and there was the TLS 1.3 Process we think that we could have avoided all of these different problems and in that we'll be able to answer any questions Thank you. We have time for one question It's more of a request than a question. So currently CFRG is running a PIC selection process I don't think side-channel analysis has really been considered as a first-class security concern yet in the selection So, please would you guys get involved and give us some of your cycles and take a look at the proposals? We'll be more than happy to do it. Thank you. Yeah, I know that they're also using the hash-to Curved draft on there. They're really looking at but you're not the handshake itself me. Yeah, exactly. Thank you That's really cool work and then now we're gonna move on to the third talk of the session Which is gonna be on navigation security. So really looking forward to the talk and not GPS actually But on Galileo security Tomer is gonna give the talk so that's my slide. Nope Good, so this is a joint work with a long list of capable people whose names are projected here So I won't read them because I'll probably butcher their names in the native language And the talk is about Galileo authentication Galileo and for those who don't know is a global navigation satellite system or GNSS operated by the European Union and Even if you're not familiar with the term GNSS, there's at least one such system that you are Familiar with and that is the US GPS So bluntly put Galileo is the European GPS and in fact, there are four deployed Systems like that the US GPS the Russian glonas Chinese Baidu and the European Galileo In addition to two regional systems the Indian Novik and the Japanese Mitsubishi And I think that in this educated crowd Everyone knows the principles of GPS navigation You stand somewhere with your cell phone. There are satellites floating around the earth Sending their location periodically and a reference time for when the message was sent Your phone collects messages like that And it records the time in which the message was received and once it has enough of those Four in the case of satellite navigation it substitutes the values that it has Into these equations which solving them then gives you your location And we all use GNSS. I came here using by using Google Maps many cars come equipped with satellite on board satellite navigation systems and For my marathons. I use devices like this to track my progress But actually GNSS is not only a consumers technology. It is heavily used in infrastructure in aviation in marine navigation synchronizing power grids Doing things in the financial sector It is really a part of the modern's day Infrastructure which is why it's so shocking how easy it is to spoof signals in GNSS In preparing this presentation about a week ago. I searched YouTube for GPS spoofing and filtered out all results older than one week still there are hundreds of videos explaining how to spoof GNSS data and What I find most insulting in this is the Motivation doesn't seem to be hijacking an airplane or crashing down the power grid. It is to cheat in a game played on your cell phone called Pokemon Go So what we have is a critical piece of infrastructure originally designed by the US military That can be spoofed by people playing Pokemon Go now. There's no disrespect towards these people I am one of them. I play Pokemon Go and I spoofed GNSS data But I still find the risk unacceptable And so do the people at the Galileo project at the European Commission Which is why they decided that their service will offer public authentication and that means that when you use Your device to determine your location based on Galileo satellites You will have assurance that this information is true So what we need is a system and we want an open system anyone Can start their cell phone? Get the data and start navigating But we all we want only legitimate satellites to be able to send the signatures for this data So that obviously puts us in the domain of public key cryptography But actually that comes with a problem due to the frequency in which GNSS operates The bandwidth is extremely limited. It's between 50 bits per second and 200 bits per second It's 120 bits per second in Galileo And if you did context for this number about 20 years ago when I was 16 and I got my first home modem it was 43 times faster than this 20 years ago and On top of that due to legacy support The part allocated for authentication in Galileo is only 40 bits every other second or 20 bits per second on average So public key cryptography is out of the question because the signatures would just be too long And that doesn't leave us too many options, right? We only have two types So we probably should be using symmetry Cryptography, but this also still comes with problems Symmetry key cryptography is called that way because the keys to all parties are the same or parties are Indistinguishable with respect to their role in the protocol So suppose we use the same secret key for all receivers if I Receive a message which I can verify using this key It means that I can also sign another message and send it to someone else who won't be able to distinguish between Me as a sender and a legitimate sender So using the same key for all receivers is also is not an option How about using a different key for each user? Well, first it's unclear how we would do the key exchange here right what I'll just talk to the satellite tell him Okay, we'll run a Diffie-Hellman dear satellite So not that and even if there was a way to disseminate these keys And there's still the problem that the satellite would have to sign the same information using different keys and send them to all the Receivers on a channel that I've already told you that is extremely limited Which leaves us with the question of what? Can we still do? So I will now present the system developed at KU Louvin and just to clarify I'm not this is not a proposal. This is the system that Galileo will be using it has been approved on all levels Already implemented and testing should commence sometime soon. I'm not exactly sure when and the system is based on Key hierarchy. I use the pyramid because I'm not sure in the hierarchy whether the bottom of the pyramid is the top or the bottom of the hierarchy We have several layers of keys and I'll go into each of them. Hopefully then you'll understand how the system works So at the bottom of the pyramid, we have the root of a Merkel tree a Merkel tree for those not familiar with the concept and this is a bit awkward to explain what Merkel trees are Merkel is in the audience. I hope I do it. Well And a Merkel tree is a way to provide a short commitment to multiple values What you do is put the Values you want to commit to in the leaves and in the first step you hash each of them separately that's this layer and Then you hash Two values at the time to create a tree like structure then the commitment is the root of this tree Now I want to authenticate a value. Sorry. I want to reveal one of the commitments So I provide the value I want to reveal along with the authentication path Which are the nodes with a circle around them and what the verifier does is to Hash this value and they get this value and then they hash these two values and they slowly rebuild the tree and compare the root they get with the commitment they received and if they match it means that the Value sent was part of the original commitment. Otherwise, it means that Someone found the collision in a collision free hash function Also, this doesn't expose any other value because let's say that I you have this value Going backwards in the tree means that you can find a pre-image in a pre-image resistant hash function Which we assume to be hard In our case what we put in the leaves are public keys Not too many of them and those will be used throughout the lifetime of the system which should work for 10 20 years and We really hope that we would never need to replace any of those keys, but just in case we have a few others The root of the tree is hard-coded into your device So what we have again is a Merkel tree Used to authenticate a public key and the public key is used to verify a digital signature for a root key I know that I said that there's no room in this protocol for digital signatures. Well, I lied and As long as you don't have to append a digital signature to every message you send We can once in a while if Infrequently sending a new root key we can probably fit in a digital signature And I say probably but we know that we can because we're testing the system now What is a root key? A root key is the end of a hash chain. The hash chain is built by selecting a Secret key and hashing it and then the output is hashed again and each output is hashed And we have now a chain of hashes and the last value in this chain is the root key The root key can be made public because it's the output of hash function so you cannot go back in this chain and It is authenticated using a digital signature then the root key is used to authenticate an effective key The effective key is another Link in this chain Now I'll tell you in two slides what's effective about it. Meanwhile, I'll tell you that having one of those keys Let's say the one before last It's easy to verify that it's called by hashing it once if it maps to the root key that we've authenticated using a digital signature It means that it was sent by the original Generator of the chain because no one else can find a pre-image But for me as the person who generated the chain, it's easy to provide pre-images. I just hash forward and Finally the effective key Or an effective key is used to authenticate our payload the message or the location data M And for that we use the Tesla protocol developed by the rigged others in 2005 And it was works in the following way The time is split into discrete components and I guess you can't see it But it's I minus one I I plus one, etc Each link in the chain is associated With one time frame and that's the an effective key is the key associated with what we think of as now Later this key will no longer be effective. It would be obsolete and we will have another effective key Now how do we authenticate a message here? In the first time frame and every subsequent time frame We get three data items we get M I'll call it M minus one, which is the location data for that time frame And a message authentication code, which is the symmetric key analog of a digital signature So a Mac of the location data M I minus one with the effective key K I minus one Now I don't have this key so I can't check the Mac. I take these two values and just store them somewhere for a later use The third data item is KR the root key Which as I said is Verified by means of a digital signature so far. I don't have my location and I haven't authenticated any location That's fine moving on to the next time step. I Again, I get the location data M. I and the message authentication code M. I Sorry the message authentication code for M. I using the effective key K. I And I don't I can't verify that so I just store it And I also get K I minus one that's an obsolete key that was effective in the previous time frame You know what I do is to hash it and see if it matches a key that have already authenticated In this case KR if it does I fetch the two data items from the previous time frame And I can now check the Mac if it checks out. I Know that I can trust M. I minus one that was authenticated using this Mac Moving on to the next time frame the same thing happens Three data items MI plus one and Mac of MI plus one with the effective key. I Store those and I get K I an obsolete key K I is hashed and if the output matches K I minus one K I minus one. I know to be authentic So now I fetch these two data items for the previous time frame and I authenticate them and This is done over and over until the chain is exhausted a chain should last for about three months And then it's replaced and that's how our authentication protocol works what we see here Is an is an authentication scheme That authenticates values in a with a certain delay in this example the delay is one time frame but the Galileo protocol actually allows Different time frame, so it supports multiple delays up to five minutes for different use cases And this is it Then we also had to make some changes to the original protocol If we would use them it in the naive way, we would need a hash chain For each satellite right we need we have a constellation of about 24 satellites So 24 chains each of them requiring a different root key means also that we each of them requires a different digital signature and That would very quickly eat all of our bandwidth. So instead we found a way to use one chain in all satellites Another change we made is that the in generating the hash chain It's not only the effective key that is given as an input. We also add an I value. This is a reference to the time frame in which this key will be effective and It's like salt in password hashing for that particular key and an alpha value Which is sold for the entire chain and also some random stuff because why not? This is an actual system and it should be working for a really long time And we don't know whether shot 256 will be secure for the entire duration of the system So for each of the primitives we use we have several options and For hashing we use shot 256, but we also support shot 3 224 and shot 3 256 for Mac Macking we use HMAC shot 256, but we also support CMAC AES and for digital signatures We use ecd assay with these curves all of these are Parameters you get from the satellite in the header of the message telling you which primitives are being used for the particular instance Our security parameters Unfortunately, even after building this complicated system with the key hierarchy We can't fit all the data. We need to send into a message So we have to truncate some values and I hope this is not too outrageous. It should be and I hope to survive this We truncate the effective keys to 90 some of between 90 and 128 bits And we truncate the message authentication codes to somewhere between 10 and 32 bits Now I don't recommend using max of 10 bits not even 32 bits, but in our particular use case We have a security analysis showing why this is secure I don't think I have time to talk about it, but maybe in the questions phase So to conclude Galileo will be using sorry Galileo will be offering a Way to authenticate publicly the navigation data you receive from it so that you can play Pokemon go without fearing that someone will Cheat and steal your Pokemon gym. Thank you Questions Let me ask one question. So these kind of systems, they're very difficult to change once you deploy once you deploy them They're going to be out there for decades So aren't you worried about quantum attacks like in 30 years 40 years? ACDSA who knows where it's going to be so I agree These decisions are made above my pay grade We actually discussed the possibility to include so I this would probably The issue would be here in the digital signatures. I know that they've considered adding Post quantum signatures as supported mechanism and decided not to and again. I don't get this vote in this Okay, maybe I misunderstood something it's not to me like you have relying on very long chains and you only sign the very first message What happens to a a GNSS system which is turned off? For the first half month then comes on and then starts hearing it. How does it how is it going to? Get the verified case of i-values. Yeah, so the root key is sent constantly by the satellite as the We have time for a slightly longer question Each packet you receive from the satellite has the disinformation that I just explained and some management stuff admin admin values one of those admin values are the is the root key and its digital signature So if you get this key for example, you also know What your time reference is you just hash it multiple times and see that it matches The root key that you also received from the satellite with the digital signature. So how long is the chain actually? Is it like a million hashes or it's about well, it's three months About three time three keys every 30 seconds someone here's probably a bit mathematician than I am but three Six keys every minute for three months. Okay, so okay. Yes, you a huge number of hatchets. Okay So How do you prevent an attacker from? Taking the signal from the satellite Delaying it Amplifying it slightly and then the receiver locks on to the amplified signal and can't decode the original signal It's authentic, but it's been delayed. So now there's a shift in the position from the satellite But the yes, so first of all This system does not prevent someone from just jamming the signal. That's not what we offer here The receiver know has loose time synchronization with the satellite so it knows which key Since the time reference is part of the key you won't be able to use it after the time frame ended so if you're using the rapid Authentication you can delay it by 10 second maybe even less Satellite navigation is even less accurate than that So that's not really a problem and beyond that the satellite can detect that the message has arrived too late and cannot be used You don't see it. I mean we're talking, you know a Microsecond delay is a is 100 meters a Millisecond delay is several kilometers. So I'm not sure about these numbers possibly Well, I don't have this slide here the error Accumulated when the satellite send you the signal is anyway larger than this Set a satellite navigation is less accurate than what we think What we use again not my field been explained that is Assisted satellite navigation. So your precision comes from the assistance part anyway and not from the satellite But I think the cryptography is not designed to defend against those kinds of attacks I mean this there are other mechanisms and the systems are more physical mechanisms that are designed to defend against that against Jamming but you're just jamming replaying. He's referring to a replaying attack Well, no, so the cryptography does prevent replaying as long well with within the delay of the loose time synchronization You have with the satellite Okay, well, this is a good topic for an offline offline discussion Fantastic. Thank you. This has been fantastic. I really really really talk All right, so we have a break coming just before we break a quick announcement There's a clicker that's been found. So if anybody wants a clicker, they'll be a clicker up here on the on the on the Stage and so we have a break now and we're gonna resume at 11 a.m