Infineon/optiga-trust-m

Mutual exclusion

Closed this issue · 6 comments

Hi,

If multiple concurrently running applications (on Linux for instance) use this application, do the applications need to implement any sort of mutual exclusion or does the library handle this? If it needs to be implemented in the application, what granularity does it need to be implemented in (especially given that the library works asynchronously)?

if they are running in one thread everything should be fine, as they share one memeory space, but if you run it from several individual processes you have instances of the stack, so there should be a mutex ensuring only one stack instance is talking to the chip. If you have a shielded connection emebaled some extra measurements should be considered.
the https://github.com/Infineon/cli-optiga-trust-m repository should provide an example code of this can be implemented.

If you have a shielded connection emebaled some extra measurements should be considered.

And what are those extra measures?

I have looked at cli-optiga-trust-m. Ref Infineon/linux-optiga-trust-m#16

On a related note: Is the application supposed to call functions like pal_os_lock_create? More specifically, which pal_* functions is the application supposed to call? Some pal_*_init functions are called by the protocol stack (e.g. pal_i2c_init), others are not.

On a related note: Is the application supposed to call functions like pal_os_lock_create? More specifically, which pal_* functions is the application supposed to call? Some pal_*_init functions are called by the protocol stack (e.g. pal_i2c_init), others are not.

the application in general should not call pal related functions, as they are used internally by the stack, the target plaform should adopt this platform abstraciton layer to its own needs.

And what are those extra measures?

The shielded connection in short is described here, the communcaiton protocol itself (with limited details, is part of the ifx i2c communication protocol documentation).
In general there is a handshake between the host and the Trust M, where the host: has a pre-shared secret (binding secret) generates a random number per communication sesion and has a sequence counter also per communication sesion. It usess them to establish a symmetric shared secret. The problem is that either you share a secret between several processes in file/shared memmeory or you esstablish a secured channel every single switch between aplications.
The CLI works in both modes

the application in general should not call pal related functions [...]

The trustm_engine in cli-optiga-trust-m, however, calls several pal_* functions: pal_gpio_init, pal_os_event_arm, pal_os_event_disarm. The examples in this repo also call e.g. pal_os_event_init and pal_gpio_init. This does not seem to be consistent and it's not clear to me who's really responsible for initializing and de-initializing.

The problem is that either you share a secret between several processes in file/shared memmeory or you esstablish a secured channel every single switch between aplications.
The CLI works in both modes

Understood. Is it correct, that e.g. the trustm_engine has mutual exclusion around the code sections where the application is open since that's where the shared secret for the shielded connection is negotiated?

This does not seem to be consistent and it's not clear to me who's really responsible for initializing and de-initializing.
THis particular example is a bit special, for linux to be precise. Other systems dont have arm/disarm functions. The gpio init is done anyway from the communication stack, for this we should have a look there, whether it is needed or not.

Is it correct, that e.g. the trustm_engine has mutual exclusion around the code sections where the application is open since that's where the shared secret for the shielded connection is negotiated?
There are several ways on how to solve that particular case, the method impleemnted in that sample, not productive code protects commands from one another by using open and close between them. An alternative is to use a daemon to handle requests.

Hi,

If multiple concurrently running applications (on Linux for instance) use this application, do the applications need to implement any sort of mutual exclusion or does the library handle this? If it needs to be implemented in the application, what granularity does it need to be implemented in (especially given that the library works asynchronously)?

please check latest implementation at the following link for mutual exclusion and on how to prevent multiple open and close application:
Infineon/linux-optiga-trust-m@da18fb1