SMS Channel Security

Channel security for [COAP] is based on the Datagram Transport Layer Security (DTLS) [RFC6347] and has only been defined for the UDP transport but not the SMS transport.

This section defines the security modes for the transport of COAP over SMS.

LWM2M Clients supporting SMS, when the SMS Channel is only used for debugging purposes MAY support the NoSec mode.

LWM2M Clients supporting UDP and SMS, when the SMS Channel is only used for triggering as defined in chapter 8.4 SHALL support the adequate mechanism for securing UDP Channel as defined in chapter 7.1 UDP channel security. Those clients MAY use any SMS security mode. In particular SMS NoSec mode can be used for SMS triggering since all other communication will be secured by UDP channel security.

LWM2M Clients supporting SMS for communications other than triggering, or supporting only the SMS Channel SHALL support SMS Secured Packet Structure Mode. Clients MAY also support other modes e.g. SMS Object Security Mode, or proprietary modes.

In any security mode except for debugging purposes, when an SMS message is received from an MSISDN that is not recorded in LWM2M Server SMS Number resource of the LWM2M Server Access Security, the SMS message MUST be silently ignored.

SMS “NoSec” mode

It is highly recommended to always use LWM2M with one of the security mechanisms described in this section. However, there are few scenarios and use cases where security is provided by lower layers. For example LWM2M devices in a controlled environment behind a gateway, or, tests focussing first on other functions before performing end-to-end tests including security.

This security profile is also useful to support SMS triggering when all other exchanges run over UDP Channel.

SMS Secured Packet Structure mode

The Secured Packet Structure is based on [3GPP TS 31 115]/[ETSI TS 102 225]] which is defining secured packets for different transport mechanisms. The solution was originally designed for securing packet structures for UICC based applications, however, for LWM2M it is suitable for securing the SMS payload exchanged between client and server.

The SMS Secured Packet Structure mode specified in this section MUST be supported when the SMS binding is used.

A LWM2M Client which uses the SMS binding MUST either be directly provisioned for use with a target LWM2M Server (Manufacturer Pre-configuration bootstrap mode or Smart Card Provisioning) or else be able to bootstrap via the UDP binding.

The end-point for the SMS channel (delivery of mobile terminated SMS, and sending of mobile originated SMS) SHALL be either on the smartcard or on the device. When the LWM2M Client device doesn’t support a smartcard, the end-point is on the LWM2M Client device.

A LWM2M Client, Server or Bootstrap Server supporting SMS binding SHALL discard SMS messages which are not correctly protected using the expected parameters stored in the “SMS Binding Key Parameters” Resource and the expected keys stored in the “SMS Binding Secret Keys” Resource, and SHALL NOT respond with an error message secured using the correct parameters and keys.

Device end-point

If the SMS channel end-point is on the device the following settings SHALL be applied:

Class 1 SMS as specified in [3GPP TS 23.038]

TP-PID of 111101 (ME Data Download) as specified in [3GPP TS 23.040]

TP-OA : the TP-OA (originating address as defined in [3GPP 23.040] of an incoming command packet (e.g CoAP request) MUST be re-used as the TP-DA of the outgoing packet (e.g CoAP response)

TAR (see coding of TAR in [ETSI TS 101 220], section 6) SHALL be set to a value in the range BF FF 00 - BF FF FF.

NOTE1: TARs for LWM2M SMS security will be requested from ETSI SCP and the range above applies only until the TAR has been assigned. There will be two different TARs for terminating the security on the smartcard or on the device.

The ciphering and integrity keys and associated counter values SHOULD be held in a smart card or other tamper-resistant secure storage environment (e.g. embedded secure element). The client SHOULD pass MT SMS to the smart card/SE for decryption and integrity checking, and SHOULD pass MO SMS to the smart card/SE for encryption and integrity protection before sending.

NOTE2: The mechanism for this is proprietary within the current release of LWM2M 1.0, but may be standardized in a future release.

If the keys and associated counter values are not stored in the above recommended way, they SHALL be treated as session keys with a lifetime no greater than the duration of the Registration Lifetime (Section 5.2.1). If the keys were provisioned from a Smart Card then the LWM2M Client SHALL discard the key material on each “Register” or “Update” operation (Section 5.2.1 or 5.2.2), load fresh key material from the Smart Card, and reset the counters. The Smart Card is responsible for generating the relevant session keys (in a way known by the LWM2M Server) and storing them in the provisioning file EF LWM2M_Bootstrap. If the keys were provisioned via the UDP binding, then they SHALL be updated over the UDP binding.

As for Section 7.1 (UDP Security), where a session persists across sleep cycles, encrypted and integrity-protected storage SHOULD be used for the session keys and counters.

Smartcard end-point

If the SMS channel end-point is on the smart card the following settings SHALL be applied:

Class 2 SMS as specified in [3GPP TS 23.038]. The [3GPP TS 23.040] SMS header MUST be defined as below:

  • TP-PID : 111111 (USIM Data Download) as specified in [3GPP TS 23.040]
  • TP-OA : the TP-OA (originating address as defined in [3GPP 23.040] of an incoming command packet (e.g CoAP request) MUST be re-used as the TP-DA of the outgoing packet (e.g CoAP response)
          1. Secure SMS Transfer to UICC

A SMS Secured Packet encapsulating a CoAP request received by the LWM2M device, MUST be – according to [ETSI TS 102 225]/[3GPP TS 31.115] - addressed to the LWM2M UICC Application in the Smartcard where it will be decrypted, aggregated if needed, and checked for integrity.

If decryption and integrity verification succeed, the message contained in the SMS MUST be provided to the LWM2M Client.

If decryption or integrity verification failed, SMS MUST be discarded.

The mechanism for providing the decrypted CoAP Request to the LWM2M Client relies on basic GET_DATA commands of [GP SCP03] .This data MUST follow the format as below:

datarcv ::= <address> <coap_msg>

address ::= TP_OA ; originated addresss

coap_msg ::= COAP_TAG <coap_request_length> <coap_request>

coap_request_length ::= 16BITS_VALUE

coap_request ::= CoAP message payload

NOTE : In current LWM2M release, the way the LWM2M Client Application is triggered for retrieving the available message from the Smartcard is at the discretion of the device: i.e a middle class LWM2M Device implementing [ETSI TS 102 223] ToolKit with class “e” and “k” support could be automatically triggered by Toolkit mechanisms, whereas a simpler LWM2M device could rely on a polling mechanisms on Smartcard for fetching data when available.

          1. Secured SMS Transfer to LWM2M Server

For sending a CoAP message to the LWM2M Server, the LWM2M Client prepares a data containing the right TP-DA to use, concatenated with the CoAP message and MUST provide that data to the LWM2M UICC Application in using the [GP SCP03]STORE-DATA command.

According to [ETSI TS 102 225]/[3GPP TS 31.115] the Smartcard will be in charge to prepare (encryption / concatenation) the CoAP message before sending it as a SMS Secure Packet ([ETSI TS 102 223] SEND_SMS command).

The SMS Secured Packet MUST be formatted as Secured Data specified in section 7.3.1.2.

The Secure Channel as specified in Annex H of this document SHOULD be used to provide the prepared data to the Smartcard.

SMS Secured Packet Binding for CoAP messages

In SMS Secured Packet Structure mode, a CoAP message as defined in [CoAP] MUST be encapsulated in [3GPP 31.115] Secured Packets, in implementing - for SMS Point to Point (SMS_PP) - the general [ETSI 102 225] specification for UICC based applications.

  • The “Command Packet” command specified in [3GPP 31.115] /[ETSI TS 102 225] MUST be used for both CoAP Request and Response message
  • The Structure of the Command Packet contained in the Short Message MUST follow [3GPP 31.115] specification
  • SPI SHALL be set as follow (see coding of SPI in [ETSI TS 102 225] section 5.1.1):
    • use of cryptographic checksum
    • use of ciphering
      • The ciphering and crypto graphic checksum MUST use either AES or Triple DES
      • Single DES SHALL NOT be used
      • AES SHOULD be used
      • When Triple DES is used , then it MUST be used in outer CBC mode and 3 different keys MUST be used
      • When AES is used it MUST be used with CBC mode for ciphering (see coding of KIc in [ETSI TS 102 225] section 5.1.2) and in CMAC mode for integrity (see coding of KID in [ETSI TS 102 225] section 5.1.3).
    • process if and only if counter value is higher than the value in the RE
    • PoR depends on LWM2M Server Policy
  • TAR SHALL be set to a value in the range BF FF 00 - BF FF FF or else the LWM2M UICC Application
    • NOTE : This TAR value will be requested to be allocated by ETSI-SCP and registered in [ETSI TS 102 220]
  • Secured Data : contains the Secured Application Message which MUST be coded as a BER-TLV, the Tag (TBD : e.g 0x05) will indicate the type (e.g CoAP type) of that message

results matching ""

    No results matching ""