What can really be done about server hacking

[DeathAndTaxes]

I would not execute code on your server, I would (if you are MtGox for example) spam you with withdrawal requests.

Which the website would then reports as error to the user and never send it to the tx server.  Eventually it would shutdown your account and ask you to contact customer support.  None of those requests would ever make it to the tx server.

[1715023958]

1715023958

[1715023958]

1715023958

[1715023958]

1715023958

[Sukrim]

Even if I have 1 BTC in my account, thus not using up even 0.1% of my funds?

It might even be possible to accumulate pay-outs by the way, so people _can_ request 1000*1 Satoshi to the same address, but they would get 1*1000 Satoshis instead once the transaction gets created.

[mistfpga]

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.

year it is better than nothing, but still i would like to see something a little more robust.  It was good enough for RPOW and Hal Finney...

Check out his security model for securing his 'blockchain'

http://web.archive.org/web/20071222072154/http://rpow.net/

and that has code running on one of these (imagine how much this would cost now days, probably one or two side channel attacks though...)

http://web.archive.org/web/20071027105630/http://www-03.ibm.com/security/cryptocards/pcicc.shtml

these are the more modern ones

http://www-03.ibm.com/security/cryptocards/

So you dont have to go thales, you could go ibm... 

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.

You are right it doesnt.  and it appears (after a couple of conversations with some people) it seems that the edge is a little lite on the resources and doesnt support SSE (it does support codesafe - which runs within the boundary of the device, all fips 140-2 level 3+ have to it would seem) thus making it a bit of a pig to code for.  So the solo would be the ideal option.  they are no where near as expensive as i first thought.  only a couple of $k

add acouple of edges and you have distributed key management and the remote access security that a payshield affords.

the Edge, contains a minihsm, (like the solo)

Here is more info than you could want for the security model of the miniHSM

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp972.pdf

They do not give the details of the resources that are avaliable to a coder though - you did used to be able to get this from the ncipher site, in their dev tools.  however it seems that these are no longer avaliable to the general public.

cheers,

steve

[Aseras]

The way bitcoin is implemented right now, if you have a "hot wallet" to do transactions on, someone can hack it. Any automated way and it's hackable. Bitcoin has to be exposed to the network to send and receive coins and as such there's always an exploit to break in somehow.

If you are a miner or only receive deposits, you can create a wallet totally offline, get an address and deposit coins there and it is secure so long as it never sees the internet.

[mistfpga]

The way bitcoin is implemented right now, if you have a "hot wallet" to do transactions on, someone can hack it. Any automated way and it's hackable. Bitcoin has to be exposed to the network to send and receive coins and as such there's always an exploit to break in somehow.

This is confusing and in the context of this thread, not true.

It is not the implementation of the bitcoin protocol that has a problem, it is people not doing due dilligence in regard to the securing of private keys (bitcoin or not, it just so happens that bitcoin private keys are cash...) - bitcoin does offer some unique challenges, but nothing that is _unsecureable_ by design or something that can be fixed with protocol changes.

This thread is about _physically_ securing a hotwallet from your server being rooted (keys cannot be accessed/copied), or someone stealing the box (keys cannot be physically recovered off the chips).  this can and should be protected against.  please check out the links I have already posted, the technology to do this has been around for years (and is legally required in the banking industry - check fips 140-2)

This is only the foundation of a proper defense in depth security approach.  If the foundations are not solid then you are correct, the hotwallet is doomed. And just because you have a solid foundation it does not mitigate the need for further security measures.

Without a solid foundation when you are hacked you will lose your coins.  You cannot stop someone hacking you, what you can do is mitigate the damage they can cause.

cheers,

steve

edit: i managed to get something similar to this setup with the armory client, a serial cable and a little perl socket io.

[rjk]

edit: i managed to get something similar to this setup with the armory client, a serial cable and a little perl socket io.

Do tell! I would like some pictures and a longer description. Pretty please?

[mistfpga]

edit: i managed to get something similar to this setup with the armory client, a serial cable and a little perl socket io.

Do tell! I would like some pictures and a longer description. Pretty please?

Sure no problem,

Do you mean like a setup guide or data flow?  i more or less tried to implement what death and taxes has already posted for the poor mans hsm. I was not trying to secure anything, just prove to myself that the armory client can handle this with little extra work.

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 intend to address all the issues, but for the moment i just wanted to make sure that the concept would work before i invested any more time in it. I would like to add similar functionality to having an edge (remote card reader that has administration control of the device, but no access to keys) and the poor mans hsm.

I havent properly checked the armory documentation or even seen if it has an api. (it is open source though...) I feel it is necessary to pointout how integral the armory client is to this, without that this would be a massive task.  as it is, he has done all the hard work, and bitcoined it up. It is an amazing tool.  

if that guy ever wants to earn serious cash he should apply to the likes of ncipher or thales as a systems architecht using armory as a demo pitch, they would snap him up. I am really surprised there are not more public partnerships between him and sites. maybe that will change.

So far I have only done some minor proof of concept perl scripts and am completely relying on the integrity of the armory client.

(a quick overview of how the armory client works)

http://bitcoinarmory.com/index.php/start-page/what-is-armory/features

I knocked up a perl script using win32::guitest to drive the armory gui. (it literally clicks the buttons, i am a tester and test scripting is quicker for me...)

So the online machine has  no sensitive information on it(per armory faq), it checkes an email box, then based off that is generates an offline transaction this is then passed to a different perl script that sole purpose is to spout data over serial to a receiving script on machine B. machine b has the offline private key.  The script on machine B checks the transaction against the rules it has (at the moment that is just it is a testnet address and the amount is less than 5btc) then it signs the transaction and passes this to back to machine A, machine A checks this again against its validation rules (just sanity checks, these can be manipulated) then squirts it out over the network.

I did this in about an hour or so.

So the concept works.  and 90% of the hard work has already been done to get a quick and dirty implementation up and running.

I would like to add much more to this and do it in python so it can interact with the actual armory client rather than just driving the mouse and keyboard. If you are interested I can tidy up the code a bit and share it with you? maybe wait until I have something that functions a bit better?

tl;dr
I changed the air gap for a serial cable, and rather than me clicking on buttons i did it with a perl script.

Hope this helps.

steve

[rjk]

Ah I see, interesting way of doing it. I wonder if the offline transactions functionality is available in API form to make the proof-of-concept easier  faster.

[mistfpga]

Ah I see, interesting way of doing it. I wonder if the offline transactions functionality is available in API form to make the proof-of-concept easier  faster.

I think so, I think someone would be able to do this will little effort, maybe get the bloke who maintains the armory to see if he fancies doing it.

from the faq

Developer Tools!  Thoroughly commented Python code.  Thoroughly-commented C++ code.  Thousands of lines of unit-test code for verifying almost every sub-function of the entire library.  Simple wallet files.  And the “Developer” user mode will give developers extra tools for their own development efforts (to be expanded in the near future).

I have mainly been focusing my efforts on component searching (for mistfgpa) and getting the bitcoin testing project off the ground, so this is fighting with a couple of other things for my time, however I am getting a bit more inspired.

I will take a look at this over the weekend and see if a couple of the mistfpga boys want to help.

I will probably start another thread, but I think I have a reasonaoble way of solving a lot of the business rule issues.  create a hash of rules that are in use on server A (this has to be done before it ever goes online.  store this hash in the hsm, then pass the business rules across with the transaction, check them by hashing, if they are different, computer B shreds keys and blue screens kernel panics. thus encrypting the drive.

edit: although I would like to run this on a RTOS, like QNX (ignore the RIM purchase, QNX is nearly military spec posix.)

The thing that would make this a lot quicker would be if i could code properly in c/++ or even python, perl and x86 assembler are my day job bread and butter...

just out of curiosty, are you intersted in this for academic reasons or do you want to use a system like this at home?

cheers,

steve

[rjk]

Just purely for my own interest. Thanks for sharing.

[etotheipi]

This is most interesting!  

I actually purchased a couple USB-to-serial cables and a null-modem converter and had started to play around with this myself.  I got as far as determining that it would work, for $25 in cables, and when I get done with some other crazy priorities, I plan to develop and integrate a serial-port interface into the GUI for the hardcore users.  It's a promising idea for filling in the "optimal" usability-security curve...

Unfortunately, Armory code is extremely well-commented, but there's not a lot of top-level documentation for using it.  Again with the priorities...most users are using Armory instead of developing with it, so I haven't spent much time on the developer documentation.   However, there is a lot of example code in the extras/sample_armory_code.py file, which shows a whole bunch of different ways to access the armoryengine tools from python.  Loading & querying the blockchain, reading wallets, scanning for balances, iterating over all blocks/txs/txins/txouts.  It needs to be cleaned up a bit, but obviously it is usable since Armory is built with it.

And, I'm always willing to help other developers dig in.  Please PM or email me if you have any questions about leveraging specific functionality with the library.  I would be pleased if someone else was able to expand the functionality like this while I work on some of the more critical stuff (like making sure Armory still works at all, after the blockchain exceeds 2 GB...)

[mistfpga]

This is most interesting! 

Unfortunately, Armory code is extremely well-commented, but there's not a lot of top-level documentation for using it.  Again with the priorities...most users are using Armory instead of developing with it, so I haven't spent much time on the developer documentation.   However, there is a lot of example code in the extras/sample_armory_code.py file, which shows a whole bunch of different ways to access the armoryengine tools from python.  Loading & querying the blockchain, reading wallets, scanning for balances, iterating over all blocks/txs/txins/txouts.  It needs to be cleaned up a bit, but obviously it is usable since Armory is built with it.

Nice, thank you for taking the time to respond.

I am up for this, i guess it is time to get over python forcing me to indent...

I will take a look early next week and send you a mail or two.

Just out of interest is your username "e to the i pi"?

I keep reading it as ethiopia

cheers,

steve

[REF]

This is most interesting! 

Unfortunately, Armory code is extremely well-commented, but there's not a lot of top-level documentation for using it.  Again with the priorities...most users are using Armory instead of developing with it, so I haven't spent much time on the developer documentation.   However, there is a lot of example code in the extras/sample_armory_code.py file, which shows a whole bunch of different ways to access the armoryengine tools from python.  Loading & querying the blockchain, reading wallets, scanning for balances, iterating over all blocks/txs/txins/txouts.  It needs to be cleaned up a bit, but obviously it is usable since Armory is built with it.

Nice, thank you for taking the time to respond.

I am up for this, i guess it is time to get over python forcing me to indent...

I will take a look early next week and send you a mail or two.

Just out of interest is your username "e to the i pi"?

I keep reading it as ethiopia

cheers,

steve

me to but now that you say "e to the i pi" and I look at his avatar that's what it has to be. Now it makes sense.