# CSE4303 Introduction to Computer Security (Lecture 14)

## Cryptography applications

### Crypto summary

- Cryptographic goals
  - Confidentiality
    - Symmetric-key ciphers
      - Block ciphers
      - Stream ciphers
    - Public-key ciphers
  - Data integrity
    - Arbitrary length hash functions
    - Message Authentication Codes (MACs)
    - Digital signatures
  - Authentication
    - Entity authentication
      - Authentication primitives
    - Message authentication
      - MACs
      - Digital signatures
  - Non-repudiation
    - Digital signatures

### Overview

- Digital certificates
  - PKI
  - Intentional MITMs
  - Other uses
- Authentication (...of users, not data)
  - SSH keys
  - Time-based One-Time Password (TOTP)
- Ransomware
- Post-Quantum (PQ) crypto
- Zero-Knowledge (ZK) proofs
- Homomorphic encryption

### Recall: key-exchange challenge

- No matter the cipher, **algorithm** is known but **key** must remain secret
  - (Security principle: open design)
  - Symmetric-key system: entire key remains secret
  - Public-key scheme: private keys remain secret
- Q: before secure channel established, how to **reliably exchange** symmetric keys? How to reliably exchange public keys?
  - Symmetric keys: via public/private keys
  - Public keys: web of trust (e.g. GPG), what else?

As presented, the protocol is insecure against active attacks

MiTM can insert and create 2 separate secure sessions

### Public-key distribution: digital certificates

- Common public-key object
  - Goal: bind identity to public key
  - Contents:
    - ID/key tuple
    - Digital signature of some trusted signing authority: provides integrity/authenticity "guarantees" (under proper assumptions)
  - Implementation:
    - Can be chained: e.g. certificate for key of interest signed by Certificate Authority $CA_N$, cert for $CA_N$'s key signed by $CA_{N-1}$, ..., certificate for $CA_2$'s key signed by $CA_1$ (root CA), root CA's key pre-loaded in OS
    - Allows for a hierarchy
    - Requires entity to gain trust of signing authority and obtain certificate

### Defeating MITM using Digital Certificates

- Alice goes to a **trusted party** to get a certificate.
- After verifying Alice's identity, the trusted party issues a certificate **signed by them** with Alice's name and her public key.
- Alice sends the entire certificate to Bob.
- Bob verifies the certificate using the trusted party's public key (i.e. he checks the **signature** on the cert).
- Bob now knows the **true owner** of a public key.

### Public key infrastructure

- Certificate Authority (CA): a trusted party responsible for verifying the identity of users and binding the verified identity to public keys by issuing signed certificates to them
- Digital Certificate: a document certifying that the public key included inside does belong to the identity described in the document (signed by CA)
  - Standard governing certs: X.509

### HTTPS layers of trust

- Data
  - Trust data b/c it's encrypted by session key
- Session Key
  - Trust session key b/c it was exchanged via public-key scheme
- Public Key
  - Trust public key b/c it's in a certificate
- Certificate
  - Trust certificate b/c it's signed by chain of CAs, ending with root CA
- Certificate Authorities
  - Trust root CA's sig b/c it's embedded in browser/OS
- Browser/OS ...
  - Trust browser/OS b/c
    - we trust whoever installed the browser/OS
    - and we trust the hardware that runs the OS
    - (note: mechanisms for justifying these trusts exist too)
- Hardware

#### Application: PKI for public-key distribution

- Q: How are encrypted communications usually sent across a network? (e.g. https traffic)
- A: Multi-part strategy
  - 1. Use symmetric-key cipher for encrypting traffic (speed advantage)
  - 2. Use public-key cipher for exchanging symmetric key values (authenticity, consistency)
  - 3. Use public-key infrastructure (PKI) to certify public keys (using certificates)
- Full details and data traces: First Few Milliseconds of a TLS 1.2 Connection (2017)
- [demo: ciphers currently used to encrypt session in Firefox, Chrome]
- [demo: root CAs currently trusted]
- How to mitigate attacks?
  - Revocation cert
- Real attacks
  - DigiNotar attacked 2011: issued fraudulent certs for, e.g., google.com
  - WoSign 2016: issued certs to domains rather than subdomains

#### Legitimate (?) MITMs in PKI: private root certs

- Recent trend: entity (company/ISP/govt) installs root cert on user's system (as requirement for access), and possibly accompanying app
- Entity intercepts all secure sessions from user and MITMs them using root cert
- Entity then has access to all user's traffic
- Possibly legitimate uses:
  - Enforce web usage policies: e.g. no gaming/social networking during work
  - Enhance security: scan traffic for malware, phishing, etc. and respond
- Possibly illegitimate uses:
  - Record user's traffic, browsing habits, personal data
  - Sell data to third party
  - Censor content
- More info:
  - How to tell whether your https session is being MITM'ed
  - Certificate hash lookup page
  - Kazakhstan's ongoing MITM saga

#### Related privacy question: visibility

- Question: should govt agencies (including law enforcement) have access to encrypted communications?
  - One "yes" argument: helps catch criminals, prevent terrorist attacks, etc.
  - One "no" argument: invades privacy, gives too much eavesdropping power
- Relevant history / case studies:
  - Munitions restrictions on crypto circa late 1990's: DES
  - Phil Zimmerman and PGP: e-mail encryption, govt attempts to suppress
  - Edward Snowden revelations 2013: fears of privacy abuse are well-founded
  - RSA Sec's use of NIST-recommended PRNG w/ECC: was apparently an NSA backdoor
  - Syed Farook ("San Bernardino shooter") case 2015: FBI pressure on Apple to unlock user's iPhone
    - Apple resisted
    - Never resolved legally: FBI found 3rd party to grant access
  - GCHQ "ghost protocol" proposal 2018
    - Don't weaken encryption, but secretly add government to encrypted conversation at will
      - Add extra private key to encrypted convos; suppress notifications about new user being added to convo
    - Condemned by big tech companies June 2019
- Question: should private companies have access to encrypted communications, or just metadata, or neither?
- Relevant history / case studies:
  - Zoom end-to-end encryption [Dec 2022 status]
    - Note: without E2EE, Zoom holds keys but never decrypts conversations
  - Facebook/WhatsApp terms of service update 2021 [Wired mag article]
    - Note: WhatsApp still has E2EE for messages, but shares metadata