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>
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
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
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
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
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
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
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
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
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.
=====================================================================
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.
=====================================================================
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.
=====================================================================
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.
=====================================================================
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
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.
=====================================================================
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.
=====================================================================
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
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.
=====================================================================
Hi,
The agenda for the forum:
1. Linker script/scatter file templating (Ken Liu)
2. Discussion on Non-Secure Client ID update (David Wang).
3. AOB
Regards,
Anton
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Wednesday, May 19, 2021 6:21 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Technical Forum call - May 27
Hi,
The next Technical Forum is planned on Thursday, May 27 , 07:00-08: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
Hi Suresh,
> I am of the belief that MCUboot will be a very thin shim layer over the FWU API to provide the compatibility interface to legacy software and most of the work that was done earlier in MCUboot is pushed down into the FWU partition.
Are you suggesting that the software stack might look like this:
Update client application
|
| Function call
V
MCUBoot user API
Shim layer
|
| Function call
V
FWU API
|
| TF-M psa_call() etc.
V
FWU Partition
|
| Function call
V
MCUBoot user API
MCUBoot engine
This looks like it has one more layer than it needs, as either:
1. The Update client application could Talk directly to the FWU API, or
2. The first MCUBoot user API could interact with an MCUBoot update partition (RoT Service), without having to tunnel the MCUBoot API over the FWU API. The latter might not be straightforward - I am not sure that anyone has reviewed the two APIs for this purpose.
Are you only considering this software stack for a system where touching the update client application source code is not possible (needed for option #1 above)? - and you also cannot introduce a custom MCUBoot RoT Service partition (option #2 above) so you want to reuse TF-M's existing FWU API and partition?
Regards,
Andrew
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Suresh Marisetty via TF-M
Sent: 25 May 2021 02:37
To: Sherry Zhang <Sherry.Zhang2(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Firmware update API - MCUboot update
Hi Sherry,
Thanks for the info. Wondering if there is some documentation or powerpoint explaining how the MCUBoot is changed to accommodate the FWU API.
Details that would help:
1. How the MCUboot works without the FWU API - natively
2. How the MCUBoot needs to be modified to leverage from FWU API
3. What components are retained in MCUBoot ex: image format, signing, metadata, tools
I am of the belief that MCUboot will be a very thin shim layer over the FWU API to provide the compatibility interface to legacy software and most of the work that was done earlier in MCUboot is pushed down into the FWU partition.
The other way to look at it is: If somebody wants to replace MCUboot with a simple BL to integrate it tightly into TFM, what would that look like?
thanks
Suresh Marisetty
Infineon Semiconductor Corporation
From: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>>
Sent: Thursday, May 13, 2021 7:51 PM
To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: Firmware update API - MCUboot update
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>.
Hi Suresh,
The MCUboot update functionality is about validating the existing images on the device which is different from that of the firmware update service which follows mostly with the PSA Firmware Update API spec<https://developer.arm.com/documentation/ihi0093/latest/>.
We designed a shim layer between the firmware update partition and bootloader. A specific bootloader can be ported into the firmware update partition via that shim layer. Please refer to the firmware update service document<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/techn…>. In the MCUboot based shim layer implementation, it calls some user/public APIs provided by MCUboot to achieve its functionality. For example, the Firmware Update API spec describes that psa_fwu_install() API should validate the image or defer the validation to a system reboot. In the MCUboot shim layer implementation, it calls the boot_write_magic() API to mark the image as a candidate image for MCUboot and defers the image validation to a system reboot. Please refer to this link<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…>.
Can you please provide more specific suggestion or questions?
Regards,
Sherry Zhang
From: Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com> <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>>
Sent: Thursday, May 13, 2021 11:40 PM
To: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: Firmware update API - MCUboot update
Hi Sherry,
Please take a closer look at the MCUboot and TFM might want to have a clear position/distinction between these two and how to transition from MCUboot update to this mechanism or it could be that they complement each other.
thanks
Suresh Marisetty
Infineon Semiconductor Corporation
From: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>>
Sent: Wednesday, May 12, 2021 8:55 PM
To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: Firmware update API - MCUboot update
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>.
Hi Suresh,
The firmware update service APIs are for updating the firmware. The functionalities of these APIs includes loading the image into its target device(flash), verifying the image and installing it and so on.
The user can call the these APIs to achieve update images. For example, in the integration of TF-M and the FreeRTOS OTA<https://github.com/Linaro/amazon-freertos/blob/tfm-fwu/libraries/abstractio…>, the OTA agent calls the firmware update service APIs to achieve an image update remotely.
I guess that the "MCUboot update services" you mentioned refers to the functionality of MCUboot which acts as a bootloader. As a bootloader, it can verify the image which already exists on the device and chose the right image to start up. But it cannot, for example, load the image into device or control the image update process.
The firmware update partition calls some user APIs provided by MCUboot to cooperate with it. You can refer to https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/techn….
Regards,
Sherry Zhang
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Suresh Marisetty via TF-M
Sent: Thursday, May 13, 2021 11:09 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Firmware update API - MCUboot update
Hi,
I would like to see if there is any guidance/documentation on how to coordinate between the firmware update services API with that of MCUboot.
Does the use of this API make the MCUboot update services redundant?
thanks
Suresh Marisetty
Infineon Semiconductor Corporation
Lead Member of Technical Staff
CYSC CSS ICW SW SSE
Mobile: +5103863997
Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>
Hi Suresh,
The firmware update service APIs are for updating the firmware. The functionalities of these APIs includes loading the image into its target device(flash), verifying the image and installing it and so on.
The user can call the these APIs to achieve update images. For example, in the integration of TF-M and the FreeRTOS OTA<https://github.com/Linaro/amazon-freertos/blob/tfm-fwu/libraries/abstractio…>, the OTA agent calls the firmware update service APIs to achieve an image update remotely.
I guess that the "MCUboot update services" you mentioned refers to the functionality of MCUboot which acts as a bootloader. As a bootloader, it can verify the image which already exists on the device and chose the right image to start up. But it cannot, for example, load the image into device or control the image update process.
The firmware update partition calls some user APIs provided by MCUboot to cooperate with it. You can refer to https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/techn….
Regards,
Sherry Zhang
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Suresh Marisetty via TF-M
Sent: Thursday, May 13, 2021 11:09 AM
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Firmware update API - MCUboot update
Hi,
I would like to see if there is any guidance/documentation on how to coordinate between the firmware update services API with that of MCUboot.
Does the use of this API make the MCUboot update services redundant?
thanks
Suresh Marisetty
Infineon Semiconductor Corporation
Lead Member of Technical Staff
CYSC CSS ICW SW SSE
Mobile: +5103863997
Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>
Hi Poppy,
SPRT requires the shared library shall not own static R/W data. ITS filesystem may not satisfy this requirement.
Usually, a SP, for example Protected Storage, can rely on ITS service to access data in non-volatile memory.
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M
Sent: Monday, May 24, 2021 12:54 PM
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] A question on tfm its filesystem
Hi,
I'd like to ask a question to see if the filesystem part of tf-m its partition can be moved to lib/sprt folder,to make this filesystem a shared library for PRoT part of tfm.
Therefore,besides its partition, other extra secure partitions can also make use of this filesystem.
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 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.
=====================================================================
Hi,
There are some out of sync contents in the wiki page (mainly the design chapter), which needs to be cleaned a bit.
https://developer.trustedfirmware.org/w/tf_m/
As the first step, the following article would be removed (Would move to a recyclable place at first):
Cooperative Scheduling Rules - content out of date.
Non-Secure Interrupt Handling - covered in the design document.
Secure Partition Interrupt Handling - covered in the interrupt handling document.
Service IPC compatibility - Attestation - low priority, no need to be a standalone item.
Service IPC compatibility - SST - same as above.
Trusted Firmware-m Isolation Level 2 - covered by document 'FF-M isolation'.
Uniform Secure Service Signature - out of date, as most of related files are changed.
Any comments please feel free to ping me.
Would do this on Thursday (27th May) this week.
Thanks.
/Ken
Hi,
I'd like to ask a question to see if the filesystem part of tf-m its
partition can be moved to lib/sprt folder,to make this filesystem a shared
library for PRoT part of tfm.
Therefore,besides its partition, other extra secure partitions can also
make use of this filesystem.
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 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.
=====================================================================
Hi,
Just a guess, but the "UNINIT" attribute described here [1] might be the one you are looking for.
[1] https://developer.arm.com/documentation/100070/0612/scatter-file-syntax/exe…
/George
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M
Sent: 21 May 2021 03:22
To: Suresh.Marisetty(a)infineon.com; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] A question on Arm linker - GCC NOLOAD equivalent
Hi Suresh,
Could you please forward the question to Arm complier forum (https://community.arm.com/developer/tools-software/tools/f/arm-compilers-fo…
I believe they can provide a more comprehensive answer.
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Suresh Marisetty via TF-M
Sent: Friday, May 21, 2021 12:13 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] A question on Arm linker - GCC NOLOAD equivalent
Wondering if anybody can answer this (may not be the right forum):
>>I need the equivalent of the gcc NOLOAD attribute with armlink linker
thanks
Suresh Marisetty
Infineon Semiconductor Corporation
Lead Member of Technical Staff
CYSC CSS ICW SW SSE
Mobile: +5103863997
Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>
