Broad Agency Announcement

Supply Chain Hardware Integrity for Electronics

Defense (SHIELD)
Microsystems Technology Office
DARPA-BAA-14-16
March 3, 2014

1
 Table of Contents
Part I: Overview Information .......................................................................................................... 3 
Part II: Full Text of Announcement ................................................................................................ 4 
Sec. I:  FUNDING OPPORTUNITY DESCRIPTION .......................................................... 4 
A.  Program Objectives ......................................................................................................... 7 
B.  Program Structure ........................................................................................................... 9 
C.  Technical Areas ............................................................................................................ 10 
Sec II.  AWARD INFORMATION ..................................................................................... 25 
A.  Fundamental Research .................................................................................................. 26 
Sec. III:  ELIGIBILITY INFORMATION .......................................................................... 27 
A.  Eligible Applicants........................................................................................................ 28 
B.  Procurement Integrity, Standards of Conduct, Ethical Considerations, and
Organizational Conflicts of Interest ...................................................................................... 28 
C.  Cost Sharing/Matching ................................................................................................. 29 
Sec. IV:  APPLICATION AND SUBMISSION INFORMATION .................................... 29 
A.  Address to Request Application Package ..................................................................... 29 
B.  Content and Form of Application Submission.............................................................. 29 
Sec. V:  APPLICATION REVIEW INFORMATION .......................................................... 42 
A.  Evaluation Criteria ........................................................................................................ 42 
B.  Review and Selection Process ...................................................................................... 43 
Sec. VI:  AWARD ADMINISTRATION INFORMATION ............................................... 44 
A.  Selection Notices .......................................................................................................... 44 
B.  Administrative and National Policy Requirements....................................................... 44 
Sec. VII:  AGENCY CONTACTS ........................................................................................ 50 
Sec. VIII. OTHER INFORMATION........................................................................................ 51 
A.  Intellectual Property Procurement Contract Proposers ................................................. 51 
B.  Non-Procurement Contract Proposers – Noncommercial and Commercial Items
(Technical Data and Computer Software) ............................................................................ 52 
C.  All Proposers – Patents ................................................................................................. 53 
D.  All Proposers – Intellectual Property Representations ................................................. 53 
E.  Other Transactions (OTs): ............................................................................................ 53 

2
Part I: Overview Information

 Federal Agency Name – Defense Advanced Research Projects Agency (DARPA),

Microsystems Technology Office/MTO
 Funding Opportunity Title – Supply Chain Hardware Integrity for Electronics Defense
(SHIELD)
 Announcement Type – Initial Announcement
 Funding Opportunity Number – DARPA-BAA-14-16
 Catalog of Federal Domestic Assistance Numbers (CFDA) – 12.910 Research and
Technology Development
 Dates
o Posting Date: March 3, 2014
o Abstract Due Date: April 1, 2014
o Proposal Due Date: May 30, 2014
o Proposer’s Day: March 14, 2014 (See DARPA-SN-14-22)
 Anticipated individual awards – Multiple awards are anticipated.
 Types of instruments that may be awarded -- Procurement contract, grant, cooperative
agreement or other transaction.
 Any cost sharing requirements - None
 Agency contact
o Mr. Kerry Bernstein
The BAA Coordinator for this effort can be reached at
DARPA/MTO
ATTN: DARPA-BAA-14-16
675 North Randolph Street
Arlington, VA 22203-2114
DARPA-BAA-14-16@darpa.mil

3
Part II: Full Text of Announcement

Sec. I: FUNDING OPPORTUNITY DESCRIPTION

The Defense Advanced Research Projects Agency 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 procedures under Federal Acquisition Regulation (FAR) 35.016
and the Department of Defense Grant and Agreement Regulatory System (DoDGARS) Part 22
for Grants and Cooperative Agreements. Any negotiations and/or awards will use procedures
under FAR 15.4, Contract Pricing, as specified in the BAA (including DoDGARS Part 22 for
Grants and Cooperative Agreements). 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.

DARPA is soliciting innovative research proposals in the area of supply chain protection of
electronic components. 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.

By nature of the application, the systems which the United States depends upon for national
security places severe demands on the electronic components comprising them; a failure in any
one of these components can put warfighter lives as well as missions at risk. It is critical, then,
that these components perform as expected and for their full specified lifetime. The erosion in
the securing and the control of industry as well as government electronic component supply
chains, however, presents a growing threat to national security. Recycled, rejected, or remarked
authentic parts and non-authentic counterfeit electronic components are increasingly widespread
throughout the defense supply chain; over the past two years alone, more than one million
suspect parts have been associated with known supply chain compromises1. Independent
distributors have indicated that anywhere from 0.5% to 35% of their incoming products for some
part categories are suspected counterfeit2. Threats from counterfeit parts of unknown provenance
may be associated with: their questionable quality control, unknown age/wear-out; uncertain
version vintage; and/or uncertainty about whether the parts meet specifications and are free from
adulteration.

1
“Inquiry into Counterfeit Electronic Parts in the Department of Defense Supply Chain”, Report of the Committee
on Armed Services, United States Senate, May 21, 2012, pp i-ii
2
“Can EDA Combat the Rise of Electronic Counterfeiting?”, Matthew Sale (USNSWC, Crane, IN, US), Design
Automation Conference (DAC) 2012, Session 8.1, 5 June, 2012

4
Many counterfeit parts sold to contractors come from legitimate independent distributors; with
the best of intentions, but lacking effective screening techniques3, these distributors may be at
risk for passing along bogus components. Because of this, a policy of excluding distributors who
have sold counterfeits from future government sales provides some improvement in security, but
it does not adequately address the problem. The globalization of semiconductor production,
packaging, and electronic module assembly, the low cost of entry and the technical
sophistication required to produce counterfeit parts are factors that will allow counterfeiting to
continue to grow. Extended DoD design and acquisition cycles of 10 years or more, and product
service lifetimes of perhaps 30 years causes components to become obsolete before a DoD
system is retired. Parts that formerly cost $10 each can become worth thousands of dollars more
once they become obsolete, thus incentivizing further counterfeiting.

Chain of custody, once an effective means of safeguarding component provenance, is no longer

able to effectively counter the infusion of counterfeit parts due to the global nature of today’s
extensive international supply chain. For larger systems, integrated circuits and subassemblies
may pass through many hands on multiple continents before they are ultimately installed in their
final application; each stop along the way exposes the assembly to additional potential
compromise. Non-destructive, high-volume detection of counterfeit electronics, where it even
exists, can be expensive and time-consuming, due in part to the growing size and complexity of
integrated circuits, and the need for comprehensive analysis of large quantities of parts. Current
methods of detection involve a variety of techniques ranging from functional testing to physical
inspections. In general, these methods are not fully effective, as well as too expensive, too slow,
and too easily circumvented. Because of the lack of an effective deterrence, counterfeiters create
and distribute illicit parts with impunity at minimal cost, reaping millions of dollars in revenue
lost to the IP owner and the OEM. In addition to the risk, replacing these counterfeit components
once they are discovered costs the Government millions of more dollars.

The threat space associated with the infiltration of counterfeit electronic components in the
supply chain is extensive, and includes:
- Recycled components removed from used printed circuit boards and sold as new;
- Unlicensed overproduction of authorized components built by a foundry;
- Test rejects and sub-standard component yield fallout sold as new, high quality parts;
- Parts remarked with falsely elevated reliability grade or newer date of manufacture;
- Clones and copies of original components, which may be of extremely low quality, or
which may include altered or hidden additional functionality; and
- OEM components that are covertly repackaged into new product form-factors and then
used in unauthorized applications.

A widely-adopted supply chain security assurance capability is urgently needed. Such a solution
must exhibit a few key characteristics. Supply chain authentication must be:
- Extremely low cost, with minimal impact to the component manufacturer, distributor, or
end-user, as well as to the host component itself;
- Effective at mitigating most supply chain security threats;
- Be simple, very fast, and executable by untrained operators;

3
“Can EDA Combat the Rise of Electronic Counterfeiting?”, Matthew Sale (USNSWC, Crane, IN, US), Design
Automation Conference (DAC) 2012, Session 8.1, 5 June, 2012

5
 - Trustworthy, reliable, and prohibitively difficult to spoof;
- Executable at any place and at any time along the supply chain, providing instant results
on-site;
- Performed using a minimum of specialized, inexpensive interrogation equipment;
- Standardized and widely adopted by government and industry;
- Manufacturable in high volume using standard foundry processes; and
- A value-add to the end-product, recognized and requested by the component consumer.
 
The DARPA SHIELD Program intends to develop an advanced supply chain hardware
authentication technology capability. Specifically, DARPA is soliciting innovative research and
development proposals to create extremely small electronic chips hosting specific advanced
capabilities described below, for use in the authentication of the host electronic components to
which they are physically attached.

Table 1 Glossary
Dielet Extremely small computer chip developed during SHIELD
Hardware Root-of-
An incorruptible, immutable hardware identity reference
Trust
A 256-bit cipher code, stored on dielet and on a secure
Key
server, used to secure the dielet authentication operation
Limited hardware proof of concept chip without full
Test Site
product functionality
Physical hardware structure on SHIELD dielet that
Sensor
passively detects intrusions compromising security
A device attached to a communication appliance that
Probe
powers the SHIELD dielet
IP Intellectual Property
CONOP Concept of Operations
DFM/DFY Design for Manufacturability/ Design for Yield
PFA Probability of False Alarm
PD Probability of Detection
OEM Original Equipment Manufacturer
GFE Government-Furnished Equipment
IC Integrated Circuit
CDR Critical Design Review
DSS Digital Signature Standard
CMVP Cryptographic Module Verification Program
Failure rate of a component, measured in Failures-in-Time
FITS
over the program
Lifetime of a component, measured in thousands of power-
KPOH
on-hours
Bill of Material, a list of components comprising a given
BOM
assembly

6
 A. Program Objectives

The SHIELD Program will provide a secure hardware root-of-trust which, when co-packaged
with an electronic component, will provide it with a unique, permanent identification that is
nearly impossible to copy or alter. This root-of-trust will be used to authenticate the provenance
of electronic components in an assembly as they travel through the supply chain, as well as by
the final consumer of the assembly to occasionally re-authenticate the composition of its final
installation throughout its lifetime. Superior dielet designs will contain six critical hardware
assurance features:

1. A hardware root-of-trust cryptographic key storage which is prohibitively expensive and

time-consuming to reverse-engineer;
2. A complete, compact, on-board key encryption engine, capable of encrypting an external
challenge using its on-board cryptographic key; the cryptographic key never leaves the
SHIELD dielet. The message will be decrypted using the cryptographic key stored in a
secure server database;
3. A physically-fragile but electrically-robust dielet which can be embedded in the host
component's electronic packaging. The dielet self-destructs upon any attempts to
physically open, remove, or transfer it from its host component using standard reverse-
engineering de-processing techniques;
4. Unpowered, passive sensors that record attempted compromises to the authenticator
dielet and potentially other operations on the overall packaged assembly such as
soldering or de-soldering;
5. Inductive or RF communication and powering to allow contactless operation; and
6. Built-in dielet resiliency against power-based component exploits or attacks.

The threat space associated with hardware attacks is substantial, and spans the entire design
process, fabrication, and distribution of a component. While no single supply chain solution can
protect the entire range of vulnerabilities, SHIELD will provide near-100% security assurance
against the six most common counterfeit modes currently being seen in the industry, listed on
page five.

To assure that such a device can fulfill the above objectives, additional design properties should
be considered in superior design proposals.
7. Hardware attacks often leverage the alteration of various re-writable data storage
structures, to reconfigure the given device into an alternative, unexpected machine state4.
Any rewritable storage included in designs must be carefully assessed for its security.
8. Components used in sensitive assemblies often have very specific, critical reliability
targets. To not interfere with the reliability of the host component in any way, the offered
SHIELD dielet proposal must be completely stand-alone, and should not touch or interact
with the host chip in any way. Isolation from the SHIELD dielet allows the host to retain
its original reliability. Potential reliability impacts include the package alterations needed
to carry the dielet, and unintended inductive or RF coupling impacts on the host device
during dielet activation. Both are studied in this program, and are described below.

4
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.prd29-genc-009492c/ch01s03s03.html

7
 9. To maintain operational security, the inductive or RF probe and dielet must be in the
immediate vicinity of each other to be able to communicate. The personalized
cryptographic key information on the dielet must never be communicated off of the
dielet, similarly, the key information on the server should never be released.
10. To be used ubiquitously and adopted by industry as well as government, the entire
proposed CONOP, including the SHIELD dielet, needs to be extremely inexpensive to
acquire, implement, and execute.
11. Finally, to minimize the physical size, power consumption, and cost of the SHIELD
dielet, CONOP complexity should be pushed up to the secure server wherever possible,
while still fulfilling the goals of the program.

The example CONOP, which will be realized during this program, demonstrates how SHIELD
authenticates a given component. The tester uses an inexpensive appliance, perhaps a repurposed
smartphone, which has an inductive or RF probe plugged into it. The component to be tested is
probed with this inductive/RF probe immediately above where the SHIELD dielet is embedded.
Besides RF or inductive powering of the dielet, the appliance communicates via RF or induction
with the dielet, uploading an unencrypted dielet serial ID which is associated with that host
component. The OEM’s secure server then responds by issuing a random challenge “question”
which is downloaded through the inductive/RF probe to the SHIELD dielet. The on-board
encryption engine encrypts the challenge using its on-board, securely-stored cryptographic key
and sends the encrypted “answer” back up to the secure server. The server unencrypts the answer
using its cryptographic key, and compares it to the original challenge for authentication. As part
of the encrypted reply, the server also receives the status of the passive sensors to verify the
integrity of the SHIELD die itself, and then increments a counter tracking the number of times
that dielet has been interrogated. A flow diagram of the example CONOP is shown in Figure 1
below.

Figure 1 SHIELD Concept of Operations. Black is unencrypted Query/Response, Red is the

Cryptographic authentication, Blue is the sensors and appliance data transfer.

8
In volume production, it is anticipated that in lieu of a hand-held inductive/RF probe, automated
scanners installed on robotic assemblies similar to current automated component installation
tools will be used to improve thru-put and accuracy. The handheld probe however will be
retained for use by the end-consumer to randomly revalidate the integrity of the installed system
as desired, after delivery. The SHIELD demonstration in Phase 3 will use only handheld probes
for demonstrating proof-of-concept.

It is likely that new industry hardware security standards will emerge as a result of the solutions
developed by SHIELD performers. DARPA expects to engage with transition partners picking
up SHIELD solutions who will pursue establishing related standards for hardware assurance.

B. Program Structure

The DARPA SHIELD program will be structured to achieve:

1. The development of fundamental, on-dielet hardware technologies needed;
2. The design and technology integration of the host dielet; and
3. The deployment and exercising of an exemplary supply chain authentication scheme,
including inductive/RF probes, networks, servers, and appliances.

Work is organized into three separate technical areas, and execution of the project will span up to
three distinct phases.

The DARPA SHIELD program structure is described below and shown graphically in Figure 2.
The program is organized in a manner that encourages performer teaming. Consistent with
Section V, preference will be given to proposals that offer collaborative, complete solutions
which address all three of the main technical areas. DARPA SHIELD will, however, consider
stand-alone proposals for developing concepts in Technical Area 1 and Technical Area 3.
Further, DARPA will also consider stand-alone Technical Area 3 proposals which on its own is
comprised of multiple collaborative performers rather than a single performer.

Figure 2 DARPA SHIELD Program structure

9
DARPA wishes to leverage the inputs of smaller institutions which may not be resourced to
participate in full solutions, but which have compelling ideas for particular technologies
identified below. In support of smaller potential contributors, a proposer offering work in
multiple phases may be required to integrate the output of other prior-phase performers into their
deliverable. All proposal descriptions should clearly define and separate the work offered for
each of the Technical Areas. Work offered should be identified by Technical Area, so that
portions of proposals may possibly be treated as “stand-alone” and selected independently for
funding, if needed.

Groups that are interested in composing a comprehensive teaming proposal may access the
DARPA SHIELD Teaming website bulletin board at
https://sharepoint.extranet.darpa.mil/sites/mto/SHIELD/SitePages/Home.aspx to explore
collaborations with other possible proposing groups. To request an account, please email the
request to the BAA-14-16 mailbox at DARPA-BAA-14-16@darpa.mil

C. Technical Areas

Development of the SHIELD concept will be executed in three distinct technical areas, and
completed in up to three phases, each with their own tasks, deliverables and deadlines. The
period of performance for each of the technical areas is shown in Figure 2. The technical areas
and their tasks and deliverables by phase are described below.

I. Technical Area 1: SHIELD On-Board Technology Phase 1 Only

The desired level of supply chain hardware assurance to be provided by DARPA SHIELD
requires novel, chip-borne technology components, which will need to be integrated into the
existing design platform. Those technology elements and their desired characteristics include:

A. Secure Cryptographic Key Storage Technology.

Secure cryptographic key storage of up to 256 bits in length is required on the dielet to
sustain cryptographic-level authentication of the product. A successful key storage
technology is:

i. Exceedingly difficult to reverse-engineer;

ii. Effectively incorruptible;
iii. Self-destructive upon reverse-engineering or tamper attempts - exquisitely fragile,
while still extremely reliable under normal use conditions;
iv. Economically personalized with unique serial ID and cryptographic key
information in volume production.
v. Compatible with, and ideally available in, the chip process technology selected by
performers for the dielet’s fabrication.
vi. Capable of storing keys that are compliant with Suite B cryptographic algorithms.

B. Passive Sensors
Sensors are central to a robust SHIELD solution, to monitor the integrity of the
authentication dielet itself, and to alert the auditor if a given host component has been
compromised. Onboard sensors must:

10
 i. Passively sense while being unpowered, and be read only when being powered;
ii. Be readable only, be permanently altered by the exposure, and be non-resettable
in any way;
iii. Be inexpensively integrated into a conventional CMOS process without impacting
the host process adversely;
iv. Be small enough to fit in the SHIELD dielet form-factor and specification;
v. Have an appropriately-tuned sensing threshold value, in order to prevent false
positives caused by safe, existing exposures encountered throughout the current
supply chain.

Multiple potential sensing modalities and technologies are of interest. Proposers

are encouraged to suggest specific innovative sensing modes that will ensure the
component’s security, or may provide sensors that passively sample for
conventional, known threat modes. Examples include:

1. X-Ray: to make sure the dielet or the host part has not been reverse-engineered;
2. Light: to verify the part has not been opened or removed from its original host,
sensitive to various wavelengths;
3. Temperature: to determine if the component has been recycled from an existing
circuit board by melting the solder mounting it to its current printed circuit board.
4. Multiple interrogations: to counter dielet reverse-engineering by inserting delays
of 1 second or more between concurrent interrogations.

Proposers are free to submit sensing technology development proposals which sense only
a single threat mode, a subset of all the possible threat modes, or a comprehensive sensor
that responds to all known potential threats.

C. Communication/Power Transmission Technology

Technology improvements will be needed to improve inductive/RF coupling efficiency
so that very small form-factor devices can be used to power the dielet and to
communicate with it. It is desirable to be able to power a dielet, pass a challenge message
to it, and receive the encrypted reply in 2 seconds or less. Performers will determine the
appropriate communication bandwidth necessary to support this latency while passing
256 bit key words, a 64 bit serial ID, random encryption challenges, and much shorter
sensor output words. Proposers are invited to suggest technologies which provide ultra-
high efficiency coupling between the on-dielet inductive coil or RF antenna, and the
interrogating appliance. Solutions offered must couple the dielet to the appliance only
when the appliance’s probe is in its immediate vicinity. The probe otherwise should not
emanate significantly beyond the dielet, nor be able to link to other external devices.
Please note that communication to the SHIELD dielet should not be via conventional
RFID technology; but rather only by inductive or RF coupling to another device within a
few millimeters of the host component’s package.

D. Manufacturing/Process Technology
Multiple adjunct process and manufacturing alterations to conventional CMOS
fabrication technology may be required to produce SHIELD dielets in volume, with the

11
 desired new capabilities, and at the target of less than a penny per dielet. Technical Area
1 manufacturing / process challenges which require performer attention include:

1. Wafer thinning technologies necessary to produce and support SHIELD wafers

that are potentially 10µm or less in thickness, as may be needed to build dielets
that are 100µm x 100µm in size;
2. Integrating disparate sensor and key storage technologies into a common process;
3. High volume, precision personalization of each dielet with a unique serial ID and
cryptographic key;
4. New test technologies needed to check the tiny dielets, i.e. contactless testing, test
coverage protocol, application-specific test patterns;
5. An economic production solution for dicing, picking, and handling microscopic
dielets that are approximately100μm x 100μm in size;
6. The means of assuring that reliability and lifetime of the SHIELD dielet matches
that of the host component. Performers should assume host components which
support 100 KPOH lifetimes, at no more than 3 FITs, and that SHIELD will be
used for under 1 power-on-hour over its entire life.

Acceptable solutions may include 3D integration technology, if it can be shown that the
resulting device assembly achieves the identified program goals, including cost.
Technical Area 1 is developed in the following program structure.

E. Technical Area 1/Phase 1: Technology Development Months 1-18

Phase 1 for the Technical Area 1 will be devoted to the development of the underlying
fundamental devices, materials, and/or structures which realize the specific on-board
capabilities defining SHIELD. During the execution of Phase 1, chip test sites
prototyping the intended embodiment of these devices, materials, or structures must be
designed, fabricated, and characterized, demonstrating specific desired capabilities.
Prospective solutions will be expected to accommodate and support the SHIELD target
specifications shown in the Program Objectives section (Section A, Page 9). This
demonstration will serve as a prototype for the specific solution to be used in the
SHIELD Phase 2 vehicle.
Phase 1 tasks include:
1. Delivery of a fully-described hardware-based solution for required technical
capability, including computer models of behavior rooted in hardware (i.e.
COMSOL, SPICE, finite element electromagnetic modeling, etc.). These models
will be made available to the Technical Area 2/Phase 2 SHIELD chip integrator in
a format that allows the integrator to generate a behavioral of the larger,
assembled dielet.
2. The design and build of a hardware proof-of-concept test site for the intended
realization of the proposed technology. Performers must sufficiently:
a. Exercise a specific realization of their proposed technology in an
exemplary hardware application setting. The setting of the demonstration
in the hardware test site should emulate conditions expected in actual
placement in a host package.

12
 b. Characterize performance, reliability and quality of the test site, for its
response and sensitivity to temperature, voltage, process tolerance, defect
modes, light intensity, altitude, x-rays, etc. The performers must establish
the suitability of their technology when placed in a host component to be
protected.
3. Verification of technology compatibility to conventional IC manufacturing
process. Performers will establish manufacturing requirements for their
technology, and verify that it can inexpensively and reliably be retrofitted to an
existing process without compromise to the base process. If any modifications to
existing conventional IC processing will be required, detailed descriptions of such
modifications must be included. Examples include:
a. An impact statement, describing the anticipated response of base
technology to the performer technology’s insertion;
b. The specific insertion point in the existing process;
c. New required materials or films to be introduced into the manufacturing
process;
d. New tooling required to accommodate SHIELD features;
e. New processes associated with the technology assertion; recipes,
depositions; techniques, implant doses and energies, temperatures,
pressures, times, process endpoint detection;
f. Required line metrology additions to assure adequate yield and quality
monitoring;
g. The re-entry point of SHIELD dielet hardware back into conventional
processing.
h. Novel SHIELD dielet passivation, for protection/isolation in packaging,
and technology compatibility to the passivation.
4. Layouts of specific technology reductions-to-practice, to be provided to the Phase
2 chip design integrator. The performer will identify layer names and
compositions, alignment markings, signal references, etc. for integration into the
design automation environment chosen by the Technical Area 2/Phase 2 designer.
5. Description of specific test conditions and a test pattern file, in an integrator-
specified format. This is needed to check the specific technology reduction at
dielet’s final test.
6. Development of a fully defined interface specification for the technology. A
defined interface will facilitate its integration and use in SHIELD Phase 2 tasks.

F. Technical Area 1/Phase 1 Responsibilities

Technical options and responsibilities in Technical Area 1 will reside entirely with the
performer and should be addressed in the offered proposal. Responsibilities to be handled
by the performer include test site design, fabrication, and characterization, as well as
operational physics, materials and structural choices.

II. Technical Area 2: SHIELD Dielet Design & Integration Phase 1 and 2 Only
SHIELD Technical Area 2 will integrate technologies developed in Phase 1 of the program onto
a microscopic dielet carrying the necessary logic, to achieve a completely autonomous supply
chain authentication prototype device. The extremely small chip will contain a full 256 bit

13
encryption engine, secure and personalized encryption key storage, sensors that detect
component compromise, inductive/RF communication and power, and the logic necessary to
realize the interface to the secure server. SHIELD authentication dielets will be fabricated,
tested, and characterized during Phase 2.

A. Technical Area 2/Phase 1: Design Months 1-18

In Technical Area 2/Phase 1, performers will design the logic realizing the onboard
encryption engine, and the interface logic necessary to successfully communicate with
the inductive/RF appliance. Proposals for Technical Area 2 must introduce innovative
means of achieving required function economically in both device count and power, in
order to meet the specifications of the program. The performer must provide block
diagrams, state machine diagrams, timing diagrams, simulation outputs, flowcharts and
other figures to illustrate the dielet architecture. These figures should guide the high-level
design representation, and will be used in design reviews.

B. Technical Area 2/Phase 1 Tasks:

1. Define a SHIELD Design Environment: Performers will configure an engineering
design automation environment that will support the development of the SHIELD
dielet and the incorporation of its protection technologies. This design methodology
must use conventional industry design descriptors and be capable of carrying the
SHIELD program from initial design through design checking, simulation, power
estimation, hardware build, test pattern generation, and electromagnetic interference
checking, Performers will provide the adopted conventions to other SHIELD
performers providing design inputs, in order to define input data syntax and data
formats.
2. Develop a SHIELD logic design description, expressed in an appropriate high-level
design language: The validated, verified logic design will comprise: a complete
standard 256 bit encryption engine which responds to random challenges; the
evaluation of onboard sensors; and the porting of network communication to the
dielet’s logic. The performance of the design should be sufficient to be able to retire
complete authentication transactions in approximately 2 seconds, which includes:
a. Powering the dielet;
b. Uploading the serial ID to a secure server, and downloading an unencrypted
random challenge back down to the dielet; and
c. Encrypting the challenge and reading the onboard integrity sensors on
board the dielet, then uploading both back up to the host server for decryption
and comparison.
3. Provide Encryption: Potential SHIELD performers should propose a security scheme
that provides at minimum the equivalent level of security as 256-bit AES, and which
can be accommodated by the SHIELD dielet’s form factor, area, and available power. 
Only open standard industry encryption designs will be used, but are the proposer’s
choice. DARPA SHIELD is concerned with the development of hardware technology
for supply chain authentication; consequently, the development of new encryption
algorithms and standards are not part of the program and should not be offered by
proposers. Only CMVP-verified encryption content may be used in the design.
Performers are encouraged to use 3rd party certified IP when available. Although

14
 discouraged from doing so, performers may elect to validate their own alternative
implementation of industry standard encryption algorithms via CMVP, if the
SHIELD schedule allows. Proposed designs must prevent the attacker from
compromising the cryptographic key, and also must be built so that alternative
encryption algorithms may later replace the performer’s implemented encryption, if
desired by subsequent industry users. The design should also prevent frequent
repeated interrogation of the chip that might be used by an attacker to attempt to
divine the cryptographic key. No network security certificates of any kind should be
stored on the SHIELD dielet.
4. Design in Needed Performance: If the proposed design is a synchronous clocked
machine, then the performer is free to choose the onboard minimum or maximum
clock rates needed to support on-dielet transaction retirement rates of 1 second on
chip, within the available power envelope on chip (see next paragraph). Including
high performance network latencies, total transactions should be completed in less
than approximately 2 seconds.
5. Estimate power for the onboard logic and sensors: Power estimation must be
performed, and the total power needed for the proposed dielet assembly must be
accommodated by the available power. Dielet power can be sourced by the inductive
or RF power design, at the prerogative of the proposer. It is anticipated that SHIELD
dielet designs will be limited to approximately 50µW, order-of-magnitude. The
design of the inductive or RF powering and communication circuitry including
scheme dependent power conditioning must be supported by rigorous simulations
and/or experimental demonstrations, as appropriate. Supply voltage is to be
determined by the proposer, and default supply voltage tolerances will be +/- 10%
unless proposers justify alternative tolerances. Power supply conditioning should be
included in design if needed.
6. Integrate Technology: Technical Area 2 performers should closely coordinate with
relevant Technical Area 1 performers to insure that:
a. The Technical Area 2 performer has a clear path for implementing Technical
Area 1 technologies; and
b. The Technical Area 2 performer has a design and fabrication plan in
Technical Area 2/Phase 2 showing how the integrated design, comprising
logic and powering/communications circuitry, will be completed successfully
in Phase 2.
c. Storage technology for the cryptographic key should be identified by the end
of Technical Area 2/Phase 1; its implementation should be consistent with the
Technical Area 1/Phase 1 key storage technology developed.
7. Create and Model SHIELD physical design: SHIELD circuit design modeling will
verify that the physical implementation of SHIELD is robust across process, voltage,
and temperature. SHIELD dielets should be functional across a +/- 3σ composite
process distribution window, and at temperatures from 0-35deg C. The dielet should
survive temperature exposures of -55deg C -125deg C. SHIELD dielets should also
be functional across the +/- 3σ voltage window determined from the design of the
power conditioning scheme selected. If performer design solutions are synchronous,
then early mode/late mode timing models using best case/worst case models will be
developed to ensure functionality and reliability of the embedded SHIELD dielet.

15
 8. Fabrication implementation plan: the process technologies to be used in Phase 2
should be clearly defined, along with the intended candidate fab(s) or vendor(s) that
will build the proposed design, the schedule checkpoints when submissions will be
made, and how the new adjunct technologies required onboard the dielet will be
accommodated by the fabrication facility selected.
9. Interface to Phase 1 Technologies: Suitable design interfaces and standards will be
established and planned to facilitate the integration of Phase 1 technology
components into the SHIELD dielet design. Phase 1 technologies will be added as IP
blocks on the SHIELD dielet, including voltage level shifting, timing changes, and
signal buffering as needed to effectively couple the IP to the chip.
10. Layout dielet design in industry standard format: Completed designs will conform to
industry standard layout formats to facilitate entry into conventional fabrication
submission systems. Successful proposers will apply insight and experience to
optimize DFM and DFY, proposing solutions which insure high yielding SHIELD
devices that are defect-resilient and process-tolerant.
11. Develop a test pattern generation and testing methodology: Successful proposers will
develop the test pattern generation and testing strategy, and automated verification
capabilities needed to thoroughly test (a) the SHIELD die, its new on-board
technologies, and its sensors; and (b) the packaged host component. Testing must
assure full SHIELD and host component functionality, economically and with as few
patterns as possible. The SHIELD program depends on the yield, quality, and
reliability of the new assembly to not compromise those of the original host
component without SHIELD.
12. Support a Critical Design Review: Before proceeding with Phase 2, DARPA will
review the performer's detailed plans for subsequent phases, and will assess whether
the proposed approach is likely to result in a satisfactory SHIELD dielet solution
before proceeding to Technical Area 2/Phase 2. To support that decision, the
performer will support a Critical Design Review. The items listed above will be
major inputs into the CDR. The performer will need to prepare analyses and reports,
and provide inputs including experimental results where appropriate to substantiate
feasibility of their SHIELD dielet design, and that it is ready to proceed to
implementation. Significant remaining risks and associated mitigation plans should be
identified.

C. Technical Area 2/Phase 2: Integration and Fabrication Months 19-36

In Phase 2 of Technical Area 2, design performers will incorporate Technical Area 1’s
specific instantiations of Phase 1 performer technology solutions into their Phase 1 dielet
chip design, for inclusion in the demonstration vehicle. After both final design checks
and process audits, designs will be fabricated in anticipation of Phase 3 demonstrations.

D. Technical Area 2/Phase 2 Tasks:

1. Design full SHIELD dielet, ready for fabrication, with all required functionality
including inductive or RF powering and communications; self-protection features;
core digital engine: In Phase 2, dielet physical designers will incorporate the
technologies from Technical Area 1/Phase 1; and the base logic design created in
Technical Area 2/Phase 1. The performer will complete final checking of the

16
 resulting assembly. During wafer manufacturing, performers will generate test
patterns, and prepare for hardware evaluation.
2. Fabricate SHIELD dielet: Performers will release the design to manufacturing, and
monitor SHIELD dielet wafers as they progress through manufacturing; they will
intercept the hardware at critical process line insertion entries and exits for any new
technology introductions. Performers will track process metrology and in-line
monitors for SHIELD parts to assure dielet functionality for Phase 3 technology
reduction. For the SHIELD program, dielet fabrication may be accomplished at US or
foreign fabrication facilities, although post-program transition partners may later
impose restrictions. Intended fab sites should be specified in the proposal.
3. Test, characterize, and assess reliability of SHIELD dielet: Performers will
coordinate with the fabrication facility to fully test and characterize SHIELD dielets,
assuring full functional schmoo windows across process, voltage, and temperature for
all of the structures on the dielet. Proposers should provide their qualification strategy
for proving that the SHIELD dielet meets all required program specifications.

E. Technical Area 2 Responsibilities:

There is no Government Furnished Equipment (GFE) or intellectual property provided to
performers in Technical Area 2. Performers are responsible for implementing the required logic,
encryption algorithm, communication technology, passive sensor management, etc.in the
required standards using their defined methodology.

III. Technical Area 3: SHIELD Deployment Phases 1, 2, 3

Performers in Technical Area 3 will develop the ability to place SHIELD dielets in
component packaging, verifying that it does not compromise the performance or reliability of
the host component or the SHIELD dielet. Performers will develop and exercise an
exemplary concept of operation (CONOP) employing the SHIELD device in a real product.
Technical Area 3 is executed across Phases 1, 2 and 3 of the SHIELD Program, and may
comprise the collaborative solutions of multiple performers. During Phase 1, the proposed
fundamental dielet package insertion, attachment, or lamination techniques are developed,
and desired parametrics for a technology reduction are determined. Also in Phase 1, the
network communications and server backbone design is initiated. This environment is to
serve simply as a representative demonstration of the SHIELD proof of concept, and is not
intended to provide the final, fielded IT system for SHIELD. Phase 2 will establish practical
techniques and tooling associated with reliable, effective precision association of the dielet to
the host package. The development of the network environment is also continued in Phase 2.
In Phase 3, these techniques are collectively deployed to demonstrate the SHIELD concept in
an actual DoD product acquisition program.

A. Technical Area 3/Phase 1: Fundamental Package Technology, and proof-of-concept

network protocol developments Months 1-18
During Phase 1 of Technical Area 3, performers will create a new technology for binding
SHIELD authentication dielets to their host components. During this phase, the
performer’s proposed new techniques for inserting, laminating, or attaching thinned
dielets to the package will be developed and validated for their conformity to SHIELD
program goals. At the close of Technical Area 3/Phase 1, performers will be prepared to

17
 begin fabrication of the tooling which demonstrates the secure and precise association of
the dielet with the host component.

Also initiated in Technical Area 3/Phase 1 is the design of the network and security
backbone upon which the proof-of-concept SHIELD demonstration will be conducted in
Technical Area 3/Phase 3. Performers will develop the rudimentary network and
conventions necessary to allow the SHIELD CONOP to be exercised as a proof-of-
concept, conducting encrypted authentication between the inductive/RF appliance and the
secure server. A strong emphasis is placed on requiring the use of open standards;
developing universal trust in the SHIELD concept is critical to its wider embrace. For
Communication, Security, and Cryptography, only NIST, IEEE, and industry standards
and protocols, and CMVP-verified code will be used in the design and in the exercise.
Performers will be asked to highlight specific areas where applicable standards did not
formerly exist, for which SHIELD may establish new standards and industry conventions
going forward. While SHIELD is a program to specifically develop a supply chain
hardware root-of-trust, its exercise will establish exemplary, preferred operational
conventions, and must be done with an eye towards future wide use and acceptance.
Technical Area 3 Performers will also develop an inexpensive inductive/RF appliance for
use in executing the SHIELD concept. The appliance may be the retrofit or repurposing
of an existing appliance such as a smartphone, with the addition of a probe that is
plugged into the device.

B. Technical Area 3/Phase 1 Tasks:

1. Develop package placement target parametrics: Performers will develop the required
specifications and their tolerances for dielet placement in the host package needed for
acceptable SHIELD dielet functionality. An actual product package will be specified
and provided by DARPA. The following parameters and concepts to be established or
developed in Phase 1:
a. An understanding of the required coupling necessary to achieve sufficient
inductive or RF power transfer and communication between the inductive/RF
appliance and the SHIELD dielet. The SHIELD dielet is approximately 1 mm
below the outer surface and the inductive/RF coupling should be active during the
approximately 2 second transaction;
b. Acceptable depth tolerance of SHIELD dielet below surface of package, and
insertion techniques achieving these tolerances;
c. Standardized positioning conventions that accommodate various package types.
Positioning conventions will also guide the alignment of the inductive/RF
appliance to the location on the package where the SHIELD dielet can be
exercised for a response, both in handheld as well as automated interrogation; and
d. Alternative dielet attachment conventions, test strategies and authentication
procedures for accommodating host components which have heat sinks fully
integrated into their packages. The demonstration CONOP to be exercised in the
SHIELD program will use a component which does not have an integrated heat
sink, however.

18
2. Create SHIELD dummy dielet surrogate: A selected Technical Area 3/Phase 1
performer will create a dummy dielet vehicle for use in exploring tooling and
techniques for the actual SHIELD dielet when it becomes available. The dummy
dielet will be designed and created by Technical Area 3/Phase 1 performers in
conjunction with Technical Area 2 developers so that it closely resembles the form-
factor of the anticipated end product in size and thickness. Simple electrical structures
may be placed on the dummy dielet to assess specific issues of concern to developers.
The dummy dielet that is produced will be made available to other performers in the
program as well, for their use in developing their own specific solutions.

3. Assure the reliability of the host component after SHIELD insertion: Starting with a
base set of assumptions on the general SHIELD dielet size, thickness, electrical
operation, and temperature specs, performers will assess potential impacts or changes
to the reliability and serviceability of the host chip caused by the SHIELD dielet’s
presence and operation within the host package. Potential concerns may include:
a. Packaging strain induced by the insertion operation or by the presence of the
dielet in the package. Strain may compromise the host component reliability
or modulate its device transconductance;
b. Hermetic seal failures in the host package caused by the dielet insertion or
presence. Seal failures can potentially lead to corrosion within the IC;
c. High electromagnetic field impacts to the underlying component when the
SHIELD dielet is interrogated by a manual or automated authentication
inductive/RF probe. High fields potentially lead to dielectric breakdown,
charging, or host component logic errors.

A substantial number of functional, packaged exemplary host components will be

provided by DARPA to Technical Area 3 performers, along with design
documentation describing underlying circuitry and process. This documentation and
the parts may be used to model and test impacts the SHIELD CONOP may have on
the underlying design. From this analysis, performers will be expected to derive rules
on generic impacts that these physical and electromagnetic intrusions may have on
any given electronic part based on its process and design features, and from that
develop a suite of preferred specs for prudent dielet placement and operation in the
package which will insure problem free, robust practice.

4. Assure the reliability of the SHIELD dielet in the host package placement: Performers
will assure the integrity and reliability of the placed SHIELD dielet in the host
package, considering potential damage caused by:
a. Chemical, mechanical, temperature, or electrically-induced materials interactions
with the host packaging materials or process occurring during normal processing,
packaging, dielet insertion or due to aging in normal use.
b. Chemical, mechanical, temperature, or electrically induced materials failures
which should intentionally occur if the product is tampered with, and which must
also be demonstrated to occur reliably and predictably.
c. Mechanical strain, compressive or tensile effects induced on the SHIELD dielet
by the package or on the host component by the SHIELD dielet. Both static and

19
 dynamic changes should be studied, including: at-use temperature effects caused
by differences in thermal expansion coefficients of the dielet and the package,
forces placed on component during socket insertion or board assembly, and strain
induced electrical behavior changes caused by isotropic strain.
d. Dielet exposure to radiation, high X-ray or RF fields when not in use.

Selected stressing of prototypes and modeling may be used to corroborate analyses.

5. Create a SHIELD Inductive/RF Authentication Appliance and Probe:

A selected Technical Area 3/Phase 1 Performer will design an inexpensive
inductive/RF appliance for use in executing the SHIELD concept. The appliance may
be the retrofit or repurposing of an existing appliance such as a smartphone, with the
addition of an inductive/RF probe that is connected to the device by cable or
Bluetooth. The performer will work with the Technical Area 3 performer developing
network protocols to make sure that the appliance developed complies with the
anticipated SHIELD communication standards to be used. The performer will design
prototype inductive/RF probes that will plug into the appliance, and fully document
the device design and its specifications. The performer will develop any microcode,
firmware, and/or software necessary to repurpose the appliance into a SHIELD
authenticator. Specific deliverables include
a. Design of handheld appliance concept, including required specifications,
documentation, schematics, etc.
b. Design of an inductive/RF probe, anticipating potential electromagnetic
interference which may obscure coupled signal. Connection to the appliance may
be accomplished by cable or Bluetooth.
c. Development of necessary microcode, firmware, software needed to repurpose
the handheld appliance to the SHIELD function

The entire SHIELD demonstration will be executed solely using this hand-held
interrogation appliance.

6. Design a Network Architecture for the Demonstration Exercise:

The design of the network architecture carrying a SHIELD demonstration will be
initiated in Phase 1 of Technical Area 3. The complete communications and server
interface will be created by SHIELD performers and will conform to the capabilities
of the hardware being developed in Technical Areas 1 and 2. Performers will design
and create the external environment which operates the embedded SHIELD dielet,
including;
a. All communications between the dielet and the server through the inductive/RF
appliance and network using TLS standards;
b. Software and functionality of the inductive/RF appliance;
c. All required server transaction and decryption software;
d. A simple graphical user interface that allows users to observe actual SHIELD
transaction demonstrations as they are executed; and
e. A key management plan describing how all cryptographic keys in their proposed
architectures are derived, protected at rest, and protected in transit.

20
 Performers will identify what security requirements are required of the appliance,
server, and any other network nodes in the proposed network to allow evaluators to
estimate true adoption costs of this proposal. No certificates should be stored on the
dielet.

By the close of Technical Area 3/Phase 1, performers will have prepared a conceptual
network infrastructure that will host SHIELD, its encryption algorithms, its
communication protocols, and the interfacing between dielet, appliance, network, and
server, and shall define the derived security requirements their architecture places on
each one. This design should be described with documentation, flowcharting, and the
performer’s choice of descriptive network design language. At the conclusion of
Technical Area 3/Phase 1, a Critical Design Review of the SHIELD demonstration’s
network architecture will be held with the performers and members of the
Government Team.

For key management standards, DARPA offers as reference document SP-800-130,

“A Framework for Designing Cryptographic Key Management Systems.” Common
traffic between the appliance and the server should use TLS convention. Performers
are free to define their own network environment, but should justify choices and
prove their efficacy, functionality, and security.

C. Technical Area 3/Phase 2: Packaging Tooling Development and network protocol

implementation Months 19-36
During Phase 2 of Technical Area 3, development of the specific techniques and tooling
required for reliable, effective placement of the dielet in the host package is established.
Aids for aligning the inductive/RF appliance to the SHIELD dielet within the package
will also be developed. At the close of Phase 2, Technical Area 3 performers should be
prepared to execute the SHIELD CONOP in an exemplary setting upon an actual
electrical component currently being used in a federal acquisition program. Also in
Technical Area 3/Phase 2, performers will implement the network structure developed in
Phase 1, and adapt it to the outputs from Phase 1 to be used in the final SHIELD product

D. Technical Area 3/Phase 2 Tasks:

1. Develop the SHIELD Insertion technology. Performers will develop the instrumentation,
tooling, and logistics which will take SHIELD dielets from wafer final test into an actual
component placement. Steps include:
a. Developing a handling technique for taking SHIELD from diced wafers into a
dispensing tool that feeds dielets to an injector. The injector resides at the point in
the encapsulation process where the SHIELD dielets are mated to their hosts.
b. Creating tooling which dispenses diced and separated dielets into the injector, and
inserts or deposits them into the packages or laminates without damage or
compromise to the package or to the dielet. The resulting placement will conform
to the dielet placement positioning and tolerance specifications defined in
Technical Area 3/Phase 1.

21
 c. Automating the association of the placed SHIELD dielet serial ID and
cryptographic key with the host component part number, date and location of
manufacture, reliability grade, and cryptographic key. The performer will design
the method that moves this data onto a secure host server during encapsulation for
later use in authenticating the part in the field, without need for manual
bookkeeping by the human operator. This technique will be used in Phase 3.
2. Develop the SHIELD Network Structure. Performers in Technical Area 3 will, during
Phase 2, implement the network structure they developed in Phase 1, and in the design,
accommodate the specific protocols and technologies that are being implemented on the
dielet in Technical Area 2. It will be essential then that Technical Area 3 performers
understand, anticipate, and accommodate the demands that the dielet design places on the
network topology and security. At the end of Phase 2, performers will provide
a. Detailed network schematics indicating protocols and standards;
b. Specific commercially available devices that the transactions will be executed
upon;
c. Estimates of transaction times and network latencies;
d. Simulation of actual transactions demonstrating successful execution of true and
false authentication requests, with and without flagged compromises appearing on
the SHIELD sensors; and
e. Build-out of the actual prototypical hardware network for use in Phase 3
SHIELD.
3. Develop the SHIELD inductive/RF appliance.
The performer from Technical Area 3/Phase 1 who designed the inductive/RF
appliance and its code will, in Phase 2, fabricate the appliance’s inductive/RF probes
and repurpose the appliance itself to the SHIELD function with required firmware, or
software additions or changes installed. Specific deliverables associated with this task
include:
a. Inductive/RF probe fabrication
b. Repurposed Appliance microcode, firmware, software installation
c. Stand-alone testing of communication between the SHIELD dielet and appliance.

E. Technical Area 3/Phase 3: Demonstration & Evaluation Months 37-48

The DARPA SHIELD program will conclude with a demonstration, one year in duration,
of the SHIELD concept of operations practiced in the supply chain of an actual
component listed in a federal acquisition program’s BOM. The exercise will be
conducted using procedures and authentication techniques that demonstrate how
component distributors and suppliers will be using SHIELD technology in actual
practice. Performer software and hardware will be in place by Phase 3 to execute the
SHIELD operation on limited production level components at vendor sites, which will be
identified and facilitated by DARPA. The operation will be executed by DARPA
SHIELD performers, but evaluated by DARPA government team members. DARPA
government team members will examine the performer solutions for robustness,
determining if the program’s interrogation delay, reliability, functionality, cost, and
security metrics have been fulfilled. Tests will be performed randomly, in rugged
industrial settings, to verify the SHIELD solution remains effective in harsh
environments and resilient to electromagnetic interference. Actual components will be

22
 shipped between work sites developing the specific assembly the component is in, and
performers will exercise SHIELD at those sites. A Government Red Team will attempt to
compromise that component’s supply chain using components with inappropriate or
missing SHIELD dielets, in order to prove the effectiveness of the performers’ overall
SHIELD supply chain solution. This demonstration is essential for transition to wider
industry adoption of the SHIELD concept. Performer results will be released and
publicized by DARPA at the conclusion of the program.

F. Technical Area 3/Phase 3 Tasks:

1. Demonstrate robust placement capability of SHIELD component into real product.
Performers will mate SHIELD dielets to actual product at product package encapsulation
Performer will identify and correct SHIELD failure modes in practice, and perform
defect characterization to identify needed changes to the installation process. Failure data
will be collected and compiled by performers as components are encapsulated and tested,
including:
a. Fails due to faulty package insertions
b. Fails due to non-functional SHIELD chips
c. Initial screening of host components, for uplift in host component failure rate at
module final test which had previous passed wafer final test, above the fallout
baseline before SHIELD was introduced in the process.
2. Exercise the CONOP. Performers will exercise the entire SHIELD CONOP. Performers
will choose the packaged host they exercise their SHIELD technology on from a number
of options offered by DARPA. Performers will then be responsible for modifying those
packages in a production-like environment which DARPA will provide access to, in
order to accommodate placement of the SHIELD dielet. The resulting actual components,
equipped with SHIELD, will be passed through real supply chain channel settings, from
supplier acquisition, through normally-used shipping channels, to subsequent board and
system subassembly vendors. Government Red Team members will intercept the parts
along the way, substituting a subset of them with components containing failing or
inappropriate SHIELD dielets, or with components that are missing the dielets entirely.
Performers will execute the SHIELD operation at various work sites in the components
supply chain throughout the US, checking for component authenticity. Government team
members will record the performer’s detection results.

Performers will be measured to a set of quantitative benchmarks. Metrics on SHIELD

performer solution effectiveness will include:
a. “Probability of Detection” of compromises (PD), broken out by
i. Type of host component (i.e. small passive/discrete, quad plastic flat pack)
ii. Failure mode (i.e. Missing, inappropriate, or failing SHIELD dielet.)
iii. Location type (i.e. at distributor, at subassembly vendor, in shipping),
iv. Setting of host component (i.e. supplied in a component tube, mounted on
a printed circuit board, installed in a system)
b. Probability of False Alarm (PFA), broken out by:
i. Type of host component (i.e. small passive/discrete, quad plastic flat pack)
ii. Setting of host component (i.e. supplied in a component tube, mounted on
a printed circuit board, installed in a system)

23
 c. Average completed authentication delay per SHIELD component.

G. Technical Area 3 Responsibilities

Because DARPA SHIELD is developing hardware assurance technology, exercised in a
simple exemplary CONOP, certain additional capabilities will be required for a
demonstration. DARPA will provide certain accesses and make certain assets available to
Technical Area 3 performers in order for them to demonstrate their design. Respective
responsibilities and government contributions are listed below.

1. Technical Area 3 performers are responsible for providing/creating/executing:

a. The appliance and its associated Inductive/RF probe;
b. All encryption conventions, protocols and standards for connections between the
dielet, probe, appliance, network, and server;
c. The server and its required software; and
d. The insertion operation of the SHIELD dielet into the component.
e. Exercise of the SHIELD CONOP in a prototypical setting.
2. The Government Team has responsibility for providing:
a. A choice of host components for the performers to exercise their CONOP upon;
b. Procurement of host components;
c. Arrangements for test sites for performer to exercise demonstration CONOP
along a prototypical supply chain, spanning from OEM site through shipping,
board sub-assembly, and system manufacture;
d. Red-teaming of the performer’s completed solutions; and
e. Evaluation of the performer solutions.

H. Summary Specifications
Table 2 summarizes exemplary target specifications for the SHIELD dielet which were
described in this BAA. Proposers may suggest alternative specifications to any of those
shown below if the proposer believes that
- only a subset of the specifications can be concurrently met,
- that the specifications are not appropriate to the approach of their proposal, or that
- the changed specifications will result in superior capability, reduced cost, or a
greater chance of user and industry acceptance.

Table 2 Summary of SHIELD Target Specs

A ≈100um x 100um (0.01 mm2); objective is to be small
Area enough to be attached to discrete devices and passives, as
well as more complex logic components.
Thinned substrate, likely 10 um or less. Objective is to
reduce chiplet volume, and increase fragility to prevent
Device thickness
removal from packaging material. Must still allow handling
during manufacturing, test, insertion
Interrogation Latency
(incl. powering and ≈ 1 second dielet delay; ≈2 second full transaction delay
bidirectional including network latencies
communications)

24
 Network
Communication TLS Standard
Protocol
Minimum Delay
between > 1 Second
interrogations
Positioning of
T ≈ 1 mm below top surface of component package;
inductive/RF probe
Encryption Standard Up to 256 bit
Serial ID Length 64 bit
Power Consumption Approximately 50µW
Voltage; tolerance
VDD at discretion of proposer; +/- 10%
(default)
Host Temperatures -55deg C - 125deg C
Interrogation
Operational 0-35 deg C
Temperatures
Sufficient to match 100KPOH host component operation at
Reliability
3 FITs. SHIELD total operational time is under 1 hour.
Cost C < 1.0¢ per dielet

I. SHIELD Alternative Implementations

Proposers may offer alternative acceptable supply chain hardware security solutions
which provide similar superior levels of effectiveness, confidence, and security as the
SHIELD Supply Chain Authentication concept described above. DARPA will consider
other proposals and CONOPs which meet the boundary conditions described above.
Proposers should thoroughly describe their offered technology concept as well as an
alternative exemplary CONOP, and how it will fit into the program’s Technical
Area/Phase structure. Proposers offering alternative solutions should verify that their
solutions mitigate the threats listed on page 7 and exhibit the primary characteristics
listed on page 8 of this solicitation.

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

25
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. 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, grant, cooperative agreement, or other transaction, depending upon the nature of the
work proposed, the required degree of interaction between parties, whether or not the
research is classified as Fundamental Research, and other factors.

In all cases, the Government contracting officer shall have sole discretion to select award
instrument type and to negotiate all instrument terms and conditions with selectees.
Proposers are advised that if they propose grants or cooperative agreements, DARPA may
select other award instruments, as it deems appropriate. 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 program. For more information on
publication restrictions, see the section below on Fundamental Research.

A. 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 established the national policy for controlling the flow of scientific, technical, and
engineering information produced in federally funded fundamental research at colleges,
universities, and laboratories. The Directive 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 either cannot be met by proposers intending to perform fundamental
research or the proposed research is anticipated to present a high likelihood of disclosing
performance characteristics of military systems or manufacturing technologies that are
unique and critical to defense. Therefore, the Government anticipates restrictions on the
resultant research that will require the contractor to seek DARPA permission before
publishing any information or results relative to the program.

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

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

The following statement or similar provision will be incorporated into any resultant non-
fundamental research procurement contract or other transaction:

There shall be no dissemination or publication, except within and between the contractor
and any subcontractors, of information developed under this contract or contained in the
reports to be furnished pursuant to this contract without prior written approval of
DARPA’s Public Release Center (DARPA/PRC). All technical reports will be given
proper review by appropriate authority to determine which Distribution Statement is to be
applied prior to the initial distribution of these reports by the contractor. With regard to
subcontractor proposals for Contracted Fundamental Research, papers resulting from
unclassified contracted fundamental research are exempt from prepublication controls
and this review requirement, pursuant to DoD Instruction 5230.27 dated October 6, 1987.

When submitting material for written approval for open publication, the
contractor/awardee must submit a request for public release to the PRC and include the
following information: (1) Document Information: document title, document author,
short plain-language description of technology discussed in the material (approx. 30
words), number of pages (or minutes of video) and document type (e.g., briefing, report,
abstract, article, or paper); (2) Event Information: event type (conference, principal
investigator meeting, article or paper), event date, desired date for DARPA's approval;
(3) DARPA Sponsor: DARPA Program Manager, DARPA office, and contract number;
and (4) Contractor/Awardee's Information: POC name, e-mail and phone. Allow four
weeks for processing; due dates under four weeks require a justification. Unusual
electronic file formats may require additional processing time. Requests may be sent
either by-mail to prc@darpa.mil or via 675 North Randolph Street, Arlington VA 22203-
2114, telephone (571) 218-4235. Refer to the following for link for information about
DARPA’s public release process:
http://www.darpa.mil/NewsEvents/Public_Release_Center/Public_Release_Center.aspx.

Sec. III: ELIGIBILITY INFORMATION

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

27
A. Eligible Applicants
1. Federally Funded Research and Development Centers (FFRDCs) and Government
entities (e.g., Government/National laboratories, military educational institutions, etc.)
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 and terms and conditions. This information is
required for FFRDCs proposing to be prime contractors or subcontractors. 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. 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 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 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. Procurement Integrity, Standards of Conduct, Ethical Considerations, and

Organizational Conflicts of Interest
Current federal employees are prohibited from participating in particular matters involving
conflicting financial, employment, and representational interests (18 U.S.C. §§ 203, 205, and
208). Once the proposals have been received, and prior to the start of proposal evaluations,
the Government will assess potential conflicts of interest and will promptly notify the
proposer if any appear to exist. The Government assessment does NOT affect, offset, or
mitigate the proposer’s responsibility to give full notice and planned mitigation for all
potential organizational conflicts, as discussed below.

Without prior approval or a waiver from the DARPA Director, in accordance with FAR
9.503, a contractor cannot simultaneously provide scientific, engineering, technical
assistance (SETA) or similar support and also be a technical performer. As part of the
proposal submission, all members of the proposed team (prime proposers, proposed
subcontractors, and consultants) must affirm whether they (their organizations and individual
team members) are providing SETA or similar support to any DARPA technical office(s)
through an active contract or subcontract. All affirmations must state which office(s) the
proposer, subcontractor, consultant, or individual supports and identify the prime contract
number(s). All facts relevant to the existence or potential existence of organizational
conflicts of interest (FAR 9.5) must be disclosed. The disclosure must include a description

28
 of the action the proposer has taken or proposes to take to avoid, neutralize, or mitigate such
conflict. If in the sole opinion of the Government after full consideration of the
circumstances, a proposal fails to fully disclose potential conflicts of interest and/or any
identified conflict situation cannot be effectively mitigated, the proposal will be rejected
without technical evaluation and withdrawn from further consideration for award.

If a prospective proposer believes a conflict of interest exists or may exist (whether

organizational or otherwise) or has questions on what constitutes a conflict of interest, the
proposer should send his/her contact information and a summary of the potential conflict to
the DARPA-BAA-14-16 mailbox before time and effort are expended in preparing a
proposal and mitigation plan.

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 (e.g., for any Other
Transactions under the authority of 10 U.S.C. §2371). Cost sharing is encouraged where
there is a reasonable probability of a potential commercial application related to the proposed
research and development effort.

Sec. IV: APPLICATION AND SUBMISSION INFORMATION

A. Address to Request Application Package

This solicitation contains all information required to submit a proposal. No additional forms,
kits, or other materials are needed. This notice constitutes the total solicitation. No additional
information is available, except as provided at FBO.gov or Grants.gov, nor will a formal
Request for Proposal (RFP) or additional solicitation regarding this announcement be issued.
Requests for the same will be disregarded.

B. Content and Form of Application Submission

1. Security and Proprietary Issues

NOTE: If proposals are classified, the proposals must indicate the classification level of
not only the proposal itself, but also the anticipated award document classification level.

The Government anticipates proposals submitted under this BAA will be unclassified.
However, if a proposal is submitted as “Classified National Security Information” as defined
by Executive Order 13526, then the information must be marked and protected as though
classified at the appropriate classification level and then submitted to DARPA for a final
classification determination.

Security classification guidance via a DD Form 254, “DoD Contract Security Classification
Specification,” will not be provided at this time, since DARPA is soliciting ideas only. After
reviewing the incoming proposals, if a determination is made that the award instrument may

29
 result in access to classified information; a DD Form 254 will be issued and attached as part
of the award.

Proposers choosing to submit a classified proposal from other classified sources must first
receive permission from the respective Original Classification Authority in order to use their
information in replying to this BAA. Applicable classification guide(s) should also be
submitted to ensure the proposal is protected at the appropriate classification level.

Classified submissions shall be appropriately and conspicuously marked with the proposed
classification level and declassification date. Submissions requiring DARPA to make a final
classification determination shall be marked as follows:

CLASSIFICATION DETERMINATION PENDING. Protect as though classified (insert the

recommended classification level: (e.g., Top Secret, Secret or Confidential)

Classified submissions shall be in accordance with the following guidance:

Confidential and Secret Collateral Information: Use classification and marking guidance
provided by previously issued security classification guides, the DoD Information Security
Manual (DoDM 5200.01, Volumes 1 - 4), and the National Industrial Security Program
Operating Manual (DoD 5220.22-M) when marking and transmitting information previously
classified by another Original Classification Authority. Classified information at the
Confidential and Secret level may be submitted via ONE of the two following methods:
1. Hand-carried by an appropriately cleared and authorized courier to the
DARPA CDR. Prior to traveling, the courier shall contact the DARPA
CDR at 703-526-4052 to coordinate arrival and delivery.

OR

2. Mailed via appropriate U.S. Postal Service methods (e.g., (USPS)

Registered Mail or USPS Express Mail). All classified information will be
enclosed in opaque inner and outer covers and double wrapped. The inner
envelope shall be sealed and plainly marked with the assigned
classification and addresses of both sender and addressee.

The inner envelope shall be addressed to:

Defense Advanced Research Projects Agency

ATTN: Kerry Bernstein/MTO
Reference: DARPA-BAA-14-16
675 North Randolph Street
Arlington, VA 22203-2114

The outer envelope shall be sealed with no identification as to the classification of its contents
and addressed to:

30
 Defense Advanced Research Projects Agency
Security & Intelligence Directorate, Attn: CDR
675 North Randolph Street
Arlington, VA 22203-2114

All Top Secret materials: Top Secret information should be hand carried by an appropriately
cleared and authorized courier to the DARPA CDR. Prior to traveling, the courier shall
contact the DARPA CDR at 703-526-4052 to coordinate arrival and delivery.

Special Access Program (SAP) Information: SAP information must be transmitted via
approved methods. Prior to transmitting SAP information, contact the DARPA SAPCO at
703-526-4052 for instructions.

Sensitive Compartmented Information (SCI): SCI must be transmitted via approved

methods. Prior to transmitting SCI, contact the DARPA Special Security Office (SSO) at 703-
526-4052 for instructions.

Proprietary Data: All proposals containing proprietary data should have the cover page and
each page containing proprietary data clearly marked as containing proprietary data. It is the
proposer’s responsibility to clearly define to the Government what is considered proprietary
data.

Proposers must have existing and in-place prior to execution of an award, approved capabilities
(personnel and facilities) to perform research and development at the classification level they
propose. It is the policy of DARPA to treat all proposals as competitive information, and to
disclose their contents only for the purpose of evaluation. Proposals will not be returned. The
original of each proposal received will be retained at DARPA and all other non-required copies
destroyed. A certification of destruction may be requested, provided the formal request is
received at this office within 5 days after unsuccessful notification.

2. Abstract Submission Information

Proposers who choose to use abstracts are strongly encouraged to submit an abstract in advance
of a full proposal. This procedure is intended to minimize unnecessary effort in proposal
preparation and review. The time and date for submission of abstracts is specified in Section 6
(Submission Dates and Times) below. DARPA will acknowledge receipt of the submission and
assign a control number that should be used in all further correspondence regarding the abstract.

Abstracts sent in response to DARPA-BAA-14-16 will be submitted through T-FIMS. See

https://baat.darpa.mil for more information on how to request an account, upload abstracts, and
use the T-FIMS tool. Because proposers using T-FIMS may encounter heavy traffic on the web
server, and T-FIMS requires a registration and certificate installation for all proposers, proposers
should not wait until the day the abstract is due to create an account in T-FIMS and submit the
abstract.

31
 3. Abstract Format

Abstracts are encouraged in advance of full proposals in order to provide potential proposers
with a rapid response to minimize unnecessary effort. Abstracts should follow the same general
format as described for Volume I under PROPOSAL FORMAT (see below), but include ONLY
Sections I and II. (However, no formal transmittal letter is required.) The cover sheet should be
clearly marked “ABSTRACT” and the total length should not exceed 12 pages, excluding cover
page and official transmittal letter. All pages shall be formatted with type not smaller than 12
point. Smaller font may be used for figures, tables and charts. The page limitation for abstracts
includes all figures, tables, and charts. No formal transmittal letter is required. All abstracts
must be written in English.

DARPA will respond to abstracts with a statement as to whether DARPA is interested in the
idea. DARPA will attempt to reply to abstracts in writing within thirty (30) calendar days of
receipt. If DARPA does not recommend the proposer submit a full proposal, DARPA will
provide detailed feedback to the proposer regarding the rationale for this decision. Regardless of
DARPA’s response to an abstract, proposers may submit a full proposal. DARPA will review all
full proposals submitted using the published evaluation criteria and without regard to any
comments resulting from the review of an abstract.

Required Sections for Abstract:

Cover sheet clearly marked “PROPOSAL ABSTRACT” to include:
(1) BAA number
(2) Technical area(s)/Advanced Study
(3) Lead Organization submitting proposal
(4) Type of business, selected among the following categories: “LARGE BUSINESS”, “SMALL
DISADVANTAGED BUSINESS”, “OTHER SMALL BUSINESS”, “HBCU”, “MI”, “OTHER
EDUCATIONAL”, OR “OTHER NONPROFIT”
(5) Contractor’s reference number (if any)
(6) Other team members (if applicable) and type of business for each
(7) Proposal title
(8) Technical point of contact to include: salutation, last name, first name, street address, city,
state, zip code, telephone, fax (if available), electronic mail (if available)
(9) Administrative point of contact to include: salutation, last name, first name, street address,
city, state, zip code, telephone, fax (if available), electronic mail (if available)
(10) Total funds requested from DARPA, and the amount of cost share (if any) AND
(11) Date proposal abstract was submitted.

4. Proposal Submission Information

The typical proposal should express a consolidated effort in support of one or more related
technical concepts or ideas. Disjointed efforts should not be included into a single proposal.
Proposals and abstracts may not be submitted by fax or e-mail; any so sent will be disregarded.
Proposals not meeting the format described in the BAA may not be reviewed.

32
Proposers requesting grants or cooperative agreements may submit proposals through one of the
following methods: (1) hard copy mailed directly to DARPA; or (2) electronic upload per the
instructions at http://www.grants.gov/applicants/apply-for-grants.html. Grant or cooperative
agreement proposals may not be submitted through any other means. If proposers intend to use
Grants.gov as their means of submission, then they must submit their entire proposal through
Grants.gov; applications cannot be submitted in part to Grants.gov and in part as a hard-copy.
Proposers using the Grants.gov APPLY do not submit paper proposals in addition to the
Grants.gov APPLY electronic submission.

Grants.gov requires proposers to complete a one-time registration process before a proposal can
be electronically submitted. If proposers have not previously registered, this process can take
between three business days and four weeks. See the Grants.gov registration checklist at
http://www.grants.gov/documents/19/18243/OrganizationRegChecklist.pdf for registration
requirements and instructions.

Once Grants.gov has received a proposal submission, Grants.gov will send two email messages
to advise proposers as to whether or not their proposals have been validated or rejected by the
system; IT MAY TAKE UP TO TWO DAYS TO RECEIVE THESE EMAILS. The first email
will confirm receipt of the proposal by the Grants.gov system; this email only confirms receipt,
not acceptance, of the proposal. The second will indicate that the application has been
successfully validated by the system prior to transmission to the grantor agency or has been
rejected due to errors. If the proposal is validated, then the proposer has successfully submitted
their proposal. If the proposal is rejected, the proposed must be corrected and resubmitted before
DARPA can retrieve it. If the solicitation is no longer open, the rejected proposal cannot be
resubmitted. Once the proposal is retrieved by DARPA, the proposer will receive a third email
from Grants.gov. To avoid missing deadlines, proposers should submit their proposals in
advance of the final proposal due date with sufficient time to receive confirmations and correct
any errors in the submission process through Grants.gov. For more information on submitting
proposals to Grants.gov, visit the Grants.gov submissions page at:
http://www.grants.gov/web/grants/applicants/apply-for-grants.html.

Proposers electing to submit grant or cooperative agreement proposals as hard copies must
complete the SF 424 R&R form (Application for Federal Assistance, Research and Related)
available on the Grants.gov website
http://apply07.grants.gov/apply/forms/sample/RR_SF424_2_0-V2.0.pdf Technical support for
Grants.gov submissions may be reached at 1-800-518-4726 or support@grants.gov.

All administrative correspondence and questions on this solicitation, including requests for
information on how to submit an abstract or full proposal to this BAA, should be directed to the
email address DARPA-BAA-14-16@darpa.mil. DARPA intends to use electronic mail and fax
for correspondence regarding DARPA-BAA-14-16. Proposals and abstracts may not be
submitted by fax or e-mail; any so sent will be disregarded. DARPA encourages use of the
Internet for retrieving the BAA and any other related information that may subsequently be
provided.

33
Proposals sent in response to DARPA-BAA-14-16 should be submitted through T-FIMS;
classified submissions and proposals requesting assistance instruments (grants or cooperative
agreements) should not be submitted through T-FIMS. See https://baat.darpa.mil for more
information on how to request an account, upload proposals, and use the T-FIMS tool. Because
proposers using T-FIMS may encounter heavy traffic on the web server, and T-FIMS requires a
registration and certificate installation for all proposers, proposers should not wait until the day
the proposal is due to create an account in T-FIMS and submit the proposal.

5. Full Proposal Format

All full proposals must be in the format given below. Nonconforming proposals may be rejected
without review. Proposals shall consist of two volumes. All pages shall be formatted 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. Volume I, Technical and
Management Proposal, may include an attached bibliography of relevant technical papers or
research notes (published and unpublished) which document the technical ideas and approach
upon which the proposal is based. Copies of not more than three (3) relevant papers may be
included with the submission. The bibliography and attached papers are not included in the page
counts given below. The submission of other supporting materials along with the proposals is
strongly discouraged and will not be considered for review. Full proposals, (consisting of
Section II and Section III of Volume I, Technical and Management Proposal), shall not exceed
30 pages. Proposals which offer solutions to less than all three technical areas shall not exceed
10 pages per technical area. All full proposals must be written in English.

A. Volume I, Technical and Management Proposal

Section I. Administrative
1. Cover sheet to include:
(1) BAA number (DARPA-BAA-14-16);
(2) Technical area;
(3) Lead Organization submitting proposal;
(4) Type of business, selected among the following categories: “LARGE BUSINESS”,
“SMALL DISADVANTAGED BUSINESS”, “OTHER SMALL BUSINESS”, “HBCU”, “MI”,
“OTHER EDUCATIONAL”, OR “OTHER NONPROFIT”;
(5) Proposer’s reference number (if any);
(6) Other team members (if applicable) and type of business for each;
(7) Proposal title;
(8) Technical point of contact to include: salutation, last name, first name, street address,
city, state, zip code, telephone, fax (if available), electronic mail (if available);
(9) Administrative point of contact to include: salutation, last name, first name, street
address, city, state, zip code, telephone, fax (if available), electronic mail (if available);
(10) Total funds requested from DARPA, and the amount of cost share (if any); AND
(11) Date proposal was submitted.

2. Official transmittal letter. (Note: An official transmittal letter is not required when
submitting an abstract.)

34
Section II. Summary of Proposal
1. Innovative claims for the proposed research. This section is the centerpiece of the
proposal and should succinctly describe the uniqueness and benefits of the proposed
approach relative to the current state-of-art alternate approaches.
2. Deliverables associated with the proposed research and the plans and capability to
accomplish technology transition and commercialization. Include in this section all
proprietary claims to the results, prototypes, intellectual property, or systems supporting
and/or necessary for the use of the research, results, and/or prototype. If there are no
proprietary claims, this should be stated. For forms to be completed regarding
intellectual property, see Section VIII. There will be no page limit for the listed forms.
3. Technical rationale, technical approach, and constructive plan for accomplishment of
technical goals in support of innovative claims and deliverable production. (In the full
proposal, this section should be supplemented by a more detailed plan in Section III.)
4. General discussion of other research in this area.
5. A clearly defined organization chart for the program team which includes, as applicable:
(1) the programmatic relationship of team member; (2) the unique capabilities of team
members; (3) the task of responsibilities of team members; (4) the teaming strategy
among the team members; and (5) the key personnel along with the amount of effort to be
expended by each person during each year.

Section III. Detailed Proposal Information

1. Statement of Work (SOW) - In plain English, clearly define the technical tasks/subtasks
to be performed, their durations, and dependencies among them. The page length for the
SOW will be dependent on the amount of the effort. The SOW must not include
proprietary information. For each task/subtask, provide:
a. A general description of the objective (for each defined task/activity);
b. A detailed description of the approach to be taken to accomplish each defined
task/activity);
c. Identification of the primary organization responsible for task execution (prime,
sub, team member, by name, etc.);
d. The completion criteria for each task/activity - a product, event or milestone that
defines its completion.
e. Define all deliverables (reporting, data, reports, software, etc.) to be provided to
the Government in support of the proposed research tasks/activities; and
f. Clearly identify any tasks/subtasks (prime or subcontracted) that will be
accomplished on-campus at a university.

Note: It is recommended that the SOW should be developed so that each Phase of the program is
separately defined.

2. Innovative Claims for the Proposed Research

This section should provide very specific details about the proposer’s suggested
embodiment which will provide a technical solution to the program’s goals. The proposer
should identify unique, key innovations that their offering would bring to the program,

35
 and why they provide a superior solution for the program’s goals. Evidence from earlier
works by the proposer supporting the suitability of the innovation to the program
application should be described, if available. It is critical that the submission
demonstrates that its offerings will satisfy all of the program’s stated boundary
conditions, and not just a subset. Proposers should provide a full description of any
additional infrastructure that would be needed to realize their preferred embodiment, and
whether that enablement exists or also needs to be developed in the execution of the
program.

3. Technical Rationale and Approach

This section is the centerpiece of the proposal and should enhance the description in
Section II A, outlining the scientific and technical challenges, unique approaches, and
potential anticipated technical solutions to the challenges that will be addressed. This
section should demonstrate that the proposer has a clear understanding of the state of the
art; and should provide sufficient technical details so as to permit complete evaluation of
the feasibility of the idea. At a minimum, this section should address the following:
a. Complete description of the proposed rapid design and prototyping facility to be
developed, including computational infrastructure, design tools, methods for
construction of genetic designs, assays for analysis, validation, and/or verification
of engineered systems, and feedback tools to inform future designs.
b. Complete description of the technical approach for accomplishing project goals
and milestones.
c. Major technical risk elements specific to the proposed technical and management
approach, estimate the risk magnitude for each such element, and describe
specific plans to mitigate risks.
d. Detailed list of and justification for at least 10 target molecules to be pursued in
Phase I, including relevance to DoD needs. For molecules that have previously
been synthesized biologically, provide quantitative metrics for improvement
relative to current state-of-the-art for biosynthesis of each product.
e. Description of the types of molecules that will be targeted in Phases II and III,
with justification for pursuing these classes of molecules and relevance to DoD
needs.
f. Description of how the proposed infrastructure can be used to address
applications beyond the biosynthesis of new molecules.
g. Description of potential impact if successful, including a list of quantitative
metrics and potential applications enabled by this technology.

4. Program Plan and Risk Assessment

All program metrics, milestones and deliverables should be summarized by the proposer
based on the offered solution. Proposers will be expected to fulfill each of the tasks listed
in the technical area(s) they are offering solutions in, and should specifically describe the
metrics they will use to measure their effectiveness, the dates when these achievements
will be demonstrated, and what specific deliverable will embody this achievement. The
submitted offering should describe the anticipated test methodology used to validate the
offered solution, and any insights that assure the solution is reliable. In proposals where
the proposer is offering solutions across multiple program phases and technical areas, the

36
 proposer should carefully indicate which phase and which technical area is satisfied by a
particular effort. Proposers are asked to highlight the exposures and risks that are
associated with their solutions, and those components of the solution for which no known
present capabilities yet exist. Proposals should identify specific technical milestones to be
achieved during the execution of their program, and to which technical areas and phases
those milestones contribute.

5. Other Research
Proposers should make evident what the prior art is for the capability they offer, and the
quantitative improvements that the development of their solution will provide.
Alternative potential technology options relating to the proposer’s concept which may
fulfill the goals of the program should be indicated, and why the offered solution
comprises the best solution, given the goals of the program (cost, security, reliability, die
size, power)

6. Teaming and Management Plan

A clearly defined organization chart for the program team which includes the
programmatic relationship and a summary of each member’s roles and responsibilities.
Additionally, a narrative discussing (1) the proposers teaming strategy/rationale; (2) the
specific roles and responsibilities of each of the team members and their respective
institutions; (3) the unique capabilities of the team members; (4) the proposers team
management approach; and (5) the key personnel along with the amount of effort to be
expended by each person during each Phase. This section should include a detailed
description of the formal teaming agreements required to execute this program, including
all academic, commercial, and non-profit collaborators and facility users. The teaming
and management plan should outline what equipment, tooling, and facilities will be
required by the collaboration, and how /where they will be accessed.

7. Technology Transition
Description of the results, products, transferable technology, and expected technology
transfer path enhancing that of Section II. B. This should also address mitigation of life-
cycle and sustainment risks associated with transitioning intellectual property for U.S.
military applications, if applicable. See also Section VIII. “Intellectual Property.”

8. Capabilities
A section describing relevant prior work, the background, qualifications and relevant
experience of team member organizations (prime and sub) and key individuals to be
assigned to the program, and the facilities and equipment to be utilized. Earlier successful
and failed attempts by the proposers to develop comparable technical capability should be
described. Earlier failures are not disqualifying inputs if the proposer can describe those
works, why they failed, and what was learned to improve chances of success when
attempted in the SHIELD program. Please do not attach supporting material to the
proposal, except as noted in Section IV. Additional Information below.

37
 9. Cost, Schedules, and Measurable Milestones
For the proposed research, include estimates of cost for each task in each year of the
effort delineated by the primes and major subcontractors, total cost, and any company
cost share. Note: Measureable milestones should capture key development points in tasks
and should be clearly articulated and defined in time relative to start of effort.

10. Summary Slides

PowerPoint slides summarizing the program and effort; download and use the template
provided in Attachment 2 posted with the subject BAA. Submit the PowerPoint (or
equivalent) file in addition to Volume I and Volume II of your full proposal.

Section IV. Additional Information

A brief bibliography of relevant technical papers and research notes (published and unpublished)
which document the technical ideas upon which the proposal is based. Copies of not more than
three (3) relevant papers can be included in the submission.

1. Volume II, Cost Proposal – {No Page Limit}

All proposers, including FFRDCs, must submit the following:

Cover sheet to include:
(1) BAA number (DARPA-BAA-14-16);
(2) Technical area;
(3) Lead Organization submitting proposal;
(4) Type of business, selected among the following categories: “LARGE BUSINESS”,
“SMALL DISADVANTAGED BUSINESS”, “OTHER SMALL BUSINESS”, “HBCU”, “MI”,
“OTHER EDUCATIONAL”, OR “OTHER NONPROFIT”;
(5) Proposer’s reference number (if any);
(6) Other team members (if applicable) and type of business for each;
(7) Proposal title;
(8) Technical point of contact to include: salutation, last name, first name, street address,
city, state, zip code, telephone, fax (if available), electronic mail (if available);
(9) Administrative point of contact to include: salutation, last name, first name, street
address, city, state, zip code, telephone, fax (if available), and electronic mail (if
available);
(10) Award instrument requested: cost-plus-fixed-fee (CPFF), cost-contract—no fee, cost
sharing contract – no fee, or other type of procurement contract (specify), grant,
cooperative agreement, or other transaction;
(11) Place(s) and period(s) of performance;
(12) Total proposed cost separated by basic award and option(s) (if any);
(13) Name, address, and telephone number of the proposer’s cognizant Defense Contract
Management Agency (DCMA) administration office (if known);
(14) Name, address, and telephone number of the proposer’s cognizant Defense Contract
Audit Agency (DCAA) audit office (if known);
(15) Date proposal was prepared;
(16) DUNS number;

38
 (17) TIN number;
(18) CAGE Code;
(19) Subcontractor Information; and
(20) Proposal validity period.

NOTE: Attachment 1, the Cost Volume Proposer Checklist, must be included with the
coversheet of the Cost Proposal. Nonconforming proposals may be rejected without review.

For proposers without a DCAA-approved cost accounting system who are proposing negotiation
of a cost-type contract, DCAA must complete an SF 1408 prior to award. To facilitate this
process, complete the SF 1408 found at http://www.gsa.gov/portal/forms/download/115778 and
submit the completed form with your proposal. Proposals requesting a cost-type contract
without this form may be deemed non-conforming to this solicitation. The Government
recognizes that this form is intended for an auditor to use when evaluating a contractor's cost
accounting system. However, your preliminary responses to the questions will expedite the
DCAA accounting system review. To complete the form, check the boxes on the second page,
then provide a narrative explanation of your accounting system to supplement the checklist on
page one.

The proposers’, to include eligible FFRDCs’, cost volume shall provide cost and pricing
information (See Note 1), or other than cost or pricing information if the total price is under
$700,000, in sufficient detail to substantiate the program price proposed (e.g., realism and
reasonableness). In doing so, the proposer shall provide for each technical area a summary cost
build-up by phase and performer fiscal year (providing visibility into the application of direct
and indirect rates); and a detailed cost build-up by phase (if multiple phases are proposed),
technical task/sub-task, and month. The breakdown shall include, at a minimum, the following
major cost item along with associated backup documentation:

Total program cost broken down by major cost items:

a. Direct Labor – a breakout clearly identifying the individual labor categories with
associated labor hours and direct labor rates, as well as a detailed Basis-of-
Estimate (BOE) narrative description of the methods used to estimate labor costs;
b. Indirect Costs – Including Fringe Benefits, Overhead, General and Administrative
Expense, Cost of Money, Fee, etc. (must show base amount and rate);
c. Travel – Provide the purpose of the trip, number of trips, number of days per trip,
departure and arrival destinations, number of people, etc.;
d. Other Direct Costs – Itemized with costs; Back-up documentation is to be
submitted to support proposed costs;
e. Material/Equipment –
(i) A priced Bill-of-Material (BOM) clearly identifying, for each item proposed,
the quantity, unit price, the source of the unit price (i.e., vendor quote,
engineering estimate, etc.), the type of property (i.e., material, equipment, special
test equipment, information technology, etc.), and a cross-reference to the
Statement of Work (SOW) task/s that require the item/s. At time of proposal
submission, any item that exceeds $1,000 must be supported with basis-of-
estimate (BOE) documentation such as a copy of catalog price lists, vendor quotes

39
 or a written engineering estimate (additional documentation may be required
during negotiations, if selected).
(ii) If seeking a procurement contract and items of Contractor Acquired Property
are proposed, exclusive of material, the proposer shall clearly demonstrate that the
inclusion of such items as Government Property is in keeping with the
requirements of FAR Part 45.102. In accordance with FAR 35.014, “Government
property and title,” it is the Government’s intent that title to all equipment
purchased with funds available for research under any resulting contract will vest
in the acquiring nonprofit institution (e.g., Nonprofit Institutions of Higher
Education and Nonprofit Organizations whose primary purpose is the conduct of
scientific research) upon acquisition without further obligation to the
Government. Any such equipment shall be used for the conduct of basic and
applied scientific research. The above transfer of title to all equipment purchased
with funds available for research under any resulting contract is not allowable
when the acquiring entity is a for-profit organization; however, such organizations
can, in accordance with FAR 52.245-1(j), be given priority to acquire such
property at its full acquisition cost.
f. Consultants – If consultants are to be used, proposer must provide a copy of the
consultant’s proposed SOW as well as a signed consultant agreement or other
document which verifies the proposed loaded daily / hourly rate and any other
proposed consultant costs (e.g. travel);
g. Subcontracts – Itemization of all subcontracts. Additionally, the prime contractor
is responsible for compiling and providing, as part of its proposal submission to
the Government, subcontractor proposals prepared at the same level of detail as
that required by the prime. Subcontractor proposals include Interdivisional Work
Transfer Agreements (ITWA) or similar arrangements. If seeking a procurement
contract, the prime contractor shall provide a cost reasonableness analysis of all
proposed subcontractor costs/prices. Such analysis shall indicate the extent to
which the prime contractor has negotiated subcontract costs/prices and whether
any such subcontracts are to be placed on a sole-source basis. All proprietary
subcontractor proposal documentation which cannot be uploaded to TFIMS or
Grants.gov as part of the proposer’s submission, shall be made immediately
available to the Government, upon request, under separate cover (i.e., mail,
electronic/email, etc.), either by the proposer or by the subcontractor organization
– this does not relieve the proposer from the requirement to include, as part of
their submission (via TFIMS, Grants.gov or Hardcopy, as applicable), subcontract
proposals that do not include proprietary pricing information (rates, factors, etc.);
h. The source, nature, and amount of any industry cost-sharing;
i. Written justification required per Section VI(B)(4) pertaining to subcontracted
effort being considered Contracted Fundamental Research; and
j. Small Business Subcontracting Plan, if applicable. See Section VI(B)(6)
“Subcontracting” below.

40
Proposers are required to provide the aforementioned cost breakdown as an editable MS Excel
spreadsheet, inclusive of calculations formulae, with tabs (material, travel, ODC’s) provided as
necessary. The Government also requests and recommends that the Cost Proposal include MS
Excel file(s) that provide traceability between the Bases of Estimate (BOEs) and the proposed
costs across all elements and phases. This includes the calculations and adjustments that are
utilized to generate the Summary Costs from the source labor hours, labor costs, material costs,
etc. input data. It is requested that the costs and Subcontractor proposals be readily traceable to
the Prime Cost Proposal in the provided MS Excel file(s) – although this is not a requirement,
providing information in this manner will assist the Government in understanding what is being
proposed both technically and in terms of cost realism.

Where the effort consists of multiple portions which could reasonably be partitioned for purposes
of funding, these should be identified as options with separate cost estimates. For IT and
equipment purchases, include a letter stating why the proposer cannot provide the requested
resources from its own funding.

The cost proposal should include identification of pricing assumptions of which may require
incorporation into the resulting award instrument (i.e., use of Government Furnished
Property/Facilities/Information, access to Government Subject Matter Experts, etc.).

Supporting cost and pricing information in sufficient detail to substantiate the summary cost
estimates in B. above. Include a description of the method used to estimate costs and supporting
documentation.

Note 1:
(a) “Cost or Pricing Data” as defined in FAR Subpart 15.4 shall be required if the proposer is
seeking a procurement contract award of $700,000 or greater unless the proposer requests an
exception from the requirement to submit cost or pricing data. Per DFARS 215.408(5),
DFARS 252.215-7009, Proposal Adequacy Checklist, applies to all proposers/proposals
seeking a FAR-based award (contract).
(b) In accordance with DFARS 15.403-1(4)(D), DoD has waived cost or pricing data
requirements for nonprofit organizations (including educational institutions) on cost-
reimbursement-no-fee contracts. In such instances where the waiver stipulated at DFARs
15.403-1(4)(D) applies, proposers shall submit information other than cost or pricing data to
the extent necessary for the Government to determine price reasonableness and cost realism;
and cost or pricing data from subcontractors that are not nonprofit organizations when the
subcontractor’s proposal exceeds the cost and pricing data threshold at FAR 15.403-4(a)(1).
(c) “Cost or pricing data” are not required if the proposer proposes an award instrument other
than a procurement contract (i.e., cooperative agreement, grant, or other transaction
agreement).

PLEASE NOTE, 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.

41
6. Submission Dates and Times

A. Abstract Date
The abstract must be submitted per the instructions outlined herein on or before April 1, 2014.
Abstracts received after this time and date may not be reviewed.

B. Full Proposal Date :

The full proposal must be submitted per the instructions outlined herein on or before, May 30,
2014, in order to be considered during the initial round of selections; however, proposals
received after this deadline may be received and evaluated up to six months (180 days) from date
of posting on FedBizOpps. Full proposals submitted after the due date specified in the BAA or
due date otherwise specified by DARPA after review of abstracts may be selected contingent
upon the availability of funds. Proposers are warned that the likelihood of available funding is
greatly reduced for proposals submitted after the initial closing date deadline. Failure to comply
with the submission procedures may result in the submission not being evaluated.

DARPA will acknowledge receipt of complete submissions via email and assign control numbers
that should be used in all further correspondence regarding proposals.

DARPA will post on a regular basis a consolidated Question and Answer (FAQ) document.
To access the posting go to
http://www.darpa.mil/Opportunities/Solicitations/MTO_Solicitations.aspx (the MTO office
solicitations page) and select “DARPA-BAA-14-16.” The link will direct you to the SHIELD
overview page and the FAQ will be posted in a PDF accessible file under the “Important Links”
section. Submit your question/s by E-mail to DARPA-BAA-14-16@darpa.mil. In order to
receive a response sufficiently in advance of the proposal due date, send your question/s by no
later than May 9, 2014.

7. Funding Restrictions

Not applicable.

Sec. V: APPLICATION REVIEW INFORMATION

A. Evaluation Criteria
Proposals will be evaluated using the following criteria, listed in descending order of importance:
(1) Overall Scientific and Technical Merit; (2) Potential Contribution and Relevance to the
DARPA Mission; (3) Proposer’s Capabilities and/or Related Experience; (4) Plans and
Capability to Accomplish Technology Transition; and (5) Cost Realism.

(1) Overall Scientific and Technical Merit

The proposed technical approach is feasible, achievable, complete and supported by a proposed
technical team that has the expertise and experience to accomplish the proposed tasks. Task
descriptions and associated technical elements provided are complete and in a logical sequence
with all proposed deliverables clearly defined such that a final outcome that achieves the goal

42
can be expected as a result of award. The proposal identifies major technical risks and planned
mitigation efforts are clearly defined and feasible.

(2) Potential Contribution and Relevance to the DARPA Mission

The potential contributions of the proposed effort are relevant to the national technology base.
Specifically, DARPA’s mission is to maintain the technological superiority of the U.S. military
and prevent technological surprise from harming national security by sponsoring revolutionary,
high-payoff research that bridges the gap between fundamental discoveries and their application.

(3) Proposer’s Capabilities and/or Related Experience

The proposer's prior experience in similar efforts clearly demonstrates an ability to deliver
products that meet the proposed technical performance within the proposed budget and schedule.
The proposed team has the expertise to manage the cost and schedule. Similar efforts
completed/ongoing by the proposer in this area are fully described including identification of
other Government sponsors.

(4) Plans and Capability to Accomplish Technology Transition

The proposer clearly demonstrates its capability to transition the technology to the research,
industrial, and/or operational military communities in such a way as to enhance U.S. defense. In
addition, the evaluation will take into consideration the extent to which the proposed intellectual
property (IP) rights will potentially impact the Government’s ability to transition the technology.

(5) Cost Realism

The objective of this criterion is to establish that the proposed costs are realistic for the technical
and management approach offered, as well as to determine the proposer’s practical
understanding of the effort. The proposal will be reviewed to determine if the costs proposed are
based on realistic assumptions, reflect a sufficient understanding of the technical goals and
objectives of the BAA, and are consistent with the proposer’s technical approach (to include the
proposed Statement of Work). At a minimum, this will involve review, at the prime and
subcontract level, of the type and number of +-labor hours proposed per task as well as the types
and kinds of materials, equipment and fabrication costs proposed. It is expected that the effort
will leverage all available relevant prior research in order to obtain the maximum benefit from
the available funding. For efforts with a likelihood of commercial application, appropriate direct
cost sharing may be a positive factor in the evaluation. The evaluation criterion recognizes that
undue emphasis on cost may motivate proposers to offer low-risk ideas with minimum
uncertainty and to staff the effort with junior personnel in order to be in a more competitive
posture. DARPA discourages such cost strategies.

B. Review and Selection Process

Evaluation of proposals will be accomplished through a scientific/technical review of each

conforming proposal. Proposals will not be evaluated against each other since they are not
submitted in accordance with a common work statement. DARPA’s intent is to review proposals
as soon as possible after they arrive; however, proposals may be reviewed periodically for
administrative reasons.

43
Award(s) will be made to proposers whose proposals are determined to be the most
advantageous to the Government, all factors considered, including the potential contributions
of the proposed work to the overall research program and the availability of funding for the
effort.

It is the policy of DARPA to ensure impartial, equitable, comprehensive proposal evaluations

and to select the source (or sources) whose offer meets the Government's technical, policy, and
programmatic goals. Pursuant to FAR 35.016, the primary basis for selecting proposals for
acceptance shall be technical, importance to agency programs, and fund availability. In order to
provide the desired evaluation, qualified Government personnel will conduct reviews and (if
necessary) convene panels of experts in the appropriate areas.

For evaluation purposes, a proposal is the document described in “Proposal Information”,

Section IV.B. Other supporting or background materials submitted with the proposal will be
considered for the reviewer's convenience only and not considered as part of the proposal.

Restrictive notices notwithstanding, proposals may be handled for administrative purposes by

support contractors. These support contractors are prohibited from competition in DARPA
technical research and are bound by appropriate non-disclosure requirements.

Subject to the restrictions set forth in FAR 37.203(d), input on technical aspects of the proposals
may be solicited by DARPA from non-Government consultants /experts who are strictly bound
by the appropriate non-disclosure requirements.

Sec. VI: AWARD ADMINISTRATION INFORMATION

A. Selection Notices
As soon as the evaluation of a proposal is complete, the proposer will be notified that (1) the
proposal has been selected for funding pending contract negotiations, or (2) the proposal has not
been selected. These official notifications will be sent via email to the Technical POC and/or
Administrative POC identified on the proposal coversheet.

B. Administrative and National Policy Requirements

1. Meeting and Travel Requirements

There will be a program kickoff meeting and all key participants are required to attend.
Performers should also anticipate regular program-wide PI Meetings and periodic site visits at
the Program Manager’s discretion.

2. Human Subjects Research

All research selected for funding involving human subjects, to include use of human biological
specimens and human data, must comply with the federal regulations for human subjects
protection. Further, research involving human subjects that is conducted or supported by the

44
DoD must comply with 32 CFR 219, Protection of Human Subjects (and DoD Instruction
3216.02, Protection of Human Subjects and Adherence to Ethical Standards in DoD-Supported
Research (http://www.dtic.mil/whs/directives/corres/pdf/321602p.pdf).

Institutions awarded funding for research involving human subjects must provide documentation
of a current Assurance of Compliance with Federal regulations for human subjects protection,
such as a Department of Health and Human Services, Office of Human Research Protection
Federal Wide Assurance (http://www.hhs.gov/ohrp). All institutions engaged in human subjects
research, to include subcontractors, must also hold a valid Assurance. In addition, all personnel
involved in human subjects research must provide documentation of completion of human
subjects research training.

For all proposed research that will involve human subjects in the first year or phase of the
project, the institution must provide evidence of or a plan for review by an Institutional Review
Board (IRB) upon final proposal submission to DARPA as part of their proposal, prior to being
selected for funding. The IRB conducting the review must be the IRB identified on the
institution’s Assurance of Compliance with human subjects protection regulations. The protocol,
separate from the proposal, must include a detailed description of the research plan, study
population, risks and benefits of study participation, recruitment and consent process, data
collection, and data analysis. It is recommended that you consult the designated IRB for
guidance on writing the protocol. The informed consent document must comply with federal
regulations (32 CFR 219.116). A valid Assurance of Compliance with human subjects
protection regulations along with evidence of completion of appropriate human subjects research
training by all investigators and personnel involved with human subjects research should
accompany the protocol for review by the IRB.

In addition to a local IRB approval, a headquarters-level human subjects administrative review

and approval is required for all research conducted or supported by the DoD. The Army, Navy,
or Air Force office responsible for managing the award can provide guidance and information
about their component’s headquarters-level review process. Note that confirmation of a current
Assurance of Compliance with human subjects protection regulations and appropriate human
subjects research training is required before headquarters-level approval can be issued.

The time required to complete the IRB review/approval process varies depending on the
complexity of the research and the level of risk involved with the study. The IRB approval
process can last between one and three months, followed by a DoD review that could last
between three and six months. Ample time should be allotted to complete the approval process.
DoD/DARPA funding cannot be used towards human subjects research until ALL approvals are
granted.

3. Animal Use

Award recipients performing research, experimentation, or testing involving the use of animals
shall comply with the rules on animal acquisition, transport, care, handling, and use as outlined
in: (i) 9 CFR parts 1-4, Department of Agriculture rules that implement the Animal Welfare Act
of 1966, as amended, (7 U.S.C. § 2131-2159); (ii) National Institutes of Health Publication No.

45
86-23, "Guide for the Care and Use of Laboratory Animals" (8th Edition); (iii) DoD Instruction
3216.01, “Use of Animals in DoD Programs.”

For projects anticipating animal use, proposals should briefly describe plans for Institutional
Animal Care and Use Committee (IACUC) review and approval. Animal studies in the program
will be expected to comply with the Public Health Service (PHS) Policy on Humane Care and
Use of Laboratory Animals, available at http://grants.nih.gov/grants/olaw/olaw.htm.

All award recipients must receive approval by a DoD-certified veterinarian, in addition to an

IACUC approval. No animal studies may be conducted using DoD/DARPA funding until the
United States Army Medical Research and Materiel Command (USAMRMC) Animal Care and
Use Review Office (ACURO) or other appropriate DoD veterinary office(s) grant approval. As
a part of this secondary review process, the award recipient will be required to complete and
submit an ACURO Animal Use Appendix, which may be found at https://mrmc-
www.army.mil/index.cfm?pageid=Research_Protections.acuro&rn=1.

4. Export Control

Per DFARS 225.7901-4, all procurement contracts, other transactions and other awards, as
deemed appropriate, resultant from this solicitation will include the DFARS Export Control
clause (252.225-7048).

5. Subcontracting

Pursuant to Section 8(d) of the Small Business Act (15 U.S.C. § 637(d)), it is the policy of the
Government to enable small business and small disadvantaged business concerns to be
considered fairly as subcontractors to contractors performing work or rendering services as prime
contractors or subcontractors under Government contracts, and to assure that prime contractors
and subcontractors carry out this policy. Each proposer who submits a contract proposal and
includes subcontractors is required to submit a subcontracting plan in accordance with FAR
19.702(a)(1) should do so with their proposal. The plan format is outlined in FAR 19.704.

6. Electronic and Information Technology

All electronic and information technology acquired through this solicitation must satisfy the
accessibility requirements of Section 508 of the Rehabilitation Act (29 U.S.C. § 794d) and FAR
39.2. Each proposer who submits a proposal involving the creation or inclusion of electronic and
information technology must ensure that federal employees with disabilities will have access to
and use of information that is comparable to the access and use by Federal employees who are
not individuals with disabilities and members of the public with disabilities seeking information
or services from DARPA will have access to and use of information and data that is comparable
to the access and use of information and data by members of the public who are not individuals
with disabilities.

46
 7. Employment Eligibility Verification

As per FAR 22.1802, recipients of FAR-based procurement contracts must enroll as federal
contractors in E-verify and use the system to verify employment eligibility of all employees
assigned to the award. All resultant contracts from this solicitation will include FAR 52.222-54,
“Employment Eligibility Verification.” This clause will not be included in grants, cooperative
agreements, or Other Transactions.

In accordance with FAR 1.108(d), the following clause will be used in all contracts performed in
Iraq or Afghanistan. Such contracts are defined as “contracts with the Department of Defense, a
subcontract at any tier issued under such a contract, or a task order or delivery order at any tier
issued under such contract, including a contract, subcontract, or task order or delivery order
issued by another Government agency for the Department of Defense, if the contract,
subcontract, or task order or delivery order involves work performed in Iraq or Afghanistan for a
period longer than 14 days.”

(a) The Contractor shall report to the appropriate investigative authorities, identified in paragraph
(c) below, any alleged offenses under—

(1) The Uniform Code of Military Justice (chapter 47 of title 10, United States code) (applicable
to contractors serving with or accompanying an armed force in the field during a declared war or
a contingency operation); or

(2) The Military Extraterritorial Jurisdiction Act (chapter 212 of title 18, United States Code).

(b) The Contractor shall provide to all contractor personnel who will perform work on a contract
in Iraq or Afghanistan, before beginning such work, information on the following:

(1) How and where to report an alleged crime described in paragraph (a) of this clause.

(2) Where to seek victim and witness protection and assistance available to contractor personnel
in connection with an alleged offense described in paragraph (a) of this clause.

(c) The appropriate investigative authorities to which suspected crimes shall be reported include
the following officials –
(i) US Army Criminal Investigations Division at
http://www.cid.army.mil/reportacrime.html
(ii) Air Force Office of Special Investigations at
http://www.osi.andrews.af.mil/library/factsheets/factsheet.asp?id=14522
(iii) Navy Criminal Investigative Service at
http://www.ncis.navy.mil/Pages/publicdefault.aspx; or
(iv) To the command of any supported military element or the command of any base.

(d) Personnel seeking whistleblower protection from reprisals for reporting criminal acts shall
seek guidance through the DoD Inspector General hotline at (800) 424-9098 or

47
www.dodig.mil/HOTLINE/index.html. Personnel seeking other forms of victim or witness
protections should contact the nearest military law enforcement office.

8. System for Award Management (SAM) Registration and Universal Identifier

Requirements

Unless the proposer is exempt from this requirement, as per FAR 4.1102 or 2 CFR 25.110 as
applicable, all proposers must be registered in the System for Award Management (SAM) and
have a valid Data Universal Numbering System (DUNS) number prior to submitting a proposal.
All proposers must maintain an active registration in SAM with current information at all times
during which they have an active Federal award or proposal under consideration by DARPA.
All proposers must provide the DUNS number in each proposal they submit.

Information on SAM registration is available at www.sam.gov.

9. Reporting Executive Compensation and First-Tier Subcontract Awards

FAR clause 52.204-10, “Reporting Executive Compensation and First-Tier Subcontract

Awards,” will be used in all procurement contracts valued at $25,000 or more. A similar award
term will be used in all grants and cooperative agreements.

10. Updates of Information Regarding Responsibility Matters

Per FAR 9.104-7(c), FAR clause 52.209-9, Updates of Publicly Available Information
Regarding Responsibility Matters, will be included in all contracts valued at $500,000 or more
where the contractor has current active Federal contracts and grants with total value greater than
$10,000,000.

11. Representation by Corporations Regarding an Unpaid Delinquent Tax Liability or

a Felony Conviction under any Federal Law—Fiscal Year 2014 Appropriations
(Deviation 2014-OO00009)

(a) In accordance with sections 8113 and 8114 of the Department of Defense
Appropriations Act, 2014, and sections 414 and 415 of the Military Construction and
Veterans Affairs and Related Agencies Appropriations Act, 2014 (Public Law 113-76,
Divisions C and J), none of the funds made available by those divisions (including
Military Construction funds) may be used to enter into a contract with any corporation
that --

(1) Has any unpaid Federal tax liability that has been assessed, for which all
judicial and administrative remedies have been exhausted or have lapsed, and that is not
being paid in a timely manner pursuant to an agreement with the authority responsible for
collecting the tax liability, where the awarding agency is aware of the unpaid tax liability,
unless the agency has considered suspension or debarment of the corporation and made a

48
 determination that this further action is not necessary to protect the interests of the
Government; or

(2) Was convicted of a felony criminal violation under any Federal law within the
preceding 24 months, where the awarding agency is aware of the conviction, unless the
agency has considered suspension or debarment of the corporation and made a
determination that this action is not necessary to protect the interests of the Government.

(b) The Offeror represents that –

(1) It is [ ] is not [ ] a corporation that has any unpaid Federal tax liability that has
been assessed, for which all judicial and administrative remedies have been exhausted or
have lapsed, and that is not being paid in a timely manner pursuant to an agreement with
the authority responsible for collecting the tax liability,

(2) It is [ ] is not [ ] a corporation that was convicted of a felony criminal violation

under a Federal law within the preceding 24 months.

12. Cost Accounting Standards (CAS) Notices and Certification

As per FAR 52.230-2, any procurement contract in excess of $700,000 resulting from this
solicitation will be subject to the requirements of the Cost Accounting Standards Board (48 CFR
99), except those contracts which are exempt as specified in 48 CFR 9903.201-1. Any proposer
submitting a proposal which, if accepted, will result in a CAS compliant contract, must submit
representations and a Disclosure Statement as required by 48 CFR 9903.202 detailed in FAR
52.230-2. The disclosure forms may be found at
http://www.whitehouse.gov/omb/procurement_casb.

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

Controlled Unclassified Information (CUI) refers to unclassified information that does not
meet the standards for National Security Classification but is pertinent to the national interests
of the United States or to the important interests of entities outside the Federal Government and
under law or policy requires protection from unauthorized disclosure, special handling
safeguards, or prescribed limits on exchange or dissemination. All non-DoD entities doing
business with DARPA are expected to adhere to the following procedural safeguards, in
addition to any other relevant Federal or DoD specific procedures, for submission of any
proposals to DARPA and any potential business with DARPA:

 Do not process DARPA CUI on publicly available computers or post DARPA

CUI to publicly available webpages or websites that have access limited only by
domain or Internet protocol restriction.
 Ensure that all DARPA CUI is protected by a physical or electronic barrier when
not under direct individual control of an authorized user and limit the transfer or
DARPA CUI to subcontractors or teaming partners with a need to know and
commitment to this level of protection.

49
  Ensure that DARPA CUI on mobile computing devices is identified and
encrypted and all communications on mobile devices or through wireless
connections are protected and encrypted.
 Overwrite media that has been used to process DARPA CUI before external
release or disposal.

14. Safeguarding of Unclassified Controlled Technical Information (This applies only

to FAR-based awards.)
Per DFARS 204.7303, DFARS 252.204-7012, Safeguarding of Unclassified Controlled
Technical Information, applies to this solicitation and all FAR-based awards resulting
from this solicitation.

C. Reporting

The number and types of reports will be specified in the award document, but will include as a
minimum monthly/quarterly financial status reports. The reports shall be prepared and submitted
in accordance with the procedures contained in the award document and mutually agreed on
before award. Reports and briefing material will also be required as appropriate to document
progress in accomplishing program metrics. A Final Report that summarizes the project and
tasks will be required at the conclusion of the performance period for the award, notwithstanding
the fact that the research may be continued under a follow-on vehicle.

D. Electronic Systems

1. Representations and Certifications

In accordance with FAR 4.1201, prospective proposers shall complete electronic annual
representations and certifications atwww.sam.gov.

2. Wide Area Work Flow (WAWF)

Unless using another means of invoicing, performers will be required to submit invoices for
payment directly to https://wawf.eb.mil. Registration in WAWF will be required prior to any
award under this BAA.

Sec. VII: AGENCY CONTACTS

Indicate here if there is a preferred method of communication (email, fax, U.S. Mail, etc).

Administrative, technical, or contractual questions should be sent via e-mail to DARPA-BAA-

14-16. All requests must include the name, email address, and phone number of a point of
contact.

The technical POC for this effort is Kerry Bernstein

The BAA Coordinator for this effort can be reached at

50
 DARPA/MTO
ATTN: DARPA-BAA-14-16
675 North Randolph Street
Arlington, VA 22203-2114
DARPA-BAA-14-16@darpa.mil

Sec. VIII. OTHER INFORMATION

A. Intellectual Property Procurement Contract Proposers

1. Noncommercial Items (Technical Data and Computer Software)

Proposers responding to this BAA requesting a procurement contract to be issued under the
FAR/DFARS shall identify all noncommercial technical data and noncommercial computer
software that it plans to generate, develop, and/or deliver under any proposed award instrument
in which the Government will acquire less than unlimited rights, and to assert specific
restrictions on those deliverables. Proposers shall follow the format under DFARS 252.227-
7017 for this stated purpose. In the event that proposers do not submit the list, the Government
will assume that it automatically has “unlimited rights” to all noncommercial technical data and
noncommercial computer software generated, developed, and/or delivered under any award
instrument, unless it is substantiated that development of the noncommercial technical data and
noncommercial computer software occurred with mixed funding. If mixed funding is anticipated
in the development of noncommercial technical data and noncommercial computer software
generated, developed, and/or delivered under any award instrument, then proposers should
identify the data and software in question, as subject to Government Purpose Rights (GPR). In
accordance with DFARS 252.227-7013 Rights in Technical Data - Noncommercial Items, and
DFARS 252.227-7014 Rights in Noncommercial Computer Software and Noncommercial
Computer Software Documentation, the Government will automatically assume that any such
GPR restriction is limited to a period of five (5) years in accordance with the applicable DFARS
clauses, at which time the Government will acquire “unlimited rights” unless the parties agree
otherwise. Proposers are advised that the Government will use the list during the evaluation
process to evaluate the impact of any identified restrictions and may request additional
information from the proposer, as may be necessary, to evaluate the proposer’s assertions. If no
restrictions are intended, then the proposer should state “NONE.” It is noted an assertion of
“NONE” indicates that the Government has “unlimited rights” to all noncommercial technical
data and noncommercial computer software delivered under the award instrument, in accordance
with the DFARS provisions cited above. Failure to provide full information may result in a
determination that the proposal is not compliant with the BAA – resulting in nonselectability of
the proposal.

A sample list for complying with this request is as follows:

51
 NONCOMMERCIAL
Technical Data Summary of Basis for Basis for Assertion Name of Person
Computer Software Intended Use in the Assertion Asserting
To be Furnished Conduct of the Restrictions
With Restrictions Research
(LIST) (NARRATIVE) (LIST) (LIST) (LIST)

2. Commercial Items (Technical Data and Computer Software)

Proposers responding to this BAA requesting a procurement contract to be issued under the
FAR/DFARS shall identify all commercial technical data and commercial computer software
that may be embedded in any noncommercial deliverables contemplated under the research
effort, along with any applicable restrictions on the Government’s use of such commercial
technical data and/or commercial computer software. In the event that proposers do not submit
the list, the Government will assume that there are no restrictions on the Government’s use of
such commercial items. The Government may use the list during the evaluation process to
evaluate the impact of any identified restrictions and may request additional information from
the proposer, as may be necessary, to evaluate the proposer’s assertions. If no restrictions are
intended, then the proposer should state “NONE.” Failure to provide full information may result
in a determination that the proposal is not compliant with the BAA – resulting in nonselectability
of the proposal.

COMMERCIAL
Technical Data Summary of Basis for Basis for Assertion Name of Person
Computer Software Intended Use in the Assertion Asserting
To be Furnished Conduct of the Restrictions
With Restrictions Research
(LIST) (NARRATIVE) (LIST) (LIST) (LIST)

A sample list for complying with this request is as follows:

B. Non-Procurement Contract Proposers – Noncommercial and Commercial Items

(Technical Data and Computer Software)

Proposers responding to this BAA requesting a Grant, Cooperative Agreement, Technology

Investment Agreement, or Other Transaction for Prototype shall follow the applicable rules and
regulations governing these various award instruments, but in all cases should appropriately
identify any potential restrictions on the Government’s use of any Intellectual Property
contemplated under those award instruments in question. This includes both Noncommercial
Items and Commercial Items. Although not required, proposers may use a format similar to that
described in Paragraphs 1.a and 1.b above. The Government may use the list during the
evaluation process to evaluate the impact of any identified restrictions, and may request
additional information from the proposer, as may be necessary, to evaluate the proposer’s
assertions. If no restrictions are intended, then the proposer should state “NONE.” Failure to
provide full information may result in a determination that the proposal is not compliant with the
BAA – resulting in nonselectability of the proposal.

52
 C. All Proposers – Patents

Include documentation proving your ownership of or possession of appropriate licensing rights

to all patented inventions (or inventions for which a patent application has been filed) that will be
utilized under your proposal for the DARPA program. If a patent application has been filed for
an invention that your proposal utilizes, but the application has not yet been made publicly
available and contains proprietary information, you may provide only the patent number,
inventor name(s), assignee names (if any), filing date, filing date of any related provisional
application, and a summary of the patent title, together with either: (1) a representation that you
own the invention, or (2) proof of possession of appropriate licensing rights in the invention.

D. All Proposers – Intellectual Property Representations

Provide a good faith representation that you either own or possess appropriate licensing rights to
all other intellectual property that will be utilized under your proposal for the DARPA program.
Additionally, proposers shall provide a short summary for each item asserted with less than
unlimited rights that describes the nature of the restriction and the intended use of the intellectual
property in the conduct of the proposed research

E. Other Transactions (OTs):

DARPA is able to obtain its research support through a variety of legal instruments and flexible
arrangements, to include use of Other Transaction Agreements (OTAs). OTAs are potentially
applicable to a wide variety of DARPA programs. They are likely to be particularly applicable to
support dual-use technologies (those with commercial nonmilitary potential as well as potential
military applications), consortia or multi-party agreements, and work supported by multiple
funding sources. Because OTAs are not traditional procurement contracts, DARPA is not
required to include the traditional FAR and DFARS clauses in these agreements, but is free to
negotiate provisions that are mutually agreeable to both the Government and the consortium of
companies entering into the agreement. Proposals may, but need not, state that an OTA rather
than a contract or grant is desired. Furthermore, DARPA does not enter into OTAs when a
contract or grant is feasible or appropriate. See FAR 35.003 for Government-wide policy on use
of contracts for research and development. Potential proposers are encouraged to visit the
DARPA Contracts Management page
(http://www.darpa.mil/Opportunities/Contract_Management/Contract_Management.aspx) for
more information regarding the use of OTAs.

Transactions for Research and Other Transactions for Prototype Projects (a.k.a “845s”). Of these
two types of OTAs, the one most pertinent to this BAA is referred to as a Technology Investment
Agreement (TIA) and is issued in accordance with Part 37 of the Department of Defense Grant
and Agreement Regulations (DODGARs)(http://www.gpo.gov/fdsys/granule/CFR-2008-title32-
vol1/CFR-2008-title32-vol1-part21/content-detail.html). TIAs are assistance instruments used to
stimulate or support research designed to: (a) reduce barriers to commercial firm’s participation
in defense research, to give the Department of Defense (DoD) access to the broadest possible
technology and industrial base; (b) promote new relationships among performers in both the
defense and commercial sectors of that technology and industrial base; and (c) stimulate

53
performers to develop, use, and disseminate improved practices. As a matter of DoD policy, a
TIA may be awarded only when one or more for-profit firms are to be involved either in the (1)
performance of the research project; or (2) the commercial application of the research results
(e.g. commercial transition partner). Also of importance is the requirement that, to the maximum
extent practicable, the non-Federal parties carrying out a research project under a TIA are to
provide at least half of the costs of the project – this being a statutory condition for any TIA, or
Other Transaction Agreement in general, issued under the authority of 10 U.S.C. 2371. Such
instruments can involve a single performer or multiple performers participating as a consortium
(which are not required to operate as a separate legal entity) and the Generally Accepted
Accounting Principle (GAAP) applies rather than the FAR or DFARS cost principles.

For information on 845 Other Transaction Authority for Prototypes (OTA) agreements, refer to
http://www.darpa.mil/Opportunities/Contract_Management/Contract_Management.aspx. All
proposers requesting an 845 Other Transaction Authority for Prototypes (OTA) agreement must
include a detailed list of milestones. Each such milestone must include the following: milestone
description, completion criteria, due date, payment/funding schedule (to include, if cost share is
proposed, contractor and Government share amounts). It is noted that, at a minimum, such
milestones should relate directly to accomplishment of program technical metrics as defined in
the BAA and/or the proposer’s proposal. Agreement type, fixed price or expenditure based, will
be subject to negotiation by the Agreements Officer; however, it is noted that the Government
prefers use of fixed price milestones with a payment/funding schedule to the maximum extent
possible. Do not include proprietary data. If the proposer requests award of an 845 OTA
agreement as a nontraditional defense contractor, as so defined in the OSD guide entitled “Other
Transactions (OT) Guide For Prototype Projects” dated January 2001 (as amended) (
http://www.acq.osd.mil/dpap/Docs/otguide.doc ), information must be included in the cost
proposal to support the claim. Additionally, if the proposer plans requests award of an 845 OTA
agreement, without the required one-third (1/3) cost share, information must be included in the
cost proposal supporting that there is at least one non-traditional defense contractor participating
to a significant extent in the proposed prototype project.

54