A software-based WSCA that matches an HSM-firmware one

The architecture

Where the wallet's keys actually live

In an HSM-based EUDI wallet the user's cryptographic keys are not on the phone. They are held by the wallet provider, inside a Hardware Security Module — an HSM. The wallet app sends an authenticated instruction: generate a key, use a key, delete a key. The provider executes it in the HSM and returns the result.

This is the architecture behind most, if not all, member state wallet implementations, including the Dutch and the German one. It puts a great deal of weight on one component: the WSCA, the Wallet Secure Cryptographic Application. The WSCA is the piece of the provider's infrastructure that authenticates the user and drives the HSM. It is, in effect, the eIDAS High authentication end-point for the wallet.

Our specification builds this on Split-ECDSA (SECDSA), which gives the architecture three properties that are hard to obtain otherwise:

No PIN data reaches the wallet provider. Nothing is stored or processed outside the HSM from which the PIN could be recovered, not even by an attacker with rooted access to the user's device.
Every instruction is publicly verifiable. Each executed instruction yields a transaction record: a compact proof, also sent to the wallet, that the provider followed exactly the instruction the user authorised. Anyone can check it.
Standard HSMs suffice. Ordinary PKCS#11, one HSM call per wallet authentication.

Together these allow the WSCA to run as ordinary software — a container on a hardened application server. No bespoke firmware, and no lock-in to a single HSM vendor.

The objection

Two issues that seemed to need firmware

Running the WSCA in software raises an obvious question: what if an attacker gets inside it? Two consequences looked intrinsic, and looked fully solvable only by moving the WSCA into the HSM itself.

The PIN counter. After a number of incorrect PIN entries the wallet must block. The WSCA keeps that counter. An attacker who controls the WSCA can reset it — and the lockout is the only barrier against simply trying PINs one after another.

Direct key use. The same attacker could skip user authentication altogether and call the HSM with the user's keys directly.

The second can be mitigated, up to a point, with the Authorization Data scheme of EN 419221-5, supported by HSMs such as the Thales Luna 7. The wallet generates a password-like value for every key the HSM creates and must present it on every use; an attacker inside the WSCA does not have it, unless the user happens to use that key while the attacker is watching. Useful, but partial.

Worth noting in passing: this second attack class dominates the debate on WSCA architectures, while the applicable regulation CIR 2024/2981, as I read it, prescribes eIDAS High for user authentication and not for the authorisation of key usage. If you — unlike CIR 2024/2981 — require authorization to be HSM-firmware bound, then authorization towards the HSM for certificate/PID/EAA issuance must be firmware-bound too. Conversely put: if certificate issuance authorization in software is deemed acceptable, the same holds for WSCA authorization towards the HSM.

The turn

Stop excluding the attacker. Make him visible.

Both problems assume the same defence: keep the attacker out of the WSCA. Firmware is one way to do that. But it is not the only property that yields a secure service.

I do not need to prevent an attacker from getting inside the WSCA. I need to detect that he is there, in near real time, and suspend the service.

Detection at that speed is not a consolation prize. An attacker inside the WSCA is not an incident affecting one user; it is a compromised service. The appropriate response is to shut it down — at which point the single PIN he may have recovered is the least of anyone's problems.

What makes this possible is a property SECDSA already has. Every transaction record is publicly verifiable, and producing one requires the user's PIN. So there exists a check that does not pass through the WSCA at all.

Architecture diagram. The wallet app sends signed instructions through the wallet provider perimeter to the WSCA, which drives a PKCS#11 HSM holding the user's blinding keys and user keys. A monitoring service receives transaction records from the WSCA and audit logs from the HSM, and raises a WSCA compromise alarm that suspends the service. — **Figure 1 — the monitoring service.** It receives two independent streams: the transaction records produced by the WSCA, and the HSM's own audit log of key usage. It sits beside the WSCA, not inside it, and holds no secrets. On any discrepancy it raises a WSCA compromise alarm, and the service is suspended.

The check

What a healthy wallet looks like

To follow the comparison, one term is needed. Each instruction has an execution window: the interval between the moment the wallet provider starts handling it and the moment it completes. Both endpoints are recorded in the transaction record and signed, so the window is publicly verifiable too, and any HSM operation carried out for that instruction must fall inside it.

Now lay the two streams side by side and a pattern appears.

Timeline of regular HSM usage. Four execution windows, each containing one blinding key usage and one user key usage and each followed by a transaction record. Between the windows there are isolated blinding key usages labelled wrong PIN, annotated as at most the lockout threshold minus one. — **Figure 2 — regular usage.** Each execution window carries exactly two HSM operations: the blinding key, which verifies the user's PIN, and then the user key, which executes the instruction. A transaction record follows. Between the windows there are further blinding key usages but no user key usages — these are attempts that did not succeed, most often a mistyped PIN. Their number must stay under the lockout threshold.

The traces

What a compromised WSCA cannot hide

An attacker inside the WSCA can do exactly two things, and each leaves a mark in the comparison.

If he resets the PIN counter to keep guessing, the blinding key is used more times between two transaction records than the lockout threshold permits. The wallet should have blocked and did not.

If he skips authentication and uses a user key directly, that usage falls inside no execution window at all — there is no transaction record that accounts for it.

Timeline of irregular HSM usage. Between the first two execution windows a long run of blinding key usages exceeds the lockout threshold, flagged as PIN counter manipulated. Later a user key usage falls outside any execution window, flagged as authentication bypassed. Both carry warning markers. — **Figure 3 — irregular usage.** Two deviations, one for each thing a compromised WSCA can do. Neither requires the attacker to slip up: they are the unavoidable consequence of using the HSM without the user's PIN. He can call the HSM — he cannot produce a transaction record that explains the call.

Why it holds

A check that needs no trust in the WSCA

The attacker controls the PIN counter, the instruction handling and the timing of every HSM call. What he does not control is the transaction record, because forming one requires the user's PIN and the result is verifiable by anyone.

That asymmetry is the whole argument. The monitoring service needs no secrets, no privileged access and no cooperation from the WSCA. Any third party holding the same two streams reaches the same conclusion.

The monitoring service also needs to store almost nothing. Records and log entries are kept only until they have been matched, after which they can be discarded; what remains is a little bookkeeping per user, and whatever failed to match. And because transaction records carry no reference to relying parties, there is nothing in them from which a user's behaviour could be traced or profiled. The service is therefore a poor target: not much to steal, and not much to protect.

There is a further difference, less technical but not less relevant. A WSCA implemented in HSM firmware places the security claim in code that is proprietary by nature: it cannot be inspected outside the vendor, and any assurance about it rests on the evaluation report. Here the algorithms are published, the conformity checks require no secrets, and the WSCA is ordinary software that a wallet provider can inspect, audit or even publish. A party wishing to satisfy itself that the property holds does not have to take anybody's word for it.

The parameters

What stays public, and what does not

How often the checks are run, which thresholds they apply and what an alarm triggers are matters for the operator, not for a specification. It is worth keeping them confidential. An attacker who knows the thresholds and the intervals can shape his behaviour to stay just below them; withholding them forces him to act without knowing when he will be observed.

This also counts in a Common Criteria evaluation. The attack potential calculation of ISO/IEC 18045 includes the window of opportunity available to an attacker, a factor that explicitly accounts for the risk of detection and for measures in the operational environment. An attacker who must work within bounded and undisclosed detection intervals no longer enjoys unlimited access, which raises the attack potential a successful exploit requires — and that is what the highest resistance level, AVA_VAN.5, asks one to demonstrate.

Note that this is not security by obscurity. The algorithms are published and their correctness does not depend on any parameter being kept secret. The confidentiality is an operational advantage on top of a construction that works without it.