- Secure the core
- Use a Harvard computer architecture. In other words build entirely separate logic pathways (including caches) for instructions and data. This means that you can't have 'self modifying code' but so what ? Less than 1% of the code in the world is really self modifying and that code is not really required and can be worked around in other ways with modest performance cost. It is like trading turds for diamonds. Easy decision.
- A little more detail for clarity for CPU designers. Yes I literally mean separate data paths and caches for instructions and data, all the way to the ALU instruction units. No buses or caches should ever be shared, period. Think entirely different systems. This guarantees that no matter what magic software does it cannot modify the expected behavior of software instructions delivered to the CPU. Period. End of story. Drop the mike. Case closed. No encryption coprocessor. No decryption keys. No asterisk. No buts. The CPU is now naturally secure by design. Trying to secure every line of software in a non Harvard architecture is like trying to stop rain one drop at a time. Totally nuts.
- You can and should still have caches for performance, but since the caches aren't shared there is no concern for security. There is no coherence or complexity issue either, since by definition the instructions and data are separate you don't have to worry about coherence between the instruction and data caches.
- Secure the box
- All software should be delivered and run from 'ROM sticks' (ROM = Read Only Memory). Imagine a small box with several USB like slots in it. Each slot contains a stick from a trusted software vendor. Installing new software from a trusted source literally means replacing the ROM stick in that slot in your computer. Pulling the stick out of the slot 'uninstalls' it. All software runs from ROM, not a hard drive.
- Finally you should then only buy software ROM sticks from trusted software vendors.
Congratulations. You now have a secure computer. Go sell a million of these to the military and get rich. You're welcome.
A couple more points for clarity and background.
- The hard drive
- Once the CPU core and software ROM path is secured per above the hard drive becomes the next vulnerability point to secure. This is because if software is allowed to write arbitrary information to your hard drive, this in an indirect way enables software the ability to behave in malicious unpredictable ways. This is similar to the self modifying code problem in the CPU, but is at a higher level - the file IO level. You should only buy software from trusted software vendors who certify that their software does not store any 'cookies' or such on your hard drive to effect software behavior.
- The good news is that if the CPU and box are secured per steps 1 and 2 above the options for malicious actors to do malicious things to your computer are limited to them finding bizarre behavior effects for unusual data. Even then since they can't execute code on your computer their hands are indeed very very tied. Cool.
- JavaScript is evil
- JavaScript by design is intended to be downloaded per website and executed on the users local machine. Isn't that like parking an RV in a crime ridden neighborhood in the middle of the night, opening the front door and putting a neon Welcome sign above the door, and then acting surprised when a stranger comes in and misbehaves. Sheesh.
- For this and several other technical reasons let me suggest RISCV discussed in a previous post for those looking for an open universal machine language, as an alternative to Java.
Further Info:
