(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】2019524016
(43)【公表日】20190829
(54)【発明の名称】接続デバイスのステータスを管理するための方法
(51)【国際特許分類】
   H04L 9/32 20060101AFI20190802BHJP
   G06F 21/64 20130101ALI20190802BHJP
   H04W 4/00 20180101ALI20190802BHJP
   H04W 12/12 20090101ALI20190802BHJP
【FI】
   !H04L9/00 675B
   !G06F21/64
   !H04W4/00
   !H04W12/12
【審査請求】有
【予備審査請求】未請求
【全頁数】23
(21)【出願番号】2018563057
(86)(22)【出願日】20170522
(85)【翻訳文提出日】20190122
(86)【国際出願番号】EP2017062234
(87)【国際公開番号】WO2017207316
(87)【国際公開日】20171207
(31)【優先権主張番号】16305646.8
(32)【優先日】20160603
(33)【優先権主張国】EP
(81)【指定国】 AP(BW,GH,GM,KE,LR,LS,MW,MZ,NA,RW,SD,SL,ST,SZ,TZ,UG,ZM,ZW),EA(AM,AZ,BY,KG,KZ,RU,TJ,TM),EP(AL,AT,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FR,GB,GR,HR,HU,IE,IS,IT,LT,LU,LV,MC,MK,MT,NL,NO,PL,PT,RO,RS,SE,SI,SK,SM,TR),OA(BF,BJ,CF,CG,CI,CM,GA,GN,GQ,GW,KM,ML,MR,NE,SN,TD,TG),AE,AG,AL,AM,AO,AT,AU,AZ,BA,BB,BG,BH,BN,BR,BW,BY,BZ,CA,CH,CL,CN,CO,CR,CU,CZ,DE,DJ,DK,DM,DO,DZ,EC,EE,EG,ES,FI,GB,GD,GE,GH,GM,GT,HN,HR,HU,ID,IL,IN,IR,IS,JP,KE,KG,KH,KN,KP,KR,KW,KZ,LA,LC,LK,LR,LS,LU,LY,MA,MD,ME,MG,MK,MN,MW,MX,MY,MZ,NA,NG,NI,NO,NZ,OM,PA,PE,PG,PH,PL,PT,QA,RO,RS,RU,RW,SA,SC,SD,SE,SG,SK,SL,SM,ST,SV,SY,TH,TJ,TM,TN,TR,TT,TZ
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.QRコード
(71)【出願人】
【識別番号】504326572
【氏名又は名称】ジエマルト・エス・アー
【住所又は居所】フランス国、92120・ムドン、リユ・ドウ・ラ・ベレリー・6
(74)【代理人】
【識別番号】110001173
【氏名又は名称】特許業務法人川口國際特許事務所
(72)【発明者】
【氏名】ファン,リー・タン
【住所又は居所】フランス国、92190・ムードン、リュ・ドゥ・ラ・ベルリ、6、ジェマルト・エス・ア気付
【テーマコード(参考)】
5J104
5K067
【Fターム(参考)】
5J104AA07
5J104KA05
5J104MA03
5J104NA02
5J104NA37
5J104PA02
5J104PA07
5K067AA32
5K067DD11
5K067DD17
5K067EE02
5K067EE10
5K067EE16
(57)【要約】
本発明は、複数の計算ノード、接続デバイスと関連付けられた公開鍵と秘密鍵を含むペアの鍵から成る不変分散型データベース内でアサーションを公開することによって、接続デバイスのステータスを管理するための方法に関する。方法は、命令メッセージを、第1のユーザに関連付けられた第1の端末から受信すること(501)と、第1のユーザが接続デバイスのステータスの修正を認められることを、検証すること(502)と、ステータス情報を含むアサーションを公開するために不変分散型データベースにアサーションリクエストを送信すること(503)とを行うステップを含む。
【特許請求の範囲】
【請求項1】
複数の計算ノード、接続デバイスと関連付けられた公開鍵と秘密鍵を含むペアの鍵から成る不変分散型データベース内でアサーションを公開することによって、接続デバイスのステータスを管理するための方法であって、
− 第1のユーザの識別子、および接続デバイスに対して考慮されるべき少なくともステータス情報を含む命令メッセージを、前記第1のユーザに関連付けられた第1の端末から接続デバイスによって受信するステップ(501)であって、前記ステータス情報が、接続デバイスの所有権を管理するために使用される、ステップ(501)と、
− 第1のユーザが接続デバイスのステータスの修正を認められることを、接続デバイスによって検証し(502)、肯定的検証の場合、ステータス情報を含むアサーションリクエストを用意するステップであって、アサーションリクエストが、接続デバイスの秘密鍵を使用して、接続デバイスによって署名される、ステップと、
− ステータス情報を含むアサーションを公開するために、アサーションリクエストを不変分散型データベースに接続デバイスによって送信するステップ(503)であって、接続デバイスに関連付けられた公開鍵を使用して分散型不変データベースの計算ノードによって署名が肯定的に検証されるとアサーションが公開される、ステップ(503)と
を行うステップを含む方法。
【請求項2】
ステータス情報のステータス情報が、接続デバイスの新しい所有者の識別子を含む、請求項1に記載の方法。
【請求項3】
新しい所有者の識別子が、公開鍵と秘密鍵を含むペアの鍵に属する公開鍵であり、前記鍵のペアが、接続デバイスの新しい所有者のものである、請求項2に記載の方法。
【請求項4】
命令メッセージが、接続デバイスの以前の所有者の識別子と、合法的な所有者として新しい所有者を示す不変分散型データベース内のアサーションの公開により以前の所有者を新しい所有者に置き換えるための指示とを含む、請求項2または3記載の方法。
【請求項5】
受信された命令メッセージ(501)が秘密データを含み、第1のユーザと接続デバイスが同じ秘密を共有していることを示す、接続デバイスに格納された秘密データと、受信された秘密データが一致する場合、第1のユーザが、接続デバイスのステータスの修正を認められるものとみなされる、請求項1から4のいずれか一項に記載の方法。
【請求項6】
接続デバイスの所有権が、第2のユーザが新しい所有者になるように第1のユーザから第2のユーザに移譲され、移譲が、肯定応答メッセージを第1の端末に送信することによって第2のユーザが関連付けられる第2の端末を使用して第2のユーザによって始められ、前記肯定応答メッセージが、接続デバイスの所有権を第2のユーザに移譲するための少なくとも命令、および第2のユーザの識別子を含む、請求項2から5のいずれか一項に記載の方法。
【請求項7】
接続デバイスの所有権が、第1のユーザが新しい所有者になるように第2のユーザから第1のユーザに移譲され、移譲が、肯定応答メッセージを第1の端末に送信することによって第2のユーザが関連付けられる第2の端末を使用して第2のユーザによって始められ、前記肯定応答メッセージが、接続デバイスの所有権を第1のユーザに移譲するための少なくとも命令、および第2のユーザの識別子を含む、請求項2から5のいずれか一項に記載の方法。
【請求項8】
接続デバイスが、第1のユーザが接続デバイスの合法的な所有者であることを公開アサーションが示す場合、接続デバイスの所有権記録、または不変分散型データベース内の所有権記録をチェックすることによって、第1のユーザが接続デバイスのステータスの修正を認められることを、検証する、請求項1から7のいずれか一項に記載の方法。
【請求項9】
命令メッセージが、アプリケーションがインストールされる第1の端末から受信され、前記アプリケーションが、命令メッセージの用意を制御するように構成される、請求項1から8のいずれか一項に記載の方法。
【請求項10】
接続デバイスが、不変分散型データベース内で公開される接続デバイスのステータス情報を読むために不変分散型データベースにリクエストを送信し、それに応じて前記ステータス情報を受信する、請求項1から9のいずれか一項に記載の方法。
【請求項11】
接続デバイスが盗まれたか、または紛失したことを、受信されたステータス情報が示す場合、接続デバイスが、最小サービスモードに切り替え、接続デバイスの合法的な所有者からの命令の受信を待つ、請求項10に記載の方法。
【請求項12】
複数の計算ノード、接続デバイスと関連付けられた公開鍵と秘密鍵を含むペアの鍵から成る不変分散型データベース内に公開されたアサーションを読むことによって、第三者からアクセス可能なステータス情報に関連付けられる接続デバイスであって、
− 第1のユーザの識別子、および接続デバイスに対して考慮されるべき少なくともステータス情報を含む命令メッセージを受信することであって、前記ステータス情報が、接続デバイスの所有権を管理するために使用されることと、
− 第1のユーザが接続デバイスのステータスの修正を認められることを、検証し、肯定的検証の場合、ステータス情報を含むアサーションリクエストを用意することであって、アサーションリクエストが、接続デバイスの秘密鍵を使用して、接続デバイスによって署名されることと、
− ステータス情報を含むアサーションを公開するために不変分散型データベースにアサーションリクエストを送信することであって、接続デバイスに関連付けられた公開鍵を使用して不変分散型データベースの計算ノードによって署名が肯定的に検証されるとアサーションが公開されることと
を行うように構成される、接続デバイス。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、モバイルデバイスの所有権を管理するための方法および装置に関し、より詳細には分散型データベースの技術ドメインに関する。
【背景技術】
【0002】
ほとんどのモバイルデバイスは、紛失、盗難、または破壊などの予期しないイベントから保護されるように、最近は保険を掛けられている。
【0003】
保険詐欺が一般的になってきたが、その一方で被害者は盗難に遭った人だけでなく、盗まれたデバイスの中古品の買手がなることもある。例として、盗まれたデバイスは、デバイスがいずれかの盗まれたデバイスのデータベースに登録されていないか、またはまだ盗まれたとみなされていない国で売られることがある。
【0004】
第3世代パートナーシッププロジェクト(3GPP:3rd Generation Partnership Project)標準によれば、盗まれたと宣言されるデバイスの識別子は、事業者のデータベースに格納される。この場合、合法的な所有者が、盗まれたデバイスを警察、その事業者、およびその保険に宣言するプロセス中に、窃盗犯は盗まれたデバイスを中古品購入者に売ることができる。デバイスが、テレコミュニケーションシステムによってまだ盗まれたとみなされていないときに、被害者がデバイスの購入時にデバイスをテストすると、デバイスは完全に動作する。しかし、デバイスが後でネットワークに接続すると、元の事業者とデータベースを共有する事業者によってブロックされる可能性がある。主な被害者は、実際には、保険会社および中古デバイスの買手であり、元の買手は、それ自身の保険会社によって一般に返金される。
【0005】
3GPPにおいて、デバイスの識別子は、移動端末装置識別子(IMEI:International Mobile station Equipment Identity)であり、データベースは、機器識別登録簿(EIR:Equipment Identity Register)と呼ばれる。デバイスが盗まれたと宣言されると、デバイスのIMEIは事業者のEIRデータベースに提供される。デバイスが3GPPネットワークに接続すると、デバイスのIMEIはEIRデータベースに送信され、EIRデータベースに格納されているIMEIと照合される。既に強調されているように、デバイスが盗まれたと宣言された場合、デバイスはネットワークに接続することができない。この技術にはいくつかの限界がある。第1に、EIRデータベースは、この技術を効率的にするのに必要なだけの事業者間では共有されない可能性がある。第2に、デバイスの使用が本当に禁止されるまでのプロセスが長い。その上、EIRデータベースの情報へのアクセスは、1つまたはいくつかのモバイル事業者に限定される。この技術は、盗まれたデバイスの使用を禁止するために、盗まれたデバイスの宣言に限定されるということにも留意する必要がある。
【0006】
モノのインターネット(IoT:Internet of Things)に関連して、およびモバイルデバイスの所有権の管理に関連して用いられる別の既存技術がこれから論じられる。
【0007】
スマートウォッチ、または住居環境管理デバイス、気象センサ、もしくはキータグなどの様々な種類の接続センサなどの二次的なデバイスは典型的には、限定されたユーザインターフェースを有するか、またはユーザインターフェースがなく、例えば、IoTサービスプロバイダによって提供されるセルラー接続またはWiFiといった、インターネットとのワイヤレス接続しかないことがある。
【0008】
例えば、キーセットを探すために使用されるキータグなどの接続デバイスの場合、デバイスとユーザの間にリンクが確立される必要がある。その上、キータグは、その登録された所有者によってのみ探すことが可能である。自分のキーを紛失したことを所有者が宣言すると、キータグに関連付けられた、紛失したキーの位置をその所有者に中継して送り返すために、コミュニティが動員される。所与の所有者に一旦関連付けられたキータグの所有権は、別の所有者に移譲されることがある。新しい所有者は、自分のキーを紛失したと宣言でき、これらのキーを探すことができる唯一の人であることが求められる。実際、以前の所有者が、デバイスの新しい所有者を探すことができるので、以前の所有者がデバイスを紛失したと宣言できたとすると、プライバシーの問題に遭遇するだろう。デバイスの所有権を以前の所有者から新しい所有者に移譲するプロセスは存在するが、厄介であり、長い。このようなデバイスの例は、Tile(商標)と呼ばれるコンパニオンデバイスであり、Tile Incorporatedによって提供される。
【0009】
所有権の証拠として、秘密コードが使用されることもある。秘密コードを新しい所有者に提供することが、問題の解決策として利用されることもある。しかしこの技法はいくつかの欠点を伴う。元のユーザが秘密コードを紛失するか、または忘れてしまうことがある。さらに、秘密コードが、物理デバイスの複数の被害者に無関係に「売られる」ことがある。これは、例えば、IoTデバイスが様々な場所に設置されるときのケースである。
【発明の概要】
【発明が解決しようとする課題】
【0010】
したがって、デバイスの所有権が合法であることを保証し、この所有権を第1の所有者から第2の所有者にセキュアかつ効率的に移譲できるようにする技術が必要である。
【課題を解決するための手段】
【0011】
本発明は、複数の計算ノード、接続デバイスと関連付けられた公開鍵と秘密鍵を含むペアの鍵から成る不変分散型データベース(immutable distributed database)内でアサーションを公開することによって、接続デバイスのステータスを管理するための方法に関する。方法は:
− 第1のユーザの識別子、および接続デバイスに対して考慮されるべき少なくともステータス情報を含む命令メッセージを、前記第1のユーザに関連付けられた第1の端末から接続デバイスによって受信することであって、前記ステータス情報が、接続デバイスの所有権を管理するために使用されることと、
− 第1のユーザが接続デバイスのステータスの修正を認められることを、接続デバイスによって検証すること、および肯定的検証の場合、ステータス情報を含むアサーションリクエストを用意することであって、アサーションリクエストが、接続デバイスの秘密鍵を使用して、接続デバイスによって署名されることと、
− ステータス情報を含むアサーションを公開するために、アサーションリクエストを不変分散型データベースに接続デバイスによって送信することであって、接続デバイスに関連付けられた公開鍵を使用して不変分散型データベースの計算ノードによって署名が肯定的に検証されるとアサーションが公開されることと
を行うステップを含む。
【0012】
例として、ステータス情報は、接続デバイスの新しい所有者の識別子を含む。
【0013】
例として、新しい所有者の識別子は、公開鍵と秘密鍵を含むペアの鍵に属する公開鍵であり、前記鍵のペアは、接続デバイスの新しい所有者のものである。
【0014】
例として、命令メッセージは、接続デバイスの以前の所有者の識別子と、合法的な所有者として新しい所有者を示す不変分散型データベース内のアサーションの公開により以前の所有者を新しい所有者に置き換えるための指示とを含む。
【0015】
例として、受信された命令メッセージは秘密データを含み、第1のユーザと接続デバイスが同じ秘密を共有していることを示す、接続デバイスに格納された秘密データと、受信された秘密データが一致する場合、第1のユーザが、接続デバイスのステータスの修正を認められるものとみなされる。
【0016】
例として、接続デバイスの所有権は、第2のユーザが新しい所有者になるように第1のユーザから第2のユーザに移譲され、移譲は、肯定応答メッセージを第1の端末に送信することによって第2のユーザが関連付けられる第2の端末を使用して第2のユーザによって始められ、前記肯定応答メッセージは、接続デバイスの所有権を第2のユーザに移譲するための少なくとも命令、および第2のユーザの識別子を含む。
【0017】
例として、接続デバイスの所有権は、第1のユーザが新しい所有者になるように第2のユーザから第1のユーザに移譲され、移譲は、肯定応答メッセージを第1の端末に送信することによって第2のユーザが関連付けられる第2の端末を使用して第2のユーザによって始められ、前記肯定応答メッセージは、接続デバイスの所有権を第1のユーザに移譲するための少なくとも命令、および第2のユーザの識別子を含む。
【0018】
例として、接続デバイスは、第1のユーザが接続デバイスの合法的な所有者であることを公開アサーションが示す場合、接続デバイスの所有権記録、または不変分散型データベース内の所有権記録をチェックすることによって、第1のユーザが接続デバイスのステータスの修正を認められることを、検証する。
【0019】
例として、命令メッセージは、アプリケーションがインストールされる第1の端末から受信され、前記アプリケーションは、命令メッセージの用意を制御するように構成される。
【0020】
例として、接続デバイスは、不変分散型データベース内で公開される接続デバイスのステータス情報を読むために不変分散型データベースにリクエストを送信し、それに応じて前記ステータス情報を受信する。
【0021】
例として、接続デバイスが盗まれたか、または紛失したことを、受信されたステータス情報が示す場合、接続デバイスは、最小サービスモードに切り替え、接続デバイスの合法的な所有者からの命令の受信を待つ。
【0022】
本発明はまた、複数の計算ノード、接続デバイスと関連付けられた公開鍵と秘密鍵を含むペアの鍵から成る不変分散型データベース内に公開されたアサーションを読むことによって、第三者からアクセス可能なステータス情報に関連付けられる接続デバイスに関し、接続デバイスは、
− 第1のユーザの識別子、および接続デバイスに対して考慮されるべき少なくともステータス情報を含む命令メッセージを受信することと、
− 第1のユーザが接続デバイスのステータスの修正を認められることを、検証し、肯定的検証の場合、ステータス情報を含むアサーションリクエストを用意することであって、アサーションリクエストが、接続デバイスの秘密鍵を使用して、接続デバイスによって署名されることと、
− ステータス情報を含むアサーションを公開するために不変分散型データベースにアサーションリクエストを送信することであって、接続デバイスに関連付けられた公開鍵を使用して不変分散型データベースの計算ノードによって署名が肯定的に検証されるとアサーションが公開されることと
を行うように構成される。
【0023】
本発明のさらなる特徴および利点は、本発明の1つの好ましい実施形態の詳細な説明を読むとさらに明確に理解でき、以下の図面と共に指示的かつ非限定的な例として示される。
【図面の簡単な説明】
【0024】
【図1】複数のステークホルダによって確認され、検証されるアサーションを公開するために使用される分散型データベースを含むワイヤレスシステムの概略図である。
【図2】分散型データベース内でアサーションを公開するために行われ得る処理の例を示す図である。
【図3】1つまたはいくつかのアサーションの公開につながるプロセスが、どのようにして時間内に編成され得るかを概略的に示す図である。
【図4】第1のユーザによって購入されるデバイスの所有権の初めの宣言のために行われ得るシーケンス図の例を示す図である。
【図5】所有権の移譲を宣言するために行われ得るシーケンス図の例を示す図である。
【図6】デバイスが盗まれたことを宣言するために行われ得るシーケンス図の例を示す図である。
【発明を実施するための形態】
【0025】
本明細書において、接続デバイスのステータスを管理するために1つの発明が提案される。以下の例において、これは、接続デバイスの所有権を管理することに関連して説明される。しかし本発明は、接続デバイスのステータスを管理することに、より一般的に適用可能である。ステータスは、例えば、所有権情報、または他のデバイスと比較したリソースへのアクセスの優先度に対応することができる。さらに本発明は、いわゆるIoTデバイスが特に関連するユースケースであるので、IoTデバイスに関して説明される。しかし本発明は、例えば、5Gスマートフォン、タブレット型コンピュータ、またはワイヤレス接続を介して通信できる車両といった、任意のタイプの接続デバイスのステータスを管理するために使用されてよい。
【0026】
図1は、複数のステークホルダによって確認され、検証されるアサーションを公開するために使用される分散型データベースを含むワイヤレスシステムの概略図である。
【0027】
システムには、複数のステークホルダ110−114がいる。ステークホルダは、ワイヤレスシステムのアクタによって運用される計算ノードである。本説明において、計算ノードは、通信ネットワーク上でデータを受信し伝達するためのハードウェア手段およびソフトウェア手段を有し、プログラムを実行するデバイスを指す。ネットワークに接続されるコンピュータは、計算ノードの例である。
【0028】
この例において、第1および第2のモバイルネットワーク事業者によって2つの計算ノード110、111がそれぞれ運用され、IoTモバイルネットワーク事業者によって1つの計算ノード112が運用され、デバイス製造業者、警察、保険会社、または中古市場メーカなどの他のタイプのアクタによって2つの計算ノード113、114が運用される。
【0029】
システムは、宣言エンティティとして指定される他のエンティティも含む。宣言エンティティは、分散型データベース130内で1つまたはいくつかのアサーションの公開をリクエストできるエンティティである。本説明において、分散型データベースは、ネットワークの複数の計算ノード全体にわたってデータが格納されるデータベースを指す。好ましい実施形態によれば、分散型データベースは不変である。有利には、本発明に関連して使用され得る不変分散型データベースの例は、ブロックチェーンである。
【0030】
図1によって提供される例に、第1のモバイルネットワーク事業者の4人のサブスクライバによって使用される4台のモバイルデバイス121、第2のモバイルネットワーク事業者の4人のサブスクライバによって使用される4台のモバイルデバイス120、およびIoTモバイルネットワーク事業者の4人のサブスクライバによって使用される4台のIoTデバイス122が表される。
【0031】
本説明において、IoTデバイスは、マシンツーマシンの通信モジュールを備えるモバイルデバイスを指す。マシンツーマシン(M2M:Machine to Machine)は、1つの端末から別の端末へのデータの伝達、またはGSM/GPRS、UMTS/HSDPA、CDMA/EVDO、LTE、もしくは他のモジュールを介したマシン間のデータの交換を指す。現在M2Mは、セキュリティ監視、自動販売機、公共交通システム、車両監視および管理、工業プロセス自動化、自動車機械設備(motor machineries)、スマートシティなどの分野において、一般に適用される。
【0032】
この例において、これらのデバイスはステークホルダではなく、宣言エンティティの役割しかない。しかし、システムの所与のアクタは、分散型データベース内でアサーションを公開する必要があることもある。この場合、所与の計算ノードは、ステークホルダおよび宣言エンティティの機能を実装するように構成されてよい。これは、例えば、2つのIoTデバイス製造業者113、114のケースであり、両者はこのように構成される計算ノードを運用することができる。
【0033】
この特定の例に関連して、システムの様々なアクタの主な機能が、この後説明される。
【0034】
モバイルネットワーク事業者はそのサブスクライバを有しているか、またはサブスクライバのホーム事業者(HPLMN)にアクセスすることができる。モバイルネットワーク事業者は、そのサブスクライバを分散型データベースに記載する責任があることがある。MNOは、その無線ネットワーク、そのサブスクリプションサービス、および認証機能などの、MNOのネットワークリソースへのアクセスをモバイルデバイスに提供する。MNOは、クレデンシャルを検証すること、およびモバイルデバイスを認証することにも責任がある。MNOは、ユーザによってサブスクライブされたサービスを検証することもできる。さらにMNOのネットワークは、分散型データベースへのアクセスを提供するように構成される。既に強調されたように、MNOは、分散型データベース内で署名済のアサーションを検証および公開することができるアクタであってもよい。
【0035】
暗号動作に、またはセキュア情報の格納に関して、IoTデバイスは、例えば、UICC、eSE、またはeUICCといったセキュア要素に関連付けられてよい。
【0036】
セキュア要素は、例えば、UICC(ユニバーサル集積回路カード(Universal Integrated Circuit Card))である。UICCは、スマートカードの形式、パッケージ化されたチップの形式、または任意の他の形式であってよい。UICCは、例えば、GSMおよびUMTSネットワークにおけるモバイル端末で使用されることがある。UICCは、すべての種類の個人データのネットワーク認証、完全性、およびセキュリティを保証する。
【0037】
UICCは、GSM/GPRSネットワークのためのSIMアプリケーションを主に収め、UMTSネットワークのためのUSIMアプリケーションにおいて、SIMアプリケーションがUSIMアプリケーションである。ロングタームエボリューション(LTE:Long−Term Evolution)をサポートするネットワークに関して、UICCはISIMアプリケーションを収める。UICCは、UMTSおよびLTEネットワークへ同じスマートカードがアクセスできるようにするいくつかの他のアプリケーションを収めることもあり、電話帳の格納ならびに他のタイプのサービスも可能にする。
【0038】
UICCは通常、モバイル端末またはIoTデバイスから取り去られてもよい。自分のUICCを自分の新しい端末に挿入しても、ユーザはまだ、自分のアプリケーション、連絡先、およびクレデンシャル(ネットワーク事業者)にアクセスすることができる。
【0039】
セキュア要素は、eUICCタイプ(埋込型UICC)のものであってもよい。eUICCは、はんだ付けされているか、またはデバイスに完全にリンクされているわけではないが、取り去られることを意図していないので苦労して取り去ることができる、離れているか、またはマシンに完全に統合されている端末内に配置される、UICCである。(例えば、非常に小さく、したがって扱いやすくないという)UICCの特殊なフォームファクタが、UICCが実際に端末内に統合されることを考慮すべき理由になることもある。ソフトウェアによってセキュア要素の機能を実装している技術が、本発明に関連して考慮されてもよい。
【0040】
モバイルネットワーク事業者のサブスクライバは、モバイルネットワーク事業者(MNO:Mobile Network Operator)に対する有効なサブスクリプションを有する。サブスクライバは、例えば、そのモバイルネットワーク事業者を介して、システム内で使用され得るサブスクライバ自身の公開鍵/秘密鍵のペアを有することもできる。サブスクライバは、自分が購入したIoTデバイスをアクティベートすることができる人である。
【0041】
所与のIoTデバイスのアクティベートにつながる暗号プロセスを行うために、サブスクライバは、例えば、スマートフォンといったモバイルデバイス、またはセキュア要素内のアプリケーションに関連付けられてよい。
【0042】
分散型データベースは、システムのステークホルダによって署名され、検証されたすべての有効なアサーションを統合することができる。これらは、システムのステークホルダがアクセスでき、ステークホルダのそれぞれは、システム内で公開された所与のアサーションを読むことができ、その公開を要求した宣言エンティティを認証することができる。
【0043】
要約として、図1で説明されるようなテレコミュニケーションシステムは、以下を含む:
− ネットワーク事業者110−112、またはデバイス製造業者、デバイス証明エンティティ、保険会社、警察、もしくは中古市場メーカなどの他のアクタ113、114によって運用される、複数のステークホルダ110−114からなる分散型データベース130。
− 例えば、ダウンロードされたアプリケーションを使用してアサーションの公開をリクエストするために、サブスクライバが分散型データベースにアクセスできるようにしている1つまたはいくつかのデバイス120、121。
− 所有権が管理される必要があり、分散型データベース130と対話できる、例えば、IoTデバイスといった、1つまたはいくつかのデバイス122。
− 様々なアクタを接続するために使用されるテレコミュニケーションネットワーク131。
【0044】
システムの様々なアクタを取り巻き得る役割および責任が以下に説明される。すべてのこれらの役割および責任は、デバイスの所有権を管理するために、提案されたメカニズムを実装するのに必須ではなく、例証のためだけに以下に示される。
【0045】
分散型データベース130は、以下を行う責任を負い得る:
− 公開アサーションリポジトリをシステムのすべてのアクタがアクセスでき、利用できるようにすること。
− 公開アサーションのオリジネータの匿名を確約すること。
− 公開された公開アサーションの真正性および有効性を検証すること。
− 公開されることになるアサーションにタイムスタンプを押すことおよび署名すること。
− ユーザの秘密鍵/公開鍵のペアをバックアップすること、および鍵回復処理を提供すること。
【0046】
IoTデバイス122は、以下を行う責任を負い得る:
− 合法的な所有者のリスト維持すること。各デバイスに対して1人または数人の所有者がいてよく、これらの所有者は、各デバイスのものである公開鍵/秘密鍵のペアのうちの公開鍵によって識別されてよい。
− デバイスに関連付けられた秘密コードを自分が知っていることが検証されると、自分が最初の1次所有者としてユーザの公開鍵によって識別され得るユーザを受け入れること。
− デバイスの合法的な所有者から受信された命令の真正性および有効性を検証すること。
− 暗号アルゴリズムに基づいて公開鍵をセキュアに計算すること。
− 署名済のアサーションリクエストを生成して分散型データベースのステークホルダに伝達すること。
− 分散型データベース内で公開されたデバイスのステータスを、要求されたときに検証すること。
− 紛失したまたは盗まれたと宣言された後にデバイスが再びオンラインになっていることを、デバイスの合法的な所有者にアラートすること。
【0047】
接続端末を使用するユーザは、以下を行う責任を負い得る:
− IoTデバイスのステータスを監視または変更するために接続端末上でアプリケーションを得ること。接続端末は、例えば、モバイル端末、タブレット型コンピュータ、ラップトップ、またはスマートウォッチであってよい。
− IoTデバイスに関連付けられた秘密コードを入手すること。
− ダウンロードされたアプリケーションを介してIoTデバイスから所有権の宣言/アサーションをリクエストすること。
− IoTデバイスによってアサーションリクエストの送信をトリガすること。
【0048】
ダウンロードされたアプリケーションは、以下を行う責任を負い得る:
− ユーザに関連付けられた公開鍵/秘密鍵のペアを得ることまたは生成すること。
− 例えば、セキュア要素の中にユーザの秘密鍵をセキュアに格納すること。
− ユーザの代わりに、例えば、セキュア要素の中で暗号アルゴリズムをセキュアに実行すること。
− 例えば、初めの所有権情報、または所有権の移譲に関連した命令を生成してIoTデバイスに送信すること。
− 例えば、デバイスを紛失したまたは盗まれたことを宣言するために、ユーザのアサーションリクエストを生成して少なくとも分散型データベースのステークホルダに送信すること。
− ユーザの公開鍵/秘密鍵のペアのバックアップ。
【0049】
他のアクタの責任は、彼らの特性に依存する。例として、証明エンティティは、一定の動作を行うために、デバイスが十分にセキュアであると宣言することができる。アクタはその他に、このような宣言に責任がある。警察は、いくつかのデバイスが無効にされていることを分散型データベース内で宣言することができる。
【0050】
任意のアクタが、デバイスの公開鍵によって識別された任意のデバイスの所有権のステータスを検証することができる。
【0051】
図2は、分散型データベース内でアサーションを公開するために行われ得る処理の例を示す。
【0052】
所与の処理期間において、第1のステークホルダ205は、4つの宣言エンティティ200−203から4つのアサーションリクエスト204を収集する。アサーションリクエストは、分散型データベース内でステークホルダによって公開されることになる情報の少なくとも一部を含むメッセージである。
【0053】
本発明の1つの実施形態によれば、公開鍵と秘密鍵を含む鍵のペアは、各宣言エンティティに関連付けられる。このタイプの鍵のペアは、宣言エンティティの鍵のペアすなわちDEの鍵のペアとして指定される。さらに、DEの公開鍵、またはDEの公開鍵に適用される一方向性関数もしくはハッシュ関数(例えば、SHA−256)の結果は、宣言エンティティの識別子として使用されてよい。宣言エンティティは、DEの鍵のペアの秘密鍵を使用して、アサーションリクエストに署名することができる。
【0054】
例として、アサーションリクエストは、例えば、DEの公開鍵に対する宣言エンティティの識別子を含む。アサーションリクエストは、アサーションの主題を示すラベルを含んでもよい。このラベルは、ステークホルダによって後で解釈され得るデジタルシーケンスである。
【0055】
次に、第1のステークホルダは、宣言エンティティのDEの公開鍵を使用してアサーションリクエストに署名した宣言エンティティを認証し、アサーションブロック206を生成することができる。
【0056】
アサーションブロック206は、所与の処理期間中に第1のステークホルダ205によって受信されたアサーションすべてを含む。アサーションブロック206は、FSの鍵のペアの秘密鍵を使用してそれぞれの受信されたアサーションに署名することによって、および、または代替的に、やはりFSの鍵のペアの秘密鍵を使用して全体ブロックに署名することによって構築されてよい。
【0057】
次に、第1のステークホルダ206は、署名済のアサーションブロックを第2のステークホルダ233に送信する。
【0058】
所与の処理期間中、第2のステークホルダ233は、1人もしくは何人かのステークホルダ220−222によって発せられたアサーションブロック230−232の1つもしくはいくつかを受信するかいずれも受信しないことができる。次に、第2のステークホルダは、受信されたアサーションブロックを集約し、集約アサーションブロック240を提供するためにこの集約の結果に署名する。
【0059】
集約アサーションブロック240はその後、分散型データベース内で公開されてよい260。
【0060】
1つの実施形態によれば、第2のステークホルダのものである鍵のペアにより、署名250が生成される。この鍵のペアは、第2のステークホルダ(SeS:second stakeholder)鍵のペアとして指定され、SeSの秘密鍵およびSeSの公開鍵を備える。好ましい実施形態において、使用される署名アルゴリズムは、現在の処理期間中に受信されたアサーションブロック230、231、232、ならびに分散型データベース内で公開された最後の集約アサーションブロックに対して生成された署名234を入力として用いる。
【0061】
プロセスの利点は、分散型データベース内で、以前に署名済の集約アサーションブロックの権限付与されていない挿入または削除を任意のステークホルダによって検知できるようになることである。データベースへの集約アサーションブロックの追加は、データベースの最後にだけ行われうる。
【0062】
権限付与されていない挿入または削除を任意のステークホルダによって検知できるようにするデータベースは、不変であるとして指定されることが多く、これは図2によって提供される例におけるケースである。本説明において、言及された分散型データベースは不変である。
【0063】
本発明の1つの実施形態によれば、署名済の集約アサーションブロックを公開する前に、分散型データベースのステークホルダのすべてまたは一部によって検証が対処される。
【0064】
署名済の集約アサーションブロックが公開されると、任意のステークホルダは、公開されたアサーションにアクセスし、集約アサーションブロックの署名を検証し、識別された宣言エンティティによって所与のアサーションが発せられたことを検証することができる。
【0065】
所与のステークホルダは、前述の「第1」および「第2」のステークホルダの両者の機能を実行することができるということを当業者は理解するであろう。しかし所与のアサーションブロックを生成するステークホルダ、および前記所与のアサーションを含む署名済の集約アサーションブロックを生成するステークホルダは、異なることが非常に好ましい。
【0066】
ビットコインなどのピアツーピアのデータベースとは異なり、システムのステークホルダだけが、公開されたアサーションにアクセスできるということに留意することが重要である。このために、ステークホルダは、信頼できる第三者に登録される必要がある。この信頼できる当事者は、それ自体がステークホルダである計算ノードによって実装されてよい。例として、信頼できる第三者TTP1は、システムの最初に登録されたステークホルダである。新しいアクタがこの方式に加わりたいと思うとき、新しいアクタは、例えばTTP1といったステークホルダのうちの1つに最初に登録する必要がある。次に例として、TTP1は、クレデンシャル、および新しいアクタの能力を検証する。検証が成功すると、TTP1は、TTP1によって新しいアクタが登録されることを示す署名済の集約アサーションブロックを生成するステークホルダにアサーションを提供することができる。新しいアクタの登録のアサーションが分散型データベースに公開されると、新しいアクタは登録され、この方式の新しいステークホルダになる。この新しいステークホルダは次に、新しいアクタを登録し、分散型に公開されることになるアサーションブロックおよび集約アサーションブロックを生成することができる。
【0067】
公開鍵と秘密鍵を含む鍵のペアは、それぞれの登録されたステークホルダに割り振られる。これは、図2によって説明のために言及された、第1および第2のステークホルダにそれぞれ割り振られるFSおよびSeSの鍵のペアに対応する。
【0068】
所与のステークホルダは、すべての登録されたステークホルダの公開鍵を知っている。したがって彼らは、所与の集約アサーションブロックまたは所与のアサーションブロックが、権限付与された(すなわち登録された)ステークホルダによって正しく署名されたことをいつでも検証することができる。
【0069】
図3は、1つまたはいくつかのアサーションの公開につながるプロセスが、どのようにして時間内に編成され得るかを概略的に示す。
【0070】
この例において、処理サイクルは、ステークホルダの数または処理されることになるアサーションの数、システムの負荷などのシステム属性に依存し得る、指定された期間のうちの4つの処理期間T1、T2、T3、およびT4から成る。
【0071】
第1の処理期間中、第1のステークホルダによってアサーションが受信される。1つまたはいくつかのアサーションから成るアサーションブロックが生成され、署名される300。
【0072】
第2の処理期間中、第1のステークホルダによって第2のステークホルダに、署名済のアサーションブロックが伝達される301。第2のステークホルダは、所定のスケジュールに基づいて選ばれてよく、所与のステークホルダは、集約アサーションブロックを生成する人として各処理期間に対して指定される。代替的に、第2のステークホルダは、ランダムに選ばれてよい。
【0073】
第3の処理期間中、第2のステークホルダは、集約アサーションブロックを生成し、署名する302。
【0074】
第4の処理期間中、システムのステークホルダすべてが、署名済の集約アサーションブロックの有効性を検証し、肯定的検証の場合、ブロックは、分散型データベース内で公開される302。
【0075】
例示的な目的で処理期間の順序は提供されている。処理期間の順序は様々に対処されてよいということを当業者は理解するであろう。例えば、プロセス300および301は、第1の処理期間内に対処されてよく、プロセス302および303は、第2の処理期間内に対処されてよい。
【0076】
図4は、第1のユーザによって購入されるデバイスの所有権の初めの宣言のために行われ得るシーケンス図の例である。
【0077】
この例において、第1のユーザであるユーザ1は、IoTデバイスの所有権を管理するためにアプリケーションがサービスへのアクセスを可能にする、例えば、モバイル端末、ラップトップ、またはタブレット型コンピュータといった端末を使用する。アプリケーションは、Apple StoreまたはGoogle Playなどのアプリケーションマーケット上で利用可能になることがある(AppleおよびGoogleは登録商標である)。
【0078】
サービスを使用するためにユーザ1が記載されることが仮定される。1つの実施形態によれば、記載されると、アプリケーションがインストールされる端末は、秘密鍵/公開鍵のペアを提供される。この鍵のペアは、端末によってローカルに生成されてもよい。ユーザ1の端末が、鍵のペアを格納するセキュア要素と連携することを含むこともできる。このセキュア要素は、セキュア環境内で暗号アルゴリズムを行うように構成されてもよい。このセキュア要素は、例えば、UICC、eUICC、またはeSEである。
【0079】
所有権が管理される必要がある新たに購入されたIoTデバイスは、ユーザ1と共有される秘密を有する。この秘密は、例えば、個人識別番号(PIN:personal identification number)、シリアル番号、またはIMEIなどのコードである。この秘密は、デバイス上に、デバイスのユーザマニュアル上に、またはより一般的には、例えば、デバイスのパッケージを開けた後に、IoTデバイスの合法的な所有者だけしか知らない場所に印刷されてもよい。
【0080】
デバイス上に秘密が印刷される場合、これは、一連のキャラクタ、ディジット、またはフラッシュコード(QRコード)の形をとることができる。代替的に、これは、非接触タグの中に格納されてよく、またIoTデバイスによって生成されてユーザ1に表示されてもよい。
【0081】
別の実施形態によれば、IoTデバイスは、それ自体の公開鍵/秘密鍵のペアを有し、セキュアな永続メモリ、セキュア要素、UICC、またはeUICCにおけるデバイスの内部に格納される。
【0082】
ユーザ1は、IoTデバイスの秘密およびデバイスの公開鍵を入手する400。これは、IoTデバイス上、またはその元のパッケージ上のこれらの情報を読むことによって、およびその後キー入力することによって行われてよく、また端末のカメラを使用して、または近距離無線通信(NFC:Near Field Communication)インターフェースなどの、短距離ワイヤレスインターフェース使用して入手されてもよい。
【0083】
ユーザ1の端末は次に、例えば以下を含む宣言の暗号署名を行うことによって所有権の宣言を生成する:
− ユーザ1がIoTデバイスの所有者であることを示す命令。
− 宣言した所有者の識別子として提供されるユーザ1の公開鍵。
− 所有権がアサーションされるデバイスの識別子として提供されるIoTデバイスの公開鍵。
− IoTデバイスの公開鍵で暗号にされ得る秘密コード。
【0084】
例えば、宣言は、ユーザ1のものである秘密鍵を使用して署名されてよい。
【0085】
宣言はその後、例えば、直接のデバイス間通信を使用して、または代替的に、ワイヤレステレコミュニケーションネットワークを通じて、通信インターフェースを介してIoTデバイスに伝達される401。
【0086】
ユーザ1は任意選択で、登録されたデータベース(図示せず)のステークホルダに同じ宣言を送信することもできる。
【0087】
本発明の一態様によれば、デバイスによって受信された所有権の宣言の真正性は、ユーザ1の公開鍵を使用して前記宣言の署名をチェックすることによってアサーションを生成する前にチェックされてよい。
【0088】
IoTデバイスは、IoTデバイスを識別する正しい公開鍵、およびこのデバイスの正しい秘密を宣言が含むことを検証することもできる。
【0089】
宣言を受信すると、IoTデバイスは、秘密コードが暗号にされた場合、秘密コードを復号すること、秘密コードを検証すること、提供された秘密コードがIoTデバイスの内部に格納された参照コードにマッチする場合、署名済のアサーションリクエストを生成することを行うことができる402。例として、署名済のアサーションリクエストは以下を含む:
− アサーションリクエストが所有権の宣言に関連するという指示。
− 例えば、ユーザ1の公開鍵といった、所有者の識別子。
− 例えば、IoTデバイスの公開鍵といった、デバイスの識別子。
− IoTデバイスによって、IoTデバイスの秘密鍵を使用して生成される署名。
【0090】
次に、署名済のアサーションリクエストは、分散型データベースのステークホルダにIoTデバイスによって送信される403。
【0091】
アサーションリクエストを受信すると、ステークホルダは、アサーションリクエストの有効性を検証する。このために、以下のことがチェックされる:
− IoTデバイスの公開鍵を使用することによって署名が有効であること。
− これが所有権の初めの宣言であること。
【0092】
アサーションが有効な場合、ステークホルダは、アサーションがデータベースに公開されるようにアサーションを用意することができる。図2によって提案された例については、アサーションリクエストを受信するステークホルダがアサーションを用意する。アサーションは、例えば、以下を含む:
− アサーションが所有権の宣言に関連するという指示。
− 例えば、ユーザ1の公開鍵といった、所有者の識別子。
− 例えば、IoTデバイスの公開鍵といった、デバイスの識別子。
− アサーションリクエストを受信したステークホルダによって、このステークホルダの秘密鍵を使用して生成される署名。
【0093】
次に、ステークホルダは、少なくとも1つのアサーションのセットを含むアサーションブロックを構築し、このアサーションブロックを、その後分散型データベース内で公開される署名済の集約アサーションブロックを生成するために、いくつかのアサーションブロックを集約して署名できる第2のステークホルダに伝達することができる。
【0094】
公開されると、IoTデバイスの所有者を識別するアサーションは、ユーザ1を含む任意の認められたアクタによって、このアクタの端末およびIoTデバイス自体を介してアクセス可能になる405、406。
【0095】
図5は、所有権の移譲を宣言するために行われ得るシーケンス図の例である。
【0096】
この例において、ユーザ2として指定された第2のユーザは、ユーザ1として指定された第1のユーザによって所有されるIoTデバイスを入手したいと思っている。
【0097】
ユーザ1およびユーザ2は、彼らの端末にダウンロードされたアプリケーションを使用して、彼らに関連付けられた公開鍵/秘密鍵のペアをそれぞれ得た。
【0098】
さらに、図4の例によって示されるように、IoTデバイスを用いてユーザ1が初めの所有権の宣言を正常に行ったことが仮定される。したがって、対応するアサーションが分散型データベース内で公開される。
【0099】
ユーザ2の秘密鍵で署名された所有権の移譲に対するユーザ2の肯定応答500を、ユーザ2がユーザ1に提供するときに、所有権の移譲が始められてよい。肯定応答は、例えば、以下を含む:
− IoTデバイスの所有権の移譲に関する肯定応答。
− 例えば、IoTデバイスの公開鍵といった、デバイスの識別子。
− 新しいユーザの識別子としてのユーザ2の公開鍵。
− ユーザ2によって、ユーザ2の秘密鍵を使用して生成される署名。
【0100】
例えば、ユーザ2は、分散型データベースにアクセスすることによって、ユーザ1がIoTデバイスの実際の所有者であることを、取得前に検証することができる。
【0101】
ユーザ1は、ユーザ1の秘密鍵を使用して署名された所有権変更の命令501を、ユーザ1の端末を使用してIoTデバイスに送信する。命令は、例えば以下を含む:
− IoTデバイスの所有権を変更する命令。
− 現在の所有者の識別子としてのユーザ1の公開鍵。
− IoTデバイスの所有権の移譲に関するユーザ2の肯定応答。
【0102】
有利には、IoTデバイスの合法的な所有者としてユーザ1が既に登録されているので、IoTデバイスの秘密コードをユーザ1が送信する必要はない。
【0103】
代替的に、ユーザ1とユーザ2が彼らの公開鍵を交換するときの初めのステップに続いて、ユーザ1の秘密鍵で署名されたIoTデバイスの所有権の移譲の同意をユーザ1がユーザ2に提供するときに、所有権の移譲が始められる。同意は、例えば以下を含む:
− IoTデバイスの所有権を変更することへの同意。
− 例えば、IoTデバイスの公開鍵といった、デバイスの識別子。
− 現在の所有者の識別子としてのユーザ1の公開鍵。
− 新しい所有者の識別子としてのユーザ2の公開鍵。
− ユーザ1によって、ユーザ1の秘密鍵を使用して生成される署名。
【0104】
ユーザ2は、ユーザ2の秘密鍵を使用して署名された所有権変更の命令を、ユーザ2の端末を使用してIoTデバイスに送信する。命令は、例えば、以下を含む:
− IoTデバイスの所有権を変更する命令。
− IoTデバイスの所有権の移譲に関するユーザ1の同意。
− 新しい所有者の識別子としてのユーザ2の公開鍵。
− ユーザ2によって、ユーザ2の秘密鍵を使用して生成される署名。
【0105】
IoTデバイスの所有権を変更するための命令を受信すると、IoTデバイスは以下のタスクを行う502:
− ユーザ1の公開鍵を使用して署名の有効性をチェックすることによって、ユーザ1からの命令または同意の真正性を検証すること。
− ユーザ2の公開鍵を使用して署名の有効性をチェックすることによって、ユーザ2からの命令または肯定応答の真正性を検証すること。
− 例えば、IoTデバイスの現在の所有者の識別子としてユーザ1の公開鍵が公開されていることを分散型データベース内で検証することによって、デバイスの合法的な所有者としてユーザ1が宣言されることを検証すること。
− ユーザ1の置換えの際、新しい所有者としてユーザ2を宣言するために、新しいアサーションを生成すること。
− IoTデバイスの秘密鍵で宣言に署名すること。
【0106】
所有権変更のアサーションは次に、分散型データベースのステークホルダに伝達される503。
【0107】
この新しいアサーションを受信すると、ステークホルダは以下のタスクを行う504:
− IoTデバイスの公開鍵を使用してアサーションの真正性を検証すること。
− 分散型データベース内に並行アサーションがないことをチェックすること。
− ステークホルダの秘密鍵で所有権変更の新しいアサーションにタイムスタンプを押し、署名する。
− アサーションが公開されるように、第2のステークホルダへのアサーションブロック中へ送信すること。
− 分散型データベース内で署名済のアサーションを公開すること。
【0108】
このステージから、分散型データベースへのアクセスを認められる任意のアクタ505が、IoTデバイスの新しい所有権をチェックすることができる。特に、IoTデバイスの所有権が正しくユーザ2に移譲されたことをユーザ2が検証することができる506。
【0109】
図6は、デバイスが盗まれたことを宣言するために行われ得るシーケンス図の例である。
【0110】
紛失または盗まれたデバイスの場合、合法的な所有者が、盗難または紛失をすぐに宣言することができる。この宣言はその後、デバイスのステータスが何であるかをシステムの任意のユーザが公開直後にチェックできるように、分散型データベース内で公開される。この例によれば、デバイスの合法的な所有者であるユーザ1が、盗まれたものとしてデバイスを宣言する。例として、このデバイスのステータス「盗難」がデータベース内で公開されることになる。この新しいステータス情報が、例えば、IoTデバイスに悪いことは何も起こらなかったことを示す、分散型データベース内で公開されたステータス「通常」を置き換える。
【0111】
さらに、異なるステータス指標が分散型データベース内で公開されることになる他のタイプのイベントが宣言されてもよい。例えば、デバイスの紛失が合法的なユーザによって宣言されてよく、その結果、ステータス「紛失」が、分散型データベース内でこのデバイスに対して公開される。
【0112】
合法的な所有者であるユーザ1は、IoTデバイスの所有権を管理するためにユーザが分散型データベースとデータを交換できるようにするダウンロードされたアプリケーションを有する通信端末を介して、デバイスが紛失したことを示すアサーションリクエスト内の宣言を分散型データベースに伝達する600。このアサーションリクエストはユーザ1の秘密鍵を使用して署名され、このプロセスは前述のアプリケーションによって行われる。
【0113】
例えば、アサーションリクエストは、以下を含む:
− 例えば、ユーザ1の公開鍵といった、所有者の識別子。
− 例えば、IoTデバイスの公開鍵といった、デバイスの識別子。
− IoTデバイスが「盗難」されたことを示す指示。
【0114】
アサーションリクエストを受信し、前記リクエスト601を検証した後、アサーションは分散型データベース内で用意され、公開される602。より正確には、また例として、分散型データベースの第1のステークホルダが宣言の真正性を検証する。このために、アサーションリクエストの署名が、ユーザ1の公開鍵を使用して検証される。その後、第1のステークホルダは、リクエスト内で提供される所有者の識別子が、このリクエストに対する分散型データベース内で公開されている識別子にマッチすることを検証する。この例において、検証される識別子は、ユーザ1の鍵のペアのうちの公開鍵に対応する。
【0115】
宣言が真正かつ有効である場合、第1のステークホルダは、ユーザ1に属するデバイスが盗まれたことを示すアサーションを用意することができる。アサーションは、以下から成る可能性がある:
− IoTデバイスが「盗難」されたことを示す指示。
− 例えば、ユーザ1の公開鍵といった、所有者の識別子。
− 例えば、IoTデバイスの公開鍵といった、デバイスの識別子。
− アサーションリクエストを受信したステークホルダによって、このステークホルダの秘密鍵を使用して生成される署名。
【0116】
署名済のアサーションはその後、第2のステークホルダによって分散型データベース上で、例えば、図2によって示されるような署名済の集約アサーションブロック内に公開される。
【0117】
したがって、分散型データベースにアクセスできる任意のアクタは、デバイスの現在の所有権およびステータスをチェックすることができる603。
【0118】
例えば、デバイスの将来の買手は、デバイスの合法的な所有者であるユーザ1によって、デバイスが紛失した/盗まれたと宣言されたかどうかを確かめることができる。
【0119】
また、所与のデバイスが紛失した/盗まれたとデバイスの所有者によって宣言されたことを警察が検知することができ、デバイスの何らかの使用が不法であるとみなされる可能性がある。
【0120】
警察および保険会社はシステムの一部であってよく、使用に不適正なデバイスを宣言することができる。結果として、デバイスを見つけた人は誰でも、デバイスを警察に報告するか、またはデバイスを保険会社に返すことが奨励される。
【0121】
さらにIoTデバイスは、分散型データベースにアクセスすることによって、IoTデバイス自体のステータスをチェックすることができる604。これは、特定のイベントが発生した時にデバイスのスイッチが入るか、または切られるときに周期的に行われてよい。
【0122】
デバイスが紛失したと宣言されたことを、デバイスが発見する場合604、デバイスは、デバイスが再びオンラインになっていること、およびデバイスが、ユーザ1からのさらなる命令を待っていることを示すアラートメッセージ605をユーザ1に送信することができる。
【0123】
さらに、IoTデバイスは最小サービスに移行し、IoTデバイスの合法的な所有者であるユーザ1からの新しい命令を待つことができる。
【0124】
ユーザ1は、例えば、ユーザ1がデバイスを見つけて取り戻した場合、再アクティベート命令をデバイスに直接送信することによって、デバイスを再アクティベートすることを決めることができる。これは、ステータスを盗難から通常に変更するために、アサーションリクエストをデータベースに送信するようにデバイスをトリガする。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【国際調査報告】