Skip to content

Latest commit

 

History

History
66 lines (51 loc) · 5.47 KB

security_tm_chainrelay.md

File metadata and controls

66 lines (51 loc) · 5.47 KB
Raw

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 integritee-network/worker#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: integritee-network/worker#85

Analysis

Attack Category Actor Description Mitigation Assessment
Impersonation User Get 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
Eclipsing Operator or ISP Expose the worker to a different (malicious) node Rely on finality and read proofs with Light-Client OK since M6
Spoofing Operator Modify the enclave to perform malicious operations Remote Attestation, TrustedCall signature payload includes MRENCLAVE OK
Tampering User Replay TrustedCalls (i.e. repeat transactions of funds until account depleted) Use of nonce in TrustedCall known issue
Tampering Operator Tamper 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
Tampering Operator Tamper with the state of the enclave State is encrypted with the state-encryption-key, the private key stored in SGX sealed storage with MRENCLAVE policy known issue
Tampering Operator Block confirmations from worker to node Redundancy of workers OK
Tampering Operator Modify worker-api response to TrustedGetter Enclave signs responses known issue
Repudiation Operator Deny WorkerApi access to certain users selectively Redundancy of workers OK
Information disclosure Operator Get information about contents of TrustedCalls TrustedCalls are encrypted with public shielding key of the enclave (whose private key is stored in SGX sealed storage with MRENCLAVE policy) known issue
Information disclosure Operator Get information about contents of TrustedGetters responses Encrypt responses
wss:// to WorkerApi into enclave		 known issue
Information disclosure Operator Get metainformation about TrustedCalls Indirect 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 disclosure Operator Know which incognito account belongs to whom SGX confidentiality guarantees, encrypted TrustedCall and TrustedGetter with enclave shielding key known issue
Information disclosure Operator Leak state information SGX confidentiality guarantees, encrypted state with state-encryption-key
MRENCLAVE policy for SGX sealed storage		 known issue
Information disclosure User Get information about other accounts and users in the enclave Authentication of TrustedGetter.
User can only query own state		 OK
Denial of service Operator Limit the resources of the worker or the enclave to slow down the system Redundancy of workers OK
Denial of service User Send invalid transactions to crash either the worker or the enclave Ensure enclave code doesn't panic OK to the best of our knowledge
Denial of service User Overload 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