クレデンシャルを安全に共有する「Secure Credential Transfer」の仕様

AppleGoogle方らによって「Secure Credential Transfer」という提案仕様が、IETFのDispatch WGに提出されています。

この仕様は、イントロダクションにも書かれている通り、iOSAndroidといったプラットフォームの異なるデバイス間でクレデンシャルを共有する方法を定めています。

実際にそういったデバイスを作ってる方々からこのような提案が出てくるというのは興味深いところです。

Secure Credential Transferの概要

この「Secure Credential Transfer」では、リレーサーバというWebアプリケーションを導入し、SenderからReceiverにクレデンシャルを共有します。

共有方法には2つの手順があり

  • ステートレス: 単一のクレデンシャルのみ送信できる
  • ステートフル: 複数のデータを送信できる。ただし手順が長い。

どちらの手順でも、SenderとReceiverは、リレーサーバ上にメールボックスを作成し操作します。メールボックスは仕様上の用語であり、Eメールは関係なく、WebのAPIを介し読み書きを行います。メールボックはそれぞれユニークなURLをもちます (例: https://relay.example/m/1234567890)

SenderとReceiverが、リレーサーバとやりとりする、ときに使用するAPIに関してもこの仕様で定義されます。

また仕様上は、Provisioning Partnersという用語が出てきます。これは、デバイス上でProvisioning Infoを取り扱う主体(エンティティ)を指す用語です。

ステートレス ワークフロー

簡単なステートレスのワークフローで簡単な流れを紹介します。

f:id:ASnoKaze:20211024012313p:plain

  • Senderは、Secretを用いてクレデンシャル情報をProvisioning Infoとして暗号化します。
  • Senderは、リレーサーバのCreateMailbox APIを利用して、メールボックスを作成します
  • リレーサーバは、作成したメールボックスのURLを返します
  • Senderは、得られたメールボックスのURLとSecretを直接Receiverに送ります。仕様上では例として、次のものが上げられています。SMS、電子メール、iMessage。
  • Receiverは、URLとSecretの療法を用いて、Relayサーバーから暗号化されたProvisioning Infoを受け取ります。
  • Receiverはクレデンシャルを取り出した後、該当のメールボックスを削除します

なお、このやり取りの中で、メールボックスは特定のSenderとReceiverに紐付けられます。SenderとReceiverは自身のDevice Claim(トークン)を登録して、それを用いてリレーサーバのAPIを叩きます。そのため、Device Claimが登録された後は、ほかのデバイスはそのメールボックスを利用できません。

なおSenderからReceiverへSecretを送る際、誤った相手と共有してしまうと問題になります。その旨Security Considerationsにも記載されています。

こんご

この仕様については、Dispatch WGのメーリングリストに投稿されています。来月行われるIETF 112で、どのように標準化を進めるか議論されることでしょう。