This morning I spent some time putting down some the risks relating to Bitcoin that I considered before I made the switch to focusing my efforts on this space.Mind Maps are a great way to collect your thinking and XMind is a great tool to create them with.
This map is far from complete but maybe it will spark your imagination.
Hardware based key management solutions like Smart Cards and Hardware Security Modules provide a lot of value. Probably the most important being that the keys are moved out-of-process into a totally separate computer. This goes a long way towards protecting keys from being stolen via by malware or exposing keys to an attacker via software defects like happened with Heartbleed.
Depending on the device you choose you may also get:
Despite how valuable these solutions are they are not without their shortcomings one of which is that for the last twenty years they have not changed much short of getting faster and adding support for newer mandated algorithms.
One of the reasons these devices have not changed is that Common Criteria (CC) and FIPS 140-2 verification, the standards they must conform with to be sold to their largest customers, make it excruciating hard to change and as such the incentive model is set up to discourage innovation and often encourage bad behavior.
These restrictions also have resulted in them not supporting algorithms not mandated by these standards this means in the case of Bitcoin the decision to use secp256k1 in the protocol precludes their use or limits their use to a limited feature set and significantly reduced performance.
Additionally since PKCS#11 (the library one uses to work with these devices) doesn’t specify how to generate a secp256k1 key any code written to use such device ends up being proprietary.
The net-effect of this is if you buy one of these devices your going to be spending $5,000 for a device that gives you some of the above properties that you can write custom software on that would be able to do about 24 secp256k1 operations a second.
This is more than enough for a personal wallet but nowhere near enough for an exchange or payment provider; which means these vendors, are not using these sorts of techniques to keep your keys safe.
There have been a number of solutions that have been started by individuals to bring some of these protections to Bitcoin to-date they are all incomplete, unusable, unmaintained or not available.
The most promising being the Trezor but based on what we know of these systems its seems very unlikely they will provide the kind of protection one gets from a commercial hardware security module or many of the other features these devices often have.
And even if they do since they are for the most part by individuals with limited resources who knows if they will be around or available a year from now? If you have lots of Bitcoin in these devices and the vendor goes down or the device fails what are you to do?
That is not to say this these projects are not good, in-fact I will order a Trezor once they start taking orders again but they should be thought of as a Wallet and not a Safe or Vault as they will not protect from a well healed attacker and without much more work are not appropriate for cold-wallet storage of large amounts of Bitcoin.
If you know anyone who invests in precious metals you have probably heard the phrase “if you don’t hold it, you don’t own it”.
This old adage comes from the risks you are exposed to through use of services that practice things like fractional reserve banking and non-segregated storage of assets. Though personally think these practices can result in significant value for the depositor one can not reasonably argue that they do not come with risks.
This is particularly interesting for Bitcoin; not for political or dogmatic reasons but ones of practicality. Today Bitcoin is in many countries considered “property”, that it has a market capitalization of over 5 billion as of today and that the top 500 Bitcoin addresses control over 30% of all Bitcoin it seems there is quite a lot that these high-net worth users can learn from people who have invested significantly in precious metals.
With that in mind I thought it was worth talking about a set of guidelines people can consider when answering the question of “how should I hold my bitcoin”
Invest proportionally to the risk; if you have forty million dollars worth of Bitcoin you should use different strategies than someone with twenty thousand dollars in Bitcoin additionally the your ability financially to survive the loss must be considered.
Plan for the worst; as they say, “locks keep honest people honest” and “to error is human” as such we must have ready plans on how to handle attacks and compromises when and if they occur.
Trust but verify; verify the claims and that the technology and service providers you use provide and regularly check on your assets and ensure they are still accesible.
Understand your risks; it’s near impossible to devise a security strategy that will effectively secure anything without having a solid understanding of the risks you are exposed to.
Don’t rely on technology alone; while technology hold promise in securing these assets we in many cases the path of least resistance is to just take physical control of them.
Learn from the past, design for the future; while we all may enjoy pointing out the ridiculousness of the TSA’s reactive strategy of threat analysis understanding attacks that have come before is key to understanding how to physically secure your assets.
Diversification, Diversification, Diversification; whatever approaches you take don’t put all your eggs in one basket. You do not want a failure of a single mechanism to result in the loss of your stored assets.
You can’t hack what you can’t find; though security through obscurity isn’t exactly a solid security design strategy it’s origins come from physical security where it has much more value. Keeping your location and control mechanisms confidential makes it harder for your attacker.
With that in mind you have a few choices to base your strategy on these include:
If you’re leveraging secret sharing chances are you will use several of these in your final solution. This helps quite a bit in that when it comes to physical storage using a third-party your biggest risk is that facility.
Of course even when you distribute your shares to multiple facilities you have the question is how you secure the secrets that are used to protect those shares.
By ensuring both the shares and the secrets that protect them are geographically distributed and under the control framework of different third-party facilities you reduce your risks significantly.
I am hopeful that within the next few years we will also see increased adoption of P2SH and hardware security modules / smart cards designed around cold wallet scenarios; these have the potential to raise the bar even further but do not replace the need for proper physical storage.
Lately I have been giving some thought to effectiveness of security controls in relationship to physical security.
To do so requires a definition of what one will consider “effective”. If we can accept that an appropriately motivated and well-funded attacker can bypass all mitigations our definition of effectiveness must be based on the skill and motivation of our attacker.
This also means we must give thought to how quickly we can respond when we become aware of an attack.
This is in essence the same approach we take when designing secure software systems. The core difference being we also have to consider the physical properties of the space we are protecting along with the human factors of the design of the system.
On the topic of physical properties of the space we have to consider the materials it was constructed with. One of my favorite examples here is how in the movie Sneakers Robert Redford’s character bypasses a security keypad by kicking the door down.
In this case even if appropriate door hardware was in place he could have simply gone through the wall like in this case of the recent burglaries of some Best Buy stores.
The state of affairs with home security is even in worse shape. Locks on doors are often of low quality and are trivially bump-able the plethora of home alarms that are installed typically use wireless sensors that can be bypassed with just a few dollars of electronics, garage doors can often be bypassed with nothing more than a bent hanger and if that wasn’t enough just throw a rock through a window.
So given this sorry state of affairs what should we do? First we need to be realistic about what the risks, the assets we have to protect and the value to the attacker. Then we should only invest proportionally to those variables.
To do this we need to develop a solid plan of what intrusions we have a chance of detecting, when we do detect them how quickly we can do so and then what our response will be in each of those cases.
For this reason a good quality alarm system is very important but they don’t do much good if they are not activated. Once activated we need to think about how long it takes for the monitoring service to be called, once contacted what do they do and how long does it take? Also In some cases the police will refuse to respond to a call that has not been confirmed by someone on-site and if they do often times responses can take hours. With that said knowing what the response time is is invaluable to understanding how long your mitigations will need to withstand attack.
But if as they say “Locks are for honest people” why do we bother at all?
The answer is that well-thought out mitigations do act as meaningful deterrents that can significantly reduce your risk but more importantly having proactively considered the risks and built the corresponding mitigations you are positioned to reduce your exposure (see my recent posts on Why shouldn’t you use safe-deposit boxes to store Bitcoin? and Insurance and Bitcoin) and ensure that such events are survivable.
So I just got my PiperWallet. For those of you not yet familiar with it the PiperWallet is an open-source hardware bitcoin wallet based Electrum running on a RaspberryPi paired with a built in thermal printer in what looks like a 3D printed chassis.
The basic idea is that managing cold wallets is hard and it doesn’t have to be.
Even though I have only started to play with the device overall I am impressed. Here are my initial observations:
So far I am happy with the purchase though I need to do some more playing with it before I make any final conclusions.
With that said here are the things I think I would change if it were my product:
Before sending someone a large sum of money on the internet via a irreversible transaction you better make sure you are sending the funds to the right address.
There are a few ways to go about doing this and depending on who you are sending funds to, how accessible their keys are and what the capabilities and behavior of their wallet software is you may need to choose different solutions.
If we assume the recipient has the key associated with the target wallet online (aka not in cold storage) and that that the software they use for that wallet supports message signing with wallet keys this can be a viable option.
Unfortunately there is not currently a standard for the format of signatures using bitcoin keys with that said thankfully there appear to only be two common formats in-use today.
The first format being in-essence no formatting; client simply present you the three values you will need to verify a message and you do with them as you see fit, for example:
This format leaves a little be desired. For one you have to pass these values independently and then you also have issues around introduction of white-space which can invalidate signatures.
There is another increasingly common format that leverages ASCII armor and some codified rules to address these issues. This style of formatting originated in a project called Privacy Enhanced Mail (PEM), it was one of the first proposals for how to sign and encrypt mail on the Internet and was later adopted by PGP (RFC https://tools.ietf.org/html/rfc4880).
But don’t confuse this format with these other formats they follow some different rules when it comes to encoding.
What this means is that depending on the implementation of the wallet software the recipient uses you may not be able to validate the signature they produce without some manipulation of the text.
As for what this format looks like, its fairly straight forward:
-----BEGIN BITCOIN SIGNED MESSAGE----- [email protected] - my voice is my passphrase authenticate me -----BEGIN SIGNATURE----- 18neTpQ5MWnXg4n4rpoK5TgxXjEVcg2MYR G0d6BnQem1gT4nd9esfsEyn1k/GfYAxDkNJmkNvmz8wCOI2Ncw9DvIcyP7OJcEvWbUHQNIBFK3V8wYdnhEFhYHI= -----END BITCOIN SIGNED MESSAGE-----
The core differences with this format (as specified in this thread and the PGP rule-set are:
The reason I point this out is that since there really isn’t a standard for this signature format and the format diverges from what has been used historically you may still encounter interoperability issues when validating messages between clients that have not been tested with each other.
With that said when you have managed to successfully verify a message like this you know that whoever produced the message owns the key associated with the wallet associated with it.
To address the risk of a message substitution the sender would need to communicate a challenge out of band to the recipient. For example you may notice in my message above I included “my voice is my passphrase authenticate me”. My inclusion of this message (presumably exchanged out of band) helps assure the sender that it was me who signed the message.
To make this process a little easier Andrew Yanovsky and I put together a simple site that can validate both formats, it’s all client side so you can save the files locally and run without the dependency on the website if you like.
NOTE: It is worth noting that this workflow does not accommodate P2SH and multi-signature wallets both of which will see increased use as time progresses.
The simplest way to verify an address is to simply send a small amount of money to that address and verify out of band with the recipient that they confirm seeing it in their balance. This is what most online payment services but again this requires the keys to be accessible to the sender they can perform the transaction.
There are a few things to keep in mind if you go this way, specifically:
Once the transaction has been sent and you use a tool like blockchain.info to see that the transaction has been confirmed you can verify out of band with the address owner again that they see the funds as well.
This approach unlike the wallet signing key approach can also work with multi-signature and P2SH wallets which will be in use increasingly as clients better support these techniques.
If they keys are offline (in cold storage) the only viable option is to carefully validate each character of the address via an out of bound secure channel, I would personally not rely on this approach for large sums but if both parties are careful it can work. By doing the check twice you reduce the chance of human error but mistakes can happen and in this case they can not be undone so use this approach with caution.
None of these solutions are perfect and moving forward I expect we will see services like OneName.io and exchanges with authenticated account profiles will become the way that we solve these problems but in the mean time you can reasonably manage the transaction workflow via these two mechanism.
Now that its possible to decode and verify the signature on X.509 certificates within the browser the natural question to ask is what can I do with that?
Well first off to build an interesting application you will need to have the ability to validate that a certificate is trusted the first step in doing that is building the certificate path associated with the certificate.
The defacto standard for path building libraries is the NIST PKITS tests our goal is to create a library that will be able to pass the sane tests from this suite (some are odd for sure).
This is a pretty high bar and will take some time. At the time of writing this blog post we pass 1-33 of this test suite in with flying colors these tests cover all of the basic certificate validation rules. We also think the library will pass all Policy Constraints and Name Constraints but more testing is needed to confirm.
So how does building a chain look like today with this library?
var certs = new Array();
// Load cert to be validated, its intermediates and root
for(var i = 0; i < cert_buffers.length; i++)
{
var asn1 = org.pkijs.fromBER(cert_buffers[i]);
certs.push(new org.pkijs.simpl.CERT({ schema: asn1.result }));
}
var crls = new Array();
// Load any CRLs we have
for(var i = 0; i < crl_buffers.length; i++)
{
var asn1 = org.pkijs.fromBER(crl_buffers[i]);
crls.push(new org.pkijs.simpl.CRL({ schema: asn1.result }));
}
var cert_chain_simpl = new org.pkijs.simpl.CERT_CHAIN({
certs: certs,
crls: crls
});
cert_chain_simpl.verify().then(
function(result)
{
alert("Good result");
},
function(error)
{
alert("Error: " + error);
}
);
The current incarnation of the API expects that the bag of certificates that is passed in will include all intermediates as well as all trust anchors. We will be changing this in a future release so that trust anchors are passed in another bag.
This will help ensure that the certificate inputs to be validated don’t contain anything that might accidentally result in the certificate being treated as valid when it should not be. With that said as it is currently structured we can begin developing automated testing which is great.
Note: Updated the post to indicate the goal is to pass the sane PKITS tests, some of which are not and some are not possible to pass in a web environment.
The other day I did a post on how to create a self-signed certificate using PKI.js in that sample we included a Basic Constraints extension but we could have also just as easily defined a custom or new certificate extension. For example thanks to #heartbleed folks are talking about MUST STAPLE again, this is an extension that was proposed several years ago that when present would indicate that clients should hard-fail instead of soft-fail with OCSP.
This proposal is based on a generic concept of expressing a security policy within the certificate. While the OIDs for this extension and the associated policy have not been defined yet one can easily construct a certificate using this extension with PKI.js:
cert_simpl.extensions.push(new org.pkijs.simpl.EXTENSION({
extnID: "1.2.3", // No OIDs assigned yet
critical: false,
extnValue: (new org.pkijs.asn1.SEQUENCE({
value: [
new org.pkijs.asn1.INTEGER({ value: 4 }),
new org.pkijs.asn1.INTEGER({ value: 5 }),
new org.pkijs.asn1.INTEGER({ value: 6 })
]
})).toBER(false)
}));
NOTE: In the above snip-it we just made up two OID values, hopefully IANA will assign OIDs soon so it is possible for browsers and CAs to implement this extension formally.
Banks are not exactly what they used to be. I don’t know exactly when it changed but as a boy I remember banks being these massive buildings with large vault doors, armed guards and cameras everywhere but it seems increasingly they are located in strip malls right next to a Great Clips with nothing more an alarm and a small safe in the back. Frankly most don’t even offer safe deposit services any longer.
The lack of security of these facilities offer is not why I don’t recommend their use; it is because they can’t be trusted to keep your valuables safe. Not only can the federal government seize the contents of these safe deposit boxes at will increasingly the state governments are doing so as well as a means to shore up their own finances via their unclaimed property programs.
You can mitigate some of these risks by using techniques like Shamir Secret Sharing to split your keys up into M of N parts or by utilizing multi-signature wallets where the parts or keys are stored at different facilities reducing the likelihood of these events impacting you (which you should do regardless) but as a general rule I recommend use of private facilities instead.
Private facilities have a number of value propositions above and beyond banks, these include:
Above these value propositions a few things to keep in mind when looking at these facilities are:
Regardless of which facilities you choose to store your Bitcoin assets its also important to remember the old adage of “Trust but verify” and periodically access the assets to ensure their integrity and availability.
One of the most common signature formats on the web is known as CMS SignedData, this is the signature format used in PDF files, CAdES, S/MIME and several other digital signature solutions.
As a signature it has a few notable features:
These traits mean you can do some interesting things like implementing counter-signing in-turn enabling notarization scenarios.
Utilizing PKI.js you can now create and verify this signature format, bellow is an example of how creating one of these messages looks using this library:
// #region Put a static values
var sample_data = new Uint8Array(sample_data);
sample_data[0] = 0x00;
sample_data[1] = 0x01;
sample_data[2] = 0x02;
sample_data[3] = 0x03;
sample_data[4] = 0x04;
cms_signed_simpl = new org.pkijs.simpl.CMS_SIGNED_DATA({
digestAlgorithms: [
new org.pkijs.simpl.ALGORITHM_IDENTIFIER({ algorithm_id: "1.3.14.3.2.26" }) // SHA-1
],
encapContentInfo: new org.pkijs.simpl.cms.EncapsulatedContentInfo({
eContentType: "1.2.840.113549.1.7.1", // "data" content type
eContent: new org.pkijs.asn1.OCTETSTRING({ value_hex: sample_data })
}),
signerInfos: [
new org.pkijs.simpl.CMS_SIGNER_INFO({
sid: new org.pkijs.simpl.cms.IssuerAndSerialNumber({
issuer: cert_simpl.issuer,
serialNumber: cert_simpl.serialNumber
}),
digestAlgorithm: new org.pkijs.simpl.ALGORITHM_IDENTIFIER({ algorithm_id: "1.3.14.3.2.26" }), // SHA-1
signatureAlgorithm: new org.pkijs.simpl.ALGORITHM_IDENTIFIER({ algorithm_id: "1.2.840.113549.1.1.5" }), // RSA + SHA-1
})
],
certificates: [cert_simpl]
});
// #endregion
return cms_signed_simpl.sign(privateKey, 0);
In this sample you can see we are putting our content to be signed within the SignedData message and then signing it with RSA and SHA1, this is in-the exact same thing that is needed to implement what is called opaque signed email in S/MIME.