Whether you are designing a nuclear fusion ignition system, an advancedweapons system, an unmanned robotics vehicle or an integrated avionicssuite, safety or security critical systems typically requirecertifications thattheir software content meets all of its requirements.
Certification efforts can be risky to both cost and schedule,especially in the most important applications where the consequences offailure are unacceptably high. Certification can also be an arduoustask, often takingmore time and costing more money than the original softwaredevelopment itself. Embedded systems developers benefit from softwarearchitectures that make high levels of certification more achievable.
One such architecture, Multiple Independent Levels of Security(MILS), is intended to simplify the certification process at highlevels of assurance, making it practical and affordable. It alsoenables code and artifact reuse to leverage investment. MILS is alayering architecture with the primary goal of minimizing the amount ofcode that needs the most rigorous inspection. Its layers are theSeparation Kernel, Middleware, and Application.
MILS approach to middleware
Traditional operating system architectures have a large body of coderunning in privileged mode. Because nothing constrains the behavior ofprivileged code, it can violate the system safety and security policiessuch as data isolation and controlled information flow. Considerableeffort is required to rigorously prove all of this code is wellbehaved, that it does not violate or weaken policy enforcement. Thetime, cost, and risk of failure for this proof increases exponentiallyas the code base gets bigger and more complex.
The MILS architecture simplifies high assurance certifications bymoving system functions from the Separation Kernel layer to theMiddleware layer. The resultant Separation Kernel is significantlysmaller and simpler, much more conducive to certification at a highlevel of assurance. The increased confidence that the Separation Kernelwill always enforce the system safety and security policies correctlyreduces assurance requirement levels for the Middleware and Applicationlayers.
The MILS approach is to move as much system code as possible to theMiddleware layer where it runs in unprivileged mode. I/O services, filesystems, and communications protocol stacks are large and complex codebases. Instead of being able to violate the system policies, all ofthat code is now strictly subject to them.
Because of this fundamental difference, a basic to moderate level ofrigor of inspection for that code is now appropriate. Basic to moderatelevel code evaluations are achievable, practical, and affordable forlarge code bases and have been done many times. MILS Middleware,typically linked with the applications that it supports, can be groupedinto three general categories: System Services, the PartitioningCommunications System, and Network Middleware.
System services as middleware
Embedded application developers are accustomed to using a full-featuredreal-time operating system (RTOS). Most of the code in an RTOSimplements the complex services described above. The MILS SeparationKernel has a sparse application programming interface (API); it doesvery few things but it does them very well.
An effective way to bridge this gap is to port an entire RTOS, afamiliar environment friendly to the application developer, to run asMiddleware in a user mode MILS partition. Although it may be perceivedas a signifi- cant engineering task, the path to this transition issurprisingly straightforward.
One of the key objectives for any commercial RTOS is portability toa wide range of processors. For this reason, RTOS code is written tothe greatest extent possible in a processor independent manner.Processor-independent implementation mandates the RTOS designer tominimize the number of operations requiring privileged instructionsbecause privileged instructions are processor specific. The bulk ofRTOS code maintains control blocks, manipulates queues, executesscheduling algorithms, and performs services as requested.
Almost none of these activities require the use of privilegedinstructions. Privileged instructions can't be entirely avoided. MemoryManagement Units (MMUs) must be configured and interrupt systems mustbe controlled, etc. These undertakings are necessarily processorspecific.
Balance between portability and the need to perform processorspecific activities is achieved by isolating the processor specificcode into a few small modules. This set of modules is called theHardware Abstraction Layer (HAL). RTOS developers are adept at writingnew HALs; it is how they can quickly and economically offer theirplatform on the latest and greatest processors. They are providingtheir standard RTOS with a new HAL.
If a HAL can abstract a physical processor, it can also abstract aMILS Separation Kernel. Instead of executing processor specificprivileged instructions, a HAL can use system services to request theseoperations be performed on its behalf by the Separation Kernel. Thehigh assurance Separation Kernel can be trusted to enforce the systemsafety and security policies as it executes requested system servicesand returns the results to the HAL. The HAL translates those results asnecessary and then gives control back to the RTOS.
The end result is that the RTOS does not know that it is running ina user mode partition as the Separation Kernel's “Guest.” Eachpartition in a MILS node can contain its own RTOS. The net effect ofthis architecture is a single microprocessor running multiple virtualmicroprocessors, each of them robustly separated in time and in spacewith tightly controlled communications among them.
The Guest RTOS architecture has many benefits. Legacy applicationswritten for the RTOS can be readily ported to the safe, secure andhighly robust MILS environment with minimal change. Software engineersenhancing legacy applications or developing new ones have the familiarRTOS environment and development tool set.
Actual target hardware is often not available during the early tomiddle stages of a project, creating potential development and testingbottlenecks. If some of the embedded applications do not requirespecialized hardware, or if that hardware can be emulated, unit testingcan be done on any COTS board supported by the RTOS.
Network stacks as middleware
Middleware often requires private execution and threading contexts.Network protocol stacks often fall into this category and are built torun in their own private MILS partitions. Strong separation is asignificant benefit of this architecture.
The application and the protocol stack are protected from eachother, considerably reducing total system vulnerability. Fortunately,moving protocol stacks out of the kernel into their own partitions canbe completely transparent to the applications that use them.
Let's use TCP/IP as an example. The semantics of the socket library(or its equivalent for non-IP based networking) are unchanged from theapplication's perspective. All modifications are hidden “under thehood.” A traditional socket library implementation of data transmissionvia send() copies data from the application to network buffers.
The copy procedure is necessary because the scope (i.e., lifetime)of the data to be sent is unknown. Once the data is copied, it ishanded over to the stack's transport layer via either a function callor a system service, depending on how the stack was implemented.
Alternatively, a MILS implementation of the send() function uses theSeparation Kernel's tightly controlled information flow facilities tomove outbound data from the application partition to the protocol stackrunning in its private partition (Figure1, below ).
|Figure1. MILS network implementation|
The Separation Kernel guarantees that there is no other way for thedata to get there. The most important point is that the applicationjust called send() in either case. What send actually does with thedata is irrelevant to the application as long as the data gets towherever it should be going.
Partitioning communications systemmiddleware
All of the COTS components that are used to connect one machine toanother are a source of vulnerability. The protocol stacks, interfacecards, routers, switches and media were all originally designed to movedata optimally.
Safety or security may not have been original requirements and wereoften bolted on as a series of emergency patches issued as amateurhackers and professional attackers succeeded in penetrating distributedsystems. This reactive approach is always one step behind, counteringthreats only after the damage has been done.
Why not start over, developing protocol stacks with safety andsecurity as a key requirement? TCP/IP protocol stacks are large andcomplex bodies of code. This assertion is proven by noting that it tookRichard Stevens three substantial volumes to explain what they do andhow they do it in the masterwork TCP/IP Illustrated.
Putting robust safety and/or security policy enforcement into aprotocol stack is suboptimal because the resultant code body size andcomplexity conflict with the rigorous inspection necessary to verifyenforcement is adequate.
The amount of code that must be trusted to enforce the securitypolicy among distributed nodes can be significantly reduced in the samemanner as MILS significantly reduces the amount of trusted code thatenforces the security policy within a single node. MILS simplifieslarge problems by dividing them into small problems that can interactonly in predictable ways ” divide and conquer. This methodology canalso be applied to distributed systems.
A security policy enforcement module, the PartitioningCommunications System (PCS), can be interposed between the applicationand protocol stack partitions instead of adding security functions tothe stacks themselves. The PCS can perform its security policyenforcement functions transparently with respect to both theapplications and the protocol stacks (Figure2, below ).
|Figure2. The Partitioning Communications System (PCS)|
PCS: The MILS Architecture Enforcer
The policy enforcement functions performed by the PCS are: flowseparation, strong authentication, bandwidth provisioning andpartitioning, covert channel separation, and secure configuration.
Flow Separation: Providing trustworthy separation of the individual flows (e.g., TCPport connections) on a shared medium (e.g., Ethernet). These flows areto or from multiple application partitions in the node local to thePCS. Because the separation is trustworthy, these flows can be atdifferent security levels (i.e., TOP SECRET vs. SECRET) or differentsafety levels (i.e., CRITICAL vs. NON-CRITICAL). In the past, separatephysical links were required to provide trustworthy “air gap”separation.
StrongAuthentication: I dentifying the node, the application, and theapplication instance at the “other end” of each flow. High value datashould not be transmitted until the sender can verify that therecipient is identified, authorized, and in a safety or securitypreserving state.
BandwidthProvisioning and Partitioning : Controlling the portion of totalchannel capacity that can be used by each flow. This useful securityfunction enforces the designer's targets for allocation of sharedbandwidth which shortens system integration time and increases totalsystem reliability. Denial of Service attacks from malicious or errantsoftware in the transmitting node are also suppressed.
Covert ChannelSuppression : Link level encryption is not enough. Significantcharacteristics of the data and the applications can be discerned byanalyzing traffic patterns, especially in response to external eventswhich may have been caused by the malicious observer himself.The PCS controls message length and timing to counter this threat,transparent to the applications.
SecureConfiguration: One cause of failure a distributed system iserrors or attacks that effectively get each node to enforce differentversions of the overall safety or security policy. Because thedifferent versions are not necessarily compatible and consistent witheach other, each node can be correctly enforcing its local policy buttotal enforcement for the enclave can be compromised. The PCS validatesthat proper versions of the system policy are being enforced for eachflow.
Trusted ImageLoading : It is a common requirement to either load or updateapplications “over the air” after a distributed system has beendeployed. The PCS controls this operation, validating that the softwareoriginates from an authenticated source, that the software has not beenmodified, that the download or update itself has been authorized, andthat the resources required by the downloaded module conform to thesafety or security policy.
PCS is NEAT
PCS communications policy enforcement has a very importantcharacteristic which is required for high assurance. It is NEAT, anacronym for:
Non-bypassable : The MILSSeparation Kernel's data isolation and controlled information flowguarantee that all data must pass through the PCS. It can't becircumvented. The PCS guarantees that data will always flow throughdowngraders, guards, and firewalls, never around them.
Evaluatable : The PCS issmall enough and simple enough to enable the mathematical proof ofcorrectness that is required for high assurance verification,certification, and accreditation. The “trusted plumbing” that the PCSprovides simplifies distributed safety and security modules, enablingtheir high assurance evaluations and validations.
Always Invoked: The safetyand security policy is enforced each and every time that data istransferred. The distributed system does not transmit data unless anduntil all protection is in place.
Tamper Proof: Trustworthydata isolation prevents erroneous or malicious applications frommodifying the PCS code or the data that defines the safety and securitypolicy. The PCS assumes that both the applications and the network arehostile, protecting itself from invalid structure or sequences in thedata that it handles. Attacks based on modifying policy data can'tsucceed.
Putting It alltogether. Revisit Figure 2, above. Application 1 and Application2 need to communicate with their counterparts in an external system. Itis important that their data flows not interfere with each other ineither content or Quality of Service.
Application 1 could be handling SECRET classified data andApplication 2's traffic could be unclassified; Application 1 could besafety critical and Application 2 could be of lesser importance to thetotal system.
The PCS is interposed between these applications and thecommunications partitions in both the sending and receiving nodes. Inthis arrangement, the PCS, because of its high assurance, can betrusted to maintain the required separation and bandwidth allocationswhen the communications facilities can't be trusted to do this bythemselves.
Network Middleware such as CORBA, DDS, and Web Services offer manyfeatures mostly aimed at providing location transparency. Applicationsaren't required to know where their input data comes from and wheretheir output data is going. This transparency conflicts with safety andsecurity requirements. In safe and secure communications systems weneed to know exactly where data comes from and exactly where it isgoing.
Why is porting Network Middleware to MILS desirable? MILS/PCScommunications resolves the conflict. Legacy applications can continueto use their existing Middleware foundations. And new applications canbe developed in those familiar environments because MILS/PCScommunications allows only authorized information flows to occurbetween authenticated sources and destinations at specified maximumrates.
This communications safety and security policy enforcement istransparent to both the application and its Middleware. Once again, theimplementation path is straightforward. Network Middleware residesabove the transport level. Since the socket (or other communications)API remain intact as explained earlier, minimal impact upon NetworkMiddleware is expected.
A system is useful to application developers because of its Middleware.Middleware is the bridge between the rudimentary services such as “waitfor an event” and desirable higher level features such as “extend afile on disk” or “send this data by TCP/IP.”
The MILS architecture moves these complex functions out ofprivileged mode. Running Middleware in user mode, where it is subjectto the Separation Kernel's policy enforcement, reduces the level ofrigor required for its safety and security evaluation andcertification. At the same time, total system robustness is increased.
Evaluation and certification of large code bodies at medium levelsof assurance is achievable, practical, and affordable. The guaranteesof strong data isolation and controlled information flow suppressundesirable side effects, and ensure that the Middleware itself and itsevaluation and certification artifacts are reusable.
Gordon M.Uchenick is Sr. Mentor/Principal Engineer at Objective Interface Systems, Inc.
To read a PDF version of thisstory, go to MiddlewareFor Security AndSafety Critical Systems at