PQCrypt

M9 / Key management and HSMs

PQC and smart cards

PractitionerAdvisor

After this lesson you can

  • Calculate, with real size figures, the storage and transmission limits ML-DSA/SLH-DSA keys and signatures hit on a smart card or QSCD
  • Acknowledge honestly how limited public, concrete vendor and applet data is in this area today, stating clearly what was searched

Before thisKey ceremonies and KMIP

Mental model

You (this course’s primary learner) already know smart-card-based signing infrastructure (QSCD, Qualified Signature Creation Device) thanks to your eIDAS/CAdES/e-signature background; this lesson does not explain “what a smart card is” but the specific constraints PQC brings to this environment. There are two real constraints: storage (the card’s limited memory) and transmission (the size limits of the APDU protocol between card and reader).

The real effect of the sizes: storage and transmission

Recall the ML-DSA and SLH-DSA sizes from M4: an ML-DSA-65 signature is 3309 BSOURCED, and an SLH-DSA-SHA2-128s signature is 7856 BSOURCED. These are tens or even hundreds of times a classical RSA-2048 (256 BDERIVED) or ECDSA-P256 (64-72 BDERIVED) signature.

This size difference hits the smart card world in two concrete places. The first is storage: the card’s EEPROM must hold the private key and, if needed, the certificate chain, and on classical cards that space may be limited to a few tens of kilobytes. The second, less known but at least as important, is transmission: commands between card and reader (APDUs, Application Protocol Data Units) work in two standard modes under ISO/IEC 7816-4: short APDUs (at most 256 BSOURCED per command/response) and extended APDUs (up to 65535 BSOURCED). The SLH-DSA-SHA2-128s signature is far above the short APDU limit; to carry it, the reader and card must support extended APDUs. This is not a small technical detail to ignore: older readers still common in the field and some operating system drivers may not fully support extended APDUs; when planning a PQC signing pilot, this should be one of the first items the inventory checks.

There is movement on the hardware side, but its rationale should not be overstated

Concrete evidence that these constraints are not abstract: IDEMIA announced a partnership with GlobalFoundries moving its smart card chips to 28nm, GF 28ESF3 platformSOURCED technology, entering mass production in 2026. But it matters not to make this claim more certain than it is: the press material gives no concrete mechanism for why the move suits PQC (for example “X times more RAM”); it only says 28nm technology is “particularly suited to implementing quantum-resistant solutions”, without justification. It is a real sign that the smart card industry takes PQC seriously, but not specific enough to present as “here is the proven technical rationale”; keep that difference (real investment, no stated mechanism) clear for a hostile architect.

An honest gap: applet and pilot data is not public today

While preparing this lesson, we searched for which vendors actually have a working ML-DSA or SLH-DSA signing applet and what state the eIDAS QSCD certification process is in for PQC: the public announcements of major smart card and chip manufacturers such as IDEMIA, Thales, Giesecke+Devrient and Infineon, GlobalPlatform’s applet standardization work, and ETSI/eIDAS trust-list announcements were checked. The result is clear: no public, concrete, verifiable vendor, applet or pilot data was found today. The only thing found is preparation on the hardware side (the 28nm move above); on the software and certification side (which card operating system, which applet, which QSCD certificate) there is no concrete public source.

This is a live application of one of this course’s principles: when you find a gap, say so openly, including what was searched, instead of inventing figures. When explaining this to a bank architect or an auditor, the right sentence is: “The hardware side (chip capacity) is preparing for PQC, and we have concrete evidence; on the software and certification side we checked [sources X, Y, Z] and found no public vendor claim; that is itself a risk signal, and we should monitor this area regularly with dogrula.” Another example of “we don’t know” being more trustworthy than “everything is ready”.

Numbers to know

  • An SLH-DSA-SHA2-128s signature is 7856 B, far above the short APDU limit of 256 B but below the extended APDU limit (65535 B); a smart card reader supporting extended APDUs is a precondition for PQC signing

Lab: Calculate your own card's APDU budget

[not run] This is a calculation exercise; testing with a real card needs the manufacturer's own APDU/applet documentation, which is outside this course's scope

Requires: . Check your setup

shell
# For an ML-DSA-65 signature (3309 B) and an SLH-DSA-SHA2-128s signature (7856 B): into how many pieces must a short APDU (256 B) split it, and does an extended APDU (65535 B) carry it in one go?
Recorded output
ML-DSA-65: ceil(3309/256) = 13 pieces with short APDUs; one piece with an extended APDU. SLH-DSA-128s: ceil(7856/256) = 31 pieces with short APDUs; one piece with an extended APDU.

At the table

How to say this in a bank meeting.

To an executive
Moving our smart-card-based e-signature infrastructure to PQC is not just ordering new cards; we also need to check our existing reader fleet's extended APDU support, otherwise new cards may not work in old readers.
To an architect
The short APDU limit of 256 bytes cannot carry even ML-DSA-65's 3309-byte signature in one go; extended APDUs are required. That means not just card firmware but readers, drivers and middleware must be updated too: an end-to-end inventory question.
Objection
“"Our card manufacturer says 'we are PQC ready'. Is that enough?"”
Answer
No; the CAVP/CMVP distinction you saw in the previous lessons of M9 applies here too, and for smart card applets we could not verify even that distinction publicly (see the honest gap section below). 'We are ready' is not enough; you need concrete answers to which applet, which certification, and which reader compatibility.

Sources

Checkpoint

Answer first, then compare with the model answer and score yourself against the rubric. Saved in this browser only.

  1. 01Recall

    How does the signature size of SLH-DSA-SHA2-128s compare with the short APDU limit of 256 bytes?

  2. 02Recall

    How specific is the rationale the press material gives for the IDEMIA/GlobalFoundries 28nm chip partnership (a concrete mechanism or a general statement)?

  3. 03Scenario

    An eIDAS QSCD vendor says 'our ML-DSA signing card is ready'. Remembering the CAVP/CMVP distinction from the earlier M9 lessons, what concrete evidence do you ask for to verify this claim?

  4. 04Hostile

    An auditor asks about the PQC migration plan for your smart-card-based e-signature infrastructure. How do you explain, without overstating, how limited public, concrete vendor data is today?

Project linkContributes to the smart card and token inventory section of Project 4's (capstone) discovery playbook, as an openly documented record of the information gap in this area.