notes/docs/lectures/cryptography/16_crypto_protocols.md

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

//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