HR001119S0017.pdf

HR001119S0017

Microsystems Technology Office Broad Agency Announcement

Guaranteed Architecture for Physical Security (GAPS)

January 4, 2019

Foreword In June 2017, the Defense Advanced Research Projects Agency (DARPA) announced the Electronics Resurgence Initiative (ERI), a five-year, upwards of $1.5B investment in the future of domestic, U.S. Government (USG), and Department of Defense (DoD) electronic systems.

ERI recognizes and addresses long-foreseen obstacles to Moore’s Law – the transistor scaling trend that has allowed for 50 years of rapid progress in electronics. To address these issues, ERI kicked off a major investment that draws on the contributions of several ongoing DARPA programs and creates new, long-term technology investments. Through novel research and development (R&D) in semiconductor materials and integration, architectures, and designs, ERI programs will promote circuit specialization as a complement to transistor scaling. The success of these efforts will depend on constructively enmeshing the technology needs and capabilities of the defense enterprise with the commercial and manufacturing realities of the electronics industry.

The first annual ERI Summit, held in July 2018, featured four workshops designed to generate ideas for future ERI programs. Three key issues emerged from the workshop discussions: the need to support domestic manufacturing options and enable them to develop differentiated capabilities for diverse needs; a demand to invest in chip security; and a desire to create new connections between the various ERI programs and to demonstrate the resulting technologies in defense applications. ERI Phase II will build on the existing ERI programs to address all of these challenges, with the goal of supporting a domestic semiconductor manufacturing industry that can implement specialized circuits, demonstrate that those circuits can be trusted through the supply chain and are built with security in mind, and are ultimately available to both DoD and commercial sector users.

To create unique and differentiated domestic manufacturing capabilities, potential areas of exploration in Phase II include the integration of photonics and radiofrequency (RF) components directly into advanced circuits and semiconductor manufacturing processes. This is important for the DoD because the Department’s electronics manufacturing needs are numerous and diverse and its systems have unique requirements and specific functionality. Anticipated investments will seek to ensure that new capabilities support a strategy for the enduring availability of differentiated, high-performance electronics for the DoD and its commercial sector partners. To date, DARPA has announced multiple efforts – Photonics in the Package for Extreme Scalability (PIPES) and Technologies for Mixed-mode Ultra Scaled Integrated Circuits (T-MUSIC) – within this area.

To provide for trusted electronics components, potential Phase II areas of exploration include electronics that can enforce security and privacy protections as well as technologies to enable traceability for electronic components, from design through use. The DoD has unique requirements for assured electronics, requiring that it mitigate risks posed by fraudulent parts; the unauthorized extraction of sensitive information during component design, build, and operation;

and the insertion of malicious hardware or software. The Guaranteed Architecture for Physical Security (GAPS) program specifically will develop hardware and software architectures with physically provable guarantees to isolate high risk transactions and to enable systems with multilevel data security assertions.

One specific aspect of the security concerns raised is the need to have data assurance through architectural change. Whether a piece of information is classified, proprietary, or private, we wish to have guarantees of where that information resides at any one time. This is consistent with the theme of the chip design playing a foundational role in next generation systems, where the physics complements the code that is written at the application layer. The previous ERI architecture explorations have focused on performance, namely how to change architecture for specific domains such as data analytics. The GAPS architecture exploration, instead, looks squarely at security. Secure operation is a tenant that must be paid attention to alongside performance and therefore is the newest addition to the ERI family of programs.

Together with the ongoing ERI programs, including the “ERI Page 3 Investments” announced in 2017, ERI Phase II is the next step in creating a more robust, secure, and heavily automated electronics industry that will provide a foundational contribution both to U.S. national security and to the needs and ambitions of the commercial sector, with new capabilities emerging in the 2025 to 2030 timeframe. DARPA is eager to receive proposals from entities that can help to achieve this goal. For further reference, an updated list of ERI programs, solicitations, and events is available via https://www.darpa.mil/work-with-us/electronics-resurgence-initiative.

Table of Contents

PART I: OVERVIEW INFORMATION

PART II: FULL TEXT OF ANNOUNCEMENT

I. Funding Opportunity Description A. Background B. Program Description C. Program Structure D. Technical Areas E. Schedule/Milestones F. Deliverables G. Government Furnished Equipment/Property/Information H. Intellectual Property

II. Award Information A. General Award Information B. Fundamental Research

III. Eligibility Information A. Eligible Applicants

1. Federally Funded Research and Development Centers (FFRDCs) and Government Entities

B. Organizational Conflicts of Interest C. Cost Sharing/Matching D. Associate Contractor Agreement Clause E. Other Eligibility Criteria

1. Collaborative Efforts

2. Ability to Support Classified Development and Integration

IV. Application and Submission Information A. Address to Request Application Package B. Content and Form of Application Submission

1. Abstract Format (TA1 and TA2 only)

2. Full Proposal Format

3. Proprietary Information

4. Security Information

a. Program Security Information

b. Unclassified Submissions

c. Classified Submissions

5. Disclosure of Information and Compliance with Safeguarding Covered Defense

Information Controls

6. Human Research Subjects/Animal Use

7. Approved Cost Accounting System Documentation

8. Section 508 of the Rehabilitation Act (29 U.S.C. § 749d)/FAR 39.2

9. Small Business Subcontracting Plan

10. Intellectual Property

a. For Procurement Contracts

b. For All Non-Procurement Contracts

11. Patents

12. System for Award Management (SAM) and Universal Identifier Requirements

13. Funding Restrictions

C. Submission Information

1. Submission Dates and Times

a. TA1 and TA2 Abstract Due Date

b. Full Proposal Dates:

c. Frequently Asked Questions (FAQ)

2. Abstract Submission Information (TA1 and TA2 only)

3. Proposal Submission Information

a. For Proposers Requesting Cooperative Agreements

b. For Proposers Requesting Contracts or Other Transaction Agreements

c. Classified Submission Information

4. Other Submission Requirements

V. Application Review Information A. Evaluation Criteria

1. Overall Scientific and Technical Merit

2. Potential Contribution and Relevance to the DARPA Mission

3. Cost Realism

B. Review and Selection Process

1. Review Process

2. Handling of Source Selection Information

3. Federal Awardee Performance and Integrity Information (FAPIIS)

VI. Award Administration Information A. Selection Notices

1. Abstracts

2. Proposals

B. Administrative and National Policy Requirements

1. Meeting and Travel Requirements

2. FAR and DFARS Clauses

3. Controlled Unclassified Information (CUI) on Non-DoD Information Systems

4. Representations and Certifications

5. Terms and Conditions

C. Reporting D. Electronic Systems

1. Wide Area Work Flow (WAWF)

2. i-Edison

VII. Agency Contacts VIII. Other Information

A. Proposers Day B. Protesting

ATTACHMENT 1: Cost Volume Proposer Checklist ATTACHMENT 2: Proposal Summary Slide Template

PART I: OVERVIEW INFORMATION

Federal Agency Name: Defense Advanced Research Projects Agency (DARPA), Microsystems Technology Office (MTO)

Funding Opportunity Title: Guaranteed Architecture for Physical Security (GAPS) Announcement Type: Initial Announcement Funding Opportunity Number: HR001119S0017 Catalog of Federal Domestic Assistance Numbers (CFDA): 12.910 Research and

Technology Development Dates: (All times listed herein are Eastern Time) o Posting Date: January 4, 2019 o Proposers Day: January 23, 2019 o TA1 and TA2 Abstract Due Date: February 1, 2019

No abstracts for TA3 o TA1 and TA2 FAQ Submission Deadline: March 8, 2019 o TA3 FAQ Submission Due Date: February 18, 2019 o TA1 and TA2 Proposal Due Date: March 22, 2019 o TA3 Proposal Due Date: March 4, 2019 o Estimated period of performance start: September 2019

Concise description of the funding opportunity: The Defense Advanced Research Projects Agency (DARPA) is soliciting innovative research proposals in the area of developing hardware and software architectures with physically provable guarantees to isolate high risk transactions and to enable systems with multilevel data security assertions.

Anticipated Funding Available for Award: The total value of the program is $54.4 million.

Anticipated individual awards: DARPA anticipates multiple awards for Technical Area 1 and 2 and a single award for Technical Area 3.

Anticipated funding type: 6.1 and 6.2 Types of instruments that may be awarded: Procurement contract, cooperative agreements, or other transactions.

Agency contact:

o Walter Weiss, Program Manager BAA Coordinator: GAPS@darpa.mil

DARPA/MTO

ATTN: HR001119S0017

675 North Randolph Street Arlington, VA 22203-2114 mailto:name@darpa.mil

PART II: FULL TEXT OF ANNOUNCEMENT

I. Funding Opportunity Description

The Defense Advanced Research Projects Agency (DARPA) often selects its research efforts through the Broad Agency Announcement (BAA) process. This BAA is being issued, and any resultant selection will be made, using the procedures under Federal Acquisition Regulation (FAR) 6.102(d)(2) and 35.016 and 2 C.F.R. § 200.203. Any negotiations and/or awards will use procedures under FAR 15.4, Contract Pricing. Proposals received as a result of this BAA shall be evaluated in accordance with evaluation criteria specified herein through a scientific review process.

DARPA BAAs are posted on the Federal Business Opportunities (FedBizOpps) website, http://www.fbo.gov/ and, as applicable, the Grants.gov website at http://www.grants.gov/. The following information is for those wishing to respond to the BAA.

The Microsystems Technology Office at DARPA seeks innovative proposals in the areas of developing hardware security and software architectures with physically provable guarantees to isolate high risk transactions and to enable systems with multilevel data security assertions.

Like many system owners, the Department of Defense (DoD) processes sensitive data in system enclaves, isolated from other systems. Corporate and government system architects pay particular attention to any interfaces between such enclaves and less trusted systems. In this BAA, we define ‘high risk transactions’ as instances when data moves between systems of different security levels.

Today, modern computing systems are incapable of creating sufficient security protections such that they can be trusted with the most sensitive data while simultaneously being exposed to untrusted data streams. Specifically, it is common knowledge that one should not load extremely sensitive data on internet-facing computing systems (even if you install an anti-virus product).

Therefore, for the most sensitive computing systems, DoD and commercial industry have in certain places adopted a series of air-gaps – breaks between computing systems to prevent the leakage and compromise of sensitive information.

For the purposes of the GAPS program, we consider high risk transactions in terms of privacy and security that are required and pay particular attention when ‘secure’ and ‘unsecure’ systems are attached. Over the past 40 years this has led to niche industries of ‘guards’ that are typically externally retrofitted into existing systems in contrast to mature engineering processes that considers security as part of a system.

The proposed effort should investigate innovative approaches that enable revolutionary advances for the DoD to maintain separation of systems with different security levels. The DoD needs to be able to leverage commercial hardware and most importantly, commercial software development paradigms to enforce physical primitives to increase security and allow the fusion of data across systems of different levels to support DoD operations.

http://www.fbo.gov/

The total value of the program is $54.4 million dollars. Proposals received as a result of this BAA shall be evaluated in accordance with evaluation criteria specified herein through a scientific review process.

Proposers must submit to each Technical Area separately. A single proposal addressing more than one Technical Area will be deemed non-compliant and, as such, will NOT be reviewed or considered for selection. While proposers may submit proposals for all three TAs, proposers selected for any TA cannot be selected for any portion of the other two TAs, whether as a prime, subcontractor, or in any other capacity from an organizational to individual level. This is to avoid organizational conflict of interest (OCI) situations between the TAs and to ensure objective test and evaluation results. The decision as to which proposal to select for funding is at the discretion of the Government.

A. Background

Today, the ability to verifiably and securely establish communication between multiple security levels is inherently too complex to implement for many DoD platforms where such communication is desired. Furthermore, current practices are insufficient for the future growth in complexity of operational systems. System architects rely on several risk mitigation strategies including human fusion of data, diodes, and hypervisors to manage high risk transactions.

These strategies may be insufficient for future commercial and DoD needs. DARPA seeks to develop additional scalable strategies beyond the current examples below:

Human Fusion: Human fusion requires an operator to use multiple screens to visually ingest and fuse data to make intelligence-driven decisions. Although this approach manages risk by physically separating data at different security levels, human fusion is a slow and manual process, which does not allow for machine to machine engagement.

Diodes: Diodes leverage single interface guards to connect systems of systems. These systems typically require multiple racks of gear and either create single points of failure or excessive system complexity and duplications. Furthermore, the approval timeline to accredit these interfaces is between two and three years, as current DoD guidance requires that all multi-level interfaces (to include diodes) are sufficiently characterized to guarantee security properties. Additionally, when such systems are implemented, they introduce heavy overhead unless specifically tuned (at a high dollar and time cost) to a specific mission. Therefore, designing and implementing secure interfaces is a boutique industry. Diodes are often only used to connect large systems.

Hypervisors: Hypervisor software (attempts to) isolate software processes from one another. Hypervisors are susceptible to software and hardware vulnerabilities. There are over 100 documented common vulnerability exposures (CVEs) for hypervisors and hypervisors are rarely patched.1 Newly discovered classes of processor bugs (e.g.

Spectre/Meltdown) have brought attention to the fact that modern highly-optimized CPUs are poor at preventing cache memory leak conditions. Furthermore, numerous commercial hypervisor implementations rely on processor microcode security features (SGX, IPMI, TPM, UEFI) that are designed via the same development processes and

1 http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=hypervisor, 2018 include the same vulnerabilities as normal software. The hypervisor method of protection is commonly used in size, weight, and power (SWaP) constrained environments such as aircraft.

The program goal for GAPS is to develop hardware security and software architectures with provable security interfaces to physically isolate high risk transactions. GAPS will create secure hardware and software co-design tools that physically isolate high risk transactions during both system design and system build, and track that such protections are physically enforced at run-time. If a user wants to compute on sensitive data, the only true assurance is to physically track where the data is and guard all high-risk transactions.

The goal is for GAPS to reduce the inherent complexity through the development of hardware and software that will be open, extendible, and compatible with SWaP constrained environments to enable security across DoD and commercial systems. If GAPS research is successful, the barrier to safely enable these high-risk transactions will be substantially lowered, thus allowing for: a) fast computer to computer transactions as diodes can be built into the protocol itself; b) spatial isolation reducing the need for unreliable software partitioning solutions (e.g.

hypervisors); and c) more complex missions without putting sensitive data at risk.

In parallel, the commercialization of TA1 and TA2 technologies will enable system architects and designers to build in security properties, thus enabling safer systems with even more complex mission and system requirements. Thus, the existence of commercially available GAPS technology will also address growing needs for commercial systems to leverage, but also protect the private data of individuals.

B. Program Description

The GAPS program will research and develop methods for establishing and leveraging the physics primitives that can be trusted and assertions between microcircuits chips required for mission-critical applications. GAPS will then make these assertions available to software development systems such that when developers write applications, security properties outlined within source-code at development time will be enforced by physical properties during run-time.

GAPS focuses on software/hardware co-design to enable security of sensitive systems and data.

The GAPS research goal is to simplify labor for the developer and automatically determine how to generate the hardware to support the security requirements. Once the primitives are added into the design tools, those tools can be used to enforce the physical primitives during software builds. Today, best practices involve using separate networks and other methodologies (as described above) in an effort to ensure security, but these methods are not provably secure.

C. Program Structure

GAPS is divided into three technical areas (TAs), each consisting of three eighteen month phases. Evaluations will be held at the end of each phase. Between evaluations, the program will hold a series of collaboration events to allow performer teams to explore cross-team techniques and prepare for program evaluations.

While teams are required to submit software and hardware individually for evaluation, teams are also strongly encouraged to work with each other to build better systems through combined submissions during program evaluations. TA3 evaluations will largely be based on the ability of various teams’ effort to be integrated together into useful demonstrations. Therefore, it is imperative that teams keep open lines of communication (as supported by an Associate Contractor Agreement (ACA) as discussed in detail in Section III.D below). DARPA recognizes that success of the GAPS research effort depends in part upon the open exchange of information between the various Performers involved in the effort. As such all Performers will be required to sign an ACA. This ACA insures there will be appropriate coordination and integration of work by the Associate Contractors to achieve complete compatibility and to prevent unnecessary duplication of effort2. Please note additional details on the ACA in Part II(III)(D) below.

Program performance targets for each phase are detailed in Figure 3.

TA1: Components and Interfaces

GAPS TA1 will leverage high speed transceiver technology (e.g. SERDES), which is inherently unidirectional, to ensure security and prevent digital leakage. All transceiver communication passes through dedicated analog IP. This pathway ensures that it is resistant to tampering and thus difficult to change the communications. With this system implementation, every transaction that occurs in-system at higher layers of abstraction ultimately has to pass through the transceiver one-way gate. GAPS will leverage unidirectionality to ensure and validate security of the data.

By implementing physically provable directional data channels and re-conceptualizing how hardware security is managed, the end user will be able to implement pre-approved security methodologies in a rapid fashion.

TA2: Co-Design Tools

GAPS TA2 will research methods to extend programming languages to build correct-by-compilation multilevel security architectures. A particular focus for TA2 is to ensure that the user experience for designers leveraging GAPS is not negatively impacted. The functional underpinning of GAPS is hardware-based logic that adds multilevel security extensions to common embedded interfaces (MIL-STD1553B, Ethernet, PCIe, RapidIO, others) without changing the bus specification itself from what is already well-known and understood. However, in modern designs, it is the profession of software engineering that is expected to leverage commodity hardware (including the hardware’s interfaces) to develop and integrate the kinds of systems the organizations specify and purchase. Therefore, it is imperative that if the capability

2 As discussed in Section III.D. below, ACAs are agreements between performers established specifically for the purpose of ensuring the necessary exchange of information takes place so that the each party can successfully carry out the tasks delineated in their respective Statements of Work (SOW) and so that the overall program goals and objectives can be accomplished. ACAs are not intended to serve as Non-Disclosure Agreements, which are agreements between organization used to establish the control (handling/disclosure restrictions, marking requirements, etc.) of shared information – although it is acceptable that ACAs also include such terms and conditions. The Government is not a party (signatory) to an ACA; however, copies of ACAs must be provided to the Contracting Officer prior to contract award.

to extend modern interfaces to permit high risk transactions comes to pass, software engineers and developers need to be able to control and guide the resulting architecture that can perform those high risk transactions safely.

TA3: Integration and Validation

GAPS TA3 will act as the bridge between the fundamental security work and the organizational needs for these technologies. Thus, in a time of ever-increasing vulnerability identification in modern CPU architectures, TA3 will validate and demonstrate that segregation of software into physically separate level runtimes, meaning that CPU architecture vulnerabilities did not affect designs built under the GAPS architecture, and the system remains provably secure.

Additionally, TA3 will perform verification on data content to demonstrably prove the security of passing data from one classification level to another if all relevant GAPS prerequisites are met.

D. Technical Areas

GAPS contains three key Technical Areas:

TA1: Components and Interfaces TA2: Co-Design Tools TA3: Integration and Validation

All proposers are expected to support integration with performers in other technical areas. As an example, if Performer A is awarded TA1 and Performer B is awarded TA2, Performer A is expected to provide Performer B with the required data to support Performer B’s efforts.

TA1 Scope:

The role of TA1 is to research and develop a range of capabilities, including appropriate verifiable bus standards and board support packages (BSPs), around required components to enable missions and develop topologies that require minimal feedback while still maintaining high reliable throughput. This TA is complex, and will require a team with a wide range of skills needed to research and develop new circuit topologies that would allow conventional programmable hardware and SoCs to act as GAPS validators, diodes, encapsulators, and encrypt/decrypt interfaces.

Unidirectional validator circuits are a natural fit for the GAPS multilevel software security model. It is understood that not all busses can be made unidirectional and still remain effective.

Examples of this are PCIe and RapidIO, or any other interface that contains provisions for non-posted transactions that require a response. However, the core of modern chip-to-chip board-level interfaces is unidirectional electrical driver/transceiver/serialization circuitry that is physically unable to process data in the reverse direction.

GAPS TA1 will take advantage of known and finite electrical interfaces between integrated circuits (ICs). For example, simplex electrical interfaces can be selected to only pass data one way with no chance of spillage through transceivers, broadcast ports, or user datagram protocol

(UDP). GAPS will leverage these standards and rely on understood drivers and programming to enforce security at the hardware level. GAPS TA1 will define and build several basic components to be built on relevant busses, such as Ethernet, PCIe, CANbus, etc. These three components are diodes, validators, and interfaces that allow for encapsulated bi-directional communication. For the purposes of GAPS, diodes involve one-way throw circuitry that uses electrical interfaces similar to transceivers permitting one-way transfer of data only with no possibility of feedback. Validators are circuits that ensure data crossing diodes are appropriate for the bus interface and task, while interface encapsulators are built between two or more bidirectional endpoints and are mirrored in a way that data can be transported over single directional links.

One example of the use of a GAPS validator to allow bi-directional communication is below in Figure 1.

Figure 1. Bidirectional Bus Example

In the above example, the GAPS Validator hardware permits functionality that is difficult to realize otherwise:

1. Non-sensitive CPU A initiates a PCIe transaction to read from sensitive CPU B.

2. GAPS software extensions permit only non-sensitive memory range to be read from CPU B as only that data is sent across the interface monitored by the validator

3. The non-posted read transaction concludes, CPU A receives and displays non-sensitive data from the sensitive CPU B

It is expected that heavy use of purchased Intellectual Property (IP) will be made for interface circuity, control logic, and other hardware development requirements. Provision for source code is required for all IP. Additionally, a successful proposal will include a plan for licensing the IP in the event of transitioning to government or industry. The Government is willing to accept standard commercial data and/or licensing rights to such purchased IP.

In addition, GAPS (TA1) will research formal methods for verification at the behavioral design stage. This includes the use of duplex interfaces, which need to pass through standardized validator hardware blocks. For example, GAPS anticipates the use of Field Programmable Gate Arrays (FPGAs) to guarantee duplex data can pass and receive a response as required by the interface protocol used. In this way, a high-speed bidirectional interface appears as such to both endpoints and is mirrored in a way that it is transported over single directional links.

Programmable hardware such as FPGAs can be certified once and reused often, which minimizes program costs. Multilevel security implementation on FPGAs has already been approved by the National Security Agency (NSA) for Type I encryptors. Furthermore, NSA Fail Safe Design Assurance confirms that FPGA synthesis and implementation does not require additional formalism.3 ASICs were considered, but FPGAs are the superior choice for this application. A successful TA1 proposal would address both low speed and high speed usage cases, and also define mechanisms to inspect, intercept, and reroute interface bus data as directed by software drivers and TA2 instructions. Special care must be taken for those aspects of the interface bus protocol that require state tracking or session tracking.

Due to the demanding nature of modern chip to chip interfaces, it is vital that TA1 be implemented on a programmable hardware device that has the requisite capabilities, speed, and hardware resources, but also reliable market availability and sales maturity. As such, TA1 proposers are strongly encouraged to make use of existing Defense Supply Center Columbus (DSCC) listed programmable devices and FPGAs in the Xilinx Ultrascale+ logic family, including Zynq Ultrascale+ MPSoC devices that meet MIL-STD-883 environmental screening requirements, or justify why an alternative platform provides significant performance benefits that would be required to achieve program goals.

TA1 Performers are reminded that modern DoD systems feature both low-speed (e.g. MIL-STD- 1553B and ARINC-429) and high-speed (Serial RapidIO, PCIe, and 10/40/100G Ethernet) busses often times concurrently, and may require extensive standards-based IP support to properly function in concert with other bus devices. Furthermore, reliability and environmental standards of many DoD systems may require the use of up-screened ruggedized versions of the FPGA devices that may not be available from alternative manufacturers or sources.

An additional obligation of the TA1 Performer is to be responsive and mindful of size, weight, and power requirements as directed by TA3. The TA1 performer metrics as established by TA3 must be measureable and must enable trade-off decisions with respect to other circuit parameters such as performance, power, and area. Hardware, BSPs, and drivers developed by TA1 are intended to be operationalized and are expected to be SWaP-compliant with realistic mission requirements as directed by TA3.

A successful TA1 proposal need not exclusively describe research to be carried out on protocol diodes, validators, or protocol encapsulators. The Government is interested in any technology that can be integrated with existing electrical interfaces under SWaP constraints and can provide security assurances when carrying out high risk data transfer.

TA1 proposals to create new or implement Physically Unclonable Functions (PUFs) are not in scope.

Proposal responses to TA1 should be unclassified.

TA1 Research Responsibilities

It is anticipated that TA1 performers will be responsible for the following:

Interfacing - identifying methods to adapt native protocols for unidirectionality while ensuring performance (e.g. speed and reliability) are not degraded.

3 http://mil-embedded.com/pdfs/NSA.Mar07.pdf

IP Development – create or adapt IP for board level interfaces that inspect, filter, validate, and retransmit transactions, as well as maintain all necessary communication states using COTS FPGA and CPU microcircuits.

BSP Development – expose APIs and software drivers to allow TA2 software to operate TA1 circuitry, with a focus on minimizing changes to existing driver code for the board level interfaces used.

Cooperation with TA2 and TA3 – Provide methods and support for integration of IP, circuitry, and BSPs that conform to TA3 ICDs, and can be targeted with TA2 software.

Integration – Plan and facilitate how TA2 and TA3 capabilities will be applied to interface control and validation circuitry.

Compilation Response – following TA2 direction to generate hardware that incorporates physical and electrical isolation sufficient to meet mission requirements. This permits TA2-level compilation to drive hardware and IP selection needed to build a GAPS-compliant mission module.

TA2 Scope

Prior work has shown some promise in the area of secure program partitioning during program compilation; however, current state of the art still requires full-duplex interfaces between all hosts. As such, TA2 performers will need to research and develop high-level languages capable of expressing unidirectional data-flow assertions and transactions as well as develop novel modelling and compilation techniques to produce physical layouts and multiple binaries.

TA2 will focus on leveraging languages with strong concurrency and multiprocessing support inherently supporting unidirectional transactions. Modern languages such as Go have created language primitives to support concurrency and make multi-processing part of the language. For example, channels in Go are excellent research candidates for expansion to take advantage of underlying unidirectional transceiver links. Wherever possible, TA2 will leverage pre-existing features of programming languages (e.g. modify Go channels) to incorporate GAPS extensions.

An example of a research challenge TA2 would need to overcome is the need to modify compiler behavior in languages that allow passing data or objects by reference (e.g. pointers) in those situations where the pointer structure comprises the high risk transaction GAPS is controlling. In this case, further work would need to be done in TA2 to handle cases of null pointers and adding static analysis for containers such as arrays (which lack compile-time bounds checking in some languages) passing through GAPS-compliant interfaces. A successful TA2 proposal would describe how existing language grammar and data structures would be modified for GAPS use.

A successful TA2 proposal at a minimum must target a language suitable for integration with low-level drivers and board support packages (e.g. C/C++) in order to be compatible with TA1.

In addition to such basic support, TA2 proposals should target modern 4th/5th generation languages, specifically those relevant to multi-processing. For TA2 solutions preprocessor/parser directives and compiler modifications will need to be made to enable the same features of directing data to unidirectional transactions carried out by TA1 hardware. In all cases, the TA2 proposal needs to demonstrate how language extensions will create a set of developer tools that are capable of understanding the topology of data transactions by ensuring that only appropriate

CPUs execute the specific security level software that is permitted. TA2 tools will also ensure that data transfers between CPUs of varying security levels go through TA1 board hardware and chip-to-chip interfaces designed for this purpose. The TA2 proposal would need to both demonstrate how GAPS extensions would be added to these languages while also demonstrating a clear understanding of the differences between binary/object code generation for legacy C/C++ and more modern languages. Identical GAPS feature sets would need to be supported for all languages described in the TA2 proposal.

Additionally, TA2 proposals need to describe how directives or other lexical features in software would be used to direct the toolchain to split compiled output into multiple concurrent binaries that each target different individual microprocessors. All requisite inter-processor communication (IPC) for supporting this distributed processing scheme needs to be inferred from the original source code. Taint analysis would need to be performed by TA2 tooling to identify the multiple security levels involved, as well as create a high-level requirement list of hardware (CPUs, validators, diodes, encryptors, and any other TA1 circuitry) needed to securely execute the user program.

Proposal responses to TA2 should be unclassified.

TA2 Research Responsibilities

It is anticipated that TA2 performers will be responsible for the following:

Coverage - full language coverage to permit unrestricted use of the programming language in question after GAPS language extensions are inserted.

Accuracy - unchanged accuracy of build products from compilation for any source code containing GAPS extensions.

Cooperation with TA1 and TA3 - provide methods and support for integration of drivers, directives, and BSPs that conform to TA3 ICDs, and can be translated into interface bus messages that pass through TA1 hardware.

Application compilation – build time errors if physical architecture does not support security features found during static analysis. Static analysis will perform automated verification of physical and electrical isolation sufficient to meet mission requirements.

TA3 Scope

GAPS TA3 will create a framework for emerging needs for DoD systems and act as the bridge to DoD requirements for the TA1 and TA2 technologies. As part of each Phase, GAPS will demonstrate these technologies’ utility on active or developmental commercial and/or DoD platforms. Thus, in a time of ever-increasing vulnerability identification in modern CPU architectures, TA3 will demonstrate segregation of software into physically separate level runtimes. Hence, CPU architecture vulnerabilities do not affect designs built under the GAPS architecture. It is expected that the TA3 Performer will have completed necessary diligence in validating the considered approaches, such as simulations, assumptions, and risks/mitigation strategies for successfully completing all three phases of the program. For the DoD, this means that future systems and system updates can be trusted after design, eliminating multi-year accreditation and security analysis requirements. The resulting TA3 work product will contain a usable and certifiable physical product that permits multilevel security data transfer in an actual deployed or deployable DoD or commercial system.

An additional purpose for the TA3 demonstration work is to act as proving ground for the certification process to enable GAPS-compliant systems to be accredited by design. As such, accreditation for new DoD multilevel security systems can be obtained at time of compilation, with TA3 demonstrations acting as examples of such efforts. In this way, TA3 demonstration work strengthens the generalized unclassified open standards defined by TA1 and TA2 and enables GAPS-compatible designs to be built by both Government and industry for both DoD and commercial purposes, resulting in significantly shorter accreditation times, faster system fielding, reduction in cost, and enhanced system security.

Competitive proposals should discuss in detail specifically where to integrate GAPS hardware and software. TA3 proposers are encouraged to identify and employ their access to DoD platforms to ensure integration begins at the start of the program. TA3 teams will be evaluated on the breadth of access they can provide. TA3 allows proposers a wide degree of latitude in methods that perform management and integration, but will work closely with the Government team and DoD transition partners to ensure a successful integration. As part of each Phase, GAPS will demonstrate these technologies’ utility on active DoD platforms.

A successful TA3 proposal will feature at a minimum one transition target that would benefit from GAPS technology infusion. TA3 proposals can be classified up to the TS//SCI//SAP level.

All TA3 Principal Investigators (PIs) must have an active TS//SCI clearance and be eligible for SAP access.

TA3 Research Responsibilities

TA3 Proposers will have demonstrated experienced in conducting experiments and evaluations in the areas of (a) DoD integration, (b) agile engineering and development,

(c) open system architecture assessments and (d) the development of data security frameworks.

Performers will focus on integration of the research and development and provide a clear transition path for the technologies, both within DoD and commercial systems.

The TA3 team will conduct reviews to iteratively validate the security, effectiveness, and processes used by the TA1 and TA2 Performers to ensure a robust and operationally relevant system capability is developed by program completion. Successful TA3 proposers will recognize the challenges associated with integrating and securing both hardware and software co-design and provide evidence of their experience working with both programmatic aspects.

The TA3 performer is expected to study the impact of GAPS technology insertion into the system being modified. The TA3 performer will identify draft performance metrics to be met by TA1 and will submit these metrics for Government review and approval.

Successful TA3 proposals need to describe how validation of security assertions given in TA1 and TA2 will be performed. The Government is willing to accept both traditional validation and formal verification methodologies. Strategies for generating test data, model/IP checking, and automated theorem proving need to be described in a successful TA3 proposal.

TA3 Proposers will create a framework applicable to emerging needs for future DoD systems.

Proposals are encouraged to consider and/or leverage experimental solutions that account for logistical and SWaP challenges of DoD systems to better highlight novel insights and their impacts on SWaP constrained environments.

Throughout the program, the TA3 Performer will outline each demonstration by DARPA and its Government Team and/or Service partners. Demonstrations of integrated GAPS capabilities, including the development and execution via advanced languages and interfaces, are expected to utilize the hardware platforms as proposed by TA1.

Demonstrations should make use of state-of-the-art technologies and languages as developed by TA2. The TA3 performer is also responsible for delivering draft ICDs and specification for Government review and approval.

The TA3 goal is to facilitate a direct engagement between warfighters and technologists to generate operationally relevant capabilities to defend DoD systems. Hence, GAPS must be integrated and demonstrated every 18 months at DARPA or DoD designated test sites. The intent of these events is to iteratively demonstrate and deliver minimum viable products. It is more important to the Government to provide integrated functional capabilities, albeit incremental, at each demonstration and interim integration milestones, rather than to present non-working component features. The goal is to deliver potential frequent technology off-ramps, which could manifest in the form of integration in ongoing warfighter assessment exercises, spin-off technology transition efforts, and/or Service-led developmental testing and evaluation activities.

E. Schedule/Milestones

Figure 2. Schedule/Milestones

Figure 3. Program Metrics

F. Deliverables

TA1 Deliverables:

The Government anticipates receiving the following deliverables throughout the program:

Technical Papers: Any technical papers covering work funded by GAPS.

Source Code: Full and complete source code, any other necessary data, and documentation (including at a minimum a user manual and a detailed software design document) including, but not limited to, schematics, layouts, board wiring diagrams, and circuit board products for all hardware developed under this program.

Demonstration Boards: Modular and socketable components and accompanying demonstration boards to allow for the development and evaluation of GAPS circuitry for application development as part of a larger Driver Development Kit (DDK). Direction for GAPS-relevant electrical bus interfaces will be provided by the Government team.

Monthly Progress Reports: Monthly reports should detail the technical and programmatic accomplishments for the previous month, as well as the plans for the next sixty days. The reports should also include major risks, planned activities, trip summaries, changes to key personnel, and any potential issues or problem areas that require the attention of the Government Team. Additionally, the monthly report should provide financial status of the program to include current month’s financials, program to date financials, and planned financials for the remainder of the program. These reports must be provided within 15 days after the end of each month.

Final Report: A final report should be submitted which summarizes the effort conducted and provide any lessons learned during the development of the GAPS technology program.

TA2 Deliverables:

The Government anticipates receiving the following deliverables from TA2 performers throughout the program:

Technical Papers: Any technical papers covering work funded by GAPS.

Source Code: Full and complete source code, any other necessary data, and documentation (including at a minimum a user manual and a detailed software design document) for all software developed under this program. Code releases will be provided to the TA3 Performer at least every two months, to include all source code, build scripts, test harnesses, development environments, unit tests and system tests.

TA2 Performers will provide a report no later than week 9 after the start of each phase.

This report will define the metrics for testing and evaluation and discussing a concept of operations for conducting evaluations of any software that requires user interaction. This report will be produced in collaboration with TA3.

Monthly Progress Reports: Monthly reports should detail the technical and programmatic accomplishments for the previous month, as well as the plans for the next sixty days. The reports should also include major risks, planned activities, trip summaries, changes to key personnel, and any potential issues or problem areas that require the attention of the Government Team. Additionally, the monthly report should provide financial status of the program to include current month’s financials, program to date financials, and planned financials for the remainder of the program. These reports must be provided within 15 days after the end of each month.

Final Report: A final report should be submitted which summarizes the effort conducted and provide any lessons learned during the development of the GAPS technology program.

TA3 Deliverables:

The Government anticipates receiving the following deliverables from TA3 performers throughout the program:

Hardware Validation: In coordination with transition partners, TA3 performers will develop methodologies and metrics by which to measure the security partitioning of hardware developed by the TA1 performers. Specifically, TA3 teams must develop quantitative metrics required to evaluate trade-offs in security, performance, power, area and other standard metrics. In addition, TA3 teams must establish a framework that enables representation of hardware security properties to system designers and architects.

These deliverables (methodologies, metrics, and frameworks) are due at the beginning of each Phase. The TA3 contract will start prior to the TA1 and TA2 contracts in order to provide the TA3 Performer with the time to develop the requirements. TA3 teams will also be expected to monitor development progress of TA1 hardware through version control access and provide status to the Government.

Software Validation: In coordination with transition partners, TA3 performers will develop methodologies and metrics by which to measure the security partitioning of software developed by the TA2 performers. Specifically, TA3 teams must develop quantitative metrics required to evaluate trade-offs in security, performance, power, and other standard metrics. In addition, TA3 teams must establish a framework that enables representation of software security properties to system designers and architects. These deliverables (methodologies, metrics and frameworks) are due at the beginning of each Phase. The TA3 contract will start prior to the TA1 and TA2 contracts in order to provide the TA3 Performers with the time to develop the requirements. TA3 teams will also be expected to monitor development progress of TA2 software through version control access and provide status to the Government.

Architecture Design Document: Design documentation for each phase shall be presented within one month after the kick off meeting for that phase. The architecture documentation shall describe the system in sufficient detail to permit an engineer to correctly implement the system without consulting the system designer. The algorithm documentation shall describe the algorithms in sufficient detail to permit a software engineer to correctly code the algorithms without consulting the algorithm designer.

Hardware and Documentation: At the conclusion of each demonstration, the complete prototype system hardware shall be delivered. The delivered system shall be the same fully functional system used to perform the final capability demonstration. The delivery is to include sufficient documentation, so as to be completely operable, maintainable, and modifiable with no reliance on any nondelivered hardware/documentation developed or procured under the GAPS program.

Software, Development Kit, and Documentation: All computer software developed and delivered under the GAPS program must be delivered as source and as object (executable) code. All deliverables are due one (1) week prior to demonstration for the phase. Include the source listings and source code for the target computer systems.

Delivered software under this effort is to be completely maintainable and modifiable with no reliance on any non-delivered computer programs or documentation. For all computer software purchased or licensed for use as a component of the software to be delivered, arrangements shall be made for licensing and maintenance agreements to be transferred to the Government upon the completion of the performer’s work under any contract awarded under this BAA.