Cryptography Pitfalls at Geekfest

Cryptography Pitfalls at Geekfest

58376779023f009fc13d160bb3e82515?s=128

John Downey

July 12, 2016
Tweet

Transcript

  1. Cryptography Pitfalls John Downey | @jtdowney @jtdowney 1

  2. @jtdowney 2

  3. @jtdowney 3

  4. The views expressed in this presentation are my own, and

    not those of PayPal or any of its affiliates. @jtdowney 4
  5. @jtdowney 5

  6. Confidentiality @jtdowney 6

  7. Authentication @jtdowney 7

  8. Identification @jtdowney 8

  9. Rigorous Science @jtdowney 9

  10. Peer Review @jtdowney 10

  11. @jtdowney 11

  12. 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 12
  13. • For data in transit • Use TLS (née SSL),

    SSH, or VPN/IPsec • For data at rest • Use GnuPG @jtdowney 13
  14. • Avoid low level libraries • OpenSSL • PyCrypto •

    Bouncy Castle • Use a high level library • NaCL/libsodium (C, Ruby, etc) • Keyczar (Python and Java) @jtdowney 14
  15. @jtdowney 15

  16. Random Number Generation @jtdowney 16

  17. • Randomness is a central part of any crypto system

    • Used to generate: • Encryption keys • API keys • Session tokens • Password reset tokens @jtdowney 17
  18. 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 18
  19. @jtdowney 19

  20. @jtdowney 20

  21. 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 21
  22. @jtdowney 22

  23. MD_Update(&m,buf,j); @jtdowney 23

  24. Don't add uninitialised data to the random number generator. This

    stop valgrind from giving error messages in unrelated code. (Closes: #363516) @jtdowney 24
  25. /* 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 25
  26. @jtdowney 26

  27. @jtdowney 27

  28. @jtdowney 28

  29. @jtdowney 29

  30. 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 30
  31. @jtdowney 31

  32. Recommendations • Use a cryptographically strong random number generator •

    Unix-like • Read from /dev/urandom • Windows • RandomNumberGenerator in System.Security.Cryptography (.NET) • CryptGenRandom (Windows) @jtdowney 32
  33. Hash Functions @jtdowney 33

  34. Pitfalls 1. Using weak/old algorithms 2. Misunderstanding checksums 3. Length

    extension attacks @jtdowney 34
  35. @jtdowney 35

  36. @jtdowney 36

  37. @jtdowney 37

  38. @jtdowney 38

  39. 9EC4C12949A4F31474F299058CE2B22A @jtdowney 39

  40. 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 40
  41. Pitfalls 1. Using weak/old algorithms 2. Misunderstanding checksums 3. Length

    extension attacks @jtdowney 41
  42. @jtdowney 42

  43. Pitfalls 1. Using weak/old algorithms 2. Misunderstanding checksums 3. Length

    extension attacks @jtdowney 43
  44. 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 44
  45. Naive approach tag = sha256(key || value) @jtdowney 45

  46. Length Extension Attacks secret = "my-secret-key" value = "buy 10

    units at $1" signature = sha256(secret + value) @jtdowney 46
  47. Length Extension Attacks secret = "my-secret-key" value = "buy 10

    units at $1<garbage>actually make that at $0" signature = sha256(secret + value) @jtdowney 47
  48. Length Extension Attacks secret = "my-secret-key" value = "buy 10

    units at $1" signature = hmac_sha256(secret, value) @jtdowney 48
  49. @jtdowney 49

  50. @jtdowney 50

  51. 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 51
  52. Password Storage @jtdowney 52

  53. @jtdowney 53

  54. @jtdowney 54

  55. @jtdowney 55

  56. @jtdowney 56

  57. @jtdowney 57

  58. @jtdowney 58

  59. @jtdowney 59

  60. @jtdowney 60

  61. sha1(password) @jtdowney 61

  62. 1. One-way • Value can be used for verification @jtdowney

    62
  63. sha1(salt + password) @jtdowney 63

  64. 1. One-way • Value can be used for verification 2.

    Randomized • Can largely defeat pre-computed tables • Forces attackers to focus on one password @jtdowney 64
  65. Hash functions are fast @jtdowney 65

  66. 1. One-way • Value can be used for verification 2.

    Randomized • Can largely defeat pre-computed tables • Forces attackers to focus on one password 3. Slow @jtdowney 66
  67. Adaptive Hashing bcrypt, scrypt, argon2, or PBKDF2 @jtdowney 67

  68. Recommendations • Delegate authentication if possible • Facebook, Twitter, Google,

    Github • Store one-way verifiers using bcrypt, scrypt, argon2, or PBDKF2 @jtdowney 68
  69. So your password storage is bad @jtdowney 69

  70. It will be ok, you can fix it @jtdowney 70

  71. Example: password_hash column is sha1(salt || password) @jtdowney 71

  72. • Don't wait for user to login and silently upgrade

    • Wrap bcrypt around existing scheme • Use bcrypt(sha1(salt || password) • Upgrade all passwords in place • This does require the previous password scheme wasn't atrociously bad (e.g. DES crypt) @jtdowney 72
  73. Now: password_hash column is bcrypt(sha1(salt || password)) @jtdowney 73

  74. Ciphers @jtdowney 74

  75. Pitfalls 1. Using old/weak algorithms 2. Using ECB mode for

    block ciphers 3. Not using authenticated encryption @jtdowney 75
  76. @jtdowney 76

  77. @jtdowney 77

  78. @jtdowney 78

  79. Pitfalls 1. Using old/weak algorithms 2. Using ECB mode for

    block ciphers 3. Not using authenticated encryption @jtdowney 79
  80. 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 80
  81. ECB Encrypt while (remaining blocks) { block = ... #

    next 16 byte (128 bit chunk) ouput.append(AES_Encrypt(key, block)) } @jtdowney 81
  82. @jtdowney 82

  83. @jtdowney 83

  84. Pitfalls 1. Using old/weak algorithms 2. Using ECB mode for

    block ciphers 3. Not using authenticated encryption @jtdowney 84
  85. @jtdowney 85

  86. @jtdowney 86

  87. @jtdowney 87

  88. @jtdowney 88

  89. World of hurt @jtdowney 89

  90. 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 90
  91. 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 91
  92. TLS/SSL @jtdowney 92

  93. Pitfalls 1. Not verifying the certificate chain or hostname 2.

    Misconfigured server settings 3. Using a broken library @jtdowney 93
  94. @jtdowney 94

  95. @jtdowney 95

  96. 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 96
  97. $ curl -k https://example.com or curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0); curl_setopt($ch, CURLOPT_SSL_VERIFYHOST,

    0); @jtdowney 97
  98. Pitfalls 1. Not verifying the certificate chain or hostname 2.

    Misconfigured server settings 3. Using a broken library @jtdowney 98
  99. @jtdowney 99

  100. SSL Labs https://www.ssllabs.com @jtdowney 100

  101. TLS Server Settings https://mozilla.github.io/server-side-tls/ssl-config-generator/ @jtdowney 101

  102. Pitfalls 1. Not verifying the certificate chain or hostname 2.

    Misconfigured server settings 3. Using a broken library @jtdowney 102
  103. @jtdowney 103

  104. @jtdowney 104

  105. 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 105
  106. Trust @jtdowney 106

  107. 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 107
  108. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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 108
  109. @jtdowney 109

  110. Certificate Pinning @jtdowney 110

  111. @jtdowney 111

  112. Recommendations • Think about what organizations you really trust •

    Investigate certificate pinning for your apps @jtdowney 112
  113. Quantum Computers @jtdowney 113

  114. Pitfalls 1. Assuming current crypto will last forever @jtdowney 114

  115. @jtdowney 115

  116. @jtdowney 116

  117. Recommendations • Follow the PQCrypto discussion • Stay away from

    PQCrypto until the industry starts to standardize • Hope that researchers are moving fast enough @jtdowney 117
  118. @jtdowney 118

  119. Stanford Crypto Class http://crypto-class.com @jtdowney 119

  120. Matasano Crypto Challenges http://cryptopals.com @jtdowney 120

  121. Questions John Downey | @jtdowney @jtdowney 121

  122. 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 122