TECHNOLOGY AREAS: Information Systems, Battlespace

ACQUISITION PROGRAM: JPEO JTRS ACAT I

The technology within this topic is restricted under the International Traffic in Arms Regulation (ITAR), which controls the export and import of defense-related material and services. Offerors must disclose any proposed use of foreign nationals, their country of origin, and what tasks each would accomplish in the statement of work in accordance with section 3.5.b.(7) of the solicitation.

OBJECTIVE: Develop protocols and software to implement previously un-trusted code within secure communications systems. Leverage the isolation features and other capabilities of real-time operating systems to meet system performance requirements while mitigating information assurance (IA) risks posed by the use of automatic code generators in the development of secure systems.

DESCRIPTION: Recent developments in Software Defined Radio (SDR) have enabled the translation of code developed for one system to be translated into another, promising to allow rapid integration while leveraging earlier development cost. In a parallel vein, recent advances in ACG tools allow designers to originate a system using high-level models, then invoke the automated tool to translate the high-level model specification into code.

However, when code eligible for re-use has not been developed in a secure environment with current best practices, it must be assumed untrusted. Threats include modification of local data, information leaks, luring attacks (co-opting trusted code), serialization attacks and exception attacks [see ref. 2]. Re-used code can contain Trojan horses or back-doors. On the other hand, visual code evaluation, subsequent re-writing and testing to establish trust, are costly. Recently, active research has addressed safe re-use of untrusted code [See refs. 1 and 2].

Real time operating systems (RTOS) play a central role in mitigating the risks posed by auto-generated code. Once a platform has been specified, commercial codes targeted for re-use, and choices of RTOS and ACG tools have been made, developers need to need to configure parameters and settings to safely meet system performance requirements (such as latency) while minimizing IA risks incurred by inappropriate placement of commercial code within program memory. Specifically, both RTOS and code generators allow users to partition program and data memory so that isolated segments only share data through tightly controlled structures. Changes in memory allocations influence these data structures, ensuing test strategies and performance profiles. For example, a finer segmentation of code functions within memory might result in a simpler test plan but impair program performance. The challenge is to organize memory so that designers can exhaustively map input-output space while maintaining system performance. Investigators should isolate key components of the IP stack and develop a proof of concept for a candidate implementation. They should perform tests to validate a series of experiments around the use of isolation capabilities of a RTOS running on one to three JTRS-like processing elements, implementing key functions of JTRS IP waveforms, such as Soldier Radio Waveform or Wideband Networking Waveform.

PHASE I: Identify state-of-the-art ACG tools and an RTOS applicable to SDR. Through experiment and analysis, characterize key trade-offs between granularity of memory partitioning, IA risk mitigation and performance. Develop methodology to exhaustively test input/output behaviors of software within partitions. Develop high-level design of prototype device that will approximate the behavior of a JTRS waveform and utilize isolation technology. Provide report to the government that details experiments, hardware and software elements/tools to be utilized, and the plan for using the same.

PHASE II: Build prototype based on Phase 1 effort. Implement testing strategy to establish I/O behavior of partitioned software. Conduct experiments to characterize throughput and latency with isolation scheme implemented. Negative testing should be included. Allow government observation of experimental work. Report on experimental outcomes in both briefing charts and technical reports.

PHASE III: Transition the Phase II implementation to the JTRS software environment and perform Development Tests. The software generated in this project is subject to approval prior to incorporation into a JTRS radio, which will have security requirements and impacts to the vendor. In addition, the software generated in this project would be considered for incorporation into the JTRS Information Repository, thus allowing JTRS vendors to utilize common software.

PRIVATE SECTOR COMMERCIAL POTENTIAL/DUAL-USE APPLICATIONS: Upon completion of the Phase II of this SBIR, the contractor will be able to leverage a Government investment that encompasses (a) the research and development of a knowledge base to implement un-trusted code (such as freeware IP stacks) in a secure manner; (b) origination of a set of test methods to validate the security of key components (e.g., the GNU Zebra stack) and thereby prepare for their insertion in a secure implementation; and (c) the development of a deep base of experience in the mediation of security risks against performance objectives, allowing the contractor to market its expertise to government agencies and commercial entities involved in IA risk mitigation.

A key aspect of commercialization is the use of lower-cost RTOS vice the high-end RTOS used in DoD classified systems. Another potential product includes a Secure Private Network router or firewall: a router device built from the ground up with secure implementations (secure because of isolation, as opposed to code re-write) of IPSec, OSPF, etc. that provides greater protection of personal data (passwords, financial and health data, etc.) than currently available products at the given price point.

Database security tool: Isolation is used to separate sensitive personal and/or business data from business logic in data processing tools. Potential government products: Government variant of Secure Private Network router/firewall described above.

REFERENCES:
1. Yee, et al., Native Client: A Sandbox for Portable, Un-trusted x86 Native Code, 2009 IEEE Symposium on Security and Privacy

2. Carlisle, Humphries and Hamilton, Safely Redistributing Un-trusted Code using .NET, Proceedings of the 2006 IEEE Workshop on Information Assurance

3. Software Communications Architecture, JTRS Standards, JPEO JTRS, http://jtrs.spawar.navy.mil/sca/home.asp

KEYWORDS: communications; audio; software; JTRS

** TOPIC AUTHOR (TPOC) **

DoD Notice:   Between July 20 and August 16, 2010, you may talk directly with the Topic Authors to ask technical questions about the topics. Their contact information is listed above. For reasons of competitive fairness, direct communication between proposers and topic authors is not allowed starting August 17, when DoD begins accepting proposals for this solicitation.

However, proposers may still submit written questions about solicitation topics through the DoD's SBIR/STTR Interactive Topic Information System (SITIS), in which the questioner and respondent remain anonymous and all questions and answers are posted electronically for general viewing until the solicitation closes. All proposers are advised to monitor SITIS (10.3 Q&A) during the solicitation period for questions and answers, and other significant information, relevant to the SBIR 10.3 topic under which they are proposing.

If you have general questions about DoD SBIR program, please contact the DoD SBIR Help Desk at (866) 724-7457 or email weblink.