1. 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.

2. Motivation  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.

3. Overview  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.

4. Cryptosync  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.

5. Simple 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 2 22 -1 (or 2 30 -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.

6. Simple 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.

7. Explicit 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 )

8. Encryption with Implicit Message 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(2 16 ) –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).

9. AX+B  Calculation –Encryption involves one multiplication in GF(2 16 ) –Decryption involves one inversion in GF(2 16 ), one multiplication in GF(2 16 ). X = (C + B)A -1  Inversion can be done using two multiplication in GF(2 16 ) using Itoh’s method and normal basis.  Multiplication in GF(2 16 ) can be done efficiently by converting into GF(2 8 ) multiplications. –Multiplications for GF(2 8 ) 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(2 24 ) Calculations only slightly more complex than GF(2 16 ) 24 bits blocks happen rarely.