CAMP CA Design

1. CAMP CA Design William Whyte, Andre Weimerskirch 1609 meeting, Annapolis, September 2011

2. Start with the conclusion • Using 1609.2 certificates • Lots of certs per vehicle • One set of short-lived (~ 5 mins), 1 set of long-lived (~1 year) • One cert from each set valid at any time (except for short overlap periods) • Download lots of certs infrequently; most of those certs are encrypted; decrypt the next “batch” of certs periodically • Certs contain a linkage value • Linkage value is not linkable by eavesdropper • Revoke cert by publishing a linkage seed • The linkage seed allows anyone to linking linkage values from the revoked OBE in future • No linkage in the past • Linkage values are calculated by 2+ linkage authorities such that at least two of (CA, RA, LA1, LA2) must collude to track a vehicle • “Butterfly keys” allow a vehicle to submit a single public key in a request and receive arbitrarily large set of distinct certs in response • Preserves the property that authorities cannot track vehicle without collusion

3. Privacy and personal data protection • Basic principle: A person shall not have their personal data processed without their consent • ITS carries personal data both directly and indirectly in all its variants: • Protocol stack offers data • Time, location (on the network) • Application offers data • Action (may also give time and location (geographic)) • Will I get an automated speeding ticket? • Will I get caught going to that motel when I said I was working late?

4. Pseudonymity requirements • Messages should not allow an eavesdropper to identify the sender • Message must not contain a link to a long-term driver or vehicle identifier • Messages should not allow an eavesdropper to know that a specific vehicle has followed a particular path, or that a specific vehicle is coming • All identifiers associated with a particular message set (e.g. source address, certificate) must change simultaneously • “Identifier” = some string that the sender uses frequently (and, by implication other vehicles in the neighborhood use infrequently if at all) • BUT… • messages must still allow receivers to build up an accurate picture of road conditions around them • It must be possible to remove misbehaving units • Revocation requires identification of misbehaving vehicles, thus discarding privacy of those vehicles

5. Certificates • Certificates are identifiers in the sense of being frequently used: they or their hash are attached to each BSM • Certs must change • But certs must also be issued in advance by a CA, rather than being chosen locally by the device as with other identifiers

6. Privacy mechanisms for certificates (pseudonyms) • Shared pseudonyms • Each vehicle is given k pseudonyms from a pool of N • Pseudonyms are shared • Even the Authority can’t associate a pseudonym with a specific vehicle • Vehicles rotate through their pseudonym list, reusing as necessary • If a vehicle requests new certificates a lot it is called in for inspection • Drawback: • One misbehaving vehicle impacts many • Does not scale • Many pseudonyms • Many pseudonyms on a single vehicle, not shared • Vehicle rotates pseudonyms, does not reuse • Drawbacks: • High storage requirements if pseudonyms are rotated frequently • A lot of pseudonyms to revoke if vehicle misbehaves – need a way to link vehicles • Research consensus favors the many pseudonyms approach

7. Many pseudonyms • Sybil attacks: if a vehicle has a lot of certs and someone compromises it, can they pretend to be a lot of vehicles? • Implications: • Vehicles should have a small number of certs valid at any one time • Certs need a lifetime • Lifetime needs to be sufficiently short that a vehicle will change identifier at least once in a trip • Vehicle needs a lot of certs! • Must have storage for certs • Must be able to download enough certs • To ensure non-repudiation the device must generate its private keys itself when applying for new certificates • Non-repudiation = “don’t get the CA blamed for compromise” • Consequences: • Computational burden when generating keys • Potentially large cert request messages when uploading request

8. Proposal • Two sets of certs • Short-lived certs: change every X minutes / seconds with short overlap • Fallback certs: last for a year or a month • Vehicle gets (say) 1 year’s worth of short-lived certs, 1 fallback cert that lasts for a year • Applies for new short-lived certs (say) 1 month before end of year • If it is offline for that whole month, when it wakes up it can use the fallback cert until it obtains more short-lived certs. • Fallback cert gives reduced privacy but still allows operations

9. Certificates and Fall-back Certificates (1) • Global parameters (might change over time): • Validity of short-term certificate: t_shortTerm: 5 minutes • Validity of fall-back certificate: t_fallBack: 3 years • Overlap of certificates: t_overlap: 30 seconds • Batch size for short-term certificates: t_batch: 1 year • Maximum time for loading new short-term certificates: t_reLoad_shortTerm: 1 month • Maximum time for loading new fall-back certificate(s): t_reLoad_fallBack: 1 year + 1 month • Time t: Initial Certificate Request (Month 0) • Load t_batch (1 year) worth of short-term certificates (116,800), starting at time t • Load one fall-back certificate valid for time t_fallBack (3 years) • Time t + t_batch – t_reLoad_shortTerm (Month 11) or later: • Load t_batch (1 year) worth of certificates (RA makes sure that first certificate fits seamlessly) • Time t + 2 * t_batch – t_reLoad_shortTerm (Month 23) (= t + t_fallBack – t_reLoad_fallBack) or later: • Load t_batch (1 year) worth of certificates • Load one fall-back certificate, with validity starting at Month t + t_fallBack – t_overlap (36 months – 30 seconds) • Now repeat

10. Certificates and Fall-back Certificates (2) • Never more than 4 certificates valid at any time • 3 certificates (2 short-term certificates and 1 fall-back certificate) valid in overlap time (30 seconds of each 5 minute interval – t_overlap out of t_shortTerm) • 4 certificates valid in overlap time of the two fall-back certificates (30 seconds per 3 year period t_overlap out of t_fallBack) • Worst case: run out of certificates after 13 months without access to CA (t_reLoad_fallBack) • Alternative: • Time t: load two fall-back certificates with validity Months (i) 0-35, (ii) 36-71 (overlap of 30 seconds) • Month 35: load new fall-back certificate with validity Months 72-107 • Pros: Better worst case behavior • Worst case: run out of certificates after 37 months without access to CA • Cons: CRL size doubles • Single CRL entry has two values: • one for short-term certificates: can be removed after, say, one month • One for fall-back certificate: validity of issued fall-back certificates dominates size of CRL

11. Mechanisms for removal • Two mechanisms: • Certificate revocation list (CRL) distribution • Issue short-lived certificates and do not reissue to misbehaving nodes • First is suited for certificate holders that cannot communicate regularly with the CA (for new certificates) • Vehicles without data connection – probably most of them initially • But CRLs may be big! 10+ million vehicles go out of service per year • Second is suited for certificate holders that are generally online • Vehicles with cellular connection – may be rare • Vehicles with data connection over 5.9 GHz (e.g. at gas station) – may be rare • Vehicles with dual-mode connection including WiFi – may be rare • Need to start with a system that supports CRLs, can migrate towards a short-lived cert system as connectivity improves

12. Combine frequent reissue with revocation using encrypted batches • Proposal: • Vehicles receive certs for time T1, but these certs are split into successive batches lasting for time T2 < T1 • e.g. T1 = 1 year, T2 = 1 month • Each batch is encrypted with a symmetric key unique to the batch • The OBE requests and receives (from the CA) the symmetric key for a particular batch shortly before it starts using the certs from that batch • e.g. 1 week before the start of the month • If the OBE does not get a symmetric key in time, it uses its fallback cert • One large download every year, one small exchange every month • It may be possible to obtain keys during a high-speed RSE transaction, it won’t be possible to get certs • Motivation: reduce size of CRL – if a cert holder is known not to have the current decryption key they can be removed from the CRL • If everyone stays on the CRL for a year, it’s 12 times larger than if they all stay for a month • Note that fallback certs will need to be on revocation list for their whole lifetime, so best we can do is reduce the size of the short-lived certs part of the CRL

13. Allowing “efficient” revocation with privacy • If a vehicle has a lot of certs, how do they go on the revocation list? • Five-minute certs = 100,000 per year • 20 million vehicles out of service – how many revoked? • BIG CRLs • Can we revoke all 100,000 certs with a single CRL entry? • Solution: a given vehicle’s certs have a cert identifier ID_i • Seed_i = hash (Seed_(i-1), k) • ID_i = hash (Seed_i) • k is a secret key • To revoke, publish Seed_i, i, k and let recipients calculate future IDs • (Rescorla, Kelsey et al; subsequently rediscovered)

14. Privacy against CA • When I apply for a cert, I need to tell the CA where to return the cert to • CA knows which unit has which cert • Insider at CA can track vehicles • How do we address this?

15. PKI Overview • RA acts as anonymizer proxy: collect OBE requests (set of certificates) and forward individual certificate requests from random OBE to CA. • RA also adds another layer of encryption: encrypts blocks of certificates and provides decryption key upon request by OBE. • CA issues certificates without knowing which certificate is for which OBE.

16. CA + RA • OBE encrypts request for CA, signs encrypted request, sends to RA • RA approves request, sends to CA • CA decrypts request, signs cert, encrypts for OBE, returns to RA • RA returns to OBE • CA knows cert but not who has it; RA knows who has it but not what’s inside it. • Proposed by Telcordia (Zhang, Di Crescenzo) for VII Proof of Concept Request V RA CA Request Request Cert Response Response Cert Cert

17. Batching Cert request V Request Request Request Response Request Request RA Request CA V Request Request Request Response Request Response Request Response Cert Response Response Revocation Check CRL CA Report

18. CA + RA • Privacy enhancements for multiple certs per vehicle per request • If RA “batches” requests from different vehicles and submits them to the CA at the same time, CA does not know for certain which cert went to which vehicle • If there are multiple CAs, and RA submits some requests to CA 1 and some to CA 2, etc, then no individual CA knows all the certs belonging to a vehicle • Can look on the RA as an anonymizing router from vehicle to CA that authenticates vehicle’s request

19. Linkage values • A set of values CertIDi(s) generated by a private function f(s, i) such that • If s is unknown it is impractical to test if CertIDi(s), CertIDj(s) were generated using the same f(s, *) • If s is known it is efficient to test if CertIDi(s), CertIDj(s) were generated using the same f(s, *) • If some function f’(s, i) is revealed, it is efficient to test matches for CertIDj(s) for all j > i and impractical to test matches for all j < i • When vehicle is revoked, CRL can contain f’(s, i) • This allows revocation of all future messages while preserving privacy on past messages • Outstanding issue: Who calculates f(s, i)? CertIDi

20. Basic linkage value function • Basic idea (originally proposed by Eric Rescorla, John Kelsey, & others for VSCC) • Define s(i) = hash (s(i-1)) • Define s(0) = random seed • Define CertId(i = AESs(i)(0), truncated to (say) 12 bytes • Could be a hash but AES is faster • Properties: • Publish s(i) to revoke all certs from period i on • Does not allow linking of messages from before revocation date • Properties: • Publish s(i) to revoke all certs from period i on • Does not allow linking of messages from before revocation date CertIDi

21. Efficient linkage value function • Issue with previous idea: if a vehicle is asleep for 6 months it may have to do 100,000 calculations per entry to catch up with current linkage values • Hashes are fast but not entirely free • More efficient modification below • Express i, number of elapsed five-minute time periods, as • (number of days * i) + (number of five-minute periods so far today, j) • Redefining i • Max(j) = 288 • Define s(i, j) = hash (s(i, j-1)) • Define s(i, 0) = hash (s(i-1, 0) || 0) • Define s(0, 0) = random seed • Define CertId(i, j) = AESs(i,j)(0), truncated to (say) 12 bytes • Security properties • Publish s(i, 0) to revoke all certs from day i on • If necessary, pubish s(i, j) and s(i+1, 0) to revoke all certs from period (i, j) on • Does not allow linking of messages from before revocation date • Performance properties: can catch up after sleeping for 200 days in 200 hashes, not 200*288 • Better! • Outstanding issue: Who calculates f(s, i)? CertIDi

22. Linkage values: who calculates them? • Calculated by vehicle • How are we guaranteed that vehicle has calculated honestly? • Possible solution = “cut & choose” but large overhead in message exchanges • Calculated by RA • Now RA knows identity of requester + linkage values in cert • Possible solution: CA applies additional transform to CertIDi but: • Either CA needs to apply vehicle-specific transform  CA knows which vehicle has which cert • Or CA applies global transformation  first time it revokes any cert, transformation is public & RA can match • Calculated by CA • Now CA knows full set of CertIDs for a vehicle • The specific problem that “batching” was intended to address

23. PKI Overview • RA acts as anonymizer proxy: collect OBE requests (set of certificates) and forward individual certificate requests from random OBE to CA. • RA also adds another layer of encryption: encrypts blocks of certificates and provides decryption key upon request by OBE. • CA issues certificates without knowing which certificate is for which OBE.

24. Two-LA linkage value function • Each LA calculates its own series of CertIDs • s(i, j) = hash (s(i, j-1)) • s(i, 0) = hash (s(i-1, 0) || 0) • s(0, 0) = random seed • CertId(i, j) = AESs(i,j)(0) • Each LA encrypts the series for the CA and sends the encrypted series to the RA, each entry labeled with • w, the series it belongs to • (i, j), its location within the series • The RA sends the CA • The appropriate cert request • The encrypted CertIDs • (i, j) • But not w – supports privacy through batching. • For each cert Ci,j • The CA decrypts CertIDleft(i,j), CertIDright(i,j) • The CertID in the certificate Is CertIDleft(i,j), XOR CertIDright(i,j) • To revoke, publish the appropriate sleft(i,0), sright(i,0) • CRL recipients calculate the two hash chains and XOR the results • NB Each revoked cert = one double-length entry on the CRL • 32 bytes rather than 16 CertIDi

25. Bootstrap • Assume that all bootstrap activities take place in a secure environment • Creating an actual secure environment is out of scope

26. Certificate Request

27. Current Certificate Expiry

28. Revocation

29. escrypt Inc. - Embedded Security Cert request performance • How to balance security and performance requirements?

30. Butterfly keys: Overview and rationale • Requirements / nice-to-haves: • Would like non-repudiation (i.e. CA does not know the private key) • Would like to minimize calculation on the OBE • Car is in use only 5% of the time: we would rather not use CPU and battery to generate keys that will not be used • Would like to minimize upload size • Cert generation may take some time, especially with batching of requests; small uploads allow the OBE to generate and submit a request on a low-bandwidth data connection some time before it collects the certs over a high-bandwidth connection • Approach: • OBE generates a single keypair and creates an “expansion function” • Expansion function can be used to generate a keypair and add public keys together • RA can run the expansion function, OBE can confirm it was run correctly • CA receives expanded key, generates another ephemeral keypair, adds the public key to the public key it received and encrypts the cert and private key back to the OBE • RA does not know key in cert (blinded by CA) • Only OBE can generate the private key

31. Butterfly keys • OBE: • generates a single “caterpillar” signing keypair: a, A = aG and “caterpillar” encryption keypair: h, H = hG • creates two globally unique functions fs(i), fe(i) • for example, encrypt (i, i XOR 1128) with a specific AES key ks (respke) • sends A, E, descriptions of fs and fe to the RA • RA approves request • For each cert to be requested, RA: • Generates “cocooned” signing public key, Bi = A + fs(i) * G and “cocooned” encryption public key, Li = H + fe(i) * G • Sends the request to the CA • For each request • CA creates “butterfly” signing public key Ci = Bi + ci*G for random ci. • Creates and signs Certi, the cert containing Ci, • Encrypts (Certi, ci) with Li • Signs ciphertext to demonstrate that it was encrypted (a) by CA (b) with OBE’s key • Prevents MITM attack • CA returns ciphertext to RA; RA includes i, returns response to OBE • OBE, and only OBE, knows private key for Ci = a + fs(i) + ci. • OBE and only OBE knows private decryption key (similar argument) in encrypted response only known to OBE OBE knows f, can calculate this

33. Spare slides

34. ECQV Implicit certificates • CA has key (q, Q) • User generates ephemeral key (a, A), sends to CA with cert information I • I is non-cryptographic information, ie does not include public key • CA generates ephemeral key (d, D), and: • Calculates • B = A + D • h = hash (I || B) • s = h*d + q • Standard Schnorr/ElGamal-like trick: h is known, but every possible d has a corresponding possible q • Sends (B, s) to user • User calculates private key c = s + hash(I||B) * a • h*a + h*d + q • Corresponding public key is C = hash (I||B) * B + Q • h*A + h*D + Q • When sending a signed message, user attaches the “implicit” cert [I, B]; verifier uses cert to obtain public key and verify

35. Properties of implicit certificates • Only user knows private key a • Only CA can create valid implicit cert due to commitment to q • Implicit cert does not include a signature, just B • Saves 2*(field size) space = 64 bytes for 256-bit signatures • By using “Shamir’s trick”, obtaining public key + verification can be done in a single step taking about as long as a single verification • verification formula aX + bY becomes aX + bY + cZ • works for an entire cert chain • investigating whether Kravitz and Brown’s attack (ECC 2011) is effective • Saves time and reduces message size • Safety-of-life messages are time-critical, received from unknown sources, and sent over a lossy channel • Match of requirements to properties • Hardware acceleration may still be useful – TBD • Implicit certs are being used in the current field trials, will probably be the default technology going forward