Submind YouTube summaries
Thumbnail for Real World Crypto conference 2020:  session 11

Real World Crypto conference 2020: session 11

Watch on YouTube

Video summary

The Real World Crypto 2020 conference highlighted critical vulnerabilities in modern communication and navigation systems, emphasizing the necessity of formal methods to ensure security. David Basin demonstrated how model checking tools like Tamarin Prover were applied to analyze the complex 3GPP 5G authentication protocol, reducing over 720 pages of documentation into roughly 500 lines of verification rules. This rigorous analysis uncovered significant flaws, including an omission in binding subscriber identifiers that could lead to billing errors and a tracing attack where replaying error messages allowed adversaries to track users despite the use of temporary identifiers. Basin concluded that such formal methods are essential for catching subtle design oversights before standardization is finalized. The session then transitioned to discussions on WPA3, where speakers revealed that timing side-channels during password verification could still enable offline dictionary attacks against Wi-Fi 6 and early implementations, even after mitigation attempts like fixed iteration counts failed to fully eliminate variance in code paths. Further investigation into WPA3 security exposed a range of implementation-specific weaknesses beyond simple timing leaks, including reliance on system time for entropy which poses catastrophic risks, denial-of-service vectors through expensive computations, and downgrade attacks facilitated by curve selection flaws. While the Wi-Fi Alliance issued guidelines prohibiting side-channels and updated standards to enforce constant-time methods that exclude MAC addresses from hash-to-curve calculations, fundamental issues regarding transcript inclusion in key derivation and backward compatibility remain unresolved. The consensus was that although new drafts address many of these problems with costly countermeasures, widespread adoption remains uncertain due to the persistence of vulnerabilities like "trustful first use" requirements for downgrade prevention. These findings underscored that simply updating standards is insufficient without addressing deep-seated architectural choices in open-source implementations and ensuring robust entropy sources are universally adopted across hardware manufacturers. In parallel, the conference addressed spoofing risks within Global Navigation Satellite Systems (GNSS), noting that GPS signals can be easily manipulated for trivial applications like Pokémon GO but pose unacceptable threats to critical infrastructure due to bandwidth limitations of approximately 120 bps. To overcome legacy constraints restricting authentication to only 40 bits and making public-key cryptography impractical, the Galileo project implemented a symmetric key hierarchy based on Merkle trees where roots of trust are hardcoded into devices and authenticated via periodic digital signatures from satellites. This system utilizes hash chains lasting about three months with time-frame references acting as salts to generate effective keys truncated to 90–128 bits, while Message Authentication Codes were reduced to 10–32 bits based on security analysis proving sufficiency despite truncation. The protocol allows receivers to authenticate location data by verifying MACs against current effective keys and validating key transitions through hashing against previously authenticated roots, effectively managing the tight time windows required for secure navigation without relying on impractical signature sizes. Despite these innovative solutions using SHA-256 and ECDSA with support for various hash functions, concerns remain regarding future quantum attacks as post-quantum signatures were not yet included in the standard. The Galileo system relies heavily on physical mechanisms to handle signal jamming and delay rather than cryptographic defenses against replay within tight windows, allowing variable delays up to five minutes for different use cases but lacking backward compatibility with older protocols without risking downgrade attacks if non-compliant devices exist. Ultimately, both sessions converged on a central theme: the transition from theoretical security models to real-world deployment requires continuous vigilance, as even minor oversights in protocol design or implementation can lead to severe privacy failures and infrastructure risks that only rigorous testing and adaptive standardization practices can mitigate effectively over time.
Read the full video transcript
all right so we already 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 who's gonna talk about 5g security so David all yours thank you so I need a clicker is this the just the right one somebody took the clicker I'd love to give a talk but we need new tactics occur 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 and 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 international across countries one is the team of researchers who have worked together with me on the tamarin project and I listed 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 v t 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 big thanks to those people who worked with me also I just like to mention that for some of the sites I'm Tamara and I'd like to thank calves because their 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 faces 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 than 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 ourself why all of these nested hashes and well there are good practices and one good practice is you use different keys from different things for 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 GD x g the y's are sometimes written another order and these cookies against denial of service or sometimes also change and you might ask yourself this 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 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 and our environments have adversaries so against what adversary does that have the properties who 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 IETF 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 wants to ask 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 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 within 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 ie the adversary which with which it interacts and also the properties and if we do this well and we have supporting tools than 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 are some great work at Oxford with cast cash Kramer'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 were 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 at 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 an 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 his program should not suffering 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 is authenticate really mean their various ways you can make that precise and finally of course the 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 of symbolic model and here even for very simple classes of protocols basic properties like as a key a 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 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 acute monkey and tamarin is basically our tamarin is basically a constraint solver that solves constraints about what the adversary could do in a particular situation and then we turn that constraint solver into a few improver so it's a constraint solver disguised as if you're improver I'll say a little bit about what tamarin does I won't say really how it works I want to 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 false applies your property or property and in our case with tamarin we use constraint solving define 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 into leave runs the protocol arbitrarily 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 patience etc and then tamarin allows you to go into an interactive mode where you can work with this theorem prover constrained solver to interactively construct a proof or to provide hints so sometimes you need exhilarate invariance or even possibly change the underlying proof strategy being used that's called Oracle's 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 but the adversary knows etc so here's a little example so in multi said rewriting our rules transform a left-hand side to the right-hand side and it 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 n represents input to the network of some K think of it as a key and in our multi set some a protocol automata with some thread ID thread ID is in some step is in its first step then in that case our protocol would say well advance your step two step two and output on the network and acknowledgment and also in your state record that you receive this key K okay so this would very person to transition from taking input off the network to recording and outputting a response and this would be labeled with a threat ID have accepted que se as a key so this gives rise to transition system with the tre semantics so now imagine we have a state of our system says this bag this multi set of facts and this multi set we have many facts but among them are that key is input to the network and some thread ID 3 is in step 1 then we can match that with the left-hand side of this rule so key would be instantiate K would be instantiate with key thread idea would be instantiate 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 instantiating right hand side so we get a new state with AK output on the network and this thread ID has advanced its state and recorded that it's gotten the key moreover 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 entered what we understand by a trace the trace amman --tx is the sequence of these red parts here and that trace is important because we specify properties over traces so 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 I have multiple roles in each role will have a role automata there might be a initiator role or 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 multiset rewriting rule okay so in general you'll have quite a lot of multis head 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 dual of yao adversary historically at least in the symbolic setting but as cryptographers here know a network adversary you know seems strong they see everything they can they can interfere but actually we want to that are even stronger adversaries who can for example corrupt long-term secrets corrupt around a number generator corrupt session state this would correspond to different Oracle's in the computational setting so here's an example of how you might specify session reveal yeah excuse me right so you can specify these 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 themself are specified in a guarded fragment at 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 threaded e's 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 of well what does tamarin really do what's the magic of tamarin so tamarin takes these specifications of the role automata of the adversary of the security properties and then it uses various constraints all VL gorillas 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 tamarin that was kind of a quick high-level bluffers guide to what a model checker my - 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 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 fourteenth two thousand eighteen this is a protocol that is going to have massive uptake so right now most of you are using four G so LTE maybe in some places of the world even 3G but for current cellular services we have about five billion mobile subscribers and we can expect that and more for 5g because 5g will also be used enable the Internet of Things and things like this and you can expect that a large portion of the world's population will eventually have 5g axis 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 the thent occation 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 au sim a universal subscriber identity module I want to be able to use this for for telephone calls and so I am Swiss and I have a phone registered in Switzerland with Swisscom so Swiss come is my home network and I come here in New York and according to my phone phone my serving network is t-mobile so I don't have any security association 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 some security you typically don't get security from nothing so we have some set of assumptions namely that on my use sim my my user subscripting user equipment in the home network will share a symmetric key it will I'll have a permanent identifier called the su p we also had su piece in previous versions of 5g like 4G that's a subscriber permanent identifier the su p is privacy relevant and in 4g there were problems with MC caches because as you go around say in New York your phone is often transmitting your su p 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 and something called a tsuki we're gonna see that later so the su p will be used to drive a tsuki and that'll be derived 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 the sequence number based protocol and I will also my use we couldn't we'll also have the public key of the home network ok sets the set up 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'd 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 supey but I will mask it I will encrypt it using the home networks public key so here this is just my terminology for asymmetric encryption is 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 case we heard I have a little message sequence chart this shows the little setup assumptions who knows what and I'm going to send the tsuki from the subscriber to the serving network and then the serving network now knows who the home network is so it says I am the serving network and here is the Sookie 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 FS are keyed a keyed one-way functions and there are also various other one-way functions such as challenge and the like in PC which is used for key derivation function some of these have slightly different properties but I won't go into those details for now so what would would be what we do here is we use this shared key shared with sis with 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 two 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 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 in the clear and the pair of this for this encrypted sequence number and the Mac is called attend 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 the the serving networks name we generate a key seed and this will be used eventually by the serving network in the subscriber to derive a common shared key and we increment our counter for the home network ok 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 an expected response in this key seed function for driving a key then the randomness and this authentication information is sent over to the subscriber and what is 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 of for the home network then it can also compute you have little explanations here 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 maket received so in other words it checks the authenticity of the information god over-the-air whose the communication between the serve 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 a serving network and 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 Sookie to the home network than the home network says I now give you the serving network the soup P so you know really which subscriber you're talking to because until then the serving network hasn't authenticated the subscriber it just has a sookie which is a pseudonym but now it really has a soup P so it can use that for billing and for other functions okay there are two failure cases the first thing we thought is that there's a failure mode where the mac checks so 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 involved 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 padded 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 seven hundred and twenty two pages in in 3gpp 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 may have a precise understanding we can make things formal and check so here are questions you might ask is the home network talking to a subscriber talking to user equipment with the ballade you sim or to an imposture privacy so for G had the problem with in CMC catchers but am i traceable as I roam through New York and if so how would that work so here we use Cameron 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 X horse an operator so we have to be able to adequately model different cryptographic operators and XOR is fairly difficult to handle we formalize that equation Lee and it makes it very difficult to integrate XOR is very difficult to integrate into our constrained solvers are constrained for solvers work well it's something which is called sub term convergent theories and this isn't one of them so we had to go off and develop theoretical basis for integrating XOR privacy requirements are also quite tricky so to see if you're being tracked those are not trace properties they're hyper properties there are 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 that's required extending our tool notches to verify protocols with respect to trace properties but also observational equivalence and of course there can be unbounded lis 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 observational equivalence an XOR okay so how the formal analysis worked we formalized RAF 1.0.0 of the standard and this required following the standardization body for about a year building based models and augmenting them with their different changes so keeping up with them and this is a methodology that seems to work fairly well for example the Oxford team with the Cass Kramer's did this for for TLS 1.3 and you can really you know as verification engineers so to speak follow standardization committees and give them feedback we had to work with the documents of the 3gpp and that was over 722 pages of documents and it required a little bit of interaction to make things precise to understand them and 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 will first verify the 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 so that 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 would we find out for authentication so what properties should hold well the standard itself specifies surprisingly few and weak attenti keishon 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 cumin I know who the serving network is they know who I am 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 whereas here the sukiya sent and then the soupier sent doesn't bind the supey to anything at all so in a in a world where interleave messages are possible it's possible for the serving network to get the wrong supey and if this were to occur this would be a real problem it could result in building 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 is a case of caching a simple mistake it's almost like type checking this type of stuff shouldn't happen there are 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 Keen 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 to have explicit authentication it turns out it's very easy to get in this protocol with very minor modifications no additional cryptography 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 but also interesting is Sookie is security and privacy so here are 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 also that's okay the long term key will remain secret when running the protocol this is all fine but there's something which wasn't fine and this was a real shock the supey 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 untraceable ax T 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 Reese where I resynchronize 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 supey isn't being sent in the clear but the error messages are actually enough to trace absque rye burrs 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 attack the tacks are real the attacks matter it generated a fair amount of media here I have just some of the media in English in German in French etc I had lots of interesting calls with handset manufacturers and liked 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 tamarind 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 twenty years ago we were doing very simple Alice and Bob exchange a key now we can handle protocols at the scale of a TLS 1.3 and 5g and I think standardization efforts should really be doing this they should be following the development of the 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 in 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 won 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 let engineers know you can use these tools and to work together in training engineers thank you [Applause] we have time for one question okay so I am one of the user of Tamra improver and you said about different kinds of adversary so how can you modify the capability of Dolloff yarr so I gave you an example of sessions tape reveal you just add rules right so we add rules that okay because I was trying to have a Vickie heat diffie-hellman model and yeah so for diffie-hellman you would want to have perfect forward secrecy perfect forward secrecy is just secrecy where you have a long term key reveal 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 can we just throw away those 700 pages and just use your 500 lines to understand the I I would say you should use both together so so the seven the 722 lines contain additional things for example hey Giselle things for example data type definitions so so you know how big are strings and things like this there's some justification arguments for things you get some history referenced others to answer I think you need both so I think that that it's in formal or semi-formal documentation should be complemented with formal models this model denial service attacks to dad 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 of service of service like say can they get you to perform can the adversary get you to a point in the protocol to perform expensive cryptographic operations you can analyze those types of things with these tools but that wasn't here [Applause] okay that was a fantastic talk and I guess we're gonna move on to another wireless protocol wg3 which was actually not on the list of protocols analyzed and so we're gonna hear about dragonblood okay good morning everyone thank you for the introduction so I will be talking about dragonfly and how it is used in wp3 ants EEP PWD so I am motif on oof and I did this work together with AOL Rowan Ronan who will do the second half of this talk 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 data find WPA based on a draft over the I Triple E standard and finally we have the latest I Triple E standard of wpa2 but wpa2 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 um they decided to use the so called dragonfly handshake on the dragonfly handshake is what we call a pig meaning a does authentication based on a password on dragonfly previously was also used in the EPW deep 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 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 wpa2 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 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 can execute the actual first phase of the messages this is called the commit phase and to simplify it the commit phase essentially negotiates a new session key in the second phase of the handshake we have the confirmed phrase aunt and a high-level this confirms that both peers negotiated the same key and 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 and the access point and we can then take the resulting output from the hash function and interpret it 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 coordinates so that's a problem so how did they decide to handle this well they decided to add if test here where there were they first check does this square root have a solution and if not they will execute extra iterations they will include the encounter into the hash function here that calculates the x-coordinate this means an 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 TRG the in fact warned about this timing leak but the designers didn't consider this series enough they thought ok 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 on induce the client into connecting to us and we can also do it the other way around we can act as a malicious client and 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 and 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 and we effectively get an independent execution of our algorithm so to come back here we can spoof a 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 RockYou 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 1 and the reason why we picked a raspberry pi 1 is because it's CPU is similar to a common home router and even some professional access points in this case we attacked the EPW D protocol so this is for example used in I would say about 3 to 4 percent of a neural networks yield attack was surprisingly effective when we make around 30 measurements per MAC address ant we filter out noise using Crosby's box test then 30 measurements is enough to recover the number of iterations so that covers the case for a PWD which was defined already several years ago when they standardized WPA 3 they did realize that they finally listed to die if I TF ones here for G at least partly ant they included countermeasures so what I did with WPA 3 they try to prevent leaks by always doing 40 iterations here on simply 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 blind that constant time to again try to prevent side channel leaks on top of that once the real password has been converted into a group element here they will execute the extra iterations of these total of 48 aerations 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 it 256 bits curve the the what is returned here are the first 256 bits of the hash output now the problem is if we use brain pool 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 on that we do introduce a small theoretical base in the calculation so we want to avoid that and how did they decide to avoid this well they simply used rejection sampling sampling unincluded an if test here so the question is is it our 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 escaped 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 variants 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 variants 0 on top of that the average execution time also depends on on which iteration the password was found as well so both the variants 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 WPA 3 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 here we'll talk about some more vulnerabilities ok thank you so now we're going to talk about cache attacks and we're going to use a relatively similar similar type model but now we've 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 smart phone it might be sufficient and it's only required to be able to measure such a macro contextual 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 lesson is that it needs to use the prime number that is very very close to a power of 2 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 this is an enabler 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 valuable 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'll also going to monitor the code to the hash notion and this is supposed to give us a kind of time doing different iterations now as this type of a text is usually very noisy and we will only want to we have a one bit of information many if this first iteration was successful or not and to do it we use and what's called the cache template attack and we're going to run several measurements and we're going to give a specific idea or number to each possible resort 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 it is easy to see that those distribution are very distinct and basically all we need is about 20 measurements in a very simple linear classifier to be able to lick this one bit of information now we see that we are able to leak information and password both with cache attacks and which time in the text but the question is can we actually exploited 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 database of password which include all of the password dumps ever linked to the internet it will cost us about 2 cent in the worst case which is the recovery of password for the missed curves and even if we go over a very large personal domain Archaea nate symbol it still suffered 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 tried 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 better randomness and for example one implementation uses the system tank as the only entropy sauce and interesting fact is is that for wpa2 this doesn't really matter it doesn't even affect the security over for WPS so this is catastrophical and allow us to actually recover the password element another shocking finding is that we are able to perform invalid health attack several implementation didn't verify the point that they received in the handshake and this basically enabled us to recover the session key in by president dedication there are also several Wi-Fi specific attacks and the simplest one is denial of service and doing the entire fourth iteration is something that's very computationally expensive and it's relatively easy to saturate the access point CPU and then cause it was monthly spot to stop responding there is also the danger of downgrade attack basically in transition mode above WP to in WP network share the same password now this is something that has been handled by their standard and doing the handshake this done great will be detected and the connection will be dropped however this will only happen after a partial completion of the WP toe and check 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 it's relatively easy to downgrade their chosen curve so we can foster and the client an access point to use curves that are ideal and we cook in perfectly Oh easier to attack using sectionals so after we've had all this funding we started a very nice and interesting process of disclosure with the Wi-Fi lines we try to notified all of the involved parties as early as possible because we wanted to be able to try to influence the WPA standard direction 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 baneful 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 enough for hibbett the use of curbs all together and if we look at the latest guidelines in the way 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 a very simple straight fault please implement your code without any satchels another guideline says that if in some case the WPS three transition mode does not meet the security requirements then please separate your passwords and in the end what you say is that if you fail to implement those guidelines this might result in an attack and copies of the network and what I am virtual is how this can be checked for matrices not very easy to find such channels in a different codec for 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 solve the main one is of course this is something this kind of protocol is very hard to implement in constant time without any state units and no matter what device is doing this 42 version is something which might be too costly and we actually saw several implementation they didn't do the whole 48 directions fortunately and I Triple E is now updated a draft of the standard which several of the our recommendations the most important one is to exclude the MAC addresses from the hash to curve calculation or together and incorporate it in a 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 more well and this switch from this hash to curve that we shown with was called hunting and pecking to a constant time hash to curve solution they explicitly prohibit the use of many different groups and they have no oppose position how to prevent a cryptographic group downgrade attack and 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 hush in the transcript of the messages in in propagated in the key derivation this has many issues it makes it much much harder to actually write a formal proof the protocol and it 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 Pokemon should make and if we simply incorporate the transcript in the Kindle evasion it will be made implicitly another problem is the way the dumb go to WP aw pay - this is something that's currently not addressed in the standard at all there is a possible solution what we call trustful first use which basically means if I connect to a network can you see that is WPA I will never agree to try to connect it with with WEP to wpa2 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 these guidelines we can always attack it and use it for the offline mode 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 a WPS 3.1 but we're not clear how the why freelance is going to end this and how they can prevent for example the risk for Dan we detect to the current which will WPC after all this you might ask yourself should we use wb-3 the question fight now think is yes w2 is trivial to attack so anything else is probably better and in conclusion we can say wp3 is vulnerable to stir channel attacks that like might lead to password recovery the current control measures are very costly and very hard to implement there is a new draft for that solves many of the issues we are 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 and for example we just seen one example with FFG and there's the TLS 1.3 err process we feel that we could've ended avoided all of these little problems and in that we'll be happy to answer any questions thank you great we have time for one question it's more of a request than a question and so currently CFR G is running a pig selection process I don't think side channel analysis has really been considered as a first-class security concern yet in this election so please would you guys get involved and give us some of your cycles and take a look at the proposals thank you yeah I know that they're also using the hash to curve Draft on there they're really looking at but you're not the handshake itself me exactly thank you okay 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 a talk all right so that's my slide nope good so this is a joint walk with a long list of capable people whose names are projected here so I won't read them cuz 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 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 u.s. GPS so bluntly put Galileo is the European GPS and in fact there are full deployed systems like that the US GPS the Russian GLONASS Chinese Baidu and the European Galileo in addition to two regional systems the Indian narvik and the Japanese michibiki and I take 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 the location periodically in a reference time for when the message was sent your phone collects mesh messages like that 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 you'll use GNSS I came here using by using Google Maps many cars come equipped with satellite not the onboard satellite navigation systems and for my mother tones I use devices like this to track my progress but actually GNSS is not only a consumer's technology it is heavily used in infrastructure in aviation in Mali navigation synchronizing power grids doing things in the financial sector it is really a part of the modern-day infrastructure which is why it's so shocking how is it is to spoof signals in Genesis 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 explain how to spoof Genesis data and what I find most insulting in this is the motive that the motivation doesn't seem to be hijacking an airplane all crashing down the power grid it is to cheat in a game played with 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 spoof Genesis 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 a 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 that we want an open system anyone can start their cell phone get the data and start navigating but we 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 Genesis 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 need 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 of 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 symmetric ography but this also still comes with problems symmetric key cryptography is called that way because the keys to all parties are the same all parties are indistinguishable with respect to the 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 the server's 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 call it if he held it alight so not that and even if there was a way to disseminate these keys 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 Cal Leuven and just to clarify I'm not this is not a proposal this is the system that Galilei 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 kill and I'll go into each of them hopefully then you understand how the system works so at the bottom of the pyramid we have the route of a medical tree a medical tree for those not familiar with the concept and this is a bit awkward to explain what medical trees and medical is in the audience I hope I do it well amiracle 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 have each of them separately that's this layer and then you have two values at the time to create a tree like structure then the commitment is the 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 pad 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 route 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 have this value when backwards in the tree means that you can find a pre-image in a pre-image resistant hash function which we assumed to be hard in our case what we put in the lives of public keys not too many of them and those will be used to out the lifetime of the system which should walk for I know 10 20 years and we really hope that we would never need to replace any of those kids 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 medical tree used to authenticate a public key and the public key is used to verify a digital signature for a wood key I know that I said that there's no room in this protocol for digital signatures well I lied as long as you don't have to obtain the digital signature to every message you send we can once in a while 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 the root key a load 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 wood key is used to authenticate an effective key an effective key is another link in this chain now I'll tell you in two slides one what's effective about it meanwhile I'll 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 the 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 three images I just hash forward and finally the effective key of 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 Reagan others in 2005 and it was walks in the following way the time is split into discrete components and I guess you can say it but it's I minus 1 I plus 1 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 is now later this key will no longer be effective it would be obsolete and we will have another less active key now how do we authenticate a message he'll in the first time frame and every subsequent time frame we get three data items we get em I'll call it n 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 map of the location data mi minus one with the effective key ki minus one I don't have this key so I can check the Mac I take these two values and just stole them some well for the later use the third that item is KL 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 mi sorry the message authentication code for mi using the effective ki KI and I don't I can't verify that so I just store it I also get a I minus one that's an obsolete key that was effective in the previous time frame what I do is to hash it and see if it matches a kid have already authenticated in this case KL if it does I fetch the two data items from the previous time frame now I can now check the Mac if it checks out I know that I can trust mi minus 1 that was authenticated using this Mac moving on to the next time frame the same thing happens played at items mi plus 1 and Mac of mi plus 1 with the effective key I store those and I get ki and obsolete ki KI is hashed and if the output matches ki minus 1 ki minus 1 I know to be authentic so now I fetch these two data items with 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 10th occasion protocol works what we see here is an is an authentication scheme that authenticates values in 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 wood 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 in generating the hash chain it's not only the effective key that is given as an input we also add an AI 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 sha-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 sha-256 but we also support sharply 224 and sharply 256 for mac macking we use h moksha 256 but we also support Simic AES and for digital signatures we use ECDSA with these curves all of these parameters you get from the satellite in the header of the message telling you which primitives are being used for the particular instance all security parameters unfortunately even after building this complicated system with the keyhole key we can't fit all the data we need to send into a message so have to plant eight some values and I hope this is not too outrageous it should be I hope to survive this we truncate the effective keys to 90 some of between 90 and 128 bits and we translate the message authentication codes to someone between 10 and 32 bits now I'm 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 solid gelila 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 [Applause] 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 gonna be out there for decades so aren't you worried about quantum attacks like in 30 years 40 years ECDSA who knows where it's gonna be so I agree these decisions are made above my paygrade we actually discussed the possibility to include so I this would probably they should 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 a vote in this okay maybe I misunderstood something it sounds to me like you have relying on very long chains and you only sign the very first up message what happens to a day GNSS system which is turned off for the first month I think comes on and then it 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 on each packet you receive from the satellite has the base information that I just explained and some management at minimal use is the root key and it's 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 a 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 times three keys every 30 seconds someone who is probably a bad mathematician than I am but three six keys every minute for three months okay so okay yeah huge number of hashes 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 onto 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 satellite but yes so first of all this system does not prevent someone from just jamming the signal that's not what we offer heal 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 SEC 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 is arrive too late and cannot be used you don't see it I mean we're talking you know a microsecond delay is a 100 meters a millisecond away is several kilometers so I'm not sure about these numbers possibly I don't have this slide here the error correlated when the satiric sandy 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 question comes from the assistance part anyway and not from the satellite but I think the cryptography is not designed to detect to defend against those kinds of attacks I mean this there are other mechanisms in the systems or more physical mechanisms that are designed to defend against that against German but German replaying he's referring to re playing attack well no so the cryptography does prevent a plane 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 a really really very pop all right so we have a break coming just before we break quick announcement there's a clicker that's been found so if anybody wants a clicker there'll be a clicker up here on the on the stage and so we have a break now and we're gonna resume at 11 a.m.