Hi,
Sorry 2nd link was broken. Here is the working version:
https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html#tab…
Tamas Ban
From: Andersson, Joakim <Joakim.Andersson(a)nordicsemi.no>
Sent: 2022. május 9., hétfő 12:14
To: Tamas Ban <Tamas.Ban(a)arm.com>
Subject: RE: Attestation token new spec
Is te second link broken? I get a 404 error code.
-Joakim
From: Tamas Ban via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Sent: mandag 9. mai 2022 11:31
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] Attestation token new spec
Hi,
the initial attestation token implementation is aligned with this specification:
https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-05<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack…>
This spec is still evolving and there is a newer version which changes the key values of the claims in the token:
https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html#tab…<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.…>
This can cause combability issues between token issuer (device) and token verifier (some remote verification service).
This is an ABI change between token issuer and consumer.
The breaking effect would be manifest in unaccepted IAT tokens by the verifier.
On-device side I see these options to make the transition:
- A build-time option could be introduced which determines which range of key numbers to use. The default value would be the new range. To not let new users pick up the old values accidentally. Existing users can notice the incompatibility issue during the integration test and adjust their build command accordingly. However, the old range would be announced as deprecated in the next TF-M release, then will be removed in the next release after.
- Immediate switch over to the new range, without supporting the old range anymore. On the verification service side, an SW update can handle the transition and might be accepting both ranges for a while. I assume the verification service can be updated more easily than remote devices therefore better to handle the compatibility issue there.
- Keeping the support for both ranges for the long term and letting users choose by build time.
Please share your thoughts on:
- Are you aware that the attestation service is used in deployed devices where this transition can cause incompatibility?
- From the above list which option would you vote to support the transition?
Best regards,
Tamas Ban
Hi everyone,
Some time ago patch for split build<https://review.trustedfirmware.org/q/topic:%2522split-build%2522> of SPE, NSPE, BL2 was announced.
I am interested on when this patch is planned to be merged?
Regards,
Bohdan Hunko
Cypress Semiconductor Ukraine
Engineer
CSUKR CSS ICW SW FW
Mobile: +38099 50 19 714
Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>
Hi experts,
Recently we are building uboot with s_veneers.o, and found that we can not jump to tfm. The reason is that the jump addr is wrong when compileing with -pie.
The symbol "tfm_vendor_aes_encrypt_with_hardware_ssk" in s_veneers.o.
$ nm ./drivers/tfm/lib/s_veneers.o | grep tfm_vendor_aes_encrypt_with_hardware_ssk
04008029 A tfm_vendor_aes_encrypt_with_hardware_ssk
Building uboot without cflags -pie, and the last line shows the wrong jump addr 0xf7fc7e61
0c0401f0 <__tfm_vendor_efuse_write_veneer>:
c0401f0: b401 push {r0}
c0401f2: 4802 ldr r0, [pc, #8] ; (c0401fc <__tfm_vendor_efuse_write_veneer+0xc>)
c0401f4: 46fc mov ip, pc
c0401f6: 4484 add ip, r0
c0401f8: bc01 pop {r0}
c0401fa: 4760 bx ip
c0401fc: f7fc7e61 .word 0xf7fc7e61
Building uboot without cflags -pie，and the last line shows the right jump addr 0x04008029.
0c040200 <__tfm_vendor_aes_encrypt_with_hardware_ssk_veneer>:
c040200: b401 push {r0}
c040202: 4802 ldr r0, [pc, #8] ; (c04020c <__tfm_vendor_aes_encrypt_with_hardware_ssk_veneer+0xc>)
c040204: 4684 mov ip, r0
c040206: bc01 pop {r0}
c040208: 4760 bx ip
c04020a: bf00 nop
c04020c: 04008029 .word 0x04008029
The linker flag -pie is default enabled in uboot(for relocation feature), and we need this feature.
Could you please give us some pointers, suggestions or objections about this problem, Thanks!
Hi Antonio,
Thank you for taking the time to help confirm the function, and we've
found out that this error just resulted from
the incorrect initialization of 'operation' before calling PSA APIs, after
fixing this bug, we also got the correct
OKM. Thanks again for your support.
Best Regards,
Poppy Wu
吴偏偏
http://www.mxic.com.cn
Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org>
2023/03/23 21:58
Please respond to
Antonio De Angelis <Antonio.DeAngelis(a)arm.com>
To
"tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org>
cc
nd <nd(a)arm.com>
Subject
[TF-M] Re: Please help check the failure of PSA_ALG_HKDF_EXPAND operation
test
Hi,
I have tried the example below on mbed TLS running on an x86 Linux based
host machine, and on the AN521 platform, and in both cases I can get
consistent results, i.e. the value of the okm buffer at the end is:
0x3c, 0xb2, 0x5f, 0x25, 0xfa, 0xac,
0xd5, 0x7a, 0x90, 0x43, 0x4f, 0x64,
0xd0, 0x36, 0x2f, 0x2a, 0x2d, 0x2d,
0x0a, 0x90, 0xcf, 0x1a, 0x5a, 0x4c,
0x5d, 0xb0, 0x2d, 0x56, 0xec, 0xc4,
0xc5, 0xbf, 0x34, 0x00, 0x72, 0x08,
0xd5, 0xb8, 0x87, 0x18, 0x58, 0x65
Which I believe matches the expected output below. Given that your issue
seems to be specific to the stm32l562e_dk platform, which uses its own
crypto accelerator I believe rather than pure software implementation, I
would suggest to have a look at the intermediate steps and compare your
results against the AN521 platform results. You might want to raise this
behaviour to the platform maintainer, as at this stage this seems to me to
be a platform specific issue.
I can only confirm that you are not misusing the PSA Crypto APIs here.
Let me know if I can be of any more help.
Thanks,
Antonio
From: Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Thursday, March 23, 2023 12:51
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Re: Please help check the failure of PSA_ALG_HKDF_EXPAND
operation test
I am going to have a look into this. Thanks for the instructions on how to
reproduce. Might get a while to reply, please bear with me.
Thanks,
Antonio
From: Edward Yang via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Thursday, March 23, 2023 01:36
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Please help check the failure of PSA_ALG_HKDF_EXPAND
operation test
Hi experts,
Recently we're testing the HKDF-EXPAND interface with TF-M v1.7.0 on
stm32l562e_dk platform.
But the HKDF-EXPAND output didn't match the expected OKM.
The test vector is as below:
ALG : PSA_ALG_HKDF_EXPAND(PSA_ALG_SHA_256),
"info" : decode_hex("f0f1f2f3f4f5f6f7f8f9"),
"L" : 42,
"PRK" :
"077709362c2e32df0ddc3f0dc47bba6390b6c73bb50f9c3122ec844ad7c2b3e5"
"OKM" :
"3cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865"
The corresponding code is as follow：
int8_t okm[42]={0};
uint8_t info[] = {0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xf9};
uint8_t ikm[]= {
0x7,0x77,0x9,0x36,0x2c,0x2e,0x32,0xdf,
0xd,0xdc,0x3f,0xd,0xc4,0x7b,0xba,0x63,
0x90,0xb6,0xc7,0x3b,0xb5,0xf,0x9c,0x31,
0x22,0xec,0x84,0x4a,0xd7,0xc2,0xb3,0xe5
};
status = psa_key_derivation_setup(&operation,
PSA_ALG_HKDF_EXPAND(PSA_ALG_SHA_256));
status = psa_key_derivation_input_bytes(&operation,
PSA_KEY_DERIVATION_INPUT_SECRET,
ikm, sizeof(ikm));
status = psa_key_derivation_input_bytes(&operation,
PSA_KEY_DERIVATION_INPUT_INFO,
info, sizeof(info));
status = psa_key_derivation_output_bytes( &operation, okm, sizeof(okm)
);
The actual output okm is : 5a 1c ea 2d 24 ee 79 c5 bf ce 27 7b ... be b 3b
2e 19 18 77 ae, which didn't match the OKM of above test vector.
Have we misused the HKDF-EXPAND operation?
Best Regards,
Poppy Wu
吴偏偏
http://www.mxic.com.cn --
TF-M mailing list -- tf-m(a)lists.trustedfirmware.org
To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org
Hi tf-m experts,
I have a fundamental query on v8m trustZone and containability of secure fault and other escalated HardFaults to SPE.
With BFHFNMINA set to '0' IIUC that a malicious actor in NSPE can willingly cause fault in SPE ? Is there a way to contain the fault in NS world?
Thanks
Sandeep
Hi experts,
Recently we're testing the HKDF-EXPAND interface with TF-M v1.7.0 on
stm32l562e_dk platform.
But the HKDF-EXPAND output didn't match the expected OKM.
The test vector is as below:
ALG : PSA_ALG_HKDF_EXPAND(PSA_ALG_SHA_256),
"info" : decode_hex("f0f1f2f3f4f5f6f7f8f9"),
"L" : 42,
"PRK" :
"077709362c2e32df0ddc3f0dc47bba6390b6c73bb50f9c3122ec844ad7c2b3e5"
"OKM" :
"3cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865"
The corresponding code is as follow：
int8_t okm[42]={0};
uint8_t info[] = {0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xf9};
uint8_t ikm[]= {
0x7,0x77,0x9,0x36,0x2c,0x2e,0x32,0xdf,
0xd,0xdc,0x3f,0xd,0xc4,0x7b,0xba,0x63,
0x90,0xb6,0xc7,0x3b,0xb5,0xf,0x9c,0x31,
0x22,0xec,0x84,0x4a,0xd7,0xc2,0xb3,0xe5
};
status = psa_key_derivation_setup(&operation,
PSA_ALG_HKDF_EXPAND(PSA_ALG_SHA_256));
status = psa_key_derivation_input_bytes(&operation,
PSA_KEY_DERIVATION_INPUT_SECRET,
ikm, sizeof(ikm));
status = psa_key_derivation_input_bytes(&operation,
PSA_KEY_DERIVATION_INPUT_INFO,
info, sizeof(info));
status = psa_key_derivation_output_bytes( &operation, okm, sizeof(okm)
);
The actual output okm is : 5a 1c ea 2d 24 ee 79 c5 bf ce 27 7b ... be b 3b
2e 19 18 77 ae, which didn't match the OKM of above test vector.
Have we misused the HKDF-EXPAND operation?
Best Regards,
Poppy Wu
吴偏偏
http://www.mxic.com.cn
Hi experts,
Recently we're testing the HKDF-EXPAND interface with TF-M v1.7.0 on
stm32l562e_dk platform.
But the HKDF-EXPAND output didn't match the expected OKM.
The test vector is as below:
ALG : PSA_ALG_HKDF_EXPAND(PSA_ALG_SHA_256),
"info" : decode_hex("f0f1f2f3f4f5f6f7f8f9"),
"L" : 42,
"PRK" :
"077709362c2e32df0ddc3f0dc47bba6390b6c73bb50f9c3122ec844ad7c2b3e5"
"OKM" :
"3cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865"
The corresponding code is as follow：
int8_t okm[42]={0};
uint8_t info[] = {0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xf9};
uint8_t ikm[]= {
0x7,0x77,0x9,0x36,0x2c,0x2e,0x32,0xdf,
0xd,0xdc,0x3f,0xd,0xc4,0x7b,0xba,0x63,
0x90,0xb6,0xc7,0x3b,0xb5,0xf,0x9c,0x31,
0x22,0xec,0x84,0x4a,0xd7,0xc2,0xb3,0xe5
};
status = psa_key_derivation_setup(&operation,
PSA_ALG_HKDF_EXPAND(PSA_ALG_SHA_256));
status = psa_key_derivation_input_bytes(&operation,
PSA_KEY_DERIVATION_INPUT_SECRET,
ikm, sizeof(ikm));
status = psa_key_derivation_input_bytes(&operation,
PSA_KEY_DERIVATION_INPUT_INFO,
info, sizeof(info));
status = psa_key_derivation_output_bytes( &operation, okm, sizeof(okm) );
The actual output okm is : 5a 1c ea 2d 24 ee 79 c5 bf ce 27 7b ... be b 3b
2e 19 18 77 ae, which didn't match the OKM of above test vector.
If we've misused the HKDF-EXPAND operation?
Best Regards,
尤文华 Wenhua You
旺宏微电子（苏州）有限公司
Macronix Microelectronics(Suzhou) Co., Ltd.
地址：中国苏州工业园区苏虹西路55号
No.55，Su Hong Xi Road，Suzhou Industrail Park，Suzhou 215021 P.R.China
TEL: 86-512-62580888 EXT: 3115
FAX: 86-512-62585399 ZIP: 215021
E-mail: wenhuayou(a)mxic.com.cn
Http: //www.mxic.com.cn
As far as ARM CCA is concerned, currently RSS supports only measured boot and delegated attestation (fetching DAK and CCA platform attestation token) interfaces. The Arm CCA Security Model 1.0 mentions that if a Realm wants to implement a persistent secure storage, the platform should deliver binding keys for local protection of persistent Realm assets.
Is there any ARM CCA specification that explains how this key should be derived?
Are there any plans to implement such functionality in RSS?
Kind regards,
Peter
