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? 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? 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? 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? 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? Q: Are attacks during boot up in scope for SSITH? Q: Is data protection in scope for SSITH. 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? 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? Q: Will the standard applications that need to run natively be available to TA-1 performers? 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? 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? 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 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? 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? 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? 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? 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? 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.