DEF CON 34 Demo Labs 参加レポート：強要下の開示制御ツール「Phasmid（Janus Eidolon System）」を展示してきました
こんにちは。ディフェンシブセキュリティ部 SOCイノベーション課の杉田です。
Black Hat USA 2026 Arsenalでの登壇に続いて、同じ渡航中にもう1件、発表をしてきました。DEF CON 34のDemo Labsにて、個人の研究プロジェクトである「Phasmid（Janus Eidolon System）」を展示・デモしてきましたので、その報告です。
登壇は2枠ありました。8月7日（金）16:00〜16:45と、8月8日（土）12:00〜12:45。場所はLVCC Level 1、Exhibit Hall West 3の1001、Demo Labs Track 1です。
公式の演題は “Phasmid: Deniable Storage for Rubber-Hose Scenarios”。ここでいうrubber-hoseは、暗号を破るのではなく、鍵を知っている人間に物理的な圧力をかけて吐かせる、いわゆるrubber-hose cryptanalysisを指しています。
本記事では、DEF CONとDemo Labsがどういう場なのか、Phasmidというツールが何をするものか、そして現地での様子について紹介します。
DEF CONとは
DEF CONは1993年に始まった、世界最大級のハッカーカンファレンスです。毎年8月にラスベガスで開催され、2026年のDEF CON 34は8月6日から9日まで、Las Vegas Convention CenterのWest Hallで行われました。Black Hat USAが同じ週の前半に開催されるため、この時期のラスベガスは「Hacker Summer Camp」と呼ばれ、両方のカンファレンスに参加する方も多くいます。私も今回はBlack Hatの後、続けてDEF CONに参加する形になりました。
Black Hatが実務者・企業寄りの色合いを持つのに対し、DEF CONはより草の根的で、コミュニティ主導の雰囲気があります。バッジ文化やCTF、Villageと呼ばれるテーマ別の展示エリアなど、独特の文化を持つカンファレンスです。
Demo Labsとは
DEF CONには、一般講演のほかにDemo Labsという枠があります。オープンソースのツールやハードウェアを持ち寄り、コミュニティに直接見せる場です。
Black Hat Arsenalとよく似た形式ですが、違いもあります。ひとつは、対象が明確にオープンソースであることです。Demo Labsへの応募には「ツールやハードウェアがオープンソースであること」が条件になっています。もうひとつは、見せ方そのものです。
公式サイトに書かれている提供物は、プロジェクター1台、スクリーン1台、マイク付きの演台、有線または無線のネットワークです。ノートPCなど、それ以外の機材は発表者側で用意します。
ただ、実際の会場はプロジェクターではなく大型ディスプレイでした。黒い幕で区切られた一角に、演台と机、その横にディスプレイが1台。前には椅子が並んでいます。
そして、行ってみて驚いたのがヘッドホンです。座席のひとつひとつにワイヤレスヘッドホンが置かれていて、電源が入ると青く光ります。聴衆は着席してそれを装着し、音声を聞きます。展示ホールの中を幕で仕切っただけのスペースなので、周囲の音は当然入ってきます。それをヘッドホンで解決しているわけです。
Demo Labsの会場。座席ごとに置かれたヘッドホンが青く光る。正面はプロジェクターではなく大型ディスプレイ
Black Hat Arsenalとの違いは、ここがいちばん大きいと思います。Arsenalはテーブルの前で人が立ち止まり、入れ替わりながら話を聞く形でした。Demo Labsは45分間、着席した聴衆に向かって話す、講演に近い形式です。ツールを持ち寄る場という点は同じでも、話し方の設計はかなり変わります。
持ち時間は1枠45分です。私には金曜と土曜の2枠が割り当てられ、同じ内容を2回まわす形になりました。
なぜPhasmidを作ったのか
正直に書きます。
Phasmidの構想自体は、実は前からありました。ただ、実装には手を付けていませんでした。頭の中に設計だけがある状態が、しばらく続いていたということです。
実装に踏み切ったきっかけは、Azazel-EdgeでBlack Hat USA 2026 Arsenalへの登壇が決まったことでした。せっかくラスベガスまで行くなら、これまで一度も参加したことのなかったDEF CONにも足を伸ばしてみたい。そう思ったことが、実装の後押しになりました。
温めていたPhasmidの構想を、この機会に一気に形にすることにしました。Demo Labsに応募するには、動くものが必要です。実装からCFPの提出まで、AIをフル活用して、およそ1週間で仕上げました。
そして、CFPを出したら、通りました。
構想はあったけれど、作っていなかった。DEF CONに行きたいという、半分は個人的な動機で実装して出してみたら、採用された。今回、いちばん書いておきたいのはここです。
もちろん、急いで作ったからといって、中身が雑でよいわけではありません。以下に書く二槽の開示モデルも、想定している脅威も、以前から考えていたことをそのまま実装したものです。「作る決心がついたきっかけ」と「何を作ったか」は、別の話だと思っています。
その「何を作ったか」の部分、つまりPhasmidがそもそもどういう問題意識から生まれた構想なのかを、ここで説明しておきます。
暗号化ツールの多くは、ある前提の上に成り立っています。利用者は、開示を求められたときに安全に拒否できる、という前提です。パスワードを聞かれても「答えません」と言えばそれで済む、という状況です。
しかし、現場ではこの前提が崩れることがあります。国境で端末を調べられる、身柄を拘束された状態で開示を迫られる、押収された端末を後から解析される。こうした状況では、「拒否する」という選択肢自体が現実的でなくなります。暗号強度をいくら上げても、攻撃者が暗号そのものではなく、鍵を知っている人間に矛先を向けてくる限り、その強度は防御として機能しません。
Phasmidは、この「拒否できない状況」を設計の前提として正面から扱うために考えた構想です。強要、検査、そして望まない過剰な開示を、例外処理ではなく、設計の一級市民として最初から組み込んでいます。フォレンジック解析そのものを打ち負かそうとするのではなく、限定された条件のもとで、制御された開示の振る舞いを検証する、という立ち位置を取っています。
ついでに書いておくと、DEF CON 34全体のテーマは「Agency」でした。自己決定の力、と言い換えてもよいと思います。物理的な圧力が通常の暗号の前提を壊すとき、利用者は開示に対する実質的なコントロールを保てるのか。Demo Labsに出したアブストラクトも、この問いの形で書きました。テーマとの相性は、応募してから気づいた偶然です。
Phasmidとはどんなツールなのか
一言でいうと
Phasmidの基本発想。拒否ではなく、制御された開示で、最も守りたいものへの到達を防ぐ
デバイスの押収や、開示の強要を受けうる状況を想定した、ローカル完結型の制御開示ストレージです。「Janus Eidolon System」と呼ぶ二槽型のアーキテクチャのリファレンス実装にあたります。
名前の由来も書いておきます。Phasmidは、ナナフシ目（Phasmatodea）に属する昆虫を指す語です。枝や葉に擬態することで知られ、その名はギリシャ語のphasma（幻、幻影）に由来します。目の前にあるものが、見えているとおりのものではない。このツールに持たせたい振る舞いと重なるので、この名前にしました。アーキテクチャ名に入っているEidolonも、同じくギリシャ語で幻影を指す言葉です。
Janus（ヤヌス）はご存じのとおり、前後に顔を持つローマ神話の神です。ひとつの入れ物が、見せてよい顔と、守るべき顔の両方を持つ。この二面性が設計の核になっています。
二槽の開示モデル
二槽の開示モデル。ひとつのVesselが複数の開示面を持ち、守るべきものは見せた面の背後に留まる
Phasmidが作る暗号化コンテナを「Vessel（器）」と呼びます。ひとつのVesselの中に、複数の「Disclosure Face（開示面）」を持たせることができます。
運用者は、あらかじめ自分自身の手で、開示用の素材をひとつの面に格納しておきます。ここは強調しておきたい点ですが、Phasmidが開示用の素材を勝手に作り出すことはありません。何を見せるかは、常に運用者自身が用意します。
強要を受けたときには、その開示面を見せます。本当に保護したい情報は、別の保護された局所状態として、見せた面の背後に留まります。見せたものが「本物ではあるが、全部ではない」状態を作ることで、開示そのものは行いながら、最も守りたいものへの到達を防ぐ、という考え方です。
もうひとつの要素が「Object cue（オブジェクトキュー）」です。これは操作上のアクセスゲートであり、暗号鍵そのものではありません。Raspberry Pi版では、カメラで特定の物体を認識させることをアクセスの引き金にできます。パスワードのような「知っていること」ではなく、「持っている、あるいはその場にあるもの」を操作の起点にする発想です。
さらに「Restricted slot（制限区画）」という概念もあります。ここへのアクセスは、ローカル状態の不可逆な破棄を引き起こします。
技術的な仕組み
暗号化コンテナ（vault.bin）は、Argon2idで鍵を導出し、AES-GCMで認証付き暗号化を行います。加えて、ローカルの鍵材料を復元プロセスに混ぜ込むことで、vault.bin単体が漏れても復元には不十分になるようにしています。
操作面は、ローカルCLI、TUI（テキストベースの操作コンソール）、そして任意でローカルWebUIをサポートしています。WebUIは既定で127.0.0.1にのみバインドされ、他の端末からアクセスするには明示的なオプトインが必要です。制限された操作には、明示的な確認を挟むようにしています。加えて、メタデータに起因するリスクを見直し、削減するためのワークフローも、ベストエフォートですが用意しています。
開発環境はLinux・macOS、実機展開はRaspberry Pi OS（Trixie/Bookwormの64bit）を想定しており、フィールド展開の想定機材はRaspberry Pi Zero 2 Wです。オブジェクトキューによる認識を使う場合はPicamera2・libcameraが必要になります。LUKS2によるストレージ層はオプションです。
実機と操作画面は、こんな構成です。
誰のためのツールで、何のためではないか
ここは、はっきり書いておく必要があります。
Phasmidは、アンチフォレンジックツールではありません。 目指しているのは、強要された開示と本当の開示を切り分けることと、強要下で「守ろうとして結果的にすべてを失う」という安全でない振る舞いを減らすことです。何を主張し、何を主張しないのかを、対で整理しておきます。
| 主張すること（claims） | 主張しないこと（non-claims） |
|---|---|
| 強要された開示と、本当の開示を切り分ける | フォレンジックツールの回避 |
| 強要下で「守ろうとして結果的にすべてを失う」振る舞いを減らす | タイムスタンプの偽造、カーネルログの捏造、プロセスの隠蔽 |
| 限定された条件のもとで、制御された開示の振る舞いを検証する | フォレンジック的な不可視性、フラッシュメディア上での確実な削除 |
| ローカル完結型の開示制御を実験するための研究用プロトタイプ | 無制限の解析に対する永続的な秘匿性 |
| 設計上の前提と限界を明示すること | ディスク全体の暗号化、ハードウェアによる鍵保護、監査済みの機密データ取扱システムの代替 |
想定している利用者は、セキュリティ研究者、現場のリスクを評価する立場の方、そしてローカル完結型の開示制御に関する実験を行う方です。カジュアルなファイル暗号化のためのツールとしては想定していません。
リポジトリでは、内部的な検討軸として2つのトラックを置いています。ひとつは「privacy-and-research」トラックで、プライバシー保護的な開示、強要下での安全性、claims/non-claimsの透明性を重視します。もうひとつは「field-operations」トラックで、制約されたデバイスでの即応性、運用上の堅牢性、検査圧力下での安全な開示の振る舞いを重視します。
デモで見せた流れ
Demo Labsでは、次のような流れで実演しました。
- Prepare（TUI）— 暗号化コンテナ（Vessel）を作成する
- Bind（WebUI）— ひとつの容器に2つの面を登録する。Slot Aには物体A、Slot Bには物体Bと破壊パスワードを割り当てる
- Operate（WebUI）— 物体Aと復号パスワードで復元に成功し、ファイルが返ってくることを見せる
- Operate（同じタブ）— 同じファイル・同じパスワードのまま、物体だけを卓の下に隠す。拒否される。物体を戻せば、また開く
- Operate（同じ入力欄）— Slot Bに破壊パスワードを入力する。Slot Bは復号できなくなる。画面の表示は、打ち間違えたときと同じ
- Disclose（TUI）— Silent Standbyへ移行し、機微な情報を含むUI状態を消す
実演はすべて実機です。Raspberry Pi Zero 2 Wにカメラを付け、三脚に据えた構成で、TUIとWebUIを併用しました。画面を切り替えたのは、TUIからWebUIへ移るときと、WebUIからTUIへ戻るときの2回だけです。
この構成のいちばん大事な点は、3から5が同じタブ・同じ入力欄のまま続くことです。変えたのは物体とパスワードだけ。画面を切り替えていないからこそ、拒否が仕込みでないことが伝わります。
なお、監査ビュー（Audit）を見せる手順も用意していましたが、時間の都合で省きました。
現地の様子
会場の雰囲気 — コミケに似ていた
DEF CONへの参加は今回が初めてでした。Black Hatとの違いをいろいろ想像していましたが、実際に会場に立ってみて浮かんだ感想は、個人的には「コミケに似ている」でした。
Black Hatが世界的なカンファレンスだとすると、DEF CONは世界的なお祭りだと思います。コミケと同じように、同じ趣味を持った仲間——この場合はハッカー——が集まって、自分たちの手で作り上げている感じがしました。老若男女の参加者、スタッフ、ボランティアが、みんなで作り上げてきたイベントなのだと感じます。
企業が主催して見せる場ではなく、コミュニティ自身が作り、コミュニティ自身が支えている場。Demo Labsという、参加者が自分の作ったものを持ち寄る形式そのものが、この空気とよく合っていたように思います。
スピーカーバッジ
DEF CONの文化として、バッジの話は外せません。参加者の種別ごとに別のバッジが配られ、それ自体が電子工作物であり、ハックの対象になります。
登壇者に配られるのはSPEAKERバッジです。水色の板に金色の配線パターンが走り、中央に小さなディスプレイと3つのボタン、周囲には青く光るLEDが並んでいます。ディスプレイにはDEF CONのスカルロゴが出ていました。上部には「THE DARK TANGENT PRESENTS DEFCON 34」、下部に「SPEAKER」の刻印。基板の端には「bunnie」のシルクが入っていて、左右には拡張用のピンヘッダが出ています。
首から下げるものが、そのまま観察と改造の対象になっている。この一点に、DEF CONがどういう場なのかが凝縮されているように思います。
印象に残ったやりとり
デモの終盤では、Slot Bに復号パスワードと破壊パスワードの両方を設定し、破壊パスワードを入力してSlot Bのデータが復号できなくなることを実演しました。このとき画面に出るのは、パスワードを打ち間違えたときと同じ表示です。破壊は起きていますが、「開示に成功した」ようには見せません。
それを見たうえで、こんな質問を受けました。
「Slot Aを復号するように見せかけて破壊パスワードを入力し、Slot Aのダミーデータを復号しながら、裏で真のデータを削除する。そういう方法は採用しないのですか」
強要下での鍵入力を想定した、いわゆるデュレスコード的な発想です。ただ、これはデモで見せた挙動とは別の設計です。Phasmidの破壊は、破壊として振る舞います。質問されたのは、開示の成功を演じながら、その裏で削除を走らせる仕組みでした。
私はこう答えました。「意図的にデータを隠して削除する挙動は、法律的に問題が生じる可能性があるため、実装していません」。相手はこの説明で納得してくれました。
そのうえで、こう付け加えました。「ただ、実装自体はとても簡単です」。相手はにやりと笑っていました。
この質問は、Phasmidの設計思想をよく突いていたと思います。「技術的に可能かどうか」と「実装すべきかどうか」は別の話です。Phasmidに無いのは、破壊の機能ではありません。破壊はあります。無いのは、それを成功したように見せる偽装の層です。
おわりに
45分の発表で、いちばん手応えがあったのは、机の下に紙を1枚隠す動作でした。
パスワードは同じ、画面も同じタブ。カメラの前から1ドル札を引っ込めるだけで、さっき開いたファイルが開かなくなる。オブジェクトキューは鍵ではない、という説明を10分続けるより、この2秒のほうが速かったと思います。
ちなみに小道具が1ドル札なのは、ラスベガスでこれを持っていない人は、たぶんいないからです。
構想だけがあって、作っていなかった。DEF CONに行きたいという半分は個人的な動機で1週間で形にして出したら、通った。そして現地では、私の設計にまだ無い層について、その場で質問を受けました。作らなければ、あの質問には出会えませんでした。
動くものを1週間で作れる時代になりました。作りかけの構想を持っている方は、とりあえず出してみるといいと思います。完成させるためだけではなく、自分では思いつかなかった問いに出会うために。今回、私にとっていちばんの収穫は、まさにその問いでした。
今後の開発の軸も、現地でもらった質問から決まりました。もうひとつ、こんな質問を受けています。
「Phasmid Aで作ったVesselを、別の環境のPhasmid Bに持っていって復号できるのか」
現状の実装では、おそらくできます。Vesselは単体で完結した暗号化コンテナとして設計しているので、開くための材料が揃っていれば、どのPhasmidで開いても同じ結果になるはずです。
問題は、それが本当に望ましいのかどうかです。私はまだ答えを出せていません。
持ち運べることには利点があります。端末が壊れても別の環境で開ける、という復元性です。一方で、Vesselが単体で流通できるということは、そのVesselがどこで作られ、どの端末で、何回開かれたのかを問えないということでもあります。強要下の開示を扱うツールとして、この問えなさをどう考えるべきか。
取り得る方向は2つあります。可搬性を認めるなら、Vesselの管理そのものに仕組みが必要です。どこで生まれ、誰の手元を経由したのかを追える来歴の考え方が要るでしょう。逆に、PhasmidとVesselの関係をもっと強く結ぶなら、インスタンスや端末に対する何らかの縛りを持たせるべきです。
どちらを選ぶかは、実装の難易度の話ではありません。Phasmidが何を主張し、何を主張しないのか、その線をどこに引くかという設計の話です。あわせて、ローカルの鍵材料を復元プロセスに混ぜているという前半の説明と、可搬性がどこまで両立するのかも整理し直す必要があります。
そんなわけで、VesselとPhasmidの関係をどう定義するか。これを次のテーマとして、開発を続けていきます。
ツールはApache-2.0ライセンスで公開しています。Issue、Pull Request、そして「この設計はここが甘い」というご指摘をお待ちしています。
