Vidéosurveillance avec chiffrement de bout en bout

« Lorsque j’étais copropriétaire et directeur général d’une entreprise qui fournissait elle-même des services de vidéosurveillance dans le cloud, je n’ai pas raccordé les caméras installées dans la cour de ma propre maison de campagne aux services de mon entreprise.

Je savais trop bien que les personnes disposant d’un accès administrateur aux serveurs multimédias pouvaient techniquement voir ce qui se passait chez moi. Je ne voulais pas que quelqu’un puisse potentiellement observer ma vie privée », explique Alexandre Vassiliev, ancien directeur général et copropriétaire de l’entreprise « LANTA ».

C’est de là qu’est née l’idée d’un système dans lequel l’opérateur du cloud peut stocker les vidéos de ses clients sans avoir la possibilité de les regarder.

Cette possibilité existe désormais dans SesameDVR.

Un petit boîtier à proximité des caméras

Le chiffrement ne nécessite ni de remplacer les caméras ni d’attendre l’apparition d’un nouveau standard RTSP.

Un petit Sesame Agent est installé sur le réseau domestique. Il suffit de le connecter à un port LAN libre du routeur ou du commutateur.

L’agent se connecte de façon autonome aux caméras locales, reçoit leurs flux RTSP, chiffre la vidéo et ne l’envoie à SesameDVR qu’ensuite.

Toutes les connexions sont établies depuis le réseau domestique vers l’extérieur. Il n’est donc pas nécessaire :

d’ouvrir des ports entrants ;
d’exposer les caméras sur Internet ;
de donner au cloud un accès direct au réseau local ;
de modifier le micrologiciel des caméras.

Pour SesameDVR, les caméras elles-mêmes sont en pratique inaccessibles. Le cloud ne reçoit que le flux déjà chiffré.

L’agent ne décode ni ne transcode la vidéo. Il reconditionne le flux H.264 ou H.265 existant, le chiffre et l’envoie au serveur. Les besoins en puissance de calcul sont donc nettement inférieurs à ceux d’un serveur vidéo complet effectuant un transcodage.

Selon le modèle, un Sesame Agent peut prendre en charge de 16 à plusieurs centaines de caméras.

Les performances réelles dépendent :

du débit binaire cumulé des caméras ;
des performances de l’appareil utilisé ;
de la vitesse de la mémoire et des interfaces réseau ;
de la bande passante de la connexion Internet ;
des paramètres de chiffrement et de la configuration du système.

Fonctionnement des clés

Le propriétaire du flux crée localement, sur son propre appareil, une paire de clés cryptographiques :

une clé publique, qui permet de chiffrer les données ;
une clé privée, qui permet de les déchiffrer.

La clé publique est chargée dans SesameDVR et transmise à l’agent. Elle permet de chiffrer des données pour le propriétaire, mais pas d’effectuer l’opération inverse.

La clé privée reste exclusivement entre les mains du propriétaire. Elle n’est pas créée dans SesameDVR, n’est pas transmise à l’opérateur et n’est pas stockée sur le serveur.

Le Sesame Agent génère ensuite périodiquement une clé aléatoire de chiffrement du contenu : la CEK, Content Encryption Key.

C’est précisément cette clé qui sert à chiffrer la vidéo.

Par défaut, une nouvelle CEK est générée chaque heure, mais cet intervalle peut être modifié. Les clés peuvent être renouvelées beaucoup plus souvent : la limite pratique dépend principalement du nombre de clés chiffrées qu’il faut conserver avec l’archive.

Chaque nouvelle CEK est chiffrée avec la clé publique du propriétaire.

SesameDVR reçoit et stocke donc :

des segments vidéo chiffrés ;
les CEK chiffrées qui protègent ces segments.

La CEK en clair ne se trouve que dans la mémoire vive de l’agent et uniquement pendant sa période de validité. Après le renouvellement de la clé, l’agent oublie la CEK précédente.

Pendant l’enregistrement, la CEK en clair n’est jamais transmise au serveur.

Le code source de l’agent est ouvert. L’utilisateur du système peut vérifier lui-même que la gestion des clés fonctionne bien comme annoncé, contrôler les données que l’agent transmet au cloud et la manière dont le chiffrement est effectué. Il peut également compiler lui-même les fichiers exécutables de l’agent et utiliser précisément ceux-ci.

Une protection qui ne se limite pas aux employés de l’opérateur

Le problème de la vidéosurveillance dans le cloud ne tient pas seulement au fait que les employés de l’opérateur peuvent potentiellement consulter les enregistrements.

L’opérateur peut agir de façon consciencieuse, bien protéger son infrastructure et contrôler strictement les accès. Cela ne garantit toutefois pas que les données resteront toujours à l’intérieur de son système et sous son contrôle.

L’archive ou l’une de ses copies peut tomber entre les mains de tiers :

à la suite du piratage des serveurs multimédias ;
en cas de compromission d’un compte administrateur ;
à cause de la fuite d’une sauvegarde ;
en raison d’une erreur de configuration du stockage cloud ;
après le vol de matériel ou de supports de stockage ;
du fait des actions d’un prestataire ou d’un centre de données ;
lors de la saisie de serveurs, de disques ou de sauvegardes pendant une perquisition ou d’autres actes d’enquête.

Dans un système cloud classique, quiconque obtient un accès suffisamment complet à l’infrastructure de l’opérateur peut potentiellement obtenir aussi la possibilité de déchiffrer la vidéo.

Dans l’architecture de SesameDVR, la copie ou la saisie du stockage côté serveur ne révèle pas, à elle seule, le contenu des enregistrements.

L’opérateur ne détient que :

les segments vidéo chiffrés ;
les CEK chiffrées ;
les données techniques nécessaires à l’organisation de l’archive et à la lecture.

La clé privée du propriétaire ne s’y trouve pas.

Même si quelqu’un copie l’intégralité du stockage de SesameDVR — à la suite d’un piratage, de la fuite d’une sauvegarde, du vol de matériel ou de la saisie de serveurs — il n’obtiendra que des vidéos chiffrées et des clés chiffrées.

Le stockage cloud ne contient pas l’ensemble des données nécessaires pour consulter les enregistrements.

Nous ne nous contentons pas de limiter le nombre d’employés autorisés à regarder les vidéos. Nous cherchons à faire en sorte que, du côté de l’opérateur, tout ce qui est nécessaire à leur déchiffrement ne soit tout simplement jamais réuni.

Qu’est-ce que CBCS 1:9 Partial ?

La vidéo est stockée au format CMAF standard, avec SAMPLE-AES et le schéma de chiffrement cbcs 1:9.

Il ne s’agit ni d’un conteneur propriétaire de SesameDVR ni d’un nouveau codec vidéo propriétaire.

Les données vidéo sont divisées en blocs AES de 16 octets, puis un motif répétitif est appliqué :

1 bloc est chiffré
9 blocs sont ignorés
1 bloc est chiffré
9 blocs sont ignorés
...

Environ 10 % de la partie protégée du flux vidéo passe ainsi par AES.

Cela ne signifie toutefois pas qu’il est possible de voir les 90 % restants de l’image sans la clé. Un flux vidéo H.264 ou H.265 n’est pas constitué de pixels indépendants ou de fragments d’image distincts.

Il s’agit d’une séquence de données compressées et interdépendantes. Les blocs chiffrés sont répartis à l’intérieur des échantillons vidéo ; sans la bonne CEK, le décodeur ne peut donc pas reconstruire correctement les images.

Le chiffrement partiel est ici une optimisation délibérée. Il réduit considérablement la charge du petit agent matériel, tout en conservant le format CMAF standard et la compatibilité avec les décodeurs multimédias intégrés.

Les données audio, quant à elles, sont intégralement chiffrées.

Comment l’utilisateur regarde la vidéo

Deux modes de lecture sont prévus.

Déchiffrement intégralement côté client

Dans le mode principal, SesameDVR envoie au navigateur :

les segments vidéo chiffrés ;
les CEK chiffrées correspondant à la période sélectionnée.

L’utilisateur charge localement sa clé privée. Le navigateur installé sur son appareil déchiffre les CEK nécessaires et les transmet à ClearKey.

ClearKey fait partie du standard de navigateur Encrypted Media Extensions — EME. Il s’agit d’une interface standard qui permet à une application web de transmettre des clés au sous-système multimédia intégré du navigateur afin de lire un flux CMAF chiffré.

Dans ce cas, ClearKey n’est utilisé ni comme système DRM commercial ni comme moyen de restreindre l’utilisateur. Il sert de passerelle standard entre les CEK déchiffrées localement et le décodeur vidéo matériel ou logiciel de l’appareil.

Avec ce mode de lecture :

la clé privée reste sur l’appareil de l’utilisateur ;
les CEK en clair ne sont pas transmises à SesameDVR ;
le serveur ne reçoit pas la vidéo en clair ;
le déchiffrement s’effectue directement pendant la lecture.

Ce mode est avant tout destiné aux navigateurs modernes basés sur Chromium ainsi qu’à Firefox. La possibilité de lire un flux donné dépend également du codec, du système d’exploitation et des capacités matérielles de l’appareil.

La propriété essentielle de l’architecture est préservée : l’opérateur transmet les données, mais ne reçoit pas les clés qui lui permettraient de les regarder.

Mode de compatibilité

Safari, iOS et certains lecteurs intégrés présentent des limitations avec ClearKey et le schéma de lecture retenu.

Un mode de compatibilité nécessitant une confirmation distincte est prévu pour ces appareils.

L’utilisateur ne déchiffre localement que les CEK nécessaires à l’intervalle d’enregistrement sélectionné et les transmet temporairement au serveur dans le cadre d’une session de courte durée.

SesameDVR déchiffre en mémoire vive uniquement les fragments demandés et les transmet à l’appareil dans un format qu’un lecteur classique peut reproduire.

La vidéo en clair et les clés temporaires ne sont alors pas enregistrées :

sur disque ;
dans un stockage permanent ;
dans un cache CDN partagé ;
dans un cache serveur de longue durée.

C’est le seul mode dans lequel le serveur acquiert temporairement la possibilité technique de déchiffrer la partie de l’archive sélectionnée par l’utilisateur.

Le mode de compatibilité est donc moins strict que le déchiffrement intégralement côté client. Il ne doit être activé qu’avec le consentement explicite de l’utilisateur et pour une durée limitée.

En contrepartie, ce mode permet de consulter l’archive sur les appareils qui ne prennent pas en charge le schéma intégralement côté client.

Il est possible de partager l’accès

Le propriétaire du flux peut créer des paires de clés distinctes pour différents utilisateurs :

pour lui-même ;
pour les membres de sa famille ;
pour le service de sécurité ;
pour ses employés ;
pour un destinataire temporaire ;
pour un système externe.

Lorsqu’un accès est accordé, les CEK sélectionnées sont également chiffrées avec la clé publique du destinataire.

Chaque destinataire les déchiffre avec sa propre clé privée. Il n’est donc pas nécessaire de communiquer à qui que ce soit la clé privée du propriétaire.

Il est ainsi possible d’accorder un accès :

à l’intégralité de l’archive ;
uniquement à certaines caméras ;
uniquement à une période déterminée ;
uniquement aux nouveaux enregistrements ;
à plusieurs utilisateurs disposant de clés indépendantes.

Pour révoquer un accès, il suffit de cesser de chiffrer les nouvelles CEK avec la clé publique du destinataire concerné.

Il est important de préciser honnêtement une limite inhérente à tout système d’accès : si une personne a déjà enregistré une vidéo déchiffrée ou obtenu les clés en clair d’une période donnée, il est impossible de l’obliger à supprimer ces données a posteriori.

La révocation de l’accès empêche d’obtenir de nouveaux enregistrements, mais ne peut pas annuler une transmission d’informations qui a déjà eu lieu.

Ce que l’opérateur pourra faire

Dans une telle architecture, l’opérateur de vidéosurveillance dans le cloud pourra :

recevoir le flux chiffré ;
l’enregistrer dans l’archive ;
construire une chronologie ;
stocker les métadonnées techniques ;
contrôler la durée de conservation ;
supprimer les anciens segments ;
transmettre les enregistrements chiffrés au propriétaire ;
fournir l’infrastructure de gestion des accès.

Mais sans la clé privée du propriétaire, l’opérateur ne pourra pas regarder lui-même la vidéo.

Même un administrateur disposant d’un accès complet aux serveurs multimédias et au stockage ne verra que des segments chiffrés et des clés chiffrées.

Il en va de même pour un pirate ayant obtenu une copie de la base de données, un prestataire ayant accès aux supports de stockage ou une personne en possession de l’infrastructure serveur saisie.

Cela ne signifie pas une sécurité absolue

Cette architecture répond à un objectif précis : protéger le contenu de l’archive contre la consultation par l’opérateur cloud et contre la compromission du stockage côté serveur.

Elle ne supprime toutefois pas la nécessité de protéger les autres éléments du système.

Un pirate peut, par exemple, toujours tenter :

d’accéder directement à la caméra avant le chiffrement ;
de pirater le réseau domestique ;
de remplacer ou de compromettre le Sesame Agent ;
de voler la clé privée du propriétaire ;
d’accéder à un appareil de l’utilisateur déjà déverrouillé ;
d’enregistrer la vidéo depuis l’écran pendant sa lecture.

En outre, le chiffrement du flux vidéo ne masque pas nécessairement toutes les métadonnées.

L’opérateur peut toujours connaître :

l’existence des caméras ;
l’heure d’arrivée des segments ;
la durée de l’archive ;
le volume des données transmises ;
les actions des utilisateurs dans l’interface.

SesameDVR ne rend pas la vidéo invulnérable en toutes circonstances. Il élimine l’un des problèmes les plus importants de la vidéosurveillance traditionnelle dans le cloud : l’existence, chez l’opérateur, d’une possibilité technique permanente de consulter l’archive du client.

Pourquoi de telles solutions sont rares

Il existe sur le marché quelques produits destinés aux entreprises avec des clés gérées par le client.

Mais les systèmes de vidéosurveillance cloud grand public utilisent généralement un autre modèle : la plateforme gère elle-même les clés et peut, si nécessaire, déchiffrer les données du client.

La particularité de l’approche de SesameDVR ne réside pas dans l’invention d’un nouvel algorithme de chiffrement, mais dans la combinaison de plusieurs caractéristiques :

fonctionnement avec des caméras RTSP ordinaires ;
agent local distinct, sans transcodage ;
absence d’accès direct du cloud aux caméras ;
format CMAF standard avec cbcs ;
lecture au moyen des mécanismes standard du navigateur ;
conservation locale de la clé privée ;
possibilité d’accorder un accès grâce au chiffrement supplémentaire des CEK ;
code source ouvert de l’agent.

Stocker ne signifie pas posséder la clé

Au fil des années de développement de la vidéosurveillance dans le cloud, nous avons pris l’habitude de penser que, si une vidéo est stockée sur le serveur de l’opérateur, celui-ci peut forcément la regarder.

Ce n’est pourtant pas une condition nécessaire.

Un serveur peut stocker des téraoctets d’enregistrements, les indexer, les supprimer à l’expiration de leur durée de conservation et les transmettre au propriétaire sans disposer de la clé nécessaire pour les regarder.

L’opérateur ne devrait pas avoir à se contenter de promettre que ses employés ne regarderont pas vos vidéos.

Il ne suffit pas non plus de bien protéger les serveurs : en théorie, tout serveur peut être piraté, copié, volé ou saisi.

Il est possible de construire un système de telle sorte que ni l’administrateur habituel, ni un pirate ayant obtenu une copie du stockage, ni une personne en possession des disques du serveur ne reçoive avec l’archive la possibilité de la déchiffrer.

Stocker une vidéo ne signifie pas nécessairement avoir accès à son contenu.

C’est précisément ce modèle que nous mettons en œuvre dans SesameDVR.