Is Attestation already implemented?
Is there somewhere information on how Attestation is used.
I'm looking for user oriented information.
Thanks for your help.
Reinhard
Hi Tamas,
The patch has eliminated the test fail.
Thank you,
Andrej
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M
Sent: Thursday, May 14, 2020 2:32 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Boot seed in TFM Attestation tests
Hi Andrej,
The value of boot_seed is compared against a hard coded value. This behaviour can be turned off in test/suites/attestation/attest_token_test_values.h.
Then only the presence of boot_seed claim will be checked but its value not.
Could you test this patch:
diff --git a/test/suites/attestation/attest_token_test_values.h b/test/suites/attestation/attest_token_test_values.h
index 5910524..fe2b9d4 100644
--- a/test/suites/attestation/attest_token_test_values.h
+++ b/test/suites/attestation/attest_token_test_values.h
@@ -110,6 +110,8 @@
/* A 32 byte mostly random value. Binary.
* platform/ext/common/template/attest_hal.c
*/
+#define TOKEN_TEST_VALUE_BOOT_SEED NULL_Q_USEFUL_BUF_C
+/*
#define TOKEN_TEST_VALUE_BOOT_SEED \
(struct q_useful_buf_c) {\
(uint8_t[]){ \
@@ -120,6 +122,7 @@
},\
32\
}
+*/
#define TOKEN_TEST_REQUIRE_BOOT_SEED true /* Mandatory claim */
/* A text string in EAN 13 format
Tamas
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M
Sent: 14 May 2020 12:06
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Boot seed in TFM Attestation tests
Hello,
Using a real boot seed instead of the dummy one is causing a Attestation Service regression fail.
The log:
Running Test Suite Initial Attestation Service non-secure interface tests(TFM_ATTEST_TEST_2XXX)...
> Executing 'TFM_ATTEST_TEST_2004'
Description: 'ECDSA signature test of attest token'
decode_test_normal_sig() returned: -55
Attest token decode_test_normal_sig() has failed (Failed at ../../../../../../middleware/tfm/test/suites/attestation/non_secure/attestation_ns_interface_testsuite.c:136)
TEST FAILED!
Is it know issue?
Probably, it's better to use a real boot seed by the Attestation tests, returned by tfm_plat_get_initial_attest_key()?
Thank you,
Andrej Butok
Hello,
Let me announce the changes in TF-M project repository structure. To allow project grow up in a more organized way the existing codebase will be split on multiple repositories and placed under TF-M folder. This is the similar structure as all other projects have in git.trustedfirmware.org<https://git.trustedfirmware.org>.
This weekend TF-M git repository will be moved
from https://git.trustedfirmware.org/trusted-firmware-m.git
to https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git
The original URL will be supported for some time (as a link to the new one) giving time for adjustment. Current plan is to keep the redirection for 6 months but let me know please, if it makes any conflict and another depreciation period is better.
Best regards,
Anton Komlev
Hi Andrej,
The value of boot_seed is compared against a hard coded value. This behaviour can be turned off in test/suites/attestation/attest_token_test_values.h.
Then only the presence of boot_seed claim will be checked but its value not.
Could you test this patch:
diff --git a/test/suites/attestation/attest_token_test_values.h b/test/suites/attestation/attest_token_test_values.h
index 5910524..fe2b9d4 100644
--- a/test/suites/attestation/attest_token_test_values.h
+++ b/test/suites/attestation/attest_token_test_values.h
@@ -110,6 +110,8 @@
/* A 32 byte mostly random value. Binary.
* platform/ext/common/template/attest_hal.c
*/
+#define TOKEN_TEST_VALUE_BOOT_SEED NULL_Q_USEFUL_BUF_C
+/*
#define TOKEN_TEST_VALUE_BOOT_SEED \
(struct q_useful_buf_c) {\
(uint8_t[]){ \
@@ -120,6 +122,7 @@
},\
32\
}
+*/
#define TOKEN_TEST_REQUIRE_BOOT_SEED true /* Mandatory claim */
/* A text string in EAN 13 format
Tamas
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: 14 May 2020 12:06
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Boot seed in TFM Attestation tests
Hello,
Using a real boot seed instead of the dummy one is causing a Attestation Service regression fail.
The log:
Running Test Suite Initial Attestation Service non-secure interface tests(TFM_ATTEST_TEST_2XXX)...
> Executing 'TFM_ATTEST_TEST_2004'
Description: 'ECDSA signature test of attest token'
decode_test_normal_sig() returned: -55
Attest token decode_test_normal_sig() has failed (Failed at ../../../../../../middleware/tfm/test/suites/attestation/non_secure/attestation_ns_interface_testsuite.c:136)
TEST FAILED!
Is it know issue?
Probably, it's better to use a real boot seed by the Attestation tests, returned by tfm_plat_get_initial_attest_key()?
Thank you,
Andrej Butok
Hello,
Using a real boot seed instead of the dummy one is causing a Attestation Service regression fail.
The log:
Running Test Suite Initial Attestation Service non-secure interface tests(TFM_ATTEST_TEST_2XXX)...
> Executing 'TFM_ATTEST_TEST_2004'
Description: 'ECDSA signature test of attest token'
decode_test_normal_sig() returned: -55
Attest token decode_test_normal_sig() has failed (Failed at ../../../../../../middleware/tfm/test/suites/attestation/non_secure/attestation_ns_interface_testsuite.c:136)
TEST FAILED!
Is it know issue?
Probably, it's better to use a real boot seed by the Attestation tests, returned by tfm_plat_get_initial_attest_key()?
Thank you,
Andrej Butok
Hi Kevin
> Presumably this positions the merged change request around 1.0 beta 3, just to know where we stand with the API documentation versus implementation in TF-M?
Yes, you are right, the Crypto service as implemented in TF-M positions it very close to 1.0 beta 3 API specification. There is still some unimplemented functionality and some differences in error code with respect to the Beta3 specification as reported by the compliance test suite here : https://github.com/ARM-software/psa-arch-tests/blob/master/api-tests/docs/t…
> Presumably this migration to ID based accesses (versus handles) is still a work in progress, with a goal of perhaps being complete for 1.1?
Yes, TF-M depends on mbedcrypto to provide the necessary functionality. This is work in progress and hopefully available towards Q3 timeframe.
> If I comment out the psa_open_key call, I CAN access the public key in the next function, but only because I have a reference to the handle from when we first persisted the key, but I wouldn't have that handle in the real world if I was accessing a previously created key, and it seems we can't access persisted keys via ID yet, only handles, unless I'm missing something (perhaps obvious)?
Hopefully the solution suggested by Sherry is good enough for you to progress although your code will need to migrate to the API as specified in v1.0 at sometime in the future when TF-M implements the same.
Best Regards
Soby Mathew
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M
Sent: 13 May 2020 12:25
To: Sherry Zhang <Sherry.Zhang2(a)arm.com>
Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Query on persistent keys Crypto API
Hi Sherry,
Thanks for the quick response. The following sequence, explicitly closing the key after creation, seems to allow me to use psa_open_key, thank you:
/* Import the private key, creating the persistent key on success */
psa_import_key(&key_attributes, key_data, key_len, &key_handle);
/* Close the key to free up a volatile slot. */
psa_close_key(key_handle);
/* Now try to re-open the persisted key based on the key ID. */
psa_open_key(key_id, &key_handle);
Best regards,
Kevin
On Wed, 13 May 2020 at 12:48, Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>> wrote:
Hi Kevin,
Yes, you are right. The persistent key management described in PSA Cryptograhphy version 1.0 is not supported yet. It still follows the version 1.0 beta3 “key management”. I also met the “INSUFFICIENT_MEMORY” issue when I am implementing the PSA based PKCS#11 shim layer. In my side, it is caused by multiple calling psa_open_key while the key is still open. Each persistent key is saved only once in non- volatile area. But each time you open a key with the key handle, a new volatile area is used. In your code, psa_open_key is called directly after psa_import_key. So in this case, an additional volatile area is taken. The default volatile area number is 16. I suggestion you check whether similar case happen in your code(calling psa_open_key while the key is in open).
After provisioning, call psa_close_key to close the key. Then the volatile area is freed. Then to get the key handle later, you can call the psa_open_key directly.
Hope it can help you!
Regards,
Sherry Zhang
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Townsend via TF-M
Sent: Wednesday, May 13, 2020 5:47 PM
To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Subject: [TF-M] Query on persistent keys Crypto API
Hi,
Support for generating and working with persistent keys was recently merged into TF-M in the following change request: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3252/8
This corresponds to section 3.2.2 (Persistent keys) of the PSA Cryptography API 1.0 (dated 19/02/2020), although there seems to be some delay in implementing the functionality described in the API document. Page 209 ("Changes between 1.0 beta 3 and 1.0.0") states: "Removed psa_open_key and psa_close_key", but these functions are both present in the repo and seem to be used in the tests here: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/test/suites/cry…
Presumably this positions the merged change request around 1.0 beta 3, just to know where we stand with the API documentation versus implementation in TF-M?
Since this is a very useful feature in real world applications, I was working on a sample application in Zephyr demonstrating how it might be used during device provisioning, and I was hoping to better understand the differences between the implementation in TF-M today and the 1.0 API document, specifically around KEY IDs versus key handle based access?
The 1.0 API documentation, for example, describes:
psa_status_t psa_export_public_key(psa_key_id_t key,
uint8_t * data, size_t data_size, size_t * data_length);
But TF-M implements this add: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/interface/inclu…
psa_status_t psa_export_public_key(psa_key_handle_t handle,
uint8_t *data,
size_t data_size,
size_t *data_length);
Presumably this migration to ID based accesses (versus handles) is still a work in progress, with a goal of perhaps being complete for 1.1?
Should I still be calling psa_open_key in the interim, for example? Some examples like the AES + PKCS#7 test case here use that: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/test/suites/cry…
However, when I try to use psa_open_key when working with PSA_ECC_CURVE_SECP256R1, I get an INSUFFICIENT_MEMORY error, and I'm not sure how to get the psa_key_handle_t for subsequent operations like reading the key back.
I've posted the WIP code that fails trying to open the key here: https://gist.github.com/microbuilder/a326cc6b935f87f413d89e44f9d3de05#file-…
If I comment out the psa_open_key call, I CAN access the public key in the next function, but only because I have a reference to the handle from when we first persisted the key, but I wouldn't have that handle in the real world if I was accessing a previously created key, and it seems we can't access persisted keys via ID yet, only handles, unless I'm missing something (perhaps obvious)?
Best regards,
Kevin
Hi Kevin,
Yes, you are right. The persistent key management described in PSA Cryptograhphy version 1.0 is not supported yet. It still follows the version 1.0 beta3 “key management”. I also met the “INSUFFICIENT_MEMORY” issue when I am implementing the PSA based PKCS#11 shim layer. In my side, it is caused by multiple calling psa_open_key while the key is still open. Each persistent key is saved only once in non- volatile area. But each time you open a key with the key handle, a new volatile area is used. In your code, psa_open_key is called directly after psa_import_key. So in this case, an additional volatile area is taken. The default volatile area number is 16. I suggestion you check whether similar case happen in your code(calling psa_open_key while the key is in open).
After provisioning, call psa_close_key to close the key. Then the volatile area is freed. Then to get the key handle later, you can call the psa_open_key directly.
Hope it can help you!
Regards,
Sherry Zhang
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M
Sent: Wednesday, May 13, 2020 5:47 PM
To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org>
Subject: [TF-M] Query on persistent keys Crypto API
Hi,
Support for generating and working with persistent keys was recently merged into TF-M in the following change request: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3252/8
This corresponds to section 3.2.2 (Persistent keys) of the PSA Cryptography API 1.0 (dated 19/02/2020), although there seems to be some delay in implementing the functionality described in the API document. Page 209 ("Changes between 1.0 beta 3 and 1.0.0") states: "Removed psa_open_key and psa_close_key", but these functions are both present in the repo and seem to be used in the tests here: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/test/suites/cry…
Presumably this positions the merged change request around 1.0 beta 3, just to know where we stand with the API documentation versus implementation in TF-M?
Since this is a very useful feature in real world applications, I was working on a sample application in Zephyr demonstrating how it might be used during device provisioning, and I was hoping to better understand the differences between the implementation in TF-M today and the 1.0 API document, specifically around KEY IDs versus key handle based access?
The 1.0 API documentation, for example, describes:
psa_status_t psa_export_public_key(psa_key_id_t key,
uint8_t * data, size_t data_size, size_t * data_length);
But TF-M implements this add: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/interface/inclu…
psa_status_t psa_export_public_key(psa_key_handle_t handle,
uint8_t *data,
size_t data_size,
size_t *data_length);
Presumably this migration to ID based accesses (versus handles) is still a work in progress, with a goal of perhaps being complete for 1.1?
Should I still be calling psa_open_key in the interim, for example? Some examples like the AES + PKCS#7 test case here use that: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/test/suites/cry…
However, when I try to use psa_open_key when working with PSA_ECC_CURVE_SECP256R1, I get an INSUFFICIENT_MEMORY error, and I'm not sure how to get the psa_key_handle_t for subsequent operations like reading the key back.
I've posted the WIP code that fails trying to open the key here: https://gist.github.com/microbuilder/a326cc6b935f87f413d89e44f9d3de05#file-…
If I comment out the psa_open_key call, I CAN access the public key in the next function, but only because I have a reference to the handle from when we first persisted the key, but I wouldn't have that handle in the real world if I was accessing a previously created key, and it seems we can't access persisted keys via ID yet, only handles, unless I'm missing something (perhaps obvious)?
Best regards,
Kevin
Hi,
Support for generating and working with persistent keys was recently merged
into TF-M in the following change request:
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3252/8
This corresponds to section 3.2.2 (Persistent keys) of the PSA Cryptography
API 1.0 (dated 19/02/2020), although there seems to be some delay in
implementing the functionality described in the API document. Page 209
("Changes between 1.0 beta 3 and 1.0.0") states: "Removed psa_open_key and
psa_close_key", but these functions are both present in the repo and seem
to be used in the tests here:
https://git.trustedfirmware.org/trusted-firmware-m.git/tree/test/suites/cry…
Presumably this positions the merged change request around 1.0 beta 3, just
to know where we stand with the API documentation versus implementation in
TF-M?
Since this is a very useful feature in real world applications, I was
working on a sample application in Zephyr demonstrating how it might be
used during device provisioning, and I was hoping to better understand the
differences between the implementation in TF-M today and the 1.0 API
document, specifically around KEY IDs versus key handle based access?
The 1.0 API documentation, for example, describes:
psa_status_t psa_export_public_key(psa_key_id_t key,
uint8_t * data, size_t data_size, size_t
* data_length);
But TF-M implements this add:
https://git.trustedfirmware.org/trusted-firmware-m.git/tree/interface/inclu…
psa_status_t psa_export_public_key(psa_key_handle_t handle,
uint8_t *data,
size_t data_size,
size_t *data_length);
Presumably this migration to ID based accesses (versus handles) is still a
work in progress, with a goal of perhaps being complete for 1.1?
Should I still be calling psa_open_key in the interim, for example? Some
examples like the AES + PKCS#7 test case here use that:
https://git.trustedfirmware.org/trusted-firmware-m.git/tree/test/suites/cry…
However, when I try to use psa_open_key when working with
PSA_ECC_CURVE_SECP256R1, I get an INSUFFICIENT_MEMORY error, and I'm not
sure how to get the psa_key_handle_t for subsequent operations like reading
the key back.
I've posted the WIP code that fails trying to open the key here:
https://gist.github.com/microbuilder/a326cc6b935f87f413d89e44f9d3de05#file-…
If I comment out the psa_open_key call, I CAN access the public key in the
next function, but only because I have a reference to the handle from when
we first persisted the key, but I wouldn't have that handle in the real
world if I was accessing a previously created key, and it seems we can't
access persisted keys via ID yet, only handles, unless I'm missing
something (perhaps obvious)?
Best regards,
Kevin
