Keeping Electric Vehicles Secure: The Need For A CAN Security Framework

[Applause] thank you everyone so good morgan so my name is srivadanjani and i'm gonna be talking about my experience uh on keeping electric vehicles secure by proposing the need for a canned security framework so a little bit about me so i s um the nc is already mentioned i am a security engineer with disass singapore and we have a global presence and there is also a division right there in germany uh we specialize in smart cabins and smart driving including self-driving capabilities and we have over 35 years in the automotive industry so before working in the csv i had a short stint at national university of singapore where i got the chance to hack into one of these famous yellow

bluetooth bikes that you see in the picture right there and i was able to hack into them and was able to ride it without having to pay for it as a part of their bug bounty program that got me super excited about vehicle security and then i transitioned from bikes to cars which is my current focus i also have a masters in information security from carnegie mellon university and for fun i play a musical instrument sometimes and every weekend you can see me paddling along the kalong river in singapore so today i'm going to be starting with an introduction of what is can and the security challenges that come along with it then i'm going to be walking you through

my journey of developing an intuition detection system over the years through different phases and what are the lessons i've learned along the way and finally i will be proposing a canned security framework that addresses some of the uh problems that i've encountered so far so let's start with can so what is scan can or controller area network is the main communication channel inside an electric vehicle or the crux of an automotive system so it connects all the import important components that you can think of like cruise control brake system air conditioning gateway you name it so everything is connected through this can bus and these components are called as electronic control units and chan can is the

channel that connects them and enables the communication between them so the main benefits of using this protocol is that it's inexpensive it's durable it's very lightweight and reliable and it's also broadcast based unlike peer-to-peer based which means that it does much less overhead and uh that's primarily one of the reasons that electric vehicles use can as one of their major communication channels so a little bit of a deep dive into a can header or a cam frame so you can see a number of fields there but there are three key fields that i would like to highlight one is the arbitration id the other one is dlc which is the data length code the data length code is basically gives

you the number of bytes of payload of data that follows along with it so here we have two eight bytes data so that would be the dlc which indicates how much of payload is sent along in that game frame and the time at which the frame was itself sent and the data itself so the key feed here is arbitration so let's start with that so in an electric car we have many electronic uh control units that want to talk to each other and they have the scan bus which is their communication channel so each um each electronic control unit has a specific set of message ids that is always on the lookout for and once it encounters

that message iv on can bus it uh reacts to it and starts a communication with it so since it's broadcast based and many of the electronic control units we try to do this simultaneously the can bus has a process called arbitration which gives priority to which message can be executed first so if you have a lower message id then you have higher priorities so by logic if you have zero zero zero which is the lowest you can go then your message would be given the highest priority and will be executed first on the canvas and every other message has to wait a bit more so this number is represented by the 11-bit arbitration ibs reference here

so a little bit more into the different type of can messages so we have two broad classifications one is called the periodic messages so the periodic messages are message sense periodically to get the statuses of different electronic control units at different times so uh i am an ecua and i want to talk to ecub and i want to know the current status at this particular point of time so i just sent messages periodically to know hey what's your current status so that kind of messages is periodic so and uh the second type of one which is called as event trigger is messages that only occur when a particular event happens so you someone locks the door someone

unlocks the door you apply brakes on the car these kind of events that are happening will trigger a bunch of messages that are only pertaining to that and those kind of messages are called as eventual messages so if you see the screenshot here this is from a can database file you can see two words that's that comes up very often one is cyclic x and the other one is spontanex so anything that's called a cyclic refers to the periodic messages and anything that's called spontaneous which is much much fewer than the cyclic x messages refers to the event triggered messages and you might be wondering looking at the screenshot what is this x and why is

there a can extended written at the end of it what's the significance of it so um the x refers to an extension or an extender and it's called as scan flexible data rate which allows you to send up to 65 64 bytes of data and has a longer identifier it basically allows you to send more data in a single cam frame as opposed to the original classic can so what does this mean from a security perspective so historically when can was introduced by robert wash in 1983 it was only meant to be like a very lightweight reliable mode of communication and there is no authentication or authorization that is built into the protocol itself so in order to ensure security you have

to take additional mechanisms so one such mechanism is building a model a component that would do the authentication or authorization for you so um coming to that you have one such examples of of the model is an auto source sequocy or secure onward communications so basically what this module does is as referenced by the figure it generates a lot of message authentication code and freshness value which is used to authenticate the electronic control units communicating on the canvas and send this keys plus data in the can frame along which which allows you to send more data so if you're using a classic can sending this type of information would mean that um it will not leave you space for

anything else and it's not your best bet but can fd can allow you to send your security related data as well as the data it's originally intended for so but there are two challenges that come along with this one main important one is that you have to secure the keys itself they've got them and the next important challenge is that secrocy has 2.5 times more bandwidth than can itself so in certain situation which means that you cannot use this always because you would have to sacrifice your bandwidth for security and we don't want that do we so what other option do we have to ensure that there is security and the the can bus itself the communications is

secure so here comes intuition detection systems so many ideas solutions sit on different electronic control unit components and monitor the messages along the canvas so an example could be gateway which can look at messages coming in from different electronic control units um so there are broadly two very different type of with pertaining to can one is flow base which only needs the bare essentials the bare essentials meaning the message id and the time at which the uh frame is sent you don't need the data you don't need anything else so this kind of information this kind of flow based pds is useful um because it's very generic and you can use it almost in many almost in all the

vehicle models that you can think of because it's very generic it's not data specific it's not vehicle specific so once you develop an algorithm you don't have to go around changing it again and again uh whereas packet base is focuses completely on the data packets or payload itself so this is also useful in certain situations um so these are the two major types and hybrid is a mix of both of them so when i started to develop an intuition detection system i started with a prototype so my goal was to create a working prototype from data that is publicly available so i wanted to identify common attack scenarios and generate adapt scenarios pertaining to that

and along with my team we wanted to add some machine and deep learning features to this prototype and finally test the results on a pc to see how our ids algorithm has failed so far so um upon a lot of literature survey i came upon a very highly cited academic paper called otids which proposed a novel nutrition deduction system from the hcrl lab in korea so they had three common attack scenarios which is denial of service fuzzy and impersonation their data was publicly available which is kind of hard to find in uh automotive domain the algorithm itself was fairly easy to implement and so this seemed like a good reference point to start of my prototype

so i wanted to generate more such data so i used vector schenoe network box it's basically a simulation tool and used i used this and programmed more attached data sets based on the reference model that i have with me so some of the attack scenarios the first one is denial of service so as the name suggests the goal is to either jam the canvas or try to get the highest priority on the canvas so the way to do this is to inject messages that would that are the highest priority which in case would be zero zero zero which is the lowest you can go you just try to just like spam it in a very short period of time so either you

get the highest priority or the canvas becomes invalid either of this uh becomes a denial of service attack the next one is fuzzy so it basically looks uh is a spoofing attack where it injects cools random plan id and data values so for example replay attacks is a common example of a fuzzy attack so and few other examples could be you have the right payload and data but you send them in wrong timings so you have a time that is expected in a normal scenario but then you just send it along in a in a uh different timing and another one is you have the wrong data but then you send it in the exact sequences that is expected

in a normal scenario so these are all examples of very fuzzy attack so the data format that was followed in this model was a request response model where the request was identified with a data length code of zero and the response had a data length code of either four or h and it had the same id so we can recognize that it's a response and came along with the payload after that so the data was collected from a kia soul vehicle and uh for the fuzzy attack the authors had two responses and they randomized one of it as original and the other responses attack so i graphed the packets as they arrive if you can

look at the figure here and so anything any packet any response that arrives after the seventh message is considered as a loss packet so we've only considered that particular window as a legitimate ones and from the figure in an attack free state uh most of the packets even if they arrive made they arrive they arrived at a pretty good uh uh time interval it didn't take too long for time to uh get the response to your eyes but if you look at denial of service and fuzzing when i grasped the arrival time you can see that they significantly increased in both these scenarios so here you see zero zero zero zero zero zero which means an attack is happening

and the response came much much later and in fuzzing as i mentioned there's two responses and they randomly chose this to be the legitimate one so uh as usual you can just look at the graphs you can just see oh there is something happening there is an attack that's got happening here you know it does not look normal or it does not look like it's in an attack free state so that's a very good indicator so uh with the help of my team we added more machine and deep learning features to this model and tested it and it came from 85 to 94 on the pc which looked good right the numbers looked good but then i realized one

thing they didn't mean anything when i requested data from the original equipment manufacturers i realized that most can data they do not follow the message request format at all and instead follow the sequencing format so which means what i had implemented was a corner case scenario and not the norm so one of the biggest takeaways that i got was to never trust the research scope blindly even if it was highly uh silent research so it was back to the drawing board so this time i wanted to create a proof of concept and i was very careful to model the attack data based on real industry data and instead of testing it on uh pc i tested it on ip03 which is

disastrous ecu so this ecu is mainly used for autonomous vehicle capabilities so the attack scenarios were uh similar to the prototype ones the denial of service and for uh fussing uh i also included the categories of can messages in account so for fuzzing i sent packets that model the original one but it's injected in a timing that is different from what is expected in a normal scenario and it applies to both the periodic and eventual messages but for frequency it's essentially the same as buzzing but it only applies to periodic messages and not even triggered messages i also added an additional attack scenario which is any id which is not recognized by the original equipment

manufacturer is also considered as an attack packet so i labeled that as alien id so this was the model for the grip of concept so i would have the normal data set and there would be a pre-processing algorithm that would uh understand the um how it behaves in a normal scenario so once i knew that we generated attack datasets using the canoeing vector box and fed it into the ipu this is the ip03 so there were two detectors which are part of the intuition detection system the first one is a logistic detector or a statistic based algorithm which takes really less resources and weeds out common attack scenarios like denial of service and alien id

the next one was a learning based detector which used a deep learning based algorithm to filter out the fuzzy and frequency eventually it would just give out if it's zero which is the normal or one which is an attack um the results looked something like this for these statistic based ones so for the alien id it's anywhere from a 98 to 100 which is really really good and for the denial of service it was either 82 to 83 which seems really good and it's very comparable to the industry standard so if you combine both of them the accuracy goes a little bit up to closer to 91 so this seems pretty good and in line

with what i had wanted for the uh deep learning algorithms it ranged from 85 to 98 and this screenshot here is from ip03 once the deep learning algorithm is executed so it just says that the accuracy is 100 here for that particular data set and it just gives you some statistic of the messages that are being processed so what were the challenges that i encountered during this this phase of um [Music] concept so the first one was me to fit the statistic-based algorithm into the mcu since it takes up very less resources and to read up the common attacks like dos and alien but then i found out that there was no straightforward way to get the id and

timestamp in ip03 because of the way that it was designed and i needed to like make some changes in in on a deeper level in order to be able to do that so um and second challenge which you might all have guessed is that we need to make sure that the incision detection system is not the sole focus of the ac itself so it should not take up a lot of the resources be it if you put it on system a moonship or if you put it on mcu it has to take much it has to perform uh very well and take up very little resources as possible so uh these the proof of concept was a fairly

good success but that it this brought me to a very important question and the question was i use data sets which are simulated and the ids algorithms did really well on them so it's great but that does not equal to a real car so if you actually deploy this ids algorithms in a real car would it still work the same way as it is intended to because in a real car you can have like some latency some delay some legitimate packets can come later than they are expected to and what happens to the ideas algorithms then would it would it still perform uh as it's supposed to or would it give you a lot of false positives and false

negatives which you want to avoid so in order to answer the question i propose the scan security framework so i wanted to test i wanted to set up a can test build which can be used to run a canvas in a realistic environment and then develop a pentas tool which can inject uh messages into the cam so this is basically a this would be like an attack toolbox that injects messages into the clan test bed in a live environment so one of the main outputs that you can get from here is a very realistic attack data set that can be fed into the ids algorithms you can see how the algorithm is fair you can make modifications if it's not

up to expectations and then you can again feed it over here so it's like a continuous loop for improvement of security so uh an example just a very uh example of a can test but set up is i have a wired can harness setup with a lot of nodes and then you know some of which is uh uses arduino and simulates different uh components in a car like a jaw engine hvac and then there are some nodes which have the much advanced ecu's from disa like ip03 so and some nodes which are left open so we can add more issues later on may want to continue testing and this this connects to a usb cam interface and

and then connects to a pc which runs the software message induction toolbox or the panties toolbox which um performs the attacks needed for intuition detecting systems so uh you can also have other related components for the ecu's to work like sensors or actuators another platform environments to make this run smoothly and uh so the pentax toolbox itself would uh start off with emulating denial of service attacks uh fuzzy replay or management attacks then frequency attacks by manipulating chaoticity and to be primarily developed in python so uh with this i'm going to go to the end of representation so here are some of the key takeaways that i want to share with you one is that if you have a highly cited

research it doesn't always mean that it's useful in the industry so always model a system based on real data and my opinion is that hybrid ids is the best bet moving forward uh this uh flowchart here represents a model for my proof of concept which took up very less resources so i had a statistic based algorithm which weeds out most of the attacks and uh deep learning one which uh we did out the advanced one so if you want if uh companies want to do something more specific for payload it can be just added to this model over here without compromising on the resources which means that it would be a really good solution in my opinion

and finally i do not consider my prototype to be a total failure because i got a chance to be here and tell you what not to do so with that i would be ending my talk and i'm open to questions now from the audience [Applause] all right folks so it is question time does anyone have any questions for oh we have a questionnaire come up please i have a question related to your ids model and related to your oem data that you received so isn't it like that you probably have to train a model for each different type of car model because the data will always look different maybe even inside the same oem model line

uh okay yes so uh basically if you use the flow based ids which is what i do the ids would be different for each uh each vehicle model because each oem have different ids and different way of processing them but the logic itself would be same but you have to as you're right you have to be training for every a single model uh depending upon their their own um ids and specifications but the core algorithms would uh remain the same if you use of your waste model okay thanks and question two if you don't mind um in the very beginning you were talking about using message authentication codes for protecting con bus messages how do you actually distribute the

symmetric key for that how do you what how do you distribute the key that is used for the hmac for the microphone it's distributed along the um the extended cam frame so it is send along with the frames when you do the checking you would actually check if it's it works or not on the receiver's end so it's sent along it's distributed along the cam frame itself so how do you secure those messages with the key uh so um let me just go back to this slide

okay so you have a sender and receiver side so you basically have a you generate a mac and then you have on a receiver side you would uh verify the key that is being sent so i think like you would send this on a can fd and you would like based on the uh agreement before you would just verify and if it's if it's not okay then you know that someone has tampered with a message and if it's okay then uh you would proceed with the uh the other other functionalities right but where do we get a secret key form oh okay so uh i think this is uh i'm not really sure but i think this is

randomly generated this is something i do not completely know yet okay thank you all right are there any other questions today so then um with that we're going to close this session thank you so much for being here shivaranjani and um have a great day thank you [Applause] you