AOPP and xPub Sharing: How Compliance and Cryptography Fit Together

In a recent blog post, AOPP & xPub Sharing: A Match Made in Heaven, we discussed how xPub sharing combines perfectly with the Address Ownership Proof Protocol (AOPP) and establishes a proof of ownership over a large set of addresses. This allows AOPP to be used for deposit transactions, where a virtual asset service provider (VASP) will, in general, require proof of ownerships over multiple input addresses for UTXO-based chains.

Today, we want to take a more detailed look at why this works in practice from a compliance standpoint. Specifically, how can we be sure that the user really has control over all private keys in the set covered by an xPub? To explain that, we first need to briefly explain one often-overlooked subtlety of xPub derivation.

Non-hardened Key Derivation

Let us first remember the goal behind xPub sharing: The counterparty should be able to derive child public keys based only on the xPub without any private key information. To do this, the usual mode of BIP32 key derivation uses (among other parts) the parent public key to derive the child public key. This later allows the counterparty to do the same since the public key is encoded in the xPub.

This procedure is referred to as non-hardened key derivation because it comes with a potential security risk: If the counterparty somehow gains access to a child private key, she can derive the parent private key, and through repetition, all of the private keys in the entire tree! This is why a hardened form of key derivation also exists, where the parent private key is used to determine the child private key (instead of the parent public key). However, this means the counterparty can no longer derive anything based on only the xPub.

In practice, almost all wallets use a combination of hardened and non-hardened derivation, often protecting the higher regions of their BIP32 tree with hardened derivation and only using non-hardened derivation for the last two levels or so.

What Does This Mean for AOPP?

What guarantees would we like to have when combining AOPP and xPub sharing? We would like to be certain that the user has control over all of the private keys in the BIP32 set. For example, we would like to avoid the scenario where Alice gives her xPub and a child private key to Bob, and Bob later submits the xPub and a signature to his VASP, claiming to control all of the private keys. This would invalidate our above goal. 

However, in the previous section, we have just seen that this scenario is impossible by definition! Concretely, because the VASP has verified that the address is part of the xPub tree, we know that Alice used non-hardened derivation. This means that Bob can take the xPub and child private key he got from Alice and derive all of the private keys! What we get is the nice property that Bob either knows no private keys or all of them, exactly what we need for proof of ownerships!

Curious to find out more about Address Ownership Proof Protocol? Reach out to us.