updates
This commit is contained in:
131
content/CSE4303/CSE4303_L14.md
Normal file
131
content/CSE4303/CSE4303_L14.md
Normal file
@@ -0,0 +1,131 @@
|
||||
# CSE4303 Introduction to Computer Security (Lecture 14)
|
||||
|
||||
## Cryptography applications
|
||||
|
||||
### Crypto summary
|
||||
|
||||
- Cryptographic goals
|
||||
- Confidentiality
|
||||
- Symmetric-key ciphers
|
||||
- Block ciphers
|
||||
- Stream ciphers
|
||||
- Public-key ciphers
|
||||
- Data integrity
|
||||
- Arbitrary length hash functions
|
||||
- Message Authentication Codes (MACs)
|
||||
- Digital signatures
|
||||
- Authentication
|
||||
- Entity authentication
|
||||
- Authentication primitives
|
||||
- Message authentication
|
||||
- MACs
|
||||
- Digital signatures
|
||||
- Non-repudiation
|
||||
- Digital signatures
|
||||
|
||||
### Overview
|
||||
|
||||
- Digital certificates
|
||||
- PKI
|
||||
- Intentional MITMs
|
||||
- Other uses
|
||||
- Authentication (...of users, not data)
|
||||
- SSH keys
|
||||
- Time-based One-Time Password (TOTP)
|
||||
- Ransomware
|
||||
- Post-Quantum (PQ) crypto
|
||||
- Zero-Knowledge (ZK) proofs
|
||||
- Homomorphic encryption
|
||||
|
||||
### Recall: key-exchange challenge
|
||||
|
||||
- No matter the cipher, **algorithm** is known but **key** must remain secret
|
||||
- (Security principle: open design)
|
||||
- Symmetric-key system: entire key remains secret
|
||||
- Public-key scheme: private keys remain secret
|
||||
- Q: before secure channel established, how to **reliably exchange** symmetric keys? How to reliably exchange public keys?
|
||||
- Symmetric keys: via public/private keys
|
||||
- Public keys: web of trust (e.g. GPG), what else?
|
||||
|
||||
As presented, the protocol is insecure against active attacks
|
||||
|
||||
MiTM can insert and create 2 separate secure sessions
|
||||
|
||||
### Public-key distribution: digital certificates
|
||||
|
||||
- Common public-key object
|
||||
- Goal: bind identity to public key
|
||||
- Contents:
|
||||
- ID/key tuple
|
||||
- Digital signature of some trusted signing authority: provides integrity/authenticity "guarantees" (under proper assumptions)
|
||||
- Implementation:
|
||||
- Can be chained: e.g. certificate for key of interest signed by Certificate Authority $CA_N$, cert for $CA_N$'s key signed by $CA_{N-1}$, ..., certificate for $CA_2$'s key signed by $CA_1$ (root CA), root CA's key pre-loaded in OS
|
||||
- Allows for a hierarchy
|
||||
- Requires entity to gain trust of signing authority and obtain certificate
|
||||
|
||||
### Defeating MITM using Digital Certificates
|
||||
|
||||
- Alice goes to a **trusted party** to get a certificate.
|
||||
- After verifying Alice's identity, the trusted party issues a certificate **signed by them** with Alice's name and her public key.
|
||||
- Alice sends the entire certificate to Bob.
|
||||
- Bob verifies the certificate using the trusted party's public key (i.e. he checks the **signature** on the cert).
|
||||
- Bob now knows the **true owner** of a public key.
|
||||
|
||||
### Public key infrastructure
|
||||
|
||||
- Certificate Authority (CA): a trusted party responsible for verifying the identity of users and binding the verified identity to public keys by issuing signed certificates to them
|
||||
- Digital Certificate: a document certifying that the public key included inside does belong to the identity described in the document (signed by CA)
|
||||
- Standard governing certs: X.509
|
||||
|
||||
### HTTPS layers of trust
|
||||
|
||||
- Data
|
||||
- Trust data b/c it's encrypted by session key
|
||||
- Session Key
|
||||
- Trust session key b/c it was exchanged via public-key scheme
|
||||
- Public Key
|
||||
- Trust public key b/c it's in a certificate
|
||||
- Certificate
|
||||
- Trust certificate b/c it's signed by chain of CAs, ending with root CA
|
||||
- Certificate Authorities
|
||||
- Trust root CA's sig b/c it's embedded in browser/OS
|
||||
- Browser/OS ...
|
||||
- Trust browser/OS b/c
|
||||
- we trust whoever installed the browser/OS
|
||||
- and we trust the hardware that runs the OS
|
||||
- (note: mechanisms for justifying these trusts exist too)
|
||||
- Hardware
|
||||
|
||||
#### Application: PKI for public-key distribution
|
||||
|
||||
- Q: How are encrypted communications usually sent across a network? (e.g. https traffic)
|
||||
- A: Multi-part strategy
|
||||
- 1. Use symmetric-key cipher for encrypting traffic (speed advantage)
|
||||
- 2. Use public-key cipher for exchanging symmetric key values (authenticity, consistency)
|
||||
- 3. Use public-key infrastructure (PKI) to certify public keys (using certificates)
|
||||
- Full details and data traces: First Few Milliseconds of a TLS 1.2 Connection (2017)
|
||||
- [demo: ciphers currently used to encrypt session in Firefox, Chrome]
|
||||
- [demo: root CAs currently trusted]
|
||||
- How to mitigate attacks?
|
||||
- Revocation cert
|
||||
- Real attacks
|
||||
- DigiNotar attacked 2011: issued fraudulent certs for, e.g., google.com
|
||||
- WoSign 2016: issued certs to domains rather than subdomains
|
||||
|
||||
#### Legitimate (?) MITMs in PKI: private root certs
|
||||
|
||||
- Recent trend: entity (company/ISP/govt) installs root cert on user's system (as requirement for access), and possibly accompanying app
|
||||
- Entity intercepts all secure sessions from user and MITMs them using root cert
|
||||
- Entity then has access to all user's traffic
|
||||
- Possibly legitimate uses:
|
||||
- Enforce web usage policies: e.g. no gaming/social networking during work
|
||||
- Enhance security: scan traffic for malware, phishing, etc. and respond
|
||||
- Possibly illegitimate uses:
|
||||
- Record user's traffic, browsing habits, personal data
|
||||
- Sell data to third party
|
||||
- Censor content
|
||||
- More info:
|
||||
- How to tell whether your https session is being MITM'ed
|
||||
- Certificate hash lookup page
|
||||
- Kazakhstan's ongoing MITM saga
|
||||
|
||||
@@ -18,4 +18,5 @@ export default {
|
||||
CSE4303_L11: "Introduction to Computer Security (Lecture 11)",
|
||||
CSE4303_L12: "Introduction to Computer Security (Lecture 12)",
|
||||
CSE4303_L13: "Introduction to Computer Security (Lecture 13)",
|
||||
CSE4303_L14: "Introduction to Computer Security (Lecture 14)",
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user