Swift: Paket für homomorphe Verschlüsselung veröffentlicht

• Neues Swift-Open-Source-Paket swift-homomorphic-encryption veröffentlicht
• Homomorphe Verschlüsselung (HE) ist eine Verschlüsselungstechnik, mit der Berechnungen auf verschlüsselten Daten möglich sind, ohne sie zu entschlüsseln
• Der Client sendet verschlüsselte Daten an den Server, und der Server verarbeitet sie und gibt das Ergebnis zurück
• Der Server entschlüsselt die Originaldaten nicht und hat keinen Zugriff auf den Entschlüsselungsschlüssel
• Bietet neue Möglichkeiten, Datenschutz und Sicherheit von Nutzerdaten in Cloud-Services zu schützen

Anwendungsfälle bei Apple

• Homomorphe Verschlüsselung wird für die neue iOS-18-Funktion Live Caller ID Lookup verwendet
• Live Caller ID Lookup sendet verschlüsselte Anfragen an den Server, um Informationen zu einer Telefonnummer bereitzustellen
• Der Server kennt die konkrete Telefonnummer der Anfrage nicht
• Die Funktion kann mit dem Paket live-caller-id-lookup-example getestet werden

Hauptfunktionen

• Unterstützung für Swift on Server, das Hummingbird-HTTP-Framework und plattformübergreifende Nutzung
• Einfaches Benchmarking mit der Benchmark-Bibliothek
• Performante Low-Level-Kryptografie-Primitive aus Swift Crypto

Private Information Retrieval (PIR)

• Live Caller ID Lookup basiert auf Private Information Retrieval (PIR)
• Der Client sendet ein Schlüsselwort an den Server und ruft den zugehörigen Wert ab
• Die Implementierung stellt sicher, dass der Server das Schlüsselwort nicht kennt
• Durch homomorphe Verschlüsselung lassen sich große Datenbanken effizient verarbeiten

Homomorphe Verschlüsselung

• Homomorphe Verschlüsselung ermöglicht Berechnungen auf verschlüsselten Daten ohne Entschlüsselung
• Typischer Workflow:
  • Der Client verschlüsselt sensible Daten und sendet sie an den Server
  • Der Server führt Berechnungen auf dem Chiffrat aus
  • Der Server sendet das resultierende Chiffrat an den Client
  • Der Client entschlüsselt das Ergebnis
• Implementiert das Brakerski-Fan-Vercauteren-(BFV)-HE-Schema
• BFV basiert auf dem RLWE-Problem und ist quantenresistent

Beispiele für den Einsatz homomorpher Verschlüsselung

• Nützlich für verschiedene datenschutzfreundliche Anwendungen
• Beispielcode:

  import HomomorphicEncryption  
  
  // Bfv 체계에 대한 몇 가지 암호화 파라미터를 선택하는 것으로 시작  
  // *이 암호화 파라미터는 안전하지 않으며 테스트용으로만 적합*  
  let encryptParams = try EncryptionParameters(from: .insecure_n_8_logq_5x18_logt_5)  
  
  // 매개변수를 사용하여 HE 계산을 위한 사전 계산을 수행  
  let context = try Context(encryptionParameters: encryptParams)  
  
  // Coefficient 인코딩을 사용하여 N 값을 인코딩  
  let values: [UInt64] = [8, 5, 12, 12, 15, 0, 8, 5]  
  let plaintext: Bfv.CoeffPlaintext = try context.encode(values: values, format: .coefficient)  
  
  // 비밀 키를 생성하고 이를 사용하여 일반 텍스트를 암호화  
  let secretKey = try context.generateSecretKey()  
  let ciphertext = try plaintext.encrypt(using: secretKey)  
  
  // 일반 텍스트를 해독하면 원래 값을 얻을 수 있음  
  let decrypted = try ciphertext.decrypt(using: secretKey)  
  let decoded: [UInt64] = try decrypted.decode(format: .coefficient)  
  precondition(decoded == values)  
  

Zusammenfassung von GN⁺

• Homomorphe Verschlüsselung eröffnet neue Möglichkeiten für Cloud-Services, während die Datenprivatsphäre gewahrt bleibt
• Der Einsatz in einer iOS-18-Funktion von Apple belegt die Praxistauglichkeit
• In der Swift-Community können damit verschiedenste datenschutzfreundliche Anwendungen entwickelt werden
• Andere Projekte mit ähnlicher Funktionalität sind unter anderem Microsoft SEAL und IBM HELib

[GN⁺]

Hacker-News-Kommentare

• Die Abfrage von Telefonnummern ist ein lehrbuchmäßiges Beispiel dafür, dass homomorphe Verschlüsselung in der Praxis nicht funktioniert
• Homomorphe Verschlüsselung ist faszinierend, als würde man eine Simulation in ein Paralleluniversum verschieben, auf das man nicht zugreifen kann
• Wer sich für FHE interessiert, sollte sich Zama.ai ansehen, die vor Kurzem praktische FHE entwickelt haben
• Das dürfte der erste echte Anwendungsfall für HE sein. Im Allgemeinen galt es als zu langsam, um nützlich zu sein, aber das hier ist ein hervorragender Use Case
• Das ist langfristig eine sehr wichtige Ankündigung, auch wenn es sich nicht sofort so anfühlt
  • Das ist eine große Ankündigung für Anwendungsfälle rund um AI und PII
• Ich frage mich, wie sich das im Vergleich zu Zama.ais FHE schlägt
• FHE ist cool, aber ich frage mich, für wie viele Anwendungsfälle es tatsächlich geeignet ist. Es bietet Nutzern bessere Sicherheitsgarantien, aber interessiert es die Nutzer wirklich, wenn eine Organisation verspricht, in der Cloud eine sichere Ausführungsumgebung bereitzustellen?
  • Außerdem muss man aus Engineering-Sicht bei der Nutzung von FHE den Flow refaktorieren und zusichern, dass die gesamte nachgelagerte Verarbeitung festgelegt ist. Wenn Gesetze das nicht vorschreiben, haben Organisationen dann genug Anreiz?
• Der Name ist lustig, weil HME in vielerlei Hinsicht überhaupt nicht schnell ist
  • Ich denke, die echte Lösung sind Secure Enclaves, aber auch die haben ihre Schwierigkeiten
• Was ich über FHE immer wissen wollte: Der Goldstandard moderner Kryptografie ist IND-CCA-Sicherheit. FHE kann diesen Standard definitionsgemäß nicht erfüllen (das Verändern eines Chiffrats mit vorhersagbaren Auswirkungen auf den Klartext ist die Definition eines Chosen-Ciphertext-Angriffs). Wie nah kommen moderne FHE-Schemata also heran? Anders gesagt: Wie viel Sicherheit opfert man, um die Vorteile von FHE zu bekommen?
• Ich verstehe nicht, wie der Server ein Chiffrat mit einem Wert abgleichen kann, ohne den Schlüssel zu kennen. Wie entscheidet der Server, dass dieses Chiffrat einem bestimmten Wert entspricht? Wenn der Server diese Chiffrat-Wert-Datenbank aufbaut, woher weiß er dann, welchen Algorithmus er verwenden muss, um Werte in Chiffrate umzuwandeln und zu speichern?