Scope
This guide explains auditable continuous group key agreement (Au-CGKA), an extension to Messaging Layer Security that supports audit capabilities while preserving Point-to-Point Encryption (P2PE). It's aimed at payment security engineers assessing secure messaging systems in regulated environments where encryption and audit recovery are both required.
You'll find implementation tips, cryptographic requirement details, and operational guidance for systems that need to meet PCI DSS encryption standards and regulatory audit obligations.
Key Concepts
Continuous Group Key Agreement (CGKA): The key management core of MLS (RFC 9420) that refreshes encryption keys as group membership changes. Standard CGKA doesn't allow auditors to recover past epoch keys.
Epoch: A distinct period in a group's lifecycle, marked by membership changes or key refreshes. Each epoch uses unique key material.
Threshold Recovery: A cryptographic method requiring multiple auditor committee members to cooperate to recover escrowed key material. Based on Shamir's Secret Sharing, it prevents unilateral access.
STARK Proofs: Scalable Transparent Arguments of Knowledge, a zero-knowledge proof system resistant to quantum computing attacks. In Au-CGKA, STARK proofs show that escrowed material is correctly formed without revealing secrets.
Silent Escrow Failure: The risk that a group accepts an epoch with unrecoverable or malformed escrow material, undetected until audit time.
Requirements Breakdown
What Au-CGKA Guarantees
Binding Verification: Each epoch admitted to the group includes a cryptographic proof binding that epoch's key material to recoverable escrow material. Members verify this before accepting the commit.
Threshold Auditability: Epoch secrets are recoverable only by a designated auditor committee meeting a defined threshold. No single auditor can access keys alone.
Post-Quantum Security: The protocol uses STARK-friendly encryption with adaptive security in the quantum random-oracle model, addressing future quantum computing threats.
Admission-Time Detection: If escrow material is malformed or unrecoverable, honest members detect the failure at epoch admission and reject the commit, preventing silent failures.
Performance Characteristics
Based on tests on an Apple M5 Pro:
- Proof generation: 1.38 seconds per epoch
- Proof size: 15.31 MB per commit
- Verification time: 0.17 seconds per member
- Scaling: Performance remains constant regardless of group size
The proof is verified at admission and discarded, so storage overhead is limited to the fixed-size escrow ciphertext.
Implementation Guidance
When to Deploy Au-CGKA
Consider deploying if:
- Your organization must provide audit access to historical communications (e.g., FFIEC IT Examination Handbook guidance, certain AML Directives interpretations).
- You currently log plaintext messages server-side to meet audit requirements.
- You need to show that encryption keys are recoverable without actually recovering them during normal operations.
- Your threat model includes quantum computing advances within your data retention period.
Integration Points
Commit Processing: Modify your MLS commit handler to verify the auditability proof before accepting an epoch. Handle proof verification failures distinctly from other commit rejections.
Auditor Committee Setup: Establish threshold parameters and distribute shares to committee members. Document the recovery procedure in your incident response plan.
Bandwidth Planning: Each commit carries an additional 15.31 MB proof. For groups with frequent membership changes, calculate the bandwidth impact: a 100-member group with daily joins/leaves generates about 450 MB monthly in proof traffic.
Key Ceremony: The auditor committee's threshold keys require generation, distribution, and lifecycle management similar to Key Encryption Keys (KEKs). Apply FIPS 140-3 requirements if you're subject to federal cryptographic standards.
Operational Considerations
Proof Verification Failures: Define escalation procedures when a member's client rejects a commit due to proof verification failure. This indicates a potential security event, not a network error.
Auditor Key Rotation: Plan for threshold key rotation without disrupting ongoing group operations. Re-escrow existing epoch secrets to new committee keys.
Compliance Documentation: Map the protocol's guarantees to specific regulatory requirements. For example, if demonstrating compliance with audit provisions in Payment Services Directive 2, document how threshold recovery satisfies "appropriate access" requirements.
Common Pitfalls
Treating Proofs as Optional: If any client accepts epochs without verifying the auditability proof, you've created a silent failure path. Enforce verification in client code.
Underestimating Bandwidth Impact: The 15.31 MB proof size is fixed per commit, not per member. In high-churn groups, this can dominate bandwidth usage.
Conflating Auditability with Surveillance: Au-CGKA provides threshold-recoverable keys for past epochs, not real-time message access. If your compliance requirement is live monitoring, this protocol doesn't meet it.
Ignoring Threshold Committee Availability: If your threshold is set too high, auditor unavailability during an incident prevents recovery. If it's too low, you've reduced the security benefit of threshold escrow.
Assuming Backward Compatibility: Au-CGKA clients can't interoperate with standard MLS clients in the same group. Migration requires coordinated upgrades or separate group creation.
Quick Reference
| Component | Specification | Notes |
|---|---|---|
| Base Protocol | MLS (RFC 9420) | Au-CGKA extends but doesn't replace MLS |
| Proof System | STARK (post-quantum) | Quantum-resistant zero-knowledge proofs |
| Escrow Method | STARK-friendly encryption of Shamir shares | Threshold recovery, not single-party access |
| Proof Generation Time | 1.38 seconds | Constant across group sizes |
| Proof Verification Time | 0.17 seconds | Per member, at commit admission |
| Proof Size | 15.31 MB | Transmitted with commit, then discarded |
| Security Model | Secure-erasure, quantum random-oracle | Adaptive post-quantum guarantees |
| Persistent Overhead | Fixed-size escrow ciphertext only | Proofs aren't stored after verification |
| Compliance Application | FFIEC guidance, AML Directives, PSD2 | Where audit access is mandatory |
When to Verify: Every member must verify the auditability proof before accepting an epoch commit. Verification happens client-side.
Recovery Procedure: The threshold auditor committee reconstructs epoch secrets from escrowed shares. Document this in your incident response plan with specific role assignments.
