Commit Graph

13550 Commits

Author SHA1 Message Date
Gilles Peskine
ef9874d11a Update terminology
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-19 21:55:27 +02:00
Gilles Peskine
5298f684bd Fix hyperlinks
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-19 21:53:59 +02:00
Gilles Peskine
2e843aeb3e Update some open questions
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-19 21:43:59 +02:00
Gilles Peskine
0dfd10d2a2 Copyediting
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-19 21:41:27 +02:00
Gilles Peskine
daf017c8a2 Allow algorithm policy wildcards as algorithm specifications
I'd intended this all along but never made it explicit.

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-07 23:40:53 +02:00
Gilles Peskine
d89cd742eb Specify that transparent drivers are considered in order
There is little point in leaving the order in which drivers are
considered unspecified. This gives flexibility to the implementation
for a process that is generally performed at build time, not in a
constrained environment. Having a well-defined order is especially
useful with fallback.

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-07 23:37:55 +02:00
Gilles Peskine
91cbf56d4c Specify what happens if multiple capabilities apply
It's ok if they map to the same function names and an error otherwise.

It's an error to have multiple opaque drivers for the same location.

If multiple transparent drivers apply, which one applies is unspecified.

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-07 23:30:16 +02:00
Gilles Peskine
c7cf13356c Define the semantics of capabilities
The existing description of the syntax of capabilities also describes
the semantics of each property, but the semantics of the capability as
a whole is not immediately clear. Add a subsection that explains
precisely when a capability is applicable.

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-07 23:24:00 +02:00
Gilles Peskine
1bc9c4c8c8 Make entry points mandatory in capabilities
Inferring entry points from algorithms is nice in that it makes
capability specifications shorter and less redundant, but that's not
really important. It also makes capabilities more fragile: if the core
starts supporting new mechanisms based on the same algorithm (for
example, adding hash-and-sign when only sign-the-hash existed before),
a driver only supporting the old mechanisms would fail at build time.
So make entry points mandatory.

This has the benefit of making the semantics of capabilities easier to
describe.

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-07 22:47:15 +02:00
Gilles Peskine
924e273b06 Change "functions" property to "entry_points"
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-07 13:53:16 +02:00
Gilles Peskine
c259213a01 More editorial corrections
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-07 13:52:43 +02:00
Gilles Peskine
15319454e6 Reword the explanation of fallback
Add the rationale which I'd accidentally omitted.

No intended meaning change.

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-06 22:49:54 +02:00
Gilles Peskine
85b3e13cd0 Introduce "acme" as the prefix each time it's used
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-06 22:20:33 +02:00
Gilles Peskine
daf9d82b75 Correct usage of key_derivation_output_key
Add the mention of key_derivation_output_key in the section about the
key derivation entry point family.

Rename "derive_key" to "key_derivation_output_key". At this point,
there's no reason to deviate from the naming convention.

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-06 22:20:33 +02:00
Gilles Peskine
a58d225d62 Add deep links to the API specification in a few places
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-06 22:20:33 +02:00
Gilles Peskine
d4e6927614 Change "function" to "entry point" in more places
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-06 22:20:33 +02:00
Gilles Peskine
53ba94c968 Clarify how the headers are used
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-06 22:20:33 +02:00
Gilles Peskine
e72e4de070 Clarify what the headers do
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-06 22:20:33 +02:00
Gilles Peskine
7a1e4f926a Minor wording improvements
Clarify some sentences. There is no change in intended meaning.

Fix typos. Change British spelling to American spelling.

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-06 22:20:32 +02:00
danh-arm
0ca6d38bc3
Merge pull request #3493 from gilles-peskine-arm/psa-unified-driver-specs
PSA unified driver specification
2020-08-06 16:10:17 +01:00
Gilles Peskine
404e1dbd5a Clarify updates to the persistent state in storage
Rename psa_crypto_driver_update_persistent_state to
psa_crypto_driver_commit_persistent_state.

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-05 22:37:29 +02:00
Gilles Peskine
5001da4aee With multiple applicable transparent drivers, the order is unspecified
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-05 22:32:36 +02:00
Gilles Peskine
b320d0833d Minor clarifications
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-05 22:27:41 +02:00
Gilles Peskine
ea739f0814 Give some examples of purpsoses of pure-software transparent driver
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-05 22:27:41 +02:00
Gilles Peskine
e265b9d183 Fix typos
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-05 22:27:41 +02:00
Gilles Peskine
3d1bcc68cb Add a link to the PSA API specification
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-05 22:20:09 +02:00
Gilles Peskine
929ab8af2b Explain locations vs lifetimes
Locations aren't in the official PSA API specification yet (they've
only be made public in Mbed TLS). Until version 1.0.1 of the API
specification is out, this document needs to explain locations.

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-05 22:18:38 +02:00
Gilles Peskine
67a85d1d3b
Merge pull request #3492 from stevew817/rework/key_slot_contains_key_buffer
Rework PSA Crypto core to store keys in export representation
2020-08-05 21:16:11 +02:00
Steven Cooreman
d4867877f1 Initialize key pointer in ecdh to NULL
Since it is being dereferenced by free on exit it should be inited to NULL.
Also added a small test that would trigger the issue.

Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
2020-08-05 17:38:47 +02:00
Steven Cooreman
b7f6deaae7 Add buffer zeroization when ecp_write_key fails
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
2020-08-05 17:38:47 +02:00
Steven Cooreman
fd4d69a72e Simplified key slot deletion
And zeroize key buffer before freeing to avoid keys hanging around on the
heap.

Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
2020-08-05 17:38:32 +02:00
Steven Cooreman
291498600b Style fixes
* return is treated as a function call
* space between opening and closing parentheses
* remove whiteline between assignment and checking of same variable

Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
2020-08-05 16:44:24 +02:00
Steven Cooreman
4fed455347 Apply review feedback
* No need to check for NULL before free'ing
* No need to reset variables that weren't touched
* Set output buffer to zero if key output fails
* Document internal functions and rearrange order of input arguments to
  better match other functions.
* Clean up Montgomery fix to be less verbose code

Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
2020-08-03 14:46:12 +02:00
Gilles Peskine
ab808e7592 Update open question section about public key storage
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-03 13:43:02 +02:00
Gilles Peskine
c93c4ed653 Remove the paragraph about declaring application needs
It's out of scope.

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-03 13:38:03 +02:00
Gilles Peskine
c1d388ae54 Change driver persistent data to a callback interface
Rather than have some functions take the in-memory copy of the
persistent data as argument, allow all of them to access the
persistent data, including modifying it.

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-03 12:04:46 +02:00
Gilles Peskine
8d06ad0177 Rework and expand key management in opaque drivers
Opaque drivers only have a destroy function if the key is stored in
the secure element.

Expand on how key creation works. Provide more explanations of
allocate_key in drivers for secure elements with storage. Discuss key
destruction as well.

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-03 12:04:46 +02:00
Gilles Peskine
921492625c Fix typos and copypasta
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-03 12:04:45 +02:00
Gilles Peskine
b6c43f61a4 Call driver entry point functions "entry point"
Call the functions listed in the driver description "entry points".
It's more precise than "functions", which could also mean any C
function defined in the driver code.

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-03 11:21:07 +02:00
Steven Cooreman
3fa684ed91 Allow importing Montgomery public keys in PSA Crypto
PSA Crypto was checking the byte length of a to-be-imported public ECP key
against the expected length for Weierstrass keys, forgetting that
Curve25519/Curve448 exists.

Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
2020-07-30 15:35:14 +02:00
Steven Cooreman
7f39187d6b Convert load_xxx_representation to take buffers instead of a whole slot
Avoids stack-allocating a key slot during ECDH, and mock-attaching a
key to a key slot during key import.

Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
2020-07-30 15:21:41 +02:00
Steven Cooreman
6d839f05bf Cleanup
* No null-check before calling free
* Close memory leak
* No need for double check of privkey validity

Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
2020-07-30 15:21:41 +02:00
Steven Cooreman
a2371e53e4 Update after feedback from #3492
* Allocate internal representation contexts on the heap (i.e. don't change
  where they're being allocated)
* Unify load_xxx_representation in terms of allocation and init behaviour

Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
2020-07-28 14:30:39 +02:00
Steven Cooreman
75b743666e Update after feedback on #3492
* Updated wording
* Split out buffer allocation to a convenience function
* Moved variable declarations to beginning of their code block

Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
2020-07-28 14:30:13 +02:00
Steven Cooreman
19fd574b3a Disconnect knowing about a PSA key type from knowing the mbedTLS API
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
2020-07-24 23:46:21 +02:00
Steven Cooreman
560c28a1ac Unify key handling logic
Now that both ECP and RSA keys are represented in export representation,
they can be treated more uniformly.

Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
2020-07-24 23:44:31 +02:00
Steven Cooreman
acda8346bf Remove ECP internal representation from key slot
Change to on-demand loading of the internal representation when required
in order to call an mbed TLS cryptography API.

Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
2020-07-24 23:44:31 +02:00
Steven Cooreman
a01795d609 Remove RSA internal representation from key slot
Change to on-demand loading of the internal representation when required
in order to call an mbed TLS cryptography API.

Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
2020-07-24 23:44:31 +02:00
Steven Cooreman
81be2fa0b2 Pull apart slot memory allocation from key validation.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
2020-07-24 23:44:31 +02:00
Steven Cooreman
71fd80d279 Re-define members of psa_key_slot_t
In preparation for the implementation of the accelerator APIs. This is
ramping up to the goal of only storing the export representation in the
key slot, and not keeping the crypto implementation-specific representations
around.

Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
2020-07-24 23:44:25 +02:00