Blog

Hey there, fellow security engineer! Let’s unpack “PSO Compute Digital Signature” – this is one of those hidden gems in smart-card crypto that powers real-world identity and credential systems every single day. Think national eID cards, OpenPGP smart cards, YubiKeys in CCID mode, or any hardware token tied to an X.509 certificate. The private key (the one paired with your public-key certificate) never leaves the secure element. Instead, the card does the signing for you. It’s the hardware-backed version of “non-repudiation” in action – perfect for signing documents, authenticating to services, or proving you are who your certificate says you are.

Here’s how it actually works in practice. Your host application (browser, PDF signer, or custom client) first selects the right application on the card (via SELECT AID), sets up the security environment if needed (more on that in a sec), verifies the PIN that protects the signing key, and then fires off the PSO command with the data to sign. The card takes that input – usually just a hash or a pre-formatted DigestInfo – applies the algorithm internally using its private key (RSA or ECDSA), adds any required padding, and spits back the raw signature bytes. No private key exposure, ever. The corresponding certificate (which you can read separately via READ BINARY from the card) provides the public key for anyone to verify the signature later. This whole dance is defined in ISO/IEC 7816-8 and is the backbone of standards like eIDAS, Estonian eID, and OpenPGP smart-card apps.

To visualize the flow without any fluff, picture this simple sequence (host on the left, card on the right):

Host                                      Smart Card (secure element)
 |                                          |
 |--- SELECT AID (eID/OpenPGP app) -------->|
 |--- VERIFY PIN (PIN2 for signing) -------->|
 |--- (optional) MSE SET (pick key/alg) ---->|
 |--- PSO: COMPUTE DIGITAL SIGNATURE -------->|
 |<-- Signature bytes + 90 00 ---------------|

The card does all the crypto magic inside its tamper-resistant chip. For RSA (still common), you usually send a PKCS#1 DigestInfo structure; the card wraps it in the classic 00 01 [FF padding] 00 [DigestInfo] block and does the modular exponentiation. For ECDSA it’s even simpler – just the raw hash value (the card zero-pads if needed). Either way, the result is a signature you can attach to your document or use in TLS client auth.

Now for the real meat – the actual APDU command structure (this is what you send over the wire with a smart-card reader). The standard encoding used by pretty much every modern card (OpenPGP, many eID implementations) is:

• CLA: 00 (or 0C if you’re using secure messaging)
• INS: 2A
• P1: 9E
• P2: 9A
• Lc: length of the data you’re sending
• Data: your prepared input (DigestInfo for RSA, raw hash for ECDSA)
• Le: 00 (or the expected signature length)

Here’s a concrete, ready-to-use example for an RSA 2048-bit key with SHA-256 (the DigestInfo prefix is standard ASN.1). Let’s say your message hash is the 32-byte value BEE92930604C4533052389A321F206C5B11EF8D7CB2381F2B83BECFC40BA2570 (I just made up a plausible one for illustration – replace with real SHA-256 in code):

Full APDU in hex (you can copy-paste this into a reader tool like pcsc_scan or OpenSC):

00 2A 9E 9A 53
30 31 30 0D 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20
BEE92930604C4533052389A321F206C5B11EF8D7CB2381F2B83BECFC40BA2570
00

The card replies with the signature (256 bytes for RSA-2048) followed by 90 00 on success. Super clean, super secure.

Practical part – let’s make it fun and runnable

Grab a smart card reader + any OpenPGP-compatible card (Yubikey, Nitrokey, or even a cheap JavaCard you programmed yourself), install pyscard (pip install pyscard), and try this minimal Python snippet. It assumes you’ve already done SELECT, MSE, and VERIFY PIN earlier in your script (those are one-liners too – I can expand if you want). Run it and watch the card sign for real!

from smartcard.System import readers
from smartcard.util import toBytes, toHexString

# Connect to first reader (plug in your card!)
r = readers()[0]
conn = r.createConnection()
conn.connect()

# Example SHA-256 DigestInfo + fake hash (replace with real hash(bytes))
digest_info_prefix = toBytes("3031300d060960864801650304020105000420")
message_hash = toBytes("BEE92930604C4533052389A321F206C5B11EF8D7CB2381F2B83BECFC40BA2570")  # your real SHA-256 here
data = digest_info_prefix + message_hash

# The magic PSO APDU
apdu = [0x00, 0x2A, 0x9E, 0x9A, len(data)] + data + [0x00]

response, sw1, sw2 = conn.transmit(apdu)
print("✅ Signature computed by the card:")
print(toHexString(response))
print(f"Status: {sw1:02X}{sw2:02X} (9000 = success!)")

conn.disconnect()

Drop this into a file, run it after the setup steps, and you’ll literally see the bytes come back from your hardware. It’s addictive – I still get a kick every time I watch a card sign without ever leaking the key. Pro tip: wrap it in a loop and benchmark how fast your card is (most do RSA-2048 in <100 ms).

This command sits right at the intersection of certificates, identity, and hardware security – every time you use a smart-card cert in Windows CNG, PKCS#11, or OpenSC, this is the APDU being sent under the hood. It directly builds on the credential systems we’ve been exploring: your X.509 cert on the card points to the key reference, the PIN protects access, and PSO is the actual signing engine.

Want to level up in the next 10 minutes? We can look at the MSE SET command (how you tell the card “use the key from this exact certificate”) or on-card hashing with PSO HASH for huge documents. Or compare RSA vs ECDSA signature formats side-by-side with real card output. Or even capture live APDUs from a real eID session using OpenSC trace. What sparks your curiosity most today? Let’s keep building this knowledge brick by brick! 🚀

part2:

YubiKey in CCID mode turns your YubiKey into a full smart-card emulator (Chip Card Interface Device). Plug it in, and tools like OpenSC, PKCS#11 or Windows CNG see it exactly like a traditional contact smart card. You can now run the same PSO: COMPUTE DIGITAL SIGNATURE APDUs we talked about yesterday – perfect bridge between modern USB keys and classic certificate credentials.

Non-repudiation is the legal/technical guarantee that the signer cannot later claim “I didn’t sign that”. Only the private key inside the secure chip can produce a valid signature (protected by PIN), so when you verify it with the matching public key from the X.509 cert, the proof is cryptographically binding. This is why governments and banks love hardware tokens for e-signatures.

DigestInfo (only for RSA PKCS#1 v1.5) is a tiny ASN.1 wrapper the card expects before signing:

30 31 30 0D 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 [32-byte SHA-256]

It tells the card “this hash was made with SHA-256”. The card then adds the PKCS#1 padding and signs the whole block. ECDSA cards skip this and just want the raw hash.

Why sign only a digest (DigestInfo or raw hash) instead of the real data?
Real documents are huge (MBs). RSA/EC math on 1 MB would be painfully slow and produce gigantic signatures. So we use a one-way collision-resistant hash (SHA-256 etc.) first – 32 bytes – and sign that. The signature proves the hash matches the original data. If even one bit of the document changes, the hash changes, the signature fails verification. That’s exactly what you do every time you sign a PDF or use client-cert TLS: your app computes the hash, sends it to the card via PSO, and gets back the signature in <100 ms.

Quick 10-second practical you can run right now (Python, no card needed):

from hashlib import sha256
data = b"My super secret contract text 2026"
digest = sha256(data).digest()
print(digest.hex())  # <-- this 32-byte value is what you actually send to PSO

See? You never send the real data to the card – only the digest. The card signs it securely, you attach the signature + your X.509 cert, and anyone can verify later.

That’s the complete picture in <2 minutes. Want the next 10-minute deep-dive on MSE SET (how you pick which key the card should use) or a live OpenSC trace of a real YubiKey signing session? Just say the word! 🚀

https://github.com/flowxcode/pySnips/commit/910e9f4741a1cd4d74ba561db7dbd7901c1f54ec

Hey there, security engineer! Today’s 10-minute power session is laser-focused on two concepts that sit right at the heart of every solid identity and credential system you’ll build or defend: MAC/HMAC (the tamper-evident seal on your messages/tokens) and key rolling (the smart way to change the locks without locking out your users). These two are best friends — you use an HMAC with a secret key to sign JWTs, API requests, or credential proofs, then you roll that key on a schedule so a breach doesn’t give attackers eternal access. Think of it as giving your digital vault a fresh set of keys every few months while keeping the old ones valid for a short “grace window” so nothing breaks.

Let’s start with the authentication side. A MAC (Message Authentication Code) is a short cryptographic tag you attach to any piece of data (a JWT payload, an API request body, a certificate serial number, whatever) so the receiver can prove two things: (1) the data hasn’t been tampered with in transit, and (2) it really came from someone who knows the shared secret. Without a MAC, an attacker could just change “role=admin” to “role=superadmin” and you’d never know.

The most popular, battle-tested version is HMAC (Hash-based Message Authentication Code). It’s defined in RFC 2104 and basically turns any cryptographic hash function (SHA-256, SHA-384, SHA-512) into a keyed authenticator. Here’s the magic in plain English: HMAC does two passes over the data using the secret key cleverly padded with special constants (ipad and opad). This double-XOR trick stops length-extension attacks that would otherwise let an attacker forge new messages once they see one valid tag. The result is a fixed-size tag (usually 256 or 512 bits) that looks completely random to anyone who doesn’t have the exact same secret key.

okta.com

abhaybhargav.medium.com

The flow is beautifully simple: sender and receiver both share the exact same secret key. Sender runs HMAC(key, message) → attaches the tag. Receiver runs the same HMAC(key, received_message) and checks if the tags match byte-for-byte. If they do → authentic + intact. If not → reject immediately. No decryption needed, which is why HMAC is fast and perfect for high-volume credential checks.

Here’s the practical part you love — copy-paste this into your terminal right now (Python 3, no extra installs):

Python

import hmac
import hashlib
import secrets

# Real-world secret (in production: load from env or HSM)
secret_key = b"super-secret-hmac-key-2026-for-credentials"  # 32+ bytes is good

# Example credential data you'd sign (like a JWT payload)
credential = b"user_id=98765&role=admin&exp=1740500000&iss=my-identity-service"

# Compute the HMAC tag (this is what you'd put in a JWT signature or API header)
tag = hmac.new(secret_key, credential, hashlib.sha256).hexdigest()
print(f"HMAC-SHA256 tag: {tag}")

# Verification on the receiving side
def verify_hmac(key, data, received_tag):
    expected = hmac.new(key, data, hashlib.sha256).hexdigest()
    return hmac.compare_digest(expected, received_tag)  # timing-safe!

if verify_hmac(secret_key, credential, tag):
    print("✅ Credential is authentic and untampered!")
else:
    print("❌ Something fishy!")

Run it, then change one character in credential (try making the role “superadmin”) and watch the verification instantly fail. That’s the power in action. Want to play more? Replace hashlib.sha256 with sha384 or sha512 — same API, different security level.

The Web Crypto API (the full name for window.crypto.subtle) is a W3C standard that has been built into browsers for years precisely because cryptography needs to be consistent and native across the web. Developers kept building their own crypto libraries in pure JavaScript before this (often with bugs or side-channel leaks), so the browsers agreed on one low-level API everyone implements. P-256 (also called secp256r1 or prime256v1) is one of only three elliptic curves officially required by the spec — the others are P-384 and P-521 — so every browser that supports ECDSA at all must support P-256. You can rely on it the same way you rely on fetch() or JSON.parse(): it’s there, it’s fast (uses hardware acceleration where possible), and it’s secure by design because the private key never leaves the browser’s secure context. That’s why we can use it in your Aliro playground without any libraries or polyfills — open the HTML file and it just works.

https://crypto.stackexchange.com/questions/73069/how-does-ecdsa-signature-verify-work-in-eos-and-eth-btc-compare-to-standard-on

Copyright STMicroselectronics

from ecdsa import SigningKey, VerifyingKey, NIST256p
from ecdsa.util import sigencode_der, sigdecode_der
from cryptography.hazmat.primitives import hashes, hmac
from cryptography.hazmat.primitives.kdf.hkdf import HKDF
from cryptography.hazmat.primitives.asymmetric import ec
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os, binascii

# Generate ephemerals (asymm)
reader_priv = ec.generate_private_key(ec.SECP256R1())
reader_pub = reader_priv.public_key().public_bytes(encoding=ec.Encoding.X962, format=ec.PublicFormat.UncompressedPoint)
device_priv = ec.generate_private_key(ec.SECP256R1())
device_pub = device_priv.public_key().public_bytes(encoding=ec.Encoding.X962, format=ec.PublicFormat.UncompressedPoint)

# Fake T (transaction data concat)
T = reader_pub + device_pub + os.urandom(8) + os.urandom(32) + b'fakeFCI'  # In real: from APDUs
hash_T = hashes.Hash(hashes.SHA256()).update(T).finalize()

# Reader signs (asymm ECDSA)
reader_long_priv = SigningKey.generate(curve=NIST256p)
reader_sig = reader_long_priv.sign(hash_T, hashfunc=hashes.SHA256, sigencode=sigencode_der)

# Device verifies, derives Z/SK (asymm ECDH to symm HKDF)
reader_long_pub = reader_long_priv.verifying_key
if reader_long_pub.verify(reader_sig, hash_T, hashfunc=hashes.SHA256, sigdecode=sigdecode_der):
    Z = device_priv.exchange(ec.ECDH(), reader_priv.public_key())
    hkdf = HKDF(algorithm=hashes.SHA256(), length=32, salt=None, info=b'AliroSecureChannel')
    SK = hkdf.derive(Z)
    print("Derived SK (symm key):", binascii.hexlify(SK).decode())

    # Device response payload (TLV), encrypt with symm AES-GCM
    payload = b'\x9E' + len(reader_sig).to_bytes(1, 'big') + reader_sig  # Fake minimal: just sig
    nonce = hash_T[:12]
    aes = AESGCM(SK)
    encrypted = aes.encrypt(nonce, payload, b'AliroAuth1')
    print("Encrypted response (over NFC):", binascii.hexlify(encrypted).decode())
else:
    print("Sig verify failed")

Here’s a minimal JavaScript snippet you can drop into a test page (or try live at webauthn.io) to register a credential – exactly what your company’s web apps would call:

JavaScript

navigator.credentials.create({
  publicKey: {
    challenge: new Uint8Array(32), // random server challenge
    rp: { name: "MyCorp", id: "mycorp.com" },
    user: { id: new Uint8Array(16), name: "user@example.com", displayName: "Jane Doe" },
    pubKeyCredParams: [{ alg: -7, type: "public-key" }], // ES256
    authenticatorSelection: { userVerification: "preferred" },
    attestation: "direct"
  }
}).then(cred => {
  console.log("Public key registered:", cred.id);
  // send cred.response.attestationObject + clientDataJSON to your backend
}).catch(err => console.error(err));

On the backend you would verify the attestation certificate chain and store the public key – classic PKI flow you already know.

For Aliro, the practical view is lower-level because it’s an NFC/BLE protocol (APDUs), but the research repo at github.com/kormax/aliro shows the exact commands you would see when implementing a reader or wallet integration. The most certificate-focused one is LOAD CERTIFICATE:

apdu

CLA=80 INS=D1 P1=00 P2=00 Data = <compressed ASN.1 certificate>

The certificate itself is a compressed TLV structure you decompress to standard X.509 DER fields: profile marker, serial, issuer, validity dates, subject, public key (EC point), and signature. You validate it against your stored reader-group root key exactly the way you validate any enterprise cert today. After that comes AUTH1 for mutual signing, then EXCHANGE over the secure channel. Compare this to FIDO2: both use ECDSA signatures and certificate chains, but Aliro adds the offline “mailbox” and precise UWB ranging for physical security.

You can play with FIDO2 today on your own laptop in under two minutes. For Aliro, watch for the first production smart-lock firmware updates from Nordic/Qorvo or Kastle Systems – their reference designs are already shipping with the protocol. Next time we can zoom into provisioning flows or revocation lists and connect them to the exact certificate fields

The, provisioning, attestation, revocation, and interoperability of devices are core components of a secure, lifecycle-managed ecosystem, particularly within Internet of Things (IoT) and Trusted Execution Environments (TEE). These processes ensure that devices are genuine, configured correctly, and can be securely decommissioned while adhering to standardized, cross-platform protocols. FIDO Alliance +4

1. Provisioning
Provisioning is the process of securely introducing a device into an ecosystem, often involving the injection of cryptographic keys, identities, and initial configurations at the time of manufacturing or during first-time setup. Android Open Source Project +4

• Remote Key Provisioning: Modern systems like Android 12+ use remote provisioning to supply devices with unique attestation certificates, which are shorter-lived and more secure than factory-provisioned certificates.
• IoT Provisioning: Services like Azure IoT Device Provisioning Service (DPS) use Registration IDs and Endorsement Keys (EK) to automatically enroll devices at scale.
• Secure Credential Loading: Securely provisioning symmetric keys or certificates ensures that only authorized devices can access services. Android Open Source Project +4

2. Attestation
Attestation is the method for confirming a device’s identity and integrity, verifying that the hardware, firmware, and software have not been compromised. Approov

• Methods: Common forms include X.509 certificates (based on public key infrastructure) and TPM (Trusted Platform Module) based on nonce challenges.
• Remote Attestation: This process allows a verifier (e.g., a cloud service) to confirm that a device is running genuine software in a secure state.
• FIDO Attestation: Used in authentication to prove that a cryptographic key was generated within trusted hardware.
• Evidence Generation: Devices, such as those using TEEs, generate signed reports (evidence) that are sent to a verifier for validation. Gramine docs +4

3. Revocation
Revocation is the process of invalidating a device’s, user’s, or application’s credentials to prevent them from accessing services, often following a security compromise or the end of the device’s lifecycle. EU Digital Strategy +4

• Mechanisms: Revocation can be handled via Certificate Revocation Lists (CRLs) or by deleting individual enrollment entries in a provisioning service.
• Suspension vs. Revocation: In identity ecosystems (like the EUDI Wallet), certificates or tokens can be suspended or permanently revoked.
• Timing: Revocation must occur immediately if a device is deemed untrustworthy to protect the overall system. GitHub +4

4. Interoperability
Interoperability ensures that devices and services from different vendors can communicate and trust each other through shared standards and protocols. YouTube +4

• Standards Bodies: Organizations like the Trusted Computing Group (TCG) and IETF (via RATS working group) define standards for attestation data models and formats to ensure compatibility across heterogeneous systems.
• Common Formats: The use of COSE (CBOR Object Signing and Encryption) and EAT (Entity Attestation Tokens) helps different vendors create interoperable, machine-readable evidence.
• Ecosystem Standards: Initiatives such as the European Digital Identity (EUDI) Wallet use frameworks to manage, share, and verify credentials across borders.
• Protocol-Aware Interoperability: Using standard protocols like RESTful APIs ensures that different software ecosystems can interact securely.

https://github.com/flowxcode/pySnips/blob/main/crcplay2.py

When you feed them Data + stored_CRC and expect zero, you will usually get a non-zero constant instead—something like 0x2144DF1C for standard CRC-32
 
seriously??

Yes, seriously — and this is one of those “aha” moments that saves you weeks of debugging later in credential systems.

The reason you almost never get exactly zero when you do the “append-and-check-zero” on real CRC-32 code is hidden in two small but crucial details that every standard library and every smart-card hardware block adds on purpose.

Most CRC-32 implementations you will actually use (zlib in Python, the CRC peripheral on NXP P71, ST33, Infineon SLE97, the software routines in GlobalPlatform libraries, even the one in your favourite embedded C toolchain) do the following:

• They start the shift register with 0xFFFFFFFF (all bits set).
• After they have processed every byte of the input, they XOR the final register value with 0xFFFFFFFF again before returning the result to you.

These two steps (initial value + final XOR) are not part of the pure mathematical polynomial division. They were added decades ago to dramatically improve error detection — especially for leading and trailing zero bytes, which are very common in certificates, key blobs, and TLV structures. The side effect is that the nice “whole block divides to remainder zero” property you learned in networking class no longer holds when you use the same function on Data + stored_CRC.

Instead, when the data is correct, feeding Data + stored_CRC back into the exact same function always produces one fixed magic constant.

For the standard IEEE CRC-32 that zlib.crc32 implements (the one you will meet in 90 % of credential work), that constant is exactly 0x2144DF1C when the stored CRC is appended in little-endian byte order — which is the order almost every embedded system uses.

In ISO/IEC 7816-4, the core standard for smart card commands and file organization, the SELECT command (INS code A4) is how a terminal or reader chooses which application (called a Dedicated File or DF) or data file (Elementary File or EF) becomes the current one on the card. Everything else the card does afterward—reading data, authenticating, running transactions—happens in the context of whatever was last selected. Think of it as navigating a file system: you have to “cd” into a directory before you can work with the files inside it.

The command works by sending an APDU with specific parameters. P1 tells the card how to interpret the identifier you’re providing (e.g., P1 = 00 for short file ID, P1 = 04 for selection by DF name, which is the AID). P2 controls details like whether this is the first selection, the next one in a series, and what information the card should return (FCI template, FCP, etc.).

When selecting an application by AID (the usual way for multi-application cards), the standard supports two important variations that tie into your second question about privacy.

Full AID selection requires sending the complete Application Identifier (5–16 bytes). The card matches it exactly. This is straightforward, but in contactless environments it can be a privacy risk because anyone eavesdropping on the radio communication sees the exact AID, which often reveals the issuer, card type, or even specific product—information that could be used to track or profile the cardholder.

Partial AID selection lets the terminal send only a prefix of the AID (truncated from the right). The card then selects the DF whose name has the longest match starting from the left. You use P2 = 00 for the first/only occurrence and P2 = 02 for the next matching one if several DFs share the same prefix. This is why the standard mentions “preferably complete” for the first command but allows the same (possibly shorter) data field on subsequent ones.

Partial selection gives some privacy because the terminal doesn’t have to transmit sensitive proprietary parts of the AID (the PIX bytes after the registered RID). It only sends the common prefix, making it harder for a passive listener to fingerprint the exact application.

Even better privacy comes from indirect selection through a directory file. ISO 7816-4 supports an optional EF.DIR (or information in historical bytes/ATR) that lists available applications. In practice, payment standards like EMV built on this idea with the fixed-name PPSE (‘2PAY.SYS.DDF01’). The terminal always selects this same well-known name first—no card-specific AID is sent over the air. The card responds with a list of supported payment applications (their full AIDs and priorities), and only then does the terminal explicitly select the desired one. This is often referred to in industry discussions as “selection with privacy” because the initial discovery step reveals nothing about which applications are actually present or chosen.

Practical example you can try yourself

If you have a smart card reader and a test card (or emulator), here is the APDU for selecting the PPSE—this is the privacy-friendly first step in every contactless payment:

Command APDU (hex):
00 A4 04 00 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00
(That’s CLA=00, INS=A4, P1=04, P2=00, Lc=0E, data=”2PAY.SYS.DDF01″)

A typical response from a payment card starts with 6F (FCI template) and contains a list of supported AIDs inside BER-TLV tags.

For partial selection, imagine two applications sharing the same RID A000000004 (Mastercard). You could send a short prefix like A000000004 and get the first matching one, then use P2=02 to get the next.

A very short Python snippet using pcsc (pyscard library) to send that PPSE select:

from smartcard.System import readers
from smartcard.util import toHexString, toBytes

r = readers()[0]
connection = r.createConnection()
connection.connect()

SELECT_PPSE = [0x00, 0xA4, 0x04, 0x00, 0x0E, 0x32, 0x50, 0x41, 0x59, 0x2E, 0x53, 0x59, 0x53, 0x2E, 0x44, 0x44, 0x46, 0x30, 0x31, 0x00]

data, sw1, sw2 = connection.transmit(SELECT_PPSE)
print("Response:", toHexString(data), "SW:", hex(sw1), hex(sw2))

Run this on a contact or contactless reader with a payment card inserted, and you’ll see the directory response—this is exactly how real terminals discover applications without compromising privacy.

In the world of smart cards, which power everything from eID credentials to payment systems in your daily software engineering tasks, data transmission isn’t always straightforward. Often, the information you need to send or receive—like a lengthy digital certificate or a chain of identity verifications—exceeds the limits of a single message. This is where chaining comes into play, allowing large payloads to be broken down and reassembled seamlessly. As someone working on credential systems, understanding chaining helps debug those pesky buffer overflows or intermittent read failures during integration testing. We’ll explore APDU-level chaining from ISO 7816 and low-level chaining tied to protocols like ISO 14443, focusing on how frames and bytes fit together to make it all work.

Let’s start with the basics of why chaining exists. Smart cards operate in constrained environments: limited buffer sizes, typically around 255 bytes for older systems, mean you can’t just dump a 1KB certificate in one go. Chaining solves this by splitting data into manageable chunks while ensuring the card processes the command only once everything arrives intact. This maintains atomicity—your update either fully succeeds or doesn’t happen at all, which is crucial for secure credential storage.

APDU-Level Chaining: Handling Logical Data in ISO 7816

APDU, or Application Protocol Data Unit, is the high-level language you use in your code to talk to the card. Defined in ISO 7816-4, it’s essentially a command-response pair: you send a header with class (CLA), instruction (INS), parameters (P1/P2), length (Lc for outgoing data, Le for expected response), and the data itself. But when data overflows that ~255-byte limit (or up to 64KB in extended mode), APDU chaining kicks in.

For sending large commands from the reader to the card—say, writing a big X.509 certificate—you flag the CLA byte to indicate “more to come.” Specifically, bit 4 (0x10 in hex) is set in the CLA for all but the last APDU. Your code would OR this with the standard CLA (like 0x00 becoming 0x10 for chained parts). Each chained APDU keeps the same INS, P1, and P2, but appends the next data slice, with Lc showing the chunk’s length. The card buffers these until the final unchained APDU arrives, then executes the full operation. It acknowledges intermediates with a status word like 0x9000, signaling “good, send more.”

On the response side, things vary by protocol. In the byte-oriented T=0 (common in older contact cards), if the card has more data than requested, it returns 0x61xx (xx being remaining bytes), prompting your software to issue a GET RESPONSE (0x00 0xC0 0x00 0x00 Le) to fetch the next piece. Modern block-oriented protocols handle this more fluidly, but the principle is the same: chaining ensures complete data transfer without truncation.

Imagine updating a credential file with 300 bytes. Your first APDU might be: 0x10 0xD6 0x00 0x00 0xFF [255 bytes data]. The card responds 0x9000. Then the last: 0x00 0xD6 0x00 0x00 0x2D [45 bytes], and boom—full write complete. In your Java or Python scripts using libraries like javax.smartcardio or pyscard, you’d implement a loop to send these chained commands, checking statuses along the way. This ties directly into credential systems, where loading large keys or certs without chaining could fail on buffer limits.

To visualize this, here’s a diagram illustrating APDU chaining structures in ISO 7816:

community.nxp.com

MRFC630] Can’t response from APDU command – NXP Community

This shows how commands and responses break into frames, with headers and data fields linking via chaining flags.

Low-Level Chaining: The Transport Layer in ISO 7816 and 14443

Beneath the APDU sits the transport protocol, where low-level chaining handles the physical movement of those APDUs over the wire or air. For contact cards, ISO 7816-3 defines T=1, a block-oriented mode using I-blocks (information), R-blocks (acknowledgments), and S-blocks (supervisory). Each block has a prologue: Node Address (NAD), Protocol Control Byte (PCB), and Length (LEN), followed by the info field (your APDU bytes) and a checksum (EDC).

The PCB is key here—bit 5 (0x20) signals chaining: set for “more blocks follow,” cleared for the last. Your reader sends chained I-blocks until done, with the card ACKing via R-blocks. This is transparent in most APIs, but if you’re sniffing with a logic analyzer, you’ll see multiple blocks wrapping one large APDU. It’s what enables extended APDUs without high-level chaining.

Shifting to contactless, ISO 14443-4 mirrors this for NFC-based credentials like passports. It’s half-duplex, with frames starting with Start of Frame (SOF), then PCB (similar chaining bit: bit 6 for continuation), optional Card Identifier (CID), the info (APDU payload), Error Detection Code (EDC), and End of Frame (EOF). Chaining here ensures reliable transmission over RF, where noise could corrupt large frames. For instance, during ePassport authentication, a long response might span several chained blocks, each ACKed before the next.

The beauty is how low-level chaining supports the APDU layer: even if you avoid high-level chaining with extended lengths, the transport still chains blocks under the hood for buffers under 255 bytes. In practice, this explains slower contactless reads—more frames mean more back-and-forth.

Practical Insights for Credential Systems Engineers

Tying it back to your work, chaining issues often surface in integration: a failed certificate load might stem from missing chaining support in your reader driver. To experiment, grab a test smart card and tools like pcsc-tools or a NFC reader app. Send a chained UPDATE BINARY as above, then check the ATR (Answer To Reset) for protocol support—T=1 indicates low-level chaining capability.

For a real-world peek, consider an eID card’s certificate read: use OpenSC or similar to trace APDUs, spotting chained GET DATA commands for large blobs. Compare fields: a chained CLA (0x10) vs. standard (0x00) highlights where splitting occurs. If you’re coding, here’s a quick Python snippet using pyscard to send a chained command:

Python

from smartcard.System import readers
from smartcard.util import toHexString

r = readers()[0]
conn = r.createConnection()
conn.connect()

# Chained APDU example: first part
apdu = [0x10, 0xD6, 0x00, 0x00, 0xFF] + [0x00] * 255  # Dummy data
data, sw1, sw2 = conn.transmit(apdu)
print(f"Status: {toHexString([sw1, sw2])}")

# Last part
apdu = [0x00, 0xD6, 0x00, 0x00, 0x05] + [0x01, 0x02, 0x03, 0x04, 0x05]
data, sw1, sw2 = conn.transmit(apdu)
print(f"Final Status: {toHexString([sw1, sw2])}")

Run this on a writable test card to see chaining in action—adjust for your credential files. Over time, connecting these dots with prior topics like certificate structures will sharpen your debugging in identity systems.

Perfect Forward Secrecy (PFS) is a property of cryptographic key exchange protocols that ensures past session keys remain secure even if the long-term private keys (the ones tied to identities, like a server’s certificate private key) are later compromised.

To understand why this matters, think about how encrypted communication usually works. In a typical secure session (like TLS for HTTPS), two parties first agree on a shared session key, then use that key to encrypt the actual data. If the protocol lacks PFS, the session key is derived in a way that depends directly on the long-term private key. An attacker who later steals that long-term private key (for example, by hacking the server years later) can retroactively compute every past session key and decrypt all previously recorded traffic. This is a serious problem for long-term confidentiality—think of sensitive credential exchanges, authentication sessions, or any data you want to stay private forever.

PFS prevents exactly this scenario. It achieves this by using ephemeral (temporary, one-time) keys during each key exchange. The most common way is through Ephemeral Diffie-Hellman (DHE or ECDHE). Both parties generate fresh key pairs just for this session, perform the Diffie-Hellman computation to arrive at a shared secret, and then immediately discard the ephemeral private keys. The final session key is derived from that shared secret (often combined with other data via a key derivation function). Because the ephemeral private keys are gone after the handshake, even a complete compromise of the long-term keys later reveals nothing useful about past shared secrets—there’s no way to recompute them without those discarded ephemeral values.

Now, the warning about EC public key validation is directly tied to preserving PFS. When using Elliptic Curve Diffie-Hellman Ephemeral (ECDHE), each side sends an ephemeral public key to the other. If the receiver does not rigorously validate that public key—checking that the point is actually on the correct curve, has the right order, isn’t the point at infinity, etc.—an attacker can send a maliciously crafted “public key” that forces the honest party’s private key to operate in a small subgroup or on a weak curve. Over multiple such malicious handshakes, the attacker can gradually learn bits of the honest party’s ephemeral private key (small subgroup attacks) or even the long-term private key in some cases. If the ephemeral private key material leaks, PFS is broken for that session; if the long-term key leaks, it’s catastrophically broken for everything. Standards like SEC1 (section 3.2.2) and NIST SP 800-186 (Appendix D.1.1) spell out the exact checks required: coordinate validity, cofactor checks, subgroup order checks, and so on. In production code for credential or identity systems, skipping these checks is a common class of vulnerability that directly undermines the PFS guarantee you’re relying on.

Practical example to see it in action

A very simple way to observe PFS in the real world is to look at a TLS handshake with a cipher suite that uses ECDHE.

You can test this yourself with OpenSSL (widely available on any developer machine):

# Connect to a site that supports modern TLS (most do in 2026)
openssl s_client -connect google.com:443 -tls1_3 -msg

# Or for TLS 1.2 with explicit ECDHE:
openssl s_client -connect google.com:443 -cipher ECDHE-RSA-AES256-GCM-SHA384 -msg

In the output, look for lines like:

--- 
Server Temp Key: ECDH, P-256, 256 bits
---

The phrase “Temp Key” or “Ephemeral” indicates ephemeral keys were used, which provides PFS. If you instead force a non-PFS cipher (rarely supported now), you might see static RSA key transport with no temporary key.

For a tiny code glimpse of the core idea (pure Python, using only the standard library and ecdsa which you likely have access to in many environments), here’s a minimal illustration of how ephemeral keys create a shared secret that cannot be recomputed later:

from ecdsa import ellipticcurve as ec, curves, numbertheory
import secrets

# Curve: NIST P-256 (common in TLS)
curve = curves.NIST256p.curve
generator = curves.NIST256p.generator

# Alice generates ephemeral key pair
alice_private = secrets.randbelow(curve.order)          # ephemeral private
alice_public = alice_private * generator                # ephemeral public

# Bob generates ephemeral key pair
bob_private = secrets.randbelow(curve.order)
bob_public = bob_private * generator

# Exchange publics (sent over network)
# Shared secret computation (same on both sides)
alice_shared = alice_private * bob_public
bob_shared = bob_private * alice_public

assert alice_shared == bob_shared
print("Shared secret x-coordinate:", alice_shared.x())

# After session: discard ephemeral privates!
del alice_private, bob_private

# Later, even if long-term keys are stolen, no one can recompute this shared secret

Run this twice—you’ll get completely different shared secrets each time, even on the same curve. The long-term identity keys would only sign or authenticate the publics, never directly contribute to the shared value. This is the essence of how PFS protects each session independently. In your credential systems work, whenever you implement or review an AKE that claims PFS, always verify that ephemeral EC keys are fully validated before use.

The misunderstanding from before makes sense now—sorry for jumping to Google Analytics cookies; the “GA” prefix there was a red herring. What you’re referring to with GA1 and GA2 is almost certainly the General Authenticate command (APDU instruction code usually 0x86 or sometimes 0x87 depending on the profile) in smart card systems based on ISO/IEC 7816-4 and extensions like ISO 7816-8.

Your system being similar to ISO 7816-4 means it uses the standard command-response structure: the terminal sends a Command APDU (C-APDU) with CLA, INS, P1, P2, optional data field, and Le; the card processes it and returns a Response APDU (R-APDU) with optional response data and a two-byte status word (SW1-SW2, like 9000 for success).

The General Authenticate command is one of the most flexible and powerful security commands in the standard. Instead of fixed older commands like Internal Authenticate (0x88) or External Authenticate (0x82), which handle simple challenge-response in one shot, General Authenticate is designed for dynamic, multi-step cryptographic protocols. It carries a “dynamic authentication template” (tag 0x7C) that contains nested BER-TLV objects specifying exactly what operation to perform—sending a nonce, performing key agreement, computing a signature, verifying a challenge, etc. This makes it ideal for modern protocols that need several back-and-forth exchanges to establish strong security.

In identity and credential systems (especially European eID cards, ePassports with PACE, or similar custom secure element designs), the most common reason you’ll see multiple General Authenticate commands—often labeled GA1, GA2, GA3, GA4 in specifications and test suites—is the PACE protocol (Password Authenticated Connection Establishment). PACE securely establishes a high-entropy session key from a low-entropy shared secret (like a PIN, CAN, or MRZ data) while resisting offline attacks.

Why both (or more than one)? A single APDU exchange can’t provide the necessary security guarantees for password-based key exchange. You need interactive steps to:

• Decrypt and map a nonce to a new generator (prevents precomputation attacks on the password).
• Exchange ephemeral public keys for Diffie-Hellman or ECDH key agreement.
• Prove possession of the derived key mutually.

Each step builds on the previous one, and the card enforces the correct sequence. If any step fails or is out of order, the protocol aborts. This chaining is why you’ll see GA1 and GA2 (and usually more): GA1 typically handles the encrypted/mapped nonce, GA2 starts the ephemeral key exchange, and so on. The BSI TR-03110 and TR-03105 test specifications explicitly refer to “GA step 1”, “GA step 2”, etc., and many implementations shorthand them as GA1/GA2/GA3/GA4.

In your credential system, you’re likely implementing something very close to this—perhaps a custom variant of PACE or another multi-step mutual authentication—to protect certificate access or signing operations.

Practical Example: Constructing a Simple General Authenticate APDU

Here’s a concrete example from public PACE implementations (simplified for the “Map Nonce” step, often GA2). The terminal sends its mapping public key to the card and receives the card’s mapping public key in return.

Command APDU (hex):

10 86 00 00 2B 7C 29 83 26 04 41 ... [41 bytes compressed point] 00

• 10: CLA (command chaining—more data may follow if needed)
• 86: INS (General Authenticate)
• 00 00: P1 P2 (usually 00 00 for PACE steps)
• 2B: Lc (length of data field)
• 7C 29: Dynamic authentication template (tag 7C, length 41 bytes)
• 83 26: Ephemeral public key from terminal (tag 83, length 38 bytes; for EC point)
• 04 41 ...: The actual compressed public key bytes
• 00: Le (expect full response, card decides length)

Expected Response APDU (simplified):

7C 28 83 26 04 79 ... [card's public key] 90 00

• 7C 28: Response template with card’s mapping public key (tag 83 again)
• 90 00: Success

You can test this kind of flow with open-source libraries like JMRTD (Java) or OpenPACE (C). A very short Python snippet using pyscard to send a raw General Authenticate (you’d need a connected reader and card that supports it):

from smartcard.System import readers
from smartcard.util import toHexString, toBytes

# Assume reader[0] is your card reader
r = readers()[0]
connection = r.createConnection()
connection.connect()

# Example GA command bytes (replace with real data for your step)
cmd = [0x10, 0x86, 0x00, 0x00, 0x2B, 0x7C, 0x29, 0x83, 0x26] + [your_38_byte_pubkey_list] + [0x00]

data, sw1, sw2 = connection.transmit(cmd)
print("Response:", toHexString(data), f"SW: {sw1:02X} {sw2:02X}")

Run this sequence multiple times with the evolving data objects for each GA step, and you’ll see exactly why multiple commands are required—the card holds state between them and derives stronger keys progressively. If your system deviates from standard PACE, the principle remains the same: use General Authenticate’s templating to build secure multi-step authentication flows. Let me know the exact P1/P2 or tags you’re seeing, and we can dig into your specific variant next!

BER-TLV encoding is a fundamental way to serialize structured data into bytes, especially in systems dealing with digital certificates, smart cards, and identity credentials. It comes from ASN.1 (Abstract Syntax Notation One), which defines data types abstractly — things like integers, strings, sequences, or sets — without tying them to a specific programming language or platform. To actually transmit or store that data, you need concrete encoding rules, and Basic Encoding Rules (BER) is the original, most flexible set of those rules. The “TLV” part describes the core pattern: every piece of data is broken into a Tag (what it is), a Length (how big the content is), and a Value (the content itself). This pattern repeats recursively, so complex nested structures naturally emerge.

The beauty of TLV is that it is self-describing. When you receive a byte stream, you read the tag to know the type, read the length to know where it ends, extract the value, and move on to the next TLV. Constructed types (like a SEQUENCE) have a value that is simply a concatenation of more TLV elements inside it. This makes parsing straightforward, though BER allows some ambiguity — the same logical data can have multiple valid byte representations (different padding, longer length forms, etc.).

How the parts work in practice:

The Tag occupies one or more bytes. The first byte splits into:

• Bits 8–7 for the class (universal, application, context-specific, or private).
• Bit 6 to indicate primitive (0) or constructed (1).
• Bits 5–1 for the tag number. If those bits are all 1s (31 decimal), the tag continues into additional bytes.

The Length can be definite (most common) or indefinite. For definite:

• If the first byte is < 128, it’s the short form — the length is that byte value directly.
• If the first byte has bit 8 set, it’s the long form — the lower 7 bits tell how many following bytes encode the actual length as a big-endian integer.

Indefinite length uses 0x80 and ends with a special End-of-Contents marker (00 00).

The Value is exactly “length” bytes (or everything until EOC for indefinite). For primitive types it’s the raw data; for constructed it’s more TLVs.

These diagrams illustrate the length field rules clearly — one general BER, one from the EMV specification (which uses BER-TLV heavily for payment card data).

Other Variants

Other encoding rules build on or restrict BER to solve specific problems:

• DER (Distinguished Encoding Rules) — A strict subset of BER. It eliminates ambiguity by enforcing the shortest possible forms (no leading zeros in integers, minimal length encoding, definite lengths only, sorted SET elements, specific BIT STRING padding). This canonical form is critical wherever signatures are involved, because the bytes being signed must be identical across implementations. Almost all X.509 certificates, CMS/PKCS#7 structures, and modern PKI credential systems use DER.
• CER (Canonical Encoding Rules) — Similar to DER but permits indefinite lengths for very large values (e.g., huge certificates or streaming scenarios). Rarely seen today outside legacy systems.
• PER (Packed Encoding Rules) — Focuses on compactness. It removes many tags when the schema is known, packs bits tightly (aligned or unaligned variants), and is much smaller than BER/DER. Used in bandwidth-constrained telecom protocols (e.g., LTE/5G signaling).
• OER (Octet Encoding Rules) — Modern, efficient, designed for automotive and IoT. Fixed octet alignment, minimal overhead.
• JER (JSON Encoding Rules) — Encodes ASN.1 as JSON, useful for web-based credential systems.

In your domain, you’ll encounter BER-TLV most often in smart-card applets (ISO 7816, EMV contactless payments) and DER in traditional PKI certificates.

Practical Part

Let’s look at a tiny real-world-style example you can try yourself.

Consider the ASN.1 structure:

MyData ::= SEQUENCE {
version INTEGER,
name OCTET STRING
}

With values version = 1, name = “Alice”.

In DER (what a real certificate would use):

Hex: 30 0A 02 01 01 04 05 41 6C 69 63 65

Breakdown:

• 30 = tag for SEQUENCE (universal constructed 16)
• 0A = length 10 bytes
• 02 01 01 = INTEGER 1 (tag 02, length 1, value 01)
• 04 05 41 6C 69 63 65 = OCTET STRING “Alice”

Here’s a minimal Python function to parse simple definite-length single-byte-tag TLVs (good starting point you can extend for multi-byte tags or indefinite):

def parse_tlv(data: bytes):
    pos = 0
    while pos < len(data):
        tag = data[pos]
        pos += 1

        # Length
        if data[pos] & 0x80:  # long form
            len_len = data[pos] & 0x7F
            pos += 1
            length = int.from_bytes(data[pos:pos + len_len], 'big')
            pos += len_len
        else:  # short form
            length = data[pos]
            pos += 1

        value = data[pos:pos + length]
        pos += length

        print(f"Tag: 0x{tag:02X}, Length: {length}, Value: {value.hex()}")

Run it on the example above:

data = bytes.fromhex("300A0201010405416C696365")
parse_tlv(data)

Output:

Tag: 0x30, Length: 10, Value: 0201010405416c696365
Tag: 0x02, Length: 1, Value: 01
Tag: 0x04, Length: 5, Value: 416c696365

The outer value contains the inner TLVs — you can recurse to handle constructed types.

For a real certificate: grab any .pem file (e.g., curl https://www.google.com > google.html, then extract the cert with openssl s_client -connect www.google.com:443 -showcerts), save the —–BEGIN CERTIFICATE—– block as cert.pem, then run:

openssl asn1parse -inform pem -in cert.pem

You’ll see the full nested TLV structure with offsets, tags, and lengths — exactly how a credential system parses identity data. Try it on a few different sites and compare fields like subject name (SEQUENCE of RelativeDistinguishedNames).

Post-Quantum Cryptography (PQC) Basics Quantum computers threaten current public-key algorithms like RSA and ECDH via Shor’s algorithm, which factors large numbers or computes discrete logs efficiently. PQC develops algorithms resistant to both classical and quantum attacks. NIST standardized the first set in 2024:

• ML-KEM for key encapsulation (key exchange).
• ML-DSA and SLH-DSA for signatures.

This matters for your work in certificate/identity systems: TLS secures credential issuance, revocation, and verification. Migrating to PQC protects against “harvest now, decrypt later” attacks, where adversaries store encrypted traffic today for future quantum decryption.

CRYSTALS-Kyber vs. ML-KEM CRYSTALS-Kyber is the original lattice-based Key Encapsulation Mechanism (KEM) from the CRYSTALS team, submitted to NIST’s PQC process. It reached round 3 and won selection in 2022.

NIST standardized it as ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) in FIPS 203 (August 2024). ML-KEM derives directly from Kyber (round 3 version) with minor tweaks:

• Better domain separation in key generation to prevent cross-protocol attacks.
• Slight changes in seed generation for public values.

They are essentially the same algorithm—many implementations still call it “Kyber,” but the official standard is ML-KEM.

How ML-KEM (Kyber) Works It bases security on the Module Learning With Errors (MLWE) problem, a structured lattice problem hard even for quantum computers.

High-level flow:

1. Key Generation —
   • Randomly generate a public matrix A (from a seed).
   • Sample small secret vector s and error e.
   • Public key pk = (A, t), where t ≈ A·s + e (compressed to reduce size).
   • Private key sk includes s.
2. Encapsulation (Sender) —
   • To share a secret with pk holder: sample randomness, compute noisy equations.
   • Output: ciphertext ct (encapsulated key) + shared secret ss (32 bytes).
3. Decapsulation (Receiver) —
   • Use sk to remove noise from ct and recover the same ss.

Security achieves IND-CCA2 via the Fujisaki-Okamoto transform and explicit rejection for invalid ciphertexts. Compression keeps sizes reasonable.

Security levels:

• ML-KEM-512 → ~AES-128.
• ML-KEM-768 → ~AES-192 (most common for TLS hybrids).
• ML-KEM-1024 → ~AES-256.

Public keys ~1-1.5 KB, ciphertexts similar—larger than ECDH but practical.

esat.kuleuven.be

asecuritysite.com

Let’s break down each term one by one, like you’re completely new to this. We’ll use everyday analogies—no heavy math.

CRYSTALS

• This is just a project name, not a thing by itself.
• It stands for Cryptographic Suite for Algebraic Lattices.
• Think of it like a “brand” or “team name” from a group of researchers who built two quantum-safe tools:
  • Kyber (for key exchange)
  • Dilithium (for digital signatures)
• So when people say “CRYSTALS-Kyber”, they’re talking about the Kyber algorithm made by the CRYSTALS team.

Kyber

• The original name of the algorithm.
• It’s a way for two computers (like a browser and a server) to agree on a secret key over the internet, even if someone is listening.
• Analogy: Imagine you and a friend want to share a secret password, but you’re mailing it through a public post office where spies can read everything. Kyber is like putting the password in a magic box that only your friend can open—even if the spy sees the box.

KEM (Key Encapsulation Mechanism)

• This is the type of tool Kyber is.
• Simple definition: A KEM is a secure way to “wrap up” (encapsulate) a random secret key and send it to someone.
• The sender creates a small package (ciphertext) that contains the secret.
• Only the person with the private key can unwrap it and get the same secret.
• Everyone else sees garbage.
• It’s used for key exchange in things like TLS (the “https” lock in your browser).

ML (Module-Lattice)

• This is the math foundation that makes Kyber secure.
• “Lattice” = imagine a giant grid of points in many dimensions (like a 3D chessboard but with 512 dimensions). Finding the shortest path on this grid is super hard—even for quantum computers.
• “Module” = a structured way to build these grids so the math is efficient and fast on normal computers.
• You don’t need to understand the math deeply—it’s just why Kyber is believed to be quantum-safe.

Putting It All Together: Kyber → ML-KEM

• Original research name: CRYSTALS-Kyber
• NIST (the US standards body) picked it as the winner for quantum-safe key exchange.
• They renamed the standardized version to ML-KEM (Module-Lattice-based Key Encapsulation Mechanism) and published it as an official standard (FIPS 203) in 2024.
• So today:
  • Kyber = the original friendly name everyone still uses.
  • ML-KEM = the official government-standard name.
  • They are basically the same thing with tiny safety tweaks.

Why This Matters for Your Job (Certificates & Identity Systems) Certificates are delivered and validated over TLS connections. Right now TLS mostly uses old algorithms (like ECDH) that a big quantum computer could break in the future. Switching the key exchange part to ML-KEM (Kyber) protects credential issuance, enrollment, and revocation against future quantum attacks—especially important for long-lived certificates or sensitive identity systems.

Practical Part – See It in Action (Super Easy)

1. Real-World Example You Can Try Today Go to a test site that supports hybrid post-quantum TLS: https://pq.cloudflareresearch.com (Cloudflare’s PQ test page)
   • Open it in Chrome or Firefox (recent versions).
   • Open Developer Tools → Security tab.
   • You might see “X25519MLKEM768” or similar in the key exchange—this is classical + ML-KEM combined (hybrid mode). This shows a real certificate being delivered over a quantum-safe connection.
2. Tiny Code Snippet (Python with liboqs-python) If you have Python and want to play locally:Bashpip install liboqs-pythonPythonfrom oqs import KeyEncapsulation # Create ML-KEM-768 (most common level) kem = KeyEncapsulation("ML-KEM-768") # Server generates keys public_key = kem.generate_keypair() # Client encapsulates (sends secret) ciphertext, shared_secret_client = kem.encapsulate(public_key) # Server decapsulates (gets same secret) shared_secret_server = kem.decapsulate(ciphertext) print("Secrets match?" , shared_secret_client == shared_secret_server) # True!Run this script → it prints “True”. You’ve just done a real post-quantum key exchange in ~10 lines.

This is the same mechanism that will protect future certificate transport. Next time you can ask about the signature side (ML-DSA / Dilithium) or how hybrids work in real TLS handshakes!

Core Idea of AES

AES (Advanced Encryption Standard) is a symmetric block cipher — meaning the same key is used for both encryption and decryption. It is the most widely used encryption algorithm today and is the official U.S. government standard (FIPS 197) for protecting sensitive but unclassified data.

Key points:

• It operates on fixed-size 128-bit blocks of data (16 bytes).
• It supports three key sizes: 128, 192, or 256 bits.
• AES-128 uses a 128-bit key, AES-256 uses a 256-bit key.
• The algorithm is the same for all key sizes; the only differences are the key length and the number of rounds (iterations) it performs.

Why the different key sizes?

• Larger keys provide higher security against brute-force attacks.
• AES-128 is considered secure for most applications today (no practical attacks exist).
• AES-256 is used when regulations or policies require “higher assurance” (e.g., some government or financial systems, or when protecting data for decades into the future).

How AES Works (High-Level)

AES encrypts a 128-bit block through a series of rounds. Each round applies four transformations:

1. SubBytes – Non-linear substitution: each byte is replaced using a fixed lookup table (S-box). This provides confusion.
2. ShiftRows – Bytes in each row of the 4×4 state matrix are cyclically shifted left. This spreads data across the block (diffusion).
3. MixColumns – Each column is multiplied by a fixed matrix over GF(2⁸). Further diffusion.
4. AddRoundKey – The round key (derived from the main key) is XORed with the state.

The process:

• An initial AddRoundKey with the original key.
• Then Nr-1 full rounds (all four steps).
• A final round with no MixColumns.

Number of rounds (Nr):

• AES-128 → 10 rounds
• AES-192 → 12 rounds
• AES-256 → 14 rounds

Key expansion: The original key is expanded into a set of round keys (one per round) using a key schedule algorithm.

Modes of operation (important in practice):
AES by itself only encrypts one 128-bit block. To encrypt larger messages securely, we use modes like:

• CBC (legacy, needs padding and IV)
• CTR (turns AES into a stream cipher)
• GCM (Galois/Counter Mode) – most common today: provides both confidentiality and authenticated encryption (integrity + authenticity).

Security Summary

• No practical break of AES exists (as of 2026).
• Best known attacks are theoretical and reduce the effective security only marginally.
• AES-128 offers ~128 bits of security.
• AES-256 offers ~256 bits (overkill for most threats except quantum computers in the distant future).

In your domain (identity/credentials/certificates):

• AES is frequently used to encrypt private keys in keystores, protect credential databases, or encrypt data at rest.
• In protocols like TLS, AES-GCM is the dominant cipher suite.
• Many credential formats (e.g., encrypted JWTs, password vaults, secure enclaves) rely on AES.

Practical Part

Here’s a short, real-world Python example using the widely available cryptography library (the de-facto standard in Python for secure crypto). It shows AES-128-GCM and AES-256-GCM encryption/decryption of a simple message.

from os import urandom
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

def encrypt_aes(key_bit_size: int, plaintext: bytes) -> bytes:
    # Generate a random 128-bit (16-byte) nonce (IV) - required for GCM
    nonce = urandom(12)

    # Key size determines AES-128 or AES-256
    key = urandom(key_bit_size // 8)  # 16 bytes for 128-bit, 32 bytes for 256-bit

    aesgcm = AESGCM(key)
    ciphertext = aesgcm.encrypt(nonce, plaintext, associated_data=None)

    # Return nonce + ciphertext (common format)
    return nonce + ciphertext

def decrypt_aes(key_bit_size: int, key: bytes, data: bytes):
    nonce = data[:12]
    ciphertext = data[12:]

    aesgcm = AESGCM(key)
    plaintext = aesgcm.decrypt(nonce, ciphertext, associated_data=None)
    return plaintext

# Example usage
message = b"Secret credential data"

# AES-128-GCM
ct_128 = encrypt_aes(128, message)
print("AES-128 ciphertext length:", len(ct_128))

# AES-256-GCM
ct_256 = encrypt_aes(256, message)
print("AES-256 ciphertext length:", len(ct_256))

# To decrypt, you need the exact same key used for encryption
# (In real code you would securely store/load the key)

Key observations:

• Ciphertext length = nonce (12 bytes) + plaintext length + 16-byte authentication tag.
• Changing just one bit in the key or nonce produces completely different ciphertext.
• Never reuse nonce with the same key (GCM requirement).

Try running this snippet locally (install with pip install cryptography). It’s only ~30 lines and gives you immediate hands-on feel for the difference between AES-128 and AES-256 in practice.

pics wikipedia:

c github:

What is Bouncy Castle?

Bouncy Castle is an open-source cryptography library for Java (and C#). It provides a clean, well-maintained implementation of a very wide range of cryptographic algorithms and standards. The project is run by the Legion of the Bouncy Castle, a non-profit group in Australia, and has been actively developed since 2000.

The two main APIs are:

• Lightweight API – direct, low-level access to algorithms (similar to how you’d use them in C).
• JCA/JCE Provider API – implements the standard Java Cryptography Architecture (JCA) and Java Cryptography Extension (JCE), so you can plug it in as an additional security provider alongside the built-in Sun/Oracle providers.

Why use Bouncy Castle in certificate/identity/credential systems?

In your domain (handling X.509 certificates, digital signatures, PKCS objects, credential issuance/validation), Bouncy Castle is extremely common for several practical reasons:

1. Broader algorithm support
   Java’s default providers support only a subset of algorithms (and some are restricted by old export rules). Bouncy Castle adds many modern and legacy algorithms: ECDSA with named curves, EdDSA (Ed25519/Ed448), RSA-PSS, CMAC, GCM with large nonces, newer hash functions, etc.
2. Excellent ASN.1 and certificate handling
   X.509 certificates, CRLs, OCSP responses, PKCS#10 requests, PKCS#12 keystores, CMS signed data, etc., are all complex ASN.1 structures. Bouncy Castle has battle-tested parsers/generators that are more robust and feature-complete than the built-in java.security.cert classes.
3. Provider model integration
   You can register Bouncy Castle as a JCA provider with one line of code:

   Security.addProvider(new org.bouncycastle.jce.provider.BouncyCastleProvider());

After that, standard Java APIs (KeyStore, CertificateFactory, Signature, Cipher, etc.) automatically gain access to all Bouncy Castle algorithms without changing your existing code.

4. FIPS-compliant variants
   There are separate Bouncy Castle FIPS jars that are certified for use in regulated environments (government, finance, healthcare).
5. Used by almost every major Java library
   Libraries like Apache PDFBox, iText, Spring Security, Bouncy Castle is often already on the classpath indirectly. Using it directly avoids reinventing the wheel.
6. Lightweight and performant
   Compared to alternatives like OpenSSL bindings (JNI overhead) or commercial libraries, Bouncy Castle is pure Java, easy to bundle, and has good performance for most use cases.

When you might not need it: If you only use very basic algorithms (RSA 2048 + SHA-256 + PKCS#12) and stay within the default Java provider limits, you can avoid the extra dependency. But as soon as you touch modern elliptic curves, post-quantum prep, or complex certificate extensions, Bouncy Castle becomes the de-facto choice.

Practical part – simple code example

Here’s a minimal, self-contained example that shows:

• Adding Bouncy Castle as a provider
• Generating a self-signed X.509 certificate with ECDSA (something the default provider can’t do easily on older JDKs)

import java.math.BigInteger;
import java.security.*;
import java.util.Date;
import org.bouncycastle.jce.provider.BouncyCastleProvider;
import org.bouncycastle.x509.X509V3CertificateGenerator; // Legacy but simple API
import javax.security.auth.x500.X500Principal;

public class BouncyCastleExample {
    public static void main(String[] args) throws Exception {
        // 1. Register Bouncy Castle provider (do this once at app startup)
        Security.addProvider(new BouncyCastleProvider());

        // 2. Generate an EC key pair (curve prime256v1 = NIST P-256)
        KeyPairGenerator kpg = KeyPairGenerator.getInstance("EC", "BC");
        kpg.initialize(256); // or use named curve: new ECGenParameterSpec("prime256v1")
        KeyPair kp = kpg.generateKeyPair();

        // 3. Generate a self-signed certificate (valid for 1 year)
        X509V3CertificateGenerator certGen = new X509V3CertificateGenerator();
        X500Principal dn = new X500Principal("CN=Test Self-Signed Cert");

        certGen.setSerialNumber(BigInteger.valueOf(System.currentTimeMillis()));
        certGen.setIssuerDN(dn);
        certGen.setNotBefore(new Date());
        certGen.setNotAfter(new Date(System.currentTimeMillis() + 365L * 24 * 60 * 60 * 1000));
        certGen.setSubjectDN(dn);
        certGen.setPublicKey(kp.getPublic());
        certGen.setSignatureAlgorithm("SHA256withECDSA");

        java.security.cert.X509Certificate cert = certGen.generate(kp.getPrivate(), "BC");

        System.out.println("Generated certificate:");
        System.out.println(cert);
    }
}

Dependencies (Maven):

<dependency>
    <groupId>org.bouncycastle</groupId>
    <artifactId>bcprov-jdk18on</artifactId> <!-- or newer jdk version -->
    <version>1.78.1</version> <!-- check latest at https://www.bouncycastle.org/latest_releases.html -->
</dependency>

Run this snippet in any Java project and you’ll see a printed X.509 certificate that uses ECDSA – something you’d need in modern credential systems (e.g., for shorter signatures or post-quantum readiness).

This directly connects to your work: whenever you need to generate, parse, validate, or sign certificates programmatically in Java, Bouncy Castle is usually the safest and most capable choice.

Logical Channels in ISO/IEC 7816-4

ISO/IEC 7816-4 defines logical channels as a mechanism to run multiple independent sessions on a single physical smart card connection. Each channel maintains its own state:

• Currently selected application (DF – Dedicated File)
• Current file (EF – Elementary File)
• Security status (e.g., PIN verified, keys in use)

This is essential for multi-application cards (common in eID, health cards, or credential systems) where you might need to access identity data and a signing certificate at the same time without deselecting one to use the other.

Key facts

• Channel 0 → basic channel, always open at card reset (ATR), cannot be closed.
• Additional channels → typically 1–3 (total 4 channels); some modern/JavaCard implementations support up to 19.
• Channels are independent → no interleaving of command-response pairs across channels (you finish one command before the next, but you can switch channels between commands).
• Support level → indicated by the card (e.g., in ATR historical bytes or card capabilities data objects).

How the channel number is encoded (most common case – channels 0–3)
The channel number is in the CLA byte of every APDU, in bits b2 and b1:

Channel	b2 b1	CLA example (standard interindustry, no SM/chaining)
0	00	0x00
1	01	0x01
2	10	0x02
3	11	0x03

To switch channel in code: cla = (base_cla & 0xFC) | channel_number (clears low bits then ORs the number).

Opening and closing channels
Two ways:

1. Implicit (most common): Send any command (usually SELECT) with CLA indicating a closed channel → the card opens it automatically if supported.
2. Explicit: Use the MANAGE CHANNEL command (INS = 0x70).

MANAGE CHANNEL details

• Open (P1 = 0x00):
• P2 = 0x00 → card assigns an available channel and returns it.
• P2 = 0x01–0x03 → request a specific channel.
• Le = 0x01 if P2=0x00 (to get the assigned number), absent otherwise.
• Close (P1 = 0x80):
• P2 = channel number to close (bits b2 b1).

Practical examples (APDUs in hex)

1. Explicit open, card assigns (sent on channel 0):

   Command:  00 70 00 00 01
   Response: 02 90 00   ← card assigned channel 2 (data byte = 02)

2. Explicit open, request channel 1:

   Command:  00 70 00 01
   Response: 90 00        ← success, no data needed

3. Use the channel – SELECT an application on channel 1:

   Command:  01 A4 04 00 0A A0 00 00 00 63 50 4B 43 53 2D 31 35   ← example PKSC#15 AID

4. Close channel 1 (sent on channel 0):

   Command:  00 70 80 01
   Response: 90 00

5. Implicit open example – directly open channel 2 and select:

   Command:  02 A4 04 00 ... (AID)

Quick code snippet (Python-like with pcsc/pyscard style)

def send_on_channel(conn, base_cla, ins, p1, p2, data=b'', le=None, channel=0):
    cla = (base_cla & 0xFC) | channel   # set channel in low bits
    apdu = bytes([cla, ins, p1, p2]) + len_field + data + le_field
    response, sw1, sw2 = conn.transmit(apdu)
    return response, sw1, sw2

# Example: open channel 1 implicitly by selecting on it
send_on_channel(conn, 0x00, 0xA4, 0x04, 0x00, data=aid, channel=1)

This gives you concurrent access – perfect for credential systems where one channel can stay authenticated to an identity app while another performs operations in a different app. Tomorrow you can build on this (e.g., how security status can be shared or isolated across channels).

CMAC (Cipher-based Message Authentication Code) is a symmetric-key cryptographic algorithm that produces a fixed-size authentication tag (usually 8–16 bytes) for a message. It proves two things:

• Integrity: the message was not tampered with.
• Authenticity: the message came from someone who knows the shared secret key.

It is defined in NIST SP 800-38B (Recommendation for Block Cipher Modes of Operation: the CMAC Mode for Authentication) and is based on a block cipher like AES (AES-CMAC is the most common variant).

Key properties compared to similar algorithms:

Algorithm	Key Type	Base Primitive	Variable-length safe?	Common Use Cases
CMAC	Symmetric	Block cipher (e.g. AES)	Yes (built-in)	Protocols needing block-cipher-based MAC (EMV payments, some IoT, secure elements)
HMAC	Symmetric	Hash function (e.g. SHA-256)	Yes	Most internet protocols (JWT HS256, TLS, OAuth)
CBC-MAC	Symmetric	Block cipher	Only for fixed-length	Legacy systems (CMAC fixes its flaws)

CMAC is especially useful when you already have a block cipher (AES) in your system (e.g. for encryption) and want a MAC without introducing a separate hash function.

How CMAC Works (High-Level)

1. Key: A symmetric block-cipher key (e.g. 128-bit AES key).
2. Subkey generation:
   • Encrypt an all-zero block with the cipher → Rb.
   • Derive two subkeys K1 and K2 by left-shifting and conditional XOR with a constant (multiplication in GF(2¹²⁸)). This is done once per key.
3. Message processing:
   • Split the message into blocks.
   • Run standard CBC-MAC (chain encryption with XOR).
   • For the last block:
     • If the message length is a multiple of the block size → XOR K1.
     • Otherwise → pad to full block, then XOR K2.
   • The final ciphertext block is the MAC tag (often truncated).

This subkey trick makes CMAC secure for arbitrary-length messages (unlike plain CBC-MAC, which is only safe for fixed-length).

Relevance to Identity & Credential Systems

In your domain (certificates, identity, credentials):

• Digital certificates (X.509) usually use asymmetric signatures (RSA/ECDSA) for public verifiability.
• Symmetric MACs like CMAC appear when:
  • A shared secret exists (e.g. device-to-server mutual authentication).
  • Hardware security modules (HSMs) or secure elements use AES-CMAC.
  • Payment/contactless cards (EMV) use AES-CMAC for transaction authentication.
  • Some IoT credential bootstrapping or attested credentials in constrained environments.
  • Protocols that already use AES encryption and want a matching MAC without pulling in SHA-2.

If your system ever handles symmetric-key protected credentials or needs to authenticate data inside a secure channel, CMAC is a standard choice.

(c) from crypto stack exchange

P71 Card/Chip Overview

The “P71” refers to NXP Semiconductors’ SmartMX3 P71 series (e.g., P71D321, P71D320), a family of secure microcontrollers designed as the core chip in modern smart cards. It’s one of the most widely used platforms for high-security applications, especially in identity and credential systems like yours.

In your field of certificates, identity, and credentials, the P71 is highly relevant: it’s the hardware foundation for many national eID cards, ePassports, driver’s licenses, health cards, and PIV-style enterprise credentials. It securely stores private keys, X.509 certificates, biometric data, and executes cryptographic operations for authentication, signing, and access control—all while resisting physical and logical attacks.

How It Works

• Hardware Architecture
  The chip features a secure RISC CPU with dedicated crypto coprocessors (Fame3 for RSA/ECC, AES/DES engines, PUF for unique device keys, TRNG for randomness). It includes tamper-resistant sensors (light, voltage, glitch detection) and IntegralSecurity 3.0 countermeasures against side-channel and fault attacks. Memory options reach up to 500 KB non-volatile (Flash/EEPROM) for code/data, plus RAM. Dual-interface support covers contact (ISO 7816) and contactless (ISO 14443 Type A, up to 848 kbit/s).
• Software/OS Layer
  It typically runs JCOP4 (NXP’s Java Card OpenPlatform implementation): Java Card 3.0.5 Classic + GlobalPlatform 2.3. This allows multiple independent applets (e.g., one for eID authentication, one for qualified electronic signature, one for payment/EMV). Applets are post-issuance loadable and deletable in secure ways.
• Key Security Features
  Certifications include Common Criteria EAL6+ (highest for smart card OS), EMVCo, FIPS 140-3 on some configs. It supports protocols like PACE-CAM (for contactless privacy), EAC (Extended Access Control for biometrics), BAC/SAC for ePassports.
• Why It’s Common in Identity Systems
  Governments choose it because it balances performance (<2s for ePassport SAC), large memory for multiple certs/data groups, and proven resistance to attacks. Over 7 billion SmartMX chips have shipped globally.

Here’s a simplified block diagram of the architecture:

Practical Examples

Real-world cards using P71/JCOP4:

• Many modern eID cards (e.g., Slovenian eID uses P71 with JCOP4).
• Some fuel/loyalty cards in Africa (dual-purpose with payment + ID).
• Enterprise PIV cards (US gov-compatible) and FIDO2 security keys.

Here are photos of actual cards built on this chip:

Quick Practical Check: Identifying a P71 Card

Most JCOP4 P71 cards return a distinctive ATR (Answer To Reset). Example from a real Slovenian eID:

3B D5 18 FF 81 91 FE 1F C3 80 73 C8 21 10 0A

You can detect it in software like this (short Python snippet using pyscard – great for testing in credential systems):

from smartcard.System import readers
from smartcard.util import toHexString

r = readers()
if not r:
    print("No reader found")
else:
    reader = r[0]
    connection = reader.createConnection()
    connection.connect()
    atr = toHexString(connection.getATR())
    print("ATR:", atr)
    # Typical P71/JCOP pattern starts with 3B ...

If you see an ATR starting with 3B … FE 45 … or similar with “JCOP” in historical bytes, it’s very likely a P71-based card.

Next Step Connection
When working with certificates on these chips, you’ll often deal with EF.CV certificates in the eID applet (e.g., authentication cert, signing cert, QES cert). The secure storage and on-card key generation make them ideal for verifiable credentials—private keys never leave the chip.

Let me know the next term or how this ties into your current project!

SI session identifier in an authentication scheme symmetric asymmetric 1-step ake 2-step ake whatever. what is the SI??

What is SI (Session Identifier)?

In authentication and key exchange protocols (AKE = Authenticated Key Exchange), the Session Identifier (SI or commonly sid) is a value that uniquely labels a specific run of the protocol between two parties (e.g., client and server, or user and identity provider).

Its main roles are:

• Partnering: In security proofs, it defines which two protocol executions “belong together” — they must output the same SI and the same session key to be considered correctly partnered.
• Session management: Allows the server (or identity provider) to track or resume a session without repeating the full authentication.
• Resumption/abbreviation: In practical systems like TLS or OpenID Connect, the SI lets a client later resume the same session (reusing cryptographic material) with a shorter handshake.
• Logout/revocation: In identity systems, the SI can identify exactly which user session to terminate (e.g., single sign-out).

How SI is constructed – differences across schemes

• Symmetric AKE (pre-shared key, PSK-based):
  • SI is often derived from nonces exchanged by both parties or from data inside an encrypted/authenticated message.
  • Example: In TLS-PSK or Kerberos, the session/ticket contains an identifier that both sides can compute or extract from the shared secret.
• Asymmetric AKE (public keys, certificates):
  • SI can be explicitly chosen by one party (usually the server) and sent in clear, or derived from the transcript (all messages exchanged).
  • Classic example: TLS 1.2 – the server picks an opaque Session ID (0–32 bytes) and sends it in ServerHello.
• 1-step (one-round) AKE:
  • Only one message is sent (often unilateral authentication).
  • SI is usually based on that single message + static identities, or a server-generated value returned in the response.
• 2-step (two-round) AKE:
  • Both parties send messages and contribute fresh randomness.
  • SI is typically the concatenation of the two main flows (or a hash of them), ensuring both parties compute the exact same value. This gives strong partnering in security models.

In modern security models (eCK, Game-based models), the sid is formally defined as something both honest parties can compute identically from the transcript, so an adversary cannot force mismatched sessions.

Connection to your work (certificates, identity, credentials)

In systems that issue or present digital credentials:

• The authentication phase that protects the issuance or presentation often uses an AKE under the hood (usually TLS + OpenID Connect or mutual TLS).
• The SI (or equivalent session handle) is what lets the identity provider correlate the authenticated user with the credential issuance request, and later invalidate only that specific session if needed.

Practical part – real examples

1. TLS 1.2 Session ID (classic explicit SI) In a Wireshark capture of a TLS 1.2 handshake, look at the Server Hello message:
   • Field: “Session ID Length” followed by the Session ID bytes (e.g., 32 random bytes chosen by the server). If the client wants to resume, it sends the same Session ID in its ClientHello, and the server can skip certificate exchange and key derivation.
2. OpenID Connect – the “sid” claim (very common in identity systems) An ID Token issued by an OpenID Provider may contain:{ "iss": "https://idp.example.com", "sub": "user-123", "aud": "client-abc", "exp": 1735857600, "iat": 1735854000, "sid": "08a5f3c8-7d4e-4f2a-9b0e-1234567890ab" }The sid value is the session identifier at the OP. It is included in Logout Tokens so relying parties can tell the provider exactly which user session to terminate during back-channel logout.
3. Quick code snippet – extracting Session ID from a TLS handshake (Python + ssl)import ssl import socket from ssl import SSLContext hostname = 'www.example.com' context = SSLContext(ssl.PROTOCOL_TLS_CLIENT) context.load_verify_locations('/path/to/trust/store') # or use default with socket.create_connection((hostname, 443)) as sock: with context.wrap_socket(sock, server_hostname=hostname) as ssock: # After handshake, get the session ID (TLS 1.2 style) session_id = ssock.session.id if hasattr(ssock.session, 'id') else None print("Session ID (hex):", session_id.hex() if session_id else "None (TLS 1.3 or no resumption)")Run this against a server that still supports TLS 1.2 session IDs and you’ll see the server-chosen SI printed.

Takeaway for today: Whenever you see “SI” or “sid” in protocol specs or security proofs related to authentication, it almost always means Session Identifier — the glue that ties two protocol runs together and enables resumption/management features critical to real-world identity systems.

TLS-PSK

What is TLS-PSK?

TLS-PSK (Pre-Shared Key) is a family of TLS authentication and key exchange modes that use a symmetric key shared in advance between client and server instead of (or in addition to) public-key certificates. It is a symmetric authenticated key exchange (AKE) because both parties prove possession of the same secret key, achieving mutual authentication without asymmetric cryptography in its pure form.

Key use cases in your domain (identity & credentials):

• Constrained devices (IoT, embedded) where certificate validation is too heavy.
• Closed ecosystems where keys can be provisioned out-of-band (e.g., device manufacturing).
• Session resumption (very common) – a PSK derived from a previous full handshake to make subsequent connections faster and lighter.
• Some credential issuance/presentation protocols use PSK-based channels for efficiency.

How TLS-PSK works – main variants

1. TLS 1.2 PSK (legacy, “pure” external PSK)
   • Separate PSK cipher suites (e.g., TLS_PSK_WITH_AES_128_GCM_SHA256).
   • Client sends ClientKeyExchange containing a PSK identity (a hint, often opaque or human-readable).
   • Both sides compute the master secret as: master_secret = PRF(pre_master_secret, “master secret”, client_random + server_random) where pre_master_secret is derived directly from the PSK (no Diffie-Hellman).
   • Optional: PSK can be combined with DHE/RSA for forward secrecy.
   • Symmetric authentication: the ability to derive correct finished messages proves knowledge of the PSK.
2. TLS 1.3 PSK (modern, integrated)
   • No separate cipher suites – PSK is a key exchange mode selected in the KeyShare extension.
   • Three sub-modes:
     • PSK-only (external): Pure symmetric, no forward secrecy. Rare in practice.
     • PSK-DHE: PSK for authentication + ephemeral Diffie-Hellman for forward secrecy (recommended).
     • PSK-only (resumption): Most common real-world use – the PSK is derived from a previous full (certificate-based) handshake.
   • Handshake flow (simplified for resumption PSK-DHE):
     1. ClientHello: offers one or more pre_shared_key extensions with PSK identities (ticket or opaque binder) + a KeyShare (ephemeral DH).
     2. Server selects one PSK and sends NewSessionTicket (for future resumptions) + its own KeyShare.
     3. Both derive session keys from the PSK + DH shared secret + transcript.
   • Binders: Client includes a cryptographic binder (HMAC over transcript using the offered PSK) to prevent downgrade attacks.

Symmetric vs Asymmetric in TLS context

Aspect	Certificate-based (asymmetric)	PSK-based (symmetric)
Authentication	Public keys + certificates (PKI)	Shared secret key
Key distribution	Trust anchors, revocation checks	Out-of-band provisioning
Computational cost	Higher (signature verification)	Lower (symmetric ops only)
Forward secrecy	Possible with DHE/ECDHE	Only if combined with (ECDHE)
Typical use	Public web, general identity	IoT, resumption, closed systems
Session resumption	Session ID (TLS 1.2) or tickets	PSK tickets (preferred in TLS 1.3)

Connection to Session Identifier (SI) from yesterday

In TLS-PSK resumption:

• The PSK identity in the pre_shared_key extension acts as the session identifier.
• For resumption tickets (most common), the identity is the opaque ticket itself (sent in clear), which the server uses to look up the encrypted PSK state.
• This is exactly the “SI” concept: a value that uniquely identifies the session and allows the server to resume it without repeating full authentication.

Practical part – real examples you can try

1. List current PSK-related cipher suites on a server Use OpenSSL (most Linux/macOS machines have it):openssl ciphers -v | grep -i PSKYou’ll see legacy TLS 1.2 suites like:TLS_PSK_WITH_AES_128_CBC_SHA TLSv1.2 Kx=PSK Au=PSK Enc=AES(128) Mac=SHA1In TLS 1.3, PSK is not listed as separate ciphers – it’s a mode.
2. Force a TLS 1.3 resumption handshake with PSK (using curl) First full handshake (creates ticket), then resumption:# Full handshake (server sends ticket) curl https://example.com --tlsv1.3 --tls-max 1.3 # Subsequent call often resumes automatically if server supports tickets curl https://example.com --tlsv1.3 --tls-max 1.3 -v 2>&1 | grep "Reused.*PSK"Look for output like “Reusing existing connection… with PSK” or in verbose mode “TLSv1.3 (OUT), TLS handshake, Finished”.
3. Wireshark view of PSK identity (resumption ticket) Capture a TLS 1.3 resumption to a site like cloudflare.com:
   • Filter: tls.handshake.type == 1 (ClientHello)
   • Expand Pre-Shared Key Extension → identities → you’ll see the opaque ticket bytes (the SI) sent in clear.

Takeaway for today: TLS-PSK is the practical symmetric AKE inside TLS, especially dominant for session resumption. When you design credential systems that run over TLS, resumption PSKs are what make repeated authentications cheap and fast, and the PSK identity/ticket is the concrete “SI” that ties sessions together.

TLS diagramThought for 33s

Visualizing the TLS Handshake

The TLS handshake is the core Authenticated Key Exchange (AKE) we’ve been discussing: it establishes authenticated, confidential channels, derives session keys, and enables features like session identifiers (SI) and PSK resumption.

Diagrams make the message flows (and differences between versions) much clearer than text alone.

Key points connecting to what we covered:

• TLS 1.2 (legacy but still common): Multi-round (usually 2-RTT), explicit Session ID field in ServerHello for resumption (that’s the classic SI you asked about first). Resumption can abbreviate the handshake.
• TLS 1.3 (current standard): Streamlined to 1-RTT for full handshakes, encryption starts earlier, no explicit Session ID field — instead uses opaque session tickets (sent via NewSessionTicket post-handshake) that contain an encrypted PSK for resumption. This is the modern symmetric resumption path we discussed in TLS-PSK.
• PSK in TLS 1.3: For resumption, the client sends a pre_shared_key extension in ClientHello containing the ticket (the SI) from a prior connection. Server looks it up, both derive keys — often combined with ephemeral DH for forward secrecy. This makes repeat connections very fast (1-RTT or even 0-RTT with risks).

Here are clear, high-quality diagrams showing the flows:

sobyte.net

Understanding HTTPS principles, SSL/TLS protocols in detail – SoByte

Side-by-side comparison of TLS 1.2 vs TLS 1.3 full handshakes, with real-world latency impact (notice how TLS 1.3 reduces round trips).

medium.com

TCP and TLS handshake: What happens from typing in a URL to …

Another clean comparison highlighting the simplified message flow in TLS 1.3.

cloudflare.com

What happens in a TLS handshake? | SSL handshake | Cloudflare

Detailed TLS 1.3 handshake (certificate-based) — note how application data can flow right after the client’s Finished message (1-RTT).

linkedin.com

How the SSL/TLS Handshake Works: A Modern Guide

Modern view of TLS 1.3 emphasizing forward secrecy via ephemeral Diffie-Hellman (common in practice).

Practical part – see it yourself

To spot the SI/PSK identity in a real handshake:

1. Install Wireshark.
2. Capture traffic to a site like cloudflare.com (supports TLS 1.3 tickets).
3. First visit → full handshake.
4. Refresh quickly → look for resumption:
   • Filter: tls.handshake.type == 1 (ClientHello)
   • Expand “Extension: pre_shared_key” → you’ll see the opaque ticket bytes (the session identifier / PSK identity) sent in clear.

Or quick code check (Python, same as before but force resumption):

import ssl
import socket

hostname = 'www.cloudflare.com'
context = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
context.check_hostname = False  # for demo only
context.verify_mode = ssl.CERT_NONE

with socket.create_connection((hostname, 443)) as sock:
    with context.wrap_socket(sock, server_hostname=hostname) as ssock:
        print("TLS version:", ssock.version())
        print("Cipher:", ssock.cipher())
        # On second run quickly, you'll often see resumption active

Run twice in a row — many servers will resume using PSK tickets automatically.

Takeaway for today: The handshake diagrams show exactly where authentication, key derivation, and session resumption (via SI or PSK ticket) happen — critical for any identity/credential system running over TLS.

16 sources

Example CVC from BSI TR-03110 (Public/Test Patterns)

BSI TR-03110 defines the CVC format precisely for use in ePassports (EAC) and eID systems, but BSI does not publish raw CVC test files directly on their site (they focus on test CSCA X.509 roots and interoperability guidelines). Instead, public test CVCs are widely available in open-source implementations and interoperability test suites that follow TR-03110 exactly.

These test certificates typically use the fictional country code “UT” (Utopia) or “DETEST” to avoid conflicting with production keys. They form short chains: CVCA → DV → Terminal (IS).

Libraries like EJBCA (with CVC plugin), OpenPACE, pycvc (Python), and JMRTD (Java) generate or include compliant test CVCs for developers.

Typical Parsed Test CVCA Example (Self-Signed Root)

Here is a realistic parsed example of a test CVCA CVC (based on common public test patterns from open-source TR-03110 implementations):

• Profile Identifier (tag 0x5F29): 00 (initial profile)
• Certificate Authority Reference (CAR) (tag 0x42): UTCVCA00001 (ASCII, identifies the issuer)
• Public Key (tag 0x7F49): Nested TLV
• OID: id-TA-ECDSA-SHA-256 (1.0.36.3.3.2.8.1.1.7 for brainpoolP256r1)
• Domain parameters: BrainpoolP256r1 reference
• Uncompressed point: 04 || X (32 bytes) || Y (32 bytes) – e.g., a test key point like 04 6B17D1F2... (full hex varies by generated key)
• Certificate Holder Reference (CHR) (tag 0x5F20): UTCVCA00001 (same as CAR for root/self-signed)
• Effective Date (tag 0x5F25): 100101 (YYMMDD → 2010-01-01)
• Expiration Date (tag 0x5F24): 251231 (2025-12-31)
• Signature (tag 0x5F37): ECDSA-SHA-256 signature (r || s, ~64 bytes)

No CHAT (0x7F4C) or extensions (0x65) in a basic CVCA.

The signed body is the raw concatenation of all TLV objects from 0x5F29 to 0x5F24. This keeps parsing simple on cards (no full ASN.1 parser needed).

Quick Comparison to X.509 (Connecting Dots)

Field/Aspect	X.509 (ASN.1 DER)	CVC (BER-TLV)
Issuer/Subject	Full DN in complex ASN.1	Short printable strings (CAR/CHR)
Public Key	SubjectPublicKeyInfo with OID	0x7F49 with nested OIDs and point
Validity	UTCTime fields in TBSCertificate	Simple YYMMDD strings
Authorization	Extensions (EKU, SAN)	Dedicated CHAT (bitmask for roles)
Signed Portion	Only TBSCertificate	All TLVs except signature
Size	Often 500–1000+ bytes	Typically 200–400 bytes (card-optimized)

CVC trades flexibility for size and parsing speed – perfect for offline verification on the chip.

Practical Part: Get and Inspect a Real Test CVC

1. Install a library to generate/view one (10-minute task):

• Python: pip install pycvc (implements TR-03110 fully).
• Or clone https://github.com/frankmorgner/openpace and build cvc-print.

1. Example with pycvc (run this to create a real test CVCA):

   from pycvc.cvc import CVCertificateBuilder, ECCurve
   from ecdsa import SigningKey, NIST256p  # Or Brainpool

   # Simple test self-signed CVCA
   sk = SigningKey.generate(curve=NIST256p)  # Use Brainpool for full TR-03110 compliance
   vk = sk.verifying_key

   builder = CVCertificateBuilder()
   builder.set_car("UTCVCA00001")
   builder.set_chr("UTCVCA00001")
   builder.set_public_key(vk)
   builder.set_effective_date("100101")
   builder.set_expiration_date("251231")

   cvc = builder.build(sk)  # Signs it
   print(cvc.to_der().hex())  # Outputs full hex of the CVC

This gives you a real DER-encoded CVC in hex. Dump it to file: with open('test_cvca.cvc', 'wb') as f: f.write(cvc.to_der())

3. Simple TLV parser to inspect any CVC hex (extend for nested public key):

   def parse_simple_tlv(data: bytes):
       pos = 0
       fields = {}
       while pos < len(data):
           tag = data[pos]
           pos += 1
           len_byte = data[pos]
           pos += 1
           if len_byte & 0x80:  # Long form (rare in CVC)
               continue  # Skip for simplicity
           length = len_byte
           value = data[pos:pos + length]
           pos += length
           if tag == 0x42:
               fields['CAR'] = value.decode('ascii')
           elif tag == 0x5F20:
               fields['CHR'] = value.decode('ascii')
           elif tag == 0x5F25:
               fields['Effective'] = value.decode('ascii')
           elif tag == 0x5F24:
               fields['Expiration'] = value.decode('ascii')
           # Add 0x7F49 handling recursively for pubkey
       return fields

   # Use with your generated hex
   hex_cvc = "your_hex_here_without_spaces"
   print(parse_simple_tlv(bytes.fromhex(hex_cvc)))

Run the builder → get real hex → parse it. You’ll see the exact fields match the example above.

This connects directly to signature verification: next time, we can add ECDSA verify on the body bytes using the public point from 0x7F49.

Spend your 10 minutes generating one with pycvc – it’s the fastest way to have a real TR-03110-compliant CVC on your machine.

Digital Signatures in Certificates and Credentials: X.509 vs. CVC

Digital signatures are the core mechanism that makes certificates trustworthy in identity and credential systems. They ensure authenticity (the certificate really comes from the claimed issuer), integrity (the content hasn’t been tampered with), and non-repudiation (the issuer can’t deny having issued it).

How a Digital Signature Works (General Principle)

1. The issuer creates the certificate data (subject identity, public key, validity dates, authorizations, etc.).
2. This data (or a specific “to-be-signed” portion) is hashed using a cryptographic hash function (e.g., SHA-256 or SHA-3).
3. The hash is encrypted with the issuer’s private key → this encrypted hash is the signature.
4. The signature is attached to the certificate.
5. To verify:

• Compute the hash of the received certificate data.
• Decrypt the signature using the issuer’s public key.
• Compare the two hashes. If they match → valid signature.

This is the same fundamental process for both X.509 and CVC, but the structure, encoding, and use cases differ.

X.509 Certificates

• Standard: ITU-T X.509 (most widely used public key certificate format).
• Use cases in your domain: TLS/SSL server certificates, client certificates, code signing, S/MIME email, enterprise PKI for user authentication, many verifiable credential systems (when using traditional PKI).
• Structure relevant to signatures:
• Three main parts:
  1. TBSCertificate (To Be Signed Certificate) – contains version, serial number, issuer, subject, public key, validity, extensions, etc.
  2. signatureAlgorithm – identifies the algorithm (e.g., sha256WithRSAEncryption, ecdsa-with-SHA256).
  3. signatureValue – the actual signature bits (the encrypted hash of the TBSCertificate).
• Encoding: ASN.1 DER (strict binary encoding).
• Signature process:
• Hash only the TBSCertificate (not the signature fields).
• Sign with issuer’s private key.
• Common algorithms: RSA-PKCS#1 v1.5, RSA-PSS, ECDSA (with NIST or Brainpool curves).
• Libraries you’ll use: OpenSSL, Bouncy Castle, Java’s java.security.cert, Python’s cryptography or pyOpenSSL.

Card Verifiable Certificates (CVC)

• Standard: Defined in ISO/IEC 7816-8 and BSI TR-03110 (German Federal Office for Information Security).
• Use cases in your domain: Smart card-based identity systems, especially European eID cards, ePassports (EAC – Extended Access Control), government-issued credentials where the card itself performs verification (offline, constrained environment).
• Key differences from X.509:
• Designed for resource-constrained devices (smart cards).
• Focus on role-based authorization rather than general identity.
• Shorter chain length, often self-described references (CAR = Certificate Authority Reference, CHR = Certificate Holder Reference).
• Structure relevant to signatures:
• TLV (Tag-Length-Value) encoding (BER-TLV, more flexible than DER).
• Profile Identifier, CAR, Public Key, CHR, Certificate Holder Authorization Template (CHAT – defines roles/permissions), validity dates, optional extensions, and outer signature.
• No separate TBSCertificate block – the signature is over the entire certificate body (all fields except the signature itself).
• Signature process:
• Concatenate the body fields in defined order.
• Hash and sign with issuer’s private key (almost always ECDSA for performance on cards).
• Common curves: BrainpoolP256r1, BrainpoolP384r1, or NIST P-256.
• Chain: Starts from a root CVCA (often linked to an X.509 CSCA), then DV (Document Verifier) certificates, then terminal/IS certificates – all in CVC format after the root.
• Libraries/tools: Less common than X.509. Often BSI libraries, OpenSC, or custom implementations in JavaCard/GlobalPlatform environments.

Quick Comparison Table

Aspect	X.509	CVC (Card Verifiable Certificate)
Primary Use	General PKI, web, enterprise	Smart cards, eID, ePassport EAC
Encoding	ASN.1 DER (strict)	BER-TLV (flexible)
Signed Data	TBSCertificate only	Entire body except signature
Typical Algorithms	RSA or ECDSA	Almost always ECDSA (card-friendly)
Authorization Model	Extensions (e.g., SAN, EKU)	CHAT field (role-based, bitmask)
Chain Length	Can be long	Usually very short (1–3 levels)
Verification Location	Anywhere (online/offline)	Often on the card itself (offline)
Standard Bodies	ITU-T, IETF (RFC 5280)	ISO/IEC 7816, BSI TR-03110

Why This Matters for Your Job

• In identity/credential systems, you’ll often need to issue, verify, or chain both types.
• Modern systems sometimes bridge them: an X.509 CSCA root signs a CVC chain for ePassport access control.
• When implementing verification services, remember that CVC requires stricter parsing of TLV structures and specific OID handling.
• Performance tip: ECDSA verification is much faster than RSA on constrained devices → prefer ECDSA when designing new credential formats.

Spend your 10 minutes today mentally walking through a verification flow: take a real client certificate (X.509) in your browser, view it, and trace the signature fields. Then look up a BSI TR-03110 example CVC (public test data exists) and compare the structure.

Next time you ask about a related topic (e.g., specific algorithms, revocation, or verifiable credentials with JSON-LD signatures), I’ll connect it back to this foundation.