特開 2024-110955 車両用オンデマンドサービスの認証を行う装置及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024110955

(43)【公開日】2024-08-16

(54)【発明の名称】車両用オンデマンドサービスの認証を行う装置及び方法

(51)【国際特許分類】

   H04L 9/32 20060101AFI20240808BHJP

   G06F 21/33 20130101ALI20240808BHJP

【ＦＩ】

H04L9/32 200B

H04L9/32 200F

G06F21/33

【審査請求】有

【請求項の数】9

【出願形態】ＯＬ

(21)【出願番号】P 2024015059

(22)【出願日】2024-02-02

(31)【優先権主張番号】10-2023-0014842

(32)【優先日】2023-02-03

(33)【優先権主張国・地域又は機関】KR

(31)【優先権主張番号】10-2023-0042322

(32)【優先日】2023-03-30

(33)【優先権主張国・地域又は機関】KR

(71)【出願人】

【識別番号】523045180

【氏名又は名称】４２ドット・インコーポレイテッド

【氏名又は名称原語表記】４２ｄｏｔ Ｉｎｃ．

(74)【代理人】

【識別番号】100145403

【弁理士】

【氏名又は名称】山尾 憲人

(74)【代理人】

【識別番号】100135703

【弁理士】

【氏名又は名称】岡部 英隆

(74)【代理人】

【識別番号】100227927

【弁理士】

【氏名又は名称】中村 拓

(72)【発明者】

【氏名】ソン，チャンヒョン

(72)【発明者】

【氏名】キム，ソンジュン

(72)【発明者】

【氏名】イ，ソンヨン

(72)【発明者】

【氏名】キム，デジュン

(57)【要約】      （修正有）

【課題】車両用オンデマンドサービスの認証を行う装置及び方法を提供する。
【解決手段】装置は、ＴＩＦ設備から車両及び販売システムでのサービス先行購入オプション値を取得４０２し、サービス先行購入オプション値をセキュリティ領域内のセキュリティストレージに記憶４０３させる。次に、プライベートルート秘密鍵及びプライベートルート証明書を取得または生成４４０する。次に、実行制御器ごとに、プライベートルート秘密鍵で署名されたデバイス証明書とデバイス秘密鍵を生成４０５する。次に，プライベートルート証明書、プライベートルート秘密鍵を使用してサービス先行購入オプション値に対するサービストークンを発行４０６する。そして、生成されたサービストークン、プライベートルート証明書及びデバイス秘密鍵を各実行制御器に伝達４０７する。
【選択図】図４

【特許請求の範囲】

【請求項1】

車両用オンデマンドサービスの認証を行うための統合通信制御器（Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）において、
ＴＩＦ（Ｔｏｏｌ Ｉｎ Ｆａｃｔｏｒｙ）装置から受信した車両用サービスに関する第１オプション値をサービス認証サーバ（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｓｅｒｖｅｒ）に記憶させるステップと、
プライベートルート秘密鍵（ｐｒｉｖａｔｅ ｒｏｏｔ 秘密 ｋｅｙ）及びプライベートルート証明書（ｐｒｉｖａｔｅ ｒｏｏｔ ｃｅｒｔｉｆｉｃａｔｅ）を取得または生成するステップと、
実行制御器ごとに前記プライベートルート秘密鍵で署名されたデバイス証明書（ｄｅｖｉｃｅ ｃｅｒｔｉｆｉｃａｔｅ）及びデバイス秘密鍵（ｄｅｖｉｃｅ ｐｒｉｖａｔｅ ｋｅｙ）を生成するステップと、
前記プライベートルート証明書、前記プライベートルート秘密鍵を用いて前記第１オプション値に対するサービストークンを生成するステップと、
前記生成されたサービストークン、前記プライベートルート証明書及び前記デバイス秘密鍵を前記実行制御器ごとに送信するステップと
を含む、方法。

【請求項2】

前記プライベートルート秘密鍵及び前記プライベートルート証明書（ｐｒｉｖａｔｅ ｒｏｏｔ ｃｅｒｔｉｆｉｃａｔｅ）は、前記統合通信制御器のセキュリティ領域（Ｓｅｃｕｒｅ Ｗｏｒｌｄ）内で生成される、請求項１に記載の方法。

【請求項3】

前記サービストークンは、前記統合通信制御器の一般領域（Ｎｏｒｍａｌ Ｗｏｒｌｄ）内で生成される、請求項２に記載の方法。

【請求項4】

前記プライベートルート秘密鍵及びプライベートルート証明書は、前記統合通信制御器の前記サービス認証サーバで生成される、請求項１に記載の方法。

【請求項5】

前記サービストークンは、前記統合通信制御器の一般領域（Ｎｏｒｍａｌ Ｗｏｒｌｄ）内で生成される、請求項４に記載の方法。

【請求項6】

前記サービストークンを生成するステップは、
ＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）対称鍵を生成し、前記第１オプション値をＡＥＳ暗号化して前記サービストークン内のペイロードフィールドに記憶させるステップと、
前記デバイス証明書で前記ＡＥＳ対称鍵をＲＳＡに暗号化し、前記サービストークン内のヘッダフィールドに追加するステップと、
前記プライベートルート秘密鍵で前記サービストークンにデジタル署名するステップと
を含む、請求項１に記載の方法。

【請求項7】

車両用オンデマンドサービスの認証を行うための統合通信制御器（Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）において、
ＤＭサーバと暗号化セキュリティ通信（ｍＴＬＳ）とを連結させるステップと、
前記暗号化セキュリティ通信を用いて、前記ＤＭサーバから受信した車両用サービスに関する第２オプション値を取得するステップと、
前記第２オプション値、署名（Ｓｉｇｎａｔｕｒｅ）、サーバ証明書（Ｓｅｒｖｅｒ ｃｅｒｔｉｆｉｃａｔｅ）のうち１つ以上を用いて署名を検証するステップと、
前記第２オプション値及びクライアント秘密鍵（ｃｌｉｅｎｔ ｐｒｉｖａｔｅ ｋｅｙ）のうち１つ以上を用いて前記第２オプション値を復号化するステップと、
前記署名及び前記第２オプション値に基づいてサービストークンを生成するステップと、
前記生成されたサービストークンを実行制御器ごとに送信するステップと
を含む、方法。

【請求項8】

車両用オンデマンドサービスの認証を行うための統合通信制御器（Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）として、
ＴＩＦ（Ｔｏｏｌ Ｉｎ Ｆａｃｔｏｒｙ）装置から受信した車両用サービスに関する第１オプション値を取得し、
プライベートルート秘密鍵（ｐｒｉｖａｔｅ ｒｏｏｔ 秘密 ｋｅｙ）及びプライベートルート証明書（ｐｒｉｖａｔｅ ｒｏｏｔ ｃｅｒｔｉｆｉｃａｔｅ）を取得または生成し、
実行制御器ごとに前記プライベートルート秘密鍵で署名されたデバイス証明書（ｄｅｖｉｃｅ ｃｅｒｔｉｆｉｃａｔｅ）及びデバイス秘密鍵（ｄｅｖｉｃｅ ｐｒｉｖａｔｅ ｋｅｙ）を生成し、
前記プライベートルート証明書、前記プライベートルート鍵を用いて前記第１オプション値に対するサービストークンを生成し、
前記生成されたサービストークン、前記プライベートルート証明書及び前記デバイス秘密鍵を前記実行制御器ごとに送信する、装置。

【請求項9】

請求項１に記載の方法をコンピュータで実行するためのプログラムを記録したコンピュータで読み取り可能な記録媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は車両用オンデマンドサービスの認証を行う装置及び方法｛ＡＰＰＡＲＡＴＵＳ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＰＥＲＦＯＲＭＩＮＧ ＡＵＴＨＥＮＴＩＣＡＴＩＯＮ ＦＯＲ ＶＥＨＩＣＬＥ ＯＮ－ＤＥＭＡＮＤ ＳＥＲＶＩＣＥ｝に関する。

【背景技術】

【0002】

最近、消費者が求める機能を必要な期間だけ購入して使用できるサブスクリプションサービス市場が徐々に拡大している。これに関連し、車両のサブスクリプションサービスは、単なるレンタカーから脱し、電気自動車の充電サービスや自動運転、車両管理に至るまで日々多様化している。さらに、車両のサブスクリプションサービスは、各種内部機能に関連して音楽やビデオストリーミング、道案内、車両管理、安全及びセキュリティなどのコネクティビティサービスにまで徐々に拡大している。

【0003】

特に、最近は自動運転システムなどの特定のオプション仕様をサブスクリプションサービスの形態で提供する車両用オンデマンドサービスが本格的に導入されている。車両用オンデマンドサービスが導入される場合、車両購入時に購入パッケージに応じて必要なオプションを購入するために不要なオプション仕様まで選択しなければならなかった不便と経済的負担から抜け出し、サブスクリプションサービスで好みに合わせて希望する機能を選択できるだけでなく、一時的に機能を解除したり、再サブスクリプションすることができ、消費者の多様なニーズを満たすことができるという利点が存在する。

【発明の概要】

【発明が解決しようとする課題】

【0004】

本発明の目的は、車両用オンデマンドサービスの認証を行う装置及び方法を提供することにある。本発明が解決しようとする課題は、以上で述べた課題に限定されず、言及されていない本発明の他の課題及び利点は、下記の説明によって理解されることができ、本発明の実施形態でより明確に理解されるであろう。さらに、本発明が解決しようとする課題及び利点は、特許請求の範囲に示された手段及びその組み合わせで実現できることが分かるであろう。

【課題を解決するための手段】

【0005】

上述した技術的課題を達成するための技術的手段として、車両用オンデマンドサービスの認証を行うための統合通信制御器（Ｃｏｍｕｎｉｃａｔｉｏｎ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）において、ＴＩＦ（Ｔｏｏｌ Ｉｎ Ｆａｃｔｏｒｙ）装置から受信した車両用サービスに関する第１オプション値をサービス認証サーバ（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｓｅｒｖｅｒ）に記憶させるステップと、プライベートルート秘密鍵（ｐｒｉｖａｔｅ ｒｏｏｔ 秘密 ｋｅｙ）及びプライベートルート証明書（ｐｒｉｖａｔｅ ｒｏｏｔ ｃｅｒｔｉｆｉｃａｔｅ）を取得または生成するステップと、実行制御器ごとに前記プライベートルート秘密鍵で署名されたデバイス証明書（ｄｅｖｉｃｅ ｃｅｒｔｉｆｉｃａｔｅ）及びデバイス秘密鍵（ｄｅｖｉｃｅ ｐｒｉｖａｔｅ ｋｅｙ）を生成するステップと、前記プライベートルート証明書、前記プライベートルート秘密鍵を用いて前記第１オプション値に対するサービストークンを生成するステップと、前記生成されたサービストークン、前記プライベートルート証明書及び前記デバイス秘密鍵を、前記実行制御器ごとに送信するステップとを含む方法が提供される。

【0006】

本開示の第２側面は、車両用オンデマンドサービスの認証を行うための統合通信制御器（Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）において、ＤＭサーバと暗号化セキュリティ通信（ｍＴＬＳ）とを連結させるステップと、前記暗号化セキュリティ通信を用いて前記ＤＭサーバから受信した車両用サービスに関する第２オプション値を取得するステップと、前記第２オプション値、署名（Ｓｉｇｎａｔｕｒｅ）、サーバ証明書（Ｓｅｒｖｅｒ ｃｅｒｔｉｆｉｃａｔｅ）のうち１つ以上を用いて署名を検証するステップと、前記第２オプション値及びクライアント秘密鍵（ｃｌｉｅｎｔ ｐｒｉｖａｔｅ ｋｅｙ）のうち１つ以上を用いて前記第２オプション値を復号化するステップと、前記署名及び前記第２オプション値に基づいてサービストークンを生成するステップと、前記生成されたサービストークンを実行制御器ごとに送信するステップとを含む方法を提供することができる。

【0007】

本開示の第３側面は、車両用オンデマンドサービスの認証を行うための統合通信制御器（Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）であり、ＴＩＦ（Ｔｏｏｌ Ｉｎ Ｆａｃｔｏｒｙ）装置から受信した車両用サービスに関する第１オプション値を取得し、プライベートルート秘密鍵（ｐｒｉｖａｔｅ ｒｏｏｔ 秘密 ｋｅｙ）及びプライベートルート証明書（ｐｒｉｖａｔｅ ｒｏｏｔ ｃｅｒｔｉｆｉｃａｔｅ）を取得または生成し、実行制御器ごとに前記プライベートルート秘密鍵で署名されたデバイス証明書（ｄｅｖｉｃｅ ｃｅｒｔｉｆｉｃａｔｅ）及びデバイス秘密鍵（ｄｅｖｉｃｅ ｐｒｉｖａｔｅ ｋｅｙ）を生成し、前記プライベートルート証明書、前記プライベートルート秘密鍵を用いて前記第１オプション値に対するサービストークンを生成し、前記生成されたサービストークン、前記プライベートルート証明書及び前記デバイス秘密鍵を、前記実行制御器ごとに送信するデバイスを提供することができる。

【0008】

その他にも、本発明を具現するための他の方法、他のシステム及び前記方法を実行するためのコンピュータプログラムが記憶されたコンピュータで読み取り可能な記録媒体がさらに提供されることができる。

【0009】

前述したもの以外の他の側面、特徴、利点が、以下の図面、特許請求の範囲及び発明の詳細な説明から明確になるであろう。

【発明の効果】

【0010】

前述した本開示の課題を解決するための手段によれば、本開示では、車両用オンデマンドサービスがハッキングに対し安全にサービスされることができる。また、本開示では、車両用オンデマンドサービスの認証システムがハッキングされるとしても他の車両には伝播されず、当該車両に限定して侵害が発生することができる。

【図面の簡単な説明】

【0011】

【図1】図１は、一実施形態に係る車両用オンデマンドサービスの認証を行う装置またはシステムを説明するための図である。

【図2】図２は、一実施形態に係る車両用オンデマンドサービスの認証を行う装置またはシステムを説明するための図である。

【図3】図３は、一実施形態に係る車両用オンデマンドサービスの認証を行う装置またはシステムを説明するための図である。

【図4】図４は、一実施形態に係る第１ユースケースの動作をフローチャートで示したものである。

【図5】図５は、一実施形態に係る、上述した第１ユースケースの第１実施形態及び第２実施形態をそれぞれ示したものである。

【図6】図６は、一実施形態に係る、上述した第１ユースケースの第１実施形態及び第２実施形態をそれぞれ示したものである。

【図7】図７は、一実施形態に係る第２ユースケースの動作をブロック図で示したものである。

【図8】図８は、一実施形態に係る第２ユースケースの動作を動作主体別に示すフローチャートである。

【図9】図９は、一実施形態に係るサービストークンを生成する方法を示すフローチャートである。

【図10A】図１０Ａは、サービストークンの生成及び検証をそれぞれ説明するための図である。

【図10B】図１０Ｂは、サービストークンの生成及び検証をそれぞれ説明するための図である。

【発明を実施するための形態】

【0012】

本発明の利点及び特徴、並びにそれらを達成する方法は、添付の図面と共に詳細に説明される実施形態を参照すれば明確になるであろう。しかしながら、本発明は、以下に提示される実施形態に限定されるものではなく、互いに異なる様々な形態で具現されることができ、本発明の思想及び技術範囲に含まれる全ての変換、均等物から代替物を含むものと理解されるべきである。以下に提示される実施形態は、本発明の開示を完全にし、本発明が属する技術分野において通常の知識を有する者に発明の範疇を完全に知らせるために提供されるものである。本発明を説明することにおいて、関連する公知技術に対する具体的な説明が本発明の要旨を阻害する可能性があると判断される場合、その詳細な説明を省略する。

【0013】

本出願で使用される用語は、単に特定の実施形態を説明するために使用されたものであり、本発明を限定しようとする意図ではない。単数の表現は、文脈上明らかに別段の意味を持たない限り、複数の表現を含む。本出願において、「含む」または「有する」などの用語は、本明細書に記載の特徴、数字、ステップ、動作、構成要素、部品、またはそれらを組み合わせたものが存在することを指定するものであり、１つまたは複数の他の特徴や数字、ステップ、動作、構成要素、部品、またはそれらを組み合わせたものの存在または追加の可能性を予め排除しないことと理解されるべきである。

【0014】

本開示の一部の実施形態は、機能的なブロック構成及び様々な処理ステップで表現されることができる。そのような機能ブロックの一部または全部は、特定の機能を実行する様々な数のハードウェア及び／またはソフトウェア構成で具現されることができる。例えば、本開示の機能ブロックは、１つ以上のマイクロプロセッサによって具現されるか、所定の機能のための回路構成によって具現されることができる。さらに、例えば、本開示の機能ブロックは、様々なプログラミングまたはスクリプト言語で具現されることができる。機能ブロックは、１つ以上のプロセッサで実行されるアルゴリズムで具現されることができる。さらに、本開示は、電子的な環境設定、信号処理及び／またはデータ処理などのために従来技術を採用することができる。「メカニズム」、「要素」、「手段」及び「構成」などの用語は広く使用されることができ、機械的及び物理的構成に限定されない。

【0015】

さらに、図面に示された構成要素間の連結線または連結部材は、機能的連結及び／または物理的または回路的連結を例示的に示したものにすぎない。実際の装置では、代替可能または追加された様々な機能的連結、物理的連結、または回路連結によって構成要素間の連結が示されることができる。

【0016】

以下において、「車両」とは、自動車、バス、オートバイ、キックボードまたはトラックなどのように機関を有して人または物を移動させるために用いられるあらゆる種類の輸送手段を意味することができる。

【0017】

以下、添付の図面を参照して本開示を詳細に説明する。

【0018】

図１～図３は、一実施形態に係る車両用オンデマンドサービスの認証を行う装置またはシステムを説明するための図である。以下では、図１～図３を一緒に参照して説明する。

【0019】

図１を参照すると、車両用オンデマンドサービスの認証を行う環境として、車両１０、ネットワーク２０及び外部装置３０が存在する。一実施形態に係る車両１０は、自動運転装置が取り付けられた自動運転車両であることができる。さらに、車両１０は、内部にオンデマンドサービスを提供するための統合通信制御器（Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）及びサービスを駆動するための実行制御器、そして車両内装置間の通信を担当するＣＡＮまたはＥｔｈｅｒｎｅｔネットワーク装置を含むことができる。これについては、図２及び図３の説明で追加説明する。

【0020】

また、ネットワーク２０は、車両１０の内部及び外部装置３０を連結させるネットワークであり、通信方式は限定されず、ネットワーク２０が含むことができる通信網（一例として、移動通信網、有線インターネット、無線インターネット、放送網）を利用する通信方式だけでなく、ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）などのセキュリティネットワーク、ＵＤＳ（Ｕｎｉｆｉｅｄ Ｄｉａｇｎｏｓｔｉｃ Ｓｅｒｖｉｃｅ）などの診断ネットワークのうち１つ以上を含むことができるが、これに限定されない。

【0021】

また、外部装置３０は、各種サーバまたは診断装置などのオンデマンドサービスを提供するために車両１０に連結されなければならない外部装置であることができる。特に、外部装置３０は、車両１０とネットワーク２０を介して通信し、命令、コード、ファイル、コンテンツ、サービスなどを提供するコンピュータ装置または複数のコンピュータ装置で具現されることができる。

【0022】

図２を参照すると、車両用オンデマンドサービスの認証を行うためのシステム１００が示されている。以下の明細書において、説明の便宜上、車両用オンデマンドサービスの認証を行うためのシステム１００はサービス認証システム１００と称することができる。図３は、サービス認証システム１００をより具体化した図である。

【0023】

一方、一実施形態によれば、車両用オンデマンドサービスは、消費者の必要に応じてソフトウェア機能を選択的に購入することができる機能であり、車両に搭載され、消費者が望む時に所望の車両機能をカスタマイズできるようにする機能である。車両用オンデマンドサービスが搭載された車両をＳＤＶ（Ｓｏｆｔｗａｒｅ Ｄｅｆｉｎｅｄ Ｖｅｈｉｃｌｅ）車両ともいう。一実施形態によれば、ＳＤＶ車両を購入した消費者は、車両用オンデマンドサービスを利用して所望の機能を設定された期間（永久的または特定期間）だけ追加購入して当該機能を活性化させることができる。

【0024】

さらに、一実施形態に係る車両用オンデマンドサービスは、統合通信制御器のセキュリティ領域においてＰＫＩ（Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）に基づいて実行されるため、ハッキングに対して安全にサービスを提供することができ、これを本発明のサービス認証システム１００が具現することができる。

【0025】

さらに、一実施形態に係るサービス認証システム１００によれば、ユーザが購入したオンデマンド商品に対し、一括払いでの永久使用及び特定期間のサブスクリプションを目的に統合通信制御器内のセキュリティが適用されることができる。これにより、サービス認証システム１００がハッキングされるとしても、他のＳＤＶには伝播されず、当該ＳＤＶに限って侵害が発生する構造として作用されることができる。

【0026】

引き続き、図２及び図３を参照すると、サービス認証システム１００は、ＤＭ（Ｄａｔａｂａｓｅ Ｍａｎａｇｅｍｅｎｔ）サーバ１１０、統合通信制御器１２０、実行制御器１３０、ＴＩＦ設備１５０及び購入サーバ１４０を含むことができる。

【0027】

まず、ＤＭサーバ１１０は、後述する購入サーバ１４０と統合通信制御器１２０内のサービスエージェント１２１とｍＴＬＳ（ｍｕｔｕａｌ ＴＬＳ）で連結され、車両内のオンデマンドサービス駆動のための装置情報をデータベースで管理するサーバであることができる。

【0028】

より詳細には、ＤＭサーバ１１０は、ＭＱＴＴ（Ｍｅｓｓａｇｅ Ｑｕｅｕｅｉｎｇ Ｔｅｌｅｍｅｔｒｙ Ｔｒａｎｓｐｏｒｔ）マネージャ１１１を含む。ＭＱＴＴマネージャ１１１は、購入サーバ１４０及び統合通信制御器１２０のサービスエージェント１２１とｍＴＬＳで連結され、オンデマンド装置ごとの設定情報（または、サービスオプション値）を統合通信制御器１２０のサービスエージェント１２１に送信することができる。

【0029】

また、図には示されていないが、ＤＭサーバ１１０は、記憶された値としてルート証明書（ｒｏｏｔ ｃｅｒｔｉｆｉｃａｔｅｓ）、サーバ証明書（Ｓｅｒｖｅｒ ｃｅｒｔｉｆｉｃａｔｅｓ）及びサーバ秘密鍵（Ｓｅｒｖｅｒ Ｐｒｉｖａｔｅ ｋｅｙ）を有することができる。より詳細には、ルート証明書は、公開鍵基盤の構造において最上位認証機関であるルート認証機関によって発行される公認認証書であり、ＴＩＦ設備１５０から注入されることができる。さらに、サーバ証明書は、ルート認証機関から生成されたルート秘密鍵で署名された中間証明書（ｉｎｔｅｒｍｅｄｉａｔｅ ｃｅｒｔｉｆｉｃａｔｅ）である。また、サーバ秘密鍵は、ＤＭサーバ１１０で生成された秘密鍵であり、前述したサーバ証明書を生成するために使用することができる。

【0030】

さらに、ＤＭサーバ１１０のＭＱＴＴマネージャ１１１は、統合通信制御器１２０及び購入サーバ１４０と通信する際に、ｍＴＬＳ（ｍｕｔｕａｌ Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）を暗号化プロトコルとして使用することができる。一実施形態によれば、ｍＴＬＳは、ＭＱＴＴマネージャ１１１及びサービスエージェント１２１が正しい秘密鍵を有していることを確認し、正当な通信当事者であるかを確認する。より詳細には、ｍＴＬＳは、統合通信制御器１２０のサービスエージェント１２１とＤＭサーバ１１０のＭＱＴＴマネージャ１１１との間のすべての情報を証明するために互いの証明書を交換した後、各通信当事者を確認及び信頼する場合のみ通信を連結させることができる。

【0031】

次に、統合通信制御器１２０は、車両内外部の連携機能及びデータ伝達のための制御装置である。より詳細には、統合通信制御器１２０は、図３に示すように、サービスエージェント１２１及びサービス認証サーバ１２２を含むことができる。サービスエージェント１２１は、統合通信制御器１２０の一般領域（Ｎｏｒｍａｌ Ｗｏｒｌｄ）で動作し、サービス認証サーバ１２２から伝達されたサービストークン、デバイス証明書及びデバイス秘密鍵を各実行制御器１３０に伝達する。

【0032】

次に、サービス認証サーバ１２２は、統合通信制御器１２０のセキュリティ領域（Ｓｅｃｕｒｅ Ｗｏｒｌｄ）で動作し、サービストークン、デバイス証明書及びデバイス秘密鍵を生成してサービスエージェント１２１に伝達する。

【0033】

また、統合通信制御器１２０は、ルート証明書（Ｒｏｏｔ ｃｅｒｔｉｆｉｃａｔｅ）、クライアント秘密鍵（Ｃｌｉｅｎｔ Ｐｒｉｖａｔｅ Ｋｅｙ）、クライアント証明書（Ｃｌｉｅｎｔ ｃｅｒｔｉｆｉｃａｔｅ）、プライベートルート秘密鍵（Ｐｒｉｖａｔｅ Ｒｏｏｔ 秘密 ｋｅｙ）、プライベートルート証明書（Ｐｒｉｖａｔｅ Ｒｏｏｔ ｃｅｒｔｉｆｉｃａｔｅ）、デバイス証明書、デバイス秘密鍵のうち１つ以上を取得または生成することができる。

【0034】

より詳細には、ルート証明書は、上述したように公開鍵基盤の構造において最上位認証機関であるルート認証機関によって発行される公認認証書であり、ＤＭサーバ１１０またはＴＩＦ設備１５０から取得されることができる。

【0035】

クライアント秘密鍵は、ＤＭサーバ１１０によって生成された鍵であり、クライアント証明書を生成するために使用され、ＴＩＦ設備１５０から取得されることができる。また、クライアント証明書は、ＤＭサーバ１１０によって生成された中間証明書（ｉｎｔｅｒｍｅｄｉａｔｅ ｃｅｒｔｉｆｉｃａｔｅ）であり、ルート秘密鍵で署名されて使用され、ＴＩＦ設備１５０から取得されることができる。

【0036】

また、プライベートルート秘密鍵は、サービス認証サーバ１２２によって発行された鍵であり、プライベートルート証明書を生成するために使用することができる。また、プライベートルート証明書は、サービス認証サーバ１２２によって発行された私設ルート機関（Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ、ＣＡ）証明書である。

【0037】

次に、実行制御器１３０は、ユーザが購入した車両用オンデマンドサービスを駆動するための車両内装置である。以下の明細書において、実行制御器１３０は、車両内の実行制御器である第１～第Ｎの実行制御器を通称する意味で使用されることができる。

【0038】

実行制御器１３０はサービスマネージャ１３１を含むことができ、セキュリティストレージ（ｓｅｃｕｒｅ ｓｔｏｒａｇｅ）にサービストークン（Ｔｏｋｅｎ）、デバイス証明書（Ｄｅｖｉｃｅ ｃｅｒｔｉｆｉｃａｔｅ）及びデバイス秘密鍵（Ｄｅｖｉｃｅ Ｐｒｉｖａｔｅ Ｋｅｙ）を含むことができる。

【0039】

まず、サービスマネージャ１３１は、統合通信制御器１２０のサービスエージェント１２１からサービストークン、統合通信制御器１２０の証明書、デバイス秘密鍵を伝達される。また、サービストークンは、統合通信制御器１２０のサービス認証サーバ１２２によって発行されたトークンであり、サービス設定データは暗号化されてペイロード（ＰａｙＬｏａｄ）に記憶され、プライベートルート秘密鍵で署名されることができる。また、プライベートルート証明書は、サービス認証サーバ１２２によって発行された統合通信制御器１２０の証明書であり、サービストークンのデジタル署名確認に使用されることができる。また、デバイス秘密鍵は、統合通信制御器１２０のサービス認証サーバ１２２によって各実行制御器１３０ごとに発行された秘密鍵であり、サービストークン内のサービス設定データの復号化に使用されることができる。

【0040】

また、ＴＩＦ設備１５０は、工程で生産された車両に一度だけ連結され、ＤＭサーバ１１０から発行されたルート証明書、クライアント証明書、クライアント秘密鍵を統合通信制御器１２０のセキュリティ領域（Ｓｅｃｕｒｅ Ｗｏｒｌｄ）のセキュリティストレージ（Ｓｅｃｕｒｅ Ｓｔｏｒａｇｅ）に注入する設備である。

【0041】

一実施形態によれば、セキュリティ資産（Ｓｅｃｕｒｉｔｙ Ａｓｓｅｔ）は、保護すべき分析対象のデータ、機能及び資源を意味し、システムモデル及び使用ケース（Ｕｓｅ Ｃａｓｅ）で複数のセキュリティ資産を識別することができる。また、セキュリティ属性（Ｓｅｃｕｒｉｔｙ Ｏｂｊｅｃｔｉｖｅｓ）は、完全性（Ｉｎｔｅｇｒｉｔｙ）、機密性（Ｃｏｎｆｉｄｅｎｔｉａｌｉｔｙ）、確実性（Ａｕｔｈｅｎｔｉｃｉｔｙ）、可用性（Ａｖａｉｌａｂｉｌｉｔｙ）、最新性（Ｆｒｅｓｈｎｅｓｓ）に分けられ、各資産に存在できるセキュリティ属性を識別することができる。

【0042】

一実施形態によれば、セキュリティ資産である統合通信制御器１２０の識別データ（Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｄａｔａ）は、統合通信制御器１２０に記憶された車両用オンデマンドサービスオプション情報であり、完全性セキュリティ属性を有することができる。また、セキュリティ資産である統合通信制御器１２０のファームウェアは、統合通信制御器１２０で動作するコンパイルされたファームウェアコードであり、機密性及び完全性セキュリティ属性を有することができる。また、セキュリティ資産であるバックエンド通信（Ｃｏｍｍｕｎｉｃａｔｉｏｎ ｗｉｔｈ ｂａｃｋｅｎｄ）は、サービス購入及びＤＭサーバ１１０との通信のために送受信されるデータであり、機密性、確実性、最新性及び可用性セキュリティ属性を有することができる。また、セキュリティ資産である暗号化情報（Ｃｒｙｐｔｏｇｒａｐｈｉｃ ｍａｔｅｒｉａｌｓ）は、統合通信制御器１２０においてサービストークン発行の暗号復号化に使用される鍵または証明書の情報であり、機密性及び完全性のセキュリティ属性を有することができる。

【0043】

本発明の一実施形態に係るオンデマンドサービス認証サービスは、１つ以上のセキュリティ要件を有することができ、各セキュリティ要件は１つ以上のセキュリティ脅威に対応することができる。一実施形態に係る第１～第５セキュリティ要件に対応するセキュリティ脅威は、以下の「表１」の通りである。

【表1】

【0044】

より詳細には、第１セキュリティ要件（ＳＲＶ０１）は、統合通信制御器１２０のファームウェアの奪取及び改ざん、メモリダンプなどを介して購入されていないサービスオプション値は活性化されてはならないということである。第２セキュリティ要件（ＳＲＶ０２）は、統合通信制御器１２０に記憶されたサービスオプション情報は変造されないように完全性を確保しなければならないということである。第３セキュリティ要件（ＳＲＶ０３）は、ＤＭサーバ１１０間の通信時に中間者攻撃（Ｍａｎ ｉｎ ｔｈｅ ｍｉｄｄｌｅ ａｔｔａｃｋ）またはセッションハイジャッキング（ｓｅｓｓｉｏｎ ｈｉｊａｃｋｉｎｇ）攻撃に対して安全でなければならないということである。第４セキュリティ要件（ＳＲＶ０４）は、ＤＭサーバ１１０から伝達されるサービスオプション値は改ざんされてはならないということである。第５セキュリティ要件（ＳＲＶ０５）は、事前に許可されていない個体（ＯＴＡ診断器）で実行制御器１３０にアクセスできないようにしなければならないということである。一方、以下の明細書では、説明の便宜上、第１～第５セキュリティ要件は各セキュリティ要件のＩＤで称されることができる。

【0045】

一方、一実施形態によれば、サービス認証システムのユースケース（Ｕｓｅ Ｃａｓｅ）は、３つが存在することができる。第１ユースケース（ＵＣ０１）は、車両出荷前の先行購入オプションとして車両用オンデマンドサービスを購入した場合であり、工場ＴＩＦラインで診断器を介して車両のサービス設定情報を設定することができる。また、第２ユースケース（ＵＣ０２）は、車両出荷後に顧客が車両用オンデマンドサービスを購入した場合であり、車両出荷後に顧客がサービスを購入すると、ＤＭサーバ１１０を介して車両のサービス設定情報を設定することができる。また、第３ユースケース（ＵＣ０３）は、車両出荷後、車両起動時にオンデマンドサービスが活性化または非活性化される場合であり、最新のサービス設定情報に従って各実行制御器１３０が活性化または非活性化されることができる。

【0046】

引き続き、第１ユースケース（ＵＣ０１）の動作手順についてより詳細に説明する。まず、ＴＩＦ設備１５０は、統合通信制御器１２０のサービスエージェント１２１を介してＤＭサーバ１１０にｍＴＬＳ連結をするためのルート証明書、クライアント証明書及びクライアント秘密鍵をセキュリティ領域に注入する。

【0047】

図４は、一実施形態に係る第１ユースケース（ＵＣ０１）の動作をフローチャートで示したものである。

【0048】

図４は、統合通信制御器１２０が動作の主体であることを仮定して記述されたフローチャートであるが、本発明の変形実施形態によって各動作の主体はＴＩＦ設備１５０、統合通信制御器１２０のサービスエージェント１２１及びサービス認証サーバ１２２、そして実行制御器１３０のサービスマネージャ１３１になることができる。

【0049】

より詳細には、ＤＭサーバ１１０へのｍＴＬＳ連結のためのルート証明書、クライアント証明書、クライアント秘密鍵をＴＩＦ設備１５０から取得し、セキュリティストレージ（Ｓｅｃｕｒｅ Ｓｔｏｒａｇｅ）に記憶させる（４０１）。このとき、ステップ４０１のセキュリティ要件ＩＤはＳＲＶ０５である。

【0050】

次に、統合通信制御器１２０のサービスエージェント１２１が、ＴＩＦ設備１５０から車両及び販売システムでのサービス先行購入オプション値（サービスオプション値）を取得する（４０２）。このとき、ステップ４０２のセキュリティ要件ＩＤは、ＳＲＶ０２、ＳＲＶ０３及びＳＲＶ０５である。また、サービス先行購入オプション値を第１オプション値と称することができる。

【0051】

一方、ステップ４０３と共に、ＤＭサーバ１１０もＴＩＦ設備１５０から車両及び販売システムにおいてサービス先行購入オプション値を取得し、データベースに記憶させることができる。このとき、セキュリティ要件ＩＤはＳＲＶ０３である。

【0052】

次に、統合通信制御器１２０のサービスエージェント１２１は、ＴＩＦ設備１５０から伝達された当該車両のサービス先行購入オプション値をセキュリティ領域（Ｓｅｃｕｒｅ Ｗｏｒｌｄ）内のセキュリティストレージに記憶させる（４０３）。付け加えると、サービス認証サーバ１２２は、車両用サービスに関するサービス先行購入オプション値、すなわち、第１オプション値を取得及び記憶することができる。このとき、セキュリティ要件ＩＤは、ＳＲＶ０１、ＳＲＶ０４、ＳＲＶ０５である。

【0053】

次に、サービス認証サーバ１２２は、セキュリティ領域において統合通信制御器１２０のプライベートルート秘密鍵（ｐｒｉｖａｔｅ ｒｏｏｔ 秘密 ｋｅｙ、ｒｏｏｔ ｋｅｙ）及びプライベートルート証明書を取得または生成することができる（４０４）。プライベートルート秘密鍵は、サービストークンを発行するための秘密鍵であることができる。

【0054】

次に、サービス認証サーバ１２２は、セキュリティ領域において実行制御器１３０ごとにプライベートルート秘密鍵で署名されたデバイス証明書（Ｄｅｖｉｃｅ ｃｅｒｔｉｆｉｃａｔｅ）とデバイス秘密鍵（ｄｅｖｉｃｅ ｋｅｙ）を生成する（４０５）。

【0055】

次に、サービス認証サーバ１２２は、プライベートルート証明書、プライベートルート秘密鍵を使用してサービス先行購入オプション値に対するサービストークンを発行する（４０６）。さらに、サービス認証サーバ１２２は、セキュリティ領域において実行制御器１３０ごとに生成されたサービストークン、プライベートルート証明書及びデバイス秘密鍵をサービスエージェント１２１に送信する。

【0056】

次に、サービスエージェント１２１は、セキュリティ領域から伝達されたサービストークン、プライベートルート証明書及びデバイス秘密鍵を各実行制御器１３０に伝達する（４０７）。このとき、各実行制御器１３０は、サービスエージェント１２１から伝達されたサービストークン、デバイス証明書及びデバイス秘密鍵を各実行制御器１３０内のセキュリティストレージに記憶させることができる。

【0057】

一方、上述したステップ４０４～４０８のセキュリティ要件ＩＤは、ＳＲＶ０１、ＳＲＶ０２、ＳＲＶ０５である。

【0058】

図５及び図６は、一実施形態に係る、上述した第１ユースケースの第１実施形態及び第２実施形態をそれぞれ示したものである。

【0059】

より詳細には、図５及び図６は、第１ユースケース（ＵＣ０１）の各動作を実行する動作主体が異なる第１実施形態（ＵＣ０１－１）及び第２実施形態（ＵＣ０１－２）をそれぞれ示したものである。以下の図５及び図６の実施形態は、第１ユースケース（ＵＣ０１）の動作がＴＩＦ設備１５０、統合通信制御器１２０のサービスエージェント１２１及びサービス認証サーバ１２２、そして実行制御器１３０のサービスマネージャ１３１によって実行されることを示すことができる。

【0060】

まず、図５は、車両出荷前の先行購入オプションとして車両用オンデマンドサービスが購入された第１ユースケース（ＵＣ０１）において、統合通信制御器１２０のサービスエージェント１２１よりサービス認証サーバ１２２が主な役割を果たす第１実施形態（ＵＣ０１－１）の動作をブロック図で示している。

【0061】

図５を参照すると、まず、ＴＩＦ設備１５０が統合通信制御器１２０のサービスエージェント１２１に第１オプション値（サービスデータとしてサービス先行購入オプション値）を注入する（５０１）。

【0062】

次に、サービスエージェント１２１は、伝達された第１オプション値をデータベースに記憶させ、セキュリティ領域内のサービス認証サーバ１２２に伝達する（５０２）。

【0063】

次に、サービスエージェント１２１は、プライベートルート鍵生成をサービス認証サーバ１２２に要求する（５０３）。一実施形態において、プライベートルート鍵（Ｐｒｉｖａｔｅ Ｒｏｏｔ Ｋｅｙ）は、プライベートルート秘密鍵（Ｐｒｉｖａｔｅ Ｒｏｏｔ 秘密 ｋｅｙ）及びプライベートルート証明書（Ｐｒｉｖａｔｅ Ｒｏｏｔ Ｃｅｒｔｉｆｉｃａｔｅ、Ｐｒｉｖａｔｅ Ｒｏｏｔ 公開鍵とも称されることができる）から構成されることができる。さらに、プライベートルート鍵は非対称鍵を使用し、統合通信制御器１２０が記憶し、１対だけ生成される特徴を有することができる。

【0064】

次に、サービス認証サーバ１２２は、プライベートルート秘密鍵を生成し（５０４）、プライベートルート証明書を生成する（５０５）。

【0065】

次に、サービス認証サーバ１２２は、連結されているデバイスの数だけデバイス鍵（ｄｅｖｉｃｅ ｋｅｙ）を生成する。一実施形態によれば、デバイス鍵は、デバイス秘密鍵（Ｄｅｖｉｃｅ Ｐｒｉｖａｔｅ Ｋｅｙ）及びデバイス証明書（Ｄｅｖｉｃｅ Ｃｅｒｔｉｆｉｃａｔｅ、デバイス公開鍵とも称されることができる）から構成されることができる。さらに、デバイス鍵は、非対称鍵が使用され、いくつかのペアが生成され、実行制御器ごとに一対だけを保持する特徴を有することができる。すなわち、サービス認証サーバ１２２は、実行制御器１３０ごとにデバイス秘密鍵を生成し（５０６）、プライベートルート秘密鍵で署名されたデバイス証明書を生成する（５０７）。

【0066】

次に、サービス認証サーバ１２２は、プライベートルート証明書をサービスエージェント１２１に伝達する（５０８）。

【0067】

次に、サービスエージェント１２１は、サービス認証サーバ１２２にデバイス情報を要求し（５０９）、それに対応してサービス認証サーバ１２２はサービストークンを生成する（５１０）。

【0068】

次に、サービス認証サーバ１２２は、生成されたサービストークン及びデバイス秘密鍵をサービスエージェント１２１に送信する（５１１）。

【0069】

次に、サービスエージェント１２１は、実行制御器１３０ごとに成されたサービスマネージャ１３１にサービストークン、プライベートルート証明書、デバイス秘密鍵を各実行制御器１３０に送信する（５１２）。

【0070】

次に、各実行制御器１３０のサービスマネージャ１３１は、プライベートルート証明書及びデバイス秘密鍵を各実行制御器１３０内のセキュリティストレージに記憶させる（５１３、５１４）。また、サービスマネージャ１３１はサービストークンを検証する（５１５）。

【0071】

引き続き、図６は、車両出荷前の先行購入オプションとして車両オンデマンドサービスが購入された第１ユースケース（ＵＣ０１）において、統合通信制御器１２０のサービスエージェント１２１がサービス認証サーバ１２２より主な役割を果たす第２実施形態（ＵＣ０１－２）の動作をブロック図で示している。第１ユースケースの第２実施形態（ＵＣ０１－２）は、第１実施形態（ＵＣ０１－１）の変形形態であるため、重複または対応する構成については説明を省略する。

【0072】

図６を参照すると、まず、ＴＩＦ設備１５０が統合通信制御器１２０のサービスエージェント１２１に第１オプション値（サービス先行購入オプション値）を注入する（６０１）。

【0073】

次に、サービスエージェント１２１は、伝達された第１オプション値をデータベースに記憶させ、セキュリティ領域内のサービス認証サーバ１２２に伝達する（６０２）。

【0074】

次に、サービスエージェント１２１は、プライベートルート鍵生成をサービス認証サーバ１２２に要求する（６０３）。

【0075】

次に、サービス認証サーバ１２２は、プライベートルート秘密鍵を生成し（６０４）、プライベートルート証明書を生成する（６０５）。

【0076】

次に、サービス認証サーバ１２２は、生成されたプライベートルート証明書をサービスエージェント１２１に伝達する（６０６）。

【0077】

次に、実行制御器の数だけサービス認証サーバ１２２は、デバイス鍵（ｄｅｖｉｃｅ ｋｅｙ）生成要求をサービスエージェント１２１から受信する（６０７）。また、デバイス鍵生成要求を受信したサービス認証サーバ１２２は、実行制御器１３０ごとにデバイス秘密鍵を生成し（６０８）、プライベートルート秘密鍵で署名されたデバイス証明書を生成する（６０９）。

【0078】

次に、サービスエージェント１２１はサービストークンを生成する（６１０）。

【0079】

次に、サービス認証サーバ１２２は、生成されたデバイス秘密鍵をサービスエージェント１２１に送信する（６１１）。

【0080】

次に、サービスエージェント１２１は、実行制御器１３０ごとに成されたサービスマネージャ１３１にサービストークン、プライベートルート証明書、デバイス秘密鍵を各実行制御器１３０に送信する（６１２）。

【0081】

次に、各実行制御器１３０のサービスマネージャ１３１は、プライベートルート証明書及びデバイス秘密鍵を各実行制御器１３０内のセキュリティストレージに記憶させる（６１３、６１４）。また、サービスマネージャ１３１はサービストークンを検証する（６１５）。

【0082】

図７は、一実施形態に係る第２ユースケースの動作をブロック図で示したものである。

【0083】

すなわち、図７は、一実施形態に係る第２ユースケース（ＵＣ０２）として出荷後の購入情報が更新される場合を示すフローチャートである。

【0084】

まず、ＤＭサーバ１１０は、購入サーバ１４０から取得した出荷後サービス購入オプション値をデータベースに記憶させる。以下の明細書において、出荷後サービス購入オプション値は第２オプション値と称されることもできる。このとき、セキュリティ要件ＩＤはＳＲＶ０２である。

【0085】

次に、図７を参照すると、サービスエージェント１２１は、ＤＭサーバ１１０と統合通信制御器１２０内のサービスエージェント１２１との間の相互認証を介して暗号化セキュリティ通信（ｍＴＬＳ）を連結させる（７０１）。

【0086】

次に、サービスエージェント１２１は、ｍＴＬＳ通信を用いてＤＭサーバ１１０から出荷後サービス購入オプション値を取得する（７０２）。このとき、ステップ７０１及び７０２のセキュリティ要件ＩＤはＳＲＶ０３、ＳＲＶ０４である。

【0087】

次に、サービスエージェント１２１は、出荷後サービス購入オプション値をセキュリティ領域内のサービス認証サーバ１２２に伝達する（７０３）。この場合、サービスエージェント１２１とサービス認証サーバ１２２との間に適用されたセキュリティ要件は存在しないことができる。

【0088】

次に、サービス認証サーバ１２２はサービストークンを生成する（７０４）。また、サービス認証サーバ１２２は、生成されたサービストークンをサービスエージェント１２１に伝達し、サービスエージェント１２１は、伝達されたサービストークンを各実行制御器１３０に伝達する（７０５）。このとき、セキュリティ要件ＩＤは、ＳＲＶ０２、ＳＲＶ０５である。

【0089】

次に、実行制御器１３０は、統合通信制御器１２０から伝達されたサービストークンを各実行制御器１３０内のセキュリティストレージに記憶させる。このとき、セキュリティ要件ＩＤは、ＳＲＶ０１、ＳＲＶ０２、ＳＲＶ０３、ＳＲＶ０４、ＳＲＶ０５である。

【0090】

図８は、一実施形態に係る第２ユースケースの動作を動作主体別に示すフローチャートである。

【0091】

図８を参照すると、図５及び図６とは異なり、第２ユースケース（ＵＣ０２）は、動作主体としてＴＩＦ設備１５０の代わりにＤＭサーバ１１０を含む。上述したように、第１ユースケース（ＵＣ０１）は、車両出荷前に工場のＴＩＦラインに連結されて車両のサービスオプション値を設定するが、第２ユースケース（ＵＣ０２）は、車両出荷後にユーザがオンデマンドサービス商品を購入すると、ＤＭサーバ１１０を介して車両のサービスオプション値を設定するためである。

【0092】

より詳細には、図８を参照すると、まず、ＤＭサーバ１１０は、購入サーバ１４０で取得した出荷後サービス購入オプション値（サービスデータ）をデータベースに記憶させた後（８０１）、サービスデータをサービスエージェント１２１に送信する（８０２）。

【0093】

次に、サービスエージェント１２１は、取得したサービスデータをサービス認証サーバ１２２に送信する（８０３）。

【0094】

次に、サービス認証サーバ１２２は、サービスデータ及び署名を含む署名検証要求を受信し（８０４）、サービスデータ、署名及びサーバ証明書を含む署名検証手続きを実行する（８０５）。

【0095】

次に、サービス認証サーバ１２２は、デバイスＩＤ及びオンデマンドサービスデータを含むオンデマンドサービスデータの記憶要求を受信し（８０６）、オンデマンドサービスデータ及びクライアント秘密鍵を含むオンデマンドサービスデータの復号化手続きを実行する（８０７）。

【0096】

次に、サービスエージェント１２１はサービストークンを生成する（８０８）。

【0097】

次に、サービスエージェント１２１は、生成されたサービストークンを実行制御器１３０のサービスマネージャ１３１に送信し（８０９）、サービストークンを受信した実行制御器１３０はサービストークンを検証する（８１０）。

【0098】

引き続き、第３ユースケース（ＵＣ０３）は、上述したように車両出荷後、車両起動時にオンデマンドサービスが活性化または非活性化される場合である。第３ユースケース（ＵＣ０３）では、最新のオンデマンドサービス設定情報に従って、各実行制御器１３０のオンデマンドサービス機能を活性化または非活性化されることができる。

【0099】

より詳細には、第３ユースケース（ＵＣ０３）では、まず、各実行制御器１３０のセキュリティストレージに記憶されたプライベートルート証明書でサービストークンのデジタル署名チェックをすることでサービストークンの改ざん有無を確認する。次に、各実行制御器１３０内のセキュリティストレージに記憶されたデバイス秘密鍵でサービストークンのヘッダに記憶されたＡＥＳ鍵を復号化し、サービストークンの暗号化されたペイロード（ＰａｙＬｏａｄ）データを取得したＡＥＳ鍵で復号化して各実行制御器１３０のオン／オフを決定することができる。このとき、セキュリティ要件ＩＤは、ＳＲＶ０１、ＳＲＶ０２、ＳＲＶ０３、ＳＲＶ０４、ＳＲＶ０５である。

【0100】

上述したように、一実施形態によれば、サービス認証システムでは認証のためにサービストークンを生成し、サービスデータ（サービスオプション値）は暗号化されてサービストークンのペイロード（ＰａｙＬｏａｄ）に記憶される。さらに、サービストークンはプライベートルート鍵でデジタル署名されることができる。以下では、サービストークン構造及び生成方法、検証（認証）方法についてより詳細に説明する。

【0101】

サービストークン構造は、ヘッダ（Ｈｅａｄｅｒ）、ペイロード（ＰａｙＬｏａｄ）及びトレーラ（Ｔｒａｉｌｅｒ）の３つのフィールドで構成されている。まず、サービストークンのヘッダは、ＡＥＳ鍵、ペイロード長、ＡＥＳ鍵暗号化アルゴリズム（例えば、ＡＥＳ－２５６ ＣＢＣ）、ペイロード暗号化アルゴリズム（例えば、ＲＳＡＥＳ－ＯＡＥＰ ２０４８）及び署名（Ｓｉｇｎａｔｕｒｅ）生成アルゴリズム（例えば、ＲＳＡＳＳＡ－ＰＳＳ ２０４８）の情報を保持することができる。この場合、ＡＥＳ鍵はデバイス証明書で暗号化され、デバイス秘密鍵で復号化されることができる。

【0102】

さらに、サービストークンのペイロードは、サービスデータの情報を保持することができ、そのときサービスデータは、ＡＥＳ鍵で暗号化及び復号化されることができる。さらに、サービストークンのトレーラは、ヘッダとペイロードに対する署名の情報を含むことができ、このとき署名はプライベートルート秘密鍵で生成され、プライベートルート証明書で認証されることができる。

【0103】

図９は、一実施形態に係るサービストークンを生成する方法を示すフローチャートである。

【0104】

一実施形態によれば、サービストークン生成は統合通信制御器１２０で実行されることができる。一実施形態によって、第１ユースケースの第１実施形態（ＵＣ０１－１）では、サービス認証サーバ１２２によってサービストークンが生成されることができ、第１ユースケースの第２実施形態（ＵＣ０１－２）では、サービスエージェント１２１によってサービストークンが生成されることができる。

【0105】

以下では、第１ユースケースの第１実施形態（ＵＣ０１－１）に従ってサービス認証サーバ１２２でサービストークンが生成される例を中心に説明する。

【0106】

まず、セキュリティ領域でＡＥＳ対称鍵を生成し、記憶されたサービス先行購入オプション（サービスデータ）をＡＥＳ暗号化してサービストークン内のペイロードフィールドに記憶させる（９０１）。一実施形態によれば、ＡＥＳ鍵は、対称鍵であり、サービストークンを生成するたびにランダムに生成されることができる。

【0107】

次に、セキュリティ領域においてデバイス証明書で以前に生成されたＡＥＳ対称鍵を公開鍵アルゴリズム（一実施形態によればＲＳＡ）で暗号化してサービストークンヘッダに追加する（９０２）。

【0108】

次に、セキュリティ領域においてプライベートルート秘密鍵でサービストークンにデジタル署名（ｓｉｇｎｉｎｇ）する（９０３）。

【0109】

図１０Ａ及び図１０Ｂは、サービストークンの生成及び検証をそれぞれ説明するための図である。

【0110】

まず、図１０Ａは、サービストークン生成過程のステップ及び各ステップでどのデータが使用または生成されたかを説明するための図である。

【0111】

まず、サービスデータが生成される（１０ａ－１）。

【0112】

次に、サービスデータが暗号化される（１０ａ－２）。このとき、ステップ１０ａ－１で生成されたサービスデータを対称鍵アルゴリズム（一実施形態によれば、ＡＥＳ鍵）を用いて暗号化し、暗号化されたサービスデータが生成される。

【0113】

次に、ＡＥＳ鍵を暗号化する（１０ａ－３）。このとき、デバイス証明書（デバイス公開鍵）でＡＥＳ鍵を暗号化し、暗号化されたＡＥＳ鍵が生成される。

【0114】

次に、署名（Ｓｉｇｎａｔｕｒｅ）を生成する（１０ａ－４）。このとき、ステップ１０ａ－３で生成された、暗号化されたＡＥＳ鍵及びステップ１０ａ－２で生成された、暗号化されたサービスデータにプライベートルート秘密鍵を用いて署名を生成することができる。

【0115】

次に、サービストークンを生成する（１０ａ－５）。このとき、サービストークンはヘッダ、ペイロード、トレーラのフィールドを有することができる。ヘッダフィールドは暗号化されたＡＥＳ鍵情報を含むことができ、ペイロードフィールドは暗号化されたサービスデータを含むことができ、トレーラフィールドは署名情報を含むことができる。

【0116】

引き続き、図１０Ｂは、サービストークンの検証（認証）過程のステップ及び各ステップでどのデータが使用または生成されたかを説明するためのものである。

【0117】

まず、サービストークンを取得する（１０ｂ－１）。図１０Ａの説明で上述したように、取得されたサービストークンのヘッダフィールドは暗号化されたＡＥＳ鍵情報を含むことができ、ペイロードフィールドは暗号化されたサービスデータを含むことができ、トレーラフィールドは署名情報を含むことができる。

【0118】

次に、署名を検証する（１０ｂ－２）。署名は、暗号化されたＡＥＳ鍵及び暗号化されたサービスデータにプライベートルート証明書（公開鍵）を用いて検証することができる。

【0119】

次に、ＡＥＳ鍵を復号化する（１０ｂ－３）。このとき、暗号化されたＡＥＳ鍵をデバイス秘密鍵で復号化し、復号化されたＡＥＳ鍵を生成することができる。

【0120】

次に、サービスデータを復号化する（１０ｂ－４）。このとき、暗号化されたサービスデータを復号化されたＡＥＳ鍵で復号化することができる。

【0121】

次に、復号化されたサービスデータを取得する（１０ｂ－５）。

【0122】

本発明に係る実施形態は、コンピュータ上で様々な構成要素を介して実行することができるコンピュータプログラムの形態で具現されることができ、そのようなコンピュータプログラムはコンピュータで読み取り可能な媒体に記録されることができる。このとき、媒体は、ハードディスク、フロッピーディスク及び磁気テープなどの磁気媒体、ＣＤ－ＲＯＭ及びＤＶＤなどの光記録媒体、フロプティカルディスク（ｆｌｏｐｔｉｃａｌ ｄｉｓｋ）などの光磁気記録媒体（ｍａｇｎｅｔｏ－ｏｐｔｉｃａｌ ｍｅｄｉｕｍ）、及びＲＯＭ、ＲＡＭ、フラッシュメモリなどのようなプログラム命令語を記憶及び実行するように特別に構成されたハードウェア装置を含むことができる。

【0123】

一方、前記コンピュータプログラムは、本発明のために特別に設計及び構成されているか、コンピュータソフトウェア分野の当業者に公知され使用可能なものであることができる。コンピュータプログラムの例には、コンパイラによって作成されるような機械語コードだけでなく、インタプリタなどを使用し、コンピュータによって実行されることができる高級言語コードも含まれることができる。

【0124】

一実施形態によれば、本開示の様々な実施形態に係る方法は、コンピュータプログラム製品（ｃｏｍｐｕｔｅｒ ｐｒｏｇｒａｍ ｐｒｏｄｕｃｔ）に含まれて提供されることができる。コンピュータプログラム製品は、商品として販売者及び購入者の間で取引されることができる。コンピュータプログラム製品は、デバイスで読み取り可能な記憶媒体（例えば、ｃｏｍｐａｃｔ ｄｉｓｃ ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ（ＣＤ－ＲＯＭ））の形態で配布されるか、またはアプリケーションストア（例えば、プレイストア（商標））を介して、または２つのユーザ装置間で直接、オンラインで配布（例えば、ダウンロードまたはアップロード）されることができる。オンライン配布の場合、コンピュータプログラム製品の少なくとも一部は、製造元のサーバ、アプリケーションストアのサーバ、または中継サーバのメモリなどの機器で読み取ることができる記憶媒体に少なくとも一時的に記憶されるか、一時的に生成されることができる。

【0125】

本発明に係る方法を構成するステップについて明らかに順序を記載したり反したりする記載がない場合、前記ステップは適当な順序で行われることができる。必ずしも前記ステップの記載順序に従って本発明が限定されるものではない。本発明において、すべての例または例示的な用語（例えば、等）の使用は、単に本発明を詳細に説明するためのものであり、特許請求の範囲によって限定されない限り、前記の例または例示的な用語によって本発明の範囲が限定されるものではない。さらに、当業者は、様々な修正、組み合わせ及び変更が追加された特許請求の範囲またはその均等物の範囲内で設計条件及び要因によって構成され得ることを理解するであろう。

【0126】

したがって、本発明の思想は、前記説明した実施形態に限定されて決められてはならず、後述する特許請求の範囲のみならず、この特許請求の範囲と均等またはこれから等価的に変更された全ての範囲は、本発明の思想の範疇に属するとするといえるだろう。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10A】

【図10B】