DSRC Security Project, P1556

1
DSRC Security Project, P1556
T. M. Kurihara 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

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,.

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

5
Operational Requirements

• Control Channel doesnt 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

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

7
Requirements

• Low cost
• Proven technology
• security community validation, acceptance
• Significant successful industry implementations
• Availability
• Non-proprietary solutions preferred

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

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

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)

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

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

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

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
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

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

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)

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

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

20
DSRC Security
Thomas M. Kurihara Chair, IEEE WG P1556, DSRC
Security TKstds Management 1 703 516
9650 tkstds_at_mindspring.com
21
Supplemental Information

• Options
• Integrity
• One-way Hash
• Anonymity
• Authentication
• Confidentiality
• Standards
• Public Key Cryptography
• IEEE 802.11i
• IEEE 802.1x

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

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

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

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 users 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

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

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

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)

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)

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 PKCS1,
• 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

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

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

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

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

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

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 

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.