Side Channels

1. Side Channels Tiffany Youzhi Bao William Wysocki Varun Jain

2. A short story • In 1991 a man named Frank Meeks claimed to be able to predict major political events 1 day in advance. • He did not have any special connections with the Federal Government. • He also did not claim any special training or knowledge which allowed him knowledge of world events.

3. A short story • Frank Meeks owneda number of Dominos pizza franchises in the DC area • He claimed that there would be a spike in pizza orders to the White House and other important government buildings on the night before major world events

4. Side Channels • A side channel is an attack against the implementation of a system rather than the information in transit • Common side channels include: electromagnetic emanations, energy consumption, message length, computation time, pizza consumption and more…

5. TEMPEST • Code name for an NSA operation to secure electronic communications equipment from eavesdropping and intercept information from other sources. • Consists of electrical, mechanical, or acoustic energy released by a equipment or systems used to process national security information.

6. TEMPEST Vintage 1943 Bell Telephone model 131-B2 A teletype terminal used during WWII to transmit encrypted communications

7. TEMPEST • A Bell engineer noticed that an unattached nearby oscilloscope would be excited by key presses • The electromagnetic energy emitted could be used to infer the plain text key pressed • Bell brought their concerns to the Signal Corps • In a demonstration of the attack, Bell engineers stationed across the street from the Signal Corps downtown Manhattan Cryptocenter, engineers were able to recover 75% of the plaintext transmitted • In 1951 the CIA re-discovered this phenomena and in collaboration with the NSA began the TEMPEST effort

8. TEMPEST • All machines which process information emit electromagnetic and acoustic energy • An attacker can listen to these signals and recover the information being processed • This can be further expanded with Van Eck phreaking, demonstrated in 1985, a method of replicating the current display of a CRT or LCD screen by its electromagnetic emissions

9. TEMPEST • How can this sensitive information be protected? • Decrease the level of EM Radiation • Very difficult due to requirements of a screen, ie ports for power, mesh shields for the screen, shields that allow ventilation etc. • Increasing the noise level • Not feasible due to FCC regulations about device interference • Create a screen that updates its display with an abnormal ordering • Most screens refresh from top to bottom, this similarity allows the easy theft of screen info • A sophisticated attacker can determine the refresh ordering and steal display information

10. Web Applications • Software as a Service is exploding, many applications which were once housed on the desktop or the phone are now easily accessible over the web File Management Banking Email Investment Management Word processing Tax preparation Health Insurance

11. Side-channel Attack on Web Applications Web Server Measurement => Secrets Protocol ssh, ssl, https Cryptography RSA, AES

12. Web Applications • Chen et al. explain that web applications are fundamentally the same as desktop applications • I/O • Program State • Except! • The I/O and Program state must pass through the shared medium of the internet, they refer to this as “web flow”

13. Web Apps – Input Entropy • State transitions are generally triggered by a small amount of input data, making input entropy low • Thus an attacker may enumerate all possible values and observe the web flow • User data from the backend may also have enumerable possibilities • Ex: Grades screen on CMU SIO

14. Web Apps – Stateful Communication • Statefulness of the web application itself implies that the communication between client and server must also have some state • In certain applications such as tax preparation this state can give a powerful advantage to the attacker

15. Web Apps – Traffic Distinctions • Makes the use of web flow as a side channel attack viable • Highly disparate sizes for incoming web flows mean an attacker who has collected information on the flows for a site can distinguish between various user states • HTTPS, WAP, and WAP2 are not sufficient to hide the large diversity found on the internet • Block ciphers can help, but the authors found them to be rarely used

16. Web Apps – A Health App • Adding Health records falls prey to the Google style auto-suggestion attack • There is a finite enumerable list of “Conditions” • The authors found that auto-suggest catastrophically leaks typed user input • All values other than “h” and “m” produced distinct input • Further “h” and “m” will be disambiguated as long as the second character is not “a” • Input by mouse essentially changes input to a stateful navigation through a tree.

17. Web Apps – A Tax App • Tax Calculation functions as a finite state machine • User starts by entering personal info which defines the flow through the state machine • Information generally considered very private drastically changes a users flow through the machine • Filing status, Income Bracket, Deductions • The authors only studied Federal Taxes so further refinements should be available by studying various state workflows as well • The primary weakness is various deductions can leak a lot of personal information about a users previous year

18. Web Apps – An Investment App • The authors were able todetermine the mutualfunds a user invested inby the daily change in thesize of the pie graphtransmitted to the user • Attack is possible because investment information about the mutual funds is public information. Further by using the same gif encoder as the website, all possible graphs can be pre-calculated

19. Web Apps – Defenses • A one size fits all approach using padding, false packets, fixed packet sizes and masking the application state will not end up working for all applications • Applications with simple patterns like SSH or VOIP will be similarly fairly easy to protect • Applications with complicated patterns will require tailored approaches that match their particular idiosyncrasies • The Web applications reviewed fall under this category

20. Web Apps - Defenses • How did the authors recommend mitigation of OnlineHealth’s leaks? • Padding – 2 types • Rounding: Round up every nearest X bytes • Random: Append a random 0-X length • At X = 256, it was still possible to distinguish some information • At X = 512 it was no longer possible to distinguish information, at a cost of 32.3% overhead

21. Web Apps - Defenses • How did the authors recommend mitigation of OnlineTax’s Leaks? • Padding is not effective because the flows are too asymmetric. • Application would need to be re-architected to merge states into longer execution paths or produce extra fake states

22. Web Apps - Defenses • How did the authors recommend mitigation of OnlineInvest’s Leaks? • Rounded padding more effective than random padding due to leaks over time of investor continually revisiting the site • Further issue that OnlineInvest’s price history charts originate from a 3rd party, and thus they must convince that 3rd party to implement padding as well.

23. Timing attacks on SSL

24. Intro to SSL • Know exactly whom you are talking to • Prevent impersonation and eavesdropping • Q: Encryption method used in SSL?

25. RSA for SSL handshake • C S: client_hello • S C: server_hello • S C: Server certificate, containing RSA public key • S C: server_key_exchange • S C: server_hello_done • C S: client_key_exchange • C S: change_cipher_spec • C  S: finished • S C: change_cipher_spec • S C: finished

26. RSA review • c: ciphertext, m: plaintext, decryption: • Attacker knows • Aim at • As long as attacker knows or • OpenSSL : Problematic implementation of RSA

27. OpenSSL implementation in modular multiplication • Modular multiplication • common method is expensive • Montgomery, 1985: Montgomery format & Montgomery Reduction, efficient in hardware and software • Combine by Chinese Remainder Theorem

28. Montgomery Reduction • Time Difference: Montgomery Reduction • Multiplicationc = ab: • Transform ‘a’ & ‘b’ to Montgomery format first

29. Montgomery reduction Decryption of g<q should be slower than decrpytion of g>q

30. Multiplication Routines • Multi-precision integer multiplication • Karatsuba(m=n) vs normal • Suppose • number of words Decryption of g>q should be slower than decrpytion of g<q

31. RSA for SSL handshake • C S: client_hello • S C: server_hello • S C: Server certificate, containing RSA public key • S C: server_key_exchange • S C: server_hello_done • C S: client_key_exchange • C S: change_cipher_spec • C  S: finished • S C: change_cipher_spec • S C: finished

32. RSA for SSL handshake • C S: client_hello • S C: server_hello • S C: Server certificate, containing RSA public key • S C: server_key_exchange • S C: server_hello_done • C S: client_key_exchange • Server checks if plaintext is properly formatted • Next phase, or S  C: ALERT • C  S: change_cipher_spec • C  S: finished • S  C: change_cipher_spec • S  C: finished

33. Trick What if timing gap is too small to be detected?

35. Defense • Increase Standard Deviation -> blinding • RSA blinding: Server blinds decryption time r: random number e: encryption exponent • Calculates x, then decrypts x by • Decrease the difference of feature -> quantized • Take maximum time of decryption

36. Side-channelattacks on history stealing

37. History Stealing • Web browsers remember what pages a user has visited recently. • CSS  lets Web pages determine whether a URL is in the user's history very quickly and without any interaction from the user.  :link { /* for unvisited links */ color: blue; } :visited {/*for visited links */ color: purple; }

38. Script to exploit the leak var links = document.links; for (vari = 0; i < links.length; ++i) { var link = links[i]; /* exact strings to match actually need to be auto-detected using reference elements */ if (getComputedStyle(link, "").color == "rgb(0, 0, 128)") { // we know link.href has not been visited } else { // we know link.href has been visited } }

39. How can we stop this attack ?

40. Solution • Disable the coloring of visited links. Eg. Set layout.css.visited_links_enabled preference in about:config to 0. • Make getComputedStyle (and similar functions such as querySelector) lie by acting as though all links are unvisited.

41. Q • Is any other attack possible if we assume getComputedStyle() lies about the style property of visited links ?

42. Side Channel Timing Attack • An attacker can make the page take longer to lay out if a link is visited than if it is unvisited, or vice versa • Modern computers’ clocks provide enough precision that even apparently trivial details of rendering, such as whether an area of color is partially transparent, or whether a line of text is underlined, can produce measurable differences in the time to draw the page.

43. CSS selector Timing Attack • Consider selector visited: {color:green} VS link:{color:orange} • Now consider selector #nav + a • All current browsers process CSS selectors from right to left , Where we see a #nav with an a in it, browsers see an a in a #nav. This subtle difference has a huge impact on selector performance, and is a very valuable thing to learn.

44. DEMO

45. Proposed Solution • Disable the coloring of visited links. Eg. Set layout.css.visited_links_enabled preference in about:config to 0. • In 2010, L. David Baron suggested a solution • It makes getComputedStyle (and similar functions such as querySelector) lie by acting as though all links are unvisited. • It limits the CSS properties that can be used to style visited links  color, background-color, border-*-color, outline-color • It makes certain CSS selectors act as though links are always unvisited, even when they are visited such as :visited + span

46. What’s missing in the solution ? • Baron’s defense makes no effort to defend against interactive attacks—that is, attacks which trick users into revealing what they see on the screen.

47. Webcam Side Channel Attack • If the color of an area of the screen depends on whether or not a link has been visited, an attacker could use the camera to detect that color. • This attack will work better if the colored area is large and the difference between the visited and unvisited colors is dramatic,

48. obstacles to this attack • First, the Flash runtime will not activate the camera without the user’s permission, and it includes defenses against “clickjacking” attacks that trick the user into granting permission. • Second, to probe many links, it is necessary to change the color of the link frequently—that is, to make some part of the screen flash, which annoys users even in tiny doses, as the <blink> tag demonstrates.

49. Page cache timing Attack • Browsers cache resources retrieved from the Web to improve the speed of subsequent page loads. • Approximately 60% of HTTP queries are requests for cacheable resources. • The cache is global, so by embedding a resource from another site and measuring the time it takes to load, a web page can determine whether that resource is already in the browser’s cache, and thus determine whether the user has visited the other site

50. How it Works ? • Suppose that Alice is surfing the Web, and she visits Bob’s Web site at http://www.bob.com.) Bob wants to find out whether Alice has visited Charlie’s Web site (http://www.charlie.com) • Bob writes a Java applet that implements his attack, and embeds it in his home page. When Alice views the attack page, the Java applet is automatically downloaded and run in Alice’s browser.