COOP_QA_4.9.2024.pdf

Con nuous-correctness On Opaque Processors (COOP) Frequently Asked Ques ons (FAQs)

Ques on #1: Is source or binary legacy compa bility with certain pla orms par cularly desirable (Opera ng System (OS), Virtual Machine Monitor (VMM), microkernel, instruc on set, etc.)?

Answer #1: Defense Advanced Research Projects Agency (DARPA) cannot comment on specific approaches. DARPA is open to solu ons that meet COOP program goals and metrics. As described in the Broad Agency Announcement (BAA), proposers should describe assump ons, risks, and mi ga ons in the proposal.

Ques on #2: What types of Controlled Unclassified Informa on (CUI) data and data formats should we be prepared to process?

Answer #2: There are no specific CUI data formats and data to process. Please refer to A achment G of the BAA for CUI guidance pertaining to COOP.

Ques ons #3: Will the program pay for Mul -Project Wafer (MPW) costs or should these be es mated in pricing for Op on II?

Answer #3: Please refer to Sec on 1.4 “Program Structure” of the BAA for informa on on mul -project wafer services. It is possible that the Government procure MPW services which will allow the Government to exercise Op on 2 without exercising Op on 3. If the Government is unable to secure or pay for a fabrica on and packaging effort, then Op on 3 may be exercised so the performer can procure the services themselves.

Ques on #4: What happens if DARPA picks a MPW process type?

Answer #4: Please consider clarifying the ques on and resubmi ng.

Ques on #5: In Phase I, can [proposers] use open-source hardware?

Answer #5: Yes, a technical solu on may include open-source hardware provided it meets program goals and metrics.

Ques on #6: Will the slides and proposers list be provided?

Answer #6: The slides will be posted. Please see Sec on IV of the BAA for a endee list requests.

Ques on #7: Overhead? Power overhead? Latency overhead? Area overhead? All of the Above?

Answer #7: Please consider clarifying the ques on and resubmi ng.

Ques on #8: Can a university be a fundamental research sub-contractor to a Prime in this work, or do all publica on restric ons have to flow down?

Answer #8: Per Sec on IV of the BAA, while DARPA does not envision ready opportuni es for Fundamental Research, either at the prime contractor or subcontractor level, under COOP, proposers are free to propose Fundamental Research (either by the prime or subcontractor) provided details are included to jus fy how the inclusion of Fundamental Research will s ll enable the COOP goals and objec ves to be met.

Ques on #9: In Phase I, are [proposers] going to work with so ware generated by the Secure Mathema cally Assured Composi on of Control Models (SMACCM) approach, or is it men oned so that [proposers] assume the trustworthiness of the control so ware?

Answer #9: With regards to trustworthiness of the mission cri cal so ware, please refer to Sec on 1.3 “Informal Threat Model” within the BAA. Any assump ons on which the technical approach is based should be described clearly in the proposal. SMACCM is used as an example mission cri cal so ware.

Ques on #10: [Should proposers] assume the presence of a trusted OS/VMM?

Answer #10: Proposals should describe assump ons, the threat model, and control boundaries. This includes which hardware and/or so ware can be considered opaque.

Ques on #11: Is the target embedded, general purpose systems or both?

Answer #11: DARPA cannot comment on specific approaches. Please see Sec on 1.5 “Major Milestones” in the BAA for examples of processor types on which the COOP solu ons will be demonstrated.

Ques on #12: In Phase I – Simulators- Are these built by the performers or Government Furnished Equipment (GFE)?

Answer #12: DARPA cannot comment on specific approaches, to include the purchase/fabrica on of devices or requests for Government Furnished Informa on (GFI)/GFE. Proposals must describe any such needs or assump ons.

Ques on #13: How do False Posi ve (FP)/False Nega ve (FN) targets relate to detec on probability target?

Answer #13: As per Sec on 1.2 “Program Descrip on” of the BAA, the false posi ve and false nega ve metrics are assessed using IV&V designed test cases.

Ques on #14: Can [proposers] rely on new features of upcoming commercial off the shelf processors to achieve COOP program goals?

Answer #14: Proposers can rely on any features of commercial-off-the-shelf processors. However, proposers should describe related risks and mi ga ons, such as if the features are not in the final product or if the features are disabled.

Ques on #15: Can changes to processor die be proposed if [proposers] show that they would be suitable for wide commercializa on?

Answer # 15: DARPA cannot comment on specific approaches, to include how a proposer may plan to show suitability for wide commercializa on. Please describe any risks and mi ga ons to include the risk of commercializa on failure. Also see Ques on #14.

Ques on #16: Ques on about the 99.9999…% accuracy:

is it with respect to a physical model that has been fed to a formal method tool, or it is with respect to the physical world?

In other words, is the gap between the physical world and its formal model included in the 99.99%?

Answer #16: The metric is based on the threat models and assump ons in each proposer’s technical proposal. Please also see the Phase I (Base) paragraph in the “Program Structure” sec on of the BAA.

Ques on #17: In one of the “proposed approaches”, namely the “prover-verifier” one, are you referring to “prover” and “verifier” as in

Crypto? As in proof of computa on or zero-knowledge (e.g. Securing Informa on for Encrypted Verifica on and Evalua on (SIEVE) program @ Informa on Innova on Office (I20))?

Or as in logic/theory proving? As in proof-scratch and proof-checking (e.g. in a proof assistant)?

Answer #17: DARPA described poten al approaches in the slides, not proposed approaches. Please consider rephrasing the ques on and resubmi ng.

Ques on #18: Can [DARPA] provide example Commercial-off-the-shelf (COTS) Central Processing Units (CPUs) for: single-threaded, mul -threaded, high performance. Out of order? Branch Predic on? CPU Clock Rate?

Answer #18: Proposers should specify which specific processor instances they plan to use. Please also see the “Major Milestones” sec on in the BAA for examples of processor types on which COOP solu ons will be demonstrated.

Ques on #19: It appears that all common threats that do not involve a computa onal error are out-of-scope (leakage, so ware errors, calculated connec vity but leads to underserved opera onal control floor, ex?) Can DARPA confirm whether this is true?

Answer #19: Please refer to the 2nd paragraph of sec on 1.3.1 of the BAA.

Ques on #20: Are [proposers] required to develop a solu on that uses a custom Applica on Specific Integrated Circuit (ASIC) and price it out in op on 2&3? Or can [proposers] propose alternate (non-fabrica on) approaches?

Answer #20: No, proposers are not required to develop a solu on that uses a custom ASIC. Proposers are free to propose any technical solu on that will meet program goals and metrics.

Ques on #21: Are so ware glitching / fault tolerance approaches in scope?

Answer #21: DARPA cannot comment on specific approaches. Proposers are free to propose any technical solu on that will meet program goals and metrics.

Ques on #22: Are approaches that reduce the ability of the a acker to know if COOP is deployed required? Valuable? Interes ng? Out of scope?

Answer #22: DARPA cannot comment on specific approaches. Proposers are free to propose any

Ques on #23: Can [proposers] focus on processor types possessing certain types of monitoring features, e.g., instruc on training?

Answer #23: DARPA cannot comment on specific approaches. Proposers are free to propose any technical solu on provided that will meet program goals and metrics.

Ques on #24: Is a Field Programmable Gate Array (FPGA) with mul ple so cores acceptable for Phase I?

Answer #24: DARPA cannot comment on specific approaches. Proposers are free to propose any

Ques on #25: Is in-package more desirable than off-package?

Answer #25: DARPA cannot comment on specific approaches. Proposers are free to propose any technical solu on provided that will meet program goals and metrics.

Ques on #26: [Is DARPA] opposed to a chiplet based approach instead of System on Chip (SOC)?

Answer #26: DARPA cannot comment on specific approaches. Proposers are free to propose any

Ques on # 27: Will [DARPA] accept an open-source process as a component or target of solu on?

Answer #27: DARPA cannot comment on specific approaches. Proposers are free to propose any technical solu on that will meet program goals and metrics. Please also see Ques on #5.

Ques on #28: Is a solu on that works for embedded or limited func on systems (but not general purpose) acceptable?

Answer #28: DARPA cannot comment on specific approaches. Proposers are free to propose any

Ques on #29: Will [DARPA] accept a modified processor architecture?

Answer #29: DARPA cannot comment on specific approaches. Proposers are free to propose any technical solu on that will meet program goals and metrics. Please also see Ques ons #14 and #15.

Ques on #30: FP/FN metrics depend on the base error rate. E.g. if I have 1% error rate, it is trivial to classify with FN=1%. What is the base error rate?

Answer #30: Please see Ques on #13.

Ques on #31: Regarding the false nega ve and false posi ve rates, what is the countable en ty the percentage is calculated against? Percent of what?

Answer #31: Please see Ques on #13.

Ques on #32: How does accuracy metric relate to FP/FN metrics?

Answer #32: The accuracy and FP/FN metrics are different. Please refer to the BAA, Ques ons #13 and #16.

Ques on #33: [It was] men oned [during the Proposer’s Day briefing] that this is targe ng integrity more so than availability, but what about confiden ality compromises? They seem more difficult to detect over ming/accuracy errors.

Answer #33: Please see Ques on #19.

Ques on #34: Please iden fy the mechanism for proposers to submit abstracts.

Answer #34: Both abstracts and proposals must be submi ed using DARPA’s Broad Agency Announcement Tool (BAAT). This can be accessed via the Proposer Instruc ons: General Terms and Condi ons (darpa.mil) page, in the Unclassified Submission Instruc ons sec on.

Ques on #35: Can proposers solely use digital side channels for the COOP solu on?

Answer #35: No. As per defini ons described in the BAA, using digital-side-channels only implies that the manifesta ons of so ware running on hardware are not physical and therefore does not link so ware with physics. Proposers could use digital-side-channels as part of their proposed solu on (i.e., use mul -modal-side-channels).

Ques on #36: Does COOP have small budget caps (e.g., $5M per performer) like other MVPs (minimal viable programs)?

Answer #36: COOP is a two-phase program as outlined in the “Program Structure” sec on of the BAA.

Proposers should propose an approach and budget that they believe is necessary to achieve the COOP program goals and metrics rather than a empt to meet a perceived budget cap. Proposed budgets are evaluated in accordance with the “Cost and Schedule Realism” sec on of “Sec on II: Evalua on Criteria” in the BAA. A budget that is too high or too low could be evaluated as not realis c.

Ques on #37: Can [proposers] assume that the adversary is limited to 1800W (120V x 15A) of compute power in my threat model?

Answer #37: Yes, this physical limita on is consistent with the COOP threat model (Sec on 1.3.2) and COOP boundaries (Sec on 1.3.3) discussions of the BAA. Proposals that use this or similar defini ons in their threat models should also include a discussion on how their technical approach can scale to larger compute environments (e.g., server class power supplies).

Ques on #38: What does “abstract en ty” mean in the “Oracle” defini on?

Answer #38: The BAA defines an oracle is “an abstract entity used in formal methods to represent the axiomatic source of correct answers”. “Abstract” means it can be used in formal argumentation but cannot be used in real implementations because real-world oracles do not exist. Proposed solutions that rely on oracles such as "golden processors" to execute mission critical software (MCS) rather than having the opaque processor execute MCS are out of scope for COOP. Approaches that execute a portion of an MCS on an assumed to be trusted processor as part of a formal verification setup are in scope. Proposed solutions such as one that uses an abstract machine implementation of a formal specification as a "golden processor" to reason about important characteristics of the MCS and physics are also within scope.

Ques on #39: Can [DARPA] provide addi onal examples of MCS?

Answer #39: In addi on to control so ware such as SMACCM (Secure Mathema cally Assured Composi on of Control Models), other examples of MCS include, but are not limited to, image processing, PNT (posi on, naviga on, and ming), and policy enforcement so ware.

Ques on #40: Is a trusted processor design that is correct-by-construc on in scope?

Answer #40: There is insufficient informa on to answer this ques on; please consider rephrasing the ques on and resubmi ng if the following response does not answer the intended ques on. Correct-by-construc on solu ons are in scope as long as they meet the program goals and metrics. Instances where correct-by-construc on solu ons are not in scope include, but are not limited to, 1) a trusted processor that serves as a “golden processor” execu ng MCS rather than having the opaque processor execute MCS (see Ques on #38); 2) correct-by-construc on techniques does not link MCS to physics; 3) a trusted processor design that is limited to a single type of digital processor.

Ques on #41: I already accomplished the program goals as part of [another research effort], is there a way to bid to directly commercialize the technology?

Answer #41: No, all proposals must be submitted and evaluated in accordance with the BAA. Proposers should not assume that reviewers are familiar with the team's previous work or results. Proposers should not assume that reviewers will read any or all references. The proposal narrative should include a description of what the referenced technique, insight, or result is and why it applies to COOP rather than stating the claim as fact.

Ques on #42: Can [DARPA] clarify what a proposed threat model should consist of?

Answer #42: The threat model is the founda on for the logical presenta on of the proposed technical approach. It should contain 1) a clear descrip on of what proper es are needed to sa sfy the program goals; 2) a clear descrip on of fundamental assump ons including a descrip on of the oracle(s) being used (if applicable) and a list of trusted and untrusted components (this helps set the boundaries to which the proposed approach is valid); 3) a clear descrip on of the threats and their capabili es (this further bounds the problem by se ng limita on on the what adversary can do). The rest of the proposal should build upon this threat model.

Ques on #43: Can [proposers] assume that the source code for MCS is available?

Answer #43: Yes. If proposers make this assumption, it should be clearly stated as part of the threat model.

Ques on #44: Can [proposers] assume that the opera ng system is coopera ve? For example, interrupts will be processed correctly and on me?

Answer #44: As defined in the BAA, non-MCS including the operating system are opaque and therefore deterministic. Deterministic does not mean correct and on time. In the example, interrupts may be processed incorrectly or at the wrong time, but this erroneous behavior is deterministic. Similarly, the erroneous behavior might be the result of a bug or an attack by an adversary. In either case, the behavior and result are still deterministic. In this sense, the operating system is neither cooperative (as in helpful) nor non-cooperative.

Question #45: Can [proposers] use a published threat model instead of presenting a new one?

Answer #45: Yes, proposers can use a published threat model as long as it is also clearly described in the required threat model section. Proposers should not assume that reviewers will read any or all references. Please also see Question #41.