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?
"tf-m@lists.trustedfirmware.org"
<tf-m@lists.trustedfirmware.org>, Edward Yang <EdwardYang@mxic.com.cn>
cc
nd <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@lists.trustedfirmware.org>
on behalf of Raef Coles via TF-M <tf-m@lists.trustedfirmware.org>
Sent: 17 May 2021 16:50
To: tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>;
Edward Yang <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@lists.trustedfirmware.org> on behalf of
Edward Yang via TF-M <tf-m@lists.trustedfirmware.org>
Sent: 14 May 2021 10:04
To: 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£¿
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.