Sicherheitsaudit (von Jean Philippe Aumasson)

Wir möchten bekannt geben, dass Ergo erfolgreich den Sicherheitsaudit bestimmter (kritischster) Teile des Codes bestanden hat. Diesmal wurde der Audit von Jean-Philippe Aumasson (auch bekannt als veorq, https://aumasson.jp/) durchgeführt.

Der detaillierte Bericht ist unten. Es wurden keine kritischen Probleme gefunden. Kommentare zu den gefundenen Problemen:

1. Bei dem Wallet-Passwort werden wir in den nächsten Versionen des Protokollclients eine Empfehlung abgeben. Es ist unklar, ob eine strikte Durchsetzung des Passworts stattfinden wird, aber wir werden weitere Konsultationen dazu durchführen.
2. Das Ändern der Parameter "n" und "k" macht nur beim Start eines neuen Netzwerks Sinn. Das Ändern dieser Parameter in einem Mining-Knoten macht die produzierten Blöcke für andere Knoten ungültig. Das Ändern dieser Parameter im Protokollclient bedeutet, dass man auf einen anderen Fork geht (Blöcke, die von den ehrlichen Protokollteilnehmern kommen, werden abgelehnt). Daher sind möglicherweise keine zusätzlichen Überprüfungen erforderlich, da die Personen, die neue Netzwerke starten, "n" und "k" korrekt einstellen werden.
3. Derzeit bietet der Ergo-Knoten (sowie andere Blockchain-Protokollclients und Wallets, von denen wir wissen, sowie die kryptografischen Bibliotheken, die wir verwenden) keinen Schutz vor lokal ausgeführten Seitenkanalangriffen (z. B. Timing-Angriffe oder Speicherinspektionen durch Malware oder Viren). Bitte schützen Sie die Maschinen, auf denen Sie Wallets ausführen!

==========================================================================================================

% Ergo-Sicherheitsbewertung % Jean-Philippe Aumasson % 07/Dez/19

Zusammenfassung

Wir wurden von Ergo gebeten, eine Sicherheitsbewertung mehrerer Komponenten ihrer Ergo-Plattform durchzuführen:

• Erstellung und Überprüfung von Sigma-Protokollbeweisen
• Sichere Speicherung von Geheimnissen im Wallet
• Validierung des Proof-of-Work

​Dieser kurze Bericht fasst unsere Bewertung zusammen und beschreibt unsere Erkenntnisse und Empfehlungen zur Minderung.

Sigma-Protokollbeweise

​Das Ergo-Protokoll basiert auf ErgoScript, einer Skriptsprache, die Sigma-Aussagen unterstützt, die durch nicht-interaktive Wissensbeweise bewiesen und verifiziert werden können.

Diese Beweise sind Aussagen, die als Baum von UND-, ODER- und Schwellenbedingungen beschrieben werden, deren Blätter Beweise für das Wissen über ein diskretes Logarithmusproblem sind.

Der Beweis der Sigma-Aussage wird dann dank der Fiat-Shamir-Transformation nicht-interaktiv gemacht.

Diese Logik ist im ErgoScript-Papier spezifiziert, und die spezifischen
Beweis- und Verifizierungsroutinen sind in Anhang A beschrieben.

​Die Implementierungsherausforderungen bestehen darin:

• Die Kodierung der Beweise zu definieren, die sicher und effizient sind, und die Serialisierung und Deserialisierung zu implementieren, die immer erfolgreich gültige Eingaben verarbeitet und immer elegant ungültige Eingaben verarbeitet.
• Die Beweis- und Verifizierungsfunktionen korrekt zu implementieren, gemäß der Spezifikation, und vor allem so, dass keine ungültige Aussage erfolgreich die Verifizierung bestehen kann.

Wir haben diese beiden Aspekte überprüft, basierend auf dem Code im Repository sigmastate-interpreter und dem ErgoScript-Papier, und sorgfältig das beabsichtigte Verhalten (im Anhang A) mit dem tatsächlichen Verhalten, wie es implementiert ist, verglichen.

​Wir haben insbesondere den Code der SigSerializer, Interpreter und ProverInterpreter Traits und Objekte überprüft.

​Wir haben hauptsächlich nach Fehlern aus den folgenden Klassen gesucht:

• ​Unsichere Verarbeitung von fehlerhaften Eingaben
• Unsichere Verarbeitung von ungewöhnlich langen oder kurzen Eingaben
• Verhalten bei großer Baumtiefe oder Rekursionstiefe
• Unsichere Verwendung von Scala-Typen und -Strukturen
• Unangemessene Variablentypen
• Ganzzahlüberläufe
• Race Conditions
• Logikfehler

​Trotz umfangreicher Überprüfung haben wir kein Sicherheitsproblem identifiziert.

Die Logik und Interna des Protokolls sind dennoch relativ komplex, und wir glauben, dass das höchste Risiko in der Analyse und Verifizierung von Beweisen liegt. Um solche Probleme auszunutzen, müsste ein Angreifer jedoch ein semantisch korrektes Skript erstellen, das ihm irgendwie zugutekommt, das jedoch die Verifizierung besteht, wenn es das nicht sollte.

Was die Software-Sicherheit betrifft, so beseitigt Scala bestimmte Klassen von Fehlern, aber Scala-Code kann dennoch unter Fehlern leiden, die auf das spezifische Verhalten von Scala oder auf nicht behandelte Fehler zurückzuführen sind.

Wallet

Die Wallet-Funktionalität von Ergo ermöglicht es den Benutzern, ein Geheimnis auf der Festplatte zu speichern und es wiederherzustellen, indem die Wallet beim ersten Gebrauch mit einem neuen Seed initialisiert wird.

​Diese Logik ist hauptsächlich in ErgoWalletActor definiert, und ein wichtiger Bestandteil der Speicherung von Geheimnissen ist JsonSecretStorage.

​Beim ersten Erstellen einer Wallet führt der Befehl InitWallet Folgendes aus:

• Generieren Sie settings.walletSettings.seedStrengthBits zufällige Bits als anfängliche Entropie. Standardmäßig werden 160 Bits generiert.
• Generieren Sie einen BIP39 aus den generierten Zufallsbits, der als Kodierung der Entropie-Bits angesehen werden kann. Die Standard-BIP39-Logik wird verwendet, mit optionalem Passwort.
• Leiten Sie einen Seed aus dem Mnemonic unter Verwendung der BIP39-PBKDF2-basierten Ableitungslogik ab.
• Verschlüsseln Sie diesen Seed auf der Festplatte mit AES-GCM, unter Verwendung eines zufälligen Nonce und eines Schlüssels, der aus dem Passwort unter Verwendung von PBKDF2-HMAC-SHA256 mit 128000 Iterationen abgeleitet wird, unter Verwendung eines zufälligen Salzes.

Um eine bereits erstellte Wallet zu entsperren, gibt der Benutzer das Passwort ein und die Wallet versucht, die gespeicherten Daten zu entschlüsseln.

​Um ein bestehendes Konto aus einer BIP39-Passphrase wiederherzustellen, wird ein ähnlicher Prozess wie bei der Initialisierung durchgeführt, mit dem Unterschied, dass die Wallet den Seed aus dem Mnemonic ableitet, anstatt ein zufälliges Mnemonic auszuwählen.

​Die beiden Risiken, die wir hier identifiziert haben, sind:

• Das Fehlen von Überprüfungen zur Länge des Passworts: Da das Passwort ausreicht, um auf den Seed zuzugreifen, der das auf der Festplatte gespeicherte Geheimnis der Wallet ist, sollte das Passwort theoretisch mindestens so viel Entropie wie das Mnemonic haben und in der Praxis praktisch schwer zu knacken sein. Wir empfehlen daher, eine minimale Passwortlänge von beispielsweise 16 Zeichen durchzusetzen.
• Kopien von geheimen Werten (Passwort, Seed und abgeleitete private Schlüssel) bleiben wahrscheinlich im Speicher, nachdem die Wallet-Software ausgeführt wurde, was eine intrinsische Einschränkung von garbage-collected Sprachen wie Scala ist.

Ein anderer Prozess oder Benutzer, der denselben Adressraum im Speicher teilt, könnte potenziell die Geheimnisse wiederherstellen, und sie könnten auch in Absturzprotokollen erscheinen. Nach unserem besten Wissen gibt es keine effektive Minderung in reinem Scala.

​

PoW-Validierung

​Nach der vorherigen Überprüfung der Sicherheit des Autolykos PoW haben wir eine weitere Überprüfungsrunde durchgeführt, die sich auf die neueste Verifizierungslogik konzentriert, insbesondere auf die Änderungen im Commit eb0f85a.

​Die Hauptdatei ist AutolykosPowScheme, und andere wichtige Operationen sind beispielsweise in HeadersProcessor und ModifierValidator implementiert.

​Wir haben überprüft, dass die implementierte Verifizierungslogik mit der in den Autolykos-Spezifikationen angegebenen übereinstimmt und dass sie ordnungsgemäß in die Logik der Blockheader-Validierung integriert ist.

​Wir glauben, dass die folgenden Punkte angesprochen werden sollten:

• Strengere Validierung von k und n: Obwohl die Klasse k<=32 (Anzahl der Elemente in der Lösung) und n<31 (log2 der Gesamtanzahl der Elemente) durchsetzt, könnten dennoch schwache Parameter aus den autorisierten Parametern erstellt werden. Die Funktion validate() könnte daher zusätzliche Validierungen haben, dass n und k den beabsichtigten Werten entsprechen.
• Sicherstellen, dass k und n positive Werte sind, da derzeit negative Werte (als Ints) die assert-Anweisungen bestehen würden.