Cryptography: Transport Layer Security

How does the TLS Record Protocol work: Padding

- last byte is the length n of the padding (not including the last byte) - padding length is random (0-255 bytes), but such that the length of the padded message is a multiple of the block length of the blockcipher used - all padding bytes have value n - examples for correct message tails: x00, x01x01, x02x02x02, ... - verification: if the last byte is n, then verify if the last n+1 bytes are all n - if verification is successful, remove the last n+1 bytes, and proceed with the verification of the MAC

Padding oracle attack on SSL/TLS: practical problems

--Alert messages are encrypted --> BAD_RECORD_MAC and DECRYPTION_FAILED cannot be easily distinguished - solution: measure timing between oracle call and oracle response (BAD_RECORD_MAC takes more time than DECRYPTION_FAILED, as it also involves the MAC verification time) --BAD_RECORD_MAC and DECRYPTION_FAILED are fatal errors --> connection is closed after one oracle call - solution: mount a multi-session attack, where a secret (e.g. password) is sent periodically to a server using TLS; each session uses a different key, but the password is always the same

BEAST, CRIME, TIME and BREACH attacks

--BEAST: in the HTTP request sent out by the browser, the 4th block will have a single unknown byte (the first letter of the cookie)...the attacker can obtain the first byte of the cookie by repeatedly checking different guesses and taking advantage of predictable IVs --CRIME: exploits information leakage through a side-channel provided by TLS compression - the attacker tries to guess the value of a cookie which is automatically appended by the browser to HTTP requests to a target site - the attacker can put their guesses in the requested path (part of HTTP request) or in any request parameter that they can control - if the guess is correct, then the same string occurs twice in the request (in the path and in the cookie header) --> compression ratio increases - the attacker can observe the size of the ciphertext --> smaller request means good guess --BREACH: similar to CRIME, but instead of HTTP requests, targets HTTP responses - many web applications routinely deliver secrets in the bodies of HTTP responses--> attacker can make guesses for a secret in a URL parameter--> if guess is correct, resulting HTTP response (which reflects the guess and contains the secret) can be compressed better --TIME: similar to BREACH, but uses timing information to infer the size of the compressed payload - larger compression ratio--> smaller message--> shorter transmission time

How are ciphersuites negotiated in the TLS handshake

--Cipher suites are negotiated during the hello phase of the handshake --In client_hello: list of cipher suites supported by the client ordered by preference --In server_hello: the selected cipher suite --A cipher suite contains the specification of: -the key exchange method -the encryption algorithm -the MAC algorithm

Lucky 13 Attack (2013)--TLS 1.1 and 1.2

--TLS 1.1 and 1.2 recommend checking MAC as if there was zero-length padding--> leaves small timing channel, but was thought to not be exploitable --similar to the padding oracle attack but uses the newly introduced timing channel key observation: - if message length <= 55bytes » then message + 8 byte length + padding fits in a single 64-byte block » hashing needs 4 invocations of the compression function f - if message length > 55 bytes » then padded message needs at least two 64-byte blocks » hashing needs at least 5 invocations of f - this is a timing channel!

How is the server authenticated in the TLS handshake?

--asymmetric key cryptography is used to authenticate parties to each other (but client authentication is optional) --certificate is required for every key exchange method except anonymous DH --server_key_exchange: sent if the certificate does not contain enough information to complete the key exchange, digitally signed --server_hello_done is sent after the client verifies that the server provided a valid certificate and the server parameters are acceptable (indicates that the server is finished its part of the key exchange)

What type of attacks do exist against earlier versions of the TLS Record Protocol (versions smaller than 1.3)?--

--chosen ciphertext (padding oracle) attacks - Lucky 13 attack --chosen plaintext attacks - CRIME attack - TIME attack - BREACH attack

How does the TLS Record Protocol work: MAC Computation

--if no authenticated encryption is used, then message integrity protection and origin authentication is provided by a keyed MAC --the MAC value is computed before the encryption --input to the MAC computation: -MAC_write_key -seq_num | type | version | length | payload (compressed fragment) -> sequence numbers are maintained at both sides of the communication -> they are not sent explicitly in the TLS Record header (implicit sequence numbering) --supported algorithms: HMAC with MD5, SHA1, SHA256

What are the main lessons of those attacks?

--in the case of message encryption schemes, any kind of information leakage may be a problem in practice, even if it seems the amount of information leaked is small - information may be leaked through the protocol itself (error messages may leak info about correctness of the padding) - or via side-channels (timing, message length) --protocols with a lot of flexibility are difficult to make secure - flexibility --> many options --> increased complexity --> <--security - in particular, supporting multiple versions (including old, potentially weak versions) of the protocol may easily lead to problems - supporting multiple key exchange protocols may allow for cross protocol attacks --even if your protocol is secure at the design level there can be implementation flaws - minimize the risk by being precise and explicit in the specification (don't let implementers make decisions on their own)

What is the role of the Change_Cipher_Spec messages?

Change_cipher_spec is a single message that indicates the end of the TLS handshake --triggers a state change at the parties

How are connection keys derived from the session master secret?

Connection key generation: -key block: PRF(master_secret, "key expansion," server_random | client_random) --> as many bytes as needed -key block is then partitioned: client_write_MAC_key | server_write_MAC_key | client_write_key | server_write_key | client_write_IV | server_write_IV

What is the role of the Finished messages and how are they constructed

Finished messages are sent immediately after the change_cipher_spec message --the change_cipher_spec message triggers a state change (not part of the handshake) and marks a point where parties are supposed to start using the newly negotiated algorithms and parameters --finished message is the first message that is protected with the newly negotiated algorithms and keys --finished messages are used to authenticate all previous handshake messages --computed with a pseudo-random function from the master secret and the hash of all handshake messages: PRF(master_secret, "client finished," hash(handshake_messages)) --> 12 bytes PRF(master_secret, "server finished," hash(handshake_messages)) --> 12 bytes

Which parts of the handshake are kept when the parties create a connection in an already existing session?

Just the hello messages and the finished messages... If a new session is opened: --session_id of client_hello is empty --session_id of server_hello is the new session ID If the client wants to create a new connection in an existing session: --session_id of client_hello is the session ID of the existing session --if a new connection can be created in that session, then the server responds with the same session ID--> parties can proceed to the "finished" messages --otherwise, the server responds with a new session ID--> full handshake will take place

What are the phases of the TLS Handshake Protocol?

Phase 1: negotiation of the session ID, key exchange algorithm, MAC algorithm, encryption algorithm, and exchange of initial random numbers Phase 2: server may send its certificate and key exchange message, and it may request the client to send a certificate. Server signals end of hello phase. Phase 3: client sends certificate if requested and may send an explicit certificate verification message. Client always sends its key exchange message Phase 4: change cipher spec and finish handshake

What key exchange methods are supported by TLS? How do they work?

RSA based (TLS_RSA with...) --the secret key (pre-master secret) is encrypted with the server's public RSA key --the server's public key is made available to the client during the exchange Fixed Diffie-Hellman (TLS_DH_RSA with... or TLS_DH_DSS with...) --the server has fixed DH parameters contained in a certificate signed by a CA --the client may have fixed DH parameters certified by a CA or it may send an unauthenticated one-time DH public value in the client_key_exchange message Ephemeral Diffie-Hellman (TLS_DHE_RSA with... or TLS_DHE_DSS_with...) --both the server and the client generate one-time DH parameters --the server signs its DH parameters with its private RSA or DSS key --the client sends an unauthenticated one-time DH public value in the client_key_exchange message --the client may authenticate itself (if requested by the server) by signing the hash of the handshake messages with its private RSA or DSS key Anonymous DIffie-Hellman (TLS_DH_anon_with...) --both the server and the client use one-time DH parameters without authentication

How does the TLS Record Protocol work: Encryption

Stream ciphers --no IV and padding --no re-initialization of the cipher for individual messages --supported algorithm: RC4 (128) Block ciphers in CBC mode: --IV must be a random value --> until TLSv1.0, IV was the last cipher block of the previous message --padding (see previous card) --supported algorithms: 3DES-EDE, AES (128, 256) Authenticated encryption modes --nonce is carried in the IV field --no padding --jointly encrypted and authenticated message is computed from: -> client_or server_write_key -> nonce -> cleartext payload -> seq_num | type | version | length --supported algorithms: AES-GCM (128, 256), AES-CCM (128, 256)

What are the TLS sub-protocols, and how do they fit in the TCP/IP network stack?

TLS Handshake Protocol --negotiation of security algorithms and parameters --key exchange --server authentication and optional client authentication TLS Record Protocol --fragmentation --compression --message authentication and integrity protection --replay protection --confidentiality by encryption TLS Alert Protocol --error messages (fatal alerts and warnings) TLS Change Cipher Spec Protocol --a single message that indicates the end of the TLS handshake --triggers a state change at the parties

What security services does TLS provide?

TLS provides a secure connection between applications (typically between a web server and a web browser--> HTTPS) --confidentiality and integrity protection: -symmetric key cryptography used for message encryption and MAC computation -MAC covers a message sequence number--> replay protection -v1.2 supports a keyed MAC function and authenticated encryption modes, v1.3 only supports authenticated encryption --(mutual) authentication of parties: -asymmetric key cryptography is used to authenticate parties to each other -however, client authentication is optional --key exchange -keys are generated uniquely for each connection -different keys are used for the encryption and the MAC (unless an authenticated encryption mode is negotiated) -different keys are used in the two directions (client--> server, server--> client) --negotiation of cryptographic algorithms and parameters

What are TLS sessions and connections? How are they related and what was the design motivation for this relationship?

TLS session is a ssecurity association between a client and a server--sessions are stateful and the session state includes: --negotiated security algorithms and parameters --certificates (if any) --a master secret shared between the client and the server (established during a full TLS handshake) A session may include multiple secure connections between the same client and server --connections of the same session share the session state --in addition, each connection has its own connection keys (derived from the master secret) and connection specific random numbers Factoring out the master secret into the session state helps to avoid expensive negotiation of new security parameters for each and every new connection (within the same session)

How does the TLS Record Protocol work: Message Format

Type, version, length...IV/Nonce (if needed--CBC mode or authenticated encryption), application data (encrypted payload--confidentiality), MAC (authentication, integrity, and replay protection), padding, p.len

Padding oracle attack on SSL/TLS v1.0

§ padding oracle (reminder) --assume the attacker can access a CBC decryption oracle --the oracle receives ciphertext messages --it decrypts in CBC mode, and checks the padding --it responds with a single bit indicating whether the padding was correct or not --thus, we assume a chosen ciphertext attack model, where the oracle does not return the full plaintext, but only some partial information about the result of the decryption --by sending carefully crafted messages (r | y) to the oracle, one can decrypt any encrypted block y § padding oracle on SSL/TLS --send random message to SSL/TLS server --server will drop the message with overwhelming probability - after decryption either the padding is incorrect (the server responds with DECRYPTION_FAILED) - or thE MAC is incorrect (very high probability) --> server responds with BAD_RECORD_MAC alert --server works as a padding oracle - the attacker can try to apply the padding oracle attack on CBC, but there are some problems in practice...