blob: 0cba9637c1a3f35ca9127085e1d6ca32d848ac2e [file] [log] [blame]
(window.webpackJsonp=window.webpackJsonp||[]).push([[90],{433:function(e,t,a){"use strict";a.r(t);var n=a(11),s=Object(n.a)({},(function(){var e=this,t=e.$createElement,a=e._self._c||t;return a("ContentSlotsDistributor",{attrs:{"slot-key":e.$parent.slotKey}},[a("h1",{attrs:{id:"mutual-attestation-why-and-how"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#mutual-attestation-why-and-how"}},[e._v("#")]),e._v(" Mutual Attestation: Why and How")]),e._v(" "),a("p",[e._v("The standard procedure to establish a secure and trusted communication channel\nfrom a client to an enclave is through remote attestation. However, when the\nclient itself is also an enclave and "),a("em",[e._v("mutual")]),e._v(" trust between two enclaves is\nrequired, we need additional design and implementation effort. The Teaclave\nplatform consists of multiple enclave services and most of the\nenclave-to-enclave RPC communications need bidirectional authentication. This\ndocument entails the methodology and process of Teaclave's mutual enclave remote\nattestation.")]),e._v(" "),a("h2",{attrs:{id:"problem"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#problem"}},[e._v("#")]),e._v(" Problem")]),e._v(" "),a("p",[e._v("The identity of an enclave is defined through a pair of cryptographically secure\nhash values, i.e., MRSIGNER and MRENCLAVE. MRSIGNER indicates the builder of the\nenclave, thus shared by enclaves signed by the same party. MRENCLAVE is unique\nto each individual enclave. Teaclave assumes that users do not trust the\nsoftware builder, so verifying MRSIGNER is not enough. For each enclave service\nin Teaclave, it must strictly check the unique identity of the other enclaves it\ncommunicates to through MRENCLAVE.")]),e._v(" "),a("p",[e._v("Since the SGX enclave trusts no outside input, the MRENCLAVE should be\nhard-coded into source files used for identity verification logic. Therefore,\nchanging the MRENCLAVE value an enclave tries to match against will change the\nMRENCLAVE of the enclave itself. When two enclaves want to remotely attest each\nother, it is impossible to decide which enclave is to be built first.")]),e._v(" "),a("h2",{attrs:{id:"solution"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#solution"}},[e._v("#")]),e._v(" Solution")]),e._v(" "),a("p",[e._v("Teaclave resolves this problem by relying on third-party auditors. We assume\nthat there will be several parties trusted by all participants of Teaclave's\ncomputation tasks (cloud platforms, data providers, and customers, etc). The\nsource code and binaries of Teaclave are audited by these trusted parties. Once\nthe auditors decided that Teaclave is secure, they sign and publish the\nidentities of audited enclaves. The "),a("em",[e._v("public keys")]),e._v(" of the auditors are\nhard-coded in Teaclave enclave source via build time configuration, while the\nenclave measures and their signatures are loaded from outside at runtime. Each\nenclave will verify that the enclave measures are indeed signed by the auditors\nbefore serving any requests.")]),e._v(" "),a("h2",{attrs:{id:"in-the-repository"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#in-the-repository"}},[e._v("#")]),e._v(" In the Repository")]),e._v(" "),a("p",[e._v("The "),a("a",{attrs:{href:"https://github.com/apache/incubator-teaclave/tree/master/config/keys",target:"_blank",rel:"noopener noreferrer"}},[e._v("keys")]),e._v("\ndirectory in the source tree contain the key pairs of three fake auditing\nparties for PoC purposes. Private keys are also included to deliver a smooth\nbuild and test process. In production, builders of Teaclave should obtain the\npublic keys, enclave identities, and the signatures directly from the auditors.")])])}),[],!1,null,null,null);t.default=s.exports}}]);