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. 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é.

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 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.

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'appareil 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.

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. Code d'authentification du document

Chaque rapport PDF contient un Code d'authentification du document, une valeur hexadécimale de 64 caractères dérivée d'un hachage SHA-256 à clé 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 et la version de l'application.

4.1 Données d'entrée

Les champs suivants sont concaténés, par ordre alphabétique de clé, sous forme de chaîne JSON déterministe, et combinés avec un secret d'application fixe :

• 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)

4.2 Algorithme

code = SHA-256( JSON(champs, clés_triées) ‖ secret_d_application )

Les 12 premiers caractères hexadécimaux du code forment l'identifiant de document lisible par l'humain, préfixé DVR-TT-. 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 hachage à clé, 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 indépendant

SDTech offre un Service professionnel de vérification de l'authentification des documents destiné aux agences et aux professionnels du droit qui requièrent une confirmation indépendante et tierce qu'un rapport DVR Time Traveler n'a pas été altéré. Sur demande, SDTech recalcule le Code d'authentification du document à partir des champs visibles sur le rapport et confirme si le code correspond — fournissant une attestation indépendante recevable en procédure judiciaire.

Pour demander une vérification ou en savoir plus sur ce service, contactez [email protected].

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'appareil affichée dans le rapport était correcte. Cette assurance est fournie indépendamment par la §6.

6. Attestation de la source de temps

Lors de chaque génération de rapport, l'application effectue une attestation de la source de temps indépendante : elle interroge plusieurs sources de temps Internet non corrélées et calcule le décalage de consensus entre l'horloge de l'appareil et ces sources. Le résultat est inclus textuellement dans le PDF.

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)
• WorldTimeAPI (JSON utc_datetime)
• TimeAPI.io (JSON dateTime en UTC)

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

• La dérive entre l'horloge de l'appareil et le consensus, en millisecondes.
• Le nombre d'échantillons réussis et l'écart (1σ).
• Un tableau par source indiquant l'heure rapportée et la dérive individuelle de chaque source.
• Un statut global : OK (≥ 2 sources), DÉGRADÉ (1 source), INDISPONIBLE (0 source).

6.4 Résolution et aptitude à l'usage

Le temps servi par HTTP a une résolution typique de 50 à 250 millisecondes. 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.

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 le Code d'authentification du document

1. Lire tous les champs numériques du PDF tels qu'affichés.
2. Recalculer le hachage SHA-256 à clé selon la §4. (Pour une vérification indépendante, contacter SDTech pour obtenir l'outil de vérification.)
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://license.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://license.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.

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é.
• Le Code d'authentification est un hachage à clé. Il 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 se rabattra sur l'horloge de l'appareil seule (statut : INDISPONIBLE).
• Secret d'application dans le binaire. Le secret du hachage à clé 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.

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 le Code d'authentification du document ; 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'appareil é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 de l'appareil 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.

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 ? »

L'application est un outil. La recevabilité est déterminée par le tribunal, par référence aux fondements établis par la partie qui la produit. Ce livre blanc, la procédure de vérification à source disponible et l'utilisation de primitives cryptographiques standard visent à soutenir l'établissement de tels fondements.

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)
• 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