Commit Graph

10 Commits

Author SHA1 Message Date
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
088b77f39c Merge psa_crypto_storage_its into psa_crypto_storage
Since the ITS API has stabilized and we don't plan to make use of more
than ITS, we don't need an abstraction layer between key storage and
key storage over ITS. Merge the ITS code into the generic storage
module.
2019-03-15 11:15:01 +01:00
Jaeden Amero
72f40c6686
Merge pull request #59 from gilles-peskine-arm/psa-its-64_bit_internal_key_id
Support key file IDs encoding the key owner
2019-02-20 13:45:12 +00: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
itayzafrir
7723ab1739 Add common header for crypto service integration 2019-02-19 15:09:14 +02:00
itayzafrir
7132dd9796 Prepare support for 64 bit key ids in a PSA system.
Preparation for type separation between SPE and NSPE.
2019-02-19 15:08:07 +02:00
Jaeden Amero
db29ab528a psa: Fix builds without MBEDTLS_PLATFORM_C
When `MBEDTLS_PLATFORM_C` is not enabled, our PSA Crypto implementation
depends on the standard C library for functions like snprintf() and
exit(). However, our implementation was not including the proper header
files nor redefining all `mbedtls_*` symbols properly to ensure
successful builds without MBEDTLS_PLATFORM_C. Add the necessary header
files and macro definitions to our PSA Crypto implementation.
2019-02-14 16:01:14 +00: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
Moran Peker
96ebf9efcf psa: Add magic header to storage backend
Add a magic header to the storage format used with files. The
header is used as an initial check that the data is what we expect,
rather than garbage data.
2018-11-20 15:21:22 +00: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