ULE Security proposal

for discussion2011-03-14

1RTX Confidential Information

ULE Security proposal

• It is proposed to base ULE security architecture on the CCM algorithm, Counter (CTR) with Cipher Block Chaining-Message Authentication Code (CBC-MAC), described in RFC3610

• Motivations for the proposal:• CCM provides both packet authentication and encryption• It is a recognized algorithm• It is based on AES-128• Approved by NIST• Believed to be patent-free• Used in Zigbee, 802.11i and other communication standards

2RTX Confidential Information

ULE Security proposal

• Architecture proposal (subject for discussions)

• DCK (128bit) produced by DSAA2 during authentication (DECT circuit switched) used as key in CCM

• Key is assigned (and renewed) by traditional circuit switched authentication by use of DSAA2

• Key is stored in non-volatile memory and is kept during deep-sleep

• All ULE packets are secured by default, no need for procedures to switch on and off encryption

• Packet overhead: • MAC (Message Authentication Code), for example 32 bit• PN (Packet Number), for example 20 bit (to be reset when a new Key is assigned)

3RTX Confidential Information

DECT-MAC

NWKMM / CC

DSAA2

ULE-MAC

CCMCCM

APPAPP

DCK

Payload

Ciphertext

MAC

PN

DLCDLC

DLC

ULE Security proposal, operation

• Initial pairing by use of Obtain-access-rights procedure in circuit switched communication mode:• Key allocation (UAK) by ordinary procedure

• PP authentication is performed by use of DSAA2 and DCK[128] is produced in both peers

• Location registration for allocation of PMID

• Registration credentials including PMID and DCK[128] are stored in non-volatile memory

• Packet (rx/tx) number counters (non-volatile) are reset

• Connection attributes may be negotiated between FP and PP (subject for definition)

• ULE device can enter deep-sleep mode• ULE device can wakeup at regular interval or specific events:

• Send packet data (incl. “I am alive”), which by default are secured by CCM

• Optional receive packet data, which by default are secured by CCM

4RTX Confidential Information

ULE Security proposal, operation

• Re-keying for purpose of refreshing the DCK[128] is performed in circuit switched mode only:• Can be triggered by application

• Initiated after too many packet authentication-fails

• Initiated when packet number range is (nearly) exhausted• PP circuit switched connection setup and initiate MM procedure

• FP indicted via connection setup via paging and initiate MM procedure

• Packet number counters are reset

• Access rights can be terminated by ordinary circuit switched procedure

5RTX Confidential Information

ULE Security proposal, overhead

• Packet authentication and encryption:• DCK[128] is available from last successful circuit switched FP authentication

• Nonce (N-once value must only be used one time) input for CCM algorithm is proposed to be constructed from a (random) value concatenated with a packet number. It ensures unique initialization vectors for the algorithm.

• Packet number counter (PN) is also used to detect re-play attach.

• PN size determines the required interval between (circuit switched) re-keying.

• Messages Authentication Code (MAC) is added to the added to the packet. CCM supports from 2 to 16 bytes.

6RTX Confidential Information

CCM algorithm++

Packet payloadPacket payload

”PN” Encrypted payload ”MAC””PN” Encrypted payload ”MAC”

PNPN

DCK[128]

Nonce

ULE Security proposal• ULE packet size are quite small. Currently we are considering 2 formats:

• Protected B-field yields 11 bytes of ULE payload• Unprotected B-field yields 17 bytes of ULE payload

• For efficiency point of view it is desirable to limit the overhead introduced by packet authentication (MAC). From security point of view it should be maximized. The CCM algorithm supports 2..16 byte for MAC.

• The packet number (PN) has to be unique DCK[128]. If it is going to be appended to the authenticated packets its size a tradeoff between overhead and interval between (circuit switch) re-keying. MAC-layer acknowledgement scheme is necessary to ensure proper numbering.

• PN size examples:• 24 bit allows a packet every 10 second for 5 years• 20 bits allows a packet every minute for 2 years• 16 bit allows a packet every 10 minute for 1 year

• Overhead example : MAC: 32bit; PN:20 bits

7RTX Confidential Information

ULE Security proposal

• Open issues:• MAC size (configurable)?• PN size (configurable)?• Do we need to transmit the PN?• Is packet numbering feasible?• Multicast / broadcast requirements (assignment of group-key)?• Do we compromise security by using same DCK[128] in a circuit connection?• How do we allocated Nonce?• Mobility considerations?

• Do we have a DLC layer?• Do we run the CCM per ULE MAC-layer packets or on concatenated DLC-

layer frames?

• Is usage of CCM in line with ETSI security standards?

8RTX Confidential Information