Publication du package Swift pour le chiffrement homomorphe

• Publication du nouveau package open source Swift swift-homomorphic-encryption
• Le chiffrement homomorphe (HE) est une technologie de chiffrement qui permet d’effectuer des calculs sur des données chiffrées sans les déchiffrer
• Le client envoie des données chiffrées au serveur, et le serveur effectue les calculs avant de renvoyer le résultat
• Le serveur ne déchiffre jamais les données d’origine et n’a pas accès à la clé de déchiffrement
• Cela ouvre de nouvelles possibilités pour protéger la confidentialité et la sécurité des données utilisateur dans les services cloud

Cas d’usage chez Apple

• Le chiffrement homomorphe est utilisé dans Live Caller ID Lookup, une nouvelle fonctionnalité d’iOS 18
• Live Caller ID Lookup envoie des requêtes chiffrées au serveur pour obtenir des informations sur un numéro de téléphone
• Le serveur ne connaît pas le numéro de téléphone précis visé par la requête
• Le package live-caller-id-lookup-example permet de tester cette fonctionnalité

Fonctionnalités principales

• Prise en charge de Swift on Server, du framework HTTP Hummingbird et du multiplateforme
• Benchmarking simplifié grâce à la bibliothèque Benchmark
• Primitives cryptographiques bas niveau performantes de Swift Crypto

Private Information Retrieval (PIR)

• Live Caller ID Lookup repose sur le Private Information Retrieval (PIR)
• Le client envoie un mot-clé au serveur pour récupérer la valeur associée
• L’implémentation est conçue pour que le serveur ne connaisse pas ce mot-clé
• Le chiffrement homomorphe permet de traiter efficacement de grandes bases de données

Chiffrement homomorphe

• Le chiffrement homomorphe permet d’effectuer des opérations sur des données chiffrées sans déchiffrement
• Workflow typique :
  • le client chiffre des données sensibles et les envoie au serveur
  • le serveur effectue des calculs sur le texte chiffré
  • le serveur renvoie au client le résultat chiffré
  • le client déchiffre le résultat
• Implémentation du schéma de chiffrement homomorphe Brakerski-Fan-Vercauteren (BFV)
• BFV repose sur le problème RLWE et offre une résistance quantique

Exemple d’utilisation du chiffrement homomorphe

• Utile pour diverses applications de protection de la vie privée
• Exemple de code :

  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)  
  

Résumé de GN⁺

• Le chiffrement homomorphe ouvre de nouvelles perspectives pour les services cloud tout en protégeant la confidentialité des données
• Son intégration dans une fonctionnalité d’iOS 18 d’Apple démontre sa viabilité pratique
• La communauté Swift peut s’en servir pour développer diverses applications axées sur la protection de la vie privée
• Parmi les autres projets offrant des fonctionnalités similaires, on peut citer Microsoft SEAL et IBM HELib

[GN⁺]

Avis Hacker News

• La recherche de numéros de téléphone est un exemple d’école où le chiffrement homomorphe ne fonctionne pas vraiment
• Le chiffrement homomorphe est fascinant, comme si l’on déplaçait une simulation vers un univers parallèle inaccessible
• Toute personne intéressée par le FHE devrait regarder Zama.ai, qui a récemment rendu le FHE pratique
• Ce sera probablement le premier vrai cas d’usage du HE. On le considère généralement comme trop lent pour être utile, mais c’est un excellent cas d’usage
• C’est une annonce très importante à long terme, même si cela ne se ressentira pas immédiatement
  • C’est une annonce majeure pour les cas d’usage liés à l’IA et aux données personnelles identifiables
• Je me demande comment cela se compare au FHE de Zama.ai
• Le FHE est cool, mais je me demande à combien de cas d’usage il convient réellement. Il offre de meilleures garanties de sécurité aux utilisateurs, mais est-ce que les utilisateurs s’en soucient vraiment si une organisation promet un environnement d’exécution sûr dans le cloud ?
  • De plus, d’un point de vue ingénierie, utiliser le FHE oblige à refactoriser les flux et à s’engager sur tous les traitements en aval de manière fixe. À moins que la loi ne l’impose, les organisations auront-elles une motivation suffisante ?
• Le nom est drôle, parce que le HME n’est absolument pas rapide à bien des égards
  • Je pense que la vraie solution, ce sont les enclaves sécurisées, mais elles ont aussi leurs difficultés
• Ce que j’ai toujours voulu savoir à propos du FHE : l’étalon-or de la cryptographie moderne est la sécurité IND-CCA. Le FHE ne peut pas satisfaire ce critère par définition (modifier un chiffré pour produire un effet prévisible sur le texte en clair est précisément la définition d’une attaque par texte chiffré choisi). Alors, à quel point les schémas FHE modernes s’en approchent-ils ? Autrement dit, quelle part de sécurité sacrifie-t-on pour obtenir les avantages du FHE ?
• Je ne comprends pas comment le serveur peut faire correspondre un chiffré à une valeur sans connaître la clé. Comment le serveur décide-t-il qu’un chiffré correspond à une valeur donnée ? Si le serveur construit cette base de données chiffré-valeur, quel algorithme doit-il utiliser pour transformer les valeurs en chiffrés et les stocker ?