Wie VivoPay die sichere Enklave und das CryptoKit nutzte

VivoPay ist eine wahnsinnig sichere Krypto-Brieftasche und nutzt die sichere Enklave moderner Mobilgeräte und Macs sowie das neue CryptoKit-Framework von Apple.

Sichere Enklave

Die Secure Enclave ist ein Chip für Android, iPhone, iPad und Macs, mit dem Sie Ihre biometrischen Daten wie FaceID und TouchID schützen können. Die sichere Enklave ist auch für Entwickler zugänglich und kann eine kleine Anzahl nützlicher kryptografischer Funktionen ausführen:

Ist es also so einfach, dass die Secure Enclave einen privaten Harmony One-Schlüssel erstellt? Nicht ganz. Es stellt sich heraus, dass die Secure Enclave-Chips (sowohl auf Android als auch auf Apple) eine andere Kurve verwenden als Blockchains. Das macht es unmöglich, Schlüsselpaare für die Blockchain in der sicheren Enklave zu erstellen.

Da ein privater Schlüssel nicht aus der sicheren Enklave exportiert werden kann, gibt es außerdem keine Möglichkeit, den privaten Schlüssel zu sichern. Wenn das Gerät verloren geht oder beschädigt wird, geht der private Schlüssel für immer verloren. Selbst wenn es möglich war (es ist nicht möglich), ist es wahrscheinlich immer noch keine gute Idee.

Als Randnotiz: Mit der sicheren Enklave können Sie eine Blockchain von Grund auf neu erstellen, wenn Sie dies wirklich möchten. Ich habe 2018 eine Blockchain für Bildungszwecke erstellt, die genau das tat.

In VivoPay verwenden wir die sichere Enklave zum Ver- und Entschlüsseln der Wallet-Datei, sodass eine Wallet-Datei nur auf dem Gerät verwendet werden kann, auf dem sie erstellt wurde. Dies verbessert die Sicherheit. Wir verwenden Apples Low-Level-Sicherheitsframework für die Berechnung sicherer Enklaven.

Wir verwenden auch ein übergeordnetes Framework namens CryptoKit, um die Sicherungsdatei zu verschlüsseln (wenn der Benutzer die Standardsicherung und nicht die Wiederherstellungsphrase verwendet).

Apple CryptoKit

Als Apple 2019 CryptoKit auf den Markt brachte, gab es einige Verwirrung. Einige Leute (und Veröffentlichungen!) waren der Meinung, dass Apple Kryptowährungen akzeptiert und CryptoKit ein Kryptowährungs-Framework ist. Leider war das nicht der Fall, wie ich in einem Tweetstorm erklärt habe. Stattdessen bietet CryptoKit eine übergeordnete Schnittstelle zu einigen grundlegenden Funktionen der Secure Enclave, z. B. zum Erstellen privater Schlüssel (die nicht mit Blockchains kompatibel sind) sowie zur grundlegenden Verschlüsselung und Signatur für die Einrichtung der SSL-Kommunikation.

In VivoPay verwenden wir CryptoKit zum Verschlüsseln der Wallet-Sicherungsdatei im Standardmodus (der erweiterte Modus zwingt Benutzer, eine Wiederherstellungsphrase aufzuschreiben). Im Quellcode von VivoPay Encryption lautet die relevante Datei Shared / Encryption / BackupEncryption.swift. Die Ver- und Entschlüsselung wird in einer einfachen Struktur namens BackupEncryption gespeichert. Für die CryptoKit-Klasse SymmetricKey befindet sich in einer Erweiterung am Ende der Datei ein praktischer Init.

Die BackupEncryption-Datei enthält drei Methoden:

Wir verwenden einen 256-Bit-Schlüssel für die symmetrische Verschlüsselung und erstellen einen, indem wir einen SymmetricKey-Convenience-Initialisierer aufrufen. Da das Kennwort kürzer als 256 Bit (= 32 Byte) sein kann, verwenden wir den SHA256-Hash des Kennworts und verwenden die ersten 32 Byte des Hash als Schlüssel.

Sobald der Schlüssel erstellt wurde, kann er zur symmetrischen Ver- und Entschlüsselung (in einer symmetrischen Verschlüsselung) verwendet werden. CryptoKit bietet zwei symmetrische Chiffren: die AES-Verschlüsselung (Advanced Encryption Standard) und die ChaCha20-Poly1305-Verschlüsselung. ChaChaPoly ist für den mobilen Einsatz optimiert. Aus diesem Grund haben wir uns für ChaChaPoly in VivoPay entschieden.

Mit dem SymmetricKey Convenience Init ist die Verschlüsselung trivial:

Entschlüsselt also. ChaChaPoly speichert die verschlüsselten Daten (Chiffretext) in einem Behälter mit versiegelter Box. Der Container enthält den Chiffretext selbst sowie eine Nonce. Das Nonce ist eine automatisch und zufällig generierte Zahl, um Doppelspurigkeiten in einer Situation zu vermeiden, in der Daten zwischen Parteien ausgetauscht werden (dies ist für unseren Anwendungsfall nicht relevant). Das Nonce ermöglicht es auch, Datenteile parallel zu verschlüsseln und zu entschlüsseln. Dies ist eine gute Nachricht, liegt jedoch außerhalb des Bereichs dieses Blogposts.

Und das war’s. Dies ist der gesamte Code, der zum Erstellen eines kennwortverschlüsselten Backups erforderlich ist.

Da der symmetrische Schlüssel überall mit einem Kennwort erstellt werden kann und nicht in der sicheren Enklave gespeichert ist, können die verschlüsselten Daten von jedem verschlüsselt werden, der auf jedem Gerät Zugriff auf das Kennwort hat. Genau das benötigen wir für ein Backup, aber nicht für die Wallet-Datei selbst.

Apples Sicherheits-Framework

Im Gegensatz zu anderen Brieftaschen funktioniert das Kopieren von Brieftaschendateien zwischen verschiedenen Geräten nicht. Eine verschlüsselte Brieftaschendatei ist immer an das Gerät gebunden, auf dem die Datei erstellt wurde. Wenn Sie dieselbe Brieftasche auf mehreren Geräten verwenden möchten, müssen Sie eine Brieftasche mithilfe der Wiederherstellungsphrase oder der Sicherungsdatei in iCloud wiederherstellen. Auf diese Weise ist VivoPay sicherer als andere Software-Portemonnaies.

Damit dies funktioniert, muss die Brieftaschendatei entweder mit einem symmetrischen Schlüssel verschlüsselt werden, der in der sicheren Enklave erstellt und gespeichert wurde, oder mit einem öffentlichen Schlüssel, der zu einem privaten Schlüssel gehört, der in der sicheren Enklave erstellt und gespeichert wurde. Leider bietet CryptoKit keine API dafür und wir müssen auf das Sicherheitsframework auf niedriger Ebene zurückgreifen.

Die Schritte ähneln CryptoKit, der Code ist jedoch aufwändiger. Den entsprechenden Code finden Sie im Quellcode von VivoPay Encryption: Die entsprechende Datei lautet Shared / Encryption / WalletEncryption.swift.

Möglicherweise wird in der Datei eine import CryptoKit -Anweisung angezeigt. Dies liegt daran, dass wir eine Verknüpfung aus CryptoKit verwenden: SecureEnclave.isAvailable

Der Code enthält einen Rückgriff auf den Schlüsselbund, falls das Gerät keine sichere Enklave hat (z. B. den iPod Touch oder Macs ohne T1- oder T2-Chip)

Der Code legt dann alle erforderlichen Attribute fest (im folgenden Code nicht dargestellt, aber im Demo-Projekt verfügbar), um einen privaten Schlüssel zu erstellen.

Der private Schlüssel wird mit der Funktion SecKeyCreateRandomKey generiert und der öffentliche Schlüssel wird vom privaten mit abgeleitet, indem SecKeyCopyPublicKey aufgerufen wird. Beachten Sie, dass das Objekt mit öffentlichem Schlüssel den öffentlichen Schlüssel enthält, das von SecKeyCreateRandomKey zurückgegebene Objekt mit privatem Schlüssel jedoch nicht den privaten Schlüssel enthält. Stattdessen enthält das Objekt einen Verweis auf den privaten Schlüssel, der in der sicheren Enklave verbleibt.

Der Verweis auf den privaten Schlüssel und den öffentlichen Schlüssel kann mit der Methode loadKey abgerufen und wiederhergestellt werden. LoadKey erstellt eine Abfrage und sendet die Abfrage mit der Funktion SecItemCopyMatching an die sichere Enklave.

Die Verschlüsselung lautet wie folgt:

Und das Entschlüsseln ist auch ziemlich einfach:

Der Code enthält eine nicht verwendete deleteKey -Methode, mit der Sie den Demo-Code experimentieren und debuggen können.

Wohin als nächstes?

Lesen Sie auch