The Computing Community Consortium (CCC) will hold a visioning workshop on Mechanism Design for Improving Hardware Security during the summer of 2022 (exact date TBD). Workshop attendance will be by invitation only—we seek short white papers to help us create the agenda for workshop discussions and select attendees, see more in the application tab. Workshop organizers Simha Sethumadhavan (Columbia University) and Tim Sherwood (University of California Santa Barbara) will host an orientation webinar from 1 – 2:30 PM ET on Thursday, January 13th, 2022 to outline the goals of the workshop and expand on what they are looking for in the white papers. Register to attend the orientation here.

More details about the motivation for the workshop can be found below:

From election security to critical health applications, trustworthy hardware is the bedrock of a modern free and healthy society. Once niche and arcane, the field of hardware security has recently become one of the most pressing issues in cybersecurity. Microarchitectural side channel attacks like Spectre and Meltdown have shown how pervasive, dangerous, and hard-to-fix a hardware attack could be; integrity attacks such as Rowhammer and CLKSCREW show how attackers can practically overwrite user data. As hardware development becomes more like software due to availability of free  hardware designs and tools the prevalence and discovery of these types of design/security problems are likely to accelerate. 

Especially concerning is that these problems, while well-known and publicized, have generally not been fixed pervasively. Why? The answer, perhaps, is not only a lack of technical solutions that are considered practical but also a series of market failures such as information asymmetry, prisoners dilemmas, and markets for lemons, which disincentivize those who are able to fix serious security vulnerabilities from doing so.  

Underpinning these market failures is the fact that hardware security usually comes at a cost in terms of performance, power, or area; present issues in hardware security can be seen as the result of the players in the game of hardware security finding ways of avoiding paying this cost. 

At this workshop, participants will investigate ways to improve the design and uptake of hardware security mechanisms. In addition to looking at traditional technical solutions, the workshop will also consider new mechanisms to incentivize designers, system integrators, and users to create and maintain security of their systems. The workshop will bring together hardware and software security experts and economists and experts in devising and implementing governmental policies.

Questions and topics to be discussed at the workshop include:

• How do current policies and market structures disincentive hardware oriented security solutions? How do we fix this: what technical and policy frameworks are necessary to make progress in this area?
• What are the mechanisms necessary to enforce a government mandate that says that X% of the performance or cost should be set aside for security? What mechanisms are necessary to determine X? How often should X be determined? Is there a quantitative approach for the organization to use up this security budget? How would this be enforced on user systems? Are there alternate government mandates that are actionable and can be supported technically?
• Is there an equitable way to proportion the benefits of security and impacts of security attacks? What hardware support, if any, is necessary to facilitate this process? (insurance)
• How do we establish a chain of responsibility for malicious and negligent action while also maintaining privacy?
• Are the mechanisms for hardware security different from those required for privacy?
• How can hardware innovations (e.g. U2F tokens) fundamentally impact software dark economies
• What incentives are necessary to patch hardware bugs in a timely manner?
• What education/certification requirements are necessary for increasing the awareness and application of hardware security solutions?
• Are there parallels to software certification requirements for hardware? What would this assurance/certification requirements look like?