Add support for elliptic curves for transient context #69

ionut-arm · 2020-05-05T15:16:33Z

This commit adds support for elliptic curve handling of the
TransientKeyContext.

It also adds and improves many of the underlying structures used to
access or provision said keys.

Signed-off-by: Ionut Mihalcea ionut.mihalcea@arm.com

ionut-arm · 2020-05-05T15:23:05Z

src/utils/mod.rs

+/// Builder for `TPMS_ECC_PARMS` values.
+// Most of the field types are from bindgen which does not implement Debug on them.
+#[allow(missing_debug_implementations)]


This is no longer the case.

Nice! Does that mean we could remove this allow?

Yes, and put Debug in derive

hug-dev

Thanks a lot for adding support for elliptic curves! That is a huge improvements!

I put some comments on what I can understand.

hug-dev · 2020-05-05T15:49:16Z

.gitignore

@@ -5,3 +5,4 @@ Cargo.lock
 *DS_Store
 *.patch
 *NVChip
+.vscode


You wouldn't need that with vim 😁

Sorry, I can't hear you over the sound of my IDE checking for and displaying any cargo issues automatically 😛

hug-dev · 2020-05-05T17:16:06Z

src/abstraction/transient.rs

+        /// Size of key in bits
+        ///
+        /// Can only be one of: 1024, 2048, 3072 or 4096
+        size: u16,


Could we have a RsaSize enumeration for those four possible values so that the check line 104 is no longer needed?

Yeah, I know, tried that with Cipher some time ago, but it feels overkill tbh... Could change if you want. Also the variant names feel weird af because you can't start a name with digits.

I think it is worth to do it!
We could write the number in clear letters like:

enum RsaSize { OneThousandTwentyFour, TwoThousandFortyEight, ...

(joking)

Actually it could be possible

Yeah, for the symmetric ones I went for Bits128, Bits192... but anyway... I'll skip it for now

hug-dev · 2020-05-05T17:18:56Z

src/utils/mod.rs

+/// Builder for `TPMS_ECC_PARMS` values.
+// Most of the field types are from bindgen which does not implement Debug on them.
+#[allow(missing_debug_implementations)]


Nice! Does that mean we could remove this allow?

hug-dev · 2020-05-05T17:24:52Z

src/utils/mod.rs

+
+impl TpmsEccParmsBuilder {
+    /// Create parameters for a restricted decryption key (i.e. a storage key)
+    pub fn new_restricted_decryption_key(symmetric: Cipher, curve: EllipticCurve) -> Self {


What is the justification for the decryption one to be restricted and the signing one to be unrestricted?

Restricted decryption keys are essentially Parent keys - they could be either used for derivation or storage of other object underneath it. The ECC one isn't used like that, so I could remove this

From the spec:

A hierarchy is rooted in a secret seed key, kept in the TPM. To create a hierarchy of keys, the seed key (Primary Seed) is used to generate a key that uses a specific set of algorithms. If this key is a restricted decryption key, then it is a Parent Key. If it is not a Derivation Parent, then it is a Storage Parent under which other objects may be created or attached.

Ahhh got it thanks!

hug-dev · 2020-05-05T17:29:06Z

src/utils/mod.rs

+        if self.for_signing
+            && scheme.scheme != TPM2_ALG_ECDSA
+            && scheme.scheme != TPM2_ALG_ECDAA
+            && scheme.scheme != TPM2_ALG_SM2
+            && scheme.scheme != TPM2_ALG_ECSCHNORR
+        {
+            return Err(Error::local_error(WrapperErrorKind::InconsistentParams));
+        }
+
+        if self.for_decryption
+            && scheme.scheme != TPM2_ALG_SM2
+            && scheme.scheme != TPM2_ALG_ECDH
+            && scheme.scheme != TPM2_ALG_ECMQV
+            && scheme.scheme != TPM2_ALG_NULL
+        {
+            return Err(Error::local_error(WrapperErrorKind::InconsistentParams));
+        }


I ask this mostly because I am not an expert but it seems like here we are checking that the appropriate algorithm is select for each key type. Does that mean that different algorithms are used for signing and verification?

No, for_signing actually means for_signing_and_verification and decryption is the same with encryption. It essentially specifies what the private key is used for.

This split here is because some scheme are for signing and others are for encryption. SM2 can do both

hug-dev · 2020-05-05T17:36:45Z

src/utils/mod.rs

+            | AsymSchemeUnion::RSAES
+            | AsymSchemeUnion::RSAOAEP(_)
+            | AsymSchemeUnion::ECMQV(_) => {
+                Err(Error::local_error(WrapperErrorKind::InconsistentParams))


Should that be UnsupportedParam?

This is in a impl TryFrom<Signature> for TPMT_SIGNATURE - meaning that only asymmetric schemes that are for signing make sense here; if the scheme on the Signature is an encryption one then there's an inconsistency.

That does, however, bring the question of whether the AsymSchemeUnion should be split into multiple enums - AsymSignScheme and AsymEncryptScheme, maybe even further, RsaSignScheme, EccSignScheme etc.

This is in a impl TryFrom for TPMT_SIGNATURE - meaning that only asymmetric schemes that are for signing make sense here; if the scheme on the Signature is an encryption one then there's an inconsistency.

That makes sense!

That does, however, bring the question of whether the AsymSchemeUnion should be split into multiple enums - AsymSignScheme and AsymEncryptScheme, maybe even further, RsaSignScheme, EccSignScheme etc.

That would mean that the scheme field of Signature could be AsymSignScheme so you would not even have to do that check?

That would mean that the scheme field of Signature could be AsymSignScheme so you would not even have to do that check?

True, but I've also realised that this would only work if we keep separate methods for creating/using signing and decryption keys. Otherwise in the TransientKeyContext, for example, we'd have to have different params types or variants for signing and encryption.

I'm not a huge fan of it, but we can keep the thing as is and simply have these checks here - we have to do a full match in most cases anyway. I could implement methods is_signing and is_decryption on AsymSchemeUnion to make checks faster.

hug-dev · 2020-05-05T17:38:03Z

src/utils/mod.rs

+pub fn create_unrestricted_signing_ecc_public(
+    scheme: AsymSchemeUnion,
+    curve: EllipticCurve,
+) -> Result<TPM2B_PUBLIC> {


Is TPM2B_PUBLIC the last structure that we use and do not abstract? (Just for my information)

Yeah, TPM2B_PUBLIC is really deeply nested and convoluted - I guess it could be made up of a hierarchy of Rust native types, but it would be a large effort to allow all the possibilities that the original interface allows, while making it easier for a developer to build a structure that just works™️.

hug-dev

Approving! I'll let you decide if you want to make the changes discussed about creating new types, and if you do, if you want to make them in this PR or a new one.

This commit adds support for elliptic curve handling of the TransientKeyContext. It also adds and improves many of the underlying structures used to access or provision said keys. Signed-off-by: Ionut Mihalcea <ionut.mihalcea@arm.com>

In order to execute the tests under different single providers, under all providers and for cross-compilation, split the tests directory into sub-directories. Each one contains a specific configuration file to run the tests under. Please check issue parallaxsecond#69 for details. Signed-off-by: Hugues de Valon <hugues.devalon@arm.com>

ionut-arm added the enhancement New feature or request label May 5, 2020

ionut-arm added this to the Rustification milestone May 5, 2020

ionut-arm requested a review from hug-dev May 5, 2020 15:16

ionut-arm self-assigned this May 5, 2020

ionut-arm commented May 5, 2020

View reviewed changes

hug-dev reviewed May 5, 2020

View reviewed changes

hug-dev approved these changes May 6, 2020

View reviewed changes

ionut-arm force-pushed the ec-support branch from f1e468c to 5bf2f06 Compare May 6, 2020 10:24

ionut-arm merged commit 43d9aff into parallaxsecond:master May 6, 2020

ionut-arm deleted the ec-support branch May 6, 2020 11:06

hug-dev mentioned this pull request Jun 2, 2020

Add ECDSA support #68

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for elliptic curves for transient context #69

Add support for elliptic curves for transient context #69

ionut-arm commented May 5, 2020

ionut-arm May 5, 2020

hug-dev May 5, 2020

ionut-arm May 5, 2020

hug-dev left a comment

hug-dev May 5, 2020

ionut-arm May 5, 2020

hug-dev May 5, 2020

ionut-arm May 5, 2020

hug-dev May 6, 2020

ionut-arm May 6, 2020

hug-dev May 5, 2020

hug-dev May 5, 2020

ionut-arm May 5, 2020

ionut-arm May 5, 2020

hug-dev May 6, 2020

hug-dev May 5, 2020

ionut-arm May 5, 2020

hug-dev May 5, 2020

ionut-arm May 5, 2020

hug-dev May 6, 2020

ionut-arm May 6, 2020

hug-dev May 5, 2020

ionut-arm May 5, 2020

hug-dev May 6, 2020

hug-dev left a comment

Add support for elliptic curves for transient context #69

Add support for elliptic curves for transient context #69

Conversation

ionut-arm commented May 5, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hug-dev left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hug-dev left a comment

Choose a reason for hiding this comment