Skip to content

Video surveillance with end-to-end encryption

“As the co-owner and CEO of a company that itself provided cloud video surveillance services, I chose not to connect the cameras in the yard of my own country home to my company’s service.

I understood all too well that people with administrative access to the media servers could technically see what was happening at my home. I did not want anyone to have even the potential to watch my private life,” said Alexander Vasiliev, former CEO and co-owner of LANTA.

This experience gave rise to the idea of a system in which a cloud operator can store customers’ video without being able to watch it.

SesameDVR now makes this possible.

A small box next to the cameras

Encryption does not require replacing the cameras or waiting for a new RTSP standard.

A small Sesame Agent is installed on the home network. It only needs to be connected to an available LAN port on a router or switch.

The agent connects to the local cameras itself, receives their RTSP streams, encrypts the video, and only then sends it to SesameDVR.

All connections are established outbound from the home network, so there is no need to:

  • open inbound ports;
  • expose cameras to the internet;
  • give the cloud direct access to the local network;
  • change camera firmware.

The cameras themselves are effectively inaccessible to SesameDVR. The cloud receives only a stream that has already been encrypted.

The agent does not decode or transcode the video. It repackages the existing H.264 or H.265 stream, encrypts it, and sends it to the server. Its processor requirements are therefore significantly lower than those of a full video server performing transcoding.

Depending on the model, Sesame Agent can handle anywhere from 16 to several hundred cameras.

Actual performance depends on:

  • the cameras’ total bitrate;
  • the performance of the particular device;
  • the speed of its memory and network interfaces;
  • the bandwidth of the internet connection;
  • the encryption settings and system configuration.

How the keys work

The stream owner locally creates a cryptographic key pair on their own device:

  • a public key, which can encrypt data;
  • a private key, which can decrypt it.

The public key is uploaded to SesameDVR and passed to the agent. It can be used to encrypt data for the owner, but it cannot reverse the operation.

The private key remains solely with the owner. It is not created in SesameDVR, is not sent to the operator, and is not stored on the server.

Sesame Agent then periodically generates a random Content Encryption Key, or CEK.

This is the key that encrypts the video.

By default, a new CEK is created every hour, but the interval can be changed. Keys can be rotated much more frequently: the practical limit is mainly determined by the number of encrypted keys that must be stored with the archive.

Each new CEK is encrypted with the owner’s public key.

As a result, SesameDVR receives and stores:

  • encrypted video segments;
  • encrypted CEKs that protect those segments.

The plaintext CEK exists only in the agent’s RAM and only for its period of validity. Once the key is rotated, the agent forgets the previous CEK.

During recording, the plaintext CEK is never sent to the server.

The agent’s source code is open. Users can independently verify that key handling works exactly as described, inspect what data the agent sends to the cloud and how encryption is performed. They can also build the agent executables themselves and use those builds.

Protection from more than operator employees

The problem with cloud video surveillance is not limited to the possibility that an operator’s employees may watch recordings.

An operator may act responsibly, protect its infrastructure well, and strictly control access. But this does not guarantee that the data will always remain inside its systems and under its control.

An archive or a copy of it may reach third parties:

  • if media servers are compromised;
  • if an administrator account is compromised;
  • through a leaked backup;
  • because of a cloud storage configuration error;
  • after equipment or drives are stolen;
  • through the actions of a contractor or data center;
  • if servers, disks, or backups are seized during a search or other investigative action.

In a conventional cloud system, anyone who gains sufficiently broad access to the operator’s infrastructure may also gain the ability to decrypt the video.

With the SesameDVR architecture, copying or seizing the server storage does not, by itself, reveal the contents of the recordings.

The operator holds only:

  • encrypted video segments;
  • encrypted CEKs;
  • service data needed to organize and play back the archive.

The owner’s private key is not there.

Even if someone copies the entire SesameDVR storage system — as a result of a breach, a leaked backup, equipment theft, or server seizure — they obtain only encrypted video and encrypted keys.

The cloud storage does not contain all the data needed to watch the recordings.

We do more than limit which employees are allowed to watch video. We aim to ensure that the operator’s side simply does not contain everything needed to decrypt it.

What CBCS 1:9 Partial means

Video is stored in standard CMAF using SAMPLE-AES and the cbcs 1:9 encryption scheme.

This is neither a SesameDVR-specific container nor a new proprietary video codec.

The video data is divided into 16-byte AES blocks, after which a repeating pattern is applied:

1 block is encrypted
9 blocks are skipped
1 block is encrypted
9 blocks are skipped
...

This means that about 10% of the protected part of the video stream passes through AES.

But this does not mean that the remaining 90% of the image can be viewed without the key. An H.264 or H.265 video stream does not consist of independent pixels or separate pieces of a picture.

It is a sequence of compressed and interdependent data. The encrypted blocks are distributed within the video samples, so without the correct CEK, the decoder cannot reconstruct the frames correctly.

Partial encryption is a deliberate optimization here. It significantly reduces the load on a compact hardware agent while retaining the standard CMAF format and compatibility with built-in media decoders.

Audio data is encrypted in full.

How users watch video

Two playback modes are available.

Fully client-side decryption

In the primary mode, SesameDVR sends the browser:

  • encrypted video segments;
  • encrypted CEKs for the selected period.

The user loads their private key locally. The browser on the user’s device decrypts the required CEKs and passes them to ClearKey.

ClearKey is part of the Encrypted Media Extensions (EME) browser standard. It is a standard interface through which a web application can pass keys to the browser’s built-in media subsystem for playback of an encrypted CMAF stream.

Here, ClearKey is used neither as a commercial DRM system nor as a way to restrict the user. It serves as a standard bridge between the locally decrypted CEKs and the device’s hardware or software video decoder.

With this playback mode:

  • the private key remains on the user’s device;
  • plaintext CEKs are not sent to SesameDVR;
  • the server does not receive plaintext video;
  • decryption takes place directly during playback.

This mode is intended primarily for modern Chromium-based browsers and Firefox. Whether a particular stream can be played also depends on the codec, operating system, and the device’s hardware capabilities.

The architecture’s essential property remains intact: the operator transmits the data but does not receive the keys needed to watch it.

Compatibility mode

Safari, iOS, and some embedded players have limitations when working with ClearKey and the selected playback scheme.

A separately confirmed compatibility mode is available for these devices.

The user locally decrypts only the CEKs required for the selected recording interval and temporarily sends them to the server within a short-lived session.

SesameDVR decrypts only the requested fragments in RAM and delivers them to the device in a format that a conventional player can play.

The plaintext video and temporary keys are not saved:

  • to disk;
  • to persistent storage;
  • to a shared CDN cache;
  • to a long-term server cache.

This is the only mode in which the server temporarily gains the technical ability to decrypt the part of the archive selected by the user.

Compatibility mode is therefore less strict than fully client-side decryption. It should be enabled only with the user’s explicit consent and only for a limited time.

In return, this mode makes it possible to watch the archive on devices that do not support the fully client-side scheme.

Access can be shared

The stream owner can create separate key pairs for different users:

  • themselves;
  • family members;
  • security personnel;
  • employees;
  • a temporary recipient;
  • an external system.

When access is granted, the selected CEKs are additionally encrypted with the recipient’s public key.

Each recipient decrypts them with their own private key. The owner never needs to give anyone their private key.

This approach can grant access:

  • to the entire archive;
  • only to specific cameras;
  • only for a particular period;
  • only to new recordings;
  • to multiple users with independent keys.

To revoke access, it is enough to stop encrypting new CEKs with the corresponding recipient’s public key.

It is important to be clear about a natural limitation of any access system: if someone has already saved a decrypted recording or obtained plaintext keys for a particular period, it is impossible to make them delete that data retroactively.

Revoking access prevents the person from receiving new recordings, but it cannot undo information that has already been transferred.

What the operator can do

With this architecture, a cloud video surveillance operator can:

  • receive an encrypted stream;
  • record it in the archive;
  • build a timeline;
  • store service metadata;
  • enforce the retention period;
  • delete old segments;
  • deliver encrypted recordings to the owner;
  • provide the infrastructure for managing access.

But without the owner’s private key, the operator cannot independently watch the video itself.

Even an administrator with full access to the media servers and storage will see only encrypted segments and encrypted keys.

The same applies to an attacker who obtains a copy of the database, a contractor with access to the drives, or someone who takes possession of seized server infrastructure.

This does not mean absolute security

This architecture solves a specific problem: it protects the contents of the archive from being viewed by the cloud operator and from compromise of the server-side storage.

It does not eliminate the need to protect the other elements of the system.

For example, an attacker could still try to:

  • access the camera itself before encryption;
  • breach the home network;
  • replace or compromise Sesame Agent;
  • steal the owner’s private key;
  • gain access to the user’s already-unlocked device;
  • record the video from the screen during playback.

Furthermore, encrypting the video stream does not necessarily conceal all metadata.

The operator may still know:

  • that cameras exist;
  • when segments arrive;
  • the duration of the archive;
  • the volume of data transferred;
  • which actions users take in the interface.

SesameDVR does not make video invulnerable under all circumstances. It eliminates one of the most significant problems with traditional cloud video surveillance: the operator’s permanent technical ability to view the customer’s archive.

Why solutions like this are rare

Some enterprise products with customer-managed keys are available on the market.

But mass-market cloud video surveillance systems usually use a different model: the platform manages the keys itself and can decrypt the customer’s data when necessary.

What distinguishes the SesameDVR approach is not a newly invented encryption algorithm, but a combination of several properties:

  • support for ordinary RTSP cameras;
  • a separate local agent with no transcoding;
  • no direct cloud access to the cameras;
  • standard CMAF with cbcs;
  • playback through standard browser mechanisms;
  • local storage of the private key;
  • the ability to grant access by additionally encrypting CEKs;
  • open-source agent code.

Storing does not mean having the key

Over the years of cloud video surveillance development, we have become accustomed to thinking that if video is stored on an operator’s server, the operator must inevitably be able to watch it.

But this is not a requirement at all.

A server can store terabytes of recordings, index them, delete them when their retention period expires, and deliver them to the owner — without possessing the key required to view them.

The operator does not have to promise that its employees will not watch your video.

Nor is it enough simply to protect servers well: in theory, any server can be breached, copied, stolen, or seized.

A system can be built so that neither an in-house administrator, nor an attacker who obtains a copy of the storage, nor a person who gains possession of the server disks receives the ability to decrypt the archive along with it.

Storing video does not necessarily mean having access to its contents.

That is the model we are implementing in SesameDVR.