HR001119S0044.pdf

HR001119S0044

Broad Agency Announcement Automatic Implementation of Secure Silicon (AISS)

Microsystems Technology Office

April 3, 2019

Foreword

On June 1, 2017, the DARPA Microsystems Technology Office (MTO) announced a new Electronics Resurgence Initiative (ERI) to ensure far-reaching improvements in electronics performance well beyond the limits of traditional scaling. ERI draws on new and existing DARPA programs to make a significant investment into enabling circuit specialization and managing complexity. Building on the tradition of other successful government-industry partnerships, ERI aims to forge forward-looking collaborations among the commercial electronics community, defense industrial base, university researchers, and the DoD to create a more specialized, secure, and heavily automated electronics industry that serves the needs of both the domestic commercial and defense sectors.

DARPA kicked off ERI with six programs aligned to three thrust areas. The Materials and Integration thrust asked whether the integration of unconventional materials could enhance conventional silicon circuits and continue the progress traditionally associated with scaling. The Architectures thrust asked whether the electronics community could enjoy the benefits of specialized circuitry while still relying on general programming constructs through the proper software/hardware co-design. The Designs thrust asked whether the electronics community could dramatically lower the barriers to modern system-on-chip design and unleash a new era of circuit and system specialization and innovation. Through novel research and development, these “Page 3” programs aimed to promote circuit specialization as a complement to transistor scaling and to constructively enmesh the needs of the defense enterprise with commercial and manufacturing realities.

Following its 2018 ERI Summit, DARPA commenced with ERI Phase II, again launching six new programs aligned to the three existing thrusts. These six programs will close out ERI Phase II. Two new materials programs, Photonics in the Package for Extreme Scalability (PIPES) and Technologies for Mixed-mode Ultra Scaled Integrated Circuits (T-MUSIC), aim to create unique and differentiated domestic manufacturing capabilities accessible to the DoD. Two new architectures programs, Guaranteed Architecture for Physical Security (GAPS) and Digital RF Battlespace Emulator (DRBE), and two new designs programs, Automatic Implementation of Secure Silicon (AISS) and Real Time Machine Learning (RTML), aim to ensure the security of sensitive electronics and data to demonstrate that specialized circuits can address emerging defense and commercial applications, such as artificial intelligence. GAPS and AISS specifically respond to a growing commercial and defense sector demand for integrating security and privacy into electronic systems, either through system architecture or circuit design. With these investments, ERI will approach new circuit designs with both security and performance in mind.

On July 15 – 17, DARPA will officially kick off year two of ERI via the 2019 ERI Summit, located in Detroit, Michigan. The Summit will emphasize the impact of advanced electronics for both semiconductor designers and manufacturers as well as the electronics user base, where sectors like automotive, telecommunications, and defense will increasingly rely on new technologies to maintain a competitive edge. DARPA looks forward to gathering the community in Detroit to discuss the progress of the initiative, highlight the technical achievements prior investments, and reflect on new directions.

Table of Contents

Foreword Glossary of Terms (in the context of the AISS BAA)

PART I: OVERVIEW INFORMATION

PART II: FULL TEXT OF ANNOUNCEMENT

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

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

III. Eligibility Information A. Eligible Applicants

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

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

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

1. Full Proposal Format

2. Proprietary Information

3. Security Information

a. Program Security Information

b. Unclassified Submissions

4. Disclosure of Information and Compliance with Safeguarding Covered Defense

Information Controls

5. Human Subjects Research (HSR)/Animal Use

6. Approved Cost Accounting System Documentation

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

8. Small Business Subcontracting Plan

9. Intellectual Property

a. For Procurement Contracts

b. For All Non-Procurement Contracts

10. Patents

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

12. Funding Restrictions

C. Submission Information

1. Submission Dates and Times

a. Full Proposal Date

b. Frequently Asked Questions (FAQ)

2. Proposal Submission Information

a. For Proposers Requesting Contracts or Other Transaction Agreements

b. Classified Submission Information

3. Other Submission Requirements

V. Application Review Information A. Evaluation Criteria

1. Overall Scientific and Technical Merit

2. Potential Contribution and Relevance to the DARPA Mission

3. Cost Realism

4. Plans and Capability to Accomplish Technology Transition

B. Review and Selection Process

1. Review Process

2. Handling of Source Selection Information

3. Federal Awardee Performance and Integrity Information (FAPIIS)

VI. Award Administration Information A. Selection Notices

1. Proposals B. Administrative and National Policy Requirements

1. Meeting and Travel Requirements

2. FAR and DFARS Clauses

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

4. Representations and Certifications

C. Reporting D. Electronic Systems

1. Wide Area Work Flow (WAWF)

2. i-Edison

VII. Agency Contacts VIII. Other Information

A. Proposers Day B. Protesting

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

Glossary of Terms (in the context of the AISS BAA) Term Definition Accelerator An implementation of a specific function as co-processor logic or hardware to provide performance assistance and speed-up, typically application- or domain-specific.

ARM A family of reduced instruction set computing (RISC) architectures or computer processors, ARM Holdings develops the architecture and licenses them to other companies, who design their own products, including systems-on-chip.

Associate Contractor Agreement (ACA)

An agreement between contractors working on government projects that specifies the requirements for them to share information, data, technical knowledge, expertise or resources, the intent being the sharing of information to enable the development of capabilities that integrate the research and resources, and particularly potentially proprietary research and development, of multiple performers.

Central Processing Unit (CPU)

The element of a general computing implementation that carries out the instructions of a computing program, performing and directing basic arithmetic, logic, data access, processing control, and use of other system elements within a computing device, traditionally the term "CPU" refers to the core computational function of a computer system versus eternal system components.

Cloud computing Where computing resources are offered as a utility via the Internet, using computer system resources, especially storage and computing, typically as data centers resources available to many users over the Internet.

Electronic Design Automation (EDA)

The use of tools and automated capabilities for the computer-aided design of electronic circuits and systems.

eXtensible Markup Language (XML)

A markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable, the markup language contains human-readable files that contain standard word rather than typical programming syntax.

Field Programmable Gate Array (FPGA)

Designed to be configured by a customer or a designer after device manufacturing for a specific application or instance of an application, FPGAs contain an array of programmable logic blocks that are interconnected in a programmable fabric that is configured to implement the user specified application.

Hardware Description Language (HDL)

A circuit design language that provides a high-level representations of a circuit, from which lower-level representations and ultimately actual implementation can be derived, such as Verilog and VHDL.

High Level Synthesis (HLS)

An automated design process that interprets an algorithmic description of a desired behavior and creates digital hardware that implements that behavior;

synthesis begins with a high-level specification of the problem, the code is analyzed, architecturally constrained, and scheduled into RTL. The goal of HLS is to describe the design at a higher level of abstraction while another tool develops the RTL implementation.

Homomorphism A transformation of one set of data into another set of data that preserves the data relations while obscuring the actual original data.

Input – Output (I/O) The interface and physical circuitry for data to be transferred into or out of a system.

Intellectual Property

(IP)

Protected logic, circuit design, functionality, and/or implementation information, the use of which must be licensed or legally obtained for use; IP blocks provide specific functionality and are integrated to provide that functionality in an overall system design.

IP-XACT An eXtensible Markup Language (XML) format that defines and describes individual, re-usable electronic circuit designs to facilitate their use in creating integrated circuit designs.

Manufacturing Floor

At the fabrication and implementation level of integrated circuits.

Obfuscation Hiding the true intent, purpose, or functionality of logic or system design through the addition of circuitry or logic in order to prevent reverse engineering or tampering.

Odometer The measurement of particular operations or activities that define the operation, both typical and abnormal, of a system

One Time Programmable

(OTP)

For memory, each bit is set and locked and the data is then permanent and cannot be changed.

Physically Unclonable Function (PUF)

A "digital fingerprint" that serves as a unique, measurable physical identity for a computing system derived from physical fabrication characteristics, PUFs are based on naturally occurring semiconductor manufacturing physical variations which make it possible to differentiate between otherwise identical semiconductors.

Platform This is the system or computation circuitry that is to be or has been designed or implemented.

Power, Area, Speed, and Security (PASS)

Measurement of performance and characteristics of a specific design to define a particular system design point's overall performance.

Proof of Concept (PoC)

A sub-set or partial implementation of a design or system to demonstrate and verify the performance and functional characteristics to support the full system design.

Provenance Providing the attribution, source, lineage, and history of an element in a system design, particularly IP or logic/functional blocks to be integrated into a system design.

Provisioning Providing the functional capabilities required for a system to perform the required operations and performance, such as providing the logic and functional blocks that will compose a systems.

Reduced Instruction Set Computer

(RISC)

A microprocessor designed to perform a reduced, smaller set of instructions so that it can operate at a higher speed, the set is based on the instructions used to perform basic, common functions that can also be used in combination to create more complex instructions, versus CISC (Complex Instruction Set Computer) which incorporates instructions that implement complex, multi-clock operations.

Register-Transfer Level (RTL)

A design abstraction which models a synchronous digital circuit in terms of the flow of digital signals (data) between hardware registers, and the logical operations performed on those signals.

RISC-V An open-source hardware instruction set architecture (ISA) based on established reduced instruction set computer (RISC) principles, in contrast to most ISAs, the RISC-V ISA is free and open-source and can be used royalty-free for any purpose.

SAT-solver Using Boolean satisfiability algorithms to determine a solution; in the case of AISS, using Boolean satisfiability algorithms to find solutions to defeat system security protections.

Silicon IP (SIP) A targeted design for implementation.

System C A system-level modeling language, composed of a set of C++ classes and macros to support event-driven simulations.

System on a Chip, or System on Chips (SoC)

An integrated circuit that incorporates all components and functions of a processing system in a chip or device; these components typically include a central processing unit (CPU), memory, input/output ports and secondary storage – all on a single substrate.

Tape-out The product of the circuit design process for integrated circuits that provides the physical layout and graphical implementation for manufacture from which an integrated circuit will be physically fabricated, and specifically the point at which the graphic layout that represents an implementation of a device’s design is represented by photomasks of the circuit that are ready to be sent to a fabrication facility for device manufacture.

Transaction –Level Modeling (TLM)

A high-level approach to modeling digital systems where details of communication among modules are separated from the details of the functional implementation, the emphasis is more on the functionality of the data transfers – what data are transferred.

Trojan attack A type of malware that is disguised as legitimate system operations or software, employed to gain access or control of a computing system.

Verilog A hardware description language (HDL) used to model electronic systems. Most commonly used in the design and verification of digital circuits at the register-transfer level of abstraction.

VHSIC Hardware Description Language (VHDL)

A hardware description language used in electronic design automation to describe digital and mixed-signal systems such as field-programmable gate arrays and integrated circuits.

VHSIC – Very High Speed Integrated Circuit Watermark An identifying characteristic that will provide the source, lineage and state of a particular logic element or block that is to be used to compose a system design or implementation.

PART I: OVERVIEW INFORMATION

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

Funding Opportunity Title: Automatic Implementation of Secure Silicon (AISS) Announcement Type: Initial Announcement Funding Opportunity Number: HR001119S0044 Catalog of Federal Domestic Assistance Numbers (CFDA): Not applicable Dates: (All times listed herein are Eastern Time) o Posting Date: April 3, 2019 o Proposers Day: April 10, 2019 o FAQ Submission Deadline: May 10, 2019 o Proposal Due Date: May 20, 2019

Estimated period of performance start: October 2019 Concise description of the funding opportunity: The DARPA Microsystems

Technology Office is soliciting research to develop a novel design flow for digital integrated circuits that aims to protect advanced chips from known attack strategies. This shall be accomplished by streamlining inclusion of scalable defense mechanisms into an automated design process that maximizes architectural exploration of security versus other economic trade-offs, all while improving design productivity.

Anticipated Funding Available for Award:

Approximately $75M of funding is anticipated for all awards made against this BAA.

Anticipated individual awards: Multiple awards are anticipated.

o Multiple awards are anticipated in each technical area.

o DARPA anticipates at least two primes each pursuing parallel ARM and RISC-V solutions.

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

Agency contact:

o Mr. Serge Leef, Program Manager BAA Coordinator: AISS@darpa.mil

DARPA/MTO

ATTN: HR001119S0044

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

PART II: FULL TEXT OF ANNOUNCEMENT

I. Funding Opportunity Description

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

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

The Microsystems Technology Office at DARPA seeks innovative proposals to develop technologies for streamlined and simplified integration of state of the art security mechanisms into advanced System on a Chip (SoC) designs. Proposed activities should investigate and prototype approaches that enable profound advances in tools, methodologies and targeted design modules for analysis, simulation, integration, and synthesis into logic circuits for comprehensive on- and off-chip security strategies. Developed design modules within the context of this program are referenced as Silicon IP, or SIP. While the primary goal of the program is to dramatically simplify integration of security into mainstream designs, advances in specific defenses and countermeasures are also targets of the program.

A. Background

Throughout the past decade, cybersecurity threats have evolved from attacks focused high in the software stack to progressively lower levels of computational hierarchy. With the explosion of popularity and growing deployment of internet connected devices, economic attackers and nation-states alike are shifting their attention to digital integrated circuit “chips” that enable complex capabilities across commercial and military application domains.

Despite growing recognition of the problem and a substantial body of research across multiple chip security areas, no common tools, methods or solutions are in wide use today. Modern chips are already very complex and expensive to design, causing incorporation of security to be viewed as a burden with unclear economic benefits. The result is that the majority of today’s chips are largely unprotected. Absence of automation makes incorporation of security a laborious, manual task that generally requires very specific design expertise not generally possessed anywhere, but in the largest semiconductor companies.

This state of affairs can be altered with a novel chip design flow that protects advanced chips from known attack strategies by streamlining inclusion of scalable defense mechanisms into an automated process that maximizes architectural exploration of security vs. economics trade-offs while improving design productivity. The effort and cost to incorporate a level of hardware http://www.fbo.gov/ security aligned with application requirements and economics will be significantly reduced so that incorporation of security at all levels of hardware design is feasible and affordable.

For this solicitation, relevant economic factors (hereafter collectively referred to as “economics”) are composed of (1) power that is consumed to support execution of the intended tasks, which translates into the costs associated with a chip, (2) silicon area required to fit all logic elements into a fabricated implementation, which translates directly into the cost of manufacturing each part, and (3) performance or speed of execution for the most critical and relevant operational sequences, which translates into a chip’s ability to execute intended functions within required time constraints.

Four specific attack surfaces are relevant to hardware security:

• Side Channel attacks extract protected information from chips through physical communication channels other than those intended by design by inferring meaning of data from passive or forced emissions. Commonly proposed counter strategies focus on attenuation of meaningful emissions or generation of random value or timing noise emanating from on-chip cryptography circuits.

• Reverse Engineering attacks interpret design intent from available or derived representation to understand protected or proprietary algorithms by manual or automatic circuit examination. Numerous protection techniques that utilize logic encryption, obfuscation, and locking have been extensively investigated to substantially increase the complexity and level of effort for this attack.

• Supply Chain attacks result in non-genuine chips being sold as real, but realized through cloning, counterfeiting, recycling, re-marking or overproduction. The attackers are typically driven by economic gain and can be effectively countered by several demonstrated techniques that employ on-chip authentication, provisioning, certificates, and silicon odometers.

• Malicious Hardware attackers insert hidden functionality, “Trojan” logic, into design blocks that are secretly triggered to deliver disruptive payloads. While these circuits are difficult to find since their functionality is not known, design implementation can be watermarked and analyzed. It is also possible to detect attempted triggers for inserted Trojan logic during the chip’s operation.

The techniques noted above have yet to be brought together in a comprehensive solution to the chip design community. They can be combined and realized in a multitude of ways to produce solutions of distinct size, performance, and power dissipation attributes. Since chip designs target specific applications and markets, there is not a single strategy that fits all and the security solutions must be tailored to the economic constraints of the end product.

B. Program Description

The objective of Automatic Implementation of Secure Silicon (AISS) is to enable a design tool and Intellectual Property (IP) ecosystem where security is pervasive and can be naturally incorporated into chip design with minimal effort and expense. The program also plans to enable rapid evaluation of architectural alternatives in platform integration where security is considered with conventional design economics, together being Power, Area, Speed, and Security (PASS).

The program aims to advance multi-level provenance and integrity validation techniques for design through advances in current methods or invention of novel technical approaches and demonstrate new capabilities in the context of ARM and RISC-V architectures.

An AISS target system consists of two partitions. The first is a security subsystem that implements security features and interacts with related structures and services on- and off-chip.

The second is a processor subsystem or platform composed of processor, memory, and co-processors or accelerators – hardware implementations of processing functions commonly used in the specific application domain targeted by the platform. Both of these partitions should be automatically generated, integrated, and optimized in tandem to meet the objectives of the application and corresponding security intent, while exploring multiple architectural strategies by weighing economics versus security trade-offs. AISS calls for a cloud-based design environment with an open source RISC-V platform as well as a commercial ARM platform for use in SoC design.

The AISS program seeks to: 1) enable automatic generation of on-chip security subsystems that defend against supply chain, side channel, reverse engineering, and malicious hardware attacks, while interacting as needed with the off-chip infrastructure that supports key management, watermarking, obfuscation, authentication, provisioning, tracking, and analytics; and 2) enable automatic generation of the processor subsystem or platform to customize processors, memories, logic accelerators, peripherals, and on-chip interconnects to optimize integration with the security subsystem in a way that meets the intent of an application’s economics and security goals.

Estimators for all PASS metrics should produce a rapid assessment of relative value for each metric without requiring exhaustive simulation or prototyping. Given a set of architectural solutions, the estimators need to be capable of ordering a set from best to worst for each PASS metric. While area and speed estimation strategies have been well understood since the 1980s, development of a rapid power estimator will require innovation. Security estimators for relative comparison across design alternatives will be an essential capability necessary for system integration and optimization. The concepts behind estimation of security will need to be developed and made quantifiable. That is, the degree of attack resistivity that the overall system offers along the defined attack surfaces would be determined by the attributes of inserted defense mechanisms as well as the overall compute architecture, subsystems, and the communication infrastructure with the representative software and I/O workloads. Pre-existing designs would be used to validate these quantification methods by comparing computed values to results derived from conventional simulation. These quantification methods would then be turned into rapid estimators applied to multi-factor optimization that converges upon solutions. Estimators will also be tested for correctness and accuracy by evaluating sample designs through extensive simulation.

Automatic implementation of security into tomorrow’s chip design is anticipated to impact both defense and commercial markets. By lowering the effort threshold for right-sized security in commercial silicon, AISS aims to have a sweeping effect on the commercial chip market. This approach is consistent with current design practices that satisfy economics-driven design constraints, yielding application-appropriate security that is “baked in” while significantly reducing development schedule.

C. Program Structure

AISS is a 48-month program divided into two Technical Areas (TAs), TA1 SECURITY and TA2 PLATFORM, across Phase 1, 2, and 3 spanning 15, 18, and 15 months, respectively. TA1 and TA2 are further divided into Track A, B, and C. All three tracks within a technical area must be fully addressed within a proposal to yield a conforming response to that technical area.

Phase 1 15 months

Phase 2 18 months

Phase 3 15 months

TA1 Track A TA1 Track B

TA1

SECURITY

TA1 Track C TA2 Track A TA2 Track B

TA2

PLATFORM

TA2 Track C Independent Verification & Validation (IV&V)

Table 1. AISS program Technical Areas divided by Phase and Track

DARPA anticipates funding multiple technical approaches and performers across AISS technical areas. It is desired that selected performers be funded through Phases 1, 2, and 3 of the program.

Beyond Phase 1, subsequent phases are options, and may or may not be exercised, at the sole discretion of the government. Funding of option phases will be based on demonstrated technical progress towards the goals of the AISS program and the availability of funds.

Collaborative efforts/teaming are strongly encouraged and will be required for the success of the AISS program. Collaboration between TA1 and TA2 proposers at the proposal stage is encouraged but not required. Associate Contractor Agreements (ACAs) between TA1 and TA2 performers must be signed prior to contract award. All TA1 developed technologies, tools, IP, and methods shall be made available under ACAs to all members of TA2 teams.

Proposers may submit multiple proposals, either to TA1, TA2, or combined TA1 and TA2.

Proposals must indicate the Technical Area(s) to which they are submitted. All proposals for a combined TA1 and TA2 effort should clearly delineate TA1 and TA2 tasks, activities, performers, and cost, to enable, at the discretion of the Government, potential independent selection and individual funding of TA1 or TA2.

There is anticipated to be at least two performers pursuing two independent TA2 paths, based on ARM and RISC-V architectures, respectively. The TA2 performers must be interoperable with all selected TA1 performers’ on-chip security implementations.

AISS program development is intended to be transitioned to the open source community, Government cloud, as well as to commercial IP suppliers and Electronics Design Automation (EDA) chip design tools, enabling rapid and low cost integration of security into chip designs in both commercial and defense markets. The performers are encouraged to self-fund and commercialize further development of differentiated derivatives outside of this program framework.

An Independent Verification and Validation (IV&V) team of Government experts will provide cloud-computing infrastructure and perform assessment of deliverables of both TA1 and TA2 at every successive Phase from ARM and RISC-V teams. The performers will deliver cost and royalty free SIP, software, scripts, and environments to the government and its contractors during the program for evaluation purposes.

Figure 1. Full program structure overview

D. Technical Areas

TA1 SECURITY

TA1 Security is composed of three tracks: A, B, and C – each performed in three successive phases. Track A and Track C target semiconductor development but are sufficiently satisfied at front-end RTL design. Track B addresses off-chip security infrastructure to be utilized after fabrication.

TA1 SECURITY Phase 1 Phase 2 Phase 3

Track A –

Security Engine

(SE)

Modular SE Configurable SE Generated SE

Track B –

Asset Management Infrastructure

Basic Asset Management

Provisioning and Tracking

Security Configuration

Track C –

Security IP

Foundational Security IP

Advanced Security

IP

Security IP Generator

Table 2. TA1 Security by Phase and Track

TA1 Track A: Security Engine

Successful proposers should ultimately demonstrate a functional SE as an automatically generated soft-core IP block (in fast simulation model and synthesizable RTL forms), upgradable via policies that would enable it to respond to emerging threats over time.

Table 3 details the system metrics for TA1 systems.

Phase 1 – Modular SE – Produce a modular version of the SE that consists of IP blocks that support distinct capabilities manually assembled to support enrollment (harvest of unique identity and register during manufacturing test), authentication (establish that the asset is registered and valid), provisioning (obtain keys that control chip features from an off-chip server) and locking (apply provisioning keys to de-obfuscate or unlock specific on-chip facilities).

Phase 2 – Configurable SE – Develop assisted assembly of the SE IP block based on a feature set specified by the designer. This version of SE should add the ability to monitor traffic on the chip busses for detection of illegal or invalid communications and possible Trojan triggers. To support this capability, the SE should be able to apply chip-specific security policies that define communication rules and guide monitoring strategies.

Phase 3 – Generated SE – Develop a program that automatically generates the SE IP block based on economic and security goals specified by the designer for each attack surface. The economic goals with respect to area, speed, and power will be specified along with objectives for each attack surface in terms of relative importance of its defense. These will be used by the generator to iteratively converge upon custom SE architectures that attempt to efficiently address all the objectives while exploring their trade-offs. Security features should be added to support bus traffic encryption to enable secure interactions among selected IP blocks. Another addition should be an active malicious hardware trigger detection mechanism where known-illegal traffic would be placed by the SE on the busses in an attempt to illicit responses from otherwise dormant and undeclared functions (i.e. suspected Trojans). Upgradability of the SE would be further expanded allowing hardware upgrades (where SE extensions address currently unknown threats) to be realized in a programmable logic block, if one is present in the design.

TA1 Track B: Asset Management Infrastructure

Off-chip Asset Management Infrastructure (AMI) should be a high availability, cloud-based system capable of managing keys, certificates, policies, and tracking data in a form consumable by external data analytics tools. A successful implementation will demonstrate scalable capacity for storing data associated with at least 10,000,000,000 devices.

Phase 1 – Basic Asset Management – Develop a system for enrollment of individual die intended to be used during fabrication. A cloud-based server should be able to respond to authentication requests from fab floor appliances and test equipment received over internet. All data traffic carrying chip identity information and other related data should be sufficiently secured through encryption or other means.

Develop a simple watermark tool capable of examining Register Transfer Logic (RTL) IP to obtain a unique signature or watermark and store it on the cloud for subsequent retrievals. As this IP block moves through the design process, which may involve stops in multiple companies and geographies, extractions of a watermark at any point can be compared to the reference values stored on the cloud, thus ensuring that the IP block has not had a malicious or unauthorized modification.

Phase 2 – Provisioning and Tracking – Extend the manufacturing floor integration to the equipment used in later stages of fabrication, packaging, test, and assembly in order to support authentication, provisioning, locking, and key and certificate management.

Extend cloud-based software to support tracking of chip provenance and expose an interface to analytics tools. Develop smart watermark technology that generates circuits that can autonomously compute a watermark and embed it in the host IP block in a way that is resistant to its identification, tampering and removal. At the time of the watermark circuit creation, the reference watermark is computed and stored on the cloud.

Subsequently, the embedded watermark generation circuits can be triggered and forced to re-compute the watermark in the simulation and emulation environments. The computed watermark should be made visible from outside the RTL IP block (via a port or a software-accessible register) for comparison to the reference value stored on the cloud.

Phase 3 – Security Configuration – Extend cloud based system to store and retrieve per chip security policy configurations, hardware extensions, and IP watermarks.

Additionally, keys necessary to enable secure domains in on-chip interconnect should also be available for storage and retrieval. Provide a Persistent Watermark technology through enhanced watermark circuits that can survive design transformations beyond

RTL as it gets synthesized into gates, decomposed into transistors, transformed into polygons and ultimately realized in silicon. This technology needs to compensate for the fact that some EDA tools that perform these design transformation may try to remove all or parts of the watermark circuits to optimize the design. The watermark embedding technology must ensure that the watermark circuits survive all transformation and can be triggered at each stage of the implementation process including in the final manufactured chip.

Embedded circuit watermarks should be accessible to SE, which would act as a conduit to the off-chip AMI to store and retrieve the watermarks.

TA1 Track C: Security IP

Essential security IP blocks would be automatically produced or configured by the generators to customize them for application needs. Successful proposers will ensure that automatically generated systems possesses improved security with respect to the relevant attack surfaces for this program: Side Channel, Supply Chain, Reverse Engineering, and Malicious Hardware. Research of novel Physical Unclonable Function (PUF) architectures and strategies is OUTSIDE of the program scope. While an adequate ‘unique identity system’ should be architected to support incorporation of multiple PUF types and sizes, the only requirement placed on the PUF itself is being scalable enough to offer different levels of attack resistance at the level driven by the PASS goals.

Phase 1 – Foundational Security IP – Develop essential IP blocks necessary to support on-chip security mechanisms including license-free, one-time programmable, memories, cryptographic engines, and an odometer capable of counting power on/off cycles.

Architect an Obfuscation Framework where multiple logic encryption, obfuscation approaches, and algorithms can be iteratively applied to RTL and gate level IP blocks.

Integrate it with the SE to enable computation and issuance of runtime keys to support locking and unlocking directives controlling the encrypted and obfuscated blocks.

Develop a Threat Heuristics library of approaches for the detection of suspect circuits in the RTL IP. Characterization of threat signatures needs to be undertaken and catalogued.

Phase 2 – Advanced Security IP – Develop an odometer that is programmable to count different types (example: read/write cycles) of events that represent chip activity and can be used to limit use and to distinguish new from recycled parts. Demonstrate crypto cores resistant to extraction of information. Develop obfuscation framework initially containing a logic encryption and obfuscation capability to insert key gates and multi-function gating circuits into optimum injection sites. The user should be able to specify the key length, type of gating element, and ratio of gating elements per key bit. A companion technology should be provided to ensure that the design’s intended functionality has not been corrupted or otherwise modified by the encryption and obfuscation tool. Develop threat detection tools that utilize static, dynamic, or formal analysis based threat detection including strategies for reduction of false positives, possibly employing machine learning techniques for improvement over time.

Phase 3 – Security IP Generator – Develop generators capable of producing crypto cores and odometers based on specified parameters to enable exploration of alternatives that meet distinct design objectives. Develop advanced obfuscation, provide a user interface for iterative execution, and assessment of alternative obfuscation strategies. Develop novel techniques that implement SAT-solver attack resistant logic obfuscation technologies. Develop an Integrated Analysis user interface that unifies multiple threat detection algorithms and facilitates into an iterative use model.

Table 3. TA1 Metrics

TA2 PLATFORM:

Successful proposers should ultimately demonstrate several fully functional compute/control platforms (application specific clusters of pre-integrated IP) as automatically generated sub-systems fully integrated with the SE. These may be composed of a Central Processing Unit (CPU), memories, logic accelerators, commodity IP, reconfigurable logic, and interconnect fabric. Standards-based technologies should be developed to enable synthesis, generation and automated integration of secure IP blocks into an optimizable on-chip bus, enabling efficient operation and connectivity with the platform and SE. Additionally, technologies for automatic bus integration of standards-based IP blocks and automatic generation of platform and security clusters based on user-specified feature selections should be developed. This will lay the foundation for system-wide optimization technology, where multiple architectural solutions are considered based on objective functions that include estimated metrics of power, area, speed, and security (PASS). Table 5 details the system metrics for TA2 systems.

For avoidance of ambiguity, the AISS framework is defined to consist of design units that each contain the following components:

• Resource – Declarative description of relevant properties of the unit capable of storing architectural parameters and representing estimated impact of unit contents and expected

1 Software that addresses Boolean Satisfiability problems. A SAT Solver commonly used in EDA-related benchmarking is from the Princeton University (https://www.princeton.edu/~chaff/).

2 As provided in the CVE (Common Vulnerabilities and Exposures) listing containing an identification number, a description, and at least one public reference for publicly known vulnerabilities (https://cve.mitre.org/).

TA1 Metrics

Metrics Phase 1 Phase 2 Phase 3

Supply Chain 2 features @ < 500K gates 4 features @ < 200K gates 6 features @ < 100K gates

Reverse Engineering Hardness

1 week manual effort 15 days of SAT solver1 100 days of SAT solver

>20% of known types >80% of known types 100% of known typesMalicious Hardware Detection2

<50% false positives <20% false positives <5% false positives https://www.princeton.edu/~chaff/ https://cve.mitre.org/ operations in terms usable to compute the PASS metrics. This format needs to be defined by the community and considered as an IP-XACT (IEEE standard for IP meta-data) extension. This format can be declarative, simulatable, or executable, the latter two potentially enabling use as an executable specification.

• Behavior – Fast simulation model that can be stitched with other such models to create a system model suitable for verification of overall functionality and execution of target code at speeds of greater than 1000 cycles per second. The choice of model type should be primarily driven by the performance requirements, however, cycle and transaction level standards-based strategies are preferred. It should be easily combined with blocks’ behaviors to enable system-wide verification and multiple levels of abstraction.

• Design – A model suitable for detailed simulation and implementation in the traditional logic synthesis flows, i.e. synthesizable RTL.

• Interface – Information necessary for automatic generation of bus interface logic and corresponding device drivers; there may be multiple interfaces to support distinct on-chip interconnect infrastructures. The minimum requirement is to provide sufficient information for the IP-XACT based EDA tools to enable automated creation of bus interface logic and corresponding software device drivers.

• Test – Portable stimulus and corresponding embedded software (if applicable) that can be used to validate functional correctness of the unit at either behavior or implementation levels. This data could take a form of test vectors, test programs, or both to assure proper operation under simulation. It should be easily combined with other unit tests to enable system-wide verification and multiple levels of abstraction.

TA2 PLATFORM is composed of three tracks: A, B, and C – each performed across three successive phases.

TA2

PLATFORM

Phase 1 Phase 2 Phase 3

Track A –

Core Platform Static Platform Modular Platform Generated Platform

Track B –

Platform Infrastructure

IP Integration IP Generation Interconnect Generation

Track C –

Composition

Assisted Composition

Automated Composition

Optimized Composition

Table 4. TA2 Platform by Phase and Track

TA2 Track A: Core Platform

Phase 1 – Static Platform – Select a vertical application target area and collect or create necessary IP blocks, centered around CPU and memory platform on a standard bus capable of executing a full software stack. A reference design can be leveraged by the performer or from the Government, such as the Common Evaluation Platform (CEP3).

This can be augmented by application specific accelerators and commodity IP blocks. In subsequent phases, this static platform should be automatically augmented with security features for Proof-of-Concept (PoC).

Phase 2 – Modular Platform – Develop generator configurable platforms that can produce an integrated IP cluster where a user can choose from a list of CPUs supported by the platform, select memory size and architecture, and choose and provide parameters for reconfigurable logic, accelerators, and commodity IP to be included. A fast system-wide simulation model capable of supporting assessment of power, area, and speed should be auto-generated.

Phase 3 – Generated Platform – Extend the generation technology by enabling a process where a platform architecture would be automatically produced based on user-specified performance, size, and power objectives. For each candidate architecture, an estimation should be produced to show how closely it matches the objectives, enabling the user to explore multiple alternatives in search of the one that most closely fits the overall system goals. Once an architecture is chosen, a fast system-wide simulation model should be auto-generated.

TA2 Track B: Platform Infrastructure

Phase 1 – IP Integration – Develop strategy and technology for IP encapsulation where the RTL blocks can be wrapped by automatically generated IP-XACT containers. Tools should be developed that automatically integrate these encapsulated blocks into the on-chip interconnect by generating bus interface logic.

Phase 2 – IP Generation – Enhance high level synthesis technologies to produce RTL IP that incorporates security. This may include adding extensions to the high-level languages commonly used to describe the desired functionality. Generated RTL IP should include mechanisms to detect and prevent illegal data flows, execution paths, and other operational scenarios outside of expectations. For all generated IP blocks, companion high speed models that would fit into system-wide simulation framework should also be generated.

Phase 3 – Interconnect Generation – Develop tools for automatic generation and optimization of on-chip interconnect (busses). The optimization strategies focusing on trade-offs around performance, size, and power need to consider alternative topologies (shared bus, hierarchical bus, rings, networks), parameters (priorities, burst, tokens, bus widths), and mapping (logic blocks to channels and communications to paths). As the buses are being constructed, a capability is needed to create support for some or all bus-

3 CEP is a DARPA funded design targeted to be a representative, open source, System on a Chip (SoC) surrogate platform. Wherever possible, dependence on specific FPGA hardware has been avoided towards a goal of ASIC synthesis (https://github.com/mit-ll/CEP).

https://github.com/mit-ll/CEP connected IP blocks to communicate via encrypted messaging. This will likely require enhancements to the bus interface logic for the involved peripherals along with system-side support mechanisms to enable key exchanges during device initialization.

TA2 Track C: Composition

Phase 1 – Assisted Composition – All blocks created in Phase 1 of Track A should be encapsulated in IP-XACT and accompanied by fast simulation models. Develop a fast and efficient system-wide modeling framework where a platform composed of these blocks can be simulated at speeds sufficient to support execution of real software driven by realistic test sequences. Rapid power and security estimator techniques should be developed, modeled, and quantified.

Phase 2 – Automated Composition – Develop a user interface for parametrization of all configurable platform blocks and the SE. Extend automatic integration technology to incorporate the SE with platform IP. In addition to the resulting RTL system, a fast, system-wide simulation model supporting strategies for estimation of power, area, and speed should be produced. Estimator modules should also be developed and tested for relative accuracy.

Phase 3 – Optimized Composition – Rapid estimators should be developed for assessment of performance, size, power, and security of the integrated system.

Furthermore, the security estimator should be made up of sub-estimators for the specificity of attack surface resistance. Thus, there will be security estimators for Side Channel, Supply Chain, Reverse Engineering, and Malicious Hardware attack resistance.

All the estimators should be used by cloud-based, scalable tools that will utilize state of the art optimization algorithms to search vast solution spaces for system architectures that best fit with user-specified design constraints. On completion of the design space exploration, the user should be presented with an architecture and configuration that comes closest to meeting the objective function. These should be accompanied by the estimation data and high speed simulation models for further assessment. It is expected that the user will repeat optimization runs until a satisfactory solution is found.

Estimators will be deployed in the context of optimization to ultimately produce and integrate chip designs.

TA2 Metrics

Metrics Phase 1 Phase 2 Phase 3

Relative Estimation

PASS accuracy of 70% @ < 1s per estimation

PASS accuracy of 90% @ < 0.5s per estimation

PASS accuracy of 100% @ < 0.1s per estimation

Simulation Speed Boot Linux > 300cps Boot Linux > 600cps Boot Linux > 1000cps

Time to Final RTL < 3 months to build < 1 months to build < 1 week to build

Functionally comparable to original PoC design

Comparable in PASS terms to original PoC design

Improvement in PASS terms to original PoC design

Linux bootable in simulation

Security features fully exercised in simulation

> 300 cycles/second simulation time

> 600 cycles/second simulation time

> 1000 cycles/second simulation time

API to estimators < 100ms call time

Design Quality for…