HR001117S0023.pdf

HR001117S0023

Microsystems Technology Office Broad Agency Announcement

System Security Integrated Through Hardware and firmware

(SSITH)

HR001117S0023

April 19, 2017

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

1. Technical Area 1: Novel hardware security architectures and design tool development

2. Technical Area 2: Security Evaluation Methodologies and Metrics E. Program Schedule F. Deliverables Table 4.1. TA-1 Deliverables by Phase G. Government Furnished Property/Information

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

2. Non-U.S. Organizations and/or Individuals B. Organizational Conflicts of Interest C. Cost Sharing/Matching D. Other Eligibility Criteria

1. Collaborative Efforts

2. Ability to Receive Awards in Multiple Technical Areas – Conflicts of Interest

(COIs) E. Associate Contractor Agreement Clause

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

1. Full Proposal Format

2. Proprietary Information

3. Security Information

a. Unclassified Submissions

b. Classified Submissions

4. 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. Full Proposal Date

b. Frequently Asked Questions (FAQ)

2. Proposal Submission Information

a. For Proposers Requesting Contracts or Other Transaction Agreements

b. Classified Submission Information

3. 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. Plans and Capability to Accomplish Technology Transition

4. Proposer’s Capabilities and/or Related Experience

5. Realism of Proposed Costs and Schedule

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. 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

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 ATTACHMENT 3: CWE Hardware Vulnerability Glossary

PART I: OVERVIEW INFORMATION

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

Funding Opportunity Title: System Security Integrated Through Hardware and firmware (SSITH)

Announcement Type: Initial Announcement Funding Opportunity Number: HR001117S0023 Catalog of Federal Domestic Assistance Numbers (CFDA): Not applicable Dates: (All times listed herein are Eastern Time) o Posting Date: April 19, 2017 o Proposers Day: April 21, 2017 o FAQ Submission Deadline: May 22, 2017 at 1:00 PM o Proposal Due Date: June 5, 2017 at 1:00 PM o Estimated period of performance start: November 2017

Concise description of the funding opportunity: The overall goal of the SSITH program is to develop hardware design tools to provide inherent security against hardware vulnerabilities that are exploited through software in DoD and commercial electronic systems. SSITH aims to drive research required to develop secure hardware that constrains the hardware attack surface and protects against classes of software attacks which exploit hardware vulnerabilities.

Anticipated Funding Available for Award: Approximately $50M Anticipated individual awards: Multiple awards are anticipated.

Anticipated funding type: 6.2 Types of instruments that may be awarded: Procurement contract or other transaction Agency contact:

Dr. Linton Salmon, Program Manager BAA Coordinator: HR001117S0023@darpa.mil

DARPA/MTO

ATTN: HR001117S0023

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/. The following information is for those wishing to respond to the BAA.

The Microsystems Technology Office at DARPA seeks innovative proposals in hardware advances that protect commercial and DoD electronic systems from software-assisted attacks on hardware vulnerabilities. Proposed research should investigate innovative approaches that enable revolutionary advances in science, devices, or systems. Specifically excluded is research that primarily results in evolutionary improvements to the existing state of practice.

A. Background

Electronic system security has become an increasingly critical area of concern for the DoD and the broader U.S. population. Current efforts to provide electronic security largely rely on robust software development and integration. Software security development environments, methodologies, and verification have been extensively analyzed and documented; however, current security measures remain inadequate. Present responses to hardware vulnerability attacks typically consist of developing and deploying patches to the software firewall without addressing the underlying hardware vulnerability. As a result, while a specific attack or vulnerability instance is defeated, creative programmers can develop new methods to exploit software access to the remaining hardware vulnerability and a continuous cycle of exploitation, patching, and subsequent exploitations ensues. A new approach is necessary to break this cycle of hardware vulnerability exploitation.

The System Security Integrated Through Hardware and firmware (SSITH) program addresses the use of hardware security architectures to help protect systems against classes of hardware vulnerabilities, rather than focusing on single instances of software weaknesses that exploit those vulnerabilities. There are seven known classes of hardware vulnerabilities listed in the Common Weakness Enumeration (CWE) list 1: permissions and privileges, buffer errors, resource management, information leakage, numeric errors, crypto errors, and code injection. Changes to the integrated circuit architecture could provide hardware protection against vulnerability instances by addressing the vulnerability classes at their source, the hardware.

Reference: [1] The Common Weakness Enumeration List (CWE), cwe.mitre.org http://www.fbo.gov/

B. Program Description

The goal of the SSITH program is to develop hardware design tools that provide security against hardware vulnerabilities that are exploited through software in DoD and commercial electronic systems. SSITH seeks to leverage current research in hardware design and software security to propel new research in the area of hardware security at the microarchitecture level. Security approaches will limit the permitted hardware to states that are assured to be secure while maintaining the performance and power required for system operation.

SSITH will develop architectures and design tools that enable system-on-chip (SoC) designers to safeguard hardware against all seven (7) known CWE classes of hardware vulnerabilities that can be exploited through software. A summary of these CWE classes is included in Attachment

3. SSITH aims to drive research required to develop secure hardware that constrains the hardware attack surface and protects against classes of software attacks which exploit hardware vulnerabilities. Development and demonstration of design tools will greatly facilitate wide use of SSITH security concepts. It is expected that architectures and design tools developed through this program will provide robust and flexible solutions applicable to both DoD and commercial electronic systems.

SSITH encourages proposals that utilize security concepts to drive development of security architectures and design tools. Listed below are examples of a few of the security concepts that may be incorporated in a security architecture.

Cryptography Metadata tagging Formal verification Verified state matching Anomalous state detection Secure multi-party computing Semi-homomorphic computing Security through compartmentalization

SSITH will drive demonstration and evaluation of selected security architectures through red team evaluation and comparison to security metrics. Security architectures will be instantiated in custom hardware to demonstrate the security of the resulting systems as well as to evaluate the impact of securitization on the performance, power, area, software compatibility, and security (PPAS) of resulting systems.

SSITH security architectures are intended to be capable of being implemented in such a way that existing application software can be run on securitized hardware without software modification.

It is expected that some software modification may be required to fully exploit hardware security features, but security should be maximized for unmodified software and software modification required to fully exploit SSITH security features should be minimized. This capability may be achieved through an intermediate firmware layer, but use of the intermediate firmware is intended to be transparent to the application software programmer.

In addition to the PPAS impact, SSITH will also evaluate the scalability, flexibility, and adaptability of the security architectures developed in the program. Scalability will be needed to apply across a broad range of applications from small, ultra-low power systems to large, high-performance systems. Flexibility will be needed to ensure responsiveness of hardware security to evolving system threats. Adaptability will allow hardware systems to respond to detected attacks.

Out of Scope Technical Areas The SSITH BAA will not focus on attacks that are not mediated through software access to the hardware. Although other areas of security are important, SSITH will focus on hardware vulnerabilities that are exploited through software to define achievable goals in a limited, but critical, part of the overall cybersecurity enterprise. Examples of out of scope topics are:

1. Development of physical elements of hardware security such as Physically Unclonable Functions (PUF) and Random Number Generators (RNG). Physical elements can be used as a part of a SSITH proposal, but SSITH will not fund their development.

2. Protection against hardware-only vulnerabilities such as EM side-channel attacks or insertion of hardware Trojans during design and/or fabrication.

3. Vulnerabilities that occur exclusively in the software domain, such as insecure interaction between software components or cross-site request forgeries.

C. Program Structure

This BAA addresses the challenges to develop hardware security architectures that are scalable, flexible, and adaptable. DARPA seeks proposals that demonstrate how these attributes are enabled through integrated circuit security design architectures and design tools. The goal of enabling scalable, flexible, and adaptable designs within design tool frameworks will be pursued concurrently in two Technical Areas across three phases with a total program period of performance of 39 months.

D. Technical Areas

This SSITH BAA is soliciting proposals in two technical areas:

Technical Area 1 (TA-1) will develop scalable, flexible, and adaptable integrated circuit security architectures that can be easily implemented in DoD and commercial SoCs.

Technical Area 2 (TA-2) will establish a methodology for evaluating the security provided by the architectures developed in TA-1.

Individual proposals shall address only one of the two technical areas; organizations wishing to propose to both technical areas must submit a separate proposal for each.

1. Technical Area 1: Novel hardware security architectures and design tool development

The focus of TA-1 is new hardware security approaches and architectures that will be used by DoD and commercial SoC designers to protect electronic systems against external software-assisted attacks. TA-1 is comprised of three key elements, 1) tasks, 2) characteristics, and 3) metrics, all of which are intended to be clearly represented and demonstrated throughout the program. Successful TA-1 proposers will illustrate the interdependency and evolution of key elements within each phase.

TA-1 Key elements:

1. Tasks:

a. Security Architectures: develop and demonstrate one or more security architectures that can be used to protect electronics systems from software-assisted attacks that exploit the 7 CWE hardware vulnerability classes. TA-1 teams are requested to show how the security architecture will secure designs, and how it would be implemented.

b. Design Tool Development: develop design tools required to implement the chosen security architectures in arbitrary circuit designs. The design tools may include methods or techniques which utilize new EDA software developments and/or modifications to existing EDA software that enable other design teams to utilize the security architecture to secure future circuit designs. Proposals should include details about how the design tools developed in TA-1 would insert security at the hardware level into circuit elements, circuit blocks and hardware architectures.

c. Impact of security implementation: evaluate the impact of the security architecture implementation on key circuit metrics as described in section 3, and demonstrate the impact on circuit metrics through simulation and custom circuit emulation.

**Note: Please refer to Table 2 for specific TA-1 tasks by phase.

2. Characteristics:

a. Scalability: demonstrate that implementation of the security architecture enables scaling of security across a wide range of system parameters, such as power, performance, and complexity. Demonstrate that scalability will enable use of security architectures across a wide range of applications (small to large).

b. Flexibility: demonstrate that the selected security architecture can be used to upgrade hardware to protect against newly found vulnerabilities without requiring redesign of the hardware.

c. Adaptability: demonstrate that the selected security architecture can adapt system characteristics to respond to detected known attacks on the electronic system without reprogramming or firmware modification. Demonstrations will show the ability of the architecture to detect and adaptively respond to classes of attacks in an appropriate manner. For example, the security architecture could detect a request for inappropriate permission access through an IO by lowering the IO transfer rate and restricting data exchange to known safe pathways.

3. Metrics:

a. Security: demonstrate that selected security architectures effectively secure electronic systems against attacks on all seven (7) CWE hardware vulnerability classes described in Appendix 3. TA-1 teams are requested to address

i. a theoretical evaluation of protection;

ii. evaluation of the protection architecture against security metrics established by TA-2 performers; and

iii. resistance of the security architecture against a ‘red team’ attack on the architecture as instantiated in hardware.

b. Performance at power: accurately quantify the impact of implementing security on key circuit parameters such as circuit performance, power, robustness, and reliability. TA-1 teams are requested to demonstrate the ability to trade-off these parameters against each other and with respect to metrics a (security) and c (area/complexity).

c. Area/complexity: accurately quantify the impact of implementing security on circuit area and on design complexity. TA-1 teams are requested to demonstrate the ability to trade-off these parameters against each other and with respect to metrics a (security) and b (performance at power).

d. Software compatibility: ensure that existing application software will run on hardware secured with SSITH and minimize the amount of software modifications required to implement all of the SSITH security features.

*Note: Please refer to Table 2 for quantitative TA-1 metrics by phase.

Table 1. TA-1 Tasks by Phase

Phase 1 Phase 2 Phase 3

Security architectures

1. Prove feasibility of security architectures that provide protection against the seven CWE classes of hardware vulnerabilities.

Security architectures

1. Implement security architectures in circuit designs.

Security architectures

1. Implement security architectures in circuit designs.

Design tool development

2. Develop alpha* design tools that implement security architectures.

Design tool development

2. Develop beta ** design tools that implement security architectures.

3. Implement security architectures on the three GFE-provided FPGA designs using design tools.

Design tool development

2. Develop distribution*** design tools to implement security architectures.

3. Implement a second version of the security architectures on the three GFE-provided FPGA designs using design tools.

Impact of security on metrics

3. Establish, by simulation, impact of security architectures on PPASS:

• Power/performance

• Design area/complexity

• Security

• Software compatibility

Impact of security on metrics

4. Establish by simulation and FPGA demo, impact of security architecture on

PPASS.

5. Support implementation of security architectures.

Impact of security on metrics

4. Establish, by and simulation and FPGA demo, impact of security architecture on PPASS.

5. Support implementation of security architectures .

* Alpha: Usable by the developing team ** Beta: Usable by other design teams with significant interaction with the developing team *** Distribution: Sufficiently robust and documented for use by other design teams without support of the developing team

Table 2. TA-1 Metrics by Phase

Phase 1 Phase 2 Phase 3

1. Provide 100% protection against at least three (3) CWE (reference) classes of the defined hardware vulnerabilities exploited by software attacks.

1. Provide 100% protection against at least five (5) CWE (reference) classes of the defined hardware vulnerabilities exploited by software attacks.

1. Provide 100% protection against all seven (7) CWE (reference) classes of the defined hardware vulnerabilities exploited by software attacks.

2. Prove security protection against the three (3) CWE classes through use of simulation and theoretical justification derived from performer-selected design.

2. Prove security protection against the five (5) CWE classes through red-team attack on the first pass FPGA instantiation of the three Government-provided GFE processor designs.

2. Prove security protection against the seven (7) CWE classes through red-team attack on the second pass FPGA instantiation of the three Government-provided GFE processor designs.

3. Provide quantitative simulation data indicating that improvement on system power, performance, and area (PPA) overhead meets Phase 1 metrics while maintaining software compatibility:

-Performance impact < 20% -Power impact = 0% -Area impact < 50%

3. Provide quantitative simulation and FPGA data indicating that improvement on system power, performance, and area (PPA) overhead meets Phase 2 metrics while maintaining software compatibility:

-Performance impact < 15% -Power impact = 0% -Area impact < 40%

3. Provide quantitative simulation and FPGA data indicating that improvement on system power, performance, and area (PPA) overhead meets Phase 3 metrics while maintaining software compatibility:

-Performance impact < 10% -Power impact = 0% -Area impact < 30%

4. Provide theoretical or empirical evidence of the ability to respond to new hardware vulnerabilities without modifying hardware.

4. Demonstrate the ability to respond to new hardware vulnerabilities without modifying FPGA hardware.

4. Demonstrate the ability to respond to new hardware vulnerabilities without modifying FPGA hardware.

2. Technical Area 2: Security Evaluation Methodologies and Metrics

The focus of TA-2 is to develop a methodology and metrics by which to measure secure electronic systems. Specifically, TA-2 teams are intended to develop quantitative metrics required to evaluate trade-offs in security, performance, power, area and other standard circuit metrics. In addition, TA-2 teams are intended to establish a framework that enables representation of hardware/firmware security properties to overall system designers.

***Note: Please refer to Table 3 for specific TA-2 tasks by phase.

TA-2 is comprised of two key tasks that will evolve across the three phases of the program:

1. Definition of quantitative security metrics for hardware security: These metrics are intended to be measureable and enable trade-off decisions with respect to other circuit parameters such as performance, power, and area. The metrics are intended to correlate with both the attack vector (e.g., software, IO port) and the protection surface (e.g., software intrusion, IO intrusion).

2. Establishment of a framework for hardware/firmware security: This framework will permit overall evaluation of system security. The framework is intended to have a theoretical and/or empirical foundation and enable a common basis on which to communicate and evaluate security properties.

Table 3. TA-2 Tasks by Phase

Phase 1 Phase 2 Phase 3

1. Define initial quantitative metrics for the hardware/firmware security and coordinate use of these metrics to evaluate TA-1 performers.

1. Finalize the security metrics and support their use to drive engineering tradeoffs in the first version of the FPGA designs.

1. Formalize security metrics and support their use to drive engineering tradeoffs in the second version of the FPGA designs.

2. Establish an initial theoretical security representation framework.

2. Refine the security representation framework established in Phase 1 and support use of the framework by TA-1 teams to represent their hardware security architectures.

2. Collaborate with TA-1 design teams to represent their security properties in the established security representation framework.

E. Program Schedule

The SSITH program schedule comprises a 15-month base period (Phase 1) followed by two 12-month periods (Phases 2 and 3 respectively), for a total of 39 months, subject to the availability of funds.

Phase 1: Base Period (15 months) TA-1: Demonstrate, through simulation, implementation of selected security architectures in integrated circuit designs to protect against three (3) of the seven (7) CWE hardware vulnerability classes, in compliance with Table 1: buffer errors, permissions/privileges, and information leakage. The demonstration circuit(s) will be chosen by performers to represent a broad range of DoD and/or commercial applications. TA-1 teams will develop alpha-level design tools to implement the security architectures and demonstrate use of those design tools to implement the security architectures. Finally, in Phase 1, TA-1 teams will quantify the tradeoffs between security as implemented by their security architecture, and key circuit parameters such as performance, power, area, software compatibility, and complexity.

TA-2: Establish an initial set of quantitative metrics and coordinate use of the initial metrics to evaluate the results of TA-1 performers. TA-2 teams are expected to work with TA-1 performers to refine the metrics and facilitate the application of the metrics to TA-1 security architectures.

TA-2 teams will also establish an initial theoretical framework for security representation.

Phase 2: Option 1 (12 months) TA-1: Demonstrate, through implementation in an FPGA platform the ability of selected security architectures to protect against five (5) of the seven (7) CWE hardware vulnerability classes, in compliance with Table 1: buffer errors, permissions/privileges, information leakage, resource management, and crypto errors. Demonstration circuits will include three government-provided RISC-V processor designs spanning from a low-end to a high-end processor design. TA-1 teams will develop beta-level design tools to implement the security architectures, and demonstrate use of those design tools to implement security architectures on a FPGA platform. Using simulation and the FPGA platform, TA-1 teams will quantify trade-offs between security (as implemented by their security architecture), and key circuit parameters, such as performance, power, area, software compatibility, and complexity. Finally, TA-1 teams will establish an initial hardware representation of the selected security architecture based on a security representation framework defined by TA-2.

TA-2: Finalize quantitative metrics to be used by TA-1 design teams as engineering parameters to drive appropriate tradeoffs in circuit design. The final set of security metrics from this phase will be used to evaluate program results. Finally, TA-2 teams will refine the initial security representation framework and collaborate with TA-1 performers to represent TA-1 security architectures in the security representation framework.

Phase 3: Option 2 (12 months) TA-1: Demonstrate, through implementation in a second version of the FPGA designs, the ability of selected security architectures to protect against all seven (7) of the CWE hardware vulnerability classes, in compliance with Table 1. The demonstration circuits will include three

(3) government-provided RISC-V processor designs spanning from a low-end to a high-end processor design. TA-1 teams will develop production-level design tools to implement the security architectures and demonstrate use of those design tools to implement their security architectures. Using simulation and the second version of the FPGA designs , TA-1 teams will quantify the trade-offs between security as implemented by their security architecture, and key circuit parameters such as performance, power, area, software compatibility, and complexity.

Finally, TA-1 teams will establish a final hardware representation of the selected security architecture based on the security representation framework defined by TA-2.

TA-2: Formalize security metrics, continue to support use of these metrics by TA-1 design teams, and disseminate the security metrics to the broader security community.

F. Deliverables

Table 4.1. TA-1 Deliverables by Phase

Phase 1 Phase 2 Phase 3

1. Simulation data indicating the impact of security architectures on circuit performance, power, area, software compatibility, and design complexity.

1. Simulation and first version FPGA data indicating the impact of security architectures on circuit performance, power, area, software compatibility, and design complexity.

1. Simulation and second version FPGA data indicating the impact of security architectures on circuit performance, power, area, software compatibility, and design complexity.

2. Alpha-level design tools that implement selected security architectures.

2. Beta-level design tools that implement selected security architectures.

2. Production-level design tools that implement selected security architectures.

3. Quarterly and end of phase technical reports and monthly financial reports.

3. First pass bitstream and RTL descriptions of the GFE-provided designs that include implementation of the selected security architecture(s).

3. Final bitstream and RTL descriptions of the GFE-provided designs that include implementation of the selected security architecture(s).

4. Quarterly and end of phase technical reports and monthly financial reports.

4. Quarterly and end of program technical reports and monthly financial reports.

Table 4.2. TA-2 Deliverables by Phase

Phase 1 Phase 2 Phase 3

1. Initial set of quantitative metrics. 1. Final set of quantitative metrics. 1. Quarterly and end of phase technical reports and monthly financial reports.

2. Initial security representation framework.

2. Final security representation framework.

3. Quarterly and end of phase technical reports and monthly financial reports.

3. Quarterly and end of phase technical reports and monthly financial reports.

G. Government Furnished Property/Information

Proposers to TA-1 may expect the following government furnished property to be made available at the beginning of Phase 2:

1. An FPGA board with IOs and 2X the capacity required to implement the most complex RISC-V baseline circuit. The FPGA board will be mounted in a chassis containing the FPGA board and accessible IOs.

2. RTL and FPGA bitstream for three different sizes of RISC-V processor designs:

a. A small, reduced-feature version of the Rocket processor,

b. A full-featured, single threaded version of the Rocket processor, and

c. A full-featured, multi-threaded, out of order execution RISC-V processor.

3. Versions of an Operating System that can be run on each of the three processors.

II. Award Information

A. General Award Information

Multiple awards are anticipated. The amount of resources made available under this BAA will depend on the quality of the proposals received and the availability of funds.

The Government reserves the right to select for negotiation all, some, one, or none of the proposals received in response to this solicitation, and to make awards without discussions with proposers. The Government also reserves the right to conduct discussions if it is later determined to be necessary. If warranted, portions of resulting awards may be segregated into pre-priced options. Additionally, DARPA reserves the right to accept proposals in their entirety or to select only portions of proposals for award. In the event that DARPA desires to award only portions of a proposal, negotiations may be opened with that proposer. The Government reserves the right to fund proposals in phases with options for continued work at the end of one or more of the phases, as applicable.

Awards under this BAA will be made to proposers on the basis of the evaluation criteria listed below (see section labeled “Application Review Information,” Sec. V.), and program balance to provide overall value to the Government. The Government reserves the right to request any additional, necessary documentation once it makes the award instrument determination. Such additional information may include but is not limited to Representations and Certifications (see Section VI.B.2., “Representations and Certifications”). The Government reserves the right to remove proposers from award consideration should the parties fail to reach agreement on award terms, conditions and cost/price within a reasonable time or the proposer fails to timely provide requested additional information. Proposals identified for negotiation may result in a procurement contract or other transaction, depending upon the nature of the work proposed, and other factors.

Proposers looking for innovative, commercial-like contractual arrangements are encouraged to consider requesting Other Transactions. To understand the flexibility and options associated with Other Transactions, consult www.darpa.mil/work-with-us/contract-management#OtherTransactions.

In all cases, the Government contracting officer shall have sole discretion to select award instrument type, regardless of instrument type proposed, and to negotiate all instrument terms and conditions with selectees. DARPA will apply publication or other restrictions, as necessary, if it determines that the research resulting from the proposed effort will present a high likelihood of disclosing performance characteristics of military systems or manufacturing technologies that are unique and critical to defense. Any award resulting from such a determination will include a requirement for DARPA permission before publishing any information or results on the http://www.darpa.mil/work-with-us/contract-management#OtherTransactions program. For more information on publication restrictions, see the section below on Fundamental Research.

B. Fundamental Research

It is DoD policy that the publication of products of fundamental research will remain unrestricted to the maximum extent possible. National Security Decision Directive (NSDD) 189 defines fundamental research as follows:

‘Fundamental research’ means basic and applied research in science and engineering, the results of which ordinarily are published and shared broadly within the scientific community, as distinguished from proprietary research and from industrial development, design, production, and product utilization, the results of which ordinarily are restricted for proprietary or national security reasons.

As of the date of publication of this BAA, the Government expects that program goals as described herein may be met by proposers intending to perform fundamental research and proposers not intending to perform fundamental research or the proposed research may present a high likelihood of disclosing performance characteristics of military systems or manufacturing technologies that are unique and critical to defense. Based on the nature of the performer and the nature of the work, the Government anticipates that some awards will include restrictions on the resultant research that will require the awardee to seek DARPA permission before publishing any information or results relative to the program.

Proposers should indicate in their proposal whether they believe the scope of the research included in their proposal is fundamental or not. While proposers should clearly explain the intended results of their research, the Government shall have sole discretion to select award instrument type and to negotiate all instrument terms and conditions with selectees. Appropriate clauses will be included in resultant awards for non-fundamental research to prescribe publication requirements and other restrictions, as appropriate. This clause can be found at www.darpa.mil/work-with-us/additional-baa.

For certain research projects, it may be possible that although the research being performed by the awardee is restricted research, a subawardee may be conducting fundamental research. In those cases, it is the awardee’s responsibility to explain in their proposal why its subawardee’s effort is fundamental research

III. Eligibility Information

All responsible sources capable of satisfying the Government's needs may submit a proposal that shall be considered by DARPA.

http://www.darpa.mil/work-with-us/additional-baa

A. Eligible Applicants

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

a) FFRDCs

FFRDCs are subject to applicable direct competition limitations and cannot propose to this BAA in any capacity unless they meet the following conditions: (1) FFRDCs must clearly demonstrate that the proposed work is not otherwise available from the private sector. (2) FFRDCs must provide a letter on official letterhead from their sponsoring organization citing the specific authority establishing their eligibility to propose to Government solicitations and compete with industry, and their compliance with the associated FFRDC sponsor agreement’s terms and conditions. This information is required for FFRDCs proposing to be awardees or subawardees.

b) Government Entities

Government Entities (e.g., Government/National laboratories, military educational institutions, etc.) are subject to applicable direct competition limitations. Government entities must clearly demonstrate that the work is not otherwise available from the private sector and provide written documentation citing the specific statutory authority and contractual authority, if relevant, establishing their ability to propose to Government solicitations.

c) Authority and Eligibility

At the present time, DARPA does not consider 15 U.S.C. § 3710a to be sufficient legal authority to show eligibility. While 10 U.S.C.§ 2539b may be the appropriate statutory starting point for some entities, specific supporting regulatory guidance, together with evidence of agency approval, will still be required to fully establish eligibility. DARPA will consider FFRDC and Government entity eligibility submissions on a case-by-case basis; however, the burden to prove eligibility for all team members rests solely with the proposer.

2. Non-U.S. Organizations and/or Individuals

Non-U.S. organizations and/or individuals may participate to the extent that such participants comply with any necessary nondisclosure agreements, security regulations, export control laws, and other governing statutes applicable under the circumstances.

B. Organizational Conflicts of Interest

FAR 9.5 Requirements In accordance with FAR 9.5, proposers are required to identify and disclose all facts relevant to potential OCIs involving the proposer’s organization and any proposed team member (subawardee, consultant). Under this Section, the proposer is responsible for providing this disclosure with each proposal submitted to the BAA. The disclosure must include the proposer’s, and as applicable, proposed team member’s OCI mitigation plan. The OCI mitigation plan must include a description of the actions the proposer has taken, or intends to take, to prevent the existence of conflicting roles that might bias the proposer’s judgment and to prevent the proposer from having unfair competitive advantage. The OCI mitigation plan will specifically discuss the disclosed OCI in the context of each of the OCI limitations outlined in FAR 9.505-1 through FAR 9.505-4.

Agency Supplemental OCI Policy In addition, DARPA has a supplemental OCI policy that prohibits contractors/performers from concurrently providing Scientific Engineering Technical Assistance (SETA), Advisory and Assistance Services (A&AS) or similar support services and being a technical performer.

Therefore, as part of the FAR 9.5 disclosure requirement above, a proposer must affirm whether the proposer or any proposed team member (subawardee, consultant) is providing SETA, A&AS, or similar support to any DARPA office(s) under: (a) a current award or subaward; or (b) a past award or subaward that ended within one calendar year prior to the proposal’s submission date.

If SETA, A&AS, or similar support is being or was provided to any DARPA office(s), the proposal must include:

The name of the DARPA office receiving the support;

The prime contract number;

Identification of proposed team member (subawardee, consultant) providing the support; and An OCI mitigation plan in accordance with FAR 9.5.

Government Procedures In accordance with FAR 9.503, 9.504 and 9.506, the Government will evaluate OCI mitigation plans to avoid, neutralize or mitigate potential OCI issues before award and to determine whether it is in the Government’s interest to grant a waiver. The Government will only evaluate OCI mitigation plans for proposals that are determined selectable under the BAA evaluation criteria and funding availability.

The Government may require proposers to provide additional information to assist the Government in evaluating the proposer’s OCI mitigation plan.

If the Government determines that a proposer failed to fully disclose an OCI; or failed to provide the affirmation of DARPA support as described above; or failed to reasonably provide additional information requested by the Government to assist in evaluating the proposer’s OCI mitigation plan, the Government may reject the proposal and withdraw it from consideration for award.

C. Cost Sharing/Matching

Cost sharing is not required; however, it will be carefully considered where there is an applicable statutory condition relating to the selected funding instrument. Cost sharing is encouraged where there is a reasonable probability of a potential commercial application related to the proposed research and development effort.

For more information on potential cost sharing requirements for Other Transactions for Prototype, see http://www.darpa.mil/work-with-us/contract-management#OtherTransactions.

D. Other Eligibility Criteria

1. Collaborative Efforts

Collaborative efforts/teaming are encouraged as appropriate to meet the goals of the program.

2. Ability to Receive Awards in Multiple Technical Areas – Conflicts of Interest (COIs)

While proposers may submit proposals for both Technical Areas 1 and 2, proposers may not be selected for both Technical Area 1 and for Technical Area 2, whether as a prime, subcontractor, or in any other capacity, from an organizational to an individual level.

E. Associate Contractor Agreement Clause

This same or similar clause will be included in all awards against HR001117S0023:

(a) It is recognized that success of the SSITH research effort depends in part upon the open exchange of information between the various Associate Contractors involved in the effort. This clause is intended to insure that there will be appropriate coordination and integration of work by the Associate Contractors to achieve complete compatibility and to prevent unnecessary duplication of effort. By executing this contract, the Contractor assumes the responsibilities of an Associate Contractor. For the purpose of this clause, the term Contractor includes subsidiaries, affiliates, and organizations under the control of the contractor (e.g. subcontractors).

(b) Work under this contract may involve access to proprietary or confidential data from an Associate Contractor. To the extent that such data is received by the Contractor from any Associate Contractor for the performance of this contract, the Contractor hereby agrees that any proprietary information received shall remain the property of the Associate Contractor and shall be used solely for the purpose of the SSITH research effort. Only that information which is received from another contractor in writing and which is clearly identified as proprietary or confidential shall be protected in accordance with this provision. The obligation to retain such information in confidence will be satisfied if the Contractor receiving such information utilizes the same controls as it employs to avoid disclosure, publication, or dissemination of its own proprietary information. The receiving Contractor agrees to hold such information in confidence as provided herein so long as such information is of a proprietary/confidential or limited rights nature.

(c) The Contractor hereby agrees to closely cooperate as an Associate Contractor with the other Associate Contractors on this research effort. This involves as a minimum:

(1) Maintenance of a close liaison and working relationship;

(2) Maintenance of a free and open information network with all Government-identified Associate Contractors;

(3) Delineation of detailed interface responsibilities;

(4) Entering into a written agreement with the other Associate Contractors setting forth the substance and procedures relating to the foregoing, and promptly providing the Agreements Officer/Procuring Contracting Officer with a copy of same; and,

(5) Receipt of proprietary information from the Associate Contractor and transmittal of Contractor proprietary information to the Associate Contractors subject to any applicable proprietary information exchange agreements between associate contractors when, in either case, those actions are necessary for the performance of either.

(d) In the event that the Contractor and the Associate Contractor are unable to agree upon any such interface matter of substance, or if the technical data identified is not provided as scheduled, the Contractor shall promptly notify the DARPA SSITH Program Manager.

The Government will determine the appropriate corrective action and will issue guidance to the affected Contractor.

(e) The Contractor agrees to insert in all subcontracts hereunder which require access to proprietary information belonging to the Associate Contractor, a provision which shall conform substantially to the language of this clause, including this paragraph (e).

Note: It is intended that ACA’s be established, after selections and prior to contract award, between each TA-1 and TA-2 performer.

IV. Application and Submission Information

PROPOSERS ARE CAUTIONED THAT EVALUATION RATINGS MAY BE LOWERED

AND/OR PROPOSALS REJECTED IF PROPOSAL PREPARATION (PROPOSAL FORMAT,

CONTENT, ETC.) AND/OR SUBMITTAL INSTRUCTIONS ARE NOT FOLLOWED.

A. Address to Request Application Package

This announcement, any attachments, and any references to external websites herein constitute the total solicitation. If proposers cannot access the referenced material posted in the announcement found at www.darpa.mil, contact the administrative contact listed herein.

B. Content and Form of Application Submission

1. Full Proposal Format

All full proposals must be in the format given below. Proposals shall consist of two volumes:

Volume I – Technical and Management Proposal (3 sections), and Volume II – Cost Proposal (4 sections). The submission of other supporting materials along with the proposals is strongly discouraged and will not be considered for review. All pages shall be printed on 8-1/2 by 11 inch http://www.darpa.mil/ paper with type not smaller than 12 point. Smaller font may be used for figures, tables and charts. The page limitation for full proposals includes all figures, tables, and charts.

Section II of Volume I, Technical and Management Proposal, shall not exceed 30 pages for a proposal responding to TA-1, or 20 pages for a proposal responding to TA-2. Individual proposals should address one of the two technical areas; organizations wishing to propose to both technical areas must submit a separate proposal for each. All full proposals must be written in English.

A summary slide of the proposed effort, in PowerPoint format, should be submitted with the proposal. A template slide is provided as Attachment 2 to the BAA. Submit this PowerPoint file in addition to Volumes I and II of your full proposal. This summary slide does not count towards the total page count.

a. Volume I, Technical and Management Proposal

Section I. Administrative

A. Cover sheet to include:

(1) BAA number (HR001117S0023);

(2) Technical area;

(3) Lead Organization submitting proposal;

(4) Type of organization, selected among the following categories:

Large Organization, Small Disadvantaged Organization, Other Small Organization, HBCU, MI, Other Educational, Other Nonprofit;

(5) Proposer’s internal reference number (if any);

(6) Other team members (if applicable) and type of organization for each;

(7) Proposal title;

(8) Technical point of contact to include:

Salutation, last name, first name, street address, city, state, zip code (+4), telephone, fax (if available), electronic mail;

(9) Administrative point of contact to include:

Salutation, last name, first name, street address, city, state, zip code (+4), telephone, fax (if available), electronic mail;

(10) Total funds requested from DARPA, and the amount of cost share (if any); AND

(11) Date proposal was submitted.

B. Official transmittal letter.

The transmittal letter should identify the BAA number, the proposal by name, and the proposal reference number (if any), and should be signed by an individual from the prime organization who is authorized to submit proposals to the Government.

Section II. Detailed Proposal Information

A. Executive Summary A one-page executive summary outlining the proposed effort. The executive summary must contain:

1. A high-level overview of the proposed work;

2. Metrics used to define success;

3. Milestones (both DARPA-mandated and proposed-defined);

4. Operational scenarios relevant to the proposed approach;

5. Innovations made by the proposed work; AND

6. The cost and duration of each phase.

B. Technical Approach A detailed description of the technical approach, technical rationale, and constructive plan for accomplishment of technical goals in support of the innovative claims and deliverables. This section is the centerpiece of the proposal and should succinctly describe the uniqueness and benefits of the proposed approach. Proposers must include adequate detail and justification for any performer-defined metrics and goals. In addition, a detailed analysis of how the proposed approach will meet both the DARPA and performer defined metrics must be provided.

For TA-1 a clear description of how the proposed security architecture would exhibit the required characteristics (scalability, flexibility, and adaptability) should be provided. It is also critical for proposers to describe how they will evaluate the tradeoff between power, performance, area, software compatibility. A clear plan for design tool development should also be provided that indicates the level of new tools that would be developed as well as the extent to which existing design tools would be utilized.

For TA-2 a clear description of how the proposer will interact with TA-1 performers should be provided. The description should include how a two-way exchange of information and ideas will be fostered and utilized. Proposers should also indicate how they will connect the hardware and software communities through the means of security representations.

C.…