Soon, after few years as the technology improves and becomes ubiquitous, another use for DRM will be that it can be used for off-chain transactions:
https://bitcointalk.org/index.php?topic=148232.msg1578079#msg1578079 (As-an-aside: Eventually, I believe this will cause problems for bitcoin because in the future most transactions will be performed off-chain. DRM based transactions for small amounts and something like traditional bank exchange for large amounts. This is will to lead to a decreasing number of on-chain transactions and reduce the miners fee rewards).
I've been reviewing mobile phone security. It appears that we might be able to implement a scheme like this on the Samsung KNOX architecture. Though I'm not sure if it does general remote attestation it does however appear to have all the other requirements.
Does anyone here know if KNOX supports remote anonymous attestation?
(It must be able to do some sort of attestation to support the features that it claims to although it looks like the phone has to configured by a company's/organization's central IT department first and then it can attest to their computers (only theirs?) when necessary ).
---------------------------------------------------
Also, I am interested in contributing funding to an off-chain system like this. If anyone wants to start a funding drive I'll pledge 50 BTC to it for the first person to deliver a working smart-phone app that implements an off-chain transfer like this (with conditions such as that it has been reviewed for security flaws by a some of the respected programmers of the bitcoin community, is open-source, etc.).
To save you clicking it, here is a re-cap of the basic off-chain coin transfer scheme from the link above:
Basically it is the public/private key pair of a wallet address that is stored cryptographically on just one computer at a time. The public key is still publicly available knowledge and can be viewed arbitrarily (eg: someone may access the public address in order to look it up on the block chain to check its balance). However the private key can only be accessed once, once it has been retrieved the coin itself is destroyed so it cannot be transferred again. The coin should also store the balance that was transferred to the address when it was created (Note: someone may add more money into it after creation because the public address is known. It would be a strange thing to do though. So the balance is technically the minimum amount that it contains-- if someone adds extra money the coin itself doesn't know about this. Only the initial creation balance is known by the coin.)
Now for the model: (Note: this is just a simple hypothetical model- in reality it would be more detailed than this). The model has three different parts, 1)coin creation, 2) coin transfer and 3)reveal private key.
Let's use the following example to explain how it the first two parts work:
Sender Sally has at least 5 BTC on-chain in her wallet. Receiver Ross is coming to collect the 5 BTC she owes him, but Ross will only accept TC/DRM coin because he doesn't want to wait around 20min-90min for 3 confirmations to prove that he has received the coin. So sally has to 1) create a coin holding 5 BTC before Ross comes and 2) transfer it to Ross when he arrives.
1) Coin creation:
a)Firstly, Sally secure boots her computer. This procedure puts the hardware into a precisely defined state and prohibits all non-signed pre-OS binaries to run (eg: the OS boot loader will only be run if it's signature matches that stored on chip). This prevents low-level pre-OS attacks such as rootkits. see:
http://en.wikipedia.org/wiki/Uefi#Secure_bootb)Once the OS is up and running then Sally runs the program and selects the "make-TC/DRM-coin" option. This software checks before it does anything that it is running on a securely-booted machine in a secure state.
c)Once the software knows that it is safe, it creates a the private/public key pair address and makes a standard on-chain transaction to load the address with 5 BTC. The software doesn't reveal the private key to Sally.
d)Once the transaction has been confirmed (the number of confirmations can be arbitrarily decided by the user.) the software puts this key pair plus a record of the amount into sealed storage. see:
http://en.wikipedia.org/wiki/Trusted_Computing#Sealed_storageThe coin has now been successfully created
2) Coin Exchange:
a)Both Sally and Ross secure boot their computers.
b)They both run the software and Sally chooses the "transfer-TC/DRM-coin" option. Like the before the first thing the program does is establish that it is running in a safe, secure environment.
c)The software establishes a secure connection between the two computers. Let's just say it is SSL over a direct computer-computer WiFi connection for this case.
d)Once the connection is established, the two computers both remote attest to the other that it is running an untampered version of the "make-TC/DRM-coin" software on a secure computer. see:
http://en.wikipedia.org/wiki/Trusted_Computing#Remote_attestation and
http://en.wikipedia.org/wiki/Direct_anonymous_attestation3)Sally's computer retrieves the coin from secure storage and transfers it to Ross's machine. Sally's machine deletes its copy. On receipt Ross's machine places it into sealed storage. (This transfer would actually be a little tricky because of the need for confirmation of the transfer before Sally has her coin deleted. Computer protocols for this sort of thing already exist.)
Voila! The coin has been transferred.
For the last part: Let's assume the Ross for some reason or other wants to transfer some amount of the coin on-chain within the Bitcoin network:
3)Reveal Private Key:
a)Ross secure boots his computer
b)He runs the program and chooses the "reveal-private-key" option. Similarly to the other options, the software only continues only if it being run securely.
c)The software retrieves the coin form sealed storage, informs Ross of the private key and destroys the coin. He can now perform standard on-chain transactions.
There you go. A simple protocol of a secure private key exchange.
Please note though: In real life you wouldn't make a new TC/DRM coin each time for a specific transaction. Rather you would make a lot of them preemptively at commonly used denominations (eg: if you had 1000BTC make 9x100BTC coin, 9x10BTCcoin, 9x1BTC, 9x0.1BTC, 10x0.001BTC) and would exchange the required number of each denomination to make up the amount required. eg: to transfer 156BTC transfer 1x100BTC, 5x10BTC, 6x1BTC.
Also note: the software can reveal the public key and amount of the coin at any time-- this can be used to increase the confidence of the person receiving the coin that the TC/DRM hardware/software protection mechanisms haven't been defeated since they can check that the address still has at least the amount stated before accepting it. It can also be used to check the number of confirmations of the coin.
