Bitcoin ecosystem needs robust server side HSM (Hardware Security Module) implementation guide. Let's use our collective intelligence and brainstorm here some of the existing HSM vendors (Thales, Safenet, etc) and see how (and if) they could be used to secure server-side Bitcoin wallets. I am announcing $100 Bitcoin bounty pool of "beer-money" (see the green banner above) to give it more visibility at BitExperts Home Page and encourage discussion. Everyone is welcome to share their knowledge and get some bounty coins!
User rating:
User rating:
Digital signatures used in Bitcoin transactions are based on secp256k1 elliptic curve that was almost never used before Bitcoin became popular. This may explain why (to the best of my knowledge as of March 2015) none of the existing HSMs natively support secp256k1 curve. However, some of devices do support loading and running custom apps inside HSM. Usually those apps should be written in C language and will execute in some sort of POSIX-compliant OS inside HSM. So one could load custom secp256k1 curve implementation into HSM and that would make it possible for Bitcoin Wallet keys to always stay ENCRYPTED outside HSM and only get DECRYPTED inside HSM to perform required digital signatures.
Let's further discuss the following:
Coinkite.com was one of the very first providers who used HSM to protect their server-side hosted bitcoin wallet-as-a-service. The details of their implementation are not public, but maybe I could ask Peter and Rodolfo at least if they are using one of well known vendors like Thales of Safent
On Jan 28, 2015, Bitcoin wallet provider GEM has announced that they have worked with Thales and used their CodeSafe Dev Toolkit to secure their wallet implementation. Quote from GEM's website:
If a bad guy physically tried to break the machine open and steal the cards inside these Level 3 devices, they are actually designed to self-destruct and zero-out the data
From that quote we could conclude that they have used internal PCI-X based Thales nShield Solo cards, not the network-attached nShield Connect units.
..
To be continued ...
...
SEND BITCOIN TIPS
User rating:
User rating:
Thanx for question
User rating:
Has there been any update on if Gemalto support or plan on supporting HD keys? It would be helpful to have the xpub key on servers so we know addresses to monitor and use the HSM merely for the signing process for any spends.
Hi Guys,
I work at Gemalto (SafeNet).
We've worked with a few vendors on integrating our Luna HSMs for Bitcoin and related (blockchain) functionality.
We have supported secp256k1 in our Luna HSMs since about 2007 I believe. It's a fully accelerated curve in our hardware which is not the case for some other vendors. It's supported across all form factors (USB, PCI, and networked) and with all of our APIs, PKCS#11 (c/c++ with validated wrappers for Java/JVM, .NET, Python, Ruby, and soon to be validated with Go), Java JCA/JCE and Microsoft's CNG. We also have our OpenSSL Engine which would be able to use this curve with that API. I of course won't single out any other vendors but I'm confident we have a greater breadth of API support for this curve and we provide that support over standard interfaces rather than a proprietary API which should make integration easier and allow for applications which would use the HSM or software libraries depending on threat model / use case as appropriate.
So for the general usage such as generating the keys and doing signing operations that is covered off with the standard APIs.
We do support programmability in our ProtectServer line of HSMs similar to the other programmable HSM vendors. I think the Luna HSM route is the way to go though. It has the 3 physical form factors, broad API support and cloud support if you don't want to purchase and run your own hardware. The AWS CloudHSM is Luna SA. The other thing about custom code within an HSM is that you often lose a lot of API support.
On the Luna side there is no facility to load code directly into the HSM but we do have a product Luna SP which allows for custom Java code (native code is deployable with a fat jar approach) to be placed on the appliance and that application or set of applications interface directly to the HSM and offer an externally available service. That might be applicable depending on deployment scenario.
Our implementation is FIPS 140-2 level 3 validated and unencumbered by EC patent issues which you may find with other vendors.
Best practices would be to have Private Keys generated and stored on the HSM. With Luna that key never leaves the HSM and under standard configuration cannot be exported from the HSM. It can only be securely cloned between hardware devices that share the same cloning domain.
The one limitation with using Luna is if you want to implement scalable HD (BIP32) style wallet. You won't find that particular derivation scheme in any HSM that I'm aware of. We are working on firmware enhancements to support a more advanced highly scalable wallet without the need for adding a special custom module into the HSM.
A server side wallet will have other considerations including but not limited to:
SEND BITCOIN TIPS
User rating:
User rating:
User rating:
Hi Mike, thank you for your contribution! It will be my pleasure to send some bounty coins your way once the Tipping Service is up :)
Lets try to elaborate a bit more on a wallet design based on a standard Luna HSM. I agree that for ultimate security, Bitcoin PrivKeys should be generated inside HSM and never leave an HSM unencrypted. Also, you mention that Luna HSM does not yet support HD keys i.e. unlimited deterministic key generation from the single seed is not yet available in Luna. Which kind of implies that the only design choice is to generate a large amount of Random Keys. Since this wallet design should scale to millions of users, let's assume conservative 100 keys per user during their wallet lifetime on average. So we would need to be able to manage 100 millions of key couples inside the Luna HSM. Not just manage, but to replicate every single key into another backup / standby Luna HSM module, after each key generation, or you might risk of losing those keys / coins in case of HSM failure.
This does not seem to be the best approach. The obvious improvement would be NOT to store 100 millions keys inside HSM, but have those keys stored outside of HSM in let's say SQL database, all 100 millions being encrypted with the same symmetric key like AES-256, lets call it Master Key. master Key is generated inside HSM and never leaves HSM, but it of course gets replicated into a backup / standby HSM module. So HSM would generate a new random key couple, use Master Key to encrypt the PrivKey part, and pass it outside to the host wallet application so the new keys would get stored into SQL database. Of course, transaction signing would have to be happening inside of Luna, and our Bitcoin wallet application will have to pass that proper (encrypted) PrivKey to Luna HSM. For simplicity, let's assume that Luna HSM is blindly signing without even checking any business rules before signing. So Luna HSM just signs the binary hashes prepared outside by the Bitcoin Wallet, without even knowing what these hashes are for. So the only function the Luna HSM serves is to make sure that if SQL database is stolen from the server, it cannot be used for signatures b/c it needs Luna HSM. I see a bunch of other security / coins thieft problems with this implementation, but let's stop here for now.
Do you think this design approach is possible with out-of-the-box standard Luna HSM? Or is it already too custom and would need something like ProtectServer HSM with custom code loaded and running inside of ProtectServer HSM?
Thank You! Alex
User rating:
Hi Alex,
You're right in that the lack of an ability to derive an EC key from another EC key would be a problem for an application developed today with our Luna line of HSMs.
Assuming using the HA features of the product all keys would be replicated but in this instance since you wouldn't want to store those keys the more likely approach would be to generate and wrap them off using AES keys. Either with a single master key or a master key per user or using a key management technique similar to BIP32 where you would use SP 800-108 derivation to get unique wrapping keys per user or even per key.
These operations are all possible with the HSM today but you would want to switch to a HD wallet type implementation when that's available since it would be more efficient than taking keys out of the HSM and pushing them back in again.
User rating:
User rating:
Wow, 3 years..
What's the current level of interest here? Both the Luna and Protect Server HSMs have supported BIP32 natively for a bit now and we have integrations with Ethereum / Hyperledger, but not with bitcoin core.
We don't want to do a one-off integration though, the goal would be to refactor the crypto code in bitcoin core to support pkcs#11 devices in a general way and have that adopted into the community.
i dont know about it!! if sasoawnr
SEND BITCOIN TIPS
User rating:
User rating:
**
Great Study .Alex thank you
**
SEND BITCOIN TIPS
User rating:
User rating:
FavScripts.com is a free tool to save your favorite scripts and commands, then quickly find and copy-paste your commands with just few clicks.
Boost your productivity with FavScripts.com!
QRID Login
