As mentioned earlier, embedded security SW is usually (and preferably) run out of ROM. This comes as clear contradiction to many electrical engineers who have learned to debug their designs by loading the code out of RAM, since, if a bug is found later on it would be straightforward to correct the source, recompile the pertinent modules, relink the appropriate code pieces and libraries, create the new executable image, and load the runtime environment into RAM. Next time one boots the embedded system, it will inevitably execute the corrected code. This seems so neat that one may be tempted to ask what is the problem with this picture.

The answer should not come as a surprise to anyone responsible for security. You never know what code your system will be forced to execute when the code is loaded from outside every time you power up the system. To put it crudely, someone may have planted a new memory module beyond your knowledge. We have built an elaborate case in this book around the premise that essentially nothing can be trusted inside someone s equipment if the stakes are high. Therefore depending on what level of security one needs to achieve, one must assume an opponent will engage the unthinkable. If a special PC adapter has to be installed inside your PC to steal information from your hard disk by malicious attackers and transmitted over the LAN or modem to an outside destination while you innocently...