(57)【特許請求の範囲】
【請求項１】
互いに接続される、１つ又は複数のソースデバイスと１つ又は複数のシンクデバイスとを有し、両者の間にセキュリティを提供するシステムであって、
前記ソースデバイスが、前記１つ又は複数のシンクデバイスのメーカによってそれぞれ電子署名された該ソースデバイスのメーカのパブリックキーを備える電子証明書の第１のリストを含み、
前記シンクデバイスが、該シンクデバイスのメーカによって電子署名された前記１つ又は複数のソースデバイスのメーカのパブリックキーを備える電子証明書の第２のリストを含み、
前記ソースデバイス及び前記シンクデバイスの少なくとも一方が、新たなメーカによるソースデバイス又はシンクデバイスが前記システムに加わるとき、該新たに加わるデバイスのメーカのパブリックキーを備える新たな電子証明書を前記第１又は第２のリストに加えるよう構成される適合化手段を含む、システム。
【請求項２】
前記ソースデバイスが、パススルーデバイスとプレイバックデバイスとのいずれかを含む、請求項１に記載のシステム。
【請求項３】
前記シンクデバイスが、記録デバイスと表示デバイスとのいずれかを含む、請求項１に記載のシステム。
【請求項４】
前記適合化手段が、デバイス間で前記新たな電子証明書を転送し、かつ格納する手段を含む、請求項１に記載のシステム。
【請求項５】
前記ソースデバイスと前記シンクデバイスとが、バスによって接続される、請求項１に記載のシステム。
【請求項６】
互いに接続される１つ又は複数のソースデバイスと１つ又は複数のシンクデバイスとを有し、両者の間にコピー保護を提供するシステムであって、
前記ソースデバイスが、前記１つ又は複数のシンクデバイスのメーカによって電子署名された該ソースデバイスのメーカのパブリックキーを備える電子証明書の第１のリストを含み、
前記シンクデバイスが、該シンクデバイスのメーカによって電子署名された前記１つ又は複数のソースデバイスのメーカのパブリックキーを備える電子証明書の第２のリストを含み、
前記ソースデバイスが、前記第１のリストに加えられるよう前記ソースデバイスに送信される、前記シンクデバイスからの新たな電子証明書を受信するよう適合化する適合化手段を含む、システム。
【請求項７】
前記シンクデバイスが、前記第２のリストに加えられるよう前記シンクデバイスに送信される、前記ソースデバイスからの新たな電子証明書を受信するよう適合化する適合化手段を含む、請求項６に記載のシステム。
【請求項８】
前記ソースデバイスが、パススルーデバイスとプレイバックデバイスとのいずれかを含む、請求項６に記載のシステム。
【請求項９】
前記シンクデバイスが、記録デバイスと表示デバイスとのいずれかを含む、請求項６に記載のシステム。
【請求項１０】
前記シンクデバイスと前記ソースデバイスとが、バスによって接続される、請求項６に記載のシステム。
【請求項１１】
互いに接続される１つ又は複数のソースデバイスと１つ又は複数のシンクデバイスとを有し、両者の間にコピー保護を提供するシステムであって、
前記ソースデバイスが、前記１つ又は複数のシンクデバイスのメーカによって電子署名された該ソースデバイスのメーカのパブリックキーを備える電子証明書の第１のリストを含み、
前記シンクデバイスが、該シンクデバイスのメーカによって電子署名された前記１つ又は複数のソースデバイスのメーカのパブリックキーを備える電子証明書の第２のリストを含み、
前記第１のリストが、前記第２のリストにはない電子証明書を含み、
前記シンクデバイスが、前記第２のリストに加えられるよう前記シンクデバイスに送信される、前記ソースデバイスからの新たな電子証明書を受信するよう適合化する適合化手段を含む、システム。
【請求項１２】
前記第２のリストが、前記第１のリストにはない電子証明書を含み、
前記ソースデバイスが、前記第１のリストに加えられるよう前記ソースデバイスに送信される、前記シンクデバイスからの新たな電子証明書を受信するよう適合化する適合化手段を含む、請求項１１に記載のシステム。
【請求項１３】
前記ソースデバイスが、パススルーデバイスとプレイバックデバイスとのいずれかを含む、請求項１１に記載のシステム。
【請求項１４】
前記シンクデバイスが、記録デバイスと表示デバイスとのいずれかを含む、請求項１１に記載のシステム。
【請求項１５】
前記シンクデバイスと前記ソースデバイスとが、バスによって接続される、請求項１１に記載のシステム。
【請求項１６】
互いに接続されるソースデバイスとシンクデバイスとの間で転送されるコンテンツに対するコピー保護を提供する方法において、
前記ソースデバイスと前記シンクデバイスとの間で識別情報を転送するステップと、
前記ソースデバイスと前記シンクデバイスとが、別のソースデバイス又はシンクデバイスから転送された識別情報を含むかどうかを決定することにより、前記ソースデバイスと前記シンクデバイスとを認証するステップと、
前記認証に失敗する場合、新たなソースデバイス又は新たなシンクデバイスのために提供される新たな識別情報が存在するかをチェックするステップと、
前記新たな識別情報を前記ソースデバイスと前記シンクデバイスとの間で転送し、格納するステップとを有する、方法。
【請求項１７】
前記新たな識別情報を転送し、格納するステップが、所定の証明ソースを用いて前記新たな識別情報を認証するステップを含む、請求項１６に記載の方法。
【請求項１８】
前記所定の証明ソースが、プライベートキーを含む、請求項１７に記載の方法。
【請求項１９】
前記識別情報と前記新たな識別情報とが、前記ソースデバイス又は前記シンクデバイスのメーカのパブリックキーを含む、請求項１６に記載の方法。
【発明の詳細な説明】
【０００１】
【発明が属する技術分野】
本発明の開示は、電子デバイスを使用する際のセキュリティに関し、より詳しくは、コピー保護を提供するパブリックキーを含む証明書を管理する方法とシステムに関する。
【０００２】
【従来の技術】
民生用電子デバイスについて検索することができるマテリアルのコピー保護についての関心は、増大している。一具体例の場合、放送事業者と映画プロデューサを含むコンテントプロバイダ産業は、コンテントマテリアルの海賊版の数が制限されることを望む。コンテントは民生用デバイスの間で扱われるので、それを保護するためにいくつかの手段が講じられてきた。例えば、コンテントが、セットトップボックスとディジタルテレビジョンとにより扱われるとき、コンテントは、保護されなければならない。さもないと、コンテントの完全なディジタルコピーが、著作権法を犯して、作られ、そして配布されてしまう。
【０００３】
現在までのところ、コンテントマテリアルを保護するスキームは、全てではないにしろそのほとんどが、秘密に保持しておかなければならない少なくとも一つの情報を含む。秘密およびその秘密が正確にどこに格納されているるかと言う点は、重要ではない。既知の一方法の場合、その秘密は、コンテントのソースとして機能することができるあらゆるデバイスにおけるユニーク暗号キーである。このキーは、デジタル署名の作成時にソースデバイスによって使用される。デジタル署名は、ソースデバイスとシンクデバイス間の、情報の安全な転送を確認するために使用される。
【０００４】
署名情報がシンクデバイスに到着すると、検証プロセスは、その情報が転送中に改変されたか否か、または、正当でないソースデバイスが、シンクデバイスに対し正当なデバイスとしてふるまおうとしているか否かを確実に決定しなければならない。シンクデバイスがデジタル署名を確認するためには、証明書がソースデバイスのメーカのパブリックキーを含んでいるか否かの確認に、シンクデバイスのメーカのパブリックキーが使用される。証明書がソースデバイスのパブリックキーを含むか否かを確認するためには、ソースデバイスのメーカのパブリックキーが、使用される。最後に、署名を確認するために、ソースデバイスのパブリックキーが使用される。
【０００５】
【課題を解決するための手段】
本発明は、種々のパブリックキーを含む証明書の利用可能性を提供する。本発明によれば、ソースデバイスまたはシンクデバイスの何れかの新たなメーカのパブリックキーを含んでいる証明書が、シンクデバイスで使用可能であるか否かを確認する問題が解決される。
【０００６】
本発明によれば、ソースデバイスとシンクデバイスの間にコピー保護を提供するシステムは、証明書のリストを含む第一デバイスを含む。リストの各証明書は、第二デバイスのメーカを識別する署名を含む。第二デバイスには、第一デバイスへのカップリングが含まれている。第二デバイスは証明書のリストを含み、そして各証明書は第一デバイスのメーカを識別する署名を含む。第一デバイスと第二デバイスの内の少なくとも一方は、第一デバイスと第二デバイスの内の一方の新たなメーカを識別する新たな署名を加えるために、その各証明書リストを適合化する手段を含む。
【０００７】
代替実施例の場合、第一デバイスは、パススルーデバイスとプレイバックデバイスの一方を含むことができる。第二デバイスは、記録デバイスと表示デバイスの一方を含むことができる。署名は、各メーカに対して指定されているパブリックキーを、各々含むことができる。適合化手段は、デバイス間に新たな証明書を転送しかつ格納する手段を含むことができる。第一デバイスと第二デバイスは、バスによって接続されていることが好ましい。
【０００８】
本発明によれば、ソースデバイスとシンクデバイスの間にコピー保護を提供する他のシステムは、証明書のリストを含むソースデバイスを含む。リストの各証明書は、シンクデバイスのメーカに対する署名（すなわち、シンクデバイスを確認する署名）を提供する。シンクデバイスには、ソースデバイスへのカップリングが含まれている。シンクデバイスは、ソースデバイスメーカに対応する証明書のリストを含む。ソースデバイスおよび／またはシンクデバイスは、シンクデバイスおよび／またはソースデバイスの他のものの証明書のリストから省略された証明書を有する。新たな証明書が、ソース／シンクデバイスに転送されて、証明書のリストに加えられ、このことによりシンク／ソースデバイスがソース／シンクデバイスから識別されるように、新たな証明書を受信するためにソースおよび／またはシンクデバイスを適合化する手段が含まれている。
【０００９】
代替実施例の場合、シンク／ソースデバイスは、ソース／シンクデバイスのメーカに対応する証明書リストを含むことができ、そしてソース／シンクデバイスは、シンク／ソースデバイスの証明書のリストから省略された証明書を有する。シンク／ソースデバイスは、新たな証明書を受信するためにシンク／ソースデバイスを適合化する手段を更に含むことができる。新たな証明書は、シンク／ソースデバイスに転送され、証明書のリストに加えられ、これによりソース／シンクデバイスがシンク／ソースデバイスから識別される。ソースデバイスは、パススルーデバイスとプレイバックデバイスの一方を含むことができ、そしてシンクデバイスは、記録デバイスと表示デバイスの一方を含むことができる。署名は、各々、各メーカに対して指定されているパブリックキーを含むことができる。デバイスは、バスによって接続されていることが好ましい。
【００１０】
ソースデバイスとシンクの間に転送されるコンテントをコピー保護する本発明の方法は、ソースデバイスとシンクデバイスの間に識別情報を転送するステップを含む。ソースデバイスとシンクデバイスの検証は、ソースデバイスとシンクデバイスが、ソースデバイスとシンクデバイスの他のものから転送された識別情報を含むか否かを決定することにより実行されることが好ましい。検証ステップが失敗すると、新たな識別情報が、新たなソースデバイスと新たなシンクデバイスの一方にその証明情報が提供されている証明情報と照合される。新たなソースデバイスまたは新たなシンクデバイス（または両方とも）は、新たな識別情報を含む。ソースデバイスとシンクデバイスの間にデータ交換を可能にする新たな証明書を提供するために、ソースデバイスとシンクデバイスの間に新たな識別情報を転送しかつ格納するステップが、含まれていることが好ましい。
【００１１】
他の方法の場合、新たな識別情報を転送かつ格納するステップは、所定の証明ソースにより新たな識別情報を確認することを含むことができる。所定の証明ソースは、プライベートキーを含むことができる。識別情報と新たな識別情報は、ソースデバイスとシンクデバイスのメーカに対応するパブリックキーを含むことができる。
【００１２】
これらのそしてまた他の本発明の目的、特徴および利点は、添付の図面を参照して読まれるべき、例示的な実施例の以下の詳細な説明から明らかになるであろう。
【００１３】
【発明を実施するための形態】
次の図を参照して好適な実施例を詳細に説明する。
【００１４】
本発明は、ソースデバイスからシンクデバイスに転送されるコンテントに対するセキュリティ（例えば、コピー保護）に関する。より詳しくは、本発明は、二方向のディジタルインタフェース／バスにより接続されているコンテントソースデバイスとコンテントシンクデバイスの間のコンテントの転送を保護するために使用されるパブリックキー情報を含む証明書を管理する方法とシステムに関する。本発明は、全ての既存のデバイスが新たなデバイスとうまく安全に対話することを可能にする、ソースまたはシンク型の両方の新たなデバイスを導入するシステム及び方法を提供する。安全に対話することを可能にするために、このデバイスは、他のデバイスから転送される証明書のディジタル署名を検証することが可能でなければならない。
【００１５】
本発明は、2つのデバイス間に確実な接続を生成するために使用される証明書を確実に入手する可能性を提供する。デバイス間の確実な接続の一つの使用分野は、コピー保護である。証明書は、シンクデバイスの認証を確実にするパブリックキーを含む。本発明は、新たなデバイスを、所定のメーカのコードまたはキーを利用するコピー保護されたシステムに導入するシステム及び方法を提供する。
【００１６】
以下の説明において、全ての証明書は、実例として国際電気通信連合通信規格化セクタ International Telecommunication Union Telecommunication Standardization Sector (ITU-T) X.509、および同一の文献国際規格化機構 International Standards Organization (ISOIIEC) 国際規格 International Standard 9594-8に記載されている標準に従っている。しかしながら、他の証明書の定義を、使用することも可能である。X.509証明書の定義は、バージョン、シリアルナンバ、署名、発行人、有効性の期間、主題のパブリックキー、発行人ユニーク識別子、主題ユニーク識別子およびイクステンション、の項目を規定する。
【００１７】
本発明の場合、各証明書は、特定メーカ、ユニークソースデバイスまたはユニークシンクデバイスの何れかのサブジェクトとパブリックキーを含む。上述したスペックについては、各証明書は、証明書の発行人によってデジタル署名される。証明書の検証は、証明書の発行人のパブリックキーを必要とする。検証された証明書から抽出されたサブジェクトとパブリックキーは、そのサブジェクトにより発行される証明書のディジタル署名を検証するために使用することができる。パブリックキーとサブジェクトが知られていて、かつ一組の証明書が存在しているとすると、一連の（またはチェーンの）検証を、一連の証明書に含まれているデータを検証して、実行することができる。
【００１８】
簡単化のために、以下では、証明書に対して記法の省略表示を採用する。現在のコンテント内の関係する証明書の項目は、サブジェクト、サブジェクトのパブリックキー、発行人と署名である。これは、Cert(Pub(<subject>),  Sig(<issuer>)と表すことができる。一例として、Cert(Pub(source device[man[A]]),  Sig(man[A]))は、サブジェクトが、メーカAによって製造されたソースデバイスで、発行人がメーカAである、証明書である。この証明書の署名を検証するためには、Pub(man[A])が使用される。他の具体例では、Cert(Pub(man[B]),  Sig(man[C])は、サブジェクトがメーカBで、発行人がメーカCである、証明書である。この証明書の署名を検証するためには、Pub(man[C])が使用される。
【００１９】
本発明によると、各ソースデバイスは、プライベートキーと、デバイスメーカによって発行された対応するパブリックキーを含む証明書、Cert(Pub(source device[man[A]]), Sig(man[A])を有する。加えて、各ソースデバイスは、デバイスメーカのパブリックキーを含み、かつシンクデバイスの全ての現在既知のメーカの組み合わせにより署名された一組の証明書、Cert(Pub(man[A]), Sig(man[i]) （ここで、iは、シンクデバイスの全ての現在既知のメーカをカバーする）を有する必要がある。
【００２０】
同様に、本発明によると、各シンクデバイスは、ユニークデバイスのプライベートキーとデバイスメーカのパブリックキー、Pub(man[B])を有する。加えて、各シンクデバイスは、デバイスメーカのパブリックキーを含み、かつソースデバイスの全ての現在既知の製品の組み合わせによって署名された一組の証明書  Cert(Pub(man[A]), Sig(man[j])) （ここで、jはソースデバイスの全ての現在既知の製品をカバーする）を有する。
【００２１】
ソースデバイスが、証明書に署名しかつシンクデバイスにそれを送出するとき、シンクは、どんな場合にもその証明書の署名を検証することが出来なければならない。上記の要件が与えられかつソースデバイスがメーカAによって製造され、そしてシンクデバイスがメーカBによって製造されたものと仮定すると、シンクは、以下の検証のチェーンの具体例によって、証明書を検証することができる。
【００２２】
シンクデバイスのメーカのパブリックキー、Pub(man[B])を使用して、証明書が、シンクメーカが発行したソースメーカのパブリックキーを含んでいるか否かが検証される、Cert(Pub(man[A]), Sig(man[B]))。ソースデバイスのメーカのパブリックキー、Pub(man[A])を抽出して、証明書は、ソースデバイスのメーカ発行のソースデバイスのパブリックキーに対して検証される、Cert(Pub(source device), Sig(man[A])。最後に、ソースデバイスのパブリックキー、Pub(source device)を抽出して、ソースデバイス発行のデータを含む証明書が検証される。シンクデバイスがソースデバイス発行の証明書を検証するために予め形成された検証のチェーンが、表1に示されている。
【００２３】
【表１】
0004607327.tif 000002
【００２４】
新たなメーカCが新たなソースデバイスを生成するときには、以前に製造されたシンクデバイスは、検証チェーンを完全なものにする証明書を持たないであろう。具体的には、Cert(Pub(man[A]).Sig(man[C])が、見つからないであろう。しかしながら、新たなソースデバイスは、その証明書の組み内にこれを有するであろう。これは、次いで、検証と使用のためにシンクデバイスに提供される。
【００２５】
同様に、新たなメーカDが新たなシンクデバイスを生成するとき、以前に製造されたソースデバイスは、検証チェーンを完全なものにすることが可能な証明書を有しないであろう。しかし、新たなシンクデバイスは、その証明書の組内にこれを有するであろう。これは、次いで、検証と使用のためにソースデバイスに提供される。
【００２６】
同様な参照番号が、同様なまたは同一の要素を識別する以下の図（先ず、図1）を、具体的に参照すると判るように、ソースデバイス100は、数多くの証明書102を格納している。ソースデバイスは、バスにコンテントを書き込むデバイスを含み、そしてシンクデバイスは、バスからコンテントを読み込むデバイスを含む。ソースデバイスは、セットトップボックスまたはVCRのような、パススルーおよび／またはプレイバックデバイスを含むことができる。シンクデバイスは、テープまたはテレビのような、記録および／または表示デバイスを含むことができる。他のソースとシンクデバイスを、使用することも可能で、かつそれらは、ラジオ、テーププレーヤ、CD、コンピュータ、などを含むことができる。証明書102の数は、ソースデバイス100が製造された時点で既知であったシンクメーカ104の数に等しい。格納されている各証明書102は、ソースメーカのパブリックキーPub(man[A])を含む。各証明書102は、シンクデバイスの各メーカによって発行される、Sig(man[i]) （ここで、i 0000はシンクメーカの指定を表す）。したがって、ソースデバイス100の証明書のリストは、Cert(Pub(man[A]), Sig(man[i]))の型をとる（ここで、Sig(man[i])は各証明書102で異なっている）。例えば、証明書は、Cert(Pub(man[A]), Sig(man[B]))、およびCert(Pub(man[A]), Sig(man[C]))である。上述したように、他の証明書108は、ソースデバイス100に格納される。証明書108は、ソースデバイス100のメーカ発行のソースデバイス100のパブリックキーCert(Pub(Device), Sig(man [A]))を含む。ソースデバイス100は、この特定デバイス（上述したように、この例では、デバイス100）に対する個別キーとして使用されるユニークプライベートキー110を更に含む。
【００２７】
図2を参照すると判るように、Cによって製造されたシンクデバイス200は、数多くの証明書202を格納する。証明書202の数は、シンクデバイス200が製造された時点で知られていたソースメーカ204の数に等しい。各格納された証明書202は、シンクメーカによって発行される、Sig(man[C])。各証明書202のコンテントは、異なったソースメーカ（メーカAとB）のパブリックキーPub(man[j]) （ここで、jは、ソースメーカ（AとB）の指定）を含む。したがって、シンクデバイス200の証明書のリストは、Cert(Pub(man[j]), Sig(man[C]))の型である（ここで、Pub(man [j])は、各証明書202で異なっている）。シンクデバイス200は、シンクメーカに対するパブリックキー206（この図1では、メーカCのパブリックキー、man[C]Public Key）と、上述の個別プライベートキー208とを含む。
【００２８】
図3に示されるように、コンテントをバス302に配置することができるとソースデバイス100が決定すると、シンクデバイス200はプロトコルを実行する。プロトコルは、シンクデバイス200に、証明書202が、シンクメーカ発行のソースメーカのパブリックキー、Cert(Pub(man[A]), Sig(man[C]))（すなわち、上述の検証チェーンに存在しないリンク）を含むこと可能にさせる。シンクメーカに対するパブリックキー、man[C] Public Keyは、参照番号206で示されている。
【００２９】
図3と4に示されるように、プロトコルは以下を含む。ブロック402において、ソースデバイス100が、行き先シンクデバイス200を決定し、かつシンクデバイス200にソースメーカの識別情報を送出する。ブロック404において、シンクデバイス200は、シンクデバイスのメーカ発行のソースデバイス100のメーカのパブリックキーを含んでいる格納された証明書、すなわち、Cert(Pub(man[source device]), Sig(man[sink device]))が、存在するか否かを決定する。この時証明書が存在すると、肯定応答が、シンクデバイス200に送出され、そしてパスはステップ410に進む。ブロック406において、シンクデバイス200は、ソースデバイスに識別情報を送出する。ブロック408において、ソースデバイス100は、それが、シンクデバイス200のメーカ発行のソースデバイス100のメーカのパブリックキーを含んでいる証明書、すなわち、Cert(Pub(man[source device]), Sig(man[sink device]))を有するか否かを決定する。証明書が存在すると、ソースデバイス100は、シンクデバイス200に証明書を送出し、そしてパスはブロック410に進む。それが存在しない場合には、失敗であり、そしてアボートされる。ブロック410において、シンクデバイス200は、Pub(man[sink device])を使用して、ソースデバイス200のメーカのパブリックキーを含む証明書、Cert(Pub(man[source device]), Sig(man[sink device]))を検証する。検証が成功した場合、動作は続く。そうでない場合、失敗であり、プロトコールをアボートする。
【００３０】
検証が失敗した場合、それは、改変がなされた、またはシステムに不正進入しようとする試みがなされたことを意味する考えることが出来る。しかしながら、異常終了は、新たなメーカが出現した、または既存のメーカがそのパブリックキーを変更したことを意味する可能性もある。この場合には、本発明の付加検証方法が、必要となる。この方法には、ユニークプライベートデバイスキー（例えば、図1のキー110）または外部証明書を使用して、本発明に関連する新たな証明書とパブリックキーとを加えることを始めることを含ませることができる。ブロック412において、新たなソースデバイスまたはシンクデバイスが、導入される。ブロック414において、新たなデバイスは、新たなメーカに関連するパブリックキーを含む証明書を転送する。証明書は、新たなパブリックキーが有効であることを検証する、独立の第三者機関からの検証コードを含むことが好ましい。他の方法と実施例の場合、新たなデバイスが、使用されているまたは新たなメーカに知られている場合には、それを事前に検証するために使用することができる、格納されている所定のコードまたはキーを含む。ブロック416において、新たなパブリックキーを含む新たな証明書が、他のデバイスに格納され、これによりソースデバイスとシンクデバイスの間のインタラクションが可能になる。ソースデバイス、シンクデバイスの何れか、または両方を、新規とすることができ、そしてパブリックキーを有する新たなメーカ証明書を導入する必要があることは、理解すべきである。新たなデバイスを受け入れるために古いデバイスを適合化する手段は、ブロードキャスト転送またはテープ装置または他のメモリー格納装置からのディジタル記録のような記録によって、古いデバイスに新たなキーまたは証明書を導入することによって実行させることができる。この適合化メカニズムは、デバイスおよび／またはインプリメンテーションに依存し、かつデバイス間の通信と格納を含むことができる。
【００３１】
図5を参照すると判るように、新たなメーカがソースデバイス500を生成すると、ソースデバイス500は、既存のシンクデバイス200に証明書502、Cert(Pub(man(NewSource)), Sig(man[C]))を提供することが可能である。本発明によると、シンクデバイス200は、ソースデバイス500とインターフェイスをとるように適合化されている。新たなパブリックキー503も、新たなソースメーカ(NewSource)に対して提供される、Cert(Pub(Device, Sig(NewSource))。同様に、シンクデバイス200は、既存のソースデバイスに証明書を提供し、そしてソースデバイスは、新たなシンクデバイスとインタフェースをとるように適合化させることができる（図6を参照）。
【００３２】
図6に示されるように、新たなメーカがシンクデバイス600を提供すると、新たなシンクデバイス600は、（Aによって製造された）ソースデバイス500 に証明書602、Cert(Pub(man[A]), Sig(man(NewSink)))を提供するであろう。本発明によれば、これによりソースデバイス500は、シンクデバイス600とインタフェースをとるように適合化される。新たなシンクデバイス600は、市場に導入される新たなソースに対する証明書を含むこともできる。例えば、証明書604を新たなシンクデバイス600に含ませることができる。証明書604は、新たなソースデバイス(NewSource)に対するパブリックキーを含む、Cert(Pub(NewSource), Sig(NewSink))。シンクデバイス（またはソースデバイス）の新たなメーカは、既存のメーカのパブリックキーを格納し、かつそれ自身を既存のシンク（ソース）メーカと識別することによって、既存のシンク（ソース）メーカの情報を使用することができることに注意されたい。NewSinkパブリックキーは、参照番号606によって示されている。
【００３３】
図7に示されるように、新たなメーカが新たなシンクデバイス600を提供すると、新たなシンクデバイス600は、新たなシンクデバイス600が、新たなソースデバイス704と対話することができるように、証明書702、Cert(Pub(NewSource), Sig(NewSink))を提供する。ソースデバイス704は、証明書706内に含まれる新たなメーカのパブリックキーPub(NewSource)を含む。本発明によれば、新たなソースデバイスと新たなシンクデバイスの間の欠けた情報は全て、バス708を介したその間の通信を可能とするために、他のデバイスに提供することができる。
【００３４】
各メーカがこれに従い、かつ新たな各デバイスの製品内に含まれる証明書のリストが更新されていれば、プロトコルの異常終了は、ほとんど発生しない。不正侵入者がソースデバイスまたはシンクデバイスの何れかの記憶装置に証明書を挿入することが可能となる前に、その不正侵入者は、メーカのプライベートキーを破壊しなければならないであろう。
【００３５】
民生用電子デバイス証明書管理のための新規な方法とシステムに対する好適な実施例を記述した（このことは、例示であり、かつ何ものも制限するものではない）が、当業者であれば、上記の教示を考慮してこれらに修正と変更を行うことが出来ることは、強調される。したがって、添付の請求項により規定される発明の範囲および精神の範囲内にある、開示された本発明の特定の実施例内で、変更を行うことが出来ることは理解されるべきである。特に特許法の要件に基づいて本発明を詳細に述べたが、現在請求されていてかつ特許権によって保護されることを望む事項は、添付の請求項に記載されている。
【図面の簡単な説明】
【図１】コピー保護のためにそこに格納されている情報を示す本発明のソースデバイスのブロック図である。
【図２】コピー保護のためにそこに格納されている情報を示す本発明のシンクデバイスのブロック図である。
【図３】本発明の、図1のソースデバイスと、バスによって接続されているデバイスを示す図2のシンクデバイスのブロック図である。
【図４】本発明の、ソースデバイスとシンクデバイスの間のインタラクションに対するプロトコルを示すフローチャートである。
【図５】本発明の、図3のシステムに加えられる新たなソースデバイスを示すブロック図である。
【図６】本発明の、図3のシステムに加えられる新たなシンクデバイスを示すブロック図である。
【図７】本発明により加えられた新たなシンクデバイスと新たなソースデバイスを示すブロック図である。
【符号の説明】
100 ソースデバイス
102  証明書
110  プライベートキー
200 シンクデバイス
202  証明書
206  パブリックキー
208  個別プライベートキー
500  ソースデバイス
600  シンクデバイス
【図１】
0004607327.tif 000003
【図２】
0004607327.tif 000004
【図３】
0004607327.tif 000005
【図４】
0004607327.tif 000006
【図５】
0004607327.tif 000007
【図６】
0004607327.tif 000008
【図７】
0004607327.tif 000009