(57)【要約】  １つ又は複数の車両における複数のＩｏＴデバイス間の安全な通信を確立するための方法は、複数のＩｏＴデバイスのそれぞれに固有識別子、デジタルアイデンティティトークン、及び暗号鍵を提供することにより複数のＩｏＴデバイスをプロビジョニングすることと、それぞれのＩｏＴデバイス間のそれぞれの通信回線を認証し、それぞれの通信回線にデジタル証明書を発行することにより、複数のＩｏＴデバイス間の安全な通信回線を確立することと、所定の基準に基づいて複数のＩｏＴデバイスを異なるグループへグループ分けすることと、異なるグループのうちの１つのグループに関するグループメンバーシップを、グループ特徴を示す属性証明書に含めることと、を含む。【選択図】図３
2020532215.tif 000002
【特許請求の範囲】
【請求項１】
１つ又は複数の車両における、それぞれハードウェアプロセッサ及び関連するメモリを含む複数のＩｏＴ（Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｔｈｉｎｇｓ）デバイス間の安全な通信を確立するための方法であって、
前記複数のＩｏＴデバイスのそれぞれに固有識別子、デジタルアイデンティティトークン、及び暗号鍵を提供することにより前記複数のＩｏＴデバイスをプロビジョニングすることと、
それぞれのＩｏＴデバイス間のそれぞれの通信回線を認証し、前記それぞれの通信回線にデジタル証明書を発行することにより、前記複数のＩｏＴデバイス間の安全な通信回線を確立することと、
所定の基準に基づいて前記複数のＩｏＴデバイスを異なるグループへグループ分けすることと、
前記異なるグループのうちの１つのグループに関するグループメンバーシップを、グループ特徴を示す属性証明書に含めることと、
を含む、方法。
【請求項２】
前記安全な通信回線のそれぞれが、前記それぞれのＩｏＴデバイス間のそれぞれ前記安全な通信回線の使用についての条件を確立するデジタル契約書を含む、請求項１に記載の方法。
【請求項３】
グループメンバーシップに関する関連するルールを含んでいる前記属性証明書がグループに発行される、請求項１〜請求項２のいずれかに記載の方法。
【請求項４】
前記異なるグループがサブグループを含む、請求項１〜請求項３のいずれかに記載の方法。
【請求項５】
各異なる車両が異なるグループを有し、それぞれのグループの各サブグループが前記車両のコンポーネントを含む、請求項１〜請求項４のいずれかに記載の方法。
【請求項６】
１つ又は複数のＩｏＴデバイスが、車両のコントローラ・エリア・ネットワーク（ＣＡＮ）バスに結合され、前記ＣＡＮバスに結合されている又は前記ＣＡＮバスに結合されていない別のＩｏＴデバイスとの安全な通信回線を確立し得る、請求項１〜請求項５のいずれかに記載の方法。
【請求項７】
１つ又は複数のＩｏＴデバイスが、車両のコントローラ・エリア・ネットワーク（ＣＡＮ）バスに結合され、前記属性証明書に記録される前記ＣＡＮバスと共に特徴付けられるＩｏＴデバイスのグループのメンバーにされ、グループに関連付けられる前記属性証明書が、前記グループのうちの１つ又は複数の間で通信するのに適格な発信者によって用いられる、請求項１〜請求項６のいずれかに記載の方法。
【請求項８】
前記安全な通信回線が、車車間（Ｖ２Ｖ）、車とインフラストラクチャ間（Ｖ２Ｉ）、車とグリッド間（Ｖ２Ｇ）、車とＸ間（Ｖ２Ｘ）、及び車のオンボード診断（ＯＢＤ）からなるグループのうちの１つ又は複数の間で通信するのに用いられる、請求項１〜請求項７のいずれかに記載の方法。
【請求項９】
特定の車両に関するグループが、外部デバイスに送信するための前記特定の車両に関する可変識別子を含む、請求項１〜請求項８のいずれかに記載の方法。
【請求項１０】
前記可変識別子が、前記特定の車両又はそのＩｏＴデバイスの或る動作モード又は動作時間のうちの１つ又は複数に基づいて動的に変化する、請求項８に記載の方法。
【請求項１１】
前記異なるグループが、特定の車両の外部の他のデバイスと通信する前記特定の車両の外部領域を監視する前記特定の車両におけるデバイスを含む外部デバイスグループと、前記特定の車両の内部領域を監視するデバイスを含む内部デバイスグループを含む、請求項１〜請求項１０のいずれかに記載の方法。
【請求項１２】
前記外部デバイスグループ又は前記内部デバイスグループが、前記グループが或る情報を他のデバイスに送信することを防止する関連するルールを含む、請求項１１に記載の方法。
【請求項１３】
前記複数のＩｏＴデバイスへの安全な通信回線が確立されていない又は承認された属性証明書を有するグループのメンバーではないデバイスが前記複数のＩｏＴデバイスと通信するのを防止することをさらに含む、請求項１〜請求項１２のいずれかに記載の方法。
【請求項１４】
前記複数のＩｏＴデバイスのそれぞれの固有識別子及びデジタルアイデンティティトークンを用いて前記複数のＩｏＴデバイスのそれぞれを認証することをさらに含む、請求項１〜請求項１３のいずれかに記載の方法。
【請求項１５】
前記ＩｏＴデバイスを認証することが、招待主−招待客プロトコルを用いることを含む、請求項１〜請求項１４のいずれかに記載の方法。
【請求項１６】
前記１つ又は複数の車両が、救急車、警察車両、牽引トラック、危険物車両、軍用車両、又は他の定義される車両タイプのうちの１つ又は複数を含む、請求項１〜請求項１５のいずれかに記載の方法。
【請求項１７】
外部デバイスの第２のグループを確立することと、
前記第２のグループの各メンバーに第２グループ秘密鍵を発行することと、
前記異なるグループのうちの１つ又は複数のメンバーへの前記第２のグループに関する属性証明書を確立することと、
をさらに含む、請求項１〜請求項１６のいずれかに記載の方法。
【請求項１８】
１つ又は複数の車両における、それぞれハードウェアプロセッサ、関連するメモリ、固有識別子、デジタルアイデンティティトークン、及び暗号鍵を含む複数のＩｏＴ（Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｔｈｉｎｇｓ）デバイス間の安全な通信を確立するための方法であって、
第２のＩｏＴデバイスからデジタルアイデンティティトークンを受信することにより第１のＩｏＴデバイスとの通信回線を確立するべく前記第１のＩｏＴデバイスにより前記第２のＩｏＴデバイスを招待することと、
前記第１のＩｏＴデバイスと前記第２のＩｏＴデバイスとの間の通信回線を認証し、前記通信回線にデジタル証明書を発行することにより、前記第１のＩｏＴデバイスと前記第２のＩｏＴデバイスとの間の安全な通信回線を確立することと、
所定の基準に基づいて前記複数のＩｏＴデバイスを異なるグループへグループ分けすることと、
前記異なるグループに関するグループメンバーシップを前記それぞれのデバイスのそれぞれの属性証明書に含めることと、
を含む、方法。
【請求項１９】
前記安全な通信回線が、前記第１のＩｏＴデバイスと前記第２のＩｏＴデバイスとの間の前記各安全な通信回線の使用についての条件を確立するデジタル契約書を含む、請求項１８に記載の方法。
【請求項２０】
グループメンバーシップに関する関連するルールを含んでいる属性証明書がグループに発行される、請求項１８〜請求項１９のいずれかに記載の方法。
【請求項２１】
前記異なるグループがサブグループを含み、各異なる車両が異なるグループを有し、それぞれのグループの各サブグループが前記車両のコンポーネントを含む、請求項１８〜請求項２０のいずれかに記載の方法。
【請求項２２】
特定の車両に関するグループが、外部デバイスに送信するための前記特定の車両に関する可変識別子を含み、前記可変識別子が、前記特定の車両又はそのＩｏＴデバイスの或る動作モード又は動作時間のうちの１つ又は複数に基づいて動的に変化する、請求項１８〜請求項２１のいずれかに記載の方法。
【請求項２３】
外部デバイスの第２のグループを確立することと、
前記第２のグループの各メンバーに第２グループ秘密鍵を発行することと、
前記異なるグループのうちの１つ又は複数のメンバーへの前記第２のグループに関する属性証明書を確立することと、
をさらに含む、請求項１８〜請求項２２のいずれかに記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願への相互参照
この国際出願は、２０１７年６月１３日に出願された米国特許出願第１５／６２１，９８２号の一部継続出願であり且つ２０１７年７月２５日に出願された米国特許仮出願第６２／５３６，８８４号の利益を主張する、２０１７年８月２４日に出願された米国特許出願第１５／６８６，０７６号の米国一部継続出願に基づく優先権及び利益を主張するものである。
【０００２】
前述の米国特許出願第１５／６２１，９８２号は、２０１６年３月２５日に出願された米国特許仮出願第６２／３１３，１２４号、２０１６年４月２４日に出願された第６２／３２６，８１２号、２０１６年５月２日に出願された第６２／３３０，８３９号、２０１６年６月９日に出願された第６２／３４７，８２２号、２０１６年８月１日に出願された第６２／３６９，７２２号、２０１６年８月１１日に出願された第６２／３７３，７６９号、及び２０１６年９月２８日に出願された第６２／４０１，１５０号の利益を主張する、２０１７年３月２４日に出願された米国特許出願第１５／４６９，２４４号（米国特許第９，７１６，５９５号として発行済み）の継続出願であり、且つ、２０１６年９月１９日に出願された米国特許出願第１５／２６９，８３２号の一部継続出願であり、前述の米国特許出願第１５／２６９，８３２号は、２０１６年１月２０日に出願された米国特許出願第１５／００２，２２５号（米国特許第９，４５５，９７８号として発行済み）の継続出願であり、前述の米国特許出願第１５／００２，２２５は、米国特許出願第１４／２１８，８９７号（米国特許第９，２７０，６６３号として発行済み）の継続出願であり、前述の米国特許出願第１４／２１８，８９７号は、２０１３年３月１５日に出願された米国特許仮出願第６１／７９２，９２７号の利益を主張するものである。米国特許出願第１５／００２，２２５号はまた、２０１２年５月２３日に出願された米国特許仮出願第６１／６５０，８６６号及び２０１１年５月２７日に出願された第６１／４９０，９５２号の利益を主張する、２０１２年５月２５日に出願された米国特許出願第１３／４８１，５５３号の一部継続出願である。
【０００３】
前述の米国特許出願第１５／００２，２２５号はまた、２０１０年１１月２３日に出願された米国特許仮出願第６１／４１６，６２９号、２０１０年７月２６日に出願された第６１／３６７，５７６号、２０１０年７月２６日に出願された第６１／３６７，５７４号、及び２０１０年４月３０日に出願された第６１／３３０，２２６号の利益を主張する、２０１１年４月２８日に出願された米国特許出願第１３／０９６，７６４号の一部継続出願である。
【０００４】
前述の米国特許出願第１５／４６９，２４４号は、２０１６年５月１３日に出願された米国特許出願第１５／１５４，８６１号（米国特許第９，５７８，０３５号として発行済み）の継続出願である２０１７年１月１８日に出願された米国特許出願第１５／４０９，４２７号の一部継続出願であり、前述の米国特許出願第１５／１５４，８６１号は、２０１５年３月１５日に出願された米国特許仮出願第６２／１３３，３７１号、２０１４年５月１７日に出願された第６１／９９４，８８５号、及び２０１０年７月２６日に出願された第６１／３６７，５７６号の利益を主張する、２０１５年５月１８日に出願された米国特許出願第１４／７１５，５８８号（米国特許第９，３５６，９１６号として発行済み）の継続出願である。前述の米国特許出願第１４／７１５，５８８号はまた、２０１３年３月１５日に出願された第６１／７９２，９２７号の利益を主張する２０１４年３月１８日に出願された第１４／２１８，８９７号（米国特許第９，２７０，６６３号として発行済み）の一部継続出願である。前述の２０１６年５月１３日に出願された米国特許出願第１５／１５４，８６１号は、２０１２年５月２３日に出願された米国特許仮出願第６１／６５０，８６６号及び２０１１年５月２７日に出願された第６１／４９０，９５２号の利益を主張する、２０１２年５月２５日に出願された米国特許出願第１３／４８１，５５３号の一部継続出願である。
【０００５】
前述の２０１６年５月１３日に出願された米国特許出願第１５／１５４，８６１号は、２０１０年１１月２３日に出願された米国特許仮出願第６１／４１６，６２９号、２０１０年７月２６日に出願された第６１／３６７，５７４号、及び２０１０年４月３０日に出願された第６１／３３０，２２６号の利益を主張する、２０１１年４月２８日に出願された米国特許出願第１３／０９６，７６４号の一部継続出願である。
【０００６】
上記の出願のうちのすべての全内容が、参照により本明細書に明確に組み込まれる。
【０００７】
本発明は、一般に、ＩｏＴ（Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｔｈｉｎｇｓ）セキュリティ及び管理に関し、より詳細には、車両のＩｏＴセキュリティ及び管理のためのシステム及び方法に関する。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ＩｏＴ（Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｔｈｉｎｇｓ）デバイスのセキュリティ、オペレーション、サポート、及びメンテナンスを担う多くの企業、組織、政府などは、益々課題に直面している。ＩｏＴデバイスは、製造、公共施設、配布、レクリエーション、軍事、居住、商業、健康管理などのための設備を含む現代の経済の多くの領域で益々重要な役割を果たすようになっている。加えて、ＩｏＴデバイスは、自動車、航空機、医療機器などの上記の設備に関連付けられる又は関連付けられない場合がある工業製品に組み込まれる。このような製品の製造に関して、ＩｏＴデバイス（通常、第三者により製造される）の保護、制御、及び管理は、困難で、危機、リスク、又は潜在的責任を伴うことがある。
【０００９】
工業製品（それらの組み込まれたＩｏＴデバイスと共に）と、オペレーティング設備（例えば、工場、電力系統など）にＩｏＴデバイスを配備する企業との両方に関して、生成されるデータの制御を保証すること、認可されていない不特定者がデバイスにアクセスできないようにアクセス制御を行うこと、認可された者のみをリッスンするようにデバイスに指示する能力を有すること、デバイスが認可されていない者を無視する能力を有すること、及び／又は典型的なＩｏＴデバイス及びこのような動作しているＩｏＴデバイス内にあり得るデバイスの強いアイデンティティ管理を外部の認可されたシステム又はエンティティに提供することが望ましい。
【００１０】
典型的なデバイスが、認可された検証されたファームウェアでのみ構成可能及び容易に更新可能となることも望ましい。ＩｏＴデバイスはまた、エンティティが外部アクセスの制御又は他の方法での保護を望み得る、これらのデバイスで所有する、制御する、或いは直接の利害関係を有する、機密性の個人情報又は企業情報を含み得る又は該情報へのアクセスを有し得る。
【課題を解決するための手段】
【００１１】
いくつかの実施形態において、本願発明は、１つ又は複数の車両における、それぞれハードウェアプロセッサ及び関連するメモリを含む複数のＩｏＴデバイス間の安全な通信を確立するための方法である。方法は、複数のＩｏＴデバイスのそれぞれに固有識別子、デジタルアイデンティティトークン、及び暗号鍵を提供することにより複数のＩｏＴデバイスをプロビジョニングすることと、それぞれのＩｏＴデバイス間のそれぞれの通信回線を認証し、それぞれの通信回線にデジタル証明書を発行することにより、複数のＩｏＴデバイス間の安全な通信回線を確立することと、所定の基準に基づいて複数のＩｏＴデバイスを異なるグループへグループ分けすることと、異なるグループのうちの１つのグループに関するグループメンバーシップを、グループ特徴を示す属性証明書に含めることと、を含む。
【００１２】
いくつかの実施形態において、本願発明は、１つ又は複数の車両における、それぞれハードウェアプロセッサ、関連するメモリ、固有識別子、デジタルアイデンティティトークン、及び暗号鍵を含む複数のＩｏＴデバイス間の安全な通信を確立するための方法である。方法は、第２のＩｏＴデバイスからデジタルアイデンティティトークンを受信することにより第１のＩｏＴデバイスとの通信回線を確立するべく第１のＩｏＴデバイスにより第２のＩｏＴデバイスを招待することと、第１のＩｏＴデバイスと第２のＩｏＴデバイスとの間の通信回線を認証し、通信回線にデジタル証明書を発行することにより、第１のＩｏＴデバイスと第２のＩｏＴデバイスとの間の安全な通信回線を確立することと、所定の基準に基づいて複数のＩｏＴデバイスを異なるグループへグループ分けすることと、異なるグループに関するグループメンバーシップをそれぞれのデバイスのそれぞれの属性証明書に含めることと、を含む。
【００１３】
いくつかの実施形態において、安全な通信回線のそれぞれは、前記それぞれのＩｏＴデバイス間の各安全な通信回線の使用についての条件を確立するデジタル契約書を含み得る。いくつかの実施形態において、グループメンバーシップに関する関連するルールを含んでいる属性証明書がグループに発行され得る。いくつかの実施形態において、異なるグループはサブグループを含み、各異なる車両は異なるグループを有し、それぞれのグループの各サブグループは前記車両のコンポーネントを含み得る。
【００１４】
本発明のこれらの及び他の特徴、態様、及び利点は、以下の説明、付属の請求項、及び添付の図面からより良く理解されるであろう。
【図面の簡単な説明】
【００１５】
【図１】本願発明のいくつかの実施形態に係る、ＩｏＴデバイスの例示的なプロビジョニングプロセスを行うためのセキュリティシステムを示す図である。
【図２】本願発明のいくつかの実施形態に係る、安全な通信回線を相互に確立するべくＩｏＴデバイスを招待するためのセキュリティシステムを示す図である。
【図３】本願発明のいくつかの実施形態に係る、車両におけるＩｏＴデバイスの複数のペア間の安全な通信回線を確立するためのセキュリティシステムを例示する図である。
【図３Ａ】本願発明のいくつかの実施形態に係る、車両における例示的なタイプのＩｏＴデバイスを示す図である。
【図４】本願発明のいくつかの実施形態に係る、ＩｏＴデバイスを含む新しい製品を認証するためのセキュリティシステムを示す図である。
【図５】本願発明のいくつかの実施形態に係る、ＩｏＴデバイスとそれらの可能な交換品を含む、製品の整備のためのセキュリティシステムを示す図である。
【図６】本願発明のいくつかの実施形態に係る、安全な認証された通信回線のいくつかの要素を示す図である。
【図７】本願発明のいくつかの実施形態に係る、セキュリティエコシステムのいくつかの要素を例示する図である。
【図８】本願発明のいくつかの実施形態に係る、２つのアプリケーション・プログラミング・インターフェース（ＡＰＩ）の例示的な使用を示す図である。
【図９】本願発明のいくつかの実施形態に係る、複数のＩｏＴデバイス間の安全な通信を確立するための例示的なプロセスの流れである。
【図１０】本発明のいくつかの実施形態に係る、帯域幅が制約された環境でデジタル署名を用いる例示的な方法を示す図である。
【図１１】本発明のいくつかの実施形態に係る、そのような送信に必要とされる帯域幅を最小にしながらデジタル署名を送信する例示的な方法を示す図である。
【発明を実施するための形態】
【００１６】
いくつかの実施形態において、本願発明は、自動車、ボート、オートバイ、及び航空機などの１つ又は複数の車両に関係した複数のＩｏＴデバイス間の安全な通信を確立するための方法である。
【００１７】
いくつかの実施形態において、本願発明のセキュリティエコシステムは、認証局、登録局、ハードウェア・セキュリティ・モジュール（ＨＳＭ）、検証局（ＶＡ、潜在的には、オンライン証明書状態プロトコル（ＯＣＳＰ）又は証明書失効リスト（ＣＲＬ）による）、権限管理基盤（ＰＭＩ）、仮想ネットワークプロトコル（ＶＰＮ）技術、デバイス側クライアントアプリケーション、クラウドホスティング、認証、及びライト・アクティブ・ディレクトリアクセス・プロトコル（ＬＡＤＰ）のうちの１つ又は複数を含む公開鍵基盤（ＰＫＩ）のうちの１つ又は複数を用いることにより信頼される第三者仲介型サービスプロバイダとして作用する属性局（ＡＡ）のうちの１つ又は複数と共に構成される中央サーバの使用を通じて上記の能力の多くを提供する。いくつかの実施形態において、本願発明のセキュリティエコシステムはまた、潜在的には他のソリューションと組み合わせて、第三者ＩｏＴデバイス製造業者（そのＩｏＴ製品が後でセキュリティエコシステムによって管理され得る）に仕様を提供し得る。現在の典型的な業界の慣行は、中央認証局（ＣＡ）から各エンドポイントにのみ証明書を発行することである。しかしながら、本願発明のセキュリティエコシステムは、エンドポイントに証明書を発行するだけでなく、エンドポイントのペアを確立（確立した）及び使用し得る各認証された通信回線７０５にも証明書を発行する。
【００１８】
いくつかの実施形態において、このセキュリティエコシステムは、結果的に、資格証明書、アイデンティティプロファイル、通信回線、及び／又は鍵のリアルタイム管理をもたらし得る。認可されたユーザ／デバイスに調整可能な権利を配布することが可能である。セキュリティエコシステムのユーザにより管理される、デバイスにより管理される、オペレータにより管理される、又は人工知能により管理される招待主−招待客プロトコルスイートを用いて、招待主は、例えば、セキュリティエコシステムにより供給されるアイデンティティサポート情報と共に安全な通信回線を確立するプロトコルの完了に成功し得る招待客のアイデンティティを保証し得る。ユーザ／デバイスは、暗号化された通信を共有し得る典型的な通信回線（エンドポイントではない）へのアクセスに関係する認可要求及び他のリアルタイム検証を確立し、応答してよい。
【００１９】
通常、通信回線は、エンドポイント間の通信回線の使用についての条件（例えば、ルール及び／又はビジネスロジック）を確立するデジタル契約書が付随し得る。これらの契約書は、一般に、監査可能な、仲介される、信用される関係性であり、このような関係性／デジタル契約書は、（一般に、プライバシーのために）それぞれ独立していてよく、又は関係性にわたるアイデンティティ信頼レベルの構築に影響を及ぼし得る。これらの関係性は、定義される「グループ」へ編成され得る。いくつかの実施形態において、暗号により保護されるグループは、単一の工業製品内に組み込まれたデバイスのすべての或いは１つ又は複数のサブセットグループを含んでよく、例えば、異なる実施形態において、グループは、自動車、航空機、医療機器、家庭用電気器具などにおけるエンドポイントＩｏＴデバイスを包含し得る。
【００２０】
本願発明のいくつかの実施形態によれば、個々に製造されたＩｏＴデバイス並びに工業製品（ＩｏＴデバイスを組み込む）は、以下の能力のうちの１つ又は複数を含む。それらは、データの保護（例えば、暗号化を用いる）と潜在的にはデータの移動を含み得る生成されるデータの制御を保証する、認可されていない不特定者がデバイスにアクセスできないようにアクセス制御を行う、中間者攻撃を防ぐ又は軽減することができるように、認可された者のみをリッスンするようにデバイスに指示する能力を有する。これらのデバイスはまた、製品内にあり得る複数のＩｏＴデバイスに関してだけでなく、製品から外部の認可されたシステム又はデバイスにも強いアイデンティティ管理を提供し得る。
【００２１】
多くのデバイスは、ホストコンピュータ又はデバイスにより認識される認証局により発行される通常はコード署名証明書内の対象公開鍵に対応する秘密鍵を用いて署名される、認可された、署名されたファームウェアコードでのみ構成可能及び容易に更新可能であり得る。本明細書で説明されるソリューションから恩恵を受け得る工業製品の一例は、自動車である。自動車が遠隔的にハッキングされているといういくつかの報告が存在している。ひとたびシステムにアクセスすると、ハッカーは、自動車のコントローラ・エリア・ネットワーク（ＣＡＮ）バスを用いて、エンジン、ブレーキ、速度、ステアリング、及び／又はその他などの複数の電子制御ユニット（ＥＣＵ）にアクセスし、少なくとも部分的に制御することができた。本願発明は、ヒューマンマシンインターフェース、エンジン制御ユニット、伝送制御ユニット、ステアリング制御ユニット、テレマティクス制御ユニット、速度制御ユニット、バッテリ管理システム、シート及びドア制御ユニットなどの様々なＥＣＵに適用可能であり得る。
【００２２】
いくつかの実施形態において、本願発明は、安全なコンポーネント又は物理複製困難関数（ＰＵＦ）の一意の特性を活用し、ＩｏＴデバイスのアイデンティティを確実に確立するための基礎、従来のファイアウォールセキュリティのギャップの解決、リモートアイデンティティの認証、認証された公開鍵の交換、ランダムデバイスのアクセスの防止、データの保護及び制御、及び／又は署名されたファームウェアでのデバイスの更新、のうちの１つ又は複数を提供する。
【００２３】
いくつかの実施形態において、本願発明を組み込んだデバイスは、保護された暗号鍵を制御及び使用することができる。いくつかの実施形態において、組み立てられる製品にＩｏＴデバイス（本願発明に係る暗号及びセキュリティ機能を組み込んでいる）を一体化することにより、他の方法では専門スキルセットを必要とし得る複雑な又は一体化されたソリューションを提供するために、協調した様態で又は組み立てられる製品で複数のＩｏＴデバイスが一緒に用いられ得る。
【００２４】
本願発明のシステムの目的上、ＩｏＴデバイスはエンドポイントであり、一般に以下のような２つの広いタイプからなる。
【００２５】
「制御ＩｏＴ」又は「ＣＩｏＴ」デバイスは、１つ又は複数の同様のＩｏＴデバイス又はより限定された性質のＩｏＴデバイスを制御又は管理するのにも用いられ得る、クライアントＩｏＴデバイスの一種である。例えば、ＣＩｏＴデバイスは、自動車におけるＥＣＵを含み得る。
【００２６】
「限定されたＩｏＴ」又は「ＬＩｏＴ」デバイスは、通常、典型的なＣＩｏＴデバイス（より大きいメモリ、処理能力などを有する）の処理能力又は記憶能力又は他の能力を含まない。ＬＩｏＴデバイスは、センサ、スイッチ、アクチュエータ、コントローラなどを含み得る。
【００２７】
ＬＩｏＴデバイスの限定された処理能力及び他の能力を考慮すると、エコシステム型システムの完全な招待主−招待客プロビジョニングプロトコルのすべて又は一部は、その製造プロセス中に部分的に事前に完成された状態でデバイスにインストールされてよい。また、このようなＬＩｏＴデバイスに事前に割り当てられるのは、デバイスに割り当てられる一意のプロトコルアドレス又は識別子と、セキュリティエコシステム内の１つ又は複数の信用されるＣＩｏＴデバイス又は他の信用されるデバイスに関する鍵であり得る。例えば、公開鍵は、これらの公開鍵がＬＩｏＴデバイスが信用するべきデバイス又はエンドポイントに関連付けられるときにＬＩｏＴデバイスを指定するために提供され得る。これらは、ファームウェア署名局、管理者／ユーザにより制御されるデバイス、信用される管理デバイス（例えば、ＣＩｏＴ）、信用されるグループデバイスなどの、ＬＩｏＴデバイスに信用されるサービスを提供し得るデバイスであろう。本開示の全体を通して、「ＩｏＴデバイス」又は「ＩｏＴエンドポイント」という用語は、ＣＩｏＴ又はＬＩｏＴデバイスのいずれかを指すのに用いられ得る。「デバイス」又は「エンドポイント」という用語は、「ＩｏＴデバイス」、「ＩｏＴエンドポイント」、ユーザ／エンドポイント、ＣＩｏＴ、ＬＩｏＴデバイス、「コンテナ」、又は、モバイルデバイス、コンピューティングデバイスなどのユーザにより制御されるデバイスを指し得る。
【００２８】
通常、限定されたＩｏＴ（ＬＩｏＴ）デバイスの割り当ては、制御ＩｏＴ（ＣＩｏＴ）デバイスに報告され、管理され、又は制御され得る。ＣＩｏＴデバイスにより収集され認定された前述の情報に基づいて、ＡＡは、収集され検証された情報と共に各ＬＩｏＴデバイスのデジタル証明書を作成し得る。例えば、このようなデジタル証明書は、デバイスの一意の識別情報、そのデバイスのタイプ、及び能力を含み得る。これはまた、ＬＩｏＴデバイスとＣＩｏＴデバイスとの関係性、アドレス、インストールされる場所、招待主−招待客プロビジョニングプロセスの関係性、グループメンバーシップ、製造業者の証明、及び他の情報を適宜含み得る。このような証明書は、製品のライフサイクルの全体を通して自動的に継続的に更新及び維持されてよい。
【００２９】
本願発明のセキュリティエコシステムは、デバイスのエンドポイントユニーク識別子 を達成するべくデバイスをプロビジョニングする複数の方法を可能にする。いくつかの実施形態において、ＩｏＴデバイス又はＩｏＴデバイスを組み込んだ製品（テレビ、冷蔵庫、セキュリティシステム、サーモスタットなど）の製造業者が製造時にそれに従って該デバイスに技術を組み込むために、ＩｏＴデバイス製造業者の仕様が作成され得る。いくつかの実施形態において、この技術は、フルカスタムのデジタルロジック、デバイスの既存のデジタルロジックに組み込まれたＩＰ論理ブロック、デバイスに搭載されるＦＰＧＡ技術を用いて実装されるプログラマブルロジック、デバイス独自のカスタムのファームウェアと共に含まれるフルカスタムのファームウェア、又はデバイスのファームウェアに追加されるオープンソース又は所有ファームウェアスタックの形態であり得る。更新可能なプログラマブルロジックリソース及び／又はファームウェアを有するデバイスに関して、この技術はまた、製造後のデバイスで具体化され得る。仕様に適合するいくつかの実施形態は、エンドポイントデバイスと別のエンドポイントとの間の通信回線を証明し、エンドポイント間で確立される通信回線の使用についての条件（例えば、ルール及び／又はビジネスロジック）を確立する、デジタル証明書に通常記録されるデジタル契約書に含まれる何らかのルールをデバイスが遵守するのをサポートするためのＩｏＴデバイスのファームウェアに関するものであろう。このような仕様はまた、ＩｏＴデバイスが既に認証されているエンドポイントとのみ通信し、他とは通信しないことを要求し得る。ＩｏＴデバイスエンドポイントは、これと１つ又は複数の他のエンドポイント、通常は動作上の必要性又は他の必要性を満たすためにこれと通信する必要があるデバイスとの間に通常確立される通信回線を有し得る。
【００３０】
本明細書で説明されるルール、手順、ポリシーは、ＩｏＴデバイスの製造業者並びに潜在的には該製造業者への種々のサプライチェーン供給業者（例えば、チップ、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）など）が、セキュリティエコシステムに一体化されるＩｏＴデバイスの作製に、設計、生産、製造、組み立て、又は他の方法で寄与するために提供されることになる書面での仕様に組み込まれ得る。このような仕様に含まれるのは、セキュリティエコシステムがすべての管理されるＩｏＴデバイスの安全なファームウェアの更新を管理するための方法であり得る。
【００３１】
このようなＩｏＴデバイスエンドポイントの仕様に適合するデバイスファームウェアは、安全な通信回線の確立を通じてまだ認証されていないどの未知のエンドポイントからの通信も拒否又は無視することになり、確立された通信回線を有し且つデジタル証明書によりサポートされる、既に認証されているエンドポイントにのみ通信することになる。デバイスファームウェアは、最初に仕様に適合していてよく、又は後の時点でファームウェアの更新により仕様に適合されてよい。ＩｏＴデバイスは、仕様に適合する状態で作製することができ、又はこのようなデバイスをセキュリティエコシステムの仕様及び説明した機能に概して適合するＩｏＴデバイスとして動作させることになる適切なアプリケーションをインストールしてよいより基本的なデバイスとして、デバイスの所有者（例えば、所有又は制御し得るＩｏＴデバイスのセキュリティ及び管理能力を高めることを望む所有者、製造業者など）が作製することができる。
【００３２】
製品（ＩｏＴデバイスを組み込んでいる）の製造業者に関して説明したのと同様の原理及び手順を適用し、セキュリティエコシステムの能力を利用することにより、所有者は、このような取得又は制御されるＩｏＴデバイスのセキュリティを強化すると共に、このような所有又は制御されるＩｏＴデバイスに対する所有者の管理及び制御を強化し、潜在的には本出願で説明される能力、特徴、及び／又は利点、その他のものを得る。さらに、プロビジョニングステップのすべて又は一部は、ＩｏＴデバイスの製造業者によって行われてよく、及び／又はすべて又は一部は、デバイスの顧客によって（又は代わりに）行われてよい。
【００３３】
いくつかの実施形態において、ＩｏＴデバイスの製造業者は、それらの製造プロセスと動作パフォーマンスとの両方を使用及び最適化するべく、包括的なインストールサポート手順、並びに、構成オプションを備えてよい。セキュリティエコシステム環境内で、ＩｏＴデバイスに、その製造プロセスでの１つのステップとして又は要望に応じてデバイスのサービスを開始するときに、一意アドレス、例えば、インターネットプロトコル（ＩＰ）アドレス又は他の識別子を割り当てることができる。アドレスは、ＩｏＴデバイス上の再書き込み可能なメモリ部に、又は安全なコンポーネントに恒久的な様態で安全に記憶することができる。セキュリティエコシステムのデバイスの製造仕様は、アルファベット／数字又はＱＲコード又はその両方により、デバイスのアドレスをデバイス自体で見ることができることを必要とし得る。
【００３４】
仕様は、デバイスの電源を入れるときに、デバイスが、そのモデルナンバー、シリアルナンバー、公開鍵、現在のホワイトリスト、現在のファームウェアバージョンなどの他の識別情報と一緒に、そのアドレスと共に「Ｈｅｌｌｏ」メッセージなどの確認メッセージをブロードキャストするように、デバイスが随意的にプログラムされることを可能にする。この特徴の使用の一例は、製造設備で自動車にコンポーネントがインストールされている期間中である。テスト、組立、インストール、品質検査などの間のあらゆる時点で、技術者はデバイスに電源投入し、テストしてよく、これにより、該デバイスを包括的に識別するデバイスの一意の「ｈｅｌｌｏ」メッセージを取り込む。この特徴は、自動車におけるインストールの場所に関連付けられる固有のデバイス名称を分類する及び割り当てるのに有用であり得る（これらのメッセージは後でディスエーブルにされてよい）。
【００３５】
いくつかの実施形態において、ＩｏＴデバイスの引き渡しの前の変更不可の製造業者証明書が、ＩｏＴデバイスの製造業者の仕様に含められ得る。このような異議を唱えることができない証明書は、安全なコンポーネントに記憶されるＰＫＩ証明書又は他のデジタルトークン、若しくはローカルに又はリモートに読み出し可能なデバイス上の物理データレコードなどの複数の容認できる形態のうちの１つとすることができる。本願発明のセキュリティエコシステムへの組み込みを意図されたＩｏＴデバイスの製造時に、製造業者は、以下のうちの１つ又は複数を認定することを求められ得る：（ａ）デバイスを出る又はデバイスにより受信されるすべての通信は、ＩｏＴデバイス上で実行する指定のアプリケーションによって制御され得る（例えば、デバイスファームウェアがセキュリティエコシステムの安全な通信回線技術を認識及びサポートする）、（ｂ）デバイスを出る又はデバイスにより受信されるすべての又は指定された通信は、更新可能なホワイトリスト上のＩＰアドレス及び／又は招待主−招待客プロトコルを通じて認証されるエンティティに関連付けられる及び／又は認可されたエンドポイントによりデバイスに他の方法で提供されるアドレスにのみ送信され得る、（ｃ）適切とみなされ得るさらなる条件、及び（ｄ）製造業者証明書は作成されないこと。
【００３６】
いくつかの実施形態において、いくつかのＩｏＴデバイスのケースでは、ユニーク識別子又は暗号鍵は、デバイスの製造プロセス中に事前にインストールされてよく、又はいくつかのケースでは、デバイスの製造後に導入される。いくつかの実施形態において、デバイス上のユニーク識別子 又は暗号鍵を提供するのにトラステッドプラットフォームモジュール（ＴＰＭ）又は物理複製困難関数（ＰＵＦ）が用いられ得る。ＰＵＦ技術によれば、セキュリティ鍵及びユニーク識別子 は、デバイス内の半導体の本質的特徴から抽出することができる。これらの一意鍵は、通常、必要なときにのみ生成され、通常、システム上に記憶されたままではなく、したがって、高レベルの保護を提供する。ＰＵＦ技術で生成される一意鍵は、ルート鍵を確立するべく暗号システムのブートストラッピング（セキュリティエコシステムのＩｏＴ／エンドポイントクライアント内で必要とされるものなど）を可能にする。いくつかの実施形態において、暗号アルゴリズム及び／又は鍵は、デバイスの内部のいくつかのセキュリティサブシステムにおけるアプリケーションソフトウェア／ファームウェアから保護又は分離される。
【００３７】
いくつかの実施形態において、セキュリティエコシステムのＩｏＴデバイスクライアントアプリケーションが、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）上に又は他のタイプの集積回路（ＩＣ）にインストールされ得る。例えば、ＦＰＧＡ、コントローラ、又はマイクロプロセッサは、ローカルキーストアモジュール（ＬＫＳＭ）、セキュリティエコシステムによりデバイスに割り当てられるグローバルユニーク識別子 （ＧＵＩＤ）、デバイスに関連付けられる公開鍵、及びＩｏＴデバイスが信用するべきエンドポイント（例えば、ファームウェア署名局、ＩｏＴ管理デバイス、ＩｏＴサポートグループなど）のうちの１つ又は複数を含み得るＩｏＴデバイスクライアントと共にプロビジョンされ得る。ＬＫＳＭは、通常、例えば、そのうちのいくつかは安全なコンポーネントにインストールされ得る（ａ）署名生成及び署名検証のための鍵ペア、（ｂ）暗号化及び復号のための鍵ペア、（ｃ）データの一体性を検証するための対称鍵、及び（ｄ）（潜在的にデバイスクライアント又は暗号法マイクロプロセッサにより、或いは潜在的にセキュリティエコシステム・サーバ又は他のものにより最初に生成された）デジタルアセット固有の鍵の暗号ラッピング／アンラッピングを管理するデバイスにおける暗号化管理システム（例えば、これは、対称曲線、非対称曲線、楕円曲線、及び／又は暗号機能を提供し得る）を含む。
【００３８】
図１は、本願発明のいくつかの実施形態に係る、ＩｏＴデバイスの例示的なプロビジョニングプロセスを示す。通常、インストール者は、コンピューティングデバイス１１４でこのプロセスを監督することになる、或いは内部インテリジェンスを有するＩｏＴデバイス又は人工知能プログラムなどのプログラムにより制御されるコンピューティングデバイスによってプロセスを制御し得る。セキュリティエコシステムのクライアントアプリケーションがＩｏＴデバイス上にまだインストールされていない場合、インストール者のコンピューティングデバイス（１１４）から又はセキュリティエコシステムプラットフォーム１０８からダウンロードされる（１０１）。セキュリティエコシステムプラットフォーム１０８は、ＰＫＩ、ＰＭＩ、ＡＡなどのうちの１つ又は複数を含む。１０２で、セキュリティエコシステムに登録されているクライアントのインストール中にクライアントインスタンスに一意ＧＵＩＤが関連付けられ得る（例えば、インストール者のコンピューティングデバイス１１４を介して送信される）。１０３で、まだ生成されていない場合に、一意ＰＵＦにより生成されるＩＤが、デバイス上で作成され得る。１０４で、デバイス内のプロセッサ上の暗号化機能が、セキュリティエコシステム１０８に直接に又はインストール者のコンピューティングデバイス１１４を介して送信される、少なくとも１つの公開鍵との１つ又は複数の公開／秘密鍵ペアを作成してよく、同じく送信されるのは、そのモデルナンバー、シリアルナンバー、タイプ名、現在のホワイトリスト、現在のファームウェアバージョンなどのデバイス識別情報であり得る。
【００３９】
１０５で、ＡＡにより、以下のうちの１つ又は複数でデバイスのアイデンティティを証明するデバイスに証明書が提供される：デバイスクライアントＧＵＩＤ、デバイスＩＤ、デバイス公開鍵、デバイスパブリックアイデンティティ（例えば、タイプ名、シリアルナンバーなど）。１０６で、デバイスは、デバイスの仕様、アイデンティティ、役割又は機能、その公開鍵、及び潜在的には他の情報のうちの１つ又は複数を含む、デバイスのアイデンティティをアサートするデジタルアイデンティティトークン（以下の段落でさらに説明される場合のＤＩＴ）を作成及び署名し得る。このＤＩＴは、インストール者のコンピューティングデバイスに又は潜在的にはセキュリティエコシステム（又は他の実施形態では内部インテリジェンスを有するＩｏＴデバイスに、又は人工知能コンピュータプログラムにより制御されるコンピューティングデバイスに）提示することができ、これは、デバイスのアサーションをレビュー及び確認し、次に、潜在的にはデバイスのアサーションへのその確認を認定し、その後、デバイスのデジタル署名されるアサーションをデジタル署名し、それを１０７でセキュリティエコシステムに送信する。随意的に、セキュリティエコシステム１０８は、これらのアサーションをレビューし、それらを肯定する属性証明書又はＤＩＴを作成し得る。セキュリティエコシステムは、ＩｏＴデバイスが信用するべき及びデジタル署名するべき他のデバイス及び／又はグループ（例えば、ファームウェア署名局、本出願で後でより詳しく説明される自動車整備士グループ）の公開鍵証明書を提供し、それらが信用されるべきものであると認定し、次いで、１０９でＩｏＴデバイスに公開鍵証明書を提供し得る（潜在的にはインストール者のコンピューティングデバイス１１４を介して送信される）。いくつかの実施形態において、ＣＩｏＴデバイス（本明細書で説明される場合の）が、上記のステップのうちの１つ又は複数においてインストール者のコンピューティングデバイスと置き換えられてよい。
【００４０】
いくつかの実施形態において、ＩｏＴデバイスはＤＩＴを備える。通常、ＤＩＴトークンは、既存のＩｏＴデバイスクライアント内から作成されてよく、これにより、該ＩｏＴデバイスクライアントのデジタル署名機能を活用する。トークンは、通常、該発行元デバイスのデジタル署名を含む。ステップ１０７において、構成可能な様々な識別フィールドでトークンが作成され得る。ＩｏＴデバイスのケースでは、これらは、デバイスの製造業者、シリアルナンバー、デバイスのタイプ、デバイスのモデル、ＧＵＩＤ、発行日などを含み得る。
【００４１】
いくつかの実施形態において、デジタル署名及びプロダクトキーをチェックすることによりブートローダ及び／又は重要なオペレーティングシステムファイルでの不正変更を検出するべく、安全なブート及びソフトウェア証明機能が提供される。無効なファイルは、システム又はデバイスを攻撃する又は感染させる前に実行をブロックされ、ＩｏＴデバイスに、動作時の信用の基礎を与える。加えて、信用される実行技術は、対象コンポーネントに関するユニーク識別子 を作成するのに暗号（又は他の）技術を使用し、既知の良好なソースとの起動（又はオペレーティング）環境の要素の正確な比較を可能にし、一致しないコードの開始を阻止する（又は適切なデバイス又はエンドポイント又はセキュリティエコシステムに警告を送信する）。いくつかの実施形態において、検出は、ＰＵＦなどのデバイスファームウェアインストールのデジタルフィンガープリントであってよい。このようなフィンガープリント（又は暗号ハッシュ又は他のその派生物）は、ＤＩＴに組み込まれ又はデジタル署名され、別個の検証として用いられてよい。これらのコンポーネントのうちの１つ又は複数は、１つ又は複数の別個のプロセッサに一体化されてよい。（例えば、図１のステップ１０５及び１０９参照）。
【００４２】
いくつかの実施形態において、プロビジョニングプロセスはまた、信用されるユーザ、デバイス、エンティティなどに関連付けられる公開鍵のＬＫＳＭ又は安全なコンポーネント又は他の容認できるストレージへの追加を含むことになる。例えば、信用されることになる最も重要な追加される公開鍵のうちの１つは、セキュリティエコシステム、及び用いられることになるすべての将来の信用される公開鍵の公開鍵証明書の署名者からのものであろう。
【００４３】
信用される検証は、いくつかの方法で達成することができる。自動車の組み立てに関するいくつかの実施形態において、セキュリティエコシステムは、（例えば、ブレーキ制御ユニットのＩｏＴデバイスクライアントの公開鍵を用いることにより）そのＩｏＴデバイスクライアントだけがアクセスすることになるブレーキ制御ユニットの新たにインストールされたＩｏＴデバイスファームウェアクライアントに、一意ＩＤ又はデジタル証明書の形態の信用されることになる公開鍵証明書を発行する。ブレーキ制御ユニットのＩｏＴデバイスクライアントは、その一意ＩＤを単独で復号し得る。ＩｏＴデバイスは、次いで、潜在的にはその秘密鍵を用いて暗号化されるその一意ＩＤで構成されるデジタル署名されたトークンを作成し、これをセキュリティエコシステムに返す。
【００４４】
セキュリティエコシステムは、ブレーキ制御ユニットのＩｏＴデバイスクライアントが、信用されることになるデバイスの一意ＩＤ及び／又は公開鍵証明書を一意に受信したことを確認する容認できるデジタルトークンを提供したことを検証する。セキュリティエコシステムは、次いで、正しい鍵検証を確認するメッセージを作成し、信用されることになる公開鍵に関連付けられる秘密鍵を用いてこれにデジタル署名し、これをブレーキ制御ユニットのＩｏＴデバイスクライアントに返す。署名された確認の真実性が、信用されることになる公開鍵を用いて検証され、確認が完了する。その後、さらなる信用される鍵が追加されてよく、セキュリティエコシステムからの他の検証されるメッセージが、この又は同様のデジタル署名機能を通じて検証されてよい。その信用される公開鍵が追加され得る信用されるエンティティの例は、コード署名局、整備士グループ、指定のデバイスなどを含む。
【００４５】
いくつかの実施形態において、ＩｏＴデバイスに関する招待主−招待客プロトコルの使用を通じて、プロビジョンされるＩｏＴデバイスが追加されてよい。ユーザ、セキュリティエコシステム、マスターＩｏＴデバイス管理エンティティ（例えば、ＣＩｏＴデバイス）、内部インテリジェンスを有するＩｏＴデバイス、セキュリティエコシステムへの（例えば、ＰＫＩ／ＰＭＩ及び／又は属性局への）アクセスを有しセキュリティエコシステムのアクションを誘導する人工知能（ＡＩ）システムなどのいくつかの認可されたエンティティによって、指定されるＩｏＴデバイス間の固有の関係性の判定がなされてよい。これらのうちの１つ又は複数は、ルール及び／又はビジネスロジックの確立を含む（又は潜在的には既存のルール及び／又はビジネスロジックの修正に限定される）、指定されるＩｏＴデバイスに１つ又は複数の他の指定されるＩｏＴデバイスとの安全な通信回線を確立するように指示するのにセキュリティエコシステムを使用し得る。適正な命令は、通常、このような要求に関するデジタル署名される認可と一緒に、招待主デバイスと招待客デバイスとの両方の適切な識別を含むことになる。
【００４６】
招待主−招待客プロセスでの認証を容易にするために、セキュリティエコシステムのＡＡは、招待主−招待客のいずれか又は両方に、招待主−招待客プロトコル中に用いられることになる質問及び／又は該質問への答えを提供し得る。このようなセキュリティエコシステムにより誘導される又は承認されるプロセスを通じて、デバイスは（潜在的には人工知能機能の追加使用を通じて又は内部インテリジェンスを有するＩｏＴデバイスにより）、直接の人間の介入又はアクションの必要を伴って又は伴わずにこのような命令を実行し、信頼される第三者ＡＡのサポートによりそれらの間の安全な通信回線を確立することが可能であり得る。いくつかの実施形態において、招待主−招待客プロセスは、人間のインストール者により又は自動プロセスにより制御又は管理される。ＩｏＴデバイスの招待主−招待客プロトコルの実行の成功は、結果的に、いくつかの実施形態においてＸ．５０９に準拠するセキュリティエコシステムのＡＡにより作成及び記録されるデジタル契約書（本明細書で説明される場合の）と共に所望の通信回線及び属性証明書の確立をもたらす。
【００４７】
図２は、本願発明のいくつかの実施形態に係る、安全な通信回線を相互に確立するべくＩｏＴデバイスを招待するためのセキュリティシステムを示す。この図は、ヒューマンマシンインターフェースユニット２１２をセキュリティエコシステム２０４に加えるべく招待することを望んでいる、セキュリティエコシステム・ユーザ／エンドポイント（例えば、システム又はデバイスインストール者２１４）の自動車ユースケース例を示し、このシステムでのインストール者は、ヒューマンマシンインターフェースユニットに属するものとしてその後識別されるＩｏＴデバイスクライアントがインストールされ、この固有のヒューマンマシンインターフェースユニットに関して制御され、詐欺師により取り込まれていないことを確実に知ることができることを望んでいる。セキュリティエコシステムプラットフォーム２０４は、ＰＫＩ、ＰＭＩ、ＡＡなどのうちの１つ又は複数を含む。また、インストール者２１４は、このヒューマンマシンインターフェースユニットのＩｏＴデバイスクライアントがセキュリティエコシステム・ネットワーク上で唯一のものであることを知ることを望み得る。このＩｏＴデバイスとのデジタルレコードの管理の連鎖プロセスを通じて、クライアントがセキュリティエコシステムにより認定され得る。
【００４８】
新しいユーザ／デバイス（この例示的なケースではヒューマンマシンインターフェースユニット２１２）が招待され（２０１）、ＩｏＴデバイスクライアントのインストールプロセスに進むときに、ＩｏＴデバイスクライアントは、デジタルアイデンティティトークンを有しているかどうかを尋ねられてよい。有している場合、ＩｏＴデバイスクライアントは、２０２により示されるようにデジタルアイデンティティトークンをロードする。インストール者２１４がそのＤＩＴへの証明書を提供し、２０３で、これをセキュリティエコシステムに送信してよい。次いで、２０４により示されるセキュリティエコシステム・ネットワークは、真正性に関するトークンを分析し得る。各トークンは一意であり、単一のセキュリティエコシステム・ユーザに関してのみインストールされ得る。いくつかの実施形態において、そのＩｏＴデバイスクライアントに関するインストール成功のさらなるアウトオブバンド確認が含められる。アウトオブバンド確認の例は、検証プロセスに含まれてよく、この場合、セキュリティエコシステム２０４は、２０５により示されるように、それが唯一アクセスすることになるヒューマンマシンインターフェースユニットの新たにインストールされたＩｏＴデバイスクライアントに一意ＩＤ（ヒューマンマシンインターフェースユニットの公開鍵を用いて暗号化され得る）を発行する。次いで、２０６で、ヒューマンマシンインターフェースユニット２１２のＩｏＴデバイスクライアントは、その一意ＩＤ（潜在的にはその秘密鍵を用いてデジタル署名される）を、確認しているシステムのインストール者に提供することになる。
【００４９】
いくつかの実施形態において、２０７で、システムのインストール者は、ヒューマンマシンインターフェースユニット２１２のインストールの完了を個人的に確認したという証明書をセキュリティエコシステム２０４に発行し、随意的に、例えば、自分のクライアントアプリケーションの使用を通じて、セキュリティエコシステムへの自身の証明書と共にこのような一意ＩＤを含める。このような確認（特に、セキュリティエコシステムにより発行される一回限りの一意ＩＤの使用による）は、安全なインストールリンクの完了を確認することになり、その後、２０９により示されるように、該ＩｏＴデバイスクライアントと他の検証されたセキュリティエコシステムのＩｏＴデバイスクライアントとの間で送信される将来のデジタルレコードの管理の連鎖をサポートすることができる。いくつかの実施形態において、説明した招待主−招待客プロセスは、デジタル署名に部分的に基づいて監査証跡を生成する。さらに、セキュリティエコシステム２０４の他のアクション及びアクティビティは、デジタル署名に部分的に基づいて監査証跡を生成し得る。
【００５０】
招待客処理の完了成功は、招待主により差し出される任意のデジタル契約書の受け入れを含意すると理解され得る。これは、招待客が所有する新たに生成される属性証明書により参照される証明書内の対象公開鍵に対応する招待客のホストコンピュータ／クライアント／デバイスによる署名生成秘密鍵の使用を含み得る。いくつかの実施形態において、Ｘ．５０９プロトコル属性証明書（ＡＣ）は、招待主・招待客処理の基礎となる。招待主−招待客処理の結果として、セキュリティエコシステム２０４は、双方の合意の下で、企業レベルで管理されるアイデンティティと、各認証及び認可されたユーザ／エンドポイントへの一意の通信回線とをペアにする。
【００５１】
デバイス及び／又はデータのセキュリティ及び／又はプライバシーの１つよりも多いレイヤを提供するべく、安全な通信回線及びデバイスグループ管理が適用され得る。このような特徴は、以下のうちの１つ又は複数を適用することによって達成され得る：（ａ）安全な通信回線に関連付けられ得るルール／ビジネスロジック、（ｂ）グループに関連付けられ得るルール／ビジネスロジック、及び／又は（ｃ）（エンドポイントがＩｏＴデバイスであるか又は他のコンピューティングデバイスであるかのいずれにせよ）指定されたグループ及び／又はサブグループ及び／又は外部エンドポイント間の通信のみを許可する。これらの能力は、個々に又は集合的に、セキュリティの階層化を提供し得る。
【００５２】
いくつかの実施形態において、グループは、（認可されたエンドポイントにより）直接にと、（認可されたユーザにより）ＡＰＩの使用を通じてとの両方で制御され得る。このような制御は、グループ及びサブグループの作成、デバイス又は他のエンドポイントをメンバーとして追加及び削除する機能、グループに名前を付ける機能、グループメンバーが従うためのルールを作成及び修正する機能、及び他のアクション又はデータを含み得る。このようなグループパラメータを作成又は修正するために、認可されたエンドポイント又はＡＰＩユーザの側の権限の勾配が存在し得る。人工知能（ＡＩ）ソフトウェアが認可されたユーザになり得る。
【００５３】
図３は、本願発明のいくつかの実施形態に係る、車両におけるＩｏＴデバイスの複数のペア間の安全な通信回線を確立するためのセキュリティシステムを例示する。１つ又は複数のデバイスプロビジョニング方法及び招待主−招待客プロセスの使用を通じて、ユーザ／デバイス及び／又は製造又は組み立てられた製品内のＩｏＴデバイスは、デバイスで一意の存在を確立し、それぞれのアイデンティティを認証し、リンクし、相互間の認証された、検証された、安全な通信回線を確立することができる。これは、エンドユーザデバイス３０２、複数の人間により操作されるエンドユーザデバイス、又はエンドユーザデバイスを操作するインストール者３０１によりヒューマンマシンインターフェース制御ユニット３０５を介して監督される１つ又は複数のデバイスによって行われ得る。
【００５４】
これらは、随意的に、他の同様にペアにされるデバイスの追加が、定義されたグループへ編成され得る、デバイス３０３（例えば、ヒューマンマシンインターフェース制御ユニット３０５及びテレマティクス制御ユニット３０６）間の関係性の形成に用いられてよい。例えば、暗号により保護されるグループは、該グループ３０７との安全な、保護された、監査可能な通信を確立するべく車両３０４、航空機、医療機器などの単一の工業製品内に組み込まれ得るそれらの通信回線を伴うデバイスのすべてを含み得る。デバイスの１つ又は複数のサブグループが、グループ３０８内で、又は潜在的にはデバイスとグループ及びグループ外のデバイスとの組み合わせで形成されてよい。さらに、グループメンバー、それらの情報、メンバー間の通信回線、グループメンバーシップ、及び／又は他の関連情報のレコードが、セキュリティエコシステムにおいて確立され、記録され、及び／又は取り消されてよい。デバイスグループメンバーシップ並びに該グループのメンバーシップに関連付けられるルールが、該グループ内のデバイスの１つ又は複数の通信回線に（ＡＡにより直接又は間接的に）付加される証明書上に含められてよい。
【００５５】
この技術がセキュリティを向上し得る１つの可能な応用例は、車両におけるコントローラ・エリア・ネットワーク（ＣＡＮ）バスである。デバイスグループ管理は、指定されたグループ及び／又はサブグループ間の通信のみを許可することによりセキュリティの１つよりも多いレイヤを提供し、したがって、セキュリティの階層化を提供する。また、通信回線及び／又はグループに関連付けられるルールの使用は、例えば、データの暗号化の要件を含めることによって、データプライバシーに関する情報の取り扱いをさらに指示し得る、又はどのようなデバイス／エンドポイントが指定のデータを受信し得る又は受信し得ないかを指示し得る。この技術は、このようなユースケースでの通信の粒度及びデータセキュリティ要件に対処し得る。
【００５６】
このような技術のさらなる応用例は、ＩｏＴデバイスを組み込んだ工業製品（例えば、車両、航空機、医療機器など）からのデータが外部エンドポイントに送信され得る用途を含む。例えば、自動車分野では、様々なこのような用途は、（Ａ）自動車を互いに通信可能にするように設計される、車車間（Ｖ２Ｖ）自動車技術、（ｂ）車両と道路インフラストラクチャとの間の重要な安全性データ及びオペレーショナルデータの無線交換を含む、車とインフラストラクチャ間（Ｖ２Ｉ）、（ｃ）グリッドに電気を返すことにより又はそれらの充電率を抑制することによりデマンドレスポンスサービスに売電するべく特定の電気自動車又はハイブリッド車が電力網と通信するシステムである、車とグリッド間（Ｖ２Ｇ）、（ｄ）すべての車両とインフラストラクチャシステムが互いに相互接続され、したがって、道路網全体にわたる交通状況のより正確な知識を提供する、インテリジェント輸送システムを指す、車とＸ間（Ｖ２Ｘ）、（ｅ）車両の自己診断・報告機能が車両の所有者又は修復技術者に様々な車両サブシステムの状態へのアクセスを提供し得る、自動車に用いられるオンボード診断（ＯＢＤ）、及び（ｆ）このようなタイプの工業製品へのアクセス（政府のアクセスを含み得る）又はこのようなタイプの工業製品からの情報を望み得る他の外部ソース、などの普及したものとなることが期待される。
【００５７】
例えば、Ｖ２Ｖ通信は、道路上の無線アドホックネットワークを形成すると期待される。Ｖ２Ｖ通信は、速度、ブレーキアクション、走行距離、及び場所などの、自動車の運転及び条件を監視するセンサなどのＩｏＴデバイスの入力を用いることによって機能する。収集したデータは、暗号化により保護されてよく、イベントの発生後に無線ネットワークを用いてサーバに自動的にアップロードされてよい。
【００５８】
システムのグループ、安全な通信回線、及びルール／ビジネスロジックは、デバイス及び／又はデータへの固有の外部アクセスを制御するのに有用である。例えば、Ｖ２Ｖアクティビティに必要とされる外部センサが「外部センサグループ」へグループ化され得る。プライバシーに対する懸念に関して、外部センサグループは、制御又は限定された識別情報（例えば、車両の一般的なメーカー及びモデルのみ）を有し得る。運転手又は車両登録に関する個人情報は、（例えば）そのグループのメンバーシップに関連付けられるルールの使用を通じて、その外部センサグループにおけるデバイスからプライベートのままであり得る。Ｖ２Ｖセンサと通信することを許される他の車両のデバイス（又は潜在的には据置型又は他のタイプのコンピューティングデバイス）は、通常、外部センサグループにおけるこれらのセンサ以外の車両におけるデバイス又は情報にアクセスするための資格証明書を有さず、したがって、ルール／ビジネスロジックにより制限され得る。このようなセンサは、通常、車両内の固有のデバイス及び情報への注意深く定義された、限定された、認証されたアクセスを有し得る。
【００５９】
いくつかの実施形態において、外部センサグループは、外部から送信し得るそれ自身のアイデンティティに関する可変の構成を有し得る。システムの構成は、車両又はそのセンサ（ＩｏＴデバイス）の或る動作モード及び／又は動作時間に基づいて動的に変化し得る複数のアイデンティティを維持できるエンドポイントを提供する。すなわち、車両又は車両デバイスグループは、複数のアイデンティティを有し得る。１つのアイデンティティは、最低限、車の一般的なメーカー及びモデル、例えば、「外部センサグループ」により用いられるアイデンティティであり得る。車両はさらに、ナンバープレート、登録情報、保険情報などのより詳細な１つ又は複数のアイデンティティを有し得る。このような可変識別子構成は、自動で又は手動で修正され得る。いくつかの実施形態において、車両識別子の選択は、車両、例えば緊急車両の定義されたクラスにプロビジョンされ得る。いくつかの実施形態において、緊急事態で動作していない消防車は、大型車両の又は非緊急の消防車のアイデンティティをブロードキャストし得る。しかしながら、消防車がその動作を緊急呼び出しへの応答モードに変化させる場合、該消防車のアイデンティティが、要請に応える緊急車両としてブロードキャストされ得る。
【００６０】
このような異なる信号を受信する車両は、通常、様々に応答するであろう。例えば、消防車が「非緊急の消防車」のアイデンティティをブロードキャストしている場合の動作の変化は皆無かそれに近いが、その同じ消防車がそのアイデンティティを「要請に応える緊急車両」のアイデンティティに変化させる場合、別の車両の運転手は、通常、道路脇に寄せることになる（自律車両の場合、道路脇に寄せることは自動であり得る）。消防車によってブロードキャストされるメッセージはまた、減速して道路脇に寄せる、次の交差点まで前に詰めて、この道路を完全に出る、この消防車が左折できるように前に詰める、又は所望であり得る任意のメッセージなどの命令を含み得る。
【００６１】
図３Ａは、本願発明のいくつかの実施形態に係る、車両における例示的なタイプのＩｏＴデバイスを示す。図示したように、参照番号３１は、（例えば）「内部ＩｏＴデバイスグループ」のＩｏＴデバイスを表す。いくつかの実施形態において、これらのＩｏＴデバイスは、通常、外部から接続しない。例は、車両のオペレーションに用いられる電子制御ユニット（ＥＣＵ）及び他のデバイスを含み得る。参照番号３２は、例えば、車両の外部領域を監視するセンサ、及び車両の外部の他のデバイスと通信し、それらと情報を共有するデバイスを含み得る、「外部センサデバイスグループ」におけるＩｏＴデバイスを表す。いくつかの実施形態において、参照番号３１及び３２のデバイスのいくつか又はすべては、同じ車両におけるすべてのデバイスを含む「車両デバイスグループ」に組み合わされてよい。
【００６２】
システムが、デジタル証明書、デジタルアイデンティティトークン、信用される公開鍵、グループ鍵などをサポートするという事実のために、消防車のブロードキャストメッセージは、受信側ノード、例えば、車両ノード又は交通信号灯のようなインフラストラクチャコンポーネントなどの非車両ノードが、ブロードキャストされるメッセージが正当であり、信用されるべきものであると信じ得るようにデジタル署名され得る。いくつかの実施形態において、システムの公開鍵基盤（ＰＫＩ）、デジタル証明書、認証された通信回線、デジタル署名などは、メッセージ認証、安全なグループ分け、プライバシー、及びセキュリティなどの特徴をサポートする。
【００６３】
消防車以外の様々な緊急車両及び他の政府車両グループタイプ、並びに、このような機能が使用されるようにし得るインフラストラクチャグループタイプが存在し、例は、救急車、警察車両、牽引トラック、危険物（ＨＡＺＭＡＴ）車両、軍用車両、交通信号灯、街路灯、防火設備などを含む。送信者ＩＤ、送信されるメッセージ、デジタル認証の粒度などは、異なるユースケースで変化し得る。いくつかの実施形態において、車両、インフラストラクチャ、又は他のサポートされるデバイスにより共有及びブロードキャストされるメッセージ又は情報は、要求タイプ及び／又は要求者の固有の要求に応じて変化し得る。
【００６４】
車両（又は他のエンドポイントデバイス又は工業製品）によって提供され得る層をなした情報のシステム又は層をなしたアイデンティティの組が、１つ又は複数の承認された機関のメンバーからの要求の受信時に自動又は手動でリリースされ得る。例えば、警察車両は、該警官に関連付けられる権限に基づいて車両ナンバープレート又は登録アイデンティティ又は情報を要求し得る。さらなる機密情報（例えば、保険情報）の要求は、普通の警官が有し得るものよりも高い権限を必要とし得る。このような機密情報の要求は、より高位の権限から来るものでなければならない、又は警官が車両によってリリースされることになるこのような情報のレポートをファイルする又は要求をファイルすると、警官に権限が提供されてよい。
【００６５】
制御された情報の要求及び応答は、自動又は手動でなされてよく、適切なデジタル証明書、デジタル署名、又は他のシステムによりサポートされる方法が付随し得る。定義されたレベルの制限されたアクセスが、任意の外部デバイスに提供されてよい。しかしながら、前述のように、認証された関係性又はグループメンバーシップに基づいて粒度により定義された外部グループに、粒度的により高レベルのアクセスが提供されてよい。このようなアクセスの例は、（ａ）車両整備士グループ、（ｂ）しかるべき政府のモニタリングの必要性のためにオンボード診断（ＯＢＤ）ポートにアクセスすることを政府により承認されたグループ、を含み得る
【００６６】
図４は、本願発明のいくつかの実施形態に係る、ＩｏＴデバイスを含む新しい製品を認証するためのセキュリティシステムを示す。ＩｏＴデバイスを組み込んだ工業製品は、通常、購入者、賃借人、又は他のエンドユーザに販売される、又は他の方法で提供される。いくつかの実施形態において、このような製品は車であり、この場合、購入者４１１が車４１２を買う。このようなケースでは、購入者の購入は、車、車に関連付けられるＩｏＴデバイスについての関連情報及び認証される情報、及び他の情報を包含するデジタル証明書４０１の組み込みを通じてより安全にされる。このようなデジタル証明書４０１は、セキュリティエコシステム４０２から購入者のモバイルデバイス４０３、タブレットデバイス４０４、コンピュータ４０５、又は他のデバイスに配信され得る。セキュリティエコシステムプラットフォーム４０２は、ＰＫＩ、ＰＭＩ、及びＡＡのうちの１つ又は複数を含む。購入者４１１は、例えば、セキュリティエコシステムを通じて認証されているセキュリティエコシステムによりサポートされるモバイルデバイス４０６を用いるデジタル署名により、自分の購入契約を実行し得る。これらのデジタルレコード４０７は、次いで、貸手又は他の利害関係者に転送されてよく、リース又はローン契約もデジタル署名され得る（４０８）。
【００６７】
車（潜在的にはリース又はローン文書（４０９））のデジタルレコードと組み合わされた購入レコードは、次いで、（貸手、セキュリティエコシステム、又は他のものにより）不変の様態で記録される（４１０）。このような記録の一例は、４１０により示されるように、Ｂｌｏｃｋｃｈａｉｎ（商標）又は同様のメディア４１８上であり得る。購入者４１１と車の関係性はまた、互いに、購入者デバイス４１３上の購入者のクライアントアプリケーションと、及び車（そのＩｏＴデバイス４１４のうちの１つを通じて）と車の受動キーエントリーシステム（キーフォブデバイス）４１５との両方で認証され得る。次いで、購入者のモバイルデバイス、車、及び受動キーエントリーシステムはすべて、認証されたグループ、例えば、「ＩｏＴデバイスグループ」４１６のメンバーとなる。
【００６８】
図５は、本願発明のいくつかの実施形態に係る、ＩｏＴデバイスを含む製品の整備のためのセキュリティシステムを示す。製品、例えば、車５０１を整備のために自動車販売代理店５０２に運ぶとき、車の内部ＩｏＴデバイスへのアクセスは、車５０１に既にインストールされているセキュリティ機能により保護することができる。例えば、アクセス５１０しようとしている整備工５０３は、セキュリティエコシステム５０７内に既に登録されている端末デバイス５０６上のアプリケーションを通じて車のヒューマンインターフェース制御ユニット５０５にアクセスするのに適切な資格証明書５０４を有していなければならないであろう。整備工、アプリケーション、又は他の容認できるアイデンティティは、この目的のために適正な認証を明示する必要があるであろう。例えば、それらのうちの１つは、車に特定のタイプの保守作業を行うための定義可能な権利と共に車内のＩｏＴデバイスにアクセスする権限を有する販売代理店の整備士グループの認証されたメンバーであり得る。例えば、整備工は、エンジン制御ユニットに不具合があると判断し、これを取り外し（５０８）、次いで、交換品をインストール（５０９）してよい。整備工は、通常、セキュリティエコシステム５０７内の車のレコードから不具合のあるエンジン制御ユニットを削除し、これを新しいエンジン制御ユニットレコードに置き換えることになる。交換プロセスは、ＩｏＴデバイス５１１間の適切な招待主−招待客プロセス（及び潜在的には前述のプロビジョニングプロセス）と、ＩｏＴデバイスの交換とセキュリティエコシステム５０７内のその更新されたＩｏＴデバイスグループを反映するための車５０１に関するレコードの更新５１０を含むことになる。セキュリティエコシステムプラットフォーム５０７は、ＰＫＩ、ＰＭＩ、及びＡＡのうちの１つ又は複数を含む。
【００６９】
図６は、本願発明のいくつかの実施形態に係る、安全な認証された通信回線のいくつかの要素を示す。図のように、ＩｏＴエンドポイント６０１は、通常、デバイス上にユニーク識別子 又は暗号鍵を確立する方法としてプロビジョンされる安全なルート鍵を有するべきである。これを行う１つの方法は、ＰＵＦ６０２の使用によるものである。デバイス上に暗号アルゴリズム、安全なキーストレージ、及びクライアントアプリケーションが提供される。一意のＤＩＴが、デバイス６０１によって作成される又はセキュリティエコシステム６０４によって提供され得る。セキュリティエコシステム６０４は、ＰＫＩ、ＰＭＩ、及びＡＡのうちの１つ又は複数を含む。２つのエンドポイント６０１／６０１間の招待主−招待客プロセスの適用を通じて、セキュリティエコシステム６０４内のＡＡからの促進サポートにより、これらのエンドポイントは、それらの間に安全な認証された通信回線６０５を確立することができる。通常、通信回線は、通信回線を証明し、エンドポイント間に確立される通信回線の使用についての条件（例えば、ルール及び／又はビジネスロジック）を確立する、デジタル証明書に記録され得るデジタル契約書６０６が付随する。
【００７０】
図７は、本願発明のいくつかの実施形態に係る、セキュリティエコシステム７０１のいくつかの要素を例示する。セキュリティを主に可能にするセキュリティエコシステム７０１の一意の要素のうちの１つは、エンドポイント自体だけでなくエンドポイント７０３間の通信回線７０２に基づいている。しかしながら、本願発明のセキュリティエコシステム７０１は、エンドポイント７０３に証明書７０４を発行するだけでなく、エンドポイントのペアが確立（確立した）及び使用し得る各認証される通信回線７０５にも証明書を発行する。証明書を有する個々の通信回線とのみ関係性を構築することにより、このようにして効果的に確立されたエンドポイントの通信回線は、ホワイトリストに入れられるようになると考えられ得る。デバイスの通信回線のホワイトリスト作成は、通常、セキュリティを強化すると考えられる。中央管理されるのではなく、通信回線は、通常、エンドポイントのペア間にエンドポイントレベルで確立される。これは、認証されたエンドポイントが、オペレーションの必要性を満たすためにそれらが通信する必要がある、認証された他のデバイスとの安全な通信回線を確立することを可能にする。既に認証されている、発行された証明書７０８を有する、安全な通信回線のない、未知のエンドポイント７０６からの通信７０７は、防止又は無視される７０９（安全な通信を確立するための未知のエンドポイントからの招待は無視されないが、このような招待は、両方のデバイスの認証をサポートするＡＡにより管理される）。これは、スプーフィング対策の結果であり、安全な通信回線を有する適正にプロビジョンされたエンドポイントは、既に認証されているエンドポイントとのみ通信し、他とは通信しない。
【００７１】
図８は、本願発明のいくつかの実施形態に係る、２つのアプリケーション・プログラミング・インターフェース（ＡＰＩ）の例示的な使用を示す。大まかに言えば、ＡＰＩは、種々のソフトウェアコンポーネント間の明瞭に定義される通信方法の組である。セキュリティエコシステムは、２つの別個のＡＰＩをサポートし得る。いくつかの実施形態において、ＡＰＩ８０２は、セキュリティエコシステム８０１の機能にアクセスする、制御する、使用するなどのためにＩｏＴエンドポイント８０３上のクライアントアプリケーションにより用いられ得る。いくつかの実施形態において、ＩｏＴエンドポイントとセキュリティエコシステムは、ＡＰＩなしに他の方法を用いて通信し得る。第２のＡＰＩ８０４は、複数の使用のために、ＩＴ部門からのユーザなどの外部ユーザによって用いられ得る。１つのこのような使用は、セキュリティエコシステムにより作成、維持、及び／又はサポートされる、デバイス（ＩｏＴデバイス並びに非ＩｏＴデバイスを含む）のすべての又はいくつかのステータス、安全な通信回線、証明書、グループ、関係性などを見ることである。このようなＡＰＩは、このような情報に、包括的な粒度が細かい可視性を提供し得る。このような情報は、随意的に、様々な解析の目的で外部システム又はユーザにより用いられ得る。随意的に、ＡＰＩは、セキュリティエコシステムが行い得るアクティビティのすべて又は一部を誘導する機能を提供し得る。いくつかの実施形態において、人工知能コンピュータプログラムの誘導の下で動作する外部システムは、このＡＰＩを使用することができる。
【００７２】
いくつかの実施形態において、本願発明は、デバイスに関して一意にソフトウェア／ファームウェアの更新を提供し得る。例えば、ファームウェア（又はファームウェアに関連付けられる証明書）の画像が、例えば、更新されることになる対象デバイスの安全なコンポーネントのＬＫＳＭによって保持されている信用される公開鍵により認識される確立されたファームウェア署名局によりデジタル署名される。業界標準コード署名技術を用いて、ファームウェアは、コード署名局の秘密鍵を用いてデジタル署名され得る。署名されたコードが対象デバイスに送信される。受信すると、対象デバイスは、コード署名局が実際にコードを署名したことを検証するべく、それが所持している信用される公開鍵を最初に使用する。このような検証後に、対象デバイスはファームウェアの更新を完了し得る。
【００７３】
いくつかの実施形態において、デバイスのファームウェアインストールの一意の画像のデバイスデジタルレコードが提供されてよく、レコードは、次いで、デバイス又は機関によってデジタル署名され得る。必要であれば、後の時点で、新しい画像を作成し、２つの画像が一致するかどうかを判定するべく以前に作成された画像と比較することができる。それらが一致しない場合、攻撃又はデバイスに伴う他の問題が調査され得る又は他のアクションがとられ得る。
【００７４】
いくつかの実施形態において、デジタル署名に部分的に基づいて、セキュリティエコシステム内でとられる他のアクションと共に、招待主／招待客処理、プロビジョニング、グループの確立などのアクションから監査証跡が生成される。いくつかの実施形態は、招待主処理と招待客処理の組み合わせの監査証跡を提供する。
【００７５】
図９は、本願発明のいくつかの実施形態に係る、複数のＩｏＴデバイス間の安全な通信を確立するための例示的なプロセスの流れである。随意的なブロック９０２に示すように、第１及び第２のＩｏＴデバイスが、固有識別子、デジタルアイデンティティトークン、及び暗号鍵を、該第１及び第２のＩｏＴデバイスのそれぞれに提供し、認証することによりプロビジョンされ得る。前述のように、プロビジョニングは、いくつかのＩｏＴデバイスを含む製品の製造時に、製品内にＩｏＴデバイスをインストールする時点で、製品又はＩｏＴデバイスのプログラミングの時点で、又は当該ＩｏＴデバイス間の通信を確立する前のあらゆる時点で行われ得る。いずれのケースにおいても、当該ＩｏＴデバイスは、固有識別子と暗号鍵を有することになり、それらが安全な通信回線を確立する前に認証される。
【００７６】
ブロック９０４で、例えば、属性局（ＡＡ）などの信頼される第三者により、デバイスに第１のデジタル証明書が発行される。ブロック９０６で、第１のＩｏＴデバイスが、第２のＩｏＴデバイスからデジタルトークンを受信することにより第１のＩｏＴデバイスとの（安全にされていない）通信回線を確立するべく第２のＩｏＴデバイスを招待する。ブロック９０８で、本開示の全体を通して詳細に説明されるように、第２のＩｏＴデバイスの固有識別子、デジタルアイデンティティトークン、及び暗号鍵を用いて第２のＩｏＴデバイスが第１のＩｏＴデバイスに認証される。ブロック９１０で、第１のＩｏＴデバイスと第２のＩｏＴデバイスとの間の通信回線に提供される第２のデジタル証明書を用いて安全にされていない通信回線を認証することにより、第１のＩｏＴデバイスと第２のＩｏＴデバイスとの間の安全な通信回線が確立される。このように、本願発明のセキュリティエコシステムは、ＩｏＴデバイス（エンドポイント）に（第１の）証明書を発行するだけでなく、ＩｏＴデバイス（エンドポイント）のペアが確立し使用する各認証された通信回線にも（第２の）証明書を発行する。
【００７７】
ブロック９１２で、第１又は第２のＩｏＴデバイスへの安全な通信回線が確立されていない別の（第３の）ＩｏＴデバイスは、第１又は第２のＩｏＴデバイスとの通信を防止される。
【００７８】
本願発明の方法及びシステムを用いて、種々の認可された者が、工業製品内に存在し得る種々のグループ及びサブグループメンバーシップ及び／又はルール／ビジネスロジックを確立及び／又は監視及び／又は修正することが可能となる。これらは、製造業者、工業製品所有者、管轄裁判所などを含み得る。
【００７９】
いくつかの実施形態において、グループは、外界センサグループ、ＣＡＮバス上のデバイスのグループ又はサブグループ、車両内のすべてのデバイス、エンドポイント、及び指定された車両の整備を担当する外部エンティティなどの機能及び／又は役割を定義する。アクティブグループは、わずか１人のアクティブメンバーを含み得る。グループ管理者は、グループのメンバーと考えられる。グループに関する属性証明書は、グループ特徴（例えば、外界センサグループ、車両、部門、及び／又は役割）を示し、署名検証公開鍵を含む公開鍵証明書を参照する。対応する署名生成秘密鍵が、グループ管理者により保持される。例えば、車両の場合、これは、人間又は人工知能機能により制御され得るマスターＩｏＴデバイス管理エンティティ（例えば、ＣＩｏＴデバイス）であり得る。例えば、車両整備士グループの場合、これは、人間又は人工知能機能により制御され得る指定されたエンドポイント・コンピューティングデバイスであり得る。この鍵は、暗号化又は鍵確立のために用いられるグループ公開鍵を割り当てるのに用いられる。この機構は、属性証明書（又はその交換品）が現在有効であり、且つ署名検証公開鍵が失効されていない限り、グループ管理者がグループ公開鍵に値を（再び）割り当てることを可能にする。
【００８０】
いくつかの実施形態において、グループ管理者がグループの他の現在のメンバーにグループ秘密鍵を安全に提供するための少なくとも２つの方法が存在する：（ａ）見込みグループメンバーの（証明書を生み出す又は他の方法で認証される）暗号化公開鍵又は鍵確立公開鍵を使用することができる、（ｂ）証明書を生み出す又は他の方法で認証される署名検証公開鍵に対応する見込みグループメンバーのデジタル署名生成秘密鍵を用いてデジタル署名されている一時的な鍵確立公開鍵を使用することができる。（グループ管理者でない）グループメンバーのアクセスが削除されるべきである場合、グループ管理者は、グループ公開鍵に新しい値を割り当てて、対応するグループ秘密鍵を、残りのグループメンバーに（並びに、このように追加される場合／このように追加されるときに新しいグループメンバーに）配布することができる。
【００８１】
属性証明書は、通常、安全に認証された永続するプライベートのポイント・ツー・ポイント通信回線を可能にする、招待主が意図した招待客により実行されたアクションの成功（本出願で説明される安全な通信回線を確立するためのすべてのデバイス／エンドポイント認証方法を含む）の結果として、セキュリティエコシステム属性局（ＡＡ）によって、並びに、グループの作成時に生成される。各ＡＡにより発行される属性証明書は、対象公開鍵を含む１つ又は複数のデジタル証明書を指す。このような公開鍵証明書は、セキュリティエコシステムの認証局によって、又は相互認証される外部認証局によって発行され得る。
【００８２】
いくつかの実施形態において、属性証明書は、公開鍵証明書（又は公開鍵の他のカプセル化（例えば、「証明書のない」ＩＤベース暗号（ＩＢＥ））を明示的に参照し、この場合、属性証明書作成要求メッセージ／招待客処理メッセージ（本出願で説明される安全な通信回線を確立するためのすべてのデバイス／エンドポイント認証方法を含む）内の固有の（例えば、招待主によって出される秘密の質問に対する招待客による答えの）ＰＫＣ／公開鍵との暗号学的結び付きは、例えば、ＡＡが脅かされていないサーバインサイダー攻撃により企まれた偽属性に対する保護を提供する。ＡＡは、自称の招待客によって提供された答えが招待主によって供給されたデータに基づいて正しいかどうかを判断することができ、このようなデータは、ＡＡの外部にさらされることを防ぐためにランダム性を賢明に利用する。さらに、招待客の通信及び処理は、偽者への情報の漏れに関してフィッシング耐性があるように設計される。
【００８３】
インターネットプロトコルでのＸ．５０９属性証明書の使用に関するプロファイルを定義するＲＦＣ５７５５  ｈｔｔｐ：／／ｄａｔａｔｒａｃｋｅｒ．ｉｅｔｆ．ｏｒｇ／ｄｏｃ／ｒｆｃ５７５５／によれば、「ＡＣに基づいてアクセス制御決定を行う場合、アクセス制御決定機能は、当該ＡＣ所持者がアクセスを要求したエンティティであることを確認する必要があり得る。要求又はアイデンティティとＡＣとの間のリンクを達成することができる１つの方法は、ＡＣ内にＰＫＣへの参照を含めることと、アクセス要求内の認証に関するＰＫＣに対応する秘密鍵を使用することである」。このような秘密鍵の所持の証明は、対応するＰＫＣへの参照を結果として生じるＡＣに含める条件として招待客プロトコル内でプリエンプティブに用いることができることに留意されたい。ＲＦＣ５７５５はアクセス要求の認証について述べているが、例えば、秘密鍵の知識なしにはアクセスできないままであるデジタルアセット鍵を安全に伝達するのに対応する公開鍵を利用することにより予想されるように、秘密鍵の使用の証拠は暗黙的であり得ることに留意されたい。招待主により出される秘密の質問の使用は随意的なものと考えられ得るが、それらが呼び出される場合、上記で簡単に説明した方法論が、招待主と意図された招待客との間の通信回線の構築の乗っ取りの試みを阻止する。
【００８４】
いくつかの実施形態において、属性証明書と公開鍵証明書とのマッピングはフレキシブルである。例えば、属性証明書は、個々のデバイス／エンドポイントレベル又はグループレベル又は部門レベルで（すなわち、デバイス／エンドポイントレベル／エンドノードレベルで）デバイス／エンドポイント／所持者／所有者に発行されてよく、ＲＦＣ５７５５に従って言及したが、アクセス制御決定機能は、当該ＡＣ所持者がアクセスを要求したエンティティであることを確認する必要があり得る。要求又はアイデンティティとＡＣとの間のリンクを達成することができる１つの方法は、ＡＣ内にＰＫＣへの参照を含めることと、アクセス要求内の認証に関するＰＫＣに対応する秘密鍵を使用することである。このような秘密鍵の所持の証明は、対応するＰＫＣへの参照を結果として生じるＡＣに含める条件として招待客プロトコル内でプリエンプティブに用いることができることに留意されたい。ＲＦＣ５７５５はアクセス要求の認証について述べているが、例えば、秘密鍵の知識なしにはアクセスできないままであるデジタルアセット鍵を安全に伝達するのに対応する公開鍵を利用することにより予想されるように、秘密鍵の使用の証拠は暗黙的なものであり得ることに留意されたい。招待主により出される秘密の質問の使用は随意的なものと考えられ得るが、それらが呼び出される場合、上記で簡単に説明した方法論が、招待主と意図された招待客との間の通信回線の構築の乗っ取りの試みを阻止する。これは、例えば、マスターＩｏＴデバイス管理エンティティ又はエンティティのＩＴ部門サーバで所有及び保持される秘密鍵にも対応する場合があり、したがって、複数の属性証明書が公開鍵証明書を共通に参照し得る。デジタル署名生成秘密鍵の場合（復号及び／又は鍵確立秘密鍵とは対照的に）、デバイス／エンドポイント／エンドノードレベルで行われる（プレーンテキスト）デジタルアセット、メッセージ、又は他のデジタルアセットのデジタル署名に関する例外が作成され得る（一方、セキュリティエコシステムへの通信／要求のデジタル署名は、マスターＩｏＴデバイス管理エンティティ又はエンティティのＩＴ部門サーバで行われる）。
【００８５】
アウトバウンドのデジタルアセット／デジタルアセットに関して、デジタルアセット鍵生成、デジタルアセット暗号化、及びデジタルアセット鍵の目標とされた暗号化は、エンティティのＩＴ部門サーバで行われ得る。インバウンドのデジタルアセットに関して、復号及び／又は鍵確立秘密鍵を用いるデジタルアセット鍵の復元、及び暗号文デジタルアセット復号は、例えば、エンティティのＩＴ部門サーバで行われ得る。特定の機密オペレーション及び／又は特定の鍵デバイス／エンドポイント／従業員に関して、ライブデジタルアセット暗号化又は復号がエンドノード／エンドポイント／デバイスで行われるようなハイブリッド手法が用いられ得る。このようなケースでは、エンドノードで用意され、意図された受信者に向けて送信される、アウトバウンドのデジタルアセットに加えて、特定の条件下でエンティティでアクセス可能なエンドノード／エンドポイントで生成された各アウトバウンドのデジタルアセットのコピーが保持又はアーカイブされ得る。このコピーの生成は、対応する秘密鍵がエンティティに代わってエスクローされている暗号化又は鍵確立公開鍵の使用を必然的に伴い得る。同様に、インバウンドのデジタルアセットに関して、エンドノードの復号鍵又は鍵確立秘密鍵は、特定の状況下でエスクローから入手可能であり得る。
【００８６】
いくつかの実施形態において、関連する公開鍵証明書を参照するために、関連する属性証明書が発行され得る。例えば、２つの関連する属性証明書が発行されてよく、この場合、１つは、暗号化又は鍵確立に用いるための対象公開鍵を含む公開鍵証明書を参照し、もう１つは、デジタル署名検証に用いるための対象公開鍵を含む公開鍵証明書を参照する。いくつかの従来の方法は、（「所持者の公開鍵証明書の発行者及びシリアルナンバー」として）ＡＣ所持者フィールドの基本証明書ＩＤオプション内のＡＣによって単一のＰＫＣのみを参照できることを示すが、ＡＣのシリアルナンバーフィールドは、一意性以外の割り当てに関するどのような固有の要件も有さない、すなわち、ＡＣ発行者により用いられるシリアルナンバーが特定の順序に従うという要件は存在しない。特に、それらは時間と共に単調に増加する必要はない。各ＡＣ発行者は、それが発行する各ＡＣが一意のシリアルナンバーを含むことを保証しなければならない。その結果、多くとも単一のＰＫＣを各ＡＣに関連付けるという制限を取り扱う１つの方法として、関連するＰＫＣを参照するのにＡＣ内の正式に関連するシリアルナンバー（例えば、追加のサブシリアルナンバー以外は同じ）が用いられ得る。この方法は、ＰＫＣを参照する関連するＡＣのＡＡによる生成の前の秘密鍵の所持の明白な証明を引き継ぐことにより、秘密鍵の所持の間接的な、しかし明白な証明に用いることができる。
【００８７】
例えば、適切なデジタル署名されるメッセージ（署名生成秘密鍵の所持を証明する）の提示が、後で受信する暗号化された通信／デジタルアセット／ファイルを正当化するのに用いられてよく、この場合、デジタル署名されるメッセージを生成するのに用いられた署名生成秘密鍵に対応する署名検証公開鍵を参照するＡＣと関係づけられるＡＣにより参照されるＰＫＣにおける暗号化公開鍵又は鍵確立公開鍵の使用に基づいてデジタルアセット鍵が暗号化される。例えばＰＫＣ１とＰＫＣ２とのこの「Ｕ形の」関連付け（ＰＫＣ２を参照するＡＣ１とシリアルナンバーにより関係づけられるＡＣ１により参照されるＰＫＣ１に対応する対象秘密鍵の所持を証明することによる）は、ＰＫＣ１とＰＫＣ２が（このようなデータを電子メールアドレス又はＩＰアドレスとして含み得る対象名又は対象代替名の関連する選択肢などを通じて）多少なりとも直接リンク可能であることに依拠しないことに注目されたい。ＰＫＣ１とＰＫＣ２は、別個のＣＡにより生成することができることに注目されたい。
【００８８】
いくつかの実施形態において、セキュリティエコシステムは、ルーティングにエンドツーエンドの信用が存在するように、ドメインにわたるデジタルアセット、メッセージ又はファイル、及び／又は他の通信の目標とされた配布及び／又は暗号化／復号を仲介するサービスを提供することができることが望ましい。権限管理は、認可（及び／又は、特に名前及び／又は識別子を含み得る他の属性）を含み、且つ、それぞれ対象公開鍵及び対象名を含む１つ又は複数のアイデンティティ証明書（公開鍵証明書としても知られている）を（好ましくは明らかに）参照するように構成することができる、属性証明書により対処できることが知られている。例えば、公開鍵証明書は、公開鍵証明書のハッシュにより又は対象公開鍵のハッシュにより又は公開鍵証明書の他のフィールドのハッシュにより、属性証明書内で参照されてよい。このようなハッシュは、一方向ハッシュであってよい。用いられる実際のハッシュ値は、すべての可能なハッシュ値の組の中で疎であり得る。
【００８９】
いくつかの実施形態において、属性証明書は、以下で説明するデジタルアセット及び通信配布の仲介の基礎として用いることができ、この場合、例えば、「ポインタ値」の参照は、ポインタ値が属性証明書のハッシュ又は属性証明書の１つ又は複数のフィールドのハッシュからなり得るときであり得る。このようなハッシュは一方向ハッシュであり得る。用いられる実際のハッシュ値は、すべての可能なハッシュ値の組の中で疎であり得る。いくつかの実施形態において、ポインタ値は、代替的に又は加えて、属性証明書に関連付けられるが外部のデータに基づいていてよい。このようなデータは、データベース内のインデックスを含み得る。
【００９０】
いくつかの実施形態において、属性証明書は、このモデル内のパブリック情報と必ずしも考えられない。むしろ、意図された受信者又はグループに関連付けられる属性証明書を（好ましくは明らかに）参照する「ポインタ値」の知識（又はそれへの直接又は間接的なアクセス）が、デジタルアセットの通信発信者（例えば、エンドポイント／デバイス、エンティティ又は個人又はグループ）が該特定の属性証明書によって表されるエンティティ又はエンドポイント／デバイス／個人又はグループとやりとりするのに適格とみなされ得る仲介型のセキュリティエコシステムへのインジケータとして用いられる。しかしながら、属性証明書及び／又はポインタ値の認可されていない配布／転送の可能性に対処するために、セキュリティエコシステム又は受信者デバイス又は他のエンドポイントは、要求者がセキュリティエコシステムで利用可能なデータベースに基づいて現在適格とされない場合に、特定の属性証明書に関係するクエリ／要求を拒否してよい。
【００９１】
便宜のため、いくつかの実施形態において、特定の属性証明書によって表されるエンドポイント／デバイス、エンティティ又は個人又はグループは、以下、属性証明書の「所有者」と呼ばれる。これは、アイデンティティ証明書の所有者を、アイデンティティ証明書内の対象公開鍵に対応する秘密鍵の所有者と考えることに類似している。所与のエンドポイント、デバイス、エンティティ、個人、又はグループが、複数の別個の属性証明書によって表され得る。このような複数の別個の属性証明書にわたって、２つ以上のこのような属性証明書にわたって共通に保持される及び／又は２つ以上のこのような属性証明書にわたって共通の公開鍵証明書を参照する、属性が存在し得る。
【００９２】
特定の属性証明書所有者の属性証明書をそれぞれ参照する１つ又は複数のポインタ値の知識へのアクセスは、もしある場合、該属性証明書所有者の他の属性証明書（又はそれらのポインタ値）へのアクセスを必ずしも含意しない。ポインタ値は、受信者にアップロード又は伝送の適格性を提供するために、可能性のあるデジタルアセット／通信アップローダによって必ずしも知られる必要はなく、又は可能性のあるデジタルアセット／通信アップローダに又は可能性のあるデジタルアセット／通信アップローダ（エンドポイント、デバイスを含む）のホストコンピュータ又は他のコンピューティングデバイスに必ずしも直接アクセス可能である必要はない。例えば、このようなポインタ値は、可能性のあるデジタルアセット／通信アップローダのエンドポイント、デバイスに関連付けられるデータの一部であってよい。可能性のあるデジタルアセット／通信アップローダは、セキュリティエコシステムのデバイス／エンドポイント／加入者として、該セキュリティエコシステムのデバイス／エンドポイント／デバイス／加入者のアカウントデータ又は記録情報に保持されるポインタ値への属性証明書所有者に関する以前に付けられた「ニックネーム」を有し得る。
【００９３】
ポインタ値の知識（又はそれへの直接又は間接的なアクセス）は、潜在的には、対応する属性証明書の所有者への通信の成功を可能にし、招待主、デバイス、エンドポイント自身のポインタ値のオファーを提供することが有利であり得る。どのポインタ値及び／又は属性証明書を特定のセキュリティエコシステムのデバイス／エンドポイント／加入者に利用可能にするかに関して仲介型のセキュリティエコシステムに要求を行うことができ、これらのポインタ値は、要求元のデバイス／エンドポイント／加入者がこれらの属性証明書のうちの１つ又は複数を所有するか否かにかかわらず、要求元のデバイス／エンドポイント／加入者のアカウントデータ又は記録情報にあり得る。一時的及び／又は持続的な使用のためのポインタ値の転送に関連付けられる条件が存在し得る。このような条件は、システムによって、及び／又は個々のセキュリティエコシステムのデバイス／エンドポイント／加入者によって、及び／又はセキュリティエコシステムのデバイス／エンドポイント／加入者のグループ又は他の集合体によって設定され得る。このような条件は、例えば、招待プロセス／招待主プロセスに関連付けられ得る。
【００９４】
招待主の所有に加えてポインタ値の転送を試みる理由の１つは、招待客がそのような同僚／仲間、デバイス／エンドポイント／グループに関する属性証明書へのポインタ値への直接又は間接的なアクセスを有するおかげで、招待の受け入れが成功すると、招待客が招待主の同僚及び／又は他の仲間に又は招待主（グループなど）に関連付けられるデバイス又はエンドポイントとの通信に成功できる可能性があるためである。招待客プロトコル（別名、招待受け入れプロセス）自体は、招待主の及び／又は招待主の同僚の又はエンドポイントの又はデバイスの属性証明書のうちの１つ又は複数の使用を含み得る。特に、招待客プロトコルの実行中に、招待客によって用いられるホストコンピュータ又はデバイスは、招待主の秘密鍵を用いてデジタル署名されたとされるデータにさらされ得る。招待客は、招待客の要件の達成のために要求される自身が所有するデータをプロセスに委ねる前に、このようなデータのソースを独立して検証することが重要であり得る。デジタル署名の検証に用いられることになる公開鍵を参照する属性証明書は、おそらく続行するかどうかの決定の一部として、招待客が考慮することができる招待主についての情報を含み得る。招待客プロトコルの実行（本出願で説明される安全な通信回線を確立するためのすべてのデバイス／エンドポイント認証方法を含む）が成功した場合、招待客が所有する１つ又は複数の属性証明書が発行されることになり得る。招待客プロトコルは、具体的には意図された招待客が招待客プロトコルの実行に実際に関与したかどうかをこのような属性証明書から判断するのに招待主のホストコンピュータ又はデバイス又は他のエンドポイントを用いることができるように設計されてよい。好ましい実施形態は、招待主処理と招待客処理との組み合わせの監査証跡を提供するように設計されてよい。
【００９５】
いくつかの実施形態において、招待プロトコル／招待主プロトコル（本出願で説明される安全な通信回線を確立するためのすべてのデバイス／エンドポイント認証方法を含む）の一部として、招待主は、その属性証明書のうちの１つ又は複数への（好ましくは曖昧でない）参照（例えば、一方向ハッシングであり得るハッシングにより達成される）が、招待客プロトコルの実行の成功からの結果である招待客の属性証明書内に含められることが許可されるか否かを選ぶことができる場合がある。招待客は、このような参照を、結果として生じる属性証明書に含めるかどうかを選ぶことができる場合がある。この属性証明書の「連鎖方式」は、エンドースメントのチェーンを供給するために用いることができる。このようなエンドースメントは、招待主・招待客処理を通じて可能にされる評判スコアリング方法のコンポーネントであり得る。特定の他の属性証明書への参照が属性証明書内に含まれる場合であっても、このような他の属性証明書の知識は、含んでいる属性証明書の知識がセキュリティエコシステムによってリリースされるたびにセキュリティエコシステムによって必ずしもリリースされない。含まれる属性証明書の所有者及び／又は含んでいる属性証明書の所有者は、このようなリリースの１つ又は複数の条件を潜在的に規定し得る。一方向ハッシングが属性証明書を参照する手段として用いられる場合、このようなリリースなしには、属性証明書を再構成することが難しい場合がある。
【００９６】
本願発明は、属性証明書を参照する属性証明書ポインタ値、及び公開鍵証明書を参照する属性証明書を可能にするので、システムがそのように構成される場合に適切なソフトウェア及び／又はハードウェアを用いてエンドエンティティ、エンドポイント、デバイスでこれらの関係性を独立して検証することができる。証明書発行者は直接信用されてよく、又は階層チェーンのより高位のエンティティが直接信用されるように発行者に関する公開鍵証明書が証明書のチェーン内で生じてよい。属性局（ＡＡ）は、属性証明書を発行する責任を割り当てられてよく、このような責任は、該エンティティの公開鍵証明書又はＡＡの公開鍵の直接信用される知識によって表され得る。属性証明書の正当性は、適正に生成された属性証明書の一部であるデジタル署名のテストを通じて少なくとも部分的に判断され得る。これらのデジタル署名は、（例えば、ＡＡの公開鍵証明書から又はＡＡに関連する公開鍵の直接的知識から判断される場合の）ＡＡの公開鍵を用いて検証されてよく、したがって結果的にエンドツーエンドの検証可能性をもたらす。
【００９７】
いくつかの実施形態において、本願発明のシステムは、必ずしもそのように露出されずにユーザの／デバイス／エンドポイント／加入者のクライアント、ブラウザ、ホストコンピュータ、及び／又は周辺装置で処理されるものとは対照的に、ユーザ・インターフェースに露出されるものについての選択肢が存在し得るように種々の方法で構成されてよい。同じデータに対して完全な又は部分的な検証可能性が繰返し生じ得る。これは、このようなデータが必ずしも保持されないためである。例えば、属性証明書ポインタ値又は属性証明書などの或るアイテムを指すのに「ニックネーム」が用いられてよく、このようなニックネームは、ローカルに保持又は記憶されてよく、又はおそらくセキュリティエコシステム以外のソースからアクセス可能であってよい。セキュリティエコシステムは、ニックネームを受信し、（おそらくアイテムへのニックネームの以前の割り当てのために）意図されたアイテムを返すことができる場合があり、受信者は返されたアイテムを独立して検証し得る。ニックネームは、ニックネーム提出者により検索され、おそらく検証されることになるアイテムに関してこの「プル」方式で用いられ得る。ニックネームはまた、又は代替的に、セキュリティエコシステムを通じて識別された（個人又はデバイス／エンドポイント又はエンティティ）デバイス／エンドポイント／加入者に利用可能にされ、おそらく検証されることになるアイテムに関して「プッシュ」様式で用いられ得る。いくつかの実施形態において、検証は、規則的又は定期的ではなくランダムに行われ得る。コスト及び／又は不便さを低減する手段として、（悪意をもって課される及び／又は自然発生の）システム異常を発見するのにランダムチェックを用いることが公知である。
【００９８】
本願発明のいくつかの実施形態に係るエンティティ間のプリエンプティブな招待プロセスは、既存の属性証明書に対応する交換されたポインタ値のマトリックスを確立することができる。プロセスは、セキュリティエコシステムを通じた属性証明書のエンティティ間のバルク交換のブリッジとして仲介型のセキュリティエコシステムを可能にする。これは、各個人に宛てられる招待の代わりとなり得るものであり、セキュリティエコシステムのデバイス／エンドポイント／エンティティメンバー／ユーザ／加入者は、セキュリティエコシステムによりそのデバイス／エンドポイント／エンティティメンバー（オプトアウトしないメンバーに関する）に利用可能にされるデバイス／エンドポイント／エンティティメンバーのリストからの名前又は他の識別子により指定される属性証明書ポインタ値及びおそらく関連する情報（及び／又は完全な属性証明書）を招待客エンティティのセキュリティエコシステムにより保持されるアカウントデータにプッシュすることにより、他の選択されたデバイス／エンドポイント／エンティティメンバーを「プリエンプティブに」招待する更新可能なホワイトリストを設定することができる。このプリエンプティブな招待プロセス／招待主プロセスのフォローアップは、招待主エンティティがこの目的のために招待客のデジタルアセットに提示された属性証明書に関連付けられた招待客の暗号化公開鍵を用いて暗号化されたデジタルアセット（好ましくはデジタル署名される）に応答するときに、受信したプッシュされた属性証明書に関連付けられた暗号化公開鍵を用いる招待客が、招待主の対応する属性証明書データ（潜在的にはマトリクスフォーマットの）と照合されることになる、アップロード側のエンティティの属性証明書ポインタ値及びおそらく関連する情報（及び／又は完全な属性証明書）（の適切なサブセット）のリストで構成されたデジタルアセット（好ましくはデジタル署名される）を提出することに限定され得る。
【００９９】
仲介型のセキュリティエコシステムは、対象鍵として暗号化公開鍵に関する公開鍵証明書を提供することを担当し得る。仲介型のセキュリティエコシステムは、（招待主及び／又は招待客がセキュリティエコシステムに属性証明書に関するポインタ値を示したか、又はこのようなポインタ値にマップする「ニックネーム」を示した場合）公開鍵又は公開鍵証明書を参照する属性証明書を提示することを担当し得る。この説明では、「暗号化公開鍵」は、結果的に生じる共有の秘密値が、暗号化のため及び復号のために用いられる対称鍵を導出するのに用いられる、鍵確立のために用いられる鍵を指す場合がある。このような鍵確立は、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎに基づいていてよい。いくつかの実施形態において、暗号化公開鍵はまた、暗号化のために用いられる鍵を指す場合があり、この場合、対応する復号秘密鍵が復号のために用いられる。
【０１００】
エンティティ／会社又は他のコンピュータユーザのデバイス／エンドポイントは、クライアント（潜在的にはホストコンピュータ上又はスマートカードなどの周辺装置上に又は複数のプラットフォームにわたってインストールされる）を用いて公開鍵／非対称暗号法を既に採用している場合がある。いくつかの実施形態において、セキュリティエコシステムにより仲介されるシステムは、このような既存の公開鍵のインポートを可能にし得る。このような公開鍵は、（例えば、このような公開鍵証明書を最初に発行したＣＡ又は該発行元ＣＡが従属するＣＡのセキュリティエコシステムのＣＡによる認証の下で）セキュリティエコシステムにより仲介されるシステム内で用いることができる証明書を既に保持している場合がある。代替的に（又は組み合わせて）、所与のユーザのすべての又はいくつかのこのような公開鍵は、セキュリティエコシステムのＣＡによって発行される証明書の対象公開鍵となり得る。以下の説明は、署名検証、署名生成鍵、及び暗号化・復号鍵に関係するが、当業者は認識するように、このような説明は、鍵確立のために用いられる鍵を含むことに容易に広げられ得る。すべてのケースにおいて、秘密鍵は、対応する公開鍵を含む証明書の所有者によって用いられ、一方、その公開鍵は、他の／証明書利用者によって用いられる。
【０１０１】
いくつかの実施形態において、セキュリティエコシステムにより仲介されるデジタルアセット／通信管理アプリケーションの代わりに、復号されることになるデータのルーティングを通じて、復号に対するエンティティの又は他の元の鍵利用ポリシーのバイパスを回避するために保護方策が講じられ得る。セキュリティエコシステム・サーバは、秘密鍵に定期的にアクセスすることができない場合がある（したがって、提出される推定上の暗号化されたデジタルアセット鍵又は他の暗号化されたデータの正当性を必ずしも判定することができない）ので、すべてのセキュリティエコシステム・クライアント／デバイス／エンドポイント（又は少なくとも、インポートされた公開鍵に関連付けられるセキュリティエコシステム・クライアント／デバイス／エンドポイントと相互作用するもの）は、任意のデータから（高確率で）区別できるようにデータパケットをフォーマットするように設計されてよい。次いで、インポートされた公開鍵に基づく復号秘密鍵の使用は、復号秘密鍵が適用されるときに期待されるパターン／書式設定を明かさない推定上のセキュリティエコシステムに基づくデータを拒否するように構成することができる。期待されるパターン／書式設定が存在する場合、セキュリティエコシステムにより仲介されるデジタルアセット／通信管理システム・クライアントへのデジタルアセット鍵又は他のデータのリリースが許可され得る。
【０１０２】
プレーンテキストのデジタルアセットに与えられるセキュリティに（セキュリティ一貫性に関して）潜在的に依存して、デジタルアセット鍵は、そのような伝送が保護される環境の外部である場合に、暗号文デジタルアセット復号に関するその使用のためにローカルでの伝送中に暗号化により保護されても又はされなくてもよい。デジタルアセット鍵が伝送中に保護される場合、暗号文デジタルアセット復号モジュールは、伝送する当該鍵の知識を適用することにより、伝送のために暗号化されたデジタルアセット鍵を最初に復号する必要があるだろう。サービスプロバイダにより仲介されないビジネスとセキュリティエコシステムのデバイス／エンドポイント／加入者としてとの両方でのホストコンピュータ／デバイス／エンドポイント（又は周辺装置）上での署名生成秘密鍵の使用に関して、セキュリティエコシステムの使用が、サービスプロバイダにより仲介されないビジネスへのセキュリティエコシステムのシステムにより供給される署名されたメッセージの偽属性成功を防ぐのに役立つ「セキュリティエコシステム・マーカーフィールド」に署名される引数を常に含む場合に、否認不可の態様は積極的に曖昧性を解消することができる。これは、特に、署名生成秘密鍵がエンティティのＣＡにより発行される証明書を所持する署名検証公開鍵に対応し、署名生成秘密鍵がデバイス／エンドポイントコンピュータ（又は周辺装置）上のエンティティにより提供される実行環境の範囲を決して離れず、セキュリティエコシステム・クライアントに代わって署名されることになるメッセージのハッシュがエンティティにより提供される実行環境に入力されるオペレーショナルパラダイムと一致している。セキュリティエコシステム・マーカーフィールドは、署名する前に、入力メッセージハッシュの最後に付加する、最初に付加する、又は排他的論理和をとることができる。セキュリティエコシステム・マーカーフィールドを適用する他の方法が実装されてよい。このような用途は、例えば、セキュリティエコシステム・マーカーフィールドが入力メッセージハッシュに付加された後でのハッシングなどの付加的なハッシュオペレーションを含み得る。メッセージハッシュ入力が、セキュリティエコシステム・クライアントソフトウェアから正当に供給されることを保証するために、エンティティにより提供される実行環境及びメッセージハッシュを生成するサービスプロバイダクライアントソフトウェアは、メッセージハッシュがエンティティにより提供される実行環境外で生成される場合に、認証鍵、例えば、メッセージ認証コード（ＭＡＣ）鍵を共有し得る。
【０１０３】
通常、メッセージ伝送にデジタル署名を含めると、メッセージ全体の待ち時間が増加するので、メッセージ認証にデジタル署名を使用するオーバーヘッドを或る程度削減する方法を以下に説明する。多くの軽量メッセージングプロトコル、例えば、ＴＣＰ／ＩＰプロトコルの上で用いられるＭＱＴＴ（Ｍｅｓｓａｇｅ  Ｑｕｅｕｅ  Ｔｅｌｅｍｅｔｒｙ  Ｔｒａｎｓｐｏｒｔ）では、帯域幅が制限される。これは特に、メッセージ伝送完了待ち時間が重要であるときのケースにあてはまる。メッセージパケットサイズは、望ましくは待ち時間を短く保つために小さくされる。制限された帯域幅の利用可能性は、各パケットに比較的大きいデジタル署名を付加するオーバーヘッドに起因して、伝送されるデータのデジタル署名などの技術の使用を困難にすることがある。
【０１０４】
図１０は、本発明のいくつかの実施形態に係る、帯域幅が制約された環境でデジタル署名を用いる例示的な方法を示す。この方法は、データの伝送に必要とされる帯域幅を減少させる。いくつかの実施形態において、各データペイロードに付加されたデジタル署名を伝送するのではなく、デジタル署名が「ｎ番目の」ペイロードおきに伝送されるように値「ｎ」が選択される。これは、種々の用途に応じてｎの値を調節することにより、セキュリティと帯域幅とのトレードオフを可能にする。このように、可能性のある侵入者／ハッカーが多くともｎ−１個のペイロードパケットの後に検出される。
【０１０５】
いくつかの実施形態において、暗号化された又は暗号化されていないシーケンスナンバー１００１を各パケット１００２に付加することができる。通常期待される連続する整数の代わりに、シーケンスナンバーは、例えば、ｎ個のペイロードパケットの伝送のための最初のデジタル署名１００３が作成されたときに生成されるハッシュ値の連続するワードであり得る。ハッシュ値は、デジタル署名の送信者と受信者にのみ知られるので、攻撃者により導入されるどのパケットも直ちに検出されることになる。
【０１０６】
いくつかの実施形態において、各シーケンスナンバー１００１並びにペイロードパケット１００２の内容は、前のパラグラフで説明したように作成されたシーケンスナンバーの数学関数として提示される。このプロセスは、パケットインジェクションに対してだけでなく、既存の、他の方法では有効なパケットのパケット変更に対しても保護することになる。
【０１０７】
図１１は、本発明のいくつかの実施形態に係る、そのような送信に必要とされる帯域幅を最小にしながらデジタル署名を送信する例示的な方法を示す。いくつかの実施形態において、これは、スライスされたデジタル署名を用いることによって達成される。例えば、デジタル署名１１０３はｎ個のスライス１１０１にカットされ、各スライス１１０１は、送信されることになる各個々のペイロード１１０２の一部として含まれる。次いで、送信の受信側エンティティが、各ペイロードからデジタル署名の各スライスを取り込む。ｎ個のペイロードパケットを受信すると、ｎ個のデジタル署名スライスが完全なデジタル署名へ再組み立てされ、次いで、これらが、公知のデジタル署名技術の適用を通じて検証される。ｎの値を調節することにより、実装者は、署名検証の待ち時間でデジタル署名のオーバーヘッド負荷をトレードオフすることができ、例えば、より大きいｎは結果的にオーバーヘッド負荷をより低くするが、メッセージ待ち時間全体はｎのサイズの増加と共に増加し得る。
【０１０８】
前述の本発明の例示した実施形態及び他の実施形態に、その広い発明的な範囲から逸脱することなく種々の修正がなされ得ることが当業者に認識されるであろう。したがって、本発明は、開示された特定の実施形態又は構成に限定されず、むしろ、付属の請求項及び図面により定義される場合の本発明の範囲内にあるあらゆる変化、適応、又は修正を包含することを意図していることが理解されるであろう。
【図１】
2020532215.tif 000003
【図２】
2020532215.tif 000004
【図３】
2020532215.tif 000005
【図３Ａ】
2020532215.tif 000006
【図４】
2020532215.tif 000007
【図５】
2020532215.tif 000008
【図６】
2020532215.tif 000009
【図７】
2020532215.tif 000010
【図８】
2020532215.tif 000011
【図９】
2020532215.tif 000012
【図１０】
2020532215.tif 000013
【図１１】
2020532215.tif 000014
【国際調査報告】
2020532215.tif 000015
2020532215.tif 000016