Commit graph

11848 commits

Author SHA1 Message Date
Gilles Peskine 2493401af4 Document that psa_close_key(0) and psa_destroy_key(0) succeed
Document that passing 0 to a close/destroy function does nothing and
returns PSA_SUCCESS.

Although this was not written explicitly, the specification strongly
suggested that this would return PSA_ERROR_INVALID_HANDLE. While
returning INVALID_HANDLE makes sense, it was awkward for a very common
programming style where applications can store 0 in a handle variable
to indicate that the handle has been closed or has never been open:
applications had to either check if (handle != 0) before calling
psa_close_key(handle) or psa_destroy_key(handle), or ignore errors
from the close/destroy function. Now applications following this style
can just call psa_close_key(handle) or psa_destroy_key(handle).
2019-10-08 15:43:13 +02:00
Andrew Thoelke 6e59505bb2 Recommend use of GREASE values for vendor defined DH groups 2019-10-07 22:27:17 +01:00
Andrew Thoelke 691ec52694 Remove over-specific RFC references
Rely on general reference to IANA documentation
2019-10-07 15:28:36 +01:00
Gilles Peskine e249c0e6b3 config.pl full: exclude MBEDTLS_CTR_DRBG_USE_128_BIT_KEY
This is a variant toggle, not an extra feature, so it should be tested
separately.
2019-10-07 15:57:50 +02:00
Gilles Peskine 77d44573cb mbedtls_hmac_drbg_set_entropy_len() only matters when reseeding
The documentation of HMAC_DRBG erroneously claimed that
mbedtls_hmac_drbg_set_entropy_len() had an impact on the initial
seeding. This is in fact not the case: mbedtls_hmac_drbg_seed() forces
the entropy length to its chosen value. Fix the documentation.
2019-10-04 18:34:12 +02:00
Gilles Peskine dddda81fbc mbedtls_ctr_drbg_set_entropy_len() only matters when reseeding
The documentation of CTR_DRBG erroneously claimed that
mbedtls_ctr_drbg_set_entropy_len() had an impact on the initial
seeding. This is in fact not the case: mbedtls_ctr_drbg_seed() forces
the initial seeding to grab MBEDTLS_CTR_DRBG_ENTROPY_LEN bytes of
entropy. Fix the documentation and rewrite the discussion of the
entropy length and the security strength accordingly.
2019-10-04 18:33:59 +02:00
Jaeden Amero 9ab7c07f1f
Merge pull request #75 from gilles-peskine-arm/asn1-tests-without-x509
ASN.1 tests without x509
2019-10-04 12:30:01 +01:00
Gilles Peskine 88f136f98b Fix free_named_data_list tests
Fix copypasta in test data and fix a switcho in test code.
2019-10-04 11:35:09 +02:00
Gilles Peskine dc2db4832d Fix typos in documentation 2019-10-04 11:35:09 +02:00
Gilles Peskine 7e27936767 Add a note about CTR_DRBG security strength to config.h 2019-10-04 11:16:31 +02:00
Gilles Peskine 1540e5bd04 Move MBEDTLS_CTR_DRBG_USE_128_BIT_KEY to the correct section
It's an on/off feature, so it should be listed in version_features.
2019-10-04 11:16:24 +02:00
Gilles Peskine d0c64c856d CTR_DRBG: more consistent formatting and wording
In particular, don't use #MBEDTLS_xxx on macros that are undefined in
some configurations, since this would be typeset with a literal '#'.
2019-10-04 11:12:04 +02:00
Gilles Peskine 2884ba3720 CTR_DRBG: Improve the explanation of security strength
Separate the cases that achieve a 128-bit strength and the cases that
achieve a 256-bit strength.
2019-10-04 11:09:03 +02:00
Gilles Peskine 017778e9d8 CTR_DRBG: make it easier to understand the security strength
Explain how MBEDTLS_CTR_DRBG_ENTROPY_LEN is set next to the security
strength statement, rather than giving a partial explanation (current
setting only) in the documentation of MBEDTLS_CTR_DRBG_ENTROPY_LEN.
2019-10-04 11:09:03 +02:00
Gilles Peskine 5d9fd07938 HMAC_DRBG: note that the initial seeding grabs entropy for the nonce 2019-10-04 11:09:03 +02:00
Gilles Peskine 217b8159da Use standard terminology to describe the personalization string
NIST and many other sources call it a "personalization string", and
certainly not "device-specific identifiers" which is actually somewhat
misleading since this is just one of many things that might go into a
personalization string.
2019-10-04 11:09:03 +02:00
Gilles Peskine 2d8f069472 Do note that xxx_drbg_random functions reseed with PR enabled 2019-10-04 11:09:03 +02:00
Gilles Peskine 10f16ac74a Consistently use \c NULL and \c 0 2019-10-04 11:09:03 +02:00
Gilles Peskine 3457b5e05e HMAC_DRBG: improve the documentation of the entropy length 2019-10-04 11:09:03 +02:00
Gilles Peskine 74efcd2b71 HMAC_DRBG documentation improvements clarifications
Improve the formatting and writing of the documentation based on what
had been done for CTR_DRBG.

Document the maximum size and nullability of some buffer parameters.
2019-10-04 11:09:03 +02:00
Gilles Peskine ec51dd12fa More CTR_DRBG documentation improvements and clarifications 2019-10-04 11:09:03 +02:00
Gilles Peskine 6fdf0b3a47 CTR_DRBG: improve the discussion of entropy length vs strength 2019-10-04 11:09:02 +02:00
Gilles Peskine 223deea86b CTR_DRBG: Document the security strength and SP 800-90A compliance
Document that a derivation function is used.

Document the security strength of the DRBG depending on the
compile-time configuration and how it is set up. In particular,
document how the nonce specified in SP 800-90A is set.

Mention how to link the ctr_drbg module with the entropy module.
2019-10-04 11:09:02 +02:00
Gilles Peskine 944bc587e8 CTR_DRBG: Document the maximum size of some parameters 2019-10-04 11:09:02 +02:00
Gilles Peskine 6b2a779323
Merge pull request #286 from athoelke/at-version
Fix defgroup syntax for API version section
2019-10-03 16:07:08 +02:00
Jaeden Amero e4209c0e62
Merge pull request #278 from RonEld/fix_on_target_test_issues
Fix on target test issues
2019-10-03 14:10:05 +01:00
Gilles Peskine 08875d441e CTR_DRBG documentation clarifications
* State explicit whether several numbers are in bits or bytes.
* Clarify whether buffer pointer parameters can be NULL.
* Explain the value of constants that are dependent on the configuration.
2019-10-02 19:16:09 +02:00
Andrew Thoelke 02b372b7b2 Fix defgroup syntax for API version section 2019-10-02 09:32:21 +01:00
Gilles Peskine e1ee8f157c Test that SE driver persistent data is saved correctly
Add invasive checks that peek at the stored persistent data after some
successful import, generation or destruction operations and after
reinitialization to ensure that the persistent data in storage has the
expected content.
2019-10-01 16:56:27 +02:00
Gilles Peskine d5536d8a5b SE driver: Fix loading of persistent data
The persistent data was not loaded correctly (the code was loading 0
bytes instead of the correct size).
2019-10-01 16:55:29 +02:00
Gilles Peskine c84c70a83c SE driver: save the persistent data after calling p_init 2019-10-01 15:41:42 +02:00
Gilles Peskine d9348f218e SE driver: call the p_init method during psa_crypto_init() 2019-10-01 15:22:29 +02:00
Gilles Peskine 5ec3a30edb SE driver: validate_slot_number: support changing persistent data
Add a parameter to the p_validate_slot_number method to allow the
driver to modify the persistent data.

With the current structure of the core, the persistent data is already
updated. All it took was adding a way to modify it.
2019-10-01 14:27:23 +02:00
Gilles Peskine 3efcebbc5e SE support: Use a transaction when registering a key
When registering a key in a secure element, go through the transaction
mechanism. This makes the code simpler, at the expense of a few extra
storage operations. Given that registering a key is typically very
rare over the lifetime of a device, this is an acceptable loss.

Drivers must now have a p_validate_slot_number method, otherwise
registering a key is not possible. This reduces the risk that due to a
mistake during the integration of a device, an application might claim
a slot in a way that is not supported by the driver.
2019-10-01 14:18:35 +02:00
Gilles Peskine a990c49caf
Merge pull request #269 from adrianlshaw/version
Add PSA API versioning
2019-09-30 15:59:21 +02:00
Gilles Peskine 9a562d471e
Merge pull request #277 from jack-fortanix/faster-pbkdf2
Improve speed of PBKDF2 by caching the digest state of the passphrase
2019-09-30 15:53:49 +02:00
Gilles Peskine 37b5c831b4
Merge pull request #276 from gilles-peskine-arm/psa-key_derivation-relax_inputs
Relax input restrictions for key derivation
2019-09-26 15:29:34 +02:00
Andrew Thoelke 214064ea85 Xref documentation for ECC curves and DH groups.
Connect the types to the key type construction macros by x-refs.
2019-09-25 22:16:21 +01:00
Andrew Thoelke fd368e50d5 Support for vendor-defined ECC curves and DH groups
Define a vendor-range within the the private use ranges in the IANA 
registry. Provide recommendations for how to support vendor-defined 
curves and groups.
2019-09-25 22:14:29 +01:00
Andrew Thoelke c625045da6 Tighten up language regarding direct use of the IANA registry values 2019-09-25 22:11:36 +01:00
Ron Eldor 038ab053d6 Add const to variable
Add const type that was accidently removed.
2019-09-25 14:06:15 +03:00
Jaeden Amero 5a627c5e19
Merge pull request #264 from gilles-peskine-arm/test_malloc_0_null
Test the library when malloc(0) returns NULL
2019-09-25 09:28:54 +01:00
Gilles Peskine 178c9aa966 Key derivation: forbid output_key without input_key
If none of the inputs to a key derivation is a
PSA_KEY_DERIVATION_INPUT_SECRET passed with
psa_key_derivation_input_key(), forbid
psa_key_derivation_output_key(). It usually doesn't make sense to
derive a key object if the secret isn't itself a proper key.
2019-09-24 18:39:03 +02:00
Gilles Peskine 1a2904c49a derive_input test function: Try output afterwards
After passing some inputs, try getting one byte of output, just to
check that this succeeds (for a valid sequence of inputs) or fails
with BAD_STATE (for an invalid sequence of inputs). Either output a
1-byte key or a 1-byte buffer depending on the test data.

The test data was expanded as follows:
* Output key type (or not a key): same as the SECRET input if success
  is expected, otherwise NONE.
* Expected status: PSA_SUCCESS after valid inputs, BAD_STATE after any
  invalid input.
2019-09-24 18:39:03 +02:00
Gilles Peskine 2058c07724 derive_input test function: More logical parameter order
No behavior change.
2019-09-24 18:39:03 +02:00
Gilles Peskine 7ebd4dcf57 Key derivation: allow both keys and direct inputs (function doc)
Update the documentation of psa_key_derivation_input_key() and
psa_key_derivation_input_bytes() now that the key/buffer distinction
is not mandatory.
2019-09-24 18:39:03 +02:00
Gilles Peskine b8965193a0 Use the constant PSA_KEY_TYPE_NONE rather than 0
No behavior change, just a readability improvement.
2019-09-24 18:39:03 +02:00
Gilles Peskine 46d7faf195 Don't jump past a variable declaration
This is valid C99 (since the variable in question is not a VLA and is
not used) but not accepted by IAR 8.20.
2019-09-24 18:39:03 +02:00
Gilles Peskine 593773d9f2 Consistently abort key derivation operations on input error 2019-09-24 18:39:03 +02:00
Gilles Peskine 224b0d656a Key derivation: allow both keys and direct inputs
Allow a direct input as the SECRET input step in a key derivation, in
addition to allowing DERIVE keys. This makes it easier for
applications to run a key derivation where the "secret" input is
obtained from somewhere else. This makes it possible for the "secret"
input to be empty (keys cannot be empty), which some protocols do (for
example the IV derivation in EAP-TLS).

Conversely, allow a RAW_DATA key as the INFO/LABEL/SALT/SEED input to a key
derivation, in addition to allowing direct inputs. This doesn't
improve security, but removes a step when a personalization parameter
is stored in the key store, and allows this personalization parameter
to remain opaque.

Add test cases that explore step/key-type-and-keyhood combinations.
2019-09-24 18:39:03 +02:00