May, 2009 C2 – Company Confidential SOURCE: Simon Mizikovsky, Ganesh Sundaram, Zhibi Wang, Jialin...
-
Upload
shawn-miles -
Category
Documents
-
view
216 -
download
3
Transcript of May, 2009 C2 – Company Confidential SOURCE: Simon Mizikovsky, Ganesh Sundaram, Zhibi Wang, Jialin...
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.
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.
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.
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
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…
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
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
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
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
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
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.
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