mirror of
https://github.com/corda/corda.git
synced 2024-12-18 20:47:57 +00:00
TWP: Rebrand SGX execution models.
This commit is contained in:
parent
877966ac47
commit
8e911e8e49
@ -1661,6 +1661,10 @@ issuer to re-issue the asset onto the ledger with a new reference field. This op
|
|||||||
unlinks the new version of the asset from the old, meaning that nodes won't attempt to explore the original dependency
|
unlinks the new version of the asset from the old, meaning that nodes won't attempt to explore the original dependency
|
||||||
graph during verification.
|
graph during verification.
|
||||||
|
|
||||||
|
However the primary privacy effort revolves around encrypting the entire ledger and validating it using secure
|
||||||
|
hardware enclaves, see~\cref{subsec:sgx}. This can provide the benefits of homomorphic encryption and zero
|
||||||
|
knowledge proofs, but without sacrificing scalability/performance or (crucially) auditability in case of failure.
|
||||||
|
|
||||||
\section{Future work}
|
\section{Future work}
|
||||||
|
|
||||||
Corda has a long term roadmap with many planned extensions. In this section we explore a variety of planned upgrades
|
Corda has a long term roadmap with many planned extensions. In this section we explore a variety of planned upgrades
|
||||||
@ -2189,17 +2193,17 @@ correctly anyway, and modern CPUs certainly have sufficient flexibility in their
|
|||||||
particular code sequences and calculate the wrong answer when found. Thus minimising the number of trusted parties
|
particular code sequences and calculate the wrong answer when found. Thus minimising the number of trusted parties
|
||||||
to \emph{only} the CPU vendor is still a major step forward from the status quo.
|
to \emph{only} the CPU vendor is still a major step forward from the status quo.
|
||||||
|
|
||||||
\subsubsection{Lose-integrity vs lose-privacy}
|
\subsubsection{Attestation vs verification models}
|
||||||
|
|
||||||
SGX enclaves can be used in two different ways to provide ledger privacy. We name these different approaches the
|
SGX enclaves can be used in two different ways to provide ledger privacy. We name these different approaches the
|
||||||
\emph{lose-integrity model} and the \emph{lose-privacy model}, after what desirable attribute you lose if the
|
\emph{attestation model} and the \emph{verification model}, after what desirable attribute you lose if the
|
||||||
enclave's security is breached.
|
enclave's security is breached.
|
||||||
|
|
||||||
Consider a scenario in which Alice wishes to transfer a state to Bob. Alice has herself received the state from
|
Consider a scenario in which Alice wishes to transfer a state to Bob. Alice has herself received the state from
|
||||||
Zack, a third party Bob should not learn anything about. The state contains complex structured business data thus
|
Zack, a third party Bob should not learn anything about. The state contains complex structured business data thus
|
||||||
rendering token-specific privacy techniques insufficient.
|
rendering token-specific privacy techniques insufficient.
|
||||||
|
|
||||||
\paragraph{Lose-integrity.}The simplest way to use SGX is for Alice to create an enclave on her own computer that
|
\paragraph{Attestation model.}The simplest way to use SGX is for Alice to create an enclave on her own computer that
|
||||||
knows how to deserialize and verify transactions. Enclaves produce \emph{signatures of validity}, which are
|
knows how to deserialize and verify transactions. Enclaves produce \emph{signatures of validity}, which are
|
||||||
signatures of attestation by an enclave binary marked as trusted by the Corda network operator and which sign over
|
signatures of attestation by an enclave binary marked as trusted by the Corda network operator and which sign over
|
||||||
the Merkle root of the verified transaction. This implies the enclave must include a small SGX compatible JVM (such
|
the Merkle root of the verified transaction. This implies the enclave must include a small SGX compatible JVM (such
|
||||||
@ -2207,12 +2211,12 @@ a JVM has been built). Alice feeds a transaction to the enclave along with signa
|
|||||||
transaction's inputs, and a new signature of validity is produced by the enclave which can be checked by
|
transaction's inputs, and a new signature of validity is produced by the enclave which can be checked by
|
||||||
any third party to convince themselves that a genuine Corda verification enclave was used.
|
any third party to convince themselves that a genuine Corda verification enclave was used.
|
||||||
|
|
||||||
In the lose-integrity model transaction data doesn't move between peers at all. Only signatures of validity are
|
In the attestation model transaction data doesn't move between peers at all. Only signatures of validity are
|
||||||
transmitted over the peer-to-peer network. This has the following advantages:
|
transmitted over the peer-to-peer network. This has the following advantages:
|
||||||
|
|
||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
\item Some countries have regulations that forbid transmission of financial data, even encrypted, outside their
|
\item Some countries have regulations that forbid transmission of financial data, even encrypted, outside their
|
||||||
own borders. The lose-integrity model can handle such cases.
|
own borders. The attestation model can handle such cases.
|
||||||
\item Transaction resolution and verification becomes much faster, as only one transaction must be checked
|
\item Transaction resolution and verification becomes much faster, as only one transaction must be checked
|
||||||
instead of an arbitrarily deep dependency graph.
|
instead of an arbitrarily deep dependency graph.
|
||||||
\item It becomes possible for nodes to check transactions `from the future' and thus maybe survive mandatory
|
\item It becomes possible for nodes to check transactions `from the future' and thus maybe survive mandatory
|
||||||
@ -2225,7 +2229,7 @@ transmitted over the peer-to-peer network. This has the following advantages:
|
|||||||
\item It is relatively simple to implement.
|
\item It is relatively simple to implement.
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
|
|
||||||
Unfortunately the lose-integrity model has one large disadvantage that makes it undesirable to support as the
|
Unfortunately the attestation model has one large disadvantage that makes it undesirable to support as the
|
||||||
only available model: if a flaw in the enclave or SGX itself is found, it becomes possible for an attacker to edit
|
only available model: if a flaw in the enclave or SGX itself is found, it becomes possible for an attacker to edit
|
||||||
the ledger as they see fit. Because nodes aren't actually cross checking each other any more, but placing full
|
the ledger as they see fit. Because nodes aren't actually cross checking each other any more, but placing full
|
||||||
confidence in the enclave to assert validity, anyone who can forge signatures of validity could create money out of
|
confidence in the enclave to assert validity, anyone who can forge signatures of validity could create money out of
|
||||||
@ -2234,15 +2238,16 @@ also unauditable.
|
|||||||
|
|
||||||
In practice both a verification enclave and SGX itself are complex systems that are unlikely to be bug free. Flaws
|
In practice both a verification enclave and SGX itself are complex systems that are unlikely to be bug free. Flaws
|
||||||
will be found and fixed over the lifetime of the system, and the design of SGX anticipates that. Indeed, such flaws
|
will be found and fixed over the lifetime of the system, and the design of SGX anticipates that. Indeed, such flaws
|
||||||
have already been found. In the lose-integrity model the ledger cannot recover from a discovered flaw: doubt over
|
have already been found. In the attestation model the ledger cannot recover from a discovered flaw: doubt over
|
||||||
the integrity of the database would persist permanently.
|
the integrity of the database would persist permanently.
|
||||||
|
|
||||||
This problem motivates the desire for a second model.
|
This problem motivates the desire for a second model.
|
||||||
|
|
||||||
\paragraph{Lose-privacy.}This model is significantly more complex. In it, Bob uses remote attestation to convince
|
\paragraph{Verification model.}This model is significantly more complex. In it, Bob uses remote attestation to
|
||||||
Alice that he is running an enclave that can verify third party transaction data without leaking it to him. Once
|
convince Alice that he is running an enclave that can verify third party transaction data without leaking it to
|
||||||
convinced, Alice encrypts Zack's transaction to the enclave and sends it to Bob's computer. Bob then feeds the
|
him. Once convinced, Alice encrypts Zack's transaction to the enclave and sends it to Bob's computer. Bob then
|
||||||
encrypted transaction to the enclave, and the enclave signals to Bob that it believes the transaction to be valid.
|
feeds the encrypted transaction to the enclave, and the enclave signals to Bob that it believes the transaction to
|
||||||
|
be valid.
|
||||||
|
|
||||||
The complexity stems from the recursive nature of this process. Alice received the transaction from Zack, who may
|
The complexity stems from the recursive nature of this process. Alice received the transaction from Zack, who may
|
||||||
in turn have obtained the state via a transaction with Yvonne, thus neither Alice nor Zack may actually have a
|
in turn have obtained the state via a transaction with Yvonne, thus neither Alice nor Zack may actually have a
|
||||||
@ -2280,12 +2285,12 @@ A simplified version of the protocol looks like this:
|
|||||||
The above description is incomplete in many ways. A real implementation will hide \emph{all} transactions and
|
The above description is incomplete in many ways. A real implementation will hide \emph{all} transactions and
|
||||||
expose only states via the node's API - the head of the chain is never special in such a design. Enclaves need to
|
expose only states via the node's API - the head of the chain is never special in such a design. Enclaves need to
|
||||||
store data locally under different keys than the ones used for communication, implying another re-encryption step.
|
store data locally under different keys than the ones used for communication, implying another re-encryption step.
|
||||||
Unlike lose-integrity the lose-privacy model doesn't improve the speed or scaling of the resolution process, and
|
Unlike the attestation model the verification model doesn't improve the speed or scaling of the resolution
|
||||||
encrypted data still moves between nodes. And side channel attacks must be mitigated, as Bob could attempt to learn
|
process, and encrypted data still moves between nodes. And side channel attacks must be mitigated, as Bob could
|
||||||
things about the contents of encrypted transactions by taking careful measurements of the enclave's execution as it
|
attempt to learn things about the contents of encrypted transactions by taking careful measurements of the
|
||||||
validates the chain of custody.
|
enclave's execution as it validates the chain of custody.
|
||||||
|
|
||||||
Despite these disadvantages, the lose-privacy model comes with a major improvement: breaches of enclave security
|
Despite these disadvantages, the verification model comes with a major improvement: breaches of enclave security
|
||||||
allow private data to be accessed but do \emph{not} grant any special write privileges. As data gets progressively
|
allow private data to be accessed but do \emph{not} grant any special write privileges. As data gets progressively
|
||||||
less valuable as it ages this means recovery from breaches happens naturally and organically; eventually none of
|
less valuable as it ages this means recovery from breaches happens naturally and organically; eventually none of
|
||||||
the data exposed by a breach matters much any more, and at any rate, a breach only reverts the system to the level
|
the data exposed by a breach matters much any more, and at any rate, a breach only reverts the system to the level
|
||||||
@ -2293,9 +2298,9 @@ of security it had pre-SGX. Therefore trading can continue even in the event of
|
|||||||
discovered. In contrast, if data integrity is lost there is no way to recover it (illegally minted money may
|
discovered. In contrast, if data integrity is lost there is no way to recover it (illegally minted money may
|
||||||
continue to circulate for years).
|
continue to circulate for years).
|
||||||
|
|
||||||
\paragraph{Mixed mode.}The two modes can be combined in the same network. For example, lose-integrity can be used
|
\paragraph{Mixed mode.}The two modes can be combined in the same network. For example, the attestation model can be used
|
||||||
if data were to cross borders with lose-privacy being the default for when data would stay within a country.
|
if data were to cross borders with verification being the default for when data would stay within a country.
|
||||||
Semi-validating notaries could operate in a network for which other nodes are running the lose-privacy model. The
|
Semi-validating notaries could operate in a network for which other nodes are running verification. The
|
||||||
exact blend of security tradeoffs a group of nodes may tolerate can be set by the network operator via its usual
|
exact blend of security tradeoffs a group of nodes may tolerate can be set by the network operator via its usual
|
||||||
governance processes. Mixed mode is also useful during incremental rollout of ledger encryption to an already live
|
governance processes. Mixed mode is also useful during incremental rollout of ledger encryption to an already live
|
||||||
Corda network.
|
Corda network.
|
||||||
|
Loading…
Reference in New Issue
Block a user