OTAP

L’OTA (pour Over The Air) est une technologie permettant d’accéder aux données d’une carte SIM à distance. Il permet par exemple ainsi à 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.

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 avant de l’envoyer à la carte SIM. Ainsi cette interface de soumission de commandes peut être un backoffice crée en interne par l’opérateur ou encore une simple page web accessible aux abonnés, leur permettant d’effectuer des mises à jour sur leurs cartes SIM. Le canal SMS est aujourd’hui utilisé car il est standardisé mais il est envisagé de passer plus tard par les canaux GPRS ou CSD.

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 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 a commande OTA. Il peut donc aussi être 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 à y ajouter les paramètres de sécurité nécessaire à 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 Rereiving Entity (RE) : c’est cette entité que reçoit les paquets sécurisés provenant du SE. Il se charge donc de les reconstituer 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 fournis par le SA dans AM. A 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