Beware: Bitcoin Insurance Is Not Just Marketing

Ask the right questions and separate the contenders from the pretenders

A core mission of ours at Knox is to enable and encourage strong insurance for anyone holding bitcoin on behalf of others. Whenever possible, we believe bitcoin holders should manage their own private keys and be sovereign. However, scenarios exist where this is either impossible or undesirable, and that in such cases insurance should be available as an option. This is because bitcoin is a bearer instrument, making any theft or loss irreversible. As a result, we believe it irresponsible to hold keys on behalf of someone else without adequate insurance cover.

The secret is, much of what passes as insurance today isn’t purchased for the sake of protection, but for pure marketing reasons. Insurance should exist to make fund recovery possible. If consumers knew they could at best recover 5% of their funds with current “insured custody” options, or that their most feared events aren’t even covered, they wouldn’t call it insurance.

We do not want to live in a world where insurance is purchased for marketing purposes. Insurance has an important practical role to play, and abusing it doesn’t help anyone. At best, this situation would be on the edge of acceptable if people understood what was really happening. Trouble is, this is rarely the case. Dubious insurance is passed off as real coverage, and consumers are left with the wrong impression.

Why are bitcoin custody insurance policies mostly marketing today? Why are custodians not covering critical risks, exposing their clients to potential thefts and losses? Is full insurance coverage economically viable for bitcoin custody? What are the required limits to provide reasonable coverage?

This article will explain why many insurance policies are nothing more than marketing, a view into the lapses of coverage, across both depth (fractional insurance coverage) and breadth (types of risks covered), alongside some useful guidelines for conducting due diligence on providers who claim, correctly or not, to have an insurance policy.

Insurance is Not a Binary

Getting bitcoin holdings insured has always been difficult. When we first got started in early 2018, there was nowhere anyone could store their bitcoin with adequate insurance against theft and loss. It is still a scarce offering today. For example, few exchanges in the world can say their cold storage bitcoin holdings are fully insured as is the case for Bitbuy in Canada. We noted so many deficiencies in existing policies, that it started to look like they existed mainly so the holder could answer “yes” to the question “are you insured?”, rather than to make claims following theft or loss scenarios. Years later, we proudly label ourselves the only 1:1 insured custodian. Then comes the question: why am I told certain holdings are insured?

Most custody service providers are buying insurance to use for marketing purposes, and “are you insured?” is usually treated as a binary condition. Technically speaking, a provider is insured if they have some policy, even if it is fractional or fails to cover collusion or some other important element and so would either not pay out at all, or recover a sliver of lost holdings.

Few understand insurance, so they think of it in binary terms: either something is insured, or it’s not. In reality, those asking the question would be better off thinking of it in terms of the adequacy of the coverage. Insurance coverage should be thought of as a spectrum, and not a binary.

If this were more common, more people would realize how many policies exist for marketing purposes and not the principal reason for which insurance exists: to make fund recovery possible. In the following sections, we present a way to aid the reader in thinking about insurance policies as something other than a simple binary condition.

Define Adequate and Hold to It

So what qualifies as adequate coverage? We have outlined some of the risks we think are important to transfer, and our belief in covering up to 100% of the value of funds held. Others may feel differently, as “adequate coverage” is subjective. The important thing is to know what adequate means to you, and dig in to find out if the coverage satisfies. If your knowledge of the coverage feels binary, you likely haven't done enough digging. Maybe our views on insurance are extreme, and what is inadequate to us is perfectly adequate to others. At the end of the day, so long as consumers are informed, we take no issue. In our experience, few are very well informed.

Following are some aspects of insurance policies or key management systems worth thinking about. These can guide you to some straightforward questions you can ask of those carrying an insurance policy. Some of these were picked up from customer interactions, others from internal thoughts or concerns we've had while continually hardening our system and the insurance policy protecting it.

A Framework for Debunking Insurance Policies

Broad Classes of Loss

We can start very simply with: What are the claim events that we care about?

In Knox's case, we asked ourselves this question from day 1, before building anything. If we were to entrust Knox with our bitcoin, what kind of events could we foresee transpiring? In each case, could we make sure that these events were explicitly covered in our insurance policy, and what would it take to get there? Briefly, we focus on:

• Protection against destruction (Natural catastrophes, etc.)
• Protection against theft: External entities stealing from Knox
• Protection against internal theft: Knox employees colluding to cause a loss
• Protection across the entire private key lifecycle

With particular stress on the last two. How these risks are transferred, and the ability to prove to our customers that we are covered as we say we are. In the coming sections, some important concerns related to these will arise.

Describing How Risk is Managed

At a high level, bitcoin custody can be described in a straightforward way: private keys are generated, those keys are backed up, and those keys are used to sign transactions. For anyone who has had to manage a set of keys that safely store large holdings, personal, corporate, or otherwise, that description belies the amount of complexity that can exist when considering every last detail. Of course, the devil is in those details, and those details matter. They matter for the likelihood of a theft or loss, and they matter because in the case of a theft or loss, the coverage may not be there.

The most obvious point, if you are entrusting an entity with your bitcoin, is that they had better be able to walk you through, detail by detail, step by step, every one of the procedures they employ. This is important to understand in a technical due diligence, but it ends up mattering equally in an insurance due diligence, as the validity of their insurance policy likely rests on the ability of the agent to actually execute those processes.

Security through obscurity

A disappointingly oft-practiced but frowned upon (for good reason) practice in the security realm is security through obscurity. We'd tell you but then we'd have to kill you. The act of constructing some system that is trivially attackable by its designer, mixed with the naïve hope that, due to its arcane construction, it will continue standing. From a security perspective, security through obscurity is not security. From an insurance perspective, coverage is dubious.

When analyzing a bitcoin key management system, it is clear when this is playing out.

The designers or maintainers should be able to outline the details of the system and its implementation, and not resort to claims that revealing such details would put the funds at risk. Playing that card is textbook security through obscurity.

There are two possible realities for a system that is described playing that card, and they both end in heartache.

1. The designer / implementer is being honest:

The implementation details really are exploitable by an attacker.

This system will eventually falter. From an insurance standpoint, a valid claim event is unlikely, as the vulnerability was either revealed resulting in a very narrow-scope insurance policy, or not revealed, invalidating the policy.

2. The more likely scenario:

You are being played.

The actual method as practiced is so embarrassingly shoddy, revealing its true nature would leave you running for the hills. Or worse, there's no protection there at all. Again, from an insurance perspective, there is not likely a valid claim event here.

In the context of a bitcoin key management system, this likely means outlining practices that the person asking the question would find questionable in a personal setting, let alone a system guarding others’ funds.

It is entirely reasonable and should be expected that anyone entrusting another entity with their bitcoin has the right to learn how it all works under the hood. The designer of a key management system should be able to run through every detail, and be proud of the many safeguards they have erected to protect customer funds. An unwillingness to do so, especially if they claim to carry insurance, is suspicious.

There are reasonable exceptions to this. For example, at Knox we take the personal safety of our personnel very seriously, and think it reasonable to hide identifying details about particular agents. We will however explain when a human is involved, and prove that that human is not the same as some other if that constraint is necessary. That is to say, we will expose every detail as it relates to our security, especially those to which we are held for our insurance policy.

Cold storage vs. Cold custody

Picking up from the above, listen carefully to how the processes are described, and look out for situations in which some private material comes to exist in a network-connected device. Such a system could, in theory, be described as a cold storage system. After all, the material is hot only briefly, and it is stored cold. But it is not cold custody. Alongside a cold insurance policy, this can easily produce an invalid claim, as the loss event will occur precisely when the keys are no longer cold.

It is critical that the private keys in a cold custody system are kept eternally quarantined. If this is not the case for even just an instant in time, the system is not a cold custody system. Ask the explicit question: Does a loss during this moment in time qualify as a valid claim event?

Meticulous follow-through

Not only should an entity be able to tell you, in excruciating detail, how every aspect of the key lifecycle is managed, they need to prove that they really follow through. We engage many risk management techniques, some of which we have detailed openly, and others we readily discuss during diligence. However, saying you do something, actually doing it, and proving that you do it, are entirely different things.

We think it important to be able to rely on your custodian to be as transparent as possible about their processes. You should be able to point to various risk management techniques, processes, or otherwise, and ask what, if any, material the entity can produce to assure you they are truly engaging that practice. Increasing the auditability of key management systems is a major goal at Knox, and we continually learn about the concerns shared by our customers and prospects when it comes to how we conduct our affairs.

Machine guarantees, not human policy.

There's a pattern that plays out once in a while, these days with increasing frequency. We’re all familiar. Some reputable organization, sometimes a law firm, sometimes a bank, sometimes the white house, suffers an embarrassing leak. You would expect the organization in question to be held to the highest security standards, or be otherwise competent, and yet this happens. They hold countless certifications. They've held a SOC2 Type 2 for years! And yet this happens.

Why is this so? It is because their primary means of securing their systems is by way of policy. This means that a set of human beings adhering to a set of rules are engaging as prescribed. The trouble is, humans are fallible at best, and nefarious at worst. Given enough time, a system secured mainly by human policy will either suffer from a mistake by its human operators, or be brought down by a malicious actor. Relying on policy alone to secure a system is another sure-fire path to heartache.

Most of the R&D work Knox has conducted has been focused on eliminating as many human processes as possible, hardening our systems with machine guarantees. Machines also have their faults, a topic we intend to write about at length in the future due to our internal obsession with correctness in digital systems, but by and large they offer a path to increased safety that should be exploited at every turn.

We have written on the specifics of this topic before, but for the purposes of this piece, consider asking anyone you are entrusting with securing your secrets: How much of this depends on people following the rules? If, in the common case, everyone at the company is nefarious, could a loss result? If so, is that loss insured?

Cradle to Grave

One aspect of existing insurance policies that surprised us when we first got started was how often they applied selectively to only some subset of the key lifecycle, leaving many activities completely exposed.

We pride ourselves on having built extreme levels of security into every layer of our architecture. From distributed key generation, to highly redundant storage, to secure global transport of private key material and HSMs, and certainly to signing of bitcoin transactions.

As a result of this, we made sure to look at how every stage of the life cycle interacts with our insurance policy, such that we can claim that every leg from cradle to grave has insurance coverage for the properties previously mentioned. This means that there is no point in time in the key lifecycle, however brief, where the policy is not effectively insuring the key risks.

When analyzing any key management system, and especially the insurance policy bound, walk through every stage of the key lifecycle. This means understanding how keys are generated, archived, transported, used in signing, and any other activity related to the key.

Following are some important areas to look at and understand. In the following, we refer to the entity that has taken out a policy as “the insured” per insurance parlance.

Can the insured describe every stage in detail?

Is it possible, with the information provided, to map out every moment in the life of a private key associated with an account? Is it clear who is involved, and what restrictions are placed on those involved? For example, how many individuals does it take to perform some action, and what does that mean for their future participation in other actions?

Is the insured held to a set of protocols that they must follow?

If so, they should be able to describe each of those protocols. Further, they should be transparent in helping, to the extent possible, to show that those protocols are being followed. This is the best time to look out for any attempt at security through obscurity.

Are key generation, transport, and signing explicitly covered?

While looking at the full lifecycle, some specific questions to ask: Are the key generation events themselves insured? Are keys or any sensitive material ever transported, and if so how? Are each of these transport events explicitly insured?

Is the full signing procedure clear and insured?

A vast majority of the life of a private key is spent signing, so understanding this aspect is critical. How is signing accomplished exactly? Are multiple keys used? How is information moved between the keys involved in the signing quorum? From previous points, how did these keys come to exist in the first place, and how were they installed into the signing context? If these keys are damaged, what does it take to recover?

Are keys ever not cold?

As mentioned above, it is possible to store keys cold (offline), yet not have a cold custody system. Is this possibly the case, and what is the rationale for it?

Can the insured think adversarially?

Anyone who has held material sums of bitcoin knows to think adversarially, and to be paranoid about the events that can transpire. Can the insured walk through what it would take to actually cause a loss or theft event? Who would need to be involved, and what obstacles would they have to overcome? Assuming full destruction of entire cities, what would have to happen in the world for an irrevocable loss to be rendered?

The importance of constructing a bespoke policy

Insurance policies can be purchased, but at their best they are constructed with a particular system in mind.

Since many in the Bitcoin space understand the nature of software far better than the nature of insurance, we like to frame it in the following way. Insurance policies, like software, are living. Like software, an insurance policy is never finished. As systems evolve, so too must the policies protecting them. You may start somewhere, and continue evolving.

When speaking to an entity about their path to insurance, they should be able to describe how they arrived at their first bound policy, the process they took to get there, and where this is all going. If not, they weren't building, they were shopping. We wouldn't buy software from a company that slapped a label on a ready made product or couldn't lay out a future roadmap, and we treat insurance the same way. It takes many months, and refinement over years to get this done right.

In particular, take care to walk through the potential exclusions and areas that are either not covered, or were not covered when they first began studying potential policies. How these were filled in, and the rationale for which were important to focus on is illuminating when understanding the history of insurance in the field as a whole, and that particular player’s views on adequacy of coverage.

Double-spending an insurance policy

If you are storing some value of bitcoin, you want to understand the capacity of the insurance policy bound by the entity storing it on your behalf. It is critical that you understand the interplay between you, and every other customer. This is the oldest trick in the book, and a key area where customers should be especially vigilant.

Is the insurance capacity of the key manager explicitly earmarked for you, or is it shared among other customers? If they have an insurance policy for 2, 3, 5, 10% of their aggregate holdings, where do you sit in the pecking order if they take a 20, 80, 100% loss? Concretely: Suppose you would like to entrust a 3rd party with $250M worth of bitcoin. Can the insured assure you that if all of the funds under custody were lost, the insurance claim can be large enough to cover your full $250M, and that none of those funds would be owed to others as well? In other words, is the insured in any way double spending their insurance policy?

We would be remiss if we didn't end with proof.

Given the importance we place on making sure that our policy limits are not shared between customers, we strive to prove to our customers that this is so. In our case, this involves allowing our customers to optionally receive a certificate signed by our broker, Marsh, asserting that the limit in question is explicitly earmarked for them, and them alone. As a result, a good question to ask of anyone is to see what if anything they can provide to prove that the limit is not shared.

Ask away

Don’t be fooled by bitcoin custody insurance that exists for marketing purposes.

Armed with a new approach for debunking insurance policies, it should now be possible to separate those which exist for marketing purposes, and those which exist to transfer the risks that matter.

If you are looking to hold material sums of bitcoin, are interested in an insured key management solution, and would like to find out more, please don’t hesitate to reach out. We’d love to walk you through every aspect of our system, and answer any questions you might have, whether those from this article, or others that you are curious to ask.