The red teams will compete to recover locked designs. Teams will be judged on how many designs they attack successfully, and under which attack models. Currently, we envision the following attack scenarios (get in touch if you want to propose other modes of attack/aims):
1. Gain secret key without access to an oracle.
- Threat model: an untrusted foundry.
- Metric: key recovered.
- Scalability: small, medium and large key sizes/designs.
2. Gain secret key with access to an oracle.
- Threat model: untrusted foundry + commercially available IC.
- Metric: key recovered.
- Scalability: small, medium and large key sizes/designs.
3. Produce a functionally equivalent netlist (without oracle access).
- Threat model: untrusted foundry.
- Metric: pass equivalence checking.
- Scalability: small, medium and large key sizes/designs
4. Produce a functionally equivalent netlist (with oracle access).
- Threat model: untrusted foundry + commercially available IC.
- Metric: equivalence checking.
- Scalability: small, medium and large key sizes/designs.
5. Produce an approximately functionally equivalent netlist.
- Threat model: untrusted foundry.
- Metric: % of functionality recovered.
- Scalability: small, medium and large key sizes/designs.
6. Produce an approximately functionally equivalent netlist. The defender has a set of test vectors that have to match.
- Threat model: untrusted foundry + commercially available IC.
- Metric: % of functionality recovered.
- Scalability: small, medium and large key sizes/designs.
7. Demonstrate the effectiveness of approximately unlocked modules in building workable system architectures
- Threat model: untrusted foundry + commercially available IC
- Context: building architectures which work despite having locked modules
As a bonus we may also evaluate:
8. Scalability: Time to recover key relative to complexity of the design and size of the key) for cases 1-6
- Threat model: all of the above
- Metric: all of the above