Les ordinateurs quantiques deviennent de plus en plus puissants. Ils risquent un jour d’être capables de casser la cryptographie moderne à clé publique. En l’absence de contre-mesures, cela conduirait certainement à l’effondrement de notre société moderne. C’est pourquoi l’on élabore des alternatives. Outre la normalisation de nouveaux algorithmes cryptographiques résistants aux ordinateurs quantiques, la distribution quantique de clé (“Quantum Key Distribution” – QKD) est présentée comme une alternative encore plus sûre. Cet article examine de plus près cette technique. De quoi s’agit-il ? Quand est-elle utile ? Quels sont les défis ? Quel est son rapport avec la cryptographie résistante aux attaques quantiques ?

La menace

La cryptographie à clé publique est – bien que quasi invisible – omniprésente dans notre société numérique. Elle est notamment nécessaire pour signer des documents ou des transactions bancaires, ainsi que pour l’authentification et la communication sécurisées avec pratiquement tous les services internet. Afin d’établir un canal de communication sécurisé, deux parties doivent d’abord se mettre d’accord sur une clé symétrique à l’aide d’un schéma de chiffrement à clé publique. Cette clé symétrique permet alors à ces deux entités de communiquer de manière sécurisée à l’aide d’un chiffrement symétrique.

Bien que la cryptographie symétrique résiste assez bien aux futures attaques quantiques, de puissants ordinateurs quantiques pourraient un jour – personne ne sait vraiment quand – compromettre la cryptographie à clé publique moderne. Même si ce scénario semble aujourd’hui lointain, le BSI (agence allemande de cybersécurité), la NSA (agence états-unienne de renseignement), la CISA (agence états-unienne de cybersécurité) et le NIST (organisme états-unien de normalisation), entre autres, mettent en garde contre l’attaque harvest now, decrypt later (récolter maintenant, déchiffrer plus tard) : les attaquants peuvent aujourd’hui collecter des messages chiffrés à grande échelle. Lorsque ceux-ci auront accès à un ordinateur quantique suffisamment puissant dans quelques années, ils seront en mesure de déchiffrer des messages, qui pourraient être encore très sensibles à ce moment-là. Pensons par exemple aux données médicales, aux secrets militaires et à la propriété intellectuelle qui restent sensibles pendant plusieurs décennies. L’urgence est souvent justifiée par le théorème de Mosca.

Réponse 1 : Algorithmes cryptographiques résistants au quantum

Afin de contrer cette menace, le NIST a déjà entamé en 2016 une procédure visant à proposer de nouveaux algorithmes normalisés résistants aux ordinateurs quantiques pour les signatures numériques, d’une part, et d’autre part, pour le chiffrement à clé publique et l’établissement de clés (public-key encryption & key establishment). Ces algorithmes, comme la génération actuelle de cryptographie à clé publique, peuvent être exécutés par des ordinateurs classiques. 

La cryptographie à clé publique moderne repose sur plusieurs hypothèses. Par exemple, l’algorithme RSA, qui date des années 1970, repose sur la supposition qu’un ordinateur est incapable de décomposer un nombre naturel qui est le produit de deux nombres premiers suffisamment grands – par exemple,  2048 bits chacun – pour le décomposer en ses facteurs premiers. Après plus de 50 ans, cette supposition est toujours valable, même pour les ordinateurs classiques. Cependant, de puissants ordinateurs quantiques pourraient le faire avec efficacité, en utilisant l’algorithme de Shor.

La cryptographie résistante aux ordinateurs quantiques repose également sur des hypothèses mathématiques. Nous supposons donc ici que les ordinateurs classiques et les ordinateurs quantiques sont incapables de résoudre efficacement certains problèmes. Nous ne pouvons pas le prouver – cela reste une hypothèse – et nous n’en sommes donc jamais sûrs à 100 %. Bien qu’avec le temps, la confiance dans ces hypothèses cryptographiques s’accroisse, certains peuvent encore ressentir un certain malaise.

Réponse 2 : Distribution quantique de clé

Une deuxième réponse à la menace posée par les ordinateurs quantiques se concentre uniquement sur l’établissement de clés (key establishment) et porte le nom de distribution quantique de clé (quantum key distribution – QKD). La beauté de la QKD réside dans le fait que deux parties peuvent se mettre d’accord sur une clé symétrique sans s’appuyer sur de telles hypothèses mathématiques ; théoriquement, la QKD repose uniquement sur les principes de la mécanique quantique, en particulier la superposition ou l’intrication.  Plusieurs protocoles ont été proposés (tels que BB84 et E91).

Dans le cadre de la QKD, des particules dans un état quantique – généralement des photons – sont échangées sur le canal quantique. Il s’agit soit d’une liaison par fibre optique attribuée exclusivement à ces parties, soit d’une liaison par satellite. L’observation d’une particule dans un état quantique fait de toute façon sortir la particule de son état quantique. Par conséquent, si une partie écoute le protocole, elle sera rapidement détectée. Seule la clé est convenue sur le canal quantique, tandis que l’échange réel de données chiffrées a lieu sur un canal classique.

La Commission européenne encourage cette technique par le biais de l’initiative EuroQCI « European Quantum Communication Infrastructure. » Elle implique les 27 États membres et l’Agence spatiale européenne (ESA). Il existe une composante terrestre axée sur les communications par fibre optique et une composante spatiale axée sur les communications par satellite. Cette seconde composante fera partie du programme IRIS² de la Commission européenne pour un système de communication sécurisé par satellite. Ces quatre dernières années, l’Europe a déjà investi quelque 180 millions d’euros dans EuroQCI. Les ambitions sont vastes, comme en témoigne notamment la citation suivante : « L’EuroQCI sera une infrastructure de communication quantique sécurisée couvrant l’ensemble de l’UE, y compris ses territoires d’outre-mer. » La branche belge d’EuroQCI est BeQCI.

D’autres pays, en particulier la Chine, investissent également massivement dans la QKD. Une fois de plus, la Chine a confirmé sa position de leader mondial dans le domaine de QKD en devenant la première à mettre en œuvre avec succès un protocole de QKD sur un câble (spiralé) de plus de 1 000 km en 2023.

Défis

La QKD se heurte toutefois à un certain nombre de difficultés. Celles-ci ont été énumérées dans un document de synthèse technique conjoint de janvier 2024 des agences de cybersécurité allemande (BSI) et française (ANSSI), de l’agence de renseignement néerlandaise (AIVD) et des forces armées suédoises.  Pour résumer, il est actuellement trop tôt pour déployer la QKD dans la pratique. Nous en exposons les raisons ci-dessous.

Coût et rapidité

Contrairement aux algorithmes résistants aux ordinateurs quantiques, la QKD exige un matériel spécialisé, dont le coût est pour le moment élevé, et nécessite des connexions par fibre optique non partagées et exclusives. La maintenance de l’ensemble du système de QKD est également coûteuse.

La perte de puissance du signal augmente de manière exponentielle en fonction de la distance. Les solutions commerciales ne dépassent pas 100 km, les solutions expérimentales quelques centaines de kilomètres. Sur une distance de 10 km, les vitesses les plus élevées rapportées en laboratoire sont de 15 mégaoctets par seconde, pour 100 km, elles tombent à 240 bits par seconde. Une installation couvrant effectivement une distance géographique de 30 km – c’est-à-dire ne se limitant pas à un câble de fibre optique enroulé dans un laboratoire – a atteint 6 000 bits par seconde. L’installation de test mentionnée précédemment en Chine sur une longueur de 1 002 km de fibre optique avait une vitesse de 0,0034 bits par seconde. Dans ce dernier cas, il faudrait donc 21 heures pour se mettre d’accord sur une clé de 256 bits. Il convient de noter qu’il n’est généralement pas nécessaire d’avoir des débits extrêmement élevés, étant donné que – comme indiqué précédemment – seule la clé est convenue sur ce canal, tandis que l’échange réel de données chiffrées a lieu sur un canal classique.

Les distances plus longues nécessitent aujourd’hui des nœuds de confiance (trusted nodes), comme par exemple les satellites. Les nœuds de confiance ont en principe accès aux clés convenues et présentent donc un risque sérieux pour la sécurité. À terme, les répéteurs quantiques pourraient offrir une solution, mais ceux-ci en sont encore au stade de la recherche fondamentale, et il n’est pas encore question d’application pratique.

Déni de service

L’écoute ou toute interférence sur le canal quantique entraîne l’impossibilité de facto de s’entendre sur les clés. Qu’il s’agisse d’une connexion par fibre optique (attribuée exclusivement) ou d’une connexion par satellite, le choix d’un autre itinéraire pour contourner les interférences n’est pas possible. Lorsque le protocole de QKD est mis en œuvre sur une connexion exclusive par fibre optique, contrairement aux communications contemporaines, il n’existe aucun chemin alternatif en cas de rupture de câble.

Authentification

La QKD ne détecte que les attaquants passifs (qui écoutent) (bien qu’il faille être prudent à cet égard également). Une attaque par l’homme du milieu (attaquant actif) est toujours possible : Si Alice et Bob veulent exécuter un protocole de QKD l’un avec l’autre, il est possible qu’ils exécutent à leur insu le protocole de QKD non pas l’un avec l’autre, mais chacun avec Charlie (l’homme du milieu). De cette manière, Charlie découvre les clés que Bob et Alice utilisent pour chiffrer leurs messages. Si Charlie peut également se positionner comme un homme du milieu dans la communication de données actuelles, il peut intercepter et déchiffrer toutes les communications cryptées. Ce scenario est illustré dans la figure ci-dessous. Bien que ce scénario semble improbable, il est inacceptable d’un point de vue cryptographique. L’authentification des entités est donc indispensable.

Une première façon d’y parvenir est d’utiliser des codes d’authentification de message (message authentication code – MAC). Chaque message envoyé contiendrait une étiquette (code) qui ne peut être créée et vérifiée qu’à l’aide d’une clé partagée à l’avance. Bien entendu, la question est de savoir comment s’assurer que les deux parties peuvent partager une clé qui n’est pas trop ancienne. Si nous partageons quand même une clé secrète à l’avance, l’avantage de la QKD – qui vise simplement à se mettre d’accord sur une clé – devient moins évident.

Un second moyen d’obtenir un canal authentifié consiste à signer numériquement les messages échangés à l’aide d’un système de signature numérique résistant aux attaques quantiques. Cependant, un tel schéma repose sur des hypothèses mathématiques dont la QKD voulait se débarrasser.

En résumé, la QKD n’est pas une solution en soi, mais elle a besoin du soutien de techniques d’authentification. Les signatures numériques et les MAC sont les techniques existantes pour cela, et peut-être qu’avec le temps, d’autres approches plus appropriées seront trouvées.

Maturité

Le document de synthèse mentionné précédemment indique en outre que la technique de QKD n’est pas suffisamment mûre pour des utilisations pratiques aujourd’hui. Il y est fait référence à l’absence de normes et à des preuves de sécurité encore insuffisamment développées. Afin d’éviter que toutes sortes de vulnérabilités ne se glissent dans les dispositifs de QKD, des efforts restent à faire pour mettre en place des procédures d’évaluation et de certification rigoureuses.

Conclusions

La QKD est une technique passionnante, mais pour la rendre utilisable dans la pratique, il faudra remédier aux lacunes constatées. Quant à savoir dans quelle mesure cela réussira, il s’agit pour l’instant d’un pari risqué. Quoi qu’il en soit, de nombreuses recherches seront nécessaires.  

Hormis quelques cas d’utilisation de niche, il est sage de s’appuyer aujourd’hui et dans un avenir proche sur la cryptographie à clé publique pour convenir des clés. Pour cela, nous n’avons pas besoin de matériel spécial, de satellites ou de connexions exclusives par fibre optique. Après tout, la cryptographie à clé publique résistante aux attaques quantiques, qui, contrairement à la QKD, peut être utilisée à d’autres fins que le choix de clés, fonctionne également sur des ordinateurs classiques.

Le document de synthèse conclut donc :

In light of the urgent need to stop relying only on quantum-vulnerable public-key cryptography for key establishment, the clear priority should therefore be the migration to post-quantum cryptography in hybrid solutions with traditional symmetric keying or classically secure public-key cryptography.

La NSA, a également écrit en 2021 :

NSA does not consider QKD a practical security solution for protecting national security information

En résumé, la QKD est une technique qui mérite d’être approfondie, mais dont la mise en pratique est trop éloignée dans le futur pour être pertinente pour Smals et ses membres aujourd’hui.

Cette contribution a été soumise par Kristof Verslype, cryptographe chez Smals Research. Elle a été rédigée en son nom propre et ne prend pas position au nom de Smals.

Kwantumcomputers worden steeds krachtiger. De kans bestaat dat ze op een dag in staat zullen zijn om de moderne publieke sleutelcryptografie te breken. Zonder tegenmaatregelen leidt dit zonder meer tot een ineenstorting van onze moderne samenleving. Daarom bouwt men aan alternatieven. Naast de standaardisatie van nieuwe, kwantumresistente cryptografische algoritmes, wordt Quantum Key Distribution (QKD) als een nog veiliger alternatief naar voor geschoven. Dit artikel gaat dieper in op deze technologie. Wat is het? Wanneer is het nuttig? Wat zijn de uitdagingen? Hoe verhoudt het zich tot kwantumresistente cryptografie?

De dreiging

Publieke sleutelcryptografie is – weliswaar quasi onzichtbaar – overal aanwezig in onze digitale samenleving. Het is onder meer noodzakelijk voor het ondertekenen van documenten of banktransacties en voor veilige authenticatie en communicatie met zowat elke internetdienst. Voor het opzetten van zo’n veilig communicatiekanaal spreken de twee partijen met behulp van publieke sleutelencryptie een symmetrische sleutel af. Die symmetrische sleutel laat twee entiteiten vervolgens toe om veilig te communiceren met behulp van symmetrische encryptie.

Terwijl symmetrische cryptografie er vrij goed bestand tegen is, kunnen krachtige kwantumcomputers op termijn – eigenlijk weet niemand echt wanneer – de moderne publieke sleutelcryptografie ondermijnen. Hoewel dit scenario vandaag nog veraf lijkt, waarschuwen onder meer de BSI (Duitse cybersecurityagentschap) de NSA (Amerikaanse inlichtingendienst), het CISA (Amerikaans cybersecurity agentschap) en het NIST (Amerikaanse organisatie voor standaardisatie) voor de harvest now, decrypt later aanval: aanvallers kunnen vandaag vercijferde berichten op massale schaal verzamelen. Wanneer ze over een aantal jaar de beschikking hebben over een voldoende krachtige kwantumcomputer, kunnen ze deze berichten – die dan nog steeds erg gevoelig kunnen zijn – ontcijferen. Denk bijvoorbeeld aan medische gegevens, militaire geheimen en intellectuele eigendommen die meerdere decennia gevoelig blijven. De urgentie wordt doorgaans onderbouwd met behulp van het Theorema van Mosca.

Antwoord 1: Kwantumresistente cryptografische algoritmes

Om die dreiging te counteren startte het NIST reeds in 2016 een procedure om te komen tot nieuwe gestandaardiseerde kwantumresistente algoritmes voor enerzijds digitale handtekeningen en anderzijds publieke sleutelvercijfering en het afspreken van sleutels (public-key encryption & key establishment). Deze algoritmes kunnen, net zoals de huidige generatie publieke sleutelcryptografie, door klassieke computers uitgevoerd worden. 

Moderne publieke sleutelcryptografie is gebouwd op aannames. RSA, dat dateert uit de jaren 70, is bijvoorbeeld gebaseerd op de aanname dat een computer niet in staat is om een natuurlijk getal dat het product is van twee voldoende grote priemgetallen – vb. 2048 bits elk – te ontbinden in zijn priemfactoren. Na ruim 50 jaar houdt deze aanname nog steeds stand, toch voor klassieke computers. Krachtige kwantumcomputers zouden dit wel efficiënt kunnen, m.b.v. het Algoritme van Shor.

Ook kwantumresistente cryptografie steunt op wiskundige aannames. We veronderstellen hier dus dat zowel klassieke computers als kwantumcomputers niet in staat zijn om bepaalde problemen efficiënt op te lossen. We kunnen dit niet bewijzen – het blijft een aanname – en zijn dus nooit 100% zeker. Hoewel mettertijd het vertrouwen in dergelijke cryptografische aannames groeit, blijven sommigen misschien toch enigszins met een oncomfortabel gevoel zitten.

Antwoord 2: Quantum key distribution

Een tweede antwoord op de dreiging die uitgaat van kwantumcomputers focust enkel op het afspreken van sleutels (key establishment) en luistert naar de naam quantum key distribution (QKD). Het mooie van QKD is dat twee partijen een symmetrische sleutel met elkaar af kunnen spreken zonder beroep te doen op dergelijke wiskundige aannames; theoretisch steunt QKD enkel op principes uit de kwantummechanica, met name superpositie of verstrengeling.  Meerdere protocollen werden voorgesteld (zoals BB84 en E91)

Bij QKD worden deeltjes in een kwantumtoestand – doorgaans fotonen –  uitgewisseld over het kwantumkanaal. Dit is ofwel een aan deze partijen exclusief toegewezen glasvezelverbinding, ofwel een satellietverbinding. De observatie van een deeltje in een kwantumtoestand haalt het deeltje sowieso uit zijn kwantumtoestand. Indien een partij het protocol afluistert, zal dit bijgevolg snel gedetecteerd worden. Enkel de sleutel wordt over het kwantumkanaal afgesproken, terwijl de eigenlijke uitwisseling van vercijferde data over een klassiek kanaal plaatsvindt.

De Europese commissie zet in op deze technologie via het EuroQCI (European Quantum Communication Infrastructure) initiatief. Zowel de 27 lidstaten als het Europese ruimteagentschap (ESA) zijn hierin betrokken. Er is een grondcomponent die focust op communicatie over glasvezel en een ruimtecomponent die focust op satellietcommunicatie. Die tweede component zal deel uitmaken van het IRIS² programma van de Europese Commissie voor een veilig, satellietgebaseerd communicatiesysteem. De afgelopen 4 jaar investeerde Europa reeds zo’n 180 miljoen euro in EuroQCI. Dat de ambities ver rijken, blijkt onder meer uit volgende citaat:  “The EuroQCI will be a secure quantum communication infrastructure spanning the whole EU, including its overseas territories.” De Belgische tak van van EuroQCI is BeQCI.

Ook andere landen, in de eerste plaats China, investeren stevig in QKD. China is de QKD leider wereldwijd, wat nog maar eens bevestigd werd toen ze in 2023 er als eersten in slaagden een QKD protocol succesvol uit te voeren over een (opgerolde) kabel van meer dan 1000km.

Uitdagingen

Toch stoot de QKD technologie op een aantal uitdagingen. Deze werden in Januari 2024 toegankelijk opgelijst in een gezamenlijke position paper van het BSI, ANSSI, AIVD en de Zweedse Strijdkrachten. De eerste drie zijn de Duitse en Franse cybersecurityagentschappen, gevolgd door de Nederlandse inlichtingendienst.  Samengevat is het momenteel nog te vroeg om QKD in de praktijk in te zetten. De redenen geven we hieronder.

Kost & snelheid

In tegenstelling tot kwantumresistente algoritmes, vereist QKD gespecialiseerde, voorlopig dure, hardware en zijn niet-gedeelde, exclusieve glasvezelconnecties vereist. Het onderhoud van het hele QKD systeem is eveneens duur.

Het verlies aan signaalsterkte stijgt exponentieel in functie van de afstand. Commerciële oplossingen gaan niet veel verder dan een 100km, experimentele oplossingen een paar honderd kilometer. Over een afstand van 10km zijn de hoogst gerapporteerde snelheden in labo-omstandigheden 15 megabyte per seconde, voor 100km daalt dit tot 240 bits per seconde. Een opstelling waarbij effectief 30km geografische afstand – dus niet enkel een opgerolde glasvezelkabel in een labo – overbrugd werd, haalde 6000 bits per seconde. De eerder vermeldde testopstelling in China over een lengte van 1002km optische vezel had een snelheid van 0.0034 bits per seconde. Het zou in dat laatste geval dus 21 uur duren om een sleutel van 256 bit af te spreken. Bemerk wel dat doorgaans geen extreem hoge debieten vereist zijn, gezien – zoals eerder vermeld – enkel de sleutel via dit kanaal afgesproken wordt, terwijl de eigenlijke uitwisseling van vercijferde data over een klassiek kanaal plaatsvindt.

Om langere afstanden te overbruggen zijn vandaag vertrouwde knooppunten (trusted nodes) nodig. Ook satellieten zijn vandaag trusted nodes. Trusted nodes hebben in principe toegang tot de afgesproken sleutels en vormen daardoor een ernstig veiligheidsrisico. Op termijn zouden quantum repeaters een uitweg kunnen bieden, maar deze bevinden zich in de fase van fundamenteel onderzoek en er is nog geen sprake van een praktische toepasbaarheid.

Denial-of-service

Afluisteren, of om het even welke interferentie, van het kwantumkanaal resulteert de facto in de onmogelijkheid om sleutels af te spreken. Zowel bij (exclusief toegekende) glasvezelverbinding als satellietverbinding kan niet zomaar een andere route gekozen worden om de interferentie te omzeilen. Wanneer het QKD protocol over een exclusieve glasvezelverbinding uitgevoerd wordt, hebben we, in tegenstelling tot hedendaagse communicatie, bij kabelbreuk geen alternatieve wegen.

Authenticatie

QKD detecteert enkel passieve (afluisterende) aanvallers (al moeten we ook daarvoor opletten). Een man in the middle (actieve aanvaller) is nog steeds mogelijk: Als Alice en Bob met elkaar een QKD protocol willen uitvoeren is het mogelijk dat ze het QKD protocol onbewust niet met elkaar, maar elk met Charlie (Man in the Middle) uitvoeren. Zo komt Charlie de sleutels te weten waarmee Bob en Alice hun berichten vercijferen. Indien Charlie zich ook als man in the middle kan positioneren bij de eigenlijke datacommunicatie, kan hij alle vercijferde communicatie onderscheppen en ontcijferen. Dit wordt geïllustreerd in onderstaande figuur. Hoewel dit een onwaarschijnlijk scenario lijkt, is het onaanvaardbaar vanuit cryptografisch perspectief. Entity authenticatie is bijgevolg onontbeerlijk.

Een eerste manier om dit te realiseren is door middel van Message Authentication Codes (MACs). Elk verstuurd bericht zou een tag (code) bevatten die enkel gecreëerd en geverifieerd kan worden m.b.v. een op voorhand gedeelde sleutel. Dan is de vraag uiteraard hoe we ervoor zorgen dat beide partijen een niet al te oude sleutel met elkaar kunnen delen. Als we toch al een geheime sleutel op voorhand delen, wordt het voordeel van QKD – wat net tot doel heeft een sleutel af te spreken – minder helder.

Een tweede wijze om tot een geauthentiseerd kanaal te komen is door de uitgewisselde berichten digitaal te ondertekenen m.b.v. een kwantumresistent schema voor digitale handtekeningen. Een dergelijk schema steunt dan toch weer op wiskundige aannames waar QKD vanaf wou raken.

Samengevat is QKD geen oplossing op zich, maar heeft het nood aan ondersteuning door technologieën voor authenticatie. Bestaande technologieën daarvoor zijn digitale handtekeningen en MAC’s, maar misschien vindt men op termijn wel andere, meer geschikte benaderingen.

Maturiteit

De recentelijk gepubliceerde position paper geeft verder aan dat QKD technologie vandaag onvoldoende volwassen is voor praktische use cases. Daarbij wordt verwezen naar het gebrek aan standaarden en nog steeds onvoldoende ontwikkelde veiligheidsbewijzen. Om te vermijden dat er allerlei kwetsbaarheden sluipen in de QKD toestellen is er nog werk aan de winkel om te komen tot rigoureuze evaluatieprocedures en certificering.

Conclusies

QKD is een boeiende technologie, maar om het ook in de praktijk inzetbaar te maken zullen de huidige tekortkomingen aangepakt moeten worden. In welke mate dit zal slagen is voorlopig koffiedik kijken. In elk geval zal daarvoor nog heel wat onderzoek nodig zijn.  

Los van een aantal niche use cases is het wijs om vandaag en in de nabije toekomst een beroep te doen op publieke sleutelcryptografie om sleutels af te spreken. Daarvoor hebben we geen speciale hardware, satellieten of exclusieve glasvezelconnecties nodig. Ook kwantumresistente publieke sleutelcryptografie, dat i.t.t. QKD voor meer ingezet kan worden dan enkel het afspreken van sleutels, wordt immers uitgevoerd op klassieke computers.

De position paper besluit dan ook als volgt:

In light of the urgent need to stop relying only on quantum-vulnerable public-key cryptography for key establishment, the clear priority should therefore be the migration to post-quantum cryptography in hybrid solutions with traditional symmetric keying or classically secure public-key cryptography.

Ook de Amerikaanse inlichtingendienst, de NSA, schreef in 2021:

NSA does not consider QKD a practical security solution for protecting national security information

Samengevat is QKD een technologie die verder onderzocht moet worden, maar waarvan de praktische bruikbaarheid te ver in de toekomst ligt om vandaag relevant te zijn voor Smals en haar leden.

Dit is een ingezonden bijdrage van Kristof Verslype, cryptograaf bij Smals Research. Het werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Om te voldoen aan de eisen van hun klanten die met gevoelige gegevens omgaan, of om nieuwe klanten aan te trekken, verrichten leveranciers van publieke IT-infrastructuren inspanningen om hun beveiliging te verbeteren en met name om de gegevens van hun klanten beter te beschermen.  Microsoft, bijvoorbeeld, zegt elk jaar ongeveer een miljard dollar te investeren in de beveiliging van zijn infrastructuren [1]. Sinds halfweg 2010 investeren deze infrastructuurleveranciers in een aanbod van confidential computing. Voornamelijk gebaseerd op Trusted Execution Environments (TEE), vermindert dit in principe het vereiste vertrouwen van de klant in de infrastructuurleverancier.

In een vorig artikel (in het Frans) gaven we een algemeen overzicht van deze TEE’s en het nut ervan. In dit artikel gaan we dieper in op hoe de belangrijkste commerciële implementaties werken. Het is echter belangrijk om in gedachten te houden dat de definities van confidential computing en TEE verschillen en soms onvolledig zijn. Dit kan leiden tot een vals gevoel van veiligheid, juridische onzekerheden en maakt het vergelijken moeilijk [2]. Als reactie op dit gebrek aan standaardisatie en interoperabiliteit tussen de verschillende benaderingen van confidential computing is het Confidential Computing Consortium opgericht door grote spelers in de sector, waaronder AMD, Google, Intel en Microsoft. Daarbij moeten we opmerken dat Amazon geen deel uitmaakt van dit consortium en dat zijn Nitro-systeem (zie hier) sterk afwijkt van de andere benaderingen¹.

Een uitgebreidere versie van dit artikel, voorbehouden aan de klanten van Smals, is op aanvraag beschikbaar.

Fabrikanten van microprocessors

AMD en Intel zijn de twee voornaamste fabrikanten van microprocessors die noodzakelijke functionaliteiten bieden voor de confidential computing in grote data centers². Terwijl Intels TDX en AMD’s SEV-SNP-technologieën ontwikkeld zijn om complete virtual machines (VM’s) te beschermen, is de SGX-technologie erg verschillend en heeft deze een kleiner attack surface. Figuur 1 toont de elementen die de Trusted Computing Base (TCB) vormen voor deze drie technologieën die we in de volgende paragrafen beschrijven.

AMD’s SEV-SNP-technologie

In 2016 introduceerde AMD de technologie Secure Encrypted Virtualisation (SEV) om VM’s op hardwareniveau te isoleren van de hypervisor [3], [4]. Elke VM ontvangt zijn eigen AES-coderingssleutel voor geheugenversleuteling. De status van de microprocessorregisters van elke VM wordt ook versleuteld, waardoor de hypervisor de gegevens in de VM niet kan lezen. Later voegde AMD de technologie Secure Nested Paging (SNP) toe om geheugenintegriteit te beschermen en aanvallen door een schadelijke hypervisor te voorkomen (bijv. replay-aanvallen, herconfiguratie van het virtuele geheugenvertaalmechanisme, corruptie van geheugengegevens) [5]. Het fundamentele principe van SEV-SNP is dat als een VM een geheugenpagina kan lezen die voor haar is gereserveerd (en daarom is versleuteld), ze altijd de laatste waarde moet lezen die ze zelf heeft geschreven. Verder vormen in het beveiligingsmodel dat voor SNP wordt gebruikt alleen de VM van de klant en de AMD-microprocessor onderdeel van de trusted base. Dit omvat niet de hypervisor, BIOS, andere VM’s, enzovoort (zie Figuur 1). Tot slot stelt een SEV-SNP-optie VM’s in staat om hun virtuele geheugen op te delen in vier Virtual Machine Privilege Levels (VMPL’s) op een vergelijkbare manier als de beschermingsringen in de x86-architectuur.

AMD’s attestatiemechanisme op afstand verifieert dat de hostmachine een AMD-processor is die de SEV-SNP-technologie ondersteunt en dat een VM is geïmplementeerd met SEV-SNP-bescherming. Elke AMD-processor bevat een beveiligde coprocessor die een paar dedicated sleutels genereert (“Platform Endorsement Key (PEK)”), zelf ondertekend door een unieke sleutel die is afgeleid van geheimen opgeslagen met behulp van eenmalig programmeerbare zekeringen in de chip zelf. Deze PEK wordt ook indirect gebruikt om een gedeeld geheim te creëren tussen het SEV-platform en de klant [6]. Wanneer de beveiligde VM door de hypervisor op het SEV-platform wordt gestart, berekent de SEV-firmware de meting (waarde van de cryptografische hash) van het geheugen van de VM. Deze meting kan veilig worden doorgegeven aan de klant, zodat deze kan controleren of de gedeployde VM niet is gewijzigd.

De SEV-SNP-technologie is beschikbaar op AMD EPYC-processors van 3^e (serie 7003) en 4^e generatie (serie 9004). Deze processors zijn verkrijgbaar bij verschillende leveranciers, waaronder Dell (‘PowerEdge‘-servers), Lenovo en HP. De prijzen variëren van enkele duizenden tot enkele tienduizenden euro’s, afhankelijk van de configuratie.

Intels SGX- en TDX-technologieën

Met Intels systeem Software Guard eXtensions (SGX), dat in 2015 werd geïntroduceerd, kan een software beschermde geheugengebieden definiëren voor beveiligde ‘enclaves’ die geïsoleerd zijn van andere processen die op dezelfde machine draaien (kernels van besturingssystemen, hypervisor, enz.) en waartoe randapparatuur ook rechtstreeks toegang heeft. De processor zorgt ervoor dat elke enclave zijn eigen speciale, versleutelde geheugengebied heeft en registreert elke allocatie door het besturingssysteem [7]. Een enclave wordt gegenereerd als een dynamisch gedeelde bibliotheek met behulp van standaard compilatietools. Wanneer een enclave wordt geïnitialiseerd, vraagt het besturingssysteem de processor om de toepassing te kopiëren naar geheugenpagina’s in de versleutelde beschermde ruimte. Wanneer dan de toepassing in het geheugen is geladen, berekent de processor een meting van de toepassing. Hiermee kan vervolgens de integriteit van de toepassing gecontroleerd worden met behulp van een attestatiemechanisme. In 2020 introduceerde Intel de technologie Trusted Domain Extensions (TDX), een ondertekende softwaremodule uitgevoerd in een nieuwe processormodus die kan worden gebruikt om virtuele machines te beschermen en cryptografisch te isoleren. Meer details over de werking en architectuur van TDX zijn te vinden in [8].

Er zijn twee soorten attestatie op afstand beschikbaar met SGX: Enhanced Privacy ID (EPID) en Data Centre Attestation Primitives (DCAP). De eerste is een attestatiemodus waarbij de Intel-attestatieserver moet worden gecontacteerd om informatie te verkrijgen over de aanvragende enclave. De tweede vereist geen contact met de Intel-attestatieserver. Tijdens het bouwen van een enclave worden er twee metingen gedaan. MRENCLAVE is de cryptografische hashwaarde van de virtuele geheugenlayout die aan de enclave wordt toegewezen wanneer deze wordt gestart. De andere meting, MRSIGNER, is de cryptografische hashwaarde van de publieke sleutel van de auteur van de toepassing die in de enclave draait [9].

Hoewel SGX-technologie is verwijderd uit Intels 12^e generatie Core-processors, blijft deze beschikbaar op 3^e generatie Xeon-processors [10]. Xeon-processors van de 4^e generatie ondersteunen TDX-technologie en zijn verkrijgbaar bij Intels erkende partners en verdelers.

We merken op dat het gebruik van SGX-technologie een grote herschrijving vereist van de bestaande toepassingen³. Het is noodzakelijk om de toepassing te partitioneren door te bepalen welk deel van de code toegang moet hebben tot gevoelige gegevens. Hoewel deze essentiële stap complex is, verbetert het in principe de veiligheid van de toepassing, omdat algemeen wordt aangenomen dat een kleine toepassing – in dit geval een toepassing die in de enclave draait – minder kans heeft op fouten en gemakkelijker te verifiëren is dan een grote. Communicatie tussen het beveiligde deel van de toepassing (binnen de enclave) en de rest van de toepassing (buiten de enclave) vindt plaats via aanroepen van functies die gedeclareerd moeten worden voordat de enclave wordt gelanceerd. Tenslotte kunnen toepassingen die geschreven zijn voor het SGX-platform niet gebruikt worden op andere platformen.

Leveranciers van IT-infrastructuren

Meerdere leveranciers van publieke IT-infrastructuren bieden vandaag oplossingen voor confidential computing gebaseerd op TEE’s. Hier beschrijven we de drie belangrijkste⁴.

AWS

Amazon definieert confidential computing als het gebruik van gespecialiseerde hardware en bijbehorende firmware om de code en gegevens van de klant tijdens de verwerking te beschermen tegen toegang van buitenaf. Amazon vertaalt dit in twee dimensies:

• Bescherming tegen de beheerder van de onderliggende IT-infrastructuur, in dit geval AWS;
• De mogelijkheid voor klanten om hun eigen workloads op te delen in meer of minder betrouwbare componenten, of om multi-agentsystemen te ontwerpen.

Amazon legt de nadruk op de architectuur van het Nitro-systeem, niet op de beschikbaarheid van een bepaalde microprocessor om een TEE te leveren. Sinds april 2023 biedt AWS echter ook de mogelijkheid om EC2-instanties te maken met AMD’s SEV-SNP-technologie (zie hier).

Het Nitro-systeem biedt volgens AWS geen enkel mechanisme waarmee systemen of personen verbinding kunnen maken met EC2-servers, het geheugen van EC2-instanties kunnen lezen of toegang kunnen krijgen tot opgeslagen gegevens. Onderhoudswerk kan alleen worden verricht via beperkte API’s.

Het AWS Nitro-systeem (Figuur 2) is onderdeel van een herziening van Amazons infrastructuur voor EC2-servicevirtualisatie, inclusief het minimaliseren van de onderdelen van de hypervisor die op het moederbord draait. Het AWS Nitro-systeem is een combinatie van servers, processors, beheercomponenten en gespecialiseerde firmware die het onderliggende platform vormt voor alle Amazon EC2-instanties. Het bestaat uit drie hoofdcomponenten:

• Specifieke Nitro Cards – Hardwareonderdelen ontworpen door AWS die zorgen voor algehele systeemcontrole en I/O-virtualisatie onafhankelijk van het moederbordvan het systeem met zijn processors en geheugen;
• Nitro-beveiligingschip – Deze is geïntegreerd in het moederbordvan de server en maakt veilig opstarten mogelijk op basis van een hardware root of trust, maakt het mogelijk om bare metal instances aan te bieden (waardoor de AWS-hypervisor overbodig wordt) en zorgt voor de bescherming van de server tegen ongeoorloofde wijzigingen in de firmware van het systeem;
• Nitro-hypervisor – Een geminimaliseerde, firmwareachtige hypervisor ontworpen om resource- en performance-isolatie te bieden.

Beveiligingsoverwegingen voor dit systeem staan gedetailleerd in [12].

Nitro enclaves daarentegen zijn geïsoleerde virtuele machines die draaien op een klassieke EC2-instantie, een zogenaamde ‘parent instance’ (Figuur 3).

Volgens AWS biedt de Nitro enclave geen extra beveiliging ten aanzien van een AWS-operator [13], maar kan wel worden voorkomen dat een client-side administrator toegang krijgt tot de inhoud van de enclave (code en gegevens).

De belangrijkste beperking van Nitro enclaves is dat de toepassing die in de enclave draait geen verbinding heeft met het netwerk. Ze kan alleen communiceren met de parent instance via een point-to-point interface genaamd ‘vsock’, die wordt gedefinieerd door een context identifier en een poortnummer⁵. Een eenvoudige ‘lift and shift’ is daarom niet mogelijk.

Wanneer het is aangemaakt, kan de toepassing die in de enclave draait een asymmetrisch sleutelpaar genereren en de publieke sleutel in het certificaat laten opnemen. Hierdoor kan de client-side applicatie die het attest verifieert deze sleutel gebruiken om beveiligde communicatie met de enclave tot stand te brengen.

Microsoft Azure

Microsoft Azure stelt drie types confidential computing voor gebaseerd op TEE’s:

• De toepassingsenclaves zijn gebaseerd op de SGX-technologie van Intel. Zoals eerder vermeld, is het noodzakelijk om de bestaande toepassingen grondig te wijzigen om ze aan te passen. Dit vereist veel denkwerk over welke delen van de toepassing beveiligd moeten worden en hun interactie met andere delen, maar het voordeel van deze aanpak is dat slechts een beknopte hoeveelheid code vertrouwd moet worden. Het nadeel is natuurlijk de complexiteit van de implementatie, die speciale training vereist voor analisten, architecten en programmeurs;
• De confidential virtual machines gebruiken AMD’s SEV-SNP-technologie (zie hier) en Microsoft kondigde in april 2023 aan dat ze binnenkort Intels TDX-technologie beschikbaar zou stellen (zie hier) [14]. Azure stelt tevens een ‘trusted platform module’ (TPM) voor, die met name wordt gebruikt voor het attesteren van virtual machines;
• De confidential containers geven de klant een preciezere mate van controle over de TCB dan virtuele machines. In principe maakt dit verpakkingsmodel het mogelijk om bestaande containers in een SGX enclave te draaien zonder dat de software aangepast of opnieuw gecompileerd hoeft te worden (“lift and shift”).

De optie om meerdere threads parallel te laten draaien (“hyper threading”-technologie) binnen dezelfde processor is uitgeschakeld op alle SGX instances. Dit voorkomt aanvallen die leiden tot datalekken tussen toepassingen die dezelfde processor delen.

Google

Google stelt verschillende manieren voor om confidential computing op zijn infrastructuur te implementeren:

• Confidential virtual machines maken gebruik van AMD’s technologie;
• Confidential Kubernetes nodes zijn ook gebaseerd op AMD’s SEV-technologie. De Kubernetes engine van Google kan het gebruik van confidential virtual machines voor alle Kubernetes nodes afdwingen.

Terwijl alle confidential virtual machines virtuele TPM’s bevatten die de integriteit van een virtuele machine valideren bij een gemeten opstart, bieden confidential virtual machines met SEV-SNP-technologie ook hardware cryptografisch ondertekende attestrapporten. SEV-SNP-technologie is echter nog niet algemeen beschikbaar op de infrastructuur van Google.

Praktische limiet van attesten

Zoals uitgelegd in ons vorige artikel, is een belangrijk punt bij het gebruik van TEE’s het verkrijgen van een garantie dat de software die draait op de gehuurde infrastructuur echt de software is die de klant verwacht en dat de gegevens die hij verwerkt niet kunnen worden gelezen door andere software. Deze garantie, een attest genoemd en verkregen via een betrouwbaar mechanisme, moet volledige, recente en semantisch expliciete informatie bevatten [15].

Ervan uitgaande dat we de fysieke veiligheid van de microprocessor of gespecialiseerde chip vertrouwen, dat bekende aanvallen zijn afgeweerd en dat de enclavecode niet kwetsbaar is voor side channel attacks, hoe kunnen we er dan zeker van zijn dat de output van een enclave betrouwbaar is?

Er moet voor gezorgd worden dat:

• De binary file die in de enclave wordt uitgevoerd, gebouwd is met de verwachte code. Hiervoor kan de klant zijn toepassing compileren op een vertrouwde machine (bijvoorbeeld een machine die hij bezit) en vervolgens de binary veilig kopiëren naar het confidential IT-platform. Een andere methode is om een reproducible build system⁶ te gebruiken;
• De binary file die wordt uitgevoerd overeenkomt met het verwachte binary. Een attestsysteem gebruikt cryptografische sleutels afgeleid van vaste geheimen in de vertrouwde microprocessor om een bewijs te ondertekenen dat de binary zich in een bepaalde toestand bevindt op echte hardware (geen simulatie). Het bewijs bevat een meting (cryptografische hashwaarde) van de binary;
• De staat van de toepassing bij het starten is de verwachte staat: het meten van het uitvoerbare deel van de binary is niet voldoende om het toekomstige gedrag te voorspellen;
• Het attest is ondertekend door een vertrouwde entiteit, in principe de fabrikant van de microprocessor of de beveiligde chip.

In de bestudeerde oplossingen, met uitzondering van SGX enclaves, wordt het attest echter ofwel ondertekend door de leverancier van de infrastructuur (en niet door de hardwarefabrikant), ofwel is het niet mogelijk om de meting van de beveiligde software te verifiëren omdat deze proprietary libraries bevat. Het risico bestaat dus dat de gecertificeerde entiteit liegt over haar status.

Conclusie

Tien jaar na de onthullingen van Edward Snowden in juni 2013, betreffende de Amerikaanse surveillancemethoden, moeten we ervan uitgaan dat informatie bemachtigd kan worden als deze voldoende waardevol is. De indruk dat nationale IT-infrastructuren veiliger zijn, kan daarom misleidend zijn⁷. Er bestaat namelijk een spanningsveld tussen het verlangen naar onafhankelijkheid van de IT-diensten van de Staat en het vermogen om het niveau van middelen (hardware, personeel, R&D), redundantie en beveiliging te evenaren dat aangeboden wordt door de dominante bedrijven in de sector⁸. Confidential computing gebaseerd op TEE’s brengt een nieuw argument ten voordele van publieke IT-infrastructuren.

Als ze correct worden geïmplementeerd, en alle andere zaken onveranderd blijven, kunnen TEE’s op basis van fysieke componenten het niveau van gegevensbescherming binnen een IT-infrastructuur aanzienlijk verhogen, met name ten opzichte van derden en in het bijzonder cybercriminelen⁹. Ze maken het in feite mogelijk om de meeste logische aanvallen te vermijden die conventionele systemen treffen, dankzij verbeterde procesisolatie, geheugenversleuteling via de hardwarelaag, veilig opstarten, controlemechanismen voor firmware-updates en, in het algemeen, een vermindering van de omvang van de trusted computing base. Met andere woorden, de veiligheidsmaatregelen opgenomen in de TEE’s maken een aanval aanzienlijk complexer en duurder.

Het aanbod van op TEE-gebaseerde confidential computing varieert tussen leveranciers, afhankelijk van het type abstractie dat wordt aangeboden: software library, container, virtuele machine. De keuze van deze opties leidt tot verschillen in de omvang van de trusted code base (en dus het oppervlak dat blootgesteld wordt aan aanvallen), maar ook in de inspanning die nodig is om bestaande toepassingen aan te passen aan deze nieuwe omgevingen.

Bij het kiezen van een op TEE-gebaseerde oplossing voor confidential computing moeten daarom de volgende punten worden gecontroleerd:

• Bescherming moet verankerd zijn in de fysieke laag van het systeem en elk apparaat moet een unieke identiteit hebben;
• Het attestmechanisme moet het mogelijk maken om de inhoud¹⁰ te verifiëren van de TEE op onafhankelijke wijze van de infrastructuurleverancier¹¹;
• Het attest moet ten minste ondertekend worden door de fabrikant van de fysieke component en niet alleen door de infrastructuurleverancier¹²;
• De dienst stelt ten minste in staat om eigen crypotografische sleutels te importeren in een toegewijde hardware-beveiligingsmodule (HSM), en in het beste geval om een eigen HSM te gebruiken;
• Het moet mogelijk zijn om de source code van de critical libraries die in de trust base zijn opgenomen door de infrastructuurleverancier te controleren op de goede werking van de klanttoepassing;
• De infrastructuurleverancier moet de klant een dienst ter beschikking stellen waarmee de verschillende software dependencies, compilatieomgevingen en binaries die voor de TEE worden gebruikt, kunnen worden getraceerd.

Tot slot is de gegevensbescherming aangeboden door confidential computing tijdens gebruik slechts één van de vele technische aspecten die in overweging moeten worden genomen met betrekking tot de vertrouwelijkheid van gevoelige gegevens (om nog maar te zwijgen van de juridische, economische en politieke aspecten). Net zoals het beste slot op de voordeur van een huis het probleem van een wijd openstaande achterdeur niet oplost, gaat het gebruik van confidential computing ervan uit dat gegevens in rust en in transit effectief worden beschermd, maar vereist het ook specifieke training voor de mensen die verantwoordelijk zijn voor het aanpassen (in meer of mindere mate afhankelijk van het gekozen type confidential computing) en migreren van bestaande toepassingen, in het bijzonder analisten, architecten en programmeurs.

Bibliografie

[1]        A. Linn, ‘Securing the cloud | Microsoft Story Labs’, Securing the cloud | Microsoft Story Labs, 2017. http://news.microsoft.com/stories/cloud-security (geraadpleegd 6 juni 2023).

[2]        M. U. Sardar en C. Fetzer, ‘Confidential computing and related technologies: a critical review’, Cybersecurity, vol. 6, nr. 1, p. 10, mei 2023, doi: 10.1186/s42400-023-00144-1.

[3]        D. Kaplan, ‘AMD x86 Memory Encryption Technologies’, augustus 2016. Geraadpleegd: 11 mei 2023. [Online]. Beschikbaar op: https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/kaplan

[4]        D. Kaplan, J. Powell, en T. Woller, ‘AMD Memory Encryption’, White Paper, okt. 2021. Geraadpleegd: 1 mei 2023. [Online]. Beschikbaar op: https://www.amd.com/system/files/TechDocs/memory-encryption-white-paper.pdf

[5]        ‘AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and More’, AMD, jan. 2020.

[6]        ‘Secure Encrypted Virtualisation API Version 0.24’, Specification, apr. 2020. [Online]. Beschikbaar op: https://www.amd.com/system/files/TechDocs/55766_SEV-KM_API_Specification.pdf

[7]        Victor Costan en Srinivas Devadas, ‘Intel SGX Explained’. Cryptology ePrint Archive, 2016. [Online]. Beschikbaar op: https://eprint.iacr.org/2016/086

[8]        P.-C. Cheng e.a., ‘Intel TDX Demystified: A Top-Down Approach’. arXiv, 27 maart 2023. Geraadpleegd: 23 mei 2023. [Online]. Beschikbaar op: http://arxiv.org/abs/2303.15540

[9]        ‘Intel 64 and IA-32 Architectures Software Developer’s Manual, Combined Volumes: 1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D, and 4’. Intel Corporation, maart 2023. [Online]. Beschikbaar op: https://cdrdv2.intel.com/v1/dl/getContent/671200

[10]       A. Rao, ‘Rising to the Challenge — Data Security with Intel Confidential Computing’, 20 januari 2022. https://community.intel.com/t5/Blogs/Products-and-Solutions/Security/Rising-to-the-Challenge-Data-Security-with-Intel-Confidential/post/1353141 (geraadpleegd 17 mei 2023).

[11]       G. Steer, ‘Finance’s big tech problem’, Financial Times, 6 juli 2022. Geraadpleegd: 10 juli 2023. [Online]. Beschikbaar op: https://www.ft.com/content/41f400b6-f83f-4fa1-8dac-731acddcf8f2

[12]       ‘The Security Design of the AWS Nitro System – AWS Whitepaper’. AWS, 18 november 2022. [Online]. Beschikbaar op: https://docs.aws.amazon.com/fr_fr/whitepapers/latest/security-design-of-aws-nitro-system/security-design-of-aws-nitro-system.html

[13]       ‘Confidential computing: an AWS perspective | AWS Security Blog’, 24 augustus 2021. https://aws.amazon.com/blogs/security/confidential-computing-an-aws-perspective/ (geraadpleegd 18 april 2023).

[14]       M. McReynolds, ‘Preview: Introducing DCesv5 and ECesv5-series Confidential VMs with Intel TDX’, 24 april 2023. https://techcommunity.microsoft.com/t5/azure-confidential-computing/preview-introducing-dcesv5-and-ecesv5-series-confidential-vms/ba-p/3800718 (geraadpleegd 16 mei 2023).

[15]       G. Coker e.a., ‘Principles of remote attestation’, Int. J. Inf. Secur., vol. 10, nr. 2, pp. 63-81, jun. 2011, doi: 10.1007/s10207-011-0124-7.

[16]       ‘Nix & NixOS | Reproducible builds and deployments’. https://nixos.org/ (geraadpleegd 6 juni 2023).

[17]       R. Gallagher, ‘The Inside Story of How British Spies Hacked Belgium’s Largest Telco’, The Intercept, 13 december 2014. https://theintercept.com/2014/12/13/belgacom-hack-gchq-inside-story/ (geraadpleegd 8 juni 2023).

[18]       R. Gallagher, ‘How U.K. Spies Hacked a European Ally and Got Away With It’, The Intercept, 17 februari 2018. https://theintercept.com/2018/02/17/gchq-belgacom-investigation-europe-hack/ (geraadpleegd 8 juni 2023).

[19]       C. Zhao, ‘SolarWinds, Probably Hacked by Russia, Serves White House, Pentagon, NASA’, Newsweek, 14 december 2020. Geraadpleegd: 9 januari 2023. [Online]. Beschikbaar op: https://www.newsweek.com/solar-winds-probably-hacked-russia-serves-white-house-pentagon-nasa-1554447

[20]       R. Koppel en C. Kuziemsky, ‘Healthcare Data Are Remarkably Vulnerable to Hacking: Connected Healthcare Delivery Increases the Risks’, Stud. Health Technol. Inf., vol. 257, pp. 218-222, 2019.

Noten

¹   Bijvoorbeeld: de term “enclave” heeft een compleet andere betekenis bij Amazon en Intel. Waar “Nitro Enclaves” volledig virtuele machines zijn, zijn de “SGX Enclaves” bibliotheken die bepaalde API’s beschikbaar stellen.

²   We moeten opmerken dat NVIDIA onlangs een grafische processor heeft aangeboden (A100 Tensor Core met de technologie Ampere Protected Memory (APM)) die een vertrouwelijke uitvoeringsmodus introduceert in de grafische processor. Deze maakt het mogelijk om datasets te gebruiken en zo modellen voor machine learning op een vertrouwelijke manier te trainen en in te zetten, met name op een publieke IT-infrastructuur. Deze processors zijn beschikbaar op de Azure-cataloog van Microsoft.

³   Dit is niet het geval met TDX, die een hele virtuele machine kan beschermen.

⁴   Volgens de Financial Times waren de drie belangrijkste leveranciers van IT-infrastructuur in 2021 Amazon, Microsoft en Google [11].

⁵   Deze ‘vsock’ gebruikt dezelfde API als POSIX ‘sockets’.

⁶   Bijvoorbeeld Nix [16].

⁷   In 2014 kwamen we te weten dat GCHQ, de Britse surveillanceagentschap, een gevoelig systeem van Belgacom had gehackt [17], [18].

⁸   Cybercriminele groepen aarzelen niet langer om de veiligheid van IT-services te ondermijnen door nieuwe soorten aanvallen uit te zetten. Het voorbeeld van hacking van SolarWind is in dit opzicht symptomatisch [19]. Een nationaal onafhankelijke, maar onvoldoende beveiligde dienst zou een single point of failure vormen die een kritiek risico inhoudt.

⁹   “Gezondheidsgegevens zijn aantrekkelijk voor cybercriminelen omdat ze financiële en persoonlijke gegevens bevatten, die gebruikt kunnen worden voor chantage en bovenal ideaal zijn voor frauduleuze facturering” [20].

¹⁰   Deze inhoud omvat, in het geval van confidential virtual machines, ook het besturingssysteem dat een minimale grootte moet hebben.

¹¹ Als de infrastructuurleverancier gedeeltelijk de inhoud controleert van de confidential virtual machine of de confidential container en dat de klant geen mechanisme heeft om dit te verifiëren, dan blijft het vertrouwen in de leverancier ongeschonden.

¹² Indien de infrastructuurleverancier het attest ondertekent, dan blijft het vertrouwen in deze leverancier totaal.

_________________________
Dit is een ingezonden bijdrage van Fabien A. P. Petitcolas, IT-beveiligingsspecialist bij Smals Research. Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Pour répondre à la demande de leurs clients traitant des données sensibles ou attirer de nouveaux clients, les fournisseurs d’infrastructures informatiques publiques mettent d’importants moyens en œuvre afin d’améliorer leur sécurité et notamment de mieux protéger les données de leurs clients. Microsoft, par exemple, déclare investir environ un milliard de dollars chaque année dans la sécurité de ses infrastructures [1]. Depuis le milieu des années 2010, ces fournisseurs d’infrastructures investissent notamment dans une offre d’informatique confidentielle. Principalement basée sur des environnements d’exécution de confiance (« Trusted Execution Environments (TEE) »), celle-ci permet en principe de réduire la confiance accordée par le client au fournisseur d’infrastructure.

Dans un article précédent, nous avons présenté de manière générale ce qu’étaient ces TEE et leur utilité. Dans cet article nous regardons plus en détail le fonctionnement des principales mises en œuvre commerciales. Cependant, il convient de garder à l’esprit que les définitions d’informatique confidentielle et de TEE diffèrent et sont parfois incomplètes. Cela peut conduire à un faux sens de sécurité, à des incertitudes légales et à rendre les comparaisons difficiles [2]. Afin de répondre à ce manque de standardisation et d’interopérabilité entre les différentes approches d’informatique confidentielle, le « Confidential Computing Consortium » a été créé par des acteurs importants du secteur, dont AMD, Google, Intel, et Microsoft. Il est à noter qu’Amazon ne fait pas partie de ce regroupement et que son système Nitro (voir ici) est très différent des autres approches¹.

Une version plus approfondie de cet article, réservée aux clients de Smals, est disponible sur demande.

Fabricants de microprocesseurs

AMD et Intel sont les deux principaux fabricants de microprocesseurs offrant des fonctionnalités nécessaires à l’informatique confidentielle dans de larges centres informatiques². Alors que les techniques TDX d’Intel et SEV-SNP d’AMD ont pour but de protéger des machines virtuelles (VM) entières, la techniques SGX est très différente et sa surface d’exposition aux attaques plus faible. La Figure 1 montre les éléments faisant partie de la base informatique de confiance (« Trusted Computing Base (TCB) ») pour ces trois techniques que nous décrivons dans les paragraphes suivants.

Technique SEV-SNP d’AMD

En 2016, AMD a introduit la technique de virtualisation sécurisée par chiffrement (« Secure Encrypted Virtualisation (SEV) ») afin d’isoler les VM de l’hyperviseur au niveau matériel [3], [4]. Chaque VM reçoit sa propre clé de chiffrement AES pour le chiffrement de la mémoire. L’état des registres du microprocesseur de chaque VM est également chiffré, empêchant l’hyperviseur de lire les données contenues dans la VM. Par la suite, AMD a ajouté une technique de pagination imbriquée sécurisée (« Secure Nested Paging (SNP) ») offrant une protection de l’intégrité de la mémoire, et permettant d’empêcher les attaques d’un hyperviseur malicieux (par ex. attaques par rejeu, reconfiguration du mécanisme de traduction de mémoire virtuelle, corruption des données mémoires) [5]. Le principe fondamental de SEV-SNP est que si une VM est en mesure de lire une page mémoire lui étant réservée (et donc chiffrée), alors elle doit toujours lire la dernière valeur qu’elle a elle-même écrite. Par ailleurs dans le modèle de sécurité utilisé pour SNP, seule la VM du client et le microprocesseur AMD font partie de la base de confiance. N’en font donc pas partie l’hyperviseur, le BIOS, les autres VM, etc. (voir Figure 1). Enfin, une option de SEV-SNP permet aux VM de diviser, d’une manière similaire aux anneaux de protection dans l’architecture x86, leur mémoire virtuelle en quatre niveaux de privilèges (« Virtual Machine Privilege Levels (VMPL) »).

Le mécanisme d’attestation à distance d’AMD, permet de vérifier que la machine hôte est bien un processeur AMD qui prend en charge la technique SEV-SNP et qu’une VM a bien été déployée avec la protection SEV-SNP. Chaque processeur AMD, contient un coprocesseur sécurisé qui permet de générer une paire de clés dédiées (« Platform Endorsement Key (PEK) »), elle-même signée par une clé unique dérivée de secrets enregistrés grâce à des fusibles dans la puce elle-même. Cette PEK est également indirectement utilisée pour établir un secret partagé entre la plate-forme SEV et le client [6]. Au moment du lancement par l’hyperviseur de la VM sécurisée sur la plate-forme SEV, le micrologiciel (« firmware ») SEV calcule la mesure (valeur du hachage cryptographique) de la mémoire de la VM. Cette mesure peut être communiquée de manière sécurisée au client afin qu’il vérifie que la VM déployée n’a pas été altérée.

La technique SEV-SNP est disponible sur les processeurs AMD EPYC de 3^e génération (série 7003) et 4^e génération (série 9004). On peut trouver ces processeurs chez différents fournisseurs comme Dell (serveurs « PowerEdge »), Lenovo ou HP. Les prix varient de quelques milliers à plusieurs dizaines de milliers d’euros en fonction de la configuration.

Technique SGX et TDX d’Intel

Introduit en 2015, le système « Software Guard eXtensions (SGX) » d’Intel permet à un logiciel de définir des zones de mémoire protégées pour des « enclaves » sécurisées isolées des autres processus fonctionnant sur la même machine (noyaux du système d’exploitation, hyperviseur, etc.) ainsi que des accès directs par des périphériques. Le processeur s’assure que chaque enclave a sa zone mémoire dédiée et chiffrée, enregistrant chaque allocation par le système d’exploitation [7]. Une enclave est générée en tant que bibliothèque partagée dynamiquement à l’aide d’outils de compilation standards. Lors de l’initialisation d’une enclave, le système d’exploitation demande au processeur de copier l’application dans des pages mémoire de la zone protégée chiffrée. Lors de ce chargement en mémoire, le processeur calcule une mesure de l’application. Cela permet par la suite de vérifier l’intégrité de l’application par un mécanisme d’attestation. Intel a introduit en 2020, la technique « Trusted Domain Extensions (TDX), » qui est un module logiciel signé, exécuté dans un nouveau mode du processeur et qui permet de protéger et d’isoler cryptographiquement des machines virtuelles. Plus de détails sur le fonctionnement et l’architecture de TDX peuvent être trouvés dans [8].

Deux types d’attestation à distance sont disponibles avec SGX « Enhanced Privacy ID (EPID) » et « Data Centre Attestation Primitives (DCAP). » Le premier est un mode d’attestation dans lequel le serveur d’attestation d’Intel doit être contacté pour obtenir des informations sur l’enclave requérante. Le second ne nécessite pas de contacter le serveur d’attestation d’Intel. Durant le processus de construction d’une enclave, deux mesures sont faites. MRENCLAVE est la valeur de hachage cryptographique de la disposition de la mémoire virtuelle assignée à l’enclave au moment de son lancement. L’autre mesure, MRSIGNER, est la valeur de hachage cryptographique de la clé publique de l’auteur de l’application fonctionnant dans l’enclave [9].

Alors que la technique SGX a été retirée de la 12^e génération des processeurs Core d’Intel, elle reste disponible sur la 3^e génération de processeurs Xeon [10]. Les processeurs Xeon de 4^e génération prennent en charge la technique TDX et sont disponibles chez les partenaires et distributeurs agréés d’Intel.

Notons que l’utilisation de la technique SGX demande une réécriture importante des applications existantes³. Il est en effet nécessaire de partitionner l’application en identifiant quelle partie du code doit pouvoir avoir accès aux données sensibles. Bien que cette étape essentielle soit complexe, elle permet en principe d’améliorer la sécurité de l’application étant donné qu’il est généralement accepté qu’une application de petite taille – en l’occurrence celle fonctionnant dans l’enclave – a moins de chances d’avoir des défauts tout en étant plus facilement vérifiable qu’une application de grande taille. La communication entre la partie sécurisée de l’application (dans l’enclave) et le reste de l’application (en dehors de l’enclave) se fait via des appels à des fonctions devant être déclarées avant le lancement de l’enclave. Enfin, les applications écrites pour la plate-forme SGX ne peuvent pas être utilisées sur d’autres plates-formes.

Fournisseurs d’infrastructures informatique

Plusieurs fournisseurs d’infrastructures informatiques publiques proposent aujourd’hui des solutions d’informatique confidentielle basées sur les TEE. Nous décrivons ici les trois principaux⁴.

AWS

Amazon définit l’informatique confidentielle comme l’utilisation de matériel spécialisé et de micrologiciels associés pour protéger le code et les données du client pendant le traitement contre tout accès extérieur. Amazon traduit cela selon deux dimensions :

• La protection vis-à-vis de de l’opérateur de l’infrastructure informatique sous-jacente, en l’occurrence AWS ;
• La capacité des clients à diviser leurs propres charges de travail en composants plus ou moins fiables, ou à concevoir des systèmes multi-agents.

L’accent est mis par Amazon sur l’architecture du système Nitro, plutôt que sur la disponibilité d’un microprocesseur particulier en charge de fournir un TEE. Cependant, depuis avril 2023, AWS offre aussi la possibilité de créer des instances EC2 avec la technique SEV-SNP d’AMD (voir ici).

Dans sa conception, selon AWS, le système Nitro n’offre aucun mécanisme permettant à un système ou à une personne de se connecter aux serveurs EC2, de lire la mémoire des instances EC2 ou d’accéder aux données stockées. Les travaux de maintenance ne peuvent se faire qu’à travers des API limitées.

Le système AWS Nitro (Figure 2) s’inscrit dans une refonte de l’infrastructure de virtualisation du service EC2 d’Amazon, notamment réduire au maximum les parties de l’hyperviseur fonctionnant sur la carte mère. Le système AWS Nitro est une combinaison de serveurs, de processeurs, de composants de gestion et de micrologiciels spécialisés qui fournissent la plate-forme sous-jacente pour toutes les instances Amazon EC2. Il se compose de trois éléments principaux :

• Cartes Nitro spécifiques – Dispositifs matériels conçus par AWS qui assurent le contrôle global du système et la virtualisation des entrées/sorties indépendamment de la carte mère du système avec ses processeurs et sa mémoire ;
• La puce de sécurité Nitro – Celle-ci est intégrée à la carte mère du serveur et permet un démarrage sécurisé basé sur une racine de confiance matérielle, la capacité d’offrir des instances « bare metal » (permettant de se passer de l’hyperviseur d’AWS), ainsi qu’une protection du serveur contre les modifications non autorisées du micrologiciel du système ;
• L’hyperviseur Nitro – Un hyperviseur minimisé, semblable à un micrologiciel, conçu pour fournir une isolation des ressources et des performances.

Les considérations de sécurité de ce système sont détaillées dans [12].

Les enclaves Nitro, quant à elles, sont des machines virtuelles isolées fonctionnant avec une instance EC2 classique, appelée instance « parent » (Figure 3).

Selon AWS, l’enclave Nitro n’offre pas de sécurité supplémentaire vis-à-vis d’une opératrice d’AWS [13], mais permet en revanche d’empêcher un administrateur du client d’accéder au contenu de l’enclave (code et données).

La contrainte principale imposée par les enclaves Nitro est que l’application fonctionnant dans l’enclave n’a pas de connexion au réseau. Elle peut seulement communiquer avec l’instance parent via une interface point à point appelée « vsock » qui est définie par un identifiant de contexte et un numéro de port⁵. Un simple « lift and shift » n’est donc pas possible.

Au moment de sa création, l’application fonctionnant dans l’enclave peut générer une paire de clés asymétriques et faire inclure la clé publique dans l’attestation. Par conséquent l’application client vérifiant l’attestation peut utiliser cette clé afin d’établir une communication sécurisée avec l’enclave.

Microsoft Azure

Microsoft Azure propose trois types d’informatique confidentielle basée sur les TEE :

• Les enclaves d’applications sont basées sur la technique SGX d’Intel. Comme indiqué précédemment, il est nécessaire de modifier en profondeur les applications existantes afin de les adapter. Cela impose une réflexion importante sur le choix des parties de l’application à sécuriser et de leur interaction avec les autres parties, mais l’avantage de cette approche est de réduire la quantité de code auquel il faut faire confiance. L’inconvénient est bien évidemment la complexité de la mise en œuvre, requérant notamment une formation particulière des analystes, architectes et programmeurs ;
• Les machines virtuelles confidentielles utilisent la technique SEV-SNP d’AMD (voir ici) et Microsoft a annoncé en avril 2023, la mise à disposition prochaine de la technique TDX d’Intel (voir ici) [14]. Azure met également à disposition un module de plate-forme fiable (« trusted platform module (TPM) ») utilisé notamment pour l’attestation des machines virtuelles ;
• Les conteneurs confidentiels permettent au client d’avoir un niveau de contrôle plus fin que les machines virtuelles sur la TCB. Ce modèle d’empaquetage permet en principe d’exécuter des conteneurs existants dans une enclave SGX sans devoir modifier ou recompiler le logiciel (« lift-and-shift »).

L’option permettant l’existence de plusieurs fils d’exécution en parallèle (technique « hyper-threading ») au sein du même processeur est désactivée sur toutes les instances SGX. Cela permet d’éviter des attaques conduisant à des fuites de données entre applications partageant le même processeur.

Google

Google propose différentes façons de mettre en œuvre l’informatique confidentielle sur son infrastructure :

• Les machines virtuelles confidentielles utilisent la technique d’AMD ;
• Les nœuds Kubernetes confidentiels reposent également sur la technique SEV d’AMD. Le moteur Kubernetes de Google peut imposer l’utilisation de machines virtuelles confidentielles pour tous les nœuds Kubernetes.

Alors que toutes les machines virtuelles confidentielles contiennent des TPM virtuels qui valident l’intégrité d’une machine virtuelle avec le démarrage mesuré, les machines virtuelles confidentielles avec la technique SEV-SNP offrent également des rapports d’attestation signés cryptographiquement par le matériel. Cependant la technique SEV-SNP n’est pas encore disponible de manière généralisée sur l’infrastructure de Google.

Limite pratique des attestations

Comme nous l’expliquions dans notre article précédent, un point essentiel de l’utilisation des TEE est d’obtenir la garantie que le logiciel fonctionnant sur l’infrastructure louée est réellement le logiciel auquel s’attend le client et que les données qu’il traite ne peuvent être lues par aucun autre logiciel. Cette garantie, appelée attestation et obtenue à travers un mécanisme fiable, devrait contenir des informations complètes, récentes et explicites sur le plan sémantique [15].

En supposant que l’on fasse confiance à la sécurité physique du microprocesseur ou de la puce spécialisée, que les attaques connues ont été atténuées et que le code de l’enclave n’est pas vulnérable aux attaques par canaux auxiliaires (« side-channel attacks »), comment peut-on être certain que la sortie d’une enclave est fiable?

Il faut s’assurer que :

• Le fichier binaire exécuté dans l’enclave a bien été construit avec le code attendu. Pour ce faire le client peut compiler son application sur une machine de confiance (par ex. lui appartenant), puis copier le binaire de manière sécurisée sur la plate-forme d’informatique confidentielle. Une autre méthode est d’utiliser un outil de compilation reproductible⁶ ;
• Le fichier binaire en cours d’exécution correspond bien au binaire attendu. Un système d’attestation utilise des clés cryptographiques dérivées de secrets figés dans le microprocesseur de confiance pour signer une preuve que le binaire est dans un état donné sur un véritable matériel (pas une simulation). La preuve contient une mesure (valeur de hachage cryptographique) du binaire ;
• L’état de l’application au moment de son démarrage est celui attendu ” la mesure de la partie exécutable du binaire n’est pas suffisante pour prédire son comportement futur ;
• L’attestation est signée par une entité de confiance, en principe par le fabricant du microprocesseur ou de la puce sécurisée.

Pourtant dans les solutions étudiées, à l’exception des enclaves SGX, soit l’attestation est signée par le fournisseur de l’infrastructure (et non par le fabricant du matériel), soit il n’est pas possible de vérifier la mesure du logiciel sécurisé car il inclut des bibliothèques propriétaires. Le risque est donc que l’entité attestée mente sur son état.

Conclusion

Dix ans après les révélations d’Edward Snowden en juin 2013, concernant les méthodes de surveillance des États-Unis, nous devons partir du principe que des informations pourront être obtenues si elles sont suffisamment précieuses. L’impression de plus grande sécurité des infrastructures informatiques nationales peut alors être trompeuse⁷. Il existe en effet une tension entre une volonté d’indépendance des services informatiques étatiques et la capacité à égaler les niveaux de ressources (matérielles, humaines, R&D), de redondance et de sécurité qu’offrent les entreprises dominantes du secteur⁸. L’ajout de l’informatique confidentielle basée sur des TEE ajoute un nouvel argument en faveur des infrastructures informatiques publiques.

Lorsqu’ils sont mis en œuvre correctement, et toutes autres choses égales par elles-mêmes, les TEE fondés sur des composants physiques permettent d’augmenter significativement le niveau de protection des données au sein d’une infrastructure informatique, en particulier vis-à-vis de tiers, et notamment de cybercriminels⁹. En effet ils permettent d’éviter la plupart des attaques logiques affectant les systèmes habituels, et ce, grâce à une meilleure isolation des processus, un chiffrement de la mémoire par la couche matérielle, un démarrage sécurisé, des mécanismes de contrôle de mise à jour du micrologiciel, et, d’une manière générale à une réduction de la taille de la base informatique de confiance. En d’autres termes les mesures de sécurité mises en place dans les TEE rendent une attaque beaucoup plus complexe et coûteuse.

Les offres d’informatiques confidentielles basées sur des TEE varient entre les fournisseurs, notamment en fonction du type d’abstraction offert : librairie logicielle, conteneur, machine virtuelle. Le choix de ces options conduit à des différences dans la taille du code de la base de confiance (et donc de la surface exposée aux attaques), mais également dans l’effort d’adaptation nécessaire des applications existantes à ces nouveaux environnements.

Lors du choix d’une solution d’informatique confidentielle basée sur les TEE, il conviendra donc de vérifier les points suivants :

• La protection doit être ancrée dans la couche physique du système et chaque appareil doit avoir une identité unique ;
• Le mécanisme d’attestation doit permettre de pouvoir vérifier le contenu¹⁰ du TEE de manière indépendante du fournisseur d’infrastructure¹¹;
• L’attestation doit être signée au moins par le fabricant du composant physique et pas uniquement par le fournisseur d’infrastructure¹²;
• Le service permet au minimum d’importer ses propres clés cryptographiques dans une boîte noire transactionnelle (HSM) dédiée, et au mieux d’utiliser sa propre boîte ;
• Il devrait être possible de vérifier le code source des librairies critiques incluses par le fournisseur d’infrastructure dans la base de confiance pour le bon fonctionnement de l’application du client ;
• Un service permettant de traquer les différentes dépendances logicielles, d’environnement de compilation, et des binaires utilisés pour le TEE devrait être mis à disposition du client par le fournisseur d’infrastructure.

Finalement, la protection des données en cours d’utilisation permise par l’informatique confidentielle ne représente qu’un des multiples aspects techniques à considérer concernant la confidentialité des données sensibles (sans compter les aspects juridiques, économiques et politiques). Tout comme la meilleure serrure sur la porte d’entrée principale d’une maison ne résout pas le problème d’une porte secondaire grande ouverte, l’utilisation de l’informatique confidentielle suppose que les données sont effectivement protégées au repos et en mouvement, mais requiert également une formation spécifique des personnes en charge de l’adaptation (plus ou moins importantes en fonction du type d’informatique confidentielle choisie) et du transfert des applications existantes, notamment les analystes, architectes, et programmeurs.

Bibliographie

[1]        A. Linn, « Securing the cloud | Microsoft Story Labs », Securing the cloud | Microsoft Story Labs, 2017. http://news.microsoft.com/stories/cloud-security (consulté le 6 juin 2023).

[2]        M. U. Sardar et C. Fetzer, « Confidential computing and related technologies: a critical review », Cybersecurity, vol. 6, n^o 1, p. 10, mai 2023, doi: 10.1186/s42400-023-00144-1.

[3]        D. Kaplan, « AMD x86 Memory Encryption Technologies », août 2016. Consulté le: 11 mai 2023. [En ligne]. Disponible sur: https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/kaplan

[4]        D. Kaplan, J. Powell, et T. Woller, « AMD Memory Encryption », White Paper, oct. 2021. Consulté le: 1 mai 2023. [En ligne]. Disponible sur: https://www.amd.com/system/files/TechDocs/memory-encryption-white-paper.pdf

[5]        « AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and More », AMD, janv. 2020.

[6]        « Secure Encrypted Virtualisation API Version 0.24 », Specification, avr. 2020. [En ligne]. Disponible sur: https://www.amd.com/system/files/TechDocs/55766_SEV-KM_API_Specification.pdf

[7]        Victor Costan et Srinivas Devadas, « Intel SGX Explained ». Cryptology ePrint Archive, 2016. [En ligne]. Disponible sur: https://eprint.iacr.org/2016/086

[8]        P.-C. Cheng et al., « Intel TDX Demystified: A Top-Down Approach ». arXiv, 27 mars 2023. Consulté le: 23 mai 2023. [En ligne]. Disponible sur: http://arxiv.org/abs/2303.15540

[9]        « Intel 64 and IA-32 Architectures Software Developer’s Manual, Combined Volumes: 1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D, and 4 ». Intel Corporation, mars 2023. [En ligne]. Disponible sur: https://cdrdv2.intel.com/v1/dl/getContent/671200

[10]       A. Rao, « Rising to the Challenge — Data Security with Intel Confidential Computing », 20 janvier 2022. https://community.intel.com/t5/Blogs/Products-and-Solutions/Security/Rising-to-the-Challenge-Data-Security-with-Intel-Confidential/post/1353141 (consulté le 17 mai 2023).

[11]       G. Steer, « Finance’s big tech problem », Financial Times, 6 juillet 2022. Consulté le: 10 juillet 2023. [En ligne]. Disponible sur: https://www.ft.com/content/41f400b6-f83f-4fa1-8dac-731acddcf8f2

[12]       « The Security Design of the AWS Nitro System – AWS Whitepaper ». AWS, 18 novembre 2022. [En ligne]. Disponible sur: https://docs.aws.amazon.com/fr_fr/whitepapers/latest/security-design-of-aws-nitro-system/security-design-of-aws-nitro-system.html

[13]       « Confidential computing: an AWS perspective | AWS Security Blog », 24 août 2021. https://aws.amazon.com/blogs/security/confidential-computing-an-aws-perspective/ (consulté le 18 avril 2023).

[14]       M. McReynolds, « Preview: Introducing DCesv5 and ECesv5-series Confidential VMs with Intel TDX », 24 avril 2023. https://techcommunity.microsoft.com/t5/azure-confidential-computing/preview-introducing-dcesv5-and-ecesv5-series-confidential-vms/ba-p/3800718 (consulté le 16 mai 2023).

[15]       G. Coker et al., « Principles of remote attestation », Int. J. Inf. Secur., vol. 10, n^o 2, p. 63‑81, juin 2011, doi: 10.1007/s10207-011-0124-7.

[16]       « Nix & NixOS | Reproducible builds and deployments ». https://nixos.org/ (consulté le 6 juin 2023).

[17]       R. Gallagher, « The Inside Story of How British Spies Hacked Belgium’s Largest Telco », The Intercept, 13 décembre 2014. https://theintercept.com/2014/12/13/belgacom-hack-gchq-inside-story/ (consulté le 8 juin 2023).

[18]       R. Gallagher, « How U.K. Spies Hacked a European Ally and Got Away With It », The Intercept, 17 février 2018. https://theintercept.com/2018/02/17/gchq-belgacom-investigation-europe-hack/ (consulté le 8 juin 2023).

[19]       C. Zhao, « SolarWinds, Probably Hacked by Russia, Serves White House, Pentagon, NASA », Newsweek, 14 décembre 2020. Consulté le: 9 janvier 2023. [En ligne]. Disponible sur: https://www.newsweek.com/solar-winds-probably-hacked-russia-serves-white-house-pentagon-nasa-1554447

[20]       R. Koppel et C. Kuziemsky, « Healthcare Data Are Remarkably Vulnerable to Hacking: Connected Healthcare Delivery Increases the Risks », Stud. Health Technol. Inf., vol. 257, p. 218‑222, 2019.

Notes

¹   Par exemple le terme « enclave » n’a pas du tout le même sens chez Amazon et Intel. Alors que les « Nitro Enclaves » sont des machines virtuelles entières, les « SGX Enclaves » sont des bibliothèques exposant certaines API.

²   Notons que NVIDIA offre depuis peu un processeur graphique (A100 Tensor Core avec la technique « Ampere Protected Memory (APM) ») qui introduit un mode d’exécution confidentielle dans le processeur graphique et permet ainsi d’utiliser des ensembles des données pour former et déployer des modèles d’apprentissage automatique (« machine learning ») de manière confidentielle, notamment sur une infrastructure informatique publique. Ces processeurs sont disponibles sur l’offre Azure de Microsoft.

³   Ce n’est pas le cas avec TDX qui permet de protéger une machine virtuelle entière.

⁴   Selon le Financial Times, les trois fournisseurs d’infrastructure informatique les plus importants en 2021 étaient Amazon, Microsoft et Google [11].

⁵   Cette « vsock » utilise la même API que les « sockets » POSIX.

⁶   Par exemple Nix [16].

⁷   Nous avons appris en 2014 que l’agence de surveillance britannique GCHQ avait piraté un système sensible de Belgacom [17], [18].

⁸   Les groupes cybercriminels n’hésitent plus à compromettre la sécurité de services informatiques en mettant en œuvre de nouveaux types d’attaques. L’exemple du piratage de SolarWind est symptomatique à cet égard [19]. Un service indépendant national mais insuffisamment sécurisé pourrait représenter un point de défaillance unique posant un risque crucial.

⁹   « Les données de santé sont attrayantes pour les cybercriminels car elles contiennent des données financières et personnelles, peuvent être utilisées pour le chantage et, surtout, sont idéales pour la facturation frauduleuse » [20].

¹⁰ Ce contenu, dans le cas de machines virtuelles confidentielles, inclut également le système d’exploitation que l’on préférera de taille minimale.

¹¹ Si le fournisseur d’infrastructure contrôle en partie le contenu de la machine virtuelle confidentielle ou du conteneur confidentiel et que le client n’a pas de mécanisme pour le vérifier, alors la confiance dans le fournisseur reste totale.

¹² Si le fournisseur d’infrastructure signe l’attestation, alors la confiance dans ce fournisseur reste totale.

_________________________

Ce post est une contribution individuelle de Fabien A. P. Petitcolas, spécialisé en sécurité informatique chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals.

On considère généralement que les données peuvent être dans trois états. Celles stockées, par exemple sur un disque dur ou dans une base de données, sont dites « au repos », celles envoyées d’un ordinateur à un autre, par exemple via un réseau, sont « en mouvement, » et les données traitées par le microprocesseur sont « en cours d’utilisation  ».

Aujourd’hui, des primitives cryptographiques sont largement déployées pour protéger les données dans les deux premiers états, assurant intégrité et confidentialité. Cependant, le renforcement des réglementations sur la protection des données et de la vie privée et l’augmentation des cyber-menaces de longue durée a fait naître le besoin de protéger les données en cours d’utilisation.

Malheureusement cette protection des données en cours d’utilisation reste difficile, en particulier dans le contexte d’infrastructures informatiques partagées : il s’agit en effet d’exécuter un logiciel avec certaines garanties de sécurité sur un ordinateur distant qui peut être détenu et géré par une partie non fiable voire malintentionnée.

De nombreuses attaques

Les attaques possibles sont nombreuses.

Au niveau logiciel on compte toutes les attaques permettant de compromettre l’intégrité du système, que ce soit le système d’exploitation, l’hyperviseur ou le micrologiciel (« firmware »). Celles-ci sont rendues possibles via divers types de rançongiciels ou d’outils de piratage, via des pilotes de périphériques compromis, via l’exploitation d’une vulnérabilité du jour zéro, de l’injection d’erreurs logiques, ou encore, à cause d’employés malveillants ou de mauvaises pratiques de fabrication, etc. [1]–[8]. On compte également l’accès aux données à l’aide de canaux auxiliaires (« side-channel attacks »), ou celui dû à des erreurs de configuration ou de paramétrage du système. Enfin, plus rares, les attaques cryptographiques, suite à une analyse poussée d’un algorithme ou à l’exploitation d’une percée mathématique sont possibles.

Au niveau physique, on peut envisager une administratrice système ou un prestataire externe accédant sans autorisation au matériel, pouvant alors se connecter directement au circuit imprimé et copier des informations par accès direct à la mémoire vive (DIMM DMA), espionner le lien à débit de données double (DDR), surveiller le bus informatique et du cache, etc.

Techniques principales

L’informatique confidentielle (« confidential computing ») vise à apporter une solution technique à ces problèmes à travers trois méthodes principales :

• Les environnements d’exécution de confiance (« trusted execution environments » – TEE) s’appuient sur une combinaison de composants matériels sécurisés, de mécanismes d’attestation et de logiciels conçus pour utiliser ces fonctionnalités matérielles¹.
• Le chiffrement homomorphe (« homomorphic encryption » – HE), partiel ou total, concerne le calcul direct sur des données chiffrées [11] et peut aider pour certaines classes de problèmes, mais engendre un coût de par la surcharge de calcul liée au chiffrement spécifique [12].
• Le calcul multipartite sécurisé [13] (« secure multiparty computation » – MPC) est une classe de méthodes cryptographiques qui permet à des parties mutuellement méfiantes de calculer conjointement des fonctions sur leurs données d’entrée sans révéler celles-ci à d’autres parties. Ce type de calcul a déjà été décrit sur cet article de blog.

Bien entendu, il est possible de combiner ces techniques comme par exemple les environnements d’exécution de confiance avec le chiffrement homomorphe (par ex. [14]).

Dans la suite nous nous concentrerons sur le premier type d’informatique confidentielle : les environnements d’exécution de confiance.

Réduction de la surface d’exposition aux attaques

En règle générale, la pile complète d’une plateforme informatique est composée de plusieurs techniques provenant de nombreux fournisseurs différents, ce qui entraîne un manque de mise en œuvre cohérente des contrôles de sécurité.

Cependant, la couche physique matérielle sur laquelle l’ensemble du système est construit reste la première couche de protection. Par conséquent une façon d’améliorer la sécurité globale d’un système – y compris en empêchant l’accès aux données – est d’augmenter la sécurité de la partie physique.

C’est sur cet argument que se basent les TEE qui visent à protéger l’exécution du code des applications contre les attaques de code privilégié et certaines attaques physiques en réduisant la base d’information de confiance et la surface d’exposition aux attaques (Figure 1).

Dans certains cas, la petitesse du TEE permet l’application de méthodes formelles (basées sur des constructions mathématiques) et la vérification de la conformité de la mise en œuvre par rapport aux spécifications. Cela permet de renforcer le niveau de confiance placé dans le TEE.

Les TEE

Les TEE sont des systèmes de sécurité qui s’exécutent parallèlement aux environnements d’exécution réguliers (y compris le système d’exploitation comme Linux ou Windows). Ils fournissent une zone sûre pour protéger les actifs (par ex., les secrets sensibles, les chaînes d’authentification) et ont également pour but d’assurer que les opérations effectuées en leur sein et les données associées ne peuvent pas être visualisées à l’extérieur, pas même par un logiciel privilégié (par ex., hyperviseur, système d’exploitation) ou un débogueur. Combinés à un mécanisme d’attestation (voir ci-dessous) ils assurent que le code qu’ils exécutent ne peut pas être modifié ou remplacé sans l’autorisation de l’utilisateur.

Un TEE peut être utilisé pour fournir une isolation de mémoire, empêchant les applications partageant le même matériel sous-jacent de lire la mémoire allouée aux autres. Certains TEE permettent d’isoler des applications entières dans leurs propres enclaves plutôt que de protéger uniquement des opérations ou de la mémoire spécifique.

L’application des propriétés mentionnées ci-dessus est basée sur un matériel physique spécifique, en intégrant tout ou une partie des ressources nécessaires au bon fonctionnement du TEE dans un même boitier, ou en utilisant des ressources partagées par les autres composants disponibles sur le circuit imprimé de la machine (par ex. la mémoire vive). Dans ce dernier cas une isolation par chiffrement est nécessaire.

Tous les TEE ne sont pas identiques et différents fabricants peuvent proposer différentes mise en œuvre de TEE avec différentes propriétés de sécurité, différentes fonctionnalités et différents mécanismes de contrôle pour fonctionner sur les application sécurisées². En effet certains TEE s’adressent plutôt à des téléphones (par ex. la technique TrustZone d’ARM) tandis que d’autres à des ordinateurs de bureau ou des ordinateurs formant une infrastructure informatique partagée (par ex. les techniques SGX d’Intel ou SEV d’AMD).

Plusieurs fournisseurs d’infrastructure informatique publiques offrent la possibilité d’utiliser ces techniques à celles ou ceux ne disposant pas de ce matériel. Par exemple, Microsoft a le produit Azure Confidential Computing offrant SGX et SEV. Amazon, met en œuvre sa propre technique TEE appelée Nitro sur son infrastructure AWS.

Exigences de sécurité

Les TEE sont conçus pour résister à un large éventail de menaces logicielles du système d’exploitation standard, y compris les menaces au niveau du noyau (par ex. [16]) provenant d’un périphérique rooté ainsi qu’à certaines attaques physiques. Les TEE font l’objet d’une analyse de sécurité rigoureuse dans le cadre des « Critères communs » [17], [18], mais ils manquent encore généralement de défenses contre les attaques matérielles complexes. Par exemple, les attaques qui « nécessitent généralement un accès à long terme et/ou invasif au matériel, y compris les techniques de grattage de puces et les sondes de microscope électronique » sont explicitement hors du champ d’application des exigences du Confidential Computing Consortium [19].

Les exigences de sécurité d’un TEE se résument ainsi (voir [9] pour plus de détails) :

• L’objectif principal d’un TEE est de protéger ses actifs contre les attaques à travers le reste de l’environnement d’exécution. Ceci est réalisé grâce à des mécanismes matériels que ces autres environnements ne peuvent pas contrôler.
• Le TEE offre une protection contre certaines attaques physiques. Les attaques intrusives qui brisent physiquement la structure physique du circuit intégré ne sont pas considérées.
• L’environnement d’exécution du système d’exploitation de confiance est démarré à partir d’une racine de confiance (RoT) à l’intérieur du TEE via un processus de démarrage sécurisé.
• Le TEE fournit un stockage sécurisé des données et des clés cryptographiques. Ce stockage est lié à ce TEE particulier sur un appareil particulier.
• Les logiciels extérieurs au TEE ne peuvent pas appeler directement les fonctionnalités exposées par les interfaces internes du TEE et doivent passer par des protocoles de communication spécifiques permettant au système d’exploitation de confiance de vérifier l’acceptabilité de l’opération non-TEE demandée.

Vérification de l’intégrité

Un concept clé des TEE est la capacité de l’utilisateur à vérifier l’intégrité de la plateforme sous-jacente. Cela est généralement réalisé grâce à deux composantes : le hachage des différents modules logiciels et la vérification du micrologiciel. Dans le cadre d’infrastructures informatiques partagées, il est nécessaire de pouvoir effectuer cette vérification à distance.

Hachage et signature des modules

Les hachages cryptographiques (également souvent appelés « mesures » dans le contexte des TEE) du logiciel, du micrologiciel et des fichiers de configuration associés, sous-tendent la création d’une chaîne de confiance. Chacune de ces chaînes de confiance commence par un module racine de confiance qui doit être aussi petit que possible. Il peut prendre la forme d’un bloc de démarrage implicitement fiable (par ex., stocké en mémoire à lecture seule) du système élémentaire d’entrée/sortie (BIOS) qui mesure d’abord sa propre intégrité, puis étend la mesure à l’ensemble du BIOS. Ensuite, chaque micrologiciel ou logiciel supplémentaire à exécuter est d’abord mesuré avant d’être exécuté et cela va jusqu’au système d’exploitation en suivant un processus de démarrage classique [20].

Ce mécanisme de chaîne de confiance résumé dans la Figure 2 fournit une vue fiable de l’état actuel du système. Toute bibliothèque, module, application, partie du système d’exploitation ou non, a une mesure d’intégrité stockée dans un stockage matériel sécurisé. En principe ces mesures sont signées afin d’empêcher les attaques par relecture ou par l’homme du milieu (par ex. [21]).

Les protections matérielles garantissent qu’une fois qu’une enclave est lancée, aucune modification de son code ou de ses données statiques ne peut être effectuée depuis l’extérieur de l’enclave. Une fois lancés, les processus extérieurs à l’enclave peuvent recevoir une attestation cryptographique qui inclut une signature du code à l’intérieur de l’enclave, de sorte que le processus extérieur peut être assuré de l’exactitude de tout le code pouvant s’exécuter dans l’enclave.

Vérification du micrologiciel et de sa configuration

L’attestation locale ou à distance implique, comme indiqué ci-dessus, la génération d’une signature des mesures, et en particulier celle de la racine de confiance pour la mesur³ (CRTM) avec des clés d’attestation spécifiques. Le mécanisme permet une utilisation à distance pour vérifier si le micrologiciel, le système d’exploitation et l’application souhaités sont réellement en cours d’exécution. Il permet également l’application de politiques de sécurité spécifiques.

Il convient de souligner que dans une architecture moderne complexe, le fabricant du CRTM peut ne pas rester longtemps l’autorité de confiance dans le processus de démarrage et il faut vérifier la chaîne de valeurs de hachage enregistrées pour déterminer l’autorité de l’état actuel du système. En outre, dans un centre de données typique, il peut y avoir des milliers de machines avec leur propre CRTM, ce qui rend leur suivi une tâche complexe, de sorte que des services d’attestation à distance dédiés sont souvent mis à la disposition de l’utilisateur de l’infrastructure informatique partagée.

Notons enfin qu’une construction de racine de confiance avec des protections matérielles physiques sera plus difficile à changer qu’une construction uniquement dans le micrologiciel. Mais un matériel immuable de racine de confiance ne peut pas être mis à jour.

Attestation à distance

L’attestation est un élément fondamental pour vérifier la fiabilité d’un TEE et ensuite décider de lui faire confiance ou pas. Il permet à un environnement logiciel de prouver qu’un programme spécifique est exécuté par un matériel spécifique. Une attestation locale peut être utilisée entre deux environnements logiciels partageant le même matériel, mais ce qui intéresse la plupart des utilisateurs de systèmes avec TEE, est l’attestation à distance où les deux environnements logiciels fonctionnent sur du matériel différent.

En général cette attestation se base sur un module de plateforme fiable (« trusted platform module » – TPM), mais d’autres méthodes existent comme par exemple l’utilisation de fonctions physiques non clonables (« physical unclonable function » – PUF) ou encore des secrets fusionnés dans le circuit intégré.

La plupart des TEE peuvent générer des preuves cryptographiques vérifiables, qui peuvent être envoyées à une partie utilisatrice (par ex., l’appareil utilisateur, le fournisseur de services), qui peut ensuite valider la signature de la preuve. Si la signature et la preuve sont valides, la partie de confiance conclut que le logiciel attendu est exécuté dans un TEE authentique. La preuve est basée sur la mesure du TEE et peut également inclure une clé publique du TEE.

La Figure 3 présente un processus d’attestation générique. La partie utilisatrice du TEE doit connaître la mesure attendue, non seulement de l’application qu’elle souhaite déployer mais également du micrologiciel du TEE. La vérification peut s’effectuer grâce à un mécanisme de défi-réponse. De cette façon l’attestation permet de convaincre l’utilisateur que l’attestation a bien été produite par un logiciel spécifique à l’intérieur d’un matériel spécifique sans interférences extérieures. Plus de détails ainsi que des variations sont donnés dans [23].

Le système d’attestation doit permettre de pouvoir révoquer le TEE dans le cas où il s’avère que la sécurité de ce dernier est compromise.

Conclusion

La combinaison de composants matériels sécurisés et de techniques d’attestation à distance forme l’assise des environnements d’exécution de confiance qui ont pour but de protéger les données sensibles ou secrètes ainsi que le code exécuté contre des attaques de plus en plus fréquentes visant des données en cours de calcul.

Ces environnements sont a priori prometteurs dans le cadre d’infrastructures informatiques partagées. D’abord ils permettent d’augmenter le niveau de sécurité de telles infrastructures en isolant mieux les applications les unes des autres, empêchant par exemple une application compromise d’accéder aux données d’une autre. Ensuite, ils pourraient permettre d’accroître le niveau de confiance des utilisateurs de cette infrastructure pour le traitement de certaines données, pour autant que ces utilisateurs puissent garder le contrôle de la gestion des clés de chiffrement et déchiffrement utilisées au sein de l’environnement de confiance.

Pour l’utilisateur final, l’évaluation des risques liés à l’utilisation du système est simplifiée en ce sens que la confiance est placée dans un composant matériel spécifique et un micrologiciel vérifiable à distance, tous deux avec un comportement attendu, plutôt que dans l’ensemble de l’ordinateur. Mais d’autres risquent sont introduits, comme, par exemple, la possibilité d’un enferment dans une technique TEE particulière.

Dans un prochain article nous regarderons plus en détails le fonctionnement de certaines mises en œuvre commerciales.

Références

[1]        A. Greenberg, « A Peek Into the Toolkit of the Dangerous Triton Hackers », Wired, 10 avril 2019. Consulté le: 4 janvier 2023. [En ligne]. Disponible sur: https://www.wired.com/story/triton-hacker-toolkit-fireeye/

[2]        K. Zetter, « Inside the Cunning, Unprecedented Hack of Ukraine’s Power Grid », Wired, 3 mars 2016. Consulté le: 4 janvier 2023. [En ligne]. Disponible sur: https://www.wired.com/2016/03/inside-cunning-unprecedented-hack-ukraines-power-grid/

[3]        R. Lakshmanan, « New Malware Families Found Targeting VMware ESXi Hypervisors », The Hacker News, 30 septembre 2022. Consulté le: 9 janvier 2023. [En ligne]. Disponible sur: https://thehackernews.com/2022/09/new-malware-families-found-targeting.html

[4]        R. Naraine, « Stuxnet attackers used 4 Windows zero-day exploits », ZDNET, 14 septembre 2010. Consulté le: 9 janvier 2023. [En ligne]. Disponible sur: https://www.zdnet.com/article/stuxnet-attackers-used-4-windows-zero-day-exploits/

[5]        C. Zhao, « SolarWinds, Probably Hacked by Russia, Serves White House, Pentagon, NASA », Newsweek, 14 décembre 2020. Consulté le: 9 janvier 2023. [En ligne]. Disponible sur: https://www.newsweek.com/solar-winds-probably-hacked-russia-serves-white-house-pentagon-nasa-1554447

[6]        B. Barrett, « Russia’s Elite Hackers Have a Clever New Trick That’s Very Hard to Fix », Wired, 27 septembre 2018. Consulté le: 4 janvier 2023. [En ligne]. Disponible sur: https://www.wired.com/story/fancy-bear-hackers-uefi-rootkit/

[7]        T. Bletsch, X. Jiang, V. W. Freeh, et Z. Liang, « Jump-oriented programming: a new class of code-reuse attack », in Proceedings of the 6th ACM Symposium on Information, Computer and Communications Security, Hong Kong China, mars 2011, p. 30‑40. doi:10.1145/1966913.1966919.

[8]        T. Claburn, « MSI motherboards found to have insecure Secure Boot », The Register, 17 janvier 2023. Consulté le: 18 janvier 2023. [En ligne]. Disponible sur: https://www.theregister.com/2023/01/17/msi_motherboards_secure_boot/

[9]        « TEE System Architecture v1.3 ». GlobalPlatform, mai 2022. [En ligne]. Disponible sur: https://globalplatform.org/specs-library/tee-system-architecture/

[10]      M. Sabt, M. Achemlal, et A. Bouabdallah, « Trusted Execution Environment: What It is, and What It is Not », in 2015 IEEE Trustcom/BigDataSE/ISPA, Helsinki, Finland, août 2015, p. 57‑64. doi: 10.1109/Trustcom.2015.357.

[11]      C. Gentry, « Fully homomorphic encryption using ideal lattices », in Proceedings of the 41st annual ACM symposium on Theory of computing, Bethesda MD USA, mai 2009, p. 169‑178. doi: 10.1145/1536414.1536440.

[12]      M. Naehrig, K. Lauter, et V. Vaikuntanathan, « Can homomorphic encryption be practical? », in Proceedings of the 3rd ACM workshop on Cloud computing security workshop – CCSW ’11, Chicago, Illinois, USA, 2011, p. 113. doi: 10.1145/2046660.2046682.

[13]      A. C. Yao, « Protocols for Secure Computations », présenté à 23rd Annual Symposium on Foundations of Computer Science, Chicago, Illinois, USA, nov. 1982. doi: 10.1109/SFCS.1982.38.

[14]      N. Drucker et S. Gueron, « Combining Homomorphic Encryption with Trusted Execution Environment: A Demonstration with Paillier Encryption and SGX », in Proceedings of the 2017 International Workshop on Managing Insider Security Threats, Dallas Texas USA, oct. 2017, p. 85‑88. doi: 10.1145/3139923.3139933.

[15]      M. Pei, H. Tschofenig, D. Thaler, et D. Wheeler, « Trusted Execution Environment Provisioning (TEEP) Architecture », Internet Engineering Task Force, Internet Draft draft-ietf-teep-architecture-19, oct. 2022. Consulté le: 30 janvier 2023. [En ligne]. Disponible sur: https://datatracker.ietf.org/doc/draft-ietf-teep-architecture-19

[16]      S. Checkoway et H. Shacham, « Iago Attacks: Why the System Call API is a Bad Untrusted RPC Interface ».

[17]      « Common Criteria for Information Technology Security Evaluation ». novembre 2022. [En ligne]. Disponible sur: https://www.commoncriteriaportal.org/cc/

[18]      « TEE Protection Profile – Version 1.3 ». GlobalPlatform, 4 juin 2020.

[19]      « A Technical Analysis of Confidential Computing ». Confidential Computing Consortium, octobre 2021. [En ligne]. Disponible sur: https://confidentialcomputing.io/wp-content/uploads/sites/85/2022/11/CCC-A-Technical-Analysis-of-Confidential-Computing-v1.2_updated_2022-11-02.pdf

[20]      D. A. Cooper, W. T. Polk, A. R. Regenscheid, et M. P. Souppaya, « BIOS protection guidelines », National Institute of Standards and Technology, Gaithersburg, MD, NIST SP 800-147, 2011. doi: 10.6028/NIST.SP.800-147.

[21]      D. Challener et K. Goldman, « Trusted Platform Module (TPM) », Trusted Computing Group (TCG), 2019. https://trustedcomputinggroup.org/work-groups/trusted-platform-module/

[22]      C. Shepherd et al., « Secure and Trusted Execution: Past, Present, and Future – A Critical Review in the Context of the Internet of Things and Cyber-Physical Systems », in 2016 IEEE Trustcom/BigDataSE/ISPA, Tianjin, China, août 2016, p. 168‑177. doi: 10.1109/TrustCom.2016.0060.

[23]      H. Birkholz, D. Thaler, M. Richardson, N. Smith, et W. Pan, « Remote ATtestation procedureS (RATS) Architecture », Internet Engineering Task Force, Request for Comments RFC 9334, janv. 2023. doi: 10.17487/RFC9334.

Notes

¹ Plusieurs définitions des environnements d’exécution (TEE) de confiance ou des environnements d’exécution sécurisés (SEE) ont été données, parfois avec des contradictions entre elles. Dans cet article nous nous basons principalement sur les spécifications du Confidential Computing Consortium et de la GlobalPlatform [9]. Différentes définitions sont comparées et une description formelle de ces environnements est proposée dans [10].

² Il y a des propositions pour simplifier le travail des programmeurs d’applications sécurisées avec, par exemple, un protocole interopérable de gestion de telles applications fonctionnant sur différents TEE [15].

³ Le « Core Root of Trust for Measurement » est le tout premier code du BIOS qui est exécuté dans le microprocesseur principal au moment de l’allumage. Il est souvent stocké dans un module de plateforme fiable.

_________________________

Ce post est une contribution individuelle de Fabien A. P. Petitcolas, spécialisé en sécurité informatique chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals.

Over het algemeen wordt aangenomen dat data zich in drie toestanden kunnen bevinden. Data die zijn opgeslagen, bijvoorbeeld op een harde schijf of in een database, worden ‘in rust’ genoemd, data die van de ene computer naar de andere worden verzonden, bijvoorbeeld via een netwerk, zijn ‘in beweging’ en data die door de microprocessor worden verwerkt, zijn ‘in gebruik’.

Tegenwoordig worden cryptografische primitieven op grote schaal ingezet om data in de eerste twee toestanden te beschermen en zo de integriteit en vertrouwelijkheid te waarborgen. Door de strengere regelgeving op het gebied van gegevensbescherming en privacy en de toename van langdurige cyberdreigingen is echter de noodzaak ontstaan om data die in gebruik zijn te beschermen.

Helaas blijft deze bescherming van data in gebruik moeilijk, vooral in de context van gedeelde IT-infrastructuren: het gaat namelijk om het uitvoeren van software met bepaalde veiligheidsgaranties op een externe computer die eigendom kan zijn van en beheerd kan worden door een onbetrouwbare of zelfs kwaadwillende partij.

Talrijke aanvallen

De mogelijke aanvallen zijn talrijk.

Op softwareniveau gaat het om alle aanvallen waarmee de integriteit van het systeem kan worden aangetast, of het nu gaat om het besturingssysteem, de hypervisor of de firmware. Deze aanvallen worden mogelijk gemaakt door verschillende soorten ransomware of hacktools, door gecompromitteerde apparaatstuurprogramma’s, door het misbruik van een zero-day-kwetsbaarheid, door het injecteren van logische fouten, of zelfs door kwaadwillende werknemers of slechte productiepraktijken, enzovoort. [1]-[8] Daarnaast is er ook toegang tot data via hulpkanalen (“side-channel attacks”) of als gevolg van configuratiefouten of fouten in de systeeminstellingen. Ten slotte zijn er, hoewel zeldzamer, cryptografische aanvallen mogelijk, na een grondige analyse van een algoritme of door misbruik te maken van een wiskundige doorbraak.

Op fysiek niveau is het denkbaar dat een systeembeheerder of een externe dienstverlener zonder toestemming toegang krijgt tot de hardware, waardoor hij rechtstreeks verbinding kan maken met de printplaat en informatie kan kopiëren via direct RAM-memory access (DIMM DMA), de double data rate (DDR) kan bespioneren, de computerbus en de cache kan controleren, enzovoort.

Voornaamste technologieën

Confidential computing heeft tot doel een technologische oplossing voor deze problemen te bieden door middel van drie belangrijke methoden:

• Trusted execution environments (TEE’s) zijn gebaseerd op een combinatie van secure hardware-componenten, authenticatiemechanismen en software die is ontworpen om deze hardwarefuncties te benutten¹.
• Homomorphic encryption (HE) heeft betrekking op directe berekeningen op versleutelde data [11] en kan voor bepaalde soorten problemen nuttig zijn, maar brengt kosten met zich mee door de extra rekenkracht die nodig is voor de specifieke encryptie [12].
• Secure multiparty computation [13] (SMC) is een klasse van cryptografische methoden waarmee wederzijds wantrouwende partijen gezamenlijk functies op hun data kunnen berekenen zonder deze aan andere partijen te onthullen. Dit type berekeningis al beschreven in deze blogpost.

Uiteraard is het mogelijk om deze technologieën te combineren, zoals bijvoorbeeld TEE’s met homomorphic encryption (bijv. [14]).

Hieronder concentreren we ons op het eerste type confidential computing: trusted execution environments.

Vermindering van de blootstelling aan aanvallen

Over het algemeen bestaat de volledige stack van een informatica-platform uit verschillende technologieën van talrijke verschillende leveranciers, wat leidt tot een gebrek aan coherente implementatie van de veiligheidscontroles.

De fysieke hardwarelaag waarop het hele systeem is gebouwd, blijft echter de eerste beschermingslaag. Een manier om de algehele veiligheid van een systeem te verbeteren – onder meer door toegang tot data te verhinderen – is dan ook het verhogen van de veiligheid van het fysieke gedeelte.

Dit is het uitgangspunt van TEE’s, die tot doel hebben de uitvoering van toepassingscode te beschermen tegen bevoorrechte code-aanvallen en bepaalde fysieke aanvallen door de vertrouwensbasis en het aanvalsoppervlak te verkleinen (Figuur 1:).

In sommige gevallen maakt de kleine omvang van de TEE de toepassing van formele methoden (gebaseerd op wiskundige constructies) mogelijk en zorgt voor de controle van de conformiteit van de implementatie met de specificaties. Dit versterkt het vertrouwen in de TEE.

TEE’s

TEE’s zijn beveiligingssystemen die parallel aan reguliere uitvoeringsomgevingen (waaronder besturingssystemen zoals Linux of Windows) worden uitgevoerd. Ze zorgen voor een beveiligde zone om activa te beschermen (bijv. gevoelige geheimen, authenticatiesleutels) en dienen ook om ervoor te zorgen dat de bewerkingen die daarbinnen worden uitgevoerd en de bijbehorende data niet van buitenaf kunnen worden geraadpleegd, zelfs niet door bevoorrechte software (bijv. hypervisor, besturingssysteem) of een debugger. In combinatie met een certificeringsmechanisme (zie hieronder) zorgen ze ervoor dat de code die ze uitvoeren niet kan worden gewijzigd of vervangen zonder toestemming van de user.

Een TEE kan worden gebruikt om geheugenisolatie te bieden, waardoor wordt voorkomen dat toepassingen die dezelfde onderliggende hardware delen, het geheugen kunnen lezen dat aan anderen is toegewezen. Sommige TEE’s maken het mogelijk om volledige toepassingen in hun eigen enclaves te isoleren in plaats van alleen specifieke bewerkingen of geheugen te beschermen.

De toepassing van de bovengenoemde eigenschappen is gebaseerd op specifieke fysieke hardware, waarbij alle of een deel van de middelen die nodig zijn voor de goede werking van de TEE in dezelfde houder worden geïntegreerd, of door gebruik te maken van middelen die worden gedeeld met andere componenten op de printplaat van het apparaat
(bijvoorbeeld het RAM-geheugen). In het laatste geval is isolatie door middel van versleuteling noodzakelijk.

Niet alle TEE’s zijn identiek en verschillende fabrikanten kunnen verschillende TEE-implementaties aanbieden met verschillende beveiligingseigenschappen, verschillende functionaliteiten en verschillende controlemechanismen om op beveiligde toepassingen te werken [2]. Sommige TEE’s zijn eerder bedoeld voor telefoons (bijv. de TrustZone-technologie van ARM), terwijl andere zijn bedoeld voor bureau-pc’s of computers die deel uitmaken van een gedeelde IT-infrastructuur (bijv. de SGX-technologie van Intel of de SEV-technologie van AMD).

Meerdere leveranciers van openbare IT-infrastructuur stellen deze technologieën beschikbaar aan zij die niet over deze hardware beschikken. Microsoft biedt bijvoorbeeld het product Azure Confidential Computing aan, dat SGX en SEV ondersteunt. Amazon implementeert zijn eigen TEE-technologie, Nitro genaamd, op zijn AWS-infrastructuur.

Veiligheidsvereisten

TEE’s zijn ontworpen om een breed scala aan softwarebedreigingen van het standaardbesturingssysteem te weerstaan, waaronder bedreigingen op kernelniveau (bijv. [16]) afkomstig van een rooted toestel, evenals bepaalde fysieke aanvallen. TEE’s worden onderworpen aan een grondige veiligheidsanalyse in het kader van de ‘Common Criteria’ [17], [18], maar over het algemeen ontbreekt het hen nog aan verdedigingsmechanismen tegen complexe hardware-aanvallen. Aanvallen die “doorgaans langdurige en/of invasieve toegang tot de hardware vereisen, waaronder chip-scrapingtechnieken en elektronenmicroscoopprobes”, vallen bijvoorbeeld expliciet buiten de toepassing van de vereisten van het Confidential Computing Consortium [19].

De beveiligingsvereisten van een TEE kunnen als volgt worden samengevat (zie [9] voor meer details):

• Het belangrijkste doel van een TEE is het beschermen van zijn activa tegen aanvallen vanuit de rest van de uitvoeringsomgeving. Dit wordt bereikt door middel van hardwaremechanismen die deze andere omgevingen niet kunnen controleren.
• De TEE biedt bescherming tegen bepaalde fysieke aanvallen. Invasieve aanvallen die de fysieke structuur van de geïntegreerde schakeling fysiek beschadigen, worden niet in aanmerking genomen.
• De uitvoeringsomgeving van het vertrouwde besturingssysteem wordt gestart vanuit een root of trust (RoT) binnen de TEE via een beveiligd opstartproces.
• De TEE biedt veilige opslag van data en cryptografische sleutels. Deze opslag is gekoppeld aan deze specifieke TEE op een specifiek apparaat.
• Software buiten de TEE kunnen de functionaliteiten die door de interne interfaces van de TEE worden blootgesteld niet rechtstreeks aanroepen en moeten via specifieke communicatieprotocollen werken, waardoor het vertrouwde besturingssysteem de aanvaardbaarheid van de gevraagde niet-TEE-bewerking kan controleren.

Integriteitscontrole

Een belangrijk concept van TEE’s is de mogelijkheid voor de user om de integriteit van het onderliggende platform te controleren. Dit wordt doorgaans gerealiseerd door middel van twee componenten: het hashen van de verschillende softwaremodules en de verificatie van de firmware. In het kader van gedeelde IT-infrastructuren is het noodzakelijk om deze controle op afstand te kunnen uitvoeren.

Hash en handtekening van modules

Cryptografische hashes (in de context van TEE’s ook vaak ‘metingen’ genoemd) van de software, de firmware en de bijbehorende configuratiebestanden vormen de basis voor het creëren van een vertrouwensketen. Elk van deze vertrouwensketens begint met een vertrouwde rootmodule die zo klein mogelijk moet zijn. Deze kan de vorm aannemen van een impliciet betrouwbaar bootblock (bijv. opgeslagen in alleen-lezen geheugen) van het Basic Input/Output System (BIOS), dat eerst zijn eigen integriteit meet en vervolgens de meting uitbreidt naar het gehele BIOS. Vervolgens wordt elke extra firmware of software die moet worden uitgevoerd, eerst gemeten voordat deze wordt uitgevoerd, en dit gaat door tot het besturingssysteem volgens een klassiek opstartproces [20].

Dit mechanisme van de vertrouwensketen, samengevat in de Figuur 2, biedt een betrouwbaar beeld van de huidige toestand van het systeem. Elke library, module of toepassing, al dan niet onderdeel van het besturingssysteem, heeft een integriteitsmeting opgeslagen in een beveiligde hardwareopslag. In principe zijn deze metingen ondertekend om replay-aanvallen of man-in-the-middle-aanvallen (bijv [21] te voorkomen.

Hardwarebeveiligingen zorgen ervoor dat zodra een enclave is gestart, er geen wijzigingen in de code of statische data kunnen worden aangebracht van buiten de enclave. Nadat ze zijn gestart, kunnen processen buiten de enclave een cryptografisch certificaat ontvangen dat een handtekening van de code binnen de enclave bevat, zodat het externe proces verzekerd is van de juistheid van alle code die in de enclave kan worden uitgevoerd.

Controle van de firmware en de configuratie ervan

Lokale of externe certificering houdt, zoals hierboven vermeld, in dat er een handtekening van de maatregelen wordt gegenereerd, en met name die van de root of trust voor de meting³ (CRTM) met specifieke certificeringssleutels. Het mechanisme maakt het mogelijk om op afstand te controleren of de gewenste firmware, het besturingssysteem en de toepassing daadwerkelijk worden uitgevoerd. Het maakt ook de toepassing van specifieke beveiligingsbeleidsregels mogelijk.

Opgemerkt moet worden dat in een complexe moderne architectuur de fabrikant van de CRTM mogelijk niet lang de vertrouwde autoriteit blijft in het bootproces en dat de keten van opgeslagen hashwaarden moet worden gecontroleerd om de autoriteit van de huidige systeemstatus te bepalen. Bovendien kunnen er in een typisch datacenter duizenden machines met hun eigen CRTM staan, waardoor het bijhouden ervan een complexe taak is, zodat er vaak speciale diensten voor verificatie op afstand ter beschikking worden gesteld aan de user van een gedeelde IT-infrastructuur.

Tot slot moet worden opgemerkt dat een vertrouwensbasis met fysieke hardwarebeveiligingen moeilijker te wijzigen is dan een basis die uitsluitend in de firmware is ingebouwd. Maar onveranderlijke root of trust-hardware kan niet worden bijgewerkt.

Certificering op afstand

Certificering is een fundamenteel element om de betrouwbaarheid van een TEE te verifiëren en vervolgens te beslissen of deze al dan niet kan worden vertrouwd. Hiermee kan een softwareomgeving aantonen dat een specifiek programma door specifieke hardware wordt uitgevoerd. Lokale certificering kan worden gebruikt tussen twee softwareomgevingen die dezelfde hardware delen, maar wat voor de meeste users van systemen met TEE van belang is, is certificering op afstand, waarbij de twee softwareomgevingen op verschillende hardware draaien.

Over het algemeen is deze certificering gebaseerd op een trusted platform module (TPM), maar er bestaan ook andere methoden, zoals het gebruik van physical unclonable functions (PUF) of geheimen die in de geïntegreerde schakeling zijn ingebed.

De meeste TEE’s kunnen verifieerbare cryptografische bewijzen genereren, die naar een gebruiker (bijvoorbeeld het apparaat van de user of de serviceprovider) kunnen worden verzonden, die vervolgens de handtekening van het bewijs kan valideren. Als de handtekening geldig is, concludeert de vertrouwende partij dat de verwachte code wordt uitgevoerd in een authentieke TEE. Het bewijs is gebaseerd op de meting van de TEE en kan ook een openbare sleutel van de TEE bevatten.

Figuur 3 toont een algemeen certificeringsproces. De gebruiker van de TEE moet de verwachte meting kennen, niet alleen van de toepassing die hij wil implementeren, maar ook van de firmware van de TEE. De verificatie kan worden uitgevoerd met behulp van een challenge-response-mechanisme. Op deze manier overtuigt de certificering de user ervan dat de certificering daadwerkelijk is gegenereerd door specifieke software binnen specifieke hardware, zonder externe interferentie. Meer data en variaties worden gegeven in [23].

Het certificeringssysteem moet het mogelijk maken om de TEE in te trekken indien blijkt dat de veiligheid ervan is aangetast.

Conclusie

De combinatie van beveiligde hardwarecomponenten en technieken voor verificatie op afstand vormt de basis van vertrouwde uitvoeringsomgevingen die tot doel hebben gevoelige of geheime data en de uitgevoerde code te beschermen tegen steeds frequentere aanvallen op data die worden verwerkt.

Deze omgevingen zijn a priori veelbelovend in het kader van gedeelde IT-infrastructuren. Ten eerste maken ze het mogelijk om het beveiligingsniveau van een privé-infrastructuur of gemeenschappelijke infrastructuur te verhogen door toepassingen beter van elkaar te isoleren, waardoor bijvoorbeeld wordt voorkomen dat een gecompromitteerde toepassing toegang krijgt tot de data van een andere. Ten tweede kunnen ze het vertrouwensniveau in een openbare infrastructuur voor de verwerking van bepaalde data verhogen, op voorwaarde dat de user de controle behoudt over het beheer van de versleutelings- en ontsleutelingssleutels die binnen de vertrouwde omgeving worden gebruikt.

Voor de enduser wordt de risicobeoordeling met betrekking tot het gebruik van het systeem vereenvoudigd, in die zin dat het vertrouwen wordt gesteld in een specifieke hardwarecomponent en op afstand verifieerbare firmware, die beide een verwacht gedrag vertonen, in plaats van in de computer als geheel. Er worden echter ook andere risico’s geïntroduceerd, zoals bijvoorbeeld de mogelijkheid van een lock-in bij een bepaalde TEE-technologie.

In een volgend artikel zullen we nader ingaan op de werking van bepaalde commerciële implementaties.

Referenties

[1]        A. Greenberg, “A Peek Into the Toolkit of the Dangerous Triton Hackers”, Wired, 10 april 2019. Geraadpleegd: 4 januari 2023. [Online]. Beschikbaar op: https://www.wired.com/story/triton-hacker-toolkit-fireeye/

[2]        K. Zetter, “Inside the Cunning, Unprecedented Hack of Ukraine’s Power Grid”, Wired, 3 maart 2016. Geraadpleegd: 4 januari 2023. [Online]. Beschikbaar op: https://www.wired.com/2016/03/inside-cunning-unprecedented-hack-ukraines-power-grid/

[3]        R. Lakshmanan, “New Malware Families Found Targeting VMware ESXi Hypervisors”, The Hacker News, 30 september 2022. Geraadpleegd: 9 januari 2023. [Online]. Beschikbaar op: https://thehackernews.com/2022/09/new-malware-families-found-targeting.html

[4]        R. Naraine, “Stuxnet attackers used 4 Windows zero-day exploits”, ZDNET, 14 september 2010. Geraadpleegd: 9 januari 2023. [Online]. Beschikbaar op: https://www.zdnet.com/article/stuxnet-attackers-used-4-windows-zero-day-exploits/

[5]        C. Zhao, “SolarWinds, Probably Hacked by Russia, Serves White House, Pentagon, NASA”, Newsweek, 14 december 2020. Geraadpleegd: 9 januari 2023. [Online]. Beschikbaar op: https://www.newsweek.com/solar-winds-probably-hacked-russia-serves-white-house-pentagon-nasa-1554447

[6]        B. Barrett, “Russia’s Elite Hackers Have a Clever New Trick That’s Very Hard to Fix”, Wired, 27 september 2018. Geraadpleegd: 4 januari 2023. [Online]. Beschikbaar op: https://www.wired.com/story/fancy-bear-hackers-uefi-rootkit/

[7]        T. Bletsch, X. Jiang, V. W. Freeh, en Z. Liang, “Jump-oriented programming: a new class of code-reuse attack”, in Proceedings of the 6th ACM Symposium on Information, Computer and Communications Security, Hong Kong China: ACM, mrt. 2011, pp. 30-40. doi: 10.1145/1966913.1966919.

[8]        T. Claburn, “MSI motherboards found to have insecure Secure Boot”, The Register, 17 januari 2023. Geraadpleegd: 18 januari 2023. [Online]. Beschikbaar op: https://www.theregister.com/2023/01/17/msi_motherboards_secure_boot/

[9]        “TEE System Architecture v1.3”. GlobalPlatform, mei 2022. [Online]. Beschikbaar op: https://globalplatform.org/specs-library/tee-system-architecture/

[10]      M. Sabt, M. Achemlal, en A. Bouabdallah, “Trusted Execution Environment: What It is, and What It is Not”, in 2015 IEEE Trustcom/BigDataSE/ISPA, Helsinki, Finland: IEEE, aug. 2015, pp. 57-64. doi: 10.1109/Trustcom.2015.357.

[11]      C. Gentry, “Fully homomorphic encryption using ideal lattices”, in Proceedings of the 41st annual ACM symposium on Theory of computing, Bethesda MD USA: ACM, mei 2009, pp. 169-178. doi: 10.1145/1536414.1536440.

[12]      M. Naehrig, K. Lauter, en V. Vaikuntanathan, “Can homomorphic encryption be practical?”, in Proceedings of the 3rd ACM workshop on Cloud computing security workshop – CCSW ’11, Chicago, Illinois, USA: ACM Press, 2011, p. 113. doi: 10.1145/2046660.2046682.

[14]      N. Drucker en S. Gueron, “Combining Homomorphic Encryption with Trusted Execution Environment: A Demonstration with Paillier Encryption and SGX”, in Proceedings of the 2017 International Workshop on Managing Insider Security Threats, Dallas Texas USA: ACM, okt. 2017, pp. 85-88. doi: 10.1145/3139923.3139933.

[15]      M. Pei, H. Tschofenig, D. Thaler, en D. Wheeler, “Trusted Execution Environment Provisioning (TEEP) Architecture”, Internet Engineering Task Force, Internet Draft draft-ietf-teep-architecture-19, okt. 2022. Geraadpleegd: 30 januari 2023. [Online]. Beschikbaar op: https://datatracker.ietf.org/doc/draft-ietf-teep-architecture-19

[16]      S. Checkoway en H. Shacham, “Iago Attacks: Why the System Call API is a Bad Untrusted RPC Interface”.

[17]      “Common Criteria for Information Technology Security Evaluation”. november 2022. [Online]. Beschikbaar op: https://www.commoncriteriaportal.org/cc/

[18]      “TEE Protection Profile – Version 1.3”. GlobalPlatform, 4 juni 2020.

[19]      “A Technical Analysis of Confidential Computing”. Confidential Computing Consortium, oktober 2021. [Online]. Beschikbaar op: https://confidentialcomputing.io/wp-content/uploads/sites/85/2022/11/CCC-A-Technical-Analysis-of-Confidential-Computing-v1.2_updated_2022-11-02.pdf

[20]      D. A. Cooper, W. T. Polk, A. R. Regenscheid, en M. P. Souppaya, “BIOS protection guidelines”, National Institute of Standards and Technology, Gaithersburg, MD, NIST SP 800-147, 2011. doi: 10.6028/NIST.SP.800-147.

[21]      D. Challener en K. Goldman, “Trusted Platform Module (TPM)”, Trusted Computing Group (TCG). [Online]. Beschikbaar op: https://trustedcomputinggroup.org/work-groups/trusted-platform-module/

[22]      C. Shepherd e.a., “Secure and Trusted Execution: Past, Present, and Future – A Critical Review in the Context of the Internet of Things and Cyber-Physical Systems”, in 2016 IEEE Trustcom/BigDataSE/ISPA, Tianjin, China: IEEE, aug. 2016, pp. 168-177. doi: 10.1109/TrustCom.2016.0060.

[23]      H. Birkholz, D. Thaler, M. Richardson, N. Smith, en W. Pan, “Remote ATtestation procedureS (RATS) Architecture”, Internet Engineering Task Force, Request for Comments RFC 9334, jan. 2023. doi: 10.17487/RFC9334.

¹ Er zijn verschillende definities gegeven van trusted execution environments (TEE’s) of secure execution environments (SEE’s), die soms onderling tegenstrijdig zijn. In dit artikel baseren wij ons voornamelijk op de specificaties van het Confidential Computing Consortium en GlobalPlatform [9]. Verschillende definities worden vergeleken en een formele beschrijving van deze omgevingen wordt voorgesteld in [10].

² Er zijn voorstellen om het werk van programmeurs van beveiligde toepassingen te vereenvoudigen, bijvoorbeeld met een interoperabel protocol voor het beheer van dergelijke toepassingen die op verschillende TEE’s draaien [15].

³ De “Core Root of Trust for Measurement” is de allereerste BIOS-code die bij het opstarten in de hoofdmicroprocessor wordt uitgevoerd. Deze wordt vaak opgeslagen in een betrouwbare platformmodule.

Dit is een ingezonden bijdrage van Fabien A. P. Petitcolas, IT-beveiligingsspecialist bij Smals Research. Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

De fysieke locatie van de public cloud services was tot nu toe beperkt tot de datacenters van de public cloud provider. Maar nu zien we een tendens waarbij cloud services ook fysiek beschikbaar gesteld worden in het datacenter van de klant of edge locaties.

Het idee is om hiermee scenario’s te ondersteunen waarbij de fysieke locatie van de services er toe doet. Dat is bijvoorbeeld het geval in het kader van bepaalde regelgeving waarbij er vereisten zijn om gegevens op een specifieke locatie te hosten: in het eigen land of in het eigen datacenter. Een ander voorbeeld is het zorgen voor minder vertraging (latency) bij het afhandelen van requests: het feit dat de data dichter staat bij de locatie waar ze verwerkt wordt, kan zorgen voor een snellere afhandeling. Tenslotte kan ook de impact van algemene netwerkproblemen beperkt worden omdat alle benodigde componenten fysiek dicht bij elkaar draaien en niet afhankelijk zijn van externe netwerkverbindingen.

Marktaanbod

Vrijwel alle grote spelers hebben in dit kader een aanbod beschikbaar of in voorbereiding:

• Amazon biedt met Outposts een oplossing waarbij bepaalde AWS infrastructuur en diensten on-premises kunnen gehost worden. Het is een combinatie van hardware en software die door Amazon beheerd, gemonitored en geupdate wordt en geconnecteerd is met de dichtste AWS Region.
• IBM Cloud Satellite kan gezien worden als een extensie van IBM’s public cloud en moet toelaten om toepassingen consistent te draaien over verschillende locaties heen (on-premises en een publieke cloud omgeving) met centraal beheer.
• Google Anthos is een Kubernetes-gebaseerd software platform voor het beheer van container clusters, zowel on-premises als in de cloud (niet enkel de Google cloud). Ook hier is er een console voor centraal beheer van alle componenten.
• Microsoft tenslotte biedt met Azure Stack de mogelijkheid om Azure services en toepassingen te draaien in het eigen datacenter. Als klant koop je gecertifiëerde hardware van een Microsoft partner met vooraf geïnstalleerde Azure services. Er is de mogelijkheid om gedeeltelijk of volledig gedeconnecteerd te werken ten opzichte van de public cloud. Daarnaast biedt Microsoft ook verschillende Azure Cognitive Services aan onder de vorm van Docker containers die je lokaal (on-premises) kan draaien (zie verder).

We zien verschillen in het aanbod van de leveranciers: in bepaalde gevallen gaat het over een puur software platform, in andere gevallen over een bundel van hardware en software. Maar telkens wordt de nadruk gelegd op de mogelijkheid om alle componenten centraal te beheren, los van de locatie waar ze fysiek draaien. Om die reden staan de “lokale” cloud services dan ook meestal nog in verbinding met de public cloud.

Aandachtspunten

De evolutie naar gedistribueerde cloud lijkt opportuniteiten te bieden, toch zijn er enkele aandachtspunten. Eerst en vooral moet nagegaan worden of de beoogde voordelen effectief gelden. Biedt een on-premises installatie bijvoorbeeld wel degelijk de nodige garanties omtrent data soevereiniteit? Cloud providers blijven namelijk in bepaalde gevallen verantwoordelijk voor het beheren, monitoren en updaten van de infrastructuur en hebben er aldus toegang toe. Ook moet er nagegaan worden wat de totale kost is van de oplossing en of de beoogde voordelen wel opwegen tegen die kost. Tenslotte bieden de leveranciers niet meteen al hun public cloud services aan in een gedistribueerde manier. Veel is nog in preview of in beta, of zelfs (nog) niet beschikbaar.

Voorbeeld

Een voorbeeld van een public cloud service die ook on-premises ter beschikking kan gesteld worden is de Azure Cognitive Services Speech container van Microsoft. Concreet biedt Microsoft een Docker container aan die om het even waar kan gedraaid worden, dus ook on-premises. De container biedt dezelfde API-functionaliteit als de public cloud API. Enige voorwaarde is dat er een link moet zijn met de Azure cloud omwille van billing. De kosten voor het gebruik van de container zijn dezelfde als die van de public cloud service volgens een pay-per-use model. Aandachtspunt is de beveiliging: de lokale API die de container aanbiedt is standaard niet beveiligd, er is bijvoorbeeld geen toegangscontrole. Dat moet je dus zelf nog voorzien.

Een kort experiment toont aan dat de container vlot te installeren is en het gebruik van de API inderdaad gelijkaardig is aan de public cloud service. Wel moet er per taal een aparte container geïnstalleerd worden terwijl de public cloud API de taal aanvaardt als input-parameter. Ook sta je als klant zelf in voor de onderliggende infrastructuur en deployment van updates.

Conclusie

Om bepaalde redenen kan het wenselijk zijn om cloud services op een specifieke locatie te draaien. Meer en meer bieden cloud providers de mogelijkheid om cloud services beschikbaar te stellen in het eigen datacenter. Het is een trend die mogelijkheden lijkt te bieden, al moeten we erover waken dat deze voordelen ook echt gelden en de totale kost niet uit het oog verliezen.

Dit is een ingezonden bijdrage van Bert Vanhalst, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

In zijn eenvoudigste vorm wordt er informatie getoond in het gezichtsveld van de gebruiker via een head-up display (HUD). Denk aan een schermpje in de wagen waarbij een bestuurder navigatie-instructies te zien krijgt in zijn gezichtsveld of een gevechtspiloot die vluchtgegevens te zien krijgt in zijn gezichtsveld en op die manier niet naar beneden moet kijken naar de instrumenten. In een meer geavanceerde vorm worden objecten accuraat toegevoegd aan de werkelijke wereld, rekening houdend met het 3D-perspectief, zodat ze volledig geïntegreerd lijken met de werkelijke wereld. Met die objecten kan je dan mogelijks ook interageren.

Augmented Reality is niet hetzelfde als Virtual Reality (VR). Waar AR iets toevoegt aan de werkelijke wereld, vervangt VR de werkelijke wereld volledig door een gesimuleerde wereld.
Een standaard smartphone is al voldoende om een AR ervaring te beleven. Zowel Google (ARCore) als Apple (ARKit) leveren frameworks om AR toepassingen te bouwen. Ze laten toe om de positie van de smartphone te traceren en de plaats ervan in de omgeving beter in te schatten. De grootte en positie van oppervlakken, zoals de grond of een tafel, wordt zo goed mogelijk gedetecteerd zodat virtuele objecten zo realiteitstrouw mogelijk toegevoegd kunnen worden aan de werkelijke wereld.

Naast de smartphone zijn er specifieke AR brillen, zoals de Google Glass Enterprise Edition en Iristick Z1 Premium, die informatie kunnen tonen in het gezichtsveld van de gebruiker via een head-up display en op die manier een handenvrije ervaring kunnen bieden. De Hololens van Microsoft gaat nog een stapje verder en laat toe om objecten te integreren in de werkelijke wereld en ermee te interageren.

Toepassingen

Eén van de bekendere voorbeelden van een AR toepassing is het spel Pokémon Go, waarbij spelers virtuele Pokémon moeten zoeken en vangen. Andere voorbeelden zijn de Quiver app waarmee kleurplaten tot leven gebracht worden en de Woody Wereld waarbij de Woodydieren op pyjama’s tot leven komen.

Naast gaming en entertainment zijn er ook toepassingen in de gezondheidszorg. Chirurgen kunnen ondersteuning krijgen bij het uitvoeren van ingrepen. Zo kan via een AR bril informatie of medische beelden gevisualiseerd worden in het gezichtsveld van de chirurg, zoals een tumor of de belangrijkste bloedvaten. Dat kan chirurgen helpen bepalen waar een incisie exact moet gebeuren. Daarnaast kan essentiële informatie over de patient in het gezichtsveld getoond worden bij dringende ingrepen, in plaats van die informatie af te lezen op papier of te consulteren in een elektronisch dossier. Bij hun opleiding kan AR zorgverstrekkers de mogelijkheid beiden om de menselijke anatomie in 3D te verkennen.

In de retail zijn er toepassingen waarbij een meubel virtueel in de woonkamer kan geplaatst worden, zoals met de Ikea Place app, of om te zien hoe je staat met een bepaald kledingstuk.

Ook in de industrie zijn er voorbeelden te vinden: digitale handleidingen en onderhoudsinstructies kunnen geprojecteerd worden op de werkomgeving zodat men de handen vrij heeft om het werk uit te voeren in plaats van een papieren handleiding te moeten doorbladeren. Via de camera van een AR bril kan een collega/expert van op afstand meekijken en assistentie bieden.

Dit is slechts een greep uit de toepassingsmogelijkheden van Augmented Reality. Met al deze voorbeelden kunnen we ons de vraag stellen of dit ook nuttig kan zijn binnen een overheidscontext. Om hier meer inzicht in te krijgen voert Smals Research momenteel experimenten uit in de context van inspectie-opdrachten. Hiermee willen we zelf ervaring opbouwen omtrent de technische mogelijkheden van AR, uitzoeken wat de concrete mogelijkheden zijn voor ondersteuning van inspecteurs op het terrein, en inspiratie bieden voor eventuele andere toepassingsmogelijkheden.

Dit is een ingezonden bijdrage van Bert Vanhalst, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Er was eens… een metrorit. En voor metroritten heb je tegenwoordig een MOBIB-kaart nodig. Dit deed me terugdenken aan het verhaal van de smartcards, en hoe we er veel te veel nodig hebben… Bij deze dan het lang beloofde derde deel van dat verhaal.

Over Metro- en Treinkaarten

Onlangs moest ik na lange tijd nog eens de metro nemen. Ik wist dat mijn papieren kaartje met magneetstrip ondertussen niet meer geldig zou zijn: de overschakeling naar MOBIB is nu volledig doorgevoerd. De MOBIB-kaart is RFID technologie, waardoor je ze kan gebruiken door ze gewoon tegen een kaartlezer tegen te houden (je hoeft ze nergens in te steken). Meer over deze technologie kan je terugvinden in één van onze techno’s: Het ABC van RFID.

Nu, ik heb reeds een treinabonnement, en ook dit staat op een MOBIB-kaart… van de NMBS. Ik moest er dus achter zien te komen of ik deze ook voor de metro kon gebruiken. Na wat zoekwerk, zag ik dat ik online een account kon aanmaken bij de MIVB en dat ik een bestaande MOBIB-kaart kon koppelen aan mijn account. Wanneer ik dit echter probeerde, wist het systeem mij te vertellen dat mijn kaart niet gekend was, maar dat dit wel het geval zou zijn indien ik deze eerst kon opladen via één van de GO-machines in de metrostations.

Zo gezegd zo gedaan, en – wonder boven wonder? – dit werkte inderdaad zoals aangegeven: ik kon mijn NMBS-kaart gebruiken als houder voor het saldo van mijn metroritten, en ik kon deze kaart daarna ook effectief koppelen aan mijn online profiel bij MIVB. (Eén mankement: het resterend saldo aan ritten is niet zichtbaar; maar misschien is dit ook voor de eigen kaarten van MIVB geen feature? – graag een comment indien iemand dit weet!)

Wat leren we nu uit dit verhaal?

• Ten eerste, de technologische mogelijkheden om het probleem van het teveel aan kaarten in mijn portefeuille op te lossen, zijn reeds duidelijk aanwezig, maar, gezien het aantal kaarten dat ik nog nodig heb, is er nog geen verregaande implementatie gebeurd (zo is mijn abonnement bij De Lijn, verkregen via NMBS, nog steeds een stukje papier, en een koppeling met bijvoorbeeld de Belgische eID is nog steeds beperkt tot de occasionele online aankoop van een treinticket). Conclusie: nog steeds geen one card to rule them all…
• Ten tweede: de netwerken van MIVB en NMBS zijn voorlopig nog onvoldoende geïntegreerd om reeds bij de aanmaak van een nieuwe kaart bij één firma, rechtstreeks ook de nodige gegevens te versturen aan de andere. Op zich is dit soort integratie misschien nogal veeleisend, maar in deze nieuwe wereld van de IT, met zijn Cloud, zijn microservices, en vooral, zijn API economy, zijn er toch wel een aantal architecturen te bedenken waarin dit geen probleem zou mogen zijn. Het “only once principe” is echter vaak meer een verhaal van politiek en economie, dan van technologie.

“Card Management as a Service”

Ik zou hier graag reeds even vooruitblikken op een toekomstige blog, waarin ik de voordelen van een gescheiden beheer van gegevensnetwerken versus er van gebruik makende toepassingen wil toelichten: Stel dat we één instelling hadden die het beheer van de kaarten en de ermee gepaard gaande gegevens, netwerken en basisdiensten op zich nam, en dat de andere bedrijven, zoals de vervoersmaatschappijen in kwestie, van deze diensten gebruik maakten. Dit zou ervoor zorgen dat alles wat met kaarten te maken had, efficiënter zou kunnen worden gemaakt wegens schaalvoordelen, én dat de vervoersmaatschappijen zelf deze verantwoordelijkheid niet meer hoefden te dragen. Dit is eigenlijk precies één van de belangrijke verwezenlijkingen van Cloud, en, meer in het bijzonder, het “as a Service” verhaal, maar dan toegepast op chipkaarten. Daarnaast kan men het ook bekijken in een microservices en API context (“you build it, you run it”).

Hierover dus later meer. Waar ik het nu verder over wil hebben is de toekomst…

De Nabije Toekomst?

Vandaag is het reeds mogelijk om met je smartphone vervoersbewijzen aan te kopen, betalingen te doen, ja, zelfs jezelf te identificeren voor gebruik van overheidstoepassingen. Een toekomst waarin we geen kaarten meer nodig hebben, maar waarin deze volledig zijn vervangen door de smartphone, is dus zeker technisch realiseerbaar, en op lange termijn misschien zelfs realistisch. Het belangrijkste probleem hierbij is er één dat slechts langzaamaan kan worden opgelost: de logistiek van het on-boarden van alles en iedereen die nu nog met kaarten werkt, en van alles en iedereen die nu nog geen smartphone heeft. In een nog verdere toekomst zullen we misschien zelfs de portefeuille in zijn geheel kunnen afschaffen, indien we dit ook met het systeem van cash geld zouden doen!

Science Fiction

Wat als we dan nog eens een paar decennia verder in de toekomst kijken? We zien reeds nu zaken opduiken als bio-authentication, waarbij we onze vingerafdrukken, stem, gezicht, of zelfs context gebruiken om te authenticeren. Daarnaast doet men ook gericht onderzoek naar nanotechnologie, robotica, artificiële intelligentie, Internet of Things, … Allemaal zaken die ervoor zorgen dat technologie en ons lichaam steeds dichter bij elkaar komen en uiteindelijk zelfs kunnen worden samengevoegd.

Uiteindelijk zou het dan mogelijk worden dat de smartphone wordt vervangen door een scherm op de huid van onze arm (zie filmpje hierboven voor wat binnenkort al kan!), met alle nodige technologie netjes verborgen aan de binnenkant van ons lichaam! Sterker nog: het scherm zou evengoed virtueel voor onze ogen kunnen worden getoverd, dankzij technologie rechtstreeks in onze ogen of hersenen. Op die manier hebben we niets meer nodig: al het nodige dragen we steeds met ons mee, zoals we dat met ons lichaam doen. En onszelf identificeren om ons vervoersbewijs te legitimiseren, doen we door eens te wuiven.

Op zich een groot gemak, maar uiteraard is hier ook een duistere zijde aan verbonden: het zou wel eens heel moeilijk kunnen worden om “off-the-grid”, of “offline” te gaan, of om zonder al deze technologische snufjes te kunnen. Sterker nog: we zouden Big Brother scenario’s kunnen krijgen, of een regelrecht doembeeld, zoals in de film “In Time“. Maar goed: wat er met een technologie gedaan wordt, staat los van de technologie zelf (ook met een eenvoudige hamer kan je zowel bouwen als verwonden).

Besluit

Er staan ons nog een aantal wonderlijke technologische evoluties te wachten, maar er blijft vooral nog veel werk aan de winkel wat betreft het vereenvoudigen van het leven van de gewone burger, met al zijn chipkaarten, zijn smartphone en zijn muntjes van twee eurocent, en van alle administratie die daarbij komt kijken. Samenwerking, integratie, en het zo breed mogelijk invoeren van het only once principe zijn de boodschap.