(57)【要約】【課題】ブロックチェーントランザクションの受け入れ前に、未知のクライアントデバイスの完全検証を提供し、ブロックチェーントランザクションに更なるセキュリティを提供するシステム及び方法を提供する。【解決手段】デバイスの健康状態は、電子トランザクションに関わる前に認証することができる。幾つかの実施形態では、完全デバイス整合性検証の自動化は、ブロックチェーントランザクションの一環として提供される。本発明の特定の態様は、デバイスを信頼できるようにする。幾つかの実施形態は、デバイスとの信頼性の高い関係が、エンドユーザとのはるかに安全、容易、且つ強力な関係に役立つことができるとの基本的前提で機能する。これを達成するには、現在のトランザクションに関わるデバイスが、前のトランザクションでのデバイスと同じデバイスであることを確実に知る必要がある。【選択図】図２Ａ
2018516026.tif 000002
【特許請求の範囲】
【請求項１】
ブロックチェーン通信ネットワーク内のユーザデバイスのデバイス整合性を検証するコンピュータ実施方法であって、
前記ブロックチェーンネットワークにおける電子トランザクションを送出する準備において、前記トランザクションの一部として、デバイス整合性検証プロセスを実施すること
を含み、前記デバイス整合性検証プロセスを実施することは、
前記ユーザデバイス内の信頼ルートから、前記デバイス実行環境の前記整合性の内部検証を実行することと、
前記署名の前記整合性の検証が前記ブロックチェーントランザクションに適用されるように、電子署名を要求することと
を含み、
前記署名の前記整合性の検証は、前記ユーザデバイスの前記実行環境が既知の良好な状況にあるか否かの判断に基づき、前記署名の整合性の検証は、
前記署名の前記整合性に基づいて、前記トランザクションの進行を許可するか、又は前記ユーザデバイスの前記実行環境が既知の良好な状況にないと判断される場合であっても、前記ユーザが意図した前記電子トランザクションが進行を許可されることを検証するように救済機関に要求すること
を含む、方法。
【請求項２】
前記署名の前記整合性の検証は、
前記ブロックチェーンネットワークの少なくとも一部が、前記電子トランザクションを受け入れるために複数の電子署名を要求することで応答するように、処理のために信頼ルートの命令を前記ブロックチェーンネットワークに送信することを含み、この信頼ルートの命令を送信することは、
前記ユーザデバイスの前記実行環境内で、前記ユーザデバイス内の信頼ルートからの命令を作成することと、
前記署名の前記整合性の検証が前記ブロックチェーントランザクションに適用されるように、前記信頼ルートの前記命令に対応する第１の電子署名を要求することと、
前記デバイスの前記実行環境が既知の良好な状況にあるか否かの判断に基づいて、前記署名の前記整合性を検証することにより、前記第１の電子署名に応答することと
を含み、
前記第１の電子署名に応答することは、
前記署名をこれまでに記録された参照値と比較することと、
前記署名がこれまでに記録された前記参照値と一致する場合、前記トランザクションの進行を許可することと、
前記署名がこれまでに記録された前記参照値と一致しない場合、前記デバイスの前記実行環境が既知の良好な状況にないと判断される場合であっても、前記ユーザが意図した前記電子トランザクションが進行を許可されることを検証するように、第三者のアウトオブバンドプロセスに要求することと
を含む、請求項１に記載の方法。
【請求項３】
前記署名の前記整合性を検証することは、
前記デバイスが、前記デバイスの前記実行環境が既知の良好な状況にあるか否かの判断に基づいて、前記電子署名を提供することと、
前記デバイスが前記電子署名を提供する場合、前記トランザクションの進行を許可することと、
前記デバイスの前記実行環境が既知の良好な状況にないと判断される場合であっても、前記救済機関が前記署名を提供する場合には、前記ユーザが意図した前記トランザクションの進行を許可することと
を含む、請求項１に記載の方法。
【請求項４】
前記アウトオブバンドプロセスは、Ｎ暗号鍵又はＭ暗号鍵の機能を使用して、前記ユーザの意図が所定の要件を満たすこと、又は前記デバイス整合性が所定の要件を満たすこと、又は追加のプロセスが所定の要件を満たすことのうちの少なくとも１つを検証することを更に含む、請求項２に記載の方法。
【請求項５】
前記参照値は、デバイスプラットフォームの所有者により実行される登録プロセス中に生成される、請求項２に記載の方法。
【請求項６】
前記参照値は、前記デバイスに割り当てられる出生証明書に基づいて生成され、前記出生証明書は、前記デバイスの製造業者もしくは作成者、前記デバイスの前記実行環境の製造業者もしくは作成者、及び／又は前記デバイスのアプリケーションの製造業者もしくは作成者により生成される、請求項２に記載の方法。
【請求項７】
前記参照値は、前記デバイスの製造業者もしくは作成者、前記デバイスの前記実行環境の製造業者もしくは作成者、及び／又は前記デバイスのアプリケーションの製造業者もしくは作成者のうちの少なくとも１つの署名を含む、請求項２に記載の方法。
【請求項８】
前記第三者のアウトオブバンドプロセスは、前記トランザクションを検証するための要求に応答してトークンを返す、請求項２に記載の方法。
【請求項９】
前記署名がこれまでに記録された前記参照値と一致しない場合、特定の時間期間以内に前記電子トランザクションが完了することを許可することを更に含む、請求項２に記載の方法。
【請求項１０】
前記デバイスの前記実行環境が既知の良好な状況にないと判断される場合であっても、前記意図された電子トランザクションが進行を許可されることを検証することは、前記参照値の登録から前記トランザクションまでの時間期間及び／又はトランザクション量に基づく、請求項２に記載の方法。
【請求項１１】
閾値量を超えるトランザクションは、前記時間期間が所定の要件を満たす場合、進行が許可される、請求項１０に記載の方法。
【請求項１２】
特定量を超える前記トランザクションを許可することは、これまでに許可された最小数のトランザクションに基づく、請求項１１に記載の方法。
【請求項１３】
デバイス整合性が最小の所定要件を満たすか否かと、更なるとるべき動作とを前記ユーザに示す表示デバイスを使用することを更に含む、請求項１に記載の方法。
【請求項１４】
前記トランザクションの第三者への通知を更に含み、前記通知に応答して、前記第三者は、前記トランザクション及び前記デバイスの状態を記録する、請求項１に記載の方法。
【請求項１５】
前記第三者は、前記トランザクションの更なる分析のために、前記デバイス整合性に関連する測定値を記録する、請求項１４に記載の方法。
【請求項１６】
前記記録が認証された第三者のみに提供されるように、前記記録を暗号で難読化することを含み、前記記録のプライバシーを確保することを更に含む、請求項１４に記載の方法。
【請求項１７】
ブロックチェーン通信ネットワーク内のユーザデバイスのデバイス整合性を検証するコンピュータ実施システムであって、
ブロックチェーン通信ネットワークと、
前記ブロックチェーンネットワーク内のユーザデバイスと、
前記ブロックチェーンネットワーク内の電子トランザクションと、
前記ブロックチェーンネットワークにおける前記電子トランザクションを送出する準備において、前記トランザクションの一部として実施されるデバイス検証プロセスと
を備え、
前記実施は、
前記デバイス内の信頼ルートからの、実行されるデバイス実行環境の前記整合性の内部検証、
前記署名の前記整合性の検証が前記ブロックチェーントランザクションに適用されるような電子署名
を更に含み、
前記署名の前記整合性の検証は、前記ユーザデバイスの前記実行環境が既知の良好な状況にあるか否かの判断に基づき、前記署名の前記整合性の検証は、
前記署名の前記整合性に基づいて、前記トランザクションの進行を許可するか、又は前記デバイスの前記実行環境が既知の良好な状況にないと判断される場合であっても、前記ユーザが意図した前記電子トランザクションが進行を許可されることを検証するように救済機関に要求すること
を含む、システム。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願
本願は、２０１５年３月２０日に出願された米国仮特許出願第６２／１３６，３４０号明細書及び２０１５年３月２０日に出願された米国仮特許出願第６２／１３６，３８５号明細書の利益を主張するものである。上記出願の教示全体は参照により本明細書に援用される。
【背景技術】
【０００２】
ビットコイン等の脱中央化トランザクションシステムの普及は、インターネットに、ブロックチェーンとして知られるデジタル価値にわたる所有権を記録する信頼性の高いセキュアプロトコルを提供した。システムは、人々がそのデジタル価値を使えるようにする秘密鍵に根差している。しかし、これらの鍵がデジタル記憶される場合、特に取引される場合、窃盗を受けやすく、大きな損失に繋がる恐れがある。業界は、何年もの間、エンドポイントデバイスでの高認証動作の必要性を予期してきた。既に展開されているハードウェアセキュリティを使用して、人々とブロックチェーンとの対話のセキュリティ及びプライバシーを強化することができる。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
数千ものピアサーバのバックに構築される共通台帳であるビットコインの背後のブロックチェーンは、数学的に貫通不可能であるように考案されている。参加ピアの大部分が、コミュニティをサポートするように振る舞う限り、過去の記録を編集し、ひいては価値を盗むのに十分な計算能力を利用することはできない。そのような大きなコミュニティが整合性を維持する場合、楕円曲線暗号の脆弱性のみがブロックチェーンを危うくすると考えられる。しかし、ブロックチェーンそれ自体はよくセキュア化されているが、個人がブロックチェーンといかに取引するかは、非常に複雑であるか、又は幾つかの周知のマルウェア攻撃を受ける。その結果、ブロックチェーンへの命令の品質は、被保護トランザクション台帳の品質保証に極めて重要になる。
【課題を解決するための手段】
【０００４】
ビットコインブロックチェーンにおいて捕捉されるトランザクションの大半は、ある人物から別の人物への価値の転送を記録する。公開鍵は、関わる当事者を表す。対応する秘密鍵により、参加者は結果を請求する。監視又は制御する他の方法がないため、秘密鍵がセキュア化されることが最重要である。ブロックチェーンは一時的構造である。人々は、ネットワーク接続されたデバイスの制御を通してのみブロックチェーンと対話することができる。概して、これが行われる３つの方法がある。Ａ）人が、それ自体がピアであり、ブロックチェーンに直接書き込むマシンを制御する。Ｂ）人がウェブサイト又はモバイルアプリを使用して、代理として機能するサーバに命令する、又はＣ）人がウェブサイト又はアプリを使用して、ローカルに形成されたトランザクションを伝搬させる。
【０００５】
一般に、秘密鍵は要求への署名に適用される。実行環境は、要求の正確性及び秘密鍵の保護を受け持つ。実行環境の健康状態及び起点の認証は、その信頼性を確立する。
【０００６】
実行環境のセキュリティを改善するために利用することができる幾つかの広く普及したツールがある。これは、ハードウェアにより後援されるデバイスの識別から完全に信頼される実行環境まで及ぶ。消費者ウェブは、デバイス識別方法ではなくユーザ識別方法で構築される最も広く分散したサービスプラットフォームである。例えば、サービスがイネーブルデバイスにより認証されるモバイル電話又はケーブルテレビとは異なり、ウェブは、エンドユーザが識別プロトコルを行うこと、すなわち、ユーザ名及びパスワードを入力することを求める。この方法の移植性に利点があるが、実際には危険なほどに影響を受けやすい。ユーザは、複雑なパスワードを覚えることが苦手であり、繰り返しの要求に苛立つ。結果として、「ＧｏＹａｎｋｓ（行けヤンキース）」のようなパスワード及び数日持続することが許されたセッションキーになる。他方、デバイスは幸いにも、デバイスのハードウェアに記憶されている数千もの機密情報のいずれへのいかなる人間の能力をもはるかに超えた暗号認証を行う。そして、デバイスは疲れずに何度も繰り返して暗号認証を行う。
【０００７】
極端な状況を除き、ユーザ名／パスワードの形態の移植性は、ある役割をつとめる。しかし、大抵、ユーザは、同じ対話で同じデバイスに携わる。ユーザが所有するデバイスを利用して、基本認証を行うことにより、この一貫性には、見返りとしてユーザの即時アクセス及びサービスプロバイダの保証増大が与えられる。
【０００８】
インターネットは、多目的デバイスにより広くアクセスされる。ＰＣ、タブレット、及び電話は、数百ものアプリケーションをホストし得、新しいアプリの活気ある市場は、非常に開かれた環境をもたらす。これは、それらのアプリの１つが悪意のある意図を隠し、デバイス上の他のアプリを破壊するか、又はデバイス上の他のアプリから盗みを開始するまでは、非常にユーザフレンドリーである。デバイスが、前のものと同じであるか否かを知ることに加えて、サービスプロバイダは、デバイスが前と同じ状態であるかと尋ねるべきである。大きな変更が行われたことが分かる場合、これは、潜在的な脅威を示し得る。この知識により、サービスプロバイダは、是正措置をとるか、又は少なくとも、マシンがなお安全であることの更なる確認をデバイス操作者から要求することができる。
【０００９】
ユーザは多くの場合、ユーザのデバイスがセキュリティ侵害を受けたか否かを知らず、ＢＩＯＳが変更されたことを検出することができる場合、サービスは警告ステップをとることができる。
【００１０】
アプリのインストール及び実行は、非常に簡単であることが意図される。しかし、アプリの出所の強力な保証及び他のアプリの実行からの不透明な分離から大きな恩恵を受けることができるクラスのアプリがある。これは、例えば、高信頼実行環境又はＴＥＥであり得る。プライマリＯＳ及びメモリスタックで実行中のアプリとは異なり、ＴＥＥで実行中のアプリは、ＯＳによるスヌーピングなしで行うことができる暗号プリミティブにアクセスすることができる。理想的な状況では、ＴＥＥで実行中のアプリは、ユーザ入力及び表示への直接アクセスも有し、デバイスの操作者とのプライベートな対話を保証する。
【００１１】
デバイスセキュリティをサポートするプロプライエタリベースの解決策及び規格ベースの解決策は両方とも、サプライチェーンに進出してきた。例えば、高信頼プラットフォームモジュールつまりＴＰＭは、近代の大半のＰＣのマザーボードに組み込まれるセキュリティチップである。この技術は、数十もの主要ベンダーの非営利連合である高信頼コンピューティンググループ（ＴＣＧ）により指定されている。これは、企業ネットワークセキュリティをサポートするように広く設計されているが、消費者ウェブの簡易化に大きな役割を有する。ＴＰＭは、６年にわたり出荷され、現在では、近代ＰＣに広く普及している。２０１５年に始まったＭｉｃｒｏｓｏｆｔのロゴコンプライアンスは、ＴＰＭなしのマシンが配達されないことを更に保証する。
【００１２】
ＴＰＭは比較的単純である。３つの基本的な目的を果たす：ＰＫＩ、ＢＩＯＳ整合性、及び暗号化。この技術は１０年をはるかに超えて遂行されてきたが、ＴＥＥのサポートを有するデバイスが利用可能になったのはここ最近である。Ｉｎｔｅｌが、２０１１年に商用解決策の送達を開始し、Ｔｒｕｓｔｏｎｉｃが２０１３年に乗り出した。プラットフォーム及び関連するツールは、消費者使用に必要な成熟度に達しつつある。ＴＥＥへのアプリの展開は、専用ハードウェアデバイスの配達と似ている。実行及びデータは、ホストのいかなる他の機能からも暗号で分離される。
【００１３】
チップは、それ自体の識別情報を有さず、鍵ペアを生成するように求められることができる。ＡＩＫ又は構成証明識別キーは、「移行不可」と記すことができ、それにより、鍵ペアのうちの秘密鍵はハードウェアの外部には決して見えない。これは、クローニングすることができないマシン識別情報を確立する機会を提供する。現在展開されているＴＰＭバージョン１．２はＲＳＡ及びＳＨＡ−１に制限されている。もうすぐ発売されるバージョン２．０は、はるかに機敏である。ＴＰＭはエンドースメントキー（ＥＫ）も実装する。ＥＫは、製造中にインストールされ、ＴＰＭが実際に本物のＴＰＭであることを証明するために使用することができる。ＴＰＭをサポートするシステムは、ブートシーケンス中、プラットフォーム構成レジスタ（ＰＣＲ）をロードする。ファームウェアから始まり、ブートプロセス中の各ステップは、その状態及び次のプロセスの状態を測定し、ＰＣＲ値を記録する。ＰＣＲはタンパー防止ＴＰＭで捕捉されるため、システムのＢＩＯＳ整合性の信頼性の高い「クォート」を続けて要求することができる。ＰＣＲは、実際に生じたことを捕捉せず、一連のハッシュを通して、何も変わらなかったことのみを捕捉する。これは、ハッカーがマシンのＢＩＯＳを危うくするか、又は秘密のハイパーバイザをインストールする、最も深刻であり、その他の方法では検出不可能な攻撃に対する保護にとって特に重要である。ウィルススキャンソフトウェアからの保証署名と組み合わせて、マシン健康状態の信頼性の高い状態を確立することができる。ＴＰＭは、バルク暗号化サービスも提供する。暗号鍵は、ＴＰＭにおいて生成されるが、ＴＰＭに記憶されない。代わりに、暗号鍵は、ＴＰＭバウンドストレージルートキーを用いて暗号化され、要求側プロセスに返される。データのブロブを暗号化又は復号化したいプロセスはまず、所望の鍵をマウントする。次に、鍵はハードウェアにおいて復号化され、暗号化に利用できるようになる。大半のＴＰＭ鍵と同様に、暗号鍵は、所望の場合、パスワードを用いて更に保護することができる。
【００１４】
Ｔｒｕｓｔｏｎｉｃ（ｈｔｔｐ：／／ｗｗｗ．ｔｒｕｓｔｏｎｉｃ．ｃｏｍ）は、ＡＲＭ、Ｇ＋Ｄ、及びＧｅｍａｌｔｏの合弁事業である。Ｔｒｕｓｔｏｎｉｃは、広範囲のスマートデバイスにわたり高信頼実行環境を提供する。その目標は、影響を受けやすいアプリケーションサービスのセキュアな実行を可能にすることである。Ｔｒｕｓｔｏｎｉｃは、高信頼実行環境のグローバルプラットフォーム規格の実施である。Ｔｒｕｓｔｏｎｉｃ  ＴＥＥで実行するように書かれたアプリは、署名され、測定される。Ｔｒｕｓｔｏｎｉｃをサポートするデバイスは、分離された実行カーネルを提供し、それにより、ロードされたアプリは、ルートデバイスのデバッグ動作を含め、デバイスで実行中のいかなる他のプロセスによってもスパイすることができない。Ｔｒｕｓｔｏｎｉｃは２０１２年に形成され、今では、６つの製造業者に出荷し、二十数個のサービスプロバイダをサポートしている。２億を超えるデバイスが現在、Ｔｒｕｓｔｏｎｉｃサポートを有して出荷されている。
【００１５】
Ｉｎｔｅｌ  ｖＰｒｏは、近代のＩｎｔｅｌチップセットに組み込まれる技術の集まりである。ｖＰｒｏを用いて販売された新しいマシンは、ＩｎｔｅｌのＴＸＴトラステッドエグゼキューションテクノロジーをサポートする。Ｉｎｔｅｌは、多くの暗号機能の保護された実行を可能にする管理エンジン（ＭＥ）でのセキュアな処理環境を提供する。この機能の一用途は、ＭＥ内のアプリとして実装されるＴＰＭ２．０機能の展開であった。管理エンジンは、ユーザとの完全に分離された通信を行うセキュアディスプレイ機能もサポートする。このようにして、ＭＥで実行中のアプリは、不正アクセスリスクを大幅に低減して、ユーザから指示を受け取ることができる。
【００１６】
ＡＲＭ  ＴｒｕｓｔＺｏｎｅは、全てのＡＲＭプロセッサで利用可能なシリコン基礎を提供する。プリミティブは、実行のセキュアワールドを一般実行スペースから分離する。ＡＲＭは、幾つかの標準プロセッサに組み込まれる設計を提供する。ＴｒｕｓｔＺｏｎｅを利用するために、アプリは、製造業者によるシステムのファームウェアの一部として展開するか、又は事後、Ｔｒｕｓｔｏｎｉｃ、Ｌｉｎａｒｏ、又はＮｖｉｄｉａのオープンソースマイクロカーネルのような第三者ツールを通して配送することができる。
【００１７】
本発明の幾つかの実施形態は、これらの技術を１組のサービスに適用して、人々とブロックチェーンとを結び付けるトランザクション環境を強化する。
【００１８】
第２要素認証の概念は、限られた使用を通して明確に確立されている。これは恐らく、ログインの突破が即時且つ不可逆的な資金の盗難を提供することができるビットコインサービスサイトで最も顕著に利用されている。大半の人々は、ＳＭＳ確認又はキーフォブの形態の第２の要素に馴染みがある。ユーザ名及びパスワードを入力し、次に、登録した電話へ連絡されたコードを入力する。第２要素認証は、ログインセキュリティにとって重要なステップであるが、ユーザに追加作業で負担を課す。第２要素認証が何故重要であるかを理解する場合であっても、人類は生来、怠惰である。多くのサイトでは、ユーザは繰り返しの確認から手を引くことを選ぶことができ、多くのユーザは、時間を節約するこのセキュリティの低下を容易に選択する。更なる方法例は、まず、認証要求の送信元のデバイス（装置）を検証するものであり得る。ＴＰＭ又は任意の他の暗号鍵セットのセキュアソースを使用して、ウェブサービスは、デバイスに、そのデバイスが前と同じデバイスであることを証明するように求めることができる。この要求は、ユーザにトランスペアレントである（又はＰＩＮで更にセキュア化する）ことができ、あるレベルの保証を提供し、それにより、多くの場合、識別情報及び認証に関するユーザのイライラを回避することができる。
【００１９】
マシン生成の暗号証明は、両方とも恐らくはユーザに起因する記憶可能なことに基づく短いユーザ名及び８文字パスワードよりもはるかに高い信頼性を有する傾向がある。ユーザは、デバイスを保護する仕事を任せるのに最良である。１万年の進化で、人々は価値のある物体を守るように訓練された。それでもなお私達は、１０桁の電話番号でさえ覚えることが難しい。他方、デバイスは、超高速数学専用である。ユーザが、通常使用するデバイスがない状況である場合、サービスはユーザ識別手順に後退することができる。一般的な使用事例ではない場合、ユーザは進んで、より面倒な識別手順を受け入れる。
【００２０】
本発明の実施形態例によれば、デバイス識別情報を利用する第１のステップは登録である。好ましい一実施形態では、デバイス登録は、何らかの他の高信頼エンティティの監視下で行われ得る。例えば、電話の登録は、物理的存在を用いてエンドユーザとデバイス識別情報とのバインドを確立することができる店頭で行うことができる。しかし、多くの使用事例では、このレベルの人物−デバイス関連付けは必要ではないか、又は望まれない。個人識別情報（ＰＩＩ）として見なすことができるデバイス識別情報及び属性は、密接にリンクされるべきではない。基本デバイス識別情報は純粋に匿名である。デバイスを高信頼的に登録するために必要なことは、２つのことだけである：Ａ）デバイスにロックされた鍵ペアを生成する能力及びＢ）このサービスを提供するデバイス環境の出所及び品質の保証。後者は、ソーシャルエンジニアリング又はサプライチェーン暗号のいずれかにより提供される。絶対的なものはないが、尊敬される調達者が存在している状態で登録されたデバイスは、実際のデバイスである可能性が高い。その調達者の持続的な評判が重要である。製造現場で適合され、ＯＥＭ認証局を用いて確認することができるデバイスの信頼性も同様に、その製造業者の評判上に築かれる。
【００２１】
幾つかの実施形態によれば、登録は、問い合わせできるが、スプーフィングできない一意性を確立することを含む。このために、ＴＰＭ（又は同様のハードウェアび信頼ルート（信頼起点））を使用し得る。ＴＰＭチップは、鍵ペアを生成し、鍵の公開部分をクライアントに返し、そして、クライアントは鍵の公開部分をサーバに投稿する。ランダムＩＤが生成され、一緒にカプレットがＮａｍｅｃｏｉｎ（又は名前付きデータを記録するように考案された同様のブロックチェーン若しくはブロックチェーン方法）に取引される。ブロックチェーンに収まると、デバイス記録は、ＰＣＲクォート、関連するビットコインアカウント、又は他のデータ等の属性で拡張及び変更することができる。大きなデータオブジェクトが、直接ではなくブロックチェーン内のハッシュ及びＵＲＬを用いて参照されることが予期される。登録エージェントは、デバイスと併せて、この記録を更新するＮａｍｅｃｏｉｎアカウントを制御する。しかし、登録エージェントもデバイスである自己登録デバイスのシナリオを想像することができる。登録すると、サービスはデバイスの公開鍵にアクセスして、通信及び関連する属性がデバイスから出てきたことの暗号保証を検証し暗号化することができる。
【００２２】
高信頼実行環境では、システムの残りの部分から分離してコードを実行する能力を更に拡張しながら、デバイス識別情報の特徴が提供される。本発明の実施形態は、様々なＴＥＥ環境での展開に向けてパッケージされたビットコインサービスコンポーネントを提供する。この結果、トランザクションの実行への２、３の重要な強化が生まれる：（１）コードは、第三者高信頼アプリケーションマネージャにより署名及び認証され、したがって、タンパリングすることができない。（２）コードは、ホスト動作環境外で実行され、したがって、マルウェアから保護される。（３）単なる鍵を超えたアプリケーションデータは、ＴＥＥ外部に決して露出されない。
【００２３】
登録されたデバイスは、サービスプロバイダがその状態及びコンテキストを確認できるようにする属性の記録を構築することができる。デバイス属性は、有用であるために、いかなるＰＩＩも包含する必要がない。例えば、クリーンブートシーケンスを宣言する最近のステートメントは、サービスプロバイダに、マシンが不正アクセスされていないことの幾らかの信頼を与えることができる。特異アサーションを提供する属性は、多くのＰＰＩを曝すことなく有用であることができ、例えば、マシン操作者は、２１才を超えているか、又は仏国市民若しくは姻戚関係のメンバーとして検証されている。大半の場合、デバイスとの対話は、そのブート整合性のステートメントを収集する機会である。これは、最新のブートステートメントと比較することができるハッシュの収集にすぎない。予測可能なようにブートされるマシンは、ＢＩＯＳ又はＯＳを変更した人よりも信頼できると信じられる。ＰＣＲクォートに加えて、参加しているアンチウィルスソフトウェアは、最後のスキャン以後、マシンがクリアされたことのステートメントを送出することができる。
【００２４】
幾つかの実施形態では、高信頼ネットワーク接続（ＴＮＣ）の原理の統合により、トランザクションを受け入れる前、未知のクライアントデバイスの完全な検証が可能になる。トランザクションの受け入れ前、既知の良好な状況又は状態にあるクライアントデバイスは、デバイスが正確に構成されているとの第三者のステートメントに基づく。このタイプの確認は、好ましくは任意のトランザクション処理システムの一環として要求し得る広範囲のサイバーセキュリティコントロールに対処する。
【００２５】
例示的な実施形態は、ブロックチェーン通信ネットワークにおいてユーザデバイスのデバイス整合性を確認するコンピュータ実施方法であり、この方法は、ブロックチェーンネットワークにおいて電子トランザクションを送出する準備として、トランザクションの一環として、デバイス整合性検証プロセスを実施することを含み、デバイス整合性検証プロセスを実施することは、ユーザデバイス内の信頼ルートから、デバイス実行環境の整合性の内部検証を実行することと、署名の整合性の確認がブロックチェーントランザクションに適用されるように、電子署名を要求することとを含み、署名の整合性の確認は、デバイスの実行環境が既知の良好な状況にあるか否かの判断に基づき、署名の整合性の確認は、署名の整合性に基づいて、トランザクションの進行を許可するか、又はデバイスの実行環境が既知の良好な状況にないと判断される場合であっても、ユーザにより意図される電子トランザクションが進行を許可されることを確認するように救済機関に要求することを含む。幾つかの実施形態では、署名の整合性の確認は、ブロックチェーンネットワークの少なくとも一部が、電子トランザクションを受け入れるために複数の電子署名を要求することで応答するように、処理のために信頼ルート命令をブロックチェーンネットワークに送信することを含み、これは、デバイスの実行環境内で、ユーザデバイス内の信頼ルートからの命令を作成することと、署名の整合性の確認がブロックチェーントランザクションに適用されるように、信頼ルート命令に対応する第１の電子署名を要求することと、第１の電子署名に応答して、デバイスの実行環境が既知の良好な状況にあるか否かの判断に基づいて、署名の整合性を確認することとを含み、第１の電子署名に応答して、前記署名の前記整合性を確認することは、署名を前に記録された参照値と比較することと、署名が前に記録された参照値に一致する場合、トランザクションの進行を許可することと、署名が前に記録された参照値に一致しない場合、ユーザにより意図された電子トランザクションが進行を許可されることを確認するように、第三者のアウトオブバンドプロセス（第三者による別個のプロセス）に要求することとを含む。幾つかの実施形態では、署名の整合性を確認することは、デバイスが、デバイスの実行環境が既知の良好な状況にあるか否かの判断に基づいて、電子署名を提供することと、デバイスが電子署名を提供する場合、トランザクションの進行を許可することと、デバイスの実行環境が既知の良好な状況にないと判断される場合であっても、救済機関が署名を提供するとき、ユーザにより意図されるトランザクションの進行を許可することとを含む。さらに、別個のプロセスは、Ｎ又はＭ暗号鍵機能を使用して、ユーザの意図が所定の要件を満たすこと、デバイス整合性が所定の要件を満たすこと、又は追加のプロセスが所定の要件を満たすことのうちの少なくとも１つを確認することを更に含む。参照値は、デバイスプラットフォームの所有者により実行される登録プロセス中に生成し得る。参照値は、デバイスに割り当てられる出生証明書に基づいて生成し得、出生証明書は、デバイスの製造業者又は作成者、デバイスの実行環境の製造業者又は作成者、及び／又はデバイスのアプリケーションの製造業者又は作成者により生成される。参照値は、デバイスの製造業者又は作成者、デバイスの実行環境の製造業者又は作成者、及び／又はデバイスのアプリケーションの製造業者又は作成者のうちの少なくとも１つの署名を含み得る。第三者のアウトオブバンドプロセスは、トランザクションの確認要求に応答してトークンを返し得る。幾つかの実施形態は、署名が前に記録された参照値と一致しない場合、特定の時間期間以内に電子トランザクションを完了させ得る。
【００２６】
幾つかの実施形態は、デバイスの実行環境が既知の良好な状況にないと判断される場合であっても、意図される電子トランザクションが進行を許可されることを確認し得、参照値の登録からトランザクションまでの時間期間及び／又はトランザクション量に基づく。所定の閾値を超えるトランザクションは、時間期間が所定の要件を満たす場合、進行が許可され得る。特定量を超えるトランザクションを許可することは、前に許可された最小数のトランザクションに基づき得る。幾つかの実施形態は、デバイス整合性が最小の所定要件を満たすか否か及びとるべき更なる動作をユーザに示す表示デバイスを使用することを更に含み得る。他の実施形態は、第三者へのトランザクションの通知を更に含み得、通知に応答して、第三者は、トランザクション及びデバイスの状態を記録する。第三者は、トランザクションの更なる分析のために、デバイス整合性に関連する測定値を記録し得る。加えて、記録のプライバシーを確保することは、記録が許可された第三者のみに提供されるように、記録を暗号で難読化することを含み得る。別の例示的な実施形態は、ブロックチェーン通信ネットワーク内のユーザデバイスのデバイス整合性を確認するコンピュータ実施システムであり、このシステムは、ブロックチェーン通信ネットワークと、ブロックチェーンネットワーク内のユーザデバイスと、ブロックチェーンネットワーク内の電子トランザクションと、ブロックチェーンネットワークにおいて電子トランザクションを送出する準備として、トランザクションの一部として実施されるデバイス確認プロセスとを備え、実施は、デバイス内の信頼ルートから実行されるデバイス実行環境の整合性の内部検証、署名の整合性の確認がブロックチェーントランザクションに適用されるような電子署名を更に含み、署名の整合性の確認は、デバイスの実行環境が既知の良好な状況にあるか否かの判断に基づき、署名の整合性に基づいて、トランザクションの進行を許可するか、又はデバイスの実行環境が既知の良好な状況にないと判断される場合であっても、ユーザにより意図される電子トランザクションが進行を許可されることを確認するように救済機関に要求することを含む。
【００２７】
上記は、同様の参照文字が、様々な図を通して同じ部分を指す添付図面に示される、以下の本発明の実施形態例のより具体的な説明から明白になる。図面は必ずしも一定の縮尺であるわけではなく、その代わり、本発明の実施形態を示すことに重点が置かれている。
【図面の簡単な説明】
【００２８】
【図１Ａ】本発明の実施形態を実施し得るデジタル処理環境例である。
【図１Ｂ】コンピュータノードまたは計算ノードの任意の内部構造のブロック図である。
【図２Ａ】本発明によるデバイス認証システム例を示すブロック図である。
【図２Ｂ】本発明によるデバイス認証システム例を示す図である。
【図２Ｃ】本発明の実施形態のコンポーネントの図である。
【図２Ｄ】認証システムアダプタ並びにその外向き及び内向きインタフェースの図である。
【図３Ａ】エンコーダによる命令の一連のパッケージ及び配送の図である。
【図３Ｂ】本発明の実施形態によるデバイス登録プロセスの図である。
【発明を実施するための形態】
【００２９】
本発明の実施形態例の説明は以下である。
【００３０】
本発明の実施形態は、電子トランザクションに携わる前にデバイスの健康状態を保証するシステム及び方法である。
【００３１】
ブロックチェーントランザクションは、トランザクションを実行する未知のデバイスに対する確認又はサイバーセキュリティコントロールを有さない。したがって、ブロックチェーントランザクションの受け入れ前に未知のクライアントデバイスを完全に検証することは、ブロックチェーントランザクションに更なるセキュリティを提供する。
【００３２】
実施形態例は、ネットワークスイッチへの接続を実際に可能にする前に、デバイスの整合性を確認し得る高信頼ネットワーク接続（ＴＮＣ）規格の原理上で見出し得る。ＴＮＣによれば、デバイスは、デバイスにセキュアに記憶される一連の測定を実行する。測定は通常、ＢＩＯＳイメージ、オペレーティングシステム（ＯＳ）、及び改竄されていないことを確認する必要がある任意のアプリケーションの検証を含む。ネットワーク接続時、スイッチは、測定データが、デバイスが前に接続されたとき又は現在の既知の良好な状況若しくは状態にあったときに計算された参照値に一致することを確認する検証プロセスを実行する。高信頼実行環境（ＴＥＥ）は、自己測定プロセス及びデバイスの健康状態のリモート保証も可能である。幾つかの好ましい実施形態では、ＴＮＣシステムは、高信頼コンピューティンググループ（ＴＣＧ）規格に基づき、通常、高信頼プラットフォームモジュール（ＴＰＭ）チップが統合される。
【００３３】
幾つかの実施形態では、完全なデバイス整合性確認の自動化は、ブロックチェーントランザクションの一環として提供される。デバイス整合性の検証を提供するために、ブロックチェーン命令を実行中のデバイスは、ブロックチェーントランザクションの初期化時、デバイス内の信頼ルートからの実行環境の整合性の内部検証を実行する。デバイスは、人間の入力あり又はなしで、測定環境内で命令を作成する。次に、この命令はブロックチェーンネットワークに送信され、処理される。ブロックチェーンネットワークは、トランザクションを受け入れるために複数の署名を必要とする。第１の署名は、署名の確認をトランザクションに適用させた、作成されたルート命令それ自体である。次に、ネットワークは、それを前に記録された参照値と比較することにより、実行環境の整合性署名を確認する。署名が参照値に一致する場合、トランザクションは、進むことが許可される。署名及び参照値が一致しない場合、システムは、実行環境が既知の良好な状況にない場合であっても、意図されたトランザクションの進行が許可されることを確認する第３のアウトオブバンドプロセスの完了を要求する。ブロックチェーントランザクションは、トランザクションを実行する未知のデバイスに対していかなる確認又はサイバーセキュリティコントロールも有さないため、本発明の実施形態は、トランザクションを受け入れる前、未知のクライアントデバイスが既知の良好な状況にあることの完全な検証を可能にする。したがって、本発明の実施形態は、任意のブロックチェーントランザクション処理システムの一環として要求されるべき広範囲のサイバーセキュリティコントロールに対処することができる。
【００３４】
デジタル処理環境
トランザクション１００に従事する前にデバイス健康状態を認証する本発明によるシステムの実施例は、ソフトウェア環境、ファームウェア環境、又はハードウェア環境で実施し得る。図１Ａは、本発明の実施形態を実施し得るそのような１つのデジタル処理環境例を示す。クライアントコンピュータ／デバイス１５０及びサーバコンピュータ／デバイス１６０（又はクラウドネットワーク１７０）は、アプリケーションプログラム等を実行する処理デバイス、記憶デバイス、及び入／出力デバイスを提供する。
【００３５】
クライアントコンピュータ／デバイス１５０は、直接又は通信ネットワーク１７０を介して、他のクライアントコンピュータ／デバイス１５０及びサーバコンピュータ／デバイス１６０を含め、他の計算デバイスにリンクし得る。通信ネットワーク１７０は、無線又は有線ネットワーク、リモートアクセスネットワーク、グローバルネットワーク（すなわち、インターネット）、コンピュータの世界規模の集まり、ローカルエリア又は広域ネットワーク、並びに現在、様々なプロトコル（例えば、ＴＣＰ／ＩＰ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＲＴＭ等）を使用して互いと通信するゲートウェイ、ルータ、及びスイッチの一部であることができる。通信ネットワーク１７０は、仮想私設ネットワーク（ＶＰＮ）、帯域外ネットワーク、又はそれら両方であることもできる。通信ネットワーク１７０は、データネットワーク、音声ネットワーク（例えば、陸線、モバイル等）、オーディオネットワーク、ビデオネットワーク、衛星ネットワーク、無線ネットワーク、及びページャネットワークを含むがこれらに限定されない様々な形態をとり得る。他の電子デバイス／コンピュータネットワークアーキテクチャも適する。
【００３６】
サーバコンピュータ１６０は、ユーザデバイス認証システム１００を提供するように構成し得、ユーザデバイス認証システム１００は、要求者が認証システムにより保護されるリソースにアクセスできるようになる前、認証機関と通信して、要求者の識別情報を確認する。サーバコンピュータは、別個のサーバコンピュータではなく、クラウドネットワーク１７０の一部であってもよい。
【００３７】
図１Ｂは、オーディオ信号、画像信号、ビデオ信号、又はデータ信号の情報の表示を促進するのに使用し得る、図１Ａの処理環境内のコンピュータ／計算ノード（例えば、クライアントプロセッサ／デバイス１５０又はサーバコンピュータ１６０）の任意の内部構造のブロック図である。図１Ｂの各コンピュータ１５０、１６０は、システムバス１１０を含み、バスは、コンピュータ又は処理システムのコンポーネント間でのデータ転送に使用される１組の実際又は仮想のハードウェア線である。システムバス１１０は基本的に、要素間でのデータ転送を可能にする、コンピュータシステムの様々な要素（例えば、プロセッサ、ディスクストレージ、メモリ、入／出力ポート等）を接続する共有コンジットである。
【００３８】
システムバス１１０には、様々な入力デバイス及び出力デバイス（例えば、キーボード、マウス、タッチスクリーン、インタフェース、ディスプレイ、プリンタ、スピーカ、オーディオ入出力、ビデオ入出力、マイクロフォンジャック等）をコンピュータ１５０、１６０に接続するＩ／Ｏデバイスインタフェース１１１が取り付けられる。ネットワークインタフェース１１３は、ネットワーク（例えば、図１Ａにおいて１７０で示されるネットワーク）に取り付けられた様々な他のデバイスにコンピュータを接続できるようにする。メモリ１１４は、本発明の幾つかの実施形態のデバイス整合性保証及び認証コンポーネントのソフトウェアインプリメンテーションを実施するのに使用されるコンピュータソフトウェア命令１１５及びデータ１１６の揮発性ストレージを提供する。本明細書に記載されるユーザ認証システム１００のそのようなデバイス整合性保証及び認証ソフトウェアコンポーネント１１５、１１６（例えば、図２Ａのエンコーダ２１０、トランステッドエグゼキューション環境（ＴＥＥ）アプレット２０８、認証サイト２０６）は、Ｐｙｔｈｏｎ等の任意の高水準オブジェクト指向プログラミング言語を含め、任意のプログラミング言語を使用して構成し得る。
【００３９】
モバイル実施例では、本発明のモバイルエージェントインプリメンテーションを提供し得る。クライアントサーバ環境を使用して、サーバ１９０を使用したモバイルセキュリティサービスを可能にすることができる。例えば、ＸＭＰＰプロトコルを使用して、デバイス１５０上のデバイス認証エンジン／エージェント１１５をサーバ１６０にテザリングすることができる。次に、サーバ１６０は、要求時にコマンドをモバイル電話に発行することができる。システム１００の特定のコンポーネントにアクセスするモバイルユーザインタフェースフレームワークは、ＸＨＰ、Ｊａｖｅｌｉｎ、及びＷＵＲＦＬに基づき得る。ＯＳ  Ｘ及びｉＯＳオペレーティングシステム及びそれぞれのＡＰＩの別のモバイルインプリメンテーション例では、Ｃｏｃｏａ及びＣｏｃｏａ  Ｔｏｕｃｈを使用して、オブジェクティブＣ又はＳｍａｌｌｔａｌｋスタイルメッセージングをＣプログラミング言語に追加する任意の他の高水準プログラミング言語を使用してクライアント側コンポーネント１１５を実施し得る。
【００４０】
システムは、サーバコンピュータ１６０に、認証（又は証明）エンジン２４０（図２）を含み得るサーバプロセスのインスタンスを含むこともでき、認証（又は証明）エンジン２４０は、ユーザの登録、要求者が登録ユーザであることを確認する認証機関（又は証明機関）の選択、要求者の識別情報の確認に関する認証機関との通信、信頼スコアを計算する統計学的アルゴリズム等のアルゴリズムの実行を可能にして、システムにより保護されるリソースへの要求者アクセスを許可又は拒絶する。
【００４１】
ディスクストレージ１１７は、システム１００の実施形態の実施に使用されるコンピュータソフトウェア命令１１５（「ＯＳプログラム」と同義）及びデータ１１６の不揮発性ストレージを提供する。システムは、サーバコンピュータ１６０がアクセス可能なディスクストレージを含み得る。サーバコンピュータは、システム１００に登録されたユーザの認証に関連するレコードへのセキュアアクセスを維持することができる。中央プロセッサユニット１１２もシステムバス１１０に取り付けられ、コンピュータ命令の実行を提供する。
【００４２】
実施形態例では、プロセッサルーチン１１５及びデータ１１６はコンピュータプログラム製品である。例えば、認証システム１００の態様がサーバ側コンポーネント及びクライアント側コンポーネントの両方を含み得る。
【００４３】
実施形態例では、認証機関／証明機関には、インスタントメッセージングアプリケーション、テレビ会議システム、ＶＯＩＰシステム、電子メールシステム等を介して交信し得、これらは全て、少なくとも部分的に、ソフトウェア１１５、１１６において実施し得る。別の実施形態例では、認証エンジン／エージェントは、アプリケーションプログラムインタフェース（ＡＰＩ）、実行可能ソフトウェアコンポーネント、又は計算デバイス１５０で実行中のトラステッドプラットフォームモジュール（ＴＰＭ）でユーザを認証するように構成されたＯＳの統合コンポーネントとして実施し得る。
【００４４】
ソフトウェアインプリメンテーション１１５、１１６は、ユーザ認証システム１００のソフトウェア命令の少なくとも一部を提供する、ストレージデバイス１１７に記憶可能なコンピュータ可読媒体として実施し得る。認証エンジンのインスタンス等のユーザ認証システム１００の各ソフトウェアコンポーネントの実行インスタンスは、コンピュータプログラム製品１１５として実施し得、当分野で周知のように、任意の適するソフトウェアインストール手順によりインストールすることができる。別の実施形態では、システムソフトウェア命令１１５の少なくとも一部は、例えば、ブラウザＳＳＬセッション又はアプリ（モバイルデバイスから実行されるか、それとも他の計算デバイスから実行されるかに関係なく）を通して、ケーブル、通信接続、及び／又は無線接続を介してダウンロードし得る。他の実施形態では、システム１００のソフトウェアコンポーネント１１５は、伝搬媒体（例えば、無線波、赤外線波、レーザ波、音波、又はインターネット若しくは他のネットワーク等のグローバルネットワークを介して伝搬する電波）上の伝搬信号で実施されるコンピュータプログラム伝搬信号製品として実施し得る。そのような搬送媒体又は搬送信号は、図２Ａの本ユーザデバイス認証システム１００のソフトウェア命令の少なくとも一部を提供する。
【００４５】
本発明の特定の実施形態例は、デバイスが、それ自体がこうであるものとするものであり、厳密に求められるように命令を実行することに信頼を置くことができる場合、オンラインサービスを大幅に強化し得る前提に基づく。サービスプロバイダは一般に、サーバを信頼し、その理由は、サーバが管理制御下にあり、通常、物理的に保護されるためである。しかし、サービスプロバイダのサービスの略全ては、サービスプロバイダがごくわずかしか知らず、いかなる制御も希にしか及ぼされないデバイスを通してユーザに届けられる。
【００４６】
トラステッドエグゼキューションテクノロジーの使用を通して、特定の本発明の実施形態は、消費者デバイスの未知の世界で信頼性のオアシスをサービスプロバイダに提供することが可能である。「これに署名」又は「これを復号化」等の基本機能は、メインＯＳの不透明な世界の外部で実行される。鍵は、メモリ内で露出されずに生成し適用することができ、デバイス製造業者に追跡される一連のエンドースメントを通して証明することができる。
【００４７】
本発明の特定の態様は、デバイスを信頼できるようにする。幾つかの実施形態は、デバイスとの高信頼関係が、エンドユーザとのはるかに安全、容易、且つ強力な関係に役立つことができるという基本的前提で動作する。これを達成するには、現在のトランザクションに関わるデバイスが、前のトランザクションでのものと同じデバイスであることを確実に知る必要がある。デバイスが、復号化又は署名等の機密的な動作を実行するように要求された場合、保護情報を漏出しないことを保証することも必要とされる。
【００４８】
好ましい一実施形態例は、高信頼実行環境（ＴＥＥ）で実行されるデバイスコードを含む。ＴＥＥは、好ましくは、メインＯＳ外部で小さなアプレットを実行するハードウェア環境である。これは、製造業者から始まる、裏書きのエコシステムにより支配される専用ハードウェアを用いて、機密コード及びデータをデバイスマルウェア又はスヌーピングから保護する。
【００４９】
デバイス整合性証明／認証−幾つかの実施形態例
図２Ａは、コンポーネント２００を有する、本発明によるデバイス認証システム例を示すブロック図である。これらのシステムコンポーネント２００を用いて、ウェブ開発者及びアプリ開発者は、アプリケーションプログラムインタフェース（ＡＰＩ）を通して、エンドポイントユーザデバイス２０５において強化された暗号化及び識別鍵を利用することができる。加えて、デバイスの管理、バックアップ、証明等に関してこれらのシステムコンポーネント２００に構築される更なるサービスを提供し得る。このシステムをサポートするために、識別鍵の登録及び証明、バックアップ、及びデバイスグループ化のための１組のデバイス管理サービスが管理される。
【００５０】
好ましい実施形態例では、従来の手法でのようにミッションクリティカルデータを保持せず、むしろ、サービスプロバイダ２０４とユーザデバイス２０５との間のシームレスでありながら、それでもなお非常にセキュアな接続のためのプラットフォームを提供することがシステムの意図である。システムの一端部には、ユーザデバイス２０５の命令を準備するエンコーダ２１０があり、他端部には、その命令で動作することができる高信頼実行環境（ＴＥＥ）アプレット２０８であるデバイスＲｉｖｅｔがある。本発明の実施形態によるプロトコルは、これらの命令及びリプライがいかに構築されるかを定義する。
【００５１】
デバイスＲｉｖｅｔ又はＴＥＥアプレット２０８は、好ましくは、物理的作業とデジタル作業との革新的なバインドを実施する。デバイスＲｉｖｅｔ又はＴＥＥアプレット２０８は、識別、トランザクション、及び証明の特徴をデバイス２０５のハードウェアにロックする。
【００５２】
システム２００は、図２Ｂに示される本発明の実施形態によれば、セキュアソケットを使用して、全てのデバイスとの永続的な接続を維持し得る。このチャネルは、ペアリング及び他の管理機能に使用される。ライブラリコード２０９をサービスプロバイダに提供して、命令の構築及び署名を簡易化し得る。このライブラリ２０９は、例えば、Ｐｙｔｈｏｎのようなダイナミックセマンティクスを有するオブジェクト指向高水準プログラミング言語等のプログラミング言語で実装することができる。
【００５３】
好ましい一実施形態例では、ＴＥＥは、リッチオペレーティングシステムと一緒に実行され、そのリッチ環境にセキュリティサービスを提供するモバイル電話ハードウェアセキュリティチップ別個実行環境として実施し得る。ＴＥＥは、リッチＯＳよりも高レベルのセキュリティを提供する実行空間を提供する。別の実施形態例では、ＴＥＥは仮想マシンとして実施し得る。セキュア要素（ＳＥ）（すなわち、ＳＩＭ）ほどセキュアではないが、ＴＥＥにより提供されるセキュリティは、幾つか／多くの用途で十分である。このようにして、ＴＥＥは、ＳＥよりもかなり低コストで、リッチＯＳ環境よりも大きなセキュリティを可能にするバランスを届けることができる。
【００５４】
リングマネージャ２１２は、ユーザデバイス２０５の集まり（又はリング）を管理する、エンドユーザに提供されるサービスとして実施することができる。デバイス２０５は、１つの識別情報にグループ化し得、互いのバックアップ及び署名に使用し得る。リングには他のリングを関連付けて、デバイスネットワークを作成し得る。幾つかの好ましい実施形態では、リングは、個々のデバイスの公開鍵の集まりである（新しい鍵とは対照的に）。環境に多くの共有デバイスがない場合、好ましくは、デバイスのリストは短いリストであり得、その理由は、デバイスリスト上の全ての公開鍵を用いてメッセージを暗号化するために、より多くの計算リソース及び帯域幅リソースが使われ得、時間コストが導入される潜在性による。
【００５５】
好ましくない実施形態例では、リングは、デバイス２０５の一意の秘密鍵の上の共有秘密鍵として実施し得る。しかし、「秘密鍵」の共有が典型的でなく、また長寿命の共有対象鍵を有することも望ましくないことに留意されたい。
【００５６】
本発明の態様によるシステムの一態様は、デバイスを登録し、デバイスにサービスプロバイダの鍵を装備する。本発明によるＡＰＩは、高信頼性で匿名のデバイスＩＤの取得を含め、幾つかの機密デバイス側トランザクションのセキュア実行を可能にする−要求時、本発明の実施形態は、デバイスの署名鍵を生成する。公開鍵は、デバイスの識別及び通信に使用することができる文字列にハッシュ化される。秘密鍵は、ハードウェアにロックされた状態を保ち、ＩＤを要求したサービスの代理としてのみ適用することができる；デバイスに何かに署名させる−デバイス識別情報の秘密鍵を使用して、この特定のデバイスが関与しなかったことを証明することに署名することができる。この署名セレモニーは、鍵が決して、デバイスの通常の処理環境に露出されないようにセキュアハードウェアで実行される；デバイスに何かを暗号化させる−暗号鍵は要求時に生成し、任意のデータブロブに適用することができる。暗号化及び復号化は、ローカルにトリガーされ、セキュア実行環境内で行われて、鍵を保護する；ビットコインアカウントを作成する−デバイスに、ＴＥＥに内蔵された乱数生成器（ＲＮＧ）を使用して新しいビットコインアカウントを生成するように求めることができる；ビットコイントランザクションの署名−デバイスは、秘密ビットコインアカウント鍵を適用して、トランザクションに署名し、次に、トランザクションをサービスプロバイダに返すことができる；確認のセキュア化−より新しいＴＥＥ環境は、高信頼実行に加えて、高信頼表示及び入力をサポートする。高信頼表示は、「トランザクション金額を確認」等の簡単な確認メッセージをエンドユーザに提示できるようにする；識別情報の共有及びバックアップにデバイスを参加させる−大半のユーザは幾つかのデバイスを有する。本発明の特定の実施形態は、複数のデバイスをリングにバインドできるようにするし、それにより、複数のデバイスは、ユーザの代理としてサービスプロバイダにそれら自体を区別せずに提示することができる。
【００５７】
サービスプロバイダは、第三者エージェント／プロセスを呼び出して、デバイスにおいてハードウェア鍵を作成する。クリプトコイン又はデータ暗号化等の目的に応じて、異なるタイプの鍵が利用可能である。ハードウェア鍵は、作成中に確立される単純な使用ルールにより支配される。例えば、鍵は、使用要求が、その鍵を作成したサービスプロバイダにより署名されること又はユーザが高信頼ユーザインタフェース（ＴＵＩ）を通してアクセスを確認することを要求する。
【００５８】
デバイスＲｉｖｅｔ２０８は、デバイス２０５と「ペア」になったサービスプロバイダ２０４からの命令にのみ応答する。認証ウェブサイト２０６は、デバイス及びサービスプロバイダの両方の整合性及び識別情報を確認することが可能であるため、ペアリングセレモニーを行う。デバイス２０５がペアリングされる場合、デバイス２０５はサービスプロバイダ２０４の公開鍵を取得し、一方、サービスプロバイダは、デバイス２０５の一意に生成された識別情報及び公開鍵を取得する。
【００５９】
第三者エージェント／プロセスはローカルコールをサポートするが、理想的には、全ての命令はサービスプロバイダ２０４により署名される。これは、デバイス鍵が不正アプリケーションにより適用されることから保護する。エンコーダ２１０が提供されて、アプリケーションサーバでデバイス命令を準備し署名するのを促進する。
【００６０】
アプリの出所の強力な保証及び他のアプリの実行からの不透明な分離から大きな恩恵を受けるアプリのクラスがある。これはトラステッド実行環境又はＴＥＥとして知られている。プライマリＯＳ及びメモリスタックで実行されるアプリとは異なり、ＴＥＥで実行されるアプリは、ＯＳによるスヌーピングなしで行うことができる暗号プリミティブにアクセスすることができる。特定のプラットフォームでは、アプリは、ユーザ入力及び表示への直接アクセスも有して、デバイスの操作者とのプライベート対話を保証する。この技術は十年以上にわたり遂行されてきたが、ＴＥＥのサポートを有するデバイスが利用可能になったのはごく最近になってからである。例えば、Ｉｎｔｅｌは、２０１１年に商用解決策の送達を開始し、ＡＲＭの合弁事業であるＴｒｕｓｔｏｎｉｃは２０１３年に乗り出した。
【００６１】
ＴＥＥへのアプリの展開は、専用ハードウェアデバイスの配達と似ている。実行及びデータは、ホストのいかなる他の機能からも暗号で分離される。トラステッドエグゼキューションテクノロジーの大半のアプリケーションは、企業セキュリティ又はＤＲＭに関係してきたが、代わりに本発明の実施形態は、一般的なウェブサービスのニーズにフォーカスされたアプレットを提供する。ビットコイン等のクリプトコインは、消費者鍵セキュリティのニーズを際立たせた。
【００６２】
本発明の実施形態は、呼び出しをセキュア環境に翻訳するネイティブＡＰＩを提供する。異なるＴＥＥ環境は非常に異なるアーキテクチャに従うが、本発明の実施形態のＡＰＩは、均一なインタフェースをアプリケーションに提示するように設計される。全てのＴＥＥアプレットと同様に、本発明の実施形態によるＴＥＥアプレットは、高信頼アプリケーションマネージャ又はＴＡＭなしではインストール及び初期化することができない。ＴＡＭは証明機関（ＣＡ）に似た役割を果たす。ＴＡＭは、デバイス製造業者との関係をセキュア化するとともに、デバイスにロードし得る全てのアプレットに署名する。このようにして、ＴＡＭは、アプレット及びＴＥＥの両方の出所及び整合性についての保証を表現する。
【００６３】
デバイス整合性証明
本発明の実施形態は、ブロックチェーントランザクションでの署名者としての既知の状態と突き合わせたデバイス整合性の証明を自動化することにより、デバイス整合性証明を提供する。本発明の実施形態により実施されるシステムは、図２Ｃに示される幾つかのコンポーネントで構成される。デバイスアダプタ２２０は、サービスプロバイダ２０４のアプリケーションへのインタフェースを提供し、デバイスＴＥＥ２０８と統合する、エンドポイントデバイスで実行されるソフトウェアサービスである。トラステッド実行環境（ＴＥＥ−時にはＴｒＥＥ）は、リッチＯＳと一緒に実行されるモバイル電話ハードウェアセキュリティチップ別個実行環境であり、セキュリティサービスをそのリッチ環境に提供する。ＴＥＥは、セキュア要素（ＳＥ）（すなわち、ＳＩＭ）ほどセキュアではないが、リッチＯＳよりも高レベルのセキュリティを提供する実行空間を提供し、ＴＥＥにより提供されるセキュリティは、幾つか／多くの用途で十分である。このようにして、ＴＥＥは、ＳＥよりもはるかに低いコストで、リッチＯＳ環境よりも大きなセキュリティを可能にするバランスを届ける。別のコンポーネントであるデバイスＴＥＥ２０８は、ハードウェアセキュアＴＥＥで実行されるソフトウェアプログラムである。デバイスＴＥＥ２０８は特に、マルウェアからの不正アクセスなしで、又はデバイスオペレータなしで暗号機能を実行するように設計される。別のコンポーネントであるデバイス登録機関２２１は、デバイスをブロックチェーン２２２に登録するサービスである。ブロックチェーン２２２は、デバイス登録及び属性の記憶並びにトランザクションの実行の両方に使用される。異なるブロックチェーンがあり得る。別のサポートコンポーネントは、デバイスとのトランザクションを行おうとするアプリケーションであるサービスプロバイダ２０４である。ＯＥＭ（相手先商標製造会社）２２３は、デバイス及び／又はデバイスの出所を暗号的に保証する権限が与えられた高信頼アプリケーションマネージャ（ＴＡＭ）を構築するエンティティである。
【００６４】
本発明の実施形態によれば、図２Ｃに示されるデバイスアダプタ２２０のソフトウェアは、初回実行時、デバイスＴＥＥ２０８に公開／秘密鍵ペアを生成するように求める。公開鍵は、デバイス製造中に確立される証明鍵により署名される。この署名された公開鍵は、デバイス登録機関２２１に送信され、ＯＥＭ２２３を用いて検証される。登録は、デバイス操作者からの確認を含み得る。登録は、販売員が存在した状態での店頭での証明を含み得る。登録機関は、以下のうちの１つ又は複数を含むデバイス測定レコードについてデバイスに尋ね得る：ブートプロセスにより生成されるプラットフォーム構成レジスタ（ＰＣＲ）の複合値、ＢＩＯＳバージョン、ＯＳバージョン、ＧＰＳロケーション。このデータは、デバイス秘密鍵により署名される。これは登録機関により更に署名される。その結果生成されるデータセットは、将来の整合性チェックのゴールドリファレンス又は参照値になる。ゴールドリファレンス又は参照値を収集するに当たり、デバイス操作者からの確認を要求し得る。このデータセットは、公開暗号台帳に掲示される。公開記録は、登録機関の証明と共に登録時の暗号証明書を確立した。登録は、ロケーション、企業名、又はデバイスのメーカー／型番等の属性データを更に含み得る。登録は、登録時に登録機関の保険期間を記載した署名付き文書を参照し得る。デバイス登録機関２２１又は別の高信頼整合性サーバは、ブロックチェーンでの多重署名トランザクションでの署名者として参照することができるブロックチェーンアカウントキー（公開／秘密鍵ペア）を作成する。ブロックチェーントランザクションで表される署名者値は、登録機関により連署されない限り、消費又は転送することができない。
【００６５】
トランザクションに署名するために、整合性サーバは、デバイスからの最近の測定値を予期する。この測定値は、デバイスアダプタにより直接要求されるか、又はデバイスとの持続的ソケット接続を通してサーバによりフェッチし得る。現在の測定値は、ブロックチェーン内のゴールド測定値又は参照値と比較される。測定値が一致する場合、トランザクションは署名される。測定値は一致するが、最近の測定値が指定された時間窓よりも古い場合、要求は拒絶される。測定値が一致しない場合、要求は拒絶される。拒絶される場合、トランザクションは、拒絶をオーバーライドするように求めることができる別の手動署名者を用いて準備された可能性がある。測定値が一致しない場合、デバイスは、新しい測定値が収集される登録リニューアルを受け得る。測定値が一致する都度、成功カウントでデバイス登録レコードを更新することができる。整合性サーバには、他の一致する測定値又は属性に鑑みて問題が深刻であると見なされない場合、一致しない測定値を受け入れるポリシールールを与え得る。
【００６６】
本発明の実施形態によるシステムは、整合性サーバではなく、高信頼デバイスの集まりを用いて実施されて、測定値照合作業及びトランザクション署名作業を行い得る。システムは、Ｅｔｈｅｒｅｕｍにより開発中であるもの等のスマートブロックチェーンシステムに内蔵される特徴を使用して、トランザクション処理中、整合性測定値を直接照合し得る。
【００６７】
デバイス整合性保証−認証ウェブサイト
実施形態例では、認証ウェブサイト２０６は、第三者エージェント／プロセス秘密鍵を使用して、デバイス２０５及びサービスプロバイダ２０４の識別鍵を登録する、Ｐｙｔｈｏｎで書かれたＪＳＯＮ  ＡＰＩであり得る。登録中、ユーザデバイス２０５又はサービスプロバイダ２０４の公開鍵は、ＴＥＥアプレット２０８により記録される。登録により、ＴＥＥアプレット２０８はデバイス２０５をサービスプロバイダ２０４とペアリングすることができる。ペアリングの結果として、ユーザデバイス２０５は、第三者エージェント／プロセスにより証明されたサービス公開鍵を有し、したがって、サービスプロバイダ２０４の命令に応答することができる。
【００６８】
本発明の実施形態によるプロトコルは、命令の構造及びデバイス２０５が命令を受け入れるために適用しなければならない署名／暗号化を指定する。命令自体は、例えば、命令コード、バージョンデータ、及びペイロードを含むＣ構造体として準備し得る。構造体全体は、好ましくは、サービスプロバイダキーにより署名され、デバイスローカルコマンドを呼び出すことによりデバイスＴＥＥアプレット２０８に送られる。
【００６９】
好ましくは、あらゆるユーザデバイス２０５は、一意の身元信用証明書を提示すべきである。デバイスはリングに加わって、単一のエンティティとして動作し得る。一実施形態では、デバイス２０５は、リストとしてローカルに記憶されるが、公開的にクロスプラットフォーム認証に変換されるグループＩＤをサポートすることができる。ＴＥＥアダプタ２１６は、ＴＥＥに施錠されたデバイスＲｉｖｅｔ／ＴＥＥアプレット２０８と、パートナーアプリ及びオンラインサービスという外部世界との間のインタフェースとして構成し得る。実施態様では、これは、デバイスにわたる基本機能、ハードウェアサポート、及びＯＳアーキテクチャにより少なくとも部分的に決まる１つ又は複数の多様な形態で現れることができる。
【００７０】
デバイス整合性保証−認証システムアダプタ
認証システムアダプタ２１４は、図２Ｄに示されるように、外向き及び内向きインタフェースで構成される。内向きインタフェースであるＴＥＥアダプタ２１６は、デバイスＲｉｖｅｔ２０８とのプロプライエタリ通信を扱う。ホストアダプタ２１７は、サービスを第三者アプリケーションに向けて露出するのに提供される。ホストアダプタ２１７は、ブラウザ又はシステムサービス等の異なるローカルコンテキストを通して、認証システムアダプタ２１４のインタフェースを提示する。多様なコンテキストの複数の実現が予期されるが、まず、これはＡｎｄｒｏｉｄサービス及びＷｉｎｄｏｗｓ  ＣＯＭプロセスであり得る。ソケットアダプタ２１５は、クライアント環境を認証ウェブサイト２０６に接続する。ＴＥＥアダプタ２１６コンポーネントは、コマンドをデバイスＲｉｖｅｔ２０８にパイピングするプロプライエタリグルー（ｇｌｕｅ：接着剤）である。Ａｎｄｒｏｉｄ実装では、認証システムアダプタ２１４は、Ａｎｄｒｏｉｄ  ＮＤＫサービスアプリとして現れ得、ブート時に起動するように構成し得る。認証システムアダプタ２１４は、デバイスＲｉｖｅｔ２０８にパイピングされ、次に、応答イベントの通知を同期して待つメッセージバッファを準備する。ホストアダプタ２１７は主に、ＴＥＥアダプタ２１６をホスト環境から分離するためにそこにある。ホストアダプタ２１７は、潜在的に厳しい環境で動作する。したがって、通常、クライアントが不正アクセスされていないことの保証は制限される。したがって、ホストアダプタの役割は主に、デバイスＲｉｖｅｔ２０８への容易なアクセスを促進することである。デバイスＲｉｖｅｔ２０８に向けられたサービスプロバイダ２０４からの命令は、サービスプロバイダ２０４により署名され、次に、ＴＥＥアダプタ２１６及びデバイスＲｉｖｅｔ２０８に通される。
【００７１】
デバイスに登録される最初のサービスプロバイダ
実施形態例によれば、認証ウェブサイト２０６は、デバイス２０５に登録される最初のサービスプロバイダである。認証ウェブサイト２０６は、追加のサービスプロバイダをそのデバイス２０５とペアリングできるようにする特別な機能を有する。認証ウェブサイト２０６との通信は、ウェブＡＰＩを通して扱われ得、認証されるべきである。一例では、これはＡＰＩキーを用いて実施される。好ましい実施形態例では、これはＳＳＬ鍵スワップを使用して実施される。幾つかの実施形態では、全ての要求は署名される。
【００７２】
デバイスとの関係は、秘密鍵を用いて命令に署名可能なことに依存し得る。そのような秘密鍵は高度に機密的であり、保護される。好ましくは、秘密鍵はＨＳＭ内に入れられる。
【００７３】
幾つかの実施形態では、複数の鍵が使用され、それにより、１つが不正アクセスされた場合、システム全体は失われない。これは、例えば、どのデバイスが不正アクセスされた鍵と接続されているかを攻撃者が知ることをより難しくするはずである。さらに、システム２００は、好ましくは、図２Ｃに示されるソケットアダプタ２１５を通して全てのデバイス２０５と略常に交信しており、それにより、鍵の頻繁なローテーションを促進することができる。
【００７４】
認証ウェブサイト２０６は、幾つかのサブコンポーネントを含み得る。デバイスＩＤは認証ウェブサイト２０６又は他の登録エージェントによりデバイスに割り当てられる、ＵＵＩＤでの一意の識別子である。任意のローカルアプリケーションにより要求することができる一時的なポインタであるデバイスポイントをデバイス１５０に提供し得る。デバイスポインタは、認証ウェブサイト２０６への現在のソケットセッションを識別することができ、したがって、デバイス通信チャネルの確立及び永続的識別子であるデバイスＩＤの検索に使用することができる。デバイス登録のルートは、一意の匿名識別子、登録日、デバイスハードウェアに保持される秘密鍵とペアになった公開鍵、及び登録エージェントからの証明署名を含む。この情報は、デバイス登録レコードに記録される。ＴＥＥアプレット２０８は、物理的作業とデジタル作業とのバインドを実施する。デバイスＲｉｖｅｔ２０９は、識別、トランザクション、及び証明の特徴をハードウェアにロックする。
【００７５】
命令処理プロトコル
デバイスＲｉｖｅｔ２０９の相手方はエンコーダ２１０である。エンコーダ２１０は、サービスプロバイダ２０４により署名及び／又は暗号化された特定のデバイスにより実行されるコマンドを準備する。サービスプロバイダの公開鍵は、認証ウェブサイト２０６により行われるペアリングプロセス中、デバイスに予めロードされる。これにより、デバイスＲｉｖｅｔ２０９は、要求の出所を検証することができ、必要な場合、命令の内容を復号化することができる。命令をパッケージし送出するシーケンスを図３Ａに示す。サービスプロバイダ２０４は、エンコーダ２１０のライブラリを用いて命令レコードを生成する。命令は、タイプ、ターゲットデバイス、及びペイロードを含む。命令は、デバイスキーを用いて符号化し得、サービスプロバイダキーにより署名されなければならない。デバイスキーは、認証ウェブサイト２０６からフェッチされるか、又はデバイス登録レコードを検索することによりブロックチェーンから直接フェッチされる。
【００７６】
デバイス登録プロトコル
ブロックチェーンへのデバイス登録又はデバイス用の出生証明書の作成は、本発明の実施形態例にとって重要である。図３Ｂに示される登録プロセスは、イライラがなく、又はユーザにトランスペアレントでなければならない。理想的には、完全に信用があるデバイスＩＤは、ＰＩＮ又は他のメモリテストを用いてのデバイスとユーザとの関係の個人化及び例えば、販売員がいる状態でデバイスを登録することによるユーザとデバイスとの法的バインドを含む。デバイスを製造したＯＥＭの証明キーを検索して、出所を保証する。デバイス登録の目的、電力、及び匿名性についてのトレーニングを含むこともできる。ＩＤをトランスペアレントに作成することだけで開始することができる。登録の状況のこの多様性により、登録エージェントは、信用が、当然であるべきところまで拡張されることを保証するために、登録の状況を記録すべきである。例えば、ＯＥＭ証明鍵をテストすることは、デバイスＲｉｖｅｔが適切なＴＥＥで動作中であることを大いにより確実にする。
【００７７】
図２Ｃに示される実施形態例では、デバイスアダプタ２２０のソフトウェアは、初回実行時、デバイスＴＥＥ２０８に公開／秘密鍵ペアを生成するように求める。公開鍵は、デバイス製造中に確立される証明鍵により署名される。この署名された公開鍵は、デバイス登録機関２２１に送信され、ＯＥＭ２２３を用いて検証される。登録は、デバイス操作者からの確認又は販売員が存在した状態での店頭での証明を含み得る。登録機関２２１は、以下のうちの１つ又は複数を含むデバイス測定レコードについてデバイスに尋ねる：ブートプロセスにより生成されるプラットフォーム構成レジスタ（ＰＣＲ）の複合値、ＢＩＯＳバージョン、ＯＳバージョン、ＧＰＳロケーション、ＢＩＯＳ識別子、ネットワークインタフェース識別子、ファイル数、ファイルサイズ、ディレクトリ、インデックス、及びデータ／サーチツリー構造等のデバイスについての属性、デバイスのプロセッサ識別番号、又は他のそのような情報。このデータは、デバイス秘密鍵により署名され、登録機関２２１により更に署名し得る。その結果生成されるデータセットは、将来の整合性チェックのゴールドリファレンスになる。ゴールドリファレンスを収集するに当たり、デバイス操作者からの確認を要求し得る。このデータセットは、Ｎａｍｅｃｏｉｎ等の公開暗号台帳に掲示される。公開記録は、登録機関の証明と共に登録時の暗号証明書を確立した。登録は、ロケーション、企業名、又はデバイスのメーカー／型番等の他の属性データを更に含み得る。登録は、登録時に登録機関の保険期間を記載した署名付き文書を参照し得る。デバイス登録機関２２１又は別の高信頼整合性サーバは、ブロックチェーンでの多重署名トランザクションでの署名者として参照することができるブロックチェーンアカウントキー（公開／秘密鍵ペア）を作成する。ブロックチェーントランザクションで表される署名者値は、登録機関２２１により連署されない限り、消費／転送することができない。トランザクションに署名するために、整合性サーバは、デバイスからの最近の測定値を予期する。この測定値は、デバイスアダプタによって直接要求されるか、又はデバイスとの持続的ソケット接続を通してサーバによりフェッチし得る。現在の測定値は、ブロックチェーン内のゴールド測定値と比較される。測定値が一致する場合、トランザクションは署名され、測定値は一致するが、最近の測定値が指定された時間窓よりも古い場合、要求は拒絶される。測定値が一致しない場合、要求は拒絶される。拒絶される場合、トランザクションは、拒絶をオーバーライドするように求めることができる別の手動署名者を用いて準備された可能性がある。測定値が一致しない場合、デバイスは、新しい測定値が収集される登録リニューアルを受け得る。測定値が一致する都度、成功カウントでデバイス登録レコードを更新することができる。整合性サーバには、他の一致する測定値又は属性に鑑みて問題が深刻であると見なされない場合、一致しない測定値を受け入れるポリシールールを与え得る。このシステムは、整合性サーバではなく、高信頼デバイスの集まりを用いて実施されて、測定値照合作業及びトランザクション署名作業を行い得る。このシステムは、Ｅｔｈｅｒｅｕｍにより開発中であるもの等のスマートブロックチェーンシステムに内蔵される特徴を使用して、トランザクション処理中、整合性測定値を直接照合し得る。
【００７８】
ブロックチェーンでのデバイスの出生証明書
実施形態は、ブロックチェーン通信ネットワークにおいてユーザデバイスの出生証明書を作成する方法であり得、この方法は、ユーザデバイスにロックされた公開／秘密鍵ペアを生成することにより、ユーザデバイスのデバイス識別情報を確立することと、デバイスの製造又は作成中、デバイスの実行環境の製造又は作成中、及び／又はデバイスのアプリケーションの製造又は作成中に確立される証明鍵によりデバイスの公開鍵を署名することと、デバイスから、生成された公開鍵を要求し、デバイスから取得することと、デバイスプラットフォーム構成レジスタ（ＰＣＲ）、ＢＩＯＳ、ＯＳ、及び／又はＧＰＳに関連する属性を含むデバイスのデバイス測定レコードを要求し取得することと、第三者及びデバイスによりデバイス測定レコードを証明することと、デバイスをブロックチェーンに登録することであって、証明されたデバイス測定レコードを公開暗号も特徴に掲示すること及びブロックチェーンでの多重署名トランザクションにおいて署名者として参照することができるブロックチェーンアカウントキーペアを作成することを含む、登録することとを含む。幾つかの実施形態では、方法は、デバイスを第三者に登録することが、デバイスとのペアリングしようとする第１のサービスプロバイダの要求時にあることを含み得る。幾つかの実施形態では、デバイスの登録は、サービスとして提供し得る。デバイスによるデバイス測定レコードの証明は、デバイス公開鍵によりレコードを署名することを含み得る。第三者によるデバイス測定レコードの証明は、サービスとして提供し得る。登録は、登録時、登録プロバイダの保険期間を記載した文書を署名することを更に含み得る。公開暗号も特徴はＮａｍｅｃｏｉｎであり得る。証明されたデバイス測定レコードは、サービスプロバイダとデバイスとの間のトランザクションの参照値を確立し得る。さらに、デバイスからデバイス属性のデバイス測定レコードを取得するには、デバイス操作者による確認が要求される。デバイス属性は、ロケーション、企業名、及び／又はデバイスのメーカー／型番を更に含み得る。さらに、サービスプロバイダとデバイスとの間のトランザクションは、デバイスがデバイス測定値を生成して提供するように求め得、デバイス測定値は、デバイスに確立された参照値と比較される。他の実施形態では、比較が一致する場合、トランザクションは許可され、又は比較が一致しない場合、トランザクションは拒絶され、比較が一致し、デバイスにより提供されるレコードが指定された時間窓よりも古い場合、トランザクションは拒絶され、又は比較が一致しない場合、デバイスは、出生証明書を再度作成するように求められる。さらに、デバイスをブロックチェーンに登録することはデバイス登録レコードを作成することを更に含み得、デバイス登録レコードは、比較が一致する場合、成功カウントで更新される。比較は、高信頼デバイスの集まりにより実施し得る。比較を実行するエンティティは、登録を実行するエンティティから独立し得る。
【００７９】
別の実施形態は、ブロックチェーン通信ネットワーク、ブロックチェーンネットワーク内のユーザデバイス、高信頼第三者、及びユーザデバイスの出生証明書を作成するシステムを備えるシステムであり得、上記システムは、ユーザデバイスにロックされた公開／秘密鍵を生成することにより、ユーザデバイスのデバイス識別情報を確立し、デバイスの製造又は作成中に確立されるエンドースメントキーを使用して、デバイスの公開鍵に署名し、デバイスの実行環境を製造又は作成し、及び／又はデバイスでのアプリケーションを製造又は作成し、生成された公開鍵を要求してデバイスから取得し、デバイスプラットフォーム構成レジスタ（ＰＣＲ）、ＢＩＯＳ、ＯＳ、及び／又はＧＰＳに関連する属性を含むデバイスのデバイス測定レコードを要求して取得し、第三者及びデバイスによりデバイス測定レコードを裏書きし、裏書きされたデバイス測定レコードを公開暗号も特徴に掲示し、ブロックチェーン上の複数の署名トランザクションでの署名者として参照することができるブロックチェーンアカウントキーペアを作成することで、デバイスをブロックチェーンに登録することにより、デバイスを高信頼第三者に登録するように構成される。
【００８０】
ブロックチェーンでのトランザクションを使用して、所有権を蓄積すること
ビットコインウォレットは、銀行口座と同様に機能し、ビットコインの受け取り及び格納並びにビットコインブロックチェーンでの電子トランザクションの形態での他の人への転送に使用することができる。ビットコインアドレスは、ユーザがビットコインを受け取れるようにする一意の識別子である。ビットコインは、ビットコインをビットコインアドレスに送信することにより転送される。ビットコインブロックチェーンでのトランザクションは通常、無料である。しかし、多数のアドレスを使用してビットコインを送受信するトランザクションでは通常、トランザクション料が発生する。ウォレットは秘密鍵を記憶し、それにより、ユーザはビットコインアドレスにアクセスすることができる。
【００８１】
ブロックチェーンでのトランザクションが所有権を蓄積又は保存するシステム及び方法を提供し得る。
【００８２】
ビットコイントランザクションを新しいライセンス権に蓄積するサービスを提供し得る。これは、スマートコントラクトを、権利に蓄積されるトランザクションチェーンを識別するトランザクションレコード内の属性情報と統合することにより、行われる。最終的に、この権利は元のウォレットアドレスにバインドされる。特定のアイテムが購入される都度、最新のトランザクションを現在のトランザクションの属性データの部分として組み込み、ブロックチェーンについての情報を読むことにより、トランザクションの蓄積を素早く効率的に確認することができることを保証する。ブロックチェーンで多くの小さなトランザクションを実行する動作は、アカウントを所有権又はリプライ権に容易に蓄積できるようにする。特定のレベルに達すると、蓄積は停止し、永続的権利がブロックチェーンに書き込まれる。
【００８３】
幾つかの実施形態は、電子トランザクションに携わる前に、デバイスの健康状態を保証するシステム及び方法を含み得る。
【００８４】
これは、スマートコントラクトを、権利に蓄積されるトランザクションチェーンを識別するトランザクションレコード内の属性情報と統合することにより行われる。最終的に、この権利は、元のウォレットアドレスにバインドされる。特定のアイテムが特定のアイテムが購入される都度、最新のトランザクションを現在のトランザクションの属性データの部分として組み込み、ブロックチェーンについての情報を読むことにより、トランザクションの蓄積を素早く効率的に確認することができることを保証する。ブロックチェーンで多くの小さなトランザクションを実行する動作は、アカウントを所有権又はリプライ権に容易に蓄積できるようにする。特定のレベルに達すると、蓄積は停止し、永続的権利がブロックチェーンに書き込まれる。
【００８５】
ビットコインアカウントに関連付けられたブロックチェーン通信ネットワーク内のトランザクションに付けられた価値を蓄積し得るシステムを提供し得、システムは、ブロックチェーン通信ネットワーク、ブロックチェーンネットワーク内の電子トランザクション、ビットコインアカウント、ビットコインアカウントに関連付けられたトランザクションレコード、ブロックチェーンネットワーク内の電子トランザクションを実行する一環として実施されるトランザクション問い合わせプロセスを備える。実施態様は、アカウントに関連付けられた前のトランザクションの存在についてトランザクションレコードをチェックすることと、前のトランザクションの存在に基づいて、前のトランザクションに付けられた蓄積価値を取得することと、取得した蓄積価値を増分することと、この増分された蓄積価値をトランザクションレコード内のトランザクションに付けることと、増分された蓄積価値をトランザクションに適用することとを更に含み得る。
【００８６】
トランザクション問い合わせプロセスの実施態様は、電子トランザクションの実行で発生する複数の料金をゼロに設定することと、増分された蓄積価値が所定の最大蓄積トランザクション価値に達するか、又はそれを超えることに基づいて、アカウントに関連付けられた権利の達成を示すこととを更に含み得る。
【００８７】
トランザクション問い合わせプロセスの実施態様は、アカウントに関連付けられた新しいトランザクションレコードを作成することと、達成された権利の指示を新たに作成されたトランザクションレコードに記憶することとを更に含み得る。
【００８８】
電子トランザクションには、特定のアイテムを関連付け得、トランザクションレコード内のトランザクションには、暗号保証を有するチェーンからのアカウントを関連付け得、トランザクション問い合わせプロセスの実施態様は、ユーザがアカウントに関連付けられたトランザクションレコードに記録された最新のトランザクションを問い合わせられるようにすることと、形成されたチェーンの暗号保証に基づいて、特定のアイテムの消費レベルを計算することとを更に含み得る。
【００８９】
蓄積された価値をトランザクションに適用することは、達成された権利に暗号鍵を関連付けることと、鍵をタンパー防止ストレージに記憶することと、達成された権利に関連付けられた、蓄積された価値に寄与する１組のトランザクションを取得することと、蓄積された価値をトランザクションに適用する前、１組のトランザクションを確認することとを含み得る。
【００９０】
幾つかのシステムでは、１組のトランザクションは、権利の達成に寄与するために、特定の時間期間以内に完了しなければならない。達成された権利は、特定の時間期間後に期限切れし、及び／又は権利の使用がないことに基づいて期限切れする。達成された権利は、複数の署名トランザクションの一環として使用されて、達成された権利の指示を必要とする追加のトランザクションの購入を可能にする。
【００９１】
幾つかのシステムでは、トランザクションには１つのアイテムが関連付けられ、トランザクションは、２つの達成された権利を含み、権利に関連付けられた蓄積価値は、暗号的に統合されて、単一の蓄積価値を生成する。
【００９２】
クラウドサービス及びピアサービスへの保証されたコンピュータ命令
現況水準のコンピューティングは、デバイスがＴｗｉｔｔｅｒのようなクラウドサービスに接続し、次に、後続データが正確であると仮定する認証モデルに基づく。暗号化された輸送が一般に使用され、保証モデルは、データを送信するコンピュータ全体を保証することに基づく。アンチウィルス及び整合性検証のような技術がホストシステムに提供される。複雑なシステムがＯＫであり、送られるクリティカルデータを信頼するという仮定がなされる。
【００９３】
認証は、両リモートソースからローカルデバイス内で形成される、これらの命令が正確であることを保証し、次に、これらの命令を処理のためにリモートサービスに送る、保証されたコンピュータ命令で拡張し得る。システムは、データをユーザ入力、デバイス入力、リモートシステム入力から収集し、次に、これが、実行が意図されるトランザクションであることをユーザが確認するセキュアメカニズムを提供し得る。クラウドサービスは、この保証された命令を受信し、トランザクションの要素が正確であることを確認する。確認プロセスは、トランザクションが処理に受け入れられる前に確認されるローカル又はリモートポリシーを課すこともできる。次に、その結果生成されたデータをログすることができる。
【００９４】
汎用計算デバイスでは、通常、認証を使用して、クリティカルサービスに接続する。強力な認証を用いる場合であっても、クラウドに送信された情報が、ユーザ意図する情報であることの保証はない。マルウェアは、データを改竄する多くの方法を見つけることができ、その結果、機密データを盗むか、又は損なうことになる。本発明の目的は、ローカルデータ及びリモートデータ両方の幾つかのソースを収集して、提供される情報が、意図されるデータであることを保証することである。特定のデータは、ローカルにマスキングして、プロセスが完了したが、詳細な秘密情報はマスキングされたままであることを保証することもできる。次に、サービスは、トランザクションが意図されたものであることを確認し、ユーザにより制御される幾つかの追加のステップを内部及び外部に組み込むことができる。これは、ロギング及び追加の確認を保証して、トランザクションが正確であることを保証することができる。これは、金融システムで使用することができるが、ドア施錠から医療装置までの興味のあることの制御に使用することもできる。
【００９５】
幾つかのシステムでは、別のコンピュータシステムへ送るセキュア命令を組み立てるセキュアサブシステムが使用される。セキュアサブシステムは、時刻、場所、識別情報、コンプライアンス、又は他のクリティカルデータ等の追加情報をローカル又はリモートに収集又は添付し、命令が署名され、次に送信される前、命令をセキュアに確認するメカニズムをユーザに提供する。
【００９６】
幾つかのシステムでは、保護された命令は、受信されると、処理前に確認される。確認は、ローカル又はリモートに行うことができ、追加のユーザ確認、ロギングシステムからの確認又は署名、他のクリティカルプロセスステップ、場所、又は時刻を含み得る。
【００９７】
幾つかのシステムでは、ローカルデータをトークン化して、プライバシーを保護することができる。例えば、ユーザの電話番号を使用して、ユーザが特定のプロバイダの顧客であり、優良状態にあると言うことができるが、渡されたものは優良状態ステータスのみであり、ユーザ名又は電話番号ではない。これは、プロバイダとローカルに連絡をとり、リモートに確認することができるプロバイダのトランザクション識別情報を確認データに包含させることにより行われる。
【００９８】
幾つかのシステムは、ローカル保証データを利用して、分離された実行環境が、トランザクション時に既知の状態にあることを証明することができることを保証し得る。
【００９９】
システムには、特定のトランザクションに必要とされるポリシーを提供することが暗号で保証される論理スクリプトを構成し得る。スクリプト検証は、トランザクション確認データの一部として包含し得る。
【０１００】
システムは、トランザクションをリリースする前のローカル又はリモート承認を含み得る（すなわち、クライアント側でのマルチ信号）。システムは、ローカルに保証されたリアルタイムデータを受信し、次に、命令がリアルタイム状態への差分であるように変更されて、例えば、ポンプ速度を上げる。幾つかのシステムでは、確認デバイスは、トランザクションが、最小数のパラメータを満たす既知のソースからのものであることを保証する。他のシステムでは、受信デバイスはさらに、ローカル又はリモート情報を確認する。
【０１０１】
本発明について本発明の実施形態例を参照して具体的に示し説明したが、添付の特許請求の範囲により包含される本発明の範囲から逸脱せずに、形態及び細部の様々な変更を行い得ることが当業者には理解されよう。
【０１０２】
＜付録＞
１．コンポーネント仕様
・コンポーネント仕様
・システム概説
・主義
・システムコンポーネント
・システム機能
２．システム概説
Ｒｉｖｅｔｚは、単純なＡＰＩを通して、ウェブ開発者及びアプリ開発者が強化された暗号及び識別鍵をエンドポイントデバイスで利用できるようにする。このシステムをサポートするために、識別鍵の登録並びに保証、バックアップ、及びデバイスグループ化に関する１組のデバイス管理サービスを管理する。
Ｒｉｖｅｔｚは、
・デバイスハードウェアで実装される一握りのプライバシー機能、識別機能、及び認可機能を露出するクライアントモジュール、
・デバイス及びサービスの登録及びペアリングを可能にするＲｉｖｅｔｚネットでホストされるウェブサービス、
・命令をサービスプロバイダからデバイスに通信するプロトコル
からなる。
Ｒｉｖｅｔｚネットは、デバイスの管理、バックアップ、保証等のこのフレームワークで構築されるサービスを更に提供する。
Ｒｉｖｅｔｚネットは、Ｒｉｖｅｔｚ秘密鍵を仕様して、デバイス及びサービスプロバイダの識別鍵を登録する、Ｐｙｔｈｏｎで書かれたＪＳＯＮ  ＡＰＩである。登録中、デバイス又はサービスプロバイダの公開鍵は、Ｒｉｖｅｔｚにより記録される。登録により、Ｒｉｖｅｔｚは、デバイスとサービスプロバイダとをペアリングすることができる。ペアリングの結果として、デバイスは、Ｒｉｖｅｔｚにより署名されたサービス公開鍵を有し、したがって、サービスプロバイダ命令に応答することができる。
Ｒｉｖｅｔｚプロトコルは、デバイスが受け入れるために適用しなければならない命令及び署名／暗号化の構造を指定する。命令自体は、命令コード、バージョンデータ、及びペイロードを含むＣ構造体として準備される。構造体全体は、サービスプロバイダキーにより署名され、デバイスローカルコマンドを呼び出すことによりＲｉｖｅｔｚに送られる。
Ｒｉｖｅｔｚは、セキュアソケットを使用して、全てのリベット登録したデバイスとの永続的な接続を維持し得る。このチャネルは、ペアリング及び他の管理機能に使用される。
Ｒｉｖｅｔｚは、ライブラリコードをサービスプロバイダに提供して、命令の構築及び署名を簡易化する。このライブラリはまず、Ｐｙｔｈｏｎで提供されることになる。他の言語も続くであろう。
３．主義
・ウェブコミュニティにツールを提供する−顧客は、高信頼性デバイス認証及び本物の暗号を必要とする膨大な数のウェブサービス及びアプリである。大方、このコミュニティは「署名」及び「暗号化」を理解し、いかに行うかを指定するように求められると路頭に迷う。Ｒｉｖｅｔｚは彼らの代わりに決定する。
・Ｒｉｖｅｔｚは障害点であることはできない−Ｒｉｖｅｔｚは、あなたがあなたの信頼を移す別のシステムであることはできない。Ｒｉｖｅｔｚは、登録、ペアリング、及び管理のサービス（及びＲｉｖｅｔ自体）で価値ある役割を果たすが、あらゆるトランザクションでＲｉｖｅｔｚのサーバに依存すべきではない。
・Ｒｉｖｅｔｚはユーザを追跡しない−Ｒｉｖｅｔｚのシステムは、デバイスを管理するように設計される。Ｒｉｖｅｔｚは、デバイスを操作するユーザを識別又は追跡しない。
・Ｒｉｖｅｔｚは、ハードウェアのみを信用する−Ｒｉｖｅｔｚは、ハードウェアにより裏付けられた暗号プリミティブのみを信用する。利用できない場合、Ｒｉｖｅｔｚは弱いルートを「強化」しようとせず、むしろ、エンドポイントの信用レベルについて正直である。
４．システムコンポーネント
本文書は、Ｒｉｖｅｔｚシステムを構成する離散コンポーネントに分割される。各コンポーネントで、コンポーネントが露出する機能、管理するデータ、及びその実現化の背後にあるインプリメンテーション判断について説明する。
Ｒｉｖｅｔｚの意図は、ミッションクリティカルデータの維持ではなく、むしろ、サービスプロバイダとデバイスとの間にシームレスでありながら、それでもなお非常にセキュアな接続のプラットフォームを提供することである。一端部には、デバイスの命令を準備するＲｉｖｅｔｚエンコーダがあり、他端部には、その命令に対して動作することができるＴＥＥアプレットであるデバイスＲｉｖｅｔがある。Ｒｉｖｅｔｚプロトコルは、これらの命令及びリプライがいかに構築されるかを定義する。
【０１０３】
【表１】
2018516026.tif 000003
【０１０４】
５．システム機能
Ｒｉｖｅｔｚ使用事例を参照して下さい。
６．リングマネージャ
リングマネージャは、デバイスの集まり（又はリング）を管理する、エンドユーザに提供されるサービスである。デバイスは単一の識別情報にグループ化し得、互いのバックアップ及び署名に使用し得る。リングに他のリングを関連付けて、デバイスネットワークを作成し得る。
・リングマネージャ
・コンポーネントコンテキスト
・コンポーネント図
・コンポーネント分解
・エンティティの責任
・インタフェース仕様
７．コンポーネントコンテキスト
（パッケージ、パターン、フレームワーク、前提条件、使用法）
８．コンポーネント図
９．コンポーネント分解
【０１０５】
【表２】
2018516026.tif 000004
【０１０６】
１０．エンティティの責任
（このコンポーネントにより制御されるビジネスエンティティ又は技術的エンティティ）
１１．インタフェース仕様
１２．Ｒｉｖｅｔｚネット
Ｒｉｖｅｔｚネットは、デバイス及びサービスプロバイダを裏書きされた関係にペアリングする、Ｒｉｖｅｔｚにより運営されるサービスである。
当初、Ｒｉｖｅｔｚは、性能及び透明性のためにデバイス登録をＮａｍｅｃｏｉｎに配置することを意図したが、プライバシー考慮事項により、差し当たり、この計画は延期された。デバイスについての保証データを収集開始するとき、この判断は再評価される（詳細についてはヒストリーのトピックを参照のこと）。
・Ｒｉｖｅｔｚネット
・コンポーネントコンテキスト
・ウェブＡＰＩ
・秘密鍵
・エンティティの責任
・インタフェース仕様
・デバイスの登録
・サービスプロバイダの登録
・デバイスＩＤの取得
・デバイスのペアリング
・使用事例参照
１３．コンポーネントコンテキスト
Ｒｉｖｅｔｚネットは、デバイスに登録される最初のサービスプロバイダであり、そのデバイスと追加のサービスプロバイダをペアリングすることができるという特別な機能を有する。
１４．ウェブＡＰＩ
ウェブＡＰＩとの全ての通信は、認証される必要がある。Ｒｉｖｅｔｚは、ＡＰＩキー又はできるならばＳＳＬキースワップを使用することができる。全ての要求が署名されるように求めることができるが、システムを使いやすく保つことを認識する必要がある。
１５．秘密鍵
デバイスとのＲｉｖｅｔｚ関係は、秘密鍵で命令を署名可能なことに依存する。当然ながら、Ｒｉｖｅｔｚがこの鍵を保護することが最重要である。Ｒｉｖｅｔｚは、この鍵をＨＳＭに入れるように努めるべきである。
１６．エンティティの責任
（このコンポーネントにより制御されるビジネスエンティティ又は技術的エンティティ）
【０１０７】
【表３】
2018516026.tif 000005
【０１０８】
１７．インタフェース仕様
１８．デバイスの登録
一意の識別子及び公開鍵を所与として、ブロックチェーンにおいてこのバインドのレコードを購入する。購入は、Ｒｉｖｅｔｚコインアカウントを用いて行われ、したがって、登録を裏書きする。理想的には、Ｒｉｖｅｔｚ署名は、デバイスがＯＥＭからのエンドースメントキーを供給することができる場合のみ、適用される。
１９．サービスプロバイダの登録
所与の組織にサービスプロバイダＩＤを作成する。登録は、ＳＰがＲｉｖｅｔｚエンコーダの実装をホストするＵＲＬ及び通信を確認する公開識別情報も含まなければならない。
２０．デバイスＩＤの取得
デバイスポインタを所与として、要求側サービスプロバイダに既知のデバイスＩＤを返す。
【０１０９】
【表４】
2018516026.tif 000006
【０１１０】
リターン：デバイスＩＤ
２１．デバイスのペアリング
サービスプロバイダが命令を送信できるようになるには、先に、サービスプロバイダのＩＤ及び公開鍵をターゲットデバイスに登録しなければならない。これにより、デバイスは、命令を実行する前に命令の出所を確認することができる。デバイスのペアリングは、デバイスで新しい識別鍵を自動的に作成する。
【０１１１】
【表５】
2018516026.tif 000007
【０１１２】
２２．使用事例参照
・デバイスをＲｉｖｅｔｚに登録−Ｒｉｖｅｔが何かを行うことが可能になるには、先に、Ｒｉｖｅｔｚネットに登録する必要がある。登録により、一意の識別鍵が生成される。登録はエンドースメントに頼る。
・デバイスをサービスプロバイダに登録−サービスプロバイダは、デバイスがいかなる要求にも応答する前、サービスプロバイダＩＤ及び公開識別鍵をそのデバイスに登録する必要がある。…でさえ、…。
・サービスプロバイダをＲｉｖｅｔｚに登録−Ｒｉｖｅｔｚシステムにコーディングしようとする者は誰でも、サービスプロバイダとして登録する必要がある。初期登録は、Ｒｉｖｅｔｚネット（ｈｔｔｐ：／／ｒｉｖｅｔｚ…）での書式記入のように簡単である。
ウェブホーム＞頭字語表＞ＨＳＭ
ハードウェアセキュリティモデルは、強力な認証のためにデジタル鍵を保護し管理し、暗号処理を提供する物理的な計算デバイスである。
１．デバイスＩＤ
Ｒｉｖｅｔｚネット又は他の登録エージェントによりデバイスに割り当てられる、ＵＵＩＤ内の一意の識別子。
２．デバイスポインタ
任意のローカルアプリケーションにより要求することができるデバイスへの一時的なポインタ。デバイスポインタは、Ｒｉｖｅｔｚネットへの現在のソケットセッションを識別することができ、したがって、デバイス通信チャネルの確立及び永続的な識別子であるデバイスＩＤの検索に使用することができる。
データ型：
３．Ｒｉｖｅｔｚ識別鍵
Ｒｉｖｅｔｚ  Ｃｏｒｐのエンドースメントを表すために生成される一意の公開／秘密鍵ペア。この鍵ペアは頻繁にローテーションされ、ハードウェアにおいて保護されるべきである。理想的には、Ｒｉｖｅｔｚのプロトコルは、鍵ペアが盗まれた場合であっても、システムが過度に損なわれないようなものである。
４．デバイス登録レコード
デバイス登録のルートは、一意の匿名識別子、登録日、デバイスハードウェアに保持された秘密鍵とペアになった公開鍵、及び登録エージェント（ここではＲｉｖｅｔｚであると仮定する）からの裏書き署名を含む。
５．ディスパッチＩＤ
Ｒｉｖｅｔｚネットから送信された命令レコードをＲｉｖｅｔアダプタにより返された応答レコードと照合するのに使用される一意の識別子
６．Ｒｉｖｅｔｚコインアカウント
Ｒｉｖｅｔｚネットは、ブロックチェーン基盤（現在、Ｎａｍｅｃｏｉｎ）を使用して、登録を記憶、スタンプ付与、及び公開する。これは、ブロックチェーン内で名前／値ペアレコードを購入することにより機能し、したがって、起点となるアカウントを有さなければならない。Ｒｉｖｅｔｚ制御のアカウントがレコードを購入したということは、エンドースメントとして解釈される。
７．サービスプロバイダＩＤ
Ｒｉｖｅｔｚネットによりサービスプロバイダに割り当てられる一意の識別子。
８．サービスプロバイダ登録レコード
命令をＲｉｖｅｔ登録デバイスに送信したい各登録サービスプロバイダに作成されるレコード。これは、サービスプロバイダの名称、登録日、公開鍵、及び裏書き署名（Ｒｉｖｅｔｚによる）を含む。
９．Ｒｉｖｅｔｚエンコーダ
Ｒｉｖｅｔｚエンコーダは、命令レコードを生成し、応答レコードを処理する。これらは、デバイスＲｉｖｅｔ（ｔｒｕｓｔｌｅｔ）に定義され、デバイスＲｉｖｅｔ（ｔｒｕｓｔｌｅｔ）により解釈されるメッセージデータ構造体である。
ａ．コンポーネントコンテキスト
Ｒｉｖｅｔｚエンコーダは、Ｒｉｖｅｔｚのパートナーによりホストされるように書かれたソフトウェアである。
Ｒｉｖｅｔｚエンコーダは、公開オープンソースとして配布される。
ｂ．エンティティの責任
【０１１３】
【表６】
2018516026.tif 000008
【０１１４】
ｃ．インタフェース仕様
ｄ．インプリメンテーション
ｅ．使用事例参照
何かを暗号化−Ｒｉｖｅｔｚは、テキスト又は画像を暗号化するメカニズムを提供するが、パートナーが、メッセージングアプリケーションであるか否かに関係なく、サービスのインタフェースを提案すると予期する。
１０．サービスプロバイダ識別鍵
サービスプロバイダ識別の秘密部分は、命令に署名するためにＲｉｖｅｔｚエンコーダにより使用される。公開部分は、Ｒｉｖｅｔｚ及びペアになったデバイスに提供される。
１１．デバイスＲｉｖｅｔ
物理的作業とデジタル作業とにバインドを実施するＲｉｖｅｔｚ  ＴＥＥアプレット。デバイスＲｉｖｅｔは、識別、トランザクション、及び保証の特徴をハードウェアにロックし、Ｒｉｖｅｔｚの技術的提供の基本をなす。
・デバイスＲｉｖｅｔ
・コンポーネントコンテキスト
・コンポーネント説明
・エンティティの責任
・インタフェース仕様
・デバイスの登録
・鍵の生成
・鍵を用いての暗号化
・鍵を用いての復号化
・命令の処理
・使用事例参照
・備考
ａ．コンポーネントコンテキスト
現在、デバイスＲｉｖｅｔインプリメンテーションをホストする２つのターゲットプラットフォームを有する：ＡｎｄｒｏｉｄでのＴｒｕｓｔｏｎｉｃ及びＷｉｎｄｏｗｓ  ＰＣでのＩｎｔｅｌ  ＭＥ。両環境とも、限られた処理を有し、セキュリティ及びリソース使用のために単純であるように特に設計されている。
Ｔｒｕｓｔｏｎｉｃの高信頼アプリ（ＴＡ：Ｔｒｕｏｓｕｔｅｄ  Ａｐｐ）は、ＣでＡｎｄｒｏｉｄ  ＮＤＫコンパイラを用いて実装される。ＴＡとのインタフェースは、共有メモリバッファを使用して行われる。コマンドはメモリブロックにパックされ、通知はＴｒｕｓｔｏｎｉｃコントローラに送信されて、ＴＡにロードしＴＡを実行する。通知は同期的である。ホストアプリ（通常のＡｎｄｒｏｉｄアプリ）は応答を待つ。高信頼アプリは、データをホストに記憶することが予期されるが、Ｔｒｕｓｔｏｎｉｃコントローラはセキュアラッパーを提供し、それにより、データは、ＴＥＥで実行されるときのみ開くことができる。
Ｉｎｔｅｌインプリメンテーションの場合、アプリはＪａｖａ（登録商標）で書かれ、Ｉｎｔｅｌのマスターキーで署名される。このために、我々はＤＡＬ  ＳＤＫをＩｎｔｅｌから取得することができ、１２月に、我々の努力から、積極的なサポートを示し始めた。
ｂ．コンポーネント説明
インプリメンテーションは、プラットフォームにわたりかなり異なり、Ｒｉｖｅｔアダプタへの統合は、デバイス固有の方法を更に生じさせる。しかし、論理的インプリメンテーションは、同じであることが意図され、入力データ構造は、必然的に同じである。Ｒｉｖｅｔｚシステムの残りの部分は、全て同じインタフェースをサポートするものとしてデバイスを扱いたいが、デバイスによってはより多数又は少数の特徴セットを有するものがある。
デバイスＲｉｖｅｔ（Ｔｒｕｓｔｌｅｔ）には３つの主要機能エリアがある。
・デバイスの登録−これは、デバイスＲｉｖｅｔが登録エージェント（Ｒｉｖｅｔｚネット）と身元確認を確立するプロセスである。
・命令の処理−所与の命令を実行する。これは、サービスプロバイダを起点とする署名付きデータ構造である。
・セキュリティプリミティブ−ローカルアプリケーション使用のために露出される単純なセキュリティ機能。
ｃ．エンティティの責任
【０１１５】
【表７】
2018516026.tif 000009
【０１１６】
ｄ．インタフェース仕様
ｉ．デバイスの登録
ｉｉ．鍵の生成
ｉｉｉ．鍵を用いての暗号化
ＴＥＥアダプタは、サービスプロバイダレコード内で名前付き暗号鍵を検索する。
ｉｖ．鍵を用いての復号化
ｖ．命令の処理
ｅ．使用事例参照
・鍵の生成−署名及び暗号化のいずれかのために、デバイスＲｉｖｅｔにおいて鍵ペアを作成する。アクター：サービスプロバイダ、説明：Ｒｉｖｅｔｚの主な目的は、…をセキュア化し適用することである。
・ローカルユーザの作成−サービスプロバイダの認可が与えられない場合、Ｒｉｖｅｔの使用を認可することができるローカルエンティティを確立する。アクター：プロダクトアクターからアクターを選択／作成する。
・何かの暗号化−Ｒｉｖｅｔｚは、テキスト又は画像を暗号化するメカニズムを提供するが、パートナーが、メッセージングアプリケーションであるか否かに関係なく、サービスのインタフェースを提案すると予期する…。
・デバイスのＲｉｖｅｔｚへの登録−Ｒｉｖｅｔが何かを行うことができるようになるには、先にＲｉｖｅｔｚネットに登録する必要がある。登録により、一意の識別鍵が生成される。登録はエンドースメントに頼る…。
１２．命令ペイロード
命令レコードによりデバイスＲｉｖｅｔに運ばれるデータブロブ。命令ペイロードは、命令タイプに従って解釈される。
１３．命令レコード
Ｒｉｖｅｔｚ命令は、識別されたデバイスＲｉｖｅｔにより処理されるように向けられたデータパッケージである。コマンド、ペイロード、及びデバイスにＲｉｖｅｔｚ  ＴＥＥアプレットで何らかの動作を実行させるために必要な署名を含む。
大半の命令は、応答レコードの構築及びリターンを生じさせる。これは、Ｒｉｖｅｔｚディスパッチによりサービスプロバイダに送られる。
ａ．データ構造
【０１１７】
【表８】
2018516026.tif 000010
【０１１８】
ｂ．命令タイプ
【０１１９】
【表９】
2018516026.tif 000011
【０１２０】
【表１０】
2018516026.tif 000012
【０１２１】
【表１１】
2018516026.tif 000013
【０１２２】
１４．命令タイプ
命令レコードのタイプを示す一定値。これは、命令ペイロードがいかに解釈されるべきかを決める。
命令タイプは、命令レコードにおいて説明される。
１５．命令署名
デバイスＲｉｖｅｔを宛先としたあらゆる命令は、発行側サービスプロバイダにより署名されなければならない。サービスプロバイダは、Ｒｉｖｅｔｚネットに登録していなければならない。登録されたサービスプロバイダは、公開鍵をＲｉｖｅｔｚにより裏書きさせ、全ての登録デバイスに配信させる。
１６．アカウントキー
アカウントキーは、デバイスＲｉｖｅｔによりセキュアに保持される。アカウントキーは、高信頼実行環境の範囲から決して出ない。アカウントキーは、デバイスにバインドされたセキュアラッパー内で生成され、記憶され、適用される。
１７．アカウントＰｉｎ
アカウントキーは、アカウントキーが任意のトランザクションで適用される前、ユーザの同意をテストするのに使用されるアカウントＰｉｎにバインドし得る。
１８．応答レコード
命令レコードの処理から生じるリターンステータス及びペイロード。
ａ．ステータスコード
【０１２３】
【表１２】
2018516026.tif 000014
【０１２４】
１９．Ｒｉｖｅｔアダプタ
Ｒｉｖｅｔアダプタは、ＴＥＥに施錠されたデバイスＲｉｖｅｔと、パートナーアプリ及びオンラインサービスの外部世界との間のインタフェースである。実施態様では、１つ又は複数の多様な形態で現れる。本発明は、デバイスにわたり同じ基本機能を提示するように努力するが、ハードウェアサポート及びＯＳアーキテクチャにより、何が実際に可能か及びこれらの特徴がいかに提示されるかが決まることになる。
・Ｒｉｖｅｔアダプタ
・図
・サブコンポーネント
・インプリメンテーション
・使用事例参照
ａ．図
ｂ．サブコンポーネント
Ｒｉｖｅｔアダプタは、外向きインタフェース及び内向きインタフェースで構成される。内向きインタフェースであるＴＥＥアダプタは、ｔｒｕｓｔｌｅｔ（デバイスＲｉｖｅｔ）とのプロプライエタリ通信を扱う。ホストアダプタは、サービスを第三者アプリケーションに露出するために提供される。
インタフェース及びインプリメンテーションの詳細については、個々のサブコンポーネントを参照して下さい。
ホストアダプタ−−ホストアダプタは、ブラウザ又はシステムサービス等の異なるローカルコンテキストを通してＲｉｖｅｔアダプタのインタフェースを提示する。多様なコンテキストの複数の実現が予期されるが、まず、これはＡｎｄｒｏｉｄサービス及びＷｉｎｄｏｗｓ  ＣＯＭプロセスである。
ソケットアダプタ−−クライアント環境をＲｉｖｅｔｚネットに接続する。
ＴＥＥアダプタ−−このコンポーネントは、コマンドをＴｒｕｓｔｏｎｉｃ又はＩｎｔｅｌ  ＭＥで実行中のｔｒｕｓｔｌｅｔにパイピングするプロプライエタリグルーである。
ｃ．インプリメンテーション
Ａｎｄｒｏｉｄインプリメンテーションでは、ＲｉｖｅｔアダプタはＡｎｄｒｏｉｄ  ＮＤＫサービスアプリとして現れる。ブート時に起動するように構成される。Ｒｉｖｅｔアダプタは、Ｔｒｕｓｔｌｅｔにパイピングされるメッセージバッファを準備し、次に、応答イベントの通知を同期して待つ。Ａｎｄｒｏｉｄアプリの現れは、第三者がトリガーする一連の意図を提示する。アプリ、ＮＤＫバイナリ、及びＴｒｕｓｔｌｅｔは全て、配布のために１つのＡＰＫにパッケージングされる。
ｄ．使用事例参照
・ローカルユーザの作成−サービスプロバイダの認可が与えられない場合、Ｒｉｖｅｔの使用を認可することができるローカルエンティティを確立する。アクター：プロダクトアクターからアクターを選択／作成する。
・何かの暗号化−Ｒｉｖｅｔｚは、テキスト又は画像を暗号化するメカニズムを提供するが、パートナーが、メッセージングアプリケーションであるか否かに関係なく、サービスのインタフェースを提案すると予期する…。
・デバイスのＲｉｖｅｔｚへの登録−Ｒｉｖｅｔが何かを行うことができるようになるには、先にＲｉｖｅｔｚネットに登録する必要がある。登録により、一意の識別鍵が生成される。登録はエンドースメントに頼る…。
・デバイスのサービスプロバイダへの登録−サービスプロバイダは、デバイスがいかなる要求にも応答する前、サービスプロバイダＩＤ及び公開識別鍵をそのデバイスに登録する必要がある。…でさえ、…。
２０．ホストアダプタ
ホストアダプタは、ブラウザ又はシステムサービス等の異なるローカルコンテキストを通してＲｉｖｅｔアダプタのインタフェースを提示する。多様なコンテキストの複数の実現が予期されるが、まず、これはＡｎｄｒｏｉｄサービス及びＷｉｎｄｏｗｓ  ＣＯＭプロセスである。
ホストアダプタは主に、ＴＥＥアダプタをホスト環境から分離するためにそこにある。しかし、ホストマシンでは最小ＵＩプレゼンスを有する。「Ａｂｏｕｔ」ページを提示し、エンドユーザがアプリリスト内で識別することができる項目である。
最終的に、ホストアダプタは、バックアップ又は結合等のリングマネージャサービスを提示する。
・ホストアダプタ
・インタフェース
・ポインタの取得
・ハッシュの取得
・実行
・暗号化
・復号化
・Ａｎｄｒｏｉｄインプリメンテーション
・Ａｎｄｒｏｉｄインテントドキュメンテーション
・Ｗｉｎｄｏｗｓインプリメンテーション
・使用事例参照
ａ．インタフェース
ホストアダプタは、潜在的に厳しい環境で動作する。したがって、通常、クライアントが不正アクセスされていないことの限られた保証を有する。したがって、ホストアダプタの役割は主に、デバイスＲｉｖｅｔへの容易なアクセスを促進することである。デバイスＲｉｖｅｔを対象としたサービスプロバイダからの命令は、サービスプロバイダにより署名され、次に、実行命令を通してＴＥＥアダプタ及びデバイスＲｉｖｅｔに渡される。ローカルサービスプロバイダの役割を使用することが意図される命令は、ホストアダプタにより構築し得、次に、ＴＥＥアダプタ又は他のエンティティにより署名され、それから、命令はデバイスＲｉｖｅｔに渡される。
暗号化及び復号化等の特定のローカルサービスは、ローカルサービスプロバイダの役割を使用して呼び出すことが許され、ホストアダプタは、顧客の便宜を図り、これらのサービスへのインタフェースをローカルに提供する。これらは、特定のプラットフォームでは非許可であり得る。
ｉ．ポイントの取得
永続的なデバイス識別子を不正使用から保護したい。検証されたサービスプロバイダは、「これは何のデバイスですか」と尋ねる必要がある。不正アプリが同じ質問で有用な応答を得ることができないように、Ｒｉｖｅｔｚはデバイスポインタを使用する。デバイスポインタは、Ｒｉｖｅｔｚネットとのソケット接続中のみ有効な識別子である。手にしたデバイスポインタを用いて、サービスプロバイダは、永続的なデバイスＩＤについて又はペアリング要求するようにＲｉｖｅｔｚネットに直接問い合わせることができる。ソケットアダプタは、Ｒｉｖｅｔｚネットに接続するときは常に、デバイスポインタをメモリに記憶する。
【０１２５】
【表１３】
2018516026.tif 000015
【０１２６】
リターン：デバイスポインタ−−任意のローカルアプリケーションにより要求することができるデバイスへの一時的なポインタ。デバイスポインタは、Ｒｉｖｅｔｚネットへの現在のソケットセッションを識別することができ、したがって、デバイス通信チャネルの確立及び永続的な識別子であるデバイスＩＤの検索に使用することができる。
ｉｉ．ハッシュの取得
署名命令及び暗号化命令の場合、サービスプロバイダは、オブジェクトのハッシュに署名する必要がある。
【０１２７】
【表１４】
2018516026.tif 000016
【０１２８】
リターン：署名付きハッシュ−
ｉｉｉ．実行
命令レコードをＴＥＥアダプタに渡し、応答レコードを返す。Ｒｉｖｅｔは、命令を処理するために、平文でサービスプロバイダＩＤを渡す必要がある所与のコンテキストを必要とする。
【０１２９】
【表１５】
2018516026.tif 000017
【０１３０】
リターン：応答レコード−−命令レコードの処理から生じるリターンステータス及びペイロード。
ｉｖ．暗号化
【０１３１】
【表１６】
2018516026.tif 000018
【０１３２】
リターン：データブロブ−−任意の長さのバイトの未指定集まりとしてのデータ
ｖ．復号化
【０１３３】
【表１７】
2018516026.tif 000019
【０１３４】
リターン：データブロブ−−任意の長さのバイトの未指定集まりとしてのデータ
ｂ．Ａｎｄｒｏｉｄインプリメンテーション
ホストアダプタは、ＡｎｄｒｏｉｄのＲｉｖｅｔｚクライアントの標準Ｊａｖａ（登録商標）部分である。クロスアプリ通信の標準メカニズムであるＩｎｔｅｎｔｓを通してインタフェースを露出する。例えば：
【０１３５】
【数１】
2018516026.tif 000020
【０１３６】
各動作は、ｃｏｍ．ｒｉｖｅｔｚ．ＲｉｖｅｔＡｃｔｉｏｎから継承される別個のクラスとして定義される。例えば：
【０１３７】
【数２】
2018516026.tif 000021
【０１３８】
ＴＥＥアダプタは、命令をデバイスＲｉｖｅｔに渡すＪＮＩ（Ｊａｖａ（登録商標）ネイティブインタフェース）コードを定義する。
ｉ．Ａｎｄｒｏｉｄインテントドキュメンテーション
これらの定義は、一般公開のためにＳＤＫページに入る。Ｒｉｖｅｔｚ  Ａｎｄｒｏｉｄクライアント参照のこと。
【０１３９】
【表１８】
2018516026.tif 000022
【０１４０】
【表１９】
2018516026.tif 000023
【０１４１】
ｃ．Ｗｉｎｄｏｗｓインプリメンテーション
ＴＢＤ
ｄ．使用事例参照
ローカルユーザの作成−サービスプロバイダの認可が与えられない場合、Ｒｉｖｅｔの使用を認可することができるローカルエンティティを確立する。アクター：プロダクトアクターからアクターを選択／作成する…。
・何かの暗号化−Ｒｉｖｅｔｚは、テキスト又は画像を暗号化するメカニズムを提供するが、パートナーが、メッセージングアプリケーションであるか否かに関係なく、サービスのインタフェースを提案すると予期する…。
２１．ソケットアダプタ
クライアント環境をＲｉｖｅｔｚネットに接続する。
・ソケットアダプタ
・コンポーネントコンテキスト
・エンティティの責任
・インタフェース仕様
・接続
・切断
・ポインタの取得
・命令
・使用事例参照
ａ．コンポーネントコンテキスト
ｂ．エンティティの責任
【０１４２】
【表２０】
2018516026.tif 000024
【０１４３】
ｃ．インタフェース仕様
ｉ．接続
サーバとの接続を開く。サーバは、このセッションに割り当てられたデバイスポインタを返す。接続は、Ｒｉｖｅｔアダプタが開始されるとき、呼び出される。
引数：なし
リターン：なし
ｉｉ．切断
サーバから切断し、デバイスポインタを破棄する。
引数：なし
リターン：なし
ｉｉｉ．ポインタの取得
現在のデバイスポインタ又はセッションがない場合にはヌルを返す。
引数：なし
リターン：デバイスポインタ−−任意のローカルアプリケーションにより要求することができるデバイスへの一時的なポインタ。デバイスポインタは、Ｒｉｖｅｔｚネットへの現在のソケットセッションを識別することができ、したがって、デバイス通信チャネルの確立及び永続的な識別子であるデバイスＩＤの検索に使用することができる。
ｉｖ．命令
命令レコードをＲｉｖｅｔｚネットから受信し、Ｒｉｖｅｔにそれを渡し応答レコードを非同期で掲示する。あらゆる命令は一意のディスパッチＩＤと共に受信され、ＲｉｖｅｔｚネットはディスパッチＩＤを使用して、命令を応答に照合する。なお、幾つかの命令は、ＴＵＩを通してのユーザ対話を含み得、したがって、応答が掲示される前に相当な経過時間が発生し得る。
【０１４４】
【表２１】
2018516026.tif 000025
【０１４５】
ｄ．使用事例参照
２２．ＴＥＥアダプタ
このコンポーネントは、Ｔｒｕｓｔｏｎｉｃ又はＩｎｔｅｌ  ＭＥで実行されるＲｉｖｅｔｚのｔｒｕｓｔｌｅｔにコマンドをパイピングするプロプライエタリグルーである。
ａ．設計概念
Ｔｒｕｓｔｏｎｉｃ及びＩｎｔｅｌ  ＭＥ環境は、同じ基本アーキテクチャに従う：ホストシステムが、メモリバッファへのデータを直列化し、次に、ＴＥＥをトリガーして、処理する。これは、ブロックキング（同期）要求である。制御は、ＴＥＥが、恐らくは応答データをメモリバッファに書き込んだ後、終了するとき、返される。
ＲｉｖｅｔｚのＴＥＥコードは、２つ以上のことを行うため、実行する手順を識別するために、データ構造の一部が渡される。そしてこれは、データ構造の残りの部分がいかに解釈されるかを決める。
同様に、実行中の命令は、一緒に作業する鍵を提供するコンテキストデータを必要とする。ＴＥＥはネイティブの永続的メモリを有さないため、データレコードは、ＴＥＥにより暗号化され、記憶し、必要時に返すために、ＴＥＥアダプタに与えられる。レコードは、サービスプロバイダ毎に記憶され、所与のサービスプロバイダに一意のデバイス識別情報、ウォレット、及び暗号鍵を含む。
ｂ．コンポーネント図
全ての作業は、パラメータ及びストレージからのデータが、共有メモリを介してＴＥＥ環境に渡される構造体内に直列化されるＴＥＥローダで起こる。
ｉ．ＴＥＥ通信レコード
あらゆる要求について、ＴＥＥアダプタは、入力をとり、ＴＥＥ用のデータ構造をパッケージングし、高信頼アプレット環境で実行を呼び出す。実行が完了すると、共有メモリは、応答レコードとして配役を変える。いかなるリターンデータも、元の呼び出し関数に向けて準備され、サービスプロバイダレコードがディスクに記憶される。
ｃ．エンティティの責任
【０１４６】
【表２２】
2018516026.tif 000026
【０１４７】
ｄ．インタフェース仕様
ｉ．命令の処理
ソケットアダプタが命令をＲｉｖｅｔｚエンコーダから受信するとき、ソケットアダプタにより呼び出される。命令は、パーズなしでＴＥＥにより直列処理されることが意味されるパッケージブロブである。
【０１４８】
【表２３】
2018516026.tif 000027
【０１４９】
Ｔｅｅアダプタは、サービスプロバイダレコードをロードし、命令レコードと共にメモリバッファに直列化し、ＴＥＥをトリガーして処理する。ＴＥＥが終了すると、サービスプロバイダレコードはディスクに再び書き込まれ、応答ブロブはソケットアダプタに返される。
ｉｉ．暗号化
名前付き鍵を使用して暗号化するローカル要求。暗号鍵は、サービスプロバイダレコードに属し、鍵作成命令を使用して作成される。
【０１５０】
【表２４】
2018516026.tif 000028
【０１５１】
ｉｉｉ．復号化
名前付き鍵を使用して復号化するローカル要求。
【０１５２】
【表２５】
2018516026.tif 000029
【０１５３】
ｅ．Ａｎｄｒｏｉｄインプリメンテーション
Ａｎｄｒｏｉｄインプリメンテーションは、Ａｎｄｒｏｉｄ  ＮＤＫにより実装されるＪａｖａ（登録商標）ネイティブインタフェース（ＪＮＩ）を使用する。
ＴｒｕｓｔｏｎｉｃアプレットであるデバイスＲｉｖｅｔと通信するために、Ａｎｄｒｏｉｄ  ＪＮＩコードを使用する必要がある。Ｒｉｖｅｔアクションで発せられる各インテントは、Ｃ＋＋実装環境に入り込ませる、定義された対応するＪＮＩ関数を有する。
【０１５４】
【数３】
2018516026.tif 000030
【０１５５】
ｆ．使用事例参照
２３．サービスプロバイダレコード
命令を処理するとき、ＴＥＥに提供されるサービスプロバイダコンテキスト情報である。
ａ．構造
このトピックは、概念を掘りさげるだけのためのものである。
【０１５６】
【表２６】
2018516026.tif 000031
【０１５７】
ｂ．実現化
これは、ＴＥＥメモリバッファ内外に容易に直列化することができるバイナリフラットファイルであることが予期される。
詳細及びデータ型はＧｉｔＨｕｂにおいてソースコードで定義され維持される。ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ｒｉｖｅｔｚ／ＲｉｖｅｔｚＥｎｃｏｄｅｒ／ｂｌｏｂ／ｍａｓｔｅｒ／ｒｉｖ＿ｔｙｐｅｓ．ｈを参照のこと。
２４．Ｒｉｖｅｔｚプロトコル
デバイス登録プロトコル
命令処理プロトコル
Ｉｎｔｅｒｃｅｄｅオンボードプロセス
２５．命令処理プロトコル
ａ．概説
デバイスＲｉｖｅｔの相手方は、Ｒｉｖｅｔｚエンコーダである。Ｒｉｖｅｔｚエンコーダは、サービスプロバイダにより署名及び／又は暗号化された特定のデバイスにより実行されるコマンドを準備する。サービスプロバイダの公開鍵は、Ｒｉｖｅｔｚネットにより行われるペアリングプロセス中、デバイスに予めロードされる。これにより、デバイスＲｉｖｅｔは、要求の出所を検証することができ、必要な場合、命令の内容を復号化することができる。
命令をパッケージし送出するシーケンスは、かなり簡単である。サービスプロバイダは、Ｒｉｖｅｔｚエンコーダのライブラリを用いて命令レコードを生成する。命令は、タイプ、ターゲットデバイス、及びペイロードを含む。命令は、デバイスキーを用いて符号化し得、サービスプロバイダキーにより署名されなければならない。デバイスキーは、Ｒｉｖｅｔｚネットからフェッチされるか、又はデバイス登録レコードを検索することによりブロックチェーンから直接フェッチされる。
２６．デバイス登録プロトコル
ａ．概説
デバイス登録は、Ｒｉｖｅｔｚのエコシステム全体が立つ基礎である。
２７．Ｉｎｔｅｒｃｅｄｅオンボードプロセス
以下に、Ｒｉｖｅｔｚが、デバイスＲｉｖｅｔをインストールするためのＩｎｔｅｒｃｅｄｅの使用し始めを完了するために必要なステップを概説する。
背景及び文献についてはＩｎｔｅｒｃｅｄｅグループを参照のこと。
・Ｉｎｔｅｒｃｅｄｅオンボードプロセス
・鍵のセットアップ
・デバイスＲｉｖｅｔアプリケーションの構築
・実行
・鍵の輸送
・マスターキーの個人化
・鍵の確認
・受信鍵の購入
ａ．鍵のセットアップ
・まず、テスト輸送鍵（これをＴＴＫと呼ぶ）を作成する。
・３つのランダムな２５６ビット値を生成し、シェア１、シェア２、シェア３に記憶する。
・シェア間でＸＯＲ演算を実行して（シェア１  ＸＯＲ  シェア２  ＸＯＲ  シェア３）、ＴＴＫを取得する。
・３つそれぞれのシェアにファイルを作成し、Ｒｉｖｅｔｚに送信されたＩｎｔｅｒｃｅｄｅ３つのＰＧＰ鍵で個々に暗号化する。
・２５６ビットのテスト個人化マスターキー（ＴＰＭＫ）を生成し、これをＲｉｖｅｔｚコードのどこかに記憶する。
・Ｉｎｔｅｒｃｅｄｅ文献に記載されるように、ＴＰＭＫをＴＴＫで暗号化し、電子メールを介してこれをＩｎｔｅｒｃｅｄｅに送信する。
・テスト購入受信鍵（ＴＰＲＫ）を生成する。
・ロージーウォレットの「顧客参照」番号を生成するか、又は欲するサービスプロバイダをテストする何かを生成する。
・ＴＰＲＫの公開部分（これをＴＰＲＰＫと呼ぶ）をＩｎｔｅｒｃｅｄｅに送信する。
ｂ．デバイスＲｉｖｅｔアプリケーションの構築
・個人化パッケージを受け入れることができるように、現在のデバイスＲｉｖｅｔソフトウェアを変更すべきである。個人化パッケージは、ＴＰＭＫから導出される鍵を含む。
・Ｒｉｖｅｔｚネットサーバ側で、個々の各デバイスＲｉｖｅｔの個人化鍵を導出するソフトウェアを作成する。
・共有デバイスＲｉｖｅｔ個人化鍵を使用して、デバイスとＲｉｖｅｔｚネットとの間に信用を確立するように、Ｒｉｖｅｔｚプロビジョニングプロトコルを交信する。これは、デバイスＲｉｖｅｔが、新しいデバイス固有鍵を生成し、その特定のデバイスＲｉｖｅｔの個人化鍵で、Ｒｉｖｅｔｚネットに向けてそれらに署名／暗号化することを含む可能性が高い。
・現実世界用途（Ｒｉｖｅｔアダプタ）では、ＭｙＴＡＭクライアントライブラリを包含して、デバイスＲｉｖｅｔ及び個人化パッケージのインストールを支援する。
ｃ．実行
ｉ．輸送キー
乱数値シェア１、シェア２、シェア２を構築するために：
【０１５８】
【数４】
2018516026.tif 000032
【０１５９】
乱数値はこのように見えるはずである。
ａ９ｆ５１５６６ｂｄ６７０５ｆ７ｅａ６ａｄ５４ｂｂ９ｄｅｂ４４９ｆ７９５５８２ｄ６５２９ａ０ｅ２２２０７ｂ８９８１２３３ｅｃ５８
このコマンドが行うことは、英数字文字を引き出し、結果をランダムな数の文字（ヘッドを有する）に切り詰め、ｓｈａ２５６ｓｕｍにこれをパイピングするテキスト処理ツール（ｔｒ）を通してｌｉｎｕｘカーネルランダムデータをパイピングすることである。最後に、ｔｒを再び使用して、後続スペース及びハイフンを除去する。
これを３回行い、Ｐｙｔｈｏｎコマンドライン呼び出しを使用して、結果を一緒にＸＯＲする。
【０１６０】
【数５】
2018516026.tif 000033
【０１６１】
この結果は、
ｆ７ｃ６２ｃｂｃｄ８４２６１２１２８ｅ９６ｅ２７２５０８９９７８ｅ４ｅｅｂｆｂｆ６５５３０９ｅ２ｃ８７４ｆｂ１ｂ０１３９４ｄｆ２
である。
これが行うことは、１６進数列のそれぞれをｉｎｔにキャストし、それらを一緒にＸＯＲし、次に、結果を再び１６進数にフォーマットすることである。
なお、これらのファイルは全てＡＳＣＩＩ  １６進数表現である。これを二進数に変換するために、
【０１６２】
【数６】
2018516026.tif 000034
【０１６３】
を行う。
これを一緒にする。
【０１６４】
【数７】
2018516026.tif 000035
【０１６５】
次に、各フラグメント毎に：
【０１６６】
【数８】
2018516026.tif 000036
【０１６７】
ｉｉ．個人化マスターキー
１．乱数を生成
２．二進数に変換
３．輸送キーで暗号化し、次に、１６進数形式にパイピングして、Ｉｎｔｅｒｃｅｄｅに送出
【０１６８】
【数９】
2018516026.tif 000037
【０１６９】
ｉｉｉ．鍵の確認
チェック値（ＫＣＶ）を計算し、Ｉｎｔｅｒｃｅｄｅに送信することもできる。任意選択的なチェック値は、個人化マスターキーが、ＩｎｔｅｒｃｅｄｅＨＳＭにインポートされると、正確であることを保証する−チェック値は以下のように計算される。
・（暗号化されていない）個人化マスターキーを使用して、二進数０の１ブロック（１６バイト）を暗号化する（ＥＣＢモードを使用、パディングなし）。
・出力の最初の３バイトはチェック値（ＫＣＶ）である。ＫＣＶをＩｎｔｅｒｃｅｄｅに送信する。
・鍵をＩｎｔｅｒｃｅｄｅのＭｙＴＡＭにインポートするプロセスは、ＫＣＶ（供給される場合）を確認し、鍵交換が正確に実行されたことの追加の確認を提供する。
【０１７０】
【数１０】
2018516026.tif 000038
【０１７１】
ｉｖ．購入受信鍵
これは、アプリ購入でＧｏｏｇｌｅ  Ｐｌａｙ受信鍵を模倣するものであると考えられる。鍵は、プロビジョニング中、デバイスＳＵＩＤに署名するのに使用される。Ｉｎｔｅｒｃｅｄｅはこれを「購入」のレシートとして使用する。
【０１７２】
【数１１】
2018516026.tif 000039
【０１７３】
これは、ファイルＴＰＲＫ．ｐｅｍにおいて２０４８ビットＲＳＡ鍵を生成し、次に、公開鍵を抽出し、Ｉｎｔｅｒｃｅｄｅに送信されるＴＰＲＰＫ．ｐｅｍに入れる。
ｏｐｅｎｓｓｌ．ｏｒｇから「ＰＥＭフォームはデフォルトフォーマットである：これは、追加のヘッダライン及びフッタラインが符号化されたＤＥＲフォーマットＢａｓｅ６４からなる。入力ＰＫＣＳ＃８フォーマットでは、秘密鍵も受け入れられる」。
Ｇｏｏｇｌｅ  Ｐｌａｙドキュメンテーションから：「Ｇｏｏｇｌｅ  Ｐｌａｙにより生成されるＢａｓｅ６４符号化ＲＳＡ公開鍵は、二進数符号化されたＸ．５０９ｓｕｂｊｅｃｔＰｕｂｌｉｃＫｅｙＩｎｆｏ  ＤＥＲ  ＳＥＱＵＥＮＣＥフォーマットである。これは、Ｇｏｏｇｌｅ  Ｐｌａｙライセンシングで使用されるものと同じ公開鍵である」。
【０１７４】
【数１２】
2018516026.tif 000040
【０１７５】
これはバイナリフォーマット鍵を送出する
２８．Ｒｉｖｅｔｚ使用事例
Ｒｉｖｅｔｚは、シンプルであるが、それでもなお重要なデバイスとのトランザクションを達成するＳＤＫをパートナーに提供する。これは、メッセージへの認証からビットコイン署名まで及ぶ。インタフェースはシステムインタフェースであるが、幾つかのサービスは、ＰＩＮ入力、視覚的確認等に関してユーザが関わる。
ａ．使用事例
【０１７６】
【表２７】
2018516026.tif 000041
【０１７７】
ｂ．アクター
【０１７８】
【表２８】
2018516026.tif 000042
【０１７９】
２９．高信頼アプリケーションマネージャ
高信頼アプリケーションを高信頼実行環境（ＴＥＥ）にロードし、裏書きすることができるエンティティ。
ａ．定義
Ｔｒｕｓｔｏｎｉｃの世界では、ＧｉｅｓｅｃｋｅＡｎｄＤｅｖｒｉｅｎｔ及びＩｎｔｅｒｃｅｄｅＧｒｏｕｐはＴＡＭとして確立される。
３０．サービスユーザ
サービスユーザは、Ｒｉｖｅｔｚのサービスの主要特徴／機能に関わる誰かである。
ａ．定義
３１．システム管理者
システム管理者は、Ｒｉｖｅｔｚのサービスのインストール、構成、及びメンテナンスに携わる。
ａ．定義
３２．アカウント担当者
サービスプロバイダとの関係を担当するＲｉｖｅｔｚ従業員。
ａ．定義
３３．サービスプロバイダ
サービスプロバイダは、Ｒｉｖｅｔｚに提供される機能を使用して、それ自体のサービスを強化する。
定義
サービスプロバイダは、Ｒｉｖｅｔｚと取引をするために、Ｒｉｖｅｔｚネットに登録する必要があり、より詳細には、ＲｉｖｅｔｚのＡＰＩにアクセスし、Ｒｉｖｅｔ登録されたデバイスに向けられた命令に署名する必要がある。
ａ．デモサービスプロバイダ
初期テスト及び実験のために、開発者に容易に配ることができるサービスプロバイダＩＤを有する必要があることは明らかである。Ｒｉｖｅｔｚは既にこれを行っているが、Ｍａｒｋ  Ｈｏｂｌｉｔが組み込まれたランダムＵＵＩＤを使用してこれを行っている。例えば：
【０１８０】
【数１３】
2018516026.tif 000043
【０１８１】
デモＳＰＩＤを用いてアクティブ化されたデバイスが、製品Ｒｉｖｅｔと全く同じように、Ｉｎｔｅｒｃｅｄｅ及びＴｒｕｓｔｏｎｉｃへのロイヤルティが発生することになることに留意されたい。
３４．サービスプロバイダのＲｉｖｅｔｚへの登録
Ｒｉｖｅｔｚシステムにコーディングしようとする者は誰であっても、サービスプロバイダとして登録する必要がある。
初期登録は、Ｒｉｖｅｔｚネット（ｈｔｔｐ：／／ｒｉｖｅｔｚ．ｃｏｍ／ｄｏｃｓ／ｒｅｇｉｓｔｒａｔｉｏｎ．ｈｔｍｌ）でフォームに記入するといった簡単なものである。
ａ．アクター
サービスプロバイダ、アカウント担当者
ｂ．説明
１．サービスプロバイダは、ローカル公開／秘密鍵を作成する。
２．サービスプロバイダはｒｉｖｅｔｚ．ｃｏｍ(ｈｔｔｐ：／／ｒｉｖｅｔｚ．ｃｏｍ／ｄｏｃｓ／ｒｅｇｉｓｔｒａｔｉｏｎ）のＨＴＴＰフォームを開き、以下の情報を入力する。
・企業名
・連絡先：名、姓、ポジション、電子メール、電話番号
・企業ウェブサイト
・企業住所：通り、市、州／県、国
３．サービスプロバイダは、サービス契約条件への「承諾します」をクリックする。
４．サービスプロバイダは、パスワードを選択し、パスワードを確認する（ユーザ名は所与の連絡先電子メールである）。
・Ｒｉｖｅｔｚは、これをデバイス認証で後に置き換えることができることを通知する。
５．サービスプロバイダは、公開鍵をアップロードするように求められる。
・これはスキップし、後で行うことができる。
・Ｒｉｖｅｔｚはまた、このアップロードよりも安全な公開鍵取得方法を提供すべきである。
６．鍵が提供されると、ＳＰＩＤ（サービスプロバイダＩＤ）が生成され、顧客に電子メール送信される。
・鍵が提供されない場合、電子メール確認は、保留メッセージ及び鍵の提供についての指示と共に送信される。
７．アカウント担当者が、新規登録の通知を受信する。
・この時点で、データを営業チームにロードすることができ、アカウント担当者は個人的にフォローアップすることを選び得る。
ｉ．変形：新しいサービスプロバイダが公開鍵に戻る
１．サービスプロバイダは、電子メール及びパスワードを用いてログインする。
２．サービスプロバイダは、アカウントの「保留」状態に気付く。
３．サービスプロバイダは、クリックして保留状態を修正し、公開鍵の入力ボックスを用いてプロンプトされる。
４．鍵が掲示されると、ＳＰＩＤが作成され、サービスプロバイダの連絡先電子メールに送信される。
５．アカウントはもはや保留中ではない。
６．アカウント担当者にアカウントの変更が通知される。
ｃ．備考
３５．ユーザが忘れたデバイスＰＩＮを思い出した
サマリ
ａ．アクター
製品アクターからアクターを選択／作成
ｂ．説明
ｃ．備考
３６．何かの確認
名前付き鍵又は所与の鍵でオブジェクトの署名を確認する。
何かの暗号化のように、これは、公開鍵を使用するため、安全なプロセスではない。これは便宜上提供される。対応するものである何かに署名を参照のこと。
ａ．アクター
サービスプロバイダ
ｂ．説明
ｃ．備考
ウェブホーム＞製品視点＞製品使用事例＞Ｒｉｖｅｔｚ使用事例＞鍵の作成
３７．鍵の作成
署名及び暗号化のいずれかのために、デバイスＲｉｖｅｔにおいて鍵ペアを作成する。
ａ．アクター
サービスプロバイダ
ｂ．説明
Ｒｉｖｅｔｚの主な目的は、エンドポイントデバイス内で鍵をセキュア化し適用することである。暗号（秘密）鍵又は署名（識別）鍵は、ＴＥＥ内の暗号ツールを使用して生成され、ＴＥＥのストレージキーを使用してデバイスにセキュアに記憶される。ビットコインアドレスキーも同様に維持されるが、微妙な差異がある。ビットコインアカウント作成を参照のこと。
全ての鍵は、サービスプロバイダのコンテキストで作成される。換言すれば、あらゆる鍵は、作成を要求したサービスプロバイダＩＤと共に記憶される。あらゆる鍵には、サービスプロバイダＩＤのコンテキストと一意である名前が与えられる。
鍵が作成されると、鍵の使用ルールが任意の組み合わせで指定される。これらは：
・鍵の作成者（サービスプロバイダ）による鍵の適用には、署名付き要求が必要とされる。
・高信頼ユーザインタフェースを通して鍵を適用するには、ユーザの確認が必要とされる。
・結果をＴＵＩで表示することが必要とされる。
ＴＵＩに結果を表示させることにより何が意味されるかについてのより詳細については、何かの復号化及び何かの確認を参照のこと。
ｃ．備考
３８．ビットコインアカウントの作成
デバイスハードウェアにおいて新しいウォレットアカウントを生成する。
ａ．アクター
サービスプロバイダ
ｂ．説明
全てのＲｉｖｅｔ保護される鍵のように、新しいビットコインアカウントもサービスプロバイダのコンテキスト内で作成され、名前が与えられる。サービスプロバイダアプリは、この名前を隠し得るか、又は特徴としてエンドユーザに提示し得る。
ビットコインアドレスを作成するとき、サービスプロバイダは、アカウントが、トランザクションの署名へのＴＵＩ確認を必要とするか否かを指定しなければならない。
ｃ．備考
３９．何かの暗号化
Ｒｉｖｅｔｚは、テキスト又は画像を暗号化するメカニズムを提供するが、パートナーが、メッセージングアプリケーションであるか否かに関係なく、サービスのインタフェースを提案すると予期する。
復号鍵は、復号化されたオブジェクトのＴＵＩ表示を必要とするようにマークすることができる。
ＭＪＳ＞これがＴＵＩ確認を要求することとは別個であることに留意する。
ａ．アクター
サービスユーザ、サービスプロバイダ
ｂ．説明
Ｒｉｖｅｔアダプタは、ターゲットデバイスの公開鍵を有する必要があり、ターゲットデバイスの公開鍵は、サービスプロバイダにより直接提供されるか、又はデバイスのペアリング中、デバイスＲｉｖｅｔに前に記録されている。暗号側では、動作は公開鍵動作のみであるため、デバイスＲｉｖｅｔは関わる必要がない。それにも関わらず、暗号側では、ホストアダプタインタフェース（又はＲｉｖｅｔｚエンコーダ）での関数への入力は、＊ターゲットデバイスＩＤ又はターゲットデバイス静的公開暗号鍵（暗号鍵は、暗号化を実行するエンティティによって既知でなければならない）＊（任意選択的）暗号化するデータを含む。
最も単純なインスタンス化では、Ｒｉｖｅｔｚは、ＥＣＤＨ動作のみを提供する。これが行われる場合、暗号化又は復号化されるデータはＲｉｖｅｔｚソフトウェアに渡されず、その代わり、Ｒｉｖｅｔｚソフトウェアは単純に、ＥＣＤＳ動作から共有秘密を出力する。次に、その共有秘密を使用してデータ暗号化を実行するかどうかは、外部ソフトウェア次第である。
ｃ．備考
４０．セキュア確認要求の送信
ターゲットエンドポイントデバイスに送られ、利用可能な場合、セキュアディスプレイを用いてユーザに表示されるショートメッセージをパッケージングする。通信されたは、両方向で署名されて、確認が有効であることを保証する。メッセージは画像又はテキストであり得る。
ａ．アクター
サービスプロバイダ、サービスユーザ
ｂ．説明
セキュア確認要求の価値は、メッセージが、意図されたデバイス以外の何らかの他のデバイスがメッセージを確認することができる機会が非常に低い（機会があるとしても）ことを知ることである。さらに、デバイスは、示されたソースのみ来ることができる確認を表示している。これを達成するには、デバイス及びサービスプロバイダ並びにデバイスでのＴＥＥの両方からの鍵の登録が必要であり、メッセージが処理中であり、ネットワークのワイルドな末端（ユーザのデバイス）での表示に提示されているとき、都合の悪いことが何も生じてないことを保証する。
サービスプロバイダは、単にメッセージ及びターゲットデバイスを宣言し、応答を待つことが予期される。ソースコードが信頼される限り、数学のみが役割を果たすことを保証するために、キーイング基盤は全ての当事者及び公衆から独立しているべきである。
ｃ．備考
４１．何かへの署名
名前付き鍵及びオブジェクト参照を所与として、オブジェクトの署名付きハッシュを返す。
ａ．アクター
サービスプロバイダ
ｂ．説明
なお、識別鍵は、鍵の作成に記載されるような鍵使用ルールに従う。
ｃ．備考
４２．デバイスのＲｉｖｅｔｚへの登録
Ｒｉｖｅｔが何かを行うことができるようになるには、先にＲｉｖｅｔｚネットに登録する必要がある。登録により、一意の識別鍵が生成される。
登録は、デバイスＲｉｖｅｔがセキュア環境で適宜実行中であることを保証するために、高信頼アプリケーションマネージャからのエンドースメントに頼る。（理想的には、高信頼アプリケーションマネージャにより確立された鍵は、デバイス登録鍵をローカルに署名する）。
ａ．アクター
高信頼アプリケーションマネージャ
ｂ．説明
デバイス登録プロトコルを参照のこと。
登録は、Ｒｉｖｅｔアダプタが最初に呼び出されるときに行われ、その結果、Ｒｉｖｅｔにおいて鍵ペアが作成され、公開鍵がＲｉｖｅｔｚネット共有される。デバイスは、登録されると、ＲａｂｂｉｔＭＱソケットが活きているときは常に、ＲａｂｂｉｔＭＱソケットを通してＲｉｖｅｔｚネットに接続しようと試みる。
１．デバイスはローカル公開／秘密鍵を作成する。
これらの鍵は、サービスプロバイダ「Ｒｉｖｅｔｚ」への識別鍵としてリー刈るに記憶されるべきである。
２．デバイスは、一意の識別子として公開鍵の署名を用いて登録を要求するＨＴＴＰ  ＲＥＳＴ呼び出しをＲｉｖｅｔｚネットに対して行う。
Ｒｉｖｅｔｚネットは、高信頼アプリケーションマネージャ（ＴＢＤ）により提供されるプロトコルを通して要求の検証をテストする必要がある。
３．デバイスは、現在、登録済みであることを示す（又は以前に登録していたことを示す）応答を受信し、その一意のデバイスＩＤ及びＲａｂｂｉｔＭＱキュー名を用いて、入力コマンドをリッスンする。
４．デバイスはＲａｂｂｉｔＭＱを開始して、指定されたキューについての入力コマンドをリッスンする。
ｃ．備考
４３．ビットコイントランザクションの署名
完全に形成されたビットコイントランザクション（出所アカウントがターゲットデバイスハードウェアにより所有される）を所与として、トランザクションに署名して返す。大半の場合、これは、利用可能な場合、セキュアディスプレイ又は利用可能ではない場合には少なくとも一般的なディスプレイを用いて確認するようにユーザにプロンプトすることも含むべきである。
ａ．アクター
サービスプロバイダ、サービスユーザ
ｂ．説明
ｃ．備考
４４．ローカルユーザの作成
サービスプロバイダの認可が与えられない場合、Ｒｉｖｅｔの使用を認可することができるローカルエンティティを確立する。
ａ．アクター
製品アクターからアクターを選択／作成
＊デバイスＲｉｖｅｔ
＊ＴＥＥアダプタ
＊Ｒｉｖｅｔｚネット（任意選択的）
ｂ．説明
デバイスＲｉｖｅｔの高速で容易な使用を可能にするために、デバイスＲｉｖｅｔは、「ローカルユーザ」の作成を可能にし得る。ローカルユーザは、認可されたサービスプロバイダではないが、幾らかのキャパシティでデバイスＲｉｖｅｔにアクセスすることが許されるエンティティであると定義される。サービスプロバイダは、ビットコインキーを作成して維持し、他のサービスを提供することが許され得るが、ローカルユーザは、特定の動作の実行のみが認められ得る。これらの動作は、
＊暗号鍵の作成及び使用、
＊署名鍵の作成及び使用
を含み得る。
ローカルユーザの属性は以下である。
−ローカルユーザの認証はまず、ローカルプラットフォームに保持されるが、後に他の場所で保護することができる。
−ローカルユーザは任意選択的に、Ｒｉｖｅｔｚネットにより認証される。
−ローカルユーザは、実際の人間であるユーザ又はアプリケーションから隠し得る。Ｒｉｖｅｔアダプタ内で管理し得る。
−ローカルユーザの認証の保護は、ユーザパスワード又は何らかの他の保護メカニズムを用いての暗号化を含むように、時間の経過に伴って強化することができる。
−アプリケーションの視点から、ホストアダプタは、ホストアダプタを通して以外、いかなるインタフェースを通してもローカルユーザに関連付けられた鍵にアクセスできないこと以外、ローカルユーザの概念をトランスペアレントにするインタフェースを提供する。
「ローカルユーザ」の名前を考慮するに当たり、これはデバイスＲｉｖｅｔの視点からのユーザであるが、必ずしも外部の視点からのユーザであるわけではないため、注意すべきである。一概念は、ローカルユーザがＴＥＥアダプタにより扱われることである。ＴＥＥアダプタは、デバイスＲｉｖｅｔとの共有秘密を確立するか、又はデバイスＲｉｖｅｔを用いてローカルユーザを認証する公開鍵を作成する。
ｃ．備考
４５．ローカルユーザ
これは、正式なサービスプロバイダからの参加なしで、デバイスＲｉｖｅｔにアクセスすることができるエンティティである。すなわち、これは、典型的なサービスプロバイダとは異なる役割であり、１つの特定のデバイスＲｉｖｅｔにのみアクセス可能である、各デバイスＲｉｖｅｔに異なるローカルユーザがあることができることを予期し得る。
ローカルユーザのプロビジョニングについて幾つかの判断を行うべきであるが、１つの可能性は、Ｒｉｖｅｔｚネットが、プロビジョニングステップ中、典型的なサービスプロバイダを用いて行い得る（例えば、「ペアリング」動作を通して）のと同じように、ローカルユーザを認証することである。これが当てはまる場合、Ｒｉｖｅｔｚはなお、デバイスＲｉｖｅｔサービスに誰がアクセスできるかの制御を維持することができるとともに、将来、ローカルユーザの役割へのアクセスにわたり何らかの強力な保護を提供することもできる（ローカルユーザの認証が、何らかの高信頼エンティティにより強力に保護され制御されることを保証することにより）。
ローカルユーザが認証される様式についても判断を行うべきである。簡明にするために、Ｒｉｖｅｔｚは、ローカルユーザによる動作が、サービスプロバイダからの動作と同じ種類の認証を必要とする（例えば、署名動作を通して）ことを要求することができ、又は短期間で単に、ローカルユーザが共有秘密（例えば、パスワード、パスフレーズ、又はランダム値）を利用するのを許可することができる。
・ローカルユーザ
４６．デバイスのサービスプロバイダへの登録
サービスプロバイダは、デバイスがいかなる要求にも応答するようになる前、サービスプロバイダＩＤを及び公開識別鍵をそのデバイスに登録させる必要がある。
名前付き鍵（識別、秘密、又はコイン）が署名付き要求を必要としない場合であっても、要求側当事者のＩＤはデバイスにとって既知でなければならない。Ｒｉｖｅｔｚネットは、デバイスとサービスプロバイダとの関係の裏書きを担当する。このようにして、Ｒｉｖｅｔｚは、エコシステムにわたり何らかの制御を維持する。Ｒｉｖｅｔｚは、サービスプロバイダキーの使用、バックアップ、及び移植に関するサービスをエンドユーザに提供できるようにする。
ａ．アクター
サービスプロバイダ
ｂ．説明
１．ローカルサービスプロバイダアプリは、デバイスポインタ要求をＲｉｖｅｔアダプタに対して行う。
２．デバイスは、新しいデバイスポインタ及びデバイスＩＤ（備考：ここで認証が必要である…上記と同様に公開鍵又はＡＰＩキーを使用することができる）並びに公開鍵を用いて、ＨＴＴＰ  ＲＥＳＴ呼び出しをＲｉｖｅｔｚネットに対して行う。
３．サーバからの応答は、入力サービスプロバイダ公開鍵を待つためのＲａｂｂｉｔＭＱキューを含む。
４．サービスプロバイダは、デバイスポインタをサーバに渡す。
５．サービスプロバイダは、デバイスポインタ及びＳＰの公開鍵を用いてＨＴＴＰ  ＲＥＳＴ呼び出しを行う。
６．サービスプロバイダへの応答は、デバイス公開鍵を含む。
７．サービスプロバイダの公開鍵はデバイスにプッシュされる。
ｃ．備考
４７．何かの復号化
暗号化されたオブジェクト及び鍵名を所与として、ＴＵＩ表示のため又は要求者に返すためにオブジェクトを復号化する。
ａ．アクター
サービスプロバイダ
ｂ．説明
秘密鍵ペアが作成されるとき、要求がＴＵＩを通してユーザにより署名及び／又は確認する必要があるか否かを指定する鍵使用ルールで秘密鍵をマークする必要がある。さらに、その鍵で復号化されるものは何でもセキュアな世界に留まることを意味する、ＴＵＩディスプレイのみ用として鍵を指定することができる。
ｃ．備考
【図１Ａ】
2018516026.tif 000044
【図１Ｂ】
2018516026.tif 000045
【図２Ａ】
2018516026.tif 000046
【図２Ｂ】
2018516026.tif 000047
【図２Ｃ】
2018516026.tif 000048
【図２Ｄ】
2018516026.tif 000049
【図３Ａ】
2018516026.tif 000050
【図３Ｂ】
2018516026.tif 000051
【国際調査報告】
2018516026.tif 000052