Helius startet verschlüsselte Solana-Transfers mit verbleibenden Vertrauensanforderungen an Betreiber

Helius hat am 10. November den erlaubnisfreien Privacy Ring im Solana-Mainnet gestartet. Privacy Ring verbirgt Zahlungswerte und Beträge durch Verschlüsselung, während die Wallet-Adressen von Sender und Empfänger öffentlich bleiben. Solana überprüft die Einhaltung der Protokollregeln, doch die Vertraulichkeit während der Beweiserstellung hängt von der Abschottung, der Software und den Bereitstellungsrichtlinien des Proof-Generators ab.

Im Wallet-Integrationshandbuch von Helius wird eine attestierte AWS-Nitro-Enklave als standardmäßiger Dienst der SDKs zur Erstellung von Zero-Knowledge-Beweisen genannt. Laut dem Handbuch erfordert die Beweiserstellung unverschlüsselte Nullifier-Schlüssel und vollständige Transaktionsdaten. Die Protokollspezifikation nennt private Ausgabeeingaben wie Vermögenswerte, Beträge, Blinding-Werte, Nullifier-Geheimnisse und Mitgliedschaftspfade im Zustandsbaum. Zu den Eingaben für den Beweis zählen der Spezifikation zufolge auch Ausgabewerte, Beträge und Blinding-Werte. Die Beweissoftware liest diese Eingaben innerhalb der Enklave. Der dokumentierte Client verschlüsselt Anfragen mit einem Schlüssel, der von der attestierten Enklave gehalten wird, um die Eingaben vor dem Host-Betreiber abzuschirmen.

Das Nullifier-Geheimnis erzeugt zudem Kennzeichen, die wiederholte Ausgaben verhindern. Bei einer nativen Wallet-Integration verbleibt der Signierschlüssel in der Wallet. Das TypeScript-SDK überlässt das Signieren der fertigen Solana-Transaktion dem Signierer der Anwendung. Helius dokumentiert eine lokale Entschlüsselungsoption, bei der der Viewing Key auf dem Gerät bleibt. Helius dokumentiert außerdem eine delegierte Entschlüsselung, bei der ein autorisierter Anbieter einen Viewing Key erhält. Damit kann der Anbieter Kontostände und Transaktionsverläufe einsehen, ohne Ausgaben autorisieren zu können.

AWS zufolge verhindern Nitro Enclaves, dass Prozesse und Administratoren auf der übergeordneten Instanz auf den Enklavenspeicher zugreifen. Laut AWS verfügen Enklaven weder über dauerhaften Speicher noch über interaktiven Zugriff oder externe Netzwerkverbindungen. Das signierte Attestierungsdokument von AWS enthält kryptografische Fingerabdrücke, die das Enklaven-Image und die Software identifizieren. Die dokumentierten Prüfungen von Privacy Ring validieren die Zertifikatskette, die Challenge-Antwort, die Aktualität, genehmigte Messwerte und die Bindung des Verschlüsselungsschlüssels an die Anfrage. Eine Wallet kann eine geprüfte Release-Richtlinie oder eine Netzwerkrichtlinie auswählen, die über im SDK hinterlegte Signierer authentifiziert wird. Signierte Richtlinien werden während der Attestierung aktualisiert und laufen nach ihrer Verwendung ab.

Wallet-Software kann überprüfen, ob Image und Verschlüsselungsschlüssel einer Enklave einer genehmigten Richtlinie entsprechen. Die Genehmigung eines Images setzt jedoch weiterhin Vertrauen in die Software und die Personen voraus, die sie prüfen. Laut dem Nitro-Bereitstellungshandbuch umfasst das gemessene Image den Proof-Generator, das Startskript, das Zertifikatpaket, zulässige externe Hosts, die Indexer-URL und die KMS-Schlüsselidentität. Das Handbuch beschreibt, wie der AWS Key Management Service einen gemeinsamen Verschlüsselungs-Seed nur an Enklaven mit übereinstimmender Attestierung ausgibt. Clients können laut Handbuch die KMS-Schlüsselrichtlinie nicht einsehen und müssen sich für diese Garantie auf die Bereitstellung durch den Betreiber verlassen. Als Vertrauensanker bei der erstmaligen Festlegung der Richtlinie nennt das Handbuch AWS KMS, AWS Support, Nitro-Hardware und den Betreiber.

Verschlüsselte Anfragen legen der übergeordneten Instanz weiterhin Metadaten offen, darunter Pfade, Abfragen, Zeitpunkte und Größen. Der Anfragepfad gibt die Struktur des Schaltkreises für den Beweis preis. Der Leitfaden zur versionierten Trusted Execution Environment dokumentiert einen Mainnet-Build auf Basis von v0.6.0-alpha mit Herkunftsnachweis für den gemessenen Build. Dieser Build unterscheidet sich vom Dokumentations-Tag ts-sdk-v0.8.0-alpha. Die Spezifikation erlaubt Clients, Beweise lokal zu erstellen. Das Repository stellt Tools für Localnet und herunterladbare Proof-Generator-Binärdateien bereit.

In der Startankündigung von Helius heißt es, Certora, zkSecurity und OtterSec hätten die Programme und Schaltkreise geprüft. Auf der Sicherheitsseite von Helius wird Certora für Oktober und zkSecurity für August aufgeführt. Der Bericht von OtterSec ist auf der Sicherheitsseite jedoch als ausstehend gekennzeichnet. Wallet-Entwickler, die den Start integrieren, müssen entscheiden, welcher Code und welcher Bereitstellungsrichtlinie sie die Eingaben für die Beweiserstellung anvertrauen.