7.5 Data Security

Assuming that the data generated by the oracles is indeed correct, how can we ensure its security in the transmission phase from the oracles to the Blockchain? Or in our specific case, from the oracles to the on-chain data aggregators?

Two approaches are commonly used to enable verification of data integrity:

1. Authenticity proofs Authenticity proofs are based on cryptographic algorithms, which allow to ensure the authenticity of the data arrived at the Blockchain. The focus with this methodology shifts from the data carrier to the attestation provider. Authenticity is verified on-chain, so that Smart Contracts can verify the integrity of the input data before using it. One of the most widely used attestations in the Ethereum environment is TLSNotary, which allows a client to provide proof of an exchange of data that took place between it and the server via HTTPS protocol. HTTPS does not support the process of data signing, but TLSNotary bases its certification on PageSigner, which instead pertains to the transport layer and is therefore managed by the Transport Layer Security. The TLS master key is used to sign data after they have been accessed, it can be divided between three actors of the transaction: the server (the oracle), the certifying entity and the recipient of the message. One of the most widely used certification services, called Oraclize, is based on Amazon Web Services virtual machines whose instances are verifiably immutable (via hashing) from the moment they are installed.

2. TEE trusted execution environments This approach uses secure hardware-based enclaves to ensure data integrity. For example, the use of Intel's Software Guard eXtensions (SGX) ensures that HTTPS query responses can be verified as authentic. SGX ensures that applications running within an enclave are protected by the CPU against the intervention of other malicious processes. It also provides privacy as it prevents other processes from knowing the state of the process running inside the enclave. Lastly SGX enables data attestation by generating a digital signature with a hash of the build of its process running inside the enclave. The smart contact verifies digital signature then knows that the process is running inside the SGX enclave, this then proves that the state of the process has not been tampered with and therefore the data output from the enclave is authentic. By using an oracle query/response system running inside an enclave with SGX we can ensure that it is running securely on 'trusted' third party hardware, thus ensuring that the requested data is not tampered with.