BE1024111A1 - Microcontroleur pour demarrage securise avec pare-feu - Google Patents

Microcontroleur pour demarrage securise avec pare-feu Download PDF

Info

Publication number
BE1024111A1
BE1024111A1 BE20165612A BE201605612A BE1024111A1 BE 1024111 A1 BE1024111 A1 BE 1024111A1 BE 20165612 A BE20165612 A BE 20165612A BE 201605612 A BE201605612 A BE 201605612A BE 1024111 A1 BE1024111 A1 BE 1024111A1
Authority
BE
Belgium
Prior art keywords
secure
microcontroller
operating system
area
linux
Prior art date
Application number
BE20165612A
Other languages
English (en)
Other versions
BE1024111B1 (fr
Inventor
Frédéric Richez
Sven Gulikers
Original Assignee
Atos Worldline S A
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Atos Worldline S A filed Critical Atos Worldline S A
Priority to ES17170242T priority Critical patent/ES2927289T3/es
Priority to EP17170239.2A priority patent/EP3244376A1/fr
Priority to EP17170242.6A priority patent/EP3244377B1/fr
Priority to EP17170202.0A priority patent/EP3244375B1/fr
Publication of BE1024111A1 publication Critical patent/BE1024111A1/fr
Application granted granted Critical
Publication of BE1024111B1 publication Critical patent/BE1024111B1/fr

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0873—Details of the card reader
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/575—Secure boot
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/74—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information operating in dual or compartmented mode, i.e. at least one secure mode
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/82—Protecting input, output or interconnection devices
    • G06F21/85—Protecting input, output or interconnection devices interconnection devices, e.g. bus-connected or in-line devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/86—Secure or tamper-resistant housings
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/86—Secure or tamper-resistant housings
    • G06F21/87—Secure or tamper-resistant housings by means of encapsulation, e.g. for integrated circuits
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F19/00—Complete banking systems; Coded card-freed arrangements adapted for dispensing or receiving monies or the like and posting such transactions to existing accounts, e.g. automatic teller machines
    • G07F19/20—Automatic teller machines [ATMs]
    • G07F19/205—Housing aspects of ATMs
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0873—Details of the card reader
    • G07F7/088—Details of the card reader the card reader being part of the point of sale [POS] terminal or electronic cash register [ECR] itself

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Mathematical Physics (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer And Data Communications (AREA)
  • Control Of Vending Devices And Auxiliary Devices For Vending Devices (AREA)
  • Cash Registers Or Receiving Machines (AREA)

Abstract

(57) La présente invention concerne un microcontrôleur comprenant un processeur et une mémoire divisée en différentes zones qui sont sécurisée, non sécurisée ou partagée, pour mettre en uvre un démarrage sécurisé comprenant un circuit de commande d'autoprotection pour détecter les conditions de vulnérabilité et le processeur exécutant un système d exploitation Linux, ledit processeur comprenant un moniteur pour commuter les opérations soit dans une zone sécurisée de la mémoire pour faire fonctionner au moins des processus d'authentification soit dans une zone non sécurisée pour d'autres opérations et déterminer si les périphériques connectés ou accédant au, ou accédés par le microcontrôleur doivent être gérés par la zone sécurisée ou par la zone non sécurisée en utilisant un pare-feu matériel pour déterminer si I information ou la commande d une application est autorisée à accéder à la zone sécurisé ou non.

Description

Microcontrôleur pour démarrage sécurisé avec pare-feu
DOMAINE TECHNIQUE DE L'INVENTION
La présente invention se rapporte au domaine de la protection des données et en particulier des données échangées dans les transactions financières. La présente invention concerne spécifiquement un dispositif pour assurer la sécurité des échanges de données confidentielles entre un client et une institution financière ou entre deux institutions financières.
ARRIERE-PLAN TECHNOLOGIQUE DE L'INVENTION
La protection des données sensibles utilisées dans les transactions financières est un défi majeur pour le domaine de l’économie. Les transactions peuvent être faites soit par l’intermédiaire d’un site web dédié, le site web utilisant le cryptage et plusieures mesures de vérification soit au moyen d’un dispositif tel que des distributeurs automatiques. Ces derniers autorisent les transactions à l’aide de cartes avec au moins une puce électronique, la puce contenant au moins une information d’authentification du détenteur de la carte. Néanmoins, les dispositifs tels que les distributeurs automatiques présentent des inconvénients. En effet, un distributeur automatique comprend une mémoire qui stocke les codes d’authentification récupérés à partir d’un réseau interbancaire, par exemple. Une défaillance volontaire ou involontaire de la machine, cependant, peut permettre à un pirate de récupérer les données de la mémoire contenue dans la machine. Bien que certains progrès dans la protection des distributeurs automatiques aient été réalisés ces dernières années, les machines ont encore des inconvénients associés à leur architecture et/ou des composants électroniques qu’ils contiennent.
Dans le document US7953989 B1, il est enseigné un dispositif comprenant un microcontrôleur haute sécurité qui comprend des circuits de commande d’autoprotection pour détecter des conditions de vulnérabilité: une écriture dans la mémoire du programme avant que les informations financières sensibles aient été effacées, une condition détection de sabotage, l’activation d’un débogueur, une condition de mise sous tension, une condition de températures non conformes, une condition de tension d’alimentation non conformes, une condition de défaillance d’un oscillateur, et une condition de retrait de la batterie. Si le circuit de commande d’autoprotection détecte une condition de vulnérabilité, alors la mémoire où les informations financières sensibles pourraient être stockées, est effacée. Lors de la mise sous tension si une image valide est détectée dans la mémoire du programme, alors le chargeur d’amorçage n’est pas exécuté et la mémoire sécurisée n’est pas effacée mais plutôt l’image est exécutée, le circuit de commande d’autoprotection étant un automate qui est hors du contrôle du logiciel chargé par un utilisateur et hors du contrôle du débogueur. L’un des inconvénients du dispositif décrit ci-dessus est que la sécurité du système dépend entièrement du bon fonctionnement du dispositif d’autoprotection. En effet, si ce dernier était défectueux, la sécurité de l’ensemble du système serait compromise.
DESCRIPTION GENERALE DE L'INVENTION
La présente invention a pour but de pallier un ou plusieurs inconvénients de l'art antérieur en proposant qui peut protéger de manière efficace les échanges de données dans les transactions financières et empêcher le vol de données par dégradation de la machine contenant ledit dispositif.
Ce but est atteint par un microcontrôleur comprenant un processeur et une mémoire séparée en différentes zones qui sont sécurisées, non sécurisées ou partagées, pour mettre en œuvre un démarrage sécurisé comprenant un circuit de commande d'autoprotection pour détecter les conditions de vulnérabilité et le processeur exécutant un système d’exploitation Linux (Linus OS), ledit processeur comprenant un moniteur pour commuter les opérations soit dans une zone sécurisée de la mémoire pour faire fonctionner au moins des processus d'authentification soit dans une zone non sécurisée pour d'autres opérations et déterminer si les périphériques connectés ou accédant au, ou accédés par le microcontrôleur doivent être gérés par la zone sécurisée ou par la zone non sécurisée en utilisant un pare-feu matériel pour déterminer si l’information ou la commande d’une application est autorisé à accéder à la zone sécurisée ou non.
Selon une autre particularité, les zones sécurisées et non sécurisées sont toutes deux incluses dans le processeur du microcontrôleur, les procédés de traitement et d'échange de données exécutés par le microcontrôleur s’effectuant d'une zone à l'autre en fonction de la nature des informations à traiter.
Selon une autre particularité, le pare-feu matériel comporte des registres qui sont affectés chacun à un périphérique et qui utilisent les informations mémorisées dans l'arborescence des périphériques Linux, décrit dans le système d'exploitation Linux, dans lequel ladite arborescence des périphériques est ajoutée avec des attributs de sécurité, définissant le statut sécurisé (S) ou non sécurisé (N) de périphérique à mémoriser dans chaque registre associé à un périphérique un statut sécurisé ou non sécurisé pour induire le traitement de l’information ou de la commande à partir d’un périphérique dans la zone sécurisée du processeur si le périphérique est défini comme sécurisé, et induire le traitement de l’information ou de la commande à partir d’un périphérique dans la zone non sécurisée du processeur si le périphérique est défini comme non sécurisé.
Selon une autre particularité, l'arborescence des périphériques Linux est authentifiée par une application primaire sécurisée durant l’opération de démarrage sécurisé.
Selon une autre particularité, la zone sécurisée comprend un cœur recevant au moins une instruction de la zone non sécurisée ou d'un périphérique inclus dans l'arborescence des périphériques, et exécutant différentes opérations qui dépendent de l’instruction reçue, un registre comprenant un ensemble de services sécurisés comportant les règles pour la protection de différents types des processus correspondant à différents types de services.
Selon une autre particularité, la zone non sécurisée comprend le noyau du système d'exploitation, un environnement d'exécution des programmes et applications et/ou des procédés de traitement des données, au moins une bibliothèque, et au moins une plateforme dédiée à l'ajout d'applications clientes ou d’applications propriétaires, le procédé d’ajout et l'accès desdites applications aux fonctionnalités du dispositif contrôlé par le microcontrôleur étant définis par des règles de sécurité mises en œuvre par le pare-feu matériel.
Selon une autre particularité, l'environnement d'exécution est configuré pour intégrer au moins un moyen pour interpréter différents types d'applications clientes, ledit moyen étant capable de traduire le langage desdites applications en programmes natifs afin de les traiter sur ledit environnement d'exécution.
Selon une autre particularité, l'environnement d'exécution est Android.
Selon une autre particularité, les périphériques accessibles sont au moins deux des périphériques suivants: circuit Bluetooth/Wifi, Ethernet, imprimantes, affichage, GPS, caméra, son, capteur de proximité, HDMI, USB, écran tactile, clavier, lecteur sans contact (NFC), lecteur de cartes magnétiques, lecteur de cartes à puce, matériel cryptographique, gestionnaire de clés informatiques.
On entend par lecteur sans contact tous lecteurs d’objet ne nécessitant pas de contact direct entre l’objet et le lecteur afin de communiquer au moins une information, par exemple une carte utilisant la technologie de radio-identification (RFID) ou communications en champ proche (NFC).
On entend par «matériel cryptographique» tout dispositif ou périphérique permettant de crypter ou chiffrer des informations ou données sensibles, par exemple et de manière non limitative un cryptoprocesseur.
Selon une autre particularité, les périphériques: affichage, écran tactile, clavier, lecteur sans contact, lecteur de cartes magnétiques, lecteur de carte à puce, matériel cryptographique et gestionnaire de clés informatiques sont des périphériques sécurisés, tandis que les périphériques: circuit Bluetooth/Wifi, Ethernet, imprimantes, GPS, caméra, son, capteur de proximité, HDMI et USB reçoivent soit un statut sécurisé (S) soit un statut non sécurisé (N).
Selon une autre particularité, le processus de démarrage sécurisé du système d’exploitation Linux pour un microcontrôleur avec dispositif d’autoprotection et zone de traitement de confiance comprend les étapes de: • commencer à exécuter le code contenu dans la mémoire ROM; • charger une partition initiale cryptée à partir d’une mémoire externe; • décrypter l’information de la partition initiale; • authentifier les clés publiques (Pk) et authentifier l’application primaire protégée (PPA) et un logiciel initial (ISW); • et charger et démarrer les autres programmes de démarrage de Linux.
Selon une autre particularité, le processus de démarrage sécurisé du système d’exploitation Linux comprend les étapes de: • charger le U-boot SPL (Secondary Program Loader); • authentifier l'arborescence des périphériques (DT); • démarrer le PA-loader (Primary Application loader); • décrypter le PA live (Primary Application live); • initialiser ramdisk; • charger le noyau Linux; • démarrer le noyau Linux; • démarrer dm-verity; • exécuter des applications Android sous SELinux.
Selon une autre particularité, au moins plusieurs registres de périphériques du microcontrôleur ont initialement un statut sécurisé (S) quand le code contenu dans la ROM commence à s’exécuter et avant l’activation du PA-loader.
Selon une autre particularité, après l’activation du PA-loader, les attributs de sécurité définis pour chaque périphérique dans l’arborescence de périphériques sont gérés par le PA-Loader et le statut sécurisé (S) d’au moins un registre du pare-feu associé à un périphérique, initialement défini dans un statut sécurisé (S) et jugé non critique en raison de la description dans l'arborescence des périphériques pour la sécurité et/ou l’intégrité d’un système ou d’un dispositif, est modifié en un statut non sécurisé (N) ou normal dans le registre du pare-feu.
Selon une autre particularité, les plateformes d’applications sont séparées de la bibliothèque, du noyau du système d’exploitation et de l’environnement d’exécution du système d’exploitation par un module de contrôle, contenu dans le système d’exploitation, qui contrôle les accès pour les applications et limite l’accès à un périphérique donné ou à un service pour les applications clientes non autorisées, le contrôle à l’accès dudit périphérique ou dudit service étant effectué au moyen d’un fichier fourni par SELinux, ledit fichier décrivant dans une liste blanche ou « whitelist » le type d’opérations permises en combinaison avec l’identité (ID) d’une application particulière ou d’un processus et établissant la permission d’opération pour chaque application.
Selon une autre particularité, l’accès d’une application cliente autorisée ou non autorisée à certaines fonctionnalités d’un périphérique tel que par exemple l’écran d’affichage tactile, est contrôlé par le microcontrôleur et se fait au moyen d'un proxy sécurisé actionné par le module de contrôle, ledit proxy sécurisé vérifiant si un message concernant un évènement tactile est signé par un tiers de confiance avant d’être affiché et sinon, l’évènement tactile n’est pas transféré dans la zone non sécurisée.
Selon une autre particularité, un microcontrôleur avec un dispositif d’autoprotection et zone de traitement de confiance et un démarrage sécurisé du système d’exploitation Linux est utilisé dans un terminal tout-en-un comprenant un écran LCD, un écran tactile capacitif, un lecteur de carte magnétique, un lecteur de cartes à puce, un lecteur de cartes sans contact, un circuit imprimé de sécurité en amont, un circuit imprimé de connexion et une caméra pour constituer un terminal inviolable dans lequel chaque opération sécurisée ou périphérique sécurisé est géré(e) par la zone de confiance du microcontrôleur et dans lequel la protection de l’accès à une cette zone de traitement de confiance est protégé contre l’accès d’une sonde au microcontrôleur par l'insertion du circuit imprimé principal comportant le microcontrôleur dans une cage de connexion permettant de détecter toute tentative d'ouverture de la cage ou de perçage à travers la cage.
Selon une autre particularité, le circuit imprimé de sécurité en amont comprend au moins un capteur de proximité pour détecter toute présence action et envoyer un signal au microcontrôleur pour effectuer une analyse et déclencher une action (affichage d’un message de bienvenue ou d’utilisation).
Selon une autre particularité, le circuit imprimé de connexion comprend au moins une interface USB, un port série UART, une interface Ethernet et une interface Bluetooth/Wifi pour la communication et l'échange de données.
DESCRIPTION DES FIGURES ILLUSTRATIVES D’autres particularités et avantages de la présente invention apparaîtront plus clairement à la lecture de la description ci-après, faite en référence aux dessins annexes, dans lesquels: - La Figure 1 représente un diagramme de la structure du microcontrôleur selon un mode de réalisation, - La Figure 2 représente un diagramme des composants du microcontrôleur sécurisés par le pare-feu dudit microcontrôleur, selon un mode de réalisation, - La Figure 3 représente un diagramme de la structure du processeur du microcontrôleur, selon un mode de réalisation, - La Figure 4 représente un diagramme de la structure d’un terminal comprenant le microcontrôleur, selon un mode de réalisation, - Les Figures 5A, 5B et 5C représentent les diagrammes, respectivement, du processus de démarrage du système et les étapes S1, S2a, S2b, S3a et S3b dudit processus de démarrage, selon un mode de réalisation.
DESCRIPTION DES MODES DE REALISATION PREFERES DE L'INVENTION
La présente invention concerne un microcontrôleur (1, Figure 1) pour la protection d’échange de données dans un terminal pour des applications avec un haut niveau de sécurité telles que par exemple les transactions financières.
Dans certains modes de réalisation, le microcontrôleur (1) comprend un processeur (11, Figures, 2 et 3) et une mémoire séparée en au moins deux zones qui sont sécurisées (110, Figures 2 et 3), non sécurisées (111, Figures 2 et 3), pour mettre en œuvre un démarrage sécurisé, comprenant un circuit de commande d'autoprotection (13) ou circuit d’autoprotection pour détecter les conditions de vulnérabilité et le processeur (11) exécutant un système d’exploitation Linux, ledit processeur comprenant un moniteur pour commuter les opérations soit dans une zone sécurisée (110) de la mémoire pour faire fonctionner au moins des processus d'authentification soit dans une zone non sécurisée (111) pour d'autres opérations et déterminer si les périphériques connectés ou accédant au, ou accédés par le microcontrôleur (1) doivent être gérés par la zone sécurisée (110) ou par la zone non sécurisée (111) en utilisant un pare-feu matériel (12, Figures 1 et 2) pour déterminer si l’information ou la commande d’une application est autorisé à accéder à la zone sécurisée (110) ou non. Le dispositif d’autoprotection (13) comprend par exemple des capteurs (130a, 130b, 130c, Figure 1) lui permettant de détecter si quelqu’un essaye d’avoir accès au microcontrôleur (1) ou au dispositif contrôlé par le microcontrôleur (1) dans le cas ou l’accès n’est pas autorisé. Par exemple et de manière non-limitative, les capteurs (130a, 130b, 130c) sont de nature à détecter des chocs (130a) et/ou des variations de tension (130b) et de température (130c), etc. Le dispositif d’autoprotection (13) comprend en outre au moins une alarme (132) se déclenchant en cas d’intrusion et au moins une horloge (131) afin de dater les événements, par exemple une tentative d’accès non-autorisée. En cas d’intrusion le dispositif d’autoprotection (13) envoie un ordre permettant d’effacer les données confidentielles contenues dans des mémoires sécurisées (14) ou cryptées (volatiles ou non volatiles) disposées dans le microcontrôleur (1) et reliées au dispositif d’autoprotection (13). Les données sont, par exemple et de manière non limitative, des codes authentification ou des clés de codage. Le microcontrôleur comprend également une mémoire ROM (10a) (« Read-Only Memory» ou mémoire morte), une mémoire de démarrage BOOT-RAM (10b), une mémoire statique SRAM (10c) (« Static Random Access Memory » ou mémoire vive statique) et un débogueur. Le processeur (11, Figures 1, 2 et 3) permet de virtualiser la zone sécurisée (110) et la zone non sécurisée (111) au moyen de la couche (112) de commutation de processeur. Par exemple et de manière non limitative, le processeur (11) est un ARM Cortex-A9. Les périphériques (16a,16b, 16c, 16d, 16e, 16f) gérés respectivement par la zone sécurisée (110) et la zone non sécurisée (111), du microcontrôleur (1), se voient assigner par le pare-feu matériel (12), respectivement, la lettre «S» (pour sécurisé) et la lettre «N» (pour non sécurisé ou normal), ladite information de sécurité est sauvegardée dans les registres du pare-feu matériel (12) comme représenté sur la figure 2. Le dispositif d’autoprotection (13), également relié au pare-feu matériel (12), se voit attribué un statut sécurisé permanent, afin d’éviter toute intrusion en particulier une tentative de récupération de données dans le cas où le dispositif d’autoprotection (13) serait défaillant.
Dans certains modes de réalisation, la mémoire est divisée en trois zones, une sécurisée, une non sécurisée et une partagée. La zone partagée est destinée à recevoir des périphériques nécessitant l’utilisation de ressources, par exemple des informations ou des applications, sécurisées et de ressources non sécurisées. Une telle architecture permet d’éviter l’introduction de point faible pour les périphériques nécessitant uniquement des ressources sécurisées.
Dans certains modes de réalisation, les zones sécurisées (110) et non sécurisées (ou zone normale) sont toutes deux incluses dans le processeur (11) du microcontrôleur (1), par exemple comme représenté sur les figures 2 et 3. Les procédés de traitement et d'échange de données exécutés par le microcontrôleur (1) s’effectuent d'une zone à l'autre en fonction de la nature des informations à traiter. Par exemple, si l’information porte sur des données sensibles telles que des codes d’authentification, elle est d’abord transmise à la zone sécurisée (110) pour vérification (authentification). Lorsque l’authentification est terminée, le résultat du traitement est transmis à la zone non sécurisée(111 ) pour permettre ou non la poursuite du traitement. La configuration du processeur (11) et de la mémoire dans une zone sécurisée (110) et une zone non sécurisée (111) et la présence du pare-feu matériel (12) contrôlant l’accessibilité des périphériques (16a,16b, 16c, 16d, 16e, 16f) gérés par le microcontrôleur (1) offre une couche de protection supplémentaire. Cette couche de protection pourrait être combinée, en plus, avec le circuit d’autoprotection (13) qui empêche principalement un accès non autorisé en provenance de l’extérieur. Le microcontrôleur (1) sécurisé empêche un accès non autorisé en provenance de l’intérieur et est donc complémentaire de la prévention d’un accès non autorisé en provenance de l’extérieur pour un terminal sécurisé et inviolable.
Dans certains modes de réalisation, le pare-feu matériel (12) comporte des registres qui sont affectés chacun à un périphérique (16a, 16b, 16c, 16d, 16e, 16f) et qui utilisent les informations mémorisées dans l'arborescence des périphériques Linux, décrit dans le système d'exploitation Linux, dans lequel ladite arborescence des périphériques est ajoutée avec des attributs de sécurité définissant le statut sécurisé (S) ou non sécurisé (N) de périphérique à mémoriser dans chaque registre associé à un périphérique un statut sécurisé ou non sécurisé pour induire le traitement de l’information ou de la commande à partir d’un périphérique dans la zone sécurisée du processeur si le périphérique est défini comme sécurisé, et induire le traitement de l’information ou de la commande à partir d’un périphérique dans la zone non sécurisée du processeur si le périphérique est défini comme non sécurisé. La disposition des différentes interfaces associées aux différents périphériques dans les deux zones est configurée par le pare-feu matériel (12).Par exemple, si le processeur essaye d’accéder à une interface donnée, il doit le faire dans le bon mode d’opération c'est-à-dire selon le statut sécurisé ou non sécurisé établi par le pare-feu matériel (12) afin d’avoir accès à ladite interface.
Dans certains modes de réalisation, l'arborescence des périphériques Linux est authentifiée par une application primaire sécurisée durant l’opération de démarrage sécurisé.
Dans certains modes de réalisation, la zone sécurisée (110) comprend un cœur (110b) recevant au moins une instruction de la zone non sécurisée (111) ou d'un périphérique (16a, 16b, 16c, 16d, 16e, 16f) inclus dans l'arborescence des périphériques, et exécutant différentes opérations qui dépendent de l’instruction reçue, un registre (110a) comprenant un ensemble de services sécurisés comportant les règles pour la protection de différents types des processus correspondant à différents types de services
Dans certains modes de réalisation, la zone non sécurisée (111) comprend le noyau du système d'exploitation (111a), un environnement d'exécution (111b) des programmes et applications et/ou des procédés de traitement des données, au moins une bibliothèque, et au moins une plateforme (111c, 111 d) dédiée à l'ajout d'applications clientes (111 d) ou d’applications propriétaires (111c), le procédé d’ajout et l'accès desdites applications aux fonctionnalités du dispositif contrôlé par le microcontrôleur (1) étant définis par des règles de sécurité mises en œuvre par le pare-feu matériel (12).
Dans certains modes de réalisation, l'environnement d'exécution (111b) est configuré pour intégrer au moins un moyen pour interpréter différents types d'applications clientes, ledit moyen étant capable de traduire le langage desdites applications en programmes natifs afin de les traiter sur ledit environnement d'exécution (111b). Cette configuration permet ainsi d’éviter d’avoir à changer d’environnement d’exécution dès lors que l’on change le langage de programmation des applications clientes.
Dans certains modes de réalisation, l'environnement d'exécution est Android.
Dans certains modes de réalisation, les périphériques accessibles sont au moins deux des périphériques suivants: circuit Bluetooth (16c)/Wifi (16b), Ethernet (16j), imprimantes, affichage, GPS, caméra (161), son, capteur de proximité (16k), HDMI, USB (16a), écran tactile (16f), clavier, lecteur sans contact (16e), un lecteur de cartes magnétiques (16h), lecteur de cartes à puce (16g), matériel cryptographique, gestionnaire de clés informatiques.
Dans certains modes de réalisation, les périphériques affichage, écran tactile (16f), clavier, lecteur sans contact (16e), un lecteur de cartes magnétique (16h), lecteur de carte à puce (16g), matériel cryptographique et gestionnaire de clés informatiques sont des périphériques sécurisés, tandis que les périphériques circuit Bluetooth (16c)/Wifi (16b), Ethernet (16j), imprimantes, GPS, caméra (161), son, capteur de proximité (16k), HDMI et USB (16a) reçoivent soit un statut sécurisé (S) soit un statut non sécurisé (N).
Dans certains modes de réalisation, le processus de démarrage sécurisé du système d’exploitation Linux (voir les Figures 5A, 5B et 5C) pour un microcontrôleur (1) avec dispositif d’autoprotection (13) et zone de traitement de confiance (110) comprend les étapes de: • commencer à exécuter le code contenu dans la mémoire ROM (10a); • charger une partition initiale cryptée à partir d’une mémoire externe; • décrypter l’information de la partition initiale; • authentifier les clés publiques (Pk) et authentifier l’application primaire protégée (PPA) et un logiciel initial (ISW); • et charger et démarrer les autres programmes de démarrage de Linux.
Le ROM comprend les clés publiques pour l’authentification l’information de la partition initiale chargée à partir de la mémoire externe et/ou optionnellement le décryptage. Le ROM, ensuite, télécharge l’information décryptée de la partition initiale, l’application primaire protégée (PPA) et le logiciel initial (ISW), qui comprend un logiciel initial sécurisé (ISSW) et un logiciel initial normal ou non sécurisé (ISNW), dans la mémoire de démarrage ou BOOT-RAM (10b), uniquement accessible en mode sécurisé (S).
Dans un autre mode de réalisation, le processus de démarrage sécurisé du système d’exploitation Linux comprend les étapes de: • charger le U-boot SPL ( Secondary Program Loader); • authentifier l'arborescence des périphériques (DT); • démarrer le PA-loader (Primary Application loader); • décrypter le PA live (Primary Application live) qui est l’application spécifique sécurisée du client qui contient les fonctions spécifiques pour un client ou un schéma de paiement; • initialiser ramdisk; • charger le noyau Linux; • démarrer le noyau Linux; • démarrer dm-verity; • exécuter des applications Android sous SELinux L’image du U-boot SPL est chargée dans la zone non sécurisée ou zone normale (voir Figures 5A, 5B) du processeur (11). Après le démarrage des programmes, la liste des périphériques compris dans l’arborescence de périphériques du système d’exploitation est envoyée pour authentification dans la zone sécurisée (110). Après authentification de la liste, l’étape suivante est enclenchée. Si, au cours des différentes étapes, un processus d’authentification est requis, l’instruction est transférée, à nouveau, dans la zone sécurisée pour vérification. Le processus se déroule, ainsi, jusqu’au démarrage du système d’exploitation (110a) et à l’exécution des applications. SELinux (Security-Enhanced Linux) est utilisé pour définir en outre les limites de l’environnement sécurisé ou « sandbox » de l’application Android. SELinux améliore la sécurité d’Android en confinant les processus privilégiés et en automatisant la création de la politique de sécurité. Tout ce qui n’est pas explicitement autorisé est refusé. SELinux peut fonctionner dans l’un des deux modes globaux: le mode permissif, dans lequel les refus d’autorisation sont consignés mais pas appliqués, et le mode renforcé, dans lequel les refus d’autorisation sont à la fois consignés et appliqués. SELinux est configuré dans le mode renforcé. SELinux supporte également un mode permissif par domaine dans lequel des domaines spécifiques (processus) peuvent être permissifs tout en plaçant le reste du système dans un mode renforcé global. Un domaine est tout simplement une étiquette identifiant un processus ou un ensemble de processus dans la politique de sécurité, où tous les processus marqués avec le même domaine sont traités de manière identique par la politique de sécurité. Une liste de domaines permissifs est stockée dans la mémoire du microcontrôleur (1) et vérifiée avant d’exécuter une commande fournie par une application Android.
Par conséquent les plateformes d’applications sont séparées de la bibliothèque, le noyau et l’environnement d’exécution du système d’exploitation par un module de contrôle, contenue dans le système d’exploitation, qui contrôle l’accès des applications et limite l’accès à un périphérique donné ou un service à une application cliente non autorisée, le contrôle et l’accès audit périphérique ou audit service s’effectuant au moyen d’un fichier fourni par SELinux, ledit fichier décrivant dans une « whitelist » le type des opérations qui sont autorisées par une application particulière ou un processus particulier et établissant la permission d’opération pour chaque application.
Dans certains modes de réalisation, au moins plusieurs registres de périphériques du microcontrôleur (1) ont initialement un statut sécurisé (S) quand le code contenu dans la ROM (10a) commence à s’exécuter et avant l’activation du PA-loader. Le démarrage du système se fait toujours dans la zone sécurisée (111a), presque tous les périphériques se voient alors assigner, initialement par défaut, le statut sécurisé (S) et sont interdits d’accès jusqu’à ce que l’étape d’authentification des périphériques compris dans l’arborescence des périphériques soit exécutée.
Dans certains modes de réalisation, après l’activation du PA-loader, les attributs de sécurité définis pour chaque périphérique dans l’arborescence de périphériques sont gérés par le PA-Loader et le statut sécurisé (S) d’au moins un registre du pare-feu (12) associé à un périphérique, initialement défini dans un statut sécurisé (S) et jugé non critique en raison de la description dans l'arborescence des périphériques pour la sécurité et/ou l’intégrité d’un système ou d’un dispositif, est modifié en un statut non sécurisé (N) ou normal dans le registre du pare-feu. Après l’authentification de l’arborescence des périphériques, le PA-loader en effectue la lecture et change le statut des périphériques contenus dans l’arborescence suivant des règles établies par le pare-feu matériel (12). Par exemple, les registres du pare-feu associés à la caméra (161) et à l’USB (16a) peuvent passer d’un statut sécurisé (S) à un statut non sécurisé (N), tandis que les registres du pare-feu associés à l’écran tactile (16f) ou le lecteur de carte magnétique (16h), qui manipulent des données sensibles, sont maintenus dans le statut sécurisé (S).
Dans certains modes de réalisation, les plateformes d’applications (111c, 111 d) sont séparées de la bibliothèque, du noyau (111a) du système d’exploitation et de l’environnement d’exécution (111b) du système d’exploitation par un module de contrôle, contenu dans le système d’exploitation, qui contrôle les accès pour les applications et limite l’accès à un périphérique donné ou à un service pour les applications clientes non autorisées, le contrôle à l’accès dudit périphérique ou dudit service étant effectué au moyen d’un fichier fourni par SELinux, ledit fichier décrivant dans une liste blanche ou « whitelist » le type d’opérations permises en combinaison avec l’identité (ID) d’une application particulière ou d’un processus et établissant la permission d’opération pour chaque application.
Dans certains modes de réalisation, l’accès d’une application cliente autorisée ou non autorisée à certaines fonctionnalités d’un périphérique tel que par exemple l’écran d’affichage tactile, est contrôlé par le microcontrôleur (1) et se fait au moyen d'un proxy sécurisé actionné par le module de contrôle, ledit proxy sécurisé vérifiant si un message concernant un évènement tactile est signé par un tiers de confiance avant d’être affiché et sinon, l’évènement tactile n’est pas transféré dans la zone non sécurisée. Par exemple et de manière non limitative, si une application cliente utilisant un API (interface de programmation d’application) standard d’Android, essaye d’avoir accès à l’écran d’affichage (16f) d’un dispositif contrôlé par le microcontrôleur (1), le module de contrôle actionne le proxy sécurisé qui vérifie s’il y a une correspondance entre ΓΑΡΙ de l’application et ΓΑΡΙ natif du système. S’il n’y a pas de correspondance, l’application n’est pas autorisée. Dans le cas où l’application est autorisée, l’écran n’affiche dans un premier temps que des données d’entrée fournies par l’application, lesdites données ne pouvant pas déclencher l’exécution d’une tâche. Les données sont, par la suite, transmises dans la zone sécurisée par le proxy sécurisé, pour vérification. Si les données sont authentifiées, celles-ci sont signées et retransmises, via le proxy sécurisé, à l’écran de manière à pouvoir déclencher dans le processeur de l’écran d’affichage, l’exécution d’une tâche.
Dans certains modes de réalisation, un microcontrôleur (1) avec un dispositif d’autoprotection (13) et zone de traitement de confiance (110) et un démarrage sécurisé du système d’exploitation Linux est utilisé dans un terminal (2) tout-en-un comprenant un écran LCD (16f), un écran tactile capacitif (16f), un lecteur de carte magnétique (16h), un lecteur de carte à puce (16g), un lecteur de carte sans contact (16e), un circuit imprimé de sécurité en amont (21), un circuit imprimé de connexion (22) et une caméra (161) pour constituer un terminal (2) inviolable dans lequel chaque opération sécurisée ou périphérique sécurisé est géré(e) par la zone de confiance (110) du microcontrôleur (1) et dans lequel la protection de l’accès à une cette zone de traitement de confiance (110) est protégé contre l’accès d’une sonde au microcontrôleur (1) par l'insertion du circuit imprimé principal (20) comportant le microcontrôleur (1) dans une cage de connexion permettant de détecter toute tentative d'ouverture de la cage ou de perçage à travers la cage.
Dans certains modes de réalisation, le circuit imprimé de sécurité en amont (21) comprend au moins un capteur de proximité (16k) pour détecter toute présence ou action et envoyer un signal au microcontrôleur (1) pour effectuer une analyse et déclencher une action (affichage d’un message de bienvenue ou d’utilisation).
Dans certains modes de réalisation, le circuit imprimé de connexion (22) comprend au moins une interface USB (16a), un port série UART (16i), une interface Ethernet (16j) et une interface Bluetooth (16c)/Wifi (16b) pour la communication et l'échange de données.
La présente demande décrit diverses caractéristiques techniques et avantages en référence aux figures et/ou à divers modes de réalisation. L’homme de métier comprendra que les caractéristiques techniques d’un mode de réalisation donné peuvent en fait être combinées avec des caractéristiques d’un autre mode de réalisation à moins que l’inverse ne soit explicitement mentionné ou qu’il ne soit évident que ces caractéristiques sont incompatibles ou que la combinaison ne fournisse pas une solution à au moins un des problèmes techniques mentionnés dans la présente demande. De plus, les caractéristiques techniques décrites dans un mode de réalisation donné peuvent être isolées des autres caractéristiques de ce mode à moins que l’inverse ne soit explicitement mentionné.
Il doit être évident pour les personnes versées dans l'art que la présente invention permet des modes de réalisation sous de nombreuses autres formes spécifiques sans l'éloigner du domaine d'application de l'invention comme revendiqué. Par conséquent, les présents modes de réalisation doivent être considérés à titre d'illustration, mais peuvent être modifiés dans le domaine défini par la portée des revendications jointes, et l'invention ne doit pas être limitée aux détails donnés ci-dessus.

Claims (19)

  1. REVENDICATIONS
    1. Microcontrôleur (1) comprenant un processeur (11) et une mémoire séparée en au moins deux zones, qui sont sécurisées (110), non sécurisées (111) ou partagées, pour mettre en œuvre un démarrage sécurisé comprenant un circuit de commande d'autoprotection (13) pour détecter les conditions de vulnérabilité et le processeur (11) exécutant un système d’exploitation Linux (Linus OS), ledit processeur (11) comprenant un moniteur pour commuter les opérations soit dans une zone sécurisée (110) de la mémoire pour faire fonctionner au moins des processus d'authentification soit dans une zone non sécurisée (111) pour d'autres opérations et déterminer si les périphériques connectés ou accédant au, ou accédés par le microcontrôleur (1) doivent être gérés par la zone sécurisée (110) ou par la zone non sécurisée (111 ) en utilisant un pare-feu matériel (12) pour déterminer si l’information ou la commande d’une application est autorisée à accéder à la zone sécurisée (110) ou non.
  2. 2. Microcontrôleur selon la revendication 1, dans lequel les zones sécurisées (110) et non sécurisées (111) sont toutes deux incluses dans le processeur (11) du microcontrôleur (1), les procédés de traitement et d'échange de données exécutés par le microcontrôleur (1) s’effectuant d'une zone à l'autre en fonction de la nature des informations à traiter.
  3. 3. Microcontrôleur selon les revendications 1 et 2, dans lequel le pare-feu matériel (12) comporte des registres qui sont affectés chacun à un périphérique (16a, 16b, 16c, 16d, 16e, 16f) et qui utilisent les informations mémorisées dans l'arborescence des périphériques Linux, décrit dans le système d'exploitation Linux, dans lequel ladite arborescence des périphériques est ajoutée avec des attributs de sécurité, définissant le statut sécurisé (S) ou non sécurisé (N) de périphérique à mémoriser dans chaque registre associé à un périphérique un statut sécurisé ou non sécurisé pour induire le traitement de l’information ou de la commande à partir d’un périphérique dans la zone sécurisée du processeur si le périphérique est défini comme sécurisé, et induire le traitement de l’information ou de la commande à partir d’un périphérique dans la zone non sécurisée du processeur si le périphérique est défini comme non sécurisé.
  4. 4. Microcontrôleur (1) selon les revendications 1 à 3, dans lequel l'arborescence des périphériques Linux est authentifiée par une application primaire sécurisée durant l’opération de démarrage sécurisé.
  5. 5. Microcontrôleur (1) selon les revendications 1 à 4, dans lequel la zone sécurisée (110) comprend un cœur (110b) recevant au moins une instruction de la zone non sécurisée (111) ou d'un périphérique (16a,16b, 16c, 16d, 16e, 16f) inclus dans l'arborescence des périphériques, et exécutant différentes opérations qui dépendent de l’instruction reçue, un registre (110a) comprenant un ensemble de services sécurisés comportant les règles pour la protection de différents types des processus correspondant à différents types de services.
  6. 6. Microcontrôleur (1) selon les revendications 1 à 4, dans lequel la zone non sécurisée (111) comprend le noyau du système d'exploitation (111a), un environnement d'exécution (111b) des programmes et applications et/ou des procédés de traitement des données, au moins une bibliothèque, et au moins une plateforme (111c, 111 d) dédiée à l'ajout d'applications clientes (111 d) ou d’applications propriétaires (111c), le procédé d’ajout et l'accès desdites applications aux fonctionnalités du dispositif contrôlé par le microcontrôleur (1) étant définis par des règles de sécurité mises en œuvre par le pare-feu matériel (12).
  7. 7. Microcontrôleur selon la revendication précédente, dans lequel l'environnement d'exécution (111b) est configuré pour intégrer au moins un moyen pour interpréter différents types d'applications clientes, ledit moyen étant capable de traduire le langage desdites applications en programmes natifs afin de les traiter sur ledit environnement d'exécution (111b).
  8. 8. Microcontrôleur (1) selon les revendications 6 et 7, dans lequel l'environnement d'exécution est Android.
  9. 9. Microcontrôleur (1) selon la revendication 1 à 3, dans lequel les périphériques accessibles sont au moins deux des périphériques suivants: circuit Bluetooth (16c)/Wifi (16b), Ethernet (16j), imprimantes, affichage, GPS, caméra (161), son, capteur de proximité (16k), HDMI , USB (16a), écran tactile (16f), clavier, lecteur sans contact (16e), lecteur de cartes magnétiques (16h), lecteur de carte à puce (16g), matériel cryptographique, gestionnaire de clés informatique.
  10. 10. Microcontrôleur selon la revendication précédente, dans lequel les périphériques affichage, écran tactile (16f), clavier, lecteur sans contact (16e), lecteur de cartes magnétiques (16h), lecteur de carte à puce (16g), matériel cryptographique et gestionnaire de clés informatique sont des périphériques sécurisés, tandis que les périphériques circuit Bluetooth (16c)/Wifi (16b), Ethernet (16j), imprimantes, GPS, caméra (161), son, capteur de proximité (16k), HDMI et USB (16a) reçoivent soit un statut sécurisé (S) soit un statut non sécurisé (N).
  11. 11. Processus de démarrage sécurisé du système d’exploitation Linux pour un microcontrôleur (1) avec dispositif d’autoprotection (13) et zone de traitement de confiance (110) comprenant les étapes de: • commencer à exécuter le code contenu dans la mémoire ROM (10a); • charger une partition initiale cryptée à partir d’une mémoire externe; • décrypter l’information de la partition initiale; • authentifier les clés publiques (Pk) et authentifier l’application primaire protégée (PPA) et un logiciel initial (ISW); • et charger et démarrer les autres programmes de démarrage de Linux.
  12. 12. Processus de démarrage sécurisé du système d’exploitation Linux selon la revendication 11, comprenant les étapes de: • charger le U-boot SPL (Secondary Program Loader); • authentifier l'arborescence des périphériques (DT); • démarrer le PA-loader (Primary Application loader); • décrypter le PA live (Primary Application live); • initialiser ramdisk; • charger le noyau Linux; • démarrer le noyau Linux; • démarrer dm-verity; • exécuter des applications Android sous SELinux
  13. 13. Processus de démarrage sécurisé du système d’exploitation Linux pour un microcontrôleur (1) selon les revendications 11 ou 12, caractérisé en ce qu’au moins plusieurs registres de périphériques du microcontrôleur (1) ont initialement un statut sécurisé (S) quand le code contenu dans la ROM (10a) commence à s’exécuter et avant l’activation du PA-loader.
  14. 14. Processus de démarrage sécurisé du système d’exploitation Linux pour un microcontrôleur (1) selon la revendication 13, caractérisé en ce qu’après l’activation du PA-loader, les attributs de sécurité définis pour chaque périphérique dans l’arborescence de périphériques sont gérés par le PA-Loader et le statut sécurisé (S) d’au moins un registre du pare-feu (12) associé à un périphérique, initialement défini dans un statut sécurisé (S) et jugé non critique en raison de la description dans l'arborescence des périphériques pour la sécurité et/ou l’intégrité d’un système ou d’un dispositif, est modifié en un statut non sécurisé (N) ou normal dans le registre du pare-feu.
  15. 15. Processus de démarrage sécurisé du système d’exploitation Linux pour un microcontrôleur (1) selon les revendications 11 à 14, caractérisé en ce que les plateformes d’applications (111c, 111 d) sont séparées de la bibliothèque, du noyau (111a) du système d’exploitation et de l’environnement d’exécution (111b) du système d’exploitation par un module de contrôle, contenu dans le système d’exploitation, qui contrôle les accès pour les applications et limite l’accès à un périphérique donné ou à un service pour les applications clientes non autorisées, le contrôle à l’accès dudit périphérique ou dudit service étant effectué au moyen d’un fichier fourni par SELinux, ledit fichier décrivant dans une liste blanche ou « whitelist » le type d’opérations permises en combinaison avec l’identité (ID) d’une application particulière ou d’un processus et établissant la permission d’opération pour chaque application.
  16. 16. Processus de démarrage sécurisé du système d’exploitation Linux pour un microcontrôleur (1) selon les revendications 11 à 15, caractérisé en ce que l’accès d’une application cliente autorisée ou non autorisée à certaines fonctionnalités d’un périphérique tel que par exemple l’écran d’affichage tactile, est contrôlé par le microcontrôleur (1) et se fait au moyen d'un proxy sécurisé actionné par le module de contrôle, ledit proxy sécurisé vérifiant si un message concernant un évènement tactile est signé par un tiers de confiance avant d’être affiché et si non, l’évènement tactile n’est pas transféré dans la zone non sécurisée.
  17. 17. Utilisation d’un microcontrôleur (1) avec un dispositif d’autoprotection (13) et zone de traitement de confiance (110) et démarrage sécurisé du système d’exploitation Linux dans un terminal (2) tout-en-un comprenant un écran LCD (16f), un écran tactile capacitif (16f), un lecteur de carte magnétique (16h), un lecteur de carte à puce (16g), un lecteur de carte sans contact (16e), un circuit imprimé de sécurité en amont (21), un circuit imprimé de connexion (22) et une caméra (161) pour constituer un terminal (2) inviolable dans lequel chaque opération sécurisée ou périphérique sécurisé est géré(e) par la zone de confiance (110) du microcontrôleur (1) et dans lequel la protection de l’accès à une cette zone de traitement de confiance (110) est protégé contre l’accès d’une sonde au microcontrôleur (1) par l'insertion du circuit imprimé principal (20) comportant le microcontrôleur (1) dans une cage de connexion permettant de détecter toute tentative d'ouverture de la cage ou de perçage à travers la cage.
  18. 18. Utilisation d’un microcontrôleur (1) selon la revendication précédente, caractérisé en ce que le circuit imprimé de sécurité en amont (21) comprend au moins un capteur de proximité (16k) pour détecter toute présence ou action et envoyer un signal au microcontrôleur (1) pour effectuer une analyse et déclencher une action: affichage d’un message de bienvenue ou d’utilisation.
  19. 19. Utilisation d’un microcontrôleur (1) selon la revendication 17, caractérisé en ce que le circuit imprimé de connexion (22) comprend au moins une interface USB (16a), un port série UART (16i), une interface Ethernet (16j) et une interface Bluetooth (16c)/Wifi (16b) pour la communication et l'échange de données.
BE2016/5612A 2016-05-10 2016-07-25 Microcontroleur pour demarrage securise avec pare-feu BE1024111B1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
ES17170242T ES2927289T3 (es) 2016-05-10 2017-05-09 Terminal estanco para tarjetas inteligentes
EP17170239.2A EP3244376A1 (fr) 2016-05-10 2017-05-09 Terminal de paiement multi-supports
EP17170242.6A EP3244377B1 (fr) 2016-05-10 2017-05-09 Terminal etanche pour cartes a puce
EP17170202.0A EP3244375B1 (fr) 2016-05-10 2017-05-09 Microcontrôleur pour démarrage sécurisé avec pare-feu

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
BE2016/5331A BE1023424B1 (fr) 2016-05-10 2016-05-10 Terminal etanche pour cartes a puce
BE2016/5331 2016-05-10
BE2016/5582A BE1023815B1 (fr) 2016-05-10 2016-07-12 Terminal de paiement multi-supports

Publications (2)

Publication Number Publication Date
BE1024111A1 true BE1024111A1 (fr) 2017-11-16
BE1024111B1 BE1024111B1 (fr) 2017-11-17

Family

ID=55963101

Family Applications (3)

Application Number Title Priority Date Filing Date
BE2016/5331A BE1023424B1 (fr) 2016-05-10 2016-05-10 Terminal etanche pour cartes a puce
BE2016/5582A BE1023815B1 (fr) 2016-05-10 2016-07-12 Terminal de paiement multi-supports
BE2016/5612A BE1024111B1 (fr) 2016-05-10 2016-07-25 Microcontroleur pour demarrage securise avec pare-feu

Family Applications Before (2)

Application Number Title Priority Date Filing Date
BE2016/5331A BE1023424B1 (fr) 2016-05-10 2016-05-10 Terminal etanche pour cartes a puce
BE2016/5582A BE1023815B1 (fr) 2016-05-10 2016-07-12 Terminal de paiement multi-supports

Country Status (1)

Country Link
BE (3) BE1023424B1 (fr)

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060112421A1 (en) * 2004-11-23 2006-05-25 Beierwalters William T Smart card systems and methods for building automation
EP2393070A1 (fr) * 2010-06-02 2011-12-07 3M Innovative Properties Company Système de sécurité pour unité de réception de données
JP5915886B2 (ja) * 2012-01-30 2016-05-11 カシオ計算機株式会社 携帯情報端末
US9058172B2 (en) * 2012-07-02 2015-06-16 Square, Inc. Method for conserving power using a wireless card reader
US9767422B2 (en) * 2013-03-12 2017-09-19 Diebold Self-Service Systems, Division Of Diebold, Incorporated Detecting unauthorized card skimmers
JP6274970B2 (ja) * 2014-05-26 2018-02-07 日本電産サンキョー株式会社 プリント基板およびカードリーダ

Also Published As

Publication number Publication date
BE1024111B1 (fr) 2017-11-17
BE1023815B1 (fr) 2017-07-28
BE1023424B1 (fr) 2017-03-15

Similar Documents

Publication Publication Date Title
US11947688B2 (en) Secure computing system
US10162975B2 (en) Secure computing system
US8782404B2 (en) System and method of providing trusted, secure, and verifiable operating environment
Altuwaijri et al. Android data storage security: A review
Parno Bootstrapping Trust in a" Trusted" Platform.
US8335931B2 (en) Interconnectable personal computer architectures that provide secure, portable, and persistent computing environments
US10788984B2 (en) Method, device, and system for displaying user interface
US8522018B2 (en) Method and system for implementing a mobile trusted platform module
CN107533609A (zh) 用于对系统中的多个可信执行环境进行控制的系统、设备和方法
WO2010010258A2 (fr) Systeme et procede pour la securisation d'une interface utilisateur
CN109657448A (zh) 一种获取Root权限的方法、装置、电子设备及存储介质
US7805601B2 (en) Computerized apparatus and method for version control and management
EP3244375B1 (fr) Microcontrôleur pour démarrage sécurisé avec pare-feu
Türpe et al. Attacking the BitLocker boot process
US10951414B2 (en) Method for securing digital currency
BE1024111B1 (fr) Microcontroleur pour demarrage securise avec pare-feu
Sancho et al. Cashing in on ATM Malware. A Comprehensive Look at Various Attack Types
WO2007060322A2 (fr) Procede et dispositif d'authentification par un utilisateur d'une interface de confiance et programme d'ordinateur associe
US11100215B2 (en) Management of a display of a view of an application on a screen of an electronic data entry device, corresponding method, device and computer program product
CN111708293A (zh) 带主动防御功能的在线调试的mcu设计方法
Altuwaijri et al. Computer and Information Sciences
Perrotis Development of cryptographic algorithms in the trusted execution environment
Angelakis Application development in the trusted execution environment
CN111783074A (zh) 移动存储器的访问控制方法、装置、电子设备和存储介质
PCI PIN Transaction Security (PTS) Point of Interaction (POI)

Legal Events

Date Code Title Description
FG Patent granted

Effective date: 20171117

HC Change of name of the owners

Owner name: WORLDLINE SA/NV; BE

Free format text: DETAILS ASSIGNMENT: CHANGE OF OWNER(S), CHANGEMENT DE NOM DU PROPRIETAIRE, CORRECTION; FORMER OWNER NAME: ATOS WORLDLINE S.A.

Effective date: 20190418

PD Change of ownership

Owner name: INGENICO BELGIUM; BE

Free format text: DETAILS ASSIGNMENT: CHANGE OF OWNER(S), ASSIGNMENT; FORMER OWNER NAME: WORLDLINE SA/NV

Effective date: 20220628