May, 2009 C2 – Company Confidential SOURCE: Simon Mizikovsky, Ganesh Sundaram, Zhibi Wang, Jialin...

12
May, 2009 C2 – Company Confidential SOURCE: Simon Mizikovsky, Ganesh Sundaram, Zhibi Wang, Jialin Zou CONTACT: [email protected] , [email protected] , [email protected] , [email protected] ABSTRACT: This is a stage 2 proposal on the security layer evolution for HRPD Rev-C. TITLE: HRPD Rev-C Security Layer Evolution TSG-C RECOMMENDATION: Discuss and adopt. The source companies of this contribution grant 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. The source companies of this contribution 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 The source companies of this contribution 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 The source companies of this contribution . The source companies of this contribution specifically reserves the right to amend or modify the material contained herein and to any intellectual property of The source companies of this contribution other than provided in the copyright statement above.

Transcript of May, 2009 C2 – Company Confidential SOURCE: Simon Mizikovsky, Ganesh Sundaram, Zhibi Wang, Jialin...

Page 1: May, 2009 C2 – Company Confidential SOURCE: Simon Mizikovsky, Ganesh Sundaram, Zhibi Wang, Jialin Zou CONTACT: smizikovsky@alcatel-lucent.com, ganneshs@alcatel-lucent.com,

May, 2009

C2 – Company Confidential

SOURCE: Simon Mizikovsky, Ganesh Sundaram, Zhibi Wang, Jialin Zou

CONTACT: [email protected], [email protected], [email protected], [email protected]

ABSTRACT: This is a stage 2 proposal on the security layer evolution for HRPD Rev-C.

TITLE: HRPD Rev-C Security Layer Evolution

TSG-C

RECOMMENDATION: Discuss and adopt.

The source companies of this contribution grant 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. The source companies of this contribution 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 The source companies of this contribution 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 The source companies of this contribution . The source companies of this contribution specifically reserves the right to amend or modify the material contained herein and to any intellectual property of The source companies of this contribution other than provided in the copyright statement above.

Page 2: May, 2009 C2 – Company Confidential SOURCE: Simon Mizikovsky, Ganesh Sundaram, Zhibi Wang, Jialin Zou CONTACT: smizikovsky@alcatel-lucent.com, ganneshs@alcatel-lucent.com,

2 | Rev-C Security Layer Evolution | May, 2009 C2 – Company Confidential

Disadvantages in the current Security Disadvantages in the current Security

LayerLayer

Identified issues and disadvantages of current security layer in CDMA Rev B- Revision B air interface is not efficient when the security is

applied. - Complexity of security with Multi-carriers- Efficient Selective Security Requires Differentiation Between

Streams Current Security Layer cannot distinguish streams- Encryption cannot be implemented separately from lower layer

functions- Pre-encryption is impossible

Propose to re-use security solution similar to that in UMB, i.e. define an additional security function at the Air Interface Application layer. Adapt this function to the HRPD Rev.C, while retaining the current Security Sub-layer for Strict Backwards Compatibility.

Page 3: May, 2009 C2 – Company Confidential SOURCE: Simon Mizikovsky, Ganesh Sundaram, Zhibi Wang, Jialin Zou CONTACT: smizikovsky@alcatel-lucent.com, ganneshs@alcatel-lucent.com,

3 | Rev-C Security Layer Evolution | May, 2009 C2 – Company Confidential

EVDO layering and security evolutionEVDO layering and security evolution

Air interface application layer

Streaming layer

Session layer

Connection layer

Security layer

MAC layer

Physical layer

Air interface application layer (Security function, new

application subtypes for SLP, RLP)

Streaming Layer

Session layer

Connection layer

Legacy Security Layer

MAC layer

Physical layer

Revisions 0, A, B Revision C

Note: This contribution makes proposal for the security function for the HRPD Rev C. Since the detail air interface structure for the Rev C is yet to be finalized, the proposal is based on air interface architecture for Rev B. It is expected that corresponding adjustments might be needed when the air interface format for Rev. C is finalized.

Page 4: May, 2009 C2 – Company Confidential SOURCE: Simon Mizikovsky, Ganesh Sundaram, Zhibi Wang, Jialin Zou CONTACT: smizikovsky@alcatel-lucent.com, ganneshs@alcatel-lucent.com,

11/12/2006

Lucent Technologies – Proprietary

Use pursuant to company instruction4

EVDO Application Layer Security (ALS)

EVDO Application Layer Security (ALS) enable encryption/authentication

ALS keeps track of “byte stream” numbering – Synchronized with RLP layer (between RNC and BTS)

ALS breaks “byte stream” into 128 bit blocks (count)– Each byte is identified using block number and byte number

within the block, and is reset to 0 after (255-1) blocks• Example: Byte 173 of byte stream is identified as 10.12

– ALS count is a virtual counter that is in “sync” with RLP sequence number all the time. For the multiple-carrier, the virtual counter is calculated based on Segmentation and Reassembly (SAR) sequence number SAR_seq, which is used to segmentation and reassembly the packet.

• 1-1 correspondence between RLP sequence # and ALS count

WARNING: Application = Air Interface Application = RLP or SLP NOT RTP

Page 5: May, 2009 C2 – Company Confidential SOURCE: Simon Mizikovsky, Ganesh Sundaram, Zhibi Wang, Jialin Zou CONTACT: smizikovsky@alcatel-lucent.com, ganneshs@alcatel-lucent.com,

11/12/2006

Lucent Technologies – Proprietary

Use pursuant to company instruction5

Link Layer Assisted ALS: Encryption Each ALS block encrypted by AES in counter mode

– No additional overhead needed. Encrypted or not is known during call set up for every RLP stream

Cryptosync at transmitter is derived from direction bit (forward vs reverse link) followed by RLP flow id followed by block number

– Note that RLP sequence number will start to recycle after 222-1 (or 26 –1 for VoIP), but ASL blocks will not until 255-1

At receiver, cryptosync is derived easily from RLP sequence number

– Example: Suppose RLP packet with sequence number 173 is received, then the receiver identifies the first byte of the packet as block 10.12.

• Therefore bytes 173, 174, 175, 176 will be decrypted using the 12 th through 15th bytes of AES counter output using cryptosync value (direction bit, RLP flow id, block number (=10)).

• Bytes 177 through 192 will be decrypted using the 0th through 15th bytes of AES counter output using cryptosync value (direction bit, RLP flow id, block number (=11)), I.e., cryptosync has been incremented by 1, etc…

Page 6: May, 2009 C2 – Company Confidential SOURCE: Simon Mizikovsky, Ganesh Sundaram, Zhibi Wang, Jialin Zou CONTACT: smizikovsky@alcatel-lucent.com, ganneshs@alcatel-lucent.com,

11/12/2006

Lucent Technologies – Proprietary

Use pursuant to company instruction6

VoIP with ROHC and ALS

EVRC<=176PADRTP=96UDP=64IP=160

Multiple of 32

EVRC<=176ROHC 16, 32

EVRC<=176ROHC 16,32

CRC+Tail=30MAC2 EVRC<=176ROHC 16,32

UP TO 516 bits

UP TO 208 bits

UP TO 208 bits

UP TO 256 bits

RLP Length

LinkFlowID 5

Route 1

First 1

Last 1

SEQ 6 (VoIP)

RLP+STR16

EVRC<=176ROHC 16,32RLP+STR16 UP TO 224 bits

Page 7: May, 2009 C2 – Company Confidential SOURCE: Simon Mizikovsky, Ganesh Sundaram, Zhibi Wang, Jialin Zou CONTACT: smizikovsky@alcatel-lucent.com, ganneshs@alcatel-lucent.com,

11/12/2006

Lucent Technologies – Proprietary

Use pursuant to company instruction7

PPP aware link layer assisted ALS for Explicit MAC Forward Link: RNC receives PPP frames from PDSN

– PPP frames encapsulated in GRE packets, but no PPP for VoIP

Reverse Link: IP packets sent to PPP layer prior to RLP PPP frames are analyzed in order to perform Van-Jacobson header compression

– Essentially the IP and TCP header are “compressed” • Some fields are eliminated, some fields are “incremented” and

some fields are maintained as is (e.g., TCP checksum) PPP assisted ALS for TCP based best effort services

– ALS packet = Output of V-J compression followed by EHMAC tag

• PPP frames are typically large, hence MAC is efficient• Cryptosync is based on the counter maintained at ALS

Encrypt ALS packet (Link Layer Assisted ALS) following which RNC transmits encrypted ALS frame to BTS

– EHMAC tag is also encrypted in the process

Page 8: May, 2009 C2 – Company Confidential SOURCE: Simon Mizikovsky, Ganesh Sundaram, Zhibi Wang, Jialin Zou CONTACT: smizikovsky@alcatel-lucent.com, ganneshs@alcatel-lucent.com,

11/12/2006

Lucent Technologies – Proprietary

Use pursuant to company instruction8

TCP with V-J compression and ALS

HTTP/FTP etcTCP=160IP=160

V-J Comp

RLP Length

LinkFlowID 5

Route 1

First 1

Last 1

SEQ 22

HTTP/FTP etc

V-J Comp HTTP/FTP etcPPP PPP

V-J Comp HTTP/FTP etcPPP PPP TAG

V-J Comp HTTP/FTP etcPPP PPP TAG

RLP+STR32

RLP+STR32

MAC2

RLP+STR32

MAC2

RLP+STR32

PDSN

RNC RL

BTS FL

RNC FL

BTS RL

ALS

Page 9: May, 2009 C2 – Company Confidential SOURCE: Simon Mizikovsky, Ganesh Sundaram, Zhibi Wang, Jialin Zou CONTACT: smizikovsky@alcatel-lucent.com, ganneshs@alcatel-lucent.com,

11/12/2006

Lucent Technologies – Proprietary

Use pursuant to company instruction9

Receiver operation

Receiver decrypts packets at ALS using RLP sequence number and RLP link-flow ID– Construct count based on sequence # and link-flow ID

– Plaintext = A-1(Ciphertext-B), where A=AES(count,0), A-1 is the inverse of A in GF(2128) and B=(count,1)

For UDP based VoIP packets receiver passes decrypted ALS packets up to “ROHC routine” to reconstruct headers– No explicit message authentication

For TCP based best effort packets receiver constructs ALS frame and verifies MAC– Transmit verified packets to “V-J routine” to reconstruct headers

– In order to verify MAC, the entire ALS packet has to be received• This may introduce some delays at the receiver, but for TCP based

services this is needed regardless of security at ALS

Page 10: May, 2009 C2 – Company Confidential SOURCE: Simon Mizikovsky, Ganesh Sundaram, Zhibi Wang, Jialin Zou CONTACT: smizikovsky@alcatel-lucent.com, ganneshs@alcatel-lucent.com,

11/12/2006

Lucent Technologies – Proprietary

Use pursuant to company instruction10

Security part embedded in the packet application and signaling application– It was proposed that the Air Interface Application security be part

of the HRPD supplemental service. This will be considered. Security function will include new application subtypes for SLP and RLP

New subtypes for packet/sig apps– If the ALS is part of the air interface application layer, new

subtypes for the packet/sig apps will be needed.Document structure.

– The document structure will be consistent with that of C.S0063 or a new document

Clarifications on the header for encryption, how often encryption keys are to be changed etc., if it is changed in an active data call etc.– The session key is not expected to be changed during the

session. For an inactive mobile that is re-activate, the new keys can be used with an signaling, therefore, there is no need to carry the keyindex for every packet.

Additional Consideration

Page 11: May, 2009 C2 – Company Confidential SOURCE: Simon Mizikovsky, Ganesh Sundaram, Zhibi Wang, Jialin Zou CONTACT: smizikovsky@alcatel-lucent.com, ganneshs@alcatel-lucent.com,

11/12/2006

Lucent Technologies – Proprietary

Use pursuant to company instruction11

Benefits of Proposed Security Function in the Air Interface Application LayerThe security function is applied before the fragmentation, and

the lower layers receive the data after it has already being processed by the security function. Therefore, the identified inefficiency is eliminated.

The security function is in the air interface application layer, traffic flows can be selectively processed by security function.

There is no need to wait for final delivery scheduling, the data can be pre-processed by the security function ahead of time.

For the multiple carrier, because security function is applied to the packet before segmentation, corresponding key management is simplified.

Page 12: May, 2009 C2 – Company Confidential SOURCE: Simon Mizikovsky, Ganesh Sundaram, Zhibi Wang, Jialin Zou CONTACT: smizikovsky@alcatel-lucent.com, ganneshs@alcatel-lucent.com,

11/12/2006

Lucent Technologies – Proprietary

Use pursuant to company instruction12

SummaryThis contribution introduces Application Layer

Security (ALS) option which overcomes all the disadvantages

– ALS operates between RLP and header compression layer

– ALS includes two new concepts• Link Layer Assisted Encrypted and optionally Implied

Message Authentication

• PPP Assisted Explicit Message Authentication

– ALS options configured for each EVDO application stream during “call” set up by adding a three bit field to QoS Blob