Hello, I am using the B-L475E-IOT01A2 board and I am trying to adapt the STSAFE-A110 secure element to it. Independent of the input I2C message, I always receive the same message from the slave (see details).

FLoui.1 · ‎2020-09-23

My basis code was generated by the cube MX V.6.0.1 where I adapted code from the Cube expansion STSAFE-A_V.1.1.1 as described in UM2646. Currently there is no crypto middleware implemented in my project. The STSAFE initialization runs throgh properly, initializing GPIO and I2C and returning STSAFE_OK after every step.

There is an Echo command mentioned in UM2646, where the STSAFE A110 should return the same data as transmitted. This are the parameters I transmit to the StSafeA_Echo function:

#define  SIZE_OF_ECHO_OUT            2
 
uint8_t InEchoData[2] = {0x5A, 0x33};
uint8_t OutEchoData_Buffer[SIZE_OF_ECHO_OUT];
StSafeA_LVBuffer_t OutEchoData;
OutEchoData.Length = SIZE_OF_ECHO_OUT;
OutEchoData.Data = OutEchoData_Buffer;
 
STSAFE_Echo(InEchoData, &OutEchoData);
 
void STSAFE_Echo(uint8_t *pInEchoData, StSafeA_LVBuffer_t *pOutEchoData)
{
    StSafeA_Echo(&stsafea_handle, pInEchoData, SIZE_OF_ECHO_OUT, pOutEchoData, STSAFEA_MAC_NONE);
}

Here is what I am reading on the I2C Bus using a logic analyzer (CRC support deactivated):

Transmit message:

START, 0b0100000 + write bit + ACK, 0x00 + ACK, 0x5A +ACK, 0x33 + ACK, STOP

Receive message:

START, 0b0100000 + read bit + ACK, 0x01 + ACK, 0x00 + ACK, 0x02 + ACK, 0xE1 + ACK, 0xF1+ NACK, STOP

Here is what I am reading on the I2C Bus using a logic analyzer (CRC support deactivated):

Transmit message:

START, 0b0100000 + write bit + ACK, 0x00 + ACK, 0x5A +ACK, 0x33 + ACK, 0x1C +ACK, 0x48 + ACK, STOP

Receive message:

START, 0b0100000 + read bit + ACK, 0x01 + ACK, 0x00 + ACK, 0x02 + ACK, 0xE1 + ACK, 0xF1 + ACK, 0xFF + ACK, 0xFF + NACK, STOP

After reading without CRC support my OutEchoData_Buffer contains 0xE1, 0xF1. When I activate CRC support the function returns STSAFEA_INVALID_CRC.

I also tryed to variate all parameters and finaly used the example API pairing.c from the Cube expansion STSAFE-A, where I also receive the same pattern on the I2C.

Unfortunately I cant find any detailed documentation about the I2C communication with this secure element. Could you tell me the mening of this slave response and provide further information about the structure of the commands? Do you have any idea, what I am possibly doing wrong? Thank you for helping!

Best regards,

Felix

FLoui.1 · ‎2020-09-24

Edit:

I found my mistake: I used the deafault CRC initialization generated by the cubeMX. It didnt adapt to the purpose of the service interface. I used the stm32l4xx nucleo driver and the functions from the stm32l4xx_nucleo_crc files to initialize and compute the CRC. After that, the commands worked properly:

Using the echo command my transmit message on the I2C is now: 0x00, 0x5A, 0x33, 0xEB, 0x53 (last two bytes represent the CRC).

The message received is: 0x00, 0x00, 0x04, 0x5A, 0x33, 0xEB, 0x53

Is it correct, that the CRC is a mandatory part of the message? The usermanual UM2646 describes the in the StSafeA_Transmit section: "Compute and concatenate a CRC, if supported". This might mislead to the conclusion, adding a CRC is an optional feature. An example echo messege documented in the manual would be very helpfull. It would provide an easy way to check, if all functions adapted to the service interface work properly.

Best regards,

Felix

Frostlike7646 · ‎2021-08-04

Just wanted to say thank you for updating with your findings, this was key to getting me on the right track. It certainly does look like `STSAFEA_CRC_SUPPORT` is hardcoded to 1 (enabled) in stsafea_core.c, and never changed.