191 lines
4.9 KiB
Markdown
191 lines
4.9 KiB
Markdown
# Cryptographic Protocols
|
||
|
||
### Message Authentication Codes
|
||
|
||
- Provide integrity and authenticity - not confidentiality
|
||
- Protecting system files
|
||
- Ensuring messages haven’t been altered
|
||
- Calculate a keyed hash of the message, then append this to the end of the message
|
||
|
||
|
||
|
||
#### HMAC
|
||
|
||
- Double hashing in HMAC avoids length extension attacks
|
||
- $HMAC(k,m) = H((k\oplus opad) || H((k\oplus ipad)||m))$
|
||
|
||
|
||
|
||
#### Authenticated Encryption (AEAD)
|
||
|
||
- It’s common to attach MACs to the end of ciphertext, that this is now usually built into ciphers as part of AEAD mode
|
||
- You’re often able to authenticate non-encrypted “associated” data too
|
||
|
||
|
||
|
||
## Transport Layer Security
|
||
|
||
#### SSL/TLS
|
||
|
||
- TLS is a protocol that provides *authenticated* and *encrypted* sessions
|
||
- Secure Socket Layer (SSL) came first, then after `v3.0` it became TLS
|
||
- Transport Layer Security has two layers
|
||
1. The record layer
|
||
- Using established symmetric keys and other session info, will encrypt application packets, very like IPsec
|
||
2. The handshake layer
|
||
- Used to establish session keys, as well as authenticate either party - usually the server using a public key certificate
|
||
|
||
##### TLS Handshake
|
||
|
||
- The TLS handshake allows us to
|
||
- Establish the master secret
|
||
- Resume sessions
|
||
- Authenticate the identity of the server or client
|
||
- This is for TLS 1.2 - ECDHE_RSA
|
||
- Elliptic curve with Diffie-Hellman ephemeral with RSA
|
||
|
||
|
||
|
||
**ClientHello**
|
||
|
||
```
|
||
Random nonce: f3bc12ad...
|
||
Supported Ciphers
|
||
{
|
||
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
|
||
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
|
||
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
|
||
}
|
||
[Extensions]
|
||
[Session ID]
|
||
```
|
||
|
||
**ServerHello**
|
||
|
||
```Hell
|
||
//Pick maximum version client and server can both do
|
||
Version: 1.2
|
||
Random Number: 16cf43a...
|
||
|
||
//Server chooses the suite out of the ones listed in client hello
|
||
Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
|
||
[Session ID]
|
||
```
|
||
Random nonce used to stop replay attacks
|
||
|
||
**Certificate**
|
||
|
||
The server sends its public-key certificate to the client
|
||
|
||
> **Client verification**:
|
||
>
|
||
> The client checks that the public key certificate is valid using a root certificate
|
||
|
||
**ServerKeyExchange**
|
||
|
||
```
|
||
Elliptic Curve Diffie-Hellman Parameters:
|
||
Named Curve: secp256r1 (0x0017)
|
||
DH Public Key: bG
|
||
```
|
||
|
||
Digital Signature calculated over the DH parameters
|
||
|
||
> **Authentication**:
|
||
>
|
||
> The client checks that the digital signature is valid
|
||
|
||
**[Certificate Request]**
|
||
|
||
Optional request for a certificate and singature from the client - only used in mutual TLS
|
||
|
||
Imagine two banks communicating where both parties need to prove their identity.
|
||
|
||
**ServerHelloDone**
|
||
|
||
Signals that there are no further messages to be sent
|
||
|
||
**ClientKeyExchange**
|
||
|
||
DH Public Key: aG
|
||
|
||
|
||
|
||
**[Certificate]**
|
||
|
||
Optional client certificate, verified by the server using PKI
|
||
|
||
**[Certificate Verify]**
|
||
|
||
Digital signature computed over the bytes send in the handshake so far
|
||
|
||
**Change Cipher Spec**
|
||
|
||
Signals the change of cipher suite, in this case from no encryption to the agreed encryption
|
||
|
||
This can also be done when renewing keys
|
||
|
||
**Finished**
|
||
|
||
A MAC computed over all handshake messages. Verifies that server and client see the same messages.
|
||
|
||
Mitigates man-in-the-middle attacks
|
||
|
||
##### TLS 1.3
|
||
|
||
**Efficiency**
|
||
|
||
- Handshake shortened
|
||
- Change cipher spec removed
|
||
- Key exchange sent early in hello messages
|
||
|
||
**Security**
|
||
|
||
- All ciphers except AEAD removed
|
||
- Public key and key exchange separated from cipher suites
|
||
- Some handshake messages are encrypted
|
||
|
||
## Public Key Infrastructure
|
||
|
||
#### Why do we need PKI?
|
||
|
||
|
||
|
||
#### Digital Certificates
|
||
|
||
- If we want to use public key cryptography, we need *trust*
|
||
- We can use a trusted third party in order to *verify the ownership of a public key*
|
||
- Primarily managed through Public Key Infrastructure (PKI)
|
||
- Certificates usually held in `X509` format
|
||
|
||
###### Certificate Issuance
|
||
|
||
- A server has a public key that they want people to trust
|
||
- Using some subject details, the server creates a Certificate Signing Request (CSR)
|
||
- A Certification Authority (CA) uses this to create and sign a certificate
|
||
|
||
###### Certificate Use
|
||
|
||
- The server can supply signatures using the public key, backed by the certificate when requested (during the TLS handshake)
|
||
|
||
|
||
|
||
###### Chains of trust
|
||
|
||
- To verify the trust in `server.com` certificate, we need to examine the signing certificate
|
||
|
||
|
||
|
||
- In many cases, the chain involves multiple certificates
|
||
- Chains always end in a root certificate, located on your machine
|
||
|
||
|
||
|
||
##### Who manages the Root Certificates?
|
||
|
||
- Major OS vendors operate *root certificate programs*
|
||
- Apple for iOS and OS X
|
||
- Microsoft for Windows
|
||
- Mozilla maintains root certificate store
|
||
- Used in linux & firefox
|