Mécanisme de contrôle d'authenticité des photographies numériques dans les réflexes Canon

1. Le format RAW/CR2 et l'usage du tag ODD

Les photographies numériques sont écrites sur la carte mémoire en format RAW (basé sur le format TIFF) ou au format Jpeg. Malgré les efforts de Dave Coffin avec Dcraw [3], Phil Harvey avec ExifTool [4] et de votre serviteur [5] pour le format CR2 de Canon, une partie des tags TIFF (ou Jpeg) ne sont pas documentés : vous ne maîtrisez pas complètement de quelle manière sont archivés les originaux de vos souvenirs de vacances. En l’occurrence, c'est le cas du tag « Original Decision Data », qui porte l'identifiant unique 0x0083 (131 en décimal). Lorsque cette option est activée, via le menu, l'appareil ajoute ce « sceau » à chaque image. L'authenticité des images peut ensuite être vérifiée grâce à un kit vendu par Canon [6]. Il est même possible de chiffrer les images sur les appareils haut de gamme uniquement, en insérant dans le boîtier une carte Secure Mobile dédiée, mais l'algorithme sous-jacent n'est pas décrit à ce jour. Les images au format Jpeg contiennent aussi des métadonnées, et peuvent également contenir un tag ODD, de format quasi-identique.

2. Que peut-on apprendre par observation du tag ODD ?

Pour commencer, analysons le contenu du tag ODD pour le modèle 20D, car son format (version 2) est plus simple que sur les appareils récents (version 3). Il ne s'agit pas dans cette première partie d'expliquer complètement le mécanisme de contrôle d'authenticité(Message Authentication Code, MAC dans la langue de Benny Hill), mais d'offrir un simple aperçu.

ExifTool nous donne l'offset du tag dans le fichier image :

Voici donc les données stockées à l'offset 7259830, (0x6ec6b6 en hexadécimal), quelque peu mises en forme. Les lignes sont numérotées pour faciliter le commentaire. Se reporter à l'encart pour appréhender le format TIFF/CR2 et comment localiser les données ODD dans un fichier image issu du 20D.

Les lignes 2, 4, 5, 6 et 7 semblent contenir chacune une empreinte SHA1 (les 20 derniers octets, à grande entropie), ou plutôt des données de contrôle d'authenticité HMAC-SHA1 [7] puisque le rôle de ces données est d'être capable d'authentifier les données images. Les 4 dernières lignes sont au même format, commençant par un entier sur 32 bits (long) au format Intel (http://en.wikipedia.org/wiki/Endianness), sans doute le numéro de la « section ». La ligne 3 dénombre ces enregistrements identiques, toujours en Little Endian.

Revenons au format TIFF : l'offset des données de l'image principale et leur taille sont données par :

respectivement 603338 (0x934ca) et 6656492 (0x6591ec). On retrouve (au format Intel) ces 2 valeurs dans le Tag ODD à la ligne 4, colonnes 2 et 3. La colonne 2 contient donc l'offset vers l'image principale et la 3e colonne la taille de cette « section ». Enfin, on peut penser que les supposés HMAC-SHA1 sont calculés à chaque fois à partir de l'offset (colonne 2) et pour la taille indiquée en colonne 3.

Pourquoi donc avoir besoin de plusieurs HMAC au lieu d'un unique code d'authenticité pour le fichier ? C'est pour authentifier également les métadonnées. Même si le tag est à la fin du fichier (0x934ca + 0x6591ec = 0x6ec6b6), il faut respecter le format TIFF et écrire l'offset vers les données du tag ODD dans le répertoire TIFF, précisément entre les offsets 0x37a (ligne 6, 0x308+0x72) et 0x37e (ligne 7). La dernière zone exclue du calcul de la signature correspond à la valeur du tag « Orientation » (paysage ou portrait), que l'utilisateur peut modifier ultérieurement à l'enregistrement de l'image sur la carte mémoire.

En résumé, une empreinte garantissant l’intégrité est calculée sur chacune des 4 régions du fichier TIFF. La ligne 2 ne décrivant pas de région, elle concerne certainement le fichier dans son ensemble, c'est-à-dire, on peut le supposer, en agrégeant les quatre HMAC-SHA1 des lignes 4 à 7. Tout ceci est illustré dans la figure 1.

Il n'est malheureusement pas possible de comprendre la totalité de l'algorithme sans analyser le logiciel interne (firmware) de l'appareil photo. C'est ce qu'a fait Dmitry Sklyarov : reportez-vous à sa présentation [1] pour les détails, à l'exception toutefois des clés HMAC. Pour la version 2 du tag ODD, une clé unique est utilisée pour tous les boîtiers d'un même modèle. Ceci n'est plus vrai pour la version 3 du tag : chaque clé HMAC est unique par boîtier. J'ai pu reproduire les résultats décrits dans cette première partie et dans [1], en disposant de la clé utilisée par les boîtiers 20D, voir les valeurs calculées qui sont en bleu dans la figure 1.

Voyons donc dans la suite de cet article comment retrouver l'algorithme complet pour la version 3 du tag ODD, et surtout récupérer cette clé secrète et unique par boîtier, comme avec le 60D.

3. Exécutons, traçons du code sur notre appareil photo

Depuis 2009, grâce aux bidouilleurs du forum CHDK [8] et autour du firmware alternatif Magic Lantern [9], il est possible d’exécuter du code sur les reflex numériques Canon. On peut « sauvegarder » la mémoire vive et non volatile (Flash) sur la carte mémoire. Le processeur interne est le DIGIC, incluant un cœur ARM. Le système d'exploitation temps-réel de Canon s'appelle DryOS [10].

L'analyse statique du firmware avec FindCrypt [11] ou SignSrch [12] révèle entre autres des constantes liées aux implémentations SHA1, HMAC-SHA1, MD5 et SHA256. Les suppositions faites précédemment se renforcent...

Des fonctions de débogage sont même activables [13]. Ci-dessous, nous pouvons voir un extrait du journal de démarrage du 60D :

avec des traces pour les fonctions « MAC », pour Message Authentification Code :

Les trois valeurs en ligne 799 sont respectivement KeyId, BoardId et BodyId, nous y reviendrons. Cette dernière valeur est également appelée SerialNumber par ExifTool, et elle est imprimée sous le boîtier de l'appareil.

Enfin, lorsqu'une photo est prise avec l'option « Original Decision Data » activée via le menu :

dans le log apparaît un calcul de digest sur 32*8 = 256 bits. Il s'agit peut être d'un calcul SHA256, une amélioration de SHA1, dont les constantes ont été détectées dans le firmware et qui produit une valeur sur 256 bits.

En analysant les chaînes de caractères du firmware, on trouve également ceci (la première colonne est l'offset dans le firmware) :

4. Reconstitution des données du tag ODD, version 3

Comme précédemment, observons le contenu du tag ODD (version 3), produit par notre 60D :

Il ne faut pas chercher dans un premier temps à tout comprendre. Nous retrouvons cette fois-ci 8 régions (entre crochets) avec deux différences : une valeur qui semble aléatoire sur 32 bits (précédée d'un * pour la lecture) et la région est définie (offset, puis taille) sur les deux dernières colonnes. Autres différences, les lignes 2 et 3 possèdent chacune un HMAC-SHA1 sans région ni aléa, enfin, la région 2 semble découpée en neuf sous-parties et utilise un seul aléa.

ExifTool nous indique que l'image principale est à l'offset 5137400 (0x4e63f8) et d'une taille de 25147809 (0x17fb9a1). Cela est cohérent avec les deux dernières valeurs de la région 1 (la différence de 4 octets est à négliger).

Sans rentrer dans les détails, les huit régions sont appelées Area dans le firmware et calculées par la fonction MAC_SetArea(), se trouvant à partir de l'offset 0x91600 dans le firmware. Nous avons vu précédemment les messages générés dans le journal par cette fonction. Voici maintenant l'algorithme à appliquer.

5. L'algorithme de signature, pour les boîtiers récents

L'algorithme suivant est utilisé pour la version 3 du tag et pour un sous-type vhash>1. Pour le 60D, vhash=3, il s'agit de la sixième valeur, ligne 4. Curieusement, l’aléa associé à chaque région n'est pas utilisé ici.

En résumé, un SHA256 puis HMAC-SHA1 sur chaque région et le contenu du tag ODD (en ignorant les 56 premiers octets, sinon il y a un problème de poule et d’œuf). Enfin un HMAC-SHA1 sur l'accumulation des SHA256 calculés aux étapes précédentes.

Comme il faut pouvoir calculer le tag ODD de chaque image, à raison de 6,3 d'entre elles par seconde, le calcul du SHA256 est effectué par accélération matérielle, nommée « Kaiser », et intégré au Digic. Pour le boîtier 450D, l'aléa par région est bien utilisé (sous-type vhash=1), et l'algorithme est basé sur MD5 au lieu de SHA256, mais je n'en connais pas les détails. L'algorithme ci-dessus a été vérifié également sur un 7D (vhash=3) et un 50D (vhash=2).

6. Calcul de hmac_key

Cette clé est calculée comme suit, dans la fonction ____MAC_Start() :

Soit la concaténation de 3 valeurs :

- IKBoardID, une clé unique au boîtier de 32 octets, générée ou injectée en usine.

- Un identifiant public du boîtier (BodyId), ici 0x22970ba2. Nous l'avons aperçu dans le log système, et il est disponible dans le tag TIFF 0x000c du MakerNote (appelé SerialNumber par ExifTool).

- Et l'aléa hmac_rand, dans notre exemple, la valeur est 0x68f00e32, ligne 4 et générée par la fonction Rand() de la bibliothèque C, appelée 2 fois successivement sur 16 bits.

avec

Il y a deux manières de récupérer la valeur unique IKBoardID, en mémoire vive ou via une version stockée de manière persistante.

Au passage, le slide 23 de M. Sklyarov [1] intervertit BodyID et Hmac_rand, ce qui est incorrect.

7. Récupération du secret boîtier IKBoardId

7.1 En mémoire vive

La fonction macdispinf(), pour « MAC display info », utilise une structure qui contient des valeurs intéressantes :

À l'offset 8 se trouve BoardID et à l'offset 0x2c (44 en décimal) notre IKBoardID sur 32 octets. Canon a dû estimer que le risque de récupération en mémoire vive était faible, et celui en mémoire persistante plus probable, d’où une meilleure protection, que nous allons détailler.

7.2 Stockée dans la mémoire flash

Les « propriétés » de DryOS sont des structures nommées, permettant de stocker en mémoire et sur la mémoire flash (ici, à l'adresse 0xff800000) la plupart des données applicatives, comme la configuration de l'appareil. On retrouve BoardID via la propriété 0x1060002 (stockée en Little Endian), et FKBoardID dispersée dans les propriétés 0x01060004, 0x01060000, 0x0100000B et 0x10000008.

FKBoardID (F pour Forward) est une version obfusquée de IKBoardID (I pour Inverse). Il faut appliquer la fonction CRP_IObfunc() du firmware pour retrouver notre valeur en clair : en clair il faut inverser obfuscation.

Le script grep_odd.py parcourt la zone de la mémoire flash où sont stockées les propriétés, à la recherche des propriétés qui nous intéressent. Le format de stockage d'une propriété en mémoire est : property_length+8 (32 bits), property_id (32 bits), property_value. Tout ceci est toujours stocké au format Intel.

En sortie, la première colonne est l'identifiant de la propriété, le 2e sa longueur, l'offset dans le dump, et enfin, sa valeur, octet par octet. On peut noter que l'on retrouve la valeur BoardID dans les 4 derniers octets de IKBoardID, ce qui confirme que cette dernière est la version en clair de FKBoardID.

8. Démo

Avec IKBoardID = 'ce5969180f38bbab2a28f08b44b536dc407cd9ee54843226505ec35a820fd801', nous pouvons calculer la clé hmac_key, et finalement vérifier l'authenticité du fichier image, via le script ci-dessous. La totalité de la sortie du script est reproduite ci-dessous afin d'expliciter la structure du tag, de récapituler les calculs intermédiaires pour reconstituer les données d'authentification, et enfin, d'afficher des valeurs test, permettant au lecteur qui le souhaite de reproduire l’opération. Ce script sera mis à disposition [15].

La valeur file_hmac calculée, à la dernière ligne, est bien identique au HMAC inclus par le firmware dans le tag ODD, autrement dit : le fichier est considéré comme authentique. On peut remarquer également que la valeur est disponible en clair dans l'en-tête des données ODD.

La figure 2 illustre l'organisation des régions et leur contenu. Le lecteur voulant comprendre l'intégralité du format du tag ODD en version 3 trouvera son bonheur dans les planches 17 à 21 de [1].

Pour information, des brevets Canon [14] décrivent comment créer des données de vérification d’authenticité d'une image et comment générer une clé secrète, la stocker sur un média « tamper resistant » : il s'agit sans doute de la carte Secure Mobile nécessaire au chiffrement des images.

9. Discussion

Nous sommes donc capables, pour la version 3 du tag, lorsque l'on dispose de IKBoardID, de vérifier l'authenticité du fichier image par rapport au contenu du tag ODDv3. Mais est-il facile de falsifier cette vérification : produire un tag valide pour une image modifiée ?

Usurper le boîtier d'origine d'une image reste, pour la même raison, difficile : comme l'algorithme pour générer le secret IKBoardID en fonction de valeurs publiques comme BoardID et KeyID est inconnu, il faut être capable d'extraire cette valeur secrèteet unique. Cela nécessite un accès physique au boîtier visé.

Par contre, forger un tag valide est plus simple, on peut en effet réutiliser le secret IKBoardIDextrait d'un boîtier,ainsi que ses valeurs liées BoardID et KeyID. C'est d'ailleurs ce que l'on peut observer pour quatre images modifiées par ElcomSoft : Sakura.jpg, Liberty.jpg, Stalin.jpg et Fuji.jpg, provenant selon les métadonnées (forgées) de quatre boîtiers différents. Les mêmes valeurs BoardID=0x82e933a7 et KeyID=1 sont utilisées à chaque fois, donc un même secret IKBoardIDa certainement été réutilisé pour ces quatre images : c'est une attaque de type « replay ». On peut imaginer alors black-lister ces valeurs, mais selon quels critères ? Et pour la version 2 du tag, il faut révoquer la clé utilisée pour tous les boîtiers d'un même modèle, la fonctionnalité est ici condamnée.   

Conclusion

Dans cet article, nous avons vu comment sont produites des données permettant de vérifier l'authenticité des données d'un fichier image (le tag ODD donc) via une combinaison de primitives cryptographiques standards : SHA256 et HMAC-SHA1, ici pour le modèle 60D. Les hypothèses faites par le constructeur étaient que la clé IKBoardID resterait secrète, puisque présente uniquement en mémoire, et que l’algorithme de signature est inconnu.

Ceci n'est plus vrai. Canon n'a sans doute pas utilisé le « attack resistant device » pour protéger la clé IKBoardID pour des raisons de coût.

Nous avons également constaté qu'avant de se précipiter sur un désassembleur, on peut faire beaucoup d'hypothèses justes par observation de la structure des données du tag ODD et via les chaînes de caractères contenues dans le firmware.

Est-il finalement envisageable de résoudre la dernière énigme dont nous parlions dans le chapitre précédent : comment le kit de vérification de Canon [6] calcule-t-il ou vérifie-t-il la valeur IKBoardID de l'appareil par rapport à ses valeurs « publiques » KeyID et BoardID ? Lors de la vérification des images, il est nécessaire de connecter la carte Secure Mobile au PC [16] où sont stockés les fichiers images. L'appareil photo n'étant pas connecté au système, le kit OSK-E3 utilise uniquement des données provenant des images. Dans le meilleur des cas pour Canon, la décision de la vérification est prise par la carte, masquant les secrets utilisés. Le brevet US 7650511 [14] contient peut-être des éléments de réponse, semble-t-il à base de chiffrement. Peut-être un lien avec les fonctions CRP_Crypto3DesWrap du firmware ?

Remerciements

Merci au projet Magic Lantern d'offrir une plate-forme d’expérimentation inattendue. Je tiens à remercier également Dmitry Sklyarov pour m'avoir désigné la dernière pièce du puzzle (c'est-à-dire où se trouve hmac_rand) et pour la clé du 20D. Merci enfin au rédacteur en chef et aux deux relecteurs pour leurs conseils.

Bibliographie

[1] Forging Canon Original Decision Data , Dmitry Sklyarov, Confidence 2.0 conference, Prague, 2010, http://201002.confidence.org.pl/prelegenci/dmitry-sklyarov

[2] Service Notice: Information Regarding Original Data Security and Original Data Verification Kits, http://www.usa.canon.com/cusa/support/consumer?pageKeyCode=prdAdvDetail&docId=0901e0248027abcd

[3] Dcraw, Dave Coffin, http://www.cybercom.net/~dcoffin/dcraw/

[4] ExifTool, Phil Harvey, http://owl.phy.queensu.ca/~phil/exiftool/TagNames/

[5] Inside the Canon RAW format version 2, http://lclevy.free.fr/cr2/

[6] Image verification : http://cpn.canon-europe.com/content/education/infobank/image_verification/canon_data_verification_system.do

[7] HMAC-SHA1, http://tools.ietf.org/html/rfc2202

[8] Canon Hack Dev Kit, http://chdk.setepontos.com/index.php?board=33.0

[9] Magic Lantern firmware, http://magiclantern.wikia.com/wiki/Unified

[10] DryOS, http://www.canon.com/technology/canon_tech/explanation/cp_tech.html#dryos

[11] FindCrypt. Ilfak Guilfanov, http://www.hexblog.com/?p=28

[12] Signsrch . Luigi Auriemma, http://aluigi.altervista.org/mytoolz.htm

[13] http://magiclantern.wikia.com/wiki/Debugging_Magic_Lantern

[14] US patent 7650511. voir aussi : US patent 7930544, US patent 7949124, US patent 8005213.

[15] http://lclevy.free.fr/cr2/odd

[16] OSK-E3, verification steps, http://www.canon.co.jp/imaging/osk/osk-e3/verifies/method/index.html