Les ateliers «Terminal»

Les TPE sont des terminaux Android et qui disposent d'un SDK, propre à leur constructeur et éventuellement au modèle de terminal.

Toute application qui leur est destinée est ciblée:

• elle utilise la plateforme Android durcie du constructeur
• elle exploite les API du SDK constructeur quand elle en a besoin (toujours si c'est une application de paiement)
• elle est signée avec un outil constructeur pour être reconnue par le terminal et pouvoir s'y exécuter.

Toute application est donc déclinée en autant d'occurrences signées, par version de SDK de chaque constructeur.

☛ Un principe de base: un terminal est toujours et seul à l'initiative de toute connexion vers l'extérieur. Les terminaux ne disposent pas en effet a priori d'adresse publique internet qui permettrait de les atteindre (depuis un client et ils seraient serveurs), d'autant qu'ils se trouvent «derrière» la box de l'installation du commerçant et son FAI, ou pire, «derrière» un opérateur télécom dans le cas de terminaux GPRS.

☛Autre point qui paraît essentiel: un terminal n'est pas nativement nexo. Il sera a priori livré «vide» d'application de paiement; il sera livré avec a minima un moyen de se connecter au serveur CA-PS, lequel serveur sera le seul à pouvoir le contrôler sur les périmètres de :

• téléchargement d'applications;
• injection de clés techniques et fonctionnelles à distance;
• initialisation et modifications de paramètres du terminal: configuration de passerelle, désactivation de la géolocalisation, mise en service de la caméra, etc…

Ce moyen de connexion, on l’appellera «Device Managment Agent». Il s'agira d'une application Android fournie par CA-PS, signée et livrée avec le terminal par son constructeur en phase de personnalisation.

Sa couverture fonctionnelle et ses données:

• Des paramètres persistants, rechargeables par l'application et modifiables par un échange serveur ou par un mainteneur via une IHM Agent sur le terminal:
  • adresse(s) — nominale et de secours (n niveaux de secours) — d'appel au serveur TMS/MDM
  • adresse(s) — nominale et de secours (n niveaux de secours) — de la passerelle intermédiaire s'il y a lieu
  • fréquence des appels récurrents au serveur: Par exemple toutes les 5 minutes
  • date et heure du terminal (important pour l'horodatage des transactions, fonction du fuseau horaire)
    Accès à un serveur de temps ? décalage heure d'hivers/heure d'été ? Android fait sa nativement ?
  • Autoriser/interdire l'accès local à des fonctionnalités Android
  • …
    
    
• Appels récurrents: «Je suis le terminal xyz, je suis vivant… Qu'as-tu pour moi ?»…
  
  
• En réponse à cet appel récurrent, le serveur peut avoir plusieurs natures de demandes en retours, dont les spécifications, le(s) protocole(s) d'échange et la(les) cinématique(s) mis en œuvre sont à définir:
  1. « Merci xyz, rien pour toi, peut-être à ton prochain appel ?» …
  2. demande paramétrage agent: lecture et/ou modification d'un ou plusieurs des paramètres de l'agent
  3. demande informations techniques: état enrichi avec % utilisation de la mémoire RAM, occupation de mémoire de stockage, charge CPU…, statut wifi, opérateur SIM utilisé, volume de data consommé, liste des applications installées / en exécution, etc…
  4. demande informations clés: Liste des clés, dates d'expiration de ces clés, liste des emplacements occupés, nombre d'emplacements libres…
  5. modification dans le fonctionnement du terminal: arrêt GPS, activation wifi…). A priori c'est de l’«Android natif» ?
  6. demande d'échanges bidirectionnels de fichiers: les paramètres d'une application métier poussé par le serveur sur le terminal, un fichier de log d'une application est envoyé au serveur, …
  7. suppression d'une application installée
  8. mécanisme de réception d'applications (fichier .apk signés), prévoir de les installer et les vérifier (si possible - inutile de garder une application qui ne s'exécutera pas parce qu'elle n'est pas ou pas bien signée) avec un compte-rendu de l'opération remonté au serveur.
     Passe la main aux mécanismes Android: téléchargement/installation ?
  9. mécanisme de Remote Key Injection (RKI) afin que le terminal reçoive et stocke dans les zones appropriées, des données de sécurité exploitées par le terminal et/ou ses applications, en provenance du serveur: clés techniques, clés fonctionnelles, certificats…
     Ce mécanisme devra être à l'état de l'art méthodologique et sécuritaire. L'agent devra connaître les accès «SDK Constructeur» aux fonctions appropriées de gestion des clés sur le terminal, prévues pour les recevoir et les stocker dans les zones de persistance adéquates sur le terminal. L'emplacement d'une clé ainsi injectée devra être connu et éventuellement remonté au serveur afin que celui-ci l'indique en paramètre des applications utilisatrices de cette clé.

• Le DM-Agent sera accessible via une interface sur le terminal, avec peut-être certaines fonctionnalités accessibles seulement par un utilisateur habilité (moyen d'accès à définir). Cette IHM permettra de contrôler les fonctionnalités de l'agent: forcer un appel, choisir une application à téléchargée disponible sur le serveur, lister les clés et leurs dates de validité, consulter les log locales, fixer la date et l'heure du terminal etc… Certaines de ces fonctionnalité sont Android: en autoriser l'usage pour celles qu'on souhaite laisser accessibles.
  
  
• Le DM-Agent (et ses paramètres) doit pourvoir être téléchargeable pour son installation ou sa mise à jour par le serveur. Sur les terminaux en Android/CB6 «transitoires», cette action pourrait être réalisée par les Machines de Diffusion de Programmes des constructeurs.
  Peut-on faire une mise à jour d'une appli qui elle-même assure les échanges ?
  
  
• Plus tard, le DM-Agent pourrait être un intermédiaire dans une prise de contrôle du terminal ou son affichage déporté sur le serveur ?