Few questions on Air Cipher parameters + SA

Hi, RC:

Did you change your plan? You said that you were using data mode for air-ciphering operation in last few querys.

For security protocol type = sa_PT_3GPP_AC, please refer to appendix "3GPP Opeartion and PDU formats" for supported PDU formats and their corresponding operations. Please refer to SA example and unit tests for sample code as well. Please note that the operation direction is little confused in the air ciphering mode where
Tx (To IP Network): From-Air traffic
Rx(From IP Network): To-Air traffic

Please find my answers to your questions below:

1. what is the role of fresh field ? I see few comments as put below, but frankly i could not make anything out of it. Say i am using AES CTR and Snow 3G, how much relevant is this field?

[Eric] Fresh is used by Kasumi-F9. This field is not required for AES-CTR, CMAC or Snow3G-F8.

u32 fresh; /**< Specify the 32-bit random number (fresh) required
for some integrity check algorithms */

 2. If i understand correctly, in PSINFO of the packet-to-be-sent-to-SA is filled with either INIT VECTOR [a typical 16 bytes] or Count-C[a typical 4 bytes] ?? please confirm?

[Eric] Yes, the psInfo will contain an 8-byte command which will include PDU offset, PDU length and optional Count-C. Please refer to "3GPP Opeartion and PDU formats" for details.

3. stressing point 2 little more, when init vector will be copied into PSINFo section of descriptor and when count-C is copied into PSINFO section of descriptor? please give out an example or it is available in some literature, please point me to it.
[Eric] For LTE, you should use count-C in From-Air direction. The Count-C is not required in To-Air direction. The IV should be provided only if you want to SASS to ignore the count-C provided in security context and use the IV provided by application. This is a special enhancement required by some customers.

4. Assuming that my implementation is purely with Count-C way of PSINFO, do i need init vector,ivsize or useIV at any point of time?

[Eric] No.

5. Per channel, i create 4 SC's, 1 for cipher, 1 for de-cipher, 1 for auth, 1 for de-auth. how internally it will select appropriate [tx and rx] instances

[Eric] The SASS does not support simultaneous ciphering and authentication in a channel in Air-ciphering mode.
            Therefore, you need to create one Air-Ciphering channel for data channel and you need to create two air-ciphering channels for control channel, one for ciphering and one for authentication.

when i call Sa_chanReceiveData [decipher,de-auth] or Sa_chanSendData [cipher, auth]? I will take one example

[Eric] As I explaned earlier, it is little confused. You need to call Sa_chanReceiveData for to-air traffic [ciphering and auth]. Sa_chanSendData for from-air traffic [de-ciphering , de-auth] Please refer to SA example and unit test for use case].

1. SC1 is for cipher

2. SC2 is for decipher

3. SC3 is for auth

4. SC4 is for de-auth.

if i call Sa_chanSendData, how internally it calls up SC for cipher, auth. I am missing understanding from LLD operation point of view. Kindly explain whether above [4 SC's per channel is possible and if so, how SC's are pulled for appropriate operation].

[Eric] The application needs to manger the security context ID and buffers and provide them to SA LLD when the call-out function ScAlloc and ScFree are invoked.

Best regards,

Eric

Hi, RC:

Please see my answers in-line:

1. say i select 5 bits, SN has to wrap around at 31. since CountC is maintained by SASS, how to specify this number 5,7 and 12?

[Eric] It is not necessary to specify SN size. The SASS uses the entire ContC [HN:SN] for ciphering and insert the countC used in front of the PDU.
          The SASS will increment the entire SN by one for every packet it processes, the SN wrap around will occur naturally regardless of the SN size.
          It is up to the appliction to extract SN and send it over the air.

2. I ran through example code and it linearly incremented the countC [to-air directions], i agree and am happy. Is it left to user/application to do manipulations on the INSERTED COUNTC [32 bit [HN:SN]] by SALLD and get the 32bit format to 5,7 or 12 bits SN [removing the HN] and wraparound thereafter ??

[Eric] The application should extract both SN and HN, send SN with the PDU and verify HN againist its internal record.

Best regards,

Eric

Hi, RC:

Your questions seem to mix the SA LLD user interface with the unit test sample code. Please note that the unit test code is dsigned for internal test. It can be served as an example , but it is not intended to be used as LTE protocol (PDCP) module code.

I will try to answer your questions below:

1. CountC which is given at the time of Channel creation and the number which is taken into to-air security context's own field and incremented for every packet send [free running counter]

uint32_t countC; /**< Specify the high bits, HFN, for the frame Counter
WCDMA RLC AM: the high 20 bits are used
WCDMA RLC UM: the high 25 bits are used
WCDMA RLC TM: the high 25 bits are used
LTE: All 32-bit is used as Count-C
GSM: Not used */


Is this countC Field purely HFN or [HFN:SFN] ?
[Eric] This configuration parameters in only used for sa_AcPduType_LTE in to-air diesction.

2. UInt32 count32; /* For GSM Key generation and LTE CP only */

for every CP packet received or to be transmitted, we fill this field in the Host descriptor and send to SA...

If i understand correctly, this field is used for LTE CP only, both To-Air and From-Air directions, please correct ?? [Eric] Yes.
is this field used in LTE only mode also in To-Air and From-Air directions. If i understand this is used only for From-Air directions. Please confirm it? Please explain in detailed on this.

 [Eric] Yes, it is only used for From-Air direction. It may be passed at the psInfo as part of shortInfo command, the SASS knows when this field is valid and should be used based on the PDU type.

in LTE [data] only To-Air packet, if i set some value in this field, how does this get clubbed with countC from step1 and do encryption. Similarly please explain in From-Air direction.

[Eric] To-Air: Ignore; From-Air: used as 32-bit count-C.

in LTE_CP only To-Air packet, if i set some value in this field, how does this get clubbed with countC from step1 and do encryption. Similarly please explain in From-Air direction.

[Eric] Used as conut-C in both directions.

what i am roughly making out the meaning is
countC is HFN only
count32 is SFN only..
how does these two [countC and count32 work together for LTE and LTE_CP in To-Air and From-Air directions], kindly reply?

[Eric] No, they are both the entire 32 bit count-C.

3. According to Ti documentation, Count-C is being put into CPPI header as stated below.

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

does this Count-C means step2's count32 ??  [Eric] Yes, count32 is intended to be used as 32-bit count-C,

4. below is done for LTE CP only

pktWrite8bits_m((tword *)pPktDesc->segments[0], 0, (UInt8)(pAcHdr->seqNum & 0x1F));

can the above step be explained. This somewhere points to me about 5 bits SFN, is that correct. kindly explain? [eric] Please read the standard document. We just try to simulate the 5-bit PDCP SN which may be the lower 5-bit of count-C. It does not matter to SA LLD or SASS since both number will be provided by the application. 

Best regards,

Eric