LA MISE EN PLACE D'UN PIPELINE DE TRANSCODAGE CRYPTÉ DE BOUT EN BOUT

Photo de JESS R
JESS R
blog-placeholder image

Pour de nombreux clients de Zencoder, la sécurisation de leur contenu pendant le processus de transcodage est une priorité absolue. Maintenant que Zencoder prend en charge les entrées cryptées, les clients peuvent s'assurer que leurs données ne sont jamais stockées en clair lorsqu'elles transitent par Zencoder. En bref, Zencoder peut accepter des entrées cryptées, les décrypter pour le transcodage, puis recrypter les vidéos de sortie avant de les écrire dans un emplacement de stockage. L'importance de ce flux de travail réside dans le fait que les entrées et les sorties sont alors protégées. Si un utilisateur non autorisé parvenait à accéder à ces fichiers cryptés, il ne pourrait pas les visualiser sans la paire clé/IV utilisée pour les crypter. Voyons à quoi ressemblerait ce processus. Avant de commencer, nous avons besoin d'une entrée chiffrée. Pour cet exemple, nous allons crypter un fichier localement à l'aide d'OpenSSL, puis le télécharger sur S3 avant de créer la tâche de transcodage.

$ openssl aes-256-cbc -k zencoderisawesome -in trailer_test.mp4 -out trailer_test.mp4.enc -p

Le -k est le secret que nous voulons utiliser, qui dans ce cas est "zencoderisawesome". Le drapeau -p indique à OpenSSL d'imprimer la clé lorsqu'il a terminé, ce dont nous aurons besoin pour le décryptage plus tard. Pour nous, la sortie ressemblait à ceci :

salt=9E7E90A964768A2F
key=DAFF64EAE3B3AB9C7905871E407293D4987E16DE76578372E161B1261F39CD66
iv =375FDBBB213C062D544FCB5A6ACBA44E

Le fichier est maintenant crypté, vous ne devriez donc pas pouvoir le lire comme vous l'auriez fait auparavant. Nous devons maintenant télécharger le fichier sur S3 ou sur un serveur FTP quelque part pour que Zencoder puisse y accéder. Nous allons utiliser l'interface de téléchargement de S3.Chargement S3Il est temps de construire la demande. Nous utiliserons l'élément Bibliothèque Node.js pour envoyer la requête dans ces exemples, mais les mêmes requêtes pourraient également être envoyées à l'aide d'un autre outil tel que l'outil Demande de constructeur. Nous devrons spécifier la clé de cryptage et l'IV que nous avons utilisés ci-dessus pour l'entrée.

var zencoder = require('zencoder')();
zencoder.Job.create({
  input: "s3://zencoder-demo/trailer_test.mp4.enc",
  decryption_method: "aes-256",
  decryption_key: "DAFF64EAE3B3AB9C7905871E407293D4987E16DE76578372E161B1261F39CD66",
  decryption_password: "zencoderisawesome"
}, function(err, data) {
  if (err) {
    console.log("Job wasn't created");
    return console.log(err);
  }
  console.log("Woo!");
  console.log(data);
});

Cela suffirait à créer une sortie h.264 standard, mais elle ne serait en aucun cas cryptée. Cela peut parfois s'avérer utile, car vous pouvez prendre un fichier mezzanine crypté (un fichier de très haute qualité utilisé pour créer d'autres sorties de moindre qualité) et l'utiliser pour des sorties filigranées ou de moindre qualité à des fins de distribution. Imaginons que nous voulions prendre un fichier mezzanine et le télécharger vers trois services différents. Nous voulons qu'une sortie soit une version non cryptée, de faible qualité, avec un filigrane, et que les deux autres soient cryptées à l'aide de deux clés différentes, l'une avec un filigrane d'identification et l'autre sans. Avant de pouvoir créer cette requête, nous devons générer les deux clés que nous allons utiliser. Nous utiliserons à nouveau OpenSSL pour créer ces nouvelles clés :

$ openssl enc -aes-256-cbc -k supersecret -P
salt=12B83BBF81DFA5B7
key=48A9E3FA8A629AEBA5B4F1FAC962920F0D7084E306E0D01A0ED01C920BBCBD08
iv =2B3CABAB503198DB32394245F54E2A34

$ openssl enc -aes-256-cbc -k anothersecret -P salt=DE2DE044EA5FEB2A key=3AAE9D6E5212224BB9F76E328D2BD826F17B4FC292845B6E3B72634D2C28052D iv =169C3DE53C56E74130CDA57BA85F8255

Nous pouvons maintenant utiliser ces clés pour crypter les sorties pendant le processus de transcodage.

zencoder.Job.create({
  input: "s3://zencoder-demo/trailer_test.mp4.enc",
  decryption_method: "aes-256",
  decryption_key: "DAFF64EAE3B3AB9C7905871E407293D4987E16DE76578372E161B1261F39CD66",
  decryption_password: "zencoderisawesome",
  outputs: [
    {
      url: 's3://some-bucket/decrypted.mp4',
      quality: 3,
      width: 320,
      watermarks: [{
        url: 's3://zencoder-live/test-job-watermark.png'
      }]
    },
    {
      url: 's3://some-other-bucket/encrypted-watermarked.mp4',
      width: 720,
      watermarks: [{
        url: 's3://zencoder-live/test-job-watermark.png'
      }],
      encryption_method: "aes-256",
      encryption_key: '48A9E3FA8A629AEBA5B4F1FAC962920F0D7084E306E0D01A0ED01C920BBCBD08',
      encryption_iv: '2B3CABAB503198DB32394245F54E2A34'
    },
    {
      url: 's3://some-bucket/encrypted-out.mp4',
      width: 720,
      encryption_method: "aes-256",
      encryption_key: '3AAE9D6E5212224BB9F76E328D2BD826F17B4FC292845B6E3B72634D2C28052D',
      encryption_iv: '169C3DE53C56E74130CDA57BA85F8255'
    }
  ]
}, function(err, data) {
  if (err) {
    console.log("Job wasn't created…");
    return console.log(err);
  }
  console.log("Woo!");
  console.log(data);
});

Omettre le cryptage d'une sortie et en crypter deux autres séparément peut sembler une chose farfelue, mais considérez le cas d'utilisation. La sortie de faible qualité pourrait être utilisée comme échantillon (vous pourriez même créer un clip plus court à cette fin). L'une des versions de haute qualité comporte un filigrane identifiant la personne à laquelle la vidéo a été téléchargée. Vous pouvez donc lui fournir la clé pour décrypter et regarder, et si la vidéo est retrouvée hors de son contrôle, vous savez de qui il s'agit. La troisième copie, non filigranée, sera téléchargée dans un répertoire que nous contrôlons, afin que nous puissions l'utiliser pour une distribution ultérieure. Une fois que vous avez un de ces fichiers cryptés localement, vous pouvez le décrypter en utilisant un processus similaire à celui que nous avons utilisé pour le crypter à l'origine. Pour décrypter le fichier en filigrane : $ openssl enc -aes-256-cbc -d -K 48A9E3FA8A629AEBA5B4F1FAC962920F0D7084E306E0D01A0ED01C920BBCBD08 -iv 2B3CABAB503198DB32394245F54E2A34 -in encrypted-watermarked.mp4 -out decrypted-watermarked.mp4 Pour décrypter le fichier sans le filigrane : $ openssl enc -aes-256-cbc -d -K 3AAE9D6E5212224BB9F76E328D2BD826F17B4FC292845B6E3B72634D2C28052D -iv 169C3DE53C56E74130CDA57BA85F8255 -in encrypted-out.mp4 -out decrypted-out.mp4 Et voilà ! Vous avez maintenant un pipeline d'encodage crypté de bout en bout. Le fichier crypté utilisé dans ces exemples est disponible à cet emplacement et a été crypté en utilisant ces informations d'identification, alors n'hésitez pas à l'utiliser comme fichier de test. Juste une noteIl ne faut pas confondre cela avec la gestion des droits numériques (DRM). Une solution DRM digne de ce nom gère des éléments tels que les droits d'accès au contenu, qui peuvent être beaucoup plus granulaires, jusqu'à certains appareils et utilisateurs. Les fichiers cryptés ne peuvent être consultés qu'avec la clé de cryptage et le mot de passe associé, mais c'est le seul critère.

Partager

Brightcove a aidé la place de marché automobile la plus reconnue à gérer son énorme vidéothèque et à la rentabiliser...
Pour préserver l'intégrité de leur marque, les enseignes de distribution ont besoin de lecteurs vidéo personnalisables qui leur permettent d'ajuster les couleurs, la police...
Savoir média propose un contenu vidéo unique à son public

PRÊT À COMMENCER ?

Contactez-nous pour savoir comment nous pouvons améliorer vos efforts de marketing vidéo et vous aider à générer les résultats et le retour sur investissement dont vous avez besoin.