Protecting BRC-69 Key Linkage Information in Transit

Ty Everett ([e-mail])

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:

1. Compute the root ECDH shared secret between user's identity key and a specified counterparty's key as per BRC-69 (method 1).

2. The prover's BRC-43 encryption protocol is counterparty linkage revelation, with a security level of 2. The key ID is the current timestamps in ISO string format.

3. Encrypt the computed shared secret using the verifier's public key with BRC-2.

Decryption:

1. An entity receives the encrypted linkage counterparty revelation payload.

2. 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:

1. Compute the child key offset with respect to specific BRC-43 protocol ID, key ID, and specified counterparty using BRC-69 (method 2).

2. The prover's BRC-43 encryption protocol is specific linkage revelation <s> <p>, with a security level of 2, 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.

3. Encrypt the computed key offset using the verifier's public key.

Decryption:

1. An entity receives the encrypted specific revelation payload.

2. 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.