Cryptography and wireless security

This chapter covered how SSL/TLS uses cryptographic tools to secure data over the Internet and how the IEEE 802.11 wireless standard enforces security through authentication, encryption, and integrity

Chapter 5: Cryptography and wireless security

Chapter 5 explored the critical security mechanisms that protect data in transit, focusing on two essential areas: cryptography for online communications and security for wireless networks. It detailed how cryptographic tools—symmetric encryption (AES), asymmetric encryption (RSA), and hashing (SHA-256)—are combined within the SSL/TLS protocol to provide confidentiality, integrity, and authentication, explaining processes like the TLS handshake and the Diffie-Hellman key exchange. The chapter then applied these principles of authentication and encryption to the wireless domain, analyzing how the IEEE 802.11 standard forms a security framework and comparing the evolution of wireless security protocols (WPA, WPA2, WPA3) in safeguarding network access and data privacy.

The first section titled Hashing Algorithms and Message Integrity established cryptographic hashing as the foundation for ensuring message integrity. An industry-grade hashing algorithm, such as SHA-256, is defined by five key characteristics: it must be a one-way function with pre-image resistance; possess second pre-image resistance to prevent forgery; maintain collision resistance to thwart the creation of two different inputs with the same output; produce a fixed-length output regardless of input size; and exhibit the avalanche effect, where a minor change to the input creates a drastically different, unpredictable hash. These properties collectively ensure that a hash digest acts as a unique, tamper-evident fingerprint for any piece of data.

While hashing alone can verify that a message was not accidentally corrupted, it is vulnerable to malicious man-in-the-middle (MITM) attacks, where an attacker can alter both the message and its accompanying hash. To defend against active tampering and verify the sender's authenticity, a shared secret key is introduced via HMAC (Hash-based Message Authentication Code). HMAC securely combines the secret key with the message before hashing, generating a MAC (Message Authentication Code). The receiver, who holds the same key, can recompute the HMAC; a match confirms both the message's integrity and that it originated from a party possessing the secret key. For scenarios without a shared secret, digital signatures using asymmetric cryptography provide a similar guarantee of integrity and authenticity.

The section Cryptographic Encryption and Confidentiality explained the two fundamental cryptographic systems used to ensure data confidentiality: symmetric and asymmetric encryption. Symmetric encryption, exemplified by algorithms like AES-128, AES-192, and AES-256, uses a single, shared secret key for both encryption and decryption. Its mathematical operations are computationally efficient, making it the preferred choice for encrypting bulk data, though it necessitates a secure method to distribute the secret key to all communicating parties. Asymmetric encryption, using algorithms such as RSA and ECC, employs a mathematically linked pair of keys: a public key for encryption and a private key for decryption. This design eliminates the key distribution problem, as the public key can be freely shared, allowing anyone to encrypt data that only the holder of the corresponding private key can decrypt.

To leverage the strengths of both systems, hybrid encryption can be employed as a practical solution. This approach uses asymmetric encryption to securely exchange a randomly generated symmetric session key. For instance, a sender encrypts a symmetric AES key using the recipient's public RSA key. Once both parties securely possess this session key, they switch to faster symmetric encryption for the actual data transmission. This method resolves the key exchange problem inherent in symmetric encryption while maintaining the performance necessary for large-scale data confidentiality, forming the basis for secure protocols like TLS/SSL.

The section on Message Signing Using Asymmetric Keys explored digital signatures, a cryptographic technique that combines hashing and asymmetric encryption to provide non-repudiation, authentication, and message integrity. The process begins with the sender generating a cryptographic hash (e.g., SHA-256) of the message, creating a fixed-size fingerprint. This hash is then encrypted using the sender's private key—a mathematical operation often called "signing"—to produce the digital signature. The original message and this signature are sent to the recipient. Crucially, hashing the message first is essential for performance (asymmetric operations are slow), ensures compatibility with algorithms that have input size limits, and guarantees that the signature is a consistent size regardless of the original message length.

Verification is performed by the recipient using the sender's publicly available public key. The recipient decrypts the received signature with this key to extract the original hash, then independently hashes the received message. A match confirms three security properties: integrity (the message is unaltered), authentication (it originated from the possessor of the private key), and non-repudiation (the sender cannot later deny sending it). This trust model typically relies on a Public Key Infrastructure (PKI) and Certificate Authorities (CAs) to validate the binding between the public key and the sender's identity. Common signing algorithms include RSA-PSS, ECDSA, and the modern, efficient EdDSA (Ed25519), while legacy schemes like DSA and RSA-PKCS#1 v1.5 are deprecated.

The Cryptographic Authentication Methods section examined three distinct cryptographic authentication methods, each operating at different points on the spectrum of complexity and trust. Username and password authentication relies on cryptographic hashing to protect the secret; the server stores only a hash digest of the password (e.g., SHA-256, bcrypt), and the plaintext password is either hashed client-side before transmission or hashed server-side upon receipt. Pre-Shared Keys (PSKs) are symmetric secrets shared out-of-band and used for mutual authentication. Rather than transmitting the PSK directly, modern implementations derive ephemeral session keys by combining the PSK with randomly generated nonces exchanged during the handshake. This provides forward secrecy: each session uses a unique key, and compromise of a session key does not reveal the long-term PSK nor decrypt past or future sessions.

Digital certificates provide the most robust authentication framework by binding a public key to an identity through a trusted third party—a Certificate Authority (CA). Certificates serve three core cryptographic functions: authentication via proof of private key possession (challenge-response or signing handshake transcripts); key establishment during the TLS handshake, where the certificate's public key either encrypts a pre-master secret (RSA) or verifies signed Diffie-Hellman parameters (ECDHE); and integrity through digital signatures on handshake messages (preventing tampering) and HMAC or AEAD modes (e.g., AES-GCM) on application data. The TLS handshake thus achieves server authentication, secure session key agreement, and cipher suite negotiation, with trust anchored in pre-installed CA root certificates. Certificates are foundational to HTTPS, email security (S/MIME), and code signing, providing non-repudiation and verifiable identity that PSKs and passwords cannot offer in open, untrusted environments.

The next section covered The SSL/TLS Handshake, a sub-protocol of the SSL/TLS protocol. The SSL/TLS protocol evolved from Netscape's deprecated SSL (1990s) to the IETF-standardized TLS 1.2 (2008) and TLS 1.3 (2018). The TLS handshake establishes a secure session through three core objectives: server authentication via X.509 digital certificates, key establishment to derive a symmetric session key, and cipher suite negotiation defining algorithms for encryption (e.g., AES-256-GCM) and integrity (e.g., HMAC-SHA256). In TLS 1.2, the handshake requires multiple round trips: after ClientHello/ServerHello negotiation, the server presents its certificate and, depending on the cipher suite, either sends a ServerKeyExchange message with Diffie-Hellman parameters (signed with its private key) or relies on RSA key transport where the client encrypts a pre-master secret with the server's public key. The client validates the certificate against trusted Certificate Authorities (CAs), checking revocation status via CRL or OCSP, and both parties derive session keys from the exchanged secrets.

TLS 1.3 fundamentally streamlines and hardens this process. It mandates ephemeral Diffie-Hellman (ECDHE/DHE) key exchange for all connections, guaranteeing Perfect Forward Secrecy (PFS)—past sessions remain secure even if the server's long-term private key is later compromised. The handshake completes in a single round trip: the client sends its DH public key share in the key_share extension of the ClientHello, and the server responds with its share, certificate, and a CertificateVerify message containing a digital signature over the entire handshake transcript. This signature cryptographically binds the server's authenticated identity to the specific ephemeral key exchange, preventing downgrade and man-in-the-middle attacks. Both parties independently derive symmetric session keys using a Key Derivation Function (KDF), after which encrypted application data flows using modern AEAD ciphers (e.g., AES-GCM, ChaCha20-Poly1305). Optional 0-RTT resumption allows returning clients to send encrypted data immediately but introduces replay attack risks that require application-layer mitigation.

The next section delved into How SSL/TLS uses Cryptography. SSL/TLS secures Internet communications by strategically integrating three cryptographic primitives—hashing, asymmetric encryption, and symmetric encryption—each serving distinct, non-interchangeable roles. Hashing provides integrity and authentication through three mechanisms: fingerprint verification (Certificate Authority-signed hashes of server certificates enable client trust validation), Message Authentication Codes (HMAC) (used in TLS 1.2 to append a keyed hash to each encrypted record, ensuring tamper detection), and digital signatures (handshake messages are hashed and signed with the server's private key, proving possession of the private key and ensuring non-repudiation). Asymmetric encryption enables secure key establishment and identity verification; in TLS 1.2, it is used either for direct key transport (RSA encrypting the pre-master secret) or for authenticating ephemeral Diffie-Hellman parameters. In TLS 1.3, asymmetric operations are restricted to digital signatures for authentication, with key exchange conducted entirely via ephemeral Diffie-Hellman (ECDHE) to guarantee forward secrecy. Symmetric encryption is reserved for bulk data encryption after the handshake, leveraging algorithms like AES-GCM or ChaCha20-Poly1305 that are 100–1000x faster than asymmetric cryptography, enabling efficient protection of application traffic.

The SSL/TLS protocol's security evolution is most evident in its integrity and key exchange mechanisms. In TLS 1.2, integrity is provided by HMAC-SHA256 appended to ciphertext, while encryption and authentication remain separate operations (e.g., AES-CBC + HMAC). TLS 1.3 replaces this with Authenticated Encryption with Associated Data (AEAD) ciphers (e.g., AES-GCM), which combine encryption and integrity into a single atomic operation, eliminating padding oracle vulnerabilities and reducing computational overhead. For key exchange, TLS 1.2 supports both RSA key transport (lacking forward secrecy) and ECDHE (providing forward secrecy via signed ephemeral keys). TLS 1.3 mandates ECDHE exclusively, with the server's certificate used solely to sign the handshake transcript in the CertificateVerify message. This cryptographic binding of identity to ephemeral parameters ensures that even if the server's long-term private key is later compromised, past sessions remain undecipherable. Across both versions, hashing underpins certificate fingerprints (SHA-256), key derivation (PRF/HKDF), and handshake signatures, demonstrating that TLS is not a monolithic cipher but a layered system where each cryptographic tool addresses a specific vulnerability.

The next section explored Replay Attacks and Anti-Replay Methods. Replay attacks exploit the inherent trust systems place in valid, properly formatted messages by intercepting a legitimate transmission and retransmitting it to achieve unauthorized access, fraudulent transactions, or session impersonation. The core vulnerability is not broken cryptography but the absence of freshness proofs—mechanisms that allow a receiver to distinguish a new, legitimate message from an identical but stale copy. Primary anti-replay methods include sequence number windowing, where each packet carries a monotonically increasing number and the receiver maintains a sliding window (default 64 packets) to discard duplicates; timestamps and nonces, which introduce time-sensitive or single-use random values to validate message freshness; cryptographic hashes (HMACs) that integrity-protect both the payload and its metadata (including sequence numbers) using a shared secret key; and rotating secret keys before sequence number exhaustion to invalidate any captured traffic from prior cryptographic contexts. These methods are typically deployed in combination, as sequence numbers alone are vulnerable to looping attacks in finite fields (e.g., 16-bit wraparound), while timestamps require synchronized clocks and nonces demand stateful tracking.

SSL/TLS historically faced significant replay threats that undermined its confidentiality, integrity, and authenticity guarantees. In TLS 1.2, reusable session tickets allowed an attacker to resume a session without authentication, and static RSA key exchange enabled captured ciphertext to be decrypted if the server's private key was later compromised. TLS 1.3 closes most of these vectors through mandatory ephemeral Diffie-Hellman (ECDHE) guaranteeing forward secrecy; one-time-use session tickets that force a full handshake upon replay; non-replayable handshakes where ClientHello and ServerHello carry fresh random nonces, making each handshake cryptographically unique; and the complete removal of static RSA key exchange. Additionally, TLS 1.3's strict key derivation ensures each session uses fresh, independently derived keys, rendering replayed application data undecryptable. However, replay attacks against the application layer—such as replaying an HTTP POST transaction—remain outside TLS's scope and require idempotency keys, CSRF tokens, or application-level nonces, as TLS guarantees only channel security, not message uniqueness.

The next section covered Wireless Client Authentication Methods, beginning the discussion with the IEEE 802.11 wireless standard. IEEE 802.11 provides a foundational framework for wireless security, defining three core components: client authentication, message privacy (encryption), and message integrity. The original 1997 standard offered only Open System authentication (a null authentication that merely validated 802.11 hardware) and WEP Shared Key authentication, which used a static 40- or 104-bit key for both authentication and RC4 encryption, rendering it fundamentally insecure. A critical evolution occurred with the IEEE 802.11i amendment (2004) , which introduced the Robust Security Network (RSN) framework. This established WPA2, mandating AES-CCMP encryption (combining AES counter mode for confidentiality with CBC-MAC for integrity) and dynamic key derivation via a secure 4-Way Handshake. In WPA2-Personal, the Pre-Shared Key (PSK) is never used for encryption directly; instead, it serves as the starting point for a handshake that mutually authenticates the client and AP while generating unique, ephemeral session keys. WPA3-Personal (2018) replaced PSK with Simultaneous Authentication of Equals (SAE) , a Dragonfly key exchange protocol that provides forward secrecy and resists offline dictionary attacks, addressing the primary weakness of PSK.

For enterprise environments, IEEE 802.1X provides a port-based access control framework that separates the authenticator (AP or WLC) from the authentication server (typically RADIUS). This framework leverages the Extensible Authentication Protocol (EAP) , a flexible container for carrying authentication credentials. EAP methods have evolved through several generations: LEAP (Cisco-proprietary, now deprecated) used challenge-response with dynamic WEP keys but was vulnerable to dictionary attacks; EAP-FAST improved security by establishing a protected access credential (PAC) and negotiating a TLS tunnel for inner authentication; PEAP (Protected EAP) creates a TLS tunnel authenticated by a server-side digital certificate, allowing legacy inner methods like MSCHAPv2 or GTC to run securely; and EAP-TLS (EAP Transport Layer Security) provides the strongest assurance by requiring mutual certificate-based authentication—both the RADIUS server and every client device must possess valid X.509 certificates. While EAP-TLS is considered the gold standard for wireless authentication, its implementation demands a Public Key Infrastructure (PKI) for certificate issuance and revocation, making it operationally complex but cryptographically robust against impersonation and credential theft.

The next section studied the historical and technical trajectory of Wireless Privacy and Integrity Methods. The failure of WEP's static RC4 encryption and CRC-32 integrity check necessitated an urgent, interim solution that could operate on existing legacy hardware. TKIP (Temporal Key Integrity Protocol) was designed as this stopgap, retaining the RC4 cipher but implementing critical fixes: a key mixing algorithm generating a unique 128-bit encryption key per frame, a 48-bit initialization vector (IV) to prevent IV exhaustion, and a TKIP sequence counter to enforce frame ordering and defeat replay attacks. To address WEP's complete lack of data integrity, WPA introduced the Michael MIC, a keyed Message Authentication Code (MAC) that uses a shared secret key to compute an integrity hash. Unlike unkeyed cryptographic hashes (e.g., SHA-256), which only detect accidental corruption and are trivially forged by an attacker who can recompute the hash, a keyed MAC like Michael ensures that only parties possessing the secret key can generate a valid integrity check. However, Michael was a lightweight, computationally efficient algorithm designed for legacy hardware and was subsequently found to have exploitable weaknesses, making it a temporary measure rather than a long-term solution.

The transition to robust, hardware-dependent security occurred with WPA2 and its mandatory protocol, AES-CCMP (Counter/CBC-MAC Protocol) . CCMP abandons RC4 entirely, using AES in counter mode for encryption and CBC-MAC (Cipher Block Chaining Message Authentication Code) for integrity. This dual-algorithm suite provides strong, cryptographically sound authenticated encryption, but requires dedicated hardware acceleration (AES engines) unavailable on WEP-era devices. WPA3 further advances this model with AES-GCMP (Galois/Counter Mode Protocol) , which replaces CBC-MAC with the more efficient GMAC (Galois Message Authentication Code) . GCMP performs encryption and integrity generation in a single, parallelizable operation, offering both security and performance improvements over CCMP. This progression—from TKIP's patched RC4 to CCMP's AES-CBC-MAC, and finally to GCMP's AES-Galois mode—reflects the industry's shift from backward-compatible software patches to requiring modern hardware that can execute computationally intensive but cryptographically robust algorithms at line rate.

The final section looked at Authentication and Encryption in WPA, WPA2, and WPA3. The evolution of Wi-Fi security across WPA, WPA2, and WPA3 is defined by distinct cryptographic approaches to authentication in Personal and Enterprise modes. In Personal mode, WPA and WPA2 rely on a Pre-Shared Key (PSK) derived from a passphrase via PBKDF2, used in a four-way handshake to generate session keys. This method is vulnerable to offline dictionary attacks if the handshake is captured. WPA3-Personal replaces PSK with Simultaneous Authentication of Equals (SAE), a Dragonfly key exchange protocol that provides forward secrecy and resists offline brute-force attacks by preventing an attacker from guessing the password without interacting with the live network. In Enterprise mode, all three WPA generations utilize 802.1X/EAP as the authentication framework, delegating credential verification to a RADIUS server. However, the supported EAP methods have matured: WPA-Enterprise often relied on legacy methods like LEAP (deprecated) or EAP-FAST; WPA2-Enterprise commonly deployed PEAP (server-side certificates with tunneled inner authentication); and WPA3-Enterprise continues to support EAP-TLS, which requires mutual certificate-based authentication and is considered the gold standard, while also mandating stronger cryptographic suites (e.g., 192-bit CNSA-compliant mode) for high-security deployments.

The encryption and integrity mechanisms have undergone a fundamental shift from RC4-based patching to hardware-accelerated AES. WPA employed TKIP as a stopgap, retaining the RC4 cipher but adding per-packet key mixing, a 48-bit IV, and the Michael MIC, a keyed hash for integrity. Both TKIP and Michael were ultimately deprecated due to exploitable weaknesses. WPA2 mandated AES-CCMP, which combines AES counter mode for encryption with CBC-MAC for integrity, delivering robust authenticated encryption but requiring dedicated hardware support. WPA3 advances this to AES-GCMP, replacing CBC-MAC with the more efficient Galois Message Authentication Code (GMAC) within a single, parallelizable Galois/Counter Mode operation. WPA3 also mandates Protected Management Frames (PMF) to secure deauthentication and disassociation frames, closing denial-of-service vectors. This progression—from PSK to SAE, from TKIP to AES-GCMP, and from optional to mandatory PMF—illustrates a trajectory away from backward-compatible compromises toward hardware-enforced, cryptographically modern defenses against both passive eavesdropping and active impersonation.