Videomonitoramento com criptografia de ponta a ponta

“Como coproprietário e diretor-geral de uma empresa que prestava serviços de videomonitoramento em nuvem, decidi não conectar as câmeras do quintal da minha própria casa de campo ao serviço da empresa.

Eu sabia muito bem que as pessoas com acesso administrativo aos servidores de mídia poderiam, tecnicamente, ver o que estava acontecendo na minha casa. Eu não queria que ninguém tivesse sequer a possibilidade de observar a minha vida privada”, afirma Alexander Vasiliev, ex-diretor-geral e coproprietário da LANTA.

Foi dessa experiência que surgiu a ideia de um sistema no qual o operador da nuvem pode armazenar os vídeos dos clientes sem ter a possibilidade de assisti-los.

Agora o SesameDVR torna isso possível.

Uma pequena caixa perto das câmeras

Para usar a criptografia, não é necessário trocar as câmeras nem esperar pelo surgimento de um novo padrão RTSP.

Um pequeno Sesame Agent é instalado na rede doméstica. Basta conectá-lo a uma porta LAN livre do roteador ou switch.

O agente se conecta às câmeras locais por conta própria, recebe os fluxos RTSP, criptografa o vídeo e só então o envia ao SesameDVR.

Todas as conexões são estabelecidas da rede doméstica para fora, portanto não é necessário:

abrir portas de entrada;
expor as câmeras na internet;
conceder à nuvem acesso direto à rede local;
alterar o firmware das câmeras.

Para o SesameDVR, as próprias câmeras ficam, na prática, inacessíveis. A nuvem recebe apenas um fluxo que já foi criptografado.

O agente não decodifica nem transcodifica o vídeo. Ele reempacota o fluxo H.264 ou H.265 existente, criptografa-o e o envia ao servidor. Por isso, os requisitos de processamento são consideravelmente menores que os de um servidor de vídeo completo que realiza transcodificação.

Dependendo do modelo, o Sesame Agent pode operar com 16 a várias centenas de câmeras.

O desempenho efetivo depende de:

taxa de bits total das câmeras;
desempenho do dispositivo utilizado;
velocidade da memória e das interfaces de rede;
largura de banda da conexão com a internet;
parâmetros de criptografia e configuração do sistema.

Como as chaves funcionam

O proprietário do fluxo cria localmente, no próprio dispositivo, um par de chaves criptográficas:

uma chave pública, que permite criptografar os dados;
uma chave privada, que permite descriptografá-los.

A chave pública é carregada no SesameDVR e transmitida ao agente. Ela permite criptografar dados para o proprietário, mas não permite realizar a operação inversa.

A chave privada permanece exclusivamente com o proprietário. Ela não é criada no SesameDVR, não é transmitida ao operador e não é armazenada no servidor.

Em seguida, o Sesame Agent gera periodicamente uma chave aleatória de criptografia de conteúdo: CEK, Content Encryption Key.

É essa chave que criptografa o vídeo.

Por padrão, uma nova CEK é criada a cada hora, mas esse intervalo pode ser alterado. As chaves podem ser trocadas com muito mais frequência: o limite prático é determinado principalmente pela quantidade de chaves criptografadas que precisam ser armazenadas junto com o arquivo.

Cada nova CEK é criptografada com a chave pública do proprietário.

Como resultado, o SesameDVR recebe e armazena:

segmentos de vídeo criptografados;
CEKs criptografadas que protegem esses segmentos.

A CEK não criptografada existe apenas na memória RAM do agente e somente durante o seu período de validade. Quando ocorre a troca de chave, o agente esquece a CEK anterior.

Durante a gravação, a CEK não criptografada nunca é transmitida ao servidor.

O código-fonte do agente é aberto. Os usuários podem verificar de forma independente se o tratamento das chaves funciona exatamente como descrito, conferir quais dados o agente transmite à nuvem e como a criptografia é realizada. Também podem compilar por conta própria os executáveis do agente e usar exatamente essas compilações.

Proteção que vai além dos funcionários do operador

O problema do videomonitoramento em nuvem não se limita à possibilidade de os funcionários do operador assistirem às gravações.

Um operador pode agir de boa-fé, proteger bem a infraestrutura e controlar rigorosamente o acesso. Mas isso não garante que os dados permanecerão sempre dentro dos seus sistemas e sob o seu controle.

O arquivo ou uma cópia dele pode chegar às mãos de terceiros:

se os servidores de mídia forem invadidos;
se uma conta de administrador for comprometida;
devido ao vazamento de um backup;
devido a um erro de configuração do armazenamento em nuvem;
após o roubo de equipamentos ou unidades de armazenamento;
em decorrência das ações de um prestador de serviços ou data center;
se servidores, discos ou backups forem apreendidos durante uma busca ou outra diligência investigativa.

Em um sistema de nuvem convencional, quem obtém acesso suficientemente amplo à infraestrutura do operador pode também obter a capacidade de descriptografar o vídeo.

Na arquitetura do SesameDVR, copiar ou apreender o armazenamento do servidor não revela, por si só, o conteúdo das gravações.

Do lado do operador há apenas:

segmentos de vídeo criptografados;
CEKs criptografadas;
dados de serviço necessários para organizar e reproduzir o arquivo.

A chave privada do proprietário não está lá.

Mesmo que alguém copie todo o armazenamento do SesameDVR — em decorrência de uma invasão, do vazamento de um backup, do roubo de equipamentos ou da apreensão de servidores —, obterá apenas vídeo criptografado e chaves criptografadas.

O armazenamento em nuvem não contém todo o conjunto de dados necessário para assistir às gravações.

Não nos limitamos a restringir quais funcionários têm permissão para assistir ao vídeo. Procuramos garantir que, do lado do operador, simplesmente não exista tudo o que é necessário para descriptografá-lo.

O que é CBCS 1:9 Partial

O vídeo é armazenado no formato CMAF padrão, usando SAMPLE-AES e o esquema de criptografia cbcs 1:9.

Não se trata de um contêiner próprio do SesameDVR nem de um novo codec de vídeo proprietário.

Os dados de vídeo são divididos em blocos AES de 16 bytes e, em seguida, é aplicado um padrão repetitivo:

1 bloco é criptografado
9 blocos são ignorados
1 bloco é criptografado
9 blocos são ignorados
...

Desse modo, cerca de 10% da parte protegida do fluxo de vídeo passa pelo AES.

Mas isso não significa que os outros 90% da imagem possam ser vistos sem a chave. Um fluxo de vídeo H.264 ou H.265 não é composto por pixels independentes nem por fragmentos isolados de uma imagem.

Trata-se de uma sequência de dados compactados e interdependentes. Os blocos criptografados são distribuídos dentro das amostras de vídeo; portanto, sem a CEK correta, o decodificador não consegue reconstruir os quadros corretamente.

A criptografia parcial é uma otimização deliberada. Ela reduz consideravelmente a carga sobre um agente de hardware compacto, ao mesmo tempo que preserva o formato CMAF padrão e a compatibilidade com os decodificadores de mídia integrados.

Os dados de áudio são criptografados por completo.

Como o usuário assiste ao vídeo

Há dois modos de reprodução.

Descriptografia totalmente no cliente

No modo principal, o SesameDVR envia ao navegador:

segmentos de vídeo criptografados;
CEKs criptografadas para o período selecionado.

O usuário carrega localmente a sua chave privada. O navegador no dispositivo do usuário descriptografa as CEKs necessárias e as transmite ao ClearKey.

O ClearKey faz parte do padrão de navegador Encrypted Media Extensions (EME). Trata-se de uma interface padrão por meio da qual uma aplicação web pode transmitir chaves ao subsistema de mídia integrado do navegador para reproduzir um fluxo CMAF criptografado.

Neste caso, o ClearKey não é usado como um sistema DRM comercial nem como um recurso para restringir o usuário. Ele funciona como uma ponte padrão entre as CEKs descriptografadas localmente e o decodificador de vídeo de hardware ou software do dispositivo.

Neste modo de reprodução:

a chave privada permanece no dispositivo do usuário;
as CEKs não criptografadas não são transmitidas ao SesameDVR;
o servidor não recebe vídeo não criptografado;
a descriptografia ocorre diretamente durante a reprodução.

Esse modo foi projetado principalmente para navegadores modernos baseados no Chromium e para o Firefox. A possibilidade de reproduzir um fluxo específico também depende do codec, do sistema operacional e dos recursos de hardware do dispositivo.

A principal propriedade da arquitetura permanece intacta: o operador transmite os dados, mas não recebe as chaves necessárias para assisti-los.

Modo de compatibilidade

O Safari, o iOS e alguns players integrados têm limitações ao trabalhar com o ClearKey e com o esquema de reprodução escolhido.

Para esses dispositivos, há um modo de compatibilidade que precisa ser confirmado separadamente.

O usuário descriptografa localmente apenas as CEKs necessárias para o intervalo de gravação selecionado e as transmite temporariamente ao servidor durante uma sessão de curta duração.

O SesameDVR descriptografa na memória RAM apenas os fragmentos solicitados e os entrega ao dispositivo em um formato que um player convencional consiga reproduzir.

O vídeo não criptografado e as chaves temporárias não são salvos:

em disco;
em armazenamento persistente;
em um cache CDN compartilhado;
em um cache de servidor de longa duração.

Esse é o único modo em que o servidor obtém temporariamente a capacidade técnica de descriptografar o trecho do arquivo selecionado pelo usuário.

Por isso, o modo de compatibilidade é menos rigoroso que a descriptografia totalmente no cliente. Ele só deve ser ativado com o consentimento explícito do usuário e por um período limitado.

Em contrapartida, esse modo permite assistir ao arquivo em dispositivos que não oferecem suporte ao esquema totalmente no cliente.

O acesso pode ser compartilhado

O proprietário do fluxo pode criar pares de chaves separados para diferentes usuários:

para si mesmo;
para familiares;
para a equipe de segurança;
para funcionários;
para um destinatário temporário;
para um sistema externo.

Ao conceder acesso, as CEKs selecionadas são criptografadas adicionalmente com a chave pública do destinatário.

Cada destinatário as descriptografa com a própria chave privada. Não é necessário transmitir a chave privada do proprietário a ninguém.

Esse método permite conceder acesso:

a todo o arquivo;
apenas a câmeras específicas;
apenas a um período determinado;
apenas a novas gravações;
a vários usuários com chaves independentes.

Para revogar o acesso, basta deixar de criptografar as novas CEKs com a chave pública do destinatário correspondente.

É importante deixar clara uma limitação natural de qualquer sistema de acesso: se uma pessoa já salvou uma gravação descriptografada ou obteve chaves não criptografadas para um período específico, é impossível obrigá-la a apagar esses dados retroativamente.

A revogação do acesso impede o recebimento de novas gravações, mas não pode desfazer uma transferência de informações que já ocorreu.

O que o operador pode fazer

Com essa arquitetura, um operador de videomonitoramento em nuvem pode:

receber um fluxo criptografado;
gravá-lo no arquivo;
criar uma linha do tempo;
armazenar metadados de serviço;
controlar o período de retenção;
excluir segmentos antigos;
entregar gravações criptografadas ao proprietário;
fornecer a infraestrutura para gerenciar o acesso.

Mas, sem a chave privada do proprietário, o operador não consegue assistir ao vídeo por conta própria.

Até mesmo um administrador com acesso total aos servidores de mídia e ao armazenamento verá apenas segmentos criptografados e chaves criptografadas.

O mesmo se aplica a um invasor que obtenha uma cópia do banco de dados, a um prestador de serviços com acesso às unidades de armazenamento ou a uma pessoa que tome posse de uma infraestrutura de servidores apreendida.

Isso não significa segurança absoluta

Essa arquitetura resolve um problema específico: ela protege o conteúdo do arquivo contra a visualização pelo operador da nuvem e contra o comprometimento do armazenamento no servidor.

Mas ela não elimina a necessidade de proteger os demais elementos do sistema.

Por exemplo, um invasor ainda pode tentar:

acessar a própria câmera antes da criptografia;
invadir a rede doméstica;
substituir ou comprometer o Sesame Agent;
roubar a chave privada do proprietário;
obter acesso ao dispositivo do usuário enquanto ele está desbloqueado;
gravar o vídeo da tela durante a reprodução.

Além disso, a criptografia do fluxo de vídeo não oculta necessariamente todos os metadados.

O operador ainda pode saber:

que as câmeras existem;
quando os segmentos chegam;
a duração do arquivo;
o volume de dados transmitidos;
quais ações os usuários realizam na interface.

O SesameDVR não torna o vídeo invulnerável em todas as circunstâncias. Ele elimina um dos problemas mais importantes do videomonitoramento tradicional em nuvem: a capacidade técnica permanente do operador de visualizar o arquivo do cliente.

Por que soluções como esta são raras

Existem no mercado alguns produtos corporativos com chaves gerenciadas pelo cliente.

No entanto, os sistemas de videomonitoramento em nuvem voltados ao mercado de massa geralmente adotam outro modelo: a própria plataforma gerencia as chaves e pode descriptografar os dados do cliente quando necessário.

O diferencial da abordagem do SesameDVR não está na invenção de um novo algoritmo de criptografia, mas na combinação de várias características:

operação com câmeras RTSP convencionais;
um agente local separado, sem transcodificação;
ausência de acesso direto da nuvem às câmeras;
CMAF padrão com cbcs;
reprodução por meio dos mecanismos padrão do navegador;
armazenamento local da chave privada;
possibilidade de conceder acesso por meio da criptografia adicional das CEKs;
código-fonte aberto do agente.

Armazenar não significa ter a chave

Ao longo dos anos de desenvolvimento do videomonitoramento em nuvem, acostumamo-nos a pensar que, se o vídeo é armazenado no servidor do operador, o operador inevitavelmente consegue assisti-lo.

Mas isso não é uma condição necessária.

Um servidor pode armazenar terabytes de gravações, indexá-las, excluí-las quando o período de retenção terminar e entregá-las ao proprietário — sem possuir a chave necessária para visualizá-las.

O operador não precisa se limitar a prometer que seus funcionários não assistirão aos seus vídeos.

Também não basta apenas proteger bem os servidores: em teoria, qualquer servidor pode ser invadido, copiado, roubado ou apreendido.

É possível construir um sistema de modo que nem um administrador interno, nem um invasor que obtenha uma cópia do armazenamento, nem uma pessoa que tome posse dos discos do servidor recebam, junto com o arquivo, a possibilidade de descriptografá-lo.

Armazenar vídeo não significa necessariamente ter acesso ao seu conteúdo.

É exatamente esse o modelo que estamos implementando no SesameDVR.