Remédier aux vulnérabilités du signal GPS (spoofing & jamming)

La dernière version de firmware 6.24 LANTIME intègre une nouvelle fonctionnalité appelée “Trusted Reference Source (TRS)”. Cette fonctionnalité supplémentaire est très attendue par tous ceux qui recherchent une méthode pour diminuer les vulnérabilités du signal GPS (spoofing, jamming).

La fonctionalité TRS est réalisée par l’adjonction au module récepteur GPS intégré dans un serveur IMS, d’un oscillateur externe Rubidium (XHE). La fonctionalitée TRS effectue des contrôles de cohérence sur le temps GPS reçu et mesure l’écart par rapport à une limite configurable par l’utilisateur.

Le Rubidium externe fonctionne en mode “holdover back-up”, et est synchronisé par le master IMS tant que celui-ci est disponible. Si le signal GPS fournit des informations incohérentes ou dérive, la fonction TRS détectera une violation, et l’algorithme de sélection de la source de référence (IRSA) invalidera la source GPS et la source Rubidium XHE deviendra la source de référence.

Lorsque le signal GPS revient dans la limite fixée, La source GPS redevient la référence de temps.

Les 4 étapes de configuration du mode “TRS” :

  • La source GPS doit être sélectionnée en tant que source de priorité 1 et la source “ext. OSC” (se référant à XHE Rubidium) doit être configure en priorité 2. [Interface graphique Web LANTIME-> Horloge-> Horloge GNS-> Priorité source]
  • L’algorithme de sélection de référence IRSA doit être activé. Une “limite TRS” est définie (250ns dans notre exemple) que la source GPS Master doit respecter.
  • Le mode TRS doit être activé en sélectionnant “Use Trusted Source” pour le master GPS. Le XHE Rubidium doit être configuré comme “Is Trusted Source”. [Interface graphique Web de LANTIME-> Horloge-> Fonctions GNS horloge->].
  • On indique que la source GPS est la source de reference pour le temps (Time Of Day) et pour la phase (PPS). Au niveau du Rubidium XHE, seule la source de phase doit être activée, car l’horloge atomique seule ne fournit pas d’informations sur l’heure de la journée.

TRS Monitoring :

Le fonctionnement du mode TRS peut être surveillé dans le “status MRS”. Tant que le décalage temporel entre le GPS et le Rubidium ne dépasse pas l’offset défini, l’état de fonctionnement normal est indiqué ci-dessous.

Lorsque la limite est dépassée, l’algorithme de référence rejette le master et passe automatiquement à “ext. Oscillator”(c’est-à-dire XHE Rubidium) et le flag “Limite TRS dépassée”est indiqué dans les informations d’état de la source GPS. Le dépassement est également répertorié dans la matrice des événements de notification et l’événement peut être envoyé sous différentes formes (email, syslog, trap snmp…) pour la surveillance.

Meinberg facilite la migration vers IP des studios Radio et TV

De nombreuses chaines de télévision ou de radio ont des projets concrets qui vont voir arriver l’IP de bout en bout dans les années à venir. Tout comme dans les réseaux télécoms, le transport de la synchronisation est un aspect majeur dans les infrastructures broadcast.

Meinberg, leader des solutions de synchronisation temps-fréquence, s’implique fortement depuis 2014 dans les instances de normalisation liées aux métiers du broadcast et des médias. Partenaire officiel de RAVENNA, Meinberg a rejoint l’association SMPTE en 2015 et AIMS (Alliance for IP Media Solutions) en 2017.

Les nouvelles solutions IMS (Intelligent Modular Synchronization) permettent une rapide adaptation à l’ensemble des industries. Déjà leader des serveur de temps PTP pour de nombreuses industries, le développement de nouveaux modules générant les signaux audio (DARS) et video (Black Burst) offre désormais une solution idéale pour les studios radio et TV désirant effectuer une migration de SDI vers IP.

La solution de synchronisation pour les studios Radio/TV :

Le M1000 est une solution modulaire sur un chassis 1U disposant de 2 slots alimentation, 2 slots horloge de référence, 1 slot CPU et 3 ou 4 slots d’entrées/sorties.

Equipé d’un module PTP HPS-100 et de modules Video Sync Generator (VSG) et « Studio Clock Generator », le M1000 délivre l’ensemble des signaux de synchronisation utiles. Il permet en effet de générer une synchronisation sur IP via le protocole PTP SMPTE ST-2059-2 (broadcast profile), mais également la génération des signaux traditionnels audio (word clock, DARS) et video (bi-level sync/Black Burst, Tri-Level Sync, Sync Signals (H-Sync, V-Sync, …), DARS)

Documentation module VSG

Documentation module SCG

MiFID 2 and Clocks synchronisation

Une des dispositions issues de la révision de la directive MiFID que les Prestataires de Services d’Investissements (PSI) devront avoir mise en place concerne la synchronisation des horloges. Cet article détaille les aspects techniques permettant sa mise en œuvre.

    1. Qu’est-ce que MiFID 2 ?

La directive sur les marchés des instruments financiers (MiFID 2) est une réglementation européenne pour les marchés financiers. Elle a été publiée dans le Journal officiel de l’UE le 12 juin 2014. La directive permet à l’ESMA, l’Autorité européenne des marchés financiers et de valeurs mobilières d’élaborer des normes techniques réglementaires (RTS) ainsi que la mise en œuvre de normes techniques (STI). L’ESMA a livré trois ensembles de normes techniques en 2015. Le plan initial était de mettre ces normes en vigueur le 1er janvier 2017. En raison de la complexité élevée et des défis techniques, cela a été reporté à janvier 2018.

    1. Qu’est-ce que RTS 25 ?

La Norme technique réglementaire RTS25 fait partie des normes élaborées par l’AEMF dans le cadre de la MiFID II. RTS 25 définit des normes pour la synchronisation de l’horloge, reconnaissant que ce sujet a un impact direct dans de nombreux processus financiers. La vitesse et le volume de transactions financières toujours croissants nécessitent un horodatage plus précis. RTS 25 couvre deux sujets principaux: la référence de temps à utiliser et le niveau de précision requis pour les horodatages utilisés dans les transactions.

L’article 1 du RTS 25 définit que la référence de temps utilisée doit être un Temps Universel Coordonné (UTC). UTC est une échelle de temps maintenue par le Bureau International des Poids et Mesures (BIPM) dont le siège social est situé à Paris. L’échelle de temps provient de la comparaison de plus de 70 horloges atomiques répartie dans le monde.

L’article 2 du RTS25 spécifie les exigences de précision pour les horloges professionnelles en fonction du « gateway-to-gateway latency » de la plate-forme de négociation : la divergence maximale par rapport à l’UTC d’être soit 1 milliseconde (latence de gw-to-gw de> 1 ms), soit 100 microsecondes (gw-to- Gw latence = <1 ms). La granularité des horodatages peut être soit 1 milliseconde, soit 1 microseconde, en fonction également du temps de latence du « gateway-to-gateway latency ». La plupart des opérateurs de marché se trouveront confrontés aux exigences de divergence < 100us et de granularité 1us.

L’article 3 du RTS25 explicite les cinq types d’activité commerciale avec pour chacune la divergence et la granularité exigées. La précision de 100 microsecondes et la granularité de 1 microseconde sont requises pour l’activité de trading algorithmique haute fréquence dans ce tableau.

L’article 4 du RTS25 définit l’obligation d’un système de traçabilité et la capacité à fournir des preuves en documentant la conception et les spécifications du système. Il est également nécessaire d’identifier le point exact auquel un horodatage est appliqué. Enfin, l’article précise que la vérification de la conformité du système de traçabilité UTC doit être effectuée chaque année.

    1. Les solutions Meinberg pour assurer la conformité aux exigences MiFID II

Les exigences du RTS25 : « “Operators of trading venues and their members or participants shall synchronize the business clocks they use to record the date and time of any reportable event with the Coordinated Universal Time (UTC) …». Le terme « business clock » n’est pas clairement défini, mais on peut supposer dans ce contexte qu’il s’agit des horloges des OS des serveurs qui effectuent l’enregistrement de la date et l’heure des événements. Les serveurs de temps NTP et PTP Meinberg permettent de synchroniser ces horloges. Il est important que la majeure partie des 100us de budget reste disponible pour le serveur réalisant l’opération d’enregistrement, et donc que le serveur NTP ou PTP atteigne une précision bien supérieure à 100us.

Il est communément admis par la communauté technique qu’une précision de 100us est difficile à assurer avec le protocole NTP. Cela est possible mais avec un environnement hardware et software (OS) optimisé, et de toute façon prendrait une large part des 100us allouée. Il est fortement conseillé et communément admis que le protocole PTP doit être utilisé pour être conforme aux exigences de MiFID II.

    1. « Compliance Review » : Pourquoi implémenter un outil de monitoring ?

L’article 4 of RTS 25 requiert une revue annuelle prouvant sur une base documentaire la conformité aux exigences. Par ce biais il ne sera pas possible de démontrer que la précision est garantie en permanence, et une bonne solution est d’implémenter un outil de monitoring de la précision des horloges. Meinberg a développé un outil de monitoring des « nœuds PTP » et collabore avec des vendeurs de « PTP stacks » pour s’assurer qu’un maximum d’implémentations PTP supporte cette fonction monitoring. Pour plus d’informations sur cet outil NetSyncMonitor, lire ce document.