Closed ldts closed 1 year ago
jenswi-linaro
commented
1 year ago We're using UUIDv5 namespaces to form a hierarchy of UUIDs+keys to allow delegating keys, see also https://optee.readthedocs.io/en/latest/architecture/subkeys.html .
The test verifies two TAs signed using this scheme.
ldts
commented
1 year ago thanks @jenswi-linaro .do the subkey.bin files that you pushed to the repository need to be manually regenerated when the sign key changes in the optee_os repository or the build system takes care of it? I didnt find code that would do this hence why I am asking....not sure if there should a CFG or a flag that I dont know about.
ldts
commented
1 year ago also are the instructions documented in https://github.com/OP-TEE/optee_test/blob/master/ta/subkey_notes.txt correct?
My tests are failing verifying the third signature after replacing the subkey binaries with the new ones for my private key following the subkey_notes.txt
Subkey
struct shdr
magic: 0x4f545348
img_type: 3 (SHDR_SUBKEY)
img_size: 320 bytes
algo: 0x70414930 (TEE_ALG_RSASSA_PKCS1_PSS_MGF1_SHA256)
hash_size: 32 bytes
sig_size: 256 bytes
hash: f573f329fe77be686ce71647909c4ea35b5e1cd7de86369bd7d9fca31f6a4d65
struct shdr_subkey
uuid: f04fa996-148a-453c-b037-1dcfbad120a6
name_size: 64
subkey_version: 1
max_depth: 4
algo: 0x70414930 (TEE_ALG_RSASSA_PKCS1_PSS_MGF1_SHA256)
attr_count: 2
next name: "mid_level_subkey"
Next header at offset: 692 (0x2b4)
Subkey
struct shdr
magic: 0x4f545348
img_type: 3 (SHDR_SUBKEY)
img_size: 320 bytes
algo: 0x70414930 (TEE_ALG_RSASSA_PKCS1_PSS_MGF1_SHA256)
hash_size: 32 bytes
sig_size: 256 bytes
hash: 233a6dcf1a2cf69e50cde8e20c4129157da707c76fa86ce12ee31037edef02d7
struct shdr_subkey
uuid: 1a5948c5-1aa0-518c-86f4-be6f6a057b16
name_size: 64
subkey_version: 1
max_depth: 3
algo: 0x70414930 (TEE_ALG_RSASSA_PKCS1_PSS_MGF1_SHA256)
attr_count: 2
next name: "subkey1_ta"
Next header at offset: 1384 (0x568)
Bootstrap TA
struct shdr
magic: 0x4f545348
img_type: 1 (SHDR_BOOTSTRAP_TA)
img_size: 72048 bytes
algo: 0x70414930 (TEE_ALG_RSASSA_PKCS1_PSS_MGF1_SHA256)
hash_size: 32 bytes
sig_size: 256 bytes
hash: 00436fe9c424c29a3747f597286f6c8828af9ff2a010730bc82bdf01ecc284e2
struct shdr_bootstrap_ta
uuid: 5c206987-16a3-59cc-ab0f-64b9cfc9e758
ta_version: 0
TA offset: 1712 (0x6b0) bytes
TA size: 72048 (0x11970) bytes
this is the trace showing the hash and signature data (previous signatures were valid)
I/TC: se050: message:: data
I/TC: se050: message:: 00.43.6f.e9.c4.24.c2.9a 37.47.f5.97.28.6f.6c.88
I/TC: se050: message:: 28.af.9f.f2.a0.10.73.0b c8.2b.df.01.ec.c2.84.e2
I/TC: se050: signa :: data
I/TC: se050: signa :: 91.a1.f0.ab.64.a4.8a.82 36.51.e4.ec.df.0d.6c.60
I/TC: se050: signa :: 8e.a5.64.c3.ab.1e.e3.4f 47.2a.be.3d.28.e2.1a.69
I/TC: se050: signa :: 97.74.8a.07.59.95.de.b1 34.7b.85.7d.94.b7.89.ca
I/TC: se050: signa :: e8.7f.b5.21.40.8d.37.24 82.57.d1.1a.5b.f9.89.dc
I/TC: se050: signa :: 22.47.7c.f4.f0.5e.5c.07 ec.09.87.d1.db.81.42.67
I/TC: se050: signa :: db.8a.ad.63.5b.16.06.c3 d1.5f.8b.8b.a3.3c.67.af
I/TC: se050: signa :: 15.34.ac.5f.35.56.61.73 84.93.b0.d4.9a.bb.c1.39
I/TC: se050: signa :: 2c.cd.cf.b3.f0.71.d2.17 40.10.79.eb.43.12.a9.27
I/TC: se050: signa :: 4e.04.cf.9a.26.1b.aa.79 cb.78.a8.2e.54.42.90.68
I/TC: se050: signa :: d8.b6.c1.ce.ba.61.3d.e7 12.45.67.df.83.2c.da.61
I/TC: se050: signa :: 03.c1.6b.43.dd.3a.c3.57 94.95.0d.9c.71.80.91.b1
I/TC: se050: signa :: 59.33.86.5c.cc.d8.47.16 74.ad.a2.9b.ac.2d.41.7a
I/TC: se050: signa :: 79.13.da.0f.9f.a1.03.12 e0.69.2e.59.7b.69.45.c6
I/TC: se050: signa :: 9b.61.81.10.24.87.6b.cf b7.2d.ee.63.3e.96.62.63
I/TC: se050: signa :: 36.be.19.06.e7.d8.4f.d9 3d.9c.5c.69.d0.05.d7.3f
I/TC: se050: signa :: e5.f7.e9.e9.2f.fe.4b.da 80.d9.a2.03.43.9e.ee.c2
F/TC:? 0 plat_prng_add_jitter_entropy:72 0xB6
F/TC:? 0 plat_prng_add_jitter_entropy:72 0xB8
F/TC:? 0 plat_prng_add_jitter_entropy:72 0x9C
F/TC:? 0 plat_prng_add_jitter_entropy:72 0x0D
F/TC:? 0 plat_prng_add_jitter_entropy:72 0xF0
F/TC:? 0 plat_prng_add_jitter_entropy:72 0xDF
F/TC:? 0 plat_prng_add_jitter_entropy:72 0xA1
F/TC:? 0 plat_prng_add_jitter_entropy:72 0x53
F/TC:? 0 plat_prng_add_jitter_entropy:72 0xD8
F/TC:? 0 plat_prng_add_jitter_entropy:72 0x8A
F/TC:? 0 plat_prng_add_jitter_entropy:72 0x30
F/TC:? 0 plat_prng_add_jitter_entropy:72 0x04
F/TC:? 0 plat_prng_add_jitter_entropy:72 0xA3
F/TC:? 0 plat_prng_add_jitter_entropy:72 0x8A
F/TC:? 0 plat_prng_add_jitter_entropy:72 0x1A
F/TC:? 0 plat_prng_add_jitter_entropy:72 0xC6
F/TC:? 0 plat_prng_add_jitter_entropy:72 0xDA
F/TC:? 0 plat_prng_add_jitter_entropy:72 0x24
F/TC:? 0 plat_prng_add_jitter_entropy:72 0xBD
F/TC:? 0 plat_prng_add_jitter_entropy:72 0x24
F/TC:? 0 plat_prng_add_jitter_entropy:72 0x0E
E/TC:? 0 verify_ssa:509 invalid signature anyway, this is not an SE050x driver issue - seems like missing functionality for non-default TA sign keys (manual action required)
ldts
commented
1 year ago Falling back to software operations (LTC) for this test generates a similar error on the last verify for the TA
F/TC:? 0 trace_syscall:151 syscall #5 (syscall_open_ta_session)
D/TC:? 0 ldelf_syscall_open_bin:142 Lookup user TA ELF 5c206987-16a3-59cc-ab0f-64b9cfc9e758 (Secure Storage TA)
F/TC:? 0 plat_prng_add_jitter_entropy:72 0xDA
F/TC:? 0 plat_prng_add_jitter_entropy:72 0x3B
F/TC:? 0 plat_prng_add_jitter_entropy:72 0xB2
F/TC:? 0 plat_prng_add_jitter_entropy:72 0x64
D/TC:? 0 ldelf_syscall_open_bin:146 res=0xffff0008
D/TC:? 0 ldelf_syscall_open_bin:142 Lookup user TA ELF 5c206987-16a3-59cc-ab0f-64b9cfc9e758 (REE)
D/TC:? 0 verify_ssa_fallback:888 se050: debug: RSA software fallback: VERIFY
E/TC:? 0 sw_crypto_acipher_rsassa_verify:609 sw_crypto_acipher_rsassa_verify 609
E/TC:? 0 sw_crypto_acipher_rsassa_verify:680 sw_crypto_acipher_rsassa_verify 680 [OK]
F/TC:? 0 plat_prng_add_jitter_entropy:72 0x08
F/TC:? 0 plat_prng_add_jitter_entropy:72 0x8A
F/TC:? 0 plat_prng_add_jitter_entropy:72 0x7C
F/TC:? 0 plat_prng_add_jitter_entropy:72 0x32
D/TC:? 0 verify_ssa_fallback:888 se050: debug: RSA software fallback: VERIFY
E/TC:? 0 sw_crypto_acipher_rsassa_verify:609 sw_crypto_acipher_rsassa_verify 609
E/TC:? 0 sw_crypto_acipher_rsassa_verify:680 sw_crypto_acipher_rsassa_verify 680 [OK]
F/TC:? 0 plat_prng_add_jitter_entropy:72 0x43
F/TC:? 0 plat_prng_add_jitter_entropy:72 0xB3
F/TC:? 0 plat_prng_add_jitter_entropy:72 0xA6
F/TC:? 0 plat_prng_add_jitter_entropy:72 0x94
D/TC:? 0 verify_ssa_fallback:888 se050: debug: RSA software fallback: VERIFY
E/TC:? 0 sw_crypto_acipher_rsassa_verify:609 sw_crypto_acipher_rsassa_verify 609
E/TC:? 0 sw_crypto_acipher_rsassa_verify:677 sw_crypto_acipher_rsassa_verify 677 [FAILED]
D/TC:? 0 ldelf_syscall_open_bin:146 res=0xffff000f
E/LD: init_elf:486 sys_open_ta_bin(5c206987-16a3-59cc-ab0f-64b9cfc9e758) Could it be some error in the software fallback mechanism for se05x?
jenswi-linaro
commented
1 year ago also are the instructions documented in https://github.com/OP-TEE/optee_test/blob/master/ta/subkey_notes.txt correct?
Those are the commands I used to generate the keys.
ldts
commented
1 year ago There must be something wrong in the signing process that I am doing for imx8mm I guess (fall back is calling LTC as it is supposed to and it does properly validate the previous signatures so I think fallback is just doing what it should)
Updating keys/default_ta.pemin OP-TEE and manually regenerating the subkey*.binin OPTEE-TEST as per your notes works fine on qemu_v8 (test 1039 does pass there).
Is the last signature generated differently? The one that fails (last in the chain) corresponds to a SHDR_BOOTSTRAP_TA image type while the other two that pass are SHDR_SUBKEY types)
ldts
commented
1 year ago Is this loop supposed to only verify (shdr->img_type == SHDR_SUBKEY) ? https://github.com/OP-TEE/optee_os/blob/master/core/kernel/ree_fs_ta.c#L282
ie: should https://github.com/OP-TEE/optee_os/blob/master/core/kernel/ree_fs_ta.c#L317 be restricted to subkeys?
The below fixes the issue for me:
shdr = shdr_alloc_and_copy(offs, ta, ta_size);
res = TEE_ERROR_SECURITY;
if (shdr && (shdr->img_type == SHDR_SUBKEY)) {
FTMN_CALL_FUNC(res, &ftmn, FTMN_INCR0,
shdr_verify_signature2, &pub_key, shdr);
incr0_count++;
} else if (shdr) {
FTMN_CALL_FUNC(res, &ftmn, FTMN_INCR0, shdr_verify_signature, shdr);
incr0_count++;
}My debug info now looks like this for regression 1039:
E/TC:? 0 ree_fs_ta_open:270 ree_fs_ta_open 270
E/TC:? 0 ree_fs_ta_open:271 image type: 0x3
E/TC:? 0 sw_crypto_acipher_rsassa_verify:609 sw_crypto_acipher_rsassa_verify 609
E/TC:? 0 sw_crypto_acipher_rsassa_verify:680 sw_crypto_acipher_rsassa_verify 680 [OK]
E/TC:? 0 ree_fs_ta_open:284 ree_fs_ta_open 284 offset 308
E/TC:? 0 ree_fs_ta_open:321 ree_fs_ta_open 321
E/TC:? 0 ree_fs_ta_open:322 image type: 0x3
E/TC:? 0 sw_crypto_acipher_rsassa_verify:609 sw_crypto_acipher_rsassa_verify 609
E/TC:? 0 sw_crypto_acipher_rsassa_verify:680 sw_crypto_acipher_rsassa_verify 680 [OK]
E/TC:? 0 ree_fs_ta_open:343 ree_fs_ta_open 343 :size = 308
E/TC:? 0 ree_fs_ta_open:344 ree_fs_ta_open 344 :offs = 1000
E/TC:? 0 ree_fs_ta_open:327 ree_fs_ta_open 327
E/TC:? 0 ree_fs_ta_open:328 image type: 0x1
E/TC:? 0 sw_crypto_acipher_rsassa_verify:609 sw_crypto_acipher_rsassa_verify 609
E/TC:? 0 sw_crypto_acipher_rsassa_verify:680 sw_crypto_acipher_rsassa_verify 680 [OK]
E/TC:? 0 ree_fs_ta_open:343 ree_fs_ta_open 343 :size = 308
E/TC:? 0 ree_fs_ta_open:344 ree_fs_ta_open 344 :offs = 1692
E/TC:? 0 ree_fs_ta_open:270 ree_fs_ta_open 270
E/TC:? 0 ree_fs_ta_open:271 image type: 0x3
E/TC:? 0 sw_crypto_acipher_rsassa_verify:609 sw_crypto_acipher_rsassa_verify 609
E/TC:? 0 sw_crypto_acipher_rsassa_verify:680 sw_crypto_acipher_rsassa_verify 680 [OK]
E/TC:? 0 ree_fs_ta_open:284 ree_fs_ta_open 284 offset 308
E/TC:? 0 ree_fs_ta_open:327 ree_fs_ta_open 327
E/TC:? 0 ree_fs_ta_open:328 image type: 0x1
E/TC:? 0 sw_crypto_acipher_rsassa_verify:609 sw_crypto_acipher_rsassa_verify 609
E/TC:? 0 sw_crypto_acipher_rsassa_verify:680 sw_crypto_acipher_rsassa_verify 680 [OK]
E/TC:? 0 ree_fs_ta_open:343 ree_fs_ta_open 343 :size = 308
E/TC:? 0 ree_fs_ta_open:344 ree_fs_ta_open 344 :offs = 936 To synthesize now using the secure element instead the software fallback.
patch upstream:
diff --git a/core/drivers/crypto/se050/core/rsa.c b/core/drivers/crypto/se050/core/rsa.c
index 7b46e48c2..0658dec35 100644
--- a/core/drivers/crypto/se050/core/rsa.c
+++ b/core/drivers/crypto/se050/core/rsa.c
@@ -511,6 +511,8 @@ static TEE_Result verify_ssa(uint32_t algo, struct rsa_public_key *key,
sss_se05x_key_store_erase_key(se050_kstore, &kobject);
sss_se05x_asymmetric_context_free(&ctx);
+ EMSG("SE050 Signature verification [%s]", res ? "ERR" : "OK");
+
return res;
}
diff --git a/core/kernel/ree_fs_ta.c b/core/kernel/ree_fs_ta.c
index cdfd95b14..400d18e27 100644
--- a/core/kernel/ree_fs_ta.c
+++ b/core/kernel/ree_fs_ta.c
@@ -315,8 +315,14 @@ static TEE_Result ree_fs_ta_open(const TEE_UUID *uuid,
shdr = shdr_alloc_and_copy(offs, ta, ta_size);
res = TEE_ERROR_SECURITY;
if (shdr) {
- FTMN_CALL_FUNC(res, &ftmn, FTMN_INCR0,
- shdr_verify_signature2, &pub_key, shdr);
+ if (shdr->img_type == SHDR_SUBKEY) {
+ FTMN_CALL_FUNC(res, &ftmn, FTMN_INCR0,
+ shdr_verify_signature2,
+ &pub_key, shdr);
+ } else {
+ FTMN_CALL_FUNC(res, &ftmn, FTMN_INCR0,
+ shdr_verify_signature, shdr);
+ }
incr0_count++;
}
shdr_free_pub_key(&pub_key);Logs:
console:
imx8mm-lpddr4-evk login:
E/TC:? 0 verify_ssa:514 SE050 Signature verification [OK]
E/TC:? 0 verify_ssa:514 SE050 Signature verification [OK]
E/TC:? 0 verify_ssa:514 SE050 Signature verification [OK]
E/TC:? 0 verify_ssa:514 SE050 Signature verification [OK]
E/TC:? 0 verify_ssa:514 SE050 Signature verification [OK] Shell:
root@imx8mm-lpddr4-evk:/var/rootdirs/home/fio# xtest -t regression 1039
Test ID: 1039
Run test suite with level=0
TEE test application started over default TEE instance
######################################################
#
# regression
#
######################################################
* regression_1039 Test subkey verification
o regression_1039.1 Load TA with two levels of subkeys
regression_1039.1 OK
o regression_1039.2 Load TA with identity subkey
regression_1039.2 OK
regression_1039 OK
+-----------------------------------------------------
Result of testsuite regression filtered by "1039":
regression_1039 OK
+-----------------------------------------------------
2 subtests of which 0 failed
1 test case of which 0 failed
100 test cases were skipped
TEE test application done!From what I can see SHDR_BOOTSTRAP_TA is being signed with the embedded ta_pub_key.c
is this what it should be?
jenswi-linaro
commented
1 year ago It looks like you might be signing the TA with the wrong key, that is, the key embedded inside OP-TEE instead of the subkey.
ldts
commented
1 year ago ok, makes sense. thx. now I need to figure out why optee-test is signing it this way.
the loop while (shdr->img_type == SHDR_SUBKEY) confused me a bit: it seems it would only process SHDR_SUBKEY images but that is not the case (it processes SHDR_BOOTSTRAP_TA before exiting)
ldts
commented
1 year ago I'll close the issue now. thanks again.
jenswi-linaro
commented
1 year ago the loop
while (shdr->img_type == SHDR_SUBKEY)confused me a bit: it seems it would only process SHDR_SUBKEY images but that is not the case (it processes SHDR_BOOTSTRAP_TA before exiting)
Yeah, perhaps we're missing a comment.
ldts
commented
1 year ago so what was happening is that since we keep our signing keys outside the optee repos, our yocto build is configured to use the keys from that separate repository (never from source trees as needed now by optee_test)
I am reading https://github.com/OP-TEE/optee_test/blob/master/ta/subkey_notes.txt and I dont quite understand what we are doing here with the UUID.
The SE05x driver is just failing at verifying the TA signature (I am NOT using the OP-TEE default.pem to sign the TAs)
Please could I get some information as to what is being done in this test?