TKurihara, TKstds Management

Slide 1

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

DSRC Security Project, P1556

T. M. Kurihara

TKstds Management

TKurihara, TKstds Management

Slide 2

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 3

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 4

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 5

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 6

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 7

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

Requirements• Low cost

• Proven technology– security community validation, acceptance

• Significant successful industry implementations

• Availability

• Non-proprietary solutions preferred

TKurihara, TKstds Management

Slide 8

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 9

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 10

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 11

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 12

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 13

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 14

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

Security Standards Process

ARINC

Principal consultants

Independent Evaluators

IEEE WG

5.9 GHz DSRC Security WG

IEEE standards process

step A

review review review

step B step C

results results results

results results results

management and technical oversight5.9GHz DSRC Security Committee

Management and technical oversight

Requirements definition, solution identification

Testing

TKurihara, TKstds Management

Slide 15

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 16

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 17

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 18

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 19

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 20

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

DSRC Security

Thomas M. KuriharaChair, IEEE WG P1556, DSRC Security

TKstds Management+1 703 516 9650

tkstds@mindspring.com

TKurihara, TKstds Management

Slide 21

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

Supplemental Information

• Options– Integrity– One-way Hash– Anonymity– Authentication– Confidentiality

• Standards– Public Key Cryptography– IEEE 802.11i– IEEE 802.1x

TKurihara, TKstds Management

Slide 22

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 23

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 24

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 25

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 26

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 27

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 28

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 29

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 30

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 31

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 32

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 33

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 34

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 35

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 36

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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

Slide 37

doc.: IEEE 802.11-03/0784r0

Submission

September 2003

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.