As you may have noticed, code and data security is a hot topic, and one covered by a number of the Intel® Embedded Communications Alliance (Intel® ECA) Roving Reporters. Indeed, security is important in protecting financial transactions, personal data such as medical records, and of course military systems dealing with national security. Today, security is tougher than ever because almost all systems, even embedded ones, connect to networks and the Internet. Moreover cost concerns result in the mix of secure and non-secure applications on the same multi-core and/or multiprocessor systems. The good news is that software technology such as separation kernels along with new security-centric features integrated in Intel® processors enable secure system design. Features such as Intel® Trusted Execution Technology (Intel® TXT) and Intel® Virtualization Technology (Intel® VT) - unique to Intel -- can be invaluable in building secure systems.


In this post, I'll dig deep into architectures and technology for maximum security. You might also review two recent Intel ECA blog posts on Intel TXT and Intel VT.


Let's start with formal security standards and specifications so you have some background. Most all security standards promulgate from military work. The commercial industry finds it easier and cheaper to leverage the military work even if the commercial systems require lower levels of security. The Common Criteria for Information Technology Security Evaluation (called Common Criteria or CC) defined in the ISO/IEC 15408 provides a framework for designers to specify security capabilities and for testing labs to validate. While conceived for IT applications, CC applies equally to embedded systems.


Products evaluated to CC get what is essentially a grade called the Evaluation Assurance Level (EAL) - EAL1 through EAL7. Commercial Operating Systems (OSs) such as some versions of Windows and Linux earn the moderately secure grade of EAL4.


Today, the most common approach to meeting CC requirements leverages the architecture called Multiple Independent Levels of Security (MILS). A MILS implementation relies on separation to meet security requirements. Most implementations rely on a separation kernel - a thin layer of software that emulates an environment where secure applications were isolated on dedicated hardware. But the separation kernel can actually mix secure and non-secure OSs and applications. MILS implementations also separate resources, such as memory or I/O, and ensure that secure and non-secure data are never intermixed.


LynuxWorks, an Affiliate member of Intel ECA,  is one of several companies offering separation kernels based on a MILS architecture. The LynxSecure Separation Kernel also embeds a hypervisor and relies on Intel VT. The diagram below depicts the kernel architecture.





























LynxSecure partitions the secure LynxOS separate from other guest OSs such as Windows or Linux.


Steve Blackman, Director of Business Development at LynuxWorks, points out that the separation kernel concept relies on small modular code blocks that can survive scrutiny. Blackman states, "Achieving security relies on a combination of proofs used to prove a higher-level proof."


The design team behind LynxSecure developed the kernel based on the Separation Kernel Protection Profile (SKPP) developed by the National Security Agency. According to Blackman, SKPP requires at a minimum that a kernel separate partitions and control communications between the partitions. But SKPP also defines a more advanced implementation called a Least Privileged Separation kernel (LPSK) and LynxSecure was architected on the LPSK model.


LPSK introduces separation and control at a more granular level. Specifically LPSK defines the concepts of subjects, resources, and partitions. Executable code is an example of a subject. A resource might be a processor core, a section of memory, a network interface, or a disk drive. In the simplest case, a subject may be equivalent to a partition. Or a more complex partition might include multiple subjects.


LynxSecure relies on an XML configuration file to define the relationships between subjects, resources, and partitions. The design team can group objects using the file. For example, you might group one or more subjects along with the specific policies and privileges of those subjects. Blackman suggests that one way you might use such a group is to set scheduling policies for fast interrupt response.


LynuxWorks is preparing to submit LynxSecure for evaluation to both EAL7 and the SKPP -- related but separate evaluation criteria.


Have you mixed secure and non-secure applications on one system? How did you isolate the sensitive code or data? Do you have experience with the CC and EAL process? Design teams following the Intel ECA community would sure benefit from your comments. Let us know your thoughts