分散型ストレージネットワークでは、すでに他人のマシンにデータの断片を預けることが一般的になっています。こうしたネットワークで長らく問われてきたのは、データを保持するマシンがその内容を読めるかどうかという問題です。IENYC の教授である Gregory Magarshak 氏が執筆した研究論文では、「Safecloud」と呼ばれるシステムが紹介されています。このシステムはひとつの設計原則に基づいています。データを保存するノードが見るのは暗号文のみであり、データをルーティングするノードは鍵を一切保持しない、というものです。
ファイルの分割と秘匿の仕組み
Safecloud は各ファイルを固定サイズのチャンクに分割し、デバイスから送り出す前にオーナーの端末上ですべてのチャンクを暗号化します。暗号化されたデータは、2 種類のノードに分散して保存されます。「Drop」は通常のブラウザタブ上で動作し、ウェブブラウザに内蔵されたストレージである IndexedDB に暗号化チャンクを保持します。「Jet」はルーティングサーバーとして、チャンクを Drop に対応付け、取得リクエストに応答します。「Cloud」と呼ばれるオーナーがルートシークレットを保持しており、コンテンツを復号する唯一の存在です。
システム内のすべての鍵は、標準的な鍵導出関数を通じて 32 バイトのルートシークレットから生成されます。同じルートのもとで同一のコンテンツを暗号化すると、常に同じ暗号文が得られるため、ネットワーク全体で重複するデータのコピーを 1 つに集約できます。この重複排除は単一オーナーのルートの範囲内で機能するため、異なるオーナーが同じファイルを暗号化した場合、生成されるアドレスは別々になります。各チャンクの格納先アドレスは暗号化済みのバイト列から算出されるため、ストレージノードは鍵がなくても、また内容を見ることなく、保持しているチャンクが正しいものかどうかを検証できます。
1 本のパスを共有する 3 つのツリー構造
Safecloud は共通のアドレッシングスキームを持つ3 つの構造を維持しています。チャンクの完全性を保証するパブリックなマークルツリー、機密性を担う鍵導出ツリー、そして認可を管理するアクセスツリーです。1 本のパスをたどるだけで、チャンクの完全性証明・復号鍵・アクセス権限のすべてを同時に特定できます。チャンクを取得する利用者はパブリックなルートと照合して返却されたバイト列を検証できるため、差し替えや破損が生じたチャンクは即座に検出されます。
鍵の構造から生まれるストリーミング機能
鍵の階層構造はメディアのストリーミングにも活用されています。トラックの鍵を持つプレイヤーは、すでに保持している鍵から 1 ステップで次のセグメントの鍵を導出できるため、動画の任意の再生位置にシークする際のコストは 1 回の鍵導出と 1 回のフェッチだけで済みます。ファイルの映像・音声・字幕の各トラックは別々のブランチに格納されており、それぞれ独立して解錠することができます。また、オーナーは特定の範囲の鍵を 1 つ渡すだけで、プレビューやレンタルチャプターなど、指定したセグメント範囲へのアクセス権を付与できます。
Magarshak 氏は、ランダムアクセス可能な復号ストリーミングとセグメント単位のアクセス制御を組み合わせたこのアプローチは、暗号化ストレージネットワークの中で新しいものだと述べています。ただし、設計上の制約が 1 つあります。範囲鍵が一度付与先に渡ると、その範囲の鍵をローテーションしなければアクセスを取り消せない点です。付与先は一度導出した鍵を保持し続けるためです。
経済的なインセンティブ層
Drop はチャンクの保持・提供の対価として「Safebux」と呼ばれるトークンを獲得し、Jet はルーティングの対価としてこれを獲得します。支払いは署名済みのクレームによって決済されます。このクレームは、番号付きのラインで段階的に上昇する上限額を許可するもので、プロバイダーは受け取るべき金額を証明でき、支払い側は古い認可を再利用することができません。ストレージの誠実性は、Jet が Drop に対して新しいコンテンツアドレスとナンスへの署名を要求するチャレンジによって担保されています。チャンクを保持していない Drop はこのチャレンジに失敗し、繰り返し失敗するとステークがスラッシュされ、チャンクが再複製されます。
Magarshak 氏は、この設計が Filecoin のシーリング方式よりもコストが低いと主張しています。Filecoin ではプロバイダーが低速なエンコード処理（セクターあたり数十分オーダー）を通じてストレージを証明し、機密性とは別に物理的な複製を証明する必要があります。同氏は、自身のチャレンジ方式は Filecoin のシーリングと同等の性質を証明するものではないとしながらも、署名＋ステーク方式は誠実なプロバイダーを低コストで維持するのに十分だと述べています。
動作中の機能と開発中の機能
Magarshak 氏は、すでに動作している部分と開発中の部分を明確に区別しています。暗号化、チャンキング、コンテンツアドレッシング、マークルによる完全性ツリー、委譲の構成はいずれも動作しています。決済と保存証明のレイヤーは仕様が定まり、部分的に実装されています。ただし論文では、現時点で決済検証フックは常に true を返す状態であり、保存証明のチャレンジ応答はプレースホルダーである旨が明記されています。
Magarshak 氏はこのレイヤーの現状についてさらに詳しく説明しています。Safecloud では「決済コントラクトは公開検証可能」であり、「すべての支払いは、公開済みのOpenClaiming Protocol を用いてオンチェーンで強制される、型付き構造体に対する有効な暗号署名を必要とする」と述べています。保存証明のチャレンジは、暗号文の SHA-256 であるコミット済みコンテンツアドレスを使用するため、チャンクを実際に保持していないストレージノードが偽造することはできません。現時点で未解決の部分はリレーパスであり、ルーティングサーバーがストレージノードのガス代を肩代わりし、セッション鍵の署名を組み込む必要があると指摘しています。「ノードが自身のクレームを直接送信するダイレクトパスはすでに動作している」と同氏は述べています。
脅威モデル
論文では、攻撃者の能力を広く想定しています。攻撃者は任意の数の Drop を運用でき、Jet を運用することもでき、すべてのネットワークトラフィックを傍受でき、ノード間で共謀することも可能です。一方で、暗号化や署名スキームを破ることはできず、鍵と平文を保持するオーナーのデバイスを制御することもできません。この前提のもと、ストレージノードは暗号文から何も学べず、改ざんされたバイト列は検出され、保持していないストレージを主張するノードはチャレンジで失敗します。残る脆弱性は、多数の Drop がデータを保留・破棄した場合の可用性の問題であり、これは複製型ストレージ全般に共通する制約です。
Safebox との連携
Safecloud は「Safebox」と呼ばれる別システムと組み合わせて使用できます。Magarshak 氏は両者が独立したものであることを強調しています。「Safecloud は Safebox から完全に独立しています。暗号化、ストレージ、ルーティング、決済の各レイヤーは、Safebox なしで監査・実行できます」と Help Net Security に語りました。クライアントサイドのコードはブラウザの開発者ツールで誰でも確認でき、コントラクトのソースコードはプロジェクトページからリンクされているブロックエクスプローラーで検証済みです。
同氏によると、Safebox は iOS 上の Groups アプリを 10 年間運用した経験から生まれた任意の証明レイヤーです。Groups アプリでは Safari Web Extension を利用してプライベート鍵をローカルに保持していました。Safebox はその考え方をオープンウェブに展開するもので、ウェブサイトや iframe が改ざんされていない信頼できるフロントエンドで動作していることを証明します。同氏はこれを、サーバー上で実行されるコードに適用された HTTPS の鍵マークに例えています。
翻訳元: https://www.helpnetsecurity.com/2026/06/19/safecloud-browser-based-encrypted-storage/
