Department of
Computer Science 

HUT

root 

This is the second version of a new idea (well, at least new to me). It may, however, be already patented.

Time to introduce sex to computers?

Not quite, but maybe it is time to copy solutions from biological systems to computers.

Every individual member of a sexually reproducing species is different from every other individual of that species, as long as we don't consider identical twins. These small variations between individuals make it more difficult for viruses and bacteria to spread. A strain of bacteria well adjusted to a certain individual may find the next individual quite resistant to it.

Similarly, should not every computer be slightly different from every other computer so that it would be more difficult for viruses and other malware to spread.

How could we do this

There are possibly limitless number of ways to make computers different from each other. Here is one scheme to do it:

Let us add a decrypting unit into the CPU chip, in front of the instruction decode unit, so that the only path for instructions to reach instruction decode and execution is trough the decrypting unit. Now, consider a simple scenario:

The binary code of the operating system and all application software is encrypted with a key. When a process is run, the corresponding decryption key is loaded into the decryption unit in the CPU. Thus the CPU would execute ordinary binary code, but the unencrypted version of the binary would exist only on the CPU-chip between the decryption unit and the instruction decode unit.

What good will this do for us?

Let us assume there is a bug in the browser. By explointing the bug it is possible to add a file to the startup folder of the computer causing the file to be executed at the next boot.

Now, if the whole software of the computer is encrypted, the chance of the new file to be encrypted with the correct key is quite small, something like one out of 2**32. The new file will be executed, but it contains just random bits after it has been decrypted by the decryption unit in front of the instruction decode, random bits, which, when fed to execution, will cause some exception to be raised sooner or later, most likely an illegal instruction exception, thus stopping the execution.

Executing random instructions for an undefinite time is not good, but -- er, well, sorry but this just will not do. We need the decryption unit to be able to tell us that either the instructions it delivered to execution really were encrypted with the right key or then the decryption unit must be able to raise invalid code condition, which will trigger the cpu to do an interrupt, similar to an illegal instruction interrupt.

So we either run code we can trust or we get an immediate abort of the process.

The good news here is that the exploit will not be able to spread, not onto this machine nor to another machine from this machine. This might even make writing exploits so useless that most bad crackers would stop writing them. Similarly viruses spreading by email or worms using buffer overflows will find the new host unhospitable.

We have gained possibly complete immunity from viruses and malware, they can no longer spread, which is a rather significant relief.

On the other hand, we haven't necessarily given up much of importance, the silicon real estate required for the decrypting unit is quite small compared to the number of transistors on a modern CPU chip. We have placed one significant demand on the decrypting unit, it must be able to differentiate good, correctly encrypted code from unencrypted malware code. This is, I believe, possible, but the encryption-decryption cycle is not trivial with this added requirement.

There is one real problem: the system must be designed in such a way the it will not become a privacy nightmare. If a computer is cryptographically individual, that is undeniably identifiable, there may arise a way to undeniably link everything that is performed on the net with that computer to that computer and thus to some individual person. However, it should be possible to avoid this trap, but the designers need to be aware of this danger. Giving the user the possibility to pick and change the encryption key at will may solve most of this. And this may give us a sort of digital rights management with anonymity.

keywords: computer security, computer individuality, encrypted code



[HUT homepage] [Department of Computer Science]
This page is maintained by Heikki(dot)Arppe(at)cs(dot)nospam(dot)fi - replace nospam by hut
Last modified: 2005-05-12