Cannot figure out how to set the HMAC on the STSAFE-A110

[CWein.1]

I am trying to use MAC with my STSAFE-A110, in order to further restrict access.

I would have expected a function similar to establishing a public key, i.e. StSafeA_PutPublicKeySlot(...), but I can only find StSafeA_PutAttribute.

Are we really supposed to setup the symmetric HMAC key with PutAttribute?

StSafeA_ResponseCode_t StSafeA_PutAttribute(
 StSafeA_Handle_t *pStSafeA,
 uint8_t InAttributeTag, // e.g. STSAFEA_TAG_HOST_KEY_SLOT
 const uint8_t *pInData,
 uint16_t InDataSize,
 uint8_t InMAC);

The HMAC key should be "write once". Once the HMAC key is established, we should not be able to change it.

[CWein.1]

Still hoping for answer!

[Benjamin BARATTE]

Hi @CWein.1​ ,

Thanks for your question.

The STSAFE-A110 CMAC mechanism is using the pairing keys.

You have a code example for the Pairing use case in the X-CUBE-SAFEA1 package.

you will get the example of StSafeA_PutAttribute() to properly configure the pairing keys.

Then you need to implement the stsafea_crypto_interface.c, once again, you have example with mbedtls in the X-CUBE-SAFEA1 package.

One point that is important, the pairing example is using by default test pairing keys and in the stsafea_crypto_interface.c you must manage the pairing keys handle so you have to make sure you are using the same key for the pairing and the crypto interface implementation.

As you mention, the configuration of the pairing keys is a one-time operation, so you can't update the pairing keys.

Last point, you have a maximum of 50 invalid CMAC operation in a row before locking the pairing keys permanently. So, during your first experiment, be sure that you don't have a loop that retry the STSAFE-A commands as this could lead to a lock of the pairing keys in a fast way.

if this happens you will get a STSAFEA_KEY_BLOCKED error on every command with CMAC authorisation.

Best Regards,

Benjamin

[CWein.1]

Thanks Benjamin. I was able to use the example and set the Host Key.

It appears setting the Host Key does not do anything unless you also configure the STSAFE CMDs to actually require it? Is that right?

#define STSAFEA_TAG_COMMAND_AUTHORIZATION_CONFIGURATION (0x24U) /*!< Command authorization configuration tag. */
 
#define STSAFEA_TAG_COMMAND_ACCESS_CONDITIONS (0x29U) /*!< Command access conditions tag. */
 
#define STSAFEA_TAG_COMMAND_HOST_ENCRYPTION_FLAGS (0x2AU) /*!< Command host encryption flags tag. */

I Imagine I need to also call PutAttribute, while setting one of these tags, but I don't see an example for doing that.

Is there something else I'm missing?

[CWein.1]

My goal is to simply restrict who can communicate with the STSAFE. I don't want bad actors to desolder the chip and use it to generate signatures.

[Benjamin BARATTE]

Hi @CWein.1​ 

These commands are one-time operation that is customizable at profile level. This is not possible with STSAFA110DFSPL02.

If you want to use such personalization, you need to contact your local ST FAE for STSAFE-A product to check the condition of the dedicated profile and the definition of it.

Best Regards,

Benjamin

[CWein.1]

Thank you for the answer.

Okay. Interesting. I would have expected that the devices from Mouser, DigiKey, etc, come "blank" and are fully customizable during client production.

My goal is simply to require HMAC authorization (or some other authorization) in order to submit a signature request command to the STSAFE. I don't want a bad actor to desolder the chips and reuse them.

Does something that "simple" require personalization from ST?

If so, I will look into ST FAE, but of course that is less "convenient" than it working out of the box.

Thank you, again.

Chip

[Benjamin BARATTE]

Hi @CWein.1​ ,

The evaluation sample STSAFA110S8SPL02 are just here to evaluation STSAFE-A features and is fully describe in the following application note.

For production, you need to go for a personalization.

Nevertheless, you can exercise the signature commands with the authentication and let this configuration for your personalized parts.

I understand your point but this type of configuration could be tricky to define and error could lead to the need to change the physically the part, therefore this is a tradeoff between simplicity of evaluation and complexity of the product.

Best Regards,

Benjamin

[CWein.1]

Thank you for the many answers, Benjamin. Your help is the reason I can consider STSAFE.

In your link, I see the following table, for STSAFA110S8SPL02:

Generate Signature

Command Code: 16

Command AC: Free

Encryption of Command Data: (NO)

Encryption of Response Data: (NO)

"free" means user configurable?

Can you share the request format needed to change it to Host C-MAC?

[Benjamin BARATTE]

Hi @CWein.1​ ,

The command AC means Command Access Condition, "free" means that the authentication of the command (C-MAC) is optional.

To enter in detail, the configure command is a one-time operation to configure all the command you have in the figure 2.

On the STSAFA110S8SPL02, the configure command has been already done so you can't modify this setup.

Could you enter an OLS ticket here for your request ?

Thanks,

Best Regards,

Benjamin

[CWein.1]

Thank you very kindly for your patience in explaining.

Finally I understand I cannot change it on the STSAFA110S8SPL02. It has already been set.

After careful consideration, I have decided to not pursue HMAC in order to keep my supply chain simple.

Thankfully, I have thought of an alternative solution, which is actually more secure than using an HMAC key (which is stored in my device in local encrypted flash memory, not very securely).

Thank you for all or your help Benjamin. =)

If you are curious, here is my alternative solution: For Context: my mobile app verifies if my hardware product is genuine by challenging the STSAFE module. The problem: My mobile app has no internet connection requirement, so it is difficult for the app to detect if a counterfeit device is forwarding the challenges via the internet to genuine STSAFE modules that a bad actor purchased from me. However, my app does typically have an accurate date & time. By having all apps request many signatures (~1000) at the same moment in time, in the entire entire world, it will DDOS any attacker who is trying to forward requests a few genuine STSAFE modules. An attacker would need to purchase 1 genuine STSAFE module from me per counterfeit device, which would be cost prohibitive. This means, even without an HMAC to restrict signature generation, a single STSAFE will not be able to generate signatures fast enough for more than a few users.