NoteNextra-origin/content/CSE4303/CSE4303_L14.md

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