- TF-M - lists.trustedfirmware.org

Re: [TF-M] TF-M API tfm_initial_attest_get_public_key() has been removed

by David Hu

Hi, This secure test service, as I mentioned in the previous email, is for test purpose only. I’d like to recommend to implement a dedicated secure service to co-work with TF-M Initial Attestation service, to fulfil the specific use cases. This test service can be an example. The factory NS app and the dedicated secure service may work in a special device lifecycle. It may require additional mechanism to protect it from accesses in improper lifecycle. It may not be reasonable to mix an API with special purpose with TF-M Initial Attestation service following PSA Attestation API. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: Friday, June 18, 2021 3:05 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M API tfm_initial_attest_get_public_key() has been removed Hi, The API is not fully disappeared, it still supported by a secure test service which can be optionally enabled at build time: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10226/ https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/10228 I think in this way a factory version of TF-M still can be used to export the public key, create a certificate for it (factory NS app) and pass on securely to the verification party to register the database. Kevin: Would this solution still satisfy your use case in mind? My thoughts regarding having the API part of the TF-M secure runtime (original solution): - I expect its usage is limited. Only at the beginning of device lifetime. * Removal of the API can reduce code size. * I cannot see how the API can be abused. Its usage can be clarified in the documentation. BR, Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of David Hu via TF-M Sent: 2021. június 18., péntek 7:18 To: Kevin Townsend (kevin.townsend(a)linaro.org<mailto:kevin.townsend@linaro.org>) <kevin.townsend(a)linaro.org<mailto:kevin.townsend@linaro.org>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] TF-M API tfm_initial_attest_get_public_key() has been removed Hi Kevin, In a simplified common attestation protocol, the attestation verifier/validation entity (VE) uses the attestation public key to verify the attestation token sent from the device. The attestation VE is unable to verify the token, if it is not provided with the public key in advance. The public key fetched in device runtime is untrustworthy. Please check the details in Initial Attestation section in PSA Platform Security Model spec. On the other hand, usually clients on device don’t need attestation public key during attestation protocol execution. It is unnecessary to let Initial Attestation service to export IAK public key to other clients. Putting a dedicated API in attestation service to export public key can confuse developers. Sorry I’m not familiar with other use cases in which the attestation public key might be required and fetched on device in runtime. Those, if exist, may not be the typical use cases of TF-M Initial Attestation service. I’d suggest to implement dedicated secure services, to fulfill your requirement and use cases, relying on TF-M Initial Attestation. It is more flexible and convenient than mixing the public key fetch with TF-M Initial Attestation service. Best regards, Hu Ziji From: Kevin Townsend <kevin.townsend(a)linaro.org<mailto:kevin.townsend@linaro.org>> Sent: Thursday, June 17, 2021 11:23 PM To: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] TF-M API tfm_initial_attest_get_public_key() has been removed Hi, On Thu, 17 Jun 2021 at 16:49, David Hu via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi all, Please note that API tfm_initial_attest_get_public_key() has been removed from TF-M Initial Attestation service. tfm_initial_attest_get_public_key() was defined by TF-M to retrieve Initial Attestation Key (IAK) public key in runtime. It is not defined by PSA Attestation API spec. It was designed for test purpose only but was always enabled in Initial Attestation service. TF-M regression tests called tfm_initial_attest_get_public_key() in runtime to retrieve IAK public key to verify the Initial Attestation Token (IAK) generated by Initial Attestation service. However, such a test implementation doesn’t fully align with common attestation protocols, in which the public key is usually distributed to the verifier when the device is deployed or registered. This API can be misleading and it concerned developers that it may be abused in actual production. Can you detail the use case(s) where you feel deriving the public key inside TF-M or the NS firmware can be abused? Personally, I find it quite useful to be able to generate the IAK randomly and retrieve the public key, which can safely be provided to the NS application to be passed on the end users. Providing the IAK public-key during factory provisioning assumes a very specific workflow that I don't think every TF-M product is likely to adopt. There are many other instances where we don't scrupulously follow the PSA APIs, so I'm not sure why this example should be highlighted, and what seems like a useful feature to me removed. If you can help me better understand the security concerns here, though, I can of course be persuaded otherwise! Best regards, Kevin

5 years

1
0
0 0

Re: [TF-M] TF-M API tfm_initial_attest_get_public_key() has been removed

by Tamas Ban

Hi, The API is not fully disappeared, it still supported by a secure test service which can be optionally enabled at build time: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10226/ https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/10228 I think in this way a factory version of TF-M still can be used to export the public key, create a certificate for it (factory NS app) and pass on securely to the verification party to register the database. Kevin: Would this solution still satisfy your use case in mind? My thoughts regarding having the API part of the TF-M secure runtime (original solution): - I expect its usage is limited. Only at the beginning of device lifetime. * Removal of the API can reduce code size. * I cannot see how the API can be abused. Its usage can be clarified in the documentation. BR, Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: 2021. június 18., péntek 7:18 To: Kevin Townsend (kevin.townsend(a)linaro.org) <kevin.townsend(a)linaro.org>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M API tfm_initial_attest_get_public_key() has been removed Hi Kevin, In a simplified common attestation protocol, the attestation verifier/validation entity (VE) uses the attestation public key to verify the attestation token sent from the device. The attestation VE is unable to verify the token, if it is not provided with the public key in advance. The public key fetched in device runtime is untrustworthy. Please check the details in Initial Attestation section in PSA Platform Security Model spec. On the other hand, usually clients on device don’t need attestation public key during attestation protocol execution. It is unnecessary to let Initial Attestation service to export IAK public key to other clients. Putting a dedicated API in attestation service to export public key can confuse developers. Sorry I’m not familiar with other use cases in which the attestation public key might be required and fetched on device in runtime. Those, if exist, may not be the typical use cases of TF-M Initial Attestation service. I’d suggest to implement dedicated secure services, to fulfill your requirement and use cases, relying on TF-M Initial Attestation. It is more flexible and convenient than mixing the public key fetch with TF-M Initial Attestation service. Best regards, Hu Ziji From: Kevin Townsend <kevin.townsend(a)linaro.org<mailto:kevin.townsend@linaro.org>> Sent: Thursday, June 17, 2021 11:23 PM To: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] TF-M API tfm_initial_attest_get_public_key() has been removed Hi, On Thu, 17 Jun 2021 at 16:49, David Hu via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi all, Please note that API tfm_initial_attest_get_public_key() has been removed from TF-M Initial Attestation service. tfm_initial_attest_get_public_key() was defined by TF-M to retrieve Initial Attestation Key (IAK) public key in runtime. It is not defined by PSA Attestation API spec. It was designed for test purpose only but was always enabled in Initial Attestation service. TF-M regression tests called tfm_initial_attest_get_public_key() in runtime to retrieve IAK public key to verify the Initial Attestation Token (IAK) generated by Initial Attestation service. However, such a test implementation doesn’t fully align with common attestation protocols, in which the public key is usually distributed to the verifier when the device is deployed or registered. This API can be misleading and it concerned developers that it may be abused in actual production. Can you detail the use case(s) where you feel deriving the public key inside TF-M or the NS firmware can be abused? Personally, I find it quite useful to be able to generate the IAK randomly and retrieve the public key, which can safely be provided to the NS application to be passed on the end users. Providing the IAK public-key during factory provisioning assumes a very specific workflow that I don't think every TF-M product is likely to adopt. There are many other instances where we don't scrupulously follow the PSA APIs, so I'm not sure why this example should be highlighted, and what seems like a useful feature to me removed. If you can help me better understand the security concerns here, though, I can of course be persuaded otherwise! Best regards, Kevin

5 years

1
0
0 0

Re: [TF-M] TF-M API tfm_initial_attest_get_public_key() has been removed

by Kevin Townsend

Hi, On Thu, 17 Jun 2021 at 16:49, David Hu via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > Hi all, > > > > Please note that API tfm_initial_attest_get_public_key() has been removed > from TF-M Initial Attestation service. > > > > tfm_initial_attest_get_public_key() was defined by TF-M to retrieve > Initial Attestation Key (IAK) public key in runtime. > > It is not defined by PSA Attestation API spec. It was designed for test > purpose only but was always enabled in Initial Attestation service. > > > > TF-M regression tests called tfm_initial_attest_get_public_key() in > runtime to retrieve IAK public key to verify the Initial Attestation Token > (IAK) generated by Initial Attestation service. > > However, such a test implementation doesn’t fully align with common > attestation protocols, in which the public key is usually distributed to > the verifier when the device is deployed or registered. > > This API can be misleading and it concerned developers that it may be > abused in actual production. > > Can you detail the use case(s) where you feel deriving the public key inside TF-M or the NS firmware can be abused? Personally, I find it quite useful to be able to generate the IAK randomly and retrieve the public key, which can safely be provided to the NS application to be passed on the end users. Providing the IAK public-key during factory provisioning assumes a very specific workflow that I don't think every TF-M product is likely to adopt. There are many other instances where we don't scrupulously follow the PSA APIs, so I'm not sure why this example should be highlighted, and what seems like a useful feature to me removed. If you can help me better understand the security concerns here, though, I can of course be persuaded otherwise! Best regards, Kevin

5 years

2
1
0 0

Re: [TF-M] Building for Musca B1 with proxy service

by Chris.Brand＠infineon.com

Thanks for the quick response! That build now works for me. Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Thursday, June 17, 2021 7:55 AM To: Mark Horvath <Mark.Horvath(a)arm.com>; Brand Chris (CSCA CSS ICW SW PSW 1) <Chris.Brand(a)infineon.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Building for Musca B1 with proxy service Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://goto.infineon.com/SocialEngineering>. The fix is merged. Thanks to Chris for reporting this issue. Also thanks to Mark for such a quick fix. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Mark Horvath via TF-M Sent: Thursday, June 17, 2021 2:59 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com> Subject: Re: [TF-M] Building for Musca B1 with proxy service Hi Chris, The build failure is a regression caused by moving the arm platforms under arm directory. Here is the patch to fix it: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10333 No need to pass artifacts from SE build to SSE-200 build, and the warning about the redefinition is not nice, but that does not cause any issue. Best regards, Mark ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Chris.Brand--- via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Wednesday, June 16, 2021 11:34 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] Building for Musca B1 with proxy service Hi, I'm trying to build for the Musca B1 with the proxy service. I understand that I have to two separate builds, one for the secure_enclave and one for the SSE-200. The secure enclave build works fine, but I'm getting errors for the SSE-200 build and my various attempts to get around them have all failed. I'm (also) wondering if there are artifacts form the secure_enclave build that need to feed into the SSE-200 build somehow, and if so how that works. Here's my command line and resulting errors: cmake -S . -B build_musca_sse200_GNUARM_Relwithdebinfo '-GUnix Makefiles' -DTFM_PLATFORM=arm/musca_b1/sse_200 -DTFM_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Relwithdebinfo -DTFM_PSA_API=ON -DFORWARD_PROT_MSG=ON In file included from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/bl0/bl0_main.c:17:0: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/cmsis.h:63:10: fatal error: core_cm33.h: No such file or directory #include <core_cm33.h> /*!< Arm Cortex-M33 processor and core peripherals */ ^~~~~~~~~~~~~ compilation terminated. /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/gcc/startup_cmsdk_musca_bl2.S:20:10: fatal error: tfm_plat_config.h: No such file or directory #include "tfm_plat_config.h" ^~~~~~~~~~~~~~~~~~~ compilation terminated. In file included from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/platform_description.h:23:0, from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/system_core_init.c:23: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/cmsis.h:63:10: fatal error: core_cm33.h: No such file or directory #include <core_cm33.h> /*!< Arm Cortex-M33 processor and core peripherals */ ^~~~~~~~~~~~~ compilation terminated. /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/device_definition.c:29:10: fatal error: tfm_plat_defs.h: No such file or directory #include "tfm_plat_defs.h" ^~~~~~~~~~~~~~~~~ compilation terminated. [...] <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition [...] platform/target/bl0/CMakeFiles/bl0.dir/build.make:86: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/bl0_main.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/bl0_main.o] Error 1 gmake[2]: *** Waiting for unfinished jobs.... platform/target/bl0/CMakeFiles/bl0.dir/build.make:138: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/system_core_init.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/system_core_init.o] Error 1 platform/target/bl0/CMakeFiles/bl0.dir/build.make:125: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/device_definition.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/device_definition.o] Error 1 platform/target/bl0/CMakeFiles/bl0.dir/build.make:81: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/gcc/startup_cmsdk_musca_bl2.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/gcc/startup_cmsdk_musca_bl2.o] Error 1 CMakeFiles/Makefile2:2539: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/all' failed gmake[1]: *** [platform/target/bl0/CMakeFiles/bl0.dir/all] Error 2 gmake[1]: *** Waiting for unfinished jobs.... This is from a clean checkout of 54d47fbd5269 (current HEAD). I see that my tree does contain platform/ext/cmsis/core_cm33.h, platform/include/tfm_plat_config.h and platform/include/tfm_plat_defs.h so I guess it's the include paths that are messed up somehow...? Thanks, Chris Brand Cypress Semiconductor (Canada), Inc. Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>

5 years

1
0
0 0

Re: [TF-M] Building for Musca B1 with proxy service

by David Hu

The fix is merged. Thanks to Chris for reporting this issue. Also thanks to Mark for such a quick fix. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mark Horvath via TF-M Sent: Thursday, June 17, 2021 2:59 PM To: tf-m(a)lists.trustedfirmware.org; Chris.Brand(a)infineon.com Subject: Re: [TF-M] Building for Musca B1 with proxy service Hi Chris, The build failure is a regression caused by moving the arm platforms under arm directory. Here is the patch to fix it: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10333 No need to pass artifacts from SE build to SSE-200 build, and the warning about the redefinition is not nice, but that does not cause any issue. Best regards, Mark ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Chris.Brand--- via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Wednesday, June 16, 2021 11:34 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] Building for Musca B1 with proxy service Hi, I'm trying to build for the Musca B1 with the proxy service. I understand that I have to two separate builds, one for the secure_enclave and one for the SSE-200. The secure enclave build works fine, but I'm getting errors for the SSE-200 build and my various attempts to get around them have all failed. I'm (also) wondering if there are artifacts form the secure_enclave build that need to feed into the SSE-200 build somehow, and if so how that works. Here's my command line and resulting errors: cmake -S . -B build_musca_sse200_GNUARM_Relwithdebinfo '-GUnix Makefiles' -DTFM_PLATFORM=arm/musca_b1/sse_200 -DTFM_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Relwithdebinfo -DTFM_PSA_API=ON -DFORWARD_PROT_MSG=ON In file included from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/bl0/bl0_main.c:17:0: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/cmsis.h:63:10: fatal error: core_cm33.h: No such file or directory #include <core_cm33.h> /*!< Arm Cortex-M33 processor and core peripherals */ ^~~~~~~~~~~~~ compilation terminated. /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/gcc/startup_cmsdk_musca_bl2.S:20:10: fatal error: tfm_plat_config.h: No such file or directory #include "tfm_plat_config.h" ^~~~~~~~~~~~~~~~~~~ compilation terminated. In file included from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/platform_description.h:23:0, from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/system_core_init.c:23: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/cmsis.h:63:10: fatal error: core_cm33.h: No such file or directory #include <core_cm33.h> /*!< Arm Cortex-M33 processor and core peripherals */ ^~~~~~~~~~~~~ compilation terminated. /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/device_definition.c:29:10: fatal error: tfm_plat_defs.h: No such file or directory #include "tfm_plat_defs.h" ^~~~~~~~~~~~~~~~~ compilation terminated. [...] <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition [...] platform/target/bl0/CMakeFiles/bl0.dir/build.make:86: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/bl0_main.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/bl0_main.o] Error 1 gmake[2]: *** Waiting for unfinished jobs.... platform/target/bl0/CMakeFiles/bl0.dir/build.make:138: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/system_core_init.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/system_core_init.o] Error 1 platform/target/bl0/CMakeFiles/bl0.dir/build.make:125: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/device_definition.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/device_definition.o] Error 1 platform/target/bl0/CMakeFiles/bl0.dir/build.make:81: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/gcc/startup_cmsdk_musca_bl2.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/gcc/startup_cmsdk_musca_bl2.o] Error 1 CMakeFiles/Makefile2:2539: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/all' failed gmake[1]: *** [platform/target/bl0/CMakeFiles/bl0.dir/all] Error 2 gmake[1]: *** Waiting for unfinished jobs.... This is from a clean checkout of 54d47fbd5269 (current HEAD). I see that my tree does contain platform/ext/cmsis/core_cm33.h, platform/include/tfm_plat_config.h and platform/include/tfm_plat_defs.h so I guess it's the include paths that are messed up somehow...? Thanks, Chris Brand Cypress Semiconductor (Canada), Inc. Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>

5 years

1
0
0 0

TF-M API tfm_initial_attest_get_public_key() has been removed

by David Hu

Hi all, Please note that API tfm_initial_attest_get_public_key() has been removed from TF-M Initial Attestation service. tfm_initial_attest_get_public_key() was defined by TF-M to retrieve Initial Attestation Key (IAK) public key in runtime. It is not defined by PSA Attestation API spec. It was designed for test purpose only but was always enabled in Initial Attestation service. TF-M regression tests called tfm_initial_attest_get_public_key() in runtime to retrieve IAK public key to verify the Initial Attestation Token (IAK) generated by Initial Attestation service. However, such a test implementation doesn't fully align with common attestation protocols, in which the public key is usually distributed to the verifier when the device is deployed or registered. This API can be misleading and it concerned developers that it may be abused in actual production. Therefore this API is removed now. A hard-coded dummy public key file is exported instead, to provide the pre-defined public key data to TF-M regression tests. This dummy public key is hard-coded here<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…>. The removal of this API doesn't impact TF-M Initial Attestation service functionalities. TF-M Initial Attestation service still works as PSA attestation API spec requests. The changes to TF-M regression tests are either transparent to platform port or tests. However, there are two exceptions: - Currently, some develop boards with OTP enabled are provisioned with random IAK pair. The public key is unknown to the attestation verifier. Therefore a dedicated attestation test partition<https://git.trustedfirmware.org/TF-M/tf-m-tests.git/tree/test/test_services…> is added to workaround this issue. It adds back API tfm_initial_attest_get_public_key() to retrieve IAK public key in runtime. Boards with similar limitations can select flag ATTEST_TEST_GET_PUBLIC_KEY to enable this workaround during TF-M regression tests. This test partition is only available for TF-M regression tests. It is recommended to enable this workaround *only when it is necessary*. - When developers integrate TF-M with 3rd party test tool, developers can pick the dummy public key file and include it into IAK verification tests as public key input. Sorry for any inconvenience or trouble if this removal impacts your ongoing task. Please let me know if you have further questions about the removal of API tfm_initial_attest_get_public_key(). Best regards, Hu Ziji

5 years

1
0
0 0

Re: [TF-M] Building for Musca B1 with proxy service

by Mark Horvath

Hi Chris, The build failure is a regression caused by moving the arm platforms under arm directory. Here is the patch to fix it: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10333 No need to pass artifacts from SE build to SSE-200 build, and the warning about the redefinition is not nice, but that does not cause any issue. Best regards, Mark ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Chris.Brand--- via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Wednesday, June 16, 2021 11:34 PM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Building for Musca B1 with proxy service Hi, I’m trying to build for the Musca B1 with the proxy service. I understand that I have to two separate builds, one for the secure_enclave and one for the SSE-200. The secure enclave build works fine, but I’m getting errors for the SSE-200 build and my various attempts to get around them have all failed. I’m (also) wondering if there are artifacts form the secure_enclave build that need to feed into the SSE-200 build somehow, and if so how that works. Here's my command line and resulting errors: cmake -S . -B build_musca_sse200_GNUARM_Relwithdebinfo '-GUnix Makefiles' -DTFM_PLATFORM=arm/musca_b1/sse_200 -DTFM_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Relwithdebinfo -DTFM_PSA_API=ON -DFORWARD_PROT_MSG=ON In file included from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/bl0/bl0_main.c:17:0: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/cmsis.h:63:10: fatal error: core_cm33.h: No such file or directory #include <core_cm33.h> /*!< Arm Cortex-M33 processor and core peripherals */ ^~~~~~~~~~~~~ compilation terminated. /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/gcc/startup_cmsdk_musca_bl2.S:20:10: fatal error: tfm_plat_config.h: No such file or directory #include "tfm_plat_config.h" ^~~~~~~~~~~~~~~~~~~ compilation terminated. In file included from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/platform_description.h:23:0, from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/system_core_init.c:23: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/cmsis.h:63:10: fatal error: core_cm33.h: No such file or directory #include <core_cm33.h> /*!< Arm Cortex-M33 processor and core peripherals */ ^~~~~~~~~~~~~ compilation terminated. /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/device_definition.c:29:10: fatal error: tfm_plat_defs.h: No such file or directory #include "tfm_plat_defs.h" ^~~~~~~~~~~~~~~~~ compilation terminated. […] <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition […] platform/target/bl0/CMakeFiles/bl0.dir/build.make:86: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/bl0_main.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/bl0_main.o] Error 1 gmake[2]: *** Waiting for unfinished jobs.... platform/target/bl0/CMakeFiles/bl0.dir/build.make:138: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/system_core_init.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/system_core_init.o] Error 1 platform/target/bl0/CMakeFiles/bl0.dir/build.make:125: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/device_definition.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/device_definition.o] Error 1 platform/target/bl0/CMakeFiles/bl0.dir/build.make:81: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/gcc/startup_cmsdk_musca_bl2.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/gcc/startup_cmsdk_musca_bl2.o] Error 1 CMakeFiles/Makefile2:2539: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/all' failed gmake[1]: *** [platform/target/bl0/CMakeFiles/bl0.dir/all] Error 2 gmake[1]: *** Waiting for unfinished jobs.... This is from a clean checkout of 54d47fbd5269 (current HEAD). I see that my tree does contain platform/ext/cmsis/core_cm33.h, platform/include/tfm_plat_config.h and platform/include/tfm_plat_defs.h so I guess it’s the include paths that are messed up somehow…? Thanks, Chris Brand Cypress Semiconductor (Canada), Inc. Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>

5 years

1
0
0 0

Documentation URLs

by Anton Komlev

Hi, You might noticed that recently documentation became available under the static links (no randomized part in URL anymore). Now it possible to bookmark or share the TF-M docs using a human friendly short URLs like: https://tf-m-user-guide.trustedfirmware.org/docs/introduction/readme.html Please try and enjoy, Anton

5 years

1
0
0 0

Building for Musca B1 with proxy service

by Chris.Brand＠infineon.com

Hi, I'm trying to build for the Musca B1 with the proxy service. I understand that I have to two separate builds, one for the secure_enclave and one for the SSE-200. The secure enclave build works fine, but I'm getting errors for the SSE-200 build and my various attempts to get around them have all failed. I'm (also) wondering if there are artifacts form the secure_enclave build that need to feed into the SSE-200 build somehow, and if so how that works. Here's my command line and resulting errors: cmake -S . -B build_musca_sse200_GNUARM_Relwithdebinfo '-GUnix Makefiles' -DTFM_PLATFORM=arm/musca_b1/sse_200 -DTFM_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Relwithdebinfo -DTFM_PSA_API=ON -DFORWARD_PROT_MSG=ON In file included from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/bl0/bl0_main.c:17:0: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/cmsis.h:63:10: fatal error: core_cm33.h: No such file or directory #include <core_cm33.h> /*!< Arm Cortex-M33 processor and core peripherals */ ^~~~~~~~~~~~~ compilation terminated. /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/gcc/startup_cmsdk_musca_bl2.S:20:10: fatal error: tfm_plat_config.h: No such file or directory #include "tfm_plat_config.h" ^~~~~~~~~~~~~~~~~~~ compilation terminated. In file included from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/platform_description.h:23:0, from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/system_core_init.c:23: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/cmsis.h:63:10: fatal error: core_cm33.h: No such file or directory #include <core_cm33.h> /*!< Arm Cortex-M33 processor and core peripherals */ ^~~~~~~~~~~~~ compilation terminated. /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/device_definition.c:29:10: fatal error: tfm_plat_defs.h: No such file or directory #include "tfm_plat_defs.h" ^~~~~~~~~~~~~~~~~ compilation terminated. [...] <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition [...] platform/target/bl0/CMakeFiles/bl0.dir/build.make:86: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/bl0_main.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/bl0_main.o] Error 1 gmake[2]: *** Waiting for unfinished jobs.... platform/target/bl0/CMakeFiles/bl0.dir/build.make:138: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/system_core_init.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/system_core_init.o] Error 1 platform/target/bl0/CMakeFiles/bl0.dir/build.make:125: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/device_definition.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/device_definition.o] Error 1 platform/target/bl0/CMakeFiles/bl0.dir/build.make:81: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/gcc/startup_cmsdk_musca_bl2.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/gcc/startup_cmsdk_musca_bl2.o] Error 1 CMakeFiles/Makefile2:2539: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/all' failed gmake[1]: *** [platform/target/bl0/CMakeFiles/bl0.dir/all] Error 2 gmake[1]: *** Waiting for unfinished jobs.... This is from a clean checkout of 54d47fbd5269 (current HEAD). I see that my tree does contain platform/ext/cmsis/core_cm33.h, platform/include/tfm_plat_config.h and platform/include/tfm_plat_defs.h so I guess it's the include paths that are messed up somehow...? Thanks, Chris Brand Cypress Semiconductor (Canada), Inc. Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>

5 years

1
0
0 0

Technical Forum call - June 24

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, June 24 7:00-8:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

5 years

1
0
0 0

Re: [TF-M] Deprecate 'partitions/audit_logging' and its related tests

by Andrej Butok

Hi Ken > Or any doubts about depreciating it? It is not used because its implementation is not finished, the current implementation is only for PSA L1 and not supported by IPC. This is not enough for certification. The Log service is optimally required by the PSA Certification. If you going to deprecate it, first delete the requirement from the PSA L2&L3 Certification profiles. Thanks, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Wednesday, June 16, 2021 10:46 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Deprecate 'partitions/audit_logging' and its related tests Hi, The component name under this folder is 'Audit logging', and: * There is no explicit specification or requirements for it, and its functionality is as a simple log collector (and looks no one is using it). * It supported under the library model only. And it is meaningless to move to IPC because of this. * It costs extra maintenance effort in test cases and partition code. So a plan is to deprecate this folder and its related test cases; will create a new one when the specification or requirements are explicitly defined. Question here is: Anyone is using this service? Or any doubts about depreciating it? Will collect the response and broadcast it at 25th Jun. Thanks. /Ken

5 years

1
0
0 0

Deprecate 'partitions/audit_logging' and its related tests

by Ken Liu

Hi, The component name under this folder is 'Audit logging', and: * There is no explicit specification or requirements for it, and its functionality is as a simple log collector (and looks no one is using it). * It supported under the library model only. And it is meaningless to move to IPC because of this. * It costs extra maintenance effort in test cases and partition code. So a plan is to deprecate this folder and its related test cases; will create a new one when the specification or requirements are explicitly defined. Question here is: Anyone is using this service? Or any doubts about depreciating it? Will collect the response and broadcast it at 25th Jun. Thanks. /Ken

5 years

1
0
0 0

Updated invitation with note: TF-M Tech forum @ Every 4 weeks from 12am to 1am on Thursday (MST) (tf-m@lists.trustedfirmware.org)

by Don Harbin

This event has been changed with this note: "Extending end date" Title: TF-M Tech forum About TF-M Tech forum:This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/==…Topic: TF-M Tech forum - Asia Time Zone FriendlyTime: Nov 12, 2020 07:00 AM Greenwich Mean Time        Every 4 weeks on Thu, until Mar 4, 2021, 5 occurrence(s)        Nov 12, 2020 07:00 AM        Dec 10, 2020 07:00 AM        Jan 7, 2021 07:00 AM        Feb 4, 2021 07:00 AM        Mar 4, 2021 07:00 AMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJYodOyvpz8jGNEc_1ykVap8Zg6oTLqZZSeJ/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT09Meeting ID: 925 3579 4925Passcode: 414410One tap mobile+12532158782,,92535794925# US (Tacoma)+13462487799,,92535794925# US (Houston)Dial by your location        +1 253 215 8782 US (Tacoma)        +1 346 248 7799 US (Houston)        +1 669 900 9128 US (San Jose)        +1 301 715 8592 US (Germantown)        +1 312 626 6799 US (Chicago)        +1 646 558 8656 US (New York)        888 788 0099 US Toll-free        877 853 5247 US Toll-freeMeeting ID: 925 3579 4925Find your local number: https://linaro-org.zoom.us/u/aesS64I7GW When: Every 4 weeks from 12am to 1am on Thursday Mountain Standard Time - Phoenix (changed) Where: https://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT… Calendar: tf-m(a)lists.trustedfirmware.org Who: * Don Harbin - creator * tf-m(a)lists.trustedfirmware.org * anton.komlev(a)arm.com * leonardo.sandoval(a)linaro.org * abdelmalek.omar1(a)gmail.com Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=aDM1OHZtbG0wa2di… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-m(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years

1
0
0 0

Re: [TF-M] Technical Forum call - June 10

by David Wang

Hi Anton, If it's open agenda, I would like to take this opportunity to get some inputs about the use scenarios and solutions for sharing flash controller (or even other HW resources) between S and NS. For example, the security/concurrency concerns/issues etc. Thanks. Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, June 9, 2021 11:03 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Technical Forum call - June 10 Hi, We have an open agenda for the forum tomorrow. Let's use that time to review any ongoing items and discuss open questions. To start: 1. What kind of project measurements would be interesting for collection and ways for benchmarking. * Booting time * PSA service access time * ... anything else ? Regards and please bring your topic, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, June 2, 2021 11:26 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] Technical Forum call - June 10 Hi, The next Technical Forum is planned on Thursday, June 10, 15:00-16:00 UTC (US time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

5 years

2
1
0 0

Re: [TF-M] Technical Forum call - June 10

by Anton Komlev

Hi, We have an open agenda for the forum tomorrow. Let's use that time to review any ongoing items and discuss open questions. To start: 1. What kind of project measurements would be interesting for collection and ways for benchmarking. * Booting time * PSA service access time * ... anything else ? Regards and please bring your topic, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, June 2, 2021 11:26 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - June 10 Hi, The next Technical Forum is planned on Thursday, June 10, 15:00-16:00 UTC (US time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

5 years

1
0
0 0

Arm platforms moved into arm folder

by Summer Qin

Hi, We have moved all arm platforms into arm folder which will make the platform folder more clear. One thing needs to pay attention to is that you need to change the TFM_PLATFORM when building arm platforms. For example: '-DTFM_PLATFORM=mps2/an521' --> '-DTFM_PLATFORM=arm/mps2/an521'. It does not influence partner platforms build commands, only for arm platforms. Best Regards, Summer

5 years

1
0
0 0

Re: [TF-M] Questions about psa crypto persistent key

by Andrej Butok

Hi Poppy Wu > the macro TFM_HUK_KEY_ADDR below may be a pointer to the shared HUK data(stored in secure RAM) from secure boot? Yes, this is a pointer to a HUK, provisioned in a secure memory region. Best regards, Andrej Butok SW Tech Lead Edge Processing NXP Semiconductors From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: Thursday, June 3, 2021 12:13 PM To: tf-m(a)lists.trustedfirmware.org; Sherry Zhang <Sherry.Zhang2(a)arm.com> Subject: Re: [TF-M] Questions about psa crypto persistent key Hi Sherry, Thanks a lot for your reply,it's a big help. So with current tf-m crypto service implementation,if I want to use psa_aead_encrypt() to do encryption with a persistent key which is provisioned before the reset,I need to use psa_open_key() as a temporary method. Besides,the implementation of key derivation from HUK on NXP platform,I suppose in actual development ,the macro TFM_HUK_KEY_ADDR below may be a pointer to the shared HUK data(stored in secure RAM) from secure boot? +#ifndef TFM_HUK_KEY_ADDR +static const uint8_t sample_tfm_key[] = + {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, \ + 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F}; + +#define TFM_HUK_KEY_ADDR sample_tfm_key +#endif status = psa_import_key(&attributes, (const uint8_t *)TFM_HUK_KEY_ADDR, TFM_HUK_KEY_LEN, &base_key); Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mxic.c om.cn%2F&data=04%7C01%7Candrey.butok%40nxp.com%7Ca93215d45b04467d08a008d9267 83c86%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637583120130280321%7CUnkn own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC I6Mn0%3D%7C1000&sdata=rkCPRgsZNK6j3xKoAJkJQDjPW8nA6RDW6JosI0EbSOY%3D&reserve d=0> http://www.mxic.com.cn Sherry Zhang via TF-M <tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> > Sent by: "TF-M" <tf-m-bounces(a)lists.trustedfirmware.org <mailto:tf-m-bounces@lists.trustedfirmware.org> > 2021/06/03 14:23 Please respond to Sherry Zhang <Sherry.Zhang2(a)arm.com <mailto:Sherry.Zhang2@arm.com> > To Edward Yang <EdwardYang(a)mxic.com.cn <mailto:EdwardYang@mxic.com.cn> >, "tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> " <tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> > cc nd <nd(a)arm.com <mailto:nd@arm.com> > Subject Re: [TF-M] Questions about psa crypto persistent key Hi Poppy, The updated PSA crypto spec supports calling psa_aead_encrypt to do encryption with a persistent key which is provisioned before the reset. But currently, the TF-M crypto service has not been updated to the updated PSA crypto spec version in which the psa_open_key is removed. Currently, in TFM, the persistent key should be opened by calling psa_open_key before using this key to do crypto operations which follows the older version of spec. The tfm_crypto_check_handle_owner() API is used for the isolation between the clients. When aligning to the new PSA crypto spec, the isolation implementation should be updated accordingly. Regards, Sherry Zhang From: Edward Yang <EdwardYang(a)mxic.com.cn <mailto:EdwardYang@mxic.com.cn> > Sent: Thursday, June 3, 2021 11:03 AM To: tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> ; Sherry Zhang <Sherry.Zhang2(a)arm.com <mailto:Sherry.Zhang2@arm.com> > Subject: Re: [TF-M] Questions about psa crypto persistent key Hi Sherry, Import persistent key with a specified key_id is indeed supported in the updated crypto spec.. I mean,if a key created by derivation functions,and this key is imported as a persistent key with s specific key id such as KEY_ID_EXAMPLE,then this key is stored in internal Flash with its service. After the reset,this persistent key still exists,but this persisten key cannot be used to do encryption directly,for example,call psa_aead_encrypt(KEY_ID_EXAMPLE,alg,nonce,...),unless import this key with psa_import() once again. Call psa_aead_encrypt(SSKEY_ID,alg,nonce,...) without calling psa_import_key() in advance is not allowed,because in tfm_crypto_check_handle_owner()(why this API is needed?)it will check this key_id with handle_owner[] array. So I am wondering what's the intended use of persistent keys? After creation, this persistent keys can only be used to derive other encryption keys,rather than used to encrypt data with themselves? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mxic.c om.cn%2F&data=04%7C01%7Candrey.butok%40nxp.com%7Ca93215d45b04467d08a008d9267 83c86%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637583120130285299%7CUnkn own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC I6Mn0%3D%7C1000&sdata=zQkONnZCSzkuPTyBfrf9yGAxpYw4iT1J7GImry15nNs%3D&reserve d=0> http://www.mxic.com.cn Sherry Zhang via TF-M < <mailto:tf-m@lists.trustedfirmware.org> tf-m(a)lists.trustedfirmware.org> Sent by: "TF-M" < <mailto:tf-m-bounces@lists.trustedfirmware.org> tf-m-bounces(a)lists.trustedfirmware.org> 2021/06/02 17:37 Please respond to Sherry Zhang < <mailto:Sherry.Zhang2@arm.com> Sherry.Zhang2(a)arm.com> To " <mailto:tf-m@lists.trustedfirmware.org> tf-m(a)lists.trustedfirmware.org" < <mailto:tf-m@lists.trustedfirmware.org> tf-m(a)lists.trustedfirmware.org> cc nd < <mailto:nd@arm.com> nd(a)arm.com> Subject Re: [TF-M] Questions about psa crypto persistent key Hi Poppy, Some feedback from my understanding on the first question. 1. Import persistent key with a key_id is still supported in the updated PSA crypto spec. In the version of PSA crypto spec in which psa_open_key is supported, the persistent key can be opened after the reset with the key_id which is specified in the key attributes in key creation. This is not very friendly. The reason is that each time the user calls the psa_open_key, the crypto service loads the key material from slot to running area(ram or flash) thus a new associated resources is allocated. The application must eventually call psa_close_key to release the allocated associated resources. It can happen that multiple applications call psa_open_key multile times as they may do not know whether the key is opened by other applications. So it can happen that multiple copies of associated resources are allocated for the same key. This is not user friendly. In the updated PSA crypto spec, the key material management strategy is changed. The user does not need to call the psa_open_key to load the key from slot to ram/flash. See the section of "9.4 Key identifies" of the spec: ``` Key identifiers are output from a successful call to one of the key creation functions. For persistent keys, this is the same identifier as the one specified in the key attributes used to create the key. The key indenter remains valid until it is invalidated by passing it to psa_destroy_key(). A volatile key identifier must not be used after it has been invalidated. ``` So I think the user can use the key_id directly to call crypto operations, such as means encrypt, decrypt. Regards, Sherry Zhang From: TF-M < <mailto:tf-m-bounces@lists.trustedfirmware.org> tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: Wednesday, June 2, 2021 1:30 PM To: <mailto:tf-m@lists.trustedfirmware.org> tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Questions about psa crypto persistent key Hi Experts, I have some questions about crypto persisten keys. 1. psa_open_key() is removed in psa crypto spec,so it is impossible to import a persistent key into key slot with key_id,which means encrypt/decrypt data directly with a persistent key is not allowed,these persistent keys can only be used to derive volatile keys which will be used for encryption/decryption, I am not sure if I understand correctly. 2. Besides,HUK can be used to derive the other crypto keys,such as ps crypto key.HUK may be stored in OTP area of MCU(without crypto element such as cc312),then what's intended flow to derive crypto keys from HUK via calling PSA crypto service?There is no reference implementation in tf-m code. tfm_plat_get_huk_derived_key(){ get HUK from OTP || || \/ how to derive crypto key from HUK with calling crypto service? } 3. BTW,HUK has a persistent key id TFM_CRYPTO_KEY_ID_HUK defined in tfm_crypto_defs.h,but I haven't seen any reference to this macro. What's the intended use of this key id?And what's the key owner of HUK? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mxic.c om.cn%2F&data=04%7C01%7Candrey.butok%40nxp.com%7Ca93215d45b04467d08a008d9267 83c86%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637583120130290277%7CUnkn own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC I6Mn0%3D%7C1000&sdata=Qq7wg%2BW9xen65%2BTArZ2w33nPvaB9iHjOOKNcwkyyXu0%3D&res erved=0> http://www.mxic.com.cn CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as it attachments from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================-- TF-M mailing list <mailto:TF-M@lists.trustedfirmware.org> TF-M(a)lists.trustedfirmware.org <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru stedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=04%7C01%7Candrey.butok%40n xp.com%7Ca93215d45b04467d08a008d926783c86%7C686ea1d3bc2b4c6fa92cd99c5c301635 %7C0%7C0%7C637583120130295255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=eGRG%2B6%2FzEx1FqR KyA2jtUfD6sSXEPYeC5Uo%2F8rtDjaQ%3D&reserved=0> https://lists.trustedfirmware.org/mailman/listinfo/tf-m-- TF-M mailing list TF-M(a)lists.trustedfirmware.org <mailto:TF-M@lists.trustedfirmware.org> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru stedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=04%7C01%7Candrey.butok%40n xp.com%7Ca93215d45b04467d08a008d926783c86%7C686ea1d3bc2b4c6fa92cd99c5c301635 %7C0%7C0%7C637583120130300233%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dLJ8SzvGNpE%2FKodd C%2FNFToPCiOiS2w3ir%2FlaiZ4q6ug%3D&reserved=0> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years

1
0
0 0

Re: [TF-M] Questions about psa crypto persistent key

by Edward Yang

Hi Sherry, Thanks a lot for your reply,it's a big help. So with current tf-m crypto service implementation,if I want to use psa_aead_encrypt() to do encryption with a persistent key which is provisioned before the reset,I need to use psa_open_key() as a temporary method. Besides,the implementation of key derivation from HUK on NXP platform,I suppose in actual development ,the macro TFM_HUK_KEY_ADDR below may be a pointer to the shared HUK data(stored in secure RAM) from secure boot? +#ifndef TFM_HUK_KEY_ADDR +static const uint8_t sample_tfm_key[] = + {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, \ + 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F}; + +#define TFM_HUK_KEY_ADDR sample_tfm_key +#endif status = psa_import_key(&attributes, (const uint8_t *)TFM_HUK_KEY_ADDR, TFM_HUK_KEY_LEN, &base_key); Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd http://www.mxic.com.cn Sherry Zhang via TF-M <tf-m(a)lists.trustedfirmware.org> Sent by: "TF-M" <tf-m-bounces(a)lists.trustedfirmware.org> 2021/06/03 14:23 Please respond to Sherry Zhang <Sherry.Zhang2(a)arm.com> To Edward Yang <EdwardYang(a)mxic.com.cn>, "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> cc nd <nd(a)arm.com> Subject Re: [TF-M] Questions about psa crypto persistent key Hi Poppy, The updated PSA crypto spec supports calling psa_aead_encrypt to do encryption with a persistent key which is provisioned before the reset. But currently, the TF-M crypto service has not been updated to the updated PSA crypto spec version in which the psa_open_key is removed. Currently, in TFM, the persistent key should be opened by calling psa_open_key before using this key to do crypto operations which follows the older version of spec. The tfm_crypto_check_handle_owner() API is used for the isolation between the clients. When aligning to the new PSA crypto spec, the isolation implementation should be updated accordingly. Regards, Sherry Zhang From: Edward Yang <EdwardYang(a)mxic.com.cn> Sent: Thursday, June 3, 2021 11:03 AM To: tf-m(a)lists.trustedfirmware.org; Sherry Zhang <Sherry.Zhang2(a)arm.com> Subject: Re: [TF-M] Questions about psa crypto persistent key Hi Sherry, Import persistent key with a specified key_id is indeed supported in the updated crypto spec.. I mean,if a key created by derivation functions,and this key is imported as a persistent key with s specific key id such as KEY_ID_EXAMPLE,then this key is stored in internal Flash with its service. After the reset,this persistent key still exists,but this persisten key cannot be used to do encryption directly,for example,call psa_aead_encrypt(KEY_ID_EXAMPLE,alg,nonce,...),unless import this key with psa_import() once again. Call psa_aead_encrypt(SSKEY_ID,alg,nonce,...) without calling psa_import_key() in advance is not allowed,because in tfm_crypto_check_handle_owner()(why this API is needed?)it will check this key_id with handle_owner[] array. So I am wondering what's the intended use of persistent keys? After creation, this persistent keys can only be used to derive other encryption keys,rather than used to encrypt data with themselves? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd http://www.mxic.com.cn Sherry Zhang via TF-M <tf-m(a)lists.trustedfirmware.org> Sent by: "TF-M" <tf-m-bounces(a)lists.trustedfirmware.org> 2021/06/02 17:37 Please respond to Sherry Zhang <Sherry.Zhang2(a)arm.com> To "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> cc nd <nd(a)arm.com> Subject Re: [TF-M] Questions about psa crypto persistent key Hi Poppy, Some feedback from my understanding on the first question. 1. Import persistent key with a key_id is still supported in the updated PSA crypto spec. In the version of PSA crypto spec in which psa_open_key is supported, the persistent key can be opened after the reset with the key_id which is specified in the key attributes in key creation. This is not very friendly. The reason is that each time the user calls the psa_open_key, the crypto service loads the key material from slot to running area(ram or flash) thus a new associated resources is allocated. The application must eventually call psa_close_key to release the allocated associated resources. It can happen that multiple applications call psa_open_key multile times as they may do not know whether the key is opened by other applications. So it can happen that multiple copies of associated resources are allocated for the same key. This is not user friendly. In the updated PSA crypto spec, the key material management strategy is changed. The user does not need to call the psa_open_key to load the key from slot to ram/flash. See the section of “9.4 Key identifies” of the spec: ``` Key identifiers are output from a successful call to one of the key creation functions. For persistent keys, this is the same identifier as the one specified in the key attributes used to create the key. The key indenter remains valid until it is invalidated by passing it to psa_destroy_key(). A volatile key identifier must not be used after it has been invalidated. ``` So I think the user can use the key_id directly to call crypto operations, such as means encrypt, decrypt. Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: Wednesday, June 2, 2021 1:30 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Questions about psa crypto persistent key Hi Experts, I have some questions about crypto persisten keys. 1. psa_open_key() is removed in psa crypto spec,so it is impossible to import a persistent key into key slot with key_id,which means encrypt/decrypt data directly with a persistent key is not allowed,these persistent keys can only be used to derive volatile keys which will be used for encryption/decryption, I am not sure if I understand correctly. 2. Besides,HUK can be used to derive the other crypto keys,such as ps crypto key.HUK may be stored in OTP area of MCU(without crypto element such as cc312),then what's intended flow to derive crypto keys from HUK via calling PSA crypto service?There is no reference implementation in tf-m code. tfm_plat_get_huk_derived_key(){ get HUK from OTP || || \/ how to derive crypto key from HUK with calling crypto service? } 3. BTW,HUK has a persistent key id TFM_CRYPTO_KEY_ID_HUK defined in tfm_crypto_defs.h,but I haven't seen any reference to this macro. What's the intended use of this key id?And what's the key owner of HUK? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd http://www.mxic.com.cn CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as it attachments from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================-- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m-- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as it attachments from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

5 years

1
0
0 0

Re: [TF-M] Questions about psa crypto persistent key

by Sherry Zhang

Hi Poppy, Question 2 and 3: In the PSA crypto spec, the Key derivation function section describes the steps to perform a key derivation. Also I think you can take the implementation of the key generation based on HUK on NXP platform as a reference at https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…. TFM_CRYPTO_KEY_ID_HUK defined in tfm_crypto_defs.h is a temp work before persistent key APIs support in general. It should be removed now. Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: Wednesday, June 2, 2021 1:30 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Questions about psa crypto persistent key Hi Experts, I have some questions about crypto persisten keys. 1. psa_open_key() is removed in psa crypto spec,so it is impossible to import a persistent key into key slot with key_id,which means encrypt/decrypt data directly with a persistent key is not allowed,these persistent keys can only be used to derive volatile keys which will be used for encryption/decryption, I am not sure if I understand correctly. 2. Besides,HUK can be used to derive the other crypto keys,such as ps crypto key.HUK may be stored in OTP area of MCU(without crypto element such as cc312),then what's intended flow to derive crypto keys from HUK via calling PSA crypto service?There is no reference implementation in tf-m code. tfm_plat_get_huk_derived_key(){ get HUK from OTP || || \/ how to derive crypto key from HUK with calling crypto service? } 3. BTW,HUK has a persistent key id TFM_CRYPTO_KEY_ID_HUK defined in tfm_crypto_defs.h,but I haven't seen any reference to this macro. What's the intended use of this key id?And what's the key owner of HUK? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd http://www.mxic.com.cn<http://www.mxic.com.cn/> CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as it attachments from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

5 years, 1 month

1
0
0 0

Re: [TF-M] Questions about psa crypto persistent key

by Edward Yang

Hi Sherry, Import persistent key with a specified key_id is indeed supported in the updated crypto spec.. I mean,if a key created by derivation functions,and this key is imported as a persistent key with s specific key id such as KEY_ID_EXAMPLE,then this key is stored in internal Flash with its service. After the reset,this persistent key still exists,but this persisten key cannot be used to do encryption directly,for example,call psa_aead_encrypt(KEY_ID_EXAMPLE,alg,nonce,...),unless import this key with psa_import() once again. Call psa_aead_encrypt(SSKEY_ID,alg,nonce,...) without calling psa_import_key() in advance is not allowed,because in tfm_crypto_check_handle_owner()(why this API is needed?)it will check this key_id with handle_owner[] array. So I am wondering what's the intended use of persistent keys? After creation, this persistent keys can only be used to derive other encryption keys,rather than used to encrypt data with themselves? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd http://www.mxic.com.cn Sherry Zhang via TF-M <tf-m(a)lists.trustedfirmware.org> Sent by: "TF-M" <tf-m-bounces(a)lists.trustedfirmware.org> 2021/06/02 17:37 Please respond to Sherry Zhang <Sherry.Zhang2(a)arm.com> To "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> cc nd <nd(a)arm.com> Subject Re: [TF-M] Questions about psa crypto persistent key Hi Poppy, Some feedback from my understanding on the first question. 1. Import persistent key with a key_id is still supported in the updated PSA crypto spec. In the version of PSA crypto spec in which psa_open_key is supported, the persistent key can be opened after the reset with the key_id which is specified in the key attributes in key creation. This is not very friendly. The reason is that each time the user calls the psa_open_key, the crypto service loads the key material from slot to running area(ram or flash) thus a new associated resources is allocated. The application must eventually call psa_close_key to release the allocated associated resources. It can happen that multiple applications call psa_open_key multile times as they may do not know whether the key is opened by other applications. So it can happen that multiple copies of associated resources are allocated for the same key. This is not user friendly. In the updated PSA crypto spec, the key material management strategy is changed. The user does not need to call the psa_open_key to load the key from slot to ram/flash. See the section of “9.4 Key identifies” of the spec: ``` Key identifiers are output from a successful call to one of the key creation functions. For persistent keys, this is the same identifier as the one specified in the key attributes used to create the key. The key indenter remains valid until it is invalidated by passing it to psa_destroy_key(). A volatile key identifier must not be used after it has been invalidated. ``` So I think the user can use the key_id directly to call crypto operations, such as means encrypt, decrypt. Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: Wednesday, June 2, 2021 1:30 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Questions about psa crypto persistent key Hi Experts, I have some questions about crypto persisten keys. 1. psa_open_key() is removed in psa crypto spec,so it is impossible to import a persistent key into key slot with key_id,which means encrypt/decrypt data directly with a persistent key is not allowed,these persistent keys can only be used to derive volatile keys which will be used for encryption/decryption, I am not sure if I understand correctly. 2. Besides,HUK can be used to derive the other crypto keys,such as ps crypto key.HUK may be stored in OTP area of MCU(without crypto element such as cc312),then what's intended flow to derive crypto keys from HUK via calling PSA crypto service?There is no reference implementation in tf-m code. tfm_plat_get_huk_derived_key(){ get HUK from OTP || || \/ how to derive crypto key from HUK with calling crypto service? } 3. BTW,HUK has a persistent key id TFM_CRYPTO_KEY_ID_HUK defined in tfm_crypto_defs.h,but I haven't seen any reference to this macro. What's the intended use of this key id?And what's the key owner of HUK? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd http://www.mxic.com.cn CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as it attachments from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================-- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as it attachments from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

5 years, 1 month

2
1
0 0

Re: [TF-M] Questions about psa crypto persistent key

by Edward Yang

Hi Andrew, “built-in keys with a pre-defined key_id” ,I take this to mean that HUK is a built-in key with the pre-defined key_id TFM_CRYPTO_KEY_ID_HUK,which can be stored in OTP,EEPROM or embedded Flash of MCU. There is no ownership of these built-in keys,however,application persisten keys are created by an application,so application persisten keys are owned by relevant applications. Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd http://www.mxic.com.cn Andrew Thoelke via TF-M <tf-m(a)lists.trustedfirmware.org> Sent by: "TF-M" <tf-m-bounces(a)lists.trustedfirmware.org> 2021/06/02 17:33 Please respond to Andrew Thoelke <Andrew.Thoelke(a)arm.com> To "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org>, nd <nd(a)arm.com> cc Subject Re: [TF-M] Questions about psa crypto persistent key Hi Poppy Wu, In the v1.0.0 PSA Crypto spec, key handles were removed, and keys are now always referred to by a key identifier. After creating a persistent key with a key_id specified by the application (by import, generation or derivation), the key can be used in a cryptographic operation by passing the key_id to the operation function. No key handles are needed anymore. See https://armmbed.github.io/mbed-crypto/html/api/keys/lifetimes.html#persiste… . An implementation can provide some built-in keys with a pre-defined key_id. Depending on the key attributes and policy, these can be used by an application in appropriate cryptographic operations. Built-in keys can behave differently to application persistent keys: They cannot be destroyed by an application They might be accessible to multiple applications They might have different values in different applications The implementation should provide documentation on the expected use of any built-in keys. We’ll need one of the TF-M team to comment on the expected use for TFM_CRYPTO_KEY_ID_HUK. Regards, Andrew Thoelke Andrew Thoelke Software Systems Architect | Arm . . . . . . . . . . . . . . . . . . . . . . . . . . . Arm.com From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: 02 June 2021 06:30 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Questions about psa crypto persistent key Hi Experts, I have some questions about crypto persisten keys. 1. psa_open_key() is removed in psa crypto spec,so it is impossible to import a persistent key into key slot with key_id,which means encrypt/decrypt data directly with a persistent key is not allowed,these persistent keys can only be used to derive volatile keys which will be used for encryption/decryption, I am not sure if I understand correctly. 2. Besides,HUK can be used to derive the other crypto keys,such as ps crypto key.HUK may be stored in OTP area of MCU(without crypto element such as cc312),then what's intended flow to derive crypto keys from HUK via calling PSA crypto service?There is no reference implementation in tf-m code. tfm_plat_get_huk_derived_key(){ get HUK from OTP || || \/ how to derive crypto key from HUK with calling crypto service? } 3. BTW,HUK has a persistent key id TFM_CRYPTO_KEY_ID_HUK defined in tfm_crypto_defs.h,but I haven't seen any reference to this macro. What's the intended use of this key id?And what's the key owner of HUK? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd http://www.mxic.com.cn CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as it attachments from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================-- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

5 years, 1 month

1
0
0 0

Technical Forum call - June 10

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, June 10, 15:00-16:00 UTC (US time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

5 years, 1 month

1
0
0 0

Re: [TF-M] Questions about psa crypto persistent key

by Sherry Zhang

Hi Poppy, Some feedback from my understanding on the first question. 1. Import persistent key with a key_id is still supported in the updated PSA crypto spec. In the version of PSA crypto spec in which psa_open_key is supported, the persistent key can be opened after the reset with the key_id which is specified in the key attributes in key creation. This is not very friendly. The reason is that each time the user calls the psa_open_key, the crypto service loads the key material from slot to running area(ram or flash) thus a new associated resources is allocated. The application must eventually call psa_close_key to release the allocated associated resources. It can happen that multiple applications call psa_open_key multile times as they may do not know whether the key is opened by other applications. So it can happen that multiple copies of associated resources are allocated for the same key. This is not user friendly. In the updated PSA crypto spec, the key material management strategy is changed. The user does not need to call the psa_open_key to load the key from slot to ram/flash. See the section of "9.4 Key identifies" of the spec: ``` Key identifiers are output from a successful call to one of the key creation functions. For persistent keys, this is the same identifier as the one specified in the key attributes used to create the key. The key indenter remains valid until it is invalidated by passing it to psa_destroy_key(). A volatile key identifier must not be used after it has been invalidated. ``` So I think the user can use the key_id directly to call crypto operations, such as means encrypt, decrypt. Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: Wednesday, June 2, 2021 1:30 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Questions about psa crypto persistent key Hi Experts, I have some questions about crypto persisten keys. 1. psa_open_key() is removed in psa crypto spec,so it is impossible to import a persistent key into key slot with key_id,which means encrypt/decrypt data directly with a persistent key is not allowed,these persistent keys can only be used to derive volatile keys which will be used for encryption/decryption, I am not sure if I understand correctly. 2. Besides,HUK can be used to derive the other crypto keys,such as ps crypto key.HUK may be stored in OTP area of MCU(without crypto element such as cc312),then what's intended flow to derive crypto keys from HUK via calling PSA crypto service?There is no reference implementation in tf-m code. tfm_plat_get_huk_derived_key(){ get HUK from OTP || || \/ how to derive crypto key from HUK with calling crypto service? } 3. BTW,HUK has a persistent key id TFM_CRYPTO_KEY_ID_HUK defined in tfm_crypto_defs.h,but I haven't seen any reference to this macro. What's the intended use of this key id?And what's the key owner of HUK? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd http://www.mxic.com.cn<http://www.mxic.com.cn/> CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as it attachments from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

5 years, 1 month

1
0
0 0

Re: [TF-M] Questions about psa crypto persistent key

by Andrew Thoelke

Hi Poppy Wu, In the v1.0.0 PSA Crypto spec, key handles were removed, and keys are now always referred to by a key identifier. After creating a persistent key with a key_id specified by the application (by import, generation or derivation), the key can be used in a cryptographic operation by passing the key_id to the operation function. No key handles are needed anymore. See https://armmbed.github.io/mbed-crypto/html/api/keys/lifetimes.html#persiste…. An implementation can provide some built-in keys with a pre-defined key_id. Depending on the key attributes and policy, these can be used by an application in appropriate cryptographic operations. Built-in keys can behave differently to application persistent keys: * They cannot be destroyed by an application * They might be accessible to multiple applications * They might have different values in different applications The implementation should provide documentation on the expected use of any built-in keys. We'll need one of the TF-M team to comment on the expected use for TFM_CRYPTO_KEY_ID_HUK. Regards, Andrew Thoelke Andrew Thoelke Software Systems Architect | Arm . . . . . . . . . . . . . . . . . . . . . . . . . . . Arm.com From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: 02 June 2021 06:30 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Questions about psa crypto persistent key Hi Experts, I have some questions about crypto persisten keys. 1. psa_open_key() is removed in psa crypto spec,so it is impossible to import a persistent key into key slot with key_id,which means encrypt/decrypt data directly with a persistent key is not allowed,these persistent keys can only be used to derive volatile keys which will be used for encryption/decryption, I am not sure if I understand correctly. 2. Besides,HUK can be used to derive the other crypto keys,such as ps crypto key.HUK may be stored in OTP area of MCU(without crypto element such as cc312),then what's intended flow to derive crypto keys from HUK via calling PSA crypto service?There is no reference implementation in tf-m code. tfm_plat_get_huk_derived_key(){ get HUK from OTP || || \/ how to derive crypto key from HUK with calling crypto service? } 3. BTW,HUK has a persistent key id TFM_CRYPTO_KEY_ID_HUK defined in tfm_crypto_defs.h,but I haven't seen any reference to this macro. What's the intended use of this key id?And what's the key owner of HUK? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd http://www.mxic.com.cn<http://www.mxic.com.cn/> CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as it attachments from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

5 years, 1 month

1
0
0 0

PEM format is enabled in crypto service by default

by Sherry Zhang

Hi, I want to talk about whether TFM should support the PEM key format in crypto operation. In the PSA crypto spec, it describes: ``` This specification supports a single format for each key type. Implementations may support other formats as long as the standard format is supported. ``` The PEM format is not the standard format described in the spec. However, in the tfm_mbedcrypto_config_default.h, the MBEDTLS_PEM_PARSE_C and the MBEDTLS_PEM_WRITE_C is defined which leads to that PEM key format operation is enabled in TFM crypto service. In isolation level1, about more than 2000 bytes code is introduced by this feature: .ER_TFM_CODE 0x2a01c // MBEDTLS_PEM_PARSE_C and the MBEDTLS_PEM_WRITE_C enabled .ER_TFM_CODE 0x29848 // MBEDTLS_PEM_PARSE_C and the MBEDTLS_PEM_WRITE_C disabled Is it necessary to support the PEM format in the key operation in crypto service at the cost of more than 2000 bytes? Any comments on that? Regards, Sherry Zhang

5 years, 1 month

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M