Bitcoin HSM implementation guide for securing a server-side hosted wallet

$100
=
$10
+
$90
$100 Bitcoin bounty has been announced by author.
$10 has been already awarded by author.
$90 remains available.
1

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!

Good question

sfdf

4 answers - total earned - 26.6 mBTC ($11.35 USD)

4
=
3
=
$11.35
3 tips with total amount of 26.6 mBTC($11.35 USD) have been sent by Anonimous, alex

Introduction

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:

  • architecture of HSM-secured Bitcoin Wallet
  • approach of integrating HSM support into Bitcoin Core wallet Open Source project
  • how and where wallet keys are stored (inside or outside of HSM)
  • communication protocol between main wallet app and custom applet running inside HSM module
  • design specs for custom applet running inside HSM module
  • implementing such applet using Thales nShield HSM (hardware) and CodeSafe Developer Toolkit (software)
  • implementing such applet using Safenet ProtectServer HSM (hardware) and The Customization Software Development Kit (ProtectProcessing) (software) which enables development, download, and storage of custom-specific functionality modules (FMs) inside the secure boundary of HSM.

Known HSM Bitcoin wallets implementations

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

Thanx for question

1

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.

On secp256k1

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.

Loaded code vs. Standard Feature

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.

Certifications

Our implementation is FIPS 140-2 level 3 validated and unencumbered by EC patent issues which you may find with other vendors.

Key Generation/Storage

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.

Limitations

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.

Other Considerations

A server side wallet will have other considerations including but not limited to:

  1. How to handle multi-tenancy / isolation of keys (access control vs. cryptographic isolation in HSM, etc.)
  2. How to handle auditing: validate the keys are only used when the owner requested the usage
SEND BITCOIN TIPS

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

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.

Mike, it is my pleasure to send you some bounty coins - your contribution and knowledge is much appreciated!

0

i dont know about it!! if sasoawnr

SEND BITCOIN TIPS
0

**

Great Study .Alex thank you

**

SEND BITCOIN TIPS

Thank you Omar. To be honest, this question is still far from being completed.

0

Post Answer


Will Bitcoin Tipping become a new Internet Culture?


Please share our story! THANK YOU!