When I tell people I am working on Web Standards for Connected Vehicles at W3C I often get a response asking if I'm sure that is such a good idea. This is especially true if the person is technical and/or has seen any of the various news articles on remote car hacking or prominent FBI warning on the subject. For those not familiar with this space, some general background first.
Vehicles are already connected and have been for quite some time. OnStar has been around for a couple decades and it has been found to have had vulnerabilities.
Security on many recent and current vehicles is absolutely frightening. It reminds me of corporate data centers of the 1980s, wave a badge at the security guard armed with a flashlight and when you are in the network (LAN) is wide open. On vehicles the network is a series of black boxes, electronic control units (ECUs) that provide specific data and functionality for various things including brakes, steering, acceleration. The problem is they are not always closed networks. Fortunately this area is getting a tremendous amount of attention, the industry understands the scope of the issues and working to address them.
I am concerned however when I hear at conferences assertions that proprietary is statistically more secure (all those ECU black boxes are proprietary from a large array of manufacturers). Security through obscurity is not secure, it is a vulnerability waiting to be discovered. Vendors of proprietary systems often quietly provide fixes as upgrades to avoid sales impact of negative publicity so we have no real statistics. Recalls/upgrades are costly and can be difficult or impossible to upgrade all affected systems (cars, underlying ECU). The next generation of connected vehicles will all have over the air (OTA) update capabilities as the industry saw how Tesla was able to quickly patch vulnerabilities (and add major new features including autonomous driving) to its entire fleet of vehicles whereas Chrysler had to mail USB fobs at considerable higher cost without being able to reach all their affected vehicle owners. Gaining physical access to devices gives security researchers and potential attackers ability to seriously dissect and analyze functionality and flaws of proprietary systems. They are even able to reverse engineer on the ROM and chip level, watch some Chaos Communication Conference videos for examples, which require more advanced techniques than playing with ECU from salvaged vehicles easily acquired on eBay. Being able to make an underlying function call in a manner other than intended may be sufficient for an attack without needing to compromise the ECU.
Attempts to make it illegal to research security vulnerabilities or even restrict right to repair one's own vehicle by accessing diagnostics data are steps in the wrong direction.
"It's certainly easier to implement bad security and make it illegal for anyone to notice than it is to implement good security." - Bruce Schneier
Another statement that I find unsettling is that there has been no widespread attack in the wild. Recalls/upgrades as mentioned are costly and embarrassing. We have seen hesitation on issuing recalls due to cost, fatality statistics and lack of public knowledge of the flaw. I agree security is a balance of risk, feature demand and benefit, convenience et al. The risk is too large to ignore. A widespread attack could render cities in massive gridlocks or worse. I sincerely hope this lack of attack in the wild argument is not a justification for curtailing security investment but to allay public concern while addressing the problem for new and existing vehicles.
Other responses I get about Web Standards for Connected Vehicles is excitement over the plethora of potential use cases, how much it can improve or even save lives. There are many other industries (insurance, travel, service, entertainment, IoT, web payments to name a few, several of which have W3C activities as well) interested in being able to harness this data and be able to interact with vehicles. Consumer demand and business potential are pushing this market.
W3C has an Automotive Webplatform Business Group which started a Vehicle API which exposes underlying vehicle information to a web runtime in the In-Vehicle Infotainment (IVI) system. IVI is also sometimes called a head unit, think car stereo marries computer and provides a touchscreen (voice as well) interface. An Automotive Working Group was formed to take this API through W3C's standardization process, freeing up the Business Group to act as an incubator. The Business Group is working on Location Based Services (LBS) and Media Tuning, the latter has mostly been providing input and use cases to the TV Controller API Community Group which is in the process of itself forming a formal Working Group. The Business Group has other topics, including software over the air updates, on the back burner that may be taken up if critical mass of interested parties get involved.
We formed a Privacy and Security Task Force to understand the IVI computing environment the web runtime will be operating in including security considerations being handled at the OS level of the stack, explore use cases for potential web applications running in a vehicle using these standards and the security concerns that arise.
The Vehicle API is primarily read only for the vast majority of attributes but does allow some to be set which provided the underlying implementation follows provides protection preventing possibly dangerous changes being made by a web application. We are in the midst of a major refactoring discussion for the Vehicle API switching from a WebIDL web runtime (browser plugin) approach to Web Sockets, JSON and RESTful model. I will not go far into that tangent other than to point out how the latter will be easier to maintain separately, not coupled to web runtime security releases, provide another layer security can be applied and the API can be leveraged by other systems on the vehicle other than the IVI.
The various IVI platforms will be hardened following many of the existing security practices for that given operating system (OS). I have a number of thoughts on specifics techniques to include but that is out of scope for this article. Genivi and Auto Grade Linux are Linux based and as a long time Linux user, developer and administrator will base examples for that platform. There are other OS and architectures being used in this space like QNX which is BSD based and generalized guidelines can be adapted to those platforms. They will be employing systems like SELinux, AppArmor and Smack to control which processes (including the web runtime), files, ports, etc a given process can use. These systems log rule violations and any such violation should result (fail2ban or similar) in a report upstream of any evidence and temporarily disabling the application that violated the defined policy (rule) until an upgrade is received. There may be multiple web runtimes with different levels of trust, some perhaps not even allowed to access read only information through the Vehicle API.
Solutions will vary but we some are considering multiple runtimes with different security levels and even permitting a sandboxed browser that can interact with any website from the vehicle. The browser will not be permitted to interact with the vehicle CAN bus data exposed by the W3C Vehicle API. Lower security level web runtimes will have limited read-only access to vehicle information.
Vehicle IVI apps with access to the Vehicle API will not be roaming the vast and varied expanses of the entire web. Auto manufacturers (OEM) simply will not permit a wide array of unreviewed applications to operate in their vehicles. Applications and web sites and services they interact with will need to be thoroughly vetted and closely reviewed on an ongoing basis for security, privacy, accessibility, usability, distractability and other considerations. Independent, objective, expert assessments will make for marked improvements in all categories. In conversations with auto executives and engineers they have also said there is no shortage of organizations wishing to have applications running in their vehicle IVI. There will most likely be multiple app markets for different vehicle manufacturers, sometimes grouped together. This environment with multitude of parties, OS platforms, markets and potentially third party reviewers clearly demonstrates the need for guidelines, conventions that it is possible to verify are being followed and done consistently.
Since we have a fairly controlled environment instead of an open free for all and companies eager to run apps in these IVI systems, it should be feasible to get them to adhere to guidelines that increase security and abide by imposed privacy and other considerations. Some of those are obvious and some can be explored and teased out more.
There are many advantages to defining and requiring a common set of guidelines ranging from lower integration cost, easier to involve multiple parties in development and review and avoiding duplication of effort. There can be different conformance levels based on what the application is permitted to do, right sizing. OEM and Tier ones could also elect additional requirements above any commonly defined ones for apps to be permitted to run in their environments.
This scenario makes me start to feel more comfortable.
The biggest attack vectors for web applications running in a connected vehicle IVI will be from security flaws in the application themselves and interaction with the web. You have to worry about things like code injection and data manipulation when apps on the IVI interact with data and services on the internet. Requiring all interactions between the vehicle and internet to be encrypted for instance is a start but brings up some questions. Having web interactions go through SSL is vague on its own.
As this can and probably should be a more controlled environment than the Web at large restricting which ciphers are supported for better encryption strength, here I would be inclined to be more rigid than what browsers presently allow since they have to factor in the lowest common acceptable denominator that websites use. Here we will be interacting with fewer sites that are motivated to be permitted in the IVI. In spite of Google's efforts SHA1 is not gone yet. Site operators practices vary widely and their SSL setup should be evaluated using various services against whatever baselines are decided.
I am in favor of SSL certificate caching, maintained (including revokation) by the packaging system used for that market/platform combination, for linux store under /etc/ssl/certs. This is not feasible for broad web interactions but IVI app developers could be required to disclose all sites their applications will interact with. The IVI could even be configured to only trust locally cached certificates, doing so along with blocking non-HTTPS traffic would mean only trusted sites are used. It would protect against a man-in-the-middle (mitm) attack with a forged certificate. SSL caching also increases performance, no round trips to verify a signed certificate with its CA. In this model it would not be necessary to use CA signed certificates but probably still should so reviewers for the app market have that and other means available to verify the certificate before including it in the application package. If SSL certificate caching doesn't become a guideline then a number of methods such as HPKP should be considered.
Another thought is in addition to caching SSL certificates domain name service (DNS) is cached as well, here again it could be file[s] to install for a local name server under /etc/bind9. This would prevent DNS spoofing, improve performance again (no lookup needed) and if there are no external name servers then only trusted, defined sites can be reached (by hostname, URIs could be IP instead of fqdn). A firewall should be maintained on the IVI or separately on the vehicle. It could read IP addresses to permit from these local DNS zone files or better a firewall rules file per app can be defined and part of the package.
A firewall should not permit pushing of any data to the vehicle as it could be spoofed and it more checks can be applied in pulling. For time sensitive updates a polling frequency can be defined in app per data source.
What could offer a great deal of protection in such a controlled environment is a Web Application Firewall (WAF) such as mod_security. It can inspect every outbound and inbound (again advise against allowing data to be pushed to the vehicle) connection down to the methods (GET v POST), particular website service URIs, encryption ciphers expected and permitted and parameters passed among other things. All web traffic would be steered through this application firewall by the web runtime's proxy settings or enforced by the network firewall. One caveat is this would necessitate the environment either doing a mitm against itself or requests to the WAF would not be encrypted, trusting the local network if the WAF is not local on the IVI itself. Otherwise the WAF would not be able to inspect the requests being made. With some more thought there may be a more palatable solution that is not too cumbersome. To encrypt the communication between the app and the WAF a second certificate would be needed separate than the one to be used between the WAF and the remote website. WAFs provide data loss prevention and guard against data tampering. It also protect against things like cross site scripting (XSS) and user session hijacking. The ability to inspect parameters being passed to external sites can detect applications attempting various (eg SQL injection and buffer overflows) attacking those sites and trigger an alarm that the local application is compromised.
WAF can check existing and emerging Content Security Protection (CSP) directives and should pass those headers onto the web runtime. We are still waiting to see which CSP2 specifications mature and get implemented in web runtimes but ones already deployed would allow sites to define which content and services can be used when interacting with other sites which is useful to allow or prevent apps on IVI combining those external services.
Should the Vehicle API architecture switch to a web socket approach as mentioned earlier, a WAF can sit on top of that server, checking any security mechanism (tokens) for registered applications and enforcing granular access control rules, connection limits etc. While this can be done by the local web socket server it might be easier to abstract out to a WAF layer for consistency and ease of defining application specific rules. Keeping those rules separate from web socket server configuration should be more maintainable. This doesn't prevent sound practices in configuring the web socket server as an additional security layer.
Requiring expert security review before inclusion in an application market would prevent mistakes like the Nissan Leaf querystring containing sensitive, personal information. The application package would contain rules for defining website interactions needed. Coming up with WAF and the various other types of rules mentioned are fairly reasonable to come up with by the developers or a third party reviewer by inspecting the code, running the application through a debugger or network monitor. As a significant bonus the WAF can also be configured to be a caching content proxy so that stale but still useful data would be available to applications at times when the vehicle has no network connectivity. One can go pretty far with additional protections in a WAF such as data integrity checks and ensuring only certain permitted content types go through, preventing for instance outside javascript from being passed to applications.
Sensitive or critical data can be signed according to W3C WebCrypto API or other techniques and can be verified by the WAF before passed to the application.
I would like if at all feasible for all javascript necessary to be installed as packages. All common javascript libraries (jquery, bootstrap, etc) should be maintained by the application market itself, not permitting application packages to provide their own alternate versions. App specific javascript should be packaged and subject to security code review before each release. Apparmor (or other) rules can maintain what local javascript directories the web runtime are permitted to use. They can also control where to find local images, stylesheets, markup and where data can be written on the IVI. Personally I like AppArmor more than SELinux since it is much easier to read (and write) rules.
If all of this is starting to sound too tedious for third party developers and website operators, bear in mind they can focus on development and subcontract making package manifests along with cataloging all sites, certs, local libraries and applications needed, identifying common js, firewall rules etc if the market maintainer does not offer such a service. Independent security review should be required before application is accepted into a market. Both client and server sides of the equation need to be addressed. External websites being interacted with should be subject to penetration tests with particular emphasis on specific services (URIs) being interacted with. These website operators should consider dedicated servers for the services used by connected vehicles and not part of a larger multi-purpose site as that would mean fewer attack surfaces for a potential site compromise. Violations to any defined
While I have not gone into privacy guidelines you may notice these web security guidelines provide a start and the mechanisms can be extended to further safeguard privacy. The various types of rules in a packaged should also include necessary comments (or be parsed) to provide individuals with a clear explanation of what data is being sent where. There would need to be methods defined for retrieving encrypted (WebCrypto) personal profiles from the web, local storage provisions and managing personal certificates, credentials and identifying or session cookies. This will need to factor in the requirements of shared vehicle business models we are seeing more of from the industry (GM Cruise Automation being one example) and already in practice on personal and corporate levels (car rentals, company vehicle fleets). I am leaving authentication alone for the time being as well as there are a number of possible approaches including multi-factor and hardware based authentication being worked on at W3C.
There is more to say about what I would like to see in application markets and on IVI but this article is already too long. I would suggest running debsums (or platform equivalent) on all app packages as part of the IVI bootup procedure. Marketplaces can be shared across OEM with any custom branding applied per make and manufacturer with differences of package image, stylesheet and markup templates. IVI manufacturer Tier 1s' apps may be more inherently more trustworthy than those from third parties but should still be subject to the same mechanisms.
We have a number of open questions general to Web APIs being specified and specific to applications in connected vehicles to answer before publishing a set of guidelines. The W3C Automotive Working Group will be liaising further with WebAppSec and other W3C Working Groups in additional to activities at other organizations. While these ideas cover a number of OWASP concerns there is more that can be done.
These are just some ideas on possible guidelines to better secure connected vehicles' IVI systems from a web based perspective and not meant to be exhaustive and absolute but to open a dialogue. Please get involved in the activity and feel free to post comments directly on this article. While I have had conversations with OEM, Tier 1s, security experts and third party developers, standards and guidelines are better when more stakeholders are actively involved providing their use cases and perspectives.
Any proposed guidelines need to be thoroughly tested and evolve continuously with new attacker and defense techniques. I submitted a grant proposal at MIT for @@@ like UW autosec.org@@ explain scope of grant proposal ACL - we should explore how to handle authentication of user, vehicle and applications. strong desire to move away from passwords. api key tokens for each registered app. 2FA for driver's personal profile and gaining access to entering and driving vehicle Ted Guild is based at MIT the Head of the W3C Systems Team @@@ CORS - and... content sniffing https://scotthelme.co.uk/hardening-your-http-response-headers/#x-content-type-options fetch https://fetch.spec.whatwg.org/ potentially ========================================= see also cipi notes, sec-writeup and Toyota adas and autonomous proposal - data driven decision