オリジン・iframe・リクエストの境界

アプリオリジン、ウォレットオリジン、Gateway、鍵管理ロールを、それぞれ独立したセキュリティ主体として扱います。 各主体は、自身の外部入力を境界で一度だけ検証・正規化します。

ブラウザーの境界

• ローカル開発以外ではHTTPSを使う。
• アプリオリジンを厳密に許可する。認証情報付きCORSでワイルドカードを使わない。
• すべてのiframeメッセージのオリジン、送信元ウィンドウ、プロトコルバージョン、セッション識別情報を検証する。
• ウォレットオリジンで、そのオリジンに有効なRP IDを使ってWebAuthnを実行する。
• 鍵、OTP、復元素材、アプリセッショントークン、しきい値署名の状態を、アプリオリジン宛てのメッセージに含めない。

CSPとフレームの制限

制限の厳しいContent Security Policyから始めてください。 アプリのframe-srcに、正確なウォレットオリジンを追加します。 ウォレットオリジンでは、スクリプト、接続、Worker、画像、スタイル、埋め込み元を、デプロイしたリリースが必要とするアセットとオリジンに制限します。 安全でないスクリプトの例外を避けてください。

SDKのiframeは、publickey-credentials-createとpublickey-credentials-getをウォレットオリジンへ委譲します。 アプリのPermissions Policyが、この委譲を許可することを確認してください。 対応ブラウザーで登録とアンロックを確認してください。SDKはアプリオリジンの入力要求へ切り替えません。

サービスへのリクエスト

アプリからGateway、Gatewayからロールへのリクエストは、各境界が管理する方式で認証します。 配送前に、対象、発行者、有効期限、ノンスまたはリプレイキー、メソッド、宛先を検証してください。 公開チャレンジと署名の受付に、レート制限を適用します。 ブラウザー設定に、鍵管理ロールの秘密情報を含めないでください。

Router A/Bの厳密な分離には、AとBそれぞれで、管理、認証情報、ストレージ、ログ、デプロイ権限を独立させる必要があります。

2者間プロトコルを維持しながら、アテステーションを使う実行環境をクラウド間で分離する構成案は、将来のTEEによる保護強化を参照してください。