Signing: mechanical operation that has no meaning in itself
Only someone who knows the private key can create a signature that verifies using the corresponding public key
meaning of the signature is by convention
both signer and verifier need to agree on meaning and trust the meaning is enforced locally
Using cryptography
does not reveal much information:
Alice does not know:
whether Bob recieved the message
when Bob recieved the message
how many times
whether the message is secrete
Bob does not know:
did Alice send it to Bob
who sent this message
when the message was sent
who else knows the plaintext
Eve (or enemy) ideally cannot see the pipeline (between Alice and Bob)
Public Key Infrastructure (PKI)
Alice wants to send plaintext m to Bob via a channel controlled by Eve
Alice and Bob know each other’s public keys
Alice and Bob establish a secure “pipe” (ssh, https)
Getting Public Keys
Alice and Bob need a way to exchange public keys
Alice → unencrypted message to Bob
will this ever be secure? no
Eve can get the key, and pretend to be Alice or Bob
Eve can sign messages pretending to be Alice/Bob
A \to_{K_A} &E \to_{K_{A}'} B \\
A \leftarrow_{K_{B}'} &E \leftarrow_{K_B} B
\end{aligned}$$
- This is a **problem**.
- Ideally, Alice and Bob meet in person to exchange public keys.
- can do a **cryptographic hash** of a public key
- cannot be sent out to public
### Trusted Third Party
- can instead meet with a **third party**, Charlie
- Alice + Bob have already exchange keys with Charlie
1. Alice, Bob exchange keys with Charlie
2. Charlie sends signed message w/ Alice's key to Bob
3. Charlie sends signed message w/ Bob's Key to Alice
4. Alice + Bob trust Charlie to send the real keys
$$A \leftarrow_{K_B || S_{kC}(K_B)} C \to_{K_A || S_{kC}(K_A)} $$
where $||$ is the concatenation symbol.
### Certificate (no middle man)
- can be better: Charlie can have a **certificate** that says Charlie verifies Alice's key
1. Charlie signes certificate with his private key and gives it to Alice
2. Alice sends Bob, Charlie's certificate
3. Bob verifies the signature on certificate
4. Bob trusts Charlie $\implies$ accepts public key from Alice
# PGP (Pretty Good Privacy)
- application used for signing, encrypting, and decrypting texts
- allows one user to attest to the trustworthyness of another user's public key
- public key is essentially *signatures (certificates)*
## Certificate Authorities
- trusted signers of public keys
- has a list of all trusted keys, browsers has lists of trusted CAs
- contains:
- subject (name, domain)
- issuing CA (who issued it)
- validity (how long is it good for?)
- limitations on use
- other stuff
### Transport Layer Security (TLS)
1. client says "hi" to server
2. server says "hi" to client + sends public key
3. cluent verifies the public key
4. client ecrypts a key to "server" with public key of server
5. client sends certificate (public key)
6. server verifies the client public key
7. client says they finished
8. server says they finished
9. begin exchanging messages
- **Authenticity?**
- Is the server who they say thay are? Yes
- Is the client who they say that are? No
- **Confidentiality?**
- no one but client/server can read the messages sent between them
- **Integrity?**
- no one can alter messages between client and server without being detected
- We depend on that **crytography** works, and that the CAs are reliable and the services are secure.
# Certificate Authorities
- which CA can issue a certificate for `mycompany.com`? (any, but who is legit?)
- how do site owners prove they are true owner?
- tangible evidence of *ownership* (fax documents, fee)
- **Domain Validation**: provide evidence of *control* over site domain name
- *Let's Encrypt* was a service where:
1. client gives website domain to LE
2. LE asks client to put a specific string at some random path on the domain with a signed public key
3. client does this $\to$ LE verifies, and says that they are legit
4. LE gives certificate
- can abstract it:
- Root CA signs key for Intermediate CAs, who signs keys for users or other Intermediate CAs.
- can be used for code signing
# Certificate Revocation
- what happens if someone steals your private key?
- someone can then impersonate you
- certification expirations help with this but not enough
- "window of vulnerability"
- CA, PGP PKIs support revocation
## Propagation of Revocation
- how does Bob know if Alice's key has been revoked?
- how can Bob trust Alice if it has been revoked? or hasn't?
- in *PGP*: only Alice can revoke her own key
- in *CA*: Alice asks the CA to revoke her certificate
- requires a **certification revocation list (CRL)**
- clients can download this and update their list
- *CRL* down: revoke all, or trust one
- or can use a **Online Certificate Status Protocol (OCSP)**:
- query *CA* about status of cert before trusting it
- CA gets stamps from clients that says the cert works from X to Y and has been last trusted
- use **Certificate Pinning**, remember certificate for a domain, and raise an alert if a different one is used later $\to$ very fragile (does not host roll out new cert until old one expires)
# Content Delivery Networks (CDNs)
- geographically distributed network of proxy servers
- cache content closer geographically
- improve latency
- decrease network congestion
- improve reliability and availablity
- CDNs need to convince client they are reprensenting *their* client
-