[RFC] POC Remote Attestation #4011

elias-vd · 2020-07-31T11:59:34Z

Contains the PTA for the example of remote attestation.

Conceptual overview: https://www.substratee.com/hw_ra_by_distributor.html

Linked PRs:

Signed-off-by: Elias von Daeniken elias.vondaeniken@bluewin.ch

jforissier

Thanks for this RFC code. Remote attestation is certainly an interesting use case for a TEE.

Please see some initial comments below. Also if we merge this new feature will want at least some basic sanity testing in xtest too. optee_examples is fine for examples, but it is xtest that we run in CI and during release testing. But that can be addressed later obviously since this is just an RFC.

jforissier · 2020-07-31T13:17:09Z

core/pta/system.c

@@ -280,6 +281,11 @@ static TEE_Result system_open_ta_binary(struct system_ctx *ctx,
 		goto err_oom;
 	params[0].value.a = h;

+#ifdef CFG_ATTESTATION_PTA
+	utc = to_user_ta_ctx(tee_ta_get_calling_session()->ctx);
+	memcpy(utc->ta_image_sha256, tag, tag_len);


This assumes the TA does not use shared libraries. Otherwise system_open_ta_binary() is called several times with the same context. First to load the TA main executable, then to load additional libraries. So ta_image_sha256 would be overwritten by the hash of the last library.

An upcall into ldelf might be required to address this issue properly. @jenswi-linaro?

Thank you for taking the time to look at my POC

I am completely aware of the fact that my POC only works if the TA do not load any libraries. But in our use case it is not intended to load any libraries. Nevertheless, if OPTEE want to offer remote attestation it has to offer a mechanism to measure a TA.

To throw in my thoughts about this topic:

From the point of view of remote attestation, it does not matter what is loaded, as long it is measured. This goes further to the point, that we would like to make our key in optee_os/keys/default_ta.pem publicly available. So that anyone can load TAs, but also everyone (remote) can attest the TA if he knows the corresponding hashes.

To my (limited) understanding of the OPTEE OS, I think remote attestation is best implemented as a pseudo TA. Then anyone can implement the protocol he wants. But the OS has to offer three things to the PTA.

Endorsement Key: Access to this key is hardware dependent and not part of the OPTEE project

System measurement: The PTA needs access to the measurements of Secure Boot, this is also platform specific

TA measurement: The TA measurement must be deterministic. I think this is problematic with the current situation. The main problem that I see, is the order in which the libraries getting loaded.

We could instead of copying the tag, hash it together with previous value. No TA code will be executed until all libraries are loaded so there's no risk of executing with an incomplete digest. But this is only the easy part, the hard part comes with dlopen() and friends. See #3189 (comment)

However, if the TA doesn't use dlopen() at all it shouldn't be a problem.

jforissier · 2020-07-31T13:17:47Z

core/pta/attestation.c

+
+	TEE_Result res = TEE_ERROR_GENERIC;
+
+	typedef struct attestation_certificate {


No typedef please.

core/pta/attestation.c

jforissier · 2020-07-31T13:24:17Z

core/pta/attestation.c

+	size_t rn_len = 32;
+	uint8_t rn[rn_len];
+
+	res = get_random_number(rn);


Why not use crypto_rng_read()?

core/pta/attestation.c

jforissier · 2020-07-31T13:34:51Z

core/pta/attestation.c

+{
+
+	uint32_t size;
+	uint32_t offset = 7; // Beginn at the start of the modulus


We normally don't use C++-style comment in OP-TEE (except for the SPDX tag in .c files.
What do others think? Should we accept them now? (they are allowed in the Linux kernel apparently).

We normally don't use C++-style comment in OP-TEE (except for the SPDX tag in .c files.
What do others think? Should we accept them now? (they are allowed in the Linux kernel apparently).

Do you have a link?

https://lkml.org/lkml/2019/6/27/117

And there this older (2016) rant from Linus https://lkml.org/lkml/2016/7/8/625 where he says he is favorable to C++-style comments.

Speaking for myself here:
I guess I could "tolerate" them in .c files, but I still think they should be avoided.
In my mind those are lazy comments that you add as reminders for yourself to be cleaned up before submitting the patch.
So sure you can use them, but each time I see one I'll be thinking "so you don't have time to write a proper comment?". ;-)

@jenswi-linaro +1, the power of habits I suppose :)

Yes, I admit it's bit due to habit. But there's at least one technical reason to avoid them. They cannot be used in .h files included by assembly files, so there are places where they are inappropriate. Why not use comments that are acceptable everywhere?

jforissier · 2020-07-31T13:39:17Z

core/pta/attestation.c

+				uint8_t **d, size_t *d_size)
+{
+
+	uint32_t size;


= 0; (coding rule, all local variables must be initialized)

jforissier · 2020-07-31T13:40:26Z

core/pta/attestation.c

+		return TEE_ERROR_SECURITY;
+
+	if (priv[offset + 1] != 0x82)
+		return TEE_ERROR_SECURITY;


if (priv[0] != 0x30 || priv[1] != 0x82 || priv[offset] != 0x02 || priv[offset + 1] != 0x82) return TEE_ERROR_SECURITY;

What are the guarantees that accessing priv[x] is valid?

jforissier · 2020-07-31T13:49:49Z

core/pta/attestation.c

+	att_data.sig_size = p[3].memref.size;
+
+	// Allocating the memory for the Attestation data
+	att_data.iv = calloc(att_data.iv_size, sizeof(uint8_t));


Memory leak if set_data() is called several times?

You are right, I will address that

ruchi393 · 2020-08-10T05:59:13Z

core/pta/attestation.c

+	return TEE_SUCCESS;
+}
+
+static TEE_Result decrypt_priv_key(uint8_t *plain, size_t *plain_size)


Some platforms may have endorsement keys embedded in the SoC itself. In those scenarios it may be useful to provide this function as a weak function which platforms can implement at their end.

Thank you for reviewing my PR.

This function decrypts the attestation identifier key (AIK), which is stored in the attestation data struct (Image here). So this function does not decrypt the endorsement key this is done by the get_endorsement_key function. And there jfossier already requested the __weak symbol. Therefore I do not think the weak symbol is necessary here.

Sorry, I thought about it again and after some research I understand your suggestion. You are absolutely right, I think it is the preferred solution to replace the decrypt_priv_key() function and ditch the get_endorsementkey() function. This will also keep the endorsement key in hardware.

No issues, I think you understand now what I was trying to say. There are hardwares where endorsement key never leaves the SoC. In such cases, SoC vendors may want to override the complete decrypt_priv_key function as per their requirements.

jenswi-linaro · 2020-08-10T10:11:58Z

core/pta/attestation.c

+
+TEE_Result __weak get_endorsement_key(uint8_t *key)
+{
+	// TODO: Dummy function get_endorsement_key


Could huk_subkey_derive() with a new enum huk_subkey_usage be used for this?
It may still make sense to keep this function __weak.

Yes, it could. But the preferred way would be to keep the endorsement key in hardware, as discussed with ruchi393. In case, there is no appropriate hardware for keeping the key in hardware this is a viable option. But I do not like the idea to include it here, because the stuff with the endorsement key is always hardware dependent and you must think about where to get your endorsement key from.

jenswi-linaro · 2020-08-10T10:14:12Z

core/pta/attestation.c

+TEE_Result __weak get_sys_measurement(uint8_t *ptr)
+{
+	// TODO: Dummy function
+	// get_sys_measurement -> do something hardware specific


Measurement as in measured boot in case you have a TPM?

Yes, exactly. But we do not have a TPM in mind. We would prefer to provision the Chips (Processor or FPGA) and then boot them with secure boot/HAB into a secure state.

jenswi-linaro · 2020-08-10T10:19:13Z

core/pta/attestation.h

+ * Dummy functions makred as __weak,
+ * some hardware specific hooks needed.
+ */
+TEE_Result get_sys_measurement(uint8_t *ptr);


These functions need a prefix.

jenswi-linaro · 2020-08-10T10:26:39Z

lib/libutee/include/pta_attestation.h

+		{ 0xa2b0b139, 0x82dc, 0x4ffc, \
+			{ 0xa8, 0xa8, 0x7d, 0x7c, 0x63, 0x66, 0xe9, 0x84 } }
+
+#define TA_NAME		"attestation.pta"


This isn't needed here.

jenswi-linaro · 2020-08-10T10:31:44Z

core/pta/attestation.c

+	crypto_cipher_final(ctx);
+	*plain_size = enc_size - plain[enc_size - 1];
+
+	return res;


Memory leakage, ctx isn't freed.

jenswi-linaro · 2020-08-10T10:32:12Z

core/pta/attestation.c

+
+	res = crypto_hash_init(ctx);
+	if (res)
+		return res;


Memory leakage, ctx isn't freed.

I do think, I free it with crypto_hash_free_ctx(ctx); on line 239.

Not when returning here.

Oh, I got it. That is the reason for this goto err: structure you are using in the core.

jenswi-linaro · 2020-08-10T10:32:45Z

core/pta/attestation.c

+
+	res = pub_asn1_decode(&n_ptr, &e_ptr, &n_size, &e_size);
+	if (res != TEE_SUCCESS)
+		return res;


Memory leakage, key_pair isn't freed.

Please correct me if I am wrong, but there is no function like crypto_acipher_free_rsa_keypair. There is only one for the public key. So I have to free each bignum seperatly?

Suggested change

return res;

crypto_bignum_free(key_pair->e);

crypto_bignum_free(key_pair->d);

crypto_bignum_free(key_pair->n);

crypto_bignum_free(key_pair->p);

crypto_bignum_free(key_pair->q);

crypto_bignum_free(key_pair->qp);

crypto_bignum_free(key_pair->dp);

It's because that function hasn't been needed yet. Feel free to add one.

Fix here, but the crypto_acipher_free_rsa_keypair problem, I will adress it tomorrow.

crypto_acipher_free_rsa_keypair#4028

jenswi-linaro · 2020-08-10T10:34:32Z

core/pta/attestation.c

+		return res;
+
+	// decode the pubkey (AIK)
+	struct rsa_public_key key;


Please declare local variables at the beginning of a code block.

jenswi-linaro · 2020-08-10T10:35:13Z

core/pta/attestation.c

+
+	res = decrypt_priv_key(plain_priv, &plain_priv_len);
+	if (res)
+		return res;


Memory leakage, plain_priv isn't freed.

elias-vd · 2020-09-10T18:32:02Z

Greetings, It is nearly a month without comments. So I suggest to close the PR and the ones associated with it. I have to direct my energy to different projects. The repos, I will keep them on Githup for the future. Thank you all for your comments and if anyone in the future wants to ask questions or just talk about it, feel free to send me an email.

jenswi-linaro · 2020-09-11T05:36:55Z

@elias-vd, the lack of comments is could very well be due to no one noticing that you made updates. Sometime notifications aren't sent out when new patches are added. So adding some short comment each time after you've updated helps getting attention.

jenswi-linaro · 2020-09-11T05:39:51Z

In order to make progress here, please squash in all the fixes to their parent commit and rebase on master.

brenzi · 2020-09-30T08:31:24Z

before we close this PR, I'd consider taking this over from @elias-vd (who was on my team when he did this work).
If there is a chance to get this merged and only little to do.

jbech-linaro · 2020-09-30T08:59:10Z

before we close this PR, I'd consider taking this over from @elias-vd (who was on my team when he did this work).
If there is a chance to get this merged and only little to do.

Please do, I personally think remote attestation is a very useful feature and building block for greater security solutions. I'd like to be part of this discussion, but I've too many other things going on right now. Which is a challenge for everyone here I suppose.

brenzi · 2020-09-30T13:58:24Z

awaiting permission from @elias-vd for his branch

github-actions · 2020-10-31T00:43:26Z

This pull request has been marked as a stale pull request because it has been open (more than) 30 days with no activity. Remove the stale label or add a comment, otherwise this pull request will automatically be closed in 5 days. Note, that you can always re-open a closed issue at any time.

brenzi · 2020-10-31T06:54:10Z

I intend to rebase, don't close

github-actions · 2020-12-01T01:05:48Z

This pull request has been marked as a stale pull request because it has been open (more than) 30 days with no activity. Remove the stale label or add a comment, otherwise this pull request will automatically be closed in 5 days. Note, that you can always re-open a closed issue at any time.

brenzi · 2020-12-01T08:14:48Z

I have resolved the first few conflicts. Will observe CI

github-actions · 2021-01-01T01:39:45Z

This pull request has been marked as a stale pull request because it has been open (more than) 30 days with no activity. Remove the stale label or add a comment, otherwise this pull request will automatically be closed in 5 days. Note, that you can always re-open a closed issue at any time.

brenzi · 2021-01-03T19:19:07Z

@jenswi-linaro I'll need some help with interpreting CI trouble. A had resolved conflicts a while ago but CI checks fail....

jenswi-linaro · 2021-01-04T09:45:16Z

Please squash and rebase on master. That should hopefully take care of the CI errors.

brenzi · 2021-01-04T10:51:02Z

I don't get it:

ERROR: Missing Signed-off-by: line by nominal patch author '"....'

the squashed commit contains that line

jenswi-linaro · 2021-01-04T11:08:29Z

That means that you need to add your Signed-off-by tag too.

jforissier · 2021-01-04T15:05:02Z

$ git fetch github pull/4011/head 2>/dev/null && git show FETCH_HEAD | egrep '(^Author|Signed-off)' | sed 's/^ *//'
Author: Elias von Däniken <elias.vondaeniken@scs.ch>
Signed-off-by: E.von Däniken <elias.vondaeniken@bluewin.ch>
Signed-off-by: Alain Brenzikofer <alain.brenzikofer@scs.ch>

As you can see in the first two lines, the text after the : is not identical. Please check your Git configuration -- typically git config --global user.name and git config --global user.email. Once the settings are OK you may update the Author field in the commit by running: git commit --amend --reset-author.

brenzi · 2021-01-04T15:09:25Z

Elias is no longer at SCS, that's the reason for the authorship email change. @elias-vd may I ask you to reset the commit authorship to your bluewin address as suggested above?

github-actions · 2021-02-04T01:04:41Z

This pull request has been marked as a stale pull request because it has been open (more than) 30 days with no activity. Remove the stale label or add a comment, otherwise this pull request will automatically be closed in 5 days. Note, that you can always re-open a closed issue at any time.

brenzi · 2021-02-04T19:02:13Z

I'll reach out to @elias-vd again....

Signed-off-by: E.von Däniken <elias.vondaeniken@bluewin.ch> Signed-off-by: Alain Brenzikofer <alain.brenzikofer@scs.ch>

jenswi-linaro · 2021-02-17T07:37:41Z

What is the current for this PR?

brenzi · 2021-02-17T07:42:11Z

We need to do a bit of work to keep up with changes after the latest rebase breaking our build. I currently can't look into it but I'll reach out to @elias-vd.

jenswi-linaro · 2021-02-17T08:55:36Z

OK, please let us know with an explicit comment in this PR when it should be reviewed again.

brenzi · 2021-02-26T15:42:58Z

After discussing with @elias-vd we think it would be easy to make the build pass again, but we wonder how big the chances are that this PR will ever be merged and the feature maintained. We are currently not able to maintain this or provide a CI test suite.

So, if the OP-TEE core team is motivated to merge this PR and if there is someone to maintain remote attestation, we're happy to do the finishing on this PR. But without such commitment we have to let this go.

etienne-lms · 2021-02-27T12:34:39Z

I apology for not having spent more time on this.
I think I catch the idea, the concept looks great even if I can't tell the design is bulletproof but maybe is. This is valuable work for the open source.

Why is the PTA such complex? I like the idea of having a fingerprint of the executed TA. @jenswi-linaro may say a work on this. It could be part of the instance context. Format of attestation data and certif is a concern. If this contribution really on a substratee format, we should name this substratee_ta_attestion or find a generic way for various client frameworks.

It would ease to clearly describe the APIs of the TA (optee_examples) and PTA (optee_os).
Text describing was command do and describing each invocation parameter.

This really need to go through a review process to land, unless what we can't maintain unread untested materials. Sorry for the delay, we all have things to do :)

jenswi-linaro · 2021-03-01T13:55:53Z

I agree with @etienne-lms, the idea is sound. But it's only worth doing if we can do it properly.
I'm prepared to review and come with suggestions, but not if it's just going to stall again.

brenzi · 2021-03-01T16:42:23Z

@jenswi-linaro understood. Then I'd like to make it clear that we will currently only be able to do minor changes. Your review would be highly welcome, but I fear we (our company scs) won't invest more into this than we already did until we have a paying customer project requiring it. (We are actually in the middle of founding a spinoff which will certainly be interested in RA for TrustZone! But it may take a moment)

jenswi-linaro · 2021-03-02T10:17:46Z

I see, perhaps it's best to let this rest until you can commit to see this through.

github-actions · 2021-04-02T01:40:28Z

This pull request has been marked as a stale pull request because it has been open (more than) 30 days with no activity. Remove the stale label or add a comment, otherwise this pull request will automatically be closed in 5 days. Note, that you can always re-open a closed issue at any time.

brenzi · 2021-04-06T11:06:50Z

I see a potential to dedicate resources to this 1-2 months from now. posting to keep it alive

jenswi-linaro · 2021-04-06T11:47:09Z

Added enhancement label to keep it alive.

elias-vd force-pushed the poc-remote-attestation branch from a97f2ef to 4d2d616 Compare July 31, 2020 12:03

This was referenced Jul 31, 2020

[RFC] POC Remote Attestation linaro-swg/optee_examples#76

Closed

[RFC] POC Remote Attestation OP-TEE/build#433

Closed

jforissier reviewed Jul 31, 2020

View reviewed changes

ruchi393 reviewed Aug 10, 2020

View reviewed changes

jenswi-linaro reviewed Aug 10, 2020

View reviewed changes

github-actions bot added the Stale label Oct 31, 2020

jforissier removed the Stale label Oct 31, 2020

github-actions bot added the Stale label Dec 1, 2020

github-actions bot removed the Stale label Dec 2, 2020

github-actions bot added the Stale label Jan 1, 2021

github-actions bot removed the Stale label Jan 4, 2021

brenzi force-pushed the poc-remote-attestation branch from 32e9870 to 08e2b5c Compare January 4, 2021 10:45

brenzi force-pushed the poc-remote-attestation branch from 08e2b5c to e0f11dc Compare January 4, 2021 14:42

github-actions bot added the Stale label Feb 4, 2021

github-actions bot removed the Stale label Feb 5, 2021

elias-vd force-pushed the poc-remote-attestation branch 2 times, most recently from ebae9fb to e86173a Compare February 9, 2021 16:36

brenzi force-pushed the poc-remote-attestation branch from 3b50b06 to 586e144 Compare February 13, 2021 18:09

poc remote attestation

af4063b

Signed-off-by: E.von Däniken <elias.vondaeniken@bluewin.ch> Signed-off-by: Alain Brenzikofer <alain.brenzikofer@scs.ch>

brenzi force-pushed the poc-remote-attestation branch from 586e144 to af4063b Compare February 13, 2021 18:12

github-actions bot added the Stale label Apr 2, 2021

jenswi-linaro added enhancement and removed Stale labels Apr 6, 2021

ruchi393 mentioned this pull request Dec 2, 2021

[RFC v4] Remote attestation PTA #5010

Closed


		TEE_Result res = TEE_ERROR_GENERIC;

		typedef struct attestation_certificate {

-		return res;
+	crypto_bignum_free(key_pair->e);
+	crypto_bignum_free(key_pair->d);
+	crypto_bignum_free(key_pair->n);
+	crypto_bignum_free(key_pair->p);
+	crypto_bignum_free(key_pair->q);
+	crypto_bignum_free(key_pair->qp);
+	crypto_bignum_free(key_pair->dp);

[RFC] POC Remote Attestation #4011

Are you sure you want to change the base?

[RFC] POC Remote Attestation #4011

Conversation

elias-vd commented Jul 31, 2020 • edited

jforissier 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

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

elias-vd Aug 10, 2020 • edited

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

elias-vd commented Sep 10, 2020

jenswi-linaro commented Sep 11, 2020

jenswi-linaro commented Sep 11, 2020

brenzi commented Sep 30, 2020 • edited

jbech-linaro commented Sep 30, 2020

brenzi commented Sep 30, 2020

github-actions bot commented Oct 31, 2020

brenzi commented Oct 31, 2020

github-actions bot commented Dec 1, 2020

brenzi commented Dec 1, 2020

github-actions bot commented Jan 1, 2021

brenzi commented Jan 3, 2021

jenswi-linaro commented Jan 4, 2021

brenzi commented Jan 4, 2021 • edited

jenswi-linaro commented Jan 4, 2021

jforissier commented Jan 4, 2021

brenzi commented Jan 4, 2021

github-actions bot commented Feb 4, 2021

brenzi commented Feb 4, 2021

jenswi-linaro commented Feb 17, 2021

brenzi commented Feb 17, 2021

jenswi-linaro commented Feb 17, 2021

elias-vd commented Jul 31, 2020 •

edited

elias-vd Aug 10, 2020 •

edited

brenzi commented Sep 30, 2020 •

edited

brenzi commented Jan 4, 2021 •

edited

brenzi commented Mar 1, 2021 •

edited