SA-021 E2EE/Noise Protocol Key Negotiation Analysis Report

**Agent ID:** SA-021 **Date:** 2025-12-30 **Status:** Completed **Grade:** B

Mission

Trace E2EE/Noise protocol key negotiation for audio encryption in the Facebook iOS application.

**Target Binary:** `./analysis/facebook/345.0/Facebook.app/Frameworks/FBSharedFramework.framework/FBSharedFramework`

**Additional Target:** `FBMessagingFramework.framework` (RTC stack)

Executive Summary

The Facebook iOS app implements a multi-layer encryption architecture for real-time audio/video calls:

undefined

The Noise protocol implementation appears to be in the native C++ layer (referenced as `__RS*` structures), not exposed in Objective-C headers.

Key Findings

1. E2EE Call Model Properties

Found in `FBWebRTCCallModel` (`FBMessagingFramework.framework`):

**Methods that set E2EE state:**

-[FBWebRTCEngine startIncomingConferenceCall:callId:ringType:peerUserIds:callerUserId:dataMessages:stateSyncInitialData:userProfiles:isE2eeMandatedCall:collisionContextData:onSuccess:onError:]

-[FBWebRTCEngine startConferenceCallWithName:localCallId:ringingUsers:initialMediaState:callTrigger:includeRingeesInPeerList:dataMessages:stateSyncInitialData:collisionKey:analyticsExtra:callConfiguration:isE2EEMandated:error:]

2. E2EE Model Update Flow

The E2EE state is propagated through the call stack via callbacks:

[Native C++ Layer]
    |
    v
[FBWebRTCEngine onCryptoE2eeModelUpdated:]
    |
    v
[FBWebRTCEngineListenerAnnouncer callUpdatedE2eeModel:]
    |
    v
[Multiple listeners implement callUpdatedE2eeModel:]
    - FBFacecastWithGuestFBWebRTCEngine
    - FBVideoBroadcastWebRTCSession
    - FBWebRTCCallStateLogWriter
    - FBWebRTCRingtoneManager

3. Crypto Proxy Architecture

The `RSCallClientDelegate` protocol exposes a crypto proxy:

@protocol RSCallClientDelegate <NSObject>
-[RSCallClientDelegate rsCallClientGetCryptoProxy];
// ... other media proxies
@end

@interface RIBRTCCallClient : NSObject <RSCallClientDelegate>
-[RIBRTCCallClient rsCallClientGetCryptoProxy];
@end

This crypto proxy is the bridge to the native encryption layer but its implementation is in C++ (`^{__RS*}` pointer types).

4. DTLS Configuration

DTLS (Datagram Transport Layer Security) is configurable via `FBWebRTCCallConfig`:

-[FBWebRTCCallConfig setNetworkingConfigShouldOfferDtls:]

DTLS handles the transport-layer encryption and certificate exchange for WebRTC connections.

5. Media Encryption Keys

Found in `MNSecureOutgoingAttachmentContent`:

**Factory Methods:**

+[MNSecureOutgoingAttachmentContent audioWithAudioEncryptionKey:audio:]
+[MNSecureOutgoingAttachmentContent videoWithVideoEncryptionKey:video:]
+[MNSecureOutgoingAttachmentContent imagesWithEncryptionKey:photos:]

6. Native RTC Infrastructure

The RTC stack uses native C++ classes exposed via opaque pointers:

7. Signaling Transport

Call signaling uses MQTT through:

@interface RIBRSSignaling : NSObject <RIBMQTTNotificationListener>
    ^{__RSSignalingTransportProxy} _signalingTransport;
    ^{__RSSignalingTransportSink} _transportSink;
@end

@interface RIBMQTTChannel : NSObject <RIBRSSignalingDelegate>
    ^{__RTChannel} _rtChannel;
    ^{_RTMQTTBridge} _mqttBridge;
@end

8. Connection to SA-006 Findings

From SA-006 Key Derivation report, the encryption uses:

undefined

**Key Derivation Flow:**

[Session Master Key]
        |
        v
[walibra_hkdf_info (HKDF)]
        |
        v
[Frame-specific Key]
        |
        v
[AES-256-GCM Encrypt/Decrypt]

Noise Protocol Analysis

Expectation vs Reality

**Expected:** Explicit Noise protocol handshake classes (e.g., `NoiseHandshake`, `NoiseSession`, `NoiseCipherState`)

**Found:** The Noise protocol implementation appears to be:

undefined

The "Noise" references found in class dump (`FBCrowdNoise*`) are unrelated - they are UI effects for live streaming audience reactions, not cryptographic protocols.

Evidence of Noise Protocol

Indirect evidence suggests Noise protocol usage:

undefined

Key Negotiation Sequence (Inferred)

Based on class analysis:

1. Call Initiation
   [FBWebRTCEngine startConferenceCallWithName:... isE2EEMandated:]

2. MQTT Signaling
   [RIBRSSignaling handleNotificationForTopic:andData:andSource:]

3. DTLS Handshake (Transport Layer)
   [FBWebRTCCallConfig setNetworkingConfigShouldOfferDtls:YES]

4. Crypto Proxy Setup
   [RIBRTCCallClient rsCallClientGetCryptoProxy]

5. E2EE Session Established
   [FBWebRTCEngine onCryptoE2eeModelUpdated:]

6. Frame Encryption Active
   [walibra_hkdf_info + AES-256-GCM per frame]

7. E2EE State Broadcast
   [callUpdatedE2eeModel:] -> all listeners

Session Key Lifecycle

SRTP Analysis

**Finding:** No explicit SRTP classes found in Objective-C layer.

SRTP (Secure Real-time Transport Protocol) is likely:

undefined

DTLS Analysis

DTLS integration confirmed via:

undefined

DTLS handles:

undefined

Connection to audioEncryptionKey

The `audioEncryptionKey` in `MNSecureOutgoingAttachmentContent` is used for:

undefined

Real-time call audio encryption:

E2EE Session Key -> HKDF Expansion -> Per-Frame Key -> AES-256-GCM

Attachment audio encryption:

Generated audioEncryptionKey -> AES encryption of audio blob

Critical Blockers

undefined

Evidence Quality

Technical Artifacts

Key Classes

Key Methods

Recommendations for Further Investigation

undefined

Impact on H3 Decoding

**Contribution to H3 Investigation:** Moderate

This analysis confirms:

undefined

**Blockers for audio decryption:**

undefined

*SA-021 E2EE/Noise Protocol Analysis - Generated 2025-12-30*