Stronghold 1.0 Stabiler Release

Ein neuer, verbesserter Weg zur Verwaltung sensibler Daten

TL;DR:
Die stabile Version von Stronghold kommt mit bahnbrechenden Änderungen. Die Client-Schnittstelle zur Interaktion mit der Stronghold-Laufzeitumgebung bietet nun einen typbasierten Ansatz für eine einfachere Integration. Die Verwaltung sensibler Daten im Speicher wurde verbessert, um ein gehärtetes Sicherheitsmodell zu bieten.

Stronghold ist eine sichere, in Rust geschriebene Softwarebibliothek zur Verwaltung sensibler Daten. Lesen Sie weiter, um die Feinheiten von Stronghold zu erfahren, einen Überblick über die Schritte zu erhalten, die uns zu den Entscheidungen brachten, die wir als Team getroffen haben, und nicht zuletzt eine Diskussion über Software-Sicherheit.

Sicherheitsbedenken stehen im Mittelpunkt der DLT-Entwicklung, wobei Angriffe und Hacks zur Entwicklung neuer Verteidigungsmaßnahmen führen. Die IOTA Foundation erlebte im Februar 2020 ihre eigene Sicherheitskrise, als ihre Trinity-Software-Wallet für Desktop- und mobile Betriebssysteme angegriffen wurde, was zum Diebstahl von rund 8,55 Ti in IOTA-Tokens führte. Aus dieser Krise erwuchs die Entschlossenheit, ein quelloffenes Sicherheits-Framework zu entwickeln, das nicht nur die Offenlegung sensibler Daten in der IOTA-Wallet verhindert, sondern letztendlich von jedem und überall genutzt werden kann. Dieses Framework ist Stronghold, das jetzt seine stabile Version erhält (zu finden auf GitHub oder auf Crates.io).

Stronghold wurde erstmals mit dem Start von Firefly vorgestellt, der Rust-basierten IOTA-Wallet, die Trinity ersetzt. Entwickelt von einem Team unter der Leitung von Daniel Thompson und Tensor, wurde Stronghold als sichere Software konzipiert, die Krypto-Seeds, die auf Desktops oder mobilen Geräten gespeichert sind, zuverlässig schützen sollte. Das System, das vor Stronghold zum Schutz von Vermögenswerten diente, nutzte einen Drittanbieterdienst.

Jetzt hat sich Stronghold über eine Funktion der IOTA-Wallet hinaus zu einer Sicherheitssoftware entwickelt, die von jedem integriert werden kann, der Geheimnisse sicher speichern möchte.

Aufbau von Stronghold

Die Implementierung von Sicherheitsfunktionen ist bekanntermaßen schwierig, und in unserer Lieblingssprache Rust gab es keine Bibliotheken mit den spezifischen Funktionen, die wir benötigten. Natürlich gibt es einige industrietaugliche Kryptographie- und Sicherheitsbibliotheken (z. B. libsodium), die erstklassige Funktionen bieten, aber keine erfüllte alle unsere Anforderungen, die da wären

• Eine in Rust geschriebene Softwarebibliothek.
• Datenstrukturen, die sensible Daten verwalten.
• Persistenz und Austausch von sensiblen Daten.
• Hohe Skalierbarkeit.
• APIs, die einen großen Funktionsumfang bieten, ohne dass es zu einem übermäßigen „Feature Creep“ kommt.

Beim Entwurf der Architektur von Stronghold hat das Team einen mehrschichtigen Ansatz gewählt. Der Kern von Stronghold besteht aus der Laufzeitumgebung, die Primitive wie verschlüsselten oder geschützten Speicher (weiter unten genauer erklärt) und zusammenhängende und nicht zusammenhängende Speichervarianten (dito) implementiert.

Auf der Runtime sitzt die Engine, die Datenstrukturen bereitstellt, bestehend aus dem Tresor, einer einfachen Datenbankstruktur und Puffertypen, der Kernlogik zum Laden und Speichern flüchtiger – sprich „in-memory“ – sensibler Daten auf der Festplatte, während sie mit xChaCha20-Poly1305 verschlüsselt und mit LZ4 komprimiert werden.

Die öffentliche API von Stronghold befindet sich innerhalb des Clients und ermöglicht den Zugriff auf die wichtigsten Funktionen. Mit dem Client können Sie Geheimnisse schreiben, komplexe kryptographische Prozeduren ausführen und unverschlüsselte Daten in den unsicheren Speicher schreiben und lesen. Zusätzlich zu den lokal verfügbaren Client-Funktionen unterstützt Stronghold auch die Arbeit mit Remote-Instanzen. Seine Funktionalität unterscheidet sich von herkömmlichen Remote-Passwortspeichern dadurch, dass Geheimnisse und sensible Daten niemals offengelegt werden.

In gewisser Weise verhält sich Stronghold wie ein Handschuhfach, die versiegelten Behälter in einem wissenschaftlichen Labor, die es den behandschuhten Händen erlauben, Objekte im Inneren des Fachs zu manipulieren, ohne den Behälter zu beschädigen. Aber dieser Handschuhkasten enthält Geheimnisse, und die Hände sind die Verfahren, die mit den geheimen Daten durchgeführt werden – sie bleiben behandschuht, wenn sie in den Kasten greifen, weil die „Hände“ die Geheimnisse selbst nie „berühren“.

Eine Herausforderung für ein Sicherheitssystem wie Stronghold besteht darin, dass viele Benutzer gleichzeitig darauf zugreifen können, ohne die Sicherheit zu gefährden. Die Lösung dieser Herausforderung war eine Odyssee für sich und hat uns letztendlich dazu gebracht, die gesamte Architektur zu ändern, wie wir im nächsten Abschnitt erläutern werden.

Gleichzeitigkeit mit Akteurssystemen

Die heutige Rechenleistung ergibt sich aus vielen parallel arbeitenden CPU-Kernen. Jede Software, die nicht eine Form der heutigen Gleichzeitigkeit verwendet, wird schlechter abschneiden als Software, die dies tut. Stronghold ist da nicht anders, und Rust ist eine ausgezeichnete Programmiersprache, die eine Menge an Nebenläufigkeit sowie asynchrone Primitive bietet. Die Diskussion der inhärenten Unterschiede zwischen gleichzeitiger, asynchroner und paralleler Codeausführung würde jedoch den Rahmen dieses Blogbeitrags sprengen.

Stronghold verwendet eine bekannte Gleichzeitigkeitsarchitektur: das Akteursmodell. Die Grundidee des Akteursmodells besteht darin, isolierte Akteure zu haben, die sich jeweils um eine bestimmte Funktionalität kümmern. Die Akteure empfangen Nachrichten mit Daten, auf die sie reagieren sollen, und senden Daten zurück, wenn sie mit der Verarbeitung fertig sind. Da jeder Akteur seinen eigenen Zustand hat und die Gleichzeitigkeit nicht durch den direkten Aufruf von Funktionen, sondern durch das Abrufen von Nachrichten erreicht wird, entfallen die meisten der unerwünschten Gleichzeitigkeitsprobleme. Deadlocks werden nie auftreten. So weit, so gut? Während andere Sprachen (z. B. Elixir) das Actor-Modell mit einem hervorragenden Supervisor usw. bereits eingebaut haben, ist die Integration in Rust mit einer Menge Boilerplate-Code verbunden. Dieser Ansatz implizierte, dass die Benutzer von Stronghold gezwungen waren, ein Akteursmodell in irgendeiner Form zu verwenden. Wir wollten herausfinden, ob wir ein einfaches Interface anbieten können, idealerweise einige primitive Typen, die mit einfachen Funktionsaufrufen bearbeitet werden können, und trotzdem in einem nebenläufigen Setup laufen können, ohne die Kopfschmerzen, die mit Locks und Mutexes einhergehen.

Stronghold ist ein mandantenfähiges System, was bedeutet, dass mehrere Clients, jeder mit seinen eigenen sensiblen gespeicherten Daten, (virtuell) gleichzeitig auf Stronghold zugreifen können. Dies wird als „Gleichzeitigkeit“ bezeichnet, und die Suche nach der richtigen Software zur Verwaltung der Gleichzeitigkeit war ein wichtiges Kapitel bei der Entwicklung von Stronghold.

Zunächst suchten wir nach einem Actor-Framework zur Verwaltung der Gleichzeitigkeit, und nach einer Testphase mit Riker, bevor es eingestellt wurde, entschieden wir uns für Actix. Obwohl Actix eine einfachere Schnittstelle zur Implementierung aller Funktionen mit seinem Akteurssystem hat, mit Nachrichten und Akteuren als Hauptprimitiven, führt es die Akteure nur auf einem einzigen Thread aus und nicht auf mehreren Threads, was den Zustand der Clients isolieren würde. Außerdem verbraucht das von Actix verwaltete Akteurssystem eine unterstützte asynchrone Laufzeit, was bedeutet, dass andere Aufgaben aus anderen Systemen nicht auf der gleichen Laufzeit geplant werden können.

Diese Nachteile bedeuteten, dass Actix letztendlich nicht gut zu Stronghold passte, und wir mussten zugeben, dass das Actor-Framework (obwohl es vom Konzept her großartig ist) dem System unnötige Komplexität hinzufügte, da die meisten Rust-Actor-Modelle so implementiert sind. Also traten wir einen Schritt zurück und tauchten tief in die Architektur ein, um zu sehen, welche Teile ersetzt und welche verbessert werden konnten.

Experimentelle Gleichzeitigkeitssynchronisation

Einführung des Software-Transaktionsspeichers (STM). Was ist das, und wie löst es das Problem? STM gibt es schon seit geraumer Zeit (siehe Nir Shavit und Dan Touitou, Software Transactional Memory in Distributed Computing, Band 10, Nummer 2, Februar 1997). Der Grundgedanke ist, dass jede Operation am Speicher in einer atomaren Transaktion erfolgt. Wann immer der Speicher verändert wird, wird diese Veränderung in ein Protokoll geschrieben. Innerhalb einer Transaktion wird auch das Lesen aus dem Speicher über ein Protokoll abgewickelt. Die Transaktion ist abgeschlossen, wenn alle im Protokoll aufgezeichneten Änderungen in den eigentlichen Speicher übertragen wurden. Eine Transaktion schlägt fehl, wenn ein anderer Thread versucht, den betreffenden Speicherbereich zwischen den Operationen zu ändern. Eine fehlgeschlagene Transaktion kann beliebig oft erneut ausgeführt werden. Die Funktionsweise von Git ist ein wenig ähnlich. Mehrere Entwickler versuchen, Änderungen am selben Zweig zusammenzuführen. Wenn sie versuchen, dieselben Bereiche zu ändern, kommt es zu einem Konflikt, und die Transaktion wird rückgängig gemacht.

Dieser Ansatz garantiert, dass Änderungen im Speicher immer konsistent sind, hat aber eine Einschränkung zur Folge. Da Transaktionen wiederholt werden können, müssen Operationen innerhalb einer Transaktion notwendigerweise idempotent sein und sollten keine Nebenwirkungen haben. Denken Sie im Extremfall an eine Funktion, die eine Rakete abschießt: Sie können den Vorgang nicht einfach rückgängig machen. Ein weiterer Grenzfall bei STM-basierten Ansätzen sind verschachtelte Transaktionen, bei denen Lese- und Schreibvorgänge zwischen zwei Threads abgewechselt werden. Im schlimmsten Fall würden beide Transaktionen unendlich oft wiederholt werden.

Verbesserte Laufzeit

Die verbesserte Laufzeit von Stronghold umfasst mehrere Aspekte, auf die wir im Folgenden eingehen werden.

Gesperrter Speicher und bewachte Seiten

Wie bereits kurz in Bezug auf die Architektur von Stronghold erwähnt, bietet die Laufzeitumgebung Speicher- (bzw. verwaltete Zuweisungs-) Typen für den Umgang mit sensiblen Daten. Ein solcher Typ ist Boxed. Dieser Typ sperrt zugewiesenen Speicher und verhindert, dass er in einem Speicherauszug aufgezeichnet wird. Da das Sperren von Speicher vom Betriebssystem abhängt, stützt sich der Typ Boxed auf die Funktion „sodium_mlock“ von libsodium, die unter Linux die Funktion mlock oder entsprechende Funktionen unter anderen Betriebssystemen aufruft. mlock verhindert, dass der aktuelle virtuelle Adressraum des Prozesses in einen Auslagerungsbereich ausgelagert wird, und verhindert so das Austreten sensibler Daten. Dieser wiederum wird von bewachten Heap-Zuweisungen von Speicher verwendet.

Bewachte Heap-Zuweisungen funktionieren, indem eine Schutzseite vor und am Ende des gesperrten Speichers platziert wird, sowie ein Canary-Wert am Anfang.

Bewachte Heap-Zuweisungen könnten wie folgt aussehen:

Libsodium bietet drei Arten, Speicher zu schützen:

• sodium_mprotect_noaccess: Dies macht den geschützten Speicher unzugänglich. Es kann weder von ihm gelesen noch in ihn geschrieben werden.
• sodium_mprotect_readonly: Dadurch wird der geschützte Speicher schreibgeschützt. Der Speicher kann gelesen, aber nicht beschrieben werden.
• sodium_mprotect_readwrite: Dies ermöglicht das Lesen von und Schreiben in den geschützten Speicher.

Stronghold stellt gesperrten Speicher über die Eigenschaft „LockedMemory“ zur Verfügung, die zwei Funktionen bereitstellt, die implementiert werden müssen:

///Modifies the value and potentially reallocates the data.
fn update(self, payload: Buffer<u8>, size: usize) -> Result<Self, MemoryError>;

///Unlocks the Memory and returns a Buffer
fn unlock(&self) -> Result<Buffer<u8>, MemoryError>;

• RamSpeicher: Der zugewiesene Wert befindet sich im Arbeitsspeicher des Systems.
• FileMemory: Der zugewiesene Wert befindet sich im Dateisystem
• NichtzusammenhängenderSpeicher: Der zugewiesene Speicher ist über den Ram des Systems oder das Dateisystem oder eine Kombination aus beidem fragmentiert.

Nicht zusammenhängende Speichertypen und das „Boojum“-Schema

Nicht zusammenhängende Speichertypen teilen den geschützten Speicher in mehrere Fragmente auf, wodurch Speicherabzüge verhindert werden und es für Angreifer extrem schwierig wird, gespeicherte Daten abzurufen. Im folgenden Abschnitt werden nicht zusammenhängende Speichertypen anhand eines Anwendungsfalls näher beschrieben, der uns häufig begegnet ist und den wir mit einer ziemlich anständigen Methode gelöst haben.

Daten, wie ein Array im Speicher, sind normalerweise zusammenhängend angeordnet. Das bedeutet, dass einzelne Elemente oder ihre Byte-Darstellung an benachbarten Adressen gespeichert werden. Stellen Sie sich eine Zahlenfolge als Adressen vor, an denen die einzelnen Elemente gespeichert sind. Dies ist aus Sicherheitsgründen nicht immer wünschenswert. Stellen Sie sich sensible Daten in einem zusammenhängenden Speicher vor. Ein Angreifer könnte leicht die Startadresse finden und dann den Rest problemlos auslesen. Aber wir können es besser machen. Abgesehen von Betriebssystemen, die den verfügbaren virtuellen Speicher in Speicherseiten einer festen Größe aufteilen (auf *nix-basierten Systemen kann diese Größe 4k Bytes betragen), können wir eine Struktur erstellen, die Verweise auf Teile des Speichers (hier sensible Daten) enthält, wobei jeder Teil zufällig über den Speicherbereich verteilt ist. Ein offensichtlicher Vorteil dieses Ansatzes besteht darin, dass der Speicher leichter genutzt werden kann, wenn die Größe der Datenteile angemessen klein ist.

Eines der größten Probleme, mit denen wir bei der Entwicklung von Stronghold konfrontiert waren, war die richtige Verwaltung der Passphrase. Jedes Mal, wenn Sie einen dauerhaften Zustand aus einer Snapshot-Datei laden müssen, benötigen Sie ein Passwort. Wäre man ein einzelner Benutzer von Stronghold und würde das Lesen und Schreiben interaktiv erfolgen (wobei man jedes Mal das Passwort eingeben muss), wäre das kein so großes Problem. Das Zeitfenster, in dem die Passphrase zum Entschlüsseln und später zum Verschlüsseln verwendet würde, um einen Zustand aufrechtzuerhalten, wäre sehr klein und fast unvorhersehbar. Betrachten wir nun eine Anwendung, die ein ständiges Schreiben in einen Schnappschuss erfordert: Die Passphrase zur erfolgreichen Verschlüsselung des Schnappschusses muss irgendwo im Speicher abgelegt werden. Dies könnte ein großes Problem darstellen: Wenn der Angreifer Zugriff auf den Rechner hat, könnte er einfach den Speicher des laufenden Prozesses auslesen und die Passphrase im Klartext auslesen! Schrecklich! Glücklicherweise gibt es dafür eine Lösung: Sie heißt Boojum Scheme und wurde von Bruce Schneier, Niels Ferguson und Tadayoshi Kohno in Cryptography Engineering beschrieben.

Die Hauptidee hinter dem Boojum-Schema – einem Spezialfall des nicht zusammenhängenden Datentyps – ist die Aufteilung sensibler Daten in zwei oder mehr Teile. Die Scherben haben eine feste Größe und werden nach dem Zufallsprinzip im Speicher abgelegt. Jeder Shard wird kontinuierlich gedreht, d. h. der Inhalt wird gemäß den unten beschriebenen mathematischen Operationen randomisiert. Wenn der Schlüssel benötigt wird, werden die Scherben wieder zusammengesetzt, so dass der ursprüngliche Schlüssel wiederverwendet werden kann, ohne dass ein Eingreifen des Benutzers erforderlich ist. Um die Sicherheit der Scherben weiter zu verbessern, wird der Speicherzugriff auf jeden einzelnen Scherben ebenfalls gesperrt und bewacht, so dass jeder Versuch, auf den Inhalt der Scherben zuzugreifen, sehr schwierig wird.

Mit diesem Schema zum Schutz einer Passphrase, die sich im Speicher befindet, erreichen wir Resistenz gegen Cold-Boot-Angriffe (eine Art von Angriff, bei dem der Speicher nach einem erzwungenen Herunterfahren erhalten bleibt).

Speicher auf Null setzen

Ein wichtiger Aspekt der sicheren Softwareentwicklung ist die Frage, was mit dem Speicher geschieht, wenn er freigegeben wird. In einer idealen Welt würde Speicher, der nicht mehr verwendet wird, entweder mit Nullen oder echten Zufallswerten überschrieben werden. In Wirklichkeit ist die Freigabe aber eher träge. Sensible Daten können im Speicher verbleiben, auch wenn sie vom Betriebssystem freigegeben und zurückgewonnen wurden. Glücklicherweise gibt es bereits eine Rust-Kiste, die alle Annehmlichkeiten des Löschens von Speicher bietet, nachdem er gelöscht wurde: zeroize.

Das Ganze zusammenfügen

Mit der neuen Laufzeitumgebung haben wir nun eine ganze Reihe von Möglichkeiten, um sicherzustellen, dass sensible Daten im Speicher geschützt sind. Nicht zusammenhängende Typen sind ziemlich neu für Stronghold und wir müssen herausfinden, was ein gutes Gleichgewicht zwischen Leistung (alles ist im RAM) und Sicherheit (fragmentiert über RAM und Dateisystem) ist. Es gibt eine weitere Grenze, die das Betriebssystem setzt, wenn es um die maximale Anzahl geschützter Speicherbereiche geht. Auf einigen Linux-Rechnern haben wir die Erfahrung gemacht, dass die Grenze bei ~8000 geschützten Seiten liegt. Um dies zu beheben, haben wir beschlossen, die geschützten Seiten nicht in einem Tresor zu speichern, sondern sie bei Bedarf zu schützen. Die Zahl der sensiblen Daten im Ruhezustand ist vermutlich höher als die Zahl der sensiblen Daten, die für kryptografische Verfahren benötigt werden. Die sensiblen Einträge im Tresorraum werden mit XChaCha20-Poly1305 verschlüsselt, was uns eine gewisse Sicherheit bietet.

Verbesserte Client-Schnittstelle

Seit dem Wegfall des Actix-Actor-Frameworks hat die Client-Schnittstelle einige Änderungen erfahren. Alle möglichen Operationen mit einer laufenden Instanz von Stronghold werden nun über primitive Typen abgebildet.

Kryptographische Prozeduren

Während die zuvor beschriebenen Teile von Stronghold sich hauptsächlich mit dem Schreiben von Geheimnissen befasst haben, stellt sich die Frage: „Was kann man eigentlich mit einem Geheimnis machen, das nie offengelegt wird? Warum sollte man es überhaupt speichern?“

Das Hauptprinzip von Stronghold ist es, eine Alternative zu Hardware-Sicherheits-Tokens zu sein. Dies bedeutet auch, dass kryptographische Operationen auf den gespeicherten Daten ausgeführt werden können. In diesem Sinne bezeichnen wir die Daten als Schlüsselmaterial, eine Folge von Bytes, die einen privaten Schlüssel bilden. Kryptografische Operationen können das Signieren von Daten, das Erstellen neuer Schlüssel, das Ableiten von Schlüsseln oder sogar das Ver- oder Entschlüsseln von Daten umfassen. Jede dieser Operationen ist in ein Primitiv verpackt, das wir „Prozedur“ nennen. Eine „Prozedur“ ist vergleichbar mit einem Funktionsaufruf auf dem sicheren Speicher. Der Typ der Prozedur bestimmt ihre Verwendung. Ein Beispiel wäre eine Prozedur, die einen Schlüssel an einem bestimmten Ort in einem Tresor erstellt oder den öffentlichen Teil eines privaten Schlüssels exportiert. Aber Prozeduren allein sind nicht der einzige Weg, um auf Geheimnisse zuzugreifen.

Stronghold bietet ein Framework zum Aufbau von Pipelines für kryptografische Operationen. Das Pipeline-Muster ist eine Abstraktion über verkettete Funktionsaufrufe. Jede Stufe einer Pipeline kann entweder einen Wert erzeugen – z.B. ein Geheimnis generieren (BIP39 und Mnemonic, Ed25519) – oder einen bestehenden Wert verarbeiten – z.B. einen geheimen Schlüssel aus einem bestehenden Schlüssel ableiten (SLIP10) – oder einen Wert aus einem bestehenden Geheimnis exportieren – z.B. den öffentlichen Schlüssel eines Schlüsselpaares exportieren. Das Prozeduren-Framework ist eine gute Möglichkeit, eine konsistente API für die Arbeit mit Geheimnissen anzubieten, aber es ist nicht die einzige Möglichkeit, auf den Tresor zuzugreifen.

Das Framework ist so abstrahiert, dass Kombinationen von einfachen und komplexen kryptographischen Prozeduren möglich sind. Es ist zu erwähnen, dass benutzerdefinierte Prozeduren mit Stronghold nicht möglich sind, und zwar aus einem einzigen Grund: Da eine Prozedur auf Geheimnisse zugreift, würde die Bereitstellung einer benutzerdefinierten Prozedur es einem Benutzer ermöglichen, ein Geheimnis preiszugeben und zurückzugeben, was gegen eines der Kernprinzipien von Stronghold verstoßen würde.

Bei Operationen mit sensiblen Daten wird das Prozeduren-Framework stark in Anspruch genommen.

// .. we initialize ‚client‘ somewhere before the calls

// This constructs a ‚GenerateKey‘ procedure, that will generate a key at given

//output location in the vault let generate_key_procedure = GenerateKey { ty: keytype.clone(), output: output_location.clone(), };

// Even though this procedure does not create a useful output, the result can be

// used to check for errors let procedure_result = client.execute_procedure(StrongholdProcedure::GenerateKey(generate_key_procedure));

// Front the previously generate key, we want to export the public keylet public_key_procedure = stronghold::procedures::PublicKey { ty: keytype, private_key: output_location, };

Die Zukunft von Stronghold

Mit der Veröffentlichung der stabilen Version 1.0 sind wir zuversichtlich, dass Stronghold einen Reifegrad erreicht hat, um in vielen Anwendungen, die eine zusätzliche Sicherheitsebene benötigen, frei verwendet werden zu können. Aber die Arbeit an Stronghold wird hier nicht enden. Wir sehen in naher Zukunft weitere Erweiterungen und Low-Level-Änderungen an der Architektur. Stronghold ist nur so gut, wie Software-Sicherheit werden kann. Dennoch spricht die Zukunft für die Integration von sicheren Hardware-Modulen. Diese können plattformgebunden (wie ein TPM) oder roamingfähig wie eine Smartcard (z. B. ein Solokey) sein. Viele verschiedene APIs wären erforderlich, um eine einfache Integration von hardwarebasierter Sicherheit zu unterstützen. Daher haben wir uns für einen plattformbasierten Ansatz entschieden, bei dem wir an einer kohärenten API arbeiten, die grundlegende Funktionen für alle Hardwareplattformen mit optionalen Opt-in-Erweiterungen unterstützt.

Eine Kernfunktion, die wir gerne in einen allgemeineren Ansatz einbinden möchten, ist die Möglichkeit, beliebige Prozeduren auf dem Tresor in einer vertrauenswürdigen Umgebung auszuführen. Bislang wird Stronghold mit einer ganzen Reihe von kryptographischen Funktionen und Hilfsprozeduren ausgeliefert. Die Betreuer von Stronghold könnten jedoch weitere Algorithmen oder Hilfsprozeduren benötigen. Im Moment erforschen wir einen neueren Ansatz, um diese „Beschränkung“ auf eine Art und Weise zu nutzen, die mehr Flexibilität bei der Arbeit mit sensiblen Daten bietet, aber gleichzeitig vernünftige Vorgaben zum Schutz des Zugriffs auf diese Daten bereitstellt. Wir sind der festen Überzeugung, dass dies eine erweiterte Hardwareunterstützung erfordert, wie z. B. vertrauenswürdige Ausführungsumgebungen, die entweder in proprietärer Hardware wie Intels SGX oder in Open-Source-Konzepten wie RISC-V Keystone vorhanden sind. Eine weitere Möglichkeit, sensible Daten im Speicher zu isolieren, könnte die Integration von sicheren Hardwaremodulen sein, wobei die bereits erwähnte Erweiterung zur Unterstützung sicherer Hardwaremodule genutzt werden könnte.

Nicht zuletzt liegt es auch an Ihnen, das Beste aus der Stronghold-Bibliothek zu machen. Welche Funktion würden Sie gerne in Stronghold sehen?

Original by IOTA Foundation: https://blog.iota.org/stronghold-1-0-stable-release/