Swift、Homomorphic Encryption（準同型暗号）パッケージを公開

 (swift.org)
12 ポイント 投稿者 GN⁺ 2024-08-01 | 1件のコメント | WhatsAppで共有
  • 新しいSwiftのオープンソースパッケージ swift-homomorphic-encryption を公開
  • 準同型暗号（HE）は、暗号化されたデータを復号せずに演算できる暗号技術
  • クライアントが暗号化されたデータをサーバーに送り、サーバーはそれを演算して結果を返す
  • サーバーは元データを復号せず、復号鍵にもアクセスしない
  • クラウドサービスにおいて、ユーザーデータのプライバシーとセキュリティを保護する新たな機会を提供

Appleの活用事例

  • iOS 18の新機能 Live Caller ID Lookup に準同型暗号を使用
  • Live Caller ID Lookup は暗号化されたクエリをサーバーに送り、電話番号に関する情報を提供
  • サーバーはリクエスト内の特定の電話番号を知ることができない
  • live-caller-id-lookup-example パッケージを通じて機能をテスト可能

主な機能

  • Swift on Server、Hummingbird HTTPフレームワーク、クロスプラットフォームをサポート
  • Benchmarkライブラリによる容易なベンチマーク
  • Swift Crypto の高性能な低レベル暗号プリミティブ

Private Information Retrieval（PIR）

  • Live Caller ID Lookup は Private Information Retrieval（PIR）に依存
  • クライアントがサーバーにキーワードを送り、関連する値を取得
  • サーバーがキーワードを知らないように実装
  • 準同型暗号を使って大規模データベースを効率的に処理

準同型暗号

  • 準同型暗号では、復号なしで暗号化データに対して演算が可能
  • 一般的なワークフロー:
    • クライアントが機密データを暗号化してサーバーに送信
    • サーバーが暗号文に対して演算を実行
    • サーバーが結果の暗号文をクライアントに送信
    • クライアントが結果を復号
  • Brakerski-Fan-Vercauteren（BFV）HEスキームを実装
  • BFV は量子耐性を持つ RLWE 問題に基づく

準同型暗号の使用例

  • さまざまなプライバシー保護アプリケーションに有用
  • サンプルコード: 
    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)

GN⁺の要約

  • 準同型暗号は、データプライバシーを保護しつつクラウドサービスの新たな可能性を開く
  • AppleのiOS 18機能に適用され、実用性を実証
  • Swiftコミュニティで多様なプライバシー保護アプリケーションを開発可能
  • 類似機能を提供する他のプロジェクトには Microsoft SEAL、IBM HELib などがある

関連記事

1件のコメント

 
GN⁺ 2024-08-01
Hacker Newsの意見
  • 電話番号検索は、同型暗号が実際には機能しないことを示す教科書的な例だ
  • 同型暗号は、シミュレーションをアクセス不可能な並行宇宙へ移すような面白さがある
  • FHEに関心がある人は、最近実用的なFHEを実現した Zama.ai を確認すべきだ
  • これは HE の最初の実際のユースケースになるだろう。一般には遅すぎて有用ではないと見なされてきたが、これは素晴らしいユースケースだ
  • これは長期的には非常に重要な発表で、すぐにはそう感じられないだろう
    • これは AI と PII に関するユースケースにとって大きな発表だ
  • Zama.ai の FHE と比べてどうなのか気になる
  • FHE はすごいが、実際にどれだけ多くのユースケースに適しているのか気になる。ユーザーにより良いセキュリティ保証を提供するが、組織がクラウド上で安全な実行環境を約束するとして、ユーザーは本当に気にするだろうか？
    • さらにエンジニアリングの観点では、FHE を使うにはフローをリファクタリングし、すべてのダウンストリーム処理を固定的に約束する必要がある。法律で義務付けられない限り、組織に十分な動機があるだろうか？
  • 名前が笑える。というのも、HME はいくつもの意味でまったく高速ではないからだ
    • 本当の解決策はセキュアエンクレーブだと思うが、それにも難しさがある
  • FHE についていつも知りたいことがある。現代暗号のゴールドスタンダードは IND-CCA 安全性だ。FHE は定義上その基準を満たせない（暗号文を変更して平文に予測可能な影響を与えること自体が選択暗号文攻撃の定義だからだ）。では、現代の FHE スキームはどれほど近いのだろうか？ つまり、FHE の利点を得るために、どれだけの安全性を犠牲にしているのか？
  • サーバーが鍵を知らないまま暗号文を値と照合できる仕組みが理解できない。サーバーはどうやってその暗号文が特定の値に対応すると判断するのだろうか？ サーバーがこの暗号文-値データベースを構築する場合、値を暗号文にして保存するためにどのアルゴリズムを使えばよいのかをどうやって知るのだろうか？