MobileSigner

Built for the SecureSign Innovation Challenge 2026 — an eFile approval platform that keeps the hardware-bound private key and removes the desktop, the driver and the middleware. Signing runs on browser-native WebAuthn, so it works on a phone today.

₹4,790 CrProjected DSC market by 2033

10M+Active DSCs on USB-A tokens

0Mobile PKCS#11 middleware from any Indian CA

The Problem

The ₹4,790 Cr gap in India's PKI infrastructure

Desktop-locked signing

10M+ DSC holders use USB-A tokens (eToken 5110, Proxkey). These physically cannot connect to any mobile device. Officers return to desktops for every Government Order signature.

No mobile middleware

Android USB Host API supports CCID since API 12, but no CA (eMudhra, Sify, CDAC, NIC-CA, TCS) provides a PKCS#11 mobile middleware. The ecosystem gap is 100%.

WebView-blind architecture

NIC’s eOffice, AP’s RTGS dashboard, MCA21 — all use embedded WebViews. Existing desktop signing middleware (Java applets, browser plugins) cannot operate inside WebView contexts.

Zero iOS path

Apple’s IOUSBHost framework (iOS 16+) supports USB-C CCID, but no Indian CA has built an SDK for it. 100% of iPhone users are excluded from DSC signing.

eSign ≠ non-repudiation

C-DAC’s e-Hastakshar and eMudhra eSign use server-side HSMs (IT Act §3A). Private key never in user’s physical possession. Insufficient for GOs requiring §3 non-repudiation.

August 2026 mandate: Digital signatures legally required for all designated government documents. 47.7% CAGR market growth projected (Grand View Research). No mobile solution exists.

The Solution

Three layers — one of them is built

Layer 3 is the working platform in this submission. Layers 2 and 1 are the hardware productisation path, shown for completeness and marked as not yet built.

Layer 3

Browser signing layer and JavaScript bridgeLive in this buildwindow.MobileSigner.sign({fileId, document, action})Browser-native WebAuthn via the Quarkus ceremony client · SHA-256 computed in the browser with crypto.subtle · digest bound to the authenticated officer and appended to the noting sheet · framework-agnostic global for WebView hosts · typed @mobilesigner/web-sdk npm package

Layer 2

PKCS#11 middleware SDKNot built — needs a CAThe path to Section 3: a CSR flow to a CCA-licensed CA, a CMS/CAdES builder over the assertion, certificate path validation to the CCA root, OCSP checking and an RFC 3161 timestamp client. Standard libraries exist for all of it; the blocker is holding a certificate, not the code.

Layer 1

Type-C hardware security moduleNot built — hardware partnerA signing-capable USB-C token would close the last gap, because a standard FIDO2 authenticator authenticates rather than signs documents. Off-the-shelf secure elements such as NXP JCOP 4 or Infineon SLE 78 are the candidates. This build works today with any FIDO2 key, which is what makes it deployable now.

What is genuinely different today

User presence required per signature — the credential cannot be delegated to a section clerk the way a token and PIN can

Credential is origin-bound, so a look-alike domain cannot use it; phishing fails structurally rather than by training

Runs in any modern browser on any platform — no app, no driver, no Java applet, no PKCS#11 host process

Signing ceremony measured per signature and displayed on the file screen — typically well under a second on the network path

No private key on any server. Compromising the platform database yields public keys and digests, never signing capability

Mobile Experience

A Government Order approved from a phone

This is the flow implemented in this build. The two measured stages are timed per signature and shown on the file screen after you sign, so the speed claim is reported from your own device rather than quoted.

Open the file on a phoneAny modern mobile browser — no app install, no driver

no setup

Read the document and noting sheetSame record an officer sees in eOffice: document of record, then the notings

—

Tap Approve, then touch the keynavigator.credentials.get() — user presence and verification on the authenticator

user gesture

Digest computed in the browserSHA-256 of the canonical document via crypto.subtle

measured

Digest bound and recordedGREEN noting appended, approval persisted, audit event written, file returned

measured

Hash and record timings are displayed after every signature

The same flow is reachable from a host application through window.MobileSigner.sign(), so an existing WebView-based portal can trigger it without importing the package or shipping a build step.

Legal & Compliance

The legal position, stated precisely

IT Act 2000 — Section 3 and Section 3A

Section 3 describes a digital signature: an asymmetric key pair with a hash function, where a licensed Certifying Authority binds the public key to an identity in an X.509 certificate. That is what a Class-3 DSC on a USB token provides.

Section 3A describes an electronic signature, judged on whether the signature creation data is under the signatory's exclusive control and whether alteration is detectable.

MobileSigner as built is a Section 3A system. Exclusive control is arguably stronger here than on a PKCS#11 token, because a FIDO2 authenticator requires user presence for every single signature and cannot be left with staff along with its PIN. What is missing for Section 3 is the CA-issued certificate and the CMS container built over it.

Section 3A today, with Section 3 architecture. The gap is a Certifying Authority integration, not a cryptographic redesign.

Standard	State	What it requires	Where this build stands
CCA-SP	Not implemented	PKCS#7 / CMS SignedData with the signer certificate embedded, per RFC 5652	No CMS container is produced. The signature evidence is a WebAuthn assertion binding the officer to a SHA-256 digest.
CCA-XMLSP	Not implemented	W3C XML Digital Signature, enveloped and detached	Not implemented. Documents are signed as a canonical JSON payload, not XML.
CCA-TSG	Not implemented	RFC 3161 timestamp token from a licensed TSA	No TSA is contacted. The approval carries a server-side timestamp only, which is not a trusted timestamp.
CCA-OCSP	Not implemented	Real-time revocation checking per RFC 6960	No responder is contacted, because no signer certificate is issued yet.
CCA-IVG v2.6	Partial	Identity verification bound to hardware possession plus a knowledge factor	Hardware possession and user verification are enforced by the FIDO2 authenticator per signature. The authenticator is not a CCA-approved crypto token, and enrolment has no identity proofing.
CCA-FT	Partial	Tamper-evident audit trail with defined retention	Every decision and verification appends an audit event with actor, outcome and target. There is no insert-only database role, no hash chaining and no retention policy.

Four of the six standards depend on holding a signer certificate from a CCA-licensed CA. Once that exists, they are well-trodden integration work — path building, OCSP and RFC 3161 are solved problems with mature Java libraries.

Comparison

Where this stands today

Assessed against India's current signing options. The status column states what this build does, not what a productised version would do.

Capability	Desktop USB tokeneToken 5110, Proxkey	eSigne-Hastakshar, eMudhra	MobileSignerthis build	Status
Delivered and demonstrable
Signs from a phone or tabletBrowser-native WebAuthn — no app install				Live
Private key stays in the holder’s hardwareKey generated on the authenticator and never exported				Live
Works on iOSSafari WebAuthn, platform or NFC security key				Live
No desktop middleware or driver installNo Java applet, no PKCS#11 host, no browser plugin				Live
Embeds in an existing web app or WebViewwindow.MobileSigner.sign() — framework-agnostic global				Live
Phishing-resistant credentialCredential is origin-bound; a look-alike domain cannot use it				Live
Cannot be delegated to staffUser presence required per signature — no shareable PIN				Live
Signing ceremony under 3 secondsMeasured per signature and shown on the file screen				Live · measured
Open — needs a Certifying Authority
X.509 certificate from a CCA-licensed CANeeds a CSR flow and identity proofing with eMudhra, NIC-CA, Sify or CDAC				Requires CA partnership
PKCS#7 / CMS signature containerA WebAuthn assertion is not a CMS blob; needs a CAdES wrapper				Depends on certificate
RFC 3161 timestamp and OCSP at verificationVerification currently resolves the digest against the approval record				Depends on certificate
IT Act 2000 Section 3 digital signatureThis build satisfies Section 3A; Section 3 needs the certificate above				Section 3A today
Integrated with NIC eOfficeThe workflow is reproduced faithfully, but nothing is wired to eOffice				Not integrated

The honest position. MobileSigner solves the exclusive-control problem — the officer's key is hardware-bound, origin-bound and cannot be handed to a section clerk. That is the failure mode that actually breaks non-repudiation in practice, and it is solved here without a desktop, a driver or an app.

What it does not yet have is a certificate from a CCA-licensed CA, which is what Section 3 turns on. Every item in the second group follows from that one dependency, and none of it is cryptographic research — it is a procurement and integration step. Until it is done, this is a Section 3A system with Section 3 architecture, and the verification screen is labelled accordingly.