DSRC Security Project: Ensuring Reliable Vehicle Safety and Communication

1. DSRC Security Project,P1556 T. M. Kurihara TKstds Management TKurihara, TKstds Management

2. Scope • DSRC Security for lower layers consistent with ASTM E2213 DSRC and IEEE Standard 802.11 • DSRC Security for application layers that interfaces with lower layers • DSRC Security Risk Assessment and Counter-measures for ITS • Consistency with the National ITS Architecture, draft Version 5.0 • Consistency with IEEE 8021.11i and WEP Encryption Algorithm, as a minimum TKurihara, TKstds Management

3. Communication • Dual Sponsors in FHWA • Security and communications • ITS Standards • IEEE Sponsor - Standards Coordinating Committee 32, ITS • Consistency with industry, national, and international security requirements • Liaisons planned with NIST, ISO/IEC JTC 1 SC27, ISO TC204, IEEE 802.11 WG, ISOC/IETF, WEP,…. TKurihara, TKstds Management

4. DSRC Security - Important • Regardless of how good a technical solution we develop, without satisfactory (i.e., excellent) security vehicle OEMs, public safety service providers and others will not support standards, sponsor applications or install equipment • Without strong support from vehicle OEMs and others, 5.9 GHz DSRC is (probably) going nowhere • THEREFORE, security is a GIANT issue and requires high-level attention TKurihara, TKstds Management

5. Operational Requirements • Control Channel doesn’t use 802.11 MAC associations • 802.11i and WEP security features may be applied in service channel operations • Low impact on overhead • Limited decrease in processing speed • Small memory requirements • Support scalability, interoperability across North America • Interoperable with related standards, 5.9GHz Band plan, ITS physical and logical architecture, IP interface TKurihara, TKstds Management

6. Operational Requirements • Ability to implement on chip set/smart card for OBUs • Cannot rely on passwords, pass phrases, PINs, biometrics for OBUs • Driving a vehicle – safety first • Support vehicle speeds up to 120 mph • Support device to device distances up to 1000m • Maintain applications sessions and authentication through intermittent contact with multiple RSUs along route of travel • Establishment of “Trust Chains” TKurihara, TKstds Management

7. Requirements • Low cost • Proven technology • security community validation, acceptance • Significant successful industry implementations • Availability • Non-proprietary solutions preferred TKurihara, TKstds Management

8. Risks • Wireless Threats • Individual or group with possession of RSU equipment and ill intent and medium capability • Individual with possession of OBU with ill intent and medium capability • Individual with jamming capability and ill intent • Wireless Vulnerabilities • Denial of Service • Identity theft, masquerading • Leads to unauthorized access, compromised confidentiality • Eavesdropping • Compromises confidentiality • Threat + Vulnerability = Risk • Based on probability determined by capability + intent TKurihara, TKstds Management

9. Vehicle Security Risks • Results drive detailed security requirements • Need for two-factor authentication vs. single factor • Need for non-repudiation or not • Need for message integrity • Confidentiality – key strength • Formal risk assessment to be funded • Requirements under definition • Start September 2003 TKurihara, TKstds Management

10. Preliminary Derived Security Requirements • Integrity • Control channel messages, OBU messages in upper layers • Confidentiality – data • Availability • Authentication • One-way authentication, either direction • Anonymity • Random number generator for MAC Address • Tied to authentication • Access control • To channel 184 • From control channel to service channels • Access Control Lists (ACLs) TKurihara, TKstds Management

11. Room for Improvement • Stronger Access Control • Mutual (Two-way) Authentication • Flexibility • To support range of security requirements • Mobile Security • Strong Confidentiality • Scalability • Some applications may require more rapid and secure re-authentication in transit TKurihara, TKstds Management

12. Related Activities • IEEE 802.15 WG • Developing Personal Area Network standards for short distance wireless personal area networks (WPAN) of mobile devices - PCs, PDAs, peripherals, cell phones, pagers, and consumer electronics • http://ieee802.org/15/ • Zigbee Alliance • Non-profit industry alliance wireless standard activity; works with IEEE 802.15.4 • Requirements low-cost, interoperability of very small, very low-power devices in the 915MHz range; up to 75 meters • www.zigbee.com • Commercial Alternatives • LEAP, TLS, TTLS, PEAP TKurihara, TKstds Management

13. Approach • High-level guidance provided by WG • Application requirements generated by DSRC Security sub-group • Security solution developed and integrated by security experts • Solution quality and viability check performed by an independent evaluator • Creating and editing draft standard by IEEE TKurihara, TKstds Management

14. Security Standards Process 5.9GHz DSRC Security Committee Management and technical oversight management and technical oversight 5.9 GHz DSRC Security WG Requirements definition, solution identification Principal consultants step C step A step B results results results Independent Evaluators review review review results results results IEEE standards process IEEE WG Testing ARINC TKurihara, TKstds Management

15. High-Level Guidance • Ultimate oversight remains with the WG • Provide security task definitions • Approve security requirements • Receive regular progress reports throughout solution development, cross-check and integration activities. • Approve results • Set direction for standard development and approval of eventual standard TKurihara, TKstds Management

16. Application Requirements • Identify threats to ITS DSRC assets • Requirements-setting separated into safety and non-safety applications • Safety applications addresses threats against safety of life or property • Non-safety applications addresses threats common to e-commerce • VSCC to assume oversight of safety applications • Separate sub-group to address non-safety applications • Requirements merged to create a requirements envelope TKurihara, TKstds Management

17. Develop Security Solution • Expert(s) address both safety and non-safety areas • Main tasks are to: • Define threat model(s) • Describe constraints, e.g., cost, complexity, computational & communications overhead • Develop & integrate security solution(s) TKurihara, TKstds Management

18. Solution Audit • Assumption – No one has a lock on ‘best security solutions’ • Separate security expert(s) engaged to do independent assessment of proposed solution(s). • This evaluator responsible for regular reports to WG TKurihara, TKstds Management

19. Generate Standard • IEEE WG to oversee security standard development (i.e., with expert editor) • Editor conduct sense-check of the proposed solution and embed it into a draft security standard using accepted security tools, nomenclature, etc. • Editor is responsible to record WG consensus for draft standard content • Editor is responsible for addressing all comments received TKurihara, TKstds Management

20. DSRC Security Thomas M. Kurihara Chair, IEEE WG P1556, DSRC Security TKstds Management +1 703 516 9650 tkstds@mindspring.com TKurihara, TKstds Management

21. Supplemental Information • Options • Integrity • One-way Hash • Anonymity • Authentication • Confidentiality • Standards • Public Key Cryptography • IEEE 802.11i • IEEE 802.1x TKurihara, TKstds Management

22. Integrity • OBUs need to validate RSU message • Not altered during transmission • RSUs need to authenticate OBU message • Not altered during transmission • i.e., emergency vehicle validation • Potential Solution: one-way secure hash function • Must be collision-resistant • Must be “claw-free” (i.e., not susceptible to “birthday” attacks) • Provides processing improvement over digital signature and other asymmetric cryptographic operations • Up to 3 to 4 orders of magnitude TKurihara, TKstds Management

23. One-Way Secure Hash Options • SHA-1 • 160-bit output (FIPS 180-1) • 20-byte overhead • 80 processing steps • Robust algorithm with greatest life cycle • Permits digital signature • Permits one-way, non-interactive public keying • Permits usage in electronic commerce • NIST Recommended TKurihara, TKstds Management

24. One-Way Secure Hash Options • MD5 • 128 bit (RFC1321) • 16 bytes overhead • Faster to process • FIPS pub 198 specifies a Hash Message Authentication Code – HMAC, constructed from a hash function vs. a block cipher algorithm • May be more convenient to implement block cipher than hash code TKurihara, TKstds Management

25. Anonymity Options • Anonymous User Digital Certificates • Allows authorization without user identity information • No user identity information on certificate • Separate certificate issued for user authentication • Contains user identity information • Both certificates contain a user’s public key • Ultra Information Systems Anonymous Key Technology v1.0 • AES Validated Implementation • Anonymity based on biometric identification • Biometric template, i.e., fingerprint or other, passed vs. any identification data • Difficult to distribute and manage biometric data TKurihara, TKstds Management

26. Authentication, Confidentiality, Integrity, Non-repudiation Options • PKI • Authentication – Digital signature, key pair match • Message integrity – Secure message hash • Non-repudiation – Digital signature (identity verified by trusted 3rd party) • Interoperability - Established key management infrastructure • Scalability – Public keys stored in public repository • Flexibility – Choice of Algorithms - Public Key, symmetric for encryption, digital signature, message hash TKurihara, TKstds Management

27. Confidentiality • Global Special Mobile (GSM) • Weak encryption, proprietary algorithm, slow • VPNs, VLANs • require excessive switching, does not address roaming, scaling issues • Broadcast Encryption • Designed to deny services to unauthorized receiver • DSRC safety applications need reverse of this approach – allow services to masses vs. denying to few TKurihara, TKstds Management

28. Confidentiality - AES • Draft NIST Special Publication 800-38b (Nov 5, 2002) • 44 implementations tested by NVLAP-Accredited Cryptographic Module Testing (CMT) Laboratories • Algorithm Validation list can be found at • http://csrc.nist.gov/cryptval/aes/aesval.html • Key Length Requirements • Encrypt using 128, 192, 256, bit keys • Decrypt in 128 bit block • http://csrc.nist.gov/encryption/aes/aesfact.html • Recommendation for Block Cipher Modes of Operation: The RMAC Authentication Code • http://csrc.nist.gov/publications/drafts.html • Provides data origin authentication and thus, data integrity • Thwarts: exhaustive key search, general forgery and extension forgery based on collision • Being implemented by Atheros (256 bit) TKurihara, TKstds Management

29. Anonymity • MAC Address Generation • Through Use of Random Number Generator • Recommend one of, or all Four FIPS-Approved Methods • Deterministic Generators • FIPS 186 (DSS) Appendices 3.1 and 3.2 • ANSI X9.31 Appendix A.2.4 • ANSI X9.62-1998 Annex A.4 • Recommend Following NIST ITL Bulletin: Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications; December 2000 • Provides a package of 16 tests that were developed to test the randomness of binary sequences produced by random or pseudorandom number generators. (Described in NIST SP 800-22) TKurihara, TKstds Management

30. Standard Specifications for Public-Key Cryptography (IEEE Std 1363) • Developing standard public-key cryptography standards • Digital signature and key establishment schemes based on : • RSA – PKCS#1, • Digital Signature Algorithm (DSA) - FIPS 186-2 • ANSI X9.31 banking standard for RSA signatures require min 1024 bits for an minimum level of security • Elliptic Curve Cryptography (ECC) • ECDSA - ANSI X9.62, 2 • Offers lower latency by using shorter key lengths • Variety of key lengths available • ECC used in many wireless applications and devices • PDAs, Mobile phones, etc • Lattice-Based Public-Key Cryptography • Encryption (e.g. NTRU) and digital signature (e.g. NSS) schemes • Others TKurihara, TKstds Management

31. IEEE 802.11i Security (1 of 3) • 802.11i – 802.1x authentication + AES-based protection + enhanced key management • Robust Security Network (RSN) • Port-based network access control • Restricts network connection to authorized entities via 802.1x • Network port is an association between the access point and a station • Based on 802.1x • 802.1x • Employs the Extensible Authentication Protocol (EAP) • Uses Challenge-Response • No integrity or privacy features provided • No message authentication • “An Initial Security Analysis of the IEE 802.1x Standard” • http://www.cs.umd.edu/~waa/1x.pdf TKurihara, TKstds Management

32. IEEE 802.11 Security (2 of 3) • Provides four cryptographic algorithms to protect data traffic • Two based on RC4 - WEP,TKIP • Two are based on AES – WRAP, CCMP • A means is provided for stations to select the algorithm to be used for a given association • In an IBSS each STA defines, implements its own security model • Each STA must trust the other STAs security model if compatible with its own • STA must be prepared for other STAs to initiate communications • STA in an IBSS can negotiate the security algorithms it desires to use when it accepts an association initiated by another station • In an ESS the AP enforces a uniform security model • STA initiates all associations • The AP always chooses the security suite being used TKurihara, TKstds Management

33. IEEE 802.11 Security (3 of 3) • The Temporal Key Integrity Protocol (TKIP) is a cipher suite enhancing the WEP protocol on pre-RSN hardware • This protocol uses WEP TKIP surrounds WEP with new algorithms • CCMP shall be mandatory-to-implement in all IEEE 802.11 equipment claiming RSN compliance • Implementation of TKIP and WRAP optional for RSN compliance • Pre-RSN devices may be patched to implement TKIP, to interoperate with RSN-compliant devices that also implement TKIP • Use of any of the privacy algorithms depends on local policies TKurihara, TKstds Management

34. IEEE 802.1x Features • Open- System • Shared key authentication • Mandatory Access Control (MAC) access control lists • One-way authentication • Extensible Authentication Protocol (EAP) • Based on Challenge-response • Device to access point • Encryption optional • Authentication • Lack of message authentication • Entity authentication is via an open-system, shared-key • Access Control Lists • Medium Access Control (MAC) address-based • Lack of state machine synchronization TKurihara, TKstds Management

35. IEEE 802.1x Features Pros/Cons • Pros • Provides encryption • Provides authentication • one-way – client authenticated to access point • Cons • Susceptible to session hijacking • Susceptible to “man-in-the-middle” attacks • Vulnerable to: • Session Hi-jacking • Man-in-the-middle attacks • Denial of service attacks TKurihara, TKstds Management

36. IEEE 802.1x Summary (1 of 2) • Port Access Entity operates the Algorithms and Protocols associated with the authentication mechanisms for a given port of the system • Supplicant PAE • In the Supplicant role, the PAE is responsible for responding to requests from an Authenticator for information that will establish its credentials  TKurihara, TKstds Management

37. IEEE 802.1x Summary (2 of 2) • Authenticator PAE • Controls the authorized/unauthorized stat of its controlled port • EAP Authentication • STAs mutually authenticate to APs to detect and prevent replay attacks. • Both the AP and STA block general 802.11 data packets to allow only 802.1X EAP packets. TKurihara, TKstds Management