aboutsummaryrefslogtreecommitdiff
path: root/docs/standards/psa_certification.rst
diff options
context:
space:
mode:
Diffstat (limited to 'docs/standards/psa_certification.rst')
-rw-r--r--docs/standards/psa_certification.rst191
1 files changed, 0 insertions, 191 deletions
diff --git a/docs/standards/psa_certification.rst b/docs/standards/psa_certification.rst
deleted file mode 100644
index e9a888c91..000000000
--- a/docs/standards/psa_certification.rst
+++ /dev/null
@@ -1,191 +0,0 @@
-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