Merge branch 'main' of https://git.trance-0.com/Trance-0/NoteNextra-origin
This commit is contained in:
Zheyuan Wu
72
content/CSE4303/CSE4303_L15.md
Normal file
72
content/CSE4303/CSE4303_L15.md
Normal file
@@ -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
|
||||
160
content/CSE4303/CSE4303_L16.md
Normal file
160
content/CSE4303/CSE4303_L16.md
Normal file
@@ -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)
|
||||
|
||||
|
||||
|
||||
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
|
||||
@@ -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)"
|
||||
}
|
||||
|
||||
@@ -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$.
|
||||
<details>
|
||||
<summary>Proof: part 2</summary>
|
||||
|
||||
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}
|
||||
|
||||
Reference in New Issue
Block a user