A short introduction to TPMs

[jgarzik]

Bitcoiners,

A useful link:  A short introduction to TPMs - http://mjg59.dreamwidth.org/24818.html

Hal, Mike Hearn and a few others have talked about using TPMs in the context of bitcoin key storage, or trusted execution of oracles. See https://en.bitcoin.it/wiki/Securing_online_services and https://en.bitcoin.it/wiki/Contracts#Example_4:_Using_external_state

It would be interesting to brainstorm what uses bitcoin software could make of TPMs.

[1715006132]

1715006132

[1715006132]

1715006132

[1715006132]

1715006132

[1715006132]

1715006132

[Peter Todd]

It would be interesting to brainstorm what uses bitcoin software could make of TPMs.

Trusted execution/remote attestation is enormously useful.

Remember that Hal's reusable proof-of-work scheme created a tradable asset directly from remote attestation and an honest ledger keeper. Similarly MintChip is basically a trusted hardware scheme. In principle you don't even need the blockchain at all if you can trust the other party to record coins moved accurately, and in practice with a blockchain as a source of secure value you can use careful engineering to limit the losses due to any broken trusted hardware implementation and provide a way to move value from one incompatible system to another.

General purpose and reasonably secure trusted execution with remote attestation would be truly groundbreaking if it can be made widely available, and not just for Bitcoin or even just financial applications. As an example Tor nodes can use remote attestation to prove they are not keeping logs of what data passes through them. In conjunction with fixed rate, fixed time slot networking this gives much better anonymity guarantees than Tor can provide right now, and with remote attestation systems guaranteed by distinct vendors - say an implementation from a US company, from a Russian company, and from a Chinese company - you can force all parties to work together to break your anonymity.

There might be reasons other than engineering that have prevented secure remote attesting TPM's from being becoming available to the general consumer...


edit: FWIW the link says that the TPM's in consumer hardware don't support remote attestation (via the quoting mechanism) because none of the certificates are signed. That's actually incorrect: at least one of the major TPM vendors, Infineon, signs the keypairs for the standalone chips they sell. (surface mount SOIC20 package FWIW; you can buy them on digikey) The issue is actually that the hardware is not secure at all and can be attacked trivially given physical access. Now with tamper protection that's not an issue, but you can't (yet) buy tamper-proof hardware with those chips in them, let alone tamper-proof hardware with the keys signed by the manufacturer in a trust chain. (AFAIK the few TPM's that are integrated into the North Bridge in some Intel chipsets do not come with certificates for their keys)

[Mike Hearn]

Good topic. Remote attestation is useful but I think the initial way to use TC will be as Hal did - as ways to secure wallets on potentially compromised web servers.

Note that a TPM by itself is not enough. It needs to be integrated with the CPU, motherboard and BIOS via infrastructure like Intel TXT or the AMD equivalents. You also need software infrastructure like Flicker or TrustVisor.

I was lamenting many years ago that people who should have known better were spreading FUD and knee-jerk reactions about TC because "zomg drm". In reality TC was never very useful for DRM but did have a lot of other applications, and the general PR disaster-zone it turned into really held back investment in the technology.

Fortunately, enough of it was completed to be useful to Bitcoiners. A good and simple business opportunity is for someone to set up a secure hosting provider that offers dedicated TC capable hardware. Given the vulnerability of pools to hacking there is serious BTC to be made by the first programmer to implement TC-secured pool accounting.

[Mike Hearn]

Here's something to think about - can we use TC to help solve our volatility problem?

Consider a business owner who is selling burgers for bitcoin throughout the month. Let's call him Joerg. His landlord also accepts Bitcoins for rent. The owner knows that he sells enough burgers to pay his rent at the end of the month, but the landlord pegs the rental price in BTC to the Euro thus exposing the owner to FX risk. If the value of a coin drops towards the end of the month, his accumulated coins may not be enough to make rent.

If Joerg thinks there's a risk BTC/EUR may drop, and he can find someone who thinks the opposite, he can form a direct bet with that other person. When he sells a burger he puts in the bitcoins received into a multi-input transaction with the counterparty. The pool has a liquidation date when the coins get sent back to each person but if both agree they can liquidate early. The pool is linked to a chosen exchange rate.  For instance these parties could find each other via a P2P broadcast network.

Let's say he puts in 1 BTC and the other side also puts in 1 BTC. Each coin is worth $100. If the exchange rate goes up to $110 then the amount of coins he gets out drops to 0.9 and the counterparty gets 1.1 BTC. If it goes down to $90 then the opposite happens. Regardless, Joerg gets out the equivalent of $100 (unless the counterparty can't cover the movement of course).

This is not exactly a futures contract but has a similar effect in that it lets you hedge your exposure to risk.

The problem is you can't do that purely peer-to-peer even with tx replacement because the moment one side seemed to be losing the bet they'd stop taking part in updating the contract in order to minimise their losses. The money needs to be controlled by a third party who will ensure the money is reallocated as appropriate without the bettors being able to stop it.

If someone implemented the oracle protocol you could use that and gain trust through challenging with bogus transactions. But the scalability of this is poor - the more challenges that are submitted the more trust you have, but if each user does this with no coordination the oracles resources would end up being mostly consumed with unused executions, which could be expensive. Also, it takes time to run enough challenges to convince yourself that the oracle operator is executing them all correctly, which means oracles have to stick around for a while before you can use them.

TC+remote attestation can solve those issues. Anyone who has the right hardware can immediately start serving requests and there's no need for bogus challenges because the trust is provided via RA instead. That means you can find nodes capable of mediating your contract via a simple P2P network where providers broadcast their prices and then you just pick one. The software that runs on the CPU would seal the private key that controls the money for a given contract to its state, remotely attest that it's running and take as input a signed feed of exchange rates+a signed timestamp. It'd then generate a signed transaction apportioning the money as output. The attestation gives you the confidence you need to send money to the appropriate public key.

As Peter notes, not all hardware is capable of this, so there's some effort involved with finding it, buying it and getting things set up. But once done you could just leave it running in your spare room and let payments roll in (dare I say .... micropayments?).

[Peter Todd]

In general you have to understand that what trusted computing provides is a way to trust the execution environment and not much else. It won't magically make your code less buggy; if anything the brittleness of most TC environments can wind up increasing risk by making it harder to apply patches and perform backups.

For instance, Hal implemented a very nice time-based spending limit using the Trusted Platform Module (TPM) support common in consumer computers these days. It works because that TPM, in conjunction with the Flicker software and Intel's Trusted Execution Technology, (TXT) provides a trusted execution environment for the wallet code to operate in. That code then only allows you to spend Bitcoins at a limited rate. It could be a useful thing for, say, the hot wallet of a pool or something.

The thing is you can get the exact same functionality with no special software or hardware by simply keeping a server in a physically secure location - maybe the pool operators closet - running the exact same code. Just firewall that server so everything but the single port used to communicate with the wallet software is blocked and you're good to go. It's not as cool, but it works. That hot wallet operators don't bother with those measures just shows how the incentives aren't really there if it's someone else's money, and all that is at stake is your reputation; you know, it's kinda sad how most of the off-chain transaction stuff I've been thinking about has nothing to do with off-chain transactions and everything to do with making Bitcoin-related services more secure in general...

For some applications knowing that your private keys are secure is useful. Amazon recently started offering a service called CloudHSM where they operate a Luna SA Hardware Security Module at their data center on your behalf. The hardware keeps the private keys safe, so you know even though Amazon has physical access to the HSM they can't get them. Sounds great right? Well, support you stored the private keys to a Bitcoin wallet in a HSM. A hacker who has gained access to your server just has to ask the HSM to sign transactions sending the coins in the wallet to him; the HSM is just a dumb box and has no idea what it is signing. If you are a certificate authority it might be valuable to know you can use the same private keys after an attack as the attacker can't create fraudulent certificates after the fact, but very few Bitcoin-related applications need to be able to use the same addresses after a hack. Unsurprisingly Amazon markets CloudHSM as a tool to meet regulatory requirements rather than a tool to actually make your servers more secure.

Going back to the idea of offering TC/TPM capable servers remotely as a business, if you can't trust the hardware with remote attestation, there really isn't much point. Granted, sometimes you can: apparently all of Akamai's edge servers supporting SSL run hardware that has been securely purchased and built, outfitted with anti-tamper sensors, and then shipped as sealed (not locked!) units to the ISP's they are installed in. They remotely interrogate the server after installation to ensure it has not been tampered with, load the SSL keys into memory, and it's ready to go. If some curious tech at the ISP wanders along and opens the door sensors immediately shutdown the unit, wipe the SSL keys from memory, and log the tamper event. I haven't seen any more public information on exactly how it works, if it actually uses TPM technology or just relies on custom anti-tamper sensors, but it's sounds like it could be a decent system.

The discrete TPM chips like the ones Infineon sells that often get incorporated into motherboards make for some pretty awful overall systems. They communicate with the rest of the system via an unauthenticated 33MHz bus. All you have to do to attack one is use a cheap logic analyzer to record the state the TPM chip is put into as system runs, and then replay that state later to get it into the configuration required to get it to sign/decrypt things using the secret keys inside. The North Bridge integrated versions are a bit better, but again, there are lots of ways to crack them without much cost if you have physical access. In short, the hardware isn't good enough to sell secure remote access, even with a certificate chain vouching for the TPM device, and AFAIK there isn't anything off-the-shelf that you can purchase and ship to the server farm without it being vulnerable to tampering. But it's feasible to build the missing parts yourself as Akamai apparently has.

With regard to DRM, keep in mind that what was planned by Microsoft's Palladium technology would have made for a very effective DRM - the concerns about it were completely justified. But in the end I think the company didn't think pursuing it was really worth it given the outrage and the technical complexity. It's much easier and cheaper to just rely on making copying difficult and using legal means for the remaining holes than it is to actually make a conventional OS TPM capable and make conventional hardware secure. The sealed storage model that has been implemented is extremely brittle with regard to software changes and updates - it's just not very practical for anything complex, hence Intel TXT and Flicker.


I agree it'd be really good to get Mt. Gox and other exchanges to start signing and timestamping their price data. You should raise the issue at the conference - it'd help a whole lot of applications.

[Mike Hearn]

Yeah, an attacker with physical access is a much harder problem. TC is still useful for pool ops and other kinds of hot wallets though, because it reduces the attack surface of the sensitive part of the system without the need for actual physically separate systems, which often you don't really want for cost reasons.

That said, I think most pools could take a good step forwards towards this state by renting two cheap VPS from different providers. The frontend talks to the backend via a Tor hidden service. Only the pool op knows where the backend is. Successfully hacking the frontend via colo compromise or otherwise doesn't help you find the hot wallet. The trick is then indeed to ensure that the protocols between frontend and backend are secure enough that the frontend can be untrusted/malicious.

[jl2012]

Bitcoiners,

A useful link:  A short introduction to TPMs - http://mjg59.dreamwidth.org/24818.html

Hal, Mike Hearn and a few others have talked about using TPMs in the context of bitcoin key storage, or trusted execution of oracles. See https://en.bitcoin.it/wiki/Securing_online_services and https://en.bitcoin.it/wiki/Contracts#Example_4:_Using_external_state

It would be interesting to brainstorm what uses bitcoin software could make of TPMs.

Running blockexplorer.com with TPM. If there are multiple services of this type running on different TPM platforms, average Joe won't need to run full nodes anymore. These TPM full nodes could be supported by ad or subscription fee

[Mike Hearn]

Joe already doesn't need to run a full node. They can use an SPV client. The chain is self-proving.

You could run a node inside a TC secured VM in order to raise peoples confidence in the traffic you're relaying that isn't blocks, though.

[Zeilap]

Joe already doesn't need to run a full node. They can use an SPV client. The chain is self-proving.

But the SPV client has no guarantee that he's been given all transactions relevant to him. If you can trust a remote peer, then you can be sure that you have been given everything.

What might be better is for a trusted service running a full node to expose a 'getbalance <scriptPubkey>' command which looks up the scriptPubkey in the UTXO set and returns the total value of all unspent outputs to that scriptPubkey. This would mean that the transaction downloads could be from untrusted peers (like now) and then confirmation that you've received everything is done by querying a trusted node for the final balance and comparing it to your calculated balance.

[Mike Hearn]

That comes up a lot, but what's the threat model here? If a node wants to DoS a client it can just not serve any data at all. If it's trying to make you think you didn't receive a payment when you did, comparing the results from a few different nodes should be enough to reveal the subterfuge. If that doesn't work, it means your internet connection is hijacked: see the recent discussion on bitcoin-development for ideas about what to do in that scenario.

OK, currently bitcoinj doesn't compare nodes with each other, mostly because nobody is attacking users in that way. But if we did start seeing it then we could implement multi-querying fairly easily.

[Zeilap]

That comes up a lot, but what's the threat model here? If a node wants to DoS a client it can just not serve any data at all. If it's trying to make you think you didn't receive a payment when you did, comparing the results from a few different nodes should be enough to reveal the subterfuge. If that doesn't work, it means your internet connection is hijacked: see the recent discussion on bitcoin-development for ideas about what to do in that scenario.

OK, currently bitcoinj doesn't compare nodes with each other, mostly because nobody is attacking users in that way. But if we did start seeing it then we could implement multi-querying fairly easily.

Yes, I agree it's a solution looking for a problem, but we're brainstorming 

[Mike Hearn]

Fair enough :-)

Someone contacted me recently about implementing the oracle system. I hope they pull through. If they do, the next step (after quorums of oracles?) would be to have TC secured and remotely attesting oracles. It's a larger project but all the pieces exist, someone just has to pick them up and put them together.

Something else that might be cool is an extension to the payment protocol such that you can provide a remote attestation in the PaymentACK message (is DAA interactive, I wonder?). Your wallet app would have the core wallet maintenance and signing code run in the TC secured environment. All the rest (GUI, network, etc) would run in the standard domain. The goal is that you can provide a proof you aren't going to (easily) double spend when uploading a transaction. Direct anonymous attestation allows you to control the linkability of attestations that nevertheless allow blacklisting of compromised TPMs.

This obviously doesn't stop super-hackers like Peter who can use bus sniffers, but it could help in the case where someone finds a point and click way to double spend, like a mining pool appears which deliberately takes part in Finney attacks. I'd hope nobody would be dumb enough to do that, but if it happened some merchants might have a policy that they wait a block unless you provide a remote attestation of your wallet core on the grounds that lots of people who might be able to run EvilWallet and click "Double spend this payment" wouldn't be able to hack their own hardware.

[jl2012]

Fair enough :-)

Someone contacted me recently about implementing the oracle system. I hope they pull through. If they do, the next step (after quorums of oracles?) would be to have TC secured and remotely attesting oracles. It's a larger project but all the pieces exist, someone just has to pick them up and put them together.

Something else that might be cool is an extension to the payment protocol such that you can provide a remote attestation in the PaymentACK message (is DAA interactive, I wonder?). Your wallet app would have the core wallet maintenance and signing code run in the TC secured environment. All the rest (GUI, network, etc) would run in the standard domain. The goal is that you can provide a proof you aren't going to (easily) double spend when uploading a transaction. Direct anonymous attestation allows you to control the linkability of attestations that nevertheless allow blacklisting of compromised TPMs.

This obviously doesn't stop super-hackers like Peter who can use bus sniffers, but it could help in the case where someone finds a point and click way to double spend, like a mining pool appears which deliberately takes part in Finney attacks. I'd hope nobody would be dumb enough to do that, but if it happened some merchants might have a policy that they wait a block unless you provide a remote attestation of your wallet core on the grounds that lots of people who might be able to run EvilWallet and click "Double spend this payment" wouldn't be able to hack their own hardware.

I'm sorry, what is oracle system?

I think the double spend problem could be solved in another (maybe better) way using 2-of-2 multisig. That requires a trusted 3rd party (e.g. bitcoin foundation). An user will first send bitcoins to a 2-of-2 address, which one private key is held by the user and the other held by BTC foundation. It's the multi-sig version of green address but the BTC foundation won't be able to run with the bitcoin. (TPM also requires trust: you trust the hardware manufacturer and assume the user is not a super-hacker)

[jgarzik]

I'm sorry, what is oracle system?

See https://en.bitcoin.it/wiki/Contracts#Example_4:_Using_external_state

There is a lot of discussion about using bots for various things.  It's fun.

[Zeilap]

Someone contacted me recently about implementing the oracle system. I hope they pull through. If they do, the next step (after quorums of oracles?) would be to have TC secured and remotely attesting oracles. It's a larger project but all the pieces exist, someone just has to pick them up and put them together.

Yes, this is interesting. You just reminded me - I had a thought some time ago that it might be possible to create trusted oracles using some kind of secure 2-party computation, such that the oracle doesn't know what it is that he knows, and therefore cannot lie convincingly. I guess it's very similar underneath to your garbled circuit blacklisting idea - have you already considered this?

Something else that might be cool is an extension to the payment protocol such that you can provide a remote attestation in the PaymentACK message (is DAA interactive, I wonder?). Your wallet app would have the core wallet maintenance and signing code run in the TC secured environment. All the rest (GUI, network, etc) would run in the standard domain. The goal is that you can provide a proof you aren't going to (easily) double spend when uploading a transaction. Direct anonymous attestation allows you to control the linkability of attestations that nevertheless allow blacklisting of compromised TPMs.

This goes the other way too. If I receive a PaymentACK saying the payment was rejected, it would be nice to have proof that the merchant won't still broadcast my payment anyway.

[Mike Hearn]

The oracle challenge system is designed to provide that kind of thing - the oracle doesn't know if he's signing for a transaction that really exists or one that's fictional. The idea being that you can't halt and demand that the user cuts you in because you're constantly handling randomly generated requests and you don't know which is real and which is fake. I think that provides very similar guarantees to more complex systems but without any fancy crypto.

Yes you can have semi-trusted third parties that guarantee against double spends, but then you depend on their availability and they will want to charge fees, etc. Because the TPM is local if your device is available, your trust proofs are also available and you can generate them for free.

[Peter Todd]

This obviously doesn't stop super-hackers like Peter who can use bus sniffers, but it could help in the case where someone finds a point and click way to double spend, like a mining pool appears which deliberately takes part in Finney attacks.

Be careful with making assumptions that it takes a "super-hacker" to use a bus sniffer; if people start depending on that I fully expect to soon see mod chips become available, just like they did for game consoles, that incorporate a specialized bus sniffer/recorder so some software can easily hack the system with very little actual user understanding.

The thing is, punishing double-spend fraud after the fact is very easy because proving it to others is trivial. You have some identity - which can be a pseudonym - commit to not double-spending fraudulently(1) and if they are found to have done so a short fraud proof can be easily constructed destroying that identity. The identity then just has to be expensive to obtain, like the keypair built into your remote attestation hardware, or one you have purchased a fidelity bond for, or both for that matter. A promised backed by hardware that takes a hundred dollars worth of labour to break is one that can be trusted that much more for your morning coffee.

The advantage of this approach is as a side-effect it nicely provides for a blacklist of compromised TC hardware, and provides infrastructure to detect such compromises in the first place.

Mycellium will be at the conference apparently showing off their bitcoincard product. They claim it has hardware double-spend prevention in it - I'll be very curious to see what they've actually accomplished. Unfortunately it'll also be interesting to see how FinCEN decides to regulate intermediaries like them, and indeed all secure remote attestation capable hardware.


1) Keep in mind a double-spend isn't fraudulent if the merchant still gets the same or more funds. Double-spending to change transaction fees after the fact, or to combine multiple payments in a mix with others, simply changes how they were paid, not that they were paid.

[beeblebrox]

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).

[Peter Todd]

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

Absolutely, and such transactions have much better privacy than on-chain transactions ever will, not to mention they can be instant. There is a fair bit of complexity involved in mitigating risk given that no trusted computing hardware is totally secure against an attack, but it's easy to make any attack far too expensive to be feasible. You wouldn't want to trust it for, say, buying a house, but it's plenty secure enough to buy your morning coffee.

I'll be talking about that exact idea at the Bitcoin conference next week.

(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).

Take a look at the wiki: https://en.bitcoin.it/wiki/Funding_network_security

Mike Hearn has some interesting ideas with assurance contracts and other schemes that in the long run can probably replace miners fee rewards. In any case the inflation subsidy will remain quite large for a long time to come; it hits 1% of the face value of all Bitcoins out there in 2024 or so for instance.

[jl2012]

Fair enough :-)

Someone contacted me recently about implementing the oracle system. I hope they pull through. If they do, the next step (after quorums of oracles?) would be to have TC secured and remotely attesting oracles. It's a larger project but all the pieces exist, someone just has to pick them up and put them together.

Something else that might be cool is an extension to the payment protocol such that you can provide a remote attestation in the PaymentACK message (is DAA interactive, I wonder?). Your wallet app would have the core wallet maintenance and signing code run in the TC secured environment. All the rest (GUI, network, etc) would run in the standard domain. The goal is that you can provide a proof you aren't going to (easily) double spend when uploading a transaction. Direct anonymous attestation allows you to control the linkability of attestations that nevertheless allow blacklisting of compromised TPMs.

This obviously doesn't stop super-hackers like Peter who can use bus sniffers, but it could help in the case where someone finds a point and click way to double spend, like a mining pool appears which deliberately takes part in Finney attacks. I'd hope nobody would be dumb enough to do that, but if it happened some merchants might have a policy that they wait a block unless you provide a remote attestation of your wallet core on the grounds that lots of people who might be able to run EvilWallet and click "Double spend this payment" wouldn't be able to hack their own hardware.

Could people backup their private key? If yes, they could double-spend. If no, coins are lost forever if the hardware is broken.