Skip to content

Commit

Permalink
Try again fixing the bullets
Browse files Browse the repository at this point in the history
  • Loading branch information
come-maiz authored Oct 11, 2024
1 parent d96810e commit ab56778
Showing 1 changed file with 5 additions and 5 deletions.
10 changes: 5 additions & 5 deletions content/2024-10-11-ztee.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -130,16 +130,16 @@ Naturally there is a question whether all of these problems need to be or can be
- Previous secure hardware use cases were not of the same magnitude of importance.
As AI tools become more powerful and more deeply ingrained in every tool we use, the amount of personal data processed by these models will grow to astonishing heights. In the past, client-side computing was able to address this issue with user data staying on the device, but the size and performance requirements of state of the art models requires that user data be sent to the cloud. This is the observation that motivated [Apple’s Private Compute Cloud announcement](https://security.apple.com/blog/private-cloud-compute/). AI models themselves can also be worth extraordinary amounts of money and increasingly are considered of national security interest.

At the same time, decentralised financial exchanges are already processing [billions of dollars of value](https://dune.com/hagaetc/dex-metrics) and the full market for financial trade is of astronomical size. In fact, decentralised financial systems are already being [attacked](https://www.ic3.gov/Media/Y2024/PSA240903) by [nation states.](https://www.coindesk.com/markets/2023/12/01/north-korean-hackers-lazarus-group-stolen-3b-in-cryptocurrency/)
At the same time, decentralised financial exchanges are already processing [billions of dollars of value](https://dune.com/hagaetc/dex-metrics) and the full market for financial trade is of astronomical size. In fact, decentralised financial systems are already being [attacked](https://www.ic3.gov/Media/Y2024/PSA240903) by [nation states.](https://www.coindesk.com/markets/2023/12/01/north-korean-hackers-lazarus-group-stolen-3b-in-cryptocurrency/)

Cryptographic identities (e.g. passkeys) are also becoming a ubiquitous mediating access to large parts of human activity as part of a global identity system. These keys are all stored and used on unverified hardware, meaning very large portions of this identity system can be completely compromised by a single party. Of course this issue transcends the remote attestation requirement and specifically points to the importance of considering the supply chain adversary.
Cryptographic identities (e.g. passkeys) are also becoming a ubiquitous mediating access to large parts of human activity as part of a global identity system. These keys are all stored and used on unverified hardware, meaning very large portions of this identity system can be completely compromised by a single party. Of course this issue transcends the remote attestation requirement and specifically points to the importance of considering the supply chain adversary.
- SLAs and other legal agreements have traditionally been used as a means of achieving security. If a TEE provided by a large cloud provider is physically attacked, the cloud provider can be sued. However, the legal action is slow, expensive, limited geographically and limited to large well-capitalised actors. The web3 industry (within which one can categorise decentralised finance), in particular, has focused on obviating the need for such agreements by removing trusted actors.

As a reference point, we can turn to the Ethereum blockchain which is the platform that plays host to the current largest decentralised exchanges. Ethereum has been explicitly designed and implemented to minimise the impact of the failure or misbehaviour of [any single party or system](https://ieeexplore.ieee.org/abstract/document/9438771). The underlying distributed protocol supports a very high number of nodes and has been parameterised to tolerate nodes in any geographic/regulatory location with resource requirements sufficiently low so that consumer hardware can be used to avoid dependence on cloud vendors. Moreover, there [are 6 maintained implementations](https://ethereum.org/en/developers/docs/nodes-and-clients/#consensus-clients) of the Ethereum client, each written in its own language.
As a reference point, we can turn to the Ethereum blockchain which is the platform that plays host to the current largest decentralised exchanges. Ethereum has been explicitly designed and implemented to minimise the impact of the failure or misbehaviour of [any single party or system](https://ieeexplore.ieee.org/abstract/document/9438771). The underlying distributed protocol supports a very high number of nodes and has been parameterised to tolerate nodes in any geographic/regulatory location with resource requirements sufficiently low so that consumer hardware can be used to avoid dependence on cloud vendors. Moreover, there [are 6 maintained implementations](https://ethereum.org/en/developers/docs/nodes-and-clients/#consensus-clients) of the Ethereum client, each written in its own language.

This context helps to understand the need to remove trusted parties from the threat model. Remote attacks are more likely than cloud providers tampering with the machines they host. Similarly, remote and physical attackers are much more worrisome than any trojan in the near future. However, these points do not take into account the dependencies which these vulnerabilities create. Businesses built around SH that is subject to these attack vectors must use one of a few large trustworthy cloud vendors and can only buy chips from the most trustworthy designers and manufacturers (a weakened business position). Some entity must be prepared to take legal action, an expensive and time consuming undertaking and one that assumes that a legal entity even exists - an assumption which does not hold for many of the systems at play. Consider a decentralised protocol that requires SH attestations to participate.
This context helps to understand the need to remove trusted parties from the threat model. Remote attacks are more likely than cloud providers tampering with the machines they host. Similarly, remote and physical attackers are much more worrisome than any trojan in the near future. However, these points do not take into account the dependencies which these vulnerabilities create. Businesses built around SH that is subject to these attack vectors must use one of a few large trustworthy cloud vendors and can only buy chips from the most trustworthy designers and manufacturers (a weakened business position). Some entity must be prepared to take legal action, an expensive and time consuming undertaking and one that assumes that a legal entity even exists - an assumption which does not hold for many of the systems at play. Consider a decentralised protocol that requires SH attestations to participate.

Even when there is an entity who is able to legal action, the ultimate end user who engaged with this entity on the basis of SH assurances - who we assume is not well resourced or in the same country - does not always have the same recourse. Another challenge with trusting supply chain actors or legal systems is that faith in these actors is not geographically universal. A US, Brazilian and Chinese person have very different views on the trustworthiness of Intel, Huawei and the likes and it is thus hard for them all to participate in the same system if that system is based on trust in entities like this. Technical security guarantees on the other hand can be much more universally agreed upon.
Even when there is an entity who is able to legal action, the ultimate end user who engaged with this entity on the basis of SH assurances - who we assume is not well resourced or in the same country - does not always have the same recourse. Another challenge with trusting supply chain actors or legal systems is that faith in these actors is not geographically universal. A US, Brazilian and Chinese person have very different views on the trustworthiness of Intel, Huawei and the likes and it is thus hard for them all to participate in the same system if that system is based on trust in entities like this. Technical security guarantees on the other hand can be much more universally agreed upon.
- Similarly to the previous point, the status quo in SH in which the security guarantees of a system are in large part assured through legal means caters to a “security through obscurity” approach. For example, the majority of tamper resistance measures are not documented publicly and common criteria - through which the security of most hardware is certified - even allocates points for keeping design details private.[^11] This approach does not carry over well to our setting in which it not only matters that the SH is actually secure, but that a 3rd party can be convinced of its security *on a technological basis* without dependence on a trusted authority. Our setting benefits from openness of as many design details as possible, thus the security model cannot rely on obscurity of these details, even if we were to work under the assumption that obscurity leads to greater security. Our next post addresses this topic in more detail.
- Purely from a business perspective, there is clear economic interest in security technology of this type. Enormous amounts of funding have poured into the comparable security technologies mentioned in this article. Network participation incentives for the Ethereum and Bitcoin blockchains (a means to guard against the collusive attacks mentioned before) have exceeded [$30B](https://dune.com/queries/4115035/6928889) and [$65B](https://dune.com/queries/4115040/6928893) respectively with Ethereum usage fees exceeding [$11B over the last two years](https://beaconcha.in/burn). Substantial amounts of funding have been allocated to [companies](https://risczero.com/blog/series-a) improving and utilising [ZK](https://blog.succinct.xyz/series-a/), MPC and [FHE](https://www.coindesk.com/business/2024/03/07/cryptography-firm-zama-raises-73m-for-fully-homomorphic-encryption-apps/) [technology](https://www.ft.com/content/a76f68a9-bcf3-4351-8fd5-d769956f3b3d), often [including](https://www.vdfalliance.org/news/open-vdf-asic-introduction) [hardware-components](https://www.coindesk.com/tech/2024/08/19/fabric-startup-building-vpu-chips-for-cryptography-raises-33m/).

Expand Down

0 comments on commit ab56778

Please sign in to comment.