Digital Certificates & Cryptographic Protocols
Asymmetric Cryptography and the Problem of Identity Verification
Foundations of Asymmetric Cryptography: * Asymmetric cryptographic algorithms rely on key pairs that function in tandem. * The Public Key: This key is freely distributed and is accessible to all individuals. * The Private Key: This key is kept strictly confidential and is only known to its designated owner. * Operational Logic: If data is encrypted using one key in the pair, it can only be decrypted using the corresponding related key. * Data in Transport: Public key cryptography is primarily used to prevent unauthorized access during transmission. For example, if Mr. Instructor encrypts a message using Alice’s public key, only Alice can decrypt it because she is the sole possessor of the associated private key.
The Identification Challenge: * While asymmetric encryption ensures that only the intended recipient can view or alter a message, it does not inherently guarantee the identity of the sender. * Because Alice’s public key is distributed freely, any individual (such as Mr. Student pretending to be an instructor) can use it to encrypt a fraudulent message to her. * A mechanism is required to verify that Mr. Instructor was the actual sender.
Digital Signature Algorithms (DSA)
Mechanism of DSA: * Asymmetric cryptography supports digital signing by leveraging the bi-directional nature of the key pairs. * If a message can be successfully decrypted using a specific user's public key, it provides proof that the message must have been encrypted using that user's private key. * Digital Signature Algorithms (DSA) utilize this fact to provide electronic verification of the sender.
Step-by-Step Process of Digital Signing: 1. Creation of Digest: Mr. Instructor creates a message and applies a hash algorithm to generate a unique digest of the content. 2. Encryption of Digest: Mr. Instructor encrypts this digest using his private key. This encrypted digest constitutes the Digital Signature. 3. Transmission: Mr. Instructor sends both the original message and the digital signature to Alice. 4. Decryption of Signature: Alice receives the package and attempts to decrypt the digital signature using Mr. Instructor’s public key. * If decryption fails, Alice knows the message did not originate from Mr. Instructor, as only his private key could have created a signature compatible with his public key. 5. Verification of Integrity: After decryption, Alice obtains the digest. She then hashes the received message using the same algorithm and compares her result to the decrypted digest. * Equality: If the digests are equal, Alice is confident the message is authentic and unaltered. * Inequality: If the digests differ, the message was modified after it was signed. * Note on Privacy: In this standard process, the message itself is sent in cleartext. To ensure confidentiality, Mr. Instructor would need to encrypt the message using Alice’s public key in addition to signing it.
Case Study: Anna and Omar: * If Anna receives a message digitally signed by Omar, her computer must perform a specific verification routine: it must decrypt the signature using Omar’s public key and then compare that result to the result of hashing the message itself.
Benefits and Limitations of Digital Signatures: * Benefits: * Sender Verification: Confirms the identity of the person from whom the message originated. * Nonrepudiation: Prevents the sender from claiming the signature was forged or disowning the message. * Integrity: Proves the message has not been altered since the moment of signing. * Weaknesses: * The signature only proves who owns the private key, not the real-world identity of the person using it. In a network of millions, an attacker could distribute a public key while falsely claiming to be Mr. Instructor.
Digital Certificates and Certificate Authorities (CA)
The Trusted Third Party Solution: * To prevent impersonation, a trusted third party is used to associate a person with their public key. * An analogy is a university ID card: if Alice trusts the university and its stamp, and the card shows Mr. Instructor’s public key, the problem of identity is solved.
Structure of a Digital Certificate: * A digital certificate serves as a container for a public key and can identify users, servers, or applications. * Standard contents include: * The owner’s name or alias. * The owner’s public key. * The name of the issuer (the Certificate Authority). * The serial number of the certificate. * The expiration date of the public key. * User-supplied info (email, postal address, registration details). * The digital signature of the issuer.
Verifying Identity via Certificates: * Mr. Instructor requests a certificate from a trusted third party. * The third party verifies his identity, hashes his info and public key, and encrypts that digest with the third party's private key. * Alice verifies the certificate by using the third party’s public key. If she can decrypt it and the hash matches, she knows the information is legitimate and has not been tampered with.
Certificate Authorities (CA) and CSR: * A user must generate a key pair and complete a Certificate Signing Request (CSR) containing their info and public key. * The CSR is processed by an intermediate CA, which authenticates the user via phone, email, documents, or in-person verification.
Trust Models and Public Key Infrastructure (PKI)
Types of Trust Models: * Direct Trust: One individual knows the other directly. * Third-party Trust: Two individuals trust each other because of a mutual trust in a third party. * Hierarchical Trust Model: Uses a single hierarchy with a single master CA known as the Root. * Distributed Trust Model: Utilizes multiple CAs to sign certificates.
Certificate Chaining: * Chaining creates a path from a few trusted Root CAs to many intermediate CAs. * The endpoint is the user's digital certificate (e.g., a website's certificate). * Each certificate is signed by the entity one level higher in the chain. * Root Certificates: These are self-signed because no higher authority exists above the Root CA.
Public Key Infrastructure (PKI) Framework: * PKI defines mechanisms for the secure creation, storage, exchange, and destruction of digital certificates and keys. * Storage: Public keys are embedded in certificates; private keys are stored on local systems (software-based) or hardware (smart cards, tokens). Software storage is more vulnerable to attackers. * Life Cycle Management: 1. Creation: Occurs after positive identity verification. 2. Suspension: Temporary invalidation (e.g., while an employee is on leave). 3. Revocation: Permanent invalidation before expiration. 4. Expiration: The point at which the key can no longer be used.
Certificate Management and Revocation: * Certificate Repository (CR): A public centralized directory for viewing certificate status. * Certificate Revocation List (CRL): A list of certificates that are no longer valid due to loss of private key, change in user details, or decommissioning. Many CAs offer online CRL queries by serial number.
Cryptographic Security Protections and States
Core Protections: * Confidentiality: Ensuring only authorized parties view data. * Integrity: Ensuring data remains correct and unaltered. * Authentication: Verifying the sender's identity. * Nonrepudiation: Ensuring a user cannot deny performing an action. * Obfuscation: Making data unclear to others; here, the obscurity of the key protects the data.
Data States: * In Transit: Data moving across a network. * In Use: Data currently being processed. * At Rest: Stored data.
Encryption Tools: * Software: VeraCrypt, Windows BitLocker, Apple’s FileVault for files or full hard drives. * Hardware: Self-Encrypting Drives (SED) and Hardware Security Modules (HSM).
Cryptographic Protocols
Secure Socket Layer (SSL) and Transport Layer Security (TLS): * SSL: An early protocol (current version v). Vulnerable to SSL Stripping. * SSL Stripping Sequence: 1. User sends an unsecured HTTP request. 2. Server redirects with code or to an HTTPS page. 3. The attacker intercepts the redirect to maintain an unsecured HTTP connection with the user while establishing HTTPS with the server, viewing all user responses in plaintext. * TLS: Replacement for SSL. Versions v and higher are more secure; current version is v.
Secure Shell (SSH): * An encrypted alternative to Telnet for remote computer access (Linux/UNIX-based). * Suite of three utilities: slogin (secure login), ssh (command execution), and scp (secure file copy). * Uses digital certificates for authentication and encrypts passwords.
HTTPS and S/MIME: * HTTPS: HTTP sent over SSL or TLS. Uses port (regular HTTP uses port ). Indicated by a padlock in the browser address bar. * S/MIME (Secure/Multipurpose Internet Mail Extensions): Standard for organizing and securing email. Allows for both encryption and digital signatures within the message body.
SRTP and IPsec: * SRTP (Secure Real-time Transport Protocol): Adds authentication and confidentiality to Voice over IP (VoIP) communications. * IPsec (Internet Protocol Security): * Security suite for IP communications that encrypts and authenticates every packet. * Implemented in the OS or hardware (routers/firewalls), making it transparent to users and applications. * Three Key Protocols: 1. Authentication Header (AH): Authenticates source by encrypting the header. 2. Encapsulating Security Payload (ESP): Encrypts the packet for confidentiality. 3. ISAKMP/Oakley: Generates the shared key and authenticates the user. * Encryption Modes: * Transport Mode: Encrypts ONLY the data portion; header is unencrypted. * Tunnel Mode: Encrypts BOTH the header and the data portion.