Security through obscurity

• The use of secrecy to hide the cryptographic system being used
  • Contrast this with algorithms such as RSA, which are publically analyzed
• The problems is that somebody will figure out how it works ("many eyes make all bugs shallow" - Linus Torvalds)
  • And then, if there is a flaw (due to lack of peer review), the system is vulnerable
• Reference

Block-ciphers vs. stream ciphers

• Block ciphers require a block of text (perhaps 1 Kb, for example)
  • Reference
• Stream ciphers encrypt data as it is provided, character-by-character
  • I prefer the name 'character cipher' over 'stream cipher'
  • Reference

Cipher Taxonomy

• Reference

One-time pad (OTP)

• A substitution cipher
• Take a random string that is as long as the plain text you want encrypt
  • Use modular arithmetic (or XOR, or Vigenere) to determine the encrypted version
  • Plain text: helloworld
  • One-time pad: zdxwhtsvtv
  • Encrypted: hijiwqhnfz
• Reference

One-time pad (OTP) analysis

• Pros
  • Proven to be perfectly secure if:
    • the pad is truly random
    • the pad is only used once
    • the pad is kept secret
  • This, it is the ONLY cryptosystem with perfect secrecy
  • It can be performed by hand
• Cons:
  • Good for short messages; it's hard to transport large pads (i.e. network communication)
  • Does not provide message authentication
  • How do you get the pad to the recipient?

Re-using a one-time pad

Use an OTP:	⊕ =
Re-use the same OTP:	⊕ =
Extract the images:	⊕ =

This example from StackExchange

Secret key cryptography

• The function and/or key to encrypt/decrypt is a secret
• (Hopefully) only known to the sender and recipient
• The same key encrypts and decrypts
• How do you get the key to the recipient?
• Also called symmetric cryptography
  • As it's the same key that both encrypts and decrypts
• Example algorithms: AES, DES

Public key cryptography

• Everybody has a key that encrypts and a separate key that decrypts
• They are not interchangable!
• The encryption key is made public
• The decryption key is kept private
• Example algorithms: RSA, ECDSA

Public key cryptography goals

• Key generation should be relatively easy
• Encryption should be easy (polynomial time)
• Decryption should be easy (polynomial time)
  • With the right key!
• Cracking should be very hard (exponential time)
• Mathematical concepts need to used where the operations to do the first three are "easy" and the operation to perform the last one is "hard"

Hard versus Easy Math

• Integer factorization
  • Generating a prime number is (relatively) easy
  • Factoring an integer, when there are not small prime factors, is hard
• Discrete logs
  • Computing $x = a^b\text{ mod }c$ is (relatively) easy
  • Computing $a$ when given $x$, $b$, and $c$, and you know $x = a^b\text{ mod }c$, is hard
• Elliptic curves
  • More on this next...

Elliptic curves

Elliptic curves

Hard versus Easy Math

• Integer factorization
  • Generating a prime number is (relatively) easy
  • Factoring an integer, when there are not small prime factors, is hard
• Discrete logs
  • Computing $x = a^b\text{ mod }c$ is (relatively) easy
  • Computing $a$ when given $x$, $b$, and $c$, and you know $x = a^b\text{ mod }c$, is hard
• Elliptic curves
  • Adding points together is (relatively) easy
    • Repeated efficient adding yields multiplication of a point by a scalar: $P=d \otimes G$
  • Computing $d$ when you are given $G$ and $P$ and you know $P=d \otimes G$, is hard

Review: RSA

• Uses prime numbers, integer factorization, and discrete logs
• Key generation:
  • Generate two large primes $p$ and $q$ and compute $n=p \ast q$
  • Choose $1 < e < n$ which is relatively prime to $(p-1)(q-1)$ (65537 is almost always chosen)
  • Compute $d$ such that $d * e \equiv 1 (mod (p-1)(q-1))$
    • That's a discrete log
• Encryption:
  • Put into blocks, padding as necessary
  • Encryption formula is $c = m^e\text{ mod }n$
• Decryption
  • Decryption formula is $m = c^d\text{ mod }n$

Security

DH key exchange example

From Wikipedia; blue are public, red are secret

1. Alice and Bob agree to use a modulus p = 23 and base g = 5 (which is a primitive root modulo 23).
2. Alice chooses a secret integer a = 4, then sends Bob A = g^a mod p
   • A = 5⁴ mod 23 = 4
3. Bob chooses a secret integer b = 3, then sends Alice B = g^b mod p
   • B = 5³ mod 23 = 10
4. Alice computes s = B^a mod p
   • s = 10⁴ mod 23 = 18
5. Bob computes s = A^b mod p
   • s = 4³ mod 23 = 18
6. Alice and Bob now share a secret (the number 18)

Colors in video (at 2:43)

If that doesn't work, try the direct Youtube link, but start at 2:43

DH key exchange in practical use

• Used in many cryptographic protocols
  • Including ones we will see shortly
• Uses very large numbers created with a very good pseudo-random number generator

MITM versus DH key exchange?

• Possible if Eve actively controls the communication medium
• If s/he is only a passive listener, then it is not possible
• How to avoid an active compromiser:
  • Post on a public forum
  • Use communication methods s/he can't compromise, such as shortwave radio
• Recap:
  • It is secure against an eavesdropper
    • Even if transmitted in plaintext
  • But not against somebody who can modify the messages

Definition

• A certificate is:
  • A public key
  • Information about the key (algorithm used, version number, etc.)
  • An identity (hostname, individual, etc.)
  • Other meta-data (expiration date, etc.)
  • A signature from a certificate authority
• Most common format is X.509

Diagram of an X.509 cert

Certificate validity

• All certificates are signed with the (private) key of a certificate authority (CA)
  • Their public keys are well known, and are hard-coded into browsers
  • Or determined by key exchange protocols discussed in this slide set
• One can verify such a certificate by the (known) public key of the CA
• One can "self sign" a certificate, but modern browsers typically won't allow viewing without manual exceptions

Certificate Chains

An entity (such as virginia.edu) can hold an intermediate certificate, which allows it to sign for entities in its division (such as news.virginia.edu)

Certificate Authorities (CAs)

• By definition, they have a so-called root certificate
  • Although it may not be trusted by anybody else
• Any CA can "vouch" (i.e., sign) for any certificate
  • For any website or any (likely new) CA
• Thus, the security is based on the weakest CA
• What happens if a CA is compromised or goes rogue?

CA Revocation

• This has happened! In February 2018.
  • Google to kill Symantec certs in Chrome 66, due in early 2018
  • Firefox also: Distrust of Symantec TLS Certificates
• The reason: a site called Trustico resold Symantec-signed certificates
  • The 23,000 certificates Trustico sold were "compromised"
    • They still had the private keys (a big no-no)
  • They were sold under the umbrella of Symantec, so Symantec was party at fault as well

Trusting Trust

• A server's certificate is signed by a Certificate Authority
  • Perhaps through an intermediary certificate
• So we trust the server's certificate because the CA vouches for it
• And we trust the CA because... everybody else does?
• At some point, we have to trust that the system is well designed and that it works

Root CA hack: DigiNotar (Sept 3, 2011)

• Dutch certificate authority DigiNotar suffered a security breach
• Result: ~500 fraudulent certificates issued
• Target: 300k Iranian gmail users
  • Gmail users then compromised via MITM attack
• Whodunit?
  • Dutch government's investigation stated the Iranian gov't was behind it
  • Bruce Schneier claims it was "either the work of the NSA, or exploited by the NSA" (ref); others dispute this
• Result: all DigiNotar certs were blacklisted; company closed a week later

Root CA Abuse: CNNIC (Apr 2015)

• China Internet Network Information Center (CNNIC (sic)) handles domain registry and certificates in China
  • Applied for a trusted root cert to Mozilla in 2009; later to Microsoft
• In 2015, an intermediate CA issued by CNNIC was found to have issued fraudulent certs for Google domains
  • An Egypt-based firm used it to impersonate some Google domains
• Google revoked CNNIC's root certificate
• April 2015: Google & Mozilla announced they were no longer trusting CNNIC's root cert

Root CA Misuse: WoSign and StartCom (2016/2017)

• WoSign was (is?) China's largest certificaute issuer, owned by Qihao 360
  • StartCom, an Israeli certificate authority, was acquired in secret by WoSign
• WoSign and SmartCom issued "hundreds of certificates with the same serial number in just five days"
  • Including one for GitHub
• Chrome and Mozilla revoked their root certificate recognition in 2017

Trusted root cert count

• For Apple devices: 159 as of Feb 21, 2024
• For Mozilla / Firefox: 170 as of Feb 21, 2024
• For Microsoft: 487 as of Feb 21, 2024
• Other platforms (Chrome, Android, etc.) only seem to list how to find it on the browser (Chrome) or device (Android)

SSL & TLS

• They are cryptographic protocols used to encrypt network communication
• SSL: Secure Sockets Layer
  • v1.0 never released due to flaws
  • v2.0 released in 1995; broken and not used
  • v3.0 released in 1996; broken and not used
• TLS: Transport Layer Security, the successor to SSL
  • v1.0 released Jan 1999; currently deprecated
  • v1.1 released Apr 2006; currently deprecated
  • v1.2 released Aug 2008; in widespread use
  • v1.3 released Aug 2018; currently being adopted

TLS Usage

• TLS can be implemented on top of just about any protocol
• Most common use: when implemented on top of HTTP, that yields HTTPS
• Also used for encrypting mail (SMTP)
• A programmer can use it for any other purpose

Public vs. Symmetric Cryptography

• Public key cryptosystems (such as RSA) are:
  • Very secure: one message will take all the computers in the world longer than the life of the universe to crack
  • Very slow: not feasible for real-time data transmission (downloading a large file, streaming, etc.)
• They are typically used for key exchange, and then symmetric key cryptography is used for the rest of the communication

TLS 1.2 Handshake, part 1

• Client opens a network connection to server
• Client sends hello, including a random number $R_c$ and supported ciphers
• Server responds with hello, including a random number $R_s$, selection of which client-supported cipher to use, its certificate, and requests client certificate
• Client checks server certificate, and sends its own cert, and a signature of all previous messages sent
  • Signed with the client certificate's private key
• Server checks client certificate and signature

TLS 1.2 Handshake, part 2

• Client generates $PMS$ (Pre-Master Secret) -- a session key -- and sends it to server, encrypted with server's public key
• Both sides compute $MS$ (Master Secret) from $PMS$, $R_s$, and $R_c$
• Client send a message to switch over to using the $MS$ for symmetric encryption
  • Server confirms switching over to using the $MS$ for encryption
• Both sides terminate the SSL handshake, and use $MS$ as the symmetric encryption key

TLS 1.2 pcap

• See https-tls-1.2.pcap
• It was a request to https://www.cs.virginia.edu/ computing
• Packets:
  • Client Hello is packet 8
  • Server Hello is packet 10
  • Server certificates in packet 12
  • Client certs and change to AES in packet 14
  • Server switch to AES is packet 15
  • HTTPS GET in packet 16

Is TLS 1.2 forward-secret?

Is TLS 1.2 forward-secret?

• No, it is not (generally)
• Depending on the ciphers used, if the keys are later made available, then it is NOT forward-secret
• Let's review the TLS 1.2 protocol
• What would make it forward-secret?
  • Adding in Diffe-Hellman Key Exchange (DHE)
• Some crypto protocols used are FS, but not all

TLS 1.3

• Cryptographic improvement:
  • Only allow public encryption protocols that are forward-secret (meaning: they use DHE)
• Other improvements:
  • Send more of the information as a single message, so there is less back-and-forth to the handshake
• Speed improvements:
  • Requires less messages

TLS 1.2 versus TLS 1.3

• Fewer msgs
• Speed diff: perhaps 200 ms instead of 300 ms

TLS 1.3 pcap

• See https-tls-1.3.pcap
• It was a request to https://google.com/ computing
• Packets:
  • Client Hello is packet 4
  • Server Hello is packet 6
  • "Finished" and HTTPS GET in packet 8
  • HTTPS response starts in packet 10

TLS Ciphers Supported

• In version 1.3, for key exchange, only forward-secret public key systems are supported
  • Various public key cryptosystems, but all with a secure DH key exchange
  • Version 1.2 allows many other algorithms
• Once the channel is configured, multiple algorithms are supported, the most common being AES

TLS key exchange protocols

TLS session protocols

Message authentication code (MAC)

• It's "a short piece of information used to authenticate a message" (Wikipedia)
• Like a digital signature, but:
  • uses a shared secret key, so it is faster
• Like a hash, but:
  • provides authentication, not just a message digest
  • includes the secret key, so two different connections' MAC of the same text will be different due to different secret keys
• We'll see these in detail later in this slide set

MAC uses

• Prevents replay attacks
  • A MAC includes a signature (hash, etc.), and combined with a sequence number, will prevent replaying an encrypted packet
  • But why does the sequence number alone not work?
  • Replay attacks may not be possible, depending on the IV method used
• Used for non-encrypted verification
  • To verify a large downloaded ISO file was correct

A possible MAC

• Given a message $m$ and a secret key $k$:
  • Create a new value $x = m \cdot k$
    • That's string concatenation
  • Hash that message: $h = hash(x)$
    • Use a good hash function!
  • Encrypt that hash with $k$: $mac = encrypt(h,k)$
    • Likely AES (or similar) with the shared secret key
• In one line: $mac = encrypt(hash(m \cdot k),k)$

MAC properties

• Does not encrypt the message!
  • If the connection is not encrypted, then the message is eavesdroppable
• Cannot be forged without the secret key
  • Any eavesdropper must know the secret key in order to create a valid MAC
• It is "unforgeable under chosen-message attacks"
  • Even if Eve can get Bob to send chosen text attacks, she needs the (unknown to her) secret key to generate a valid MAC
• Provides authentication (since only the other party has the secret key)

Authenticated Encryption with Associated Data (AEAD)

• MACs do not encrypt the data, and we want to do so
• If we combine encryption and a MAC, we get an AEAD
  • Assuming a few properties about the quality of the encryption and MAC function
• The "associated data" is non-encrypted data
• Usage: network packets
  • The payload is encrypted (via authenticated encryption)
  • The packet headers, which cannot always be encrypted, are the "associated data"

TLS MAC protocols

Note that even if the MAC doesn't support encryption (in the first 3 rows), the cipher (likely AES) still does

Data Encryption Standard (DES)

• Adopted in 1976, it's a private-key encryption/decryption block cipher
• Briefly, it does a lot of (invertible) bit-shifting in rounds to encrypt/decrypt a message
• How to crack?
  • It is susceptible to brute force attacks ($2^{56} = 7 * 10^{16}$ keys)
• Solution: use DES three times => "Triple DES"
  • Use a 56*3 = 168 bit key, and encrypt the message three times, once with each key

Cracking Triple DES encryption

• Brute-force attacks:
  • $2^{168}$ keys, but due to various mathematical properties, this ends up being $2^{112}$ different keys
• "The best attack known on 3-key TDES requires around $2^{32}$ known plaintexts, $2^{113}$ steps, $2^{90}$ single DES encryptions, and $2^{88}$ memory"
• NIST (National Institute of Standards and Technology) considers it secure through 2030

DES conspiracy theories

• NSA was involved with DES' creation
  • They convinced IBM to lower the key length from 128 to 64, and then to 56
  • And kept many of the details secret
  • Many well-respected people criticized the NSA for "improper interference" with the algorithm
• In 1977, Diffie and Hellman (major names in cryptography) proposed a $20 million machine that could crack a DES message in a single day
• It's known that the NSA had the budget for such a machine. But did they build it?

Advanced Encryption Standard (AES)

• The successor to DES
• Has three possible key lengths: 128, 192, and 256
• NSA approved this standard, and kept the process open
• Like DES, it's a series of (invertible) bit-shifting in rounds to encrypt/decrypt a message
• Many worry about the security of the standard
  • ... that somebody may figure a way to crack it mathematically, in particular
• Reference
• More details in the next slide column

Confusion and Diffusion

• Two properties of ciphers (Shannon, 1945)
• Confusion hides the relationship between the plaintext and the ciphertext
  • Ideally it makes the ciphertext appear random or uniform
  • Confusion only ciphers: OTP (high confusion), Caesar cipher (low confusion)
• Diffusion means a small change in the plaintext has a large change in the ciphertext
  • Changing one bit in the plaintext should change about half the bits in the cipher text, and visa-versa
  • Diffusion only ciphers: transposition cipher
• Any "reasonable" block cipher has both

Confusion and diffusion

• One time pad, stream ciphers: high confusion, no diffusion
  • High confusion: the pad makes it impossible to crack the plaintext
  • No diffusion: Changing one bit in the plaintext changes only one bit in the ciphertext
• Transposition cipher: no confusion, moderate diffusion
  • No confusion: the bytes are the same in the plaintext and ciphertext, just out of order
  • Moderate diffusion: this cipher moves things around
• Caesar cipher: moderate confusion, no diffusion
  • Moderate confusion: each letter is obscured
  • No diffusion: a change to one letter in the plaintext changes only one letter in the ciphertext

Symmetric ECB encryption

• ECB = electronic codebook
• Formally: $c_x = AES_e(m_x)$
• With no initialization vector, the same plaintext encrypts the same each time
  • No diffusion! And susceptible to replay attacks.

ECB Encryption Issues

• With small block sizes, and large areas of uniform color:
  • The original image (left)
  • Can be viewed as the middle image
  • Whereas other modes make it look more random like the right image

Cipher block chaining (CBC) mode encryption

• CBC = Cipher Block Chaining
• Formally:
  • $c_0 = AES_e(IV \oplus m_0)$
  • $c_1 = AES_e(c_0 \oplus m_1)$
  • $c_2 = AES_e(c_1 \oplus m_2)$

Cipher block chaining (CBC) mode decryption

• CBC = Cipher Block Chaining
• Formally:
  • $m_0 = IV \oplus AES_d(c_0)$
  • $m_1 = c_0 \oplus AES_d(c_1)$
  • $m_2 = c_1 \oplus AES_d(c_2)$

Cipher block chaining (CBC) mode details

• Encryption cannot be parallelized
  • Each block depends on the previous one
• But decryption can
  • As each block only depends on the previous one
• Provides only confidentiality, not integrity or authenticity
  • Confidentiality: because it's encrypted
  • No integrity: there is no hash or checksum
  • No authenticity: a replay attack could occur
    • The plaintext would be scrambled (different counter) but that might not make it "invalid"

Counter (CTR) mode encryption

• CTR = Counter
• Nonce is the same as the IV
• Formally: $c_x = AES_e(IV \cdot counter) \oplus m_x$
• This is now essentially a stream cipher
  • As the encryption is on the key, and the result is xor'ed with the plaintext

Counter (CTR) mode decryption

• CTR = Counter
• Nonce is the same as the IV
• Formally: $m_x = c_x \oplus AES_d(IV \cdot counter)$

Counter (CTR) mode details

• Both encryption and decryption can be parallelized
• Provides only confidentiality, not integrity or authenticity
  • Confidentiality: because it's encrypted
  • No integrity: there is no hash or checksum
  • No authenticity: a replay attack could occur
    • The plaintext would be scrambled (different counter) but that might not make it "invalid"
• This mode is also known as integer counter mode (ICM) and segmented integer counter (SIC) mode

CCM mode

• CCM = counter with cipher block chaining message authentication code
• A merging of the counter (CTR) and cipher block chaining (CBC) modes
• Provides the same assurances as GCM: confidentiality, integrity, authentication

TLS session protocols

• Notice the two allowed AES modes for TLS 1.3: GCM & CCM
• And the one that was allowed previously: CBC

So many encryption modes

• Confidentiality-only modes
  • Propagating cipher block chaining (PCBC)
  • Electronic codebook (ECB)
  • Cipher block chaining (CBC)
  • Cipher feedback (CFB): Full-block CFB and CFB-1, CFB-8, CFB-64, CFB-128, etc.
  • Output feedback (OFB)
  • Counter (CTR)
• Authenticated encryption with additional data (AEAD) modes
  • Galois/counter (GCM)
  • Counter with cipher block chaining message authentication code (CCM)
  • Synthetic initialization vector (SIV)
  • AES-GCM-SIV

Advanced Encryption Standard (AES)

• The successor to DES
• Has three possible key lengths: 128, 192, and 256
• NSA approved this standard, and kept the process open
• Like DES, it's a series of (invertible) bit-shifting in rounds to encrypt/decrypt a message
• Many worry about the security of the standard
  • ... that somebody may figure a way to crack it mathematically, in particular
• Reference

AES Overview

1. Determine number of rounds, $r$:
   • 10, 12, or 14 rounds for 128-bit, 192-bit, and 256-bit keys
2. KeyExpansion: derive round keys from the AES Key Round Schedule
3. Round 1: AddRoundKey: XOR with round key
4. Rounds 2 through $r-1$:
   1. SubBytes: replace bytes as per lookup table
   2. ShiftRows: transpose bytes
   3. MixColumns: matrix operation on the columns
   4. AddRoundKey
5. Final round $r$:
   1. SubBytes
   2. ShiftRows
   3. AddRoundKey

AES: SubBytes step

• Input is mapped to its mult. inverse in a finite field
• Bytes are replaced based on a fixed substitution table
  • Fixed for all of AES
• Called the Rijndael S-box

AES: ShiftRows step

• Rows are shifted cyclically to the left
• This provides diffusion

AES Overview

1. Determine number of rounds, $r$:
   • 10, 12, or 14 rounds for 128-bit, 192-bit, and 256-bit keys
2. KeyExpansion: derive round keys from the AES Key Round Schedule
3. Round 1: AddRoundKey: XOR with round key
4. Rounds 2 through $r-1$:
   1. SubBytes: replace bytes as per lookup table
   2. ShiftRows: transpose bytes
   3. MixColumns: matrix operation on the columns
   4. AddRoundKey
5. Final round $r$:
   1. SubBytes
   2. ShiftRows
   3. AddRoundKey

Message authentication code (MAC)

• It's "a short piece of information used to authenticate a message" (Wikipedia)
• Like a digital signature, but:
  • uses a shared secret key, so it is faster
• Like a hash, but:
  • provides authentication, not just a message digest
  • includes the secret key, so two different connections' MAC of the same text will be different due to different secret keys
• We'll see these in detail later in this slide set

MAC uses

• Prevents replay attacks
  • A MAC includes a signature (hash, etc.), and combined with a sequence number, will prevent replaying an encrypted packet
  • But why does the sequence number alone not work?
• Used for non-encrypted verification
  • To verify a large downloaded ISO file was correct

A possible MAC

• Given a message $m$ and a secret key $k$:
  • Create a new value $x = m \cdot k$
  • That's string concatenation
  • Hash that message: $h = hash(x)$
  • Use a good hash function!
  • Encrypt that hash with $k$: $mac = encrypt(h,k)$
    • Likely AES (or similar) with the shared secret key
• In one line: $mac = encrypt(hash(m \cdot k),k)$

MAC properties

• Does not encrypt the message!
  • If the connection is not encrypted, then the message is eavesdroppable
• Cannot be forged without the secret key
  • Any eavesdropper must know the secret key in order to create a valid MAC
• It is "unforgeable under chosen-message attacks"
  • Even if Eve can get Bob to send chosen text attacks, she needs the (unknown to her) secret key to generate a valid MAC
• Provides authentication (since only the other party has the secret key)

Encryption & Hashing Goals

• Integrity: the message canʻt be changed, maliciously or accidentally
  • Formally, a change is always detectable
• Confidentiality: the message can't be read by somebody else
  • In other words, itʻs encrypted
• Authenticity: the message came from who you think it came from
  • Formally, from an entity that has the appropriate key

Message Authentication Code (MAC)

• Like a digital signature, but with a symmetric key
• Provides the integrity and authenticity but not confidentiality
• $MAC(k,m)$ will produce a short bit string that can only be created with the key $k$ and message $m$
  • Hash-based (HMAC) example:
    • $HMAC(k,m) = SHA256(k \cdot m)$
    • Named for the algorithm used: HMAC-MD5, HMAC-SHA1, etc.
  • Cipher-based (CMAC) example:
    • $CMAC(k,m) = AES(k,m).truncate(256)$
    • Also named for the cipher used: CMAC-AES, etc.
  • GMAC uses Galois algorithm from AES-GCM

Why MACs?

• Provides integrity
  • An adversary can change the ciphertext; this change would be detected
• Provides authenticity
  • A chosen-message attack cannot succeed (canʻt create the MAC)
• Earlier implementations, with just hashes...
  • Were difficult to get right
  • Very error prone and subject to attacks

HMAC

• A MAC is a general term for a message authentication code
• A HMAC uses a hash as its algorithm
• Not all MACs use hashes
  • A CMAC uses a cipher (AES, DES, etc.) to create the code
    • Likely truncating it to the first $x$ bits
• The example algorithm a few slides back was an HMAC
• Named by their hash algorithm:
  • HMAC-MD5, HMAC-SHA1, etc.