Smart Card Web Authentication

Smart Card Web Authentication

Smart cards provide the strongest available factor for web authentication: a hardware-bound private key that never leaves the secure element, combined with a PIN or biometric for user presence. Two complementary approaches exist for browser-based deployments — WebAuthn (FIDO2FIDO2StandardPasswordless authentication standard.Click to view →) and TLS client certificates via PKCS#11.

WebAuthn / FIDO2 with Smart Cards

FIDO2 defines the WebAuthn browser API and the CTAP2 protocol for communicating with external authenticators. A smart card can act as a FIDO2 authenticator when it implements the CTAP2 command set — either via direct USB/NFC transport or through OS middleware that bridges PC/SC to CTAP2.

Registration Flow

Browser                Server               Smart Card
  │                       │                     │
  │── navigator.credentials.create() ──────────>│
  │<── challenge (random nonce) ─────────────── │
  │                                              │
  │── CTAP2 MakeCredential(challenge, rpId) ──>  │
  │           (PIN prompt displayed)             │
  │<── authenticatorData + attestation ──────── │
  │                                              │
  │── POST /register {attestation} ───────────>  │
  │                        │── verify attestation│
  │<── 200 OK + credential stored ────────────── │

The card generates an ECC key pair on-card; the private key is bound to the relying party ID (rpId) and never exported.

PKCS#11-Based FIDO2 Bridging

Cards that expose a PKCS#11 interface (rather than native CTAP2) require a PKCS#11-to-FIDO2 bridge. The OpenSC opensc-pkcs11.so module, loaded into Firefox's security devices panel, exposes card keys as platform authenticators:

Firefox → NSS (PKCS#11) → opensc-pkcs11.so → PC/SC → Smart Card

Configuring Firefox: 1. Open about:preferences#privacy → Certificates → Security Devices. 2. Load module: path to opensc-pkcs11.so. 3. The card's keys appear as "SmartCard: Slot N" in certificate dialogs.

TLS Client Certificates

Client certificate authentication (mTLS) embeds the client's identity in the TLS handshake. The smart card holds the private key; the server validates the certificate chain.

APDU Flow During TLS Handshake

The TLS stack requests a CertificateVerify signature. This triggers a PKCS#11 C_Sign call that generates a single APDU to the card:

CLA INS P1  P2  Lc  [hash bytes...]
00  2A  9E  9A  20  <32-byte SHA-256 digest>
                    ────────────────────────
Response: <signature bytes> 90 00

The browser blocks until the card returns — typically 300–800 ms for RSARSACryptographyPublic-key algorithm for smart card signatures and key exchange.Click to view →-2048.

Nginx Configuration (mTLS)

server {
    listen 443 ssl;
    ssl_client_certificate /etc/nginx/ca-bundle.pem;
    ssl_verify_client       on;
    ssl_verify_depth        3;

    location /secure/ {
        # Pass DN to application
        proxy_set_header X-SSL-Client-DN $ssl_client_s_dn;
        proxy_pass http://127.0.0.1:8000;
    }
}

Browser and OS Support Matrix

PIV and CAC Integration

US government PIV and CAC cards follow NIST SP 800-73 and carry X.509 certificates in well-known slots:

Enrol a PIV certificate in a web application by extracting the chain:

pkcs15-tool --read-certificate 9A | openssl x509 -inform DER -text -noout

Security Considerations

• Origin binding: WebAuthn credentials are bound to rpId; phishing pages receive only assertions for their own origin — not the legitimate site's credentials.
• Certificate revocation: Check CRLs or OCSP for every mTLS handshake; smart card certificates are revoked when cards are lost or stolen.
• PIN entry: Prompt for PIN at the OS/middleware level, not in JavaScript — browser input fields are visible to page scripts.

For the underlying PKCS#11 mechanics, see PKCS#11 for Smart Cards. For card identification, use the Card Identifier.