Merge branch 'main' of https://git.trance-0.com/Trance-0/NoteNextra-origin

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

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

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