[Ethereum] How does Oraclize handle the TLSnotary secret

cryptographyoraclesSecurity

Oraclize claims to offer a provably honest secure retrieval of a webpage by taking advantage of TLSnotary (a service that allows an auditor to verify if a specific web page was accurately retrieved)

The purpose of Oraclize seems to be to make this information available to smart contracts.

But to my understanding, the only factor keeping the TLSnotary proof secure is that the person doing the auditing generates and withholds a secret piece of data until the person being audited provides them with the hash of the retrieved web page. A contract obviously cannot generate and withhold a secret. Doesn't this mean that the contract itself is unable to verify the TLSnotary proof?

It seems like some clarification is needed of how exactly Oraclize is handling the TLSnotary secret.

Oraclize also seems to offer a web tool allowing you to play the role of the auditor. Can multiple people audit the same TLSnotary proof in parallel? And suppose I do somehow manage catch Oraclize cheating. How can I prove this to a third party?

Put in more simple terms, how much can I trust Oraclize's service?

Don't take my questions the wrong way–I'm very excited by the idea of oracles actually proving their claims. I just like to ask difficult questions!

Best Answer

Oraclize stores the TLSnotary secret in an Amazon Web Services (AWS) Virtual Machine.

Using the techniques described here, they are able to provide some additional guarantees regarding the software running in the AWS instance and when/whether it has been modified since being initialised. The "proofs of honesty" they provide (and allow you to verify with their web tool) are the signed attestations of this AWS instance that a proper TLSnotary proof did occur (rather than the TLSnotary proof itself, which would be impossible for a third party to verify after the fact).

It's probably difficult for the average user to understand what this means in terms of security and trust, so let me elaborate a little regarding the security implications of this technique.

Major advantages of the Oraclize approach:

  • By involving an AWS oracle, Oraclize has made it harder for their data retrieval service to lie about the contents of a web page. So this approach is slightly better than a purely trusted oracle service.
  • Also, someone who compromises Oraclize's smart contract doesn't automatically gain the ability to fake results (with most oracle services, compromising the key or smart contract would let you fake arbitrary results)
  • Finally, verifying the signature of the AWS oracle is a comparatively "cheap" computational operation, so Oraclize's "honesty proofs" could potentially be verified on chain provided that the TLSnotarised content is short enough (like an API call).

Major disadvantages of the Oraclize approach:

  • Amazon themselves, or anyone able to hack/subpoena Amazon's AWS platform, can gain an ability to fake the "proofs of honesty" by stealing the AWS oracle's private key. This entity would probably also have to gain control of the Oraclize API server and/or smart contract if they wanted to break applications based on Oraclize's service, however.
  • If you do catch someone faking Oraclize proofs, there's no way to prove it to anyone else unless you yourself can obtain the AWS oracle's private key. For further clarity: if you retrieve some data from Oraclize and it's obviously wrong, there's no way for the public to know whether the server or the Oraclize service is the source of the problem. Either can just blame the other.
  • Don't forget that when retrieving a web page through an oracle, you're still allowing the web server to respond with anything it wants. So for 3rd party attackers, it would probably be much easier to just compromise the server when you want to break an app that uses Oraclize (i.e. the exchange website if an app uses it for market prices). With this point (and the previous one) in mind, it's a lot less hassle to just get the information provider to be the oracle. Oraclize should be thought of as a fallback for retrieving information from sources who aren't blockchain aware. Blockchain aware sources should just sign their information directly.
  • In many information retrieval situations (where only two parties are involved), it would make a lot more sense for the parties to the transaction themselves to act as client and auditor in the TLSnotary proof. This gives you all the guarantees of Oraclize with none of the additional risks.

Things Oraclize can do to improve:

  • offer a large, on-chain bounty for successful retrieval of their AWS oracle's private key.
  • ensure that their AWS oracle's code is hardened against vm side-channel attacks (i.e. signing operations are all constant time and memory, etc.)
  • set up various simple static https pages and offer a large, on-chain bounty that pays out to any address retrieved from those pages via Oraclize's API. This would be a simultaneous bet on their behalf against Oraclize's proof mechanisms being compromised and against attackers being able to compromise an Oraclize-run server.

tl;dr:

Oraclize is better than nothing for retrieving content from an HTTPS web page. It's probably the best we can do right now for making public claims about the contents of secure web pages. But it shouldn't be considered a final or completely secure solution to the retrieval of web content. In many cases, having your apps use TLSnotary themselves is strictly superior to using Oraclize. And having an information provider sign their content directly is superior to both in all cases! Oraclize is a decent step forward, but it's not the final solution. Be careful that you use their service in a manner appropriate to the risk level of your application!

Related Topic