Functional Testing
Tested operations between ZetaCA and Utimaco SecurityServer Simulator v6.4.0.0:
-
RSA Key Generation: RSA-2048 (2.7s), RSA-4096 (8.2s) — C_GenerateKeyPair successful.
-
ECDSA Key Generation: P-256, P-384 — C_GenerateKeyPair successful.
-
ML-DSA Key Generation (QuantumProtect): ML-DSA-44/65/87 via VDM CKM_MECH_MLDSA_GENKEY.
-
RSA Signing: CKM_SHA256_RSA_PKCS — signature generated and verified with OpenSSL.
-
ECDSA Signing: CKM_ECDSA — raw r||s signature, converted to DER for verification.
-
ML-DSA Signing: CKM_MECH_MLDSA_SIGN — VDM signature generated and verified.
-
Root CA Creation: RSA-4096 CA created via ZetaCA SysAdmin UI with HSM key storage.
-
Certificate Issuance: TLS server certificate (server-tls template) signed by HSM-backed CA.
-
Certificate Verification: openssl x509 confirms sha256WithRSAEncryption, valid issuer chain.
10. Composite Certificates: Dual sub-CA (ECDSA P-384 + ML-DSA-65), both keys on HSM.
Conclusion of HSM PQC validation. End-to-end testing with the Utimaco u.trust GP HSM Simulator v6.4.0.0 (classical algorithms) and the Utimaco QuantumProtect R3 simulator (post-quantum ML-DSA) was conclusive: HSM connectivity test passed (Figure 5, 5 keys discovered), an RSA-4096 Root CA was successfully created with key material generated and held inside the HSM (Figures 6–7), and a post-quantum ML-DSA-65 issuing CA was operated end-to-end with PKCS#11 R3 VDM mechanisms (Figure 8, 12 certificates issued and 0 revoked from the PQC issuing CA at the time of testing). All signing operations were performed exclusively inside the HSM via C_Sign — CA private keys never crossed the HSM boundary.
Performance Benchmarks
Benchmarks on Utimaco SecurityServer Simulator v6.4.0.0 (CPU-emulated, not hardware):
Key Generation: RSA-2048 ~2.7s, RSA-4096 ~8.2s, ECDSA P-256/P-384 <0.5s, ML-DSA-65 <1.0s .
Signing: RSA-4096 SHA-256 <100ms, ECDSA P-384 <50ms, ML-DSA-65 <50ms .
Note: Hardware HSM performance is typically 10-100x faster for RSA due to dedicated accelerators.
Logs and Validation Steps
PKCS#11 Logs
Enabling PKCS#11 logging to facilitate easier testing and troubleshooting is recommended. This can be done by configuring the Logging Loglevel and LogPath parameters in the configuration file.
-
LogPath should point to a writable directory (not a specific file) where log files can be stored.
-
Logging Loglevel controls the verbosity of the logs:
-
Set it to 1 for basic logging.
-
For detailed testing and debugging, increase the level to 4.
-
The generated log file will be named cs_pkcs11_R3.log and located in the directory specified by LogPath. Reviewing this log file can help identify and resolve issues that arise during testing.
Once testing is complete, it is advisable to reduce the Logging Loglevel to 1 or 2 to limit logging to only critical or important messages, thereby optimizing performance and reducing unnecessary log data.
ZetaCA Logs
ZetaCA logs HSM operations via structured JSON logging:
INFO [zetaca.crypto.hsm] Connecting to HSM: /usr/lib/libcs_pkcs11_R3.so
INFO [zetaca.crypto.hsm] HSM connection established
INFO [zetaca.crypto.hsm] Generating RSA-4096 key pair, label=root-ca
ERROR [zetaca.crypto.hsm] PKCS#11 PinIncorrect: PinIncorrect
Log location: stdout (Docker).
View with:
docker logs zetaca-backend --tail 100