Videovigilancia con cifrado de extremo a extremo
«Como copropietario y director general de una empresa que ofrecía servicios de videovigilancia en la nube, decidí no conectar las cámaras del patio de mi propia casa de campo al servicio de mi empresa.
Sabía demasiado bien que las personas con acceso administrativo a los servidores multimedia podían, desde un punto de vista técnico, ver lo que ocurría en mi casa. No quería que nadie tuviera siquiera la posibilidad de observar mi vida privada», afirma Alexander Vasiliev, antiguo director general y copropietario de LANTA.
De ahí surgió la idea de un sistema en el que el operador de la nube pueda almacenar el vídeo de sus clientes sin tener la posibilidad de verlo.
Ahora SesameDVR hace posible este modelo.
Una pequeña caja junto a las cámaras
El cifrado no exige cambiar las cámaras ni esperar a que aparezca un nuevo estándar RTSP.
En la red doméstica se instala un pequeño Sesame Agent. Basta con conectarlo a un puerto LAN libre del router o del conmutador.
El agente se conecta por sí mismo a las cámaras locales, recibe sus flujos RTSP, cifra el vídeo y solo entonces lo envía a SesameDVR.
Todas las conexiones se establecen desde la red doméstica hacia el exterior, por lo que no es necesario:
- abrir puertos de entrada;
- exponer las cámaras en internet;
- dar a la nube acceso directo a la red local;
- cambiar el firmware de las cámaras.
Para SesameDVR, las propias cámaras son en la práctica inaccesibles. La nube recibe únicamente un flujo ya cifrado.
El agente no decodifica ni transcodifica el vídeo. Reempaqueta el flujo H.264 o H.265 existente, lo cifra y lo envía al servidor. Por eso, sus requisitos de procesador son considerablemente menores que los de un servidor de vídeo completo que realiza transcodificación.
Según el modelo, Sesame Agent puede atender desde 16 hasta varios cientos de cámaras.
El rendimiento concreto depende de:
- la tasa de bits total de las cámaras;
- el rendimiento del dispositivo utilizado;
- la velocidad de la memoria y de las interfaces de red;
- el ancho de banda de la conexión a internet;
- los parámetros de cifrado y la configuración del sistema.
Cómo funcionan las claves
El propietario del flujo crea localmente, en su propio dispositivo, un par de claves criptográficas:
- una clave pública, que permite cifrar los datos;
- una clave privada, que permite descifrarlos.
La clave pública se carga en SesameDVR y se entrega al agente. Con ella se pueden cifrar datos para el propietario, pero no se puede realizar la operación inversa.
La clave privada permanece exclusivamente en poder del propietario. No se crea en SesameDVR, no se transmite al operador y no se almacena en el servidor.
A continuación, Sesame Agent genera periódicamente una clave aleatoria de cifrado de contenido: CEK, Content Encryption Key.
Esta es la clave que cifra el vídeo.
De forma predeterminada, se crea una nueva CEK cada hora, aunque el intervalo puede modificarse. Las claves pueden rotarse con mucha mayor frecuencia: el límite práctico viene determinado principalmente por la cantidad de claves cifradas que deben almacenarse junto con el archivo.
Cada nueva CEK se cifra con la clave pública del propietario.
Como resultado, SesameDVR recibe y almacena:
- segmentos de vídeo cifrados;
- CEK cifradas que protegen esos segmentos.
La CEK sin cifrar solo existe en la memoria RAM del agente y únicamente durante su periodo de validez. Cuando se rota la clave, el agente olvida la CEK anterior.
Durante la grabación, la CEK sin cifrar nunca se transmite al servidor.
El agente es de código abierto. Los usuarios pueden comprobar por sí mismos que la gestión de las claves funciona exactamente como se describe, verificar qué datos envía el agente a la nube y cómo se realiza el cifrado. También pueden compilar por su cuenta los ejecutables del agente y utilizar precisamente esas compilaciones.
Protección más allá de los empleados del operador
El problema de la videovigilancia en la nube no se limita a la posibilidad de que los empleados del operador vean las grabaciones.
Un operador puede actuar de buena fe, proteger bien su infraestructura y controlar estrictamente el acceso. Pero eso no garantiza que los datos permanezcan siempre dentro de su sistema y bajo su control.
El archivo, o una copia del mismo, puede acabar en manos de terceros:
- si se vulneran los servidores multimedia;
- si se compromete una cuenta de administrador;
- por la filtración de una copia de seguridad;
- por un error de configuración del almacenamiento en la nube;
- tras el robo de equipos o unidades de almacenamiento;
- como resultado de las acciones de un contratista o de un centro de datos;
- si se incautan servidores, discos o copias de seguridad durante un registro u otra actuación de investigación.
En un sistema convencional en la nube, quien obtiene un acceso suficientemente amplio a la infraestructura del operador también puede obtener la capacidad de descifrar el vídeo.
En la arquitectura de SesameDVR, copiar o incautar el almacenamiento del servidor no revela por sí solo el contenido de las grabaciones.
En el lado del operador solo se encuentran:
- segmentos de vídeo cifrados;
- CEK cifradas;
- datos de servicio necesarios para organizar y reproducir el archivo.
La clave privada del propietario no está allí.
Aunque alguien copiara todo el almacenamiento de SesameDVR —como consecuencia de un ataque, la filtración de una copia de seguridad, el robo de equipos o la incautación de servidores—, solo obtendría vídeo cifrado y claves cifradas.
El almacenamiento en la nube no contiene todos los datos necesarios para ver las grabaciones.
No nos limitamos a restringir qué empleados están autorizados a ver el vídeo. Procuramos que, en el lado del operador, sencillamente no exista todo lo necesario para descifrarlo.
Qué es CBCS 1:9 Partial
El vídeo se almacena en CMAF estándar utilizando SAMPLE-AES y el esquema de cifrado cbcs 1:9.
No se trata de un contenedor propio de SesameDVR ni de un nuevo códec de vídeo propietario.
Los datos de vídeo se dividen en bloques AES de 16 bytes y después se aplica un patrón repetitivo:
se cifra 1 bloque
se omiten 9 bloques
se cifra 1 bloque
se omiten 9 bloques
...
De este modo, alrededor del 10 % de la parte protegida del flujo de vídeo pasa por AES.
Pero esto no significa que el 90 % restante de la imagen pueda verse sin la clave. Un flujo de vídeo H.264 o H.265 no está compuesto por píxeles independientes ni por fragmentos aislados de una imagen.
Es una secuencia de datos comprimidos e interdependientes. Los bloques cifrados se distribuyen dentro de las muestras de vídeo, por lo que, sin la CEK correcta, el decodificador no puede reconstruir correctamente los fotogramas.
El cifrado parcial es aquí una optimización deliberada. Reduce considerablemente la carga del agente de hardware compacto, al tiempo que conserva el formato CMAF estándar y la compatibilidad con los decodificadores multimedia integrados.
Los datos de audio se cifran por completo.
Cómo ve el vídeo el usuario
Hay dos modos de reproducción.
Descifrado completamente en el cliente
En el modo principal, SesameDVR envía al navegador:
- segmentos de vídeo cifrados;
- CEK cifradas correspondientes al periodo seleccionado.
El usuario carga localmente su clave privada. El navegador del dispositivo del usuario descifra las CEK necesarias y las entrega a ClearKey.
ClearKey forma parte del estándar para navegadores Encrypted Media Extensions (EME). Es una interfaz estándar mediante la cual una aplicación web puede entregar claves al subsistema multimedia integrado del navegador para reproducir un flujo CMAF cifrado.
En este caso, ClearKey no se utiliza como sistema DRM comercial ni como medio para imponer restricciones al usuario. Sirve como puente estándar entre las CEK descifradas localmente y el decodificador de vídeo de hardware o software del dispositivo.
Con este modo de reproducción:
- la clave privada permanece en el dispositivo del usuario;
- las CEK sin cifrar no se transmiten a SesameDVR;
- el servidor no recibe vídeo sin cifrar;
- el descifrado se realiza directamente durante la reproducción.
Este modo está pensado principalmente para navegadores modernos basados en Chromium y para Firefox. La posibilidad de reproducir un flujo concreto depende además del códec, del sistema operativo y de las capacidades de hardware del dispositivo.
La propiedad esencial de la arquitectura se mantiene: el operador transmite los datos, pero no recibe las claves que permitirían verlos.
Modo de compatibilidad
Safari, iOS y algunos reproductores integrados presentan limitaciones al trabajar con ClearKey y con el esquema de reproducción elegido.
Para estos dispositivos existe un modo de compatibilidad que debe confirmarse por separado.
El usuario descifra localmente solo las CEK necesarias para el intervalo de grabación seleccionado y las transmite temporalmente al servidor dentro de una sesión de corta duración.
SesameDVR descifra en la memoria RAM únicamente los fragmentos solicitados y los entrega al dispositivo en un formato que pueda reproducir un reproductor convencional.
El vídeo sin cifrar y las claves temporales no se guardan:
- en disco;
- en almacenamiento persistente;
- en una caché CDN compartida;
- en una caché de servidor de larga duración.
Este es el único modo en el que el servidor obtiene temporalmente la capacidad técnica de descifrar la parte del archivo seleccionada por el usuario.
Por eso, el modo de compatibilidad es menos estricto que el descifrado completamente en el cliente. Solo debe habilitarse con el consentimiento explícito del usuario y durante un tiempo limitado.
A cambio, este modo permite ver el archivo en dispositivos que no admiten el esquema completamente del lado del cliente.
El acceso se puede compartir
El propietario del flujo puede crear pares de claves independientes para distintos usuarios:
- para sí mismo;
- para familiares;
- para el personal de seguridad;
- para empleados;
- para un destinatario temporal;
- para un sistema externo.
Al conceder acceso, las CEK seleccionadas se cifran además con la clave pública del destinatario.
Cada destinatario las descifra con su propia clave privada. No es necesario entregar a nadie la clave privada del propietario.
Este método permite conceder acceso:
- a todo el archivo;
- únicamente a cámaras concretas;
- únicamente durante un periodo determinado;
- únicamente a las nuevas grabaciones;
- a varios usuarios con claves independientes.
Para revocar el acceso basta con dejar de cifrar las nuevas CEK con la clave pública del destinatario correspondiente.
Es importante dejar clara una limitación natural de cualquier sistema de acceso: si una persona ya ha guardado una grabación descifrada o ha obtenido claves sin cifrar para un periodo concreto, es imposible obligarla a eliminar esos datos con efecto retroactivo.
La revocación del acceso impide recibir nuevas grabaciones, pero no puede deshacer una transferencia de información que ya se ha producido.
Qué puede hacer el operador
Con esta arquitectura, un operador de videovigilancia en la nube puede:
- recibir un flujo cifrado;
- grabarlo en el archivo;
- crear una línea de tiempo;
- almacenar metadatos de servicio;
- controlar el periodo de conservación;
- eliminar segmentos antiguos;
- entregar las grabaciones cifradas al propietario;
- proporcionar la infraestructura para gestionar el acceso.
Pero, sin la clave privada del propietario, el operador no puede ver el vídeo por su cuenta.
Incluso un administrador con acceso completo a los servidores multimedia y al almacenamiento solo verá segmentos cifrados y claves cifradas.
Lo mismo se aplica a un atacante que obtenga una copia de la base de datos, a un contratista con acceso a las unidades o a una persona que tome posesión de una infraestructura de servidores incautada.
Esto no significa seguridad absoluta
Esta arquitectura resuelve un problema concreto: protege el contenido del archivo frente a la visualización por parte del operador de la nube y frente a la vulneración del almacenamiento del servidor.
Pero no elimina la necesidad de proteger los demás elementos del sistema.
Por ejemplo, un atacante aún podría intentar:
- acceder a la propia cámara antes del cifrado;
- vulnerar la red doméstica;
- sustituir o comprometer Sesame Agent;
- robar la clave privada del propietario;
- acceder al dispositivo del usuario mientras está desbloqueado;
- grabar el vídeo de la pantalla durante la reproducción.
Además, cifrar el flujo de vídeo no oculta necesariamente todos los metadatos.
El operador puede seguir sabiendo:
- que existen cámaras;
- cuándo llegan los segmentos;
- la duración del archivo;
- el volumen de datos transmitidos;
- qué acciones realizan los usuarios en la interfaz.
SesameDVR no hace que el vídeo sea invulnerable en cualquier circunstancia. Elimina uno de los problemas más importantes de la videovigilancia tradicional en la nube: la capacidad técnica permanente del operador para ver el archivo del cliente.
Por qué estas soluciones son poco habituales
En el mercado existen algunos productos empresariales con claves gestionadas por el cliente.
Pero los sistemas de videovigilancia en la nube destinados al mercado masivo suelen utilizar otro modelo: la plataforma gestiona las claves y puede descifrar los datos del cliente cuando es necesario.
Lo que distingue al enfoque de SesameDVR no es la invención de un nuevo algoritmo de cifrado, sino la combinación de varias propiedades:
- funcionamiento con cámaras RTSP convencionales;
- un agente local independiente sin transcodificación;
- ausencia de acceso directo de la nube a las cámaras;
- CMAF estándar con
cbcs; - reproducción mediante mecanismos estándar del navegador;
- almacenamiento local de la clave privada;
- posibilidad de conceder acceso mediante el cifrado adicional de las CEK;
- código fuente abierto del agente.
Almacenar no significa tener la clave
Con los años de desarrollo de la videovigilancia en la nube, nos hemos acostumbrado a pensar que, si un vídeo se almacena en el servidor del operador, este inevitablemente podrá verlo.
Pero esto no tiene por qué ser así.
Un servidor puede almacenar terabytes de grabaciones, indexarlas, eliminarlas cuando expire su periodo de conservación y entregarlas al propietario, sin poseer la clave necesaria para verlas.
El operador no tiene por qué limitarse a prometer que sus empleados no verán su vídeo.
Tampoco basta simplemente con proteger bien los servidores: en teoría, cualquier servidor puede ser vulnerado, copiado, robado o incautado.
Es posible construir un sistema de modo que ni un administrador interno, ni un atacante que obtenga una copia del almacenamiento, ni una persona que tome posesión de los discos del servidor reciban, junto con el archivo, la posibilidad de descifrarlo.
Almacenar vídeo no significa necesariamente tener acceso a su contenido.
Este es precisamente el modelo que estamos implementando en SesameDVR.