Over-the-air programming
Cet article ne cite pas suffisamment ses sources ().
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 ».
En pratique : Quelles sources sont attendues ? Comment ajouter mes sources ?L'OTA est un mode de mise à jour automatique. Elle permet par exemple à un opérateur de téléphonie mobile ou directement du fabriquant de mettre à jour le contenu ou d'introduire un nouveau service sur tout un lot de cartes SIM de manière rapide et efficace. 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.
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.
