Oracles provide smart contract developers with real-world data that they can use in the blockchain environment. Popular use cases for oracles involve financial data as this allows the development of financial contract engines based on autonomous smart contracts. Oracles are not limited to financial data. Using the right data, one could also create autonomous crop-insurances based on weather data.
The challenge
The challenge that all oracles face today is how data can be verified as being accurate, timely and complete. Since data is mostly made available through the HTTP protocol an obvious approach could be the use of the widespread HTTPS/TLS protocol, which is already built on top of a public key infrastructure and then simply rely on the certificate (and public key attached to it) that for example “Yahoo Finance” shows. TLS, however, only uses asymmetric encryption for the exchange of symmetric keys (because of performance reasons) whilst actual data applies symmetric encryption. This means that while the connection is end-to-end encrypted, both parties can encrypt/decrypt data making it impossible for a third party to know if this data was really sent from the server. So how can one overcome this challenge?
There are various ways used in crypto projects:
- The data source (i.e. Coinbase) signs the data directly. This is the most elegant solution because it requires no “special” role of data transmitter/data fetcher. This solution is currently only available for crypto related projects which limits the possible use cases significantly (see Compound).
- Put full trust in the data transmitter and assume or hope the data is not manipulated. This approach is common, and sometimes multiple parties are used. One assumes that if enough parties provide the same data it can be trusted (see Chainlink).
- Use a verifiable way to fetch the data, such that a third party can verify that the data was collected in a certain way (see Provable).
For ubinetic oracles we have decided to leverage Android’s key attestation and built-in hardware security modules to create a verifiable trusted execution environment.
Why Android?
When today’s mobile operating systems iOS and Android were developed, the decision was made not to build on top of legacy operating systems, but to start a new operating system from scratch using the best practices known.
Android’s standards include building blocks that enable secure solutions such as cryptographically signed executables (aka Apps), a permission system, application sandboxing, isolated filesystems, no root user and hardware security modules. As a consequence, mobile operating systems are more secure than any server and/or computer operating system.
Gartner independently tested the strengths of security controls and concluded that Android performed best. Based on this report and combined with the options that the Android Safetynet Attestation and Android Key Attestation offer, we chose Android as the platform for this approach.
Gartner test documentation can be found here:
https://blog.google/products/android-enterprise/android-enterprise-security-assessed-gartner/
https://www.wired.com/story/android-zero-day-more-than-ios-zerodium/).
What is the Android SafetyNet Attestation?
All of the mobile security concepts described above only work if the integrity of the device and software running on it can be proven. Google provides with the Android SafetyNet Attestation a way to cryptographically prove that
- a specific executable with a specific signature and hash requested this attestation
- the device has not been tampered with all the way from the boot loader to the application.
You can read more about it here: https://developer.android.com/training/safetynet/attestation
The developer team is aware that there are ways to circumvent (spoof) a “BASIC” SafetyNet attestation (using i.e. https://github.com/kdrag0n/safetynet-fix), but to date there is no way to spoof a “HARDWARE_BACKED” attestation (read more here: https://www.thecustomdroid.com/android-safetynet-hardware-attestation/) as it is used in this setup.
What is the Android Key Attestation?
In addition to the above, Google provides with the Android Key Attestation a way to cryptographically prove that
- the key is located in a Hardware security module (HSM) that Google believes to be secure.
- the key has all the properties described in the attestation
You can read more about it here: https://source.android.com/security/keystore/attestation
The HSM on Android applies strict sandboxing, meaning that only one individual application can access a specific key. And because we can give as an input of our SafetyNet request a custom nonce (self-chosen data), we can link a specific key to a specific executable.
This means we end up with an easily programmable and provable execution environment which is cryptographically attested by Google. The example in the screenshot shows us the certificate trust chain from Google’s Root CA used for key attestations all the way down to our individual key pair which resides in the HSM on the device.
Android HSM supports ECDSA P-256 which is also supported by the Tezos protocol and can be used inside smart contracts.
How is the oracle designed?
An application on several mobile phones run by several independent parties (transmitters) fetches data from liquid markets, initially from APIs of the largest crypto exchanges such as Binance. At the same time, the application checks whether the source of the data is accurate, timely and complete, and signs the data to ensure that manipulation can be detected. The combination of certificate pinning (read more here https://www.digicert.com/dc/blog/certificate-pinning-what-is-certificate-pinning/) and a verifiable tamper-proof execution of our specific application allows the data transmitter to confirm that the collected data corresponds to the data provided by the data source and hence, that the data was never manipulated.
The application periodically posts the data to the Aggregator. To ensure that the App is run independently, multiple so-called Data Transmitters run the mobile devices. The Aggregator verifies and stores the attestations, collects signed data for an interval and publishes the data to the Tezos smart contract. Data normalisation, specifically calculating the volume-weighted averages of the data from the different exchanges, is transparently managed in the smart contract.
How can an end-user verify this process?
By integrating the Google data verification process into the Tezos smart contract information, the user is able to verify that the data was sourced without modification. Independent endorsements of data transmitters of their keys strengthen the independence additionally and increase the stability of the overall setup. Finally, the data normalization can be seen in the smart contracts. More information can be found on https://ubinetic.com/oracles/.
Summary
- By leveraging secure hardware with cryptography and a PKI given by Google we provide a way to verify fetched data from data sources and provide that data in a Tezos smart contract consumable format
- The system requires trust in Google’s PKI
- The system requires trust in Android’s security
- The system requires a dedicated Android device (in our implementation, two devices per Data Transmitter)
What is planned in the future?
Oracles with this design can handle different data sources with the same security and stability. Different Data Transmitters may offer new data sources that support new DApps, new products or processes. Currently, the Tezos smart contracts and the non-blockchain elements of the setup are being audited by IT Security firms.
