FR 3028122 A1 20160506 FR 1460656 A 20141105 SYSTEME DE SECURISATION DES ECHANGES ENTRE UN OBJET COMMUNICANT ET UNE PLATEFORME DE SERVICES La présente invention concerne les objets communicants aptes à effectuer certaines tâches sous le contrôle d'une plateforme de services, et/ou d'envoyer des données, par exemple des résultats de mesures, à une plateforme de services. Plus particulièrement, la présente invention concerne la sécurisation des échanges entre un tel objet communicant et la plateforme de services. Les objets communicants visés par l'invention sont de nature extrêmement variée. Il peut s'agir, par exemple, d'un thermomètre, équipé éventuellement d'une alarme sonore, d'une balance, d'un capteur de présence, d'un feu de circulation dont on peut contrôler l'allumage des feux, d'une fenêtre dont on peut contrôler l'ouverture et la fermeture, d'un four offrant plusieurs possibilités de durée et de température de cuisson, et ainsi de suite. De tels objets sont capables, par leurs actions, de faciliter de nombreux aspects de la vie en société. Ces actions peuvent par exemple rendre : - des services de domotique pour contrôler les objets de la maison (on parle de « maison intelligente »), ou - des services de gestion de la ville, tels que parcmètres, poubelles, feux de circulation ou radars, ou encore - des services de santé, notamment pour la surveillance des malades à distance. Le support physique des communications entre ces objets communicants et les plateformes de services peut être d'un type quelconque. Il peut s'agir aussi bien d'une liaison filaire (câble, Ethernet, fibre de verre, et ainsi de suite) que d'une liaison non-filaire (réseau cellulaire, WiFi, Bluetooth, et ainsi de suite). Or le fait que ces objets puissent communiquer à distance les expose à des attaques malveillantes. Pour certains services, ces attaques peuvent avoir des répercussions désastreuses. Considérons par exemple, comme illustré sur la figure 1, un feu de circulation 1, équipé d'un émetteur-récepteur 8 apte à émettre et à recevoir des messages de contrôle, et opéré à distance par une plateforme de services 2 (située, par exemple, au sein d'un poste de gendarmerie) de façon à adapter les changements de couleur (vert/orange/rouge) aux conditions de circulation ; une intrusion malveillante dans un tel système pourrait perturber la circulation automobile, avec de graves risques d'accidents. Il est donc nécessaire dans le cadre de nombreux services de sécuriser les échanges entre l'objet communicant et la plateforme de services avec laquelle il communique. Comme illustré sur la figure 1, on pourrait penser à sécuriser le canal de communication 3 entre l'objet communicant 1 (ou, plus précisément, le dispositif 4 installé par le fabricant et contrôlant les actions de cet objet communicant 1), et la plateforme de services 2 (ou, plus exactement son interface de commande 5). Ce canal sécurisé 3 pourrait par exemple utiliser une clé de chiffrement partagée entre le dispositif de contrôle 4 et l'interface de commande 5. Mais une telle solution serait très peu commode à mettre en oeuvre sur le plan industriel. En effet : - en ce qui concerne les plateformes de services, elles ne sont a priori pas équipées de moyens de production et de distribution de clés de chiffrement/déchiffrement, et - en ce qui concerne les objets communicants, ils ne sont a priori pas équipés de moyens de chiffrement et déchiffrement ; de plus, l'intégration d'une clé de chiffrement personnalisée dans chaque objet communicant 30 représenterait un alourdissement considérable du processus de fabrication et donc une augmentation sensible du coût de fabrication (notamment pour les objets communicants dont la structure est relativement simple, et le fonctionnement relativement rudimentaire). La présente invention concerne donc un système de sécurisation 5 des échanges entre une plateforme de services et un objet communicant comprenant un dispositif de contrôle. Ledit système est remarquable en ce qu'il comprend en outre un serveur, dit serveur de médiation, possédant des moyens pour : - recevoir un message de la part de ladite plateforme de services, 10 chiffrer ce message et envoyer le message chiffré audit objet communicant, et/ou - recevoir un message chiffré de la part de l'objet communicant, déchiffrer ce message et envoyer le message déchiffré à la plateforme de services, 15 et en ce que l'objet communicant est en outre équipé d'une carte à puce possédant des moyens pour : - recevoir un message chiffré émis par ledit serveur de médiation, déchiffrer ce message et envoyer le message déchiffré audit dispositif de contrôle, et/ou 20 - recevoir un message de la part du dispositif de contrôle, chiffrer ce message et envoyer le message chiffré au serveur de médiation, les opérations de chiffrement et de déchiffrement étant réalisées au moyen d'une clé secrète partagée entre le serveur de médiation et la carte à puce. 25 On notera que, dans le cadre de la présente invention, on désigne par « carte à puce » un circuit intégré, par exemple du type « Universal Integrated Circuit Card » (UICC) selon la norme IS0-7816. Il peut s'agir notamment d'une « carte USIM » telle que définie dans les spécifications TS 31.102 et TS 21.1112 du 3GPP (« Third Generation Partnership 30 Project »), ou d'une « carte SIM » telle que définie dans la spécification TS 51.0111 du 3GPP, ou de tout autre objet analogue associé à un opérateur de télécommunications. Ainsi, l'invention propose de tirer profit du fait qu'il existe déjà un procédé de distribution de clés de chiffrement/déchiffrement qui est à la fois très répandu et très fiable, à savoir la distribution de cartes à puce sous la responsabilité des opérateurs de télécommunications. La carte à puce et le serveur de médiation selon l'invention pourront par exemple être commodément gérés par un même opérateur de télécommunications. Par ailleurs, les cartes à puce classiques embarquent un microprocesseur, et sont programmables : il est donc parfaitement possible de programmer une carte à puce (par exemple, au moyen d'une « applet » Java) de manière à ce qu'elle soit capable de chiffrer ou déchiffrer des messages avec une clé de chiffrement/déchiffrement stockée de manière sécurisée dans la carte à puce. On notera que les messages de contrôle échangés entre la carte à puce et le dispositif de contrôle n'auront pas nécessairement à être chiffrés, notamment dans le cas où ces deux éléments sont intégrés dans un boîtier considéré comme inviolable. Par ailleurs, s'il apparaît que le lien entre la plateforme de services et le serveur de médiation est sensible à des intrusions malveillantes, les échanges entre ces deux entités pourront naturellement être chiffrés ou signés. Quoiqu'il en soit, la solution selon l'invention est avantageusement simple et peu coûteuse, car les gérants de la plateforme de services n'auront pas à se soucier de la production et de la distribution de clés de chiffrement/déchiffrement. Par ailleurs, la carte à puce sera de préférence incorporée dans le boîtier de l'objet communicant qu'elle équipe, de sorte que les fabricants d'objets communicants auront seulement besoin de sceller une carte à puce (telle qu'une « embedded SIM >>) dans chaque objet communicant, ou de prévoir, dans chaque objet communicant, un logement standard pour une carte à puce (ainsi que les connexions entre la carte à puce et le dispositif de contrôle). On notera que, dans le domaine de la téléphonie mobile, les cartes à puce sont classiquement utilisées en début de communication téléphonique pour l'authentification mutuelle entre l'utilisateur du téléphone et le réseau mobile, et pour la production d'une clé de session, mais que, suite à ces étapes préalables, la communication est chiffrée/déchiffrée par le téléphone sans aucune participation de la carte à puce. Au contraire, selon la présente invention, toutes les communications entre la plateforme de services et le dispositif de contrôle de l'objet communicant sont interceptées, et chiffrées/déchiffrées, par la carte à puce. Selon des caractéristiques particulières, ladite carte à puce embarque une application conforme à la norme USAT (« USIM Application Toolkit »). Grâce à ces dispositions, on peut commodément établir, entre le serveur de médiation et la carte à puce, un canal de communication mettant en oeuvre le protocole IP (« Internet Protocol »). Les communications entre le serveur de médiation et la carte à puce pourront ainsi avantageusement transiter via n'importe quel réseau IP, tel qu'un réseau Internet, GPRS (« General Packet Radio Service >>) ou UMTS (« Universal Mobile Telecommunications System »). Selon d'autres caractéristiques particulières, le canal de communication entre la carte à puce et ledit dispositif de contrôle (que nous appellerons « canal local >>) met en oeuvre le protocole IP. Selon encore d'autres caractéristiques particulières, les fonctionnalités de l'objet communicant sont représentées comme des ressources bien identifiées, et la carte à puce contrôle ces ressources identifiées au moyen de commandes génériques. Grâce à ces dispositions, le contrôle de l'objet communicant par la carte à puce requiert moins de ressources d'exécution que lorsque ledit canal local met en oeuvre le protocole IP. On notera à cet égard que le fait que le canal de communication entre le serveur de médiation et la carte à puce mette en oeuvre le protocole IP n'implique pas que ledit canal local doive, lui aussi, mettre en oeuvre le protocole IP. Corrélativement, l'invention concerne divers procédés. Elle concerne ainsi, premièrement, un procédé d'actionnement à distance d'un objet communicant comprenant un dispositif de contrôle, Ledit procédé d'actionnement est remarquable en ce qu'il comprend les étapes suivantes : - une plateforme de services envoie à un serveur, dit serveur de médiation, un message contenant une commande d'actionnement, - ledit serveur de médiation chiffre ledit message, et envoie le message chiffré audit objet communicant, - ledit message chiffré est déchiffré par une carte à puce équipant l'objet communicant, et - ladite carte à puce transmet le message déchiffré audit dispositif de contrôle, les opérations de chiffrement et de déchiffrement étant réalisées au moyen d'une clé secrète partagée entre le serveur de médiation et la carte à puce. L'invention concerne aussi, deuxièmement, un procédé de fourniture à distance de données collectées par un objet communicant comprenant un dispositif de contrôle. Ledit procédé de fourniture de données est remarquable en ce qu'il comprend les étapes suivantes : - ledit dispositif de contrôle transmet un message contenant lesdites données à une carte à puce équipant ledit objet communicant, - ledit message est chiffré par ladite carte à puce, - le message chiffré est envoyé par l'objet communicant à un serveur, dit serveur de médiation, - ledit serveur de médiation déchiffre le message chiffré, et envoie le message déchiffré à une plateforme de services, les opérations de chiffrement et de déchiffrement étant réalisées au moyen d'une clé secrète partagée entre le serveur de médiation et la carte à puce. Les avantages offerts par ces procédés sont essentiellement les mêmes que ceux offerts par le système de sécurisation succinctement exposé ci-dessus. L'invention vise également un programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur. Ce programme d'ordinateur est remarquable en ce qu'il comprend des instructions pour l'exécution des étapes du procédé d'actionnement succinctement exposé ci-dessus, ou du procédé de fourniture de données succinctement exposé ci-dessus, lorsqu'il est exécuté sur un ordinateur. Les avantages offerts par ce programme d'ordinateur sont essentiellement les mêmes que ceux offerts par lesdits procédés. D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée ci-dessous de modes de réalisation particuliers, donnés à titre d'exemples non limitatifs. La description se réfère aux figures qui l'accompagnent, dans lesquelles : - la figure 1, déjà décrite ci-dessus, représente un système comprenant un feu de circulation et une plateforme de services reliés par un canal sécurisé, selon l'art antérieur, - la figure 2 représente un système comprenant un feu de circulation et une plateforme de services reliés par un canal sécurisé, selon un mode de réalisation de l'invention, - la figure 3 représente une première variante du mode de réalisation représenté sur la figure 2, - la figure 4 représente une deuxième variante du mode de réalisation représenté sur la figure 2, - la figure 5 représente une troisième variante du mode de réalisation représenté sur la figure 2, et - la figure 6 représente une quatrième variante du mode de réalisation représenté sur la figure 2. Dans le cadre de la présente invention, on considère un objet 10 communicant 1 commandé à distance par une plateforme de services 2. Selon l'invention, l'objet communicant 1 est équipé d'une carte à puce 7. Les messages de contrôle échangés entre le dispositif de contrôle 4 et la plateforme de services 2 passent par cette carte à puce 7 et par un serveur de médiation 6. En outre, le canal reliant la carte à puce 7 au 15 serveur de médiation 6 est sécurisé par chiffrement desdits messages, les opérations de chiffrement et de déchiffrement étant réalisées au moyen d'une clé secrète partagée entre la carte à puce 7 et le serveur de médiation 6. Cette clé secrète peut être stockée dans la carte à puce 7 de manière classique. 20 On notera que, selon l'invention, le dispositif de contrôle 4 n'accepte que les messages de contrôle provenant de la carte à puce 7. On peut envisager, séparément ou simultanément, deux catégories de mise en oeuvre de l'invention. Selon une première catégorie, la plateforme de services 2 actionne 25 à distance l'objet communicant 1, par exemple pour commander un changement de couleur de feu si l'objet communicant 1 est un feu de circulation. Le procédé d'actionnement correspondant comprend les étapes suivantes. Selon une étape 51, la plateforme de services 2 envoie au serveur 30 de médiation 6 un message contenant une commande d'actionnement. Selon une étape S2, le serveur de médiation 6 chiffre ledit message. Selon une étape S3, le serveur de médiation 6 envoie le message chiffré à l'objet communicant 1. Selon une étape S4, ledit message chiffré est déchiffré par la carte à puce 7 équipant l'objet communicant 1. Enfin, selon une étape S5, la carte à puce 7 transmet le message déchiffré au dispositif de contrôle 4, qui actionne alors l'objet communicant de façon classique. Selon une deuxième catégorie, la plateforme de services 2 commande à l'objet communicant 1 de lui fournir des données qu'il a collectées, par exemple une mesure de température si l'objet communicant 1 est un thermomètre. Le procédé de fourniture de données correspondant comprend les étapes suivantes. Selon une étape 5'1, le dispositif de contrôle 4 collecte des données de manière classique, et transmet un message contenant ces données à la carte à puce 7 équipant l'objet communicant 1. Selon une étape 5'2, ledit message est chiffré par la carte à puce 7. Selon une étape 5'3, le message chiffré est envoyé par l'objet 20 communicant 1 au serveur de médiation 6. Selon une étape 5'4, le serveur de médiation 6 déchiffre le message chiffré. Enfin, selon une étape 5'5, le serveur de médiation 6 envoie le message déchiffré à la plateforme de services 2. 25 On va décrire à présent, en référence à la figure 2, un mode de réalisation de l'invention. Dans ce mode de réalisation, la carte à puce 7 embarque (et met en oeuvre) une application conforme à la norme USAT (« USIM Application Toolkit »). On rappelle à cet égard que la spécification TS 31.111 du 3GPP et la norme TS 102 223 de l'ETSI (« European Telecommunications Standards lnstitute ») définissent les possibilités de contrôle d'un terminal par une carte à puce qui y est hébergée : l'ensemble de ces possibilités constitue la norme USAT. Les possibilités offertes par cette norme comprennent notamment : - le contrôle de l'interaction entre le terminal et son utilisateur via l'écran du terminal et/ou via des tonalités sonores ; - l'envoi et la réception de messages SMS (« Short Message 10 Service »), MMS (« Multimedia Messaging Service >>) et USSD (« Unstructured Supplementary Service Data ») ; - le contrôle des appels entrants et sortants ; - l'exécution de commandes « AT » (il s'agit de commandes permettant de contrôler la gestion de l'accès du terminal au réseau mobile 15 ainsi que la gestion de certaines procédures des services conversationnels) ; - l'affichage d'une page Web par un navigateur présent dans le terminal ; - le contrôle de l'exécution d'une application hébergée dans le 20 terminal, par exemple lancement/arrêt ; et - l'établissement d'un canal IP de communication ; ce canal de communication peut être un canal local établi entre l'application USAT et une application dans le terminal, ou un canal établi entre l'application USAT et une application distante dans le réseau. 25 Le contrôle de ces procédures se fait par des commandes appelées « commandes USAT )>. Une application utilisant ces commandes est appelée « application USAT )>. Dans le présent mode de réalisation, la carte à puce 7 est donc munie d'une application USAT. En outre, on établit de préférence un canal 30 IP entre la carte à puce 7 et le serveur de médiation 6; cela peut se faire commodément au moyen de la commande USAT appelée « Open Channel », qui permet à la carte à puce 7 de demander à l'objet communicant 1 d'établir ce canal IP. On va décrire à présent plusieurs variantes de ce mode de réalisation. Selon une première variante, illustrée sur la figure 3 : on établit un canal IP entre la carte à puce 7 et le dispositif de contrôle 4, par exemple en utilisant la commande USAT « Open Channel » mentionnée ci-dessus, et - l'application USAT est générique. Cette première variante présente notamment l'avantage que l'application USAT embarquée dans la carte à puce 7 peut fonctionner avec n'importe quel type d'objet communicant 1, car elle ne fait que relayer les messages de contrôle. Selon une deuxième variante, illustrée sur la figure 4, on établit un canal IP entre la carte à puce 7 et le dispositif de contrôle 4, comme dans la première variante. Mais, dans cette deuxième variante, l'application USAT, au lieu d'être générique, est spécifique au service fourni par l'objet communicant 1, et apte à mettre en oeuvre une logique de service adéquate ; l'application USAT ne se contente donc pas de relayer les messages entre la plateforme de services et le dispositif de contrôle 4. L'application USAT étant spécifique au service et au type d'objet communicant 1, elle ne peut être intégrée par construction dans toutes les cartes à puce destinées à mettre en oeuvre l'invention. L'application USAT pour un service donné peut être pré-provisionnée dans la carte à puce destinée à ce service, ou téléchargée et installée dans la carte à puce après la mise en service de l'objet communicant 1, au moyen, par exemple, du mécanisme OTA (« Over The Air »). Un avantage de cette deuxième variante est qu'elle permet de déporter l'exécution d'une partie de la logique (intelligence) de service dans la carte à puce ; on peut ainsi bénéficier des capacités d'exécution de la carte à puce, et décharger la plateforme de services 2. On notera toutefois que l'utilisation, dans les première et deuxième variantes, d'un canal local mettant en oeuvre le protocole IP implique une certaine complexité de fonctionnement, laquelle résulte, notamment, de l'attribution d'adresses IP, du maintien du canal IP, et de l'encapsulation des commandes dans des paquets IP. C'est pourquoi, selon une troisième variante, illustrée sur la figure 5, les fonctionnalités de l'objet communicant 1 sont représentées comme des ressources bien identifiées ; par exemple, si l'objet communicant 1 est un four, on identifie une ressource « thermostat » (pouvant prendre une série de valeurs correspondant à la gamme de températures accessibles), et une ressource « mode de chaleur » (pouvant prendre une valeur pour le mode « normal » et une autre valeur pour le mode « chaleur tournante »). La plateforme de services 2 connaît l'identification des ressources correspondant aux fonctionnalités de l'objet communicant 1, et peut utiliser des messages de format standard (c'est-à-dire dont la syntaxe et la 20 sémantique sont normalisées), par exemple de format HTTP (« Hypertext Transfer Protocol ») pour manipuler les valeurs de ces ressources. On définit alors des commandes génériques pour permettre à l'application USAT de contrôler ces ressources ; ces commandes génériques peuvent comprendre par exemple une commande « READ » 25 pour lire la valeur courante d'une ressource, et une commande « UPDATE » pour modifier la valeur d'une ressource. Or les normes TS 102 690 (« Machine-to-Machine communications (M2M); Functional architecture >>) et TS 102 921 (« Machine-to-Machine communications (M2M); mla, dia and mfd interfaces ») de l'ETSI définissent une syntaxe 30 pour représenter les fonctionnalités d'un terminal comme des ressources contrôlables avec la technologie REST (« Representational State Transfer >>) ; cette troisième variante marie donc la technologie REST à la technologie USAT. Par ailleurs, dans cette troisième variante, l'application USAT est 5 générique comme dans la première variante (décrite ci-dessus en référence à la figure 3). Cette troisième variante présente notamment les avantages suivants : - la plupart des objets communicants ont un nombre restreint de 10 fonctionnalités : elles sont donc facilement identifiables ; et - l'utilisation de commandes USAT génériques permet d'éviter l'établissement d'un canal IP entre la carte à puce 7 et le dispositif de contrôle 4, et donc de réduire la complexité de fonctionnement ; l'application USAT nécessite ainsi moins de ressources d'exécution, ce 15 qui est particulièrement avantageux en l'occurrence car les ressources d'une carte à puce sont relativement limitées. Une quatrième variante, illustrée sur la figure 6, est analogue à la deuxième variante (décrite ci-dessus en référence à la figure 4) en ce que l'application USAT n'est pas générique : elle est spécifique au service et 20 apte à mettre en oeuvre une certaine logique de service ; l'application USAT ne se contente pas de relayer les messages entre la plateforme de services et le dispositif de contrôle 4. Un avantage de cette quatrième variante est donc qu'elle permet de déporter l'exécution d'une partie de la logique (intelligence) de service 25 dans la carte à puce ; on peut ainsi bénéficier des capacités d'exécution de la carte à puce, et décharger la plateforme de service 2. L'application USAT étant spécifique au service et au type d'objet communicant 1, elle ne peut être intégrée par construction dans toutes les cartes à puce destinées à mettre en oeuvre l'invention. L'application USAT 30 pour un service donné peut être pré-provisionnée dans les cartes à puce destinées à ce service, ou téléchargée et installée dans la carte à puce après la mise en service de l'objet communicant 1, au moyen, par exemple, du mécanisme OTA. Enfin, contrairement à la deuxième variante, les fonctionnalités de l'objet communicant 1 sont représentées ici comme des ressources bien identifiées, et l'application USAT contrôle ces ressources identifiées au moyen de commandes génériques, analogues aux commandes génériques utilisées dans la troisième variante (décrite ci-dessus en référence à la figure 5), avec les avantages qui en résultent. D'autres variantes que les quatre variantes décrites ci-dessus sont naturellement possibles dans le cadre de l'invention. On notera pour terminer que l'invention peut être mise en oeuvre au sein d'un objet communicant, ou d'un serveur de médiation, au moyen de composants logiciels et/ou matériels. Les composants logiciels pourront être intégrés à un programme d'ordinateur classique de gestion de noeud de réseau. C'est pourquoi, comme indiqué ci-dessus, la présente invention concerne également un système informatique. Ce système informatique comporte de manière classique une unité centrale de traitement commandant par des signaux une mémoire, ainsi qu'une unité d'entrée et une unité de sortie. De plus, ce système informatique peut être utilisé pour exécuter un programme d'ordinateur comportant des instructions pour la mise en oeuvre de l'un quelconque des procédés selon l'invention. En effet, l'invention vise aussi un programme d'ordinateur téléchargeable depuis un réseau de communication comprenant des instructions pour l'exécution des étapes d'un procédé selon l'invention, lorsqu'il est exécuté sur un ordinateur. Ce programme d'ordinateur peut être stocké sur un support lisible par ordinateur et peut être exécutable par un microprocesseur. Ce programme peut utiliser n'importe quel langage de programmation, et se présenter sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations, inamovible, ou partiellement ou totalement amovible, lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comprendre un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou un moyen d'enregistrement magnétique, tel qu'un disque dur, ou encore une clé USB (« USB flash drive » en anglais). D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme d'ordinateur selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. En variante, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution de l'un quelconque des procédés selon l'invention.25 REVENDICATIONS1. Système de sécurisation des échanges entre une plateforme de services et un objet communicant comprenant un dispositif de contrôle, ledit système étant caractérisé en ce qu'il comprend en outre un serveur, dit serveur de médiation (6), possédant des moyens pour : - recevoir un message de la part de ladite plateforme de services (2), chiffrer ce message et envoyer le message chiffré audit objet communicant (1), et/ou - recevoir un message chiffré de la part de l'objet communicant (1), déchiffrer ce message et envoyer le message déchiffré à la plateforme de services (2), et en ce que l'objet communicant (1) est en outre équipé d'une carte à puce (7) possédant des moyens pour : - recevoir un message chiffré émis par ledit serveur de médiation (6), déchiffrer ce message et envoyer le message déchiffré audit dispositif de contrôle (4), et/ou - recevoir un message de la part du dispositif de contrôle (4), chiffrer ce message et envoyer le message chiffré au serveur de médiation (6), les opérations de chiffrement et de déchiffrement étant réalisées au moyen d'une clé secrète partagée entre le serveur de médiation (6) et ladite carte à puce (7). 2. Système de sécurisation selon la revendication 1, caractérisé en ce que ladite carte à puce (7) embarque une application conforme à la 25 norme USAT (« USIM Application Toolkit »). 3. Système de sécurisation selon la revendication 2, caractérisé en ce que ladite application USAT est générique. 4. Système de sécurisation selon la revendication 2, caractérisé en ce que ladite application USAT est spécifique au service fourni par l'objet communicant (1). 5. Système de sécurisation selon l'une quelconque des revendications 1 à 4, caractérisé en ce que le canal de communication entre la carte à puce (7) et ledit dispositif de contrôle (4) met en oeuvre le protocole IP. 6. Système de sécurisation selon l'une quelconque des revendications 1 à 4, caractérisé en ce que les fonctionnalités dudit objet communicant (1) sont représentées comme des ressources bien identifiées, et en ce que ladite carte à puce (7) contrôle lesdites ressources identifiées au moyen de commandes génériques. 7. Procédé d'actionnement à distance d'un objet communicant comprenant un dispositif de contrôle, caractérisé en ce qu'il comprend les étapes suivantes : - une plateforme de services (2) envoie (51) à un serveur, dit serveur de médiation (6), un message contenant une commande d'actionnement, - ledit serveur de médiation (6) chiffre (S2) ledit message, et envoie (S3) le message chiffré audit objet communicant (1), - ledit message chiffré est déchiffré (S4) par une carte à puce (7) équipant l'objet communicant (1), et - ladite carte à puce (7) transmet (S5) le message déchiffré audit dispositif de contrôle (4), les opérations de chiffrement et de déchiffrement étant réalisées au moyen d'une clé secrète partagée entre le serveur de médiation (6) et la carte à puce (7). 8. Procédé de fourniture à distance de données collectées par un objet communicant comprenant un dispositif de contrôle, caractérisé en ce qu'il comprend les étapes suivantes : - ledit dispositif de contrôle (4) transmet (Si) un message contenant lesdites données à une carte à puce (7) équipant ledit objet communicant (1), - ledit message est chiffré (S'2) par ladite carte à puce (7), - le message chiffré est envoyé (S'3) par l'objet communicant (1) à un serveur, dit serveur de médiation (6), - ledit serveur de médiation (6) déchiffre (S'4) le message chiffré, et envoie (S'5) le message déchiffré à une plateforme de services (2), les opérations de chiffrement et de déchiffrement étant réalisées au moyen d'une clé secrète partagée entre le serveur de médiation (6) et la carte à puce (7). 9. Moyen de stockage de données inamovible, ou partiellement ou totalement amovible, comportant des instructions de code de programme informatique pour l'exécution des étapes d'un procédé d'actionnement selon la revendication 7 ou d'un procédé de fourniture de données selon la revendication 8. 10. Programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions pour l'exécution des étapes d'un procédé d'actionnement selon la revendication 7 ou d'un procédé de fourniture de données selon la revendication 8, lorsqu'il est exécuté sur un ordinateur.