Thoughts on Rust Cryptography

Bay Area Rust Meetup - Mozilla SF (2014)

Video: https://www.youtube.com/watch?v=fO_ox-DGDqw

Transcript

1. Thoughts on Rust Cryptography Tony Arcieri Mozilla SF December 19th, 2014
5. This Talk • 2014: This year in cryptography • Is Rust a good language for crypto? • Survey of the Rust crypto landscape • A Rust common crypto library • Measuring timing variability in Rust
6. 2014 Year In Review
7. • Java: Bleichenbacher OOB MitM (JCE) • Apple: “goto fail” MitM (SecureTransport) • GNUTLS: “goto cleanup” MitM • OpenSSL: “Heartbleed” Memory Exposure • TLS: Triple-Handshake MitM • NSS: “BERserk” MitM (Firefox/Chrome) • SSLv3: “POODLE” ciphertext recovery • Microsoft: “Winshock” RCE (SChannel)
8. • Java: Bleichenbacher OOB MitM (JCE) • Apple: “goto fail” MitM (SecureTransport) • GNUTLS: “goto cleanup” MitM • OpenSSL: “Heartbleed” Memory Exposure • TLS: Triple-Handshake MitM • NSS: “BERserk” MitM (Firefox/Chrome) • SSLv3 (and TLS): “POODLE” ciphertext recovery • Microsoft: “Winshock” RCE (SChannel) BITES AGAIN!!!
9. Themes?
10. • Java: Bleichenbacher OOB MitM (JCE) • Apple: “goto fail” MitM (SecureTransport) • GNUTLS: “goto cleanup” MitM • OpenSSL: “Heartbleed” Memory Exposure • TLS: Triple-Handshake MitM • NSS: “BERserk” MitM (Firefox/Chrome) • SSLv3 (and TLS): “POODLE” ciphertext recovery • Microsoft: “Winshock” RCE (SChannel) SSL/TLS Design Flaws
11. • Java: Bleichenbacher OOB MitM (JCE) • Apple: “goto fail” MitM (SecureTransport) • GNUTLS: “goto cleanup” MitM • OpenSSL: “Heartbleed” Memory Exposure • TLS: Triple-Handshake MitM • NSS: “BERserk” MitM (Firefox/Chrome) • SSLv3 (and TLS): “POODLE” ciphertext recovery • Microsoft: “Winshock” RCE (SChannel) SSL/TLS Design Flaws
12. https://xkcd.com/1354/
13. • Java: Bleichenbacher OOB MitM (JCE) • Apple: “goto fail” MitM (SecureTransport) • GNUTLS: “goto cleanup” MitM • OpenSSL: “Heartbleed” Memory Exposure • TLS: Triple-Handshake MitM • NSS: “BERserk” MitM (Firefox/Chrome) • SSLv3 (and TLS): “POODLE” ciphertext recovery • Microsoft: “Winshock” RCE (SChannel) SSL/TLS Design Flaws
14. • Java: Bleichenbacher OOB MitM (JCE) • Apple: “goto fail” MitM (SecureTransport) • GNUTLS: “goto cleanup” MitM • OpenSSL: “Heartbleed” Memory Exposure • TLS: Triple-Handshake MitM • NSS: “BERserk” MitM (Firefox/Chrome) • SSLv3 (and TLS): “POODLE” ciphertext recovery • Microsoft: “Winshock” RCE (SChannel) C is a crappy language
15. “goto fail” Apple SecureTransport
16. http://tinyurl.com/tlsundersiege
17. “goto fail”
18. “goto fail” oops
19. “goto fail” dead code
20. “goto fail” mandatory braces?
21. “goto fail” automatic cleanup?
22. “goto fail” goto considered harmful maybe?
23. “goto cleanup” GNUTLS http://www.cigital.com/justice-league-blog/2014/03/07/understanding-gnutls-certificate-verification-bug/
24. GOTO BAD!!!
25. Actually, it’s about representing booleans as integers
26. _gnutls_verify_certificate2
27. _gnutls_verify_certificate2 zero == NOT CA
28. check_if_ca 0: false 1: true
29. check_if_ca
30. check_if_ca less-than-zero == ERROR
31. check_if_ca less-than-zero == ERROR
32. check_if_ca less-than-zero == ERROR
33. _gnutls_verify_certificate2 less-than-zero != zero
34. _gnutls_verify_certificate2 less-than-zero == IT’S A CA!!!
35. How do we fix this?
36. “Should’ve used != 1”
37. true and false
38. true and false and maybe get rid of goto…
39. Is zero false or true?
40. What’s going on? https://www.openssl.org/docs/ssl/SSL_shutdown.html
41. What’s going on? https://www.openssl.org/docs/ssl/SSL_shutdown.html when in doubt, call twice
42. OpenSSL
44. Which was the worst?
45. “Winshock” Microsoft SChannel Remote Code Execution
46. Remote Code Execution
47. How do we fix this?
48. Memory Safety
49. Things that might help • Dead code detection • Mandatory braces • Automatic resource management • No goto statement • true/false (and better ways of handling errors) • Memory safety
50. Is Rust a good language for crypto?
51. Things Rust has • Dead code detection • Mandatory braces • Automatic resource management • No goto statement • true/false (and better ways of handling errors) • Memory safety
52. What problems do we need to solve to create robust cryptography?
53. Timing side-channels
54. http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
55. http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
56. http://tonyarcieri.com/cream-the-scary-ssl-attack-youve-probably-never-heard-of
57. Bad: OpenSSL
58. Good: djb
59. Lucky 13 http://www.ieee-security.org/TC/SP2013/papers/4977a526.pdf
60. — Nadhem J. AlFardan and Kenneth G. Paterson "In this sense, the attacks do not pose a significant danger to ordinary users of TLS in their current form. However, it is a truism that attacks only get better with time, and we cannot anticipate what improvements to our attacks, or entirely new attacks, may yet be discovered."
61. http://www.ieee-security.org/TC/SP2013/papers/4977a526.pdf
62. https://github.com/dmayer/time_trial
63. What rules must we follow to create robust cryptographic implementations?
64. Cryptocoding.net Rules • Compare secret strings in constant time • Avoid branchings controlled by secret data • Avoid table look-ups indexed by secret data • Avoid secret-dependent loop bounds • Prevent compiler interference with security-critical operations • Prevent confusion between secure and insecure APIs • Avoid mixing security and abstraction levels of cryptographic primitives in the same API layer • Use unsigned bytes to represent binary data • Use separate types for secret and non-secret information • Use separate types for different types of information • Clean memory of secret data • Use strong randomness
65. Constant Time Operation • Compare secret strings in constant time • Avoid branchings controlled by secret data • Avoid table look-ups indexed by secret data • Avoid secret-dependent loop bounds
66. Avoid “Optimizations” • Prevent compiler interference with security- critical operations
67. Clear Abstractions • Prevent confusion between secure and insecure APIs • Avoid mixing security and abstraction levels of cryptographic primitives in the same API layer
68. Types! • Use unsigned bytes to represent binary data • Use separate types for secret and non-secret information • Use separate types for different types of information
69. Clean Up Secrets Zero out memory when done
70. Use Strong Randomess
71. People are working on solutions to all of these problems already
72. No changes to Rust needed!
75. Crypto in the standard library limits agility
76. We need all the agility we can get
77. Crypto libraries should be developed and released by crypto experts
78. Survey of the Rust crypto landscape
79. What Rust crypto libraries should I use today?
80. rust-openssl https://github.com/sfackler/rust-openssl
81. rust-openssl https://github.com/sfackler/rust-openssl
82. rust-openssl https://github.com/sfackler/rust-openssl
83. http://tinyurl.com/tlsundersiege
84. sodiumoxide https://github.com/dnaq/sodiumoxide
86. Is it safe?
87. libsodium • Portable repackaging of the Networking and Cryptography Library (NaCl a.k.a. “salt”) • Includes Ed25519 and ChaCha20 • Includes the scrypt password hashing function • Includes the Blake2 hash function • Includes SipHash • Some optional libsodium-specific utility functions
88. Pure Rust Crypto WARNING: Proceed with caution!
90. rust-crypto https://github.com/DaGenix/rust-crypto
91. rust-crypto • Promising start! • Some good implementations • Some questionable implementations • Sometimes they’re the same!
92. AES-NI “Advanced Encryption Standard New Instructions” Hardware implementation of AES from Intel
93. https://github.com/DaGenix/rust-crypto/blob/master/src/rust-crypto/aesni.rs
94. https://github.com/DaGenix/rust-crypto/blob/master/src/rust-crypto/aesni.rs o_O “aseni? Did you mean “aesni"?
95. https://github.com/DaGenix/rust-crypto/blob/master/src/rust-crypto/aesni.rs
96. asm!
97. Avoid “Optimizations” • Prevent compiler interference with security- critical operations
98. https://github.com/DaGenix/rust-crypto/blob/master/src/rust-crypto/aesni.rs
99. https://github.com/DaGenix/rust-crypto/blob/master/src/rust-crypto/aesni.rs
100. Fast and safe!
101. rust-crypto tl;dr • Good effort! • No immediate security problems on cursory inspection • Clear signs the code has not been well-reviewed • Needs more expert scrutiny to be trusted
102. TARS Protected memory buffers for Rust https://github.com/seb-m/tars
103. Protect Keys! • mprotect! PROT_NONE guard pages • mlock! prevents keys from being swapped out • volatile zero on drop
104. rust-consttime WARNING: DO NOT USE THIS!!!!!!!!!!
106. Warning: While this library tries to avoid branches or input-dependent memory operations, the code optimizer may reintroduce them and you should carefully verify the assembly in order to use this.
107. you should carefully verify the assembly in order to use this.
109. How do we escape from LLVM’s optimizations?
110. asm!
111. ASM Problems • Architecture specific • Hard to write • Error-prone • Difficult to verify
112. Is it possible to generate constant-time assembly from Rust source code?
113. nadeko Constant-time syntax extension for a limited subset of Rust https://github.com/klutzy/nadeko
114. BLACK F&@KING MAGIC! WARNING:
116. Is it constant time?
117. NOPE!
118. NOPE! THANKS LLVM!
119. With nadeko No branches!
120. ROT13 Super-secure constant time version
123. nadeko • Constant-time arithmetic and bitwise ops • Constant-time basic “if” • No support for “for” yet
124. suruga Ultra-modern (i.e. practically useless) TLS stack https://github.com/klutzy/suruga
126. Towards a Rust common crypto library
127. What should a common crypto library provide?
128. Isn’t that just
 rust-crypto?
129. Shared Unsafe Code rust-openssl sodiumoxide rust-crypto Encapsulate and reuse unsafe primitives
130. Rust Common Crypto • Handle zeroing buffers on drop • Protected buffers for keys (ala TARS) • Traits! Traits! Traits! • Constant-time primitives (ala Nadeko)
131. sodiumoxide example
132. sodiumoxide example
133. sodiumoxide example
134. Can we do better?
135. Common crypto library • Common foundation for all crypto libraries • Solve unsafe concerns in one place • Solve constant-time operation in one place • Promote interoperability
136. Measuring timing variability in Rust
137. Verifying constant time operation requires counting CPU cycles
138. Modern CPU • Example clock speed: 2.5 GHz • 2,500,000,000 CPU cycles per second • 0.4 nanoseconds per cycle • 400 picoseconds per cycle
139. Mind Your Nanoseconds!
140. How do we measure CPU cycles?
141. Timestamp Counter (TSC)
142. RDTSC in Rust TSC: 85211194993141998
143. Cyclometer https://github.com/cryptosphere/cyclometer
144. Cyclometer • Automated testing for data-dependent timing variability in Rust cryptographic libraries • Use RDTSC to measure timing • Collect a large number of samples and apply statistical test (e.g. Box Test) to determine if timing variability is distinguishable
145. Lucky 13 http://www.ieee-security.org/TC/SP2013/papers/4977a526.pdf
146. Automatically detect data-dependent timing
147. Vaporware Pull requests accepted!
148. Final thoughts • Rust has immense potential for cryptography but we must tread carefully • Rust code without any branches isn’t necessarily constant time. Beware LLVM! • Stick with wrappers to mainstream crypto libraries until pure Rust crypto is more mature
149. Join the Rust crypto IRC channel! irc.mozilla.org:6697 #rust-crypto
150. That’s all folks!
151. Twitter @bascule Blog tonyarcieri.com IRC Mozilla: bascule Freenode: tarcieri