Skip to main content

Threat Model - MLS Implementation

Overview​

Comprehensive threat model analyzing adversary capabilities, attack surfaces, and security properties of the MLS implementation.

Adversary Model​

1. Passive Network Adversary​

Capabilities:

  • Monitor all network traffic
  • Read message metadata (size, timing, destination)
  • Perform traffic analysis
  • Cannot modify or inject messages

Protection Status:

  • ✅ Protected: Cannot decrypt messages (AES-128-GCM)
  • ✅ Protected: Cannot derive session keys (X25519 ECDH)
  • ✅ Protected: Forward secrecy prevents past message decryption
  • ✅ Protected: Cannot identify message content
  • ⚠️ Vulnerable: Can perform traffic analysis (metadata visible)
  • ⚠️ Vulnerable: Can identify group membership (Welcome messages)
  • ⚠️ Vulnerable: Can track group size changes (commit patterns)

Risk Level: 🟢 LOW - Core confidentiality protected

2. Active Network Adversary​

Capabilities:

  • All passive capabilities
  • Modify messages in transit
  • Inject malicious messages
  • Drop or delay messages
  • Perform man-in-the-middle attacks

Protection Status:

  • ✅ Protected: Cannot forge signatures (Ed25519)
  • ✅ Protected: Cannot modify messages (AEAD integrity)
  • ✅ Protected: MITM prevented by credential binding
  • ❌ Vulnerable: Can replay old messages (no timestamp validation)
  • ❌ Vulnerable: Can inject malformed messages (no input validation)
  • ❌ Vulnerable: Can perform DoS (no size limits)
  • ❌ Vulnerable: Can cause epoch desynchronization (drop commits)

Risk Level: 🔴 HIGH - Multiple active attack vectors

3. Malicious Group Member​

Capabilities:

  • Valid member with legitimate credentials
  • Can send messages to group
  • Can see all group messages
  • Can propose group changes
  • May have past message history

Protection Status:

  • ✅ Protected: Cannot decrypt past messages (forward secrecy)
  • ✅ Protected: Cannot decrypt future messages after removal (key rotation)
  • ✅ Protected: Cannot impersonate other members (signatures)
  • ✅ Protected: Cannot create fake members (credential validation)
  • ⚠️ Vulnerable: Can inject malicious key packages (no validation)
  • ❌ Vulnerable: Can cause DoS (massive messages, no rate limiting)
  • ❌ Vulnerable: Can attempt epoch rollback (no epoch validation)

Risk Level: 🟠 MEDIUM - Limited attack surface due to cryptographic protections

4. Compromised Endpoint​

Capabilities:

  • Full access to device memory
  • Read current session keys
  • Read plaintext messages
  • Read private keys
  • Cannot access other devices

Protection Status:

  • ✅ Protected: Past messages safe (forward secrecy)
  • ✅ Protected: Future messages recover (post-compromise security after key rotation)
  • ❌ No Protection: Current epoch messages (expected behavior)
  • ❌ No Protection: Private keys in memory (JavaScript limitation)
  • ⚠️ Vulnerable: Debug logs may expose additional information
  • ⚠️ Vulnerable: Browser console may cache secrets

Risk Level: 🟡 MEDIUM - Inherent to any end-to-end encryption

5. Side-Channel Adversary​

Capabilities:

  • Measure timing of operations
  • Observe power consumption (local access)
  • Analyze cache behavior
  • Memory access patterns

Protection Status:

  • ⚠️ Partial: Timing variations exist (JavaScript limitation)
  • ✅ Protected: Crypto operations use constant-time libs (@noble)
  • ⚠️ Vulnerable: Error paths have different timing
  • ⚠️ Vulnerable: Success vs. failure timing differs
  • ⚠️ Vulnerable: Timing information in metadata
  • ⚠️ Partial: Cache timing depends on platform

Risk Level: 🟡 MEDIUM - Practical attacks are difficult but theoretically possible

Attack Surface Analysis​

External Input Points​

  1. processWelcome(welcome, ratchetTree)

    • ⚠️ Accepts arbitrary Welcome structure
    • ⚠️ Accepts arbitrary ratchet tree
    • Risk: DoS, type confusion, memory exhaustion

  2. addMembers(groupId, keyPackages)

    • ⚠️ Accepts arbitrary key packages
    • ⚠️ No signature verification at app level
    • Risk: Malicious member injection, DoS

  3. decryptMessage(envelope)

    • ⚠️ Accepts arbitrary message envelopes
    • ⚠️ No replay protection
    • Risk: Replay attacks, DoS

  4. processCommit(groupId, commit)

    • ⚠️ Accepts arbitrary commit structure
    • ⚠️ No epoch validation
    • Risk: Epoch rollback, type confusion

  5. mlsCodec decode functions

    • ⚠️ Accepts arbitrary JSON
    • ⚠️ No size limits
    • Risk: DoS, prototype pollution, type confusion

Total Attack Surface: 5 major input points, all vulnerable

Attack Scenarios & Mitigations​

Scenario 1: Message Replay Attack​

Attack:

  1. Attacker captures legitimate encrypted message
  2. Stores message for later replay
  3. Sends old message to victim after days/weeks
  4. Message is accepted and decrypted

Current Protection: ❌ None

Impact:

  • Bypass access controls
  • Replay old commands/actions
  • Confuse application state
  • Social engineering attacks

Mitigation:

  • Implement timestamp validation (24-hour window)
  • Track message IDs/nonces
  • Reject messages older than threshold

Severity: 🔴 HIGH

Scenario 2: Epoch Rollback Attack​

Attack:

  1. Attacker intercepts commit at epoch 10
  2. Crafts malicious commit with epoch 5
  3. Sends to victim
  4. If accepted: victim rolls back to compromised epoch

Current Protection: ❌ None (no epoch validation)

Impact:

  • Force use of old/compromised keys
  • Bypass security updates
  • Break forward secrecy
  • Group compromise

Mitigation:

  • Validate epoch = current + 1
  • Reject any epoch decrease
  • Track expected epoch per member

Severity: 🔴 CRITICAL

Scenario 3: DoS via Massive Welcome​

Attack:

  1. Attacker sends Welcome with 1GB encryptedGroupInfo
  2. Victim attempts to process
  3. Memory exhaustion
  4. Application crash

Current Protection: ❌ None (no size limits)

Impact:

  • Application unavailability
  • Resource exhaustion
  • Potential system crash

Mitigation:

  • Implement size limits (10MB max)
  • Validate before allocation
  • Rate limiting

Severity: 🔴 CRITICAL

Scenario 4: Type Confusion via mlsCodec​

Attack:

  1. Attacker crafts malicious key package
  2. Sets __type: 'Uint8Array' with string data
  3. Sends to victim
  4. Type confusion in new Uint8Array()

Current Protection: ❌ None (no type validation)

Impact:

  • Undefined behavior
  • Potential crash
  • Possible RCE (depending on ts-mls handling)

Mitigation:

  • Validate __type markers
  • Validate data is array
  • Validate array element types
  • Add recursion limits

Severity: 🔴 CRITICAL

Scenario 5: Information Disclosure via Console​

Attack:

  1. Attacker gains console access (malicious extension, XSS)
  2. Views console logs
  3. Observes commit objects, tree structure, error details
  4. Analyzes group topology and state

Current Protection: ❌ None (extensive debug logging)

Impact:

  • Group structure exposed
  • Implementation details revealed
  • Internal state leaked
  • Attack planning aided

Mitigation:

  • Remove all debug logging
  • Sanitize error messages
  • Disable console in production

Severity: 🟠 HIGH

Scenario 6: Inactive User Compromise​

Attack:

  1. Alice goes offline (vacation, device off)
  2. Attacker compromises Alice's old key material
  3. Group performs multiple key rotations
  4. Alice stays at old epoch (doesn't update)
  5. Attacker can still derive Alice's keys

Current Protection: 🟡 Partial (MLS provides PCS but requires participation)

Impact:

  • Compromised member remains vulnerable
  • Group security degraded
  • Attacker maintains access via inactive member

Mitigation:

  • Detect inactive members
  • Remove inactive members after threshold
  • Implement Quarantined-TreeKEM (2024 research)

Severity: 🟡 MEDIUM (industry-wide MLS limitation)

Scenario 7: Desynchronization Attack​

Attack:

  1. Alice, Bob, Charlie at epoch 5
  2. Alice sends commit (epoch 5→6) to Charlie
  3. Attacker drops commit to Bob
  4. Bob stays at epoch 5, Alice/Charlie at epoch 6
  5. Bob cannot decrypt future messages

Current Protection: ❌ None (no sync detection)

Impact:

  • Members permanently desynchronized
  • Communication breakdown
  • Denial of service
  • Requires group recreation

Mitigation:

  • Track expected epoch per member
  • Detect desynchronization
  • Implement resync protocol
  • Redundant commit distribution

Severity: 🟠 HIGH

Security Properties Matrix​

PropertyPassive NetActive NetMalicious MemberCompromised DeviceSide-Channel
Confidentiality✅ Protected✅ Protected✅ Protected❌ No Protection✅ Protected
Integrity✅ Protected✅ Protected✅ Protected❌ No Protection✅ Protected
Authentication✅ Protected✅ Protected✅ Protected❌ No Protection✅ Protected
Forward Secrecy✅ Protected✅ Protected✅ Protected✅ Protected✅ Protected
PCS✅ Protected✅ Protected🟡 Partial✅ Protected✅ Protected
DoS ResistanceN/A❌ Vulnerable❌ VulnerableN/A⚠️ Partial
Replay ProtectionN/A❌ Vulnerable❌ VulnerableN/AN/A
Privacy⚠️ Metadata⚠️ Metadata⚠️ Metadata❌ Full Access⚠️ Timing

Risk Assessment Summary​

By Adversary Type​

AdversaryRisk LevelPrimary ThreatsMitigations
Passive Network🟢 LOWTraffic analysisAccept (inherent)
Active Network🔴 HIGHReplay, DoS, desyncP0 fixes required
Malicious Member🟠 MEDIUMDoS, malicious dataInput validation
Compromised Device🟡 MEDIUMCurrent keysAccept (inherent)
Side-Channel🟡 MEDIUMTiming leaksMonitoring needed

By Attack Category​

Attack TypeLikelihoodImpactRiskPriority
Replay AttackHighHigh🔴 CRITICALP0
Epoch RollbackMediumCritical🔴 CRITICALP0
DoS (size)HighHigh🔴 CRITICALP0
Type ConfusionMediumCritical🔴 CRITICALP0
Info DisclosureHighMedium🟠 HIGHP0
DesynchronizationMediumHigh🟠 HIGHP1
Timing AttacksLowMedium🟡 MEDIUMP2

Defense in Depth​

Layer 1: Cryptographic (✅ STRONG)​

  • X25519 key exchange
  • Ed25519 signatures
  • AES-128-GCM encryption
  • HKDF key derivation
  • Platform CSRNG

Layer 2: Protocol (🟡 MODERATE)​

  • RFC 9420 compliant
  • Forward secrecy
  • Post-compromise security
  • TreeKEM structure
  • ⚠️ Missing: replay protection, epoch validation

Layer 3: Implementation (🔴 WEAK)​

  • ❌ No input validation
  • ❌ No size limits
  • ❌ Extensive debug logging
  • ❌ No error sanitization
  • ⚠️ JavaScript timing limitations

Layer 4: Operational (❌ MISSING)​

  • ❌ No rate limiting
  • ❌ No monitoring
  • ❌ No alerting
  • ❌ No audit logging
  • ❌ No incident response

Recommendations​

Critical (P0) - Address Before Deployment​

  1. Implement replay protection (timestamp validation)
  2. Add epoch validation (prevent rollback)
  3. Implement size limits (10MB messages, 20K nodes)
  4. Remove debug logging
  5. Add input validation for all external inputs

High (P1) - Within 1 Week​

  1. Add desynchronization detection
  2. Implement error sanitization
  3. Add sender validation for commits
  4. Implement rate limiting
  5. Add security monitoring

Medium (P2) - Within 1 Month​

  1. Consider timing attack mitigations
  2. Implement inactive user detection
  3. Add audit logging
  4. Create incident response procedures
  5. Perform penetration testing

Conclusion​

Overall Risk: 🔴 HIGH

The implementation has strong cryptographic foundations but weak operational security. Primary threats are from active network adversaries exploiting missing input validation and replay protection.

Key Findings:

  • ✅ Core cryptography is secure
  • ✅ Protocol design is sound
  • ❌ Implementation has critical gaps
  • ❌ No protection against active attacks
  • ❌ Extensive attack surface

Recommendation: DO NOT DEPLOY until P0 mitigations are implemented.