Scribble at 2026-05-12 19:06:15 Last modified: 2026-05-12 19:15:30
Encryption is the most direct technique to protect data confidentiality when users outsource their data to the cloud. Typically, ciphertexts are stored in the cloud, while cryptographic keys are managed by a key management server (KMS). However, this approach introduces new challenges in securely managing both keys and ciphertexts. Specifically, two crucial issues remain unresolved. One is that the simultaneous leakage of data encryption key and ciphertexts stored in cloud can directly compromise user data. Another is that if the cloud and KMS collude, they can trivially retrieve user data. In this work, we propose a Password-protected Encrypted Cloud Storage scheme PECS that is resilient to the aforementioned leakage and collusion attacks. In PECS, the users can encrypt/decrypt their data using only a password without storing any key material, and neither the cloud nor KMS learns any information about the user data or keys. Technically, we introduce a re-encryption mechanism performed by the cloud to prevent an adversary from obtaining the original ciphertexts. Furthermore, the user encrypts key wrap before sending it to the cloud, under a pair of password-derived secret and public key. Both the data encryption keys and password are protected from being exposed by the servers through an oblivious pseudorandom function (OPRF). Provable security and efficiency of PECS are demonstrated through comprehensive analyses.
この論文は、パスワードだけでクラウド上の暗号化データを安全に管理するための新しいスキームである "PECS" (password-protected encrypted cloud storage) を提案する。現在のセキュリティ研究者や実務家が採用しているクラウド・ストレージへのデータ移送方法では、ユーザがデータを暗号化してクラウド・サービス事業者に預け、その暗号鍵をキー管理サーバが管理するという構成がとられている。もちろん、これはセキュリティ技術者や学者にとっての「一般的な」やりかたなのであって、大半の人にしてみれば、「わたしはそんなことしてない」と思うかもしれない。だが、もう少し話を広く考えてみると、HTTPS でクラウド側にデータをアップロードしていれば、公開暗号鍵を使っていることになるので、自分自身の作業手順としてデータを何かのソフトウェアで暗号化している自覚がないとしても、実質的にブラウザやクラウド・ストレージのデスクトップ・クライアントを使っていれば自分のデータを（少なくとも end-to-end では）暗号化していることになる。
しかし何にしても、この従来の方式には、暗号鍵と暗号文が同時に漏洩した場合にデータが解読されてしまうというリスクや（HTTPS で通信している場合の中間者攻撃などを想定すればよい）、クラウド事業者とキー管理のサーバを運営する事業者（SSL サーバ証明書の認証機関など）が結託した場合に、ユーザのデータが筒抜けになってしまうというリスクがある。
PECS は、これらの問題を解決するために設計されたという。技術的な特徴として、まずクラウド側でデータの再暗号化を行うメカニズムを導入しており、これにより攻撃者がオリジナルの暗号文をそのまま入手することを防ぐ。また、忘却型擬似乱数関数 (oblivious pseudorandom function) を活用することで、サーバ側にパスワードや暗号鍵を明かすことなく、ユーザの記憶しているパスワードのみから安全に秘密鍵を導出できるようにしている。
具体的なワークフローとしては、ユーザがデータをアップロードする際、データ識別子ごとに独自の鍵を生成して暗号化し、その鍵自体もパスワード由来の公開鍵で保護してクラウドに送る。クラウド側では、受け取った暗号文をさらに自身の再暗号化鍵で処理して保管する。データをダウンロードする際は、ユーザが正しいパスワードを入力することで、クラウドと協力しながら秘密鍵を復元し、再暗号化されたデータを元の暗号文へ戻し、最終的にデータを復号する。この多段階の構成により、たとえクラウド上のデータと鍵の両方が漏洩しても、あるいはクラウドと認証鍵の二者が結託しても、ユーザのパスワードがなければデータの中身を知ることはできないようになる。また、ユーザ側で複雑な鍵を物理的に管理・保存する必要がなく、どのデバイスからでもパスワード１個で安全に自分のデータにアクセスできるという、実用上の高い利便性も備えるという。計算コストや通信回数の面でも最適化されており、現代のクラウド環境において十分に実用可能なパフォーマンスが示されている。
・・・という話なのだけど、ぶっちゃけ言って Cryptometor のようなユーザ（クライアント）側でファイルを暗号化してしまう仕組みを使えば、こんな仕組みは不要だと思う。もちろん、Cryptometor は施錠・開錠にユーザ自身が強力なパスフレーズを設定すればいいわけであって、僕は実際に会社ではなくプライベートで契約している Google One の Google Drive 領域に Cryptometor で暗号化したファイルをアップロードしているので、たとえ Google のエンジニアが暗号化されたファイルを奪おうと復号はできないし、Cryptometor のエンジニアが Google のエンジニアと結託して開錠用のパスフレーズを共有する（パスフレーズを設定したり入力するときに黙って Google へ送信するとか）可能性は低いと思う。そもそも、この手のソフトウェアは、VeryCrypt などもそうであるように、セキュリティ目的のソフトウェアをセキュリティの研究者やエンジニアが監査しているからだ。隠れてデータを送信する機能なんてものが実装されていれば簡単にバレる。