yuzu/mbedtls
1
0
Fork 0
mirror of https://github.com/yuzu-emu/mbedtls.git synced 2024-12-23 00:45:39 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'development' into development-restricted

Browse source 
* development: (488 commits)
  Fix removal of deprecated PSA constants
  Use GitHub-compatible table formatting
  Remove psa header files in uninstall part
  Change function casting in `ssl_calc_finished_tls_sha384`
  Fix GCC warning in `ssl_calc_finished_tls_sha384`
  Add changelog entry file to `ChangeLog.d`
  Fix GCC warning in `ssl_calc_finished_tls_sha384`
  Fix GCC warning about `test_snprintf`
  Fix mismatched function parameters (prototype/definition)
  Fix build failure on gcc-11
  Copyediting
  Clarifications around key import
  Fix copypasta
  A variable is unused in some configurations
  Rename test_driver_keygen to test_driver_key_management
  Move "internal use" sentence attached to the wrong function
  Added changelog
  Plug in the entry point for public key export through driver
  tests: psa: Reset key attributes where needed
  Improve/fix documentation
  ...
This commit is contained in:
Manuel Pégourié-Gonnard 2020-12-03 09:59:42 +01:00
parent 72c868a0fb d9d4e807fa
commit 489c058b52
249 changed files with 14264 additions and 3488 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
.gitignore vendored
View file

@ -54,4 +54,5 @@ massif-*
/GSYMS
/GTAGS
/TAGS
/cscope*.out
/tags

4
.travis.yml
View file

@ -28,10 +28,6 @@ jobs:
script:
- tests/scripts/all.sh -k test_full_cmake_gcc_asan
- name: check compilation guards
script:
- tests/scripts/all.sh -k 'test_depends_*' 'build_key_exchanges'
- name: macOS
os: osx
compiler: clang

26
CMakeLists.txt
View file

@ -14,9 +14,13 @@
# CMake files. It is related to ZLIB support which is planned to be removed.
# When the support is removed, the associated include_directories command
# will be removed as well as this note.
# - MBEDTLS_TARGET_PREFIX: CMake targets are designed to be alterable by calling
# CMake in order to avoid target name clashes, via the use of
# MBEDTLS_TARGET_PREFIX. The value of this variable is prefixed to the
# mbedtls, mbedx509, mbedcrypto and apidoc targets.
#
cmake_minimum_required(VERSION 2.6)
cmake_minimum_required(VERSION 2.8.12)
if(TEST_CPP)
project("mbed TLS" C CXX)
else()
@ -112,9 +116,12 @@ option: \n\
endif()
endif()
set(CMAKE_BUILD_TYPE ${CMAKE_BUILD_TYPE}
CACHE STRING "Choose the type of build: None Debug Release Coverage ASan ASanDbg MemSan MemSanDbg Check CheckFull"
FORCE)
# If this is the root project add longer list of available CMAKE_BUILD_TYPE values
if(CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
set(CMAKE_BUILD_TYPE ${CMAKE_BUILD_TYPE}
CACHE STRING "Choose the type of build: None Debug Release Coverage ASan ASanDbg MemSan MemSanDbg Check CheckFull"
FORCE)
endif()
# Create a symbolic link from ${base_name} in the binary directory
# to the corresponding path in the source directory.
@ -152,6 +159,8 @@ endfunction(link_to_source)
string(REGEX MATCH "Clang" CMAKE_COMPILER_IS_CLANG "${CMAKE_C_COMPILER_ID}")
include(CheckCCompilerFlag)
if(CMAKE_COMPILER_IS_GNU)
# some warnings we want are not available with old GCC versions
# note: starting with CMake 2.8 we could use CMAKE_C_COMPILER_VERSION
@ -168,7 +177,10 @@ if(CMAKE_COMPILER_IS_GNU)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wshadow")
endif()
if (GCC_VERSION VERSION_GREATER 5.0)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wformat-signedness")
CHECK_C_COMPILER_FLAG("-Wformat-signedness" C_COMPILER_SUPPORTS_WFORMAT_SIGNEDNESS)
if(C_COMPILER_SUPPORTS_WFORMAT_SIGNEDNESS)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wformat-signedness")
endif()
endif()
set(CMAKE_C_FLAGS_RELEASE "-O2")
set(CMAKE_C_FLAGS_DEBUG "-O0 -g3")
@ -256,7 +268,7 @@ add_subdirectory(library)
# to define the test executables.
#
if(ENABLE_TESTING OR ENABLE_PROGRAMS)
file(GLOB MBEDTLS_TEST_FILES ${CMAKE_CURRENT_SOURCE_DIR}/tests/src/*.c)
file(GLOB MBEDTLS_TEST_FILES ${CMAKE_CURRENT_SOURCE_DIR}/tests/src/*.c ${CMAKE_CURRENT_SOURCE_DIR}/tests/src/drivers/*.c)
add_library(mbedtls_test OBJECT ${MBEDTLS_TEST_FILES})
target_include_directories(mbedtls_test
PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/tests/include
@ -268,7 +280,7 @@ if(ENABLE_PROGRAMS)
add_subdirectory(programs)
endif()
ADD_CUSTOM_TARGET(apidoc
ADD_CUSTOM_TARGET(${MBEDTLS_TARGET_PREFIX}apidoc
COMMAND doxygen mbedtls.doxyfile
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/doxygen)

113
ChangeLog
View file

@ -1,5 +1,118 @@
mbed TLS ChangeLog (Sorted per branch, date)
= mbed TLS 2.24.0 branch released 2020-09-01
API changes
* In the PSA API, rename the types of elliptic curve and Diffie-Hellman
group families to psa_ecc_family_t and psa_dh_family_t, in line with the
PSA Crypto API specification version 1.0.0.
Rename associated macros as well:
PSA_ECC_CURVE_xxx renamed to PSA_ECC_FAMILY_xxx
PSA_DH_GROUP_xxx renamed to PSA_DH_FAMILY_xxx
PSA_KEY_TYPE_GET_CURVE renamed to to PSA_KEY_TYPE_ECC_GET_FAMILY
PSA_KEY_TYPE_GET_GROUP renamed to PSA_KEY_TYPE_DH_GET_FAMILY
Default behavior changes
* Stop storing persistent information about externally stored keys created
through PSA Crypto with a volatile lifetime. Reported in #3288 and
contributed by Steven Cooreman in #3382.
Features
* The new function mbedtls_ecp_write_key() exports private ECC keys back to
a byte buffer. It is the inverse of the existing mbedtls_ecp_read_key().
* Support building on e2k (Elbrus) architecture: correctly enable
-Wformat-signedness, and fix the code that causes signed-one-bit-field
and sign-compare warnings. Contributed by makise-homura (Igor Molchanov)
<akemi_homura@kurisa.ch>.
Security
* Fix a vulnerability in the verification of X.509 certificates when
matching the expected common name (the cn argument of
mbedtls_x509_crt_verify()) with the actual certificate name: when the
subjecAltName extension is present, the expected name was compared to any
name in that extension regardless of its type. This means that an
attacker could for example impersonate a 4-bytes or 16-byte domain by
getting a certificate for the corresponding IPv4 or IPv6 (this would
require the attacker to control that IP address, though). Similar attacks
using other subjectAltName name types might be possible. Found and
reported by kFYatek in #3498.
* When checking X.509 CRLs, a certificate was only considered as revoked if
its revocationDate was in the past according to the local clock if
available. In particular, on builds without MBEDTLS_HAVE_TIME_DATE,
certificates were never considered as revoked. On builds with
MBEDTLS_HAVE_TIME_DATE, an attacker able to control the local clock (for
example, an untrusted OS attacking a secure enclave) could prevent
revocation of certificates via CRLs. Fixed by no longer checking the
revocationDate field, in accordance with RFC 5280. Reported by
yuemonangong in #3340. Reported independently and fixed by
Raoul Strackx and Jethro Beekman in #3433.
* In (D)TLS record decryption, when using a CBC ciphersuites without the
Encrypt-then-Mac extension, use constant code flow memory access patterns
to extract and check the MAC. This is an improvement to the existing
countermeasure against Lucky 13 attacks. The previous countermeasure was
effective against network-based attackers, but less so against local
attackers. The new countermeasure defends against local attackers, even
if they have access to fine-grained measurements. In particular, this
fixes a local Lucky 13 cache attack found and reported by Tuba Yavuz,
Farhaan Fowze, Ken (Yihan) Bai, Grant Hernandez, and Kevin Butler
(University of Florida) and Dave Tian (Purdue University).
* Fix side channel in RSA private key operations and static (finite-field)
Diffie-Hellman. An adversary with precise enough timing and memory access
information (typically an untrusted operating system attacking a secure
enclave) could bypass an existing counter-measure (base blinding) and
potentially fully recover the private key.
* Fix a 1-byte buffer overread in mbedtls_x509_crl_parse_der().
Credit to OSS-Fuzz for detecting the problem and to Philippe Antoine
for pinpointing the problematic code.
* Zeroising of plaintext buffers in mbedtls_ssl_read() to erase unused
application data from memory. Reported in #689 by
Johan Uppman Bruce of Sectra.
Bugfix
* Library files installed after a CMake build no longer have execute
permission.
* Use local labels in mbedtls_padlock_has_support() to fix an invalid symbol
redefinition if the function is inlined.
Reported in #3451 and fix contributed in #3452 by okhowang.
* Fix the endianness of Curve25519 keys imported/exported through the PSA
APIs. psa_import_key and psa_export_key will now correctly expect/output
Montgomery keys in little-endian as defined by RFC7748. Contributed by
Steven Cooreman in #3425.
* Fix build errors when the only enabled elliptic curves are Montgomery
curves. Raised by signpainter in #941 and by Taiki-San in #1412. This
also fixes missing declarations reported by Steven Cooreman in #1147.
* Fix self-test failure when the only enabled short Weierstrass elliptic
curve is secp192k1. Fixes #2017.
* PSA key import will now correctly import a Curve25519/Curve448 public key
instead of erroring out. Contributed by Steven Cooreman in #3492.
* Use arc4random_buf on NetBSD instead of rand implementation with cyclical
lower bits. Fix contributed in #3540.
* Fix a memory leak in mbedtls_md_setup() when using HMAC under low memory
conditions. Reported and fix suggested by Guido Vranken in #3486.
* Fix bug in redirection of unit test outputs on platforms where stdout is
defined as a macro. First reported in #2311 and fix contributed in #3528.
Changes
* Only pass -Wformat-signedness to versions of GCC that support it. Reported
in #3478 and fix contributed in #3479 by okhowang.
* Reduce the stack consumption of mbedtls_x509write_csr_der() which
previously could lead to stack overflow on constrained devices.
Contributed by Doru Gucea and Simon Leet in #3464.
* Undefine the ASSERT macro before defining it locally, in case it is defined
in a platform header. Contributed by Abdelatif Guettouche in #3557.
* 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. This also
eliminates the need for the lines declaring the files to be part of
MbedTLS. Fixes #3457.
* Add the command line parameter key_pwd to the ssl_client2 and ssl_server2
example applications which allows to provide a password for the key file
specified through the existing key_file argument. This allows the use of
these applications with password-protected key files. Analogously but for
ssl_server2 only, add the command line parameter key_pwd2 which allows to
set a password for the key file provided through the existing key_file2
argument.
= mbed TLS 2.23.0 branch released 2020-07-01
Default behavior changes

29
ChangeLog.d/00README.md
View file

@ -3,6 +3,29 @@
This directory contains changelog entries that have not yet been merged
to the changelog file ([`../ChangeLog`](../ChangeLog)).
## What requires a changelog entry?
Write a changelog entry if there is a user-visible change. This includes:
* Bug fixes in the library or in sample programs: fixing a security hole,
fixing broken behavior, fixing the build in some configuration or on some
platform, etc.
* New features in the library, new sample programs, or new platform support.
* Changes in existing behavior. These should be rare. Changes in features
that are documented as experimental may or may not be announced, depending
on the extent of the change and how widely we expect the feature to be used.
We generally don't include changelog entries for:
* Documentation improvements.
* Performance improvements, unless they are particularly significant.
* Changes to parts of the code base that users don't interact with directly,
such as test code and test data.
Until Mbed TLS 2.24.0, we required changelog entries in more cases.
Looking at older changelog entries is good practice for how to write a
changelog entry, but not for deciding whether to write one.
## Changelog entry file format
A changelog entry file must have the extension `*.txt` and must have the
@ -33,8 +56,7 @@ The permitted changelog entry categories are as follows:
Bugfix
Changes
Use “Changes” for anything that doesn't fit in the other categories, such as
performance, documentation and test improvements.
Use “Changes” for anything that doesn't fit in the other categories.
## How to write a changelog entry
@ -49,8 +71,7 @@ Include GitHub issue numbers where relevant. Use the format “#1234” for an
Mbed TLS issue. Add other external references such as CVE numbers where
applicable.
Credit the author of the contribution if the contribution is not a member of
the Mbed TLS development team. Also credit bug reporters where applicable.
Credit bug reporters where applicable.
**Explain why, not how**. Remember that the audience is the users of the
library, not its developers. In particular, for a bug fix, explain the

3
ChangeLog.d/_GNU_SOURCE-redefined.txt Normal file
View file

@ -0,0 +1,3 @@
Bugfix
* Fix the build when the macro _GNU_SOURCE is defined to a non-empty value.
Fix #3432.

2
ChangeLog.d/add-aes-ecb-to-psa.txt Normal file
View file

@ -0,0 +1,2 @@
Features
* Add support for ECB to the PSA cipher API.

6
ChangeLog.d/add_MBEDTLS_TARGET_PREFIX_to_cmake.txt Normal file
View file

@ -0,0 +1,6 @@
Features
* Add MBEDTLS_TARGET_PREFIX CMake variable, which is prefixed to the mbedtls,
mbedcrypto, mbedx509 and apidoc CMake target names. This can be used by
external CMake projects that include this one to avoid CMake target name
clashes. The default value of this variable is "", so default target names
are unchanged.

4
ChangeLog.d/add_cipher_transparent_driver.txt Normal file
View file

@ -0,0 +1,4 @@
Features
* Partial implementation of the new PSA Crypto accelerator APIs for
enabling symmetric cipher acceleration through crypto accelerators.
Contributed by Steven Cooreman in #3644.

3
ChangeLog.d/add_export_public_key_driver.txt Normal file
View file

@ -0,0 +1,3 @@
Features
* Implementation of the export_public_key interface for PSA Crypto
accelerator drivers, as defined in #3493. Contributed in #3786.

4
ChangeLog.d/add_sign_verify_keygen_transparent_driver.txt Normal file
View file

@ -0,0 +1,4 @@
Features
* Partial implementation of the new PSA Crypto accelerator APIs for
enabling key generation and asymmetric signing/verification through crypto
accelerators. Contributed by Steven Cooreman in #3501.

3
ChangeLog.d/adjusting sliding_window_size_PR3592.txt Normal file
View file

@ -0,0 +1,3 @@
Changes
* Reduce stack usage significantly during sliding window exponentiation.
Reported in #3591 and fix contributed in #3592 by Daniel Otte.

5
ChangeLog.d/aes-zeroize-pointer.txt Normal file
View file

@ -0,0 +1,5 @@
Changes
* Remove the zeroization of a pointer variable in AES rounds. It was valid
but spurious and misleading since it looked like a mistaken attempt to
zeroize the pointed-to buffer. Reported by Antonio de la Piedra, CEA
Leti, France.

3
ChangeLog.d/android-socklen_t.txt Normal file
View file

@ -0,0 +1,3 @@
Bugfix
* Use socklen_t on Android and other POSIX-compliant system

3
ChangeLog.d/arc4random_buf-implicit.txt Normal file
View file

@ -0,0 +1,3 @@
Bugfix
* Make arc4random_buf available on NetBSD and OpenBSD when _POSIX_C_SOURCE is
defined. Fix contributed in #3571.

3
ChangeLog.d/bugfix_3524.txt Normal file
View file

@ -0,0 +1,3 @@
Bugfix
* Include the psa_constant_names generated source code in the source tree
instead of generating it at build time. Fixes #3524.

2
ChangeLog.d/bugfix_3782.txt Normal file
View file

@ -0,0 +1,2 @@
Bugfix
* Fix build failures on GCC 11. Fixes #3782.

4
ChangeLog.d/bugfix_3794.txt Normal file
View file

@ -0,0 +1,4 @@
Bugfix
* Fix handling of EOF against 0xff bytes and on platforms with
unsigned chars. Fixes a build failure on platforms where char is
unsigned. Fixes #3794.

4
ChangeLog.d/bugfix_PR3294.txt Normal file
View file

@ -0,0 +1,4 @@
Bugfix
* Fix build failure in configurations where MBEDTLS_USE_PSA_CRYPTO is
enabled but ECDSA is disabled. Contributed by jdurkop. Fixes #3294.

3
ChangeLog.d/bugfix_PR3452.txt
View file

@ -1,3 +0,0 @@
Bugfix
* Use local labels in mbedtls_padlock_has_support() to fix an invalid symbol redefinition if the function is inlined.
Reported in #3451 and fix contributed in #3452 by okhowang.

6
ChangeLog.d/build_with_only_montgomery_curves.txt
View file

@ -1,6 +0,0 @@
Bugfix
* Fix build errors when the only enabled elliptic curves are Montgomery
curves. Raised by signpainter in #941 and by Taiki-San in #1412. This
also fixes missing declarations reported by Steven Cooreman in #1147.
* Fix self-test failure when the only enabled short Weierstrass elliptic
curve is secp192k1. Fixes #2017.

3
ChangeLog.d/cmake-install.txt
View file

@ -1,3 +0,0 @@
Bugfix
* Library files installed after a CMake build no longer have execute
permission.

6
ChangeLog.d/copyright.txt
View file

@ -1,6 +0,0 @@
Changes
* 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. This also
eliminates the need for the lines declaring the files to be part of
MbedTLS. Fixes #3457.

4
ChangeLog.d/do_not_persist_volatile_external_keys.txt
View file

@ -1,4 +0,0 @@
Default behavior changes
* Stop storing persistent information about externally stored keys created
through PSA Crypto with a volatile lifetime. Reported in #3288 and
contributed by Steven Cooreman in #3382.

3
ChangeLog.d/ecb_iv_fix.txt Normal file
View file

@ -0,0 +1,3 @@
Bugfix
* Correct the default IV size for mbedtls_cipher_info_t structures using
MBEDTLS_MODE_ECB to 0, since ECB mode ciphers don't use IVs.

5
ChangeLog.d/ecp_curve_list.txt Normal file
View file

@ -0,0 +1,5 @@
Bugfix
* mbedtls_ecp_curve_list() now lists Curve25519 and Curve448 under the names
"x25519" and "x448". These curves support ECDH but not ECDSA. If you need
only the curves that support ECDSA, filter the list with
mbedtls_ecdsa_can_do().

2
ChangeLog.d/error-include-string.txt Normal file
View file

@ -0,0 +1,2 @@
Bugfix
* Fix conditions for including string.h in error.c. Fixes #3866.

2
ChangeLog.d/feature-dtls-srtp.txt Normal file
View file

@ -0,0 +1,2 @@
Features
* Add support for DTLS-SRTP as defined in RFC 5764. Contributed by Johan Pascal, improved by Ron Eldor.

6
ChangeLog.d/fix-rsa-blinding.txt Normal file
View file

@ -0,0 +1,6 @@
Bugfix
* Fix rsa_prepare_blinding() to retry when the blinding value is not
invertible (mod N), instead of returning MBEDTLS_ERR_RSA_RNG_FAILED. This
addresses a regression but is rare in practice (approx. 1 in 2/sqrt(N)).
Found by Synopsys Coverity, fix contributed by Peter Kolbus (Garmin).
Fixes #3647.

5
ChangeLog.d/fix_ccm_add_length_check.txt Normal file
View file

@ -0,0 +1,5 @@
Bugfix
* Fix an off-by-one error in the additional data length check for
CCM, which allowed encryption with a non-standard length field.
Fixes #3719.

3
ChangeLog.d/format-signedness.txt
View file

@ -1,3 +0,0 @@
Changes
* Only pass -Wformat-signedness to versions of GCC that support it. Reported
in #3478 and fix contributed in #3479 by okhowang.

11
ChangeLog.d/local-lucky13.txt
View file

@ -1,11 +0,0 @@
Security
* In (D)TLS record decryption, when using a CBC ciphersuites without the
Encrypt-then-Mac extension, use constant code flow memory access patterns
to extract and check the MAC. This is an improvement to the existing
countermeasure against Lucky 13 attacks. The previous countermeasure was
effective against network-based attackers, but less so against local
attackers. The new countermeasure defends against local attackers, even
if they have access to fine-grained measurements. In particular, this
fixes a local Lucky 13 cache attack found and reported by Tuba Yavuz,
Farhaan Fowze, Ken (Yihan) Bai, Grant Hernandez, and Kevin Butler
(University of Florida) and Dave Tian (Purdue University).

3
ChangeLog.d/minimum_cmake_version_PR3802.txt Normal file
View file

@ -0,0 +1,3 @@
Requirement changes
* Update the minimum required CMake version to 2.8.12.
* This silences a warning on CMake 3.19.0. #3801

3
ChangeLog.d/netbsd-rand-arc4random_buf.txt
View file

@ -1,3 +0,0 @@
Bugfix
* Use arc4random_buf on NetBSD instead of rand implementation with cyclical
lower bits. Fix contributed in #3540.

6
ChangeLog.d/protect-base-blinding.txt
View file

@ -1,6 +0,0 @@
Security
* Fix side channel in RSA private key operations and static (finite-field)
Diffie-Hellman. An adversary with precise enough timing and memory access
information (typically an untrusted operating system attacking a secure
enclave) could bypass an existing counter-measure (base blinding) and
potentially fully recover the private key.

17
ChangeLog.d/psa-openless.txt Normal file
View file

@ -0,0 +1,17 @@
Features
* In the PSA API, it is no longer necessary to open persistent keys:
operations now accept the key identifier. The type psa_key_handle_t is now
identical to psa_key_id_t instead of being platform-defined. This bridges
the last major gap to compliance with the PSA Cryptography specification
version 1.0.0. Opening persistent keys is still supported for backward
compatibility, but will be deprecated and later removed in future
releases.
Bugfix
* psa_set_key_id() now also sets the lifetime to persistent for keys located
in a secure element.
* Attempting to create a volatile key with a non-zero key identifier now
fails. Previously the key identifier was just ignored when creating a
volatile key.
* Attempting to create or register a key with a key identifier in the vendor
range now fails.

9
ChangeLog.d/psa_curve25519_key_support.txt
View file

@ -1,9 +0,0 @@
Features
* The new function mbedtls_ecp_write_key() exports private ECC keys back to
a byte buffer. It is the inverse of the existing mbedtls_ecp_read_key().
Bugfix
* Fix the endianness of Curve25519 keys imported/exported through the PSA
APIs. psa_import_key and psa_export_key will now correctly expect/output
Montgomery keys in little-endian as defined by RFC7748. Contributed by
Steven Cooreman in #3425.

3
ChangeLog.d/psa_curve25519_public_key_import.txt
View file

@ -1,3 +0,0 @@
Bugfix
* PSA key import will now correctly import a Curve25519/Curve448 public key
instead of erroring out. Contributed by Steven Cooreman in #3492.

9
ChangeLog.d/psa_ecc_dh_macros.txt
View file

@ -1,9 +0,0 @@
API changes
* In the PSA API, rename the types of elliptic curve and Diffie-Hellman group families to
psa_ecc_family_t and psa_dh_family_t, in line with the PSA Crypto API specification version 1.0.0.
Rename associated macros as well:
PSA_ECC_CURVE_xxx renamed to PSA_ECC_FAMILY_xxx
PSA_DH_GROUP_xxx renamed to PSA_DH_FAMILY_xxx
PSA_KEY_TYPE_GET_CURVE renamed to to PSA_KEY_TYPE_ECC_GET_FAMILY
PSA_KEY_TYPE_GET_GROUP renamed to PSA_KEY_TYPE_DH_GET_FAMILY

4
ChangeLog.d/psa_error_invalid_argument_for_invalid_cipher_input_sizes.txt Normal file
View file

@ -0,0 +1,4 @@
Bugfix
* Consistently return PSA_ERROR_INVALID_ARGUMENT on invalid cipher input
sizes (instead of PSA_ERROR_BAD_STATE in some cases) to make the
psa_cipher_* functions compliant with the PSA Crypto API specification.

3
ChangeLog.d/psa_generate_key-curve25519.txt Normal file
View file

@ -0,0 +1,3 @@
Bugfix
* Fix psa_generate_key() returning an error when asked to generate
an ECC key pair on Curve25519 or secp244k1.

6
ChangeLog.d/support-ecdh-kdf-with-ecdh-key.txt Normal file
View file

@ -0,0 +1,6 @@
Features
* In PSA, allow using a key declared with a base key agreement algorithm
in combined key agreement and derivation operations, as long as the key
agreement algorithm in use matches the algorithm the key was declared with.
This is currently non-standard behaviour, but expected to make it into a
future revision of the PSA Crypto standard.

4
ChangeLog.d/support-key-agreement-and-derivation-output-as-key.txt Normal file
View file

@ -0,0 +1,4 @@
Bugfix
* Fix psa_key_derivation_output_key() to allow the output of a combined key
agreement and subsequent key derivation operation to be used as a key
inside of the PSA Crypto core.

5
ChangeLog.d/systematically_store_bit_size_3740.txt Normal file
View file

@ -0,0 +1,5 @@
Changes
* The PSA persistent storage format is updated to always store the key bits
attribute. No automatic upgrade path is provided. Previously stored keys
must be erased, or manually upgraded based on the key storage format
specification (docs/architecture/mbed-crypto-storage-specification.md). #3740

11
ChangeLog.d/x509-verify-non-dns-san.txt
View file

@ -1,11 +0,0 @@
Security
* Fix a vulnerability in the verification of X.509 certificates when
matching the expected common name (the cn argument of
mbedtls_x509_crt_verify()) with the actual certificate name: when the
subjecAltName extension is present, the expected name was compared to any
name in that extension regardless of its type. This means that an
attacker could for example impersonate a 4-bytes or 16-byte domain by
getting a certificate for the corresponding IPv4 or IPv6 (this would
require the attacker to control that IP address, though). Similar attacks
using other subjectAltName name types might be possible. Found and
reported by kFYatek in #3498.

4
ChangeLog.d/x509parse_crl-empty_entry.txt
View file

@ -1,4 +0,0 @@
Security
* Fix a 1-byte buffer overread in mbedtls_x509_crl_parse_der().
Credit to OSS-Fuzz for detecting the problem and to Philippe Antoine
for pinpointing the problematic code.

4
ChangeLog.d/x509write_csr_heap_alloc.txt
View file

@ -1,4 +0,0 @@
Changes
* Reduce the stack consumption of mbedtls_x509write_csr_der() which
previously could lead to stack overflow on constrained devices.
Contributed by Doru Gucea and Simon Leet in #3464.

4
ChangeLog.d/zeroising_of_plaintext_buffer.txt
View file

@ -1,4 +0,0 @@
Security
* Zeroising of plaintext buffers in mbedtls_ssl_read() to erase unused
application data from memory. Reported in #689 by
Johan Uppman Bruce of Sectra.

17
Makefile
View file

@ -45,6 +45,7 @@ install: no_test
uninstall:
rm -rf $(DESTDIR)/include/mbedtls
rm -rf $(DESTDIR)/include/psa
rm -f $(DESTDIR)/lib/libmbedtls.*
rm -f $(DESTDIR)/lib/libmbedx509.*
rm -f $(DESTDIR)/lib/libmbedcrypto.*
@ -126,12 +127,26 @@ apidoc_clean:
endif
## Editor navigation files
C_SOURCE_FILES = $(wildcard include/*/*.h library/*.[hc] programs/*/*.[hc] tests/suites/*.function)
C_SOURCE_FILES = $(wildcard \
3rdparty/*/include/*/*.h 3rdparty/*/include/*/*/*.h 3rdparty/*/include/*/*/*/*.h \
3rdparty/*/*.c 3rdparty/*/*/*.c 3rdparty/*/*/*/*.c 3rdparty/*/*/*/*/*.c \
include/*/*.h \
library/*.[hc] \
programs/*/*.[hc] \
tests/include/*/*.h tests/include/*/*/*.h \
tests/src/*.c tests/src/*/*.c \
tests/suites/*.function \
)
# Exuberant-ctags invocation. Other ctags implementations may require different options.
CTAGS = ctags --langmap=c:+.h.function -o
tags: $(C_SOURCE_FILES)
$(CTAGS) $@ $(C_SOURCE_FILES)
TAGS: $(C_SOURCE_FILES)
etags -o $@ $(C_SOURCE_FILES)
global: GPATH GRTAGS GSYMS GTAGS
GPATH GRTAGS GSYMS GTAGS: $(C_SOURCE_FILES)
ls $(C_SOURCE_FILES) | gtags -f - --gtagsconf .globalrc
cscope: cscope.in.out cscope.po.out cscope.out
cscope.in.out cscope.po.out cscope.out: $(C_SOURCE_FILES)
cscope -bq -u -Iinclude -Ilibrary $(patsubst %,-I%,$(wildcard 3rdparty/*/include)) -Itests/include $(C_SOURCE_FILES)
.PHONY: cscope global

2
README.md
View file

@ -208,7 +208,7 @@ The design goals of the PSA cryptography API include:
* The API distinguishes caller memory from internal memory, which allows the library to be implemented in an isolated space for additional security. Library calls can be implemented as direct function calls if isolation is not desired, and as remote procedure calls if isolation is desired.
* The structure of internal data is hidden to the application, which allows substituting alternative implementations at build time or run time, for example, in order to take advantage of hardware accelerators.
* All access to the keys happens through handles, which allows support for external cryptoprocessors that is transparent to applications.
* All access to the keys happens through key identifiers, which allows support for external cryptoprocessors that is transparent to applications.
* The interface to algorithms is generic, favoring algorithm agility.
* The interface is designed to be easy to use and hard to accidentally misuse.

12
configs/config-psa-crypto.h
View file

@ -1144,20 +1144,20 @@
*/
//#define MBEDTLS_ENTROPY_NV_SEED
/* MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER
/* MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER
*
* In PSA key storage, encode the owner of the key.
* Enable key identifiers that encode a key owner identifier.
*
* This is only meaningful when building the library as part of a
* multi-client service. When you activate this option, you must provide
* an implementation of the type psa_key_owner_id_t and a translation
* from psa_key_file_id_t to file name in all the storage backends that
* multi-client service. When you activate this option, you must provide an
* implementation of the type mbedtls_key_owner_id_t and a translation from
* mbedtls_svc_key_id_t to file name in all the storage backends that you
* you wish to support.
*
* Note that this option is meant for internal use only and may be removed
* without notice.
*/
//#define MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER
//#define MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER
/**
* \def MBEDTLS_MEMORY_DEBUG

2
configs/config-symmetric-only.h
View file

@ -92,6 +92,8 @@
#define MBEDTLS_VERSION_C
#define MBEDTLS_XTEA_C
#include "mbedtls/config_psa.h"
#include "check_config.h"
#endif /* MBEDTLS_CONFIG_H */

44
docs/architecture/mbed-crypto-storage-specification.md
View file

@ -107,14 +107,12 @@ Backward compatibility commitments: TBD
### Key names for 1.0.0
Information about each key is stored in a dedicated file designated by a _key file identifier_ (`psa_key_file_id_t`). The key file identifier is constructed from the 32-bit key identifier (`psa_key_id_t`) and, if applicable, an identifier of the owner of the key. In integrations where there is no concept of key owner (in particular, in library integrations), the key file identifier is exactly the key identifier. When the library is integrated into a service, the service determines the semantics of the owner identifier.
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 file identifier depends on the storage backend. The content of the file is described [below](#key-file-format-for-1.0.0).
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](#key-file-format-for-1.0.0).
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.
* Library integration: the key file name is just the key identifer. This is a 32-bit value.
* PSA service integration: the key file identifier is `(uint32_t)owner_uid << 32 | key_id` where `key_id` is the key identifier specified by the application 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.
* 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
@ -253,6 +251,7 @@ The layout of a key file is:
* key material length (4 bytes).
* key material:
* For a transparent key: output of `psa_export_key`.
* For an opaque key (unified driver interface): driver-specific opaque key blob.
* For an opaque key (key in a secure element): slot number (8 bytes), in platform endianness.
* Any trailing data is rejected on load.
@ -282,3 +281,36 @@ The layout of a transaction file is:
* 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.
Mbed Crypto TBD
---------------
Tags: TBD
Released in TBD 2020. <br>
Integrated in Mbed OS TBD.
### Changes introduced in TBD
* The type field has been split into a type and a bits field of 2 bytes each.
### 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 (2 bytes): `psa_key_type_t` value.
* bits (2 bytes): `psa_key_bits_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 (unified driver interface): driver-specific opaque key blob.
* For an opaque key (key in a secure element): slot number (8 bytes), in platform endianness.
* Any trailing data is rejected on load.

4
docs/architecture/testing/invasive-testing.md
View file

@ -100,7 +100,7 @@ Resources include:
* Memory.
* Files in storage (PSA API only — in the Mbed TLS API, black-box unit tests are sufficient).
* Key handles (PSA API only).
* Key slots (PSA API only).
* Key slots in a secure element (PSA SE HAL).
* Communication handles (PSA crypto service only).
@ -116,7 +116,7 @@ When code should clean up resources, how do we know that they have truly been cl
* Zeroization of confidential data after use.
* Freeing memory.
* Closing key handles.
* Freeing key slots.
* Freeing key slots in a secure element.
* Deleting files in storage (PSA API only).

9
docs/architecture/tls13-experimental.md
View file

@ -38,3 +38,12 @@ together with their level of testing:
- The HKDF key derivation function on which the TLS 1.3 key schedule is based,
is already present as an independent module controlled by `MBEDTLS_HKDF_C`
independently of the development of the TLS 1.3 prototype.
- The TLS 1.3-specific HKDF-based key derivation functions (see RFC 8446):
* HKDF-Expand-Label
* Derive-Secret
- Secret evolution
* The traffic {Key,IV} generation from secret
Those functions are implemented in `library/ssl_tls13_keys.c` and
tested in `test_suite_ssl` using test vectors from RFC 8448 and
https://tls13.ulfheim.net/.

64
docs/getting_started.md
View file

@ -64,7 +64,7 @@ To use the Mbed Crypto APIs, call `psa_crypto_init()` before calling any other A
### Importing a key
To use a key for cryptography operations in Mbed Crypto, you need to first
import it. Importing the key creates a handle that refers to the key for use
import it. The import operation returns the identifier of the key for use
with other function calls.
**Prerequisites to importing keys:**
@ -76,7 +76,7 @@ void import_a_key(const uint8_t *key, size_t key_len)
{
psa_status_t status;
psa_key_attributes_t attributes = PSA_KEY_ATTRIBUTES_INIT;
psa_key_handle_t handle;
psa_key_id_t key;
printf("Import an AES key...\t");
fflush(stdout);
@ -95,7 +95,7 @@ void import_a_key(const uint8_t *key, size_t key_len)
psa_set_key_bits(&attributes, 128);
/* Import the key */
status = psa_import_key(&attributes, key, key_len, &handle);
status = psa_import_key(&attributes, key, key_len, &key);
if (status != PSA_SUCCESS) {
printf("Failed to import key\n");
return;
@ -106,7 +106,7 @@ void import_a_key(const uint8_t *key, size_t key_len)
psa_reset_key_attributes(&attributes);
/* Destroy the key */
psa_destroy_key(handle);
psa_destroy_key(key);
mbedtls_psa_crypto_free();
}
@ -135,7 +135,7 @@ void sign_a_message_using_rsa(const uint8_t *key, size_t key_len)
0xa9, 0xe8, 0xcc, 0xac, 0xd0, 0xf6, 0x54, 0x5c};
uint8_t signature[PSA_SIGNATURE_MAX_SIZE] = {0};
size_t signature_length;
psa_key_handle_t handle;
psa_key_id_t key;
printf("Sign a message...\t");
fflush(stdout);
@ -154,14 +154,14 @@ void sign_a_message_using_rsa(const uint8_t *key, size_t key_len)
psa_set_key_bits(&attributes, 1024);
/* Import the key */
status = psa_import_key(&attributes, key, key_len, &handle);
status = psa_import_key(&attributes, key, key_len, &key);
if (status != PSA_SUCCESS) {
printf("Failed to import key\n");
return;
}
/* Sign message using the key */
status = psa_sign_hash(handle, PSA_ALG_RSA_PKCS1V15_SIGN_RAW,
status = psa_sign_hash(key, PSA_ALG_RSA_PKCS1V15_SIGN_RAW,
hash, sizeof(hash),
signature, sizeof(signature),
&signature_length);
@ -176,7 +176,7 @@ void sign_a_message_using_rsa(const uint8_t *key, size_t key_len)
psa_reset_key_attributes(&attributes);
/* Destroy the key */
psa_destroy_key(handle);
psa_destroy_key(key);
mbedtls_psa_crypto_free();
}
@ -188,7 +188,7 @@ Mbed Crypto supports encrypting and decrypting messages using various symmetric
**Prerequisites to working with the symmetric cipher API:**
* Initialize the library with a successful call to `psa_crypto_init()`.
* Have a handle to a symmetric key. This key's usage flags must include `PSA_KEY_USAGE_ENCRYPT` to allow encryption or `PSA_KEY_USAGE_DECRYPT` to allow decryption.
* Have a symmetric key. This key's usage flags must include `PSA_KEY_USAGE_ENCRYPT` to allow encryption or `PSA_KEY_USAGE_DECRYPT` to allow decryption.
**To encrypt a message with a symmetric cipher:**
1. Allocate an operation (`psa_cipher_operation_t`) structure to pass to the cipher functions.
@ -213,7 +213,7 @@ void encrypt_with_symmetric_ciphers(const uint8_t *key, size_t key_len)
size_t iv_len;
uint8_t output[block_size];
size_t output_len;
psa_key_handle_t handle;
psa_key_id_t key;
psa_cipher_operation_t operation = PSA_CIPHER_OPERATION_INIT;
printf("Encrypt with cipher...\t");
@ -232,7 +232,7 @@ void encrypt_with_symmetric_ciphers(const uint8_t *key, size_t key_len)
psa_set_key_algorithm(&attributes, alg);
psa_set_key_type(&attributes, PSA_KEY_TYPE_AES);
psa_set_key_bits(&attributes, 128);
status = psa_import_key(&attributes, key, key_len, &handle);
status = psa_import_key(&attributes, key, key_len, &key);
if (status != PSA_SUCCESS) {
printf("Failed to import a key\n");
return;
@ -240,7 +240,7 @@ void encrypt_with_symmetric_ciphers(const uint8_t *key, size_t key_len)
psa_reset_key_attributes(&attributes);
/* Encrypt the plaintext */
status = psa_cipher_encrypt_setup(&operation, handle, alg);
status = psa_cipher_encrypt_setup(&operation, key, alg);
if (status != PSA_SUCCESS) {
printf("Failed to begin cipher operation\n");
return;
@ -268,7 +268,7 @@ void encrypt_with_symmetric_ciphers(const uint8_t *key, size_t key_len)
psa_cipher_abort(&operation);
/* Destroy the key */
psa_destroy_key(handle);
psa_destroy_key(key);
mbedtls_psa_crypto_free();
}
@ -298,7 +298,7 @@ void decrypt_with_symmetric_ciphers(const uint8_t *key, size_t key_len)
uint8_t iv[block_size] = ENCRYPTED_WITH_IV;
uint8_t output[block_size];
size_t output_len;
psa_key_handle_t handle;
psa_key_id_t key;
printf("Decrypt with cipher...\t");
fflush(stdout);
@ -316,7 +316,7 @@ void decrypt_with_symmetric_ciphers(const uint8_t *key, size_t key_len)
psa_set_key_algorithm(&attributes, alg);
psa_set_key_type(&attributes, PSA_KEY_TYPE_AES);
psa_set_key_bits(&attributes, 128);
status = psa_import_key(&attributes, key, key_len, &handle);
status = psa_import_key(&attributes, key, key_len, &key);
if (status != PSA_SUCCESS) {
printf("Failed to import a key\n");
return;
@ -324,7 +324,7 @@ void decrypt_with_symmetric_ciphers(const uint8_t *key, size_t key_len)
psa_reset_key_attributes(&attributes);
/* Decrypt the ciphertext */
status = psa_cipher_decrypt_setup(&operation, handle, alg);
status = psa_cipher_decrypt_setup(&operation, key, alg);
if (status != PSA_SUCCESS) {
printf("Failed to begin cipher operation\n");
return;
@ -352,7 +352,7 @@ void decrypt_with_symmetric_ciphers(const uint8_t *key, size_t key_len)
psa_cipher_abort(&operation);
/* Destroy the key */
psa_destroy_key(handle);
psa_destroy_key(key);
mbedtls_psa_crypto_free();
}
@ -592,8 +592,8 @@ derived from the key, salt and info provided:
PSA_KEY_DERIVATION_OPERATION_INIT;
size_t derived_bits = 128;
size_t capacity = PSA_BITS_TO_BYTES(derived_bits);
psa_key_handle_t base_key;
psa_key_handle_t derived_key;
psa_key_id_t base_key;
psa_key_id_t derived_key;
printf("Derive a key (HKDF)...\t");
fflush(stdout);
@ -702,7 +702,7 @@ This example shows how to authenticate and encrypt a message:
size_t output_length = 0;
size_t tag_length = 16;
psa_key_attributes_t attributes = PSA_KEY_ATTRIBUTES_INIT;
psa_key_handle_t handle;
psa_key_id_t key;
printf("Authenticate encrypt...\t");
fflush(stdout);
@ -726,11 +726,11 @@ This example shows how to authenticate and encrypt a message:
psa_set_key_algorithm(&attributes, PSA_ALG_CCM);
psa_set_key_type(&attributes, PSA_KEY_TYPE_AES);
psa_set_key_bits(&attributes, 128);
status = psa_import_key(&attributes, key, sizeof(key), &handle);
status = psa_import_key(&attributes, key, sizeof(key), &key);
psa_reset_key_attributes(&attributes);
/* Authenticate and encrypt */
status = psa_aead_encrypt(handle, PSA_ALG_CCM,
status = psa_aead_encrypt(key, PSA_ALG_CCM,
nonce, sizeof(nonce),
additional_data, sizeof(additional_data),
input_data, sizeof(input_data),
@ -747,7 +747,7 @@ This example shows how to authenticate and encrypt a message:
free(output_data);
/* Destroy the key */
psa_destroy_key(handle);
psa_destroy_key(key);
mbedtls_psa_crypto_free();
```
@ -756,7 +756,7 @@ This example shows how to authenticate and decrypt a message:
```C
psa_status_t status;
static const uint8_t key[] = {
static const uint8_t key_data[] = {
0xC0, 0xC1, 0xC2, 0xC3, 0xC4, 0xC5, 0xC6, 0xC7,
0xC8, 0xC9, 0xCA, 0xCB, 0xCC, 0xCD, 0xCE, 0xCF };
static const uint8_t nonce[] = {
@ -773,7 +773,7 @@ This example shows how to authenticate and decrypt a message:
size_t output_size = 0;
size_t output_length = 0;
psa_key_attributes_t attributes = PSA_KEY_ATTRIBUTES_INIT;
psa_key_handle_t handle;
psa_key_id_t key;
printf("Authenticate decrypt...\t");
fflush(stdout);
@ -797,7 +797,7 @@ This example shows how to authenticate and decrypt a message:
psa_set_key_algorithm(&attributes, PSA_ALG_CCM);
psa_set_key_type(&attributes, PSA_KEY_TYPE_AES);
psa_set_key_bits(&attributes, 128);
status = psa_import_key(&attributes, key, sizeof(key), &handle);
status = psa_import_key(&attributes, key_data, sizeof(key_data), &key);
if (status != PSA_SUCCESS) {
printf("Failed to import a key\n");
return;
@ -805,7 +805,7 @@ This example shows how to authenticate and decrypt a message:
psa_reset_key_attributes(&attributes);
/* Authenticate and decrypt */
status = psa_aead_decrypt(handle, PSA_ALG_CCM,
status = psa_aead_decrypt(key, PSA_ALG_CCM,
nonce, sizeof(nonce),
additional_data, sizeof(additional_data),
input_data, sizeof(input_data),
@ -822,7 +822,7 @@ This example shows how to authenticate and decrypt a message:
free(output_data);
/* Destroy the key */
psa_destroy_key(handle);
psa_destroy_key(key);
mbedtls_psa_crypto_free();
```
@ -848,7 +848,7 @@ Mbed Crypto provides a simple way to generate a key or key pair.
size_t exported_length = 0;
static uint8_t exported[PSA_KEY_EXPORT_ECC_PUBLIC_KEY_MAX_SIZE(key_bits)];
psa_key_attributes_t attributes = PSA_KEY_ATTRIBUTES_INIT;
psa_key_handle_t handle;
psa_key_id_t key;
printf("Generate a key pair...\t");
fflush(stdout);
@ -867,14 +867,14 @@ Mbed Crypto provides a simple way to generate a key or key pair.
psa_set_key_type(&attributes,
PSA_KEY_TYPE_ECC_KEY_PAIR(PSA_ECC_FAMILY_SECP_R1));
psa_set_key_bits(&attributes, key_bits);
status = psa_generate_key(&attributes, &handle);
status = psa_generate_key(&attributes, &key);
if (status != PSA_SUCCESS) {
printf("Failed to generate key\n");
return;
}
psa_reset_key_attributes(&attributes);
status = psa_export_public_key(handle, exported, sizeof(exported),
status = psa_export_public_key(key, exported, sizeof(exported),
&exported_length);
if (status != PSA_SUCCESS) {
printf("Failed to export public key %ld\n", status);
@ -884,7 +884,7 @@ Mbed Crypto provides a simple way to generate a key or key pair.
printf("Exported a public key\n");
/* Destroy the key */
psa_destroy_key(handle);
psa_destroy_key(key);
mbedtls_psa_crypto_free();
```

1
docs/proposed/Makefile
View file

@ -3,6 +3,7 @@ PANDOC = pandoc
default: all
all_markdown = \
psa-conditional-inclusion-c.md \
psa-driver-developer-guide.md \
psa-driver-integration-guide.md \
psa-driver-interface.md \

238
docs/proposed/psa-conditional-inclusion-c.md Normal file
View file

@ -0,0 +1,238 @@
Conditional inclusion of cryptographic mechanism through the PSA API in Mbed TLS
================================================================================
This document is a proposed interface for deciding at build time which cryptographic mechanisms to include in the PSA Cryptography interface.
This is currently a proposal for Mbed TLS. It is not currently on track for standardization in PSA.
Time-stamp: "2020/11/26 09:30:50 GMT"
## Introduction
### Purpose of this specification
The [PSA Cryptography API specification](https://armmbed.github.io/mbed-crypto/psa/#application-programming-interface) specifies the interface between a PSA Cryptography implementation and an application. The interface defines a number of categories of cryptographic algorithms (hashes, MAC, signatures, etc.). In each category, a typical implementation offers many algorithms (e.g. for signatures: RSA-PKCS#1v1.5, RSA-PSS, ECDSA). When building the implementation for a specific use case, it is often desirable to include only a subset of the available cryptographic mechanisms, primarily in order to reduce the code footprint of the compiled system.
The present document proposes a way for an application using the PSA cryptography interface to declare which mechanisms it requires.
### Conditional inclusion of legacy cryptography modules
Mbed TLS offers a way to select which cryptographic mechanisms are included in a build through its configuration file (`config.h`). This mechanism is based on two main sets of symbols: `MBEDTLS_xxx_C` controls the availability of the mechanism to the application, and `MBEDTLS_xxx_ALT` controls the availability of an alternative implementation, so the software implementation is only included if `MBEDTLS_xxx_C` is defined but not `MBEDTLS_xxx_ALT`.
### PSA evolution
In the PSA cryptography interface, the **core** (built-in implementations of cryptographic mechanisms) can be augmented with drivers. **Transparent drivers** replace the built-in implementation of a cryptographic mechanism (or, with **fallback**, the built-in implementation is tried if the driver only has partial support for the mechanism). **Opaque drivers** implement cryptographic mechanisms on keys which are stored in a separate domain such as a secure element, for which the core only does key management and dispatch using wrapped key blobs or key identifiers.
The current model is difficult to adapt to the PSA interface for several reasons. The `MBEDTLS_xxx_ALT` symbols are somewhat inconsistent, and in particular do not work well for asymmetric cryptography. For example, many parts of the ECC code have no `MBEDTLS_xxx_ALT` symbol, so a platform with ECC acceleration that can perform all ECDSA and ECDH operations in the accelerator would still embark the `bignum` module and large parts of the `ecp_curves`, `ecp` and `ecdsa` modules. Also the availability of a transparent driver for a mechanism does not translate directly to `MBEDTLS_xxx` symbols.
### Requirements
[Req.interface] The application can declare which cryptographic mechanisms it needs.
[Req.inclusion] If the application does not require a mechanism, a suitably configured Mbed TLS build must not include it. The granularity of mechanisms must work for typical use cases and has [acceptable limitations](#acceptable-limitations).
[Req.drivers] If a PSA driver is available in the build, a suitably configured Mbed TLS build must not include the corresponding software code (unless a software fallback is needed).
[Req.c] The configuration mechanism consists of C preprocessor definitions, and the build does not require tools other than a C compiler. This is necessary to allow building an application and Mbed TLS in development environments that do not allow third-party tools.
[Req.adaptability] The implementation of the mechanism must be adaptable with future evolution of the PSA cryptography specifications and Mbed TLS. Therefore the interface must remain sufficiently simple and abstract.
### Acceptable limitations
[Limitation.matrix] If a mechanism is defined by a combination of algorithms and key types, for example a block cipher mode (CBC, CTR, CFB, …) and a block permutation (AES, CAMELLIA, ARIA, …), there is no requirement to include only specific combinations.
[Limitation.direction] For mechanisms that have multiple directions (for example encrypt/decrypt, sign/verify), there is no requirement to include only one direction.
[Limitation.size] There is no requirement to include only support for certain key sizes.
[Limitation.multipart] Where there are multiple ways to perform an operation, for example single-part and multi-part, there is no mechanism to select only one or a subset of the possible ways.
## Interface
### PSA Crypto configuration file
The PSA Crypto configuration file `psa/crypto_config.h` defines a series of symbols of the form `PSA_WANT_xxx` where `xxx` describes the feature that the symbol enables. The symbols are documented in the section [“PSA Crypto configuration symbols”](#psa-crypto-configuration-symbols) below.
The symbol `MBEDTLS_PSA_CRYPTO_CONFIG` in `mbedtls/config.h` determines whether `psa/crypto_config.h` is used.
* If `MBEDTLS_PSA_CRYPTO_CONFIG` is unset, which is the default at least in Mbed TLS 2.x versions, things are as they are today: the PSA subsystem includes generic code unconditionally, and includes support for specific mechanisms conditionally based on the existing `MBEDTLS_xxx_` symbols.
* If `MBEDTLS_PSA_CRYPTO_CONFIG` is set, the necessary software implementations of cryptographic algorithms are included based on both the content of the PSA Crypto configuration file and the Mbed TLS configuration file. For example, the code in `aes.c` is enabled if either `mbedtls/config.h` contains `MBEDTLS_AES_C` or `psa/crypto_config.h` contains `PSA_WANT_KEY_TYPE_AES`.
### PSA Crypto configuration symbols
#### Configuration symbol syntax
A PSA Crypto configuration symbol is a C preprocessor symbol whose name starts with `PSA_WANT_`.
* If the symbol is not defined, the corresponding feature is not included.
* If the symbol is defined to a preprocessor expression with the value `1`, the corresponding feature is included.
* If the symbol is defined with a different value, the behavior is currently undefined and reserved for future use.
#### Configuration symbol usage
The presence of a symbol `PSA_WANT_xxx` in the Mbed TLS configuration determines whether a feature is available through the PSA API. These symbols should be used in any place that requires conditional compilation based on the availability of a cryptographic mechanism through the PSA API, including:
* In Mbed TLS test code.
* In Mbed TLS library code using `MBEDTLS_USE_PSA_CRYPTO`, for example in TLS to determine which cipher suites to enable.
* In application code that provides additional features based on cryptographic capabilities, for example additional key parsing and formatting functions, or cipher suite availability for network protocols.
#### Configuration symbol semantics
If a feature is not requested for inclusion in the PSA Crypto configuration file, it may still be included in the build, either because the feature has been requested in some other way, or because the library does not support the exclusion of this feature. Mbed TLS should make a best effort to support the exclusion of all features, but in some cases this may be judged too much effort for too little benefit.
#### Configuration symbols for key types
For each constant or constructor macro of the form `PSA_KEY_TYPE_xxx`, the symbol **`PSA_WANT_KEY_TYPE_xxx`** indicates that support for this key type is desired.
For asymmetric cryptography, `PSA_WANT_KEY_TYPE_xxx_KEY_PAIR` determines whether private-key operations are desired, and `PSA_WANT_KEY_TYPE_xxx_PUBLIC_KEY` determines whether public-key operations are desired. `PSA_WANT_KEY_TYPE_xxx_KEY_PAIR` implicitly enables `PSA_WANT_KEY_TYPE_xxx_PUBLIC_KEY`: there is no way to only include private-key operations (which typically saves little code).
#### Configuration symbols for curves
For elliptic curve key types, only the specified curves are included. To include a curve, include a symbol of the form **`PSA_WANT_ECC_family_size`**. For example: `PSA_WANT_ECC_SECP_R1_256` for secp256r1, `PSA_WANT_ECC_MONTGOMERY_CURVE25519`. It is an error to require an ECC key type but no curve, and Mbed TLS will reject this at compile time.
#### Configuration symbols for algorithms
For each constant or constructor macro of the form `PSA_ALG_xxx`, the symbol **`PSA_WANT_ALG_xxx`** indicates that support for this algorithm is desired.
For parametrized algorithms, the `PSA_WANT_ALG_xxx` symbol indicates whether the base mechanism is supported. Parameters must themselves be included through their own `PSA_WANT_ALG_xxx` symbols. It is an error to include a base mechanism without at least one possible parameter, and Mbed TLS will reject this at compile time. For example, `PSA_WANT_ALG_ECDSA` requires the inclusion of randomized ECDSA for all hash algorithms whose corresponding symbol `PSA_WANT_ALG_xxx` is enabled.
## Implementation
### Additional non-public symbols
#### Accounting for transparent drivers
In addition to the [configuration symbols](#psa-crypto-configuration-symbols), we need two parallel or mostly parallel sets of symbols:
* **`MBEDTLS_PSA_ACCEL_xxx`** indicates whether a fully-featured, fallback-free transparent driver is available.
* **`MBEDTLS_PSA_BUILTIN_xxx`** indicates whether the software implementation is needed.
`MBEDTLS_PSA_ACCEL_xxx` is one of the outputs of the transpilation of a driver description, alongside the glue code for calling the drivers.
`MBEDTLS_PSA_BUILTIN_xxx` is enabled when `PSA_WANT_xxx` is enabled and `MBEDTLS_PSA_ACCEL_xxx` is disabled.
These symbols are not part of the public interface of Mbed TLS towards applications or to drivers, regardless of whether the symbols are actually visible.
### Architecture of symbol definitions
#### New-style definition of configuration symbols
When `MBEDTLS_PSA_CRYPTO_CONFIG` is set, the header file `mbedtls/config.h` needs to define all the `MBEDTLS_xxx_C` configuration symbols, including the ones deduced from the PSA Crypto configuration. It does this by including the new header file **`mbedtls/config_psa.h`**, which defines the `MBEDTLS_PSA_BUILTIN_xxx` symbols and deduces the corresponding `MBEDTLS_xxx_C` (and other) symbols.
`mbedtls/config_psa.h` includes `psa/crypto_config.h`, the user-editable file that defines application requirements.
#### Old-style definition of configuration symbols
When `MBEDTLS_PSA_CRYPTO_CONFIG` is not set, the configuration of Mbed TLS works as before, and the inclusion of non-PSA code only depends on `MBEDTLS_xxx` symbols defined (or not) in `mbedtls/config.h`. Furthermore, the new header file **`mbedtls/config_psa.h`** deduces PSA configuration symbols (`PSA_WANT_xxx`, `MBEDTLS_PSA_BUILTIN_xxx`) from classic configuration symbols (`MBEDTLS_xxx`).
The `PSA_WANT_xxx` definitions in `mbedtls/config_psa.h` are needed not only to build the PSA parts of the library, but also to build code that uses these parts. This includes structure definitions in `psa/crypto_struct.h`, size calculations in `psa/crypto_sizes.h`, and application code that's specific to a given cryptographic mechanism. In Mbed TLS itself, code under `MBEDTLS_USE_PSA_CRYPTO` and conditional compilation guards in tests and sample programs need `PSA_WANT_xxx`.
Since some existing applications use a handwritten `mbedtls/config.h` or an edited copy of `mbedtls/config.h` from an earlier version of Mbed TLS, `mbedtls/config_psa.h` must be included via an already existing header that is not `mbedtls/config.h`, so it is included via `psa/crypto.h` (for example from `psa/crypto_platform.h`).
#### Summary of definitions of configuration symbols
Whether `MBEDTLS_PSA_CRYPTO_CONFIG` is set or not, `mbedtls/config_psa.h` includes `mbedtls/crypto_drivers.h`, a header file generated by the transpilation of the driver descriptions. It defines `MBEDTLS_PSA_ACCEL_xxx` symbols according to the availability of transparent drivers without fallback.
The following table summarizes where symbols are defined depending on the configuration mode.
* (U) indicates a symbol that is defined by the user (application).
* (D) indicates a symbol that is deduced from other symbols by code that ships with Mbed TLS.
* (G) indicates a symbol that is generated from driver descriptions.
| Symbols | With `MBEDTLS_PSA_CRYPTO_CONFIG` | Without `MBEDTLS_PSA_CRYPTO_CONFIG` |
| ------------------------- | -------------------------------- | ----------------------------------- |
| `MBEDTLS_xxx_C` | `mbedtls/config.h` (U) or | `mbedtls/config.h` (U) |
| | `mbedtls/config_psa.h` (D) | |
| `PSA_WANT_xxx` | `psa/crypto_config.h` (U) | `mbedtls/config_psa.h` (D) |
| `MBEDTLS_PSA_BUILTIN_xxx` | `mbedtls/config_psa.h` (D) | `mbedtls/config_psa.h` (D) |
| `MBEDTLS_PSA_ACCEL_xxx` | `mbedtls/crypto_drivers.h` (G) | N/A |
#### Visibility of internal symbols
Ideally, the `MBEDTLS_PSA_ACCEL_xxx` and `MBEDTLS_PSA_BUILTIN_xxx` symbols should not be visible to application code or driver code, since they are not part of the public interface of the library. However these symbols are needed to deduce whether to include library modules (for example `MBEDTLS_AES_C` has to be enabled if `MBEDTLS_PSA_BUILTIN_KEY_TYPE_AES` is enabled), which makes it difficult to keep them private.
#### Compile-time checks
The header file **`library/psa_check_config.h`** applies sanity checks to the configuration, throwing `#error` if something is wrong.
A mechanism similar to `mbedtls/check_config.h` detects errors such as enabling ECDSA but no curve.
Since configuration symbols must be undefined or 1, any other value should trigger an `#error`.
#### Automatic generation of preprocessor symbol manipulations
A lot of the preprocessor symbol manipulation is systematic calculations that analyze the configuration. `mbedtls/config_psa.h` and `library/psa_check_config.h` should be generated automatically, in the same manner as `version_features.c`.
### Structure of PSA Crypto library code
#### Conditional inclusion of library entry points
An entry point can be eliminated entirely if no algorithm requires it.
#### Conditional inclusion of mechanism-specific code
Code that is specific to certain key types or to certain algorithms must be guarded by the applicable symbols: `PSA_WANT_xxx` for code that is independent of the application, and `MBEDTLS_PSA_BUILTIN_xxx` for code that calls an Mbed TLS software implementation.
## PSA standardization
### JSON configuration mechanism
At the time of writing, the preferred configuration mechanism for a PSA service is in JSON syntax. The translation from JSON to build instructions is not specified by PSA.
For PSA Crypto, the preferred configuration mechanism would be similar to capability specifications of transparent drivers. The same JSON properties that are used to mean “this driver can perform that mechanism” in a driver description would be used to mean “the application wants to perform that mechanism” in the application configuration.
### From JSON to C
The JSON capability language allows a more fine-grained selection than the C mechanism proposed here. For example, it allows requesting only single-part mechanisms, only certain key sizes, or only certain combinations of algorithms and key types.
The JSON capability language can be translated approximately to the boolean symbol mechanism proposed here. The approximation considers a feature to be enabled if any part of it is enabled. For example, if there is a capability for AES-CTR and one for CAMELLIA-GCM, the translation to boolean symbols will also include AES-GCM and CAMELLIA-CTR. If there is a capability for AES-128, the translation will also include AES-192 and AES-256.
The boolean symbol mechanism proposed here can be translated to a list of JSON capabilities: for each included algorithm, include a capability with that algorithm, the key types that apply to that algorithm, no size restriction, and all the entry points that apply to that algorithm.
## Open questions
### Open questions about the interface
#### Naming of symbols
The names of [elliptic curve symbols](#configuration-symbols-for-curves) are a bit weird: `SECP_R1_256` instead of `SECP256R1`. Should we make them more classical, but less systematic?
#### Impossible combinations
What does it mean to have `PSA_WANT_ALG_ECDSA` enabled but with only Curve25519? Is it a mandatory error?
#### Diffie-Hellman
Way to request only specific groups? Not a priority: constrained devices don't do FFDH. Specify it as may change in future versions.
#### Coexistence with the current Mbed TLS configuration
The two mechanisms have very different designs. Is there serious potential for confusion? Do we understand how the combinations work?
### Open questions about the design
#### Algorithms without a key type or vice versa
Is it realistic to mandate a compile-time error if a key type is required, but no matching algorithm, or vice versa? Is it always the right thing, for example if there is an opaque driver that manipulates this key type?
#### Opaque-only mechanisms
If a mechanism should only be supported in an opaque driver, what does the core need to know about it? Do we have all the information we need?
This is especially relevant to suppress a mechanism completely if there is no matching algorithm. For example, if there is no transparent implementation of RSA or ECDSA, `psa_sign_hash` and `psa_verify_hash` may still be needed if there is an opaque signature driver.
### Open questions about the implementation
#### Testability
Is this proposal decently testable? There are a lot of combinations. What combinations should we test?
<!--
Local Variables:
time-stamp-line-limit: 40
time-stamp-start: "Time-stamp: *\""
time-stamp-end: "\""
time-stamp-format: "%04Y/%02m/%02d %02H:%02M:%02S %Z"
time-stamp-time-zone: "GMT"
End:
-->

10
docs/proposed/psa-driver-developer-guide.md
View file

@ -5,7 +5,7 @@ PSA Cryptoprocessor driver developer's guide
This document describes how to write drivers of cryptoprocessors such as accelerators and secure elements for the PSA cryptography subsystem of Mbed TLS.
This document focuses on behavior that is specific to Mbed TLS. For a reference of the interface between Mbed TLS and drivers, refer to the [PSA Cryptoprocessor Driver Interface specification](architecture/psa-driver-interface.md).
This document focuses on behavior that is specific to Mbed TLS. For a reference of the interface between Mbed TLS and drivers, refer to the [PSA Cryptoprocessor Driver Interface specification](psa-driver-interface.html).
The interface is not fully implemented in Mbed TLS yet and is disabled by default. You can enable the experimental work in progress by setting `MBEDTLS_PSA_CRYPTO_DRIVERS` in the compile-time configuration. Please note that the interface may still change: until further notice, we do not guarantee backward compatibility with existing driver code when `MBEDTLS_PSA_CRYPTO_DRIVERS` is enabled.
@ -24,7 +24,7 @@ There are two types of drivers:
To write a driver, you need to implement some functions with C linkage, and to declare these functions in a **driver description file**. The driver description file declares which functions the driver implements and what cryptographic mechanisms they support. Depending on the driver type, you may also need to define some C types and macros in a header file.
The concrete syntax for a driver description file is JSON. The structure of this JSON file is specified in the section [“Driver description syntax”](architecture/psa-driver-interface.md#driver-description-syntax) of the PSA cryptography driver interface specification.
The concrete syntax for a driver description file is JSON. The structure of this JSON file is specified in the section [“Driver description syntax”](psa-driver-interface.html#driver-description-syntax) of the PSA cryptography driver interface specification.
A driver therefore consists of:
@ -34,11 +34,7 @@ A driver therefore consists of:
## Driver C interfaces
Mbed TLS calls [driver functions as specified in the PSA Cryptography Driver Interface specification](architecture/psa-driver-interface.md#) except as otherwise indicated in this section.
### Key handles
Mbed TLS currently implements the interface for opening and closing persistent keys from version 1.0 beta 3 of the PSA Crypto specification. As a consequence, functions that operate on an existing key take an argument of type `psa_key_handle_t` instead of `psa_key_id_t`. Functions that create a new key take an argument of type `psa_key_handle_t *` instead of `psa_key_id_t *`.
Mbed TLS calls driver entry points [as specified in the PSA Cryptography Driver Interface specification](psa-driver-interface.html#driver-entry-points) except as otherwise indicated in this section.
## Building and testing your driver

264
docs/proposed/psa-driver-interface.md
View file

@ -5,15 +5,15 @@ This document describes an interface for cryptoprocessor drivers in the PSA cryp
This specification is work in progress and should be considered to be in a beta stage. There is ongoing work to implement this interface in Mbed TLS, which is the reference implementation of the PSA Cryptography API. At this stage, Arm does not expect major changes, but minor changes are expected based on experience from the first implementation and on external feedback.
Time-stamp: "2020/08/05 20:37:24 GMT"
Time-stamp: "2020/11/24 11:03:32 GMT"
## Introduction
### Purpose of the driver interface
The PSA Cryptography API defines an interface that allows applications to perform cryptographic operations in a uniform way regardless of how the operations are performed. Under the hood, different keys may be processed in different hardware or in different logical partitions, and different algorithms may involve different hardware or software components.
The PSA Cryptography API defines an interface that allows applications to perform cryptographic operations in a uniform way regardless of how the operations are performed. Under the hood, different keys may be stored and used in different hardware or in different logical partitions, and different algorithms may involve different hardware or software components.
The driver interface allows implementations of the PSA Crypytography API to be built compositionally. An implementation of the PSA Cryptography API is composed of a **core** and zero or more **drivers**. The core handles key management, enforces key usage policies, and dispatches cryptographic operations either to the applicable driver or to built-in code.
The driver interface allows implementations of the PSA Cryptography API to be built compositionally. An implementation of the PSA Cryptography API is composed of a **core** and zero or more **drivers**. The core handles key management, enforces key usage policies, and dispatches cryptographic operations either to the applicable driver or to built-in code.
Functions in the PSA Cryptography API invoke functions in the core. Code from the core calls drivers as described in the present document.
@ -21,12 +21,12 @@ Functions in the PSA Cryptography API invoke functions in the core. Code from th
The PSA Cryptography driver interface supports two types of cryptoprocessors, and accordingly two types of drivers.
* **Transparent** drivers implement cryptographic operations on keys that are provided in cleartext at the beginning of each operation. They are typically used for hardware **accelerators**. When a transparent driver is available for a particular combination of parameters (cryptographic algorithm, key type and size, etc.), it is used instead of the default software implementation. Transparent drivers can also be pure software implementations that are distributed as plug-ins to a PSA Crypto implementation (for example, an alternative implementation with different performance characteristics, or a certified implementation).
* **Transparent** drivers implement cryptographic operations on keys that are provided in cleartext at the beginning of each operation. They are typically used for hardware **accelerators**. When a transparent driver is available for a particular combination of parameters (cryptographic algorithm, key type and size, etc.), it is used instead of the default software implementation. Transparent drivers can also be pure software implementations that are distributed as plug-ins to a PSA Cryptography implementation (for example, an alternative implementation with different performance characteristics, or a certified implementation).
* **Opaque** drivers implement cryptographic operations on keys that can only be used inside a protected environment such as a **secure element**, a hardware security module, a smartcard, a secure enclave, etc. An opaque driver is invoked for the specific [key location](#lifetimes-and-locations) that the driver is registered for: the dispatch is based on the key's lifetime.
### Requirements
The present specification was designed to fulfil the following high-level requirements.
The present specification was designed to fulfill the following high-level requirements.
[Req.plugins] It is possible to combine multiple drivers from different providers into the same implementation, without any prior arrangement other than choosing certain names and values from disjoint namespaces.
@ -34,7 +34,7 @@ The present specification was designed to fulfil the following high-level requir
[Req.types] Support drivers for the following types of hardware: accelerators that operate on keys in cleartext; cryptoprocessors that can wrap keys with a built-in keys but not store user keys; and cryptoprocessors that store key material.
[Req.portable] The interface between drivers and the core does not involve any platform-specific consideration. Driver calls are simple C functions. Interactions between driver code and hardware happen inside the driver (and in fact a driver need not involve any hardware at all).
[Req.portable] The interface between drivers and the core does not involve any platform-specific consideration. Driver calls are simple C function calls. Interactions with platform-specific hardware happen only inside the driver (and in fact a driver need not involve any hardware at all).
[Req.location] Applications can tell which location values correspond to which secure element drivers.
@ -46,54 +46,94 @@ The present specification was designed to fulfil the following high-level requir
### Deliverables for a driver
To write a driver, you need to implement some functions with C linkage, and to declare these functions in a **driver description file**. The driver description file declares which functions the driver implements and what cryptographic mechanisms they support. Depending on the driver type, you may also need to define some C types and macros in a header file.
To write a driver, you need to implement some functions with C linkage, and to declare these functions in a **driver description file**. The driver description file declares which functions the driver implements and what cryptographic mechanisms they support. If the driver description references custom types, macros or constants, you also need to provide C header files defining those elements.
The concrete syntax for a driver description file is JSON. The structure of this JSON file is specified in the section [“Driver description syntax”](#driver-description-syntax).
A driver therefore consists of:
* A driver description file (in JSON format).
* C header files defining the types required by the driver description. The names of these header files is declared in the driver description file.
* An object file compiled for the target platform defining the functions required by the driver description. Implementations may allow drivers to be provided as source files and compiled with the core instead of being pre-compiled.
* C header files defining the types required by the driver description. The names of these header files are declared in the driver description file.
* An object file compiled for the target platform defining the entry point functions specified by the driver description. Implementations may allow drivers to be provided as source files and compiled with the core instead of being pre-compiled.
How to provide the driver description file, the C header files and the object code is implementation-dependent.
Implementations should support multiple drivers.
### Driver description syntax
The concrete syntax for a driver description file is JSON.
#### Driver description list
PSA Cryptography core implementations should support multiple drivers. The driver description files are passed to the implementation as an ordered list in an unspecified manner. This may be, for example, a list of file names passed on a command line, or a JSON list whose elements are individual driver descriptions.
#### Driver description top-level element
A driver description is a JSON object containing the following properties:
* `"prefix"` (mandatory, string). This must be a valid prefix for a C identifier. All the types and functions provided by the driver have a name that starts with this prefix unless overridden with a `"name"` element in the applicable capability as described below.
* `"type"` (mandatory, string). One of `"transparent"` or `"opaque"`.
* `"headers"` (optional, array of strings). A list of header files. These header files must define the types provided by the driver and may declare the functions provided by the driver. They may include other PSA headers and standard headers of the platform. Whether they may include other headers is implementation-specific. If omitted, the list of headers is empty.
* `"headers"` (optional, array of strings). A list of header files. These header files must define the types, macros and constants referenced by the driver description. They may declare the entry point functions, but this is not required. They may include other PSA headers and standard headers of the platform. Whether they may include other headers is implementation-specific. If omitted, the list of headers is empty. The header files must be present at the specified location relative to a directory on the compiler's include path when compiling glue code between the core and the drivers.
* `"capabilities"` (mandatory, array of [capabilities](#driver-description-capability)).
A list of **capabilities**. Each capability describes a family of functions that the driver implements for a certain class of cryptographic mechanisms.
* `"key_context"` (not permitted for transparent drivers, mandatory for opaque drivers): information about the [representation of keys](#key-format-for-opaque-drivers).
* `"persistent_state_size"` (not permitted for transparent drivers, optional for opaque drivers, integer or string). The size in bytes of the [persistent state of the driver](#opaque-driver-persistent-state). This may be either a non-negative integer or a C constant expression of type `size_t`.
* `"location"` (not permitted for transparent drivers, optional for opaque drivers, integer or string). The [location value](#lifetimes-and-locations) for which this driver is invoked. In other words, this determines the lifetimes for which the driver is invoked. This may be either a non-negative integer or a C constant expression of type `psa_key_location_t`.
#### Driver description capability
### Driver description capability
#### Capability syntax
A capability declares a family of functions that the driver implements for a certain class of cryptographic mechanisms. The capability specifies which key types and algorithms are covered and the names of the types and functions that implement it.
A capability is a JSON object containing the following properties:
* `"functions"` (optional, list of strings). Each element is the name of a [driver function](#driver-functions) or driver function family. If specified, the core will invoke this capability of the driver only when performing one of the specified operations. If omitted, the `"algorithms"` property is mandatory and the core will invoke this capability of the driver for all operations that are applicable to the specified algorithms. The driver must implement all the specified or implied functions, as well as the types if applicable.
* `"entry_points"` (mandatory, list of strings). Each element is the name of a [driver entry point](#driver-entry-points) or driver entry point family. An entry point is a function defined by the driver. If specified, the core will invoke this capability of the driver only when performing one of the specified operations. The driver must implement all the specified entry points, as well as the types if applicable.
* `"algorithms"` (optional, list of strings). Each element is an [algorithm specification](#algorithm-specifications). If specified, the core will invoke this capability of the driver only when performing one of the specified algorithms. If omitted, the core will invoke this capability for all applicable algorithms.
* `"key_types"` (optional, list of strings). Each element is a [key type specification](#key-type-specifications). If specified, the core will invoke this capability of the driver only for operations involving a key with one of the specified key types. If omitted, the core will invoke this capability of the driver for all applicable key types.
* `"key_sizes"` (optional, list of integers). If specified, the core will invoke this capability of the driver only for operations involving a key with one of the specified key sizes. If omitted, the core will invoke this capability of the driver for all applicable key sizes. Key sizes are expressed in bits.
* `"names"` (optional, object). A mapping from entry point names described by the `"functions"` property, to the name of the C function in the driver that implements the corresponding function. If a function is not listed here, name of the driver function that implements it is the driver's prefix followed by an underscore (`_`) followed by the function name. If this property is omitted, it is equivalent to an empty object (so each entry point *suffix* is implemented by a function called *prefix*`_`*suffix*).
* `"fallback"` (optional for transparent drivers, not permitted for opaque drivers, boolean). If present and true, the driver may return `PSA_ERROR_NOT_SUPPORTED`, in which case the core should call another driver or use built-in code to perform this operation. If absent or false, the core should not include built-in code to perform this particular cryptographic mechanism. See the section “[Fallback](#fallback)” for more information.
* `"names"` (optional, object). A mapping from entry point names described by the `"entry_points"` property, to the name of the C function in the driver that implements the corresponding function. If a function is not listed here, name of the driver function that implements it is the driver's prefix followed by an underscore (`_`) followed by the function name. If this property is omitted, it is equivalent to an empty object (so each entry point *suffix* is implemented by a function called *prefix*`_`*suffix*).
* `"fallback"` (optional for transparent drivers, not permitted for opaque drivers, boolean). If present and true, the driver may return `PSA_ERROR_NOT_SUPPORTED`, in which case the core should call another driver or use built-in code to perform this operation. If absent or false, the driver is expected to fully support the mechanisms described by this capability. See the section “[Fallback](#fallback)” for more information.
Example: the following capability declares that the driver can perform deterministic ECDSA signatures using SHA-256 or SHA-384 with a SECP256R1 or SECP384R1 private key (with either hash being possible in combination with either curve). If the prefix of this driver is `"acme"`, the function that performs the signature is called `acme_sign_hash`.
#### Capability semantics
When the PSA Cryptography implementation performs a cryptographic mechanism, it invokes available driver entry points as described in the section [“Driver entry points”](#driver-entry-points).
A driver is considered available for a cryptographic mechanism that invokes a given entry point if all of the following conditions are met:
* The driver specification includes a capability whose `"entry_points"` list either includes the entry point or includes an entry point family that includes the entry point.
* If the mechanism involves an algorithm:
* either the capability does not have an `"algorithms"` property;
* or the value of the capability's `"algorithms"` property includes an [algorithm specification](#algorithm-specifications) that matches this algorithm.
* If the mechanism involves a key:
* either the key is transparent (its location is `PSA_KEY_LOCATION_LOCAL_STORAGE`) and the driver is transparent;
* or the key is opaque (its location is not `PSA_KEY_LOCATION_LOCAL_STORAGE`) and the driver is an opaque driver whose location is the key's location.
* If the mechanism involves a key:
* either the capability does not have a `"key_types"` property;
* or the value of the capability's `"key_types"` property includes a [key type specification](#key-type-specifications) that matches this algorithm.
* If the mechanism involves a key:
* either the capability does not have a `"key_sizes"` property;
* or the value of the capability's `"key_sizes"` property includes the key's size.
If a driver includes multiple applicable capabilities for a given combination of entry point, algorithm, key type and key size, and all the capabilities map the entry point to the same function name, the driver is considered available for this cryptographic mechanism. If a driver includes multiple applicable capabilities for a given combination of entry point, algorithm, key type and key size, and at least two of these capabilities map the entry point to the different function names, the driver specification is invalid.
If multiple transparent drivers have applicable capabilities for a given combination of entry point, algorithm, key type and key size, the first matching driver in the [specification list](#driver-description-list) is invoked. If the capability has [fallback](#fallback) enabled and the first driver returns `PSA_ERROR_NOT_SUPPORTED`, the next matching driver is invoked, and so on.
If multiple opaque drivers have the same location, the list of driver specifications is invalid.
#### Capability examples
Example 1: the following capability declares that the driver can perform deterministic ECDSA signatures (but not signature verification) using any hash algorithm and any curve that the core supports. If the prefix of this driver is `"acme"`, the function that performs the signature is called `acme_sign_hash`.
```
{
"functions": ["sign_hash"],
"entry_points": ["sign_hash"],
"algorithms": ["PSA_ALG_DETERMINISTIC_ECDSA(PSA_ALG_ANY_HASH)"],
}
```
Example 2: the following capability declares that the driver can perform deterministic ECDSA signatures using SHA-256 or SHA-384 with a SECP256R1 or SECP384R1 private key (with either hash being possible in combination with either curve). If the prefix of this driver is `"acme"`, the function that performs the signature is called `acme_sign_hash`.
```
{
"entry_points": ["sign_hash"],
"algorithms": ["PSA_ALG_DETERMINISTIC_ECDSA(PSA_ALG_SHA_256)",
"PSA_ALG_DETERMINISTIC_ECDSA(PSA_ALG_SHA_384)"],
"key_types": ["PSA_KEY_TYPE_ECC_KEY_PAIR(PSA_ECC_CURVE_SECP_R1)"],
@ -105,7 +145,7 @@ Example: the following capability declares that the driver can perform determini
#### Algorithm specifications
An algorithm specification is a string consisting of a `PSA_ALG_xxx` macro that specifies a cryptographic algorithm defined by the PSA Cryptography API. If the macro takes arguments, the string must have the syntax of a C macro call and each argument must be an algorithm specification or a decimal or hexadecimal literal with no suffix, depending on the expected type of argument.
An algorithm specification is a string consisting of a `PSA_ALG_xxx` macro that specifies a cryptographic algorithm or an algorithm wildcard policy defined by the PSA Cryptography API. If the macro takes arguments, the string must have the syntax of a C macro call and each argument must be an algorithm specification or a decimal or hexadecimal literal with no suffix, depending on the expected type of argument.
Spaces are optional after commas. Whether other whitespace is permitted is implementation-specific.
@ -114,6 +154,7 @@ Valid examples:
PSA_ALG_SHA_256
PSA_ALG_HMAC(PSA_ALG_SHA_256)
PSA_ALG_KEY_AGREEMENT(PSA_ALG_ECDH, PSA_ALG_HKDF(PSA_ALG_SHA_256))
PSA_ALG_RSA_PSS(PSA_ALG_ANY_HASH)
```
#### Key type specifications
@ -135,9 +176,9 @@ PSA_KEY_TYPE_ECC_KEY_PAIR(_)
Drivers define functions, each of which implements an aspect of a capability of a driver, such as a cryptographic operation, a part of a cryptographic operation, or a key management action. These functions are called the **entry points** of the driver. Most driver entry points correspond to a particular function in the PSA Cryptography API. For example, if a call to `psa_sign_hash()` is dispatched to a driver, it invokes the driver's `sign_hash` function.
All driver entry points return a status of type `psa_status_t` which should use the status codes documented for PSA services in general and for PSA Crypto in particular: `PSA_SUCCESS` indicates that the function succeeded, and `PSA_ERROR_xxx` values indicate that an error occurred.
All driver entry points return a status of type `psa_status_t` which should use the status codes documented for PSA services in general and for PSA Cryptography in particular: `PSA_SUCCESS` indicates that the function succeeded, and `PSA_ERROR_xxx` values indicate that an error occurred.
The signature of a driver entry point generally looks like the signature of the PSA Crypto API that it implements, with some modifications. This section gives an overview of modifications that apply to whole classes of entry points. Refer to the reference section for each entry point or entry point family for details.
The signature of a driver entry point generally looks like the signature of the PSA Cryptography API that it implements, with some modifications. This section gives an overview of modifications that apply to whole classes of entry points. Refer to the reference section for each entry point or entry point family for details.
* For entry points that operate on an existing key, the `psa_key_id_t` parameter is replaced by a sequence of three parameters that describe the key:
1. `const psa_key_attributes_t *attributes`: the key attributes.
@ -148,15 +189,20 @@ The signature of a driver entry point generally looks like the signature of the
* For entry points that involve a multi-part operation, the operation state type (`psa_XXX_operation_t`) is replaced by a driver-specific operation state type (*prefix*`_XXX_operation_t`).
Some entry points are grouped in families that must be implemented as a whole. If a driver supports a entry point family, it must provide all the entry points in the family.
* For entry points that are involved in key creation, the `psa_key_id_t *` output parameter is replaced by a sequence of parameters that convey the key context:
1. `uint8_t *key_buffer`: a buffer for the key material or key context.
2. `size_t key_buffer_size`: the size of the key buffer in bytes.
2. `size_t *key_buffer_length`: the length of the data written to the key buffer in bytes.
Some entry points are grouped in families that must be implemented as a whole. If a driver supports an entry point family, it must provide all the entry points in the family.
#### General considerations on driver entry point parameters
Buffer parameters for driver entry points obey the following conventions:
* An input buffer has the type `const uint8_t *` and is immediately followed by a parameter of type `size_t` that indicates the buffer size.
* An output buffer has the type `uint8_t *` and is immediately followed by a parameter of type `size_t` that indicates the buffer size. A third parameter of type `size_t *` is provided to report the actual buffer size if the function succeeds.
* An in-out buffer has the type `uint8_t *` and is immediately followed by a parameter of type `size_t` that indicates the buffer size. Note that the buffer size does not change.
* An output buffer has the type `uint8_t *` and is immediately followed by a parameter of type `size_t` that indicates the buffer size. A third parameter of type `size_t *` is provided to report the actual length of the data written in the buffer if the function succeeds.
* An in-out buffer has the type `uint8_t *` and is immediately followed by a parameter of type `size_t` that indicates the buffer size. In-out buffers are only used when the input and the output have the same length.
Buffers of size 0 may be represented with either a null pointer or a non-null pointer.
@ -201,15 +247,15 @@ This family corresponds to the calculation of a hash in multiple steps.
This family applies to transparent drivers only.
This family requires the following type and functions:
This family requires the following type and entry points:
* Type `"hash_operation_t"`: the type of a hash operation context. It must be possible to copy a hash operation context byte by byte, therefore hash operation contexts must not contain any embedded pointers (except pointers to global data that do not change after the setup step).
* `"hash_setup"`: called by `psa_hash_setup()`.
* `"hash_update"`: called by `psa_hash_update()`.
* `"hash_finish"`: called by `psa_hash_finish()` and `psa_hash_verify()`.
* `"hash_abort"`: called by all multi-part hash functions.
* `"hash_abort"`: called by all multi-part hash functions of the PSA Cryptography API.
To verify a hash with `psa_hash_verify()`, the core calls the driver's *prefix`_hash_finish` entry point and compares the result with the reference hash value.
To verify a hash with `psa_hash_verify()`, the core calls the driver's *prefix*`_hash_finish` entry point and compares the result with the reference hash value.
For example, a driver with the prefix `"acme"` that implements the `"hash_multipart"` entry point family must define the following type and entry points (assuming that the capability does not use the `"names"` property to declare different type and entry point names):
@ -261,7 +307,8 @@ This family requires the following type and entry points:
* `"key_derivation_input_bytes"`: called by `psa_key_derivation_input_bytes()` and `psa_key_derivation_input_key()`. For transparent drivers, when processing a call to `psa_key_derivation_input_key()`, the core always calls the applicable driver's `"key_derivation_input_bytes"` entry point.
* `"key_derivation_input_key"` (opaque drivers only)
* `"key_derivation_output_bytes"`: called by `psa_key_derivation_output_bytes()`; also by `psa_key_derivation_output_key()` for transparent drivers.
* `"key_derivation_abort"`: called by all key derivation functions.
* `"key_derivation_output_key"`: called by `psa_key_derivation_output_key()` for transparent drivers when deriving an asymmetric key pair, and also for opaque drivers.
* `"key_derivation_abort"`: called by all key derivation functions of the PSA Cryptography API.
TODO: key input and output for opaque drivers; deterministic key generation for transparent drivers
@ -269,45 +316,127 @@ TODO
### Driver entry points for key management
The driver entry points for key management differs significantly between [transparent drivers](#key-management-with-transparent-drivers) and [opaque drivers](#key-management-with-transparent-drivers). Refer to the applicable section for each driver type.
The driver entry points for key management differ significantly between [transparent drivers](#key-management-with-transparent-drivers) and [opaque drivers](#key-management-with-opaque-drivers). This section describes common elements. Refer to the applicable section for each driver type for more information.
The entry points that create or format key data have the following prototypes for a driver with the prefix `"acme"`:
```
psa_status_t acme_import_key(const psa_key_attributes_t *attributes,
const uint8_t *data,
size_t data_length,
uint8_t *key_buffer,
size_t key_buffer_size,
size_t *key_buffer_length,
size_t *bits); // additional parameter, see below
psa_status_t acme_generate_key(const psa_key_attributes_t *attributes,
uint8_t *key_buffer,
size_t key_buffer_size,
size_t *key_buffer_length);
```
TODO: derivation, copy
* The key attributes (`attributes`) have the same semantics as in the PSA Cryptography application interface.
* For the `"import_key"` entry point, the input in the `data` buffer is either the export format or an implementation-specific format that the core documents as an acceptable input format for `psa_import_key()`.
* The size of the key data buffer `key_buffer` is sufficient for the internal representation of the key. For a transparent driver, this is the key's [export format](#key-format-for-transparent-drivers). For an opaque driver, this is the size determined from the driver description and the key attributes, as specified in the section [“Key format for opaque drivers”](#key-format-for-opaque-drivers).
* For an opaque driver with an `"allocate_key"` entry point, the content of the key data buffer on entry is the output of that entry point.
* The `"import_key"` entry point must determine or validate the key size and set `*bits` as described in the section [“Key size determination on import”](#key-size-determination-on-import) below.
All key creation entry points must ensure that the resulting key is valid as specified in the section [“Key validation”](#key-validation) below. This is primarily important for import entry points since the key data comes from the application.
#### Key size determination on import
The `"import_key"` entry point must determine or validate the key size.
The PSA Cryptography API exposes the key size as part of the key attributes.
When importing a key, the key size recorded in the key attributes can be either a size specified by the caller of the API (who may not be trusted), or `0` which indicates that the size must be calculated from the data.
When the core calls the `"import_key"` entry point to process a call to `psa_import_key`, it passes an `attributes` structure such that `psa_get_key_bits(attributes)` is the size passed by the caller of `psa_import_key`. If this size is `0`, the `"import_key"` entry point must set the `bits` input-output parameter to the correct key size. The semantics of `bits` is as follows:
* The core sets `*bits` to `psa_get_key_bits(attributes)` before calling the `"import_key"` entry point.
* If `*bits == 0`, the driver must determine the key size from the data and set `*bits` to this size. If the key size cannot be determined from the data, the driver must return `PSA_ERROR_INVALID_ARGUMENT` (as of version 1.0 of the PSA Cryptography API specification, it is possible to determine the key size for all standard key types).
* If `*bits != 0`, the driver must check the value of `*bits` against the data and return `PSA_ERROR_INVALID_ARGUMENT` if it does not match. If the driver entry point changes `*bits` to a different value but returns `PSA_SUCCESS`, the core will consider the key as invalid and the import will fail.
#### Key validation
Key creation entry points must produce valid key data. Key data is _valid_ if operations involving the key are guaranteed to work functionally and not to cause indirect security loss. Operation functions are supposed to receive valid keys, and should not have to check and report invalid keys. For example:
* If a cryptographic mechanism is defined as having keying material of a certain size, or if the keying material involves integers that have to be in a certain range, key creation must ensure that the keying material has an appropriate size and falls within an appropriate range.
* If a cryptographic operation involves a division by an integer which is provided as part of a key, key creation must ensure that this integer is nonzero.
* If a cryptographic operation involves two keys A and B (or more), then the creation of A must ensure that using it does not risk compromising B. This applies even if A's policy does not explicitly allow a problematic operation, but A is exportable. In particular, public keys that can potentially be used for key agreement are considered invalid and must not be created if they risk compromising the private key.
* On the other hand, it is acceptable for import to accept a key that cannot be verified as valid if using this key would at most compromise the key itself and material that is secured with this key. For example, RSA key import does not need to verify that the primes are actually prime. Key import may accept an insecure key if the consequences of the insecurity are no worse than a leak of the key prior to its import.
With opaque drivers, the key context can only be used by code from the same driver, so key validity is primarily intended to report key creation errors at creation time rather than during an operation. With transparent drivers, the key context can potentially be used by code from a different provider, so key validity is critical for interoperability.
This section describes some minimal validity requirements for standard key types.
* For symmetric key types, check that the key size is suitable for the type.
* For DES (`PSA_KEY_TYPE_DES`), additionally verify the parity bits.
* For RSA (`PSA_KEY_TYPE_RSA_PUBLIC_KEY`, `PSA_KEY_TYPE_RSA_KEY_PAIR`), check the syntax of the key and make sanity checks on its components. TODO: what sanity checks? Value ranges (e.g. p < n), sanity checks such as parity, minimum and maximum size, what else?
* For elliptic curve private keys (`PSA_KEY_TYPE_ECC_KEY_PAIR`), check the size and range. TODO: what else?
* For elliptic curve public keys (`PSA_KEY_TYPE_ECC_PUBLIC_KEY`), check the size and range, and that the point is on the curve. TODO: what else?
### Miscellaneous driver entry points
#### Driver initialization
A driver may declare an `"init"` entry point in a capability with no algorithm, key type or key size. If so, the driver calls this entry point once during the initialization of the PSA Crypto subsystem. If the init entry point of any driver fails, the initialization of the PSA Crypto subsystem fails.
A driver may declare an `"init"` entry point in a capability with no algorithm, key type or key size. If so, the core calls this entry point once during the initialization of the PSA Cryptography subsystem. If the init entry point of any driver fails, the initialization of the PSA Cryptography subsystem fails.
When multiple drivers have an init entry point, the order in which they are called is unspecified. It is also unspecified whether other drivers' init functions are called if one or more init function fails.
When multiple drivers have an init entry point, the order in which they are called is unspecified. It is also unspecified whether other drivers' `"init"` entry points are called if one or more init entry point fails.
On platforms where the PSA Crypto implementation is a subsystem of a single application, the initialization of the PSA Crypto subsystem takes place during the call to `psa_crypto_init()`. On platforms where the PSA Crypto implementation is separate from the application or applications, the initialization the initialization of the PSA Crypto subsystem takes place before or during the first time an application calls `psa_crypto_init()`.
On platforms where the PSA Cryptography implementation is a subsystem of a single application, the initialization of the PSA Cryptography subsystem takes place during the call to `psa_crypto_init()`. On platforms where the PSA Cryptography implementation is separate from the application or applications, the initialization of the PSA Cryptography subsystem takes place before or during the first time an application calls `psa_crypto_init()`.
The init function does not take any parameter.
The init entry point does not take any parameter.
### Combining multiple drivers
To declare a cryptoprocessor can handle both cleartext and plaintext keys, you need to provide two driver descriptions, one for a transparent driver and one for an opaque driver. You can use the mapping in capabilities' `"names"` property to arrange for multiple driver entry points to map to the same C function.
To declare a cryptoprocessor can handle both cleartext and wrapped keys, you need to provide two driver descriptions, one for a transparent driver and one for an opaque driver. You can use the mapping in capabilities' `"names"` property to arrange for multiple driver entry points to map to the same C function.
## Transparent drivers
### Key format for transparent drivers
The format of a key for transparent drivers is the same as in applications. Refer to the documentation of `psa_export_key()` and `psa_export_public_key()`.
The format of a key for transparent drivers is the same as in applications. Refer to the documentation of [`psa_export_key()`](https://armmbed.github.io/mbed-crypto/html/api/keys/management.html#c.psa_export_key) and [`psa_export_public_key()`](https://armmbed.github.io/mbed-crypto/html/api/keys/management.html#c.psa_export_public_key) in the PSA Cryptography API specification. For custom key types defined by an implementation, refer to the documentation of that implementation.
### Key management with transparent drivers
Transparent drivers may provide the following key management entry points:
* `"generate_key"`: called by `psa_generate_key()`, only when generating a key pair (key such that `PSA_KEY_TYPE_IS_ASYMMETRIC` is true).
* `"derive_key"`: called by `psa_key_derivation_output_key()`, only when deriving a key pair (key such that `PSA_KEY_TYPE_IS_ASYMMETRIC` is true).
* [`"import_key"`](#key-import-with-transparent-drivers): called by `psa_import_key()`, only when importing a key pair or a public key (key such that `PSA_KEY_TYPE_IS_ASYMMETRIC` is true).
* `"generate_key"`: called by `psa_generate_key()`, only when generating a key pair (key such that `PSA_KEY_TYPE_IS_KEY_PAIR` is true).
* `"key_derivation_output_key"`: called by `psa_key_derivation_output_key()`, only when deriving a key pair (key such that `PSA_KEY_TYPE_IS_KEY_PAIR` is true).
* `"export_public_key"`: called by the core to obtain the public key of a key pair. The core may call this function at any time to obtain the public key, which can be for `psa_export_public_key()` but also at other times, including during a cryptographic operation that requires the public key such as a call to `psa_verify_message()` on a key pair object.
Transparent drivers are not involved when importing, exporting, copying or destroying keys, or when generating or deriving symmetric keys.
Transparent drivers are not involved when exporting, copying or destroying keys, or when importing, generating or deriving symmetric keys.
#### Key import with transparent drivers
As discussed in [the general section about key management entry points](#driver-entry-points-for-key-management), the key import entry points has the following prototype for a driver with the prefix `"acme"`:
```
psa_status_t acme_import_key(const psa_key_attributes_t *attributes,
const uint8_t *data,
size_t data_length,
uint8_t *key_buffer,
size_t key_buffer_size,
size_t *key_buffer_length,
size_t *bits);
```
This entry point has several roles:
1. Parse the key data in the input buffer `data`. The driver must support the export format for the key types that the entry point is declared for. It may support additional formats as specified in the description of [`psa_import_key()`](https://armmbed.github.io/mbed-crypto/html/api/keys/management.html#c.psa_export_key) in the PSA Cryptography API specification.
2. Validate the key data. The necessary validation is described in the section [“Key validation with transparent drivers”](#key-validation-with-transparent-drivers) above.
3. [Determine the key size](#key-size-determination-on-import) and output it through `*bits`.
4. Copy the validated key data from `data` to `key_buffer`. The output must be in the canonical format documented for [`psa_export_key()`](https://armmbed.github.io/mbed-crypto/html/api/keys/management.html#c.psa_export_key) or [`psa_export_public_key()`](https://armmbed.github.io/mbed-crypto/html/api/keys/management.html#c.psa_export_public_key), so if the input is not in this format, the entry point must convert it.
### Fallback
If a transparent driver entry point is part of a capability which has a true `"fallback"` property and returns `PSA_ERROR_NOT_SUPPORTED`, the built-in software implementation will be called instead. Any other value (`PSA_SUCCESS` or a different error code) is returned to the application.
Sometimes cryptographic accelerators only support certain cryptographic mechanisms partially. The capability description language allows specifying some restrictions, including restrictions on key sizes, but it cannot cover all the possibilities that may arise in practice. Furthermore, it may be desirable to deploy the same binary image on different devices, only some of which have a cryptographic accelerators.
For these purposes, a transparent driver can declare that it only supports a [capability](#driver-description-capability) partially, by setting the capability's `"fallback"` property to true.
If there are multiple available transparent drivers, the core tries them in turn until one is declared without a true `"fallback"` property or returns a status other than `PSA_ERROR_NOT_SUPPORTED`. The order in which the drivers are called is unspecified and may be different for different entry points.
If a transparent driver entry point is part of a capability which has a true `"fallback"` property and returns `PSA_ERROR_NOT_SUPPORTED`, the core will call the next transparent driver that supports the mechanism, if there is one. The core considers drivers in the order given by the [driver description list](#driver-description-list).
If all the available drivers have fallback enabled and return `PSA_ERROR_NOT_SUPPORTED`, the core will perform the operation using built-in code.
As soon as a driver returns any value other than `PSA_ERROR_NOT_SUPPORTED` (`PSA_SUCCESS` or a different error code), this value is returned to the application, without attempting to call any other driver or built-in code.
If a transparent driver entry point is part of a capability where the `"fallback"` property is false or omitted, the core should not include any other code for this capability, whether built in or in another transparent driver.
@ -379,13 +508,13 @@ If the key is stored in wrapped form outside the secure element, and the wrapped
### Key management with opaque drivers
Transparent drivers may provide the following key management entry points:
Opaque drivers may provide the following key management entry points:
* `"export_key"`: called by `psa_export_key()`, or by `psa_copy_key()` when copying a key from or to a different [location](#lifetimes-and-locations).
* `"export_public_key"`: called by the core to obtain the public key of a key pair. The core may call this entry point at any time to obtain the public key, which can be for `psa_export_public_key()` but also at other times, including during a cryptographic operation that requires the public key such as a call to `psa_verify_message()` on a key pair object.
* `"import_key"`: called by `psa_import_key()`, or by `psa_copy_key()` when copying a key from another location.
* `"generate_key"`: called by `psa_generate_key()`.
* `"derive_key"`: called by `psa_key_derivation_output_key()`.
* `"key_derivation_output_key"`: called by `psa_key_derivation_output_key()`.
* `"copy_key"`: called by `psa_copy_key()` when copying a key within the same [location](#lifetimes-and-locations).
In addition, secure elements that store the key material internally must provide the following two entry points:
@ -400,7 +529,7 @@ This section describes the key creation process for secure elements that do not
When creating a key with an opaque driver which does not have an `"allocate_key"` or `"destroy_key"` entry point:
1. The core allocates memory for the key context.
2. The core calls the driver's import, generate, derive or copy function.
2. The core calls the driver's import, generate, derive or copy entry point.
3. The core saves the resulting wrapped key material and any other data that the key context may contain.
To destroy a key, the core simply destroys the wrapped key material, without invoking driver code.
@ -412,7 +541,7 @@ This section describes the key creation and key destruction processes for secure
* `"allocate_key"`: this function obtains an internal identifier for the key. This may be, for example, a unique label or a slot number.
* `"destroy_key"`: this function invalidates the internal identifier and destroys the associated key material.
These functions have the following prototypes:
These functions have the following prototypes for a driver with the prefix `"acme"`:
```
psa_status_t acme_allocate_key(const psa_key_attributes_t *attributes,
uint8_t *key_buffer,
@ -439,7 +568,7 @@ If a failure occurs after the `"allocate_key"` step but before the call to the s
To destroy a key, the core calls the driver's `"destroy_key"` entry point.
Note that the key allocation and destruction entry point must not rely solely on the key identifier in the key attributes to identify a key. Some implementations of the PSA Crypto API store keys on behalf of multiple clients, and different clients may use the same key identifier to designate different keys. The manner in which the core distinguishes keys that have the same identifier but are part of the key namespace for different clients is implementation-dependent and is not accessible to drivers. Some typical strategies to allocate an internal key identifier are:
Note that the key allocation and destruction entry points must not rely solely on the key identifier in the key attributes to identify a key. Some implementations of the PSA Cryptography API store keys on behalf of multiple clients, and different clients may use the same key identifier to designate different keys. The manner in which the core distinguishes keys that have the same identifier but are part of the key namespace for different clients is implementation-dependent and is not accessible to drivers. Some typical strategies to allocate an internal key identifier are:
* Maintain a set of free slot numbers which is stored either in the secure element or in the driver's persistent storage. To allocate a key slot, find a free slot number, mark it as occupied and store the number in the key context. When the key is destroyed, mark the slot number as free.
* Maintain a monotonic counter with a practically unbounded range in the secure element or in the driver's persistent storage. To allocate a key slot, increment the counter and store the current value in the key context. Destroying a key does not change the counter.
@ -450,37 +579,40 @@ TODO: some of the above doesn't apply to volatile keys
#### Key creation entry points in opaque drivers
The key creation entry points have the following prototypes:
The key creation entry points have the following prototypes for a driver with the prefix `"acme"`:
```
psa_status_t acme_import_key(const psa_key_attributes_t *attributes,
const uint8_t *data,
size_t data_length,
uint8_t *key_buffer,
size_t key_buffer_size);
size_t key_buffer_size,
size_t *key_buffer_length,
size_t *bits);
psa_status_t acme_generate_key(const psa_key_attributes_t *attributes,
uint8_t *key_buffer,
size_t key_buffer_size);
size_t key_buffer_size,
size_t *key_buffer_length);
```
If the driver has an [`"allocate_key"` entry point](#key-management-in-a-secure-element-with-storage), the core calls the `"allocate_key"` entry point with the same attributes on the same key buffer before calling the key creation function.
If the driver has an [`"allocate_key"` entry point](#key-management-in-a-secure-element-with-storage), the core calls the `"allocate_key"` entry point with the same attributes on the same key buffer before calling the key creation entry point.
TODO: derivation, copy
#### Key export entry points in opaque drivers
The key export entry points have the following prototypes:
The key export entry points have the following prototypes for a driver with the prefix `"acme"`:
```
psa_status_t acme_export_key(const psa_key_attributes_t *attributes,
const uint8_t *key_buffer,
size_t key_buffer_size);
size_t key_buffer_size,
uint8_t *data,
size_t data_size,
size_t *data_length);
psa_status_t acme_export_public_key(const psa_key_attributes_t *attributes,
const uint8_t *key_buffer,
size_t key_buffer_size);
size_t key_buffer_size,
uint8_t *data,
size_t data_size,
size_t *data_length);
@ -524,7 +656,7 @@ Transparent drivers linked into the library are automatically used for the mecha
Each opaque driver is assigned a [location](#lifetimes-and-locations). The driver is invoked for all actions that use a key in that location. A key's location is indicated by its lifetime. The application chooses the key's lifetime when it creates the key.
For example, the following snippet creates an AES-GCM key which is only accessible inside a secure element.
For example, the following snippet creates an AES-GCM key which is only accessible inside the secure element designated by the location `PSA_KEY_LOCATION_acme`.
```
psa_key_attributes_t attributes = PSA_KEY_ATTRIBUTES_INIT;
psa_set_key_lifetime(&attributes, PSA_KEY_LIFETIME_FROM_PERSISTENCE_AND_LOCATION(
@ -534,8 +666,8 @@ psa_set_key_type(&attributes, PSA_KEY_TYPE_AES);
psa_set_key_size(&attributes, 128);
psa_set_key_algorithm(&attributes, PSA_ALG_GCM);
psa_set_key_usage_flags(&attributes, PSA_KEY_USAGE_ENCRYPT | PSA_KEY_USAGE_DECRYPT);
psa_key_handle_t handle = 0;
psa_generate_key(&attributes, &handle);
psa_key_id_t key;
psa_generate_key(&attributes, &key);
```
## Using opaque drivers from an application
@ -574,9 +706,9 @@ psa_set_key_lifetime(&attributes, PSA_KEY_LIFETIME_FROM_PERSISTENCE_AND_LOCATION
### Driver declarations
#### Declaring driver functions
#### Declaring driver entry points
The core may want to provide declarations for the driver functions so that it can compile code using them. At the time of writing this paragraph, the driver headers must define types but there is no obligation for them to declare functions. The core knows what the function names and argument types are, so it can generate prototypes.
The core may want to provide declarations for the driver entry points so that it can compile code using them. At the time of writing this paragraph, the driver headers must define types but there is no obligation for them to declare functions. The core knows what the function names and argument types are, so it can generate prototypes.
It should be ok for driver functions to be function-like macros or function pointers.
@ -586,6 +718,14 @@ How does a driver author decide which location values to use? It should be possi
Can the driver assembly process generate distinct location values as needed? This can be convenient, but it's also risky: if you upgrade a device, you need the location values to be the same between builds.
The current plan is for Arm to maintain a registry of vendors and assign a location namespace to each vendor. Parts of the namespace would be reserved for implementations and integrators.
#### Multiple transparent drivers
When multiple transparent drivers implement the same mechanism, which one is called? The first one? The last one? Unspecified? Or is this an error (excluding capabilities with fallback enabled)?
The current choice is that the first one is used, which allows having a preference order on drivers, but may mask integration errors.
### Driver function interfaces
#### Driver function parameter conventions
@ -619,6 +759,16 @@ ECC key pairs are represented as the private key value only. The public key need
The specification doesn't mention when the public key might be calculated. The core may calculate it on creation, on demand, or anything in between. Opaque drivers have a choice of storing the public key in the key context or calculating it on demand and can convey whether the core should store the public key with the `"store_public_key"` property. Is this good enough or should the specification include non-functional requirements?
#### Symmetric key validation with transparent drivers
Should the entry point be called for symmetric keys as well?
#### Support for custom import formats
[“Driver entry points for key management”](#driver-entry-points-for-key-management) states that the input to `"import_key"` can be an implementation-defined format. Is this a good idea? It reduces driver portability, since a core that accepts a custom format would not work with a driver that doesn't accept this format. On the other hand, if a driver accepts a custom format, the core should let it through because the driver presumably handles it more efficiently (in terms of speed and code size) than the core could.
Allowing custom formats also causes a problem with import: the core can't know the size of the key representation until it knows the bit-size of the key, but determining the bit-size of the key is part of the job of the `"import_key"` entry point. For standard key types, this could plausibly be an issue for RSA private keys, where an implementation might accept a custom format that omits the CRT parameters (or that omits *d*).
### Opaque drivers
#### Opaque driver persistent state

2
doxygen/input/doc_mainpage.h
View file

@ -22,7 +22,7 @@
*/
/**
* @mainpage mbed TLS v2.23.0 source code documentation
* @mainpage mbed TLS v2.24.0 source code documentation
*
* This documentation describes the internal structure of mbed TLS. It was
* automatically generated from specially formatted comment blocks in

2
doxygen/mbedtls.doxyfile
View file

@ -28,7 +28,7 @@ DOXYFILE_ENCODING = UTF-8
# identify the project. Note that if you do not use Doxywizard you need
# to put quotes around the project name if it contains spaces.
PROJECT_NAME = "mbed TLS v2.23.0"
PROJECT_NAME = "mbed TLS v2.24.0"
# The PROJECT_NUMBER tag can be used to enter a project or revision number.
# This could be handy for archiving the generated documentation or

4
include/mbedtls/bignum.h
View file

@ -61,12 +61,12 @@
* Maximum window size used for modular exponentiation. Default: 6
* Minimum value: 1. Maximum value: 6.
*
* Result is an array of ( 2 << MBEDTLS_MPI_WINDOW_SIZE ) MPIs used
* Result is an array of ( 2 ** MBEDTLS_MPI_WINDOW_SIZE ) MPIs used
* for the sliding window calculation. (So 64 by default)
*
* Reduction in size, reduces speed.
*/
#define MBEDTLS_MPI_WINDOW_SIZE 6 /**< Maximum windows size used. */
#define MBEDTLS_MPI_WINDOW_SIZE 6 /**< Maximum window size used. */
#endif /* !MBEDTLS_MPI_WINDOW_SIZE */
#if !defined(MBEDTLS_MPI_MAX_SIZE)

4
include/mbedtls/ccm.h
View file

@ -148,7 +148,7 @@ void mbedtls_ccm_free( mbedtls_ccm_context *ctx );
* than zero, \p output must be a writable buffer of at least
* that length.
* \param tag The buffer holding the authentication field. This must be a
* readable buffer of at least \p tag_len Bytes.
* writable buffer of at least \p tag_len Bytes.
* \param tag_len The length of the authentication field to generate in Bytes:
* 4, 6, 8, 10, 12, 14 or 16.
*
@ -193,7 +193,7 @@ int mbedtls_ccm_encrypt_and_tag( mbedtls_ccm_context *ctx, size_t length,
* than zero, \p output must be a writable buffer of at least
* that length.
* \param tag The buffer holding the authentication field. This must be a
* readable buffer of at least \p tag_len Bytes.
* writable buffer of at least \p tag_len Bytes.
* \param tag_len The length of the authentication field to generate in Bytes:
* 0, 4, 6, 8, 10, 12, 14 or 16.
*

9
include/mbedtls/check_config.h
View file

@ -609,6 +609,11 @@
#error "MBEDTLS_PSA_ITS_FILE_C defined, but not all prerequisites"
#endif
#if defined(MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER) && \
defined(MBEDTLS_USE_PSA_CRYPTO)
#error "MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER defined, but it cannot coexist with MBEDTLS_USE_PSA_CRYPTO."
#endif
#if defined(MBEDTLS_RSA_C) && ( !defined(MBEDTLS_BIGNUM_C) || \
!defined(MBEDTLS_OID_C) )
#error "MBEDTLS_RSA_C defined, but not all prerequisites"
@ -871,6 +876,10 @@
#endif /* MBEDTLS_DEPRECATED_REMOVED */
#endif /* MBEDTLS_SSL_HW_RECORD_ACCEL */
#if defined(MBEDTLS_SSL_DTLS_SRTP) && ( !defined(MBEDTLS_SSL_PROTO_DTLS) )
#error "MBEDTLS_SSL_DTLS_SRTP defined, but not all prerequisites"
#endif
/*
* Avoid warning from -pedantic. This is a convenient place for this
* workaround since this is included by every single file before the

20
include/mbedtls/cipher.h
View file

@ -227,10 +227,30 @@ enum {
};
/** Maximum length of any IV, in Bytes. */
/* This should ideally be derived automatically from list of ciphers.
* This should be kept in sync with MBEDTLS_SSL_MAX_IV_LENGTH defined
* in ssl_internal.h. */
#define MBEDTLS_MAX_IV_LENGTH 16
/** Maximum block size of any cipher, in Bytes. */
/* This should ideally be derived automatically from list of ciphers.
* This should be kept in sync with MBEDTLS_SSL_MAX_BLOCK_LENGTH defined
* in ssl_internal.h. */
#define MBEDTLS_MAX_BLOCK_LENGTH 16
/** Maximum key length, in Bytes. */
/* This should ideally be derived automatically from list of ciphers.
* For now, only check whether XTS is enabled which uses 64 Byte keys,
* and use 32 Bytes as an upper bound for the maximum key length otherwise.
* This should be kept in sync with MBEDTLS_SSL_MAX_BLOCK_LENGTH defined
* in ssl_internal.h, which however deliberately ignores the case of XTS
* since the latter isn't used in SSL/TLS. */
#if defined(MBEDTLS_CIPHER_MODE_XTS)
#define MBEDTLS_MAX_KEY_LENGTH 64
#else
#define MBEDTLS_MAX_KEY_LENGTH 32
#endif /* MBEDTLS_CIPHER_MODE_XTS */
/**
* Base cipher information (opaque struct).
*/

2
include/mbedtls/cipher_internal.h
View file

@ -134,7 +134,7 @@ typedef enum
typedef struct
{
psa_algorithm_t alg;
psa_key_handle_t slot;
psa_key_id_t slot;
mbedtls_cipher_psa_key_ownership slot_state;
} mbedtls_cipher_context_psa;
#endif /* MBEDTLS_USE_PSA_CRYPTO */

83
include/mbedtls/config.h
View file

@ -864,7 +864,7 @@
* may result in a compromise of the long-term signing key. This is avoided by
* the deterministic variant.
*
* Requires: MBEDTLS_HMAC_DRBG_C
* Requires: MBEDTLS_HMAC_DRBG_C, MBEDTLS_ECDSA_C
*
* Comment this macro to disable deterministic ECDSA.
*/
@ -1258,20 +1258,17 @@
*/
//#define MBEDTLS_ENTROPY_NV_SEED
/* MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER
/* MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER
*
* In PSA key storage, encode the owner of the key.
* Enable key identifiers that encode a key owner identifier.
*
* This is only meaningful when building the library as part of a
* multi-client service. When you activate this option, you must provide
* an implementation of the type psa_key_owner_id_t and a translation
* from psa_key_file_id_t to file name in all the storage backends that
* you wish to support.
* The owner of a key is identified by a value of type ::mbedtls_key_owner_id_t
* which is currently hard-coded to be int32_t.
*
* Note that this option is meant for internal use only and may be removed
* without notice.
* without notice. It is incompatible with MBEDTLS_USE_PSA_CRYPTO.
*/
//#define MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER
//#define MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER
/**
* \def MBEDTLS_MEMORY_DEBUG
@ -1329,6 +1326,17 @@
*/
#define MBEDTLS_PKCS1_V21
/** \def MBEDTLS_PSA_CRYPTO_DRIVERS
*
* Enable support for the experimental PSA crypto driver interface.
*
* Requires: MBEDTLS_PSA_CRYPTO_C
*
* \warning This interface is experimental and may change or be removed
* without notice.
*/
//#define MBEDTLS_PSA_CRYPTO_DRIVERS
/**
* \def MBEDTLS_PSA_CRYPTO_SPM
*
@ -1804,6 +1812,37 @@
*/
#define MBEDTLS_SSL_DTLS_HELLO_VERIFY
/**
* \def MBEDTLS_SSL_DTLS_SRTP
*
* Enable support for negotation of DTLS-SRTP (RFC 5764)
* through the use_srtp extension.
*
* \note This feature provides the minimum functionality required
* to negotiate the use of DTLS-SRTP and to allow the derivation of
* the associated SRTP packet protection key material.
* In particular, the SRTP packet protection itself, as well as the
* demultiplexing of RTP and DTLS packets at the datagram layer
* (see Section 5 of RFC 5764), are not handled by this feature.
* Instead, after successful completion of a handshake negotiating
* the use of DTLS-SRTP, the extended key exporter API
* mbedtls_ssl_conf_export_keys_ext_cb() should be used to implement
* the key exporter described in Section 4.2 of RFC 5764 and RFC 5705
* (this is implemented in the SSL example programs).
* The resulting key should then be passed to an SRTP stack.
*
* Setting this option enables the runtime API
* mbedtls_ssl_conf_dtls_srtp_protection_profiles()
* through which the supported DTLS-SRTP protection
* profiles can be configured. You must call this API at
* runtime if you wish to negotiate the use of DTLS-SRTP.
*
* Requires: MBEDTLS_SSL_PROTO_DTLS
*
* Uncomment this to enable support for use_srtp extension.
*/
//#define MBEDTLS_SSL_DTLS_SRTP
/**
* \def MBEDTLS_SSL_DTLS_CLIENT_PORT_REUSE
*
@ -2011,6 +2050,24 @@
*/
//#define MBEDTLS_USE_PSA_CRYPTO
/**
* \def MBEDTLS_PSA_CRYPTO_CONFIG
*
* This setting allows support for cryptographic mechanisms through the PSA
* API to be configured separately from support through the mbedtls API.
*
* Uncomment this to enable use of PSA Crypto configuration settings which
* can be found in include/psa/crypto_config.h.
*
* If you enable this option and write your own configuration file, you must
* include mbedtls/config_psa.h in your configuration file. The default
* provided mbedtls/config.h contains the necessary inclusion.
*
* This feature is still experimental and is not ready for production since
* it is not completed.
*/
//#define MBEDTLS_PSA_CRYPTO_CONFIG
/**
* \def MBEDTLS_VERSION_FEATURES
*
@ -3450,7 +3507,7 @@
*/
/* MPI / BIGNUM options */
//#define MBEDTLS_MPI_WINDOW_SIZE 6 /**< Maximum windows size used. */
//#define MBEDTLS_MPI_WINDOW_SIZE 6 /**< Maximum window size used. */
//#define MBEDTLS_MPI_MAX_SIZE 1024 /**< Maximum number of bytes for usable MPIs. */
/* CTR_DRBG options */
@ -3803,6 +3860,10 @@
#include MBEDTLS_USER_CONFIG_FILE
#endif
#if defined(MBEDTLS_PSA_CRYPTO_CONFIG)
#include "mbedtls/config_psa.h"
#endif
#include "mbedtls/check_config.h"
#endif /* MBEDTLS_CONFIG_H */

233
include/mbedtls/config_psa.h Normal file
View file

@ -0,0 +1,233 @@
/**
* \file mbedtls/config_psa.h
* \brief PSA crypto configuration options (set of defines)
*
* This set of compile-time options takes settings defined in
* include/mbedtls/config.h and include/psa/crypto_config.h and uses
* those definitions to define symbols used in the library code.
*
* Users and integrators should not edit this file, please edit
* include/mbedtls/config.h for MBETLS_XXX settings or
* include/psa/crypto_config.h for PSA_WANT_XXX settings.
*/
/*
* Copyright The Mbed TLS Contributors
* 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.
*/
#ifndef MBEDTLS_CONFIG_PSA_H
#define MBEDTLS_CONFIG_PSA_H
#if defined(MBEDTLS_PSA_CRYPTO_CONFIG)
#include "psa/crypto_config.h"
#endif /* defined(MBEDTLS_PSA_CRYPTO_CONFIG) */
#ifdef __cplusplus
extern "C" {
#endif
#if defined(MBEDTLS_PSA_CRYPTO_CONFIG)
#if defined(PSA_WANT_ALG_DETERMINISTIC_ECDSA)
#if !defined(MBEDTLS_PSA_ACCEL_ALG_DETERMINISTIC_ECDSA)
#define MBEDTLS_PSA_BUILTIN_ALG_DETERMINISTIC_ECDSA 1
#define MBEDTLS_ECDSA_DETERMINISTIC
#define MBEDTLS_ECDSA_C
#define MBEDTLS_HMAC_DRBG_C
#define MBEDTLS_MD_C
#endif /* !MBEDTLS_PSA_ACCEL_ALG_DETERMINISTIC_ECDSA */
#endif /* PSA_WANT_ALG_DETERMINISTIC_ECDSA */
#if defined(PSA_WANT_ALG_ECDH)
#if !defined(MBEDTLS_PSA_ACCEL_ALG_ECDH)
#define MBEDTLS_PSA_BUILTIN_ALG_ECDH 1
#define MBEDTLS_ECDH_C
#define MBEDTLS_ECP_C
#define MBEDTLS_BIGNUM_C
#endif /* !MBEDTLS_PSA_ACCEL_ALG_ECDH */
#endif /* PSA_WANT_ALG_ECDH */
#if defined(PSA_WANT_ALG_ECDSA)
#if !defined(MBEDTLS_PSA_ACCEL_ALG_ECDSA)
#define MBEDTLS_PSA_BUILTIN_ALG_ECDSA 1
#define MBEDTLS_ECDSA_C
#endif /* !MBEDTLS_PSA_ACCEL_ALG_ECDSA */
#endif /* PSA_WANT_ALG_ECDSA */
#if defined(PSA_WANT_ALG_HKDF)
#if !defined(MBEDTLS_PSA_ACCEL_ALG_HKDF)
#define MBEDTLS_PSA_BUILTIN_ALG_HMAC 1
#define MBEDTLS_PSA_BUILTIN_ALG_HKDF 1
#endif /* !MBEDTLS_PSA_ACCEL_ALG_HKDF */
#endif /* PSA_WANT_ALG_HKDF */
#if defined(PSA_WANT_ALG_HMAC)
#if !defined(MBEDTLS_PSA_ACCEL_ALG_HMAC)
#define MBEDTLS_PSA_BUILTIN_ALG_HMAC 1
#endif /* !MBEDTLS_PSA_ACCEL_ALG_HMAC */
#endif /* PSA_WANT_ALG_HMAC */
#if defined(PSA_WANT_ALG_RSA_OAEP)
#if !defined(MBEDTLS_PSA_ACCEL_ALG_RSA_OAEP)
#define MBEDTLS_PSA_BUILTIN_ALG_RSA_OAEP 1
#define MBEDTLS_RSA_C
#define MBEDTLS_BIGNUM_C
#define MBEDTLS_OID_C
#define MBEDTLS_PKCS1_V21
#define MBEDTLS_MD_C
#endif /* !MBEDTLS_PSA_ACCEL_ALG_RSA_OAEP */
#endif /* PSA_WANT_ALG_RSA_OAEP */
#if defined(PSA_WANT_ALG_RSA_PKCS1V15_CRYPT)
#if !defined(MBEDTLS_PSA_ACCEL_ALG_RSA_PKCS1V15_CRYPT)
#define MBEDTLS_PSA_BUILTIN_ALG_RSA_PKCS1V15_CRYPT 1
#define MBEDTLS_RSA_C
#define MBEDTLS_BIGNUM_C
#define MBEDTLS_OID_C
#define MBEDTLS_PKCS1_V15
#endif /* !MBEDTLS_PSA_ACCEL_ALG_RSA_PKCS1V15_CRYPT */
#endif /* PSA_WANT_ALG_RSA_PKCS1V15_CRYPT */
#if defined(PSA_WANT_ALG_RSA_PKCS1V15_SIGN)
#if !defined(MBEDTLS_PSA_ACCEL_ALG_RSA_PKCS1V15_SIGN)
#define MBEDTLS_PSA_BUILTIN_ALG_RSA_PKCS1V15_SIGN 1
#define MBEDTLS_RSA_C
#define MBEDTLS_BIGNUM_C
#define MBEDTLS_OID_C
#define MBEDTLS_PKCS1_V15
#define MBEDTLS_MD_C
#endif /* !MBEDTLS_PSA_ACCEL_ALG_RSA_PKCS1V15_SIGN */
#endif /* PSA_WANT_ALG_RSA_PKCS1V15_SIGN */
#if defined(PSA_WANT_ALG_RSA_PSS)
#if !defined(MBEDTLS_PSA_ACCEL_ALG_RSA_PSS)
#define MBEDTLS_PSA_BUILTIN_ALG_RSA_PSS 1
#define MBEDTLS_RSA_C
#define MBEDTLS_BIGNUM_C
#define MBEDTLS_OID_C
#define MBEDTLS_PKCS1_V21
#define MBEDTLS_MD_C
#endif /* !MBEDTLS_PSA_ACCEL_ALG_RSA_PSS */
#endif /* PSA_WANT_ALG_RSA_PSS */
#if defined(PSA_WANT_ALG_TLS12_PRF)
#if !defined(MBEDTLS_PSA_ACCEL_ALG_TLS12_PRF)
#define MBEDTLS_PSA_BUILTIN_ALG_TLS12_PRF 1
#endif /* !MBEDTLS_PSA_ACCEL_ALG_TLS12_PRF */
#endif /* PSA_WANT_ALG_TLS12_PRF */
#if defined(PSA_WANT_ALG_TLS12_PSK_TO_MS)
#if !defined(MBEDTLS_PSA_ACCEL_ALG_TLS12_PSK_TO_MS)
#define MBEDTLS_PSA_BUILTIN_ALG_TLS12_PSK_TO_MS 1
#endif /* !MBEDTLS_PSA_ACCEL_ALG_TLS12_PSK_TO_MS */
#endif /* PSA_WANT_ALG_TLS12_PSK_TO_MS */
#if defined(PSA_WANT_KEY_TYPE_ECC_KEY_PAIR)
#if !defined(MBEDTLS_PSA_ACCEL_KEY_TYPE_ECC_KEY_PAIR)
#define MBEDTLS_PSA_BUILTIN_KEY_TYPE_ECC_KEY_PAIR 1
#define MBEDTLS_ECP_C
#define MBEDTLS_BIGNUM_C
#endif /* !MBEDTLS_PSA_ACCEL_KEY_TYPE_ECC_KEY_PAIR */
#endif /* PSA_WANT_KEY_TYPE_ECC_KEY_PAIR */
#if defined(PSA_WANT_KEY_TYPE_ECC_PUBLIC_KEY)
#if !defined(MBEDTLS_PSA_ACCEL_KEY_TYPE_ECC_PUBLIC_KEY)
#define MBEDTLS_PSA_BUILTIN_KEY_TYPE_ECC_PUBLIC_KEY 1
#define MBEDTLS_ECP_C
#define MBEDTLS_BIGNUM_C
#endif /* !MBEDTLS_PSA_ACCEL_KEY_TYPE_ECC_PUBLIC_KEY */
#endif /* PSA_WANT_KEY_TYPE_ECC_PUBLIC_KEY */
#if defined(PSA_WANT_KEY_TYPE_RSA_KEY_PAIR)
#if !defined(MBEDTLS_PSA_ACCEL_KEY_TYPE_RSA_KEY_PAIR)
#define MBEDTLS_PSA_BUILTIN_KEY_TYPE_RSA_KEY_PAIR 1
#define MBEDTLS_RSA_C
#define MBEDTLS_BIGNUM_C
#define MBEDTLS_OID_C
#define MBEDTLS_GENPRIME
#define MBEDTLS_PK_PARSE_C
#define MBEDTLS_PK_WRITE_C
#define MBEDTLS_PK_C
#endif /* !MBEDTLS_PSA_ACCEL_KEY_TYPE_RSA_KEY_PAIR */
#endif /* PSA_WANT_KEY_TYPE_RSA_KEY_PAIR */
#if defined(PSA_WANT_KEY_TYPE_RSA_PUBLIC_KEY)
#if !defined(MBEDTLS_PSA_ACCEL_KEY_TYPE_RSA_PUBLIC_KEY)
#define MBEDTLS_PSA_BUILTIN_KEY_TYPE_RSA_PUBLIC_KEY 1
#define MBEDTLS_RSA_C
#define MBEDTLS_BIGNUM_C
#define MBEDTLS_OID_C
#define MBEDTLS_PK_PARSE_C
#define MBEDTLS_PK_WRITE_C
#define MBEDTLS_PK_C
#endif /* !MBEDTLS_PSA_ACCEL_KEY_TYPE_RSA_PUBLIC_KEY */
#endif /* PSA_WANT_KEY_TYPE_RSA_PUBLIC_KEY */
#else /* MBEDTLS_PSA_CRYPTO_CONFIG */
/*
* Ensure PSA_WANT_* defines are setup properly if MBEDTLS_PSA_CRYPTO_CONFIG
* is not defined
*/
#if defined(MBEDTLS_ECDH_C)
#define MBEDTLS_PSA_BUILTIN_ALG_ECDH 1
#endif /* MBEDTLS_ECDH_C */
#if defined(MBEDTLS_ECDSA_C)
#define MBEDTLS_PSA_BUILTIN_ALG_ECDSA 1
// Only add in DETERMINISTIC support if ECDSA is also enabled
#if defined(MBEDTLS_ECDSA_DETERMINISTIC)
#define MBEDTLS_PSA_BUILTIN_ALG_DETERMINISTIC_ECDSA 1
#endif /* MBEDTLS_ECDSA_DETERMINISTIC */
#endif /* MBEDTLS_ECDSA_C */
#if defined(MBEDTLS_ECP_C)
#define MBEDTLS_PSA_BUILTIN_KEY_TYPE_ECC_KEY_PAIR 1
#define MBEDTLS_PSA_BUILTIN_KEY_TYPE_ECC_PUBLIC_KEY 1
#endif /* MBEDTLS_ECP_C */
#if defined(MBEDTLS_HKDF_C)
#define MBEDTLS_PSA_BUILTIN_ALG_HMAC 1
#define MBEDTLS_PSA_BUILTIN_ALG_HKDF 1
#endif /* MBEDTLS_HKDF_C */
#if defined(MBEDTLS_MD_C)
#define MBEDTLS_PSA_BUILTIN_ALG_HMAC 1
#define MBEDTLS_PSA_BUILTIN_ALG_TLS12_PRF 1
#define MBEDTLS_PSA_BUILTIN_ALG_TLS12_PSK_TO_MS 1
#endif /* MBEDTLS_MD_C */
#if defined(MBEDTLS_RSA_C)
#if defined(MBEDTLS_PKCS1_V15)
#define MBEDTLS_PSA_BUILTIN_ALG_RSA_PKCS1V15_CRYPT 1
#define MBEDTLS_PSA_BUILTIN_ALG_RSA_PKCS1V15_SIGN 1
#endif /* MBEDTLSS_PKCS1_V15 */
#if defined(MBEDTLS_PKCS1_V21)
#define MBEDTLS_PSA_BUILTIN_ALG_RSA_OAEP 1
#define MBEDTLS_PSA_BUILTIN_ALG_RSA_PSS 1
#endif /* MBEDTLS_PKCS1_V21 */
#define MBEDTLS_PSA_BUILTIN_KEY_TYPE_RSA_KEY_PAIR 1
#define MBEDTLS_PSA_BUILTIN_KEY_TYPE_RSA_PUBLIC_KEY 1
#endif /* MBEDTLS_RSA_C */
#endif /* MBEDTLS_PSA_CRYPTO_CONFIG */
#ifdef __cplusplus
}
#endif
#endif /* MBEDTLS_CONFIG_PSA_H */

4
include/mbedtls/gcm.h
View file

@ -155,7 +155,7 @@ int mbedtls_gcm_setkey( mbedtls_gcm_context *ctx,
* than zero, this must be a writable buffer of at least that
* size in Bytes.
* \param tag_len The length of the tag to generate.
* \param tag The buffer for holding the tag. This must be a readable
* \param tag The buffer for holding the tag. This must be a writable
* buffer of at least \p tag_len Bytes.
*
* \return \c 0 if the encryption or decryption was performed
@ -283,7 +283,7 @@ int mbedtls_gcm_update( mbedtls_gcm_context *ctx,
* tag. The tag can have a maximum length of 16 Bytes.
*
* \param ctx The GCM context. This must be initialized.
* \param tag The buffer for holding the tag. This must be a readable
* \param tag The buffer for holding the tag. This must be a writable
* buffer of at least \p tag_len Bytes.
* \param tag_len The length of the tag to generate. This must be at least
* four.

11
include/mbedtls/pk.h
View file

@ -331,12 +331,13 @@ int mbedtls_pk_setup( mbedtls_pk_context *ctx, const mbedtls_pk_info_t *info );
*
* \return \c 0 on success.
* \return #MBEDTLS_ERR_PK_BAD_INPUT_DATA on invalid input
* (context already used, invalid key handle).
* (context already used, invalid key identifier).
* \return #MBEDTLS_ERR_PK_FEATURE_UNAVAILABLE if the key is not an
* ECC key pair.
* \return #MBEDTLS_ERR_PK_ALLOC_FAILED on allocation failure.
*/
int mbedtls_pk_setup_opaque( mbedtls_pk_context *ctx, const psa_key_handle_t key );
int mbedtls_pk_setup_opaque( mbedtls_pk_context *ctx,
const psa_key_id_t key );
#endif /* MBEDTLS_USE_PSA_CRYPTO */
#if defined(MBEDTLS_PK_RSA_ALT_SUPPORT)
@ -858,9 +859,9 @@ int mbedtls_pk_load_file( const char *path, unsigned char **buf, size_t *n );
*
* \param pk Input: the EC key to import to a PSA key.
* Output: a PK context wrapping that PSA key.
* \param handle Output: a PSA key handle.
* \param key Output: a PSA key identifier.
* It's the caller's responsibility to call
* psa_destroy_key() on that handle after calling
* psa_destroy_key() on that key identifier after calling
* mbedtls_pk_free() on the PK context.
* \param hash_alg The hash algorithm to allow for use with that key.
*
@ -868,7 +869,7 @@ int mbedtls_pk_load_file( const char *path, unsigned char **buf, size_t *n );
* \return An Mbed TLS error code otherwise.
*/
int mbedtls_pk_wrap_as_opaque( mbedtls_pk_context *pk,
psa_key_handle_t *handle,
psa_key_id_t *key,
psa_algorithm_t hash_alg );
#endif /* MBEDTLS_USE_PSA_CRYPTO */

2
include/mbedtls/psa_util.h
View file

@ -83,6 +83,8 @@ static inline psa_algorithm_t mbedtls_psa_translate_cipher_mode(
{
switch( mode )
{
case MBEDTLS_MODE_ECB:
return( PSA_ALG_ECB_NO_PADDING );
case MBEDTLS_MODE_GCM:
return( PSA_ALG_AEAD_WITH_TAG_LENGTH( PSA_ALG_GCM, taglen ) );
case MBEDTLS_MODE_CCM:

4
include/mbedtls/sha512.h
View file

@ -131,8 +131,7 @@ int mbedtls_sha512_update_ret( mbedtls_sha512_context *ctx,
/**
* \brief This function finishes the SHA-512 operation, and writes
* the result to the output buffer. This function is for
* internal use only.
* the result to the output buffer.
*
* \param ctx The SHA-512 context. This must be initialized
* and have a hash operation started.
@ -148,6 +147,7 @@ int mbedtls_sha512_finish_ret( mbedtls_sha512_context *ctx,
/**
* \brief This function processes a single data block within
* the ongoing SHA-512 computation.
* This function is for internal use only.
*
* \param ctx The SHA-512 context. This must be initialized.
* \param data The buffer holding one block of data. This

184
include/mbedtls/ssl.h
View file

@ -42,7 +42,12 @@
#include "mbedtls/dhm.h"
#endif
#if defined(MBEDTLS_ECDH_C)
/* Adding guard for MBEDTLS_ECDSA_C to ensure no compile errors due
* to guards also being in ssl_srv.c and ssl_cli.c. There is a gap
* in functionality that access to ecdh_ctx structure is needed for
* MBEDTLS_ECDSA_C which does not seem correct.
*/
#if defined(MBEDTLS_ECDH_C) || defined(MBEDTLS_ECDSA_C)
#include "mbedtls/ecdh.h"
#endif
@ -214,6 +219,9 @@
#define MBEDTLS_SSL_CERT_REQ_CA_LIST_ENABLED 1
#define MBEDTLS_SSL_CERT_REQ_CA_LIST_DISABLED 0
#define MBEDTLS_SSL_DTLS_SRTP_MKI_UNSUPPORTED 0
#define MBEDTLS_SSL_DTLS_SRTP_MKI_SUPPORTED 1
/*
* Default range for DTLS retransmission timer value, in milliseconds.
* RFC 6347 4.2.4.1 says from 1 second to 60 seconds.
@ -393,6 +401,8 @@
#define MBEDTLS_TLS_EXT_SIG_ALG 13
#define MBEDTLS_TLS_EXT_USE_SRTP 14
#define MBEDTLS_TLS_EXT_ALPN 16
#define MBEDTLS_TLS_EXT_ENCRYPT_THEN_MAC 22 /* 0x16 */
@ -851,6 +861,41 @@ typedef void mbedtls_ssl_async_cancel_t( mbedtls_ssl_context *ssl );
#endif /* MBEDTLS_KEY_EXCHANGE_WITH_CERT_ENABLED &&
!MBEDTLS_SSL_KEEP_PEER_CERTIFICATE */
#if defined(MBEDTLS_SSL_DTLS_SRTP)
#define MBEDTLS_TLS_SRTP_MAX_MKI_LENGTH 255
#define MBEDTLS_TLS_SRTP_MAX_PROFILE_LIST_LENGTH 4
/*
* For code readability use a typedef for DTLS-SRTP profiles
*
* Use_srtp extension protection profiles values as defined in
* http://www.iana.org/assignments/srtp-protection/srtp-protection.xhtml
*
* Reminder: if this list is expanded mbedtls_ssl_check_srtp_profile_value
* must be updated too.
*/
#define MBEDTLS_TLS_SRTP_AES128_CM_HMAC_SHA1_80 ( (uint16_t) 0x0001)
#define MBEDTLS_TLS_SRTP_AES128_CM_HMAC_SHA1_32 ( (uint16_t) 0x0002)
#define MBEDTLS_TLS_SRTP_NULL_HMAC_SHA1_80 ( (uint16_t) 0x0005)
#define MBEDTLS_TLS_SRTP_NULL_HMAC_SHA1_32 ( (uint16_t) 0x0006)
/* This one is not iana defined, but for code readability. */
#define MBEDTLS_TLS_SRTP_UNSET ( (uint16_t) 0x0000)
typedef uint16_t mbedtls_ssl_srtp_profile;
typedef struct mbedtls_dtls_srtp_info_t
{
/*! The SRTP profile that was negotiated. */
mbedtls_ssl_srtp_profile chosen_dtls_srtp_profile;
/*! The length of mki_value. */
uint16_t mki_len;
/*! The mki_value used, with max size of 256 bytes. */
unsigned char mki_value[MBEDTLS_TLS_SRTP_MAX_MKI_LENGTH];
}
mbedtls_dtls_srtp_info;
#endif /* MBEDTLS_SSL_DTLS_SRTP */
/*
* This structure is used for storing current session data.
*
@ -1023,11 +1068,12 @@ struct mbedtls_ssl_config
#if defined(MBEDTLS_KEY_EXCHANGE_SOME_PSK_ENABLED)
#if defined(MBEDTLS_USE_PSA_CRYPTO)
psa_key_handle_t psk_opaque; /*!< PSA key slot holding opaque PSK.
* This field should only be set via
* mbedtls_ssl_conf_psk_opaque().
* If either no PSK or a raw PSK have
* been configured, this has value \c 0. */
psa_key_id_t psk_opaque; /*!< PSA key slot holding opaque PSK. This field
* should only be set via
* mbedtls_ssl_conf_psk_opaque().
* If either no PSK or a raw PSK have been
* configured, this has value \c 0.
*/
#endif /* MBEDTLS_USE_PSA_CRYPTO */
unsigned char *psk; /*!< The raw pre-shared key. This field should
@ -1057,6 +1103,13 @@ struct mbedtls_ssl_config
const char **alpn_list; /*!< ordered list of protocols */
#endif
#if defined(MBEDTLS_SSL_DTLS_SRTP)
/*! ordered list of supported srtp profile */
const mbedtls_ssl_srtp_profile *dtls_srtp_profile_list;
/*! number of supported profiles */
size_t dtls_srtp_profile_list_len;
#endif /* MBEDTLS_SSL_DTLS_SRTP */
/*
* Numerical settings (int then char)
*/
@ -1137,9 +1190,12 @@ struct mbedtls_ssl_config
* record with unexpected CID
* should lead to failure. */
#endif /* MBEDTLS_SSL_DTLS_CONNECTION_ID */
#if defined(MBEDTLS_SSL_DTLS_SRTP)
unsigned int dtls_srtp_mki_support : 1; /* support having mki_value
in the use_srtp extension */
#endif
};
struct mbedtls_ssl_context
{
const mbedtls_ssl_config *conf; /*!< configuration information */
@ -1298,6 +1354,13 @@ struct mbedtls_ssl_context
const char *alpn_chosen; /*!< negotiated protocol */
#endif /* MBEDTLS_SSL_ALPN */
#if defined(MBEDTLS_SSL_DTLS_SRTP)
/*
* use_srtp extension
*/
mbedtls_dtls_srtp_info dtls_srtp_info;
#endif /* MBEDTLS_SSL_DTLS_SRTP */
/*
* Information for DTLS hello verify
*/
@ -1559,7 +1622,7 @@ void mbedtls_ssl_conf_dbg( mbedtls_ssl_config *conf,
* \note For DTLS, you need to provide either a non-NULL
* f_recv_timeout callback, or a f_recv that doesn't block.
*
* \note See the documentations of \c mbedtls_ssl_sent_t,
* \note See the documentations of \c mbedtls_ssl_send_t,
* \c mbedtls_ssl_recv_t and \c mbedtls_ssl_recv_timeout_t for
* the conventions those callbacks must follow.
*
@ -2032,6 +2095,8 @@ void mbedtls_ssl_conf_export_keys_cb( mbedtls_ssl_config *conf,
* (Default: none.)
*
* \note See \c mbedtls_ssl_export_keys_ext_t.
* \warning Exported key material must not be used for any purpose
* before the (D)TLS handshake is completed
*
* \param conf SSL configuration context
* \param f_export_keys_ext Callback for exporting keys
@ -2755,7 +2820,7 @@ int mbedtls_ssl_conf_psk( mbedtls_ssl_config *conf,
* \return An \c MBEDTLS_ERR_SSL_XXX error code on failure.
*/
int mbedtls_ssl_conf_psk_opaque( mbedtls_ssl_config *conf,
psa_key_handle_t psk,
psa_key_id_t psk,
const unsigned char *psk_identity,
size_t psk_identity_len );
#endif /* MBEDTLS_USE_PSA_CRYPTO */
@ -2801,7 +2866,7 @@ int mbedtls_ssl_set_hs_psk( mbedtls_ssl_context *ssl,
* \return An \c MBEDTLS_ERR_SSL_XXX error code on failure.
*/
int mbedtls_ssl_set_hs_psk_opaque( mbedtls_ssl_context *ssl,
psa_key_handle_t psk );
psa_key_id_t psk );
#endif /* MBEDTLS_USE_PSA_CRYPTO */
/**
@ -3120,6 +3185,105 @@ int mbedtls_ssl_conf_alpn_protocols( mbedtls_ssl_config *conf, const char **prot
const char *mbedtls_ssl_get_alpn_protocol( const mbedtls_ssl_context *ssl );
#endif /* MBEDTLS_SSL_ALPN */
#if defined(MBEDTLS_SSL_DTLS_SRTP)
#if defined(MBEDTLS_DEBUG_C)
static inline const char *mbedtls_ssl_get_srtp_profile_as_string( mbedtls_ssl_srtp_profile profile )
{
switch( profile )
{
case MBEDTLS_TLS_SRTP_AES128_CM_HMAC_SHA1_80:
return( "MBEDTLS_TLS_SRTP_AES128_CM_HMAC_SHA1_80" );
case MBEDTLS_TLS_SRTP_AES128_CM_HMAC_SHA1_32:
return( "MBEDTLS_TLS_SRTP_AES128_CM_HMAC_SHA1_32" );
case MBEDTLS_TLS_SRTP_NULL_HMAC_SHA1_80:
return( "MBEDTLS_TLS_SRTP_NULL_HMAC_SHA1_80" );
case MBEDTLS_TLS_SRTP_NULL_HMAC_SHA1_32:
return( "MBEDTLS_TLS_SRTP_NULL_HMAC_SHA1_32" );
default: break;
}
return( "" );
}
#endif /* MBEDTLS_DEBUG_C */
/**
* \brief Manage support for mki(master key id) value
* in use_srtp extension.
* MKI is an optional part of SRTP used for key management
* and re-keying. See RFC3711 section 3.1 for details.
* The default value is
* #MBEDTLS_SSL_DTLS_SRTP_MKI_UNSUPPORTED.
*
* \param conf The SSL configuration to manage mki support.
* \param support_mki_value Enable or disable mki usage. Values are
* #MBEDTLS_SSL_DTLS_SRTP_MKI_UNSUPPORTED
* or #MBEDTLS_SSL_DTLS_SRTP_MKI_SUPPORTED.
*/
void mbedtls_ssl_conf_srtp_mki_value_supported( mbedtls_ssl_config *conf,
int support_mki_value );
/**
* \brief Set the supported DTLS-SRTP protection profiles.
*
* \param conf SSL configuration
* \param profiles Pointer to a List of MBEDTLS_TLS_SRTP_UNSET terminated
* supported protection profiles
* in decreasing preference order.
* The pointer to the list is recorded by the library
* for later reference as required, so the lifetime
* of the table must be at least as long as the lifetime
* of the SSL configuration structure.
* The list must not hold more than
* MBEDTLS_TLS_SRTP_MAX_PROFILE_LIST_LENGTH elements
* (excluding the terminating MBEDTLS_TLS_SRTP_UNSET).
*
* \return 0 on success
* \return #MBEDTLS_ERR_SSL_BAD_INPUT_DATA when the list of
* protection profiles is incorrect.
*/
int mbedtls_ssl_conf_dtls_srtp_protection_profiles
( mbedtls_ssl_config *conf,
const mbedtls_ssl_srtp_profile *profiles );
/**
* \brief Set the mki_value for the current DTLS-SRTP session.
*
* \param ssl SSL context to use.
* \param mki_value The MKI value to set.
* \param mki_len The length of the MKI value.
*
* \note This function is relevant on client side only.
* The server discovers the mki value during handshake.
* A mki value set on server side using this function
* is ignored.
*
* \return 0 on success
* \return #MBEDTLS_ERR_SSL_BAD_INPUT_DATA
* \return #MBEDTLS_ERR_SSL_FEATURE_UNAVAILABLE
*/
int mbedtls_ssl_dtls_srtp_set_mki_value( mbedtls_ssl_context *ssl,
unsigned char *mki_value,
uint16_t mki_len );
/**
* \brief Get the negotiated DTLS-SRTP informations:
* Protection profile and MKI value.
*
* \warning This function must be called after the handshake is
* completed. The value returned by this function must
* not be trusted or acted upon before the handshake completes.
*
* \param ssl The SSL context to query.
* \param dtls_srtp_info The negotiated DTLS-SRTP informations:
* - Protection profile in use.
* A direct mapping of the iana defined value for protection
* profile on an uint16_t.
http://www.iana.org/assignments/srtp-protection/srtp-protection.xhtml
* #MBEDTLS_TLS_SRTP_UNSET if the use of SRTP was not negotiated
* or peer's Hello packet was not parsed yet.
* - mki size and value( if size is > 0 ).
*/
void mbedtls_ssl_get_dtls_srtp_negotiation_result( const mbedtls_ssl_context *ssl,
mbedtls_dtls_srtp_info *dtls_srtp_info );
#endif /* MBEDTLS_SSL_DTLS_SRTP */
/**
* \brief Set the maximum supported version sent from the client side
* and/or accepted at the server side

81
include/mbedtls/ssl_internal.h
View file

@ -378,6 +378,49 @@ typedef int mbedtls_ssl_tls_prf_cb( const unsigned char *secret, size_t slen,
const char *label,
const unsigned char *random, size_t rlen,
unsigned char *dstbuf, size_t dlen );
/* cipher.h exports the maximum IV, key and block length from
* all ciphers enabled in the config, regardless of whether those
* ciphers are actually usable in SSL/TLS. Notably, XTS is enabled
* in the default configuration and uses 64 Byte keys, but it is
* not used for record protection in SSL/TLS.
*
* In order to prevent unnecessary inflation of key structures,
* we introduce SSL-specific variants of the max-{key,block,IV}
* macros here which are meant to only take those ciphers into
* account which can be negotiated in SSL/TLS.
*
* Since the current definitions of MBEDTLS_MAX_{KEY|BLOCK|IV}_LENGTH
* in cipher.h are rough overapproximations of the real maxima, here
* we content ourselves with replicating those overapproximations
* for the maximum block and IV length, and excluding XTS from the
* computation of the maximum key length. */
#define MBEDTLS_SSL_MAX_BLOCK_LENGTH 16
#define MBEDTLS_SSL_MAX_IV_LENGTH 16
#define MBEDTLS_SSL_MAX_KEY_LENGTH 32
/**
* \brief The data structure holding the cryptographic material (key and IV)
* used for record protection in TLS 1.3.
*/
struct mbedtls_ssl_key_set
{
/*! The key for client->server records. */
unsigned char client_write_key[ MBEDTLS_SSL_MAX_KEY_LENGTH ];
/*! The key for server->client records. */
unsigned char server_write_key[ MBEDTLS_SSL_MAX_KEY_LENGTH ];
/*! The IV for client->server records. */
unsigned char client_write_iv[ MBEDTLS_SSL_MAX_IV_LENGTH ];
/*! The IV for server->client records. */
unsigned char server_write_iv[ MBEDTLS_SSL_MAX_IV_LENGTH ];
size_t key_len; /*!< The length of client_write_key and
* server_write_key, in Bytes. */
size_t iv_len; /*!< The length of client_write_iv and
* server_write_iv, in Bytes. */
};
typedef struct mbedtls_ssl_key_set mbedtls_ssl_key_set;
/*
* This structure contains the parameters only needed during handshake.
*/
@ -394,17 +437,22 @@ struct mbedtls_ssl_handshake_params
#if defined(MBEDTLS_DHM_C)
mbedtls_dhm_context dhm_ctx; /*!< DHM key exchange */
#endif
#if defined(MBEDTLS_ECDH_C)
/* Adding guard for MBEDTLS_ECDSA_C to ensure no compile errors due
* to guards also being in ssl_srv.c and ssl_cli.c. There is a gap
* in functionality that access to ecdh_ctx structure is needed for
* MBEDTLS_ECDSA_C which does not seem correct.
*/
#if defined(MBEDTLS_ECDH_C) || defined(MBEDTLS_ECDSA_C)
mbedtls_ecdh_context ecdh_ctx; /*!< ECDH key exchange */
#if defined(MBEDTLS_USE_PSA_CRYPTO)
psa_key_type_t ecdh_psa_type;
uint16_t ecdh_bits;
psa_key_handle_t ecdh_psa_privkey;
psa_key_id_t ecdh_psa_privkey;
unsigned char ecdh_psa_peerkey[MBEDTLS_PSA_MAX_EC_PUBKEY_LENGTH];
size_t ecdh_psa_peerkey_len;
#endif /* MBEDTLS_USE_PSA_CRYPTO */
#endif /* MBEDTLS_ECDH_C */
#endif /* MBEDTLS_ECDH_C || MBEDTLS_ECDSA_C */
#if defined(MBEDTLS_KEY_EXCHANGE_ECJPAKE_ENABLED)
mbedtls_ecjpake_context ecjpake_ctx; /*!< EC J-PAKE key exchange */
@ -419,7 +467,7 @@ struct mbedtls_ssl_handshake_params
#endif
#if defined(MBEDTLS_KEY_EXCHANGE_SOME_PSK_ENABLED)
#if defined(MBEDTLS_USE_PSA_CRYPTO)
psa_key_handle_t psk_opaque; /*!< Opaque PSK from the callback */
psa_key_id_t psk_opaque; /*!< Opaque PSK from the callback */
#endif /* MBEDTLS_USE_PSA_CRYPTO */
unsigned char *psk; /*!< PSK from the callback */
size_t psk_len; /*!< Length of PSK from callback */
@ -1018,16 +1066,16 @@ static inline int mbedtls_ssl_get_psk( const mbedtls_ssl_context *ssl,
* 2. static PSK configured by \c mbedtls_ssl_conf_psk_opaque()
* Return an opaque PSK
*/
static inline psa_key_handle_t mbedtls_ssl_get_opaque_psk(
static inline psa_key_id_t mbedtls_ssl_get_opaque_psk(
const mbedtls_ssl_context *ssl )
{
if( ssl->handshake->psk_opaque != 0 )
if( ! mbedtls_svc_key_id_is_null( ssl->handshake->psk_opaque ) )
return( ssl->handshake->psk_opaque );
if( ssl->conf->psk_opaque != 0 )
if( ! mbedtls_svc_key_id_is_null( ssl->conf->psk_opaque ) )
return( ssl->conf->psk_opaque );
return( 0 );
return( MBEDTLS_SVC_KEY_ID_INIT );
}
#endif /* MBEDTLS_USE_PSA_CRYPTO */
@ -1052,6 +1100,23 @@ int mbedtls_ssl_check_sig_hash( const mbedtls_ssl_context *ssl,
mbedtls_md_type_t md );
#endif
#if defined(MBEDTLS_SSL_DTLS_SRTP)
static inline mbedtls_ssl_srtp_profile mbedtls_ssl_check_srtp_profile_value
( const uint16_t srtp_profile_value )
{
switch( srtp_profile_value )
{
case MBEDTLS_TLS_SRTP_AES128_CM_HMAC_SHA1_80:
case MBEDTLS_TLS_SRTP_AES128_CM_HMAC_SHA1_32:
case MBEDTLS_TLS_SRTP_NULL_HMAC_SHA1_80:
case MBEDTLS_TLS_SRTP_NULL_HMAC_SHA1_32:
return srtp_profile_value;
default: break;
}
return( MBEDTLS_TLS_SRTP_UNSET );
}
#endif
#if defined(MBEDTLS_X509_CRT_PARSE_C)
static inline mbedtls_pk_context *mbedtls_ssl_own_key( mbedtls_ssl_context *ssl )
{

8
include/mbedtls/version.h
View file

@ -37,7 +37,7 @@
* Major, Minor, Patchlevel
*/
#define MBEDTLS_VERSION_MAJOR 2
#define MBEDTLS_VERSION_MINOR 23
#define MBEDTLS_VERSION_MINOR 24
#define MBEDTLS_VERSION_PATCH 0
/**
@ -45,9 +45,9 @@
* MMNNPP00
* Major version | Minor version | Patch version
*/
#define MBEDTLS_VERSION_NUMBER 0x02170000
#define MBEDTLS_VERSION_STRING "2.23.0"
#define MBEDTLS_VERSION_STRING_FULL "mbed TLS 2.23.0"
#define MBEDTLS_VERSION_NUMBER 0x02180000
#define MBEDTLS_VERSION_STRING "2.24.0"
#define MBEDTLS_VERSION_STRING_FULL "mbed TLS 2.24.0"
#if defined(MBEDTLS_VERSION_C)

366
include/psa/crypto.h
View file

@ -36,16 +36,6 @@
* @{
*/
/** \brief Key handle.
*
* This type represents open handles to keys. It must be an unsigned integral
* type. The choice of type is implementation-dependent.
*
* 0 is not a valid key handle. How other handle values are assigned is
* implementation-dependent.
*/
typedef _unsigned_integral_type_ psa_key_handle_t;
/**@}*/
#endif /* __DOXYGEN_ONLY__ */
@ -146,11 +136,30 @@ static psa_key_attributes_t psa_key_attributes_init(void);
* linkage). This function may be provided as a function-like macro,
* but in this case it must evaluate each of its arguments exactly once.
*
* \param[out] attributes The attribute structure to write to.
* \param id The persistent identifier for the key.
* \param[out] attributes The attribute structure to write to.
* \param key The persistent identifier for the key.
*/
static void psa_set_key_id(psa_key_attributes_t *attributes,
psa_key_id_t id);
static void psa_set_key_id( psa_key_attributes_t *attributes,
mbedtls_svc_key_id_t key );
#ifdef MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER
/** Set the owner identifier of a key.
*
* When key identifiers encode key owner identifiers, psa_set_key_id() does
* not allow to define in key attributes the owner of volatile keys as
* psa_set_key_id() enforces the key to be persistent.
*
* This function allows to set in key attributes the owner identifier of a
* key. It is intended to be used for volatile keys. For persistent keys,
* it is recommended to use the PSA Cryptography API psa_set_key_id() to define
* the owner of a key.
*
* \param[out] attributes The attribute structure to write to.
* \param owner_id The key owner identifier.
*/
static void mbedtls_set_key_owner_id( psa_key_attributes_t *attributes,
mbedtls_key_owner_id_t owner_id );
#endif
/** Set the location of a persistent key.
*
@ -192,7 +201,8 @@ static void psa_set_key_lifetime(psa_key_attributes_t *attributes,
* This value is unspecified if the attribute structure declares
* the key as volatile.
*/
static psa_key_id_t psa_get_key_id(const psa_key_attributes_t *attributes);
static mbedtls_svc_key_id_t psa_get_key_id(
const psa_key_attributes_t *attributes);
/** Retrieve the lifetime from key attributes.
*
@ -347,7 +357,7 @@ static size_t psa_get_key_bits(const psa_key_attributes_t *attributes);
* Once you have called this function on an attribute structure,
* you must call psa_reset_key_attributes() to free these resources.
*
* \param[in] handle Handle to the key to query.
* \param[in] key Identifier of the key to query.
* \param[in,out] attributes On success, the attributes of the key.
* On failure, equivalent to a
* freshly-initialized structure.
@ -363,7 +373,7 @@ static size_t psa_get_key_bits(const psa_key_attributes_t *attributes);
* It is implementation-dependent whether a failure to initialize
* results in this error code.
*/
psa_status_t psa_get_key_attributes(psa_key_handle_t handle,
psa_status_t psa_get_key_attributes(mbedtls_svc_key_id_t key,
psa_key_attributes_t *attributes);
/** Reset a key attribute structure to a freshly initialized state.
@ -386,93 +396,28 @@ void psa_reset_key_attributes(psa_key_attributes_t *attributes);
* @{
*/
/** Open a handle to an existing persistent key.
/** Remove non-essential copies of key material from memory.
*
* Open a handle to a persistent key. A key is persistent if it was created
* with a lifetime other than #PSA_KEY_LIFETIME_VOLATILE. A persistent key
* always has a nonzero key identifier, set with psa_set_key_id() when
* creating the key. Implementations may provide additional pre-provisioned
* keys that can be opened with psa_open_key(). Such keys have a key identifier
* in the vendor range, as documented in the description of #psa_key_id_t.
* If the key identifier designates a volatile key, this functions does not do
* anything and returns successfully.
*
* The application must eventually close the handle with psa_close_key() or
* psa_destroy_key() to release associated resources. If the application dies
* without calling one of these functions, the implementation should perform
* the equivalent of a call to psa_close_key().
* If the key identifier designates a persistent key, then this function will
* free all resources associated with the key in volatile memory. The key
* data in persistent storage is not affected and the key can still be used.
*
* Some implementations permit an application to open the same key multiple
* times. If this is successful, each call to psa_open_key() will return a
* different key handle.
*
* \note Applications that rely on opening a key multiple times will not be
* portable to implementations that only permit a single key handle to be
* opened. See also :ref:\`key-handles\`.
*
* \param id The persistent identifier of the key.
* \param[out] handle On success, a handle to the key.
* \param key Identifier of the key to purge.
*
* \retval #PSA_SUCCESS
* Success. The application can now use the value of `*handle`
* to access the key.
* \retval #PSA_ERROR_INSUFFICIENT_MEMORY
* The implementation does not have sufficient resources to open the
* key. This can be due to reaching an implementation limit on the
* number of open keys, the number of open key handles, or available
* memory.
* \retval #PSA_ERROR_DOES_NOT_EXIST
* There is no persistent key with key identifier \p id.
* The key material will have been removed from memory if it is not
* currently required.
* \retval #PSA_ERROR_INVALID_ARGUMENT
* \p id is not a valid persistent key identifier.
* \retval #PSA_ERROR_NOT_PERMITTED
* The specified key exists, but the application does not have the
* permission to access it. Note that this specification does not
* define any way to create such a key, but it may be possible
* through implementation-specific means.
* \retval #PSA_ERROR_COMMUNICATION_FAILURE
* \retval #PSA_ERROR_CORRUPTION_DETECTED
* \retval #PSA_ERROR_STORAGE_FAILURE
* \p key is not a valid key identifier.
* \retval #PSA_ERROR_BAD_STATE
* The library has not been previously initialized by psa_crypto_init().
* It is implementation-dependent whether a failure to initialize
* results in this error code.
*/
psa_status_t psa_open_key(psa_key_id_t id,
psa_key_handle_t *handle);
/** Close a key handle.
*
* If the handle designates a volatile key, this will destroy the key material
* and free all associated resources, just like psa_destroy_key().
*
* If this is the last open handle to a persistent key, then closing the handle
* will free all resources associated with the key in volatile memory. The key
* data in persistent storage is not affected and can be opened again later
* with a call to psa_open_key().
*
* Closing the key handle makes the handle invalid, and the key handle
* must not be used again by the application.
*
* \note If the key handle was used to set up an active
* :ref:\`multipart operation <multipart-operations>\`, then closing the
* key handle can cause the multipart operation to fail. Applications should
* maintain the key handle until after the multipart operation has finished.
*
* \param handle The key handle to close.
* If this is \c 0, do nothing and return \c PSA_SUCCESS.
*
* \retval #PSA_SUCCESS
* \p handle was a valid handle or \c 0. It is now closed.
* \retval #PSA_ERROR_INVALID_HANDLE
* \p handle is not a valid handle nor \c 0.
* \retval #PSA_ERROR_COMMUNICATION_FAILURE
* \retval #PSA_ERROR_CORRUPTION_DETECTED
* \retval #PSA_ERROR_BAD_STATE
* The library has not been previously initialized by psa_crypto_init().
* It is implementation-dependent whether a failure to initialize
* results in this error code.
*/
psa_status_t psa_close_key(psa_key_handle_t handle);
psa_status_t psa_purge_key(mbedtls_svc_key_id_t key);
/** Make a copy of a key.
*
@ -511,7 +456,10 @@ psa_status_t psa_close_key(psa_key_handle_t handle);
* The effect of this function on implementation-defined attributes is
* implementation-defined.
*
* \param source_handle The key to copy. It must be a valid key handle.
* \param source_key The key to copy. It must allow the usage
* #PSA_KEY_USAGE_COPY. If a private or secret key is
* being copied outside of a secure element it must
* also allow #PSA_KEY_USAGE_EXPORT.
* \param[in] attributes The attributes for the new key.
* They are used as follows:
* - The key type and size may be 0. If either is
@ -525,12 +473,14 @@ psa_status_t psa_close_key(psa_key_handle_t handle);
* the source key and \p attributes so that
* both sets of restrictions apply, as
* described in the documentation of this function.
* \param[out] target_handle On success, a handle to the newly created key.
* \param[out] target_key On success, an identifier for the newly created
* key. For persistent keys, this is the key
* identifier defined in \p attributes.
* \c 0 on failure.
*
* \retval #PSA_SUCCESS
* \retval #PSA_ERROR_INVALID_HANDLE
* \p source_handle is invalid.
* \p source_key is invalid.
* \retval #PSA_ERROR_ALREADY_EXISTS
* This is an attempt to create a persistent key, and there is
* already a persistent key with the given identifier.
@ -558,9 +508,9 @@ psa_status_t psa_close_key(psa_key_handle_t handle);
* It is implementation-dependent whether a failure to initialize
* results in this error code.
*/
psa_status_t psa_copy_key(psa_key_handle_t source_handle,
psa_status_t psa_copy_key(mbedtls_svc_key_id_t source_key,
const psa_key_attributes_t *attributes,
psa_key_handle_t *target_handle);
mbedtls_svc_key_id_t *target_key);
/**
@ -571,28 +521,22 @@ psa_status_t psa_copy_key(psa_key_handle_t source_handle,
* make a best effort to ensure that that the key material cannot be recovered.
*
* This function also erases any metadata such as policies and frees
* resources associated with the key. To free all resources associated with
* the key, all handles to the key must be closed or destroyed.
*
* Destroying the key makes the handle invalid, and the key handle
* must not be used again by the application. Using other open handles to the
* destroyed key in a cryptographic operation will result in an error.
* resources associated with the key.
*
* If a key is currently in use in a multipart operation, then destroying the
* key will cause the multipart operation to fail.
*
* \param handle Handle to the key to erase.
* If this is \c 0, do nothing and return \c PSA_SUCCESS.
* \param key Identifier of the key to erase. If this is \c 0, do nothing and
* return #PSA_SUCCESS.
*
* \retval #PSA_SUCCESS
* \p handle was a valid handle and the key material that it
* referred to has been erased.
* Alternatively, \p handle is \c 0.
* \p key was a valid identifier and the key material that it
* referred to has been erased. Alternatively, \p key is \c 0.
* \retval #PSA_ERROR_NOT_PERMITTED
* The key cannot be erased because it is
* read-only, either due to a policy or due to physical restrictions.
* \retval #PSA_ERROR_INVALID_HANDLE
* \p handle is not a valid handle nor \c 0.
* \p key is not a valid identifier nor \c 0.
* \retval #PSA_ERROR_COMMUNICATION_FAILURE
* There was an failure in communication with the cryptoprocessor.
* The key material may still be present in the cryptoprocessor.
@ -610,7 +554,7 @@ psa_status_t psa_copy_key(psa_key_handle_t source_handle,
* It is implementation-dependent whether a failure to initialize
* results in this error code.
*/
psa_status_t psa_destroy_key(psa_key_handle_t handle);
psa_status_t psa_destroy_key(mbedtls_svc_key_id_t key);
/**@}*/
@ -645,7 +589,9 @@ psa_status_t psa_destroy_key(psa_key_handle_t handle);
* \p data buffer.
* If the key size in \p attributes is nonzero,
* it must be equal to the size from \p data.
* \param[out] handle On success, a handle to the newly created key.
* \param[out] key On success, an identifier to the newly created key.
* For persistent keys, this is the key identifier
* defined in \p attributes.
* \c 0 on failure.
* \param[in] data Buffer containing the key data. The content of this
* buffer is interpreted according to the type declared
@ -690,7 +636,7 @@ psa_status_t psa_destroy_key(psa_key_handle_t handle);
psa_status_t psa_import_key(const psa_key_attributes_t *attributes,
const uint8_t *data,
size_t data_length,
psa_key_handle_t *handle);
mbedtls_svc_key_id_t *key);
@ -751,7 +697,9 @@ psa_status_t psa_import_key(const psa_key_attributes_t *attributes,
*
* The policy on the key must have the usage flag #PSA_KEY_USAGE_EXPORT set.
*
* \param handle Handle to the key to export.
* \param key Identifier of the key to export. It must allow the
* usage #PSA_KEY_USAGE_EXPORT, unless it is a public
* key.
* \param[out] data Buffer where the key data is to be written.
* \param data_size Size of the \p data buffer in bytes.
* \param[out] data_length On success, the number of bytes
@ -778,7 +726,7 @@ psa_status_t psa_import_key(const psa_key_attributes_t *attributes,
* It is implementation-dependent whether a failure to initialize
* results in this error code.
*/
psa_status_t psa_export_key(psa_key_handle_t handle,
psa_status_t psa_export_key(mbedtls_svc_key_id_t key,
uint8_t *data,
size_t data_size,
size_t *data_length);
@ -821,7 +769,7 @@ psa_status_t psa_export_key(psa_key_handle_t handle,
* Exporting a public key object or the public part of a key pair is
* always permitted, regardless of the key's usage flags.
*
* \param handle Handle to the key to export.
* \param key Identifier of the key to export.
* \param[out] data Buffer where the key data is to be written.
* \param data_size Size of the \p data buffer in bytes.
* \param[out] data_length On success, the number of bytes
@ -848,7 +796,7 @@ psa_status_t psa_export_key(psa_key_handle_t handle,
* It is implementation-dependent whether a failure to initialize
* results in this error code.
*/
psa_status_t psa_export_public_key(psa_key_handle_t handle,
psa_status_t psa_export_public_key(mbedtls_svc_key_id_t key,
uint8_t *data,
size_t data_size,
size_t *data_length);
@ -1225,7 +1173,8 @@ psa_status_t psa_hash_clone(const psa_hash_operation_t *source_operation,
* about the MAC value which could allow an attacker to guess
* a valid MAC and thereby bypass security controls.
*
* \param handle Handle to the key to use for the operation.
* \param key Identifier of the key to use for the operation. It
* must allow the usage PSA_KEY_USAGE_SIGN_MESSAGE.
* \param alg The MAC algorithm to compute (\c PSA_ALG_XXX value
* such that #PSA_ALG_IS_MAC(\p alg) is true).
* \param[in] input Buffer containing the input message.
@ -1240,7 +1189,7 @@ psa_status_t psa_hash_clone(const psa_hash_operation_t *source_operation,
* \retval #PSA_ERROR_INVALID_HANDLE
* \retval #PSA_ERROR_NOT_PERMITTED
* \retval #PSA_ERROR_INVALID_ARGUMENT
* \p handle is not compatible with \p alg.
* \p key is not compatible with \p alg.
* \retval #PSA_ERROR_NOT_SUPPORTED
* \p alg is not supported or is not a MAC algorithm.
* \retval #PSA_ERROR_BUFFER_TOO_SMALL
@ -1256,7 +1205,7 @@ psa_status_t psa_hash_clone(const psa_hash_operation_t *source_operation,
* It is implementation-dependent whether a failure to initialize
* results in this error code.
*/
psa_status_t psa_mac_compute(psa_key_handle_t handle,
psa_status_t psa_mac_compute(mbedtls_svc_key_id_t key,
psa_algorithm_t alg,
const uint8_t *input,
size_t input_length,
@ -1266,7 +1215,8 @@ psa_status_t psa_mac_compute(psa_key_handle_t handle,
/** Calculate the MAC of a message and compare it with a reference value.
*
* \param handle Handle to the key to use for the operation.
* \param key Identifier of the key to use for the operation. It
* must allow the usage PSA_KEY_USAGE_VERIFY_MESSAGE.
* \param alg The MAC algorithm to compute (\c PSA_ALG_XXX value
* such that #PSA_ALG_IS_MAC(\p alg) is true).
* \param[in] input Buffer containing the input message.
@ -1282,7 +1232,7 @@ psa_status_t psa_mac_compute(psa_key_handle_t handle,
* \retval #PSA_ERROR_INVALID_HANDLE
* \retval #PSA_ERROR_NOT_PERMITTED
* \retval #PSA_ERROR_INVALID_ARGUMENT
* \p handle is not compatible with \p alg.
* \p key is not compatible with \p alg.
* \retval #PSA_ERROR_NOT_SUPPORTED
* \p alg is not supported or is not a MAC algorithm.
* \retval #PSA_ERROR_INSUFFICIENT_MEMORY
@ -1296,7 +1246,7 @@ psa_status_t psa_mac_compute(psa_key_handle_t handle,
* It is implementation-dependent whether a failure to initialize
* results in this error code.
*/
psa_status_t psa_mac_verify(psa_key_handle_t handle,
psa_status_t psa_mac_verify(mbedtls_svc_key_id_t key,
psa_algorithm_t alg,
const uint8_t *input,
size_t input_length,
@ -1381,9 +1331,9 @@ static psa_mac_operation_t psa_mac_operation_init(void);
* \param[in,out] operation The operation object to set up. It must have
* been initialized as per the documentation for
* #psa_mac_operation_t and not yet in use.
* \param handle Handle to the key to use for the operation.
* It must remain valid until the operation
* terminates.
* \param key Identifier of the key to use for the operation. It
* must remain valid until the operation terminates.
* It must allow the usage PSA_KEY_USAGE_SIGN_MESSAGE.
* \param alg The MAC algorithm to compute (\c PSA_ALG_XXX value
* such that #PSA_ALG_IS_MAC(\p alg) is true).
*
@ -1392,7 +1342,7 @@ static psa_mac_operation_t psa_mac_operation_init(void);
* \retval #PSA_ERROR_INVALID_HANDLE
* \retval #PSA_ERROR_NOT_PERMITTED
* \retval #PSA_ERROR_INVALID_ARGUMENT
* \p handle is not compatible with \p alg.
* \p key is not compatible with \p alg.
* \retval #PSA_ERROR_NOT_SUPPORTED
* \p alg is not supported or is not a MAC algorithm.
* \retval #PSA_ERROR_INSUFFICIENT_MEMORY
@ -1409,7 +1359,7 @@ static psa_mac_operation_t psa_mac_operation_init(void);
* results in this error code.
*/
psa_status_t psa_mac_sign_setup(psa_mac_operation_t *operation,
psa_key_handle_t handle,
mbedtls_svc_key_id_t key,
psa_algorithm_t alg);
/** Set up a multipart MAC verification operation.
@ -1443,9 +1393,10 @@ psa_status_t psa_mac_sign_setup(psa_mac_operation_t *operation,
* \param[in,out] operation The operation object to set up. It must have
* been initialized as per the documentation for
* #psa_mac_operation_t and not yet in use.
* \param handle Handle to the key to use for the operation.
* It must remain valid until the operation
* terminates.
* \param key Identifier of the key to use for the operation. It
* must remain valid until the operation terminates.
* It must allow the usage
* PSA_KEY_USAGE_VERIFY_MESSAGE.
* \param alg The MAC algorithm to compute (\c PSA_ALG_XXX value
* such that #PSA_ALG_IS_MAC(\p alg) is true).
*
@ -1471,7 +1422,7 @@ psa_status_t psa_mac_sign_setup(psa_mac_operation_t *operation,
* results in this error code.
*/
psa_status_t psa_mac_verify_setup(psa_mac_operation_t *operation,
psa_key_handle_t handle,
mbedtls_svc_key_id_t key,
psa_algorithm_t alg);
/** Add a message fragment to a multipart MAC operation.
@ -1638,9 +1589,8 @@ psa_status_t psa_mac_abort(psa_mac_operation_t *operation);
* vector). Use the multipart operation interface with a
* #psa_cipher_operation_t object to provide other forms of IV.
*
* \param handle Handle to the key to use for the operation.
* It must remain valid until the operation
* terminates.
* \param key Identifier of the key to use for the operation.
* It must allow the usage #PSA_KEY_USAGE_ENCRYPT.
* \param alg The cipher algorithm to compute
* (\c PSA_ALG_XXX value such that
* #PSA_ALG_IS_CIPHER(\p alg) is true).
@ -1658,7 +1608,7 @@ psa_status_t psa_mac_abort(psa_mac_operation_t *operation);
* \retval #PSA_ERROR_INVALID_HANDLE
* \retval #PSA_ERROR_NOT_PERMITTED
* \retval #PSA_ERROR_INVALID_ARGUMENT
* \p handle is not compatible with \p alg.
* \p key is not compatible with \p alg.
* \retval #PSA_ERROR_NOT_SUPPORTED
* \p alg is not supported or is not a cipher algorithm.
* \retval #PSA_ERROR_BUFFER_TOO_SMALL
@ -1672,7 +1622,7 @@ psa_status_t psa_mac_abort(psa_mac_operation_t *operation);
* It is implementation-dependent whether a failure to initialize
* results in this error code.
*/
psa_status_t psa_cipher_encrypt(psa_key_handle_t handle,
psa_status_t psa_cipher_encrypt(mbedtls_svc_key_id_t key,
psa_algorithm_t alg,
const uint8_t *input,
size_t input_length,
@ -1684,9 +1634,10 @@ psa_status_t psa_cipher_encrypt(psa_key_handle_t handle,
*
* This function decrypts a message encrypted with a symmetric cipher.
*
* \param handle Handle to the key to use for the operation.
* \param key Identifier of the key to use for the operation.
* It must remain valid until the operation
* terminates.
* terminates. It must allow the usage
* #PSA_KEY_USAGE_DECRYPT.
* \param alg The cipher algorithm to compute
* (\c PSA_ALG_XXX value such that
* #PSA_ALG_IS_CIPHER(\p alg) is true).
@ -1704,7 +1655,7 @@ psa_status_t psa_cipher_encrypt(psa_key_handle_t handle,
* \retval #PSA_ERROR_INVALID_HANDLE
* \retval #PSA_ERROR_NOT_PERMITTED
* \retval #PSA_ERROR_INVALID_ARGUMENT
* \p handle is not compatible with \p alg.
* \p key is not compatible with \p alg.
* \retval #PSA_ERROR_NOT_SUPPORTED
* \p alg is not supported or is not a cipher algorithm.
* \retval #PSA_ERROR_BUFFER_TOO_SMALL
@ -1718,7 +1669,7 @@ psa_status_t psa_cipher_encrypt(psa_key_handle_t handle,
* It is implementation-dependent whether a failure to initialize
* results in this error code.
*/
psa_status_t psa_cipher_decrypt(psa_key_handle_t handle,
psa_status_t psa_cipher_decrypt(mbedtls_svc_key_id_t key,
psa_algorithm_t alg,
const uint8_t *input,
size_t input_length,
@ -1804,9 +1755,10 @@ static psa_cipher_operation_t psa_cipher_operation_init(void);
* \param[in,out] operation The operation object to set up. It must have
* been initialized as per the documentation for
* #psa_cipher_operation_t and not yet in use.
* \param handle Handle to the key to use for the operation.
* \param key Identifier of the key to use for the operation.
* It must remain valid until the operation
* terminates.
* terminates. It must allow the usage
* #PSA_KEY_USAGE_ENCRYPT.
* \param alg The cipher algorithm to compute
* (\c PSA_ALG_XXX value such that
* #PSA_ALG_IS_CIPHER(\p alg) is true).
@ -1816,7 +1768,7 @@ static psa_cipher_operation_t psa_cipher_operation_init(void);
* \retval #PSA_ERROR_INVALID_HANDLE
* \retval #PSA_ERROR_NOT_PERMITTED
* \retval #PSA_ERROR_INVALID_ARGUMENT
* \p handle is not compatible with \p alg.
* \p key is not compatible with \p alg.
* \retval #PSA_ERROR_NOT_SUPPORTED
* \p alg is not supported or is not a cipher algorithm.
* \retval #PSA_ERROR_INSUFFICIENT_MEMORY
@ -1832,7 +1784,7 @@ static psa_cipher_operation_t psa_cipher_operation_init(void);
* results in this error code.
*/
psa_status_t psa_cipher_encrypt_setup(psa_cipher_operation_t *operation,
psa_key_handle_t handle,
mbedtls_svc_key_id_t key,
psa_algorithm_t alg);
/** Set the key for a multipart symmetric decryption operation.
@ -1867,9 +1819,10 @@ psa_status_t psa_cipher_encrypt_setup(psa_cipher_operation_t *operation,
* \param[in,out] operation The operation object to set up. It must have
* been initialized as per the documentation for
* #psa_cipher_operation_t and not yet in use.
* \param handle Handle to the key to use for the operation.
* \param key Identifier of the key to use for the operation.
* It must remain valid until the operation
* terminates.
* terminates. It must allow the usage
* #PSA_KEY_USAGE_DECRYPT.
* \param alg The cipher algorithm to compute
* (\c PSA_ALG_XXX value such that
* #PSA_ALG_IS_CIPHER(\p alg) is true).
@ -1879,7 +1832,7 @@ psa_status_t psa_cipher_encrypt_setup(psa_cipher_operation_t *operation,
* \retval #PSA_ERROR_INVALID_HANDLE
* \retval #PSA_ERROR_NOT_PERMITTED
* \retval #PSA_ERROR_INVALID_ARGUMENT
* \p handle is not compatible with \p alg.
* \p key is not compatible with \p alg.
* \retval #PSA_ERROR_NOT_SUPPORTED
* \p alg is not supported or is not a cipher algorithm.
* \retval #PSA_ERROR_INSUFFICIENT_MEMORY
@ -1895,7 +1848,7 @@ psa_status_t psa_cipher_encrypt_setup(psa_cipher_operation_t *operation,
* results in this error code.
*/
psa_status_t psa_cipher_decrypt_setup(psa_cipher_operation_t *operation,
psa_key_handle_t handle,
mbedtls_svc_key_id_t key,
psa_algorithm_t alg);
/** Generate an IV for a symmetric encryption operation.
@ -2109,7 +2062,9 @@ psa_status_t psa_cipher_abort(psa_cipher_operation_t *operation);
/** Process an authenticated encryption operation.
*
* \param handle Handle to the key to use for the operation.
* \param key Identifier of the key to use for the
* operation. It must allow the usage
* #PSA_KEY_USAGE_ENCRYPT.
* \param alg The AEAD algorithm to compute
* (\c PSA_ALG_XXX value such that
* #PSA_ALG_IS_AEAD(\p alg) is true).
@ -2140,7 +2095,7 @@ psa_status_t psa_cipher_abort(psa_cipher_operation_t *operation);
* \retval #PSA_ERROR_INVALID_HANDLE
* \retval #PSA_ERROR_NOT_PERMITTED
* \retval #PSA_ERROR_INVALID_ARGUMENT
* \p handle is not compatible with \p alg.
* \p key is not compatible with \p alg.
* \retval #PSA_ERROR_NOT_SUPPORTED
* \p alg is not supported or is not an AEAD algorithm.
* \retval #PSA_ERROR_INSUFFICIENT_MEMORY
@ -2155,7 +2110,7 @@ psa_status_t psa_cipher_abort(psa_cipher_operation_t *operation);
* It is implementation-dependent whether a failure to initialize
* results in this error code.
*/
psa_status_t psa_aead_encrypt(psa_key_handle_t handle,
psa_status_t psa_aead_encrypt(mbedtls_svc_key_id_t key,
psa_algorithm_t alg,
const uint8_t *nonce,
size_t nonce_length,
@ -2169,7 +2124,9 @@ psa_status_t psa_aead_encrypt(psa_key_handle_t handle,
/** Process an authenticated decryption operation.
*
* \param handle Handle to the key to use for the operation.
* \param key Identifier of the key to use for the
* operation. It must allow the usage
* #PSA_KEY_USAGE_DECRYPT.
* \param alg The AEAD algorithm to compute
* (\c PSA_ALG_XXX value such that
* #PSA_ALG_IS_AEAD(\p alg) is true).
@ -2200,7 +2157,7 @@ psa_status_t psa_aead_encrypt(psa_key_handle_t handle,
* The ciphertext is not authentic.
* \retval #PSA_ERROR_NOT_PERMITTED
* \retval #PSA_ERROR_INVALID_ARGUMENT
* \p handle is not compatible with \p alg.
* \p key is not compatible with \p alg.
* \retval #PSA_ERROR_NOT_SUPPORTED
* \p alg is not supported or is not an AEAD algorithm.
* \retval #PSA_ERROR_INSUFFICIENT_MEMORY
@ -2215,7 +2172,7 @@ psa_status_t psa_aead_encrypt(psa_key_handle_t handle,
* It is implementation-dependent whether a failure to initialize
* results in this error code.
*/
psa_status_t psa_aead_decrypt(psa_key_handle_t handle,
psa_status_t psa_aead_decrypt(mbedtls_svc_key_id_t key,
psa_algorithm_t alg,
const uint8_t *nonce,
size_t nonce_length,
@ -2311,9 +2268,10 @@ static psa_aead_operation_t psa_aead_operation_init(void);
* \param[in,out] operation The operation object to set up. It must have
* been initialized as per the documentation for
* #psa_aead_operation_t and not yet in use.
* \param handle Handle to the key to use for the operation.
* \param key Identifier of the key to use for the operation.
* It must remain valid until the operation
* terminates.
* terminates. It must allow the usage
* #PSA_KEY_USAGE_ENCRYPT.
* \param alg The AEAD algorithm to compute
* (\c PSA_ALG_XXX value such that
* #PSA_ALG_IS_AEAD(\p alg) is true).
@ -2322,10 +2280,10 @@ static psa_aead_operation_t psa_aead_operation_init(void);
* Success.
* \retval #PSA_ERROR_BAD_STATE
* The operation state is not valid (it must be inactive).
* \retval #PSA_ERROR_INVALID_HANDLE
* \retval #PSA_ERROR_INVALID_HANDLE
* \retval #PSA_ERROR_NOT_PERMITTED
* \retval #PSA_ERROR_INVALID_ARGUMENT
* \p handle is not compatible with \p alg.
* \p key is not compatible with \p alg.
* \retval #PSA_ERROR_NOT_SUPPORTED
* \p alg is not supported or is not an AEAD algorithm.
* \retval #PSA_ERROR_INSUFFICIENT_MEMORY
@ -2339,7 +2297,7 @@ static psa_aead_operation_t psa_aead_operation_init(void);
* results in this error code.
*/
psa_status_t psa_aead_encrypt_setup(psa_aead_operation_t *operation,
psa_key_handle_t handle,
mbedtls_svc_key_id_t key,
psa_algorithm_t alg);
/** Set the key for a multipart authenticated decryption operation.
@ -2377,9 +2335,10 @@ psa_status_t psa_aead_encrypt_setup(psa_aead_operation_t *operation,
* \param[in,out] operation The operation object to set up. It must have
* been initialized as per the documentation for
* #psa_aead_operation_t and not yet in use.
* \param handle Handle to the key to use for the operation.
* \param key Identifier of the key to use for the operation.
* It must remain valid until the operation
* terminates.
* terminates. It must allow the usage
* #PSA_KEY_USAGE_DECRYPT.
* \param alg The AEAD algorithm to compute
* (\c PSA_ALG_XXX value such that
* #PSA_ALG_IS_AEAD(\p alg) is true).
@ -2388,10 +2347,10 @@ psa_status_t psa_aead_encrypt_setup(psa_aead_operation_t *operation,
* Success.
* \retval #PSA_ERROR_BAD_STATE
* The operation state is not valid (it must be inactive).
* \retval #PSA_ERROR_INVALID_HANDLE
* \retval #PSA_ERROR_INVALID_HANDLE
* \retval #PSA_ERROR_NOT_PERMITTED
* \retval #PSA_ERROR_INVALID_ARGUMENT
* \p handle is not compatible with \p alg.
* \p key is not compatible with \p alg.
* \retval #PSA_ERROR_NOT_SUPPORTED
* \p alg is not supported or is not an AEAD algorithm.
* \retval #PSA_ERROR_INSUFFICIENT_MEMORY
@ -2405,7 +2364,7 @@ psa_status_t psa_aead_encrypt_setup(psa_aead_operation_t *operation,
* results in this error code.
*/
psa_status_t psa_aead_decrypt_setup(psa_aead_operation_t *operation,
psa_key_handle_t handle,
mbedtls_svc_key_id_t key,
psa_algorithm_t alg);
/** Generate a random nonce for an authenticated encryption operation.
@ -2431,7 +2390,7 @@ psa_status_t psa_aead_decrypt_setup(psa_aead_operation_t *operation,
* Success.
* \retval #PSA_ERROR_BAD_STATE
* The operation state is not valid (it must be an active aead encrypt
operation, with no nonce set).
* operation, with no nonce set).
* \retval #PSA_ERROR_BUFFER_TOO_SMALL
* The size of the \p nonce buffer is too small.
* \retval #PSA_ERROR_INSUFFICIENT_MEMORY
@ -2863,10 +2822,11 @@ psa_status_t psa_aead_abort(psa_aead_operation_t *operation);
* parameter to this function. You can use #PSA_ALG_SIGN_GET_HASH(\p alg)
* to determine the hash algorithm to use.
*
* \param handle Handle to the key to use for the operation.
* It must be an asymmetric key pair.
* \param key Identifier of the key to use for the operation.
* It must be an asymmetric key pair. The key must
* allow the usage #PSA_KEY_USAGE_SIGN_HASH.
* \param alg A signature algorithm that is compatible with
* the type of \p handle.
* the type of \p key.
* \param[in] hash The hash or message to sign.
* \param hash_length Size of the \p hash buffer in bytes.
* \param[out] signature Buffer where the signature is to be written.
@ -2882,7 +2842,7 @@ psa_status_t psa_aead_abort(psa_aead_operation_t *operation);
* determine a sufficient buffer size by calling
* #PSA_SIGN_OUTPUT_SIZE(\c key_type, \c key_bits, \p alg)
* where \c key_type and \c key_bits are the type and bit-size
* respectively of \p handle.
* respectively of \p key.
* \retval #PSA_ERROR_NOT_SUPPORTED
* \retval #PSA_ERROR_INVALID_ARGUMENT
* \retval #PSA_ERROR_INSUFFICIENT_MEMORY
@ -2896,7 +2856,7 @@ psa_status_t psa_aead_abort(psa_aead_operation_t *operation);
* It is implementation-dependent whether a failure to initialize
* results in this error code.
*/
psa_status_t psa_sign_hash(psa_key_handle_t handle,
psa_status_t psa_sign_hash(mbedtls_svc_key_id_t key,
psa_algorithm_t alg,
const uint8_t *hash,
size_t hash_length,
@ -2913,10 +2873,12 @@ psa_status_t psa_sign_hash(psa_key_handle_t handle,
* parameter to this function. You can use #PSA_ALG_SIGN_GET_HASH(\p alg)
* to determine the hash algorithm to use.
*
* \param handle Handle to the key to use for the operation.
* It must be a public key or an asymmetric key pair.
* \param key Identifier of the key to use for the operation. It
* must be a public key or an asymmetric key pair. The
* key must allow the usage
* #PSA_KEY_USAGE_VERIFY_HASH.
* \param alg A signature algorithm that is compatible with
* the type of \p handle.
* the type of \p key.
* \param[in] hash The hash or message whose signature is to be
* verified.
* \param hash_length Size of the \p hash buffer in bytes.
@ -2942,7 +2904,7 @@ psa_status_t psa_sign_hash(psa_key_handle_t handle,
* It is implementation-dependent whether a failure to initialize
* results in this error code.
*/
psa_status_t psa_verify_hash(psa_key_handle_t handle,
psa_status_t psa_verify_hash(mbedtls_svc_key_id_t key,
psa_algorithm_t alg,
const uint8_t *hash,
size_t hash_length,
@ -2952,11 +2914,12 @@ psa_status_t psa_verify_hash(psa_key_handle_t handle,
/**
* \brief Encrypt a short message with a public key.
*
* \param handle Handle to the key to use for the operation.
* It must be a public key or an asymmetric
* key pair.
* \param key Identifer of the key to use for the operation.
* It must be a public key or an asymmetric key
* pair. It must allow the usage
* #PSA_KEY_USAGE_ENCRYPT.
* \param alg An asymmetric encryption algorithm that is
* compatible with the type of \p handle.
* compatible with the type of \p key.
* \param[in] input The message to encrypt.
* \param input_length Size of the \p input buffer in bytes.
* \param[in] salt A salt or label, if supported by the
@ -2985,7 +2948,7 @@ psa_status_t psa_verify_hash(psa_key_handle_t handle,
* determine a sufficient buffer size by calling
* #PSA_ASYMMETRIC_ENCRYPT_OUTPUT_SIZE(\c key_type, \c key_bits, \p alg)
* where \c key_type and \c key_bits are the type and bit-size
* respectively of \p handle.
* respectively of \p key.
* \retval #PSA_ERROR_NOT_SUPPORTED
* \retval #PSA_ERROR_INVALID_ARGUMENT
* \retval #PSA_ERROR_INSUFFICIENT_MEMORY
@ -2999,7 +2962,7 @@ psa_status_t psa_verify_hash(psa_key_handle_t handle,
* It is implementation-dependent whether a failure to initialize
* results in this error code.
*/
psa_status_t psa_asymmetric_encrypt(psa_key_handle_t handle,
psa_status_t psa_asymmetric_encrypt(mbedtls_svc_key_id_t key,
psa_algorithm_t alg,
const uint8_t *input,
size_t input_length,
@ -3012,10 +2975,11 @@ psa_status_t psa_asymmetric_encrypt(psa_key_handle_t handle,
/**
* \brief Decrypt a short message with a private key.
*
* \param handle Handle to the key to use for the operation.
* It must be an asymmetric key pair.
* \param key Identifier of the key to use for the operation.
* It must be an asymmetric key pair. It must
* allow the usage #PSA_KEY_USAGE_DECRYPT.
* \param alg An asymmetric encryption algorithm that is
* compatible with the type of \p handle.
* compatible with the type of \p key.
* \param[in] input The message to decrypt.
* \param input_length Size of the \p input buffer in bytes.
* \param[in] salt A salt or label, if supported by the
@ -3044,7 +3008,7 @@ psa_status_t psa_asymmetric_encrypt(psa_key_handle_t handle,
* determine a sufficient buffer size by calling
* #PSA_ASYMMETRIC_DECRYPT_OUTPUT_SIZE(\c key_type, \c key_bits, \p alg)
* where \c key_type and \c key_bits are the type and bit-size
* respectively of \p handle.
* respectively of \p key.
* \retval #PSA_ERROR_NOT_SUPPORTED
* \retval #PSA_ERROR_INVALID_ARGUMENT
* \retval #PSA_ERROR_INSUFFICIENT_MEMORY
@ -3059,7 +3023,7 @@ psa_status_t psa_asymmetric_encrypt(psa_key_handle_t handle,
* It is implementation-dependent whether a failure to initialize
* results in this error code.
*/
psa_status_t psa_asymmetric_decrypt(psa_key_handle_t handle,
psa_status_t psa_asymmetric_decrypt(mbedtls_svc_key_id_t key,
psa_algorithm_t alg,
const uint8_t *input,
size_t input_length,
@ -3317,9 +3281,9 @@ psa_status_t psa_key_derivation_input_bytes(
* psa_key_derivation_setup() and must not
* have produced any output yet.
* \param step Which step the input data is for.
* \param handle Handle to the key. It must have an
* appropriate type for \p step and must
* allow the usage #PSA_KEY_USAGE_DERIVE.
* \param key Identifier of the key. It must have an
* appropriate type for step and must allow the
* usage #PSA_KEY_USAGE_DERIVE.
*
* \retval #PSA_SUCCESS
* Success.
@ -3345,7 +3309,7 @@ psa_status_t psa_key_derivation_input_bytes(
psa_status_t psa_key_derivation_input_key(
psa_key_derivation_operation_t *operation,
psa_key_derivation_step_t step,
psa_key_handle_t handle);
mbedtls_svc_key_id_t key);
/** Perform a key agreement and use the shared secret as input to a key
* derivation.
@ -3370,7 +3334,8 @@ psa_status_t psa_key_derivation_input_key(
* The operation must be ready for an
* input of the type given by \p step.
* \param step Which step the input data is for.
* \param private_key Handle to the private key to use.
* \param private_key Identifier of the private key to use. It must
* allow the usage #PSA_KEY_USAGE_DERIVE.
* \param[in] peer_key Public key of the peer. The peer key must be in the
* same format that psa_import_key() accepts for the
* public key type corresponding to the type of
@ -3414,7 +3379,7 @@ psa_status_t psa_key_derivation_input_key(
psa_status_t psa_key_derivation_key_agreement(
psa_key_derivation_operation_t *operation,
psa_key_derivation_step_t step,
psa_key_handle_t private_key,
mbedtls_svc_key_id_t private_key,
const uint8_t *peer_key,
size_t peer_key_length);
@ -3558,7 +3523,9 @@ psa_status_t psa_key_derivation_output_bytes(
*
* \param[in] attributes The attributes for the new key.
* \param[in,out] operation The key derivation operation object to read from.
* \param[out] handle On success, a handle to the newly created key.
* \param[out] key On success, an identifier for the newly created
* key. For persistent keys, this is the key
* identifier defined in \p attributes.
* \c 0 on failure.
*
* \retval #PSA_SUCCESS
@ -3598,7 +3565,7 @@ psa_status_t psa_key_derivation_output_bytes(
psa_status_t psa_key_derivation_output_key(
const psa_key_attributes_t *attributes,
psa_key_derivation_operation_t *operation,
psa_key_handle_t *handle);
mbedtls_svc_key_id_t *key);
/** Abort a key derivation operation.
*
@ -3639,7 +3606,8 @@ psa_status_t psa_key_derivation_abort(
* (\c PSA_ALG_XXX value such that
* #PSA_ALG_IS_RAW_KEY_AGREEMENT(\p alg)
* is true).
* \param private_key Handle to the private key to use.
* \param private_key Identifier of the private key to use. It must
* allow the usage #PSA_KEY_USAGE_DERIVE.
* \param[in] peer_key Public key of the peer. It must be
* in the same format that psa_import_key()
* accepts. The standard formats for public
@ -3677,7 +3645,7 @@ psa_status_t psa_key_derivation_abort(
* results in this error code.
*/
psa_status_t psa_raw_key_agreement(psa_algorithm_t alg,
psa_key_handle_t private_key,
mbedtls_svc_key_id_t private_key,
const uint8_t *peer_key,
size_t peer_key_length,
uint8_t *output,
@ -3733,7 +3701,9 @@ psa_status_t psa_generate_random(uint8_t *output,
* attributes.
*
* \param[in] attributes The attributes for the new key.
* \param[out] handle On success, a handle to the newly created key.
* \param[out] key On success, an identifier for the newly created
* key. For persistent keys, this is the key
* identifier defined in \p attributes.
* \c 0 on failure.
*
* \retval #PSA_SUCCESS
@ -3758,7 +3728,7 @@ psa_status_t psa_generate_random(uint8_t *output,
* results in this error code.
*/
psa_status_t psa_generate_key(const psa_key_attributes_t *attributes,
psa_key_handle_t *handle);
mbedtls_svc_key_id_t *key);
/**@}*/

30
include/psa/crypto_accel_driver.h
View file

@ -75,7 +75,7 @@ typedef struct psa_drv_hash_context_s psa_drv_hash_context_t;
* \param[in,out] p_context A structure that will contain the
* hardware-specific hash context
*
* \retval PSA_SUCCESS Success.
* \retval #PSA_SUCCESS Success.
*/
typedef psa_status_t (*psa_drv_hash_setup_t)(psa_drv_hash_context_t *p_context);
@ -120,7 +120,7 @@ typedef psa_status_t (*psa_drv_hash_update_t)(psa_drv_hash_context_t *p_context,
* \param[out] p_output_length The number of bytes placed in `p_output` after
* success
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
* Success.
*/
typedef psa_status_t (*psa_drv_hash_finish_t)(psa_drv_hash_context_t *p_context,
@ -188,7 +188,7 @@ typedef struct psa_drv_accel_mac_context_s psa_drv_accel_mac_context_t;
* to be used in the operation
* \param[in] key_length The size in bytes of the key material
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
* Success.
*/
typedef psa_status_t (*psa_drv_accel_mac_setup_t)(psa_drv_accel_mac_context_t *p_context,
@ -235,7 +235,7 @@ typedef psa_status_t (*psa_drv_accel_mac_update_t)(psa_drv_accel_mac_context_t *
* \param[in] mac_length The size in bytes of the buffer that has been
* allocated for the `p_mac` buffer
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
* Success.
*/
typedef psa_status_t (*psa_drv_accel_mac_finish_t)(psa_drv_accel_mac_context_t *p_context,
@ -261,7 +261,7 @@ typedef psa_status_t (*psa_drv_accel_mac_finish_t)(psa_drv_accel_mac_context_t *
* \param[in] mac_length The size in bytes of the data in the `p_mac`
* buffer
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
* The operation completed successfully and the comparison matched
*/
typedef psa_status_t (*psa_drv_accel_mac_finish_verify_t)(psa_drv_accel_mac_context_t *p_context,
@ -335,7 +335,7 @@ typedef psa_status_t (*psa_drv_accel_mac_t)(const uint8_t *p_input,
* \param[in] p_mac The MAC data to be compared
* \param[in] mac_length The length in bytes of the `p_mac` buffer
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
* The operation completed successfully and the comparison matched
*/
typedef psa_status_t (*psa_drv_accel_mac_verify_t)(const uint8_t *p_input,
@ -396,7 +396,7 @@ typedef struct psa_drv_accel_cipher_context_s psa_drv_accel_cipher_context_t;
* to be used in the operation
* \param[in] key_data_size The size in bytes of the key material
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
*/
typedef psa_status_t (*psa_drv_accel_cipher_setup_t)(psa_drv_accel_cipher_context_t *p_context,
psa_encrypt_or_decrypt_t direction,
@ -419,7 +419,7 @@ typedef psa_status_t (*psa_drv_accel_cipher_setup_t)(psa_drv_accel_cipher_contex
* \param[in] p_iv A buffer containing the initialization vecotr
* \param[in] iv_length The size in bytes of the contents of `p_iv`
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
*/
typedef psa_status_t (*psa_drv_accel_cipher_set_iv_t)(psa_drv_accel_cipher_context_t *p_context,
const uint8_t *p_iv,
@ -448,7 +448,7 @@ typedef psa_status_t (*psa_drv_accel_cipher_set_iv_t)(psa_drv_accel_cipher_conte
* \param[out] p_output_length After completion, will contain the number
* of bytes placed in the `p_output` buffer
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
*/
typedef psa_status_t (*psa_drv_accel_cipher_update_t)(psa_drv_accel_cipher_context_t *p_context,
const uint8_t *p_input,
@ -477,7 +477,7 @@ typedef psa_status_t (*psa_drv_accel_cipher_update_t)(psa_drv_accel_cipher_conte
* \param[out] p_output_length After completion, will contain the number of
* bytes placed in the `p_output` buffer
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
*/
typedef psa_status_t (*psa_drv_accel_cipher_finish_t)(psa_drv_accel_cipher_context_t *p_context,
uint8_t *p_output,
@ -499,7 +499,7 @@ typedef psa_status_t (*psa_drv_accel_cipher_finish_t)(psa_drv_accel_cipher_conte
* \param[in,out] p_context A hardware-specific structure for the
* previously started cipher operation
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
*/
typedef psa_status_t (*psa_drv_accel_cipher_abort_t)(psa_drv_accel_cipher_context_t *p_context);
@ -659,7 +659,7 @@ typedef psa_status_t (*psa_drv_accel_aead_decrypt_t)(const uint8_t *p_key,
* \param[out] p_signature_length On success, the number of bytes
* that make up the returned signature value
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
*/
typedef psa_status_t (*psa_drv_accel_asymmetric_sign_t)(const uint8_t *p_key,
size_t key_size,
@ -697,7 +697,7 @@ typedef psa_status_t (*psa_drv_accel_asymmetric_sign_t)(const uint8_t *p_key,
* \param[in] p_signature Buffer containing the signature to verify
* \param[in] signature_length Size of the `p_signature` buffer in bytes
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
* The signature is valid.
*/
typedef psa_status_t (*psa_drv_accel_asymmetric_verify_t)(const uint8_t *p_key,
@ -748,7 +748,7 @@ typedef psa_status_t (*psa_drv_accel_asymmetric_verify_t)(const uint8_t *p_key,
* \param[out] p_output_length On success, the number of bytes
* that make up the returned output
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
*/
typedef psa_status_t (*psa_drv_accel_asymmetric_encrypt_t)(const uint8_t *p_key,
size_t key_size,
@ -800,7 +800,7 @@ typedef psa_status_t (*psa_drv_accel_asymmetric_encrypt_t)(const uint8_t *p_key,
* \param[out] p_output_length On success, the number of bytes
* that make up the returned output
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
*/
typedef psa_status_t (*psa_drv_accel_asymmetric_decrypt_t)(const uint8_t *p_key,
size_t key_size,

128
include/psa/crypto_compat.h
View file

@ -34,6 +34,27 @@
extern "C" {
#endif
/*
* To support both openless APIs and psa_open_key() temporarily, define
* psa_key_handle_t to be equal to mbedtls_svc_key_id_t. Do not mark the
* type and its utility macros and functions deprecated yet. This will be done
* in a subsequent phase.
*/
typedef mbedtls_svc_key_id_t psa_key_handle_t;
#define PSA_KEY_HANDLE_INIT MBEDTLS_SVC_KEY_ID_INIT
/** Check wether an handle is null.
*
* \param handle Handle
*
* \return Non-zero if the handle is null, zero otherwise.
*/
static inline int psa_key_handle_is_null( psa_key_handle_t handle )
{
return( mbedtls_svc_key_id_is_null( handle ) );
}
#if !defined(MBEDTLS_DEPRECATED_REMOVED)
/*
@ -113,10 +134,6 @@ MBEDTLS_PSA_DEPRECATED static inline psa_status_t psa_asymmetric_verify( psa_key
return psa_verify_hash( key, alg, hash, hash_length, signature, signature_length );
}
#endif /* MBEDTLS_DEPRECATED_REMOVED */
/*
* Size-specific elliptic curve families.
*/
@ -223,6 +240,109 @@ MBEDTLS_PSA_DEPRECATED static inline psa_status_t psa_asymmetric_verify( psa_key
#define PSA_DH_GROUP_CUSTOM \
MBEDTLS_DEPRECATED_CONSTANT( psa_dh_family_t, PSA_DH_FAMILY_CUSTOM )
#endif /* MBEDTLS_DEPRECATED_REMOVED */
/** Open a handle to an existing persistent key.
*
* Open a handle to a persistent key. A key is persistent if it was created
* with a lifetime other than #PSA_KEY_LIFETIME_VOLATILE. A persistent key
* always has a nonzero key identifier, set with psa_set_key_id() when
* creating the key. Implementations may provide additional pre-provisioned
* keys that can be opened with psa_open_key(). Such keys have an application
* key identifier in the vendor range, as documented in the description of
* #psa_key_id_t.
*
* The application must eventually close the handle with psa_close_key() or
* psa_destroy_key() to release associated resources. If the application dies
* without calling one of these functions, the implementation should perform
* the equivalent of a call to psa_close_key().
*
* Some implementations permit an application to open the same key multiple
* times. If this is successful, each call to psa_open_key() will return a
* different key handle.
*
* \note This API is not part of the PSA Cryptography API Release 1.0.0
* specification. It was defined in the 1.0 Beta 3 version of the
* specification but was removed in the 1.0.0 released version. This API is
* kept for the time being to not break applications relying on it. It is not
* deprecated yet but will be in the near future.
*
* \note Applications that rely on opening a key multiple times will not be
* portable to implementations that only permit a single key handle to be
* opened. See also :ref:\`key-handles\`.
*
*
* \param key The persistent identifier of the key.
* \param[out] handle On success, a handle to the key.
*
* \retval #PSA_SUCCESS
* Success. The application can now use the value of `*handle`
* to access the key.
* \retval #PSA_ERROR_INSUFFICIENT_MEMORY
* The implementation does not have sufficient resources to open the
* key. This can be due to reaching an implementation limit on the
* number of open keys, the number of open key handles, or available
* memory.
* \retval #PSA_ERROR_DOES_NOT_EXIST
* There is no persistent key with key identifier \p id.
* \retval #PSA_ERROR_INVALID_ARGUMENT
* \p id is not a valid persistent key identifier.
* \retval #PSA_ERROR_NOT_PERMITTED
* The specified key exists, but the application does not have the
* permission to access it. Note that this specification does not
* define any way to create such a key, but it may be possible
* through implementation-specific means.
* \retval #PSA_ERROR_COMMUNICATION_FAILURE
* \retval #PSA_ERROR_CORRUPTION_DETECTED
* \retval #PSA_ERROR_STORAGE_FAILURE
* \retval #PSA_ERROR_BAD_STATE
* The library has not been previously initialized by psa_crypto_init().
* It is implementation-dependent whether a failure to initialize
* results in this error code.
*/
psa_status_t psa_open_key( mbedtls_svc_key_id_t key,
psa_key_handle_t *handle );
/** Close a key handle.
*
* If the handle designates a volatile key, this will destroy the key material
* and free all associated resources, just like psa_destroy_key().
*
* If this is the last open handle to a persistent key, then closing the handle
* will free all resources associated with the key in volatile memory. The key
* data in persistent storage is not affected and can be opened again later
* with a call to psa_open_key().
*
* Closing the key handle makes the handle invalid, and the key handle
* must not be used again by the application.
*
* \note This API is not part of the PSA Cryptography API Release 1.0.0
* specification. It was defined in the 1.0 Beta 3 version of the
* specification but was removed in the 1.0.0 released version. This API is
* kept for the time being to not break applications relying on it. It is not
* deprecated yet but will be in the near future.
*
* \note If the key handle was used to set up an active
* :ref:\`multipart operation <multipart-operations>\`, then closing the
* key handle can cause the multipart operation to fail. Applications should
* maintain the key handle until after the multipart operation has finished.
*
* \param handle The key handle to close.
* If this is \c 0, do nothing and return \c PSA_SUCCESS.
*
* \retval #PSA_SUCCESS
* \p handle was a valid handle or \c 0. It is now closed.
* \retval #PSA_ERROR_INVALID_HANDLE
* \p handle is not a valid handle nor \c 0.
* \retval #PSA_ERROR_COMMUNICATION_FAILURE
* \retval #PSA_ERROR_CORRUPTION_DETECTED
* \retval #PSA_ERROR_BAD_STATE
* The library has not been previously initialized by psa_crypto_init().
* It is implementation-dependent whether a failure to initialize
* results in this error code.
*/
psa_status_t psa_close_key(psa_key_handle_t handle);
#ifdef __cplusplus
}
#endif

69
include/psa/crypto_config.h Normal file
View file

@ -0,0 +1,69 @@
/**
* \file psa/crypto_config.h
* \brief PSA crypto configuration options (set of defines)
*
*/
#if defined(MBEDTLS_PSA_CRYPTO_CONFIG)
/**
* When #MBEDTLS_PSA_CRYPTO_CONFIG is enabled in config.h,
* this file determines which cryptographic mechanisms are enabled
* through the PSA Cryptography API (\c psa_xxx() functions).
*
* To enable a cryptographic mechanism, uncomment the definition of
* the corresponding \c PSA_WANT_xxx preprocessor symbol.
* To disable a cryptographic mechanism, comment out the definition of
* the corresponding \c PSA_WANT_xxx preprocessor symbol.
* The names of cryptographic mechanisms correspond to values
* defined in psa/crypto_values.h, with the prefix \c PSA_WANT_ instead
* of \c PSA_.
*
* Note that many cryptographic mechanisms involve two symbols: one for
* the key type (\c PSA_WANT_KEY_TYPE_xxx) and one for the algorithm
* (\c PSA_WANT_ALG_xxx). Mechanisms with additional parameters may involve
* additional symbols.
*/
#else
/**
* When \c MBEDTLS_PSA_CRYPTO_CONFIG is disabled in config.h,
* this file is not used, and cryptographic mechanisms are supported
* through the PSA API if and only if they are supported through the
* mbedtls_xxx API.
*/
#endif
/*
* Copyright The Mbed TLS Contributors
* 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.
*/
#ifndef PSA_CRYPTO_CONFIG_H
#define PSA_CRYPTO_CONFIG_H
#define PSA_WANT_ALG_DETERMINISTIC_ECDSA 1
#define PSA_WANT_ALG_ECDH 1
#define PSA_WANT_ALG_ECDSA 1
#define PSA_WANT_ALG_HKDF 1
#define PSA_WANT_ALG_HMAC 1
#define PSA_WANT_ALG_RSA_OAEP 1
#define PSA_WANT_ALG_RSA_PKCS1V15_CRYPT 1
#define PSA_WANT_ALG_RSA_PKCS1V15_SIGN 1
#define PSA_WANT_ALG_RSA_PSS 1
#define PSA_WANT_ALG_TLS12_PRF 1
#define PSA_WANT_ALG_TLS12_PSK_TO_MS 1
#define PSA_WANT_KEY_TYPE_ECC_KEY_PAIR 1
#define PSA_WANT_KEY_TYPE_ECC_PUBLIC_KEY 1
#define PSA_WANT_KEY_TYPE_RSA_KEY_PAIR 1
#define PSA_WANT_KEY_TYPE_RSA_PUBLIC_KEY 1
#endif /* PSA_CRYPTO_CONFIG_H */

4
include/psa/crypto_entropy_driver.h
View file

@ -47,7 +47,7 @@ extern "C" {
* containing any context information for
* the implementation
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
*/
typedef psa_status_t (*psa_drv_entropy_init_t)(void *p_context);
@ -75,7 +75,7 @@ typedef psa_status_t (*psa_drv_entropy_init_t)(void *p_context);
* \param[out] p_received_entropy_bits The amount of entropy (in bits)
* actually provided in `p_buffer`
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
*/
typedef psa_status_t (*psa_drv_entropy_get_bits_t)(void *p_context,
uint8_t *p_buffer,

6
include/psa/crypto_extra.h
View file

@ -231,10 +231,12 @@ typedef struct mbedtls_psa_stats_s
size_t cache_slots;
/** Number of slots that are not used for anything. */
size_t empty_slots;
/** Number of slots that are locked. */
size_t locked_slots;
/** Largest key id value among open keys in internal persistent storage. */
psa_app_key_id_t max_open_internal_key_id;
psa_key_id_t max_open_internal_key_id;
/** Largest key id value among open keys in secure elements. */
psa_app_key_id_t max_open_external_key_id;
psa_key_id_t max_open_external_key_id;
} mbedtls_psa_stats_t;
/** \brief Get statistics about

80
include/psa/crypto_platform.h
View file

@ -41,60 +41,44 @@
#include MBEDTLS_CONFIG_FILE
#endif
/* Translate between classic MBEDTLS_xxx feature symbols and PSA_xxx
* feature symbols. */
#include "mbedtls/config_psa.h"
/* PSA requires several types which C99 provides in stdint.h. */
#include <stdint.h>
/* Integral type representing a key handle. */
typedef uint16_t psa_key_handle_t;
/* 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;
#if defined(MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER)
#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;
#if ( defined(__ARMCC_VERSION) || defined(_MSC_VER) ) && \
!defined(inline) && !defined(__cplusplus)
#define inline __inline
#endif
typedef struct
#if defined(MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER)
/* Building for the PSA Crypto service on a PSA platform, a key owner is a PSA
* partition identifier.
*
* The function psa_its_identifier_of_slot() in psa_crypto_storage.c that
* translates a key identifier to a key storage file name assumes that
* mbedtls_key_owner_id_t is an 32 bits integer. This function thus needs
* reworking if mbedtls_key_owner_id_t is not defined as a 32 bits integer
* here anymore.
*/
typedef int32_t mbedtls_key_owner_id_t;
/** Compare two key owner identifiers.
*
* \param id1 First key owner identifier.
* \param id2 Second key owner identifier.
*
* \return Non-zero if the two key owner identifiers are equal, zero otherwise.
*/
static inline int mbedtls_key_owner_id_equal( mbedtls_key_owner_id_t id1,
mbedtls_key_owner_id_t id2 )
{
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 )
return( id1 == id2 );
}
/* 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;
#define PSA_KEY_ID_INIT {0, 0}
#else /* !MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER */
/* 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 )
#endif /* !MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER */
#endif /* MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER */
#endif /* PSA_CRYPTO_PLATFORM_H */

60
include/psa/crypto_se_driver.h
View file

@ -178,7 +178,7 @@ typedef uint64_t psa_key_slot_number_t;
* \param[in] algorithm The algorithm to be used to underly the MAC
* operation
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
* Success.
*/
typedef psa_status_t (*psa_drv_se_mac_setup_t)(psa_drv_se_context_t *drv_context,
@ -213,7 +213,7 @@ typedef psa_status_t (*psa_drv_se_mac_update_t)(void *op_context,
* \param[out] p_mac_length After completion, will contain the number of
* bytes placed in the `p_mac` buffer
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
* Success.
*/
typedef psa_status_t (*psa_drv_se_mac_finish_t)(void *op_context,
@ -230,10 +230,10 @@ typedef psa_status_t (*psa_drv_se_mac_finish_t)(void *op_context,
* will be compared against
* \param[in] mac_length The size in bytes of the value stored in `p_mac`
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
* The operation completed successfully and the MACs matched each
* other
* \retval PSA_ERROR_INVALID_SIGNATURE
* \retval #PSA_ERROR_INVALID_SIGNATURE
* The operation completed successfully, but the calculated MAC did
* not match the provided MAC
*/
@ -264,7 +264,7 @@ typedef psa_status_t (*psa_drv_se_mac_abort_t)(void *op_context);
* \param[out] p_mac_length After completion, will contain the number of
* bytes placed in the `output` buffer
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
* Success.
*/
typedef psa_status_t (*psa_drv_se_mac_generate_t)(psa_drv_se_context_t *drv_context,
@ -289,10 +289,10 @@ typedef psa_status_t (*psa_drv_se_mac_generate_t)(psa_drv_se_context_t *drv_cont
* be compared against
* \param[in] mac_length The size in bytes of `mac`
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
* The operation completed successfully and the MACs matched each
* other
* \retval PSA_ERROR_INVALID_SIGNATURE
* \retval #PSA_ERROR_INVALID_SIGNATURE
* The operation completed successfully, but the calculated MAC did
* not match the provided MAC
*/
@ -384,8 +384,8 @@ typedef struct {
* \param[in] direction Indicates whether the operation is an encrypt
* or decrypt
*
* \retval PSA_SUCCESS
* \retval PSA_ERROR_NOT_SUPPORTED
* \retval #PSA_SUCCESS
* \retval #PSA_ERROR_NOT_SUPPORTED
*/
typedef psa_status_t (*psa_drv_se_cipher_setup_t)(psa_drv_se_context_t *drv_context,
void *op_context,
@ -406,7 +406,7 @@ typedef psa_status_t (*psa_drv_se_cipher_setup_t)(psa_drv_se_context_t *drv_cont
* \param[in] p_iv A buffer containing the initialization vector
* \param[in] iv_length The size (in bytes) of the `p_iv` buffer
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
*/
typedef psa_status_t (*psa_drv_se_cipher_set_iv_t)(void *op_context,
const uint8_t *p_iv,
@ -428,7 +428,7 @@ typedef psa_status_t (*psa_drv_se_cipher_set_iv_t)(void *op_context,
* \param[out] p_output_length After completion, will contain the number
* of bytes placed in the `p_output` buffer
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
*/
typedef psa_status_t (*psa_drv_se_cipher_update_t)(void *op_context,
const uint8_t *p_input,
@ -449,7 +449,7 @@ typedef psa_status_t (*psa_drv_se_cipher_update_t)(void *op_context,
* \param[out] p_output_length After completion, will contain the number of
* bytes placed in the `p_output` buffer
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
*/
typedef psa_status_t (*psa_drv_se_cipher_finish_t)(void *op_context,
uint8_t *p_output,
@ -484,8 +484,8 @@ typedef psa_status_t (*psa_drv_se_cipher_abort_t)(void *op_context);
* \param[in] output_size The allocated size in bytes of the `p_output`
* buffer
*
* \retval PSA_SUCCESS
* \retval PSA_ERROR_NOT_SUPPORTED
* \retval #PSA_SUCCESS
* \retval #PSA_ERROR_NOT_SUPPORTED
*/
typedef psa_status_t (*psa_drv_se_cipher_ecb_t)(psa_drv_se_context_t *drv_context,
psa_key_slot_number_t key_slot,
@ -553,7 +553,7 @@ typedef struct {
* \param[out] p_signature_length On success, the number of bytes
* that make up the returned signature value
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
*/
typedef psa_status_t (*psa_drv_se_asymmetric_sign_t)(psa_drv_se_context_t *drv_context,
psa_key_slot_number_t key_slot,
@ -578,7 +578,7 @@ typedef psa_status_t (*psa_drv_se_asymmetric_sign_t)(psa_drv_se_context_t *drv_c
* \param[in] p_signature Buffer containing the signature to verify
* \param[in] signature_length Size of the `p_signature` buffer in bytes
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
* The signature is valid.
*/
typedef psa_status_t (*psa_drv_se_asymmetric_verify_t)(psa_drv_se_context_t *drv_context,
@ -617,7 +617,7 @@ typedef psa_status_t (*psa_drv_se_asymmetric_verify_t)(psa_drv_se_context_t *drv
* \param[out] p_output_length On success, the number of bytes that make up
* the returned output
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
*/
typedef psa_status_t (*psa_drv_se_asymmetric_encrypt_t)(psa_drv_se_context_t *drv_context,
psa_key_slot_number_t key_slot,
@ -657,7 +657,7 @@ typedef psa_status_t (*psa_drv_se_asymmetric_encrypt_t)(psa_drv_se_context_t *dr
* \param[out] p_output_length On success, the number of bytes
* that make up the returned output
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
*/
typedef psa_status_t (*psa_drv_se_asymmetric_decrypt_t)(psa_drv_se_context_t *drv_context,
psa_key_slot_number_t key_slot,
@ -1195,7 +1195,7 @@ typedef struct {
* \param[in] source_key The key to be used as the source material for
* the key derivation
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
*/
typedef psa_status_t (*psa_drv_se_key_derivation_setup_t)(psa_drv_se_context_t *drv_context,
void *op_context,
@ -1215,7 +1215,7 @@ typedef psa_status_t (*psa_drv_se_key_derivation_setup_t)(psa_drv_se_context_t *
* \param[in] p_collateral A buffer containing the collateral data
* \param[in] collateral_size The size in bytes of the collateral
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
*/
typedef psa_status_t (*psa_drv_se_key_derivation_collateral_t)(void *op_context,
uint32_t collateral_id,
@ -1230,7 +1230,7 @@ typedef psa_status_t (*psa_drv_se_key_derivation_collateral_t)(void *op_context,
* \param[in] dest_key The slot where the generated key material
* should be placed
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
*/
typedef psa_status_t (*psa_drv_se_key_derivation_derive_t)(void *op_context,
psa_key_slot_number_t dest_key);
@ -1244,7 +1244,7 @@ typedef psa_status_t (*psa_drv_se_key_derivation_derive_t)(void *op_context,
* \param[out] p_output_length Upon success, contains the number of bytes of
* key material placed in `p_output`
*
* \retval PSA_SUCCESS
* \retval #PSA_SUCCESS
*/
typedef psa_status_t (*psa_drv_se_key_derivation_export_t)(void *op_context,
uint8_t *p_output,
@ -1353,7 +1353,7 @@ typedef struct {
* \param location The location value through which this driver will
* be exposed to applications.
* This driver will be used for all keys such that
* `location == PSA_KEY_LIFETIME_LOCATION( lifetime )`.
* `location == #PSA_KEY_LIFETIME_GET_LOCATION( lifetime )`.
* The value #PSA_KEY_LOCATION_LOCAL_STORAGE is reserved
* and may not be used for drivers. Implementations
* may reserve other values.
@ -1362,22 +1362,22 @@ typedef struct {
* module keeps running. It is typically a global
* constant.
*
* \return PSA_SUCCESS
* \return #PSA_SUCCESS
* The driver was successfully registered. Applications can now
* use \p lifetime to access keys through the methods passed to
* this function.
* \return PSA_ERROR_BAD_STATE
* \return #PSA_ERROR_BAD_STATE
* This function was called after the initialization of the
* cryptography module, and this implementation does not support
* driver registration at this stage.
* \return PSA_ERROR_ALREADY_EXISTS
* \return #PSA_ERROR_ALREADY_EXISTS
* There is already a registered driver for this value of \p lifetime.
* \return PSA_ERROR_INVALID_ARGUMENT
* \return #PSA_ERROR_INVALID_ARGUMENT
* \p lifetime is a reserved value.
* \return PSA_ERROR_NOT_SUPPORTED
* \return #PSA_ERROR_NOT_SUPPORTED
* `methods->hal_version` is not supported by this implementation.
* \return PSA_ERROR_INSUFFICIENT_MEMORY
* \return PSA_ERROR_NOT_PERMITTED
* \return #PSA_ERROR_INSUFFICIENT_MEMORY
* \return #PSA_ERROR_NOT_PERMITTED
*/
psa_status_t psa_register_se_driver(
psa_key_location_t location,

87
include/psa/crypto_sizes.h
View file

@ -657,4 +657,91 @@
PSA_KEY_TYPE_IS_ECC_PUBLIC_KEY(key_type) ? PSA_KEY_EXPORT_ECC_PUBLIC_KEY_MAX_SIZE(key_bits) : \
0)
/** The default nonce size for an AEAD algorithm, in bytes.
*
* This macro can be used to allocate a buffer of sufficient size to
* store the nonce output from #psa_aead_generate_nonce().
*
* See also #PSA_AEAD_NONCE_MAX_SIZE.
*
* \note This is not the maximum size of nonce supported as input to #psa_aead_set_nonce(),
* #psa_aead_encrypt() or #psa_aead_decrypt(), just the default size that is generated by
* #psa_aead_generate_nonce().
*
* \warning This macro may evaluate its arguments multiple times or
* zero times, so you should not pass arguments that contain
* side effects.
*
* \param key_type A symmetric key type that is compatible with algorithm \p alg.
*
* \param alg An AEAD algorithm (\c PSA_ALG_XXX value such that #PSA_ALG_IS_AEAD(\p alg) is true).
*
* \return The default nonce size for the specified key type and algorithm.
* If the key type or AEAD algorithm is not recognized,
* or the parameters are incompatible, return 0.
* An implementation can return either 0 or a correct size for a key type
* and AEAD algorithm that it recognizes, but does not support.
*/
#define PSA_AEAD_NONCE_LENGTH(key_type, alg) \
(PSA_BLOCK_CIPHER_BLOCK_SIZE(key_type) == 16 && \
(PSA_ALG_AEAD_WITH_DEFAULT_TAG_LENGTH(alg) == PSA_ALG_CCM || \
PSA_ALG_AEAD_WITH_DEFAULT_TAG_LENGTH(alg) == PSA_ALG_GCM) ? 12 : \
(key_type) == PSA_KEY_TYPE_CHACHA20 && \
PSA_ALG_AEAD_WITH_DEFAULT_TAG_LENGTH(alg) == PSA_ALG_CHACHA20_POLY1305 ? 12 : \
0)
/** The maximum default nonce size among all supported pairs of key types and AEAD algorithms, in bytes.
*
* This is equal to or greater than any value that #PSA_AEAD_NONCE_LENGTH() may return.
*
* \note This is not the maximum size of nonce supported as input to #psa_aead_set_nonce(),
* #psa_aead_encrypt() or #psa_aead_decrypt(), just the largest size that may be generated by
* #psa_aead_generate_nonce().
*/
#define PSA_AEAD_NONCE_MAX_SIZE 12
/** The default IV size for a cipher algorithm, in bytes.
*
* The IV that is generated as part of a call to #psa_cipher_encrypt() is always
* the default IV length for the algorithm.
*
* This macro can be used to allocate a buffer of sufficient size to
* store the IV output from #psa_cipher_generate_iv() when using
* a multi-part cipher operation.
*
* See also #PSA_CIPHER_IV_MAX_SIZE.
*
* \warning This macro may evaluate its arguments multiple times or
* zero times, so you should not pass arguments that contain
* side effects.
*
* \param key_type A symmetric key type that is compatible with algorithm \p alg.
*
* \param alg A cipher algorithm (\c PSA_ALG_XXX value such that #PSA_ALG_IS_CIPHER(\p alg) is true).
*
* \return The default IV size for the specified key type and algorithm.
* If the algorithm does not use an IV, return 0.
* If the key type or cipher algorithm is not recognized,
* or the parameters are incompatible, return 0.
* An implementation can return either 0 or a correct size for a key type
* and cipher algorithm that it recognizes, but does not support.
*/
#define PSA_CIPHER_IV_LENGTH(key_type, alg) \
(PSA_BLOCK_CIPHER_BLOCK_SIZE(key_type) > 1 && \
((alg) == PSA_ALG_CTR || \
(alg) == PSA_ALG_CFB || \
(alg) == PSA_ALG_OFB || \
(alg) == PSA_ALG_XTS || \
(alg) == PSA_ALG_CBC_NO_PADDING || \
(alg) == PSA_ALG_CBC_PKCS7) ? PSA_BLOCK_CIPHER_BLOCK_SIZE(key_type) : \
(key_type) == PSA_KEY_TYPE_CHACHA20 && \
(alg) == PSA_ALG_CHACHA20 ? 12 : \
0)
/** The maximum IV size for all supported cipher algorithms, in bytes.
*
* See also #PSA_CIPHER_IV_LENGTH().
*/
#define PSA_CIPHER_IV_MAX_SIZE 16
#endif /* PSA_CRYPTO_SIZES_H */

51
include/psa/crypto_struct.h
View file

@ -77,6 +77,16 @@ extern "C" {
#include "mbedtls/sha256.h"
#include "mbedtls/sha512.h"
typedef struct {
/** Unique ID indicating which driver got assigned to do the
* operation. Since driver contexts are driver-specific, swapping
* drivers halfway through the operation is not supported.
* ID values are auto-generated in psa_driver_wrappers.h */
unsigned int id;
/** Context structure for the assigned driver, when id is not zero. */
void* ctx;
} psa_operation_driver_context_t;
struct psa_hash_operation_s
{
psa_algorithm_t alg;
@ -158,16 +168,18 @@ struct psa_cipher_operation_s
unsigned int key_set : 1;
unsigned int iv_required : 1;
unsigned int iv_set : 1;
unsigned int mbedtls_in_use : 1; /* Indicates mbed TLS is handling the operation. */
uint8_t iv_size;
uint8_t block_size;
union
{
unsigned dummy; /* Enable easier initializing of the union. */
mbedtls_cipher_context_t cipher;
psa_operation_driver_context_t driver;
} ctx;
};
#define PSA_CIPHER_OPERATION_INIT {0, 0, 0, 0, 0, 0, {0}}
#define PSA_CIPHER_OPERATION_INIT {0, 0, 0, 0, 0, 0, 0, {0}}
static inline struct psa_cipher_operation_s psa_cipher_operation_init( void )
{
const struct psa_cipher_operation_s v = PSA_CIPHER_OPERATION_INIT;
@ -330,12 +342,12 @@ typedef struct
psa_key_type_t type;
psa_key_bits_t bits;
psa_key_lifetime_t lifetime;
psa_key_id_t id;
mbedtls_svc_key_id_t id;
psa_key_policy_t policy;
psa_key_attributes_flag_t flags;
} psa_core_key_attributes_t;
#define PSA_CORE_KEY_ATTRIBUTES_INIT {PSA_KEY_TYPE_NONE, 0, PSA_KEY_LIFETIME_VOLATILE, PSA_KEY_ID_INIT, PSA_KEY_POLICY_INIT, 0}
#define PSA_CORE_KEY_ATTRIBUTES_INIT {PSA_KEY_TYPE_NONE, 0, PSA_KEY_LIFETIME_VOLATILE, MBEDTLS_SVC_KEY_ID_INIT, PSA_KEY_POLICY_INIT, 0}
struct psa_key_attributes_s
{
@ -359,29 +371,44 @@ static inline struct psa_key_attributes_s psa_key_attributes_init( void )
return( v );
}
static inline void psa_set_key_id(psa_key_attributes_t *attributes,
psa_key_id_t id)
static inline void psa_set_key_id( psa_key_attributes_t *attributes,
mbedtls_svc_key_id_t key )
{
attributes->core.id = id;
if( attributes->core.lifetime == PSA_KEY_LIFETIME_VOLATILE )
attributes->core.lifetime = PSA_KEY_LIFETIME_PERSISTENT;
psa_key_lifetime_t lifetime = attributes->core.lifetime;
attributes->core.id = key;
if( PSA_KEY_LIFETIME_IS_VOLATILE( lifetime ) )
{
attributes->core.lifetime =
PSA_KEY_LIFETIME_FROM_PERSISTENCE_AND_LOCATION(
PSA_KEY_LIFETIME_PERSISTENT,
PSA_KEY_LIFETIME_GET_LOCATION( lifetime ) );
}
}
static inline psa_key_id_t psa_get_key_id(
static inline mbedtls_svc_key_id_t psa_get_key_id(
const psa_key_attributes_t *attributes)
{
return( attributes->core.id );
}
#ifdef MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER
static inline void mbedtls_set_key_owner_id( psa_key_attributes_t *attributes,
mbedtls_key_owner_id_t owner )
{
attributes->core.id.owner = owner;
}
#endif
static inline void psa_set_key_lifetime(psa_key_attributes_t *attributes,
psa_key_lifetime_t lifetime)
{
attributes->core.lifetime = lifetime;
if( lifetime == PSA_KEY_LIFETIME_VOLATILE )
if( PSA_KEY_LIFETIME_IS_VOLATILE( lifetime ) )
{
#ifdef MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER
#ifdef MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER
attributes->core.id.key_id = 0;
attributes->core.id.owner = 0;
#else
attributes->core.id = 0;
#endif

31
include/psa/crypto_types.h
View file

@ -33,6 +33,8 @@
#ifndef PSA_CRYPTO_TYPES_H
#define PSA_CRYPTO_TYPES_H
#include "crypto_platform.h"
#include <stdint.h>
/** \defgroup error Error codes
@ -123,7 +125,7 @@ typedef uint32_t psa_algorithm_t;
* implementation-specific device management event occurs (for example,
* a factory reset).
*
* Persistent keys have a key identifier of type #psa_key_id_t.
* Persistent keys have a key identifier of type #mbedtls_svc_key_id_t.
* This identifier remains valid throughout the lifetime of the key,
* even if the application instance that created the key terminates.
* The application can call psa_open_key() to open a persistent key that
@ -226,15 +228,24 @@ typedef uint32_t psa_key_location_t;
* - 0 is reserved as an invalid key identifier.
* - Key identifiers outside these ranges are reserved for future use.
*/
/* Implementation-specific quirk: The Mbed Crypto library can be built as
* part of a multi-client service that exposes the PSA Crypto API in each
* client and encodes the client identity in the key id argument of functions
* such as psa_open_key(). In this build configuration, we define
* psa_key_id_t in crypto_platform.h instead of here. */
#if !defined(MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER)
typedef uint32_t psa_key_id_t;
#define PSA_KEY_ID_INIT 0
#endif
#if !defined(MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER)
typedef psa_key_id_t mbedtls_svc_key_id_t;
#else /* MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER */
/* Implementation-specific: The Mbed Cryptography library can be built as
* part of a multi-client service that exposes the PSA Cryptograpy API in each
* client and encodes the client identity in the key identifier argument of
* functions such as psa_open_key().
*/
typedef struct
{
psa_key_id_t key_id;
mbedtls_key_owner_id_t owner;
} mbedtls_svc_key_id_t;
#endif /* !MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER */
/**@}*/
@ -341,7 +352,7 @@ typedef uint32_t psa_key_usage_t;
* -# Call a key creation function: psa_import_key(), psa_generate_key(),
* psa_key_derivation_output_key() or psa_copy_key(). This function reads
* the attribute structure, creates a key with these attributes, and
* outputs a handle to the newly created key.
* outputs a key identifier to the newly created key.
* -# The attribute structure is now no longer necessary.
* You may call psa_reset_key_attributes(), although this is optional
* with the workflow presented here because the attributes currently

133
include/psa/crypto_values.h
View file

@ -108,7 +108,7 @@
* as applicable.
*
* Implementations shall not return this error code to indicate that a
* key handle is invalid, but shall return #PSA_ERROR_INVALID_HANDLE
* key identifier is invalid, but shall return #PSA_ERROR_INVALID_HANDLE
* instead. */
#define PSA_ERROR_BAD_STATE ((psa_status_t)-137)
@ -118,7 +118,7 @@
* combination of parameters are recognized as invalid.
*
* Implementations shall not return this error code to indicate that a
* key handle is invalid, but shall return #PSA_ERROR_INVALID_HANDLE
* key identifier is invalid, but shall return #PSA_ERROR_INVALID_HANDLE
* instead.
*/
#define PSA_ERROR_INVALID_ARGUMENT ((psa_status_t)-135)
@ -266,7 +266,7 @@
* to read from a resource. */
#define PSA_ERROR_INSUFFICIENT_DATA ((psa_status_t)-143)
/** The key handle is not valid. See also :ref:\`key-handles\`.
/** The key identifier is not valid. See also :ref:\`key-handles\`.
*/
#define PSA_ERROR_INVALID_HANDLE ((psa_status_t)-136)
@ -769,9 +769,9 @@
* an algorithm built from `PSA_xxx_SIGNATURE` and a specific hash. Each
* call to sign or verify a message may use a different hash.
* ```
* psa_sign_hash(handle, PSA_xxx_SIGNATURE(PSA_ALG_SHA_256), ...);
* psa_sign_hash(handle, PSA_xxx_SIGNATURE(PSA_ALG_SHA_512), ...);
* psa_sign_hash(handle, PSA_xxx_SIGNATURE(PSA_ALG_SHA3_256), ...);
* psa_sign_hash(key, PSA_xxx_SIGNATURE(PSA_ALG_SHA_256), ...);
* psa_sign_hash(key, PSA_xxx_SIGNATURE(PSA_ALG_SHA_512), ...);
* psa_sign_hash(key, PSA_xxx_SIGNATURE(PSA_ALG_SHA3_256), ...);
* ```
*
* This value may not be used to build other algorithms that are
@ -978,6 +978,26 @@
*/
#define PSA_ALG_XTS ((psa_algorithm_t)0x044000ff)
/** The Electronic Code Book (ECB) mode of a block cipher, with no padding.
*
* \warning ECB mode does not protect the confidentiality of the encrypted data
* except in extremely narrow circumstances. It is recommended that applications
* only use ECB if they need to construct an operating mode that the
* implementation does not provide. Implementations are encouraged to provide
* the modes that applications need in preference to supporting direct access
* to ECB.
*
* The underlying block cipher is determined by the key type.
*
* This symmetric cipher mode can only be used with messages whose lengths are a
* multiple of the block size of the chosen block cipher.
*
* ECB mode does not accept an initialization vector (IV). When using a
* multi-part cipher operation with this algorithm, psa_cipher_generate_iv()
* and psa_cipher_set_iv() must not be called.
*/
#define PSA_ALG_ECB_NO_PADDING ((psa_algorithm_t)0x04404400)
/** The CBC block cipher chaining mode, with no padding.
*
* The underlying block cipher is determined by the key type.
@ -1432,7 +1452,7 @@
* a key derivation function.
* Usually, raw key agreement algorithms are constructed directly with
* a \c PSA_ALG_xxx macro while non-raw key agreement algorithms are
* constructed with PSA_ALG_KEY_AGREEMENT().
* constructed with #PSA_ALG_KEY_AGREEMENT().
*
* \param alg An algorithm identifier (value of type #psa_algorithm_t).
*
@ -1541,7 +1561,7 @@
/** The default lifetime for volatile keys.
*
* A volatile key only exists as long as the handle to it is not closed.
* A volatile key only exists as long as the identifier to it is not destroyed.
* The key material is guaranteed to be erased on a power reset.
*
* A key with this lifetime is typically stored in the RAM area of the
@ -1636,16 +1656,105 @@
/** The minimum value for a key identifier chosen by the application.
*/
#define PSA_KEY_ID_USER_MIN ((psa_app_key_id_t)0x00000001)
#define PSA_KEY_ID_USER_MIN ((psa_key_id_t)0x00000001)
/** The maximum value for a key identifier chosen by the application.
*/
#define PSA_KEY_ID_USER_MAX ((psa_app_key_id_t)0x3fffffff)
#define PSA_KEY_ID_USER_MAX ((psa_key_id_t)0x3fffffff)
/** The minimum value for a key identifier chosen by the implementation.
*/
#define PSA_KEY_ID_VENDOR_MIN ((psa_app_key_id_t)0x40000000)
#define PSA_KEY_ID_VENDOR_MIN ((psa_key_id_t)0x40000000)
/** The maximum value for a key identifier chosen by the implementation.
*/
#define PSA_KEY_ID_VENDOR_MAX ((psa_app_key_id_t)0x7fffffff)
#define PSA_KEY_ID_VENDOR_MAX ((psa_key_id_t)0x7fffffff)
#if !defined(MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER)
#define MBEDTLS_SVC_KEY_ID_INIT ( (psa_key_id_t)0 )
#define MBEDTLS_SVC_KEY_ID_GET_KEY_ID( id ) ( id )
#define MBEDTLS_SVC_KEY_ID_GET_OWNER_ID( id ) ( 0 )
/** Utility to initialize a key identifier at runtime.
*
* \param unused Unused parameter.
* \param key_id Identifier of the key.
*/
static inline mbedtls_svc_key_id_t mbedtls_svc_key_id_make(
unsigned int unused, psa_key_id_t key_id )
{
(void)unused;
return( key_id );
}
/** Compare two key identifiers.
*
* \param id1 First key identifier.
* \param id2 Second key identifier.
*
* \return Non-zero if the two key identifier are equal, zero otherwise.
*/
static inline int mbedtls_svc_key_id_equal( mbedtls_svc_key_id_t id1,
mbedtls_svc_key_id_t id2 )
{
return( id1 == id2 );
}
/** Check whether a key identifier is null.
*
* \param key Key identifier.
*
* \return Non-zero if the key identifier is null, zero otherwise.
*/
static inline int mbedtls_svc_key_id_is_null( mbedtls_svc_key_id_t key )
{
return( key == 0 );
}
#else /* MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER */
#define MBEDTLS_SVC_KEY_ID_INIT ( (mbedtls_svc_key_id_t){ 0, 0 } )
#define MBEDTLS_SVC_KEY_ID_GET_KEY_ID( id ) ( ( id ).key_id )
#define MBEDTLS_SVC_KEY_ID_GET_OWNER_ID( id ) ( ( id ).owner )
/** Utility to initialize a key identifier at runtime.
*
* \param owner_id Identifier of the key owner.
* \param key_id Identifier of the key.
*/
static inline mbedtls_svc_key_id_t mbedtls_svc_key_id_make(
mbedtls_key_owner_id_t owner_id, psa_key_id_t key_id )
{
return( (mbedtls_svc_key_id_t){ .key_id = key_id,
.owner = owner_id } );
}
/** Compare two key identifiers.
*
* \param id1 First key identifier.
* \param id2 Second key identifier.
*
* \return Non-zero if the two key identifier are equal, zero otherwise.
*/
static inline int mbedtls_svc_key_id_equal( mbedtls_svc_key_id_t id1,
mbedtls_svc_key_id_t id2 )
{
return( ( id1.key_id == id2.key_id ) &&
mbedtls_key_owner_id_equal( id1.owner, id2.owner ) );
}
/** Check whether a key identifier is null.
*
* \param key Key identifier.
*
* \return Non-zero if the key identifier is null, zero otherwise.
*/
static inline int mbedtls_svc_key_id_is_null( mbedtls_svc_key_id_t key )
{
return( ( key.key_id == 0 ) && ( key.owner == 0 ) );
}
#endif /* !MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER */
/**@}*/

63
library/CMakeLists.txt
View file

@ -61,6 +61,7 @@ set(src_crypto
platform_util.c
poly1305.c
psa_crypto.c
psa_crypto_driver_wrappers.c
psa_crypto_se.c
psa_crypto_slot_management.c
psa_crypto_storage.c
@ -103,6 +104,7 @@ set(src_tls
ssl_srv.c
ssl_ticket.c
ssl_tls.c
ssl_tls13_keys.c
)
if(CMAKE_COMPILER_IS_GNUCC)
@ -148,46 +150,59 @@ if (NOT USE_STATIC_MBEDTLS_LIBRARY AND NOT USE_SHARED_MBEDTLS_LIBRARY)
message(FATAL_ERROR "Need to choose static or shared mbedtls build!")
endif(NOT USE_STATIC_MBEDTLS_LIBRARY AND NOT USE_SHARED_MBEDTLS_LIBRARY)
set(target_libraries "mbedcrypto" "mbedx509" "mbedtls")
set(mbedtls_target "${MBEDTLS_TARGET_PREFIX}mbedtls")
set(mbedx509_target "${MBEDTLS_TARGET_PREFIX}mbedx509")
set(mbedcrypto_target "${MBEDTLS_TARGET_PREFIX}mbedcrypto")
set(mbedtls_target ${mbedtls_target} PARENT_SCOPE)
set(mbedx509_target ${mbedx509_target} PARENT_SCOPE)
set(mbedcrypto_target ${mbedcrypto_target} PARENT_SCOPE)
if (USE_STATIC_MBEDTLS_LIBRARY)
set(mbedtls_static_target ${mbedtls_target})
set(mbedx509_static_target ${mbedx509_target})
set(mbedcrypto_static_target ${mbedcrypto_target})
endif()
set(target_libraries ${mbedcrypto_target} ${mbedx509_target} ${mbedtls_target})
if(USE_STATIC_MBEDTLS_LIBRARY AND USE_SHARED_MBEDTLS_LIBRARY)
set(mbedtls_static_target "mbedtls_static")
set(mbedx509_static_target "mbedx509_static")
set(mbedcrypto_static_target "mbedcrypto_static")
string(APPEND mbedtls_static_target "_static")
string(APPEND mbedx509_static_target "_static")
string(APPEND mbedcrypto_static_target "_static")
list(APPEND target_libraries
"mbedcrypto_static" "mbedx509_static" "mbedtls_static")
elseif(USE_STATIC_MBEDTLS_LIBRARY)
set(mbedtls_static_target "mbedtls")
set(mbedx509_static_target "mbedx509")
set(mbedcrypto_static_target "mbedcrypto")
${mbedcrypto_static_target}
${mbedx509_static_target}
${mbedtls_static_target})
endif()
if(USE_STATIC_MBEDTLS_LIBRARY)
add_library(${mbedcrypto_static_target} STATIC ${src_crypto})
set_target_properties(${mbedcrypto_static_target} PROPERTIES OUTPUT_NAME mbedcrypto)
target_link_libraries(${mbedcrypto_static_target} ${libs})
target_link_libraries(${mbedcrypto_static_target} PUBLIC ${libs})
add_library(${mbedx509_static_target} STATIC ${src_x509})
set_target_properties(${mbedx509_static_target} PROPERTIES OUTPUT_NAME mbedx509)
target_link_libraries(${mbedx509_static_target} ${libs} ${mbedcrypto_static_target})
target_link_libraries(${mbedx509_static_target} PUBLIC ${libs} ${mbedcrypto_static_target})
add_library(${mbedtls_static_target} STATIC ${src_tls})
set_target_properties(${mbedtls_static_target} PROPERTIES OUTPUT_NAME mbedtls)
target_link_libraries(${mbedtls_static_target} ${libs} ${mbedx509_static_target})
target_link_libraries(${mbedtls_static_target} PUBLIC ${libs} ${mbedx509_static_target})
endif(USE_STATIC_MBEDTLS_LIBRARY)
if(USE_SHARED_MBEDTLS_LIBRARY)
add_library(mbedcrypto SHARED ${src_crypto})
set_target_properties(mbedcrypto PROPERTIES VERSION 2.23.0 SOVERSION 5)
target_link_libraries(mbedcrypto ${libs})
add_library(${mbedcrypto_target} SHARED ${src_crypto})
set_target_properties(${mbedcrypto_target} PROPERTIES VERSION 2.24.0 SOVERSION 5)
target_link_libraries(${mbedcrypto_target} PUBLIC ${libs})
add_library(mbedx509 SHARED ${src_x509})
set_target_properties(mbedx509 PROPERTIES VERSION 2.23.0 SOVERSION 1)
target_link_libraries(mbedx509 ${libs} mbedcrypto)
add_library(${mbedx509_target} SHARED ${src_x509})
set_target_properties(${mbedx509_target} PROPERTIES VERSION 2.24.0 SOVERSION 1)
target_link_libraries(${mbedx509_target} PUBLIC ${libs} ${mbedcrypto_target})
add_library(mbedtls SHARED ${src_tls})
set_target_properties(mbedtls PROPERTIES VERSION 2.23.0 SOVERSION 13)
target_link_libraries(mbedtls ${libs} mbedx509)
add_library(${mbedtls_target} SHARED ${src_tls})
set_target_properties(${mbedtls_target} PROPERTIES VERSION 2.24.0 SOVERSION 13)
target_link_libraries(${mbedtls_target} PUBLIC ${libs} ${mbedx509_target})
endif(USE_SHARED_MBEDTLS_LIBRARY)
foreach(target IN LISTS target_libraries)
@ -208,7 +223,9 @@ foreach(target IN LISTS target_libraries)
PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ)
endforeach(target)
add_custom_target(lib DEPENDS mbedcrypto mbedx509 mbedtls)
set(lib_target "${MBEDTLS_TARGET_PREFIX}lib")
add_custom_target(${lib_target} DEPENDS ${mbedcrypto_target} ${mbedx509_target} ${mbedtls_target})
if(USE_STATIC_MBEDTLS_LIBRARY AND USE_SHARED_MBEDTLS_LIBRARY)
add_dependencies(lib mbedcrypto_static mbedx509_static mbedtls_static)
add_dependencies(${lib_target} ${mbedcrypto_static_target} ${mbedx509_static_target} ${mbedtls_static_target})
endif()

2
library/Makefile
View file

@ -118,6 +118,7 @@ OBJS_CRYPTO= \
platform_util.o \
poly1305.o \
psa_crypto.o \
psa_crypto_driver_wrappers.o \
psa_crypto_se.o \
psa_crypto_slot_management.o \
psa_crypto_storage.o \
@ -162,6 +163,7 @@ OBJS_TLS= \
ssl_srv.o \
ssl_ticket.o \
ssl_tls.o \
ssl_tls13_keys.o \
# This line is intentionally left blank
.SILENT:

169
library/aes.c
View file

@ -730,6 +730,7 @@ exit:
return( ret );
}
#endif /* !MBEDTLS_AES_SETKEY_DEC_ALT */
#if defined(MBEDTLS_CIPHER_MODE_XTS)
static int mbedtls_aes_xts_decode_keys( const unsigned char *key,
@ -808,8 +809,6 @@ int mbedtls_aes_xts_setkey_dec( mbedtls_aes_xts_context *ctx,
}
#endif /* MBEDTLS_CIPHER_MODE_XTS */
#endif /* !MBEDTLS_AES_SETKEY_DEC_ALT */
#define AES_FROUND(X0,X1,X2,X3,Y0,Y1,Y2,Y3) \
do \
{ \
@ -867,63 +866,56 @@ int mbedtls_internal_aes_encrypt( mbedtls_aes_context *ctx,
unsigned char output[16] )
{
int i;
uint32_t *RK, X0, X1, X2, X3, Y0, Y1, Y2, Y3;
uint32_t *RK = ctx->rk;
struct
{
uint32_t X[4];
uint32_t Y[4];
} t;
RK = ctx->rk;
GET_UINT32_LE( X0, input, 0 ); X0 ^= *RK++;
GET_UINT32_LE( X1, input, 4 ); X1 ^= *RK++;
GET_UINT32_LE( X2, input, 8 ); X2 ^= *RK++;
GET_UINT32_LE( X3, input, 12 ); X3 ^= *RK++;
GET_UINT32_LE( t.X[0], input, 0 ); t.X[0] ^= *RK++;
GET_UINT32_LE( t.X[1], input, 4 ); t.X[1] ^= *RK++;
GET_UINT32_LE( t.X[2], input, 8 ); t.X[2] ^= *RK++;
GET_UINT32_LE( t.X[3], input, 12 ); t.X[3] ^= *RK++;
for( i = ( ctx->nr >> 1 ) - 1; i > 0; i-- )
{
AES_FROUND( Y0, Y1, Y2, Y3, X0, X1, X2, X3 );
AES_FROUND( X0, X1, X2, X3, Y0, Y1, Y2, Y3 );
AES_FROUND( t.Y[0], t.Y[1], t.Y[2], t.Y[3], t.X[0], t.X[1], t.X[2], t.X[3] );
AES_FROUND( t.X[0], t.X[1], t.X[2], t.X[3], t.Y[0], t.Y[1], t.Y[2], t.Y[3] );
}
AES_FROUND( Y0, Y1, Y2, Y3, X0, X1, X2, X3 );
AES_FROUND( t.Y[0], t.Y[1], t.Y[2], t.Y[3], t.X[0], t.X[1], t.X[2], t.X[3] );
X0 = *RK++ ^ \
( (uint32_t) FSb[ ( Y0 ) & 0xFF ] ) ^
( (uint32_t) FSb[ ( Y1 >> 8 ) & 0xFF ] << 8 ) ^
( (uint32_t) FSb[ ( Y2 >> 16 ) & 0xFF ] << 16 ) ^
( (uint32_t) FSb[ ( Y3 >> 24 ) & 0xFF ] << 24 );
t.X[0] = *RK++ ^ \
( (uint32_t) FSb[ ( t.Y[0] ) & 0xFF ] ) ^
( (uint32_t) FSb[ ( t.Y[1] >> 8 ) & 0xFF ] << 8 ) ^
( (uint32_t) FSb[ ( t.Y[2] >> 16 ) & 0xFF ] << 16 ) ^
( (uint32_t) FSb[ ( t.Y[3] >> 24 ) & 0xFF ] << 24 );
X1 = *RK++ ^ \
( (uint32_t) FSb[ ( Y1 ) & 0xFF ] ) ^
( (uint32_t) FSb[ ( Y2 >> 8 ) & 0xFF ] << 8 ) ^
( (uint32_t) FSb[ ( Y3 >> 16 ) & 0xFF ] << 16 ) ^
( (uint32_t) FSb[ ( Y0 >> 24 ) & 0xFF ] << 24 );
t.X[1] = *RK++ ^ \
( (uint32_t) FSb[ ( t.Y[1] ) & 0xFF ] ) ^
( (uint32_t) FSb[ ( t.Y[2] >> 8 ) & 0xFF ] << 8 ) ^
( (uint32_t) FSb[ ( t.Y[3] >> 16 ) & 0xFF ] << 16 ) ^
( (uint32_t) FSb[ ( t.Y[0] >> 24 ) & 0xFF ] << 24 );
X2 = *RK++ ^ \
( (uint32_t) FSb[ ( Y2 ) & 0xFF ] ) ^
( (uint32_t) FSb[ ( Y3 >> 8 ) & 0xFF ] << 8 ) ^
( (uint32_t) FSb[ ( Y0 >> 16 ) & 0xFF ] << 16 ) ^
( (uint32_t) FSb[ ( Y1 >> 24 ) & 0xFF ] << 24 );
t.X[2] = *RK++ ^ \
( (uint32_t) FSb[ ( t.Y[2] ) & 0xFF ] ) ^
( (uint32_t) FSb[ ( t.Y[3] >> 8 ) & 0xFF ] << 8 ) ^
( (uint32_t) FSb[ ( t.Y[0] >> 16 ) & 0xFF ] << 16 ) ^
( (uint32_t) FSb[ ( t.Y[1] >> 24 ) & 0xFF ] << 24 );
X3 = *RK++ ^ \
( (uint32_t) FSb[ ( Y3 ) & 0xFF ] ) ^
( (uint32_t) FSb[ ( Y0 >> 8 ) & 0xFF ] << 8 ) ^
( (uint32_t) FSb[ ( Y1 >> 16 ) & 0xFF ] << 16 ) ^
( (uint32_t) FSb[ ( Y2 >> 24 ) & 0xFF ] << 24 );
t.X[3] = *RK++ ^ \
( (uint32_t) FSb[ ( t.Y[3] ) & 0xFF ] ) ^
( (uint32_t) FSb[ ( t.Y[0] >> 8 ) & 0xFF ] << 8 ) ^
( (uint32_t) FSb[ ( t.Y[1] >> 16 ) & 0xFF ] << 16 ) ^
( (uint32_t) FSb[ ( t.Y[2] >> 24 ) & 0xFF ] << 24 );
PUT_UINT32_LE( X0, output, 0 );
PUT_UINT32_LE( X1, output, 4 );
PUT_UINT32_LE( X2, output, 8 );
PUT_UINT32_LE( X3, output, 12 );
PUT_UINT32_LE( t.X[0], output, 0 );
PUT_UINT32_LE( t.X[1], output, 4 );
PUT_UINT32_LE( t.X[2], output, 8 );
PUT_UINT32_LE( t.X[3], output, 12 );
mbedtls_platform_zeroize( &X0, sizeof( X0 ) );
mbedtls_platform_zeroize( &X1, sizeof( X1 ) );
mbedtls_platform_zeroize( &X2, sizeof( X2 ) );
mbedtls_platform_zeroize( &X3, sizeof( X3 ) );
mbedtls_platform_zeroize( &Y0, sizeof( Y0 ) );
mbedtls_platform_zeroize( &Y1, sizeof( Y1 ) );
mbedtls_platform_zeroize( &Y2, sizeof( Y2 ) );
mbedtls_platform_zeroize( &Y3, sizeof( Y3 ) );
mbedtls_platform_zeroize( &RK, sizeof( RK ) );
mbedtls_platform_zeroize( &t, sizeof( t ) );
return( 0 );
}
@ -947,63 +939,56 @@ int mbedtls_internal_aes_decrypt( mbedtls_aes_context *ctx,
unsigned char output[16] )
{
int i;
uint32_t *RK, X0, X1, X2, X3, Y0, Y1, Y2, Y3;
uint32_t *RK = ctx->rk;
struct
{
uint32_t X[4];
uint32_t Y[4];
} t;
RK = ctx->rk;
GET_UINT32_LE( X0, input, 0 ); X0 ^= *RK++;
GET_UINT32_LE( X1, input, 4 ); X1 ^= *RK++;
GET_UINT32_LE( X2, input, 8 ); X2 ^= *RK++;
GET_UINT32_LE( X3, input, 12 ); X3 ^= *RK++;
GET_UINT32_LE( t.X[0], input, 0 ); t.X[0] ^= *RK++;
GET_UINT32_LE( t.X[1], input, 4 ); t.X[1] ^= *RK++;
GET_UINT32_LE( t.X[2], input, 8 ); t.X[2] ^= *RK++;
GET_UINT32_LE( t.X[3], input, 12 ); t.X[3] ^= *RK++;
for( i = ( ctx->nr >> 1 ) - 1; i > 0; i-- )
{
AES_RROUND( Y0, Y1, Y2, Y3, X0, X1, X2, X3 );
AES_RROUND( X0, X1, X2, X3, Y0, Y1, Y2, Y3 );
AES_RROUND( t.Y[0], t.Y[1], t.Y[2], t.Y[3], t.X[0], t.X[1], t.X[2], t.X[3] );
AES_RROUND( t.X[0], t.X[1], t.X[2], t.X[3], t.Y[0], t.Y[1], t.Y[2], t.Y[3] );
}
AES_RROUND( Y0, Y1, Y2, Y3, X0, X1, X2, X3 );
AES_RROUND( t.Y[0], t.Y[1], t.Y[2], t.Y[3], t.X[0], t.X[1], t.X[2], t.X[3] );
X0 = *RK++ ^ \
( (uint32_t) RSb[ ( Y0 ) & 0xFF ] ) ^
( (uint32_t) RSb[ ( Y3 >> 8 ) & 0xFF ] << 8 ) ^
( (uint32_t) RSb[ ( Y2 >> 16 ) & 0xFF ] << 16 ) ^
( (uint32_t) RSb[ ( Y1 >> 24 ) & 0xFF ] << 24 );
t.X[0] = *RK++ ^ \
( (uint32_t) RSb[ ( t.Y[0] ) & 0xFF ] ) ^
( (uint32_t) RSb[ ( t.Y[3] >> 8 ) & 0xFF ] << 8 ) ^
( (uint32_t) RSb[ ( t.Y[2] >> 16 ) & 0xFF ] << 16 ) ^
( (uint32_t) RSb[ ( t.Y[1] >> 24 ) & 0xFF ] << 24 );
X1 = *RK++ ^ \
( (uint32_t) RSb[ ( Y1 ) & 0xFF ] ) ^
( (uint32_t) RSb[ ( Y0 >> 8 ) & 0xFF ] << 8 ) ^
( (uint32_t) RSb[ ( Y3 >> 16 ) & 0xFF ] << 16 ) ^
( (uint32_t) RSb[ ( Y2 >> 24 ) & 0xFF ] << 24 );
t.X[1] = *RK++ ^ \
( (uint32_t) RSb[ ( t.Y[1] ) & 0xFF ] ) ^
( (uint32_t) RSb[ ( t.Y[0] >> 8 ) & 0xFF ] << 8 ) ^
( (uint32_t) RSb[ ( t.Y[3] >> 16 ) & 0xFF ] << 16 ) ^
( (uint32_t) RSb[ ( t.Y[2] >> 24 ) & 0xFF ] << 24 );
X2 = *RK++ ^ \
( (uint32_t) RSb[ ( Y2 ) & 0xFF ] ) ^
( (uint32_t) RSb[ ( Y1 >> 8 ) & 0xFF ] << 8 ) ^
( (uint32_t) RSb[ ( Y0 >> 16 ) & 0xFF ] << 16 ) ^
( (uint32_t) RSb[ ( Y3 >> 24 ) & 0xFF ] << 24 );
t.X[2] = *RK++ ^ \
( (uint32_t) RSb[ ( t.Y[2] ) & 0xFF ] ) ^
( (uint32_t) RSb[ ( t.Y[1] >> 8 ) & 0xFF ] << 8 ) ^
( (uint32_t) RSb[ ( t.Y[0] >> 16 ) & 0xFF ] << 16 ) ^
( (uint32_t) RSb[ ( t.Y[3] >> 24 ) & 0xFF ] << 24 );
X3 = *RK++ ^ \
( (uint32_t) RSb[ ( Y3 ) & 0xFF ] ) ^
( (uint32_t) RSb[ ( Y2 >> 8 ) & 0xFF ] << 8 ) ^
( (uint32_t) RSb[ ( Y1 >> 16 ) & 0xFF ] << 16 ) ^
( (uint32_t) RSb[ ( Y0 >> 24 ) & 0xFF ] << 24 );
t.X[3] = *RK++ ^ \
( (uint32_t) RSb[ ( t.Y[3] ) & 0xFF ] ) ^
( (uint32_t) RSb[ ( t.Y[2] >> 8 ) & 0xFF ] << 8 ) ^
( (uint32_t) RSb[ ( t.Y[1] >> 16 ) & 0xFF ] << 16 ) ^
( (uint32_t) RSb[ ( t.Y[0] >> 24 ) & 0xFF ] << 24 );
PUT_UINT32_LE( X0, output, 0 );
PUT_UINT32_LE( X1, output, 4 );
PUT_UINT32_LE( X2, output, 8 );
PUT_UINT32_LE( X3, output, 12 );
PUT_UINT32_LE( t.X[0], output, 0 );
PUT_UINT32_LE( t.X[1], output, 4 );
PUT_UINT32_LE( t.X[2], output, 8 );
PUT_UINT32_LE( t.X[3], output, 12 );
mbedtls_platform_zeroize( &X0, sizeof( X0 ) );
mbedtls_platform_zeroize( &X1, sizeof( X1 ) );
mbedtls_platform_zeroize( &X2, sizeof( X2 ) );
mbedtls_platform_zeroize( &X3, sizeof( X3 ) );
mbedtls_platform_zeroize( &Y0, sizeof( Y0 ) );
mbedtls_platform_zeroize( &Y1, sizeof( Y1 ) );
mbedtls_platform_zeroize( &Y2, sizeof( Y2 ) );
mbedtls_platform_zeroize( &Y3, sizeof( Y3 ) );
mbedtls_platform_zeroize( &RK, sizeof( RK ) );
mbedtls_platform_zeroize( &t, sizeof( t ) );
return( 0 );
}

2
library/bignum.c
View file

@ -2101,7 +2101,7 @@ int mbedtls_mpi_exp_mod( mbedtls_mpi *X, const mbedtls_mpi *A,
size_t i, j, nblimbs;
size_t bufsize, nbits;
mbedtls_mpi_uint ei, mm, state;
mbedtls_mpi RR, T, W[ 2 << MBEDTLS_MPI_WINDOW_SIZE ], Apos;
mbedtls_mpi RR, T, W[ 1 << MBEDTLS_MPI_WINDOW_SIZE ], Apos;
int neg;
MPI_VALIDATE_RET( X != NULL );

2
library/ccm.c
View file

@ -175,7 +175,7 @@ static int ccm_auth_crypt( mbedtls_ccm_context *ctx, int mode, size_t length,
if( iv_len < 7 || iv_len > 13 )
return( MBEDTLS_ERR_CCM_BAD_INPUT );
if( add_len > 0xFF00 )
if( add_len >= 0xFF00 )
return( MBEDTLS_ERR_CCM_BAD_INPUT );
q = 16 - 1 - (unsigned char) iv_len;

72
library/check_crypto_config.h Normal file
View file

@ -0,0 +1,72 @@
/**
* \file check_crypto_config.h
*
* \brief Consistency checks for PSA configuration options
*/
/*
* Copyright The Mbed TLS Contributors
* 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.
*/
/*
* It is recommended to include this file from your crypto_config.h
* in order to catch dependency issues early.
*/
#ifndef MBEDTLS_CHECK_CRYPTO_CONFIG_H
#define MBEDTLS_CHECK_CRYPTO_CONFIG_H
#if defined(PSA_WANT_ALG_DETERMINISTIC_ECDSA) && \
!( defined(PSA_WANT_KEY_TYPE_ECC_KEY_PAIR) || \
defined(PSA_WANT_KEY_TYPE_ECC_PUBLIC_KEY) )
#error "PSA_WANT_ALG_DETERMINISTIC_ECDSA defined, but not all prerequisites"
#endif
#if defined(PSA_WANT_ALG_ECDSA) && \
!( defined(PSA_WANT_KEY_TYPE_ECC_KEY_PAIR) || \
defined(PSA_WANT_KEY_TYPE_ECC_PUBLIC_KEY) )
#error "PSA_WANT_ALG_ECDSA defined, but not all prerequisites"
#endif
#if defined(PSA_WANT_ALG_RSA_PKCS1V15_CRYPT) && \
!( defined(PSA_WANT_KEY_TYPE_RSA_KEY_PAIR) || \
defined(PSA_WANT_KEY_TYPE_RSA_PUBLIC_KEY) )
#error "PSA_WANT_ALG_RSA_PKCS1V15_CRYPT defined, but not all prerequisites"
#endif
#if defined(PSA_WANT_ALG_RSA_PKCS1V15_SIGN) && \
!( defined(PSA_WANT_KEY_TYPE_RSA_KEY_PAIR) || \
defined(PSA_WANT_KEY_TYPE_RSA_PUBLIC_KEY) )
#error "PSA_WANT_ALG_RSA_PKCS1V15_SIGN defined, but not all prerequisites"
#endif
#if defined(PSA_WANT_ALG_RSA_OAEP) && \
!( defined(PSA_WANT_KEY_TYPE_RSA_KEY_PAIR) || \
defined(PSA_WANT_KEY_TYPE_RSA_PUBLIC_KEY) )
#error "PSA_WANT_ALG_RSA_OAEP defined, but not all prerequisites"
#endif
#if defined(PSA_WANT_ALG_RSA_PSS) && \
!( defined(PSA_WANT_KEY_TYPE_RSA_KEY_PAIR) || \
defined(PSA_WANT_KEY_TYPE_RSA_PUBLIC_KEY) )
#error "PSA_WANT_ALG_RSA_PSS defined, but not all prerequisites"
#endif
#if defined(PSA_WANT_KEY_TYPE_ECC_KEY_PAIR) && \
!defined(PSA_WANT_KEY_TYPE_ECC_PUBLIC_KEY)
#error "PSA_WANT_KEY_TYPE_ECC_KEY_PAIR defined, but not all prerequisites"
#endif
#endif /* MBEDTLS_CHECK_CRYPTO_CONFIG_H */

20
library/cipher_wrap.c
View file

@ -753,7 +753,7 @@ static const mbedtls_cipher_info_t camellia_128_ecb_info = {
MBEDTLS_MODE_ECB,
128,
"CAMELLIA-128-ECB",
16,
0,
0,
16,
&camellia_info
@ -764,7 +764,7 @@ static const mbedtls_cipher_info_t camellia_192_ecb_info = {
MBEDTLS_MODE_ECB,
192,
"CAMELLIA-192-ECB",
16,
0,
0,
16,
&camellia_info
@ -775,7 +775,7 @@ static const mbedtls_cipher_info_t camellia_256_ecb_info = {
MBEDTLS_MODE_ECB,
256,
"CAMELLIA-256-ECB",
16,
0,
0,
16,
&camellia_info
@ -1129,7 +1129,7 @@ static const mbedtls_cipher_info_t aria_128_ecb_info = {
MBEDTLS_MODE_ECB,
128,
"ARIA-128-ECB",
16,
0,
0,
16,
&aria_info
@ -1140,7 +1140,7 @@ static const mbedtls_cipher_info_t aria_192_ecb_info = {
MBEDTLS_MODE_ECB,
192,
"ARIA-192-ECB",
16,
0,
0,
16,
&aria_info
@ -1151,7 +1151,7 @@ static const mbedtls_cipher_info_t aria_256_ecb_info = {
MBEDTLS_MODE_ECB,
256,
"ARIA-256-ECB",
16,
0,
0,
16,
&aria_info
@ -1553,7 +1553,7 @@ static const mbedtls_cipher_info_t des_ecb_info = {
MBEDTLS_MODE_ECB,
MBEDTLS_KEY_LENGTH_DES,
"DES-ECB",
8,
0,
0,
8,
&des_info
@ -1604,7 +1604,7 @@ static const mbedtls_cipher_info_t des_ede_ecb_info = {
MBEDTLS_MODE_ECB,
MBEDTLS_KEY_LENGTH_DES_EDE,
"DES-EDE-ECB",
8,
0,
0,
8,
&des_ede_info
@ -1655,7 +1655,7 @@ static const mbedtls_cipher_info_t des_ede3_ecb_info = {
MBEDTLS_MODE_ECB,
MBEDTLS_KEY_LENGTH_DES_EDE3,
"DES-EDE3-ECB",
8,
0,
0,
8,
&des_ede3_info
@ -1770,7 +1770,7 @@ static const mbedtls_cipher_info_t blowfish_ecb_info = {
MBEDTLS_MODE_ECB,
128,
"BLOWFISH-ECB",
8,
0,
MBEDTLS_CIPHER_VARIABLE_KEY_LEN,
8,
&blowfish_info

2
library/cmac.c
View file

@ -420,7 +420,7 @@ exit:
*/
int mbedtls_aes_cmac_prf_128( const unsigned char *key, size_t key_length,
const unsigned char *input, size_t in_len,
unsigned char *output )
unsigned char output[16] )
{
int ret = MBEDTLS_ERR_ERROR_CORRUPTION_DETECTED;
const mbedtls_cipher_info_t *cipher_info;

5
library/ecp.c
View file

@ -546,8 +546,11 @@ static const mbedtls_ecp_curve_info ecp_supported_curves[] =
#if defined(MBEDTLS_ECP_DP_SECP192K1_ENABLED)
{ MBEDTLS_ECP_DP_SECP192K1, 18, 192, "secp192k1" },
#endif
#if defined(MBEDTLS_ECP_DP_CURVE25519_ENABLED) && defined(MBEDTLS_ECDH_VARIANT_EVEREST_ENABLED)
#if defined(MBEDTLS_ECP_DP_CURVE25519_ENABLED)
{ MBEDTLS_ECP_DP_CURVE25519, 29, 256, "x25519" },
#endif
#if defined(MBEDTLS_ECP_DP_CURVE448_ENABLED)
{ MBEDTLS_ECP_DP_CURVE448, 30, 448, "x448" },
#endif
{ MBEDTLS_ECP_DP_NONE, 0, 0, NULL },
};

2
library/entropy_poll.c
View file

@ -17,7 +17,7 @@
* limitations under the License.
*/
#if defined(__linux__)
#if defined(__linux__) && !defined(_GNU_SOURCE)
/* Ensure that syscall() is available even when compiling with -std=c99 */
#define _GNU_SOURCE
#endif

18
library/error.c
View file

@ -19,20 +19,20 @@
#include "common.h"
#if defined(MBEDTLS_ERROR_STRERROR_DUMMY)
#include <string.h>
#endif
#include "mbedtls/error.h"
#if defined(MBEDTLS_ERROR_C) || defined(MBEDTLS_ERROR_STRERROR_DUMMY)
#if defined(MBEDTLS_ERROR_C)
#if defined(MBEDTLS_PLATFORM_C)
#include "mbedtls/platform.h"
#else
#define mbedtls_snprintf snprintf
#define mbedtls_time_t time_t
#endif
#if defined(MBEDTLS_ERROR_C)
#include <stdio.h>
#include <string.h>
#if defined(MBEDTLS_AES_C)
#include "mbedtls/aes.h"
@ -960,8 +960,6 @@ void mbedtls_strerror( int ret, char *buf, size_t buflen )
#else /* MBEDTLS_ERROR_C */
#if defined(MBEDTLS_ERROR_STRERROR_DUMMY)
/*
* Provide an non-function in case MBEDTLS_ERROR_C is not defined
*/
@ -973,6 +971,6 @@ void mbedtls_strerror( int ret, char *buf, size_t buflen )
buf[0] = '\0';
}
#endif /* MBEDTLS_ERROR_STRERROR_DUMMY */
#endif /* MBEDTLS_ERROR_C */
#endif /* MBEDTLS_ERROR_C || MBEDTLS_ERROR_STRERROR_DUMMY */

6
library/md.c
View file

@ -411,6 +411,10 @@ int mbedtls_md_setup( mbedtls_md_context_t *ctx, const mbedtls_md_info_t *md_inf
if( md_info == NULL || ctx == NULL )
return( MBEDTLS_ERR_MD_BAD_INPUT_DATA );
ctx->md_info = md_info;
ctx->md_ctx = NULL;
ctx->hmac_ctx = NULL;
switch( md_info->type )
{
#if defined(MBEDTLS_MD2_C)
@ -466,8 +470,6 @@ int mbedtls_md_setup( mbedtls_md_context_t *ctx, const mbedtls_md_info_t *md_inf
}
}
ctx->md_info = md_info;
return( 0 );
}
#undef ALLOC

Some files were not shown because too many files have changed in this diff Show more