Talk:Open Toaster Architecture

From OSDVwiki

I know that it's hard to make a claim of perfect statelessness (and I am not trying to claim perfection, but a large step toward it) so I hope to see some discussion of that! or other aspects of OTA that seem to be reaching too far.

Contents 1 Previous discussion 2 Rop Gonggrijp 3 Also skeptical about state 4 Missing requirement: trusted reset

[edit] Previous discussion

Hi Rop Gonggrijp here. I'm very skeptical of this entire Fixed Function Device concept, and in an e-mail exchange John Sebes suggested we continue the discussion here. We talked about this before, but here's the mails mostly leading up to this.

John Sebes:

Anyway, it seems that what's really needed is guidance for what a trustworthy high assurance system would be like, including how an independent 3rd party could perform a decent assessment of a specific system's claims of assurance. To that end (though not very far along it), I am working on defining what I call the Open Toaster Architecture -- you might want to check out [url to this page] and see if its interesting.

Rop Gonggrijp:

Interesting. I've been discussing some of this with Andy Tanenbaum here at VU Amsterdam university. He's also a believer, whereas I am a skeptic. One thing that throws off most people thinking about this is realising just how much state any piece of worthwhile COTS equipment has.

E.g: even if you designed something from scratch, would you even know if, say, the bus controller you just bought has firmware? Even the datasheet often doesn't tell you. Your drive (CD/HD) certainly has. Even USB-sticks sometimes come with code that runs on the stick. Granted, it may only used for turning a tiny LED red, yellow or green, but are you sure it couldn't replace a crucial sector when pushed to the limit? Could you even look at this firmware without knowing the factory's secrets? And would you be sure you had all the secrets? Your touch screen controller is also likely to have much more computing power than the Apollo crew module. How about the USB hub? Seems like every chip you buy has firmware these days. Not to mention processors having uploadable code in multiple domains, flashable microcode and on-chip debugging mechanisms that sometimes have permanent state. And if I mess with any of these components, the security is gone. In my opinion, this invalidates the "hardware would be commodity hardware" near the end.

The level of trust in whoever touched the machines is just not something I'm willing to accept in the election process. And I don't buy any of the premises in the piece under the interity tipi, this whole concept of "each integrity mechanism can be bypassed, but the bypass is controlled by another integrity mechanism". That's daydreaming, falsified by a look at even the more paranoid trusted computing designs.

John Sebes:

Great remarks on the Open Toaster Architecture, thanks much! If you wanted to get Andy Tanenbaum into the discussion that'd be fantastic!!! Getting feedback from him would be very helpful indeed -- if I can't make a convincing exposition to a believer, then I've got a real problem. ;-)

I have a responses below to your two excellent comments, but I wanted to suggest that there might be some public benefit to having the discussion online, that is in the discussion area of the wiki. To that end I created a wiki account for you, with details in email. It would be great if you'd toss in some comment, either your original ones I quote below, and any come-back that might be generated by my responses below.

But back to your two excellent comments.

First, on the tipi.

[my quote from above]

I'm not trying to make a case for a bulletproof and/or theoretically provably sound design here, so clearly I have wordsmithing to do. So let me try out on you a different way of saying it. What I am trying to pre-empt with the remark that you took objection to, is responses that mechanism X is fine, but then the bad guys can do Y. My claim is that each route to arbitrary code execution has *some* mechanism trying to get in the way. I am not claiming that every such mechanism is perfect, or that the sum is any better than the weakest link. But very often in these discussions - and I have been on this for years believe me - it is easy to dismiss the ideas in a familiar way: "You're talking about locks on the door, but you've left the windows wide open!" That is to say, there is no point in trying the combo, because there is a simple and obvious way around the whole thing. In the case of the multiple supporting integrity mechanisms, I believe that there is no simple and obvious way around the whole thing. Beyond that, I don't want to make any claims except about worked examples. I was thinking about having a contest for building the "hello world" isolated OTA system; maybe I also ought to have a contest for people to take such systems and demonstrate ways to undermine their integrity.

Second, on HW state. You make an *excellent* point that commodity HW isn't stateless. There is an ideal that each boot process should end up in the same state as the one before, when the boot image is the same. In practice, I think that the most one can claim for OTA is that SW has no effect, but physical access to the HW could completely violate that ideal -- because as you point out the HW does have state. Now, again, you've taken exception to a specific remark "the hardware would be commodity HW". I don't say that it *should* but I do say that it *could* but that depends on your threat model, how high you set the bar. You are right in pointing out that when Rop is setting the bar, commodity HW probably won't cut it.

Here is how I want it work out in practice. We build some stuff, show that it can work on commodity HW, has some very useful properties. Then we look at some specific HW configs, and assess how physical tinkering could enable targeted attack. Then we try and see if there is any way for some existing specific HW configs and physical layouts to make effective use of tamper-evident sealing. If so, then we specify the exact configs as standards for a very high degree of integrity , including physical integrity. Then we also do some industrial design for a new HW spec that uses carefully selected HW components, in a system design and physical config that should enable effective use of tamper evident sealing. Then we public those specs and pay to have some sample systems built for demo. I couldn't say today whether there are some orgs that would think that commodity HW is good enough considering the funding they have. In the US, it would certainly be a step up! In Netherlands, definitely down. I also couldn't say whether some orgs would find custom-designed HW to be cost effective in light of the additional integrity. Certainly, the current US vendors' margins have plenty of slack to include custom HW cost in the COGS! ;-)

In fact, I just want to find out! There is an awful lot we can learn by trying this stuff. At the minimum, we can have some real artifacts to help the discussion between some folks on one end of the spectrum (who I know are very keen on re-using cheap existing HW) and others on the other end (who are psyched about the potential for new open-source HW to help with integrity).

Even if you don't think I'm on the same page as you, I hope that helps shore up my reputation with you! ;-) One last point below ...

[quote from my mail about state in almost anything]

Especially on that last statement ... If I were a citizen of the Netherlands, I would agree. Your government has said computers are not allowed. Your municipalities have shown that non-computerized Dutch elections in the 21st century are quite feasible. Any use of computers would create new risk - you just cannot trust a computer down to the HW. Don't do it! However, in the US, the government is never going to tell counties to go pure hand-count paper ballots (except for handicapped access). They're using computers all over the map literally and figuratively. If we can effect a change where the threats are so down-scoped to the point that physical HW tampering is a top concern, I think we'll have done something really great. And then, yeah, we might also have done some work to show what would be the bang for the buck of custom HW, and see where that leads.

Thanks again! Challenging discussion is really, really helpful!

[edit] Rop Gonggrijp

I'm not trying to make a case for a bulletproof and/or theoretically provably sound design here, so clearly I have wordsmithing to do. So let me try out on you a different way of saying it. What I am trying to pre-empt with the remark that you took objection to, is responses that mechanism X is fine, but then the bad guys can do Y. My claim is that each route to arbitrary code execution has *some* mechanism trying to get in the way. I am not claiming that every such mechanism is perfect, or that the sum is any better than the weakest link. But very often in these discussions - and I have been on this for years believe me - it is easy to dismiss the ideas in a familiar way: "You're talking about locks on the door, but you've left the windows wide open!"

All of this would be fine and well if the problem was computer security. In that case you'd just do the best you could and that would be it. However, the main problem here is a lack of transparency in systems that are replacing a fundamentally more transparent system. Simply put: in computer security, the best we can do will just have to make do. In elections, I feel skeptics such as myself only need to prove that an evil government could 'get away with murder' to make the entire thing a bad idea.

That is to say, there is no point in trying the combo, because there is a simple and obvious way around the whole thing. In the case of the multiple supporting integrity mechanisms, I believe that there is no simple and obvious way around the whole thing.

Again: this is all assuming we trust the chain of custody for every instance of this artefact we're producing. If we have this level of trust, why not task the high people we trust this much to perfom an opinion poll, and use the outcome of that? The whole (and often forgotten) point of an election is that the whole thing can be observed.

Second, on HW state. You make an *excellent* point that commodity HW isn't stateless. There is an ideal that each boot process should end up in the same state as the one before, when the boot image is the same. In practice, I think that the most one can claim for OTA is that SW has no effect, but physical access to the HW could completely violate that ideal -- because as you point out the HW does have state. Now, again, you've taken exception to a specific remark "the hardware would be commodity HW". I don't say that it *should* but I do say that it *could* but that depends on your threat model, how high you set the bar. You are right in pointing out that when Rop is setting the bar, commodity HW probably won't cut it.

Before we discuss the height of the bar, elections should always be able to withstand a few smart people working for the dark side, no?

Here is how I want it work out in practice. We build some stuff, show that it can work on commodity HW, has some very useful properties.

My fear is that it will renew people's trust that "a technical non-paper solution is possible". This misguided trust is something that I and many others have worked very hard to destroy.

Then we look at some specific HW configs, and assess how physical tinkering could enable targeted attack. Then we try and see if there is any way for some existing specific HW configs and physical layouts to make effective use of tamper-evident sealing. If so, then we specify the exact configs as standards for a very high degree of integrity , including physical integrity.

[...]

Again: all of this would make perfect sense if this were essentially a security problem.

Even if you don't think I'm on the same page as you, I hope that helps shore up my reputation with you! ;-) One last point below ...

Hey, no worries, I enjoy a good debate as much as the next guy.

[quote from my mail about state in almost anything]

Especially on that last statement ... If I were a citizen of the Netherlands, I would agree. Your government has said computers are not allowed. Your municipalities have shown that non-computerized Dutch elections in the 21st century are quite feasible. Any use of computers would create new risk - you just cannot trust a computer down to the HW. Don't do it! However, in the US, the government is never going to tell counties to go pure hand-count paper ballots (except for handicapped access).

I still think helping them do it on computers is the wrong way. For many reasons, some completely unrelated to the debate at hand, Americans need to disentangle the mess that US elections have become. Even though I will accept that the introduction of optical-scanners over DREs is worth campaigning for, this is only because with opscans, the paper is there.

Your 'solutions' would only provide some kind of reassurance where none is warranted. Maybe, after this is all over and DREs are gone, some of this might make sense in related domains such as central tabulation. In light of the stuff I mentioned before, I think that right now, especially in the context of the current political situation in the US, the only useful thing technologists like us can do is prove that computers cannot begin to provide the transparency needed in the electoral process.

(Which hurts a little bit with me too: I'd like to also offer something more constructive...)

Thanks again! Challenging discussion is really, really helpful!

Only if I can change your mind... :)  ;)

[edit] Also skeptical about state

The current Wiki page seems to suggest that it's OK if the device contains updateable BIOS or firmware. I think that's a problem.

It seems to me that if the hardware contains BIOS or other firmware that can be updated by software, it doesn't deserve the title "stateless".

I can understand the goal of prototyping stuff on commodity hardware (which isn't stateless because it contains software-updateable BIOS/firmware), to get some experience and build some initial stuff, with the intent of then modifying the hardware platform to eliminate all of the software-updateable non-volatile state. OK, that's understandable. But there are some risks: (1) One has to make sure not to forget to do the important step of fixing the hardware, or an important part of the security architecture has been lost. (2) There's a risk that changes to the hardware platform might require significant changes to the software (e.g., because you need different drivers, or a different instruction set, or what-have-you), so it may be worth thinking about this in advance.

[edit] Missing requirement: trusted reset

I think you need to add one more requirement: the toaster needs to contain a trusted reset functionality that the user can invoke, and when the user invokes it, we can be certain that all of the state of the hardware/software is reset.

Example: The toaster might have a big red button that when pressed forcibly resets the state of the machine by doing a hard reboot.

Warning: Note that a soft reset (such as typically happens when you press Ctrl-Alt-Del to reboot) is not sufficient to provide this property. Typically, on a soft reboot, the state of memory is not cleared, and the state of various devices (e.g., your video card) may not be reset, either. Yanking the power for a minute and then restoring it probably is sufficient, if the hardware has no non-volatile storage anywhere. Intermediate positions need further analysis.

Warning: The trusted path issue is important. It is important that this be under hardware control, not under software control. Ctrl-Alt-Del does not suffice, because software could just ignore the Ctrl-Alt-Del, or worse, display a sequence of screens that makes it look like the machine is rebooting when actually it is not. For many applications, it's a crucial requirement that when the user thinks he/she is resetting the device, the device truly is reset -- for instance, if the user does something with the machine that causes the machine's running software to be subverted/compromised/penetrated, and then the user resets the device, we want it to restart a fresh new copy of the software from a known-good state with high confidence that the malicious code cannot persist across a reboot. This is one of the key properties of a toaster that makes it useful for many security purposes; if you can't provide that property, it's much less useful; and to provide that property, you need a hardware reset button that the user can trust.

Recommendation: For human factors reasons, if you expect that the user ought to be pressing the reboot button after each task, I'd suggest that you program the legitimate software to shut itself down after each task, so that the user is forced to press the button after each task. The hope is that this will train the user to get into the habit of pressing the reset button after each task. Of course if the running software becomes compromised during some task, it might decline to shut itself down, but we hope the user will be in the habit of pressing the button between tasks anyway and so will be safe despite the attempts of the malicious code to fool the user.

For human factors reasons, it is important that the reset operation be very fast. This means that you need a very fast reboot operation. This may be a challenge with OSDV's current approach to building toasters (stripped-down Linux), as the current approach takes quite a while to boot -- too long to imagine pressing the button after each task you do.