Enhancing Security of Bluetooth Secure Connections via Deferrable Authentication

Key Takeaways

um so hello everyone my name is bet d uh from cryptography team uh today we have Olga sanina from Technical University of damad and she's joining us from Germany uh remotely unfortunately and she's going to talk about the Bluetooth uh protocol stack and the most importantly the security and vulnerabilities of that uh stack and Stage is yours Olga welcome thank you for the introduction thank you also for inviting me it's really nice to have so many people interested in Bluetooth and really looking forward to my talk so before I start I will give some disclaimers uh first of all uh I'm really passionate of Bluetooth so I really love it with my heart and sometimes I can say things like I like or I dislike so in this regard all the opinions are on my own not of my employer or of my co-authors it's only mine then I will also show you some attacks and these attacks are publicly known they have been disclosed but just to be sure that I'm not going to show you anything like what is not publicly known so far and finally as I show you some attacks they're only for educational purposes like it's not a guide how to hack bluo or anything I do not encourage you to do so so just enjoy the talk um so BL is almost like everywhere right we use it I don't know for example now I have the headphones and they're connected via Bluetooth so when we talk about Bluetooth we talk about two types usually first one is classical version or basic rate enhance data rate so I will probably use both this terms so you might need to remember this and this type of the connections in Bluetooth is more stable so you might need it when you want to stream some data like for example with headphones you still want to hear the people talking about or in the car for example or if you play some video games you also want to have really good connections and there is also the low energy version that was in used mostly for devices that do not have really high memory or they do not have high energy so they have like small battery and these are usually like SmartWatches or I don't know lockers and some controllers um there are also some devices that can use both mods uh so-called dual mode and these are usually our smartphones or our laptops um and there is something also interesting as Bluetooth mesh so this is mostly used for um mesh networks so that each devices can talk to each other and not through some Central one in this talk I will not talk about Bluetooth smash it's just for you to know that okay it exists um I will focus mostly on classical version maybe a little bit I will touch low energy but let's see so now you might ask me here okay where is contact tracing here because this is what people usually ask me uh so contact tracing is a little bit different kind of so it still uses Bluetooth but what I'm going to talk today is about Connections that are uh longterm and they use um B directional communication while uh contact tracing is usually just beaconing so you just send some message and then you forget about it like you do not get any response and this are not long-term relationship it's just like you're just sending things and that's it all right um so when we want to connect Bluetooth devices I guess some of you might know then we basically take these devices and then we need to discover them first so if you ever connect it they first need to go through some parent process and this parent might be like you see some digits displayed on your screen or maybe you do not see anything but you still see that the devices pairing so and the same one you will see of course on the other device and when you did this initial pairing and the devices kind of remember it each other then you can also just connect any time because you already know this device and it's saved so for example I'm using headphones right now so whenever I just want to use them I just open the saved devices I click the button okay this is the device that I want to connect with and then they're just connecting so this is how it looks for from the user perspectives but let's look how it looks from a little bit more crypto perspective so it's still a very high level protocol description um so we again have this initial connection and we have reconnection and it starts with the physical connection on the physical layer level so this is because we use wireless communication right so we still need to exchange some physical information like what frequency we're going to use what channel we're going to hop and so on most importantly for us here we sent over the device address you can think about it as the MAC address of the devices so there is also a mechanisms to change this one but you can only just think okay this is the MAC address then the devices need to connect on The Logical level so they exchange what are their capabilities that can you do this or that protocol can you use this algorithms what size of the key do you support like such information that helps to make a decision on what exactly protocol out of the protocol stack you will be using uh and then the pairing happen so here I have it for the secure connections which is the most secure protocol in the stack and it consists of the eliptic D on the exchange when the devic is just exchange some public shares then they exchange the notes and they do some kind of key information on what they exchanged before as a result of this communication they derive the so-called link key in the Bluetooth classic or long-term key in bluetoo low energy so what enters the computation of this key is the key that we exchange that we derived during the elliptic curve def helmet then also the nones that we exchange and the device addresses from the physical level for Bluetooth low energy this is um iscm computation and for link key this is hm computation so now when we have this key we can just use it any time to connect again so what do we do again if we were not connected before then we need to again establish a connection of the physical layer um exchange our device addresses and so on and then we can go exactly to the session key establishment and this is to derive the encryption key so not the launter key of the link key will be used for encryption of the data because it will be just stored but the encryption key and this is the key that you will be using for one session and whenever you disconnect then you will drive the new one so what enters the computation here is the longterm key or the link key and the challenges that were derived um that were exchanged during the session key establishment okay I hope I'm not going too fast I'm not sure how people are familiar but in case you have some questions about like high level protocol description you can just shoot me with questions can I ask some questions sure to clarify make sure um so the so when you do this initial connection so basically this key confirmation uh so this link key is so this is a long-term key basically when I store that device um say I connect my laptop to my headphones basically I store this link key and if I erase the device from my list of Bluetooth devices then the linky is gone is there ever any reason to refresh this link key otherwise or is it just it's going to remain there for as long as I have the device stored so you might want to refresh it if it was compromised so if you know that maybe there was an adversary or know you know that it was leaked somehow that it's you got access to your device sometimes it also happens that you might get run into the error and your device is just not reconnecting so you try but they do not establish the connections then you need to forget the device again and hair from the scratch I see but from no okay and in terms of The Logical level uh and these capabilities basically uh I mean I don't know if you know this but so like what if I create my own Bluetooth device that does something that's never been done before right so this I don't know it uh it uh releases some food for my cat and and um uh I mean obviously I guess obviously like say some windows Bluetooth driver isn't familiar with this kind of capability right so can can I like somehow uh how can I just tell my Windows device for example that uh you you can somehow pair with this Bluetooth device that has this kind of capability or okay I see the question uh so in the course specification they Define only several capabilities that you can have such as uh you have only display you have only keyboard you have display and keyboard you have no display no keyboard um what else did I miss okay so they have like specified um entries here but they also have some strings reserved for the future use so for example if you send me I don't know beat stre with I don't know digits let's say number 10 then I don't know what is that and I'm going to just reject but it can be that on the application layer for example some uh manufacturer introduces something new for example I can have I don't know the hearing opportunity right because I can hear maybe the pass cre through my headphones so this way you can say I use this research for the first for the future use is the B1 and then I send it over and if the device also supports or if it's from the same manufacturer then it will recognize what it is but it's not specified in the core specification so it's might be specified by something else like I don't know specifications of the phones smartphones like anything of the devic it's not in the specification but yeah you can modify this and I guess some devices might do this but I'm speculating here okay it's definitely possible okay it seems we have more questions AA yeah he uh so the first thing is in the secure connection case that you showed I know it's a very high level protocol but are there multiple different protocols to establish this secure Channel like there are actually so there are Legacy protocols which just used I'm talking about Bluetooth classic now which does just used PIN and this one was not secure even against passive adversary so it was uh POS I to just Brute Force then as a solution to this came the secure simple parent protocol um so this one also has four variations depending on the input and output capabilities like numeric comparison py entry out of band communication and just works and then there is also secure connections which is based on the secure simple parent but just they use the bigger elliptic curve uh for this one kind of similar thing is happening in Bluetooth low energy but they they did not nice think with the nameing because they said that we have secure simple pairing but it's not secure even against um passive adversaries that's the problem uh but the idea is also kind of the same and the reason why it's not secur against the passive uh ADV is because there is no elliptic curve involved no elliptic curve def hel or any kind of T helmet and then they have also secure connections and this is exactly the copy of the secure Connections in Bluetooth classic so here I show exactly the secure connections for Bluetooth low energy off for Bluetooth classic but yeah there are like a huge variety of the protocols that you might use for pairing I see and this is uh not just the crypto LEL I guess the key confirmation also changes whether it's Pass key or pin is that true or exactly like everything changes there for example in Legacy it will be completely different in um so key confirmation would stay the same for secure simple pairing and secure connections uh but the non exchange will look a little bit different so in some cases they will first commit and then uh reveal the nonsense in some cases only one party will um commit and reveal the nonsense such things I see and the key conf so say the key confirmation always is manual in the sense you would expect the human user to import something or actually it happens a little bit before so during The nons Exchange they first the devices first commit the nons and then they reveal it and then based on this they might comput some digits and then display to the user and then the user checks and confirms it here and then they will run key information on top so you can think about key confirmation as they use the Mac key that is derived from the elri curve def key exchange then they include all the transcript that they had like what nons we um exchange what input output capabilities we exchange mod def addresses we exchange they took this whole bunch and they just comput the mac and they sent over so this is what the key confirmation is thanks sure so uh I have a question so I'm more of a systems guy not a security person but to run ecdh I think each other uses their uh public keys right uh is that so to is there a step where they verify the public key for example say when my laptop says this is the laptops public key do you go do they usually go through a kind of a certificate chain kind of thing to validate the public key or how is that done so unfortunately they do not do this check but it would be really nice if they did so what they just exchange here so they generate a pair of the secret and public key then the public key gets exchanged sometimes it's generated each time but the specification also allows to reuse it in up to eight connections if I'm not mistaken there is validation but it's not like the public validation it's more like okay are we on the same curve um do we still use like the valid curve or did you use some I don't know you put y coordinate to zero like such things or maybe you send my own key so they do some kind of small checks to prevent some of the attacks but they do not validate that it's really coming from this device or that device okay yeah that's what I see one more question from Paul is there is um an opportunity for certificate exchange defined in this setup protocol huh yeah actually going ahead because this is what we did so in this term no in this initial connection or Rec connection no but you should be able to build it on top maybe not with this Keys maybe you need to generate new pair of keys also with the certified Authority but here yeah it's not possible here unfortunately yeah okay I don't see questions anymore all right so I'm not sure what exactly happened but um at some point there were really really really many attacks on Bluetooth and they were really really different so for example one of the attacks was on the um logical level where the parties negotiated what size of the key they want to use and it was possible to downgrade the key size up to one or seven um bytes which is really horrible um then there was attacks to downgrade what the protocol we want to use and this is the case because we do not authenticate this choice we just exchange okay this is what I can do this is what I would like to do and that's it so we even though we confirm it later there is no proper authentication in the cryptography sense then there were also some um attacks on one of the protocols or like well like more protocols in this stack and this is exactly the problem in case we have some attacks like method confusion attack where we exploit two protocols and we interwin with them then of course there were also attacks on Legacy which I mentioned when it was just possible to Brute Force the key there were also some attacks on the session key establishment mechanism but it was mostly on Legacy uh key establishment or on the Y Wess of the protocol um there is also something that I didn't mention so far but there is also a possibility to derive the key on a different type of Bluetooth on different transport so for example if we connected uh with some device on a Bluetooth classic um type it was possible to switch or like to derive a new key for Bluetooth low energy so this is what is called cross transfer key derivation but this mechanism was also found not to be secure it was possible to replace the keys or to derive the keys that are not really secure and so on um I will show some of the attacks I think I still have some time so I will show like my favorite attacks of Bluto so there was a blue mirror attack what is happening is we have two devices uh they commit the nonis and then they reveal it but if we have the address who just pretends to be the other device and this address just mirrors whatever it received then it was possible to do the authentication so these kind of checks should be done but as you can see like this attack was discovered in 2021 so there is still a huge fi of attacks in bluo another attack that I really really like is the method confusion attack so there we again have two devices and during The Logical level connection they negotiate what exactly they can do for example one says okay I can compare the digits or I can also enter them and the other device also answerers okay I can also do both but if we have the adversary in between then the adversary can modify this value and say oh actually I cannot do compare or enter I can do only one and the same happens with the other um with other connection so now what happens the devices will enter the different protocols so on the right side it will be um the numeric comparison and on the left side it will be pasy entry so what it does it mean from the cryptographic perspective it means that both connections will have different keys and the adders will be sharing the keys with the victims but from the user perspective and we have the user who just okay I see the digits and I just confirm them or I enter them it looks legit so from the user perspective it looks like okay the genuine connection because I confirm something or entered something but from the crypto perspective it was two completely different protocols it was completely different noes and hands completely different Keys would were DED during this connection okay questions here yes so what exactly do you mean by compareed digits so is it like you'll enter something like yes or like what exactly does it mean is compar US yeah this numeric comparison you have two um devices and both display the digit you as the user you need to compare if they're the same and then you press the button if they're the same so it will be yes or no button than and for enter it would be one device is displaying some digits and you enter it on the other device or it can also happen that you just come up with the digits yourself and you enter them on both devices yeah sure all right so another attack that I really really like is on pasy Entry so when we show the digits on one phone and or one device and enter the digits on the other one so we have the user who wants to connect a keyboard with the screen okay looks good so what happens is some digs are displayed on the screen I hope it's not 1 2 3 four five six because it's kind of easy and then they us it need to input the same digits on the keyboard but what is happening at the same time is that tag so the advisary connects fake screen to the keyboard for example using some notse secure commun communication protocol like I don't know just works or Legacy protocols or maybe the advisory had like physical access to the device but now the whatever the user um inputs on this keyboard the addressor will see on the screen so this way the addor can learn exactly the pass key that was uh used by the by the user and use this Pass Key to connect its own fake keyboard to the screen and here we will have exactly proper connection like proper in the sense like authentication um in Bluetooth um sorry so here we will have um what Bluetooth Square specification calls authenticated connection but the thing is that in both these connections the add will compute their own um link key or lunam key with the user and from the user perspective it again looks like okay nothing happens because I compared the digits or I entered them so it looks really legit okay uh other questions on this attack all right so these attacks that I presented and some more they are publicly known and they reported on the website of Bluetooth special interest group what they also do there they release a security notice so they tell what the manufacturers or the the developers of maybe Bluetooth chips should do in order to mitigate this attack or at least like reduce the consequences of this attacks the thing is that um such mitigations are a little bit problematic in the sense that you usually if we consider Bluetooth as a whole ecosystem or like whole system we try to fix some part of Bluetooth like maybe we fix one attack or the other one but it's still vulnerable like in a hall um so these patches are not a deal but also if we look in how to fix uh bluo protocol step we also need to acknowledge that we need some Universal fix like a unicorn that will just fix everything on the whole protocol stack and against all the attacks because if we just patch everything this is going to be not so nice maybe we enter maybe we even introduce some more vulnerabilities the other problem is that we want to have it Backward Compatible um there are pacemakers for example that use Bluetooth and of course you do not want to make a surgery in order to change the hardware or anything or maybe less dramatic example is we do not want to get a new phone each time there is something change in the protocol stack on the really low level physical layer or um Network layer so it means that we cannot change the protocol itself when we think about um the mitigations for this attacks and it also a little bit limits us that the devices do not store the transcript that they exchange so when we run this initial connection the devices only remember the address of the device of the partner or the keys maybe some other keys that were derived and that's it so we do not store all the information that was exchanged sometimes not even the input and output capabilities or other capabilities and this also makes the the fix very challenging so before I present the the Fig we need to think about what is wrong with the parent procedure from the cryptographic point of view so if you remember the picture that I showed with the distribution of the attacks they were mostly on the initial connections there was some also for the rec connections but it was mostly like against Legacy so what we did in the Asia group paper um we analyzed blutu protocol as just on first used model and this means that we allowed the advisory to be passively secure to be passive in the initial connection so the industry can still if stop the communication can connect with some other devices but we do not even aim to to protect this devices but during the reconnections when the devices already established the long-term key and the link key The Advisory can do whatever it can drop the messages can modify them reveal some session keys and this way we could achieve the security for Bluetooth the probable security um questions so far here all right so now the natural question is okay how can we do a little bit better than TR on first use so that how we can make Bluetooth secure also against active attacks during the initial connection so one natural candid that is okay we can just use out of band communication we can use I don't know QR codes or NFC and so on the problem with this solution is that it requires some physical um capabilities from the devices for example in order to uh exchange the NC messages you need to have the NC uh receiver and the sender and this is not the case for all the devices another possibility to fix this is what signal and WhatsApp for example are doing so the user will be shown with some maybe C code to scan or some digits to compare and verify and this way we can have also reassurance that okay the key that is derived is secure or it was derived during the honest execution again the problem here is that you need to have a screen to show such things um and also not all the devices for example support the QR code again another opportunity is to use the pre shared key for example in TLS research mode but the problem is that uh we still need to somehow distribute this PR shared key and in TLS for example what they do they first establish the connection in a like an regular execution and only then they can use psk to authenticate further so this would correspond exactly to the setting of tofo that we analyzed in the Asia Creed paper all right so what we did in C CS paper is we thought okay we can actually run another protocol just like on top of blooth on the application layer so if you think about Bluetooth it takes all the layers from the physical layer to I don't know the association or presentation layer and then it has application on top and applications are up to the designers and developers to make so we can make such an authentication step on the application layer this is good because we can try to link L the derived launchtime keys to the authentication or link authentication to the derived keys that we had I see another question yes so I'm just curious so in when you talked about this QR code scanning kind of fixes if is it somewhat similar to when you did the confirmation in your high level protocol uh if you move that confirmation to the end of the protocol is it somewhat similar would that help in any way yeah so the key confirmation I guess you're talking about in the initial connection the problem is that that it's still it's exchanged during the connection within the Bluetooth band and because we want to protect exactly the Bluetooth uh Channel we cannot let the Addis to modify this key information and here you can see that it's out of Bend right we have the user who is entering the digits or comparing the Dig check in the QR code but isn't the key confirmation like not maybe exactly what you're calling key confirmation but there is a human authentication step involved and I'm wondering if you move that step in the authentic Bluetooth Authentication Protocol to be the last step would that help because I think the way you explained as I understood is that process happens after that there are some key exchanges that are happening so instead if you could move say the pin confirmation to the end of that step is it somewhat similar to doing an out of band QR code scanning would that help this is actually a really good question because I was also thinking about this because in pasy entry for example what you do you enter the digits first and then you exchange the nons and so on it's possible to like fruit force it in the future I was also asking this question myself but then we again have the same problem that not all the devices have this input and output capabilities so you will again have the problems that it might be downgraded so as a temporal fix I think it can be true but you're saying that if you just for example move um py entry to the later point or if I'm actually not sure if it's possible but I think we can also do the key confirmation because it happens at the end of the protocol we might try to make it also out of band but here I'm not sure how Bluetooth protocol stack interacts with the application like is it possible to show to the user this confirmation Mac as some I don't know user friendly stream or QR code or I don't know eny whatever I don't know if it's possible or not but it could be a solution yeah thanks yeah all right so coming back to the authentication step uh where we try to link the authentication to the keys that we dve during the initial connection so the good part about our solution is that it does not introduce any new functions so whatever is there in Bluetooth core specification already we just use it um another good think is that it can run at any point of time so you can for example pair then you can reconnect reconnect again and at some point you can run this authentication this is also good for low energy devices because it might happen that you did the initial parent for example and then you run out of battery and then you disc connected so you do not want to lose this connection when you reconnect and then you can do the authentication so you can just like postpone and defer this out the first use so our Solutions are based on the challenge response scheme which is not some rocket science but it works and we propos two types of the schemes so one is based on the Dy helmet and one is based on the signature so why does it exact L work so if we think about um initial connection when we go into the trust and the first use uh model then it means that whenever the execution was honest then all the consequential like all the following reconnections they will be also um secure like toos secure and if we run the the initial connection again if we pair again and it was a gen connection again then we can get the same guarantees that okay it was also the reconnection will be secure and the following reconnection but now with uh what we call Dophin so defer outside the first use whenever we run authentication we also make sure that the previous connections were secure up to the initial connection and if we run the authentication in the lower part of the spring then we will again guarantee that not only the following connections but also up to the IAL connection was Secure so there was no adversary who did something right so here I have the signature based authentication and it might get a little bit more technical but I hope you will bear with me um are there any points by now or questions or comments okay so we again look into the setting of two devices they already derived okay here I look at the classical version so I call the keys as link Keys um but for signatures we also need to have um some pair of the secret and public and also the certificate so what we have we ask the devices to generate some challenge which will be 128 bits long then the initiator sends each part of the challenge and the respond will compute the authentication data which consists of the challenge of both parties and um computed over the hmac using the link key that's be derived during the initial connection then the responder will sign this data using the secret key and send everything together so s the challenge that It produced generated then also the signature also the certificate and the publicy what the other party does it also computes the authentication data because now it has both challenges and it also verifies the certificate that it received and checks the signature if it's valid or not so this solution is it looks pretty simple but it works for Bluetooth and we actually managed to show um the CHF for Bluetooth classic at works and you can mitigate some of the attacks so before I go to the attack there questions on the scheme all right so you might remember this uh distribution of the tax slide from before so what we could we could mitigate some of the attacks like method confusion attack and so on on the downgrade of the protocol and we also could mitigate the consequences of the attacks on exact protocols so you can see for example we could not uh do anything against Legacy because it's not secure against um passive advisories so even if we have authentication the addor will know the key so there is no point in this authentication actually um we could not do anything with cross transfer key derivation because it uses is CMAC and this one is not Collegian resistant so we couldn't show a proof there but if it's replaced with hmac we believe that it should work then we could not do anything with Legacy the attacks on the Legacy in R connections but the same reasons yeah you just canot do anything with them but in an interesting from my perspective is the key negotiation attack so when we could reduce the size of the key um in Bluetooth Classic this communication happens during the reconnection and it's not authenticated so the devices first agree on this size and then they derive the encryption key of this size and that's it so we could not use our protocol to mitigate this attack potentially we could use this in bluto's slow energy because the communication negotiation of the key size happens during The Logical level communication um but the problem is that we couldn't show that du to slow energy is actually secure in our model for the same reason as the cross um transfer key derivation mechanism is not secure because it uses cm and this is not a collision resistant function so we couldn't get away from this um okay here we have some results so we compare it to two papers um that tried to mitigate some of that TX as you can see we do not um abstract all that tax only some of them uh but yeah you can see the pardon that it's again Legacy or the reconnections or the negotiation mechanism or the cross trans um so now I have contribution are there any questions maybe so far otherwise I will go to contribution okay so what we did we proposed this cryptographic method um and not user based to abstract some of the attacks uh we proposed four options so two for each Bluto classic and two for Bluetooth low energy we extended the model that we had before the T model and now it also contains the defer outside first use authentication um we managed to show that Bluto classic is secure in this new model but we failed with Bluto s energy so this actually concludes my presentation because I really tried to make it a high level but if you have some more questions left I will be happy to answer them I think we still have some time and let me just end on the contribution slide well thank you thank you very interesting actually um there were already plenty of good questions I see some more really good questions yeah Paul please go ahead uh so you say you failed to prove BL is but you still think it will work it's just you have not yet completed the proof what's your say a few more is there um so the problem is that we couldn't show that the the longterm keys in blut slow energy they Achi key secrecy with our authentication and the reason is that the long-term keys are derived using ISC mag algorithm and not hmac and ismac is not Collision resistant so it might happened that two completely independent executions they derive the same long-term key and the adversary can run the protocol between these two executions the Authentication Protocol and they will authenticate each other because the key is the same but they were not partner it before so from cryptographic point of view they will have diff different transcript so they should not be partnered but it works uh as an attack so it could be proved also um secure if we use c h ma for example but there is no this option in to slow energy so they only have ISAC and they have is and that's it so they do not have any other algorithms so does this mean you're worried that you that this your Technique will not mitigate these things or you're not worried but you just can't prove it h word is an interesting word so we can prove this only if another algorithm is used let's put it this way so we are sure that we are most certainly sure that the proof will work if just another algorithm will be used which is Collision resistant not necessarily H mag but just some other algorithm that is Collision resistant maybe it's even ISC mag but just like some version of CAC that is Collision secure I think there are some modifications but yeah thank you I hope this answer is so I have one more question so so do you do you know if there's an attack that Ed this Collision did it translate to a real attack or not yeah I actually do not have a backup slide for this but yeah it was an attack um unfortunately I do not remember the authors but let me check maybe I can do some check here because I have the slide with the taex um so it was already okay so um there were actually two attacks that exploited this one was on mesh protocol that I said I will not be talking today and another was uh on Bluetooth low energy um and here on this slide you can see like the last meable commitment in Bluetooth so the idea is um the following that you commit so also the commitment is computed using this ISC mag so two devices commit the commitment they exchange the commitments that were um computed using the iscm and the adory can find such a not that fits exactly this ISC so in this sense I think it's not one way secure if I'm not mistaken how it's called um and it the advisory might exploit this by making the device accept even though it was used with the another nons I'm not sure if I can explain it well with my hands because I didn't have a slide so it will be two again in one the device will commit the adversary will try to find such a no that will open to such uh that will feed the same commit so that the non that opens on the other side it really feeds this so you think the adversary can insert something in the middle basically so yeah exactly right yeah okay thanks can you hear me I can yeah course I'm not sure about others okay cool I just maybe when question about the like modeling like how did you have to come up with new definitions for these things are there existing definitions like and how much of it did you did you model like do you model all the stages or just one more so now I'm really sad that I didn't include more technical part because people are actually asking about this um so let me maybe open this slide so from this slide you can see what definitions we had and there pretty I would say used in the literature so for example m security is um ensuring that we have the same I'm sure how technical I can go but it can ensure that if the parties have the same session identify or the same transcript then they will also dve the same key the session key and that there do not exist more than three such sessions that have the same session identifier this is for example the m security this accuracy would be that that we canot distinguish between a real key that is given in a test Oracle and some just random string you know that is given authentication is just okay we agree on each other identity it's also pretty straightforward um we had leakage resistance and I think we also change the name for a bit so that it does not sound like side Channel attack so with this uh definition what we wanted to have is that if we run this authentication process protol that uses link key or longterm key we do not reveal any information about this key so even if adversary I don't know if drops this conversation it will not learn anything about the key so yeah these are the Notions so I would say three of them are pretty much used in the literature and one at least we didn't find this but in case you know this one you can also point to me so these are like key standard key exchange definition question is does it match up with that you don't have to do anything different because it's a has this out of because you do sort of have some kind of out of band human or you know comparing the digits or something like that in the in the middle there somewhere right or does that not do you not have to capture that part yeah we do not capture this there was some models that tried to capture this um for example from trosa and uh hail they Tred to model the interaction between the devices and the user but no we do not do this we just do not take unfortunately the user into account so do you H do you not need to does that not because it seems like that's sort of something you need as part of the protocol how do you uh do you somehow start after that step or like yeah how does that work so we just assume that the information that is exchanged through the user is just exchange out of band so if we have the pass key for example that the user reads on one screen and tries to input on the other screen we just say we inherit this from some out of band Channel see and this channel is secure and the adory can cannot even drop on this thanks so yeah I'm not sure if there are any more questions yeah no more questions okay well um let thank Olga again very nice very nice very interesting talk and uh look forward to to we can discuss more of these technical details in our uh uh follow-up discussion which I'll set up oh definitely then it would be with different slides in case I need to prepare some oh so that we can really discuss the modeling sounds good all right thank you everyone thanks for joining thanks hga thank you bye-bye thanks by