diff --git a/content/CSE4303/CSE4303_L15.md b/content/CSE4303/CSE4303_L15.md new file mode 100644 index 0000000..b42552d --- /dev/null +++ b/content/CSE4303/CSE4303_L15.md @@ -0,0 +1,64 @@ +# CSE4303 Introduction to Computer Security (Lecture 15) + +## Cryptography applications + +### Authentication (...of users, not data) + +- Traditional authentication: password-based, single-factor + - Disadvantage: convenience often chosen over security + - Weak passwords + - Password re-use: one password compromised ==> many accounts compromised + - Attack: "credential stuffing" (testing single stolen password against many accounts) + +#### SSH keys + +- Idea: relieve burden of secure passwords + - Use public/private-key auth instead (can be automated!) + - Use secure password once to exchange public key +- Protocol: challenge/response to verify possession of keys + +#### Case Study: SSH + +- SSH can use public-key based authentication to authenticate users +- Generate a pair of public and private keys: `ssh-keygen -t rsa` +- private key: `/home/seed/.ssh/id_rsa` +- public key: `/home/seed/.ssh/id_rsa.pub` +- Register public key with server: + - Send the public key file to the remote server using a secure channel + - Add public key to the authorization file `~/.ssh/authorized_keys` +- Server can use key to authenticate clients + +#### Time-based One-Time Password (TOTP) + +- Goal: provide secure 2nd factor for authentication +- Idea: + - Generate one-time (single-use) password for each login attempt + - Compute one-time password using secure HMAC with current time as a parameter +- Key used for HMAC: exchanged once at setup +- Protocol: open standard published by OATH, IETF + - HMAC-based One-Time Password (HOTP) + - e.g. $TOTP(k) = HOTP(k, C_t)$, where $C_t$ is absolute measure of current time interval + - Num digits taken from output: 6 to 10 + +### Ransomware + +- Idea: attacker encrypts victim's data with symmetric cipher, requires ransom payment to decrypt (or provide key) + - System model: any data store (company database, municipal database, user's hard drive, etc.) + - Threat model: attacker who has already compromised victim's system + - Vuln: lack of backups (or prohibitive time to restore); whatever vuln allowed attacker into system + - Surface: exposed data, and surface of original compromise + - Vector: encrypt data store and erase or replace original data store + - Mitigation/defense: keep up-to-date backups (possibly "air-gapped") in separate location; practice restoring from backups +- Enabler: anonymity of Bitcoin payments +- Recent-ish examples: + - Baltimore 2019 (didn't pay, est. $18 million to fix) + - Atlanta 2018 (~$9 million to fix) + - Lake City & Riviera City, Florida 2019 (did pay, $500,000+ apiece) + - Many others since these + - One of the top projected trends in cybersecurity in 2021 (e.g. by CSO online) + +### Post-Quantum (PQ) crypto + +### Zero-Knowledge (ZK) proofs + +### Homomorphic encryption \ No newline at end of file diff --git a/content/CSE4303/CSE4303_L16.md b/content/CSE4303/CSE4303_L16.md new file mode 100644 index 0000000..a1ffb8d --- /dev/null +++ b/content/CSE4303/CSE4303_L16.md @@ -0,0 +1,65 @@ +# CSE4303 Introduction to Computer Security (Lecture 16) + +## System security + +- Why system security / platform security? + - All code runs on some physical machine! + - The cloud is not a cloud + - Web pages are just data and code copied from a server that also manages the transfer +- Why Linux? + - Majority of web servers run Linux (esp. Cloud); popular in embedded, mobile devices + +### Operating system background + +Context: computing stack + +| Layer | Description | +| --- | --- | +| Application | Web browser, user apps, DNS | +| OS:libs | Memory allocations, compiler/linker| +| OS:kernel | Process control, networking, file system, access control| +| OS:drivers | Manage hardware| +| (Firmware) | Minimal hardware management (if no full OS)| +|Hardware | Processor, cahce, RAM, disk, USB ports| + +#### Operating systems + +- Operating System: + - Provides easier to use and high level **abstractions** for resources such as address space for memory and files for disk blocks. + - Provides **controlled access** to hardware resources. + - Provides **isolation** between different processes and between the processes running untrusted/application code and the trusted operating system. + +- Need for trusting an operating system + - Why do we need to trust the operating system? (AKA a Trusted Computing Base or TCB) + - What requirements must it meet to be trusted? + +- TCB Requirements: + - 1. Tamper-proof + - 2. Complete mediation (reference monitor) + - 3. Correct + +Isolating User Processes from Each Other + +- How do we meet the user/user isolation and separation? + - OS uses hardware support for memory protection to ensure this. + +System Calls: Going from User to OS Code + +- System calls used to transfer control between user and system code + - Such calls come through "call gates" and return back to user code. + - The processor execution mode or privilege ring changes when call and return happen. + - x86 `sysenter` / `sysexit` instructions + +## Isolating OS from Untrusted User Code + +- How do we meet the first requirement of a TCB (e.g., isolation or tamper-proofness)? + - Hardware support for memory protection + - Processor execution modes (system AND user modes, execution rings) + - Privileged instructions which can only be executed in system mode + - System calls used to transfer control between user and system code + +### Secure boot and Root of Trust (RoT) + +### Access control + +### Hazard: race conditions \ No newline at end of file diff --git a/content/CSE4303/_meta.js b/content/CSE4303/_meta.js index 77badba..ca3154f 100644 --- a/content/CSE4303/_meta.js +++ b/content/CSE4303/_meta.js @@ -19,4 +19,6 @@ export default { CSE4303_L12: "Introduction to Computer Security (Lecture 12)", CSE4303_L13: "Introduction to Computer Security (Lecture 13)", CSE4303_L14: "Introduction to Computer Security (Lecture 14)", + CSE4303_L15: "Introduction to Computer Security (Lecture 15)", + CSE4303_L16: "Introduction to Computer Security (Lecture 16)" }