Kriptográfia - a legerősebb láncszem a kiberbiztonság gyakorlatában?

1. Kriptográfia - a legerősebb láncszem a kiberbiztonság gyakorlatában? Boldizsár Bencsáth PhD Laboratory of Cryptography and System Security (CrySyS) Budapest University of Technology and Economics www.crysys.hu this is joint work with Levente Buttyán

2. Part 1 Using bad crypto in bad way -> Fail

3. SecureURL.php flaw • In one of our comsulting work, we found SecureURL.php to be used • SecureURL.php hides and protects CGI GET parameters • Instead of www.example.com/mydata?id=11&parameter=other You see something like www.example.com?sec=RGlQXQULVAJRWQpdVR9RWWgBXREFW1pDFw4ZFREtMUUFPRcAOjQ1OGIyNWY1 • Protects against investigating parameters and manipulating them (integrity protection by checksum)

4. SecureURL encryption flaw • Encryption: In function crypt($text,$key): $key = md5($key); ... … ($crypt .= chr(ord($text[$i]) ^ ord($key[$j])); Problem: • If You know the crypt and know the text -> You can calculate the key (MD5 of the key). • It can be easy to identify the cypher text – cleartext pairs by guessing, etc. • The length of the key is limited - MD5: 32 chars.

5. SecureURL integrity check flaw • The problematic part: return dechex(crc32(md5($text) . md5($this->key))); • A CRC is calculated over the cleartext with adding the md5 of the key • CRC is not a cyptographically strong integrity protection algorithm • The main problem is if you don’t need the key for producing fake integrity check code, just the MD5 of the key • The MD5 of the key can be calculated from the previous encryption flaw

6. What was the problem? • MD5, CRC, and XOR worked how it was intended • We know problems with MD5 • We know where to use CRC • But the main problem was the bad application of the elements

7. Part 2 Intermezzo How we are thinking about the position of cryptography?

8. People think like this / Importance Users Applications OS Libraries Cryptographic primitives Math In marketing, and in user’s head the most important thing is the User and nobody cares about layers below. However, a bug in lower layers can cause a hype – everybody loves to be “clever” about those things.

9. The reality: Strong security foundations Users Applications OS Libraries Cryptographic primitives Mathematics In reality if we go deeper we see much stronger foundations and lessproblems. Users are the weakest point, problems at or below the cryptographic primitives level are not the main problem.

10. Press hype on “protocol X is cracked” • The hype begins when some guys, whose technical knowledge something like but knows that the real importance is tries to tell others the importance of a small flaw in lower layers…. Basically, he knows that math/problem is important, but does not understand the problem in detail

11. Part 3 Using good crypto in bad way -> Fail (protocol errors) • Vaudenay • ASP .NET • Bleichenbacher • Others

12. CBC encryption with padding pad. len. padding P1 P2 P3 PN example: • TLS padding • last byte is the length n of the padding (not including the last byte) • all padding bytes have the value n • examples for correct padding: x00, x01x01, x02x02x02, … • verification of TLS padding: • if the last byte is n, then verify if the last n+1 bytes are all n IV CN-1 + + + + … E E E E K K K K C1 C2 C3 CN

13. The padding oracle attack on CBC • padding oracle • assume that a system uses CBC encryption/decryption with MAC and padding (in this order!) • the receiver of a CBC encrypted message may respond differently in the case of “incorrect padding” and in the case of “correct padding but incorrect MAC” • we get 1 bit of information ! • example padding oracle in practice: a TLS server • send a random message to a TLS server (chosen ciphertext attack model) • the server will drop the message with overwhelming probability • either the padding is incorrect (the server responds with a DECRYPTION_FAILED alert) • or the MAC is incorrect with very high probability (the server responds with BAD_RECORD_MAC) • if the response is BAD_RECORD_MAC, then the padding was correct  we get 1 bit of information ! • how to exploit this? • such an oracle can be used repeatedly in a clever way to obtain more bits of information • ultimately, any encrypted message can be decrypted in an efficient way (~1024*N oracle call, where N is the number of ciphertext blocks in the message) • this attack was discovered by Vaudenay in 2002 • vulnerable protocols: SSL/TLS, WTLS, IPsec (with AH and ESP), ASP.NET (2010-2011!) … • lesson learnt • the block cipher can be strong (e.g., AES), the problem is in the protocol (the way it is used)

14. Bleichenbacher’s attack on PKCS1 v1.5 • conceptually similar to the Vaudenay attack on CBC • Introduced on Crypto’98 • adaptive chosen ciphertext attack on RSA with PKCS1 v1.5 formatting (e.g. SSL v3.0) • the goal is to decrypt a message with the help of an oracle that • inputs an arbitrary message • decrypts it • verifies PKCS formatting • responds with 1 if the obtained plaintext is PKCS conform, and 0 otherwise • the attack needs ~220 oracle call only

15. Some other examples • Latest TLS v1.0 problem • related to IV handling in CBC mode • makes it possible to recover some bytes under special conditions • Fixed in TLS v1.1, v1.2 • Sony hack – PS3 digital signature • ECDSA signature is created • The random element was _not_ random • The private key can be calculated from two signatures

16. Part 4 Using good crypto in good way

17. Good crypto with proper usage • Good crypto done in good way is working • It’s the strongest element of the computer security chain • Nobody cares about that, hype only begins when there are problems • Cryptography should not be blamed in general, it is our friend

18. Conclusions • bad crypto --> fail (example: secure URL) • good crypto used in a bad way --> fail (example: Vaudenay attack on CBC) • good crypto used in a good way --> strongest element in the chain, however, theoretical foundations are often missing for telling if crypto is used in a good or in a bad way • solid work exists for proving correctness of cipher modes • some works exist for key exchange protocols • nothing exists for modeling real operation environments

19. The end… Dr. Boldizsár Bencsáth www.crysys.hu