Livre blanc — Méthodologie forensique

Référence technique pour les procureurs, avocats de la défense, témoins experts et responsables de la sécurité des informations des agences qui évaluent les rapports produits par DVR Time Traveler.

1. Portée et utilisation prévue

DVR Time Traveler est un outil d'aide à l'enquête et un instrument de certification de la base de temps. Il effectue un calcul arithmétique déterministe sur des valeurs de temps fournies par un agent et produit un rapport PDF structuré documentant le calcul, les données d'entrée, l'appareil sur lequel le calcul a été effectué et le moment auquel il l'a été.

Utilisé ainsi, le rapport certifie la base de temps du DVR examiné — en établissant, au dossier, si l'horloge interne de cet enregistreur était en retard, exacte ou en avance par rapport à l'heure réelle au moment de l'examen. Cela s'applique à tout DVR doté d'une horloge interne, y compris les enregistreurs dont l'horloge est déjà correcte : le rapport documente que l'horloge a été vérifiée et jugée exacte, plutôt que de laisser cette hypothèse non exprimée.

L'application n'ingère pas de vidéo, ne décode pas les horodatages vidéo, n'établit pas de chaîne de possession pour les médias tiers (tels que l'enregistrement DVR sous-jacent) et n'affirme pas l'authenticité de l'enregistrement DVR sous-jacent. Ces déterminations demeurent la responsabilité de l'enquêteur, de l'agence saisissante et du juge des faits. L'application produit toutefois deux catégories d'artefacts générés par elle-même — les rapports PDF et les photos de dossier — qui portent chacun leur propre métadonnées de détection d'altération, d'attestation temporelle et de liaison au dispositif décrites dans le présent document (voir §4.5 pour les propriétés du document PDF et §6.5 pour l'attestation EXIF des photos).

Ce livre blanc décrit les contrôles qui permettent à un tiers de vérifier de façon indépendante, des semaines ou des années après les faits, que :

1. Le PDF en question a bien été produit par DVR Time Traveler.
2. Il n'a pas été modifié depuis l'instant de sa génération.
3. Le hachage de son contenu existait à un instant précis ou avant cet instant, attesté par une Autorité d'horodatage indépendante.
4. L'horloge de l'application utilisée pour effectuer le calcul était, dans une marge déclarée, exacte au moment de la génération.

2. Énoncé du problème

Les enregistreurs vidéo numériques de surveillance (DVR) fonctionnent couramment avec des horloges temps réel en roue libre qui ne sont pas synchronisées avec des sources de temps faisant autorité. Une dérive de quelques secondes par jour est normale ; une dérive de plusieurs heures ou jours n'est pas inhabituelle pour des DVR réinstallés sans reconfiguration, ayant subi une coupure d'alimentation prolongée, ou dont le fuseau horaire a été mal configuré à l'installation.

Les enquêteurs doivent donc effectuer une conversion entre deux horloges : l'horloge inexacte du DVR et une horloge fiable du « monde réel ». Les erreurs dans cette conversion se répercutent dans les rapports d'incident, les déclarations de cause probable, les entretiens avec les témoins et, en définitive, dans les pièces à conviction au procès.

DVR Time Traveler élimine l'arithmétique manuelle en calculant la conversion, en formalisant les données d'entrée et en produisant un artefact auto-descriptif (le rapport PDF) qui documente à la fois le résultat et les conditions dans lesquelles il a été produit. Lorsque l'horloge du DVR est jugée exacte, ce même artefact sert de certification de ce fait — un enregistrement documenté et vérifiable de façon indépendante attestant que la base de temps de l'enregistreur a été examinée et confirmée, et non simplement présumée.

3. Les mathématiques

L'application prend en charge trois calculs fondamentaux, tous effectués en temps universel coordonné (UTC) en interne :

3.1 Différence de temps

Étant donné un temps réel T_reel et l'heure affichée par le DVR T_dvr au même instant physique :

delta = T_reel − T_dvr

Où delta peut être positif (le DVR est en retard) ou négatif (le DVR est en avance). La valeur absolue est décomposée en jours, heures, minutes et secondes pour l'affichage.

3.2 Heure DVR cible pour un événement

Étant donné le delta calculé et l'heure réelle de l'événement d'intérêt T_evenement :

T_dvr_cible = T_evenement − delta

On obtient ainsi l'heure que l'enquêteur doit chercher sur le DVR pour visualiser l'événement.

3.3 Horizon de rétention

Étant donné une date réelle actuelle T_maintenant et la période de rétention configurée R (en jours) :

T_fin_retention = T_maintenant + R jours

La date la plus ancienne encore récupérable est T_maintenant − R jours.

3.4 Cas limites traités

• Transitions à l'heure d'été. Les calculs sont effectués en UTC, de sorte que les passages à l'heure d'été et d'hiver sont naturellement pris en compte. L'affichage utilise les paramètres locaux de l'appareil pour présenter l'heure locale correcte.
• Années bissextiles. Les limites jour-du-mois sont validées par mois et par année (ex. : le 29 février n'est autorisé que les années bissextiles).
• Deltas enjambant minuit. Les différences couvrant minuit sont gérées correctement en opérant sur des horodatages absolus, non sur des chaînes heure-du-jour.
• Deltas couvrant un changement d'année. Idem.
• Différences de fuseau horaire. L'appareil enregistre son propre décalage de fuseau horaire et l'inclut dans le calcul et dans le rapport.

4. Somme de contrôle anti-altération

Chaque rapport PDF contient une Somme de contrôle anti-altération, une valeur hexadécimale de 64 caractères dérivée d'un code d'authentification de message à clé HMAC-SHA256 (RFC 2104) calculé sur la représentation canonique de chaque champ numérique affiché dans le rapport, plus le numéro de matricule de l'agent, l'identifiant de l'appareil, la date du rapport, la version de l'application et les champs administratifs du dossier (numéro de dossier, adresse du DVR, identification du DVR, nom de l'agent, département et unité).

4.1 Données d'entrée

Les champs suivants sont sérialisés, par ordre alphabétique de clé, sous forme de chaîne JSON déterministe. Cette chaîne est le message HMAC; un secret d'application fixe est la clé HMAC :

• Identifiant de l'appareil (UUID dérivé des identifiants matériels)
• Version de l'application
• Numéro de matricule de l'agent (partie numérique seulement)
• Date de génération du rapport
• Horodatage de corrélation (l'instant auquel le delta a été capturé)
• Date et heure du DVR à la corrélation
• Date et heure de l'événement
• Date et heure finale (cible) sur le DVR
• Différence de temps calculée (décomposée)
• Date de fin de rétention
• Période de rétention (jours)
• Numéro de dossier (texte normalisé)
• Adresse / emplacement du DVR (texte normalisé)
• Identification du DVR (texte normalisé)
• Nom de l'agent (texte normalisé)
• Département / agence (texte normalisé)
• Unité / division (texte normalisé)

Les champs numériques et de date/heure sont réduits à leurs chiffres (normalisés selon l'ordre ISO 8601) avant le hachage, de sorte que le code est indépendant de la langue d'affichage et du format régional de l'appareil. Les champs administratifs du dossier sont normalisés comme du texte — les espaces superflus sont réduits et la valeur est mise en majuscules — afin que des différences d'espacement ou de casse n'affectent pas le code, tandis que toute modification substantielle le change.

4.2 Algorithme

code = HMAC-SHA256( clé = secret_d_application, message = JSON(champs, clés_triées) )

HMAC-SHA256 est le code d'authentification de message à clé standard défini par la RFC 2104 et la norme FIPS 198-1. Les 12 premiers caractères hexadécimaux du code forment l'identifiant de document lisible par l'humain, préfixé DVRTT-. La valeur complète de 64 caractères est affichée dans le PDF pour une vérification byte à byte.

4.3 Propriétés et assurance visée

• Détection des altérations. La modification de tout champ inclus changera, avec une probabilité écrasante, le code. Un vérificateur disposant du même secret d'application peut recalculer le code à partir des champs affichés et détecter toute altération.
• Déterminisme. Des données d'entrée identiques produisent toujours des codes identiques. Cela fait du code une référence stable entre réimpressions.
• Non-propriété honnête. Le code est un code d'authentification de message à clé (HMAC), non une signature numérique à clé publique. Le secret d'application est intégré dans le binaire de l'application. Une partie suffisamment motivée disposant d'une copie de l'application peut en principe calculer des codes valides pour des données arbitraires. Le code fournit donc une détection des altérations, non la non-répudiation.
• Atténuation. La non-répudiation est assurée par l'horodatage de confiance RFC 3161 indépendant décrit à la §5, qui ne repose sur aucun secret intégré à l'application.

4.4 Service de vérification des rapports

SDTech offre un Service professionnel de vérification des rapports destiné aux agences et aux professionnels du droit qui requièrent une confirmation formelle qu'un rapport DVR Time Traveler n'a pas été altéré. Sur demande, SDTech recalcule la somme de contrôle anti-altération à partir des champs visibles sur le rapport et confirme si le code correspond — fournissant une attestation signée pouvant être soumise en procédure judiciaire. Comme SDTech développe l'application, il s'agit d'une vérification d'expert par la première partie et non d'une vérification indépendante ; pour une vérification entièrement indépendante, tout tiers peut recalculer la méthode HMAC-SHA256 ouverte décrite ci-dessus, et l'horodatage de confiance RFC 3161 de la §5 est émis par une autorité indépendante.

Pour demander une vérification ou en savoir plus sur ce service, utilisez notre page sécurisée de demande de certificat.

4.5 Propriétés du document PDF

En plus de la somme de contrôle anti-altération décrite ci-dessus, chaque rapport PDF porte un dictionnaire Info PDF structuré, rempli au moment de la génération. Ces champs sont consultables dans le panneau de propriétés de tout lecteur PDF et fournissent une couche d'attestation indépendante et facile à inspecter concernant l'origine du document :

Les champs CreationDate et ModDate sont renseignés à partir de timeService.getNowSync() — la même horloge verrouillée pour la session et ancrée sur un compteur monotone qui pilote tous les autres horodatages du rapport — plutôt que par la valeur par défaut du système d'exploitation (qui relirait l'horloge de l'appareil au moment où le moteur de rendu PDF écrit le fichier, sans l'ancrage qui protège contre les modifications d'horloge en cours de session). Cet alignement fait en sorte que la CreationDate interne du PDF correspond à l'horodatage « Corrélation effectuée à » imprimé sur le rapport ainsi qu'au nom de fichier de toute photo prise dans la même session, fournissant un enregistrement temporel cohérent entre tous les artefacts générés par l'application.

Ces propriétés ne sont pas couvertes par la somme de contrôle anti-altération (qui ne hache que les données du rapport affichées). Un examinateur de la défense peut librement modifier le dictionnaire Info à l'aide d'outils standards ; s'il le fait, l'horodatage de confiance de la §5 continuera de lier le hachage original à l'instant original d'émission. Le dictionnaire Info est présenté ici comme métadonnée informative rendant la provenance immédiatement visible, non comme une garantie cryptographique.

5. Horodatages de confiance RFC 3161

À partir de la version 10.2.5, chaque rapport PDF inclut optionnellement un horodatage de confiance conforme à la RFC 3161 (Protocole d'horodatage de la clé publique Internet X.509).

5.1 Conception préservant la confidentialité

L'application calcule un hachage SHA-256 du contenu canonique décrit à la §4 et ne transmet que ce hachage au serveur de licences SDTech. Le serveur transmet une TimeStampReq RFC 3161 contenant le hachage à une Autorité d'horodatage (AHO) configurée. L'AHO ne voit pas le contenu original. Le contenu original ne quitte jamais l'appareil.

5.2 Chaîne de confiance

1. L'AHO émet un TimeStampToken, structure CMS SignedData contenant un champ TSTInfo qui atteste le hachage, la politique sous laquelle l'horodatage a été émis et un temps de confiance. Le jeton est signé avec la clé privée de l'AHO.
2. Le certificat de signature de l'AHO est enchaîné à une Autorité de certification racine approuvée publiquement.
3. Le serveur de licences stocke le jeton, le hachage original, le nom de l'AHO, l'heure d'émission et le contexte de la demande dans un enregistrement Cloudflare D1 à l'épreuve des altérations. Chaque enregistrement reçoit un identifiant de jeton stable et sécurisé pour les URL.
4. Le PDF intègre l'identifiant du jeton, l'heure d'émission, le nom de l'AHO, le hachage du contenu et une URL de vérification publique.
5. Quiconque peut ultérieurement accéder à l'URL de vérification pour récupérer les métadonnées et (avec ?include_raw=1) le TimeStampToken encodé en DER original, pour une vérification cryptographique avec des outils standard (OpenSSL ts -verify, bibliothèques conformes RFC 3161, etc.).

5.3 Autorités d'horodatage configurées

5.4 Ce que prouve un horodatage de confiance

• Que le hachage du document existait à l'heure d'émission attestée ou avant.
• Que l'heure attestée a été certifiée par un tiers opérant à l'extérieur du contrôle de SDTech.
• Que le contenu du document n'a pas été modifié depuis l'émission de l'horodatage (toute modification changerait le hachage).

5.5 Ce que ne prouve pas un horodatage de confiance

• Il n'authentifie pas l'identité de la personne qui a produit le rapport.
• Il n'affirme pas que les données d'entrée sous-jacentes (l'heure du DVR, l'heure réelle de l'événement) étaient véridiques ou exactes. Ces questions demeurent à la discrétion du juge des faits.
• Il n'affirme pas que l'horloge de l'application affichée dans le rapport était correcte. Cette assurance est fournie indépendamment par la §6.

6. Attestation de la source de temps

L'application utilise une horloge d'appareil vérifiée pour tous les horodatages et calculs des rapports. Sur la page d'avertissement au début de la session, l'horloge de l'appareil est comparée à un consensus temps Internet multi-sources (voir §6.1–§6.2). Lorsque la dérive mesurée est dans une marge de ±2 secondes du consensus — le plancher de bruit de la mesure par en-tête HTTP Date, et plus fin que la précision que l'application peut revendiquer de manière significative — l'horloge de l'appareil est acceptée telle quelle : aucun décalage n'est appliqué, car à cette résolution la propre source de temps du système d'exploitation (NITZ / GNSS / NTP) est plus précise qu'une correction HTTP calculée par l'application. L'horloge acceptée est ensuite verrouillée pour la session et accédée exclusivement via timeService.getNowSync(), qui l'ancre à performance.now() (un compteur monotone) de sorte que les modifications d'horloge en cours de session soient détectées et traitées — voir §6.6 pour le comportement précis en cas de manipulations arrière et avant, et pour la façon dont l'application distingue un sommeil légitime de l'appareil d'un saut avant malveillant. Cette horloge vérifiée et verrouillée pilote la CreationDate interne du PDF (§4.5), l'horodatage « Corrélation effectuée à » imprimé au recto, et l'heure de capture de toute photo prise dans l'application (§6.5). Si la dérive mesurée est ≥ 2 secondes, l'utilisateur ne peut procéder tant qu'il n'a pas re-vérifié, corrigé l'horloge de l'appareil ou explicitement reconnu la situation et procédé sur la propre attestation de l'agent. Lors de la génération du rapport, l'application effectue une seconde attestation de la source de temps indépendante — elle interroge à nouveau les mêmes sources de temps Internet non corrélées, calcule un consensus et enregistre la dérive entre l'horloge d'application verrouillée et ce consensus — fournissant une preuve contemporaine, vérifiable par un tiers, de l'exactitude de l'horloge de l'application au moment de la génération du rapport.

Si l'appareil est hors ligne au moment de la génération, aucune source de temps externe ne peut être interrogée et l'attestation est marquée INDISPONIBLE — l'application se rabat sur l'horloge de l'appareil pour les calculs et affiche de façon visible une icône cloud-off sur le rapport. Dans ce scénario, l'agent a déjà confirmé sur la page d'avertissement — en cochant la case libellée « J'ai vérifié que l'heure automatique est activée et j'accepte les conditions ci-dessus » — que le réglage « Heure automatique » de l'appareil est actif et que les trois conditions d'intégrité temporelle énoncées sur la même page ont été lues et acceptées. La bonne pratique consiste à recouper en outre l'horloge de l'appareil avec une référence temporelle externe indépendante (montre radio-pilotée, second appareil, horodatage de la répartition ou signal horaire diffusé) et à photographier cette référence avec la caméra intégrée afin que le JPEG résultant porte, dans ses métadonnées EXIF, le même temps vérifié et verrouillé pour la session (étiqueté « NTP-verified » ou « device clock » selon §6.5) (§6.5). La page hors ligne du rapport documente explicitement cet état, fournissant une chaîne de responsabilité documentée pour l'exactitude de l'horloge même sans attestation automatisée. Le résultat de l'attestation est inclus textuellement dans le PDF.

Pourquoi l'heure automatique est physiquement nécessaire. Sur iOS comme sur Android, l'interface de réglage manuel de l'heure ne propose que les heures et les minutes — il n'existe aucun sélecteur de secondes. Lorsqu'un utilisateur règle l'horloge manuellement, la composante des secondes est soit réinitialisée à :00, soit laissée à sa valeur arbitraire actuelle, selon la version du système. Un réglage manuel entraîne donc toujours un décalage incontrôlable pouvant atteindre 59 secondes par rapport à l'heure réelle. Seule la synchronisation automatique du système d'exploitation (via NITZ, GNSS ou NTP) peut régler les secondes avec précision. C'est pourquoi la première condition de la page d'avertissement de l'application est la confirmation que l'heure automatique est activée : il ne s'agit pas d'une simple recommandation mais d'un prérequis physique pour une précision à la seconde.

6.1 Sources interrogées

La liste actuelle des sources (sujette à évolution) est :

• Cloudflare (en-tête HTTP Date sur cdn-cgi/trace)
• Google (en-tête HTTP Date sur generate_204)
• Apple (en-tête HTTP Date sur le point de terminaison de test)
• Microsoft (en-tête HTTP Date sur Bing)
• Amazon (en-tête HTTP Date sur AWS CloudFront)

Ces sources sont exploitées par des organisations indépendantes dans plusieurs juridictions. Une seule source compromise ne peut pas induire le consensus en erreur.

6.2 Méthode

Pour chaque source, l'application enregistre :

• L'heure locale immédiatement avant la requête (t_debut) ;
• L'heure locale immédiatement après la réponse (t_fin) ;
• L'heure rapportée par la source (t_rapportee).

Elle applique ensuite la correction SNTP standard à demi-RTT :

t_corrigee  = t_rapportee − (t_fin − t_debut) / 2
point_med   = (t_debut + t_fin) / 2
derive      = t_corrigee − point_med

Le décalage de consensus est la médiane de tous les échantillons réussis ; l'écart est l'écart-type des échantillons.

6.3 Ce qui est rapporté dans le PDF

Le bloc d'attestation imprimé sur le rapport contient :

• Une ligne de résumé en langage clair indiquant l'écart entre l'horloge de l'application et le consensus — exprimé en millisecondes lorsque la dérive est inférieure à une seconde, ou en secondes sinon (p. ex. « Horloge de l'app est dans les 250 ms du consensus de 4 sources »).
• Un tableau par source énumérant chaque source interrogée, avec un marqueur de succès/échec (✓ / ✗), le nom de la source, l'heure qu'elle a rapportée (UTC, corrigée du temps d'aller-retour) — ou un motif d'échec tel que « Délai dépassé » ou « Inaccessible » — ainsi que la dérive individuelle de cette source en millisecondes.
• Une ligne de métadonnées indiquant le statut global, l'heure du consensus (UTC), la dispersion des échantillons (1σ) en millisecondes, et la fenêtre d'exécution (horodatages début → fin).
• Le statut global : OK (≥ 2 sources), DÉGRADÉ (1 source), INDISPONIBLE (0 source).

6.4 Résolution et aptitude à l'usage

L'en-tête HTTP Date a une résolution à la seconde entière selon la RFC 7231. Un seul échantillon comporte donc de l'ordre de ±1 à 2 secondes d'erreur de mesure (quantification à la seconde plus asymétrie de l'aller-retour réseau) ; la prise de la médiane sur plusieurs opérateurs indépendants élimine la gigue propre à chaque source, tandis que le plancher absolu reste d'environ ±1 seconde. C'est suffisant pour l'utilisation prévue : confirmer que l'horloge de l'appareil utilisée pour calculer les horodatages du rapport était, au moment de la génération, exacte à la seconde, et non à la microseconde. L'utilisation de NTP via UDP pour une précision supérieure est réservée à de futurs travaux sur les modules natifs et n'est pas requise pour cet usage.

6.5 Capture de photos et attestation EXIF

Les photos de dossier prises avec la caméra intégrée à l'application sont traitées comme des artefacts de preuve de premier plan. À l'instant où le déclencheur est activé — avant que le système d'exploitation ne termine l'encodage du JPEG — l'application lit l'heure courante depuis timeService.getNowSync() (la même horloge verrouillée pour la session et ancrée sur un compteur monotone utilisée partout ailleurs dans le rapport). Cette valeur d'heure de capture pilote à la fois le nom de fichier de la photo et les balises EXIF suivantes, écrites in-place après la capture :

Le statut de la source de temps inscrit dans UserComment est l'une des trois valeurs littérales suivantes :

• NTP-verified — l'horloge de l'appareil a été vérifiée comme étant dans une marge de ±2 secondes du consensus temps réseau multi-sources décrit à §6.1–§6.4, puis verrouillée pour la session, avant que la photo ne soit prise.
• device clock — l'application fonctionnait hors ligne (ou dans un état où l'agent a explicitement reconnu une dérive résiduelle), et l'agent a confirmé l'exactitude de l'horloge de l'appareil contre une référence externe indépendante avant de procéder, comme décrit à §6.
• NTP-verified (checkpoint pending) ou device clock (checkpoint pending) — la photo a été prise pendant la brève fenêtre (~2 secondes) entre le retour de l'application au premier plan et l'achèvement du point de contrôle de vérification temporelle (§6.6). Le suffixe entre parenthèses est transparent sur le fait que le point de contrôle n'avait pas encore confirmé l'ancrage au moment du déclenchement.

L'identifiant d'appareil inscrit dans UserComment est le même identifiant dérivé du matériel qui est inclus parmi les 17 champs couverts par la somme de contrôle anti-altération sur tout rapport PDF généré sur le même appareil (§4.1). C'est le mécanisme qui lie une photo au(x) rapport(s) PDF produit(s) sur le même appareil : un examinateur qui compare la valeur Device dans le UserComment d'une photo à la ligne Identifiant d'appareil imprimée sur un rapport PDF peut confirmer que les deux artefacts proviennent de la même installation de DVR Time Traveler.

Les champs EXIF sont lisibles par tout outil standard — exiftool, la plupart des éditeurs d'images, et la boîte de dialogue des propriétés de fichiers de chaque système d'exploitation — sans nécessiter de coopération de SDTech. L'horodatage du nom de fichier et le DateTimeOriginal EXIF sont renseignés à partir de la même valeur, de sorte qu'un décalage entre les deux est un indicateur positif de manipulation a posteriori.

Horodatage incrusté. En plus des métadonnées EXIF lisibles par machine, un horodatage visible est rendu directement dans les pixels de l'image à la résolution native du capteur (coin inférieur droit, police monospace sur un fond semi-transparent). Le texte incrusté affiche DVR Time Traveler (jaune) sur une ligne et l'heure de capture au format ISO AAAA-MM-JJ  HH:MM:SS (blanc) sur la ligne suivante. Cela garantit que l'heure de capture vérifiée est visible lorsque la photo est imprimée, projetée ou consultée comme fichier autonome sans logiciel compatible EXIF. Le format ISO 8601 est utilisé quel que soit le paramètre régional de l'agent afin que la date soit non ambiguë dans les procédures inter-juridictionnelles.

Précision infra-seconde. L'horodatage de capture est lu depuis l'horloge vérifiée à l'instant où le bouton de déclenchement est pressé, avant que le capteur de la caméra ne commence l'exposition. Les trois représentations — nom de fichier, EXIF et texte incrusté — tronquent aux secondes entières et sont dérivées de la même valeur. Sur la plupart des appareils, l'horodatage incrusté correspond exactement au contenu de la scène. Sur du matériel plus ancien ou plus lent, l'exposition du capteur et l'encodage JPEG peuvent prendre légèrement plus de temps, et dans de rares cas une horloge visible dans la scène pourrait différer d'une seconde de l'horodatage incrusté (p. ex., l'horodatage affiche 14:35:01 tandis que la scène montre 14:35:02). Il s'agit d'un cas limite dépendant du matériel, pas d'un décalage systématique ; l'horodatage enregistre toujours la décision de capturer.

Les métadonnées EXIF ne sont pas couvertes par la somme de contrôle anti-altération (qui ne sécurise que les champs du rapport PDF). Si le fichier JPEG est modifié après la capture, les défenses standard sont (i) le hachage SHA-256 du fichier original, calculé lors du transfert vers le système de gestion des dossiers, et (ii) le nom de fichier vérifié et verrouillé qui est fixé à la capture et ne peut être falsifié sans modifier le fichier écrit par le système d'exploitation. Si la photo est ensuite jointe à un rapport PDF, l'horodatage de confiance du rapport (§5) lie le contenu du rapport, mais pas les fichiers photo joints — c'est le DateTimeOriginal EXIF propre de la photo qui porte le registre temporel contemporain de l'image elle-même.

6.6 Détection des modifications d'horloge en cours de session

Une fois la session verrouillée (§6), chaque transition AppState → 'active' (l'application revenant au premier plan après avoir été mise en arrière-plan ou après que l'appareil se réveille du sommeil) déclenche un point de contrôle au premier plan :

1. Un drapeau checkpoint-pending est défini immédiatement. Toute photo ou PDF sauvegardé pendant cette brève fenêtre (~2 secondes) porte le suffixe (checkpoint pending) dans ses métadonnées (§6.5).
2. Le verrou de session est temporairement libéré et une nouvelle synchronisation NTP s'exécute contre le même consensus multi-sources utilisé au démarrage de la session (§6.1–§6.4). La synchronisation écrit un nouvel offset et ré-ancre l'horloge monotone.
3. La session est re-verrouillée et le drapeau checkpoint-pending est effacé.
4. La dérive — la différence entre l'avance de l'horloge murale de l'appareil pendant la fenêtre d'arrière-plan et l'avance de la réalité réseau pendant la même fenêtre — est calculée.
   • Si la dérive est < 2 secondes (dans le bruit de mesure des en-têtes Date HTTP), le rafraîchissement de l'ancrage est silencieux. C'est le cas courant : l'appareil dormait, sa synchronisation au niveau OS maintenait l'horloge exacte, et aucune invite n'est nécessaire.
   • Si la dérive est ≥ 2 secondes, un modal Vérification au retour en avant-plan est présenté avec le nombre exact de secondes de divergence. La seule option est Re-vérification complète — l'agent est renvoyé à la page d'avertissement pour relire les trois conditions et re-attester formellement via la case à cocher. Il n'y a pas de raccourci ; chaque modification d'horloge détectée exige le même engagement que le démarrage d'une nouvelle session.
   • Si l'appareil est hors ligne et que la synchronisation NTP échoue, le point de contrôle est un no-op : l'ancrage n'est pas modifié, le verrou de session reste en place, et le prochain point de contrôle réussi (quand la connectivité revient) révélera toute divergence.

Pourquoi cela suffit. Sur iOS et Android, les paramètres de date/heure se trouvent dans Réglages / Paramètres système, qui est une application séparée. L'ouvrir met DVR Time Traveler en arrière-plan. Revenir à DVR Time Traveler produit un événement AppState → 'active'. Par conséquent, chaque opportunité de manipulation est encadrée par exactement un point de contrôle. Aucun réglage de seuil, heuristique de direction ou désambiguation sommeil/manipulation n'est nécessaire.

Protection en ligne pendant que l'application est au premier plan. Pendant que l'application est au premier plan, getNowSync() lit toujours performance.now() en parallèle avec Date.now() à chaque appel. Si l'horloge de l'appareil dévie de plus de 5 secondes de l'estimation monotone, le timeOffset interne est silencieusement corrigé pour que les horodatages continuent d'avancer de façon monotone à partir de l'ancrage verrouillé de la session.

Combiné à l'horodatage de confiance RFC 3161 (§5), qui est émis par une AHO tierce qu'aucune manipulation d'horloge d'appareil ne peut affecter, la chaîne forensique est complète :

• L'horodatage de génération du rapport provient de l'horloge vérifiée et verrouillée pour la session (§6) ;
• Toute manipulation en cours de session est soit corrigée en ligne (changement d'horloge au premier plan) soit signalée à l'agent au point de contrôle (changement d'horloge en arrière-plan) ;
• L'horodatage de confiance prouve indépendamment quand le contenu du rapport existait, indépendamment de tout état d'horloge côté appareil.

7. Procédure de vérification

Toute partie peut vérifier indépendamment un PDF de DVR Time Traveler en utilisant uniquement des outils standard disponibles publiquement.

7.1 Vérifier la somme de contrôle anti-altération

1. Lire tous les champs numériques du PDF tels qu'affichés.
2. Recalculer le code HMAC-SHA256 en utilisant la construction d'entrée canonique décrite à la §4 et la clé HMAC documentée dans le code source de l'application. (SDTech offre aussi un service payant de vérification de première partie — voir §4.4 — mais aucune coopération de SDTech n'est requise pour la vérification par un tiers.)
3. Comparer à la valeur imprimée sur le PDF. Toute divergence indique une altération.

7.2 Vérifier les métadonnées de l'horodatage de confiance

curl https://verify.sdtech.app/api/v1/timestamp/verify/<TOKEN_ID>

La réponse inclut le hachage original, l'AHO, l'heure d'émission et le contexte de la demande. Comparer le hachage à celui imprimé sur le PDF.

7.3 Vérifier cryptographiquement le jeton d'horodatage de confiance

# 1. Récupérer le jeton RFC 3161 brut (base64)
curl 'https://verify.sdtech.app/api/v1/timestamp/verify/<TOKEN_ID>?include_raw=1' \
  | jq -r .tokenB64 | base64 -d > jeton.tsr

# 2. Vérifier par rapport au hachage du document (certificat racine de l'AHO FreeTSA / DigiCert selon le cas)
openssl ts -verify -in jeton.tsr -digest <HASH_HEX> \
  -CAfile tsa-ca.pem

Un résultat OK confirme que le hachage attesté existait à l'heure d'émission ou avant, et que le jeton a bien été émis par l'AHO nommée.

7.4 Vérifier l'attestation de la source de temps

L'attestation est reproductible en principe mais pas en pratique (les sources interrogées ne conservent pas les réponses historiques). Le bloc d'attestation dans le PDF est donc évalué comme preuve contemporaine de l'exactitude de l'horloge au moment de la génération du rapport, et non comme un test ré-exécutable.

7.5 Portail de vérification et horodatage des rapports hors ligne

SDTech fournit un portail de vérification public à l'adresse verify.sdtech.app. Toute partie peut y coller un identifiant de jeton (ts_...) ou une URL de vérification complète pour consulter un enregistrement d'horodatage.

Pour les rapports générés hors ligne (aucun horodatage de confiance n'a pu être obtenu au moment de la génération), un outil d'horodatage pour rapports hors ligne est disponible à l'adresse verify.sdtech.app/api/v1/timestamp/offline. L'outil accepte l'empreinte SHA-256 du document (imprimée sur la page d'attestation hors ligne) et la soumet à la même Autorité d'horodatage tierce indépendante utilisée pour les rapports en ligne. Le jeton RFC 3161 résultant lie cryptographiquement l'empreinte du document au moment de la soumission, produisant un certificat de vérification imprimable identique à celui fourni automatiquement lorsque l'appareil est en ligne. Un lien pré-rempli vers cet outil est intégré directement dans la page d'attestation forensique de chaque rapport hors ligne.

7.6 Vérifier les propriétés du document PDF

Le dictionnaire Info (§4.5) est consultable dans tout lecteur PDF (Adobe Acrobat, Aperçu macOS, lecteurs PDF Windows) via Fichier → Propriétés, ou depuis la ligne de commande :

exiftool -PDF:all rapport.pdf
# ou
pdfinfo rapport.pdf

Valeurs attendues : Author = DVR Time Traveler, Creator/Producer = DVR Time Traveler v<version>, Subject correspondant au type de rapport (Law Enforcement ou Private Investigation). La CreationDate doit correspondre à l'horodatage « Corrélation effectuée à » imprimé sur le recto du rapport. Un décalage n'est pas une preuve d'altération (le dictionnaire Info n'est pas signé), mais mérite d'être étudié conjointement avec la somme de contrôle anti-altération.

7.7 Vérifier les métadonnées EXIF des photos

Pour tout JPEG capturé avec la caméra intégrée à l'application (§6.5), les balises EXIF peuvent être inspectées avec exiftool :

exiftool -Software -ImageDescription -DateTimeOriginal \
         -DateTimeDigitized -UserComment photo.jpg

Valeurs attendues :

• Software commence par DVR Time Traveler.
• DateTimeOriginal correspond à l'horodatage intégré dans le nom de fichier (p. ex. nom de fichier ...T14-35-22.jpg → EXIF 14:35:22). Un décalage indique que le fichier a été ré-encodé ou que l'EXIF a été réécrit.
• UserComment contient un statut de source de temps (NTP-verified ou device clock) et un champ Device: <ID>. L'ID d'appareil doit correspondre à l'Identifiant d'appareil imprimé sur tout rapport PDF de la même session.

La vérification EXIF est complémentaire, non un substitut, à la somme de contrôle anti-altération et à l'horodatage de confiance du rapport PDF. Elle est particulièrement utile pour déterminer si une photo jointe à un rapport a bien été prise par le même appareil que celui qui a généré le rapport, ou pour authentifier une photo partagée séparément de son rapport.

8. Limites et mises en garde honnêtes

• Outil d'aide à l'enquête, non preuve originale. Le PDF est un artefact dérivé. La preuve originale demeure l'enregistrement de surveillance lui-même.
• Mauvaises entrées, mauvais résultats. Les mathématiques sont exactes ; les données d'entrée ne le sont pas nécessairement. Si l'agent saisit une mauvaise heure de DVR lors de la corrélation, le résultat sera précisément erroné.
• La somme de contrôle anti-altération est un code d'authentification de message à clé (HMAC). HMAC-SHA256 fournit une détection des altérations mais pas la non-répudiation. La non-répudiation découle de l'horodatage RFC 3161.
• Les horodatages RFC 3161 dépendent de l'AHO. Si la clé de signature de l'AHO émettrice est ultérieurement révoquée ou ses opérations mises en cause, la valeur d'assurance des horodatages émis pendant la période concernée devra être réévaluée. SDTech surveille le statut des AHO et peut émettre des avis correspondants.
• L'attestation de la source de temps est ponctuelle. Elle reflète le moment de la génération du rapport, non la santé continue de l'horloge.
• Dépendance réseau. Si l'appareil est hors ligne au moment de la génération, l'horodatage de confiance sera omis (le PDF le stipule clairement) et l'attestation de la source de temps sera marquée INDISPONIBLE. Dans ce cas, l'agent confirme l'exactitude de l'horloge de l'appareil par rapport à une référence temporelle externe avant de procéder ; le rapport documente cet état vérifié par l'agent via l'icône cloud-off et une page d'attestation hors ligne dédiée. Un horodatage de confiance peut être obtenu après coup à l'aide de l'outil à l'adresse verify.sdtech.app (voir §7.5).
• Secret d'application dans le binaire. La clé HMAC est récupérable depuis le binaire de l'application. Cela est documenté ; la conception repose sur RFC 3161 pour la confiance au-delà de la simple détection d'altération.
• Dictionnaire Info PDF et EXIF des photos : informatifs, non cryptographiques. Les propriétés PDF (§4.5) et les balises EXIF des photos (§6.5) rendent la provenance immédiatement visible dans tout lecteur standard, mais elles ne sont pas couvertes par la somme de contrôle anti-altération. Un adversaire averti peut les réécrire avec des outils courants. Leur valeur probante découle de leur cohérence avec les champs couverts par le HMAC sur le rapport et, pour les photos, avec le nom de fichier fixé à l'instant du déclenchement.

9. Questions et réponses anticipées au contre-interrogatoire

Q. « L'agent aurait-il pu manipuler ce rapport ? »

Un agent qui modifie les champs affichés sans régénérer le rapport invalidera la somme de contrôle anti-altération ; la modification sera détectable par recalcul. Un agent qui régénère le rapport après modification produira un nouvel horodatage RFC 3161 avec une heure d'émission ultérieure, ce qui sera visible à la face même du document.

Q. « Comment sait-on que l'horloge de l'application était exacte lors de la génération ? »

Le bloc d'attestation de la source de temps dans le PDF enregistre la dérive entre l'horloge verrouillée de l'application et la médiane de plusieurs sources de temps Internet indépendantes au moment de la génération. Une valeur de dérive de quelques secondes proche de zéro est une preuve contemporaine d'une horloge exacte. Puisque l'application ancre son heure verrouillée à performance.now() (un compteur monotone), l'attestation reste significative même si l'horloge système de l'appareil est modifiée en cours de session — l'ancrage rend le changement détectable.

Q. « Comment sait-on que SDTech n'a pas fabriqué cet horodatage ? »

L'horodatage de confiance est signé par une Autorité d'horodatage externe — FreeTSA, DigiCert ou Sectigo selon la configuration — avec une clé que SDTech ne possède pas. SDTech ne peut pas forger de jeton valide. Le jeton est vérifiable de façon indépendante en utilisant OpenSSL ou toute bibliothèque conforme RFC 3161.

Q. « Et si l'AHO était compromise ? »

La compromission d'une AHO publique constituerait un incident majeur touchant l'ensemble du secteur. SDTech surveille les avis de sécurité des AHO publiques et émettrait un avis correspondant affectant les rapports générés durant toute fenêtre concernée. Des rapports peuvent être ré-ancrés sur une AHO alternative sur demande.

Q. « Cette application est-elle certifiée pour un usage judiciaire ? »

Aucun logiciel n'est « certifié » pour un usage judiciaire au sens général; la recevabilité est tranchée au cas par cas par le tribunal compétent. Ce que l'application fournit, c'est un solide fondement technique à cette détermination : chaque rapport porte une somme de contrôle anti-altération (§4), un horodatage de confiance RFC 3161 indépendant émis par une autorité externe (§5) et un relevé contemporain de l'exactitude de l'horloge (§6) — tous vérifiables par tout tiers à l'aide d'outils standard et accessibles au public. Les tribunaux de diverses juridictions acceptent couramment les preuves numériques horodatées et à détection d'altération lorsqu'elles sont correctement présentées et appuyées par un témoignage. Ce livre blanc et la procédure de vérification ouverte visent à soutenir cette présentation.

Q. « L'agent aurait-il pu fabriquer l'ensemble du scénario ? »

L'application ne peut pas, et ne prétend pas pouvoir, défendre contre un agent qui saisit délibérément de fausses données d'entrée. Ce scénario est identique à un calcul manuscrit contenant délibérément de faux chiffres. Le rôle de l'application est de s'assurer que, compte tenu des données d'entrée telles qu'elles sont enregistrées, l'arithmétique est correcte, le résultat est préservé sans altération et l'événement de génération est indépendamment ancré dans le temps.

10. Normes et références

• RFC 3161 — Protocole d'horodatage de la clé publique Internet X.509 (TSP)
• RFC 5816 — Mise à jour ESSCertIDv2 pour RFC 3161
• FIPS 180-4 — Norme de hachage sécurisé (SHA-256)
• RFC 2104 — HMAC : hachage à clé pour l'authentification de message
• FIPS 198-1 — Code d'authentification de message à clé (HMAC)
• FIPS 197 — Standard de chiffrement avancé (AES)
• NIST SP 800-171 r2 — Protection des informations non classifiées contrôlées
• NIST SP 800-88 r1 — Directives pour la désinfection des médias
• Politique de sécurité CJIS du FBI v6.0 (cartographiée dans le dossier de conformité SDTech, disponible sur demande)
• RFC 8446 — TLS 1.3