Secure Internet Communication

celerymoldwarpΑσφάλεια

3 Δεκ 2013 (πριν από 3 χρόνια και 4 μήνες)

98 εμφανίσεις

Secure Internet Communication
Can we prevent the
Cryptocalypse
?
Dr. Gregor Koenig
Barracuda Networks AG
ITSecX
, St.
Pölten
, 08.11.2013
Overview

Transport Layer Security

History

Orientation

Basic Functionality

Key Exchange Algorithms

Perfect Forward Secrecy

Elliptic Curve Cryptography

Encrypted Data Exchange

Attacks on Algorithms

BEAST

CRIME

BREACH

Padding Oracle

Lucky
13

AES GCM
Transport Layer Security
-
History

Secure Socket Layer (SSL)

Developed by Netscape 1993
-
1995

SSL v3.0 published in RFC 6101 in 1996 still widely in use

Transport Layer Security (TLS)

Defined in RFC 2246 in 1999 as improvement of SSL v3.0

TLS 1.1 defined in RFC 4346 in 2006

TLS
1.2
defined in RFC
5246
in
2008

The backward
-
compatibility with SSL was defined in RFC 6176 in 2011
TLS
-
Orientation
1. Physical Layer
2. Data Link Layer (IEEE 802.3 Ethernet, …)
3. Network Layer (IP, ..)
4. Transport Layer (TCP, UDP, …)
6. Presentation Layer (MIME, …)
5. Session Layer (TLS/SSL, …)
7. Application Layer (HTTP, …)
TLS

Basic Functionality
Client
Server
TLS Handshake
TLS Record

Negotiation of Cipher

Authentication

Negotiation of Keys

Authenticated and

Encrypted Data Exchange
TLS

Key Exchange

Most commonly used in TLS

RSA

Diffie
-
Hellman

Problems

Long
-
term confidentiality

Prime factorization is not considered future
-
proof

Specialized
algorithms

Availability of computing power
TLS

Key
Exchange II

Perfect Forward Secrecy

Ensures long
-
term confidentiality

Key cannot be compromised
even if private keys compromised in
future

Elliptic Curve Cryptography

Provides better mathematical properties

Equivalent protection with lower key lengths

Ratio of equivalent key length about 32:1
TLS

Ephemeral
Diffie
-
Hellman
Prime Number p
Primitive Root g
Secret b
Server Key Message (A, p, g)
B =
g^b
mod p
A =
g^a
mod p
Client Key Exchange (B)
S =
B^a
mod p
S =
A^b
mod p
Secret a
Ephemeral DH: Secret a and b chosen randomly for every connection
Performances of stud on 6
cores, with and without
DHE with a 1024bit key
TLS

Ephemeral
Diffie
-
Hellman II
Graph from http
://vincent.bernat.im/en/blog/2011
-
ssl
-
perfect
-
forward
-
secrecy.html#fn:pfs
TLS
-
Elliptic Curve
DH
Elliptic
curve
y^2=x^3
+ alpha x +
beta
Base
point G
Secret b
Server Key Message (A,
G,curve
)
B =
b

G
A =
a

G
Client Key Exchange (B)
S =
a•b

G
S =
a•b

G
Secret a
Simplified Key Exchange Protocol
TLS
-
Elliptic Curve
DH

Elliptic curve point
multiplication

A•A=B
A•B=C
A•C=D
A•D=E

Operation used in ECDH

aG
= G•G•G•…•G
Graph from http
://
arstechnica.com/security/2013/10/a
-
relatively
-
easy
-
to
-
understand
-
primer
-
on
-
elliptic
-
curve
-
cryptography
TLS
-
Elliptic Curve Cryptography
III

Up to 20x faster than RSA

Doubts

NIST standardized EC
-
based random number generator may have
backdoor (Dual Elliptic Curve Deterministic Random Bit)

130 patents of EC uses owned by BlackBerry

Implementations available thought not to infringe patents

ECDSA EC
-
based digital signature requires proper randomness

Android random number flaw disclosed
Bitcoin
wallets

Sony PlayStation vulnerability
TLS

Attacks on Encrypted Data Exchange

BEAST
-
Browser
Exploit Against
SSL/TLS

CRIME
-
Compression Ratio Info
-
leak Made
Easy

BREACH

Browser
Reconnaissance and Exfiltration via
Adaptive Compression of
Hypertext

Padding Oracle

Lucky 13
TLS

BEAST attack

What is it?

Browser Exploit Against SSL/TLS

Adaptive chosen plaintext attack with predictable IV

Thai and Rizzo showed exploitability in 2011

How does it work?

Based on two mechanisms

Initialization vector

Cipher block chaining mode

Passive network eavesdropping
Figure from http
://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Cipher
-
block_chaining_.28CBC.29
TLS

BEAST
attack II

Applicable to reveal the sessions cookie

Session cookie transmitted at known offset

Block boundaries (e.g. AES 16 bytes) can be controlled

adjusting URL parameters

Block containing cookie secret can be moved

Contains only 1 unknown byte
TLS

BEAST attack
III

Feasibility

Eavesdrop traffic e.g. over wireless network

Run malicious code in user’s browser

Bypass browser’s same
-
origin
-
policy

Counter Measures

Mitigated in TLS 1.1 and 1.2

If back
-
compatibility with TLS 1.0 or SSL is required
ensure that browser implements countermeasures

e
.g. 1/n
-
1 record splitting
TLS

CRIME attack

What is it?

Compression Ratio Info
-
leak Made Easy

Rizzo and
Doung
showed
exploitability in
2012

How does it work?

Brute force attack

Exploits data compression properties

DEFLATE is the most common used compression in TLS

Removes redundancy of repeating symbols

Applicable to reveal the sessions cookie
TLS

CRIME
attack II

Exploits length of encrypted message

length(encrypt(compress(
header+body
)))

Original HTTP Client Request:
POST
/ HTTP /
1.1
Host
:
example.com
User
-
Agent
:
Mozilla/5.0
(Windows NT 6.1; WOW64; rv :14.0) Gecko
/20100101
Firefox/14.0.1
Cookie
:
secretcookie
=7xc89f94wa96fd7cb4cb0031ba249ca2
Accept
-
Language
:
en
-
US,en;q
=0.8
(...
body of the request
...)
Example from https
://www.isecpartners.com/media/106031/ssl_attacks_survey.pdf
TLS

CRIME attack
III

HTTP request modified by attacker
POST
/
secretcookie
=0 HTTP
/1.1
Host: example.com
User
-
Agent: Mozilla /5.0 (Windows NT 6.1; WOW64;
rv
:14.0) Gecko
/20100101 Firefox /14.0.1
Cookie:
secretcookie
=7xc89f94wa96fd7cb4cb0031ba249ca2
Accept
-
Language
: en
-
US ,
en;q
=0.8

Block boundaries

Use padding to move known cookie secret
Example from
https
://www.isecpartners.com/media/106031/ssl_attacks_survey.pdf
TLS

CRIME attack
IV

Feasibility

Affects all browsers and servers supporting TLS compression

42% of servers, 45% of browsers

Needs way to execute code in user’s browser

Brute Force

O(W), W is the size of the character set

Counter Measures

Disable TLS compression!
TLS

BREACH attack

What is it?

Browser
Reconnaissance and Exfiltration via
Adaptive
Compression of
Hypertext

Demonstrated by Gluck, Harris, Prado in 2013

Application of CRIME
attack based on HTTP compression

How does it work?

Inject controlled information in HTTP requests

Eavesdrop HTTP response
TLS

BREACH
attack II

Modified HTTP request
GET
/product /?id =12345& user=
CSRFtoken
=<
guess>
HTTP /
1.1
Host
: example.com

Server’s response
<
form target="https :// example.com :443/
products/
catalogue.aspx?id
=12345& user=
CSRFtoken
=<guess >"
>
...
<
td
nowrap
id="
tdErrLgf
">
<
a
href
="
logoff.aspx?CSRFtoken
=4bd634cda846fd7cb4cb0031ba249ca2">
Log
Off</a></td
>
Example from
https
://www.isecpartners.com/media/106031/ssl_attacks_survey.pdf
TLS

BREACH
attack III

Feasibility

Monitor server requests

ARP spoofing

Run code in user’s browser

3 Requirements

Application supports HTTP compression

Response reflects user’s input

Response has sensitive information embedded
TLS

BREACH attack
IV

Countermeasures

Disable HTTP
compression

Length hiding

Add
garbage to the response

Proposal for TLS extension in development

Separating secrets from user input

Masking secrets

Request rate
-
limiting and monitoring
TLS

Padding oracle
attack

Padding oracle
attack

Chosen cipher text attack

Side
-
channel attack

Exploits leaked information about validity of format

Server leaks information if padding format is correct

Works for Cipher
-
block chaining (CBC) mode of operation

Theoretically independent of encryption algorithm
TLS

Padding oracle
attack II

Encryption (Normal operation)

Plaintext is split in blocks

Last block is padded to fill up block

RC5
-
CBC
-
PAD algorithm proposes padding:
Padded n bytes are filled with the value of n
e.g. for n=5 the last bytes are …,5,5,5,5,5

Padded plaintext is encrypted

Decryption
(Normal operation
)

Cipher text is decrypted

Correct format of padding is checked
TLS

Padding oracle
attack III
Figure from http
://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Cipher
-
block_chaining_.28CBC.29
TLS

Lucky13

What is it?

Padding oracle attack

Man
-
in
-
the
middle can recover plaintext from TLS connection

When using CBC
-
mode

Exploits timing bug of TLS data decryption

How does it work?

Message Authentication Code (MAC) is used to provide integrity

TLS encrypts block: plaintext + MAC of plaintext + padding

Decryption check padding, then checks correct MAC
TLS

Lucky13 II

Problem in TLS 1.0

Invalid padding

Explicit error returned

Made padding oracle attacks possible

Fixed in TLS 1.1

Problem in TLS 1.1

Invalid padding

Server kills the session to prevent attacks

Server’s reaction time measureable

Padding oracle attacks also work across sessions
TLS

Lucky13 III

Current version TLS 1.2

If padding fails, whole message used to calculate MAC

Should resolve previous problems

But: takes slightly longer!

Lucky 13 exploits this subtle time difference

Blocks of 64 bytes, max. 55 bytes of data

Attacker alters padding to have > 55 bytes
MACed

Extra calculation round is
measurable
TLS

Lucky13 IV

Feasibility

Intercept client
-
server communication, Inject malware to the client

Attack cookies using known location

Repetition to eliminate noise and network jitter in time measurement

All TSL cipher suites including CBC
-
mode encryption vulnerable

Slow attack

needs lots of connections to succeed

Countermeasures

Implement uniform processing time

Add random server
-
side delays

Use AES
-
GCM
TLS

RC4 Biases

What is it?

Most commonly used cipher

Long history of weaknesses

WEP protocol

Weaknesses concerning biases in initial byte stream

Thought to have no practical applicability in SSL/TLS

Bernstein,
Poettering
,
Schuldt
developed attack in 2013

Full plaintext recovery attack
TLS

RC4
Biases II

RC4

Key Scheduling Algorithm (KSA)

KSA is input to pseudo
-
random generation algorithm (PRGA)

Output of PRGA is
XORd
to the plaintext

Strong bias in first 257 bytes of encryption

Recovery of plaintext after 2^28 to 2^32 encryption using unique keys

Further optimization using known structures

Some positions have multiple biases
TLS

RC4 Biases
III

Feasibility

Attacker has to force victim to repeatedly encrypt same plaintext

Most web
-
traffic does not contain sensitive information in first 256 bytes

Experimentally 2^21 encryptions per hour are feasible

Un
-
optimized attack does not present practical threat

Mitigation

Discarding initial stream bytes

Limiting Session ID lifetime

Throttling re
-
negotiations

Recommendation to DEPRICATE USAGE OF RC4
TLS

AES Galois Counter Mode (GCM)

Features

State
-
of the art

High speed communication

Reasonable use of (HW) resources

Supports Authentication (GMAC) and Encryption

Combination

Counter Mode of Operation

Galois Mode of Authentication
TLS

AES Galois Counter Mode (GCM
) II
Figures from http
://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Counter_.28CTR.29
TLS

AES Galois Counter Mode (GCM) III

Performance

Ideal for packetized data

Minimal latency, minimum operation overhead

Intel hardware
support for Galois Hash

High
level of parallelization exploitable

Security

Depends on unique IV

Timing
-
attack resistant implementations available
Availability of Algorithms

Secure Key Exchange Algorithms in TLS 1.2

Ephemeral
Diffie
Hellman

Ephemeral Elliptic Curve
Diffie
Hellman

Security of Ciphers defines in TLS 1.2

HTTP compression makes any algorithm attackable

Renegotiation
Indication
Extension (RFC 5746) has to be implemented

Don’t use RC4

Use AES GCM
Take
-
Home Message

Yes, we can prevent the
Cryptocaplypse

… for the moment

Update
your Servers

Use latest versions of libraries

Enable secure algorithms

Update
your Browser

Latest browser version support TLS 1.2

Chrome >=
30, Firefox
>=
28, Internet
Explorer >=
11
Opera
>=
17, Safari
>= 5 (
iOS
), >= 7 (Mac OS X
)
Thank You
Dr. Gregor Koenig
gkoenig@barracuda.com
Comic from http
://xkcd.com/538/
References
General
1.
P.
Bright, Crypto experts issue a call to arms to avert the
cryptopocalypse
http
://arstechnica.com/security/2013/08/crytpo
-
experts
-
issue
-
a
-
call
-
to
-
arms
-
to
-
avert
-
the
-
cryptopocalypse/
2.
Wikipedia
, Transport Layer Security.
http://en.wikipedia.org/wiki/Transport_Layer_Security
Key Exchange
1.
Wikipedia, Perfect Forward Secrecy
http
://en.wikipedia.org/wiki/Perfect_forward_secrecy
2.
N. Sullivan
, A primer on elliptic curve
cryptography, 2013
http://
arstechnica.com/security/2013/10/a
-
relatively
-
easy
-
to
-
understand
-
primer
-
on
-
elliptic
-
curve
-
cryptography
Ciphers
1.
P. Sarkar, S. Fitzgerald,. Attacks on SSL, A comprehensive Study of BEAST, CRIME, TIME, BREACH, LUCK13 & RC4 BIAS, 2013
https://www.isecpartners.com/media/106031/ssl_attacks_survey.pdf
2.
S.
Vaudenay
, Security Flaws Induced by CBC padding, Applications to SSL, IPSEC, WTLS
http://lasec.epfl.ch/pub/lasec/doc/Vau02a.ps
3.
S.
Gueron
, AES
-
GCM for
Efficient Authenticated Encryption ,
2013.
https://
crypto.stanford.edu/RealWorldCrypto/slides/gueron.pdf
4.
D.
Goodin
, Gone in 30 seconds: New attack plucks secrets from HTTPS
-
protected pages
http://arstechnica.com/security/2013/08/gone
-
in
-
30
-
seconds
-
new
-
attack
-
plucks
-
secrets
-
from
-
https
-
protected
-
pages
5.
N.
AlFardan
et al., On the security of RC4 in TLS and WPA, 2013.
http
://
www.isg.rhul.ac.uk/tls
6.
Wikipedia
, Galois/Counter Mode
http://en.wikipedia.org/wiki/Galois/Counter_Mode