NXP PKCS#11 Parsec integration testing.

[sahilnxp]

Hi,

I have just integrated the Parsec PKCS#11 Provider with NXP PKCS#11 Library and ran already available tests in the PARSEC only and all of them gets passed.
From below dump it looks like there are only 15 tests done, and there is no cryptography tests like key generation/encryption/decryption tests.
I am curious to know if currently only these tests are supported with PKCS#11 or we can do more testing with some other commands ?

Tested this on LS1046 board.

Thanks in advance.
Sahil

root@localhost:~/parsec# git clone https://github.com/tpm2-software/tpm2-tss.git^C
root@localhost:~/parsec# RUST_LOG=info ./target/debug/parsec -c e2e_tests/provider_cfg/pkcs11/config.toml &
[2] 8400
[INFO  parsec] Parsec started. Configuring the service...
[INFO  parsec_service::utils::service_builder] Creating a PKCS 11 Provider.
[INFO  parsec_service::providers::pkcs11] Building a PKCS 11 provider with library '/usr/lib/libpkcs11.so'
[WARN  parsec_service::utils::service_builder] Direct authenticator has been set as the default one. It is only secure under specific requirements. Please make sure to read the Recommendations on a Secure Parsec Deployment at https://parallaxsecond.github.io/parsec-book/parsec_security/secure_deployment.html
[WARN  parsec_service::front::domain_socket] Removing the existing socket file at /tmp/parsec.sock.
[INFO  parsec] Parsec is ready.
root@localhost:~/parsec#

root@localhost:~/parsec# cargo test --features pkcs11-provider
    Finished test [unoptimized + debuginfo] target(s) in 0.21s
     Running unittests (target/debug/deps/parsec_service-75d8cd3006b96a11)

running 15 tests
test authenticators::unix_peer_credentials_authenticator::test::successful_authentication ... ok
test authenticators::unix_peer_credentials_authenticator::test::unsuccessful_authentication_no_metadata ... ok
test authenticators::unix_peer_credentials_authenticator::test::admin_check ... ok
test authenticators::unix_peer_credentials_authenticator::test::unsuccessful_authentication_wrong_declared_uid ... ok
test authenticators::unix_peer_credentials_authenticator::test::unsuccessful_authentication_wrong_metadata ... ok
test authenticators::unix_peer_credentials_authenticator::test::unsuccessful_authentication_garbage_data ... ok
test key_info_managers::on_disk_manager::test::big_names_emoticons ... ok
test key_info_managers::on_disk_manager::test::big_names_ascii ... ok
test key_info_managers::on_disk_manager::test::exists ... ok
test key_info_managers::on_disk_manager::test::insert_get_key_info ... ok
test key_info_managers::on_disk_manager::test::insert_overwrites ... ok
test providers::core::tests::test_ping ... ok
test key_info_managers::on_disk_manager::test::remove_unexisting_key ... ok
test key_info_managers::on_disk_manager::test::insert_remove_key ... ok
test key_info_managers::on_disk_manager::test::create_and_load ... ok

test result: ok. 15 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests (target/debug/deps/parsec-5665ce8f2f648cee)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests parsec-service

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

root@localhost:~/parsec# 

[hug-dev]

Hey @sahilnxp 👋!

Good question! Actually what you ran are only the Parsec unit tests. There is indeed a large base of tests that we call the end-to-end tests that are available in the e2e_tests folder. Those are crypto and key management tests that are executed against a running Parsec version.

To execute them, have a Parsec service running and then execute:

cargo test --features pkcs11-provider --manifest-path ./e2e_tests/Cargo.toml normal_tests

Let us know if that does not work, or if you need any help! Hopefully they all pass 🙏

You can find more information about testing in the book. We have a list of all of our tests in the subpage.

[hug-dev]

Nice, going in the right direction 👌

I had a look at the failed tests, I think it would be worth to investigate further.

• 5 of them seem to fail on verify_with_ecdsa_sha256. It would be worth to execute only one of them (say simple_verify_hash_ecc) and debug what's wrong. Maybe the ECDSA mechanism is not supported?
• two of them (verify_ecc_with_ring and export_ecc_public_key) fail when exporting the public part of a generated ECC key. Might be worth to debug one of them.
• the format of a public key is wrong in check_public_ecc_export_format2

[hug-dev]

Maybe the ECDSA mechanism is not supported?

That seems to be the case from the list of supported mechanisms here. Only RSA ones seem to be supported 😢
When capability profiling is available, we should maybe use C_GetMechanismList to dynamically check which ones are supported.
Might still be a bug of us not returning PsaErrorNotSupported when those are used?

[ionut-arm]

Yes, that sounds like an excellent idea, and we can/should do the same for TPMs. I guess we've not had a clear "requirement" for such discovery until now.

[hug-dev]

Ok I went for some detective work 🕵️

When verifying, because the PKCS11 library does not support it, we export the public key to the Mbed Crypto provider and do the verification there. This is done through the move_pub_key_to_psa_crypto call.
I counted the Attempting to export public key and the Importing public key into PSA Crypto occurences in your logs and there is 8 more (!!) of the first one which maps to the eight tests failing!!

If that's the case, I think the PsaErrorGenericError returned is from that line, because the EC_POINT attribute returned by the PKCS11 library is not correctly parsed as an ASN.1 OctetString.

It could be interesting to expend that error log message to print the content of that attribute to see what is its form?

[ionut-arm]

Btw, note for future - when looking at failing tests, adding -- --test-threads=1 would be useful, so that each test is run sequentially and you don't have to sift through logs from different threads overlapping.

[hug-dev]

Also, feel free to join our Slack channel if you want and if that helps to debug this!

[hug-dev]

I am wondering if the documentation of the NXP PKCS11 library is up-to-date.

We are using way more PKCS11 calls than what is listed there. Also, all of our sessions are R/W User sessions without it seeming to cause any problems? We are also definitely generating and importing a lot of keys using the PKCS11 library.

[sahilnxp]

Yes, documentation is not updated.
Currently supported mechanisms are:

CKM_MD5
CKM_SHA_1
CKM_SHA256
CKM_SHA384
CKM_SHA512
CKM_RSA_PKCS
CKM_MD5_RSA_PKCS
CKM_SHA1_RSA_PKCS
CKM_SHA256_RSA_PKCS
CKM_SHA384_RSA_PKCS
CKM_SHA512_RSA_PKCS
CKM_ECDSA_SHA1
CKM_ECDSA
CKM_RSA_PKCS_KEY_PAIR_GEN
CKM_EC_KEY_PAIR_GEN
CKM_RSA_PKCS_OAEP

If you want to have a look at PKCS#11 implementation you can have at:
https://source.codeaurora.org/external/qoriq/qoriq-components/libpkcs11/

[hug-dev]

Nice, thanks for the link! We also found more up-to-date documentation here 👌

[hug-dev]

Hi @sahilnxp 👋 !

Just to update you that #466 was merged and provide a better way to handle one of the problems that you saw. You should be able to use Parsec from main and set the allow_export flag to false.
There might be other issues as reported above, maybe related with the format used to represent keys internally. Happy to help if you want to debug it more.

We were also curious and interested about your motivation for this work? We would be definitely excited about greater integration between Parsec and the Layerscape 👌

It might be interesting for you to check out this issue (#439) which is about tighter integration with the libsecure_obj library directly.