 Good morning, everyone. Thank you for joining me this morning. My name is Tatiana Jamison. I'm a software architect with Jaguar Land Rover here in Portland. I'm part of the Open Software Technology Center. We work primarily on in-vehicle infotainment platforms, but we're also really interested in technologies connecting to IVI systems. And of course, right up the forefront of that is the connected car. Jaguar Land Rover, and I threw Jaguar Land Rover a member of the open source standards development organization, Geneva. How many of you have heard of Geneva? A handful. I'm not talking about the debugger. Some of you might hear that and think that sounds a lot like GDB. We are also part of a Linux Foundation project called Automotive Grade Linux. How many of you have heard of Automotive Grade Linux? All right, about the same. So as everyone knows, connected cars probably going to be vulnerable. They're connected to the network. Everything that's connected to a network can be vulnerable. I want to start out by saying, like any security talk, nothing in this talk is going to provide bulletproof security. Nothing can completely eliminate the possibility of any vulnerabilities or any exploits. Instead, what we're trying to do is mitigate security vulnerabilities by making the cost of exploiting those vulnerabilities higher than the rewards. Now, obviously at Jaguar Land Rover, we have a pretty high incentive. A lot of automotive manufacturers are concerned about security. But as a luxury automaker, I mean, who wouldn't want to steal a Jaguar if they could do it for a low enough cost, you know? On top of that, Jaguar and Land Rover provide the fleet vehicles for the royal families of England, Scotland, and Wales. So we have a lot of business motivation to be concerned about security. And just by showing up to this talk, you probably know everyone's talking about car hacking. Back in 2015, security researchers Charlie Miller and Chris Valasek identified a method for exploiting an unaltered Jeep Grand Cherokee. As a direct result of that exploit, 1.4 million Fiat Chrysler vehicles were recalled. They had to be recalled into dealerships or repair facilities because there were no facilities for over-the-air upgrades. When Miller and Valasek, how many of you are familiar with this exploit, first of all? Most of you. Have any of you read the white paper on this exploit? A couple. OK. When Miller and Valasek were doing their initial exploratory work, they had done a lot of work trying to find exploits on any unaltered passenger vehicle. They spent years and years doing this. They'd built on academic researchers' work. What they found was that there was a way to get a back door into a sprint cellular phone network and get access to any vehicles that were connected to the sprint cellular towers for data through that device that allowed them to connect to the sprint network. And once they had a telnet connection, an unsecured telnet connection to the vehicle, they were able to access a debus, which is the inter-process communication method that's used on the vehicle. When they did their initial scans, they were trying to find this particular vehicle that they were targeting. They found over 2,500 vehicles. They had to filter out the list of responses just to be able to find the vehicle that they were targeting so that when they cut the brakes on this particular vehicle with a reporter behind the wheel, they knew that they were doing it to this vehicle and not to some unsuspecting person's vehicle. They did a lot of control things through the debus before they actually cut the brakes by changing HVAC control, changing the radio station, all kinds of things. Tesla in 2016 was hit by a number of exploits. Tesla is a very juicy target for security researchers because it's so high profile. In early 2016, some security researchers identified that there was a possibility of an exploit by accessing a malicious wireless network on the in-car browser, but that particular exploit required physical access to the vehicle. In September, Chinese security researchers' keen security labs identified a possible exploit that did not require physical access to the vehicle. All it required was that the driver of the vehicle access a malicious Wi-Fi network. In November, Proman AS, a Norwegian security research group, announced another remote exploit. This was through a malicious Wi-Fi network that the driver connected to and downloaded a malicious app on their Android phone. This isn't a security exploit that's directly on the Tesla platform. This security exploit is entirely through the Android model and the Android security model. But nevertheless, it was an exploit that allowed the researchers to steal the owner's authentication credentials so that they could steal the car. They could track the car remotely. They could have control over the car. As many of you know, automotive software architecture is very, very complex. It's also made up by a lot of black boxes, a lot of proprietary black boxes. Some recent publications indicated that a typical luxury vehicle has about 100 million lines of code. That's more than the entire code base for Facebook and Windows Vista combined. And I'm sure we all have some thoughts about Windows Vista and CodeBloat. The internal network of a car has to control all of these features. An internal network is a mixed assurance system. That means that many, many, many of these features are safety-critical features, of course, the brakes, the transmission, all of the stuff that you would normally expect a car to do at its base are all safety-critical features. But then there are also pieces of software running in a car that maybe you might think aren't so safety-critical. A radio is probably not safety-critical, right? A CD player might not be safety-critical. And yet most of those systems do have some manner of communicating with other parts of the internal system network. And so there is an issue of access control. When you add the additional component of interacting with remote services and remote devices, then that infrastructure becomes even more complex. This is from Craig Smith's CarHackers Handbook. This is the 2014 publication, which is freely available. Craig Smith also published an updated version in 2016 following the FCA exploit. I definitely recommend reading both the Elmatics paper and Craig Smith's work, if this is a topic you're interested in, by the way. And of course, for every line that we have represented here, this is an example of something that crosses trust boundaries. If you're familiar with security in embedded systems, we already know that there's the trust boundary of kernel space versus user space. It's why we have user accounts versus root accounts and other privilege access, other access control in any sort of Linux system. When you have anything crossing a trust boundary, that is a potential attack surface. And there needs to be some plan for a mitigation in place. Geneva, as a standards development organization, is interested in identifying standards for automotive to adopt. And you don't need to be a Geneva member to adopt these standards. Anyone can adopt them pretty freely. The primary project that Geneva is sponsoring for this is called Remote Vehicle Interaction, or RBI. And RBI is a form of middleware for service-oriented architecture, which should be pretty familiar from many other applications in internet of things or system architecture. The vehicle may want to connect to a mobile device. It may want to connect to a driver's smartwatch, a passenger's smartwatch. It may also need to connect to a backend cloud. And that might be a billing service from the OEM. It might be somebody wants to stream Spotify in their car. The motivation behind RBI is that it is a small shim layer that abstracts whatever network protocol you might be running on your device. It adds some access control layers which are enforced through the JSON web token standards. So these are self-carried credentials. And when a connection is initiated, both endpoints on the connection send along their credentials to inform the other person, here's what I have access to. Everything is based on public key infrastructure. And it's all API-based. So here is a more detailed view of the architecture. So the vehicle will have its IVI platform. It will have some number of apps running on top of that IVI platform. That IVI platform will communicate with an RBI plugin, which is through a well-known standard of JSON. We can also use a message pack, in some cases, or BSON, if we need to compress the data. But we use JSON for proof of concept because it's a really well-known data format. The data router is also responsible for handling routing on the vehicle to other parts of the internal vehicle network, aside from the IVI platform. If there's the CAN bus, any ECU control, that might be available. The data router is available is the common piece among all parts of the architecture, whether that's the mobile device, smartwatch, a cloud device. And like I said before, it's a shim layer. The data router itself is the component that Genevieve has been developing for several years. We have been doing demos for it for at least two years that I know of. I started with Jaguar Land Rover in January of 2016. And we're currently on version 050 for RBI Core, which is our primary proof of concept implementation. It's based on Erlang. We also have SDKs available for iOS and Android development. And we've done demo applications, demos using RBI at least to Genevieve all members meetings for at least the last four, probably longer. We also, as of new as of last year, have a C library that is a limited implementation of the RBI architecture so that if you would like to have this behavior on an embedded device, for example, then you have a behavior that's a little bit more like this so that you don't have to bring in the full Erlang stack in order to run RBI. All of these implementations are available on GitHub. They're available for free. You don't need to be a member of Genevieve to use them. You don't even need to have a car to use them. You can run them on your desktop environment platform because Genevieve is a Linux focused organization. We do most of our development on Linux. And so most of the testing that we do and the continuous integration pipelines that we do are all done on Ubuntu or another x86 Linux architecture. So when I'm working on it, I prefer to work on it in a virtual machine. But there's lots of options. Well, there are, if you've attended any of the other talks here this week, you've probably heard some other talks about IoT and messaging platform or messaging protocols. So I attended a talk on DPS for IoT. It's a distributed published subscribe model for Internet of Things that definitely has some commonality with RBI. I also attended a talk on Lyoda, which has, again, some commonality. They're definitely operating in a similar space. One of the things that is motivating us for RBI is we want to keep it completely open source. And we want to make sure that the licensing is very permissive so that commercial implementers can integrate it into their own platform without licensing difficulties. So that's a MPL version 2.0 license. The flip side of that is we don't really know what uptake is yet. We know that we have other Genevieve members and people outside of Genevieve organizations who have emailed us about issues that they've run into or feature requests. We've had ongoing conversations with IoTivity and the Open Connectivity Foundation about working with RBI. But ultimately, we don't know what the uptake is. Yes. So Advanced Telematics did a reference implementation for software over the air and firmware over the air with Genevieve. We have been working pretty closely with Advanced Telematics. So that SodaFota is part of the overarching project concept for RBI. RBI consists of the project charter consists of three major areas. It's control, software over the air, and big data. So that's metrics. As I understand it, the current reference implementation that ATS has for their Soda platform does not use the specific RBI, the specific Erlang RBI implementation, but that is a planned modification. The C Library, in fact, was developed in response to an ask from ATS to have a lightweight client that did not require the full Erlang staff. Yes. So right now, RBI Live, that's the C Library implementation, is currently the only one that is under review for compliance with Genevieve. Right now, that is a platform compliance proposal. So our target in the short term is to get that incorporated into the Genevieve development platform to give it some more time to mature and identify how people are using it and what features may need to be added for a production release. The Erlang implementation, however, is the implementation where it's likely that new features will be introduced first. Does that help? Yeah, I realized I forgot to repeat the question. So the question was, so basically, the spec is solid, but are there any open source known production ready implementations for it? And I would say that the Erlang implementation is the most mature, but as a developer on the project, I would not feel comfortable putting any in production just yet. Yes, the spec is open. It's available both on the GitHub repo. The high level definition document is available in the RBI Core repo. There are links to it from the other RBI repos as well. And it's also available through the Genevieve Projects wiki. And I'll have a link to that right at the end. So the primary motivation for the spec is to define the data router and the protocol of how messages look when they're being transferred over the air, as well as the connection protocol. Unfortunately, I don't think I included those particular slides in this slide deck. I didn't want to get too much into a deep dive, given the time limitations. But let me see. We have some information right here about how an application will look. So this is roughly how a southbound would be. So southbound would be from the data router to the application on a device. And northbound would be from the device up to the cloud. So this is a pretty simple JSON message. It asks for a service name. One of the pieces that the spec defines is the concept of fully qualified service names. And if you're familiar with MQTT, it's going to be a fairly similar concept. It has topics. It has delimiters using the forward slash, just like an MQTT. Access control is based on wild carding modeled after the MQTT specification. A fully qualified service name will always include a domain. It will include a device type, the UUID, and then some subtopics, which might be control subtopics or it might be topic names for metrics and so on. A method invocation can also include parameters, which is just a simple JSON object. The data router takes that JSON request that's come in, identifies, based on the service, a routing method to forward it to if that service is still available, if a connection is still live. If the connection is not still live, it will hold that message until a timeout occurs. And I see that there isn't a timeout specified in this particular callback. There are some default values that are specified or an application can specify a timeout directly. And if a connection makes that service available before the timeout occurs, then it will route that message, route the invocation to the correct service. So it will hold it in a buffer. This is a way to handle sparse connectivity. Car obviously isn't always going to be connected to the internet. And also supports multiple types of routes that might be possible. So if your car, if you're driving down the road and you're in a good cellular network, it might be fine to stream information from Spotify to play your music. But if you're parked in a garage and you've got your phone, you've got a mobile unlock on your phone, you don't want to have to have access to a back end server in order to be able to unlock your phone if you've previously authenticated. And so part of the spec is supporting multiple data link layers. And that's Bluetooth. It includes some, we've done some proof of concept on SMS using wake up SMSes over RVI. Actually invoking services over SMS is not often very successful because it's not a particularly reliable method. SMS doesn't guarantee delivery at all. It doesn't guarantee that the delivery will occur only once. It doesn't guarantee delivery within a particular time frame or not at all. So there are definitely some perks to offering SMS. But also some limitations. And does specify a variety of security features. In general, we prefer TLS version 1.2. We do not support any earlier version of TLS or SSL because they're vulnerable. Over an unreliable connection, we support DTLS or TCP tunneling over UDP, for example. We use asymmetric cryptography with a public key infrastructure. The scope of the public key infrastructure is outside of the scope of the RVI project. But one of the assumptions that we make in this project is that it is possible for a provisioning server to be a trusted route that is available to provision certificates, both for a device and to make certificates available mobile device and to a vehicle. We also assume that that provisioning server has the ability to create JSON web tokens, which is how those self-carried credentials are generated. So we've got a little bit about authorization in here. How many of you have heard of JSON web tokens before? OK, so for those of you who aren't familiar with it, a JSON web token is a JSON structure. It's when you have a signed version of it, it looks like a base-64 encoded string. It's got three parts separated by a period. Mostly looks like garbage. If you have the public key of the signing authority, then you can check the signature on it. And of course, even if you don't have the public key, you can base-64 decode the header and the body to see what the contents are. You just don't know whether the contents have been tampered with by some other authority. We use JSON web tokens along with data link encryption to ensure that even if there's some sophisticated TLS man in the middle attack, for example, then the access control still relies on that original route of trust. The credential will contain information like the device's own X509 certificate signed by the trusted route. So this is the information that proves that the device really is who it says it is. So if I'm a bad actor and I steal your F-types credential, then and modify it so that it's using my device certificate and then try to send it along to your F-type to try to steal your F-type, then it's not going to work. Because your F-type will have a different certificate to use in the TLS upgrade. The original signing, the original provisioning for the certificate and the credential are handled out of band of the RVI protocol. It would generally be expected off the assembly line when initializing an app on your mobile phone, something out of band of your standard usage. We've also defined a protocol that I have in our supplemental slides for dynamically provisioning. And this procedure works. We have a guest device that creates its certificate signing request. It does initial provisioning that you might expect, creating a public private key pair, creating the certificate signing request, sending that certificate signing request along to the provisioning authority to get a signed certificate back. It will also get a basic credential authorizing it to use an internal RVI service to get additional credentials. And so then when it connects to a car, on that car, it can invoke the internal RVI service to get additional credentials. And if a user space application that a driver interacts with grants additional permissions to unlock the vehicle, for example, or to control the media player, or control the HVAC settings, then that vehicle would act as an intermediate certificate authority and create a new set of credentials for that device that just connected. And because of the two-step authentication, the multiple steps involved on both ends of the device, we expect it to be difficult to compromise in much the same way that paired Bluetooth connection is difficult to compromise. Do I have any other questions so far? How do we prevent replay attacks? The major one, of course, using TLS, we can reduce the possibility of replay attacks. We also have, in the specification, transaction ID in every message. And so if the transaction ID is lower than the last known good transaction ID, we can discard the message. It depends on the specific implementation choice of the system administrator setting up RVI. But it is our recommendation that you do. So if I were an evil guy, and I set up my own base station, and I managed to convince your appetite to associate and sell your connection, and then I could do a TLS mill in the mill because I own a base station, what would, is your only last security barrier that you often web tokens on transactions to prevent someone from using it? Yes, so the question was, if I set up a malicious base station and I'm able to do a TLS man in the middle attack, is the final piece of authentication these JSON web tokens? And yes, this is part of our defense in depth strategy, a TLS man in the middle connection. In many cases for remote vehicle interaction, we're not really seeing other strategies to prevent anything beyond that. What we're doing with this is that the credential, if it is not signed by a trusted provisioning server, if it doesn't have the correct signature on it, then we completely reject anything. And the vehicle, the remote device, won't even expose any of the services that it has available on it. Does that answer your question? The lifetime of the certificate is, again, an implementation detail that we don't define in the specification. We recommend short-lived certificates. Do I have any other questions before moving on to the next slide? We have, ah, for what's next for RVI, we are currently undergoing a Geneva compliance review. We've also been undergoing a security audit with the Geneva security team. The security audit report, I believe, is being released soon. But that may be an internal Geneva release. I'm not sure about that. We are continuing to work and extend and mature our proof of concepts. And we are working to get to the maturity level of having a reference implementation that we integrate into the baseline for Geneva, for future Geneva releases. We are also participating in a Geneva-sponsored project to field test RVI. It's called a Smart City Pilot. We're working with the city of Las Vegas with sensor networks, traffic data. And we're doing a test on how drivers respond to driver notifications for high-risk pedestrian areas. We have a variety of big data demos, and we're working on IoT integration. As I said, we have been speaking with the Open Connectivity Foundation at CES, Geneva, and OCF data joint demonstration on an F-type that actually sits about 20 feet away from my desk most of the time. We have all of our GitHub repos right up here. Most of our proof of concepts we wind up doing with a Raspberry Pi or a development Android. There's a lot of options. The Erlang proof of concept has the most features available to it. The C proof of concept is the proof of concept that we're working most closely on maturity. We also have the Android and the iOS SDKs. And we do have demo projects that are available both on GitHub and it's something that we're actively using with our team in the office. And then all of the Genevieve project information is right here at projects.genev.org. Recommended reading on automotive security. Like I mentioned, Craig Smith's Car Hacker's Handbook. The Miller and Valasek white paper is just titled Remote Car Hacking, or Remote Exploitation of an Unaltered Passenger Vehicle. And then a group of security researchers also based here in Portland with the company Galwa did a paper and a presentation at the SCAR conference in 2016. So SCAR is Embedded Security for the Car. That paper is also available for free online. I'm always looking for new recommendations on security related reading. Also, how many of you heard Google's announcement, Google security team's announcement today of the first known SHA-1 collision? Good. So I see a hand there. The terrifying paper from the University of Washington is an excellent paper and I also recommend reading it. One of the first papers on automotive security that I read even before the Miller and Valasek paper was, I think it may actually have been that University of Washington paper. It was talking about radio as an attack surface because signals are just data. They're interpreted by a computer in your car. RDS, a data, is turned into a stream that's used to display the information, station identifier, maybe the song if the data is high enough quality. That's an attack surface. Yes. So. Yes, so repeating that for the video, the important idea is to isolate concerns and to assume that you will be attacked. So the RBI team are certainly assuming that the vehicle is operating in a malicious world and that we will be attacked. It will probably be often. It will definitely be, some of those attacks will definitely be by people who have some amount of resources behind them. And so isolation is very important. There is, at the same time, a competing pressure inside the automotive industry to integrate concerns. Because, of course, why wouldn't, like with all of the smart home controls, why wouldn't you want to be able to control all of your HVAC settings in your car? Or have your car recognize you when you, maybe even before you get into the car and make it just the way you like it. How many of you share a car or maybe use car rentals? It's so annoying every time I get in to have to readjust the seats and readjust the mirrors and figure out what radio station I'm on. So like there's certainly the motivation to integrate these concerns. But there is also a very real security consideration. Because, quite frankly, getting control of the radio, which is what Miller and Balasek were originally trying to do. They were just trying to control the entertainment system, should not give you control of safety-critical systems. If you're operating under the assumption that some parts of your system are not high assurance, then you'd better make sure that they're not high assurance. Yes? Yes? How is the car which actually being operated for a car well, in for maintenance? Yeah, so the question to repeat it was, was there no separation of concerns between the IVI system and the safety-critical systems in this particular line of vehicles? And why not? And the answer is, clearly, there was not enough separation. Internal, the car's internal network often all operates on a, may operate on a single bus. It's not always the case. Every different manufacturer has different software architecture that they put in place, and different physical and different hardware architecture as well. One reason that it may have happened in this case is because with so many components on board a vehicle, you run into very real space considerations, and weight and cost considerations. And so for people who are accustomed to developing in an environment where an air gap is sufficient to enforce security, there's a very, very small threat to the IVI and safety-critical systems being able to communicate with each other. And there are some advantages. If the brakes are depressed very, very quickly, that might indicate an accident. If the airbag is deployed, that might indicate an accident. And so you might want to have the car, the doors, unlock automatically so that you don't have somebody trapped in a panicky situation where they're trying to unlock the doors. And at the same time, we all know that there is a motivation to have a remote key unlock or a mobile device unlock. And so already with just that combination of considerations, you get this motivation for some form of inter-process communication. I think modern vehicle architectures, or post Miller and Balasek exploit vehicles, I think every architect in the automotive world is thinking about that separation of concerns and thinking about how to enforce access control. But ultimately, these are very complex systems that are composed of a lot of proprietary parts. And the major focus of OEMs is not on software development expertise. At best, most OEMs have expertise as integrators of solutions that are provided to them by third party vendors. And the fact that we have so many platforms, so many complicated architectures out there is a big motivation behind what Geneva is working to do in providing baselines and also in what automotive grade Linux is working to do in providing an embedded Linux distribution that can serve as the foundation for an IVI system. Looks like a time about five more minutes for questions. So does anybody else have any questions? Yes? We're really hackable. So here we are going into a place of time where just for convenience, we're giving ourselves an opportunity to get killed. Does that make sense and should we be doing that? OK, so the question is, we used to drive cars that were very manual. Didn't have a lot of software components, if any software components. And so it was pretty hard or impossible to hack those things. And the question is, we're giving ourselves an opportunity to be killed for the sake of convenience. Should we do that? And as a counterpoint, I will offer you that that is what driving is. People died today discreet for human errors. So how many guys have to be lost because they are stolen? There are 100,000 for a month. Sure. And that can increase. Or if there are not, we do how it happens. I think that's a really excellent point. We have a gentleman over here who has his hand raised for a question. Yes. Vehicle maintenance is only safer. So I think both from your point of view and from your point of view, those are some really excellent points for motivating software and connected software in vehicles that go beyond my flip point about driving. But I think my flip point about driving still stands. So one thing that I want to add is that we have passenger vehicles. You're talking about commercial vehicles offering safety features through management software that do have to connect to a back end server somehow. We also have a lot of cases of passenger vehicles and aftermarket modifications of passenger vehicles that do improve safety. And some of those are modules that stay entirely on the car. And some of those are modules that do connect to a remote service. And to your point about stealing cars and manual cars, my first car was a 95 Honda Accord. It was a stick transmission. Love that car. I still miss it. My stepdad used to drive Toyotas. How many of you are familiar with the whole Toyota? We're the super-roo keying issue where there were only so many different kinds of keys that were made. So about one and I think it was about 1 in 1,000 vehicles were duplicated, 1 in 100, so even worse than I thought. So the known mostly like a matter of convenience by some good examples of physical considerations and trade-offs that can be made that software can enable and possibly make the property or lives safer for people in the automotive world. I think I need to get out of here to let the next speaker talk. However, I've got some contact information right up here. If you'd like to talk to me just outside, I'd be happy to chat some more. Thank you very much for coming here today. Thank you.