Air-Interface Application Layer Security: A follow up to C20-2006-327-011

Source: Lucent Technologies, Inc.S.Patel, G.Sundaram, R.Rance, S.Mizikovsky, Z.Wang

Recommendation: Discuss and adopt

Lucent Technologies grants a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner's name any Organizational Partner's standards publication even though it may include all or portions of this contribution; and at the Organizational Partner's sole discretion to permit others to reproduce in whole or in part such contribution or the resulting Organizational Partner's standards publication. Lucent Technologies is also willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing an Organizational Partner’s standard which incorporates this contribution.

This document has been prepared by Lucent Technologies to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on Lucent Technologies. Lucent Technologies specifically reserves the right to amend or modify the material contained herein and to any intellectual property of Lucent Technologies other than provided in the copyright statement above.

MotivationMotivation This is a follow up to contribution C20-20060327-011 Introducing Link Layer Security functions above RLP Motivation

1. Bandwidth savings due to reduced overheads• Cryptosync overhead is reduced to zero bytes• Explicit Message Authentication - only one tag per application packet rather

than many tags.• Implicit Message Authentication - without explicit tags

2. Minimizes encryption/decryption in multiple places• The encrypted data can be moved around without requiring a need to

secure the data and shuttle keys around.

3. Encryption can be implemented separately from lower layer functions

4. Pre-encryption possible • application data can be pre-encrypted rather than waiting for lower layers

to schedule and create cryptosync.

OverviewOverview Encryption Overview

– Three choices for encryption - one selected during connection setup:

1. Null encryption

2. Simple encryption

3. Encryption with Implicit Message Authentication (EIMA)

Message Authentication Overview

– Choices for explicit message authentication and tag sizes – selected during connection setup:

1. Null authentication

2. Explicit Message Authentication

– Tag sizes negotiated to be 32, 64, or 96.

CryptosyncCryptosync A Byte Number based cryptosync used for byte oriented RLP

– Transmitter: • 1) keeps track of the bytes seen at the security layer and • 2) uses them to create cryptosync for encryption and message authentication

tag creation.– Receiver:

• 1) the RLP byte number received in the RLP packet is used at the security layer to track the byte number and

• 2) create the crytposync for decryption and message authentication tag verification.

A Packet Number based cryptosync used for packet oriented RLP – Transmitter:

• 1) keeps track of packets seen at the security layer and • 2) uses them to create cryptosync for encryption and message authentication

tag creation.– Receiver:

• 1) the RLP packet number received in the RLP packet is used at the security layer to track the packet number and

• 2) create the cryptosync for decryption and message authentication tag verification.

Simple Encryption: for Byte oriented flowsSimple Encryption: for Byte oriented flows

Sender– Application packet is broken into 128-bit blocks and encrypted one block at a

time.– Each block is stream ciphered (XORed) with mask bits created for that block.

• Mask bits are created by running AES with a cryptosync.– The cryptosync is a flow_id concatenated with the current Block Number.

• The block number is ((byte# of first byte)/16)– Block number is a large counter value of say 56 (or 64) bits

Receiver– Received RLP Byte Sequence Number is used to track the Bytes received

at the security layer. • Note that RLP sequence number will start to recycle after 222-1 (or 230 -1)

blocks are transmitted, after which a virtual counter is incremented.– Block Number is created from the Byte Number and used to create the

cryptosync for that block, which in turn is used to create the mask bits to decrypt the ciphertext 128 bit block.

– Decryption proceeds one block at a time.

Simple encryption: for Packet oriented flowsSimple encryption: for Packet oriented flows Encryption is similar to existing standard. Security layer tracks the number of packets seen, and knows

the length of the current application packet to be encrypted. Mask bits for the entire packet are created using existing AES

encryption mode Cryptosync is flow_id concatenated with Packet Number.

– An internal incrementing 32-bit counter is used as part of the AES input to create mask bits beyond one block.

• Again same as existing AES mode of encryption in standard.

At receiver, the received RLP Sequence Number is used along with a virtual part to create a Packet Number input to the cryptosync.– Mask bits needed for the length of the packet are created to

decrypt the packet.

Explicit Message AuthenticationExplicit Message Authentication

Cryptosync– For packet oriented flow, the cryptosync is same as for

encryption.

– For byte oriented flow, the first block number in the application packet is used for cryptosync.

Message authentication on entire application layer packet– Dramatically reduces overheads due to tags

• E.g., entire IP packet, rather than RLP segment

Message authentication tag is:– EHMAC_SHA( Cryptosync | message )

Encryption with Implicit Message Encryption with Implicit Message Authentication (EIMA)Authentication (EIMA)

Mode of encryption that can provide message authentication in certain cases without incurring the bandwidth overhead of tags.

C = AX+B – X is message and C is ciphertext.

– A and B are two streams of bits created by running AES twice with ‘0’|cryptosync and ‘1’|cryptosync respectively.

– Basic block size is 16 bits, i.e. operations are done over GF(216)

– Some performance details on next slide.

A malicious change in ciphertext would cause the decrypted text to be randomly changed.– If there are redundancy or error check in the message, e.g. UDP/TCP

checksum, then its verification would fail, and the message would be rejected by the application.

– Moreover, tampering with VoIP and other multimedia packets would result in noise at the receiver (implicitly rejected by the user).

AX+BAX+B Calculation

– Encryption involves one multiplication in GF(216)

– Decryption involves one inversion in GF(216), one multiplication in GF(216). X = (C + B)A-1

Inversion can be done using two multiplication in GF(216) using Itoh’s method and normal basis.

Multiplication in GF(216) can be done efficiently by converting into GF(28) multiplications. – Multiplications for GF(28) can be done efficiently using lookup tables.

24 bit blocks – A 24 bit block may be created for a short 24 bit message or if a long

message is not a multiple of 16 bits.

– Do AX+B over GF(224) • Calculations only slightly more complex than GF(216)• 24 bits blocks happen rarely.