Top Banner
Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203
59

Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Apr 01, 2015

Download

Documents

Raegan Isbell
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Cryptography And Secure Channels

Kenny Paterson

Information Security Group Royal Holloway, University of London

05/22/09 | Cryp-203

Page 2: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

2

Agenda

What is a secure channel?

Why ad hoc approaches to building secure channels may be dangerous

Why the order of encryption and integrity protection matters

Conclusions

Short theoretical interlude

Why encryption alone is not enough

Page 3: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

What is a secure channel?

Page 4: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

4

The Secure Channel Concept

• We often want to guarantee the confidentiality and integrity of data travelling over insecure networks.

• Applications:– Branch office connectivity.

– Connecting to business partners at remote site.

– Remote access for employees.

– Remote administration of network devices and servers.

– E-commerce: protecting credit card numbers in transactions.

– Secure file transfers.

– …

Page 5: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

The Secure Channel Concept

• Achieved by building a secure channel.

• Typically this secure channel will offer:– Data origin authentication

– Data integrity

– Confidentiality

– Anti-replay

• But usually not:– Non-repudiation

– Any security services once data has been received

Page 6: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

The Secure Channel Concept

Secure channels are usually constructed as follows:

• An authenticated key establishment protocol.– During this one or both parties is authenticated and a fresh, shared secret is

established.

– Using asymmetric (public key) or symmetric cryptography, or a combination of the two.

• A key derivation phase.– MAC and encryption keys are derived from the shared secret established during

protocol.

• And then further traffic protected using derived keys.– MAC gives data integrity mechanism and data origin authentication.

– Encryption gives confidentiality.

– Using symmetric cryptography for speed.

Page 7: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

IPsec, SSL/TLS and SSH

• Three commonly used protocols for building secure channels

• All three use an authenticated key establishment protocol followed by key derivation. – IKE and IKEv2 in IPsec.

– Handshake Protocol in SSL/TLS.

– Authentication Protocol in SSH.

• All three then use these keys with symmetric algorithms to build a secure channel.– With subtle but important differences in the approaches taken.

Page 8: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

This Talk

In this talk, we will:

• Examine how each of IPsec, SSL/TLS and SSH use symmetric key cryptography to provide secure channels.– Key establishment and key derivation are out of scope for this talk.

• Discuss each in relation to our current theoretical knowledge.

• Highlight some of the pitfalls in the design and implementation of these protocol families.

• Identify open research problems for the design of secure channels.

Page 9: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Short Theoretical Interlude

Page 10: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Short Theoretical Interlude

• Security models for symmetric encryption are well established.

• IND-CPA security:– Attacker has no access to decryption oracle, but has access to

encryption oracle.

– Attacker has to decide which one of two selected messages was encrypted by the challenger.

– Easy to achieve with, e.g. block cipher in CBC mode with random IVs, or block cipher in CTR mode.

– See Bellare et al., FOCS’97.

• IND-CCA security:– Attacker now has access to encryption and decryption oracles.

– All basic modes of operation are insecure in this model.

Page 11: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Short Theoretical Interlude

• IND-CCA security from generic constructions (Bellare and Namprempre):– Encrypt-then-MAC: SECURE

• As used by IPsec ESP enc+auth.

– Encrypt-and-MAC: INSECURE

• MAC can leak plaintext information.

• But specific instantiations may be provably secure, e.g. as used in SSH (Bellare, Kohno and Namprempre) or Kerberos (Boldyreva and Kumar).

– MAC-then-Encrypt: INSECURE

• But MAC followed by CBC mode encryption or stream cipher is IND-CCA secure (Krawczyk).

– As used by SSL/TLS.

• Also available: dedicated authenticated encryption algorithms – e.g. CCM, EAX, GCM, OCB.

Page 12: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Why encryption alone is not enough – IPsec

Page 13: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Encryption in IPsec• IPsec provides security at the IP layer.

– Cryptographic protection of IP packets and their payloads.

• Widely used in VPNs and remote access systems.

• ESP = Encapsulating Security Protocol.– v1, v2, v3 in IETF RFCs 1827, 2406, 4303.

– IPsec’s “encryption workhorse”.

• ESP provides one or both of:– Confidentiality for packet/payload (v1, v2, v3).

– Integrity protection for packet/payload (v2, v3).

• ESP uses symmetric encryption and MACs.– Usually CBC mode of block cipher for encryption.

– HMAC-SHA1 and HMAC-MD5 for integrity protection.

Page 14: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

CINS/F1-01

ESP in Tunnel Mode

Encrypt

Inner payloadInner IPheader

• Encrypt-then-MAC construction, generically secure.

• ESP trailer contains padding, pad length and next header field.

• ESP commonly uses a block cipher in CBC mode for encryption.

ESP trailer

ESP header Encrypted inner packet

MAC

Encrypted inner packetESP headerOuter IPheader

MAC tag

Original IP packet

Page 15: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

CBC Mode – Reminder

Ci-1 Ci

Pi-1 Pi

dK dK

Pi-1 Pi

Ci-1 Ci

eK eKTypical block size n: 64 bits (DES, triple DES) or 128 bits (AES).

Typical key size: 56 bits (DES), 168 bits (triple DES), 128, 192 or 256 bits (AES).

Page 16: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Integrity Protection and ESPv1

• ESPv1 (RFC 1827) provided no integrity protection.

– Reliant on separate AH protocol to provide this.

Encrypt

Inner payloadInner IPheader

ESP trailer

ESP header Encrypted inner packetOuter IPheader

Original IP packet

Page 17: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Integrity Protection and ESPv1

• Bellovin-Wagner attack on ESPv1 without AH:

– Limited plaintext recovery:

• One byte of plaintext from each TCP segment.

– Requires ciphertexts matching 224 chosen plaintexts.

– Requires receiver to ignore encryption padding format.

• Attack fails if padding check carried out upon decryption.

– Requirements can be reduced to 28 chosen plaintexts if variable length padding acceptable.

Page 18: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Integrity Protection and ESPv2

• IETF response to Bellovin-Wagner:

– ESPv2 (RFC 2406) recommends receiver should check format of encryption padding.

• Sufficient to stop Bellovin-Wagner attack.

– Also includes integrity protection as an option.

– But implementations MUST still support “encryption-only” mode.

• ESPv2 represents a compromise between improving security and maintaining backwards-compatibility.

Page 19: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Integrity Protection and ESPv3

• ESPv3 (RFC 4303):– Still allows encryption-only ESP:

“ESP allows encryption-only … because this may offer considerably better performance and still provide adequate security, e.g., when higher layer authentication/integrity protection is offered independently.”

– Implying a MAC-then-encrypt construction.

– But no longer requires support for encryption-only modes.

– Gives strong warnings about Bellovin-Wagner attack and refers to theoretical cryptography literature to motivate need to use integrity protection.

Page 20: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Encryption-only ESP in the Real World

• The theoretical cryptography community is well aware of the need to carefully combine integrity protection with encryption.

– To achieve IND-CCA security and so prevent active attacks against confidentiality.

• It is also well-known amongst IPsec experts that encryption-only configurations should be avoided.

– Clear warnings against their use in the RFCs.

• So is there really any problem if encryption-only modes continue to be allowed in the RFCs?

Page 21: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Encryption-only ESP in the Real World

• Developers are required by RFC 2406 to support encryption-only ESP.

• Developers rarely pass RFC warnings to end users.

• Developers don’t properly implement RFCs.

• End users don’t read RFCs or technical papers.

• End users might reasonably assume that encryption on its own gives confidentiality.

• On-line tutorials sometimes do not highlight the dangers of encryption-only IPsec…

Page 22: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Encryption-only ESP in the Real World

From the IPsec Tunnel Implementation administrator's guide of a well-known vendor (until very recently):

“If you require data confidentiality only in your IPSec tunnel implementation, you should use ESP without authentication. By leaving off the authentication service, you gain some performance speed but lose the authentication service.”

Page 23: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Attacking Encryption-only ESP

• Paterson and Yau (Eurocrypt 2006):– Efficient ciphertext-only, active attacks against encryption-only ESP.

– Implemented in a realistic lab setting against the Linux implementation.

– Attacks do not work for implementation strictly following the RFCs.

• Degabriele and Paterson (IEEE S&P 2007)– Ciphertext-only attacks against encryption-only ESP.

– Less efficient than Linux attacks.

– But attacks should work for any implementation strictly following the RFCs.

– Implemented against OpenSolaris implementation.

Page 24: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Bit Flipping in CBC Mode

• Flipping bits in ciphertext block Ci-1 leads to controlled changes in plaintext block Pi upon decryption.

• But block Pi-1 is randomised.

Ci-1 Ci

Pi-1 Pi

dK dK

Flipping bits here

Leads to bit flips hereAnd randomised block here

Page 25: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Attacking Linux ESP

Paterson and Yau (Eurocrypt 2006):

• Exploit bit flipping weakness of CBC mode encryption.

• Modify headers for inner packets so they produce error messages when processed by IP.– Error messages are carried by ICMP and reveal partial plaintext

data.

• Modify headers so that error messages are sent outside of IPsec tunnel.– In some variants, straight to attacker’s machine.

Page 26: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Example: Protocol Field Manipulation for 128-bit Blocks

C1 C2

dK dK

C3

dK

IV

Payload

Dest addr

Src addrPF Csum

Payload

Flip bits here

To change protocol field and source address here Correction of

checksum via further IV bit flips

Encrypted inner packet

Inner packet

Page 27: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Example (ctd.)

• End-host generates ICMP “protocol unreachable” message in response to modified protocol field in header.

• In Linux, ICMP payload carries inner packet header and up to 528 bytes of inner packet’s payload.– Payload now in plaintext form.

– ICMP message is sent to host indicated in source address.

– And we have modified this so ICMP message does not pass through IPsec tunnel.

• Attacker intercepts ICMP message to get plaintext bytes.

Page 28: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Characteristics of Linux Attacks

The attacks:

• Recover complete contents of IPsec-protected datagrams.– But not encryption keys.

• Are efficient.– Can be run in near real-time against an IPsec tunnel.

• Do not require special operating conditions.– Attacker needs to capture packets from network, inject packets into

network, and monitor gateway for ICMP messages.

• Work in practice against Linux implementation of IPsec.– But not against implementations strictly compliant with the RFCs.

Page 29: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Attacking Linux ESP – Reactions

Some reactions to the Linux ESP attacks:– “…the possibility of active attacks on unauthenticated but

encrypted ESP packets is well known, and we advise against such use in the most recent set of IPsec documents. These documents have been approved for publication by the IESG and are in the queue to be published as RFCs. As a result, no further, substantiative changes will be made.”

– “This is all very well understood among the IPSec community, and is not news.”

– “I think the spec is clear about the dangers of encryption without authentication. If anyone built implementations that negotiate encryption without authentication, then maybe they weren't paying attention closely enough.”

Page 30: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Attacking the RFCs – Main Ideas

Degabriele and Paterson (IEEE S&P 2007):

• Extension of Vaudenay’s padding oracle attacks on CBC mode (Eurocrypt 2002) combined with Paterson-Yau techniques.

• Attack should work if (and only if) implementor has followed all the advice in IPsec RFCs:– Check correctness of padding format, as per RFCs 2406, 4303.

– Post-processing policy checks (omitted in Linux).

• Resulting attack is less efficient than Linux attack, but still recovers all plaintext.– About 216 packet injections to decrypt each block.

• So are any implementations strict enough?

Page 31: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Implementing the RFC Attack

• We examined 10 different open-source IPsec implementations:– Linux kernel, KAME, OpenBSD, FreeBSD, NetBSD, MacOS X,

Openswan, strongSwan, FreeS/WAN, OpenSolaris.

• All except one (OpenSolaris) failed to follow some of the advice to implementors given in the RFCs.– But variants of our attacks could still extract some plaintext data in

each case.

• OpenSolaris closely followed the RFCs but had a bug in the padding check implementation.

• Once the bug was fixed (Release 55) we were able to break this implementation.

Page 32: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Summary of ESP Attacks

• We produced a range of attacks against encryption-only ESP that work:– Against any implementation strictly following the RFCs, e.g.

OpenSolaris.

– Against many implementations not following the RFCs, e.g. Linux.

• The attacks that work in practice shouldn’t work against the RFCs.

• The attacks that work against the RFCs often don’t work in practice.

Page 33: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Final Remarks on IPsec

• The attacks show that encryption-only ESP is dangerously weak in a practical sense.

– There are not so many real-world examples where the lack of integrity protection has such devastating consequences.

– This kind of attack seems necessary to convince practitioners.

• No security is gained from the provision of upper layer integrity protection, despite claims to the contrary in ESPv3.

– An appropriate combination of encryption and integrity protection is needed.

– As provided, for example, by ESP with encryption and integrity protection (Encrypt-then-MAC construction).

Page 34: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Final Remarks on IPsec

• We cannot view cryptography in isolation.– Our ESP attacks arose from interaction between cryptographic

processing and network protocols.

– Sometimes called reaction attacks.

• Attacks in theory versus attacks in practice.– Implementations often deviate from standards (RFCs) in small

ways that turn out to be important for security.

– These deviations can result in big differences between attacks on paper and attacks that work in practice.

– Our attacker is incomparable with the IND-CPA attacker that is considered in theoretical work.

Page 35: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Why ad hoc approaches to building secure channels may be dangerous – SSH

Page 36: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

CINS/F1-01

SSH

Secure Shell or SSH is a network protocol that allows data to be exchanged using a secure channel between two networked devices. Used primarily on Linux and Unix based systems to access shell accounts, SSH was designed as a replacement for TELNET and other insecure remote shells, which send information, notably passwords, in plaintext, leaving them open for interception. The encryption used by SSH provides confidentiality and integrity of data over an insecure network, such as the Internet.

– Wikipedia

Page 37: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

CINS/F1-01

SSH

• SSHv1 had several security flaws.– Worst ones arising from use of CRC algorithm to provide integrity.

– Enabling, for example, traffic injection attacks.

• SSHv2 was standardised in 2006 by the IETF in RFCs 4251-4254.

• RFC 4253 specifies the SSH Binary Packet Protocol (BPP).

• SSHv2 is widely regarded as providing strong security.– It is widely used to secure remote administration of sensitive systems.

– But one minor flaw in the BPP that in theory allows distinguishing attacks (Dai; Bellare, Kohno and Namprempre).

• Several minor variants of the SSH BPP were proven secure by Bellare, Kohno and Namprempre.

– E.g. SSH-$NPC: SSH using randomised padding and CBC mode encryption with explicit IVs.

– This formal security analysis was not integrated with the design phase.

Page 38: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

CINS/F1-01

The SSH BPP

Encrypt

MAC

Payload

Ciphertext MAC tag

SequenceNumber 4

PacketLength 4

PadLen 1

Padding ≥4

• Encode-then-Encrypt&MAC construction, not generically secure.

• Packet length field measures the total size of the packet on the wire in bytes and is encrypted to hide the true length of SSH packets.

Page 39: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

CBC Mode in SSH

• RFC 4253 mandates 3DES-CBC and recommends AES-CBC.

– In fact, all originally specified optional configurations involve CBC mode, and ARCFOUR was the only optional stream cipher.

• SSH uses a chained IV in CBC mode:

– IV for current packet is the last ciphertext block from the previous packet.

– Effectively creates a single stream of data from multiple SSH packets.

Ci-1 Ci

Pi-1 Pi

dK dK

Pi-1 Pi

Ci-1 Ci

eK eK

Page 40: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Attacking the SSH BPP

• We (Albrecht, Paterson and Watson, IEEE S&P 2009) have recently developed plaintext recovering attacks against SSH.

• These new attacks exploit the interaction of the following BPP features:– The packet length field encodes how much data needs to be received

before the MAC is checked.

• So this field must be decrypted before the MAC is checked, and the amount of data needed to trigger the MAC check depends on the content of this field.

– The attacker can send data on an SSH connection in small chunks (TCP).

– CBC mode is mandated.

– A MAC failure is visible on the network.

Page 41: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Attacking the SSH BPP (Theory)

• The attacker intercepts a target ciphertext block Ci* from

the SSH connection.

Ci* = eK(Ci-1

* Pi*), i.e. Pi

* = Ci-1* dK(Ci

*)

• The attacker injects Ci* as the first block of a new SSH

packet on the connection.– The recipient will treat the first 32 bits of the corresponding plaintext

block P0’ as the packet length field. Here:

P0’ = IV dK(Ci

*).

• The attacker then feeds random ciphertext blocks into the SSH connection.– One block at a time, waiting to see what happens with each new block.

Page 42: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Attacking the SSH BPP (Theory)

• Once enough data has arrived, the recipient checks the MAC.– This check will fail with overwhelming probability.

– Consequently the connection is terminated with an error message.

• How much is enough?– The number of random blocks required to trigger this behaviour reveals

the content of the 32-bit packet length field, i.e. the first 32 bits of:

P0’ = IV dK(Ci

*).

– Because of CBC mode, this in turn reveals 32 bits of the target plaintext block:

Pi* = Ci-1

* dK(Ci*) = Ci-1

* IV P0’

Page 43: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Attack Performance

• As described, the attack would succeed in recovering 32 bits of plaintext with probability 1.– But would require the injection of about 227 random blocks to

trigger the MAC check.

– And would lead to an SSH connection tear-down.

• The attack still works if a fresh IV is used for each new SSH packet.– Breaking SSH-$NPC that was proven secure by Bellare, Kohno

and Namprempre.

• In practice, things are a bit more complicated….

Page 44: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Attacking OpenSSH

• OpenSSH is the most popular implementation of the SSH RFCs.– Open-source, distributed as part of OpenBSD.

– OpenSSH webpages state that OpenSSH accounts for more than 80% of all deployed SSH servers.

– www.openssh.org/usage/index.html

• We worked with OpenSSH 5.1.– Version 5.2 released 23/2/09 partly as a consequence of our

work.

– Main file of interest is packet.c.

Page 45: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Attacking OpenSSH

• In the OpenSSH implementation, two sanity checks are carried out on the length field after first block is decrypted.

• When each of the checks fails, the SSH connection is terminated in subtly different ways.

• If the length checks pass, then when the MAC check fails, a third type of connection termination is seen.

Page 46: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Attacking OpenSSH

• The manner in which OpenSSH behaves on failure allows:– A first attack verifiably recovering 14 bits of plaintext with probability

2-14.– A second attack verifiably recovering 32 bits of plaintext with probability

2-18 (for a 128-bit block cipher).

• Both attacks result in termination of the SSH connection with high probability.

• The attacks can be iterated to boost success probability if a fixed plaintext is repeated at a fixed position in SSH packets over multiple connections.

• We implemented the attacks.– And they worked.

Page 47: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Impact of the Attacks

• The attacks recover small amounts of plaintext and have low success probabilities.

• The attacks are easily circumvented by switching to CTR mode or by modifying error handling in CBC mode.– Countermeasures now adopted in OpenSSH release 5.2.

• So the attacks are of limited practical significance.

• Yet SSH is meant to be a “bullet-proof” protocol.– The fact that quite simple attacks are possible against such an

important protocol is troubling.

Page 48: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Theoretical Impact

• Various flavours of SSH were proven secure by Bellare, Kohno and Namprempre.– Including SSH-$NPC – randomised, per-packet IV with random padding

field – to which our attacks apply.

• So what went wrong with the theory?

• The security model does model errors during the BPP decryption process.– Even so, there is a probability 1 distinguishing attack against SSH-

$NPC that exploits these errors!

• But it fails to reflect the fact that the decryption process depends on the content of the length field.– In fact, the length field does not appear at all in the security model, and

all operations on data are atomic rather than block-wise.

Page 49: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Theoretical Impact

From Bellare, Kohno and Namprempre:

“…in the modern era of strong cryptography it would seem counterintuitive to voluntarily use a protocol with low security when it is possible to fix the security of SSH at low cost.”

• Provable security is one of the best tools we currently have.– But how do we know that “fixing” SSH actually improves security?

• We need more comprehensive security models.– Capturing the on-line nature of decryption process and the potential for

error-based side channels.

• We need to integrate security analysis with the design process.– And we need to persuade designers that this is worthwhile.

Page 50: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Why the order of encryption and integrity protection matters – SSL/TLS

Page 51: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

SSL/TLS Overview

• SSL = Secure Sockets Layer.– unreleased v1, flawed but useful v2, good v3.

• TLS = Transport Layer Security.– IETF-standardised version of SSL.

– TLS1.0 = SSL3.0 with minor tweaks, RFC 2246.

– TLS1.1=TLS1.0 with tweaks, RFC 4346 (2006).

– TLS1.2=TLS1.1 with yet more tweaks, RFC 5246 (2008).

• SSL/TLS provides security ‘at TCP layer’.– Runs over TCP, using TCP to provide reliable, end-to-end transport.

– Widely deployed in Web browsers and servers to support ‘secure e-commerce’ over HTTP.

Page 52: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

SSL/TLS Record Protocol

SSL/TLS Record Protocol provides:

• Data origin authentication, integrity, anti-replay using a MAC and sequence number.– Algorithms supported in TLS1.2 are NULL, HMAC-MD5, HMAC-SHA1,

HMAC-SHA256.

• Confidentiality using symmetric algorithm.– Algorithms supported in TLS1.2 are NULL; 3DES, AES-128, AES-256

block ciphers, all in CBC mode; RC4-128 stream cipher.

• Earlier versions of SSL/TLS will support different sets of algorithms.

Page 53: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

CINS/F1-01

SSL/TLS Record Protocol (Simplified)

MAC

SequenceNumber

Payload

Padding

Encrypt

Ciphertext

MAC tag

• MAC-then-pad-then-encrypt construction, not generically secure.

• Basic MAC-then-encrypt construction proven secure by Krawczyk for CBC mode encryption or stream cipher.

• Padding has a particular format, e.g. 01, 02 02, 03 03 03,…

Payload

Header

Page 54: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Attacking OpenSSL

• Decryption process:– Decrypt ciphertext– Remove padding (checking format as part of process).– Check the MAC field.

• Padding check or MAC failure may result in an error message on the SSL channel.

• Potential differences in timing of these error messages leads to a padding oracle attack (Vaudenay).– Padding oracle tells adversary whether underlying plaintext was

correctly padded or not.– Such an oracle can be “leveraged” to build a decryption oracle!

• Canvel et al. (Crypto 2003) showed how to exploit this to obtain a plaintext recovery attack against OpenSSH.

• OpenSSH was subsequently patched to ensure uniform timing of error messages, thus preventing the attack.

Page 55: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Theoretical Impact

• The attack of Canvel et al. shows the importance of looking beyond the basic encryption and MAC algorithm components of secure channels.– Security depends in a delicate way on the details of something as

innocuous as padding and the timing of error messages.

• It also shows that the order of operations matters.– Pad-then-encrypt-then-MAC preferable to SSL/TLS’s MAC-then-pad-

then-encrypt construction.

• Krawczyk’s result, while valuable, is not the whole story about SSL/TLS record protocol security.– In fact, his security proof needs all messages to be “block-aligned” and

assumes that no padding is used.

• Recent work of Paterson and Watson has looked at provable security of CBC mode in the presence of padding oracles.– But open problems remain for the security of MAC-then-PAD-then-

encrypt construction used by SSL/TLS.

Page 56: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Conclusions

Page 57: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Conclusions

• We have studied how IPsec, SSL/TLS and SSH use symmetric cryptographic components to build secure channels.

• The security of these cryptographic components is now very well-understood.

• But combining these components in a secure way is still a challenging task with many potential pitfalls.

• Don’t try this at home!

Page 58: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Conclusions

Major open problem:

How to model and reason about the security of secure channels in a way that captures all significant cryptographic attacks?

How do we even know what system features should be included in a security model?– What is the right amount of abstraction?

– How close to the implementation level do we need to go?

– How do we model interactions between cryptographic components and the overall system?

Page 59: Cryptography And Secure Channels Kenny Paterson Information Security Group Royal Holloway, University of London 05/22/09 | Cryp-203.

Last Words

A (mis)quote from Eugene Spafford:

“Using encryption on the Internet is the equivalent of arranging an armored car to deliver credit-card information from someone living in a cardboard box to someone living on a park bench.”

Thank You