Arm's Platform Security Architecture (PSA) is a holistic set of threat models, security analyses, hardware and firmware architecture specifications, and an open source firmware reference implementation. PSA provides a recipe, based on industry best practice, that allows security to be consistently designed in, at both a hardware and firmware level.

A significant part of PSA is the storage APIs, which have been development within the company for some time.

The primary requirements in the development of the PSA Storage APIs are as follows:

1. Two levels of API required. The security model of the PSA describes two Roots of Trust, the PSA Root of Trust (PRoT) and the Application Root of Trust (ARoT). Most embedded platforms have internal flash storage that is only accessible to software running on the system. For PSA compliant platforms, it is expected (but not required) that at least a portion of the internal flash be reserved for use by the PRoT. This storage should only be accessible to non-secure and secure partitions via the PSA Internal Trusted Storage API. For platforms that also have external flash storage, an additional access API is desired, so that applications written to the PSA not be confined to the limited space available on internal flash. This is the PSA Protected Storage API. This API should be managed either by the ARoT, or, in limited situations where there are no ARoT services dependent upon it, by the non-secure partition. On platforms without external storage, it is permissible to map the PSA Protected Storage API directly to the PSA Internal Trusted Storage API.
2. Keep the APIs simple for users to learn. Since many security vulnerabilities are the result of mis-use or mis-understanding, it was a requirement that APIs developed for PSA be easy to use correctly, and difficult to use incorrectly. Thus, the goal was to minimize the number of function parameters. Instead of having a rich feature set, that required more parameters that are infrequently used, the PSA Storage APIs have a small set of parameters that are used more frequently.
3. Limit Complexity within the Root of Trust. It is very difficult to write vulnerability-free code. It is even more difficult to write complex vulnerability-free code. Thus, the PSA APIs are designed to limit the complexity required inside the Roots of Trust. We considered adding more complex features, such as partial writes or string-based UIDs, but decided against them to limit the required complexity of implementations.
4. Needs to have the ability to create/or overwrite in one function call. Having separate create and set functions causes problems for systems as they start up, as the firmware needs to be aware of whether create has been called on a previous start up. The complexity can be reduced by having a set function that can create or overwrite existing data without additional parameters or function calls.
5. Leave Internal details up to the implementers. To enable PSA implementers as much freedom as possible to innovate, the temptation to overspecify the requirements was resisted.
6. Separation between PSA Crypto responsibilities and PSA Storage responsibilities. With a simple storage API, the creator of the data is responsible for the appropriate use of the data. This means that the storage layer does not need to be aware of the attributes of the data (besides which partition is its owner), as it is not responsible for enforcement of how it is used. This leaves responsibility for the use of various types of data up to the partition most able to enforce the proper use. For example, the cryptographic partition is responsible for enforcement of proper use of keys.

This task is to update SST service to align it with the PSA Protected Storage APIs version 1.0

More information about the design can be found here