• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 723 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

XTCIEVMK2X: SA Ciphering and Authenticating

Tony Liu1
Intellectual 640 points

Hi TI experts,

I would like to use SA to do 3GPP air ciphering and authenticating.

SRB includes ciphering and authenticating.

DRB inclues ciphering.

We have SRB1, SRB2 and DRB1~DRB8.

Q1:How many SA channels should we create?

Q2: Both ciphering and authenticating need the below parametes.

1. Key

2.Count

3.Bearer ID

4.Direction

5.Length

6.Message

But we seem just input "message" and "length" parameters to SA, and other parameters are decided when setting up SA channels. Can we dynamic configurate SA channel? How?

Best Reds.

Tony

  • 0
    TI__Guru* 81335 points
    Hi Tony,
    We are working with experts to answer this post. Thank you for your patience.
  • 0 in reply to Raja
    Intellectual 640 points
    Hi Rajasekaran K,

    Any progress?

    Regards,

    Tony
  • 0
    TI__Expert 5805 points

    Hi Tony,


    How SA manages security associations it does so by creating a channel for encryption/authentication_tx and one for decryption/authentication_rx. So for every connection you must create two SA "channels". Each channel will be configured with at least Cipher Mode, Auth Mode, IV Size, Count-C, Encryption Key, Enc Key size, Auth Key, Auth Key size, PDU type. For full list of parameters please see links below. Once the channel is created you may send packets for encryption/authentication.

    For LTE PDU Types you provide the following to SA:

    LTE:
    Supported PDU types:
     
                      0 1 2 3 4 5 6 7 
                     +-+-+-+-+-+-+-+-+
                     |                       |
                     |   Count-C     |
                     |   (4-byte)       |
                     |                       |          
                   +>+-+-+-+-+-+-+-+-+
                   | |                      | 
                   | |                      |
                   | |     Data        |               
                   | |                      | 
                   | |                      | 
                   | +-+-+-+-+-+-+-+-+
                   |
                   |-> Ciphering Unit
 
                   Figure 5.  Ciphering Unit of a PDCP Data PDU.
 
 
                      0 1 2 3 4 5 6 7 
                     +-+-+-+-+-+-+-+-+ <+
                     |R R R| PDCP SN |  |
                   +>+-+-+-+-+-+-+-+-+  |
                   | |                                |  |
                   | |                                |  |
                   | |     Data                  |  |             
                   | |                                |  |
                   | |                                |  |
                   | +-+-+-+-+-+-+-+-+  |-> Authentication Unit
                   | |   MAC-I                   |
                   | |   (4 byte)                 |
                   | +-+-+-+-+-+-+-+-+
                   | 
                   |-> Ciphering Unit
 
                   Figure 6.  PDCP Control Plane Data Uint for SRBs
    Ciphering algorithm: Snow 3G/F8, AES-CTR Authentication algorithm: CMAC - [JMB] Will be programmed per channel
    From Air Traffic (Decryption and/or Authentication verification) :
    • Input to SA:
      • PDCP Data with 32-bit Count-C in the CPPI header for the Data Plane PDU
      • PDCP Header plus Data and MAC-I with 32-bit Count-C in the CPPI header for the Control Plane PDU
    • Output from SA: 32-bit Count-C plus decrypted PDCP PDU Data
      • PDCP Data for the Data Plane PDU
      • PDCP Header plus Data and MAC-I for the Control Plane PDU
    To Air Traffic (Encryption and/or Authentication) :
    • Input to SA:
      • PDCP Data for the Data Plane PDU
      • PDCP Header plus Data and MAC-I with 32-bit Count-C in the CPPI header for the Control Plane PDU
    • Output from SA: 32-bit Count-C plus encrypted PDCP PDU Data
      • 32-bit Count-C plus PDCP Data for the Data Plane PDU
      • PDCP Header plus Data and MAC-I for the Control Plane PDU

    You may find more information here: I suggest taking a look at the PDK SA LL Unit Test for specific examples of how to setup the air cipher channels. under -> PDK/packages/ti/drv/sa/docs/doxygen/html/appendix1.html

    Regards,

    Javier

  • 0 in reply to Javier Malave-Bonet
    Intellectual 640 points

    Hi Javier,

    Thanks for your reply.

    You memtioned "So for every connection you must create two SA "channels".

    Q1: What do your mean "every connection" here? Is it "DRB" or "SRB" or others?

    Q2: What do two SA channes refer to? Are they a channel for encryption/authentication_tx and the other for decryption/authentication_rx?

    But from https://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/259388, One SA channel should contains both tx and rx.

    [Eric] There is no concept of users in the SA LLD. It is designed to handle multiple channels where each channel is defined by its configuration parameters.

     Each channel consists of tx path and rx path. Where tx means to-network (IPSEC/SRTP) or from-air traffic (Air Ciphering) and rx means from network (IPSEC/SRTP) or to-air (Air Ciphering) traffic. Therefore, each channel will require two security contexts, one for tx and one for rx.

    Q3:If one UE has 2 SRB and 5 DRB, then how many SA channels should be created (from eNB side)?

    Q4: If two UE both have 2 SRB and 5 DRB, then how many SA channels should be created (from eNB side)?

    Tony