Видеонаблюдение с end-to-end шифрованием

«Будучи совладельцем и генеральным директором компании, которая сама предоставляла услуги облачного видеонаблюдения, я не стал подключать камеры во дворе собственного загородного дома к услугам своей компании.

Я слишком хорошо понимал, что люди, имеющие административный доступ к медиасерверам, технически могут посмотреть, что происходит у меня дома. Мне не хотелось, чтобы кто-либо потенциально мог наблюдать за моей личной жизнью»,

— Александр Васильев, бывший генеральный директор и совладелец компании «ЛАНТА».

Из этого и выросла идея системы, в которой оператор облака может хранить видео клиентов, но не имеет возможности его посмотреть.

Теперь такая возможность появилась в SesameDVR.

Маленькая коробочка рядом с камерами

Для шифрования не нужно менять камеры или ждать появления нового стандарта RTSP.

В домашней сети устанавливается небольшой Sesame Agent. Его достаточно подключить в свободный LAN-порт роутера или коммутатора.

Агент самостоятельно подключается к локальным камерам, получает их RTSP-потоки, шифрует видео и только после этого отправляет его в SesameDVR.

Все соединения устанавливаются из домашней сети наружу, поэтому не требуется:

открывать входящие порты;
публиковать камеры в интернете;
выдавать облаку прямой доступ к локальной сети;
менять прошивку камер.

Для SesameDVR сами камеры фактически недоступны. Облако получает только уже зашифрованный поток.

Агент не декодирует и не перекодирует видео. Он переупаковывает готовый поток H.264 или H.265, шифрует его и отправляет на сервер. Поэтому требования к процессору значительно ниже, чем у полноценного видеосервера, выполняющего транскодирование.

В зависимости от модели Sesame Agent может обеспечить работу от 16 до нескольких сотен камер.

Конкретная производительность зависит от:

суммарного битрейта камер;
производительности конкретного устройства;
скорости памяти и сетевых интерфейсов;
пропускной способности интернет-канала;
параметров шифрования и конфигурации системы.

Как устроены ключи

Владелец потока локально, на своём устройстве, создаёт пару криптографических ключей:

публичный ключ, который позволяет шифровать данные;
приватный ключ, который позволяет их расшифровывать.

Публичный ключ загружается в SesameDVR и передаётся агенту. С его помощью можно зашифровать данные для владельца, но нельзя выполнить обратную операцию.

Приватный ключ остаётся только у владельца. Он не создаётся в SesameDVR, не передаётся оператору и не хранится на сервере.

Далее Sesame Agent периодически генерирует случайный ключ шифрования содержимого — CEK, Content Encryption Key.

Именно этим ключом шифруется видео.

По умолчанию новый CEK создаётся каждый час, но период можно изменить. Ключи можно менять значительно чаще: практическое ограничение определяется в основном количеством зашифрованных ключей, которые необходимо хранить вместе с архивом.

Каждый новый CEK шифруется публичным ключом владельца.

В результате SesameDVR получает и хранит:

зашифрованные видеосегменты;
зашифрованные CEK, которыми защищены эти сегменты.

Открытый CEK находится только в оперативной памяти агента и только в течение своего периода действия. После смены ключа агент забывает предыдущий CEK.

В процессе записи открытый CEK никогда не передаётся на сервер.

Исходный код агента открыт. Пользователь системы может самостоятельно убедиться в том, что работа с ключами устроена именно так, как заявлено, проверить, какие данные агент передаёт в облако и как выполняется шифрование. Кроме того, пользователь может собрать исполняемые файлы агента самостоятельно и использовать именно их.

Защита не только от сотрудников оператора

Проблема облачного видеонаблюдения заключается не только в том, что записи потенциально могут посмотреть сотрудники оператора.

Оператор может быть добросовестным, хорошо защищать инфраструктуру и строго контролировать доступ. Но это не гарантирует, что данные всегда останутся внутри его системы и под его контролем.

Архив или его копия могут оказаться у третьих лиц:

при взломе медиасерверов;
при компрометации учётной записи администратора;
из-за утечки резервной копии;
из-за ошибки в настройках облачного хранилища;
после кражи оборудования или накопителей;
в результате действий подрядчика или дата-центра;
при изъятии серверов, дисков или резервных копий во время обыска или других следственных действий.

В обычной облачной системе тот, кто получает достаточно полный доступ к инфраструктуре оператора, потенциально получает и возможность расшифровать видео.

В архитектуре SesameDVR копирование или изъятие серверного хранилища само по себе не раскрывает содержание записей.

На стороне оператора находятся только:

зашифрованные видеосегменты;
зашифрованные CEK;
служебные данные, необходимые для организации архива и воспроизведения.

Приватного ключа владельца там нет.

Даже если кто-то полностью скопирует хранилище SesameDVR — в результате взлома, утечки резервной копии, кражи оборудования или изъятия серверов, — он получит только зашифрованное видео и зашифрованные ключи.

Облачное хранилище не содержит достаточного набора данных для просмотра записей.

Мы не просто ограничиваем круг сотрудников, которым разрешено смотреть видео. Мы стараемся сделать так, чтобы на стороне оператора в принципе не существовало всего необходимого для его расшифрования.

Что такое CBCS 1:9 Partial

Видео хранится в стандартном CMAF с использованием SAMPLE-AES и схемы шифрования cbcs 1:9.

Это не собственный контейнер SesameDVR и не новый проприетарный видеокодек.

Видеоданные разбиваются на AES-блоки по 16 байт, после чего применяется повторяющийся шаблон:

1 блок шифруется
9 блоков пропускаются
1 блок шифруется
9 блоков пропускаются
...

Таким образом, через AES проходит около 10% защищаемой части видеопотока.

Но это не означает, что без ключа можно увидеть оставшиеся 90% изображения. Видеопоток H.264 или H.265 не состоит из независимых пикселей или отдельных фрагментов картинки.

Это последовательность сжатых и взаимозависимых данных. Зашифрованные блоки распределены внутри видеосэмплов, поэтому без правильного CEK декодер не может корректно восстановить кадры.

Частичное шифрование здесь является осознанной оптимизацией. Оно существенно снижает нагрузку на компактный аппаратный агент, но сохраняет стандартный формат CMAF и совместимость со встроенными медиадекодерами.

Аудиоданные при этом шифруются полностью.

Как пользователь смотрит видео

Предусмотрено два режима воспроизведения.

Полностью клиентское расшифрование

В основном режиме SesameDVR отправляет браузеру:

зашифрованные видеосегменты;
зашифрованные CEK для выбранного периода.

Пользователь локально загружает свой приватный ключ. Браузер на устройстве пользователя расшифровывает необходимые CEK и передаёт их в ClearKey.

ClearKey является частью браузерного стандарта Encrypted Media Extensions — EME. Это стандартный интерфейс, через который веб-приложение может передать ключи встроенной медиаподсистеме браузера для воспроизведения зашифрованного CMAF-потока.

В данном случае ClearKey используется не как коммерческая DRM-система и не как средство ограничения пользователя. Он служит стандартным мостом между локально расшифрованными CEK и аппаратным или программным видеодекодером устройства.

При таком воспроизведении:

приватный ключ остаётся на устройстве пользователя;
открытые CEK не передаются в SesameDVR;
сервер не получает открытое видео;
расшифрование выполняется непосредственно во время воспроизведения.

Этот режим предназначен прежде всего для современных браузеров на базе Chromium и Firefox. Возможность воспроизведения конкретного потока дополнительно зависит от кодека, операционной системы и аппаратных возможностей устройства.

Главное свойство архитектуры сохраняется: оператор передаёт данные, но не получает ключей, позволяющих их посмотреть.

Режим совместимости

Safari, iOS и некоторые встроенные плееры имеют ограничения при работе с ClearKey и выбранной схемой воспроизведения.

Для таких устройств предусмотрен отдельно подтверждаемый режим совместимости.

Пользователь локально расшифровывает только те CEK, которые необходимы для выбранного интервала записи, и временно передаёт их серверу в рамках короткоживущей сессии.

SesameDVR расшифровывает в оперативной памяти только запрошенные фрагменты и отдаёт их устройству в формате, который может воспроизвести обычный плеер.

Открытое видео и временные ключи при этом не сохраняются:

на диск;
в постоянное хранилище;
в общий CDN-кэш;
в долговременный серверный кэш.

Это единственный режим, в котором сервер временно получает техническую возможность расшифровать выбранный пользователем участок архива.

Поэтому режим совместимости менее строгий, чем полностью клиентское расшифрование. Он должен включаться только с явного согласия пользователя и только на ограниченное время.

Зато такой режим позволяет просматривать архив на устройствах, которые не поддерживают полностью клиентскую схему.

Доступом можно делиться

Владелец потока может создать отдельные пары ключей для разных пользователей:

для себя;
для членов семьи;
для охраны;
для сотрудников;
для временного получателя;
для внешней системы.

При предоставлении доступа выбранные CEK дополнительно шифруются публичным ключом получателя.

Каждый получатель расшифровывает их своим приватным ключом. Приватный ключ владельца при этом никому передавать не требуется.

Таким способом можно предоставить доступ:

ко всему архиву;
только к отдельным камерам;
только к определённому периоду;
только к новым записям;
нескольким пользователям с независимыми ключами.

Для отзыва доступа достаточно прекратить шифровать новые CEK публичным ключом соответствующего получателя.

При этом важно честно обозначить естественное ограничение любой системы доступа: если человек уже сохранил расшифрованную запись или получил открытые ключи к определённому периоду, заставить его удалить эти данные задним числом невозможно.

Отзыв доступа предотвращает получение новых записей, но не может отменить уже состоявшуюся передачу информации.

Что сможет оператор

В такой архитектуре оператор облачного видеонаблюдения сможет:

принять зашифрованный поток;
записать его в архив;
построить временную шкалу;
хранить служебные метаданные;
контролировать срок хранения;
удалить старые сегменты;
передать зашифрованные записи владельцу;
предоставить инфраструктуру для управления доступом.

Но без приватного ключа владельца оператор не сможет самостоятельно посмотреть само видео.

Даже администратор, имеющий полный доступ к медиасерверам и хранилищу, увидит только зашифрованные сегменты и зашифрованные ключи.

То же самое относится к злоумышленнику, получившему копию базы данных, подрядчику с доступом к накопителям или человеку, в распоряжении которого оказалась изъятая серверная инфраструктура.

Это не означает абсолютную безопасность

Такая архитектура решает конкретную задачу: защищает содержание архива от просмотра со стороны облачного оператора и от компрометации серверного хранилища.

Но она не отменяет необходимости защищать остальные элементы системы.

Например, злоумышленник всё ещё может попытаться:

получить доступ к самой камере до шифрования;
взломать домашнюю сеть;
подменить или скомпрометировать Sesame Agent;
украсть приватный ключ владельца;
получить доступ к уже разблокированному устройству пользователя;
записать видео с экрана во время просмотра.

Кроме того, шифрование видеопотока не обязательно скрывает все метаданные.

Оператор по-прежнему может знать:

о существовании камер;
о времени поступления сегментов;
о продолжительности архива;
об объёме передаваемых данных;
о действиях пользователей в интерфейсе.

SesameDVR не делает видео неуязвимым при любых обстоятельствах. Он устраняет одну из наиболее существенных проблем традиционного облачного видеонаблюдения: наличие на стороне оператора постоянной технической возможности просматривать клиентский архив.

Почему подобные решения встречаются редко

На рынке существуют отдельные корпоративные продукты с клиентским управлением ключами.

Но в массовых облачных системах видеонаблюдения обычно применяется другая модель: платформа сама управляет ключами и при необходимости может расшифровать данные клиента.

Особенность подхода SesameDVR заключается не в изобретении нового алгоритма шифрования, а в сочетании нескольких свойств:

работа с обычными RTSP-камерами;
отдельный локальный агент без перекодирования;
отсутствие прямого доступа облака к камерам;
стандартный CMAF с cbcs;
воспроизведение через стандартные механизмы браузера;
локальное хранение приватного ключа;
возможность предоставлять доступ через дополнительное шифрование CEK;
открытый исходный код агента.

Хранить — не значит иметь ключ

За годы развития облачного видеонаблюдения мы привыкли считать, что если видео хранится на сервере оператора, значит оператор неизбежно может его посмотреть.

Но это вовсе не обязательное условие.

Сервер может хранить терабайты записей, индексировать их, удалять по окончании срока хранения и передавать владельцу — не располагая ключом, необходимым для просмотра.

Оператору не обязательно обещать, что его сотрудники не станут смотреть ваше видео.

Недостаточно и просто хорошо защищать серверы: любой сервер теоретически может быть взломан, скопирован, украден или изъят.

Можно построить систему так, чтобы ни штатный администратор, ни злоумышленник, получивший копию хранилища, ни человек, в распоряжении которого оказались серверные диски, не получили вместе с архивом возможность его расшифровать.

Хранить видео — не обязательно означает иметь доступ к его содержимому.

Именно такую модель мы реализуем в SesameDVR.