Architecture Support for Security

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


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


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



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. 2012.

● 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. 2012.

● 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. 2012.

● S. Jana and V. Shmatikov, “Memento: Learning Secrets from Process Footprints,” in Security and Privacy (SP), 2012 IEEE Symposium on, 2012, pp. 143 –157.

Documents

Architecture Support for Security