• Startseite
  • Kontakt

Maximale Sicherheit durch TPM’s - Kein TPM = Keine Sicherheit

Eine Kopie des Whitepapers (PDF) können Sie hier laden.

 

TPMs (Trusted Platform Modules) sind winzige Halbleiterbausteine, die in allen PCs eingebettet und manchmal sogar in der CPU selbst integriert sind. Sie sind ein sicherer Tresor für Verschlüsselungsschlüssel – in vielerlei Hinsicht ähnlich wie der Chip auf einer Zahlungskarte. TPMs kommen seit langer Zeit in PCs und Laptops zum Einsatz, aber sie werden in Geldautomaten-Netzwerken von Banken nicht richtig verwendet.

Dies ist oft auf die Trägheit bei der Implementierung neuer Sicherheitsarchitekturen zurückzuführen. Das ist überraschend, wenn man bedenkt, dass Geldautomaten- bzw. GAA-Netzwerke kryptographisch sichere Architekturen benötigen, mehr als die meisten anderen Branchen.

TPMs sind in der Tat viel mehr als nur ein sicherer Schlüsselspeicher. Sie bilden die Vertrauensgrundlage der gesamten Sicherheit in PC-basierten Netzwerken – und das sollte auch in GAA-Netzwerken so sein.
Dieses Dokument untersucht, worauf Banken bei der Gestaltung ihrer GAA-Sicherheitsarchitektur achten müssen und wie die Branche TPMs nutzen sollte, um die Hardware, Software und das Netzwerk kryptografisch zu sichern.

Einführung

Alle sind sich darüber einig, dass Geldautomaten so weit wie möglich gesichert werden müssen, ohne ihre Nutzbarkeit zu beeinträchtigen. Es scheint jedoch weniger Konsens darüber zu bestehen, wie dies erreicht werden kann. Natürlich entsteht ein Teil dieser Verwirrung aufgrund des Wettbewerbs zwischen den Anbietern, wobei unterschiedliche Sicherheitsprodukte um die Aufmerksamkeit der Kunden wetteifern. Aber es gibt auch eine ganze Reihe von Fehlinformationen, die Kunden verwirren und letztlich zu schlechten Implementierungen führen, die anfällig für Angriffe sind.

Dieses Whitepaper fasst wichtige Grundlagen der Systemsicherheit zusammen, beginnend mit der Ausgangsbasis, wie einzelne Computersysteme geschützt werden sollten. Dann wird auf den einzigartigen Anwendungsfall der GAA-Netzwerke eingegangen, die natürlich das höchste Schutzniveau erfordern. Geldautomaten-Netzwerke haben nicht nur die Verantwortung für Millionen von Euros an Bargeld, sie sind auch ein potenzieller Einstiegspunkt zu den Host-Computersystemen einer Bank, die große Geldbeträge in die ganze Welt überweisen. Ein kompromittierter Geldautomat könnte eine Bank teurer zu stehen kommen, als nur das Bargeld im Tresor.

Lassen Sie uns zunächst einige verbreitete Missverständnisse über Sicherheit betrachten. Das vielleicht größte Missverständnis bei der Systemsicherheit ist ein Missverständnis des Konzepts der mehrschichtigen Sicherheit. Es stimmt, dass es bei der Sicherung eines komplexen Systems keinen einzelnen Königsweg gibt – es werden mehrere koordinierte Schlösser benötigt. Dieses Konzept wird jedoch oft missverstanden und so ausgelegt, dass ein System umso sicherer ist, je undurchsichtiger und komplexer die Sicherheit ist.  Das ist aber einfach nicht der Fall. Es gibt grundlegende kryptographische Techniken, die einfach, offen diskutiert und gut verstanden werden können und die den Kern jeder Sicherheitsarchitektur bilden müssen. Solche Techniken liefern nicht nur quantifizierbare Sicherheit, sie sind auch einfach zu bedienen und nicht auf Verrenkungen der Benutzer angewiesen, damit sie funktionieren.

Lassen Sie uns dies an einem kurzen Beispiel veranschaulichen. Wir alle sind an PC-Systeme gewöhnt, die zur Anmeldung einen Benutzernamen und ein Passwort erfordern. Als das kennwortbasierte Sicherheitssystem von Hackern angegriffen wurde, schufen Organisationen immer kompliziertere Kennwortregeln, die für legitime Benutzer höchst unfreundlich sind – regelmäßige Kennwortänderungen, keine Verwendung der letzten X Kennwörter, komplizierte und schwer zu merkende Kennwortzusammensetzungen usw. All das hat Microsoft dann mit „Windows Hello“ vereinfacht.

Windows Hello kombiniert TPM-geschützte, kryptografisch sichere Hardware-Geräteerkennung mit biometrischer Gesichtserkennung. Dies ist in der Tat einem Sicherheitskonzept sehr ähnlich, das die Geldautomatenindustrie gut versteht – Chip und Pin. Bei Windows Hello ist der Chip das TPM, ein kryptographischer Prozessor, ähnlich dem Chip auf einer Zahlungskarte, und die biometrische Information tritt an die Stelle des Pins. Dieses System ist nicht nur sicherer, als jedes System mit Benutzernamen und Passwort jemals sein kann, es ist auch äußerst benutzerfreundlich. Ich kann mich auf meinem Surface-Tablett nicht nur anmelden, indem ich es einfach ansehe, sondern ich kann dies auch sofort tun – schneller, als ich einen einzigen Buchstaben meines Passworts eingeben kann. Ist es möglich, dass ein System sowohl sicherer als auch einfacher zu bedienen ist? Auf jeden Fall. Wir müssen von dem Glauben wegkommen, dass es ohne Fleiß keinen Preis gibt – echte Sicherheit muss den Benutzer nicht foltern.

Sie werden bemerkt haben, dass wir im vorigen Absatz das Konzept der TPMs eingeführt haben. In diesem Dokument geht es um TPMs als die „Vertrauensgrundlage“ auf Computern. Das TPM ist ein sicherer Halbleiterchip, der aus einer Sicherheitsarchitektur besteht, die von der Trusted Computing Group (TCG) mit über 100 Unternehmen entwickelt wurde, darunter große Unternehmen wie Intel, Microsoft, HP und IBM. Ihre Arbeit begann bereits 1999 mit dem Ziel, einen sicheren Kern für Computergeräte zu schaffen, sodass die gesamte Computersicherheit von diesem sicheren Kern aus aufgebaut werden konnte. Die gute Nachricht ist, dass TPMs in allen neuen PC-Geräten völlig standardisiert sind, und das schon seit vielen Jahren. Die schlechte Nachricht ist, dass viele Organisationen nicht einmal wissen, dass sie dieses Sicherheitsjuwel in ihren Computergeräten haben und es nicht nutzen. Dieses Whitepaper ist ein Versuch, diese Situation zu ändern – insbesondere für unsere Geldautomaten-Industrie. Schließlich brauchen wir mehr als die meisten Branchen eine sichere Datenverarbeitung.

TPMs – die „Vertrauensgrundlage“

Was ist mit „Vertrauensgrundlage“ gemeint und warum ist das TPM von zentraler Bedeutung für die Computersicherheit? Um das zu verstehen, ist es wichtig zu wissen, dass jede Computersicherheit auf dem cleveren Einsatz von Verschlüsselung beruht. Die Verschlüsselung ist eine Rechenmethode, die Daten von einer „klaren“ Form in eine scheinbar zufällige Form und zurück umwandelt.

Wenn Daten oder Informationen in der klaren Form vorliegen, können sie für einen bestimmten Zweck verwendet werden. Wenn Daten verschlüsselt werden, sind sie unbrauchbar, bis sie entschlüsselt werden. Das Entscheidende bei der Ver- und Entschlüsselung ist, dass für die Ver- und Entschlüsselung von Daten ein sicherer „Schlüssel“ benötigt wird. Ohne den Schlüssel sind die verschlüsselten Daten nutzlos. In der Tat ist das Wort „Schlüssel“ in diesem Sinne nichts anderes als ein Schlüssel zu einem Tresor. Wenn der Schlüssel zu einem Tresor verloren geht, haben Sie keinen Zugriff auf das Gold in diesem Tresor. Im Falle der Datenverarbeitung sind das Gold die Daten, die durch das Verschlüsselungsverfahren geschützt werden.

Nun ist es wichtig zu verstehen, dass der Schlüssel selbst in eindeutiger Form vorliegen muss, damit er zum Entschlüsseln einer Nachricht verwendet werden kann. Das bedeutet, dass Sie eine Möglichkeit haben müssen, den Schlüssel sicher aufzubewahren. Ja, Sie können diesen Schlüssel mit einem anderen Schlüssel verschlüsseln. Das würde den ursprünglichen Schlüssel schützen, aber dann haben Sie ein Problem damit, wo Sie den zweiten Schlüssel aufbewahren sollen. Sie können tatsächlich eine Schlüsselkette haben (und solche Ketten kommen ziemlich häufig vor). Aber der ursprüngliche Schlüssel muss an einem sicheren Ort in eindeutiger Form aufbewahrt werden. Wo kann man einen so eindeutigen Hauptschlüssel in einem Computer aufbewahren? Die Antwort liegt nicht auf der Festplatte (oder SSD). Es ist unmöglich, einen Klartext-Schlüssel sicher auf der Festplatte zu speichern. Ein Hacker mit physischem Zugriff auf das Laufwerk findet den eindeutigen Schlüssel immer. Software allein kann sie nicht schützen, wenn ein Angreifer physischen Zugang hat.

Hier kommt das TPM ins Spiel. Die TCG entwarf das TPM als einen Hardwaretresor für Geheimnisse, der in das Motherboard eingebettet ist. Bei einigen Designs kann sich das TPM innerhalb des CPU-Chips selbst befinden. Es ist genau für den Zweck der sicheren Aufbewahrung von Schlüsseln konzipiert. Es ist auch viel mehr als nur ein Schlüsselspeicher, worauf wir im nächsten Abschnitt eingehen werden. Im Moment sollte man bedenken, dass ein Computersystem eine Kette von Schlüsseln haben kann, dass aber der Schlüssel am Anfang dieser Kette unverschlüsselt  sein muss und sehr sicher aufzubewahren ist, sodass er nur für vertrauenswürdige Zwecke verwendet werden kann. Das TPM ist dieser Schlüsselspeicher.

CRTM – „Core Root of Trust Measurement“ (Messung der Vertrauensgrundlage)

Ich habe versprochen, dass das TPM nicht nur ein glorifizierter Schlüsselspeicher ist. Denken Sie an das allererste Problem, das ein sicherer Schlüsselspeicher an seinem ersten Arbeitstag hat. Wenn jemand zum TPM sagt: „Kann ich bitte den eindeutigen Schlüssel haben?“, woher weiß das TPM, wer nach dem Schlüssel fragt? Es ist schön und gut, einen Schlüssel sicher aufzubewahren, aber wem werden Sie diesen Schlüssel geben? Ist das ein legitimes Stück des Codes, das zur Verwendung des Schlüssels auffordert, oder handelt es sich um Malware? Hat ein Hacker die Software auf dem PC mit Malware modifiziert und sagt dann ganz höflich: „Liebes TPM, kann ich bitte den Schlüssel benutzen?“ Sie sehen das Problem. Es reicht nicht aus, nur ein äußerst sicherer Schlüsselspeicher zu sein. Sie müssen die Software authentifizieren, die nach der Verwendung dieser Schlüssel fragt. Hier kommt der zweite Trick des TPM ins Spiel – „Core Root of Trust Measurement“ (CRTM).

CRTM arbeitet mit einer Vertrauenskette, die beim Einschalten beginnt. Die Hardware und das TPM arbeiten Hand in Hand, um die Boot-Sequenz des PCs vom ersten Booten über das BIOS/UEFI bis hin zum Hochfahren des Betriebssystems zu „messen“. Es „misst“, ob die Software auf dem PC während des Startprozesses verändert oder manipuliert wurde. Dieser Prozess ist am besten als Sicherer Start bekannt, was heute eine Standardfunktion neuer PC-Kerne ist, die UEFI-Firmware zum Starten des PCs verwenden.

Zur Unterstützung von Sicherer Start wurde mit dem TPM-Design ein Konzept namens PCRs (Plattform-Konfigurationsregister) eingeführt. Die PCR-Werte werden vom TPM in einem Prozess berechnet, der als „Erweiterung der PCR“ bezeichnet wird, ähnlich wie bei der Erstellung einer Blockchain, sodass die PCRs einen eindeutigen Fingerabdruck (d. h. einen Satz Hash) der Startsequenz des PCs haben. Wenn die PCRs aus der Vergangenheit unverändert sind, dann ist auch die Startsoftware im PC unverändert – und das ist kryptographisch garantiert. Es ist unmöglich, dass Malware auch nur ein einziges Byte der gemessenen Startsoftware verändert, ohne die PCR-Werte zu beeinflussen.

tpm diagram 1

Dies ist ein enorm wichtiges Konzept in der Kryptographie. Die so genannte „sichere Hash-Funktion“ ist eine der Verschlüsselung ähnliche Funktion, die einen Datenblock in eine Zeichenkette fester Länge umwandelt, die als Fingerabdruck der Originaldaten fungiert. Wenn sich die Daten ändern, ändert sich der Fingerabdruck. Dies ist daher eine todsichere Methode, um selbst die geringste Änderung an einer großen Software-Datenmenge zu erkennen. Das TPM verwendet eine Variante des Hashings, die als HMAC bezeichnet wird. Ein HMAC ist ein Hash, der ein „Schlüssel-Hash“ ist, was bedeutet, dass nur jemand mit dem richtigen sicheren Schlüssel in der Lage ist, den HMAC-Hash zu erzeugen oder zu verifizieren. Es handelt sich um eine Art „verschlüsseltes Hash“.

Es gibt einen Grund, warum wir diesen Teil so ausführlich behandelt haben. Auf diese Weise garantiert die TPM-Technologie, dass die Kern-Software im Geldautomaten zu 100 % sicher ist. Es gibt keine Möglichkeit, auch nur ein einziges Stück Software in der Boot-Sequenz eines durch ein TPM geschützten Geldautomaten zu verändern, ohne die moderne Kryptographie selbst zu knacken. Es ist auch das Konzept, das wir dann in diesem Whitepaper erweitern, um den gesamten Rest des Geldautomaten zu sichern.

Wir haben jetzt einen sicheren Software-Kern – was ist mit der Anwendungssoftware?

Auf einem Windows 10-Geldautomaten gibt es zwei wichtige Microsoft-Technologien, die an diesem Punkt die Führung übernehmen. Bitlocker und Device Guard (jetzt bekannt als Windows Defender Application Control – WDAC). Bitlocker ist die Laufwerk-Verschlüsselungstechnologie von Microsoft. Es ist in der Lage, die gesamte Festplatte bzw. SSD zu verschlüsseln, und speichert vor allem seinen Laufwerk-Verschlüsselungs-Schlüssel „im TPM“. Eigentlich ist es etwas komplizierter als nur den Schlüssel im TPM zu speichern, aber wir werden das noch etwas näher erläutern.

Denken Sie daran, dass es nicht ausreicht, die Schlüssel sicher aufzubewahren, sondern dass es wichtig ist, vor der Schlüsselfreigabe herauszufinden, „wer“ nach dem Schlüssel fragt. Das TPM verfügt über einen weiteren neuen Trick, der als „Versiegelung“ des Schlüssels bezeichnet wird. Wenn das Laufwerk eines Geldautomaten zunächst in einer sicheren Umgebung verschlüsselt wird und von Windows ein neuer Schlüssel generiert wird, wird dieser Schlüssel dann mit einem separaten „Schlüssel-Verschlüsselungs-Schlüssel“, dem KEK, verschlüsselt. Der KEK selbst wird in einem als „Versiegelung“ bezeichneten Verfahren unter Verwendung der PCR-Werte und eines privaten Schlüssels des TPM weiter verschlüsselt. Wenn der Geldautomat hochfährt, wird der KEK-Schlüssel nur dann verfügbar, wenn alle von den PCRs gemessenen Fingerabdrücke der Kern-Software validiert wurden. Das bedeutet, dass das BIOS und der Windows-Code nicht manipuliert wurden, wie zuvor erläutert. Mithilfe des KEK entschlüsselt Windows seinen Laufwerk-Verschlüsselungs-Schlüssel und verwendet diesen, um das gesamte Laufwerk zu entschlüsseln. Sobald der KEK abgerufen wurde, schließt Windows die „KEK-Tür“ hinter ihm. Dies geschieht durch „Erweitern“ von PCR 11 – was bedeutet, dass PCR 11 nach der Entsiegelung des KEK modifiziert wird, sodass niemand anderes den KEK nachträglich abrufen kann. Der KEK wird vom TPM bis zum nächsten Startvorgang sicher aufbewahrt und nur dann wieder zur Verfügung gestellt, wenn die PCRs bestätigen, dass keine Komponente der Kern-Software manipuliert wurde, und schließt die Tür wieder ab, sobald der KEK Bitlocker zur Entschlüsselung des Laufwerks bereitgestellt wurde.

Wie Sie sehen können, haben wir die Kernsoftware Schritt für Schritt aufgebaut, wobei wir mithilfe von PCRs überprüft haben, um sicherzustellen, dass keine Manipulation stattgefunden hat, bis wir den Startvorgang abgeschlossen und Windows geladen haben. Wir müssen nun die GAA-Anwendungssoftware starten und überprüfen, dass alle von uns ausgeführten Programmdateien nicht manipuliert wurden, bevor wir sie verwenden. Mit anderen Worten: Wir erweitern die gleichen Konzepte der Überprüfung des kryptographischen Fingerabdrucks jeder Softwarekomponente, bevor wir sie verwenden. Dieser letzte Teil der Startkette wird von Windows WDAC (oder Software von Drittanbietern mit ähnlicher Funktion) ausgeführt. Dies wird oft als Whitelisting bezeichnet und führt dazu, dass das Hash (d. h. der berechnete Fingerabdruck) jeder ausführbaren Datei überprüft wird, bevor sie ausgeführt werden darf.

Whitelisting des Geldautomaten

Der beste Weg, GAA-Software unter Verwendung von Windows WDAC (oder anderer Whitelisting-Software) auf die Whitelist zu setzen, ist die Verwendung einer so genannten „Zertifikatregel“. Dies setzt voraus, dass die Software auf Ihrem Geldautomaten vom Entwickler dieser Software vorab signiert wurde. So werden z. B. ausführbare Dateien von Windows 10 von Microsoft mit einem privaten Schlüssel signiert. Das bedeutet, dass jeder überprüfen kann, ob die ausführbaren Windows-Dateien während der Übertragung nicht verändert oder manipuliert wurden und sich in dem identischen Zustand befinden, in dem sie sich zum Zeitpunkt des Signierens durch Microsoft befanden, indem man sie einfach mit Microsofts öffentlichem Codesignatur-Schlüssel verifiziert. Um dies durch WDAC bestätigen zu lassen, muss lediglich eine „Zertifikatsregel“ erstellt werden, die besagt, dass von Microsoft signierte ausführbare Dateien sicher sind. 

In ähnlicher Weise wird die Software von KAL immer mit dem privaten Codesignatur-Schlüssel von KAL signiert. Unsere Kunden können verifizieren, dass die KAL-Software nicht manipuliert wurde, indem sie das Codesignatur-Zertifikat von KAL auf jedem Geldautomaten installieren.

Aber was ist mit anderer Software, die vielleicht nicht auf diese Weise vorab signiert wurde? Banken stehen drei Optionen offen:

  1. Bitten Sie Ihren Anbieter, seinen Code zu signieren.
  2. Kündigen Sie Ihrem Anbieter. (Gibt es wirklich GAA-Anbieter, die ihren Code im Jahr 2020 nicht signieren? Offensichtlich ja).
  3. Verwenden Sie eine „Hash-Regel“.A hash rule is a rule that you add to your whitelist policy for WDAC whereby the bank calculates a hash for each of the files that are from a vendor that has not signed their executables. In other words, you do their code signing for them. Obviously, this is not as good as the code being signed at the origin, as any tampering that occurs in transit between the vendor and the bank cannot be detected (although there might be other mechanisms to ensure secure transmission).

Eine Hash-Regel ist eine Regel, die Sie Ihrer Whitelist-Richtlinie für WDAC hinzufügen, wobei die Bank ein Hash für jede Anbieter-Datei ohne Signatur für ausführbare Dateien berechnet. Mit anderen Worten: Sie führen die Codesignatur für den Anbieter durch. Dies ist natürlich nicht so gut wie der Code, der am Ursprungsort signiert wird, da jegliche Manipulation während der Übertragung zwischen dem Anbieter und der Bank nicht erkannt werden kann (obwohl es andere Mechanismen für eine sichere Übertragung geben könnte).

Ein zweiter Nachteil dieser Art der Implementierung besteht darin, dass die Bank für jede ausführbare Datei eine „Hash-Regel“ erstellen muss. Dies ist weit weniger elegant als die einfache Installation des öffentlichen Zertifikats des Anbieters in den Geldautomaten, das dann alle ausführbaren Dateien dieses Anbieters einschließlich aller zukünftigen Aktualisierungen abdeckt.

Sind wir schon so weit?

Sobald wir an diesem Punkt angelangt sind und der Geldautomat in Betrieb ist, wurde die gesamte Software kryptographisch verifiziert. Keine ausführbare Datei, die in irgendeiner Weise manipuliert oder modifiziert wurde, darf ausgeführt werden. Nicht einmal ein einziges Bit der Gigabytes an ausführbaren Softwaredateien auf einem modernen Geldautomaten kann gehackt werden, ohne dass der Versuch entdeckt und blockiert wird.

Wir sind jedoch noch nicht ganz so weit. Ein auf diese Weise geschützter Geldautomat ist kugelsicher, was die unbefugte Veränderung seines Softwarestapels betrifft. Aber das ist noch nicht das Ende der Geschichte. Das Einschleusen von Malware in den Geldautomaten ist nicht die einzige Methode, einen Geldautomaten anzugreifen. Wir werden nun untersuchen, wie das TPM bei anderen Arten von Angriffen helfen kann.

Verstehen, was TPMs bewirken können

Bei dem TPM geht es nicht nur um die Sicherung des Startvorgangs eines Geldautomaten. Es bietet die Vertrauensgrundlage, die es ermöglicht, auch alles andere zu sichern. Wenden wir uns einem ausgezeichneten Buch zu, das von Mitgliedern der Trusted Computing Group, Will Arthur, David Challener und Kenneth Goldman, geschrieben wurde. Das Buch „A practical guide to TPM 2.0“ (Ein praktischer Leitfaden zu TPM 2.0) ist hervorragend und stellt eine Fundgrube an Ideen dar, die mich zu diesem Whitepaper inspiriert haben. Das Buch kann kostenlos hier heruntergeladen werden.

Der beste Weg, dieses Buch schnell in diesem Whitepaper zusammenzufassen, besteht darin, sich auf die 53 im Buch aufgeführten Anwendungsfälle zu konzentrieren. Mit Erlaubnis der Autoren gebe ich im Folgenden ihre Anwendungsfälle wieder:

1. Speichern von Boot-Parametern

2. VPN-Schlüssel-Zugriff

3. Optimierung des Primärschlüssels

4. Bereitstellung von Identitätsschlüsseln

5. Einem Ressourcenmanager erlauben, TPM-Schlüssel sicher zu verwalten

6. Angreifer ersetzt einen Schlüssel am gleichen Handle

7. UEFI

8. Erkennen eines Neustarts zwischen Nachweisen

9. Hashing einer großen Datei

10. Vertrauenswürdiger Start – 1

11. Vertrauenswürdiger Start – 2

12. Mehrere gleichzeitige TPM-Digest-Algorithmen

13. Speichern von Anmeldekennwörtern

14. Vertrauensgrundlage der Signaturverifizierung

15. Mehrere Primärschlüssel

16. Benutzerdefinierte Primärschlüssel

17. Zertifizieren eines TPM-Kursschlüssels

18. Erstellen einer Zertifikatskette

19. Sicherstellen, dass die Autorisierung eines Schlüssels eine digitale Signatur erfordert

20. Sicherstellen, dass die Autorisierung eines Schlüssels biometrische Daten erfordert

21. Sicherung permanenter Daten

22. Angebots-Äquivalent für einen permanenten Erweiterungs-Index

23. Speichern eines Geheimnisses

24. Speichern eines Zertifikats

25. Speichern eines gemeinsamen Passworts

26. Speichern eines öffentlichen Root-Schlüssels

27. Speichern eines HMAC-Schlüssels

 

28. Zugang zu einem Schlüssel widerrufen

29. Entzug von Mehrbenutzer-Schlüsseln

30. Sicheres Audit-Protokoll der CA-Schlüsselverwendung

31. Zusätzliche PCRs

32. PCRs mit verschiedenen Attributen

33. Virtualisierung

34. Einmal beschreibbarer permanenter Index

35. Standard-Zertifikate

36. Einmal beschreibbarer NV-Index mit permanentem Lesezugriff

37. Sichern eines Richtlinien-Geheimnisses

38. Duplizieren eines Schlüsselsatzes

39. Versiegeln eines Festplatten-Verschlüsselungs-Schlüssels mit Plattformstatus

40. VPN-Schlüssel

41. Sichere Weitergabe eines Kennworts vom vorhandenen Betriebssystem an eine Umgebung ohne Betriebssystem

42. Angebot

43. Erkennen eines Neustarts zwischen Transaktionen

44. Keine Inkrementattribut-PCRs für VMs

45. Keine Inkrementattribut-PCRs für Audit

46. Erstellung verschiedener SrKs für verschiedene Benutzer

47. Eine Reihe von Servern fungiert als ein Server

48. Mit welchem TPM bin ich verbunden?

49. Was ist der Status eines NV-Index, Zählers oder Bitfeldindex?

50. Als PCR verwendeter NV-Index

51. Audit des als Zertifizierungsstelle verwendeten TPM

52. Verwendung des TPM zur Sicherung eines Anwendungs-Audit-Protokolls

53. Sicherstellen, dass sich die PCRs während einer Befehlssequenz nicht ändern

Bitte werfen Sie einen Blick auf die obigen Anwendungsfälle. Das erste, was man zu schätzen weiß, ist, dass es bei TPMs nicht nur darum geht, den Startvorgang zu sichern. Wie wir bereits gesagt haben, ist das TPM die zentrale Vertrauensgrundlage, die es ermöglicht, jeden erforderlichen Schritt beim Geldautomaten Schritt für Schritt zu sichern. Natürlich muss nicht jeder der oben genannten Anwendungsfälle unbedingt auf unsere Branche zutreffen. Und denken Sie daran, dass es in diesen Anwendungsfällen darum geht, den Gegenstand kryptografisch sicher zu schützen.

Nehmen wir als Beispiel Nr. 40 – „VPN-Schlüssel“. Im Normalfall würde ein VPN zwischen einem GAA und einem Server durch die Installation digitaler Zertifikate (d. h. signierter öffentlicher Schlüssel) auf beiden Systemen eingerichtet werden. Aber was passiert, wenn jemand die Zertifikate hackt? Es ist wahr, dass Zertifikate, die in einer TPM-geschützten Windows-Umgebung mit der bisher in diesem Whitepaper beschriebenen Sperre gespeichert sind, unveränderbar wären. Wir können jedoch noch einen Schritt weiter gehen. Die VPN-Schlüssel können mit dem TPM gegen PCRs versiegelt werden. Das bedeutet, dass in dem Moment, in dem das VPN eingerichtet werden soll, die für die Einrichtung des VPN erforderlichen Schlüssel nur dann zur Verfügung gestellt werden können, wenn die PCRs im korrekten Status sind. Bei jeglicher Abweichung wird die VPN-Verbindung verweigert. Bedenken Sie nun, dass dieses Konzept für beide Seiten des VPN-Tunnels gelten kann. Die PCRs müssen sich nicht nur auf der GAA-Seite im korrekten Status befinden, sondern der korrekte Status ist auch für den GAA-Server im Rechenzentrum erforderlich. In diesem Fall hätten wir vor dem Verbindungsaufbau kryptographisch bestätigt, dass sowohl der Geldautomat als auch der Geldautomatenserver in einem sicheren Zustand sind. Wir würden wissen, dass alle ausführbaren Dateien, die bis zu diesem Zeitpunkt sowohl auf dem Geldautomaten als auch auf dem Geldautomaten-Server gelaufen sind, unverfälscht und unangetastet sind, und wir gestatten beiden die Verbindung, wenn – und nur wenn – dieses Szenario von beiden Systemen erfüllt wird.

In diesem Whitepaper möchte ich nicht alle Ideen im E-Book besprechen. In der Tat gibt es zusätzliche Anwendungsfälle, die speziell für Geldautomaten gelten und die diskutiert, entworfen und implementiert werden müssen. Ich hoffe, dass die GAA-Branche dies über einen oder mehrere ihrer Ausschüsse tun wird. Dazu später mehr.

Sichern von Netzwerkverbindungen

Der vorige Abschnitt befasste sich mit der Netzwerksicherheit. Lassen Sie uns das nun etwas ausführlicher untersuchen, da dies ein Anwendungsfall ist, der für Geldautomaten von besonderer Bedeutung ist. Es ist klar, dass wir nicht nur wollen, dass Geldautomaten individuell sicher sind, sondern dass jedes Backend-Serversystem, mit dem wir in Berührung kommen, auch sicher und kompromisslos ist.  Bitte beachten Sie das nachstehende Diagramm:

 

tpm diagram 2

 

Das Diagramm zeigt das Anschlussszenario in einer typischen Großbank mit anspruchsvollen Geldautomatendiensten. Die Geldautomaten sind mit einem Terminal-Handler verbunden, der die Dienste von mehreren Backend-Servern orchestriert. Ein HSM (Hardware-Sicherheitsmodul) bietet kryptographische Dienste und hilft bei der Pin-Zonierung. Sobald eine Transaktion in die Wege geleitet wurde und autorisiert werden muss, wird sie an das Kernbankensystem weitergeleitet, wenn es sich um eine „On Us“-Transaktion handelt, oder an die Kartensysteme, wenn es sich um eine „Off Us“-Transaktion handelt.

Betrachten wir nun eine Sicherheits-Utopie, bei der jeder Geldautomat und jeder Server über ein TPM verfügt (was bei aller neueren Hardware der Fall ist), alle Systeme vom Boot aus mit PCR-Messungen verifiziert wurden und alle TLS-Verbindungen und VPNs mit Zertifikaten eingerichtet wurden, die vom TPM entsiegelt und daher kryptographisch garantiert nicht manipuliert wurden. In der Tat eine Utopie. Der traurige Stand im August 2020 ist, dass nur sehr wenige Banken dieses Sicherheitsniveau erreicht haben.

Eine potenzielle Implementierungs-Herausforderung ist hier die Skalierbarkeit und das Clustering. Wie erstellt man einen Server-Cluster, wenn Verbindungen an einzelne TPMs gebunden sind? Siehe Anwendungsfall Nr. 47 oben – „Eine Reihe von Servern fungiert als ein Server“. Daran hat TCG bereits gedacht.

Sichern der Hardware-Geräteverbindungen des Geldautomaten

Dieses Whitepaper hat sich bisher auf den PC-Kern des Geldautomaten konzentriert und darauf, wie sichergestellt werden kann, dass die Software nach der Inbetriebnahme und während des Betriebs frei von Malware ist. Wenden wir uns nun den einzelnen Hardware-Geräten im Inneren des Geldautomaten zu: dem Kartenleser, dem Pinpad und natürlich dem Bargeldausgeber. Wie ist die Sicherheitslage bei den Verbindungen zwischen dem PC-Kern und den einzelnen Geräten? Bei den meisten Geldautomaten sind diese Verbindungen USB-Verbindungen, die physisch manipuliert werden können. Wenn diese Verbindungen eindeutige Daten haben, ist der Geldautomat anfällig für Angriffe, auch wenn er frei von Malware ist. Lassen Sie uns das noch einmal mit einem Diagramm diskutieren: 

 

tpm diagram 3

 

Wie Sie sehen können, habe ich die USB-Verbindungen als Wolke gezeichnet, um das Angriffsrisiko anzuzeigen. Das TPM sichert den PC-Kern, aber die USB-Kabel sind durch einen Angriff gefährdet, wenn sie nicht geschützt sind. Es liegt wohl in der Verantwortung des Herstellers der Geldautomaten-Hardware, diese Verbindungen zu schützen. Die Situation ist jedoch nicht ganz so einfach, da sie auch von den Anforderungen an die Interoperabilität zwischen den Hardware-Geräten und dem Rest des Systems abhängt. Wenn zum Beispiel die Nachrichten an den CDM (Geldautomat) durchgehend verschlüsselt sind, wo sollte das „andere Ende“ sein? Wenn das andere Ende z. B. beim Terminal-Handler endet, müssen viele Interoperabilitätsanforderungen diskutiert und vereinbart werden.

Es ist auch klar, dass selbst der Bargeldausgeber vieler Geldautomaten noch nicht gut gesichert ist. Sehen Sie die verschiedenen „Blackbox-Angriffe“ in Medienberichten. Ein Angriff auf die Blackbox eines Geldautomaten erfolgt, wenn Hacker die Verbindung zum CDM unterbrechen und mithilfe ihres eigenen PC-Kerns Bargeld ausgeben. Die meisten modernen Geldautomaten haben eine verschlüsselte Verbindung vom PC-Kern zum CDM, aber KAL vermutet, dass das Sicherheitsdesign zu wünschen übrig lässt, da einige dieser Geldautomaten keine TPMs haben. Lassen Sie es uns ganz klar sagen: Kein TPM = Keine Sicherheit. Undurchsichtige Methoden zur Verschlüsselung der Verbindung mit magisch geschützten Schlüsseln bieten keine Sicherheit. Das sind nur Unsicherheit und Hoffen. Wenn Ihr Hardware-Hersteller keine Informationen darüber veröffentlichen kann, wie Verschlüsselungs-Schlüssel geschützt werden, muss klar sein, dass dies daran liegt, dass die Schlüssel nicht richtig geschützt sind.

XFS4IoT- und Hardware-Geräteschutz

Die gute Nachricht ist, dass das XFS-Komitee der GAA-Branche diskutiert, wie die nächste Generation von GAA-Geräten geschützt werden soll. Einige von Ihnen haben vielleicht von der bevorstehenden Veröffentlichung von XFS 4.0 mit dem Namen XFS4IoT gehört. Der IoT-Teil demonstriert die Absicht der Spezifikation, für die moderne IoT-Welt bereit zu sein. Es gibt mehrere Hauptziele für XFS4IoT:

  1. Die Spezifikation ist Betriebssystem unabhängig. Das bedeutet, dass sich im Geldautomaten sowohl Windows als auch Linux oder jedes andere Betriebssystem befinden können.
  2. Es ist Cloud-freundlich. GAA-Geräte können Dienste direkt in der Cloud bereitstellen. Die Kernstücke der Geldautomaten können sich in der Cloud befinden und nicht nur im Geldautomaten, wie es heute der Fall ist. Beispielsweise könnte der Kartenleser die Kartenleserdienste der Cloud aussetzen. Der Bargeldausgeber könnte die Geldausgabedienste der Cloud aussetzen.
  3. Webdienste, die auf diese Weise exponiert werden, müssen sicher sein. XFS4IoT wird über integrierte Sicherheitsfunktionen verfügen, um die End-to-End-Sicherheit der Geräte zu gewährleisten. Das Transportprotokoll wurde als Web-Sockets ausgewählt, die durch TLS mit Zertifikaten auf beiden Seiten gesichert sind. Darüber hinaus kann jedes XFS4IoT-Gerät über ein sicheres Hardware-Element verfügen, um die End-to-End-Sicherheit der Verbindung zu gewährleisten. Diese Verbindung kann innerhalb des Geldautomaten selbst (wie heute üblich) oder auf einem Cloud-Server enden.

Das folgende Diagramm veranschaulicht das Konzept:

tpm diagram 4

XFS4-Geldautomaten können wie die konventionellen Geldautomaten auf der linken Seite des Diagramms gestaltet werden, bei denen die Geräte eine Verbindung zu einer Software-Anwendung auf dem PC-Kern herstellen, oder sie können wie auf der rechten Seite einen sicheren Dienst der Cloud aussetzen. Im zweiten Fall gibt es möglicherweise überhaupt keinen PC-Kern innerhalb des Geldautomaten, und jedes Gerät ist möglicherweise völlig unabhängig voneinander, aber physisch nahe beieinander und arbeitet im Tandem, orchestriert durch die Cloud-Anwendung.

Das Wichtigste sind die grünen Kästchen mit der Aufschrift „HSE“. HSE steht für „Hardware Secure Element“ (sicheres Element der Hardware), und die XFS-Spezifikation lässt es natürlich den Hardware-Anbietern offen, wie sie diese am besten implementieren. Es liegt auf der Hand, dass das HSE entweder ein TPM sein muss oder eine Teilmenge der TPM-Funktionen enthält. Zumindest muss das HSE zu Folgendem in der Lage sein:

  • Private Schlüssel sicher speichern
  • Implementierung eines grundlegenden „Core Root of Trust Measurement“ (CRTM), um sicherzustellen, dass nur sichere Firmware das HSE nutzen kann
  • Implementierung von Verschlüsselungs- und Signaturdiensten

KAL hat dies mit dem TCG-Ausschuss erörtert, und dieser gibt an, dass er der ATM-Branche gerne bei der Ideenfindung für die Optionen behilflich sein würde. Tatsächlich hat der TCG bereits einige Fortschritte mit „Mini-TPM“-Konzepten erzielt. Das eine ist der DICE-Entwurf der TCG und das andere ist der MARS-Entwurf der TCG. Sind DICE und MARS für den Einsatz in der GAA-Branche bereit? Das müssen wir herausfinden.

Ein interessanter Gedanke hierbei ist, ob Standard-TPMs als HSE in jedem Gerät verwendet werden könnten. Aus Kostensicht mag die Antwort ja lauten – TPMs kosten weniger als 1 USD im OEM-Volumen. DICE könnte sogar noch weniger kosten. Für unsere Industrie, die Millionen von Dollar an Verbrauchergeldern schützt, dürften die Kosten für ein TPM oder eine andere Art von HSE kaum der Hinderungsgrund sein.

Geldautomaten haben eine zweite Vertrauensgrundlage – EPP

Wir haben im vorigen Abschnitt über den Schutz von Geräten gesprochen, aber es gibt ein einzigartiges Gerät, das wir im Zusammenhang mit Sicherheit hervorheben müssen, und das ist das EPP („Encrypting Pin Pad“ – verschlüsselndes Pin-Pad). Das EPP ist in der Tat eine unabhängige Vertrauensgrundlage innerhalb des Geldautomaten. Es ist hochgradig sicher, wird über die Anforderungen von PCI PED reguliert und jedes EPP wird individuell verwaltet und von der Branche weltweit verfolgt. Es verfügt über eine eigene CRTM-Messung seiner Firmware und zerstört sich automatisch, wenn eine Manipulation festgestellt wird. Es ist in der Tat sehr sicher.

Das EPP bot jedoch Vor- und Nachteile für die Branche. Da das EPP ein gewisses Maß an Sicherheit für Geldautomaten bietet (wir werden gleich auf die Einschränkungen eingehen), haben sich die Banken bei der Absicherung von Geldautomaten-Transaktionen auf EPPs verlassen. Das EPP speichert den Hauptschlüssel der Bank sicher, und die Verwendung einer Kette von Schlüsseln gewährleistet, dass der Pin-Block sicher ist und die Kommunikationsnachrichten zwischen dem Geldautomaten und dem Host verschlüsselt und MAC-geschützt sind. Dies ist eine gute Sicherheit. Es ist jedoch keine ausreichende Sicherheit.

Das EPP ist nicht verfügbar, wenn der Geldautomat startet, und bleibt so lange nicht verfügbar, bis Windows geladen ist und die XFS SPs (die Hardwaretreiber des Geldautomaten) hochgefahren sind. Das bedeutet, dass das EPP nichts über die Gültigkeit der Software innerhalb des Geldautomaten weiß. Wenn eine mit Malware infizierte Geldautomatenanwendung eine Pin akzeptieren oder eine MAC-Nachricht an den Geldautomaten-Host senden möchte, führt das EPP diesen Befehl aus. Der Schutzumfang des EPP ist zu klein, um zur Sicherung des gesamten Geldautomaten beitragen zu können. Es ist ein Juwel der Sicherheit in einer Masse potenziell ungeschützter Software, in der es kein TPM gibt.

Wie aktualisiert man die Software, wenn sie durch ein TPM geschützt ist?

Der Leser denkt in diesem Stadium vielleicht, dass es schwierig sein wird, gültige Software-Updates durchzuführen, wenn es unmöglich ist, die Software innerhalb eines durch ein TPM geschützten Geldautomaten zu ändern. Denken Sie daran, dass die Anwendungssoftware durch eine Zertifikatsregel geschützt ist. Sie wird vom Anwendungsentwickler signiert (dies kann die Bank selbst oder ein vertrauenswürdiger Anbieter der Bank sein). Es genügt, die aktualisierte Software mit dem sicheren privaten Schlüssel der Software-Entwicklungsorganisation zu signieren, und der Geldautomat akzeptiert die Änderung. So einfach ist das.

Änderungen an der Kern-Software, die durch die PCRs gemessen werden, erfordern einen zusätzlichen Schritt. Die Kernsoftware kann vollständig per Fernzugriff ohne den Besuch eines Technikers aktualisiert werden, erfordert jedoch während des Installationsprozesses die Erstellung eines temporären Schlüssels, der gegen die unveränderten PCRs versiegelt wird. Sobald die Installation abgeschlossen ist, werden die neuen Schlüssel gegen den vollständigen Satz von PCRs versiegelt. Einfach.

Erinnern Sie sich an unser früheres Beispiel zu Windows Hello – gute Sicherheit muss nicht schwierig zu bedienen sein. Tatsächlich ist die erstklassige Sicherheit – die der TPM-Schutz den Banken bietet – im Vergleich zu herkömmlichen Methoden einfacher zu verwenden und kryptografisch sicher.

Verteidigung gegen physische Angriffe

Obwohl wir dies bisher nicht ausdrücklich angesprochen haben, dreht sich ein Großteil der obigen Diskussion um den Schutz des Geldautomaten sowohl vor physischen als auch vor Software-Angriffen. Eine übliche Angriffsmethode auf Geldautomaten besteht darin, das Laufwerk zu entfernen, die Software zu modifizieren und die Änderungen an diesem Geldautomaten sowie an anderen Geldautomaten wiederherzustellen. Diese Angriffsmethode ist nicht möglich, wenn das Laufwerk verschlüsselt ist und die Bootkette durch das TPM geschützt ist.

Eine andere Art von Angriff ist der Versuch, das TPM „mit brachialer Gewalt zu zwingen“ und verschiedene Schlüssel in schneller Folge auszuprobieren. Das TPM verfügt über integrierten „Anti-Hammering“-Schutz, der dies verhindert. 

Schließlich gibt es noch bestimmte andere Arten extremer Angriffe, die direkte Interferenzen mit der Elektronik der Hauptplatine umfassen können. Ein solcher Angriff wäre kostspielig, da er Spezialausrüstung erfordert und bisher noch nicht stattgefunden hat, soweit uns bekannt ist. Es gibt jedoch kostengünstige Möglichkeiten, sich gegen solche Angriffe zu schützen, wie z. B. die Verwendung von Harz zum Schutz freiliegender elektronischer Verbindungen auf der Hauptplatine.

Vorsicht vor „magischen“ Lösungen

Die Sicherung von Geldautomaten und PCs mit TPMs als Vertrauensgrundlage ist die einzige bekannte und veröffentlichte Methode zur vollständigen Sicherung von Computersystemen. Unsere Branche sollte sich fragen, warum TPM-basierte Sicherheit in GAA-Netzwerken nicht häufiger anzutreffen ist. Natürlich werden verschiedene Unternehmen auf dem Markt konkurrieren und ihre Sicherheitsprodukte positionieren wollen. Das ist zu erwarten. Aber es ist sehr wichtig, dass die Banken nicht auf illusorische Lösungen hereinfallen. Hier ist eine Liste von Dingen, auf die Sie achten sollten:

Mythos: „Ein sicheres Hardware-Element ist nicht erforderlich“

Seien Sie sich darüber im Klaren, dass es unmöglich ist, private Schlüssel sicher auf der Festplatte/SSD eines Geldautomaten zu speichern. Der Grund dafür ist, dass es zunächst einen eindeutigen Schlüssel geben muss, egal wie lang der Schlüsselanhänger ist. Wenn dieser Schlüssel auf dem Laufwerk „versteckt“ ist, kann er immer wiederhergestellt werden. Einige Lösungen behaupten, dass sie den Schlüssel beim Start erzeugen. Aber denken Sie daran, dass zur Erzeugung dieses Schlüssels ein unverschlüsselter Code erforderlich ist. Er muss unverschlüsselt sein, da wir das Laufwerk noch nicht entschlüsselt haben. Wenn er eindeutig vorliegt, kann er sehr einfach aus dem ausführbaren Code, der vor der Entschlüsselung des Laufwerks eindeutig vorliegt, zurückentwickelt werden.

Denken Sie darüber auf andere Weise nach: Wenn es möglich wäre, Schlüssel allein mithilfe von Softwaretechniken in einem Geldautomaten zu schützen, hätte sich unsere Branche nicht die Mühe gemacht, EPPs zu bauen …

Mythos: „Es ist kein sicheres Hardware-Element erforderlich, da die Schlüssel im Netzwerk gespeichert werden“

Wenn der Geldautomat nicht sicher genug ist, um die Schlüssel sicher aufzubewahren, weil es kein TPM gibt, ist es nicht möglich, dieses Problem zu lösen, indem die Schlüssel an einen Netzwerkstandort verlegt werden. Und zwar aus folgendem Grund: Wenn der Geldautomat hochfährt, muss er auf das Netzwerk zugreifen, um den sicheren Schlüssel zu erhalten. Er verfügt dann nicht über eine kryptographisch sichere Möglichkeit, sich im Netzwerk zu authentifizieren, da er keinen Schlüsselspeicher hat. Das bedeutet, dass der Netzwerkserver nicht weiß, „wer nach dem Schlüssel fragt“. Wenn Bitlocker zum Beispiel Schlüssel im Netzwerk speichert, benötigt er immer noch ein TPM, um sich im Netzwerk zu authentifizieren. Kein TPM = Keine Sicherheit.

Mythos: „Verschlüsselungs-Schlüssel sind nicht notwendig“

Der Anbieter behauptet, dass die Speicherung von Schlüsseln unnötig ist, da er über eine magische Technologie verfügt, die eine Verschlüsselung ohne Schlüssel ermöglicht. Das wäre in der Tat zu schön, um wahr zu sein. Warum hat die Welt schon immer mit Techniken zur Schlüsselverwaltung gekämpft, wenn man gar keine Schlüssel braucht? Alle bekannten Verschlüsselungstechniken wie 3DES, AES und RSA erfordern private Schlüssel. Private Schlüssel werden so genannt, weil sie sicher gespeichert werden müssen. Was ein Verschlüsselungssystem sicher macht, ist, dass die Schlüssel aus einer wirklich großen Zahl von Möglichkeiten ausgewählt werden. Beispielsweise hat 3DES mindestens 2112 Schlüssel. Man bräuchte 30 Jahre, um alle Schlüssel auszuprobieren, wenn man es mit einer Geschwindigkeit von 5 Milliarden pro Sekunde versuchen würde. Mit AES würde es bei gleicher Geschwindigkeit 1022 Jahre dauern.

Mythos: „Unser Algorithmus ist vertraulich“

Echte Sicherheit beruht auf offenen Standards und offenen Algorithmen zusammen mit vertraulichen Schlüsseln. Der einzige Aspekt eines Sicherheitssystems, der vertraulich sein sollte, sind die Schlüssel. Wenn die Schlüssel kompromittiert werden, ändern Sie sie, und das System ist wieder sicher.

Mythos: „Zugriffskontrolllisten (ACLs) schützen uns“

Zugangskontrolllisten können leicht umgangen werden, wenn keine TPM-Sperre besteht. Es gibt noch verschiedene andere Nachteile von ACLs, auf die wir hier nicht näher eingehen wollen, aber es genügt zu sagen, dass ACLs allein keinen ausreichenden Schutz für Geldautomaten bieten.

Schlussfolgerungen

Ich hoffe, dass der Leser zu einem Verständnis dafür gelangt ist, warum das TPM für die Computersicherheit und damit für die Sicherheit von Geldautomaten von zentraler Bedeutung ist. Ich hoffe, es ist auch klar, dass die meisten Banken noch einen weiten Weg vor sich haben, um ihr Netzwerk kryptographisch garantiert abzusichern. Es ist auch wichtig zu beachten, dass ein solches Sicherheitssystem unter Berücksichtigung der Interoperabilität entworfen werden muss. Da mehrere Anbieter und mehrere Produktlösungen ein Standardbestandteil der modernen Geldautomatentechnologie sind, wäre es nicht möglich, dass Sperren von jedem Anbieter unabhängig implementiert werden. Das würde zu einem Geldautomaten führen, der unbrauchbar ist.

Ich hoffe, dass dieses Dokument der Beginn eines Prozesses ist, der es ermöglicht, interoperable Sicherheitsspezifikationen unter Verwendung der kryptographischen Grundlagen zu entwickeln, die uns durch TPMs zur Verfügung stehen. Die Trusted Computing Group hat uns ihre Hilfe angeboten. Es liegt nun an den verschiedenen Ausschüssen unserer Branche – XFS4IoT, ATMIA und EAST – zusammen mit Banken und Händlern, den Weg in die Zukunft zu gestalten.

Vielen Dank

Ich möchte den folgenden Personen für ihren Beitrag zu diesem Projekt danken:

  • Michael Moltke (NCC Group Denmark)
  • Kit Patterson (KAL)
  • Will Arthur, David Challener und Kenneth Goldman für das Schreiben des E-Books über TPMs und David Challener für die Organisation der Unterstützung durch die TCG

Ihre Kommentare, Fragen und Meinugen sind wilkommen. Bitte beteiligen Sie sich am Blog: kal.com/tpm-whitepaper. Falls Sie noch Fragen zum Whitepaper haben, mailen Sie uns an Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!