Merge branch 'main' of https://git.trance-0.com/Trance-0/NoteNextra-origin

content/CSE4303/CSE4303_L14.md

@@ -0,0 +1,156 @@
+# 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
+
+

content/CSE4303/_meta.js

@@ -18,4 +18,5 @@ export default {
     CSE4303_L11: "Introduction to Computer Security (Lecture 11)",
     CSE4303_L12: "Introduction to Computer Security (Lecture 12)",
     CSE4303_L13: "Introduction to Computer Security (Lecture 13)",
+    CSE4303_L14: "Introduction to Computer Security (Lecture 14)",
 }