This explicitly spells out what informally has been the coding
convention for some time on preprocessor directives, making it
more transparent and easier to find.
This is particularly useful as the code base has at least three
different styles. Deducing what actually is the current policy
would require a details look at how the style has changed over
time, rather than being obvious from a quick `grep` over the
code base.
This formats the code to improve readability and apply the coding
convention. This is a whitespace only change that will not change
generated binaries.
Add some tests to verify that when creating or importing keys,
the usage flags PSA_KEY_USAGE_SIGN_HASH/PSA_KEY_USAGE_VERIFY_HASH
automatically set the usage flags PSA_KEY_USAGE_SIGN_MESSAGE/
PSA_KEY_USAGE_VERIFY_MESSAGE on the key.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
This makes it easier to work with encrypted keys and multiple keys.
The firmware binary can contain multiple public keys that are used
to verify the manifest.
The use case is that we want to include the production public key
in the debug build, so we can seamlessly update to the production
version without re-flashing the device.
If the public keys is always generated on the fly, this would still
require the production key password even for the debug build.
Instead if we store the (unencrypted) public key, we can always
include it in the debug build.
The CoAP block option gets written twice:
First a 'dummy' value is written by `coap_opt_add_block2()`, later this gets
overwritten by the real option value by coap_block2_finish().
The problem arises when the size of the option changes.
If the option ends up smaller than the dummy, we have garbage bytes after the
real option value, corrupting the packet.
To mitigate this, always write at least one option byte (which will be a 0 byte)
to ensure the dummy data is overwritten.
fixes#20686
The PSA crypto specification states that when creating keys,
the usage flags PSA_KEY_USAGE_SIGN_HASH/PSA_KEY_USAGE_VERIFY_HASH
automatically set the usage flags
PSA_KEY_USAGE_SIGN_MESSAGE/PSA_KEY_USAGE_VERIFY_MESSAGE on the key.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
When psa_status_t is defined inside crypto_types.h, then all
users of psa_status_t are forced to pull the full range of PSA
Crypto API type definitions.
This however means that psa_status_t cannot be used when defining
those PSA Crypto API types, since doing so would create a cycle.
Fix this by moving the PSA status definitions into a separate header
file which additionally is compatible with the PSA Status code API.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
