Keys of size 0 generally don't make sense: a key is supposed to be
secret. There is one edge case which is "raw data" keys, which are
useful to store non-key objects in the same storage location as keys.
However those are also problematic because they involve a zero-length
buffer. Manipulating zero-length buffers in C requires special cases
with functions like malloc() and memcpy(). Additionally, 0 as a key
size already has a meaning "unspecified", which does not always
overlap seamlessly with the meaning "0".
Therefore, forbid keys of size 0. No implementation may accept them.
Clarify how key creation functions use attributes. Explain the meaning
of attribute values, espcially what 0 means in each field where it has
a special meaning. Explain what an algorithm usage policy can be (an
algorithm, a wildcard with ANY_HASH, or 0).
* open output distinct key handles
* each handle must be closed
* destroying a key does not invalidate other handles
* closing a key can/might fail an active operation (but not required)
It may be possible that the implementation runs out of
memory when exporting a key from storage or a secure
element. For example, it may not be possible to directly
move the data from storage to the caller, so the implementation
will have to buffer the material temporarily (an issue if dynamic
memory allocation scheme is used). For a large key
this is more likely to return.
It may be possible that an implementation does not
fetch key material until a command like
this is called and such an error may occur if an
off-chip secure storage dependency may have been wiped.
Note that PSA_ERROR_NOT_PERMITTED is not included
because I can't think of a scenario where you have
a valid key handle but aren't allowed to read the
attributes
If the key doesn't exist by the time this call is made
then the handle is invalid,
which means that PSA_ERROR_INVALID_HANDLE should be
returned rather than "does not exist"
It may be possible that the implementation runs out of
memory when exporting a key from storage or a secure
element. For example, it may not be possible to directly
move the data from storage to the caller, so the implementation
will have to buffer the material temporarily (an issue if dynamic
memory allocation scheme is used). For a large key
this is more likely to return.
It may be possible that an implementation does not
fetch key material until a command like
this is called and such an error may occur if an
off-chip secure storage dependency may have been wiped.
Note that PSA_ERROR_NOT_PERMITTED is not included
because I can't think of a scenario where you have
a valid key handle but aren't allowed to read the
attributes
Adjust the wording to permit multiple handles to a single key - closing
a handle does not necessarily release volatile memory associated with
the key, that only occurs when the last handle is closed.
- Describe the implementation defined behavior for opening multiple
keys, and provide a reference to the relevant section.
- Describe the use of INSUFFICENT_MEMORY error to indicate additional
implementation resource constaints.
- Clarify the distinction between DOES_NOT_EXIST and INVALID_HANDLE
error conditions.
PSA_KEY_ATTRIBUTES_INIT and psa_key_attributes_init weren't declared
in the API document, only defined in our implementation, but they are
referenced in the API document.
generate_key is a more classical name. The longer name was only
introduced to avoid confusion with getting a key from a generator,
which is key derivation, but we no longer use the generator
terminology so this reason no longer applies.
perl -i -pe 's/psa_generate_random_key/psa_generate_key/g' $(git ls-files)
“Tampering detected” was misleading because in the real world it can
also arise due to a software bug. “Corruption detected” is neutral and
more precisely reflects what can trigger the error.
perl -i -pe 's/PSA_ERROR_TAMPERING_DETECTED/PSA_ERROR_CORRUPTION_DETECTED/gi' $(git ls-files)
Parametrize finite-field Diffie-Hellman key types with a DH group
identifier, in the same way elliptic curve keys are parametrized with
an EC curve identifier.
Define the DH groups from the TLS registry (these are the groups from
RFC 7919).
Replicate the macro definitions and the metadata tests from elliptic
curve identifiers to DH group identifiers.
Define PSA_DH_GROUP_CUSTOM as an implementation-specific extension for
which domain parameters are used to specify the group.
Move psa_get_key_domain_parameters() and
psa_set_key_domain_parameters() out of the official API and declare
them to be implementation-specific extensions.
Expand the documentation of psa_set_key_domain_parameters() a bit to
explain how domain parameters are used.
Remove all mentions of domain parameters from the documentation of API
functions. This leaves DH and DSA effectively unusable.
Generators are mostly about key derivation (currently: only about key
derivation). "Generator" is not a commonly used term in cryptography.
So favor "derivation" as terminology.
This commit updates the function descriptions.
Generators are mostly about key derivation (currently: only about key
derivation). "Generator" is not a commonly used term in cryptography.
So favor "derivation" as terminology. Call a generator a key
derivation operation structure, since it behaves like other multipart
operation structures. Furthermore, the function names are not fully
consistent.
In this commit, I rename the functions to consistently have the prefix
"psa_key_derivation_". I used the following command:
perl -i -pe '%t = (
psa_crypto_generator_t => "psa_key_derivation_operation_t",
psa_crypto_generator_init => "psa_key_derivation_init",
psa_key_derivation_setup => "psa_key_derivation_setup",
psa_key_derivation_input_key => "psa_key_derivation_input_key",
psa_key_derivation_input_bytes => "psa_key_derivation_input_bytes",
psa_key_agreement => "psa_key_derivation_key_agreement",
psa_set_generator_capacity => "psa_key_derivation_set_capacity",
psa_get_generator_capacity => "psa_key_derivation_get_capacity",
psa_generator_read => "psa_key_derivation_output_bytes",
psa_generate_derived_key => "psa_key_derivation_output_key",
psa_generator_abort => "psa_key_derivation_abort",
PSA_CRYPTO_GENERATOR_INIT => "PSA_KEY_DERIVATION_OPERATION_INIT",
PSA_GENERATOR_UNBRIDLED_CAPACITY => "PSA_KEY_DERIVATION_UNLIMITED_CAPACITY",
); s/\b(@{[join("|", keys %t)]})\b/$t{$1}/ge' $(git ls-files)
In psa_import_key, change the order of parameters to pass
the pointer where the newly created handle will be stored last.
This is consistent with most other library functions that put inputs
before outputs.
In psa_generate_derived_key, change the order of parameters to pass
the pointer where the newly created handle will be stored last.
This is consistent with most other library functions that put inputs
before outputs.
Use individual setters for the id and lifetime fields of an attribute
structure, like the other attributes.
This commit updates the specification and adds an implementation of
the new setters.
Define a range of key identifiers for use by the application
(0..2^30-1), a range for use by implementations (2^30..2^31), and a
range that is reserved for future use (2^31..2^32-1).
Change the scope of key identifiers to be global, rather than
per lifetime. As a result, you now need to specify the lifetime of a
key only when creating it.
New macros PSA_AEAD_UPDATE_OUTPUT_SIZE, PSA_AEAD_FINISH_OUTPUT_SIZE
and PSA_AEAD_VERIFY_OUTPUT_SIZE to determine the output buffer sizes
for psa_aead_update(), psa_aead_finish() and psa_aead_verify().
Like psa_aead_finish(), psa_aead_verify() needs to produce output from
the last partial block of input if psa_aead_update() cannot produce
output byte by byte.
In psa_import_key and psa_copy_key, some information comes from the
key data (input buffer or source key) rather than from the attributes:
key size for import, key size and type and domain parameters for copy.
If an unused attribute is nonzero in the attribute structure, check
that it matches the correct value. This protects against application
errors.
There was a guarantee that psa_get_key_attributes() does not require a
subsequent psa_reset_key_attributes() to free resources as long as the
key was created with attributes having this property. This requirement
was hard to pin down because if a key is created with default
parameters, there are cases where it is difficult to ensure that the
domain parameters will be reported without allocating memory. So
remove this guarantee. Now the only case psa_reset_key_attributes() is
not required is if the attribute structure has only been modified with
certain specific setters.
Read extra data from the domain parameters in the attribute structure
instead of taking an argument on the function call.
Implement this for RSA key generation, where the public exponent can
be set as a domain parameter.
Add tests that generate RSA keys with various public exponents.
Change psa_get_domain_parameters() and psa_set_domain_parameters() to
access a psa_key_attributes_t structure rather than a key handle.
In psa_get_key_attributes(), treat the RSA public exponent as a domain
parameter and read it out. This is in preparation for removing the
`extra` parameter of psa_generate_key() and setting the RSA public
exponent for key generation via domain parameters.
In this commit, the default public exponent 65537 is not treated
specially, which allows us to verify that test code that should be
calling psa_reset_key_attributes() after retrieving the attributes of
an RSA key is doing so properly (if it wasn't, there would be a memory
leak), even if the test data happens to use an RSA key with the
default public exponent.
Instead of passing a separate parameter for the key size to
psa_generate_key and psa_generator_import_key, set it through the
attributes, like the key type and other metadata.
Types and functions that are not used in the attribute-based key
creation API are now implementation-specific extensions, kept around
until we finish transitioning to the new API.
Implement attribute querying.
Test attribute getters and setters. Use psa_get_key_attributes instead
of the deprecated functions psa_get_key_policy or
psa_get_key_information in most tests.
Implement the new, attribute-based psa_import_key and some basic
functions to access psa_key_attributes_t. Replace
psa_import_key_to_handle by psa_import_key in a few test functions.
This commit does not handle persistence attributes yet.
This commit starts a migration to a new interface for key creation.
Today, the application allocates a handle, then fills its metadata,
and finally injects key material. The new interface fills metadata
into a temporary structure, and a handle is allocated at the same time
it gets filled with both metadata and key material.
This commit was obtained by moving the declaration of the old-style
functions to crypto_extra.h and renaming them with the to_handle
suffix, adding declarations for the new-style functions in crypto.h
under their new name, and running
perl -i -pe 's/\bpsa_(import|copy|generator_import|generate)_key\b/$&_to_handle/g' library/*.c tests/suites/*.function programs/psa/*.c
perl -i -pe 's/\bpsa_get_key_lifetime\b/$&_from_handle/g' library/*.c tests/suites/*.function programs/psa/*.c
Many functions that are specific to the old interface, and which will
not remain under the same name with the new interface, are still in
crypto.h for now.
All functional tests should still pass. The documentation may have
some broken links.
Merge the Mbed Crypto development branch a little after
mbedcrypto-1.0.0 into the PSA Crypto API 1.0 beta branch a little
after beta 2.
Summary of merge conflicts:
* Some features (psa_copy_key, public key format without
SubjectPublicKeyInfo wrapping) went into both sides, but with a few
improvements on the implementation side. For those, take the
implementation side.
* The key derivation API changed considerably on the API side. This
merge commit generally goes with the updated API except in the tests
where it keeps some aspects of the implementation.
Due to the divergence between the two branches on key derivation and
key agreement, test_suite_psa_crypto does not compile. This will be
resolved in subsequent commits.
For DH, ECC (Weierstrass curves) and DSA, specify that the re-drawing
method is the one defined by NIST as
"key-pair generation by testing candidates", and describe it
unambiguously.
Also specify DES explicitly.
psa_generator_import_key() was only specified for "symmetric keys",
and there were some mistakes in the specification. Rewrite the
specification and extend it to other key types.
* For most private key types, specify that the function draws a byte
string repeatedly until the byte string is suitable.
* For DES, despite being a symmetric key type, re-drawing is
necessary.
* For Montgomery curves, despite being asymmetric, no re-drawing is
necessary.
* Specify the behavior for every standard key type other than RSA.
An implementation doesn't have to support all key types, but if it
does, it's better to have a standard.
