Il me semble que les clés de lecture des DCP dans les cinémas permettent de limiter très précisément le nombre de lectures, les dates autorisées, le type de matériel, etc... Dans ce cadre de verrou numérique, je vois pas bien comment ouvrir le format totalement sans péter toute la logique de verrouillage qui va avec.
Les deux ne sont pas antinomiques.
Pour cela, il faut démystifier toute la partie cryptographie du DCP avec ses clés.
Je vais essayer de résumer.
Un DCP est chiffré (s’il l’est, ce n’est pas obligatoire) via un ou plusieurs clés AES (128-CBC) - pour être plus précis, ce sont les fichiers MXF qui sont chiffrés - et pour être encore plus précis, ce ne sont que les layers (KLV) contenant les assets (images, audios, autres) qui le sont (le MXF n’est pas totalement chiffré, seulement les images/audios/autres intégrées dedans). Une ou plusieurs clefs AES peuvent chiffrer un ou plusieurs MXF. (en général, on recommande 1 MXF = 1 clef AES), un DCP peut avoir plusieurs MXF (au moins 2: les images et le son)
Quand il faut distribuer le film en salle, les clés AES ne sont pas distribuées comme cela, elles sont chiffrées via le certificat public du matériel en salle (RSA) puis intégrées dans un ou plusieurs containers cryptographiques (CipherValue) stockées dans un gros fichier XML intégrant des métadatas pour leurs gestions (KDM aka « Key Delivery Message »). Ce sont ces fichiers qui sont envoyés au cinéma.
Jehan a assez bien résumé les raisons et les besoins de ce workflow :
Un DCP, c’est environ entre 70 à 300G (voire plus si on fait de la 3D en 120 FPS en 4DX, etc..), il faut envoyer plusieurs copies aux différentes salles. Si un film doit être envoyé à 500 salles, il faudrait donc chiffrer 500 fois plusieurs gigas: c’est une perte de temps pour le laboratoire. Il suffit de chiffrer une fois le DCP référent (par exemple « STARWARS-3-VF ») et de l’envoyer dans les salles. Puis de chiffrer une petite clef AES 128 bits, 500 fois, avec le certificat de chaque player des différentes salles qui veulent/peuvent diffuser le film, c’est beaucoup plus rapide :)
Je vais aussi démystifier un autre truc de suite : Techniquement, pour déchiffrer un DCP, il suffit simplement des clefs AES. Rien de plus.
Le reste (KDM), c’est du folklore pour la distribution (et surtout pour respecter le workflow de distribution DCI et garantir une certaine sécurité des données même quand ils sont dans les players dans les différentes salles).
A titre de comparaison foireux: c’est comme mettre une clef de maison dans un colis et l’envoyer par la poste. (imagine que le colis soit un coffre dont le seul détenteur de la clef (ou une combinaison) permettant de l’ouvrir est celui qui va réceptionner le colis). C’est la clef de la maison qui permettra d’ouvrir la porte de la maison, pas le colis.
Quand on te dit qu’il faut des clés de lecture avec les dates autorisées, le type de matériel, etc. (pas le nombre de lecture), on doit te parler des KDM. Ce gros fichier XML contient quelques metadatas - dont notamment les informations techniques du film, la date de début et de fin (informatives seulement), les informations cryptographiques RSA, dont le Signer (celui qui a fait ce KDM) et le Recipient (celui va le déchiffrer : le player) et d’autres trucs qui seraient trop long à résumer. Et bien entendu, des containers cryptographiques (CipherValue) qui ne peuvent être déchiffrés que par celui qui détient le certificat privé (le player).
Quand on a déchiffré ces containers cryptographiques (via RSA, donc crypto asymétrique), ils contiennent des metadatas: Un ID, un thumbprint, un autre ID, le type du MXF, l’ID de la clef, les dates début-fin et enfin, la fameuse clef AES sur 128 bits.
A partir de là, tu comprends que si tu fais ton certificat RSA, tu génères un cert public, tu envoies cela pour avoir un DCP chiffré, tu peux déchiffrer la partie CipherValue, tu récupères les clefs AES pour déchiffrer tes MXF et tu peux ignorer les obligations. (aucun labo n’acceptera ton certificat louche :) mais techniquement, il sera valide)
Dans une autre mesure, tu peux aussi faire ton propre DCP : tu génères tes propres clefs AES et tu chiffres tes MXF. Tu as maintenant toute la liberté de la méthode d’envoi et de réception des clefs AES auprès de ton interlocuteur: soit tu es joueur et tu les envoies en clair (mais on sait que c’est pas bien), soit tu demandes à ton interlocuteur son certificat public pour chiffrer un message: tu viens de créer un ersatz de KDM (note que ceci n’est pas le workflow DCI pour la distribution en salle, nous aurons toujours un couple DCP chiffré avec des clefs AES + KDM avec clefs AES chiffrés par un certificat public)
Petit bonus : il existe aussi ce qu’on appelle DKDM, ce sont simplement des KDM - mais avec un autre nom - qui ne sont pas à destination des salles de cinéma, mais des laboratoires ou autres professionnels : Cela permet de s’échanger des clefs AES entre professionnels (par exemple, un labo qui doit générer des KDM mais pour un DCP qu’un autre laboratoire à fait)
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Prae . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. Évalué à 6.
Les deux ne sont pas antinomiques.
Pour cela, il faut démystifier toute la partie cryptographie du DCP avec ses clés.
Je vais essayer de résumer.
Un DCP est chiffré (s’il l’est, ce n’est pas obligatoire) via un ou plusieurs clés AES (128-CBC) - pour être plus précis, ce sont les fichiers MXF qui sont chiffrés - et pour être encore plus précis, ce ne sont que les layers (KLV) contenant les assets (images, audios, autres) qui le sont (le MXF n’est pas totalement chiffré, seulement les images/audios/autres intégrées dedans). Une ou plusieurs clefs AES peuvent chiffrer un ou plusieurs MXF. (en général, on recommande 1 MXF = 1 clef AES), un DCP peut avoir plusieurs MXF (au moins 2: les images et le son)
Quand il faut distribuer le film en salle, les clés AES ne sont pas distribuées comme cela, elles sont chiffrées via le certificat public du matériel en salle (RSA) puis intégrées dans un ou plusieurs containers cryptographiques (CipherValue) stockées dans un gros fichier XML intégrant des métadatas pour leurs gestions (KDM aka « Key Delivery Message »). Ce sont ces fichiers qui sont envoyés au cinéma.
Jehan a assez bien résumé les raisons et les besoins de ce workflow :
Un DCP, c’est environ entre 70 à 300G (voire plus si on fait de la 3D en 120 FPS en 4DX, etc..), il faut envoyer plusieurs copies aux différentes salles. Si un film doit être envoyé à 500 salles, il faudrait donc chiffrer 500 fois plusieurs gigas: c’est une perte de temps pour le laboratoire. Il suffit de chiffrer une fois le DCP référent (par exemple « STARWARS-3-VF ») et de l’envoyer dans les salles. Puis de chiffrer une petite clef AES 128 bits, 500 fois, avec le certificat de chaque player des différentes salles qui veulent/peuvent diffuser le film, c’est beaucoup plus rapide :)
Je vais aussi démystifier un autre truc de suite : Techniquement, pour déchiffrer un DCP, il suffit simplement des clefs AES. Rien de plus.
Le reste (KDM), c’est du folklore pour la distribution (et surtout pour respecter le workflow de distribution DCI et garantir une certaine sécurité des données même quand ils sont dans les players dans les différentes salles).
A titre de comparaison foireux: c’est comme mettre une clef de maison dans un colis et l’envoyer par la poste. (imagine que le colis soit un coffre dont le seul détenteur de la clef (ou une combinaison) permettant de l’ouvrir est celui qui va réceptionner le colis). C’est la clef de la maison qui permettra d’ouvrir la porte de la maison, pas le colis.
Quand on te dit qu’il faut des clés de lecture avec les dates autorisées, le type de matériel, etc. (pas le nombre de lecture), on doit te parler des KDM. Ce gros fichier XML contient quelques metadatas - dont notamment les informations techniques du film, la date de début et de fin (informatives seulement), les informations cryptographiques RSA, dont le Signer (celui qui a fait ce KDM) et le Recipient (celui va le déchiffrer : le player) et d’autres trucs qui seraient trop long à résumer. Et bien entendu, des containers cryptographiques (CipherValue) qui ne peuvent être déchiffrés que par celui qui détient le certificat privé (le player).
Quand on a déchiffré ces containers cryptographiques (via RSA, donc crypto asymétrique), ils contiennent des metadatas: Un ID, un thumbprint, un autre ID, le type du MXF, l’ID de la clef, les dates début-fin et enfin, la fameuse clef AES sur 128 bits.
A partir de là, tu comprends que si tu fais ton certificat RSA, tu génères un cert public, tu envoies cela pour avoir un DCP chiffré, tu peux déchiffrer la partie CipherValue, tu récupères les clefs AES pour déchiffrer tes MXF et tu peux ignorer les obligations. (aucun labo n’acceptera ton certificat louche :) mais techniquement, il sera valide)
Dans une autre mesure, tu peux aussi faire ton propre DCP : tu génères tes propres clefs AES et tu chiffres tes MXF. Tu as maintenant toute la liberté de la méthode d’envoi et de réception des clefs AES auprès de ton interlocuteur: soit tu es joueur et tu les envoies en clair (mais on sait que c’est pas bien), soit tu demandes à ton interlocuteur son certificat public pour chiffrer un message: tu viens de créer un ersatz de KDM (note que ceci n’est pas le workflow DCI pour la distribution en salle, nous aurons toujours un couple DCP chiffré avec des clefs AES + KDM avec clefs AES chiffrés par un certificat public)
Petit bonus : il existe aussi ce qu’on appelle DKDM, ce sont simplement des KDM - mais avec un autre nom - qui ne sont pas à destination des salles de cinéma, mais des laboratoires ou autres professionnels : Cela permet de s’échanger des clefs AES entre professionnels (par exemple, un labo qui doit générer des KDM mais pour un DCP qu’un autre laboratoire à fait)