オフラインでの無効化
インターネット接続がない場合に、システムはどのように応答者の信頼を無効化しますか？
現状
現在のAndroid実装では、短い有効期限の役割証明書、オフラインでの署名または役割/時間制限チェック、および利用可能なキャッシュ証明書がなくなった場合に強制的にオンラインでの再認証を使用しています。
未解決の事項
デバイス上で明示的にCRLまたはブラックリストのキャプチャをインポートすることは、現在のベースラインでは、強制的な適用パスではなく、デプロイメントターゲットです。
コンテンツ
モバイル技術アーキテクチャ
モバイル技術アーキテクチャ
このページでは、Crisis Connect モバイルアプリがインターネット接続中にエンドツーエンドでメッセージや通話を暗号化し、ネットワークがダウンした場合でもBluetooth経由で動作し、救助隊員を安全な経路に誘導する方法について説明しています。
オープンソースemirhan-duman/Crisis-ConnectBLE + RFCOMM
デフォルトインシデントパス
Wi-Fi Aware + GATT
制御された拡張レイヤー
AES-GCM + ECDH
セキュアトラストプロファイル
Android 1.0.4 · iOS 1.1.0
公開版バージョン
Crisis Connectは、オフラインを優先した緊急通信システムです。インターネットが利用可能な場合は、エンドツーエンド暗号化されたメッセージング、音声およびビデオ通話を提供します。また、インターネットと携帯電話インフラが故障または過負荷になった場合でも、同じアプリは近隣の携帯電話の短距離無線を通じて動作し続けます。Androidアーキテクチャのベースは、インシデントパスをローカルBluetooth上に構築し、オンラインレイヤーをエンドツーエンド暗号化されたエンベロープに構築します。ポリシーが許可される場合にのみ拡張レイヤーを追加し、クラウドをプレーンとして扱い、プレーンテキストコンテンツは一切見ることなく、単に配信と信頼の役割を果たします。
システム概要
オフライン優先メッセージパス: 近くのデバイスはBluetoothで互いを発見し、インターネットに依存せずにローカルな点対点輸送を通じて安全なペイロードを交換します
オンラインレイヤー: インターネットが利用可能な場合は、メッセージはエンドツーエンド暗号化されたエンベロープとして送受信され、1対1の通話はWebRTCで実行され、SOSレポートは承認された対応パネルに到達します
明示的な信頼設定: 既知の連絡先は、QRコードを通じてオフラインで設定され、緊急対応モードではのみ検証されたレスポンダーが安全な双方向チャットに参加できます
制御された拡張モデル: 承認されたレスポンダーネットワークと広範なパブリック連携が存在しますが、それらは別個のもので、厳格に管理されており、デフォルトのパスとして扱われていません
クラウドはコンテンツを認識しません: バックエンドサービスが証明書の発行、信頼アンカーの配布、テレメトリ同期、および暗号化されたエンベロープの配信を行います。その過程で、エンドツーエンドで暗号化されたコンテンツの内容を読み取ることはできません
01
運用モデル
前提、範囲、および現在の能力境界
Crisis Connectは、インターネットが利用可能な状態（日常的なエンドツーエンド暗号化メッセージングと通話）と、広域ネットワークがダウンした場合でも機能するローカル連携を両方サポートするように設計されています。アーキテクチャ上の決定の主な焦点は、近くのスマートフォンが引き続き機能し、オペレーターが制御された—無限ではない—ローカル連携レイヤーを使用できることです。
オフライン優先の前提: このアプリは、インターネットおよびセルラーサービスが利用不可または過負荷の場合に設計されており、近くのスマートフォンにはバッテリーと使用可能なラジオが残っています。
プリインストールされたクライアント: 市民参加では、接続喪失前に互換性のあるアプリのビルドが既にインストールされているか、またはインストールが可能な状況で、承認されたローカルワークフローを通じて配布されることを前提とします。
ローカルラジオ環境: 通信は近接に基づいています。Bluetooth がデフォルトのパスであり、Wi-Fi Aware はサポートされているデバイスでの認証されたレスポンダーメッシュセッションにのみ使用されます。
現在の機能セット: 安全なテキストおよび位置情報の更新、オプションの点対点音声通話、救助モード、承認されたレスポンダーメッシュチャット、エンドツーエンド暗号化インターネットメッセージング、WebRTC 音声およびビデオ通話、およびオプションの Crisis Link telemetry 同期が現在の範囲に含まれます。
噂抑制体制: 市民間のメッセージは既知の連絡先をデフォルトとし、SOS は発見可能ですが、安全なチャットのために検証されます。広範なパブリックコーディネーションはオプションであり、制限されています。
02
設計原則
ローカル優先、クラウド非依存
システムはインターネットなしで完全に動作するように設計されています。オンライン層はオフラインの緊急経路を補完するものであり、置き換えるものではありません。近距離での緊急通信は、デバイス間の無線通信経路を使用します。
直接接続優先、メッシュ非依存
デフォルトではBluetoothによる点対点接続が使用されます。より広範囲な通信は、明示的な役割、機能、およびオペレーターの制御下でのみ有効になります。
制限された実行時間
設計上、電力供給が不安定で、フィールド環境も厳しいため、キューのサイズ制限、再試行回数の上限、フォアグラウンドサービスの制限、および単一通話の音声範囲を意図的に設けています。
信頼は明示的
連絡先は、QRブートストラップと暗号学的本人確認に加えて、応答者による安全なフローが必要な場合にのみ機能します。証明書ベースの検証が必要です。
03
主要無線スタック
RFCOMMペイロード輸送におけるBLE検出と制御
デフォルトのインシデントパスは、異なるタスクを持つ2つのBluetoothレイヤーを組み合わせます。BLEは軽量な検出、サービス信号、および救助制御の交換を処理し、Bluetooth Classic RFCOMMはテキスト、位置情報、メディア、およびオプションの音声などの重い点対点のペイロードトラフィックを伝送します。
検出および制御レイヤー
BLE (GAP/GATT)
存在信号、短い制御交換、救助モード広告、および低電力検出
近隣デバイスの低電力ピア検出とローカル存在ブロードキャスト
認証と制御によるセキュアなセッションの確立前の情報交換
救助モードにおけるSOSビーコンの動作とサービスレベルのシグナリング
ペイロード転送レイヤー
Bluetooth Classic RFCOMM/SPP
テキスト、位置情報、メディア、およびオプションの音声に対する信頼性の高い点対点通信
近くのピア間の高スループットな直接セッション（発見が成功した場合）
アプリケーション定義プロトコルによる安全なメッセージ、画像、ファイル、および音声の転送
互換性には、安全または不安全なソケットへのフォールバックが含まれる場合があるため、メッセージのセキュリティはソケットレベルで強制される
動作範囲: 良好な視界では約50〜150m、都市または混雑した環境では30〜80m、屋内では10〜30m、瓦礫状の障害物がある場合は5〜20mです。両方の範囲とソケットの挙動はデバイスによって異なるため、機密性はRFCOMMモードのみから推測するのではなく、アプリケーション層で確保されます。
04
管理された拡張機能
Bluetoothを介さないベースラインの拡大方法
システムは、安全なレスポンダーメッシュと広範なパブリックな協調の両方がベースラインに存在しますが、それらは異なる信頼、アクティブ化、およびガバナンスルールの下で動作します。
承認されたレスポンダーメッシュ
Androidリリースには、Wi-Fi Awareを介した安全なグループチャット拡張機能が含まれており、これは承認された管理者とフィールドチームの役割に対してオプションです。この機能は、役割証明書とプラットフォームの機能チェックが両方成功した場合にのみ有効になります。
選択可能なパブリックGATTチャンネル
高度な設定から、近隣での一般的なチャットやアナウンスメント用の別のパブリックGATTメッシュを有効化できます。これは意図的に広範囲に及び、機密情報ではない協調トラフィックとして扱われます。
明示的なアクティブ化ゲート
レスポンダーメッシュは、有効なローカルロールとサポートされているハードウェアが必要です。パブリックメッシュは、ユーザーが明示的にパブリックメッシュモードを有効にするまでオフになります。
境界付きの不正アクセス制御
宣言されたパブリックチャネルプロファイルでは、ホップ天井を4に設定し、タイムスタンプウィンドウ、ソースごとのフロッド予算、メッセージサイズ制限、重複抑制、および境界付きのレリーキューを強制します。
05
信頼できるBootstrap
障害の前または最中に信頼を確立
障害中でもQR交換でローカルに信頼を確立できます。事前準備は負担を減らしますが、プロトコルの前提条件ではありません。認証済み番号はオンライン検索と、事前認証後のローカル「近く」を追加します。
完全オフラインQR： 近くの2台がQRでローカルセッションと暗号材料を交換し、Bluetooth経路で検証・保存します。アカウント、SMS、SIM、サーバー検索は不要です。
オンライン連絡先： 両者がオンラインで番号を認証すると、ディレクトリからQRなしで追加できます。
オフラインの「近く」： 事前認証後、選択した番号を秘匿したローカル交換に使用します。番号は送信されず、インターネットも不要です。
有効化： 適用される暗号検証とローカルリンク検査に成功してから保存します。
QRは普遍的なローカル経路で、障害中も利用できます。電話番号方式は両者の事前認証が必要です。ディレクトリには現在の接続が必要ですが、「近く」には不要です。
06
身元と信頼モデル
ローカルQR信頼、認証済み電話検索、レスポンダー証明書
Crisis Connectは、異なる関係に対して異なる信頼パスを使用します。既知の連絡先および認証済みのレスポンダーは、同じブートストラップ、認証、または復旧モデルを共有しません。
既知の連絡先用セキュアパス
連絡先はアカウント、電話番号認証、インターネットなしでQRからローカルに信頼を確立できます。オンライン検索は認証済み番号が必要で、「近く」は事前認証済み番号をオフラインのBluetoothペアリングに再利用します。
レスポンダー認証
救助活動では、ECDSAロール証明書をオフラインでピン留めされた権威の公開鍵に対して検証し、署名、所有者UID、役割範囲、および有効期間を確認してから、安全なプロモーションを行います。
メッシュ資格
承認されたWi-Fi Awareメッシュセッションには、有効なローカルロール証明書とプラットフォームのサポートの両方が必要です。認証されていない接続試行は、メッシュチャットの活性化前に拒否されます。
キーおよび証明書のライフサイクル
役割証明書は、基本設定（現在の発行者プロファイル：72時間のTTL）では一時的なものであり。ローカルのIDキーはAndroidKeyStoreに保存され、その他の機密情報は暗号化されたストレージで保護されます。応答者の状態が欠落または期限切れの場合、再認証または再構成が必要となります。
07
メッセージライフサイクル
発見からACKへの進行
このセクションでは、近接（Bluetooth）の安全なパスのライフサイクルについて説明します。インターネットメッセージングについては、「オンラインレイヤー」セクションを参照してください。近接パスでは、データは送信デバイスで暗号化され、受信デバイスで復号化されます。ピアがオフラインまたは一時的に通信範囲外の場合、配信はローカルリンクを使用し、クラウド経由での通信を待機します。
01BLEによる発見と制御信号は、ピアの可用性を示し、ローカルセッションの準備を行います。
02RFCOMMリンクの確立により、テキスト、位置情報、メディア、およびオプションの音声用の高帯域幅のトランスポートが使用されます。
03既知の連絡先のアクティブ化は、`HSK_REQ`と`HSK_ACK`のチャレンジ応答フレームを使用します。セッションは、タイムアウト制バウンド検証が成功した場合のみ有効になります。
04`SEC_MSG`フレームは、メッセージUUID、IV（初期化ベクトル）、および暗号文で識別される送信者による暗号化されたペイロードを伝送します。受信側は、ローカルでの永続化の前にAEAD（認証型暗号）を検証します。
05`ACK`の進行は、UUIDで永続化されたレコードを複製することなく、メッセージを「送信済み」と「読み取られた」の状態を経由して処理します。
06音声、画像、およびファイルの転送は、チャンキング、再試行ウィンドウ、および転送完了時の整合性チェックを含む、タイプされたJSONレコードファミリーに切り替えます。
07再生、重複、および冪等性のルールは、完璧なリンクを前提とせず、UUIDの一意性、制限付きキャッシュ、および受信側での拒否動作を利用します。
08Public GATTの汎用チャネルは、これらの指定された安全なパスとは論理的に分離されており、機密的なトランスポートとして扱ってはなりません。
プロトコル状態: Androidベースでは、RFCOMMトラフィックは改行区切りのUTF-8レコードであり、パイプ区切り制御行と、より豊かなメディアまたはコールコントロールフローのためのタイプされたJSONファミリーを使用します。
08
音声経路
点対点Bluetooth経由のオーパス
音声はオプションであり、意図的に控えめです。リアルタイムのピアツーピアストリーミングとして、点対点のトランスポート上で動作し、送信前に暗号化されます。バッテリーとRFの安定性も考慮する必要があります。
音声プロファイル
コーデックオーパス
サンプリングレート16 kHz
フレーム / パケット10 ミリ秒 x 5 = ~50 ミリ秒
ビットレート目標20 kbps WB / 16 kbps NB
ジッタバッファ20-50 ミリ秒 (デフォルト: 30 ミリ秒)
バッファリング目標~70-100 ミリ秒
コールシーケンス
01オーディオは、Opusでエンコードされ、暗号化され、アクティブなRFCOMMリンク経由で送信されます。これは、別個のインターネットメディアスタックを経由するのではなく行われます。
02基本範囲では、各ポイントツーポイントリンクあたり1つのアクティブな音声セッションを想定しています。複数の同時音声通話は、1つのデバイスでのみ対象外です。
031秒の制御ループで、ワイドバンドとナローバンドの間で切り替えることができ、6秒間のクールダウンと、プロファイル変更の効果が出る前に交渉された構成のACKが必要です。
04パイロット証拠は、特定のシナリオ条件の下で、コールセットアップ時間、損失、レイテンシ分布、およびバッテリーへの影響を報告する必要があります。これは、単なる個人的な継続性ではなく、具体的な状況に基づいた情報です。
適応ポリシー
実装では、書き込み時間が上昇した場合、またはエラーが再発した場合、またはジッターの深さが不安定になった場合に、WBからNBに自動的に切り替えます。回復後、再度WBに戻すまで待機します。これは、限定的な継続性ポリシーであり、普遍的なQoS保証ではありません。
09
オンライン層
インターネット接続下でのエンドツーエンド暗号化されたメッセージングと通話
インターネット接続がある場合、Crisis Connectは、日常的に使用できるメッセンジャーのように機能します。エンドツーエンド暗号化されたチャット、音声およびビデオ通話、および承認された対応パネルに届くSOSレポートが可能です。この層はオフラインアーキテクチャを置き換えるものではなく、同じ原則に基づいて、デバイス上でコンテンツが暗号化され、サーバーは暗号化されたエンベロープと、配信に必要なメタデータのみを処理します。
エンドツーエンド暗号化されたメッセージング
メッセージ、音声メモ、および添付ファイルは、サーバーが解読できないようにエンドツーエンドで暗号化された「封筒」としてのみデバイスから送信されます。 両者がサポートする場合、セッションはlibsignal（ダブルラッチとポスト量子PQXDHキー合意）を通じてシグナルプロトコル上で実行され、前方秘密保護を提供します。 認証されたECIES封筒（ECDH P-256 + HKDF-SHA-256 + AES-256-GCM）は、古いクライアントをカバーし、前方秘密保護は提供しません。 シグナルセッションが存在すると、その形式へのダウングレードの試みは拒否されます。 従来のP-256アイデンティティキーは、サポートされているデバイスでハードウェアバックされたAndroidKeyStoreに保存され、シグナルのアイデンティティキーは、Keystoreキーの下で暗号化して保管されています。 連絡先は、60桁の安全番号を使用して検証できます。
WebRTC 音声およびビデオ通話
個別の通話は、WebRTCを使用して実行されます。オーディオにはOpus、ビデオには720pまでのカメラ、および画面共有が含まれます。メディアはDTLS-SRTPで暗号化され、SDPとICEのシグナリングもサーバーを経由せずにエンドツーエンドで暗号化されたメッセージエンベロープ内で伝送されます。直接接続ができない場合は、暗号化されたメディアはCloudflare TURNリレーを介してルーティングされます。TURN認証情報はサーバー側で短期間で生成され、サービスに到達不能な場合は、STUN経由での直接接続にフォールバックします。
インターネット上のSOS
インターネット接続が可能な場合、SOSは2つの異なる経路で処理されます。承認された対応パネルに送信されるレポートには、場所、精度、バッテリーレベル、および国が表示され、意図的にエンドツーエンドの暗号化は行われません。これにより、パネルはレポートを読み取ることができます。緊急連絡先に送信されるSOSアラートとライブ位置情報更新は、他のメッセージと同様にエンドツーエンドで暗号化されたメッセージとして送られます。接続がない場合、レポートはキューに入れられ、インターネットが復旧したときに送信されます。BLE SOSビーコンは、すべてのケースで主要なオフライン経路として常に動作します。
トランスポートの選択は自動: Bluetoothリンクがピアに確立されている場合、メッセージはローカルパスを使用します。それ以外の場合は、インターネットを使用します。どちらも利用できない場合は、メッセージはキューに入れられ、同じチャットが1つの会話として続行されます。正直な境界：コンテンツはエンドツーエンドで暗号化されますが、送信および信号メタデータ（送信者と受信者の識別子、タイムスタンプ、IPアドレス）はサーバーによって処理されます。確認されたエンベロープのサーバー上のコピーは削除され、期限切れになったものは削除されます。
10
救助モード
緊急放送、レスポンダーの確認、安全なチャットの促進
救助モードは、発見可能性と信頼性を分離します。被害者は事前にペアリングしなくても見つかることができますが、安全な双方向の救助チャットは、レスポンの確認が完了した後に開始されます。
01 SOSビーコン送信
SOSビーコン送信
- ユーザーによるSOS発動により、デバイスはローカルの緊急状態に移行し、`0xCC00`のRescueサービス用の接続可能なBLE広告を送信します。
- 基本的な広告内容は最小限です：ラジオ信号は、認証されたIDではなく、サービスレベルの発見可能性のみを表示します。
- SOS放送は、広域ネットワークがダウンした場合の近隣レスポンの発見を改善するように設計されています。
- プライバシーに関するコストは明確です：SOSモードでは、発見可能性が増加するため、同意、明確なUIの状態、およびレート制御が重要になります。
02 救助隊員の認証
救助隊員の認証
- 接続後、救助隊員と被害者は、`0xCC10` と `0xCC11` で認証チャレンジと応答を交換し、一時的な ECDH セッションキーを生成します。
- 暗号化された役割証明が `0xCC20` に到着し、証明書参照、役割範囲、発行時間、および有効期限を含める必要があります。
- 安全なプロモーションの前に、署名、信頼アンカー、トランスクリプトバインディング、有効期限、および役割認証を確認します。
- 期限切れ、不正な形式、または範囲外の証明は、救助チャットに降格されることなく、ゲートで拒否されます。
03 安全な救助チャット
安全な救助チャット
- 被害者が `0xCC21` で「OK」を送信し、安全なパスを開くのは、認証が成功した場合のみです。
- 暗号化された双方向の救助チャットは、`0xCC30` と `0xCC31` で「DELIVERED」と「READ」ACK のセマンティクスを使用して進行します。
- 現在の基本的な制約には、制限された役割証明パケットサイズ、MTUに準拠したチャンキング、および大規模だが有限の安全なチャットパケットが含まれます。
- 検証されていないクライアントは、安全な書き込みチャネルに到達しません。プロモーションゲートはハードな境界であり、アドバイザリーUIではありません。
主なセキュリティ特性は、レスキューモードが発見可能性と信頼性を等価ではないということです。近隣での発見は十分な範囲で被害者を特定できますが、安全な救助チャットはそうではありません。
11
バックグラウンドサービス
フォアグラウンド実行とプラットフォーム範囲
主要な検証済みの機関向けランタイムは、Android サービスアーキテクチャです。別個の iOS クライアントは、BLE に重点を置いたメッセージングとレスポンダー制御された救助ロジックを備えて公開されていますが、プラットフォームごとにレスポンダーグレードでの展開に関する証拠を確認する必要があります。
SVC-01
RfcommForegroundService
クラシックなトランスポートリスナー、コールシグナリング、およびメディアまたはファイル転送のライフサイクルを維持し、近距離セッションのために使用します。
SVC-02
GattSOSServerService
救助モードの SOS ブロードキャスターと、BLE 救助フローで使用される被害者による安全なレスポンダーとの相互作用エンドポイントをホストします。
SVC-03
GattRescueClientService + MeshAwareService
レスポンダー側のBLE救助セッションを処理し、承認された場合、Wi-Fi Awareメッシュによる検出と認証を行い、制限付きの再接続を行います。
SVC-04
CrisisLink、オフラインツール、iOS Note
CrisisLinkForegroundServiceは、検証済みのインターネット回復後にキュー内のテレメトリをフラッシュします。OfflineDownloadServiceは、オフラインマップ領域を管理し、個別のiOSクライアントは引き続き有効ですが、独自の準備ゲートの背後で動作します。
12
暗号化と脅威モデル
不安定な無線通信環境におけるアプリケーション層のセキュリティ保証
Bluetoothソケットの動作とRF条件は、デバイスによって異なるため、セキュリティパスに関する保証はアプリケーション層で定義されます。暗号化プロファイル、脅威の前提条件、および鍵の管理モデルは、アーキテクチャの明確な部分です。
レイヤー 01
安全なパスへの連絡: QRで提供された連絡先は、AES-256-GCMと96ビットのIV、および128ビットのタグを使用します。ハードニングされたハンドシェイクフレームは、鍵情報を伝送しません。
レイヤー 02
レスポンダー証明書: レースモードは、安全なチャットの開始前に、オフラインでECDSA P-256ロール証明書をピン留めされた認証局の公開鍵と照合します。
レイヤー 03
レスポンダーメッシュキー: 承認されたWi-Fi Awareメッシュは共有グループキーを使用し、救助（GATT）セキュアチャットの手がかりは、一時的なECDH P-256とHKDF-SHA-256を使用して、各ピアのセッションキーを生成し、AES-256-GCMでメッセージに紐付けられたAADを使用してチャットを暗号化します。
レイヤー 04
ノンとリプレイポリシー: AES-GCMの安全な運用を維持するために、CSPRNGによって生成されたIV、キーごとのパケット数の制限、再起動または再手がかりのリフレッシュ、リプレイキャッシュ、およびUUIDの一貫性が必要です。
レイヤー 05
キーの管理: デバイスのID署名キーはAndroidKeyStore (`dcs_attested_signing_key`)に保存され、機密性の高い対称材料は暗号化されたプリファレンスに保存され、バックアップ機能は無効になっています。
レイヤー 06
パブリックチャネルの境界: 公開GATTパケットは、整合性とフォーマットの保護のためにAES-GCMエンベロープを使用できますが、チャネルは依然として非機密な公開コーディネーショントラフィックとして扱われます。
レイヤー 07
インターネットメッセージエンベロープ: インターネットメッセージの推奨されるパスは、libsignal（ダブルラッチ+ポスト量子PQXDH）を介したSignalプロトコルです。互換性のあるエンベロープは、ECDH P-256 + HKDF-SHA-256 + AES-256-GCMを使用し、AADは送信元、受信者、および会話にバインドされます。また、Signalセッションが存在する場合、レガシー形式へのダウングレードは拒否されます。
レイヤー 08
コールメディアとTURN: WebRTCのコールは、DTLS-SRTPで暗号化されたメディアを使用し、コールシグナリングはエンドツーエンドで暗号化されたエンベロープ内に含まれます。TURNリレーは、のみ暗号化されたパケットを転送し、認証情報はサーバー側で短期間で生成されます。
レイヤー 09
脅威モデル: 設計は、パッシブなRF傍受とアクティブなリプレイ、詐称、妨害、デバイスの大量送信、クラウド制御平面の障害といった攻撃を想定しています。インターネット経路では、サーバーおよび中継インフラはコンテンツに対して信頼できないものとして扱われ、プレーンテキストは決してサーバーに到達せず、配信メタデータは可視状態です。
レイヤー 010
明示的な除外: 完全なOSの侵害、ユーザーによる強制、および全国規模でのRF妨害は範囲外であるため、展開に関する主張には保護を提供するという記述は含めるべきではありません。
ここでは、送信デバイスの暗号化、受信側の検証、明確な役割ゲート、および制限されたメタデータポリシーといった多層防御を採用しています。これにより、ラジオ上で検出されることによるプライバシーへの影響を完全に排除できるわけではありません。
13
プライバシーとガバナンス
メタデータ、噂の抑制、および運用所有権
災害時の運用安全は、暗号化だけでなく、情報フローの制限にも依存します。ポリシー決定、メタデータの遵守、証拠追跡は、この技術アーキテクチャの一部です。
情報衛生
デフォルトの市民間の通信は、事前に設定された連絡先内にとどまり、SOSの発見と安全なチャットは分離され、Public GATTは、レスポンダーによって検証されたアナウンスメント形式でのみ、公式な指示を使用する必要があります。
オンエアメタデータポリシー
オンボーディング放送は時間制約付きで、通常の準備では安定した人間が読み取れる識別子が使用されず、SOSモードでは救助サービスのUUIDを意図的に公開し、パブリックメッシュは送信者ラベルとホップメタデータを内在的に明らかにします。
保持と匿名化
メッセージの永続化にはUUIDベースのレコードを使用し、コールイベント履歴は制限されたウィンドウに切り詰められます。機密キーは暗号化されたローカルストレージに保存され、パイロットログではデバイスIDを匿名化し、位置情報を量子化します。
制御の所有権
発行機関は、証明書の発行、ブラックリストの更新、鍵のロールオーバー、緊急時の取り消し、およびGo/No-Goレビューで使用される証拠アーティファクトについて明確な所有者を必要とします。
Public GATTにおける信頼されたアナウンスメントは、今日の製品保証よりもガバナンス契約です。ダウングレードの証拠とパーサーの対応範囲については、引き続きレビューが必要です。
14
クラウド支援型信頼プラットフォーム
緊急経路の外; オンラインパスでのみ暗号化されたメッセージのみ
Crisis Connectは、連絡者間の近接通信のために完全にオフラインで動作できます。クラウドサービスは、運用テレメトリのサポートと、インターネットメッセージングのためのエンドツーエンド暗号化されたメッセージの配信という2つの役割を果たします。サーバーは決して暗号化されたコンテンツを開きません。また、緊急経路はクラウドなしでも機能します。
身元と発行
担当者は、レスポンダーロール証明書を発行し、キーをローテーションし、機関のIAMまたはKeycloakなどの自社ホストIdPとの信頼ワークフローを統合できます。オフラインでの検証サポート
デバイスは、レスポンダの検証のためにクラウドへの接続なしに、信頼アッカーとポリシーバンドルをローカルで保存します。ブラックリストのスナップショットは、接続ウィンドウのためのデプロイメント拡張です。Crisis Linkテレメトリ
承認された担当者は、インターネットが復旧した後、救助テレメトリのキャプチャをキューし、同期できます。ただし、このチャネルは緊急チャットペイロードを送信しません。暗号化されたメッセージ配信
インターネットメッセージングの場合、バックエンドは暗号化されたメッセージとルーティングメタデータのみを保存します。これにより、オフラインの受信者にメッセージが届きます。サーバーは、配信が確認されるとコピーを削除し、期限切れになったメッセージは削除されます。信頼プラットフォームの分離: 緊急コンテンツは、BLE、RFCOMM、Wi-Fi Aware、またはオプションのPublic GATTチャネルに留まります
クラウドシステムが、証明書のライフサイクル管理、信頼元配信、テレメトリ同期、および暗号化されたメッセージの配信を処理します。
本番環境での運用では、署名キーをソースコードから分離し、HSM、KMS、またはシークレットマネージャーのような制御下に置く必要があります。
15
パイロット段階での証拠と承認の基準
より広範な展開前に測定すべき項目
アーキテクチャに関する主張は、プロトコルの意図だけでなく、現場の証拠に基づいて評価する必要があります。パイロットの承認は、設計の意図ではなく、シナリオデータに基づきます。
メッセージ送信成功率: 屋内または都市環境では95%以上、瓦礫のような状況では85%以内、30秒以内に。
テキスト遅延: 計画された運用範囲内で、エンドツーエンドのメッセージ遅延の95パーセンタイルが5秒以下に保たれること。
音声遅延: アクティブな通話中に、平均片方向遅延が150ミリ秒以下で、3%以下の持続的なパケット損失を維持すること。
電力消費: スタンバイ検出とアクティブな送信または音声の消費は、ミッションで定義された制限内に収まること。現在のPixel 7aのスタンバイに関する証拠は補助的であり、承認基準ではありません。
レスポンダーワークフロー: SOS、役割認証、安全なメッセージ交換、および承認されたメッシュの活性化が、100%のスクリプト検証シナリオを通過すること。
公開チャネルの悪用防止: 不正またはウィンドウ外からのパケットは、中継前に >=99% の割合で破棄し、検証されていないレスポンダーのアナウンスは決して信頼できるアラートとして表示されないようにする。
推奨されるパイロット手順
01
閉鎖型レスポンダーのパイロット: 訓練されたデバイス群から開始し、クレデンシャルの発行、救助モード、バックグラウンドサービスの動作、およびロールベースのメッシュアクティブ化を検証する。
02
シナリオマトリックス: 固定距離のコンテナ、RSSI コンテナ、クロック処理に関するメモ、および明示的な音声継続または喪失トレースを含む、屋内、都市、開けた場所、および瓦礫のような環境でのシミュレーションを実施する。
03
ガバナンスレビュー: 公開チャネルパラメータを固定し、取り消しとロールオーバー手順を文書化し、主張を証拠のアーティファクトにマッピングし、その後初めて段階的な広範な展開を検討する。
現在の証拠状況
2026年6月2日現在、公開ストアのリリースは Android 1.0.4 および iOS 1.1.0 である。2026年3月の Android ベースの証拠は、通過したローカルユニットテストを含む、補助的な待機電力および音声の証拠であり、いくつかの機関ゲートはまだレビューまたは保留状態である。正しい機関態度は、条件なしの広範な展開ではなく、制御されたパイロットの使用である。
16
技術的な未解決の問題
レビュー担当者が依然として確認すべき点
現在のAndroid実装では、実装されている内容、運用上の要件、およびまだ解決が必要な事項が明確に定義されています。これらの点が最も重要なポイントです。
メッシュ範囲
Wi-Fi Awareは、すべてのユーザーに対して一般的なトランスポート層ですか？
現状
いいえ。安全なWi-Fi Awareメッシュは、サポートされているAndroidデバイス向けの承認されたレスポンダー拡張であり、オプションのPublic GATTチャネルとは別に、また直接Bluetooth接続セッションとはさらに別のものです。
未解決の事項
機関は、デバイス機能、オペレーターSOP、およびレスポンダーメッシュを有効にするか抑制すべきかを明確に定義したポリシーが必要です。
電力証拠
現在のバッテリー数値が電力ゲートを閉めますか？
現状
いいえ。2026年3月15日にPixel 7aで実施されたペア比較では、制御されたデバッグ環境およびAC電源を使用した場合、約14.1mWの追加的なスタンバイオーバーヘッドが見られ、これは補完的な証拠としてのみ役立ちます。
未解決の事項
ゲートの閉鎖には、未接続の複数のデバイス間で、特定の条件下でのベースラインとアクティブな状態との比較が必要です。
パブリックチャネルの悪用
スパムや噂の制御は単なる理論上のものですか？
現状
いいえ。パブリックチャネルのプロファイルには、ホップ数、タイムスタンプ、インバウンドフロッド予算、キュー深度、重複処理の取り扱い、およびメッセージサイズのハードな制限が定義されており、関連するロジックの一部はローカルテストで実装されています。
未解決の事項
残っているのは、C-06またはT-08による閉鎖ワークフローに関連付けられた、パケットレベルでのストレス試験と、信頼できるアナウンスメントの降下証明です。
範囲と音声エンベロープ
今日の実際のパフォーマンスエンベロープは？
現状
現在の証拠には、示唆的な範囲バンドに加えて、隣接デバイス、2つの壁、およびクロック調整された音声テストが含まれており、これらは完全な検証なしに実現可能性の主張を強化します。
未解決の事項
レビュー機関による承認には、範囲別に分類された、低劣化のRF信号、複数のデバイスからの追跡データ、および同期されたレイテンシ、損失、およびドロップアウトに関するレポートが必要です。
オンライン層の証拠
オンライン層は、同じ基準で証拠を求められますか？
現状
インターネットメッセージングと1対1の通話は、成熟した、広くレビューされたコンポーネント（libsignal、WebRTC、およびCloudflare TURN）に基づいています。短期間有効な認証情報、エンベロープ形式、ダウングレード拒否、および安全番号の検証は、コードレベルで定義されています。
未解決の事項
グループ通話は現在製品には含まれていません。MLSベース（RFC 9420）のSFU経由でのグループ通話の開発が進行中であり、デバイスによる認証された証拠が必要となります。オンライン層に関する独立した監査も未完了です。
17
制限事項と安全に関する注意
システムが保証しないこと
Bluetoothは近接ベースであり、環境、障害物、ハードウェア、OSの電力ポリシーによって範囲が制限されます。
このシステムは、すべての被害者への到達を保証していません。特に瓦礫の下での状況では。
デフォルトの民生フローは、直接的なローカルリンクに依存します。メッシュモードには、互換性のあるハードウェア、明示的な有効化、およびローカルラジオの近接が必要です。
パブリックなGATTメッシュはオプションであり、デフォルトで無効になっています。すべてのユーザープロファイルに対して常にオンにする設定として推奨されません。
機密性の高い運用情報は、安全なパスまたは役割ベースのレスポンダーチャネルに配置し、広範なパブリックな協調表面には配置しないでください。
無限の非管理型リレーまたは転送動作は、検証された基準外です。
現在の、機関によるAndroid版の導入状況は、主要なものです。iOS版は一般公開されていますが、独自の緊急対応能力の検証が必要です。
デバイス、OS、およびOEMのバッテリー管理の違いにより、動作が変わる可能性があります。そのため、パイロットは個々のデバイスの結果を推測するのではなく、全体的なデバイス群を測定する必要があります。
オンライン連絡先ディレクトリにはインターネットと両者の事前認証済み番号が必要です。これは完全オフラインQRを妨げません。事前認証後は「近く」もオフラインでローカルペアリングできます。
インターネット経由では、コンテンツはエンドツーエンドで暗号化されますが、配信、シグナリング、およびルーター情報—識別子、タイムスタンプ、IPアドレス—はサーバーとTURNインフラによって処理されます。
安全性Crisis Connectは公式の緊急サービスを代替するものではありません。広範囲の経路が利用可能な場合は、ユーザーは引き続き、112、911、または国で指定された同等の番号など、ローカルのエマージェンシーナンバーを試す必要があります。
18
展開シナリオ
インターネット接続下での、家族や友人とのエンドツーエンド暗号化されたメッセージ、音声およびビデオ通話
障害の前または最中にローカルQRで追加した連絡先、または条件を満たす認証済み電話検索による家族・チーム通信
オフラインでのローカルメッセージングと位置情報の共有（オフグリッド旅行やフィールドワーク中）
地震やインフラ崩壊時の被害者によるSOS信号の発信と、救助隊員による確認
インターネット接続のある被害者のSOS報告を、承認された対応パネルにルーティング
Wi-Fi Awareに対応したAndroidデバイスでの、救助隊員専用の安全なグループチャット
近隣での連携と一般的なアナウンスメント（利用者が明示的に有効にした場合）
RFと電力範囲が許可されている場合、直接のBluetoothリンク経由での音声通話
サポートされたモバイルクライアントでオフラインマップのダウンロード、ローカルの生存またはユーティリティツール、および緊急対応ワークフロー
検証済みのインターネット復旧後に、機関のバックエンドへのCrisis Linkテレメトリ同期（オプション）
建築上の成果
Crisis Connectのモバイルアーキテクチャは、意図的に保守的です。インターネットが利用可能な間、コンテンツはエンドツーエンドで暗号化されたエンベロープを通じて移動し、サーバーはそれを見ることができません。ネットワークが故障した場合、デフォルトのインシデントパスはBluetoothであり、信頼性はオフラインで確立され、安全なレスポンダーフローは証明書によって制御され、クラウドは緊急経路から隔離されます。このシステムは、Androidリリースライン周辺での証拠に基づいた機関向けパイロットに適しており、より広範なレスポンダーグレードの展開は、宣言された受け入れ基準を満たすことによるフィールド検証後に待機する必要があります。