アダム・パワーズ、FIDOアライアンステクニカルディレクター
FIDOには、よく言及されるがほとんど理解されていない用語である「構成証明」があります。 FIDO製品を実装するエンジニアでさえ、構成証明の仕組みや必要な理由について混乱することがよくあります。 このテクニカルノートは、FIDOトランザクションにおけるアテステーションとその役割を明確にする試みです。この投稿は主に技術コミュニティ向けですが、FIDOの基本的な知識を持つ一般の人にとっても十分に明確であることを願っています。
まず、ユーザーが新しいサービス(Google、Facebook、PayPal、GitHubなど)に登録するたびに、FIDO認証器はそのサービスの新しいキーペアを生成します。 キーは必ずしもそのサービスに固有であり、サービス間で共有されません。 これは、FIDOに最も一般的に関連付けられているキーペアであり、「クレデンシャルキーペア」または単に「キーペア」と呼ばれます。 ユーザーがサービスに登録すると、新しいキー ペアが生成され、公開キーがサービスに送信され、保存され、将来ユーザーを認証するために使用されます。 そのキーペアは構成証明キーペアではなく、さらに混乱を招くために、そのキーペアは「アサーション」(認証中のチャレンジの署名)と呼ばれる操作に使用されます。 「アサーション」と「アテステーション」という用語はしばしば混同されますが、アサーションは認証時に発生します。構成証明は登録時に行われます。
図1 :ユーザーが登録するサービスごとに新しい「認証キーペア」が生成されます。
その文脈を念頭に置いて、構成証明とは何でしょうか? これは、製造時にデバイスに焼き付けられるキー ペアで、デバイス モデルに固有です。 たとえば、すべての YubiKey 4 デバイスには同じ構成証明証明書があります。または、すべてのSamsung Galaxy S8に同じ構成証明証明書があります。 構成証明はデバイス モデルに固有であり、ユーザーが登録時に特定のモデルのデバイスを持っていることを暗号で証明するために使用できます。 ユーザーが上記の新しい “資格情報キー ペア” を作成すると、サービスに送信される公開キーは構成証明の秘密キーで署名されます。 ユーザーの新しいアカウントを作成しているサービスは、新しく作成された公開キーの “構成証明署名” がデバイスからのものであることを検証できます。
一般に、構成証明キーには構成証明証明書が関連付けられており、それらの証明書はサービスが信頼するルート証明書にチェーンされます。 これは、サービスがオーセンティケーターの構成証明キーに対する信頼を確立する方法です。
図2 :登録時に、新しい公開鍵が作成され、製造時にデバイスで作成された構成証明秘密鍵によって署名されます。
構成証明は、次の 2 つのことを実現します。 1)攻撃者が自分の登録メッセージを傍受した場合、構成証明の署名が一致しないため、新しい公開鍵を自分の公開鍵と交換することはできません。そして 2) これにより、サービスは、使用されているオーセンティケーターの出所を知っていることを信頼できます。
一見すると、攻撃者が公開鍵を自分の鍵に置き換えるのを防ぐことが、構成証明のより重要な側面であるように思えるかもしれません。 ただし、FIDOへの登録では、通常、ユーザーがすでに認証されたセッションを持っている必要があり、通信はTLSで保護されているため、悪意のある動作の機会はあまりありません。 このため、多くのサービスでは、オーセンティケーターが「自己構成証明」を使用している場合、オーセンティケーターは拒否されません。 自己構成証明 (代理構成証明とも呼ばれます) は、オーセンティケーターが、ルート証明書にチェーンバックする構成証明証明書ではなく、自己署名証明書を使用する場合です。
ただし、金融業界や公共部門などの一部のサービスでは、サービスにアクセスしているデバイスについて詳しく知る必要がある場合があります。 暗号化キーが安全であること、生体認証が一定レベルの精度であることなどを保証する必要があります。 ここで、構成証明の 2 つ目の側面が重要になり、登録要求が特定のモデルの FIDO 認証器から送信されていることをサービスが信頼できるようになります。
登録時に、デバイスの一意のモデル番号が、新しく作成された公開キーと共にサービスに送信されます。 一意のモデル番号は、UAF の “Authenticator Attestation ID” (AAID) です。FIDO2 の “Authenticator Attestation Globally Unique ID” (AAGUID)またはU2Fの「Attestation Certificate Key Identifier」です。 登録時にユーザーから新しい公開鍵を受け取ると、この一意の識別子を使用して、次のようなサービスでメタデータステートメントを検索できます。 FIDOメタデータサービス(MDS). MDS の各レコードには、デバイスに対応する AAID、AAGUID、または構成証明証明書キー識別子があります。
適切なレコードが見つかると、そのレコードには 2 種類の重要な情報が含まれます。 1)「構成証明ルート証明書」。そして 2)デバイスに関するメタデータ。 前に “自己 (またはサロゲート) 構成証明” について説明しましたが、デバイスでは、構成証明証明書が既知の構成証明ルート証明書までチェーンされる “完全な基本構成証明” を使用することもできます。 公開キーに対する構成証明署名が正しく、証明書チェーンがルート証明書に対して検証されていると仮定すると、サービスは、デバイスのセキュリティや生体認証特性など、デバイスに関する他のメタデータを信頼できます。
(注:FIDO認証器認定プログラムは、鍵やその他のシークレットが外部の脅威から保護されているかどうかをテストし、保証します。FIDOは、生体認証がユーザーを正しく検証することを保証する生体認証プログラムをまもなく開始する予定です。どちらの認定もオーセンティケーターに関するメタデータとして表示され、サービスがオーセンティケーターに対するより強力な信頼を確立できるようにするための詳細情報を提供します。
図 3 : 登録時に、サービスはデバイスの一意の識別子を使用して、メタデータ サービス (MDS) からデバイスに関する “ルート構成証明証明書” と属性を検索できます。
UAF と U2F の場合、それぞれに独自の構成証明形式があります。 UAF には、カスタムの「タグ長値」(TLVの)構造に構成証明署名だけでなく、U2Fプロトコルには構成証明証明書と構成証明署名があります。 FIDO2 と WebAuthn が展開されるにつれて、ますます多くのプラットフォームが、プラットフォームに組み込まれるサービスとして構成証明を組み込んでいます。 Android には、SafetyNet と Android キーの構成証明の両方があります。 最新のほとんどの PC には TPM 構成証明があり、プラットフォームが進化するにつれて、将来的にはさらに多くの構成証明形式が予想されます。 そのため、WebAuthnは複数の構成証明形式を定義し、将来的に新しいものを追加できるようにしています。
構成証明とは何か、どのように使用されるかを明確にするのに役立つことを願っていますが、もう 1 つだけ指摘しておきたいことがあります。 予めご了承ください。 構成証明は、個々のデバイスではなく、デバイス モデルに固有であるはずです 。
すべてのFIDO操作と同様に、構成証明の重要な属性の1つは、ユーザーのプライバシーを保護する必要があることです。 構成証明キーが、個々のデバイスが独自のキーを持つのではなく、デバイスのモデルに共通である理由は、構成証明をユーザーを識別して追跡する方法として使用できないようにするためです。 先日のFIDO相互運用では、FIDOの素晴らしい実装をした、信じられないほど賢く、十分な教育を受けたエンジニアと一緒に仕事をする機会に恵まれました。ただし、デバイスのインスタンスごとに新しい構成証明証明書を作成すべきではないことを理解していませんでした。 これは潜在的に問題であり、電話またはセキュリティキーのモデルを購入するすべての人が同じモデルのデバイスを取得し、異なる構成証明証明書を持っている場合、その構成証明証明書を使用して、サービス全体で個人を追跡および識別できます。 FIDOは強力なプライバシーの原則に基づいており、構成証明を使用してユーザーを追跡すると、 FIDOのプライバシー原則. 構成証明証明書が同じモデル (100,000+) のオーセンティケーターの大規模なバッチで使用されるようにすることで、構成証明証明書に基づいてユーザーを追跡できなくなります。 このブログ投稿が、構成証明証明書を正しく使用し、ユーザーのプライバシーを保護するのに役立つことを願っています。
