May 2020 - TF-M - lists.trustedfirmware.org

Re: [TF-M] Query on persistent keys Crypto API

by Soby Mathew

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

3 years, 11 months

1
0
0 0

Re: [TF-M] BL2 scatter file issue

by Tamas Ban

Hi Mark, Thank you, I think your observation is right. I have opened the following ticket to fix: https://developer.trustedfirmware.org/T749 Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mark Horvath via TF-M Sent: 13 May 2020 17:13 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] BL2 scatter file issue Hi, I think there is an error in the usual BL2 scatter file, for example in platform<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform>/ext<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext>/target<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…>/musca_b1<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…>/Device<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…>/Source<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…>/armclang<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…>/musca_bl2.sct<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…> The maximum size of the region ER_DATA is set to BL2_DATA_SIZE which is usually equals to the size of the available RAM. But not just the ER_DATA region have to be placed into RAM but also the BOOT_DATA, the heap and the MSP stack. In addition if the TFM_MULTI_CORE_TOPOLOGY macro is set then the BOOT_DATA is not placed at the start of the RAM in TF-M but after unprivileged data. So I would recommend to use the same check like in tfm_common_s.sct and adjust BOOT_DATA start: --- a/platform/ext/target/musca_b1/Device/Source/armclang/musca_bl2.sct +++ b/platform/ext/target/musca_b1/Device/Source/armclang/musca_bl2.sct @@ -24,10 +24,10 @@ LR_CODE BL2_CODE_START { * (+RO) } - TFM_SHARED_DATA BL2_DATA_START ALIGN 32 EMPTY BOOT_TFM_SHARED_DATA_SIZE { + TFM_SHARED_DATA BOOT_TFM_SHARED_DATA_BASE ALIGN 32 EMPTY BOOT_TFM_SHARED_DATA_SIZE { } - ER_DATA +0 BL2_DATA_SIZE { + ER_DATA +0 { * (+ZI +RW) } @@ -37,4 +37,15 @@ LR_CODE BL2_CODE_START { ARM_LIB_HEAP +0 ALIGN 8 EMPTY BL2_HEAP_SIZE { } + + /* This empty, zero long execution region is here to mark the limit address + * of the last execution region that is allocated in SRAM. + */ + SRAM_WATERMARK +0 EMPTY 0x0 { + } + + /* Make sure that the sections allocated in the SRAM does not exceed the + * size of the SRAM available. + */ + ScatterAssert(ImageLimit(SRAM_WATERMARK) <= BL2_DATA_START + BL2_DATA_SIZE) } What are your thoughts? Best regards, Mark

3 years, 11 months

1
0
0 0

BL2 scatter file issue

by Mark Horvath

Hi, I think there is an error in the usual BL2 scatter file, for example in platform<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform>/ext<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext>/target<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…>/musca_b1<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…>/Device<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…>/Source<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…>/armclang<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…>/musca_bl2.sct<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…> The maximum size of the region ER_DATA is set to BL2_DATA_SIZE which is usually equals to the size of the available RAM. But not just the ER_DATA region have to be placed into RAM but also the BOOT_DATA, the heap and the MSP stack. In addition if the TFM_MULTI_CORE_TOPOLOGY macro is set then the BOOT_DATA is not placed at the start of the RAM in TF-M but after unprivileged data. So I would recommend to use the same check like in tfm_common_s.sct and adjust BOOT_DATA start: --- a/platform/ext/target/musca_b1/Device/Source/armclang/musca_bl2.sct +++ b/platform/ext/target/musca_b1/Device/Source/armclang/musca_bl2.sct @@ -24,10 +24,10 @@ LR_CODE BL2_CODE_START { * (+RO) } - TFM_SHARED_DATA BL2_DATA_START ALIGN 32 EMPTY BOOT_TFM_SHARED_DATA_SIZE { + TFM_SHARED_DATA BOOT_TFM_SHARED_DATA_BASE ALIGN 32 EMPTY BOOT_TFM_SHARED_DATA_SIZE { } - ER_DATA +0 BL2_DATA_SIZE { + ER_DATA +0 { * (+ZI +RW) } @@ -37,4 +37,15 @@ LR_CODE BL2_CODE_START { ARM_LIB_HEAP +0 ALIGN 8 EMPTY BL2_HEAP_SIZE { } + + /* This empty, zero long execution region is here to mark the limit address + * of the last execution region that is allocated in SRAM. + */ + SRAM_WATERMARK +0 EMPTY 0x0 { + } + + /* Make sure that the sections allocated in the SRAM does not exceed the + * size of the SRAM available. + */ + ScatterAssert(ImageLimit(SRAM_WATERMARK) <= BL2_DATA_START + BL2_DATA_SIZE) } What are your thoughts? Best regards, Mark

3 years, 11 months

1
0
0 0

Re: [TF-M] Query on persistent keys Crypto API

by Sherry Zhang

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

3 years, 11 months

2
1
0 0

Query on persistent keys Crypto API

by Kevin Townsend

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

3 years, 11 months

1
0
0 0

Profile Small design document is merged

by David Hu

Hi all, Profile Small design document is merged into TF-M design documents. Thanks again for your help and reviews. Comments and feedbacks are still and always welcome. The patch set to enable Profile Small is uploaded and under review. Could you please take a look at https://review.trustedfirmware.org/q/topic:%22profile-s-config%22+(status:o… Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Thursday, May 7, 2020 12:03 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Request for final review of Profile Small design document Hi all, Profile Small design document has been reviewed for a long time. Thanks a lot for all your comments and suggestions. I'd like to request a final round review. If no further critical comment, the Profile Small design document will be merged next Wednesday. If you have interest in reading the document again, please access https://review.trustedfirmware.org/c/trusted-firmware-m/+/3598. Best regards, Hu Ziji

3 years, 11 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - May 14

by Andrew Thoelke

Hi, Following on from the presentation and discussion on Ken's "Default Handles" proposal on 30 April, we have made some updates following the feedback and further implementation consideration. I (or Ken if he attends) can present an update on the proposal. I also mentioned last time that there is some missing context for this proposal. We are working on an update for PSA-FF-M v1.1 that will provide an enhancement of the v1.0 'IPC model' for secure services, and also a 'Secure Function model' which is similar to the 'library model' of TF-M today. The objective is a single architecture that enables secure service developers to select the framework features required for the complexity of the service; and the framework implementation to be optimised for simple systems. On Thursday, I would like to present an introduction to this PSA-FF-M v1.1 roadmap, and outline the steps that we think are required. Regards, Andrew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 06 May 2020 10:17 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - May 14 Hello, The next Technical Forum is planned on Thursday, May 14 at 15:00-16:00 UTC. Please reply on this email with your proposals for agenda topics. To avoid confusion here are some local times: https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=… Vancouver<https://www.timeanddate.com/worldclock/canada/vancouver> (Canada - British Columbia) Thursday, 14 May 2020, 08:00:00 PDT<https://www.timeanddate.com/time/zones/pdt> UTC-7 hours Chicago<https://www.timeanddate.com/worldclock/usa/chicago> (USA - Illinois) Thursday, 14 May 2020, 10:00:00 CDT<https://www.timeanddate.com/time/zones/cdt> UTC-5 hours Cambridge<https://www.timeanddate.com/worldclock/uk/cambridge> (United Kingdom - England) Thursday, 14 May 2020, 16:00:00 BST<https://www.timeanddate.com/time/zones/bst> UTC+1 hour Shanghai<https://www.timeanddate.com/worldclock/china/shanghai> (China - Shanghai Municipality) Thursday, 14 May 2020, 23:00:00 CST<https://www.timeanddate.com/time/zones/cst-china> UTC+8 hours Best regards, Anton Komlev

3 years, 11 months

1
0
0 0

Re: [TF-M] [TF-A] Project Maintenance Proposal for tf.org Projects

by Sandrine Bailleux

Hi all, On 5/5/20 9:04 AM, Sandrine Bailleux via TF-A wrote: > I've received very little feedback on version 2 of the proposal, which > hints that we are reaching an agreement. Thus, I plan to finalize the > proposal this week. This can then become part of our development flow > for all trustedfirmware.org projects. > > Thanks again for all the inputs! The project maintenance process is now live. The document has been moved here (with a few minor edits to turn it from a proposal to an effective process): https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p… Thanks! Regards, Sandrine

3 years, 11 months

1
0
0 0

TFM 1.0 integration merged into upcoming Zephyr 2.3

by Kevin Townsend

Hi, Just as a FYI, TF-M 1.0 support was merged into Zephyr RTOS this week, meaning that it will be included by default in Zephyr starting with the upcoming 2.3 release. Zephyr is used on the non-secure side, and TF-M is used on the secure side, with the TF-M build happening as part of the normal Zephyr build process, meaning no knowledge of TF-M internals is required to get started. It's also worth highlighting QEMU integration with Zephyr+TF-M. Using the MPS2 AN521 target, you can run application from the command-line with QEMU, meaning that you can create test applications that use the PSA APIs with no HW required, or perform certain application tests purely in SW. As an example, the following sample was run with a clean install of Zephyr, showing QEMU output and demonstrating how to use the initial attestation, crypo and secure storage services: https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/tfm_integr… $ mkdir zephyrtfm && cd zephyrtfm $ west init $ west update $ west build -p -b mps2_an521_nonsecure zephyr/samples/tfm_integration/psa_level_1/ -t run [INF] Starting bootloader [INF] Swap type: none [INF] Swap type: none [INF] Bootloader chainload address offset: 0x80000 [INF] Jumping to the first image slot [Sec Thread] Secure image initializing! TF-M isolation level is: 1 Booting TFM v1.0 *** Booting Zephyr OS build zephyr-v2.2.0-2701-ge5aaf21a73c7 *** [00:00:00.003,000] <inf> app: app_cfg: Creating new config file with UID 0x155cfda7a [00:00:03.518,000] <inf> app: att: System IAT size is: 545 bytes. [00:00:03.518,000] <inf> app: att: Requesting IAT with 64 byte challenge. [00:00:06.925,000] <inf> app: att: IAT data received: 545 bytes. 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 D2 84 43 A1 01 26 A0 59 01 D5 AA 3A 00 01 24 FF ..C..&.Y...:..$. 00000010 58 40 00 11 22 33 44 55 66 77 88 99 AA BB CC DD X@.."3DUfw...... 00000020 EE FF 00 11 22 33 44 55 66 77 88 99 AA BB CC DD ...."3DUfw...... 00000030 EE FF 00 11 22 33 44 55 66 77 88 99 AA BB CC DD ...."3DUfw...... 00000040 EE FF 00 11 22 33 44 55 66 77 88 99 AA BB CC DD ...."3DUfw...... 00000050 EE FF 3A 00 01 24 FB 58 20 A0 A1 A2 A3 A4 A5 A6 ..:..$.X ....... 00000060 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6 ................ 00000070 B7 B8 B9 BA BB BC BD BE BF 3A 00 01 25 00 58 21 .........:..%.X! 00000080 01 FA 58 75 5F 65 86 27 CE 54 60 F2 9B 75 29 67 ..Xu_e.'.T`..u)g 00000090 13 24 8C AE 7A D9 E2 98 4B 90 28 0E FC BC B5 02 .$..z...K.(..... 000000A0 48 3A 00 01 24 FA 58 20 AA AA AA AA AA AA AA AA H:..$.X ........ 000000B0 BB BB BB BB BB BB BB BB CC CC CC CC CC CC CC CC ................ 000000C0 DD DD DD DD DD DD DD DD 3A 00 01 24 F8 20 3A 00 ........:..$. :. 000000D0 01 24 F9 19 30 00 3A 00 01 24 FD 82 A5 01 63 53 .$..0.:..$....cS 000000E0 50 45 04 65 30 2E 30 2E 30 05 58 20 BF E6 D8 6F PE.e0.0.0.X ...o 000000F0 88 26 F4 FF 97 FB 96 C4 E6 FB C4 99 3E 46 19 FC .&..........>F.. 00000100 56 5D A2 6A DF 34 C3 29 48 9A DC 38 06 66 53 48 V].j.4.)H..8.fSH 00000110 41 32 35 36 02 58 20 B4 74 47 EE 2A 2C A4 73 B2 A256.X .tG.*,.s. 00000120 A5 55 D4 73 6D 7F 8B 42 97 94 C2 36 BC 03 33 04 .U.sm..B...6..3. 00000130 29 C3 E5 9C FF CD C4 A5 01 64 4E 53 50 45 04 65 )........dNSPE.e 00000140 30 2E 30 2E 30 05 58 20 B3 60 CA F5 C9 8C 6B 94 0.0.0.X .`....k. 00000150 2A 48 82 FA 9D 48 23 EF B1 66 A9 EF 6A 6E 4A A3 *H...H#..f..jnJ. 00000160 7C 19 19 ED 1F CC C0 49 06 66 53 48 41 32 35 36 |......I.fSHA256 00000170 02 58 20 07 16 EE 98 EA 6A CC 0F 7A 9A 21 46 E6 .X .....j..z.!F. 00000180 CD 26 B4 0B 3D 4B 35 B4 9C B1 89 57 56 12 66 AB .&..=K5....WV.f. 00000190 72 BD 47 3A 00 01 25 01 77 77 77 77 2E 74 72 75 r.G:..%.wwww.tru 000001A0 73 74 65 64 66 69 72 6D 77 61 72 65 2E 6F 72 67 stedfirmware.org 000001B0 3A 00 01 24 F7 71 50 53 41 5F 49 4F 54 5F 50 52 :..$.qPSA_IOT_PR 000001C0 4F 46 49 4C 45 5F 31 3A 00 01 24 FC 72 30 36 30 OFILE_1:..$.r060 000001D0 34 35 36 35 32 37 32 38 32 39 31 30 30 31 30 58 456527282910010X 000001E0 40 51 33 D9 87 96 A9 91 55 18 9E BF 14 7A E1 76 @Q3.....U....z.v 000001F0 F5 0F A6 3C 7B F2 3A 1B 59 24 5B 2E 67 A8 F8 AB ...<{.:.Y$[.g... 00000200 12 A3 AC 9C E8 44 95 13 60 82 E9 49 43 7B 4E C5 .....D..`..IC{N. 00000210 2C 0D E5 EC BA 72 C5 35 2C F7 C9 1C B7 26 93 80 ,....r.5,....&.. 00000220 12 . [00:00:06.982,000] <inf> app: Generating 256 bytes of random data. 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 0C 90 D8 0C FA 0F 97 00 29 B2 AE 5C 90 48 3D 39 ........)..\.H=9 00000010 00 14 6C A3 84 E2 C0 C9 82 F5 8B A6 E9 38 66 16 ..l..........8f. 00000020 EA B7 E7 78 91 0D 6D 87 5B B8 04 0B 8B E0 74 23 ...x..m.[.....t# 00000030 7D 11 E2 17 32 34 1A 01 71 24 29 D5 7C 05 B1 11 }...24..q$).|... 00000040 A0 97 20 82 03 FF D6 76 9D 6F D5 52 45 C9 E1 17 .. ....v.o.RE... 00000050 69 DF 18 B6 8E 0C AA 3B 74 B4 EF 97 D9 0E 82 25 i......;t......% 00000060 E1 97 0E 6E 4F 0F DE B9 20 60 34 A4 EA 0D 9A B3 ...nO... `4..... 00000070 3F C4 9A CF F3 5E F2 2C 78 96 6F 0E DD E3 E6 CB ?....^.,x.o..... 00000080 DC 19 26 A3 E8 8E 07 0E 1E 5B DB 59 B0 05 41 E2 ..&......[.Y..A. 00000090 A4 ED 90 35 8B AB 1C B8 00 7E BB 2D 22 FE 7A EA ...5.....~.-".z. 000000A0 CF A0 BB DF 4F 2B 32 55 C9 07 0D 3D CE B8 43 78 ....O+2U...=..Cx 000000B0 63 33 6C 79 CA 43 3A 4F 0B 93 33 2B B1 D2 B0 A7 c3ly.C:O..3+.... 000000C0 44 A0 E9 E8 BF FB FD 89 2A 44 7A 60 2D 9B 0F 9E D.......*Dz`-... 000000D0 0D B1 0E 9D 5C 60 5D E6 92 78 36 79 68 37 24 C5 ....\`]..x6yh7$. 000000E0 57 7F 2E DF 53 D2 7B 3F EE 56 9B 9E BB 39 2C B6 W...S.{?.V...9,. 000000F0 AA FF B5 3B 59 4E 40 1D E0 34 50 05 D0 E0 95 12 ...;YN@..4P..... [00:00:07.004,000] <inf> app: Calculating SHA-256 hash of value. 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 E3 B0 C4 42 98 FC 1C 14 9A FB F4 C8 99 6F B9 24 00000010 27 AE 41 E4 64 9B 93 4C A4 95 99 1B 78 52 B8 55 A big thanks to Karl, who was involved in getting this integration work going during his time as an assignee to the LITE team at Linaro, and to other members of the Zephyr community who got this over the finish line at the last minute, as well as to Mate for some last second feedback and debugging with TF-M in IPC mode using Zephyr. We hope this will make TF-M, and all the hard work that has gone into it, far more accessible to a wider range of people, with HW no longer being an immediate limitation to trying it out. Best regards, Kevin Townsend, Linaro

3 years, 11 months

1
0
0 0

Remove 'INDIVIDUAL_SW_COMPONENTS' support from attestation

by Tamas Ban

Hi, I let you notify that 'INDIVIDUAL_SW_COMPONENTS' support is planned to be removed from attestation service and bootloader. What is this? * Boootloader and SPE can exchange data through shared memory. This is needed to provide the boot status info to attestation service. The boot status info is included in the SW_COMPONENT claim in the attestation token. * Until now two types of data encoding was supported during this data sharing: * All boot status data item is passed as a single TLV entry: -DATTEST_BOOT_INTERFACE=INDIVIDUAL_CLAIMS * Boot status is already encoded to CBOR format at build time. Bootloader only updates a few field in it, and pass the CBOR object to SPE. Then attestation service just include this already CBOR formatted object to the token, without the need to applying further encoding. -DATTEST_BOOT_INTERFACE=CBOR_ENCODED_CLAIMS The 'INDIVIDUAL_CLAIMS' format is marked as deprecated feature for a while in the code base. Now the plan is to remove it and rely fully on the 'CBOR_ENCODED_CLAIMS' format. The build system support for this is present in TF-M for a long, and recently it was upstream to original MCUBoot 'imgtool' script as well. Next MCUBoot release (v1.6) will contain it. If you has any objection, because your project is using the 'INDIVIDUAL_CLAIMS' format then please let us know! BR, Tamas

3 years, 11 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

TF-M May 2020