Everything you need to know about Bitcoin cold storage


Imagine opening your Bitcoin wallet. To your surprise, it's empty and there's no way to recover the money you lost. How do you feel?

Every Bitcoin user faces the problem of securely storing their money. Unlike the banking system, there's little recourse when things go wrong, and little margin for error. Thefts and losses can be prevented, but they can't be rolled back. Preventing these losses is the goal of cold storage.

Cold storage is an important subject with a steep learning curve. To make the topic more approachable, this article introduces core Bitcoin concepts when needed. It concludes by discussing a new Bitcoin feature that could simplify the safe storage of funds.

When to use cold storage

Like any powerful tool, cold storage can cause damage if misused. Consider using cold storage only if all of these apply:

  • You need to store significant sums of bitcoin securely.
  • You need infrequent, but secure access to the funds.
  • You trust yourself with the security of your funds more than you trust a third party.

Beginners should pay close attention to the risk of accidentally losing funds through simple cold storage mistakes. Consider practicing with pocket change before using cold storage for meaningful amounts of bitcoin.

Keys to the kingdom

Although we sometimes speak of a person "owning" bitcoin, this is misleading. A more accurate way to think about the relationship might be to imagine a tamper-proof vault designed to hold paper bills.

The vault dispenses the cash it holds to anyone who can prove they know a unique number called the private key. The legal and moral rights of the person attempting to gain access to the funds in the vault are irrelevant. The vault accepts an unlimited number of access attempts by anyone.

Although you might be tempted to try guessing the vault's private key, doing so is useless. The range of possible numbers is virtually infinite. You could make millions of guesses per second for millions of years without success.

Bitcoin stores funds in the electronic equivalent of this imaginary vault called an address. As with the vault, funds at an address may be unlocked by anyone knowing the unique private key.

Despite its apparent complexity, Bitcoin security boils down to one simple rule: keep secret the private keys for all addresses at which you store funds. A close corollary to this rule would be: maintain secure backups of all private keys.

Data is money

To a thief on a network, Bitcoin private keys represent more than just data - they're money. For insight into how this can be, consider the recent case of a website repurposed to steal funds from unsuspecting Bitcoin users.

Listen to Bitcoin was a popular service for the real-time monitoring of transactions on the Bitcoin network. Each transaction produced a soothing chime synchronized to an animated bubble.

The creator of the site eventually sold it. Shortly after the sale, problems began to surface. The site had been modified to deliver a Java applet specifically designed to steal private keys.

Numerous such exploits have been reported, with many victims along the way. The ease, speed, and anonymity with which many of these attacks can be carried out should give pause to anyone holding large sums of Bitcoins in a vulnerable wallet.

How private keys work

Our imaginary vault didn't require the private key itself to gain access. Instead, it required the user to prove knowledge of the private key. Asking directly for the private key would permit any eavesdropper to discover it. Likewise, spending funds from a Bitcoin address requires proof of knowledge of the private key - not the key itself.

To understand how this works, imagine Alice wants to pay Bob 10 BTC. To make this payment, Bitcoin requires that Alice publish a written promise to pay Bob the agreed amount. This promise is called a transaction. Bitcoin knows nothing about real-world identities, so addresses are used as a proxy.


Alice pays Bob: Transaction from Alice to Bob for 10 BTC. The transaction posted to the network substitutes real-world identities with addresses controlled by Alice and Bob, respectively.

If this were the end of the story, it would be very easy to steal from Alice by forging transactions from her address. Bitcoin prevents this kind of theft by requiring that each transaction bear an unforgeable digital signature.

Alice's wallet software adds a digital signature by processing the transaction together with the private key to her address. Changing the transaction in any way also changes the signature. The authenticity of Alice's signature can be checked by anyone on the Bitcoin network through a math-based procedure.


Alice to Bob transaction: Two transactions from Alice to Bob. The first transfers 10 BTC, and the second transfers 2 BTC. The same private key gives a unique, unguessable signature for each transaction.

By signing the transaction, Alice proves knowledge of her private key and authorizes the transfer of funds. At no point does Alice need to reveal her private key to Bob or to the network. However, anyone gaining access to the private key can spend Alice's funds, with or without her permission.

Hot wallets and cold storage

To make payments, a Bitcoin wallet needs to perform four basic tasks:

  1. Generate and store one or more private keys.
  2. Create valid transactions.
  3. Digitally sign transactions using private keys.
  4. Broadcast signed transactions to the network.

The need to do all four tasks creates a security dilemma: private keys kept on a network-connected device are vulnerable to theft via network-based attacks, but a network is needed to broadcast transactions.

A hot wallet combines all functions into a single system, typically running on a single computer. Many hot wallets encrypt private keys to deter their use if stolen, but the threat remains. For example, keyloggers, clipboard loggers, and screen capturers can transmit decrypted keys used during manual operations. What a hot wallet may lack in security, it makes up for in convenience. Managing funds and sending payments can be accomplished from a single device.


Hot wallet: An unsigned transaction is digitally signed with one of possibly several private keys. The signed transaction is then broadcasted to the network. A network-based attacker gaining access to decrypted keys can steal funds.

Cold storage resolves the network security dilemma through quarantine. A specially-created offline environment hosts all operations that either create or use private keys. Private keys remain secure from network-based attacks through strict isolation of the offline environment from the network.


Cold storage: A transactions is signed on an offline device and returned to an online device, from which it is broadcast. A network-based attacker can't steal private keys.

The process starts by generating an unsigned transaction on an online device. The transaction is then moved via USB or other connection to an offline environment, where it is signed. The signed transaction is then moved back to the online environment, from which it is broadcast to the network. At no point does the private key contact a system connected to the network.

Both hot wallets and cold storage can be used together, just as a saving accounts and purse are often used by the same person. Cold storage funds are held securely, but are hard to access. Hot wallet funds are kept ready to spend at a moment's notice, but are stored less securely.

Cold storage in practice often represents a balance between security and convenience. The more securely we try to store funds, the more difficult and error-prone it becomes to manage them.

Hardware

An offline environment plays a key role in most cold storage schemes. Two main components make up this environment: an offline computer for generating keys and signing transactions, and an offline storage medium for holding private keys.

Offline computers can be configured with a range of security features, depending on budget, the value of funds being stored, and perceived threat.

At one extreme, a computer currently in service can be taken offline by temporarily disconnecting the network card or cable. Although easily implemented, this approach offers little protection against attacks that are tolerant to intermittent network connectivity.

A dedicated offline computer with a permanently-disabled network connection offers a more robust alternative. These system are sometimes called air-gapped computers. They're often equipped with secure operating systems such as Linux. Many use strongly-encrypted hard drives.

In the absence of a dedicated offline computer, a secure operating system can be booted from removable media such as CD's and USB drives. Many Linux distributions, including Ubuntu, support this option.

Private keys may either be stored directly on an offline computer or stored separately. A variety of external media can be used, including paper, plastic cards, hard drives, removable USB drives, and even the human brain. Even if private keys are stored on the hard drive of an offline computer directly, these other media are often used to store backups.

Cold storage in practice

Cold storage methods can be divided into two broad categories based on how private keys are maintained. With a manual keystore, the user maintains a collection of private keys directly. With a software keystore, private key maintenance is under the full control of software.

Manual keystore

If flexibility and software minimalism are your goals, consider using manual cold storage. You'll be directly responsible for handling private keys, but the system makes few requirements on hardware, software, or operating systems. Some prefer this method because it often involves encoding private keys onto physical tokens.

A manual keystore can be implemented through the following steps:

  1. Using an offline device, generate one address or private key pair for each cold storage address you plan to use. Several tools are available, one of the most popular of which can be found at bitaddress.org.
  2. Transfer a copy of each cold storage address or private key to your offline medium of choice such as paper, plastic, or USB drive. This is the keystore.
  3. Transfer funds from a hot wallet or exchange into each of the active cold storage addresses.
  4. To spend funds, transfer the appropriate private key into a hot wallet to sign a transaction.

Step #4 poses the biggest challenge under a manual keystore system because wallets vary in how they handle external private keys and change addresses. Some wallets don't accept external private keys at all. Before committing to manual cold storage, learn how your wallet works with external private keys.


Spending with a manual keystore: The private key must be transferred to the hot wallet, via a USB drive or QR code, and at least temporarily held. While being held, the key may be vulnerable to network-based theft.

Notice that spending funds from cold storage requires the transfer of a private key into a hot wallet. Unfortunately, this risks unintended transmission of the key to a network-based attacker. Holding the key in memory only, or sending change to a newly-created cold storage change address are both possible workarounds. However, neither approach completely eliminates the threat.

Backup media are often selected to be complementary to the primary keystore medium. For example, if paper wallets are kept in a secure on-site location, a backup printed on plastic might be kept in a safety deposit box.

Software keystore

If the thought of maintaining private keys yourself leaves you uneasy, consider a wallet that handles the job for you. Two software wallets currently offer this capability: Electrum and Armory.

Software keystores employ two devices, an online computer and a single-use offline computer. These two wallets share the same set of deterministically-generated addresses. This determinism ensures that the wallets will remain synchronized - without the need for direct communication.


Software keystore: New addresses are generated from a deterministic algorithm, enabling both an online and offline wallet to share the same addresses without direct communication. Only the offline wallet generates private keys.

Funds are moved from cold storage via a multi-step procedure. The online wallet first prepares an unsigned transaction. Next, the transaction is signed by the offline computer. Finally, the signed transaction is broadcast to the network by the online computer. A physical medium such as a USB stick shuttles the transaction between computers, however more secure methods such as QR codes could be used in principle.


Spending from a software keystore: Each wallet maintains the same set of deterministically-generated addresses. A transaction is created on the online wallet, signed with the offline wallet, and returned to the online wallet from which it is broadcasted. The private key used for signing is never revealed to the online wallet.

A variety of hardware can be used to implement this system. For example, Cold Pi and Pi-Wallet offer a portable, dedicated platform for running Armory cold storage from a small form-factor open source computer. Trezor takes this approach one step further with an all-in-one device running custom software. More typically, the offline wallet runs on a dedicated offline computer.

Backups of deterministic wallet keystores are relatively simple. Each wallet uses a seed as a reproducible starting point for generating addresses and private keys. The seed is often represented as a series of words, but QR code representations are also used. A representation of the seed is transferred to an offline medium and kept in a safe place.

Multisignature storage

Implementing cold storage correctly takes technical skill and fine attention to detail. Bitcoin's private key system exposes a single point of leverage, a private key. As a result, spending from addresses is easy for users and thieves alike. This situation leaves little margin for security errors.

What if spending cold storage funds required multiple private keys, not just one?

Multisignature addresses offer the potential for more convenient and secure bitcoin storage options. Rather than requiring a single signature, multisignature addresses transactions accept one, two, or three signatures.

Although the benefit might not be obvious, consider what this capability offers third-party services. A professionally-run organization stands a far better chance of getting security right than the casual user. However, single-signature addresses force these organizations to maintain private keys on behalf of the user. Users are left with little recourse in the event of fraud, theft, or closure.


A bank-like multisignature account: Both Alice and her bank must sign all transactions. Provided that Alice securely stores key #2, an attacker needs to compromise both Alice and her bank to spend funds.

Multisignature addresses enable a bank-like organization to offer financial services in which funds may only be moved in collaboration with the user. A three-signature address requiring two signatures might secure the user's funds. One key would be held by the service. Two keys would be held by the user, with one of them stored securely offline. Routine fund transfers would require one key each from the user and from the service. Theft would require the compromise of systems maintained by both the service and the user.


Multisigning Alice: Alice uses both of her keys to withdraw funds, without approval of the bank.

Should the service ever be shut down, the user can move funds by signing a transaction with the two keys she holds.

The recent introduction of multisignature addresses has already led to the launch of professionally-managed storage services. Currently available options include GreenAddress and BitGo.

Conclusions

When using Bitcoin, data is money. Private keys represent a prime target for network-based attacks. Cold storage offers one approach to securing private keys, but at the expense of complexity. Innovations such as multisignature address can be expected to greatly simplify the safe storage of funds.

Keep your money safely.
Postat av RoLex den 2017-12-12 16:550 comments2 likes

Ledokol 2.9.4.62

Changes in 2.9.4.62
[ 47] Fixed: User logger command parameters when searched string is a number
[ 49] Fixed: Country code gag reason parameter could not be empty, report by KCAHDEP
[ 53] Fixed: Invalid comparison of number of days parameter in registered users list cleanup command
[ 58] Fixed: Fake operator key not disappearing after setting a lower class on user, report by KCAHDEP
[ 58] Changed: VIP kicks are again made with bot nick due to rights restriction and command reservation in Verlihub, report by KCAHDEP
[ 48] Added: Separate feed for search filter notifications
[ 50] Added: Antispam debug uses operator note to specify entry that caused detection when user is banned, request by KCAHDEP
[ 51] Added: sefiblockmsg configuration to disable block list notification
[ 52] Added: WHOIS lookup using system command
[ 54] Added: History cleanup type parameter, request by Mank
[ 55] Added: Disability of automatic country chatroom entrance with code --, request by Pasha
[ 56] Added: GeoIP ASN information to userinfo and ipinfo commands
[ 57] Added: autosendhelp configuration to disable display of command list on hub help command, request by Reanimator®
[ 59] Added: norepltoops configuration to disable chat replacer in PM to operators, request by KCAHDEP
[ 60] Added: City gag feature, request by KCAHDEP
[ 61] Added: Chat code feed notification, request by Alexandr
[ 62] Added: Chat replacer can be removed by LRE, request by KCAHDEP

File information: Ledokol 2.9.4.62
Postat av ledokol den 2017-11-05 14:070 comments3 likes

AdvOR 0.3.1.5

Changes in 0.3.1.5
- geoip_c.h was updated with GeoIPCountryWhois.csv released on October 4'th; there are 163953 IP ranges having 32 ranges in the fake "A1" country; all 32 ranges were approximated to real countries
- the OpenSSL library was updated to 1.1.0g
- updated directory authorities according to https://atlas.torproject.org/#search/flag:Authority

File information: AdvOR 0.3.1.5
Postat av advor den 2017-11-05 14:060 comments3 likes

Ministry of Defence of Bangladesh - XSS

Vulnerable page: http://www.mod.gov.bd/site/search?key=

PoC
http://www.mod.gov.bd/site/search?key=<!--<img%20src="--><img%20src=x%20onerror=alert(1)//">

You can either include any XSS code in search input box, or request any XSS code directly using GET method and key parameter.



Note: This is a proof of concept and it doesn't reflect the views or interests of above websites.
Postat av Neo den 2017-09-07 22:041 comment8 likes

AdvOR 0.3.1.4

Changes in 0.3.1.4
- geoip_c.h was updated with GeoIPCountryWhois.csv released on June 7'th; there are 153678 IP ranges having 32 ranges in the fake "A1" country; 31 ranges were approximated to real countries
- the OpenSSL library was updated to 1.1.0f

File information: AdvOR 0.3.1.4
Postat av advor den 2017-06-11 10:480 comments8 likes
« Bakåt • 1 • Framåt »