HR001118S0052-Amendment-01.pdf

Broad Agency Announcement Resilient Anonymous Communication for Everyone (RACE)

HR001118S0052

July 20, 2018

Amendment 1

Amended on August 7, 2018

Defense Advanced Research Projects Agency Information Innovation Office 675 North Randolph Street Arlington, VA 22203-2114

HR001118S0052 RESILIENT ANONYMOUS COMMUNICATION FOR EVERYONE (RACE) 2

Table of Contents

I. Funding Opportunity Description

A. Introduction

B. Program Description and Scope

B.1 RACE Security Model and Assumptions B.2 RACE System Architecture and Description

C. Program Structure and Technical Areas

C.1 Technical Area 1: Cryptography C.2 Technical Area 2: Obfuscated Communication C.3 Technical Area 3: Integration C.4 Technical Area 3.1: Resilient Application Distribution C.5 RACE Performer Collaboration Summaries

D. Program Capability Demonstration

E. Schedule and Milestones

F. Deliverables

G. Intellectual Property

H. Abbreviations

II. Award Information

A. Awards

B. Fundamental Research

C. Disclosure of Information and Compliance with Safeguarding Covered Defense Information Controls

III. Eligibility Information

A. Eligible Applicants

B. Organizational Conflicts of Interest

C. Cost Sharing/Matching

D. Other Eligibility Requirements

IV. Application and Submission Information

A. Address to Request Application Package

B. Content and Form of Application Submission

C. Submission Dates and Times

D. Funding Restrictions

E. Other Submission Requirements

V. Application Review Information

HR001118S0052 RESILIENT ANONYMOUS COMMUNICATION FOR EVERYONE (RACE) 3

A. Evaluation Criteria

B. Review and Selection Process

VI. Award Administration Information

A. Selection Notices

B. Administrative and National Policy Requirements

C. Reporting

VII. Agency Contacts

VIII. Other Information

A. Frequently Asked Questions (FAQs)

B. Collaborative Efforts/Teaming

C. Proposers Day

D. Submission Checklist

E. Associate Contractor Agreement (ACA)

HR001118S0052 RESILIENT ANONYMOUS COMMUNICATION FOR EVERYONE (RACE) 4

PART I: OVERVIEW INFORMATION

Federal Agency Name: Defense Advanced Research Projects Agency (DARPA), Information Innovation Office (I2O)

Funding Opportunity Title: Resilient Anonymous Communication for Everyone

(RACE)

Announcement Type: Initial Announcement

Funding Opportunity Number: HR001118S0052

Catalog of Federal Domestic Assistance Numbers (CFDA): 12.910 Research and Technology Development

Dates o Posting Date: July 20, 2018 o Proposers Day: July 24, 2018 o Abstract Due Date: August 14, 2018, 12:00 noon (ET) o Proposal Due Date: September 18, 2018, 12:00 noon (ET) o BAA Closing Date: September 18, 2018, 12:00 noon (ET)

Anticipated Individual Awards: DARPA anticipates multiple awards for Technical Areas 1 and 2, and a single award each for Technical Areas 3 and 3.1.

Total Funding Available for Award: $44 million

Types of Instruments that May be Awarded: Procurement contracts or cooperative agreements

Agency Contacts o Technical POC: Dr. Joshua Baron, Program Manager, DARPA/I2O o BAA Email: RACE@darpa.mil o BAA Mailing Address:

DARPA/I2O

ATTN: HR001118S0052

675 North Randolph Street Arlington, VA 22203-2114 o I2O Solicitation Website: http://www.darpa.mil/work-with-us/opportunities http://www.darpa.mil/work-with-us/opportunities

HR001118S0052 RESILIENT ANONYMOUS COMMUNICATION FOR EVERYONE (RACE) 5

PART II: FULL TEXT OF ANNOUNCEMENT

I. Funding Opportunity Description

DARPA is soliciting innovative research proposals in the area of cryptographic and communication obfuscation techniques in order to build an anonymous, attack-resilient mobile communication system that can reside completely within a network environment. 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.

This Broad Agency Announcement (BAA) is being issued, and any resultant selection will be made, using procedures under Federal Acquisition Regulation (FAR) 6.102(d)(2) and 35.016.

Any negotiations and/or awards will use procedures under FAR 15.4 (or 32 CFR § 200.203 for 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 (FBO) website (https://www.fbo.gov/) and the Grants.gov website (http://www.grants.gov/).

The following information is for those wishing to respond to this BAA.

A. Introduction

The Resilient Anonymous Communication for Everyone (RACE) program will research technologies for a distributed messaging system that a) can exist completely within a given network, b) provides confidentiality, integrity, and availability of messaging, and c) preserves privacy to any participant in the system. Compromised system data and associated networked communications should not be helpful for compromising any additional parts of the system.

RACE advances will be based on rigorous security arguments, such as those found in the academic cryptography community or statistical arguments based on realistic simulations.

RACE will create advances in communication protocol encapsulation methods as well as efficient, oblivious, distributed system tasking, possibly via secure multiparty computation, to build a system that cannot be compromised even with limited participant compromises and large-scale, real-time deep packet inspection. Approaches to preserving privacy are of interest, such as ubiquitous encryption, even during computation, and obfuscating communication protocols.

Please note that ad hoc security arguments are not in scope for the program.

Proposers are highly encouraged to submit abstracts in order to ensure that their security regimes and other assumptions are deemed in scope for RACE. Proposers are also highly encouraged to read this BAA in its entirety; important information for all proposers may be found in all sections of this solicitation.

B. Program Description and Scope

This effort will bring together advances in efficient, oblivious, distributed system tasking, possibly via secure multiparty computation, with communication protocol encapsulation methods to build a distributed system that cannot be compromised even with limited participant https://www.fbo.gov/ http://www.grants.gov/

HR001118S0052 RESILIENT ANONYMOUS COMMUNICATION FOR EVERYONE (RACE) 6

compromises and large-scale, real-time deep packet inspection. It is assumed that the network environment is large enough that it is infeasible to actively monitor every, or even most, systems in the environment, but it is possible to monitor all inter-network traffic (traffic between significant groups of networked systems). As an example, we assume that inter-network traffic can be affected by filtering, monitoring, or injection via real-time deep packet inspection at scale.

The primary purpose of the RACE system is to avoid large-scale compromise. In particular, small compromises against the system should not be helpful to compromise the operation or security of the larger system. The system will avoid compromise in two primary ways: 1) preventing compromised information from being useful for identifying any of the system nodes because all such information is encrypted on the nodes at all times, even during computation; and

2) preventing communications compromise by virtue of obfuscating communication protocols.

RACE will focus on Internet Protocol communications, to include those coming from the mobile phones used to send messages to each other. Please note that wireless-based solutions (e.g., mobile ad hoc networks) are NOT in scope.

B.1 RACE Security Model and Assumptions

The security guarantees for the RACE system should correspond to the standard notions of confidentiality, integrity, and availability, as contained in Table 1.

Type of security Attribute Notes user messages Only the sender and receiver of a message can see it1 user message metadata

Confidentiality of who talks to who and when unobservable communication

The fact that Alice possesses and uses the mobile application should not be inferable unless Alice’s mobile device is compromised.

Confidentiality unobservable service node participation

The fact that Bob is running software to execute service node functionality should not be inferable unless Bob’s system is compromised.

Integrity user messages User messages cannot be changed in transit Availability user messages End-to-end communication time should be one minute

Table 1: Desired RACE System Security Properties

For the RACE program, security should be maintained even if its component systems and network traffic can be observed, and possibly selected for compromise, throughout the network environment. The RACE system should maintain the security properties outlined in Table 12. It is assumed that the software for RACE mobile clients and server nodes are public knowledge, as well as technical specifications for the whole system. The network operator also should be assumed to have sufficient cyberspace operations capabilities that they are able to successfully exploit whatever systems that they deem of interest; however, they are not assumed to be resident on all systems. In particular, it is assumed that the vast majority of mobile devices

1 End-to-end encryption has become a standard feature in many mobile communication applications; the focus of RACE is not to develop breakthrough new means to achieve end-to-end encryption.

2 Technologies that hide RACE applications on systems, including mobile devices, are out of scope.

HR001118S0052 RESILIENT ANONYMOUS COMMUNICATION FOR EVERYONE (RACE) 7

within the network are not compromised at any one time.

The RACE system should function properly even in the presence of real-time, deep-packet inspection. This includes high-level analysis on network source/destination connections (netflows) in real time. The point-of-traffic-capture is assumed to be at inter-network points (i.e., between ISP, corporate gateway, etc.), not at every node in the network. In particular, RACE should not assume constant monitoring of every home or corporate network (though occasional, limited monitoring may occur if a particular subnetwork is of interest).

B.2 RACE System Architecture and Description

At a high level, the distributed RACE system will have two main components:3

1) a client, which should be viewed as a mobile application executed on a mobile device,

2) a distributed server, which consists of many server nodes that are executed in the network environment (e.g., by volunteers).

The mobile client will be an application for a version of the Android operating system, and the server nodes will be executable on specific versions of the Windows and/or Linux operating systems. The server nodes should be executable on a (possibly high-end) home computer.

Network connectivity/bandwidth of server nodes should be assumed to be broadband (e.g., 20 Mbps+). Assume that there are many clients who can participate in the system at will, while server nodes participation must be curated, or “permissioned.”

If a user, Alice, wishes to communicate the message m to another user, Bob, she would send the encrypted identity of the receiver (Bob4) together with the message, m, to the server. This may be broadcast to all server nodes, or perhaps only sent to some of them (at a high level, this should be done in such a way to leverage the cryptographic security achieved via fully distributed secure Multi-party Computation [MPC], even if in practice a fewer number of nodes perform the actual computation). The nodes then jointly compute on the encrypted receiver identity in order to task themselves to pass the encrypted message on to Bob.

RACE communication links should be designed to operate entirely within the network environment, because the system is expected to work even if the gateways between the network environment and the rest of the world are shut off. As a result, communication techniques that rely on specialized means to exit the environment, such as domain fronting, are NOT in scope.

There are two modes of communication that RACE will incorporate to avoid large-scale detection: 1) client-server communication and 2) server-server communication. Client-server communication, or “rendezvous,” enables Alice to communicate to the server nodes in order to task the server to pass her message to Bob. Therefore, Alice transmits the encrypted message and identity of the receiver via this mode of communication. The primary purpose of this communication mode is to enable Alice to communicate with server nodes in a manner that is both unobservable but also does not enable Alice to be able to learn sufficient information that would enable compromising any particular server node (and vice versa).

3 In what follows, to give the reader intuition about the desired technical approach, we will discuss primarily a “push” architecture, where a message is directly passed from Alice to Bob; it may be more efficient and/or secure to use a “push/pull” architecture, where Alice stores her message in the server and Bob retrieves it.

4 In reality, this identifier may be a pseudonym or some cryptographic key denoting Bob.

HR001118S0052 RESILIENT ANONYMOUS COMMUNICATION FOR EVERYONE (RACE) 8

Server-server communications enable the server nodes to communicate with each other in order to accomplish secure MPC, as well as other tasks the server nodes may need to accomplish. Due to the underlying supported protocols such as MPC, the bandwidth of these channels must be higher and more consistently used than the client-server communication mode. In order to accomplish this, the RACE system will build communications channels5 by embedding communications protocols within existing network services.

Table 2 contains desired logical bandwidth of each mode of communication. By logical bandwidth, we mean that, although the actual path from server node A to server node B may be indirect and will likely be embedded within higher-bandwidth links, the message capacity from A to B will appear to the users of the system to be 10 Mbps.

System Communication Mode Logical Bandwidth Frequency of Transmission Client-server <1Mbps Infrequent (~50 transmissions/day) Server-server 10Mbps Near-constant

Table 2: RACE System Modes of Obfuscated Communication

Finally, the RACE system will not assume an app store will carry the RACE communication application, since the network environment could filter such applications. RACE will require a method for enabling users to obtain the app from the network environment without creating an opportunity for detection. This method must be capable of providing the app on short notice.

Note that the server nodes that store these shards may be the same or different from the server nodes who accomplish distributed message passing above (but will still rely on the communications mechanisms described above).

C. Program Structure and Technical Areas

The program has been organized into three (3) phases. Phase 1 will be 18 months, followed by a 12-month Phase 2, and then concluded with Phase 3 at 18 months.

Phase 1 will emphasize initial development of the tools and techniques needed to validate the individual components of the RACE system (MPC, obfuscated communications, resilient application distribution) at a moderate scale.

Phase 2 will emphasize developing an initial integrated RACE system. The individual system components will also be refined to handle larger scales.

Phase 3 will emphasize scaling techniques to demonstrate an integrated system at large scale (1,000 server nodes and 10,000 mobile client users).

The program will be divided into 4 technical areas (TA), with all performers coordinating with each other and in concert with the integrator:

TA1: Cryptography, focused on MPC and other advanced cryptographic tasks.

TA2: Obfuscated communications, in both the client-server and server-server modes.

TA3: Integration of the RACE system.

TA 3.1: Resilient application distribution

5 We refer to “channels” in an information-theoretic sense: the actual channel may be an amalgamation of various means of communication, and may rely on side channels such as timing.

HR001118S0052 RESILIENT ANONYMOUS COMMUNICATION FOR EVERYONE (RACE) 9

Performers should be prepared to work closely with each other and be flexible in order to support integration and support system development needs that may arise as the RACE system becomes more mature. To facilitate the open exchange of information, performers will have Associate Contractor Agreement (ACA) language included in their award. See Section VIII.E for more information regarding an ACA.

C.1 Technical Area 1: Cryptography

Performers in this TA will develop techniques, protocols and prototype code to accomplish specific, efficient secure multiparty computation (MPC) task at thousand-party scale. For metrics, see Table 3. The overall desired functionality of such computation is to let users send and receive messages and to enable system nodes to jointly determine how to pass messages from one user to another without any server node understanding how the message is passed.

Additional information that server nodes hold about each other that could be used to compromise larger groups of nodes should also be encrypted at all times, and computation will likely need to be performed on such encrypted information in order to keep it secure at all times. TA1 performers will work with TA3 performers to identify and secure such information.

The end-to-end task of passing a message should be performed in minutes (e.g., from the time the initial communication of the sender to the time the receiver obtains the message)6. From the perspective of TA1 performers, they should simply assume 10 Mbps point-to-point channels. It may be that TA1 performers have limited access to the broadcast channel used for client-server communications as described in Section 1.B.2 and below in Section 1.C.2, but TA1 performers should recognize that this may not be a channel designed for persistent use (and therefore may only be usable for very limited purposes).

The desired outcome from TA1 is efficient MPC implementations. Proposals that only demonstrate asymptotic (i.e., complexity theoretic) efficiency are not of interest. It is anticipated that concrete efficiency will be the primary challenge of this TA. TA1 proposers should describe in detail methods for demonstrating the concrete performance of their solutions over the course of the program.

Proposers to TA1 should describe a viable MPC architecture (e.g., whether a message is actively pushed from Alice to Bob or if Bob will retrieve the message from the server). There may also be server nodes with different purposes (e.g., some nodes may only perform specific subtasks, such as message receipt from Alice or passing to Bob, or may perform particular MPC subtasks so TA1 proposers should be careful to justify why such specialization does not reduce the security of the system (e.g., that more than 20% of the system must be corrupted to break its security). In addition, for architectures where the receiver must retrieve a message from the server, the distributed, resilient storage issues must be addressed.

The metrics for this program stipulate correct system operation at a 20% node corruption rate.

TA1 proposers should note that this rate is epoch-based, where the security model should be assumed to be able to support security up to this threshold over the course of, for example, a

6 If a mechanism is proposed where a receiver must actively retrieves the message, this time assumes that the receiver attempts to receive the message as soon as it is stored.

HR001118S0052 RESILIENT ANONYMOUS COMMUNICATION FOR EVERYONE (RACE) 10

month. TA1 proposers should describe how the system can incorporate new nodes (and kick out corrupted nodes) over time (see Table 3 for more details).

TA1 proposers should not expect that the graph of logical connections between server nodes be a complete graph. As a result, proposers should address how internode connectivity might affect the security and efficiency of their solutions. While TA1 proposals do not need to be explicitly topology hiding or support deniable communications, stronger proposals will reinforce the system security goals of the RACE program.

TA1 performers will be the cryptographic experts for RACE system development. For example, to the extent that advanced cryptographic means are required, TA1 performers will also be responsible for key management and/or distribution in the RACE system (e.g., MPC, identity- or attribute-based encryption).

While standard cryptographic security models revolve around security definitions such as “honest but curious” and “malicious” (referred to as “passive” and “active”, respectively, in Table 3), proposers should describe how they will achieve whatever security is desired in order to create the desired security properties as outlined in Section 1.B.1. Proposers should indicate the extent to which they believe non-standard security models are more appropriate, and their implications (e.g., for efficiency).

TA1 performers will be expected to work with TA3 integrators to determine desired code format and other interoperability issues. TA1 performers will be required to periodically deliver and integrate their code within a framework that the TA3 integrator specifies. TA1 proposals should discuss their experience creating code to implement advanced cryptographic protocols (e.g., MPC). TA1 proposals should fully explain why they will be able to work seamlessly with other performers.

Topics of research that are specifically OUT OF SCOPE for TA1 include:

Reliance on specialized or secure hardware;

Cryptanalysis (other than security proofs for provided systems); and Cryptographic protocols based on non-standard or not commonly accepted cryptographic hardness assumptions.

Metric Phase 1 (18 mo) Phase 2 (12 mo) Phase 3 (18 mo) Nodes: users/server 10 / 100 100 / 1k 10k / 1k Crypto adversary / corruption level Passive / 20% Active / 10% Active / 20%

Crypto key infrastructure

Assumed Not assumed Not assumed msg/day / size / delay 500 / 140B / 5 min latency

5k / 140B / 1 min latency

500k / 1MB / 1 min latency

Node refresh Demonstrate 1/month 1/week

Table 3: TA1 Metrics

HR001118S0052 RESILIENT ANONYMOUS COMMUNICATION FOR EVERYONE (RACE) 11

C.2 Technical Area 2: Obfuscated Communication

Performers in this TA should develop a communications toolbox that enables users to evade automated protocol identification via stateful deep packet inspection capabilities across the network environment where the toolbox is deployed. This toolbox should create a means by which the RACE system can embed desired communications protocols within particular channels that reside completely within the network environment. Proposals for this TA that require exiting the network environment are not of interest. A minimal amount of external communications is allowed for initializing the system.

The fundamental goal of TA2 is to achieve undiscoverable communications even where real-time, deep packet inspection (DPI) is possible. Further, such DPI could be leveraged via traffic filtering, manipulation or injection, again possibly in real time, and at network scale.

The fundamental security approach of RACE to obfuscated communications is through rigorous security arguments, essentially a Kerckhoffs’ principle for communications systems.7 The means of obfuscated communication, other than specific keys or initialization values, should be assumed to be publically known.

There are three capabilities that TA2 performers will need to develop:

1) the means to encapsulate desired communications within targeted channels that exist within the network environment (here, a channel is an information-theoretic construct and could entail numerous concrete communications channels and phenomenologies);

2) the means to measure targeted normal channels in order to understand their baseline statistics with respect to how the protocol encapsulation will modify them; and

3) the means of rigorously demonstrating, ideally via proof, that the statistical distance of the distributions that model the targeted channel with and without encapsulated communications will be close. TA2 technologies should maintain security (that is, statistical closeness to normal communications) even when their methods are publically known.

Within TA2, there are two primary modes of communication: 1) server-server communication and 2) client-server communication. Server-server communication is the mode that system nodes will use to communicate with each other. Client-server communication is the mode by which the mobile app should communicate with the server nodes. It is anticipated, but not required, that server-server communications should target channels associated with point-to-point-based network services while client-server communications will target broadcast-based network services. TA2 proposals may address both or just one of these modes of communication, however, proposals should clearly and conspicuously state which mode(s) of communication their proposal addresses.

The channels targeted by TA2 solutions may be very specific. As a result, it is acceptable for a TA2 proposal to only be appropriate for specific environments due to their use of specific technologies (e.g., the targeted channel will leverage traffic from technology X, in environment Y, or both). TA2 proposals should clearly specify these constraints and discuss why they are

7 Auguste Kerckhoffs, "La cryptographie militaire" Journal des sciences militaires, vol. IX, pp. 5–83, January 1883,

pp. 161–191, February 1883.; Shannon, Claude. "Communication Theory of Secrecy Systems". Bell System Technical Journal. 28: 662.

http://www.petitcolas.net/kerckhoffs/ https://archive.org/stream/bstj28-4-656#page/n5/mode/2up

HR001118S0052 RESILIENT ANONYMOUS COMMUNICATION FOR EVERYONE (RACE) 12

appropriate. TA2 proposals should discuss how their technologies might work in environments that don’t satisfy these constraints. Strong TA2 proposals will clearly discuss the limitations of how their proposed approach would work in a real network environment.

Because a critical approach to the RACE system is testability, proposals should discuss the elements required to test their technologies within a simulated network environment. There are two primary components of this testability requirement. First, TA2 performers should plan on holding regular discussions with the Government provided Test and Evaluation (T&E) team in order to help increase the realism of the network environment. The relationship between TA2 performers and the T&E team will be collaborative rather than adversarial. Second, TA2 technologies must be testable. For the purposes of planning and cost estimation, proposers should assume that the test environment will be implemented within Amazon Web Services.

Accordingly, TA2 proposals should discuss how their solutions could be implemented and tested within a commercial cloud environment. For instance, solutions that require special hardware (e.g., gaming computers) or software (e.g., popular applications and their related back-end infrastructure) should explain how such systems could be either implemented or realistically simulated within such a commercial cloud environment in order to realistically test their proposed technology. Proposals should make clear their assumptions about the test environment, and propose mitigations in case their assumptions do not hold. Strong TA2 proposals should fully explain the testability of their solutions.

Strong TA2 proposals should justify their targeted channels within the objectives of the RACE program and TA2. Choosing too-rich channels within which to encapsulate can be nearly impossible to realistically model.8

Strong TA2 proposal should explain how their channel is measurable by the T&E team, testable, and there is reason to believe that statistical closeness can be demonstrated with respect to encapsulated communications within the channel. Strong proposals will also discuss how possibly unrelated network effects and traffic may affect proposed TA2 statistical models.

Strong TA2 proposals should explain why the targeted channel is such that it would be undesirable to simply filter out the entire channel in order to broadly filter the RACE system as well. Note that in-depth economic or other analysis of the value of the targeted channel is not required within this TA, however this motivation will help the proposer argue the applicability of their proposed solution.

Strong TA2 proposals should discuss how TA2 solutions can resist manipulation of the network environment. For instance, if a timing side-channel solution is proposed, why will this be resilient against the active introduction of random timing jitter across the network?

Strong TA2 proposals should discuss how TA2 solutions can retain the RACE TA2 security and functionality objectives even in the face of successful compromise of server nodes, clients, and their respective systems (to include TA2-related settings).

8 See, for instance: Amir Houmansadr, Chad Brubaker, and Vitaly Shmatikov. The Parrot Is Dead: Observing Unobservable Network Communications. In Proceedings of the 2013 IEEE Symposium on Security and Privacy (SP '13). IEEE Computer Society, Washington, DC, USA, 65-79.

HR001118S0052 RESILIENT ANONYMOUS COMMUNICATION FOR EVERYONE (RACE) 13

All TA2 proposals should discuss what, if any, communication is ever needed outside of the network environment (e.g., for initial setup).

TA2 proposers should discuss their experience creating code to obfuscated communication/protocol encapsulation technologies. TA2 proposers should fully explain why they will be able to work seamlessly with other RACE performers.

TA2 performers will be expected to work with TA3 integrators, as well as the T&E team, to determine desired code format and other interoperability issues. TA2 performers will be expected to regularly discuss range realism issues with the T&E team, particularly as it may relate to any data TA2 may gather in order to increase their understanding of targeted channel statistics. TA2 performers will be required to periodically deliver and integrate their code within a framework that the TA3 integrator specifies.

Metric Phase 1 (18 mo) Phase 2 (12 mo) Phase 3 (18 mo) Nodes: users/server 10 / 100 100 / 1k 10k / 1k Crypto key infrastructure

Assumed Not assumed Not assumed

Security Quantitative/ simulated evaluation

Statistical distance proof sketch

Statistical distance full proof

Adversary Passive Active link inject Link+node inject Logical bandwidth (server-server)

5 Mbps 10 Mbps 10 Mbps

Logical bandwidth (client-server broadcast)

100 kbps outgoing 500 kbps outgoing 500 kbps outgoing

Channel Model Simulation evaluation Proof (passive adversary)

Proof (active adversary)

Table 4: TA2 Metrics

Please note that topics of research that are specifically OUT OF SCOPE for TA2 include:

RF-based communication (other than IP-based mobile communication); and Techniques that are untestable other than by deployment in an actual network environment.

C.3 Technical Area 3: Integration

The primary objective of TA3 is the creation of a working RACE system prototype that maintains RACE security objectives listed in Table 1 (i.e., user metadata and “fact of” communication confidentiality, confidentiality of system node identity, etc.). It is anticipated this TA will also address initial system configuration/setup including implementation of key distribution methods required by TA1 teams. TA3 will develop the prototype RACE system, which includes a mobile application for communications, the software application for the system nodes, as well as integrate the application distribution approach from TA3.1 (discussed below).

TA3 will develop the system by incorporating technologies from the TA1 and TA2 teams into an integrated software suite.

HR001118S0052 RESILIENT ANONYMOUS COMMUNICATION FOR EVERYONE (RACE) 14

As mentioned in Section B.2, TA3 will develop the mobile client for a version of the Android operating system and the server nodes as an application on specific versions of the Windows and/or Linux operating systems. The server nodes should be executable on a (possibly high-end) home computer. Network connectivity/bandwidth of these systems should be assumed to be broadband (e.g. 20 Mbps+).

In the first phase of the program, it is anticipated the TA3 performer will design and develop a messaging architecture with a plugin interface for TA1 and TA2 technologies. As part of this initial capability, the TA3 performer will build an integration specification for the software suite which TA1 and TA2 teams will comply in Phase 2. It is expected that during the initial PI and integration meetings that the TA3 team will drive discussion of requirements from TA1, TA2, and TA3.1 teams in order to reach a design consensus.

In the second and third phases, it is anticipated the TA3 performer will create an integrated RACE system prototype. A large part of this task is to ensure that the overall RACE system that TA3 develops does not introduce attack surfaces that TA1, TA2, and TA3.1 have specifically been designed to reduce. Therefore, TA3 proposals should explain how they will integrate TA1, TA2, and TA3.1 technologies in such a manner that still maintains the larger RACE security and functionality goals. As an example, if TA3 creates fixed identities for server nodes that enable the compromise of many nodes once a single node is successfully compromised, such an outcome would run entirely counter to the design philosophy of RACE.

It is TA3’s responsibility to bridge the capability gap between the underlying TA1 and TA2 technologies and the needs of the integrated RACE system. Accordingly, TA3 proposals should discuss what additional capabilities they think need to be developed to enable the creation of a prototype RACE system. Such capabilities may include:

Networking technologies that can be built on top of TA2 communications links;

Technologies to counter denial of service attacks (e.g., by downloading many copies of the client system in order to overwhelm RACE server node capacity);

Technical mechanisms, to include mechanisms for trusted introduction, to help enable the introduction of new server nodes; and Technical mechanisms to leverage TA3.1 technologies to create (possibly trusted) introductions to help spread the mobile application to potential users.

The TA3 performer will lead bi-weekly telecons amongst the various other RACE performers.

The TA3 performer will lead quarterly integration meetings with all other RACE performers starting at the first PI meeting in Month 6. Every other such meeting will coincide with the bi-annual PI meetings. The TA3 team will host a shared, program-only software repository for TA1, TA2, and TA3.1 teams to deliver modules and for the T&E team to obtain artifacts to run their version of the messaging system infrastructure. This repository should support a shared workspace area (e.g. wiki, docs) as well. The TA3 performer will ensure that this repository incorporates appropriate cybersecurity controls (e.g., ensure latest system/security updates installed, multi-factor authentication to access the repository, etc.). The TA3 team should also maintain the ability to validate their system (though the most extensive testing, especially from an adversarial perspective, will likely only be doable within the T&E team’s environment).

Strong TA3 proposals should address how they will work to integrate TA1, TA2, and TA3.1 technologies from a software development perspective. Proposals should mention previous

HR001118S0052 RESILIENT ANONYMOUS COMMUNICATION FOR EVERYONE (RACE) 15

experience, if any, in managing diverse teams of academics and companies to develop complex systems. Proposals should discuss their approach to the design of the RACE system architecture and integration API/plugin system

Strong TA3 proposals should describe what additional capabilities will be needed on top of TA1, TA2 and TA3.1 technologies to build a useful, prototype RACE system and how the TA3 team will develop those capabilities. Strong proposals should discuss how their integrated system will achieve the needed RACE functionality and security objectives. In particular, proposals will discuss how their integration will maintain the security delivered by individual TA technologies.

Because a critical approach to the RACE system is testability, TA3 proposals should discuss the elements required to test their technologies within a simulated network environment. TA3 performers should assume that TA2 technologies are testable per the discussion in Section 1.C.2.

TA3 proposals should discuss how the integrated RACE system could be implemented and tested within a commercial cloud environment (e.g., Amazon Web Services), following the same line of issues outlined above in Section 1.C.2. TA3 proposals should make clear their assumptions about the test environment, and propose mitigations in case their assumptions do not hold. Strong TA3 proposals should fully explain the testability of their solutions.

TA3 proposals should discuss their experience developing systems relevant to the RACE server node and mobile application architecture.

TA3 performers will be expected to work with other TA teams well as the T&E team to determine desired code format and other interoperability issues. TA3 performers will be required to periodically release their system to the T&E team.

Metric Phase 1 (18 mo) Phase 2 (12 mo) Phase 3 (18 mo) Nodes: users/server 10 / 100 100 / 1k 10k / 1k

System Architecture Full prototype integration Full demo system

Adversarial exploitation Passive Active node exploitation

Full spectrum exploitation

Communications channels Mock channel Single TA 2 (server-server and client-server) channel

Switch between channels

Table 5: TA3 Metrics

C.4 Technical Area 3.1: Resilient Application Distribution

Performers in this TA will develop techniques as well as associated software to enable a distributed storage and reconstruction functionality for the RACE mobile app (and potentially for other RACE-relevant software). The goal is to distribute an application so that many RACE system nodes hold random-appearing data “shards” that can be used to reconstruct the application, and only after sufficient shards are collected will the application be recoverable. Not all shards are needed to accomplish reconstruction (the percentage of shards needed is a tunable parameter; for concrete performance metrics, see Table 6). The primary goal of this task is

HR001118S0052 RESILIENT ANONYMOUS COMMUNICATION FOR EVERYONE (RACE) 16

enable application sharding, shard storage, and reconstruction via shards. The challenge is to enable application sharding and reconstruction that supports immediate execution of the reconstructed output.

Any proposer can bid on this TA, not just TA3 proposers. For TA1 and TA3 proposers, TA3.1 may be bid as part of a combined proposal, but TA3.1 must be bid as a separable option. It is anticipated that there will be a single performer for this TA, but its selection determination may be separate from the other TA proposed and not being selected as the single TA3.1 performer does not automatically disqualify the remaining portion of your proposal from being potentially selected. This TA3.1 team will work closely with the main TA3 team to ensure the techniques developed are able to be integrated quickly into mobile app distribution.

The TA3.1 performer should create three functionalities: 1) take as input an application and split it into shards; 2) store and maintain these shards across service nodes; and 3) upon appropriate command (which will be determined by TA3.1 performers), reconstruct the application at a desired service node and/or mobile device. The TA3.1 performer will work carefully with the larger RACE team to ensure that these functionalities seamlessly integrate within the larger RACE system. This includes the fact that TA3.1-related communications must go over TA2 communications links (and therefore TA3.1 should assume a maximum communication bandwidth of 10 Mbps).

Just as for TA1, the TA3.1 performer should assume that server nodes may be compromised at a given rate. Proposers should describe how they will be able to add new app shards as server nodes are added or removed.

Strong TA3.1 proposals should be able to accomplish sharding such that the underlying identity of the sharded application cannot be determined. What is desired is that the “splitting” functionality described above first splits the application into underlying innocuous “gadgets” that, even if reconstructed, would not reveal the underlying functionality of the overall software functionality. These gadgets are then in turn cryptographically secret-shared.

Server nodes responsible for app shard storage and reconstruction may be the same or different from those required for message passing. The actual architecture will be determined in conjunction with TA3 and the larger RACE performer base.

The TA3.1 performer should be able to support Android, Windows, or Linux application splitting. The TA3.1 performer should be able to support server nodes that run either the Windows or Linux operating system. Proposers should assume that the Android device has sufficient permissions to download and install an application outside of the standard app store.

The main challenge for TA3.1 is the combination of the cryptographic sophistication combined with the need to create a concretely usable technological output. TA3.1 is an optional TA precisely because some TA1 proposers may not have the required software development experience, while some TA3 proposers may not have the required cryptographic experience.

TA3.1 will be expected to work with TA3 integrators to determine desired code format and other interoperability issues. The TA3.1 performer will be required to periodically deliver and integrate their code within a framework that the TA3 integrator specifies. TA3.1 proposals should discuss their experience creating code to implement cryptographic protocols (e.g., secret

HR001118S0052 RESILIENT ANONYMOUS COMMUNICATION FOR EVERYONE (RACE) 17

sharing) as well as application splitting and recombination. TA3.1 proposals should fully explain why they will be able to work seamlessly with other RACE performers.

Metric Phase 1 (18 mo) Phase 2 (12 mo) Phase 3 (18 mo) Crypto adversary / corruption level Passive / 20% Active / 10% Active / 20%

Crypto key infrastructure Assumed Not assumed Not assumed Node refresh Demonstrate 1/year 1/month

Logical sharding Demonstrate Atomic functionalities Innocuous “gadgets”

Nodes: total that hold shards/needed to reconstruct a single app

50/10 250/30 1000/50

App reconstruction 10 min 5 min 5 min

App size 1MB 10 MB 50 MB

Table 6: TA3.1 Metrics

C.5 RACE Performer Collaboration Summaries

The following table outlines the expected collaboration efforts between the various TA teams:

TA (Bidirectional) Collaboration Required TA1 Work within the TA3-provided system development framework to transition code to perform MPC and/or other cryptographic technologies. Aid the TA3 team in constructing distributed system architectures and/or hierarchies that correspond to those required by TA1-developed MPC protocols.

Work with TA2 team to support any cryptographic key generation and distribution that may be required for TA2 channels; communicate with TA2 team to ensure that MPC-related communication links correspond to those being developed within TA2

TA2 Work within the TA3-provided system development framework to integrate TA2 communications capabilities into the RACE system architecture. Ensure that TA2 communications link security properties are maintained by TA3 implementations.

Work with TA3.1 team to ensure that communications links correspond with communications needs associated with resilient application distribution.

Work with T&E team to help ensure testing range realism;

communicate desired capabilities the T&E environment should replicate in order to support TA2 technologies (but see also the testability requirements discussed in Section I.C.2).

TA3.1 Work within the TA3-provided system development framework to integrate TA3.1 application distribution capabilities into the RACE system architecture. Work with the TA3 integrator to ensure that server node capabilities and architectures appropriately support TA3.1 technologies.

HR001118S0052 RESILIENT ANONYMOUS COMMUNICATION FOR EVERYONE (RACE) 18

TA3 Work with the T&E team to communicate desired capabilities that the T&E environment should replicate in order to support testing the integrated RACE system.

Table 7: Performer Collaboration Summary

D. Program Capability Demonstration

A key part of the RACE program is demonstration of capability in a realistic network environment. The T&E team will create a realistic environment within which to deploy and evaluate technologies built by the other RACE teams. The goal for the T&E team is to create environments that support both realistic scale and functionality of network environments. This testbed will be utilized for testing both large scale distributed computation tasks created by TA1 teams as well as modelling third party communications channels need by TA2 teams in order to obfuscation their communication within it. TA2 performers are in particular expected to work closely with the T&E team in order to help ensure network environment realism. The T&E team will participate in the quarterly integration meetings to cover testbed-specific matters, to include measures to ensure testbed realism. The T&E team will run the main test environment which will scale up to support testing within the metrics for each TA. This includes hosting virtual clients, compute nodes, network infrastructure (routers, firewalls, taps), storage (e.g. for packet capture), and nodes required to implement TA2 channels as needed. The testbed will be instrumented to observe and capture network traffic as might happen in large network environments (e.g., at simulated ISP connection points, gateway routers, etc.). For the purpose of this BAA, proposers should assume that the T&E test environment will be implemented within Amazon Web Services.

Note that general functional testing is expected to be performed separately by individual TA teams and the integration team. In particular, the T&E-developed simulated environment will be used to test RACE performers; it is not a development or prototype testing environment.

However, as the program progresses, performers will have the ability to periodically “scrimmage” within the T&E environment before each end-of-phase evaluation is conducted.

The T&E team will also act as the voice of the adversary. The primary focus of the voice of the adversary is to try to degrade or deny RACE system functionality and to try to turn small victories into larger ones. The two primary components of this effort will be: 1) evaluate RACE system communications traffic in order to try to violate the observability security properties (see Table 1) and/or to filter or otherwise manipulate RACE communications traffic; and 2) evaluate data resident on the RACE client application and system nodes in order to try to target other, not currently exploited RACE system participants. Actual exploitation of RACE system software, e.g., by developing implants and/or exploits, will not be a focus of the voice of the adversary effort; it will just be assumed that the adversary can successfully exploit RACE systems and software as desired.

From an overall system testing perspective, the T&E team will be testing increasingly complex variants and increasing the adversary’s capabilities over the program lifetime. Table 8 shows the high level testing goals.

HR001118S0052 RESILIENT ANONYMOUS COMMUNICATION FOR EVERYONE (RACE) 19

Phase 1 (18 mo) Phase 2 (12 mo) Phase 3 (18 mo)

Testing emphasis and adversarial capabilities

Test unintegrated, individual TA technologies assuming a passive adversary

Test initial integrated RACE system prototype assuming an adversary who can 1) manipulate TA2 links in transit and 2) actively corrupt system nodes and users to try to break MPC-secured functionalities of TA1 and TA3.1 (but not to break TA2 links)

Test full RACE system via active link and node injection and manipulation for TA1, TA2, and TA3.1 technologies

Table 8: Test and Evaluation Progression

It is intended that the T&E team will consist of FFRDC and/or UARC participants. As a result, DARPA is not soliciting proposals for the T&E team under this BAA.

E. Schedule and Milestones

DARPA anticipates a March 2019 start date for the RACE program. The program will run for 48 months and has been organized into three (3) phases. Phase 1 will be 18 months, followed by a 12-month Phase 2, and then concluded with Phase 3 at 18 months. See Figure 1 for details.

There will be biannual PI meetings held in conjunction with demonstrations to review technical progress and provide an opportunity for face-to-face collaboration. T&E system evaluations will be conducted three months prior to each PI meeting starting in month 9 in order for results to be available for review and discussion.

M ar

-1

Ap r-

M ay

-1

Ju n-

Ju l-1

Au g-

Se p-

O ct

-1

N ov

-1

De c-

Ja n-

Fe b-

M ar

-2

Ap r-

M ay

-2

Ju n-

Ju l-2

Au g-

Se p-

O ct

-2

N ov

-2

De c-

Ja n-

Fe b-

M ar

-2

Ap r-

M ay

-2

Ju n-

Ju l-2

Au g-

Se p-

O ct

-2

N ov

-2

De c-

Ja n-

Fe b-

M ar

-2

Ap r-

M ay

-2

Ju n-

Ju l-2

Au g-

Se p-

O ct

-2

N ov

-2

De c-

Ja n-

Fe b-

Phase

Month # 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 Kickoff Meeting ▲ PI Meeting ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ Integration Meeting ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲

TA1

Code Release

TA2

Code Release

TA3

Integration Specification

Code Release

Integration Test

TA3.1

Code Release

T&E

Testbed Specification

Testbed Scrimmage

End of Phase Evaluation ▲ ▲ ▲

Phase Scope/Metrics ▲ ▲ ▲ Month # 1 2 3…