EDIT 2 May 2015
Updated setup instructions can be found here:https://github.com/tlsnotary/pagesigner-oracles
EDIT 18 Oct 2013
Here is a link to a comprehensive explanation of what must be done to setup an oracle on AWS.https://github.com/themighty1/ssllog/blob/development/oracle/INSTALL
I'd like to suggest for peer review a method of proving that a certain set of programs (called oracle)
1) is available on a certain IP address hosted on Amazon AWS
2) has not been and cannot be tampered with
This method relies on Amazon Query API and assumes that Amazon itself will not tamper with the oracle.
This can have many applications for the Bitcoin servces, to me this is really useful in connection with the project I'm currently working on: creating a decentralized bank-transfer-to-BTC exchange based on certain SSL logging techniques.https://bitcointalk.org/index.php?topic=173220.0
Steps needed to setup an oracle:
1. Start an instance from an Amazon-provided AMI with EBS-backed storage and modify all the software acc.to oracle's needs. Make note of the AMI ID.
2. Create a snapshot of the EBS volume and make that snapshot public. Make note of the Snapshot ID.
3. Publically describe all the modifcations made to AMI's EBS volume, so that anyone with an AWS account could take the original AMI's EBS, perform the modifications and compare file tree hashes against the hashes of the public Snapshot.
4. Assuming ec2-api-tools installed. Start the oracle with
ec2-run-instances <AMI id> -k mykeypair -t t1.micro -z us-east-1a -b /dev/sda1=none -b /dev/sda1=<Snapshot ID>::false:standard -O <access ID> -W <secret key>
The trick here is that Amazon starts the AMI, doesn't attach its default volume but attaches a new volume which is automatically created by Amazon from the snapshot we published earlier.
5. Create GET requests using the following Amazon Query API.
DescribeInstances - shows you launch-time, IP address, block device attach time
DescribeVolumes - shows you snapshot ID from which the volume was created, and time of creation.
Now anyone can use those get requests to compare the times when the instance was started, when the volume was created and when the volume was attached. Usually volume is created and attached on the same second, and the volume gets attached to the instance 2-3 seconds after the instance is launched.
1. If the attacker tries to detach the volume, modify it and then attach it back, the attach time will be changed and the attack will be detected.
2. Amazon only allows instances to use Amazon pre-made kernels and init ramdisks. This rules out the possibility of tampering with the volume durng boot time.
3. All Amazon root partitions are mounted to /dev/sda1. The attacker can attach a rogue volume during the boot to /dev/sda1 and the legit volume as /dev/sda2. He will then modify the legit volume and will try to unmount the rogue volume from /dev/sda1 and re-mount the legit volume to /dev/sda1. Linux doesn't allow the root partition to be unmounted on a live system. Besides, DescribeInstances API will show that the legit volume was initially attached to /dev/sda2 and not /dev/sda1 as it was supposed to.
But assuming the attacker finds a way to game the way Amazon attaches/detaches volumes, there is still another extra layer of protection:
API call GetMetrics returns a list of all volumes of the AWS account that were attached within the last two weeks. Part of the proving process will be that the oracle owner must not have any other volumes attached in his AWS account.
Are there any weaknesses which I might have overlooked?