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] 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)", }