1 of 26

When a Man-in-the-Middle tries crashing the live streaming party, the C2PA bouncer steps in

Roberto Ramos-Chavez, Mohamad Raad, Adam Goldberg, Arjen Wagenaar

Unified Streaming

February 2-4, 2026

The Cable Center, Denver, CO

2 of 26

Background and objective

C2PA manifests are signed documents that provide provenance and authenticity of media.
Mostly targeted towards non-live content (VOD, images, etc.)
Live content (streaming) is extremely important in many use cases.

News, sports, and similar.
Security cameras feeds 24/7.
Identifying if viewers are watching unaltered content to preserve trust.

C2PA manifests can become quite large in some cases (e.g., many ingredients, many assertions, etc.)
How can we carry C2PA metadata without requiring the full manifest in each media segment? How can we validate if the content has been tampered by a Man-in-the-Middle (MITM)?

We present a proof of concept demonstrating the C2PA live video standardization activity.

2

3 of 26

Generation and Validation of C2PA Metadata

3

C2PA metadata generation

C2PA metadata validation

4 of 26

Live C2PA Framework: �Use Cases and Requirements

The solution must support generating and consuming C2PA metadata in real-time.
Live media presentation with C2PA metadata must be suitable for validation and playback on a broad range of devices.
The delivery at scale of a media presentation must enable an efficient HTTP caching mechanism.
The solution must support detection of a Man-in-the-Middle (MITM) manipulation of the media.

4

5 of 26

Validation of C2PA metadata

5

6 of 26

Validation requirements of C2PA metadata - MITM in a live stream

Use cases and requirements

The MITM must support replacing C2PA metadata and emulating rebroadcast of the stream.
The MITM must support switching media segments sequences to provide an alternate narrative to the live stream.

Content replacement
Alternate narrative
Signature stripping
C2PA Manifest replacement

6

7 of 26

7

THE BOUNCER

8 of 26

8

9 of 26

9

10 of 26

Core concepts

Previously, C2PA content had to be pre-authored (signatures applied on the whole media asset)
C2PA Live Task Force has been exploring alternatives mechanisms for binding provenance metadata to live streaming.
The C2PA information can be carried in an event stream.
The C2PA manifest does not need to be included in the media segment, instead short-lived session keys are used.
C2PA verification steps can be used to trace which media content is consumed and by whom.

10

11 of 26

Taking a step back: C2PA and Manifests

Developed by the Coalition for Content Provenance and Authenticity
C2PA publishes three specifications

“Content credentials” Our focus
“Attestations”
"Soft binding API"

Attestations to convey trusted data, used to signal create or modify content.
The content credentials specification is a “live” spec.
C2PA v2.3 is at https://c2pa.org/specifications/specifications/2.3/index.html

11

So just to take a step back and explain a little bit about what C2PA is and what the manifests are. As I mentioned this specification has been developed by what's known as the Coalition for Content provenance and authenticity. They have actually two main specifications: content credentials and attestations. Attestations are focused on the reliability of the software that has been used to produce content. Our focus is in content credentials.

There's a third spec that's actually now being developed and sometimes you'll see it on the C2A website. but again that's not our concern for this particular work. it's important to keep in mind that this specification is actually a live spec. At the moment it's version 2.2. So content credentials is at version 2.2 and C2PA has a lot of task forces working on expanding the specification for different use cases. what a C2PA manifest is that it basically enables the manifestation of the trust model between media consumers, signers and credential issuers.

A C2PA manifest enables interaction between media consumers, signers, credential issuers and validators

The actors in the assumed trust model

12 of 26

Manifest structure

Assertions 🡪 state what has been done to the content or provide information about the data. These can be grouped together into an assertion store.
Claims 🡪 made on a group of assertions at a given time
Claim signature 🡪 the signature applied to the claim.
Additional data 🡪 a data box that can be used to add extra data.
A manifest is packaged in a JUMBF box
Manifests can be grouped together into manifest stores
Assertions are specified to be CBOR [RFC8949] objects.

12

- And the way that it does that is by a simple data structure that's really made up of four key parts.

1.- Assertions which basically state of what has been done, as in for example media has been created, media has been transcoded, media has been encoded etc. That's an assertion.

2.- Then there are claims which basically may are made against assertions as in these specific actions or assertions are claimed by this party.

3.- And then there's the claim signature of course to identify that party and whether or not it's trusted.

4.- There's a fourth part which is the additional data part now which basically means you could more or less put any piece of data that you want into a manifest.

- A manifest is actually a JUMBF box. So it's actually a JPEG universal u metadata box. - Importantly manifests can be grouped into a group of manifests called the manifest store. And the reason why that's in the specification is because you can actually have a complete history for your media. it's important to know that really the most recent manifest is the active manifest. That's the manifest that you validate against.

- That's the only manifest that you have a binding to the received media. All the previous manifests are there as a history as a record of what's actually happened for you to reach the current point.

- Now assertions are CBORG objects. So that's what the C2PA manifest is.

-- That's what we really want to get across from the source to the player.

13 of 26

What is a DASH event?

if (version==0) {
string scheme_id_uri;
string value;
unsigned int(32) timescale;
unsigned int(32) presentation_time_delta;
unsigned int(32) event_duration;
unsigned int(32) id;
} unsigned int(8) message_data[];

13

if (version==1) {
unsigned int(32) timescale;
unsigned int(64) presentation_time;
unsigned int(32) event_duration;
unsigned int(32) id;
string scheme_id_uri;
string value;
} unsigned int(8) message_data[];

A DASH event has two versions - Unified uses both but sends out version 0 for enhanced interoperability:
We use in-band events

14 of 26

Framework overview

14

Sec. 4

Sec. 4.2

Sec. 5

Sec. 3

Sec. 3.3.4

15 of 26

Two Methods for C2PA Live Video Streaming

2. Verifiable segment Info method:

Binds the C2PA manifest to initialization segment.
Uses Session Keys to bind the C2PA manifest to each media segment.
Reduces duplication of the C2PA metadata and provenance information in the live stream.
No overhead of embedding full C2PA manifest in each segment.

1. Per-segment C2PA Manifest method:

A C2PA manifest is bounded to each media segment.
This also means that each bitrate quality has its own C2PA manifest -- Highly granular.
Duplication of metadata and provenance information. For instance, the root certificate, assertions, ingredients, etc.

15

Bitrate

Time

C2PA Manifest

Seg 1

Seg 2

Seg N

…

Init. seg

C2PA Manifest

Bitrate

Time

COSE_Sign1

Seg 1

Seg 2

Seg N

…

Init. seg

16 of 26

Verifiable segment info method - Init. segment

keys: An array of one or more session key objects.
key: A COSE key
minSequenceNumber
createdAt
validityPeriod
signerBinding

16

https://spec.c2pa.org/specifications/specifications/2.3/specs/C2PA_Specification.html#_session_keys

{

"label": "c2pa.session-keys",

"kind": "Cbor",

"data": {

"keys": [

{

"key": {

1: 2, / kty: EC2 /

2: h'6b65795f303031', / kid: "key_001" /

-1: 1, / crv: P-256 /

-2: h'18b4ca7f19bb7ad4e8e5e28a8c9a7fb8e0bb5e5c9e5b8e5d7f4c8a9b7c6d5e4f3', / x /

-3: h'1a2b3c4d5e6f708192a3b4c5d6e7f8091a2b3c4d5e6f708192a3b4c5d6e7f809' / y /

},

"minSequenceNumber": 175,

"createdAt": 0("2025-07-29T10:00:00Z"),

"validityPeriod": 3900,

"signerBinding": 18([

/ protected / h'a10126',

/ unprotected / {},

/ payload / h'',

/ signature / h'3046022100abcd...'

])

}

]

}

Example using one single key

Session Keys structure:

17 of 26

Verifiable segment info method [1] - Media segments

emsg box:

version set to 0
scheme_id_uri: urn:c2pa:verifiable-segment-info
value: “fseg”
presentation_time_delta: 0
timescale
event_duration
message_data:

COSE_Sign1_Tagged [2] generation:

sequenceNumber
manifestId
bmffHash
manifestUri (optional)

17

[1] https://spec.c2pa.org/specifications/specifications/2.3/specs/C2PA_Specification.html#verifiable_segment_info

[2] https://datatracker.ietf.org/doc/html/rfc8152

Payload

18 of 26

Framework Evaluation (Sec. 5.2)

Test content:

5 video AVC1 CMAF Tracks

Bitrate ladder [KB]: 400, 750, 1000, 1500, 2200

Media segment duration: 48/25 = 1.92 seconds
Output format: DASH

Test environment

MacBook Pro (Apple M1 Pro, 10 cores, 16 GB RAM).
Containerized environment configured with 10 vCPUs and 12 GB RAM (2 GB swap).

18

19 of 26

Framework Evaluation (Sec. 5.2)

Avg. size of media segment using Per-segment method (blue) and Session keys method (purple)

Avg. MPD size and initialization segment size per bitrate.

19

C2PA Manifest avg. size in segment:

Per media segment method: 20 KB
Session Keys method: (700 B + 1.3 KB of \0x00 padding) = 2KB

Total size, including media data �and provenance data

20 of 26

Content size Evaluation Costs

20

Example scenario - Super Bowl-like events

CDN Cost Tier (Enterprise)

Concurrent Viewers	30M	CDN Pricing Options:
Event Duration (hours)	3	Pay-as-you-go ($/GB)	$0.080
Avg. Data per Viewer (GB)	4.5	Enterprise ($/GB)	$0.010
Number of renditions	5

Metric	Session Keys (2 KB)	Per Segment Manifest (20 KB)	Difference	% Decrease (20KB ->2KB)
C2PA per Segment (KB)	2	20	18	90.0%
Segments per Viewer	5,625	5,625	0
Total C2PA Data (PB)	1.5	15.7	14.1	90.0%
C2PA % of Total Bandwidth	1.16%	11.64%	10.48%	90.0%
Additional CDN Cost	$15,716	$157,160	$141,444	90.0%

21 of 26

C2PA Content Validation (Sec. 4.2)- dash.js v4.7.4

21

Initialization segment

Receives initialization segment blob before it goes into the media buffer.

Extracts JUMBF box (manifest store) from init. segment.

Reads and validates the manifest store using c2pa-js.

Update UI/UX based on C2PA manifest metadata: valid or invalid

Media segment

Receives media segment blob before it goes into the media buffer.

Extract session keys from C2PA manifest and matches KID

Extract COSE_Sign1 from emsg and compute COSE_Sign1 structure for validation

Update UI/UX based on COSE_Sign1 signature: valid or invalid

Note: Player keeps a state of the sequence number to identify if media segments have been swapped by a MITM.

Implemented a dash.js v4.7.4 plugin using c2pa-js and c2pa-rs.
Based on dash.js implementation by Content Authenticity Initiative.

https://github.com/contentauth/c2pa-js

https://github.com/contentauth/c2pa-rs

https://github.com/contentauth/dash.js/tree/c2pa-dash/samples/c2pa

22 of 26

C2PA Content Validation (Sec. 4.2)- dash.js v4.7.4

22

Initialization segment

Receives initialization segment blob before it goes into the media buffer.

Extracts JUMBF box (manifest store) from init. segment.

Reads and validates the manifest store using c2pa-js.

Update UI/UX based on C2PA manifest metadata: valid or invalid

Media segment

Receives media segment blob before it goes into the media buffer.

Extract session keys from C2PA manifest and matches KID

Extract COSE_Sign1 from emsg and compute COSE_Sign1 structure for validation

Update UI/UX based on COSE_Sign1 signature: valid or invalid

DEMO: https://demo.unified-streaming.com/k8s/vod2live-c2pa/stable/sessions.html

Note: Player keeps a state of the sequence number to identify if media segments have been swapped by a MITM.

23 of 26

Observations and assessment

We demonstrated that a ~90% decrease in bandwidth overhead using Verifiable Segment method (Session keys) instead of including a C2PA manifest in each media segment like the Per Segment method.
The current PoC we used 2KB for emsg.message_data in the Verifiable Segment method (Sessions keys) but this can be decreased to ~ 700 Bytes for even more bandwidth savings.

The MITM framework helps verifying the C2PA live specification based on different use cases covered.
Using the Verifiable segment (Session keys) method is cache friendly.

23

24 of 26

Concluding remarks and next steps

We presented a framework for deploying C2PA in live streaming using Verifiable Segment Method (Session keys).
We presented the C2PA Generator framework using a HTTP Proxy for modifying media requests from the Origin.
We presented the C2PA Validator using a customized dash.js plugin to identify if the live stream has been tampered with.
Verifiable segment info method can provide live stream workflows with minimal overhead and without sacrificing scalability.

Provenance information provided on a segment on a segment basis.
Allows for encrypted media to be validate without decryption.
Does not require update to encoder (e.g., new SEI messages).

Next steps:

Improve robustness of C2PA Validator in dash.js and other media players
Where can the provenance information stop in the media chain? For instance, a Broadcaster trying to protect a journalist's information.
Some specifications/regulations may require a specific percentage of valid segments.

24

25 of 26

Thanks

25

To add an image click on the icon or drag an image from your files to this slide.

If you want to change the image in terms of position or cropping click with the right mouse button on the image and click Crop Image. Use the spheres at the edges of the image to adjust the image.

If any text disappears after adding an image, right click on the image and select Move to background.

Add image

26 of 26

26

Get in contact?

Email me -> roberto@unified-streaming.com