Avoiding theft using trusted computing

[Mike Hearn]

If you look at the thread from slush, he says he used Linode because connectivity from Prague is poor so he does not want to run the pool there. VM providers are very popular these days, I guess because many people don't want to run servers from home. Having a machine with no remote access as the monitor basically requires it be physically close to you, either at home (limited bandwidth, running servers may violate consumer ISP ToS), or at a local colo (prices/connectivity may not be competitive).

The hardware isn't really that obscure, there are over 200 million TPMs out there. The combination of TPM+all the other stuff is a bit more exotic but still available from several well known manufacturers.

Once the initial setup work is done, it can be made available to everyone relatively easily. People can SSH in to their account, run their site and have the sensitive parts run in the isolated space where even the people with physical access to the box would find it hard to compromise. But you can still get the benefits of having other people manage power, cooling, connectivity, etc.

That said, until the work is actually done, I agree that the two server solution is more straightforward.

[1714938594]

1714938594

[1714938594]

1714938594

[1714938594]

1714938594

[1714938594]

1714938594

[DeathAndTaxes]

Once the initial setup work is done, it can be made available to everyone relatively easily. People can SSH in to their account, run their site and have the sensitive parts run in the isolated space where even the people with physical access to the box would find it hard to compromise. But you can still get the benefits of having other people manage power, cooling, connectivity, etc.

I would point out there is a 3rd option.  Secure colocation.  

Maybe it didn't make sense in slush case but for Bitcoinica there is simply no excuse.  They were holding $250K with $50 in security.  It would be like locking up a briefcase holding $250K in cash with a bycicle lock.  No jeweler would have done that, no gold miner would do that.  The "safe" should be priced accordingly to the assets it is protecting.

So not to hit zou while he is down but hopefully that is a wakeup call.  $250K in digital assets should be protected like any other assets worth $250K.

Renting private cage space secured with private key and ID verified access is sub $1000 in many parts of the world.  Most provide secure shipping and remote installation of servers and have bonded employees.  Data security during installation can be ensured with things like truecrypt.  Features like KVM over IP, remote switched PDUs, and private firewalls allow you to build a physical fortress around your hardware which holds your information[/b] that ensures there is no "backdoors".  The cage would never even need to be opened except to replace hardware.  The amount that was stolen could have paid for 20 years of such remote co-location. 

Information Security starts with physical security.  Using a virtual machine is fine to house your personal wallet to $100 in assets.  $250K in assets should have enterprise grade PHYSICAL SECURITY.  That doesn't mean things like 2 factor authentication and TPM aren't important.  They are because future thieves will only become more resourceful but one needs to start with ironclad physical security.

[ripper234]

If you look at the thread from slush, he says he used Linode because connectivity from Prague is poor so he does not want to run the pool there. VM providers are very popular these days, I guess because many people don't want to run servers from home. Having a machine with no remote access as the monitor basically requires it be physically close to you, either at home (limited bandwidth, running servers may violate consumer ISP ToS), or at a local colo (prices/connectivity may not be competitive).

The hardware isn't really that obscure, there are over 200 million TPMs out there. The combination of TPM+all the other stuff is a bit more exotic but still available from several well known manufacturers.

Once the initial setup work is done, it can be made available to everyone relatively easily. People can SSH in to their account, run their site and have the sensitive parts run in the isolated space where even the people with physical access to the box would find it hard to compromise. But you can still get the benefits of having other people manage power, cooling, connectivity, etc.

That said, until the work is actually done, I agree that the two server solution is more straightforward.

I would point out there is a 3rd option.

Secure colocation.  Maybe it didn't make sense in slush case but for Bitcoinica there is simply no excuse.

They were holding $250K with $50 in security.  No jeweler would have done that, no gold miner would do that.  The "safe" should be priced accordingly to the

So not to hit zou while he is down but hopefully that is a wakeup call.  $250K in assets should be protected like $250K in assets.

Renting private cage space secured with private key and ID verified access is sub $1000 in many parts of the world.  Things like KVM over IP, remote switched PDUs, and private firewalls allow you to build a physical fortress around your hardware that ensures there is no "backdoors".  The cage would never even need to be opened except to replace hardware.  The amount that was stolen could have paid for 20 years of such co-location.

Information Security starts with physical security.  Using a virtual machine is fine to house your personal wallet to $100 in assets.  $250K in assets should have enterprise grade PHYSICAL SECURITY.  That doesn't mean things like 2 factor authentication and TPM aren't important.  They are because future thieves will only become more resourceful but one needs to start with ironclad physical security.

+1

It's very easy to start Bitcoin businesses ... securing them as they explode and grow larger is difficult sometimes.
I'm sure Gavin is much less devastated about the few BTC stolen from the faucet than Zhou. What's fit for a freemium non-profit website like the Faucet isn't what's fit for a medium-sized business, isn't what's fit for Mt. Gox, Bitcoinica or any semi-serious Bitcoin exchange for that matter.

[check_status]

You want to implement something like this, but without the secure switch and additional physical servers?
http://www.nsa.gov/ia/media_center/video/orlando2010/flash.shtml

[Hal]

Apologies for resurrecting this old thread, but I wanted to mention a new development. The people that brought you Flicker and TrustVisor, both mentioned by Mike, have a new project out. xmhf is a hypervisor framework built around Trusted Computing. Its main advantage is that it works on both Intel and AMD, but you still need a newer, relatively high-end machine. TrustVisor has been ported to xmhf, so now it works on both architectures whereas previously it was just AMD.

I agree with the comments above that TC may not be quite right for bitcoin. For one thing these secure program compartments can't do any I/O directly. They have to rely on the insecure code to relay data, although crypto keeps the data secure. So if we wanted the user to approve a transaction, you'd have to send the data to a secure device for approval. In which case you might as well use multisig or even just keep all the keys there.

You could try to implement a self-contained policy like rate limiting, although as discussed above you need a secure time source and state rollback protection. I'm worried that using the blockchain as a time standard might be vulnerable to timing games by the untrusted code, although there might be mitigations. A couple of other potential sources of secure time: the network time protocol, which is how a lot of computers keep their time in sync, has a crypto layer. Unfortunately it doesn't seem suitable for public use, although I found out the US NIST will supposedly supply you with an authenticated time if you go through a complicated application process, http://www.nist.gov/pml/div688/grp40/auth-ntp.cfm.

Thinking way outside the box, you could open an SSL connection to a web page that's updated frequently, and use the Date: header from the http response. You'd hard code the CA root cert and all the relaying could be done by the untrusted code and still be secure. I've tried this with https://google.com and the time is pretty accurate. TrustVisor includes a version of openssl so this would seem to be feasible.

But even if you got rate-limiting working, the untrusted code could substitute its addresses for the target addresses, or maybe just skim a percentage off each transaction, hoping to evade detection. A lot of things have to go right for the created transaction to match the user's intentions. Assuming a malware takeover and still trying to protect the user is aiming too high IMO. Maybe we can limit the damage though.

[Mike Hearn]

Superb, Jonathan got TrustVisor open sourced. For a while I think they were considering keeping it proprietary. I talked about TrustVisor with him before, it seems they went even beyond that. I will explore it later.

Thanks for the pointer, Hal. I agree with everything you wrote: I think the design of a supervisor server suitable for use on exchanges/trading platforms/other businesses with hot wallets is very much an open question. Once you have figured out such a design though, moving it into a PAL seems like a fairly straightforward transformation. Issues like how to do rate limiting, to stop a hacked system replacing addresses all need to be resolved for a multi-signer solution to work anyway.

Yes, finding a source of secure time is annoying. Doing an HTTPS request to google.com works - I should know because I've written software that does that before Of course google.com is really not supposed to be a global time server, but serving 404s with a date header is fortunately very cheap. IIRC every Google server is synced to GPS time using an internal NTP pool so it should always be accurate.

Throttling/limiting the damage is a valuable goal in and of itself, as it gives you much more time to notice something has gone wrong and throw the off switch. Even if you don't have any automated way to detect badness, the ground truth is often user complaints. If the losses are small enough you can make things right from your profits.

[casascius]

received as a PM, thought I'd post in the thread:

I was reading  your response to the TC/TPM thread.  Somehow it seems too complex for the gains.

In light of the Bitfloor incident maybe an rs232 black box project is worth pursuing?  Seems to me multiple layers of protocols between boxes makes attack vectors just a pain in the ass that DMZ configurations can't do much about.

I definitely think so...

There needs to be a base use case where the box is a wallet and does nothing more than ask a user to confirm a proposed transaction on its own display, and signs the proposed transaction if the user agreed to it.  Basic messages to the box would include "getnewaddress", "please sign this transaction", and "here is a new transaction/block I heard on the network".  Basic messages from the box would include "here is a new receiving address", "here is your signed transaction", and "I refuse to sign this transaction".

Then the protocol and/or app could be added with user extensions (different for everyone using it for more than a wallet) to implement the security policy of the operator's choice.  The app could be extended to limit total withdrawals within a 24h period without console intervention, or the protocol could be extended to allow the wallet to learn PGP public keys and then require PGP signatures for user withdrawals, or whatever.

The advantage of RS232 is that it's dumb, slow, universally compatible, and well-understood.  The "black box" can be implemented on another PC, a credit card machine, a Raspberry Pi, or even a microcontroller.

[Timo Y]

I am curious why a TPM and all kinds of high-tech kernel wizardry with elaborate cutting edge hardware would be more desirable than a low-tech dedicated computer doing this same thing over RS232 where the airgap is visible, easily explained, and easy to comprehend?  
[...]

TC doesn't require physical access to the server. Your RS232 solution does. 

Apart from being more costly than using a dedicated hosting service, this simply isn't practicable for a lot of bitcoin entrepreneurs, eg. those with a nomadic lifestyle.  Where is Zhou Tong going set up this machine? In his student dorm?

[Mike Hearn]

You don't need a serial cable. A regular network cable is plenty secure enough as long as you tightly control the traffic allowed to it from other machines. In this case it sounds like there was an SSH daemon listening and that is how the attacker was able to log in. So don't do that - require physical access to change the configuration of the server.

The reason for investigating TPMs and related technologies is that if they are quite general and easily integrated by server vendors, so it's cheap and totally reasonable to provision yourself a trusted computing environment in a remote datacenter then do everything via SSH - whilst still having similar security properties that a piece of dedicated hardware would give you. Yes, it's advanced and exotic today, but we're building the payment system of tomorrow, right? So it's worth thinking about these things.

In any event, this currency exchange was still running on Linode months after that provider was found to be unable to withstand a motivated assault. I think these kinds of hacks can be avoided by people doing basic due diligence if they're about to (reality check!) entrust large sums of money to a random guy off the internet!