JP2013153284A - 暗号鍵管理システム - Google Patents

暗号鍵管理システム Download PDF

Info

Publication number
JP2013153284A
JP2013153284A JP2012012331A JP2012012331A JP2013153284A JP 2013153284 A JP2013153284 A JP 2013153284A JP 2012012331 A JP2012012331 A JP 2012012331A JP 2012012331 A JP2012012331 A JP 2012012331A JP 2013153284 A JP2013153284 A JP 2013153284A
Authority
JP
Japan
Prior art keywords
encryption key
session
server
client
service server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2012012331A
Other languages
English (en)
Inventor
Shinya Tachimori
伸也 日月
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Onkyo Corp
Original Assignee
Onkyo Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Onkyo Corp filed Critical Onkyo Corp
Priority to JP2012012331A priority Critical patent/JP2013153284A/ja
Publication of JP2013153284A publication Critical patent/JP2013153284A/ja
Pending legal-status Critical Current

Links

Images

Abstract

【課題】クライアントに対する暗号鍵の設定が容易な暗号鍵管理システムを提供することである。
【解決手段】ローカルサーバ1及びAV機器2が、LAN7に接続される。サービスサーバ5は、ローカルサーバ1及びAV機器2と通信可能である。ローカルサーバ1は、認証情報をサービスサーバ5に送信してローカルサーバ1とサービスサーバ5との間にセッション100を確立する。ローカルサーバ1は、暗号鍵16とローカルサーバ1のUUID15とを、セッション100を介してサービスサーバ5に送信する。AV機器2は、認証情報をサービスサーバ5に送信してAV機器2とサービスサーバ5との間にセッション200を確立する。サービスサーバ5は、ローカルサーバ1から送信された認証情報がAV機器2から送信された認証情報に一致する場合、UUID15及び暗号鍵16を、セッション200を介してAV機器2に配信する。
【選択図】図5

Description

本発明は、暗号鍵管理システムに関し、さらに詳しくは、サーバが使用する暗号鍵をクライアントに設定する暗号鍵管理システムに関する。
一般家庭では、楽曲を録音した音声データ、映像を録画した映像データなどのコンテンツデータを、ハードディスク装置(サーバ)に記録することが行われている。ユーザは、サーバに記録されたコンテンツデータを、ホームネットワークに接続されたテレビ、PC(Personal Computer)などのクライアントで視聴することができる。コンテンツデータは、DTCP−IP(Digital Transmission Content Protection over Internet Protocol)と呼ばれる規格に基づいて暗号化された上で、サーバからクライアントに転送される。
DTCP−IPは、著作権保護技術により保護されたコンテンツデータを、IP(Internet Protocol)ネットワーク上で転送するための規格である。DTCP−IPにおいて、共通鍵を用いてコンテンツデータを暗号化する場合、サーバ及びクライアントに共通鍵を予め設定しなければならない。共通鍵を変更する場合、ユーザは、新たな共通鍵を認証局から取得して、取得した共通鍵を設定する作業を、サーバ及びクライアントのそれぞれに対して行う。ユーザは、複数のクライアントを使用する場合、各クライアントに共通鍵を設定する操作を行わなければならない。このように、DTCP−IPを用いた場合、クライアントへの共通鍵の設定がユーザにとって負担となっていた。
特開2006−191341号公報 特開2006−317997号公報
本発明の目的は、クライアントに対する暗号鍵の設定が容易な暗号鍵管理システムを提供することである。
課題を解決するための手段及び効果
本発明による暗号鍵管理システムは、ローカルサーバと、クライアントと、サービスサーバとを備える。ローカルサーバは、ローカルネットワークに接続される。クライアントは、ローカルネットワークに接続される。サービスサーバは、ローカルサーバ及びクライアントと通信可能である。ローカルサーバは、第1セッション確立部と、暗号鍵送信部とを備える。第1セッション確立部は、第1認証情報をサービスサーバに送信してローカルサーバとサービスサーバとの間に第1セッションを確立する。暗号鍵送信部は、暗号鍵とローカルサーバの識別情報とを第1セッションを介してサービスサーバに送信する。クライアントは、第2セッション確立部を備える。第2セッション確立部は、第2認証情報をサービスサーバに送信してクライアントとサービスサーバとの間に第2セッションを確立する。サービスサーバは、暗号鍵配信部を備える。暗号鍵配信部は、ローカルサーバから送信された第1認証情報がクライアントから送信された第2認証情報に一致する場合、ローカルサーバから送信された暗号鍵及び識別情報を第2セッションを介してクライアントに配信する。
クライアントは、第1セッションの確立に用いられた第1認証情報と同一の第2認証情報を用いて第2セッションを確立することにより、暗号鍵をサービスサーバから取得することができる。したがって、ユーザは、ローカルサーバが使用する暗号鍵を簡易な操作でクライアントに設定することができる。
好ましくは、ローカルサーバは、さらに、第1グループ識別子送信部を備える。第1グループ識別子送信部は、第1セッションが属するグループを特定する第1グループ識別子をサービスサーバに送信する。クライアントは、さらに、第2グループ識別子送信部を備える。第2グループ識別子送信部は、第2セッションが属するグループを特定する第2グループ識別子をサービスサーバに送信する。暗号鍵配信部は、クライアントから送信された第2グループ識別子がローカルサーバから送信された第1グループ識別子に一致する場合、暗号鍵をクライアントに配信する。
サービスサーバは、クライアントから送信された第2グループ識別子がローカルサーバから送信された第1グループ識別子に一致しなければ、暗号鍵をクライアントに配信しない。したがって、サービスサーバは、グループ識別子を用いることにより、暗号鍵をクライアントに選択的に配信することができる。
好ましくは、クライアントは、さらに、記憶部と、コンテンツ要求部とを備える。記憶部は、サービスサーバから配信された暗号鍵及び識別情報を記憶する。コンテンツ要求部は、記憶部に記憶された識別情報を記憶部に記憶された暗号鍵で暗号化し、暗号化された識別情報を含むコンテンツ要求をローカルサーバに送信する。ローカルサーバは、さらに、コンテンツ格納部と、コンテンツ送信部とを備える。コンテンツ格納部は、コンテンツデータを格納する。コンテンツ送信部は、コンテンツ要求に含まれる識別情報を、暗号鍵を用いて復号し、識別情報と復号された識別情報とが一致する場合、コンテンツデータを暗号鍵で暗号化してクライアントに送信する。
クライアントは、記憶部に記憶された暗号鍵で識別情報を暗号化し、暗号化された識別情報を含むコンテンツ要求をローカルサーバに送信する。ローカルサーバは、コンテンツ要求に含まれる識別情報を復号する。ローカルサーバは、復号された識別情報を、サービスサーバへ送信した識別情報と比較することにより、コンテンツ要求の正当性を判定することができる。
好ましくは、ローカルサーバは、さらに、コンテンツ格納部と、コンテンツ送信部とを備える。コンテンツ格納部は、コンテンツデータを格納する。コンテンツ送信部は、コンテンツデータを暗号鍵で暗号化し、識別情報を暗号鍵で暗号化し、暗号化されたコンテンツデータ及び暗号化された識別情報をクライアントに送信する。クライアントは、識別情報復号部と、コンテンツ復号部とを備える。識別情報復号部は、ローカルサーバから送信された識別情報を、記憶部に記憶された暗号鍵を用いて復号する。コンテンツ復号部は、復号された識別情報が記憶部に記憶された識別情報に一致する場合、ローカルサーバから送信されたコンテンツデータを、記憶部に記憶された暗号鍵を用いて復号する。
ローカルサーバは、コンテンツデータ及び識別情報を暗号鍵でそれぞれ暗号化し、暗号化されたコンテンツデータ及び識別情報をクライアントに送信する。クライアントは、記憶部に記憶された暗号鍵を用いて、送信された識別情報を復号する。クライアントは、復号された識別情報を記憶部に記憶されている識別情報と比較することにより、ローカルサーバから送信されたコンテンツデータの正当性を判定することができる。
本発明のサービスサーバは、本発明の暗号鍵管理システムに用いられる。
本発明の暗号鍵管理方法は、本発明の暗号鍵管理システムに用いられる。
本発明の第1の実施の形態による暗号鍵管理システムの機能ブロック図である。 図1に示すローカルサーバの機能ブロック図である。 図1に示すAV機器の機能ブロック図である。 図1に示すサービスサーバの機能ブロック図である。 図1に示す暗号鍵管理システムの動作を示すシーケンス図である。 図4に示すセッションテーブルの一例を示す図である。 図1に示すローカルサーバから送信されるペアリング情報を示す図である。 図1に示すローカルサーバの動作を示すフローチャートである。 図1に示すサービスサーバの動作を示すフローチャートである。 図1に示すサービスサーバの動作を示すフローチャートである。 図1に示すAV機器の動作を示すフローチャートである。 本発明の第2の実施の形態による暗号鍵管理システムの動作を示すシーケンス図である。 本発明の第1の実施の形態の変形例による暗号鍵管理システムの動作を示すシーケンス図である。
以下、図面を参照し、本発明の実施の形態を詳しく説明する。図中同一又は相当部分には同一符号を付してその説明は繰り返さない。
[第1の実施の形態]
{全体構成}
図1は、本発明の第1の実施の形態による暗号鍵管理システムの機能ブロック図である。図1を参照して、本実施の形態の暗号鍵管理システムは、ローカルサーバ1と、AV(Audio and Visual)機器2,3と、ルータ4と、サービスサーバ5とを備える。
LAN(Local Area Network)7は、ローカルサーバ1及びAV機器2,3のユーザの家屋内に構築される。LAN7は、ローカルサーバ1及びAV機器2,3がルータ4に接続されることにより構築される。
ローカルサーバ1は、ハードディスクレコーダである。ローカルサーバ1は、楽曲を録音した音声データ、映像を録画した映像データなどのコンテンツデータを格納する。AV機器2,3は、ローカルサーバ1から送信されたコンテンツデータを再生するクライアントである。クライアントは、PC(Personal Computer)、オーディオ再生機器などである。ルータ4は、LAN7をインターネット6に接続する。
サービスサーバ5は、インターネット6及びLAN7を介して、ローカルサーバ1及びAV機器2,3と通信可能である。サービスサーバ5は、ローカルサーバ1からAV機器2,3へコンテンツデータを転送する際に使用される暗号鍵を管理する。サービスサーバ5は、ローカルサーバ1から送信されたペアリング情報19をAV機器2,3に配信する。ペアリング情報19は、暗号鍵を含む。ペアリング情報19の詳細は後述する。
セッション100が、ローカルサーバ1とサービスサーバ5との間に確立される。セッション200が、AV機器2とサービスサーバ5との間に確立される。セッション300が、AV機器3とサービスサーバ5との間に確立される。
図2は、ローカルサーバ1の機能ブロック図である。図2を参照して、ローカルサーバ1は、CPU(Central Processing Unit)11と、メモリ12と、ネットワークインタフェース13と、HDD(Hard Disk Drive)14とを備える。
CPU11は、HDD14に格納されたプログラムを実行する。すなわち、CPU11は、プログラムをメモリ12にロードし、ロードされたプログラムを実行してローカルサーバ1を制御する。ネットワークインタフェース13は、TCP(Transmission Control Protocol)/IP(Internet Protocol)などのプロトコルを用いて、インターネット6又はLAN7に接続されたコンピュータと通信する。
HDD14は、UUID(universally unique identifier)15と、暗号鍵16と、コンテンツデータ17と、制御プログラム18とを格納する。UUID15は、ローカルサーバ1に固有の識別情報であり、ローカルサーバ1により生成される。暗号鍵16は、コンテンツデータ17の暗号化に用いられる。コンテンツデータ17は、楽曲又は映像などのコンテンツを記録したデジタルデータである。図2では、HDD14は、一つのコンテンツデータ17を格納しているが、実際には、複数のコンテンツデータ17を格納する。制御プログラム18は、ローカルサーバ1の動作を制御するプログラムである。
図3は、AV機器2の機能ブロック図である。図3を参照して、AV機器2は、CPU21と、メモリ22と、ネットワークインタフェース23と、HDD24とを備える。
CPU21は、HDD24に格納されたプログラムをメモリ22にロードし、ロードされたプログラムを実行してAV機器2を制御する。ネットワークインタフェース23は、TCP/IPなどのプロトコルを用いて、インターネット6又はLAN7に接続されたコンピュータと通信する。
HDD24は、UUID15と、暗号鍵16と、制御プログラム25とを格納する。HDD24に格納されるUUID15及び暗号鍵16は、サービスサーバ5を経由してローカルサーバ1から送信される。制御プログラム25は、AV機器2の動作を制御するプログラムである。
AV機器3は、AV機器2と同様の構成を有するため、その構成の詳細な説明を省略する。
図4は、サービスサーバ5の機能ブロック図である。図4を参照して、サービスサーバ5は、CPU51と、メモリ52と、ネットワークインタフェース53と、HDD54とを備える。
CPU51は、HDD54に格納されたプログラムをメモリ52にロードし、ロードされたプログラムを実行してサービスサーバ5を制御する。ネットワークインタフェース53は、TCP/IPなどのプロトコルを用いて、インターネット6又はLAN7に接続されたコンピュータと通信する。
HDD54は、UUID15と、暗号鍵16と、サーバプログラム55と、セッションテーブル56とを格納する。HDD54に格納されるUUID15及び暗号鍵16は、ローカルサーバ1から送信される。サーバプログラム55は、サービスサーバ5をウェブサーバとして機能させるためのプログラムである。セッションテーブル56は、サービスサーバ5と他の装置との間に確立されるセッションを管理するために用いられる。
{暗号鍵管理システムの動作の概略}
以下、図1に示す暗号鍵管理システムの動作の概略を説明する。図1を参照して、ローカルサーバ1が認証情報(ログイン用のユーザID及びパスワード)をサービスサーバ5に送信することにより、セッション100が、ローカルサーバ1とサービスサーバ5との間に確立される。ローカルサーバ1は、UUID15及び暗号鍵16をセッション100を介してサービスサーバ5に送信する。
AV機器2が認証情報をサービスサーバ5に送信することにより、セッション200が、AV機器2とサービスサーバ5との間に確立される。ローカルサーバ1から送信された認証情報がAV機器2から送信された認証情報に一致する場合、サービスサーバ5は、ローカルサーバ1から送信されたUUID15及び暗号鍵16をセッション200を介してAV機器2に送信する。
このように、AV機器2が、ローカルサーバ1のログインに用いた認証情報を用いて、サービスサーバ5にログインすることにより、UUID15及び暗号鍵16が、AV機器2に設定される。ユーザが暗号鍵の設定に関する特別な操作をクライアントに対して行わなくてもよいため、AV機器2に対する暗号鍵16の設定が簡略化される。
{暗号鍵管理システムにおけるデータの流れ}
図5は、暗号鍵管理システム全体の動作を示すシーケンス図である。図6は、セッションテーブル56の一例を示す図である。図5及び図6を参照して、暗号鍵管理システムの各装置間でやり取りされるデータの流れを説明する。
最初に、ユーザは、ローカルサーバ1からサービスサーバ5にログインする。具体的には、ローカルサーバ1は、認証情報とグループIDとを含むログイン要求をサービスサーバ5に送信する(ステップS11)。グループIDの詳細は、後述する。
サービスサーバ5は、ローカルサーバ1から送信された認証情報が認証データベース(図示省略)に登録されている場合、ローカルサーバ1のログインを許可する。サービスサーバ5は、ログイン許可通知をローカルサーバ1に送信する(ステップS12)。この結果、セッション100が、ローカルサーバ1とサービスサーバ5との間に確立される。サービスサーバ5は、セッションテーブル56を用いて、セッション100を管理する。
セッションIDは、各セッションに固有の識別子である。サービスサーバ5は、ローカルサーバ1のログインを許可した場合、セッションID「34501」をセッションテーブル56に登録する。サービスサーバ5は、認証情報(ユーザID及びパスワード)と、ローカルサーバ1のIPアドレスと、グループID「10」をセッションID「34501」に対応付けてセッションテーブル56に登録する。ステップS12で送信されるログイン許可通知は、セッションID「34501」を含む。
次に、ユーザは、AV機器2からサービスサーバ5に別途ログインする。AV機器2は、認証情報及びグループIDを含むログイン要求をサービスサーバ5に送信する(ステップS13)。サービスサーバ5は、ローカルサーバ1からのログイン要求を受信した場合と同様に、AV機器2のログインを許可する。サービスサーバ5は、AV機器2からのログインを許可した場合、セッションID「74189」をセッションテーブル56に新たに登録する。AV機器2から送信された認証情報及びグループIDが、セッションID「74189」に対応付けられて、セッションテーブル56に登録される。サービスサーバ5は、セッションID「74189」を含むログイン許可通知をAV機器2に送信する(ステップS14)。これにより、セッション200が、AV機器2とサービスサーバ5との間に確立される。
図7は、ローカルサーバ1からサービスサーバ5に送信されるペアリング情報19を示す図である。図7を参照して、ペアリング情報19は、UUID15と、暗号鍵16と、グループID51と、アクセス情報52とを含む。アクセス情報52は、コンテンツデータ17の格納先を示すURL(Uniform Resource Locator)のリストである。ローカルサーバ1は、サービスサーバ5にログインした後に、ペアリング情報19を、セッション100を介してサービスサーバ5に送信する(ステップS15)。サービスサーバ5は、送信されたペアリング情報19を、セッション100に割り当てられたセッションID「34501」に対応付けてHDD54に格納する。
サービスサーバ5は、ペアリング情報19を受信した場合、セッションテーブル56のユーザID、パスワード、及びグループIDを参照して、ペアリング情報19の配信先が存在するか否かを確認する。
ここで、図6を参照して、グループIDについて説明する。グループIDは、サービスサーバ5が利用可能な各セッションが属するグループの識別子である。グループID「10」が、セッションID「34501」、「74189」に対応付けられている。つまり、セッション100,200は、同一のグループに属する。
セッション100に割り当てられたセッションID「34501」の認証情報が、セッション200に割り当てられたセッションID「74189」の認証情報に一致している。セッション100のグループIDが、セッション200のグループIDに一致している。したがって、サービスサーバ5は、ペアリング情報19をセッション200の接続先(AV機器2)に配信することを決定する。サービスサーバ5は、ペアリング情報19をセッション200を介してAV機器2に送信する(ステップS16)。
セッションID「92441」は、AV機器3とサービスサーバ5との間に確立されたセッション300の識別子である。セッション300に割り当てられたセッションID「92441」に対応する認証情報は、セッション100に割り当てられたセッションID「34501」に対応する認証情報に一致する。しかし、セッション300のグループIDは、セッション100のグループIDに一致しない。この場合、サービスサーバ5は、ペアリング情報19をAV機器3に送信しない。このように、ユーザは、グループIDを用いて、各セッションが属するグループを設定することにより、ペアリング情報19の配信先を指定することができる。
図5を参照して、AV機器2は、サービスサーバ5から送信されたペアリング情報19をHDD24に格納する。AV機器2は、ローカルサーバ1に格納されているコンテンツデータ17の再生指示を受け付けた場合、UUID15を暗号鍵16で暗号化する。ユーザは、アクセス情報52の中から、再生を希望するするコンテンツデータ17のURLを選択する。AV機器2は、暗号化されたUUID15と選択されたURLとを含むコンテンツ送信要求を、ローカルサーバ1に送信する(ステップS17)。
ローカルサーバ1は、AV機器2から送信されたUUID15を、HDD14に格納されている暗号鍵16を用いて復号する。復号されたUUID15が、HDD14に格納されているUUID15に一致する場合、ローカルサーバ1は、AV機器2から送信されたコンテンツ送信要求が正当であると判定する。ローカルサーバ1は、AV機器2から送信されたURLで指定されたコンテンツデータ17を、HDD14に格納されている暗号鍵16で暗号化し、暗号化されたコンテンツデータ17をAV機器2に送信する(ステップS18)。
AV機器2は、ローカルサーバ1から送信されたコンテンツデータ17を、HDD24に格納されている暗号鍵16を用いて復号する。復号されたコンテンツデータ17は、AV機器2により再生される。
このように、ユーザは、ローカルサーバ1からサービスサーバ5にログインし、AV機器2からサービスサーバ5にログインすることにより、ローカルサーバ1が保持する暗号鍵16をAV機器2に設定することができる。したがって、ユーザは、簡易な操作で、暗号鍵16をクライアント(AV機器2)に設定することができる。
{各機器の動作}
以下、図1に示す暗号鍵管理システムを構成する各機器の動作を詳しく説明する。
{ローカルサーバ1の動作}
図8は、ローカルサーバ1の動作を示すフローチャートである。図8を参照して、ログインをサービスサーバ5に要求してから、コンテンツデータ17をAV機器2に送信するまでのローカルサーバ1の動作を詳しく説明する。
制御プログラム18は、認証情報及びグループID51の入力を受け付けた場合、入力された認証情報及びグループID51を含むログイン要求を、サービスサーバ1に送信する(ステップS101)。ログイン要求の送信には、HTTPS(HyperText Transfer Protocol over SSL)が用いられる。ユーザは、グループIDとして、任意の数字を入力することができる。グループIDは、制御プログラム18により自動的に生成されてもよい。この場合、制御プログラム18は、ログインが許可された後などに、生成したグループIDをユーザに通知すればよい。
制御プログラム18は、ログイン許可通知をサービスサーバ5から受信した場合(ステップS102においてYes)、セッション100が確立されたと判断する。制御プログラム18は、ログイン許可通知に含まれるセッションID「34501」をメモリ12に保存する。
制御プログラム18は、UUID15及び暗号鍵16を生成し(ステップS103)、生成したUUID15及び暗号鍵16をHDD14に格納する。制御プログラム18は、ステップS103で生成されたUUID15及び暗号鍵16を用いて、ペアリング情報19(図7参照)を生成する。
制御プログラム18は、生成されたペアリング情報19をセッション100を介してサービスサーバ5に送信する(ステップS104)。具体的には、制御プログラム18は、メモリ12に保存されたセッションID「34501」をペアリング情報19に付加して、サービスサーバ5に送信する。ペアリング情報19の送信には、HTTPSが用いられる。その後、制御プログラム18は、コンテンツ送信要求を受信するまで(ステップS105においてYes)、待機する。
制御プログラム18は、コンテンツ送信要求をAV機器2から受信した場合(ステップS105においてYes)、コンテンツ送信要求に含まれるUUID15を、HDD14に格納されている暗号鍵16を用いて復号する(ステップS106)。制御プログラム18は、ステップS106で復号されたUUID15を、HDD14に格納されているUUID15と比較する(ステップS107)。
復号されたUUID15が、HDD14に格納されているUUID15に一致する場合(ステップS107でYes)、制御プログラム18は、受信したコンテンツ送信要求が正当であると判断する。制御プログラム18は、コンテンツ送信要求に含まれるURLに基づいて、送信を要求されたコンテンツデータ17を特定する。制御プログラム18は、HDD14に格納された暗号鍵16を用いて、URLで特定されたコンテンツデータ17を暗号化し、暗号化されたコンテンツデータ17をHTTPSを用いてAV機器2に送信する(ステップS108)。
一方、復号されたUUID15が、HDD14に格納されているUUID15に一致しない場合(ステップS107でNo)、コンテンツ送信要求は、正当でないと判定される。制御プログラム18は、エラーをAV機器2に通知する(ステップS109)。
{サービスサーバ5の動作}
以下、ログイン要求を受信した場合におけるサービスサーバ5の動作と、ペアリング情報を受信した場合におけるサービスサーバ5の動作とを、それぞれ説明する。
図9は、ログイン要求を受信した場合におけるサービスサーバ5の動作を示すフローチャートである。図9を参照して、サーバプログラム55は、ログイン要求をローカルサーバ1から受信した場合(ステップS501においてYes)、ローカルサーバ1のログインを許可するか否かを判定する(ステップS502)。
ログイン要求に含まれる認証情報が、HDD54に予め格納されている認証データベース(図示省略)に登録されている場合、サーバプログラム55は、ローカルサーバ1のログインを許可する(ステップS502においてYes)。サーバプログラム55は、セッション100の識別子として、セッションID「34501」を新たに発行してセッションテーブル56に登録する(ステップS503)。ステップS503では、ログイン要求に含まれる認証情報及びグループIDも、セッションID「34501」とともにセッションテーブル56に登録される。サーバプログラム55は、セッションID「34501」を含むログイン許可通知をローカルサーバ1に送信する(ステップS504)。
ログインを許可しない場合(ステップS502においてNo)、サーバプログラム55は、ログインを許可しないことをローカルサーバ1に通知した後に、ステップS501に戻る。
一方、AV機器2からのログイン要求を受け付けた場合、サービスサーバ5は、ステップS501〜S504を繰り返す。これにより、セッション200の識別子であるセッションID「74189」と、AV機器2から送信された認証情報と、グループIDとが、セッションテーブル56に登録される。
図10は、ペアリング情報19を受信した場合におけるサービスサーバ5の動作を示すフローチャートである。ローカルサーバ1は、サービスサーバ5にログインした後に、セッションID「34501」を付加したペアリング情報19を、サービスサーバ5に送信する(ステップS104。図8参照)。図10を参照して、サーバプログラム55は、ペアリング情報19を受信した場合(ステップS505においてYes)、受信したペアリング情報19を、セッション100に割り当てられたセッションID「34501」に対応付けてHDD54に保存する(ステップS506)。
サーバプログラム55は、受信したペアリング情報19の配信先を決定する(ステップS507)。具体的には、サーバプログラム55は、セッションテーブル56を参照して、セッションID「34501」の認証情報及びグループIDがセッションID「74189」の認証情報及びグループIDに一致すると判定する。サーバプログラム55は、セッションID「74189」に対応付けられたIPアドレス(AV機器2のIPアドレス)をペアリング情報19の配信先として決定する。
配信先が決定された場合(ステップS507でYes)、サーバプログラム55は、ペアリング情報19を、特定した配信先にHTTPSを用いて配信する(ステップS508)。なお、サーバプログラム19は、決定した配信先にペアリング情報19を既に送信していた場合、ステップS508を実行しない。
サーバプログラム55は、配信先を決定できなかった場合(ステップS507でNo)、新たなログインを許可するまで待機する(ステップS509)。サーバプログラム55は、ログインを新たに許可した場合(ステップS509においてYes)、HDD54に格納されたペアリング情報19を、ログインを新たに許可した機器に転送できるか否かを判定するために、ステップS507に戻る。
{AV機器2の動作}
図11は、AV機器2の動作を示すフローチャートである。図11を参照して、ログインをサービスサーバ5に要求してから、コンテンツデータ17の再生を開始するまでのAV機器2の動作を説明する。
制御プログラム25は、認証情報及びグループID51の入力を受け付けた場合、入力された認証情報及びグループID51を含むログイン要求を、サービスサーバ1に送信する(ステップS201)。ログイン要求の送信には、HTTPSが用いられる。ステップS201で送信されるログイン要求は、ローカルサーバ1がログインする際に用いられた認証情報及びグループIDと同一のデータを含む。
制御プログラム25は、ログイン許可通知をサービスサーバ5から受信した場合(ステップS202においてYes)、セッション200が確立されたと判断し、ペアリング情報19を受信するまで待機する(ステップS203)。制御プログラム25は、ペアリング情報19を、セッション200を介してサービスサーバ5から受信した場合(ステップS203においてYes)、受信したペアリング情報19をHDD24に格納する(ステップS204)。
AV機器2は、ユーザの操作に応じて、アクセス情報52を表示する。ユーザは、表示されたアクセス情報52の中から、AV機器2で再生するコンテンツデータ17のURLを選択する。制御プログラム25は、ステップS205,S206を実行して、AV機器2で再生するためのコンテンツデータ17の送信を要求する。
具体的には、制御プログラム25は、HDD24に格納されたペアリング情報19からUUID15と暗号鍵16とを取り出す。制御プログラム25は、UUID15を暗号鍵16で暗号化する(ステップS205)。制御プログラム25は、暗号化されたUUID15と選択されたURLとを含むコンテンツ送信要求を作成して、ローカルサーバ1に送信する(ステップS206)。コンテンツ送信要求の送信には、HTTPSが用いられる。その後、制御プログラム25は、ローカルサーバ1からの応答があるまで待機する(ステップS207)。
制御プログラム25は、コンテンツデータ17をコンテンツ送信要求の応答として受信した場合(ステップS207においてYes)、受信したコンテンツデータ17を、HDD24に格納されている暗号鍵16を用いて復号する(ステップS208)。制御プログラム25は、復号したコンテンツデータを再生する。
以上説明したように、セッション100,200に割り当てられたセッションIDが、同一の認証情報及びグループIDに対応づけられている場合、サービスサーバ5は、セッション100を介して受信したペアリング情報19を、セッション200を介してAV機器2に送信する。ユーザは、ローカルサーバ1からサービスサーバ5にログインする操作と、AV機器2からサービスサーバ5にログインする操作とを、同一の認証情報を用いて行うことにより、AV機器2に暗号鍵16を設定することができる。したがって、AV機器2に暗号鍵を設定する操作が簡略化される。
[第2の実施の形態]
本発明の第2の実施の形態について、上記第1の実施の形態と異なる点を中心に説明する。第1の実施の形態では、ローカルサーバ1は、AV機器2からのコンテンツ送信要求に応じて、コンテンツデータ17を送信する。しかし、第2の実施の形態では、AV機器2は、コンテンツ送信要求を送信しない。ローカルサーバ1は、コンテンツデータ17をAV機器2,3にマルチキャストする。
図12は、第2の実施の形態による暗号鍵管理システムの動作を示すシーケンス図である。図12を参照して、ステップS16以降のデータの流れを説明する。
サービスサーバ1が、ペアリング情報19をAV機器2に配信した時点で(ステップS16)、AV機器3は、サービスサーバ5にログインしていない。ユーザは、ローカルサーバ1を操作して、AV機器2,3に対するコンテンツデータ17のマルチキャストを指示する。
ローカルサーバ1は、暗号化されたコンテンツデータ17のマルチキャストを開始する(ステップS21,S22)。具体的には、ローカルサーバ1は、HDD14に格納されているUUID15とコンテンツデータ17とを暗号鍵16で暗号化する。暗号化されたUUID15及びコンテンツデータ17を含むデータ(以下、マルチキャストデータという)がAV機器2,3へマルチキャストされる。
AV機器2は、マルチキャストデータを受信した場合、HDD24に格納されている暗号鍵16を用いて、マルチキャストデータに含まれるUUID15(ローカルサーバ1から送信されたUUID15)を復号する(ステップS23)。復号されたUUID15が、HDD24に格納されているUUID15と一致する場合、AV機器2は、受信したマルチキャストデータが正当であると判定する。AV機器2は、HDD24に格納されている暗号鍵16を用いて、マルチキャストデータに含まれるコンテンツデータ17(ローカルサーバ1から送信されたコンテンツデータ17)の復号を開始する(ステップS24)。この結果、AV機器2において、復号されたコンテンツデータの再生が開始される。
一方、AV機器3は、サービスサーバ5にログインしていないため、ペアリング情報19をサービスサーバ5から取得していない。AV機器3は、マルチキャストデータを受信しても、暗号化されたUUID15及びコンテンツデータ17を復号できない。
マルチキャストが開始された後に、ユーザは、AV機器3を操作して、サービスサーバ5へのログインを指示する。ユーザは、AV機器2のログイン時に使用した認証情報とグループID51とを、AV機器3に入力する。AV機器3は、入力された認証情報及びグループID51を含むログイン要求をサービスサーバ5に送信する(ステップS25)。サービスサーバ5は、ログイン要求に含まれる認証情報に基づいて、AV機器3のログインを許可し、ログイン許可通知をAV機器3に送信する(ステップS26)。この結果、セッション300が、AV機器3とサービスサーバ5との間に確立される。セッションテーブル56のセッションID「34501」、「74189」、「92441」には、同一の認証情報及びグループIDが登録される。
サービスサーバ5は、更新されたセッションテーブル56を参照して、ペアリング情報19をAV機器3に配信できると判断する。サービスサーバ1は、ペアリング情報19を、セッション300を介してAV機器3に配信する(ステップS27)。ペアリング情報19の送信には、HTTPSが用いられる。
AV機器3は、ペアリング情報19を受信することにより、マルチキャストデータに含まれるUUID15を復号することが可能となる。AV機器3は、AV機器2と同様に、HDD24に格納されている暗号鍵16を用いて、マルチキャストデータに含まれるUUID15を復号する(ステップS28)。AV機器3は、マルチキャストデータが正当であると判定した場合、マルチキャストデータに含まれるコンテンツデータ17の復号を開始する(ステップS29)。この結果、AV機器3において、復号されたコンテンツデータ17の再生が開始される。
このように、第2の実施の形態では、ローカルサーバ1が、配信データをマルチキャスト配信する。ユーザは、ローカルサーバ1を操作して、AV機器2,3で同一のコンテンツを再生することが可能となる。
上記第1及び第2の実施の形態では、ローカルサーバ1及びAV機器2,3が、グループIDを認証情報とともに送信する例を説明したが、これに限られない。図13を参照して、ローカルサーバ1は、セッション100がステップS11,S12の処理により確立された後に、グループID「10」をセッション100を介してサービスサーバ5に送信してもよい(ステップS51)。同様に、AV機器2は、セッション200がステップS13,S14の処理により確立された後に、グループID「10」をセッション200を介してサービスサーバ5に送信してもよい(ステップS52)。ユーザは、ローカルサーバ1及びAV機器2のログインをやり直すことなく、セッション200が属するグループをセッション200が属するグループと異なるグループに変更することができる。したがって、互いに異なる暗号鍵をAV機器2,3に容易に設定することができる。
上記第1及び第2実施の形態において、ローカルサーバ1及びAV機器2,3が、ログイン要求のときにグループIDをサービスサーバ5に送信する例を説明したが、これに限られない。ローカルサーバ1は、グループIDを送信しなくてもよい。この場合、サービスサーバ5は、各セッションIDに対応付けられた認証情報を比較することによって、ペアリング情報19の送信先を決定すればよい。
上記実施の形態では、クライアントがAV機器2,3である例を説明したが、これに限られない。クライアントは、ローカルサーバ1及びサービスサーバ5と通信可能であり、コンテンツデータ17を再生できる機能を有する機器であればよい。たとえば、クライアントとして、スマートフォンなどの携帯電話などを用いることができる。
以上、本発明の実施の形態を説明したが、上述した実施の形態は本発明を実施するための例示に過ぎない。よって、本発明は上述した実施の形態に限定されることなく、その趣旨を逸脱しない範囲内で上述した実施の形態を適宜変形して実施することが可能である。
1 ローカルサーバ
2,3 AV機器
5 サービスサーバ
11,21,51 CPU
12,22,52 メモリ
14,24,54 HDD
15 UUID
16 暗号鍵
17 コンテンツデータ
18,25 制御プログラム
19 ペアリング情報
51 グループID
55 サーバプログラム
56 セッションテーブル

Claims (6)

  1. ローカルネットワークに接続されるローカルサーバと、
    前記ローカルネットワークに接続されるクライアントと、
    前記ローカルサーバ及び前記クライアントと通信可能なサービスサーバとを備え、
    前記ローカルサーバは、
    第1認証情報を前記サービスサーバに送信して前記ローカルサーバと前記サービスサーバとの間に第1セッションを確立する第1セッション確立部と、
    暗号鍵と前記ローカルサーバの識別情報とを前記第1セッションを介して前記サービスサーバに送信する暗号鍵送信部とを備え、
    前記クライアントは、
    第2認証情報を前記サービスサーバに送信して前記クライアントと前記サービスサーバとの間に第2セッションを確立する第2セッション確立部を備え、
    前記サービスサーバは、
    前記ローカルサーバから送信された第1認証情報が前記クライアントから送信された第2認証情報に一致する場合、前記ローカルサーバから送信された暗号鍵及び識別情報を前記第2セッションを介して前記クライアントに配信する暗号鍵配信部を備える、暗号鍵管理システム。
  2. 請求項1に記載の暗号鍵管理システムであって、
    前記ローカルサーバは、さらに、
    前記第1セッションが属するグループを特定する第1グループ識別子を前記サービスサーバに送信する第1グループ識別子送信部を備え、
    前記クライアントは、さらに、
    前記第2セッションが属するグループを特定する第2グループ識別子を前記サービスサーバに送信する第2グループ識別子送信部を備え、
    前記暗号鍵配信部は、前記クライアントから送信された第2グループ識別子が前記ローカルサーバから送信された第1グループ識別子に一致する場合、前記暗号鍵を前記クライアントに配信する、暗号鍵管理システム。
  3. 請求項1又は請求項2に記載の暗号鍵管理システムであって、
    前記クライアントは、さらに、
    前記サービスサーバから配信された暗号鍵及び識別情報を記憶する記憶部と、
    前記記憶部に記憶された識別情報を前記記憶部に記憶された暗号鍵で暗号化し、前記暗号化された識別情報を含むコンテンツ要求を前記ローカルサーバに送信するコンテンツ要求部とを備え、
    前記ローカルサーバは、さらに、
    コンテンツデータを格納するコンテンツ格納部と、
    前記コンテンツ要求に含まれる識別情報を前記暗号鍵を用いて復号し、前記識別情報と復号された識別情報とが一致する場合、前記コンテンツデータを前記暗号鍵で暗号化して前記クライアントに送信するコンテンツ送信部とを備える、暗号鍵管理システム。
  4. 請求項1又は請求項2に記載の暗号鍵管理システムであって、
    前記ローカルサーバは、さらに、
    コンテンツデータを格納するコンテンツ格納部と、
    前記コンテンツデータを前記暗号鍵で暗号化し、前記識別情報を前記暗号鍵で暗号化し、暗号化されたコンテンツデータ及び暗号化された識別情報を前記クライアントに送信するコンテンツ送信部とを備え、
    前記クライアントは、
    前記ローカルサーバから送信された識別情報を、前記記憶部に記憶された暗号鍵を用いて復号する識別情報復号部と、
    復号された識別情報が前記記憶部に記憶された識別情報に一致する場合、前記ローカルサーバから送信されたコンテンツデータを、前記記憶部に記憶された暗号鍵を用いて復号するコンテンツ復号部とを備える、暗号鍵管理システム。
  5. サービスサーバであって、
    第1認証情報をローカルネットワークに接続されるローカルサーバから受信して前記ローカルサーバと前記サービスサーバとの間に第1セッションを確立する第1セッション確立部と、
    暗号鍵と前記ローカルサーバの識別情報とを前記第1セッションを介して前記ローカルサーバから受信する暗号鍵受信部と、
    第2認証情報を前記ローカルネットワークに接続されるクライアントから受信して前記クライアントと前記サービスサーバとの間に第2セッションを確立する第2セッション確立部と、
    前記第1セッション確立部により受信された第1認証情報が前記第2セッション確立部により受信された第2認証情報に一致する場合、前記暗号鍵受信部により受信された暗号鍵及び識別情報を、前記第2セッションを介して前記クライアントに配信する暗号鍵配信部とを備える、サービスサーバ。
  6. ローカルネットワークに接続されるローカルサーバと、前記ローカルネットワークに接続されるクライアントと、前記ローカルサーバ及び前記クライアントと通信可能なサービスサーバとを備える暗号鍵管理システムで用いられる暗号鍵管理方法であって、
    第1認証情報を前記ローカルサーバから前記サービスサーバに送信して前記ローカルサーバと前記サービスサーバとの間に第1セッションを確立するステップと、
    暗号鍵と前記ローカルサーバの識別情報とを前記第1セッションを介して前記ローカルサーバから前記サービスサーバに送信するステップと、
    第2認証情報を前記クライアントから前記サービスサーバに送信して前記クライアントと前記サービスサーバとの間に第2セッションを確立するステップと、
    前記ローカルサーバから送信された第1認証情報が前記クライアントから送信された第2認証情報に一致する場合、前記ローカルサーバから送信された暗号鍵及び識別情報を、前記第2セッションを介して前記サービスサーバから前記クライアントに配信するステップとを備える、暗号鍵管理方法。
JP2012012331A 2012-01-24 2012-01-24 暗号鍵管理システム Pending JP2013153284A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2012012331A JP2013153284A (ja) 2012-01-24 2012-01-24 暗号鍵管理システム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2012012331A JP2013153284A (ja) 2012-01-24 2012-01-24 暗号鍵管理システム

Publications (1)

Publication Number Publication Date
JP2013153284A true JP2013153284A (ja) 2013-08-08

Family

ID=49049320

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012012331A Pending JP2013153284A (ja) 2012-01-24 2012-01-24 暗号鍵管理システム

Country Status (1)

Country Link
JP (1) JP2013153284A (ja)

Similar Documents

Publication Publication Date Title
US11528128B2 (en) Encryption management, content recording management, and playback management in a network environment
US10389689B2 (en) Systems and methods for securely streaming media content
US9847975B2 (en) Method of provisioning persistent household keys for in-home media content distribution
EP2975854B1 (en) Content distribution method, content distribution system, source device, and sink device
JP2004303111A (ja) ライセンス管理機能付き携帯端末
US10218681B2 (en) Home network controlling apparatus and method to obtain encrypted control information
JP2007235471A (ja) コンテンツ配信システム、コンテンツ配信方法、端末装置、及びそのプログラム
US9160720B2 (en) Digital rights management of streaming contents and services
WO2017096887A1 (zh) 防盗链的方法及装置
US10708326B2 (en) Secure media casting bypassing mobile devices
US9979702B2 (en) Persistent household keys for in-home media content distribution
WO2003081499A1 (fr) Procede et dispositif de gestion de licence
WO2009151015A1 (ja) サーバ装置、ライセンス配布方法、およびコンテンツ受信装置
JP5908296B2 (ja) 情報端末装置、情報端末システム、情報端末制御方法およびプログラム
CN103312686A (zh) 基于信任关系的用于实时流传输的数字权限管理
JP2012003682A (ja) アクセス制御システム、アクセス制御方法、認証装置、認証システム
JP2013153284A (ja) 暗号鍵管理システム
KR101397480B1 (ko) 전자장치 및 그의 암호화방법
US20230254342A1 (en) Cryptographic binding of data to network transport
JP7233773B2 (ja) セキュリティ指向及びグループ共有に基づくモノのインターネットシステム
JP2012178742A (ja) データ受信装置、通信装置、及び通信処理方法
JP4675040B2 (ja) コンテンツ配信システム、コンテンツ配信方法及びクライアント機器
EP3044953B1 (en) Persistent household keys for in-home media content distribution
JP2014513364A (ja) コンテンツ利用方法、コンテンツ利用装置、モバイル端末機、及び記録媒体
WO2015038831A1 (en) Persistent household keys for in-home media content distribution