- Some things that were indicated as in the near future are now done.
- Clarify when these macros are needed and when they're not.
- Prepare to make the header public.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Currently just replacing existing uses, but the real point of having
these conditions as a single macro is that we'll be able to use them in
tests case dependencies, see next commit.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Strategy for dependencies inside libmbecrypto, in particular in the PSA
Crypto core, are outside the scope of the present study.
Note: PR 6065, referenced in a few places, is the one that also
introduces the present commit. It kicks of the work towards G5 in parts
of the code governed by MBEDTLS_USE_PSA_CRYPTO.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
- lack of support for PSA_CRYPTO_CONFIG is not really a reason not to
enable MBEDTLS_USE_PSA_CRYPTO by default - while it's true that
currently X.509/TLS do not behave as expected when PSA_CRYPTO_CONFIG and
MBEDTLS_USE_PSA_CRYPTO are both enabled, it's no worse than when
MBEDTLS_USE_PSA_CRYPTO is disabled.
- as a consequence of removing the paragraph mentioned above, the
sub-section about PSA_CRYPTO_CONFIG no longer belongs in the
"compile-time option" section. Also, it's superseded by the study work
that happened in the meantime (of which this PR is part). So let's
remove it, and the new commit will add something more up-to-date
instead.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Not related to the changes in this PR, except in the next commit I'll
update the strategy document for changes in this PR and to outline
likely follow-ups, and while looking at the document I noticed a few
things that needed updated, so here there are in their own commit.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Note: limitations of opaque PSKs changed from "TLS 1.2 only" to "none"
since TLS 1.3 does not support PSK at all so far, and it is expected to
support opaque PSKs as soon as it gains PSK support, it will be just a
matter of selecting between psa_key_derivation_input_bytes() and
psa_key_derivation_input_key() - and testing obviously.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The scope of the option has been expanded, now it makes more sense to
describe it as "everything except ...".
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
It was initially motivated by the fact that the PSA Crypto APIs
themselves were not stable. In the meantime, PSA Crypto has reached
1.0.0 so this no longer applies.
If we want user to be able to fully benefit from PSA in order to
isolate long-term secrets, they need to be able to use the new APIs with
confidence. There is no reason to think those APIs are any more likely
to change than any of our other APIs, and if they do, we'll follow the
normal process (deprecated in favour of a new variant).
For reference, the APIs in question are:
mbedtls_pk_setup_opaque() // to use PSA-held ECDSA/RSA keys in TLS
mbedtls_ssl_conf_psk_opaque() // for PSA-held PSKs in TLS
mbedtls_ssl_set_hs_psk_opaque() // for PSA-held PSKs in TLS
mbedtls_cipher_setup_psa() (deprecated in 3.2)
mbedtls_pk_wrap_as_opaque() (documented internal, to be removed in 3.2)
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
- misc updates about on-going/recent work
- removal of the section about mixed-PSK: being done in #5762
- clarifications in some places
- some typo fixes
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The new function psa_crypto_driver_key_derivation_get_input_type() allows
drivers to retrieve the effective type of each input step, and thus to call
the correct get-data function. This is simpler than the previous scheme
which required a somewhat contrived dance with get_key() and get_bytes() for
inputs that can be passed either as a key or as a byte buffer at the
application's choice.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
We hadn't updated the storage specification in a while. There have been no
changes to the storage layout, but the details of the contents of some
fields have changed.
Since this is now a de facto stable format (unchanged between 2.25 and 3.2),
describe it fully, avoiding references to previous versions.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Also have check_config.h enforce this. And MBEDTLS_SSL_EXPORT_KEYS has been removed,
so no longer mention it.
Signed-off-by: Tom Cosgrove <tom.cosgrove@arm.com>
Add a check list with what typically needs to be done when adding a new
algorithm, key type or operation. There are a few explanations but this is
primarily intended as a list of places to look and not as a detailed
explanation of exactly what to do.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Remaining hits seem to be hex data, certificates,
and other miscellaneous exceptions.
List generated by running codespell -w -L
keypair,Keypair,KeyPair,keyPair,ciph,nd
Signed-off-by: Andrzej Kurek <andrzej.kurek@arm.com>
There are two somewhat distinct aspects here: if it compiled, it still
compiles; and if it worked functionally, it still works. They're related in
that if application code currently compiles but cannot possibly work, we
could reasonably make it not compile anymore.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The dependencies-xxx.md documents where merely a support for study,
now distilled to strategy.md, psa-limitation.md, and tasks-xx.md
and/or github issues.
The tasks-g1.md document has now been fully converted to a list of
github issues.
These documents would quickly become out-of-date and there's little
point in updating them, so it's better to remove them. They're still in
the github history if anyone wants to have a look.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Don't use “output” for an input of the KDF. It's correct in context (it's
the output of a function that copies the input of the KDF from core-owned
memory to driver-owned memory) but confusing.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Pass all the initial inputs in a single structure. It's impossible to pass
the inputs as soon as the application makes them available because the core
cannot know which driver to call until it receives the SECRET input.
Do support hiding the key material inside a secure element if the relevant
driver has all the requisite entry points.
Do cooked key derivation (i.e. derivation of non-raw keys) and key agreement
separately.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Replace descriptions with links just to double-check nothing has been
forgotten.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
- fix inaccuracy about PSA hash implementation
- add note about context-less operations
- provide summary
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Data gathered with:
for c in server9*.crt; do echo $c; openssl x509 -noout -text -in $c |
grep '^ Signature Algorithm: rsassaPss' -A3 | sed '1d'; done
for c in crl-rsa-pss-*; do echo $c; openssl crl -noout -text -in $c |
grep '^ Signature Algorithm: rsassaPss' -A3 | sed '1d'; done
for c in server9.req.*; do echo $c; openssl req -noout -text -in $c |
grep '^ Signature Algorithm: rsassaPss' -A3 | sed '1d'; done
Unfortunately there is no record of how these files have been generated.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Work in progress, some tasks have very explicit definitions and details
on how to execute, others much less so; some may need splitting.
These documents are temporary anyway, to give a rough idea of the work
remaining to reach those goals (both of which we started, but only for
some use case so far). Ultimately the result will be actionable and
estimated tasks on github.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Note: removed `mbedtls_x509write_crt_set_subject_key()` from the list of
things that should be tested, as it's taking public key rather than a
keypair.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This is an updated version of the study that was done a few years ago.
The script `syms` was used to list symbols form libmbedtls.a /
libmbedx509.a that are defined externally. It was run with config.py
full minus MBEDTLS_USE_PSA_CRYPTO minus
MBEDTLS_SSL_PROTO_TLS1_3_EXPERIMENTAL.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Moved python script generate_driver_wrappers.py under scripts and
corresponding template file under script/data_files.
Signed-off-by: Archana <archana.madhavan@silabs.com>
TLS1.3 MVP would benefit from a different curve group preference order
in order to not cause a HelloRetryRequest (which are not yet handled),
however changing the curve group preference order would affect both
TLS1.2 and TLS1.3, which is undesirable for something rare that can
be worked around.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Section 9.2 of the specification defines server_name
extension as mandatory if not specified otherwise by
an application profile. Thus add its support to the
MVP scope.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Don't mention "TLS 1.2 only" for PSK, as that could give the impression
that the other things about TLS are supported beyond 1.2, which isn't
the case currently.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The section is about things that are not covered, but some lists are
about things that are covered, which was very confusing.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Also, remove the section about design considerations for now. It's
probably more suitable for a developer-oriented document that would also
include considerations about possible paths for the future, which would
better be separated from user documentation (separating the certain that
is now, from the uncertain that might or might not be later).
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
What matters is that we validate that test data is not removed. Keeping the
test data is the most obvious way, but not the only way.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The import-and-save and load-and-check parts of the tests don't have to be
actually the same test cases.
Introduce the terms “forward compatibility” and “backward compatibility” and
relate them to import-and-save and load-and-check actions.
These are clarifications of intent that do not represent an intended change
in the strategy or intended coverage.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
