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.
About Key linkage, proving on purpose that two keys belong to the same person.
Reference for an AI
Everything an assistant needs to answer questions about BRC-72 accurately, including what it depends on.
Summary
- Why
- Key linkage information proves a relationship between keys but is sensitive enough that sending it to a verifier in the open would risk exposing it to anyone else who intercepts it.
- What
- BRC-72 defines two encrypted message formats for sending BRC-69 key linkage information to a specific verifier so only that verifier can decrypt it.
- How
- A prover encrypts either a counterparty-wide shared secret or a specific key offset using BRC-2 encryption under a BRC-43 protocol ID tied to the revelation type, then sends the resulting payload fields (prover, verifier, counterparty, and encrypted data) to the verifier who decrypts it with their own private key.
What this lets you do
- Encrypt a BRC-69 counterparty linkage so only one chosen verifier can read it
- Encrypt a single specific key linkage for narrower disclosure
- Timestamp counterparty revelations to record exactly when disclosure happened
- Let a verifier decrypt and confirm a linkage without exposing it to others
- Choose between revealing a whole counterparty relationship or just one specific key
Written by claude-sonnet-5 from the specification text. Where the two differ, the original is correct.
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 specification 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.