Bei einer Internetrecherche habe ich entdeckt, dass die Sematicon in München eine kostengünstige Krypto Appliance entwickelt hat, die für eine Vielzahl an IT und Industrie Anwendungen geeignet ist. Als Spezialist für Hardware Security Module (HSM) habe ich mich natürlich sofort dafür interessiert und Kontakt mit sematicon aufgenommen, um diese Appliance zu testen.
Die Hardware
Der Vertrieb hat sofort positiv geantwortet und bereits 5 Tage später war die Appliance im Haus. Hier ein Bild der 1HE Appliance gleich nach dem Auspacken.
Der Appliance lag ein Datenblatt und eine ausführliche englische Dokumentation in Farbe bei. Neben einer ausführlichen Erklärung und Checkliste für die Inbetriebnahme sind auch viele Erklärungen zu den Krypto-Funktionen vorhanden, was besonders für neue Anwender spannend sein dürfte.
Die Rückansicht ist unspektakulär. So offenbart die Ansicht eine 19″ Industrie Appliance mit 230V Anschluss, einem Netzteil mit integriertem Lüfter, 3 NICs, einen VGA Anschluss und einige USB-Anschlüsse. Eine direkte Beschriftung der Anschlüsse gibt es an der Appliance keine, jedoch fand ich diese sofort im englischen Handbuch.
Die Inbetriebnahme
Zuerst entschied ich mich bei der Inbetriebnahme für ein Netzwerksegment mit DHCP Server. Infolge übernimmt die Appliance sofort nach dem Einschalten alle Netzwerkeinstellungen per DHCP. Sobald man einen Monitor anschließt, sieht man am Bildschirm die IP-Adressen der zwei (warum nur zwei?) Netzwerkinterfaces.
Die Dokumentation verrät mir hier die Antwort, warum nur zwei NICs nutzbar sind. Die NIC oberhalb der blauen USB3 Anschlüsse ist ein nicht benutzter Netzwerkanschluss.
Die Lüfter sind angenehm leise und die Appliance hat eine sehr kurze Einbautiefe. Daher kann die Appliance einerseits in einem Büro oder direkt in einer Entwicklungsabteilung und anderseits in einem Wandschrank betrieben werden kann.
Die Kryptographie
Im Manual entdecke ich eine gute Anzahl an Applikations-Schnittstellen, die mich neugierig machen. Jedoch erkenne ich in der Dokumentation keine speziellen Verschlüsselungs- oder Signaturanwendungen, die mit der Crypto Appliance kompatibel sind, später dazu aber mehr.
Im beiliegenden Datenblatt finden sich alle unterstützten Crypto Algorithmen. Einerseits sind das symmetrischen AES Algorithmen, anderseits auch Hashing Methoden von SHA1 bis SHA-512, ebenfalls aktuelle RSA und ECC Kryptographie.
Ergänzend kommt eine Schlüssel-Ableitungen (Key-Derivation-Function) auf Basis von HKDF hinzu, gefolgt von ein paar zusätzliche Funktionen auf dem Datenblatt.
Diese zusätzlichen Funktionen sind Secure-Hardware-Counter, wie in der Stückzahlenfertigung benötigt, ein True Random Number Generator, Schlüsselaustauschfunktionen und ein kryptographischer Lizenzschlüssel-Generator. Wahrscheinlich ähnelt der Generator den Codes auf Rubbelkarten oder Aktivierungs-Codes zu Wertkarten-Aufladung.
Crypto Schnittstellen
In meinen vergangenen Projekten hatte ich öfters mit Hardware Security Modulen zu tun. In der Zwischenzeit habe ich bereits mit allen bekannten HSM Herstellern wie Entrust nCipher, Thales, Gemalto, SafeNet als auch Utimaco gearbeitet, wobei ich kürzlich auch Securosys kennenlernen durfte. Die Netzwerk HSM der Hersteller sind Entrust nCipher nShield, Gemalto/SafeNet Luna SA, Utimco SecurityServer HSM und Securosys Primus HSM. Mir gefällt nicht, dass die Hersteller in der Regel nur komplexe APIs wie PKCS#11, manchmal auch OpenSSL oder Java/JCE, Microsoft CAPI und NG-CSP anbieten, da man diese aufwendig wie eine Smartcard ansprechen muss und selbst einfache Anwendungen ein lange Einarbeitungszeit in die komplexen Schnittstellen bedarf.
Bei der sematicon Crypto Appliance finden sich nur moderne netzwerkfähige Programmierschnittstellen, die ich kurz analysieren möchte.
Schnittstellenübersicht der sematicon N-Series
RESTful JSON API – Gilt als der moderne Nachfolger der SOA/XML oder SOAP Schnittstelle, die auf HTTP/HTTPS GET und POST beruht. Als Ergebnis einer Anfrage erhält man über die Web-Schnittstelle ein JSON Datenpaket, das einfach in jeder Hochsprache genutzt werden kann.
TCP/TLS RAW Socket – Ist eine sehr einfache TCP Schnittstelle, die sich ähnlich wie ein serielles Terminal darstellt. Die Schnittstelle wartet auf einen Befehl, um innerhalb der aktiven TCP Verbindung eine Antwort zurückzuliefern. Testen kann man eine solche Schnittstelle mit jedem Putty, TELNET oder OpenSSL s_client Befehl.
Microsoft CNG Key Storage Provider – eine klassische Microsoft Schnittstelle für den Betrieb einer Microsoft Certificate Authority (CA). Die Schnittstelle ist optional und in meiner Testappliance nicht aktiv. Für die Zielgruppe Industrie und DevOps ist jedoch die CNG KSP Schnittstelle nicht relevant, die Anwenderschicht freut sich eher über die moderne RESTful API.
Das Starten der se.SAM Admin GUI
Über den Hostnamen oder die IP-Adresse und HTTPS auf Port 444 gelangt man auf eine intuitive grafische GUI. Der Startbildschirm zeigt eine Übersicht der aktiv laufenden APIs und Dienste:
Ein Administrator muss sich anmelden, damit Änderungen der „se.SAM N-Series Administration“ durchgeführt werden können. Da die initialen Zugangsdaten der Appliance sind im Handbuch angeführt sind, müssen diese vor der produktiven Inbetriebnahme geändert werden.
Jeder, der schon mal ein Thales nShield (jetzt nCipher nShield), Gemalto/SafeNet Luna SA, Utimaco HSM oder Securosys HSM konfiguriert hat, freut sich über die einfache Nutzung der Admin Funktionen.
Administratoren können neben dem Online-Manual und einer Update-Funktion auch das Web-Server TLS Zertifikat der Appliance laden. Autorisierte Benutzer können auch jederzeit ein Backup per Download oder E-Mail generieren und ein Restore eines Backups starten. Auch eine Synchronisation der Benutzer und Administratoren per Active Directory Service (ADS) und LDAP wird angeboten, genauso wie ein Download von Log Daten.
Benutzer- und Sicherheitskonfigurationen
Users – hier werden die Benutzeraccounts der RESTful / JSON API und auch weitere Administratoren verwaltet. Standardmäßig gibt es einen Benutzer „admin“ als zentralen Admin Account und als Standardbenutzer für die API.
Meine Empfehlung ist für jede Anwendung und jeden Server immer eigene Benutzeraccounts anzulegen, damit Abhängigkeiten zwischen Diensten deutlich reduziert werden.
Cores – vorkonfiguriert sind hier die Crypto-Module der Appliance oder auch Crypto-Cores genannt. Sehr interessant ist, dass nicht nur einen Krypto-Prozessor gibt, sondern gleich zwei Cores in der Appliance arbeiten. Laut Handbuch können die Cores in einer Security-Domäne betrieben werden, um sich die Last teilen, oder in getrennten Security-Domänen. Entweder kann eine getrennte Core-Konfiguration für die Trennung des Produktivnetzes und der Entwicklungsumgebung genutzt werden, oder sogar auch eine Trennung unterschiedlicher Unternehmensbereiche umsetzen werden.
Instance – in diesem Konfigurationsmenü versteckt sich die Konfiguration der aktuellen Appliance. Neben der Rolle (Standalone oder Cluster) werden weitere Einstellungen zum Backup konfiguriert. Ohne besonderen Aufwand können hier die Einstellungen der E-Mail-Schnittstelle, sowie Syslog-Servers und ADS Integration festgelegt werden.
Der HSM Schlüsselspeicher und das Regelwerk
Keyobjects – In diesem Listenformat werden alle Schlüsselobjekte der Appliance aufgelistet, wobei Keyobjekte alle symmetrische AES Schlüssel, als auch RSA Schlüssel und ECC Schlüssel und ebenfalls Counter sind. Aktuell ist die Liste leer.
Rules – in diesem etwas komplexeren Menü erfolgt das Berechtigungsmanagement zwischen Benutzern und Funktionen der Appliance. Obwohl das Menü überladen wirkt, bietet es dennoch ein granulares Rechtemanagement für Benutzer auf die Funktionen. Gleichzeitig regelt die Einstellung die erforderliche Authentisierung und die minimalen Schlüssellängen, die für diesen Benutzer erlaubt sind.
Hier erkennt man das, man Rechte für API-Benutzer in den folgenden Parametern einschränken kann:
- Benutzer
- Core-Nummer
- IP-Adresse
- Authentisierung per:
- IP-Adresse
- Basic User Authentisierung (Username+Passwort)
- Multi-Factor-Authentisierung (MFA) mit E-Mail-Token
- 18 unterschiedliche Krypto-Berechtigungsgruppen
Wie viel Krypto-Regelwerk benötigt man wirklich?
Im Grunde genommen handelt es sich bei einem „User“ um User-Credentials für eine spezielle Anwendung, als typisches Beispiel eine Signaturanwendung auf einem Server. Zuerst definiert der Administrator in einer Regel, ob diese Anwendung nur einen Core, oder beide Cores nutzen darf, dann die Authentisierung. Sollte eine Authentisierung per IP-Adresse nicht ausreichen, empfiehlt sich eine Passwortanmeldung per Basic-User Authentication. Auch die besondere Anforderung einer Multi-Faktor-Authentisierung mit einer E-Mail-MFA wird an dieser Stelle definiert. Zum Beispiel ermöglicht eine Regel RSA und AES zu deaktivieren, um ausschließlich ECC Kryptographie zu erlauben. Zuletzt deaktiviert man alle Häkchen außer „Allow sign/hash/certificate functions“, folglich wird so die Funktionsnutzung auf ein Minumum eingeschränkt. Das ist einfach!
Zurück zu den Benutzer- und Sicherheitskonfigurationen, es gibt noch zwei Einträge:
Systemstates – eine interne Ansicht die dem Service View entspricht.
Usages – Die Nutzungs-Ansicht ist aktuell leer. Laut Dokumentation quantifiziert die Appliance das Nutzungsverhalten aller Applikationsuser. Zum Beispiel misst die Appliance infolge wie viele Verschlüsselungs- oder Signaturbefehle eine Anwendung bereits genutzt hat. Meiner Meinung nach optimal, um später die Berechtigungen einer Anwendung auf ein Minimum zu reduzieren. Siehe auch das heute notwendigen Konzept Secure by Design und das Prinzip Principle of least privilege.
sematicon Lösung: weitere Konfiguration
Die se.SAM N-Series Administration ermöglicht primär die Einstellungen der Kryptographie-Funktionen und Nutzung des HSMs. Moment mal, ist die Appliance überhaupt ein HSM?
Inzwischen habe ich sowohl die Doku und das Datenblatt gesichtet, jedoch referenziert der Hersteller in keinem der Dokumente auf die Begriff Hardware Security Modul beziehungsweise HSM noch Hardware-Sicherheitsmodul.
Wie ist ein Hardware Security Modul / HSM definiert?
Ein HSM oder auf Deutsch „Hardware-Sicherheitsmodul“ ist laut Wikipedia:
Der Begriff Hardware-Sicherheitsmodul oder englisch Hardware Security Module (HSM) bezeichnet ein internes oder externes Peripheriegerät für die effiziente und sichere Ausführung kryptographischer Operationen oder Applikationen. Dies ermöglicht zum Beispiel, die Vertrauenswürdigkeit und die Integrität von Daten und den damit verbundenen Informationen in geschäftskritischen IT-Systemen sicherzustellen. Um die Vertrauenswürdigkeit zu gewährleisten, kann es erforderlich sein, die zum Einsatz kommenden kryptographischen Schlüssel sowohl softwaretechnisch als auch gegen physische Angriffe oder Seitenkanalangriffe zu schützen.
https://de.wikipedia.org/wiki/Hardware-Sicherheitsmodul
Aufgrund der verschlossenen Appliance die im Rechenzentrum betrieben wird, sehe ich die Schlüssel gleichwohl softwaretechnisch, als auch physisch geschützt.
Grundsätzlich erfordert ein Seitenkanalangriffe zumeist eine taktgenaue Messung des Stromverbrauchen direkt am Crypto-Prozessor. Umso mehr funktioniert ein solcher Angriff bei einer Netzwerkappliance im Server-Rack nicht.
Welche Algorithmen sind erforderlich?
Auch verweist derselbe Wikipedia Artikel auf die gängigen Algorithmen, die ein HSM unterstützen soll:
In einem HSM können verschiedene kryptographische Algorithmen implementiert sein:
https://de.wikipedia.org/wiki/Hardware-Sicherheitsmodul
– Asymmetrisches Kryptosysteme, z. B. RSA (Verschlüsselung oder Signatur), ECDSA, Diffie-Hellman-Schlüsselaustausch, Elliptic Curve Cryptography
– Symmetrische Ver- und Entschlüsselung: AES, DES, Triple-DES, IDEA
– Kryptographische Hashfunktionen: SHA-1
– Erzeugung von Zufallszahlen, Schlüsseln und PINs (sowohl physisch, als auch deterministisch)
Bis auf die symmetrische Ver- und Entschlüsselung mit DES, 3DES und IDEA habe ich alle Funktionen in der Sematicon N-Series Appliance gefunden. Folglich ist die Appliance ein Netzwerk HSM, denn es erfüllt alle typischen Anforderungen.
Auch werden die Schlüssel nicht in Software abgelegt, sondern in einem eigenen Modul, das in der Appliance eingebaut ist. Die Kryptographie wird also nicht von der CPU übernommen sondern von einem dedizierten Krypto-Prozessor. Die Specs hierzu muss ich aber noch recherchieren.
Jetzt aber wieder zurück zu den weiteren sematicon HSM Konfigurationen
Anstatt über die grafische Admin GUI erfolgt die Konfigurationen der Dienste und der Zugangsdaten über eine zusätzliche Konsole. Die Konsole ist sowohl per Tastatur und VGA-Bildschirm, als auch per SSH erreichbar. Um Administratoren die Arbeit in Serverräumen zu ersparen, ist nach der Netzwerkkonfiguration die Nutzung von SSH zu empfehlen. Hier ein Überblick über die Funktionen der netadmin Konsole:
Ach ja, hier gibt es mit tls cert auch die Möglichkeit ein passendes TLS Zertifikat zu generieren, oder ein Unternehmenszertifikat zu importieren/generieren.
Nutzung der sematicon RESTful / JSON API
Über den Hostname oder die IP-Adresse und HTTP Port 80, als auch über HTTPS Port 443 kann die RESTful API genutzt werden.
Anmerkung: Ich überspringe hier im Unboxing die Initialisierung der Crypto-Cores, da der Prozess sehr gut im Handbuch beschrieben ist. Der Prozess dauert nur rd. 1 Minute. Erwähnenswert ist eventuell jedoch, dass eine Rollenteilung bei der HSM Initialiserung möglich ist, womit auch organisatorische Anforderungen berücksichtigt werden können.
Im Handbuch sind die rd. 50 Befehle gelistet, die über die unterschiedlichen APIs genutzt werden können. Ich entscheide mich über die GET-API die man einfach auch im Browser aufrufen kann. Der Befehl „gensymkey“ hat drei Parameter. Die AES Schlüssellänge, den ACL (hier FFFF) und die geheime PIN des Schlüssels, in meinem Beispiel „pin123456“.
Hier der Aufruf und das Ergebnis, nämlich die KeyID „hsm0201237A8C224FC92BEE0000000000000001“
Wow! Ich habe soeben einen AES-256 Schlüssel auf der Appliance erzeugt. Den Schlüssel werde ich fortan für weitere Befehle wie Verschlüsselung, Entschlüsselung, Schlüsselableitung, etc. nutzen.
Was ist nun das Besondere an einem HSM generierten Schlüssel?
Der mit gensymkey generierte Schlüssel sieht eigentlich nicht wie ein AES-256 Schlüssel aus. Diese sehen meist so aus:
$ openssl rand 32 > aes-keyfile.key $ od -x aes-keyfile.key 0000000 fd92 5710 54c3 6826 1e4c 4584 5acf 906b 0000020 ade4 a857 68fd e01e 1fe8 2328 28d3 4938 0000040
Das HSM jedoch liefert über die API nur eine Referenz (die KeyID) zu dem Schlüssel zurück, den kann man auch jederzeit in der Admin-GUI unter Keyobjects finden. Der tatsächliche AES Schlüssel ist direkt in dem Hardware-Crypto-Modul der Appliance gespeichert und wird nur über diese KeyID identifiziert. Dies stellt sicher, dass vertrauliche Signatur und Verschlüsselungsschlüssel niemals die Appliance verlassen können, jedoch von autorisierten Anwendungen diese Schlüssel jederzeit genutzt werden können. Für die Schlüsselnutzung benötigt eine Anwendung oder ein Benutzer: Zugriffsrechte z.B. Benutzername + Passwort, die Key-ID und natürlich die bei der Schlüsselerstellung vergebene PIN für den Schlüssel. In meinem Fall war das die wenig kreative PIN „pin123456“.
Aber wo sind die Schlüssel wirklich gespeicher? Laut Handbuch auf einem Crypto-Core, also einer speziellen kryptographischen Hardware die in der Appliance eingebaut ist. Näheres erfährt man, wenn mit in dem Netadmin Tool den Befehl „check modules“ aufruft. Hier sieht man die Statusinformationen der beiden Crypto-Prozessoren die eine eigene Firmware in Version 4.0.2. haben. Den Befehl getinfo() und stest(0) habe ich übrigens auch im Handbuch wiedergefunden, diese lesen den Corestatus aus, bzw. überprüfen dessen Funktion.
Auf jeden Fall möchte ich in meinem nächsten Artikel die Applikations-Schnittstellen intensiv kennenlernen, daher werde ich in Kürze meine erste Anwendung an das Sematicon N-Series HSM anbinden.
Auch werde ich mich demnächst mit der Leistungsfähigkeit wie der Krypto-Performance der Appliance beschäftigen. Kann man wie bei anderen teuren HSM Lösungen auch hunderte Signaturen pro Sekunde ausführen? Wie viele Anwendungen/Server können sich gleichzeitig verbinden? Und wie viele Schlüssel kann man pro Appliance speichern?
Wenn Ihr Fragen habt, meldet Euch bitte über mein Kontaktformular oder schreibt jetzt ein Kommentar!