検証に基づく安全性

まず結論：3つの「数学」で守られています

通信は解読できない暗号で守られる — 画面・音声・操作は端末どうしを直接結ぶ暗号で流れ、サーバにも中継業者にも中身は見えません。
サーバ＝公開コードと同一を証明できる — 「指紋・封印・公開台帳」という3つの数学の道具で、運営者でも後からこっそり書き換えられません。
しかもブラウザが自動で検証する — 相手の画面の「ℹ︎ → PAssist について」を開くだけ。ブラウザ自身が計算して ✓（一致） を表示します。インストールも専門知識も不要。

以下では、なぜ「数学的に安全」と言い切れるのかを、順を追ってやさしく説明します。

1通信は数学的に解読できない

サーバを信用するかどうかの前に、まず「そもそも中身が見えない」ことから整理します。

① 画面・音声・操作は "端末どうしの直接通信"

WebRTC により、あなたの PC と相手のブラウザは直接つながります。中央サーバは「最初の引き合わせ（シグナリング）」をするだけで、映像の本体はサーバを通りません。

② 通信はすべて暗号化（DTLS-SRTP）

映像・音声は AES-128-GCM、鍵交換は ECDHE (Curve25519)。鍵はあなたと相手の端末でだけ作られ、サーバには一度も渡りません。たとえるなら「二人だけが持つ鍵で施錠した箱」を郵送するイメージで、配達業者（サーバ）は中身を開けられません。

③ 中継（TURN）が入っても同じ

ネットワークの都合で TURN サーバが中継する場合も、流れるのは暗号化された塊（SRTP）だけ。鍵を持たないので中継業者にも解読できません。

経路	暗号化	鍵を知るのは？
メディア（画面/音声）	DTLS-SRTP / AES-128-GCM	あなたと相手だけ
DataChannel（操作入力）	SCTP over DTLS	同上
TURN 中継時	中継するのは暗号化済み SRTP	TURN サーバは鍵を持たない

使われている暗号は TLS 1.3 / NIST / IETF の標準。現在の数学の常識では、総当たりで破るのに宇宙の年齢を超える計算時間がかかります。実際の暗号方式は、接続中の「PAssist について」画面に表示されます。

つまりサーバが覗ける情報は、接続時刻や IP などのメタデータに限られ、映像の中身は数学的に守られています。

2暗号の「3つの道具」— やさしい解説

この先の「サーバが公開コードと同じ」を支えるのは、次の3つの数学の道具です。難しい言葉が出てきたら、ここに戻ってください。

🔍

① 指紋（ハッシュ／SHA-256）

データを一方向の計算で短い「指紋」に変えます。中身を1文字でも変えると指紋は全く別物に。同じ指紋なら中身も同じと数学的に言えます（偶然の一致は事実上起こりません）。

🖋️

② 封印（デジタル署名）

「本人にしか作れず、誰でも本物か確認できる」ハンコです。偽造には秘密鍵が必要。PAssist では署名のたびに使い捨ての鍵を使い、すぐ破棄するので「鍵が漏れて偽造」も起きません。

📖

③ 公開の台帳（透明性ログ／Rekor）

署名を、世界中から見える「追記しかできない公開ノート」に記録します。後からこっそり消す・書き換えると、数学（ハッシュの木）でバレる仕組みです。

3サーバ＝「公開コードと同じもの」の証明

WebRTC で守られるのは「中身（映像）」だけ。理屈の上では、サーバ自体がこっそり改造コードを動かしてメタデータを盗む余地が残ります。これを封じるのが Reproducible Build ＋ Cosign 署名です（道具①②③をフル活用）。

Reproducible Build（再現可能ビルド）

同じソースコードから誰がビルドしても、寸分たがわず同じ Docker イメージ（同じ指紋）になる仕組みです。タイムスタンプを git コミット時刻に固定（SOURCE_DATE_EPOCH）し、依存を package-lock.json 通りに厳格再現（npm ci）。道具①により「同じ指紋＝同じ中身」と確定できます。

Cosign keyless 署名＋ Sigstore Rekor

GitHub Actions がイメージをビルドした直後、GitHub の身分証明（OIDC）を使い、秘密鍵を持たずに署名します（道具②）。署名は公開の改ざん不能な台帳 Rekor に記録されます（道具③）。「この署名は github.com/paps-jp/passist の release ワークフローが作った」という事実が、世界中から検証可能な形で残ります。

運営者は秘密鍵を持たないので、鍵漏洩による偽造のリスクがありません。

4ブラウザがワンタッチで自動検証 ⭐

ここが PAssist の肝です。専門知識も追加インストールも不要。相手の操作画面（ビューア）の右上 「ℹ︎ → PAssist について」を開くと、ブラウザ自身がその場で数学の計算をして、いま接続しているサーバの正体を検証します。

✓

検証OK — このサーバは github.com/paps-jp/passist の公開コードから作られたものです（GitHub Actions が署名・Rekor に記録済み）。

ブラウザは内部で、サーバから受け取った署名と Sigstore の公開ログを取り寄せ、次を確かめています：

この署名は公開ログに実在する — Rekor のハッシュの木（Merkle 証明 / RFC 6962）を再計算して、台帳に確かに載っていることを確認（道具①③）。
署名の対象＝いま動いているサーバと一致 — 署名された中身の指紋と、稼働中イメージの dig（sha256:…）が一致することを確認（道具①）。
署名した主体＝正規のリポジトリ — 証明書に記録された発行元が github.com/paps-jp/passist で、発行者が GitHub の OIDC(token.actions.githubusercontent.com)であることを確認（道具②）。

💡 同じ自動検証は、ホストアプリ（PAssist.exe）の「PAssist について」でも実行できます。

正直な但し書き（透明性のために明記）

ブラウザ内検証は手軽さのため一部を簡略化しています（Rekor 自身の署名や証明書チェーンの完全な検証までは行いません）。日常利用には十分な確認ですが、「絶対の確証」が欲しいときは下記の cosign verify を使ってください。同じ署名を、省略なしでフル検証します。

5信頼の連鎖

ソースコードから、あなたの画面の ✓ まで、すべてが数学でつながっています。

Git コミット：ソース改ざんは指紋（SHA-256）で検知。GitHub が履歴を保管。
GitHub Actions が自動ビルド：人手を介さず、ビルドのログは誰でも閲覧可能。
イメージを GHCR に公開：イメージの指紋 sha256:… が確定。
Cosign keyless 署名：「paps-jp/passist の release が作った」を Rekor 公開ログに記録。
VPS で docker pull：指紋が一致しなければ取得時点でエラー。
あなたが検証：ブラウザの自動検証（ワンタッチ）／さらに cosign verify・自前再ビルドでも一致を確認可能。

6上級者向け：自分の手でも確認できる

ブラウザの ✓ だけで十分ですが、技術に詳しい方は同じことを手元のコマンドで「省略なし」に確かめられます。

A. 公開イメージの真正性（30秒・フル検証）

cosign verify ghcr.io/paps-jp/passist-signaling@<digest> \
  --certificate-identity-regexp 'https://github.com/paps-jp/passist' \
  --certificate-oidc-issuer 'https://token.actions.githubusercontent.com'

→ Sigstore Rekor の公開ログを参照し、「このイメージは確かに paps-jp/passist の release ワークフローから生まれた」を完全に検証します。

B. 自分でも同じ指紋を再現（数分）

git clone https://github.com/paps-jp/passist
cd passist && git checkout v0.2.0
docker buildx build server \
  --build-arg SOURCE_DATE_EPOCH=$(git log -1 --format=%ct) \
  --provenance=mode=max --sbom=true -t local-rebuild
docker inspect local-rebuild --format='{{.Id}}'
# → 公開 digest と一致するはず

C. 運用中サーバの自己申告（入口の確認）

curl https://passist.paps.jp/api/build

サーバが動かしている commit / イメージ digest / build 時刻を返します。これ自体は嘘がつけるので、必ず A の cosign verify と digest を突き合わせて判断します（ブラウザの自動検証も、この digest と署名の一致を確かめています）。

7ライセンス

PAssist は MIT License のもとで公開しています。OSI 認定の最もシンプルな許諾型 OSS ライセンスで、商用利用を含むほぼすべての利用が自由です。

✅ 自由にできること

使うこと — 個人・法人を問わず、商用・非商用を問わず、PAssist を動かして自分の業務、支援活動、サービス提供に用いること（有償サービスとして提供することも含む）。
自分または所属組織のサーバで PAssist を立て、社内・組織内・対外サービスとして運用すること。
改変すること、コードを読んで監査・検証すること、ビルド再現性を確かめること。
改変版や派生物を、商用・非商用を問わず頒布・公開すること。
派生物に独自のライセンスを付けて公開・販売すること（プロプライエタリ化も可）。

📌 唯一の条件

再配布する際は、ソースコードまたはバイナリの配布物に 著作権表示と MIT ライセンス全文 を含めてください。

これだけです。サービスとして社内・社外で運用する場合、配布行為が発生しないため、特に何もする必要はありません。

詳細は LICENSE ファイルまたは MIT License 公式ページ (OSI) を参照してください。