Lesson Notes
Advanced Crypto & Disk Encryption
Module 5: Defensive Strategies. Full-disk (LUKS, BitLocker). PKI/certificates (OpenSSL self-signed). Weak keys, padding oracles. Lab: HTTPS on local Apache.
Module 5: Advanced Crypto & Disk Encryption — Comprehensive Theory
This lesson extends encryption from single-file and transport (TLS) to full-disk encryption (data at rest) and to server identity (PKI and HTTPS). You will learn how LUKS works on Linux and BitLocker on Windows, how Public Key Infrastructure (PKI) and certificates bind identities to public keys, and how to generate and use self-signed certificates with OpenSSL for testing. You will also see why weak keys, predictable IVs, and vulnerable padding (e.g. padding oracle attacks) can break security. The lab includes configuring HTTPS on a local Apache server with a self-signed certificate and verifying the connection in the browser.
Full-Disk Encryption: LUKS and BitLocker in Detail
Full-disk encryption (FDE) encrypts an entire disk or partition so that if the device is lost or stolen, the data cannot be read without the key or passphrase. LUKS (Linux Unified Key Setup) is the standard on Linux: it defines a header on the volume that stores encrypted key material; you unlock the volume with a passphrase or key file, which decrypts the volume key. LUKS supports multiple key slots (e.g. passphrase + recovery key) and secure erasure (overwrite key slots). BitLocker is the Windows equivalent: it can use a TPM (Trusted Platform Module) to bind the key to the hardware, or a PIN/password, or a recovery key. Both rely on strong passphrases and safe key management—if the key is lost, the data is unrecoverable. FDE does not protect against malware or an attacker with the key (e.g. after login); it protects against physical theft or unauthorized access to the raw disk.
PKI: Certificates, CAs, and Trust
Public Key Infrastructure (PKI) binds public keys to identities (e.g. a hostname or organization) using certificates. A certificate contains the public key, the identity, validity dates, and a signature from a Certificate Authority (CA). Browsers and OSs ship with a list of trusted root CAs; they verify that a server's certificate is signed by a trusted CA (or a chain to a trusted root) and that the identity matches (e.g. hostname). For testing or internal use, you can create a self-signed certificate: you act as your own CA. OpenSSL: openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365. The browser will warn because the cert is not from a trusted CA; you can add an exception to test HTTPS. In production, use certificates from a public CA (Let's Encrypt, DigiCert, etc.) or an enterprise internal CA.
Common Crypto Failures: Weak Keys, IVs, and Padding
Weak or reused keys: if the key is guessable or reused across contexts, confidentiality can be broken. Use cryptographically random key material and key derivation (e.g. PBKDF2, Argon2 for passphrases). Predictable or reused IVs: in CBC mode, the IV must be unique and unpredictable per encryption; reuse or predictable IVs can leak information. Padding oracle: in CBC decryption, if the server reveals whether padding is valid (e.g. different error message), an attacker can decrypt ciphertext block by block. Defenses: use AEAD (e.g. GCM), which does not use padding, or ensure the server does not leak padding validity. Key management: secure generation, storage, rotation, and destruction are part of a full crypto strategy.
Apache HTTPS Lab and Verification
Configure Apache to listen on 443 and use your self-signed cert (SSLCertificateFile, SSLCertificateKeyFile). Restart Apache and open https://localhost in the browser. You will see a certificate warning (untrusted CA or hostname mismatch); accept the exception for lab use only. Verify in the browser that the connection is HTTPS (lock icon, certificate details). This demonstrates how TLS is configured at the server and how client trust works. Next: pentesting methodology and where cipher enumeration fits in recon.
Key Takeaway for Lesson 20
FDE (LUKS, BitLocker) protects data at rest; PKI and certificates establish server identity for HTTPS. Use self-signed certs only for testing; avoid weak keys, predictable IVs, and padding oracles. Practice HTTPS on Apache and verify in the browser. Next: pentesting methodology and cipher enumeration in recon.