直接匿名認証

直接匿名証明( DAA ) は、プラットフォームのユーザーのプライバシーを保護しながら、信頼できるコンピューターのリモート認証を可能にする暗号化プリミティブです。このプロトコルは、プライバシーの問題に対処するために、Trusted Computing Group (TCG) のTrusted Platform Module (TPM) 仕様の最新バージョン^{[1]で採用されています (}インターネットの匿名性の喪失も参照)。ISO/IEC 20008 でも DAA が指定されており、Intel のマイクロプロセッサ向けEnhanced Privacy ID (EPID) 2.0 実装は、オープンソース SDK とともに RAND-Zのライセンスで利用できます。

原則として、プライバシーの問題は、標準的な署名方式 (または公開鍵暗号化) と単一の鍵ペアを使用して解決できます。製造元は、製造するすべての TPM に秘密鍵を埋め込み、公開鍵は証明書として公開されます。TPM によって生成された署名は、テクノロジの性質上、秘密鍵から生成されたものでなければなりません。また、すべての TPM が同じ秘密鍵を使用するため、区別がつかず、ユーザーのプライバシーが確保されます。このかなり素朴な解決策は、グローバル シークレットが存在するという仮定に依存しています。DVDの暗号化システムであるコンテンツ スクランブル システム(CSS)の前例を見るだけで、この仮定が根本的に間違っていることがわかります。さらに、このアプローチでは、二次的な目標である不正な TPM を検出する機能を実現できません。不正な TPM とは、侵害されて秘密が抽出された TPM です。

TCG で最初に採用されたソリューション (TPM 仕様 v1.1) では、信頼できるサードパーティ、つまりプライバシー証明機関(プライバシー CA) が必要でした。各 TPM には、エンドースメント キー (EK) と呼ばれるRSAキー ペアが埋め込まれており、プライバシー CA はこれを認識しているものと想定されています。TPM は証明するために、証明 ID キー (AIK) と呼ばれる 2 番目の RSA キー ペアを生成します。EK によって署名された公開 AIK をプライバシー CA に送信し、プライバシー CA はその有効性をチェックして AIK の証明書を発行します (これが機能するには、a) プライバシー CA が TPM の公開 EK を事前に認識しているか、b) TPM の製造元がエンドースメント証明書を提供している必要があります)。これで、ホスト/TPM は証明書に対して自身を認証できるようになりました。このアプローチでは、不正な TPM を検出する 2 つの方法があります。まず、プライバシー CA は、不正であることがわかっている EK で識別される TPM のリストを保持し、それらの TPM からの要求を拒否します。次に、プライバシー CA が特定の TPM から受信した要求が多すぎる場合は、それらの要求を拒否し、TPM EK をブロックリストに追加します。許可される要求の数は、リスク管理演習の対象になります。このソリューションは、プライバシー CA がすべてのトランザクションに参加する必要があり、セキュリティを維持しながら高可用性を提供する必要があるため、問題があります。さらに、プライバシー CA と検証者が共謀すると、プライバシー要件に違反する可能性があります。後者の問題は、ブラインド署名を使用して解決できる可能性がありますが、最初の問題は残ります。

EPID 2.0 ソリューションは、製造時にマイクロプロセッサに秘密キーを埋め込み、物理デバイスの出荷時にキーを配布し、最初の電源投入時にキーがプロビジョニングされて使用できる状態になります。

DAA プロトコルは、3 つのエンティティと 2 つの異なるステップに基づいています。エンティティとは、DAA メンバー (TPM プラットフォームまたは EPID 対応マイクロプロセッサ)、DAA 発行者、および DAA 検証者です。発行者は、参加ステップで TPM プラットフォームを検証し、プラットフォームに DAA 資格情報を発行する責任があります。プラットフォーム (メンバー) は、署名ステップで検証者とともに DAA 資格情報を使用します。ゼロ知識証明により、検証者はプラットフォームのプライバシーを侵害することなく資格情報を検証できます。プロトコルはブロックリスト機能もサポートしているため、検証者は侵害された TPM からの証明書を識別できます。

プロトコルは、さまざまなレベルのプライバシーを許可します。やり取りは常に匿名ですが、メンバー/検証者は、検証者がトランザクションをリンクできるかどうかについて交渉できます。これにより、ユーザー プロファイリングや、リクエストが多すぎるホストからのリクエストの拒否が可能になります。メンバーと検証者は、匿名でないやり取りを実現するために、追加情報を公開することもできます (見知らぬ人にフルネームを伝えるかどうかを選択できるのと同じです)。したがって、匿名のスタートの上に、既知の ID を構築できます (これとは対照的に、既知の ID から始めると、その ID を知らないことを証明して匿名に戻ることはできません)。

最初の直接匿名認証方式は、Brickell、Camenisch、Chen によるものでした。^[2]この方式は安全でないことが判明し、修正が必要でした。^[3] Brickell、Chen、Li は、RSA ではなく対称ペアリングを使用して、最初の方式の効率を改善しました。^[4] Chen、Morrissey、Smart は、対称設定から非対称設定に切り替えることで、さらに効率を改善しようとしました。^{[5] [6]} 残念ながら、非対称方式も安全ではありませんでした。^[7] Chen、Page、Smart は、Barreto–Naehrig 曲線を使用した新しい楕円曲線暗号方式を提案しました。^[8]この方式は、EPID 2.0 と TPM 2.0 標準の両方で実装されています。これは、TPM 全般に推奨されており^[9]、PC クライアント プロファイルに準拠する TPM では必須です。^[10] さらに、ISO/IEC 20008 DAAのIntel EPID 2.0実装と利用可能なオープンソースSDK ^[11]を使用して、メンバーと検証者が認証を行うことができます。TPM 2.0のDAA認証方法の1つはEPID 2.0と同一であるため、ISO/IEC 20008 DAAとTPM 2.0 DAA認証を仕様レベルで互いに一貫して読み取れるようにする作業が進行中です。^{[引用が必要]}

• 暗号化プロトコル
• デジタル認証
• 信頼できるプラットフォームモジュール
• 強化されたプライバシーID
• プライバシー強化技術

• E. Brickell、J. Camenisch、L. Chen:直接匿名認証。第 11 回 ACM コンピューターおよび通信セキュリティ会議の議事録、ACM Press、2004 年。(PDF)
• E. Brickell、J. Camenisch、L. Chen：直接匿名認証（[1]）
• ドメイン間ユーザー認証とプライバシー (Andreas Pashalidis 著) - セクション 6