Cryptography Pitfalls at CactusCon 2019

58376779023f009fc13d160bb3e82515?s=47 John Downey
December 06, 2019

Cryptography Pitfalls at CactusCon 2019

58376779023f009fc13d160bb3e82515?s=128

John Downey

December 06, 2019
Tweet

Transcript

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

  2. @jtdowney 2

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

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

  5. Confidentiality @jtdowney 5

  6. Authentication @jtdowney 6

  7. Identification @jtdowney 7

  8. Rigorous Science @jtdowney 8

  9. Peer Review @jtdowney 9

  10. @jtdowney 10

  11. 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 11
  12. • For data in transit • Use TLS, SSH, or

    VPN/IPsec • For data at rest • Use GnuPG • Data to be signed • Use GnuPG @jtdowney 12
  13. • Avoid low level libraries • OpenSSL • PyCrypto •

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

  15. Random Number Generation @jtdowney 15

  16. Pitfalls 1. Not using a cryptographically strong random number generator

    2. Not using random data when it is required 3. Broken random number generators @jtdowney 16
  17. @jtdowney 17

  18. @jtdowney 18

  19. Pitfalls 1. Not using a cryptographically strong random number generator

    2. Not using random data when it is required 3. Broken random number generators @jtdowney 19
  20. @jtdowney 20

  21. Pitfalls 1. Not using a cryptographically strong random number generator

    2. Not using random data when it is required 3. Broken random number generators @jtdowney 21
  22. @jtdowney 22

  23. @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. Recommendations • Use a cryptographically strong random number generator •

    Unix-like • Read from /dev/urandom • Windows • RandomNumberGenerator in System.Security.Cryptography (.NET) • CryptGenRandom • Java use java.security.SecureRandom @jtdowney 29
  30. Hash Functions @jtdowney 30

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

    extension attacks @jtdowney 31
  32. @jtdowney 32

  33. @jtdowney 33

  34. @jtdowney 34

  35. @jtdowney 35

  36. 9EC4C12949A4F31474F299058CE2B22A @jtdowney 36

  37. 9EC4C12949A4F31474F299058CE2B22A 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. @jtdowney 37
  38. Pitfalls 1. Using weak/old algorithms 2. Misunderstanding checksums 3. Length

    extension attacks @jtdowney 38
  39. @jtdowney 39

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

    extension attacks @jtdowney 40
  41. 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 41
  42. Naive approach tag = sha256(key + value) @jtdowney 42

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

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

    units at $1" + " or $0" signature = sha256(secret + value) @jtdowney 44
  45. Fixed secret = "my-secret-key" value = "buy 10 units at

    $1" signature = hmac_sha256(secret, value) @jtdowney 45
  46. @jtdowney 46

  47. @jtdowney 47

  48. Recommendations • Use SHA-256 (SHA-2 family) • Choose HMAC-SHA-256 if

    you want a signature • Use BLAKE2b if you need speed • Stop using MD5 • Stop using SHA1 @jtdowney 48
  49. Ciphers @jtdowney 49

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

    block ciphers 3. Not using authenticated encryption @jtdowney 50
  51. @jtdowney 51

  52. @jtdowney 52

  53. @jtdowney 53

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

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

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

  58. @jtdowney 58

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

    block ciphers 3. Not using authenticated encryption @jtdowney 59
  60. @jtdowney 60

  61. @jtdowney 61

  62. @jtdowney 62

  63. @jtdowney 63

  64. World of hurt @jtdowney 64

  65. 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 65
  66. 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 66
  67. TLS/SSL @jtdowney 67

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

    Misconfigured server settings 3. Using a broken library 4. Shipping your private key @jtdowney 68
  69. @jtdowney 69

  70. @jtdowney 70

  71. @jtdowney 71

  72. @jtdowney 72

  73. Hostname verification @jtdowney 73

  74. 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 74
  75. Pitfalls 1. Not verifying the certificate chain or hostname 2.

    Misconfigured server settings 3. Using a broken library 4. Shipping your private key @jtdowney 75
  76. @jtdowney 76

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

  78. testssl.sh https://testssl.sh @jtdowney 78

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

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

    Misconfigured server settings 3. Using a broken library 4. Shipping your private key @jtdowney 80
  81. @jtdowney 81

  82. @jtdowney 82

  83. 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 83
  84. Pitfalls 1. Not verifying the certificate chain or hostname 2.

    Misconfigured server settings 3. Using a broken library 4. Shipping your private key @jtdowney 84
  85. @jtdowney 85

  86. Trust @jtdowney 86

  87. 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 87
  88. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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 88
  89. @jtdowney 89

  90. Certificate Pinning @jtdowney 90

  91. @jtdowney 91

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

    Investigate certificate pinning for your apps @jtdowney 92
  93. @jtdowney 93

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

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

  96. Questions John Downey | @jtdowney @jtdowney 96

  97. Bonus Round @jtdowney 97

  98. Quantum Computers @jtdowney 98

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

  100. @jtdowney 100

  101. @jtdowney 101

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

    PQCrypto until the industry starts to standardize • Hope that researchers are moving fast enough @jtdowney 102
  103. 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 • https://flic.kr/p/5tWgh4 @jtdowney 103