Note: this article is written by myself as a personal article and is not representative of any institution that I may be part of. Thoughts and opinions are my own.
Since the beginning of the blockchain renaissance, there has been an explosion in privacy-preserving technologies. Specifically, advancements in transactional privacy, and more recently, massive breakthroughs in implementation of computational privacy.
Within each of these technologies are risks and tradeoffs that are inherent to any architecture of choice. Anyone who tells you there is no risk involved is lying to you. Simultaneously, anyone who FUDs certain privacy tech on the basis of it not achieving maximal security is also presenting a level of deception surrounding privacy. With maximal security comes scalability constraints and oftentimes usability constraints as well. This isn’t to say that maximal privacy and security shouldn’t be the end goal, but it is an acknowledgement that every user has a risk profile and should proceed accordingly.
Are you willing to use a privacy platform that is fast, fluid, flexible, and has an attack vector that has a 0.000001% chance of occurring over the course of a decade? What about 0.001%? What about 1%? Or 5%? Or 20%?
It is difficult to quantify the likelihood of attack vectors. Simultaneously, there is some naivety to this approach. The overwhelming majority of current blockchains are entirely transparent by default. If you want to compare risk-profiles of potential transparency exposure between different privacy-focused blockchain technologies, have at it. But you must do so with an understanding of tradeoffs, and that many users are searching for anything better than total transparency.
Honesty is key, and within the privacy community we need to be careful with our claims to certain levels of anonymity. At the same time, we must be careful with the claim that a security model that is not 10000% secure is by default worthless.
If someone accuses a security model of being worthless because they believe it is not 10000% secure is simply not true — this is about probabilities, not absolutes. The narrative that is contra to protocols that are not “security-maximalist” (which generally speaking is a personal opinion and difficult to probabilistically quantify) damages the privacy-innovation sector and communities. And while I always expect a certain degree of tribalism, privacy-based projects have a unique opportunity to have a distinct ethos that unites us into perpetuity.
In all of its shades and degrees of certainty, privacy is significantly better than the current transparent Web3.
Secret Network & Hardware Level Encryption
Secret Network has been criticized in the past as it pertains to privacy model. Secret Network uses hardware level encryption via Trusted Execution Environments (specifically SGX). Each node, before it registers, creates an attestation report that proves the node is using the latest security patches of SGX. Then, using an x25519 creates an AES key with the enclave of the entire network, and once the entire network verifies the attestation report of the new node, nodes already within the accept set send the shared key with the AES key to the new node. This entire process is done on-chain and always inside the enclave (the consensus enclave and the new node’s enclave) such that node operators cannot decrypt anything.
To further reduce the number of possible attack vectors on the network, Secret Network has opted to only use SGX-SPS. SGX comes in 2 forms, 1) SGX-ME (management engine) uses a small extra chip on the CPU to manage various functions related to the enclave. This includes memory and energy management, both which have been used in lab environments to break into the enclave. SGX-SPS (Server Platform Services) allows the bypassing of the ME chip. As a result all attack vectors of the ME chip are not applicable to Secret Network.
Once the new node gets the shared key of the consensus they become part of the consensus and are able to process computations and transactions in parallel to the network.
The entire process is also detailed here: https://github.com/enigmampc/SecretNetwork/blob/master/docs/protocol/encryption-specs.md
In terms of architecture, the core development team has been pretty strict about ensuring none (or at least, the vast majority) of known SGX vulnerabilities are allowed. All nodes in the network have to prove they are not only running SGX, but are also running it with all the latest firmware/microcode (processor firmware) upgrades. In other words — you have to be patched. Furthermore, you must also be running SGX-SPS. For the most part, this makes SGX attacks quite unlikely.
Some of these attacks depend on adding mitigations to the code that’s running on top of SGX (i.e Secret Network code) and the core development team has put fixes to that as well.
As to any future vulnerabilities in SGX — if that ever occurs the community of node-runners will mitigate and request the entire network to upgrade. Such a proposal would pass rapidly as it is in everyone’s best interest. In the future, Secret Network could implement other TEEs as needed.
Long story short — the team has been pretty comprehensive.
Are these absolute guarantees? No. It’s hard to say anything is absolute in blockchain, but the core development team has done the best they can to continue to be cutting edge as possible with security. Other chains have alluded to ZKSnarks & MPC for encrypted smart contracts (something Secret Network already has live)— but the majority of these proposed technologies are slow, difficult to implement, and struggle with scalability and interoperability.
Secret Network is live, and has been since September of 2020 with Secret Contracts — no other chain has been able to do this as rapidly as Secret Network has. Secret Network was the first — willing to experiment and push the edge in order to make programmable privacy implementable, while being fully aware of potential tradeoffs.
All nodes compute all computations at the same time and then come to consensus. Even if a privacy attack is successfully carried out, the following would have to be true:
- This 0-day exploit has not yet been patched by Intel
- The attack was executed by a node on the network
- The attack is hardware based in its execution (you have to be in a very unique niche of people to pull this off while not in a lab)
Even if an attack is executed on SGX, the underlying data itself cannot be modified unless consensus is compromised. That is to say, while data could be exposed, the ledger itself still remains immutable as long as decentralization is maintained.
On a side tangent, any noderunner that attacks their own network is automatically placing their investment at risk, and ultimately are gathering data (not tokens). It is unknown the value of the underlying data, and therefore an attack puts the noderunners investment at risk without a guarantee of any tangible financial return.
Once again, this is not to say that these types of attacks are not possible. It is merely to say these attacks are not probable. Additionally, the next generation of SGX technology is on the horizon.
Thoughts and opinions are my own. I hope you enjoyed this article. Long live the privacy community, and may we be united under the banner of it, regardless of the debate surrounding maximalism vs usability.
-Carter Woetzel | Twitter