Advances in Blockchain could contribute to automotive cyber security

Advances in Blockchain could contribute to automotive cyber security

The Lightning Network could make a real contribution to automotive cyber security, whether planes, trains or any vehicle the potential for blockchain technology to have a role is being explored across the globe. Mercedes and BMW have both recently advertised roles to explore its potential. 

Whilst a distributed, decentralised and dis-intermediated network is fantastic for security and well understood in the context of an open ledger, it depends on the number of nodes; the more nodes the better the potential security is. 

Concerns have thus far been raised as to the overhead for blockchain maintenance in terms of processing, energy consumption and data storage requirements. Lightning maybe a game changer – Lightning-fast blockchain token exchange without worrying about block confirmation times. Security is enforced by blockchain smart-contracts without creating a on-blockchain transaction for individual payments. Payment speed measured in milliseconds to seconds!

By transacting and settling off-blockchain, the Lightning Network potentially allows for exceptionally low overhead, which allows for emerging use cases such as instant micro-token exchanges. As a result, it is possible to conduct transactions off-blockchain without limitations. Transactions can be made off-chain with confidence of on-blockchain enforceability.

There are millions of connected vehicles across the globe, each one a potential node. Each vehicle has an increasing number of ECU nodes onboard, so the potential for a super-secure decentralised and distributed  network is clear. Lighting could make this possible.

As vehicles interact with Intelligence Transport Systems and increase their off-board processing capability as well as exploiting Transport Telematics, the necessity for trusted (authenticated) network participants with trusted traffic-data and content (integrity) whilst respecting privacy (controlling its’ availability) will make a significant contribution to a public acceptance test for autonomous systems. Add in an audit record and you are starting to construct a secure environment. When you factor in over-the-air software and firmware updates and counterfeit hardware countermeasures, prognostics , diagnostics and service schedules with the need for any vehicle to interact with services (e.g. EV recharge, motor lubricants and even insurance and smart tolling) you have a potential new eco-system. A market where the vehicle user has a stake and a commodity to exchange value with both humans and machines.

Additionally the token could be a safety critical token and a millisecond exchange starts to make blockchain technology a possibility for high integrity systems where fail-operational, fail-safe now must include fail-secure.

EP90group Ltd is actively researching smart contract blockchain deployments in vehicles, interested? get in touch – .

Attacker-in-the loop

Attacker-in-the loop

Attacker-in-the-loop (AIL) is the logical integration of security into the development lifecycle of embedded systems, specifically in the context of connected and autonomous vehicles. It is equally valid across the wider IOT domain.

If ‘security’ is protecting the vehicle from its environment, and ‘safety’ is protecting the environment from the vehicle (and / or human), the traditional ‘V’ or ‘V plus’ model of feature and system development and integration can be augmented throughout with security and safety considerations – an additional loop of requirement capture and solution provision at each stage.

In light of the infamous and well publicised ‘hacks’ of OEM, Tier 1 and tier 2 equipment to the auto-industry, the well articulated issues of automotive cyber security are increasingly in our consciousness. If not a direct or indirect safety issue, the reputational and brand damage that this can cause is a major concern. 

As the design and development engineer will typically start with a requirement specification with increasing detail from Model-in-the-loop (MIL) and Software-in-the-loop (SIL) the overlay of AIL at each stage from professionals will assist in the secure by design requirements being captured. As hardware is incrementally added in the loop through component, sub system and whole vehicle integration; AIL testing  can validate and verify appropriate tests to provide assurance that known and identified issues can be managed through the product lifecycle development in increasingly complex whole vehicle systems.

Significant detail is required to establish specific tests with which AIL can be executed, indeed AIL requires a foundational research with which to establish a methodological approach that is appropriate for a dynamic and evolving threat catalogues. It has to be capable of handling legacy system integration as well as future architecture and technologies. This foundational research is being undertaken at WMG, The University of Warwick a a UK Engineering and Physical Sciences research council grant.

To kick it off, what do you think about the notion of AIL? How does it feel like it could fit with ISO 26262, AutoSPICE and ASIL levels?