docs/standards/psa_certification.rst

PSA Certification Requirements
==============================

Trusted services contribute to meeting PSA security requirements.  In the context of PSA certification, the scope and required
capabilities of supported trusted services are guided by:

    - The security primitives needed by system software for PSA level 1 checklist compliance.
    - Test coverage of the certification test suite used for PSA Functional API certification.

To determine what security primitives are needed, the 'system software' PSA scope has been used as a reference.  The current PSA
level 1 questionnaire is highly Cortex-M specific so some interpretation is needed to map requirements to Cortex-A based designs
that use a rich-OS such as Linux.  The following assessment is based on the assumption that the PSA system software scope
encompasses an entire Linux distribution.  The reference system software for the assessment will include:

    - TF-A.
    - Secure partition manager (OP-TEE with FF-A extensions performs this role).
    - Set of trusted services, deployed in S-EL0 secure partitions that are built-in to the OP-TEE image to allow early loading.
    - Normal-world boot loader.  EDK2 with Grub used as reference.
    - Linux kernel.
    - Root filesystem that includes generic services, libraries and program binaries.

Product developers will extend the base distribution to add application specific components.

PSA System Software Questionnaire Analysis
------------------------------------------

The following table lists PSA level 1 assessment questions with an attempt to identify the back-end security primitives that are
needed to meet the requirement.  The table is based on PSA Certified Level 1 Questionnaire Version 2.1.

.. list-table:: PSA Questionnaire Analysis
    :widths: 13 40 15 15 28
    :header-rows: 1

    * - Requirement
      - Summary
      - Depends on
      - TS used
      - Comment
    * - R1.1
      - | System software and application software update
        | verification using immutable root-of-trust.
      - Verify signed hash
      - Crypto
      - Depends on secure for persistent key storage.
    * - R1.2
      - | System software and application software update
        | anti-rollback protection.
      - Increment only NV counter
      - | Secure Storage (for protecting normal
        | world components)
      - | TF-A uses OTP fuses for early boot stages. This requirement is much more difficult to meet
        | on Cortex-A compared to M as
        | there are potentially many separately updatable components.
    * - R2.1
      - Protected device ID
      - Sign hash
      - Crypto
      - Depends on secure storage for persistent key storage.
    * - R2.2
      - Secure storage
      - Replay protected persistent storage, tied to device
      - Secure storage
      - | A filesystem mount that provided file storage with the required security properties would be
        | the conventional interface for user-space processes.
    * - R2.3
      - Crypto best practices
      - TRNG for random number and key generation
      - Crypto
      - Crypto service will need an entropy source.
    * - R3.1
      - Remote server authentication
      - Verify signed hash
      - Crypto
      - Depends on secure storage for persistent key storage.
    * - R3.2
      - Communication encryption
      - Kernel encryption support
      - None
      - Not a use-case for trusted services.
    * - R3.3
      - TLS authentication support
      - Sign & verify hash
      - Crypto
      - TLS library such as Mbed TLS needs to use Crypto service.
    * - R4.1
      - Provide attestation token for device life-cycle state
      - Secure life-cycle state variable, Sign message.
      - Attestation, Secure lifecycle, Crypto
      -
    * - R4.2
      - Unused functionality disabled
      - Secure life-cycle state variable
      - Secure Lifecycle
      - | Although the PSA questionnaire doesn't state this, in practice, the minimal capabilities
        | required will depend on the device lifecycle state. This will extend to all parts of the
        | system software, including trusted service capabilities.
    * - R4.3
      - Secure logging
      - Sign hash for non-repudiable log.
      - Crypto
      - | PSA questionnaire isn't specific about non-repudiation but for security auditing purposes,
        | this may be a requirement. For example, for industrial IoT applications where conformance
        | to IEC 62443 is important, verifiable log data that can be reliably traced, back to the
        | originating device is understood to be required.
    * - R4.4
      - Restricted log file access
      - File access control
      -	None
      - File access using standard Linux DAC or MAC if used.
    * - R4.5
      - Data on external interfaces checked defensively
      - Good coding practices in application components
      -
      - | The same could be applied for messages crossing any security boundary e.g. trusted service
        | interfaces. PSA only mentions external interfaces and critical APIs but for Cortex-A, this
        | likely to be insufficient.
    * - R4.6
      - Principle of least privileges
      - Use of Linux isolation, access control and other containment methods.
      -
      - | No direct dependency on trusted services but access to TS held assets must be controlled
        | according to principle of least privileges.
    * - R5.1
      - Passwords not resettable
      - Enforcing password policy
      -
      -
    * - R5.2
      - Password best practices
      - Enforcing password policy
      -
      -
    * - R5.3
      - User authentication using critical security parameters
      - Depends on auth method
      - Crypto (possibly)
      - | Requirement is not specific enough to determine if there is a trusted service dependency.
        | Dependency may be indirect, say to authenticate an Oauth2 server.
    * - R6.1
      - Externally applied configuration signed
      - Verify signed hash
      - Crypto
      - Similar to firmware update verification requirement.
    * - R7.1
      - Persistent storage of user data must support destructive erase
      - Destructive erase	secure Storage (possibly)
      - Secure storage
      - | File based storage with a filesystem mount with the required security properties would be the
        | conventional way to provide persistent storage to user-space processes.

Observations
------------

- All dependencies on the PSA Crypto service involve persistent keys.  Volatile key support is not needed for compliance.
- Applying R4.2 to system software doesn't really make sense.  The system software features that are needed are largely
  determined by the application software that implements the device functionality.  For a supplier of the base system software,
  a super-set of required functionality is likely to be the right offering but with the facility to allow features to be
  configured by device developers.  The ability to apply a configuration that limits functionality would be a more useful goal.
- Although the PSA certification document doesn't mention this, available device capabilities need to be a function of device
  life-cycle state.  For example, some features used during manufacture should not be available when a device is delivered to
  end users.
- It's hard to see anyone using the PSA Protected Storage API directly.  However, enabling a filesystem mount with equivalent
  security properties would be beneficial.  For example, a protected storage filesystem driver that uses the Protected Storage
  service as its back-end would be a good fit.  The PSA Protected Storage API would never be used directly by user-space
  applications.
- Logging with the guarantee of non-repudiation is really required to support audit use-cases.  Without that guarantee, it's
  just logging.

PSA Functional API Tests
------------------------

Functional API tests suites are currently available for:

    - PSA Crypto
    - PSA Attestation
    - PSA Storage

Running and passing API tests is not a requirement for PSA level 1 certification.  However, incorporating the API tests into the
trusted service test process is obviously beneficial as a way of demonstrating a defined set of functionality.

Functional API tests focus on valid behavior testing and are quite thorough in exercising all required functionality that can be
observed at each API.  To pass all tests, the service implementation needs to be complete, at least from a functional
perspective.

Test code depends on an implementation of the PSA C APIs for each service under test.

--------------

*Copyright (c) 2020-2021, Arm Limited and Contributors. All rights reserved.*

SPDX-License-Identifier: BSD-3-Clause