PKI on Smart Cards

PKI on Smart Cards

Public Key Infrastructure (PKI) running on smart card hardware is the foundation of government PIVPIVIdentityUS federal identity card standard.Click to view → cards, NATO CACCACIdentityUS DoD identification smart card.Click to view → cards, corporate badge access, and document signing tokens. The smart card generates and stores the private key in tamper-resistant silicon; the corresponding certificate, issued by a Certificate Authority, travels with the card and is presented during authentication or signing operations.

Key Concepts

On-Card Key Generation

The cardinal rule of PKI on smart cards: generate the key pair on the card, never import it. NIST SP 800-73 mandates on-card key generation for PIV credentials.

The APDU sequence for key generation (PIV/OpenPGP applets):

# PIV GENERATE ASYMMETRIC KEY PAIR (INS=47)
Command: 00 47 00 9A  05  AC 03 80 01 11  00
                   ^           ^     ^
              key ref (9A)   template  ALG=11 (RSA-2048)

Response: 7F 49 ...  (public key in TLV)
  SW1 SW2: 90 00

For ECCECCCryptographyEfficient public-key cryptography using elliptic curves.Click to view → P-256 (ALG=06):

Command: 00 47 00 9A  05  AC 03 80 01 06  00
Response: 7F 49 86 41 04 [64 bytes: uncompressed EC point]
  SW1 SW2: 90 00

PKCS#15 File Structure

ISO 7816-15 defines a portable on-card layout. Key files under the PKCS#15 application DF:

DF.PKCS15
├── EF.ODF          — Object Directory File (pointers to all object DFs)
├── EF.TokenInfo    — Card label, serial number, capabilities
├── EF.PrKDF        — Private Key Directory (key metadata, usage flags)
├── EF.PuKDF        — Public Key Directory
├── EF.CDF          — Certificate Directory (DER-encoded X.509)
├── EF.AODF         — Authentication Object Directory (PINs/biometric refs)
└── EF.DODF         — Data Object Directory (opaque data objects)

Each directory file is a BER-TLV encoded list of record templates pointing to the actual key or certificate file paths within the DF hierarchy.

Certificate Chain Storage

A smart card typically stores multiple X.509 certificates:

The full chain (intermediate + root CA certificates) may be stored on-card in separate DOs or retrieved via AIA (Authority Information Access) extension in the end-entity certificate.

PKCS#11 Software Interface

Applications communicate with smart card keys via PKCS#11 (Cryptoki) — a C API that abstracts the underlying hardware:

CK_SESSION_HANDLE hSession;
CK_OBJECT_HANDLE hKey;

C_OpenSession(slotID, CKF_SERIAL_SESSION | CKF_RW_SESSION,
              NULL_PTR, NULL_PTR, &hSession);
C_Login(hSession, CKU_USER, pin, pinLen);

// Sign data using on-card private key
C_SignInit(hSession, &mechanism, hKey);  // mechanism = CKM_ECDSA
C_Sign(hSession, data, dataLen, sig, &sigLen);

Middleware libraries like OpenSC (opensc-pkcs11.so), Feitian PKCS#11, and ActivClient implement the PKCS#11 interface on top of raw APDU exchanges. Use pkcs11-tool --list-slots to enumerate available tokens.

Key Usage Flags

PKCS#15 and X.509 both carry key usage constraints that the card enforces:

The smart card OS will refuse an operation (returning SW 69 82 = Security Status Not Satisfied) if the attempted use is not in the key's authorised usage set.

Security Considerations

• PIN caching: never cache PINs in software; always require fresh PIN entry per signing session
• Signature counting: use the signCount attribute in PKCS#15 for audit trails
• Key expiry: link certificate validity to key slot; retire and regenerate before expiry using slot 82–8C
• Revocation: CRL or OCSP check against issuing CA is mandatory for authentication use cases

For the file layout underlying PKCS#15, revisit ISO 7816 Parts Guide. For hardware-level key protection, see HSM Integration.