セキュリティ

このアプリは、実在する Mac 上の実サービスを、ときには地球の裏側から起動・停止できます。それが理にかなうのは、盗まれた端末・盗聴されたネットワーク・推測されたトークンのどれもが、そのままではサーバの制御に変わらない場合だけです。FrontierStack は、それらのどれも単独では不十分になるよう作られています。本章ではその層を解説し、なぜ Cloudflare トンネル越しにどこからでも安全に Mac へ到達できるのかを説明します。

3.1すべてのリクエストに署名する

最も強力な保護は目に見えません。この端末はペアリング時に自分専用の秘密鍵を生成し、iOS の Keychain に保存しました — 鍵は端末から出ることはなく、このアプリでさえ平文として読み出せません。アプリが Mac に送るすべてのリクエストは、その鍵で署名されます。Mac は承認した端末を公開鍵ごとに許可リストとして保持し、リクエストのたびに、送信元を名乗る端末に対して署名を検証します。

これが FS1 端末ごとのモデルです。Ed25519 署名を用い、署名付きリクエストにはタイムスタンプと一回限りのナンスも含まれるため、捕捉されたリクエストは数秒後でも再送できません。実用上の肝心な点はこうです — 旧来のアプリが頼るような共有秘密、すなわちベアラートークン単体では、ここでは何も制御できません。この端末の秘密鍵がなければ、コピーされたトークンは無力です。

3.2暗号化・ピン留めされた接続

署名は誰が話しているかを証明し、暗号化は何を話すかを守ります。Mac が HTTPS アドレスを広告すると、このアプリは通常の安全な接続と同じく TLS で通信します。ただし一ひねりあります — Mac は自ら生成した自己署名証明書を使うため、その正当性を保証する公的な認証局が存在しません。

代わりに、アプリは証明書のピン留めを使います。ペアリング用の QR コードには、Mac の証明書の正確なフィンガープリントが含まれていました。それ以降、アプリはそのフィンガープリントと完全に一致する証明書を提示する接続だけを受け入れます。中間に割り込んで自前の証明書を差し出す攻撃者は、たとえ「有効な」証明書であっても、ペアリング時にピン留めしたものと一致しないため拒否されます。

3.3どこからでも安全な理由

この 2 つを合わせれば、公開経路 — たとえば Cloudflare トンネル — 越しに Mac へ到達することが、無謀ではなく安全である理由が見えてきます。トンネルは通信を運ぶだけで、偽造はできません。

• 接続は暗号化されピン留めされているため、トンネル（および経路上の誰か）が見るのは、なりすませない証明書宛ての暗号文だけです。
• すべてのリクエストはこの端末の鍵で署名されているため、Mac に届いた何かがあっても、Mac が受け入れるコマンドは発行できません。
• 再送はリクエストごとのタイムスタンプとナンスで防がれるため、捕捉したリクエストの再送は失敗します。

公開経路を存在させるかどうかは Mac が決め、いつでも閉じられます。ここでは何一つネットワークが私的であることに依存していません — 保護は各リクエストとともに運ばれます。

3.4アプリロック

誰かがロックされていないあなたの端末を手に取るだけなら、ネットワークのセキュリティは役に立ちません。アプリロックがその隙を塞ぎます。設定でパスコードを有効にすると、以降アプリは入力するまでロックされ、ワンタップ解除のために Face ID または Touch ID を追加できます。アプリは離れるたびに再ロックします — 別のアプリに切り替えたり端末をロックしたりすれば、戻ったときに再び尋ねられます。

パスコード自体は保存されません。アプリは端末の Keychain にソルト付きハッシュだけを保持するため、端末を手にしても読み出せるパスコードはありません — 入力がハッシュ化されて保存値と一致するか、しないか、それだけです。生体認証は iOS が処理し、アプリには可否だけを伝えます。

Mac のロックのミラーリング。Mac 自体にアプリロックのパスワードが設定されている場合、このアプリはペアリング時にそれを取り込み、施錠して同じパスワードを要求します。パスワードが送られることはなく、ソルト付きハッシュだけがピン留めされたペアリング接続で渡され、端末側で入力をローカルに照合します（両者は同一方式です）。ミラーリング中は端末側でロックの変更や解除はできず、Mac に従います。

3.5この端末に許可された操作

認証が「これは本当に私の端末か？」に答えるのに対し、権限スコープは「ではどこまでできるか？」に答えます。その判断はここではなく Mac にあります。ペアリング済みの各端末には 4 つのレベル — 読み取り専用・再起動・操作・フルコントロール — のいずれかが割り当てられ、Mac が署名付きリクエストごとにそれを適用します。常に持ち歩く端末は、完全にペアリングされていても低いレベルに安全に留められます。

ボタンが無効だったり操作が拒否されたりするのは、この端末のレベルがそれを許していないからです — Mac で引き上げるか、すでに権限のある端末を使ってください。4 つのレベルとそれぞれが解除する範囲は ペアリング にまとめてあります。

レベルと並んで 2 つの許可があり、どちらも Mac 側で設定します。AI 管理者を許可（既定はオン）は、この電話が AI タブをそもそも使えるかを決めます — 一方の端末にはチャットを許可しつつ別の端末をブロックできます。リモートシェルを許可はフルコントロールのときのみ表示され、既定はオフです。これはこの端末が Shell タブを開き、サーバへ直接到達するために必要です。どちらもバイパスではありません：AI を許可していても、変更にはフルコントロールの「Allow changes」とアプリのロック解除が依然として必要です。

3.6端末を失くしたとき

各端末が自分の鍵を持つため、1 台を切り離すのに他は一切変更する必要がありません。Mac でセキュリティ ▸ ペアリング済みモバイル端末を開き、名前で端末を探して失効させます。その鍵は直ちに許可リストから削除されます — 次にその端末が Mac へ通信を試みた瞬間、署名は拒否されます。他の端末はそのまま動き続けます。

Mac 上での失効が決定的な手順です — 端末そのものに手が届かなくても、その端末を止められます。アプリ内の「この端末のペアリング解除」は、まだ手元にある端末で接続を忘れるだけです。失くした端末は、Mac で失効させてください。

本当に手元を離れた電話には、Mac がより強力なワンクリック操作 紛失した電話を保護を用意しています。鍵の失効に加えて、その端末の古いキュー操作を直ちに取り消し、開いているセッションを閉じ、直接アクセス用にサーバへ導入した SSH 鍵を削除し、プッシュ通知を無効化します。その時点でオフラインのサーバは一覧に残るので、復帰後に鍵の削除を完了できます。