Cryptography Pitfalls at Little Rock Tech Fest 2015

Cryptography Pitfalls at Little Rock Tech Fest 2015

58376779023f009fc13d160bb3e82515?s=128

John Downey

October 16, 2015
Tweet

Transcript

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

  2. @jtdowney 2

  3. @jtdowney 3

  4. Chicago @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 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 the right random number generator 2.

    Broken random 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. Pitfalls 1. Not using the right random number generator 2.

    Broken random random number generators 3. Not using random data when it is required @jtdowney 27
  28. @jtdowney 28

  29. Recommendations • Unix-like • Read from /dev/urandom • Windows •

    RandomNumberGenerator.Create() (.NET) • CryptGenRandom (Windows) @jtdowney 29
  30. Hash Functions @jtdowney 30

  31. • Often called a fingerprint • One way • Not

    reversible (can’t find person without fingerprint DB) • Ideally, no two people with same fingerprint (no two inputs) @jtdowney 31
  32. Pitfalls 1. Using weak/old algorithms 2. Misunderstanding checksums 3. Length

    extension attacks @jtdowney 32
  33. @jtdowney 33

  34. @jtdowney 34

  35. @jtdowney 35

  36. @jtdowney 36

  37. 9EC4C12949A4F31474F299058CE2B22A @jtdowney 37

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

    extension attacks @jtdowney 39
  40. @jtdowney 40

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

    extension attacks @jtdowney 41
  42. Length Extension Attacks secret = "my-secret-key" value = "buy 10

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

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

    units at $1" signature = hmac_sha256(secret, value) @jtdowney 44
  45. Message Authentication Code (MAC) tag = hmac_sha256(key, value) • key

    - shared secret • value - value to protected integrity of • tag - value that represents the integrity @jtdowney 45
  46. @jtdowney 46

  47. 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 47
  48. Password Storage @jtdowney 48

  49. @jtdowney 49

  50. @jtdowney 50

  51. @jtdowney 51

  52. @jtdowney 52

  53. @jtdowney 53

  54. @jtdowney 54

  55. sha1(password) @jtdowney 55

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

    56
  57. sha1(salt + password) @jtdowney 57

  58. 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 58
  59. Hash functions are fast @jtdowney 59

  60. 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 60
  61. Adaptive Hashing bcrypt, scrypt, or PBKDF2 @jtdowney 61

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

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

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

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

  66. • 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 @jtdowney 66
  67. Now: password_hash column is bcrypt(sha1(salt || password)) @jtdowney 67

  68. Block Ciphers @jtdowney 68

  69. Pitfalls 1. Using old/weak algorithms 2. Using ECB mode 3.

    Not using authenticated encryption @jtdowney 69
  70. @jtdowney 70

  71. Pitfalls 1. Using old/weak algorithms 2. Using ECB mode 3.

    Not using authenticated encryption @jtdowney 71
  72. 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 72
  73. ECB Encrypt while (remaining blocks) { block = ... #

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

  75. @jtdowney 75

  76. Pitfalls 1. Using old/weak algorithms 2. Using ECB mode 3.

    Not using authenticated encryption @jtdowney 76
  77. @jtdowney 77

  78. World of hurt @jtdowney 78

  79. Recommendations • Prefer to use box/secret box from NaCL/libsodium •

    Stop using DES • Stop building your own on top of AES @jtdowney 79
  80. 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 80
  81. Stream Ciphers @jtdowney 81

  82. XOR Refresher @jtdowney 82

  83. XOR Refresher A xor 0 = A A xor A

    = 0 A xor B = C A xor C = B B xor C = A A xor A xor B = B @jtdowney 83
  84. Encrypting keystream = expand(key) # => "\x84\x859\x87\xBC\x15\x91\x01N\xD4^\xA0\xAC371" message = 'attack

    at dawn' ciphertext = message xor keystream # => "\xE5\xF1M\xE6\xDF~\xB1`:\xF4:\xC1\xDB]" @jtdowney 84
  85. Decrypting keystream = expand(key) # => "\x84\x859\x87\xBC\x15\x91\x01N\xD4^\xA0\xAC371" message = ciphertext

    xor keystream # => 'attack at dawn' @jtdowney 85
  86. Pitfalls 1. Using old/weak algorithms 2. Reusing the same key

    3. Not using authenticated encryption @jtdowney 86
  87. @jtdowney 87

  88. @jtdowney 88

  89. Pitfalls 1. Using old/weak algorithms 2. Reusing the same key

    3. Not using authenticated encryption @jtdowney 89
  90. keystream = expand(key) message1 = 'attack at dawn' ciphertext1 =

    message1 xor keystream message2 = 'attack at dusk' ciphertext2 = message2 xor keystream @jtdowney 90
  91. (ciphertext1) xor (ciphertext2) ! ! (message1 xor keystream) xor (message2

    xor keystream) @jtdowney 91
  92. message1 xor keystream xor message2 xor keystream @jtdowney 92

  93. message1 xor message2 @jtdowney 93

  94. @jtdowney 94

  95. Pitfalls 1. Using old/weak algorithms 2. Reusing the same key

    3. Not using authenticated encryption @jtdowney 95
  96. General 1 keystream = expand(key) message = 'attack at dawn'

    ciphertext = message xor keystream @jtdowney 96
  97. Spy tweak = "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x14\x04\x05" new_ciphertext = message xor tweak @jtdowney

    97
  98. General 2 keystream = expand(key) message = new_ciphertext xor keystream

    message = 'attack at dusk' @jtdowney 98
  99. General 2 message = (new_ciphertext) xor keystream ! message =

    (ciphertext xor tweak) xor keystream @jtdowney 99
  100. General 2 'attack at dawn' xor tweak 'attack at dusk'

    @jtdowney 100
  101. Recommendations • Use box/secret box from NaCL/libsodium • Stop using

    RC4 • Ensure you don't reuse keys • This means reusing nonces as well • Always protect ciphertext integrity (i.e. with a MAC) @jtdowney 101
  102. TLS/SSL Verification @jtdowney 102

  103. @jtdowney 103

  104. Pitfalls 1. Not verifying the certificate chain 2. Not verifying

    the hostname 3. Using a broken library @jtdowney 104
  105. @jtdowney 105

  106. $ curl -k https://example.com or curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0); @jtdowney 106

  107. Pitfalls 1. Not verifying the certificate chain 2. Not verifying

    the hostname 3. Using a broken library @jtdowney 107
  108. • Hostname verification is protocol dependent • OpenSSL doesn't have

    it built in • Also, some people just turn it off: curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0); @jtdowney 108
  109. Pitfalls 1. Not verifying the certificate chain 2. Not verifying

    the hostname 3. Using a broken library @jtdowney 109
  110. @jtdowney 110

  111. @jtdowney 111

  112. 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 112
  113. TLS Server Settings https://mozilla.github.io/server-side-tls/ssl-config-generator/ @jtdowney 113

  114. Trust @jtdowney 114

  115. 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 115
  116. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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 116
  117. AOL Time Warner Inc. AS Sertifitseerimiskeskus AddTrust Baltimore beTRUSTed Buypass

    CNNIC COMODO CA Limited Certplus certSIGN Chambersign Chunghwa Telecom Co., Ltd. ComSign Comodo CA Limited Cybertrust, Inc Deutsche Telekom AG Deutscher Sparkassen Verlag GmbH Dhimyotis DigiCert Inc DigiNotar Digital Signature Trust Co. Disig a.s. EBG Bilişim Teknolojileri ve Hizmetleri A.Ş. EDICOM Entrust, Inc. Equifax GTE Corporation GeoTrust Inc. GlobalSign nv-sa Hongkong Post Japan Certification Services, Inc. Japanese Government Microsec Ltd. NetLock Halozatbiztonsagi Kft. Network Solutions L.L.C. PM/SGDN QuoVadis Limited RSA Security Inc SECOM Trust Systems CO.,LTD. SecureTrust Corporation Sociedad Cameral de Certificación Digital Sonera Staat der Nederlanden Starfield Technologies, Inc. StartCom Ltd. SwissSign AG Swisscom TC TrustCenter GmbH TDC Taiwan Government Thawte The Go Daddy Group, Inc. The USERTRUST Network TÜBİTAK TÜRKTRUST Unizeto Sp. z o.o. VISA ValiCert, Inc. VeriSign, Inc. WISeKey Wells Fargo XRamp Security Services Inc @jtdowney 117
  118. Certificate Pinning @jtdowney 118

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

    Investigate certificate pinning for your apps @jtdowney 119
  120. @jtdowney 120

  121. Stanford Crypto Class https://www.coursera.org/course/crypto @jtdowney 121

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

  123. Questions John Downey | @jtdowney @jtdowney 123

  124. 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 @jtdowney 124