Beyond Spectre: Confronting New Technical and Policy Challenges Proceedings of a Workshop (2019) / Chapter Skim
Currently Skimming:
2 Hardware and Software Engineering Assumptions at Risk
2 Hardware and Software Engineering Assumptions at Risk
Pages 13-27
The Chapter Skim interface presents what we've algorithmically identified as the most significant single chunk of text within every page in the chapter.
Select key terms on the right to highlight them within pages of the chapter.
From page 13... ...
Over the decades, Manferdelli argued, bad actors have gotten closer and closer to reaching the hardware. Cache and timing attacks have affected cryptographic keys: despite placing a high priority on securing the hardware and keys, designers succumbed to "the tyranny of performance and capability." Companies were loath to Beyond Spectre 13
|
From page 14... ...
ERNIE BRICKELL Independent Security Researcher Ernie Brickell shared several ideas that he believes can improve the security environment. While at Intel, Brickell ran a security architecture review team that reviewed the architecture for all proposals for improving security of Intel platforms and for any new features that might impact security.
|
From page 15... ...
Some critical systems are never patched at all because administrators prioritize availability over security, and they do not want to risk having the system fail due to applying a patch. Brickell reminded participants that OpenSSL, an open source cryptography library, for example, had flaws that remained undiscovered and unpatched for years.
|
From page 16... ...
• Permanent fix may affect performance Patchable Hardware • Patch may affect performance Unpatchable Hardware • Permanent fix may affect performance FIGURE 2.1 Privilege escalation of attacks. SOURCE: Ernie Brickell, Independent Security Researcher, "Privilege Escalation of Attacks," presentation to the workshop.
|
From page 17... ...
Many hardware vendors are already performance or designing hardware to partition applications increased security, through trusted execution environments (TEEs) , which provide a place to execute depending on the applications protected from eavesdropping application.
|
From page 18... ...
Nightingale, 2017, "The Seven Properties of High ly Secure Devices," Microsoft Research NExT Operating Systems Technologies Group, MSR-TR-2017-16, March, https://www.microsoft.com/en-us/research/research-area/ security-privacy-cryptography/publications/. 18 Forum on Cyber Resilience
|
From page 19... ...
Hunt described how Microsoft is trying to bring the best available knowledge about security and connectivity to the world of IoT. Azure Sphere's MCUs are connected, secure, crossover devices that enable other manufacturers to build highly secured IoT devices.
|
From page 20... ...
Now, Myers claimed, it is clear that these kinds of specifications are not good enough. The key flaw is that specifications to date have not accounted for the time delay involved in performing computer instructions, and these time delays can be exploited to create dangerous timing channels.
|
From page 21... ...
Myers argued that safer contracts must address time. Protecting the timing channel will require designing contracts to constrain information flow between computing layers -- in particular, its flow into time.
|
From page 22... ...
Adding information flow policies to the code that defines the hardware implementation We need a more makes it possible to verify that information expressive way is kept secret, including preventing timing channels. If there are timing leaks in the of defining code for the hardware implementation, then contracts between the compiler for the hardware description language will reject that code.
|
From page 23... ...
Myers agreed that several such techniques were used as inspiration, but a key difference is the statically verified information flow, an approach that is less prone to difficulties than a dynamically verified flow, which was more prevalent in the 1980s. Butler Lampson, Microsoft, asked if the hardware description language security would not carry over to higher levels of the stack, and Myers replied that the contracts between layers could extend the improved information flow policies to the higher levels.
|
From page 24... ...
For example, he said, there is a need to develop more expressive ways to state information flow policies, although he believes this is possible. Hunt and Brickell expressed doubt that formal verification on such a system would be possible, but Hunt noted that software fuzzing techniques could be applied.
|
From page 25... ...
Hunt explained that Azure Sphere intends to add that feature so that users would have more control, but noted that this approach does not address home routers, which represent another challenge for IoT insecurity. In response to a question from Ed Frank about Azure Sphere's level of confidence in the security coverage of its MCUs, Hunt noted that the MCUs, like anything, are not 100 percent guaranteed, and the company continues to consider potential areas of concern.
|
From page 26... ...
Kocher wondered if it would be possible for vendors to disclose relevant information about the elements of their system in order to create transparency, and hopefully trust, in device security. No matter what we do, Brickell said, a future without any security problems is highly unlikely, so we must plan to respond adequately to problems as they arise.
|
From page 27... ...
Kocher pointed out that thus far, security design has been a very closed, opaque process, with little or no regulatory framework. Kocher brought up a broader question: Can we accept a world with inevitable security vulnerabilities, or should we pursue intentionally simpler processors that increase security?
|
Key Terms
This material may be derived from roughly machine-read images, and so is provided only to facilitate research.
More
information on Chapter Skim is available.