«applied cryptanalysis everything else» by vladimir garbuz
Post on 18-Aug-2015
20 Views
Preview:
TRANSCRIPT
Applied Cryptanalysis:Everything else
Vladimir Garbuz
Block ciphers
Intro•Operate on blocks of equal, identical size•Have different and clever modes of operation• Some of them can simulate a Stream cipher
•Has to have it’s input length divisible by block size• To achieve that, padding is used (e.g. PKCS7)
Block ciphers
Modes of operation: ECB•Electronic CodeBook, the naive approach
Block ciphersModes of operation: CBC
•Cipher block chaining, a more clever approach
Block ciphers
Modes of operation: CBC•Bit flipping•Padding oracle attack• E.g. POODLE on SSLv3•And TLS 1.0-1.2 implementations
Block ciphers
Modes of operation: CBC – Padding Oraclehttp://sampleapp/home?UID=7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6
Block ciphers
Modes of operation: CBC – Padding OracleRequest: http://sampleapp/home?UID=0000000000000000F851D6CC68FC9537
Response: 500 - Internal Server Error
Block ciphers
Modes of operation: CBC – Padding OracleRequest: http://sampleapp/home?UID=0000000000000001F851D6CC68FC9537
Response: 500 - Internal Server Error
Block ciphers
Modes of operation: CBC – Padding OracleRequest: http://sampleapp/home?UID=000000000000003CF851D6CC68FC9537
Response: 500 - Internal Server Error
X ⊕ 3C = 01X = 01 ⊕ 3CX = 3D3D 0F = ‘2’!⊕
3D Y = 02⊕Y = 3D 02⊕Y = 3F
Block ciphers
Modes of operation: CBC – Padding OracleRequest: http://sampleapp/home?UID=000000000000003FF851D6CC68FC9537
Response: 500 - Internal Server Error
Block ciphers
Modes of operation: CBC – Padding OracleRequest: http://sampleapp/home?UID=000000000000243FF851D6CC68FC9537
Response: 500 - Internal Server Error
Block ciphers
Modes of operation: CTR
Block ciphers
Modes of operation: CTR•Very parallelizable and simple•Still has many vulnerabilities…• Bit flipping works great• Counter must count•And nonces should NEVER be reused
Hash
Cryptographic hash
Basically a one way function With a finite number of possible digests And infinite possible inputs collision possibility
Cryptographic hashes have stronger properties, specifically it must be hard to: Modify a message without changing its hash
Avalanche effect is our friend Generate a message that has a given hash
Which makes it a one-way function Find two different messages with the same hash
Which provides collision resistance
Cryptographic hash
Main problems they address
1. Password storage2. Key derivation3. Ensuring data integrity
1. Message authentication codes (MAC)2. Doing it right - HMAC
4. Proof of work
Cryptographic hash
Password storage Never store passwords for verification in the clear Use salts with hashes to fight rainbow tables
Don’t reuse it with different passwords Don’t make it too short Get it with CSPRNG
Never use clear hash functions to hash passwords Wat?!
Yep! Go for a key derivation function! Wat?...
Cryptographic hash
Key derivation functions Designed to be slooow, hard to parallelize And are used in password hashes storage Also used to increase entropy of an encryption key
Entropy of stuff you can type on a keyboard isn’t great Examples:
PBKDF2 from RSA – better than nothing bcrypt – pretty good, widely available scrypt – best! Not yet as available, but if it is – use it!
Cryptographic hash
Ensuring data integrity Usual workflow:
Hash data to get it’s hash, send hash with data Receiver gets the data, computes its hash and
compares it with the hash transmitted E.g. you can see them next to sourcecode downloads…
This catches transmission errors but doesn’t work against an attacker modifying the message
Cryptographic hash
Ensuring data integrityMessage Authentication Codes
MAC is a hash tag computed as F(message, key) And the key MUST be unpredictable and NOT short
Function F() could be any, e.g.:1. F(message, key) = key + message (the naive approach)2. F(message, key) = message + key (just a little better)3. F(message, key) = key + message + key (still bad)4. F(message, key) = weird pseudo-random transforms,
… But the right way is HMAC, always HMAC!
Cryptographic hash
Breaking “key + message” MAC:Length extension attack
What’s vulnerable? Hash functions with Merkle–Damgård construction, e.g.
MD4, MD5, RIPEMD-160, WHIRLPOOL, SHA-0, SHA-1 and even SHA-2
Doesn’t work on other constructions - SHA-3, poly1305,... In this construction, the resulting hash is the internal
state of the function at the end of computation Which can (and will ) be used as the starting state of the
hash function
Cryptographic hash
Breaking “key + message MAC”:Length extension attack
Hash of k+m is actually a hash of k+m+p, where p is some necessary, but easily predictable, padding
To illustrate this: H0(k) = Hk - here, H0 is the initial state of hash function Hk(m) = Hkm - Hk is its state after processing k Hkm (p) = Hkmp
Hkmp = H(k+m+p)
Cryptographic hash
Breaking “key + message MAC”:Length extension attack
Since p is predictable and end state Hkmp is known We chose any arbitrary m´ Set the hash function’s initial state to Hkmp And make it process the bytes of message m´Hkmp(m´) = Hkmpm´
Curiously, this is EXACTLY what happens when you hash m+p+m´ under a known key!
Now, our hash is forged but will check out as valid!
Cryptographic hash
Ensuring data integrityThe right way: HMAC
Introduced in 1996 Thus, widely available So effective, even broken functionsproduce secure tags with it! (e.g. MD5)
Still, not a reason to ever use MD5or any other broken hash function!
Cryptographic hash
Proof of work The basic idea – something must be hard to compute but
easy to check if the computation is right Make the client find a string whose hash matches a mask
E.g. whose SHA-1 starts with the phrase “JEEZUZ” in ASCII Get the text, compute it’s SHA-1 and check if it matches Although, choose the mask randomly for each client If it’s not enough, throttle the connection down by larger mask
Very useful to deter DoS or password bruteforce
By the way, that’s what Bitcoin is based on
Cryptographic hash
Vulnerable, but still used, hash functions MD4 MD5 – yes, fully broken since 2007, stop using it! SHA-1
“Oh please, we’ve used MD5 forever and it’s been ok!”
Cryptographic hash
MD5What’s similar for these 3 images?..
Their MD5 hash!And a freely available tool HashClash was used!
Cryptographic hash
MD5 Chosen prefix collisions
Authenticated encryption
Authenticated encryption
Approaches to Authenticated Encryption Encrypt-and-MAC (E&M): A MAC is produced based on the
plaintext, and the plaintext is encrypted without the MAC.
MAC-then-Encrypt (MtE): A MAC is produced based on the plaintext, then the plaintext and MAC are together encrypted to produce a ciphertext based on both.
Encrypt-then-MAC (EtM): The plaintext is first encrypted, then a MAC is produced based on the resulting ciphertext.
One should NEVER start decrypting if the MAC isn’t right!
Authenticated encryption
AE with Associated Data – AEAD Basically means that some data is sent in cleartext but the
MAC authenticates it as well (e.g. packet routing info)
NEVER use un-authenticated encryption! E.g. TLS 1.3 removes support for non-AEAD cipher modes!
NEVER implement encryption (cryptography) yourself! Go google how to use AE in your framework Example AEAD modes are GCM, EAX, CWC
“That’s all cool stuff, but how do we securely exchange encryption keys over an insecure Internet connection with people we’ve never met in person?...”
Public-key cryptography!
CRYPTOMANTo the rescue!
Public-key cryptography
A famous example is RSA
Digital signature
A simplified signing scheme via RSA
Key exchange
Abstract Diffie-Hellman key exchange Acronyms – DHE, ECDHE Basic principle: paints Paints are easy to mix But difficult to separate Vulnerable to MITM! “Common paint” must be signed Then why not just use public-keyto encrypt the key?.. Perfect forward secrecy!
Perfect forward secrecy
Even if private keys are stolen, the actual encryption keys can not be uncovered When Diffie-Hellman is properly configured, e.g IPSec,
SSH, TLS, STARTTLS, OpenSSL support it
Best Practices
1. NEVER invent your own crypto – it’s way too easy to screw up!
2. NEVER implement existing cryptographic algorithms yourself!3. NEVER use export (EXP) crypto!4. NEVER use broken cryptographic functions/primitives!5. NEVER use passphrases as encryption keys! Go for key
derivation functions!6. NEVER use unauthenticated encryption!7. Use cryptographically strong PRNGs!8. For symmetric encryption, use at least AES-128 or higher 9. For cryptographic hashing, use at least SHA-256 or higher10. For password storage, use a key derivation function with a
long, random salt!
Best Practices
•Do TLS the right way!•Yay or nay?• ECDHE-RSA-AES256-GCM-SHA256• Yay!
• ECDHE-RSA-RC4-SHA• Nay!
• EXP-RC4-MD5• Nay nay nay!!!
Questions and Discussion
top related