S32G RTD HSE Crypto driver: Addressing keys through constants?

[soerenh]

Hello,

I'm using the Crypto driver from S32 Real-Time Drivers Version 4.0.2 P10 and configured keys in tresos. As a next step, I wanted to make use of the keys in my code.

To my surprise, it seems the Crypto driver generated code does not create programmatically addressable names for the keys that are configured in Tresos. Even worse - the only programmatically addressable constants (CryptoConf_CryptoKeyElement_.*) can't be used, because Tresos *enforces* the same CryptoKeyElementId:

...this limitation makes the resulting constants pretty useless, because they all have the same value...

In the documentation of the API - for example Crypto_KeyElementSet() - the parameter to pass to the function is the ID of the Key that is only visible visually, but not accessible programmatically through macros or constants.

This means that every key needs to be addressed through a hard-coded number in the code. If I wanted to address keys through user-friendly names, I have to create that myself and manually synchronize whenever the configuration in tresos changes. This is very impractical and not well maintainable.

Am I missing something, or is this indeed the intended way?

[Daniel-Aguirre]

Hi,

We might be misunderstanding the overall inquiry. If so, we do apologize.

We understand that the behavior you are seeing is intended, given that the CryptoKeyElementId only supports hexadecimal, decimal, octal and binary inputs.

We also seem to understand that the generated files should create the CryptoKeyElementId macro with the usage of the Name element, as shown below:

Which you should be able to use, rather than the number itself. You should be able to differentiate each key with the name itself. As for the KeyElementSet  function, we understand that you can use macros, as shown below:

For which, we don't see any problems from our side.

Again, we could be misunderstanding the overall inquiry. If so, we do apologize.

Please, let us know.

[soerenh]

Hello Daniel,

thank you for the reply - and very sorry for my late reply

I've been looking into the autosar crypto driver spec - and can confirm that this is actually conformant behavior according to the spec. The keyElementId parameter must be set to 1 when a SHE key is referenced. Your example screenshot shows this, i.e. two different keys have the same ID.

When all keys have the same ID, that however means that I can't use those macros, nor any other macro to reference a key by name from my application.

If, for instance, I wanted to make a service request to HSE, I need to provide a key handle. There seems to be no way that I can configure a key in Tresos - let's say we name this "KeyA" - and then create a service request in my application that references KeyA by name. In order to do this, I'd have to manually create these macros myself - or hardcode numbers into the request.

I understand the code generator produces autosar-conformant code, but that code isn't very useful when working with the HSE. It would be great, if there was an option to automatically generate HSE keyhandles from the key catalog configured in Tresos.