Threat model of ChainRelay

Introduction

A security threat model for the ChainRelay of Integritee.

The following points will be analysed:

  • Spoofing
  • Tampering
  • Repudiation
  • Information disclosure
  • Denial of service
  • Elevation of privileges

System overview

Diagram

Actors

User

User of the system that holds tokens either on-chain or in an incognito account.

  • He uses the integritee-cli
  • He can send extrinsics/transactions to the node that will then be processed by the enclave
  • He can query his own enclave state, the enclave public key and the mutual-remote-attestation port directly from a worker over WebSocket
  • He holds his keypairs (for on-chain and incognito accounts)

Worker operator

Operates the worker and the enclave.

  • He uses the integritee-service
  • He has full access to the system (HW, OS and services)

Vendor

Releases Integritee software

  • He distributes SW binaries
  • He can sign enclaves with MRSIGNER

There is no specific vendor in Integritee as it is open source code that can be deterministically built by anyone to reach an identical MRENCLAVE for the enclave. Therefore, each operator is also a vendor!

Because of this Integritee may not use MRSIGNER policy but MRENCLAVE for SGX sealed storage (known issue https://github.com/integritee-network/worker/issues/88)! This means that sealed storage can only be accessed by the very same untampered version of the enclave running on the same HW platform.

Software updates are not yet supported: https://github.com/integritee-network/worker/issues/85

Analysis

Attack CategoryActorDescriptionMitigationAssessment
ImpersonationUserGet access to private keys of other users.Protection of keys and key stores with passwords.
WARNING: This is the responsibility of the developer building the client. Our example client does not include any mitigations.
delegated
EclipsingOperator or ISPExpose the worker to a different (malicious) nodeRely on finality and read proofs with Light-ClientOK since M6
SpoofingOperatorModify the enclave to perform malicious operationsRemote Attestation, TrustedCall signature payload includes MRENCLAVEOK
TamperingUserReplay TrustedCalls (i.e. repeat transactions of funds until account depleted)Use of nonce in TrustedCallknown issue
TamperingOperatorTamper with the block header store of the Light-Client (roll back or modify)Block header store is encrypted as SGX sealed storage
Sync with chain upon startup
Verify linked-hash-chain of block headers
OK
TamperingOperatorTamper with the state of the enclaveState is encrypted with the state-encryption-key, the private key stored in SGX sealed storage with MRENCLAVE policyknown issue
TamperingOperatorBlock confirmations from worker to nodeRedundancy of workersOK
TamperingOperatorModify worker-api response to TrustedGetterEnclave signs responsesknown issue
RepudiationOperatorDeny WorkerApi access to certain users selectivelyRedundancy of workersOK
Information disclosureOperatorGet information about contents of TrustedCallsTrustedCalls are encrypted with public shielding key of the enclave (whose private key is stored in SGX sealed storage with MRENCLAVE policy)known issue
Information disclosureOperatorGet information about contents of TrustedGetters responsesEncrypt responses
wss:// to WorkerApi into enclave
known issue
Information disclosureOperatorGet metainformation about TrustedCallsIndirect invocation: need to use public account to proxy the TrustedCall through blockchain. Use fresh unlinkable accounts for each TrustedCall.
Direct invocation: limited access to metainformation (network layer only)
(delegated)
known issue
Information disclosureOperatorKnow which incognito account belongs to whomSGX confidentiality guarantees, encrypted TrustedCall and TrustedGetter with enclave shielding keyknown issue
Information disclosureOperatorLeak state informationSGX confidentiality guarantees, encrypted state with state-encryption-key
MRENCLAVE policy for SGX sealed storage
known issue
Information disclosureUserGet information about other accounts and users in the enclaveAuthentication of TrustedGetter.
User can only query own state
OK
Denial of serviceOperatorLimit the resources of the worker or the enclave to slow down the systemRedundancy of workersOK
Denial of serviceUserSend invalid transactions to crash either the worker or the enclaveEnsure enclave code doesn't panicOK to the best of our knowledge
Denial of serviceUserOverload the system with spam (TrustedGetters or TrustedCalls)TrustedCalls: cost of tx fees (indirect invocation), Blocksize limit
TrustedGetter: load balancing as needed (scale number of workers horizontally), standard DDoS mitigations
delegated