1 / 8

ULE Security proposal for discussion 2011-03-14

ULE Security proposal for discussion 2011-03-14. 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:

lucian-pierce
Download Presentation

ULE Security proposal for discussion 2011-03-14

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ULE Security proposalfor discussion2011-03-14 RTX Confidential Information

  2. 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 RTX Confidential Information

  3. ULE Security proposal APP Payload CCM DSAA2 NWK MM / CC DCK DLC PN DLC Cipher text MAC ULE-MAC DECT-MAC • 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) RTX Confidential Information

  4. 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 RTX Confidential Information

  5. 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 RTX Confidential Information

  6. ULE Security proposal, overhead Packet payload PN + CCM algorithm Nonce DCK[128] ”PN” Encrypted payload ”MAC” • 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. RTX Confidential Information

  7. 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 RTX Confidential Information

  8. 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? RTX Confidential Information

More Related