Educational tour · Annex D + F

SECDSA & the software WSCA

Sole control you can verify — without burying the wallet provider in HSM firmware.

A gentle, step-by-step introduction

Not for production. SECDSA is patent-encumbered — see USAGE.md. This deck is for learning only. Terms: GLOSSARY.md.

Before we start

Terminology lives in the glossary

Words like CKM_ECDH1_DERIVE, Y_bl, τ_U, ASN, Tr, and “blinding” are collected with plain-language definitions.

Roles: Wallet, WSCA, WSCD, Monitor, Judge
SECDSA letters: u, Y, a_U, G', …
Windows & records: ASN, TS_S/TS_E, Tr, IC
PKCS#11: CKM_…, CKA_…, SoftHSM

Open GLOSSARY.md · also linked from the lab header.

The problem

What does “sole control” mean?

Only you (PIN + your device) can authorize use of your keys — and later, anyone should be able to check that this was true.

If the wallet provider’s software is hacked, it might drive keys in the HSM. The old instinct: put that software inside HSM firmware.

This design’s answer: keep a normal software WSCA — but make misuse detectable fast.

Players

Cast of characters

Who	Plain-language role
Wallet	Your phone. Holds PIN + device key. Never sends the raw PIN-sensitive public key.
WSCA	Provider’s software (a container). Orchestrates work. Do not trust it.
HSM / WSCD	Hardware (or SoftHSM). Holds secrets. Writes an audit log of every key use.
Monitor	Independent checker: receipts × audit. No secrets.
Judge	Anyone with public evidence. Runs Algorithm 38.

Architecture

Big picture

flowchart LR W["Wallet · phone"] <--> S["WSCA · software"] S <--> H["HSM / WSCD"] H -. "audit log" .-> M[Monitor] S -. "Transaction Records" .-> M S -. "Tr + IC" .-> J[Judge]

Monitor compares two streams the attacker cannot keep consistent: public receipts and hardware audits.

Crypto · gentle

Points, not pain

Public-key idea

Private key = secret number u

Public key = U = u · G

Given U, recovering u is hard. That’s the lock.

ECDSA

A way to prove “I know u” for a message — without revealing u.

Verifiers only need the public key.

Split-ECDSA

Two factors, one signature

Ordinary ECDSA: one private key signs.

SECDSA binds signing to both:

PIN → turned into a number P (what you know)
Device key u (what the phone holds)

Roughly: strength like P · u — a safe that needs code + physical key.

The design carefully avoids handing the provider the PIN-sensitive public point Y = P · U.

Why blind?

Don’t leak a PIN oracle

If someone steals Y = P · U, they can guess PINs offline until the math matches.

So the wallet sends only a blinded copy:

Y_bl = t · Y (random t chosen on the phone)

Provider + HSM work on blinded material
Wallet unblinds locally, then deletes Y and t

Provider never learns raw Y.

1

Activate the wallet

Protocol 4 · Internal Certificate

Create a certificate binding account id, blinded SECDSA material, and device key U — without revealing raw Y.

sequenceDiagram participant W as Wallet participant S as WSCA participant H as HSM W->>W: Build U and Y from PIN + device W->>S: Send blinded Y_bl (not Y) S->>H: Create a_U · compute blinded points H-->>S: G' , Y_bl' S-->>W: G' , Y_bl' W->>W: Unblind to Y' · delete Y and t W->>S: Finish with proofs S-->>W: Internal Certificate

After activation

What stays where?

On the phone

PIN (user)
Device key u
Internal Certificate
Gone: raw Y, factor t

Provider / HSM

Blinding key a_U (non-extractable)
IC copy, counters PC / τ
Never has: raw Y, PIN

2

Open a freshness window

Before each instruction

WSCA issues (TS_S, N):

TS_S — earliest time this attempt may run
N — nonce binding this attempt

Later the receipt closes the window at TS_E.

Same wallet → windows never overlap, so each HSM use maps to at most one receipt.

3

Sign the instruction

Algorithm 36 · on the phone

User enters PIN
SECDSA-sign the instruction (PIN + device)
Attach zero-knowledge proofs (WSCA can check math, not learn PIN)
Encrypt the instruction body
Send challenge + ciphertext + proof points

Wrong PIN still sends a message — the HSM check fails without leaking the PIN.

4

WSCA executes

Algorithm 37 · provider + HSM

sequenceDiagram participant W as Wallet participant S as WSCA participant H as HSM W->>S: Signed instruction S->>H: 1 · PIN verify ECDH · audit blinding alt PIN OK S->>H: 2 · Run ECHO / GENKEY / SIGN · audit user H-->>S: Result S-->>W: Transaction Record else fail S-->>W: Reject · counter++ end

Two HSM uses on success: (1) authenticate with blinding key a_U, then (2) perform the instruction’s user-key op. The paper’s “one PKCS#11 call” refers to that authentication step — not the whole instruction.

Evidence

Transaction Record = public receipt

Each successful run produces a Tr that binds:

the authorized instruction
SECDSA / proof data
HSM result
window end TS_E
provider signature

A compromised WSCA cannot forge a valid Tr without the user’s PIN factors.

5

Anyone can verify

Algorithm 38 · the Judge

Inputs (all public): Internal Certificate · record public key · Transaction Records

Output: ACCEPT or REJECT per record

No PIN
No HSM secret a_U
No need to trust the live WSCA process

Transferable evidence for disputes — the lab’s Judge page.

Annex F

Don’t prevent — detect

Inside a compromised WSCA an attacker can reset counters or skip PIN checks.

They still cannot mint matching receipts for what the HSM actually did.

Security rests on an axis that does not pass through the WSCA: Transaction Records × HSM audit log.

Near-real-time alarm → suspend the service. No proprietary WSCA firmware required for that argument.

Visual check

Windows × audit marks

time →
       [==== window SN1 ====]        [==== window SN2 ====]
            ▲        ▲                    ▲        ▲
         blinding  user                blinding  user

  …too many PIN guesses…  →  Alg 39 alarm
       ▲ ▲ ▲ ▲ ▲

  orphan user (no window)  →  Alg 40 alarm
       ◆

Bars = claimed windows in receipts. Marks = real HSM key uses.

Algorithms 39 & 40

Monitor in plain English

Alg 39 · PIN lockout

One blinding use per window
Between windows: ≤ τ−1 extra blinds
More → counter was cheated

Alg 40 · key use

Every user-key use inside a window
Uses match the instruction
Orphan mark → auth bypass

Lab demos

What attacks look like

Simulate	What the monitor sees
Skip PIN · use user key	User audit with no matching window → Alg 40
Burn τ PIN attempts	Too many blinds between windows → Alg 39
Honest traffic	NO_ALARM

Paper’s operational response: raise WSCA_COMPROMISE_ALARM and suspend.

Storage

Tiny receipts on the phone

Keep ~200 bytes per transaction:

ASN ‖ TS_E ‖ T₁ ‖ T₂ ‖ T₃ ‖ Sig

Full Tr stays with the provider
On dispute: rehydrate, check hashes + Alg 38
Provider can’t produce a match → settle for the user

Recap

End-to-end

flowchart TD A["1 Activate · Protocol 4"] --> B["2 Freshness token"] B --> C["3 Wallet signs · Alg 36"] C --> D["4 WSCA + HSM · Alg 37 → Tr"] D --> E["5 Verify · Alg 38 Judge"] D --> F["Monitor · Alg 39/40"]

Hands-on

Run the lab

git clone https://github.com/HarryKodden/SECDSA
cd SECDSA && go run ./cmd/lab
# http://localhost:8080

docker pull ghcr.io/harrykodden/secdsa:latest
docker run --rm -p 8080:8080 ghcr.io/harrykodden/secdsa:latest

Path: Activate → GENKEY → SIGN → Monitor → Burn τ → instruct → Timeline → Judge.

Before you ship anything

Please remember

Educational / research implementation
Not production, not certified
SECDSA is patent-encumbered — Apache-2.0 here does not grant patent rights
Read USAGE.md and NOTICE

Paper: wellet.nl/SECDSA-EUDI-wallet-latest.pdf

Thank you

Sole control without trusting the WSCA — detect compromise, don’t bury it in firmware.

← → or space to move · home/end for ends · glossary

Educational only. No patent license. No production claims.