Commit graph

23 commits

Author SHA1 Message Date
Steven Cooreman
7dadf14e7b Minor language correction after review
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
2021-01-28 19:46:52 +01:00
Steven Cooreman
d80e8a4112 Check for existence of key material on store/load
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
2021-01-26 14:28:48 +01:00
Ronald Cron
967835596c psa: Fix references to macros in comments
This commit tries to fix the usage of #MACRO_NAME
to reference macros in comments.

Signed-off-by: Ronald Cron <ronald.cron@arm.com>
2020-11-10 16:18:07 +01:00
Steven Cooreman
40120f6b76 Address review comments
* zero key buffer on failure
* readability improvements
* psa_finish_key_creation adjustment after removing import_key_into_slot

Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
2020-10-30 10:20:01 +01:00
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
Ronald Cron
039a98b598 Define always psa_key_id_t as defined in PSA crypto spec
Define always psa_key_id_t as defined in the PSA
Cryptography API specification independently of
whether the MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER
configuration file is set or not.

As a consequence, get rid of `psa_app_key_id_t` that is
not needed anymore.

Signed-off-by: Ronald Cron <ronald.cron@arm.com>
2020-09-02 14:27:07 +02:00
Ronald Cron
27238fcbd8 psa: Use psa_key_file_id_t as the key id type
The purpose of this commit and the following is for
psa_key_id_t to always be as defined by the PSA
Cryptography API specification.

Currently psa_key_id_t departs from its specification
definition when MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER
configuration flag is set. In that configuration, it is set
to be equal to psa_key_file_id_t which in that configuration
encodes an owner identifier along the key identifier.

Type psa_key_file_id_t was meant to be the key identifier type
used throughout the library code. If
MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER is set it
includes both a key and owner identifier, otherwise it is
equal to psa_key_id_t.

It has not been the key identifier type throughout the
library so far because when the PSA Cryptography
specification was developped the library Doxygen
documentation was used to generate the PSA Cryptography API
specification thus the need to use psa_key_id_t and not
psa_key_file_id_t.

As this constraint does not hold anymore, move
to psa_key_file_id_t as the key identifier type throughout
the library code.

By the way, this commit updates the key identifier
initialization in the tests to be compatible with a
composit key identifier. A psa_key_id_make()
inline function is introduced to initialize key
identifiers (composit ot not) at runtime.

Signed-off-by: Ronald Cron <ronald.cron@arm.com>
2020-09-02 14:27:07 +02:00
Bence Szépkúti
1e14827beb Update copyright notices to use Linux Foundation guidance
As a result, the copyright of contributors other than Arm is now
acknowledged, and the years of publishing are no longer tracked in the
source files.

Also remove the now-redundant lines declaring that the files are part of
MbedTLS.

This commit was generated using the following script:

# ========================
#!/bin/sh

# Find files
find '(' -path './.git' -o -path './3rdparty' ')' -prune -o -type f -print | xargs sed -bi '

# Replace copyright attribution line
s/Copyright.*Arm.*/Copyright The Mbed TLS Contributors/I

# Remove redundant declaration and the preceding line
$!N
/This file is part of Mbed TLS/Id
P
D
'
# ========================

Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com>
2020-08-19 10:35:41 +02:00
Gilles Peskine
4ed0e6f11a Switch storage functions over to psa_core_key_attributes_t 2019-07-31 14:15:27 +02:00
Gilles Peskine
c744d99386 Limit keys to 65528 bits
65528 bits is more than any reasonable key until we start supporting
post-quantum cryptography.

This limit is chosen to allow bit-sizes to be stored in 16 bits, with
65535 left to indicate an invalid value. It's a whole number of bytes,
which facilitates some calculations, in particular allowing a key of
exactly PSA_CRYPTO_MAX_STORAGE_SIZE to be created but not one bit
more.

As a resource usage limit, this is arguably too large, but that's out
of scope of the current commit.

Test that key import, generation and derivation reject overly large
sizes.
2019-07-30 20:58:33 +02:00
Gilles Peskine
2ea06fd48d Improve documentation of transaction storage 2019-07-26 13:23:51 +02:00
Gilles Peskine
bfd322ff34 Use a key attribute structure in the internal storage interface
Pass information via a key attribute structure rather than as separate
parameters to psa_crypto_storage functions. This makes it easier to
maintain the code when the metadata of a key evolves.

This has negligible impact on code size (+4B with "gcc -Os" on x86_64).
2019-07-23 13:31:54 +02:00
Gilles Peskine
fc76265385 Do secure element key creation and destruction in a transaction
Key creation and key destruction for a key in a secure element both
require updating three pieces of data: the key data in the secure
element, the key metadata in internal storage, and the SE driver's
persistent data. Perform these actions in a transaction so that
recovery is possible if the action is interrupted midway.
2019-07-22 19:46:22 +02:00
Gilles Peskine
c8336cb8f9 Implement a transaction record storage for resilience
Implement a transaction record that can be used for actions that
modify more than one piece of persistent data (whether in the
persistent storage or elsewhere such as in a secure element).

While performing a transaction, the transaction file is present in
storage. If the system starts with an ongoing transaction, it must
complete the transaction (not implemented yet).
2019-07-22 19:46:22 +02:00
Gilles Peskine
f9666595e1 Implement and test the new key identifier range
Only allow creating keys in the application (user) range. Allow
opening keys in the implementation (vendor) range as well.

Compared with what the implementation allowed, which was undocumented:
0 is now allowed; values from 0x40000000 to 0xfffeffff are now
forbidden.
2019-05-06 18:56:30 +02:00
Gilles Peskine
e3dbdd8d90 Gate entropy injection through a dedicated configuration option
Entropy injection has specific testing requirements. Therefore it
should depend on a specific option.
2019-03-15 11:15:21 +01:00
Gilles Peskine
5e80d91dbf Remove psa_crypto_storage_backend.h
Since there is now a single storage backend, we don't need a backend
interface. Make the functions that were declared in
psa_crypto_storage_backend.h and are now both defined and used in
psa_crypto_storage.c static, except for psa_is_key_present_in_storage
which is used by the gray-box tests and is now declared in
psa_crypto_storage.h.
2019-03-15 11:15:04 +01:00
Gilles Peskine
5b229a06f4 Support encoding an owner in key file IDs
Differentiate between _key identifiers_, which are always `uint32_t`,
and _key file identifiers_, which are platform-dependent. Normally,
the two are the same.

In `psa/crypto_platform.h`, define `psa_app_key_id_t` (which is always
32 bits, the standard key identifier type) and
`psa_key_file_id_t` (which will be different in some service builds).
A subsequent commit will introduce a platform where the two are different.

It would make sense for the function declarations in `psa/crypto.h` to
use `psa_key_file_id_t`. However this file is currently part of the
PSA Crypto API specification, so it must stick to the standard type
`psa_key_id_t`. Hence, as long as the specification and Mbed Crypto
are not separate, use the implementation-specific file
`psa/crypto_platform.h` to define `psa_key_id_t` as `psa_key_file_id_t`.

In the library, systematically use `psa_key_file_id_t`.

    perl -i -pe 's/psa_key_id_t/psa_key_file_id_t/g' library/*.[hc]
2019-02-20 12:52:07 +01:00
Gilles Peskine
e988a66b5b Fix PSA_MAX_PERSISTENT_KEY_IDENTIFIER to mean what it says
PSA_MAX_PERSISTENT_KEY_IDENTIFIER was actually one plus the maximum
key identifier. Change it to be the maximum value, and change the code
that uses it accordingly.

There is no semantic change here (the maximum value hasn't changed).
This commit only makes the implementation clearer.
2019-02-20 12:51:37 +01:00
David Saada
b4ecc27629 Replace PSA error code definitions with the ones defined in PSA spec 2019-02-18 13:53:13 +02:00
Gilles Peskine
48868129cd Document the maximum key identifier
Give it a name and explain why it was chosen.
2018-12-11 16:48:14 +01:00
Gilles Peskine
8d4919bc6a Persistent storage implementation: psa_key_slot_t -> psa_key_id_t
Move the persistent storage implementation from psa_key_slot_t to
psa_key_id_t. For the most part, this just means changing the types of
function arguments.

Update the documentation of some functions to reflect the fact that
the slot identifier is purely a storage identifier and is not related
to how the slot is designated in memory.
2018-12-11 16:48:13 +01:00
Darryl Green
db2b8db715 psa: Add storage implementation for files
Add new functions, psa_load_persistent_key(),
psa_free_persistent_key_data(), and psa_save_persistent_key(), for
managing persistent keys. These functions load to or save from our
internal representation of key slots. Serialization is a concern of the
storage backend implementation and doesn't abstraction-leak into the
lifetime management code.

An initial implementation for files is provided. Additional storage
backends can implement this interface for other storage types.
2018-11-20 15:21:22 +00:00