Authenticated Validity for M2M devices IEEE Presentation Submission Template (Rev. 9) Document Number: IEEE S802.16p-11/0251 Date Submitted: Source: Eldad ZeiraVoice: InterDigital Venue: IEEE n at session #75 Base Contribution: C802.16p-11/0251 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

Authenticated Validity for M2M devices

IEEE S802.16p-11/0251 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 EAP doesn’t protect from tampering

IEEE S802.16p-11/0251 M2M Vulnerabilities

IEEE S802.16p-11/ p Requirements: SRD 6.4Security 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

IEEE S802.16p-11/0251 We need to: Prevents a potentially tampered device from accessing services (e.g. multicast) 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: optionality of integrity validation –Must be able to mix different device types in single network

IEEE S802.16p-11/0251 The basis: Devices which need integrity validation have an (unspecified) difficult to tamper with module which can test the validity of the device as a whole. Failed devices must not attempt to connect… but that in itself does not provide the network with any validity proof

IEEE S802.16p-11/0251 What are our alternatives? A.Prevent release of EAP certificate if test failed B.Prevent release of EAP certificate if test failed + add information regarding this capability of the device Both require that EAP is made mandatory and used for key derivation C. Send certificate confirming the passing of the validity test after keys are established 1.In RNG-REQ 2.“higher layer” messages

IEEE S802.16p-11/0251 Network behavior: Device typeEAP certificate sentEAP certificate NOT sent Validity test capability indicated Authorize device-Do not authorize device -alert for rogue device Validity test capability NOT indicated N/ADo not authorize device Device typevalidity certificate sentvalidity certificate NOT sent Validity test capability indicated Authorize device for sensitive information -Expire keys -alert for rogue device Validity test capability NOT indicated N/A-Do not authorize device for sensitive information, BUT -allow other services Network behavior for Alt-A: Device typeEAP certificate sentEAP certificate NOT sent Not applicableAuthorize deviceDo not authorize device Network behavior for Alt-B: Network behavior for Alt-C: No difference between C-1 & C-2, as long as validity information is timely and there is a mechanism for retries if message fails. These already exist for RNG-REQ/RSP

IEEE S802.16p-11/0251 Conclusions: If EAP is used for the validity test then EAP must be mandatory Use of EAP does not allow to mix devices which have validity testing and those which have not. Both must be denied service. –If validity testing capability information is provided then the network has evidence of tampering. Sending a separate certificate (in addition to EAP or RSA) plus information regarding device type: –Allows to differentiate between devices with and without validity testing and offer different services to each –Doesn’t make EAP mandatory –Provides confidentiality to device type

IEEE S802.16p-11/0251 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

IEEE S802.16p-11/0251 The network MAY, if device validity check IS: Successful, Establish additional keys that may be used for additional services –Multicast access –Sensitive user payload Unsuccessful, Cause key(s) to expire Send an (unspecified) command that affects device behavior (e.g. re-boot, “safe mode”, etc.)

IEEE S802.16p-11/0251 MS behavior for device integrity validation Un-touched Retries possible

IEEE S802.16p-11/0251 The procedure (1/2) 1.AMS that has a TE and failed the validity test shall not attempt to enter the network. 1.Provides protection from DOS attacks on AAA server; nature of protection depends on implementation. 2.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. 1.Shifts integrity responsibility to network 2.Provides network with tampering attempt information 3.Part of the network access state machine 3.Out of scope for p: 1.ABS forwards the received information to the network. 2.If device validity is not acceptable, the network may expire keys. 3.Otherwise the network or AMS may initiate new services and new keys

IEEE S802.16p-11/0251 The procedure (2/2) 4.The ABS response in AAI-REG-RSP indicates whether the device validity has been accepted or not. 4.Prevents need to wait until next transmission to find out keys have been expired 5.AAI-REG-RSP with negative confirmation shall be interpreted as an abort. The AMS behavior in this case is FFS.