Cryptography Pitfalls at LASCON 2016

Transcript

1. Cryptography Pitfalls John Downey | @jtdowney @jtdowney 1
2. Chicago @jtdowney 2
3. @jtdowney 3
4. @jtdowney 4
5. @jtdowney 5
6. @jtdowney 6
7. The views expressed in this presentation are my own, and not those of PayPal or any of its affiliates. @jtdowney 7
8. @jtdowney 8
9. Confidentiality @jtdowney 9
10. Authentication @jtdowney 10
11. Identification @jtdowney 11
12. Rigorous Science @jtdowney 12
13. Peer Review @jtdowney 13
14. @jtdowney 14
15. You have probably seen the door to a bank vault, at least in the movies. You know, 10-inch-thick, hardened steel, with huge bolts to lock it in place. It certainly looks impressive. We often find the digital equivalent of such a vault door installed in a tent. The people standing around it are arguing over how thick the door should be, rather than spending their time looking at the tent. — Cryptography Engineering by Niels Ferguson, Bruce Schneier, and Tadayoshi Kohno @jtdowney 15
16. • For data in transit • Use TLS (née SSL), SSH, or VPN/IPsec • For data at rest • Use GnuPG • Data to be signed • Use GnuPG @jtdowney 16
17. • Avoid low level libraries • OpenSSL • PyCrypto • Bouncy Castle • Use a high level library • NaCL/libsodium (C, Ruby, etc) • Keyczar (Python and Java) @jtdowney 17
18. @jtdowney 18
19. Random Number Generation @jtdowney 19
20. Pitfalls 1. Not using a cryptographically strong random number generator 2. Broken random number generators 3. Not using random data when it is required @jtdowney 20
21. @jtdowney 21
22. @jtdowney 22
23. Pitfalls 1. Not using a cryptographically strong random number generator 2. Broken random number generators 3. Not using random data when it is required @jtdowney 23
24. @jtdowney 24
25. @jtdowney 25
26. MD_Update(&m,buf,j); @jtdowney 26
27. Don't add uninitialised data to the random number generator. This stop valgrind from giving error messages in unrelated code. (Closes: #363516) @jtdowney 27
28. /* DO NOT REMOVE THE FOLLOWING CALL TO MD_Update()! */ MD_Update(&m,buf,j); /* We know that line may cause programs such as purify and valgrind to complain about use of uninitialized data. The problem is not, it's with the caller. Removing that line will make sure you get really bad randomness and thereby other problems such as very insecure keys. */ @jtdowney 28
29. @jtdowney 29
30. @jtdowney 30
31. @jtdowney 31
32. @jtdowney 32
33. Pitfalls 1. Not using a cryptographically strong random number generator 2. Broken random number generators 3. Not using random data when it is required @jtdowney 33
34. @jtdowney 34
35. Recommendations • Use a cryptographically strong random number generator • Unix-like • Read from /dev/urandom • Windows • RandomNumberGenerator in System.Security.Cryptography (.NET) • CryptGenRandom (Windows) @jtdowney 35
36. Hash Functions @jtdowney 36
37. Pitfalls 1. Using weak/old algorithms 2. Misunderstanding checksums 3. Length extension attacks @jtdowney 37
38. @jtdowney 38
39. @jtdowney 39
40. @jtdowney 40
41. @jtdowney 41
42. 9EC4C12949A4F31474F299058CE2B22A @jtdowney 42
43. mission = """ USCYBERCOM plans, coordinates, integrates, synchronizes and conducts activities to: direct the operations and defense of specified Department of Defense information networks and; prepare to, and when directed, conduct full spectrum military cyberspace operations in order to enable actions in all domains, ensure US/Allied freedom of action in cyberspace and deny the same to our adversaries. """ md5(mission) # => 9EC4C12949A4F31474F299058CE2B22A @jtdowney 43
44. Pitfalls 1. Using weak/old algorithms 2. Misunderstanding checksums 3. Length extension attacks @jtdowney 44
45. @jtdowney 45
46. Pitfalls 1. Using weak/old algorithms 2. Misunderstanding checksums 3. Length extension attacks @jtdowney 46
47. Message Authentication Code (MAC) tag = MAC(key, value) • Takes: • key - shared secret • value - value to protected integrity of • Returns: • tag - value that represents the integrity @jtdowney 47
48. Naive approach tag = sha256(key || value) @jtdowney 48
49. Length Extension Attacks secret = "my-secret-key" value = "buy 10 units at $1" signature = sha256(secret + value) @jtdowney 49
50. Length Extension Attacks secret = "my-secret-key" value = "buy 10 units at $1<garbage>actually make that at $0" signature = sha256(secret + value) @jtdowney 50
51. Length Extension Attacks secret = "my-secret-key" value = "buy 10 units at $1" signature = hmac_sha256(secret, value) @jtdowney 51
52. @jtdowney 52
53. @jtdowney 53
54. Recommendations • Use SHA-256 (SHA-2 family) • Choose HMAC-SHA-256 if you want a signature • Stop using MD5 • Don't use SHA-1 in new projects • Phase it out for uses that require collision resistance @jtdowney 54
55. Ciphers @jtdowney 55
56. Pitfalls 1. Using old/weak algorithms 2. Using ECB mode for block ciphers 3. Not using authenticated encryption @jtdowney 56
57. @jtdowney 57
58. @jtdowney 58
59. @jtdowney 59
60. Pitfalls 1. Using old/weak algorithms 2. Using ECB mode for block ciphers 3. Not using authenticated encryption @jtdowney 60
61. AES - primitive ciphertext = AES_Encrypt(key, plaintext) plaintext = AES_Decrypt(key, ciphertext) • Function over: • key - 128, 192, or 256 bit value • plaintext - 128 bit value • ciphertext - 128 bit value @jtdowney 61
62. ECB Encrypt while (remaining blocks) { block = ... # next 16 byte (128 bit chunk) ouput.append(AES_Encrypt(key, block)) } @jtdowney 62
63. @jtdowney 63
64. @jtdowney 64
65. Pitfalls 1. Using old/weak algorithms 2. Using ECB mode for block ciphers 3. Not using authenticated encryption @jtdowney 65
66. @jtdowney 66
67. @jtdowney 67
68. @jtdowney 68
69. @jtdowney 69
70. World of hurt @jtdowney 70
71. Recommendations • Prefer to use box/secret box from NaCL/libsodium • Stop using DES • Stop building your own on top of AES • Stop encrypting without protecting integrity @jtdowney 71
72. What if you have to use AES • Do not use ECB mode • Be sure to use authenticated encryption • GCM mode would be a good first choice • Verify the tag/MAC first • Still easy to mess up in a critical way @jtdowney 72
73. TLS/SSL @jtdowney 73
74. Pitfalls 1. Not verifying the certificate chain or hostname 2. Misconfigured server settings 3. Using a broken library @jtdowney 74
75. @jtdowney 75
76. @jtdowney 76
77. @jtdowney 77
78. Hostname verification @jtdowney 78
79. Hostname verification • Check that you got the certificate for who you intended to connect to • Hostname verification is protocol dependent • OpenSSL doesn't have it built in @jtdowney 79
80. Pitfalls 1. Not verifying the certificate chain or hostname 2. Misconfigured server settings 3. Using a broken library @jtdowney 80
81. @jtdowney 81
82. SSL Labs https://www.ssllabs.com @jtdowney 82
83. testssl.sh @jtdowney 83
84. TLS Server Settings https://mozilla.github.io/server-side-tls/ssl-config-generator/ @jtdowney 84
85. Pitfalls 1. Not verifying the certificate chain or hostname 2. Misconfigured server settings 3. Using a broken library @jtdowney 85
86. @jtdowney 86
87. @jtdowney 87
88. Recommendations • Do ensure you're validating connections • Lean on a framework/library if possible • But check that it also does the right thing • Setup and automated test to validate this setting (badssl.com) @jtdowney 88
89. Trust @jtdowney 89
90. The authenticity of host 'apollo.local (10.0.2.56)' can't be established. RSA key fingerprint is 04:63:c1:ba:c7:31:04:12:14:ff:b6:c4:32:cf:44:ec. Are you sure you want to continue connecting (yes/no)? @jtdowney 90
91. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 04:63:c1:ba:c7:31:04:12:14:ff:b6:c4:32:cf:44:ec. Please contact your system administrator. @jtdowney 91
92. @jtdowney 92
93. Certificate Pinning @jtdowney 93
94. @jtdowney 94
95. Recommendations • Think about what organizations you really trust • Investigate certificate pinning for your apps @jtdowney 95
96. Quantum Computers @jtdowney 96
97. Pitfalls 1. Assuming current crypto will last forever @jtdowney 97
98. @jtdowney 98
99. @jtdowney 99
100. Recommendations • Follow the PQCrypto discussion • Stay away from PQCrypto until the industry starts to standardize • Hope that researchers are moving fast enough @jtdowney 100
101. @jtdowney 101
102. Stanford Crypto Class http://crypto-class.com @jtdowney 102
103. Matasano Crypto Challenges http://cryptopals.com @jtdowney 103
104. Questions John Downey | @jtdowney @jtdowney 104
105. Images • https://flic.kr/p/6eagaw • https://flic.kr/p/4KWhKn • https://flic.kr/p/9F2BCv • https://flic.kr/p/486xYS • https://flic.kr/p/7Ffppm • https://flic.kr/p/8TuJD9 • https://flic.kr/p/4iLJZt • https://flic.kr/p/4pGZuz • https://flic.kr/p/48w7wP • https://flic.kr/p/8aZWNE • https://flic.kr/p/5NRHp • https://flic.kr/p/7p7raq • https://flic.kr/p/aZEE1Z • https://flic.kr/p/7WtwAz • https://flic.kr/p/6AN9mM • https://flic.kr/p/6dt62u • https://flic.kr/p/4ZqwyB • https://flic.kr/p/Bqewr • https://flic.kr/p/ecdhVE • https://flic.kr/p/AV1Nd @jtdowney 105