September 2003 doc IEEE 802 11 -03 0784

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 DSRC Security Project, P 1556 T. M. Kurihara TKstds Management Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 Scope • DSRC Security for lower layers consistent with ASTM E 2213 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. 11 i and WEP Encryption Algorithm, as a minimum Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 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 SC 27, ISO TC 204, IEEE 802. 11 WG, ISOC/IETF, WEP, …. Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 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 Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 Operational Requirements • Control Channel doesn’t use 802. 11 MAC associations • 802. 11 i 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. 9 GHz Band plan, ITS physical and logical architecture, IP interface Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 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 1000 m • Maintain applications sessions and authentication through intermittent contact with multiple RSUs along route of travel – Establishment of “Trust Chains” Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 Requirements • Low cost • Proven technology – security community validation, acceptance • Significant successful industry implementations • Availability • Non-proprietary solutions preferred Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 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 Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 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 Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 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) Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 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 Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 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: //ieee 802. 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 915 MHz range; up to 75 meters • www. zigbee. com • Commercial Alternatives – LEAP, TLS, TTLS, PEAP Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 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 Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 Security Standards Process 5. 9 GHz DSRC Management and technical oversight management and technical oversight Security Committee 5. 9 GHz DSRC Security WG Principal consultants Requirements definition, solution identification step A results Independent Evaluators review results IEEE WG ARINC Submission step C step B results review results IEEE standards process Testing TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 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 Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 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 Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 Develop Security Solution • Expert(s) address both safety and nonsafety areas • Main tasks are to: – Define threat model(s) – Describe constraints, e. g. , cost, complexity, computational & communications overhead – Develop & integrate security solution(s) Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 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 Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 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 Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 DSRC Security Thomas M. Kurihara Chair, IEEE WG P 1556, DSRC Security TKstds Management +1 703 516 9650 tkstds@mindspring. com Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 Supplemental Information • Options – – – Integrity One-way Hash Anonymity Authentication Confidentiality • Standards – Public Key Cryptography – IEEE 802. 11 i – IEEE 802. 1 x Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 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 Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 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 Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 One-Way Secure Hash Options • MD 5 – 128 bit (RFC 1321) – 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 Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 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 v 1. 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 Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 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 3 rd 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 Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 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 Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 Confidentiality - AES • Draft NIST Special Publication 800 -38 b (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/aesval. html • Key Length Requirements – Encrypt using 128, 192, 256, bit keys – Decrypt in 128 bit block – http: //csrc. nist. gov/encryption/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 Submission

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 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 X 9. 31 Appendix A. 2. 4 • ANSI X 9. 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) Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 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 X 9. 31 banking standard for RSA signatures require min 1024 bits for an minimum level of security • Elliptic Curve Cryptography (ECC) – – ECDSA - ANSI X 9. 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 Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 IEEE 802. 11 i Security (1 of 3) • 802. 11 i – 802. 1 x authentication + AES-based protection + enhanced key management • Robust Security Network (RSN) – Port-based network access control • Restricts network connection to authorized entities via 802. 1 x • Network port is an association between the access point and a station • Based on 802. 1 x • 802. 1 x – 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. 1 x Standard” • http: //www. cs. umd. edu/~waa/1 x. pdf Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 IEEE 802. 11 Security (2 of 3) • Provides four cryptographic algorithms to protect data traffic – Two based on RC 4 - 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 Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 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 Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 IEEE 802. 1 x 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 Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 IEEE 802. 1 x 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 Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 IEEE 802. 1 x 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 Submission TKurihara, TKstds Management

September 2003 doc. : IEEE 802. 11 -03/0784 r 0 IEEE 802. 1 x 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. 1 X EAP packets. Submission TKurihara, TKstds Management