can cryptographic software bob s laptop screen be fixed
play

Can cryptographic software Bobs laptop screen: be fixed? From: - PowerPoint PPT Presentation

1 2 Can cryptographic software Bobs laptop screen: be fixed? From: Alice D. J. Bernstein Thank you for your submission. We received many interesting papers, and unfortunately your Bob assumes this message is something Alice actually


  1. 3 4 Trusted computing base (TCB) Examples of attack strategies: 2018) code: TCB: portion of computer system 1. Attacker uses buffer overflo that is responsible for enforcing in a device driver to control the users’ security policy. Linux kernel on Alice’s laptop. etc. Security policy for this talk: If message is displayed on messages. Bob’s screen as “ From: Alice ” fixed in 61: then message is from Alice. If TCB works correctly, size then message is guaranteed CVE-2018- to be from Alice, no matter what when the rest of the system does. CVE-2018-12361, SwizzleData”.

  2. 4 5 Trusted computing base (TCB) Examples of attack strategies: TCB: portion of computer system 1. Attacker uses buffer overflow that is responsible for enforcing in a device driver to control the users’ security policy. Linux kernel on Alice’s laptop. Security policy for this talk: If message is displayed on Bob’s screen as “ From: Alice ” then message is from Alice. If TCB works correctly, then message is guaranteed to be from Alice, no matter what the rest of the system does.

  3. 4 5 Trusted computing base (TCB) Examples of attack strategies: TCB: portion of computer system 1. Attacker uses buffer overflow that is responsible for enforcing in a device driver to control the users’ security policy. Linux kernel on Alice’s laptop. Security policy for this talk: 2. Attacker uses buffer overflow If message is displayed on in a web browser to control Bob’s screen as “ From: Alice ” disk files on Bob’s laptop. then message is from Alice. If TCB works correctly, then message is guaranteed to be from Alice, no matter what the rest of the system does.

  4. 4 5 Trusted computing base (TCB) Examples of attack strategies: TCB: portion of computer system 1. Attacker uses buffer overflow that is responsible for enforcing in a device driver to control the users’ security policy. Linux kernel on Alice’s laptop. Security policy for this talk: 2. Attacker uses buffer overflow If message is displayed on in a web browser to control Bob’s screen as “ From: Alice ” disk files on Bob’s laptop. then message is from Alice. Device driver is in the TCB. If TCB works correctly, Web browser is in the TCB. then message is guaranteed CPU is in the TCB. Etc. to be from Alice, no matter what the rest of the system does.

  5. 4 5 Trusted computing base (TCB) Examples of attack strategies: TCB: portion of computer system 1. Attacker uses buffer overflow that is responsible for enforcing in a device driver to control the users’ security policy. Linux kernel on Alice’s laptop. Security policy for this talk: 2. Attacker uses buffer overflow If message is displayed on in a web browser to control Bob’s screen as “ From: Alice ” disk files on Bob’s laptop. then message is from Alice. Device driver is in the TCB. If TCB works correctly, Web browser is in the TCB. then message is guaranteed CPU is in the TCB. Etc. to be from Alice, no matter what Massive TCB has many bugs, the rest of the system does. including many security holes. Any hope of fixing this?

  6. 4 5 rusted computing base (TCB) Examples of attack strategies: Classic sec portion of computer system 1. Attacker uses buffer overflow Rearchitect responsible for enforcing in a device driver to control to have a users’ security policy. Linux kernel on Alice’s laptop. Security policy for this talk: 2. Attacker uses buffer overflow message is displayed on in a web browser to control screen as “ From: Alice ” disk files on Bob’s laptop. message is from Alice. Device driver is in the TCB. works correctly, Web browser is in the TCB. message is guaranteed CPU is in the TCB. Etc. from Alice, no matter what Massive TCB has many bugs, rest of the system does. including many security holes. Any hope of fixing this?

  7. 4 5 computing base (TCB) Examples of attack strategies: Classic security strategy: computer system 1. Attacker uses buffer overflow Rearchitect computer onsible for enforcing in a device driver to control to have a much smaller security policy. Linux kernel on Alice’s laptop. for this talk: 2. Attacker uses buffer overflow displayed on in a web browser to control “ From: Alice ” disk files on Bob’s laptop. from Alice. Device driver is in the TCB. rrectly, Web browser is in the TCB. guaranteed CPU is in the TCB. Etc. Alice, no matter what Massive TCB has many bugs, system does. including many security holes. Any hope of fixing this?

  8. 4 5 (TCB) Examples of attack strategies: Classic security strategy: system 1. Attacker uses buffer overflow Rearchitect computer systems rcing in a device driver to control to have a much smaller TCB Linux kernel on Alice’s laptop. talk: 2. Attacker uses buffer overflow in a web browser to control Alice ” disk files on Bob’s laptop. Alice. Device driver is in the TCB. Web browser is in the TCB. ranteed CPU is in the TCB. Etc. matter what Massive TCB has many bugs, es. including many security holes. Any hope of fixing this?

  9. 5 6 Examples of attack strategies: Classic security strategy: 1. Attacker uses buffer overflow Rearchitect computer systems in a device driver to control to have a much smaller TCB. Linux kernel on Alice’s laptop. 2. Attacker uses buffer overflow in a web browser to control disk files on Bob’s laptop. Device driver is in the TCB. Web browser is in the TCB. CPU is in the TCB. Etc. Massive TCB has many bugs, including many security holes. Any hope of fixing this?

  10. 5 6 Examples of attack strategies: Classic security strategy: 1. Attacker uses buffer overflow Rearchitect computer systems in a device driver to control to have a much smaller TCB. Linux kernel on Alice’s laptop. Carefully audit the TCB. 2. Attacker uses buffer overflow in a web browser to control disk files on Bob’s laptop. Device driver is in the TCB. Web browser is in the TCB. CPU is in the TCB. Etc. Massive TCB has many bugs, including many security holes. Any hope of fixing this?

  11. 5 6 Examples of attack strategies: Classic security strategy: 1. Attacker uses buffer overflow Rearchitect computer systems in a device driver to control to have a much smaller TCB. Linux kernel on Alice’s laptop. Carefully audit the TCB. 2. Attacker uses buffer overflow e.g. Bob runs many VMs: in a web browser to control VM A VM C disk files on Bob’s laptop. · · · Alice data Charlie data Device driver is in the TCB. TCB stops each VM from Web browser is in the TCB. touching data in other VMs. CPU is in the TCB. Etc. Massive TCB has many bugs, including many security holes. Any hope of fixing this?

  12. 5 6 Examples of attack strategies: Classic security strategy: 1. Attacker uses buffer overflow Rearchitect computer systems in a device driver to control to have a much smaller TCB. Linux kernel on Alice’s laptop. Carefully audit the TCB. 2. Attacker uses buffer overflow e.g. Bob runs many VMs: in a web browser to control VM A VM C disk files on Bob’s laptop. · · · Alice data Charlie data Device driver is in the TCB. TCB stops each VM from Web browser is in the TCB. touching data in other VMs. CPU is in the TCB. Etc. Browser in VM C isn’t in TCB. Massive TCB has many bugs, Can’t touch data in VM A, including many security holes. if TCB works correctly. Any hope of fixing this?

  13. 5 6 Examples of attack strategies: Classic security strategy: 1. Attacker uses buffer overflow Rearchitect computer systems in a device driver to control to have a much smaller TCB. Linux kernel on Alice’s laptop. Carefully audit the TCB. 2. Attacker uses buffer overflow e.g. Bob runs many VMs: in a web browser to control VM A VM C disk files on Bob’s laptop. · · · Alice data Charlie data Device driver is in the TCB. TCB stops each VM from Web browser is in the TCB. touching data in other VMs. CPU is in the TCB. Etc. Browser in VM C isn’t in TCB. Massive TCB has many bugs, Can’t touch data in VM A, including many security holes. if TCB works correctly. Any hope of fixing this? Alice also runs many VMs.

  14. 5 6 Examples of attack strategies: Classic security strategy: Focus of ttacker uses buffer overflow Rearchitect computer systems How does device driver to control to have a much smaller TCB. that incoming Linux kernel on Alice’s laptop. is from Alice’s Carefully audit the TCB. ttacker uses buffer overflow Cryptographic e.g. Bob runs many VMs: web browser to control Message-authentication VM A VM C files on Bob’s laptop. · · · Alice data Charlie data Alice’s driver is in the TCB. TCB stops each VM from rowser is in the TCB. touching data in other VMs. authenticated is in the TCB. Etc. Browser in VM C isn’t in TCB. authenticated Massive TCB has many bugs, Can’t touch data in VM A, including many security holes. if TCB works correctly. hope of fixing this? Alice’s Alice also runs many VMs.

  15. � � � 5 6 attack strategies: Classic security strategy: Focus of this talk: buffer overflow Rearchitect computer systems How does Bob’s laptop driver to control to have a much smaller TCB. that incoming netw on Alice’s laptop. is from Alice’s laptop? Carefully audit the TCB. buffer overflow Cryptographic solution: e.g. Bob runs many VMs: wser to control Message-authentication VM A VM C Bob’s laptop. · · · Alice data Charlie data Alice’s message in the TCB. TCB stops each VM from in the TCB. touching data in other VMs. authenticated message TCB. Etc. untrusted Browser in VM C isn’t in TCB. authenticated message has many bugs, Can’t touch data in VM A, security holes. if TCB works correctly. fixing this? Alice’s message Alice also runs many VMs.

  16. � � � � 5 6 strategies: Classic security strategy: Focus of this talk: Cryptography overflow Rearchitect computer systems How does Bob’s laptop know control to have a much smaller TCB. that incoming network data laptop. is from Alice’s laptop? Carefully audit the TCB. overflow Cryptographic solution: e.g. Bob runs many VMs: control Message-authentication codes. VM A VM C laptop. · · · Alice data Charlie data Alice’s message TCB. TCB stops each VM from TCB. touching data in other VMs. authenticated message untrusted netwo Browser in VM C isn’t in TCB. authenticated message bugs, Can’t touch data in VM A, holes. if TCB works correctly. Alice’s message � Alice also runs many VMs.

  17. � � � � � 6 7 Classic security strategy: Focus of this talk: Cryptography Rearchitect computer systems How does Bob’s laptop know to have a much smaller TCB. that incoming network data is from Alice’s laptop? Carefully audit the TCB. Cryptographic solution: e.g. Bob runs many VMs: Message-authentication codes. VM A VM C · · · Alice data Charlie data Alice’s message k TCB stops each VM from touching data in other VMs. authenticated message untrusted network Browser in VM C isn’t in TCB. authenticated message Can’t touch data in VM A, if TCB works correctly. Alice’s message k Alice also runs many VMs.

  18. � � � � � 6 7 Classic security strategy: Focus of this talk: Cryptography Rearchitect computer systems How does Bob’s laptop know to have a much smaller TCB. that incoming network data is from Alice’s laptop? Carefully audit the TCB. Cryptographic solution: e.g. Bob runs many VMs: Message-authentication codes. VM A VM C · · · Alice data Charlie data Alice’s message k TCB stops each VM from touching data in other VMs. authenticated message untrusted network Browser in VM C isn’t in TCB. modified message Can’t touch data in VM A, if TCB works correctly. “Alert: forgery!” k Alice also runs many VMs.

  19. � � � � � 6 7 security strategy: Focus of this talk: Cryptography Important to share rchitect computer systems How does Bob’s laptop know have a much smaller TCB. that incoming network data What if is from Alice’s laptop? on their refully audit the TCB. Cryptographic solution: Bob runs many VMs: Message-authentication codes. A VM C · · · data Charlie data Alice’s message k stops each VM from touching data in other VMs. authenticated message untrusted network wser in VM C isn’t in TCB. modified message touch data in VM A, works correctly. “Alert: forgery!” k also runs many VMs.

  20. � � � � � 6 7 strategy: Focus of this talk: Cryptography Important for Alice to share the same computer systems How does Bob’s laptop know smaller TCB. that incoming network data What if attacker w is from Alice’s laptop? on their communication the TCB. Cryptographic solution: many VMs: Message-authentication codes. VM C · · · Charlie data Alice’s message k VM from other VMs. authenticated message untrusted network C isn’t in TCB. modified message ta in VM A, rrectly. “Alert: forgery!” k many VMs.

  21. � � � � � 6 7 Focus of this talk: Cryptography Important for Alice and Bob to share the same secret k . systems How does Bob’s laptop know TCB. that incoming network data What if attacker was spying is from Alice’s laptop? on their communication of k Cryptographic solution: Message-authentication codes. · · · Alice’s message k VMs. authenticated message untrusted network TCB. modified message A, “Alert: forgery!” k VMs.

  22. � � � � � 7 8 Focus of this talk: Cryptography Important for Alice and Bob to share the same secret k . How does Bob’s laptop know that incoming network data What if attacker was spying is from Alice’s laptop? on their communication of k ? Cryptographic solution: Message-authentication codes. Alice’s message k authenticated message untrusted network modified message “Alert: forgery!” k

  23. � � � � � � � � � � � � 7 8 Focus of this talk: Cryptography Important for Alice and Bob to share the same secret k . How does Bob’s laptop know that incoming network data What if attacker was spying is from Alice’s laptop? on their communication of k ? Cryptographic solution: Solution 1: Message-authentication codes. Public-key encryption. Alice’s message private key a k k authenticated message ciphertext public key aG untrusted network network network modified message ciphertext public key aG “Alert: forgery!” k k

  24. � � � � � � � � � � � � � � � 7 8 of this talk: Cryptography Important for Alice and Bob Solution to share the same secret k . Public-key does Bob’s laptop know incoming network data What if attacker was spying m Alice’s laptop? on their communication of k ? signed message Cryptographic solution: Solution 1: Message-authentication codes. Public-key encryption. signed message Alice’s message private key a k k m authenticated message ciphertext public key aG untrusted network network network dified message ciphertext public key aG “Alert: forgery!” k k

  25. � � � � � � � � � � � � 7 8 talk: Cryptography Important for Alice and Bob Solution 2: to share the same secret k . Public-key signatures. laptop know network data What if attacker was spying m laptop? on their communication of k ? signed message solution: Solution 1: network Message-authentication codes. Public-key encryption. signed message message private key a k k � � m message ciphertext public key aG untrusted network network network message ciphertext public key aG rgery!” k k

  26. � � � � � � � � � � � � � � 7 8 Cryptography Important for Alice and Bob Solution 2: to share the same secret k . Public-key signatures. know data What if attacker was spying m a on their communication of k ? signed message aG Solution 1: network net des. Public-key encryption. signed message aG private key a k k m ciphertext public key aG work network network ciphertext public key aG k k

  27. � � � � � � � � � � � � � � 8 9 Important for Alice and Bob Solution 2: to share the same secret k . Public-key signatures. What if attacker was spying m a on their communication of k ? signed message aG Solution 1: network network Public-key encryption. signed message aG private key a k m ciphertext public key aG network network ciphertext public key aG k

  28. � � � � � � � � � � � � � � 8 9 Important for Alice and Bob Solution 2: to share the same secret k . Public-key signatures. What if attacker was spying m a on their communication of k ? signed message aG Solution 1: network network Public-key encryption. signed message aG private key a k m ciphertext public key aG Fantasy world: software for network network authentication/encryption/sigs ciphertext public key aG is small and carefully audited ⇒ no cryptographic security failures. k

  29. � � � � � � � � � � � 8 9 rtant for Alice and Bob Solution 2: Real world: re the same secret k . Public-key signatures. Cryptographic if attacker was spying is huge. m a their communication of k ? of many signed message aG Solution 1: Most complications network network Public-key encryption. signed message aG private key a m ciphertext public key aG Fantasy world: software for network network authentication/encryption/sigs ciphertext public key aG is small and carefully audited ⇒ no cryptographic security failures.

  30. � � � � � � � � � 8 9 Alice and Bob Solution 2: Real world: same secret k . Public-key signatures. Cryptographic part was spying is huge. Many implementations m a communication of k ? of many cryptograph signed message aG Most complications network network encryption. signed message aG private key a m public key aG Fantasy world: software for network authentication/encryption/sigs public key aG is small and carefully audited ⇒ no cryptographic security failures.

  31. � � � � � � � 8 9 Bob Solution 2: Real world: . Public-key signatures. Cryptographic part of the TCB ying is huge. Many implementations m a of k ? of many cryptographic primitives. signed message aG Most complications are for sp network network signed message aG key a m y aG Fantasy world: software for network authentication/encryption/sigs y aG is small and carefully audited ⇒ no cryptographic security failures.

  32. � � � � � � � 9 10 Solution 2: Real world: Public-key signatures. Cryptographic part of the TCB is huge. Many implementations m a of many cryptographic primitives. signed message aG Most complications are for speed. network network signed message aG m Fantasy world: software for authentication/encryption/sigs is small and carefully audited ⇒ no cryptographic security failures.

  33. � � � � � � � 9 10 Solution 2: Real world: Public-key signatures. Cryptographic part of the TCB is huge. Many implementations m a of many cryptographic primitives. signed message aG Most complications are for speed. network network e.g. February 2018: Google adds signed message aG NSA’s Speck cipher to Linux kernel using hand-written asm m for ARM Cortex-A7 processors. Fantasy world: software for authentication/encryption/sigs is small and carefully audited ⇒ no cryptographic security failures.

  34. � � � � � � � 9 10 Solution 2: Real world: Public-key signatures. Cryptographic part of the TCB is huge. Many implementations m a of many cryptographic primitives. signed message aG Most complications are for speed. network network e.g. February 2018: Google adds signed message aG NSA’s Speck cipher to Linux kernel using hand-written asm m for ARM Cortex-A7 processors. Fantasy world: software for August 2018: Google switches authentication/encryption/sigs from Speck to ChaCha12, again is small and carefully audited ⇒ using hand-written assembly. no cryptographic security failures. Why not ChaCha20? Speed.

  35. � � � � � � � 9 10 Solution 2: Real world: Keccak (SHA-3) Public-key signatures. “Keccak Cryptographic part of the TCB > 20 optimized is huge. Many implementations m a of Keccak: of many cryptographic primitives. Includes message aG Most complications are for speed. many further network network e.g. February 2018: Google adds message aG NSA’s Speck cipher to Linux kernel using hand-written asm m for ARM Cortex-A7 processors. antasy world: software for August 2018: Google switches authentication/encryption/sigs from Speck to ChaCha12, again small and carefully audited ⇒ using hand-written assembly. cryptographic security failures. Why not ChaCha20? Speed.

  36. � � 9 10 Real world: Keccak (SHA-3) team signatures. “Keccak Code Pack Cryptographic part of the TCB > 20 optimized implementations is huge. Many implementations a of Keccak: AVX2, of many cryptographic primitives. Includes “parallel Keccak”: aG Most complications are for speed. many further implementations. network e.g. February 2018: Google adds aG NSA’s Speck cipher to Linux kernel using hand-written asm for ARM Cortex-A7 processors. software for August 2018: Google switches authentication/encryption/sigs from Speck to ChaCha12, again refully audited ⇒ using hand-written assembly. security failures. Why not ChaCha20? Speed.

  37. 9 10 Real world: Keccak (SHA-3) team maintains “Keccak Code Package” with Cryptographic part of the TCB > 20 optimized implementations is huge. Many implementations of Keccak: AVX2, NEON, etc. of many cryptographic primitives. Includes “parallel Keccak”: Most complications are for speed. many further implementations. network e.g. February 2018: Google adds NSA’s Speck cipher to Linux kernel using hand-written asm for ARM Cortex-A7 processors. r August 2018: Google switches authentication/encryption/sigs from Speck to ChaCha12, again audited ⇒ using hand-written assembly. failures. Why not ChaCha20? Speed.

  38. 10 11 Real world: Keccak (SHA-3) team maintains “Keccak Code Package” with Cryptographic part of the TCB > 20 optimized implementations is huge. Many implementations of Keccak: AVX2, NEON, etc. of many cryptographic primitives. Includes “parallel Keccak”: Most complications are for speed. many further implementations. e.g. February 2018: Google adds NSA’s Speck cipher to Linux kernel using hand-written asm for ARM Cortex-A7 processors. August 2018: Google switches from Speck to ChaCha12, again using hand-written assembly. Why not ChaCha20? Speed.

  39. 10 11 Real world: Keccak (SHA-3) team maintains “Keccak Code Package” with Cryptographic part of the TCB > 20 optimized implementations is huge. Many implementations of Keccak: AVX2, NEON, etc. of many cryptographic primitives. Includes “parallel Keccak”: Most complications are for speed. many further implementations. e.g. February 2018: Google adds Why not portable C code using NSA’s Speck cipher to Linux “optimizing” compiler? Slower. kernel using hand-written asm for ARM Cortex-A7 processors. August 2018: Google switches from Speck to ChaCha12, again using hand-written assembly. Why not ChaCha20? Speed.

  40. 10 11 Real world: Keccak (SHA-3) team maintains “Keccak Code Package” with Cryptographic part of the TCB > 20 optimized implementations is huge. Many implementations of Keccak: AVX2, NEON, etc. of many cryptographic primitives. Includes “parallel Keccak”: Most complications are for speed. many further implementations. e.g. February 2018: Google adds Why not portable C code using NSA’s Speck cipher to Linux “optimizing” compiler? Slower. kernel using hand-written asm Another example: many different for ARM Cortex-A7 processors. primitives in NIST competition August 2018: Google switches for post-quantum public-key from Speck to ChaCha12, again cryptography. (See next talk.) using hand-written assembly. Some overlap in implementations, Why not ChaCha20? Speed. but still huge volume of code.

  41. 10 11 orld: Keccak (SHA-3) team maintains Often people “Keccak Code Package” with cryptographic Cryptographic part of the TCB > 20 optimized implementations e.g. NIST, huge. Many implementations of Keccak: AVX2, NEON, etc. really like many cryptographic primitives. Includes “parallel Keccak”: optimized complications are for speed. many further implementations. ⇒ More ebruary 2018: Google adds Why not portable C code using Speck cipher to Linux “optimizing” compiler? Slower. using hand-written asm Another example: many different M Cortex-A7 processors. primitives in NIST competition August 2018: Google switches for post-quantum public-key Speck to ChaCha12, again cryptography. (See next talk.) hand-written assembly. Some overlap in implementations, not ChaCha20? Speed. but still huge volume of code.

  42. 10 11 Keccak (SHA-3) team maintains Often people still complain “Keccak Code Package” with cryptographic perfo part of the TCB > 20 optimized implementations e.g. NIST, May 2018: implementations of Keccak: AVX2, NEON, etc. really like to see mo cryptographic primitives. Includes “parallel Keccak”: optimized impleme complications are for speed. many further implementations. ⇒ More and more 2018: Google adds Why not portable C code using cipher to Linux “optimizing” compiler? Slower. hand-written asm Another example: many different rtex-A7 processors. primitives in NIST competition Google switches for post-quantum public-key ChaCha12, again cryptography. (See next talk.) hand-written assembly. Some overlap in implementations, Cha20? Speed. but still huge volume of code.

  43. 10 11 Keccak (SHA-3) team maintains Often people still complain ab “Keccak Code Package” with cryptographic performance. TCB > 20 optimized implementations e.g. NIST, May 2018: “we’d implementations of Keccak: AVX2, NEON, etc. really like to see more platfo rimitives. Includes “parallel Keccak”: optimized implementations”. r speed. many further implementations. ⇒ More and more software. ogle adds Why not portable C code using Linux “optimizing” compiler? Slower. asm Another example: many different cessors. primitives in NIST competition switches for post-quantum public-key again cryptography. (See next talk.) sembly. Some overlap in implementations, eed. but still huge volume of code.

  44. 11 12 Keccak (SHA-3) team maintains Often people still complain about “Keccak Code Package” with cryptographic performance. > 20 optimized implementations e.g. NIST, May 2018: “we’d of Keccak: AVX2, NEON, etc. really like to see more platform- Includes “parallel Keccak”: optimized implementations”. many further implementations. ⇒ More and more software. Why not portable C code using “optimizing” compiler? Slower. Another example: many different primitives in NIST competition for post-quantum public-key cryptography. (See next talk.) Some overlap in implementations, but still huge volume of code.

  45. 11 12 Keccak (SHA-3) team maintains Often people still complain about “Keccak Code Package” with cryptographic performance. > 20 optimized implementations e.g. NIST, May 2018: “we’d of Keccak: AVX2, NEON, etc. really like to see more platform- Includes “parallel Keccak”: optimized implementations”. many further implementations. ⇒ More and more software. Why not portable C code using Many security failures from “optimizing” compiler? Slower. incorrect computations: e.g., CVE-2017-3732, CVE-2017-3736, Another example: many different CVE-2017-3738 in OpenSSL. primitives in NIST competition for post-quantum public-key cryptography. (See next talk.) Some overlap in implementations, but still huge volume of code.

  46. 11 12 Keccak (SHA-3) team maintains Often people still complain about “Keccak Code Package” with cryptographic performance. > 20 optimized implementations e.g. NIST, May 2018: “we’d of Keccak: AVX2, NEON, etc. really like to see more platform- Includes “parallel Keccak”: optimized implementations”. many further implementations. ⇒ More and more software. Why not portable C code using Many security failures from “optimizing” compiler? Slower. incorrect computations: e.g., CVE-2017-3732, CVE-2017-3736, Another example: many different CVE-2017-3738 in OpenSSL. primitives in NIST competition for post-quantum public-key Many security failures from cryptography. (See next talk.) variable-time computations: e.g. CVE-2018-0495, CVE-2018-0737, Some overlap in implementations, CVE-2018-5407 in OpenSSL. but still huge volume of code.

  47. 11 12 Keccak (SHA-3) team maintains Often people still complain about Timing attacks “Keccak Code Package” with cryptographic performance. Large po optimized implementations e.g. NIST, May 2018: “we’d optimizations Keccak: AVX2, NEON, etc. really like to see more platform- addresses Includes “parallel Keccak”: optimized implementations”. Consider further implementations. ⇒ More and more software. instruction not portable C code using Many security failures from parallel cache “optimizing” compiler? Slower. incorrect computations: e.g., store-to-load CVE-2017-3732, CVE-2017-3736, Another example: many different branch p CVE-2017-3738 in OpenSSL. rimitives in NIST competition ost-quantum public-key Many security failures from cryptography. (See next talk.) variable-time computations: e.g. CVE-2018-0495, CVE-2018-0737, overlap in implementations, CVE-2018-5407 in OpenSSL. still huge volume of code.

  48. 11 12 team maintains Often people still complain about Timing attacks ackage” with cryptographic performance. Large portion of CPU implementations e.g. NIST, May 2018: “we’d optimizations depending VX2, NEON, etc. really like to see more platform- addresses of memo rallel Keccak”: optimized implementations”. Consider data cachin implementations. ⇒ More and more software. instruction caching, ble C code using Many security failures from parallel cache banks, compiler? Slower. incorrect computations: e.g., store-to-load forwa CVE-2017-3732, CVE-2017-3736, example: many different branch prediction, CVE-2017-3738 in OpenSSL. NIST competition public-key Many security failures from (See next talk.) variable-time computations: e.g. CVE-2018-0495, CVE-2018-0737, implementations, CVE-2018-5407 in OpenSSL. volume of code.

  49. 11 12 maintains Often people still complain about Timing attacks with cryptographic performance. Large portion of CPU hardw implementations e.g. NIST, May 2018: “we’d optimizations depending on etc. really like to see more platform- addresses of memory locations. Keccak”: optimized implementations”. Consider data caching, implementations. ⇒ More and more software. instruction caching, using Many security failures from parallel cache banks, Slower. incorrect computations: e.g., store-to-load forwarding, CVE-2017-3732, CVE-2017-3736, different branch prediction, etc. CVE-2017-3738 in OpenSSL. etition ey Many security failures from talk.) variable-time computations: e.g. CVE-2018-0495, CVE-2018-0737, implementations, CVE-2018-5407 in OpenSSL. de.

  50. 12 13 Often people still complain about Timing attacks cryptographic performance. Large portion of CPU hardware: e.g. NIST, May 2018: “we’d optimizations depending on really like to see more platform- addresses of memory locations. optimized implementations”. Consider data caching, ⇒ More and more software. instruction caching, Many security failures from parallel cache banks, incorrect computations: e.g., store-to-load forwarding, CVE-2017-3732, CVE-2017-3736, branch prediction, etc. CVE-2017-3738 in OpenSSL. Many security failures from variable-time computations: e.g. CVE-2018-0495, CVE-2018-0737, CVE-2018-5407 in OpenSSL.

  51. 12 13 Often people still complain about Timing attacks cryptographic performance. Large portion of CPU hardware: e.g. NIST, May 2018: “we’d optimizations depending on really like to see more platform- addresses of memory locations. optimized implementations”. Consider data caching, ⇒ More and more software. instruction caching, Many security failures from parallel cache banks, incorrect computations: e.g., store-to-load forwarding, CVE-2017-3732, CVE-2017-3736, branch prediction, etc. CVE-2017-3738 in OpenSSL. Many attacks (e.g. TLBleed from Many security failures from 2018 Gras–Razavi–Bos–Giuffrida) variable-time computations: e.g. show that this portion of the CPU CVE-2018-0495, CVE-2018-0737, has trouble keeping secrets. CVE-2018-5407 in OpenSSL.

  52. 12 13 people still complain about Timing attacks Typical literature cryptographic performance. Large portion of CPU hardware: Understand NIST, May 2018: “we’d optimizations depending on But details like to see more platform- addresses of memory locations. not exposed optimized implementations”. Consider data caching, Try to push re and more software. instruction caching, This becomes security failures from parallel cache banks, Tweak the rrect computations: e.g., store-to-load forwarding, to try to CVE-2017-3732, CVE-2017-3736, branch prediction, etc. CVE-2017-3738 in OpenSSL. Many attacks (e.g. TLBleed from security failures from 2018 Gras–Razavi–Bos–Giuffrida) riable-time computations: e.g. show that this portion of the CPU CVE-2018-0495, CVE-2018-0737, has trouble keeping secrets. CVE-2018-5407 in OpenSSL.

  53. 12 13 still complain about Timing attacks Typical literature on erformance. Large portion of CPU hardware: Understand this po 2018: “we’d optimizations depending on But details are often more platform- addresses of memory locations. not exposed to securit implementations”. Consider data caching, Try to push attacks re software. instruction caching, This becomes very failures from parallel cache banks, Tweak the attacked computations: e.g., store-to-load forwarding, to try to stop the kno CVE-2017-3736, branch prediction, etc. in OpenSSL. Many attacks (e.g. TLBleed from failures from 2018 Gras–Razavi–Bos–Giuffrida) computations: e.g. show that this portion of the CPU CVE-2018-0737, has trouble keeping secrets. in OpenSSL.

  54. 12 13 complain about Timing attacks Typical literature on this topic: rmance. Large portion of CPU hardware: Understand this portion of CPU. e’d optimizations depending on But details are often proprieta platform- addresses of memory locations. not exposed to security review. tions”. Consider data caching, Try to push attacks further. re. instruction caching, This becomes very complicated. parallel cache banks, Tweak the attacked software e.g., store-to-load forwarding, to try to stop the known attacks. CVE-2017-3736, branch prediction, etc. enSSL. Many attacks (e.g. TLBleed from 2018 Gras–Razavi–Bos–Giuffrida) computations: e.g. show that this portion of the CPU CVE-2018-0737, has trouble keeping secrets. enSSL.

  55. 13 14 Timing attacks Typical literature on this topic: Large portion of CPU hardware: Understand this portion of CPU. optimizations depending on But details are often proprietary, addresses of memory locations. not exposed to security review. Consider data caching, Try to push attacks further. instruction caching, This becomes very complicated. parallel cache banks, Tweak the attacked software store-to-load forwarding, to try to stop the known attacks. branch prediction, etc. Many attacks (e.g. TLBleed from 2018 Gras–Razavi–Bos–Giuffrida) show that this portion of the CPU has trouble keeping secrets.

  56. 13 14 Timing attacks Typical literature on this topic: Large portion of CPU hardware: Understand this portion of CPU. optimizations depending on But details are often proprietary, addresses of memory locations. not exposed to security review. Consider data caching, Try to push attacks further. instruction caching, This becomes very complicated. parallel cache banks, Tweak the attacked software store-to-load forwarding, to try to stop the known attacks. branch prediction, etc. For researchers: This is great! Many attacks (e.g. TLBleed from 2018 Gras–Razavi–Bos–Giuffrida) show that this portion of the CPU has trouble keeping secrets.

  57. 13 14 Timing attacks Typical literature on this topic: Large portion of CPU hardware: Understand this portion of CPU. optimizations depending on But details are often proprietary, addresses of memory locations. not exposed to security review. Consider data caching, Try to push attacks further. instruction caching, This becomes very complicated. parallel cache banks, Tweak the attacked software store-to-load forwarding, to try to stop the known attacks. branch prediction, etc. For researchers: This is great! Many attacks (e.g. TLBleed from For auditors: This is a nightmare. 2018 Gras–Razavi–Bos–Giuffrida) Many years of security failures. show that this portion of the CPU No confidence in future security. has trouble keeping secrets.

  58. 13 14 Timing attacks Typical literature on this topic: The “constant-time” Don’t give portion of CPU hardware: Understand this portion of CPU. to this p optimizations depending on But details are often proprietary, (1987 Goldreich, addresses of memory locations. not exposed to security review. Oblivious Consider data caching, Try to push attacks further. domain-sp instruction caching, This becomes very complicated. rallel cache banks, Tweak the attacked software re-to-load forwarding, to try to stop the known attacks. prediction, etc. For researchers: This is great! attacks (e.g. TLBleed from For auditors: This is a nightmare. Gras–Razavi–Bos–Giuffrida) Many years of security failures. that this portion of the CPU No confidence in future security. trouble keeping secrets.

  59. 13 14 Typical literature on this topic: The “constant-time” Don’t give any secrets CPU hardware: Understand this portion of CPU. to this portion of the depending on But details are often proprietary, (1987 Goldreich, 1990 memory locations. not exposed to security review. Oblivious RAM; 2004 caching, Try to push attacks further. domain-specific for caching, This becomes very complicated. banks, Tweak the attacked software rwarding, to try to stop the known attacks. rediction, etc. For researchers: This is great! (e.g. TLBleed from For auditors: This is a nightmare. Gras–Razavi–Bos–Giuffrida) Many years of security failures. ortion of the CPU No confidence in future security. eeping secrets.

  60. 13 14 Typical literature on this topic: The “constant-time” solution: Don’t give any secrets rdware: Understand this portion of CPU. to this portion of the CPU. on But details are often proprietary, (1987 Goldreich, 1990 Ostrovsky: cations. not exposed to security review. Oblivious RAM; 2004 Bernstein: Try to push attacks further. domain-specific for better sp This becomes very complicated. Tweak the attacked software to try to stop the known attacks. For researchers: This is great! TLBleed from For auditors: This is a nightmare. Gras–Razavi–Bos–Giuffrida) Many years of security failures. the CPU No confidence in future security. secrets.

  61. 14 15 Typical literature on this topic: The “constant-time” solution: Don’t give any secrets Understand this portion of CPU. to this portion of the CPU. But details are often proprietary, (1987 Goldreich, 1990 Ostrovsky: not exposed to security review. Oblivious RAM; 2004 Bernstein: Try to push attacks further. domain-specific for better speed) This becomes very complicated. Tweak the attacked software to try to stop the known attacks. For researchers: This is great! For auditors: This is a nightmare. Many years of security failures. No confidence in future security.

  62. 14 15 Typical literature on this topic: The “constant-time” solution: Don’t give any secrets Understand this portion of CPU. to this portion of the CPU. But details are often proprietary, (1987 Goldreich, 1990 Ostrovsky: not exposed to security review. Oblivious RAM; 2004 Bernstein: Try to push attacks further. domain-specific for better speed) This becomes very complicated. TCB analysis: Need this portion Tweak the attacked software of the CPU to be correct, but to try to stop the known attacks. don’t need it to keep secrets. Makes auditing much easier. For researchers: This is great! For auditors: This is a nightmare. Many years of security failures. No confidence in future security.

  63. 14 15 Typical literature on this topic: The “constant-time” solution: Don’t give any secrets Understand this portion of CPU. to this portion of the CPU. But details are often proprietary, (1987 Goldreich, 1990 Ostrovsky: not exposed to security review. Oblivious RAM; 2004 Bernstein: Try to push attacks further. domain-specific for better speed) This becomes very complicated. TCB analysis: Need this portion Tweak the attacked software of the CPU to be correct, but to try to stop the known attacks. don’t need it to keep secrets. Makes auditing much easier. For researchers: This is great! Good match for attitude and For auditors: This is a nightmare. experience of CPU designers: e.g., Many years of security failures. Intel issues errata for correctness No confidence in future security. bugs, not for information leaks.

  64. 14 15 ypical literature on this topic: The “constant-time” solution: Case study: Don’t give any secrets Understand this portion of CPU. Subroutine to this portion of the CPU. details are often proprietary, Classic McEliec (1987 Goldreich, 1990 Ostrovsky: exposed to security review. Gravity-SPHINCS, Oblivious RAM; 2004 Bernstein: LEDApkc, push attacks further. domain-specific for better speed) sort array ecomes very complicated. TCB analysis: Need this portion e.g. sort the attacked software of the CPU to be correct, but Typical so to stop the known attacks. don’t need it to keep secrets. merge so Makes auditing much easier. researchers: This is great! choose load/sto Good match for attitude and based on auditors: This is a nightmare. experience of CPU designers: e.g., also branch years of security failures. Intel issues errata for correctness confidence in future security. How to so bugs, not for information leaks. without

  65. 14 15 literature on this topic: The “constant-time” solution: Case study: Constant-time Don’t give any secrets portion of CPU. Subroutine in (e.g.) to this portion of the CPU. often proprietary, Classic McEliece, GeMSS, (1987 Goldreich, 1990 Ostrovsky: security review. Gravity-SPHINCS, Oblivious RAM; 2004 Bernstein: LEDApkc, NTRU Prime, ttacks further. domain-specific for better speed) sort array of secret very complicated. TCB analysis: Need this portion e.g. sort 768 32-bit attacked software of the CPU to be correct, but Typical sorting algo the known attacks. don’t need it to keep secrets. merge sort, quickso Makes auditing much easier. This is great! choose load/store Good match for attitude and based on secret data. This is a nightmare. experience of CPU designers: e.g., also branch based security failures. Intel issues errata for correctness future security. How to sort secret bugs, not for information leaks. without any secret

  66. 14 15 topic: The “constant-time” solution: Case study: Constant-time so Don’t give any secrets of CPU. Subroutine in (e.g.) BIG QUAKE, to this portion of the CPU. rietary, Classic McEliece, GeMSS, (1987 Goldreich, 1990 Ostrovsky: review. Gravity-SPHINCS, LEDAkem, Oblivious RAM; 2004 Bernstein: LEDApkc, NTRU Prime, Round2: further. domain-specific for better speed) sort array of secret integers. complicated. TCB analysis: Need this portion e.g. sort 768 32-bit integers. are of the CPU to be correct, but Typical sorting algorithms— attacks. don’t need it to keep secrets. merge sort, quicksort, etc.— Makes auditing much easier. great! choose load/store addresses Good match for attitude and based on secret data. Usually nightmare. experience of CPU designers: e.g., also branch based on secret failures. Intel issues errata for correctness security. How to sort secret data bugs, not for information leaks. without any secret addresses?

  67. 15 16 The “constant-time” solution: Case study: Constant-time sorting Don’t give any secrets Subroutine in (e.g.) BIG QUAKE, to this portion of the CPU. Classic McEliece, GeMSS, (1987 Goldreich, 1990 Ostrovsky: Gravity-SPHINCS, LEDAkem, Oblivious RAM; 2004 Bernstein: LEDApkc, NTRU Prime, Round2: domain-specific for better speed) sort array of secret integers. TCB analysis: Need this portion e.g. sort 768 32-bit integers. of the CPU to be correct, but Typical sorting algorithms— don’t need it to keep secrets. merge sort, quicksort, etc.— Makes auditing much easier. choose load/store addresses Good match for attitude and based on secret data. Usually experience of CPU designers: e.g., also branch based on secret data. Intel issues errata for correctness How to sort secret data bugs, not for information leaks. without any secret addresses?

  68. 15 16 “constant-time” solution: Case study: Constant-time sorting Foundation give any secrets a compa Subroutine in (e.g.) BIG QUAKE, portion of the CPU. Classic McEliece, GeMSS, x Goldreich, 1990 Ostrovsky: Gravity-SPHINCS, LEDAkem, Oblivious RAM; 2004 Bernstein: LEDApkc, NTRU Prime, Round2: • domain-specific for better speed) sort array of secret integers. analysis: Need this portion e.g. sort 768 32-bit integers. min { x; y CPU to be correct, but Typical sorting algorithms— need it to keep secrets. merge sort, quicksort, etc.— Easy constant-time auditing much easier. choose load/store addresses Warning: match for attitude and based on secret data. Usually compiler erience of CPU designers: e.g., also branch based on secret data. Even easier issues errata for correctness How to sort secret data not for information leaks. without any secret addresses?

  69. 15 16 “constant-time” solution: Case study: Constant-time sorting Foundation of solution: secrets a comparator sorting Subroutine in (e.g.) BIG QUAKE, of the CPU. Classic McEliece, GeMSS, x Goldreich, 1990 Ostrovsky: Gravity-SPHINCS, LEDAkem, 2004 Bernstein: LEDApkc, NTRU Prime, Round2: • for better speed) sort array of secret integers. Need this portion e.g. sort 768 32-bit integers. min { x; y } max e correct, but Typical sorting algorithms— keep secrets. merge sort, quicksort, etc.— Easy constant-time much easier. choose load/store addresses Warning: C standa attitude and based on secret data. Usually compiler to break the U designers: e.g., also branch based on secret data. Even easier exercise errata for correctness How to sort secret data information leaks. without any secret addresses?

  70. 15 16 solution: Case study: Constant-time sorting Foundation of solution: a comparator sorting 2 integers. Subroutine in (e.g.) BIG QUAKE, CPU. Classic McEliece, GeMSS, x y Ostrovsky: Gravity-SPHINCS, LEDAkem, Bernstein: LEDApkc, NTRU Prime, Round2: • • speed) sort array of secret integers. ortion e.g. sort 768 32-bit integers. min { x; y } max { x; y } but Typical sorting algorithms— secrets. merge sort, quicksort, etc.— Easy constant-time exercise easier. choose load/store addresses Warning: C standard allows and based on secret data. Usually compiler to break the solution. designers: e.g., also branch based on secret data. Even easier exercise in asm. rrectness How to sort secret data leaks. without any secret addresses?

  71. 16 17 Case study: Constant-time sorting Foundation of solution: a comparator sorting 2 integers. Subroutine in (e.g.) BIG QUAKE, Classic McEliece, GeMSS, x y Gravity-SPHINCS, LEDAkem, LEDApkc, NTRU Prime, Round2: • • sort array of secret integers. e.g. sort 768 32-bit integers. min { x; y } max { x; y } Typical sorting algorithms— merge sort, quicksort, etc.— Easy constant-time exercise in C. choose load/store addresses Warning: C standard allows based on secret data. Usually compiler to break the solution. also branch based on secret data. Even easier exercise in asm. How to sort secret data without any secret addresses?

  72. 16 17 study: Constant-time sorting Foundation of solution: Combine a comparator sorting 2 integers. sorting net routine in (e.g.) BIG QUAKE, McEliece, GeMSS, Example x y y-SPHINCS, LEDAkem, Apkc, NTRU Prime, Round2: • • rray of secret integers. • rt 768 32-bit integers. min { x; y } max { x; y } ypical sorting algorithms— sort, quicksort, etc.— Easy constant-time exercise in C. • load/store addresses Warning: C standard allows on secret data. Usually compiler to break the solution. anch based on secret data. Even easier exercise in asm. • to sort secret data without any secret addresses?

  73. 16 17 Constant-time sorting Foundation of solution: Combine comparato a comparator sorting 2 integers. sorting network fo (e.g.) BIG QUAKE, e, GeMSS, Example of a sorting x y y-SPHINCS, LEDAkem, Prime, Round2: • • cret integers. • • 32-bit integers. min { x; y } max { x; y } • algorithms— quicksort, etc.— Easy constant-time exercise in C. • • re addresses Warning: C standard allows • data. Usually compiler to break the solution. based on secret data. Even easier exercise in asm. • • ecret data secret addresses?

  74. 16 17 Constant-time sorting Foundation of solution: Combine comparators into a a comparator sorting 2 integers. sorting network for more inputs. QUAKE, Example of a sorting network: x y em, Round2: • • integers. • • gers. min { x; y } max { x; y } • • rithms— tc.— Easy constant-time exercise in C. • • • • addresses Warning: C standard allows • • Usually compiler to break the solution. secret data. Even easier exercise in asm. • • addresses?

  75. 17 18 Foundation of solution: Combine comparators into a a comparator sorting 2 integers. sorting network for more inputs. Example of a sorting network: x y • • • • min { x; y } max { x; y } • • Easy constant-time exercise in C. • • • • Warning: C standard allows • • compiler to break the solution. Even easier exercise in asm. • •

  76. 17 18 oundation of solution: Combine comparators into a Positions comparator sorting 2 integers. sorting network for more inputs. in a sorting independent Example of a sorting network: y Naturally • • • ; y } max { x; y } • • constant-time exercise in C. • • • • rning: C standard allows • • compiler to break the solution. easier exercise in asm. • •

  77. 17 18 solution: Combine comparators into a Positions of compa sorting 2 integers. sorting network for more inputs. in a sorting network independent of the Example of a sorting network: y Naturally constant-time. • • • max { x; y } • • constant-time exercise in C. • • • • standard allows • • reak the solution. exercise in asm. • •

  78. 17 18 Combine comparators into a Positions of comparators integers. sorting network for more inputs. in a sorting network are independent of the input. Example of a sorting network: Naturally constant-time. • • } • • exercise in C. • • • • ws • • tion. . • •

  79. 18 19 Combine comparators into a Positions of comparators sorting network for more inputs. in a sorting network are independent of the input. Example of a sorting network: Naturally constant-time. • • • • • • • • • • • •

  80. 18 19 Combine comparators into a Positions of comparators sorting network for more inputs. in a sorting network are independent of the input. Example of a sorting network: Naturally constant-time. But remember all the people complaining about speed: e.g., • • “We would be happy to hear that • • fixed weight sampling is efficient on a variety of platforms : : : • • • • We have not yet been convinced that this is the case.” • • • •

  81. 18 19 Combine comparators into a Positions of comparators sorting network for more inputs. in a sorting network are independent of the input. Example of a sorting network: Naturally constant-time. But remember all the people complaining about speed: e.g., • • “We would be happy to hear that • • fixed weight sampling is efficient on a variety of platforms : : : • • • • We have not yet been convinced that this is the case.” • • ( n 2 − n ) = 2 comparators in bubble • • sort produce complaints about performance as n increases.

  82. 18 19 Combine comparators into a Positions of comparators void int32_sort(int32 rting network for more inputs. in a sorting network are { int64 independent of the input. if (n Example of a sorting network: Naturally constant-time. t = 1; while But remember all the people for (p complaining about speed: e.g., • • for “We would be happy to hear that if • • fixed weight sampling is efficient on a variety of platforms : : : • • • • for We have not yet been convinced for that this is the case.” • • ( n 2 − n ) = 2 comparators in bubble • • sort produce complaints about } performance as n increases. }

  83. 18 19 rators into a Positions of comparators void int32_sort(int32 for more inputs. in a sorting network are { int64 t,p,q,i; independent of the input. if (n < 2) return; rting network: Naturally constant-time. t = 1; while (t < n - But remember all the people for (p = t;p > complaining about speed: e.g., for (i = 0;i “We would be happy to hear that if (!(i & p)) • fixed weight sampling is efficient minmax(x+i,x+i+p); on a variety of platforms : : : • • for (q = t;q We have not yet been convinced for (i = 0;i that this is the case.” • if (!(i & ( n 2 − n ) = 2 comparators in bubble minmax(x+i+p,x+i+q); sort produce complaints about } performance as n increases. }

  84. 18 19 a Positions of comparators void int32_sort(int32 *x,int64 inputs. in a sorting network are { int64 t,p,q,i; independent of the input. if (n < 2) return; ork: Naturally constant-time. t = 1; while (t < n - t) t += But remember all the people for (p = t;p > 0;p >>= complaining about speed: e.g., for (i = 0;i < n - p;++i) “We would be happy to hear that if (!(i & p)) fixed weight sampling is efficient minmax(x+i,x+i+p); on a variety of platforms : : : • for (q = t;q > p;q >>= We have not yet been convinced for (i = 0;i < n - that this is the case.” if (!(i & p)) ( n 2 − n ) = 2 comparators in bubble minmax(x+i+p,x+i+q); sort produce complaints about } performance as n increases. }

  85. 19 20 Positions of comparators void int32_sort(int32 *x,int64 n) in a sorting network are { int64 t,p,q,i; independent of the input. if (n < 2) return; Naturally constant-time. t = 1; while (t < n - t) t += t; But remember all the people for (p = t;p > 0;p >>= 1) { complaining about speed: e.g., for (i = 0;i < n - p;++i) “We would be happy to hear that if (!(i & p)) fixed weight sampling is efficient minmax(x+i,x+i+p); on a variety of platforms : : : for (q = t;q > p;q >>= 1) We have not yet been convinced for (i = 0;i < n - q;++i) that this is the case.” if (!(i & p)) ( n 2 − n ) = 2 comparators in bubble minmax(x+i+p,x+i+q); sort produce complaints about } performance as n increases. }

Recommend


More recommend