Topic: Avoiding theft using trusted computing - page 2. (Read 4948 times)

No.  The TPM has no time data beyond system clock.

Are there any trusted time servers which sign timestamps and provide a public key for verification.  If so the TPM could require timestamps which it then verifies against a stored copy of the public key (which it keeps encrypted so only TPM can access).   Failure to authenticate timestamp, failure to provide timestamp, or failure to meet payment rules would result in TPM denying all transactions until it receives a verifiable timestamp 24 hours in the future.

On edit: as indicated above DUH the blockchain.  Close enough for this work and nearly impossible to spoof at least economically.

Um... yes. The bitcoin block-chain.

I thought of a similar concept, the idea in my head being that the trusted box only have an RS232 connection to the world, using a port that is completely nonresponsive until a process of some sort opens it directly (e.g. No shell, no getty or opportunity to ctrl-c the controlling program back to a shell prompt etc.). Such a box could use plain untrusted hardware off the shelf.

With such a setup, control of the box remains airgapped while leaving a connection just big enough to pass the activity being validated and the signatures.

If a trusted time source is needed just hook a common GPS receiver to another serial port, which reports UTC derived from the GPS system.

If I'm understanding this correctly, it's similar to the plans for Open Transactions. They will have several servers running OT and will only sign a multisig transaction if they agree.

Trusted computing would be more open-ended, since you could run whatever code you want. Open Transactions would be cheaper and more secure, but one would need to build everything out of smart contracts. Could be useful for something like Bitcoinica, though.

What if you periodically feed the hot wallet from the outside, only from a secure server,
(offline transactions ?). Can this be a simpler approach to limit loss, or is it just nonsense ?

Great ideas, Mike. I think the "use two servers" approach will happen first (you typically want at least two servers anyway just for backup and redundancy), but trusted code running in a TPM could be an extremely powerful and cost-effective building block for much more secure solutions.

RE:

That seems like the hardest problem.

Does the TPM have access to a guaranteed-to-be-unhackable time source? If it does, then a policy like "do not approve more than X bitcoins worth of transactions in timeperiod Y" should work well enough to prevent more than petty theft, assuming you've got some other way of watching the blockchain for unauthorized transactions and shutting down the compromised machine or using an emergency offline backup key to move the funds to a non-compromised wallet.

Finally, TC being used for good instead of evil!

This sounds promising.  Subscribing.

In recent times the Bitcoin community has suffered from major service providers being hacked and coins being stolen. Mitigation techniques include the use of hot/cold wallets and secure coding techniques, but secure coding does not help much if the infrastructure providers themselves are breached.

One possible solution proposed by Gavin is having a "monitor" server and multisig transactions. The monitor would check the transactions submitted to it for consistency and only sign if valid. This is a useful approach but suffers from some limitations:

• It's expensive (you need to pay extra hosting costs)
• It is tempting to reduce management overhead by duplicating configuration, eg, using Linux on both systems instead of Linux and Windows, or having the SSH keys for each in the same place, or using the same VPS for both. That reduces the security benefits dramatically.
• There are likely to be bandwidth/latency constraints between the two hosts that will make verification of the transactions harder

Trusted computing lets us solve some of these problems by allowing the creation of the "monitor server" inside the untrusted, possibly compromised server. The bandwidth between them is similar to your regular memory bandwidth. Only one piece of hardware is needed. The monitor runs an absolutely minimal piece of code, not even including a regular operating system, thus there is little or nothing that can be hacked. The monitor is resistant to physical attack by bad insiders.

I'd like to convince you of the benefits of this approach in the hope that an intrepid entrepreneur may start offering shell accounts on TC servers to the Bitcoin community, along with tutorials and libraries to assist in the development of secure monitors. By reducing the costs of the dual-sided approach I hope to see it become a lot more common, and accessible even to small or amateur operations that would likely not consider a multi-server setup.

You start with a platform that implements the Trusted Computing Groups technical specifications, for example:

• Dell PowerEdge T105 server
• HP dc7800 workstation
• Dell Optiplex 740 workstation
• Dell Optiplex 755 workstation
• Lenovo T400 laptop
• HP 8530p laptop
• HP 8540p laptop
• HP Elite 8100 desktop

The specs I'm talking about are open and you can read them directly, but I recommend a decent book like this one to become familiar with the underlying technologies. I only offer a brief overview here.

A TC platform contains a chip called a trusted platform module (TPM), which can be standalone but these days is often integrated into the southbridge. The TPM is a tamper resistant crypto chip. It's important to understand that a TPM is not a crypto accelerator. TPMs are very slow. Instead they provide a repository for cryptographic keys that is difficult to compromise even by a physically present and determined attacker.

Together with some special CPU instructions, it's possible to create isolated software worlds which are extremely difficult to attack, even by somebody who has compromised the host OS. It works like so:

• Code running in the (possibly compromised) regular operating system environment loads sensitive application code into memory, for example, in Bitcoinicas case it might be a part of the trading engine, in slushs case it might be the code that examines some data files to create the payout transactions. It also loads any data files that program might need, typically these will be encrypted.
• You execute the magic instruction. On AMD this is the SKINIT instruction, on Intel chips it's the more complicated SENTER instruction. What happens next is a bit convoluted, but to simplify, the CPU performs a kind of reset in which the host operating system loses control - interrupts are suspended, other cores are shut down and execution resumes at the start of the sensitive code block. Crucially as a part of this process the TPM is initialized with hashes of the sensitive code and any other code in the system that can affect execution, like the BIOS.
• The TPM has the ability to "seal" encryption keys such that they are only released from the chip when the CPU is in particular states. For instance you can seal a key under a hash of the sensitive code. It then isn't possible for the host OS to make the TPM cough up the key. The sensitive code asks the TPM to unseal the key, and it does so because the CPU has already (electrically) informed it that the hardware is in the expected state.
• The sensitive code then performs whatever calculations it needs, for example, it may decrypt the wallet loaded into memory for it by the untrusted code, create and sign some Bitcoin transactions, which it then deposits in a region of memory that was previously reserved for it by the untrusted/possibly compromised code.
• The code wipes the memory it used, then exits the secure state with the SEXIT instruction (or AMD equivalent).
• The untrusted host OS can then take the signed transactions and relay them to the Bitcoin network.

Actually implementing all this is complex. Fortunately some nice people have written Flicker which makes the process easy. Flicker is very small, which means it's easy to audit and convince yourself there are no flaws that might allow the host OS to make the isolated world do something unexpected.

The nice thing about this approach is that TC is a very general tool. For instance it has applications in intelligent agents, secure timestamping, oracles and other topics that may be of interest to Bitcoiners. The isolated worlds can create cryptographic proofs of their execution that are verifiable by others - this means you can dramatically increase your trust in a third party, providing an interesting and often cheaper alternative to the "quorum of independent participants" paradigm.

There are some open questions that need to be solved first:

• Services like Linode reduce their costs by virtualizing the hardware. It's possible to virtualize TC hardware, indeed, the open source "tboot" project from Intel suspends the host OS and then literally installs a Xen-based hypervisor underneath it on the fly, allowing an entirely separate copy of Linux to boot which runs in parallel to the first one - all tracked by the TPM. However this increases complexity a lot! First versions of TC services would probably want to find a simpler way to support virtualization.
• How do you make writing secure monitors easy for people who are not necesssarily comfortable with C or C++? Flicker helps a lot but it still assumes fluency in low level programming.
• How do you abstract and simplify the techniques needed to track external state. For instance, a pool server needs to track who is owed what payouts. Even if an attacker can't compromise the wallet, they could submit bogus payment data to the monitor and trick it into signing away its money. The monitor could potentially store and manage the entire database itself, but there are often better ways. The trick is to make them simple. This is a problem shared with the multi-server approach. Common design patterns would help a lot.

I plan to research some of these topics in the coming months.