24. Dez’20
Übersetzung des Blogartikel von Autor Daniel Thompson-Yvetot, IOTA Foundation.
Stronghold ist eine Open-Source-Software-Bibliothek, die ursprünglich zum Schutz von IOTA Seeds entwickelt wurde, aber zum Schutz jedes digitalen Geheimnisses verwendet werden kann. Es ist eine sichere Datenbank für die Arbeit mit Kryptographie, die sicherstellt, dass Geheimnisse (wie etwa der private key) niemals preisgegeben werden. Es bietet eine eigene Peer-to-Peer-Kommunikationsschicht, so dass verschiedene Instanzen sicher über das hochmoderne Noise-Protokoll kommunizieren können. Stronghold wird eine sichere Basis für die neue IOTA Firefly Wallet bilden.
In einer zunehmend vernetzten Welt mit intelligenten Geräten, egal ob Telefon, Stromzähler, Fernseher oder sogar Kreditkarte, wird die Bedeutung von echter Sicherheit nur noch wachsen. IoT-Geräte müssen über feindliche Netzwerke sicher miteinander kommunizieren. Jedem, der dies liest, muss klar sein, dass es eine sehr reale Notwendigkeit gibt, Daten wie Identität und digitale Führerscheine vor zentralisierten Hacks zu schützen. Das Problem ist nicht, dass dieses Risiko unbekannt ist. Es ist nur eine sehr schwierige Herausforderung, die richtig gelöst werden muss. Wir haben diese Herausforderung angenommen, um das IOTA-Ökosystem zu schützen und Bibliotheken zu bauen, die jeder nutzen kann.
Seit der ersten Ankündigung von Stronghold haben wir das Team vergrößert, das Innenleben der Engine überarbeitet und Anwendungen erforscht, die mit Stronghold gebaut werden können. Heute freuen wir uns, das Alpha-Release ankündigen zu können, das den Schritt von der Forschung zur Entwicklung vollzieht. Wir haben diese Version “Saint-Malo” getauft, nach der wunderschönen Festungsstadt an der nordfranzösischen Küste der Bretagne, die nach dem Zweiten Weltkrieg wieder aufgebaut wurde. Dieses einstige Piratenversteck hat sich erholt und überlebt, seine massiven Mauern schützen es vor den gewaltigen Attacken der Gezeiten.
Sie fragen sich vielleicht, was bedeutet “Alpha”? Was macht manche Software zu “Alpha” und manche zu “Beta” – und wann wird sie “stabil”? Diese Stadien in der Software-Entwicklung haben mit der Stabilität des Codes zu tun und mit dem Vertrag, den die Projektingenieure mit den Kunden haben. Im Fall von Stronghold, indem wir unser Projekt als “Alpha”-Qualität deklarieren, sagen wir Ihnen, dass wir denken, dass es gut genug ist, um damit zu experimentieren. Wir haben die Theorie in die Praxis umgesetzt, unsere Annahmen überarbeitet und versucht, etwas zu entwickeln, das den Sweet Spot zwischen maximaler Sicherheit und Benutzerfreundlichkeit findet. Wir sind jetzt an dem Punkt, an dem wir Ihr Feedback wollen, das wir in die nächsten Entwicklungsstufen einfließen lassen werden.
Während der Alpha-Phase können Sie davon ausgehen, dass Stronghold weiterhin so funktionieren wird wie jetzt. Wir werden jedoch einige der internen Mechanismen verändern und möglicherweise auch kleinere Aspekte der offenen API ändern. Wir können nicht empfehlen, dass Stronghold heute von externen Parteien in der Produktion eingesetzt wird, da sich die Dinge bis zum Erreichen der Beta-Phase schnell ändern können – insbesondere während der externen Sicherheitsüberprüfung von Firefly und dessen Integration mit Stronghold. Während der Beta-Phase werden wir Stronghold für ein komplettes Sicherheits-Audit vorbereiten, danach werden wir die Spezifikation und Dokumentation für das stabile Release fertigstellen.
Wenn Sie sich jedoch schon jetzt die Hände schmutzig machen wollen und sich im Umgang mit der Kommandozeile wohlfühlen, gibt es hier eine schnelle Möglichkeit, Stronghold zu testen:
Besuchen Sie die GitHub-Releases-Seite, um das vorgefertigte Stronghold-Kommandozeilen-Binary für Ihre Plattform herunterzuladen. Wenn Sie etwas abenteuerlustiger sind und sich mit Rust auskennen, können Sie das GitHub-Repository klonen und es lokal für Ihr System bauen:
Der Rest dieses Artikels wird die Stronghold-Architektur in größerer Tiefe beschreiben und ist sehr technischer Natur.
Überblick:
- Wie sich Stronghold von anderen Datenbanken unterscheidet
- Stronghold-Engine und internes Akteursmodell
- Neue Client-Schnittstelle
- Härtung von Strongholds
- Dedizierte Kryptographie-crate – crypto.rs
- Releases und sicheres Konsumieren von Stronghold
- X-Teams
Was ist Stronghold und wie unterscheidet es sich von anderen Datenbanken?
Stronghold ist eine Software-Bibliothek, die in der Programmiersprache Rust geschrieben ist. Sie bietet eine verschlüsselte, persistente Datenbank zur Durchführung kryptographischer Operationen in einer sicheren Rechenzone, die über mehrere Geräte verteilt werden kann. Wir wurden schon oft gefragt, worin der Unterschied zwischen Stronghold und anderen Datenbanken besteht. Dieser lässt sich in drei Hauptunterscheidungen zusammenfassen:
- Stronghold-Datensätze (und ihre Dateisicherungen) sind “von Natur aus” verschlüsselt, um Offline-Angriffe abzuschwächen. Bei den meisten anderen Datenbanken müssen Sie die Verschlüsselung selbst vornehmen, durch Bibliotheken, Plugins oder ein zugrunde liegendes verschlüsseltes Dateisystem.
- Stronghold erlaubt es Ihnen, Operationen mit diesen gespeicherten digitalen Geheimnissen durchzuführen, ohne sie externen Prozessen zu offenbaren, und verhindert, dass diese Geheimnisse jemals in entschlüsselter Form exportiert werden. (Siehe Härtung von Strongholds weiter unten)
- Mehrere Strongholds können als Netzwerk arbeiten und auf erlaubte, dezentralisierte Weise kommunizieren und zusammenarbeiten. (Erscheint im Januar 2021).
Stronghold-Engine und internes Akteursmodell
https://github.com/iotaledger/stronghold.rs/tree/dev/engine
Bevor wir in die Details der Client-Schnittstelle eintauchen, ist es wichtig, kurz auf die zugrunde liegende Architektur einzugehen.
Strongholds werden durch eine Binärdatei persistiert, die wir einen “Snapshot” nennen. Diese Dateien sind im Ruhezustand verschlüsselt und können zwischen Geräten und verschiedenen Betriebssystemen transportiert werden. Sobald ein Snapshot entschlüsselt wurde, existiert er als Tresor (oder mehrere Tresore) im Speicher. Um auf einen Datensatz im Speicher zugreifen und ihn entschlüsseln zu können, müssen Sie seinen Pfad kennen. Sobald Sie den Inhalt des Datensatzes haben, können Sie eine Operation mit diesem Datensatz durchführen und die Ergebnisse zurückgeben. Das ist alles sehr kompliziert, und wenn es unsachgemäß gemacht wird, besteht die Gefahr, dass Geheimnisse nach außen dringen, was wir mit Stronghold in erster Linie zu vermeiden versuchen.
Das Actor-Modell ist eine Art von Architektur, bei der einzelne “Actors” sich gegenseitig Nachrichten schicken, anstatt direkt Funktionen aufzurufen und Speicher zu übergeben. Dies ist ein hervorragendes Muster, das nicht nur eine Prozessisolierung bietet, sondern uns auch erlaubt, Nachrichten an andere Geräte zu senden. Wir haben die Schnittstelle, wie Sie weiter unten sehen werden, so gestaltet, dass Sie nicht gezwungen sind, ein Actor-Modell in Ihrem Code zu verwenden, aber es ist verfügbar, wenn Sie es bevorzugen.
Neue Client-Schnittstelle
https://github.com/iotaledger/stronghold.rs/tree/dev/client
Die gesamte Client-Schnittstelle wurde seit unserer ersten Implementierung neu aufgebaut, wobei das Riker-Akteursmodell und das “ask pattern” verwendet wurden. Dies erlaubt es Stronghold, seine interne Architektur zu isolieren, ohne eine höhere Bibliothek oder Anwendung zu zwingen, Riker (oder ein anderes Akteursmodell) zu verwenden.
- Die Schnittstelle kann durch asynchrone Methoden aufgerufen werden, die an das Stronghold-Objekt angehängt sind.
- Bei jedem Methodenaufruf wird ein temporärer Akteur erzeugt und ein Future an die konsumierende Bibliothek zurückgegeben.
- Nach Beendigung des Aufrufs wird der Actor garbage-collected und der Future aufgelöst.
Dies alles ist aufgrund der leichtgewichtigen Akteur-Abstraktionen von Riker möglich.
Das Stronghold-Objekt erzeugt intern mehrere Actor-Systeme, die über einen Client-Pfad-Identifikator definiert werden. Jedes dieser Systeme besteht aus mindestens 2 Akteuren: einem Cache-Akteur und einem internen Stronghold-Akteur, jeweils mit eindeutigen Bezeichnern, die vom Client-Pfad abgeleitet sind. Ein Snapshot-Actor wird hochgefahren, so dass er beim Schreiben eines Snapshots die Daten in allen zugehörigen Client-Systemen gemeinsam kapselt. Umgekehrt wird ein Snapshot, wenn er in das System eingelesen wird, zwischengespeichert und für jedes Paar aus Cache und internem Akteur einzeln gelesen, so dass der Konsument sicherstellen kann, dass die Daten auf vorhersehbare Weise angeordnet werden. Auf diese Weise ist es möglich, einen Teil eines Snapshots oder den gesamten Snapshot zu lesen.
Unter der Client-Abstraktion befindet sich die grundlegende Stronghold-Engine – ein sicheres versioniertes Key-Value-Speicherprotokoll. Dieses System lebt innerhalb des internen Akteurs zusammen mit der zonierten Runtime. Die Versionierung wurde über eine Location-API zu einem Opt-in-Feature gemacht. Jeder Standort definiert eine Beziehung zwischen jedem Client-System und den Tresoren und Datensätzen darin. Ein Client ist eine Sammlung von Tresoren und ein Tresor ist eine Sammlung von Datensätzen, wobei jeder Datensatz einen Teil der Daten enthält.
Die Standort-API ermöglicht es dem Verbraucher, einen generischen Standort oder einen Zählerstandort anzugeben. Der generische Speicherort definiert einen Tresor- und Datensatzpfad, der fest ist. Diese generischen Speicherorte verwenden keine Versionierung und können überschrieben werden. Die Speicherortzähler hingegen verwenden einen Zähler, um den Datensatzindex zu definieren. Wenn ein Verbraucher einen Speicherortzähler verwendet, hat er die Möglichkeit, den Zählerwert entweder direkt anzugeben oder das System dies für ihn tun zu lassen. Wenn der Zähler nicht explizit angegeben wird, verwendet das System standardmäßig den “Kopf” des Tresors. Der Kopf des Tresors wird abhängig von der Operation definiert; wenn die Operation ein Lesevorgang ist, ist der Kopf der letzte Datensatz, der in den Tresor geschrieben wurde, und wenn die Operation ein Schreibvorgang ist, ist der Kopf der nächste Datensatz, der basierend auf dem linearen Zählerwert geschrieben wird.
Neben den grundlegenden datenbankähnlichen Operationen bietet Stronghold über seine Laufzeit eine Reihe von kryptografischen Operationen. Jede dieser kryptographischen Operationen ist als Prozedur definiert. Spezifische Eingaben und Ausgaben werden je nach Bedarf pro Prozedur angegeben. Wenn zum Beispiel ein Verbraucher wie Firefly einen kryptographischen Seed mit Hilfe einer Mnemonik generieren und dann diesen Seed verwenden möchte, um ein Ed25519-Schlüsselpaar abzuleiten, um ein Stück Daten zu signieren, kann er dies tun, indem er die entsprechenden Prozeduren aufruft. “BIP39 Generate” könnte aufgerufen werden, um einen Seed aus einer bereitgestellten Mnemonik zu erzeugen. “SLIP10 Derive” kann auf diesem Seed-Platz aufgerufen werden, um einen Schlüssel zu erzeugen, der wiederum im Stronghold gespeichert wird. “Ed25519 Public Key” kann nun auf diesem Schlüsselspeicherplatz aufgerufen werden, um den benötigten öffentlichen Schlüssel abzuleiten, und dann kann “Ed25519 Sign” aufgerufen werden, um Daten zu signieren. Bei diesem Vorgang sind die einzigen Daten, die vom Stronghold zurückgegeben werden, die Signatur und der öffentliche Schlüssel. Alle anderen Daten werden zur Sicherheit innerhalb des Strongholds an den angegebenen Stellen aufbewahrt.
Härten von Stronghold
https://github.com/iotaledger/stronghold.rs/tree/dev/runtime
Einige Betriebssysteme und Hardware-Plattformen bieten einzigartige Möglichkeiten, die Runtime-Sicherheit zu erhöhen. Wir entwickeln daher eine sichere Rechenzone innerhalb von Stronghold, die Prozess-Sandboxing und Syscall-Filterung verwendet, um eine Rechenenklave zu bilden. Wir verwenden auch einen benutzerdefinierten Speicherallokator mit “Guard Pages”, der es uns ermöglicht, den Zugriff auf den Speicher zu beschränken, wenn er nicht benutzt wird. Diese Enklaven-Tools können von anderen Projekten verwendet werden, auch wenn sie nicht den vollen Funktionsumfang von Stronghold benötigen.
Für die Uneingeweihten: Syscall-Filterung ermöglicht es einem Prozess, seine Rechte für den Zugriff auf Betriebssystem-Ressourcen aufzugeben. Ein Beispiel: Warum sollte ein kryptographischer Algorithmus jemals auf das Dateisystem oder sogar auf Dateideskriptoren zugreifen müssen (zur Erinnerung: unter Unix ist alles eine Datei)? Um diese Einschränkungen anzuwenden, gabelt sich der Wrapper vom Hauptprozess ab (z. B. die Wallet-Anwendung, die UI- und Netzwerkcode enthält) und führt dann die sensiblen Operationen aus. Dies bringt auch zusätzliche Vorteile in Bezug auf die Speicherisolierung und potenziell böswillig erzeugte Threads.
Attribute der Secure Zone
Die folgenden Merkmale der sicheren Zone werden angewendet (sofern das Betriebssystem sie bereitstellt), um die defensive Tiefe der Gesamtsicherheit des Systems zu erhöhen:
- Prozessisolierung: Fork zur Secure Zone (Runtime) und Anwendung einer Acceptlist mit einer sehr restriktiven Menge an erlaubten Syscalls
- Speicherverwaltung: Verwenden Sie innerhalb der Secure Zone nur Zuweisungen mit Guard Pages und restriktivem Speicherschutz
- Kommunikation: Eingehende Anforderungen (TX) werden aus dem elterlichen Speicher gelesen, und das ausgehende Ergebnis (RX) wird verschlüsselt und mit einem ephemeren Schlüssel authentifiziert, der vor dem Forking erzeugt wird.
Es kann auch darauf hingewiesen werden, dass diese Maßnahmen es schwieriger machen, ein bereits kompromittiertes System zu sondieren, d. h. es handelt sich um Defense in Depth, nicht um perfekte Sicherheit. Dafür müssen wir Strongholds auf dedizierter Hardware, wie dem USB Armory Mk-II, herstellen und verteilen.
crypto.rs
https://github.com/iotaledger/crypto.rs
Mit der Entscheidung der IOTA Foundation im Jahr 2019 auf die Programmiersprache Rust umzusteigen, verwenden viele der Software-Bibliotheken und Produkte der Foundation Rust. Es besteht ein wachsender Bedarf an einer ordnungsgemäß überprüften und gepflegten Kryptographie-Bibliothek, die kryptographische Primitive und Algorithmen sammelt, die für Anwendungen in IOTA benötigt werden. Kryptographie muss geprüft, gewartet und ordnungsgemäß überprüft werden.
Leider ist Kryptographie leicht falsch zu machen und Fehler können sehr reale Auswirkungen haben. In der Tat ist dies eines der Hauptziele des IOTA Stronghold-Projekts: Es einfach zu machen, Kryptographie sicher zu benutzen – also setzen wir unsere eigene Philosophie um.
Zu diesem Zweck haben wir bereits die gesamte Familie der von IOTA benötigten Kryptographie integriert:
Quelle: https://github.com/iotaledger/crypto.rs/blob/dev/README.md
Release und sicherer Umgang
Für jede Bibliothek, die auf Sicherheit bedacht ist, ist es wichtig, eine solide Veröffentlichungsstrategie zu haben. Wie viele andere moderne Paketverteilungssysteme, hat Rust das Cargo Crates Ökosystem. Wir veröffentlichen automatisch auf crates.io, indem wir das Covector Polyglot Changelog und den Freigabe-Workflow verwenden, der drüben in der Tauri Community entwickelt wurde. Covector ermöglicht eine schlüsselfertige Veröffentlichungsprozedur, mit einem Minimum an menschlichen Eingriffen und einer überprüften Prozesskette für das Testen, Bauen, Linting, Auditing, Changelogging, das Zusammenführen in den Haupt-Branch, das Erstellen von Git-Release-Tags, das Herstellen von Artifacts (wie das Kommandozeilen-Binary), das Veröffentlichen einer neuen Version auf Github und das anschließende Veröffentlichen auf crates.io.
Bis sich Stronghold und Crypto.rs jedoch stabilisiert haben und alle Ressourcen rein über crates.io (und nicht über Git) verfügbar sind, werden unsere Ressourcen nur auf GitHub verfügbar sein. Wir entschuldigen uns dafür, aber wir arbeiten Tag und Nacht daran, die Crates und ihre Dokumentation richtig verfügbar zu machen.
Obwohl es robust und im Allgemeinen stabiler als NPM ist, ist crates.io immer noch zentralisiert und es macht es schwierig, entfernte Crates zu verifizieren. Aus diesem Grund möchten wir empfehlen, dass Ihr Rust-Projekt Stronghold immer über Git-Hashes konsumiert, da Sie auf diese Weise absolut verifizieren können, dass der Code, den Sie erhalten, das ist, was Sie erwarten.
[dependencies.iota-stronghold]
git = “https://github.com/iotaledger/stronghold.rs”
rev = “fdff9f22c087f0c027e4aaa5a8dbc40218e6cf52”
Vertraue, aber überprüfe.
X-Teams
Sie sind großartig, weil Sie sich diesen ganzen Artikel durchgelesen haben, und deshalb würden wir uns freuen, wenn Sie eng mit uns zusammenarbeiten, um die Zukunft von Stronghold mitzugestalten.
Unabhängig davon, ob Sie sich selbst als Mitglied der IOTA-Community betrachten oder nicht, sind Sie eingeladen, Ihre Erfahrung in Stronghold einzubringen. Dazu bewerben Sie sich bitte über dieses Formular, um in das X-Team aufgenommen zu werden und an dem Kick-Off-Meeting teilzunehmen, das im Januar 2021 stattfinden wird.
Sie können den Fortschritt verfolgen unter: https://github.com/iota-community/X-Team_IOTA_STRONGHOLD