Topic: What can really be done about server hacking - page 2. (Read 8334 times)

That's where your customized secure code comes in.  You can refuse withdrawals over a certain limit, or program in some sort of two-factor authentication for withdrawals, or even just a simple password needs to be input before a set of withdrawals is processed.

If you keep the wallet file on the web server though, all it takes is a compromise of the web server and the criminal can copy the private keys and do what he wants.

DeathAndTaxes,

there's one thing I don't grasp...

What stops someone having access to the web fronting compromised machine from sending a command through the serial port to the hardened PC requesting an 18K withdrawal?

spiccioli.

I don't know enough about the armory client to know what kind of API access it has.  It can be done with the Satoshi client though.  Physical access can be hardened through the use of secure chassis (lockable and not w/ those $0.20 "computer locks"), locked co-location cage, and intrusion tamper switch.  Connect the intrusion tamper switch to the motherboard hard reset pins.  Open case and motherboard reboots disabling access to the encrypted wallet. 

Like I said poor mans solution  but a 1U wallet server w/ hardened chassis, IPMI, a linux distro, and serial port should be <$1K even with niceties like redundant drives/PSU, TPM (to prevent decryption of wallet file even if stolen inroute and passphrase leaked/stolen).  I haven't checked transaction throughput on an atom based system but if it is sufficient you could likely build a "HSM in a box" for ~$500.


The quote doesn't clearly indicate if that code is running INTERNALLY on the HSM or if "nCore" is marketing for their API to allow external programs to interface w/ the HSM.  The former is awesome but the later doesn't provide much additional security.  Sadly it is tough to get any real information from thales website.  I hate marketing "buzz".  Come on Thales, show me the specs, the API, code examples.  How much internal memory do the HSM have, how much nonvolatile storage, etc.

very true, however seeing as now there is a proven market for Bitcoin Finacial Services, these services should be using these sorts devices to protect the coins of their customers.  It is like the old addage, "best practices are for those who are not capale doing thier own due dilligence". 

The good thing about spending this amount of cash is you have the potential to get insurace from proper finacial brokers and you can publish your security model, in all its gory details so it can be peer reviewed.


Can this be done already? using the armoury client? rather than usb from machine to machine, just connect them over serial with a python/perl socket script. still doesnt help too much with physical access.  still useful for protecting a home setup.  I might see if I can get this running later today.


yeah the yubi looks very awkward to set up (you might be able to do this with 4 yubi keys and their one time password feature, but I cannot be bothered to think about it.)

I would be interested in what you look up.  I might be able to give you remote access to the edge when it gets here (no promises though)

Running custom code is part of the nCore interface. 

http://www.thales-esecurity.com/Resources/Solution%20Sheets/Options%20for%20nShield%20HSMs.aspx


If you look at the bottom of that link there is a supported feature list for the nShield series HSMs.  All of them (the nShield range) support custom code.  Although for running in an off site location I would probably only go for a solo (i am pretty sure it is cheaper than the netHSM or nShield Connet).

the edge is not completely weak, iirc it will only run signed code... this is a pretty good defense, not amazing, but it is alright.

cheers,

steve

How about keeping your Bitcoins offline as much as possible?  It is difficult to hack a machine that is off.  Theft is really your only course of action.   Encrypted hard-drives help keep that safe in the event of theft.  Proper policy is the large step in the right direction.

That kinda sums it all up.  Just because Bitcoin can be instant may not mean it always should be instant.

* Let your page/backend/whatever create a list of tuples like this: [(address1, amount1), (address2, amount2), ...]
* get a current copy of the blockchain from a trusted bitcoin node
* take the blockchain copy + payout list to the offline PC, let it create and sign transactions and save them to a third file.
* feed the transactions back to the bitcoin network

The above can be done as often/frequently as you like. No PC will ever have a chance (other than virus codes embedded in the blockchain?) to be compromised, keys are offline from the beginning etc.

Some other use cases:
If you need fresh keys for deposits, just generate a bunch of them on the offline PC and transfer a text file with the resulting addresses only.
If you need to know how much was deposited to which account, you don't need the private keys for that - just run a standard bitcoind and don't use it's wallet at all, instead query for address balances etc.

Really, is the "convenience" of being able to pull money from an exchange/bitcoinica/... within one hour instead of one day really worth the real danger that they can get hit as hard as they repeadedly were?

Agreed however I would point out the Bitcoin "robbery" was the digital version of a smash and grab.  The list wasn't intended to be comprehensive (and shouldn't be taken as such).  There will always be an escalation.  As simple attacks are defeated attackers will move to more complex attacks.

However codebase security/audits without physical security is worthless.  It doesn't matter if your codebase is hardened against intrusion if the theif can simply change the locks and let himself in the front door and walk out with all the loot. Rock solid physical security can lay the foundation for a more comprehensive and hardened system.  It is the beginning not the end but it has to start there or the rest is futile.

As a db developer I can tell you #3 is pretty simple to secure against.  Don't allow the web application to execute ANY arbitrary SQL.  Period.  With no exceptions (no matter how much the web developers bitch and moan).

Interesting.

Although for $20K it likely isn't cost effective for most operations.  A "poor mans" version would be a dedicated locked down box.


Web Application server connects to a tx server via serial port.  The tx server is the "poor mans's HSM".  It has no uncessary applications, no ssh, no remote login.  It simply communicates to the outside world via serial port.

It gets inputs from the serial port, runs them against its "rules", builds tx from private keys and outputs signed tx.  Changes to the tx server could be accomplished by simply providing it a new complete distro.


Interesting.  I will look into it.  The yubi HSM though would not be useful for securing a hotwallet.  It has no ability to run internal code and merely provides secure key generation and storage.  If the host has access to the yubi then so does the attacker.

On edit: The docs on the edge don't seem to indicate the ability to run internal custom code but maybe I am missing it.

of course your are correct, i was over simplifying and went too far, to the point where i was wrong.  I was trying to create payshield type hsm functionality and ended up messing it up.
however, the point i was making was valid... see below.


the answer is very much yes. what you have outlined above was the usecase i was trying to put forward (although without the explicit business rules and simple value based ones instead, the way you have proposed it is much clearer.), from the page on the solo:

http://www.thales-esecurity.com/Products/Hardware%20Security%20Modules/nShield%20Solo.aspx
(also has quotes from the solo feature page)


see, this stuff _will_ make things safer.  you could have the client and blockchain on the device if you wanted (not sure why you would, but you can)


By on chip, i meant all the action takes place in the device.


I intend on doing this if/when my edge gets here (I have been told I will get one to play with). until then i have other things to be doing (like the bitcoin testing project) - I hope you can see that the solo can cope with what you want it to do.  The Edge will too, but it does not have the secure execution engine.  The edge does have ECC and will run custom code too.   afaik these boxes run posix compliant microkernels, so development is pretty simple.  There are a set of api's that you can use, if you do not want to write a completely custom solution.  See the Thales website for more info.

cheers,

steve

SHA-256 is a hash function not a signing function.  SHA-256 would be useless for outputting a signed bitcoin tx while keeping the private key(s) inaccessible.


So the devices you mention know how to take a set of internal ECC private keys and an output address provided by the host, determine the value of the keys,  verify the transaction against business rules (velocity, tx volume, time), then generate the public key from the private key, create the Bitcoin transaction and sign it, and output only the signed transaction.

Input:
a payment address
value of various addresses

Internal:
Private keys
Business rule counters

Output:
Signed bitcoin tx.

I am thinking the answer is no?


On chip signing is equally useless.  Attacker says here HSM sign this tx for 18K withdrawal.  What security did an on chip signing accomplish.  


Which would accomplish absouletely nothing since the hot wallet would by defintion allow the attacker to withdrawal funds.  Securing a cold wallet is trivially easy and doesn't require an HSM.


Not really.

Maybe you should state exactly (as in low level protocol) what the HSM would do and how you think that would provide enhanced security.  What are the inputs, what are the outputs?

Xss and csrf dont expose a site to losing an entire wallet, only one customers account.

I also don't see the point why on earth people are putting a wallet file or running a bitcoind on a hosted server. 

Instead, put the bitcoind with its wallet on a simple PC/server behind a firewall (at home/office, right where you can keep an eye on it) only letting traffic in from the server IP on a particular (non-standard) port where bitcoind listens.
Let the hosted server send its RPC's to the "off-line" bitcoind.
No easy wallet.dat to be copied if the hosted server gets cracked (that is what supposedly happened).

Instead the cracker needs to gather all the info how to contact that offline bitcoind, compile a client, upload it to the server, and only after that the cracker could send some bogus RPC's to "steal" some bitcoins.
Probably some simple countermeasures can be taken against that too: some special sequence for the RPC's or whatever (if you need to send X.Y bitcoins, sequence could be: ask block header X, send X.Y bitcoins, ask block header Y), so that an simple attempt to spend some bitcoins from the main wallet address can be easily detected (the normal server code would never make a false sequence) and that cuts off the offline bitcoind from the Internet until the problem has been investigated (fail2ban style for example).

If you put together a site in just a few days, of course if can't be much more then some copy & paste of standard blocks...

Have a second server do all the transactions. Have the server use a polling method, through TOR so it's IP address is never known. Even if you break into the site, you'd still have to figure out the comm protocol witht he off site server, and event hen you can only steal the maximum single withdraw amount, ~500 BTC sounds reasonable. I have a private server in my apartment with 6-hour UPS, and 5x redundant internet connections through 3 different providers. Certainly an exchange owner can afford the same without resorting to hacking wifis either.

Hi Death and Taxes,


in my experience no hsms work like this. (none of nciphers' nshield range or thales' hsm products act in this manner,  100% sure on that. I dont think the yubi does either. not sue. that is why I am going to order one, see what it does do, if it will do sha256 signing.)


This is exactly how all code signing hsms work, although for us rather than signing code, you sign a bitcoin transaction.

You can set all sorts of reboot security... they nearly always will reboot into standby and need an activation key. (key card or physical key)

I agree on the dubiousness of having withdraw limits, my usecase was to show how the bitcoin private key is never exposed. And the distributed control that could be achieved. I didnt really think too much about the rest of the example. Stopping someone putting invalid transactions through your box is a different problem...


I agree.

The Edge and Solo both do on chip signing, so the keys never leave the device, nor are in plaintext (both are fips level 3 certified devices.)

using and edge and a solo, the keys can be split amongst people in different parts of the world and never be on the datacentre machines. nor have one person know the whole key. (you dont have to use this functionality)

I hope this clears things up a bit.

cheers,

steve

When considering password reset services external to the system in question this could be seen as a matter of perimeter security.

Sadly, as it was the perimeter wasn't secured very well (no thanks to Rackspace to allow root by way of an email).  For a financial system this is truly scary.  I'm really surprised.

The issue with things like yubi or COTS HSM is the key will be in plaintext at some point.

Even if you use yubi or another HSM to keep keys decrypted to send funds you will need to decrypt them and then the keys can be stolen.  I don't see how any of that provides any security.  Limiting the per tx limit is also of dubious value.  Instead of thief stealing 18K, they simply transfer out 1K, 18 times.  

The only HSM which would provide any real security is one in which the private keys NEVER (under any cirmcumstances) leave the device.  The host would send a payout request to the HSM which would use a private key to construct a tx and return that to the host.  The HSM could be configured with velocity limits and require a key on startup.  Changing an admin password would require a host reboot (thus leaving HSM offline).

Any device which simply encrypts and decrypts the private keys on command provides no security.  The host has to have the ability to issue a decrypt command (or the wallet isn't hot) and if the host can then so can the attacker who has gained access to the host.

hey rjh

Yeah, that YUBI does look alright, I was just thinking it is probably easier to break into a data centre and nick the little stick than it is to break into a local bank and getting away with $100k


from their faq it is clear that this device is not the device you want to use to protect a place like an exchange.  However, if you are running your own server, it will help you not lose your bitcoins if you get rooted. so a pratical solution to the allinvain issue (although armoury[1] can have this functionality, i like harware. this yubi might allow for some more interesting use cases)

http://www.yubico.com/YubiHSM-FAQ


so physical access is still a problem. but for $500 it is a really good product.  I cannot find anything similar for anywhere near that cash.

In some good news, I was speaking to a friend about this over the weekend and he is going to lend me an edge.  Hopefully I can write something that will give people and idea of how all this works.

For a really serious deployment, you can make a bitcoin hsm with the 3 card reader control and exactly the same ACL's that existing banking infrastructure. all that for about $50k (this includes one ncipher solo, 3 edges and $10k for thales or ncipher to set it all up - although this is not a payshield, it will work in the same fashion)

I am not into regulation in the slightest, but i do not see why we cannot use the FIPS 140 standard for security, even if you do not get the cert, why not use certified kit and get someone certified to set it up?

I am going to order one of those yubi's, thanks for the link. It will be interesting to see what can be protected with it, i will write a guide for that too. (i am just waiting for a response that it supports sha256 signatures)

cheers,
steve

[1]I am amazed at the work and how quality the armoury software is.
 

Well, note that the YubiHSM is in a small USB stick format - it is designed to be installed inside any server, and then the server itself would have case opening sensors and case locks. I am not sure about the anti-tamper stuff other than that, but the device is designed to be write-only for the keys, and it does its own computations based on signals sent to it to decode. It's kind of complicated and I don't totally understand it, but I think it has a bit more going on behind the scenes then it really looks like.

As for the special smart cards - that sounds like an extremely cool technology to have, and it makes a lot of sense with that kind of design. Kind of like a missile launcher where 2 guys both have to turn their keys at the same time. It sounds like it would be expensive though.

Yes.  If the machine needs to be re-booted, a password needs to be typed in to get it to boot.  This would be inconvenient if the machine was unreliable, but would work fine if the machine was reliable.  The password could be typed remotely through a secured connection of course. 

Keep a smaller wallet online.  So the transaction volume is great?  Ok.  You can re-fill the machine by sending coins to it from a secured offline machine periodically.  Large withdrawals get delayed.  Outgoing transactions should be checked by a human 2x a day looking looking for any loss.