diff --git a/content/2024-11-08-ZTEE2.mdx b/content/2024-11-08-ZTEE2.mdx
index 80a1fe4a..cd76d9b2 100644
--- a/content/2024-11-08-ZTEE2.mdx
+++ b/content/2024-11-08-ZTEE2.mdx
@@ -33,8 +33,8 @@ The current chain of trust for a semiconductor looks something like the followin
 ![RTL to GDS](/img/ZTEE/rtl2gds.png)
 
     
-2. **Fabrication**: The fab receives the GDS, which is pretty much a giant layered image, and prints it layer by layer. A big variable determining the performance, size and cost of the chip is the quality of the [process node](https://www.design-reuse.com/articles/43316/a-brief-history-of-process-node-evolution.html) - the technology the fab uses to produce the chip - that is used. Big process nodes (e.g. 130nm) are less precise than smaller nodes and therefore can’t pack transistors as tightly. The state of the art is around 2nm^[[The actual physical pitch of features at 2nm is 45nm for gates and 20nm for metal](https://en.wikipedia.org/wiki/2_nm_process).]. Each process node has its own dedicated PDK.
-3. **Key generation**: Since the hardware needs a signing key, a key must be embedded into the hardware ^[it is technically possible to use a software-based key, but this is worse for our purposes as will soon become clear]. This hardware key forms part of a larger unit called the Root of Trust (RoT) that contains additional logic for using the hardware key.
+2. **Fabrication**: The fab receives the GDS, which is pretty much a giant layered image, and prints it layer by layer. A big variable determining the performance, size and cost of the chip is the quality of the [process node](https://www.design-reuse.com/articles/43316/a-brief-history-of-process-node-evolution.html) - the technology the fab uses to produce the chip - that is used. Big process nodes (e.g. 130nm) are less precise than smaller nodes and therefore can’t pack transistors as tightly. The state of the art is around 2nm[^1]. Each process node has its own dedicated PDK.
+3. **Key generation**: Since the hardware needs a signing key, a key must be embedded into the hardware[^2]. This hardware key forms part of a larger unit called the Root of Trust (RoT) that contains additional logic for using the hardware key.
 4. **Delivery**: Before being delivered to purchasers, the chip goes through several additional steps like packaging and testing. These steps may involve as many as 10 different parties gaining access to the chip. Currently, in the case of TEEs, these chips are eventually mostly sold to cloud providers.
 5. **Generating a report**: When the hardware is turned on, a boot process with the RoT at its core checks the firmware running on the device - i.e. the hardware inspects the loaded low-level software. This process produces a report about the firmware, signed by the hardware key. This signed report is sent to an attestation service which has received a database of public keys and chip metadata collected earlier in the manufacturing process.
 6. **Attestation**: If the firmware checks out and the signature matches a public key in the attestation service’s registry, the attestation service responds with a certificate confirming this.
@@ -56,8 +56,8 @@ After concerns around the hardware key and attestation, the next category of con
 
 There are [various models](https://www.sogis.eu/documents/cc/domains/hardware_devices/JIL-Application-of-Attack-Potential-to-Hardware-Devices-with-Security-Boxes-v3.1.pdf) according to which we can measure security. A comprehensive analysis should incorporate all three of the following:
 
-- **Cost of attack**: some attacks have measurable costs. For example, precise advanced SEM microscopes can cost hundreds of thousands of dollars and other attacks could require several months of highly skilled experts’ time. If the reward of attack approaches or exceeds the cost of attack we consider a system insecure. Once systems are implemented bounty programs in which the bounty slowly increases over time are a potential means to improve estimates of the cost of attack.^[This could be done quite easily by passing a private key that controls some cryptocurrency to any hardware that provides a certain attestation]
-- **Difficulty of attack**: some attacks have measurable difficulty. For example, we can prove that some attacks are not possible given the adversary is only able to observe d and fault k wires with each additional wire constituting a greater technical challenge ([1](https://eprint.iacr.org/2023/1143.pdf), [2](https://eprint.iacr.org/2023/1341.pdf), [3](https://tches.iacr.org/index.php/TCHES/article/view/7270)). Another important metric is the [number of queries an adversary needs to pull off an attack](https://smaesh-challenge.simple-crypto.org/).^[The cited metrics are used to measure attacks on complete chips, which is not the topic of this post. These metrics are still relevant as some trojans could be inserted to introduce side channels, but the development of other metrics would also be necessary.]  The ultimate goal would be to theoretically or [empirically](https://smaesh-challenge.simple-crypto.org/leaderboard.html) lower bound this number to be infeasibly high. Schemes built on top of SH that do not consider hardware secure after a certain life time help to make this target of “infeasibility” concrete.
+- **Cost of attack**: some attacks have measurable costs. For example, precise advanced SEM microscopes can cost hundreds of thousands of dollars and other attacks could require several months of highly skilled experts’ time. If the reward of attack approaches or exceeds the cost of attack we consider a system insecure. Once systems are implemented bounty programs in which the bounty slowly increases over time are a potential means to improve estimates of the cost of attack[^3].
+- **Difficulty of attack**: some attacks have measurable difficulty. For example, we can prove that some attacks are not possible given the adversary is only able to observe d and fault k wires with each additional wire constituting a greater technical challenge ([1](https://eprint.iacr.org/2023/1143.pdf), [2](https://eprint.iacr.org/2023/1341.pdf), [3](https://tches.iacr.org/index.php/TCHES/article/view/7270)). Another important metric is the [number of queries an adversary needs to pull off an attack](https://smaesh-challenge.simple-crypto.org/)[^4]. The ultimate goal would be to theoretically or [empirically](https://smaesh-challenge.simple-crypto.org/leaderboard.html) lower bound this number to be infeasibly high. Schemes built on top of SH that do not consider hardware secure after a certain life time help to make this target of “infeasibility” concrete.
 - **Honesty assumptions**: some attacks are not possible under the assumption that certain parties behave according to a protocol. If a cloud provider is considered honest (an assumption we will not be making) then we may consider physical attacks on hardware under their control to be infeasible. At the same time, we may not consider certain supply chain actors to be honest and require a system to be secure against arbitrary actions taken by them or make statements about security conditional on k out of n actors being honest.
 
 # I. Verifiable Designs
@@ -68,13 +68,13 @@ Inevitably, building chips that don’t require strong trust assumptions in the
 
 *Puff, PUF, pass on key injection*
 
-We can break up our task into two: generating the key and storing it. The key must be generated so that it is **unique** to the device and **unpredictable**. We need secure storage to make the key **persistent** since the key acts as an identifier over the lifetime of the chip.^[One could imagine protocols in which chips are reinspected and issued new identities, but we leave this aside for now.]
+We can break up our task into two: generating the key and storing it. The key must be generated so that it is **unique** to the device and **unpredictable**. We need secure storage to make the key **persistent** since the key acts as an identifier over the lifetime of the chip[^5].
 
 A common practice is “key injection.” This features a party that generates the key externally and then stores the key within the chip by, for instance, burning it into an efuse. (e.g. [Intel SGX provisioning secret](https://eprint.iacr.org/2016/086)). The actor generating the key is able to retain a copy of the private key, making the key predictable and the entire system insecure. Consequently, we do not consider this approach. 
 
 The first approach we do consider is using a [True Random Number Generator](https://ieeexplore.ieee.org/abstract/document/4016501) (TRNG) on the chip to generate the key. TRNGs use the electrical noise present in the chip as a source of entropy and return ~random numbers when queried. The storage could be constructed in such a way that only the TRNG can write to it and only if all other means of reading the TRNG (e.g. for testing the TRNG) are disabled. To achieve this, the storage could be provided as an IP block that simply lacks an AXI write interface with the only wires connected to the memory storage buffers coming from the TRNG. There are several possible solutions for storing the key. A common approach is encoding the key by burning efuses. For example, Apple follows this approach for the [Secure Enclave](https://support.apple.com/guide/security/secure-enclave-sec59b0b31ff/web) used in its consumer electronics in their recent [Private Cloud Compute](https://security.apple.com/documentation/private-cloud-compute/hardwarerootoftrust#Apple-silicon-root-of-trust). However, [fuses can be hard to defend against physical attackers](https://youtu.be/z33TSv9EXBQ?si=Gyn6AzDA73EsOwP4) since blown fuses are relatively large features. There are [new types of memories](https://irds.ieee.org/editions/2023/20-roadmap-2023-edition/126-irds%E2%84%A2-2023-beyond-cmos-and-emerging-materials-integration) such as resistive memories ([ReRAM](https://ieeexplore.ieee.org/abstract/document/9900346)) or [antifuses](https://www.pufsecurity.com/technology/otp/) that might offer more promising alternatives. Although there are already [commercial ReRAM offerings](https://www.crossbar-inc.com/news/press-releases/2022-04-05-reram-proves-resistant-to-invasive-attacks/), hardware researchers have [called for more thorough research](https://ieeexplore.ieee.org/document/10533875) to better understand their security. 
 
-The second approach we consider is a [Physically Unclonable Functions](https://www.nature.com/articles/s41928-020-0372-5) (PUF) which uses manufacturing process variations as a source of entropy.^[Note that there is a large body of literature about exploiting *strong* PUFs. These should not be conflated with the more easily realised *weak* PUFs we need for our use case.] Unlike TRNGs, PUFs are designed to provide the same response over their lifetimes so the key generation occurs as a byproduct of the chip being fabricated, and the PUF itself constitutes a key-storage mechanism. The PUF derives its uniqueness and unpredictability from three important claims. The first is that no fabrication process is sufficiently precise to produce two of exactly the same chips, thus two of the same PUFs cannot be created. The second claim is that PUFs are tamper-evident. In particular, any attempt to read the fine details of the PUF so as to learn anything about the secret instantiated in its structure will disturb its structure, irreversibly destroying the key. PUFs can be constructed such that this property applies to the entire chip meaning that penetration of the passivation top layer or silicon bottom layer is not feasible as this would disturb the electrical characteristics of the chip, changing the PUF.^[Delay-based PUFs are more appealing than the common SRAM PUFs as they are more resistant to invasive attacks.] The third claim is that the PUF construction introduces sufficient entropy for the generated key to be secure. 
+The second approach we consider is a [Physical Unclonable Functions](https://www.nature.com/articles/s41928-020-0372-5) (PUF) which uses manufacturing process variations as a source of entropy[^6]. Unlike TRNGs, PUFs are designed to provide the same response over their lifetimes so the key generation occurs as a byproduct of the chip being fabricated, and the PUF itself constitutes a key-storage mechanism. The PUF derives its uniqueness and unpredictability from three important claims. The first is that no fabrication process is sufficiently precise to produce two of exactly the same chips, thus two of the same PUFs cannot be created. The second claim is that PUFs are tamper-evident. In particular, any attempt to read the fine details of the PUF so as to learn anything about the secret instantiated in its structure will disturb its structure, irreversibly destroying the key. PUFs can be constructed such that this property applies to the entire chip meaning that penetration of the passivation top layer or silicon bottom layer is not feasible as this would disturb the electrical characteristics of the chip, changing the PUF[^7]. The third claim is that the PUF construction introduces sufficient entropy for the generated key to be secure. 
 
 For any approach, the logic that facilitates use of the key must also be secured to protect the key against attacks like side-channel and fault injection attacks. Most PUFs use error correction logic to stabilize the PUF response to ensure deterministic key generation. Signing or decryption logic must also be implemented and the [key must be securely passed to this logic](https://ieeexplore.ieee.org/abstract/document/9300258). State-of-the-art techniques that protect this logic make use of [hardware masking](https://doi.org/10.1109/TC.2020.3022979) to defend against side-channel attacks, and [redundancy](https://ieeexplore.ieee.org/document/1580506/) to defend against fault injection attacks.
 
@@ -104,7 +104,7 @@ The next phase of producing the GDS file requires the netlist that we derive fro
 
 As Mark’s talk explains in more detail, there are many other files and pieces of software that sit between the designer’s idea and the GDSII file. Ownership of these is spread across a variety of parties who take legal measures to keep their IP from becoming public.
 
-The motivation for these legal measures varies. As in the case of fabs, some actors are driven to protect advanced solutions from competitors. Security and the perception of security provides another motivation. Obscurity of design does slow attacks and open designs are more likely to draw attention from security researchers who inevitably bring bad PR. Security through obscurity has become so entrenched that the Common Criteria standard, through which almost all secure hardware is evaluated, explicitly rewards designs which are not publicly available.^[To reach CC-EAL-5+, a developer needs to satisfy ALC_DVS.2, which requires security controls to “[protect the confidentiality and integrity of the TOE design](https://www.commoncriteriaportal.org/files/ccfiles/CC2022PART3R1.pdf)”] At the same time, in an industry where closed designs are the norm, there has historically been limited incentive to do otherwise. 
+The motivation for these legal measures varies. As in the case of fabs, some actors are driven to protect advanced solutions from competitors. Security and the perception of security provides another motivation. Obscurity of design does slow attacks and open designs are more likely to draw attention from security researchers who inevitably bring bad PR. Security through obscurity has become so entrenched that the Common Criteria standard, through which almost all secure hardware is evaluated, explicitly rewards designs which are not publicly available[^8]. At the same time, in an industry where closed designs are the norm, there has historically been limited incentive to do otherwise. 
 
 The result of this IP quagmire is that most design documentation doesn’t see the light of day. Some of the time these legal restrictions permeate all the way to low level software/firmware. For example, the critically important “microcode” that instantiates Intel’s SGX and TDX security cannot be publicly audited.
 
@@ -114,7 +114,7 @@ The result of this IP quagmire is that most design documentation doesn’t see t
 
 An obvious repercussion of this closedness is that, for users of these systems, there is little way to directly verify the security properties of a system without trusting private audits. An even more impactful implication is that anyone who wants to build fully open hardware, must rely on the little technology that is not legally encumbered. For components like DDR DRAM interfaces, PCIe and RISC-V cores, the closed source state of the art far outperforms open designs, impacting security and performance of open designs. This gap between closed and open technology is most critical at the level of process nodes. A determined fabless design team may be willing to implement an open source version of a needed component (at substantial cost), but this is not an option for process nodes and their PDKs. Without open PDKs, GDS files cannot be publicly released.
 
-The fabs with open PDKs have far from the state of the art process nodes available, the most advanced being Google Skywater’s 130nm node^[[90nm may soon be on the horizon](https://opensource.googleblog.com/2022/07/SkyWater-and-Google-expand-open-source-program-to-new-90nm-technology.html)]. Even for comparable nodes, Open PDKs have their limitations compared to closed counterparts (e.g. poor SRAM support). The quality of the process node significantly impacts the size, cost and efficiency of chips. For example, [manufacturing the same chip on 28nm vs 130nm can imply a 20x cost difference and a 5-10x power/speed differential.](https://youtu.be/JMOWU6pFflw?si=jgh4Ds6_U21Dv4Ck&t=1274) Naturally, the difference with the 2nm state of the art is more pronounced. 
+The fabs with open PDKs have far from the state of the art process nodes available, the most advanced being Google Skywater’s 130nm node[^9]. Even for comparable nodes, Open PDKs have their limitations compared to closed counterparts (e.g. poor SRAM support). The quality of the process node significantly impacts the size, cost and efficiency of chips. For example, [manufacturing the same chip on 28nm vs 130nm can imply a 20x cost difference and a 5-10x power/speed differential.](https://youtu.be/JMOWU6pFflw?si=jgh4Ds6_U21Dv4Ck&t=1274) Naturally, the difference with the 2nm state of the art is more pronounced. 
 
 Better process nodes not only imply better economics and performance, they also impact security. As chips get denser, it becomes much harder to carry out various forms of physical tampering. Extracting information via probing and electromagnetic side channel attacks becomes much more difficult for example. Interestingly, defense against hardware trojans does the inverse and becomes harder to do as features get smaller due to the limited precision of current imaging techniques. Open access to better process nodes is certainly very necessary today, but there may be a point at which smaller nodes would not be more desirable even if they were open.
 
@@ -122,7 +122,7 @@ Better process nodes not only imply better economics and performance, they also
 An open source maximalist may want every design detail to be open, but given the status quo we will need to navigate a world in which not everything is open, at least for now. Despite a [growing](https://fossi-foundation.org/orconf/2024) [community](https://wiki.f-si.org/index.php/FSiC2024) of people and [commercial](https://www.zerorisc.com/) [projects](https://tropicsquare.com/) working to build open versions of the tools required to design and build chips, there is still a very high cost to building fully open hardware, impacting the performance, cost and security of chips. There is a point at which benefits of fully open designs outweigh the costs, but significant work is required to reach this point.
 
 **Opening Everything**
-Fortunately, there are already several designs which are ***partially*** open. [OpenTitan](https://opentitan.org/), [Cramium](https://www.crossbar-inc.com/products/secure-processing-units/overview/) and [Tropic Square](https://tropicsquare.com/) are projects building chips with many, but not all aspects of their chip design collateral publicly released. By keeping the GDS and some other details closed, chips can be produced with high quality process nodes. However, enough material is open for users to be able to audit the design for potential bugs or side channels. For example, some side-channel mitigation techniques ([1](https://ieeexplore.ieee.org/abstract/document/9190067), [2](https://eprint.iacr.org/2022/507), [3](https://tches.iacr.org/index.php/TCHES/article/view/11689)) can be verified by existing tooling given the netlist ([1](https://eprint.iacr.org/2020/634), [2](https://tches.iacr.org/index.php/TCHES/article/view/9820), [3](https://graz.elsevierpure.com/en/publications/cocoalma-a-versatile-masking-verifier), [4](https://tches.iacr.org/index.php/TCHES/article/view/9822)) or RTL ([1](https://link.springer.com/chapter/10.1007/978-3-030-29959-0_15), [2](https://ieeexplore.ieee.org/abstract/document/9833600)). There’s also the benefit of lessened vendor lock-in and easier extensibility. To address trojans, we could throw weight behind the movement to open up tools and designs. **The aim would be to get better open PDKs** and make enough of an economic, social and/or political argument to sway foundries into opening up higher quality process nodes, making it possible to have a public commercially viable chip with an open GDS. Since some process nodes (e.g. ~28nm^[The 2x node is also the “last node of Moore’s law” in that it was the last node where transistors got cheaper. It used to be that the cost of wafers always dropped to around $3k as the process matured; 2x nm was the end of that. For smaller nodes, wafer cost doesn’t come down, and they may even go up. This makes 2x nm a very economically important node. For instance, TSMC is doubling down on this node and trying to get legacy customers to migrate to the node.]) have been around for quite some time, the “edge” lost from opening these PDKs is not that large and it is realistic to expect that, especially with demonstration of sufficient demand, some of these will be opened up in the next 2 years.
+Fortunately, there are already several designs which are ***partially*** open. [OpenTitan](https://opentitan.org/), [Cramium](https://www.crossbar-inc.com/products/secure-processing-units/overview/) and [Tropic Square](https://tropicsquare.com/) are projects building chips with many, but not all aspects of their chip design collateral publicly released. By keeping the GDS and some other details closed, chips can be produced with high quality process nodes. However, enough material is open for users to be able to audit the design for potential bugs or side channels. For example, some side-channel mitigation techniques ([1](https://ieeexplore.ieee.org/abstract/document/9190067), [2](https://eprint.iacr.org/2022/507), [3](https://tches.iacr.org/index.php/TCHES/article/view/11689)) can be verified by existing tooling given the netlist ([1](https://eprint.iacr.org/2020/634), [2](https://tches.iacr.org/index.php/TCHES/article/view/9820), [3](https://graz.elsevierpure.com/en/publications/cocoalma-a-versatile-masking-verifier), [4](https://tches.iacr.org/index.php/TCHES/article/view/9822)) or RTL ([1](https://link.springer.com/chapter/10.1007/978-3-030-29959-0_15), [2](https://ieeexplore.ieee.org/abstract/document/9833600)). There’s also the benefit of lessened vendor lock-in and easier extensibility. To address trojans, we could throw weight behind the movement to open up tools and designs. **The aim would be to get better open PDKs** and make enough of an economic, social and/or political argument to sway foundries into opening up higher quality process nodes, making it possible to have a public commercially viable chip with an open GDS. Since some process nodes (e.g. ~28nm[^10]) have been around for quite some time, the “edge” lost from opening these PDKs is not that large and it is realistic to expect that, especially with demonstration of sufficient demand, some of these will be opened up in the next 2 years.
 
 ![image(4)|490x488](upload://f387HyyNbYD5nFRrmICZSdncpaV.png)
 
@@ -133,7 +133,7 @@ Fortunately, there are already several designs which are ***partially*** open. [
 Another approach recognises that the march to a sufficiently powerful open hardware “stack” is a long and unpredictable one, and instead asks what we can do without opening everything up. The idea is to go as far as possible with only the RTL and netlist being public, using mathematical tooling to learn as much as possible from the information that is open.
 ![image|690x205, 75%](/img/ZTEE/zklvs1.jpeg)
 
-One way ([proposed by Bunnie](https://www.bunniestudios.com/blog/2024/iris-infra-red-in-situ-project-updates/)) to do this is to **bound the density of logic** (i.e. number of transistors per unit of area) we should expect in different regions of the chip. We could rely on formal methods to achieve these bounds, but partial reliance on heuristics may also be a viable path. The reasoning behind these heuristics would be that there are large financial incentives to develop techniques to pack logic more tightly and to advertise such improvements instead of secretly developing them for the insertion of trojans. Sufficiently tight bounds would render large trojans detectable. Given how [small](https://link.springer.com/chapter/10.1007/978-3-642-40349-1_12) some (dopant-level) trojans can be, we would also need other techniques to force trojans to a detectable size. We cover this issue in more depth in the next section. The proof techniques for upper bounding logic density and lower bounding trojans still need to be developed so this should be considered a direction for exploration rather than an option today.^[If you are knowledgeable or interested in working on (or funding) these problems reach out to us or Bunnie directly.]
+One way ([proposed by Bunnie](https://www.bunniestudios.com/blog/2024/iris-infra-red-in-situ-project-updates/)) to do this is to **bound the density of logic** (i.e. number of transistors per unit of area) we should expect in different regions of the chip. We could rely on formal methods to achieve these bounds, but partial reliance on heuristics may also be a viable path. The reasoning behind these heuristics would be that there are large financial incentives to develop techniques to pack logic more tightly and to advertise such improvements instead of secretly developing them for the insertion of trojans. Sufficiently tight bounds would render large trojans detectable. Given how [small](https://link.springer.com/chapter/10.1007/978-3-642-40349-1_12) some (dopant-level) trojans can be, we would also need other techniques to force trojans to a detectable size. We cover this issue in more depth in the next section. The proof techniques for upper bounding logic density and lower bounding trojans still need to be developed so this should be considered a direction for exploration rather than an option today[^11].
 ![image|690x379, 75%](/img/ZTEE/zklvs2.jpeg)
 
 
@@ -150,7 +150,7 @@ There are several techniques we can use to do this. The most basic is simply to
 The combination of the mathematical and pro-openness approaches is promising. The mathematical approaches serve as a good hedge against the open hardware movement taking a long time to get up to speed and helps to add additional assurances to partially open architectures like OpenTitan. One approach is technical while the other requires navigating patents and licensing or convincing large corporations to change their stance on something, presenting two very different forms of risk.
 
 # III. Detecting Trojans
-We can separate trojan detection techniques into destructive and non-destructive. [Destructive analyses](https://ieeexplore.ieee.org/document/10179341) are the state of the art. The destructive analysis process typically involves shaving away protective packaging and then, because chips actually consist of many layers of logic and interconnects, carefully shaving away each layer of logic and using a tool like a [scanning electron microscope (SEM)](https://en.wikipedia.org/wiki/Scanning_electron_microscope) or [Focused Ion Beam](https://en.wikipedia.org/wiki/Focused_ion_beam) (FIB)^[Not to be confused with [ion cannons](https://starwars.fandom.com/wiki/Ion_cannon).] to inspect each layer. These techniques have been shown [to be able to detect even stealthy dopant-level of trojans](https://link.springer.com/chapter/10.1007/978-3-662-44709-3_7). 
+We can separate trojan detection techniques into destructive and non-destructive. [Destructive analyses](https://ieeexplore.ieee.org/document/10179341) are the state of the art. The destructive analysis process typically involves shaving away protective packaging and then, because chips actually consist of many layers of logic and interconnects, carefully shaving away each layer of logic and using a tool like a [scanning electron microscope (SEM)](https://en.wikipedia.org/wiki/Scanning_electron_microscope) or [Focused Ion Beam](https://en.wikipedia.org/wiki/Focused_ion_beam) (FIB)[^12] to inspect each layer. These techniques have been shown [to be able to detect even stealthy dopant-level of trojans](https://link.springer.com/chapter/10.1007/978-3-662-44709-3_7). 
 
 Despite their effectiveness, destructive techniques have significant downsides such as being, well, *destructive*… Not only are destructive techniques slow and costly, chips that end up being used have never gone through such an inspection process so the security guarantee must be derived from the adversary being statistically warded off by a sampling process which checks some fraction of produced chips. Additionally, as section IV makes clearer, creating publicly verifiable trojan-detection protocols based on destructive analysis is challenging because a chip can only be inspected once and the process doesn’t produce evidence that can be tied back to the identity of the chip. These limitations do not rule out the use of destructive techniques, but do motivate exploration of non-destructive alternatives.
 
@@ -237,3 +237,16 @@ We have also touched on several open problems and challenges, which would be a g
     - For continuous attestation, understand the impact of frequency of attestations on passive side-channel attacks and physical attacks. Higher frequency should make physical attacks harder and side-channel attacks easier.
 
 This post would not have been possible without Thorben Moos from [Simple Crypto](https://www.simple-crypto.org/). Thanks to [Zach Belateche](https://x.com/blip_tm), Leonardo Arias, [James Ball](https://x.com/_troglobyte) and Nikki Sigurdson for valuable review and discussion.
+
+[^1]: [The actual physical pitch of features at 2nm is 45nm for gates and 20nm for metal](https://en.wikipedia.org/wiki/2_nm_process).
+[^2]: It is technically possible to use a software-based key, but this is worse for our purposes as will soon become clear.
+[^3]: This could be done quite easily by passing a private key that controls some cryptocurrency to any hardware that provides a certain attestation.
+[^4]: The cited metrics are used to measure attacks on complete chips, which is not the topic of this post. These metrics are still relevant as some trojans could be inserted to introduce side channels, but the development of other metrics would also be necessary.
+[^5]: One could imagine protocols in which chips are reinspected and issued new identities, but we leave this aside for now.
+[^6]: Note that there is a large body of literature about exploiting *strong* PUFs. These should not be conflated with the more easily realised *weak* PUFs we need for our use case.
+[^7]: Delay-based PUFs are more appealing than the common SRAM PUFs as they are more resistant to invasive attacks.
+[^8]: To reach CC-EAL-5+, a developer needs to satisfy ALC_DVS.2, which requires security controls to “[protect the confidentiality and integrity of the TOE design.](https://www.commoncriteriaportal.org/files/ccfiles/CC2022PART3R1.pdf)”
+[^9]: [90nm may soon be on the horizon.](https://opensource.googleblog.com/2022/07/SkyWater-and-Google-expand-open-source-program-to-new-90nm-technology.html)
+[^10]: The 2x node is also the “last node of Moore’s law” in that it was the last node where transistors got cheaper. It used to be that the cost of wafers always dropped to around $3k as the process matured; 2x nm was the end of that. For smaller nodes, wafer cost doesn’t come down, and they may even go up. This makes 2x nm a very economically important node. For instance, TSMC is doubling down on this node and trying to get legacy customers to migrate to the node.
+[^11]: If you are knowledgeable or interested in working on (or funding) these problems reach out to us or Bunnie directly.
+[^12]: Not to be confused with [ion cannons](https://starwars.fandom.com/wiki/Ion_cannon).