Protecting BRC-69 Key Linkage Information in Transit
Revealing how two parties' keys are linked hands over something genuinely sensitive, and sending it in the clear defeats the purpose. This adds encryption around that revelation so only the intended recipient learns it.
Summary
- Why
- Key linkage proofs are sensitive enough that they must reach only the intended verifier, not anyone who happens to see the message.
- What
- BRC-72 defines two encrypted payload formats, one for revealing a counterparty's shared secret and one for revealing a specific derived key offset, so linkage information from BRC-69 can be disclosed to a single verifier securely.
- How
- A prover computes the shared secret or key offset per BRC-69, encrypts it to the verifier's public key using BRC-2 with a BRC-43 protocol ID of either 'counterparty linkage revelation' or 'specific linkage revelation', and sends a JSON payload the verifier decrypts with their own private key.
What this lets you do
- Disclose a counterparty key linkage to one named verifier only
- Disclose a specific protocol-scoped key linkage without exposing the counterparty relationship
- Timestamp counterparty revelations so the moment of disclosure is provable
- Encrypt linkage payloads so interception reveals nothing
- Let a verifier decrypt and confirm a linkage is authentic
Written by claude-sonnet-5 from the specification text. Where the two differ, the original is correct.
Reference for an AI
Everything an assistant needs to answer questions about BRC-72 accurately, including what it depends on.
The specification
Abstract
This BRC outlines additional security measures for the protection and controlled revelation of key linkage information as defined in BRC-69. This standard describes an approach for encrypting this sensitive data during communication, according to BRC-2. The intent is to ensure that only approved parties are capable of decrypting and accessing this information, thereby maintaining privacy and security.
Motivation
Providers of key linkages, as defined in BRC-69, need a secure way to disclose this information to a particular verifier. The information, although intended for verification, is highly sensitive and could infringe on privacy and security if mishandled. Therefore, a standard way to protect and communicate it is required. This proposal allows provers to reveal linkage information intentionally and securely, minimizing the risk of breaches.
Specification
Counterparty Revelation Payload
A counterparty-revelation payload emphasizes encryption using the BRC-2 standard. The protocol ID in this context is counterparty linkage revelation with security level 2. The key ID comprises the current timestamp and serves to indicate the precise moment when the prover revealed the linkage information to the verifier.
Encryption:
- Compute the root ECDH shared secret between user's identity key and a specified counterparty's key as per BRC-69 (method 1).
- The prover's BRC-43 encryption protocol is
counterparty linkage revelation, with a security level of2. The key ID is the current timestamps in ISO string format. - Encrypt the computed shared secret using the verifier's public key with BRC-2.
Decryption:
- An entity receives the encrypted linkage counterparty revelation payload.
- The entity decrypts the payload by using their private key with the prover's public key and the protocol ID and key ID specified.
Payload Fields
| Field | Type | Description |
|---|---|---|
| type | String | Indicates the type of payload, will be 'counterparty-revelation' for this payload. |
| prover | String (hex) | Public identity key of the entity revealing the key linkage. |
| verifier | String (hex) | Public identity key of the entity performing verification. |
| counterparty | String (hex) | Public identity key of the counterparty in question. |
| revelationTime | String (ISO Time) | Timestamp of when the linkage is revealed. |
| encryptedLinkage | String (base64) | The encrypted root shared secret computed between the prover's identity key and the counterparty's key. |
Specific Revelation Payload
The specific-revelation payload involves encrypting the linkage information using BRC-2. The protocol ID incorporates the base specific linkage revelation, and incorporates the security level and protocol ID used within the specific linkage being revealed. The key ID equals the key ID of the disclosed specific linkage.
Encryption:
- Compute the child key offset with respect to specific BRC-43 protocol ID, key ID, and specified counterparty using BRC-69 (method 2).
- The prover's BRC-43 encryption protocol is
specific linkage revelation <s> <p>, with a security level of2, where<s>is the security level of the specific linkage protocol and<p>is its protocol ID. The key ID equals the key ID of the revealed specific linkage. - Encrypt the computed key offset using the verifier's public key.
Decryption:
- An entity receives the encrypted specific revelation payload.
- The entity decrypts the payload by using their private key with the prover's public key and the protocol ID and key ID specified.
Payload Fields
| Field | Type | Description |
|---|---|---|
| type | String | Indicates the type of payload, will be 'specific-revelation' for this payload. |
| prover | String (hex) | Public identity key of the entity revealing the key linkage. |
| verifier | String (hex) | Public identity key of the entity performing verification. |
| counterparty | String (hex) | Public identity key of the counterparty in question. |
| protocolID | Array | BRC-43 protocol ID for the specific linkage in question. It is defined as an array where first element is the security level and second element is the protocol string. |
| keyID | String | A string that specifies the key ID for the specific linkage in question. |
| encryptedLinkage | String (base64) | The encrypted key offset computed for the specific BRC-43 protocol ID, key ID, and specified counterparty. |
Examples
Example Counterparty Revelation Payload:
{
type: 'counterparty-revelation',
prover: '03a0ce1bba254b3a844ea93ba080efe45e7224cd4aca041310fe0df7386947a0e1',
verifier: '021fd9ef7157080d3aee10aa0e342e45dae60cf1f35d31fb017d7f68033ae88822',
counterparty: '029da2905137abddf91e374f8bcadc4a4b559288b5e66f22ef37a6efd492f6f03e',
revelationTime: '2023-09-06T20:49:45.611Z',
encryptedLinkage: 'VlZKv4URE3gfjTHXttvOKpH7LRXRCjJn/F0WKVfFSdxnbxZXFaaDmRDb3Rn/HrPvFAlvQL7j8N+IF0pVi4bIPSgL0XgXgzagio/9Jj2UO+kS'
}
Example Specific Revelation Payload:
{
type: 'specific-revelation',
prover: '03a0ce1bba254b3a844ea93ba080efe45e7224cd4aca041310fe0df7386947a0e1',
verifier: '021fd9ef7157080d3aee10aa0e342e45dae60cf1f35d31fb017d7f68033ae88822',
counterparty: '029da2905137abddf91e374f8bcadc4a4b559288b5e66f22ef37a6efd492f6f03e',
protocolID: [ 2, 'social' ],
keyID: '4',
encryptedLinkage: 'zRd37/OOijnwE/cIbqVaskN0XJTW31/K3ngincbi2AXfkIsLD/VoxzQjfHO6GSpOd1shKK9nIeg4+vvQtUqZLp11YTO/941bnUr/uq6J/Ik='
}
In each of the two above examples, the verifier's private key is c1a97bde329903b2035a870955b570f9f795e372af8a3e0fee78534157a7af18.
You should be able to successfully verify that the keys linked between the prover and the prover's counterparty are authentic.
Implementation
Entities implementing this standard should consider privacy and security as critical. When creating a revelation payload, it is crucial to use precise protocol IDs and key IDs that correspond to the linkage being revealed. The use of accurate timestamps as key IDs in counterparty revelations is vital to document the exact time of the revelation. Entities should design their systems to handle these payloads correctly, ensuring the decryption process is secure. They should also ensure received payloads are legitimate by verifying accurate key linkages. If it is necessary to store linkage information, it should always be stored in an encrypted manner, away from less sensitive data.