CAMP. Intelligent Transportation Systems. A Security Credential Management System for Vehicle-to-Vehicle Communications

Transcription

1 CAMP Vehicle Safety Communications 3 Intelligent Transportation Systems A Security Credential Management System for Vehicle-to-Vehicle Communications William Whyte (Security Innovation); André Weimerskirch (University of Michigan Transportation Research Institute); Virendra Kumar (Security Innovation); Thorsten Hehn (Volkswagen of America) (This material has been presented at IEEE VNC 2013) 1

2 BACKGROUND 2

3 Background 32,000 deaths on the road in the US in 2012 Significant reduction may be possible from V2V wireless communications for 360 o warning applications. 300 m range, derived medium access Basic Safety Message (BSM) Contains location, velocity, steering angle Transmitted up to 10x second Allows receiving unit to predict collisions and warn driver Prevent 80% of unimpaired 2-vehicle accidents 3

4 Basic Safety Message Spectrum reserved for these communications since 1999 Standards under development since 2003 selection of p MAC Field trials in Michigan, scalability analysis, driver acceptance clinics USDOT (NHTSA) currently considering mandating this system for inclusion in new light vehicles System benefit = p 2 where p is fraction of equipped vehicles, want p as large as possible Decision on mandate to be made 2014 Everything in this presentation is in that context this is the leading candidate for deployment, please review it! 4

5 Security considerations Risk of false messages Reduce users faith in system and cause warnings to be ignored (not safety-related): Messages may affect choice of route or have other mobility/efficiency impacts Requirement: must be able to detect untrustworthy senders or messages and let receivers know not to trust them Impact on privacy Don t want the system to be used as a tracking system Tracking is always possible, don t want this option to be the cheapest Prevent eavesdroppers or insiders from collecting Personally Identifiable Information (PII) Conflict with requirement to detect and remove untrustworthy senders 5

6 System considerations Design constraints Constraints on available data rate using current V2V system (6 MBps under ideal conditions) Cost-sensitive suppliers: limits on processing power, storage, connectivity, number of 5.9 GHz radios, 6

7 Authentication Messages are signed Signed using ECDSA over the NISTp256 curve bandwidth Vehicles are provisioned with three years worth of certs No requirement to verify all messages Message signing certificate specifies permissions (not identity) of holder Misbehaving units can have their certificates identified and revoked while preserving privacy as much as possible, see later Use different certs for different types of operation Security management, application A, application B 7

8 Protect privacy No personal information included in broadcast messages Prevent tracking: Identifiers at application, network and other levels should be transient Attack model: Eavesdropper can record some but not all messages Vehicles have k simultaneously valid BSM certificates, Dynamically choose which certificate to use to sign Baseline number of certs = 20 per week When cert changes, all other identifiers change too SCMS is split into a number of components No individual component knows the full set of certificates that belong to a single device Attack model: Eavesdropper can record some but not all messages and access database at a single SCMS component Policy means also possible Out of scope for this presentation (and CAMP) Vehicle Infrastructure Integration Consortium (VIIC) coordinates policy responses from OEMs 8

9 ARCHITECTURE 9

10 Overview / Standard PKI Hierarchy SCMS Manager Policy Technical Root CA Certification Services Intermediate CA Internal Blacklist Manager Misbehavior Authority Global Detection CRL Generator Enrollment CA Pseudonym CA Linkage Authority 1 Linkage Authority 2 CRL Store CRL Broadcast Request Coordination Registration Authority Device Config. Manager Location Obscurer Proxy Device 1 Device 2 Device 3 10

11 Lifecycle SCMS Manager Policy Technical Root CA Certification Services Intermediate CA Internal Blacklist Manager Misbehavior Authority Global Detection CRL Generator Enrollment CA Pseudonym CA Linkage Authority 1 Linkage Authority 2 CRL Store CRL Broadcast Request Coordination Registration Authority Device Config. Manager Location Obscurer Proxy Legend Intrinsically Central Not Intrinsically Central Device 1 Device 2 Device 3 Regular communication Out-of-band communication 11

12 CRYPTO 12

13 Features Implicit certificates Ability to change service providers per component Privacy against insiders when provisioning RA shuffle Certificate request: Butterfly keys Efficient privacy-preserving revocation: Linkage authorities and linkage values 13

14 Implicit certificates Signed using ECDSA over the NISTp256 curve with ECQV certs Implicit certs replace signature with public key reconstruction value Save 64 bytes per certificate Speed up the first verification of a certificate chain 14

15 Certificate Provisioning SCMS Manager Policy Technical Root CA Certification Services Intermediate CA Internal Blacklist Manager Misbehavior Authority Global Detection CRL Generator Enrollment CA Pseudonym CA Linkage Authority 1 Linkage Authority 2 CRL Store CRL Broadcast Request Coordination Registration Authority Device Config. Manager Location Obscurer Proxy Legend Device 1 Device 2 Device 3 Directly acts in this use case Provides information before execution 15

16 Shuffle at the RA RA receives requests from multiple end-entity devices Combines requests so that PCA doesn t know that two individual cert requests received at the same time come from the same vehicle Generate Requests EE1 EE2 (0, 0) (0, 1) (1, 0) {S 1} (i, j) (ima x, jma x) (0, 0) (0, 1) (1, 0) {S 2} (i, j) (ima x, jma x) RA Deliver shuffled elements to PCA PCA does not know which series the elements originally belonged to EE3 {S 2} (0, 0) (0, 1) (1, 0) (i, j) (ima x, jma x) (0, 1) (0, 0) (ima x, jma x) (i, j) (0, 1) (0, 1) (i, j) (0, 1) (1, 0) (ima x, jma x) (0, 0) (i, j) (0, 0) EE3 {S 2} (0, 0) (0, 1) (1, 0) (i, j) (ima x, jma x) (0, 0) (1, 0) (1, 0) (0, 0) (i, j) (ima x, jma x) EE kmax {S 2} (0, 0) (0, 1) (1, 0) (i, j) (ima x, jma x) (1, 0) (i, j) (0, 1) (1, 0) (ima x, jma x) (ima x, jma x) Shuffle 16

17 Butterfly keys Generating a lot of keys for requests is a pain at the OBE side It mightn t need all of them It needs to store the private keys Increases request size and risk that request doesn t make it through the network Can we do better? Yes, with seed key + expansion functions ECC: (a+b)g = ag + bg 17

18 Butterfly keys Device generates A seed or caterpillar keypair An expansion function Cost: ~1 key generation Expansion function: f(i,j) = AES k (i,j) AES k (I,j XOR ) Publish expansion function by publishing k Device a A 18

19 Butterfly keys: concept Device generates A seed or caterpillar keypair An expansion function Cost: ~1 key generation RA runs the expansion function to generate cocoon public keys from the caterpillar public key Cocoon public keys from the same caterpillar keys are not correlated Expansion function lets you generate arbitrarily many cocoon keys RA submits cocoon keys to CA for certification Private key b i,j = a + f(i,j) Public key Bi,j = A + f(i,j) G Device RA a A Expansion B1 B2 B3 Exp. Bn b1 bn 19

20 Butterfly keys: concept Device generates A seed or caterpillar keypair An expansion function Cost: ~1 key generation RA runs the expansion function to generate cocoon public keys from the caterpillar public key Cocoon public keys from the same caterpillar keys are not correlated Expansion function lets you generate arbitrarily many cocoon keys RA submits cocoon keys to CA for certification CA randomizes each public key separately so the RA can t recognize them Certs contain the resulting butterfly keys CA returns certs and private randomization values to the OBE Private key = a + f(i,j) + c Public key = A + f(i,j) G + C Device RA PCA a A Expansion B1 B2 B3 Cert c Exp. Bn b1 bn + Private key Cert 20

21 Butterfly keys: summary Large number of certs generated from a single initial keypair OBE is the only device that knows private keys Public keys cannot be correlated by any entity Low computational burden on OBE at request time Request once, generate keys for the entire lifetime of the vehicle 21

22 Revocation and Linkage Authorities Why do we need revocation? Why not just choose not to issue new certs to a misbehaving vehicle? Not all vehicles will have good data connection Even vehicles that do may be out of coverage Vehicles need to be provisioned with a minimum number of certs in case they are turned off for some time and turned on in an area with no coverage If you have a month s worth of certs, you can misbehave for a month If you have three months worth of certs, you can misbehave for three months If you have three years worth of certs Revocation must be supported to reduce potential disruption within system, even if in practice it isn t used. Need efficient, privacy-preserving revocation 22

23 Revocation and Linkage Authorities Public key info Permissions l(1) Cert (1) Revoke all n of a device s certs with just one entry on the CRL CA Auth. E k ( 1 ) E k ( 2 ) l(2) Cert (2) Cert (3) Multiple certs valid in one time period Backwards unlinkability k E k ( 3 ) E k (n) l(3) No component in the SCMS knows the chain Cert (n) l(n) 23

24 Revocation and Linkage Authorities l(1) Revoke all n of a device s certs with just one entry on the CRL Include linkage value l(i) = E k (i) in the cert k E k ( 1 ) E k ( 2 ) E k ( 3 ) E k (n) l(2) l(3) Include key k on CRL; in each time period i, vehicles calculate E k (i) for all entries and compare to the linkage value in the cert. l(n) 24

25 Revocation and Linkage Authorities E k ( 1 ) l(1) l(2) Revoke all n of a device s certs with just one entry on the CRL Multiple certs valid in one time period E k ( 2 ) k E k ( 3 ) l(3) E k (n) l(n) 25

26 Revocation and Linkage Authorities k E k (0,0) E k (0,j) E k (1,0) E k (1,j) E k (0,1) E k (1,1) l(0,0) l(0,2) l(0,j) E k (0,2) l(0, 1) l(1,0) l(1,2) l(1,j) E k (1,2) l(1, 1) Revoke all n of a device s certs with just one entry on the CRL Multiple certs valid in one time period E k (i max,0) E k (i max,1) l(imax,0) Ek (i E k (i max,j max ) max,2) 1) l(imax,2) l(imax,jmax) 26

27 Revocation and Linkage Authorities k E k (0,0) E k (0,j) E k (1,0) E k (1,j) E k (0,1) E k (1,1) l(0,0) l(0,2) l(0,j) E k (0,2) l(0, 1) l(1,0) l(1,2) l(1,j) E k (1,2) l(1, 1) Revoke all n of a device s certs with just one entry on the CRL Multiple certs valid in one time period Backwards unlinkability E k (i max,0) E k (i max,1) l(imax,0) Ek (i E k (i max,j max ) max,2) 1) l(imax,2) l(imax,jmax) 27

28 Revocation and Linkage Authorities k 0 Hash k 1 Hash k 2 E k0 (0) E k0 (j) E k1 (0) E k1 (j) E k0 (1) E k1 (1) E k0 (2) l(0,0) l(0,2) 1) l(0,j) E k1 (2) l(1,0) l(1,2) 1) l(1,j) Revoke all n of a device s certs with just one entry on the CRL Multiple certs valid in one time period Backwards unlinkability Hash k imax E k_imax (0) E k_imax (1) l(imax,0) E k_imax (2) l(imax,2) 1) E k_imax (j max ) l(imax,jmax) 28

29 Revocation and Linkage Authorities k 0 E k0 (0) E k0 (1) l(0,0) E k0 (2) l(0,2) 1) E k0 (j) l(0,j) Hash k 1 E k1 (0) E k1 (1) l(1,0) E k1 (2) l(1,2) 1) E k1 (j) l(1,j) Hash k 2 Hash k imax E k_imax (0) E k_imax (1) l(imax,0) E k_imax (2) l(imax,2) 1) E k_imax (j max ) l(imax,jmax) Revoke all n of a device s certs with just one entry on the CRL Multiple certs valid in one time period Backwards unlinkability No component in the SCMS knows the chain 29

30 Revocation and Linkage Authorities LA 1 k 0 k 1 k 2 k imax p(0,0) p(0,2) 1) p(0,j) p(1,0) p(1,2) 1) p(1,j) p(imax,0) p(imax,2) 1) p(imax,jmax ) LA 2 k 0 k 1 k 2 k imax p(0,0) p(0,2) 1) p(0,j) p(1,0) p(1,2) 1) p(1,j) p(imax,0) p(imax,2) 1) p(imax,jmax ) PCA l(0,0) l(0,1) l(0,2) l(0,j) l(1,0) l(1,2) l(1,1) l(1,j) l(imax,0) l(imax,1) l(imax,2) l(imax, jmax) Revoke all n of a device s certs with just one entry on the CRL Multiple certs valid in one time period Backwards unlinkability No component in the SCMS knows the chain LAs encrypt chain for PCA Send to RA RA groups, shuffles PCA decrypts, XORs 30

31 Revocation SCMS Manager Policy Technical Root CA Certification Services Enrollment CA Intermediate CA Pseudonym CA Internal Blacklist Manager Misbehavior Authority Global Detection 4 CRL Generator Linkage Authority 1 Linkage Authority 2 CRL Store CRL Broadcast Request Coordination Registration Authority 5 Device Config. Manager Location Obscurer Proxy Legend Device 1 Device 2 Device 3 Directly acts in this use case Provides information before execution 31

32 Real World Crypto Is the overall design good? Butterfly keys? Linkage authorities? Are we making the right tradeoffs? Privacy / security / complexity Subjects of ongoing projects: Misbehavior detection CRL distribution Organizational structure and relationship to USDOT WANTED IN THE NEXT TEN YEARS: Post-quantum signature scheme with short signatures 32

33 Questions? 33