132 lines
5.0 KiB
Markdown
132 lines
5.0 KiB
Markdown
# 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
|
|
|