Is it possible to engineer a computer that is 100% secure?
If you answered “no” to this question, you’re in good company. Pretty much everyone that knows anything about computer security shares this view as well. And as we all know, if everyone (95-99%) believes something is true, it must be true, right?
As you might have already guessed, I’m in the minority that says that it is possible. I don’t hold it against you that you don’t believe it’s possible. Being quite honest, I expect you to not believe it’s possible. Why? Because given current computer technology and security paradigms, it’s impossible. But I’m not talking about making current computing technology secure, I’m talking about starting from scratch with a clean sheet of paper. If you’re interested in how it might be possible to engineer a computer that is 100% secure, please read on.
Before we continue, there are two things you should know:
1. I don’t have all the answers. There are people who are much smarter than I am at all of this and I bet they can come up with an even better solution – and ultimately, that’s what I’m hoping others will do. But before that can happen, more people need to believe that a computer can be 100% secure.
2. Re-thinking computer security isn’t easy. All this makes intuitive sense to me, but it may not make any sense to you. If you have questions, ask. Given #1, I’m open to any and all comments, suggestions and criticisms.
There are four things that need to be secure in order for a computer to be 100% secure – the hardware, the operating system, the application software and the user’s data. By secure, I mean that someone cannot perform actions that will result in unauthorized control of a device, unauthorized control or modification of the executing code, or unauthorized access to data or configuration information.
For this post, I’m going to start by focusing on securing the operating system. The primary concern I want to focus on is operating system compromise. By compromise, I mean the injection of malicious code into the file system – either a root kit, key logger, TCP/IP stack hijacker, malicious copycat daemon/service, etc. There are no third party operating system add-ons in this scenario, just the operating system itself. And just so that you know, buffer overflows are technically impossible in my re-engineered new world order. We’ll have to discuss preventing buffer overflows another time.
So if you had to re-engineer the hardware to make the operating system impervious to compromise, how would you do it? Get out a blank sheet of paper and start jotting down and sketching out your ideas. Don’t continue until you’ve given this some thought.
** Mister Reiner hums the Jeopardy theme song while you’re thinking. **
Ready? This is my idea:
Hardware and Operating System
1. Operating System Management Module (OSMM). This sealed module plugs directly into the hard drive. The OSMM is responsible for managing and updating the operating system and has a user interface (admin and user). It has its own internal operating system and network card. When the computer is powered on, it boots into the OSMM after the initial POST. The OSMM does complete manifest and MD5 checks on all operating system files. The OSMM establishes it’s own connection to get updates from a local or remote update server. No inbound connections can be established to the network card.
2. Smart operating system (OS) hard drive. For the purposes of this discussion, there are four unique features of this drive:
- It “binds” (keys) itself to the OSMM and once bound, cannot be accessed by any other OSMM without reformatting the hard drive.
- Only the OSMM can write to the hard drive through a dedicated interface. The rest of the computer only has read access to the smart OS hard drive through a different interface.
- Prior to starting the operating system, the OSMM locks out the write capability of the smart OS hard drive.
- The drive only contains static operating system files. All dynamic files and settings files are stored on a different drive.
3. Operating system that is OSMM aware. The operating system will only load operating system executables from the smart OS hard drive. For an OS using something like the Windows registry, only static OS specific registry information is stored on the smart OS hard drive. Other non-OS registry entries or dynamic OS entries are stored on a different drive.
Simple Concept of Operation (CONOPS)
The computer boots into the OSMM and the OSMM verifies the integrity of the operating system files on the smart OS hard drive. The OSMM establishes a connection to an update server to determine if any updates are required. If any updates are required, the OSMM updates and re-verifies the integrity of the files. After the OSMM is done with it’s tasks, it locks out the smart OS hard drive and launches the operating system loader. If anything is amiss, the OSMM will generate an error message, stop and provide a menu of available actions.
Local and remote server updates are hosted on servers with a special OSMM update card. The update card will only obtain operating system updates from the operating system vendor’s designated servers or another server running a OSMB update card specified by the system’s administrator. Distributed update architectures are allowed. If there is no local or remote update server specified or accessible, the OSMM defaults to the operating system vendor’s designated servers.
Potential Operating System Compromise Vectors
1. From what I described above, it’s impossible for any malicious code that makes it’s way into the operating system environment to write to the smart OS hard drive.
2. OSMM update man-in-the-middle attack. I’m not up on on the latest encryption technologies (sorry, been slacking), but I’m sure someone smarter than me knows how to best address this issue. Some type of chain of custody and/or trusted source verification process needs to be established to prevent man-in-the-middle attacks.
3. OSMM update server spoofing. This needs more thought. See #2.
4. OSMM admin interface access. Two/three factor authentication? A physical electronic key, that is unique to each administrator, can perhaps be bound to the OSMM. This needs more thought.
The overall architecture and concept described above can be applied to applications as well, but I would expect a shared module and hard drive for applications vice a dedicated module and drive for each application. Hard drive partitioning seems to make the most sense. There will have to be a third drive for settings, and other OS and application specific working files – and a fourth drive for user data. I realize that there are a myriad of issues when it comes to downloading, installing and managing applications, but they can be overcome with the right approach.
For all you LiveCD fans, what I’m essentially describing is a LiveCD that can update itself. It’s like checking, updating and burning a new ISO image from a trusted source every time the computer is started, but doing it with a hard drive instead of a CD or USB drive.
Given the architecture I’ve described thus far, it becomes impossible for operating system and application executables, and the folders in which they reside, to become “infected” will malware while someone is using a computer. Even if a hacker could figure out how to write executables to a writable hard drive, they’ll never run because it’s impossible to write to the drives from which executables are allowed to load and execute. For all intensive purposes, a hacker’s executables become nothing more than text files.
All of the above is oversimplified for discussion purposes, but I think you get the general idea of how everything works. Yes, I know it’s not as “simple” as what I’ve described above, but what do you expect from a blog post? I acknowledge that there are a lot more details that need to be worked out – and I would be crazy to think that I could work out everything myself. This is only the start of an idea – not a finished product.
So what are your thoughts on what I’ve presented? Can this idea be refined to the point of being 100% secure? Do you have any additional or better ways of doing the above? How can some of the challenges of this type of architecture best be addressed? What’s your idea?
Thanks for taking the time to read this post. I hope I’ve given you something to think about.