Les TPM sont à la base de la sécurité dans son ensemble. Pas de TPM = pas de sécurité

éléchargez le livre blanc. Vous pouvez télécharger le livre blanc au format PDF.

 

Introduction

Tout le monde est d’accord pour dire que les GAB doivent être sécurisés au maximum sans nuire à leur opérabilité. Cependant, les avis divergent sur la manière d'y parvenir. Bien sûr, une partie de cette confusion découle de la concurrence entre les fournisseurs et différents produits de sécurité se disputant l'attention des clients. Cependant, il y a aussi une bonne part de désinformation qui déroute les clients et conduit finalement à des implémentations médiocres, vulnérables aux attaques.

Ce livre blanc rassemblera les fondamentaux de la sécurité des systèmes, en partant de la façon dont les systèmes informatiques individuels doivent être protégés, et en abordant ensuite le cas d'utilisation spécifique des réseaux GAB qui, bien sûr, nécessitent le plus haut niveau de protection. Les réseaux GAB sont non seulement responsables de millions de dollars en espèces, mais constituent également un point d’entrée potentiel vers les systèmes informatiques hôtes d’une banque qui peuvent transférer de grandes sommes d’argent dans le monde entier. Un GAB compromis pourrait s’avérer plus coûteux pour une banque que l’argent liquide dans son coffre-fort.

Tout d'abord, examinons quelques fausses idées courantes sur la sécurité. La plus grande idée fausse en matière de sécurité des systèmes est peut-être une incompréhension du concept de sécurité en couches. Il est vrai qu'il n'existe pas de solution miracle pour sécuriser un système complexe - plusieurs verrous coordonnés sont nécessaires. Cependant, ce concept est souvent mal interprété comme signifiant que plus la sécurité est obscure et complexe, plus le système est sécurisé.  Ce n'est tout simplement pas le cas. Il existe des techniques cryptographiques fondamentales qui peuvent être simples, discutées ouvertement et bien comprises et qui doivent constituer le cœur de toute architecture de sécurité. Ces techniques offrent non seulement une sécurité quantifiable, mais elles sont également faciles à utiliser et les utilisateurs ne doivent pas faire d’efforts exagérés pour les faire fonctionner.

Illustrons cela par un exemple rapide. Nous sommes tous habitués aux ordinateurs qui nécessitent un nom d'utilisateur et un mot de passe de connexion. Du fait que le système de sécurité basé sur mot de passe a fait l’objet d’attaques par des pirates informatiques, les entreprises ont créé des règles de mot de passe de plus en plus complexes qui sont très peu conviviales pour les utilisateurs légitimes - des changements de mot de passe réguliers, la non-utilisation des x derniers mots de passe, des compositions de mots de passe compliquées et difficiles à retenir, etc. Puis Microsoft a mis fin à cela grâce à « Windows Hello ».

Windows Hello associe la reconnaissance des périphériques matériels sécurisés par TPM à sécurité cryptographique à la reconnaissance faciale biométrique. C'est, en fait, très similaire à un concept de sécurité que l'industrie des GAB connaît bien - puce et code PIN. Avec Windows Hello, la puce est le TPM qui est un processeur cryptographique semblable à la puce d'une carte de paiement, et les informations biométriques remplacent le code PIN. Ce système est non seulement plus sûr que n'importe quel système de nom d'utilisateur + mot de passe, mais il est également extrêmement facile à utiliser. Je peux me connecter à ma tablette Surface d’un simple regard, mais je peux également le faire en un instant - plus rapidement qu’il ne faut de temps pour saisir une lettre de mon mot de passe. Un système peut-il être à la fois plus sûr et plus facile à utiliser ? Absolument. Nous devons oublier l'idée que l’on n’a rien sans mal - la vraie sécurité n'exige pas de torture pour l'utilisateur.

Vous avez sans doute remarqué que nous avons introduit le concept de TPM dans le paragraphe précédent. Cet article est construit autour des TPM en tant que « racine de confiance » en informatique. Le TPM est une puce semi-conductrice sécurisée constituée d'une architecture de sécurité conçue par le Trusted Computing Group (TCG) de plus de 100 entreprises, incluant de grandes entreprises telles qu'Intel, Microsoft, HP et IBM. Leur travail a commencé dès 1999 dans le but de créer un noyau sécurisé pour les appareils informatiques afin que toute la sécurité informatique puisse être construite à partir de ce noyau sécurisé. La bonne nouvelle est que les TPM sont complètement standards dans tous les nouveaux PC et ce, depuis de nombreuses années. La mauvaise nouvelle est que de nombreuses organisations ne savent même pas qu'elles possèdent ce joyau de sécurité à l'intérieur de leurs appareils informatiques, et elles n'en profitent pas. Ce document constitue une tentative pour changer cette situation - en particulier pour notre secteur des GAB. Après tout, nous avons davantage besoin d'une informatique sécurisée que la plupart des secteurs.

TPM - la « racine de confiance »

Que signifie la « racine de confiance » et pourquoi le TPM est-il essentiel à la sécurité informatique ? Pour comprendre cela, il est important de souligner que l’ensemble de la sécurité informatique repose sur l'utilisation intelligente du cryptage. Le cryptage est une méthode de calcul qui convertit les données d'une forme « claire » en une forme apparemment aléatoire et inversement.

Lorsque les données ou informations se présentent sous une forme claire, elles peuvent être utilisées à des fins prévues. Lorsque les données sont cryptées, elles sont inutilisables tant qu'elles ne sont pas décryptées. Ce qu’il convient de noter à propos du cryptage et du décryptage est qu'une « clé » sécurisée est nécessaire pour crypter ou décrypter les données. Sans la clé, les données chiffrées sont inutiles. En effet, le mot « clé » dans ce sens n'est pas différent de la clé d'un coffre-fort. Si vous perdez la clé d'un coffre-fort, vous ne pouvez pas accéder à l'or à l'intérieur de ce coffre-fort. Dans le cas de l'informatique, l'or est la donnée qui est protégée par le processus de cryptage.

Maintenant, il faut comprendre que la clé elle-même doit être sous une forme claire pour pouvoir être utilisée afin de décrypter un message. Cela signifie que vous devez disposer d'un moyen de stocker la clé en toute sécurité. Oui, vous pouvez crypter cette clé avec une autre clé. Cela rendrait la clé d'origine sûre - mais vous avez alors un problème pour savoir où stocker la deuxième clé. En effet, vous pouvez disposer d’une chaîne de clés (et bien souvent, une telle chaîne existe). Cependant, la clé initiale doit être stockée dans un endroit sûr sous une forme claire. Où pouvez-vous stocker cette clé principale en clair dans un ordinateur ? La réponse n'est pas sur le disque dur (ou SSD). Il est impossible de stocker une clé en clair sur le lecteur en toute sécurité - un pirate informatique qui peut accéder physiquement au lecteur peut toujours trouver la clé en clair. Du logiciel seul ne peut pas la protéger si un attaquant y a un accès physique.

C’est ici qu’intervient le TPM. Le TCG a conçu le TPM comme un coffre-fort matériel pour les secrets, et il est intégré à l’intérieur de la carte mère. Dans certaines architectures, le TPM peut être à l'intérieur de la puce du processeur elle-même. Il est conçu dans le but précis de stocker les clés en toute sécurité. C'est aussi bien plus qu'un simple moyen de stockage de clés - et nous y reviendrons dans la section suivante. Pour le moment, considérez qu'un système informatique peut avoir une chaîne de clés, mais que la clé au début de cette chaîne doit être en clair et doit être stockée de manière très sécurisée afin qu'elle ne puisse être utilisée que par des acteurs de confiance. Le TPM est ce moyen de stockage de clés.

CRTM – Mesurer la racine de confiance

J'ai promis que le TPM n'est pas simplement un magnifique moyen de stockage de clés. Pensez au tout premier problème rencontré par un stockage de clés sécurisé le premier jour de travail. Si quelqu'un dit au TPM : « Pourrais-je avoir cette clé en clair? » comment savez-vous qui demande la clé ? C’est très bien de stocker une clé en toute sécurité, mais à qui allez-vous la donner ? Est-ce un morceau de code légitime qui demande à utiliser la clé ou s'agit-il d'un logiciel malveillant ? Un pirate a-t-il modifié le logiciel du PC avec des logiciels malveillants, puis demandé très poliment : « S'il-vous-plaît, TPM, puis-je utiliser la clé? » Vous voyez le problème - il ne suffit pas d'être un moyen de stockage de clés super sécurisé. Vous devez authentifier le logiciel qui demande à utiliser ces clés. C’est là qu’intervient maintenant la deuxième astuce du TPM - la mesure de la racine de confiance (CRTM).

Le CRTM fonctionne avec une chaîne de confiance qui commence dès la mise sous tension. Le matériel et le TPM travaillent main dans la main pour « mesurer » la séquence de démarrage du PC depuis le démarrage initial, puis jusqu'au BIOS/UEFI, et enfin jusqu'au démarrage du système d'exploitation. Il « mesure » si un des logiciels sur le PC a été modifié ou falsifié pendant le processus de démarrage. Ce processus est mieux connu sous le nom de Démarrage sécurisé, qui est aujourd'hui une fonctionnalité standard des nouveaux PC qui utilisent un firmware UEFI pour démarrer.

Pour faciliter le démarrage sécurisé, les concepteurs du TPM ont introduit un concept appelé PCR (Platform Configuration Registers - Registres de configuration de plateforme). Les valeurs de PCR sont calculées par le TPM dans un processus appelé « extension du PCR » d'une manière quelque peu similaire à la création d'une blockchain, ce qui confère aux PCR une empreinte digitale unique (c'est-à-dire un ensemble de hachages) de la séquence de démarrage du PC . Si les PCR ne sont pas modifiés par rapport au passé, le logiciel de démarrage du PC reste alors inchangé - et cela est garanti par cryptographie. Il est impossible pour les logiciels malveillants d'avoir modifié ne serait-ce qu'un seul octet du logiciel de démarrage mesuré sans affecter les valeurs de PCR.

C'est un concept extrêmement important en cryptographie. Ce que l'on appelle la « fonction de hachage sécurisé » est une fonction de type cryptage qui convertit un bloc de données en une chaîne de caractères de longueur fixe qui agit comme une empreinte digitale des données d'origine. Si les données changent, l'empreinte digitale change. Il s'agit donc d'un moyen infaillible de détecter les modifications les plus mineures d'un grand nombre de logiciels. Le TPM utilise une variante de hachage appelée HMAC. Un HMAC est un hachage qui est un « hachage par clé », ce qui signifie que seule une personne disposant de la bonne clé sécurisée est capable de générer ou de vérifier le hachage HMAC. C'est une sorte de « hachage chiffré ».

Il y a une raison pour laquelle nous avons approfondi cette partie en détail. C'est ainsi que la technologie TPM garantit à 100 % la sécurité du logiciel de base du GAB. Il n'y a aucun moyen de modifier ne serait-ce qu'un seul bit de logiciel dans la séquence de démarrage d'un GAB protégé par un TPM sans briser la cryptographie moderne elle-même. C'est aussi le concept que nous exposons ensuite dans cet article de manière plus détaillée pour sécuriser l'ensemble du reste du GAB.

Nous avons maintenant un noyau logiciel sécurisé - qu'en est-il du logiciel applicatif ?

Sur un GAB équipé de Windows 10, deux technologies Microsoft importantes prennent le relais à ce stade. Bitlocker et Device Guard (désormais connu sous le nom de Windows Defender Aplication Control - WDAC). Bitlocker est la technologie de chiffrement de disque de Microsoft. Il est capable de crypter la totalité du disque dur ou du SSD, et surtout, il enregistre sa clé de cryptage « dans le TPM ». En fait, c'est un peu plus compliqué que de simplement enregistrer la clé dans le TPM - nous allons le préciser.

Gardez à l'esprit qu'il ne suffit pas de stocker les clés en toute sécurité : il est essentiel de déterminer « qui » demande la clé avant de la remettre. Le TPM a une autre nouvelle astuce que l’on appelle « sceller » la clé. Lorsque le disque dur d'un GAB est d'abord chiffré dans un environnement sûr, et qu'une nouvelle clé est générée par Windows, cette clé est ensuite chiffrée à l'aide d'une « clé de chiffrement de clé » distincte appelée KEK. La KEK elle-même est ensuite chiffrée dans un processus appelé « scellement » en utilisant les valeurs PCR et une clé privée du TPM. Lorsque le GAB démarre, la clé KEK n'est disponible que si toutes les empreintes digitales du logiciel de base mesurées par les PCR ont été validées - ce qui signifie que le BIOS et le code Windows n'ont pas été falsifiés, comme expliqué précédemment. En utilisant la KEK, Windows déchiffre sa clé de chiffrement de disque et l'utilise pour déchiffrer l'ensemble du disque dur. Une fois que la KEK a été récupérée, Windows ferme la porte KEK derrière elle. Il le fait en « étendant » le PCR 11 - ce qui signifie que le PCR 11 est modifié après que la KEK soit descellée, de sorte que personne d'autre ne puisse récupérer la KEK par la suite. La KEK est gardée en sécurité par le TPM jusqu'à la séquence de démarrage suivante et n'est rendue disponible que si les PCR confirment qu'aucun des logiciels de base n'a été falsifié, puis il verrouille à nouveau la porte dès que la KEK a été mise à disposition pour que Bitlocker décrypte le disque dur.

Comme vous pouvez le voir, nous avons construit le logiciel de base étape par étape, en le vérifiant à l'aide des PCR pour nous assurer qu'aucune falsification ne s'est produite, jusqu'à ce que nous terminions le processus de démarrage et lancions Windows. Nous devons maintenant démarrer le logiciel applicatif du GAB et vérifier qu’aucun exécutable que nous lançons n'a été falsifié avant de l’utiliser. En d'autres termes, nous étendons davantage les mêmes concepts de vérification de l'empreinte cryptographique de chaque composant logiciel avant de l'utiliser. Cette dernière partie de la chaîne de démarrage est exécutée par Windows WDAC (ou un logiciel tiers avec des fonctionnalités similaires). Ceci est souvent appelé liste blanche et entraîne la vérification du hachage (c'est-à-dire l'empreinte digitale calculée) de chaque exécutable avant qu'il ne soit autorisé à s'exécuter.

Liste blanche sur le GAB

La meilleure façon de mettre sur liste blanche un logiciel GAB à l'aide de Windows WDAC (ou d'un autre logiciel de liste blanche) est d'utiliser ce que l'on appelle une « règle de certificat ». Il faut que le logiciel que vous déployez sur le GAB ait été pré-signé par le développeur de ce logiciel. Ainsi, par exemple, les exécutables Windows 10 sont signés par Microsoft avec leur clé privée. Cela signifie que n'importe qui peut vérifier que les exécutables Windows n'ont pas été modifiés ou falsifiés en cours de transmission et sont dans le même état qu'ils étaient au moment où ils ont été signés par Microsoft, en les vérifiant simplement à l'aide de la clé publique de signature de code de Microsoft. Pour que WDAC le confirme, il suffit de créer une « règle de certificat » qui indique que les exécutables signés par Microsoft peuvent être utilisés en toute sécurité. 

De même, le logiciel de KAL est toujours signé par la clé privée de signature de code de KAL. Nos clients peuvent vérifier que le logiciel KAL n’a pas été falsifié en installant le certificat de signature de code de KAL sur chaque GAB.

Mais qu'en est-il des autres logiciels qui ne sont peut-être pas pré-signés de cette manière ? Trois options s'offrent à la banque :

1. Demander à votre fournisseur de signer son code.
2. Changer de fournisseur. (Y a-t-il vraiment des fournisseurs de GAB qui ne signent pas leur code en 2020? Apparemment, oui).
3. Utiliser une « règle de hachage ».

Une règle de hachage est une règle que vous ajoutez à votre stratégie de liste blanche pour WDAC au moyen de laquelle la banque calcule un hachage pour chacun des fichiers provenant d'un fournisseur qui n'a pas signé ses exécutables. En d'autres termes, vous effectuez la signature de leur code pour eux. De toute évidence, ce n'est pas aussi bien que d’avoir un code signé à l'origine, car toute falsification qui se produit durant la transmission entre le fournisseur et la banque ne peut pas être détectée (bien qu'il puisse y avoir d'autres mécanismes pour assurer une transmission sécurisée).

Un deuxième inconvénient d’une telle mise en œuvre est que la banque doit créer une « règle de hachage » pour chaque fichier exécutable. C'est beaucoup moins élégant que d'installer simplement le certificat public du fournisseur dans le GAB qui couvre ensuite tous les exécutables de ce fournisseur, y compris toutes les futures mises à jour de ce fournisseur.

Sommes-nous déjà arrivés ?

Une fois que nous sommes arrivés à ce point et que le GAB est opérationnel, tous les logiciels ont été vérifiés cryptographiquement. Aucun exécutable qui a été falsifié ou modifié de quelque manière que ce soit n'est autorisé à s'exécuter. Pas même un seul bit des gigaoctets d'exécutables logiciels sur un GAB moderne ne peut être piraté sans être détecté et bloqué.

Nous ne sommes cependant pas encore tout à fait arrivés au bout. Un GAB ainsi protégé est totalement imperméable en ce qui concerne la modification non autorisée de l’ensemble de ses logiciels. Mais ce n'est pas tout. L'injection de logiciels malveillants dans le GAB n'est pas la seule méthode d'attaque d'un GAB. Nous allons maintenant voir comment le TPM peut aider pour d'autres types d'attaques.

Comprendre ce que peuvent faire les TPM

Le TPM ne consiste pas seulement à sécuriser le processus de démarrage d'un GAB. C'est la racine fondamentale de la confiance qui permet également de sécuriser tout le reste. Découvrons un livre fabuleux écrit par des membres du Trusted Computing Group, Will Arthur, David Challener et Kenneth Goldman. Le livre, « Un guide pratique du TPM 2.0 », est exceptionnel et constitue un trésor d'idées qui m'a inspiré pour écrire ce livre blanc. Ce livre est téléchargeable gratuitement ici.

La meilleure façon de résumer rapidement ce livre dans cet article est de se concentrer sur les 53 cas d'utilisation répertoriés dans le livre. Avec la permission des auteurs, je reprends leurs cas d'utilisation ci-dessous :

Veuillez jeter un œil sur les cas d'utilisation ci-dessus. La première chose à réaliser est que les TPM ne visent pas seulement à sécuriser le processus de démarrage. Comme nous l'avons dit précédemment, le TPM est la racine fondamentale de la confiance qui permet de sécuriser chaque étape de ce que nous devons faire avec les GAB, étape par étape. Bien entendu, tous les cas d'utilisation ci-dessus ne s'appliquent pas nécessairement à notre industrie. Et rappelez-vous que ces cas d'utilisation concernent la sécurisation de cet élément de manière cryptographique.

Prenons donc un exemple - # 40 "Clés VPN". En utilisation normale, un VPN est mis en place entre un GAB et un serveur en installant des certificats numériques (c'est-à-dire des clés publiques) sur les deux systèmes. Mais que se passe-t-il si quelqu'un pirate les certificats ? Il est vrai que les certificats stockés dans un environnement Windows protégé par TPM avec le verrouillage décrit jusqu'à présent dans cet article ne seraient pas modifiables. Cependant, nous pouvons aller plus loin. Les clés VPN peuvent être scellées avec les PCR à l'aide du TPM. Cela signifie qu'au moment où le VPN est sur le point d'être configuré, les clés nécessaires pour configurer le VPN peuvent être rendues disponibles uniquement si les PCR sont dans le bon état. S’il y a une différence, la connexion VPN est rejetée. Considérez maintenant que ce concept peut s'appliquer aux deux côtés du tunnel VPN. Les PCR doivent être non seulement dans l'état correct du côté GAB, mais ils peuvent également être tenus d'être dans l'état correct pour le serveur de GAB dans le centre de données. Si cela est fait, nous aurions confirmé cryptographiquement que le GAB et le serveur de GAB sont dans un état sécurisé avant de se connecter. Nous saurions que tous les exécutables qui ont fonctionné à la fois sur le GAB et sur le serveur de GAB jusqu'à ce moment sont vierges et intacts, et nous permettons aux deux de se connecter si, et seulement si, ce scénario est satisfait par les deux systèmes.

Ce livre blanc n'est pas le lieu où je propose de discuter de toutes les idées de l'eBook. En effet, il existe des cas d'utilisation supplémentaires qui s'appliquent spécifiquement aux GAB qui doivent être discutés, conçus et mis en œuvre. J'espère que l’industrie du GAB le fera par l'intermédiaire d'un ou de plusieurs de ses comités. J’en dirai plus à ce sujet par la suite.

Sécurisation des connexions réseau

La section précédente a abordé la sécurité du réseau. Voyons maintenant cela un peu plus en détail car il s'agit d'un cas d'utilisation qui revêt une importance particulière pour les GAB. Il est clair que non seulement nous voulons que les GAB soient individuellement sécurisés, mais nous exigeons également que tout système de serveur backend que nous touchons soit également sécurisé et non compromis.  Veuillez considérer le diagramme ci-dessous :

 

 

Le diagramme montre le scénario de connexion dans une grande banque typique avec des services GAB sophistiqués. Les GAB se connectent à un gestionnaire de GAB qui orchestre les services de plusieurs serveurs backend. Un HSM (Hardware Security Module) fournit des services cryptographiques et aide au zonage des clés. Une fois qu'une transaction a été requise et doit être autorisée, elle est envoyée au système bancaire central s'il s'agit d'une transaction « On Us », ou aux réseaux internationaux de paiement par carte s'il s'agit d'une transaction « Off Us ».

Considérez maintenant une sécurité utopique où chaque GAB et chaque serveur a un TPM (ce qui est le cas pour tout le matériel récent), tous les systèmes ont été vérifiés dès le démarrage avec des mesures PCR, et toutes les connexions TLS et VPN ont été configurées à l'aide de certificats descellés par le TPM et sont donc garanties par cryptographie comme n'ayant pas été altérées. C’est bien une utopie en effet. Le triste état des lieux en août 2020 est que très peu de banques ont atteint ce niveau de sécurité.

Un défi potentiel de mise en œuvre ici est l'évolutivité et le clustering. Comment créer un cluster de serveurs si les connexions sont liées à des TPM individuels ? Voir le cas d'utilisation n°47 ci-dessus « Un ensemble de serveurs agit comme un seul ». Le TCG y a déjà pensé.

Sécurisation des connexions des périphériques matériels du GAB

Cet article s'est jusqu'à présent concentré sur le PC du GAB et sur la manière de garantir que le logiciel est exempt de logiciels malveillants après le démarrage et pendant son fonctionnement. Passons maintenant aux périphériques matériels individuels à l'intérieur du GAB - le lecteur de carte, le clavier crypté et, bien sûr, le distributeur de billets. Quelle est la situation en matière de sécurité pour ce qui est des connexions entre le PC et les dispositifs? Sur la plupart des GAB, ces connexions sont des connexions USB qui peuvent être physiquement manipulées. Si ces connexions ont des données en clair, le GAB est vulnérable aux attaques, même s'il est exempt de logiciels malveillants. Discutons-en à nouveau avec un diagramme : 

 

 

Comme vous pouvez le voir, j'ai dessiné les connexions USB sous forme de cloud pour indiquer le risque d'attaque. Le TPM sécurise le PC, mais les câbles USB risquent d'être attaqués s'ils ne sont pas protégés. On peut prétendre que la protection de ces connexions incombe au fournisseur de GAB. Cependant, la situation n'est pas aussi simple car elle dépend également des exigences d'interopérabilité entre les périphériques matériels et le reste du système. Par exemple, si les messages adressés au CDM (distributeur de billets) sont chiffrés de bout en bout, où doit se trouver cette « autre extrémité »? Si l'autre extrémité se termine au niveau du gestionnaire de GAB, par exemple, de nombreuses exigences d'interopérabilité doivent faire l'objet d’une discussion et d’un accord.

Il est également clair que même le distributeur de billets n'est pas encore bien sécurisé sur de nombreux GAB - voyez les différentes « attaques boîte noire » dans les médias. Une attaque boîte noire sur un GAB se produit lorsque des pirates interceptent la connexion avec le CDM et distribuent de l'argent en utilisant leur propre PC. La plupart des GAB modernes ont une connexion cryptée du PC au CDM, mais KAL soupçonne que la conception de la sécurité laisse beaucoup à désirer car certains de ces GAB n'ont pas de TPM. Soyons bien clairs : Pas de TPM = pas de sécurité. Les moyens obscurs de crypter la connexion à l'aide de clés protégées par magie ne sont pas de la sécurité. C'est de l'obscurité et de l'espoir. Si votre fournisseur de matériel ne peut pas publier d'informations sur la manière dont les clés de chiffrement sont protégées, sachez que c'est parce que les clés ne sont pas correctement protégées.

XFS4IoT et la protection des périphériques matériels

La bonne nouvelle est que le comité XFS de l’industrie du GAB discute de la manière dont la prochaine génération de dispositifs des GAB doit être protégée. Certains d'entre vous ont peut-être entendu parler de la prochaine version de XFS 4.0, qui a été nommée XFS4IoT. La partie IoT démontre l'intention de la spécification d'être prête pour le monde IoT moderne. Il existe plusieurs objectifs majeurs pour XFS4IoT :

1. La spécification est indépendante du système d'exploitation. Cela signifie que les GAB peuvent tourner avec Windows ainsi que Linux ou tout autre système d'exploitation.
2. Il est compatible avec le cloud. Les dispositifs du GAB peuvent exposer des services directement dans le cloud. Le cerveau du GAB peut être dans le cloud et pas seulement à l'intérieur du GAB comme c'est le cas aujourd'hui. Par exemple, le lecteur de carte pourrait exposer les services de lecture de carte dans le cloud. Le distributeur de billets pourrait exposer les services de distribution d'espèces dans le cloud.
3. Les services Web exposés de cette manière doivent être sécurisés. XFS4IoT aura une sécurité intégrée pour assurer la sécurité de bout en bout des dispositifs. Le protocole de transport sélectionné est Web Sockets sécurisé par TLS avec des certificats des deux côtés. De plus, chaque dispositif XFS4IoT peut avoir un élément matériel sécurisé pour permettre une sécurité de bout en bout pour la connexion. Cette connexion peut se terminer à l'intérieur du GAB lui-même (comme c'est courant aujourd'hui) ou elle peut se terminer sur un serveur cloud.

Le schéma ci-dessous illustre le concept :

Les GAB XFS4 peuvent être conçus comme un GAB conventionnel sur le côté gauche du diagramme où les dispositifs se connectent à une application logicielle sur le PC du GAB, ou peuvent exposer un service sécurisé dans le cloud comme sur le côté droit. Dans le second cas, il se peut qu'il n'y ait pas du tout de PC à l'intérieur du GAB et que chaque dispositif puisse être complètement indépendant l'un de l'autre, mais physiquement proche et fonctionnant en tandem, orchestré par l'application dans le cloud.

La chose la plus importante à noter sont les cases vertes étiquetées « HSE ». HSE signifie « élément de sécurité matérielle » et la spécification XFS, bien sûr, laisse libre cours aux fournisseurs de matériel pour déterminer la meilleure façon de l'implémenter. Il est évident que le HSE doit être un TPM ou contenir un sous-ensemble de fonctionnalités TPM. Au minimum, le HSE doit être capable de :

• Stocker vos clés privées en toute sécurité
• Mettre en œuvre une « mesure de la racine de confiance » (CRTM) pour garantir que seul un firmware sécurisé peut utiliser le HSE
• Mettre en œuvre des services de chiffrement et de signature

KAL en a discuté avec le comité TCG et ils indiquent qu'ils seraient ravis d'aider l‘industrie du GAB à réfléchir aux options. En fait, le TCG a déjà fait quelques progrès avec les concepts de « mini TPM ». L'un est la conception DICE du TCG et l'autre est la conception MARS du TCG. DICE et MARS sont-ils prêts à être utilisés dans l'industrie des GAB ? Il nous reste à le découvrir.

Une réflexion intéressante ici est de savoir si les TPM standards peuvent être utilisés comme HSE à l'intérieur de chaque dispositif. Du point de vue des coûts, la réponse peut être oui - les TPM coûtent moins de 1 USD en volume OEM. DICE pourrait coûter encore moins cher. Pour notre secteur, qui protège des millions de dollars de fonds des clients, le coût d'un TPM ou d'un autre type de HSE ne sera probablement pas une entrave.

Les GAB ont une deuxième racine de confiance - l’EPP

Nous avons discuté de la protection des périphériques dans la section précédente, mais il y a un dispositif unique que nous devons mettre en évidence dans le contexte de la sécurité, et c'est l'EPP (Encrypting Pin Pad, clavier crypté). L’EPP est, en fait, une racine de confiance indépendante à l’intérieur du GAB. Il est hautement sécurisé, est réglementé via les exigences PCI PED et chaque EPP est géré individuellement et suivi à l'échelle mondiale par l’industrie. Il a sa propre mesure CRTM de son propre firmware et s'autodétruit si une falsification est détectée. Il est donc très sûr.

Cependant, l'EPP a été à la fois un avantage et un inconvénient pour le secteur. Comme l'EPP offre un certain niveau de sécurité pour les GAB (nous discuterons de ses limites dans un instant), les banques se sont appuyées sur celui-ci pour sécuriser les transactions des GAB. L'EPP stocke la clé principale de la banque en toute sécurité, et l'utilisation d'une chaîne de clés garantit que le bloc PIN est sécurisé et que les messages de communication entre le GAB et le serveur sont cryptés et scellés. C'est une bonne sécurité. Cependant, ce n'est pas une sécurité suffisante.

L'EPP n'est pas disponible au démarrage du GAB et reste indisponible tant que Windows et que les SP XFS (les pilotes des dispositifs du GAB) n’ont pas démarré. Cela signifie que l'EPP n'a rien à dire sur la validité du logiciel à l'intérieur du GAB. Si une application GAB infectée par un logiciel malveillant souhaite recevoir un PIN ou sceller un message pour le serveur de GAB, l'EPP se soumettra à sa demande. Le périmètre de protection de l'EPP est trop petit pour pouvoir contribuer à sécuriser l’ensemble du GAB. C'est un joyau de sécurité dans une masse de logiciels potentiellement non protégés quand il n'y a pas de TPM.

Comment mettre à jour le logiciel lorsqu'il est protégé par un TPM ?

Le lecteur pense peut-être à ce stade que s'il est impossible de modifier un logiciel à l'intérieur d'un GAB protégé par un TPM, il sera difficile d'effectuer des mises à jour logicielles valides. N'oubliez pas que le logiciel applicatif est protégé à l'aide d'une règle de certificat. Il est signé par le développeur de l’application (qui peut être la banque elle-même ou le fournisseur de confiance de la banque). Il faut simplement que le logiciel mis à jour soit signé avec la clé privée sécurisée de l'entreprise de développement de logiciel, et le GAB acceptera le changement. C'est aussi simple que cela.

Les modifications apportées au logiciel de base mesurées par les PCR nécessitent une étape supplémentaire. Le logiciel de base peut être entièrement mis à jour à distance sans visite d'un technicien, mais il nécessite la création d'une clé temporaire pendant le processus d'installation, scellée contre les PCR inchangés. Une fois l'installation terminée, les nouvelles clés sont scellées contre l'ensemble complet de PCR. C’est simple.

Souvenez-vous de notre exemple précédent concernant Windows Hello : une bonne sécurité n'a pas besoin d'être difficile à utiliser. En fait, une sécurité de classe mondiale - ce que la protection TPM offre aux banques - est plus facile à utiliser et elle est sécurisée par cryptographie en comparaison avec les méthodes traditionnelles.

Se défendre contre les attaques physiques

Bien que nous ne l’ayons pas mentionné spécifiquement auparavant, une grande partie de la discussion ci-dessus porte sur la protection du GAB contre les attaques physiques et logicielles. Une méthode d'attaque courante sur les GAB consiste à retirer le disque dur, à modifier le logiciel et à déployer les modifications sur ce GAB ainsi que sur d'autres GAB. Cette méthode d'attaque n'est pas possible si le lecteur est chiffré et la chaîne de démarrage est protégée par le TPM.

Un autre type d'attaque consiste à utiliser la « force brute» avec le TPM en essayant diverses touches en succession rapide. Le TPM possède une protection « anti-hammering » intégrée qui empêche cela. 

Enfin, il existe certains autres types d'attaques extrêmes qui pourraient impliquer des interférences directes avec l'électronique de la carte mère. Une telle attaque coûterait cher à entreprendre car elle nécessite un équipement spécialisé et ne s'est pas produite jusqu'à présent, à notre connaissance. Cependant, il existe des moyens peu coûteux de se protéger contre de telles attaques, comme l'utilisation de résine pour protéger les connexions électroniques exposées sur la carte mère.

Méfiez-vous des solutions magiques

Sécuriser les GAB et les ordinateurs avec les TPM comme racine de confiance est le seul moyen connu et rendu public de sécuriser entièrement les systèmes informatiques. Notre industrie devrait se demander pourquoi la sécurité basée sur le TPM n'est pas plus courante sur les réseaux GAB. Bien sûr, différentes entreprises voudront entrer en concurrence sur le marché et elles voudront positionner leurs produits de sécurité. C'est à prévoir. Mais il est très important que les banques ne soient pas tentées par des solutions illusoires. Voici une liste de choses à surveiller :

Mythe : « Pas besoin d'élément matériel sécurisé »

Ayez à l’esprit qu'il est impossible de stocker des clés privées sur le disque/SSD d'un GAB en toute sécurité. La raison est que quelle que soit la longueur de la chaîne de clés, il doit y avoir une clé initiale en clair. Si cette clé est «cachée» sur le lecteur, elle peut toujours être récupérée. Certaines solutions prétendent générer la clé au démarrage. N’oubliez pas cependant qu'un code en clair est nécessaire pour générer cette clé. Il doit être en clair car nous n'avons pas encore décrypté le disque dur. S'il est en clair, il peut très simplement être désassemblé par rétro-ingénierie du code exécutable qui sera en clair avant le décryptage du disque.

Considérez les choses autrement. S'il était possible de conserver les clés en toute sécurité dans un GAB en utilisant uniquement des techniques logicielles, notre industrie ne se serait pas donné la peine de construire des EPP…

Mythe : « Aucun élément de sécurité matérielle n'est requis car les clés sont stockées sur le réseau »

Si le GAB n'est pas suffisamment sécurisé pour contenir les clés en toute sécurité car il n'y a pas de TPM, il n'est pas possible de résoudre ce problème en déplaçant les clés vers un emplacement réseau. Voici pourquoi : lorsque le GAB démarre, il doit accéder au réseau pour obtenir la clé sécurisée. Il ne dispose alors pas d'un moyen cryptographiquement sécurisé de s'authentifier sur le réseau car il n'a pas de stockage de clés. Cela signifie que le serveur sur le réseau ne sait pas « qui demande la clé ». Par exemple, lorsque Bitlocker stocke des clés sur le réseau, il a toujours besoin d'un TPM pour s'authentifier auprès du réseau. Pas de TPM = pas de sécurité.

Mythe : « ¨Pas besoin de clés de chiffrement »

Le fournisseur affirme que le stockage des clés est inutile car il dispose d'une technologie magique qui permet au cryptage de se produire sans clés. Eh bien, ce serait vraiment trop beau pour être vrai. Pourquoi tout le monde s’est-il toujours donné du mal avec les techniques de gestion des clés alors que vous n'en avez pas besoin ? Toutes les techniques de cryptage connues telles que 3DES, AES et RSA nécessitent des clés privées. Les clés privées sont appelées ainsi car elles doivent impérativement être stockées en toute sécurité. Ce qui rend un système de cryptage sécurisé, c'est que les clés sont choisies parmi un très grand nombre de possibilités. Par exemple, 3DES compte au moins 2¹¹² clés. Il faudrait 30 ans pour essayer toutes les clés si on les essayait au rythme de 5 milliards par seconde. Avec AES, il faudrait 10²² ans au même rythme.

Mythe : « Notre algorithme est confidentiel »

La vraie sécurité repose sur des normes ouvertes et des algorithmes publics en plus des clés confidentielles. Le seul aspect d'un système de sécurité qui doit être confidentiel, ce sont les clés. Si les clés sont compromises, vous les modifiez et le système est à nouveau sécurisé.

Mythe : « Les listes de contrôle d'accès (ACL) assurent notre sécurité »

Les listes de contrôle d'accès sont facilement contournées en l'absence d'un verrouillage du TPM. Les ACL présentent également divers autres inconvénients, que nous n'aborderons pas ici, mais il suffit de dire que les ACL en elles-mêmes sont une protection insuffisante pour les GAB.

Conclusions

J'espère que le lecteur est parvenu à comprendre pourquoi le TPM est essentiel à la sécurité informatique et donc essentiel à la sécurité du GAB. J'espère qu'il est également clair que la plupart des banques ont encore du chemin à parcourir pour sécuriser leur réseau de manière cryptographique garantie. Il est également important de noter que tout système de sécurité de ce type doit être conçu en gardant à l'esprit l'interopérabilité. Étant donné que plusieurs fournisseurs et plusieurs solutions de produits font partie intégrante du paysage technologique moderne du GAB, il ne serait pas possible que des verrouillages soient mis en œuvre par chaque fournisseur de manière indépendante. Cela créerait un GAB inutilisable.

J'espère que ce document est le début d'un processus qui permettra de développer des spécifications de sécurité interopérables en utilisant les fondations cryptographiques dont nous disposons à partir des TPM. Le Trusted Computing Group nous a proposé son aide. Il appartient maintenant aux divers comités de notre industrie - XFS4IoT, ATMIA et EAST - ainsi qu'aux banques et aux fournisseurs de définir la voie à suivre.

Mes remerciements

Je tiens à remercier les personnes suivantes pour leur contribution à ce projet :

• Michael Moltke (NCC Group Denmark)
• Kit Patterson (KAL)
• Will Arthur, David Challener et Kenneth Goldman pour la rédaction de l'eBook sur les TPM et David Challener pour l'organisation du support de la part du TCG

Pour plus d’informations, contactez-nous par e-mail à l’adresse Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.