SE050E aead encryption

[Zarein94]

Hi @Kan_Li, with your previous solution, The problem was solved and I could compile and execute it using the SE050 on a raspberry pi. My actual target is a device running openwrt. I've already cross-compiled the middleware and executed the examples on the target and they all work fine. Good to mention that I successfully executed the symmetric example. Now that the problem is solved, only on the target I am getting the following errors when executing on the board. I've seen a similar post (EdgeLock SE050 OpenSSL, pkcs11-tool, and SM_Connect Failed. Status 7012) which faces the same error but in a different context. I don't think the solution there works for me too. Here's the error I get:

App   :INFO :PlugAndTrust_v04.03.01_20230203
App   :INFO :Running ./ex_symmetric
App   :INFO :Using PortName='/dev/i2c-0:0x48' (CLI)
App   :INFO :Using default PlatfSCP03 keys. You can use keys from file using ENV=EX_SSS_BOOT_SCP03_PATH
sss   :INFO :atr (Len=35)
      01 A0 00 00    03 96 04 03    E8 00 FE 02    0B 03 E8 00
      01 00 00 00    00 64 13 88    0A 00 65 53    45 30 35 31
      00 00 00
sss   :INFO :tlvGet_u8buf: I've reached here**!
sss   :INFO :DoAPDUTxRx_s_Case4_ext: I've reached here it's OK!
App   :INFO :Running AES symmetric Example ex_sss_symmetric.c
App   :INFO :Do Encryption
App   :INFO :iv (Len=16)
      00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00
App   :INFO :srcData (Len=16)
      48 45 4C 4C    4F 48 45 4C    4C 4F 48 45    4C 4C 4F 31
sss   :INFO :SE05 being returned
smCom :ERROR:PAL Read status error status = ff
smCom :ERROR:phNxpEseProto7816_GetRawFrame phNxpEse_read failed , status : 0xff
smCom :ERROR:phNxpEseProto7816_ProcessResponse phNxpEseProto7816_GetRawFrame failed starting recovery
smCom :ERROR:Failed writing data (nrWritten=-1).

smCom :ERROR: - Error in I2C Write.....
smCom :ERROR:phNxpEseProto7816_SendRawFrame Error phNxpEse_WriteFrame
smCom :ERROR:TransceiveProcess Transceive send failed, going to recovery!
smCom :ERROR:phNxpEseProto7816_Transceive Transceive failed, hard reset to proceed
smCom :ERROR: phNxpEse_Transceive phNxpEseProto7816_Transceive- Failed
smCom :ERROR: Transcive Failed
sss   :WARN :nxEnsure:'retStatus == SM_OK' failed. At Line:7131 Function:sss_se05x_channel_txn
sss   :WARN :nxEnsure:'ret == SM_OK' failed. At Line:7026 Function:sss_se05x_TXn
sss   :WARN :nxEnsure:'status == SM_OK' failed. At Line:6082 Function:sss_se05x_aead_one_go
App   :WARN :nxEnsure:'status == kStatus_SSS_Success' failed. At Line:198 Function:ex_sss_entry
App   :ERROR:ex_sss_symmetric Example Failed !!!...
App   :INFO :ex_sss Finished
App   :ERROR:ex_sss_entry Failed
smCom :ERROR:Failed writing data (nrWritten=-1).

smCom :ERROR: - Error in I2C Write.....
smCom :ERROR:phNxpEseProto7816_SendRawFrame Error phNxpEse_WriteFrame
smCom :ERROR:TransceiveProcess Transceive send failed, going to recovery!
smCom :ERROR:phNxpEseProto7816_Close TransceiveProcess failed
smCom :ERROR:Failed to close session
App   :ERROR:!ERROR! ret != 0.

Could you please help me with that! The strange thing is that I don't have the same problem for symmetric example. Could it be some specific config is needed for aead. I've also checked that I have the same config in (fsl_sss_ftr.h) for both raspberry pi and the cross-compiled one.

[Zarein94]

@Kan_Li I have a question about aead encryption using AES-GCM algorithm. Thanks to your help, all the process is going well. The only problem, which is not small actually is for a round of encryption and decryption with a tag and authentication data, it takes around 9 seconds. Is this normal? 

[Kan_Li]

Hi @Zarein94 ,

Yes, AES GCM is not fast on SE05x. The AES operation is HW-accelerated, the Galois-Counter is not  accelerated . 

The performance of AES GCM scales mainly with the size of data to be processed and not with the size of the key (data to be encrypted and additional authentication data (AAD))

Hope that makes sense,

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[Kan_Li]

Hi @Zarein94 ,

So now the MW is running on a device running openwrt, right? Was the demo of ex_symmetric is the one you modified for AEAD encryption or the original one? Did you run some demo else? Was the result the same? Please kindly clarify.

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[Zarein94]

Hi @Kan_Li, 

Thanks for your reply. So the MW now is running on openwrt. This is the output while running on openwrt. So I can explain better, These are the steps I've takes for  openwrt + SE  and raspberry + Evaluation board with SE. 

Raspberry pi:

1. Compiled the MW

2. Executed examples and they all execute successfully 

3. Original ex_symmetric executes successfully

4. Modified ex_symmetric for AEAD executes successfully with TagSize 12 => 16

Openwrt:

1. Compiled the MW

2. Executed examples and they all execute successfully 

3. Original ex_symmetric executes successfully

4. Modified ex_symmetric for AEAD with TagSize 12 => 16 gives the errors that I just shared with you. 

[Kan_Li]

Hi @Zarein94 ,

Thanks for the clarification! It seems that the I2C driver from Openwrt has some issue to work with the MW, though you didn't provide the full log, but I can see this issue happened somewhere after the encryption, which does take some time to complete, so I suspected maybe there was some timeout method in the I2C driver of Openwrt which interrupted the communication between each other in such cases. 

Hope that makes sense,

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[Zarein94]

Hi @Kan_Li ,

Thanks for your response. I have investigated more and I was not able to find any type of timeout for i2c in openwrt kernel config. I am also sharing the full log of the program. Do you confirm that this problem is coming from the i2c bus or the driver and not from the fw or MW? 

Thanks a lot for your support. 

[Kan_Li]

Hi @Zarein94 ,

Thanks for the information! Looks like the error happened here:

so please check on your side if the above condition was met in your case, and if yes, you may have to adjust ESE_NAD_POLLING_MAX to a larger value to meet the following requirement.

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[Zarein94 · Accepted solution]

Hi @Kan_Li ,

Thanks for your support. Actually your guidance made me find me the actual problem. For target-specific, the sm_sleep function has three different implementations. In my case, due to cross-compilation for openwrt the option "other" is the final implementation which is using clock() to count the number of clocks to implement the delay. But this implementation does not work correctly for the Muscle compiler being used in openwrt. So due to no delay in polling, for this specific case which takes more time to encrypt, it fails. So I change the implementation to usleep or (nanosleep), then the implementation works fine and then the example finishes successfully.