特許 7583108 グループ署名による匿名イベント証明

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-11-05

(45)【発行日】2024-11-13

(54)【発明の名称】グループ署名による匿名イベント証明

(51)【国際特許分類】

   H04L 9/32 20060101AFI20241106BHJP

【ＦＩ】

H04L9/32 200B

【請求項の数】 13

【外国語出願】

(21)【出願番号】P 2023081793

(22)【出願日】2023-05-17

(62)【分割の表示】P 2022514770の分割

【原出願日】2021-03-16

(65)【公開番号】P2023096089

(43)【公開日】2023-07-06

【審査請求日】2023-05-19

(31)【優先権主張番号】275954

(32)【優先日】2020-07-09

(33)【優先権主張国・地域又は機関】IL

(73)【特許権者】

【識別番号】502208397

【氏名又は名称】グーグル エルエルシー

【氏名又は名称原語表記】Ｇｏｏｇｌｅ ＬＬＣ

【住所又は居所原語表記】１６００ Ａｍｐｈｉｔｈｅａｔｒｅ Ｐａｒｋｗａｙ ９４０４３ Ｍｏｕｎｔａｉｎ Ｖｉｅｗ， ＣＡ Ｕ．Ｓ．Ａ．

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(72)【発明者】

【氏名】ガン・ワン

(72)【発明者】

【氏名】マルセル・エム・モティ・ユン

【審査官】青木 重徳

(56)【参考文献】

【文献】中国特許出願公開第１０７６５９４０６（ＣＮ，Ａ）

【文献】特開２００９－０２７７０８（ＪＰ，Ａ）

【文献】米国特許第１０１５４０６１（ＵＳ，Ｂ１）

【文献】米国特許出願公開第２０２０／０１６２２５１（ＵＳ，Ａ１）

【文献】米国特許出願公開第２００８／０２７０７８６（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ ９／３２

(57)【特許請求の範囲】

【請求項1】

受信側のコンピューティングシステムによって実行される方法であって、
(i)データのセットおよび(ii)前記データのセットを使用して生成されたデジタル署名を含む証明トークンを、クライアントデバイスから受信するステップと、
前記デジタル署名に基づいて前記証明トークンを妥当性検査するステップであって、
複数のグループ検証鍵のうちの1つまたは複数のグループ検証鍵について、前記グループ検証鍵、前記データのセット、および前記デジタル署名を使用して検証関数を評価して、前記デジタル署名が検証に合格した所与のグループ検証鍵を識別するステップであって、各グループ検証鍵が信頼性のそれぞれのカテゴリに対応する、ステップと、
信頼性の前記カテゴリが前記所与のグループ検証鍵に対応することを決定するステップと、
信頼性の前記カテゴリが前記所与のグループ検証鍵に対応することに少なくとも基づいて前記証明トークンを妥当性検査するステップと
を含む、妥当性検査するステップと、
前記証明トークンを検証することに応答してアクションを実行するステップと
を含む、方法。

【請求項2】

前記証明トークンを受信するステップは、前記証明トークンを含む要求を、前記クライアントデバイスから受信するステップを含み、
前記アクションを実行するステップは、前記要求への応答を、前記クライアントデバイスに送信するステップを含む、請求項1に記載の方法。

【請求項3】

前記デジタル署名は、グループ署名方式と、前記クライアントデバイスに対するデバイスレベル不正検出信号の評価に基づいて前記クライアントデバイスに提供される匿名証明書とを使用して生成される、請求項1または2に記載の方法。

【請求項4】

前記匿名証明書が、前記クライアントデバイスが所与の署名グループに取り消し不能に割り当てられたことを示す取り消し不能な匿名証明書である、請求項3に記載の方法。

【請求項5】

前記グループ署名方式が、直接匿名証明(DAA)署名方式である、請求項3または4に記載の方法。

【請求項6】

前記DAA署名方式が、楕円曲線暗号(ECC)DAA署名方式である、請求項5に記載の方法。

【請求項7】

前記ECC DAA署名方式が、Barreto-Naehrig曲線を用いたECC DAA署名方式である、請求項5に記載の方法。

【請求項8】

前記証明トークンは、前記証明トークンが作成された時刻を示す証明トークン作成タイムスタンプを含み、
前記証明トークンを妥当性検査するステップは、前記証明トークンが受信された時刻と前記証明トークンが作成された時刻との時間差がしきい値内であると決定するステップを含む、請求項1～7のいずれか一項に記載の方法。

【請求項9】

前記証明トークン作成タイムスタンプは、約1ミリ秒未満または約1マイクロ秒未満の時間分解能を有する、請求項8に記載の方法。

【請求項10】

前記証明トークンを受信する前に、前記複数のグループ検証鍵を取得するステップを含む、請求項1～9のいずれか一項に記載の方法。

【請求項11】

前記複数のグループ検証鍵を定期的に取得するステップを含む、請求項1～10のいずれか一項に記載の方法。

【請求項12】

システムであって、
1つまたは複数のプロセッサと、
前記1つまたは複数のプロセッサに、請求項1から11のいずれか一項に記載の方法を実行させるように構成されたコンピュータ可読命令を記憶する1つまたは複数のメモリと
を含むシステム。

【請求項13】

1つまたは複数のコンピュータによって実行されると、前記1つまたは複数のコンピュータに、請求項1から11のいずれか一項に記載の方法の動作を実行させる命令を記憶する非一時的コンピュータ可読媒体。

【発明の詳細な説明】

【背景技術】

【0001】

クライアントデバイスは、インターネットなどの公衆網を介して、要求および他のデータを送信する。これらの通信は、通信を傍受する当事者および/または通信を受信し、それらを他の当事者に転送する仲介者など、他の当事者によって変更することができる。

【0002】

クライアントデバイスはまた、ユーザにわからないようにまたはユーザの認証なしに不正な要求を送信することができるウィルスおよびマルウェアなどの悪意のある攻撃を受ける。加えて、他の当事者は、クライアントデバイスから発生しているように見えるが、実際には他の当事者のデバイスから来る要求を送信するために、クライアントデバイスをエミュレートすることができる。

【0003】

様々な認証技法を使用して、不正および悪用を防止し、公衆ネットワークを介したトランザクションの完全性を保護することができる。同時に、これらの認証技法は、プライバシの問題を含む可能性がある。たとえば、クライアントデバイスのユーザは、クライアントデバイスまたはこれらのクライアントデバイスのユーザを追跡するために使用することができる情報(安定したデバイス識別子など)を共有することを望まないことがあり、データプロバイダは、そのような情報をデータプロバイダが受信または処理することを妨げるプライバシ保護規格下で動作することがある。

【発明の概要】

【発明が解決しようとする課題】

【0004】

本明細書は、クライアントデバイスから送信される通信の完全性を保護すると同時に、クライアントデバイスまたはそのユーザを追跡するために使用することができる安定したデバイス識別子の使用を回避するための認証技法に関する技術について記述する。

【課題を解決するための手段】

【0005】

一般に、本明細書で説明する主題の第1の発明的態様は、コンピュータ実装方法で具現化することができ、コンピュータ実装方法は、デバイス完全性コンピューティングシステムによって、クライアントデバイスから、N個のデバイス完全性要素に対する要求を受信するステップであり、要求が、クライアントデバイスに対するデバイスレベル不正検出信号、およびN個のデバイス完全性要素の各々について、(i)デバイス完全性要素のためのそれぞれの公開鍵、または(ii)デバイス完全性要素のためのそれぞれの公開鍵の派生物のうちの少なくとも1つを含む公開鍵データを含む、受信するステップと、デバイス完全性コンピューティングシステムによって、少なくともデバイスレベル不正検出信号に基づいて、クライアントデバイスの信頼性の評決を判定するステップと、N個のデバイス完全性要素の各々について、デバイス完全性コンピューティングシステムによって、デバイス完全性要素のための少なくとも公開鍵データを使用してデバイス完全性要素を生成するステップであり、デバイス完全性要素は、デバイス完全性要素のための公開鍵データを含むコンテンツのセットに基づいて生成されたデジタル署名を含む、生成するステップと、デバイス完全性コンピューティングシステムによって、N個のデバイス完全性要素をクライアントデバイスに送信するステップとを含む。Nは、たとえば、2以上の整数とすることができる。この態様の他の実装形態は、コンピュータ記憶デバイス上で符号化された方法の態様を実施するように構成された、対応する装置、システム、およびコンピュータプログラムを含む。

【0006】

いくつかの態様では、各デバイス完全性要素は、デバイス完全性要素のためのコンテンツのセットを含むそれぞれのデバイス完全性トークンを含み、デバイス完全性要素のためのコンテンツのセットは、信頼性の評決が判定された時刻を示すタイムスタンプ、およびデバイス完全性要素のための公開鍵データを含み、各デバイス完全性要素を生成することは、デバイス完全性コンピューティングシステムの秘密鍵を使用してデバイス完全性要素のためのコンテンツのセットにデジタル署名することを含む。デバイス完全性要素のためのコンテンツのセットは、信頼性の評決をさらに含むことができる。

【0007】

いくつかの態様では、各デバイス完全性要素を生成することは、ブラインド署名方式を使用して、デバイス完全性要素のための公開鍵データのブラインド署名を生成することを含み、デバイス完全性要素は、ブラインド署名である。方法は、クライアントデバイスのM個の信頼性レベルに対応するM個のブラインド署名検証鍵を公開することと、M個の検証鍵に対応するM個のそれぞれの署名鍵を保持することとをさらに含むことができる。

【0008】

いくつかの態様では、信頼性の評決を判定することは、M個の信頼性レベルから選択された信頼性のレベルをクライアントデバイスに割り当てることを含むことができる。たとえば、各デバイス完全性要素のための公開鍵データは、デバイス完全性要素のための公開鍵の派生物を含むことができ、デバイス完全性要素のための公開鍵の派生物は、ブラインド署名方式を使用してブラインドされたブラインド公開鍵を含むことができる。デバイス完全性要素のための公開鍵の派生物は、デバイス完全性要素のための公開鍵のブラインド切捨て暗号ハッシュを含むことができる。

【0009】

いくつかの態様では、ブラインド署名方式は、プライベートに検証可能なブラインド署名方式を含む。たとえば、プライベートに検証可能なブラインド署名方式は、IETF VOPRFブラインド署名方式とすることができる。

【0010】

他の態様では、ブラインド署名方式は、公的に検証可能なブラインド署名方式を含む。たとえば、公的に検証可能なブラインド署名方式は、ブラインドRSA署名方式とすることができる。

【0011】

本明細書で説明する主題の別の発明的態様は、クライアントデバイスによって実行される方法で具現化され得、方法は、匿名証明書に対する第1の要求をデバイス完全性コンピューティングシステムに送信するステップであり、要求が、クライアントデバイスに対するデバイスレベル不正検出信号を含む、送信するステップと、匿名証明書をデバイス完全性コンピューティングシステムから受信するステップであり、匿名証明書が、少なくともデバイスレベル不正検出信号に基づいて、デバイス信頼性グループのセットから選択された所与の署名グループに対応し、各デバイス信頼性グループが、それぞれの信頼性カテゴリに対応する、受信するステップと、(i)第2の要求と、匿名証明トークンの作成の時刻を示す証明トークン作成タイムスタンプとを含むデータのセットと、(ii)匿名証明書によるグループ署名方式を使用して生成されたデータのセットのデジタル署名とを含む匿名証明トークンを作成するステップと、証明トークンを受信側に送信するステップとを含む。この態様の他の実装形態は、コンピュータ記憶デバイス上で符号化された方法の態様を実施するように構成された、対応する装置、システム、およびコンピュータプログラムを含む。

【0012】

いくつかの態様では、グループ署名方式は、直接匿名証明(DAA)署名方式である。DAA署名方式は、楕円曲線暗号(ECC)DAA署名方式とすることができる。ECC DAA署名方式は、Barreto-Naehrig曲線を用いたECC DAA署名方式とすることができる。

【0013】

いくつかの態様では、匿名証明書は、クライアントデバイスが所与の署名グループに取り消し不能に割り当てられたことを示す取り消し不能な匿名証明書である。

【0014】

いくつかの態様では、デバイス信頼性グループのセットは、少なくとも、メンバーとして、第1の信頼度を有するデバイスを含む第1の信頼性グループと、メンバーとして、第1の信頼度よりも低い第2の信頼度を有するデバイスを含む第2の信頼性グループとを含み、所与のグループが、第1のグループまたは第2の署名グループのうちの1つである。第1および第2の信頼性グループは、デバイス完全性コンピューティングシステムによって公開された対応する第1および第2のグループ公開鍵を有し得る。

【0015】

いくつかの態様では、方法は、匿名証明書をクライアントデバイス上の安全なプライベートキーストアに記憶するステップをさらに含む。

【0016】

いくつかの態様では、トークン作成タイムスタンプは、約1ミリ秒未満または約1マイクロ秒未満の時間分解能を有する。

【0017】

いくつかの実装形態では、方法は、証明トークン量制限を示す情報を受信するステップと、作成するステップの前に、作成が証明トークン量制限を超えないことを確認するステップとをさらに含む。証明トークン量制限は、選択された時間フレーム内に、クライアントデバイスから、選択された宛先ドメインに送信される資格がある匿名トークンの数の制限とすることができる、または、証明トークン量制限は、選択された時間フレーム内に、クライアントデバイス上の1つまたは複数の選択されたアプリケーションから、選択された宛先ドメインに送信される資格がある匿名トークンの数の制限とすることができる、または、証明トークン量制限は、選択された時間フレーム内に、クライアントデバイスから、選択された宛先ドメイン内の選択されたエンドポイントに送信される資格がある匿名トークンの数の制限とすることができる、または、証明トークン量制限は、選択された時間フレーム内に、クライアントデバイス上の1つまたは複数の選択されたアプリケーションから選択された宛先ドメイン内の選択されたエンドポイントに送信される資格がある匿名トークンの数の制限とすることができる、またはそれらの任意の組合せとすることができる。

【0018】

本明細書で説明する主題は、以下の利点のうちの1つまたは複数を実現するために特定の実施形態で実装され得る。

【0019】

クライアントデバイスからデータを送信するために証明トークンを使用することは、クライアントデバイスと、他のエンティティのコンピュータまたは他のデバイスとの間の安全な通信チャネルを提供する。証明トークンとともに、証明トークンに含まれるデータのデジタル署名を含めることによって、エンティティは、証明トークンが作成された後に証明トークン内のデータが変更されなかったことを検証することができる。加えて、証明トークンにトークン作成時間を含めることによって、受信側は、要求が新しいものであるか、またはリプレイ攻撃の潜在的な一部であるかを判定することができる。

【0020】

証明トークンはまた、証明トークンを送信したクライアントデバイスの完全性を示すデバイス完全性トークンも含むことができ、これは、証明トークンの受信側が、データが、たとえば、エミュレータまたは危険にさらされたデバイスからではなく、信用できるクライアントデバイスから来たことを検証することを可能にする。証明トークンの受信側が、クライアントデバイスが信用できるデバイスアナライザによって評価されたこと、およびデバイス完全性トークン内のデータが、信用できるデバイスアナライザによって作成された後に修正されなかったことを検証することができるように、デバイス完全性トークンが、信用できるデバイスアナライザ(たとえば、サードパーティデバイスアナライザ)によって生成され、デジタル署名され得る。

【0021】

証明トークンは、クライアントデバイスから送信される通信の完全性を保護するが、証明トークンの使用に関連付けられた潜在的なプライバシ問題がある。第1のプライバシ問題は、複数の証明トークン内の同じデバイス完全性トークンの再使用によって、証明トークン受信側が、同じクライアントデバイスによって送信された複数の要求を相関させ、その相関に基づいてユーザデータを集約することを潜在的に可能にすることができることである。本明細書で説明する技法は、各々がクライアントデバイスの一意の公開鍵を含む複数のデバイス完全性トークンを使用することによって、そのような相関に対するプライバシを向上させることができる。たとえば、クライアントデバイスは、N個の公開/秘密鍵ペアのバッチを生成し、次いで、N個の対応するデバイス完全性トークンのバッチを受信するために、N個の公開鍵をサードパーティデバイスアナライザに送信することができる。次いで、クライアントデバイスは、たとえば、要求ごとに新しいデバイス完全性トークンを使用することができ、またはクライアントデバイスは、ある時間間隔内にすべての要求について同じデバイス完全性トークンを使用することができ、またはクライアントデバイスは、クライアントデバイス上の同じアプリケーションから発せられたすべての要求について同じデバイス完全性トークンを使用することができ、またはそれらの何らかの組合せを使用することができる。各公開鍵の使用を制限することは、受信側が公開鍵に基づいて相関することができる要求の量を制限する。このバッチアプローチを使用することはまた、そうでなければ、デバイス完全性トークンが必要とされるたびにクライアントデバイスがデバイス完全性トークンに対する要求を送信した場合に導入されるであろうデバイス完全性トークンを含む要求を送信するときに、処理する要求をより少なくすることによってデバイスアナライザの負担を低減し、ネットワーク帯域幅の消費を低減し、クライアントデバイスにおける待ち時間を低減する。

【0022】

第2のプライバシ問題は、クライアントデバイスの安定した公開鍵をデバイスアナライザと共有することにより、デバイスアナライザがクライアントデバイスを追跡することを潜在的に可能にする可能性があることである。たとえば、デバイスアナライザと共謀することによって、複数の別個の証明トークンの受信側は、デバイスアナライザが、同じデバイスからの同じバッチ要求でそれらの証明トークンを受信したことを知ることができ、したがって、そのような証明トークンの受信側は、同じクライアントデバイスによって送信された複数の要求を相関させ、その相関に基づいてユーザデータを集約することができる。本明細書に記載される技法は、公開鍵の生の値ではなく、公開鍵のブラインドバージョンをデバイスアナライザに送信することによって、そのような追跡に対するプライバシを向上させることができる。たとえば、クライアントデバイスは、N個の公開-秘密鍵ペアのバッチを生成し、N個の公開鍵(または公開鍵の暗号ハッシュ(cryptohash))をブラインドし、次いで、N個のブラインド鍵をデバイスアナライザに送信することができ、サードパーティデバイスアナライザは、クライアントデバイス公開鍵の生の値を受信することさえなく、N個の対応するブラインド署名のバッチを返す。

【0023】

本開示のさらなる態様は、公開鍵署名方式ではなくグループ署名方式を使用することによって、信用できるデバイスアナライザと証明トークン受信側の両方による追跡に対するプライバシを向上させるという利点を提供し得る。たとえば、サードパーティデバイスアナライザは、クライアントデバイスの信頼性のレベルに対応する署名グループにクライアントデバイスを割り当て、署名グループの匿名証明書をクライアントデバイスに提供することができる。次いで、クライアントは、匿名証明書によるグループ署名方式を使用して各証明トークンに署名することができ、証明トークン受信側は、サードパーティデバイスアナライザによって公開される公開グループ鍵を使用して匿名署名の妥当性検査を行うことができる。このアプローチを使用することは、多くの公開/秘密鍵ペアを作成する負担からクライアントデバイスのリソースを解放し、公開鍵ごとにデバイス完全性トークンを作成する負担からデバイスアナライザのリソースを解放する。これは、他の機能を実行するためにそれぞれのリソースを解放し、解放されたリソースを使用して、デバイスアナライザがより多くのクライアントデバイスをより短い時間期間で評価することを可能にする。したがって、グループ署名方式の使用は、公開/秘密鍵ペアの生成が低減されるので、より効率的なプロセスを提供する。

【0024】

前述の主題の様々な特徴および利点は、以下で、図面に関して説明される。追加の特徴および利点は、本明細書で説明する主題および特許請求の範囲から明らかである。

【図面の簡単な説明】

【0025】

【図1】デジタルコンポーネントシステムがデジタルコンポーネントを配信する環境のブロック図である。

【図2】N個のデバイス完全性トークンのバッチを要求し、受信するための例示的なプロセスを示すフロー図である。

【図3】認証トークンを送信し、受信し、妥当性検査を行うための例示的な処理を示すフロー図である。

【図4】N個のブラインド署名付きデバイス完全性トークンのバッチを要求し、受信するための例示的なプロセスを示すフロー図である。

【図5】ブラインド署名付き認証トークンを送信し、受信し、妥当性検査を行うための例示的なプロセスを示すフロー図である。

【図6】署名グループの匿名秘密鍵を要求するための例示的なプロセスを示すフロー図である。

【図7】匿名署名付き証明トークンを送信し、受信し、妥当性検査を行うための例示的なプロセスを示すフロー図である。

【図8】公開されたトークン量制限に従うために証明トークンをスロットリングするための例示的なプロセスを示すフロー図である。

【図9】例示的なコンピュータシステムのブロック図である。

【発明を実施するための形態】

【0026】

様々な図面における同じ参照番号および名称は、同じ要素を示す。

【0027】

一般に、本明細書で説明するシステムおよび技法は、クライアントデバイスと、コンテンツパブリッシャ、デジタルコンポーネント配信システム、およびデジタルコンポーネント配信システムによる配信のためにデジタルコンポーネントを作成し、提供するデジタルコンポーネントプロバイダなど他のエンティティとの間の安全な通信チャネルを提供することができる。クライアントデバイスは、要求の完全性およびクライアントデバイスの完全性の妥当性検査を行うために他のエンティティによって使用される証明トークンを、ネットワークを介した要求および他のデータ送信とともに提供することができる。要求は、たとえば、ユーザのデータを管理する(たとえば、ユーザ関連データを削除する)要求、コンテンツの要求、および/または他のコンテンツとともに提示するデジタルコンポーネントの要求を含むことができる。証明トークンを使用して通信チャネルをセキュリティ保護することによって、不正なユーザが、たとえば、デジタルコンポーネント配信システムおよび/またはプロバイダをだますために、ユーザデータを変更、削除、またはそうでなければアクセスしたり、要求の内容を変更したり、または新しい要求を作成したりすることができないことを確実にする。

【0028】

いくつかのアプローチでは、証明トークンは、クライアントデバイスの秘密鍵を使用してデジタル署名することができる。クライアントデバイスは、秘密鍵を秘密に維持することができる。証明トークンは、とりわけ、秘密鍵に対応する公開鍵、ペイロード、およびデバイス完全性トークンを含むことができる。デバイス完全性トークンは、信用できるデバイス完全性システム、たとえば、クライアントデバイスのユーザおよび証明トークンの受信側とは異なるエンティティによって維持されるサードパーティデバイス完全性システムによって判定される、クライアントデバイスの完全性のレベルを示す評決を含むことができる。デバイス完全性トークンはまた、デバイス完全性トークンをクライアントデバイスにバインドするために、クライアントデバイスの公開鍵(または公開鍵の暗号ハッシュ)を含むことができる。

【0029】

デバイス完全性トークンは、デバイス完全性システムが秘密に保持する秘密鍵を使用して、デバイス完全性システムによってデジタル署名することができる。受信側が、たとえば、公開鍵を使用してデバイス完全性トークンのデジタル署名を検証することによって、クライアントデバイスがデバイス完全性システムによって評価されたことを信頼できるように、この秘密鍵に対応する公開鍵を受信側に提供することができる。2対の鍵を使用するこの組合せは、受信側がクライアントデバイスの完全性およびクライアントデバイスから受信された通信の完全性の妥当性検査を行うことを可能にし、他のデバイスがデバイス完全性トークンを使用してそれらの完全性を偽造することができないように、デバイス完全性トークンをクライアントデバイスにバインドする、安全な通信チャネルを提供する。

【0030】

いくつかのアプローチでは、デバイス完全性システムは、デバイス完全性トークンに含めるための公開鍵の生データを受信しない。代わりに、クライアントデバイスは、ブラインド署名方式を使用して公開鍵またはその派生物をブラインドすることによって、ブラインド公開鍵または公開鍵のブラインド派生物(たとえば、公開鍵のブラインド切捨て暗号ハッシュ)を送信することができる。ブラインド署名方式では、デバイス完全性システムは、クライアントデバイスの公開鍵の生の値を受信することなく、クライアントデバイスの完全性を証明することができ、公開鍵を介した潜在的な追跡のリスクを低減することによって、クライアントデバイスまたはユーザのプライバシを向上させる。デバイス完全性システムは、受信側がブラインド署名を検証するために使用することができるブラインド署名検証鍵を公開することができる。

【0031】

他のアプローチでは、グループマネージャとしてデバイス完全性システムとともに、グループ署名方式を使用することができる。たとえば、デバイス完全性システムは、M個の信頼性グループについてのM個のグループ検証鍵を公開し、クライアントデバイスをM個の信頼性グループのうちの1つに割り当て、匿名証明書をクライアントデバイスに配信することができる。クライアントデバイスは、匿名証明書を使用して証明トークンに匿名署名することができ、これらの匿名署名は、公開されたグループ検証鍵を使用して受信側によって検証することができる。グループ署名方式では、デバイス完全性システムも証明トークンの受信側もクライアントデバイスの公開鍵の生の値を受信する必要がなく、公開鍵を介した潜在的な追跡のリスクを低減することによって、クライアントデバイスまたはユーザのプライバシをさらに向上させる。

【0032】

図1は、デジタルコンポーネントシステム150がデジタルコンポーネント129を配信する環境100のブロック図である。例示的な環境100は、ローカルエリアネットワーク(LAN)、広域ネットワーク(WAN)、インターネット、モバイルネットワーク、またはそれらの組合せなど、データ通信ネットワーク105を含む。ネットワーク105は、クライアントデバイス110、パブリッシャ130、ウェブサイト140、デジタルコンポーネント配信システム150、およびデバイス完全性システム170(デバイス完全性コンピューティングシステムとも呼ばれる)を接続する。例示的な環境100は、多くの異なるクライアントデバイス110、パブリッシャ130、ウェブサイト140、デジタルコンポーネント配信システム150、およびデバイス完全性システム170を含み得る。

【0033】

ウェブサイト140は、ドメイン名に関連付けられ、1つまたは複数のサーバによってホストされる1つまたは複数のリソース145である。例示的なウェブサイトは、テキスト、画像、マルチメディアコンテンツ、およびスクリプトなどのプログラミング要素を含むことができる、HTMLでフォーマットされたウェブページの集合である。各ウェブサイト140は、ウェブサイト140を制御し、管理し、および/または所有するエンティティであるパブリッシャ130によって維持される。

【0034】

リソース145は、ネットワーク105を介して提供することができる任意のデータである。リソース145は、リソース145に関連付けられたリソースアドレス、たとえばユニバーサルリソースロケータ(URL)によって識別される。リソースには、ほんのいくつかの例を挙げれば、HTMLページ、ワードプロセッシングドキュメント、およびポータブルドキュメントフォーマット(PDF)ドキュメント、画像、ビデオ、およびフィードソースが含まれる。リソースは、埋め込まれた情報(ハイパーリンク内のメタ情報など)および/または埋め込まれた命令(スクリプトなど)を含み得る、単語、語句、画像、および音声などのコンテンツを含むことができる。

【0035】

クライアントデバイス110は、ネットワーク105を介して通信することが可能な電子デバイスである。例示的なクライアントデバイス110は、パーソナルコンピュータ、モバイル通信デバイス、たとえば、スマートフォン、デジタルメディアプレーヤ、スマートスピーカー、ウェアラブルデバイス(たとえば、スマートウォッチなど)、およびネットワーク105を介してデータを送り、受信することができる他のデバイスを含む。クライアントデバイス110は、一般に、ネットワーク105を介してデータを送信すること、および受信することを円滑にする、ウェブブラウザおよび/またはネイティブアプリケーションなどのアプリケーション111を含む。ネイティブアプリケーションは、特定のプラットフォームまたは特定のデバイスに対して開発されたアプリケーションである。パブリッシャ130は、ネイティブアプリケーションを開発し、クライアントデバイス110に提供することができる。

【0036】

いくつかのリソース145、アプリケーションページ、または他のアプリケーションコンテンツは、デジタルコンポーネントにリソース145またはアプリケーションページを提示するためのデジタルコンポーネントスロットを含むことができる。本明細書全体にわたって使用されるように、「デジタルコンポーネント」という語句は、デジタルコンテンツまたはデジタル情報の個別ユニット(たとえば、ビデオクリップ、オーディオクリップ、マルチメディアクリップ、画像、テキスト、または別の単位のコンテンツなど)を指す。デジタルコンポーネント129は、単一のファイルとして、またはファイルの集合として物理メモリデバイスに電子的に記憶することができ、デジタルコンポーネントは、ビデオファイル、オーディオファイル、マルチメディアファイル、画像ファイル、またはテキストファイルの形態をとり、広告情報を含むことができ、したがって、広告は、デジタルコンポーネントの一種である。たとえば、デジタルコンポーネント129は、アプリケーション111によって提示されるウェブページ、リソース、またはアプリケーションページのコンテンツを補足することが意図されるコンテンツであってもよい。より具体的には、デジタルコンポーネント129は、リソースコンテンツに関連するデジタルコンテンツを含み得る(たとえば、デジタルコンポーネントは、ウェブページコンテンツと同じトピック、または関連するトピックに関連し得る)。したがって、デジタルコンポーネント配信システム150によるデジタルコンポーネントの提供は、ウェブページコンテンツを補足し、一般に拡張することができる。

【0037】

アプリケーション111が、1つまたは複数のデジタルコンポーネントスロットを含むリソース145またはアプリケーションコンテンツをロードすると、ウェブブラウザであり得るアプリケーション111は、デジタルコンポーネント配信システム150に各スロットのデジタルコンポーネント129を要求することができる。デジタルコンポーネント配信システム150は、次に、デジタルコンポーネントプロバイダ160にデジタルコンポーネントを要求することができる。デジタルコンポーネントプロバイダ160は、リソース145および/または他のコンテンツと一緒に提示するためのデジタルコンポーネントを提供するエンティティである。例示的なデジタルコンポーネントプロバイダは、広告を提供する広告主である。

【0038】

いくつかの場合には、デジタルコンポーネント配信システム150は、1つまたは複数のデジタルコンポーネントパートナー152にデジタルコンポーネントを要求することもできる。デジタルコンポーネントパートナー152は、デジタルコンポーネント要求に応答してデジタルコンポーネントプロバイダ160の代わりにデジタルコンポーネントを選択するエンティティである。

【0039】

デジタルコンポーネント配信システム150は、様々な基準に基づいて、各デジタルコンポーネントスロットのデジタルコンポーネントを選択することができる。たとえば、デジタルコンポーネント配信システム150は、デジタルコンポーネントプロバイダ160および/またはデジタルコンポーネントパートナー152から受信されたデジタルコンポーネントから、リソース145または他のアプリケーションコンテンツへの関連性、デジタルコンポーネントの性能(たとえば、ユーザがデジタルコンポーネントと対話するレート)などに基づいてデジタルコンポーネントを選択することができる。次いで、デジタルコンポーネント配信システム150は、リソース145または他のアプリケーションコンテンツと一緒に提示するために、選択されたデジタルコンポーネントをクライアントデバイス110に提供することができる。デジタルコンポーネント配信システム150は、クライアントデバイス110上で動作するアプリケーション111による提示のために、選択されたデジタルコンポーネント129を1つまたは複数のクライアントデバイス110に送信することができる。

【0040】

アプリケーション111がネットワーク105を介して要求120を送信すると、アプリケーション111は、要求とともに証明トークン122を送信することができる。たとえば、アプリケーション111がデジタルコンポーネント配信システム150にデジタルコンポーネント要求を送信する場合、この要求は証明トークン122を含むことができる。同様に、アプリケーション111が、別のエンティティ(たとえば、パブリッシャ130、デジタルコンポーネント配信システム150、デジタルコンポーネントパートナー152、またはデジタルコンポーネントプロバイダ160)に、そのエンティティによって記憶されたデータを管理、たとえば、削除する要求を送信する場合、この要求は、証明トークン122を含むことができる。

【0041】

いくつかの実装形態では、アプリケーション111は、指定されたタイプの要求のための証明トークン122を送信するように構成される。たとえば、証明トークン122を送信する各アプリケーション111は、アプリケーション111に証明トークン122を生成および/または送信させるソフトウェア開発キット(SDK)またはアプリケーションプログラミングインターフェース(API)を含むことができる。SDKは、たとえば、ユーザデータを管理するための要求、デジタルコンポーネントを要求するための要求など、証明トークン122が含まれるべき要求のセットを指定することができる。他のタイプの要求、たとえば、ニュースウェブページを要求する要求は、証明トークン122を必要としない場合がある。

【0042】

クライアントデバイス110はまた、アプリケーション111のための証明トークンを生成する信用できるプログラム114を含むことができる。信用できるプログラム114は、偽造が困難な信頼できるソースからの信用できるコードを含み得る。たとえば、信用できるプログラム114は、オペレーティングシステム、オペレーティングシステムの一部分、ウェブブラウザ、などであってよい。概して、信用できるプログラム114は、侵入が困難であり、犯罪者が信用できるプログラム114を改ざんするために費やすことが必要になる時間および労力の量が極めて高い。加えて、信用できるプログラム114は信頼できるソースによって提供され保持されるため、発生するいかなる脆弱性もソースによって対処され得る。信用できるプログラムは侵入が困難であるため、そのような信用できるプログラムをこのように使用することは、クライアントデバイスにおけるセキュリティを増大する技術的利点を提供する。加えて、信用できるプログラムは信頼できるソースによって保持されるため、このプログラムは信用できるプログラム内の脆弱性を低減する利点を提供する。

【0043】

信用できるプログラム114は、クライアントデバイス110に対してローカルであってよい。たとえば、信用できるプログラム114は、クライアントデバイス110のオペレーティングシステムのデバイスドライバであってよい。いくつかの実装形態では、信用できるプログラム114は、クライアントデバイス110に対して完全にローカルに動作し、ユーザ情報を送信する必要を低減する。いくつかの実装形態では、信用できるプログラム114は、クライアントデバイス110に対して、ネットワーク105などのネットワークを介して、ローカルに動作し得る。たとえば、信用できるプログラム114は、ユーザデバイス110上にインストールされ、ネットワーク105を介して情報を送信および受信するウェブブラウザであってよい。

【0044】

信用できるプログラム114は、以下でより詳細に説明するように、暗号鍵(たとえば、公開/秘密鍵ペア)を生成し、暗号鍵をセキュアストレージ115(たとえば、セキュアキャッシュ)に記憶し、デバイス完全性トークンをセキュアストレージ115に記憶し、証明トークンを生成し、暗号鍵またはその派生物のブラインド署名を生成し、および/または証明書をフェッチおよび記憶することができる。いくつかの実装形態では、信用できるプログラム114は、デバイス完全性クライアントと対話して、デバイス完全性システム170にデータを送信し、デバイス完全性システム170からデータを受信する。いくつかの実装形態では、信用できるプログラム114は、たとえば、ユーザプライバシ設定を変更する要求など、指定されたタイプの要求のセットの各々について証明トークン122を生成するように構成される。

【0045】

証明トークン122は、要求の完全性およびクライアントデバイス110の完全性の妥当性検査を行うためにエンティティによって使用される。たとえば、他のエンティティによって記憶された自己データをユーザが管理できるようにすることは、悪意のあるユーザが他のユーザのデータを管理および/または盗もうとする可能性を広げる可能性がある。デジタルコンポーネントの場合、一部の悪意のあるエンティティは、たとえば、要求が実際よりも価値があるように見えるようにするために、デジタルコンポーネントが提供される異なるリソースを指定するために、および/または、デジタルコンポーネントが提示される異なるユーザを指定するために、デジタルコンポーネント要求のパラメータを改ざんしようと試みる可能性がある。加えて、一部の悪意のある当事者は、不正な目的のために他者のクライアントデバイスをエミュレートしようと試みることがある。

【0046】

証明トークン122は、他者が要求120を変更することを防止し、要求120が妥当性検査合格クライアントデバイス110から来たことを確実にする、クライアントデバイス110と他のエンティティのコンピュータまたは他のデバイスとの間の仲介者を介した安全な通信チャネルを提供する。

【0047】

信用できるプログラム114は、異なる形式を有する、または異なるコンテンツを含む、異なるタイプの証明トークン122を生成することができる。いくつかの実装形態では、証明トークン122は、クライアントデバイス110の公開鍵113と、証明トークン122が作成される時刻を示すトークン作成時間と、ペイロードデータと、クライアントデバイス110から受信されたデータを使用してデバイス完全性システム170または信用できるプログラム114によって生成されるデバイス完全性トークンとを含むセットコンテンツを含む。証明トークン122はまた、証明トークン122およびコンテンツのセットに含まれる公開鍵113に対応する秘密鍵112を使用して、信用できるプログラム114によって生成されたデジタル署名を含むことができる。すなわち、信用できるプログラム114は、秘密鍵112を使用してコンテンツのセットにデジタル署名し、結果として得られるデジタル署名を、コンテンツのセットとともに証明トークン122に含めることができる。

【0048】

いくつかの実装形態では、証明トークン122は、ペイロードデータを含むコンテンツのセットと、証明トークン122が作成される時刻を示す証明トークン作成時間と、コンテンツのセットのデジタル署名とを含む。この例では、信用できるプログラム114は、グループ署名方式と、デバイス完全性システム170によってクライアントデバイス110に発行された証明書とを使用して、デジタル署名を生成することができる。

【0049】

いずれの例においても、クライアントデバイス110は、デジタルコンポーネント配信システム150または他の受信側に送信される要求120に証明トークン122を含めることができる。証明トークン122の受信側は、証明トークン122および/または証明トークン122に含まれるデバイス完全性トークン(適切な場合)の妥当性検査を行うことを試みることができる。証明トークン122が妥当性検査に合格した場合、受信側は、クライアントデバイス110が信用できるデバイスであるかどうかを判定し、それに応じて要求を処理することができる。証明トークン122が妥当性検査に合格しなかった場合、受信側は、たとえば、要求120に応答することなく、または要求120に応答してデータを変更することなく、要求120を無視または削除することができる。証明トークン122を含む要求を生成し、証明トークンの妥当性検査を行う例示的なプロセスが図2～図8に示されており、以下で説明する。

【0050】

証明トークン作成時間は、証明トークン122が作成された時刻を示す。信用できるプログラム114は、信用できるプログラム114が証明トークンを作成する作成時間を記録することができる。この証明トークン作成時間は、高分解能タイムスタンプ(たとえば、秒、ミリ秒、またはマイクロ秒の精度)とすることができる。証明トークン作成時間は、証明トークン122を含む要求120が新しい要求であるか、または最近の要求であるかを判定するために使用することができる。たとえば、証明トークン122を受信するエンティティは、トークン作成時間を、現在時間または証明トークン122が受信された時間と比較することができる。2つの時間の差がしきい値を超える場合、エンティティは、以下でより詳細に説明するように、要求が新しいものではない、または無効であると判定することができる。

【0051】

証明トークン作成時間は、リプレイ攻撃を検出するために使用することもできる。たとえば、同じ証明トークン作成時間を含む、同じデータのセットを有する複数の要求が受信される場合、要求を受信するエンティティは、要求が複製であること、および/または要求がリプレイ攻撃の一部であることを判定することができる。

【0052】

証明トークン作成時間は、他のデータと組み合わせて、要求120のためのトランザクション識別子としての役割も果たすこともできる。たとえば、トランザクション識別子は、証明トークン122が公開鍵113を含む実装形態では、証明トークン122の証明トークン作成時間と証明トークン122の公開鍵113との2つ以上の組合せとすることができる。トランザクション識別子は、複数のチャネルから受信された同じ要求の複数のバージョンを重複排除するために使用することができる。たとえば、デジタルコンポーネントプロバイダ160-3は、デジタルコンポーネント配信システム150とデジタルコンポーネントパートナー152の両方から同じ要求を受信することができる。この例では、トランザクション識別子は、証明トークン122のトークン作成時間および証明トークン122の公開鍵113に基づくことができる。デジタルコンポーネントプロバイダ160-3は、2つ以上の要求の中の2つのデータを比較して、要求が重複しているかどうかを判定することができる。

【0053】

ペイロードは、個々の要求120のためのデータを含むことができる。たとえば、要求120がデジタルコンポーネントに対するものである場合、ペイロードは、デジタルコンポーネントを選択するために使用することができるデータを含むことができる。このペイロードは、デジタルコンポーネントスロット(またはリソース145のURL)を有するリソース145、リソース145に関する情報(たとえば、リソースのトピック)、デジタルコンポーネントスロットに関する情報(たとえば、スロットの数、スロットのタイプ、スロットのサイズなど)、ユーザがこの機能を有効にした場合のクライアントデバイス110に関する情報(たとえば、デバイスのタイプ、デバイスのIPアドレス、クライアントデバイス110の地理的位置)、および/または他の適切な情報を含むことができる。

【0054】

要求120が、パブリッシャ130、デジタルコンポーネント配信システム150、デジタルコンポーネントパートナー152、デジタルコンポーネントプロバイダ160、または別のエンティティにおいてユーザのデータを管理することである場合、要求120は、要求された変更を指定するデータを含むことができる。たとえば、ユーザがデジタルコンポーネントプロバイダ160-2からユーザのデータのすべてを除去することを選択した場合、ペイロードは、このデータの除去およびデジタルコンポーネントプロバイダ160-2を指定するデータ(たとえば、デジタルコンポーネントプロバイダ160-2の識別子またはネットワークアドレス)を含む。

【0055】

デバイス完全性システム170は、クライアントデバイス110から、たとえば、信用できるプログラム114から受信されたデバイスレベル不正検出信号を評価し、デバイスレベル不正検出信号に基づいてクライアントデバイス110の信頼性(または完全性)のレベルを判定する。デバイスレベル不正検出信号は、クライアントデバイスが損なわれているかどうか、またはクライアントデバイスが通常のクライアントデバイスとして動作しているかまたはエミュレートされたクライアントデバイスとして動作しているかを判定するために使用され得る、クライアントデバイスの動作特性またはメトリックを表すデータを含み得る。いくつかの動作特性およびメトリックは、エミュレータと比べて、真のクライアントデバイスでは異なることがよくある。いくつかの実装形態では、デバイスレベル不正検出信号は、信用トークンを要求しているアプリケーション111の動作特性およびメトリックを含むアプリケーションレベルの不正検出信号を含む。信用できるプログラム114は、これらのデバイスレベル不正検出信号を収集し、これらの信号を信用トークンに対する要求内に含めることができる。

【0056】

デバイス完全性システム170は、クライアントデバイス110の信頼性(または完全性)のレベルを示す評決を発行することができる。受信側は、評決を使用して、その評決を含む要求120を信用すべきかどうかを判定する。たとえば、評決が、クライアントデバイス110が信頼できないことを示す場合、受信側は、たとえば、要求に応答しないなど、要求を無視することができる。

【0057】

上記で説明したように、いくつかのアプローチでは、デバイス秘密/公開鍵ペア(およびデバイス公開鍵に関連付けられたデバイス完全性トークン)は、複数の証明トークンにわたって変更されて、証明トークン受信側による追跡に対するクライアントデバイスまたはユーザのプライバシを向上させることができる。たとえば、クライアントデバイスは、秘密/公開鍵ペアのバッチを生成し、デバイス完全性トークンの対応するバッチをデバイス完全性サーバから取り出すことができ、その結果、デバイス完全性トークンの再利用が低減または排除される。このバッチプロセスの例示的な例を図2に示す。

【0058】

この例では、クライアントデバイス200は、N個の公開/秘密鍵ペアを作成する(201)。たとえば、クライアントデバイス200の信用できるプログラムは、公開/秘密鍵ペアを生成することができる。公開/秘密鍵ペアは、非対称鍵ペアとすることができる。各公開/秘密鍵ペアは、秘密鍵と、秘密鍵に対応し、数学的にリンクされた公開鍵とを含む。秘密鍵を使用してデジタル署名されたデータは、対応する公開鍵を使用してのみ検証することができる。同様に、公開鍵を使用して暗号化されたデータは、対応する秘密鍵を使用してのみ復号することができる。

【0059】

クライアントデバイス200は、N個のデバイス完全性要素に対する要求をデバイス完全性コンピューティングシステム220に送信する(202)。数Nは、2以上の整数とすることができる。この例では、デバイス完全性要素は、デバイス完全性トークンであり、要求は、N個の公開/秘密鍵ペアに対応するN個のデバイス完全性トークンに対するものである。信用できるプログラムは、信用できるプログラムが要求において一意のデバイス完全性トークンを使用する頻度に基づいて、要求すべきデバイス完全性トークンの数Nを判定することができる。クライアントデバイスは、要求されたデバイス完全性トークンごとに公開/秘密鍵ペアを生成し、要求に公開鍵データを含めることができる。この例では、公開鍵データは、公開鍵自体とすることができる。したがって、要求は、クライアントデバイス200のN個の公開鍵211をデバイス完全性サーバ220に渡すことを含む。この例では、N個の公開鍵211は、実際の公開鍵、たとえば、N個の公開鍵211の生データを含む。要求はまた、デバイスレベル不正検出信号を含むことができる。たとえば、信用できるプログラムは、デバイスレベル不正検出信号を収集し、これらの信号を要求内に含めることができる。

【0060】

デバイス完全性コンピューティングシステム220は、要求を受信する(221)。クライアントデバイスから受信されたデバイスレベル不正検出信号に基づいて、デバイス完全性コンピューティングシステム220は、クライアントデバイスの信頼性のレベルを判定する(222)。たとえば、デバイス完全性コンピューティングシステムは、それぞれの評決に各々対応するM個の可能な信頼性レベルを有し得る。この例では、デバイス完全性コンピューティングシステム220は、上記のように、デバイスレベル不正検出信号に基づいて、これらのM個の可能な信頼性レベルのうちの1つを選択することができる。

【0061】

デバイス完全性コンピューティングシステム220は、N個のデバイス完全性要素を生成する(223)。この例では、各デバイス完全性要素は、デバイス完全性トークンの形式である。すなわち、デバイス完全性コンピューティングシステム220は、受信された公開鍵ごとにそれぞれのデバイス完全性トークンを生成する。

【0062】

各デバイス完全性トークンは、信頼性評決、信頼性の評決のためのタイムスタンプ、およびクライアントデバイス200のN個の公開鍵211のうちの1つを含むことができる。タイムスタンプは、デバイス完全性トークンが生成される時刻を示す。デバイス完全性システムは、N個の公開鍵211のうちの1つに基づいて各デバイス完全性トークンを生成することができる。たとえば、デバイス完全性システム220は、クライアントデバイス200の公開鍵、信頼性評決、およびタイムスタンプを含むデータのセットをアセンブルすることができる。信頼性の評決がちょうど2つの可能な評決(信頼できる、および信頼できない)を含むいくつかのアプローチでは、信頼性の評決は、デバイス完全性トークンから省略することができる。言い換えれば、これらのアプローチでは、デバイス完全性システムは、信頼できるデバイスのためのデバイス完全性トークンを生成することができ(これらのトークンは、信頼性の暗黙の評決を省略する)、信頼できないデバイスのためのデバイス完全性トークンを生成することを単に拒否することができる。

【0063】

デバイス完全性コンピューティングシステム220は、N個のデバイス完全性トークンの各々にデジタル署名する(224)。たとえば、デバイス完全性コンピューティングシステム220は、デバイス完全性システムの秘密鍵を使用し、デバイス完全性トークンの他のデータ(たとえば、信頼性評決、クライアントデバイス200の公開鍵、およびタイムスタンプ)に基づいて、デジタル署名を生成することができる。

【0064】

デバイス完全性コンピューティングシステム220は、N個のデバイス完全性トークンをクライアントデバイスに送信する(225)。クライアントデバイス200は、デバイス完全性トークンのバッチを受信し、後の使用のために記憶する(203)。クライアントデバイス200は、デバイス完全性トークンをローカルに、たとえば、信用できるプログラムによって維持されるキャッシュまたはセキュアストレージに記憶することができる。各キャッシュデバイス完全性トークンは、たとえば、(1)デバイス完全性コンピューティングシステム220によって判定される信頼性の評決、(2)デバイス完全性トークンの作成のためのタイムスタンプ、(3)クライアントデバイスの公開鍵、および(4)デバイス完全性コンピューティングシステム220の秘密鍵を使用して署名されたトークンコンポーネントのデジタル署名を含むことができる。

【0065】

図2の例に示されるように、デバイス完全性トークンのバッチを取得すると、クライアントデバイスは、デバイス完全性トークンを使用して、上記で説明したように、デジタルコンポーネントプロバイダまたは他の証明トークン受信側に向かう様々な要求の一部として証明トークンをアセンブルし、送信することができる。そのような要求の例示的な例が、図3にプロセスフロー図として示されている。

【0066】

要求を準備するために、クライアントデバイス300は、クライアントデバイスのローカルストレージからデバイス完全性トークンを取り出すことができる(301)。様々なアプローチでは、クライアントデバイス300は、たとえば、(1)要求ごとに新しいデバイス完全性トークンを使用することができる、または(2)選択された時間間隔(たとえば、H連続時間)にわたって同じデバイス完全性トークンを使用し、その間隔が経過すると、異なるデバイス完全性トークンを使用することができる、または(3)同じアプリケーションまたはウェブサイトから発せられたすべての要求について同じデバイス完全性トークンを使用することができる(たとえば、異なるデバイス完全性トークンが各アプリケーションまたはウェブサイトに使用される場合)、または(4)これらのトークン再使用アプローチのうちの2つ以上の組合せを使用することができる(たとえば、選択された時間間隔内に同じアプリケーションまたはウェブサイトから発せられたすべての要求について同じデバイス完全性トークンを使用する)。したがって、クライアントデバイス300は、要求が生成されるアプリケーションまたはウェブサイト、あるいは要求が生成される現在時間に基づいて、デバイス完全性トークンを取り出すことができる。

【0067】

クライアントデバイス300は、要求を生成することができる(302)。要求311は、たとえば、(上記で説明したように)ペイロードデータ、要求作成タイムスタンプ、取り出されたデバイス完全性トークン、デバイス完全性トークンに対応するデバイス公開鍵、および要求コンポーネントのデジタル署名を含むことができる。クライアントデバイスの信用できるプログラム、またはクライアントデバイスのオペレーティングシステムの信用できるコンポーネントは、ペイロードデータおよびデバイス保全性トークンにアクセスすることによって、証明トークンを含むことができ、または証明トークンの形式とすることができる要求311を生成することができる。信用できるプログラムは、要求作成タイムスタンプとして、現在時間を判定することもできる。信用できるプログラムは、クライアントデバイスの秘密鍵(たとえば、要求に含まれるデバイス公開鍵に対応する秘密鍵)を使用して、ペイロードデータ、公開鍵、およびタイムスタンプのデジタル署名を生成することができる。いくつかのアプローチでは、証明トークンサイズを低減するための単純な最適化として、デバイス公開鍵は、証明トークンのコンポーネントとして含まれるデバイス完全性トークンにすでに存在するので、証明トークンは、デバイス公開鍵を省略する。

【0068】

クライアントデバイス300は、要求311を受信側のコンピューティングシステム320に送信する(303)。この例では、受信側は、デジタルコンポーネントプロバイダである。たとえば、クライアントデバイス300は、要求311をデジタルコンポーネント配信システムに送信することができ、デジタルコンポーネント配信システムは、要求を1つまたは複数のデジタルコンポーネントプロバイダに送信することができる。

【0069】

受信側コンピューティングシステム320は、要求を受信する(321)。受信側コンピューティングシステム320は、要求の妥当性検査を行う(322)。たとえば、受信側コンピューティングシステム320は、要求に含まれるデバイス公開鍵を使用して、要求のデジタル署名を検証することによって、要求の妥当性検査を行うことができる。受信側コンピューティングシステム320は、公開鍵と、たとえば、ペイロードデータ、タイムスタンプ、公開鍵、およびデバイス完全性トークンなど、クライアントデバイス300によって署名された要求のコンテンツを使用して、デジタル署名を検証しようと試みることができる。デジタル署名が生成された後にこのコンテンツのいずれかが変更された場合、検証は失敗する。たとえば、悪意のある当事者が、デバイス完全性トークンを別の要求に挿入した場合、または信頼性のより高い評決を有する異なるデバイス完全性トークンを要求に挿入した場合、署名検証は失敗することになる。これは、要求の内容が、たとえば仲介者による要求の送信中に変更されなかったことを確実にする。

【0070】

受信側コンピューティングシステム320は、デバイス完全性トークンの妥当性検査を行う(323)。たとえば、受信側コンピューティングシステム320は、デバイス完全性コンピューティングシステムの公開鍵を使用してデバイス完全性トークンの署名を検証することによって、デバイス完全性トークンの妥当性検査を行うことができる。これは、同様に、デバイス完全性トークンがデバイス完全性トークンコンピューティングシステムによって発行されたので、デバイス完全性トークンのコンテンツが変更されていないことを確実にする。証明トークンがデバイス公開鍵を含む場合、デバイス完全性トークンの妥当性検査は、証明トークンに含まれるデバイス公開鍵がデバイス完全性トークン内に含まれるデバイス公開鍵と一致するという確認も含むことができる。

【0071】

受信側コンピューティングシステム320は、デバイス完全性トークンの適時性およびクライアントデバイスの信頼性の妥当性検査を行って(324)、たとえば、デバイス完全性トークンが最近作成された(すなわち、H,D=1,2,3,…の場合、要求が行われた時間のH時間またはD日前など、選択された時間間隔を超えて作成されなかった)ことを確認し、デバイス完全性トークン内の信頼性評決が要求に従うのに十分な評決であることを確認する。

【0072】

これらの妥当性検査のすべてが合格である場合、受信側コンピューティングシステム320は、要求に応答して(325)、たとえば、上記で説明したように、設定を変更し、ユーザデータを追加または削除し、デジタルコンポーネントを配信することなどができる。妥当性検査のいずれかが不合格である場合、受信側コンピューティングシステム320は、要求を無視することができる。たとえば、受信側コンピューティングシステム320は、要求に応答しなくてもよく、要求された動作を実行しなくてもよい、などである。

【0073】

デジタルコンポーネントを配信することを含む要求の場合、応答325は、随意に、適切なデジタルコンポーネント312を送信することを含むことができる。たとえば、受信側コンピューティングシステム320は、要求のペイロードに基づいてデジタルコンポーネントを選択し、デジタルコンポーネントを、要求をデジタルコンポーネントプロバイダに送信したデジタルコンポーネント配信システムに送信することができる。次に、デジタルコンポーネント配信システムは、デジタルコンポーネントをクライアントデバイス300に送信することができる。クライアントデバイス300は、デジタルコンポーネントを受信することができる(304)。次に、クライアントデバイス300は、デジタルコンポーネントを提示することができる。

【0074】

上記で説明したように、いくつかのアプローチでは、デバイス完全性トークンを生成するためのプロセスにおいて、デバイス完全性コンピューティングシステムがクライアントデバイスの公開鍵の生データを認識しないように、ブラインド署名方式が使用されてもよい。たとえば、クライアントデバイスは、秘密/公開鍵ペアのバッチを生成し、次いで、公開鍵をデバイス完全性システムに送信してデバイス完全性要素の対応するバッチを取り出す前に、ブラインド署名方式を使用して、公開鍵(または、公開鍵の暗号ハッシュ、またはデバイスモデル番号と連結された公開鍵の暗号ハッシュなど、ブラインド署名方式のコミットフェーズのための値として使用され得るこれらの公開鍵の適切な派生物)をブラインドすることができる。この例では、デバイス完全性要素は、ブラインド公開鍵のブラインド署名である。このバッチプロセスの例示的な例を図4に示す。

【0075】

この例では、デバイス完全性コンピューティングシステム420は、クライアントデバイスについてのM個の異なる信頼性レベルを定義し、対応するM個の信頼性レベルに対してM個の異なるブラインド署名検証鍵411を公開することができる(421)。たとえば、M個のレベルは、信頼できるレベルと信頼できないレベルの2つのレベルを含むことができる。別の例では、M個のレベルは、疑わしい、満足できる、および信用できるの3つのレベルを含むことができる。他の例では、M個のレベルは、不正、疑わしい、満足できる、および信用できるの4つのレベルを含むことができる。他の量のレベルも使用可能である。したがって、Mは、2以上の整数とすることができる。いくつかのアプローチでは、最低レベルの信頼性(たとえば、「信頼できない」または「不正な」レベルの信頼性)にブラインド署名検証鍵を割り当てる代わりに、最低レベルの信頼性をM個のレベルの信頼性から省略することができ、デバイス完全性コンピューティングシステムは、単に、最低レベルの信頼性を有するデバイスにブラインド署名を提供することを拒否することができる。したがって、これらのアプローチでは、Mは、1以上の整数とすることができる。

【0076】

デバイス完全性コンピューティングシステム420は、ブラインド署名方式を使用して、信頼性のレベルごとにそれぞれのブラインド署名検証鍵411を生成することができる。ブラインド署名方式は、インターネットエンジニアリングタスクフォース(IETF)のVerifiable Oblivious Pseudorandom Functions(VOPRF)ブラインド署名方式など、プライベートに検証可能なブラインド署名方式とすることができる。他のアプローチでは、ブラインド署名方式は、Rivest-Shamir-Adleman(RSA)ブラインド署名方式など、公的に検証可能なブラインド署名方式とすることができる。

【0077】

デバイス完全性コンピューティングシステム420は、クライアントデバイス400を含むクライアントデバイスがブラインド署名検証鍵411を取得することができるように、ブラインド署名検証鍵411を公開することができる。たとえば、デバイス完全性コンピューティングシステム420は、ブラインド署名検証鍵411をウェブサイトまたはモバイルアプリストアに公開することができる。

【0078】

クライアントデバイス400は、これらのブラインド署名検証鍵を受信することができる(401)。たとえば、クライアントデバイス400は、ブラインド署名検証鍵411をダウンロードし、ブラインド署名検証鍵411をローカルに、たとえば、セキュアストレージまたはキャッシュに記憶することができる。クライアントデバイス400は、以下でさらに説明するように、デバイス完全性コンピューティングシステム420から後に受信されるブラインド署名を検証するために、ブラインド署名検証鍵411を保持することができる。いくつかのアプローチでは、デバイス完全性コンピューティングシステム420は、新しいブラインド署名検証鍵411を定期的に公開することができ(たとえば、毎時、毎日、毎週、または他の適切な時間期間)、ブラインド署名検証鍵のセットのこのリフレッシュは、以下でさらに説明するように、デバイス完全性トークンの適時性の妥当性検査を行うために使用することができる。

【0079】

N個のデバイス完全性トークンのバッチを取得するために、クライアントデバイス400は、N個の公開/秘密鍵ペアを作成する(402)。たとえば、クライアントデバイスの信用できるプログラムは、デバイス完全性トークンごとにそれぞれの非対称公開/秘密鍵ペアを作成することができる。

【0080】

クライアントデバイス400は、ブラインド署名検証鍵を生成するために使用されるブラインド署名方式に従って、各公開鍵または各公開鍵の派生物をブラインドする(403)。すなわち、クライアントデバイス400は、公開鍵データが公開鍵または公開鍵の派生物のいずれかである場合、公開鍵ごとに公開鍵データをブラインドする。公開鍵をブラインドすることは、公開鍵の生の値にブラインド係数を適用することによって、公開鍵の生の値を不明瞭にすることを含むことができる。このようにして、デバイス完全性コンピューティングシステム420は、クライアントデバイス400から受信された公開鍵の生の値にアクセスすることができず、これらの値を使用して、たとえば、追加のデータとともに公開鍵の生の値を受信した別のエンティティから受信されたデータを使用して、ユーザまたはクライアントデバイス400を追跡することができない。

【0081】

デバイス完全性コンピューティングシステム420によってブラインド署名される必要があるデータの量を低減するために、各デバイス公開鍵全体をブラインドする代わりに、クライアントデバイス400(たとえば、その信用できるプログラム)は、公開鍵の派生物を生成し、公開鍵の派生物をブラインドすることができる。派生物は、公開鍵の暗号ハッシュとすることができる。たとえば、クライアントデバイス400は、暗号ハッシュ関数を使用して各公開鍵の暗号ハッシュを生成し、次いで、ブラインド署名方式を使用して公開鍵の暗号ハッシュをブラインドすることができる。いくつかの実装形態では、暗号ハッシュアルゴリズムは、SHA256とすることができる。

【0082】

いくつかの実装形態では、クライアントデバイス400は、暗号ハッシュを切り捨てることによって、ブラインド公開鍵データのデータサイズをさらに低減し、次いで切り捨て後の暗号ハッシュをブラインドすることができる。たとえば、この切捨ては、暗号ハッシュを、より大きいデータサイズを有する元の暗号ハッシュから16バイトに制限することができる。この切捨ては、クライアントデバイス400がブラインド署名方式を使用してブラインドする、より短い暗号ハッシュをもたらす。

【0083】

このようにしてブラインド署名されるデータの量を低減することは、データをブラインド署名する際に、デバイス完全性コンピューティングシステム420にかかる負担を低減し(たとえば、CPUサイクル、データ記憶要件、メモリ消費などを低減し)、これにより、デバイス完全性コンピューティングシステム420は、完全な公開鍵のブラインドバージョンが提供された場合よりも、ブラインド署名を、より速く、より効率的に生成し、より多くの要求を処理することができる。これはまた、要求が送信されるネットワークの帯域幅消費を低減し、大量のブラインド公開鍵データが単一の要求で送信されることを可能にする。

【0084】

クライアントデバイス400は、N個のデバイス完全性トークンに対する要求412をデバイス完全性コンピューティングシステム420に送信する(404)。数Nは、2以上の整数とすることができる。要求は、クライアントデバイス400によって生成された公開鍵411ごとにブラインド公開鍵データを含むことができる。たとえば、要求は、N個のブラインド公開鍵、N個の公開鍵のブラインド暗号ハッシュ、またはN個の公開鍵のブラインドされた切り捨て後の暗号ハッシュを含むことができる。要求はまた、たとえば、クライアントデバイス400の信用できるプログラムによって収集されるデバイスレベル不正検出信号も含むことができる。

【0085】

デバイス完全性コンピューティングシステム420は、要求を受信する(422)。デバイス完全性コンピューティングシステム420は、デバイスレベル不正検出信号に基づいて、クライアントデバイス400の信頼性の評決を判定し得る(423)。たとえば、デバイス完全性コンピューティングシステム400は、(動作421で公開されたM個のブラインド署名検証鍵に対応する)信頼性のM個の可能な評決を有することができる。デバイス完全性コンピューティングシステム420は、デバイスレベル不正検出信号に基づいて、M個の可能な評決のうちの1つにクライアントデバイス400を割り当てることができる。

【0086】

クライアントデバイス400の信頼性の評決を判定すると、デバイス完全性コンピューティングシステム400は、ブラインド署名秘密鍵を使用して、ブラインド公開鍵データの各部分(たとえば、各N個のブラインド公開鍵または各ブラインド暗号ハッシュ)に署名する(424)。たとえば、デバイス完全性コンピューティングシステム420は、クライアントデバイス400に対して判定された信頼性の評決に対応するブラインド署名秘密鍵、たとえば、判定された信頼性の評決に対する公開ブラインド署名検証鍵に対応するブラインド署名秘密鍵を取得することができる(424)。このようにブラインド署名方式を使用して、デバイス完全性コンピューティングシステム420は、公開鍵データの実際の値を知ることなく、ブラインド公開鍵データのデジタル署名を生成することができる。

【0087】

デバイス完全性コンピューティングシステム420は、N個のブラインド署名413をクライアントデバイスに返す(425)。クライアントデバイス400は、デバイス完全性コンピューティングシステムからブラインド署名を受信する(405)。

【0088】

クライアントデバイス400は、ブラインド署名方式を使用してブラインド署名をアンブラインドする(406)。たとえば、クライアントデバイス400の信用できるプログラムは、ブラインド署名が生成されたブラインド公開鍵データと、デバイス完全性コンピューティングシステム420によって公開されたブラインド署名検証鍵とを使用して、各ブラインド署名の妥当性検査を行うことができる。これを行うために、信用できるプログラムは、たとえば、信頼性の評決ごとなど、複数のブラインド署名検証鍵を使用して、ブラインド署名の妥当性検査を行うことを試みることができる。評決がクライアントデバイス400に割り当てられた評決と一致しない場合、ブラインド署名は、その評決が理由でブラインド署名検証鍵を使用も妥当性検査に合格しない。信用できるプログラムは、ブラインド署名を妥当性検査して合格としたブラインド署名検証鍵に基づいて、クライアントデバイス400の信頼性の割り当てられた評決を判定することができ、たとえば、ブラインド検証鍵に対応する信頼性の評決は、クライアントデバイス400に割り当てられた評決である。妥当性検査に合格とした場合、信用できるプログラムは、ブラインド署名方式を使用してブラインド署名をアンブラインドすることができる。

【0089】

クライアントデバイス400は、デバイス完全性トークンのバッチを生成する(408)。たとえば、クライアントデバイス400の信用できるプログラムは、上記の動作402で生成された公開鍵ごとにデバイス完全性トークンを生成することができる。各デバイス完全性トークンは、たとえば、(1)デバイス完全性トークンが生成されているクライアントデバイスの公開鍵、(2)デバイス完全性コンピューティングシステムによって判定される信頼性の評決、および(3)ブラインド公開鍵のアンブラインドされたブラインド署名または公開鍵の暗号ハッシュ(たとえば、切り捨て後の)を含むことができる。いくつかのアプローチでは、デバイス完全性トークンは、アンブラインドされたブラインド署名から暗示され得るので、信頼性の評決を省略することができる。ブラインド署名が公的に検証可能でない場合、ブラインド署名を検証する(たとえば、以下で説明する図5の541を参照)ためにデバイス完全性コンピューティングシステムが呼び出されると、デバイス完全性コンピューティングシステムは、評決を返すこともできる。ブラインド署名が公的に検証可能である場合、ブラインド署名を検証する公開鍵は、デバイスの信頼性の評決も暗示する。

【0090】

クライアントデバイス400は、デバイス完全性トークンを記憶する(410)。たとえば、クライアントデバイス400の信用できるプログラムは、デバイス完全性トークンを含むべき要求を送信するときに後で使用するために、デバイス完全性トークンをセキュアストレージに記憶することができる。セキュアストレージは、クライアントデバイス400のトークンキャッシュとすることができる。

【0091】

図4の例に示されるように、デバイス完全性トークンのバッチを生成し、記憶すると、クライアントデバイスは、デバイス完全性トークンを使用して、上記で説明したように、デジタルコンポーネントプロバイダまたは他の証明トークン受信側に対して行われる様々な要求の一部として証明トークンをアセンブルし、送信することができる。そのような要求の例示的な例が、図5にプロセスフロー図として示されている。

【0092】

要求を準備するために、クライアントデバイス500は、たとえば、クライアントデバイスのトークンキャッシュから、デバイス完全性トークンを取り出すことができる(501)。様々なアプローチでは、クライアントは、たとえば、(1)要求ごとに新しいデバイス完全性トークンを使用することができる、または(2)選択された時間間隔(たとえば、H連続時間)にわたって同じデバイス完全性トークンを使用することができる、または(3)同じアプリケーションまたはウェブサイトから発せられたすべての要求について同じデバイス完全性トークンを使用することができる、または(4)これらのトークン再使用アプローチの組合せを使用することができる(たとえば、選択された時間間隔内に同じアプリケーションまたはウェブサイトから発せられたすべての要求について同じデバイス完全性トークンを使用する)。したがって、クライアントデバイス500は、要求が生成されるアプリケーションまたはウェブサイト、あるいは要求が生成される現在時間に基づいて、デバイス完全性トークンを取り出すことができる。

【0093】

クライアントデバイス500は、(上記のように)要求ペイロードと、要求が生成される時間を示す要求作成タイムスタンプと、デバイス完全性トークンと、デバイス完全性トークンに対応するデバイス公開鍵(たとえば、公開鍵データがブラインド署名され、アンブラインドのブラインド署名とともにデバイス完全性トークンに含まれる公開鍵)とを含むコンテンツのセットを含む要求511をアセンブルすることができる。要求はまた、クライアントデバイスの秘密鍵(たとえば、要求に含まれる公開鍵に対応する秘密鍵)を使用して署名された(502)コンテンツのセットのデジタル署名も含むことができる。たとえば、クライアントデバイス500の信用できるプログラムは、秘密鍵を使用して、コンテンツのセットに基づいてデジタル署名を生成することができる。要求は、証明トークンを含むことができ、または証明トークンの形態とすることができる。たとえば、証明トークンは、コンテンツのセット(たとえば、証明トークン作成タイムスタンプを有する)およびデジタル署名を含むことができる。

【0094】

クライアントデバイス500は、要求511を受信側のコンピューティングシステム520に送信する(503)。受信側がデジタルコンポーネントプロバイダである場合、クライアントデバイス500は、要求をデジタルコンポーネント配信システムに送信することができ、デジタルコンポーネント配信システムは、次に、要求を適切なデジタルコンポーネントプロバイダに転送する。

【0095】

受信側コンピューティングシステム520は、要求の妥当性検査を行う(522)。受信側コンピューティングシステム520は、要求に含まれるデバイス公開鍵を使用して、要求のデジタル署名を検証することによって、要求の妥当性検査を行うことができる。受信側コンピューティングシステム520はまた、要求内のタイムスタンプを、要求が受信された時間と比較することによって、その要求の妥当性検査を行うこともできる。署名が妥当性検査に合格し、タイムスタンプが現在時間のしきい値持続時間内である場合、クライアントデバイス500は、要求が妥当性検査に合格したと見なすことができる。

【0096】

受信側コンピューティングシステム520はまた、デバイス完全性トークンの妥当性検査を行う。この妥当性検査プロセスは、ブラインド署名を生成するときにデバイス完全性コンピューティングシステム540によって使用されるブラインド署名スキームに基づいて異なり得る。ブラインド署名方式が公的に検証可能な方式(たとえば、RSA)である場合、受信側コンピューティングシステム520は、デバイス完全性コンピューティングシステムを呼び出すことなく、デバイス完全性トークンの妥当性検査を行うことができる(523a)。この例では、受信側コンピューティングシステム520は、ブラインド署名方式を使用して、デバイス完全性トークンに含まれる公開鍵データのアンブラインドのブラインド署名を検証することができる。公開鍵の暗号ハッシュが使用される場合、受信側コンピューティングシステム520は、クライアントデバイス500と同じ暗号ハッシュ関数を使用して、要求に含まれる公開鍵の暗号ハッシュを生成し(適切であれば、それを切り捨て)、ブラインド署名方式を使用して、暗号ハッシュのアンブラインドのブラインド署名を検証することができる。

【0097】

ブラインド署名方式がプライベート検証可能方式(たとえば、IETF VOPRF)である場合、受信側コンピューティングシステム520は、デバイス完全性コンピューティングシステム540を呼び出して、アンブラインドのブラインド署名を検証することができる(523b)。この例では、受信側コンピューティングシステム520は、アンブラインドのブラインド署名および公開鍵または公開鍵の暗号ハッシュをデバイス完全性コンピューティングシステム540に送信することができる。

【0098】

デバイス完全性コンピューティングシステム540は、ブラインド署名方式を使用して、アンブラインドのブラインド署名を検証しようと試み、デジタルコンポーネントプロバイダに応答を提供することができる(541)。応答は、検証が成功したかどうか、およびアンブラインドのブラインド署名を検証するブラインド署名検証鍵に対応するクライアントデバイスの信頼性を示すことができる。

【0099】

受信側コンピューティングシステム520は、デバイス完全性トークンの適時性およびクライアントデバイスの信頼性の妥当性検査を行って(524)、たとえば、デバイス完全性トークンが最近作成されたことを確認し、デバイス完全性トークン内の信頼性評決が要求に従うのに十分な評決であることを確認する。デバイス完全性コンピューティングシステム540は、新しいブラインド署名検証鍵を定期的に再公開することができるので、適時性の妥当性検査は、デバイス完全性トークンのブラインド署名が無効な古い鍵で署名されていないことを、たとえば、デバイス完全性トークンが期限切れのブラインド署名検証鍵で検証されたと判定することによって確認することを含むことができる。1つのアプローチでは、受信側コンピューティングシステムは、ブラインド署名検証鍵の有効日が、公開された鍵のURLの一部として符号化されたので、ブラインド署名検証鍵が期限切れであると判定することができる。別のアプローチでは、受信側コンピューティングシステムは、検証鍵が、検証鍵の有効期限を符号化するメタデータとともに公開されているので、ブラインド署名検証鍵が期限切れであると判定することができる。

【0100】

これらの妥当性検査のすべてが合格である場合、受信側コンピューティングシステム520は、要求に応答して(525)、たとえば、上記で説明したように、設定を変更し、ユーザデータを追加または削除し、デジタルコンポーネントを配信することなどができる。したがって、デジタルコンポーネントを配信することを含む要求の場合、応答525は、随意に、適切なデジタルコンポーネント512をクライアントデバイス500に送信することを含むことができる。この例では、クライアントデバイス500は、デジタルコンポーネントを提示することができる。妥当性検査のいずれかが不合格である場合、受信側コンピューティングシステム520は、要求を無視することができ、たとえば、要求に対する応答を送信しないこと、設定を更新することなどを選択することができる。

【0101】

図2～図5の例に示され、上記で説明したアプローチは、クライアントデバイスのデバイス公開鍵を使用することを含むが、他のアプローチは、グループ署名方式のためにデバイス公開鍵の使用を控えることがある。一般的に言えば、グループ署名方式は、グループのメンバーが、グループに代わってメッセージに匿名署名することを可能にする方法である。グループ署名方式では、グループマネージャは、証明書Cでメッセージに署名するために使用することができるグループ署名機能sign(message,C)を公開し、証明書Cは、グループマネージャによってグループのメンバーにプライベートに発行された秘密証明書(匿名秘密鍵としても知られる)である。グループマネージャはまた、グループ検証鍵K(グループ公開鍵としても知られる)およびグループ署名検証関数verify(sign(message,C),K)を公開し、これは、メッセージが匿名証明書Cを使用してグループ署名関数で署名され、KがCのグループ検証鍵である場合にのみ、TRUEを返す。

【0102】

これらの技法は、デバイス完全性システムをグループマネージャとして、クライアントデバイス要求の証明のために、グループ署名方式を使用することができる。一部のグループ署名方式は、グループマネージャが、グループのメンバーによって作成された匿名署名を匿名解除することを可能にするが、プライバシの考慮では、直接匿名証明(DAA)など、この匿名解除機能を含まないグループ署名方式が好ましい場合がある。たとえば、いくつかのアプローチでは、デバイス完全性システムは、Barreto-Naehrig曲線を用いたECC DAAなどの楕円曲線暗号(ECC)DAA方式を使用することができる。さらに、いくつかのグループ署名方式は、グループマネージャがグループメンバーシップを取り消すことを可能にし得るが、効率を考慮すると、この取り消し機能を含まないグループ署名方式が好ましい場合があり、その結果、技法は、たとえば数百万または数十億のグループメンバーを含むグループを有するインターネット規模に拡張可能である。

【0103】

クライアントデバイス要求の証明のためのグループ署名方式の例示的な例が、図6および図7のプロセスフロー図に示されている。この例では、デバイス完全性コンピューティングシステム620は、クライアントデバイスについてM個の異なる信頼性レベルを定義し、対応するM個の信頼性レベルに対してM個の異なるグループ検証鍵を公開することができる。たとえば、デバイス完全性システムは、1つ、2つ、またはそれを超えるグループ検証鍵、たとえば、デバイス信頼性のレベルに対応するECC DAA検証鍵を公開することができる。M=1であるアプローチの場合、グループ検証鍵は、ある最低レベルの信頼性に対応し、その最低レベルの信頼性を満たさないデバイスは、信頼性グループのメンバーとして参加しない。M≧2であるアプローチの場合、異なるグループ検証鍵は、デバイス信頼性のそれぞれのレベルまたは分類に対応する。いくつかのアプローチでは、デバイス完全性コンピューティングシステムは、新しいグループ検証鍵を定期的に公開することができ(たとえば、毎時、毎日、毎週、または必要に応じて他の時間期間)、グループ検証鍵のセットのこのリフレッシュは、以下でさらに説明するように、クライアントデバイス要求の適時性の妥当性検査を行うために使用することができる。

【0104】

ここで図6を参照すると、クライアントデバイス600は、デバイス完全性サーバ620によって管理されるM個の信頼性グループのうちの1つについて、秘密証明書の形態のプライベートデバイス完全性証明書を要求することができる(601)。要求は、たとえば、クライアントデバイス600の信用できるプログラムによって収集されるデバイスレベル不正検出信号を含むことができる。

【0105】

デバイス完全性コンピューティングシステムは、要求を受信する(621)。デバイス完全性コンピューティングシステム620は、デバイスレベル不正検出信号に基づいてクライアントデバイスの信頼性の評決を判定し、信頼性の評決に対応する選択された信頼性グループにクライアントデバイスを割り当てることができる(622)。

【0106】

次いで、デバイス完全性コンピューティングシステム620は、選択された信頼性グループに対応する匿名証明書611を生成または選択し、匿名証明書611をクライアントデバイスに返すことができる(623)。たとえば、デバイス完全性コンピューティングシステムは、デバイス完全性コンピューティングシステムによってデバイスに割り当てられたデバイス信頼性レベルに関連付けられたECC DAA検証鍵に対応する信用証明書を生成することができる。クライアントデバイス600は、匿名証明書611を受信し、それをクライアントデバイス600でローカルに、たとえば、プライベートキーストアに安全に記憶することができる(602)。たとえば、クライアントデバイスは、プライベートキーストアのマスターキーを使用して証明書を暗号化することができ、その結果、悪意のある当事者が証明書を悪用したり、それを異なるデバイス上で使用したりすることができないようになる。

【0107】

特定の信頼性グループにおけるメンバーシップの匿名証明書を取得すると、クライアントデバイスは、この匿名証明書を使用して、デジタルコンポーネントプロバイダまたは他の証明トークン受信側から行われる様々な要求の一部として証明トークンをアセンブルし、送信することができる。この例では、証明トークンは、クライアントデバイスの公開鍵を含まないので、匿名証明トークンと呼ぶことができる。そのような要求の例示的な例が、図7にプロセスフロー図として示されている。

【0108】

クライアントデバイス700は、デジタルコンポーネントプロバイダまたは他の証明トークン受信側から行われる要求を開始することができる(701)。いくつかの実装形態では、クライアントデバイスは、以下でさらに説明するように、要求が証明トークン制限を超えないことを随意に確認することができる(702)。クライアントデバイス700は、上記および図6に記載されたように、デバイス完全性コンピューティングシステムから証明書を前もって取得した、たとえば、クライアントデバイス上のプライベートキーストアから匿名証明書を取り出す(703)。

【0109】

クライアントデバイス700は、要求711を生成し、取り出された匿名証明書でその要求に署名する(704)。要求の生成は、たとえば、要求ペイロードおよび要求作成タイムスタンプを含むコンテンツのセットを生成することを含むことができる。要求ペイロードは、たとえば、デジタルコンポーネントを選択するために使用することができるデータ、またはデータの除去など、証明トークン受信側によって行われるべき要求された変更を指定するデータを含むことができる。要求作成タイムスタンプは、要求が作成された時間を示すことができる。いくつかの例では、要求作成タイムスタンプは、重複した要求またはリプレイ攻撃を検出するのに十分小さい時間分解能を有する。たとえば、要求作成タイムスタンプは、約1ミリ秒未満または約1マイクロ秒未満の時間分解能を有することができる。グループ署名方式が確率的グループ署名方式であるアプローチでは、クライアントデバイス700による同じ要求711の2つの別々の署名が、異なる署名を生成する。これらのアプローチでは、要求711の受信側は、同一の署名を有する要求を拒否することによって、重複した要求またはリプレイ攻撃を防止することができる。

【0110】

上記ならびに図3および図5に記載された他のアプローチに反して、要求711は、クライアントデバイスの公開鍵を含まず、デバイス完全性トークンも含まない(図3の要求311および図5の要求511と比較されたい)。前に説明したアプローチのこれらの証明トークンの特徴は、クライアントデバイスによる匿名証明書Cの所有および使用が、クライアントデバイスがデバイス完全性コンピューティングシステムによって管理される信頼性グループのメンバーであることを示す、本アプローチのグループ署名方式では不要である。クライアントデバイスは、公開されたグループ署名関数sign(message,C)を使用して匿名証明書Cを使用して要求711に署名する。たとえば、クライアントデバイス700は、匿名証明書Cを使用してコンテンツのセットのデジタル署名を生成することができ、たとえば、クライアントデバイスは、デバイス完全性サーバによってクライアントデバイスに以前に提供されたECC DAA証明書によるECC DAA署名方式を使用して要求に署名することができる。

【0111】

クライアントデバイスは、要求711を受信側のコンピューティングシステム720に送信する(705)。受信側がデジタルコンポーネントプロバイダである場合、クライアントデバイス700は、要求をデジタルコンポーネント配信システムに送信することができ、デジタルコンポーネント配信システムは、次に、要求を適切なデジタルコンポーネントプロバイダに転送する。

【0112】

受信側コンピューティングシステム720は、要求を受信する(722)。クライアントデバイス700から要求711を受信する前に、受信側コンピューティングシステム720は、デバイス完全性コンピューティングシステムのM個の信頼性クラスのためのM個の異なるグループ検証鍵のセットを受信する(721)。デバイス完全性コンピューティングシステム740は、これらのM個のグループ検証鍵を公開し(741)、新しいグループ検証鍵を定期的に再公開することができ(たとえば、毎時、毎日、毎週、または必要に応じて他の時間期間)、その場合、証明トークン受信側は、クライアントデバイスからの要求の妥当性検査を行うための新しいグループ検証鍵を定期的に受信する。1つのアプローチでは、任意の受信側コンピューティングシステム720が標準HTTP要求を使用してグループ検証鍵をフェッチすることができるように、よく知られているURLを使用して、グループ検証鍵がよく知られているパス上で公開される。パスは、日付/時間情報を符号化することができ、またはグループ検証鍵に付随するメタデータは、鍵有効期限を符号化することができ、その結果、受信側コンピューティングシステムは、以下でさらに説明するように、鍵が現在のものであるかどうかを判定することができる。

【0113】

受信側コンピューティングシステム720は、要求の適時性の妥当性検査を行う(723)。たとえば、受信側は、とりわけ、要求が複製(または再生の試行)ではなく、要求が古くないこと(たとえば、要求作成タイムスタンプと、受信側コンピューティングシステムがしきい値内に要求を受信した時間との差)を確認するために、要求作成タイムスタンプを検討することができる。

【0114】

受信側コンピューティングシステム720は、要求の匿名署名および信頼性の妥当性検査を行う(724)。たとえば、受信側は、M個の公開されたグループ検証鍵のセット内の公開されたグループ検証鍵Kごとに、検証関数verify(sign(message,C),K)を評価することによって、匿名署名の妥当性検査を行うことができる。検証関数は、たとえば、デバイス完全性サーバによって以前に公開されたECC DAA検証鍵を使用して計算されるECC DAA署名検証関数とすることができる。すべての公開されたグループ検証鍵Kについて関数がFALSEである場合、受信側は、要求が改ざんされたか、またはクライアントデバイス700がいずれの信頼性グループにも属さないと判定することができる。一方、特定のグループ検証鍵Kについて関数が真である場合、クライアントデバイス700は、その特定のグループ検証鍵Kに対応する信頼性グループに属する。

【0115】

これらの妥当性検査が合格である場合、証明トークン受信側は、要求に応答して(725)、たとえば、上記で説明したように、設定を変更し、ユーザデータを追加または削除し、デジタルコンポーネントを配信することができる。次いで、デジタルコンポーネントを配信することを含む要求の場合、応答725は、随意に、適切なデジタルコンポーネント712をクライアントデバイス700に送信することを含むことができる。クライアントデバイス700は、デジタルコンポーネントを受信する(706)。次に、クライアントデバイス700は、デジタルコンポーネントをクライアントデバイス700のユーザに提示することができる。

【0116】

図6および図7に示され、上記で説明したグループ署名アプローチは、クライアントデバイスのデバイス公開鍵に基づく追跡を防止することによってクライアントデバイスまたはユーザのプライバシを向上させるが、証明トークン受信側(デジタルコンポーネントプロバイダなど)が、不当な量の要求を証明トークン受信側に送信する可能性がある不正なデバイスまたはアプリケーションを識別することを防止することもできる。したがって、いくつかのアプローチでは、クライアントデバイスは、クライアントデバイスが過剰な量の証明トークンを送信することを抑制することができる信用できるスロットラを含み得る。再び図7を参照すると、スロットラは、たとえば、開始された要求が認証トークン制限を超えないことを検証する動作702を、要求を進行させる前に実行し得る。スロットラは、たとえば、クライアントデバイスの信用できるオペレーティングシステムのスレッド、プロセス、サブルーチン、または他のコンポーネントとすることができる。スロットラは、図6～図8のグループ署名アプローチの文脈で以下に説明されるが、本明細書で説明する証明トークンコンテキストのいずれかにおいて、スロットラを使用して証明トークンの量を制限することができることを企図している。たとえば、スロットラは、図3の要求311、または図5の要求511を制限するために使用され得る。

【0117】

このスロットリングアプローチの例示的な例が、図8のプロセスフロー図に示されている。デジタルコンポーネントプロバイダおよび証明トークンを含む要求または他の通信の他の受信側など、様々な証明トークン受信側850は、証明トークン量制限を示す情報を公開することができる(851)。たとえば、証明トークン受信側は、(1)(たとえば、Y秒、分、または時間内のX個以下の要求など)選択された時間フレーム内に、各個々のクライアントデバイスから受信側の選択された宛先ドメインに送信することができるトークンの数の制限、(2)(たとえば、Y秒、分、または時間以内の、アプリケーションAからの、またはアプリケーションA以外の任意のアプリケーションからのX個以下の要求など)選択された時間フレーム内に、個々のクライアントデバイス上の1つまたは複数の選択されたアプリケーションから受信側の選択された宛先ドメインに送信することができるトークンの数の制限、(3)選択された時間フレーム内に受信側の選択された宛先ドメイン内の選択されたエンドポイントに個々のクライアントデバイスから送信することができるトークンの数の制限、(4)選択された時間フレーム内に、クライアントデバイス上の1つまたは複数の選択されたアプリケーションから、選択された宛先ドメイン内の選択されたエンドポイントに送信することができるトークンの数の制限、または(5)そのような制限のうちの2つ以上の任意の組合せを公開することができる。

【0118】

スロットラ830は、クライアントデバイス800の信用できるプログラム820(たとえば、オペレーティングシステム)の構成要素として、公開されたトークン量制限情報を受信する(821)。公開されたトークン量制限情報を、様々な方法で受信することができる。1つのアプローチでは、各証明トークン受信側は、トークン受信側の秘密鍵で署名されたファイルでトークン量情報を公開する。トラステッドクローラは、(トークン受信側のための公開鍵とともに)これらのファイルを定期的にフェッチし、これらのファイルを各クライアントデバイス800に配信する。次いで、各クライアントデバイス上のスロットラ830は、トークン受信側の署名を検証した後、スロットリング要件に従う。たとえば、スロットラ830は、制限を超える要求のための証明トークンを生成しないことによって、制限を超えないことを確実にすることができる。

【0119】

別のアプローチでは、各トークン受信側は、署名されたトークン量情報をデジタル配信プラットフォーム(モバイルアプリをダウンロードすることができるモバイルアプリストアなど)にサブミットする。デジタル配信プラットフォームは、トークン量情報を検証し、署名する。次いで、各トークン受信側は、2回署名されたトークン量情報をクライアントデバイス800に配信する。次いで、各クライアントデバイス上のスロットラ830は、トークン受信側とデジタル配信プラットフォームの両方の署名を検証した後、スロットリング要件に従う。たとえば、スロットラ830は、制限を超える要求のための証明トークンを生成しないことによって、制限を超えないことを確実にすることができる。

【0120】

クライアントデバイス上のアプリケーション810が、証明トークンについての信用できるプログラム820に対する要求を開始すると(811)、信用できるプログラム820は、この要求を受信する(822)。次いで、信用できるプログラム820は、スロットラを呼び出して、要求に従うことにより、クライアントデバイスが公開されたトークン量制限の1つまたは複数を超えることになるかどうかを評価することができる(823)。要求が公開されたトークン量制限の1つまたは複数を超える場合、信用できるプログラム820は、証明トークン要求を拒否する(ステップ823a)。要求が公開されたトークン量制限を超えない場合、信用できるオペレーティングシステム820は、証明トークンを生成し、適切な証明トークン受信側に送信することを可能にする(ステップ823b)。

【0121】

上記の説明に加えて、ユーザには、本明細書で説明されるシステム、プログラム、または特徴がユーザ情報(たとえば、ユーザのソーシャルネットワーク、ソーシャルアクションもしくはアクティビティ、職業、ユーザの選好、またはユーザの現在のロケーションについての情報)の収集を可能にし得るかどうかおよびいつそれを可能にし得るかと、サーバからのパーソナライズされたコンテンツまたは通信がユーザに送信されるかどうかの両方に関しての選択をユーザが行うことを可能にする制御が与えられ得る。加えて、いくつかのデータは、個人が識別できる情報が除去されるように、記憶または使用される前に1つまたは複数のやり方で処置されてよい。たとえば、ユーザの識別情報は、個人を識別できる情報(たとえば、電話番号、IMEI、デバイスシリアル番号)がユーザについて特定できないように扱われ得る、またはユーザの地理的位置は、ユーザの具体的な位置が特定できないように、位置情報が取得される場合に(都市、ZIPコード、もしくは州のレベルなどに)一般化され得る。したがって、ユーザは、ユーザについてのどの情報が収集されるか、その情報がどのように使用されるか、情報の保持方針、およびどの情報がユーザに提供されるかを制御することができる。

【0122】

図9は、上述の動作を実行するために使用することができる例示的なコンピュータシステム900のブロック図である。システム900は、プロセッサ910、メモリ920、記憶デバイス930、および入力/出力デバイス940を含む。コンポーネント910、920、930、および940の各々は、たとえば、システムバス950を使用して相互接続することができる。プロセッサ910は、システム900内で実行するための命令を処理することが可能である。いくつかの実装形態では、プロセッサ910は、シングルスレッドプロセッサである。別の実装形態では、プロセッサ910はマルチスレッドプロセッサである。プロセッサ910は、メモリ920または記憶デバイス930に記憶された命令を処理することが可能である。

【0123】

メモリ920は、システム900内に情報を記憶する。一実装形態では、メモリ920は、コンピュータ可読媒体である。いくつかの実装形態では、メモリ920は、揮発性メモリユニットである。別の実装形態では、メモリ920は不揮発性メモリユニットである。

【0124】

記憶デバイス930は、システム900のための大容量ストレージを提供することが可能である。いくつかの実装形態では、記憶デバイス930は、コンピュータ可読媒体である。様々な異なる実装形態では、記憶デバイス930は、たとえば、ハードディスクデバイス、光ディスクデバイス、複数のコンピューティングデバイスによってネットワーク上で共有される記憶デバイス(たとえば、クラウド記憶デバイス)、または他の何らかの大容量記憶デバイスを含むことができる。

【0125】

入出力デバイス940は、システム900のための入出力動作を提供する。いくつかの実装形態では、入出力デバイス940は、ネットワークインターフェースデバイス、たとえば、Ethernetカード、シリアル通信デバイス、たとえば、RS-232ポート、および/またはワイヤレスインターフェースデバイス、たとえば、802.11カードのうちの1つまたは複数を含み得る。別の実装形態では、入出力デバイスは、入力データを受信し、出力データを外部デバイス960、たとえば、キーボード、プリンタ、およびディスプレイデバイスに送るように構成された、ドライバデバイスを含み得る。しかしながら、モバイルコンピューティングデバイス、モバイル通信デバイス、セットトップボックステレビクライアントデバイスなど、他の実装形態が使用されてもよい。

【0126】

図9には例示的な処理システムが記載されているが、本明細書に記載される主題および機能的動作の実装は、他のタイプのデジタル電子回路、または本明細書に開示された構造およびそれらの構造的均等物を含むコンピュータソフトウェア、ファームウェア、もしくはハードウェア、またはそれらの1つもしくは複数の組合せに実装することができる。

【0127】

本明細書で説明される主題および動作の実施形態は、デジタル電子回路において、または本明細書で開示される構造およびその構造的等価物を含むコンピュータソフトウェア、ファームウェア、もしくはハードウェアにおいて、またはそれらのうちの1つもしくは複数の組合せにおいて実装され得る。本明細書で説明される主題の実施形態は、1つまたは複数のコンピュータプログラム、すなわち、データ処理装置による実行のためにまたはデータ処理装置の動作を制御するために(1つまたは複数の)コンピュータ記憶媒体上で符号化された、コンピュータプログラム命令の1つまたは複数のモジュールとして実装され得る。代替または追加として、プログラム命令は、データ処理装置による実行のために、適切な受信機装置への伝送のために情報を符号化するために生成された、人工的に生成された伝搬信号、たとえば、機械で生成された電気信号、光信号、または電磁信号上で符号化され得る。コンピュータ記憶媒体は、コンピュータ可読記憶デバイス、コンピュータ可読記憶基板、ランダムもしくはシリアルアクセスメモリアレイもしくはデバイス、またはそれらのうちの1つもしくは複数の組合せであり得るか、またはそれらに含まれ得る。さらに、コンピュータ記憶媒体は伝搬信号ではないが、コンピュータ記憶媒体は、人工的に生成された伝搬信号において符号化されたコンピュータプログラム命令のソースまたは宛先であり得る。コンピュータ記憶媒体はまた、1つまたは複数の別個の物理構成要素または媒体(たとえば、複数のCD、ディスク、または他の記憶デバイス)であり得るか、またはそれらに含まれ得る。

【0128】

本明細書で説明される動作は、1つもしくは複数のコンピュータ可読記憶デバイス上に記憶されたまたは他のソースから受信されたデータに対してデータ処理装置によって実施される動作として実装され得る。

【0129】

「データ処理装置」という用語は、例として、プログラマブルプロセッサ、コンピュータ、システムオンチップ、もしくは上記の複数のもの、または上記の組合せを含む、データを処理するためのすべての種類の装置、デバイス、および機械を包含する。装置は、専用論理回路、たとえば、FPGA(フィールドプログラマブルゲートアレイ)またはASIC(特定用途向け集積回路)を含むことができる。装置は、ハードウェアに加えて、当該のコンピュータプログラムのための実行環境を作成するコード、たとえば、プロセッサファームウェア、プロトコルスタック、データベース管理システム、オペレーティングシステム、クロスプラットフォームランタイム環境、仮想マシン、またはそれらのうちの1つもしくは複数の組合せを構成するコードも含むことができる。装置および実行環境は、ウェブサービス、分散コンピューティングインフラストラクチャおよびグリッドコンピューティングインフラストラクチャなどの様々な異なるコンピューティングモデルインフラストラクチャを実現することができる。

【0130】

コンピュータプログラム(プログラム、ソフトウェア、ソフトウェアアプリケーション、スクリプト、またはコードとしても知られている)は、コンパイル型言語またはインタプリタ型言語、宣言型言語または手続き型言語を含む任意の形態のプログラミング言語で書かれ得、スタンドアロンプログラムとして、またはモジュール、構成要素、サブルーチン、オブジェクト、もしくはコンピューティング環境において使用するのに適した他のユニットとしてを含む任意の形態で展開され得る。コンピュータプログラムは、ファイルシステムにおけるファイルに対応し得るが、そうでなくてもよい。プログラムは、他のプログラムもしくはデータ(たとえば、マークアップ言語文書に記憶された1つもしくは複数のスクリプト)を保持するファイルの一部分に、当該のプログラム専用の単一のファイルに、または複数の協調ファイル(たとえば、1つもしくは複数のモジュール、サブプログラム、またはコードの部分を記憶するファイル)に記憶され得る。コンピュータプログラムは、1つのコンピュータ上で、または、1つのサイトに配置されるかもしくは複数のサイトにわたって分散され、通信ネットワークによって相互接続される複数のコンピュータ上で実行されるように展開され得る。

【0131】

本明細書で説明したプロセスおよび論理フローは、入力データ上で動作し、出力を生成することによってアクションを行うために、1つまたは複数のコンピュータプログラムを実行する1つまたは複数のプログラマブルプロセッサによって実行され得る。プロセスおよび論理フローは、専用論理回路、たとえば、FPGA(フィールドプログラマブルゲートアレイ)またはASIC(特定用途向け集積回路)によっても実施され得、装置は、それらとしても実装され得る。

【0132】

コンピュータプログラムの実行に適したプロセッサは、例として、汎用マイクロプロセッサと専用マイクロプロセッサの両方を含む。一般に、プロセッサは、読取り専用メモリもしくはランダムアクセスメモリまたはその両方から命令およびデータを受信する。コンピュータの必須要素は、命令に従ってアクションを実施するためのプロセッサ、ならびに命令およびデータを記憶するための1つまたは複数のメモリデバイスである。一般に、コンピュータは、データを記憶するための1つまたは複数の大容量記憶デバイス、たとえば、磁気ディスク、光磁気ディスク、または光ディスクも含むか、あるいは、それらからデータを受信することもしくはそれらにデータを転送することまたはその両方を行うために動作可能に結合される。しかしながら、コンピュータはそのようなデバイスを有さなくてもよい。さらに、コンピュータは、ほんの数例を挙げると、別のデバイス、たとえば、モバイル電話、携帯情報端末(PDA)、モバイルオーディオもしくはビデオプレーヤ、ゲームコンソール、全地球測位システム(GPS)受信機、またはポータブル記憶デバイス(たとえば、ユニバーサルシリアルバス(USB)フラッシュドライブ)に埋め込まれ得る。コンピュータプログラム命令およびデータを記憶するのに適したデバイスは、例として、半導体メモリデバイス、たとえば、EPROM、EEPROM、およびフラッシュメモリデバイス、磁気ディスク、たとえば、内部ハードディスクまたはリムーバブルディスク、光磁気ディスク、ならびにCD-ROMディスクおよびDVD-ROMディスクを含む、すべての形態の不揮発性メモリ、媒体およびメモリデバイスを含む。プロセッサおよびメモリは、専用論理回路によって補完され得るか、または専用論理回路に組み込まれ得る。

【0133】

ユーザとの対話を提供するために、本明細書に記載される主題の実施形態は、ユーザに情報を表示するための、CRT(陰極線管)またはLCD(液晶ディスプレイ)モニタなどのディスプレイデバイス、ならびにユーザがコンピュータに入力を提供することができる、キーボードおよび、たとえば、マウスまたはトラックボールなどのポインティングデバイスを有するコンピュータ上に実装することができる。他の種類のデバイスを使用して、ユーザとの対話を提供することもでき、たとえば、ユーザに提供されるフィードバックは、たとえば、視覚フィードバック、聴覚フィードバック、または触覚フィードバックなど、任意の形態の感覚フィードバックとすることができ、ユーザからの入力は、音響、音声、または触覚入力を含む任意の形態で受信することができる。加えて、コンピュータは、文書をユーザによって使用されるデバイスに送信し、文書をそのデバイスから受信することによって、たとえば、ユーザのクライアントデバイス上のウェブブラウザから受信された要求に応答してウェブページをそのウェブブラウザに送信することによって、ユーザと対話することができる。

【0134】

本明細書で説明される主題の実施形態は、バックエンド構成要素、たとえば、データサーバを含む、またはミドルウェア構成要素、たとえば、アプリケーションサーバを含む、またはフロントエンド構成要素、たとえば、それを通じてユーザが本明細書で説明される主題の一実装形態と対話することができるグラフィカルユーザインターフェースもしくはウェブブラウザを有するクライアントコンピュータを含む、または1つもしくは複数のそのようなバックエンド構成要素、ミドルウェア構成要素、もしくはフロントエンド構成要素の任意の組合せを含む、コンピューティングシステムにおいて実装され得る。システムの構成要素は、デジタルデータ通信の任意の形態または媒体、たとえば、通信ネットワークによって相互接続され得る。通信ネットワークの例は、ローカルエリアネットワーク(「LAN」)およびワイドエリアネットワーク(「WAN」)、インターネットワーク(たとえば、インターネット)、ならびにピアツーピアネットワーク(たとえば、アドホックピアツーピアネットワーク)を含む。

【0135】

コンピューティングシステムは、クライアントおよびサーバを含むことができる。クライアントとサーバとは、一般に、互いに遠隔であり、典型的には、通信ネットワークを介して対話する。クライアントとサーバとの関係は、それぞれのコンピュータ上で実行され、互いにクライアントサーバ関係を有するコンピュータプログラムによって生じる。いくつかの実施形態では、サーバは、(たとえば、クライアントデバイスと対話するユーザにデータを表示し、そのユーザからユーザ入力を受信する目的で)データ(たとえば、HTMLページ)をクライアントデバイスに伝送する。クライアントデバイスにおいて生成されたデータ(たとえば、ユーザ対話の結果)は、サーバにおいてクライアントデバイスから受信され得る。

【0136】

本明細書は多くの特定の実装形態の詳細を含んでいるが、これらは発明の範囲または特許請求され得るものの範囲に対する限定として解釈されるべきではなく、むしろ特定の発明の特定の実施形態に特有の特徴の説明として解釈されるべきである。別個の実施形態の文脈において本明細書で説明されるいくつかの特徴はまた、単一の実施形態において組み合わせて実装され得る。逆に、単一の実施形態の文脈において説明される様々な特徴はまた、複数の実施形態において別々にまたは任意の適切な副組合せで実装され得る。さらに、特徴はいくつかの組合せにおいて働くものとして上記で説明され、そのようなものとして最初に特許請求されることさえあるが、特許請求される組合せからの1つまたは複数の特徴は、場合によっては、その組合せから削除される場合があり、特許請求される組合せは、副組合せまたは副組合せの変形を対象とし得る。

【0137】

同様に、動作は、特定の順序で図面に示されるが、これは、望ましい結果を達成するために、そのような動作が図示された特定の順序でもしくは順番に行われること、または例示したすべての動作が行われることを必要とするものと理解されるべきではない。状況によっては、マルチタスキングおよび並列処理が有利であり得る。さらに、上記で説明した実施形態における様々なシステム構成要素の分離は、すべての実施形態においてそのような分離を必要とするものとして理解されるべきではなく、説明したプログラム構成要素およびシステムは一般に、単一のソフトウェア製品に一緒に組み込まれるか、または複数のソフトウェア製品にパッケージ化されることがあると理解されたい。

【0138】

このようにして、主題の特定の実施形態が説明されてきた。他の実施形態は、以下の特許請求の範囲の範囲内にある。場合によっては、特許請求の範囲に列挙されるアクションは、異なる順序で行われ、それでも望ましい結果を達成し得る。加えて、添付の図面に示したプロセスは、所望の結果を達成するために、必ずしも示した特定の順序または順番を必要としない。いくつかの実装形態では、マルチタスキングおよび並列処理が有利であり得る。

【符号の説明】

【0139】

100 環境
105 データ通信ネットワーク
110 クライアントデバイス
111 アプリケーション
112 秘密鍵
113 公開鍵
114 信用できるプログラム
115 セキュアストレージ
120 要求
122 証明トークン
129 デジタルコンポーネント
130 パブリッシャ
140 ウェブサイト
145 リソース
150 デジタルコンポーネント配信システム
152 デジタルコンポーネントパートナー
160 デジタルコンポーネントプロバイダ
170 デバイス完全性システム
200 クライアントデバイス
211 公開鍵
220 デバイス完全性コンピューティングシステム
300 クライアントデバイス
311 要求
312 デジタルコンポーネント
320 受信側コンピューティングシステム
325 応答
400 クライアントデバイス
411 ブラインド署名検証鍵
412 要求
413 ブラインド署名
420 デバイス完全性コンピューティングシステム
500 クライアントデバイス
511 要求
512 デジタルコンポーネント
520 受信側コンピューティングシステム
525 応答
540 デバイス完全性コンピューティングシステム
600 クライアントデバイス
611 匿名証明書
620 デバイス完全性コンピューティングシステム
700 クライアントデバイス
711 要求
712 デジタルコンポーネント
720 受信側コンピューティングシステム
740 デバイス完全性コンピューティングシステム
800 クライアントデバイス
810 アプリケーション
820 信用できるプログラム
830 スロットラ
850 証明トークン受信側
900 コンピュータシステム
910 プロセッサ
920 メモリ
930 記憶デバイス
940 入力/出力デバイス
950 システムバス
960 外部デバイス

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】