Part 2: The Porsche-XAIN Vehicle Blockchain Network

October 2018

We’re back with part two of the Porsche-XAIN Vehicle Network’s technical overview. Last time we looked at five innovations for Porsche vehicles made possible by XAIN’s use of blockchain technology.

This article will uncover five more cases of how blockchain technology can fuel innovation in automobiles.

Before we get started, let’s remind ourselves what part one’s first five innovations of the Porsche-XAIN vehicle network were:

  1. General Setup and History
  2. Overview of XAIN Blockchain
  3. System Architecture: Vehicle Network and System Components
  4. Smart Contract Architecture
  5. Access Control and Key Management

Feeling refreshed? Get ready for what part two holds.

6. Direct Connector via Bluetooth Low Energy (BLE)

This section will describe the pertinent steps of communication protocols, illustrated in the figures below, which consist of general process flow and the corresponding subparts. The owner can communicate using the smartphone application, which is encrypted via BLE with their vehicle. Currently, opening and closing the vehicle, and opening the trunk are actions that are available. Here is how this works: Both the user and the vehicle have two private key types. One key is used for encrypted communication via BLE, here called KeyType1, and the other key (Type 2) is again only used for signing transactions and messages.

So, how does the transfer protocol turn requests into actions? Well, the user connects to the vehicle securely via the smartphone application, and both the smartphone application and the vehicle exchange their Type1 public keys.

Upon receiving the Type1 public key of the user, the vehicle checks whether the key is contained in the user register smart contract. However, the Type1 public key is not contained in the smart contract, but rather only the SHA3 hash of this key is. If the Type1 public key exists, the smart contract returns the XAIN network address of the user, which is the shortened SHA3 hash of Type2 public key. After this has taken place, a random nonce is generated and sent back encrypted to the smartphone application with the Type1 private key of the vehicle and with the Type1 public key of the user. The creation of a random nonce is used to prevent replay attacks.

In the smartphone application, the random nonce is decrypted with the Type1 private key, incremented by 1, encrypted with the Type1 public key, and sent back to the vehicle along with a timestamp and the selected actions (e.g. a request to open the vehicle). Both the action and the timestamp are signed with the Type2 private key of the user. First, the vehicle checks to see if the nonce has been successfully increased by 1. Next, it verifies whether the signature of the requested action matches that of the user’s XAIN network address. Lastly, it is verified whether the timestamp is within the specified time interval and whether the user is authorized to perform this action. The verification of the authorization is technically realized by a call to the VehicleState smart contract. The outcome of that verification activity is then recorded via a transaction (signed with the Type 2 private key of the vehicle) in the smart contract.

The so-called “Eventual Consistency” property of the Blockchain makes these actions available even when the vehicle is not connected to the Internet. However, there are restrictions on the validity of third-party permissions in such circumstances, which will be discussed in the following section.

7. Remote Control

Certain actions, like opening and closing the vehicle, opening the trunk, and assigning or withdrawing authorizations, can also be carried out remotely via the smartphone application.

The smartphone application communicates via the Web3 module with the distributed clients. Upon the user selecting an action through the application, a transaction with the selected action is created and signed with the user’s private key on the smartphone. After signing, the transaction is sent to the nodes in the network.

In order to ensure that past actions or actions planned for the future are not performed at present, the “Open,” “Close the vehicle,” and “Open the trunk” actions are all timestamped. Though the authorizations may refer to the future, their validity is limited in time. The validity depends on the difference between the last synchronization of the Blockchain client and the network. If this difference is too large, permissions to third parties are also ignored for security reasons. The owner could have already long ago withdrawn a permission during this time. Only the owner themselves can open their vehicle at any time with the smartphone via BLE (without an Internet connection). The vehicle smart contract can be easily extended by further actions.

8. Secure Data Logging and Auditing

If the owner opens their vehicle, the public key responsible for encrypting the vehicle data is sent to the SBC via BLE. The SBC is connected to the vehicle via the CAN bus interface. The SBC logs the generated vehicle data once the engine starts. The logged vehicle data is stored in small files (chunks), encrypted on the data system of the SBC.

The data is encrypted with a symmetrical key, which is randomly generated by the vehicle. The symmetric key is then encrypted with the owner’s public key and attached to the file in the form of metadata. The data package (consisting of the encrypted vehicle data, the encrypted symmetric key and further metadata, such as the timestamp of the file) is then sent via the Whisper protocol V5 to the XAIN clients. As an identification of the data package, a SHA3 hash is formed via this data package and signed with the private key of the vehicle. The data package itself is encrypted with the public Whisper key of the AWS client. This public key is stored in a smart contract (a register for AWS clients connected to an IPFS node). Only these AWS clients can decrypt this data package. Public keys can only be added or removed by Porsche itself. As soon as an AWS client receives a data package, the sender’s signature is checked with the VehicleRegister.

If a vehicle with this address exists, the data package is stored in IPFS and the resulting multihash, signed with the private Whisper key of the AWS client, gets sent back to the sender. The multihash is subsequently stored by the SBC via a transaction in the UserHistory Contract of the owner. The AWS clients are stateless. If the SBC does not receive a response after a specified time interval, the data package is resent.

The time intervals can be freely selected. In Porsche’s live test drive, the chosen transmission interval was 2.5 seconds, which enabled us to follow the driven route via our smartphones almost in real time. For the streaming of data, the functions and possibilities of IPNS were used. It is interesting to note here that Swarm could be an alternative to IPFS / Whisper, but it was not used, because Swarm is still a very early stage of development. However, all system components are loosely coupled, which means that Swarm can easily replace the IPFS / Whisper system at a later stage.

The entire data logging case provides the network with the benefit of a very secure, flexible, immutable and, most importantly, GDPR-compliant means to collect valuable data. Data that can be used by Porsche for third-party integrations on the platform, as well as for a personal revenue stream on the basis of reports. One such example is a trusted car certificate that informs about the history of a vehicle, including not only information such as mileage but also past driving behavior, which can be used as a trusted certificate when re-selling the car. Furthermore, the data on its own is also highly valuable to Porsche itself when it comes to predictive maintenance and autonomous driving, both involving not just global models but also the locality of data.

9. Distributed Machine Learning for Autonomous Driving

The locality of data enables the advancement of autonomous driving using distributed machine learning networks, a technology that is a strategic focus of XAIN. To this end, Porsche distributes smaller local models trained by individual cars that can be used by the entire network, instead of building only a global model. Some manufacturers solve the problem of locality by collecting all personal data into central servers, which not only collides with various privacy regulations but is also quite inefficient, as huge amounts of data need to be sent into a single place. Global models by themselves, trained in clean environments like Stuttgart or Silicon Valley, lack the ability to react to very local problems, especially when considering extreme scenarios in India, for example, of cattle walking down the streets.

Porsche’s system prefers to follow the approach of building models locally in cars and then, using the security of the platform, distributing them as an additional feature alongside global models. It is in this war that the car can automatically decide whether or not to make use of such models when entering new regions. Instead of sending large data packages, this approach increases the efficiency of the network, as it allows us to only need to send inferences or the variances of inferences of models via the mobile network. As a result, the signatures are stored in the Blockchain to ensure that these inferences have neither been altered nor integrated from non-network participants to damage the ability of machine learning to support decision making. At its core, distributed machine learning via the XAIN Blockchain network leads to knowledge transfers instead of pure data transfers.

10. Third Party Integration

One of the system’s main features is its flexible use as a distributed app store for vehicle software by third parties. As soon as Porsche will have published its system, not only will third parties be able to access the Porsche system, but it will also allow the integration of third-party addresses in the user register smart contract. A third party only needs two private keys and an implementation of the BLE transmission protocol to communicate with the vehicle. If the owner of the vehicle allows a third party, like DHL, to access their vehicle data, further use cases are possible. For example, DHL can not only open the trunk but can then also determine the last location of the vehicle and thus deliver the package easily and quickly. Further use cases include telematic insurances, fleet management, electrical charging, and entertainment applications or over the air system updates in general.

In the case of telematic insurances, Allianz, for example, can ask the vehicle owner via the smartphone application whether it may access their vehicle data for a smart contract as a telematics insurance that evaluates driving behavior, such that the owner only pays per usage and pays less when exhibiting good driving behavior. If the owner agrees, the encrypted symmetric key used to encrypt the vehicle data is decrypted with the owner’s private key and then re-encrypted using the Allianz public key. Subsequently, this encrypted key will be sent to Allianz.

Ultimately, these selected use cases are just an extension of the underlying product’s wide range of capabilities. With the help of Blockchain technology, Porsche and XAIN have created a platform that makes it possible to safely communicate with the vehicle from the outside. The advantage of this platform is that it allows building applications without requiring their own security stack and or additional hardware. It is in this way that the connected car is brought to the level of a smartphone, where the user has constant and immediate access to the newest standards with a quick software update.