yuzu-emu/mbedtls
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
mbedtls/docs/architecture/mbed-crypto-storage-specification.md
Ronald Cron 71016a9ea7 psa: Rename psa_key_file_id_t to mbedtls_svc_key_id_t 
With PSA crypto v1.0.0, a volatile key identifier may
contain a owner identifier but no file is associated
to it. Thus rename the type psa_key_file_id_t to
mbedtls_svc_key_id_t to avoid a direct link with a
file when a key identifier involves an owner
identifier.

The new type name is prefixed by mbedtls to highlight
that the type is specific to Mbed TLS implementation
and not defined in the PSA Cryptography API
specification.

The svc in the type name stands for service as this
is the key identifier type from the point of view of
the service providing the Cryptography services.
The service can be completely provided by the present
library or partially in case of a multi-client service.

As a consequence rename as well:
. MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER to
  MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER
. PSA_KEY_ID_INIT to MBEDTLS_SVC_KEY_ID_INIT
. PSA_KEY_FILE_GET_KEY_ID to MBEDTLS_SVC_KEY_ID_GET_KEY_ID
. psa_key_file_id_make to mbedtls_svc_key_id_make

Signed-off-by: Ronald Cron <ronald.cron@arm.com>
2020-09-02 14:27:07 +02:00

14 KiB
Raw Blame History

Mbed Crypto storage specification

This document specifies how Mbed Crypto uses storage.

Mbed Crypto may be upgraded on an existing device with the storage preserved. Therefore:

  1. Any change may break existing installations and may require an upgrade path.
  2. This document retains historical information about all past released versions. Do not remove information from this document unless it has always been incorrect or it is about a version that you are sure was never released.

Mbed Crypto 0.1.0

Tags: mbedcrypto-0.1.0b, mbedcrypto-0.1.0b2

Released in November 2018.
Integrated in Mbed OS 5.11.

Supported backends:

Supported features:

This is a beta release, and we do not promise backward compatibility, with one exception:

On Mbed OS, if a device has a nonvolatile random seed file produced with Mbed OS 5.11.x and is upgraded to a later version of Mbed OS, the nonvolatile random seed file is preserved or upgraded.

We do not make any promises regarding key storage, or regarding the nonvolatile random seed file on other platforms.

Key names for 0.1.0

Information about each key is stored in a dedicated file whose name is constructed from the key identifier. The way in which the file name is constructed depends on the storage backend. The content of the file is described below.

The valid values for a key identifier are the range from 1 to 0xfffeffff. This limitation on the range is not documented in user-facing documentation: according to the user-facing documentation, arbitrary 32-bit values are valid.

The code uses the following constant in an internal header (note that despite the name, this value is actually one plus the maximum permitted value):

#define PSA_MAX_PERSISTENT_KEY_IDENTIFIER 0xffff0000

There is a shared namespace for all callers.

Key file format for 0.1.0

All integers are encoded in little-endian order in 8-bit bytes.

The layout of a key file is:

  • magic (8 bytes): "PSA\0KEY\0"
  • version (4 bytes): 0
  • type (4 bytes): psa_key_type_t value
  • policy usage flags (4 bytes): psa_key_usage_t value
  • policy usage algorithm (4 bytes): psa_algorithm_t value
  • key material length (4 bytes)
  • key material: output of psa_export_key
  • Any trailing data is rejected on load.

Nonvolatile random seed file format for 0.1.0

The nonvolatile random seed file contains a seed for the random generator. If present, it is rewritten at each boot as part of the random generator initialization.

The file format is just the seed as a byte string with no metadata or encoding of any kind.

File namespace on ITS for 0.1.0

Assumption: ITS provides a 32-bit file identifier namespace. The Crypto service can use arbitrary file identifiers and no other part of the system accesses the same file identifier namespace.

File namespace on stdio for 0.1.0

Assumption: C stdio, allowing names containing lowercase letters, digits and underscores, of length up to 23.

An undocumented build-time configuration value CRYPTO_STORAGE_FILE_LOCATION allows storing the key files in a directory other than the current directory. This value is simply prepended to the file name (so it must end with a directory separator to put the keys in a different directory).

  • CRYPTO_STORAGE_FILE_LOCATION "psa_key_slot_0": used as a temporary file. Must be writable. May be overwritten or deleted if present.
  • sprintf(CRYPTO_STORAGE_FILE_LOCATION "psa_key_slot_%lu", key_id) content of the key whose identifier is key_id.
  • Other files: unused.

Mbed Crypto 1.0.0

Tags: mbedcrypto-1.0.0d4, mbedcrypto-1.0.0

Released in February 2019.
Integrated in Mbed OS 5.12.

Supported integrations:

Supported features:

Backward compatibility commitments: TBD

Key names for 1.0.0

Information about each key is stored in a dedicated file designated by the key identifier. In integrations where there is no concept of key owner (in particular, in library integrations), the key identifier is exactly the key identifier as defined in the PSA Cryptography API specification (psa_key_id_t). In integrations where there is a concept of key owner (integration into a service for example), the key identifier is made of an owner identifier (its semantics and type are integration specific) and of the key identifier (psa_key_id_t) from the key owner point of view.

The way in which the file name is constructed from the key identifier depends on the storage backend. The content of the file is described below.

  • Library integration: the key file name is just the key identifier as defined in the PSA crypto specification. This is a 32-bit value.
  • PSA service integration: the key file name is (uint32_t)owner_uid << 32 | key_id where key_id is the key identifier from the owner point of view and owner_uid (of type int32_t) is the calling partition identifier provided to the server by the partition manager. This is a 64-bit value.

Key file format for 1.0.0

The layout is identical to 0.1.0 so far. However note that the encoding of key types, algorithms and key material has changed, therefore the storage format is not compatible (despite using the same value in the version field so far).

Nonvolatile random seed file format for 1.0.0

Identical to 0.1.0.

File namespace on a PSA platform for 1.0.0

Assumption: ITS provides a 64-bit file identifier namespace. The Crypto service can use arbitrary file identifiers and no other part of the system accesses the same file identifier namespace.

Assumption: the owner identifier is a nonzero value of type int32_t.

File namespace on ITS as a library for 1.0.0

Assumption: ITS provides a 64-bit file identifier namespace. The entity using the crypto library can use arbitrary file identifiers and no other part of the system accesses the same file identifier namespace.

This is a library integration, so there is no owner. The key file identifier is identical to the key identifier.

File namespace on stdio for 1.0.0

This is a library integration, so there is no owner. The key file identifier is identical to the key identifier.

Identical to 0.1.0.

Upgrade from 0.1.0 to 1.0.0.

  • Delete files 1 through 0xfffeffff, which contain keys in a format that is no longer supported.

Suggested changes to make before 1.0.0

The library integration and the PSA platform integration use different sets of file names. This is annoyingly non-uniform. For example, if we want to store non-key files, we have room in different ranges (0 through 0xffffffff on a PSA platform, 0xffff0000 through 0xffffffffffffffff in a library integration).

It would simplify things to always have a 32-bit owner, with a nonzero value, and thus reserve the range 0–0xffffffff for internal library use.

Mbed Crypto 1.1.0

Tags: mbedcrypto-1.1.0

Released in early June 2019.
Integrated in Mbed OS 5.13.

Identical to 1.0.0 except for some changes in the key file format.

Key file format for 1.1.0

The key file format is identical to 1.0.0, except for the following changes:

  • A new policy field, marked as [NEW:1.1.0] below.
  • The encoding of key types, algorithms and key material has changed, therefore the storage format is not compatible (despite using the same value in the version field so far).

A self-contained description of the file layout follows.

All integers are encoded in little-endian order in 8-bit bytes.

The layout of a key file is:

  • magic (8 bytes): "PSA\0KEY\0"
  • version (4 bytes): 0
  • type (4 bytes): psa_key_type_t value
  • policy usage flags (4 bytes): psa_key_usage_t value
  • policy usage algorithm (4 bytes): psa_algorithm_t value
  • policy enrollment algorithm (4 bytes): psa_algorithm_t value [NEW:1.1.0]
  • key material length (4 bytes)
  • key material: output of psa_export_key
  • Any trailing data is rejected on load.

Mbed Crypto TBD

Tags: TBD

Released in TBD 2019.
Integrated in Mbed OS TBD.

Changes introduced in TBD

  • The layout of a key file now has a lifetime field before the type field.
  • Key files can store references to keys in a secure element. In such key files, the key material contains the slot number.

File namespace on a PSA platform on TBD

Assumption: ITS provides a 64-bit file identifier namespace. The Crypto service can use arbitrary file identifiers and no other part of the system accesses the same file identifier namespace.

Assumption: the owner identifier is a nonzero value of type int32_t.

File namespace on ITS as a library on TBD

Assumption: ITS provides a 64-bit file identifier namespace. The entity using the crypto library can use arbitrary file identifiers and no other part of the system accesses the same file identifier namespace.

This is a library integration, so there is no owner. The key file identifier is identical to the key identifier.

Non-key files on TBD

File identifiers in the range 0xffff0000 through 0xffffffff are reserved for internal use in Mbed Crypto.

  • Files 0xfffffe02 through 0xfffffeff (PSA_CRYPTO_SE_DRIVER_ITS_UID_BASE + lifetime): secure element driver storage. The content of the file is the secure element driver's persistent data.
  • File 0xffffff52 (PSA_CRYPTO_ITS_RANDOM_SEED_UID): nonvolatile random seed.
  • File 0xffffff54 (PSA_CRYPTO_ITS_TRANSACTION_UID): transaction file.
  • Other files are unused and reserved for future use.

Key file format for TBD

All integers are encoded in little-endian order in 8-bit bytes except where otherwise indicated.

The layout of a key file is:

  • magic (8 bytes): "PSA\0KEY\0".
  • version (4 bytes): 0.
  • lifetime (4 bytes): psa_key_lifetime_t value.
  • type (4 bytes): psa_key_type_t value.
  • policy usage flags (4 bytes): psa_key_usage_t value.
  • policy usage algorithm (4 bytes): psa_algorithm_t value.
  • policy enrollment algorithm (4 bytes): psa_algorithm_t value.
  • key material length (4 bytes).
  • key material:
    • For a transparent key: output of psa_export_key.
    • For an opaque key (key in a secure element): slot number (8 bytes), in platform endianness.
  • Any trailing data is rejected on load.

Transaction file format for TBD

The transaction file contains data about an ongoing action that cannot be completed atomically. It exists only if there is an ongoing transaction.

All integers are encoded in platform endianness.

All currently existing transactions concern a key in a secure element.

The layout of a transaction file is:

  • type (2 bytes): the transaction type.
  • unused (2 bytes)
  • lifetime (4 bytes): psa_key_lifetime_t value that corresponds to a key in a secure element.
  • slot number (8 bytes): psa_key_slot_number_t value. This is the unique designation of the key for the secure element driver.
  • key identifier (4 bytes in a library integration, 8 bytes on a PSA platform): the internal representation of the key identifier. On a PSA platform, this encodes the key owner in the same way as in file identifiers for key files).

Transaction types on TBD

  • 0x0001: key creation. The following locations may or may not contain data about the key that is being created:
    • The slot in the secure element designated by the slot number.
    • The file containing the key metadata designated by the key identifier.
    • The driver persistent data.
  • 0x0002: key destruction. The following locations may or may not still contain data about the key that is being destroyed:
    • The slot in the secure element designated by the slot number.
    • The file containing the key metadata designated by the key identifier.
    • The driver persistent data.