Casa just launched an inheritance planning protocol, which shares many similarities with the protocol that we introduced at the end of 2022.

The following is a comparison between the two protocols, so that interested users can better understand the features and associated trade-offs.

During the writing of this report, we’ve uncovered a security weakness in Casa’s implementation. We suggest that Casa address the issue before rolling out the service to users.

Overview

We’ll strip the protocols down to the basics to make the comparison easy. We’ll be comparing Casa “3-key vault” (a 2-of-3 multisig) with our Honey Badger wallet (a 2-of-4 multisig).

The core mechanism is the same:

1. The Owner sets up a multisig wallet: two signatures are required to move funds. One backup key is controlled by the Service Provider (Casa or Nunchuk), namely the Platform Key. The rest of the keys are controlled by the Owner.
2. The Beneficiary is granted access to the encrypted backup of one of the Owner’s keys.
3. When certain conditions have been met, the Beneficiary can decrypt the above key with help from the Service Provider.
4. A sweep transaction is created; the Beneficiary signs it with the now decrypted key; the Service Provider co-signs with the Platform Key, and broadcasts.

That is the main blueprint. Now let’s get to the specifics.

Differences Between Casa’s and Nunchuk’s Inheritance Protocols
What are the conditions that must be met, before the Beneficiary can claim the inheritance?

This is where Casa and Nunchuk differ.

With Casa’s protocol:

• A Beneficiary must be explicitly named upfront and create their own account with Casa.
• They can initiate a claim on the inheritance at any time.
• When a claim is initiated, Casa starts a 6-month timer.
• During the 6-month period, Casa will notify the Owner of the claiming attempt several times.
• If the Owner is still alive, they can deny the claim.
• If the Owner is dead, after the 6 months is over, the Beneficiary can sweep the inheritance.

With Nunchuk’s protocol:

• A Beneficiary does not have to be explicitly named, although they can optionally be notified via email.
• The Owner sets a timelock on the inheritance. We currently recommend it to be 1 or 2 years. Every year the Owner is reminded to review the inheritance, and refresh the timelock (to make it 1 or 2 years again).
• Before the timelock expires, claiming is disallowed.
• As long as the Owner is alive, they can keep refreshing the timelock indefinitely.
• After the timelock has expired, the Beneficiary can create an account and start a claim. Claiming requires the Beneficiary to know two cryptographic secrets: the Magic Phrase, and the Backup Password.
• Once a claim is initiated, an optional Buffer Period ensues (7 days or 30 days).
• During the Buffer Period, Nunchuk will notify the Owner of the claiming attempt several times.
• If the Owner is still alive, they can deny the claim.
• If the Owner is dead, after the Buffer Period is over, the Beneficiary can sweep the inheritance.

To summarize so far:

• Both protocols rely on time as the main defense mechanism. Nunchuk requires two additional secrets.
• Casa has one time component: the 6-month timer that starts when a claim is made.
• Nunchuk has two time components: the timelock, set by the Owner, and a Buffer Period (7 days or 30 days) that starts when a claim is made.
• Nunchuk requires the Owner to review the inheritance every year and refresh the timelock.
• Casa requires the Beneficiary to be explicitly named. They must create an account with Casa from the beginning.

The fact that Casa's protocol requires the Beneficiary to open an account from the beginning for it to work, means several things:

• The Beneficiary has to be involved with the inheritance planning from the get-go.
• The Owner needs to reveal the existence of the inheritance to the Beneficiary.
• The Beneficiary would need to maintain an active (but unused) account with Casa until the Owner passes away. If they lose the account, they will not be able to access the inheritance.
• Since it is the Beneficiary that must open an account, Casa's protocol cannot work with a Trustee or within a larger estate plan. Consequently, if the Beneficiary is a minor, Casa's protocol will not work.

Nunchuk's protocol does not have the above limitations. With Nunchuk:

• The Beneficiary does not need to open an account with Nunchuk from the beginning. They can open an account at any time, after the Owner passes away.
• The Owner does not need to reveal the existence of the inheritance to the Beneficiary, unless the Owner chooses to.
• The Owner has a number of options when it comes to passing down the inheritance. They can pass it directly to the Beneficiary, by sharing the required secrets ("direct inheritance"). They can also pass it indirectly by entrusting the secrets with a Trustee ("indirect inheritance"). Lastly, they can also mix the above two options: give the Beneficiary and a Trustee joint control over the inheritance ("joint control") by giving each one secret.
• Nunchuk's inheritance protocol can fit within a larger estate plan and legal framework.

The above are the key differences between Casa's and Nunchuk's inheritance protocols.

Now let’s get to the problematic area in Casa’s current implementation.

Security weakness in Casa’s implementation

Above we mentioned that the Beneficiary is granted access to the encrypted backup of one of the Owner’s keys.

There are two reasons that this key must be encrypted:

(a) To ensure that the fully decrypted key can be released to the Beneficiary at a later date in a controlled manner,

(b) and more importantly, to ensure that the Service Provider themselves can never gain access to the underlying private key. Since if the Service Provider can access one of the Owner’s keys, together with the Platform Key they already hold, they’d have enough keys to move the funds themselves.

Due to the latter reason, it is absolutely crucial for security that the decryption key must not be generated by the Service Provider, and the encryption process must not be handled by the Service Provider either.

In Nunchuk, we ensure the above by requiring that the Owner uses a Tapsigner card for the inheritance key, which the Owner must purchase directly from the vendor. The decryption key is on the physical Tapsigner card, which the Nunchuk service never has possession of. The Owner must also share the decryption key with the Beneficiary themselves. The encryption of the Tapsigner’s private key is not done in Nunchuk’s software, but is handled directly by the Tapsigner hardware via the AES-CTR-128 algorithm.

However, Casa is generating the decryption key and doing the encryption themselves. This is a major security weakness. It potentially opens the door to Casa gaining access to the mobile key, and as a result, full access to the user’s funds.

Additionally, Casa also generated the mobile key in the first place through the Casa mobile app. This increases the risk of the mobile key being compromised even further.

To sum it up, Casa’s current solution requires the users not only to trust Casa in generating the mobile key, but also in encrypting it and sharing it with the Beneficiary securely, all the while not learning what the mobile key is. This is a lot of trust.

We suggest that at minimum, Casa should move the encryption part of the protocol to a dedicated hardware, or an independent party that is not affiliated with Casa.

If you are a Casa user, we recommend that you delay using Casa inheritance service until this issue has been properly addressed.

An early version of this report has been sent to the Casa team.