Lorsqu'on utilise l'AMC sur mobile sous forme de Code2D il peut être nécessaire de se protéger contre la copie frauduleuse. A cette fin le GT AMC a prévu une méthode pour générer des AMC mobile dynamique. Cette méthode est décrite dan le document https://www.adcet.org/fr/documents-gt-amc?download=151:amc-sur-support-non-calypso-v1-1 et un extrait spécifique à la signature dynamique a été publié https://www.adcet.org/fr/documents-gt-amc?download=190:amc-mobile-avec-signature-dynamique-sur-supports-non-calypso.


Dans notre expérience, pour les échanges entre machines il est toujours préférable de s'affranchir des fuseaux horaires et de l'heure d'été/hiver, qui ne sont utiles que dans les interfaces avec les utilisateurs. Cela évite par exemple des problèmes avec un touriste ayant conservé son téléphone à l'heure de son pays d'origine.

Tous les OS peuvent fournir des horodates UTC, par exemple en Java :

  • Horodate UTC courante : Instant.now().getEpochSecond()
  • Horodate UTC du CB2D : LocalDateTime.of(year, month, day, 0, 0, 0).toEpochSecond(ZoneOffset.UTC) + DynamicDateTime

Pour avoir l’ancienneté du CB2D en secondes, il suffit de comparer ces deux horodates.


La durée de validité d'un CB2D dynamique devrait être égale à sa période de régénération, plus une marge de sécurité pour gérer le décalage d'heure entre les téléphones qui génèrent le CB2D et les lecteurs qui le vérifient.
Par exemple, pour une période de régénération de 20 secondes, une durée de validité de 50 secondes me semble envisageable.
Ces temps devraient être testés sur le terrain, afin de les adapter aux conditions réelles d'exactitude de l'heure des lecteurs et des téléphones.