Remioのセキュリティアーキテクチャを、率直に。

§01 · エグゼクティブサマリー

Remioは、ゼロナレッジのピアツーピアアーキテクチャで構築されたリモートデスクトップアプリケーションです。画面の内容、入力データ、オーディオのストリームは、業界標準のDTLS-SRTPを使って、デバイス間でエンドツーエンドに暗号化されます。これは、WebRTCベースのすべての製品が依拠している、同じセキュリティモデルです。集中型のソリューションとは違い、Remioのシグナリングサーバーが担うのは、最初の接続の確立の手助けだけで、セッションのデータを見ることも、処理することも、保存することも決してありません。

必要なアカウントも、突破されるパスワードも、中央の認証情報データベースもありません。デバイスのペアリングには、ホスト自身の画面から読み取る6桁のコードを使い、すべてのセッション鍵は、完全前方秘匿性を備えた一時的なものです。たとえ鍵が侵害されても、過去と将来のセッションは、暗号学的に安全なままです。このアーキテクチャは、競合を悩ませてきた、攻撃のカテゴリーそのものをなくします。盗めるものが、そもそもないからです。

§02 · 脅威モデル

Remioのセキュリティアーキテクチャは、企業と個人の両方の場面で、リモートデスクトップの利用に関わる一連の脅威のシナリオに対して設計されています。何から守るのか、そして、信頼の境界がどこにあるのかを、明確にしています。

守っている脅威

• 盗聴。すべてのメディア（映像、音声）とデータチャネル（入力、キーボード、カーソル）は、それぞれSRTPとDTLSで暗号化されます。ネットワークの観測者に見えるのは、暗号化されたパケットだけで、セッションの内容を再構築することはできません。
• 中間者攻撃（MITM）。証明書のフィンガープリントを検証するDTLSハンドシェイクが、傍受を防ぎます。シグナリングのチャネルは、完全前方秘匿性を備えたTLS 1.3を使います。
• サーバーの侵害。当社のシグナリングサーバーが完全に侵害されても、攻撃者が得られるのは、接続のメタデータ（IPアドレス、タイムスタンプ）だけです。セッションの内容が、当社のサーバーを通ることも、保存されることも、決してありません。
• 不正アクセス。PINによるペアリングには、物理的な近さか、表示されたPINの知識が必要です。攻撃対象となる、リモートからアクセスできる認証情報のデータベースは存在しません。
• 認証情報の窃取。パスワードも、アカウントも、中央の認証情報ストアもありません。デバイスの信頼は、PINによるペアリングで確立され、セッショントークン（JWT）は有効期間が短く、デバイスに紐づけられています。
• セッションのリプレイ。SRTPに組み込まれたリプレイ保護と、DTLSのシーケンス番号が、キャプチャしたパケットの再送を防ぎます。
• サプライチェーン攻撃。Remioのすべてのバイナリにはコード署名があります。macOSのビルドは、Appleによる公証を受けています。iOSのビルドは、App Storeだけを通じて配布されます。

信頼の境界

私たちの脅威モデルは、3つの信頼の境界を明確に定義しています。

1. デバイスの境界。各デバイスは、PINの検証後にだけ信頼されます。OSレベルの保護（サンドボックス、Keychain、Secure Enclave）が、デバイス上のデータを守ります。
2. ネットワークの境界。通信中のすべてのデータは暗号化されます。ネットワークは、敵対的だと想定しています。
3. サーバーの境界。当社自身のサーバーも、信頼できない中継として扱います。接続の手助けはしますが、内容を検査できません。

§03 · アーキテクチャの概要

Remioは、シグナリングのプレーン（接続のセットアップ）と、データのプレーン（ストリーミング）を分離しています。この分離は、私たちのゼロナレッジ設計の根幹です。接続を手助けするサーバーが、やり取りされるデータに触れることはありません。

シグナリングとデータのプレーン

シグナリングサーバーの唯一の役割は、接続のセットアップ中に、デバイス間でSDPのoffer/answerとICE候補を中継することです。P2P接続が確立したあとは、シグナリングサーバーは関与しません。

サーバーは、中継する内容を解析できません。それは、対象のデバイスだけが解釈できる、暗号化されたバイナリの塊です。バイナリのプロトコルは、構造の層をさらに加え、JSONベースのシグナリングに比べて、インジェクション攻撃を難しくします。

§04 · 暗号化の層

Remioは、多層の暗号化戦略を採用しており、各通信チャネルが、その要件にいちばん適した暗号プロトコルを使います。

完全前方秘匿性

Remioのすべてのセッションは、ECDHEの鍵交換によって、固有の一時的な暗号鍵の組を生成します。

• 現在のセッション鍵が侵害されても、過去のセッションが露出することはありません。
• 現在のセッション鍵が侵害されても、将来のセッションが露出することはありません。
• 各鍵のペアは、1回のセッションの間だけ存在します。
• 鍵がディスクに保存されることはありません。メモリー上にだけ存在します。

暗号スイート

# Signaling — TLS 1.3 cipher suites (in order of preference)
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

# Media — SRTP protection profile (WebRTC industry default)
SRTP_AES128_CM_SHA1_80   # AES-128 counter mode, HMAC-SHA1-80 auth

# DTLS certificates
Self-signed ECDSA (P-256), verified out-of-band via SDP fingerprints

鍵のローテーション

鍵は、次のタイミングで自動的にローテーションされます。

• セッションの開始。新しいDTLSハンドシェイクが、すべての接続で新しい鍵を生成します。
• SRTP鍵の導出。メディア鍵は、DTLSハンドシェイクから導出され、メディアトラックごとに固有です。
• 再接続。セッションが中断して再接続した場合は、まったく新しい鍵交換が行われます。

§05 · 認証とペアリング

Remioは、従来のユーザー名とパスワードによる認証を、あえて避けています。かわりに、リモートデスクトップソフトウェアで最も一般的な攻撃経路をなくす、PINによるデバイスのペアリングモデルを使います。

PINによるペアリング

クライアントが、初めてホストに接続しようとするとき、手順は次のとおりです。

1. ホストが、短い数字のPINを、画面に（またはQRコードとして）表示します。
2. クライアントがPINを入力し、それがシグナリングのチャネルを通じて、ホストに送られます。
3. ホストがPINを検証し、ペアリングを承認または拒否します。
4. 成功すると、デバイス間の信頼関係が確立されます。
5. 同じデバイスからの、以降の接続では、再ペアリングは不要です。

デバイスの信頼モデル

ペアリングされると、各デバイスは、固有のデバイスIDで識別されます。ホストは、信頼するデバイスのローカルな一覧を保持します。この信頼関係は、次のとおりです。

• ホストのデバイスのみのローカルに保存され、OSのKeychainに入ります。
• 送信されることはありません。サーバーは、どのデバイスが信頼されているかを知りません。
• 取り消し可能です。ホストは、いつでも、信頼するデバイスを削除できます。

セッショントークン（JWT）

ペアリングの後は、有効期間の短い署名付きトークン（24時間で失効）が、シグナリングサーバーの認証に使われます。

これらのトークンは、ルームの作成とメッセージの中継のために、シグナリングサーバーに対してデバイスを認証します。セッションの内容へのアクセスは許可しません。それは、別のDTLSハンドシェイクで守られています。

AIエージェントのアクセス（Remio MCP Server）

Remioは、この同じ信頼モデルを、AIエージェントにも広げています。Claude Code、Codex、Claudeアプリのようなツールが、Remio MCP Serverを通じて、あなたのマシンをリモートで操作できます。そして、セキュリティの境界は、人間のクライアントが越えるものと同じです。

• すべては、あなたのサインインで制限されます。エージェントが届けるのは、オンラインで、あなたが認証したアカウント（OAuth経由のGoogleまたはAppleのサインイン）にペアリングされたホストだけです。認証されたアカウントがなければ、ツールはありません。
• Remioは、仲介者であって、操作者ではありません。MCPサーバーの唯一の仕事は、認証されたアカウントの範囲に限定したツールの一式を公開し、あなたが接続を選んだAIツールに渡すことです。Remioが、自分からあなたのマシンとのセッションを始めることはできません。ホストは、上のデバイスの信頼モデルとまったく同じように、アカウントの認可の証明を提示する接続だけを受け付けます。
• 同じ、暗号化されたトランスポート。エージェントのセッションは、§04で説明した、同じエンドツーエンドで暗号化されたチャネルを通ります。当社のサーバーに見えるのは、暗号化された塊だけで、§06のゼロナレッジの特性が、そのまま適用されます。
• 見える、止められる、監査される。エージェントのセッションは、実行中にホストに表示され、キルスイッチで即座に終了でき、ローカルの監査ログに記録されます。

§06 · ゼロナレッジ設計

ゼロナレッジは、Remioでは宣伝用語ではなく、アーキテクチャ上の制約です。当社のシステムは、セッションの内容が、Remio、その従業員、あるいはいかなる第三者にも、構造的にアクセスできないように設計されています。

当社のサーバーに見えるもの

• 接続するデバイスのIPアドレス（ネットワークに必要）。
• 接続のタイムスタンプ。
• デバイスID（個人情報に紐づかない、不透明な識別子）。
• シグナリングのメタデータ：SDPのoffer/answerの交換、ICE候補。

当社のサーバーに見えないもの

• 画面の内容：映像のフレームは、エンドツーエンドでSRTP暗号化されます。
• 音声：映像と同じSRTP暗号化です。
• 入力イベント：マウス、キーボード、タッチは、DTLSで暗号化されます。
• カーソルの位置：暗号化されたデータチャネルで送られます。
• ファイルの内容：ファイル転送は、すべて暗号化されたチャネルで行われます。
• クリップボードのデータ：暗号化されたデータチャネル。
• アプリケーションの状態：どのアプリを動かしているか、何に取り組んでいるか。

データ保持のポリシー

P2Pのアーキテクチャのため、保持するものは、事実上何もありません。

• セッションの内容。保存されることはありません。リアルタイムのストリームのみ。
• シグナリングのログ。接続のメタデータは、デバッグのために最大30日間保持され、その後削除されます。セッションの内容は含まれません。
• ユーザーアカウント。アカウントは不要です。任意のFirebase Authのデータは、Googleのインフラが管理し、ユーザーが削除できます。
• デバイス情報。各デバイスにローカルに保存されます。サインインを選んだ場合、デバイスの一覧は、アカウントと同期されます（プライバシーポリシーをご覧ください）。

P2P優先のデータフロー

大半の接続（NAT越えが成功した場合）では、データは、サーバーに触れることなく、デバイス間を直接流れます。

# Best case: direct P2P
Client <—— DTLS-SRTP (encrypted) ——> Host
              ↑ No server involvement

# Fallback: TURN relay
Client <— DTLS-SRTP —> TURN server <— DTLS-SRTP —> Host
                            ↑ Still E2E encrypted
                            ↑ Server sees only encrypted blobs

TURNリレーにフォールバックする場合でも、リレーサーバーが扱うのは、暗号化されたパケットだけです。リレーは、単なる土管として動き、データを復号することも、検査することも、改ざんすることもできません。

§07 · ネットワークセキュリティ

P2P接続の確立

Remioは、ICE（Interactive Connectivity Establishment）プロトコルを使って、デバイス間の最良の接続経路を見つけます。

1. ホスト候補：同じネットワーク上での、直接のLAN接続。
2. サーバーリフレクシブ候補（STUN）：STUNサーバーを通じたNAT越えで、グローバルIPを調べます。
3. リレー候補（TURN）：直接の接続を確立できないときの、暗号化されたリレー。

ICEエージェントは、すべての候補のペアを同時にテストし、最も低遅延で、最も信頼できる経路を選びます。直接のP2Pが、常に優先されます。

設定可能なトランスポートのポリシー

接続は、デフォルトで直接のP2Pを優先し、暗号化されたリレーに自動でフォールバックします。すべての通信をリレー経由にする、あるいはLANでの探索を完全に省略するといった、より厳格なポリシーも、制限の厳しいネットワーク環境向けに用意されています。

レート制限

シグナリングサーバーは、悪用を防ぐために、厳格なレート制限を実装しています。

期限切れのレートリミッターは、5分間隔、10分のTTLで自動的にクリーンアップされ、分散攻撃によるメモリーの枯渇を防ぎます。

DDoS対策

当社のシグナリングのインフラは、Cloudflareで保護されており、次の機能を提供します。

• グローバルなエッジネットワークを備えた、AnycastのDNS。
• レイヤー3、4、7でのDDoS緩和。
• Webアプリケーションファイアウォール（WAF）。
• トラフィックがオリジンに届く前の、エッジでのレート制限。
• ボットの検出とチャレンジページ。

§08 · クライアントのセキュリティ

Remioは、各オペレーティングシステムのセキュリティスタックを最大限に活用して、ローカルのデータを守り、アプリケーションの完全性を確保します。

macOS

• Keychainとの統合。すべての機密データ（デバイスの信頼トークン、JWT）は、macOSのKeychainに保存され、ユーザーのログイン認証情報とハードウェア暗号化で保護されます。
• App Sandbox。Remioは、最小限の権限のサンドボックス環境で動きます。画面キャプチャとアクセシビリティには、ユーザーの明示的な承認が必要です。
• コード署名。すべてのビルドは、Apple Developerの証明書で署名されています。
• 公証。macOSのビルドは、Appleによる公証を受けており、既知のマルウェアを含まないことが確認されています。
• Hardened Runtime。本番ビルドでの、コードインジェクション、ライブラリの乗っ取り、デバッグを防ぎます。

iOS

• App Transport Security（ATS）。すべてのネットワーク接続は、HTTPS/TLSを使う必要があります。例外は設定されていません。
• Secure Enclave。利用できる場合、暗号鍵は、Secure Enclaveのハードウェアで生成され、保存されます。
• Keychain Services。デバイスの認証情報は、iOSのKeychainに、kSecAttrAccessibleWhenUnlockedThisDeviceOnlyの保護クラスで保存されます。
• App Storeの審査。すべてのiOSビルドは、Appleのセキュリティ審査のプロセスを通過しています。
• バックグラウンドでのデータなし。アプリは、バックグラウンドにある間、データを収集も送信もしません。

コード署名 & 検証

# Verify Remio macOS binary — verify_signature.sh
$ codesign --verify --deep --strict "Remio Host.app"
# Remio Host.app: valid on disk

$ spctl --assess --verbose "Remio Host.app"
# Remio Host.app: accepted
# source=Notarized Developer ID

§09 · インシデント対応

セキュリティの実績

2026年2月時点で、Remioには、セキュリティ侵害やインシデントの履歴はありません。ゼロナレッジのアーキテクチャによって、攻撃対象は大幅に減っています。標的にできる、認証情報やセッションデータの中央のデータベースがないからです。

脆弱性の報告

セキュリティ研究者による、責任ある開示を歓迎します。脆弱性の可能性を見つけた場合は、次のようにしてください。

1. 詳しい説明を添えて、[email protected]にメールしてください。
2. 該当する場合は、再現手順を含めてください。
3. 48時間以内に、受領を確認します。
4. 確認された脆弱性は、30日以内の解決を目指します。
5. 匿名を希望されない限り、報告者は、当社のセキュリティの更新履歴にお名前を掲載します。

責任ある開示のポリシー

• 公開前に、90日間の開示の猶予期間をお願いしています。
• 善意で行動する研究者に対して、法的措置を取ることはありません。
• 重大度（クリティカル、高、中、低）の順に、修正の優先順位をつけます。
• 正式なバグ報奨金プログラムは、ロードマップに入っています。

インシデント対応のプロセス

セキュリティ上の問題が確認された場合は、次のとおりです。

1. 封じ込め。影響を受けたシステムを、1時間以内に隔離します。
2. 評価。範囲と影響を、24時間以内に判断します。
3. 連絡。影響を受けるユーザーに、72時間以内に通知します（GDPRに準拠）。
4. 是正。自動アップデートのインフラを通じて、パッチを配布します。
5. 事後検証。透明性レポートを公開します。

§10 · コンプライアンス

GDPRへの対応

Remioのゼロナレッジのアーキテクチャは、データの収集を技術的な最小限まで抑えているため、本質的にGDPRに適しています。

• データの最小化。接続の確立に必要なものだけを収集します。
• 消去の権利。ユーザーの内容を保存していないため、削除するものがありません。任意のアカウントデータは、依頼があれば削除できます。
• データポータビリティ。デバイスの信頼データは、ローカルに保存され、ユーザーが管理します。
• 同意。PINによるペアリングは、デバイスごとの明示的な同意の仕組みです。
• 内容の国境を越えた移転なし。P2P接続はデータをデバイス間にとどめ、当社のインフラに入ることはありません。

SOC 2のロードマップ

計画しているコンプライアンスのマイルストーン

• 独立したセキュリティ監査：専門家による侵入テストとコードレビュー。2026年に計画。
• SOC 2 Type I：組織的な管理策の初回の評価。
• SOC 2 Type II：継続的なコンプライアンスの検証。
• バグ報奨金プログラム：責任ある開示への、正式な報奨金。

データの所在

RemioはP2P優先のため、セッションのデータは、お使いのデバイスがある場所にあります。データが、デバイス間の直接の接続の外に出ることはありません。シグナリングサーバー（CloudflareとDigitalOceanでホスト）が処理するのは、接続のメタデータだけで、このメタデータは、個人情報に紐づいていません。

§11 · 代替サービスとの比較

リモートデスクトップの業界は、注目を集めるセキュリティ侵害に悩まされてきました。Remioのアーキテクチャが、集中型の代替サービスと根本的にどう違うのかを示します。

集中型のアーキテクチャが失敗する理由

集中型のリモートデスクトップサービスの根本的な問題は、1回の侵害で、すべてのユーザーが危険にさらされうることです。2024年2月にAnyDeskの本番サーバーが侵害されたとき、攻撃者はコード署名の証明書を盗み、正規のAnyDeskソフトウェアに見せかけたマルウェアを配布できた可能性があります。すべてのユーザーのパスワードがリセットされました。

2024年6月、APT29（ロシアの国家が支援するグループ）がTeamViewerの社内ネットワークに侵入したとき、製品そのものの完全性についての疑問が生じました。集中型のアーキテクチャでは、ベンダーに、セッションにアクセスする技術的な能力があるからです。

Remioは、この種類の攻撃を完全になくします。シグナリングサーバーが侵害されても、得られるのは、接続のメタデータだけです。盗める認証情報も、アクセスできるセッションも、ユーザーのデバイスを狙った悪意あるソフトウェアに署名するために使える証明書も、ありません。

§12 · 結論

Remioのセキュリティは、製品に後付けした機能の集まりではなく、初日から下してきたアーキテクチャ上の判断の帰結です。集中型ではなくP2P、パスワードではなくPINによるペアリング、データ収集ではなくゼロナレッジを選ぶことで、セキュリティが、オプションのアップグレードではなく、初期状態であるリモートデスクトップをつくりました。

私たちは、プライバシーはオプションではないこと、そして信頼は、利用規約で求めるのではなく、透明性を通じて勝ち取るべきものだと信じています。このホワイトペーパーは、その約束の一部です。

質問、エンタープライズ向けのセキュリティレビュー、または脆弱性の報告は、こちらへ。

• セキュリティについてのお問い合わせ： [email protected]
• エンタープライズ向けの営業： [email protected]
• 一般： [email protected]