[trustable-software] I fear we need trustable hardware too...
Colin.Robbins at nexor.com
Thu Jan 4 11:53:59 GMT 2018
From my perspective, trustable "anything" has dependencies, and a key factor in determining trust is how well can you understand trust the dependencies.
Software depends on hardware.
So you have to either trust the hardware, or build the software such that it minimises the trust in the hardware.
Meltdown + Spectre are side channel attacks. In the crypto world, side channels have been know about for a long time, and the "trustable" crypto suppliers will have designed controls (hardware or software) to reduce the risk.
I think this is an example of the point I tried to make yesterday - security changes over time, and new vulnerabilities are discovered. The trustable solutions are ones that have anticipated potential, undiscovered, vulnerabilities and offer mitigations (but you can't directly validate by testing). It's what high grade crypto does, but also why its expensive.
Tel: +44 (0) 115 953 5541
From: trustable-software [mailto:trustable-software-bounces at lists.trustable.io] On Behalf Of Paul Sherwood
Sent: 04 January 2018 11:10
To: trustable-software at lists.trustable.io
Subject: [trustable-software] I fear we need trustable hardware too...
When this discussion list in 2016 we were already seeing enough news headlines to realise the scale of the elephant in the room for software trustability.
Now it's becoming clear  with the discovery of the Meltdown + Spectre  vulnerabilities (and Rowhammer), we have to think about the elephant underneath... in the hardware.
My immediate emotional reaction has been to worry that this is just another signal that what we're thinking about is futile. What's the point of trustable software, if we can't trust the hardware?
After reflection and discussions with colleagues, we broadly concluded that discovering a secret tunnel into the basement doesn't reduce the need for us to fix the front door lock.
I need to re-scope and re-think some of my presentations and diagrams to include hardware, and expressly escalating hardware risks for customer projects.
But I'm interested to get others' thoughts on this, in the aftermath...
- are we wasting our time?
- is there any of what we are thinking about that re-applies to hardware?
trustable-software mailing list
trustable-software at lists.trustable.io
More information about the trustable-software