- Add `alg` and `computation_stage` to `psa_pake_operation_s`.
Now when logic is moved to core information about `alg` is required.
`computation_stage` is a structure that provides a union of computation stages for pake algorithms.
- Move the jpake operation logic from driver to core. This requires changing driver entry points for `psa_pake_output`/`psa_pake_input` functions and adding a `computation_stage` parameter. I'm not sure if this solution is correct. Now the driver can check the current computation stage and perform some action. For jpake drivers `step` parameter is now not used, but I think it needs to stay as it might be needed for other pake algorithms.
- Removed test that seems to be redundant as we can't be sure that operation is aborted after failure.
Signed-off-by: Przemek Stekiel <przemyslaw.stekiel@mobica.com>
If an error occurs, calling any function on the same operation should return
PSA_ERROR_BAD_STATE, and we were not honouring that for all errors. Add extra
failure tests to try and ratify this.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
For sign and verify, the pointer passed in to the hash is not guaranteed to
remain valid inbetween calls, thus we need to store the hash in the
operation. Added a test to ensure this is the case.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Make it clear that these functions reset the number of ops, and remove
statements that say they have no effect.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Also make previous changes apply to both interruptible sign hash operation
structures rather than just the one as it was.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Move to accumulate ops in context rather than attempting to read straight out
of structures due to structure ops getting reset per operation, and also
issues with _abort clearing internal data. Fix usage of size_t in structures
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Pacify Clang >=15 which complained:
```
include/psa/crypto.h:91:23: error: empty paragraph passed to '\retval' command [-Werror,-Wdocumentation]
* \retval #PSA_SUCCESS
~~~~~~~~~~~~~~~~~~~^
```
This commit performs the following systematic replacement:
```
perl -i -0777 -p -e 's/([\\@])(retval +\S+)\n(?! *\*? *([^\n \\*\/]|\\[cp]\b))/$1$2 ${1}emptydescription\n/g' $(git ls-files '*.[hc]' '*.function' '*.jinja')
```
i.e. add an `\emptydescription` argument to `\retval` commands (or
`@retval`, which we don't normally used) that are followed by a single word,
unless the next line looks like it contains text which would be the
description.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Add PSA_WANT_KEY_TYPE_PASSWORD and PSA_WANT_KEY_TYPE_PASSWORD_HASH to
psa/crypto_config.h, since the types PSA_KEY_TYPE_PASSWORD and
PSA_KEY_TYPE_PASSWORD_HASH are used by ECJPAKE.
The two key types are always enabled, like PSA_KEY_TYPE_DERIVE.
Add the key types to the metadata test suite as well.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The following shell command lists features that seem to be supported, but
are missing from include/psa/crypto_config.h:
```
for x in $(grep -ho -Ew '(PSA_WANT|MBEDTLS_PSA_BUILTIN)_\w+_\w+' library/psa_crypto*.c | sed 's/^MBEDTLS_PSA_BUILTIN/PSA_WANT/' | sort -u); do grep -qw $x include/psa/crypto_config.h || echo $x; done
```
This looks for PSA_WANT_<kind>_<thing> macros that gate a part of the
library, as well as their MBEDTLS_PSA_BUILTIN_<kind>_<thing> counterparts.
This is not necessarily a complete list of identifiers that must appear
in the config file, since a few features are not gated.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Some preprocessor macro definitions must have a specific expansion so that
the same macro name can be defined in different products. The definition of
having the same expansion (per the C language specification) means the same
sequence of tokens, and also the same absence/presence of spacing between
tokens.
Two macros are also defined in headers in the PSA Compliance test suite, so
the test suite would fail to build if we changed the definitions. Preserve
those definitions. Technically this is a bug in the test suite, since having
extra spaces (or even a completely different constant expression with the
same value) would still be compliant. Bug reported as
https://github.com/ARM-software/psa-arch-tests/issues/337
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Some preprocessor macro definitions must have a specific expansion so that
the same macro name can be defined in different products. The definition of
having the same expansion (per the C language specification) means the same
sequence of tokens, and also the same absence/presence of spacing between
tokens.
For PSA error code definitions, the specific expansion is mandated by the
PSA Status code specification and the PSA Crypto API specification. In
particular, there must not be a space between (psa_status_t) and the
numerical value (whereas K&R would put a space).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Additionally use psa_get_and_lock_key_slot_with_policy() to obtain key.
This requires making this function public. This will have to be solved while adding driver dipatch for EC-JPAKE.
Signed-off-by: Przemek Stekiel <przemyslaw.stekiel@mobica.com>
Fix the PSA_XXX typos detected by check_names.py.
PSA_WANT is actually not typo, but would cause a false negative
result. So PSA_WANT is reworded to PSA_WANT_xxx.
Signed-off-by: Pengyu Lv <pengyu.lv@arm.com>
This macro is specific to the Mbed TLS implementation and not part of
the public API, so it shouldn't used the PSA_ namespace.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The format used by the mbedtls_ecjpake_xxx() APIs and that defined by
the PSA Crypto PAKE extension are quite different; the former is
tailored to the needs of TLS while the later is quite generic and plain.
Previously we only addressed some part of this impedance mismatch: the
different number of I/O rounds, but failed to address the part where the
legacy API adds some extras (length bytes, ECParameters) that shouldn't
be present in the PSA Crypto version. See comments in the code.
Add some length testing as well; would have caught the issue.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
TLS uses it to derive the session secret. The algorithm takes a serialized
point in an uncompressed form, extracts the X coordinate and computes
SHA256 of it. It is only expected to work with P-256.
Fixes#5978.
Signed-off-by: Andrzej Kurek <andrzej.kurek@arm.com>
Certain numerical values are written to the key store. Changing those
numerical values would break the backward compatibility of stored keys. Add
a note to the affected types. Add comments near the definitions of affected
values.
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>
The accessor macros for key_id and owner_id in the mbedtls_svc_key_id_t
need to have the MBEDTLS_PRIVATE() specifier as these fields are private
Signed-off-by: Antonio de Angelis <antonio.deangelis@arm.com>
The cipher module implements XTS, and the PSA API specifies XTS, but the PSA
implementation does not support XTS. It requires double-size keys, which
psa_crypto does not currently support.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Perform the following optimizations:
- fix used flags for conditional compilation
- remove redundant N variable
- move loop used to generate valid k value to helper function
- fix initial value of status
- fix comments
Signed-off-by: Przemyslaw Stekiel <przemyslaw.stekiel@mobica.com>
Use PSA_BUILTIN macros instead of the Mbed TLS ones
as in the hash operation contexts the context for a
given hash is needed only if the support for it
through PSA is enabled.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
This commit removes the test_psa_crypto_config_basic
all.sh component that can no longer work without
adapting it to the separately compiled test driver
library. This component is replaced by several
components in the following commits to test various
type of acceleration independently.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
The PSA max hash size has to be 64 if SHA512 or
SHA384 is supported by the library or an
accelerator, not just in case of the library.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
static function mbedtls_set_key_owner() is declared in psa/crypto.h
and defined in psa/crypto_struct.h with different parameter name for
the mbedtls_key_owner_id_t parameter and that may trigger errors
from static code analysis tool as cppcheck.
Signed-off-by: Antonio de Angelis <antonio.deangelis@arm.com>
Move fields around to have fewer accesses outside the 128-element Thumb
direct access window.
In psa_hkdf_key_derivation_t, move the large fields (output_block, prk,
hmac) after the state bit-fields. Experimentally, it's slightly better
to put hmac last.
Other operations structures don't go outside the window, at least when not
considering nested structures.
Results (arm-none-eabi-gcc 7.3.1, build_arm_none_eabi_gcc_m0plus build):
library/psa_crypto.o: 16510 -> 16434 (diff: 76)
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Several files among include/psa/crypto_*.h are not meant to be included
directly, and are not guaranteed to be valid if included directly. This
makes it harder to perform some static analyses. So make these files more
self-contained so that at least, if included on their own, there is no
missing macro or type definition (excluding the deliberate use of forward
declarations of structs and unions).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The current definition of PSA_ALG_IS_HASH_AND_SIGN includes
PSA_ALG_RSA_PKCS1V15_SIGN_RAW and PSA_ALG_ECDSA_ANY, which don't strictly
follow the hash-and-sign paradigm: the algorithm does not encode a hash
algorithm that is applied prior to the signature step. The definition in
fact encompasses what can be used with psa_sign_hash/psa_verify_hash, so
it's the correct definition for PSA_ALG_IS_SIGN_HASH. Therefore this commit
moves definition of PSA_ALG_IS_HASH_AND_SIGN to PSA_ALG_IS_SIGN_HASH, and
replace the definition of PSA_ALG_IS_HASH_AND_SIGN by a correct one (based
on PSA_ALG_IS_SIGN_HASH, excluding the algorithms where the pre-signature
step isn't to apply the hash encoded in the algorithm).
In the definition of PSA_ALG_SIGN_GET_HASH, keep the condition for a nonzero
output to be PSA_ALG_IS_HASH_AND_SIGN.
Everywhere else in the code base (definition of PSA_ALG_IS_SIGN_MESSAGE, and
every use of PSA_ALG_IS_HASH_AND_SIGN outside of crypto_values.h), we meant
PSA_ALG_IS_SIGN_HASH where we wrote PSA_ALG_IS_HASH_AND_SIGN, so do a
global replacement.
```
git grep -l IS_HASH_AND_SIGN ':!include/psa/crypto_values.h' | xargs perl -i -pe 's/ALG_IS_HASH_AND_SIGN/ALG_IS_SIGN_HASH/g'
```
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This is a variant of PSA_ALG_RSA_PSS which currently has exactly the same
behavior, but is intended to have a different behavior when verifying
signatures.
In a subsequent commit, PSA_ALG_RSA_PSS will change to requiring the salt
length to be what it would produce when signing, as is currently documented,
whereas PSA_ALG_RSA_PSS_ANY_SALT will retain the current behavior of
allowing any salt length (including 0).
Changes in this commit:
* New algorithm constructor PSA_ALG_RSA_PSS_ANY_SALT.
* New predicates PSA_ALG_IS_RSA_PSS_STANDARD_SALT (corresponding to
PSA_ALG_RSA_PSS) and PSA_ALG_IS_RSA_PSS_ANY_SALT (corresponding to
PSA_ALG_RSA_PSS_ANY_SALT).
* Support for the new predicates in macro_collector.py (needed for
generate_psa_constant_names).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Also fiixed the following merge problems:
crypto_struct.h : Added MBEDTLS_PRIVATE to psa_aead_operation_s
members (merge conflict)
psa_crypto_aead.c : Added ciphertext_length to mbedtls_gcm_finish
call (change of API during development)
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Use the encoding from an upcoming version of the specification.
Add as much (or as little) testing as is currently present for Camellia.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Although checking if the key was symmetric was correct, its easier to
read if we just check the block length is not zero before we use it in a
division.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Enable Curve448 support
Add test vectors to evaluate
* RFC 7748
* a known-answer public key export test.
* a known-answer ECDH (X448) test.
Signed-off-by: Archana <archana.madhavan@silabs.com>
If PSA_CIPHER_ENCRYPT_OUTPUT_SIZE was called on a non symmetric key,
then a divide by zero could happen, as PSA_CIPHER_BLOCK_LENGTH will
return 0 for such a key, and PSA_ROUND_UP_TO_MULTIPLE will divide by the
block length.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Fix initialization of mbedtls_psa_cipher_operation_t by not initializing the mbedtls_cipher_context_t typed field completely.
Signed-off-by: gabor-mezei-arm <gabor.mezei@arm.com>
According to the PSA specification the PSA_USAGE_SIGN_HASH has the
permission to sign a message as PSA_USAGE_SIGN_MESSAGE. Similarly the
PSA_USAGE_VERIFY_HASH has the permission to verify a message as
PSA_USAGE_VERIFY_MESSAGE. These permission will also be present when
the application queries the usage flags of the key.
Signed-off-by: gabor-mezei-arm <gabor.mezei@arm.com>
Also remove preprocessor logic for MBEDTLS_CONFIG_FILE, since
build_info.h alreadyy handles it.
This commit was generated using the following script:
# ========================
#!/bin/sh
git ls-files | grep -v '^include/mbedtls/build_info\.h$' | xargs sed -b -E -i '
/^#if !?defined\(MBEDTLS_CONFIG_FILE\)/i#include "mbedtls/build_info.h"
//,/^#endif/d
'
# ========================
Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com>
Fix typos in the PBKDF2 documentation
Correct the constraints on PSA_KEY_USAGE_DERIVE and PSA_KEY_USAGE_VERIFY_DERIVATION, aligning them with the note against psa_key_derivation_input_key(). All key inputs must have the required usage flag to permit output or verification.
Correct the constraints on PSA_KEY_DERIVATION_INPUT_SECRET and PSA_KEY_DERIVATION_INPUT_PASSWORD, aligning them with 4feb611. psa_key_derivation_verify_key() does not require the secret/password input to be a key.
Signed-off-by: Andrew Thoelke <andrew.thoelke@arm.com>
This makes it easier to ensure that crypto_spe.h is included everywhere it
needs to be, and that it's included early enough to do its job (it must be
included before any mention of psa_xxx() functions with external linkage,
because it defines macros to rename these functions).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Conflicts:
include/mbedtls/ssl.h
include/psa/crypto_struct.h
Conflicts fixed by using the code from development branch
and manually re-applying the MBEDTLS_PRIVATE wrapping.
Removing reference to RFC 7748 as it is more confusing than helpful. (It
decodes the scalars after masking which is not part of the encoding we
want to specify. Also, it has the explanation what it means by little
endian in a preceding section that is not trivial to find.)
We also explicitly specify constraint on leading zeroes.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The expression "the masking is omitted" assumes familiarity with
Montgomery curve private key format and even then can be confusing and
ambiguous or confusing.
Describe directly what format we mean and add some more background
information and reference to the standard as well.
Signed-off-by: Janos Follath <janos.follath@arm.com>
4-space indent is only guaranteed to result in a code block if there's a
blank line just before (details vary depending on the markdown
implementation, and doxygen isn't exactly markdown anyway). In a bullet
list, you need 8 spaces since the list itself is a nested construct
which takes a 4-space indent (even though you don't have to indent
continuation lines inside a bullet point by 4 spaces, 1 is enough).
Using \code...\encode which is rendering as intended.
Signed-off-by: Janos Follath <janos.follath@arm.com>
This level of detail can be confusing and could require even more detail
to clear it up. Simplifying it instead in alignment wiht the
documentation of existing setup functions.
Signed-off-by: Janos Follath <janos.follath@arm.com>
This reverts commit 03a5fd7780026b2ca0b4728352ded930f5a7cff9.
We're already calling the output of a PAKE a "shared secret". The
password is a shared secret (for PAKE where the verifier knows a
password-equivalent secret), but calling it "shared secret" or even just
"secret" would be confusing.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Technically this function takes a low entropy secret as an input which
might or might not be the password. Using the term "secret" in the
function name is less misleading.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The password stretching (using slow and/or memory hard hashes) in PAKEs
usually serves two purposes:
- Defending against server compromise impersonation attacks. J-PAKE is an
augmented PAKE and as such, stores a password-equivalent and defending
against this class of attacks is out of scope.
- Preventing offline dictionary attacks. J-PAKE is proven to be zero
knowledge and leaks no information beyond the fact if the passwords
matched and offline dictionary attack is not possible.
In summary: J-PAKE does not benefit from pasword stretching and is
unlikely to be an input. This part of the API is not necessary at this
point and can be added later.
Signed-off-by: Janos Follath <janos.follath@arm.com>
We are not confident about the stability of the PAKE interface (it is
just a proposal, not part of the standard yet). So we should explicitly
document it as experimental, subject to change.
Signed-off-by: Janos Follath <janos.follath@arm.com>
At this point this is a proposed PAKE interface for the PSA Crypto API
and not part of the official standard. Place the interface in
crypto_extra.h to make this clear.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The API has PSA_ALG_GCM and not PSA_ALG_AEAD_GCM, PSA_ALG_MD5 and not
PSA_ALG_HASH_MD5, etc., so PSA_ALG_PAKE_JPAKE should be PSA_ALG_JPAKE as
well.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The caller is likely to receive the inputs on the wire, and having a
known size for which they can confidently reject longer inputs would be
helpful in cases where the application can't just use the input in
place.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Define the size macros to 0 rather than empty. That will lead to fewer
weird errors when we start implementing.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Make input/output format documentation easier to find:
- Add direct reference to the steps from the input/output functions
- Move the format description directly to the step constants
Signed-off-by: Janos Follath <janos.follath@arm.com>
- Transformed setup description to a more explicit pseudocode based
approach.
- Explained implicit vs explicit key confirmation
Signed-off-by: Janos Follath <janos.follath@arm.com>
This step is not necessarily a memory-hard function. Memory-hard
functions are the best of the breed at the moment, but that's due to
current hardware designs, and CPU-hard-but-not-memory-hard functions
like PBKDF2 are acceptable as well. We're using “key stretching” as the
generic term for such functions.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The key derivation operation passed to psa_pake_set_password_mhf() might
enter an error state before the function returns. If this happens, the
user needs to know about it so that they can properly abort it.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The type of the key derivation operation was incorrect.
Also neither the PAKE nor key_derivation algorithm knows how many bytes
to transfer at this stage.
There is no optimal or recommended size, PAKEs don't mandate it either
(with the exception of OPAQUE, but that uses it internally and won't be
using this interface).
Adding an input length parameter to allow the application to control how
many bytes the PAKE takes from the key derivation.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Using memory hard functions with PAKEs is the more secure option. It
should be as convenient and efficient to use as less secure options, but
so far it required creating an additional temporary key object.
With psa_pake_set_password_mhf() this eliminates the need for this.
Similarly we could add a convenience function to supply the password
directly from character strings, but that would make the less secure
option more convenient again and therfore we are not doing it now.
Signed-off-by: Janos Follath <janos.follath@arm.com>
