1. Authenticated Validity for M2M devices
IEEE Presentation Submission Template (Rev. 9)
Document Number:
IEEE S802.16p-11/0093
Date Submitted:
Source:
Eldad Zeira Voice:
InterDigital
Venue:
IEEE n at session #73
Base Contribution:
C802.16p-11/0093
Purpose:
To be discussed and adopted by p
Notice:
This document does not represent the agreed views of the IEEE Working Group or any of its subgroups. It represents only the views of the participants listed in the “Source(s)” field above. It is offered as a basis for discussion. It is not binding on the contributor(s), who reserve(s) the right to add, amend or withdraw material contained herein.
Release:
The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
Patent Policy:
The contributor is familiar with the IEEE-SA Patent Policy and Procedures:
< and <
Further information is located at < and < >. 1

2. Authenticated Validity for M2M devices

3. M2M networks are vulnerable
M2M networks are more vulnerable to security threats due to longevity and field updates / provisioning
M2M networks are required to handle critical missions without human intervention
Attacks can lead to false situational awareness, loss of privacy, DOS
In some cases network attacks = physical attacks

4. M2M Vulnerabilities

5. 802.16p Requirements: PAR Scope
5.2 Scope: This amendment specifies IEEE Std medium access control (MAC) enhancements and minimal orthogonal frequency division multiple access (OFDMA) physical layer (PHY) modifications in licensed bands to support lower power consumption at the device, support by the base station of significantly larger numbers of devices, efficient support for small burst transmissions, and improved device authentication.

6. 802.16p Requirements: SRD
6.4 Security Support The p system shall support integrity and authentication of M2M devices, as well as integrity and privacy of M2M application traffic which requires a secure connection The p system shall support a device validity check between the device and the network The p system shall enable a flexible security suite that can be adjusted per the security requirements of the M2M application

7. Provides the network with evidence of tampering
This proposal:
Prevents a potentially tampered device from accessing services and performing DOS attacks
Provides the network with evidence of tampering
So owner can take action
Imposes minimal burden on devices that do not require integrity validation

8. Elements of tamper detection & mitigation
A Trusted Element (TE) tests for tampering
TE is NOT mandatory for all devices; Capability & implementation are out of scope
TE, if implemented, should be tamper resistant
A device that fails the test does not attempt to access network
Send Device Validity Information to network: within time limit, confidentially and with integrity protection,
Validity testing capability information (e.g. as H/W, S/W certificates)
Validation certificate (if implemented)
- The only requirement mandatory to all devices in the network;
Needed to prevent tampered devices from pretending it doesn’t have the capability
Provides tampering evidence to network

9. The network MAY, if device validity check IS:
Successful,
Unsuccessful,
Establish additional keys that may be used for additional services
The additional keys may be required to exchange sensitive user payload or access multicast channels
Cause key(s) to expire
Send an (unspecified) command that affects device behavior (e.g. re-boot, “safe mode”, etc.)

10. MS behavior for device integrity validation

11. The procedure:
AMS that has a TE and failed test shall not attempt to enter the network.
The AMS sends its validity testing capability information (e.g. as H/W & S/W build certificates) and optionally its validation (integrity) certificate in AAI-REG-REQ.
Out of scope for p: (The ABS forwards the received information to the network. If the network decides that device validity was not acceptable, the network may expire keys. Otherwise the network or AMS may initiate new services and new keys)
The ABS response in AAI-REG-RSP indicates whether the device validity has been accepted or not.
AAI-REG-RSP with negative confirmation shall be interpreted as an abort. The AMS behavior in this case is FFS.