From f37253b47184db1f72ec84e0800cfbb126e5091d Mon Sep 17 00:00:00 2001 From: Zheyuan Wu <60459821+Trance-0@users.noreply.github.com> Date: Tue, 17 Mar 2026 12:36:05 -0500 Subject: [PATCH 1/2] updates --- content/CSE4303/CSE4303_L14.md | 131 +++++++++++++++++++++++++++++++++ content/CSE4303/_meta.js | 1 + 2 files changed, 132 insertions(+) create mode 100644 content/CSE4303/CSE4303_L14.md diff --git a/content/CSE4303/CSE4303_L14.md b/content/CSE4303/CSE4303_L14.md new file mode 100644 index 0000000..419bae5 --- /dev/null +++ b/content/CSE4303/CSE4303_L14.md @@ -0,0 +1,131 @@ +# 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 + diff --git a/content/CSE4303/_meta.js b/content/CSE4303/_meta.js index d62ca52..77badba 100644 --- a/content/CSE4303/_meta.js +++ b/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)", } From e1ed310a2ec6ff9bd855ca766b6836cb9929cfbc Mon Sep 17 00:00:00 2001 From: Zheyuan Wu <60459821+Trance-0@users.noreply.github.com> Date: Tue, 17 Mar 2026 13:30:41 -0500 Subject: [PATCH 2/2] Update CSE4303_L14.md --- content/CSE4303/CSE4303_L14.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/content/CSE4303/CSE4303_L14.md b/content/CSE4303/CSE4303_L14.md index 419bae5..5c5ee04 100644 --- a/content/CSE4303/CSE4303_L14.md +++ b/content/CSE4303/CSE4303_L14.md @@ -129,3 +129,28 @@ MiTM can insert and create 2 separate secure sessions - 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 + +