The QR codes with encrypted privkeys can even be transferred via open channels, provided that the value on the address corresponding to the privkey is not too large.
Like, top manager have some qr codes in his wallet, and if the need arise, just snap a picture of one, and send to an employee via message app. Employee shows qr code on his phone to the camera, and it entered into the system.
Only signer node can decrypt the privkey, so there's little risk in sending it via open channel.
If someone steals encryption key used by the signer node, he can steal the amount of the top-up, but will reveal himself that way.
Or someone might steal a wallet from top manager to get his hands on more qr codes, but it is much more complex to perform - you need to both to get encryption key used by signer node, and target the top manager. You can also add another level of encryption, so that after the qr code is received from top manager, it needs to be decrypted with the key stored in the office, before it can reach the signer node. But this may be an overkill.
Topic: Idea: instant hot wallet top-up with encrypted paper wallets (Read 210 times)
The signer node enforces money flow limits, and can be protected much better than the main system, because it does not require a lot of resources, and can be in a different location, but if someone takes over this node, and also the main system (if attacker does not control main system, an alerts will be sent out if it detects that funds were spent outside the system), and starts to siphon funds out, than yes - lower-level employess might be duped into thinking that it is OK to add another 1btc into hot wallet for now.
This can be mitigated with multisig - when you have more than one independent signer nodes in different locations (maybe even on different OS and hardware), that all enforce the same limits, and attacker needs to take over them all, to circumvent the limits. To use the paper wallet top-up with multisig you'll need several employees to scan several keys of one address to increase spendable balance.
Or this can be solved with administrative methods - like, employees need to report to the management that they just added X btc to hot wallet, and this way the management can monitor the usage and intervene if it feels not right.
Or both - multisig and administrative.
This can be mitigated with multisig - when you have more than one independent signer nodes in different locations (maybe even on different OS and hardware), that all enforce the same limits, and attacker needs to take over them all, to circumvent the limits. To use the paper wallet top-up with multisig you'll need several employees to scan several keys of one address to increase spendable balance.
Or this can be solved with administrative methods - like, employees need to report to the management that they just added X btc to hot wallet, and this way the management can monitor the usage and intervene if it feels not right.
Or both - multisig and administrative.
Signer node is a part of the system of hot wallet (or you can say 'warm' wallet - because it can do money flow limiting, like network traffic shaping, but for money).
Signer node is not a cold wallet - it cannot be, because it have to actually connect to the internet, at least periodically, to be able to download transaction proposals and upload signatures. For busy hot wallets you probably want it to connect to the main system once a minute.
For cold wallet, you download transaction proposals yourself, put them onto SD card, sign on offline system, and upload signatures to the main system manually (with a script)
If signer node goes down, you cannot use hot wallet, until you bring it back up. You can have several signer nodes for one key on stand-by, or in multisig setup - but that means you have more hosts to secure and protect.
That's what money flow limits are for - you set how fast the funds can outflow, and the maximum amount of money that can be sent out before manual intervention is needed . Even if the funds are available, the signer won't sign the transactions until money cap is increased (scan QR code with the command 'allow withdrawal of another 10 btc' - and this QR code is in big boss's safe - she can give it out only if convinced that the limit exhaustion is not suspicious)
Signer node is not a cold wallet - it cannot be, because it have to actually connect to the internet, at least periodically, to be able to download transaction proposals and upload signatures. For busy hot wallets you probably want it to connect to the main system once a minute.
For cold wallet, you download transaction proposals yourself, put them onto SD card, sign on offline system, and upload signatures to the main system manually (with a script)
If signer node goes down, you cannot use hot wallet, until you bring it back up. You can have several signer nodes for one key on stand-by, or in multisig setup - but that means you have more hosts to secure and protect.
Quote
they kept loading funds into the hot wallet that had been hacked.
That's what money flow limits are for - you set how fast the funds can outflow, and the maximum amount of money that can be sent out before manual intervention is needed . Even if the funds are available, the signer won't sign the transactions until money cap is increased (scan QR code with the command 'allow withdrawal of another 10 btc' - and this QR code is in big boss's safe - she can give it out only if convinced that the limit exhaustion is not suspicious)
The problem with this system is that if the signing node goes down you will lose your entire cold wallet. The cold wallets are not self contained. The decryption keys hosted by the signing node are required to spend from them. So you have to be careful to backup those keys as well. You have to make sure the signing node stays up. If it goes down you won't be able to transfer money from the cold wallet to the hot wallet until you get it up and running again.
Also this doesn't help you if the problem is with the hot wallet. If your hot wallet has been hacked then you want higher level employees/management to provide oversight of transfers from the cold wallet. The idea is that they might notice a leaky hot wallet while lower level employees might not. We've seen this problem in the past with Mt. Gox and bitfinex where they kept loading funds into the hot wallet that had been hacked.
Also this doesn't help you if the problem is with the hot wallet. If your hot wallet has been hacked then you want higher level employees/management to provide oversight of transfers from the cold wallet. The idea is that they might notice a leaky hot wallet while lower level employees might not. We've seen this problem in the past with Mt. Gox and bitfinex where they kept loading funds into the hot wallet that had been hacked.
Quote
i doubt they do something that complex based on past exchange hacks.
I try to create a scheme that will be as low-tech as possible, from the user's perspective.
Working with confidential paper documents have much longer history than working with digital documents, and the 'safe' and 'confidential paper' is the concepts that is understood by much larger pool of people, than the concept of signing requests with PGP.
For employees, in my view, the scheme should be very simple - "I take these envelope and show it to the camera. I do not give this envelope to anyone, because it bears a lot of value, and this is from my individual safe (we can have individual encryption keys per employee), so they will know that it is me who added this value to hot wallet"
That depends on each exchange's decision, but IMO i doubt they do something that complex based on past exchange hacks. Besides, we will never know since by reveal how they manage their coins, their security would be weaken significantly.
For sure, combination between multi-signature address as cold wallet and hardened address from multiple xpub/master public key as hot wallet is the minimum that every exchange use.
About your idea, i think every employer should have their own PGP signature or bitcoin address (to encrypt the message and as identity verification). When someone need access to cold storage, the steps would be :
1. The employer sign message of the access request with unsigned transaction to higher management.
2. If higher management approve it, they would send encrypted message with authorized person's PGP signature which contain unsigned transaction.
3. The authorized person sign the transaction and send it back to the employee/higher management.
IMO it's more flexible and you could add more authorized person if you use multi-signature address.
Edit : now i get your idea, but i prefer my own idea and IMO it's easier to documentation since the transaction/flow is on blockchain.
For sure, combination between multi-signature address as cold wallet and hardened address from multiple xpub/master public key as hot wallet is the minimum that every exchange use.
About your idea, i think every employer should have their own PGP signature or bitcoin address (to encrypt the message and as identity verification). When someone need access to cold storage, the steps would be :
1. The employer sign message of the access request with unsigned transaction to higher management.
2. If higher management approve it, they would send encrypted message with authorized person's PGP signature which contain unsigned transaction.
3. The authorized person sign the transaction and send it back to the employee/higher management.
IMO it's more flexible and you could add more authorized person if you use multi-signature address.
Edit : now i get your idea, but i prefer my own idea and IMO it's easier to documentation since the transaction/flow is on blockchain.
Quote
When someone need access to cold storage, the steps would be
The idea is to not access the cold storage at all - in a sense that when you need to top-up hot wallet, you do not create a transaction, do not sign it and do not send it.
The transaction is already in blockchain and is already confirmed, and as this can be done long before the top-up, the fees for this transaction can be minimal.
Everything is already in the system - the addresses and UTXOs are already known.
The wallet shows full balance (let's say, 123 btc), and spendable balance (for example, 0.3 btc).
We add one key, so hot wallet will be able to spend from one additional UTXO (value 1 btc)
The wallet shows full balance (123 btc) and spendable balance (1.3 btc)
We increased spendable balance without sending any transaction (it was sent long ago)
And we do not have to wait for funding transaction confirmation, or send 0-conf coins out.
Let's say an exchange got a hot wallet, and if there's more withdrawals than deposits, after some time it will need to move some funds from their cold wallet to hot wallet, to satisfy withdrawal requests.
Moving funds from cold wallet might require actions from high management, and will be visible in blockchain.
The idea to speed this up and allow less senior personnel to perform the top-up:
Generate 100 new addresses, encrypt their privkeys with symmetric key, print encrypted privkey (along with other metadata about the address) on paper as QR codes, put them into envelopes, and put envelopes into safe. Send 1 btc to each address. (edit: and of course you do not reuse these addresses! 1 address = 1 UTXO)
When there's a need to top-up hot wallet, three employees go to the safe, open it (while the procedure is recorded on video), take one envelope, put a log entry into paper journal, sign that journal entry with their manual signatures, and then open the envelope and scan qr code into payment system.
As the privkey is encrypted, and the decryption key is only present on separate signer node (that may be anywhere in the world and even connect to the main system via TOR), employees or anyone who sees that QR code cannot steal the funds.
There's no blockchain transaction at the time of top-up, and higher management is not needed to perform it, because there is much less trust involved, and with paper journal and video, the level of collusion between employees needs to be much higher for them to steal.
If someone takes over the signer node, he cannot steal the keys that are not yet scanned into the system.
(currently we can do similar setup, but with money flow limiter settings - for example, an employee can increase money flow limit from 0.3 btc/minute to 1 btc/minute by scanning a QR code with the command for the signer, but if anyone finds and takes over that signer node, and this is not a multisig setup - its game over)
We can try to use asymmetric encryption to encrypt private keys for addresses, and then the key to decrypt them need not be known at the time when QR codes are created, but using asymmetric encryption will mean that the data size will be much larger (256 bytes for RSA 2048) and the QR code needs to be larger. Private keys for addresses are much more valuable data, and we are working with them directly when we are encrypting them anyway, so I think symmetric encryption will suffice here.
I think we are going to implement support for this scheme in the near future, and I wanted to bounce my idea against a collective mind before diving into coding.
Is there anything that can be done to make this scheme more secure or more convenient ?
Do the exchanges already use similar schemes ? What challenges they face with these schemes ?
Is it too involved and complex ?
Moving funds from cold wallet might require actions from high management, and will be visible in blockchain.
The idea to speed this up and allow less senior personnel to perform the top-up:
Generate 100 new addresses, encrypt their privkeys with symmetric key, print encrypted privkey (along with other metadata about the address) on paper as QR codes, put them into envelopes, and put envelopes into safe. Send 1 btc to each address. (edit: and of course you do not reuse these addresses! 1 address = 1 UTXO)
When there's a need to top-up hot wallet, three employees go to the safe, open it (while the procedure is recorded on video), take one envelope, put a log entry into paper journal, sign that journal entry with their manual signatures, and then open the envelope and scan qr code into payment system.
As the privkey is encrypted, and the decryption key is only present on separate signer node (that may be anywhere in the world and even connect to the main system via TOR), employees or anyone who sees that QR code cannot steal the funds.
There's no blockchain transaction at the time of top-up, and higher management is not needed to perform it, because there is much less trust involved, and with paper journal and video, the level of collusion between employees needs to be much higher for them to steal.
If someone takes over the signer node, he cannot steal the keys that are not yet scanned into the system.
(currently we can do similar setup, but with money flow limiter settings - for example, an employee can increase money flow limit from 0.3 btc/minute to 1 btc/minute by scanning a QR code with the command for the signer, but if anyone finds and takes over that signer node, and this is not a multisig setup - its game over)
We can try to use asymmetric encryption to encrypt private keys for addresses, and then the key to decrypt them need not be known at the time when QR codes are created, but using asymmetric encryption will mean that the data size will be much larger (256 bytes for RSA 2048) and the QR code needs to be larger. Private keys for addresses are much more valuable data, and we are working with them directly when we are encrypting them anyway, so I think symmetric encryption will suffice here.
I think we are going to implement support for this scheme in the near future, and I wanted to bounce my idea against a collective mind before diving into coding.
Is there anything that can be done to make this scheme more secure or more convenient ?
Do the exchanges already use similar schemes ? What challenges they face with these schemes ?
Is it too involved and complex ?
Jump to: