Add API to support device lifecycle change

[cneveux]

In order to enforce Secure Element state, a device can support different lifecycle, device supporting such mechanism requires a user request to switch its lifecycle state when it’s ready to restrict Secure Element features/functionalities.

The PSA Attestation API defines the notion of “Security Lifecycle” in the initial attestation token report but there is no PSA API allowing to switch the “token’s Security Lifecycle”.

• One use case could be the device provisioning before switching in functional state:
  A device in PSA_LIFECYCLE_PSA_ROT_PROVISIONING lifecycle state allows to provision assets that are usable or not in PSA_LIFECYCLE_PSA_ROT_PROVISIONING state. Assets to provision could be injected in a wrap format and only unwrapped-able by the Secure Element. Assets could be certificates, keys, passwords, binaries, …
  Then when all assets are correctly provisioned, the device can be switched in PSA_LIFECYCLE_SECURED lifecycle state.
  In PSA_LIFECYCLE_SECURED lifecycle state, assets provisioned becomes genuine and usable in the Secure Element. Indeed because the device is in protected lifecycle, assets are in protected Secure Element and could not be replaced if desired.

[athoelke]

Apologies for delay in responding to this question.

When we originally defined the PSA Certified APIs, the need for a lifecycle state in the device Root of Trust was obvious. A generic lifecycle state model is described in the PSA Certified Security Model, and this is also used in the PSA Firmware Framework for M (FF-M), the Attestation API, and the Authenticated Debug Access Control Specification (ADAC).

These are almost entirely consistent in the states defined and transitions. I do note, however, that at some point the Security Model made a change related to the PRoT Debug state(s), after the names and numerical values for the states used by the other specifications had been published.

There is a single API function (currently still defined in FF-M) to report the current lifecycle state of the Root of Trust. We were not sure of the need for a standard API to request a transition to a different state: our expectation was that most transitions are triggered by external events (such as attaching and authenticating a debugger), or by platform-specific code (e.g. during provisioning as a test/development device or as a production device).

If there is demand, and value, in having a standard API that could be used for some of those use cases, we could consider providing this via the PSA Certified APIs.