Verifiable Oracles for Tezos by ubinetic

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

There are various ways used in crypto projects:

  1. 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).
  2. 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).
  3. 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?

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://bayton.org/docs/enterprise-mobility/android/gartner-comparison-of-security-controls-for-mobile-devices-2019/

https://www.wired.com/story/android-zero-day-more-than-ios-zerodium/).

What is the Android SafetyNet Attestation?

  • 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?

  • 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?

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?

Summary

  • 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?

Enables you to create your bespoke synthetic asset