Messenger Security

Privacy in Messenger Applications

Two different architectures:

• In-transit Encryption
• End-to-end Encryption

E2EE Messaging

Challenges:

• What about offline parties?
• Group chats?

Cryptography Perspective:

• Signature keys for authenticity
• Ephemeral key exchange (EDH) ⇒ Perfect forward secrecy
• Encrypt messages with AES
• As seen in TLS, IPsec

Practically:

• Email with S/MIME, OpenPGP
• S/MIME over XMPP (RFC 6120, RFC 3923)
  • Problem: Usability
    • Sender needs certificate or public key of receiver

Desired Properties

Ideal Goal: Private Conversation, face-to-face in a private room

• Functionality
  • Asynchronous messaging
  • Efficient group messaging
    • multi-device support
• Security / Privacy:
  • Secure Channel
  • Perfect Forward Secrecy
    • Eve entering the room does not learn about past conversations.
  • Post-compromise security
    • Eve leaving the room does not learn about future conversations.
  • Maybe: Plausible deniability
    • Eve cannot prove that Alice talked to Bob

Messaging Layer Security (MLS) Protocol

• RFC 9420
• https://messaginglayersecurity.rocks/mls-architecture/draft-ietf-mls-architecture.html#name-overview-of-operation

Groups, Groups, Groups

• MLS is purpose-built for group communication
  • Target: Large groups with ~50’000 members!
  • E.g. Alice’s phone, computer, and Bob’s microwave

SC and SAs

Same as MACsec

Key Derivation

Same as MACsec

Protocol Stack

Epochs

Parties may enter or leave the group

• Ex-member should not be able to read messages
• New members should not read old messages

Secure Communication

• Hybrid Public Key Encryption (RFC 9180)
  • Key Generation:
    • Key Encapsulation Mechanism (KEM)
      • e.g. DH based
    • Key Derivation Function (KDF)
      • e.g. HMAC
• Encryption:
  • Authenticated Encryption
    • AES-GCM

Key Ratcheting

Solves: Forward Secrecy

• Idea: Evolve current key and delete old one
  • ⇒ Ephemeral Keys, ideally one per message
• (Too) simple idea: Hash chain (KDF)

Problem: Post Compromise Issue

Double Ratchet

Solves: Post Compromise Issue

• Combine KEM with KDF Ratchet
• Allows for offline messaging
  • Use KDF to evolve key

Scaling of Key Exchange

• Double ratchet built for two party setting
• Signal: Groups are just pairwise secure channels
  • Becomes inefficient for large (> 300) groups
• Solution: Tree based key structure
  • Ratchet the tree (starting at leaf)

Limitations of E2EE

Encryption Ends on the Device

• End device (phone, computer) contains all messages
  • Often unencrypted (if device is unlocked)
  • Spyware can exfiltrate them
    • E.g., Pegasus (NSO group)
• Backups of the end device contain the messages
  • Often not encrypted by default

Lawful Interception

With E2EE:

---

Relevant Note(s):