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.