Problems in Cryptographic Standards and Implementations
[email protected]
1
Overview Perspective on theory and practice Vulnerability statistics Proposal: new security metrics Case study: Authenticated Encryption Ideas
2
Ecosystem
Theory
1+ Year
Standards
1+ Year
Implementations
1+ Year
Deployment
3
Number of Units
Technology Adoption
Time
Moore, Crossing the Chasm; Bohlen, Beal and Rogers 4
Number of Units
Technology Adoption
Patents
Time
Moore, Crossing the Chasm; Bohlen, Beal and Rogers 5
Theory Perspective 1995 2000 2005 2010 -
SSL2.0
Wagner, Schneier
SSL3.0
Paulson
TLS1.0 3DES_EDE_CBC_SHA
Krawczyk
Vaudenay
Canetti TLS1.1 3DES_EDE_CBC_SHA TLS1.2
Rizzo,Duong Rizzo,Thai
AES_128_CBC_SHA
Ray, Dispensa
Gajek et al
Paterson, AlFarden 6
Practice Perspective
Cryptography is a well-designed lock 7
Practice Perspective
Cryptography is a well-designed lock, too often installed on a weak system 8
Practice Perspective
Can we improve system security through cryptography? 9
Product Vulnerabilities Methodology Crypto
Non-Crypto
All data taken from Cisco SIO Security Advisories and Responses web pages Some Advisories and Responses contain multiple vulnerabilities, which are counted fractionally
Note: “Vulnerabilities that would be avoided if cryptography was used” might be even larger than the “Crypto” category
Crypto Vulnerabilities: Categories Parse Flaw Incorrect parsing of message ; in many cases, it is a potential DoS attack.
Design Flaw Implementation was correct, but design was insufficient to provide security.
Access Control Flaw Absence of appropriate access control check on certificate, address, username, …
Crypto Vulnerabilities 100% 90%
Design Flaws
80% 70%
Other
60%
Access Control Design Flaws Other
50% 40% 30% 20%
Parse Flaws
Parse Flaws
OpenSSL
Products
10% 0%
Analysis Many theoretical attacks did not meet the severity threshold to be described as vulnerabilities Access Control checking is important Could be tested/validated
Parsing is of prime importance Parsing should be made easy Defense: verify before parsing Parsers should be tested/validated
If we exclude availability (DoS), then parsing attacks would diminish in importance
What else should we be measuring? Not everything that can be counted counts, and not everything that counts can be counted. – Albert Einstein
What else should we be measuring? Not everything that can be counted counts, and not everything that counts can be counted. – Albert Einstein
Number of block cipher invocations Latency Places where crypto should be used Implementation Complexity
Complexity Measures
Computational Complexity
Communication Complexity
Protocol A
1
2
Protocol B
2
3
Implementation Complexity An intrinsic property of a protocol or algorithm that measures the likelihood that an implementation of the protocol will be flawed Computational Complexity
Communication Complexity
Implementation Complexity
Protocol A
1
2
5
Protocol B
2
3
1
Implementation Complexity 6 5 4 Computation Communication Implementation
3 2 1 0 Protocol A
Protocol B
Desirable Security Properties Confidentiality Mutual Authentication Forward Security Identity Protection Threshold Compromise Resilience Independence from computational assumption C …
C is event that computational assumption is wrong Protocol A is secure whether or not C occurs Protocol B is not secure if C occurs IA is event that an implementation of A is insecure IB is event that an implementation of B is insecure P[ A secure] = P[ IAc] P[ B secure ] = P[ Cc ∧ IBc] = P[ Cc ] P[ IBc]
Protocol B more secure than Protocol A when P[ Cc ] > P[ IAc ] / P[ IBc ] Can we find a way to estimate implementation complexity ~ probability implementation failure? Lines in description Number of states in state machine Function point counting Parsing difficulty Other?
Authenticated Encryption 1995 2000 2005 2010 -
XCBC AE AEAD, OCB CCM, 802.11i GCM 802.3, IPsec 1619, FC, LTO RFC 5116 An Interface and Algorithms for Authenticated Encryption SIV, TLSv1.2, IKE, XMLsec OCBv3, SSH, SRTP 23
Vulnerabilities Prevented by AEAD Bellovin, “Problem Areas for the IP Security Protocols”, Usenix Unix Security Symposium, 1996. Vaudenay, "Security Flaws Induced by CBC Padding Applications to SSL, IPSEC, WTLS...", EUROCRYPT 2002. Bellare, Kohno, Namprempre, "Breaking and provably repairing the SSH authenticated encryption scheme: A case study of the Encode-then- Encrypt-and-MAC paradigm", ACM Transactions on Information and System Security, May 2004. Paterson, Yau, “Cryptography in theory and practice: The case of encryption in IPsec”, EUROCRYPT 2006, Degabriele, Paterson, "Attacking the IPsec Standards in Encryption-only Configurations", IEEE Symposium on Security and Privacy, 2007. Rizzo, Duong, "Practical Padding Oracle Attacks", Black Hat Europe, 2010. Jager, Somorovsky, "How To Break XML Encryption", 18th ACM Conference on Computer and Communications Security (CCS), 2011. Rizzo, Thai, "BEAST: Surprising crypto attack against HTTPS", Ekoparty, 2011. Paterson, Alfardan, "Plaintext-Recovery Attacks Against Datagram TLS", NDSS 2012.
24
Header
Header
Data
Ciphertext
Tag Pad
Header
Header
Data
Ciphertext
Nonce Generator
Header
Nonce
Data
Header
Nonce
Ciphertext
Nonce Generator
Header
Nonce
Data
Header
Nonce
Ciphertext
Nonce Generator
Header
Nonce
Data
Header
Nonce
Ciphertext
Nonce Generator
Header
Nonce
Ciphertext
Data Chunk 1
Nonce Generator
Header
Nonce
Ciphertext
Data Chunk 1
Data Chunk 2
Nonce Generator
Header
Nonce
Ciphertext
Data Block 1
FAIL
Object Size (Bytes) 802.15 Frame (max)
133
802.3 Frame (max)
1500
Ethernet Jumbo Frame
9000
Disk Block
512
File
1M
Disk
1T
AEAD should only be applied to objects that fit into data buffers
Data
Header Nonce Generator
Header
Nonce
Ciphertext
Recommended IV/Nonce format +-------------------------------+------------------------+! | Fixed | Counter |! +-------------------------------+------------------------+!
1st 2nd 3rd 4th 5th
Fixed Counter! ! 5DAD87F80000000000000001! 5DAD87F80000000000000002! 5DAD87F80000000000000003! 5DAD87F80000000000000004! 5DAD87F80000000000000005!
RFC 5116, draft-mcgrew-iv-gen-01!
Partially implicit IV/Nonce format +--------------+----------------+------------------------+! | Fixed-Common | Fixed-Distinct | Counter |! +--------------+----------------+------------------------+! ! Figure 3:!
1st 2nd 3rd 4th 5th
Fixed Fixed! Common Distinct Counter! ! 5DAD87F81E0E000000000001! 5DAD87F81E0E000000000002! 5DAD87F81E0E000000000003! 5DAD87F81E0E000000000004! 5DAD87F81E0E000000000005!
Unpredictable IV/Nonce format +-----------------+-----------------+! | Fixed | Counter |---+! +-----------------+-----------------+ |! |! +-----------------------------------+ v! | Randomizer |->(+)! +-----------------------------------+ |! |! +-----------------------------------+ |! | Initialization Vector |
