 Okay, no one. So this is Nissan Leaf and Nissan Leaf is a smart and electric car and like any other smart car it has an app and through the app you can control various features of the car like a setting of your air-conditioned appardo So far the story is pretty boring, but here come the cool twist and the cool twist related to this guy And I'm sure a lot of you recognize him. How many I recognize this guy? Okay, I expect it to be more people, but this is my hand. So there's a few of us familiar with him Really glad to check him out. Security is such an owner of a lot of cool tools And one of the things he's doing is a workshop called Hacking Selfies And in this workshop we teach people basic hacking skills And one of the time we did this workshop one of the participants in the workshop own Nissan Leaf So after the workshop this participant go home and try the things he learned at the workshop on the app for Nissan Leaf and What he found out was that all the requests from the app were totally anonymous without any authentication Meaning in order to perform a request the app is doing all you have to know is the Publicly available data like the car ID, the VIN and you could execute any request the app is doing You can read the full story on Tri-Hunt blog just Google Tri-Hunt Nissan Leaf But basically it means that if the app is able to change the air-conditioned portal You can also do that to any Nissan Leaf car in the world just by knowing its VIN Which is pretty cool when you think about it By the way, don't worry. It's an old story. So I pretty much hope they already fix it But anyway, I'm pretty sure your reaction to this story is something like that Who know how they did such an epic failure and it's not something you do by mistake and I also think that way. I'm also a developer. I'm writing calls for the last 10 years But I want to offer a bit different view on the story and I want to show some compassion to the Nissan Leaf developers and I want to tell you our story at Zaloto what we did with and to explain what I am thinking So as I said, I'm working at Zaloto and at Zaloto we are trying to help people with their technology Me and I'm sure each one of you had a lot of smart devices at your home like Smart cameras, smart TV, laptop, smart printers, mobiles, whatever you name it And you don't always know what to get the most out of it For example, how I can connect my phone to my printer and print from it So we have to try to help people with that and the main thing we are doing to achieve that is with an app And one of the things you can do from the app is content an expert In fast and convenient way and the expert can guide you on how to do side stuff. For example, how to set up your printer So if we'll get back in time early 2015 we started to work on the app and One of the things we asked ourselves was how we are going to authenticate the request from the app after all I don't need to convince you that Authentication is important, but we won't really show how And you're probably thinking why do you have any questions, right? Authentication is simple. Just add social again and that's it. You have authentication. It's not really complex But we didn't want to do that And the reason we didn't want to do that was Because it's a fake user experience. If you add social again to the onboarding flow what the user had to do When you download the app on the store and before we can use the app You can affect the number of users who actually start to use that and we didn't want to affect it We want to have as many users who actually download the app and start using it And you are not the only one who's saying it This is a quote from optimistic. We talked about 56% off now even if the numbers are a lot high from the Actual numbers if it's even if it's only 20% It's still a lot of users and we don't want to lose all those users just because we need authentication and As I said, maybe this was something that the guys of Nice and Leaf had in mind We don't really know what happened there, but maybe they expressed a similar issue and they did not know how to solve it Anyway, we decided we are going to challenge the assumption that Login is essential for mobile app and we are going to find a way to authenticate without authentication and We decided to go for it and I started to work on this project. It was pretty long project It was again two years ago and it took around half a year to find the solution build the backend Build the mobile client, but it's working. It's live in production. This is just a quick demonstration showing that it's actually work It's a graph show with the number of requests or authentication server But the reason I'm here telling you our story is because I think this story is not special to Stiletto I don't think we are the only one who faced this issue who wanted to have authentication without affecting the user experience And I want to share with you how we did it and hopefully it will be relevant to you And I also think that not only it's relevant to mobile It's even more relevant to Internet of Things, whether it is smart refrigerator or smart camera Those are cases that interactive login is not always trivial either because you don't have a UI or because it's real Why I have to enter my Twitter credentials or my Facebook credentials the actual that my smart refrigerator will be able to walk So this is the why and before I explain how and how I did it at Stiletto. I'm going to explain what I want to achieve So if in regular authentication, we are talking about Authenticating the user and then use the user details the user identifier or something that to perform authorization. I want to achieve something else I want to be able to Authenticating the app on the device the app running on the device by some app unique identifier and And then do authorization based on this identifier say this app installation is allowed to this that are allowed to perform this data We do lose some information here because I might be able to say okay This app belong to this user, but I will not be able to say who the user was actually performing the operation But this fit our needs a little and again, I believe this would be relevant to others too So what I'm going to talk about today So as I said we come up with a solution and this solution is based on three protocols Which is open ID digital signature and one time password So I explained each one of those protocol in a very very high level and because of the time limitation and how I use those protocol to implement our solution I stop for questions after each one So in case you did not understand something feel free to come and ask. It's really important to understand the full solution And then I'll do a quick demo. Hopefully it will work and then I discuss two edge cases that Our solution is able to handle So this is the plan and let's start So as I said I started to work on this project Two years ago and when I started to think about how we can do authentication and what exists out there Open they look like a pretty trivial option for this Open ID is a simple identity layer basically a support the code that described how you can perform authentication and She will use our identity and stuff like that and it's not pretty much fit to what we need And the authentication open D is done using some token some strings that you can press and by this you're doing Authentication we will see it in a minute when I explain open ID But the reason I wanted to use open ID is because open ID is widely support meaning No matter what stack we will use in our back end. It's probably has some support for open ID so we have to write a lot of a lot less code and Also, it's widely support. So it's already butter proven. It's already secure and stuff like that. It's pretty important and Also open ID is highly modular and I explained what I mean by highly modular after I explained how open they work so How open ID work and I do now really quick overview of open ID if you're not familiar with it There is a full 40 minute session after later today about open ID So your mother invited to check it out. Open ID is really cool protocol But anyway open ID to talk about three participants or three players and the most important one is the authorization server The position server is the one defined strictly by the protocol or the question response to the server defined in the protocol And here's the one who actually hand during the authentication Except on the transition server We have our server which is the application server during our logic handling our data and we have the device Which running our app or our web app or something like that Now let's say we want to authenticate the user. So the mobile app Initiate an authentication request to the transition server. This is the step when the user actually does the login Enter his Facebook address something that and if this authentication succeed the user will receive a token This token will return to our app and the app can use this token again this string to authenticate the request with the authorization Hello, so if the app can send it to our server And the server can does some sort of validation with our authorization server to make sure this token is valid and If the token is valid it can perform the request return data or something like that So this is basically in a very very high level how open they work and It's super to fit what we need so I started to look how we can do authentication in open ID and Basically the protocols are defined how you can do authentication in an open ID but each one of the available method did not fit our needs because Either it required interactive login, which we don't want or it required us to store the hard-coded credentials on the application code And we also don't want that because anyone with the app code has the credentials, so it's not secure at all So at that point understood that We need a new authentication flow If you will be able to perform this little component to change this little component We'll be able to enjoy the full benefits of open ID and that's what why I say it's highly modular You need to change small components and you have you can use a regular open ID in all our other place Which is pretty cool So what I combined went we will have for such an authentication solution We started to think about what we want from this solution and the first one which is the most trivial is It has to be strong. We don't want something that is easy to break The second one as we already said I want to have a way to uniquely identify the device So I will I will be able to perform authorization based on this device identify or something like that. I Also wanted to be simple because simple means less bugs less vulnerabilities is to implement stuff like that I wanted to be I wanted the authentication request will be unique per quest Meaning if an attacker were able to capture one authentication request and send it again It will not work what called replay attack and The last one which is also very important. I want to have I wanted to be for tolerant I want that our client will be able to recover from a loss and not really just be Hang there without being able to authenticate after experience a loss because a loss are expected Any questions about open ID something not clear Okay, so we have an ID and Now we need to find out how we are going to perform the authentication and the next thing that the default checking out is digital signature And before I explain how we wanted to use the signature I do expect a quick high-level over ticketed signature and I'm going to expect a signature using Bob the builder because I have to re-order time So this is pretty much what I'm dealing with right now To those of you are not familiar Bob the builder Pretty shame on you go see an episode, but anyway, this is Bob and Bob has a crew of people helping it So this is Leo Leo is one of Bob's girl And let's say that Leo want to send a message to Bob and Bob want to know that this message Come from Leo and not from someone else impersonating Leo Pretty trivial cryptographic security problem. Anyway, what Leo can does is the following. Leo can generate something called Private key and from this private key generate something called public key private is red public is green Now Leo can give to Bob the public key He needed to do that in a secure way So Bob will you know for sure this is Leo's public key and he need to save the private key safely so no one else will have access to it Now when Leo want to send a message to Bob and he can take the message and You think he's private key. He can sign this message The result of this sign process is the original message which sounds in cold signature So this is not encryption that he sent a message to Bob clear text if someone creates it He can read the message, but it has something in addition which is this signature When Bob received the message and the signature he can verify it with Leo's public key and if the verification with this public key succeed He can know that this message come from Leo and not from someone else impersonating Leo Why? Because the verification will succeed only and only if the message was signed with Leo's private key because there is a Relationship between the public and the private key Now if only Leo's has the private key and no one else has it He was the only one who were able to sign it. So only Leo were able to send this message So this is very very high level Over with digital signature, which is also a pretty cool idea and I'm sure a few of you already thinking how that's familiar. There is a pretty popular protocol Based on digital signature, how many of you can think on a popular protocol based on digital signature? Yes, so he has a HTTPS so most correct SSL TLS in a very high level is based on a digital signature and As there is a very popular library called open SSL, which is implementation of TLSSR and the reason this is important is it means that We can assume that any device in the world probably support HTTPS So we already have implementation for digital signature. We don't need to write digital signature our own Which is pretty cool when thinking about simplicity. Let's call we need to write more Good things you want to happen So this is a why digital signature going to be good for us, but how we can use digital signature So let's say we have the device in the authorization server and Before the device will be able to request a token He need to perform a small step of registration like in the first time is on the apple son had it So the device that you're before can generate the private and the public key and Send the public key to the server with the device identify again this number, which is uniquely per device The server can store the public key in his database some key value store something that and Then when the device want to authenticate again like here before It can use the private key to sign something some message and doesn't really matter what now and send this Signed message to the authorization server with its identifier The server can fetch the matching public key to this identifier from the database and verify the signature And if the signature is verified if the signature match to this public key He can now that again like more before this message come from this device again Not from someone else impersonating him because the device keep this public key secret and return a token to the device So we can see that from our initial list of requirements. We're ready for field strong authentication solution because digital signature is a pretty strong protocol We have uniquely unique way to identify the device because of the poverty only the device has this public key and no one else has it And we have something that is simple again began because of TLS SSL So now we need to think about what we are going to sign And we need to make sure that this thing we are going to sign will be a unique per request and for time and for explain what was our next idea any questions about the signature You don't need a C.I. here, but I can talk about later. She won't come to me and explain to you why He can anyone can register but we have a way to uniquely identify a device Oh, so he asked if if that doesn't mean that anyone can register So yes, anyone will be able to register, but he will we have we are doing authorization So he will be able to does a quest only for his device and not for someone else So he asked if the registration is no So, yes I'm not Anyone can register. It's a different problem, but it's not a problem. It is interesting here because Also if you can register, but you will only be able to request a token for your device identified or not be able to request that are belong to other devices So you ask if the signature going to be different if the message is the same, right? so There is a it's like kind of you can say it's like having a very high level So no if the message is the same the signature will be the same So you ask why it is why it's a protecting from for tolerant from replay attack and I explain why when I when I talk about what we are going to sign we need to find what we are going to sign and make sure It's a protect us from replay attack and One last question and then I continue Let's keep this discussion after the question because it's pretty complex one. It's another different Big big problem. So come and let and we talk about it Okay, so to continue your questions how we can make sure That if someone capture this signature will not be able to authenticate so This time what we checked the idea the next step or the words look pretty fit is one time password One time password is a protocol or set of protocols describing how you can generate Unique password on each request, which is pretty much what we want right away to create a new password each time Which our server is able to validate So we might be able to use that as the message we are signing now one time password has two main popular implementation Which is time based and counter based and the time base is the most simple one Basically, you are taking the core and time step on your client Sign it with some signing algorithm and send it to your server The server can validate the signal signature and then he can check that the time in summer is in some allowed by lunch For example, plus minus one minutes, but it really doesn't matter what this range is So it's pretty simple and that's why it's also used Usually in a MFA solution the Google Authenticator The counter based is a bit more complex You start with some random seed let's say seven, but it really doesn't matter which number it is and After each request both the client and the server increasing it. So it will be seven seven eight eight nine nine and Like we tell him I saw here. We have allowed value range so if the client Send us sign the number two and the number on the server is ten You can see that ten minus two is bigger than the allowed value range Then five so the request will not be valid Anyway, those are the regular one-time password solutions But we didn't want to use it either one of them because they both have had similar issue Which is synchronization issue? Time is the Time is a complex because which little already know we have mobile devices out there with their time is not synchronized One day before regular time or something like that. So if your time is not synchronized, you cannot create one-time password based on time And counter is even more problematic because if the client experienced a few errors You will get out of things and you will not be able to authenticate So we want one-time password but We need to build a new one-time password protocol and let's see how I did it So as I said before we have the registration step and I said that the client generate the private key and Send the public key to the server Sorry, and so the number is also if the She asked what's the problem with the number based so If the client experienced a few errors, you will keep increasing the number and finally we will get out of sync It will not be able to authenticate So to return to this I said that You we can we can keep this discussion after I don't want to go get too much into it right now, but It's a bit more complex than that. Anyway So I said that the client generate the private and the public key send the public key to the server and He can also generate two random numbers to crypto on the numbers that I called them all the new You send them also to the server so in the end of registration the server has the public key and those two numbers and The client has the private key and those two numbers. I will refer to them as payload through the rest of the session now before the client can request a token he need the order snap those two numbers and The rolling is basically all get the value of new so all become two and You get new crypto on the value in this this case 42 Now the client can say sign this payload using the private key and send it to the server and The server can verify the signature with the public like I described before and if the signature is valid You can verify the payload. How we verify the payload He need to check that all the equal new the client or the equal to the server new in this case two equal two and If the equal the request is valid and the server update the payload in his database So the next request will succeed and he returned a token to the user And you can see that in addition to the three requirements way before We now it's something that is unique by request and I can say that it's also for tolerance We will see why when I discuss the edge cases Any questions about this session I Start so you ask why the server needed Or so you will see why when I discuss about edge cases, but the order new year Required for handling our cases. So we'll see why next So you ask if an attacker were able to intercept the first registration request and send another Public instead of the time quality. Yes, you will be able to block the world solution we You're right We are protecting this with certificate pinning and stuff like that, but it's not a perfect So I prefer to keep this discussion later because it will be a bit longer than just a quick response You're asking about scaling up because we need to stay to keep a lot of data The only thing I kept on the server or those two numbers you asked about keeping the state on the server So you're asking about how we are keeping the state So you're asking about scaling up and keeping the state Database for that and they are using the same database and I can share more about that. I said if you want to come talk with me Yes You asked why I'm letting the client just the next time us and not the server Because The client is not I didn't go to the desk And Yes, but I trust the client to generate all the other stuff And I want to plan to generate a private key because if he's not generated a public key I need to press the private key on the on the wire and I don't want to press the private key On the wire the private key never leave the device. So if I can trust him to generate the private key I think I can trust him to generate those numbers and it's also make things a bit more simpler and again, let's take this question of flying because We need to you know, have a bigger discussion Okay, so now let's go over to the demo Okay, so this is pretty much how the demo is built It's pretty much like open ID before We have the solution server the application server and the client The transition server is built in dotnet core using a library called identity server Identity server is a full open ID implementation Which is pretty cool because again, let's go we need to write only our code and not the full open disk back the application server is also in dotnet core because it was a bit easier for me and In the demo, it's basically API that you can request Sensitive data for me for any device in the world and he does authorizations So you will get sensitive data only if you request it for the authenticated device And we will see in the demo what I mean into it and we have the client which the client is written a lobby against simplicity and is running on Raspberry Pi, which is this thing a Small computer credit card size which is here to simulate another thing device So let's see the demo in action all the code available in Github. I put the link to the Github later Okay, so the demo is running It's running a bit slow because the Raspberry Pi Okay, good. So you can see that we have the device identifier the number that identified and we can now request Sensitive data for any device in the world. So let's ask that for our device. I think one four five eight seven And you will see that it's a ton the data for us Because this is our device if I now just put random number So you can see that I got an authorized This is real. This is a I this is how I show a demo that we can do authorization so the sensitive data the sensitive API is able to Authorize by the token this thing that placed in the position other and said if you are authorized or not to this device data And in question about it because I will not have time to go over the code How do you generate device? Okay, so we ask how I generate a device ID Excelator using great, but it doesn't really matter. You can do whatever work for you No, because of the authorization you saw that I tried to ask sensitive data for device ID 56 and it did not work and Because I explained counter and explain to you later and just don't have a lot of time for that and I want to keep with the rest of the demo and the rest of the slides So again, check out the level on github. It has the code and it's making it easier to understand it But the point was to show that I am able to perform authorization Anyway, let's go to the last part which is dealing with edge cases So the first case I want to hear to discuss is handling errors and we all know that network request can fail and because of timeout network failure or just server-side errors like database down and in those cases the client does not know what is the server state because Either the request did not get to the server and therefore the server did not update its database in state or the request did not get to the server and The request did get to the server and the server already update the state so the client doesn't know how to distinguish between those two states and I now go to show how our protocol ended each one of those and I start with the most simple one Let's say the clients and the authentication request to the server But from some reason did not get to the And this time of return and token the client will save an error so here the client just can retry the request and He will receive a valid token because because you can see that all the equal new Nothing to do here Let's talk about the more interesting solution case So the client now send a request and the request go to the server and request is valid because all the equal new but From some reason the client did not go to token. He got an error. That's very much away Now the client can retry over and over and over again Until at some point he will be able to send a request to the server Now you can see it related to the question of why we need the old that old does not Equal new hill to does not equal 42 But you can see that the world payload is equal or the equal old and new equal new So this is a special case the server expecting this case and he's assuming that what happened here is the client got out of sync So in this case the server just a tone HTTP status code 400 by request and the client is also expecting this Satisfied so on this status code the client just to work like it does on success request and if you're all You will be able to see that now all the equal new and the client will ever to recover from this error And we give it okay So this is how we handle all And you ask if this will be able to abuse for with the attack so If you send the same request again. Yes, it will be the same as this okay Because it will be the same state But you can see that it really does nothing on the server the server does not change his state here So it really does nothing here. We can do that It's only affect our low-timers kill the server any time and doors and stuff like that. It will not You are not a server token So let's go to the last stage s, which is more interesting. Oh, sorry So you're asking if you're not if I'm not using a password what happened if the device is stolen If you were able to store device, of course, you will be able and To access the data and yes, this is a problem with this whole solution. We're trying to do authentication without user interaction So you will be limited with what you can do and and it's pretty much something here And I'm sorry. I'm not taking more questions. I just want to get to a time for the last case because it's also pretty interesting and I want to talk about There is a pretty easy way to break this solution like what we started to ask about and And this is what happened if someone is able to access the device private team or compromising the device And if someone will be able to compromise the device It will be able to impersonate this device and send a question impersonating him so as this is a pretty Bet scenario and so I want our protocol will be able to handle it And to explain it. I want to introduce if If is the best hacker in the world or she need is like this hoodie put the hoodie on use like terminal with green letters I can any good movie and she can hack into any device in the world. It doesn't really need to be connected to the internet and Let's say that if we're able to compromise one of our devices and now we have Client server and if you can see that client and if both has the private key and both has the same state Now if if we request a token You can see that all the equal new and she will receive a token Now you can also see that if no protocol so you already want the payload What would happen if the client will request the token? So if the client will request the token now, you can see that it's the same as the error case before who will say for another bed status code because the payload is equal and You can go now and notice that if the server and the client each one has a bit different state So it means that now the client will be able to request a token because all the equal new But the next time if we request a token something different will be it will happen You can see that it's almost like the okay, so this got before but it's not the same because the new does not equal 78 That's not equal 93 So in this case the server respond with panic and you can assume that something bad happen and Instead of just returning better quest to the client and not exporting information you can also revoke this client totally so no one will be able to authenticate and Send someone out so someone will be able to go and check out what happened I saw four questions at the end because I don't have a lot of time So I'll stop for questions at the end because I don't want her. I don't have a lot of time So I want to complete the presentation dance up for questions So now we do a quick conclusion before the conclusion Reminding about the responsible disclosure. We really want to feel like about the solution This is why we are sharing it and we want to hear about potential issues But if you have some ideas come back with me Twitter whatever I will provide you the way to Responsible disclose such issues and again, we really want to hear them anyway, those are the requirements we started with and I hope you can see that the solution for feel all of them which mean We now have a way to uniquely authenticate the device and use the full open edicts another solution and And Maybe if the guys on this and if no water solution, maybe they use it Maybe it will help them anyway I do hope that you ask you're asking yourself how you can use it And if this is the case we are thinking about releasing the we are working about releasing part of the solution the back end and the client to open so so feel free to tweet me open issues on the demo on the demo get a page and Just to let us know that you want it what you need It will help us to provide The right open source and that's it. Thank you. And if there are questions, I get like four minutes for them questions and So you ask how the device gets the device at it and the device simply generate the device that you hear it's a little We're using a GUI, but you can use whatever you want Again, so yes, if you are going to write a script that will just go over all the ideas in the world and Send them to us. Yes, you will be able to dose us. That's why you are using good, which is Pretty hard not that hard, but pretty how to go over all the good in the world. But yes, and this is again a Issue related to how you authenticate the fierce registration quest because this is the only request. You cannot authenticate But yes, that's correct So you're asking what will happen if if it's the one with us to request Instead of the client and in this case the client will be the one who will trigger that up So I don't really care if evil the client trigger that I just want that one of them will do it Yeah, so I did not get you So you're asking how we are doing basically I see an access control, right? Yeah, so we can use open ID for that come to me later and I can expand you a bit how it and use open ID for that any more questions Okay, thank you. The next talk will begin with ten minutes over. Oh, there you are At 1115 we're gonna begin