Add the rest of university notes
This commit is contained in:
366 files changed
+9844
-110
No files matched your search
@@ -0,0 +1,190 @@
|
||||
# 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
|
||||
Reference in new issue
Block a user