JP6888673B2 - デバイスを認証および認可するためのシステムおよび方法 - Google Patents

デバイスを認証および認可するためのシステムおよび方法 Download PDF

Info

Publication number
JP6888673B2
JP6888673B2 JP2019521454A JP2019521454A JP6888673B2 JP 6888673 B2 JP6888673 B2 JP 6888673B2 JP 2019521454 A JP2019521454 A JP 2019521454A JP 2019521454 A JP2019521454 A JP 2019521454A JP 6888673 B2 JP6888673 B2 JP 6888673B2
Authority
JP
Japan
Prior art keywords
key
scm
authorization
acp
cloud
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2019521454A
Other languages
English (en)
Other versions
JP2019536329A (ja
Inventor
エリック ジョン スミス
エリック ジョン スミス
レイモンド マイケル スティット
レイモンド マイケル スティット
デービッド スタックレス マイアー
デービッド スタックレス マイアー
ブライアン エンシンク
ブライアン エンシンク
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Denso Corp
Original Assignee
Denso Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Denso Corp filed Critical Denso Corp
Publication of JP2019536329A publication Critical patent/JP2019536329A/ja
Application granted granted Critical
Publication of JP6888673B2 publication Critical patent/JP6888673B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Lock And Its Accessories (AREA)

Description

本出願は、デバイスを認証および認可するため、および／または、鍵を配信するためのシステムおよび方法に関する。
スマートフォンをドアや車両などの機器デバイスへのアクセスや操作を指示するための鍵として利用することができるようにするため多大な努力がなされてきた。しかしながら、これらの従来のシステムは、スマートフォンが機器デバイスの操作を指示する権限を有するかどうかを認証するために、ネットワークアクセスを有する機器デバイスに依存する、セキュリティの単純な形態とみなされるものに依存する。このような従来の機器デバイスは、認可デバイスが以前に機器デバイスと通信して鍵、デバイスまたはユーザーの権限を識別していないとき、鍵、デバイスおよびユーザーの少なくとも１つを認証および／または認可することができない。言い換えれば、認可デバイスと機器デバイスとの間の通信リンクが存在しない場合、つまり接続性が欠如する場合、この従来のシステムの機器デバイスは、機器デバイスと通信しようとしているスマートフォンが認可デバイスによって認可されているかを判定することができない。
車両製造業者によって利用される従来のキーフォブシステムでは、鍵および／またはキーフォブの認証情報が、キーフォブが認証および／または認可される前に認可デバイスに配信され、認可デバイスは、認可情報を機器デバイスに送信することができる。
同様の従来のシステムは、例えば、システムが、認証および／または認可プロセスの間、クラウドシステム（または、接続性の欠如のために到達不能な他のシステムコンポーネント）と通信することができる機器デバイスに依存している場合があるため、通信リンクが存在しない間、鍵、デバイス、またはユーザーを認証および／または認可することはできない可能性がある。このシナリオ（接続性の欠如）は、一般的ではないように思われるかもしれない。しかし、セルラ接続なしで、駐車場、僻地、または森のコテージに止めた車を考えれば、それは実際には非常によくあることにすぎない。このような状況での接続性の欠如は、スマートフォンや他のデバイスに車を操作したり、またはコテージにアクセスしたりする権限を付与することを可能にすることを妨げる可能性がある。
本開示は、主として、システムコンポーネントを認証し、システムコンポーネント間でメッセージを安全に転送し、制約付きリンクを介して安全な通信チャネルを確立し、メッセージコンテンツを認証し、アクションを承認し、および、デバイス・アズ・ア・キーシステムでのユーザーシステムコンポーネントの中で認可及び設定データを配信することの、１つ以上を達成するために使用されうる分散セキュリティモデルのためのシステムおよび方法に関する。
一実施形態によるシステムは、ポータブルデバイス、クラウドまたはネットワークサーバーまたはシステム、ハードウェア、変更および取り消しのうちの１つ以上のために、潜在的に固有の識別子を用いて、認証を容易にすることができる。
一実施形態では、システムは、システムコンポーネント間で安全かつ非公開な方法で情報の転送を可能にすることができる。一実施形態では、すべての通信リンクにわたって提供されるエンドツーエンド暗号化が存在し得る。システムは、あるデータが暗号化されていないチャネルを介して送信されてもよいが、そのデータ自体は完全に暗号化される分散システムを形成することができる。
一実施形態では、システムは、ａ）認証されたエンティティによる１つ以上の署名のチェーン、ｂ）潜在的に独立したクラウド、およびｃ）信頼のルーツと認証のルーツとの間の潜在的な分離、に基づく認可を提供することができる。認可は、オーナーとゲストの間で区別され、オーナーシップの移転を提供することができる。
一実施形態によるシステムは、認可、並びに、新しい鍵の生成、変更された鍵のアイデンティフィケーション、ブラックリスト／取り消し通知、鍵の循環、オーナーシップの移転、リセット、設定の信頼のルーツ、鍵、および他のデータを含む１つまたは複数の関連する特徴の配信を容易にすることができる。
一実施形態によるシステムは、例えば、設定の順序付け、タイムデルタ、およびジェイルブレイク検出を含む１つ以上のセキュリティチェックを提供することができる。
１つの実施形態では、システムは、各認可が、その認可をアクティブとして識別するために必要と考えられる１つ以上の属性を有する、鍵属性認可モデルを提供することができる。そのような１つ以上の属性の例には、時間、使用回数、位置、およびカスタム属性が含まれる。
一実施形態のシステムは、認可がデバイス毎、デバイス＋アカウント毎、および／または（例えば、組織レベルであっても）アカウント毎に供され、付与される共有モデルに役立つ。
一実施形態では、システムは、信頼できるデバイスレベルおよび／またはクラウドレベルで時間同期を提供することができる。
一実施形態によるシステムは、初見であっても、実用的なインターネット接続なしに、デバイス間で認証および認可を与えることを可能にすることができる。
システムは、安全な動作を容易にするための、モバイルソフトウェアの信頼できる実行環境、ハードウェアＴＥＥ、またはセキュアエレメント（セキュアストレージ）を提供することができる。
一実施形態では、第１のデバイスから第２のデバイスにコマンドを通信するためのシステムが提供される。第１のデバイスは、オンラインモードでネットワークサーバーと無線通信し、ネットワークサーバーから認可設定情報を取得するように構成することができる。認可設定情報は、第１のデバイスが第２のデバイスにコマンドを発行するための認可に関係し、認可設定情報は、第２のデバイスに関連する第１の鍵によって暗号化されたデータを含むことができる。
第２のデバイスは、機器コンポーネントに対するものであってもよく、機器制御にコマンドを実行するように指示するように構成されてもよい。
第２のデバイスは、第１のデバイスと第２のデバイスのいずれもネットワークサーバーと効果的に通信することができないオフラインモードにおいて、第１のデバイスと無線通信するように構成することができる。第１のデバイスおよび第２のデバイスは、通信を交換するための通信リンクを確立するように構成され、第２のデバイスは、通信リンクを確立する前は、第１のデバイスが第２のデバイスにコマンドを発行する認可に関連する認可設定情報を第１のデバイスが取得したことを示す情報を受信していない。
第１のデバイスは、通信リンクを介して、認可設定情報を第２のデバイスに通信することができる。第１のデバイスはまた、通信リンクを介して、コマンドを実行する要求に関するコマンド情報を通信することができる。第２のデバイスは、認可設定情報に基づいて、第１のデバイスのアイデンティティを認証し、第１のデバイスが第２のデバイスにコマンドを発行する権限を判定することができる。
一実施形態では、機器コンポーネントの動作を制御する制御ユニットは、通信インターフェース、メモリ、機器インターフェース、およびコントローラを含む。通信インターフェースは、遠隔デバイスと無線で通信するように動作可能であり、メモリは、遠隔デバイスの認証及び認可に関係する１つ以上の暗号鍵を記憶するように構成することができる。機器インターフェースは、遠隔デバイスから受信したコマンドに応答して機器制御の動作を指示するように動作可能であってもよい。
制御ユニットのコントローラは、通信インターフェースを介して遠隔デバイスとの通信リンクを確立し、遠隔デバイスから認可設定情報を受信するように構成することができる。認可設定情報は、暗号化された認可データを含み、コントローラのみが認可設定情報から認可データを復号することができる。
認可データに少なくとも部分的に基づいて、コントローラは遠隔デバイスのアイデンティティを認証し、遠隔デバイスにコマンドを発行する遠隔デバイスの権限を判定することができる。
一実施形態による、第１のデバイスと第２のデバイスとの間の通信方法が提供される。その方法は、第１のデバイスにおいて、ネットワークサーバーから認可設定情報を取得することを含むことができ、認可設定情報は、第２のデバイスに関連付けられた第１の鍵によって暗号化されたデータを含む。その方法は、第１のデバイスと第２のデバイスとの間で通信を交換するための通信リンクを確立することを含むことができ、第２のデバイスは、通信リンクを確立する前は、第１のデバイスが認可設定情報を取得したことを示す情報を受信していない。
その方法は、第２のデバイスにおいて、認可設定情報を受信すること、および、第２のデバイスにおいて、第１のデバイスが第２のデバイスの動作を指示するための１つ以上の認可に関係するデバイス鍵及び認可データを取得するために、認可設定情報を復号することを含むことができる。
第２のデバイスは、認可設定情報から得られたデバイス鍵に基づいて第１のデバイスのアイデンティティを認証し、第１のデバイスからコマンドを受信することができる。
その方法は、第１のデバイスがコマンドを発行する権限があるかどうかを判定すること、および、第１のデバイスがコマンドを発行する権限があると判定したことに応じて、機器コンポーネントにコマンドを実行するように指示することを含むことができる。
一実施形態では、集中クラウドおよびクラウドへの接続性に依存する従来の鍵配信システムとは異なるシステムが提供される。例えば、本開示の一実施形態では、鍵がデバイスに送信され、その鍵が承認者（例えば、ロック）によって検証されてもよい。
一実施形態では、高価値のターゲットが存在せず、知識が無くともコンポーネントが危険にさらされることのない（システムのセキュリティを損なう単一のコンポーネントの穴のない）セキュリティモデルを提供することができる。
本発明の実施形態が詳細に説明される前に、本発明は、以下の説明に記載の、または図面に示されたコンポーネントの動作の詳細、あるいは、構成および配置の詳細に限定されないことを理解されたい。本発明は、様々な他の実施形態で実施することができ、本明細書に明示的に開示されていない別の方法で実施または実行することができる。また、本明細書で使用される表現および用語は、説明のためのものであり、限定するものとして見なされるべきではないことを理解されたい。「含む（including）」および「備える（comprising）」およびそれらの変種の使用は、それ以降に列挙される品目及びそれらの等価物、並びに追加の品目およびそれらの等価物を包含することを意味する。さらに、列挙することが、様々な実施形態の説明において使用されるかもしれない。特に明記しない限り、列挙することの使用が、本発明をコンポーネントのある特定の順序または数に限定するものとして解釈されるべきではない。また、列挙することの使用が、列挙されたステップまたはコンポーネントと、またはコンポーネント内に組み合わせることができる任意の追加のステップまたはコンポーネントを本発明の範囲から除外するものとして解釈されるべきではない。
図１は、一実施形態によるシステムの代表図である。
図２は、一実施形態におけるシステムコンポーネントの代表図である。
図３は、一実施形態によるマイクロロケーションシステムを示す。
図４は、一実施形態によるＡＣＰコンテナを示す。
図５は、一実施形態によるＡＣＰコンテナおよびＡＣＰコンテナバージョンパッケージを示す。
図６は、一実施形態による信頼および認可のツリーを示す。
図７は、一実施形態による信頼および認可の別のツリーを示す。
図８は、一実施形態による、ＳＣＭのための認可を発行する方法を示す。
図９は、一実施形態によるデバイスを登録する方法を示す。
図１０は、一実施形態によるユーザーアカウントを生成する方法を示す。
図１１Ａ−Ｂは、一実施形態によるデータ配信の代表図である。
図１２は、一実施形態による鍵を循環させる方法である。
図１３は、一実施形態によるマイクロロケーション接続を確立する方法を示す。
図１４は、一実施形態による、安全で信頼できる通信リンクを確立する方法を示す。
図１５は、一実施形態による、権利を付与するためのブロックファン配信スキームを示す。
図１６は、一実施形態によるデータ配信の代表図を示す。
図１７は、一実施形態によるシステムの代表的な図を示す。
本開示は、システムコンポーネントを認証し、システムコンポーネント間でメッセージを安全に転送し、制約付きリンクを介して安全な通信チャネルを確立し、メッセージコンテンツを認証し、アクションを承認し、および、デバイス・アズ・ア・キーシステムでのユーザーシステムコンポーネントの中で承認及び設定データを配信することの、１つ以上を達成するために使用されうる分散セキュリティモデルのためのシステムおよび方法に関する。システムの１つまたは複数の部分は、２０１５年２月１２に出願され、米国特許９６６６００５号として発行され、「車両と通信するためのシステムおよび方法」と題する、J. Michael Ellisらの米国特許出願第１４／６２０９５９、および２０１７年４月１４日に出願され、米国特許９７９４７５３号として発行され、「リアルタイムロケーションを確立するためのシステムおよび方法」と題する、Raymond Michael Stittの米国特許出願第１５／４８８１３６号に記載されているマイクロロケーションシステムの１つまたは複数の部分とともに実行することができる。これらの開示は、その全体が本明細書に組み込まれており、そのハードウェアはモニタまたはマスタデバイスであってもよく、その結果、認証検証、認可検証、および位置検証されたポータブルデバイスの、（安全な、信頼できる、非公開の）エンドツーエンド暗号化を用いた他のシステムとのやり取りをもたらす。
Ｉ．システムアーキテクチャ
一実施形態によるシステムが図１および１７に示され、全体的に１００で指定される。システム１００は、以下のシステムコンポーネントから構成することができる。ａ）１人以上のユーザー１０（例えば、人）、ｂ）ポータブルデバイス（例えば、スマートフォン、カードまたはフォブ、またはそれらの組み合わせ）および／または固定デバイス（例えば、コンピュータ／サーバー、壁掛けパネル／ディスプレイ、またはそれらの組み合わせ）などの１つ以上のデバイス１１０、ｃ）ハードウェアとも記載される１つ以上のシステムコントロールモジュール（ＳＣＭ）１２０、ｄ）１つ以上のベンダからの１つ以上のバックエンドサーバーまたはコンピュータの集合を含むことができるクラウド１３０（例えば、クラウドの集合）、およびｅ）機器の動作を制御し、サービスを起動し、システム１００の別の部分に情報を中継し、またはシステム１００の別の部分から情報を取り出し、または、それらの組み合わせのために構成されえる１つ以上の機器コンポーネント１４０。図示された実施形態では、クラウド１３０および／または機器１４０はオプションである。
システム１００は、１人以上のユーザー１０が、デバイス１１０を使用して機器１４０とやり取りするか、機器１４０にアクセスすることを可能にすることができる。デバイス１１０は、ＳＣＭ１２０と通信することによって（車両、ロック、またはテーブルなどの）機器１４０と通信することができる。一実施形態のＳＣＭ１２０は、デバイス１１０を認証し、設定データを提供または受信し、アクション（例えば、接続すること、または、要求、コマンド、更新または応答、またはそれらの組み合わせを送信および／または受信すること）を承認し、または、所望のアクションを達成するために機器コンポーネントと通信し、またはそれらの組み合わせを実行することができる。デバイス１１０は、関係するデバイスおよびユーザーとの間で、（本明細書で説明される）認可および他の設定データを取得し、変更し、または配信し、またはそれらの組み合わせを行うために、クラウド１３０と通信することができる。セキュリティモデルにはあまり関係しない他のシステムのやりとりがあるが、開示の目的のためには、これ以上詳細には示されないか、または説明されない。例えば、他のシステムのクラウドとやり取りすることが可能である、ＳＣＭ１２０およびクラウド１３０と通信するファクトリツールが存在する。
Ａ．通信とやり取りの概要
図１に図示された実施形態に示された１つ以上のシステムコンポーネント間の通信リンクは、無線または有線、またはその両方であってもよい。デバイス１１０などの１つのシステムコンポーネントは、ＳＣＭ１２０などの別のシステムコンポーネントに対してローカルまたはリモートであり得る。システム１００は、クラウドおよび／または機器が存在しない場合のように、その数がゼロである実施形態を含む、任意の数の各システムコンポーネントを含むことができる。
一実施形態では、システム１００のシステムコンポーネントの役割は、必ずしも１つのタイプのコンポーネントとして固定されるとは限らない。例えば、システムコンポーネントは、動作中に動的に役割を変更してもよく、またはシステムコンポーネントが、システム１００の２つ以上のコンポーネントの役割を受け持ってもよい。例えば、ＳＣＭ１２０は、別のＳＣＭ１２０のための機器コンポーネント１４０であってもよい。この例のより具体的な形態では、ＳＣＭ１２０は、他のＳＣＭ１２０と通信する機器コンポーネント１４０であってもよい。これらのシステムコンポーネントの１つまたは複数が存在しなくてもよいと理解されるべきであるが、開示の目的のため、残りの議論は、１つまたは複数の機器コンポーネント１４０およびクラウド１３０が存在するシステム１００に焦点を当てる。
Ｂ．コンポーネントの概要
図示された実施形態におけるシステム１００は、本明細書に概説されるような１つ以上のシステムコンポーネントを含むことができる。システムコンポーネントは、ユーザーまたは電子システムコンポーネントであってもよく、それは、デバイス１１０、ＳＣＭ１２０、機器コンポーネント１４０、およびクラウド１３０、またはそれらの組み合わせであってもよい。本明細書で論じられるように、電子システムコンポーネントは、それらのデバイスの任意の１つまたは複数として動作するように構成することができる。この意味で、一実施形態では、デバイス１１０、ＳＣＭ１２０、機器コンポーネント１４０、およびクラウド１３０の間で共通するいくつかの様相または特徴が存在し得る。開示の目的のために、これらの特徴が、図２に示され、全体として２００で指定される電子コンポーネントに関連して説明される。
電子システムコンポーネント２００（例えば、ユーザーを除くすべてのシステムコンポーネント）は、他の電子ハードウェアの中で、１つ以上のアプリケーション２３２（ソフトウェアおよび／またはファームウェアを含む）を実行する１つ以上のプロセッサ２１０、１つ以上のメモリユニット２１２（例えば、ＲＡＭおよび／またはＲＯＭ）、および１つ以上の通信ユニット２１４を含むことができる。電子システムコンポーネント２００は、通信ユニット２１４を介してより下位レベルのデバイス／電子機器へのアクセスを制御するオペレーティングシステム２３０を有していても有していなくてもよい。電子システムコンポーネント２００は、ハードウェアベースの暗号化ユニット２２２を有していても有していなくてもよく、存在しない場合、暗号化機能はソフトウェアで実行されてもよい。電子システムコンポーネント２００は、セキュアメモリユニット２２０（例えば、セキュアエレメントまたはハードウェアセキュリティモジュール（ＨＳＭ））を有していてもよいし、有していなくても（または、アクセスしてもアクセスしなくても）よい。オプションのコンポーネントおよび通信経路は、図示の実施形態では仮想線で示されている。
図示された実施形態のシステム１００は、任意のコンポーネント内のセキュアメモリユニット２２０の存在に依存しない。セキュアメモリユニット２２０がオプションで存在しない場合、セキュアメモリユニット２２０に格納されるデータ（例えば、非公開鍵および／または秘密鍵）は、静止時に（可能なときに）暗号化されてもよい。ソフトウェアベースおよびハードウェアベースの対処の両方を利用して、そのようなデータへのアクセスを実質的に防止し、並びに、全体的なシステムコンポーネントのセキュリティ破壊の招来を実質的に防止しまたは検出するか、またはその両方を行うことができる。このような対策機能の例には、物理的な障害物またはシールドの実装、ＪＴＡＧおよび他のポートの無効化、攻撃ベクトルを排除するようにソフトウェアインターフェースを強化、信頼できる実行環境（ハードウェアまたはソフトウェア、またはその両方）の使用、オペレーティングシステムのルートアクセスまたはセキュリティ破壊の招来の検出などがある。
開示の目的のため、安全であることは、一般に、秘密であること（暗号化されていること）、認証されていること、および完全性が検証されていることと考えられている。しかし、本開示はそれに限定されず、「安全」という用語はこれらの態様のサブセットであってもよく、またはデータセキュリティに関連する追加の態様を含んでもよいことを理解されたい。
通信インターフェース２１４は、有線または無線を含む、本明細書で説明する通信リンクのタイプのいずれかを含む、任意のタイプの通信リンクとすることができる。通信インターフェース２１４は、外部または内部の、またはその両方の通信を容易にすることができる。例えば、通信インターフェース２１４は、ブルートゥース（登録商標、以下同様）ローエナジー規格による無線通信や、Ｗｉ−Ｆｉイーサネット（登録商標、以下同様）通信リンクを介するクラウド１３０など、デバイス１１０の形態の別のシステム電子デバイス２００との無線通信リンクを提供することができる。別の例では、通信インターフェース２１４は、複数のデバイス間の通信を容易にするＣＡＮベースの有線ネットワークなどの有線リンクを介して、機器コンポーネント１４０（例えば、車両コンポーネント）と通信するように構成することができる。一実施形態の通信インターフェース２１４は、ユーザー１０に情報を通信し、および／またはユーザー１０から情報を受信するためのディスプレイおよび／または入力インターフェースを含むことができる。
図２に示す一実施形態では、電子システムコンポーネント２００は、別の電子システムコンポーネント２００またはユーザー以外の１つまたは複数の補助デバイス３００と通信するように構成されてもよい。補助デバイス３００は、電子システムコンポーネント２００とは異なって構成されることができ、例えば、補助デバイス３００は、プロセッサ２１０を含まず、代わりに、電子システムコンポーネント２００との情報の送信または受信、もしくはその両方のための少なくとも１つの直接接続および／または通信インターフェースを含んでもよい。例えば、補助デバイス３００は、電子システムコンポーネント２００からの入力を受け入れるソレノイドであってもよく、または補助デバイス３００は、電子システムコンポーネント２００にアナログおよび／またはデジタルフィードバックを提供するセンサ（例えば、近接センサ）であってもよい。
Ｃ．マイクロロケーション
図示の実施形態のシステム１００は、デバイス１１０に関してリアルタイムで位置情報を決定するように構成されてもよい。図１の図示の実施形態では、ユーザー１０は、デバイス１１０（例えば、スマートフォン）を携帯することができる。システム１００は、機器へのアクセスまたは機器コマンドの許可が与えられるべき位置にユーザーが位置しているかどうかを判定するのに十分な精度でリアルタイムに、機器１４０（例えば、車両）に対するデバイス１１０の位置特定を容易にすることができる。
例えば、機器１４０が車両である車両の分野では、システム１００は、デバイス１１０が車両の外部にあるが、例えば、運転者側のドアまで５フィート、３フィート、または２フィート以下のようにすぐ近くであるかどうかの決定を容易にすることができる。この決定は、システム１００が車両をアンロックすべきかどうかを識別するための基礎をなすことができる。一方、システム１００が、デバイス１１０は車両の外部にあり、運転者側ドアのすぐ近くにない（例えば、２フィート、３フィート、または５フィートの範囲外にある）と判定した場合、システム１００は、運転者側ドアをロックすることを決定することができる。別の例として、システム１００が、デバイス１１０は運転者側シートのすぐ近くにあるが、パッセンジャーシートまたはリヤシートの近くではないと判断した場合、システム１００は、車両の始動を可能にすることを決定することができる。逆に、デバイス１１０が運転者側シートの近接範囲外であると判定された場合、システム１００は、車両を不動にすることまたは不動を維持することを決定することができる。
この状況における車両はまた、図３の図示された実施形態に関連して説明され、センサおよびセンサハブ構成とともに図１６および図１７に示される、遠隔デバイス３１０と類似する１つまたは複数のセンサのような他のタイプの機器１４０を含むことができる。図１６のセンサおよびセンサハブ構成を形成する機器１４０は、センサおよびセンサハブから受信した情報の認証を容易にするために、本明細書で説明される１つまたは複数の鍵を含むことができる。１つまたは複数の鍵は、センサまたは遠隔デバイス３１０および／またはセンサハブと共に使用するために、システム１００に組み込むことができることに留意されたい。システム１００の機器デバイスまたは他のコンポーネントと構造が類似する１つまたは複数の追加の鍵は、ＳＣＭ１２０およびセンサネットワーク内のセンサ／センサハブに存在してもよい。加えて、または代替として、システム１００の１つまたは複数のこれらの鍵および／または１つまたは複数の他の鍵は、センサネットワークにおけるセンサ／センサハブの真正性を識別し、その参加を承認するために使用されてもよい。
機器１４０のマイクロロケーションは、全地球測位システム、デバイス１１０からの通信の１つ以上の信号特性、および１つまたは複数のセンサ（例えば、近接センサ、リミットスイッチ、または視覚センサ）、またはそれらの組み合わせから得られた情報を使用するなど、様々な方法で決定することができる。システム１００を構成することができるマイクロロケーション技術の一例は、２０１７年４月１４に出願され、「リアルタイムロケーションを確立するためのシステムおよび方法」と題する、Raymond Michael Stittらの米国特許出願第１５／４８８１３６に記載され、その開示は、全体が参照により本明細書に組み込まれる。より詳細には、図３の図示された実施形態に描かれた一例では、ＳＣＭ１２０および複数の遠隔デバイス３１０（デバイス１１０といくつかの点で類似）は、機器コンポーネント１４０に対して固定された位置に配置することができる。機器コンポーネント１４０の例示のユースケースは、先の例で特定された車両、または機器コンポーネント１４０によってアクセスが制御される建物を含む。
デバイス１１０は、通信リンクを介してＳＣＭ１２０と無線で（例えば、ブルートゥースローエナジーを介して）通信することができる。複数の遠隔デバイス３１０は、デバイス１１０とＳＣＭ１２０との間の通信を傍受して、信号強度などの通信の１つ以上の信号特性を決定するように構成されてもよい。決定された信号特性は、デバイス１１０とＳＣＭ１２０との間の通信リンクとは別の通信リンクを介して、ＳＣＭ１２０に通信されるか、または分析された後に通信されてもよい。追加的にまたは代替的に、デバイス１１０は、１つまたは複数の遠隔デバイス３１０との直接の通信リンクを確立してもよく、１つ以上の信号特性は、この直接通信リンクに基づいてを決定されてもよい。
一例として、図示の実施形態に示すように、デバイス１１０からＳＣＭ１２０への通信の伝播波が示され、３０２、３０４、３０６で明示されている。デバイス１１０（ソース）からの距離が大きいほど、無線通信の強度は小さくなる。伝播波３０６に関する通信の強度は、伝播波３０２の強度よりも小さい。さらに、時間Ｔ０において通信が送信された場合、伝播波３０２での通信のための移動時間（ＴＰ１−Ｔ０）は、伝播波３０６での通信のための移動時間（ＴＰ３−Ｔ０）よりも短い。その結果、遠隔デバイス３２０が伝播波３０２で通信を受信した場合、通信の到着のタイムスタンプは、通信が伝播波３０６で受信された場合よりも早くなる。信号強度および到着時間などの１つ以上の信号特性が、ＳＣＭ１２０に対するデバイス１１０に関する位置情報を決定するために、解析されてもよい。例えば、遠隔デバイス３１０とＳＣＭ１２０との間の到着の時間差が、デバイス１１０の相対位置を決定するために処理されてもよい。ＳＣＭ１２０に対する１つまたは複数の遠隔デバイス３１０の位置は、デバイス１１０の相対位置が遠隔デバイス３１０およびＳＣＭ１２０に対する絶対位置に変換されることができるように、既知であってもよい。信号特性の追加的または代替的な例は、距離関数、三辺測量関数、三角測量関数、多辺測量関数、指紋関数、微分関数、飛行時間関数、到着時間関数、到着時間差関数、到着角度関数、出発角度関数、幾何学関数など、またはそれらの任意の組み合わせを含む、１つまたは複数のアルゴリズムに従って位置を決定することを容易にするために取得されてもよい。
図示の目的のために、伝播波３０２、３０４、３０６は一様な円形として描かれているが、伝播波は、干渉または指向性アンテナの使用などの他の要因に依存して形状が変化してもよいことに留意されたい。
一実施形態では、デバイス１１０とＳＣＭ１２０との間の通信に関する情報は、複数の遠隔デバイス３２０に提供されてもよい。例えば、ブルートゥースローエナジーチャネルに関する接続パラメータは、複数の遠隔デバイス３２０が通信を監視することができるように、遠隔デバイス３２０に提供されてもよい。例えば、通信チャネルは、パケットごとにまたはパケット内で送信されるビットの中で、送信の周波数など、通信中に１つまたは複数のパラメータを変更するかもしれない。これらの１つ以上の可変パラメータは、パケットまたは通信の受信を可能にするために遠隔デバイスに３２０に通信されてもよい。
システム１００、システムコンポーネントを認証する、システムコンポーネント間でメッセージを安全に転送する、制約付きリンクを介して安全な通信チャネルを確立する、メッセージコンテンツを認証する、アクションを承認する、および、デバイス・アズ・ア・キーシステムでのユーザーシステムコンポーネントの中で承認及び構成データを配信する、の中の１つまたは複数を容易にするために、本明細書で説明されるように、セキュリティモデルを利用することができる。
ＩＩ．承認
本明細書で説明するように、システム１００は、１つまたは複数の権利をデバイス１１０に関連付けることができ、システム内の１つ以上の権利を利用する認可を容易にする。本明細書で論じられるように、認可は、（特定のユーザー１０の代理として機能する）デバイス１１０が、ＳＣＭ１２０および／またはデバイス１１０に固有のものであってもよい、１つまたは複数の（アクセス属性としても説明される）制約内で、（特定の機器の代理として機能する）ＳＣＭ１２０とやり取りすることを可能にするアクセス権または一般的な権利である。
一実施形態では、鍵（信用証明書または仮想／電子／モバイル鍵）がデバイス１１０に配信され、その鍵は、検証（またはそのいくつかのバリエーション）のために、使用時にＳＣＭ１２０に受け渡される。
システム１００の図示された実施形態では、デバイス１１０自体（そのアイデンティティ）が鍵であり、ＳＣＭ１２０は、ＳＣＭ１２０がデバイス１１０のために設定することができる１つ以上の認可に基づいて、デバイス１１０の所望のアクションを承認することができる。デバイス１１０の「アイデンティティ」は、１つ以上の暗号のアイデンティティまたはデバイス１１０に固有の任意の他の識別子、またはそれらの複合および／またはそれらの任意の組み合わせであってもよい（または、基づくものであってもよい）。暗号識別子の例には、非対称暗号で生成された鍵のペアなどの固有の公開／非公開鍵、対称暗号で生成された鍵などの共有秘密鍵が含まれる。デバイス１１０に固有の別の識別子の例は、ハードウェアシリアル番号、ハードウェアセキュリティモジュール（ＨＳＭ）、および１つ以上のアプリケーションインスタンス識別子を含む。１つ以上の暗号アイデンティティおよび／またはデバイス１１０の１つ以上の他の識別子の組み合わせの例には、複数の暗号アイデンティティおよび暗号アイデンティティと非暗号アイデンティティが含まれる。
デバイス１１０は、同じＳＣＭ１２０に対する複数の認可、または別のＳＣＭ１２０に対する異なる認可を含む、任意の所与の時点でゼロ以上の認可を有することができる。認可は、デバイス１１０がＳＣＭ１２０と通信することを可能にする、複数のデバイス１１０と複数のＳＣＭ１２０を相互に認証する、およびデバイス１１０がＳＣＭ１２０とやり取りすることができる条件を特定する、との中の１つまたは複数を容易にすることができる情報を提供するので、認可は本明細書で説明するセキュリティモデルの有用な部分である。認可は、認証のための有用な情報に加えて、ＳＣＭ１２０に対する各デバイス１１０のために、アクセス属性を定義することができる。一実施形態によるアクセス属性は、以下の１つまたは複数を含むことができる。
１）タイプ（例えば、オーナー、ゲスト、バレットなど）−標準。様々な認可タイプは、異なる認可配信／共有の権限との結果をもたらす（例えば、オーナーは、別のデバイスをオーナーにすることはできるが、ゲストなどにはできない）。オーナー（または他のタイプの）権限を持つユーザーのみがアクセスできるコマンドまたは他のシステムレベルの機能があってもよい。追加情報については、認可タイプセクションＶＩＩを参照。
２）有効なタイムスタンプ範囲開始−標準。
３）有効なタイムスタンプ範囲終了−オプション。存在する場合、認可が、特定の日付／時刻に自動的に取り消されることがある。
４）有効なスケジュール−オプション。存在する場合、認可は、定義されたスケジュール（例えば、一週間の各曜日、月間スケジュール、またはカスタムスケジュールで、どの時間に利用されるかを指定する定期的な週間スケジュール）ごとにのみ使用され得る。
５）有効な使用回数−オプション。存在する場合、認可は、設定された回数（例えば、コマンドの数、使用された日数／時間の数）まででのみ使用され得る。
６）追加の認証タイプと識別子−オプション。存在する場合、認可は、システムが既に提供しているもの（例えば、デバイスアンロック／ログイン／ボタン押下／パスコード入力／親指の指紋／特定のコマンドを発するため別のデバイスなどの存在の要求）を超える追加の（アクティブまたはパッシブ）認証を利用することができる。
７）配信権−オプション。存在する場合、ＳＣＭ１２０のために別のデバイス１１０に新しい認可を発行するため、デバイス１１０が有する権利を識別および／または記述する権利管理サービス（本明細書の説明を参照）における認可の権限が参照される。言い換えると、配信権は、デバイス１１０が他のデバイスと認可を共有するためのデバイス１１０の権利に関係する。存在しない場合、少なくとも１）項およびセクションＶＩＩに記載される認可タイプに完全にまたは部分的に基づいてもよい。代替の実施形態では、相互チェックを行うなどして、認可タイプとデジタル権利管理サービスの両方を一緒に使用することができる。
８）命令権−オプション。存在する場合、特定のコマンドまたは応答もしくはその両方を発行し、または受信し、もしくはその両方を行うために、デバイス１１０が有する権利を識別および／または記述する権利管理サービス（本明細書の説明を参照）における認可の権限が参照される。例えば、デバイス１１０は、ドアを開くコマンドを発行することができるが、それを閉めることはできない。権利は、コマンド単位またはクラス単位で付与することができる。存在しない場合、命令権は、少なくとも１）項およびセクションＶＩＩに記載される認可タイプに完全にまたは部分的に基づいてもよい。代替の実施形態では、相互チェックを行うなどして、認可タイプとデジタル権利管理サービスの両方を一緒に使用することができる。別の代替の実施形態では、認可されたコマンドのリスト（および他の必要であり得るメタデータ）が代りに提供されてもよい。さらに別の代替の実施形態では、禁止されたコマンドのリスト（および他の必要であり得るメタデータ）が代わりに提供されてもよい。
９）ＳＣＭ１２０が相互作用を許可または拒否する他の可能性のある属性。一実施形態では、デバイス１１０がそのような安全な通信のための認可を所有するときにのみ、デバイス１１０はＳＣＭ１２０と安全に通信することができるが、デバイス１１０がＳＣＭ１２０と安全でない通信を行うかもしれないシナリオまたは状況がありえることが理解されたい。
すべての属性がＳＣＭ１２０またはデバイス１１０に通信される必要はないことに留意されたい。例えば、いくつかの属性は、クラウド１３０内にのみ存在してもよい。
ＳＣＭ１２０は、以下のうちの少なくとも１つに基づいて、リクエスト、コマンド、アップデート、およびレスポンスのうちの１つまたは複数を送信または受信する、またはその両方を行うように、デバイス１１０を認可することができる。
１）１つ以上の認可が認証されている（例えば、少なくともセクションＩＩＩのＡＣＰ参照）。
２）１つまたは複数の認証された認可において、すべてまたはいくつかの潜在的に必要な条件が満たされる。
３）デバイス１１０が認証されている。このように、上記の条件に加えて、各認可は、暗号鍵（例えば、Device-SCM-Keyおよび／またはUser-SCM-Key）と、デバイス１１０がターゲットＳＣＭ１２０との暗号化された通信リンクを確立するため、デバイス１１０がターゲットＳＣＭ１２０を認証するため、およびターゲットＳＣＭ１２０がデバイス１１０を認証するために使用されるデータとを含んでもよい。このような状況でデバイス１１０のために使用されるデータが、セクションＸＩＩで鍵システムとしても特定される、システム鍵記述セクションにおいてさらに詳細に記載される。
ＩＩＩ．承認パッケージ
一実施形態では、情報は、図４の一実施形態に従って示され、４００で指定される認可設定パッケージ（ＡＣＰ）を介して安全な方法でＳＣＭ１２０に通信することができる。ＡＣＰ４００は、ＳＣＭ１２０に送信されることができる認可または他の設定データ、またはその両方を含むことができる。１つ以上のデバイス１１０が、ＡＣＰ４００をＳＣＭ１２０に送信してもよいが、ＡＣＰ４００は、他のデバイスを介してＳＣＭに送信されてもよく、本開示は、デバイス１１０を介した送信に限定されないことを理解されたい。
ＡＣＰ４００は、図５の一実施形態に従って示されるように、ＡＣＰコンテナコレクション４１４内にカプセル化され得るＡＣＰコンテナ４１０にカプセル化することができる。ＡＣＰ４００、ＡＣＰコンテナ４１０またはＡＣＰコンテナコレクション４１４、もしくはそれらの任意の組み合わせは、シーケンス化された多層暗号化に基づくものであってもよい。ＡＣＰコンテナ４１０は、ネストされた層を含むことができ、各層は異なる暗号鍵に従って各層を暗号化するなど異なる方法で暗号化されてもよい。このようにして、ネストされた層は、タマネギの層として概念化することができ、外側の層を解読することなく各内側の層にアクセスすることはできない。
一実施形態では、ＡＣＰコンテナ４１０は、分散システムを介して設定データをＳＣＭ１２０に配信するための安全手段であってもよい。図示の実施形態におけるＡＣＰコンテナ４１０は、クラウド１３０によってデバイス１１０に配信されてもよい。ＡＣＰコンテナ４１０は、次のうちの１つ以上を提供する方式で、シーケンス化された多層暗号化を利用することができる。
・デバイスまたは通信セキュリティ（例えば、安全ではない通信リンクを使用する安全ではないデバイス）に係らず、実質的に保証された機密性と完全性。
・実質的に保証された真正性と、複数の認証されたシステムコンポーネントがＡＣＰ４００の内容を承認したこと（例えば、オーナーデバイス１１０、そのユーザー、および、本明細書に記載されるように、別個のクラウド認可要求とクラウド認可承認サービスが使用される場合に、例えば、２つ以上のクラウドサービス１３０を含む、１つまたは複数のクラウドサービス１３０）。
・ＡＣＰ４００がターゲットＳＣＭ１２０向けであり、他のシステムコンポーネントがＡＣＰ４００の無認可の内容を解読できないことの実質的な保証。
・システム１００の状態の実質的な保証（例えば、適切なシステムコンポーネントが定義された順序で構成を承認したこと）。
・ターゲットＳＣＭ１２０が以前にデバイス１１０と通信したことがない場合であっても、デバイス１１０とターゲットＳＣＭ１２０との間の通信リンクのみを使用して認証および認可を実行することの許可（例えば、インターネットから切断されたとき、デバイス１１０もＳＣＭ１２０もいずれのクラウドサービス１３０にもアクセスしていないとき、言い換えると、デバイス１１０とＳＣＭの両方がオフラインであるとき、認証が実行されてもよい）。
クラウド１３０によって実施される認可変更プロセスおよびパッケージ層の暗号化シーケンスとともに、ＡＣＰコンテナ４１０の構造は、ターゲットＳＣＭ１２０のみが、ＡＣＰコンテナ４１０の全体を復号することができること、および、複数のシステムコンポーネント（例えば、ユーザー１０、クラウド１３０、およびオーナーデバイス１１０、またはそれらの組み合わせ）がＡＣＰ４００を承認したことを保証することができる。ＡＣＰコンテナ４１０の暗号化シーケンスは、最内層（最後に復号される）から最外層（最初に復号される）まで、さらに詳細に後述される。ＡＣＰコンテナ４１０の構造は、アプリケーションによって異なる場合がある。しかしながら、図示された実施形態では、ＡＣＰコンテナ４１０は、インテグリティハッシュ（例えば、暗号ハッシュおよび／または署名）、タイムスタンプ、バージョン、送信器アイデンティティ、受信機アイデンティティ、および他のデータロケーション並びにカプセル化属性（図４または図５に示さず）の少なくとも１つを含むことができる。
全ての必要な認可された層が解読され、認証され、完全性検証され、整合性のため属性が複数の層に渡って検査された後、ＡＣＰコンテナ４１０または（ＡＣＰ４００を含む）いずれかの層は、ＳＣＭ１２０によって処理および／または格納される。図示された実施形態では、ＳＣＭ１２０は、ＡＣＰコンテナ４１０のすべての層を処理し、および復号する権限が与えられるが、ＳＣＭ１２０が、処理または復号する権限が与えられないか、処理または復号するように構成されない、ＡＣＰコンテナ４１０のさらなる層があってもよいことを理解されたい。ＡＣＰコンテナ４１０は、多数の層を有すると本明細書で説明しているが、ＡＣＰコンテナの層数および構成または構造は、アプリケーションに応じて変更してもよいことにも留意されたい。（ＡＣＰ４００を含む）ＡＣＰコンテナ４１０の任意の部分が格納されてもよいが、そのような層は、受信された（暗号化された）フォーマットとして、受信されたが復号されたフォーマットとして、代わりの（例えば、格納効率またはランタイム検索のために最適化された）フォーマットで、またはそれらの任意の組み合わせで、格納されてもよいことも理解されたい。
Ａ．ＡＣＰ外層１
図４に示す実施形態では、ＡＣＰ４００は、４０１で指定されるＡＣＰ外層１内に含まれる。ＡＣＰ外層１は、ＡＣＰ４００が、クラウド１３０から生じ、ターゲットＳＣＭ１２０に向けられたものであることを確認することができる。クラウド１３０は、ターゲットＳＣＭ１２０とクラウド１３０によって定義されるペアに固有であり得る（本明細書の少なくともセクションＸＩＩでより詳細に説明されるCloud-SCM-Key鍵などの）鍵で、ＡＣＰ外層１を暗号化することができる。一実施形態では、オプションで、クラウド１３０、ターゲットＳＣＭ１２０、およびそのターゲットＳＣＭ１２０に対する認可を有するデバイス１１０のみが、このＡＣＰ外層１を復号することができてもよい。
代替的な実施形態では、ＡＣＰ外層１を暗号化するために利用される鍵は、ターゲットＳＣＭ１２０とクラウド１３０によって定義されるペアに固有ではないCloud-SCM-Key鍵であってもよい。例えば、複数のＳＣＭ１２０のシステム内におけるすべてのＳＣＭ１２０の間で共有される共通鍵が利用されてもよい。一実施形態では、Cloud-SCM-Key鍵が存在しない場合、ＡＣＰがクラウド１３０から生じ、ターゲットＳＣＭ１２０に向けられたものであるとの検証は、Cloud-SCM-Keyの使用に限定されない別の方法で達成することができる。代替の実施形態では、システム１００は、Cloud-SCM-Keyに基づくＡＣＰ外層１の検証を利用しなくてもよく、代わりに他の層の暗号化およびシーケンシングまたはクラウド１３０の認証（本明細書で説明する）に依拠してもよい。
Ｂ．ＡＣＰ外層２
図４の図示された実施形態では、ＡＣＰ外層１は、４０２で指定されるＡＣＰ外層２内に含まれる。ＡＣＰ外層２は、ターゲットＳＣＭ１２０のための（クラウド１３０から生じた）ＡＣＰ４００が、ターゲットＳＣＭ１２０のためのオーナーデバイス１１０にて、ユーザー１０によって検視され承認されたことを確認することができる。クラウド１３０のユーザーアカウントサービスは、本明細書の少なくともセクションＸＩＩでより詳細に説明されるUser-SCM-Key鍵のような鍵でＡＣＰ外層２を暗号化することができ、その鍵は、ターゲットＳＣＭ１２０とデバイス１１０と関連付けられたユーザーアカウントによって定義されるペアに固有であり得る。一実施形態では、認可が、ターゲットＳＣＭ１２０のためユーザーアカウントに対して発行されてもよく、それにより、そのユーザーアカウントに関連付けられたすべてのデバイス１１０が認可される。
一実施形態では、オプションで、ＡＣＰ４００を承認したユーザーアカウントに関連付けられたクラウド１３０、ターゲットＳＣＭ１２０、およびデバイス１１０のみが、ＡＣＰ外層２を復号することができる。
代替の実施形態では、デバイス１１０は、本明細書の少なくともセクションＸＩＩでより詳細に説明されるDevice-SCM-Key鍵のような鍵でＡＣＰ外層２を暗号化することができ、その鍵は、ターゲットＳＣＭ１２０とデバイス１１０によって定義されるペアに固有であり得る。一実施形態では、認可が、特定のデバイス１１０に対してターゲットＳＣＭ１２０のために発行されてもよい。一実施形態では、オプションで、クラウド１３０、ターゲットＳＣＭ１２０、およびＡＣＰ４００を承認したターゲットＳＣＭ１２０のための特定のオーナーデバイス１１０のみが、ＡＣＰ外層２を復号することができる。
代替の実施形態では、ＡＣＰ外層２は、ターゲットＳＣＭ１２０とデバイス１１０またはユーザーアカウントによって定義されたペアに固有ではないDevice-SCM-KeyまたはUser-SCM-Key鍵で暗号化されてもよい。例えば、複数のＳＣＭ１２０のシステム内におけるすべてのＳＣＭ１２０の間で共有される共通鍵が利用されてもよい。一実施形態では、Device-SCM-KeyまたはUser-SCM-Key鍵がCloud-SCM-Key鍵と異なる場合、またはDevice-SCM-KeyまたはUser-SCM-Keyが存在しない場合、ＡＣＰ４００が、ターゲットＳＣＭ１２０のためのオーナーデバイス１１０のユーザー１０によって検視され承認されたことの検証は、Cloud-SCM-Keyの使用に限定されない別の方法で達成することができる。代替の実施形態では、システム１００は、Cloud-SCM-KeyまたはUser-SCM-Keyに基づくＡＣＰ外層２の検証を利用しなくてもよく、代わりに他の層の暗号化およびシーケンシングまたはクラウドの認証（本明細書で説明する）に依拠してもよい。
Ｃ．ＡＣＰ外層３
図４の図示された実施形態では、ＡＣＰ外層２は、４０３で指定されるＡＣＰ外層３内に含まれる。ＡＣＰ外層３は、ターゲットＳＣＭ１２０のための（クラウド１３０から生じた）ＡＣＰ４００が、ターゲットＳＣＭ１２０のためのオーナーデバイス１１０にてユーザー１０によって検視され承認され、ターゲットＳＣＭ１２０のためのオーナーデバイス１１０にて、（本明細書に記載される）帯域外認証メカニズムを介して、変更されずに、ユーザー１０によって承認されたことをクラウド１３０によって確かめられたことを確認することができる。クラウド１３０は、少なくともセクションＸＩＩで本明細書においてより詳細に説明されるSCM-Key鍵のような鍵でこの層を暗号化することができ、その鍵は、ターゲットＳＣＭ１２０に固有であり得る。一実施形態では、ターゲットＳＣＭ１２０のみがＡＣＰ外層３を復号することができる。ＡＣＰ外層２は、潜在的に複数のオーナーアカウント（User-SCM-Key鍵）および／またはデバイス１１０（Device-SCM-Key鍵）のうちの１つによって暗号化され得るので、この層のメタデータは、どのアカウントおよび／またはデバイス１１０がＡＣＰ外層２を署名したかの表示（例えば、Device-SCM-EDまたはUser-SCM-ID）を含む。
代替の実施形態では、ＡＣＰ外層３は、ターゲットＳＣＭ１２０に固有ではないSCM-Key鍵で暗号化されてもよく、複数のＳＣＭ１２０のシステム内におけるすべてのＳＣＭ１２０の間で共有される共通鍵が利用されてもよい。一実施形態では、SCM-Key鍵がDevice-SCM-Key鍵と異なるものではない場合、またはSCM-Keyが存在しない場合、ターゲットＳＣＭ１２０のためのオーナーデバイス１１０にて、（本明細書に記載される）帯域外認証メカニズムを介して、変更なしで、ユーザー１０によってクラウド１３０がＡＣＰ４００を承認したことの検証は、SCM-Key鍵の使用に限定されない別の方法で達成することができる。代替の実施形態では、システム１００は、SCM-Keyに基づくＡＣＰ外層３の検証を利用しなくてもよく、代わりに他の層の暗号化およびシーケンシングまたはクラウドの認証（本明細書で説明する）に依拠してもよい。帯域外認証がこの検証に含まれるすべての実施形態では、帯域外認証が完全に除去されるか、特定のタイプの変更にのみ必要とされる代替構成が存在する。
Ｄ．ＡＣＰ外層４
図４の図示された実施形態では、ＡＣＰ外層３は、４０４で指定されるＡＣＰ外層４内に含まれる。ＡＣＰ外層４は、完成したＡＣＰコンテナ４１０がクラウド１３０から生じて、クラウド１３０によって承認され、ターゲットＳＣＭ１２０に向けられたものであることを確認することができる。クラウド１３０は、少なくともセクションＸＩＩで本明細書においてより詳細に説明されるCloud-SCM-Approval-Key鍵のような鍵でＡＣＰ外層４を暗号化することができ、その鍵は、ターゲットＳＣＭ１２０とクラウド１３０によって定義されるペアに特有であり得る。一実施形態では、オプションで、クラウド１３０、ターゲットＳＣＭ１２０、およびそのターゲットＳＣＭ１２０のための認可を有するデバイス１１０のみが、ＡＣＰ外層４を復号することができる。
一実施形態では、クラウド認可要求およびクラウド認可承認サービスは分離することができないので、ＡＣＰ外層４は、少なくともセクションＸＩＩで本明細書においてより詳細に説明するCloud-SCM-Key鍵で暗号化されてもよく、その鍵は、ターゲットＳＣＭ１２０およびクラウド１３０によって定義されるペアに固有のものであってもよい。
一実施形態では、ＡＣＰ外層４は、ターゲットＳＣＭ１２０とクラウド１３０によって定義されるペアに固有ではないCloud-SCM-Approval-KeyまたはCloud-SCM-Key鍵で暗号化されてもよい。例えば、複数のＳＣＭ１２０のシステム内のすべてのＳＣＭ１２０の間で共有される共通鍵が利用されてもよい。一実施形態では、Cloud-SCM-Approval-KeyまたはCloud-SCM-Key鍵がSCM-Key鍵と異なるものではない場合、またはCloud-SCM-Approval-KeyまたはCloud-SCM-Keyが存在しない場合、完成したＡＣＰコンテナ４１０がクラウド１３０から生じて、クラウド１３０によって承認され、ターゲットＳＣＭ１２０に向けられたものであるとの検証は、別の方法で達成されてもよい。代替の実施形態では、システム１００は、Cloud-SCM-Approval-KeyまたはCloud-SCM-Keyに基づくＡＣＰ外層４の検証を利用しなくてもよく、代わりに、他の層の暗号化およびシーケンシングまたはクラウドの認証（本明細書で説明する）に依拠してもよい。
セキュリティモデル内で利用されるＡＣＰコンテナ４１０の構造は、認証と認可の分離を達成するか、または実質的に達成することができる。セキュリティモデルは、これらのアクションを異なるサービスおよび構造に分離してもよいが、セキュリティモデルは、認証および認可を、別々に認証された２つの別々のツリー（すなわち、別々の信頼ルーツ）に明示的に分離しないかもしれない。代わりに、認証および認可ツリーは、分散暗号化およびシーケンス復号によって別個に認証されてもよい。認証と認可の分離は、（デバイス１１０に加えて）ＡＣＰコンテナ４１０を生成および／または解読するためには、複数の別個の物理的クラウドサーバー１３０から鍵を取得することをハッカーに要求することによって近似することができる。
認証と認可の分離を近似するための一構成例は、ａ）最初のＡＣＰ４００を生成し、ユーザー１０にＡＣＰ４００を承認することを要求するサービス（クラウド認可要求サービス）と、ｂ）ユーザー１０が最初のＡＣＰ４００を承認し、最終的なＡＣＰコンテナ４１０を生成するサービス（クラウド認可承認サービス）とを分離することである。一実施形態において、ＡＣＰ外層４で使用される鍵（例えば、クラウド認可承認サービスによって使用されるCloud-SCM-Approval-Key）は、ＡＣＰ外層１で使用される鍵（例えば、クラウド認可要求サービスによって使用されるCloud-SCM-Key）とは違ってもよい。一実施形態では、クラウド認可承認サービスなどのＡＣＰ外層４に署名するクラウドサービス１３０は、クラウド認可要求サービスなどのＡＣＰ外層１に署名するクラウドサービス１３０とは別のサーバー上にある。
ＩＶ．ＡＣＰコンテナの配信
一実施形態では、ＡＣＰコンテナ４１０は、ターゲットＳＣＭ１２０のためのすべての現行の認可を含むことができる。クラウド１３０は、ＳＣＭ１２０のためのＡＣＰ４００内に含まれるデータがプッシュメカニズムを介して変化するたびに、完全な（すなわち、部分更新ではない）ＡＣＰコンテナ４１０を生成および／または更新し、すべての関連するデバイス１１０に自動的に配信することができる。変化の例は、ａ）ＳＣＭ１２０について追加、変更、および取り消しの少なくとも１つがなされた、ＡＣＰ４００内のデータと認可、ｂ）工場リセットするよう指示されたＳＣＭ１２０、ｃ）認可された最初のオーナーデバイス、およびｄ）循環された暗号鍵を含む。
Ａ．ＡＣＰコンテナのプッシュ
プッシュメカニズムは、すべてのＡＣＰコンテナ４１０の配信に使用してもよいし、またはプッシュメカニズムの使用は、特定の変更および／またはイベントに応答してのＡＣＰコンテナ４１０の配信に限定してもよい。関連するデバイス１１０は、現行の認可を有している、または以前に１つ以上の認可を有していたが、ターゲットＳＣＭ１２０のための、更新されたＡＣＰコンテナ４１０（例えば、ＳＣＭ１２０がより新しいＡＣＰ４００を有する）をまだ送信されてしないデバイス１１０とみなされてもよい。現行の認可は、取り消され（すなわち、除去され、無効化され、削除され）ておらず、期限切れとなっていない認可（すなわち、有効である認可）である。使用されるプッシュメカニズムは、限定されないが、モバイル、ウェブ、またはデスクトッププラットフォームプッシュ通知サービス（例えば、ウェブソケット、Appleプッシュ通知サービス（ＡＰＮＳ）、Googleクラウドメッセージング（ＧＣＭ）およびアーバンエアシップ）と、持続的なポーリングに基づくデバイス−クラウド間接続またはロングポーリングに基づくデバイス−クラウド間接続または類似のデバイス−クラウド間接続と、メッシュ、スター、および／または他のトポロジのデバイス間メッセージングと、そして、ＳＭＳと、の任意の組み合わせを含み、デバイス１１０のタイプに基づいて変更されてもよい。
プッシュメカニズムは、（デバイス１１０が即座に、または後でＡＣＰコンテナ４１０を要求できるように）ＡＣＰコンテナ４１０を直接配信してもよいし、または更新されたＡＣＰコンテナ４１０をデバイス１１０に通知してもよい。デバイス１１０は、クラウド１３０が代わりのプッシュメカニズム（例えば、ＳＭＳ）を使用していたり、プッシュメカニズムを使用していなかったり（例えば、デバイス１１０がＡＣＰコンテナ４１０の更新を周期的に問い合わせる）した場合、所定のタイプのプッシュメカニズム（例えば、ＡＰＮＳ）を禁じるように構成されてもよい。別の実施形態では、システム１００は、ＡＣＰコンテナ４１０の配信のために、常にプッシュメカニズムを使用してもよい。別の実施形態では、システム１００は、ＡＣＰコンテナ４１０の配信のために、プッシュメカニズムを使用しないかもしれないし、いつもプッシュメカニズムを使用するとは限らない。別の実施形態では、システム１００は、関連するデバイス内で（現行の、または現行ではない）認可を持つすべてのデバイス１１０にＡＣＰコンテナ４１０を配信するために、プッシュメカニズムを使用してもよい。別の実施形態では、システム１００は、関連するデバイス内で、現行の認可のみを配信するようにＡＣＰコンテナ４１０を配信してもよい。別の実施形態では、現行の認可の範囲が、固定のまたは設定可能な所定の時間（例えば、クラウドごと、デバイスごと、ＳＣＭごと、機器ごと）内に失効した認可を含むように拡張されてもよい。例えば、配信される現行の認可は、最近２日間に失効した認可を含んでもよい。
図示の実施形態では、クラウド１３０は、現行の認可のない関連するデバイス１１０に現行のＡＣＰコンテナ４１０を配信することができる。別の実施形態では、クラウド１３０は、デバイス１１０がもはやいずれの現行の認可を持たない場合、第１のバージョンのＡＣＰコンテナ１１０を、現行の認可のない各々の関連するデバイス１１０に送信してもよい。
デバイス１１０は、特定のイベントが発生したとき、自動的に、ＳＣＭ１２０のための（または、デバイス１１０が現行の認可を有するすべてのＳＣＭ１２０のための）、現在承認されているＡＣＰ４００をクラウド１３０から要求することができる。例示的なイベントには、アプリケーションが実行状態（例えば、開始、一時停止、再開、停止、または終了）を変更したとき、または定期的にＳＣＭ１２０および／またはクラウド１３０への接続が確立されたとき、またはユーザーによって要求されたとき、その直後のリセットが含まれる。１つまたは複数の代わりの実施形態では、上記の配信および／または要求トリガの組合せのすべての順列が実行されえる。
１つまたは複数のＳＣＭ１２０または１つまたは複数のデバイス１１０、もしくはそれらの任意の組み合わせは、クラウド１３０への通信リンクが利用できない環境に置かれてもよい。例えば、通信リンクが、存在しなくてもよく、または、別のデバイスまたは機器コンポーネント１４０を介して通信リンクをルーティングするなど、他のシステムコンポーネントを介して間接的に、を含む、何らかの手段によって利用できなくてもよい。そのような通信リンクの欠如は、永続的であっても、一時的であってもよい。
一実施形態では、主として、ＳＣＭ１２０がデバイス１１０を認可する前にクラウド１３０と通信したことは厳密には必要とされないとの理由で、システム１００のセキュリティモデルは、通信の欠如に著しく煩わされない。ＳＣＭ１２０は、デバイス１１０がＳＣＭ１２０と通信する前のある時点でクラウド１３０と通信したことを期待するだけでよい。この状況で起こり得る１つの問題は、ＳＣＭ１２０が、デバイス１１０のための認可を含むＡＣＰ４００を記憶していないと、ＳＣＭ１２０がデバイス１１０との安全な通信リンクを確立することができないことがあることである。しかし、少なくとも部分的にＡＣＰコンテナ４１０の暗号化シーケンシングまたはレイヤーリング、またはその両方により、またＡＣＰコンテナ４１０はターゲットＳＣＭによってのみ解読されるため、ＡＣＰコンテナ４１０は安全でない通信リンクによってＳＣＭ１２０に送信されてもよい。このように、ＳＣＭ１２０は、ＳＣＭ１２０が通信したことのないデバイス１１０から、および認可を所有していないデバイス１１０（または、他のシステムコンポーネント／ソース）から、を含め、任意の通信リンクを介して、任意のソースから更新されたＡＣＰ４００を受信してもよい。例えば、認可が取り消されたデバイス１１０が、更新されたＡＣＰ４００を含むＡＣＰコンテナ４１０を通信してもよい。
一実施形態では、デバイス１１０は、安全な通信リンクを確立する前に、更新されたＡＣＰ４００をＳＣＭ１２０に送信してもよい。デバイス１１０は、安全な通信リンクが確立された後に、更新されたＡＣＰ４００をＳＣＭ１２０に送信してもよい。更新されたＡＣＰ４００が接続されたデバイス１１０のための認可を含まない場合、このような既存の安全な通信リンクは終了されてもよい。一実施形態では、ＳＣＭ１２０は、ＳＣＭ１２０によって記憶されるバージョンよりも新しいバージョンのＡＣＰコンテナ４１０を有するシステムコンポーネントと安全な通信リンクを確立することを拒否してもよい。一実施形態では、ＳＣＭ１２０は、ＳＣＭ１２０によって記憶されるバージョンと一致しないバージョンのＡＣＰコンテナ４１０を有するシステムコンポーネントと安全な通信リンクを確立することを拒否しても良い。
Ｂ．ＡＣＰコンテナバージョンパッケージ
デバイス１１０が異なるＡＣＰ４００を有するかどうかを決定するために、ＳＣＭ１２０がすべてのデバイス１１０からのすべての接続でＡＣＰコンテナ４１０を受信して処理する必要性を排除することを容易にするために、ＡＣＰコンテナ４１０の最初のＮバイト（ここで、Ｎは必要とされる情報を得るために必要なバイト数であり、本明細書では、ＡＣＰコンテナバージョンパッケージ４１２としても知られる）は、（本明細書で記載される）デバイス１１０とＳＣＭ１２０との間の接続確立プロセスの一部として送信されても良く、ＳＣＭ１２０は、必要とされる情報を得るために解読することができ、必要とされる情報は、ＡＣＰバージョン、および／またはインテグリティハッシュまたは署名、またはその両方など、比較に使用される他の属性を含むことができる。一実施形態では、本明細書で説明するように、ＡＣＰコンテナバージョンパッケージ４１２は、ＡＣＰコンテナ４１０の最初のＮバイトとしてデバイス１１０に配信される（ここで、Ｎは必要とされる情報を得るために必要と考えられるバイト数である）。デバイス１１０が新しいバージョンのＡＣＰ４００を有するとＳＣＭ１２０が判定した場合、ＳＣＭ１２０は、安全な接続が確立される前に、更新されたＡＣＰ４００を提供するためにデバイス１１０を利用してもよい。代替の実施形態では、ＳＣＭ１２０は、デバイス１１０が、ＳＣＭ１２０に記憶されたＡＣＰ４００よりも新しいものではないかもしれない、異なるＡＣＰ４００を有する場合、ＡＣＰ更新プロセスを実行することを決定してもよい。ＳＣＭ１２０が、そのＳＣＭ１２０と関連付けられる最初のオーナーデバイス１１０を待機している工場リセットモードでなく、ＡＣＰコンテナバージョンパッケージ４１２が提供されていない場合、デバイス１１０への接続は拒否されるか、または終了されるか、または両方であってもよい。この工場リセットモードの動作は、少なくともセクションＸ．Ｄで、本明細書においてさらに詳細に説明される。
デバイス１１０がＳＣＭ１２０との安全な接続を既に確立している場合、ＳＣＭ１２０は、定期的にＡＣＰコンテナバージョンパッケージ４１２を送信するようデバイス１１０に要求し、そして、更新されたＡＣＰ４００が存在する場合には、デバイス１１０との接続を断ち、デバイス１１０が再接続する（斯くして、更新されたＡＣＰ４００を送信する）よう要求するか、もしくは、デバイス１１０に安全な接続を介して更新されたＡＣＰ４００を送信するよう要求する。追加的または代替的に、デバイス１１０が既にＳＣＭ１２０との安全な接続を確立している場合、デバイス１１０は、（ＡＣＰコンテナバージョンパッケージ４１２を伴って）更新されたＡＣＰ４００をＳＣＭ１２０に通知してもよく、ＳＣＭ１２０が（本明細書に説明するように）その更新は適切であると判定したならば、デバイス１１０との接続を断ち、デバイス１１０が再接続する（斯くして、更新されたＡＣＰ４００を送信する）ことを期待するか、もしくは、デバイス１１０に安全な接続を介して更新されたＡＣＰ４００を送信するよう要求する。デバイス１１０が（例えば、ある期間内に）ＡＣＰコンテナバージョンパッケージ４１２を送信する要求に応答し損ねた場合、ＳＣＭ１２０は、それから切り離してもよい。
一実施形態では、ＡＣＰコンテナバージョンパッケージ４１２は、少なくともセクションＸＩＶで本明細書に記載された接続確立プロセスの一部としてＳＣＭに配信するための別個の暗号化されたパッケージとして、クラウド１３０によって、大抵はデバイス１１０である送信者に配信されてもよい。ＡＣＰコンテナバージョンパッケージ４１２は、ＡＣＰコンテナコレクション４１４によって図５に示されているように、ＡＣＰコンテナ４１０と一緒に、またはＡＣＰコンテナ４１０の最初の部分として配信されてもよい。ＡＣＰコンテナ４１０とＡＣＰコンテナコレクション４１４は、本開示を通じて交換可能に使用されてもよいことに留意されたい。ＡＣＰ４００の配信が記述される場合、そのような配信は、ＡＣＰコンテナ４１０を介して達成されてもよいことにも留意されたい。
図５に示す一実施形態では、ＡＣＰコンテナバージョンパッケージ４１２は、ＡＣＰバージョン、大きな乱数またはシーケンス番号などの１つ以上の埋め込み識別子、およびメッセージ認証コードまたは署名を含むことができる。埋め込み識別子、メッセージ認証コード、署名、およびACP-Version-Key鍵の一部または全部のうちの１つ以上が、検証のためにＡＣＰコンテナ４１０内に格納されてもよい。ＡＣＰコンテナバージョンパッケージ４１２は、クラウド１３０によって生成され、本明細書で説明するようにターゲットＳＣＭ１２０に固有のACP-Version-Key鍵のような鍵で暗号化してもよい。代替的な実施形態では、ＡＣＰコンテナバージョンパッケージ４１２は、ACP-Version-Key鍵で暗号化され、次いで、Device-SCM-Key鍵またはSCM-Key鍵、もしくはその両方などの１つまたは複数の他の鍵でさらに暗号化されてもよい。
代替の実施形態では、ＡＣＰコンテナバージョンパッケージ４１２は、デバイス１１０によって以前に生成されまたは提供された、ＡＣＰコンテナ４１０内の対応する暗号鍵なしでデバイス１１０が所有する単なるＡＣＰ４００のＡＣＰバージョンである。一例として、この実施形態では、ＳＣＭ１２０は、デバイス１１０によって提供されるバージョンを信頼し、ＡＣＰコンテナ４１０を要求するか否かを決定するために、そのバージョンを使用することができる。ＡＣＰバージョンは、デバイス１１０を介して共有暗号化鍵で暗号化されても、されなくてもよい番号または文字列によって定義され得る。
この代替の実施形態は、前述の実施形態よりもはるかに安全性が低く、デバイス１１０が望むＡＣＰ４００のいかなるバージョンも有しているとデバイス１１０が言うことができる潜在的な脆弱性を持つことが認識される。しかしながら、一般に、これが起こることはありそうもなく、そして最も可能性のある欠点は、デバイス１１０が（ａ）更新のためにＡＣＰ４００を送信しない（バージョンが現在のものより古いので）か、または（ｂ）更新のためにＡＣＰ４００を送信する（バージョン番号が非常に高い場合は毎回処理後に拒否される）だろうということかもしれない。デバイス１１０がＡＣＰ４００を製造することは事実上不可能と考えられる。したがって、最も可能性の高い欠点は、ＳＣＭ１２０が多くの余分な作業、すなわちサービス拒否（ＤｏＳ）を背負い込むようになることである。
Ｃ．検証
ＳＣＭ１２０がＡＣＰコンテナ４１０を受信すると、その各層を順番に復号し、インテグリティハッシュ（署名）を演算して比較することによってＡＣＰコンテナ４１０の内容が改変されておらず適切に復号されたことを保証し、提供されたＡＣＰコンテナバージョンパッケージ４１２およびその内容が、ＡＣＰコンテナ４１０の様々な層における対応する内容（例えば、ＡＣＰバージョンおよび他の任意の適用可能な属性）と一致することを検証し、そして、ＡＣＰコンテナ４１０が各層で処理されるときに、（列挙されていない）他の整合性およびデータの完全性／妥当性チェックを実行することにより、ＳＣＭ１２０はＡＣＰコンテナ４１０の真正性を検証してもよい。
いずれかのポイントでＡＣＰコンテナ４１０の検証が失敗した場合、ＡＣＰコンテナ４１０は無効とみなされ、拒否（格納されない）されてもよい。新しいＡＣＰコンテナ４１０が受け入れられた場合（例えば、すべての検証が正常に完了し、新しいＡＣＰ４００が現在のＡＣＰ４００とは異なると看做される）、それはＳＣＭ１２０に記憶され、直ちにアクティブにされるか、または直ちに現在のＡＣＰ４００となる。
ＡＣＰコンテナ４１０を復号することは集中的なプロセスと考えられ、リアルタイムシステムにおける使用のため、より最適なデータ構造／データ構成が存在する可能性があるので、ＡＣＰコンテナ４１０（またはＡＣＰ４００）自体は、受信したときにＳＣＭ１２０のメモリ２１２に記憶されても、されなくてもよい。ＡＣＰコンテナ４１０またはＡＣＰ４００は、セキュアメモリ２２０、またはセキュアエンクレーブまたはハードウェアセキュリティモジュール（ＨＳＭ）などの同等のハードウェアモジュールに記憶されてもよい。ＡＣＰコンテナ４１０またはＡＣＰ４００は、その全体または一部だけが記憶されてもよい。あるいは、ＡＣＰコンテナ４１０またはＡＣＰ４００は、ＲＯＭ内の代替暗号鍵で暗号化され（そして実行中に復号され、ＲＡＭに記憶され）てもよく、または、保護されたＲＯＭ内に暗号化されずに記憶されてもよく、もしくは、上記のまたは他の技術のいくつかの組み合わせであってもよい。追加のまたは他の技術の例には、そのようなデータへのアクセスを防止でき、ハードウェアの障害物またはシールドを提供でき、物理的な障害物またはシールドを提供でき、ＪＴＡＧおよび他のポートを無効化でき、攻撃ベクトルを排除するようにソフトウェアインターフェースを強化でき、信頼できる実行環境（ハードウェアまたはソフトウェア）を確立でき、オペレーティングシステムのルートアクセスまたはセキュリティ破壊の招来を検出できる、ソフトウェアベースの対処またはハードウェアベースの対処を含む。
代替の実施形態では、ＡＣＰコンテナ４１０の元の形式ではなく、ＡＣＰコンテナ４１０の内容が、ＲＯＭに暗号化されずに格納されてもよい。別の代替の実施形態では、ＡＣＰコンテナ４１０は、（すべての暗号化層とともに）受信時にＲＯＭに格納され、動作中に復号されてＲＡＭに格納されてもよい。
Ｄ．ＡＣＰコンテナの取得−配信パス
本開示の一実施形態によるＡＣＰコンテナ４１０および／またはＡＣＰコンテナバージョンパッケージ４１２は、様々な方法で、デバイス１１０またはＳＣＭ１２０、またはその両方によって受信または取得され得る。
一実施形態では、ＡＣＰコンテナバージョンパッケージ４１２は、オプションで、デバイス１１０によってＳＣＭ１２０に提供される。ＡＣＰコンテナバージョンパッケージ４１２がＳＣＭ１２０に提供されない場合、ＳＣＭ１２０は、カプセル化されたＡＣＰ４００のＡＣＰバージョンを決定するために、ＡＣＰコンテナ４１０の最初の層を取得して解読することが必要とされ得る。代替の実施形態では、ＡＣＰコンテナバージョンパッケージ４１２は、デバイス１１０によって提供されないかもしれない。この場合、デバイス１１０またはＳＣＭ１２０は、ＡＣＰコンテナ４１０の更新を通知または要求し、ＡＣＰコンテナ４１０全体を処理する必要があり得る。
別の代替実施形態では、デバイス１１０は、ＳＣＭ１２０が現在所有しているＡＣＰコンテナバージョンパッケージ４１２をＳＣＭ１２０に要求してもよい。そして、デバイス１１０は、ＡＣＰコンテナバージョンパッケージ４１２において同定されたＡＣＰ４００のバージョンを、メモリに格納されたＡＣＰ４００のバージョンと比較し、ＡＣＰコンテナ４１０をＳＣＭ１２０に送信するか否かを決定してもよい。この実施形態では、ＡＣＰコンテナバージョンパッケージ４１２に対する要求は、少なくともセクションＸＩＶで、本明細書で説明されるように、デバイス１１０とＳＣＭ１２０のための接続確立プロセスの一部として送信されないかもしれない。
一実施形態では、デバイス１１０は、ＡＣＰコンテナ４１０全体の完全なバージョンをＳＣＭ１２０に送信してもよい。一実施形態では、デバイス１１０は、ユーザー要求、クラウド要求、またはデバイスプロセス、またはそれらの任意の組み合わせに基づいてもよい、デバイス１１０の裁量でＳＣＭ１２０にＡＣＰコンテナ４１０を送信してもよい。一実施形態では、ＡＣＰコンテナ４１０は、利用可能な通信リンクを使用して、デバイス１１０に接続された機器コンポーネント１４０または他のアクセサリなどの、デバイス１１０以外のシステムコンポーネントによってＳＣＭ１２０に配信されてもよい。利用可能な通信リンクは、アプリケーションごとに、または異なる状況下で変化してもよく、物理的なメディア、無線リンク、有線リンク、またはそれらの任意の組み合わせであってもよい。
一実施形態では、ＡＣＰコンテナ４１０は、クラウド１３０を介してＳＣＭ１２０に直接配信されてもよい。追加的にまたは代替的に、ＡＣＰコンテナ４１０は、機器コンポーネント１４０または別のデバイスなどの代替および／または中間システムコンポーネントに配信され、その後、利用可能な通信リンクを使用してＳＣＭ１２０に配信されてもよい。利用可能な通信リンクは、状況に応じて変化してもよく、物理的なメディア、無線リンク、および有線リンクのうちの少なくとも１つとすることができる。
無節操なインターネット接続および部分的な更新が見逃される可能性による意図しない挙動を含む、部分的な更新と不整合なシステム状態となる潜在的なリスクがあるので、図示された実施形態において、完全な形態のＡＣＰコンテナ４１０がＳＣＭ１２０に送信されてもよい。例示的なリスクシナリオには、オーナーがデバイスＡを追加し、その後デバイスＢを取り除いた場合、ＳＣＭ１２０において結果として得られた設定が、デバイスＡおよびデバイスＢのいずれもアクセスできないかもしれない状態が存在することが含まれる。言い換えると、最初の更新が見逃されたかもしれない。しかし、これらのリスクは、部分的な更新のバージョンと順序付けを追跡する属性を追加することによって、克服または低減され得る。
一実施形態では、ＡＣＰコンテナ４１０への部分的または増分的な更新はクラウド１３０から得てもよい。その更新は、認証の追加、削除、または変更、またはそれらの組み合わせ、および暗号鍵の循環の少なくとも１つを含んでもよい。一実施形態では、ＡＣＰコンテナ４１０への部分的または増分的更新がＳＣＭ１２０に送信されてもよい。代替の実施形態では、ＡＣＰコンテナ４１０は、ＳＣＭアイデンティティ設定パッケージおよびＡＣＰ４００などの、より小さな設定パッケージに分割されてもよい。
一実施形態では、送信されるＡＣＰコンテナ４１０のサイズを縮小することが必要であるか、または望ましい場合がある。そうするための１つのアプローチは、２つの特定のＡＣＰコンテナ４１０間の差異のみが送信される、デルタ更新を使用することである。ＡＣＰコンテナ４１０の多数のバージョンが存在し、デルタ更新イメージがＡＣＰコンテナ４１０の前後のバージョンに固有のものであるとすれば、デルタ更新イメージ（更新を実行するＳＣＭ１２０に送信されるイメージ）は、デルタ更新イメージをＳＣＭ１２０に送信するシステムコンポーネント（例えば、デバイス１１０）によって生成されてもよい。一実施形態では、デルタ更新イメージは、ＡＣＰコンテナ４１０をＳＣＭ１２０に送信するために使用されてもよく、その際、デルタ更新イメージは、デルタ更新イメージをＳＣＭ１２０に送信するシステムコンポーネント（例えば、デバイス１１０）によって生成される。一実施形態では、デルタ更新イメージは、ＡＣＰコンテナ４１０をＳＣＭ１２０に送信するために使用されてもよく、その際、デルタ更新イメージはクラウド１３０によって作成される。一実施形態では、デルタ更新イメージは、システム１００内の他のメッセージおよび設定パッケージのために使用されてもよい。
追加的または代替的に、送信されるＡＣＰコンテナ４１０のサイズの縮小は、圧縮によって達成されてもよい。圧縮は、ＡＣＰコンテナ４１０を送信するクラウド１３０またはシステムコンポーネント（例えば、デバイス１１０）のいずれかによって実行されてもよい。一実施形態では、ＡＣＰコンテナ４１０をＳＣＭ１２０に送信するために圧縮が使用されてもよい。一実施形態では、圧縮およびデルタ更新イメージの両方が、いずれかの順序（最初に圧縮、次いでデルタ、または最初にデルタ、次いで圧縮）で、ＡＣＰコンテナ４１０をＳＣＭに送信するために使用されてもよい。一実施形態では、システム１００内の他のメッセージおよび設定パッケージのために圧縮が使用されてもよい。
一実施形態では、ＳＣＭ１２０はクラウド１３０に接続してもよく、その場合、ＳＣＭ１２０はＡＣＰ４００内に認可を格納せず、代わりに、適切なときまたは必要なときに、特定のデバイス１１０が認可されているか否かを判定するようクラウド１３０に要求する。例えば、クラウド１３０は、デバイス１１０のアイデンティティが認可されていることを判定するように要求されてもよい。デバイス１１０が認可を有しているならば、その場合、デバイス１１０のＳＣＭ１２０への接続の持続時間（またはメモリが許せばより長く）に渡り、認可がＳＣＭ１２０上にキャッシュされてもよい。追加的にまたは代替的に、ネットワーク待ち時間を短縮するために、認可は、ローカルサーバー（またはサーバーのセット）にキャッシュされてもよい。
一実施形態では、デバイス１１０に格納された特定のＳＣＭ１２０のためのＡＣＰ４００は、該当デバイス１１０のための認可のみを含んでもよい。追加的にまたは代替的に、ＳＣＭ１２０は、複数のデバイス１１０からの認可をＳＣＭ１２０に格納された統合ＡＣＰ４００に併合してもよい。
一実施形態では、各ＳＣＭ１２０は、複数のＡＣＰ４００を受信して記憶してもよく、その場合、各ＡＣＰ４００は、ＳＣＭ１２０に対して発行されたすべてのセットの認可のサブセットを含む。これにより、多くのデバイス１１０が認可されている環境（例えば、数百人または数千人の従業員が特定のロックを解除する権限を与えられている建物アクセス管理システム、またはフリート環境）においてＡＣＰ４００が大きくなり過ぎるのを防ぐことができる。各サブセットＡＣＰ４００の内容は、ユーザーアカウントおよび／またはデバイス１１０の特定のセットに対する認可のみを含むことができる。例えば、一実施形態では、サブセットＡＣＰ４００は、各ユーザーアカウントに対して作成されてもよい（その場合、ＡＣＰ４００は、そのユーザーアカウントに関連付けられたデバイス１１０のみを含む）。例えば、別の実施形態では、サブセットＡＣＰ４００は、１０個のユーザーアカウントの各セットに対して作成されてもよい。例えば、さらに別の実施形態では、サブセットＡＣＰ４００は、１００個のデバイス１１０の各セットに対して作成されてもよい。サブセットＡＣＰ４００は、すべてのサブセットＡＣＰを含む合同ＡＣＰコンテナ４１０の一部、任意の数のサブセットＡＣＰ４００（例えば、変更されたサブセットＡＣＰ４００）を含む合同ＡＣＰコンテナ４１０、個別のＡＣＰコンテナ４１０（つまり、各サブセットＡＣＰ４００に対して１つ）、またはそれらの任意の組合せとして配信されてもよい。一実施形態では、各ＡＣＰコンテナ４１０は、各サブセットＡＣＰ４００に必要と考えられるバージョン情報を含む１つのＡＣＰコンテナバージョンパッケージ４１２を有してもよい。別の実施形態では、各ＡＣＰコンテナ４１０は、複数のＡＣＰコンテナバージョンパッケージ４１２を有してもよい。
Ｖ．代替パッケージの管理と配信
ＡＣＰコンテナ４１０と類似の意味、処理、およびエンコーディングを含む、ＡＣＰコンテナ４１０に関して本明細書で説明された１つ以上の実施形態に従って構成され生成されるＳＣＭ１２０のために定められた他のデータのパッケージが存在してもよい。その結果、別の設定（および他の）パッケージを利用することができ、類似の方法で管理および／または配信することができることを理解されたい。他のシステムコンポーネント（例えば、デバイス１１０または機器コンポーネント１４０）のために定められたパッケージも存在し得る。以下は、存在し得るパッケージの例である（そのいくつかは、本明細書でさらに詳細に説明される）。
１）アプリケーション設定
２）ファームウェア更新パッケージ
３）サブコンポーネント設定
４）機器プロトコル設定
５）機器モデル
６）ブラックリストパッケージ
７）システムログパッケージ
本明細書に記載されるセキュリティモデル／システムがマイクロローテーションシステムに適用される実施形態において、その例が、２０１５年２月１２に出願され、「車両と通信するためのシステムおよび方法」と題する、J. Michael Ellisらの米国特許出願第１４／６２０９５９、および２０１７年４月１４日に出願され、「リアルタイムロケーションを確立するためのシステムおよび方法」と題する、Raymond Michael Stittの米国特許出願第１５／４８８１３６号に記載されており、これらの開示は、その全体が参照により本明細書に組み込まれる。マイクロロケーションシステムの一実施形態に従って提供され得る情報の例には、以下が含まれる。
１）ゾーン構成または関連するデータは、ユーザーまたは機器１４０のオーナーの使用に関連すると考えられる、ＳＣＭ１２０に対する１つまたは複数のエリアまたはスペースを識別することができる。例えば、ドアの５フィート以内のエリアまたはスペースは、ドアの操作に関連すると考えられてもよく、例えば、このゾーン内の存在がドアを介したアクセスを可能にするトリガとなってもよい。
２）監視装置の構成および配置または関連するデータは、ＳＣＭ１２０と通信するため、およびＳＣＭ１２０に対して遠隔デバイス３１０を位置決めするための接続パラメータなど、図３に図示された実施形態に関連して説明した遠隔デバイス３１０の設定を識別することができる。
３）アルゴリズムチューニング設定または関連するデータは、ＳＣＭ１２０に対するデバイス１１０の位置を決定する際に使用されるアルゴリズムのための１つ以上の補償係数を示すことができる。
４）アルゴリズムモデルまたは関連するデータは、ＳＣＭ１２０に対するデバイス１１０の位置を決定する際に利用されるアルゴリズムを示すことができる。
ＶＩ．候補ＡＣＰ
図示の実施形態では、クラウド１３０は、各ＳＣＭ１２０のために、現に作動中のＡＣＰ４００のコピー（候補ＡＣＰ）を保持してもよい。候補ＡＣＰは、変更がなされるたびにバージョンが変化するバーション管理の下で、ＡＣＰ４００のバージョンによって識別可能にされてもよい。例えば、新しいバージョンが作成されて、ＡＣＰ４００のバージョンは、変更が行われるたびに増分されてもよい。
オーナーアカウントの承認のために識別される新しい候補ＡＣＰが作成されたとき、オーナーアカウントデバイス１１０（および対応するユーザー１０）の各々は、新しいＡＣＰ４００が承認のため作成されたことを、例えばプッシュ通知またはＳＭＳを介して通知されてもよい。すると、ユーザー１０は、承認のために、デバイス１１０において最新の候補ＡＣＰを取得することができる。ユーザー１０は、オーナーユーザーアカウント（すなわち、ＳＣＭ１２０のオーナーとして認可されているユーザーアカウント）に関連付けられたデバイス１１０のいずれかからの候補ＡＣＰを承認することができる。
一実施形態では、認可は特定のデバイス１１０に対してのみ（すなわち、ユーザーアカウントの代わりに）発行される。そのように、オーナーデバイス１１０の承認のために識別される新しい候補ＡＣＰが作成されたとき、オーナーデバイス１１０（および対応するユーザー１０）は、新しいＡＣＰ４００が承認のため作成されたことを、例えばプッシュ通知またはＳＭＳを介して通知され得る。すると、ユーザー１０は、承認のために、デバイス１１０において最新の候補ＡＣＰを取得することができる。
一実施形態では、候補ＡＣＰは、他のオーナー１０からの追加の変更を含んでもよく、その一部または全部は望ましくない可能性がある。その結果、ユーザー１０は、（ａ）何も起こらない場合に、候補ＡＣＰを承認しないことによって候補ＡＣＰを拒絶するか、または（ｂ）受諾可能になるまで候補ＡＣＰを編集し、変更をクラウド１３０に提出し（別の承認要求をオーナーデバイス１０にプッシュする）、そして、ＡＣＰを承認する。編集、提出、および承認のステップは、デバイス１１０のユーザーインターフェースに組み込まれてもよい。候補ＡＣＰが拒絶された場合、その候補ＡＣＰが残り、将来の変更が、その拒絶されたバージョンに対して行われる可能性がある。
候補ＡＣＰへの編集が提出され、候補ＡＣＰのＡＣＰバージョンがもはや現在のＡＣＰバージョンではない場合、クラウド１３０は提出を拒絶し、評価のためデバイス１１０に、より最近の候補ＡＣＰを取得することを許可してもよい。例えば、候補ＡＣＰが承認プロセス中に別のデバイス１１０によって更新された場合、デバイス１１０における編集はより古いバージョンのＡＣＰ４００について行われた可能性があり、したがって、クラウド１３０は、デバイス１１０によって提出されたすべての変更を拒絶し、現在のバージョンのＡＣＰ４００に基づいて候補ＡＣＰを受諾して編集するための承認プロセスを再開する。
オーナーデバイス１１０を用いたユーザー１０による候補ＡＣＰの承認後、または承認に応答して、候補ＡＣＰは、承認デバイス１１０のDevice-SCM-Key（非公開）鍵によって署名されてもよい。一実施形態では、候補ＡＣＰは、承認デバイス１１０に関連付けられたUser-SCM-Key鍵によってさらに署名されてもよい。別の実施形態では、候補ＡＣＰは、承認デバイス１１０に関連付けられたUser-SCM-Key鍵によって代わりに署名されてもよい。署名されたバージョンの候補ＡＣＰはクラウド１３０に提出されてもよく、クラウド１３０は、署名されたバージョンの候補ＡＣＰがクラウド１３０に記憶された現在のバーションの候補ＡＣＰに一致するか、および／または、適切なデバイス１１０がそれを承認（署名）したことを判定してもよい。オプションで、クラウド１３０は、オーナーデバイス１１０のユーザー１０が二因子認証（２ＦＡ）を無効にしていないかどうかを判定し、もしそうであれば、クラウド１３０は、ユーザー１０に２ＦＡコードを（ユーザー１０のデバイス１１０またはユーザー１０と関連付けられた別のデバイスなどの１つ以上の選択された媒体を介して）送信してもよい。
デバイス１１０によってクラウド１３０に提出された署名されたバージョンの候補ＡＣＰが、クラウド１３０に記憶された現在のバーションの候補ＡＣＰと一致しない、または、適切なデバイス１１０によって承認されなかった場合、提出が拒絶されてもよい（そして、承認プロセスが繰り返されてもよい）。デバイス１１０によって提出された署名されたバージョンの候補ＡＣＰが、クラウド１３０内の現在のバーションの候補ＡＣＰと一致する場合、候補ＡＣＰは適切なデバイス１１０によって承認されたものとして識別され、ユーザー１０は２ＦＡを有効化せず、提出が受け入れられる。オプションで、ユーザーが２ＦＡコードを受信した場合、ユーザーは、オーナーバイス１１０に２ＦＡコードを入力してもよく、その後、オーナーデバイス１１０は、入力された２ＦＡコードをクラウド１３０に提出する。そして、クラウド１３０は、提出された２ＦＡが送信された２ＦＡコードと一致することを検証してもよい。一致した場合、提出は、他の基準も満たされていれば受け入れられるものとみなされる。一致しない場合、提出は拒絶される（そして、承認プロセスが繰り返されてもよい）。代替の実施形態では、クラウド１３０は、少なくともセクションＸＩＩ.Ｎにおいて本明細書に記載されるもの（例えば、網膜、顔、および／またはタッチＩＤ）のように、１つ以上のユーザー関連鍵の受領に基づいて受け入れを行ってもよい。
クラウド１３０が、署名されたバージョンの候補ＡＣＰのデバイス１１０による提出を受け入れることを決定した後、クラウド１３０は、承認されたものとして対応する候補ＡＣＰに印を付け、最終ＡＣＰコンテナ４１０を生成し、ＳＣＭ１２０に関連する様々なデバイスにＡＣＰコンテナ４１０を配信する。一実施形態では、提出されたＡＣＰバージョンが候補ＡＣＰよりも古い場合、提出は拒絶される。
候補ＡＣＰアプローチは、システム１１０に、ＡＣＰ４００のブロックチェーン型の元帳と、複数のバーションのＡＣＰ４００が承認のために出現するか、または、一度にただ１つのバーションのＡＣＰ４００が承認のために出現する場合に生じ得る潜在的な同時実行またはブロッキングの問題を避けることが可能なアプローチとの両方を提供することができる。ＡＣＰ４００の元帳は検査履歴を提供することができ、そこでは、各編集結果は新しいバージョンになり、各バージョンは、特定のデバイス１１０に関連付けられる。
代替の実施形態では、ＡＣＰ４００を配信して承認する候補ＡＣＰプロセスが利用されないかもしれない。代わりに、承認を引き出す変更がなされるたびに、承認のための新しいＡＣＰ４００が生成されてもよい。追加的または代替的に、承認を引き出す変更がなされるたびに、新しいＡＣＰ４００の承認前のその後の変更が拒絶される場合に、承認のための新しいＡＣＰ４００が生成されてもよい。
ＶＩＩ．認可タイプ
一実施形態では、システム１００は、１つ以上の認可として定義され、少なくともセクションＩＩにおいて本明細書で議論される、デバイス１１０に付随する１つ以上の権利を利用する、またはデバイス１１０に１つ以上の権利を関連付けることができる。認可は、認可タイプとして知られる、認可と関連付けられたタイプ（例えば、セクション１）およびＶＩＩを参照）を有することができる。
認可は、デバイス１１０とＳＣＭ１２０との間で定義されるペアリングと関連付けることができる。開示の目的のために、認可および認可タイプは、１つのＳＣＭと対になる１つのデバイス１１０に関連して説明されることを理解されたい。しかしながら、複数のデバイス１１０と複数のＳＣＭ１２０との間には、１つ以上のＳＣＭ１２０と関連付けられる複数のデバイス１１０を含む、ペアリングの可能な多数の組み合わせが存在する。
一実施形態では、認可タイプは、ユーザーアカウントが認可される各ＳＣＭ１２０について、ユーザーアカウントに関連付けられてもよい。そして、認可タイプは、各デバイス１１０に対して作成され、ユーザーのアカウントに関連付けられる認可に流れることができる。例えば、ユーザーアカウントサービスは、ユーザーのデバイス１１０の各々に対する認可を作成し、特定のＳＣＭ１２０に対するユーザーアカウント認可タイプを、作成された認可のそれぞれに適用することができる。一実施形態では、ユーザーアカウントは、そのユーザーアカウントが認可される各ＳＣＭ１２０に対して、ユーザーアカウントと関連付けられた認可に従って、それぞれ異なる時間および／または異なる条件下でそれぞれ有効となる、零またはそれ以上の認可タイプ（例えば、翌週はゲスト−管理者、その後、ゲスト）を有することができる。
さらに別の実施形態では、認可は、特定のデバイス１１０にのみ関連付けられてもよい。例えば、１つまたは複数のまたはすべての認可が、複数のユーザーアカウントに関連付けられていないかもしれず、および／または１つのユーザーアカウントに関連付けられたデバイス１１０の間で共有されないかもしれない。
認可タイプは、特定のデバイス１１０が特定のＳＣＭ１２０に対して有する役割のタイプを最終的に示すことができる。システム１００において、認可タイプは、限定される訳ではないが、「別の権利を付与する」、「オーナーシップを移転する」、「誰かをオーナーにする」、「ゲストを追加する」、「他と共有する」、「特定のコマンドを発行する」のうちの１つ以上を行う権利を含む、特定の認可に関連付けられる認可権利を決定することもできる。代わりの実施形態では、認可タイプと認可権利は、例えば、ブロックファン権利の管理のため、少なくともセクションＸＸにおいて本明細書に記載された１つ以上の実施形態に従ってなど、別々に管理されてもよい。認可タイプは、特定のデバイス１１０（および、代理でそのユーザー１０）が、特定のＳＣＭ１２０（および、代理でＳＣＭ１２０と通信する機器コンポーネント）に関して実行できる様々なアクションを制御することができるので、認可タイプはセキュリティモデルの有用な一面であり得る。例示的な認可タイプは、開示のために以下に列挙され、オーナー認可タイプ、ゲスト−管理者認可タイプ、ゲスト認可タイプ、バレット認可タイプ、および組織認可タイプを含むが、これらに限定されない。
Ａ．オーナー
オーナー認可タイプは、所定のＳＣＭ１２０に対して完全な権限を持つユーザーアカウントおよび／またはデバイス１１０のために確保されてもよい。オーナー認可タイプを持つユーザーアカウントは、オーナーアカウントとして知られる。オーナー認可を有するデバイス１１０は、オーナーデバイス１１０として知られる。各アカウントおよび／またはデバイス１１０は、所定のＳＣＭ１２０に対して最大１つのオーナー認可を関連付けられてもよい。しかし、ＳＣＭ１２０は、複数のオーナーアカウントおよび／またはデバイス１１０と関連付けられてもよい。一実施形態では、所定のＳＣＭ１２０に対するオーナーアカウントおよび／またはデバイス１１０は、同じＳＣＭ１２０に対して他の有効な認可を有していないかもしれない。他の認可が発行された後に、アカウントおよび／またはデバイス１１０がオーナー認可を発行された場合、少なくともセクションＶＩＩＩにおいて本明細書に記載されている認可発行方法に従ってなど、他のすべての認可が取り消されてもよい。
代替の実施形態では、ＳＣＭ１２０は、最大１つのオーナーアカウントを有することができる。
代替の実施形態では、ＳＣＭ１２０は、最大１つのオーナーデバイスを有することができる。
図１の図示された実施形態では、オーナーアカウントおよび／またはデバイス１１０は、所定のＳＣＭ１２０に対する任意の認可を検分、発行（作成）、変更、および取り消し（削除）することができる。オーナーアカウントおよび／またはデバイス１１０は、ＳＣＭ１２０を新しいアカウントおよび／またはデバイス１１０に移すことができ、それによって所有者アカウントおよび／またはデバイス１１０から発生されたＳＣＭ１２０のためのすべての認可を取り消し、そして、対象とするアカウントおよび／またはデバイス１１０に対して、それぞれ、オーナー認可を作成することができる。一実施形態では、オーナーアカウントおよび／またはデバイス１１０は、オーナーアカウントおよび／またはデバイス１１０が所定のＳＣＭ１２０に対するすべての認可変更を承認しなければならないように構成されてもよい。ユーザー１０は、変更のタイプに依存して、関与する必要があってもよいし、関与する必要が無くてもよい。一実施形態では、任意のオーナーアカウントおよび／またはデバイス１１０は、認可変更を承認してもよい。アカウントおよび／またはデバイス１１０のオーナー認可が取り消されると、そのアカウントおよび／またはデバイス１１０から生じたすべての認可も取り消されてもよい。
代替的な実施形態では、アカウントおよび／またはデバイス１１０のオーナー認可が取り消されたとき、そのアカウントおよび／またはデバイス１１０から生じたすべての認可が、ＳＣＭ１２０に対する別のオーナーアカウントおよび／またはデバイス１１０、または、ゲスト−管理者アカウントおよび／またはデバイス１１０に移動されてもよい。
本明細書で論じるように、認可は、その認可がオーナー認可タイプを含むかどうかを含む、１つ以上のアクセス属性に関連付けることができる。発行された認可についてのアクセス属性を制限または変更する修正は、アクセス属性を含む、すべての発行された認可（制限または変更されるアクセス属性に基づいて発行されたすべての認可を含む）に適用されてもよい。例えば、オーナー認可タイプまたはアクセス属性が変更された場合、このオーナー認可タイプから発行されたいかなる認可も、同様の方法で修正されてもよい。代替実施形態では、発行する認可にアクセス属性を限定する修正（例えば、開始日／終了日の変更）は、発行する認可のアクセス属性に基づいて、発行済みの認可のいずれにも影響を及ぼさないかもしれない。
一実施形態では、システム１００内のＳＣＭ１２０のすべてまたはサブセットは、工場リセット状態にあるときを除いて、ＳＣＭ１２０のそれぞれが少なくとも１つのオーナーアカウントおよび／またはデバイス１１０を有するように構成されてもよく、その場合、ＳＣＭ１２０、その最初のオーナーアカウントおよび／またはデバイス１１０の割り当てを待つ間、過渡的な状態にある。全ての実施形態がこのように構成されるわけではないことを理解されたい。少なくとも１つのオーナーアカウントおよび／またはデバイス１１０が所定のＳＣＭ１２０に関連付けられた後、その少なくとも１つのオーナーアカウントおよび／またはデバイス１１０が、所定のＳＣＭ１２０に関連付けられたままであってもよい。一例として、所定のＳＣＭ１２０が新しいオーナーアカウントおよび／またはデバイス１１０に移されない限り、所定のＳＣＭ１２０に対する最終オーナー認可は取り消されないことがある。代替的な実施形態では、ＳＣＭ１２０に対する最終のオーナー認可は取り消されてもよく、その最終のオーナー認可が取り消されたとき、ＳＣＭ１２０は工場リセットモードに入る。
一実施形態では、オーナー認可が作成されると、オーナー認可は別の認可タイプに変更することはできない。代替の実施形態では、オーナー認可が任意の他の認可タイプに変更されてもよい。別の認可タイプへの変更は、以前に発行されたがもはや許可されない認可との結果をもたらしてもよい。これらの認可は、自動的にまたは手動で、適用可能な認可を持つ代わりのアカウントおよび／またはデバイス１１０に移動されてもよいし、または取り消されてもよい。
Ｂ．ゲスト−管理者
ゲスト−管理者認可タイプは、所定のＳＣＭ１２０に対してほぼ完全な権限を持つアカウントおよび／またはデバイス１１０に関連付けることができる。ゲスト−管理者認可を有するデバイス１１０は、ゲスト−管理者デバイス（または、ゲスト認可タイプに関して動作上の違いがない場合にはゲストデバイス）として知られる。ゲスト−管理者認可タイプのユーザーアカウントは、ゲスト−管理者アカウント（または、ゲスト認可タイプに関して動作上の違いがない場合はゲストアカウント）として知られる。各アカウントおよび／またはデバイス１１０は、所与のＳＣＭ１２０に対して最大１つのゲスト−管理者認可を有することができる。しかし、ＳＣＭ１２０、複数のゲスト−管理者アカウントおよび／またはデバイスを有することができる。所定のＳＣＭ１２０に対するゲスト管理アカウントおよび／またはデバイス１１０は、同じＳＣＭ１２０に対して他の有効な認可を有していないかもしれない。一実施形態では、他の認可がすでに発行された後に、アカウントおよび／またはデバイス１１０がゲスト−管理者認可を発行された場合、少なくともセクションＶＩＩＩにおいて本明細書に記載されている認可発行方法に従ってなど、他のすべての認可が取り消されてもよい。
代替の実施形態では、各アカウントおよび／またはデバイス１１０は、所定のＳＣＭ１２０に対して零またはそれ以上のゲスト−管理者認可を有してもよい。別の代替実施形態では、各アカウントおよび／またはデバイス１１０が、同じＳＣＭ１２０に対する零またはそれ以上の他の許容される認可を発行されてもよい。さらに別の代替実施形態では、アカウントおよび／またはデバイス１１０は、他の認可が既に発行されている場合、ゲスト−管理者認可を発行されないかもしれない。またさらに別の代替実施形態では、アカウントおよび／またはデバイス１１０が、他の認可が既に発行された後にゲスト− 管理者認可を発行された場合、少なくともセクションＶＩＩＩにおいて、本明細書に記載されている認可発行方法に従ってなど、冗長または許容されない認可が取り消されてもよい。
図１の図示された実施形態では、ゲスト−管理者アカウントおよび／またはデバイス１１０は、非オーナー認可を発行（作成）することができるが、それらが所定のＳＣＭ１２０に対して発行した（または発行された）認可を、検分、修正、および取り消し（削除）のみすることができる。ゲスト−管理者アカウントおよび／またはデバイス１１０は、限定されたアクセス属性を有する認可を発行されえる。例えば、ゲスト−管理者アカウントおよび／またはデバイス１１０は、限定された有効期限の認可を発行されることができる。
ゲスト−管理者アカウントおよび／またはデバイス１１０は、ゲスト−管理者アカウントおよび／またはデバイス１１０の認可よりも広範なアクセス属性を有する認可を発行しないかもしれない。一例を提供するために、ゲスト−管理者アカウントおよび／またはデバイス１１０は、ゲスト−管理者認可タイプと関連付けられた有効期限外の有効期限を有する認可を発行しないかもしれない。
ゲスト−管理者アカウントおよび／またはデバイス１１０の認可アクセス属性がさらに制限されるように変更された場合、ゲスト−管理者アカウントおよび／またはデバイス１１０によって発行された認可は、相応して、許容可能なままであるように変更されてもよいし、または取り消されてもよい。一実施形態では、アカウントおよび／またはデバイス１１０のゲスト−管理者認可が取り消されると、そのアカウントおよび／またはデバイス１１０からのゲスト−管理者認可に由来するすべての認可も取り消される。ＳＣＭ１２０のためのゲスト−管理者アカウントおよび／またはデバイス１１０は、同じＳＣＭ１２０のために、それ自体（すなわち、同じアカウントおよび／またはデバイス１１０）への認可を発行しないかもしれない。
代替の実施形態では、ＳＣＭ１２０に対するゲスト−管理者アカウントおよび／またはデバイス１１０は、同じＳＣＭ１２０のために、それ自体（すなわち、同じアカウントおよび／またはデバイス１１０）に認可を発行してもよい。一実施形態では、ゲスト−管理者認可は、限定されたアクセス属性を有さないかもしれない。一実施形態では、発行アカウントおよび／またはデバイス１１０（例えば、オーナーアカウントおよび／またはデバイス１１０）から認可を発行されたゲスト−管理者アカウントおよび／またはデバイス１１０は、発行アカウントおよび／またはデバイス１１０の裁量で、所定のＳＣＭ１２０に対する、発行アカウントおよび／またはデバイス１１０から認可を発行された、発行アカウントおよび／またはデバイス１１０を包含または除外する、他のアカウントおよび／またはデバイス１１０に発行された認可を検分することができる。代替の実施形態では、アカウントおよび／またはデバイス１１０のゲスト−管理者認可が取り消されると、アカウントおよび／またはデバイス１１０のゲスト−管理者認可に由来するすべての認可が、ＳＣＭ１２０に対する、別のオーナーアカウントおよび／またはデバイス１１０、またはゲスト−管理者アカウントおよび／またはデバイス１１０に移動されてもよい。
一実施形態では、ゲスト−管理者アカウントおよび／またはデバイス１１０は、発行アカウントおよび／またはデバイス１１０（例えば、オーナーアカウントおよび／またはデバイス１１０）による承認のため、認可変更要求を提出してもよい。
一実施形態では、一旦、ゲスト−管理者認可が作成されると、そのゲスト−管理者認可は別の認可タイプに変更されることはできない。一実施形態では、ゲスト−管理者認可は任意の他の認可タイプに変更されてもよいが、それは、もはや許容されない、ゲスト−管理者認可から発行された１以上の認可をもたらすかもしれない。そのような認可は、自動的にまたは手動で、適用可能な認可を持つ代わりのアカウントおよび／またはデバイス１１０に移動されてもよいし、もしくは取り消されてもよい。
Ｃ．ゲスト
ゲスト認可タイプは、所定のＳＣＭ１２０に対する限定された権限を有するアカウントおよび／またはデバイス１１０に関連付けられてもよい。ゲスト認可を有するデバイス１１０は、ゲストデバイス１１０として知られる。ゲスト認可タイプを有するユーザーアカウントは、ゲストアカウントとして知られる。各アカウントおよび／またはデバイス１１０は、所定のＳＣＭ１２０に対して、零またはそれ以上のゲスト認可を有してもよく、ＳＣＭ１２０は、複数のゲストアカウントおよび／またはデバイス１１０を有することができる。所定のＳＣＭ１２０のゲストアカウントおよび／またはデバイス１１０は、同じＳＣＭ１２０に対して有効なオーナーまたはゲスト−管理者認可を持たなくともよい。他の認可が既に発行された後にアカウントおよび／またはデバイス１１０がゲスト認可を発行された場合、少なくともセクションＶＩＩＩにおいて本明細書に記載されている認可発行方法に従ってなど、冗長または許容されない認可が取り消されてもよい。
代替の実施形態では、各アカウントおよび／またはデバイス１１０は、所定のＳＣＭ１２０に対して最大１つのゲスト認可を有してもよい。別の代替実施形態では、アカウントおよび／またはデバイス１１０は、他の認可が既に発行された後にゲスト認可を発行された場合、少なくともセクションＶＩＩＩにおいて本明細書に記載された認可発行方法に従ってなど、他のすべての認可が取り消されてもよい。さらに別の代替実施形態では、各アカウントおよび／またはデバイス１１０は、同じＳＣＭ１２０に対して零またはそれ以上の他の許容可能な認可を発行されてもよい。またさらに別の代替実施形態では、アカウントおよび／またはデバイス１１０は、他の認可が既に発行されている場合、ゲスト認可を発行されないかもしれない。さらに別の代替実施形態では、アカウントおよび／またはデバイス１１０は、他の認可が既に発行された後にゲスト認可を発行される場合、少なくともセクションＶＩＩＩにおいて本明細書に記載される認可発行方法に従ってなど、冗長または許容されない認可が取り消されてもよい。
図１の図示の実施形態では、ゲストアカウントおよび／またはデバイス１１０は、バレット認可を発行（作成）することができるが、所定のＳＣＭ１２０に対してゲストアカウントおよび／またはデバイス１１０が発行された認可を、検分、および取り消し（削除）のみすることができる。ゲストアカウントおよび／またはデバイス１１０は、限定されたアクセス属性を有する１つ以上の認可を発行されてもよい。例えば、ゲストアカウントおよび／またはデバイス１１０は、限定された有効期限の認可を発行されてもよい。
ゲストアカウントおよび／またはデバイス１１０は、ゲストアカウントおよび／またはデバイス１１０の認可よりも広範なアクセス属性を有する認可を発行しないかもしれない。一例を提供するために、ゲストアカウントおよび／またはデバイス１１０は、ゲストアカウントおよび／またはデバイス１１０に提供されたゲスト認可タイプと関連付けられた有効期限外の有効期限を有する認可を発行しないかもしれない。
ゲストアカウントおよび／またはデバイス１１０の認可アクセス属性がさらに制限されるように変更された場合、ゲストアカウントおよび／またはデバイス１１０によって発行された認可は、相応して、許容可能なままであるように変更されてもよいし、または取り消されてもよい。アカウントおよび／またはデバイス１１０のゲスト認可が取り消されると、そのゲスト認可に由来するすべての認可も取り消されてもよい。
代替の実施形態では、ゲストアカウントおよび／またはデバイス１１０は、それ自体のゲスト認可を取り消すことができない。ＳＣＭ１２０のためのゲストアカウントおよび／またはデバイス１１０は、同じＳＣＭ１２０のために、それ自体（すなわち、同じアカウントおよび／またはデバイス１１０）への認可を発行しないかもしれない。
代替の実施形態では、発行アカウントおよび／またはデバイス１１０（例えば、オーナーアカウントおよび／またはデバイス１１０）から認可を発行されたゲストアカウントおよび／またはデバイス１１０は、発行アカウントおよび／またはデバイス１１０の裁量で、所定のＳＣＭ１２０に対する、発行アカウントおよび／またはデバイス１１０から認可を発行された、発行アカウントおよび／またはデバイス１１０を包含または除外する、他のアカウントおよび／またはデバイス１１０に発行された認可を検分することができる。代替の実施形態では、アカウントおよび／またはデバイス１１０のゲスト認可が取り消されると、アカウントおよび／またはデバイス１１０のゲスト認可に由来するすべての認可が、ＳＣＭ１２０に対する、別のオーナーアカウントおよび／またはデバイス１１０、またはゲスト−管理者アカウントおよび／またはデバイス１１０に移動されてもよい。一実施形態では、ゲストアカウントおよび／またはデバイス１１０は、発行アカウントおよび／またはデバイス１１０による承認のため、認可変更要求を提出してもよい。
図示の実施形態では、ゲスト認可が作成された後、そのゲスト認可は別の認可タイプに変更されることはできない。代替実施形態では、ゲスト認可は、任意の他の認可タイプに変更されてもよいが、それは、もはや許容されない、ゲスト認可から発行された１以上の認可をもたらすかもしれない。そのような１以上の認可は、自動的にまたは手動で、適用可能な認可を持つ代わりのアカウントおよび／またはデバイス１１０に移動されてもよいし、もしくは取り消されてもよい。
Ｄ．バレット
バレット認可タイプは、所定のＳＣＭ１２０に対する限定された権限を有するアカウントおよび／またはデバイス１１０のための特別な目的の認可タイプと考えることができる。バレット認可を有するデバイス１１０は、バレットデバイスとして知られる。バレット認可タイプを有するユーザーアカウントは、バレットアカウントとして知られる。各アカウントおよび／またはデバイス１１０は、所定のＳＣＭ１２０に対して零またはそれ以上のバレット認可を有してもよい。しかし、ＳＣＭ１２０は、複数のバレットアカウントおよび／またはデバイス１１０を有することができる。所定のＳＣＭ１２０のバレットアカウントおよび／またはデバイス１１０は、同じＳＣＭ１２０に対して有効なオーナー認可、ゲスト−管理者認可、またはゲスト認可を有さないかもしれない。他の認可が既に発行された後に、アカウントおよび／またはデバイス１１０がバレット認可を発行された場合、少なくともセクションＶＩＩＩにおいて本明細書に記載されている認可発行方法に従ってなど、冗長または許容されない認可が取り消されてもよい。
バレットアカウントおよび／またはデバイス１１０は、バレットアカウントおよび／またはデバイス１１０が所定のＳＣＭ１２０に対して発行された認可を検分のみすることができる。バレットアカウントおよび／またはデバイス１１０は、限定されたアクセス属性を持つ認可を発行されてもよい。例えば、バレットアカウントおよび／またはデバイス１１０は限定された有効期限を持つ認可を発行されてもよい。
代替の実施形態では、バレット認可は存在しないかもしれない。別の代替実施形態では、限定された数のバレット認可が、所定のＳＣＭ１２０のアカウントおよび／またはデバイス１１０に提供されてもよい。その数は固定数（例えば、１）であってもよい。さらに別の代替実施形態では、バレット認可は、バレットアカウントおよび／またはデバイス１１０と同じエンティティ（例えば、バレットサービス組織）に属し、または関連する別のアカウントおよび／またはデバイス１１０に転送されてもよい。
一実施形態では、何らかのイベントが発生したとき（例えば、非バレットアカウントおよび／またはデバイス１１０がＳＣＭ１２０に接続されたか、または機器コンポーネント１４０が、ＳＣＭ１２０はある合理的な閾値を超えて移動したことを示すなど）、バレット認可は自動的に取り消されてもよい。
図示された実施形態では、バレット認可が作成された後、そのバレット認可は別の認可タイプに変更されることはできない。代替的に、バレット認可が任意の他の認可タイプに変更されてもよいが、それは、もはや許容されない、バレット認可から発行された１以上の認可をもたらすかもしれない。そのような認可は、自動的にまたは手動で、適用可能な認可を持つ代わりのアカウントおよび／またはデバイス１１０に移動されてもよいし、もしくは取り消されてもよい。
Ｅ．組織
一実施形態では、組織認可タイプは、アカウントおよび／またはデバイス１１０のセットが、１つ以上の他のアカウントおよびまたはデバイス１１０に、組織と関連づけられた１つ以上のＳＣＭ１２０に対するオーナー認可を付与するための能力を備えてもよい。
Ｆ．転送
一実施形態では、本明細書で説明するように、転送認可タイプは、ＳＣＭ１２０のオーナーシップ転送プロセスの間に使用されてもよい。この認可タイプは過渡的である。それは、適切な承認および取り消しが実行されるように、そのような転送が望まれていることを信号で送るために使用され、承認に基づいて、オーナー認可が対象アカウント（およびそのデバイス１１０）に適用されてもよい。
Ｇ．他の潜在的に動的なタイプ
一実施形態では、システム１００での使用に利用可能な認可タイプは動的であってもよい。認可タイプのセットは、実行時に、実行時前の設定を介して、またはプログラムによって変更してもよい。例えば、以前にシステム１００で使用されなかった新しいタイプの認可タイプが、アカウントおよび／またはデバイス１１０およびＳＣＭ１２０に対してＡＣＰ４００を介して導入されてもよい。
Ｈ.認可ツリー
本明細書に記載される１つ以上の実施形態によれば、特に１つ以上の認可タイプに関して、認可タイプおよび関連付けられたアクセス権は、第１及び第２のアカウントおよび／またはデバイス１１０に与えられた権利に応じて、第１のアカウントおよび／またはデバイス１１０から第２のアカウントおよび／またはデバイス１１０などに付与されてもよいことを理解されたい。このようにして、新しい認可が付与され、古い認可が取り消されたり変更されたりするので、時間の経過とともに動的に変化する認可のツリーが生成されてもよい。このようなツリーの２つのタイプの例が、図６および図７の図示の実施形態に示されている。
図６および図７の図示の実施形態では、システム１００内に複数のＳＣＭ１２０が存在し、それぞれ、１つ以上のオーナーアカウントおよび／またはデバイス１１０に関連付けられている。１つ以上のオーナーアカウントおよび／またはデバイス１１０は、ゲスト−管理者アカウントおよび／またはデバイス１１０、ゲストアカウントおよび／またはデバイス１１０、およびバレットアカウントおよび／またはデバイス１１０のための認可を、直接的または間接的に提供している。
ＶＩＩＩ．認可発行シーケンス
図１の図示された実施形態では、ユーザー１０は、ユーザーアカウント（そして、ユーザーアカウントサービスを介して、デバイス１１０）および／またはデバイス１１０に、複数のＳＣＭに対する様々なタイプの認可を発行し、変更し、および取り消すことができる。セキュリティモデルは、（認可発行要求と結果として生じるＡＣＰ４００の両方を受け入れるために）ユーザー１０を含む、認可を発行するための複数のシステムコンポーネントの関与を利用することができる。認可の変更と取り消しは、必ずしもユーザーの関与を必要としないかもしれない。
一実施形態による１つ以上の認可を発行する方法が、図８に示され、全体として８００で表されている。その方法８００は、ステップ８０１）認可を発行する権利を持つユーザー１０が、特定のＳＣＭ１２０に対する受信ユーザーアカウントおよび／またはデバイス１１０に、（その権利を持つ）デバイス１１０を使用して認可発行要求を送信する、ステップ８０２）受信ユーザーは、それぞれのデバイス１１０（例えば、それぞれのユーザーアカウントに関連付けられた任意のデバイス１１０、特定のデバイス１１０）を使用して認可発行要求を受け入れる、ステップ８０３）ＳＣＭ１２０に対するオーナーデバイス１１０が、発行された認可から生じるＡＣＰ４００に対する変更を受け入れる、を含む様々なステップを含んでいる。
上記に加えて、本明細書に記載されるように、２因子認証（２ＦＡ）が、上記の１つ以上のステップにおいて、システムレベル要件として追加されてもよい。ただし、理解を容易にするために、２ＦＡメッセージは上記のシーケンス図には示されない。適用可能なユーザーアカウントに関連付けられたいずれかのデバイス１１０を使用して、２因子認証要求が完了されてもよいことに留意されたい。
一実施形態では、第１のユーザー１０が、既存のユーザーアカウントおよび／またはＯＥＭ（Original Equipment Manufacturer）クラウドアカウントを持たない第２のユーザー１０に認可発行要求を送信するための通信経路が提供される。通信経路は、電子メールおよび／またはＳＭＳ通信に少なくとも部分的に基づいてもよい。第２のユーザー１０に配信されるメッセージは、第２のユーザー１０のデバイス１１０のためのアプリケーションを入手すること（適切な場合）、またはウェブサイトを訪問して、ユーザーアカウントおよび／またはＯＥＭアカウントを作成すること、そして、要求を受け入れることを第２のユーザー１０に要求してもよい。
１つ以上の実施形態に関連して本明細書で説明するように、オーナーシップ移転要求は、典型的な認可発行プロセスの特殊なケースと考えることができる。これは、オーナーシップ移転要求が、所定のＳＣＭ１２０に対する他のすべての認可の取り消しを伴う、オーナー認可の発行をもたらすためである。図８の図示された実施形態では、新しいオーナーおよび以前のオーナーの両方がオーナーシップ移転要求を承認することを要求されてもよく、ただし、オーナーシップ移転要求の性質上、移転要求が承認されるまで候補ＡＣＰは変更され得ない。
少なくともステップ８０３に示す図示の実施形態では、オーナーアカウントおよび／またはデバイス１１０（および、代理でそのユーザー１０）は、ＳＣＭ１２０に対する任意のユーザー１０によって開始されたＡＣＰ４００への変更を承認することができる。オーナーアカウントおよび／またはデバイス１１０が、非オーナー認可（例えば、ゲスト）を発行する場合、発行ユーザー１０は、ＡＣＰ４００の承認プロセスに関与することは必要とされないかもしれない。ユーザー１０の関与が必要とされない（例えば、２ＦＡではない、または承認ボタンの押下が必要とされない）場合でさえ、オーナーデバイス１１０は、（例えば、ユーザーの介入なしにバックグラウンドで処理を実行することによって）関与してもよい。
ユーザーの関与を必要としないことが望ましい他の認可および／または認可処理が存在してもよい。本明細書で説明される認可および／または認可処理のいずれも、ユーザーの関与を必要としないこのような方法に適合されてもよい。ユーザーが開始した何かの承認にユーザー１０が関与することを要求しないことによって、ユーザーエクスペリエンスを改善することが望ましい。ユーザー１０が、彼らのユーザーアカウントに関連する複数のデバイス１１０を有する場合、たとえ彼らが変更を開始したとしても、別のユーザーデバイス１１０からの承認を要求することが望ましい。代替的な実施形態では、ＡＣＰ４００への変更の範囲は、ａ）ユーザー１０がＳＣＭ１２０ための承認に関与することを要求され得るか、またはｂ）ＳＣＭ１２０の承認プロセスへのユーザー１０の関与が、新しいオーナー認可が発行されるときのみに必要とされ得るように、制限されてもよい。新しいオーナー認可が発行されるとき、ユーザーの関与が必要とされてもよい。２ＦＡが有効化されないか、または承認ボタンの押下が有効化されない場合など、ユーザーの関与が必要とされない場合も、オーナーデバイス１１０は依然として（例えば、ユーザーの介入なしにバックグラウンドで処理を実行することによって）関与してもよい。
代替実施形態では、ＡＣＰ４００への変更は委任されてもよい。本明細書で論じるように、オーナーアカウントおよび／またはデバイス１１０は、ＳＣＭ１２０のためにＡＣＰ４００を承認するように構成されてもよい。オーナーアカウントおよび／またはデバイス１１０は、ＡＣＰ４００の承認権限を、認可を発行しようと試みている別のアカウントおよび／またはデバイス１１０に委任してもよい。承認権限は、オーナーアカウントおよび／またはデバイス１１０が利用可能な認可タイプのサブセットに限定されてもよく、または利用可能なすべての認可タイプを含んでもよい。例えば、オーナーＣがゲストＡにゲスト認可、およびゲスト認可を委任する権限を与えた場合、ゲストＡはオーナーＣの関与なしでゲストＢにゲスト認可を発行することができる。別の例では、ＡＣＰ４００への他の変更が存在しない場合、承認権限が委任されてもよい。そうでなければ、発行連鎖内のオーナーアカウントおよび／またはデバイス１１０、または非オーナー発行アカウントおよび／またはデバイス１１０が、ＡＣＰ４００への変更を承認してもよい。
デバイス１１０などのシステムコンポーネントがジェイルブレイクされたと判定された場合、システムコンポーネント（または、異常を検出したシステムコンポーネント）は、クラウド１３０に警報を出してもよい。ジェイルブレイクされたデバイス１１０、または他のコンポーネントは、そのオペレーティングシステムまたはそのインフラストラクチャソフトウェア（例えば、標準ライブラリまたはアプリケーション）が危険にさらされているコンポーネントとして定義されえる。クラウド１３０は、ジェイルブレイクされたデバイス１１０が盗まれ、悪意のある使用が意図されているとみなし、したがって、ジェイルブレイクされたデバイス１１０に対して、またはジェイルブレイクされたデバイス１１０によって発行された認可を取り消してもよい。一実施形態では、クラウド１３０は、ジェイクブレイクされたデバイス１１０に関連するユーザーアカウントに対して、またはユーザーアカウントによって発行された認証を取り消してもよい。
図８の図示された実施形態は、認可発行要求の送信、認可発行要求の受け入れ、および発行された認可から生じるＡＣＰ４００への変更の受け入れを含む、本明細書で強調されるいくつかのステップを含む（ステップ８０１、８０２、８０３）。例示の実施形態は、これらのステップのうちの１つ以上が、１つ以上の追加のステップを含み得ることを強調する。
例えば、認可発行要求を送信するためのステップ８０１は、現在、オーナーとして分類されているユーザーＡによって定義されてもよく、ユーザーＡのデバイスＡはオーナーデバイス１１０である。ユーザーＢおよびデバイスＢとラベル付けされた彼女のデバイス１１０は、認可の発行の対象となり得る。ユーザーＡは、ユーザーＢのユーザー名（例えば、「Ｂ」）を要求することができ、ユーザーＢはそれに応答することができる（ステップ８２１、８２２）。ユーザーＡは、ユーザーＢにゲスト認可を発行するように彼女のデバイスＡに指示することができる。デバイス１１０は、その要求をクラウド１３０に送信する（ステップ８２３）。クラウド１３０は、ユーザーＡのデバイス１１０が所定のＳＣＭ１２０に対する認可を発行する権限を与えられていることを検証する（ステップ８２４）。一実施形態では、認可は、ユーザーＢのすべてのデバイス１１０に適用される。別の実施形態では、ユーザーＢが複数のデバイス１１０を有する場合、ユーザーＡは、ユーザーＢのデバイス１１０のどれに認可が送信されるかを選択することができる（ステップ８２５）。クラウド１３０は、ユーザーＢのデバイス１１０の１つに、認可を受け入れるか拒否するように要求する（ステップ８２６）。ユーザーＢが認可を受け入れる場合、ユーザーＢのデバイス１１０はDevice-SCM-Key鍵を生成し、クラウド１３０が候補ＡＣＰを更新するために使用する、関連部分（例えば公開鍵）をクラウド１３０に送信する（ステップ８２７）。更新された候補ＡＣＰの存在は、（デバイス１１０を介して）ユーザーＡに通信され、ユーザーＡは、候補ＡＣＰの変更を受け入れる。ユーザーＡによって使用されるデバイス１１０は、変更を承認するため、承認した候補ＡＣＰに署名し、それをクラウド１３０に送信する（ステップ８２８）。この承認ステップは、たとえ発信者がオーナーデバイスであっても、変更がオーナーシップの移転である場合、一実施形態では要件と見なすことができる。
クラウド１３０は、署名された候補ＡＣＰを検証し、確定ＡＣＰ４００を生成し、すべての適用可能デバイス１１０にその存在を知らせる（ステップ８２９）。デバイス１１０は、（例えば、ＡＣＰコンテナ４１０、ＡＣＰコンテナコレクション４１４、または他の媒体を介して）更新されたＡＣＰ４００を取得する（ステップ８３０）。ユーザーＢのデバイス１１０は、更新されたＡＣＰ４００を（例えば、ＡＣＰコンテナ４１０または任意の他の媒体を介して）ＳＣＭ１２０に送信する（ステップ８３１）。
ＩＸ．ユーザーアカウントモデルとデバイス登録
一実施形態では、システム１００は、ユーザー名およびパスワードベースのアカウントモデルなどのアカウントモデルを介してサービスにアクセスすることをもって、ユーザーがよく知っていることを利用してもよい。追加的に、または代替的に、システム１００は、デバイス１１０のアイデンティティに基づいて、鍵ベースの識別システム（すなわち、暗号アイデンティティ）を利用することができる。鍵ベースの識別（すなわち、暗号アイデンティティ）は、ユーザーにある程度の匿名性を提供するとともに、ブロックチェーンの元帳に従ってＡＣＰ４００への変更または取引の追跡を容易にすることができる。非対称暗号／暗号アイデンティティの一部としての匿名公開鍵、および取引を追跡するブロックチェーンの元帳を使用して、ユーザーが識別され、認証される暗号化システムと同様に、および少なくとも部分的に基づいて、システム１００は、認可発行シーケンスにおける鍵としてデバイスアイデンティティを利用することができる。デバイスアイデンティティはデバイスの１つ以上の特性に基づいて動的であっても固定であってもよく、アカウントおよびパスワードによってユーザー１０の識別、追跡、および認証を潜在的に回避する。システム１００は、デバイス１１０の物性を機械的鍵の物性と実質的に同等視することができ、デバイス１１０のアイデンティティをユーザー１０の代理とみなすことができる。
システム１００で利用されるデバイスアイデンティティは、ユーザー１０と機器１４０のアイデンティティを両方とも保護するため、並びに、セキュリティ侵害の発生時にハッカーがその情報を取得することを実質的に防ぐために、様々なシステムコンポーネントからできるだけ多くのユーザーおよび機器識別情報を意図的に省略するように定義されることができる。しかしながら、ユーザー１０によりデバイス１１０を集団とするためのビジネス及びユーザーエクスペリエンスを容易なものとするために、デバイス１１０が登録されるとき、各デバイス１１０がクラウド１３０（ユーザーアカウントサービス）によってにクラウドユーザー識別子（Cloud-User-ID）を提供されてもよい。
Cloud-User-IDは、同じＯＥＭユーザー識別子（OEM-ED）に関連付けられた各デバイスについて同じであってもよい。その結果、特定のCloud-User-IDに関連付けられたデバイス１１０のセットを決定することが可能となる。クラウド１３０のユーザーアカウントサービスは、安全なデータベースアプローチを使用して、Cloud-User-IDに対して抽象的に（ＯＥＭユーザー識別子を介して）ＯＥＭユーザーアカウントを結び付けることができ、このマッピングを格納し実行するクラウド１３０のサービス（ユーザーアカウントサービス）は、クラウド１３０およびＯＥＭクラウドの他のサービスから隔離または分離され、ユーザー特定可能な情報が外部ＯＥＭクラウドに残ることを可能にする。このアプローチは、ハッカーが、ＯＥＭユーザーアカウントへのユーザー１０のマッピング、デバイス１１０へのユーザー１０のマッピング、ＳＣＭ１２０または機器１４０へのユーザー１０のマッピングなどの個人識別情報（PII）をまとめるために、３つの別個のシステムコンポーネント（そのうちの少なくとも２つは別個の管理インフラストラクチャ、ドメイン、または制御領域にある）に侵入しない限り、ハッカーの不正アクセスを防止することができる。
代替実施形態では、クラウド１３０は、安全なデータベースアプローチを使用しないかもしれないが、依然としてクラウド１３０の他のサービスと統合された別のユーザーアカウントサービスを提供することができる。たとえば、ユーザーアカウントサービスは、潜在的に、同じインフラストラクチャ、ネットワーク、または仮想プライベートネットワークを介して動作してもよい。別の実施形態では、クラウド１３０は、ＯＥＭアカウント情報を他のユーザー情報から分離しないかもしれない。一例を提供するために、クラウド１３０は安全なデータベースアプローチを使用せず、ＯＥＭユーザー識別子およびCloud-User-IDは存在しないか、または抽象化されていないかもしれない。
図示の実施形態では、クラウド１３０は、個人を識別可能なアカウント情報を維持しなくてもよい。結果として、クラウド１３０は、従来のコンセプトのユーザーアカウントを持たず、ダイレクトアクセスを可能にする非ＯＥＭクラウドログインＡＰＩを欠いていてもよい。デバイス１１０は、クラウド１３０と順番にやり取りすることができる、ＯＥＭクラウドを使用して登録され、ＯＥＭユーザーアカウントと関連付けられてもよい。
一実施形態によるデバイスを登録する方法が、図９の図示された実施形態において説明され、全体として９００で表される。デバイス１１０は、（例えば、ＴＬＳを介して）ＯＥＭクラウドと安全に接続する（ステップ９０１）。デバイス１１０は、ユーザー１０からの入力を使用して、ＯＥＭクラウドにユーザーのユーザー名およびパスワードを送信する（ステップ９０２）。ユーザー名とパスワードが検証（すなわち、正しい）された場合、ＯＥＭクラウドはデバイス１１０にCloud-User-ED、OEM識別子、必要なトークン（例えば、セッショントークンおよび／またはクラウドトークン）、およびデバイスを首尾よく登録するのに必要な任意の他のデータを提供する。ＯＥＭクラウドは、クラウド１３０の他の部分とやり取りしてもよい（ステップ９０３）。デバイス１１０は、（特定のCloud-User-IDおよびOEM-EDにマッピングすることができ、デバイス１１０がそれらを個別に送信しないことを可能にする、または追加の検証としてそれらを別々に要求することを可能にする）セッショントークン、（プッシュ通知サービストークンなどの）任意の他の必要なトークン、デバイス権利公開鍵（本明細書に記載のブロックファンシステムのようなデバイス権利サービスを使用する場合）、および（例えば、デバイスのオペレーティングシステムソフトウェアから取得される）デバイス固有の署名を含む、登録要求をＯＥＭクラウドに送信する（ステップ９０４）。一実施形態では、悪意のあるデバイスが同じデバイスを複数回登録するのを実質的に回避または防止するために、デバイス固有の署名（例えば、識別子またはベンダーアプリケーション識別子）が登録プロセスで利用されてもよい。
方法９００で、ＯＥＭクラウドは、登録要求を検証することができる（ステップ９０５）。登録要求が成功した場合、ＯＥＭクラウドは、登録されたデバイス１１０にDevice-IDを提供する（ステップ９０６）。
同じデバイス１１０の偶発的な重複登録から保護を援助するために、デバイス固有の署名が、デバイス登録要求の一部として提供される。デバイスの署名は、暗号の意味でのシ署名でなくてもよく、真にデバイス固有のものである必要もない（たとえば、アプリケーションインストール固有のものであってもよい）。むしろ、デバイスの署名は、特定のデバイスを一意に識別しようとするために使用できる識別子であってもよい（例えば、ランダムに生成される番号またはオペレーティングシステムによって提供される番号などの、シリアル番号またはアプリケーションインスタンス番号）。デバイス登録プロセスは、成功すると、認可を発行するなどの後の処理での使用のため、生成されたDevice-EDをデバイス１１０に提供することができる。
代替の実施形態では、ＯＥＭクラウドが利用されないかもしれない。クラウド１３０は、ランダムに生成された（おそらく一意の）Cloud-User-EDで、デバイス１１０が登録されることを可能にすることができる。この場合のCloud-User-EDは、特定のグローバルに定義または設定可能なＯＥＭ識別子を含むことができ、デバイス１１０は、デバイス集合情報および所望の相互デバイス処理を実行するための情報を得るために利用されるすべての便宜を維持または提供する役割を果たすことができる。
多くの場合、ＯＥＭは、限定されるわけではないが、ブランド化されたウェブサイトおよびモバイルアプリケーションのような、機器コンポーネント１４０のためのユーザーインターフェースを提供する。したがって、ＯＥＭは、ＯＥＭブランドのユーザーアカウントおよびＯＥＭクラウドによって提供されるデバイス関連サービスを含んで、機器コンポーネント１４０に配信するために必要な対応するシステムコンポーネントを管理することができる。
適切なプライバシーと信頼（暗号化、認証、および認可）を使用する一連のアプリケーションプログラマインターフェース（ＡＰＩ）を介して、ＯＥＭクラウドは、クラウド１３０からどのデバイス１１０が特定のユーザーに関連しているか取得し、認可を管理し、およびＯＥＭの機器コンポーネント１４０の製品寿命にわたって必要とされる任意のデバイスオーナーシップの調整を実行することができる。プライバシーと信頼は、Ｘ．５０９証明書を使用するＴＬＳ１．２＋相互認証、および、ＯＡｕｔｈ２または代理／カスタムのチャレンジ／レスポンスメカニズム（ＯＥＭクラウド）を介してを含む、様々な方法で確立されることができる。ＯＥＭクラウド、ユーザー１０、およびクラウド１３０間のやり取りのためのＯＡｕｔｈ２チャレンジ／レスポンスフロー、つまり方法１０００の例が、図１０の図示の実施形態に示されている。
図示された実施形態では、ユーザー１０は、本明細書に記載されるクラウド１３０と同様に構成され得る、ＯＥＭクラウド１３５からユーザーアカウントを取得することができる（ステップ１００２）。次に、ユーザー１０は、（例えば、ＯＡｕｔｈ２認証処理で使用するための）仮のＯＥＭクラウド識別子および／またはクラウドトークンを取得するために、ＯＥＭクラウド１３５にログインすることができる（ステップ１００４）。ユーザー１０は、先立ってＯＥＭクラウド１３５から取得した仮のＯＥＭクラウド識別子および／またはクラウドトークンをクラウド１３０に提供して、クラウド１３０からのCloud-User-IDを要求することができる（ステップ１００６）。クラウド１３０は、ユーザー１０によって提供されるクラウドトークンおよび／または仮のＯＥＭクラウド識別子を、ＯＥＭクラウド１３５で確認することができる（ステップ１００８）。クラウドトークンおよび／または仮のＯＥＭクラウド識別子が確認された場合、クラウド１３０は、もしかするとＯＥＭクラウド識別子（ＯＥＭユーザー識別子）（仮のＯＥＭクラウド識別子であってもよいが、その仮ステータスをクリアしたもの）とともにCloud-User-IDをユーザー１０に送信することができる。上記で使用される仮のＯＥＭクラウド識別子は、ＯＥＭクラウド１３５およびクラウド１３０が同じユーザーを参照していることを検証するための手段として単に使用されてもよい。仮のＯＥＭクラウド識別子は、どのサーバーに接続するかを指示する、またはＯＥＭクラウド１３５がクラウド１３０とは異なるＯＥＭクラウド識別子（Cloud-User-ID）の使用を許可するなどの他の目的に使用されてもよい。
代替の実施形態では、プライバシーと信頼は、Ｘ．５０９証明書を使用するＴＬＳ１．２＋サーバー側（クラウド）認証、および、ＯＥＭクラウド１３５と確立される、ＯＡｕｔｈ２または代理またはカスタムのチャレンジおよびレスポンスメカニズム（ＯＥＭクラウド）を介して確立されてもよい。別の代替の実施形態では、プライバシーと信頼は、ＴＬＳ１．２＋、またはＯＡｕｔｈ２を伴うカスタムまたは代理の暗号化および認証プロトコル、または代理またはカスタムチャレンジおよびレスポンスメカニズムを使用して確立されてもよい。
本明細書で説明されるように、一実施形態では、クラウド１３０は、ユーザーがアカウントを作成し、その後、ウェブまたはモバイルアプリケーションを使用して彼らのデバイス１１０をアカウントに関連付けることを可能にするユーザーアカウントサービスを提供しなくともよい。代わりに、ＯＥＭクラウドが、これらのサービスを提供してもよい。ユーザーアカウントサービスは、ＯＥＭクラウドによる使用のために、（ＯＥＭユーザー識別子を介して）ＯＥＭユーザーアカウントに関連付けられたデバイス１１０を識別する能力を提供する。クラウド１３０のユーザーアカウントサービスは、匿名扱いのユーザーアカウントを提供することができる。一実施形態では、クラウド１３０は、ＯＥＭクラウド、他のＯＥＭサービス、アプリケーション、および、ユーザー１０、デバイス１１０、ＳＣＭ１２０、機器１４０、クラウド１３０自体などのシステムコンポーネントによって使用され得る、（例えばユーザーアカウント管理サービスを介して）従来のユーザーアカウント管理およびデバイス１１０関連サービスを提供することができる。この実施形態は、本明細書に記載された安全なデータベースアプローチを使用してもしなくてもよく、各システムにおけるＯＥＭによる使用のための、クラウド生成ＯＥＭユーザー識別子（またはＯＥＭクラウド識別子）を公開してもしなくてもよい。クラウド１３０のユーザーアカウント管理サービスによって提供されるユーザーアカウント管理およびデバイス関連サービスは、（限定されるわけではないが）以下を含むことができる。
１）２因子認証と電子メール検証を用いて、（名前、電子メール、電話番号、およびパスワードによる）ユーザーアカウントを作成し、有効化する。
２）ユーザーアカウントに対して、またはユーザーアカウントから、もしくはその両方で、デバイスを追加または削除する。
３）ユーザーアカウントに関連付けられたデバイスと、デバイスに関連付けられた認可を検分する。
一実施形態では、ユーザー１０のユーザーアカウントに関連付けられたすべてのデバイス１１０にわたって認可が共有されてもよい。認可変更は、ＳＣＭ１２０のオーナーデバイス１１０に関連付けられたユーザーアカウントと関連付けられた任意のデバイス１１０によって承認されてもよい。ユーザー１０は、それらのデバイス１１０間でどのように認可が共有されるかを設定できてもよいし、できなくともよい。例えば、ユーザー１０は、どのデバイス１１０がどのＳＣＭ１２０に対する認可を受信するかを設定することができてもよいし、できなくともよい。ユーザーアカウントサービスは、これらの操作が、任意の設定される選択およびシステムルールごとに、ユーザーに代わって実行されることを保証することができる。
Ｘ．収益化
一実施形態でのシステム１００は、システム１００によって実行される特定の処理のために、ユーザー１０からの支払いを要求するように構成されてもよい。このようにして、システム１００は、システム１００によって提供される態様または機能を収益化してもよい。システムコンポーネントが動作し安全に通信するための技術とインフラストラクチャを維持することは、困難で高価なプロセスになる可能性がある。さらに、ユーザー１０は、技術の進歩、改良、市場で提供される新製品および技術との互換性、およびセキュリティパッチまたは機能強化（それらのすべてが資金調達を必要とする可能性がある）を期待する可能性がある。計算コストが高いが、ユーザー１０には直接的または具体的な関与がない、本明細書に記載された多数のシステム処理が存在する。認可の発行、修正、または取り消し、登録、ＳＣＭ１２０のオーナーシップの移転または工場リセット、ファームウェアの更新などの、ユーザー１０が関与する多くの計算コストの高いシステム処理（すなわちサービス）が存在する。サービスに対する支払いは、ユーザー１０、ＯＥＭ、または他のエンティティによって行われてもよい。以下のアクションが、本明細書に記載されるセキュリティモデル／システムの処理に関して収益化されてもよい：認可の発行、デバイス１１０の登録、ＳＣＭ１２０のオーナーシップの移転、ＳＣＭ１２０の工場リセット、およびファームウェアの更新。収益化はこれらのイベントに限定されず、他のイベントまたは状況が収益化の基礎を形成してもよいことを理解されたい。
Ａ．認可の発行
ＯＥＭは、ユーザー１０によって首尾よく発行された各認可について請求されてもよく、その場合、毎日、毎週、または毎月など予め定められた期間の間に生じて、集められた請求金額について請求書が生成される。あるいは、ＯＥＭは、首尾よく発行された各認可についてリアルタイムに請求されてもよい。このリアルタイム課金モデルは、マイクロペイメントをもたらす可能性がある。
ユーザー１０は、ユーザー１０によって首尾よく発行された各認可について請求されてもよく、その場合、毎日、毎週、または毎月など予め定められた期間の間に生じて、集められた請求金額について請求書が生成されえる。あるいは、ユーザー１０は、マイクロペイメントに基づく収益化をもたらすように、ユーザー１０によって首尾よく発行された各認可についてリアルタイムに請求されてもよい。この実施形態では、支払いは、ユーザー１０が料金請求されることに同意することを示して、ユーザー１０によって承認されてもよい。同意は、認可要求が送信されるときに得られてもよく、受信者が認可を受け入れたとき、またはＡＣＰ４００への結果として生じる変化が承認されたときのいずれかで、ユーザーが料金請求されてもよい。同意の証拠は、要求の一部として供給されることができ、これは、支払い承認の証拠がない場合に拒絶されてもよい。
代替の実施形態では、承認を与えるシーケンスが成功しなかった場合、ユーザー１０は直ちに請求されるが、その取引は取り消され／払い戻されてもよい。
一実施形態では、ユーザー１０は、クラウド１３０がユーザー１０に首尾よく発行する各認証について料金請求されてもよく、その場合、毎日、毎週、または毎月などの予め定めた期間の間に生じて、集められた請求金額について請求書が生成されえる。一実施形態では、ユーザー１０は、マイクロペイメントに基づく収益化システムを生み出すように、ユーザー１０によって首尾よく受け取られるか、または依頼された各認可についてリアルタイムに請求されてもよい。この実施形態では、支払いは、ユーザー１０が料金請求されることに同意することを示して、ユーザー１０によって承認されてもよい。同意は、認可要求の受信に併せて得られてもよい。同意の証拠は、要求受諾応答の一部として供給されることができ、これは、支払い承認の証拠がない場合に拒絶されてもよい。要求受諾応答がクラウド１３０によって受信されたとき、またはＡＣＰ４００への結果として生じる変化が承認されたときのいずれかで、ユーザー１０が料金請求されてもよい。代替の実施形態では、シーケンスが成功しなかった場合、ユーザーは直ちに請求されるが、その取引は取り消され、または払い戻されてもよい。
Ｂ．デバイスの登録
ＯＥＭは、ユーザー１０によって首尾よく登録された各デバイスについて請求されてもよく、その場合、毎日、毎週、または毎月など予め定められた期間の間に生じて、集められた請求金額について請求書が生成されえる。一実施形態では、ＯＥＭは、マイクロペイメントタイプのシステムを生じる、首尾よく登録された各デバイス１０についてリアルタイムに請求されてもよい。
一実施形態では、ユーザー１０は、ユーザー１０によって首尾よく登録された各デバイス１０について請求されてもよく、その場合、毎日、毎週、または毎月など予め定められた期間の間に生じて、集められた請求金額について請求書が生成されえる。一実施形態では、ユーザー１０は、マイクロペイメントタイプのシステムを生じる、ユーザーが首尾よく登録した各デバイス１０についてリアルタイムに請求されてもよい。この構成では、支払いは、ユーザーが料金請求されることに同意することを示して、ユーザー１０によって承認されてもよい。同意は、デバイス登録要求の送信に併せて得られてもよく、同意の証拠は、要求の一部として供給されてもよい。支払承認の証拠がない場合、要求は拒絶されてもよく、ユーザーはデバイス登録が正常に処理されたときに料金請求されてもよい。代替の実施形態では、ユーザー１０は直ちに請求されるが、デバイス登録シーケンスが成功しなかった場合、その取引は取り消されるか、または払い戻されてもよい。
Ｃ．ＳＣＭのオーナーシップの移転
一実施形態におけるＯＥＭは、ＯＥＭのユーザー１０によるＳＣＭ１２０のオーナーシップの移転の各成功に対して請求されてもよい。請求書は、予め定められた期間（例えば、毎日、毎週、毎月など）の間に生じて、集められた請求金額について生成されてもよい。ＯＥＭは、マイクロペイメントベースの収益化システムを生じる、ＳＣＭのオーナーシップの成功した各移転に対してリアルタイムに請求されてもよい。
一実施形態でのユーザー１０は、ＳＣＭ１２０のオーナーシップの各成功した転送に対して請求されてもよい。請求書は、毎日、毎週、または毎月などの予め定められた期間の間に生じて、集められた請求金額について生成されてもよい。一実施形態では、ユーザー１０は、マイクロペイメントベースの収益化システムを生じる、ＳＣＭ１２０のオーナーシップの成功した各移転に対してリアルタイムで請求されてもよい。この構成では、支払いは、ユーザーが料金請求されることに同意することを示して、ユーザーによって承認されてもよい。同意は、デバイス登録要求の送信に併せて得られてもよく、同意の証拠は、要求の一部として供給されてもよい。支払承認の証拠がない場合、要求は拒絶されてもよく、ユーザーはデバイス登録が正常に処理されたときに料金請求されてもよい。代替の実施形態では、ユーザー１０は直ちに請求されるが、デバイス登録シーケンスが成功しなかった場合、その取引は取り消されるか、または払い戻されてもよい。
Ｄ．ＳＣＭの工場リセット
ＯＥＭは、ＯＥＭと関連付けられたユーザーによるＳＣＭ１２０の工場リセットの各成功に対して請求されてもよい。請求書は、毎日、毎週、または毎月などの予め定められた期間の間に生じて、集められた請求金額について生成されてもよい。一実施形態では、ＯＥＭは、マイクロペイメントベースの収益化システムを生じる、成功したＳＣＭの各工場リセットに対してリアルタイムで請求されてもよい。
一実施形態では、ユーザー１０は、ＳＣＭ１２０の工場リセットの各成功に対して請求されてもよく、その場合、請求書は、毎日、毎週、または毎月などの予め定められた期間の間に生じて、集められた請求金額について生成されえる。一実施形態では、ユーザー１０は、マイクロペイメントベースの収益化システムを生じる、成功したＳＣＭの各工場リセットに対してリアルタイムで請求されてもよい。この構成では、支払いは、ユーザー１０が料金請求されることに同意することを示して、ユーザー１０によって承認されてもよい。同意は、新規オーナー開始要求が送信されたときに得られてもよく、同意の証拠は、要求の一部として供給されてもよい。支払承認の証拠がない場合、要求は拒絶されてもよい。ユーザー１０は、クラウド１３０が結果として生じるＡＣＰ４００を生成したときに料金請求されてもよい。代替の実施形態では、ユーザー１０は直ちに請求されるが、シーケンスが成功しなかった場合、その取引は取り消されるか、または払い戻されてもよい。
Ｅ．ファームウェアの更新
ＯＥＭは、ユーザー１０によるファームウェアの更新の各成功に対して請求されてもよく、その場合、請求書は、毎日、毎週、または毎月などの予め定められた期間の間に生じて、集められた請求金額について生成されえる。一実施形態でのＯＥＭは、マイクロペイメントベースの収益化システムを生じるであろう、ファームウェアの更新の各成功に対してリアルタイムで請求されてもよい。
ユーザー１０は、ファームウェア更新の各成功に対して請求されてもよく、その場合、請求書は、毎日、毎週、または毎月などの予め定められた期間の間に生じて、集められた請求金額について生成される。一実施形態でのユーザー１０は、成功した各ファームウェア更新に対してリアルタイムで請求されてもよい（例えば、マイクロペイメント）。この構成では、ファームウェア更新が送信された、または始まったとき、支払いが（ユーザー１０が料金請求されることに同意することを示して）ユーザー１０によって承認されてもよい。承認の証拠は、要求の一部として供給されてもよく、支払承認の証拠がない場合、要求は拒絶される。システム１００のコンポーネントがファームウェア更新は成功したことを検出したときに、ユーザー１０は料金請求されてもよい。代替の実施形態では、ユーザー１０は直ちに請求されるが、シーケンスが成功しなかった場合、その取引は取り消されるか、または払い戻されてもよい。
ＸＩ．分散信頼モデル
一実施形態によるシステム１００は、分散信頼モデルを利用することができる。この分散信頼モデルは、デバイス１１０、ＳＣＭ１２０、および機器システムコンポーネント１４０が、信頼を確立し、安全に通信し、および動作することができる間、オンラインおよび／またはオフラインのいずれかであることを可能にすることができる。例えば、デバイス１１０、ＳＣＭ１２０、および機器システムコンポーネント１４０は、オンラインおよびまたはオフラインでのシステムコンポーネントの認証とアクションの認可を可能にすることができる。
Ａ．概要
一実施形態のシステム１００は、秘密性およびプライバシーを強化し、システムコンポーネントを分離し、攻撃面を減少させるために、最小特権の原則を組み込むことができる。システムコンポーネント間の通信とシステムコンポーネント内のデータストレージは、セキュリティ基準をプロセスと一意に組み合わせることで、安全かつ機密に実現することができる。基準には、暗号化、認証、完全性検証、またはセキュリティプロトコル、もしくはそれらの組み合わせが含まれ、プロセスには、プロトコル、ワークフロー、またはシステム状態の管理または検証、もしくはそれらの任意の組み合わせが含まれる。
開示の目的のために、例えば、システムコンポーネントが証明機関と通信することができる場合を含む、システムコンポーネントがインターネットを介してサービスと通信できる場合、システムコンポーネントはオンラインである。
ある意味で、暗号化は、ある程度の機密性のみを提供することができる。暗号化されたメッセージまたは暗号文は、適切な鍵を持つエンティティによってのみ覗かれ、または復号されることができる。鍵は共有秘密または鍵であってもよく、もしくは鍵は公開鍵と非公開鍵によって定義される非対称ペアの一部であってもよい。
メッセージの完全性を検証するため、またはメッセージが改ざんされていないことを確認するために、安全な（暗号化された）ハッシュが暗号化されたメッセージ内に格納されてもよい。メッセージの真正性を検証するために、発信者識別情報が暗号化メッセージ内に格納されてもよい。暗号化されたメッセージに（または、メッセージとともに）対称暗号、メッセージ認証コード（ＭＡＣ）、または非対称暗号（例えば、公開鍵暗号）、デジタル署名を含めることによって、メッセージの完全性と真正性を同時に検証することができる。
非対称暗号では、デジタル署名はそれ自体によって作成者がメッセージに署名し暗号化したことを保証するものではない。そのような保証は、暗号の否認不可または作成者および／または発信元の証拠として記述することができる。
従来の署名−暗号化（Ｓ−Ｅ）アプローチは、秘密の転送に対して脆弱であると考えられる。すなわち、発信者の公開鍵を持つ誰もが復号し、次いで、代わりの非公開鍵を使用してメッセージに再署名し、再暗号化することができる。暗号化（−Ｅ）ステップは、暗号化プロセスの1つまたは複数のステップで発生してもよいし、発生しなくてもよい。例えば、暗号化ステップは、メッセージパッケージの一部として直ちに行われてもよく、またはメッセージは署名され暗号化された構成またはコマンドメッセージであってもよい。暗号化ステップは、ＴＬＳのような通信チャネルトランスポートの一部として行われてもよい。暗号化ステップは、パッケージの機密性が必要でない場合や、通信チャネルなどの他の手段によって提供される場合など、存在しないかもしれない。不要な機密性の具体例は、単に署名されたメッセージであってもよい。
公開鍵がメッセージと共に配信された場合、受信者は、作成者の変更を認識していない可能性がある。公開鍵インフラストラクチャ（ＰＫＩ）によって管理されるであろう、デジタル証明書（Ｘ．５０９）は、特定の公開鍵が特定の作成者の鍵であり、それゆえ、特定のデジタル署名が特定の作成者によって作成されたとの証拠を提供することができる。デジタル証明書がない場合、作成者の証拠、および、もしかすると意図された宛て先の証拠が、Ｓ−Ｅアプローチを使用するとき、暗号化されたメッセージに適切に作成者のＩＤ、宛て先のＩＤ、またはその両方を含むことによって確立されてもよい。Ｓ−Ｅアプローチは、ａ）Ｓ−Ｅメッセージに署名する（Ｓ−Ｓ−Ｅ）など、メッセージを二重以上に署名すること、およびｂ）Ｅ−Ｅ−Ｓメッセージを設計することができる、暗号化後署名（Ｅ−Ｓ）メッセージの暗号化など、メッセージを二重以上に暗号化することの両方を含んでもよい。
対称暗号は、秘密の転送を苦にしないかもしれない。受信者は、作成者が分かること、および、送信者が受信者にメッセージを送信しようとしたことが保証され得る。しかしながら、対称暗号は、双方が共有された秘密を有するので、暗号否認不可を提供しないかもしれない。対称暗号に基づくシステムは、選択されたセキュリティプロトコル、メッセージのパッケージングまたは格納、および通信方式の１つ以上のレイヤを介してこの問題を検討し緩和することができる。
デジタル証明書有りでおよび／または無しで、メッセージの完全性および認証メカニズムを使用する、対称および／または非対称暗号化は、システムコンポーネント間で通信し、システムコンポーネント内にデータを格納するために、システム１００全体で使用される。多くの例が本明細書に記載される。非対称暗号化が実装される場合はいつでも、非対称暗号化の識別された弱点、および他の既知の脆弱性または明示的には識別されていないが一般にセキュリティコミュニティに知られている考慮事項を実質的に克服するために、以下の特徴の１つ以上がシステム１００で使用されてもよい。
・ デジタル証明書
デジタル証明書（Ｘ．５０９）は、クラウド１３０のような、常にまたはほぼ常にオンラインであるシステムコンポーネントのアイデンティティを検証するために使用されてもよい。システムコンポーネントは、公開証明機関、非公開クラウド証明期間、または自己署名証明書の１つ以上を実装してもよい。
・ 公開証明書と鍵
メッセージを復号するために利用され得る公開証明書および／または公開鍵は、メッセージと共に配信されることは決してありえない。すなわち、一実施形態における受信者は、信頼できるソースから事前に公開証明書と公開鍵を受信し、認証しなければならない。公開鍵および証明書は、クラウド１３０ごとまたはＳＣＭ１２０ごととする代わりに、デバイス１１０とクラウド１３０によって定義されるペア間、およびデバイス１１０とＳＣＭ１２０によって定義されるペア間など、実用的または有益と考えられる特定の関係を対象とすることができる。公開鍵と証明書は、利用されるシステムコンポーネントによってのみ格納されてもよい。
３．署名
デジタル証明書が使用されない場合、署名が使用されてもよく、メッセージコンテンツの機能およびセキュリティ要件に適するように、作成者ＩＤおよび／または受信者ＩＤがメッセージ内に含まれてもよい。メッセージは、暗号化されていても、暗号化されていなくてもよく、あるいは、メッセージは二重以上に署名され、および／または二重以上に暗号化されてもよい。
・ 作成者の証拠
システム１００の分散された信頼性のために、システム１００は、特定のメッセージが特定のソースから発信されたことを実質的に保証するように構成されてもよい。例えば、メッセージは、作成者のＩＤが保存される限り、任意のソースによって配信されてもよく、そのメッセージは、その特定のソースから発信されたものとして認証されることができる。メッセージは、特定のシステムコンポーネントに向けられたメッセージの内部が他のコンポーネントによって覗かれず、しかし、信頼されるコンポーネントによって作成されたものとしてすべてのまたは一部のコンポーネントによって検証されるように、構成され、配信されることができる。
共有秘密鍵、公開／非公開鍵、証明書などの対称および非対称鍵は、循環または変更されてもよい。この循環または変更は、侵害回復手順の一部として、またはシステム１００の通常の処理を介して実行されてもよい。システム１００は、周期的に鍵を循環させることができる。システムコンポーネントとメッセージ定義は、オンラインシステムコンポーネント、オフラインシステムコンポーネント、およびオフラインとオンラインを切り替えるコンポーネントを含む、システムコンポーネントまたはシステム通信の中で、鍵循環プロトコルの一部として更新された鍵を提供するアクションをサポートすることができる。例示的なオンラインシステムコンポーネントまたは通信は、クラウド１３０またはクラウド１３０とデバイス１１０との間のペアリングを含む。例示的なオフラインシステムコンポーネントまたは通信は、デバイス１１０、デバイス１１０とＳＣＭ１２０との間のペアリング、ＳＣＭ１２０、機器１４０とＳＣＭ１２０との間のペアリング、および機器１４０を含む。一実施形態では、鍵循環命令および１つ以上の鍵が、ＡＣＰ４００のようなメッセージ内容内で配信されることができる。
クラウド１３０およびクラウド１３０とデバイス１１０との間の通信などのデジタル証明書を使用するシステムコンポーネントまたは通信は、適切な証明機関の証明書取消リスト（ＣＲＬ）を用いて、取り消された証明書を登録することができる。取り消された証明書は、ＣＲＬを用いてリアルタイムに登録されてもよい。代替の実施形態では、無効化された証明書は、毎時、４時間ごと、または毎日などの予め定められた期間でバッチで登録されてもよい。代替の実施形態では、取り消された証明書は、ＣＲＬを用いて登録されないかもしれない。
クラウド１３０およびクラウド１３０とデバイス１１０との間の通信などのデジタル証明書を使用するシステムコンポーネントまたは通信は、認証プロセス中に、証明書が失効しておらず、取り消されていないことを検証することができる。検証は、適切な証明機関のＣＲＬを使用して行うことができる。代替の実施形態では、証明書の取消がチェックされなくてもよい。別の代替実施形態では、証明書有効期限がチェックされなくてもよい。
さらに別の代替実施形態では、適切な証明機関のＣＲＬの代わりに、オンライン証明書ステータスプロトコル（ＯＣＳＰ）が使用されてもよい。ＯＣＳＰの応答者は、証明機関、第三者サービス、またはクラウド１３０内に存在してもよい。
一実施形態では、システムコンポーネントは、チャレンジ／レスポンスセキュリティプロトコル、暗号化されたＩＤ含有メッセージ、エンベロープ公開鍵暗号（ＥＰＫＥ）、および／または、プロセスおよび／または２因子認証などの他の手段の１つ以上とともに、対称および／または非対称暗号を使用して、アイデンティティまたは作成者を検証してもよい。さらに、証明書有りまたは無しで、複数のハードウェアまたはソフトウェアベースのセキュリティおよび認証レイヤが利用されてもよい。例を提供するために、ＢＬＥ認証、ＤＴＬＳ、ＴＬＳS、ＮＦＣ、またはＲＦＩＤ、もしくはそれらの組み合わせなどの、基礎をなす通信チャネルの認証および暗号化に利用される、１つ以上のセキュリティおよび認証レイヤの１つ以上のレイヤが存在し得る。
アイデンティティの変更および取り消し（およびアイデンティティの検証または認証の変更）は、ＡＣＰ４００、工場リセット手順、または鍵循環、もしくはそれらの組み合わせを介してなど、クラウドから又はクラウドへ、もしくはすべてのまたは一部のシステムコンポーネントから又はすべてのまたは一部のシステムコンポーネントへ配信されてもよい。
一実施形態では、証明書は、オンラインシステムコンポーネントのアイデンティティ検証のために使用されてもよいが、その一方で、「生の」非対称暗号化は、オフラインであり得るシステムコンポーネントのために使用されてもよい。証明書は有用なように見えるかもしれないが、証明書には、ＲＯＭ、ＲＡＭ、処理能力、または通信帯域幅／スループットがほとんどないシステムコンポーネントなど、制約のあるデバイスでは利用できない重要なリソースが含まれることがある。
図示された実施形態のシステム１００では、ＳＣＭ１２０、デバイス１１０、および機器１４０が、制約のあるデバイスと見なすことができる。１つまたは２つの証明書が実現可能であるかもしれないが、各認可の真正性ならびに各接続デバイス１１０のアイデンティティを検証するために必要とされる証明書の数は実現可能でないかもしれない。したがって、そのようなシステムコンポーネントでは、「生の」非対称および／または対称暗号化が使用され得る。なぜなら、このタイプの暗号化は、相当に低い処理オーバーヘッドとともに、著しく少ないメモリしか使用しないからである。メモリ使用量が少なくなると、情報を転送するための通信帯域幅の減少ももらたすことができる。
一実施形態では、デバイス１１０は、非対称の非公開／公開鍵のペアを生成することと対照的に、デバイス１１０のアイデンティティを確立するために１つ以上の自己署名デジタル証明書を生成することができる。
代替の実施形態では、生の公開鍵暗号が利用される場合はいつでも、例えば非証明書ベースの使用の場合には、対称暗号が使用されてもよい。
一実施形態では、Ｐ−２５６（ｓｅｃｐ２５６ｒｌ）楕円曲線（ＥＣＣ）（非対称）およびＡＥＳ−１２８（対称）暗号が使用される。１つまたは複数の代替実施形態は、以下のタイプの暗号化の１つまたは複数を利用することができる。Ｐ−１９２（ｓｅｃｐ１９２ｒｌ）楕円曲線（非対称）暗号（ＥＣＣ）、Ｐ−３８４（ｓｅｃｐ３８４ｒｌ）楕円曲線（非対称）暗号（ＥＣＣ）、Ｐ−５２１（ｓｅｃｐ５２１ｒｌ）楕円曲線（非対称）暗号（ＥＣＣ）、ＲＳＡ（非対称）暗号、ＡＥＳ−１９２（対称）暗号、およびＡＥＳ−２５６（対称）暗号。システムは、上記の暗号アルゴリズムに限定されないことに留意されたい。
Ｂ．証明書の検証
一実施形態では、（オンラインおよびオフラインの）システムコンポーネント、認可、および他の重要なデータ項目および設定のすべてまたはサブセットについて真正性または作成者を検証するために、１つ以上の証明書が使用されてもよい。代替の実施形態では、オンラインおよびオフライン両方のシステムコンポーネント、認可、および他の重要なデータ項目および設定のための、メッセージまたは委任された認証又は権限を適切な当事者が承認したことを確かめるために、証明書が連鎖されてもよい（または署名が証明書において連鎖される）。
別の代替実施形態では、システムコンポーネントのアイデンティティおよび認可（および潜在的に他のクラスまたはサブクラス）が、異なる証明機関を持つ各クラスおよび／またはサブクラス（例えば、アイデンティティと認可）をもって、証明書として表される別個のエンティティであってもよい。例えば、各エンティティは、別々の認証および認可ツリーを有してもよい。一実施形態では、認証および認可証明機関は、異なるサーバー上に存在してもよい。
代替の実施形態では、各クラスは同じ証明機関を使用してもよい。別の代替実施形態では、属性（認可）証明書（ＲＦＣ５７５５）が、設定パラメータまたは識別子などの認可または他の情報を表すために使用されてもよい。
ＸＩＩ．分散鍵システム
各システムコンポーネントが互いを認証することができ、データがコンポーネントにアクセス可能である（おそらくデータが必要と考えられるコンポーネントにのみ）ようにデータを機密的かつ安全に配信することができるように、システム１００内のシステムコンポーネントに分散された多数の暗号鍵が存在する。データは、オンラインおよび／またはオフラインで通信することができる。一実施形態による鍵または識別子の配信は、複数のシステムコンポーネントとそれらが所有する暗号鍵（およびいくつかの識別子）を含む、図１１Ａ−Ｂに示されている。さらに、図１６の図示された実施形態も、各システムコンポーネントと、それが所有する非公開／対称暗号鍵のみを有するシステム１００を示している。１つまたは複数の実施形態による暗号鍵の各々が、以下により詳細に説明される。
Ａ．SCM-KeyとSCM-ID
SCM-Key鍵は、特定のＳＣＭ１２０を一意に識別することができる。SCM-Key鍵は、ＳＣＭ１２０によって直接的にまたは製造ツールによって製造プロセス中にのみ生成および格納される非対称の非公開／公開鍵のペアであってもよい。SCM-Key非公開鍵は、ＳＣＭ１２０において、セキュアエンクレーブまたはハードウェアセキュリティモジュール（ＨＳＭ）などのセキュアハードウェアモジュールを含む、セキュアメモリ２２０またはセキュアエレメント内に安全に格納されることができる。
SCM-Key非公開鍵は、他のシステムコンポーネントに送信されない。一方、SCM-Key公開鍵は、デバイス１１０またはクラウド１３０などのSCM-Key公開鍵を利用するシステムコンポーネントに安全に送信され、格納されてもよい。SCM-Key非公開鍵は、ＳＣＭ１２０によって他のシステムコンポーネントに送信されるメッセージを暗号化し、および／または署名するためにＳＣＭ１２０によって使用することができ、並びに、他のシステムコンポーネントからＳＣＭ１２０に送信されたメッセージを復号し、および／または検証するために使用することができる。SCM-Key公開鍵は、特定のＳＣＭ１２０から発信されたメッセージを復号し、および／または検証するためにシステムコンポーネントによって使用さすることができ、並びに、特定のＳＣＭ１２０に向けられたメッセージを暗号化および／または署名するために使用することができる。
一実施形態では、SCM-EDは、SCM-Key鍵と比較して、異なるが関連する目的を果たすことができる。SCM-EDは、特定のＳＣＭ１２０に固有のものと見なすことができる。しかし、SCM-EDは、システム１００のセキュリティモデルに直接参加することはできない。SCM-EDは、記憶および／または表現（例えば、３２ビットまたは６４ビット対２５６ビット）に関して、SCM-Key鍵と比較して、サイズが比較的小さくてもよい。SCM-EDは、ＳＣＭ１２０を識別する際にユーザー１０を支援するために、他のシステムコンポーネントにシステム１００を介して転送され、他のシステムコンポーネントによって使用されてもよい。その結果、SCM-IDは安全な方法で転送され、保管されることができる。SCM-EDは、ユーザー１０または他のシステムサービスによるＳＣＭ１２０の識別をさらに支援するために、デバイス１１０およびクラウド１３０などの他のシステムコンポーネントに格納（キャッシュ）されてもよい。
SCM-EDの変更は期待されていないので、システムコンポーネントは、改ざん、なりすましの試み、またはプロトコル違反の兆候などのセキュリティ異常としての変更をユーザー１０に報告してもよい。変更は、代わりに、ＳＣＭ１２０のオーナー１０に、メモリ破損などの製品故障の兆候として報告されてもよい。
SCM-EDは、ＳＣＭ１２０の識別のためだけに使用されるランダムに生成された識別子であってもよく、またはSCM-EDは他の目的にも役立てられてもよい。このような別の目的の一例は、メディアアクセス制御（ＭＡＣ）アドレス、および／または、例えばブルートゥース（登録商標）ローエナジー（ＢＬＥ）を含む他のサービスと共有されるグローバル／ユニバーサル固有識別子（ＧＵＥＤ／ＵＵＥＤ）などの通信プロトコル識別子として振る舞うことである。SCM-IDの別の例示の目的は、シリアル番号、製造者部品番号（ＭＰＮ）、ユニバーサルプロダクトコード（ＵＰＣ）、国際／ヨーロッパ商品番号（ＥＡＮ）、車両識別番号（ＶＥＳＴ）、または特定のＳＣＭ１２０に固有の他の任意の識別子などの人間／機械可読の識別子としてのものである。
代替の実施形態では、SCM-EDは、特定のＳＣＭ１２０に固有でなくてもよい。固有でないタイプのSCM-EDの例には、国際標準図書番号（ＩＳＢＮ）、ＵＳＢデバイス識別子、および製品モデル、クラス、またはタイプが含まれる。
一実施形態では、SCM-EDは安全に格納されない可能性がある。たとえば、SCM-EDはロギングやレポートの目的でのみ使用されるため、またはいずれのシステムコンポーネントによっても依存されない識別情報の追加部分として使用されるため、セキュアストレージは使用されないかもしれない。さらに別の代替の実施形態では、SCM-EDは存在しないかもしれない。
一実施形態では、SCM-IDと類似の複数の識別子が存在してもよく、それらの各々は特定のＳＣＭ１２０に固有であってもなくてもよい。例えば、ＳＣＭ１２０は、ランダムな内部SCM-ID、外部に見えるシリアル番号、イーサネット（登録商標）ＭＡＣ、ＢＬＥ ＵＵＩＤ、電子シリアル番号（ＥＳＮ）と国際移動局機器アイデンティティ（ＩＭＥＩ）と、および／またはモバイル機器識別子（ＭＥＥＤ）とを含む１つ以上のセルラ識別子を含むことができる。
代替の実施形態では、SCM-Key鍵は、使用中のすべてのＳＣＭ１２０にわたって共有されてもよい。
一実施形態では、SCM-Key公開鍵は、それを利用するシステムコンポーネントに安全に送信されず、および／または記憶されないかもしれない。
一実施形態では、SCM-Key非公開鍵は、セキュアメモリ２２０またはセキュアエレメントまたは同等のハードウェアモジュールに格納されないが、それでも安全に格納される。例えば、SCM-Key非公開鍵は、静止時に暗号化されてもよく、そのようなデータへのアクセスを防止するために、ソフトウェアベースの対処および／またはハードウェアベースの対処が実装されてもよいし、ハードウェアおよび／または物理的な障害物またはシールドが実装されてもよい。ＪＴＡＧおよび他のポートが無効化されてもよい。攻撃ベクトルを排除するために、強化されたソフトウェアインターフェースが実装されてもよい。信頼できる実行環境、ハードウェアまたはソフトウェアが制定され、オペレーティングシステムのルートアクセスまたはセキュリティ破壊の招来を検出するための検出システムが実装されてもよい。別の実施形態では、SCM-Key非公開鍵は安全に記憶されない。
一実施形態では、SCM-Key公開／非公開鍵は、鍵循環または工場リセットの結果として変更および／または生成されてもよい。
一実施形態では、１つ以上の証明書が、SCM-Key鍵として使用されてもよい。別の実施形態では、SCM-Key鍵は対称鍵である。別の代替実施形態では、SCM-Key鍵はＯＡｕｔｈ２トークンである。さらに別の代替実施形態では、SCM-Key鍵の代わりに、別の認証鍵またはトークンタイプおよび／またはチャレンジ／レスポンスメカニズムが使用されてもよい。
代替の実施形態では、後で使用するために、１つ以上のSCM-Key鍵が作成されて、ＳＣＭ１２０に格納されてもよい。この手法は、ＳＣＭ１２０が通常の動作中にそのような鍵を生成する能力を持たない場合に有用であり得る。一実施形態では、ＳＣＭ１２０は、工場リセット後に鍵の循環および／または異なる鍵をサポートすることができるように、複数の鍵が利用されてもよい。この実施形態では、ＳＣＭ１２０は、どのSCM-Key鍵が使用可能であるが使用中ではないか、使用中であるか、廃棄されているか、または撤去されているか、を管理することができる。あるいは、オンデマンド（１度に１つ）またはバッチで（本明細書に記載されるように後の時点での使用のために）など、SCM-Key鍵がクラウド１３０（または他のシステムコンポーネント）によって生成され、通常の動作中に、ＳＣＭ１２０に格納されてもよい。
一実施形態では、SCM-Key鍵は存在せず、この場合、システムコンポーネントがＳＣＭ１２０と通信し、および／またはＳＣＭ１２０の真正性を検証するために、他の手段が使用されてもよい。
Ｂ．Equipment-Key
Equipment-Key鍵は利用されてもされなくてもよい。それは、１つ以上の機器１４０システムと通信するためにＳＣＭ１２０によって保持される独自の鍵を生成することを望む機器製造業者（ＯＥＭ）向けのものである。SCM-Equipment-Key鍵は、逆使用モデルである（おそらく好まれる）。
Equipment-Key鍵は、取り付けられたＳＣＭ１２０に対し、特定の機器１４０を一意に識別することができる。Equipment-Key鍵は、機器１４０によって直接的にまたは製造ツールによって、機器製造プロセス中にのみ生成される非対称の非公開／公開鍵のペアであってもよい。Equipment-Key非公開鍵は、機器において、セキュアメモリ２２０内、またはセキュアエンクレーブまたはハードウェアセキュリティモジュール（ＨＳＭ）などのセキュアエレメントまたは同等のハードウェアモジュール内に安全に格納されてもよい。
Equipment-Key非公開鍵は、図示の実施形態では他のシステムコンポーネントには送信されない。Equipment-Key公開鍵は、ＳＣＭ１２０のようなEquipment-Key公開鍵を利用するシステムコンポーネントに安全に送信され、格納されてもよい。Equipment-Key公開鍵は、製造ツールによって機器１４０またはＳＣＭ１２０の製造中にＳＣＭ１２０（または他の機器）に送信されてもよい。Equipment-Key公開鍵は、通信リンクまたは物理的媒体を介して機器１４０または他のシステムコンポーネントによってＳＣＭ１２０（または他の機器）に送信されてもよい。Equipment-Key非公開鍵は、機器１４０が他のシステムコンポーネントに送信するメッセージを暗号化および／または署名するために、特定の機器１４０によって使用され、および、他のシステムコンポーネントから機器１４０に送信されるメッセージを復号および／または検証するために使用されてもよい。
Equipment-Key公開鍵は、特定の機器１４０から発せられたメッセージを復号および／または検証するためにシステムコンポーネントによって使用され、特定の機器１４０に向けられるメッセージを暗号化および／または署名するために使用されてもよい。
代替の実施形態では、Equipment-Key公開鍵は、Equipment-Key公開鍵を利用するシステムコンポーネントに安全に送信されず、および／または格納されない。
一実施形態のEquipment-Key公開鍵は、システムコンポーネントが、格納されたEquipment-Key公開鍵をまだ有していない場合にのみ、ＳＣＭ１２０などのシステムコンポーネントに送信されてもよい（または、受け入れられてもよい）。これは、製造時または工場リセットに続いて発生する可能性がある。追加的に、または代替的に、Equipment-Key公開鍵は、製造ツールによって別のシステムコンポーネントに送信のみされてもよい。代替の実施形態では、Equipment-Key公開鍵は、製造ツールによって別のシステムコンポーネントに送信されないかもしれない。
代替実施形態では、Equipment-Key鍵は、使用中のすべての機器１４０にわたって共有されてもよい。
一実施形態では、Equipment-Key公開鍵は、１つ以上の他のシステムコンポーネントによる承認なしでは、システムコンポーネントに送信されず、および／またはシステムコンポーネントによって使用されないかもしれない。例えば、ＳＣＭ１２０は、デバイス１１０、ユーザー１０、またはクラウド１３０からの承認なしでは、特定の機器１４０と通信することができない。追加的、または代替的に、機器１４０はそれ自体を承認しなくてもよい。
一実施形態のEquipment-Key秘密鍵は、セキュアメモリ２２０またはセキュアエレメントまたは同等のハードウェアモジュールに格納されない。ただし、Equipment-Key秘密鍵はそれでも安全に格納されえる。例えば、Equipment-Key秘密鍵は、静止時に暗号化されてもよく、そのようなデータへのアクセスを防止するために、ソフトウェアベースの対処および／またはハードウェアベースの対処が実装されてもよいし、ハードウェアおよび／または物理的な障害物またはシールドが実装されてもよい。ＪＴＡＧおよび他のポートが無効化されてもよい。攻撃ベクトルを排除するために、強化されたソフトウェアインターフェースが実装されてもよい。信頼できる実行環境、ハードウェアまたはソフトウェアが制定され、オペレーティングシステムのルートアクセスまたはセキュリティ破壊の招来を検出するための検出システムが実装されてもよい。別の実施形態では、Equipment-Key非公開鍵は安全に記憶されない。
一実施形態では、Equipment-Key公開／非公開鍵は、鍵循環または工場リセットの結果として変更および／または生成されてもよい。
一実施形態では、Equipment-Key鍵のために１つ以上の証明書が使用されてもよい。代替の実施形態では、Equipment-Key鍵は対称鍵である。別の代替実施形態では、Equipment-Key鍵はＯＡｕｔｈ２トークンである。さらに別の代替実施形態では、Equipment-Key鍵の代わりに、別の認証鍵またはトークンタイプおよび／またはチャレンジ／レスポンスメカニズムが使用される。
一実施形態では、ＳＣＭ１２０を含むシステムコンポーネントは、複数の機器１４０と通信してもよく、その結果、システムコンポーネントは、複数の異なるEquipment-Key公開鍵を所有してもよい。
一実施形態では、Equipment-Key鍵は存在しなくてもよく、この場合、ＳＣＭが機器１４０と通信し、および／または真正性を検証するために他の手段が使用されてもよい。
Ｃ．SCM-Equipment-Key
SCM-Equipment-Key鍵は利用されてもされなくてもよい。それは、１つ以上の機器１４０システムと通信するためにＳＣＭ１２０によって提供される外部的な生成鍵を使用することを望む機器メーカ向けのものである。Equipment-Key鍵は逆使用モデルである。
SCM-Equipment-Key鍵は、取り付けられた機器１４０に対し、ＳＣＭ１２０を一意に識別することができる。SCM-Equipment-Key鍵は、ＳＣＭ１２０によって直接的にまたは製造ツールによって製造プロセス中にのみ生成および格納される、非対称の非公開／公開鍵のペアであってもよい。
SCM-Equipment-Key鍵は、機器メーカが、機器１４０は十分に保護されておらず、そのため、SCM-Key公開鍵でさえも公開しないことが好ましいと考えられるモデルを含む、任意の望ましいと考えるセキュリティモデルを使用することができるように、SCM-Key鍵とは別けられてもよい。
SCM-Equipment-Key非公開鍵は、ＳＣＭ１２０において、セキュアメモリ２２０内、またはセキュアエンクレーブまたはハードウェアセキュリティモジュール（ＨＳＭ）などのセキュアエレメントまたは同等のハードウェアモジュール内に安全に格納されてもよい。SCM-Equipment-Key非公開鍵は、図１１の図示の実施形態において、他のシステムコンポーネントに送信されない。さらに、図示された実施形態において、SCM-Equipment-Key公開鍵は、製造ツール、通信リンク、または物理的媒体を介して、取り付けられた機器１４０にのみ送信され、格納されてもよい。
SCM-Equipment-Key非公開鍵は、ＳＣＭ１２０が機器１４０に送信するメッセージを暗号化しおよび／または署名し、機器１４０からＳＣＭ１２０に送信されたメッセージを復号しおよび検証するために、ＳＣＭ１２０によって使用されてもよい。SCM-Equipment-Key公開鍵は、特定のＳＣＭ１２０から発せられたメッセージを復号しおよび／または検証し、特定のＳＣＭ１２０向けのメッセージを暗号化しおよび／または署名するために機器１４０によって使用されてもよい。
一実施形態では、SCM-Equipment-Key公開鍵は、例えばデバイス１１０、クラウド１３０、またはＳＣＭ１２０、またはそれらの組み合わせを含む、取り付けられた機器１４０以外のシステムコンポーネントに安全に送信され、格納されてもよい。
一実施形態では、SCM-Equipment-Key公開鍵は、システムコンポーネントに安全に送信されないか、または格納されないかもしれない。
特定のＳＣＭ１２０に取り付けられる１つまたは複数の機器１４０が存在してもよい。このように、システム１００は、１ＳＣＭ多機器システムを定義することができる。１ＳＣＭ多機器システムでは、デバイス１１０は、個々の機器１４０またはそれらの任意の組み合わせに対するステータスの取得、コマンドの発行、および／または個々の機器１４０またはそれらの任意の組み合わせからの応答の受信を行ってもよい。
使用中のＳＣＭの全部または一部にわたって共有されるSCM-Equipment-Key鍵が、一実施形態に従って実装されてもよい。
一実施形態において、SCM-Equipment-Key公開鍵は、システムコンポーネントが既に格納されたEquipment-Key公開鍵を有する場合、システムコンポーネント（例えば、機器１４０）によって受け入れられないかもしれない。
一実施形態では、SCM-Equipment-Key公開鍵は、１つ以上の他のシステムコンポーネントによる承認なしでは、機器１４０に送信されず、および／または機器１４０によって使用されなくてもよい。例えば、機器１４０は、デバイス１１０、ユーザー１０、またはクラウド１３０からの承認なしでは、特定のＳＣＭ１２０と通信することができない。追加的に、または代替的に、ＳＣＭ１２０はそれ自体を承認しなくてもよい。
一実施形態では、SCM-Equipment-Keyを使用する代わりに、SCM-Key鍵が利用されてもよい。そのような場合、様々な特定されたSCM-Equipment-Key処理が、SCM-Keyにも適用されてもよい。
一実施形態では、SCM-Equipment-Key非公開鍵は、セキュアメモリ２２０またはセキュアエレメントまたは同等のハードウェアモジュールに格納されない。SCM-Equipment-Key非公開鍵はそれでも安全に格納され得る。例えば、SCM-Equipment-Key非公開鍵は、静止時に暗号化され、そのようなデータへのアクセスを防止するために、ソフトウェアベースの対処および／またはハードウェアベースの対処が実装されてもよいし、ハードウェアおよび／または物理的な障害物またはシールドが実装されてもよい。ＪＴＡＧおよび他のポートは無効にされてもよい。攻撃ベクトルを排除するために、強化されたソフトウェアインターフェースが実装されてもよい。信頼できる実行環境、ハードウェアまたはソフトウェアが制定され、オペレーティングシステムのルートアクセスまたはセキュリティ破壊の招来を検出するための検出システムが実装されてもよい。代替の実施形態では、SCM-Equipment-Key非公開鍵は安全に格納されない。
一実施形態では、SCM-Equipment-Key公開鍵は、SCM-Equipment-Key公開鍵を利用するシステムコンポーネントによって安全に格納されない。
SCM-Equipment-Key公開／非公開鍵は、本開示の一実施形態による鍵循環または工場リセットの結果として変更および／または生成されてもよい。
複数のシステムコンポーネント（例えば、機器１４０）は、単一のＳＣＭ１２０と通信することができ、複数のSCM-Equipment-Key公開／非公開鍵のペアが利用されてもよい。
１つ以上の証明書が、SCM-Equipment-Key鍵のために使用されてもよい。あるいは、SCM-Equipment-Key鍵は対称鍵でもよい。別の代替実施形態では、SCM-Equipment-Key鍵はＯＡｕｔｈ２トークンであってもよい。さらに別の代替実施形態では、SCM-Equipment-Key鍵の代わりに、別の認証鍵またはトークンタイプおよび／またはチャレンジ／レスポンスメカニズムが使用されてもよい。
代替の実施形態では、後で使用するために、１つ以上のSCM- Equipment-Key鍵が作成されて、ＳＣＭ１２０に格納されてもよい。この手法は、ＳＣＭ１２０が通常の動作中にそのような鍵を生成する能力を持たない場合に有用であり得る。一実施形態では、ＳＣＭ１２０は、工場リセット後に鍵の循環および／または異なる鍵をサポートすることができるように、複数の鍵が利用されてもよい。この実施形態では、ＳＣＭ１２０は、どのSCM-Equipment-Key鍵が使用可能であるが使用中ではないか、使用中であるか、廃棄されているか、または撤去されているか、を管理することができる。あるいは、オンデマンド（１度に１つ）またはバッチで（本明細書に記載されるように後の時点での使用のために）など、SCM-Equipment-Key鍵がクラウド１３０（または他のシステムコンポーネント）によって生成され、通常の動作中に、ＳＣＭ１２０に格納されてもよい。
一実施形態では、SCM-Equipment-Key鍵が存在せず、この場合、機器がＳＣＭ１２０と通信し、および／またはＳＣＭ１２０の真正性を検証するために他の手段が使用されてもよい。
Ｄ．Device-SCM-Key、Device-ID、およびDevice-SCM-ID
Device-SCM-Key鍵は、デバイス１１０とＳＣＭ１２０との間の特定のペアリング（デバイス／ＳＣＭペア）を一意的に識別することができる。図示された実施形態におけるDevice-SCM-Key鍵は、デバイス１１０によって生成され格納される非対称非公開／公開鍵のペアである。クラウド１３０が、デバイス１１０が認可を発行されていないＳＣＭ１２０のような新しいＳＣＭ１２０のためのデバイス１１０への認可を発行することを要求するときに、Device-SCM-Key鍵が生成されてもよい。Device-SCM-Key鍵は、製造中など、デバイス１１０が工場リセットＳＣＭ１２０のオーナーになることを要求しているとき、またはオーナーシップを移転するときにも生成されてもよい。
この手法は、侵害された各Device-SCM-Key鍵の露出を単一のＳＣＭ１２０に制限することができるので、実質的に固有のDevice-SCM-Key鍵が各デバイス／ＳＣＭのペアに対して使用されることができる。これは、特定のデバイス１１０に関連付けられたすべてのＳＣＭ１２０に対して（例えば、Device-Keyを用いて）単一の鍵が使用された場合のように、特定のデバイス１１０に関連付けられたすべてのＳＣＭ１２０への露出とは対照的である。
一実施形態のDevice-SCM-Key非公開鍵は、デバイス１１０において、セキュアメモリ２２０内、またはセキュアエンクレーブまたはハードウェアセキュリティモジュール（ＨＳＭ）などのセキュアエレメントまたは同等のハードウェアモジュール内に安全に格納されてもよい。Device-SCM-Key非公開鍵は、他のシステムコンポーネントに送信されなくてもよい。一方、Device-SCM-Key公開鍵は、クラウド１３０のような、Device-SCM-Key公開鍵を利用するシステムコンポーネントに安全に送信され、格納されてもよい。
Device-SCM-Key非公開鍵は、関連付けられたＳＣＭ１２０のためのメッセージを暗号化および／または署名するためにデバイス１１０によって使用されてもよく、関連付けられたＳＣＭ１２０からデバイス１１０に送信されたメッセージを復号および／または検証するために使用されてもよい。このメッセージは、認可を発行するプロセス中、またはオーナーデバイス１１０が関連付けられたＳＣＭ１２０のためのＡＣＰ４００に署名し、署名されたＡＣＰ４００をクラウド１３０に送信するときなど、デバイス１１０に直接送信されてもされなくてもよい。Device-SCM-Key公開鍵は、関連付けられたデバイス１１０から発せられたメッセージを復号および／または検証するためにＳＣＭ１２０によって使用されてもよく、ＳＣＭ１２０から関連付けられたデバイス１１０向けのメッセージを暗号化および／または署名するために使用されてもよい。
Device-IDは、Device-SCM-Key鍵と比較して、異なるが関連する目的を果たすことができる。Device-IDは、（特定のデバイス／ＳＣＭのペアにではなく）特定のデバイス１１０に実質的に固有であり、クラウド１３０によって生成されてもよい。Device-IDは、システム１００のセキュリティモデルに直接参加することはできない。Device-IDは、記憶および／または表現（例えば、３２ビットまたは６４ビット対２５６ビット）に関して、Device-SCM-Key鍵と比較して、サイズが比較的小さくてもよい。Device-IDは、デバイス１１０を識別し、デバイス特有のサービスを可能にするのを支援するために、システム１００を介して、（クラウド１３０、ＳＣＭ１２０、およびユーザー１０などの）他のシステムコンポーネントに転送され、それらによって使用されてもよい。デバイス特有のサービスの例には、ＳＭＳおよびプッシュ通知が含まれる。その結果、Device-IDが安全に転送され、記憶されることを確保するための努力がなされえる。
Device-IDの変更は期待されていないが、一部のシステムコンポーネントは、デバイスオーナー１０にセキュリティ異常または製品故障として変更を報告できるようにしてもよい。セキュリティ異常は、改ざん、なりすましの試み、またはプロトコル違反の結果であるかもしれない。同じ物理的なデバイス１１０であっても、アプリケーションが除去され、再インストールされたり、メモリが消去されたり、またはアップグレードされたりすると、所定のデバイス１１０が、その製品寿命を通じて、多数のユニークなDevice-IDを循環することがあるため、製品故障が、メモリ破損から生じる可能性がある。
Device-IDは、純粋にデバイス識別のために使用される、ランダムに生成された識別子であってもよい。あるいは、デバイスIDは他の目的にも役立てられてもよい。このような別の目的の一例は、メディアアクセス制御（ＭＡＣ）アドレス、例えばブルートゥース（登録商標）ローエナジー（ＢＬＥ）を含む他のサービスと共有されるグローバル／ユニバーサルユニーク識別子（ＧＵＥＤ／ＵＵＥＤ）などの通信プロトコル識別子として振る舞うことである。Device-IDの別の例示の目的は、シリアル番号、製造者部品番号（ＭＰＮ）、ユニバーサルプロダクトコード（ＵＰＣ）、国際／ヨーロッパ商品番号（ＥＡＮ）、車両識別番号（ＶＥＳＴ）、ユーザー定義文字列、または特定のデバイス１１０に固有の他の任意の識別子などの人間／機械可読の識別子としてのものである。
代替の実施形態では、Device-IDは、特定のデバイス１１０に固有でないかもしれない。固有ではないタイプのDevice-IDの例には、国際標準図書番号（ＩＳＢＮ）、ＵＳＢデバイス識別子、および製品モデル、クラス、またはタイプが含まれる。
一実施形態では、Device-IDは安全に格納されないかもしれない。例えば、Device-IDは、ロギングや報告目的、あるいはいずれのシステムコンポーネントによっても依存されない追加の識別情報の部分としてのみ使用されるため、セキュアストレージが利用されなくてもよい。
１つ以上の実施形態では、Device-IDが存在しないか、または利用されないかもしれないことを理解されたい。
代替実施形態のDevice-IDは、デバイス１１０によって生成されてもよい。
一実施形態では、Device-IDに類似した複数の識別子が存在してもよく、各識別子は、特定のデバイス１１０に固有であってもなくてもよい。例えば、デバイス１１０は、ランダムな内部Device-ID、外部に見えるシリアル番号、イーサネット（登録商標）ＭＡＣ、ＢＬＥ ＵＵＩＤ、電子シリアル番号（ＥＳＮ）と国際移動局機器アイデンティティ（ＩＭＥＩ）と、および／またはモバイル機器識別子（ＭＥＥＤ）、デバイス名、またはユーザー識別子、またはそれらの任意の組み合わせとを含むセルラ識別子を含むことができる。
Device-SCM-EDは、Device-EDと同様であってもよいが、図示された実施形態では、Device-SCM-EDは、制約付きデバイスまたは制約付き帯域幅インターフェース、またはその両方との使用に向けられたものである。Device-SCM-EDは、一実施形態では、特定のデバイス／ＳＣＭのペアに対して実質的に固有であってもよく、クラウド１３０によって生成されてもよく、システム１００のセキュリティモデルに直接的に参加しない。Device-SCM-EDは、記憶および／または表現（例えば、８ビット又は１６ビット対３２又は６４ビット）に関して、Device-EDと比較して、サイズが比較的小さくてもよい。
Device-SCM-EDは、デバイス１１０とＳＣＭ１２０との間の安全な通信チャネルを確立するのを支援するために、クラウド１３０、デバイス１１０、およびＳＣＭ１２０などの他のシステムコンポーネントにシステム１００を介して転送され、それらによって使用されてもよい。一実施形態では、Device-SCM-EDは、ＡＣＰ４００および／またはＡＣＰコンテナ４１０内で配信されえるように、クラウド１３０のみに格納されてもよい。Device-SCM-IDは、場合によっては、安全に転送または格納されなくてもよい。
Device-SCM-EDの変更は期待されていない。その結果、一部のシステムコンポーネントは、デバイスオーナー１０にセキュリティ異常または製品故障としての変更を報告できるようにしてもよい。セキュリティ異常は、改ざん、なりすましの試み、またはプロトコル違反の結果であるかもしれない。同じ物理的なデバイス１１０であっても、アプリケーションが除去され、再インストールされたり、メモリが消去されたり、またはアップグレードされたりすると、所定のデバイス１１０が、その製品寿命を通じて、多数のユニークなDevice-SCM-IDを循環することがあるので、製品故障が、メモリ破損から生じる可能性がある。
一実施形態では、Device-SCM-EDは、純粋にデバイス識別のために使用される、ランダムに生成された小さい識別子であってもよいし、特定のＳＣＭ１２０の環境内で一意であってもよい。あるいは、Device-SCM-EDが存在しなくてもよい。
Device-SCM-EDは、一実施形態では、デバイス１１０によって生成されてもよい。場合によっては、Device-SCM-EDに類似した複数の識別子が存在し、その場合、識別子の各々は、特定のデバイス１１０に固有であってもなくてもよい。例えば、デバイス１１０は、他の小さなランダムな識別子を含んでもよい。
一実施形態では、Device-Key鍵は、Device-SCM-Key鍵に代わって、使用中の特定のデバイス１１０のみに固有のものであってもよい。この実施形態では、デバイス１１０の登録プロセス中にDevice-Keyが生成されてもよい。あるいは、Device-Key鍵は、Device-SCM-Key鍵の代わりに、使用中のすべてのデバイス１１０にわたって共有されてもよい。
一実施形態では、Device-SCM-Key公開鍵は、Device-SCM-Key公開鍵を利用するシステムコンポーネントに安全に送信されず、および／または格納されないかもしれない。
Device-SCM-Key非公開鍵は、セキュアメモリ２２０またはセキュアエレメントまたは同等のハードウェアモジュールに格納されないかもしれない。ただし、Device-SCM-Key非公開鍵はそれでも安全に格納され得る。例えば、セキュアメモリ２２０を使用しないセキュアストレージは、Device-SCM-Key非公開鍵が静止時に暗号化されてもよい、そのようなデータに対するアクセスを防止するために、ソフトウェアベースの対処および／またはハードウェアベースの対処が実装されてもよい、および、ハードウェアおよび／または物理的な障害物またはシールドが実装されてもよい、とのいずれか１つ以上によって達成することができる。ＪＴＡＧおよび他のポートが無効化されてもよい。攻撃ベクトルを排除するために、強化されたソフトウェアインターフェースが実装されてもよい。信頼できる実行環境、ハードウェアまたはソフトウェアが制定され、オペレーティングシステムのルートアクセスまたはセキュリティ破壊の招来を検出するための検出システムが実装されてもよい。代替の実施形態では、Device-SCM-Key非公開鍵は安全に格納されない。
一実施形態では、Device-SCM-Key公開／非公開鍵は、鍵循環または工場リセットの結果として、変更または生成、またはその両方が行われてもよい。
一実施形態では、１つ以上の証明書がDevice-SCM-Key鍵のために使用されてもよい。あるいは、Device-SCM-Key鍵は、対称鍵であってもよい。別の代替実施形態では、Device-SCM-Key鍵はＯＡｕｔｈ２トークンであってもよい。さらに別の代替実施形態では、別の認証鍵またはトークンタイプおよび／またはチャレンジ／レスポンスメカニズムが、Device-SCM-Key鍵の代わりに使用されてもよい。
後で使用するために、１つ以上のDevice-SCM-Key鍵が作成されて、デバイス１１０に格納されてもよい。この手法は、デバイス１１０が通常動作中にそのような鍵を生成する能力を持たない場合に有用であり得る。一実施形態では、デバイス１１０が、工場リセット後に鍵の循環および／または異なる鍵をサポートすることができるように、複数の鍵が利用されてもよい。この実施形態では、デバイス１１０は、どのDevice-SCM-Key鍵が使用可能であるが使用中でないか、使用中であるか、廃棄されているか、または撤去されているか、を管理することができる。あるいは、オンデマンド（１度に１つ）またはバッチで（本明細書に記載されるように後の時点での使用のために）など、Device-SCM-Key鍵がクラウド１３０（または別のシステムコンポーネント）によって生成され、通常の動作中に、デバイス１１０に格納されてもよい。
一実施形態では、Device-SCM-Key鍵が存在しなくてもよく、この場合、システムコンポーネントがデバイス１１０と通信し、および／またはデバイス１１０の真正性を検証するために他の手段が使用されてもよい。
Ｅ．User-SCM-KeyおよびUser-SCM-ID
一実施形態では、User-SCM-Key鍵は、ユーザーアカウントとＳＣＭ１２０との間の特定のペアリング（ユーザーアカウント／ＳＣＭペア）を一意的に識別することができる。図示された実施形態におけるUser-SCM-Key鍵は、クラウド１３０内のユーザーアカウントサービスによって生成され格納される非対称非公開／公開鍵のペアである。User-SCM-Key鍵は、クラウド１３０が、ユーザーアカウントが認可を発行されていないＳＣＭ１２０などの新しいＳＣＭ１２０に対するユーザーのユーザーアカウントに関連付けられたデバイス１１０への認可を発行するように要求するときに生成されてもよい。User-SCM-Key鍵は、ユーザーのユーザーアカウントに関連付けられたデバイス１１０が、製造中など、工場リセットＳＣＭ１２０のオーナーになることを要求しているとき、またはオーナーシップを移転するときにも生成されてもよい。User-SCM-Keyは、少なくともユーザーアカウントサービスによって、ＡＣＰ４００に署名する（および、ＳＣＭ１２０によって、ＡＣＰコンテナ４１０が承認されたことを復号して検証する）ために使用される。
この手法は、侵害された各User-SCM-Key鍵の露出を単一のＳＣＭ１２０に制限することができるので、実質的に一意のUser-SCM-Key鍵が各ユーザーアカウント／ＳＣＭのペアに対して使用されることができる。これは、特定のユーザーアカウントに関連付けられたすべてのＳＣＭ１２０に対して（例えば、User-Keyを用いて）単一の鍵が使用された場合のように、特定のユーザーアカウントに関連付けられたすべてのＳＣＭ１２０への露出とは対照的である。
一実施形態におけるUser-SCM-Key非公開鍵は、クラウド１３０のユーザーアカウントサービスによって安全に格納されてもよい。User-SCM-Key非公開鍵は、他のシステムコンポーネントに送信されなくてもよい。一方、User-SCM-Key公開鍵は、ＳＣＭ１２０のような、User-SCM-Key公開鍵を利用するシステムコンポーネントに安全に送信され、格納されてもよい。
User-SCM-Key非公開鍵は、関連付けられたＳＣＭ１２０へのメッセージを暗号化および／または署名するためにユーザーアカウントサービスによって使用されてもよく、関連付けられたＳＣＭ１２０からユーザーアカウントサービスに送信されたメッセージを復号および／または検証するために使用されてもよい。User-SCM-Key公開鍵は、ユーザーアカウントサービスから発せられたメッセージを復号および／または検証するためにＳＣＭ１２０によって使用されてもよく、ＳＣＭ１２０からユーザーアカウントサービス宛のメッセージを暗号化および／または署名するために使用されてもよい。
一実施形態では、User-SCM-KeyがDevice-SCM-Keyの代わりに使用されてもよい。この実施形態では、ユーザーアカウントに関連付けられたすべてのデバイス１１０は、（個々のDevice-SCM-Key鍵の代わりに）同じUser-SCM-Keyを使用してもよい。
一実施形態では、User-SCM-Key鍵とDevice-SCM-Key鍵の両方が使用される。この実施形態では、例えば、ＡＣＰ４００のＡＣＰ外層２は、User-SCM-Key鍵を使用して署名されてもよいが、デバイス１１０は、Device-SCM-Key鍵を使用して個別に認証される。
一実施形態では、User-Key鍵は、User-SCM-Key鍵の代わりに、特定のユーザーアカウントにのみ固有であってもよい。この実施形態では、User-Keyは、ユーザーアカウント作成プロセス中に生成されてもよい。あるいは、User-Key鍵は、User-SCM-Key鍵の代わりに、そのユーザーのユーザーアカウントに関連付けられたすべてのデバイス１１０にわたって共有されてもよい。
一実施形態では、User-SCM-Key公開鍵は、User-SCM-Key公開鍵を利用するシステムコンポーネントに安全に送信されず、および／または格納されないかもしれない。
User-SCM-Key非公開鍵は、セキュアメモリ２２０またはセキュアエレメント、または同等のハードウェアモジュールに格納されないかもしれない。ただし、User-SCM-Key非公開鍵はそれでも安全に格納されることができる。例えば、セキュアメモリ２２０を使用しないセキュアストレージは、User-SCM-Key非公開鍵が静止時に暗号化されてもよい、そのようなデータに対するアクセスを防止するために、ソフトウェアベースの対処および／またはハードウェアベースの対処が実装されてもよい、および、ハードウェアおよび／または物理的な障害物またはシールドが実装されてもよい、とのいずれか１つ以上によって達成することができる。ＪＴＡＧおよび他のポートが無効化されてもよい。攻撃ベクトルを排除するために、強化されたソフトウェアインターフェースが実装されてもよい。信頼できる実行環境、ハードウェアまたはソフトウェアが制定され、オペレーティングシステムのルートアクセスまたはセキュリティ破壊の招来を検出するための検出システムが実装されてもよい。代替の実施形態では、User-SCM-Key非公開鍵は安全に格納されない。
一実施形態では、User-SCM-Key公開／非公開鍵は、鍵循環または工場リセットの結果として、変更または生成されるか、またはその両方が行われてもよい。
一実施形態では、１つ以上の証明書がUser-SCM-Keyのために使用されてもよい。あるいは、User-SCM-Key鍵は対称鍵であってもよい。別の代替実施形態では、User-SCM-Key鍵はＯＡｕｔｈ２トークンであってもよい。さらに別の代替実施形態では、別の認証鍵またはトークンタイプおよび／またはチャレンジ／レスポンスメカニズムが、User-SCM-Key鍵の代わりに使用される。
一実施形態では、後の使用のため、特定のＳＣＭ１２０のために（またはグローバル鍵プールとしてのすべてのＳＣＭ１２０のために）、１つ以上のUser-SCM-Key鍵が、クラウド１３０のユーザーアカウントサービスによって作成され格納されてもよい。この手法は、クラウド１３０のユーザーアカウントサービスに、通常動作中、そのような鍵を生成させることを避けることができる。クラウド１３０のユーザーアカウントサービスが、鍵の循環および／または複数のＳＣＭ１２０をサポートすることができるように、複数の鍵が利用されてもよい。この実施形態では、クラウド１３０のユーザーアカウントサービスは、どのUser-SCM-Key鍵が使用可能であるが使用中でないか、使用中であるか、廃棄されているかまたは撤去されているかを管理することができる。
一実施形態では、User-SCM-Key鍵が存在しなくてもよく、その場合、システムコンポーネントがユーザーアカウントサービスと通信し、および／またはユーザーアカウントサービスの真正性を検証するために他の手段が使用されてもよい。
一実施形態では、Device-SCM-IDと同様に、User-SCM-IDが使用されてもよい。
Ｆ．Cloud-SCM-KeyとCloud-SCM-Approval-Kev
Cloud-SCM-Key鍵は、ＳＣＭ１２０とクラウド１３０との間の特定のペアリング（つまりクラウド／ＳＣＭペア）を一意的に識別することができる。図示の実施形態におけるCloud-SCM-Keyは、クラウド１３０によって生成され格納される非対称の非公開／公開鍵のペアであってもよい。Cloud-SCM-Keyは、製造中などの工場リセットの後、最初のオーナーデバイス１１０がＳＣＭ１２０に対して確立されるとき、またはオーナーシップを移転するときに、生成されてもよい。
実質的に固有のCloud-SCM-Key鍵は、各クラウド／ＳＣＭのペアに対して使用されてもよい。この手法は、特定のクラウド１３０に関連付けられたすべてのＳＣＭ１２０とは違って、侵害されたCloud-SCM-Key鍵の露出を単一のＳＣＭ１２０に実質的に制限することができる。これは、特定のクラウド１３０に関連付けられたすべてのＳＣＭ１２０に対して（例えば、Cloud-Keyを用いて）単一の鍵が使用された場合のように、特定のクラウド１３０に関連付けられたすべてのＳＣＭ１２０への露出とは対照的である。
Cloud-SCM-Key非公開鍵は、クラウド１３０のセキュアメモリ２２０、またはセキュアエンクレーブまたはハードウェアセキュリティモジュール（ＨＳＭ）などのセキュアエレメントまたは同等のハードウェアモジュール内に安全に格納されてもよい。Cloud-SCM-Key非公開鍵は、他のシステムコンポーネントに送信されないかもしれない。Cloud-SCM-Key公開鍵は、クラウド１３０、デバイス１１０、またはＳＣＭ１２０のような、Cloud-SCM-Key公開鍵を利用するシステムコンポーネントに安全に送信され、格納されてもよい。Cloud-SCM-Key非公開鍵は、関連付けられたＳＣＭ１２０のためのメッセージを暗号化および／または署名するためにクラウド１３０によって使用されてもよいし、関連付けられたＳＣＭ１２０からクラウド１３０に送信されたメッセージを復号および／または検証するために使用されてもよい。Cloud-SCM-Key公開鍵は、クラウド１３０から発せられたメッセージを復号および／または検証するためにＳＣＭ１２０によって使用されてもよいし、ＳＣＭ１２０からクラウド１３０宛のメッセージを暗号化および／または署名するために使用されてもよい。メッセージは、ＳＣＭ１２０に直接送信されてもよいし、送信されなくてもよい。例えば、認可を発行するプロセス中に、署名されたＡＣＰ４００が、承認のためにオーナーデバイス１１０に送信されてもよい。承認後、クラウド１３０は、デバイス１１０を介してＳＣＭ１２０に配信される、完成したＡＣＰコンテナ４１０（以前に署名されたＡＣＰ４００を含む）に署名してもよい。
一実施形態では、クラウド１３０内の異なるサービスのための１つ以上のCloud-SCM-Key鍵のような複数のCloud-SCM-Key鍵が利用されてもよい。例えば、クラウド認可リクエストサービスのための１つのCloud-SCM-Key鍵と、クラウド認可承認サービスのための別ののCloud-SCM-Approval-Key鍵が、本明細書で以前に述べたように存在し得る。
一実施形態では、各クラウド１３０および／またはクラウドサービスに対してCloud-ID（Device-IDに類似）が存在してもよい。
一実施形態では、Cloud-Key鍵は、Cloud-SCM-Key鍵の代わりに、特定のクラウド１３０および／またはクラウドサービスにのみ固有のものであってもよい。この実施形態では、Cloud-Keyが、クラウド１３０のプロビジョニングおよび／または初期セットアップ中に生成されてもよい。
一実施形態では、Cloud-SCM-Key公開鍵は、Cloud-SCM-Key公開鍵を利用するシステムコンポーネントに安全に送信されず、および／または格納されないかもしれない。
Cloud-SCM-Key非公開鍵は、セキュアメモリ２２０またはセキュアエレメントまたは同等のハードウェアモジュールに格納されないかもしれない。ただし、Cloud-SCM-Key非公開鍵はそれでも安全に格納されえる。例えば、セキュアメモリ２２０を使用しないセキュアストレージは、Cloud-SCM-Key非公開鍵が静止時に暗号化されてもよい、そのようなデータに対するアクセスを防止するために、ソフトウェアベースの対処および／またはハードウェアベースの対処が実装されてもよい、および、ハードウェアおよび／または物理的な障害物またはシールドが実装されてもよい、とのいずれか１つ以上によって達成することができる。ＪＴＡＧおよび他のポートが無効化されてもよい。攻撃ベクトルを排除するために、強化されたソフトウェアインターフェースが実装されてもよい。信頼できる実行環境、ハードウェアまたはソフトウェアが制定され、オペレーティングシステムのルートアクセスまたはセキュリティ破壊の招来を検出するための検出システムが実装されてもよい。代替の実施形態では、Cloud-SCM-Key非公開鍵は安全に格納されない。
一実施形態では、鍵循環の結果として、Cloud-SCM-Key公開／非公開鍵が変更または生成され、またはその両方が行なわれてもよい。Cloud-SCM-Key公開／非公開鍵は、工場リセットの結果しては変更できない。
一実施形態では、１つ以上の証明書がCloud-SCM-Key鍵に使用されてもよい。あるいは、Cloud-SCM-Key鍵は対称鍵であってもよい。別の代替実施形態では、Cloud-SCM-Key鍵はＯＡｕｔｈ２トークンである。さらに別の代替実施形態では、代わりの認証鍵またはトークンタイプおよび／またはチャレンジ／レスポンスメカニズムがCloud-SCM-Key鍵の代わりに使用されてもよい。
一実施形態では、後で使用するために、特定のＳＣＭ１２０のために（またはグローバル鍵プールとしてのすべてのＳＣＭ１２０のために）、１つ以上のCloud-SCM-Key鍵が作成され、クラウド１３０に格納されてもよい。この手法は、クラウド１３０に、通常動作中、そのような鍵を生成させることを避けることができる。クラウド１３０が鍵の循環および／または複数のＳＣＭ１２０をサポートすることができるように、複数の鍵が利用されてもよい。この実施形態では、クラウド１３０は、どのCloud-SCM-Key鍵が使用可能であるが使用中でないか、使用中であるか、廃棄されているか、または撤去されているかを管理することができる。
一実施形態では、Cloud-SCM-Key鍵は存在しなくてもよく、この場合、システムコンポーネントがクラウド１３０と通信し、および／またはクラウド１３０の真正性を検証するために他の手段が使用されてもよい。
Ｇ．Root-Cert
Root-Certは、一実施形態によるシステム１００のルート証明書であってもよい。Root-Certは、システム１００の信頼のルーツを確立する自己署名証明書であってもよい。非公開Root-Certは、オフラインであるか、またはクラウド１３０または他のシステムコンポーネントにとって一般的にアクセスできないサーバー上に安全に格納することができる。公開Root-Certは、クラウド１３０、およびデバイス１１０またはＯＥＭクラウド１３５などのクラウド１３０と通信することができる各システムコンポーネントに配布されてもよい。
一実施形態では、Root-Certは、証明機関によって署名されてもよい。
一実施形態では、複数のRoot-Certが存在してもよい。例えば、システム１００、クラウド１３０、クラウドサービス、またはデバイス１１０、およびＯＥＭクラウド１３５、またはそれらの任意の組み合わせの異なる例に対するRoot-Certが存在してもよい。複数のRoot-Certの各々は、自己署名されてもよいし、証明機関によって署名されてもよい。一例では、システム１００は、オンライン検証のための１つの信頼ルートと、オフライン検証のためのもう１つとを有して構成されてもよい。
場合によっては、Root-Certをオフラインで格納することは厳密には必要ないので、一実施形態では、Root-Certがオンラインのサーバーに格納されてもよい。
Root-Certのコンテンツおよび／または作成プロセスは、アプリケーションごとに異なってもよい。一実施形態では、Root-Certは、非対称の公開／非公開鍵のペアであってもよいし、Root-Certが対称鍵であってもよい。
Ｈ．Cloud-Node-Cert
図示された実施形態におけるCloud-Node-Certは、対応するシステム１００の非公開Root-Certによって署名された証明書である。したがって、各Cloud-Node-Certは、特定のクラウドサーバー１３０のアイデンティティを検証するための、信頼のチェーンの一部を形成することができる。非公開Cloud-Node-Certは、各クラウドサーバー１３０に安全に格納されてもよい。公開Cloud-Node-Certは、クラウド１３０と、例えばデバイス１１０およびＯＥＭクラウド１３５を含むクラウド１３０と通信するかもしれない各システムコンポーネントとに配信されてもよい。いずれかの他の暗号化鍵が、暗号化鍵ではなく証明書として具体化される場合、これらの証明書は、Root-CertまたはCloud-Node-Cert、あるいは代替の信頼のルート証明書によって署名されてもよい。
一実施形態では、システム１００、クラウド１３０、クラウドサービス、デバイス１１０、またはＯＥＭクラウド１３５、もしくはそれらの任意の組み合わせの異なる例および／またはクラスタのためのレイヤのような、Cloud-Node-Certの複数のレイヤが存在してもよい。それぞれの子Cloud-Node-Cert（つまり、下位レベル）は、その親、つまり上位レベルの非公開Cloud-Node-Certによって署名されてもよく、それにより、より長い信頼のチェーンを形成することができる。
Cloud-Node-Certは、様々な方法で署名されることができる。例えば、Cloud-Node-Certは、一実施形態では自己署名されていてもよいし、または、Cloud-Node-Certは非親証明書または非対称の非公開／公開鍵によって署名されてもよい。
一実施形態では、Cloud-Node-Certは、非対称の公開／非公開鍵のペアである。あるいは、Cloud-Node-Certは対称鍵であってもよい。
Ｉ．Device-Rights-Key
Device-Rights-Key鍵は、クラウド１３０の権利管理システムに対する特定のデバイス１１０を一意的に識別することができる。Device-Rights-Key鍵は、デバイス１１０が最初にクラウド１３０に登録される前のある時点で、デバイス１１０によって生成され格納される非対称の非公開／公開鍵のペアであってもよい。Device-Rights-Key非公開鍵は、デバイス１１０内のセキュアメモリ２２０、またはセキュアエンクレーブまたはハードウェアセキュリティモジュール（ＨＳＭ）などのセキュアエレメントまたは同等のハードウェアモジュールに安全に格納することができる。Device-Rights-Key非公開鍵は、他のシステムコンポーネントには送信されないかもしれない。一方、Device-Rights-Key公開鍵は、クラウド１３０などのDevice-Rights-Key公開鍵を利用するシステムコンポーネントに安全に送信され、記憶されることができる。
Device-Rights-Key非公開鍵は、デバイス１１０がクラウド１３０の権利管理システムに送信するメッセージを暗号化および／または署名するためにデバイス１１０によって使用されることができ、および、クラウド１３０の権利管理システムからデバイスに送信されるメッセージを復号しおよび／または検証するために使用されることができる。Device-Rights-Key公開鍵は、特定のデバイス１１０から発信されるメッセージを復号および／または検証するためにクラウド１３０の権利管理システムによって使用されることができ、および、特定のデバイス１１０宛てのメッセージを暗号化および／または署名するために使用されることができる。
一実施形態では、Device-Rights-Key鍵は、デバイス１１０ごとに実質的に一意ではないかもしれない。そのような構成の例には、Device-Rights-Key鍵が、アカウントごとに実質的に一意である、アカウント内の一定の複数のデバイス１１０のために使用される、もしくは、すべてのデバイス１１０に対して全体的に同一またはクラウド１３０の特定の権利管理システムにのみ固有である、ことが含まれる。デバイスごとに実質的に一意ではないDevice-Rights-Key鍵の別の例は、特定の組織によって所有される、すべてのデバイス１１０のために使用されるDevice-Rights-Key鍵である。
一実施形態では、Device-Rights-Key鍵は、クラウド１３０によって生成され、デバイス１１０の登録プロセスの一部としてデバイス１１０に配信されてもよい。
一実施形態では、Device-Rights-ID（Device-IDに類似）が、クラウド１３０の権利管理システムと共に使用するために、各デバイス１１０に関連付けられてもよい。
一実施形態では、Device-Rights-Key公開鍵は、Device-Rights-Key公開鍵を利用するシステムコンポーネントに安全に送信されず、および／または格納されない。
Device-Rights-Key非公開鍵は、セキュアメモリ２２０またはセキュアエレメントまたは同等のハードウェアモジュールに格納されないかもしれない。ただし、それでもDevice-Rights-Key非公開鍵は安全に格納されることができる。例えば、セキュアメモリ２２０を使用しないセキュアストレージは、Device-Rights-Key非公開鍵が静止時に暗号化されてもよい、そのようなデータに対するアクセスを防止するために、ソフトウェアベースの対処および／またはハードウェアベースの対処が実装されてもよい、および、ハードウェアおよび／または物理的な障害物またはシールドが実装されてもよい、とのいずれか１つ以上によって達成することができる。ＪＴＡＧおよび他のポートが無効化されてもよい。攻撃ベクトルを排除するために、強化されたソフトウェアインターフェースが実装されてもよい。信頼できる実行環境、ハードウェアまたはソフトウェアが制定され、オペレーティングシステムのルートアクセスまたはセキュリティ破壊の招来を検出するための検出システムが実装されてもよい。代替の実施形態では、Device-Rights-Key非公開鍵は安全に格納されない。
一実施形態では、Device-Rights-Key公開／非公開鍵は、鍵循環の結果として、変更または生成され、またはその両方が行なわれてもよい。一実施形態のDevice-Rights-Key公開／非公開鍵は、工場リセットの結果として変更されないかもしれない。
一実施形態では、１つ以上の証明書がDevice-Rights-Key鍵のために使用されてもよい。あるいは、Device-Rights-Key鍵は、対称鍵であってもよい。別の代替実施形態では、Device-Rights-Key鍵はＯＡｕｔｈ２トークンであってもよい。さらに別の代替実施形態では、代わりの認証鍵またはトークンタイプおよび／またはチャレンジ／レスポンスメカニズムが、Device-Rights-Key鍵の代わりに使用されてもよい。
後で使用するために、１つ以上のDevice-Rights-Key鍵が作成され、デバイス１１０に格納されてもよい。この手法は、デバイス１１０が、通常動作中、そのような鍵を生成する能力を持たない場合に有用であり得る。一実施形態では、デバイス１１０が、鍵の循環および／または工場リセット後の異なる鍵をサポートすることができるように、複数の鍵が利用されてもよい。この実施形態では、デバイス１１０が、どのDevice-Rights-Key鍵が使用可能であるが使用中ではないか、使用中であるか、廃棄されているか、または撤去されているか、を管理することができる。あるいは、オンデマンド（１度に１つ）またはバッチで（本明細書に記載されるように後の時点での使用のために）など、Device-Rights-Key鍵がクラウド１３０（または別のシステムコンポーネント）によって生成され、通常の動作中に、デバイス１１０に格納されてもよい。
一実施形態では、Device-Rights-Key鍵は存在しなくてもよく、この場合、認可タイプまたは他の何らかの手段が、デバイスの権利を確立するために使用されてもよいし、または、デバイス１１０が、またはクラウド１３０の権利管理システムと通信および／または権利管理システムの真正性を検証できるように、他のなんらかの手段が使用されてもよい。
Ｊ．ACP-Version-Key
ACP-Version-Key鍵は、ＡＣＰコンテナバージョンパッケージ４１２（ＡＣＰバージョン情報を含むセキュアパッケージ）のコンテキスト内で使用されることができ、クラウド１３０とＳＣＭ１２０との間の特定のペアリング（または、クラウド／ＳＣＭペア）を一意的に識別することができる。図示された実施形態におけるACP-Version-Key鍵は、製造中など、工場リセット後に最初のオーナーデバイス１１０がＳＣＭ１２０に対して確立されるとき、またはオーナーシップを移転するときに、クラウド１３０によって生成され格納される非対称の非公開／公開鍵のペアである。図示された実施形態において、ACP-Version-Key鍵は、デバイス１１０に提供されないかもしれない。
潜在的に固有のACP-Version-Key鍵は、各クラウド／ＳＣＭペアに対して使用されてもよい。この手法は、特定のクラウド１３０に関連付けられたすべてのＳＣＭ１２０とは違って、侵害された各ACP-Version-Key鍵の露出を単一のＳＣＭ１２０に実質的に制限することができる。これは、特定のクラウド１３０に関連付けられたすべてのＳＣＭに対し、（例えば、１つのACP-Keyを用いて）単一の鍵が使用された場合のように、特定のクラウド１３０に関連付けられたすべてのＳＣＭ１２０への露出とは対照的である。
ACP-Version-Key非公開鍵は、クラウド１３０のセキュアメモリ２２０、セキュアエンクレーブまたはハードウェアセキュリティモジュール（ＨＳＭ）などのセキュアエレメントまたは同等のハードウェアモジュール内に安全に格納されてもよい。ACP-Version-Key非公開鍵は、他のシステムコンポーネントに送信されないかもしれない。一方、ACP-Version-Key公開鍵は、ＳＣＭ１２０などの、ACP-Version-Key公開鍵を利用するシステムコンポーネントに安全に送信され、格納されてもよい。ACP-Version-Key非公開鍵は、関連付けられたＳＣＭ１２０のためのメッセージを暗号化および／または署名するためにクラウド１３０によって使用されてもよいし、関連付けられたＳＣＭ１２０からクラウド１３０に送信されたメッセージを復号および／または検証するために使用されてもよい。ACP-Version-Key公開鍵は、クラウドから発せられたメッセージを復号および／または検証するためにＳＣＭ１２０によって使用されてもよいし、ＳＣＭ１２０からクラウド１３０宛のメッセージを暗号化および／または署名するために使用されてもよい。
一実施形態では、Cloud-SCM-Key鍵がACP-Version-Key鍵に使用されてもよい。
一実施形態では、ACP-Version-Key非公開鍵は、SCM-Keyと同様の方法で生成および管理されてもよい。例えば、ACP-Version-Key非公開鍵は、ＳＣＭ１２０上に存在してもよく、公開鍵は、クラウド１３０内に存在してもよい。
代替の実施形態では、特定のクラウド１３０にのみ固有のACP-Key鍵が、ACP-Version-Key鍵の代わりに実装されてもよい。
一実施形態では、ACP-Version-Key公開鍵は、ACP-Version-Key公開鍵を利用するシステムコンポーネントに安全に送信されず、および／または格納されないかもしれない。
一実施形態では、ACP-Version-Key非公開鍵は、セキュアメモリ２２０またはセキュアエレメントまたは同等のハードウェアモジュールに格納されないかもしれない。しかし、ACP-Version-Key非公開鍵は、それでも安全に格納されることができる。例えば、セキュアメモリ２２０を使用しないセキュアストレージは、ACP-Version-Key非公開鍵が静止時に暗号化されてもよい、そのようなデータに対するアクセスを防止するために、ソフトウェアベースの対処および／またはハードウェアベースの対処が実装されてもよい、および、ハードウェアおよび／または物理的な障害物またはシールドが実装されてもよい、とのいずれか１つ以上によって達成することができる。ＪＴＡＧおよび他のポートが無効化されてもよい。攻撃ベクトルを排除するために、強化されたソフトウェアインターフェースが実装されてもよい。信頼できる実行環境、ハードウェアまたはソフトウェアが制定され、オペレーティングシステムのルートアクセスまたはセキュリティ破壊の招来を検出するための検出システムが実装されてもよい。代替の実施形態では、ACP-Version-Key非公開鍵は安全に格納されない。
一実施形態では、ACP-Version-Key公開／非公開鍵は、鍵の循環の結果として、変更または生成され、またはその両方が行われてもよい。
一実施形態では、ACP-Version-Key公開／非公開鍵は、工場リセットの結果として、変更されないかもしれない。
１つ以上の証明書が、ACP-Version-Key鍵に使用されてもよい。あるいは、ACP-Version-Key鍵は、対称鍵であってもよい。別の代替実施形態では、ACP-Version-Key鍵はＯＡｕｔｈ２トークンであってもよい。さらに別の代替実施形態では、代わりの認証鍵またはトークンタイプおよび／またはチャレンジ／レスポンスメカニズムが、ACP-Version-Key鍵の代わりに使用されてもよい。
一実施形態では、後で使用するため、特定のＳＣＭ１２０のために（またはグローバル鍵プールとしてのすべてのＳＣＭ１２０のために）、１つ以上のACP-Version-Key鍵が作成され、クラウド１３０に格納されてもよい。この手法は、クラウド１３０に、通常動作中、このような鍵を生成させることを回避することができる。クラウド１３０が鍵の循環および／または複数のＳＣＭ１２０をサポートすることができるように、複数の鍵が利用されてもよい。この実施形態では、クラウド１３０は、どのACP-Version-Key鍵が使用可能であるが使用中でないか、使用中であるか、または廃棄されているかまたは撤去されているか、を管理することができる。
一実施形態では、ACP-Version-Key鍵は存在しなくてもよく、この場合、システムコンポーネントがＡＣＰコンテナバージョンパッケージ４１２と通信し、および／またはＡＣＰコンテナバージョンパッケージ４１２の真正性を検証するために、他の手段が使用されてもよい。一実施形態では、システムコンポーネントは、ＡＣＰコンテナバージョンパッケージ４１２のすべてで真正性を検証しなくてもよい。
一実施形態では、複数のACP-Version-Key鍵が存在してもよい。例えば、各ＳＣＭ１２０が２つ以上のＡＣＰ４００を記憶し使用することができるシステムであり、したがって、それは、所定のＳＣＭが複数のＡＣＰコンテナ４１０および／または複数のＡＣＰコンテナバージョンパッケージ４１２および／または複数のACP-Version-Key鍵を使用する複数のＡＣＰコンテナコレクション４１４を受信することが必要と考えられてもよい。
Ｋ．Device-SCM-Sessuion-Key
Device-SCM-Sessuion-Key鍵は、ＴＬＳマスターシークレットと類似した方法で認証されるように、少なくとも１つのペアが認証された後に、特定のデバイス１１０とＳＣＭ１２０との間に定義されるペアリング（または、デバイス／ＳＣＭペア）間での通信を保護するために使用される対象鍵であってもよい。システム性能および制約のあるシステムコンポーネントとの応答性を向上させるために、Device-SCM-Session-Key鍵は（ＴＬＳセッションの続行と同様の方法でなど）接続を継続してもよいし、本明細書で説明するように定期的に循環されてもよい。
デバイス／ＳＣＭペア内のデバイスのDevice-SCM-EDは、接続を確立および／または再開するときに、適切なDevice-SCM-Session-Key鍵を特定および／または選択するために使用されてもよい。
一実施形態では、Device-SCM-Session-ID（Device-SCM-EDに類似）が各デバイス／ＳＣＭペアに提供され、接続を確立および／または再開するときに、適切なDevice-SCM-Session-Key鍵を特定および／または選択するために使用されてもよい。これは、ＴＬＳセッションＩＤまたはセッションチケットと同様の方法で行われることができる。
一実施形態では、Device-SCM-Session-Key鍵は非対称鍵のペアである。あるいは、Device-SCM-Session-Key鍵は、ＯＡｕｔｈ２トークンであってもよい。別の代替の実施形態では、代わりの認証鍵またはトークンタイプおよび／またはチャレンジ／レスポンスメカニズムが、Device-SCM-Session-Key鍵の代わりに使用されてもよい。
一実施形態では、Device-SCM-Session-Key鍵は存在しなくてもよく、この場合、デバイス１１０とＳＣＭ１２０が安全に通信するために他の手段が使用されてもよいし、および／または、デバイス１１０とＳＣＭ１２０が安全に通信しなくてもよい。
Ｌ．セッショントークン
クラウド１３０および／またはＯＥＭクラウド１３５と通信するシステムコンポーネント（デバイス１１０など）は、追加のセキュリティ対策として使用するために、ＯＥＭクラウドログインプロセスの間にＯＥＭクラウドセッショントークンおよび／またはクラウドセッショントークンを取得してもよい。ＯＥＭクラウドセッショントークンは、すべてのＯＥＭクラウド１３５メッセージに加えて、ＯＥＭクラウド１３５によって管理される他のデータアイテムへの任意の内部マッピングに付随してもよい。クラウドセッショントークンは、特定のCloud-User-EDおよびOEM-EDにマッピングすることができ、クラウド１３０が特定のCloud-User-EDおよびOEM-EDに関連付けられたデータへのアクセスを制限することができる、すべてのクラウド１３０メッセージに付随してもよい。ＯＥＭクラウド１３５は、Cloud-to-OEMクラウドセッショントークンを使用して、クラウド１３０と通信することができる。Cloud-to-OEMクラウドセッショントークンは、Cloud-to-OEMクラウドセッショントークンが、特定のOEM-IDと関連付けられたデータへのアクセスのみを制限することができることを除いて、クラウドセッショントークンと同様であってもよい。
クラウド１３０とＯＥＭクラウド１３５は、トークンの有効期限が切れるように、セッショントークンを周期的に循環させてもよい。さまざまな状況下で、またはログインごとなどのイベントに応じて、または疑わしいアクティビティが発生したときやメッセージの検証が失敗したとき、循環が生じてもよい。
ＯＥＭクラウドセッショントークンとクラウドセッショントークンは、一実施形態では同じであってもよい。あるいは、ＯＥＭクラウドセッショントークンは使用されないかもしれない。代替の実施形態では、クラウドセッショントークンが使用されないかもしれない。追加的に、または代替的に、Cloud-to-OEMクラウドセッショントークンは使用されないかもしれない。
Ｍ．その他の鍵
１つの目的専用であるおよび／または一時的である、他の鍵がシステム１００内に存在してもよい。専用の目的の例は、特定のメッセージセット内で、または特定のシステムコンポーネントに対して内部的に利用される鍵である。一時的である例には、ＴＬＳやＤＴＬＳなどの標準セキュリティプロトコルのコンテキスト内で動作する他のシステムコンポーネント間で利用されるセッション鍵が含まれる。
Ｎ．ユーザー
一実施形態では、ユーザー１０は、システムにおいて、暗号鍵と同様の役割を果たしてもよい。ユーザー１０は、認証（または２因子または多因子認証）メカニズムのために使用される、またはシステム１００内のシステムコンポーネントによる承認ゲートに関連して使用される、暗号鍵として組み込むことができる以下の潜在的に固有の特性／特徴を有する。
１）目および／または顔（例えば、網膜／フェイシャルキー／サイン、レシートの視覚的確認）
２）指紋（例えば、フィンガープリントキー／署名、Apple Touch IDなどの確証情報）
３）電子メールアクセス（例えば、電子メールアカウントへの実証されたアクセス）
４）ＳＭＳアクセス（例えば、ＳＭＳメッセージへの実証されたアクセス）
５）プッシュ通知アクセス（例えば、プッシュ通知への実証されたアクセス）
６）画面アクセスまたはコード入力（例えば、デバイス画面への実証されたアクセス）
７）近接性（例えば、微小位置に基づく近接性、またはＩＲ検出に基づく近接性などのシステムコンポーネントへの近接性）
８）アクセス（例えば、ボタンプッシュなどのシステムコンポーネントへの実証された物理的アクセス）
９）他のデバイス（例えば、時計またはバンドなどの他のユーザーデバイス）への近接性またはアクセス
ＸＩＩＩ．鍵の循環
一実施形態による、鍵の回転または鍵の更新としても知られている鍵の循環は、変更をユーザーに直接通知することなく、またはユーザーとのやり取りを必要とすることなく、既存の対象物に対して鍵が変更されるプロセスである。例えば、認可、デバイス１１０、ＳＣＭ１２０、クラウド１３０、機器コンポーネント１３０、およびＯＥＭクラウド１３５を含む、対象物に対する鍵が変更されることができる。
鍵は、数時間毎、毎日、毎週、毎月、６ヶ月毎、または毎年、もしくは侵害または異常が検出されたときなど、周期的に循環させることができる。変更は、自動的に、または管理アクションまたは操作アクションを通じてなど手動で行われてもよい。
鍵の循環を適切にサポートすることは、システム１００のための集中的な作業であってもよい。オフラインであるかもしれないシステムコンポーネントには１つの問題があり、鍵の変更要求が、まだ別の鍵の変更要求の前に、ターゲットとするシステムコンポーネントに配信されないかもしれない。例えば、連続的な鍵の循環処理は、鍵の変更の配信不能または配信遅延を招く可能性がある。鍵（例えば、ＡＣＰ４００）に依存する設定変更も、システムコンポーネントがオフラインであることにより、配信不能または配信遅延との結果を招くかもしれない。多くのシステムコンポーネントにとって、鍵の変更は迅速に配信されるので、これは起こりそうもない。しかし、ＳＣＭ１２０が数日、数ヶ月、または数年間使用されないままである可能性があり、したがって、いくつかの鍵の循環イベントが見逃される可能性があり、その後、以前のオーナーは、システム１００を使用する新しいオーナーにＳＣＭ１２０を移譲することができなくなってしまう可能性がある。より具体的には、この場合、ＳＣＭ１２０は、更新されたＡＣＰ４００または更新されたＡＣＰコンテナ４１０を復号することができず、および／または循環されたデバイス１１０を認証することができない。この場合、ＳＣＭ１２０を工場リセットすることは許容され得るかもしれない。別のシナリオでは、数時間にわたって、ＳＣＭ１２０を（オーナーまたはゲストによって）使用不能にする複数の鍵の循環イベントが発生した場合、ユーザーエクスペリエンスまたはユーザビリティの観点からは許容されない可能性がある。
複数の鍵に影響を及ぼす鍵の循環イベントもありえる。複数の鍵は、複数のＳＣＭ１２０を管理するデバイス１１０、または、複数の認証されたアカウントおよび／またはデバイス１１０を有するＳＣＭ１２０において、システム全体の鍵の循環など、様々な状況下で影響を受ける可能性がある。シーケンスの例が以下に示される。
一実施形態によるキーを循環させる方法が、図１２に示され、全体的に１２００で指定される。クラウド１３０は、デバイス１１０に、新しいCloud-SCM-Key鍵および他のクラウド生成鍵（例えば、User-SCM-Key）および／またはクラウドと通信するために必要とされる鍵（トークンなど）を提供して、所定のＳＣＭ１２０に対する鍵を循環させるように要求する（ステップ１２０１）。デバイス１１０は、新しいDevice-SCM-Key鍵を生成し、それを鍵の循環要求に応答してクラウド１３０に送信する（ステップ１２０２）。
クラウド１３０が、ＳＣＭ１２０と関連付けられたすべてのデバイス１１０から更新されたDevice-SCM-Key（および、必要とされる任意の他の入力鍵）を受信した後のある時点で、クラウド１３０は、ＳＣＭ１２０へ配信するために（例えば、ＡＣＰコンテナ４１０を介して）、更新されたＡＣＰ４００（「バージョン２」）をデバイス１１０に送信する（ステップ１２０３）。デバイス１１０は、更新されたＡＣＰ４００をＳＣＭ１２０に配信し、それは、必要な全ての更新された鍵を含む（ステップ１２０４）。ＳＣＭ１２０は、ＡＣＰ４００の更新が成功したことをデバイス１１０に通知する（ステップ１２０５）。デバイス１１０は、ＳＣＭ１２０が「バージョン２」のＡＣＰ４００を適用したことをクラウド１３０に通知する。これにより、クラウド１３０は、各ＳＣＭ１２０のＡＣＰ４００の適切なバージョンに対して適切な鍵のセットを維持することができ、その結果、ＳＣＭ１２０またはデバイス１１０（または他のシステムコンポーネント）が鍵の更新をし損なった場合、リカバリのため、以前の更新が順番通りに配信されることができ、または最新の更新が以前の鍵を使用して配信されることができる（ステップ１２０６）。
ステップ１２０７−１２１１は、第２の鍵循環イベントを示す。ある時点で、クラウド１３０は、ＳＣＭ１２０用のクラウド生成鍵の１つを循環させ、ＳＣＭ１２０へ配信するために（例えば、ＡＣＰコンテナ４１０を介して）、更新されたＡＣＰ４００（「バージョン３」）をデバイス１１０に配信する（ステップ１２０７、１２０８）。ステップ１２０９−１２１１は、ステップ１２０４−１２０６と同様であり、ＳＣＭ１２０が「バージョン３」のＡＣＰ４００を適用したことをクラウド１３０が通知されることになる。
ＳＣＭ１２０における鍵を循環させるために、「新しい鍵」と「古い鍵」（既知の鍵）の両方が、ターゲットＳＣＭ１２０のためのＡＣＰ４００に含有されえる。ＡＣＰ４００がＳＣＭ１２０によって受理されるたびに、受領確認が、デバイス１１０などのオンラインシステムコンポーネントを介して、ある時点でクラウド１３０に返送されることができる。特定のＳＣＭ１２０が最後にどのＡＣＰバージョンを受理したかを追跡することによって、クラウド１３０は、送信中のＡＣＰ４００がＳＣＭ１２０によって受理されるまで、「古い鍵」のフィールドが送信中の（以前の／不受理の）ＡＣＰ４００とは異なる、鍵の変更を含む、そのＳＣＭ１２０に対する後続のＡＣＰコンテナ４１０の生成を防止することができる。
代替の実施形態では、どのＡＣＰ４００がＳＣＭ１２０によって受理されたかにかかわらず、クラウド１３０は、そのＳＣＭ１２０に対して通常通りの後続のＡＣＰコンテナ４１０を送信してもよい。この実施形態では、ＡＣＰコンテナバージョンパッケージ４１２、ＡＣＰコンテナ４１０、ＡＣＰ４００、および／またはクラウドＡＰＩレスポンスに最小限の先行バージョンが追加されてもよい。
ＳＣＭ１２０が、その現在のＡＣＰバージョンが最小限の先行バージョン（すなわち、ＳＣＭ１２０の現行の鍵のセットが有効であった最後のバージョン）以上でないことを検出した場合、ＳＣＭ１２０、ＡＣＰの更新を拒絶し、最小限の先行バージョンを要求してもよい。これは、より古いＡＣＰコンテナ４１０の連続した後戻りという結果となり、その後、更新されたパッケージが順番通りに送信されるか、または送信システムコンポーネント（例えば、デバイス１１０）によって実行されることになる。ＡＣＰ更新の拒絶は、クラウド１３０が、各ＳＣＭ１２０に対して、または少なくとも最新のＡＣＰを受信していないＳＣＭ１２０に対して、以前に確定されたＡＣＰコンテナ４１０のコピーを維持することを伴い得る。
追加的にまたは代替的に、最小限先行バージョンは、クラウドＡＰＩへの応答を介して受信システムコンポーネントにだけ通信されてもよく、その後、受信システムコンポーネントは適切なＡＣＰコンテナ４１０を要求することができる。追加的にまたは代替的に、クラウド１３０は、実行可能なＡＣＰコンテナ４１０のみをＳＣＭ１２０に順番に提供してもよい。すなわち、クラウドはいかなる順番の並べかえを行わなくてもよい。
一実施形態では、送信中のＡＣＰ４００が特定のＳＣＭ１２０によってまだ受理されていない場合、クラウド１３０は、送信中のＡＣＰ４００を受け入れるまで、そのＳＣＭに対する後続のＡＣＰコンテナ４１０を送信しなくてもよい。
一実施形態では、送信中のＡＣＰ４００が特定のＳＣＭ１２０によってまだ受理されていない場合、クラウド１３０は、送信中の鍵の変更を新しいＡＣＰバージョンに併合してもよい。言い換えれば、クラウド１３０は、各システムコンポーネントのための１つ以上の以前の鍵を維持し、そして、ターゲットＳＣＭ１２０の最後の既知の状態に基づいて適切な鍵を使用してもよい。
図示された実施形態では、ＡＣＰコンテナ４１０は特定のＳＣＭ１２０を対象とし、１つ以上のシステムコンポーネントまたはサービスによって署名されているので、SCM-KeyおよびCloud-SCM-Keyなど、ＡＣＰ４００内に含まれるもの以外の鍵、並びに識別子を含む他の非鍵属性も同時に更新されてもよい。
循環される鍵のみを含むＡＣＰコンテナ４１０に関して、認可がアカウントに発行されない（例えば、代わりに認可は特定のデバイス１１０に発行される）一実施形態では、オーナー１０は、更新されたＡＣＰを承認することは必要とされないかもしれず、従って、オーナーデバイス１１０は、ＡＣＰ外層２を暗号化して署名しないかもしれない。代わりに、オーナーデバイス識別子が、そのオーナーデバイス識別子は鍵循環ＡＣＰ４００であることを示す値に設定され、次いで、ＡＣＰ外層２が、別の層（例えば、ＡＣＰ外層１またはＡＣＰ外層３）によって使用される鍵を用いて暗号化されてもよい。追加的にまたは代替的に、鍵循環ＡＣＰ４００は、暗号化されなくてもよく、この場合、署名および鍵フィールドはさらなる検証に使用されてもよい。
循環される鍵のみを含むＡＣＰコンテナ４１０に関して、認可がアカウントに発行される一実施形態において、オーナー１０は、更新されたＡＣＰ４００を承認する必要はないかもしれないが、ユーザーアカウントサービスは、以前として、通常通りにＡＣＰ外層２を暗号化し、署名することができる。
ＡＣＰ４００は、パッケージが正当であることをさらに検証するように設定され得る鍵循環属性を有することができる。正当性は、ＡＣＰ外層２の暗号化、もしくはその欠如が意図的であったことを示してもよい。ＡＣＰコンテナ４１０の検証の間、ＳＣＭ１２０は、ＳＣＭ１２０の現行の鍵（すなわち、ＳＣＭ１２０によって受信された、以前のＡＣＰ４００において特定された鍵）が、新しいＡＣＰ内の「古い鍵」と一致することを検証することができる。いずれかの鍵が一致しない場合、ＡＣＰ４００は拒絶され得る。
代替の実施形態では、鍵循環ＡＣＰ４００について、ＳＣＭ１２０は、（認可に関連する鍵を除いて）認可が更新されていないことを検証してもよい。別の代替の実施形態では、鍵循環ＡＣＰ４００について、鍵だけが更新されてもよい。
代替の実施形態では、オーナーデバイス１１０は、ユーザーの介入有りで、または無しで、鍵変更ＡＣＰ４００を承認し、可能であれば署名するように構成されてもよい。オーナーデバイス１１０は、この状況で自動的にＡＣＰ４００を署名するだけでもよい。代替の実施形態では、オーナーデバイスは、ユーザーの介入有りで、鍵変更ＡＣＰ４００を承認し、可能であれば署名するように構成されてもよい。ユーザー１０は、ＡＣＰ４００がいずれかの他の認可変更であるかのように、ＡＣＰ４００を承認することを要求されるかもしれない。
鍵を循環するとき、システムコンポーネントは、見逃した鍵循環ＡＣＰ４００の対応を支援するために、しばらくの間、零またはそれ以上の先行鍵を保持してもよい。システムコンポーネントは、より最近の鍵が失敗した場合、以前の鍵の使用を試みてもよい。システムコンポーネントは、最も最近の鍵を使用する、新たな鍵のない、別の設定が到着する後まで、またはある時間が経過するまでなど、そうすることがもはや必要ではないと判定される時点まで、先行鍵を存続させてもよい。
一実施形態では、鍵が循環されたとき、鍵を利用するエンティティへの接続が再確立されるか、または少なくとも再検証されてもよい。このような接続の例には、デバイス／ＳＣＭペア、クラウド／デバイスペア、および機器／ＳＣＭペアが含まれる。鍵の循環は、実装が不適切なためにユーザーエクスペリエンスが減少された場合、ある点では厄介であるかもしれないが、鍵の循環は安全対策と見なすことができ、厄介であることを意味するものではない。一実施形態では、ハッキングされたデバイスを使用しての侵害を防止するために、鍵が循環され、それにより、再接続を強制させるべくＳＭＣ１２０などのシステムコンポーネントを切断させるために使用される場合がありえる。ハッキングされたデバイスの場合、再接続の試みはおそらく失敗する。
代替の実施形態では、ＳＣＭ１２０に対する鍵の変更は、ＡＣＰコンテナ４１０内でそれらがどのように配信されるかと同様に配信されてもよいが、代わりに、各ＳＣＭ１２０についてクラウド１３０によって追跡される別個のＫＣＰバージョンを有する、または有さない、鍵変更パッケージ（ＫＣＰ）のような別個のパッケージ内で配信されてもよい。そのような手法が使用され、ＫＣＰバージョンが使用されない場合、ＫＣＰバージョンは、ＡＣＰバージョンと併合されてもよい。
一実施形態では、ＳＣＭは、鍵の循環を利用することができる唯一のシステムコンポーネントではない。デバイス１１０、クラウドサーバー１３０、機器コンポーネント１４０、ＯＥＭクラウド１３５、およびその他（もしあれば）も、侵害に応じて、鍵が更新されるように構成することができる。
鍵循環要求は、クラウド１３０から発することができ、したがって、各システムコンポーネントは、鍵を循環させる要求が真正であることを検証してもよい。本明細書で説明されるように、各システムコンポーネントは、多数の鍵を所有することができる。多数の鍵の零またはそれ以上は、そのシステムコンポーネントによって生成され、多数の鍵の零またはそれ以上は、他のシステムコンポーネントから取得されることができる。各システムコンポーネントは、それらの鍵のうちの少なくとも１つを生成することができるので、鍵循環処理は、複数のシステムコンポーネントの協力、協調、および順序付けを伴ってもよい。
ＳＣＭ１２０は、それ自体の鍵を生成しないかもしれしれず、したがって、ＳＣＭ１２０は、鍵を循環することを要求されないかもしれない。この場合、ＳＣＭ１２０は鍵循環プロセスの受信者となる。ＳＣＭ１２０によって生成されない鍵は、SCM-KeyおよびSCM-Equipment-Keyのうちの少なくとも１つを含む。
ＳＣＭがそれ自体の鍵を生成しない場合、鍵がクラウド１３０のコントロール下にないとき、クラウド１３０は、その特定の鍵が循環されるように要求を発行してもよい。例えば、クラウド１３０は、デバイス１１０に特定のＳＣＭ１２０のための新しいDevice-SCM-Keyを生成する要求を発行することができる。設定された場合、（要求されたデバイス１１０からのものであることが認証された）更新された鍵が、ＡＣＰ４００に含まれて、そのデバイス１１０または特定のＳＣＭ１２０に関連付けられた複数のデバイス１１０に配信されえる。そのデバイスまたは複数のデバイス１１０は、ＡＣＰ４００をＳＣＭ１２０に配信することができる。
代替の実施形態では、ＳＣＭ１２０は、それ自体の鍵を生成してもよく、したがって、ＳＣＭ１２０は、鍵を循環させるように要求されてもよい。代替の実施形態では、システムコンポーネントは、特定のキーを循環させるか、または鍵循環を開始し、配信のために新しい鍵をクラウド１３０に発行してもよい。
代替の実施形態では、更新された鍵をＡＣＰコンテナ４１０を介してＳＣＭ１２０に配信する代わりに、（クラウド１３０から個別にまたはまとめて取得される）個々の鍵循環要求がＳＣＭ１２０に発行されてもよく、その状況がクラウド１３０に報告されてもよい。この実施形態の１つの構成では、すべての要求が処理されたときにのみ、鍵循環処理が完了したとみなされる。
別の代替実施形態では、システム１００は、鍵の循環を直接的にサポートしなくてもよく、代わりに、認可を削除して再発行する、ＳＣＭ１２０を工場リセットする、デバイス１１０を工場リセットし、および／またはアプリケーションを消去または再インストールする、および新しいクラウドサーバーをスタートさせる、との１つ以上を行うように、システム１００内の処理を利用してもよい。
ＸＩＶ．安全な接続の確立
図１４の図示された実施形態において、デバイス／ＳＣＭ通信チャネルは、ユーザエクスペリエンス（応答性）を向上させるとともに、ＳＣＭ１２０によって今までに見られなかったデバイス１１０との通信を可能にするために、段階的なゆっくりした認証プロセスまたは方法、もしくはその両方を採用することができる。安全な接続プロセスは、どの通信リンクで発生してもよいが、ブルーツゥースローエナジー（ＢＬＥ）通信リンクなどの制約付きハードウェア間の比較的低速で安全ではない無線通信リンク用に構成されえる。
図示の実施形態では、安全な接続確立プロセスまたは方法１４００は、３つの異なるフェーズを含むことができる。（１）未知−ステップ１４０１。（２）安全−ステップ１４０２。（３）信頼−ステップ１４０３。結果として生じる安全な接続は、基礎をなす通信層が安全であるか安全でないかにかかわらず、基礎をなす通信リンクがどんなものであっても利用されることができる。この基礎をなす通信リンクは、事前未知の通信リンクとして説明されえる。事前未知の通信リンクが安全であることが分かっている（例えば、ＴＬＳまたはＤＴＬＳセッションが既に確立されている）ことが分かっている状況では、代替の実施形態は、冗長なフェーズ（例えば、未知および／または安全）を取り除いてもよい。方法１４００は、いくつかの点で、ＴＬＳ／ＤＴＬＳ接続確立プロセスと同様でありえる。
Ａ．事前未知の通信リンク
事前未知の通信リンク初期化および接続シーケンスは、システム構成および基礎をなす物理媒体およびプロトコルスタック（例えば、Ethernet-IP-TCP、Ethernet-IP-UDP、Ethernet-IP-TCP-TLS、BLE、802.15.4-IPv6 [6L0WPAN]など）に基づいて変化しえる。そのため、実際のメッセージングコンテンツ、パケット化／フレーム化、送受信接続／被接続プロトコルのシーケンス／処理は、基礎となる技術の相違によって多少異なる場合がある。また、基礎となる技術の違いにより、１つ以上のプロトコルステップを単一のステップにまとめることも可能である（逆に、非常に小さいパケット／メッセージ制限を克服するために、単一のステップを多くの小さなステップに分割することが有用であり、または必要かもしれない）。しかし、上位レベルのプロトコルステップは同じままとすることができる。図示の実施形態では、接続確立プロセスは、ブルーツゥースローエナジー（ＢＬＥ）で行われるが、本開示はこれに限定されないことを理解されたい。
ＳＣＭ１２０およびデバイス１１０が未知のフェーズ−ステップ１４０１のスタートに達するまでに、事前未知の通信リンクをセットアップするためにかなりの労力が費やされた可能性がある。この１つのそのような例は、２０１５年２月１２に出願され、「車両と通信するためのシステムおよび方法」と題する、J. Michael Ellisらの米国特許出願第１４／６２０９５９、および２０１７年４月１４日に出願され、「リアルタイムロケーションを確立するためのシステムおよび方法」と題する、Raymond Michael Stittの米国特許出願第１５／４８８１３６号に記載されたシステムと組み合わせた本実施形態の適用である。それらの開示は、ＢＬＥを使用したマイクロロケーションシステムを含む、その全体が参照により本明細書に組み込まれる。このシステムによる方法が、図１３の図示された実施形態に示され、１３００で指定される。方法１３００は、マスタデバイス（ＳＣＭ１２０）が周辺としてスタートし、ポータブルデバイス（デバイス１１０）が中央としてスタートする（初期接続）接続戦略を使用することができる（ステップ１３０１）。互いに通信することに同意した後、役割が切り換えられ、そこでは、マイクロロケーティング接続の一部として、マスタデバイス１１０が中央になり、ポータブルデバイス１１０が周辺となる（ステップ１３０２）。
本明細書に記載されたセキュリティモデル／システムが、本明細書に記載されたシステム、および／または、２０１５年２月１２に出願され、「車両と通信するためのシステムおよび方法」と題する、J. Michael Ellisらの米国特許出願第１４／６２０９５９、および２０１７年４月１４日に出願され、「リアルタイムロケーションを確立するためのシステムおよび方法」と題する、Raymond Michael Stittの米国特許出願第１５／４８８１３６号に記載されたシステムと組み合わされて適用されえる実施形態において、それらの開示が、それらの全体において参照により本明細書に組み込まれる。
・ 事前未知の通信リンク−初期接続
事前未知の通信リンクが、方法１３００に関連して、初期接続とすることができる。言い換えれば、デバイス１１０とＳＣＭ１２０は、まだ役割を交換しておらず、そのため、方法１３００に関して本明細書で説明されるシーケンスにおける最初のやり取りは、デバイス１１０からＳＣＭ１２０へ対するものとなる。
この実施形態において、安全な接続確立プロセスは、初期接続のコンテキスト内で安全のフェーズまたは信頼のフェーズのいずれかを通じて完了することができる。プロセスは、未知のフェーズまたは安全のフェーズの間に相互認証が実行されるかどうかに応じて、安全のフェーズまたは信頼のフェーズを通じて完了することができる。
このプロセス中に確立されたDevice-SCM-Session-Keyなどのセッション鍵は、マイクロロケーション接続への切り替え（すなわち役割反転）に先立ち、検証および／または認証されてもよい。いずれにしても、安全な通信チャネルを確立するために、セッションキーがマイクロロケーション接続内で使用されることができる（マイクロロケーション接続へハンドオーバされる）。フェーズ格下げが利用される場合、マイクロロケーション接続が引き続き使用されてもよい。フェーズ格下げは、切断／再接続、セッション鍵循環、または認証失敗によるなどのさまざまな状況で利用されえる。
この手法は、ＳＣＭ１２０が、役割反転の境目で、デバイス接続を代わりのシステムコンポーネント（例えば、ＳＣＭ１２０または類似のモジュール）にきちんと配信することを可能にすることができる。
２．事前未知の通信リンク−マイクロロケーション接続
一実施形態では、事前未知通信リンクは、マイクロロケーション接続であってもよい。言い換えれば、デバイス１１０とＳＣＭ１２０はすでに役割を交換している可能性があり、従って、方法１４００に関して説明したシーケンスにおける最初の交換は、ＳＣＭ１２０からデバイス１１０へと、逆になる。
これは代替の実施形態であり、その場合、ステップ１４０１における未知の接続確立フェーズは、方法１３００における初期接続中に完了されない可能性がある。すなわち、接続確立プロセス１４００の全体が、方法１３００のステップ１３２０で確立されるマイクロロケーション接続のコンテキスト内で完了されてもよい。
３.事前未知の通信リンクを確立
図１４の図示の実施形態では、マイクロロケーションシステムにおける初期接続の始まりは、デバイス１１０が特定のＳＣＭ１２０に接続することを決定した時点である。例を挙げると、ＳＣＭ１２０は、ａ）デバイス１１０は通信するように構成されている、ｂ）デバイス１１０はＳＣＭ１２０のオーナーになりたい、またはｃ）デバイス１１０はＳＣＭ１２０と接続する詮索好きな（または、悪意のある）デバイスである、とデバイス１１０が信じるシステムコンポーネントとして認識されるので、デバイス１１０はＳＣＭ１２０に接続することを決定することができる。
デバイス１１０は、ＳＣＭ１２０が工場リセットモードにあるかどうかを判断するなど、ＳＣＭ１２０に問い合わせるため、更新されたＡＣＰを送信するため、または他の設定を判定するために、方法１３００に従ってステップ１３０１で確立された初期接続を使用することができる。デバイス１１０および／またはＳＣＭ１２０が、セッション鍵（Device-SCM-Session-Key）が確立される、安全な接続確立プロセスの部分を開始するとき、デバイス１１０は、ステップ１３０２に従ってマイクロロケーション接続へ切り替えることによって、役割反転を実行することができる（ステップ１４０２）。安全な接続確立ステップは、デバイス１１０が、そのデバイス１１０のDevice-SCM-EDを共有した後に行われてもよく、したがって、ＳＣＭ１２０は、安全ではない可能性があるにもかかわらず、
デバイス１１０が、そのＳＣＭ１２０が接続すべきデバイス１１０であることのいくつかの証拠を有する。
この手法では、デバイス１１０は、ＳＣＭ１２０を認証することができず、および／または、ＳＣＭ１２０は、マイクロロケーション接続に切り替えるかどうか、デバイス１１０との安全な通信チャネルを確立することを試みるかどうかを決定する前に、デバイス１１０を認証することができない可能性がある。
図１４の図示の実施形態において、リレーアタックに対する保護を援助するために、メッセージタイミング情報が通信リンクのチャレンジ−レスポンスプロトコルに組み込まれてもよい。図１４に示されるアプリケーションの実施形態は、本明細書で論じられ、参照により本明細書に組み込まれるマイクロロケーションシステムに焦点を当てているが、本開示はそれに限定されず、本明細書に記載のシステム１００および通信方法は、デバイスまたはシステムコンポーネントの、いずれのタイプのシステムでの通信を容易にすることができる。
一実施形態では、いくつかのデバイスプラットフォーム／ライブラリは、バックグラウンド処理モードの間に、ＢＬＥ周辺機器がすべての所望の情報をアドバタイズすることを許可しないので、ＳＣＭ１２０および／またはデバイス１１０は、マイクロロケーション接続への移行を完了するために、ＢＬＥ結合情報を記憶してもよい。代替の実施形態では、ＢＬＥ結合は、ユーザーに代わって初期接続フェーズ中に完了されてもよい。
Ｂ．安全な接続の確立
デバイス１１０は、図１４の図示された実施形態に従ってＳＣＭ１２０との接続を開始することができる。ＳＣＭ１２０は、接続を受け入れ、ステップ１４０１−第１の（未知の）フェーズ、ステップ１４０２−第２の（安全の）フェーズ、およびステップ１４０３−第３の（信頼の）フェーズの接続確立プロセスを開始することができる。
・ 第１の（未知の）フェーズ
図示された実施形態では、第１の（未知の）フェーズの間、通信リンクが安全であるかどうかは不明である。
基礎をなす通信リンクは、あるレベルの暗号化および／または終端ノードハードウェア認証を既に提供することができ、それは、実際のところ安全であってもなくてもよい。例えば、基礎をなす通信リンクは、既知の欠陥／脆弱性に煩わされる可能性がある。その結果、このフェーズの間、通信リンクは安全ではないと想定される。
このフェーズにおいて、またはステップ１４０１中に、デバイス１１０は、安全な通信チャネルに切り替えるようにＳＣＭ１２０に要求を送信することができる（ステップ１４１０）。この要求は、デバイス１１０に、そのDevice-SCM-IDおよびＡＣＰコンテナバージョンパッケージ４１２をＳＣＭ１２０へ送信するように誘導することができる。代替実施形態では、デバイス１１０のDevice-SCM-IDは、ＡＣＰコンテナバージョンパッケージ４１２内に含まれてもよい。Device-SCM-IDは、Device-SCM-Key、ACP-Version-Key、またはDevice-SCM-Session-Key、もしくはそれらの組み合わせなどの後続のメッセージのために、いずれの暗号鍵のセットを使用すべきかを決定するために、ＳＣＭ１２０によって使用されることができる。
少なくともＡＣＰコンテナ４１０のセクション（セクションＩＩＩ）に記載されているように、ＳＣＭ１２０は、ＡＣＰ４００が更新されるべきである場合、安全な通信チャネルへの移行を許可しない可能性がある。ＳＣＭ１２０のＡＣＰ４００が更新されるべきであると判定された場合、ＳＣＭ１２０は、更新されたＡＣＰ４００を送信するためにデバイス１１０に要求を送り返すことができる。
ＳＣＭ１２０のＡＣＰ４００が更新される必要がない場合、ＳＣＭ１２０は、デバイス１１０が続行できることを示すメッセージをデバイス１１０に返信し、さらに、以前に格納されたセッション鍵（Device-SCM-Session-Key）を使用するかどうかを判定する（ステップ１４１２）。デバイス１１０が既に確立されたセッション鍵（セッション鍵自体は開示されなくてよい）を使用すべきであることをＳＣＭ１２０が示し、デバイス１１０がセッション鍵（Device-SCM-Session-Key）を所有する場合、デバイス１１０とＳＣＭ１２０は、即座に安全のフェーズに移行することができる。そうでない場合、ＳＣＭ１２０とデバイス１１０は、新しいセッション鍵（Device-SCM-Session-Key）の確立を開始することができる。Device-SCM-Session-Keyセッション鍵は、以下の１つ以上のステップに従って、デバイス１１０がＳＣＭ１２０のチャレンジレスポンス認証を達成しようと試みる間に確立されてもよい。
１）デバイス１１０は、暗号ノンス（Ｎ）を生成することができる。
２）デバイス１１０は、Device-SCM-Key（非公開）鍵でＮを暗号化し、ＮＤを作成することができる。
３）デバイス１１０は、ＮＤをＳＣＭ１２０に送信することができる。
４）ＳＣＭ１２０は、Device-SCM-Key（公開）鍵を使用してＮＤを復号し、ＮＤＳを作成することができる。
５）ＳＣＭ１２０は、暗号ノンス（Ｍ）を生成することができる。
６）ＳＣＭ１２０は、例えば、Ｍと連結されたＮＤＳの暗号ハッシュを使用して、セッションキーのコピー、Device-SCM-Session-Keyを計算することができる。セッションシーケンス番号（セッション鍵と共に格納される）が０または乱数にセットされることができる。
７）ＳＣＭ１２０は、ＮＤＳおよびＭをSCM-Key（非公開）鍵で暗号化し、ＮＭを生成することができる。
８）ＳＣＭ１２０は、デバイス１１０にＮＭを送信することができる。
９）デバイス１１０は、SCM-Key（公開）鍵を使用してＮＭを復号し、ＮＤＳＤおよびＭＤを作成することができる。
１０）デバイスは、ＮがＮＤＳＤに等しいことを確認することができる。一致がなければ、ＳＣＭ１２０は認証されることができず、デバイス１１０は切断する。ＳＣＭ１２０とデバイス１１０は、以前に計算されたセッション鍵を破棄してもよい。チャレンジレスポンス認証プロセスは、この段階で中止されることがある。
１１）デバイス１１０は、例えば、ＭＤと連結されたＮの暗号ハッシュを使用して、セッション鍵のコピー、Device-SCM-Session-Keyを計算することができる。セッション鍵とともに格納されるセッションシーケンス番号は０に設定されることができる。
この時点で、デバイス１１０とＳＣＭ１２０の両方が新しいセッション鍵を計算したが、それらが首尾よく通信できることはいずれも検証しておらず、それはＳＣＭ１２０の真正性のさらに別の基準と考えることができる。チャレンジレスポンス認証プロセスが首尾よく完了した場合、ステップ１４０２で、デバイスとＳＣＭは即座に安全のフェーズに移行することができる。
一実施形態では、チャレンジレスポンス認証プロセスにおけるメッセージを暗号化することに加えて、メッセージが署名された後に暗号化されてもよい。代替実施形態では、デバイス１１０によって生成される暗号ノンス（Ｎ）は、Device-SCM-Key（非公開）鍵の代わりにSCM-Key（公開）鍵によって暗号化されてもよい。別の代替実施形態では、デバイス１１０によって生成される暗号ノンス（Ｎ）は暗号化されなくてもよい。さらに別の代替の実施形態では、ＳＣＭ１２０によって生成される暗号ノンス（Ｍ）は、セッション鍵がまだ確立されていないときに、「続行」メッセージとともに送信されてもよい（チャレンジレスポンス認証プロセスの前に送信される）。
さらに別の代替実施形態では、セッション鍵（Device-SCM-Session-Key）は別の方法によって計算されてもよい。さらに別の代替の実施形態では、代わりのチャレンジレスポンス認証アルゴリズムが利用されてもよい。さらに別の実施形態では、Device-IDがDevice-SCM-EDとして使用されてもよい。一実施形態では、セッションシーケンス番号は利用されない。
一実施形態では、チャレンジレスポンス認証プロセスが成功したとき（すなわち、デバイスがそのセッション鍵を生成するとき）、デバイス１１０はＳＣＭ１２０に「セッション鍵確立済み」メッセージを送信してもよい。一実施形態では、デバイス１１０は、チャレンジレスポンス認証プロセスが中止されたときに、ＳＣＭに「認証失敗」メッセージを送信してもよい。
一実施形態では、ＳＣＭ１２０は、このフェーズまたはステップ１４０１の間に（ＳＣＭ１２０の真正性を検証するデバイス１１０に代わって）デバイス１１０の真正性を検証してもよい。その結果、後の段階で、コマンドが送信されるとき、デバイス１１０が、ＳＣＭ１２０の真正性を検証する場合がある。
一実施形態では、本明細書に記載された１つ以上の実施形態に追加または代替として、デバイス１１０とＳＣＭ１２０が、ステップ１４０１の間に相互に互いを認証してもよい。この場合、成功したならば、デバイス１１０およびＳＣＭ１２０は、信頼のフェーズに移行してもよい。
ＳＣＭ１２０は、所定の活動停止期間後にデバイス１１０から切断するように構成されてもよい。ＳＣＭ１２０は、いつでも、または任意のイベントに応答して、デバイス１１０から切断してもよい。例えば、ＳＣＭ１２０は、ＳＣＭ１２０における高いシステムリソースの使用率のため、所定の時間内に要求に応答しないため、または、所定の最大持続時間を超える接続持続時間のために、切断してもよい。
このセクションＸＩＶ．Ｂの冒頭で説明したように、ＳＣＭ１２０は、ＡＣＰコンテナバージョンパッケージ４１２を伴うＡＣＰコンテナ４１０を送信するようにデバイス１１０に要求してもよい。デバイス１１０は、このフェーズの間にＡＣＰコンテナ４１０をＳＣＭ１２０に送信してもよい。ＡＣＰコンテナ４１０の受信に応答して、ＳＣＭ１２０は、ＡＣＰコンテナ４１０が受け入れられたか、処理されなかったか、または拒絶されたかを、おそらくは最低でも示すステータス表示を有する応答を提供してもよい。受け入れは、ＡＣＰコンテナ４１０が処理され格納されていることを示し、ＡＣＰコンテナ４１０に含まるどのような変更もうまく適用されたことを示す可能性がある。処理されないのは、ＡＣＰコンテナ４１０が古いまたは同じバージョンであることに起因する可能性がある。拒絶は、検証が失敗したことを示している可能性がある。代替実施形態では、ＳＣＭ１２０は、処理を更新するために、ＡＣＰコンテナ４１０に関してデバイス１１０にステータス表示を提供しなくてもよい。
工場リセット状態をサポートするために、デバイス１１０は、新規オーナー開始要求を介して、ステップ１４０１の間にＳＣＭ１２０からSCM-Key（公開）鍵および／またはSCM-ID識別子を要求してもよい。この要求に応答して、工場リセットモードにある場合には、ＳＣＭ１２０は、SCM-Key（公開）鍵および／またはSCM-ED識別子を含む応答を提供することができ、それにより、ＳＣＭ１２０が、実際に工場リセットモードにあることを示すことができる。
ＳＣＭ１２０は、失敗した認証試行に関する情報をＳＣＭシステムログに記録してもよい。失敗した認証試行の例には、安全の、および／または信頼のフェーズに入る、またはその中に留まることの失敗が含まれる。
２．第２の（安全の）フェーズ
第２の（安全の）フェーズまたはステップ１４０２の間、デバイス１１０およびＳＣＭ１２０の両方は、安全な通信チャネルを生成するために使用され得るセッション鍵（Device-SCM-Session-Key）を有することができる。すなわち、セッション鍵は、デバイス１１０およびＳＣＭ１２０が、データの暗号化、シーケンス番号の増加、およびメッセージ認証コードの生成の１つ以上を実行することを可能にすることができる。
安全な通信チャネルを使用するデバイス１１０およびＳＣＭ１２０からのメッセージは、暗号化し、そしてＭＡＣを行うために（例えば、Device-SCM-Session-Keyを使用してメッセージを暗号化し、暗号化されたメッセージから計算されるＭＡＣ[メッセージ認証コード]を付加するために）、増加するシーケンス番号とともに、Device-SCM-Session-Keyセッション鍵を使用して送信されてもよく、それにより、デバイス１１０およびＳＣＭ１２０が送信／受信されたメッセージを検証および認証することが可能となる。この通信モードは、ＴＬＳ／ＤＴＬＳのいくつかの特徴に類似しているかもしれない。暗号化後ＭＡＣ以外の手法が使用されてもよいことに留意されたい（例えば、ＭＡＣ後暗号化、または暗号化並びにＭＡＣ）しかし、それらは、安全性が低くなる可能性がある。
図示の実施形態では、セッション鍵（Device-SCM-Session-Key）は接続を存続させることができる。したがって、セッション鍵の持続時間または持続性を制限するために、Device-SCM-Session-Keyセッション鍵は、定期的におよび／または都合のよい時に、ＳＣＭ１２０によって（任意のフェーズで）循環されてもよい。都合のよい時は、ユーザーエクスペリエンスが既に影響を受けている他のイベント中、またはどんな方法でも（鍵循環またはＡＣＰ更新）新しいセッション鍵をもたらす他のアクションが発生している間であってもよい。都合のよい時はまた、より伝統的な意味としてとらえることができ、その場合、都合のよい時は、ユーザー１０がＳＣＭ１２０を積極的に使用していないが、ＳＣＭ１２０の範囲内にいる間、またはユーザーが範囲を出入りしており、処理を完了するのに十分な時間がある間など、ユーザーエクスペリエンスが影響を受けない、または顕著に影響を受けない時と考えられる。範囲内にいる例としては、すでに始動されている車の中に座っていること、テーブルに着いていること、施錠されたドアの中に座っていることが含まれる。
セッション鍵は、既存の安全な通信チャネル内でセッション鍵ローリングアルゴリズムを実行することによって、および／または、チャレンジレスポンス認証プロセス、または未知のフェーズおよび未知のフェーズ中のセッション鍵の計算に関して本明細書に記載されたプロセスといくつかの点で類似の別のプロセスを使用して新しいセッション鍵を計算することによって、循環させることができる。追加的にまたは代替的に、セッション鍵は、格納されたセッション鍵を無効化し、次いで、未知のフェーズの間にセッション鍵を切断して再確立することによって循環させることができる。一実施形態では、デバイス１１０が、セッション鍵の循環を開始することができる。
ステップ１４０２の開始時に、セッション鍵（Device-SCM-Session-Key）が有効であることを検証する（チャネルが動作可能であることを検証する）ためのＳＣＭ１２０への要求と、チャネルの有効性とＳＣＭ１２０の真正性の両方を検証するための要求のいずれかを、デバイス１１０が送信してもよい（ステップ１４１６、１４１８）。例えば、前のフェーズが最近実行されなかったなど、既存のセッション鍵が使用された場合、ＳＣＭ１２０の有効性および真正性が確認され得る（ステップ１４１８）。
デバイス１１０が、チャネルの動作を最近確認した場合、またはセッション鍵が有効であることを検証した場合、このチャネルの検証ステップ１４１８をスキップしてもよい。代替の実施形態では、デバイスは検証ステップ１４１８をスキップしなくてもよい。
セッション鍵検証ステップ１４１８を完了するために、デバイス１１０およびＳＣＭ１２０は、安全のフェーズのチャレンジレスポンスプロトコルを実行してもよい。このプロトコルの第１の目的は、ＳＣＭ１２０の真正性がすでに確立されていて、未知のフェーズから検証のフェーズへと直ちに入るときに、デバイス１１０がチャネルの動作を検証することである。しかし、安全のフェーズのチャレンジレスポンスプロトコルは、チャネルの接続を保持するものとして、または他の目的のために、デバイス１１０またはＳＣＭ１２０のいずれかによって定期的に使用されてもよい。以下に、（簡単な）チャレンジレスポンスプロトコルの例が示される。
１）デバイス１１０（またはＳＣＭ１２０）は、乱数（Ｎ）を生成することができる。
２）デバイス１１０は、ＮをＳＣＭに送信することができる。
３）ＳＣＭ１２０は、Ｎ＋１（Ｍ）を計算することができる。
４）ＳＣＭ１２０は、Ｍをデバイス１１０に送信することができる。
５）デバイス１１０は、Ｎ＋１がＭに等しいことを検証することができる。それらが一致しない場合、おそらくメッセージが適切に通信されなかったため、検証は失敗する結果となる。
デバイス１１０が安全のフェーズのチャレンジレスポンスプロトコルを実行するとき、デバイス１１０は、通信チャネルが動作していることを検証してもよい。デバイス１１０は、この段階では、ＳＣＭ１２０が正しいセッション鍵を所有している点を除いて、ＳＣＭ１２０の真正性に関する何かを検証していなくてもよい。ＳＣＭ１２０も、安全な通信チャネルを検証するために、安全のフェーズのチャレンジレスポンスプロトコルを開始すことができるので、ＳＣＭ１２０とデバイス１１０の役割は逆にされてもよい。代替の実施形態では、安全のフェーズのチャレンジレスポンスプロトコルは利用されなくてもよい。この場合、認証プロトコルが常に使用されてもよいし、または、認証プロトコルは存在しない。
一実施形態では、デバイス１１０は、ＳＣＭ１２０の真正性を検証するために、安全のフェーズのチャレンジレスポンス認証プロトコルを使用してもよい。安全のフェーズのチャレンジレスポンス認証プロトコルは、所定の時間が経過した後に安全のフェーズに入ったとき、または他の何らかのイベントが発生したとき、定期的に実行されてもよい。例示的なイベントは、ＳＣＭ１２０が安全のフェーズのチャレンジレスポンス認証プロトコルを実行することをデバイス１１０に要求すること、および更新されたＡＣＰ４００がデバイス１１０によって受信されたことを含む。以下に概説される安全のフェーズの認証プロトコルは、多くの点で未知のフェーズの認証プロトコルと類似している。しかし、本明細書に概説される安全のフェーズの認証プロトコルは、より少ない非対称暗号化処理しか利用しないので、大幅に少ない計算しか利用しないで済む。例示的な安全のフェーズの認証プロトコルは、以下のように行うことができる（代わりのチャレンジレスポンス認証プロトコルを使用することもできる）。
１）デバイス１１０は、暗号ノンス（Ｎ）を生成することができる。
２）デバイス１１０は、ＮをＳＣＭに送信することができる。
３）ＳＣＭ１２０は、Ｎ＋１（Ｍ）の暗号ハッシュを計算することができる。
４）ＳＣＭ１２０は、SCM-Key（非公開）鍵でＭを暗号化して、ＭＳを作成することができる。
５）ＳＣＭ１２０は、ＭＳをデバイス１１０に送信することができる。
６）デバイス１１０は、SCM-Key（公開）鍵を使用してＭＳを復号し、ＭＳＤを作成することができる。
７）デバイス１１０は、Ｎ＋１（ＭＤ）の暗号ハッシュを計算することができる。
８）デバイス１１０は、ＭＤがＭＳＤに等しいことを確認することができる。それらが一致しない場合は、ＳＣＭ１２０がその真正性を証明するための適切な暗号化鍵を所有していない可能性があるため、認証は失敗する結果となる。
代替の実施形態では、SCM-Key（非公開）鍵の代わりに、Device-SCM-Key（公開）鍵などの代わりの暗号鍵が利用されてもよい。代替の実施形態では、Device-SCM-Key鍵などの追加の暗号鍵が利用されてもよい。
未知のフェーズにおける説明された処理と同様に、デバイス１１０は、安全な通信チャネルを使用してＡＣＰコンテナバージョンパッケージ４１２をＳＣＭ１２０に送信してもよい。一例として、デバイス１１０は、更新されたＡＣＰコンテナ４１０のデバイス受信に応答して、またはそれに基づいて、ＡＣＰコンテナバージョンパッケージ４１２を送信してもよい。ＳＣＭ１２０が、対応するＡＣＰコンテナ４１０を受信する必要性または希望を決定した場合、ＳＣＭ１２０は、ＡＣＰコンテナバージョンパッケージ４１２に付随するＡＣＰコンテナ４１０を送信するようにデバイス１１０に要求してもよい。ＳＣＭ１２０はまた、デバイス１１０に、周期的に、またはイベントの発生に応答して、デバイス１１０に格納された最新のＡＣＰコンテナバージョンパッケージ４１２を送信するようにデバイス１１０に要求してもよい。
デバイス１１０は、安全な通信チャネルを使用して、このフェーズの間にＡＣＰコンテナ４１０をＳＣＭ１２０に送信することができる。これに応答して、ＳＣＭ１２０は、以前のフェーズで説明したように、ステータス表示を有するレスポンスを提供することができる。代替の実施形態では、ＡＣＰコンテナ４１０および／またはＡＣＰコンテナバージョンパッケージ４１２は、安全のフェーズ中にＳＣＭ１２０に送信されることを許可されなくてもよい。本明細書で説明するように、ＡＣＰコンテナ４１０と同様の意味／処理を使用する他の設定パッケージが存在してもよく、従って、ＡＣＰコンテナ４１０が、このフェーズ及び他のフェーズで配信されえる、システム１００の唯一の設定パッケージであると推断されるべきではない。
一実施形態では、ファームウェア更新パッケージ（ＦＵＰ）は、安全のフェーズまたは信頼のフェーズの間になど、安全な通信チャネルを介してのみ、デバイス１１０からＳＣＭ１２０に配信されてもよい。デバイス１１０は、クラウド１３０から、またはデバイス１１０に格納される実行可能／ロード可能イメージの一部として、ＦＵＰを取得することができる。例えば、ＦＵＰは、アプリケーションバンドルの一部として取得されてもよいし、より大きなデバイスファームウェアイメージに含まれる別個のイメージとして取得されてもよい。
一実施形態では、ＦＵＰは、任意の通信チャネルを介してデバイス１１０からＳＣＭ１２０に配信されてもよい。一実施形態では、ＦＵＰは、信頼のフェーズの間にのみなど、デバイス１１０が認証された安全な通信チャネルを介してだけ、デバイス１１０からＳＣＭ１２０に配信されてもよい。一実施形態では、ＦＵＰは、オーナーデバイス１１０によってのみ、デバイス１１０からＳＣＭ１２０に配信されてもよい。一実施形態では、デバイス１１０は、ＦＵＰをＳＣＭ１２０に配信しなくてもよい。追加または代替のファームウェア更新設定および実施形態は、少なくともセクションＸＶに記載されており、それは、ファームウェア更新パッケージ自体に関する追加の情報を含む。
ＳＣＭ１２０は、安全な通信チャネルを使用して、少なくともセクションＸＸＩにおいて本明細書でさらに詳しく論じるブラックリストパッケージをデバイス１１０に送信してもよい。デバイス１１０は、ブラックリストパッケージに対して、ステータス表示を有するレスポンスを提供してもよい。一実施形態では、デバイス１１０は、デバイス１１０にブラックリストパッケージを送信するようにＳＣＭ１２０に要求してもよい。ブラックリストに載せる項目がない場合、ＳＣＭ１２０は何もしなくてもよいし、またはＳＣＭ１２０はブラックリストに載せる項目が存在しないことのしるしを送信してもよい。
デバイス１１０およびＳＣＭ１２０は、安全な通信チャネルを介して互いに通信しつつ、バックグラウンドで様々なシステムレベルの処理を実行してもよい。これらの処理は、開始または完了のために認証および／または認可を利用するコマンドの明示的な実行に関連しないかもしれない。開示の目的のために、デバイス１１０とＳＣＭ１２０との間の通信の結果、または通信が行われない結果として実行される任意の処理は、コマンドとみなされる。したがって、このようなバックグラウンドの処理はコマンドと見なされる。実行される可能性のあるすべてまたはアクションは、コマンドと見なすことができる。何も接続されていないときに発生するなんらかの操作またはアクションがあるかもしれず（例えば、ライトを消す）、また、何かが接続されているときに発生するなんらかの操作またはアクションがあるかもしれない（例えば、デバイスを追跡する、ライトを点ける、など）。コマンドは、デバイス１１０またはＳＣＭ１２０、もしくは他のシステムコンポーネントのアクションまたは動作に関連してもよい。
例示的なバックグラウンド処理は、マイクロロケーションサービス、ＧＰＳ／ＩＮＳサービス、ステータス情報、ロギング、バックグラウンド／メンテナンス処理、パワーモード変更、および設定更新を含む。さらに、ある通信フェーズから別のフェーズへの移行は、コマンドとみなされる（例えば、切断するために、未知から安全、安全から信頼、信頼から未知への移行など）。例えば、ＳＣＭ１２０に対するデバイス１１０のための認可は、信頼の通信フェーズへの移行が必要とされるかもしれない（すなわち、認可は認証情報と認可基準の両方を含むことができる）。
このフェーズ（ステップ１４０２）において、ＳＣＭ１２０は、デバイスの真正性を明示的に検証していない可能性があることにも留意する価値がある。近時または最初に、明示的な検証が行われていない可能性がある。しかしながら、デバイス１１０が真正であるという高い信頼性を有する十分な証拠が存在し得る。このフェーズ（ステップ１４０２）のある時点で、デバイス１１０および／またはＳＣＭ１２０は、以下のコマンドのいずれか１つ以上を送信／受信することをカプセル化することができる、コマンドを発生、発行、または受信することができる。
１）コマンド（例えば、デバイス１１０は、何かを行うようにＳＣＭ１２０またはその機器コンポーネント１４０に指示しているかもしれない）。
２）要求（例えば、デバイス１１０は、データを送信するように、ＳＣＭ１２０またはその機器コンポーネント１４０に要求しているかもしれない）。
３）更新（例えば、ＳＣＭ１２０またはその機器コンポーネント１４０は、周期的／非周期的データを提供しているかもしれない）。
４）レスポンス（例えば、ＳＣＭ１２０またはその機器コンポーネント１４０は、リクエストに対するレスポンスを提供しているかもしれない）。
ＳＣＭ１２０は、デバイス１１０の存在、位置、認証状態、または認可状態、もしくはそれらの任意の組み合わせに基づいて、列挙されたコマンドのうちのいずれか１つを含む処理を実行することができる。デバイス１１０は、ＳＣＭ１２０の存在、場所、認証状態、または認可状態、もしくはそれらの任意の組み合わせに基づいて、列挙されたコマンドのうちのいずれか１つを含む処理を実行することができる。
様々なタイプのコマンド、およびコマンドとみなされるものの上記の説明は、網羅的なものではなく、または上記のリストに制限されず、また、コマンドのリストはこのフェーズの通信に制限されない（例えば、コマンドは、通信のいずれのフェーズであるかに係わらず、生成され、発行され、もしくは受信されたコマンドである）。
ＳＣＭ１２０がコマンドを受信し、デバイス１１０が認証されていない場合、コマンドは、デバイス１１０が認証されている間、キューに登録されてもよい。デバイス１１０が認証に失敗した場合、拒絶されたコマンドごとに適切なエラーレスポンスが提供されてもよい。
一実施形態では、デバイス１１０が認証されている間に、１つまでのコマンドのみがキューに登録されてもよい。追加的にまたは代替的に、デバイス１１０がまだ認証されていない場合、コマンドが拒絶されてもよい。
一実施形態では、システムレベルのバックグラウンド処理は、信頼のフェーズでない限り、許可されなくてもよい（ステップ１４０３）。
ＳＣＭ１２０は、ユーザーエクスペリエンスを改善するために、たとえコマンドが送信または受信されなくても、デバイス１１０を（先制して）認証してもよい。別の実施形態では、ＳＣＭ１２０は、デバイス１１０を先制して認証しなくてもよい。
一実施形態では、デバイス１１０がＳＣＭ１２０にコマンドを送信または受信するために、ＳＣＭ１２０は、ＳＣＭ１２０によるデバイス１１０の認証を必要とするかもしれない。ＳＣＭ１２０は、コマンドの実行を許可する前にデバイス１１０の真正性を検証するために、安全のフェーズのチャレンジレスポンス認証プロトコルを開始してもよい（ステップ１４２０、１４２２）。安全のフェーズのチャレンジレスポンス認証プロトコルの一例は、以下のステップの１つ以上を含むことができる。
１）ＳＣＭ１２０は、暗号ノンス（Ｎ）を生成することができる。
２）ＳＣＭ１２０は、Ｎをデバイスに送信することができる。
３）デバイス１１０は、Ｎ＋１（Ｍ）の暗号ハッシュを計算することができる。
４）デバイス１１０は、Device-SCM-Key（非公開）鍵を用いてＭを暗号化し、ＭＳを作成することができる。
５）デバイス１１０は、ＭＳをＳＣＭに送信することができる。
６）ＳＣＭ１２０は、Device-SCM-Key（公開）鍵を使用してＭＳを復号化し、ＭＳＤを作成することができる。
７）ＳＣＭ１２０は、Ｎ＋１（ＭＤ）の暗号ハッシュを計算することができる。
８）ＳＣＭ１２０は、ＭＤがＭＳＤに等しいことを確認することができる。ＭＤとＭＳＤが一致しない場合、認証は失敗する結果となる。言い換えれば、ＭＤとＭＳＤとが一致しない場合、デバイス１１０は、デバイス１１０の真正性を証明するための適切な暗号鍵を所有していなかったことになる。
デバイス１１０が認証されると、デバイス１１０は、所定の期間、および／または、接続切断の発生、ＡＣＰコンテナ４１０への更新、および機器コンポーネント１４０からの認証要求、もしくはそれらの任意の組み合わせなどの所定のイベントが発生するまで、再度認証されなくてもよい。
一実施形態では、本明細書で説明するように、デバイス１１０の真正性は、鍵循環セッションあたり１度だけ実行されてもよい。一実施形態では、デバイス１１０の真正性のＳＣＭ検証が失敗した場合、デバイス１１０およびＳＣＭ１２０は、安全のフェーズに留まってもよい（ステップ１４０２）。
一実施形態では、デバイス１１０の認証は、デバイス１１０から発行され、デバイス１１０によって送信されるすべてのコマンドで、ＳＣＭ１２０によって実行されてもよい。一実施形態では、デバイス１１０の認証は、デバイス１１０から発行されるすべてのコマンドで実行されてもよい。一実施形態では、ＳＣＭ１２０の認証は、ＳＣＭ１２０から発行されるすべてのコマンドで実行されてもよい。
チャレンジレスポンスプロセスまたはチャレンジレスポンス認証プロセスが失敗した場合、デバイス１１０およびＳＣＭ１２０は、直ちに、切断してもよいし、および／または、ステップ１４０１での未知のフェーズに戻ってもよい。
ＳＣＭ１２０がデバイス１０の真正性を確認した後、デバイス１１０およびＳＣＭ１２０は、信頼のフェーズに移行することができる。
３．第３の（信頼の）フェーズ
第３の（信頼の）フェーズの間、デバイス１１０とＳＣＭ１２０の両方が、検証されたセッション鍵（Device-SCM-Session-Key）を所有してもよく、デバイス１１０とＳＣＭ１２０の両方が真正であると決定される（ステップ１４０３）。
このフェーズ（ステップ１４０３）の間に、例えば、ＡＣＰコンテナ４１０への更新、ファームウェア更新、バックグラウンド／他の処理、および、デバイス１１０とＳＣＭ１２０のチャレンジレスポンス認証プロトコルを含む、以前のフェーズのアクション及びその帰結のすべてまたはサブセットが、安全な通信チャネルを介して実行されてもよい。安全な通信チャネルを介した認証に失敗した場合、デバイス１１０およびＳＣＭ１２０は直ちに切断してもよいし、および／または以前のフェーズ（例えば、未知のフェーズ）に戻ってもよい。
信頼のフェーズの間に、ＳＣＭ１２０とデバイス１１０の両方の定期的な認証が利用されてもよく、必要であるとさえみなされてもよい。定期的な認証は、コマンドのルーチン実行によって、（適切なチャレンジレスポンス認証プロトコルを介した）ＳＣＭ１２０およびデバイス１１０についての真正性の定期的なおよび／またはトリガされた別個の認証検証によって、または定期的なおよび／またはトリガされた相互認証のチャレンジレスポンス認証プロトコルによって、実施されてもよい。代替の実施形態では、ＳＣＭ１２０とデバイス１１０の両方の定期的な認証は、必要でなくともよいし、または必要とみなされなくてもよい。
一実施形態では、１つ以上の例外はあるが、上述のチャレンジレスポンスプロトコルに類似する、相互認証チャレンジレスポンスプロトコルが実装されてもよい。１つの違いは、ＳＣＭ１２０とデバイス１１０の両方が1つのシーケンスにおいて認証されることである。この単一シーケンス認証は、ＴＬＳ／ＤＴＬ相互認証の１つ以上の特徴を組み入れることができる。チャレンジレスポンス認証プロセスが失敗した場合、デバイス１１０およびＳＣＭ１２０は直ちに切断してもよいし、および／または未知のフェーズに戻ってもよい。
信頼のフェーズ（ステップ１４０３）の間、抽象的なユーザー定義のコマンドおよび／またはデータを転送し合うために使用すべく、ＳＣＭ１２０とデバイス１１０との間で、不透明データチャネル（ＯＤＣ）が利用可能にされてもよい。ＯＤＣは、ＳＣＭ１２０が、１つのシステムコンポーネント（例えば、デバイス１１０）からのコマンドおよび／またはデータを、デバイス１１０はそうすることを許可されているが、おそらく、そのデバイス１１０のＡＰＩまたはデータの細部の知識を利用しないことを保証しつつ、他のデバイス（例えば、機器コンポーネント１４０）に確実に渡すことを可能にすることができる。ＯＤＣ内で使用されるコマンドおよび／またはデータの認可、検証、および確認のうちの１つまたは複数が、ＳＣＭ１２０によって実行されないかもしれない。ＡＣＰ４００は、追加の認証タイプ及び識別子のような、ＯＤＣと共に有用であり得る追加の情報を含むこともできる。
ＸＶ．ファームウェアのアップグレード
一実施形態では、システム１００は、システムコンポーネントがファームウェアを安全かつ確実にアップグレードできることを保証するように構成されえる。ファームウェアをアップグレードする機能により、セキュリティ上の脆弱性やファームウェアの欠陥を修正することができる。ファームウェア更新は、本明細書で説明するファームウェア更新パッケージ（ＦＵＰ）を介してＳＣＭ１２０に配信されることができる。
ＦＵＰは、ＦＵＰバージョンパッケージ（多くの点でＡＣＰコンテナバージョンパッケージ４１２に類似するが、ＡＣＰ４００の代わりにＦＵＰの転送を容易にするように適合されている）を使用して受信されえる。ＦＵＰ（及び、一緒に提供されるＦＵＰバージョンパッケージ）は、クラウド１３０を介して、機器コンポーネント１４０などのシステムコンポーネントに配信され、次いで、ＡＣＰコンテナ４１０と同様の方法でＳＣＭ１２０に配信されえる。
一実施形態に従って本明細書に説明されるように、ファームウェア更新は、安全な通信チャネルを介してＳＣＭ１２０に配信されてもよい。異なるシステムのインスタンス化は、異なる許容されるファームウェア更新ディストリビュータを有することができる。例えば、１つのシステムは、ファームウェアをデバイス１１０を介して、またはクラウド１３０から直接的に配信することを可能にすることができるが、それに対し、別のシステムは、機器コンポーネント１４０またはＳＣＭ１２０の物理的媒体を介してのみ更新が行われることを期待することができる。
ＦＵＰは、ＦＵＰがいずれかのシステムコンポーネントから特定のＳＣＭ１２０に送信され、格納され、配信され得るという点で、本明細書で説明されるＡＣＰコンテナ４１０および他の安全なファームウェアイメージ／配信手法の設計と類似している。しかし、一実施形態では、システム１００は、送信が１つ以上の特定のシステムコンポーネントのみ可能とされるように構成されてもよい。別の実施形態では、任意のタイプの通信チャネルを介してファームウェア更新がＳＣＭ１２０に送信されてもよい。
ＦＵＰおよびＦＵＰバージョンパッケージは、ＡＣＰコンテナ４１０と同様に、ターゲットＳＣＭ１２０用に署名され、および／または暗号化され、次いで、クラウド１２０によって署名され、および／または暗号化されてもよく、それにより、ＦＵＰおよびＦＵＰバージョンパッケージが、適切なクラウド１３０から発信されたことが検証でき、および、ターゲットＳＣＭ１２０のみがＦＵＰおよびＦＵＰバージョンパッケージの内容を復号することができる。
ＦＵＰがターゲットＳＣＭ１２０に特有である場合、ターゲットＳＣＭ１２０はパッケージ内で特定されえる。クラウド１３０のアイデンティティは、ＦＵＰおよびＦＵＰバージョンパッケージ内において提供されえる。
一実施形態では、ＦＵＰおよびＦＵＰバージョンパッケージは、クラウド１３０によってのみ暗号化および／または署名されてもよい。ＦＵＰおよびＦＵＰバージョンパッケージは、多くのＳＣＭ１２０に可視であり、および／または適用可能であってもよく、または、１つのＳＣＭ１２０にのみ適用可能であるが、ＦＵＰおよびＦＵＰバージョンパッケージの内容は、多くのＳＣＭ１２０のすべてに可視であってもよい。一実施形態では、ＦＵＰバージョンパッケージは、ACP-Package-Version鍵を使用して、暗号化され、および／または署名されてもよい。
一実施形態では、ＦＵＰおよびＦＵＰバージョンパッケージは暗号化されていなくてもよい。別の実施形態では、ＦＵＰは、その他のオプションの中で、特定の業界、顧客、製品ライン、および／またはターゲットの数（単一のターゲットに固有であることを含む）に固有であってもなくてもよい、製造業者提供の暗号キー（例えば、Firmware-Key）でさらに署名され、および／または暗号化されてもよい。一実施形態では、署名および／または暗号化の追加の層がＦＵＰおよび／またはＦＵＰバージョンパッケージのために利用されてもよく、それは、ＦＵＰバージョンパッケージをＡＣＰコンテナ４１０の構成により類似させる。
ＦＵＰは、１つ以上のシステムコンポーネント（例えば、デバイス１１０またはクラウド１３０）において、セキュアメモリ２２０、もしくはセキュアエンクレーブまたはハードウェアセキュリティモジュール（ＨＳＭ）などのセキュアエレメントまたは同等のハードウェアモジュール内に安全に格納されてもよい。
一実施形態では、ＦＵＰは、セキュアエレメント（または同等のハードウェアモジュール）に格納されなくてもよい。しかし、それでもＦＵＰは安全に格納されえる。例えば、セキュアメモリ２２０を使用しないセキュアストレージは、ACP-Version-Key非公開鍵が静止時に暗号化されてもよい、そのようなデータに対するアクセスを防止するために、ソフトウェアベースの対処および／またはハードウェアベースの対処が実装されてもよい、および、ハードウェアおよび／または物理的な障害物またはシールドが実装されてもよい、とのいずれか１つ以上によって達成することができる。ＪＴＡＧおよび他のポートが無効化されてもよい。攻撃ベクトルを排除するために、強化されたソフトウェアインターフェースが実装されてもよい。信頼できる実行環境、ハードウェアまたはソフトウェアが制定され、オペレーティングシステムのルートアクセスまたはセキュリティ破壊の招来を検出するための検出システムが実装されてもよい。代替の実施形態では、ACP-Version-Key非公開鍵は安全に格納されない。
ＳＣＭ１２０およびＳＣＭ１２０のサブコンポーネントは、ファームウェア更新イメージを受信している間、正常に動作し続けることができる。ＳＣＭ１２０およびＳＣＭ１２０のサブコンポーネントは、直ちに、および／または使用されていないとき、および／または１日における時刻または週の曜日など、所定の期間に、更新を適用することができる。一実施形態では、ＳＣＭ１２０およびＳＣＭ１２０のサブコンポーネントは、ファームウェアが更新されている間、通常動作を中断または無効にする更新モードに入ることができる。
ＳＣＭ１２０は、ＳＣＭ１２０の現在動作中のファームウェアが破損しているか、もしくは期待されたまたは要求された制約内で動作していない場合に、それ自身のファームウェアおよびすべてのＳＣＭサブコンポーネントの以前のバージョンにロールバックすることができる。例えば、単位時間内に過度に多くの例外が発生した場合、ＳＣＭ１２０が別のファームウェア更新を実行するのに十分長い間連続して動作できない場合、ＳＣＭ１２０が別のシステムコンポーネント（デバイス１１０、クラウド１３０、または機器コンポーネント１４０など）との接続を確立できない、または、ロード時にイメージハッシュ／ＣＲＣ検証が失敗した場合、もしくはそれらの任意の組み合わせの場合、ＳＣＭ１２０は、ロールバック手続きを開始することができる。動作の制約は、ブートセレクタ、ブートローダ、ファームウェア／アプリケーション、または他のロード可能項目内でハードコードされてもよい。
一実施形態では、動作の制約は、実行時に設定可能であってもよい。動作の制約を評価するのに有用な統計的および／または他の情報は、リセットおよび／または電力消失を切り抜けるメモリ領域に格納されてもよい。一実施形態では、動作の制約は、ランタイム挙動のまたは統計的な解析、ランタイム性能（例えば、タイミングまたはスループット）解析、機械学習を使用する分類、またはファームウェアが適切に動作しているかどうかを判定する他の動的アナライザ、もしくはそれらの任意の組み合わせを含むことができる。一実施形態では、ファームウェアロールバックが発生すると、ＳＣＭ１２０のサブコンポーネントは、通知され、ロールバックするか否かを選択してもよい。一実施形態では、ＳＣＭ１２０およびＳＣＭ１２０のサブコンポーネントは、例えば、これらのコンポーネントのうちの１つ以上がロールバックを実行できないため、またはそれらのコンポーネントの１つ以上がダウングレードするべきか否かを判定するための十分な統計データを追えないためなどを含む、さまざまな理由でロールバックしないかもしれない。
一実施形態では、ＦＵＰを要求する前に、ファームウェアバージョン、タイムスタンプ、最小互換バージョン、および他のバージョン情報、並びにＦＵＰバージョンパッケージによって特定されるＦＵＰ内のファームウェアイメージのすべてまたはサブセットに対する制約、もしくはこれらの情報の任意の組み合わせが、適用可能性について検証されてもよい。
ＦＵＰが適用可能であると判定された場合、ＦＵＰはターゲットから要求されてもよい。特定のファームウェア更新イメージは、ファームウェア更新イメージのバージョンが現在のファームウェアよりも新しい（または等価で、そのタイムスタンプがより新しい）、様々な設定の最小互換バージョンが新たしいファームウェアと互換性がある、および他のすべての制約が満たされる、などの１つ以上の基準に基づいて適用可能であると判定されてもよい。完全なファームウェアイメージが取得されると（そして、おそらくＲＯＭに書き込まれるときに再度）、イメージがターゲットによって検証されてもよい。検証には、完全性ハッシュ、署名、検証される可能性のある他の属性の分析、またはそれらの任意の組み合わせの実施が含まれる。
一実施形態では、ファームウェアイメージは、より小さなチャンク（制約のあるコンポーネントによる処理を可能にするため）で、ターゲットシステムコンポーネントに配信されてもよく、それにより、より小さなチャンクが独立して検証されることができる。
ＳＣＭ１２０は、ＳＣＭ１２０のサブコンポーネントのファームウェア更新を認証し、追加的に暗号化および／または署名し、または変更されないままとし、あるいはそれらの任意の組み合わせを行って、その更新をサブコンポーネントに配信してもよい。ＳＣＭ１２０のサブコンポーネントは、他のシステムコンポーネントの観点からＳＣＭ１２０を集合的に表す、ＳＣＭ１２０における他のハードウェアモジュール、および／またはＳＣＭ１２０における他のセンサであってもよい。
一実施形態では、ＳＣＭ１２０のサブコンポーネントへのファームウェア更新の配信は、サブコンポーネント間で同期および／または順序付けされてもよい。ＳＣＭ１２０は、自身を更新する前にすべてのサブコンポーネントを更新して、ロードされたアイテムのバージョンを検証することによって各サブコンポーネントが正常に更新されたことを検証してもよい。一実施形態では、ＳＣＭ１２０は、サブコンポーネントのファームウェアの前に自身のファームウェアを更新してもよい。一実施形態では、システム１００は、ＦＵＰ内のデータに基づいて、ＳＣＭ１２０が最初にサブコンポーネントを更新するか、ＳＣＭ１２０が最初に更新されるか、または満たされるべき別の順序制約があるかどうかを設定可能であってもよい。
ＳＣＭ１２０は、ファームウェア更新をすべてのＳＣＭサブコンポーネントにブロードキャストすることができ、またはＳＣＭは、特定のＳＣＭサブコンポーネントに対象とするファームウェア更新を送信することができる。
一実施形態では、ＦＵＰをＳＣＭ１２０に送信するためにデルタ更新が使用されてもよい。ＦＵＰをＳＣＭ１２０に送信するために圧縮が使用されてもよい。
一実施形態では、クラウド１３０は、ＦＵＰフォーマットまたは異なるシステムコンポーネントのための代替フォーマットを使用して、デバイス１１０および機器コンポーネント１４０などのＳＣＭ１２０以外のシステムコンポーネントにファームウェア更新パッケージを提供してもよい。一実施形態では、システムコンポーネントは、他のシステムコンポーネントのためのファームウェア更新の配信（および／またはルーティング）をサポートすることができる。例えば、デバイス１１０は、ＳＣＭ１２０を介して機器ファームウェア更新を配信してもよい。
一実施形態では、システムコンポーネントは、ファームウェア更新を認証し、追加的に暗号化／署名し、または変更されないままとし、あるいはそれらの任意の組み合わせを行って、その更新を他のコンポーネントに配信してもよい。一例として、デバイス１１０は、ＳＣＭ１２０にファームウェア更新パッケージを配信することができ、ＳＣＭ１２０は、ファームウェア更新パッケージに署名し、別のＳＣＭ１２０または取り付けられた機器コンポーネント１４０に配信してもよい。
初期製造の後、または工場リセットするよう命令されたことに応答して、ＳＣＭ１２０は工場リセットモードに入ることができる。工場リセットするように命令されたことに応答して、ＳＣＭ１２０は、工場（初期製造）状態に戻るために、そのＡＣＰ４００、他の設定記録、および暗号鍵を破棄してもよい。以下の識別子および暗号鍵の零以上が、工場リセットの結果として、リセットされなくてもよい。
１）SCM-ID識別子
２）SCM-Key鍵
３）Equipment-Key鍵
４）SCM-Equipment-Key鍵
一実施形態では、SCM-Key鍵は、工場リセットの結果としてＳＣＭ１２０によって循環されてもよい。SCM-Key鍵を変更することは、ＳＣＭ１２０を新しいＳＣＭ１２０としてシステム１００に提示させることになり、古いSCM-Key鍵を有するいずれのシステムコンポーネントもＳＣＭ１２０からのメッセージを暗号化または復号することをできなくなる。ＳＣＭ１２０が新規であるように見えるかもしれないが、ＳＣＭ１２０は、そのSCM-IDが変更されない（または、ＳＣＭ１２０を識別するための代替識別子が変更されないままである）限り、依然として同じＳＣＭ１２０として識別され得る。
一実施形態では、SCM-Keyが循環されず、攻撃者が、攻撃者の制御下にあるデバイス１１０を用いて、首尾よくクラウド１３０と接続して、クラウド１３０で認証できたとすると、攻撃者は、システムの一部に侵入するための情報を集めることができ、次いで、新しいオーナー登録要求を提出するかもしれない。このようにして、攻撃者は、ＳＣＭ１２０のオーナーシップを攻撃者のデバイス１１０に移転することをクラウド１３０に納得させることができるかもしれない。しかしながら、ＳＣＭ１２０へのおよび／またはＳＣＭ１２０からのコマンドを、送信および／または受信することを攻撃者のデバイス１１０に認可するＡＣＰ４００を含め、ＳＣＭ１２０は、クラウド１３０によって署名されなければならないいずれのメッセージも拒絶する。この場合、攻撃者のアクションは、明確に識別可能で可逆的であるかもしれない。
工場リセット時にSCM-Keyを変更することは、クラウド１３０が、同じSCM-Keyで既に登録されているＳＣＭ１２０の最初のオーナーデバイス１１０になるためのいかなる要求をも拒絶することを可能とすることができ、攻撃者が、新規のオーナー登録要求を使用して、ＳＣＭ１２０を「引き継ぐ」ことを試みることを防ぐための追加のメカニズムを提供する。代替の実施形態では、クラウド１３０は、新規のオーナー登録要求応答の一部としてＳＣＭ１２０に配信されるための新しいSCM-Key鍵を生成することができる。
一実施形態では、SCM-ID識別子は、工場リセットの結果としてＳＣＭ１２０によって循環されてもよい。SCM-ID識別子は、永続的な識別子であることが意図されてもよい。しかしながら、SCM-ID識別子を変更することにより、特にSCM-Keyも変更された場合に、システム１００が、ＳＣＭ１２０を同一の物理的部品として識別することができなくなる可能性がある。一実施形態では、クラウド１３０は、新規のオーナー登録要求応答の一部としてＳＣＭ１２０に配信されるための新しいSCM-ID識別子を生成することができる。一実施形態では、SCM-IDが循環されてもよく、クラウド１３０はそのＳＣＭ１２０のSCM-IDの履歴を保持してもよい。
一実施形態では、Equipment-Key鍵が、工場リセットの結果としてＳＣＭ１２０によってクリアされてもよい。SCM-Equipmen-Key鍵は、一実施形態による工場リセットの結果としてＳＣＭ１２０によって循環されてもよい。機器鍵をクリアおよび／または変更することにより、ＳＣＭ１２０は、ＳＣＭ１２０に結合された、またはおそらくは取り付けられた機器コンポーネント１４０と通信することができなくなる可能性がある。一実施形態では、クラウド１３０が、新規のオーナー登録要求応答の一部としてＳＣＭ１２０に配信されるための新しいSCM-Equipment-Key鍵を生成することができる。
工場リセットされたＳＣＭ１２０に関連付けられ、ＳＣＭ１２０に対する認可を有する１つ以上のデバイス１１０は、ＳＣＭ１２０が工場リセットされたといういかなる通知を受信しなくてもよい。工場リセットされたＳＣＭ１２０のSCM-ID識別子またはSCM-Key鍵の少なくとも１つが変更されない場合、クラウド１３０は、ＳＣＭ１２０に対する新しいオーナー登録要求に応じて自動的にユーザー１０のための認可を取り消してもよい。
ＳＣＭ１２０は、工場リセットモードでその製造プロセスを完了してもよいが、製造プロセスは、Equipment-Key鍵または他の設定データなど、特定の届け先に固有の設定をロードすることができる。ＳＣＭ１２０は、ＳＣＭ１２０が結合される機器コンポーネント１４０の製造プロセスに含まれてもよい。機器製造プロセスの間、ＳＣＭ１２０は工場リセットモードから抜けてもよく、製造装置がＳＣＭ１２０のオーナーデバイス１１０として登録され得る。機器製造プロセスの終了時に、ＳＣＭ１２０のオーナーシップが別のデバイス１１０に移転されてもよいし、またはＳＣＭが工場リセットされてもよい。他のデバイス１１０は、ＯＥＭ、再販業者、またはレンタル業者に関連付けられてもよい。
製造のこの段階では、ＳＣＭ１２０は、販売および配送プロセスの間に、他のデバイス１１０に移転され、および／または工場リセットされてもよい。ＳＣＭ１２０は、それが結合される機器コンポーネント１４０によって工場リセットするよう命令されることができる。機器コンポーネント１４０がＳＣＭ１２０の工場リセットの適切性を判断する基準は、ＯＥＭシステムの全体的なセキュリティにとって有用であり得る。例えば、機器コンポーネント１４０は、工場リセットを要求するユーザー１０がそれを行うことを認可されていることを検証することができる。認可は、機器コンポーネント１４０のオーナーシップまたは機器コンポーネント１４０の物理的な所有などの１つ以上の要因に基づくことができる。
一実施形態では、ＳＣＭ１２０は、クラウド１３０によって、１つまたは複数のシステムコンポーネントを介して直接的または間接的に、工場リセットするように命令されてもよい。ＳＣＭ１２０がクラウド１３０に接続されている場合、工場リセットする直接命令が受信されえる。工場リセットする間接命令は、クラウド１３０からデバイス１１０へＳＣＭ１２０へ、またはクラウド１３０から機器コンポーネント１４０へＳＣＭ１２０へなど、１つ以上のシステムコンポーネントを介して、ＡＣＰ４００と同様に受信されてもよい。
一実施形態では、オーナーデバイス１１０は、ＳＣＭ１２０に工場リセットするように命令することができる。あるいは、任意のデバイス１１０が、ＳＣＭ１２０に工場リセットするように命令してもよい。追加的に、または代替的に、任意のシステムコンポーネント（ＳＣＭ１２０自体を含む）が、ユーザーがＳＣＭ１２０上のボタンを押すなどして、ＳＣＭ１２０に工場リセットするように命令してもよい。
ＳＣＭ１２０が工場リセットモードにあるとき、そのＳＣＭ１２０に対するオーナーデバイス１１０は存在しないが、ＳＣＭ１２０は新しいオーナー開始要求を受け入れることができる。新規オーナー開始要求は、ＳＣＭ１２０に対する最初のオーナーデバイス１１０を確立することができ、ＳＣＭ１２０のための最初のＡＣＰ４００の生成及び転送をもたらすことができ、ＳＣＭ１２０にクラウドキー（例えば、Cloud-SCM-Key鍵、Cloud-SCM-Approval-Key、およびACP-Version-Key鍵）と認可、並びに他の設定データを提供する。ＳＣＭ１２０の登録および新しいオーナーの確立は、以下のステップのうちの１つまたは複数に従って実施されることができる。
１）デバイス１１０は、新規オーナー開始要求をＳＣＭ１２０に送信することができる。
２）ＳＣＭ１２０は、自身のSCM-Key（公開）鍵およびSCM-ID識別子をデバイス１１０に送信することができる。
３）デバイス１１０は、新しいDevice-SCM-Key公開／非公開鍵のペアを生成することができる。
４）デバイス１１０は、新規オーナー登録要求をクラウド１３０に送信することができる。デバイス１１０は、新規オーナー登録要求の一部として、以下のいくつかまたはすべてをクラウド１３０に送信することができる。
・Cloud-User-ID識別子
・Device-SCM-Key（公開）鍵
・SCM-Key（公開）鍵
・SCM-ID識別子
・Device-ID識別子
・Device-SCM-ID識別子
・その他（例えば、イーサネットMAC、BLE UUID、APNS/GCMトークン）
５）クラウド１３０は、デバイス１１０を登録し、以下の１つ以上を生成することができる。
・新しいCloud-SCM-Key公開／非公開鍵（例えば、Cloud-SCM-KeyやCloud-SCM-Approval-Key）を生成する。
・新しいACP-Version-Key公開／非公開鍵を生成する
・新しいUser-SCM-Key公開／非公開鍵を生成する
・オーナーデバイス認可を生成する
・最初のＡＣＰ４００を生成し、それを配信する
６）クラウド１３０は、Cloud-SCM-Key（公開）鍵をデバイス１１０に送信することができる。
７）クラウド１３０は、（最初のＡＣＰを含む）ＡＣＰコンテナ４１０をデバイス１１０に送信することができる。
８）デバイス１１０は、ＡＣＰ４００をＳＣＭ１２０に転送することができる。
９）ＳＣＭ１２０は、ＡＣＰ４００を受け入れ、工場リセットモードを抜けることができる。
ＳＣＭ１２０が、その最初のＡＣＰ４００を受け入れ、工場リセットモードを抜けた後、追加のデバイス１１０に対する認可が通常のように追加されてもよい。
一実施形態では、SCM-IDは、安全でない接続を介して取得されなくともよく、従って、SCM-Keyが安全な接続を確立するために使用されてもよい。安全な接続の確立は、未知のフェーズから始まるデバイス／ＳＣＭ接続確立プロセスと類似していてもよく、その後、デバイス１１０は、安全な接続を使用してＳＣＭからSCM-IDを要求することができる。
ＸＶＩ．デバイス／クラウド通信−サーバー側認証
一実施形態では、デバイス１１０とクラウド１３０との間の通信チャネルが、証明書およびクラウドセッショントークンに基づくサーバー側（クラウド）認証を備えた、ＴＬＳ１．２以上を使用するなどして、保護されてもよい。
システム１００内のアプリケーション層および／またはアプリケーションプログラミングインターフェースは、HTTPS、Googleプロトコルバッファ、AMQP、MQQT、CoAP、TCP、およびUDPなどの、関連する標準技術の任意の組み合わせに基づくことができる。一実施形態では、各デバイス１１０はそれ自身の一意のクライアント証明書を有してもよく、この一意のクライアント証明書に基づいてＴＬＳ相互認証が実行されてもよい。一実施形態では、ＴＬＳの代わりにＤＴＬＳが利用されてもよい。一実施形態では、生の非対称暗号がＴＬＳの代わりに使用されてもよい。一実施形態では、対称暗号がＴＬＳの代わりに使用されてもよい。一実施形態では、安全な通信チャネルは使用されない。デバイス１１０が特定のＳＣＭのためにクラウド１３０から受信するメッセージは、ＳＣＭの対応するCloud-SCM-Key鍵によって署名されてもよい。
ＸＶＩＩ．クラウド／クラウド通信−相互認証
一実施形態では、クラウド１３０内（クラウド内部）および／またはクラウドシステム間で利用される通信チャネルは、証明書を使用しす相互認証を備えたＴＬＳ１．２以上を使用して、保護されてもよい。
アプリケーション層および／またはアプリケーションプログラミングインターフェースは、HTTPS、Googleプロトコルバッファ、AMQP、MQQT、CoAP、TCP、およびUDPなどの、関連する標準技術の任意の組み合わせに基づくことができる。一実施形態では、ＴＬＳの代わりにＤＴＬＳが利用されてもよい。一実施形態では、生の非対称暗号がＴＬＳの代わりに使用されてもよい。一実施形態では、対称暗号がＴＬＳの代わりに使用されてもよい。一実施形態では、安全な通信チャネルは使用されない。
ＸＶＩＩＩ．機器／ＳＣＭ通信
機器コンポーネント１４０とＳＣＭ１２０との間の通信チャネルは、通信を保護するために生の非対称暗号を使用することができる。非対称暗号は、SCM-Equipment-Keyおよび／またはEquipment-Keyに基づくことができる。
アプリケーション層および／またはアプリケーションプログラミングインターフェースは、例えば、Googleプロトコルバッファ、CoAP、TCP、UDP、CAN、UART（おそらくカスタム）、SPI、およびI2Cを含む、関連する標準技術の任意の組み合わせに基づくことができる。一実施形態では、ＴＬＳは、証明書または非対称暗号を備えた、相互またはサーバー側認証とともに使用されてもよい。一実施形態では、証明書または非対称暗号とともにＤＴＬＳが使用されてもよい。一実施形態では、対称暗号が使用されてもよい。一実施形態では、安全な通信チャネルは使用されない。
本明細書で説明するように、ＳＣＭ１２０は、別のＳＣＭ１２０のための機器であってもよく、ＳＣＭ１２０ごとに１つまたは複数のＳＣＭ間通信チャネルを確立する。このような構成は、接続の共有、認可、および／または、ＳＣＭ間の認証アクティビティ、負荷平衡（例えば、通信接続またはコンピューティングリソース）、デバイスまたは他のシステムコンポーネント（例えば、他の機器）の冗長／多因子検証／認証、冗長／ロックステップシステムの実行および検証（例えば、クロスチェック）、およびシステム制御能力の拡張（例えば、より多くの入力／出力ポートまたは通信範囲の改善）の１つ以上を容易にすることができる。
ＸＥＸ．時間配信
１つ以上のシステムコンポーネントは、安全な接続を確立するため、または情報を検証するため、またはその両方を行うために、現在の時刻を利用することができる。現在の時刻は、信頼できるソースから安全に配信され、または取得されえる。一実施形態では、ＳＣＭ１２０は、ＳＣＭ１２０が結合されている機器コンポーネント１４０から現在時刻を取得してもよい。一実施形態では、ＳＣＭ１２０は、デバイス１１０から（おそらく安全な通信チャネルを使用しまたは使用せずに）現在時刻を取得してもよい。一実施形態では、ＳＣＭ１２０は、クラウド１３０から現在時刻を取得してもよい。一実施形態では、デバイス１１０は、クラウド１３０から現在時刻を取得してもよい。
ＸＸ．ブロックファン権利管理
一実施形態では、システム１００は、ブロックファンベースの権利管理システムを利用してもよい。ブロックファン（Blockfan）は、（各ノードが最大１つの親と最大1つの子を有することができる）従来のブロックチェーンとは対照的に、各ノードがツリーに「ファン」することができる、ブロックチェーンベースの権利管理システムとして識別される。ブロックファンのツリー構造は、親の許可を介して付与されたピアの権利を管理および検証するために使用されてもよい。例えば、デバイス１１０は、ＳＣＭ１２０にアクセスする権利を付与され（親の許可）、その権利のコンテキストの下で、いくつかのコマンドを発行する権利が付与される（ピアの許可）。
ブロックファンのチェーン構造は、時間の経過とともに許可を順序付けるために利用されてもよい。一実施形態では、ブロックファンのノード（トークン付与が多重に使用されなかったことを保証するために、許可ノードの兄弟ノードを含む）のハッシュおよび／または署名を検証するために、Merkleツリーが使用されてもよい。したがって、Merkleツリーは、権利管理システム全体の完全性、妥当性および正確性を検証するために使用されえる。ブロックファンベースの権利管理システムは、トークン付与を定義することができ、一回使用権が後の使用のために付与される。例えば、将来のある時点で、特定のデバイス１１０が、特定のＳＣＭ１２０のオーナーシップ取得したいことがある。ブロックファンは元帳を形成することができる。言い換えれば、権利は決して削除されず、すべての権利は１つまたは複数の付与根源に遡ることができる。権利が付与根源まで追跡できない場合、これは検証の失敗を示すものとみなされる。
図１５の図示された実施形態による権利管理システムにおける権利は、３つ構成要素に分けて定義されえる。
１）１５０１で指定される、アクションを行う権利。
２）１５０２で指定される、アクションを実行する権利を付与する権利。
３）１５０３で指定される、アクションを実行する権利を付与する権利を付与する権利。
・権利を付与する権利を有することは、必ずしもその付与者が自分自身で行動を取ることができるということを意味するものではないことに留意されたい。
・この権利は、この権利を他のだれかに付与する権利を含む場合がある。
一実施形態では、付与者は自分自身に権利を割り当てることはできないし、権利付与を許可する権利を付与する権利を付与された付与者は、自分自身にその認可を付与することもできない。
例えば、ＳＣＭ１２０のオーナー１０は、別のユーザー１０に、特定のコマンドを発行する権利を付与する権利を与えることができる。その別のユーザー１０は特定のコマンドを発行する権利を他のユーザー１０に与えることができるが、その別のユーザー１０は、別のユーザーに、他のユーザー１０が特定のコマンドを発行することを許可する権利を与えることはできない。図示の実施形態では、ＳＣＭ１２０のオーナーのみがこれを行うことができる。
一実施形態では、すべての付与は、以下の情報を含むことができる。
・アクション
・コンテキスト
・被付与者
・被付与者の公開鍵のコピー
・付与されたこと
・開始日
・失効日
・親付与ＥＤ
・チェック値
この情報の集合は、付与者の非公開鍵で暗号化されてもよく、付与者のＥＤ、被付与者のＩＤ、親付与のＥＤ、アクション、コンテキスト、付与されたこと、開始日、および終了日を含んでもよい。本開示は、特定された情報のすべてを有する付与に限定されず、追加の情報が含まれてもよく、特定された情報の１つ以上が存在しなくてもよいことを理解されたい。
一実施形態では、取り消された権利のテーブルに対する結合を介して、各権利または付与は、
・取り消された親ＥＤ
・取り消された値
も含むことができる。
この集合は、取消者の非公開鍵で暗号化されてもよく、取消者のＥＤ、取り消されたもののＥＤ、取消許可のＥＤ、アクション、コンテキスト、および取り消されたステータスを含んでもよい。
付与の発行に署名して日付を付けることにより、すべての権利の付与を、システム１００の始まりまで遡ることが可能になり、処理中のシステム１００内のデータの検証が可能になる。
以下に列挙する権利のタイプは、本開示の一実施形態に従って利用することができる。付与は、アクションによって、異なるモデルを持つかもしれないことに留意されたい。
・従属。権利を与える付与者の権利が失効すると、従属する権利が失効することがある。このタイプの権利は、主にＳＣＭ１２０のための操作権に使用されることができ、ＳＣＭ１２０が移転されるとき、またはＳＣＭ１２０のオーナーが外されたとき、そのようなすべての従属する権利は取り消すことができる。
・独立。独立した権利は、付与の時点の後で、許可を与える付与者の権利が有効であることを必要としないことがある。付与の時点で、付与者の権利が有効であることを保証するために、追跡が、依然としてシステム１００を通じて可能とされてもよい。このタイプの権利は、管理タスクのために組織内で有用となりえる。
・トークン。一実施形態では、トークン付与は一度しか使用できない。一実施形態では、トークン付与は、副作用なしに使用することができない、システム１００内の唯一の権利である。トークン権利の使用は、兄弟関係のトークンを無効にするかもしれない。トークン権利は、ＳＣＭ１２０の移転のために使用されてもよい。
・不滅。不滅である権利は、ＳＣＭ１２０の寿命まで付与されることがあり、ＳＣＭ１２０のオーナーシップを超越する可能性がある。不滅である権利は、もし付与するとしても、ＯＥＭに付与するだけとすることができ、不滅の権利によって参照されるＳＣＭ１２０に対して作成されるすべての設定に含められる権利を表すことができる。
一実施形態では、ブロックファンベースの権利管理システムが使用されて、このシステム１００およびセキュリティモデル（そこでは、Device-Rights-Keyはブロックファン内の対応するノードを参照する）内で使用されるクラウド１３０内に権利管理サービスを作成することができる。
ＸＸＩ．ブラックリスト
一実施形態では、システム１００は、起こりうる脆弱性に煩わされていると考えることができる。通信する方法がない場合、更新は配信されない可能性がある。システム１００の分散される性質は、システム１００を他のシステム１００よりも接続性の欠如に対してより寛容にすることができる。しかしながら、システム１００は、オンラインシステムでは提供されない可能性が高い、この問題に対する実質的に絶対的な解決策を提供しない可能性がある。
認可および設定の更新は、他のシステムコンポーネント（例えば、デバイス１１０）を介してＳＣＭ１２０に配信することができる。システムコンポーネントがＳＣＭ１２０と通信できない場合、またはそれ自体の接続性の欠如によって更新を取得できない場合、システムコンポーネントはＳＣＭ１２０に更新を配信しない可能性がある。意図しないまたは意図的な接続性の欠如のために適時に更新を受け取ることができないことは、認可の取り消しに関して特に懸念される。
１人のユーザーＡは、ユーザーＢに属するデバイス１１０のＳＣＭ１２０の認可を取り消すが、ユーザーＢは、ＳＣＭ１２０が取り付けられた機器コンポーネント１４０へのアクセスを継続したいといったシナリオを考える（すなわち、「クレイジーエックス」シナリオ）。このシナリオでは、ユーザーＢが自分のデバイス１１０上の無線を無効にすると、そのデバイス１１０は、その認可を取り消す更新されたＡＣＰ４００をＳＣＭ１２０に配信することができず、したがって、ユーザーＢは、ＳＣＭ１２０に関連付けられた機器コンポーネント１４０を使用し続けることができる。システム１００の分散された性質は、ＳＣＭ１２０に対する認可を有する任意のデバイス１１０が、更新されたＡＣＰ４００を配信することができるので、このシーケンスを回避するのを助けるかもしれない。しかしながら、このシナリオでは、ユーザーＡは、唯一の近くにある認可されたデバイス１１０を持ち、ユーザーＢのデバイス１１０はオフラインであるが、ユーザーＡはＳＣＭ１２０および取り付けられた機器コンポーネント１４０にアクセスする。
機器コンポーネント１４０（および、代理でユーザー１０）が認可をローカルに取り消す手段を提供するために、ＳＣＭ１２０は、認可ブラックリスト（ＳＣＭブラックリスト）を管理することができる。機器コンポーネント１４０が適切なユーザーインターフェースを有すると仮定すると、機器コンポーネント１４０は、ユーザーインターフェースを使用して、ユーザーＡに有効な認可のリストを提示することができ、ユーザーＡはユーザーＢの認可をＳＣＭ１２０のブラックリストに追加することができ、その時点で、ユーザーＢの認可がローカルに取り消され、ユーザーＢは、ユーザーＢに関連付けられたデバイス１１０を使用して機器コンポーネント１４０にアクセスできなくなる。
ＳＣＭ１２０のブラックリストの各エントリは、認証と一意のBlacklist-Item-EDとのペアであってもよい。一実施形態では、Device-IDまたはDevice-SCM-IDがBlacklist-Item-EDとして使用されてもよい。
デバイス１１０が、（少なくとも安全のフェーズで、デバイス／ＳＣＭ接続確立プロセスごとに）ＳＣＭ１２０と安全な通信リンクを確立する場合、ＳＣＭ１２０はブラックリストパッケージをデバイス１１０に送信してもよい。ＳＣＭ１２０は、更新されたＡＣＰ４００を処理した後、デバイス１１０が接続した後のある時点、またはＳＣＭ１２０のブラックリストが変更されたとき、ブラックリストパッケージをデバイス１１０に送信してもよい。
ブラックリストパッケージは、ブラックリストパッケージが多層暗号化パッケージであってもよいという点でＡＣＰコンテナ４１０と類似する。ブラックリストパッケージは、ＳＣＭ１２０の現在のＡＣＰバージョンを含んでもよくｋ、SCM-Key（非公開）鍵で署名され、暗号化されてもよく、次いで、Cloud-SCM-Key（公開）鍵で署名され、暗号化されてもよい。一実施形態では、ＳＣＭ１２０は、ブラックリストパッケージを、任意の通信リンクを介して別のＳＣＭ１２０または別のシステムコンポーネントに送信してもよい。一実施形態では、ブラックリストパッケージはまた、ACP-Package-Version(公開)鍵で署名され、暗号化されてもよい。一実施形態では、機器コンポーネント１４０以外のシステムコンポーネントは、有効な認可のリストを受信し、ブラックリストに登録された認可をＳＣＭ１２０に送信してもよい。
デバイス１１０がブラックリストパッケージを受信したとき、デバイス１１０は、ブラックリストパッケージを変更せずにクラウド１３０に送信してもよい（デバイス１１０はブラックリストパッケージを復号できないかもしれない）。クラウド１３０は、以下の、ブラックリストパッケージを検証する、ブラックリストパッケージに記載された取り消しを適用する、および、更新されたＡＣＰ４００が承認のために利用可能であることをＳＣＭ１２０のオーナーデバイス１１０に通知する、のうちの１つ以上を実行してもよい。ＡＣＰ４００は、設定がＳＣＭ１２０に配信されたとの確認をクラウド１３０が最後に受信してから処理されたBlacklist-Item-IDを含むことができる。例えば、ブラックリストの内容が処理されたという確認が受信されるまでＡＣＰブラックリストは増加し、その時点で、ブラックリストは減少されるかもしれない。更新されたＡＣＰ４００がオーナー１０に受け入れられない場合、オーナー１０は、ＡＣＰ４００が承認を満たすまで、ＡＣＰ４００を修正してもよい。
デバイス１１０が更新されたＡＣＰ４００をＳＣＭ１２０に配信したとき、ＳＣＭ１２０は、ＳＣＭ１２０ブラックリストとＡＣＰ４００ブラックリストの両方に存在するBlacklist-Item-IDを除去して、ＡＣＰ４００ブラックリストを処理してもよい。ＡＣＰ４００ブラックリスト内のBlacklist-Item-EDの存在は、Blacklist-Item-IDをＡＣＰ４００に含めるとのオーナーデバイス１１０の決定を表すかもしれない（オーナー１０が対応する認可を保持または取り消すことを決定したかどうか）。
ＸＸＩＩ．セントラルシステムログ
一実施形態では、システム１００または特定のシステムコンポーネント（ユーザー１０を含む）に対する攻撃の検出および分析、あるいは、システムの性能および動作の分析を支援できる情報を提供するため、クラウド１３０は、セントラルシステムログとして定義される安全な、集中システムログを管理してもよく、それは、システム１００の全部または一部のコンポーネントにわたって発生したイベントからの情報を格納（すなわち、ログ）することができる。そのようなイベントは、クラウド１３０自体に発生するイベントを含んでもよい。
各システムコンポーネントは、システムコンポーネントが遭遇したローカルイベントに関する情報を格納（すなわち、ログ）することが可能なシステムログを保持してもよい。コンポーネントのシステムログに格納されている情報、およびシステムログが格納されている場所は、設定可能（実装時、設定時、または実行時）であってもよく、システム状態によって変化してもよい。その変化は、別のシステムコンポーネントによってそうするよう命令された場合など、自動的におよび／または手動で行われてもよい。
システムコンポーネントは、セントラルシステムログ、またはＲＡＭ、ＲＯＭ、他のシステムコンポーネント、または１つ以上の通信リンク、診断／デバッグポート、および／または物理的媒体へ、イベントを、リアルタイム、バッチ、または配信可能なシステムログパッケージを介してログしてもよい。システムログパッケージは、クラウド１３０に送信するために他のシステムコンポーネント（例えば、デバイス１１０、機器１４０、ＳＣＭ１２０など）に配信されてもよい（例えば、ＳＣＭ１２０は、クラウドに送信するため、ＳＣＭ１２０システムログパッケージをデバイスに配信してもよい）。あるいは、システムログパッケージは、ブラックリストパッケージと同様に、クラウド１３０に直接送信されてもよい。システムログパッケージが暗号化される方法により、システムログパッケージはいずれかの通信チャネルを介して配信されてもよい。一実施形態におけるリアルタイムおよびバッチログは、安全な通信リンクを介してクラウド１３０送信されるだけであってもよい。一実施形態では、システムログパッケージは、安全な通信チャネルを介してのみ送信されてもよい。
一実施形態では、セントラルシステムログは存在せず、代わりに各システムコンポーネントがそれ自身のシステムログを作成し、管理してもよい。

ＸＸＩＩＩ．ユースケースの例
本開示の１つまたは複数の実施形態は、様々なアプリケーションに関連して実施することができ、本開示は本明細書に記載の特定のアプリケーションに限定されないことを理解されたい。開示の目的のために、マイクロロケーションシステムと組み合わされ得るユースケースを含む、いくつかのユースケースまたはアプリケーションは、以下のように特定される。
１）自動車
・乗員／軽トラック
・バス
・長距離輸送
・地域配送
・万能／特化
・ＲＶ
・ライドシェア
・レンタル
・ディーラー
・共用アクセス
２）重機（ブルドーザー）
３）農業機械（ジョン・ディア、クボタ）
４）オートバイ（および四輪車および三輪車およびスノーモービル）
５）飛行機
・一般航空
・商業
・軍事
６）船舶
・パーソナルウォータークラフト
・ボート（住宅）／ヨット
・商業
・貨物船
７）ドアロック
・居住＆商業
・ホテル／レンタル
・安全で制御されたアクセス
８）オフィス機器およびオートメーション
・会議室の設備
・安全なボタン（別個の特許が用意されている）
・オートメーション
９）オフィス家具
・スペース利用
・オープンデスク
・スペースのカスタマイズ
・移動する機器
・調節可能な椅子
・ブロディチェア
・ディスプレイ
１０）会議のイベント
・セッションへの入場（タグのスキャンに対して）
・私の座席はどこ／私は正しい座席にいるか
１１）テーマパーク（ディズニー、シックスフラッグス）
１２）病院
・部屋及び設備のアクセス
・誰がどの部屋にいるか
・ＲＴＬＳ（リアルタイム位置情報システム）−ものを追跡
1３）小売（店舗）
1４）産業機器／製造オートメーション（大きくて高価なもの）
1５）自動販売機
1６）レストラン
・給仕人／マネージャ
・どの食卓がどの食べ物を注文したか
・テーブルからの注文、あなたのものを入手
1７）コンピュータモニター／ラップトップ
本明細書に記載される１つまたは複数の実施形態は、従来のシステムに対していくつかの利点を提供する。
「垂直」、「水平」、「上」、「下」、「上方」、「下方」、「内側」、「内側へ」、「外側」および「外側へ」などの方向を示す用語が、図示された実施形態の方向に基づいて本発明を説明するのを助けるために使用される。方向を示す用語の使用が、本発明をいずれかの特定の方向に限定すると解釈されるべきではない。
上記の説明は、本発明の現在の実施形態の説明である。均等論を含む特許法の原則に従って解釈されるべき、添付の特許請求の範囲に定義される本発明の精神および広範な態様から逸脱することなく、様々な変更や変化がなされることができる。本開示は、説明の目的のために提示されたものであり、本発明のすべての実施形態の包括的な説明として解釈されるべきではなく、または請求の範囲をこれらの実施形態に関連して図示または説明される特定の要素に限定するものでもない。例えば、限定するものではないが、記載された発明の任意の個々の要素は、実質的に同様の機能を提供するか、さもなければ適切な動作を提供する代替要素によって置き換えることができる。これには、例えば、当業者に現在知られているような、現在知られている代替要素、および開発時に当業者が代替要素として認識するような、将来的に開発される代替要素が含まれる。さらに、開示された実施形態は、共に説明され、協力して利点の集まりを提供する複数の特徴を含む。本発明は、発行された特許請求の範囲に明示的に記載されている場合を除き、これらの特徴の全てを含む、または、記載された全ての利点を提供する実施形態のみに限定されない。例えば、冠詞「a」、「an」、「the」または「said」を使用する、単数形での請求項要素を参照することは、その要素を単数に限定するものとして解釈されるべきではない。「Ｘ、ＹおよびＺのうちの少なくとも１つ」としての請求項要素に対する言及は、個々にＸ、ＹまたはＺのいずれか１つ、およびＸ、ＹおよびＺの任意の組み合わせ、例えばＸ、Ｙ、Ｚ；Ｘ、Ｙ；Ｘ、Ｚ：Ｙ、Ｚを含むことを意味する。

Claims (18)

  1. 第１のデバイスから第２のデバイスへ通信するためのシステムであって、
    前記第１のデバイスは、オンラインモードでネットワークサーバーと無線通信するように構成され、前記第１のデバイスは、ネットワークサーバーから認可設定情報を取得するように構成され、前記認可設定情報は、前記第１のデバイスが前記第２のデバイスと通信するための認可に関係し、前記認可設定情報は、前記第２のデバイスと関連付られた第１の鍵によって暗号化されたデータを含み、
    前記第２のデバイスは、車両用の機器コンポーネントに結合され、前記第２のデバイスは前記機器コンポーネントと通信するように構成され、
    前記第２のデバイスは、前記第１のデバイスと前記第２のデバイスのいずれもネットワークサーバーと効果的に通信することができないオフラインモードにおいて、前記第１のデバイスと無線通信するように構成され、
    前記第１のデバイスおよび前記第２のデバイスは、通信を交換するための通信リンクを確立するように構成され、前記第２のデバイスは、通信リンクを確立する前は、前記第２のデバイスに対する前記第１のデバイスの認証および前記第１のデバイスの認可の少なくとも１つに関係する認可設定情報を前記第１のデバイスが取得したことを示す情報を受信しておらず、
    前記第１のデバイスは、前記通信リンクを介して、認可設定情報を前記第２のデバイスに通信するように構成され、前記第２のデバイスは、前記認可設定情報に基づいて、前記第１のデバイスのアイデンティティを認証し、および、前記第１のデバイスが前記第２のデバイスに対して認可されているかを判定するシステム。
  2. 前記第１のデバイスと前記第２のデバイスとの間に確立される前記通信リンクは、前記第２のデバイスが前記第１のデバイスの前記アイデンティティを認証するチャレンジレスポンス認証プロセスに関与する請求項１に記載のシステム。
  3. 前記第２のデバイスは、前記第１の鍵に関連付けられた第２の鍵を用いて、前記認可設定情報の前記データの復号に少なくとも部分的に基づいて、ネットワークサーバーから発行された前記認可設定情報を認証し、前記第１の鍵は非公開鍵であり、前記第２の鍵は公開鍵である請求項１に記載のシステム。
  4. 前記非公開鍵および前記公開鍵は、前記第１のデバイスと前記第２のデバイスとの間の通信に先立って、ネットワークサーバーと前記第２のデバイスとの間に確立される請求項３に記載のシステム。
  5. 前記認可設定情報は、前記第１のデバイスに関連付けられた公開鍵を含み、前記第１のデバイスは、前記公開鍵に関連付けられた非公開鍵を保存し、前記第２のデバイスは、前記通信リンクを介して受信されたデータを前記公開鍵を用いて復号することに少なくとも部分的に基づいて、前記第１のデバイスの前記アイデンティティを認証する請求項１に記載のシステム。
  6. 前記第１のデバイスは、前記通信リンクを介して前記第２のデバイスから受信されたデータを復号することに基づいて、前記第２のデバイスのアイデンティティを認証する請求項５に記載のシステム。
  7. 前記認可設定情報は、前記第２のデバイスに対する１つ以上のコマンドについての前記第１のデバイスの１つ以上の認可に関係する認可データを含み、前記認可データは暗号化され、前記第２のデバイスのみが前記認可データを復号することができる請求項１に記載のシステム。
  8. 前記認可設定情報は、複数の層を有する積層パッケージであり、各層は、非対称鍵のペアの１つの鍵に従って暗号化される請求項１に記載のシステム。
  9. 前記認可設定情報は、認証情報を含む請求項８に記載のシステム。
  10. 前記認可設定情報の１つの層は、前記第２のデバイスの通信および動作の少なくとも１つに関連する１つ以上の認可に関係する認可データを含む請求項８に記載のシステム。
  11. 前記第２のデバイスのみが前記複数の層の全てを復号することができる請求項１０に記載のシステム。
  12. 前記複数の層の中のオーナー暗号化層は、前記第２のデバイスの動作に権限を持つものとして確立される、前記第２のデバイスに関連付けられるオーナーデバイスによって暗号化され、前記オーナー暗号化層の暗号化は、前記オーナーデバイスが、前記層に含まれる認可データを認可したことを示す請求項１０に記載のシステム。
  13. 機器コンポーネントと通信するための制御ユニットであって、
    遠隔デバイスと無線で通信するように動作可能な通信インターフェースと、
    遠隔デバイスの認証および認可に関係する１つ以上の暗号鍵を記憶するように構成されるメモリと、
    機器コンポーネントと通信するように動作可能な機器インターフェースと、
    通信インターフェースを介して遠隔デバイスと通信リンクを確立するように構成されるコントローラと、を備え
    コントローラは、遠隔デバイスから認可設定情報を受信するように構成され、認可設定情報は、暗号化された認可データを含み、コントローラのみが認可設定情報から認可データを復号することができ、そして、
    認可データに少なくとも部分的に基づいて、コントローラは遠隔デバイスのアイデンティティを認証し、遠隔デバイスが認可されているかを判定し、
    認可設定情報は、複数の層を有する積層パッケージであり、各層は、非対称鍵のペアの１つの鍵に従って暗号化される制御ユニット。
  14. 前記認可設定情報は、認証情報を含む請求項１３に記載の制御ユニット。
  15. 前記認可設定情報の１つの層は認可データを含み、認可データは、通信および動作の少なくとも１つに関連する１つ以上の認可に関係する請求項１３に記載の制御ユニット。
  16. 前記制御ユニットのみが前記複数の層の全てを復号することができる請求項１３に記載の制御ユニット。
  17. 前記複数の層の中のオーナー暗号化層は、制御ユニットの動作に権限を持つものとして確立される、制御ユニットに関連付けられるオーナーデバイスによって暗号化され、前記オーナー暗号化層の暗号化は、オーナーデバイスが、層に含まれる認可データを認可したことを示す請求項１３に記載の制御ユニット。
  18. 第１のデバイスと第２のデバイスとの間の通信方法であって、
    第１のデバイスにおいて、ネットワークサーバーから認可設定情報を取得すること、認可設定情報は、第２のデバイスに関連付けられた第１の鍵によって暗号化されたデータを含み、
    第１のデバイスと第２のデバイスとの間で通信を交換するための通信リンクを確立すること、第２のデバイスは、通信リンクを確立する前は、第１のデバイスが認可設定情報を取得したことを示す情報を受信しておらず、
    認可設定情報を第２のデバイスに提供すること、
    第１のデバイスが第２のデバイスと通信するための１つ以上の認可に関係する認可データを取得するために、第２のデバイスにおいて、認可設定情報を復号すること、
    認可設定情報から得られた認可データに基づいて、第１のデバイスのアイデンティティを認証すること、
    第１のデバイスが第２のデバイスに対して認可されているかを判定すること、そして、
    認可設定情報の少なくとも一部を、第２のデバイスとネットワークサーバーとの間に確立された第２の鍵を用いて暗号化することを備え、
    認可設定情報は認証情報を含む方法。
JP2019521454A 2016-10-27 2017-10-27 デバイスを認証および認可するためのシステムおよび方法 Active JP6888673B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201662413778P 2016-10-27 2016-10-27
US201662413966P 2016-10-27 2016-10-27
US62/413,966 2016-10-27
US62/413,778 2016-10-27
PCT/US2017/058792 WO2018081583A1 (en) 2016-10-27 2017-10-27 System and method for authenticating and authorizing devices

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2020191808A Division JP2021040330A (ja) 2016-10-27 2020-11-18 デバイスを認証および認可するためのシステムおよび方法

Publications (2)

Publication Number Publication Date
JP2019536329A JP2019536329A (ja) 2019-12-12
JP6888673B2 true JP6888673B2 (ja) 2021-06-16

Family

ID=62021981

Family Applications (3)

Application Number Title Priority Date Filing Date
JP2019521454A Active JP6888673B2 (ja) 2016-10-27 2017-10-27 デバイスを認証および認可するためのシステムおよび方法
JP2020191808A Pending JP2021040330A (ja) 2016-10-27 2020-11-18 デバイスを認証および認可するためのシステムおよび方法
JP2022211220A Pending JP2023036897A (ja) 2016-10-27 2022-12-28 デバイスを認証および認可するためのシステムおよび方法

Family Applications After (2)

Application Number Title Priority Date Filing Date
JP2020191808A Pending JP2021040330A (ja) 2016-10-27 2020-11-18 デバイスを認証および認可するためのシステムおよび方法
JP2022211220A Pending JP2023036897A (ja) 2016-10-27 2022-12-28 デバイスを認証および認可するためのシステムおよび方法

Country Status (5)

Country Link
US (3) US10313134B2 (ja)
EP (1) EP3532971A4 (ja)
JP (3) JP6888673B2 (ja)
CN (1) CN109891416A (ja)
WO (1) WO2018081583A1 (ja)

Families Citing this family (115)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9417922B2 (en) 2012-12-03 2016-08-16 Cutting Edge Consulting Associates, Inc. Systems and methods for protecting an identity in network communications
US10277616B2 (en) 2014-09-25 2019-04-30 Vigilant Ip Holdings Llc Secure digital traffic analysis
US10169614B2 (en) 2016-11-17 2019-01-01 International Business Machines Corporation Container update system
CN113490147A (zh) 2016-12-14 2021-10-08 株式会社电装 用于建立关于便携式设备和车辆的位置信息的系统及方法
CN110574414B (zh) 2016-12-27 2023-04-04 株式会社电装 用于微定位传感器通信的系统和方法
US20180198620A1 (en) * 2017-01-11 2018-07-12 Raptor Engineering, LLC Systems and methods for assuring data on leased computing resources
US11468439B2 (en) * 2017-01-12 2022-10-11 American Express Travel Related Services Company, Inc. Systems and methods for blockchain based proof of payment
WO2018140813A1 (en) * 2017-01-27 2018-08-02 Celitech Inc. Systems and methods for enhanced mobile data roaming and connectivity
US10425417B2 (en) * 2017-03-08 2019-09-24 Bank Of America Corporation Certificate system for verifying authorized and unauthorized secure sessions
US10560844B2 (en) * 2017-03-15 2020-02-11 International Business Machines Corporation Authentication of users for securing remote controlled devices
US11107048B2 (en) * 2017-04-17 2021-08-31 International Business Machines Corporation Providing out-of-band verification for blockchain transactions
US10358114B2 (en) * 2017-04-25 2019-07-23 Ford Global Technologies, Llc Method and apparatus for dynamic vehicle key generation and handling
US11194562B2 (en) * 2017-05-19 2021-12-07 Blackberry Limited Method and system for hardware identification and software update control
US11153076B2 (en) * 2017-07-17 2021-10-19 Thirdwayv, Inc. Secure communication for medical devices
US10805276B2 (en) * 2017-09-05 2020-10-13 Comodo Security Solutions, Inc. Device and methods for safe control of vehicle equipment secured by encrypted channel
US10516650B2 (en) * 2017-09-13 2019-12-24 Netabstraction, Inc. Dynamic, user-configurable virtual private network
US11251975B1 (en) * 2017-09-27 2022-02-15 Seagate Technology Llc Block chain based trusted security infrastructure
JP7242169B2 (ja) * 2017-10-31 2023-03-20 株式会社小松製作所 通信監視装置、通信監視システム、および通信監視方法
US10904230B2 (en) * 2017-11-29 2021-01-26 Vmware, Inc. Distributed encryption
US10715610B2 (en) * 2017-12-15 2020-07-14 Slack Technologies, Inc. System, method, and apparatus for generating a third party resource usage map in a group based communication system
US10871952B2 (en) * 2017-12-20 2020-12-22 Nio Usa, Inc. Method and system for providing secure over-the-air vehicle updates
US20200387611A1 (en) * 2017-12-22 2020-12-10 Vincent J. Zimmer Manageability engine and automatic firmware validation
US11606190B2 (en) * 2017-12-26 2023-03-14 Akamai Technologies, Inc. High performance distributed system of record with cryptographic service support
US10868812B2 (en) * 2017-12-29 2020-12-15 ANI Technologies Private Limited Method and system for device authentication
US11010739B2 (en) 2017-12-29 2021-05-18 Square, Inc. Application programming interfaces for structuring distributed systems
US11164172B2 (en) * 2017-12-29 2021-11-02 Square, Inc. Application programming interfaces for structuring distributed systems
US10437745B2 (en) * 2018-01-05 2019-10-08 Denso International America, Inc. Mobile de-whitening
US20190215163A1 (en) * 2018-01-09 2019-07-11 Ford Global Technologies, Llc Electronic custody tracking
JP2019133471A (ja) * 2018-01-31 2019-08-08 Ｄｙｎａｂｏｏｋ株式会社 電子機器、及び電子機器の起動方法
US11277421B2 (en) * 2018-02-20 2022-03-15 Citrix Systems, Inc. Systems and methods for detecting and thwarting attacks on an IT environment
KR102511778B1 (ko) * 2018-03-05 2023-03-21 삼성전자주식회사 전자 디바이스 및 전자 디바이스의 디지털 키 프로비저닝 수행 방법
JP7311245B2 (ja) 2018-03-07 2023-07-19 トヨタ自動車株式会社 マスタ装置、マスタ、制御方法、プログラム及び車両
US10681020B2 (en) * 2018-03-12 2020-06-09 The Boeing Company Blockchain fortified aircraft communications addressing and reporting system (ACARS) communication
WO2019211045A1 (en) * 2018-05-04 2019-11-07 Stanfeld Aps A remote support device
EP3570578B1 (en) * 2018-05-15 2021-12-22 Volkswagen Aktiengesellschaft Apparatus, method and computer program for determining information related to an authenticity of a wireless message in a wireless group communication among vehicles of a group of vehicles
CN108777613A (zh) * 2018-06-01 2018-11-09 杭州电子科技大学 物联网中传感信息虚拟服务的数据分块安全存储方法
WO2019237264A1 (zh) * 2018-06-13 2019-12-19 卧槽科技（深圳）有限公司 低功耗蓝牙通信方法、电子设备、网络和存储介质
US11120137B2 (en) 2018-06-19 2021-09-14 Netgear, Inc. Secure transfer of registered network access devices
CN110659986B (zh) * 2018-06-28 2022-07-19 本无链科技(深圳)有限公司 一种区块链的多账户协同打块的方法及系统
CN108921565B (zh) * 2018-08-01 2021-08-27 杭州字节方舟科技有限公司 一种互联网区块链大数据处理系统及方法
CN110798434B (zh) * 2018-08-03 2022-04-08 Emc Ip控股有限公司 计算机系统、计算装置所进行的方法和存储介质
US10511443B1 (en) * 2018-10-02 2019-12-17 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US20210306157A1 (en) * 2018-11-01 2021-09-30 Hewlett-Packard Development Company, L.P. Infrastructure device enrolment
US10945092B2 (en) 2018-11-07 2021-03-09 Adero, Inc. Organizing physical objects using wireless tags
US10911899B2 (en) 2018-11-07 2021-02-02 Adero, Inc. Providing indication to location of physical object using wireless tag
US11138680B1 (en) 2018-11-21 2021-10-05 Square, Inc. Updating menus based on predicted efficiencies
US10938254B2 (en) * 2018-12-18 2021-03-02 Dell Products, L.P. Secure wireless charging
CN109474365A (zh) * 2018-12-29 2019-03-15 深圳市柠檬互动科技有限公司 一种帧同步udp网络同步方法
CN109857101A (zh) * 2019-01-11 2019-06-07 丰疆智慧农业股份有限公司 智能农机授权系统和方法
EP3909276A1 (en) * 2019-01-11 2021-11-17 Telefonaktiebolaget Lm Ericsson (Publ) 5g-4g authentication data coexistence
CN109687963B (zh) * 2019-01-15 2021-06-22 如般量子科技有限公司 基于公钥池的抗量子计算联盟链交易方法和系统
US11295024B2 (en) 2019-01-18 2022-04-05 Red Hat, Inc. Providing smart contracts including secrets encrypted with oracle-provided encryption keys using threshold cryptosystems
US11593493B2 (en) 2019-01-18 2023-02-28 Red Hat, Inc. Providing smart contracts including secrets encrypted with oracle-provided encryption keys
US11177955B2 (en) * 2019-01-23 2021-11-16 Apple Inc. Device-to-device messaging protocol
US11316660B2 (en) * 2019-02-21 2022-04-26 Red Hat, Inc. Multi-stage secure smart contracts
US10666431B1 (en) * 2019-03-11 2020-05-26 Capital One Services, Llc Systems and methods for enhancing web security
US11329968B2 (en) * 2019-03-18 2022-05-10 Microsoft Technology Licensing, Llc Authentication across decentralized and centralized identities
US11341261B2 (en) * 2019-04-05 2022-05-24 Spideroak, Inc. Integration of a block chain, managing group authority and access in an enterprise environment
CN113994625A (zh) * 2019-04-11 2022-01-28 株式会社Ntt都科摩 网络节点
CN110099065A (zh) 2019-05-10 2019-08-06 北京百度网讯科技有限公司 物联网设备及认证方法、云服务器、处理设备、可读介质
US11956231B1 (en) * 2019-05-30 2024-04-09 Apple Inc. Authority transfer for virtual objects in shared computer-generated reality environments
US11677554B2 (en) * 2019-06-01 2023-06-13 Apple Inc. Key registration transparency for secure messaging
US20200403794A1 (en) * 2019-06-21 2020-12-24 Acton, Inc. Electric vehicle with public and private keys pairs to cryptographically secure sensitive information relative to the electric vehicle
JP7184188B2 (ja) * 2019-06-27 2022-12-06 京セラドキュメントソリューションズ株式会社 画像形成装置、ファームウェアの改竄防止方法及び改竄防止プログラムを記憶したコンピューター読取可能な非一時的な記録媒体
US11451380B2 (en) 2019-07-12 2022-09-20 Red Hat, Inc. Message decryption dependent on third-party confirmation of a condition precedent
CN110620668B (zh) * 2019-08-09 2022-11-15 如般量子科技有限公司 基于区块链的抗量子计算公钥池更新方法和系统
CN110490305B (zh) * 2019-08-22 2021-06-04 腾讯科技（深圳）有限公司 基于区块链网络的机器学习模型处理方法及节点
US20210067350A1 (en) * 2019-09-04 2021-03-04 Adero, Inc. Presence and identity verification using wireless tags
JP7318461B2 (ja) * 2019-09-30 2023-08-01 株式会社リコー 通信システム、通信端末、通信方法、通信端末のプログラムおよびアプリケーションプログラム
EP4046044A1 (en) * 2019-10-14 2022-08-24 Vestas Wind Systems A/S Secure data synchronization between offline and online systems
CN110881026B (zh) * 2019-10-15 2022-10-04 中国电力科学研究院有限公司 一种用于对信息采集终端用户进行身份认证的方法及系统
CN110765446B (zh) * 2019-10-21 2023-09-12 深圳市神飞电子科技有限公司 一种电子设备授权许可分发方法
CN110784461B (zh) * 2019-10-23 2020-05-12 北方工业大学 一种基于区块链的安全6LoWPAN通信方法及系统
US11334655B2 (en) * 2019-11-19 2022-05-17 Micron Technology, Inc. Authenticating a device using a remote host
CN110865608A (zh) * 2019-11-21 2020-03-06 武夷学院 一种可重构制造系统
CN114930327A (zh) * 2019-12-06 2022-08-19 亚萨合莱有限公司 安全更新安全元件的方法和过程
KR102090911B1 (ko) * 2019-12-16 2020-03-19 주식회사 케이비시스 컨테이너 기반의 클라우드 서비스 제공 시스템
US11115819B2 (en) * 2019-12-30 2021-09-07 Itron, Inc. Local authentication of communications device
CN111193751B (zh) * 2020-01-13 2022-02-08 临沂大学 一种恢复出厂设置的方法及设备
JP7331714B2 (ja) * 2020-01-27 2023-08-23 富士通株式会社 情報処理装置、情報処理方法及びプログラム
US11321489B2 (en) * 2020-03-03 2022-05-03 The Prudential Insurance Company Of America System for improving data security when storing data
CN111460499B (zh) * 2020-03-31 2022-03-15 中国电子科技集团公司第三十研究所 一种保护隐私的基于Merkletree的区块链用户属性集核验方法
US11665159B2 (en) 2020-04-22 2023-05-30 Kyndryl, Inc. Secure resource access by amalgamated identities and distributed ledger
CN111639020B (zh) * 2020-05-06 2021-07-02 贝壳找房(北京)科技有限公司 一种程序漏洞复现方法、系统、装置、电子设备及其存储介质
US11606349B2 (en) 2020-06-02 2023-03-14 Salesforce.Com, Inc. Authentication token refresh
US11394695B2 (en) * 2020-07-02 2022-07-19 Kpn Innovations, Llc. Methods and systems for generating a secure communication channel interface for video streaming of sensitive content
CN111541788B (zh) 2020-07-08 2020-10-16 支付宝(杭州)信息技术有限公司 区块链一体机的哈希更新方法及装置
CN113971289A (zh) 2020-07-08 2022-01-25 支付宝(杭州)信息技术有限公司 区块链一体机的可信启动方法及装置
CN111866000A (zh) * 2020-07-24 2020-10-30 宁夏政安信息科技有限公司 计算机介质管理系统的账号密码管理方法
US11632244B2 (en) * 2020-09-14 2023-04-18 Paypal, Inc. Techniques for single round multi-party computation for digital signatures
US11522684B2 (en) 2020-09-24 2022-12-06 Capital One Services, Llc Key rotation service
CN112187459B (zh) * 2020-10-09 2022-08-16 安徽大学 一种智能网联车中模块间的可信认证方法及系统
CN112218279B (zh) * 2020-10-14 2024-06-11 福建小飞科技有限公司 一种多协议的手持终端对展示终端的控制方法及设备
US11533309B2 (en) * 2020-12-28 2022-12-20 Okta, Inc. Digital signature injection for user authentication across multiple independent systems
US11503114B2 (en) 2021-01-05 2022-11-15 Toyota Motor North America, Inc. Provisioning of event-based keys to transports
US11438158B2 (en) 2021-01-05 2022-09-06 Toyota Motor North America, Inc. Provisioning of external functionality to transports
US11870557B2 (en) 2021-01-05 2024-01-09 Toyota Motor North America, Inc. Process for generating transport keys for data communication based on actions performed by a transport
US20220247576A1 (en) * 2021-02-04 2022-08-04 Fortanix, Inc. Establishing provenance of applications in an offline environment
US20220327003A1 (en) * 2021-04-09 2022-10-13 Oracle International Corporation Cloud edge device virtualization
US11831641B2 (en) 2021-04-19 2023-11-28 Capital One Services, Llc Using tokens from push notification providers to enhance device fingerprinting
US11943221B2 (en) 2021-08-25 2024-03-26 International Business Machines Corporation Preventing masquerading service attacks
JP2023049595A (ja) 2021-09-29 2023-04-10 株式会社デンソー 車両用デジタルキーシステム、車両用デジタルキー管理方法、車両用装置、携帯端末
JP2023049594A (ja) 2021-09-29 2023-04-10 株式会社デンソー 車両用デジタルキーシステム、車両用デジタルキー管理方法、車両用装置、携帯端末
JP2023049593A (ja) 2021-09-29 2023-04-10 株式会社デンソー 車両用デジタルキーシステム、車両用デジタルキー管理方法、車両用装置、携帯端末
US11546358B1 (en) * 2021-10-01 2023-01-03 Netskope, Inc. Authorization token confidence system
CN114152460B (zh) * 2021-11-30 2023-04-21 四川虹美智能科技有限公司 智能空调的生产检测系统和方法
US20230297724A1 (en) * 2022-03-15 2023-09-21 Microsoft Technology Licensing, Llc Hardware identity restoration post-device repair
US11652696B1 (en) * 2022-03-24 2023-05-16 Red Hat, Inc. Zoned mesh network isolation
US20230354020A1 (en) * 2022-04-27 2023-11-02 Capital One Services, Llc Systems and methods for context-switching authentication over short range wireless communication
US11985124B2 (en) 2022-06-02 2024-05-14 Bank Of America Corporation System for implementing multifactor authentication based on secure tokenization
WO2024010666A1 (en) * 2022-07-07 2024-01-11 Qualcomm Incorporated Systems and methods for assigning and using privileges to assist maneuvering and travel of vehicles
US11972300B2 (en) * 2022-07-22 2024-04-30 Oracle International Corporation Techniques for managing edge device provisioning
CN115766130B (zh) * 2022-11-02 2024-04-19 中国联合网络通信集团有限公司 一种会议加密方法、装置、电子设备及存储介质
CN117093969B (zh) * 2023-08-22 2024-06-04 上海合芯数字科技有限公司 调试授权方法及系统
CN117097570B (zh) * 2023-10-19 2023-12-29 中国民航大学 一种基于云链融合的机载软件安全分发身份认证方法

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6826616B2 (en) * 1998-10-30 2004-11-30 Science Applications International Corp. Method for establishing secure communication link between computers of virtual private network
DE60044586D1 (de) * 2000-04-28 2010-08-05 Swisscom Ag Verfahren zur sicherung der kommunikation zwischen einem endgerät und einer zusätzlichen benutzervorrichtung
FI20002255A (fi) 2000-10-13 2002-04-14 Nokia Corp Menetelmä lukkojen hallintaan ja kontrollointiin
EP1388126B1 (en) * 2001-05-17 2013-03-27 Nokia Corporation Remotely granting access to a smart environment
US7606560B2 (en) * 2002-08-08 2009-10-20 Fujitsu Limited Authentication services using mobile device
JP2004140706A (ja) 2002-10-18 2004-05-13 Toshiba Corp 車載用通信装置
ZA200602880B (en) 2003-10-08 2007-08-29 Stephan J Engberg Method and system for establishing a communication using privacy enhancing techniques
EP1596529B1 (en) 2004-04-30 2007-12-05 Research In Motion Limited Cryptographic device authentication
JP2006083604A (ja) 2004-09-16 2006-03-30 Auto Network Gijutsu Kenkyusho:Kk データ読取装置および車載機器無線制御システム
JP2007162309A (ja) 2005-12-13 2007-06-28 Tokai Rika Co Ltd リモートコントロールキーシステム
CN101051898B (zh) 2006-04-05 2010-04-21 华为技术有限公司 无线网络端到端通信认证方法及其装置
JP4821837B2 (ja) 2008-11-18 2011-11-24 Ｎｅｃアクセステクニカ株式会社 無線通信装置、無線通信方法、無線通信プログラム
WO2010064966A1 (en) 2008-12-04 2010-06-10 Saab Ab Key issuer, key carrier, access unit and methods performed in said units
JP2011012511A (ja) * 2009-07-06 2011-01-20 Kesaka System Inc 電気錠制御システム
US11042816B2 (en) 2009-10-30 2021-06-22 Getaround, Inc. Vehicle access control services and platform
US8996876B2 (en) 2010-03-02 2015-03-31 Liberty Plugins, Inc. Method and system for using a smart phone for electrical vehicle charging
ES2527793T3 (es) * 2010-08-23 2015-01-29 3M Innovative Properties Co. Método y dispositivo para la autenticación de pregunta-respuesta
US8799675B2 (en) * 2012-01-05 2014-08-05 House Of Development Llc System and method for electronic certification and authentication of data
JP2013257653A (ja) 2012-06-11 2013-12-26 Toyota Infotechnology Center Co Ltd カーシェアリングシステム、通信端末、通信プログラムおよび通信方法
CN102752298B (zh) * 2012-06-29 2015-04-29 华为技术有限公司 安全通信方法、终端、服务器及系统
MX2017007292A (es) 2014-12-02 2017-08-25 Carrier Corp Programacion remota para sistema de control de acceso con datos de tarjeta virtual.
JP6419588B2 (ja) * 2015-01-19 2018-11-07 株式会社東海理化電機製作所 携帯端末追加登録システム
WO2016139301A1 (de) * 2015-03-05 2016-09-09 Volkswagen Aktiengesellschaft Intelligenter elektronischer schlüssel mit mobilfunk-fähigkeit
JP2016184875A (ja) * 2015-03-26 2016-10-20 美和ロック株式会社 鍵データ通信システム
US10693658B2 (en) * 2016-02-12 2020-06-23 Visa International Service Association Methods and systems for using digital signatures to create trusted digital asset transfers

Also Published As

Publication number Publication date
WO2018081583A1 (en) 2018-05-03
US20190253262A1 (en) 2019-08-15
EP3532971A4 (en) 2019-11-06
US11895247B2 (en) 2024-02-06
CN109891416A (zh) 2019-06-14
EP3532971A1 (en) 2019-09-04
US10771263B2 (en) 2020-09-08
US20180123804A1 (en) 2018-05-03
JP2019536329A (ja) 2019-12-12
JP2023036897A (ja) 2023-03-14
JP2021040330A (ja) 2021-03-11
US20200403808A1 (en) 2020-12-24
US10313134B2 (en) 2019-06-04

Similar Documents

Publication Publication Date Title
JP6888673B2 (ja) デバイスを認証および認可するためのシステムおよび方法
US20220245724A1 (en) Securing distributed electronic wallet shares
US11657665B2 (en) Method and system for decentralized digital authentication
KR102117584B1 (ko) 로컬 디바이스 인증
CN111049660B (zh) 证书分发方法、系统、装置及设备、存储介质
US20220255931A1 (en) Domain unrestricted mobile initiated login
EP2632108B1 (en) Method and system for secure communication
CN113691560B (zh) 数据传送方法、控制数据使用的方法以及密码设备
US20180205540A1 (en) System, apparatus and method for group key distribution for a network
JP2021523650A (ja) 安全なブロックチェーントランザクションおよびサブネットワークのためのシステム、方法、デバイス及び端末
US20190207927A1 (en) Single sign on (sso) using continuous authentication
KR102177794B1 (ko) 사물인터넷 블록체인 환경에서의 디바이스 분산 인증 방법 및 이를 이용한 디바이스 분산 인증 시스템
US8145917B2 (en) Security bootstrapping for distributed architecture devices
US9608971B2 (en) Method and apparatus for using a bootstrapping protocol to secure communication between a terminal and cooperating servers
JP2004180280A (ja) 適応性のある委任のための方法とシステム
CN102984252A (zh) 一种基于动态跨域安全令牌的云资源访问控制方法
KR20140127303A (ko) 다중 팩터 인증 기관
CA2798024C (en) One time passwords with ipsec and ike version 1 authentication
US20190173880A1 (en) Secure node management using selective authorization attestation
JP5992535B2 (ja) 無線ｉｄプロビジョニングを実行するための装置及び方法
WO2018207174A1 (en) Method and system for sharing a network enabled entity
US20240205027A1 (en) System and method for authenticating and authorizing devices
Lu et al. Distributed ledger technology based architecture for decentralized device-to-device communication network
JP2024503921A (ja) トラストレス鍵プロビジョニングのシステムおよび方法
WO2022140469A1 (en) Domain unrestricted mobile initiated login

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190422

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20200625

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200721

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20200914

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20201118

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20210420

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210503

R151 Written notification of patent or utility model registration

Ref document number: 6888673

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250