Topic: [ANN] bcflick - using TPM's and Trusted Computing to strengthen Bitcoin wallets (Read 21536 times)

its`s great

ya this implies Mark was not really that stupid as to let all those coins "disappear" ! ?    hmmmm

Cool finding. I must say I'm not surprised that there's a correlation between "exchanges run by people who implement math libraries" and "exchanges that are run competently". I wish we had a dozen more of Mark and Hal.

I noticed Hall mentions LibTomMath in the OP, the only time it has ever been mentioned on this forum. I'm curious as to how that term relates to the following: https://groups.google.com/group/libtom/tree/browse_frm/thread/54e386b8696e964d/763a8138e9d0bb61?_done=%2Fgroup%2Flibtom%2Fbrowse_frm%2Fthread%2F54e386b8696e964d%2F763a8138e9d0bb61%3Ftvc%3D1%26&tvc=1

From the newbie jail (jnewsome, you should be able to post here now):

Hi,
I signed up for the forum to reply to this thread https://bitcointalk.org/index.php?PHPSESSID=vu5sekbqqr91jnsqnb28jfn7k3&topic=154290.0, where they are discussing using trusted computing, and in particular Flicker, to implement a hardened bitcoin wallet.

I am (well, was) one of a small number of engineers working with Jon McCune on the follow-on work to Flicker. That work includes XMHF, XMHF-TrustVisor, and TEE-SDK, all published under the 'XMHF' umbrella: http://sourceforge.net/projects/xmhf/

In particular I'd like to point out that the TEE-SDK addresses some of the concerns raised in that thread. It includes a simple marshalling library, with an optional protocol-buffers layer on top. It also supports multiple trusted execution environment back-ends. The ones currently implemented are as a XMHF-TrustVisor based PAL, or a "NULL" userspace backend for debugging. Envisioned alternative backends include Flicker, or a privileged process running on the machine (as one commenter suggested).

The general trend, in the Linux kernel at least, is to base everything around a poll-able file descriptor.  Google for "epoll_create", "signalfd", "eventfd", "timerfd_create", etc.

New syscalls take a long time to fully deploy on some platforms, and are often under-used for that reason.  It is easier to create a driver that services standard, long-deployed file descriptor syscalls: read, write, poll/select, etc.

Indeed, I bricked my laptop when I was first experimenting with this technology several years ago. Fortunately it was under warrantee and they replaced it. All you have to do is make sure your BIOS is up to date and that won't be a problem.

As far as XMHF (TrustVisor) I just bought a new system from bitcoinstore.com which should support it. This is a newer technology than Flicker which should remove some of the limitations. I'm worried though because Jon McCune, whose group is doing both of those projects, left CMU for Google. The projects seem a little rudderless now.

I should note now that if anyone wants to actually play with this, you must observe the following warnings.

• Before starting, ensure your BIOS is the latest version. Failure to update your BIOS could result in a bricked motherboard.
• The TPM ownership password should obviously not be available anywhere on the machine itself after you have taken ownership. It should be long and random. If you aren't using a safe mode, then watch out for bash history files and other things that remember your command history.
• You may also need to enable hardware virtualization in the BIOS, along with the TPM.
• You may not use a PAE kernel.
• On Intel systems you need something called an SINIT file. Make sure you have the latest version and it matches your motherboard/chipset.
• My post talks about physically present attackers. Whilst TPM/TC technology is designed to thwart these too (ie, corrupt datacenter operators), Flicker doesn't actually do everything required on the software side. In particular I believe that it does not configure the IOMMU properly. Also, no existing TC library (neither flicker nor trustvisor) sets the CPU cache to no-fill mode, meaning that someone who can attach a bus sniffer to your hardware might be able to recover the wallet keys from RAM. This is a fairly sophisticated attack, but large hot wallets in untrustworthy colocation centers could theoretically motivate such a thing.

All that said, if you don't have a TPM or don't want to bother with it, you could easily adapt Hal's code to run without one and just rely on plain old kernel level isolation (ie, run bcflick as a different user and just use a local socket to relay command buffers back and forth). It's not as good as the real thing but it raises the bar from "find a bug in your web app" to "find a bug in your web app and a local root exploit", which is a pretty significant change.

If you want to use it but don't want to have to boot into a safe mode, you can probably assume that a freshly provisioned server didn't come pre-attacked by the provider unless it's already well known that you're a big and rich Bitcoin operation.

Start of the security analysis

bcflick is a Flicker PAL (Piece of Application Logic) designed to increase the security of the Satoshi Bitcoin client. Flicker uses security features on modern processors to create an isolated, cryptographically protected segment of memory which is immune to tampering by other code running on the same computer. These security features go by different names depending on the manufacturer. Intel calls it TXT, while AMD calls it SVM. I will refer to it here simply as the secure mode.

The threat model which bcflick is designed to address is a thorough infection by sophisticated malware. It is assumed that the attacker can corrupt the operating system, install key loggers, read and write files and network traffic, and generally exert arbitrary control over the computer. Despite this powerful attacker, bcflick lets the user spend and receive bitcoins, and enforces a daily limit on the number of bitcoins spent. The attacker, as well as the user, is bound by that limit. This prevents the attacker from stealing the bitcoins all at once. He is forced to let them trickle out a little at a time, giving the user a chance to detect and mitigate the theft.

Although this is a powerful attacker, we have to restrict its capability is one way. We assume that there is some way to boot into a "safe" mode, out of the control of the attacker. Typically this would be done by booting from an external medium, a CD or a USB drive. Technically, sophisticated malware can insinuate itself into even a boot from a clean medium, by inserting itself into the firmware of some peripheral device, or even the BIOS. However, these techniques are little used and hardware dependent. In practice, booting from a clean external device will produce a safe mode with high probability.

bcflick uses the safe mode for three purposes. On initialization, the wallet is encrypted, and the decryption key is passed to bcflick, along with the daily spending limit. It is also used for error recovery, such as if the TPM timer gets reset, or if a Flicker crash gets things out of sync. By booting into safe mode, the user can reset the passphrase, and that will reinitialize bcflick. Last, if the user wants to spend more than the bcflick policy permits, he can boot into safe mode, unlock the wallet with the passphrase, and create arbitrary transactions, bypassing bcflick.

The remainder of this document discusses the security design of bcflick. It is dived into four parts. I first list the security assumptions. The second part addresses security related to Flicker and the secure mode. The next part discusses Bitcoin related security. Finally, I conclude with further directions for research.

I was thinking about that for general paranoid users too - have a smartphone application to compute a cryptographic hash for an address + amount, and validate every transaction this way.

Really nice use of a TPM device.

By the way, what's up with the bizarre Flicker API? It's been a while since I did any kernel programming, but is there some jihad against adding new syscalls? Writing single character commands to a control fd seems like a very strange way to do things vs just invoking a syscall with the set of params being marshalled that way. Also, it seems odd that the files are not world read/write by default. I guess the Flicker module could be fixed to not require root to use it.

A nice extension would be to allow the PAL to accept signed commands that updated its limits. That way a server operator can keep the signing keys offline at home/office and send them to the server if needed to raise/lower the limit temporarily, without needing to re-initialize bcflick each time.

Thanks Hal. I realized after I did my post that I could just read the code and was about to post the same thing, but you beat me to it.

This is really nice work, the code is very easy to read. I think it'd be great to get it integrated into the core code. Whilst regular end users probably wouldn't be the first target, operations like mining pools or anyone who currently has a "hot wallet" on a live server could easily benefit. And the setup doesn't look all that complex, really. You just need to ensure you have a dedicated server of the right hardware type and then run a few commands.

What's more, the PAL code that is implementing the policy is quite straightforward. It could be easily extended to define more specialised policies.

A few more thoughts:

• The command buffer serialization/unserialization code looks like the kind of thing that can easily go wrong. I'd be tempted to use protobufs for all data input/output.
• The TrustVisor approach is nice in that it just optimises out the cost of the secure/insecure world switch and handles function parameter marshalling for you. Do you think the additional complexity of TrustVisor makes it not worth it for this particular use case?
• For more complex policies, a secure database system is likely to be needed. I think a library that provides key/value mappings with a hash chain linking transactions is the way to go, sort of a block chain without the proofs of work or split/merge behaviour and in which the head block hash is stored into the PAL state.

Actually TPM's do have a secure clock. There's just no guarantee about when it will keep ticking. You can detect if it gets reset because there is a 20 byte nonce, which changes at every reset. I've found that my HP laptop preserves the timer in S3 sleep, I don't know for sure, but I shut it down for a few seconds and it seemed to be preserved, which was a surprise. And my HP desktop system is never shutdown, but it preserves the timer across reboots.

If bcflick eetects a timer reset, it won't let you spend anything for 24 hours. But you can always boot into a safe mode and reset your passphrase. This will reininitialize bcflick and you can spend up to the daily limit, right away.

For an implementation of this designed for busy services could simply take advantage of the slowness of flicker itself to keep track of time roughly. Just assume every flicker call takes t time and increment your current time variable.

This is superb. Even though it's prototype level, I can imagine your stated policy being useful.

One quick question - I didn't think TPMs have a secure clock. Did I just miss that feature or have you found some other way to link the secure world to real time? You mentioned before using the Date header in an SSLd google.com request seems good enough.


(edit: after re-reading the old thread it seems the date header suggestion was actually from Hal himself)

In this post, https://bitcointalksearch.org/topic/avoiding-theft-using-trusted-computing-67508, Mike Hearn gives a good introduction to trusted computing technology and how it could help secure Bitcoin wallets. I've been working on these ideas, using the Flicker software that Mike linked to, and it's about ready for testing, if anyone is interested.

Basically it's a patched version of bitcoin-qt/bitcoind (for Linux only) that enforces limits on your daily spending. You could get infected with malware and the most it could do would be to drain your wallet a little bit at a time. All this with a single machine, although only certain models of Intel and AMD processors support the secure mode.

Mike gives a good summary of the principles of trusted computing. Suffice it to say that the technology allows you to create a piece of code that can run unmolested by the rest of the computer. The TPM chip is used to cryptographically protect its data. The data is sealed to the hash of the secure code, so that only that piece of code has access to its secrets.

I'm using Jon McCune's Flicker technology. Flicker switches you into the secure mode for just an instant, and then switches you back out again. In this way, the secure mode doesn't have to coexist with the operating system, which would require hypervisor technology. Flicker is only about 3000 lines of code, small as these things go.

I've made a Flicker module (they call it a PAL) called bcflick. And I've patched bitcoind to make calls into bcflick to generate new keys and to sign transactions. The Flicker module knows the wallet encryption key, while bitcoind (normally) doesn't. So the only way to sign transactions, for you or for malware, is to go through bcflick. Bcflick knows the time from the TPM and keeps track of the amount spent today, and will refuse to sign a transaction if the daily amount were to exceed the pre-set limit.

Because Flicker is so minimal, it has limitations. The total size of the PAL has to be less than 1 Meg. And the size of the input to and output from the PAL is a couple hundred K. More importantly, the PAL can't do any device I/O, because that would interfere with OS management of devices. Basically, the PAL starts up, reads input buffer, does work, and writes its output buffer, all in the blink of an eye. Actually, that is a little exaggerated about the speed. Because the TPM is so slow, and because of the firmware overhead in switching into the secure mode, a Flicker call takes a substantial fraction of a second.

These Flicker limitations restrict what we can do to strengthen a Bitcoin wallet. We can't ask the user to approve spends, because of no I/O. So the policy enforcement has to be self-contained. The daily spending limit seemed useful and not too complex. More complicated policies could be supported, such as adjusted daily limits based on the average of recent days. More ambitious would be to take into consideration infow of funds; this would require parsing the block chain, including dealing with reorgs.

It's best to start with a new wallet. If you have some funds, transfer them elsewhere temporarily and delete wallet.dat. After you finish initialization, transfer your funds back to new, bcflick-protected addresses.

In more detail, bcflick must be initialized when running cleanly, i.e. malware-free. This is unfortunately impossible. An approximation can be achieved by booting from a live CD or USB. Doing this will eliminate all but the most sophisticated threats.

In this mode, start bitcoind with the -flickerlimit switch. This will allow you to set the daily spending limit that bcflick will enforce.  Then encrypt the new wallet with a long passphrase. This will pass the wallet encryption key to bcflick, along with the daily spending limit.

If you don't want to transfer your funds away and you are certain that you are not currently infected with malware, there is a shortcut. Boot into a clean mode and start bitcoind with the -flickerlimit switch. Then change your passphrase. You can change it to something longer, or even have the old and new passphrases be the same. Executing a passphrase change (re)initializes bcflick with the wallet encryption key and spending limit. This procedure is also useful when things go wrong and bcflick stops working. Boot into a clean state, run bitcoind with -flickerlimit, and change the passphrase from itself to itself.

Then you can boot into a regular mode, and bcflick will sign transactions, using the wallet encryption key to decrypt the signing keys. Bcflick will also create (encrypted) keys. This is so malware can't observe any decrypted keys. Any other operations requiring the wallet passphrase, such as spending in excess of the daily limit, should be done by booting into a clean mode and entering the passphrase. Under no circumstances should you enter your passphrase without booting into a clean mode. Otherwise, malware could learn it, and steal all your funds.

Because the passphrase is not needed for daily use, you can use a longer and more complex one. That, coupled with the infrequent use, means you should probably write it down and store it in a secure place.

I need to write more about the security model, both Flicker related and Bitcoin related. But in the mean time, here is a quick-start guide:



Experimental integration of Flicker with Bitcoin

Get a computer that supports Flicker

Set up the TPM:
Get TPM/J from http://projects.csail.mit.edu/tc/tpmj/
Enable the TPM in BIOS
Take ownership of the TPM with sudo java edu.mit.csail.tpmj.tools.TPMTakeOwnership
Create a counter with sudo java edu.mit.csail.tpmj.tools.TPMCreateCounter BITC

Get the master branch of flicker working, git clone git://git.code.sf.net/p/flickertcb/code
Get the master branch of bitcoin working, git clone git://github.com/bitcoin/bitcoin.git
Download the bitcoin block chain
If you have bitcoins, transfer them elsewhere and delete wallet.dat
Get the flicker branch, git clone http://github.com/halfinney/bitcoin/
Get the mytxtck branch, git clone git://git.code.sf.net/u/hal/flickertcb
Make a symbolic link called flicker in the bitcoin directory pointing to the flicker/examples/app directory
Run make in flicker/examples/{app,pal/libtommath,pal}
Copy flicker/examples/pal/bcflick.bin to ~/.bitcoin
Run make bitcoind in bitcoin/src
Run chmod 666 /sys/devices/system/cpu/cpu*/online /sys/kernel/flicker/* (you'll probably have to do this after every reboot)
Boot into a secure mode (eg. boot from a live CD)
Run bitcoind -flickerlimit= &  where limit is the maximum daily limit of bitcoins spent
Run bitcoind encryptwallet
Boot into a regular mode and flicker will limit the amount spent per day to the limit you have set, without requiring a passphrase
Now you can transfer your funds back, to new addresses in your wallet
If you want to spend more, boot into the secure mode and unlock the wallet with the passphrase