Entries in ChangeLog and Migration guide files
have been merged to cover both the removal of
MBEDTLS_SSL_TRUNCATED_HMAC and
MBEDTLS_SSL_TRUNCATED_HMAC_COMPAT.
Signed-off-by: Thomas Daubney <thomas.daubney@arm.com>
For TLS, secp256k1 is deprecated by RFC 8422 §5.1.1. For X.509,
secp256k1 is not deprecated, but it isn't used in practice, especially
in the context of TLS where there isn't much point in having an X.509
certificate which most peers do not support. So remove it from the
default profile. We can add it back later if there is demand.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Meld the migration guide for the removal of
MBEDTLS_TLS_DEFAULT_ALLOW_SHA1_IN_CERTIFICATES into the migration guide for
the strengthening of TLS and X.509 defaults, which is more general. The
information in the SHA-1 section was largely already present in the
strengthening section. It is now less straightforward to figure out how to
enable SHA-1 in certificates, but that's a good thing, since no one should
still be doing this in 2021.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
TLS used to prefer larger curves, under the idea that a larger curve has a
higher security strength and is therefore harder to attack. However, brute
force attacks are not a practical concern, so this was not particularly
meaningful. If a curve is considered secure enough to be allowed, then we
might as well use it.
So order curves by resource usage. The exact definition of what this means
is purposefully left open. It may include criteria such as performance and
memory usage. Risk of side channels could be a factor as well, although it
didn't affect the current choice.
The current list happens to exactly correspond to the numbers reported by
one run of the benchmark program for "full handshake/s" on my machine.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Merge part of the RSA entries into this one, as I think it's easier for
users to have all similar changes in one place regardless of whether
they were introduce in the same PR or not.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
library/ecp_alt.h (declaring individual functions of the ECP module that can
be substituted, included when building the library with
MBEDTLS_ECP_INTERNAL_ALT enabled) clashes with ecp_alt.h (not provided,
declaring types of the ECP module when the whole implementation is
substituted, included when building the library with MBEDTLS_ECP_ALT enabled).
Depending on the search path during build, this can make MBEDTLS_ECP_ALT
unusable.
Rename library/ecp_alt.h to follow the naming convention of other alt headers:
MBEDTLS_XXX_ALT corresponds to xxx_alt.h.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This commit fixes typos and re-words
the migration guide. It also adds
the issue number to the ChangeLog.
Signed-off-by: Thomas Daubney <thomas.daubney@arm.com>
Conflicts:
library/version_features.c
programs/test/query_config.c
Files were removed in development branch and modified by current branch.
Conflicts fixes by removing them.
The output parameter of mbedtls_sha256_finish_ret and mbedtls_sha256_ret
now has a pointer type rather than array type. This removes spurious
warnings in some compilers when outputting a SHA-224 hash into a
28-byte buffer.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The output parameter of mbedtls_sha512_finish_ret and mbedtls_sha512_ret
now has a pointer type rather than array type. This removes spurious
warnings in some compilers when outputting a SHA-384 hash into a
48-byte buffer.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
For now the entries are in no particular order. Before the release we
should have a final pass over this document and order them from most
impactful to least impactful. We might even create sections, a table of
contents, etc.
In the meantime, each PR should add an entry about it changes.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Add implementation for MBEDTLS_PSA_CRYPTO_BUILTIN_KEYS
Merging as it has been ready for four days now and I prefer not having to go through other rebases especially given the coming change of scope of development (3.0 rather than 2.2x).
Specifically allow the driver to override the persistency level of a
builtin key in cases where the driver is persistency-aware.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
Time stamps are useful when the document gets shared around, but they
tend to lead to merge conflicts.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Add architecture document explaining how this
PR aim to restructure the PSA implementation (only
part of it) and why.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
While builtin keys will often have a fixed-size context, this is not
necessarily the case, so the "get_builtin_key" entry point needs to
return the size of the actual key context.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Initial revision.
Save-compare-load approach: the test case data contains attributes of
the object under test and the expected file content. Create the
object, save it, check that the file has the expected content, load
the file and check that the new object has the expected attributes.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
If a random driver has a built-in entropy source and doesn't need an
external entropy source, make the driver author declare this
explicitly, rather than it being a less secure default.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The get_random entry point was allowed to return partial data on both
PSA_SUCCESS and PSA_ERROR_INSUFFICIENT_ENTROPY, but there was no
meaningful difference between the two. Keep it simple: PSA_SUCCESS is
success but can be partial, and PSA_ERROR_INSUFFICIENT_ENTROPY is an
error with no output.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Explicitly recommend that the driver accounts for environmental
conditions that can affect the amount of entropy.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
A random generation driver does not need to support entropy injection.
This will limit it to platforms where the RNG peripheral is the sole
entropy source and without an RNG seed saved into persistent storage.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
If an RNG peripheral includes an entropy source, it would presumably
declare "initial_entropy_size" and "reseed_entropy_size" to be 0. In
this case, don't require the core to call "add_entropy".
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The `get_entropy` entry point can be provided by multiple transparent
drivers, and the core will call all of them. But apart from that,
`get_entropy` doesn't involve an opaque key or a location, so it can
be in a transparent driver.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Transparent drivers may provide a DRBG interface through "add_entropy"
and "get_random" entry points. This interface may also be used with a
non-deterministic generator, for chips that include a TRNG.
Opaque driver may provide a "get_entropy" entry point.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Allow the core to call the "get_builtin_key" entry point to retrieve
the attributes of a built-in key. This is useful to implement
psa_get_key_attributes(), and also when the key data buffer's size
depends on the key type and size.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Having a time stamp identifying each revision of the document is
useful, but it's also a pain because it creates a conflict whenever
there are multiple pending changes at the same time. The gain isn't
worth the pain, so I'm removing the time stamp.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The driver interfaces described in crypto_accel_driver.h and
crypto_entropy_driver.h are no longer being worked on. We do not
intend to finish the design of these interfaces or to implement them
in Mbed TLS. They have been superseded by the unified driver
interface (docs/proposed/psa-driver-interface.md), which is being
actively worked on both to finalize the specification and to implement
it in Mbed TLS.
The partially implemented dynamic secure element interface is staying
for now.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Rework the section describing key import, in particular to clarify key
size determination and checking. There is no intended semantic change.
Note an open question around support for implementation-specific
import formats.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
PSA_WANT_xxx is useful regardless of how the symbols are defined:
explicitly (with MBEDTLS_PSA_CRYPTO_CONFIG) or implicitly (without
MBEDTLS_PSA_CRYPTO_CONFIG).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Move all the PSA crypto APIs using key handles
to use key identifiers but psa_key_open() and
psa_key_close(). This is done without modifying
any test as key handles and key identifiers are
now the same.
Update the library modules using PSA crypto APIs
to get rid of key handles.
Programs and unit tests are updated to not use
key handles in subsequent commits, not in this
one.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Now that transparent drivers have an "import_key" entry point, the key
creation interfaces for transparent drivers and opaque drivers are
very similar. Unify the sections that describe their behavior,
including key validation and key size determination.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
When importing a transparent key, the key needs to be not only
validated, but also possibly converted, if it is not already in the
canonical representation. So change the validate_key entry point to an
import_key entry point.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Without MBEDTLS_PSA_CRYPTO_CONFIG, PSA_WANT_xxx needs to be defined,
for the sake of code that calls the PSA API (TLS code, tests, sample
apps).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
* Stores bits in psa_persistent_key_storage_format.
* psa_load_persistent_key_into_slot still imports plaintext keys which
ensures that the bits value gets set.
* Updates key specification to match new implementation.
* Expands persistent store and load tests with to check for bits
attribute.
* Removes bits storage from psa_se_key_data_storage_t.
Signed-off-by: Torstein Nesse <torstein.nesse@silabs.com>
When importing a key, the code that parses the input needs to
determine the key size ("bits" attribute). This is specific to import
since other key creation methods require the caller to supply a size.
Therefore, add an extra output parameter `bits` to the "import_key"
entry point for opaque drivers. Likewise, add a `bits` output
parameter to the "validate_key" entry point for transparent drivers.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
With PSA crypto v1.0.0, a volatile key identifier may
contain a owner identifier but no file is associated
to it. Thus rename the type psa_key_file_id_t to
mbedtls_svc_key_id_t to avoid a direct link with a
file when a key identifier involves an owner
identifier.
The new type name is prefixed by mbedtls to highlight
that the type is specific to Mbed TLS implementation
and not defined in the PSA Cryptography API
specification.
The svc in the type name stands for service as this
is the key identifier type from the point of view of
the service providing the Cryptography services.
The service can be completely provided by the present
library or partially in case of a multi-client service.
As a consequence rename as well:
. MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER to
MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER
. PSA_KEY_ID_INIT to MBEDTLS_SVC_KEY_ID_INIT
. PSA_KEY_FILE_GET_KEY_ID to MBEDTLS_SVC_KEY_ID_GET_KEY_ID
. psa_key_file_id_make to mbedtls_svc_key_id_make
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Proposed specification for conditional inclusion of cryptographic
mechanism through the PSA API in Mbed TLS.
The inclusion of a mechanism is based on a declaration of boolean
symbols by the application. There is a symbol for each key type or
parametrized key type constructor, and for each algorithm or
parametrized algorithm constructor.
This is work in progress, presented for a first design discussion.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
There is little point in leaving the order in which drivers are
considered unspecified. This gives flexibility to the implementation
for a process that is generally performed at build time, not in a
constrained environment. Having a well-defined order is especially
useful with fallback.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
It's ok if they map to the same function names and an error otherwise.
It's an error to have multiple opaque drivers for the same location.
If multiple transparent drivers apply, which one applies is unspecified.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The existing description of the syntax of capabilities also describes
the semantics of each property, but the semantics of the capability as
a whole is not immediately clear. Add a subsection that explains
precisely when a capability is applicable.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Inferring entry points from algorithms is nice in that it makes
capability specifications shorter and less redundant, but that's not
really important. It also makes capabilities more fragile: if the core
starts supporting new mechanisms based on the same algorithm (for
example, adding hash-and-sign when only sign-the-hash existed before),
a driver only supporting the old mechanisms would fail at build time.
So make entry points mandatory.
This has the benefit of making the semantics of capabilities easier to
describe.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Add the mention of key_derivation_output_key in the section about the
key derivation entry point family.
Rename "derive_key" to "key_derivation_output_key". At this point,
there's no reason to deviate from the naming convention.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Clarify some sentences. There is no change in intended meaning.
Fix typos. Change British spelling to American spelling.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Locations aren't in the official PSA API specification yet (they've
only be made public in Mbed TLS). Until version 1.0.1 of the API
specification is out, this document needs to explain locations.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
