March 2023 - TF-M - lists.trustedfirmware.org

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, July 7, 15:00-16:00 UTC (West time zone). Please reply on this email with your proposals for agenda topics. Link to the forum: https://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz… Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

3 days, 9 hours

6
29
0 0

Technical Forum call - July 21

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, July 21, 7:00-8:00 UTC (East time zone). Please reply on this email with your proposals for agenda topics. Link to the forum: https://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT… Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

1 week, 3 days

6
31
0 0

Split build

by Bohdan.Hunko＠infineon.com

Hi everyone, Some time ago patch for split build<https://review.trustedfirmware.org/q/topic:%2522split-build%2522> of SPE, NSPE, BL2 was announced. I am interested on when this patch is planned to be merged? Regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>

2 weeks, 4 days

4
5
0 0

s_veneers linking problem when building uboot with flags -pie

by xulu＠allwinnertech.com

Hi experts, Recently we are building uboot with s_veneers.o, and found that we can not jump to tfm. The reason is that the jump addr is wrong when compileing with -pie. The symbol "tfm_vendor_aes_encrypt_with_hardware_ssk" in s_veneers.o. $ nm ./drivers/tfm/lib/s_veneers.o | grep tfm_vendor_aes_encrypt_with_hardware_ssk 04008029 A tfm_vendor_aes_encrypt_with_hardware_ssk Building uboot without cflags -pie, and the last line shows the wrong jump addr 0xf7fc7e61 0c0401f0 <__tfm_vendor_efuse_write_veneer>: c0401f0: b401 push {r0} c0401f2: 4802 ldr r0, [pc, #8] ; (c0401fc <__tfm_vendor_efuse_write_veneer+0xc>) c0401f4: 46fc mov ip, pc c0401f6: 4484 add ip, r0 c0401f8: bc01 pop {r0} c0401fa: 4760 bx ip c0401fc: f7fc7e61 .word 0xf7fc7e61 Building uboot without cflags -pie，and the last line shows the right jump addr 0x04008029. 0c040200 <__tfm_vendor_aes_encrypt_with_hardware_ssk_veneer>: c040200: b401 push {r0} c040202: 4802 ldr r0, [pc, #8] ; (c04020c <__tfm_vendor_aes_encrypt_with_hardware_ssk_veneer+0xc>) c040204: 4684 mov ip, r0 c040206: bc01 pop {r0} c040208: 4760 bx ip c04020a: bf00 nop c04020c: 04008029 .word 0x04008029 The linker flag -pie is default enabled in uboot(for relocation feature), and we need this feature. Could you please give us some pointers, suggestions or objections about this problem, Thanks!

2 months

2
1
0 0

Re: Please help check the failure of PSA_ALG_HKDF_EXPAND operation test

by Edward Yang

Hi Antonio, Thank you for taking the time to help confirm the function, and we've found out that this error just resulted from the incorrect initialization of 'operation' before calling PSA APIs, after fixing this bug, we also got the correct OKM. Thanks again for your support. Best Regards, Poppy Wu 吴偏偏 http://www.mxic.com.cn Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> 2023/03/23 21:58 Please respond to Antonio De Angelis <Antonio.DeAngelis(a)arm.com> To "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> cc nd <nd(a)arm.com> Subject [TF-M] Re: Please help check the failure of PSA_ALG_HKDF_EXPAND operation test Hi, I have tried the example below on mbed TLS running on an x86 Linux based host machine, and on the AN521 platform, and in both cases I can get consistent results, i.e. the value of the okm buffer at the end is: 0x3c, 0xb2, 0x5f, 0x25, 0xfa, 0xac, 0xd5, 0x7a, 0x90, 0x43, 0x4f, 0x64, 0xd0, 0x36, 0x2f, 0x2a, 0x2d, 0x2d, 0x0a, 0x90, 0xcf, 0x1a, 0x5a, 0x4c, 0x5d, 0xb0, 0x2d, 0x56, 0xec, 0xc4, 0xc5, 0xbf, 0x34, 0x00, 0x72, 0x08, 0xd5, 0xb8, 0x87, 0x18, 0x58, 0x65 Which I believe matches the expected output below. Given that your issue seems to be specific to the stm32l562e_dk platform, which uses its own crypto accelerator I believe rather than pure software implementation, I would suggest to have a look at the intermediate steps and compare your results against the AN521 platform results. You might want to raise this behaviour to the platform maintainer, as at this stage this seems to me to be a platform specific issue. I can only confirm that you are not misusing the PSA Crypto APIs here. Let me know if I can be of any more help. Thanks, Antonio From: Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Thursday, March 23, 2023 12:51 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Re: Please help check the failure of PSA_ALG_HKDF_EXPAND operation test I am going to have a look into this. Thanks for the instructions on how to reproduce. Might get a while to reply, please bear with me. Thanks, Antonio From: Edward Yang via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Thursday, March 23, 2023 01:36 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Please help check the failure of PSA_ALG_HKDF_EXPAND operation test Hi experts, Recently we're testing the HKDF-EXPAND interface with TF-M v1.7.0 on stm32l562e_dk platform. But the HKDF-EXPAND output didn't match the expected OKM. The test vector is as below: ALG : PSA_ALG_HKDF_EXPAND(PSA_ALG_SHA_256), "info" : decode_hex("f0f1f2f3f4f5f6f7f8f9"), "L" : 42, "PRK" : "077709362c2e32df0ddc3f0dc47bba6390b6c73bb50f9c3122ec844ad7c2b3e5" "OKM" : "3cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865" The corresponding code is as follow： int8_t okm[42]={0}; uint8_t info[] = {0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xf9}; uint8_t ikm[]= { 0x7,0x77,0x9,0x36,0x2c,0x2e,0x32,0xdf, 0xd,0xdc,0x3f,0xd,0xc4,0x7b,0xba,0x63, 0x90,0xb6,0xc7,0x3b,0xb5,0xf,0x9c,0x31, 0x22,0xec,0x84,0x4a,0xd7,0xc2,0xb3,0xe5 }; status = psa_key_derivation_setup(&operation, PSA_ALG_HKDF_EXPAND(PSA_ALG_SHA_256)); status = psa_key_derivation_input_bytes(&operation, PSA_KEY_DERIVATION_INPUT_SECRET, ikm, sizeof(ikm)); status = psa_key_derivation_input_bytes(&operation, PSA_KEY_DERIVATION_INPUT_INFO, info, sizeof(info)); status = psa_key_derivation_output_bytes( &operation, okm, sizeof(okm) ); The actual output okm is : 5a 1c ea 2d 24 ee 79 c5 bf ce 27 7b ... be b 3b 2e 19 18 77 ae, which didn't match the OKM of above test vector. Have we misused the HKDF-EXPAND operation? Best Regards, Poppy Wu 吴偏偏 http://www.mxic.com.cn -- TF-M mailing list -- tf-m(a)lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org

2 months, 1 week

1
0
0 0

How does TF-M deal with the faults originated from NSPE

by Sandeep Tripathy

Hi tf-m experts, I have a fundamental query on v8m trustZone and containability of secure fault and other escalated HardFaults to SPE. With BFHFNMINA set to '0' IIUC that a malicious actor in NSPE can willingly cause fault in SPE ? Is there a way to contain the fault in NS world? Thanks Sandeep

2 months, 1 week

4
5
1 0

Please help check the failure of PSA_ALG_HKDF_EXPAND operation test

by Edward Yang

Hi experts, Recently we're testing the HKDF-EXPAND interface with TF-M v1.7.0 on stm32l562e_dk platform. But the HKDF-EXPAND output didn't match the expected OKM. The test vector is as below: ALG : PSA_ALG_HKDF_EXPAND(PSA_ALG_SHA_256), "info" : decode_hex("f0f1f2f3f4f5f6f7f8f9"), "L" : 42, "PRK" : "077709362c2e32df0ddc3f0dc47bba6390b6c73bb50f9c3122ec844ad7c2b3e5" "OKM" : "3cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865" The corresponding code is as follow： int8_t okm[42]={0}; uint8_t info[] = {0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xf9}; uint8_t ikm[]= { 0x7,0x77,0x9,0x36,0x2c,0x2e,0x32,0xdf, 0xd,0xdc,0x3f,0xd,0xc4,0x7b,0xba,0x63, 0x90,0xb6,0xc7,0x3b,0xb5,0xf,0x9c,0x31, 0x22,0xec,0x84,0x4a,0xd7,0xc2,0xb3,0xe5 }; status = psa_key_derivation_setup(&operation, PSA_ALG_HKDF_EXPAND(PSA_ALG_SHA_256)); status = psa_key_derivation_input_bytes(&operation, PSA_KEY_DERIVATION_INPUT_SECRET, ikm, sizeof(ikm)); status = psa_key_derivation_input_bytes(&operation, PSA_KEY_DERIVATION_INPUT_INFO, info, sizeof(info)); status = psa_key_derivation_output_bytes( &operation, okm, sizeof(okm) ); The actual output okm is : 5a 1c ea 2d 24 ee 79 c5 bf ce 27 7b ... be b 3b 2e 19 18 77 ae, which didn't match the OKM of above test vector. Have we misused the HKDF-EXPAND operation? Best Regards, Poppy Wu 吴偏偏 http://www.mxic.com.cn

2 months, 1 week

2
2
0 0

Please help check the failure of PSA_ALG_HKDF_EXPAND operation test

by Wenhua You

Hi experts, Recently we're testing the HKDF-EXPAND interface with TF-M v1.7.0 on stm32l562e_dk platform. But the HKDF-EXPAND output didn't match the expected OKM. The test vector is as below: ALG : PSA_ALG_HKDF_EXPAND(PSA_ALG_SHA_256), "info" : decode_hex("f0f1f2f3f4f5f6f7f8f9"), "L" : 42, "PRK" : "077709362c2e32df0ddc3f0dc47bba6390b6c73bb50f9c3122ec844ad7c2b3e5" "OKM" : "3cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865" The corresponding code is as follow： int8_t okm[42]={0}; uint8_t info[] = {0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xf9}; uint8_t ikm[]= { 0x7,0x77,0x9,0x36,0x2c,0x2e,0x32,0xdf, 0xd,0xdc,0x3f,0xd,0xc4,0x7b,0xba,0x63, 0x90,0xb6,0xc7,0x3b,0xb5,0xf,0x9c,0x31, 0x22,0xec,0x84,0x4a,0xd7,0xc2,0xb3,0xe5 }; status = psa_key_derivation_setup(&operation, PSA_ALG_HKDF_EXPAND(PSA_ALG_SHA_256)); status = psa_key_derivation_input_bytes(&operation, PSA_KEY_DERIVATION_INPUT_SECRET, ikm, sizeof(ikm)); status = psa_key_derivation_input_bytes(&operation, PSA_KEY_DERIVATION_INPUT_INFO, info, sizeof(info)); status = psa_key_derivation_output_bytes( &operation, okm, sizeof(okm) ); The actual output okm is : 5a 1c ea 2d 24 ee 79 c5 bf ce 27 7b ... be b 3b 2e 19 18 77 ae, which didn't match the OKM of above test vector. If we've misused the HKDF-EXPAND operation? Best Regards, 尤文华 Wenhua You 旺宏微电子（苏州）有限公司 Macronix Microelectronics(Suzhou) Co., Ltd. 地址：中国苏州工业园区苏虹西路55号 No.55，Su Hong Xi Road，Suzhou Industrail Park，Suzhou 215021 P.R.China TEL: 86-512-62580888 EXT: 3115 FAX: 86-512-62585399 ZIP: 215021 E-mail: wenhuayou(a)mxic.com.cn Http: //www.mxic.com.cn

2 months, 1 week

1
0
0 0

Sealing key - RSS

by Peter Sawicki

As far as ARM CCA is concerned, currently RSS supports only measured boot and delegated attestation (fetching DAK and CCA platform attestation token) interfaces. The Arm CCA Security Model 1.0 mentions that if a Realm wants to implement a persistent secure storage, the platform should deliver binding keys for local protection of persistent Realm assets. Is there any ARM CCA specification that explains how this key should be derived? Are there any plans to implement such functionality in RSS? Kind regards, Peter

2 months, 2 weeks

3
4
0 0

TF-M scheduling

by Chris.Brand＠infineon.com

Hi, I've read https://tf-m-user-guide.trustedfirmware.org/integration_guide/non-secure_cl… and https://tf-m-user-guide.trustedfirmware.org/design_docs/software/tfm_cooper… but I'm not sure that I understand the whole system. For example, in this scenario: 1. NSPE is running a low-priority thread which has called into the PSA API. S partition is running to do the work. 2. NS interrupt occurs. 3. NS RTOS determines that a higher-priority thread should now run. At step 2, the S context gets stored on the S stack. I guess at step 3 the NS RTOS ISR would manipulate the stack so that it "returns" to the higher-priority NS thread rather than to the secure partition? And then sometime later when it schedules in the low-priority thread, it will return to the interrupted S partition. So the higher-priority thread can also make a PSA API call (provided the NS RTOS is notifying TF-M of the scheduling decisions it makes)? Thanks, Chris Brand Cypress Semiconductor (Canada), Inc. An Infineon Technologies Company Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com> www.infineon.com<www.cypress.com> www.cypress.com<http://www.cypress.com/> Discoveries<http://www.infineon.com/discoveries> Facebook<http://www.facebook.com/infineon> Twitter<http://www.twitter.com/Infineon> LinkedIn<http://www.linkedin.com/company/infineon-technologies> Part of your life. Part of tomorrow. NOTICE: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material of Infineon Technologies AG and its affiliated entities which is for the exclusive use of the individual designated above as the recipient. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact immediately the sender by returning e-mail and delete the material from any computer. If you are not the specified recipient, you are hereby notified that all disclosure, reproduction, distribution or action taken on the basis of this message is prohibited.

2 months, 2 weeks

1
0
0 0

2023

2022

2021

2020

2019

2018

TF-M March 2023