diff --git a/content/CSE4303/CSE4303_L15.md b/content/CSE4303/CSE4303_L15.md new file mode 100644 index 0000000..004ba70 --- /dev/null +++ b/content/CSE4303/CSE4303_L15.md @@ -0,0 +1,72 @@ +# 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 + +- Fundamentally different computation paradigm than "classical" von Neumann or dataflow models +- Relies on properties of quantum physics to solve problems efficiently + - Superposition: state of quantum bit ("qubit") expressed by probability model over continuous range of values (vs. classic bit: 0 or 1 only) + - Like being able to operate on all possible bit combos of a register simultaneously, instead of operating on only one among all possibilities + - Entanglement: operating on one qubit affects others + + + +### 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..1cc46e3 --- /dev/null +++ b/content/CSE4303/CSE4303_L16.md @@ -0,0 +1,160 @@ +# 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 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 + + +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 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. + +Virtualization + +- OS is large and complex, even different operating systems may be desired by different customers +- Compromise of an OS impacts all applications + +Complete Mediation: The TCB + +- Make sure that no protected resource (e.g., memory page or file) could be accessed without going through the TCB +- TCB acts as a reference monitor that cannot be bypassed +- Privileged instructions + +Limiting the Damage oa a Hacked OS + +Use: Hypervisor, virtual machines, guest OS and applications + +Compromise of OS in VM1 only impacts applications running on VM1 + +### Secure boot and Root of Trust (RoT) + +Goal: create chain of trust back to hardware-stored cryptographic keys + +#### Secure enclave: overview (Intel SGX) + +![Intel SGX](https://notenextra.com/CSE4303/Intel_SGX.png) + +Goal: keep sensitive data within hardware-isolated encrypted environment + +### Access control + +Controlling Accesses to Resources + +- TCB (reference monitor) sees a request for a resource, how does it decide whether it should be granted? + - Example: Should John's process making a request to read a certain file be allowed to do so? + +- Authentication establishes the source of a request (e.g., John's UID) +- Authorization (or access control) answers the question if a certain source of a request (User ID) is allowed to read the file +- Subject who owns a resource (creates it) should be able to control access to it (sometimes this is not true) + +- Access control + - Basically, it is about who is allowed to access what. + - Two parts + - Part I - Policy: decide who should have access to certain resources (access control policy) + - Part II - Enforcement: only accesses defined by the access control policy are granted. + - Complete mediation is essential for successful enforcement + +Discretionary Access Control + +- In discretionary access control (DAC), owner of a resource decides how it can be shared + - Owner can choose to give read or write access to other users +- Two problems with DAC: + - You cannot control if someone you share a file with will not further share the data contained in it + - Cannot control "information flow" + - In many organizations, a user does not get to decide how certain type of data can be shared + - Typically the employer may mandate how to share various types of sensitive data + - Mandatory Access Control (MAC) helps address these problems + +Mandatory Access Control (MAC) Models + +- User works in a company and the company decides how data should be shared + - Hospital owns patient records and limits their sharing + - Regulatory requirements may limit sharing + - HIPAA for health information + +#### Example: Linux system controls + +Unix file access control list + +- Each file has owner and group +- Permissions set by owner + - Read, write, execute + - Owner, group, other + - Represented by vector of four octal values +- Only owner, root can change permissions + - This privilege cannot be delegated or shared +- Setid bits -- Discuss in a few slides + +Process effective user id (EUID) + +- Each process has three IDs (+ more under Linux) + - Real user ID (RUID) + - Same as the user ID of parent (unless changed) + - Used to determine which user started the process + - Effective user ID (EUID) + - From set user ID bit on the file being executed, or sys call + - Determines the permissions for process + - File access and port binding + - Saved user ID (SUID) + - So previous EUID can be restored +- Real group ID, effective group ID used similarly + +#### Weaknesses in Unix isolation, privileges + +- Shared resources + - Since any process can create files in `/tmp` directory, an untrusted process may create files that are used by arbitrary system processes +- Time-of-Check-to-Time-of-Use (TOCTTOU), i.e. race conditions + - Typically, a root process uses system call to determine if initiating user has permission to a particular file, e.g. `/tmp/X`. + - After access is authorized and before the file open, user may change the file `/tmp/X` to a symbolic link to a target file `/etc/shadow`. + +### 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)" } diff --git a/content/Math4202/Math4202_L23.md b/content/Math4202/Math4202_L23.md index 4ff60f8..0582521 100644 --- a/content/Math4202/Math4202_L23.md +++ b/content/Math4202/Math4202_L23.md @@ -29,6 +29,8 @@ $f|_{B^2}$ is a continuous map from $B^2\to \mathbb{R}^2-\{0\}$. $f|_{S^1=\partial B^2}:S^1\to \mathbb{R}-\{0\}$ **is nulhomotopic**. +> Recall that: Any map $g:S^1\to Y$ is nulhomotopic whenever it extends to a continuous map $G:B^2\to Y$. + Construct a homotopy between $f|_{S^1}$ and $g$ $$ @@ -57,10 +59,9 @@ Therefore $f$ must have a root in $B^2$.
Proof: part 2 -If \|a_{n-1}\|+\|a_{n-2}\|+\cdots+\|a_0\|< R$ has a root in the disk $B^2_R$. (and $R\geq 1$, otherwise follows part 1) - -Consider $\tilde{f}(x)=f(Rx)$. +If $\|a_{n-1}\|+\|a_{n-2}\|+\cdots+\|a_0\|< R$ has a root in the disk $B^2_R$. (and $R\geq 1$, otherwise follows part 1) +Consider $\tilde{f}(x)=f(Rx)$. $$ \begin{aligned} \tilde{f}(x) @@ -71,7 +72,7 @@ $$ $$ \begin{aligned} -\|\frac{a_{n-1}}{R}\|+\|\frac{a_{n-2}}{R^2}\|+\cdots+\|\frac{a_0}{R^n}\|&=\frac{1}{R}\|a_{n-1}\|+\frac{1}{R^2}\|a_{n-2}\|+\cdots+\frac{1}{R^n}\|a_0\|\\ +\left\|\frac{a_{n-1}}{R}\right\|+\left\|\frac{a_{n-2}}{R^2}\right\|+\cdots+\left\|\frac{a_0}{R^n}\right\|&=\frac{1}{R}\|a_{n-1}\|+\frac{1}{R^2}\|a_{n-2}\|+\cdots+\frac{1}{R^n}\|a_0\|\\ &<\frac{1}{R}\left(\|a_{n-1}\|+\|a_{n-2}\|+\cdots+\|a_0\|\right)\\ &<\frac{1}{R}<1 \end{aligned} diff --git a/public/CSE4303/Intel_SGX.png b/public/CSE4303/Intel_SGX.png new file mode 100644 index 0000000..00bc18e Binary files /dev/null and b/public/CSE4303/Intel_SGX.png differ