Hi,
Some of you using TF-M v1.0 or earlier may have experienced build failures recently because of the CMSIS_5 repo git-lfs quota. To avoid this issue, it is recommended to either update to the latest TF-M version or to manually download the CMSIS_5 pack without using git-lfs.
TF-M only uses a small part of the CMSIS_5 pack for testing purposes. To avoid cloning the entire CMSIS_5 pack, TF-M has been using a forked copy of the required RTX libraries in the tf-m-tests repo since v1.1 so updating to any TF-M version including and after v1.1 is fine.
Hope that helps,
Anton K.
Hi Poppy,
There is no reference implementation for the case when only attest service can access to IAK, which is stored in on-chip flash. Attest code is part of PRoT code, they have the same privileged level.
Tamas
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M
Sent: 2021. május 18., kedd 6:07
To: David Wang <David.Wang(a)arm.com>; Raef Coles <Raef.Coles(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Factory provisioning with tf-m
Hi Raef and David,
Thanks for the detailed explanation.
As I understand it,in the scenario without CC312 ,these keys(HUK,IAK,RoTPK) can be stored in secure-privileged area(using SAU and MPU) of embedded flash during factory
provisioning,so these keys cannot be accessed by ARoT and non-secure code.
But how to make IAK accessible only to the Initial Attestation Service？Is there any reference implementation?
Best Regards,
Poppy Wu
Macronix Microelectronics (Suzhou) Co.,Ltd
Http: //www.mxic.com.cn
David Wang <David.Wang(a)arm.com<mailto:David.Wang@arm.com>>
2021/05/17 20:54
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>>, Edward Yang <EdwardYang(a)mxic.com.cn<mailto:EdwardYang@mxic.com.cn>>
cc
nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject
Re: [TF-M] Factory provisioning with tf-m
Hi Poppy,
One more thing about IAK, it's defined as one of the immutable PSA parameters in PSA security model document.
And
"To prevent cloning or spoofing, the IAK must be secret and accessible only to the Initial Attestation Service."
In that case, for the product, you may need to consider how to ensure confidentiality/integrity and it's immutable based on the embedded flash solution.
Regards,
David Wang
ARM Electronic Technology (Shanghai) Co., Ltd
Phone: +86-21-6154 9142 (ext. 59142)
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Raef Coles via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Sent: 17 May 2021 16:50
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>>; Edward Yang <EdwardYang(a)mxic.com.cn<mailto:EdwardYang@mxic.com.cn>>
Subject: Re: [TF-M] Factory provisioning with tf-m
Hi Poppy.
The current code we use for provisioning the CC312 OTP on the Musca reference platforms is under platform/ext/accelerator/cc312/cc312_provisioning.c, and the code for using keys from OTP is at platform/ext/target/musca_b1/sse_200/crypto_keys.c
Note that because the Musca S1 has volatile OTP memory (I think it's a design choice that makes sense on a dev-board) a workaround is used, for the reference implementation it's best to look at the Musca B1.
The basic flow is:
* Build TF-M with -DCRYPTO_HW_ACCELERATOR_OTP_STATE=PROVISIONING, which will cause an ifdef in the bootloader to jump to the provisioning code instead of TF-M
* TF-M then generates a 256 bit AES HUK and an ECC_P256 private key using the code in cc312_provisioning.c, and program these key into the OTP memory of the CC312
* Programming these keys into OTP causes the lifecycle state to be changed, so a reboot is needed between programming the keys to allow the new LCS to be used
* The board is now provisioned - building TF-M with
* -DCRYPTO_HW_ACCELERATOR_OTP_STATE=ON will cause TF-M to use the HUK, IAK and ROTPK from OTP, and will derive the SST/PS keys from the HUK on boot
The general idea is that a platform can provide it's own implementation of the platform/ext/common/template/crypto_keys.c file, which could then load the keys from wherever they've been provisioned. I'd say it's reasonable to program keys into any NV storage region that is internal to the chip itself (and hence safe from tampering), which would include embedded flash. You'd then just need to load that data from flash in crypto_keys.c. Note that it would also be necessary to prevent secure partitions / non-secure code from directly accessing the flash where the keys are stored, probably by using an mpc/ppc to make it only accessible by secure-privileged code.
Let me know if you have any other questions about the current CC312 provisioning flow.
Raef
________________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Edward Yang via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Sent: 14 May 2021 10:04
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Factory provisioning with tf-m
Hi,
I would like to know about how to use tf-m with factory provisioning,for example,HUK,IAK,ROTPK these ROT assets should be injected to device via factory provisioning,besides,application specific certificates and private keys can also be injected during this procedure,in tf-m roadmap,there is a provision service,what's the functionality of this service?
In initial attestation service, attest_register_initial_attestation_key() calls tfm_plat_get_symmetric_iak() to get IAK, I found implementation template of tfm_plat_get_symmetric_iak() just copys hardcoded key value(for developer mode).
I think this is not allowed in production mode.Is there any recommended implementation of this API?
What if I stored IAK in a specific address of MCU embedded flash during factory provisioning, such as #define IAK_REGION IAK_base_addr in flash_layout.h,and then use flash.read get the key value？
tfm_plat_get_symmetric_iak( )
{
TFM_HAL_ITS_FLASH_DRIVER.ReadData(IAK_REGION, buff, size);
}
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.
=====================================================================
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi Poppy,
One more thing about IAK, it's defined as one of the immutable PSA parameters in PSA security model document.
And
"To prevent cloning or spoofing, the IAK must be secret and accessible only to the Initial Attestation Service."
In that case, for the product, you may need to consider how to ensure confidentiality/integrity and it's immutable based on the embedded flash solution.
Regards,
David Wang
ARM Electronic Technology (Shanghai) Co., Ltd
Phone: +86-21-6154 9142 (ext. 59142)
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Raef Coles via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 17 May 2021 16:50
To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>; Edward Yang <EdwardYang(a)mxic.com.cn>
Subject: Re: [TF-M] Factory provisioning with tf-m
Hi Poppy.
The current code we use for provisioning the CC312 OTP on the Musca reference platforms is under platform/ext/accelerator/cc312/cc312_provisioning.c, and the code for using keys from OTP is at platform/ext/target/musca_b1/sse_200/crypto_keys.c
Note that because the Musca S1 has volatile OTP memory (I think it's a design choice that makes sense on a dev-board) a workaround is used, for the reference implementation it's best to look at the Musca B1.
The basic flow is:
* Build TF-M with -DCRYPTO_HW_ACCELERATOR_OTP_STATE=PROVISIONING, which will cause an ifdef in the bootloader to jump to the provisioning code instead of TF-M
* TF-M then generates a 256 bit AES HUK and an ECC_P256 private key using the code in cc312_provisioning.c, and program these key into the OTP memory of the CC312
* Programming these keys into OTP causes the lifecycle state to be changed, so a reboot is needed between programming the keys to allow the new LCS to be used
* The board is now provisioned - building TF-M with
* -DCRYPTO_HW_ACCELERATOR_OTP_STATE=ON will cause TF-M to use the HUK, IAK and ROTPK from OTP, and will derive the SST/PS keys from the HUK on boot
The general idea is that a platform can provide it's own implementation of the platform/ext/common/template/crypto_keys.c file, which could then load the keys from wherever they've been provisioned. I'd say it's reasonable to program keys into any NV storage region that is internal to the chip itself (and hence safe from tampering), which would include embedded flash. You'd then just need to load that data from flash in crypto_keys.c. Note that it would also be necessary to prevent secure partitions / non-secure code from directly accessing the flash where the keys are stored, probably by using an mpc/ppc to make it only accessible by secure-privileged code.
Let me know if you have any other questions about the current CC312 provisioning flow.
Raef
________________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Edward Yang via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 14 May 2021 10:04
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Factory provisioning with tf-m
Hi,
I would like to know about how to use tf-m with factory provisioning,for example,HUK,IAK,ROTPK these ROT assets should be injected to device via factory provisioning,besides,application specific certificates and private keys can also be injected during this procedure,in tf-m roadmap,there is a provision service,what's the functionality of this service?
In initial attestation service, attest_register_initial_attestation_key() calls tfm_plat_get_symmetric_iak() to get IAK, I found implementation template of tfm_plat_get_symmetric_iak() just copys hardcoded key value(for developer mode).
I think this is not allowed in production mode.Is there any recommended implementation of this API?
What if I stored IAK in a specific address of MCU embedded flash during factory provisioning, such as #define IAK_REGION IAK_base_addr in flash_layout.h,and then use flash.read get the key value？
tfm_plat_get_symmetric_iak( )
{
TFM_HAL_ITS_FLASH_DRIVER.ReadData(IAK_REGION, buff, size);
}
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.
=====================================================================
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi Poppy.
The current code we use for provisioning the CC312 OTP on the Musca reference platforms is under platform/ext/accelerator/cc312/cc312_provisioning.c, and the code for using keys from OTP is at platform/ext/target/musca_b1/sse_200/crypto_keys.c
Note that because the Musca S1 has volatile OTP memory (I think it's a design choice that makes sense on a dev-board) a workaround is used, for the reference implementation it's best to look at the Musca B1.
The basic flow is:
* Build TF-M with -DCRYPTO_HW_ACCELERATOR_OTP_STATE=PROVISIONING, which will cause an ifdef in the bootloader to jump to the provisioning code instead of TF-M
* TF-M then generates a 256 bit AES HUK and an ECC_P256 private key using the code in cc312_provisioning.c, and program these key into the OTP memory of the CC312
* Programming these keys into OTP causes the lifecycle state to be changed, so a reboot is needed between programming the keys to allow the new LCS to be used
* The board is now provisioned - building TF-M with
* -DCRYPTO_HW_ACCELERATOR_OTP_STATE=ON will cause TF-M to use the HUK, IAK and ROTPK from OTP, and will derive the SST/PS keys from the HUK on boot
The general idea is that a platform can provide it's own implementation of the platform/ext/common/template/crypto_keys.c file, which could then load the keys from wherever they've been provisioned. I'd say it's reasonable to program keys into any NV storage region that is internal to the chip itself (and hence safe from tampering), which would include embedded flash. You'd then just need to load that data from flash in crypto_keys.c. Note that it would also be necessary to prevent secure partitions / non-secure code from directly accessing the flash where the keys are stored, probably by using an mpc/ppc to make it only accessible by secure-privileged code.
Let me know if you have any other questions about the current CC312 provisioning flow.
Raef
________________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Edward Yang via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 14 May 2021 10:04
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Factory provisioning with tf-m
Hi,
I would like to know about how to use tf-m with factory provisioning,for example,HUK,IAK,ROTPK these ROT assets should be injected to device via factory provisioning,besides,application specific certificates and private keys can also be injected during this procedure,in tf-m roadmap,there is a provision service,what's the functionality of this service?
In initial attestation service, attest_register_initial_attestation_key() calls tfm_plat_get_symmetric_iak() to get IAK, I found implementation template of tfm_plat_get_symmetric_iak() just copys hardcoded key value(for developer mode).
I think this is not allowed in production mode.Is there any recommended implementation of this API?
What if I stored IAK in a specific address of MCU embedded flash during factory provisioning, such as #define IAK_REGION IAK_base_addr in flash_layout.h,and then use flash.read get the key value？
tfm_plat_get_symmetric_iak( )
{
TFM_HAL_ITS_FLASH_DRIVER.ReadData(IAK_REGION, buff, size);
}
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 Shebu,
Thanks for your reply.I would like to know is there any reference usage
example of tf-m available now?
Best Regards,
Poppy Wu
Macronix Microelectronics (Suzhou) Co.,Ltd
Http: //www.mxic.com.cn
----- Forwarded by Edward Yang/CHINA/MXIC on 2021/05/17 11:56 -----
Shebu Varghese Kuriakose <Shebu.VargheseKuriakose(a)arm.com>
2021/05/15 01:19
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] Factory provisioning with tf-m
Hi Poppy,
In the roadmap, provisioning service is noted incase there is any standard
provisioning mechanism that PSA defines in future. There is no plans
around provisioning at this point.
It is upto the platform to generate the keys and provision it securely on
the device which TF-M can make use of. On Arm reference platforms, MuscaB1
and MuscaS1, the HUK, IAK are generated in Cryptocell-312.
HUK, IAK private keys and ROTPK are provisioned in the OTP of CC-312.
The hardcoding of keys in TF-M is just for development purposes and not to
be used in production environment.
Provisioning the attestation key in the secure region of the embedded
flash might be acceptable. Experts in the list can comment.
Regards,
Shebu
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward
Yang via TF-M
Sent: Friday, May 14, 2021 10:04 AM
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Factory provisioning with tf-m
Hi,
I would like to know about how to use tf-m with factory provisioning,for
example,HUK,IAK,ROTPK these ROT assets should be injected to device via
factory provisioning,besides,application specific certificates and private
keys can also be injected during this procedure,in tf-m roadmap,there is a
provision service,what's the functionality of this service?
In initial attestation service, attest_register_initial_attestation_key()
calls tfm_plat_get_symmetric_iak() to get IAK, I found implementation
template of tfm_plat_get_symmetric_iak() just copys hardcoded key
value(for developer mode).
I think this is not allowed in production mode.Is there any recommended
implementation of this API?
What if I stored IAK in a specific address of MCU embedded flash during
factory provisioning, such as #define IAK_REGION IAK_base_addr in
flash_layout.h,and then use flash.read get the key value？
tfm_plat_get_symmetric_iak( )
{
TFM_HAL_ITS_FLASH_DRIVER.ReadData(IAK_REGION, buff, size);
}
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.
=====================================================================
============================================================================
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,
In the roadmap, provisioning service is noted incase there is any standard provisioning mechanism that PSA defines in future. There is no plans around provisioning at this point.
It is upto the platform to generate the keys and provision it securely on the device which TF-M can make use of. On Arm reference platforms, MuscaB1 and MuscaS1, the HUK, IAK are generated in Cryptocell-312.
HUK, IAK private keys and ROTPK are provisioned in the OTP of CC-312.
The hardcoding of keys in TF-M is just for development purposes and not to be used in production environment.
Provisioning the attestation key in the secure region of the embedded flash might be acceptable. Experts in the list can comment.
Regards,
Shebu
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M
Sent: Friday, May 14, 2021 10:04 AM
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Factory provisioning with tf-m
Hi,
I would like to know about how to use tf-m with factory provisioning,for example,HUK,IAK,ROTPK these ROT assets should be injected to device via factory provisioning,besides,application specific certificates and private keys can also be injected during this procedure,in tf-m roadmap,there is a provision service,what's the functionality of this service?
In initial attestation service, attest_register_initial_attestation_key() calls tfm_plat_get_symmetric_iak() to get IAK, I found implementation template of tfm_plat_get_symmetric_iak() just copys hardcoded key value(for developer mode).
I think this is not allowed in production mode.Is there any recommended implementation of this API?
What if I stored IAK in a specific address of MCU embedded flash during factory provisioning, such as #define IAK_REGION IAK_base_addr in flash_layout.h,and then use flash.read get the key value？
tfm_plat_get_symmetric_iak( )
{
TFM_HAL_ITS_FLASH_DRIVER.ReadData(IAK_REGION, buff, size);
}
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 @Mark Horvath<mailto:Mark.Horvath@arm.com>,
Could you please help take a look at the following questions about Musca-B1 SE?
Thanks 😊
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Suresh Marisetty via TF-M
Sent: Thursday, May 13, 2021 6:04 AM
To: Tamas Ban <Tamas.Ban(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Questions on Musca-B1 SE implementation
Hi Tamas,
The following is good information. A few questions:
1. Is it correct to state that for the SE, the PSA RoT services do not have any software Crypto implementation, but leverage from CC-312?
2. What is the size of the TFM on the host (M33) with only PSA RoT service proxy with redirection to SE
3. Just trying to understand the TFM image size requirements on M33 vs. SE
4. How much of the Flash region/code Executed In Place vs. execution out of SRAM (XIP)
thanks
Suresh Marisetty
Infineon Semiconductor Corporation
From: Tamas Ban <Tamas.Ban(a)arm.com<mailto:Tamas.Ban@arm.com>>
Sent: Friday, April 30, 2021 12:40 AM
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: Questions on Musca-B1 SE implementation
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,
Here is a link how to build images to Musca-B1 SE:
https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…
I have built with GCC and MinSizeRel build type:
Profile Medium:
Memory region Used Size Region Size %age Used
FLASH: 101464 B 381 KB 26.01%
RAM: 61304 B 64 KB 93.54%
[100%] Built target tfm_s
Profile Large:
Memory region Used Size Region Size %age Used
FLASH: 170448 B 381 KB 43.69%
RAM: 62980 B 64 KB 96.10%
[ 97%] Built target tfm_s
The profiles means different capabilities of TF-M, they were introduced to support constrained devices as well, with limited capability.
There is a detailed description about the profiles here:
https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/techn…
BR,
Tamas
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: 2021. április 29., csütörtök 21:49
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Questions on Musca-B1 SE implementation
I am following up on a question that came up on the TFM Core and MCUBoot image sizes that is built for SE on Musca-B1.
We are trying to figure out the resource requirements for SE, to be able to host the TF-M as suggested in the slides below. Wondering if anyone throw more light on the RAM/FLASH requirements for it.
Also, does the TFM profile small/medium/large map to this at all or is it different from them. Also, what’s are the estimated latencies of boot on SE with all the Flash accesses, etc.
https://www.trustedfirmware.org/docs/Musca-B1-Secure-Enclave-Solution.pdfhttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…
Any info on this would be appreciated.
thanks
Suresh Marisetty
Infineon Semiconductor Corporation
Hi,
I would like to know about how to use tf-m with factory provisioning,for
example,HUK,IAK,ROTPK these ROT assets should be injected to device via
factory provisioning,besides,application specific certificates and private
keys can also be injected during this procedure,in tf-m roadmap,there is a
provision service,what's the functionality of this service?
In initial attestation service, attest_register_initial_attestation_key()
calls tfm_plat_get_symmetric_iak() to get IAK, I found implementation
template of tfm_plat_get_symmetric_iak() just copys hardcoded key
value(for developer mode).
I think this is not allowed in production mode.Is there any recommended
implementation of this API?
What if I stored IAK in a specific address of MCU embedded flash during
factory provisioning, such as #define IAK_REGION IAK_base_addr in
flash_layout.h,and then use flash.read get the key value？
tfm_plat_get_symmetric_iak( )
{
TFM_HAL_ITS_FLASH_DRIVER.ReadData(IAK_REGION, buff, size);
}
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,
The agenda for the forum today:
1. How to use docker to build TFM on Windows and Linux by Hugo L'hostis
2. Linker script/scatter file templating (preliminary and tentative)
3. AOB
Regards,
Anton
From: docker to build TFM on windows and Linux (It should take 10 to 15 minutes).
<Hugo.Lhostis(a)arm.com>
Sent: Wednesday, May 12, 2021 10:36 AM
To: Anton Komlev <Anton.Komlev(a)arm.com>
Cc: nd <nd(a)arm.com>
Subject: RE: Technical Forum call - May 13
Hi Anton,
I would like to speak about using docker to build TFM on windows and Linux (It should take 10 to 15 minutes).
Best regards,
Hugo
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: 06 May 2021 19:20
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 - May 13
Hi,
The next Technical Forum is planned on Thursday, May 13, 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
