Benchmarks

Last updated: Mar 4th 2022

Sample Benchmarks

This link points to the ZIP bundle of the sample benchmarks, which are different layout implementations for an AES circuit, designed using the Nangate 45nm library.

Note that these sample benchmarks are intended for warm-up on the theme and the problem formulation. They contain some examples for baseline versus somewhat hardened/protected layouts. Recall that there is no single, right or wrong approach for the contest — it is up to your creativity and skills to come up with the best defense solutions.

The ZIP includes the post-layout netlists, the DEF files, the layout databases for Cadence Innovus and supporting files, also for Synopsys ICC2 and OpenROAD. Note that some files are empty (0 bytes); they are not relevant but still kept such that the tool flows don’t throw any warnings/errors about those files missing.

There are three different layouts for the AES implementation in the ZIP:

• • post_impl_aes_70_orig — 70% utilization, regular design setting;
  • post_impl_aes_90_orig — 90% utilization, regular design setting;
  • post_impl_aes_70_shield — 70% utilization, setting for shielding of selected devices and nets against probing and fault injection, by tuning of placement and routing.

The take-away points are basically the following:

• • A naive increase of utilization from 70% to 90% helps to harden the layout against Trojan insertion, but makes timing closure more difficult.
  • Shielding of sensitive cells and nets helps to harden the layout against probing and fault injection, but makes timing closure more difficult as well, along with some PPA cost.
  • Competitive defense schemes will achieve both, hardening layouts and limiting impact on design quality. Such efforts are not made explicitly for the sample benchmarks. 

Next, more details are given. The exemplary security assessment reports, found in the folder reports, are the following:

• • Analysis_probe_0.rpt, Analysis_probe_shield_0.rpt — report on exposure of sensitive cells (AES key registers) through the frontside, considering a perpendicular/top-view attack vector. Relates to the regular layout with 70% utilization and the protected counterpart, respectively.
  • net_exposed_area.rpt, net_exposed_area_probe.rpt — report on exposure of sensitive wires (driven by AES key registers) through the frontside, considering a perpendicular/top-view attack vector. Relates to the regular layout with 70% utilization and the protected counterpart, respectively.
  • vulnerable_sites_aes_70.rpt, vulnerable_sites_aes_90.rpt — summary of placement sites in the vicinity of the sensitive AES key registers. Fully vulnerable means routing resource are also free, whereas partially vulnerable means that routing resources are only partially free. Relates to the regular layouts with 70% and 90% utilization, respectively. 
  • trigger_space_aes_70.rpt, trigger_space_aes_90.rpt — a more detailed report for the vulnerable sites and related routing resources. Relates to the regular layouts with 70% and 90% utilization, respectively.
  • aes_70_ppa.rpt, aes_70_probe_PPA.rpt, aes_90.rpt — power, performance, area reports for all three layouts.

The snapshots, found in folder snapshots and below, illustrate the following:

• • AES_Layout_70.PNG, AES_Layout_90.PNG — Top-view on placement and vulnerable sites. Fully vulnerable sites are highlighted in red, partially vulnerable sites in yellow. Relates to the regular layouts with 70% and 90% utilization, respectively.

    

    

  • InstProbing.PNG — A zoomed-in example for exposure of standard cells. The regions highlighted in red are exposed throughout the frontside.
    

 

As indicated, these sample benchmarks are only intended for warm-up on the theme and the problem formulation. Note that, for the forthcoming benchmarks, the general format will remain the same: archives of post-layout netlists, DEF files, and supporting files. However, instead of providing static report files, an evaluation platform will be made accessible such that participants can evaluate their own, hardened layout versions of the benchmarks. Also, the sensitive assets, like AES key registers, will be listed out explicitly for forthcoming benchmarks; here, these are provided only implicitly in the security assessment reports.

Alpha-Round Benchmarks

This link points to the ZIP bundle of the alpha-round benchmarks, which are different crypto cores. The designs have varying ranges of complexity, size, layout density, timing constraint, number of assets, and available metal layers.

Note that the AES layouts from the sample benchmarks are also included, but along with a different sets of cell and net assets to be protected.

Each benchmark contains the following files:

• • README — an overview on the benchmark and relevant details
  • design_original.def — the DEF file, representing the baseline layout, which is to be optimized
  • design_original.v — the corresponding post-layout, gate-level netlist
  • design.sdc, mmmc.tcl — the files used for timing analysis, along with __utils/init_eval.tcl used for basic design evaluation
  • cells.assets — the list of sensitive cells to be protected
  • nets.assets — the list of sensitive nets to be protected
  • NangateOpenCellLibrary.* — the LIB/LEF files
  • snapshot/exploit_regions.* — detailed plot of exploitable regions, along with __utils/gnuplot_exploit_regions.sh used for plotting
  • snapshots/*.gif — high-level snapshots on sensitive cells and nets to be protected
  • reports/scores.rpt shows the reference scores, i.e., the scores which a submission assuming the very same physical implementation as the baseline layout would achieve
  • reports/*.rpt — text reports on design quality and security

Final-Round Benchmarks

This link points to the ZIP bundle of the public final-round benchmarks, which are different crypto cores and a microprocessor. As with the alpha-round benchmarks, the designs have varying ranges of complexity, size, layout density, timing constraint, number of assets, and available metal layers.

Note that all the benchmarks from the alpha round are also included as is.

Note that on/around March 27th few more blind benchmarks will be released, including further crypto cores, microprocessor and SoC designs.