updates
This commit is contained in:
64
content/CSE4303/CSE4303_L15.md
Normal file
64
content/CSE4303/CSE4303_L15.md
Normal file
@@ -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
|
||||
Reference in New Issue
Block a user