2018-01-27 23:32:46 +01:00
|
|
|
/**
|
|
|
|
* \file psa/crypto_platform.h
|
|
|
|
*
|
2019-05-30 14:14:00 +02:00
|
|
|
* \brief PSA cryptography module: Mbed TLS platform definitions
|
2018-06-28 18:02:53 +02:00
|
|
|
*
|
|
|
|
* \note This file may not be included directly. Applications must
|
|
|
|
* include psa/crypto.h.
|
|
|
|
*
|
|
|
|
* This file contains platform-dependent type definitions.
|
|
|
|
*
|
|
|
|
* In implementations with isolation between the application and the
|
|
|
|
* cryptography module, implementers should take care to ensure that
|
|
|
|
* the definitions that are exposed to applications match what the
|
|
|
|
* module implements.
|
2018-01-27 23:32:46 +01:00
|
|
|
*/
|
|
|
|
/*
|
|
|
|
* Copyright (C) 2018, ARM Limited, All Rights Reserved
|
|
|
|
* SPDX-License-Identifier: Apache-2.0
|
|
|
|
*
|
|
|
|
* Licensed under the Apache License, Version 2.0 (the "License"); you may
|
|
|
|
* not use this file except in compliance with the License.
|
|
|
|
* You may obtain a copy of the License at
|
|
|
|
*
|
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
*
|
|
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
|
|
* distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
|
|
|
|
* WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
* See the License for the specific language governing permissions and
|
|
|
|
* limitations under the License.
|
|
|
|
*
|
|
|
|
* This file is part of mbed TLS (https://tls.mbed.org)
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef PSA_CRYPTO_PLATFORM_H
|
|
|
|
#define PSA_CRYPTO_PLATFORM_H
|
|
|
|
|
|
|
|
/* Include the Mbed TLS configuration file, the way Mbed TLS does it
|
|
|
|
* in each of its header files. */
|
|
|
|
#if !defined(MBEDTLS_CONFIG_FILE)
|
2019-06-07 12:49:59 +02:00
|
|
|
#include "mbedtls/config.h"
|
2018-01-27 23:32:46 +01:00
|
|
|
#else
|
|
|
|
#include MBEDTLS_CONFIG_FILE
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/* PSA requires several types which C99 provides in stdint.h. */
|
|
|
|
#include <stdint.h>
|
|
|
|
|
2018-11-30 14:08:36 +01:00
|
|
|
/* Integral type representing a key handle. */
|
|
|
|
typedef uint16_t psa_key_handle_t;
|
|
|
|
|
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-19 13:24:37 +01:00
|
|
|
/* This implementation distinguishes *application key identifiers*, which
|
|
|
|
* are the key identifiers specified by the application, from
|
|
|
|
* *key file identifiers*, which are the key identifiers that the library
|
|
|
|
* sees internally. The two types can be different if there is a remote
|
|
|
|
* call layer between the application and the library which supports
|
|
|
|
* multiple client applications that do not have access to each others'
|
|
|
|
* keys. The point of having different types is that the key file
|
|
|
|
* identifier may encode not only the key identifier specified by the
|
|
|
|
* application, but also the the identity of the application.
|
|
|
|
*
|
|
|
|
* Note that this is an internal concept of the library and the remote
|
|
|
|
* call layer. The application itself never sees anything other than
|
|
|
|
* #psa_app_key_id_t with its standard definition.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* The application key identifier is always what the application sees as
|
|
|
|
* #psa_key_id_t. */
|
|
|
|
typedef uint32_t psa_app_key_id_t;
|
|
|
|
|
2019-02-19 14:00:31 +01:00
|
|
|
#if defined(MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER)
|
|
|
|
|
2019-02-19 14:16:17 +01:00
|
|
|
#if defined(PSA_CRYPTO_SECURE)
|
|
|
|
/* Building for the PSA Crypto service on a PSA platform. */
|
|
|
|
/* A key owner is a PSA partition identifier. */
|
|
|
|
typedef int32_t psa_key_owner_id_t;
|
|
|
|
#endif
|
|
|
|
|
2019-02-19 14:00:31 +01:00
|
|
|
typedef struct
|
|
|
|
{
|
|
|
|
uint32_t key_id;
|
|
|
|
psa_key_owner_id_t owner;
|
|
|
|
} psa_key_file_id_t;
|
|
|
|
#define PSA_KEY_FILE_GET_KEY_ID( file_id ) ( ( file_id ).key_id )
|
|
|
|
|
|
|
|
/* Since crypto.h is used as part of the PSA Cryptography API specification,
|
|
|
|
* it must use standard types for things like the argument of psa_open_key().
|
|
|
|
* If it wasn't for that constraint, psa_open_key() would take a
|
|
|
|
* `psa_key_file_id_t` argument. As a workaround, make `psa_key_id_t` an
|
|
|
|
* alias for `psa_key_file_id_t` when building for a multi-client service. */
|
|
|
|
typedef psa_key_file_id_t psa_key_id_t;
|
2019-08-20 12:11:55 +02:00
|
|
|
#define PSA_KEY_ID_INIT {0, 0}
|
2019-02-19 14:00:31 +01:00
|
|
|
|
|
|
|
#else /* !MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER */
|
|
|
|
|
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-19 13:24:37 +01:00
|
|
|
/* By default, a key file identifier is just the application key identifier. */
|
|
|
|
typedef psa_app_key_id_t psa_key_file_id_t;
|
|
|
|
#define PSA_KEY_FILE_GET_KEY_ID( id ) ( id )
|
|
|
|
|
2019-02-19 14:00:31 +01:00
|
|
|
#endif /* !MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER */
|
|
|
|
|
2018-01-27 23:32:46 +01:00
|
|
|
#endif /* PSA_CRYPTO_PLATFORM_H */
|