Q: Are power supply attacks in scope for SSITH? A: The hacker team will not have physical access to the power supply.

Transcription

1 SSITH FAQ Questions about the Scope of SSITH Q: Is securitization of external memory in the scope for SSITH? A: Yes. Please refer to BAA section I-B, page 6. Q: Is reverse engineering research of integrated circuits in scope for SSITH? A: No. Please refer to BAA section I-B, page 7. Q: Is the securitization of SoC applications in the scope for SSITH? A: Yes. Please refer to BAA section I-B, page 6. Q: Are quantum computing attacks in scope for SSITH? A: No. SSITH is confined to classical computing. Q: Are power supply attacks in scope for SSITH? A: The hacker team will not have physical access to the power supply. Q: Are row hammer attacks in scope for SSITH? A: Yes. Please refer to BAA section I-B, page 6. Q: Are electromagnetically induced side channel attacks in scope for SSITH? A: No. Please refer to BAA section I-B, page 7. Q: Are security performance monitors in scope for SSITH? A: Yes. Please refer to BAA section I-B, page 6. However, please note that any security performance monitors should be able to run on the FPGA demonstration platform. Q: Are government recommended algorithms, such as NSA/NIST approved encryption algorithms, considered in scope for SSITH? A: Yes. Q: Are attacks during boot up in scope for SSITH? A: Yes. Please refer to BAA section I-B, page 6. Q: Is data protection in scope for SSITH. A: Yes. Please refer to BAA section I-B, page 7. Q: Must all security solutions be formally verified? A: No, but each performer must demonstrate security assurance completeness.

2 Questions about Hardware/Software/OS Modification, Configuration, Architecture and IP Q: Within SSITH, are solutions that are implemented as a side or slave processor acceptable? A: A side processor is in scope. It would have to be possible for the slave processor to be integrated and run on the FPGA demonstration platform. Q: Can an application be recompiled to enable securitization? A: Yes, as long as the unmodified software can run on the securitized processor after being recompiled. In general, the less modification to software required to take advantage of security features, the better. Q: Within SSITH, can a performer modify the ISA? A: A performer can modify the ISA so long as the unmodified software that ran on the unmodified system still runs. Q: Will the performers be able to modify the operating systems in their system stack? A: Yes, as long as software that runs on the unmodified OS still runs successfully. Q: Can a user add a layer of software or firmware to the system to implement their security approach? A: Yes. PPASS impact of the intermediate layer will need to be evaluated. Q: Within SSITH, can a performer use a high level language IP such as CHISEL? A: Yes. Q: Will the standard applications that need to run natively be available to TA-1 performers? A: Yes. In general, all software that can run on the unmodified system should be executable on the securitized system. Q: How generalizable or scalable is the SSITH architecture expected to be? A: Please refer to BAA section I-D, page 8. Q: Can graceful failure be considered a design target of SSITH? A: Yes. It is expected that graceful degradation will be appropriately flexible for the scale and purpose of various systems. Q: Will the performers be expected to use an open source operating system? A: A fully specified OS will be provided to all performers as part of the FPGA evaluation exercise. Q: Will performers be permitted to add cache to their security architectures? A: So long as it is implementable on the FPGA demo platforms, and meets PPAS requirements, performers will be permitted to add or extend caching to their architectures. Q: Is proprietary IP allowed as part of a SSITH proposal? A: Yes. However, please refer to BAA section IV (page 36) for an explanation of the evaluation criteria.

3 Questions about CWE classes Q: How broad a solution does the proposer s architecture have to be? Does it have to address all seven CWE classes? A: By the last phase of the SSITH program, it expected that performers will address all seven CWE classes. Please refer to BAA Table 2. TA-1 Metrics by Phase for details. Questions about Proposing to TA-1 and/or TA-2 Q: Within SSITH, can a company propose to both TA-1 and TA-2 A: Yes. Please refer to BAA page 21, Section IV.B.1. Full Proposal Format. Q: Will it be possible to propose as a lead on TA-1 and a sub-contractor on TA-2? A: Yes. Questions about SSITH Program Structure Q: Will a required down selection be included in the SSITH Program? A: No. Q: How much visibility will a TA-2 team have within the SSITH Program? A: Please refer to BAA section III E, page 19. TA-2 Team(s) will have access to all TA-1 performer information that is required to establish/evaluate security metrics and develop hardware security representations. TA-2 Team(s) will be involved in regular TA-1 to TA-2 interactions. Q: Is security tool flow development to be included in TA-1 or TA-2. A: TA-1. Please refer to BAA section I-D, page 8. Questions about the Hacker Teams Q: If a proposer uses CHISEL or Bluespec, will the source code be presented to the hacker teams? A: During the evaluation, the hacker team will have access to the unsecuritized application, OS, and design. Any security modification to either the RTL or the FPGA bit stream will not be provided to the hacking teams. Q: Will the evaluator/hacker teams be permitted to use firmware attacks? A: Hacker teams will be permitted to use any software that is not embedded in the FPGA board/system. Q: Will the hacker/evaluator teams attack the unmodified design or the securitized design? A: The hacker teams will attack the securitized design.

4 Q: For the purposes of the hacker team testing, what will be considered a successful hack? A: When the hacker team can either exfiltrate unauthorized data, or modify the operation of the system in an unauthorized way, this will be considered a successful hack. Q: Hardware assisted secure boot would the hacker team be able to interrupt the secure boot bit stream? A: The hackers would not be permitted to interrupt the secure boot bit stream. Q: Will it be possible to add malicious code to the hacker system? A: Yes. Hacker teams will be able to use malicious code as long as the code is outside of the confines of the FPGA system. Q: What will the hacker teams have access to? A: The hacker team will have access to the system I/O ports and wireless connections. Hackers will not have access to anything within the FPGA box. Q: Will the hacker team have access to on-chip cryptographic keys in order to penetrate the systems under test? A: No. Q: Will clock glitching or power glitching by the hacker teams be permitted? A: Clock or power glitching will be allowed by the hacker teams as long as the glitching mechanisms are implemented through software. Questions about Tool Flow and IP Licensing Q: How should proposers deal with possible tool flow licensing and IP licensing? A: If IP or EDA tool licensing is required for SSITH development, include those costs in the proposal. Questions about the SSITH RISC V Demonstration Platforms Q: Is there going to be a tool chain that comes with the RISC V demonstration platform? A: Publically available RISC V tools (toolchain, ISA simulator) will be provided with the FPGA development kit. Q: Must performers demonstrate security function on all three RISC-V platforms that are provided? A: Yes. Please refer to BAA Table 1 on page 10.

5 Second FAQ for SSITH Q: The BAA currently states that the most complex design will be a full featured, multi-threaded, out of order execution RISC-V processor. Is the most complex design to be addressed within SSITH a single core but multi-threaded design, or a multi-core design A: For the proposal, assume that the most complex RISC-V design will be similar to the Berkeley BOOM RISC-V microprocessor. Q: How many PI meetings and site visits will be held over the course of the SSITH Program? A: There is no set number of such events and each proposal should use their own assumptions for budget purposes.. Q: If we change the RISC-V RTL such that it has a different number of threads (as a result of a generic technique for any processor), how will performance be evaluated, per thread or in the aggregate? A: Performance and the other metrics will be evaluated in aggregate. Q: Will the RISC-V RTL provided as GFE be made artificially weak? If performers provide their own RISC- V RTL, who would be responsible to make sure all RTLs are similarly weakened? A: The unmodified RISC-V RTL and OS will be provided as GFP. Q: For cryptography errors CWE, what are the assumptions about the two ends of encrypted communication? If the two ends are both within the same platform, something could be done to strengthen the weaknesses induced by weak keys and hashes. But if the two ends are two different platforms, what would you expect beyond detection of a weak key/weak hash exception? A: The performer should make required assumptions, and clearly state them in the proposal. Q: Do performers need to address denial of service attacks? A: Yes, SSITH solutions must address denial of service attacks. Please refer to BAA section I-D, page 9. Q: Are the power, performance and area overhead targets in SSITH BAA Table 2 relative to all digital logic on the design, or to the complete SoC? A: Power, performance, area overhead targets in SSITH BAA Table 2 pertain to the complete SoC.

6 Q: Is there a particular view in the CWE database that was used to identify the seven CWE classes of hardware based vulnerabilities discussed in the BAA? Would it be possible to provide examples of each of the seven CWE/CVE vulnerability classes? A: Please refer to the BAA Attachment 3. Q: Do the references to cryptography or crypto-errors in the BAA make any assumptions about the level of cryptography or the method of implementation of the cryptography? A: Please refer to the BAA Attachment 3. Q: For the SSITH program, is there a restriction on foreign nationals performing work in their home countries? Is there a distinction between Tier 1 and Tier 2 countries? Is there a maximum amount of work that can be performed at US universities? A: Please refer to BAA section IV, starting on page 34. Q: Is there a preference or requirement on the minimum budget or size of the team? Will the program planning to select a small number of large teams, or is it open for small teams? A: The total funding amount for the program will be approximately $50M as noted in Part 1, page 4 of the BAA. The budget and size of each team should be appropriate for the proposed technical approach. Q: Is there a preference or requirement for university teams to have an industry partner? A: No. Q: For SSITH, the performers will receive RTL as government furnished equipment. Is it in scope to recode or rework the government furnished RTL into a higher level language? A: Yes. Please refer to BAA section I-D, page 8. Q. Is a multi-core processor (with multiple Rocket cores or multiple BOOM cores) within the scope of the SSITH program? Or is the focus of the SSITH program primarily focused on securing single core processors? A: Yes. SSITH proposals should address securitized versions of a broad range of commercial and DoD applications. Please refer to BAA section I-D, page 8.

7 Q. Can two different teams with non-overlapping PIs/Co-PIs from the same university (or from the same company) submit two completely separate proposals for SSITH TA-1. A: Yes.

8 Third FAQ for SSITH Q: There is a list of evaluation metrics for TA-1 (item 3 in TA-1 Key elements, pg. 8), as well as a table quantifying those metrics (table 2: TA-1 Metrics by Phase, pg. 11). However, there is no discussion in the BAA of evaluation metrics for TA-2. How will TA-2 teams be evaluated by DARPA? A: Refer to the TA-2 evaluation criteria described in SSITH BAA section I-D starting on page 11. Q: Eligibility criterion D.2. ( Ability to Receive Awards in Multiple Technical Areas - Conflicts of Interest (COIs) ) states, While proposers may submit proposals for both Technical Areas 1 and 2, proposers may not be selected for both Technical Area 1 and for Technical Area 2, whether as a prime, subcontractor, or in any other capacity, from an organizational to an individual level. Is any other capacity intended to cover only those situations where a proposer would receive funding, directly or indirectly, through both a TA-1 and a TA-2 proposal, or is it intended more broadly to cover any involvement whatsoever? Here are two specific examples that we need addressed: 1. If a company is a TA-1 subcontractor (receiving funding from DARPA), is it permitted for an individual within that company to play a non-funded advisory role in a TA-2 project? 2. If a company licenses their software to TA-1 contractors, are they also permitted to license their software to TA-2 contractors? A: 1. No 2. Yes Q: Is DARPA going to provide RTL for a given ISA or set of ISAs? Could proposers instead provide their own ISA, provided it is compatible with running the application? A: For evaluation purposes, the government will furnish RTL and FPGA bitstream for 3 different RISC-V processor designs as described in SSITH BAA section II-G, starting on page 14. Q: In order to validate the operation of the existing code on the enhanced box, DARPA must have some test cases with associated test data. When can performers have the test cases and test data with respect to the point at which the testing will take place (by DARPA Hackers)? The difference between an hour, a day, a week, and a month or more could have a significant impact on the results. Will DARPA be providing millions of lines of code? Hundreds of thousands? Less than 1000 SLOCs that are not OS? A: Government Furnished Property/Information will be provided at the beginning of Phase 2 as noted in the SSITH BAA section II-G, starting on page 14. Proposers can also stipulate any proposal assumptions regarding GFP in their proposal.

9 Q: What is the reference power spec for Power Impact = 0%? In Phase 2, the program provides FPGA boards with RTL designs of three sizes of RISC-V processors. Does this imply the reference power spec. is the power requirement for the synthesized version of these three provided RISC-V processors? A: All PPASS metric comparisons will be made with respect to the un-securitized SoC, as noted in the SSITH BAA section II-D, page 9. Q: The program requires software compatibility for existing software. Since the program provides RTL hardware designs to enable a PPA impact assessment, will the program provide any software instances or benchmarks to help quantify software compatibility metrics? A: Refer to the SSITH BAA section II-G, starting on page 14 for a description of Government Furnished Property/Information.