Bitcoin Forum

Hi all,

It seems now after another major crack we are again in the same position.  I have started this thread to offer some reasonable way of being able to operate with proper server security. And therefore potentially be able to get insurance from _normal_ insurance companies.

For a long time the traditional banks have faced this situation.  The only full solutions for banks is the Hardware Securty Module 8000 from thales or the paysheild 9000 from ncipher (now owned by thales)

These devices will secure the secret keys and sign credit card transactions.  most of the worlds interbanking relies on these devices.

I have worked with both HSM's and PayShields before.  They would not translate in their current format to any non banking transactions. So Thales and nCipher created this at a fraction of the cost, but still with all the goodness that is needed for a tamper proof bitcoin signing box. (it will purge the key if needs be)

http://www.thales-esecurity.com/Products/Hardware%20Security%20Modules/nShield%20Edge.aspx

the nCipher EDGE.

I urge all major bitcoin handlers to seriously consider contacting Thales or nCipher for a demo.

I do not work for Thales or nCipher.  I just know their products very well and this _will_ help the community.  my email address is in my profile if anyone wishes to discuss this further.

(why dont companies purge the keys when the alarms go off? restoring a key from a paper back up is a lot cheaper...)

regards,

steve

How about this? http://www.yubico.com/YubiHSM
I don't know the details of how fast it can go or anything like that, but it is intended to be a secure store of secrets.

Steve,

Thanks for starting this thread.  I think except for those who have BTC tied up in the downed servers the best that can come of this latest incident if for the community to  share their best practices while we come to understand what the root cause of Bitcoinica's issue so others can prevent similar incidents in the future.  I hope others will see fit to post insightful info for the benefit of the community.

Thanks.

Would TPM have stopped this?

Not sure.  Sounds like an email account was accessed which was used to reset the server password.  Seems like "they" had root access.

Preventing access to the Bitcoin keys should the root password be reset is pretty simple, really.

Encrypt the drive with the keys on it.  If it is mounted, it is accessible.  But as long as the hacker does not have the root password, and has to reset the root password to gain access to it, the drive will unmount, and be inaccessible even with the root password reset.  They would have to know the encryption password for the drive itself to gain access.

So are you saying the server has to reboot to change the root password and the encrypted disk would not be automatically remounted on reboot?   I use keys on all my server so I'm not familiar with this.

Well, it might be possible to configure it so that it auto-remounted on reboot, but that would require the boot password to be stored on the machine, which would defeat the purpose of an encrypted disk.

Pretty simple stuff:

1) Use your own hardware in a colo-cage.
2) No external password reset.  Period.
3) Remote access only via a dedicated NIC
4) Hardware firewall/VPN which handles IP whitelisting
5) Two factor authentication for all server logins.

TL/DR version:
How about don't let the hacker reset your password and login to your server?

+1.  Anybody attempting to host a currency exchange where their machines aren't in a locked cabinet/cage that only they have the key to is only fooling themselves if they think they're being professional.

DeathandTaxes I don't think you can get any more secure then this but I think more then a few of the cloud services could be made just as secure with out owning all the hardware.

Yes, there are ways which could prevent your cloud/VPS provider from resetting your password and accessing your stuff.  That's not the point though.  A currency exchange should never be in the situation where an external party could have unauthorized access to your servers [which will ALWAYS be the case for VPS/cloud].  An external party shouldn't even have physical access to their servers.  Sure, there's always the chance of a physical break-in, thats why you still have strong security on the server.

Hosting a site like that on hardware you don't own and have control over in terms of physical access is just asking for trouble.

hi,

@rjh
That looks alright, but it doesnt say what antitamper it has, it looks like someone with physical access to the machine could just take the key out, then probe it for the secret key
I would be a little hessitant about running a multimillon dollar business on a $500 key. (it mentions sha but not sha256...)

The Edge usecase is a bit more relevant, when in remote operation mode (via ssh/tls/cert based) it takes a physical device (smart card) inserted at the remote management location to sign something.
so you could have 4 cards, a,b,c and d.  card a inserted allows signing of transactions upto $1000.  if card b is inserted then you can process transactions of $1000 - $5000. for any transactions over $5000 you need cards c and d.

you can have multiple copies of each card with thier own unique encryption code and with their own revocation certificates.

you would always have key a in until you need to process large transactions, then once an hour put card b in once all transactions are verified and clear transactions that are $1000-$5000, then twice a day, you and someone else have to insert keys c and d to process the really large transactions.

on top of this, if anyone tries to mess with the device it will purge all the keys off the device, to a standard you could not get them back by probing or skimming the chips. but not the cards. (which are on the other side of the world anyway) you can then use the cards and the master cards to reprogram the device remotely.

This kind of functionality has been around and avaliable to the public for at least 4 or 5 years. I guess that the Edge costs around $7000 based of the pricing of thales' other products.

physical access does you no good at all.

@check_status maybe, maybe not.  there is no out of the box solution for this that i know of that uses tpm.  the thales technology is proven.

@sgtspike - in that one circumstance that would protect the system.  however it does not help if there is a priv elevation.  Also what happens if the box falls over? someone in the datacentre or nearby must have the keys.

if you are processing $50k a month in profit how can you not spend $7k on one very good layer of defense (shit a paysheild is only around $50k anyway...), then add more layers (i am not suggesting have only one layer of defense) the everyone already knows the drill for that (death and taxes just posted a good list - the edge will do all that too...). but people dont do it, that really amazes me. if you are lazy buy an edge!

 - if someone wants to buy me one, I will write a guide. :)

EDIT: from the ncipher website the device "Delivers FIPS compliance" That is the bit that should allow you to be underwritten and insured as a standard finacial institiution. (although i am not in anyway a lawyer at all. I do know you wont get any insurance without it)

EDIT2: they are at least security level 3 in fips... i think payshields are 4 iirc but dont quote me on either :)

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. 

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. ;D It sounds like it would be expensive though.

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.
 

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.

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.

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

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.

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...

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

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?

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

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.

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).

* 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?

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

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.

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

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.

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.

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.

SgtSpike,

ah OK, yes, now it is clear.

Thanks.

spiccioli

Business rules.

The serial port wouldn't connect to the bitcoind directly.  Instead its access would be limited to only a process/service/daemon which validates tx requests (not commands) against business rules.  

Just brainstorming here but as an example imagine the tx server had these rules:
1) Max Tx value is 1000 BTC (or whatever limit is useful for 90% of users).
2) TX value > 100 BTC results in 60 minute delay before return the signed tx.
3) TX value > 300 BTC reults in 180 minutes delay before returning the signed tx.
4) Certain conditions which indicate either a probable attack or software malfunction trigger an automatic lockdown.**
5) If total tx value in last 15 minutes exceeds preset limit delay all tx an additional 30 minutes (even those under 100 BTC) and notify admins.
5) TX volume 50% higher than 7 day peak causes a security hold. *
6) TX value 50% higher than 7 day peak cause a security hold. *
7) TX velocity increases by more than preset limit causes a security hold. *


Web front end -> API via serial port -> tx processors -> wallet.

* Security hold:
On a security hold the server remains online and queues up tx requests but stops returning signed txs.  Admin are notified and the server remains halted until it receives a security key (which isn't stored on front end server).  This would be useful to put a "man in the loop" when volume is high.  

 It is possible this is just a valid but unusual event.  Admin can check the tx logs, access logs, and if everything checks out provide the security key to resume operation.   Grocery stores use a system like this.  Ever seen a cashier mess up and she needs the manager key?  Same concept.  It limits the potential for fraud based on business rules of unusual behavior.

** Lockdown:
In a lockdown (possible intrusion) the server powers off.  Resuming tx processing requires powering on the server, providing the startup key, and optionally waiting for a preset delay.  All admins are notified of the lockdown and the front end server is halted also.   "Red alert.  Shields up".  

For more security the box could be designed to allow a security hold or lockdown command to be issued from any internet connected computer.  The command would need to be digitally signed to prevent abuse but this would provide a "manual override".  Zhou noticed the admin reset and the "weird" tx within minutes.   Even if the tx server hadn't realized it was fraudulent if it was still in the delayed signing queue Zhou could have forced the server into lockdown and saved six figures.

The rules could start out simple and get more complex as the business evolves.  The goal is to prevent direct access to the keys or funds by limiting unusual activity even when someone has "access".  Does anyone think in a traditional bank if a teller uses their terminal to make a "valid" $100,000,000 cash withdrawal the bank's vault automatically swings opens and bags of money roll out?  Meanwhile security guards and bank managers stand by helpless as thieves fill a dumptruck with cash because "she had the right code". :)

D&T seems to know a little something here.

I would have a team write a withdrawal.log file that is read from another server somewhere that reads the withdrawal requests, verifies against the preknown accounts (hashed of course), and executes the outgoing to the network from a completely different location. This Floating 'float' account can be moved at intervals to provide another level of security.

OFC, this doesn't prevent messing with the positions of people in the code but it would help to not lose $300K.

D&T has already pointed out in another thread in a strongly worded opinion things that should have been learned. I would have thought $300K would have taught somethings if at least another degree.

D&T,

very clear, thank you.

spiccioli.

So just by writing a program that requests 1000 withdrawals of 1 Satoshi (which would very likely look like a malfunction or an attack) one could bring down the site potentially for hours? Nice! ::)

I would still go with my initial idea:
Pay-ins are credited as soon as they are confirmed
Pay-outs are processed every x hours en block (saves on Tx-fees, keeps wallet offline etc.etc.)

Instant payouts will always be a security risk and unless you have a site that pays out less than a handful of BTC every day anyways, you really should just use an offline wallet, collect transactions and manually create a sendmany every once in a while on an offline PC.

The tx server only accepts inputs from serial port hardwired to the web server.

If the attacker has admin access to the frontend webserver and is executing arbitrary code then the site likely SHOULD be locked down don't you think? :)

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.

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.

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... 


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

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.

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.

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.


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

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

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

Just purely for my own interest. Thanks for sharing.

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...)

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.