Over-the-air programming

Cet article ne cite pas suffisamment ses sources (septembre 2014). Si vous disposez d'ouvrages ou d'articles de référence ou si vous connaissez des sites web de qualité traitant du thème abordé ici, merci de compléter l'article en donnant les références utiles à sa vérifiabilité et en les liant à la section « Notes et références » (modifier l'article, comment ajouter mes sources ?).

L’OTA (pour over the air) est une technologie permettant d’accéder aux données d’une carte SIM à distance. Elle permet par exemple à un opérateur de téléphonie mobile de mettre à jour le contenu ou d'introduire un nouveau service sur tout un lot de cartes SIM de manière rapide, efficace et peu coûteuse. Par extension ce sigle désigne aussi les technologies permettant de distribuer et d'installer de nouvelles versions de firmware dans un équipement mobile, téléphone, smartphone ou tablette par exemple.

L’OTA est basé sur une architecture où d’une part il y a une interface de soumission de commandes (hébergée chez l’opérateur) et d’autre part une carte à puce. Via l’interface, la commande est envoyée à une passerelle OTA qui se charge alors de la convertir en un SMS (et en codes USSD) avant de l’envoyer à la carte SIM. Cette interface de soumission de commandes peut être un backoffice créé en interne par l’opérateur ou encore une simple page web accessible aux abonnés, leur permettant d’effectuer des mises à jour sur leur carte SIM ou leur téléphone mobile. Le canal SMS est utilisé car il est standardisé mais on peut aussi passer par les canaux CSD, GPRS ou les canaux de donnée des terminaux compatibles UMTS (3G).

Il apparaît clairement que l’enjeu principal voire la difficulté est la gestion des transactions entre la passerelle OTA et la carte à puce. Chaque opérateur peut concevoir un certain nombre de procédures à cet effet. Cependant une norme standard a été définie par le 3GPP afin de garantir une interopérabilité, c’est la norme GSM 03.48.

La norme GSM 03.48, publiée en 2003, décrit assez exhaustivement une transaction OTA de manière générale, la structure des données qui transitent au cours de la transaction et l’implémentation de l’OTA via les SMS. Une dernière partie est consacrée à la description des commandes OTA ainsi qu’à la présentation de quelques commandes en guise d’exemple.

Différentes entités d’une transaction OTA

Une transaction OTA fait intervenir quatre grandes entités :

• un sending application (SA) : c’est toute application capable d’émettre une commande OTA. Il peut par exemple s’agir d’une application résidant dans la carte SIM ou simplement d’une interface applicative résidant chez l’opérateur ;
• un receiving application (RA) : c’est l’application destinataire de la commande OTA. Il peut donc aussi s'agir d'une application résidant dans la carte SIM ou simplement d’une interface applicative résidant chez l’opérateur ;
• un sending entity (SE) : elle se charge de convertir les commandes envoyées par le SA et ajoute les paramètres de sécurité nécessaires à un envoi en toute sécurité sur le réseau. Il peut s’agir par exemple d’un SMS-SC (jouant le rôle de passerelle OTA) ou d’une simple carte SIM qui envoie des commandes ;
• un receiving entity (RE) : c’est cette entité que reçoit les paquets sécurisés provenant du SE. Il se charge donc de les reconstituer et d’enlever toutes les en-têtes de sécurité précédemment ajoutées afin de permettre l’exploitation de la donnée.

Entre les quatre entités précédemment citées transitent deux types de données :

• Application message (AM) : c’est un paquet de données sans paramètres de sécurité ni en-tête produit par un SA. C’est d’ailleurs le seul type de paquet manipulable par ce dernier. Il peut aussi être reçu par un RA de la part d’un RE pour exploitation ;
• Secured packet (SP) : à la réception d’un AM, le SE y ajoute des paramètres de sécurité (command ou response header) ainsi que des indications précises sur ces paramètres (SPI pour security parameter indicator) pour ainsi former un paquet sécurisé appelé secured packet ;
• Secured command packet (SCP) : c’est un SP résultant d’une commande émise par un SA (à travers un AM) et traitée par un SE (ajout d’un Command Header) ;
• Secured response packet (SRP) : c’est un SP envoyé un RE en réponse à une commande venant d’être traitée pas le RA. Un SRP est constitué d’un en-tête (response header) et, facultativement, de certaines données fournies par le RA à titre informatif sur la commande venant d’être exécutée.

Description d'une transaction OTA

Un application message (AM) est produit par les sending application (SA) et envoyé au sending entity (SE). Ce dernier y ajoute le command header (CH) qui contient l’ensemble des paramètres de sécurité, généré suivant des indications fournies par le SA dans AM. À partir de ce moment l’ensemble AM + CH et appelé secured command packet (SCP) et c’est justement ce paquet qui est envoyé sur le réseau.

Le receiving entity (RE) est à la réception du SCP et se charge alors d’enlever les en-têtes de sécurité (command header) et de transmettre l’AM ainsi reconstitué au receiving application. Le RE est aussi tenu de créer un secured response packet (SRP) si celui-ci est exigé par le SE. Le SRP sera constitué d’un response header (RH) et d’une partie facultative constituée de données fournies par le RA et sera sécurisé suivant les paramètres contenus dans le CH.

• Portail de l’informatique
• Portail des télécommunications