JP7367212B2 - リモートホストを使用したデバイスの認証 - Google Patents

Description

［クロスリファレンス］
本特許出願は、２０２０年１０月１３日に出願された”ＡＵＴＨＥＮＴＩＣＡＴＩＮＧ Ａ ＤＥＶＩＣＥ ＵＳＩＮＧ Ａ ＲＥＭＯＴＥ ＨＯＳＴ”と題されたＤｕｖａｌによる国際特許出願ＰＣＴ／ＵＳ２０２０／０５５３４７の国内段階出願であり、それは、２０１９年１１月１９日に出願された“ＡＵＴＨＥＮＴＩＣＡＴＩＮＧ Ａ ＤＥＶＩＣＥ ＵＳＩＮＧ Ａ ＲＥＭＯＴＥ ＨＯＳＴ”と題されたＤｕｖａｌによる米国特許出願第１６／６８８，８４８号の優先権を主張するものであり、それぞれは、本明細書の譲受人に割り当てられ、参照によりその全体が本明細書に明示的に組み込まれる。

以下は、一般に、少なくとも１つのメモリデバイスを含むシステムに関し、より具体的には、リモートホストを使用してデバイスを認証することに関する。

メモリデバイスは、コンピュータ、無線通信デバイス、カメラ、及びデジタルディスプレイ等の様々な電子デバイス内に情報を蓄積するために広く使用されている。情報は、メモリデバイスの異なる状態をプログラミングすることによって蓄積される。例えば、バイナリデバイスは、論理１又は論理０でしばしば示される２つの状態の内の１つを蓄積する。他のデバイスでは、２つよりも多い状態が蓄積され得る。蓄積された情報にアクセスするために、デバイスのコンポーネントは、メモリデバイス内の少なくとも１つの蓄積された状態を読み出し得、又はセンシングし得る。情報を蓄積するために、デバイスのコンポーネントは、メモリデバイス内に状態を書き込み得、プログラミングし得る。

磁気ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、同期型ダイナミックＲＡＭ（ＳＤＲＡＭ）、強誘電体ＲＡＭ（ＦｅＲＡＭ）、磁気ＲＡＭ（ＭＲＡＭ）、抵抗変化型ＲＡＭ（ＲＲＡＭ）、フラッシュメモリ、及び相変化メモリ（ＰＣＭ）等を含む様々なタイプのメモリデバイスが存在する。メモリデバイスは、揮発性又は不揮発性であり得る。幾つかのメモリデバイスは、サーバとの通信を実施する前に認証プロセスを実行し得る。幾つかのメモリデバイスは、ソフトウェアのアップデートを定期的に実施し得る。

本明細書に開示するような例に従ったリモートホストを使用してデバイスを認証することをサポートするシステムの一例を説明する。 本明細書に開示するような例に従ったリモートホストを使用してデバイスを認証することをサポートするプロセスフローの一例を説明する。 本明細書に開示するような例に従ったリモートホストを使用してデバイスを認証することをサポートするプロセスフローのブロック図を示す。 本明細書に開示するような例に従ったリモートホストを使用してデバイスを認証することをサポートするフィールドサーバのブロック図を示す。 本明細書に開示するような例に従ったリモートホストを使用してデバイスを認証することをサポートする１つ以上の方法を説明するフローチャートを示す。 本明細書に開示するような例に従ったリモートホストを使用してデバイスを認証することをサポートする１つ以上の方法を説明するフローチャートを示す。

幾つかのデバイスは、ユーザ（例えば、デバイス又はデバイスのコンポーネントの製造業者の顧客又はクライアント）によって配備及び動作され得る。一旦配備されると、サーバと通信する前にデバイスは認証され得る。認証は、セキュアなドメインにログインしようと試みる個々のプロセス又はエンティティを識別するプロセスである。認証は、認証されたデバイス（又はプロセス）のみがその保護されたリソースにアクセスすることを許可することによってネットワークを安全に保ち得、該リソースは、コンピューターシステム、ネットワーク、データベース、ウェブサイト、及びその他のネットワークベースのアプリケーション又はサービスを含み得る。サーバにおいてデータにアクセスする、又はサーバにデータを提供する前に、サーバへのアクセスをリクエストするデバイスが特定のデバイスであり、又は悪意のないデバイス（例えば、改竄されていないデバイス）であることを確認するために、デバイスはサーバとの認証手順を経り得る。

サーバは、デバイスと関連付けられたキー（例えば、デバイスエイリアスキー）と、サーバに蓄積され、さもなければサーバによりアクセス可能な証明書とに基づいてデバイスを認証し得る。例えば、キー管理サーバは、証明書と、デバイスと関連付けられたキーとの生成に利用され得る。デバイス固有のシークレット及びデバイスのソフトウェアのハッシュは、証明書又はキーを生成するために使用され得る。ソフトウェアのハッシュは、デバイスのコードがエンティティによって改竄されているか否かを検出する方法として、証明書及びキーを生成する場合に使用される。ソフトウェアのハッシュが使用されるため、デバイスのソフトウェアがアップデートされた場合、証明書間の不一致が原因で認証手順は失敗し得る。

本明細書に説明する技術に従えば、システムは、デバイス上でソフトウェアのアップデートを実施することの一部として、認証手順のために使用される証明書をアップデートするように動作可能である。システムはまた、デバイスとサーバとの両方によって認識された有効なキーに基づいて、デバイスがサービスに接続することを可能にし得る。例えば、サーバはソフトウェアのアップデートをデバイスへ送信し得る。サーバは、デバイスがソフトウェアのアップデートを経験していることを指し示すフラグを設定し得る。こうした場合、デバイスが接続リクエストを送信し、キー又は証明書（例えば、ソフトウェアのハッシュが異なるためにサーバにアップロードされた証明書と一致しない無効なキー又は無効な証明書）を提示する場合、サーバは、フラグが設定されているため、キーを有効なものとして一時的に受け入れ得る。サーバは、キーを含むデバイスからの追加の接続リクエストを受け入れ得るように、キーをリストに追加し得る。こうした場合、システムは、ソフトウェアのアップデートが発生した後の認証プロセスの複雑さを軽減し得、接続遅延を軽減し得、デバイスの製造業者若しくはユーザに対するコストを軽減し得、又はそれらの組み合わせであり得る。

開示の機構は、図１及び図２を参照して説明するようにシステム及びプロセスフロー図の文脈で説明される。開示のこれらの及びその他の機構は、図３～図６を参照して説明するように、リモートホストを使用してデバイスを認証することに関連する装置図及びフローチャートによって更に例証され、及びそれらを参照して説明される。

図１は、本明細書に開示するような例に従ったリモートホストを使用してデバイスを認証することをサポートするシステム１００の一例を説明する。システム１００は、デバイス１０５、キー管理サーバ１５０、登録ポータル１６５、デバイス製造ホスト１７５、及びフィールドサーバ１８５を含み得る。

デバイス１０５は、少なくともシークレット１１５を安全に蓄積するように構成されたセキュアコンポーネント１１０を含み得る。シークレット１１５は、ユニークデバイスシークレット（ＵＤＳ）の一例であり得る。幾つかの場合、セキュアコンポーネント１１０は、管理キー１２０を蓄積し得る。管理キー１２０は、サーバルートキー（ＳＲＫ）の一例であり得る。ＳＲＫは、管理キー１２０のコピーを所有するエンティティが、セキュアコンポーネント１１０のセキュリティ機構をオンにすることによって、セキュアコンポーネント１１０を管理することを可能にし得る。デバイス１０５は、デバイス２２０全体に対する１つ以上の認証手順を実施するように動作可能なメモリデバイスと関連付けられた１つ以上のコンポーネントを含み得る。デバイス１０５は、車両、パーソナルコンピュータ、携帯型電子デバイス、サーバ、又は任意のその他のタイプのコンピューティングデバイスのインフォテインメントシステムの一例であり得る。

セキュアコンポーネント１１０は、デバイス識別子構成エンジン（ＤＩＣＥ）標準、若しくはＲＩｏＴと関付けられた標準、又はそれらの組み合わせに従って生成されたデバイス識別子１２５を含み得る。幾つかの場合、デバイス識別子１２５は、デバイスシークレット１１５及びソフトウェア１３０に基づき得る。デバイス識別子１２５は、第１のキーペア１３５及び第２のキーペア１４０等の非対称キーペアを生成するために使用され得る。第１のキーペアは、エイリアスキーペアの一例であり得、第２のキーペア１４０は、デバイス識別キーペアの一例であり得る。幾つかの例では、デバイス１０５は、ソフトウェア１３０に関連してデバイス１０５の機能を提供するために、セキュアコンポーネント１１０に接続された１つ以上の追加のコンポーネント１４５を含み得る。

幾つかの例では、コマンドのセットは、シークレット１１５から及び暗号化ソフトウェアハッシュ１７０からデバイス識別子１２５を生成するために、デバイス１０５内で実行され得る。そうした場合、デバイス１０５は、デバイス製造ホスト１７５と通信し得る。デバイス製造ホスト１７５は、プロビジョニングツール１８０、ソフトウェア１３０、及びソフトウェアハッシュ１７０を含み得る。コマンドのセットの実行は、第１のキーペア１３５及び第２のキーペア１４０等の非対称キーペアを更に生成し得る。

システム１００は、デバイス製造ホスト１７５と通信するキー管理サーバ１５０を含み得る。キー管理サーバ１５０は、証明書ジェネレータ１５５を含み得る。証明書ジェネレータ１５５は、非対称キーペアを生成する際にデバイス１０５の機構をエミュレートするように構成され得る。例えば、証明書ジェネレータ１５５は、キー管理サーバ１５０内に蓄積されたシークレット１１５のコピーから、及び登録ポータル１６５から受信したソフトウェアハッシュ１７０からデバイス識別子１２５を生成するために、デバイス１０５内で実行されるコマンドの同じセットを使用するように構成され得る。こうした場合、登録ポータル１６５は、デバイス製造ホスト１７５及びキー管理サーバ１５０と通信し得る。

証明書ジェネレータ１５５内で実行されるコマンドのセットは、非対称キーペア（例えば、第１のキーペア１３５及び第２のキーペア１４０）を生成し得る。例えば、ソフトウェアハッシュ１７０及びシークレット１１５は、キーを創出するために組み合わされ得る。幾つかの例では、証明書ジェネレータ１５５は、キーに基づいて証明書（例えば、キー証明書１６０）を生成し得る。例えば、証明書ジェネレータ１５５は、証明書ジェネレータ１５５又はキー管理サーバ１５０の秘密キーを使用して、対応する非対称キーペア内の公開キーに対する証明書（例えば、キー証明書１６０）にデジタル署名し得る。キー証明書１６０の認証は、証明書ジェネレータ１５５の公開キーを介して検証され得る。

幾つかの場合、キー管理サーバ１５０は、デバイス１０５のキー証明書１６０をフィールドサーバ１８５に提供し得、それによって、証明書ジェネレータ１５５により認証された公開キーと、対応する秘密キーを使用してデバイス１０５により署名されたメッセージ（例えば、証明書）とに基づいてフィールドサーバ１８５がデバイス１０５を認証することを可能にする。そうした場合、フィールドサーバ１８５は、証明書ジェネレータ１５５により署名された証明書を有する公開キーの信頼性を検証し得る。

デバイス１０５の公開キーが一旦証明されると、デバイス１０５は、フィールドサーバ１８５に対してそれ自体を認証するために、対応する秘密キーを使用し得る。そうした場合、デバイス１０５は、フィールドサーバ１８５と直接通信し得る。例えば、デバイス１０５は、秘密キーを使用してメッセージをデジタル署名し得る。デバイス１０５の秘密キーと関連付けられた公開キーが証明書のデジタル署名を検証するために使用される場合、デバイス１０５は秘密キーを所有するとみなされ得る。他の例では、デバイス１０５は、公開キーにより署名された証明書で指定されたアイデンティティを有するとみなされ得る。そうした場合、システム１００は、セキュアコンポーネント１１０内のシークレット（例えば、管理キー１２０及びシークレット１１５）の実装とは異なる時間及び場所でデバイス１０５がソフトウェアを用いてロードされることを可能にする。システム１００はまた、デバイス１０５が有効な公開キーに基づいてサービスに接続することを可能にし得る。

フィールドサーバ１８５は、デバイス１０５のための複数の異なるサービスを含み得る。幾つかの場合、異なるサービスは、デバイス状態に依存する。例えば、デバイス１０５が登録ポータル１６５を通じて登録される場合、１つ以上のソフトウェアハッシュ１７０がアップロードされ得る。各ソフトウェアハッシュ１７０は、デバイス１０５の有効なバージョンを表し得る。幾つかの場合、デバイス１０５は、複数のステップを含み得るサプライチェーンを通過し得、各ステップは、ソフトウェア１３０の異なるバージョンを表し得る。フィールドサーバ１８５は、ソフトウェア１３０のバージョンを通知するために、デバイスがサプライチェーンの何れのステップにあるかをリクエストし得る。

デバイス１０５は、（例えば、サプライチェーン内の各ステップを指し示す）あらゆるソフトウェアハッシュ１７０を登録ポータル１６５にアップロードすることによって登録され得る。証明書ジェネレータ１５５は、各ソフトウェアハッシュ１７０に対する証明書を生成し得る。そうした場合、キー管理サーバ１５０は、ソフトウェアハッシュ１７０の各バージョンをフィールドサーバ１８５にアップロードし得る。デバイス１０５がフィールドサーバ１８５にキーを提示する場合、フィールドサーバ１８５は、デバイス１０５をデバイス状態（例えば、ソフトウェアハッシュ１７０）と関連付けられたサービスに接続し得る。

幾つかの例では、デバイス１０５は、登録ポータル１６５にアップロードされたソフトウェアハッシュ１７０のリストを修正し得る。例えば、デバイス１０５は、ソフトウェアハッシュ１７０のリストからソフトウェアハッシュ１７０を追加又は削除することをリクエストし得る。幾つかの例では、デバイス１０５は、登録ポータル１６５を介してキー管理サーバと通信するのではなく、ソフトウェアハッシュ１７０をキー管理サーバ１５０に直接追加又は削除するためのリクエストを通信し得る。証明書ジェネレータ１５５は、それらのソフトウェアハッシュが削除されたか、それとも追加されたか否かに基づいて証明書を再生成し得る。

幾つかの例では、フィールドサーバ１８５は、接続エージェント１９０及び１つ以上のキー証明書１６０を含み得る。フィールドサーバ１８５がデバイス１０５からキーを受信した場合、フィールドサーバ１８５は、フィールドサーバ１８５内のキー証明書１６０の各々を受信したキーと比較し得る。他の例では、フィールドサーバ１８５は、デバイス状態に基づく比較のためにキー証明書１６０を識別し得る。例えば、デバイス１０５は、デバイス状態の通知をフィールドサーバ１８５へ送信し得る。デバイス状態に基づいて、フィールドサーバ１８５は、デバイス状態に対応する証明書をチェックし得る。

幾つかの例では、デバイス１０５は、接続リクエストを接続エージェント１９０へ送信し得る。リクエストは、キー及びデバイス識別情報（例えば、デバイス識別（ＩＤ））を含み得る。接続エージェント１９０は、接続リクエスト（例えば、キー）をキー証明書１６０と照合し得る。提示されたキーが有効ではない（例えば、キー証明書１６０と一致しない）場合、接続エージェント１９０は、デバイス１０５がソフトウェアのアップデートを実施していること、デバイスがエラーを経験していること、又はそれら両方であることを判定し得る。幾つかの場合、エラーは、デバイス１０５が欠陥のある又は悪意のあるソフトウェアを含むことを識別することを指し示し得る。

接続エージェント１９０は、デバイス１０５がソフトウェアのアップデートを経験していると接続エージェント１９０が判定した場合に、ローカルリストに新たなキーを追加し得る。ソフトウェアのアップデートは、キー証明書１６０を無効にさせ得る。例えば、キー証明書１６０は、ソフトウェアハッシュ１７０（例えば、ソフトウェアコード）をハッシュすることに基づいて生成される。そうした場合、ソフトウェアのアップデートは、ソフトウェアハッシュ１７０へのアップデートを含み得、それによって、キー証明書１６０とアップデートされたソフトウェアハッシュ１７０との間の不一致を指し示す。例えば、デバイスのソフトウェア１３０への如何なるアップデートも、フィールドサーバ１８５により蓄積されたキー証明書１６０内に反映されないことがある。幾つかの例では、キー証明書１６０は、ソフトウェアのアップデート（例えば、アップデートされたソフトウェアハッシュ１７０）に基づいて再生成され得る。幾つかの場合、ソフトウェアハッシュ１７０は、ソフトウェアコードが（例えば、許可されていないユーザを介して）許可なく修正されたか否かをチェックし得る。

フィールドサーバ１８５は、ソフトウェアのアップデートが進行中であることを指し示すフラグを設定し得る。幾つかの例では、フィールドサーバ１８５は、ローカルリストへの新たなキーの追加及びフラグの設定に基づいて、無効なキーを一時的に許可し得る。他の例では、無効なキーが接続エージェント１９０に提示された場合、接続エージェント１９０は、デバイス１０５からキー証明書１６０をリクエストし得る。フィールドサーバ１８５がリクエストされた証明書を一旦受信すると、フィールドサーバ１８５は、無効なキーを検証（例えば、確認）し得る。

デバイス１０５は、フィールドサーバ１８５と関連付けられたサービスへのサブスクリプションをデバイス１０５が含むことに基づいて接続エージェント１９０にアクセスし得る。幾つかの例では、デバイス１０５は、フィールドサーバ１８５に有効なキーを提示し得る。幾つかの場合、接続エージェント１９０は、デバイス１０５を有効なキーに対応するサービスにルーティングし得る。

幾つかの例では、各キーは、別個のプロファイルを含み得る。例えば、接続エージェント１９０は、フィールドサーバ１８５に提示されたキーに基づいてデバイス１０５をプロファイルと一致させ得る。幾つかの場合、プロファイルは、デバイス１０５上に存在するソフトウェアイメージと一致させ得る。プロファイルは、シークレット１１５及びソフトウェアハッシュ１７０に加えてフィールドサーバ１８５と関連付けられ得る。幾つかの例では、プロファイルは、ソフトウェアハッシュ１７０内に埋め込まれ得、プロファイルは、サービスと関連付けられ得、又はそれらの両方であり得る。幾つかの場合、フィールドサーバ１８５は、ソフトウェアイメージと関連付けられたプロファイルを識別し得、デバイス１０５をプロファイルと関連付けられたサービスにルーティングし得る。

システム１００は、フィールドサーバ１８５にアクセスする際のデバイス１０５のセキュアな認証のための構成を備えたデバイス１０５上にソフトウェア１３０を搭載するためのプロセスを説明し得る。例えば、セキュアコンポーネント１１０は、セキュアコンポーネント１１０を使用するデバイス１０５内に後で配備又はインストールされ得るソフトウェア１３０に対する何れの知識又はアクセスもなくファクトリ内で構成され得る。セキュアコンポーネント１１０がファクトリである場合、第１のルートオブトラストのシークレット（例えば、管理キー１２０及びシークレット１１５）は、セキュアコンポーネント１１０に導入され得る。シークレットのコピーは、ファクトリとキー管理サーバ１５０との間のセキュアな接続を介して、（例えば、セキュアコンポーネント１１０の識別と共に）キー管理サーバ１５０に蓄積され得る。

幾つかの例では、デバイス製造業者は、セキュアコンポーネント１１０と追加のコンポーネント１４５とを統合するデバイス１０５の設計を開発する。デバイス１０５を動作させるためのソフトウェア１３０は、デバイス製造業者の施設（例えば、フィールドサーバ１８５）で利用可能になり得る。幾つかの場合、ソフトウェア１３０をセキュアコンポーネント１１０にインストールし、ソフトウェア１３０についての情報を生成するために、プロビジョニングツール１８０が使用され得る。ソフトウェア１３０についての情報は、デバイス１０５のデバイス識別子１２５を生成するために、デバイス１０５内で使用され得る。

ソフトウェア１３０についての情報は、ソフトウェア１３０のソフトウェアハッシュ１７０の一例であり得る。例えば、ソフトウェアハッシュ１７０は、ソフトウェア１３０のソースコードの暗号化関数であり得る。幾つかの場合、ソフトウェアハッシュ１７０は、デバイス製造業者と関連付けられた第２のルートオブトラストの情報を表し得る。他の例では、ソフトウェアハッシュ１７０は、デバイス製造業者の秘密キーを使用してデジタル署名され得る。

デバイス１０５におけるキーの生成のために使用されるソフトウェアハッシュ１７０は、セキュアコンポーネント１１０の登録中に、登録ポータル１６５を介してキー管理サーバ１５０に通信され得る。幾つかの場合、ソフトウェアハッシュ１７０は、デバイス１０５内のソフトウェア１３０のインストールプロセスの一部としてデバイス１０５に提供され得る。そうした例では、フィールドサーバ１８５上に蓄積されたキー証明書１６０は、元のソフトウェアのソフトウェアハッシュ１７０に基づき得る。デバイスのソフトウェア１３０への如何なるアップデートも、フィールドサーバ１８５により蓄積されたキー証明書１６０に反映されないことがある。ソフトウェアのアップデート後に証明書をアップデートするための技術は、本明細書に説明される。幾つかの例では、証明書ジェネレータ１５５は、デバイス１０５の動作とは無関係にデバイス１０５の公開キーを生成し、デバイス１０５の公開キーに対するキー証明書１６０に署名するためにソフトウェアハッシュ１７０を使用し得る。

登録ポータル１６５は、セキュアコンポーネント１１０を管理するために管理キー１２０を使用し得、セキュアコンポーネント１１０の登録後又はキー証明書１６０の生成後にセキュアコンポーネント１１０のセキュリティ機構をアクティブにし得る。セキュアコンポーネント１１０のセキュリティ機構がアクティブにされると、デバイス１０５内にインストールされたセキュアコンポーネント１１０は、デバイス１０５のデバイス識別子１２５及びデバイス識別子１２５の暗号化キー（例えば、第１のキーペア１３５及び第２のキーペア１４０）を生成する際に使用され得る。

図２は、本明細書に開示するような例に従ったリモートホストを使用してデバイスを認証することをサポートするプロセスフロー２００の一例を説明する。プロセスフロー２００は、管理サーバ２０５、キー管理（ＫＭ）サーバ２１０、フィールドサーバ２１５、及びデバイス２２０を含み得、これらは、図１を参照して本明細書に説明した対応するデバイスの例であり得る。プロセスフロー２００は、リモートホストを使用してデバイスを認証することを説明し得る。リモートホストは、管理サーバ２０５、ＫＭサーバ２１０、フィールドサーバ２１５、その他のコンポーネント、又はそれらの組み合わせを指し得る。

２２５において、管理サーバ２０５は、ソフトウェアのアップデートを識別し得る。初期化プロセスの一部として、２３０において、ＫＭサーバ２１０は、ルートキーを管理サーバ２０５へ送信し得る。２３５において、ＫＭサーバ２１０は、証明書を生成し得、該証明書をフィールドサーバ２１５にアップロードし得る。幾つかの場合、ＫＭサーバ２１０は、ＫＭサーバ２１０にアップロードされた各ソフトウェアハッシュに対して証明書を生成し得る。証明書は、エイリアスキー、公開キー、及びデバイスＩＤ秘密キーで署名された証明書を含み得る。幾つかの場合、フィールドサーバ２１５は、各証明書がエイリアスキー及び公開キーを含む複数の証明書を受信し得る。

２４０において、管理サーバ２０５は、ソフトウェアのアップデートを開始し得る。例えば、管理サーバ２０５は、ソフトウェアのアップデートをデバイス２２０へ送信し得る。デバイス２２０は、管理サーバ２０５からソフトウェアのアップデートを受信することに基づいてそのソフトウェアをアップデートし得る。そうした手順は、アップデートが成功したことの確認応答（ＡＣＫ）又は否定確認応答（ＮＡＣＫ）をデバイス２２０が送信することを含み得る。

２４５において、管理サーバ２０５は、ソフトウェアのアップデートがデバイス２２０へ送信されたことをフィールドサーバ２１５に通知し得る。そうした場合、フィールドサーバ２１５は、ソフトウェアのアップデートがデバイス２２０へ送信されたことの通知を受信し得る。通知は、デバイス２２０から受信したキーと関連付けられた証明書がソフトウェアのアップデートに基づいて変更されたことを識別するためのものであり得る。幾つかの例では、フィールドサーバ２１５は、デバイス２２０のソフトウェアを認証し得、それによって、ソフトウェアが安全であることを指し示す。

２５０において、デバイス２２０は、ソフトウェアのアップデートを実施し得、完了し得る。幾つかの例では、デバイス２２０は、デバイス２２０のソフトウェアをハッシュし得、ソフトウェアのハッシュ及びデバイス固有のシークレットに基づいてキーを生成し得る。ソフトウェアのアップデートは、プロセスフロー２００の何時でも発生し得る。２５５において、デバイス２２０は、完了メッセージを管理サーバ２０５へ送信し得る。完了メッセージは、デバイス２２０がソフトウェアのアップデートを実施したことを指し示し得る。

２６０において、フィールドサーバ２１５は、デバイス２２０と、フィールドサーバ２１５のメモリ内のソフトウェアのアップデートとの間の関連を指し示すフラグを設定し得る。例えば、フィールドサーバ２１５は、ソフトウェアのアップデートを受けているものとしてデバイス２２０にフラグを立てるために、データベース内に記録し得る。幾つかの場合、通知及びフラグを使用することは、アップデートされた証明書を生成するためにＫＭサーバ２１０を伴うことなく、フィールドサーバ２１５上に蓄積された証明書をシステムがアップデートすることを可能にし得る。こうした手順は、ソフトウェアのアップデートに遅延をもたらし得、証明書が正しいことを確認することに関連する他の問題を引き起こし得る。

２６５において、フィールドサーバ２１５は、デバイス２２０を認証するためのキーと関連付けられた証明書を含む接続リクエストをデバイス２２０から受信し得る。例えば、デバイス２２０は、確立メッセージ（例えば、接続リクエスト）を送信することによって、フィールドサーバ２１５にエイリアスキー（例えば、第１のキー）を提示し得る。幾つかの場合、接続リクエストはデバイスＩＤ情報を含み得る。そうした場合、デバイスＩＤ情報は、キーと、２３５においてアップロードされた証明書とを照合するようにフィールドサーバ２１５に命じ得る。

２７０において、フィールドサーバ２１５は、デバイス２２０から受信したキーの有効性を判定し得る。例えば、２７０において、フィールドサーバ２１５は、デバイスから受信したキーが無効であると判定し得る。幾つかの例では、フィールドサーバ２１５は、デバイス２２０とソフトウェアのアップデートとの間の関連を指し示すフラグに基づいて、キーを有効であるとして判定し（例えば、受け入れ）得る。例えば、フィールドサーバ２１５は、フラグに基づいてキーを有効であるものとして一時的に受け入れ得る。２７０において、フィールドサーバ２１５は、キーが有効であるとして判定することに基づいて、メモリ内のリスト内にキーを蓄積し得る。

２７０において、フィールドサーバ２１５は、接続と関連付けられた証明書が有効であるか否かを判定し得る。幾つかの例では、フィールドサーバ２１５は、（例えば、接続リクエスト内に含まれる）キーと関連付けられた証明書と、デバイスと関連付けられた証明書との間の不一致を識別し得る。例えば、フィールドサーバ２１５は、キーと関連付けられた証明書を、（例えば、２３５において）フィールドサーバにより蓄積された証明書と比較し得る。不一致が識別された場合、フィールドサーバ２１５は、証明書を送信したデバイスを識別し得、ソフトウェアのアップデートに関連するフラグが設定されているか否かを識別し得る。フラグが設定されている場合、フィールドサーバ２１５は、接続リクエストを認証し得、接続リクエストの一部としてデバイス２２０から受信した証明書を、フィールドサーバ２１５により蓄積された新たな証明書として保存し得る。幾つかの実例では、フィールドサーバ２１５は、デバイス２２０に対する証明書としてソフトウェアコードのアップデートされたハッシュ値と共に、受信した証明書を蓄積することに基づいてフラグをクリアし得る。幾つかの例では、フィールドサーバ２１５は、キーが証明書に一致することに基づいてデバイス２２０を認識及び認証し得る。幾つかの場合、デバイス２２０は、デバイス状態をフィールドサーバ２１５へ送信し得、それによって、キーと証明書とを比較する時間を短縮する。そうした場合、フィールドサーバ２１５は、デバイスを識別し得、デバイスの状態に基づいてフラグが設定されるか否かを識別し得る。他の例では、フィールドサーバ２１５は、フィールドサーバ２１５がデバイス２２０からキーを受信した場合に、フィールドサーバ２１５にアップロードされた各証明書をチェックする。

２７５において、フィールドサーバ２１５は、キーが有効であるか否かを指し示すＡＣＫメッセージ又はＮＡＣＫメッセージをデバイス２２０へ送信し得る。例えば、フィールドサーバ２１５は、キーが有効である場合にＡＣＫメッセージを送信し得、又はフィールドサーバ２１５は、キーが無効である場合にＮＡＣＫメッセージを送信し得る。幾つかの場合、フィールドサーバ２１５は、エイリアスキーがフィールドサーバ２１５により蓄積された証明書と一致しないことを識別し得る。そうした場合、フィールドサーバ２１５は、デバイス２２０から証明書（例えば、エイリアスキーと一致するエイリアス証明書）をリクエストするメッセージを送信し得る。

２８０において、フィールドサーバ２１５は、キーを有効であるとして判定すること（例えば、デバイス２２０から受信した証明書がキーを含むと判定するこ）に基づいて、デバイス２２０とサービスとの間の接続を確立し得る。例えば、２８０において、フィールドサーバ２１５は、デバイス２２０とソフトウェアのアップデートとの間の関連を指し示すフラグに基づいて、不一致に関係なく接続リクエストを検証し得る。こうした場合、キーが有効であると判定することは、接続リクエストを検証することに基づく。他の例では、フィールドサーバ２１５は、キーと関連付けられた証明書を証明書と比較することに基づいて、アプリケーションプラットフォームへのアクセスのためにデバイス２２０を認証し得る。例えば、フィールドサーバ２１５は、サービスへのサブスクリプションを検証し得る。デバイス２２０を認証することは、デバイス２２０がアプリケーションプラットフォームと通信し、サービスにサブスクライブすることを可能にし得る。

代替的に又は追加的に、フラグを使用して、管理サーバ２０５は、ソフトウェアのアップデートが完了したことの完了メッセージをデバイス２２０から受信することに基づいて、デバイス２２０と関連付けられたアップデートされた証明書を送信し得る。そうした場合、フィールドサーバ２１５は、デバイス２２０のソフトウェアがアップデートされた後、デバイス２２０と関連付けられたアップデートされた証明書を受信し得る。フィールドサーバ２１５は、フィールドサーバ２１５により蓄積されたデバイス２２０と関連付けられた証明書をアップデートし得る。代替的に又は追加的に、フラグを使用して、管理サーバ２０５は、ソフトウェアのアップデートをＫＭサーバ２１０へ送信し得る。ＫＭサーバ２１０は、ソフトウェアのアップデートを受信し得、ソフトウェアのアップデート（例えば、ソフトウェアのアップデートされたハッシュ）に基づいてアップデートされた証明書を生成し得る。そうした場合、ＫＭサーバ２１０は、アップデートされた証明書をフィールドサーバ２１５へ送信し得る。フィールドサーバ２１５は、アップデートされた証明書を受信することに基づいて、フィールドサーバ２１５により蓄積されたデバイス２２０と関連付けられた証明書をアップデートし得る。

２８５において、デバイス２２０は、接続リクエストを送信し得る。こうした場合、フィールドサーバ２１５は、キーが有効であるとして判定することに基づいて、デバイス２２０からの接続リクエストを処理し得る。例えば、デバイス２２０は、接続が既に確立されている（例えば、キーが有効であると以前に認識されている）ため、フィールドサーバ２１５との接続の確立をバイパスし得る。

他の例では、デバイス２２０を認証するための無効なキーと関連付けられた証明書を含む接続リクエストをデバイス２２０が送信した場合に、デバイス２２０は、接続障害を経験し得る。２９０において、フィールドサーバ２１５は、接続リクエストを受信し得、自己署名される証明書に対する証明書リクエストを送信し得る。こうした場合、フィールドサーバ２１５は、接続リクエスト内の証明書が無効なキーを含むことに基づいて認証を検証するために、デバイス２２０が秘密キー（例えば、有効なキー）を用いて証明書に署名することをリクエストし得る。

２９２において、デバイス２２０は、署名（例えば、署名された証明書）をフィールドサーバ２１５へ送信し得る。そうした場合、フィールドサーバ２１５は、証明書が秘密キーを用いて署名されていることに基づいて、デバイス２２０が秘密キーを含むと判定し得る。２９５において、フィールドサーバ２１５は、署名された証明書に起因してデバイスを識別し得る。例えば、フィールドサーバ２１５は、何れのデバイス２２０がフィールドサーバ２１５と接続しようと試み得るかを識別し得る。

２９２において、フィールドサーバ２１５は、デバイス２２０がエラーを含むことを識別し得る。そうした場合、デバイス２２０は、エラーを指し示すステータスのアップデートをフィールドサーバ２１５がデバイス２２０から受信することよりも暗号的に強い（例えば、確実性が増す）ことがあり得るアラームをトリガーし得る。フィールドサーバ２１５は、デバイス２２０がアラームと関連付けられていることを検証し得、それによって、デバイス２２０の識別、デバイス２２０の位置、又はその両方を判定するためのフォレンジック分析に対する検証を使用する。

図３は、本明細書に開示するような例に従ったリモートホストを使用してデバイスを認証することをサポートするプロセスフロー３００の一例を説明する。プロセスフロー３００は、管理サーバ３０５、ＫＭサーバ３１０、フィールドサーバ３１５、及びデバイス３１０を含み得、これらは、図１及び図２を参照して本明細書に説明した対応するデバイスの例であり得る。プロセスフロー３００は、追記書き込みモードで動作することを説明し得る。

３２５において、ＫＭサーバ３１０は、ルートキーを管理サーバ２０５へ送信し得る。幾つかの場合、ＫＭサーバ３１０は、ＫＭサーバ３１０にアップロードされた各ソフトウェアハッシュに対して証明書を生成し得る。例えば、登録ポータルは、ソフトウェアの第１のバージョンに対するソフトウェアハッシュと、ソフトウェアの第２のバージョンに対するソフトウェアハッシュとをＫＭサーバ３１０にアップロードし得る。そうした場合、ＫＭサーバ３１０は、あらゆるソフトウェアハッシュ対して、及びあらゆるデバイス３２０に対して証明書を生成し得る。３３０において、ＫＭサーバ３１０は、第１の証明書を生成し得、第１の証明書をフィールドサーバ３１５にアップロードし得る。３３５において、ＫＭサーバ３１０は、第２の証明書を生成し得、第２の証明書をフィールドサーバ３１５にアップロードし得る。

３４０において、管理サーバ３０５は、デバイス３２０の一部分を追記書き込みモードで動作するように構成し得る。追記書き込みモードは、デバイス３２０内のメモリセルの１つ以上の部分に適用され得、非特権ユーザがデバイス３２０の１つ以上の部分内のコンテンツを消去することを防止し得る。

３４５において、デバイス３２０は、ソフトウェアの第１のバージョンをインストールし得、それによって、デバイス３２０の一部分を追記書き込みモードで動作するように構成する。３５０において、フィールドサーバ３１５は、デバイス３２０を認証するための第１のキーと関連付けられた証明書を含む接続リクエストをデバイス３２０から受信し得る。３５５において、フィールドサーバ３１５は、第１のキーを第１の証明書と照合し得る。例えば、フィールドサーバ３１５は、ＫＭサーバ３１０から受信した第１の証明書に基づいて、デバイス３２０から受信した第１のキーの有効性を判定し得る。３６０において、フィールドサーバ３１５は、第１のキーが有効であることを指し示すＡＣＫメッセージをデバイス３２０へ送信し得る。

幾つかの場合、管理サーバ３０５は、デバイス３２０の証明書を無効にするために、追記書き込みモードを使用し得る。例えば、管理サーバ３０５は、ソフトウェアに追加情報を追記し得る。こうしたアクションは、デバイス３２０により生成され接続リクエストの一部として通信される証明書が、フィールドサーバ３１５により蓄積された証明書と一致させないことがある。フィールドサーバ３１５内にフラグが設定されていない場合、フィールドサーバ３１５は、証明書間の不一致に基づいてデバイス３２０を認証することを失敗し得る。幾つかの場合、管理サーバ３０５は、追加情報を追記することに基づいて、デバイス３２０から受信したキーをアップデートし得る。そうした場合、フィールドサーバ３１５上のサービスへのアクセスは、キーをアップデートすることに基づいて削除され（例えば、ブロックされ）得る。

３６５において、フィールドサーバ３１５は、第１のキーが第１の証明書と一致することに基づいて、デバイス３２０とフィールドサーバ３１５との間に接続（例えば、少なくとも第１の接続）を確立し得る。例えば、デバイス３２０のユーザは、１つ以上のサービス（例えば、音楽リスニングサービス、マッピングサービス、又は旅行サポートサービス等）にサブスクライブし得る。フィールドサーバ３１５は、１つ以上のサービスへの接続を確立し得る。

他の例では、管理サーバ３０５は、サブスクリプションサービスが期限切れになることに基づいて、デバイス３２０の追記書き込みモード部分内に情報を書き込み得る。例えば、これらのサービスの内の幾つかは、ユーザが料金を支払うことに基づいて一時的に提供され得る。（料金の未払いを含む何らかの理由で）サブスクリプションが期限切れになった場合、ソフトウェアは、デバイス３２０内のセキュアなフラッシュに書き込み得る。そうした場合、デバイス３２０上のイメージは変更され得、それによって、証明書を生成するためのハッシュを生成するために使用された基礎となるコードを変更する。

この方法でサービスへのサブスクリプションを無効にすることは、デバイス３２０がサービスに接続することを防止し得る。幾つかの場合、ソフトウェアのイメージは、外部コンピュータによってデバイス３２０上で修正され得る。例えば、デバイス３２０への直接アクセスを備えたプログラミングツールは、ソフトウェアイメージを修正し得、ソフトウェアのアップデートを送信するリモートサーバは、イメージを修正し得、又はそれら両方であり得る。

３７０において、デバイス３２０は、追記書き込みモードを修正し得る。例えば、デバイス３２０は、ソフトウェアの第１のバージョンをソフトウェアの第２のバージョンに修正（例えば、アップデート）し得る。３７５において、フィールドサーバ３１５は、デバイス３２０を認証するための第２のキーと関連付けられた証明書を含む接続リクエストをデバイス３２０から受信し得る。３８０において、フィールドサーバ３１５は、第２のキーを第２の証明書と照合し得る。例えば、フィールドサーバ３１５は、ＫＭサーバ３１０から受信した第２の証明書に基づいて、デバイス３２０から受信した第２のキーの有効性を判定し得る。３８５において、フィールドサーバ３１５は、第２のキーが有効であることを指し示すＡＣＫメッセージをデバイス３１０へ送信し得る。

３９０において、フィールドサーバ３１５は、第２のキーが第２の証明書と一致することに基づいて、デバイス３２０とフィールドサーバ３１５との間に接続（例えば、少なくとも第２の接続）を確立し得る。例えば、フィールドサーバ３１５は、１つ以上のサービス（例えば、音楽リスニングサービス、マッピングサービス、又は旅行サポートサービス等）への接続を確立し得る。

デバイス３２０とフィールドサーバ３１５との間の接続を確立又は再確立するために、ソフトウェアハッシュはアップデートされ得、サービスにアクセスするために新たな証明書がリクエストされ得る。サービスは、サービスにアクセスするための支払い計画に対応する期間中にデバイス３２０と相互作用し得る。該期間は、サービスの購入において開始し得、サービスの有効期限まで延長し得る。有効期限後、フィールドサーバ３１５は、サービスへのアクセスを防止するためにコンテンツを変更し（例えば、ソフトウェアのイメージを修正し）得る。こうした場合、コンテンツを変更することが、サービスと関連付けられた各プロファイルを無効にし得るように、キーは、サービスと関連付けられたプロファイルに対応する。

図４は、本明細書に開示するような例に従ったリモートホストを使用してデバイスを認証することをサポートするフィールドサーバ４０５のブロック図４００を示す。フィールドサーバ４０５は、図１～図３を参照して説明したようなフィールドサーバの態様の一例であり得る。フィールドサーバ４０５は、接続コンポーネント４１０、ソフトウェアアップデートコンポーネント４１５、フラグマネージャ４２０、キー無効性マネージャ４２５、キー有効性マネージャ４３０、リクエストレシーバ４３５、及び証明書コンポーネント４４０を含み得る。これらのモジュールの各々は、（例えば、１つ以上のバスを介して）相互に直接的又は間接的に通信し得る。

接続コンポーネント４１０は、第１のキーを有効であるとして判定することに基づいて、デバイスとサービスとの間の接続を確立し得る。幾つかの例では、接続コンポーネント４１０は、フラグに基づいて不一致に関係なく接続リクエストを検証し得、第１のキーが有効であると判定することは、接続リクエストを検証することに基づく。幾つかの例では、接続コンポーネント４１０は、第１のキーと関連付けられた証明書と証明書とを比較することに基づいて、アプリケーションプラットフォームへのアクセスのためにデバイスを認証し得る。

幾つかの例では、接続コンポーネント４１０は、デバイスを認証することに基づいてサービスへのサブスクリプションを検証し得る。幾つかの例では、接続コンポーネント４１０は、接続リクエストを受信することに基づいて第１のキーが有効であるか否かを指し示すＡＣＫメッセージ又はＮＡＣＫメッセージをデバイスへ送信し得る。幾つかの場合、認証することは、デバイスがアプリケーションプラットフォームと通信し、サービスにサブスクライブすることを可能にする。

ソフトウェアアップデートコンポーネント４１５は、ソフトウェアのアップデートがデバイスへ送信されたことの通知をフィールドサーバによって受信し得、フィールドサーバは、デバイスのソフトウェアが安全であることを認証するためのものである。

フラグマネージャ４２０は、通知を受信することに基づいて、デバイスとメモリ内のソフトウェアのアップデートとの間の関連を指し示すフラグをフィールドサーバによって設定し得る。

キー無効性マネージャ４２５は、接続リクエストを受信することに基づいて、デバイスから受信した第１のキーが無効であると判定し得る。幾つかの例では、キー無効性マネージャ４２５は、接続リクエストを受信することに基づいて、第１のキーと関連付けられた証明書とデバイスと関連付けられた証明書との間の不一致を識別し得る。幾つかの例では、キー無効性マネージャ４２５は、第１のキーと関連付けられた証明書を、フィールドサーバにより蓄積された証明書と比較し得る。

キー有効性マネージャ４３０は、関連を指し示すフラグに基づいて、第１のキーを有効であるとして判定し得る。幾つかの例では、キー有効性マネージャ４３０は、フラグに基づいて第１のキーを有効であるとして判定することに基づいて、メモリ内のリスト内に第１のキーを蓄積し得る。幾つかの場合、デバイスから受信した第１のキーと関連付けられた証明書は、デバイスのソフトウェアのハッシュに基づく。

リクエストレシーバ４３５は、デバイスを認証するための第１のキーと関連付けられた証明書を含む接続リクエストをデバイスから受信し得る。幾つかの例では、リクエストレシーバ４３５は、第１のキーが有効であるとして判定することに基づいて、デバイスからの追加の接続リクエストを処理し得る。

証明書コンポーネント４４０は、デバイスのソフトウェアがアップデートされた後、デバイスと関連付けられたアップデートされた証明書を受信し得る。幾つかの例では、証明書コンポーネント４４０は、アップデートされた証明書を受信することに基づいて、フィールドサーバにより蓄積されたデバイスと関連付けられた証明書をアップデートし得る。

図５は、本明細書に開示するような例に従ったリモートホストを使用してデバイスを認証することをサポートする１つ以上の方法５００を説明するフローチャートを示す。方法５００の動作は、本明細書で説明するように、フィールドサーバ又はそのコンポーネントによって実装され得る。例えば、方法５００の動作は、図３を参照して説明したようなフィールドサーバによって実施され得る。幾つかの例では、フィールドサーバは、説明する機能を実施するためにフィールドサーバの機能的素子を制御するための命令のセットを実行し得る。追加的又は代替的に、フィールドサーバは、特別な目的のハードウェアを使用して、説明する機能の態様を実施し得る。

５０５において、フィールドサーバは、ソフトウェアのアップデートがデバイスへ送信されたことの通知を受信することであって、フィールドサーバは、デバイスのソフトウェアが安全であることを認証するためのものであり得る。５０５の動作は、本明細書に説明する方法に従って実施され得る。幾つかの例では、５０５の動作の態様は、図３を参照して説明したようなソフトウェアアップデートコンポーネントによって実施され得る。

５１０において、フィールドサーバは、通知を受信することに基づいて、デバイスとメモリ内のソフトウェアのアップデートとの間の関連を指し示すフラグを設定し得る。５１０の動作は、本明細書に説明する方法に従って実施され得る。幾つかの例では、５１０の動作の態様は、図３を参照して説明したようなフラグマネージャによって実施され得る。

５１５において、フィールドサーバは、デバイスを認証するための第１のキーと関連付けられた証明書を含む接続リクエストをデバイスから受信し得る。５１５の動作は、本明細書に説明する方法に従って実施され得る。幾つかの例では、５１５の動作の態様は、図３を参照して説明したようなリクエストレシーバによって実施され得る。

５２０において、フィールドサーバは、接続リクエストを受信することに基づいて、デバイスから受信した第１のキーが無効であると判定し得る。５２０の動作は、本明細書に説明する方法に従って実施され得る。幾つかの例では、５２０の動作の態様は、図３を参照して説明したようなキー無効性マネージャによって実施され得る。

５２５において、フィールドサーバは、関連を指し示すフラグに基づいて、第１のキーを有効であると判定し得る。５２５の動作は、本明細書に説明する方法に従って実施され得る。幾つかの例では、５２５の動作の態様は、図３を参照して説明したようなキー有効性マネージャによって実施され得る。

５３０において、フィールドサーバは、第１のキーを有効であると判定することに基づいて、デバイスとサービスとの間の接続を確立し得る。５３０の動作は、本明細書に説明する方法に従って実施され得る。幾つかの例では、５３０の動作の態様は、図３を参照して説明したような接続コンポーネントによって実施され得る。

幾つかの例では、本明細書に説明するような装置は、方法５００等の１つ以上の方法を実施し得る。装置は、ソフトウェアのアップデートがデバイスへ送信されたことの通知をフィールドサーバよって受信することであって、フィールドサーバは、デバイスのソフトウェアが安全であることを認証するためのものであることと、通知を受信することに基づいて、デバイスとメモリ内のソフトウェアのアップデートとの間の関連を指し示すフラグをフィールドサーバによって設定することと、デバイスを認証するための第１のキーと関連付けられた証明書を含む接続リクエストをデバイスから受信することと、接続リクエストを受信することに基づいて、デバイスから受信した第１のキーが無効であると判定することと、関連を指し示すフラグに基づいて、第１のキーを有効であると判定することと、第１のキーを有効であると判定することに基づいて、デバイスとサービスとの間の接続を確立することのための機構、手段、又は命令（例えば、プロセッサにより実行可能な命令を蓄積する非一時的コンピュータ可読媒体）を含み得る。

本明細書に説明する方法５００及び装置の幾つかの例は、フラグに基づいて第１のキーを有効であると判定することに基づいて、メモリ内のリスト内に第１のキーを蓄積するための動作、機構、手段、又は命令を更に含み得る。本明細書に説明する方法５００及び装置の幾つかの例は、デバイスのソフトウェアがアップデートされ得る後にデバイスと関連付けられたアップデートされた証明書を受信することと、アップデートされた証明書を受信することに基づいてフィールドサーバにより蓄積されたデバイスと関連付けられた証明書をアップデートすることのための動作、機構、手段、又は命令を更に含み得る。

本明細書に説明する方法５００及び装置の幾つかの例は、第１のキーを有効であると判定することに基づいて、デバイスからの追加の接続リクエストを処理することのための動作、機構、手段、又は命令を更に含み得る。本明細書に説明する方法５００及び装置の幾つかの例は、接続リクエストを受信することに基づいて、第１のキーと関連付けられた証明書とデバイスと関連付けられた証明書との間の不一致を識別することと、フラグに基づいて不一致に関わらず接続リクエストを検証することであって、第１のキーを判定することは、接続リクエストを検証することに基づき得ることのための動作、機構、手段、又は命令を更に含み得る。

本明細書に説明する方法５００及び装置の幾つかの例は、第１のキーと関連付けられた証明書をフィールドサーバにより蓄積された証明書と比較することと、第１のキーと関連付けられた証明書を証明書と比較することに基づいて、アプリケーションプラットフォームへのアクセスのためにデバイスを認証することのための動作、機構、手段、又は命令を更に含み得る。

本明細書に説明する方法５００及び装置の幾つかの例は、デバイスを認証することに基づいてサービスへのサブスクリプションを検証するための動作、機能、手段、又は命令を更に含み得る。本明細書に説明する方法５００及び装置の幾つかの例では、認証することは、デバイスがアプリケーションプラットフォームと通信し、サービスにサブスクライブすることを可能にし得る。

本明細書に説明する方法５００及び装置の幾つかの例では、デバイスから受信した第１のキーと関連付けられた証明書は、デバイスのソフトウェアのハッシュに基づき得る。本明細書に説明する方法５００及び装置の幾つかの例は、接続リクエストを受信することに基づいて第１のキーが有効であるか否かを指し示すＡＣＫメッセージ又はＮＡＣＫメッセージをデバイスへ送信することのための動作、機構、手段、又は命令を更に含み得る。

図６は、本明細書に開示するような例に従ったリモートホストを使用してデバイスを認証することをサポートする１つ以上の方法６００を説明するフローチャートを示す。方法６００の動作は、本明細書に説明するように、（第１のサーバと称され得る）管理サーバ又はそのコンポーネントによって実装され得る。例えば、方法６００の動作は、図２～図３を参照して説明したような管理サーバによって実施され得る。幾つかの例では、管理サーバは、説明する機能を実行するために管理サーバの機能的素子を制御するための命令のセットを実行し得る。追加的又は代替的に、管理サーバは、特別な目的のハードウェアを使用して、説明する機能の態様を実施し得る。

６０５において、管理サーバは、デバイスに対するソフトウェアのアップデートを識別し得る。６０５の動作は、本明細書に説明する方法に従って実施され得る。幾つかの例では、６０５の動作の態様は、図４を参照して説明したようなソフトウェアアップデート識別子によって実施され得る。

６１０において、管理サーバは、ソフトウェアのアップデートを識別することに基づいてソフトウェアのアップデートがデバイスへ送信されたことの通知を、デバイスのソフトウェアが安全であることを認証するための第２のサーバへ送信し得る。６１０の動作は、本明細書に説明する方法に従って実施され得る。幾つかの例では、６１０の動作の態様は、図４を参照して説明したような通知トランシーバによって実施され得る。

６１５において、管理サーバは、デバイスに対するソフトウェアのアップデートを識別することに基づいて、ソフトウェアのアップデートをデバイスへ送信し得る。６１５の動作は、本明細書に説明する方法に従って実施され得る。幾つかの例では、６１５の動作の態様は、図４を参照して説明したようなソフトウェアアップデートトランシーバによって実施され得る。

幾つかの例では、本明細書に説明するような装置は、方法６００等の１つ以上の方法を実施し得る。装置は、デバイスに対するソフトウェアのアップデートを第１のサーバによって識別することと、ソフトウェアのアップデートを識別することに基づいてソフトウェアのアップデートがデバイスへ送信されることの通知を、デバイスのソフトウェアが安全であることを認証するための第２のサーバへ送信することと、デバイスに対するソフトウェアのアップデートを識別することに基づいて、ソフトウェアのアップデートをデバイスへ送信することのための機構、手段、又は命令（例えば、プロセッサにより実行可能な命令を蓄積する非一時的コンピュータ可読媒体）を含み得る。

本明細書に説明する方法６００及び装置の幾つかの例は、デバイスがソフトウェアのアップデートを実施したことを指し示す完了メッセージをデバイスから受信することと、完了メッセージを受信することに基づいてデバイスと関連付けられたアップデートされた証明書を送信することのための動作、機構、手段、又は命令を更に含み得る。本明細書に説明する方法６００及び装置の幾つかの例では、通知は、デバイスから受信したキーと関連付けられた証明書がソフトウェアのアップデートに基づいて変更され得ることを識別するためのものであり得る。

本明細書に説明する方法６００及び装置の幾つかの例は、ソフトウェアのアップデートを送信することに基づいて、デバイスの一部分を追記書き込みモードで動作するように構成することのための動作、機構、手段、又は命令を更に含み得る。本明細書に説明する方法６００及び装置の幾つかの例は、デバイスの一部分を追記書き込みモードで動作するように構成することに基づいてソフトウェアに追加情報を追記することと、追加情報を追記することに基づいてソフトウェアのアップデート前に利用可能なソフトウェアのバージョンへのアクセスを防止することと、追加情報を追記することに基づいてデバイスから受信したキーをアップデートすることのための動作、機構、手段、又は命令を更に含み得る。

本明細書に説明する方法は可能な実装であること、動作及びステップは再配され得、さもなければ修正され得ること、及びその他の実装が可能であることに留意すべきである。更に、方法の内の２つ以上からの部分は組み合わされ得る。

本明細書に説明する情報及び信号は、様々な異なる技法及び技術の内の何れかを使用して表され得る。例えば、上の説明全体通じて言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、及びチップは、電圧、電流、電磁波、磁界若しくは磁性粒子、光場若しくは光粒子、又はそれらの任意の組み合わせにより表され得る。幾つかの図面は、（複数の）信号を単一の信号として説明し得るが、バスが様々なビット幅を有し得る場合に、信号が信号のバスを表し得ることは、当業者により理解されるであろう。

用語“電子通信する”、“導電的に接触する”、“接続される”、及び“結合される”は、コンポーネント間の信号の流れをサポートするコンポーネント間の関係を指し得る。コンポーネント間の信号の流れを何時でもサポートし得る何らかの導電経路がコンポーネント間にある場合、コンポーネントは、相互に電子通信する（又は導電的に接触する、又は接続される、又は結合される）とみなされる。任意の所与の時間において、相互に電子通信する（又は導電的に接触する、又は接続される、又は結合される）コンポーネント間の導電経路は、接続されるコンポーネントを含むデバイスの動作に基づいて開回路又は閉回路であり得る。接続されるコンポーネント間の導電経路は、コンポーネント間の直接の導電経路であり得、又は接続されるコンポーネント間の導電経路は、スイッチ、トランジスタ、若しくはその他のコンポーネント等の介在コンポーネントを含み得る間接的な導電経路であり得る。幾つかの場合、接続されるコンポーネント間の信号の流れは、例えば、スイッチ又はトランジスタ等の１つ以上の介在コンポーネントを使用して一時的に中断され得る。

メモリアレイを含む本明細書で論じるデバイスは、シリコン、ゲルマニウム、シリコン－ゲルマニウム合金、ヒ化ガリウム、窒化ガリウム等の半導体基板上に形成され得る。幾つかの例では、該基板は半導体ウエハである。その他の場合、該基板は、シリコンオンガラス（ＳＯＧ）若しくはシリコンオンサファイア（ＳＯＰ）等のシリコンオンインシュレータ（ＳＯＩ）基板、又は別の基板上の半導体材料のエピタキシャル層であり得る。基板又は基板のサブ領域の導電性は、リン、ホウ素、又はヒ素を含むがそれらに限定されない様々な化学種を使用したドーピングを通じて制御され得る。ドーピングは、イオン注入により、又は任意のその他のドーピング手段により、基板の初期の形成又は成長の間に実施され得る。

添付の図面に関連して本明細書に記載される説明は、例示的構成を説明し、実装され得る又は請求項の範囲内にある全ての例を表さない。本明細書で使用する用語“例示的”は、“好適”又は“その他の例よりも有利”ではなく“一例、実例、又は説明として役立つこと”を意味する。詳細な説明は、説明する技術の理解を提供するための具体的詳細を含む。これらの技術は、しかしながら、これらの具体的詳細なしに実践され得る。幾つかの実例では、説明する例の概念を不明確にすることを避けるために、周知の構造体及びデバイスはブロック図の形式で示されている。

添付の図では、同様のコンポーネント又は機構は、同じ参照ラベルを有し得る。更に、同じタイプの様々なコンポーネントは、参照ラベルに続いてダッシュと、同様のコンポーネントの間で区別する第２のラベルとを付すことにより区別され得る。明細書において第１の参照ラベルのみが使用される場合、説明は、第２の参照ラベルに関係なく、同じ第１の参照ラベルを有する同様のコンポーネントの内の何れか１つに適用可能である。

本明細書に説明する情報及び信号は、様々な異なる技法及び技術の内の何れかを使用して表され得る。例えば、上述の説明全体通じて言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、及びチップは、電圧、電流、電磁波、磁界若しくは磁性粒子、光場若しくは光粒子、又はそれらの任意の組み合わせにより表され得る。

本明細書の開示と関連して説明する様々な説明ブロック及びコンポーネントは、本明細書に説明する機能を実施するように設計された汎用プロセッサ、ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ（ＤＳＰ）、ａｐｐｌｉｃａｔｉｏｎ－ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ（ＡＳＩＣ）、ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ（ＦＰＧＡ）若しくはその他のプログラマブルロジックデバイス、ディスクリートゲート若しくはトランジスタロジック、ディスクリートハードウェアコンポーネント、又はそれらの任意の組み合わせを用いて実装又は実施され得る。汎用プロセッサは、マイクロプロセッサであり得るが、代わりに、プロセッサは、任意のプロセッサ、コントローラ、マイクロコントローラ、又はステートマシーンであり得る。プロセッサはまた、コンピューティングデバイスの組み合わせ（例えば、ＤＳＰとマイクロプロセッサとの組み合わせ、複数のマイクロプロセッサ、ＤＳＰコアと連携した１つ以上のマイクロプロセッサ、又は任意のその他のこうした構成）として実装され得る。

本明細書に説明する機能は、ハードウェア、プロセッサにより実行されるソフトウェア、ファームウェア、又はそれらの任意の組み合わせで実装され得る。プロセッサにより実行されるソフトウェアで実装される場合、機能は、コンピュータ可読媒体上の１つ以上の命令又はコードとして蓄積され得、又は送信され得る。その他の例及び実装は、開示及び添付の請求項の範囲内にある。例えば、ソフトウェアの性質に起因して、本明細書で説明した機能は、プロセッサにより実行されるソフトウェア、ハードウェア、ファームウェア、配線、又はこれらの任意の組み合わせを使用して実装され得る。機能を実装する機構はまた、機能の（複数の）部分が異なる物理的場所において実装されるように分散されることを含め、様々な位置に物理的に設置され得る。また、請求項を含む本明細書で使用するとき、項目のリスト（例えば、“少なくとも１つの”又は“の内の１つ以上”等の句により前置きされる項目のリスト）に使用されるような“又は”は、例えば、Ａ、Ｂ、又はＣの内の少なくとも１つのリストがＡ又はＢ又はＣ又はＡＢ又はＡＣ又はＢＣ又はＡＢＣ（すなわち、Ａ及びＢ及びＣ）を意味するように包含的リストを指し示す。また、本明細書で使用するとき、句“に基づいて”は、条件の閉集合への言及として解釈されないであろう。例えば、“条件Ａに基づいて”として説明する例示的ステップは、本開示の範囲から逸脱することなく、条件Ａ及び条件Ｂの両方に基づき得る。言い換えれば、本明細書で使用するとき、句“に基づいて”は、句“少なくとも部分的に基づいて“と同じ方法で解釈されるであろう。

コンピュータ可読媒体は、非一時的コンピュータストレージ媒体と、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む通信媒体との両方を含む。非一時的ストレージ媒体は、汎用又は専用のコンピュータによってアクセスされ得る任意の利用可能な媒体であり得る。例として、非限定的に、非一時的コンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、電気的消去可能プログラマブルリードオンリーメモリ（ＥＥＰＲＯＭ）、コンパクトディスク（ＣＤ）ＲＯＭ若しくはその他の光ディスクストレージ、磁気ディスクストレージ若しくはその他の磁気ストレージデバイス、又は命令若しくはデータ構造の形式で所望のプログラミングコード手段を搬送又は蓄積するために使用され得、汎用若しくは専用コンピュータ、若しくは汎用若しくは専用プロセッサによりアクセス可能であり得る任意のその他の非一時的媒体を含み得る。また、任意の接続はコンピュータ可読媒体と適切に呼ばれる。例えば、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）、又は赤外線、無線、及びマイクロ波等の無線技術を使用して、ソフトウェアがウェブサイト、サーバ、又はその他のリモートソースから送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）、又は赤外線、無線、及びマイクロ波等の無線技術は媒体の定義に含まれる。ディスク（ｄｉｓｋ）及びディスク（ｄｉｓｃ）は、本明細書で使用するとき、ＣＤ、レーザーディスク（登録商標）、光ディスク、デジタル多用途ディスク（ＤＶＤ）、フロッピーディスク、及びブルーレイディスクを含み、ディスク（ｄｉｓｋ）は通常、データを磁気的に再生する一方、ディスク（ｄｉｓｃ）はレーザーを用いて光学的にデータを再生する。上記の組み合わせも、コンピュータ可読媒体の範囲に含まれる。

本明細書の説明は、当業者が開示を製作又は使用可能なように提供されている。開示への様々な修正は当業者に分かるであろうし、本明細書で定義される包括的な原理は開示の範囲を逸脱することなくその他の変形に適用され得る。したがって、開示は、本明細書に説明した例及び設計に限定されず、本明細書に開示した原理及び新規の機構と一致する最も広い範囲に一致する。

Claims (22)

1. デバイスのソフトウェアが安全であることを認証するフィールドサーバによって行われる方法であって、
   ソフトウェアのアップデートが前記デバイスへ送信されたことの通知を受信することと、
   前記通知を受信することに少なくとも部分的に基づいて、前記デバイスとメモリ内の前記ソフトウェアのアップデートとの間の関連を指し示すフラグを設定することと、
   前記デバイスを認証するための第１のキーと関連付けられた証明書を含む接続リクエストを前記デバイスから受信することと、
   前記接続リクエストを受信することに少なくとも部分的に基づいて、前記デバイスから受信した前記第１のキーが無効であると判定することと、
   前記関連を指し示す前記フラグに少なくとも部分的に基づいて、前記第１のキーを有効であると判定することと、
   前記第１のキーを有効であると判定することに少なくとも部分的に基づいて、前記デバイスとサービスとの間の接続を確立すること
   を含む、方法。
2. 前記フラグに少なくとも部分的に基づいて前記第１のキーを有効であると判定することに少なくとも部分的に基づいて、前記メモリ内のリスト内に前記第１のキーを蓄積すること
   を更に含む、請求項１に記載の方法。
3. 前記デバイスの前記ソフトウェアがアップデートされた後、前記デバイスと関連付けられたアップデートされた証明書を受信することと、
   前記アップデートされた証明書を受信することに少なくとも部分的に基づいて、前記フィールドサーバにより蓄積された前記デバイスと関連付けられた第２の証明書をアップデートすること
   を更に含む、請求項２に記載の方法。
4. 前記第１のキーが有効であると判定することに少なくとも部分的に基づいて、前記デバイスからの追加の接続リクエストを処理すること
   を更に含む、請求項３に記載の方法。
5. 前記接続リクエストを受信することに少なくとも部分的に基づいて、前記第１のキーと関連付けられた前記証明書と前記デバイスと関連付けられた第２の証明書との間の不一致を識別することと、
   前記フラグに少なくとも部分的に基づいて、前記不一致に関係なく前記接続リクエストを検証することであって、前記第１のキーが有効であると判定することは、前記接続リクエストを検証することに少なくとも部分的に基づくこと
   を更に含む、請求項１に記載の方法。
6. 前記第１のキーと関連付けられた前記証明書を、前記フィールドサーバにより蓄積された第２の証明書と比較することと、
   前記第１のキーと関連付けられた前記証明書を前記第２の証明書と比較することに少なくとも部分的に基づいて、アプリケーションプラットフォームへのアクセスのために前記デバイスを認証すること
   を更に含む、請求項１に記載の方法。
7. 前記デバイスを認証することに少なくとも部分的に基づいて、前記サービスへのサブスクリプションを検証すること
   を更に含む、請求項６に記載の方法。
8. 前記認証することは、前記デバイスが前記アプリケーションプラットフォームと通信し、前記サービスにサブスクライブすることを可能にする、請求項６に記載の方法。
9. 前記デバイスから受信した前記第１のキーと関連付けられた前記証明書は、前記デバイスの前記ソフトウェアのハッシュに少なくとも部分的に基づく、請求項１に記載の方法。
10. 前記接続リクエストを受信することに少なくとも部分的に基づいて、前記第１のキーが有効であるか否かを指し示す確認応答メッセージ又は否定確認応答メッセージを前記デバイスへ送信すること
    を更に含む、請求項１に記載の方法。
11. 第１のサーバによって行われる方法であって、
    デバイスに対するソフトウェアのアップデートを識別することと、
    前記ソフトウェアのアップデートを識別することに少なくとも部分的に基づいて前記ソフトウェアのアップデートが前記デバイスへ送信されることの通知を、前記デバイスのソフトウェアが安全であることを認証するための第２のサーバへ送信することと、
    前記デバイスに対する前記ソフトウェアのアップデートを識別することに少なくとも部分的に基づいて、前記ソフトウェアのアップデートを前記デバイスへ送信すること、
    前記デバイスが前記ソフトウェアのアップデートを実施したことを指し示す完了メッセージを前記デバイスから受信することと、
    前記完了メッセージを受信することに少なくとも部分的に基づいて、前記デバイスと関連付けられたアップデートされた証明書を前記第１のサーバから前記第２のサーバへ送信すること
    を含む、方法。
12. 前記デバイスと前記ソフトウェアのアップデートとの間の関連を指し示すフラグが、前記第２のサーバによって、前記通知を受信することに少なくとも部分的に基づいて、メモリ内に設定される、請求項１１に記載の方法。
13. 前記通知は、前記デバイスから受信したキーと関連付けられた証明書が前記ソフトウェアのアップデートに少なくとも部分的に基づいて変更されていることを識別するためのものである、請求項１１に記載の方法。
14. 前記ソフトウェアのアップデートを送信することに少なくとも部分的に基づいて、前記デバイスの一部分を追記書き込みモードで動作するように構成すること
    を更に含む、請求項１１に記載の方法。
15. 前記デバイスの前記一部分を前記追記書き込みモードで動作するように構成することに少なくとも部分的に基づいて、前記ソフトウェアに追加情報を追記することと、
    前記追加情報を追記することに少なくとも部分的に基づいて、前記ソフトウェアのアップデート前に利用可能な前記ソフトウェアのバージョンへのアクセスを防止することと、
    前記追加情報を追記することに少なくとも部分的に基づいて、前記デバイスから受信したキーをアップデートすること
    を更に含む、請求項１４に記載の方法。
16. 第１のサーバデバイスであって、
    デバイスに対するソフトウェアのアップデートを識別することと、
    前記ソフトウェアのアップデートを識別することに少なくとも部分的に基づいて、前記ソフトウェアのアップデートが前記デバイスへ送信されたことの通知を送信することと
    をするように構成された前記第１のサーバデバイスと、
    前記第１のサーバデバイスと電子通信し、
    前記ソフトウェアのアップデートが前記デバイスへ送信されたことの前記通知を受信することと、
    前記通知を受信することに少なくとも部分的に基づいて、前記デバイスとメモリ内の前記ソフトウェアのアップデートとの間の関連を指し示すフラグを設定することと、
    前記デバイスを認証するための第１のキーと関連付けられた証明書を含む接続リクエストを受信することと、
    前記関連を指し示す前記フラグに少なくとも部分的に基づいて、前記第１のキーを有効であるものとして受け入れること
    をするように構成された第２のサーバデバイスと
    を含む、システム。
17. 前記第１のサーバデバイス及び前記第２のサーバデバイスと電子通信する前記デバイスを更に含み、前記デバイスは、
    前記ソフトウェアのアップデートを受信することと、
    前記ソフトウェアのアップデートを受信することに少なくとも部分的に基づいて前記ソフトウェアのアップデートを実施すること
    をするように構成される、請求項１６に記載のシステム。
18. 前記デバイスは、
    前記デバイスのソフトウェアをハッシュすることと、
    前記ソフトウェアの前記ハッシュとデバイス固有のシークレットとに少なくとも部分的に基づいて前記第１のキーを生成すること
    をするように更に構成される、請求項１７に記載のシステム。
19. 前記第２のサーバデバイスは、
    前記ソフトウェアのアップデートの前記実施に少なくとも部分的に基づいて、前記デバイスを認証するための前記第１のキーと関連付けられた前記証明書を含む前記接続リクエストを判定すること
    をするように更に構成される、請求項１７に記載のシステム。
20. 前記第２のサーバデバイスは、
    前記接続リクエストを受信することに少なくとも部分的に基づいて、前記デバイスから受信した前記第１のキーが無効であることを識別すること
    をするように更に構成される、請求項１６に記載のシステム。
21. 前記第２のサーバデバイスは、
    前記第１のキーと関連付けられた前記証明書を前記デバイスと関連付けられた第２の証明書と比較することと、
    前記第１のキーと関連付けられた前記証明書を前記第２の証明書と比較することに少なくとも部分的に基づいて、前記デバイスがアプリケーションサービスにアクセスするための認証手順を実施すること
    をするように更に構成される、請求項１６に記載のシステム。
22. 前記第１のサーバデバイスは、
    前記デバイスの前記ソフトウェアのアップデートが完了した後、前記デバイスと関連付けられたアップデートされた証明書を送信すること
    をするように更に構成される、請求項１６に記載のシステム。