Once robocars got public attention, a certain faction promoted the view that we should be giving much more attention to the idea of the "connected car." The connected car was coming sooner, would have a big effect, and some said that it was silly to talk about robocars at all without first thinking of them as connected cars. Many even pushed for the vocabulary around robocars to always include connectivity, pushing names like "connected autonomous vehicle" as a primary term for the technology.

Robocars will be connected, but not nearly as much as people in the "connected car" world imagine. And the connection won't be essential. Some cars will work with only a connection when they are parked, or with intermittent connectivity during the day. But most of all, they won't connect out to the world. The robocar probably will connect only to servers at its HQ -- the company that made it or which runs the fleet it's in. It won't talk directly to infrastructure and other cars, it may not even talk two-way with the rider's phone.

Fortunately, the efforts to require vehicle-to-vehicle and vehicle-to-infrastructure connectivity in cars are rumoured to have suffered a setback in the USA.

I call this partially connected car the "disconnected car" because, while not fully disconnected, compared to the typical vision of a "connected car," it is effectively disconnected. The primary reason for this is security. With security being so important in robocars, we don't want to open up any more "attack surfaces" than we have to. An attack surface is any path of electronic entry (or physical) into the vehicle. The fewer you have, the better chance you have of your security actually working.

• No two-way connection between the driving system and non-driving systems (such as entertainment) in the car
• No connection between the driving system and the passenger's devices.
• A one-way streaming output from the driving system which can be used to display status and other useful info
• The driving system communicates only with its HQ servers in a highly scrutinized authenticated channel. It is wary even of its HQ servers.
• Absolutely no V2V and V2I except through the HQ server
• Many classes of software updates do not go over the air. Rather the car drives to an update depot to add physicality to the update process

Here I propose ideas for the security architecture of robocars, based on the idea of the disconnected car.

One way communication between driving system and user systems in the car

The driving system should be effectively entirely isolated from things like the infotainment system or other user experience systems. Those systems will be connected heavily to the user's phone and can't be trusted. Here we want almost an "air gap" -- no connection or wires between them at all.

One exception might be the ability of the car system to receive a one way stream from the driving system. The driving system would put out streams of useful information that the car UI system might want to display. Map data. Progress data. "How is it working?" data. Audio alerts. In the pure model, it would broadcast a stream with redundant information (to allow packet loss,) but we might permit a very simple flow control/ACK protocol to allow the UI system to turn the stream on and off and request the retransmission of packets so that the connection is reliable. Scrutiny would be put on even this low level protocol.

The driving system might also just have its own display, but it's too useful to be able to write apps for the user's phone and in-car system to do a better job with status information coming from the driving system.

The driving system's own UI hardware

Even though it is wasteful, the driving system should have its own independent UI hardware for very basic UI, such as the input of destinations, changes to destinations, driving preferences and stop orders. This hardware might not normally be used. Instead, the user's mobile phone can provide this interface better, and send the commands up to the HQ server. (HQS) Since the phone might not always be able to reach the HQS, a backup display and UI to allow basic commands might be needed, though rarely used. For the disabled, speech interface might also be good, or it might be the only backup interface.

Talking to the sensors in the car

A car's sensors may get compromised, and attempt an attack on the driving system. The sensors should be air gapped from all other systems, on an independent network from other car networks. The sensors should not ever talk digitally to the outside world. If they need information or software updates, these should be provided only by the driving system, which will use its connection to the HQ server.

A sensor may be compromised by physical access to the car, but this is not an attack that scales. Protection against that requires sensors that are tamper-resistant. Sensors should probably communicate with the driving system over encrypted, authenticated channels. If a sensor is replaced you may need steps to assure the replacement is trustworthy -- no small problem, though this sort of attack is not scalable.

Sensors may also be fooled by false external data, which again is not a scalable attack and is less likely to present a channel for compromise, unless the sensor can actually be hijacked by external data. Sensors which talk digitally to the outside world should not be used, and reviews should be done to assure that strange data from the outside world can't cause buffer overflows or other channels into the sensor's microcontrollers.

Some attacks on ordinary cars have come through channels to sensors such as the tire pressure monitors, because they communicate wirelessly with the car. Wireless connectivity should be discouraged and highly secured if it must be used. While tire pressure is difficult to do with a wired connection, extra scrutiny must be applied on connections like this.

It may be wise to have a different physical network for the driving system and its sensors. Since robocar sensors tend to be much higher bandwidth than traditional car systems, this can be a good idea anyway.

Communication with the HQ server

In addition to the sensors, the driving system should communicate only with its HQ server. Reality requires this will go over an untrusted channel such as the mobile data networks, but all data should be signed and authenticated, and encrypted doesn't hurt. Any unusual packets coming from outside should be flagged, logged with care and discarded. Only packets with correct signatures should be accepted for further processing.

Even so, there must be proper data hygiene and suspicion about packets and messages signed by the HQ keys. HQ may be compromised at some level or another.

The messages from the HQ server should be well scrutinized and limited. Adding a new one should require strong proof of value, and a protocol designed to be robust against malicious messages. Unfortunately, this protocol will still be complex, and is the greatest risk of external compromise if HQ is partially compromised, or its keys are.

In some cases, the underlying channel may be a privately negotiated 4G or 5G channel. However, at times it is expected that an internet based protocol will be used. In that event, the use of DNS should be avoided. Instead the HQ should have a list of servers which can be contacted by IP address so that simultaneous failure of all of them is highly unlikely. Updates can update this list. No 3rd party (including DNS) should be depended on for any authentication or identification.

The customer's phones will also be talking with HQ, but to different servers, which will relay sanitized commands to and from the HQ server to send to the driving system.

Information for/from other cars and infrastructure

At no time should the vehicle receive messages from other vehicles or infrastructure. While it might be permissible (from a security standpoint, not a privacy one) to send information out, this should be over a pure broadcast protocol if done at all. Those other vehicles are foolish to process it, however.

Instead, vehicles should talk to their own servers which would gather information on car activities, traffic, obstacles, hazards, changes to the road and more. This information should be gathered by an independent server and sanitized for security purposes, then checked and sent in an approved format to the HQ server for relay to cars.

All data from infrastructure can be sent over longer latency channels. Traffic signals do not change their plans in sub-second times. At present, there are few messages that require sub-200ms latency, except for the synchronization of platooning vehicles which is a special case. Effort should be made to get the latency down on vehicle-server-server-vehicle below 100ms. This is readily attainable with a special effort, much smaller than the effort to get DSRC radios in all cars, and it would have greater reach and lower security risk. Mobile data companies plan very low latency channels in their 5G roadmaps.

Updates of software -- not always over the air

A great risk comes if a compromised software update is sent to vehicles and they automatically install it. Updates must undergo extensive code review by independent security auditors. Signing keys for updates must be controlled, and all updates must be signed by several auditors, ideally located in different political regimes.

Non-emergency updates should be rolled out slowly. Contrary to common conception, it may make sense to not do these "over the air." Instead, vehicles might be told about the availability of an update, and they should then drive by an "update station" at a convenient time, where they can get the update over a local data link. Activity at update stations should be logged and monitored. Any attempt to do a surprise update of vehicles will have a physical obviousness to it. This comes with some energy cost, of course, so it may be that only a fraction of vehicles make the trip, to assure the physicality, and then later other vehicles can receive the update over the air.

There will (ideally rarely) be updates which must be done over the air because the problem is so serious it would be unsafe for vehicles to drive to the update station. Such updates must require even stronger code review and signing by more parties with well secured signing keys. Vehicles taking such updates should still do some physical movement and make sounds so it is impossible for one to happen without being noticed.

Communication with the mobile devices of passengers

One of the most difficult issues is any communication between the driving system and the mobile devices of passengers. Passengers will use their mobile devices to summon vehicles, to see their approach and to do post-ride communication. They also may wish to be able to reroute vehicles using this device and get ride status information.

The user's mobile device is clearly an untrusted device. It must be assumed to be compromised and ready to attack the car system at any time. As such, there is a strong incentive to not communicate with it. Instead, it can communicate with the cloud and HQ servers, which can relay data to the driving system. This would fail, however, in the event the car or the mobile phone is somewhere off the network. Since the car and mobile phone may use different networks, this can happen to one and not the other.

Network dead zones will be known to the car for the networks it uses. Cars will not wait in the dead zones, and will avoid driving in them. However, zones for customer devices will not be as easily predicted.

Connected user devices

While the safety and driving systems of the car will be mostly disconnected, the passenger-serving systems such as the entertainment system, climate controls and user's mobile devices can and will be well connected. In fact, since people will want to do things like watch movies and surf the web while moving, they will demand even more bandwidth than we use today on the road. All of this infrastructure is already being built, and people want it not just when they are in the car. As such it is not really related to the question of car connectivity.

It may be the case that cars will contain a mobile data relay, to take advantage of a car's ability to have a better antenna and higher power radios. This is fine, but should be kept isolated from the driving system. In theory the same radio could be used by both as long as a very well tested system only allows signed and authenticated packets from outside to be relayed to the driving system, but scrutiny here should be quite high.

It is the best plan to put most intelligence not in the car's entertainment systems but in the user's mobile device. User's devices are constantly being updated and are powerful. They are also customized to the user. Most users have things like their music already in their mobile device. They don't seek to use a different interface which changes from car to car. At most, they want the car to be a peripheral, offering speakers or a big screen when they interact with their user.

Additional security practices

With the minimal connection proposed, there is still more to do to increase security. There will be compromises of the HQ server. There may be people working on the software who become malicious, or who are even foreign intelligence agents. A good architecture makes it difficult for even a malicious executive at the company making or managing the car to compromise it. In theory, it should be not possible for the CEO of the company to compromise a car.

• All code modifications must undergo extensive code review in a secure manner. (This means that reviewers must authenticate in a secure system.)
• All development tools such as compilers must be secured and reviewed. It is recommended that all tools be open source tools that undergo security audits for all changes.
• All software updates to vehicles must be signed by multiple distinct trusted parties, including possibly certain security consultants who are not directly beholden to company executives. This would be particularly true for emergency updates that must go over the air and can't use the physical update procedure derived above.
• Each car will have its own authentication keys which are kept highly secured. There should not be a "master key" which can change multiple cars. Master keys that exist will instead allow access to the vault in which the individual keys are kept. Access to the vault should be secured and logged and may possibly need to be direct and physical. Backups of the vault must be well protected. Sending an update to all cars will require that several executives of the company get together to use their keys to command the vault to generate signatures for the update for each car being updated.
• Privately owned cars may actually require a physical external token -- analogous to the modern car key -- before they will begin operations. That means before the car will start up and go to pick-up its master, it will request authentication from the token which will be in the master's possession and require some sort of physical confirmation. (Ie. you can summon your car with your phone but you must press confirm on your "key" for it to be able to start moving.) This authentication will be required by the lowest level drive-by-wire computers which can actuate throttle. The car will be unable to go somewhere without an authentication from the token. Token keys can be backed up but should be backed up with care.
• Fleet cars would also need authentication, but there it would have to come from a group server at fleet HQ. This server should be secured and monitored for unusual activity, but its operations would have to be more automatic, since fleet operations would want to be highly automated. Still, a physical re-authorization every so often could be a good idea.
• The car's internal OS should be a highly secure one. The use of Capability-based security is recommended. This can allow a less strict security procedure on segments of the system that are not given dangerous capabilities, and require higher scrutiny for systems which can control the motion of the vehicle.

As always, the difficulty with this architecture is the risk that mistakes will render cars inoperable because the tokens needed can't be obtained. Notoriously, most security systems end up blocking authorized use far too often, and they complicate UI. Avoiding this and securing 1500kg roving robots is the great challenge of this industry.

Hardware and OS choices

There are extensive documents and projects in the general area of computer security, and the full scope of that is well beyond the goal of this document. In general, hardware choice should include gear which is resistant to external attack and surveillance, including tempest attacks.

While generally the system will not talk to unknown outsiders or run their code, good security hygiene within the system is still important. More secure OS platforms, such as capability-based systems, should be considered. Only a very few software modules should have access to throttle, brake and steering. The same principle should apply at the HQS. Modules of the HQS which take in data from outside sources to sanitize it should be well isolated from modules which get to talk to the cars.

Incident Response

In spite of the best security efforts, there will be incidents. A plan should be in place to deal with incidents and mitigate them. In particular, it is important that any need to shutdown the fleet or a vehicle is very rare, since such a shutdown could destroy the value of the system to the public. Rather, fallbacks which include human driving or "highly assisted" human driving, done with a different software system which is hard loaded in the car, can't easily be changed or remotely overridden and is well verified and stable should be possible. Detection of intrusion should be done by independently operating monitors, and a team should be ready to deal with problems.

Threat models

The most concerning threat model is an attack by a state or mob intelligence agency on a large number of cars: Cyberwar. One nation might seek to either cripple the other by shutting down all its cars, or just eroding trust in them. Or it might actively injure or kill people riding in cars or even on the road with cars. It could possibly kill millions.

Fortunately, most other parties aside from nation states at war don't wish to kill. Criminals just want to make money. They will like to disable cars in exchange for ransom. This technique will work best on fleets, but you could also find private car owners faced with a "Pay 1 bitcoin if you want your car to work today" ransomware.

A little more frightening, but less likely, is a car demanding money while it is driving, threatening to crash you if you don't pay. This is less likely because police and nations would react very strongly to this and put extreme effort into finding the perpetrators. You don't want them putting extreme effort into finding you.

People with fear of assassination may need more caution, though. In this case the attacker is motivated to kill you or those close to you. Those people may insist on even more secure cars -- all updates must be manual and confirmed, minimal interaction with HQ. Of course, switching to manual updates could leave you more vulnerable, not less.

I welcome comments and additional security rules. The threat model is severe -- a foreign intelligence agency, with the power to plant spies on the software team, wishes to be able to take over large numbers of cars and order them to commit mayhem or simply to shut down during time of conflict.