attestation architecture on the example of an automotive ... · pdf fileattestation...

Lecture Embedded System Security

Attestation ArchitectureOn the Example of an Automotive Platform

Prof. Dr.-Ing. Ahmad-Reza Sadeghi

System Security Lab

Technische Universität Darmstadt

Germany

Summer Term 2017

1

Introduction

• Large set of electronic control units (ECUs) in a car

• Most of those devices play key roles in safety-critical systems

• And the trend continues

• More driver assistance systems

• More connections to the outside world

• Eventually autonomous cars

• This makes an attractive target

Remote Exploitation of an Vehicle„Jeep Hack“

[Miller and Valasek, BlackHat USA ’15]

CAN: Controller Area Network, IPC: Interprocess Communication, GPS: Global Positioning System



Control over Infotainment• Radio• GPS• etcOverwrite CAN-Controller

1. Injecting IPC messages over the network






2. Reflash CAN-Controller with modified firmware






2. Reflash CAN-Controller with modified firmware

3. Send CAN messgaesto control the car


System Model

• Attestation is a protocol between a prover P and a verifier V

• P proves the integrity of its software to the verifier

• The verifier is a central unit

• Can be integrated into an existing component (e.g., immobilizer)

• Central security component must be properly protected

• Prover can be any embedded automotive controller

• Three classes of devices: Board Computer, Control Unit, Sensor

Functional Requirements

Title Description Priority

Availability The attestation mechanism must not infer significant overhead (e.g., execution time,

transmission time or response time) of embedded automotive controllers.

High

Low Overhead The implementation of the attestation mechanism should require only minimal

changes to existing embedded automotive controller architectures and the overall

system.

Med

Accountability The history of system states (including device identifiers, device configurations and

software versions used) and partial system states should be recorded.

High

Upgradeability Legitimate changes to the system state (e.g., firmware, software and hardware

updates/upgrades) should be possible.

High

Vehicle Binding Automotive controllers should be bound to the vehicle they are integrated. High

Backwards Compatibility Backwards compatibility of new components to older ones must be ensured. Low

Anti-counterfeiting The verifier should be able to detect non-genuine embedded automotive controllers. High

Migratability It should be possible to introduce the attestation mechanisms in a step-by-step

fashion, i.e., attestation-enabled controllers should also work in a conventional

environment that does not yet support attestation.

Med

Extendability It must be possible to add additional controllers after the system has been deployed. Med

Security Requirements

Title Description Priority

Device Identification It should be infeasible for the adversary to copy or forge device identifiers of genuine

embedded automotive controllers.

High

Device Authentication It should be infeasible for the adversary to impersonate a genuine embedded

automotive controller.

High

Software Integrity It should be infeasible for the adversary to modify the firmware or software of an

embedded automotive controller without being detected by the verifier.

High

Hardware Integrity It should be infeasible for the adversary to modify the embedded automotive

controller hardware without being detected by the verifier.

Low

Version Rollback

Protection

It should be infeasible for the adversary to install an older firmware or software

version than the latest version on automotive embedded controllers.

Low

Secure Storage It should be infeasible for the adversary to extract secret information (e.g.,

cryptographic secrets) from automotive embedded controllers.

High

Attestation

Attestation Requirements

• Authentication of Prover / Report

• Attestation must come from the correct prover

• Mechanism: Cryptography (MAC/Signature) or physical proximity

• Freshness of Attestation

• Attestation must reflect the current state of the prover

• Mechanism: Challenge-response with verifier chosen nonce

• Integrity of Attestation

• Ensure that the attestation report is generated correctly

• Mechanism: Isolated reporting component (e.g., TPM) or timing-based

Security Architectures

• Low-end device

• Minimal hardware extensions• SMART

• TrustLite

• Drive-domain devices:

• Minor hardware extension• TrustLite

• TyTAN

• High-end device(s)

• Co-processor based • Trusted Platform Module (TPM)

Setup

Board Computer

Sensor

Control Unit

Protocol Overview / Sub-Protocols

• Device production

• Devices are setup and certificates are issued

• Device integration / join

• Public key exchange

• Code certificate exchanged

• Shared secret

• Device attestation

• Attestation

• Session key distribution

Setup - Abstract

Board Computer SensorControl Unit

Join Protocol – Join of New Device

σM(pkV)pkV/skV pkM


• Install new device Di

i σM(ci)σM(pki)pki/ski

σM(pkV)pkV/skV pkMpkM



• Configuration (ci) certificated of Di send to verifier σM(ci)

• σM(ci) is signed by manufacturer M


σM(pkV)pkV/skV

σM(ci)pkMpkM





• Public keys and certificates of public keys are exchanged

• Verifier’s public key pkV and certificate σM(pkV)

• Device’s public key pki and certificate σM(pki)


pkV

σM(pkV)pkV/skV

pki

σM(ci)pkMpkM

σM(pki) σM(pkV)








• Verifier verifies σM(pki), device verifies σM(pkV)


pkV

σM(pkV)pkV/skV

pki

σM(ci)pkMpkM

σM(pki) σM(pkV)








• Verifier verifies σM(pki), device verifies σM(pkV)

• Shared-Secret based on own private key and counterpart’s public key

• Shared key (ki) between verifier and new device is established

i

ki

σM(ci)σM(pki)pki/ski

pkVki

σM(pkV)pkV/skV

pki

σM(ci)pkMpkM

σM(pki) σM(pkV)

Join Protocol – Component Reuse

• Di and verifier have established a shared key (ki)

i

ki


pkVki

σM(pkV)pkV/skV

pki

σM(ci)pkMpkM

σM(pki) σM(pkV)



i

ki


ki




• Di deletes it’s own secret key (plus public key and certificates)• it will never be able to join another car

i

kiki

σM(pkV)pkV/skV pkM



• Di deletes it’s own secret key (plus public key and certificates)• it will never be able to join another car

• To reuse a component in a legitimate way new keys and certificates need to be issued to the device

i

ki


ki


Attestation Protocol

• Verifier sends attestation request (R)• Including a nonce N

R



• Devices generate report (r)• HASH(N || memory state || ki)

rirj




• Devices send reports back to Verifier

ri, rj rirj




• Devices send reports back to Verifier• Verifier checks reports

ri, rj




• Devices send reports back to Verifier• Verifier checks reports• If ri for device Di is valid send session key S to Di

• Encrypted with ki

SSS

Authenticated Communication

• Dj authenticates message with session key S• HASH(msg || S)

AuthS(msg)

Authenticated Communication

• Dj authenticates message with session key S• HASH(msg || S)

• Authenticated message is send to Di

• Di validates authenticity of the message• Iff the message is authentic it is process• Otherwise it is ignored

AuthS(msg)

Conclusion

• The Integrity Self-verifying Car

• System architectures for embedded device need hardware support• TrustLite / TyTAN architectures for small devices

• Co-processor for high-end devices

• Attestation protocol is composed of two parts• Join protocol uses asymmetric cryptograph → High flexibility

• The attest protocol uses symmetric cryptography → High performance

attestation architecture on the example of an automotive ... · pdf fileattestation...

Documents