Les certificats sont la partie essentielle du workflow sécurité du cinéma numérique normé par le SMPTE et DCI.
Les spécifications DCI et la normalisation SMPTE définissent que la cryptographie asymétrique utilisée dans le cadre du cinéma numérique est la cryptographique asymétrique RSA.
Pour rappel, la cryptographie asymétrique nécessite de créer deux types de clefs, chacune ayant un rôle spécifique : une clef privée et une clef publique. La clef privée servant à déchiffrer (ou signer) et la clef publique servant à chiffrer (ou à vérifier la signature d'un document signé par la clef privée).
Lors de la diffusion de la clef publique, vous pouvez soit diffuser la clef publique brute, sans aucune fioriture. Elle intègrera les valeurs cryptographiques utiles pour le chiffrement (appelés modulus et exposant, que nous croisons par la suite dans ce chapitre mais qui sont détaillées dans le chapitre RSA), soit vous pouvez intégrer cette clef publique dans un containeur et l'accompagner de plus amples informations - des métadonnées - comme une identification, des dates de validité, le nom du parent ou toutes autres informations, qui permettrait d'en savoir plus sur cette clef publique ou même d'en faire la gestion.
Les métadonnées représentent parfois beaucoup plus de données que la clef publique en elle-même :)
En résumé: un certificat n'est qu'une fiche signalétique incorporant des informations et la clef publique. Voyez cela comme une enveloppe : à l'intérieur de l'enveloppe, votre clef (publique). A l'extérieur, l'adresse du destinataire, de l'expéditeur, etc...
Qui utilise ces certificats et pourquoi ?
Les certificats sont utilisés à plusieurs reprises dans le workflow DCI :
CompositionPlaylist (CPL) : Pour l'authenticité et l'intégrité - à l'aide d'une signature.
PackingList (PKL) : Pour l'authenticité et l'intégrité également - à l'aide d'une signature.
KDM : Pour l'authenticité, l'intégrité mais surtout pour la confidentialité : pour le chiffrement.
Certificats : Créér et signer toute la chaîne de certifications (nous verrons ce concept dans ce chapitre).
Les certificats sont utilisés par tout appareil respectant les spécifications DCI (et donc SMPTE), ainsi vous aurez - principalement - des certificats pour les players DCP, les encodeurs DCP et les générateurs de KDM.
Les certificats sont principalement échangés entre laboratoires et exploitants de cinéma pour pouvoir chiffrer et signer des KDM. 1
Et dans quels contextes ?
On va utiliser les certificats dans des cas comme :
Lors de la création d'un KDM : pour chiffrer les parties du KDM (CipherValue) qui seront déchiffrées par un récepteur 2, nous utiliserons le certificat public du dit-récepteur. Le certificat public de l'encodeur va être intégré dans le KDM.
Quand on va créer un DCP : PKL et CPL vont être signés par la clef privée de l'encodeur. Son certificat publique sera donc intégré dans PKL et CPL.
Peut-on utiliser n'importe quel type de certificat ?
Réponse rapide : non :-)
Un certificat DCI / SMPTE respecte une structure de données normée par le standard X509 et sur sa version 3 qui ajoute des extensions utiles pour nos besoins spécifiques.
Pour la suite des chapitres sur les certificats, je nommerais un certificat respectant les normes SMPTE et les spécifications DCI, un Certificat x509 DCI ou Certificat DCI, afin de bien faire la différence avec les autres types de certificat x509 utilisés dans d'autres domaines.
A l'intérieur d'un certificat x509 DCI
La plupart des certificats sont délivrés sous forme de fichier avec l'extension .pem3, ils sont lisibles simplement via un simple éditeur :
Et le format ASN.1 est une structure normée pour décrire et stocker les informations (sérialisation) du certificat x509, dans une structure binaire, appelée DER (Distinguished Encoding Rules).
Si nous enlevons notre surcouche base64, voici ce que nous trouvons :
Nous avons des parties lisibles dans la colonne à droite
Elle débute par un 0x3082 : c'est un entête typique d'une structure ASN.1 DER4
Si nous passons notre sortie au format ASN.1 DER dans un parseur ASN.1, nous allons voir toutes les entrées composant le certificat :
openssl base64 -d -in certificate.pem \
| openssl asn1parse \
-inform DER \ # notre input sera au format DER
-i \ # petite indentation
-dump # dump hex form
Oui, ça pique (encore trop) les yeux, même avec l'aide colorimétrique.
Ceci est la structure ASN.1 DER d'un certificat x509 DCI - avec ses différents tags (SEQUENCE, INTEGER, OBJECT, BITSTRING, etc.).
Vous allez me demander pourquoi je vous montre cela, on est pas là pour souffrir. Je suis obligé de vous montrer ceci car elle aura son importance lors de certains calculs d'empreintes que nous verrons un peu plus tard dans les prochains chapitres.
Cela reste assez illisible pour le quidam qui n'a pas fait un master RFC et une thèse sur l'ASN.1.
Fort heureusement, OpenSSL nous permet d'interpréter sa structure avec une sortie plus lisible :
openssl x509 -in certificate.pem -text
Data:
Version: 3 (0x2)
Serial Number: 643 (0x283)
Signature Algorithm: sha256WithRSAEncryption
Issuer: O = DC2.SMPTE.DOREMILABS.COM, OU = DC.DOREMILABS.COM, CN = .DC.DMS.DC2.SMPTE, dnQualifier = "+LLvuYNO4YBJSp9Jjmlv8oippzQ="
Validity
Not Before: Jan 1 00:00:00 2007 GMT
Not After : Dec 31 23:59:59 2025 GMT
Subject: O = DC2.SMPTE.DOREMILABS.COM, OU = DC.DOREMILABS.COM, CN = CS.DMSJP2K-80119.DC.DC2.SMPTE, dnQualifier = SQFYSSqWwjefppqasMJmfdmS6lI=
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:bc:62:a5:fb:33:4f:73:58:2a:6a:03:37:2b:52:
62:4e:17:1a:41:6f:6e:f4:c3:98:b5:32:4c:4d:54:
62:c4:e7:ee:e6:c1:88:39:80:05:7f:a1:66:49:fe:
55:9d:e1:06:1b:db:5d:fe:23:7a:1a:99:48:d5:ee:
6e:a5:3b:e4:cb:0d:42:4e:68:ae:02:9d:e9:a9:ca:
8b:84:cf:2f:c8:f9:ed:ce:5a:08:09:33:71:7b:d0:
08:8a:e3:a7:25:03:b5:92:12:c6:51:0d:69:80:3e:
4c:be:97:f2:6b:fe:08:8a:a9:ea:f2:ea:51:f3:83:
e8:2e:79:ec:10:ab:e8:c5:eb:97:6b:58:8b:ac:2c:
83:67:29:0f:ed:86:e7:f1:4e:66:bb:37:40:aa:bf:
58:46:e1:73:17:36:db:ab:c1:5c:af:3d:6e:3e:1c:
8a:78:ad:22:eb:e6:50:55:d7:d3:f3:1c:b8:06:e3:
46:41:cb:9c:8a:63:c6:a0:89:ae:fb:6c:9f:35:b1:
1c:7c:54:1f:7c:30:39:6c:6c:d1:db:f5:c3:25:32:
c4:6a:a3:70:7b:f5:97:67:21:a8:91:9b:48:47:39:
85:25:81:9b:e1:9c:be:a5:81:96:20:ae:6e:9a:e8:
63:34:51:13:b9:f3:48:e3:c9:b2:6c:d6:6d:7a:5a:
63:23
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Key Usage:
Digital Signature, Key Encipherment, Data Encipherment
X509v3 Subject Key Identifier:
49:01:58:49:2A:96:C2:37:9F:A6:9A:9A:B0:C2:66:7D:D9:92:EA:52
X509v3 Authority Key Identifier:
keyid:F8:B2:EF:B9:83:4E:E1:80:49:4A:9F:49:8E:69:6F:F2:88:A9:A7:34
DirName:/O=DC2.SMPTE.DOREMILABS.COM/OU=DC.DOREMILABS.COM/CN=.DMS.DC2.SMPTE/dnQualifier=RQ\/53RmuLsbzgfPXGlRYmJruwMs=
serial:02
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
3c:1a:59:e9:39:20:f5:36:60:d8:b6:a6:2d:a3:82:3c:4e:a2:
9e:00:6f:aa:6b:10:1d:1e:55:e1:bf:7d:b0:d5:3f:12:f7:46:
2f:67:89:8d:91:70:e1:82:ec:c5:a1:26:3e:9a:48:18:57:4c:
20:4f:90:24:7a:c4:0f:96:0b:68:9f:62:d5:5b:d3:6c:3d:63:
35:fa:dc:95:6e:12:6d:ce:be:9a:54:0a:14:2e:af:38:3e:7f:
82:8d:e1:2d:80:bc:03:9c:3d:d9:e6:bb:e6:25:fb:ed:2b:83:
d0:30:83:d4:62:2c:e8:52:f7:10:64:ab:31:70:b9:f4:71:4a:
e1:a8:67:22:4c:5c:53:28:55:ef:90:a7:d7:8b:a3:68:e4:29:
88:ef:b3:07:1a:ff:55:a8:bf:3c:36:68:cb:a2:92:9b:4c:98:
24:48:7d:ee:ae:3e:bd:06:10:95:15:92:3f:57:05:f4:88:cb:
ba:ca:d8:05:38:d4:df:47:fb:af:28:0e:47:8b:dc:a8:bf:31:
9c:d4:21:62:9a:c1:94:90:67:f8:a4:b7:16:a3:4a:b6:b5:28:
1d:31:74:62:d2:e5:e0:8e:65:f7:4a:1c:b6:5f:af:b5:03:46:
5b:1a:b8:c5:4d:f7:0e:ef:6a:5c:e0:57:04:4f:61:79:27:c6:
dc:2b:26:57
En vert, nous avons les données d'identifications principalement.
En orange est la clef public (modulus et son exposant, voir chapitre RSA pour mieux comprendre).
En bleu, nous avons les extensions x509v3 très utiles pour comprendre le rôle de ce certificat.
Et enfin, en rose, la signature de ce certificat.
Chaque entrée est appelé « Champ » ou « Field » ( nous les étudierons un par un dans le prochain chapitre )
Autres visualiseurs de certificats
Vous avez aussi la possibilité de prévisualiser les métadonnées d'un certificat via d'autres différents outils, par exemple, sous MacOS, via l'outil KeyChain :
Ou également la possibilité de visualiser via des outils en ligne :
Site
Description
Niveau
https://certificatedecoder.dev
Visualiseur x509 minimaliste
Débutant
https://certlogik.com/decoder
Visualiseur x509 complet + visualisateur structure ASN.1 normée RFC
Intermédiaire
https://www.lapo.it/asn1js
Visualiseur de la structure ASN.1 en mode binaire et normée RFC
Expert
Vous pouvez faire des tests sur les différents sites en effectuant un copier/coller du certificat public ci-dessous :
Nous avons rapidement vu ce qu'était un certificat, nous pouvons voir maintenant ce que représente chaque entrée - que nous avons aperçu rapidement dans les différentes visualisations - grâce au chapitre suivant sur les champs (fields) d'un certificat x509 DCI.
Entre autres. Nous avons d'autres cas, comme des échanges de certificats entre laboratoires pour des échanges de clefs AES par exemple. Les certificats étant publics, vous pouvez les retrouver sur les sites des différents constructeurs. ↩
Par exemple, un player DCP ou un autre encodeur - qui va recevoir un DKDM :) ↩
L'extension n'est qu'une convention de nommage. On peut trouver des certificats stockés dans fichiers ayant l'extension .txt, .crt, .cert, etc. A noter également que ces certificats peuvent être délivrés même en dehors d'un fichier, par exemple si vous demandez un certificat via l'API du player, il vous délivrera un flux contenant le certificat directement. Aucune obligation d'être dans un fichier donc :) ↩
Pour être plus précis, ASN.1 respecte le TLV qui est ... comme un KLV ;-) ↩
TLV voulant dire Type (ou Tag suivant les inspirations des auteurs) LengthValue,
