Flow Reference
SecureSign — DSC Signing Flow Reference
Seven stages of a signing operation, compared across today's hardware-token desktop DSC signing, today's software-only (soft-cert) DSC signing, PC test tools, the mobile app, the STM32F417 prototype, and the STM32U585 + FPGA production target.
| Stage | What Happens | Today — Hardware Token (Desktop) | Today — Software-Based DSC (No Hardware) | Windows / Mac (PC Test) | Mobile App | Prototype (F417 + mbedTLS) | Real Hardware (U585 + FPGA) | Touches Controller? |
|---|---|---|---|---|---|---|---|---|
| 0. Onboarding — key generation | Device generates a key pair internally; only the public key ever leaves. | Done once, at purchase, by the DSC vendor (eMudhra, Sify, Capricorn, etc.) — usually at a physical Registration Authority or via video-KYC, per CCA rules. Key pair generated on-token by the vendor's own provisioning tools before delivery. | Key pair generated in software (e.g. OpenSSL, or the CA's own enrollment tool) and exported into a password-protected PKCS#12 (.pfx) file. Unlike a hardware token, the private key is exportable — it exists as a file, not confined to a chip. |
N/A for the six-step test below. | SDK calls generateKeyPair() once during enrollment. |
Skipped — demo key pair pre-embedded in flash at build time. | Real GENERATE_KEY_PAIR APDU; key pair generated inside the FPGA's secure key store. |
Yes (real HW) N/A (prototype) |
| 1. Plug in / enumerate | OS recognizes the dongle as a standard USB smart-card reader. | User plugs a USB-A token into a PC. Almost always requires installing that specific vendor's own proprietary driver/middleware first (ePass2003, Aladdin eToken, Watchdata, etc.) — a different installer per brand, and none of it works on mobile. This is the actual gap SecureSign is solving. | Nothing to plug in — the .pfx file just needs to be present on disk (or copied/emailed between machines, which is itself a real security weakness this approach has and hardware tokens don't). |
Device Manager shows a generic "Smart card readers" entry automatically — standard usbccid.sys, no driver install. |
Android: USB Host API attach intent. iOS: needs MFi certification. | STM32F417 enumerates as composite CDC + CCID. | Same enumeration; crypto backend behind it doesn't change this step. | Yes |
| 2. Power on / get ATR | Host asks "what card is this," device answers with its ATR. | Handled invisibly by the vendor's PKCS#11 DLL/driver stack, hidden behind whatever signer utility (or historically, Java applet) the portal uses. | N/A — no smart-card protocol involved. The signing app simply opens the .pfx file directly, using a standard crypto library (e.g. Windows CryptoAPI, OpenSSL). |
opensc-tool --atr / certutil -scinfo |
SDK/middleware issues the equivalent low-level open-session call. | SC_Itf_IccPowerOn() returns a placeholder ATR (still not a real card's ATR — only enough to enumerate; the rest of the flow below no longer needs it to be more than that). |
Forwarded to FPGA over SPI, returns its real capability info. | Yes |
| 3. Read certificates | Host reads the token's cert(s) via SELECT + READ BINARY APDUs. | Signer utility/browser plugin calls the vendor's own PKCS#11 DLL to enumerate certs — works, but only with that vendor's software installed. | The signing app reads the certificate bundled inside the .pfx file itself — a local file parse, not a device query. |
pkcs15-tool --list-certificates |
SDK's enumerateCertificates() → PKCS#11 C_FindObjects/C_GetAttributeValue |
Real SELECT + READ BINARY against a PKCS#15 file system in flash (EF(ODF)/AODF/PrKDF/CDF + the cert EF), with GET RESPONSE chaining since the demo cert (611 B DER) is larger than one CCID bulk message. Same wire protocol a real card uses, not a shortcut. | Same APDUs; cert from secure NVM on the FPGA side. | Yes |
| 4. PIN verification | User's PIN is checked against the device, never cached elsewhere. | Desktop popup (native OS dialog or the signer utility's own window) asks for the token PIN, forwards it to the vendor stack. | User enters a password/passphrase that decrypts the .pfx locally. Critically, this decrypts the private key into the application's own memory — unlike a hardware token, where the key never leaves the chip at all. |
pkcs11-tool --login --pin 1234 |
User enters PIN in-app → SDK's authenticate(pin) → C_Login → VERIFY APDU |
Real VERIFY APDU (INS 0x20) against the demo PIN, with a 3-try RAM retry counter and the standard 63Cx "X tries left" / 6983 "blocked" status words — same host-visible behavior as a real card, just checked against a flash-embedded demo value instead of provisioned secret storage. |
PIN check happens inside FPGA's secure boundary, not the MCU. | Yes — comparison happens on-controller |
| 5. Sign document | App hashes the document, sends only the hash; device signs it with the private key. | Desktop signer utility (or historically a Java applet) hashes the document, sends it via vendor PKCS#11, gets the signature back, embeds it — same PAdES/XMLDSig standards as the new solution. | The hash is signed using the private key now sitting in the app's RAM, via software crypto (e.g. OpenSSL) on the general-purpose PC. The actual signing operation happens outside any tamper-resistant hardware — this is the core difference from both the hardware token and SecureSign. | pkcs11-tool --sign --mechanism ECDSA-SHA256 |
SDK's signHash()/signPdf()/signXml() → C_Sign → PSO APDU |
Real PSO: COMPUTE DIGITAL SIGNATURE APDU (INS 0x2A, P1P2 9E9A), gated on PIN verification, signs the host-supplied hash via mbedtls_ecdsa_sign_det() (deterministic ECDSA / RFC 6979 — no RNG dependency) and returns raw r‖s — software crypto on the F417, not certified, prototype only. |
FPGA's ECC engine signs; key never leaves it; signature relayed back through STM32U585. | Yes — core security-critical step |
| 6. Verify signature | Anyone checks the signature against the public certificate. | Identical to the new solution — recipient verifies with the public certificate, independent of desktop vs. mobile vs. any vendor. | Identical again — verification only ever needs the public certificate, regardless of how (or how insecurely) the private key was held during signing. | openssl dgst -verify pub.pem -signature test.sig test.txt |
Optional in-app convenience, or left to the recipient. | N/A — pure math. | N/A — pure math, identical regardless of backend. | No — device never touched again |
Note on software-based DSC: it's simpler and cheaper (no hardware to buy or lose), but it fails the
requirement that matters most — Security Req 2, "cryptographic operations executed on-token" — because
the private key is exportable and briefly sits in general-purpose RAM during signing. This is exactly why CCA guidance
favors hardware tokens for most Class 3 individual-signing use cases, and why SecureSign is built on the hardware-token
model rather than a purely software one.
Observation: Stages 0, 2, 3, 5, and 6 are conceptually identical to what already works on desktop today.
The real new engineering is stage 1 (driver-less, vendor-agnostic USB-C enumeration that works the same on a phone as a PC)
and carrying stages 2–5 over that same USB-C link on Android/iOS instead of a Windows-only vendor DLL.
Prototype status (F417): stages 1, 3, 4, and 5 are now a real ISO 7816-4 APDU responder over CCID —
SELECT, READ BINARY (with GET RESPONSE chaining), VERIFY, and PSO: COMPUTE DIGITAL SIGNATURE — backed by a PKCS#15
file system and a demo key/cert in flash, not shortcuts or stubs. Verified: builds clean, follows the CCID/ISO 7816
wire protocol correctly, deterministic-ECDSA signing needs no RNG (this MCU has none wired up). Not yet verified:
the PKCS#15 ASN.1 encoding was hand-built against the spec without a live OpenSC rig to test against, so
pkcs15-tool/pkcs11-tool recognizing the card on the first flash isn't guaranteed — the raw-APDU
path (opensc-tool --send-apdu) is the reliable fallback for proving the signing flow end-to-end while
that gets ironed out.
Complete Command Reference — Requirement Traceability
The seven stages above are the core happy-path flow. A real implementation needs the full command set below — every row maps to the specific requirement(s) it exists to satisfy, across all four sections of the spec. "—" means that category genuinely doesn't apply to that row, rather than forcing a stretch connection.
Key to the reference codes used below
Scope of Work (SW) — SW1: complete hardware–software integration stack (token driver, security layer, middleware, SDK, API). SW2: native SDKs + JS bridge, framework-agnostic. SW3: vendor-agnostic support, no single-manufacturer dependency. SW4: reference/demo apps incl. WebView. SW5: complete digital signature workflow (detection, cert enumeration, PIN, signing, embedding/verification).
Functional Requirements (FR) — FR1: detect/communicate with dongle. FR2: enumerate certs, PIN auth, key never leaves dongle. FR3: sign PDF/XML/text. FR4: simple API/SDK, any dev stack. FR5: verifiable signatures, timestamping, clear error handling.
Security & Compliance (Sec) — Sec1: CCA/IT Act 2000 conformance, X.509 certs from Indian CCA-licensed CAs. Sec2: crypto executed on-token, PIN/key never cached/logged/transmitted. Sec3: protection against replay/MITM/tampering, integrity verifiable by standard validators. Sec4: security architecture document (threat model, data flows, compliance mapping).
Deliverables (Del) — Del1: working solution (SDKs, WebView bridge, middleware, token driver layer, source code). Del2: demo apps + live demonstration. Del3: documentation (technical architecture, security architecture, integration guide, API reference, CCA compliance). Del4: concept note, presentation, screenshots, demo video.
Scope of Work (SW) — SW1: complete hardware–software integration stack (token driver, security layer, middleware, SDK, API). SW2: native SDKs + JS bridge, framework-agnostic. SW3: vendor-agnostic support, no single-manufacturer dependency. SW4: reference/demo apps incl. WebView. SW5: complete digital signature workflow (detection, cert enumeration, PIN, signing, embedding/verification).
Functional Requirements (FR) — FR1: detect/communicate with dongle. FR2: enumerate certs, PIN auth, key never leaves dongle. FR3: sign PDF/XML/text. FR4: simple API/SDK, any dev stack. FR5: verifiable signatures, timestamping, clear error handling.
Security & Compliance (Sec) — Sec1: CCA/IT Act 2000 conformance, X.509 certs from Indian CCA-licensed CAs. Sec2: crypto executed on-token, PIN/key never cached/logged/transmitted. Sec3: protection against replay/MITM/tampering, integrity verifiable by standard validators. Sec4: security architecture document (threat model, data flows, compliance mapping).
Deliverables (Del) — Del1: working solution (SDKs, WebView bridge, middleware, token driver layer, source code). Del2: demo apps + live demonstration. Del3: documentation (technical architecture, security architecture, integration guide, API reference, CCA compliance). Del4: concept note, presentation, screenshots, demo video.
| # | Command / Function | Layer | What It Does | Scope of Work | Functional Req. | Security & Compliance | Deliverable |
|---|---|---|---|---|---|---|---|
| Session / Device Management | |||||||
| 1 | SELECT / GET_DEVICE_INFO | Device APDU | Identifies the dongle and its capabilities (the spec's "CTRL" identity step). | SW5 | FR1 | — | Del1 |
| 2 | RESET | Device APDU | Power-cycles the session without a full USB replug. | SW1 | FR1, FR5 | — | Del1 |
| Authentication | |||||||
| 3 | VERIFY_PIN | Device APDU | The spec's "PIN (authentication)" step — checked on-device, never leaves it. | SW5 | FR2 | Sec2 | Del1 |
| 4 | CHANGE_PIN | Device APDU | User-initiated PIN change, same on-device guarantee as verify. | SW1 | FR2 | Sec2 | Del1 |
| 5 | UNBLOCK_PIN (PUK recovery) | Device APDU | Resets a locked-out PIN using a recovery code, without extracting key material. | SW1 | FR5 — "wrong PIN" named explicitly | Sec2 | Del1 |
| 6 | GET_PIN_RETRIES | Device APDU | Reports remaining PIN attempts before lockout. | — | FR5 | — | Del1 |
| Key Management | |||||||
| 7 | GENERATE_KEY_PAIR | Device APDU | The spec's "PUF (root key) → ECDSA (key pair)" step — key pair generated on-device from the hardware root key. | SW1 | FR2 — private key must never leave the dongle | Sec2 — crypto executed on-token | Del1 |
| 8 | GET_PUBLIC_KEY | Device APDU | Exports only the public key — the spec's explicit "Only the public key leaves the device." | SW5 | FR2 | Sec2 | Del1 |
| 9 | DELETE_KEY | Device APDU | Key lifecycle/re-issuance support (lost device, re-enrollment). | SW1 | — | Sec4 — feeds the security architecture document | Del3 |
| Certificate Management | |||||||
| 10 | IMPORT_CERTIFICATE | Device APDU | Loads the CA-signed X.509 certificate back onto the device after CA enrollment. | SW5 | FR2 | Sec1 — X.509 certs from Indian CCA-licensed CAs | Del1 |
| 11 | GET_CERTIFICATE | Device APDU | Reads a stored certificate. | SW5 | FR2 — enumerate certificates | — | Del1 |
| 12 | GET_CERTIFICATE_CHAIN | Device APDU | Returns the full chain (intermediate + root CA) needed for independent verification. | SW5 | FR5 — verifiable signatures | Sec3 — integrity verifiable by standard validators | Del1 |
| 13 | LIST_CERTIFICATES | Device APDU | Enumerates multiple stored identities if the token supports more than one. | SW5 | FR2 — allow user selection | — | Del1 |
| Signing Operations | |||||||
| 14 | SIGN_HASH (PSO: Compute Digital Signature) | Device APDU | The core operation — signs a hash with the on-device private key; the key itself never crosses back out. | SW5 | FR3, FR2 | Sec2 — private key stays on-token | Del1 |
| 15 | GET_SIGNING_ALGORITHM_INFO | Device APDU | Reports supported algorithms/curves for interoperability. | — | FR5 — standards-compliant | — | Del1 |
| Timestamping | |||||||
| 16 | REQUEST_TIMESTAMP | Host-side (TSA call) | Obtains an RFC 3161 timestamp from a Time Stamping Authority, embedded alongside the signature. | — | FR5 — "timestamping support," named explicitly | — | Del1 |
| Device Lifecycle & Security | |||||||
| 17 | LOCK_DEVICE / FACTORY_RESET | Device APDU | Administrative wipe/lock, e.g. for a lost or compromised dongle. | SW1 | — | Sec3 — protection against tampering | Del1 |
| 18 | GET_SECURITY_STATUS / tamper status | Device APDU | Reports tamper flags if the hardware supports detection. | SW1 | — | Sec3 — protection against tampering | Del3 |
| 19 | FIRMWARE_VERSION / secure-boot attestation | Device APDU | Reports firmware/attestation info for audit purposes. | SW1 | — | Sec4 — feeds the security architecture document | Del3 |
| Cross-Cutting | |||||||
| 20 | Consistent SW1SW2 status-word taxonomy | Device APDU (all commands) | Every command above returns through the same error-code system (no dongle, wrong PIN, expired certificate, etc.) — this is scope across all ~19 device commands, not a separate feature. | SW5 | FR5 — clear error handling, named with these exact examples | — | Del3 |
| Host / SDK Layer (not device commands) | |||||||
| 21 | SDK wrapper functions (detectDongle(), enumerateCertificates(), authenticate(), sign(), ...) | SDK | The simple, documented API app developers actually call — wraps every device command above. | SW1, SW2 | FR4 — minimal integration code | — | Del1, Del3 — this is what the API reference documents |
| 22 | WebView JavaScript bridge | SDK / JS | Exposes the same SDK surface to WebView pages via addJavascriptInterface (Android) / WKScriptMessageHandler (iOS). | SW2 — "JavaScript bridge/interface... WebView applications" | FR4 — framework-agnostic | — | Del1, Del2 — exercised by the WebView demo |
| 23 | PAdES / XMLDSig / raw-hash container building | SDK | Wraps the raw signature from SIGN_HASH into a standards-compliant PDF, XML, or hash signature container. | SW5 | FR3 | — | Del1 |
| 24 | Vendor-agnostic PKCS#15 generic client | Middleware | Reads any compliant token's standard object layout instead of a vendor-specific one. | SW3 — "no dependency on a single token manufacturer" | — | — | Del1 |
| 25 | Independent signature verification | Host-side (SDK or recipient's own tools) | Confirms a signature against the public certificate — no device involved. | SW5 — "signature embedding/verification" | FR5 | Sec3 — verifiable by standard validators | — |
Project-level items not tied to a single command: SW4 (reference/demo apps) and
Del2 (demo apps + live demonstration) are satisfied by the assembled demo app itself — built from
rows 21–24 above, not any one command. Del4 (concept note, presentation, screenshots, demo video) is
purely submission packaging for the challenge portal, satisfied by presenting this documentation alongside a working
prototype, not by firmware or SDK work.
Status & Roadmap
SecureSign — Status & Roadmap
Current state of the STM32F417 prototype scored against the ten-category, 100-mark evaluation rubric,
what's still missing in each category, and the next steps to close the gaps. Reflects only what has been verified this
session (live opensc-tool / PC-SC testing over the working CDC+CCID USB link) — not aspirational claims.
| Category | Marks | Status | Evidence / Current State | Gap / What's Needed |
|---|---|---|---|---|
| Technical Feasibility | 12 | Proven | Full end-to-end flow works on real hardware: USB composite CDC+CCID enumerates, ATR completes, SELECT → VERIFY PIN → PSO: COMPUTE DIGITAL SIGNATURE all succeed against opensc-tool/PC-SC, returning a valid 64-byte P-256 signature (SW=9000) in under 700 ms. Certificate SELECT + READ BINARY (611 bytes) also verified, including USB packet chunking and CCID GET RESPONSE (61xx) handling. |
— |
| Performance & Reliability | 10 | Working | Full PIN-verify-and-sign round trip completes in well under a second. Boot is stable after fixing the bootloader stack-pointer validation, watchdog timing, and CCID multi-packet transfer bugs found this session — no resets observed across repeated testing. | Signing currently executes synchronously inside the USB interrupt path. Fine at P-256 speeds on this prototype, but should move to a task context before scaling to slower operations. |
| Innovation & Originality | 10 | Partial | Digital Signature Certificates remain bound to the desktop: every hardware token ships with its own vendor driver, and that dependency is precisely why DSC signing has never reached mobile. SecureSign removes it. One driverless, generic Type-C dongle integrates with any Android, iOS, or Windows application — native or WebView, regardless of stack — delivering the same plug-and-play signing experience users expect on desktop, fully compliant with CCA guidelines. Its onboarding sequence is rooted in hardware at every step: CTRL establishes device identity, PIN authenticates the user, the FPGA's PUF derives a unique hardware root key, and the ECDSA key pair is generated on-device directly from that root — the private key never leaves the silicon; only the public key does. This prototype validates that protocol on real USB hardware, end to end: driverless CCID enumeration, on-device PIN verification, and on-device signing, with an MCU and mbedTLS software cryptography standing in for the FPGA's dedicated crypto engines. | The mobile-facing half of the innovation — Android/iOS SDK, WebView bridge, and the FPGA target itself (USB device controller, CCID/APDU parser, command dispatcher, SPI/I²C/GPIO masters, AES/SHA/ECC/RSA engines, TRNG, Key Manager, flash controller) — is not yet built. This board is a desktop-only proof of the protocol, not the cross-platform dongle itself. |
| Security Architecture | 15 | Partial | On-device PIN gate and deterministic ECDSA (RFC 6979, mbedTLS) signing implemented and tested — the private key never leaves the device during signing. | Demo private key is embedded in flash rather than generated/held in a secure element (this MCU has none). No written security-architecture document yet (threat model, data flows, key custody). |
| Compliance with CCA Guidelines | 15 | Partial | PKCS#15 file structure (EF(DIR)/ODF/AODF/PrKDF/CDF/TokenInfo) implemented and readable by standard tooling. | Certificate is self-signed, not issued by a CCA-licensed CA. No GENERATE_KEY_PAIR, CHANGE_PIN, UNBLOCK_PIN, or GET_PIN_RETRIES — key/PIN are fixed demo values, not provisioned per requirements. |
| Interoperability Across Platforms | 10 | Partial | Confirmed working on Windows via PC/SC and OpenSC, using the standard driverless CCID class. | Not yet tested on Linux/macOS PC/SC. No mobile (Android/iOS) path exists yet. |
| User Experience | 8 | Minimal | On-device LCD shows live status (PIN / cert / sign / last event) driven off a lock-free event queue fed from the USB ISR. | No host-side application yet — testing today is command-line only via opensc-tool. |
| Ease of Integration | 8 | Not started | — | No SDK or wrapper layer yet — every test so far talks raw APDUs directly. Need a thin host SDK (detect / verify PIN / sign / read cert) so integrators don't need PC/SC or APDU knowledge. |
| Scalability & Maintainability | 6 | Prototype-only | Single hardcoded demo key and PIN, by design, for this proof-of-concept. | Production is intended to move to different target hardware (STM32U585 + FPGA) rather than extend this prototype's key handling. |
| Deployment Readiness | 6 | Not started | — | No packaged submission deliverables yet — demo app, documentation set, concept note, or walkthrough video. |
Where we are today: 2 of 10 categories proven & working, 6 partial with a clear specific gap, 2 not
yet started. The core signing flow — the part every other category depends on — is fully working end-to-end on real
hardware, on the desktop side of the model. Remaining gaps are mostly about breadth (mobile/FPGA target, compliance commands, platforms, packaging) rather than whether the
core idea works.
Next Panel — Roadmap
Ordered by what unblocks the most rubric categories per step of effort — command-set gaps first, since they're referenced by both Security Architecture and CCA Compliance, then integration, then platform breadth, then packaging.
| # | Next Step | Why It Matters | Closes Gap In |
|---|---|---|---|
| 1 | Verify PKCS#15 at the tooling level | Run pkcs15-tool / pkcs11-tool against the device, not just raw APDUs, to catch anything a real signing client would trip on that opensc-tool --send-apdu testing can't reveal. | Technical Feasibility, Interoperability |
| 2 | Implement the missing card commands | CHANGE_PIN, UNBLOCK_PIN, GET_PIN_RETRIES, GET_CERTIFICATE_CHAIN, and a timestamp request — the set most compliance and security gaps trace back to. | Security Architecture, CCA Compliance |
| 3 | Write the security architecture document | Key custody, PIN handling, threat model, and what's demo-only vs. production-real. Directly required, not just implied. | Security Architecture, CCA Compliance, Deployment Readiness |
| 4 | Build a minimal host SDK + demo app | Wraps detect/verify/sign/read-cert so the device can be integrated without APDU knowledge. | Ease of Integration, User Experience |
| 5 | Test on Linux/macOS, then scope mobile | Confirm PC/SC behavior beyond Windows before committing to an Android/iOS SDK effort. | Interoperability |
| 6 | Plan the production hardware move | Define what changes — secure key storage, CA-issued certificate, real GENERATE_KEY_PAIR on a secure element — when moving off this prototype MCU to STM32U585 + FPGA. | Scalability & Maintainability, CCA Compliance |
| 7 | Assemble submission deliverables | Demo app, documentation, concept note, and a recorded walkthrough of the working SELECT → VERIFY → SIGN flow. | Deployment Readiness |
Scope note: figures above reflect the STM32F417 prototype only, verified this session via direct
opensc-tool and serial-log testing. This is not a production security claim — see the
Flow Reference tab for how each stage compares against the intended production target
(STM32U585 + FPGA) and today's hardware-token / software-DSC alternatives.
Testing Guide
SecureSign — Testing Guide
Test cases for the STM32F417 prototype dongle, organized in four levels — device/APDU, PKCS#15/PKCS#11, real application, and reliability. Run each level in order: a failure at Level 1 explains a failure at every level above it.
| TC# | Objective | Command | Expected Result | Status |
|---|---|---|---|---|
| 1.1 | Device enumerates as composite CDC + CCID | Windows Device Manager → Ports (COM) & LPT + Smart card readers | One CDC COM port and one "SEQUENTIA SecureSign Dongle" reader appear, no driver install prompt | Verified |
| 1.2 | Reader is visible to PC/SC | opensc-tool --list-readers | Reader listed by name, card present | Verified |
| 1.3 | ATR retrieval | opensc-tool --atr | 19-byte T=0 ATR returned, no SCARD_STATE_MUTE | Verified |
| 1.4 | SELECT by AID/FID | opensc-tool --send-apdu 00A4000C023F00 | SW=9000 | Verified |
| 1.5 | READ BINARY on certificate EF, with chaining | opensc-tool --send-apdu 00B0000000 (611-byte cert, exceeds one 64-byte CCID packet) | Full DER certificate returned intact via GET RESPONSE (61xx) chaining; matches embedded demo cert byte-for-byte | Verified |
| 1.6 | VERIFY PIN — correct value | opensc-tool --send-apdu 002000810431323334 | SW=9000 | Verified |
| 1.7 | VERIFY PIN — wrong value, retry counter | Send VERIFY with an incorrect PIN once | SW=63C2 (2 tries remaining), no crash, correct PIN still works after | Not yet run |
| 1.8 | PIN lockout after repeated failures | Send VERIFY with wrong PIN three times in a row | SW=6983 on the 3rd attempt and on all further attempts, including with the correct PIN | Not yet run |
| 1.9 | PSO: COMPUTE DIGITAL SIGNATURE | opensc-tool --send-apdu 002A9E9A20<32-byte-hash> | 64-byte raw r‖s ECDSA signature, SW=9000, completes in <700 ms | Verified |
| 1.10 | Signature validity (independent check) | openssl dgst -verify pub.pem -signature test.sig test.hash against the r‖s from TC 1.9 (DER-wrapped) | OpenSSL reports Verified OK | Not yet run |
| 1.11 | Signing without prior PIN verify is rejected | Power-cycle card, send PSO:SIGN without VERIFY first | SW=6982 (security status not satisfied) | Not yet run |
| 1.12 | Malformed APDU handling | Send a truncated/incomplete APDU | Clean error status word (e.g. SW=6A86), no hang, device remains responsive to the next command | Verified (found during testing — was my own malformed test command, device behaved correctly) |
| TC# | Objective | Command | Expected Result | Status |
|---|---|---|---|---|
| 2.1 | Generic PKCS#15 driver parses the on-card file system | pkcs15-tool --dump | ODF, AODF, PrKDF, CDF, and TokenInfo all parse without errors | Not yet run |
| 2.2 | Certificate enumeration via OpenSC | pkcs15-tool --list-certificates | Demo certificate listed with correct label/usage | Not yet run |
| 2.3 | PKCS#11 object listing | pkcs11-tool --module opensc-pkcs11.dll --list-objects | Private key and certificate objects both listed, correct CKA_ID linkage | Not yet run |
| 2.4 | PKCS#11 login | pkcs11-tool --module opensc-pkcs11.dll --login --pin 1234 --test | Login succeeds, built-in self-test signs and verifies successfully | Not yet run |
| 2.5 | PKCS#11 sign via mechanism | pkcs11-tool --sign --mechanism ECDSA-SHA256 --login --pin 1234 -i data.txt -o data.sig | Signature file produced, verifies against the public certificate | Not yet run |
| TC# | Objective | Method | Expected Result | Status |
|---|---|---|---|---|
| 3.1 | Adobe Acrobat recognizes the token | Attach opensc-pkcs11.dll under Edit → Preferences → Signatures → PKCS#11 Modules | Demo identity appears under Digital IDs after PIN login | Not yet run |
| 3.2 | End-to-end PDF signing | Sign any PDF in Acrobat using the demo identity | PAdES signature embedded; Acrobat shows "Signature is valid" on reopen | Not yet run |
| 3.3 | Programmatic sign/verify via PyKCS11 | Small Python script: load module, login(pin), sign(hash), verify against public cert | Script reports signature valid, matching TC 1.9/1.10 result through a real application-layer API | Not yet run |
| 3.4 | OpenSSL engine signing (libp11) | openssl dgst -engine pkcs11 -keyform engine -sign "pkcs11:object=...", -out out.sig file.txt | Signature produced without any vendor-specific code, using only standard OpenSSL + PKCS#11 engine | Not yet run |
| TC# | Objective | Method | Expected Result | Status |
|---|---|---|---|---|
| 4.1 | No unexpected resets under normal use | Run TC 1.4 → 1.9 in a loop 20+ times, watch CDC log | No IWDG reset, no hang, consistent timing each pass | Verified (stable across repeated testing this session) |
| 4.2 | Power-on without debugger attached | Unplug/replug the dongle directly (no ST-Link session) | Enumerates and responds identically to the debugger-attached case | Verified (root cause of the earlier boot-hang was fixed) |
| 4.3 | LCD status reflects live flow state | Watch LCD while running SELECT → VERIFY → SIGN from a host | Status rows update per stage (Idle → Card ON → PIN OK → Sign OK) without flicker or garbled text | Verified |
| 4.4 | CDC debug log is readable and correctly tagged | Open the CDC COM port in a serial terminal during a test run | Each line is [MODULE] Message. format, no garbled/binary output | Verified |
Summary: Level 1 (device/APDU) is fully proven — this is the hard, security-critical part and it works.
Levels 2 and 3 are the next actions needed (see the Status & Roadmap tab, step 1) — they test whether
standard tooling and real applications, not just direct APDU calls, can use the dongle without any custom code.
How to run Level 2/3 tests: requires OpenSC installed (already done —
opensc-tool.exe confirmed
working this session) and, for Level 3, either Adobe Acrobat or a small PyKCS11 script pointed at
opensc-pkcs11.dll (typically under C:\Program Files\OpenSC Project\OpenSC\pkcs11\). See
the Flow Reference tab for how each stage maps to the production (STM32U585 + FPGA) target.
Requirement Spec
Requirement Specification — SecureSign Type-C DSC Dongle Mobile Signing Solution
Sequentia's original requirement document in full, reformatted for the site. This is the source of truth the Flow Reference, Status & Roadmap, and Testing Guide tabs are all built against.
1. Background & Objective
The SecureSign requirement is to solve a real-world gap: Digital Signature Certificate (DSC) signing today works only on desktops. The objective is the end-to-end development of a generic Type-C DSC dongle signing solution that integrates seamlessly with mobile apps and mobile WebView applications — irrespective of the app's development stack — on both Android and iOS, giving users a plug-and-play signing experience comparable to desktop DSC signing, fully conforming to CCA (Controller of Certifying Authorities) guidelines.
Onboarding / login flow: the host confirms the device identity, authenticates the user with a PIN, then has the device derive its hardware root key and generate the DSC key pair. Only the public key leaves the device.
CTRL (identity) → PIN (authentication) → PUF
(root key) → ECDSA (key pair). Responses: pin_ok, key_ready, and the
public key.
2. Scope of Work (Full Solution Build)
- Design and develop the complete hardware–software integration stack: token driver integration, security layer, middleware, SDK, and API framework for Type-C DSC dongles.
- Native SDKs for Android and iOS, plus a JavaScript bridge/interface enabling signing from mobile WebView applications, framework-agnostic (native, Flutter, React Native, hybrid web).
- Vendor-agnostic support for commonly used CCA-approved Type-C DSC tokens (e.g., PKCS#11-compliant tokens); no dependency on a single token manufacturer.
- Reference/demo mobile applications on Android and iOS demonstrating the full signing workflow, including a WebView demonstration.
- Complete digital signature workflow: dongle detection, certificate enumeration and selection, PIN authentication, document signing (PDF, XML, text), and signature embedding/verification.
3. Functional Requirements
- FR1: Detect and communicate with a Type-C DSC dongle on plug-in (USB-C OTG on Android; supported connectivity per Apple MFi/USB-C on iOS).
- FR2: Enumerate certificates on the token, allow user selection, and authenticate via token PIN; private key must never leave the dongle.
- FR3: Sign PDF (PAdES-compatible), XML (XMLDSig), and text/hash payloads invoked from a host mobile app or WebView page.
- FR4: Expose a simple, documented API/SDK so any third-party app can integrate signing with minimal code, independent of its development stack.
- FR5: Return verifiable, standards-compliant signatures with timestamping support and clear error handling (no dongle, wrong PIN, expired certificate, etc.).
4. Security & Compliance Requirements
- Full conformance to CCA guidelines and IT Act, 2000 provisions for digital signatures; support X.509 certificates issued by Indian CCA-licensed CAs.
- Cryptographic operations executed on-token; PIN and key material never cached, logged, or transmitted. Secure channel between app, middleware, and token.
- Protection against replay, man-in-the-middle, and tampering; signed-data integrity verifiable by standard validators.
- Security architecture document covering threat model, data flows, and compliance mapping (to be part of deliverables).
5. Deliverables
- Working solution: Android SDK, iOS SDK, WebView bridge, middleware, and token driver integration layer — with source code (repository access to Sequentia).
- Demo apps (Android & iOS) and live demonstration of the end-to-end signing workflow, including WebView flow.
- Documentation: technical architecture document, security architecture overview, integration guide, API reference, and CCA compliance documentation.
- Concept note, solution presentation, prototype screenshots, and demo video in formats required by the challenge portal (file-size limits apply).
6. System Architecture — Communication Stack
Every signing call travels down one fixed stack, from the application on the host to the secure element on the dongle. Nothing above the STM32 / FPGA line ever sees the private key — it terminates inside the secure element and only status words and signatures travel back up.
Application
▼
PKCS#11 API
▼
PKCS#11 Library (DLL / SO / DYLIB)
▼
PC/SC Smart Card API
▼
USB CCID Driver
▼
USB Cable
▼
STM32 / FPGA
▼
APDU
▼
Secure Element
On this prototype: the STM32F417 stands in for the STM32/FPGA layer, and mbedTLS software crypto stands in for the secure element — the stack above it (PKCS#11 → PC/SC → USB CCID) is real and unchanged from the production target.