Architecture Support for Security Peter Chapman Michael Maass

Overview ● The Pervasiveness of Computing Vulnerabilities ● Hardware vs. Software Mitigations ● Hardware Challenges ● Examples: – Timing Side Channels – Code Re-use Attacks

Overview ● The Pervasiveness of Computing Vulnerabilities ● Hardware vs. Software Mitigations ● Hardware Challenges ● Examples: – Timing Side Channels – Code Re-use Attacks Ask Questions!

The Pervasiveness of Computing Vulnerabilities ● Computing stacks are vulnerable at all layers ● Software vulnerabilities are introduced at all phases: – Design/implementation vulnerabilities ● We'd like to catch vulnerabilities early, but we don't always succeed – Makes the problem much harder and more expensive

The Pervasiveness of Computing Vulnerabilities Hardware is vulnerable for the same reasons as software – Hardware is harder to fix because you can't usually just patch it – Sometimes the vulnerability is due to physical properties that are difficult to predict or model

The Pervasiveness of Computing Vulnerabilities Hardware is vulnerable for the same reasons as software – Hardware is harder to fix because you can't usually just patch it – Sometimes the vulnerability is due to physical properties that are difficult to predict or model

The Pervasiveness of Computing Vulnerabilities

Overcoming an Untrusted Computing Base: Detecting and Removing Malicious Hardware Automatically Is the server with the HDL secure?

Hardware vs. Software Mitigations Software is easier to deploy, but: – Some vulnerabilities can't easily be fixed in software due to performance issues or a lack of context – Sometimes it's too expensive to fix in software because a general solution doesn't exist ● Every system needs a custom solution – Sometimes the solution works against the hardware ● Tracking taint in at runtime consumes resources (e.g., cache, registers, etc.)

Hardware Challenges ● Needs very low overhead in terms of performance and space ● Needs to be simple enough to reason about correctness while still fixing the problem ● Needs a very good reason to do it ● If software support is necessary, adoption becomes more expensive ● Backwards compatibility is harder ● Must avoid political landmines that harm adoption – TPM cooped by DRM

Timing Side Channels ● Computations take varying lengths of time based on the input and use different resources – This information leaks ● Timing information can be correlated to statistically determine private information such as key presses, cryptographic keys, visited web sites, etc.

Timing Side Channels ● We can deny access to timing information, thus plugging the leak, but: – Some applications depend on accurate timing information (e.g., games, multimedia, etc.) – Denying access still requires potentially significant hardware/software changes ● Bleach the timing data so that it's still monotonic, but no longer allows for correlation

Code Reuse Attacks Code injection attacks are typically mitigated by preventing existing code from being changed or by preventing data from being executed as code Attackers now make clever use of existing code

Code Reuse Attacks In hardware: – Prevent jumps outside of the current function unless it's to the start of a new function – Prevent calls to anything but the start of functions – Prevent return values from being changed Need: – Hardware in the pipeline to perform checks on redirections – Software support is needed to securely mark the start of functions – A secure stack is required to prevent return values from being changed

References ● M. Kayaalp, M. Ozsoy, N. Abu-Ghazaleh, and D. Ponomarev, “Branch regulation: low- overhead protection from code reuse attacks,” in Proceedings of the 39th International Symposium on Computer Architecture, Piscataway, NJ, USA, 2012, pp. 94–105. ● J. Valamehr, M. Chase, S. Kamara, A. Putnam, D. Shumow, V. Vaikuntanathan, and T. Sherwood, “Inspection resistant memory: architectural support for security from physical examination,” SIGARCH Comput. Archit. News, vol. 40, no. 3, pp. 130–141, Jun ● J. Demme, R. Martin, A. Waksman, and S. Sethumadhavan, “Side-channel vulnerability factor: a metric for measuring information leakage,” SIGARCH Comput. Archit. News, vol. 40, no. 3, pp. 106–117, Jun ● R. Martin, J. Demme, and S. Sethumadhavan, “TimeWarp: rethinking timekeeping and performance monitoring mechanisms to mitigate side-channel attacks,” SIGARCH Comput. Archit. News, vol. 40, no. 3, pp. 118–129, Jun ● S. Jana and V. Shmatikov, “Memento: Learning Secrets from Process Footprints,” in Security and Privacy (SP), 2012 IEEE Symposium on, 2012, pp. 143 –157.