Digital Signatures, PKI, and Cryptographic Protocols

Demystifying Digital Signatures, PKI, and Cryptographic Protocols: Your Essential Guide

In our increasingly digital world, securing online interactions and verifying identities is paramount. This comprehensive guide will break down the complex topics of Digital Signatures, PKI, and Cryptographic Protocols, explaining their fundamental roles in ensuring trust and security in electronic transactions. We'll cover everything from how digital signatures work to the intricate systems that underpin secure communication.

Understanding Digital Signatures: What Are They and Why Do They Matter?

A digital signature offers essential security functionalities: data integrity, data origin authentication, and non-repudiation of origin. Unlike a Message Authentication Code (MAC) which provides integrity and authentication but no repudiation, a digital signature ensures the signer cannot later deny having signed the data. In practice, it's typically the hash of the data that is signed, not the data itself, due to performance considerations with asymmetric cryptography.

Key steps involved in using digital signatures include:

1. Key Generation: Creating a unique private and public key pair.
2. Public-Key Certification/Signing: Associating the public key with an identity.
3. Signature Generation: Creating the digital signature using the private key.
4. Signature Verification: Using the public key to confirm the signature's authenticity and data integrity.

For signature verification, the public key must be authentic and readily available. The private key, used for signing, must always be kept confidential.

Types of Electronic Signatures Under eIDAS Regulation

The European Union's eIDAS Regulation (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) defines three main types of electronic signatures, each with different technological requirements and legal weight:

• Simple Electronic Signature: This is any data in electronic form, attached to or logically associated with other electronic data, and used by the signatory to sign. An email signature like "Pavel Loutocký" is an example.
• Advanced Electronic Signature (AES): While based on a certificate, it has no specific requirements for the certificate itself. It's considered "something in between" simple and qualified signatures.
• Qualified Electronic Signature (QES): This is the highest level, an advanced electronic signature that must be based on a qualified certificate for electronic signatures and created using a qualified electronic signature creation device (e.g., chip cards, eID, tokens). It provides the equivalent legal effect of a handwritten signature in all EU Member States.

Article 25 of eIDAS clarifies that an electronic signature cannot be denied legal effect solely because it's electronic or doesn't meet QES requirements. However, a qualified electronic signature holds the equivalent legal effect of a handwritten signature.

Public Key Infrastructure (PKI): The Foundation of Trust

Public Key Infrastructure (PKI) is a system of hardware, software, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates. It's the framework that enables secure communication by managing public keys and their associated identities.

Public Key Certificates and Their Role

A public-key certificate, often in the X.509v3 standard, is issued by a trusted Certification Authority (CA). It binds a public key to an individual or entity, allowing others (relying parties) to trust that public key even if the CA is offline. Relying parties trust the values in the certificate to make decisions, employing approaches like "Trust on First Use" (TOFU) or "Check on First Use" (COFU).

When creating a public-key certificate, a CA checks:

1. Evidence of corresponding private key control/knowledge: This can be logistically complex.
2. Evidence of computer-addressable identity control/ownership: This is commonly done.
3. Evidence of real-world identity/name ownership: This can be complicated across different borders and cultures.

The certificate contains the subject's public key, subject information, and policy data, all digitally signed by the CA's private key. The CA's public key (certificate) must be available to relying parties for verification.

X.509v3 certificates include extension fields that can be critical or non-critical. If a system encounters an unknown critical field, it must reject the entire certificate. Examples include:

• Key-Usage: Defines allowed uses for the key (e.g., signatures, encryption).
• Extended-Key-Usage: Specifies further uses like code signing or TLS server authentication.
• Subject-Alternate-Name: Provides alternative identifiers like email addresses or domain names.
• Name-Constraints: Allows a CA to control subject names in subsequent certificates within a hierarchy.

PKI Trust Models

PKI employs various trust models:

• Browser/application trust model: Browsers and applications come pre-configured with a list of trusted root CAs.
• Cross-certification: Two CAs mutually trust each other, allowing their respective certificate chains to be validated across domains.
• Hierarchical trust model: A root CA issues certificates to intermediate CAs, which then issue certificates to end entities, forming a chain of trust.

Certificate Chain Validation Explained

When a public-key certificate is presented, its validity is established through a certificate chain validation. This process involves verifying each certificate in the chain, from the end-entity certificate all the way up to a trusted root CA certificate, ensuring that each certificate was signed by the private key corresponding to the public key in the next certificate up the chain.

Certificate Revocation: When Trust Ends

Certificates are not permanent and can be revoked for various reasons, not just key compromise. Revocation means a certificate is no longer valid before its scheduled expiry date. The primary methods for checking revocation status are:

• Certificate Revocation List (CRL): This is a "blacklist" published by the CA, listing revoked certificate serial numbers and the time of revocation. It's important to note it's a list of revoked certificates, not revoked public keys.
• Online Certificate Status Protocol (OCSP): This preferred method involves querying a CA responder in real-time about a certificate's status, which can be "good," "revoked," or "unknown." OCSP offers fresher status information compared to CRLs.

Handling Key Compromise

Key compromise is a serious security event with different implications depending on whose key is compromised:

• User Private Key Compromised: The user should request revocation ASAP, inform potential relying parties, and obtain a new key pair and certificate.
• CA Private Key Compromised: This is a severe threat to business trust. All relying parties must be informed. Key hierarchies can offer a partial solution by limiting the impact. Root CA keys are highly protected (e.g., in safes, encrypted for most of their lifetime), with recovery options like threshold cryptography (where 't' out of 'n' shareholders are needed to recover the secret).

Cryptographic Protocols: Orchestrating Secure Interactions

A cryptographic protocol is an algorithm that specifies the exchange of messages and actions between parties, involving cryptographic techniques to achieve a specific security goal. They are fundamental to secure communication over networks.

Goals and Types of Cryptographic Protocols

Common goals and types of cryptographic protocols include:

• Entity Authentication Protocols: Verify the identity of one or more parties.
• Unilateral Authentication: One party is authenticated to another.
• Mutual Authentication: Both parties authenticate each other.
• Key Establishment Protocols: Establish shared cryptographic keys between parties.
• Key Transport: One party transfers a key to another.
• Key Agreement: Parties contribute to derive a shared key.

Most modern security protocols combine authentication with key establishment, typically focusing on authenticated key establishment to create session keys (short-term, symmetric, often ephemeral and destroyed after use). Authentication-only protocols are rare.

Basic Unilateral Authentication Protocol Examples

• Naïve Solution – Sending the Secret (S): The verifier learns S and can impersonate the claimant. (Insecure)
• Naïve Solution – Sending Hash of Secret (H(S)): The verifier doesn't learn S but can replay H(S) to impersonate. (Insecure)
• Challenge-Response (2-step) with Password: B challenges A with random value 'r', A responds with H(r, P) (where P is password). Vulnerable to offline guessing attacks if the password is weak.

Challenge-Response with Symmetric Cryptography

1. A ← B: rB (B sends a random number challenge 'rB' to A)
2. A → B: E_K(rB, "B") (A encrypts 'rB' and a fixed string "B" with a shared secret key K, and sends it back to B)

This protocol aims for unilateral authentication of A (claimant) to B (verifier) by proving knowledge of the secret key K. However, it's susceptible to reflection and relay attacks, depending on the wider context and timing.

Challenge-Response with Asymmetric Cryptography

This approach proves the ability to use a private key.

• Through Signing:

1. A ← B: rB
2. A → B: rA, "B", Sign_A(rA, rB, "B") (A sends its own random 'rA', "B", and a signature over 'rA', 'rB', and "B" using its private key. B must have A's trusted certificate.)

• Through Decryption:

1. A ← B: h(r), "B", Pub_A(r, "B") (B sends a hash of 'r', "B", and an encrypted message using A's public key, containing 'r' and "B". B must have A's public key from a trusted certificate.)
2. A → B: r (A decrypts the message and sends 'r' back).

Key Establishment with Public-Key Cryptography

• Public-key encrypted session key examples:
• A → B: P_B(S_A("B", K, t_A)): A encrypts a signed session key K and timestamp t_A with B's public key. (Requires signature schemes with message recovery).
• A → B: P_B(K, t_A), S_A("B", K, t_A): A encrypts K and t_A with B's public key, and also sends a separate signature over "B", K, and t_A. (Typical for signature schemes with appendix).
• Diffie-Hellman Key Agreement: The first published concept in public-key cryptography (1976), allowing two parties (Alice and Bob) to establish a shared secret key over an insecure channel without ever directly exchanging the key.
• Alice calculates g^a mod p and sends it to Bob.
• Bob calculates g^b mod p and sends it to Alice.
• Alice then calculates (g^b mod p)^a mod p = g^(ab) mod p.
• Bob calculates (g^a mod p)^b mod p = g^(ab) mod p.
• Both arrive at the same shared secret g^(ab) mod p.

Attacks on Authentication Protocols

Authentication protocols can be vulnerable to various attacks, including replay attacks, reflection attacks, and Man-in-the-Middle (MITM) attacks, where an attacker secretly relays and alters the communication between two parties who believe they are directly communicating.

Time-Variant Parameters (TVPs) for Protocol Security

TVPs provide uniqueness or freshness (timeliness) to protocol messages and cryptographically bind them together:

1. Random Number: Guarantees freshness and chains messages. Must be unpredictable, never reused, and sufficiently long to make reuse negligible.
2. Timestamp: Guarantees timeliness without a challenge-response. Requires synchronized clocks and helps enforce time-bounded protocols.
3. Sequence Number: Used when only message uniqueness is required, not unpredictability. Often a monotonic counter.

Timestamping: Proving Data Existence in Time

Timestamping provides a guarantee of data existence at a specified time and often a timeliness guarantee in cryptographic protocols. It typically combines a digital signature with reliable clock information. Challenges include clock synchronization issues and potential attacks. Timestamping is considered one of the first "digital notary services."

eIDAS Regulation: Shaping Europe's Digital Identity

The eIDAS Regulation (Regulation (EU) No 910/2014), updated by eIDAS 2.0 (Regulation (EU) 2024/1183), is crucial for completing the digital free internal market in Europe. It enhances the credibility of electronic transactions and creates a unified framework for electronic identification and trust services.

What eIDAS Covers

1. Electronic Identification (eID): Defines "electronic identification" as using person identification data in electronic form to uniquely represent a natural or legal person. The goal is mutual recognition of eIDs across EU Member States.

• Assurance Levels: eIDAS defines three levels of assurance for electronic identification means: Low, Substantial, and High. These levels refer to the degree of confidence in the claimed identity, based on technical specifications and controls.

2. Trust Services: Aligns regulations for specific tools:

• Electronic signature
• Electronic seal
• Electronic timestamp
• Electronic registered delivery
• Website authentication
• Electronic document

eIDAS 2.0 and the Future of Digital Identity

The revision, eIDAS 2.0, introduces concepts like the European Digital Identity Wallet (EUIDW), qualified archiving, attributed authentication, and advanced electronic signatures based on qualified services. This framework aims to provide citizens and businesses with a secure and convenient way to prove their identity and share electronic attestations of attributes across borders.

Frequently Asked Questions about Digital Signatures, PKI, and Cryptographic Protocols

What is Public Key Infrastructure (PKI) and why is it important?

PKI is a system that enables secure communication by managing public keys and their associated identities. It's crucial because it provides the framework for verifying the authenticity of digital certificates and ensuring trust in online transactions, much like a digital passport system for identities and encryption keys.

How does a digital signature differ from a traditional handwritten signature?

A digital signature uses cryptographic techniques to link a signature to data, providing strong guarantees of integrity and origin, and non-repudiation. A handwritten signature, while legally binding, can be forged and doesn't inherently verify the integrity of a document after it's signed. A qualified electronic signature under eIDAS has the equivalent legal effect of a handwritten signature.

What are the main types of cryptographic protocols?

Cryptographic protocols primarily serve two main goals: entity authentication (verifying identities, either unilaterally or mutually) and key establishment (creating shared secret keys, either through transport or agreement). Most modern protocols combine these two functions to establish authenticated, ephemeral session keys.

What is the eIDAS regulation, and what does it cover?

The eIDAS Regulation is an EU law that establishes a common framework for electronic identification and trust services across Member States. It covers electronic identification (eID) with different assurance levels and various trust services like electronic signatures, seals, timestamps, and website authentication, aiming to facilitate a digital single market.

What happens if a private key is compromised?

If a user's private key is compromised, they must immediately request certificate revocation, inform any relying parties, and obtain a new key pair and certificate. If a Certification Authority's private key is compromised, it's a severe threat requiring all relying parties to be informed, and can impact the trust in a wide range of certificates. Strong protections are in place for CA keys to prevent such occurrences.