Technical Editor Robert Cravotta explores processor and software-processing architectures and the impact they have on system and software development. Relevant architectures include microprocessors, microcontrollers, digital signal processors (DSPs), multiprocessor architectures, processor fabrics, coprocessors, and accelerators, plus embedded cores in FPGAs, SOCs, and ASICs.
Jan 3 2007 7:02AM | Permalink |Email this|Comments (1) |
I received yet another notice in the mail that my or my wife's identity information may have been stolen. In one case, the information was on a portable computer that was stolen. In another case, the server was hacked into for more than a year before they detected the hacker's activity. An alarming difference between these two incidents is how each entity that lost the data did or did not take steps to mitigate the potential downstream problems to us—problems they made possible.
In the first case, the company that lost the data provided us with two years of fraud-alert service, whereas the other organization merely sent us a letter saying we should contact the credit-reporting agencies and handle any arising problems ourselves. One thing to note between these two organizations was that the first was a private business and the second was a government organization.
While these incidents involved server and workstation applications, I believe we will begin to hear more about security-related attacks on embedded systems in the near future. The financial incentives for such attacks are there. According to CyberSource, a provider of software and services for secure electronic payment, credit card fraud management, and verification, online merchants in the US and Canada will lose $3 billion to online payment fraud.
Accessing the controls for major infrastructure facilities, such as the power grid, presents opportunities for aggression in wartime. I recall as an engineering intern my surprise at discovering that legal data/commands could be used to damage equipment, in this case impact-line printers, if the data sent to the equipment contained a specific legal sequence of characters. As more embedded systems become connected to the worldwide network, people will find new incentives for malicious access to what have historically been isolated islands.
One tool for developers that is becoming more visible is a Common Criteria security evaluation. Common Criteria describes a framework for a standard and rigorous process of specification, implementation, and evaluation of computer security products. The EAL (Evaluation Assurance Level) of a system, which is a numerical rank from 1 to 7, is assigned following the completion of a Common Criteria security evaluation. The international standard for EALs has been in effect since 1999.
An EAL1 rank indicates that the system has been functionally tested. An EAL4 rank indicates the system has been methodically designed, tested, and reviewed. EAL4 is considered the highest economically feasible level for retrofitting existing products. According to Wikipedia's EAL entry, commercial operating systems, such as Novell NetWare, SUSE Linux Enterprise Server 9, and Windows 2000 Service Pack 3 are evaluated at EAL4. An EAL5 rank encompasses semiformal design and testing, while EAL6 adds verification. An EAL7 rank is the highest rank and encompasses formally verified design and testing.
Another component of the Common Criteria is the protection profile (PP) that applies to that type of system. Understanding the different protection profiles for an application is important to be able to meaningfully compare the EAL of two systems. For example, two protection profiles for operating systems are the CAPP (Controlled Access Protection Profile) and the SKPP (Separation Kernel Protection Profile). The SKPP is stricter than the CAPP in that it goes beyond just memory protection to ensure that programs in different partitions are isolated from each other.
I'm bringing embedded security up as an item for you to consider in your requirements checklist, especially if your end design will be connected to a network. Just because no one has done anything malicious with your product before, if there is a way to do it after you add network connectivity, it will eventually surface someday unless you begin to take steps to mitigate it. Depending on what steps you did or did not take for securing your embedded system, there could be future liabilities to contend with. I hope to delve into greater detail on this topic later this year. If this is a topic you are involved with, please contact me.