This chapter verifies only the Paraview API Security Gateway and the HSM — that the HSM can perform ML-DSA, that the key resides in the HSM, that the certificate is applied, and that a post-quantum handshake is negotiated. It requires no other business system.
Confirming HSM Algorithm Support (Optional but Recommended)
Independently confirm that the HSM can perform ML-DSA-65 key generation, signing and verification, using the Utimaco Java CXI samples from the evaluation package (pure socket, no vendor .so required):
java -cp "CryptoServerAPI-<version>-linux.jar:<compiled-samples>" \
com.utimaco.FullTestSuite -mldsa -suite -p <cryptographic user>,<user PIN>
Expected (ML-DSA-65 corresponds to keytype 0x33 → MLDSA-...-51-1):
MLDSA-PSEU-EXT-51-1 Keytype is 51 (33)
GEN STAGE: PASSED
SIGN STAGE: PASSED
VERIFY STAGE: PASSED
Tip (known sample issues): On the single-keytype path, announceMLDSA reports "Invalid MLDSA key type" — use -suite to bypass it. The sample's key-file login fails with 0xb906100e because a two-part credential is treated as an HMAC password; the -p <user>,<PIN> form shown above is password login and works unmodified.
Testing HSM Connectivity from a Gateway Node
curl -X POST http://<gateway-node>:9095/v1/admin/hsm/test \
-H "x-admin-key: <STOA_ADMIN_KEY>"
# On success: {"ok":true,"results":[{"token_label":"...","manufacturer":"...","slot_id":0}]}
For every delivered HSM configuration this performs load → initialize → find slot by label → log in → read token information. If the deployed image does not include HSM support, it returns 501 with an explicit message rather than failing silently.
Verifying the Post-Quantum TLS Handshake
# TLS version, post-quantum KEM and post-quantum signature in one line
curl -vk --tlsv1.3 https://<gateway>:8443/ 2>&1 | grep "SSL connection"
# Expect: TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519MLKEM768 / id-ml-dsa-65
# Negotiation details and certificate subject
echo | openssl s_client -connect <gateway>:8443 -tls1_3 2>/dev/null \
| grep -E "Protocol|Peer signature type|Negotiated TLS1.3 group|subject="
# Certificate signature algorithm
echo | openssl s_client -connect <gateway>:8443 2>/dev/null \
| openssl x509 -noout -text | grep -i "Signature Algorithm" # → ML-DSA-65
A self-signed test certificate produces Verify return code: 18 (self-signed), which is
expected. In production use a certificate issued by a trusted CA, or validate the chain with -CAfile .Important: A client with OpenSSL earlier than 3.5 reports an unsupported algorithm or version. That is a client limitation, not a server fault.
Generating a Test ML-DSA-65 Certificate
openssl req -x509 -new -newkey ml-dsa-65 -noenc \
-keyout mldsa.key -out mldsa.crt -days 365 \
-subj "/CN=gw.example.com" -addext "subjectAltName=DNS:gw.example.com"
openssl x509 -in mldsa.crt -noout -text | grep -iE "Signature Algorithm|Public Key Algorithm"
# Signature Algorithm: ML-DSA-65
# Public Key Algorithm: ML-DSA-65
(The OID of ML-DSA-65 is id-ml-dsa-65 = 2.16.840.1.101.3.4.3.18.)
Acceptance Tests
|
No. |
Verification Item |
Method |
Expected Result |
|---|---|---|---|
|
1 |
HSM post-quantum firmware ready |
|
a5 ML, a6 PQMI, a2 HBS all INIT_OK |
|
2 |
PKCS#11 library can reach the HSM |
|
Token CryptoServer PKCS11 Token listed |
|
3 |
HSM algorithm support (optional) |
ML-DSA GEN/SIGN/VERIFY all PASSED |
|
|
4 |
Console connects to the HSM |
ok:true |
|
|
5 |
Gateway node connects to the HSM |
ok:true |
|
|
6 |
Key resides in the HSM (managed path) |
Certificate shows HSM key source with a key reference; the matching label is visible on the HSM |
Private key never leaves the HSM |
|
7 |
Delivery and hot activation |
Start a handshake after creating the certificate |
Takes effect without a restart |
|
8 |
Post-quantum signature algorithm |
Signature Algorithm: ML-DSA-65 |
|
|
9 |
Post-quantum key agreement |
X25519MLKEM768 |
|
|
10 |
Business traffic works |
Send a request through the HTTPS port |
Proxied to the upstream normally |
Acceptance Tests