JP2004533194A - データを交換するように構成されたデバイスおよび認証の方法 - Google Patents
データを交換するように構成されたデバイスおよび認証の方法 Download PDFInfo
- Publication number
- JP2004533194A JP2004533194A JP2003508037A JP2003508037A JP2004533194A JP 2004533194 A JP2004533194 A JP 2004533194A JP 2003508037 A JP2003508037 A JP 2003508037A JP 2003508037 A JP2003508037 A JP 2003508037A JP 2004533194 A JP2004533194 A JP 2004533194A
- Authority
- JP
- Japan
- Prior art keywords
- key
- certificate
- public key
- sink
- source
- 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
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/44—Program or device authentication
- G06F21/445—Program or device authentication by mutual authentication, e.g. between devices or programs
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/104—Grouping of entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computing Systems (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Storage Device Security (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Computer And Data Communications (AREA)
Abstract
【課題】第二デバイスとデータを交換するように構成された第一デバイスであって、第二デバイスを透明かつスケーラブルに認証できる、第一デバイスを提供すること。
【解決手段】第二デバイス(130)とデータを交換するように構成された第一デバイス(110)。第一デバイス(110)は、第二デバイス(130)から、第二デバイスの公開鍵(UPK)を有する証明書を受信する。第一デバイスは、次いで、認証局の公開鍵(CAPK)が利用可能である場合には、認証局の公開鍵による受信された証明書の検証が成功したときに、第二デバイス(130)を保護が強いデバイスとして認証し、かつ、ローカルに利用可能な公開鍵(SPK)による受信された証明書の検証が成功したときに、第二デバイス(130)を保護が弱いデバイスとして認証する。第二デバイス(130)は、相互認証を達成するため、同じことを行う。互いに認証されると、デバイス(110, 130)は、セッション鍵を安全に作成してデータを交換できる。データは、関連付けられるDRM規則を有することが望ましい。
【選択図】図１
【解決手段】第二デバイス(130)とデータを交換するように構成された第一デバイス(110)。第一デバイス(110)は、第二デバイス(130)から、第二デバイスの公開鍵(UPK)を有する証明書を受信する。第一デバイスは、次いで、認証局の公開鍵(CAPK)が利用可能である場合には、認証局の公開鍵による受信された証明書の検証が成功したときに、第二デバイス(130)を保護が強いデバイスとして認証し、かつ、ローカルに利用可能な公開鍵(SPK)による受信された証明書の検証が成功したときに、第二デバイス(130)を保護が弱いデバイスとして認証する。第二デバイス(130)は、相互認証を達成するため、同じことを行う。互いに認証されると、デバイス(110, 130)は、セッション鍵を安全に作成してデータを交換できる。データは、関連付けられるDRM規則を有することが望ましい。
【選択図】図１
Description
【技術分野】
【０００１】
本発明は、第二デバイスとデータを交換するように構成された第一デバイスと、遠隔デバイスの認証の方法とに関する。
【背景技術】
【０００２】
ソースデバイスとシンクデバイスの間でデータを交換するときに、これらのデバイスが互いに認証できることが望まれることがしばしばある。互いに認証できれば、ソースは、信頼されるシンクにデータを送信していることを認識し、シンクは、受信するデータの発信元を認識する。このことは、例えば、シンクが新しいソフトウェアをダウンロードする必要があるときのみならず、デジタル著作権管理（DRM：Digital Rights Management）規則に従ってデータを配信するときにも重要である。
【０００３】
デバイスを認証するために公開鍵暗号法を使用できることは、よく知られている。デバイスは、一意の公開鍵と一意の秘密鍵とを持つ。独立した第三者が、デバイスの識別子とデバイスの公開鍵とを有するいわゆる証明書を発行する。別のデバイスは、その証明書をダウンロードすることができ、かつそのデバイスしか解読できないデバイスの公開鍵によって対象内容を暗号化する。暗号解読が成功した場合には、この別のデバイスは、証明書の中に識別されているデバイスと通信していることを知る。
【０００４】
しかしながら、この手法においては、この別のデバイスは、認証する対象のデバイスの証明書を何らかの方法によって取得する必要がある。さらに、この手法は「白か黒」、すなわち認証が成功するか失敗するかのいずれかであり、認証が失敗した場合には、デバイスは相互に信頼される方式においてデータを交換することができない。当然ながら、デバイスは、複数の公開鍵とそれに関連付けられた複数の証明書を持つことができるが、これは複雑であり、管理するのが難しい。さらに重要な点として、この手法では、証明書を発行するために認証局の協力が必要となる。
【０００５】
EP-A-0 592 808は、2つのデバイスの間の鍵配信チャネルを使用する鍵配信メカニズムを開示している。デバイスは、システムの初期化の一部としてインストールされる、鍵を暗号化する鍵を共有する。セッション鍵は、第一デバイスにおいて鍵を暗号化する鍵のもとに暗号化され、第二デバイスにおいて同じ鍵によって暗号解読される（第12欄、第33〜43行）。しかしながら、このように配信されるセッション鍵の場合、デバイス間で認証が行われない。また、このメカニズムは、上記の証明書ベースの手法からこの鍵配信メカニズムに、またはこの逆方向に切り替えるための簡単な方法が存在しないという点において、透明ではない。
【０００６】
US-B-5,949,883は、高トラスト環境と低トラスト環境との間で透明でかつ保護レベルが可変である暗号化システムを開示している。これは、両方の環境に共通の暗号化アルゴリズム（例えば、データ暗号化規格（DES））を選択し、かつ低トラスト環境におけるデバイス内の多数の鍵ビットを固定することによって、行われる。これにより、低トラスト環境におけるデバイスは、高トラスト環境におけるデバイスが暗号解読できる、高トラスト環境におけるデバイスに対するデータを、暗号化することができる。多数の鍵ビットは固定されているので、当局機関は、鍵を強制使用することによって暗号化されたデータにアクセスすることもできる。しかしながら、高トラスト環境におけるデバイスは、高トラスト環境における別のデバイスと通信しているのか、低トラスト環境におけるデバイスと通信しているのかを識別することはできない。
【特許文献１】
EP-A-0 592 808US-B-5,949,883
【発明の開示】
【課題を解決するための手段】
【０００７】
本発明の目的は、第二デバイスを透明かつスケーラブルに認証できる、於て書きの第一デバイスを提供することである。
【０００８】
この目的は、本発明によると、第一デバイスであって、当該第一デバイスが、
- 前記第二デバイスの公開鍵(UPK)の証明書を前記第二デバイスから受信するための受信手段と、
- 認証局の公開鍵(CAPK)が利用可能である場合には、前記認証局の前記公開鍵による前記受信された証明書の検証が成功したときに、前記第二デバイスを保護が強いデバイスとして認証し、かつ、ローカルに利用可能な公開鍵(SPK)による前記受信された証明書の検証が成功したときに、前記第二デバイスを保護が弱いデバイスとして認証する、認証手段と、
を有する第一デバイス、によって達成される。
【０００９】
第一デバイスまたは第二デバイスのいずれかをソース、他方をシンクとすることが出来る。第二デバイスから受信される証明書は、認証局によって署名されているか、または第二デバイスにおいて利用可能な秘密鍵によって署名されている。後者の場合には、第一デバイスは、ローカルに利用可能な対応する公開鍵を持つ必要がある。この場合には安全度は低い。なぜなら、証明書の信頼性と有効性を保証できる独立した第三者が存在しないためである。この理由のため、この場合、第二デバイスは保護が弱いデバイスとして認証される。以上のように概説される認証ステップは、第一デバイスと第二デバイスの両方によって実行されることが望ましい。このようにして、相互認証が達成される。
【００１０】
第一デバイスがシンクであり、かつ認証局の利用可能な公開鍵を持つ場合には、第一デバイスは、この公開鍵を使用して証明書を検証することを試みる。成功した場合には、第一デバイスは、第二デバイス（ソース）が強く保護されていることを知る。その場合、シンクは、両デバイスがデータを安全に(securely)交換できるように、自身が保護が強いデバイスとしてソースに認証させることができる。しかし、認証局の公開鍵を使用して証明書を検証できない場合には、第一デバイスは、ローカルに利用可能な公開鍵によって証明書を検証することによって、弱いモードに切り替えることができる。このように、認証（および暗黙的にデータの保護）はスケーラブルである。
【００１１】
一実施例においては、前記第一デバイスは、前記第一デバイスの公開鍵(UPK)の証明書を前記第二デバイスに送信するための送信手段をさらに有し、前記証明書が、認証局によって署名されているかまたはローカルに利用可能な秘密鍵(SSK)によって署名されているかのいずれかである。このように、第一デバイスは、上記に概説されている相互認証手順を、単に証明書を第二デバイスに送信することによって開始できる。デバイスが認証局によって署名された証明書を持つ場合、ほとんどの場合、そのデバイスは自身が保護が強いデバイスとして認証されるように、この証明書を使用することを望む。しかしながら、このような証明書を持たない場合、証明書を自身で生成して、その証明書を送信する必要がある。
【００１２】
第二デバイスが保護が強いデバイスとして認証されている場合には、送信される証明書は、認証局によって署名された証明書であり、かつ第二デバイスが保護が弱いデバイスとして認証されている場合には、この証明書が、ローカルに利用可能な秘密鍵(SSK)によって署名された証明書であることが、望ましい。
【００１３】
また、第一デバイスが、相互認証手順を開始したデバイスでないこともある。この場合、第一デバイスは、最初に、上述されているように第二デバイスを認証する。これにより、第一デバイスは、第二デバイスの保護レベルを認識し、適切な証明書を送り返すことができる。第一デバイスがシンクであり、第二デバイスを保護が強いソースとして認証したが、認証局によって署名された利用可能な証明書を持たない場合には、この第一デバイスは終了(abort)する。なぜならば、保護が弱いシンクは、保護が強いソースと共に動作できないためである。
【００１４】
さらなる実施例においては、前記認証手段は、前記第二デバイスが保護が弱いデバイスとして認証されかつ前記第一デバイスが保護が強いデバイスである場合に、データの交換を防ぐように構成されている。これにより、強いソースデバイスが価値の高いデータを弱いシンクデバイスに誤って送信することを危惧することなく、デバイスを互いに透明に接続することができる。実際には、保護が強いソースは、認証局の公開鍵によって受信された証明書の検証が失敗した時点で、シンクデバイスを保護が弱いデバイスとして認識できる。
【００１５】
さらなる実施例においては、前記第一デバイスが、
前記セッション鍵と前記ローカルに利用可能な秘密鍵(SSK)の連結の第一ハッシュを計算し、かつ、前記第一ハッシュを前記第二デバイスと交換されるデータを暗号化するための暗号化鍵として使用するように構成されている弱い暗号化鍵生成器、をさらに有する。
【００１６】
データ暗号化鍵生成のこのモードは、単純であるため、ブリッジデバイスまたは処理能力のないストレージデバイスにおける処理量を大幅に低減させるために使用できる。さらに、セッションの間、暗号化鍵を生成するためにソースとシンクの間に通信は必要ない。
【００１７】
前記弱い暗号化鍵生成器は、その後、前記第一ハッシュと前記ローカルに利用可能な秘密鍵の連結の第二ハッシュを計算し、かつ、前記第二ハッシュを前記第一ハッシュの代わりに使用するように、さらに構成されていることが望ましい。これによって、ソースとシンクは定期的に鍵を交換でき、従って、1つのデータ暗号化鍵が危殆化しても、それは一時的な問題にとどまる。ローカルに利用可能な秘密鍵は（おそらくは）まだ秘密であるため、攻撃者は前の鍵と秘密鍵との連結のハッシュを予測できない。
【００１８】
さらなる実施例においては、前記第一デバイスは、
セッション鍵とデジタル著作権管理(Digital Rights Management)データを有するコンテナを構築し、前記コンテナに、前記第一デバイスの前記公開鍵(UPK)に対応する秘密鍵(USK)によって署名し、前記署名されたコンテナを、前記第二デバイスの前記公開鍵(UPK)によって暗号化し、かつ、前記署名されかつ暗号化されたコンテナを前記第二デバイスに送信するための、セッション確立手段、をさらに有する。
【００１９】
セッションは、ソースがコンテンツをシンクに送信する必要が生じるたびに確立できる。セッションは、ソースからシンクへの音楽トラックのダウンロード、CD全体のコピー、フットボールの試合の記録等とすることができる。
【００２０】
相互に認証されたデバイスは、コンテンツの送信が許可されることを検証するために、その両方がデジタル著作権管理データを検査する必要がある。デジタル著作権の記述をコンテナ内で安全に送信することによって、おそらくはコンテンツの形式を理解しないブリッジデバイスまたは処理能力のないストレージデバイスが、コンテンツ自体を処理する必要なしに、そのコンテンツを正しく扱うことができる。アプリケーションに追加情報が必要な場合には、その情報もコンテナに格納できる。
【００２１】
さらなる実施例においては、前記第一デバイスは、
署名されかつ暗号化されたコンテナを前記第二デバイスから受信し、前記コンテナを、前記第一デバイスの前記公開鍵(UPK)に対応する秘密鍵(USK)によって暗号解読し、前記署名を、前記第二デバイスの前記公開鍵(UPK)によって検証し、かつ、セッション鍵とデジタル著作権管理データを前記コンテナから取得するための、セッション確立手段、をさらに有する。
【００２２】
本発明のさらなる目的は、第二デバイスを透明かつスケーラブルに認証する、於て書きの方法を提供することである。
【００２３】
この目的は、本発明によると、認証方法であって、
・ 前記遠隔デバイスの公開鍵(UPK)を有する証明書を前記遠隔デバイスから受信するステップと、
・ 認証局の公開鍵(CAPK)が利用可能である場合には、前記認証局の前記公開鍵による前記受信された証明書の検証が成功したときに、前記遠隔デバイスを保護が強いデバイスとして認証し、かつ、ローカルに利用可能な公開鍵(SPK)による前記受信された証明書の検証が成功したときに、前記遠隔デバイスを保護が弱いデバイスとして認証するステップ、
を有する、方法において、達成される。
【００２４】
本発明は、本発明による方法をプロセッサに実行させるように構成されているコンピュータプログラム製品にも、関する。
【００２５】
本発明の上記およびその他の観点は、図面に示されている実施例を参照しながら、以下に明確に解明される。
【００２６】
すべての図面を通じて、類似または対応する特徴要素には、同じ参照数字が、付されている。図面に示されている特徴要素のいくつかは、一般にはソフトウェア、および（ソフトウェアモジュールまたはオブジェクトなどの）ソフトウェアエンティティを示すものにより実施される。
【発明を実施するための最良の形態】
【００２７】
システムアーキテクチャ
図1は、ソースデバイス110、120とシンクデバイス130、140を有する機器構成100を線図的に示す。以下の説明において、用語「ソースデバイス」または短縮形としての単なる「ソース」は、別のデバイス、すなわち「シンクデバイス」または短縮形としての単なる「シンク」に送信するデータを持つデバイスを意味する。ソースデバイスは、通常、最初にシンクデバイスとの通信セッションを確立する。
【００２８】
ソースデバイスまたはシンクデバイスの実施例は、オーディオ／ビデオ受信機と再生機、セットトップボックス、汎用コンピュータ、移動電話、インターネット機器などを含む。ソースデバイスまたはシンクデバイスが、本文書に説明されるように本発明に従って動作するときには、「SCOPを使用可能な」と言う。SCOPは、スケーラブルなコンテンツ保護(Scalable Content Protection)を表し、本発明はこの保護方式を提供する。
【００２９】
送信されるデータは、任意のデータでよい。望ましい実施例においては、データは、音楽、ビデオ、写真、テキスト、その他の潜在的に価値のあるマテリアルなどのコンテンツ項目を表す。このようなデータは、権限のないアクセスを防ぐため、安全な方式によって転送する必要がある。例えば、データには、データの再生および／またはコピーを制限するデジタル著作権管理（DRM）規則を関連付けることがある。このようなデータは、DRM規則に従いかつこの規則の制限を実施するデバイスの間でのみ送信させる必要がある。
【００３０】
以下の説明においては、保護が強いデバイスと保護が弱いデバイスとが区別される。いま、高い価値を持たず、従って保護が弱いソース上で再生されるコンテンツを考える。この場合、シンクが強い保護を実施する必要が生じる理由はない。なぜなら、ソース自体がその必要がないためである。しかしながら、コンテンツの価値が高い場合には、ソースは強く保護される。従ってシンク側も、悪意のあるユーザが保護が弱いシンクを破ることによってこの価値の高いコンテンツにアクセスすることを防止するために、強く保護される必要がある。
【００３１】
図1において、デバイス110と130は、保護が強いデバイスであり、これに対して、デバイス120と140は、保護が弱いデバイスである。
【００３２】
すべてのデバイス110、120、130、140は、以下の鍵を格納する。
- 一意の秘密鍵(USK)を安全に格納する（読み取る／修正する／交換することはできない）。
- 対応する一意の公開鍵(UPK)を安全に格納する（修正する／交換することはできない）。
- 共有される秘密鍵(SSK)を安全に格納する（読み取る／修正する／交換することはできない）。
- 対応する共有される公開鍵(SPK)を安全に格納する（修正する／交換することはできない）。
【００３３】
保護が強いデバイス110、130は、以下も格納する。
- 一意の公開鍵UPKを含む、認証局によって署名された証明書(CUPK)を安全に格納する（修正する／交換することはできない）。
- 認証局の公開鍵(CAPK)を安全に格納する（修正する／交換することはできない）。
【００３４】
鍵のエスクローをサポートするデバイスは、秘密鍵(ESK)も安全に格納する（読み取る／修正する／交換することはできない）。鍵を安全に格納するため、デバイス110、120、130、140には、それぞれのセキュアメモリ111、121、131、141が設けられる。留意すべき点として、このコンテキストにおける「読み取り」は、デバイスの外側のエンティティによる読み取りを意味する。当然ながら、デバイス自身は、メッセージを暗号解読する、または署名を生成するために秘密鍵を読み取る必要がある。
【００３５】
セキュアメモリは、例えば、スマートカード上に設けることができる。このような場合には、スマートカードは、必要な暗号化、暗号解読、および署名の生成と検証操作を行うことのできるセキュア中央処理装置（CPU）も有することができる。この場合、秘密鍵は、スマートカードが挿入されているデバイスさえも読み取ることができない。
【００３６】
デバイスは、他のデバイスからのメッセージを送信および受信するための、それぞれの送信モジュール112、122、132、142と受信モジュール113、123、133、143とを有する。ソースデバイスとシンクデバイスは、何らかの方法によって互いに接続される。図1には、デバイス110、120、130、140を接続するネットワーク150がある。このネットワークは、例えば、ローカルエリアネットワーク、ケーブルネットワーク、またはワイドエリアネットワーク（例えば、インターネット）でよい。デバイス間の接続は、例えば、IEEE 1394, 802.11、HIPERLAN、またはBluetooth接続を使用しての有線または無線とすることができる。
【００３７】
相互認証
ソースとシンクの間でデータを交換するためには、その前に相互認証を実行する必要がある。保護が弱いデバイスは、保護が強いデバイスと同様に、保護が弱いデバイス同士でデータを交換できる。保護が弱いソースは、保護が強いシンクにデータを送信することもできる。しかしながら、保護が強いソースは、保護が弱いシンクにデータを送信することはできない。
【００３８】
この認証方法は、公開鍵暗号法を使用する。署名と暗号化の両方に、楕円曲線暗号法が使用されることが望ましい。当然ながら、RSAまたはDiffie-Hellmanなどの他の公開鍵システムも使用できる。このような暗号法システムは、この技術分野において周知である。
【００３９】
図2は、ソースデバイスにおける認証の方法を示すフローチャートである。保護が強いシンクは保護が弱いソースと相互動作できるはずであるため、使用する強度をシンクが識別できるように、相互認証を開始するのはソースである。認証を実行するため、ソースデバイスは、それぞれの認証モジュール114、124を有する。
【００４０】
ステップ200において、ソースデバイスは、認証方法を開始する。最初に、210において、認証モジュール114、124は、一意の公開鍵UPKの証明書CUPKが利用可能である否かを判断する。利用可能である場合には、ソースデバイスは強く保護されている。従って、認証モジュール114は、利用可能な証明書CUPKを見つけるが、認証モジュール124は見つけない。認証モジュール114は、240において、送信モジュール112を起動し、証明書CUPKをシンクデバイスに送る。
【００４１】
認証モジュール124は、証明書を送信する代わりに、230において、その一意の公開鍵UPKの証明書を生成し、共有される秘密鍵SSKを使用してこの証明書に署名する。認証モジュール124は、次いで、240において、送信モジュール122を起動し、生成された証明書CUPKをシンクデバイスに送信する。ソースデバイス120は、セキュアメモリ121において利用可能な共有される秘密鍵SSKを使用して署名された、その一意の公開鍵UPKの証明書を持つこともできる。このように、証明書を生成する必要があるのは一度のみである。
【００４２】
次いで、受信モジュール113、123は、250において、シンクデバイスがその公開鍵の証明書によって応答するのを待つ。このような証明書によって応答するときのシンクデバイス側の動作については、図3を参照して後に説明する。
【００４３】
受信モジュール113、123は、シンクデバイスの公開鍵の証明書を受信すると、それを認証モジュール114、124に供給する。認証モジュール114、124は、260において、認証局（CA）の公開鍵CAPKが利用可能か否かを判断する。この認証局は、証明書CUPKを発行した認証局と同じでよいが、必ずしも同じでなくてもよい。認証モジュール114は利用可能な公開鍵CAPKを見つけ、認証モジュール124は見つけない。通常、公開鍵CAPKは、認証局自身または別の認証局によって発行される認証局の証明書の一部である。
【００４４】
認証モジュール114は、270において、受信された証明書を公開鍵CAPKによって検証することを試みる。認証モジュール114は、次いで、280において、この検証が成功するか否かを判断する。成功の場合には、290において、シンクが、保護が強いシンクとして認証される。失敗の場合には、291において、シンクの認証が失敗する。なぜなら、保護が強いソースは、保護が弱いシンクと通信することが許可されないためである。
【００４５】
認証モジュール124は、275において、受信された証明書を共有される公開鍵SPKを使用して検証することを試みる。認証モジュール124は、次いで、285において、この検証が成功するか否かを判断する。成功の場合には、292において、シンクが、保護が弱いシンクとして認証される。失敗の場合には、291において、シンクの認証が失敗する。
【００４６】
図3は、シンクデバイスにおける認証の方法を示すフローチャートである。保護が強いシンクは保護が弱いソースと相互動作できるはずであるため、使用する強度をシンクが識別できるように、相互認証を開始するのはソースである。認証を実行するため、シンクデバイスは、それぞれの認証モジュール134、144を有する。
【００４７】
ステップ300において、シンクデバイスは、認証方法を開始する。最初に、310において、受信モジュール133、143は、ソースデバイスの公開鍵の証明書をソースデバイスから受信する。前述されているように、この証明書は、図2のフローチャートのステップ240において、ソースデバイスによって送信されたものである。
【００４８】
受信モジュール133、143は、ソースデバイスの公開鍵の証明書を受信すると、それを認証モジュール134、144に供給する。認証モジュール134、144は、320において、認証局（CA）の公開鍵CAPKが利用可能か否かを判断する。この認証局は、証明書CUPKを発行した認証局と同じでよいが、必ずしも同じでなくてもよい。認証モジュール134は、利用可能な公開鍵CAPKを見つけるが、認証モジュール144は見つけない。
【００４９】
次いで、認証モジュール134は、330において、受信された証明書を公開鍵CAPKを使用して検証することを試みる。認証モジュール134は、次いで、340において、この検証が成功するか否かを判断する。成功の場合には、ソースが、保護が強いソースとして認証され、認証モジュールはステップ380に進む。失敗の場合には、認証モジュール134はステップ350に進む。
【００５０】
認証モジュール134、144は、350において、受信された証明書を共有される公開鍵SPKを使用して検証することを試みる。認証モジュール134、144は、次いで、360において、この確認が成功するか否かを判断する。成功の場合には、ソースが、保護が弱いソースとして認証される。失敗の場合には、375において、ソースの認証が失敗する。
【００５１】
保護が弱いソースとしてのソースの認証に成功すると、認証モジュール134、144は、370において、一意の公開鍵UPKの証明書を生成し、共有される秘密鍵SSKを使用してこれに署名する。
【００５２】
380において、認証モジュール134、144は、それぞれの送信モジュール132、142を起動し、生成された証明書をソースデバイスに送信する。シンクデバイス130、140は、セキュアメモリ131、141において利用可能な共有される秘密鍵SSKを使用して署名された、その一意の公開鍵UPKの証明書を持つこともできる。このように、証明書を生成する必要があるのは一度のみである。
【００５３】
ソースデバイスとシンクデバイスそれぞれにおいて実行される認証方法の間の相互作用を明確にするために、保護が強いソースおよびシンクと保護が弱いソースおよびシンクの4種類の可能な組合せと、それぞれの場合における処理を以下に示す。
【００５４】
保護が強いソースから保護が強いシンク
保護が強いソースは、認証局によって署名された自身の証明書(CUPK)を送信する。保護が強いシンクは、この証明書を受信し、認証局の公開鍵(CAPK)を使用してこれを検証する。署名が一致しない場合には、保護が強いシンクは、共有された公開鍵(SPK)を使用して証明書を検証する。それでも署名が一致しない場合には、保護が強いシンクはプロトコルを終了する。
【００５５】
しかしながら、最初の検証時に署名が一致する場合には、保護が強いシンクは、ソースが強い保護を使用していることを知り、認証局によって署名された証明書(CUPK)を送信する。保護が強いソースはこれを受信し、認証局の公開鍵(CAPK)を使用してこれを検証する。署名が一致しない場合には、このプロトコルは終了する。一致する場合には、両方のデバイスが強い保護について認証され、両方のデバイスが、他方のデバイスの一意の公開鍵(UPK)を持つ。
【００５６】
保護が弱いソースから保護が強いシンク
保護が弱いソースは、最初に、その一意の公開鍵(UPK)の証明書を作成し、共有される秘密鍵(SSK)を使用してこれに署名する。この作成ステップは、リソースを節約するために事前に行うことができる。この証明書は、保護が強いシンクに送信される。保護が強いシンクは、この署名された証明書を受信し、認証局の公開鍵(CAPK)を使用してこれを検証する。署名が一致しない場合には、保護が強いシンクは、共有される公開鍵(SPK)を使用して証明書を検証する。それでも一致しない場合には、保護が強いシンクは、このプロトコルを終了する。
【００５７】
しかしながら、署名が一致する場合には、保護が強いシンクは、ソースが弱い保護をサポートするのみであることを認識し、自身の一意の公開鍵(UPK)の証明書を作成し（リソースを節約するために事前に作成することもできる）、共有される秘密鍵(SSK)を使用してこれに署名する。この証明書は、ソースに送信される。ソースは、シンクからこの証明書を受信すると、共有される公開鍵(SPK)を使用してこれを検証する。署名が一致しない場合には、ソースはこのプロトコルを終了する。一致する場合には、両方のデバイスが弱い保護について認証され、両方のデバイスが、他方のデバイスの一意の公開鍵(UPK)を持つ。
【００５８】
保護が弱いソースから保護が弱いシンク
保護が弱いソースは、最初に、その一意の公開鍵(UPK)の証明書を作成し、共有される秘密鍵(SSK)を使用してこれに署名する。この作成ステップは、リソースを節約するために事前に行っても良い。この証明書は、保護が弱いシンクに送信される。保護が弱いシンクは、この署名された証明書を受信し、共有される公開鍵(SPK)を使用してこれを検証する。署名が一致しない場合には、保護が弱いシンクは、このプロトコルを終了する。
【００５９】
しかしながら、署名が一致する場合には、保護が弱いシンクは、その一意の公開鍵(UPK)の証明書を作成し、共有される秘密鍵(SSK)を使用してこれに署名する。この作成ステップは、リソースを節約するために事前に行うことができる。この証明書は、ソースに送信される。ソースは、シンクからこの証明書を受信すると、共有される公開鍵(SPK)を使用してこれを検証する。署名が一致しない場合には、保護が弱いソースは、このプロトコルを終了する。一致する場合には、両方のデバイスが弱い保護について認証され、両方のデバイスが、他方のデバイスの一意の公開鍵(UPK)を持つ。
【００６０】
保護が強いソースから保護が弱いシンク
保護が強いソースは、認証局によって署名された証明書(CUPK)を直接送信する。保護が弱いシンクは、この証明書を受信し、共有される公開鍵(SPK)を使用してこれを検証する。署名が一致しない場合には、保護が強いシンクはこのプロトコルを終了する。従って、認証は必ず失敗する。このように、保護が強いソースは、保護が弱いシンクを認証することはなく、従ってソースからシンクにデータは送信されない。
【００６１】
セッションの確立
ソースとシンクが相互に認証されると、セッションを確立する必要がある。一般には、認証は、ソースとシンクが互いに最初に接続されるときに実行する必要があるのに対し、セッションは、ソースがコンテンツをシンクに送信する必要が生じるたびに確立する必要がある。従って、セッションは、ソースからシンクへの音楽トラックのダウンロード、CD全体のコピー、フットボールの試合の記録等とすることができる。
【００６２】
各セッションの最初に、コンテナがソースからシンクに安全に転送される。このコンテナには、ソースによってランダムに選択されるセッション鍵SKが含まれ、さらに、アプリケーションがデジタル著作権管理（DRM）システムであるか否かに応じて、そのセッションの間に送信されるコンテンツに関連付けられるデジタル著作権の記述も含まれる。
【００６３】
相互に認証されたデバイスは、コンテンツの送信が許可されるか否かを検証するために、その両方がこれらのデジタル著作権を検査する必要がある。この検査の方法について、以下に具体的に示す。コンテナ内でデジタル著作権の記述を安全に送信することによって、おそらくはコンテンツの形式を理解しないブリッジデバイスまたは処理能力のないストレージデバイスが、コンテンツ自体を処理する必要なしに、そのコンテンツを正しく扱うことができる。アプリケーションが追加の情報を必要とする場合には、その情報もコンテナに格納できる。
【００６４】
図4は、ソースデバイスにおける、シンクデバイスとの通信セッションを確立する方法を示すフローチャートである。セッションの確立は、セッション確立モジュール115、125によって管理される。
【００６５】
この方法は、ステップ400から開始される。最初に、410において、セッション確立モジュール115、125は、このセッションにおいて交換されるデータがDRM規則に従う必要があるか否かを検証する。必要がある場合には、411において、データの著作権の記述が取得され、412において、そのデータを実際にシンクに送信できるか否かが検証される。この検証が失敗した場合には、セッション確立モジュール115、125は、413においてこのセッションを終了する。
【００６６】
ステップ420において、この特定のセッションのセッション鍵として機能する乱数SKが選択される。暗号法の分野において周知であるように、予測することが非常に難しい数をセッション鍵として選択することが重要である。この数SKは完全な乱数が理想的であるが、これは非常にコストがかかり、実現することが難しいため、数SKは通常は、擬似ランダムに生成される。セッション鍵SKのサイズは、保護方式の選択される強度に応じて、適切に構築された表に従って変化する。
【００６７】
次いで、430において、このセッションに対して鍵のエスクローを使用する必要があるか否かが判断される。鍵のエスクローの1つの手法は、本発明と同じ出願人による国際特許出願PCT/EP/01/11722（社内整理番号PHNL000558）に説明されている。
【００６８】
相対的に小さいセッション鍵SKと、これより長い秘密鍵ESKとを混合し、その結果の鍵RKをセッション鍵として使用することによって、悪意のある（ESKを知らない）ユーザにとっては、この保護方式を破ることはより難しくなるが、（ESKを知っている）関係当局またはコンテンツの所有者にとっては、より容易になる。
【００６９】
しかしながら、これにより、この保護方式にセキュリティ上の脅威が生まれることは、注目すべきである。悪意のあるユーザは、セキュリティレベルの低い関係当局／コンテンツ所有者から盗むことによって、またはそこにアクセスする膨大な人のうちの一人から不正に聞き出すことによって、最終的に秘密鍵ESKを見つけることができると考えるのが妥当である。鍵のエスクローを使用する必要がある場合には、440において、エスクロー鍵ESKが乱数SKと混合され、その結果がセッション鍵として使用される。
【００７０】
ステップ450において、セッション確立モジュール115、125は、コンテナを生成する。このコンテナには、セッション鍵SKが含まれ、さらに、アプリケーションがデジタル著作権管理（DRM）システムであるか否かに応じて、そのセッションの間に送信されるコンテンツに関連付けられるデジタル著作権の記述も含まれる。
【００７１】
セッション確立モジュール115、125は、次いで、460において、それぞれの一意の秘密鍵USKを使用してコンテナに署名し、470において、シンクの一意の公開鍵UPKを使用してその結果を暗号化する。この公開鍵UPKは、図2を参照しながら前述されているように、ソースが受信して認証したものである。次いで、署名されかつ暗号化されたコンテナが、480において、シンクに送信される。490において、この方法が終了する。
【００７２】
図5は、シンクデバイスにおける、ソースデバイスとの通信セッションを確立する方法を示すフローチャートである。シンクデバイス130、140におけるセッションの確立は、セッション確立モジュール135、145によって管理される。この方法は、500から開始される。セッション確立モジュール135、145は、510において、署名されかつ暗号化されたコンテナを受信する。
【００７３】
セッション確立モジュール135、145は、署名されかつ暗号化されたコンテナを受信すると、520において、最初に自身の一意の秘密鍵USKを使用してこれを暗号解読する。次いで、セッション確立モジュール135、145は、530において、図3を参照しながら前述されているように受信されかつ認証された一意の公開鍵UPKを使用して、証明書を検証する。
【００７４】
次いで、540において、セッション鍵SKと、セッションの間にシンクが受信するコンテンツに関連付けられているデジタル著作権の記述（存在する場合）とを取得するために、コンテナが調べられる。
【００７５】
次いで、セッション確立モジュール135、145は、550において、デジタル著作権が存在するか否かを判断する。存在する場合には、セッション確立モジュール135、145は、551において、これらの著作権をコンテナから取得し、552において、このセッションの間にデータを送信するための著作権が存在するか否かを検証する。存在しない場合には、553において、このセッションは許可されない。
【００７６】
デジタル著作権が見つからない場合、または見つかった著作権に、このセッションの間にデータを送信するための著作権が含まれる場合には、560において、乱数SKが取得され、セッション鍵として使用可能になる。570において、この方法が終了する。
【００７７】
送信されるデータの暗号化
ソースからシンクに送信されるデータは、段数と暗号化鍵EKのサイズが保護方式の必要な強度に応じて変化する、強いブロック暗号を使用して暗号化される。1セッションの間に暗号化鍵EKが更新される頻度も、保護方式の必要な強度に依存する。データを暗号化するため、デバイス110、120、130、140には、それぞれの暗号化／暗号解読モジュール117、127、137、147が設けられる。
【００７８】
望ましい一実施例の場合、暗号化／暗号解読モジュール117、127、137、147は、小さく高速で使用料がかからないTEA（Tiny Encryption Algorithm）を使用して、データをブロック暗号として暗号化および暗号解読する。このアルゴリズムは、Springer-Verlag社のComputer Science誌の「Lecture Notes」の第1008回（1994年、p.363〜366）「TEA, a Tiny Encryption Algorithm（TEA：Tiny Encryption Algorithm）」（David J. Wheeler氏、Roger M. Needham氏）に説明されている。また、インターネット上のhttp://vader.brad.ac.uk/tea/tea.shtmlにも記載されている。
【００７９】
暗号化されたデータを交換するためには、その前に暗号化鍵を生成する必要がある。本文書には、鍵生成の2種類のモードが定義されている。保護が強いデバイスは、新しい暗号化鍵が必要になるたびに、情報を相互に交換する。保護が弱いデバイスは、非常に単純な方式を使用して、前のセクションにおいて安全に交換されたセッション鍵から連続的な暗号化鍵を生成する。保護が強いデバイスは、すべて、弱い暗号化鍵の生成もサポートする必要がある。これによって、保護が弱いソースが保護が強いシンクと相互動作することができる。
【００８０】
弱い暗号化鍵の生成
図6は、ソースデバイスとシンクデバイスが、保護が弱いデバイスとして互いに相互認証済みであるときに使用される鍵生成の方法を示すフローチャートである。保護が弱いデバイス120、140には、この方法を実行する、それぞれの鍵生成モジュール126、146が設けられる。この方法は、600から開始される。最初の生成時には、610において、セッション鍵SKが、共有される秘密鍵SSKと連結される。
【００８１】
次いで、620において、この連結がハッシュ関数への入力として使用される。暗号法として強力な多数のハッシュ関数が、この分野において公知である。一実施例においては、上述されているTEA（Tiny Encryption Algorithm）が、周知のDavies-Mayerハッシュ関数と組み合せて使用される。
【００８２】
ハッシュ関数の出力のサイズは、（使用される保護方式の強度に応じて）可変である。630において、この出力は、第一暗号化鍵EK1として使用される。新しい暗号化鍵が必要となるたびに、セッション鍵SKと共有される秘密鍵SSKを連結する代わりに、前の暗号化鍵EKn-1が、共有される秘密鍵SSKを使用してハッシュ処理される。セッションの間に暗号化鍵を生成するのに、ソースとシンクの間の通信は必要ない。
【００８３】
暗号化鍵の生成のこのモードを使用することで、ブリッジデバイスまたは処理能力のないストレージデバイスにおける処理量を大幅に低減させることができる。
【００８４】
強い暗号化鍵の生成
図7は、両方のデバイスが保護が強いデバイスとして相互に認証済みであるときに使用される鍵生成の方法を示すフローチャートである。保護が強いデバイス110、130には、この方法を実行する、それぞれの鍵生成モジュール116、136が設けられる。この方法は、700から開始される。
【００８５】
710において、ソース内の鍵生成モジュール116とシンク内の鍵生成モジュール136の両方が、セッション鍵と同じサイズの、それぞれRsrc、Rsnkと呼ばれる乱数を生成する。
【００８６】
720において、この乱数が、セッション鍵SKに対してXOR処理され、730において、他方に送信される。740において、鍵生成モジュール116、136の両方は、セッション鍵SKに対してXOR処理された、他方の乱数を受信する。両方の鍵生成モジュールは、他方の実際の乱数を得るために、750において、受信した乱数をセッション鍵SKに対して再びXOR処理する。この時点で、両方の鍵生成モジュールは、両方の乱数を知る。
【００８７】
ソースにおいては、760において、乱数Rsnkがシンクの公開鍵UPKと連結される。同様に、シンクにおいては、760において、乱数Rsrcがソースの公開鍵UPKと連結される。次いで、770において、この連結が、ハッシュ関数に送られる。
【００８８】
さらに、シンクにおいては、765において、乱数Rsnkがシンクの公開鍵UPKと連結される。同様に、ソースにおいては、765において、乱数Rsrcがソースの公開鍵UPKと連結される。次いで、775において、この連結が、ハッシュ関数に送られる。
【００８９】
ハッシュ関数の出力サイズは、使用される保護方式の強度に応じて可変である。次いで、780において、この結果がXOR処理され、暗号化鍵EKが生成される。新しい暗号化鍵EKが必要となるたびに、このプロセスが繰り返される。この鍵生成方法は、図5を参照しながら説明した方法よりも強力であるが、XOR処理されるセッション鍵を交換するために、ソースとシンクの間の通信が必要となる。
【００９０】
鍵生成のこの方法は、Bluetooth仕様バージョン1.0A、第14.2.2.4項、p155〜156に示されている、組み合わせ鍵を生成する手順に、その一部が基づいている。
【００９１】
コンテンツの送信
ソースが、ブリッジデバイス（例えば、IEEE1394からUSBへのブリッジ）を経由することによってコンテンツをシンクに安全に送信する必要がある場合には、ソースとブリッジ（シンクとして機能する）の間のリンクと、ブリッジ（この場合はソースとして機能する）とシンクの間の第二リンクを確立する必要がある。
【００９２】
このことは、コンテンツがブリッジの中で暗号解読され、再び暗号化されることを意味する。これを回避するため、セッションの確立が以下のように起こる場合には、上記の暗号化鍵生成方法を使用できる。すなわち、ソースとブリッジは、図2と3を参照しながら前述されているように両方のデバイスが相互に認証された後に、図4と5を参照しながら前述されているようにセッションを確立する。
【００９３】
しかしながら、ブリッジとシンクは、（相互に認証された後に）セッションを確立するが、このセッションにおいては、セッション鍵SKがブリッジによってランダムに選択されるのではなく、ブリッジがソースから受信したコンテナから取得される。このようにして、ソースとシンクの両方が同じセッション鍵SKを持ち、ブリッジは、自身を通過するコンテンツを暗号解読してから再び暗号化する必要がない。
【００９４】
処理能力のないストレージデバイスは、コンテンツが特定の時間だけ存在した後にシンクに渡されるブリッジとみなすことができる。従って、ストレージデバイスには、ソースから受信された暗号化されたコンテンツが、シンクから受信されたコンテナと共に格納される。このコンテナを安全に格納するために、ストレージデバイスは、その一意の公開鍵UPKによってコンテナを暗号化する。コンテンツを再送信するときに、ストレージデバイスは、その一意の秘密鍵USKによってセキュアコンテナを暗号解読し、ソースによって選択されたセッション鍵SKを取得する。次いで、ストレージデバイスは、シンクとのセッションを（相互認証後に）確立し、乱数を選択する代わりに、取得されたセッション鍵SKを使用する。
【００９５】
ブリッジデバイスとストレージデバイスのいずれも、関連付けられるデジタル著作権を取得して解釈するために、コンテンツの形式を理解できる必要がないことは、留意すべきである。さらに、ソースとシンクの間のブリッジデバイスまたは処理能力のないストレージデバイスの最大数は、デジタル著作権によってこの種類の送信が許可されるならば、上限がない点も留意すべきである。
【００９６】
図8は、SCOPを使用可能なソースデバイス810（例えば、デジタルオーディオプレイヤー）が、SCOPを使用可能なシンク820（例えば、デジタル受信機）に有線接続され、安全に送信されるコンテンツがコピー不可である、機器構成の一実施例を線図的に示す。この場合には、シンク820が記録機能を持たないため、ソースからシンクへの送信が許可される。
【００９７】
いま、消費者が、自分のオーディオシステムからすべての配線を取り除くことを望むとする。この消費者は、例えば、IEEE 1394とBluetoothの間で双方向に変換できる、SOCPを使用可能な2つのブリッジデバイス830、831を購入することによって、これを実現する。この時点で、この消費者のシステムには、ソース810からブリッジ830、ブリッジ830からブリッジ831、ブリッジ831からシンク820、という3つのリンクが存在する。
【００９８】
コピー不可コンテンツの送信時、ソース810は、送信先のシンク820が記録デバイスなのか受信機なのかを区別できないため、この送信に関して正しい決定を下すことができない。従って、ソース810は、チェーン内の相互に認証されている次のデバイスにこの決定を任せて、前述されている方法によって、このコンテンツを安全に送信する。しかしながら、有線から無線へのブリッジ830も、この決定を下すことができず、この場合にも、相互に認証されている次のデバイスに、（コンテンツの暗号解読と再暗号化を行う必要なしに）コンテンツを安全に渡す。
【００９９】
しかしながら、無線から有線へのブリッジ831は、自身がレコーダーに接続されているのか受信機に接続されているのかを認識し、コンテンツに関連付けられているデジタル著作権の記述をコンテナから取得してそれを検査することができる。送信が許可される場合には、ブリッジ831は、暗号化されたコンテンツをシンク820に渡し、この場合にも、コンテンツの暗号解読と再暗号化を行う必要はない。
【０１００】
ブリッジデバイス830、831は、関連付けられているデジタル著作権を取得するとき、またはコンテンツを暗号解読および暗号化することによって処理するときにさえも、コンテンツの形式を知る必要がないため、保護のために加わるコストは最小限である。このアプリケーションをさらに拡張するために、SCOPを使用可能な無線から有線への第三のブリッジを、別の部屋の中に位置する、SCOPを使用可能な別の受信機に接続できる。SCOPを使用可能な無線から有線へのこの第三のブリッジは、有線から無線へのブリッジによって相互に認証され、単に、このコンテンツ保護方式における最初のブリッジと同じように機能する。
【０１０１】
このようにして、ソース810は、各SCOPリンクにおいて連続的な暗号解読／再暗号化を行う必要なく、かつ、DRMシステムを危殆化することなく、1つの有線出力を使用して、有線入力を持つ複数の受信機に無線式に接続される。この場合、完全に透明なブリッジは使用できず、なぜなら、ソース810は1つの出力のみを有するため、相互認証、セッション確立、および暗号化の間に複数のシンクを扱うことができないためである。しかしながら、SCOPを使用可能な有線から無線へのブリッジは、各SCOPリンクにおいて暗号解読／再暗号化を行う必要なしに複数の相互認証とセッション確立を扱うように明確に設計されている。
【０１０２】
デジタル著作権管理
本発明は、デジタルオーディオプレイヤーとレコーダーなど、DRMを使用可能なデバイスにおいても使用できる。その場合、デバイスは、交換するデータに対してユーザが持つデジタル著作権を認識する必要がある。例えば、デジタルオーディオプレイヤーがデジタルオーディオ受信機に接続されている場合には、コンテンツはSCOPリンクを介して安全に一回送信する必要がある。そのデジタルオーディオプレイヤーがデジタルオーディオレコーダーに接続されているか、またはコンテンツがすでに一度再生された場合には、そのコンテンツはSCOPリンクを介して送信されてはならない。
【０１０３】
本発明の実施例においては、再生著作権と記録著作権という2種類のデジタル著作権が区別されている。当然ながら、これ以外のタイプの著作権も可能であり、本発明は、この実施例に定義されている著作権に制限されない。
【０１０４】
再生著作権
ユーザは、再生することを望むコンテンツに対して以下の著作権のうちの1つを持つ。
【０１０５】
- 時間制限付き再生：コンテンツは、最初のx秒のみ再生できる。
【０１０６】
- 回数制限付き再生：コンテンツは、特定のプレイヤー上で指定された回数のみ再生でき、それ以降はそのプレイヤー上で再生できなくなる。
【０１０７】
- 期間制限付き再生：コンテンツは、特定の期間が終了するまでの間のみ再生できる。
【０１０８】
- 制限なし再生：コンテンツは、永久に回数の制限なく最後まで再生できる。
【０１０９】
- 再生不可：コンテンツは、（それ以上）再生できない。
【０１１０】
一般には、ユーザのデジタル再生著作権は、同じままではなく別のタイプに変化する。例えば、ユーザが時間制限付き再生と再生不可著作権を無料で受け取り、制限なし再生または回数制限付き再生著作権を購入することを望むことがある。回数制限付き再生著作権は、ユーザがコンテンツを指定された回数だけ再生した後に再生不可著作権に変化することもある。デジタル再生著作権は、組み合わせることもできる（例えば、時間制限付き再生と期間制限付き再生）。
【０１１１】
記録著作権
ユーザは、記録することを望むコンテンツに対して以下の著作権のうちの1つを持つ。
【０１１２】
- 回数制限付き再生：コンテンツは、指定された回数のみ記録でき、それ以降は記録できなくなる。
【０１１３】
- 制限なし記録：コンテンツは、回数の制限なしに記録できる。
【０１１４】
- 記録不可：コンテンツは、（それ以上）記録できない。
【０１１５】
一般には、デジタル記録著作権によって記録が許可される場合には、コンテンツは、オリジナルの媒体上に見つかるデジタル再生著作権と共に新しい媒体上に記録される。しかしながら、コンテンツの記録を許可する新しいデジタル記録著作権であって、記録される媒体上でのデジタル再生著作権がオリジナルの媒体のデジタル再生著作権と異なるデジタル記録著作権を定義することは有用かもしれない。例えば、ユーザが特定のコンテンツの再生著作権を持たないときに、さらに配信できるように回数制限付き再生著作権を付してそのコンテンツをコピーすることを許可することは有用かもしれない。
【０１１６】
従って、ユーザは、以下のオプションの記録著作権を持つことができる。
【０１１７】
- 配信時記録：コンテンツは、回数の制限なしに記録できるが、デジタル再生著作権は、オリジナルの媒体からコピーされる代わりに、この記録著作権によって指定される。
【０１１８】
ここまでの説明においては、ソースデバイスとシンクデバイスとが区別されている。シンクは、さらに、レコーダー、受信機、またはブリッジに分類できる。2つのデバイスが相互に認証されると、ソースは、自身が接続されているシンクのタイプを認識する。この場合の組み合わせとして、ソースからレコーダー、ソースから受信機、ソースからブリッジ、が可能である。
【０１１９】
ソースからレコーダー
セッションを確立している間、ソースは、そのセッションの間に送信されるコンテンツに対してユーザが持つデジタル記録著作権を調べる。通常の記録が許可される場合には、ソースは、ユーザのデジタル再生著作権とデジタル記録著作権とを、「セッションの確立」に説明されている二重に暗号化されたコンテナによって、レコーダーに送信する。通常の記録が許可されないがそのコンテンツに対する配信時記録著作権をユーザが持つ場合には、ソースは、配信時記録著作権と、その配信時記録著作権によって指定されるデジタル再生著作権とを、レコーダーに送信する。
【０１２０】
レコーダー（シンク）は、ユーザのデジタル記録著作権を二重に確認し、ソースと同じ結論（記録は許可される）に達する。セッションが確立されると、コンテンツはSCOPリンクを通じて安全に送信され、セッションの記録が進行する。受信されたデジタル再生著作権と、（シンクによって）更新されたデジタル記録著作権が、新しい媒体上に記録される。
【０１２１】
ソースから受信機
セッションを確立している間、ソースは、そのセッションの間に送信されるコンテンツに対してユーザが持つデジタル再生著作権を調べる。再生が許可される場合には、ソースは、ユーザのデジタル再生著作権と記録不可著作権とを、二重に暗号化されたコンテナによって送信する。受信機は、ユーザのデジタル再生著作権を二重に確認し、同じ結論（再生は許可される）に達する。セッションが確立されると、ソースは、コンテンツに対してユーザが持つデジタル再生著作権を更新する。更新が行われた後、コンテンツはSCOPリンクを通じて安全に送信され、受信機によるセッションの再生が進行する。
【０１２２】
ソースからブリッジ
ソースは、ブリッジに接続されているシンクのタイプを識別できないため、認証されているブリッジとのセッションを確立し、コンテンツに対してユーザが持つデジタル再生著作権とデジタル記録著作権とを、二重に暗号化されたコンテナによって、安全に送信する。ブリッジは、自身が接続されているシンクのタイプを識別でき、従って、シンクがレコーダーである場合には「ソースからレコーダー」に説明されている方法、シンクが受信機である場合には「ソースから受信機」に説明されている方法、シンクがさらに別のブリッジである場合には「ソースからブリッジ」に説明されている方法を、（ソースとして）適用することによって、デジタル著作権を管理することができる。
【０１２３】
鍵の破棄
破棄は、認証の間に強い保護を使用するデバイスが危殆化された場合にのみ推奨される。その場合には、権限を与えられたエンティティが、破棄されるデバイスの公開鍵UPKを含む破棄証明書を生成し、認証局の私有鍵によってこれに署名する。次いで、この破棄証明書は、新しくリリースされる媒体（例えば、CD、DVD）を通じるか、通信チャネル（例えば、インターネット、ブロードキャストネットワーク）を通じるか、またはデバイス間の相互接続そのものを通じて、フィールド内のデバイスに配布される。
【０１２４】
デバイスは、このような破棄証明書を受信すると、認証局の公開鍵CAPKを使用してこれを検証し、安全に格納する。相互認証の間、デバイスは、格納されている破棄証明書を検査することによって、他のデバイスから受信した公開鍵が破棄されていないかを確認する。留意すべき点として、この場合の語「デバイス」は、広義に使用される。例えば、インターネット上のコンテンツ配信サービスを破棄することもでき、これによって、悪意のあるユーザが、危殆化された一連の鍵を認証と暗号化に使用することによって、インターネット上に違法なコンテンツ配信サービスを確立することを防止する。
【０１２５】
別の例としては、シンクとして機能するPC上の危殆化されたソフトウェアプレイヤーを破棄することによって、この危殆化されたプレイヤーをインターネットを通じてさらに配信することを無意味にする。さらに、デバイスのグループの破棄も、上述されているのと同じ方法によってサポートされ、この場合、危殆化された一連のデバイスのグループIDを含むグループ破棄証明書を生成して配布することによって、これらのデバイスすべてが1つの破棄証明書を使用して破棄される。
【０１２６】
保護が弱いデバイスは、破棄をサポートすべきではない。なぜなら、破棄証明書は共有される私有鍵を使用して署名する必要があり、この鍵は、デバイス内に隠されていることによってのみ悪意のあるユーザから保護されるためである。この鍵が知られてしまうと、悪意のあるユーザが、保護が弱いデバイスの偽の破棄証明書を作成し、それをフィールド内のデバイスすべてにウイルス方式に拡散させることによって、相当な数の完全に合法のデバイスを動作不能にすることができる。この場合、危殆化された弱い保護方式においては一部のユーザが違法なコピーを行うことができるという元の問題は、正当なユーザのデバイスが偽の破棄証明書によって汚染され、動作不能となったデバイスがメーカーに戻されるというさらに悪い問題に発展する。
【０１２７】
留意すべき点として、上記の実施例は、本発明を制限するものではない。当業者は、添付される請求項の範囲を逸脱することなく、多数の代替の実施例を設計できるであろう。
【０１２８】
請求項において、カッコ内の参照記号は請求項の制限として解釈されないものとする。語「有する」は、請求項に記載されている以外の要素またはステップの存在を除外するものではない。要素の前の語「a」または「an」は、このような要素が複数存在することを除外するものではない。
【０１２９】
本発明は、いくつかの個別の要素を有するハードウェアによって、または適合するようにプログラムされたコンピュータによって、実施できる。デバイスの請求項においては、いくつかの手段を同一のハードウェアまたはソフトウェア要素により実施できる。
【図面の簡単な説明】
【０１３０】
【図１】ソースデバイスとシンクデバイスを有する機器構成の実施例を線図的に示す。
【図２】ソースデバイスにおける認証の方法を示すフローチャートである。
【図３】シンクデバイスにおける認証の方法を示すフローチャートである。
【図４】ソースデバイスにおける、シンクデバイスとの通信セッションを確立する方法を示すフローチャートである。
【図５】シンクデバイスにおける、ソースデバイスとの通信セッションを確立する方法を示すフローチャートである。
【図６】保護が弱いデバイスとして相互に認証されたデバイスにおける、鍵生成の方法を示すフローチャートである。
【図７】保護が強いデバイスとして相互に認証されたデバイスにおける、鍵生成の方法を示すフローチャートである。
【図８】ソースデバイスと、シンクデバイスと、2つのブリッジデバイスとを有する機器構成の実施例を線図的に示す。
【符号の説明】
【０１３１】
100 機器構成
110、120 ソースデバイス
130、140 シンクデバイス
111、121、131、141 セキュアメモリ
112、122、132、142 送信モジュール
113、123、133、143 受信モジュール
114、124、134、144 認証モジュール
115、125、135、145 セッション確立モジュール
116、126、136、146 鍵生成モジュール
117、127、137、147 暗号化／暗号解読モジュール
150 ネットワーク
810 ソース
820 シンク
830、831 ブリッジデバイス
USK 一意の秘密鍵
UPK 一意の公開鍵
SSK 共有される秘密鍵
SPK 共有される公開鍵
CAPK 認証局の公開鍵
ESK 秘密鍵
SK セッション鍵
CUPK 公開鍵UPKの証明書
CAPK 認証局（CA）の公開鍵
【０００１】
本発明は、第二デバイスとデータを交換するように構成された第一デバイスと、遠隔デバイスの認証の方法とに関する。
【背景技術】
【０００２】
ソースデバイスとシンクデバイスの間でデータを交換するときに、これらのデバイスが互いに認証できることが望まれることがしばしばある。互いに認証できれば、ソースは、信頼されるシンクにデータを送信していることを認識し、シンクは、受信するデータの発信元を認識する。このことは、例えば、シンクが新しいソフトウェアをダウンロードする必要があるときのみならず、デジタル著作権管理（DRM：Digital Rights Management）規則に従ってデータを配信するときにも重要である。
【０００３】
デバイスを認証するために公開鍵暗号法を使用できることは、よく知られている。デバイスは、一意の公開鍵と一意の秘密鍵とを持つ。独立した第三者が、デバイスの識別子とデバイスの公開鍵とを有するいわゆる証明書を発行する。別のデバイスは、その証明書をダウンロードすることができ、かつそのデバイスしか解読できないデバイスの公開鍵によって対象内容を暗号化する。暗号解読が成功した場合には、この別のデバイスは、証明書の中に識別されているデバイスと通信していることを知る。
【０００４】
しかしながら、この手法においては、この別のデバイスは、認証する対象のデバイスの証明書を何らかの方法によって取得する必要がある。さらに、この手法は「白か黒」、すなわち認証が成功するか失敗するかのいずれかであり、認証が失敗した場合には、デバイスは相互に信頼される方式においてデータを交換することができない。当然ながら、デバイスは、複数の公開鍵とそれに関連付けられた複数の証明書を持つことができるが、これは複雑であり、管理するのが難しい。さらに重要な点として、この手法では、証明書を発行するために認証局の協力が必要となる。
【０００５】
EP-A-0 592 808は、2つのデバイスの間の鍵配信チャネルを使用する鍵配信メカニズムを開示している。デバイスは、システムの初期化の一部としてインストールされる、鍵を暗号化する鍵を共有する。セッション鍵は、第一デバイスにおいて鍵を暗号化する鍵のもとに暗号化され、第二デバイスにおいて同じ鍵によって暗号解読される（第12欄、第33〜43行）。しかしながら、このように配信されるセッション鍵の場合、デバイス間で認証が行われない。また、このメカニズムは、上記の証明書ベースの手法からこの鍵配信メカニズムに、またはこの逆方向に切り替えるための簡単な方法が存在しないという点において、透明ではない。
【０００６】
US-B-5,949,883は、高トラスト環境と低トラスト環境との間で透明でかつ保護レベルが可変である暗号化システムを開示している。これは、両方の環境に共通の暗号化アルゴリズム（例えば、データ暗号化規格（DES））を選択し、かつ低トラスト環境におけるデバイス内の多数の鍵ビットを固定することによって、行われる。これにより、低トラスト環境におけるデバイスは、高トラスト環境におけるデバイスが暗号解読できる、高トラスト環境におけるデバイスに対するデータを、暗号化することができる。多数の鍵ビットは固定されているので、当局機関は、鍵を強制使用することによって暗号化されたデータにアクセスすることもできる。しかしながら、高トラスト環境におけるデバイスは、高トラスト環境における別のデバイスと通信しているのか、低トラスト環境におけるデバイスと通信しているのかを識別することはできない。
【特許文献１】
EP-A-0 592 808US-B-5,949,883
【発明の開示】
【課題を解決するための手段】
【０００７】
本発明の目的は、第二デバイスを透明かつスケーラブルに認証できる、於て書きの第一デバイスを提供することである。
【０００８】
この目的は、本発明によると、第一デバイスであって、当該第一デバイスが、
- 前記第二デバイスの公開鍵(UPK)の証明書を前記第二デバイスから受信するための受信手段と、
- 認証局の公開鍵(CAPK)が利用可能である場合には、前記認証局の前記公開鍵による前記受信された証明書の検証が成功したときに、前記第二デバイスを保護が強いデバイスとして認証し、かつ、ローカルに利用可能な公開鍵(SPK)による前記受信された証明書の検証が成功したときに、前記第二デバイスを保護が弱いデバイスとして認証する、認証手段と、
を有する第一デバイス、によって達成される。
【０００９】
第一デバイスまたは第二デバイスのいずれかをソース、他方をシンクとすることが出来る。第二デバイスから受信される証明書は、認証局によって署名されているか、または第二デバイスにおいて利用可能な秘密鍵によって署名されている。後者の場合には、第一デバイスは、ローカルに利用可能な対応する公開鍵を持つ必要がある。この場合には安全度は低い。なぜなら、証明書の信頼性と有効性を保証できる独立した第三者が存在しないためである。この理由のため、この場合、第二デバイスは保護が弱いデバイスとして認証される。以上のように概説される認証ステップは、第一デバイスと第二デバイスの両方によって実行されることが望ましい。このようにして、相互認証が達成される。
【００１０】
第一デバイスがシンクであり、かつ認証局の利用可能な公開鍵を持つ場合には、第一デバイスは、この公開鍵を使用して証明書を検証することを試みる。成功した場合には、第一デバイスは、第二デバイス（ソース）が強く保護されていることを知る。その場合、シンクは、両デバイスがデータを安全に(securely)交換できるように、自身が保護が強いデバイスとしてソースに認証させることができる。しかし、認証局の公開鍵を使用して証明書を検証できない場合には、第一デバイスは、ローカルに利用可能な公開鍵によって証明書を検証することによって、弱いモードに切り替えることができる。このように、認証（および暗黙的にデータの保護）はスケーラブルである。
【００１１】
一実施例においては、前記第一デバイスは、前記第一デバイスの公開鍵(UPK)の証明書を前記第二デバイスに送信するための送信手段をさらに有し、前記証明書が、認証局によって署名されているかまたはローカルに利用可能な秘密鍵(SSK)によって署名されているかのいずれかである。このように、第一デバイスは、上記に概説されている相互認証手順を、単に証明書を第二デバイスに送信することによって開始できる。デバイスが認証局によって署名された証明書を持つ場合、ほとんどの場合、そのデバイスは自身が保護が強いデバイスとして認証されるように、この証明書を使用することを望む。しかしながら、このような証明書を持たない場合、証明書を自身で生成して、その証明書を送信する必要がある。
【００１２】
第二デバイスが保護が強いデバイスとして認証されている場合には、送信される証明書は、認証局によって署名された証明書であり、かつ第二デバイスが保護が弱いデバイスとして認証されている場合には、この証明書が、ローカルに利用可能な秘密鍵(SSK)によって署名された証明書であることが、望ましい。
【００１３】
また、第一デバイスが、相互認証手順を開始したデバイスでないこともある。この場合、第一デバイスは、最初に、上述されているように第二デバイスを認証する。これにより、第一デバイスは、第二デバイスの保護レベルを認識し、適切な証明書を送り返すことができる。第一デバイスがシンクであり、第二デバイスを保護が強いソースとして認証したが、認証局によって署名された利用可能な証明書を持たない場合には、この第一デバイスは終了(abort)する。なぜならば、保護が弱いシンクは、保護が強いソースと共に動作できないためである。
【００１４】
さらなる実施例においては、前記認証手段は、前記第二デバイスが保護が弱いデバイスとして認証されかつ前記第一デバイスが保護が強いデバイスである場合に、データの交換を防ぐように構成されている。これにより、強いソースデバイスが価値の高いデータを弱いシンクデバイスに誤って送信することを危惧することなく、デバイスを互いに透明に接続することができる。実際には、保護が強いソースは、認証局の公開鍵によって受信された証明書の検証が失敗した時点で、シンクデバイスを保護が弱いデバイスとして認識できる。
【００１５】
さらなる実施例においては、前記第一デバイスが、
前記セッション鍵と前記ローカルに利用可能な秘密鍵(SSK)の連結の第一ハッシュを計算し、かつ、前記第一ハッシュを前記第二デバイスと交換されるデータを暗号化するための暗号化鍵として使用するように構成されている弱い暗号化鍵生成器、をさらに有する。
【００１６】
データ暗号化鍵生成のこのモードは、単純であるため、ブリッジデバイスまたは処理能力のないストレージデバイスにおける処理量を大幅に低減させるために使用できる。さらに、セッションの間、暗号化鍵を生成するためにソースとシンクの間に通信は必要ない。
【００１７】
前記弱い暗号化鍵生成器は、その後、前記第一ハッシュと前記ローカルに利用可能な秘密鍵の連結の第二ハッシュを計算し、かつ、前記第二ハッシュを前記第一ハッシュの代わりに使用するように、さらに構成されていることが望ましい。これによって、ソースとシンクは定期的に鍵を交換でき、従って、1つのデータ暗号化鍵が危殆化しても、それは一時的な問題にとどまる。ローカルに利用可能な秘密鍵は（おそらくは）まだ秘密であるため、攻撃者は前の鍵と秘密鍵との連結のハッシュを予測できない。
【００１８】
さらなる実施例においては、前記第一デバイスは、
セッション鍵とデジタル著作権管理(Digital Rights Management)データを有するコンテナを構築し、前記コンテナに、前記第一デバイスの前記公開鍵(UPK)に対応する秘密鍵(USK)によって署名し、前記署名されたコンテナを、前記第二デバイスの前記公開鍵(UPK)によって暗号化し、かつ、前記署名されかつ暗号化されたコンテナを前記第二デバイスに送信するための、セッション確立手段、をさらに有する。
【００１９】
セッションは、ソースがコンテンツをシンクに送信する必要が生じるたびに確立できる。セッションは、ソースからシンクへの音楽トラックのダウンロード、CD全体のコピー、フットボールの試合の記録等とすることができる。
【００２０】
相互に認証されたデバイスは、コンテンツの送信が許可されることを検証するために、その両方がデジタル著作権管理データを検査する必要がある。デジタル著作権の記述をコンテナ内で安全に送信することによって、おそらくはコンテンツの形式を理解しないブリッジデバイスまたは処理能力のないストレージデバイスが、コンテンツ自体を処理する必要なしに、そのコンテンツを正しく扱うことができる。アプリケーションに追加情報が必要な場合には、その情報もコンテナに格納できる。
【００２１】
さらなる実施例においては、前記第一デバイスは、
署名されかつ暗号化されたコンテナを前記第二デバイスから受信し、前記コンテナを、前記第一デバイスの前記公開鍵(UPK)に対応する秘密鍵(USK)によって暗号解読し、前記署名を、前記第二デバイスの前記公開鍵(UPK)によって検証し、かつ、セッション鍵とデジタル著作権管理データを前記コンテナから取得するための、セッション確立手段、をさらに有する。
【００２２】
本発明のさらなる目的は、第二デバイスを透明かつスケーラブルに認証する、於て書きの方法を提供することである。
【００２３】
この目的は、本発明によると、認証方法であって、
・ 前記遠隔デバイスの公開鍵(UPK)を有する証明書を前記遠隔デバイスから受信するステップと、
・ 認証局の公開鍵(CAPK)が利用可能である場合には、前記認証局の前記公開鍵による前記受信された証明書の検証が成功したときに、前記遠隔デバイスを保護が強いデバイスとして認証し、かつ、ローカルに利用可能な公開鍵(SPK)による前記受信された証明書の検証が成功したときに、前記遠隔デバイスを保護が弱いデバイスとして認証するステップ、
を有する、方法において、達成される。
【００２４】
本発明は、本発明による方法をプロセッサに実行させるように構成されているコンピュータプログラム製品にも、関する。
【００２５】
本発明の上記およびその他の観点は、図面に示されている実施例を参照しながら、以下に明確に解明される。
【００２６】
すべての図面を通じて、類似または対応する特徴要素には、同じ参照数字が、付されている。図面に示されている特徴要素のいくつかは、一般にはソフトウェア、および（ソフトウェアモジュールまたはオブジェクトなどの）ソフトウェアエンティティを示すものにより実施される。
【発明を実施するための最良の形態】
【００２７】
システムアーキテクチャ
図1は、ソースデバイス110、120とシンクデバイス130、140を有する機器構成100を線図的に示す。以下の説明において、用語「ソースデバイス」または短縮形としての単なる「ソース」は、別のデバイス、すなわち「シンクデバイス」または短縮形としての単なる「シンク」に送信するデータを持つデバイスを意味する。ソースデバイスは、通常、最初にシンクデバイスとの通信セッションを確立する。
【００２８】
ソースデバイスまたはシンクデバイスの実施例は、オーディオ／ビデオ受信機と再生機、セットトップボックス、汎用コンピュータ、移動電話、インターネット機器などを含む。ソースデバイスまたはシンクデバイスが、本文書に説明されるように本発明に従って動作するときには、「SCOPを使用可能な」と言う。SCOPは、スケーラブルなコンテンツ保護(Scalable Content Protection)を表し、本発明はこの保護方式を提供する。
【００２９】
送信されるデータは、任意のデータでよい。望ましい実施例においては、データは、音楽、ビデオ、写真、テキスト、その他の潜在的に価値のあるマテリアルなどのコンテンツ項目を表す。このようなデータは、権限のないアクセスを防ぐため、安全な方式によって転送する必要がある。例えば、データには、データの再生および／またはコピーを制限するデジタル著作権管理（DRM）規則を関連付けることがある。このようなデータは、DRM規則に従いかつこの規則の制限を実施するデバイスの間でのみ送信させる必要がある。
【００３０】
以下の説明においては、保護が強いデバイスと保護が弱いデバイスとが区別される。いま、高い価値を持たず、従って保護が弱いソース上で再生されるコンテンツを考える。この場合、シンクが強い保護を実施する必要が生じる理由はない。なぜなら、ソース自体がその必要がないためである。しかしながら、コンテンツの価値が高い場合には、ソースは強く保護される。従ってシンク側も、悪意のあるユーザが保護が弱いシンクを破ることによってこの価値の高いコンテンツにアクセスすることを防止するために、強く保護される必要がある。
【００３１】
図1において、デバイス110と130は、保護が強いデバイスであり、これに対して、デバイス120と140は、保護が弱いデバイスである。
【００３２】
すべてのデバイス110、120、130、140は、以下の鍵を格納する。
- 一意の秘密鍵(USK)を安全に格納する（読み取る／修正する／交換することはできない）。
- 対応する一意の公開鍵(UPK)を安全に格納する（修正する／交換することはできない）。
- 共有される秘密鍵(SSK)を安全に格納する（読み取る／修正する／交換することはできない）。
- 対応する共有される公開鍵(SPK)を安全に格納する（修正する／交換することはできない）。
【００３３】
保護が強いデバイス110、130は、以下も格納する。
- 一意の公開鍵UPKを含む、認証局によって署名された証明書(CUPK)を安全に格納する（修正する／交換することはできない）。
- 認証局の公開鍵(CAPK)を安全に格納する（修正する／交換することはできない）。
【００３４】
鍵のエスクローをサポートするデバイスは、秘密鍵(ESK)も安全に格納する（読み取る／修正する／交換することはできない）。鍵を安全に格納するため、デバイス110、120、130、140には、それぞれのセキュアメモリ111、121、131、141が設けられる。留意すべき点として、このコンテキストにおける「読み取り」は、デバイスの外側のエンティティによる読み取りを意味する。当然ながら、デバイス自身は、メッセージを暗号解読する、または署名を生成するために秘密鍵を読み取る必要がある。
【００３５】
セキュアメモリは、例えば、スマートカード上に設けることができる。このような場合には、スマートカードは、必要な暗号化、暗号解読、および署名の生成と検証操作を行うことのできるセキュア中央処理装置（CPU）も有することができる。この場合、秘密鍵は、スマートカードが挿入されているデバイスさえも読み取ることができない。
【００３６】
デバイスは、他のデバイスからのメッセージを送信および受信するための、それぞれの送信モジュール112、122、132、142と受信モジュール113、123、133、143とを有する。ソースデバイスとシンクデバイスは、何らかの方法によって互いに接続される。図1には、デバイス110、120、130、140を接続するネットワーク150がある。このネットワークは、例えば、ローカルエリアネットワーク、ケーブルネットワーク、またはワイドエリアネットワーク（例えば、インターネット）でよい。デバイス間の接続は、例えば、IEEE 1394, 802.11、HIPERLAN、またはBluetooth接続を使用しての有線または無線とすることができる。
【００３７】
相互認証
ソースとシンクの間でデータを交換するためには、その前に相互認証を実行する必要がある。保護が弱いデバイスは、保護が強いデバイスと同様に、保護が弱いデバイス同士でデータを交換できる。保護が弱いソースは、保護が強いシンクにデータを送信することもできる。しかしながら、保護が強いソースは、保護が弱いシンクにデータを送信することはできない。
【００３８】
この認証方法は、公開鍵暗号法を使用する。署名と暗号化の両方に、楕円曲線暗号法が使用されることが望ましい。当然ながら、RSAまたはDiffie-Hellmanなどの他の公開鍵システムも使用できる。このような暗号法システムは、この技術分野において周知である。
【００３９】
図2は、ソースデバイスにおける認証の方法を示すフローチャートである。保護が強いシンクは保護が弱いソースと相互動作できるはずであるため、使用する強度をシンクが識別できるように、相互認証を開始するのはソースである。認証を実行するため、ソースデバイスは、それぞれの認証モジュール114、124を有する。
【００４０】
ステップ200において、ソースデバイスは、認証方法を開始する。最初に、210において、認証モジュール114、124は、一意の公開鍵UPKの証明書CUPKが利用可能である否かを判断する。利用可能である場合には、ソースデバイスは強く保護されている。従って、認証モジュール114は、利用可能な証明書CUPKを見つけるが、認証モジュール124は見つけない。認証モジュール114は、240において、送信モジュール112を起動し、証明書CUPKをシンクデバイスに送る。
【００４１】
認証モジュール124は、証明書を送信する代わりに、230において、その一意の公開鍵UPKの証明書を生成し、共有される秘密鍵SSKを使用してこの証明書に署名する。認証モジュール124は、次いで、240において、送信モジュール122を起動し、生成された証明書CUPKをシンクデバイスに送信する。ソースデバイス120は、セキュアメモリ121において利用可能な共有される秘密鍵SSKを使用して署名された、その一意の公開鍵UPKの証明書を持つこともできる。このように、証明書を生成する必要があるのは一度のみである。
【００４２】
次いで、受信モジュール113、123は、250において、シンクデバイスがその公開鍵の証明書によって応答するのを待つ。このような証明書によって応答するときのシンクデバイス側の動作については、図3を参照して後に説明する。
【００４３】
受信モジュール113、123は、シンクデバイスの公開鍵の証明書を受信すると、それを認証モジュール114、124に供給する。認証モジュール114、124は、260において、認証局（CA）の公開鍵CAPKが利用可能か否かを判断する。この認証局は、証明書CUPKを発行した認証局と同じでよいが、必ずしも同じでなくてもよい。認証モジュール114は利用可能な公開鍵CAPKを見つけ、認証モジュール124は見つけない。通常、公開鍵CAPKは、認証局自身または別の認証局によって発行される認証局の証明書の一部である。
【００４４】
認証モジュール114は、270において、受信された証明書を公開鍵CAPKによって検証することを試みる。認証モジュール114は、次いで、280において、この検証が成功するか否かを判断する。成功の場合には、290において、シンクが、保護が強いシンクとして認証される。失敗の場合には、291において、シンクの認証が失敗する。なぜなら、保護が強いソースは、保護が弱いシンクと通信することが許可されないためである。
【００４５】
認証モジュール124は、275において、受信された証明書を共有される公開鍵SPKを使用して検証することを試みる。認証モジュール124は、次いで、285において、この検証が成功するか否かを判断する。成功の場合には、292において、シンクが、保護が弱いシンクとして認証される。失敗の場合には、291において、シンクの認証が失敗する。
【００４６】
図3は、シンクデバイスにおける認証の方法を示すフローチャートである。保護が強いシンクは保護が弱いソースと相互動作できるはずであるため、使用する強度をシンクが識別できるように、相互認証を開始するのはソースである。認証を実行するため、シンクデバイスは、それぞれの認証モジュール134、144を有する。
【００４７】
ステップ300において、シンクデバイスは、認証方法を開始する。最初に、310において、受信モジュール133、143は、ソースデバイスの公開鍵の証明書をソースデバイスから受信する。前述されているように、この証明書は、図2のフローチャートのステップ240において、ソースデバイスによって送信されたものである。
【００４８】
受信モジュール133、143は、ソースデバイスの公開鍵の証明書を受信すると、それを認証モジュール134、144に供給する。認証モジュール134、144は、320において、認証局（CA）の公開鍵CAPKが利用可能か否かを判断する。この認証局は、証明書CUPKを発行した認証局と同じでよいが、必ずしも同じでなくてもよい。認証モジュール134は、利用可能な公開鍵CAPKを見つけるが、認証モジュール144は見つけない。
【００４９】
次いで、認証モジュール134は、330において、受信された証明書を公開鍵CAPKを使用して検証することを試みる。認証モジュール134は、次いで、340において、この検証が成功するか否かを判断する。成功の場合には、ソースが、保護が強いソースとして認証され、認証モジュールはステップ380に進む。失敗の場合には、認証モジュール134はステップ350に進む。
【００５０】
認証モジュール134、144は、350において、受信された証明書を共有される公開鍵SPKを使用して検証することを試みる。認証モジュール134、144は、次いで、360において、この確認が成功するか否かを判断する。成功の場合には、ソースが、保護が弱いソースとして認証される。失敗の場合には、375において、ソースの認証が失敗する。
【００５１】
保護が弱いソースとしてのソースの認証に成功すると、認証モジュール134、144は、370において、一意の公開鍵UPKの証明書を生成し、共有される秘密鍵SSKを使用してこれに署名する。
【００５２】
380において、認証モジュール134、144は、それぞれの送信モジュール132、142を起動し、生成された証明書をソースデバイスに送信する。シンクデバイス130、140は、セキュアメモリ131、141において利用可能な共有される秘密鍵SSKを使用して署名された、その一意の公開鍵UPKの証明書を持つこともできる。このように、証明書を生成する必要があるのは一度のみである。
【００５３】
ソースデバイスとシンクデバイスそれぞれにおいて実行される認証方法の間の相互作用を明確にするために、保護が強いソースおよびシンクと保護が弱いソースおよびシンクの4種類の可能な組合せと、それぞれの場合における処理を以下に示す。
【００５４】
保護が強いソースから保護が強いシンク
保護が強いソースは、認証局によって署名された自身の証明書(CUPK)を送信する。保護が強いシンクは、この証明書を受信し、認証局の公開鍵(CAPK)を使用してこれを検証する。署名が一致しない場合には、保護が強いシンクは、共有された公開鍵(SPK)を使用して証明書を検証する。それでも署名が一致しない場合には、保護が強いシンクはプロトコルを終了する。
【００５５】
しかしながら、最初の検証時に署名が一致する場合には、保護が強いシンクは、ソースが強い保護を使用していることを知り、認証局によって署名された証明書(CUPK)を送信する。保護が強いソースはこれを受信し、認証局の公開鍵(CAPK)を使用してこれを検証する。署名が一致しない場合には、このプロトコルは終了する。一致する場合には、両方のデバイスが強い保護について認証され、両方のデバイスが、他方のデバイスの一意の公開鍵(UPK)を持つ。
【００５６】
保護が弱いソースから保護が強いシンク
保護が弱いソースは、最初に、その一意の公開鍵(UPK)の証明書を作成し、共有される秘密鍵(SSK)を使用してこれに署名する。この作成ステップは、リソースを節約するために事前に行うことができる。この証明書は、保護が強いシンクに送信される。保護が強いシンクは、この署名された証明書を受信し、認証局の公開鍵(CAPK)を使用してこれを検証する。署名が一致しない場合には、保護が強いシンクは、共有される公開鍵(SPK)を使用して証明書を検証する。それでも一致しない場合には、保護が強いシンクは、このプロトコルを終了する。
【００５７】
しかしながら、署名が一致する場合には、保護が強いシンクは、ソースが弱い保護をサポートするのみであることを認識し、自身の一意の公開鍵(UPK)の証明書を作成し（リソースを節約するために事前に作成することもできる）、共有される秘密鍵(SSK)を使用してこれに署名する。この証明書は、ソースに送信される。ソースは、シンクからこの証明書を受信すると、共有される公開鍵(SPK)を使用してこれを検証する。署名が一致しない場合には、ソースはこのプロトコルを終了する。一致する場合には、両方のデバイスが弱い保護について認証され、両方のデバイスが、他方のデバイスの一意の公開鍵(UPK)を持つ。
【００５８】
保護が弱いソースから保護が弱いシンク
保護が弱いソースは、最初に、その一意の公開鍵(UPK)の証明書を作成し、共有される秘密鍵(SSK)を使用してこれに署名する。この作成ステップは、リソースを節約するために事前に行っても良い。この証明書は、保護が弱いシンクに送信される。保護が弱いシンクは、この署名された証明書を受信し、共有される公開鍵(SPK)を使用してこれを検証する。署名が一致しない場合には、保護が弱いシンクは、このプロトコルを終了する。
【００５９】
しかしながら、署名が一致する場合には、保護が弱いシンクは、その一意の公開鍵(UPK)の証明書を作成し、共有される秘密鍵(SSK)を使用してこれに署名する。この作成ステップは、リソースを節約するために事前に行うことができる。この証明書は、ソースに送信される。ソースは、シンクからこの証明書を受信すると、共有される公開鍵(SPK)を使用してこれを検証する。署名が一致しない場合には、保護が弱いソースは、このプロトコルを終了する。一致する場合には、両方のデバイスが弱い保護について認証され、両方のデバイスが、他方のデバイスの一意の公開鍵(UPK)を持つ。
【００６０】
保護が強いソースから保護が弱いシンク
保護が強いソースは、認証局によって署名された証明書(CUPK)を直接送信する。保護が弱いシンクは、この証明書を受信し、共有される公開鍵(SPK)を使用してこれを検証する。署名が一致しない場合には、保護が強いシンクはこのプロトコルを終了する。従って、認証は必ず失敗する。このように、保護が強いソースは、保護が弱いシンクを認証することはなく、従ってソースからシンクにデータは送信されない。
【００６１】
セッションの確立
ソースとシンクが相互に認証されると、セッションを確立する必要がある。一般には、認証は、ソースとシンクが互いに最初に接続されるときに実行する必要があるのに対し、セッションは、ソースがコンテンツをシンクに送信する必要が生じるたびに確立する必要がある。従って、セッションは、ソースからシンクへの音楽トラックのダウンロード、CD全体のコピー、フットボールの試合の記録等とすることができる。
【００６２】
各セッションの最初に、コンテナがソースからシンクに安全に転送される。このコンテナには、ソースによってランダムに選択されるセッション鍵SKが含まれ、さらに、アプリケーションがデジタル著作権管理（DRM）システムであるか否かに応じて、そのセッションの間に送信されるコンテンツに関連付けられるデジタル著作権の記述も含まれる。
【００６３】
相互に認証されたデバイスは、コンテンツの送信が許可されるか否かを検証するために、その両方がこれらのデジタル著作権を検査する必要がある。この検査の方法について、以下に具体的に示す。コンテナ内でデジタル著作権の記述を安全に送信することによって、おそらくはコンテンツの形式を理解しないブリッジデバイスまたは処理能力のないストレージデバイスが、コンテンツ自体を処理する必要なしに、そのコンテンツを正しく扱うことができる。アプリケーションが追加の情報を必要とする場合には、その情報もコンテナに格納できる。
【００６４】
図4は、ソースデバイスにおける、シンクデバイスとの通信セッションを確立する方法を示すフローチャートである。セッションの確立は、セッション確立モジュール115、125によって管理される。
【００６５】
この方法は、ステップ400から開始される。最初に、410において、セッション確立モジュール115、125は、このセッションにおいて交換されるデータがDRM規則に従う必要があるか否かを検証する。必要がある場合には、411において、データの著作権の記述が取得され、412において、そのデータを実際にシンクに送信できるか否かが検証される。この検証が失敗した場合には、セッション確立モジュール115、125は、413においてこのセッションを終了する。
【００６６】
ステップ420において、この特定のセッションのセッション鍵として機能する乱数SKが選択される。暗号法の分野において周知であるように、予測することが非常に難しい数をセッション鍵として選択することが重要である。この数SKは完全な乱数が理想的であるが、これは非常にコストがかかり、実現することが難しいため、数SKは通常は、擬似ランダムに生成される。セッション鍵SKのサイズは、保護方式の選択される強度に応じて、適切に構築された表に従って変化する。
【００６７】
次いで、430において、このセッションに対して鍵のエスクローを使用する必要があるか否かが判断される。鍵のエスクローの1つの手法は、本発明と同じ出願人による国際特許出願PCT/EP/01/11722（社内整理番号PHNL000558）に説明されている。
【００６８】
相対的に小さいセッション鍵SKと、これより長い秘密鍵ESKとを混合し、その結果の鍵RKをセッション鍵として使用することによって、悪意のある（ESKを知らない）ユーザにとっては、この保護方式を破ることはより難しくなるが、（ESKを知っている）関係当局またはコンテンツの所有者にとっては、より容易になる。
【００６９】
しかしながら、これにより、この保護方式にセキュリティ上の脅威が生まれることは、注目すべきである。悪意のあるユーザは、セキュリティレベルの低い関係当局／コンテンツ所有者から盗むことによって、またはそこにアクセスする膨大な人のうちの一人から不正に聞き出すことによって、最終的に秘密鍵ESKを見つけることができると考えるのが妥当である。鍵のエスクローを使用する必要がある場合には、440において、エスクロー鍵ESKが乱数SKと混合され、その結果がセッション鍵として使用される。
【００７０】
ステップ450において、セッション確立モジュール115、125は、コンテナを生成する。このコンテナには、セッション鍵SKが含まれ、さらに、アプリケーションがデジタル著作権管理（DRM）システムであるか否かに応じて、そのセッションの間に送信されるコンテンツに関連付けられるデジタル著作権の記述も含まれる。
【００７１】
セッション確立モジュール115、125は、次いで、460において、それぞれの一意の秘密鍵USKを使用してコンテナに署名し、470において、シンクの一意の公開鍵UPKを使用してその結果を暗号化する。この公開鍵UPKは、図2を参照しながら前述されているように、ソースが受信して認証したものである。次いで、署名されかつ暗号化されたコンテナが、480において、シンクに送信される。490において、この方法が終了する。
【００７２】
図5は、シンクデバイスにおける、ソースデバイスとの通信セッションを確立する方法を示すフローチャートである。シンクデバイス130、140におけるセッションの確立は、セッション確立モジュール135、145によって管理される。この方法は、500から開始される。セッション確立モジュール135、145は、510において、署名されかつ暗号化されたコンテナを受信する。
【００７３】
セッション確立モジュール135、145は、署名されかつ暗号化されたコンテナを受信すると、520において、最初に自身の一意の秘密鍵USKを使用してこれを暗号解読する。次いで、セッション確立モジュール135、145は、530において、図3を参照しながら前述されているように受信されかつ認証された一意の公開鍵UPKを使用して、証明書を検証する。
【００７４】
次いで、540において、セッション鍵SKと、セッションの間にシンクが受信するコンテンツに関連付けられているデジタル著作権の記述（存在する場合）とを取得するために、コンテナが調べられる。
【００７５】
次いで、セッション確立モジュール135、145は、550において、デジタル著作権が存在するか否かを判断する。存在する場合には、セッション確立モジュール135、145は、551において、これらの著作権をコンテナから取得し、552において、このセッションの間にデータを送信するための著作権が存在するか否かを検証する。存在しない場合には、553において、このセッションは許可されない。
【００７６】
デジタル著作権が見つからない場合、または見つかった著作権に、このセッションの間にデータを送信するための著作権が含まれる場合には、560において、乱数SKが取得され、セッション鍵として使用可能になる。570において、この方法が終了する。
【００７７】
送信されるデータの暗号化
ソースからシンクに送信されるデータは、段数と暗号化鍵EKのサイズが保護方式の必要な強度に応じて変化する、強いブロック暗号を使用して暗号化される。1セッションの間に暗号化鍵EKが更新される頻度も、保護方式の必要な強度に依存する。データを暗号化するため、デバイス110、120、130、140には、それぞれの暗号化／暗号解読モジュール117、127、137、147が設けられる。
【００７８】
望ましい一実施例の場合、暗号化／暗号解読モジュール117、127、137、147は、小さく高速で使用料がかからないTEA（Tiny Encryption Algorithm）を使用して、データをブロック暗号として暗号化および暗号解読する。このアルゴリズムは、Springer-Verlag社のComputer Science誌の「Lecture Notes」の第1008回（1994年、p.363〜366）「TEA, a Tiny Encryption Algorithm（TEA：Tiny Encryption Algorithm）」（David J. Wheeler氏、Roger M. Needham氏）に説明されている。また、インターネット上のhttp://vader.brad.ac.uk/tea/tea.shtmlにも記載されている。
【００７９】
暗号化されたデータを交換するためには、その前に暗号化鍵を生成する必要がある。本文書には、鍵生成の2種類のモードが定義されている。保護が強いデバイスは、新しい暗号化鍵が必要になるたびに、情報を相互に交換する。保護が弱いデバイスは、非常に単純な方式を使用して、前のセクションにおいて安全に交換されたセッション鍵から連続的な暗号化鍵を生成する。保護が強いデバイスは、すべて、弱い暗号化鍵の生成もサポートする必要がある。これによって、保護が弱いソースが保護が強いシンクと相互動作することができる。
【００８０】
弱い暗号化鍵の生成
図6は、ソースデバイスとシンクデバイスが、保護が弱いデバイスとして互いに相互認証済みであるときに使用される鍵生成の方法を示すフローチャートである。保護が弱いデバイス120、140には、この方法を実行する、それぞれの鍵生成モジュール126、146が設けられる。この方法は、600から開始される。最初の生成時には、610において、セッション鍵SKが、共有される秘密鍵SSKと連結される。
【００８１】
次いで、620において、この連結がハッシュ関数への入力として使用される。暗号法として強力な多数のハッシュ関数が、この分野において公知である。一実施例においては、上述されているTEA（Tiny Encryption Algorithm）が、周知のDavies-Mayerハッシュ関数と組み合せて使用される。
【００８２】
ハッシュ関数の出力のサイズは、（使用される保護方式の強度に応じて）可変である。630において、この出力は、第一暗号化鍵EK1として使用される。新しい暗号化鍵が必要となるたびに、セッション鍵SKと共有される秘密鍵SSKを連結する代わりに、前の暗号化鍵EKn-1が、共有される秘密鍵SSKを使用してハッシュ処理される。セッションの間に暗号化鍵を生成するのに、ソースとシンクの間の通信は必要ない。
【００８３】
暗号化鍵の生成のこのモードを使用することで、ブリッジデバイスまたは処理能力のないストレージデバイスにおける処理量を大幅に低減させることができる。
【００８４】
強い暗号化鍵の生成
図7は、両方のデバイスが保護が強いデバイスとして相互に認証済みであるときに使用される鍵生成の方法を示すフローチャートである。保護が強いデバイス110、130には、この方法を実行する、それぞれの鍵生成モジュール116、136が設けられる。この方法は、700から開始される。
【００８５】
710において、ソース内の鍵生成モジュール116とシンク内の鍵生成モジュール136の両方が、セッション鍵と同じサイズの、それぞれRsrc、Rsnkと呼ばれる乱数を生成する。
【００８６】
720において、この乱数が、セッション鍵SKに対してXOR処理され、730において、他方に送信される。740において、鍵生成モジュール116、136の両方は、セッション鍵SKに対してXOR処理された、他方の乱数を受信する。両方の鍵生成モジュールは、他方の実際の乱数を得るために、750において、受信した乱数をセッション鍵SKに対して再びXOR処理する。この時点で、両方の鍵生成モジュールは、両方の乱数を知る。
【００８７】
ソースにおいては、760において、乱数Rsnkがシンクの公開鍵UPKと連結される。同様に、シンクにおいては、760において、乱数Rsrcがソースの公開鍵UPKと連結される。次いで、770において、この連結が、ハッシュ関数に送られる。
【００８８】
さらに、シンクにおいては、765において、乱数Rsnkがシンクの公開鍵UPKと連結される。同様に、ソースにおいては、765において、乱数Rsrcがソースの公開鍵UPKと連結される。次いで、775において、この連結が、ハッシュ関数に送られる。
【００８９】
ハッシュ関数の出力サイズは、使用される保護方式の強度に応じて可変である。次いで、780において、この結果がXOR処理され、暗号化鍵EKが生成される。新しい暗号化鍵EKが必要となるたびに、このプロセスが繰り返される。この鍵生成方法は、図5を参照しながら説明した方法よりも強力であるが、XOR処理されるセッション鍵を交換するために、ソースとシンクの間の通信が必要となる。
【００９０】
鍵生成のこの方法は、Bluetooth仕様バージョン1.0A、第14.2.2.4項、p155〜156に示されている、組み合わせ鍵を生成する手順に、その一部が基づいている。
【００９１】
コンテンツの送信
ソースが、ブリッジデバイス（例えば、IEEE1394からUSBへのブリッジ）を経由することによってコンテンツをシンクに安全に送信する必要がある場合には、ソースとブリッジ（シンクとして機能する）の間のリンクと、ブリッジ（この場合はソースとして機能する）とシンクの間の第二リンクを確立する必要がある。
【００９２】
このことは、コンテンツがブリッジの中で暗号解読され、再び暗号化されることを意味する。これを回避するため、セッションの確立が以下のように起こる場合には、上記の暗号化鍵生成方法を使用できる。すなわち、ソースとブリッジは、図2と3を参照しながら前述されているように両方のデバイスが相互に認証された後に、図4と5を参照しながら前述されているようにセッションを確立する。
【００９３】
しかしながら、ブリッジとシンクは、（相互に認証された後に）セッションを確立するが、このセッションにおいては、セッション鍵SKがブリッジによってランダムに選択されるのではなく、ブリッジがソースから受信したコンテナから取得される。このようにして、ソースとシンクの両方が同じセッション鍵SKを持ち、ブリッジは、自身を通過するコンテンツを暗号解読してから再び暗号化する必要がない。
【００９４】
処理能力のないストレージデバイスは、コンテンツが特定の時間だけ存在した後にシンクに渡されるブリッジとみなすことができる。従って、ストレージデバイスには、ソースから受信された暗号化されたコンテンツが、シンクから受信されたコンテナと共に格納される。このコンテナを安全に格納するために、ストレージデバイスは、その一意の公開鍵UPKによってコンテナを暗号化する。コンテンツを再送信するときに、ストレージデバイスは、その一意の秘密鍵USKによってセキュアコンテナを暗号解読し、ソースによって選択されたセッション鍵SKを取得する。次いで、ストレージデバイスは、シンクとのセッションを（相互認証後に）確立し、乱数を選択する代わりに、取得されたセッション鍵SKを使用する。
【００９５】
ブリッジデバイスとストレージデバイスのいずれも、関連付けられるデジタル著作権を取得して解釈するために、コンテンツの形式を理解できる必要がないことは、留意すべきである。さらに、ソースとシンクの間のブリッジデバイスまたは処理能力のないストレージデバイスの最大数は、デジタル著作権によってこの種類の送信が許可されるならば、上限がない点も留意すべきである。
【００９６】
図8は、SCOPを使用可能なソースデバイス810（例えば、デジタルオーディオプレイヤー）が、SCOPを使用可能なシンク820（例えば、デジタル受信機）に有線接続され、安全に送信されるコンテンツがコピー不可である、機器構成の一実施例を線図的に示す。この場合には、シンク820が記録機能を持たないため、ソースからシンクへの送信が許可される。
【００９７】
いま、消費者が、自分のオーディオシステムからすべての配線を取り除くことを望むとする。この消費者は、例えば、IEEE 1394とBluetoothの間で双方向に変換できる、SOCPを使用可能な2つのブリッジデバイス830、831を購入することによって、これを実現する。この時点で、この消費者のシステムには、ソース810からブリッジ830、ブリッジ830からブリッジ831、ブリッジ831からシンク820、という3つのリンクが存在する。
【００９８】
コピー不可コンテンツの送信時、ソース810は、送信先のシンク820が記録デバイスなのか受信機なのかを区別できないため、この送信に関して正しい決定を下すことができない。従って、ソース810は、チェーン内の相互に認証されている次のデバイスにこの決定を任せて、前述されている方法によって、このコンテンツを安全に送信する。しかしながら、有線から無線へのブリッジ830も、この決定を下すことができず、この場合にも、相互に認証されている次のデバイスに、（コンテンツの暗号解読と再暗号化を行う必要なしに）コンテンツを安全に渡す。
【００９９】
しかしながら、無線から有線へのブリッジ831は、自身がレコーダーに接続されているのか受信機に接続されているのかを認識し、コンテンツに関連付けられているデジタル著作権の記述をコンテナから取得してそれを検査することができる。送信が許可される場合には、ブリッジ831は、暗号化されたコンテンツをシンク820に渡し、この場合にも、コンテンツの暗号解読と再暗号化を行う必要はない。
【０１００】
ブリッジデバイス830、831は、関連付けられているデジタル著作権を取得するとき、またはコンテンツを暗号解読および暗号化することによって処理するときにさえも、コンテンツの形式を知る必要がないため、保護のために加わるコストは最小限である。このアプリケーションをさらに拡張するために、SCOPを使用可能な無線から有線への第三のブリッジを、別の部屋の中に位置する、SCOPを使用可能な別の受信機に接続できる。SCOPを使用可能な無線から有線へのこの第三のブリッジは、有線から無線へのブリッジによって相互に認証され、単に、このコンテンツ保護方式における最初のブリッジと同じように機能する。
【０１０１】
このようにして、ソース810は、各SCOPリンクにおいて連続的な暗号解読／再暗号化を行う必要なく、かつ、DRMシステムを危殆化することなく、1つの有線出力を使用して、有線入力を持つ複数の受信機に無線式に接続される。この場合、完全に透明なブリッジは使用できず、なぜなら、ソース810は1つの出力のみを有するため、相互認証、セッション確立、および暗号化の間に複数のシンクを扱うことができないためである。しかしながら、SCOPを使用可能な有線から無線へのブリッジは、各SCOPリンクにおいて暗号解読／再暗号化を行う必要なしに複数の相互認証とセッション確立を扱うように明確に設計されている。
【０１０２】
デジタル著作権管理
本発明は、デジタルオーディオプレイヤーとレコーダーなど、DRMを使用可能なデバイスにおいても使用できる。その場合、デバイスは、交換するデータに対してユーザが持つデジタル著作権を認識する必要がある。例えば、デジタルオーディオプレイヤーがデジタルオーディオ受信機に接続されている場合には、コンテンツはSCOPリンクを介して安全に一回送信する必要がある。そのデジタルオーディオプレイヤーがデジタルオーディオレコーダーに接続されているか、またはコンテンツがすでに一度再生された場合には、そのコンテンツはSCOPリンクを介して送信されてはならない。
【０１０３】
本発明の実施例においては、再生著作権と記録著作権という2種類のデジタル著作権が区別されている。当然ながら、これ以外のタイプの著作権も可能であり、本発明は、この実施例に定義されている著作権に制限されない。
【０１０４】
再生著作権
ユーザは、再生することを望むコンテンツに対して以下の著作権のうちの1つを持つ。
【０１０５】
- 時間制限付き再生：コンテンツは、最初のx秒のみ再生できる。
【０１０６】
- 回数制限付き再生：コンテンツは、特定のプレイヤー上で指定された回数のみ再生でき、それ以降はそのプレイヤー上で再生できなくなる。
【０１０７】
- 期間制限付き再生：コンテンツは、特定の期間が終了するまでの間のみ再生できる。
【０１０８】
- 制限なし再生：コンテンツは、永久に回数の制限なく最後まで再生できる。
【０１０９】
- 再生不可：コンテンツは、（それ以上）再生できない。
【０１１０】
一般には、ユーザのデジタル再生著作権は、同じままではなく別のタイプに変化する。例えば、ユーザが時間制限付き再生と再生不可著作権を無料で受け取り、制限なし再生または回数制限付き再生著作権を購入することを望むことがある。回数制限付き再生著作権は、ユーザがコンテンツを指定された回数だけ再生した後に再生不可著作権に変化することもある。デジタル再生著作権は、組み合わせることもできる（例えば、時間制限付き再生と期間制限付き再生）。
【０１１１】
記録著作権
ユーザは、記録することを望むコンテンツに対して以下の著作権のうちの1つを持つ。
【０１１２】
- 回数制限付き再生：コンテンツは、指定された回数のみ記録でき、それ以降は記録できなくなる。
【０１１３】
- 制限なし記録：コンテンツは、回数の制限なしに記録できる。
【０１１４】
- 記録不可：コンテンツは、（それ以上）記録できない。
【０１１５】
一般には、デジタル記録著作権によって記録が許可される場合には、コンテンツは、オリジナルの媒体上に見つかるデジタル再生著作権と共に新しい媒体上に記録される。しかしながら、コンテンツの記録を許可する新しいデジタル記録著作権であって、記録される媒体上でのデジタル再生著作権がオリジナルの媒体のデジタル再生著作権と異なるデジタル記録著作権を定義することは有用かもしれない。例えば、ユーザが特定のコンテンツの再生著作権を持たないときに、さらに配信できるように回数制限付き再生著作権を付してそのコンテンツをコピーすることを許可することは有用かもしれない。
【０１１６】
従って、ユーザは、以下のオプションの記録著作権を持つことができる。
【０１１７】
- 配信時記録：コンテンツは、回数の制限なしに記録できるが、デジタル再生著作権は、オリジナルの媒体からコピーされる代わりに、この記録著作権によって指定される。
【０１１８】
ここまでの説明においては、ソースデバイスとシンクデバイスとが区別されている。シンクは、さらに、レコーダー、受信機、またはブリッジに分類できる。2つのデバイスが相互に認証されると、ソースは、自身が接続されているシンクのタイプを認識する。この場合の組み合わせとして、ソースからレコーダー、ソースから受信機、ソースからブリッジ、が可能である。
【０１１９】
ソースからレコーダー
セッションを確立している間、ソースは、そのセッションの間に送信されるコンテンツに対してユーザが持つデジタル記録著作権を調べる。通常の記録が許可される場合には、ソースは、ユーザのデジタル再生著作権とデジタル記録著作権とを、「セッションの確立」に説明されている二重に暗号化されたコンテナによって、レコーダーに送信する。通常の記録が許可されないがそのコンテンツに対する配信時記録著作権をユーザが持つ場合には、ソースは、配信時記録著作権と、その配信時記録著作権によって指定されるデジタル再生著作権とを、レコーダーに送信する。
【０１２０】
レコーダー（シンク）は、ユーザのデジタル記録著作権を二重に確認し、ソースと同じ結論（記録は許可される）に達する。セッションが確立されると、コンテンツはSCOPリンクを通じて安全に送信され、セッションの記録が進行する。受信されたデジタル再生著作権と、（シンクによって）更新されたデジタル記録著作権が、新しい媒体上に記録される。
【０１２１】
ソースから受信機
セッションを確立している間、ソースは、そのセッションの間に送信されるコンテンツに対してユーザが持つデジタル再生著作権を調べる。再生が許可される場合には、ソースは、ユーザのデジタル再生著作権と記録不可著作権とを、二重に暗号化されたコンテナによって送信する。受信機は、ユーザのデジタル再生著作権を二重に確認し、同じ結論（再生は許可される）に達する。セッションが確立されると、ソースは、コンテンツに対してユーザが持つデジタル再生著作権を更新する。更新が行われた後、コンテンツはSCOPリンクを通じて安全に送信され、受信機によるセッションの再生が進行する。
【０１２２】
ソースからブリッジ
ソースは、ブリッジに接続されているシンクのタイプを識別できないため、認証されているブリッジとのセッションを確立し、コンテンツに対してユーザが持つデジタル再生著作権とデジタル記録著作権とを、二重に暗号化されたコンテナによって、安全に送信する。ブリッジは、自身が接続されているシンクのタイプを識別でき、従って、シンクがレコーダーである場合には「ソースからレコーダー」に説明されている方法、シンクが受信機である場合には「ソースから受信機」に説明されている方法、シンクがさらに別のブリッジである場合には「ソースからブリッジ」に説明されている方法を、（ソースとして）適用することによって、デジタル著作権を管理することができる。
【０１２３】
鍵の破棄
破棄は、認証の間に強い保護を使用するデバイスが危殆化された場合にのみ推奨される。その場合には、権限を与えられたエンティティが、破棄されるデバイスの公開鍵UPKを含む破棄証明書を生成し、認証局の私有鍵によってこれに署名する。次いで、この破棄証明書は、新しくリリースされる媒体（例えば、CD、DVD）を通じるか、通信チャネル（例えば、インターネット、ブロードキャストネットワーク）を通じるか、またはデバイス間の相互接続そのものを通じて、フィールド内のデバイスに配布される。
【０１２４】
デバイスは、このような破棄証明書を受信すると、認証局の公開鍵CAPKを使用してこれを検証し、安全に格納する。相互認証の間、デバイスは、格納されている破棄証明書を検査することによって、他のデバイスから受信した公開鍵が破棄されていないかを確認する。留意すべき点として、この場合の語「デバイス」は、広義に使用される。例えば、インターネット上のコンテンツ配信サービスを破棄することもでき、これによって、悪意のあるユーザが、危殆化された一連の鍵を認証と暗号化に使用することによって、インターネット上に違法なコンテンツ配信サービスを確立することを防止する。
【０１２５】
別の例としては、シンクとして機能するPC上の危殆化されたソフトウェアプレイヤーを破棄することによって、この危殆化されたプレイヤーをインターネットを通じてさらに配信することを無意味にする。さらに、デバイスのグループの破棄も、上述されているのと同じ方法によってサポートされ、この場合、危殆化された一連のデバイスのグループIDを含むグループ破棄証明書を生成して配布することによって、これらのデバイスすべてが1つの破棄証明書を使用して破棄される。
【０１２６】
保護が弱いデバイスは、破棄をサポートすべきではない。なぜなら、破棄証明書は共有される私有鍵を使用して署名する必要があり、この鍵は、デバイス内に隠されていることによってのみ悪意のあるユーザから保護されるためである。この鍵が知られてしまうと、悪意のあるユーザが、保護が弱いデバイスの偽の破棄証明書を作成し、それをフィールド内のデバイスすべてにウイルス方式に拡散させることによって、相当な数の完全に合法のデバイスを動作不能にすることができる。この場合、危殆化された弱い保護方式においては一部のユーザが違法なコピーを行うことができるという元の問題は、正当なユーザのデバイスが偽の破棄証明書によって汚染され、動作不能となったデバイスがメーカーに戻されるというさらに悪い問題に発展する。
【０１２７】
留意すべき点として、上記の実施例は、本発明を制限するものではない。当業者は、添付される請求項の範囲を逸脱することなく、多数の代替の実施例を設計できるであろう。
【０１２８】
請求項において、カッコ内の参照記号は請求項の制限として解釈されないものとする。語「有する」は、請求項に記載されている以外の要素またはステップの存在を除外するものではない。要素の前の語「a」または「an」は、このような要素が複数存在することを除外するものではない。
【０１２９】
本発明は、いくつかの個別の要素を有するハードウェアによって、または適合するようにプログラムされたコンピュータによって、実施できる。デバイスの請求項においては、いくつかの手段を同一のハードウェアまたはソフトウェア要素により実施できる。
【図面の簡単な説明】
【０１３０】
【図１】ソースデバイスとシンクデバイスを有する機器構成の実施例を線図的に示す。
【図２】ソースデバイスにおける認証の方法を示すフローチャートである。
【図３】シンクデバイスにおける認証の方法を示すフローチャートである。
【図４】ソースデバイスにおける、シンクデバイスとの通信セッションを確立する方法を示すフローチャートである。
【図５】シンクデバイスにおける、ソースデバイスとの通信セッションを確立する方法を示すフローチャートである。
【図６】保護が弱いデバイスとして相互に認証されたデバイスにおける、鍵生成の方法を示すフローチャートである。
【図７】保護が強いデバイスとして相互に認証されたデバイスにおける、鍵生成の方法を示すフローチャートである。
【図８】ソースデバイスと、シンクデバイスと、2つのブリッジデバイスとを有する機器構成の実施例を線図的に示す。
【符号の説明】
【０１３１】
100 機器構成
110、120 ソースデバイス
130、140 シンクデバイス
111、121、131、141 セキュアメモリ
112、122、132、142 送信モジュール
113、123、133、143 受信モジュール
114、124、134、144 認証モジュール
115、125、135、145 セッション確立モジュール
116、126、136、146 鍵生成モジュール
117、127、137、147 暗号化／暗号解読モジュール
150 ネットワーク
810 ソース
820 シンク
830、831 ブリッジデバイス
USK 一意の秘密鍵
UPK 一意の公開鍵
SSK 共有される秘密鍵
SPK 共有される公開鍵
CAPK 認証局の公開鍵
ESK 秘密鍵
SK セッション鍵
CUPK 公開鍵UPKの証明書
CAPK 認証局（CA）の公開鍵
Claims (10)
- 第二デバイスとデータを交換するように構成された第一デバイスであって、当該第一デバイスが、
- 前記第二デバイスの公開鍵の証明書を前記第二デバイスから受信するための受信手段と、
- 認証局の公開鍵が利用可能である場合には、前記認証局の前記公開鍵による前記受信された証明書の検証が成功したときに、前記第二デバイスを保護が強いデバイスとして認証し、かつ、ローカルに利用可能な公開鍵による前記受信された証明書の検証が成功したときに、前記第二デバイスを保護が弱いデバイスとして認証する、認証手段と、
を有する、第一デバイス。 - 当該第一デバイスが、前記第一デバイスの公開鍵の証明書を前記第二デバイスに送信するための送信手段をさらに有し、前記証明書が、認証局によって署名されているか、またはローカルに利用可能な秘密鍵によって署名されているかのいずれかである、請求項1の第一デバイス。
- 前記送信される証明書が、前記第二デバイスが保護が強いデバイスとして認証済みである場合には前記認証局によって署名されていて、かつ、前記送信される証明書が、前記第二デバイスが保護が弱いデバイスとして認証済みである場合には前記ローカルに利用可能な秘密鍵によって署名されている、請求項2の第一デバイス。
- 前記認証手段が、前記第二デバイスが保護が弱いデバイスとして認証されかつ前記第一デバイスが保護が強いデバイスである場合に、データの交換を防ぐように構成されている、請求項1の第一デバイス。
- 当該第一デバイスが、
前記セッション鍵と前記ローカルに利用可能な秘密鍵の連結の第一ハッシュを計算し、かつ、前記第一ハッシュを前記第二デバイスと交換されるデータを暗号化するための暗号化鍵として使用するように構成されている弱い暗号化鍵生成器をさらに有する、請求項1の第一デバイス。 - 前記弱い暗号化鍵生成器が、その後、前記第一ハッシュと前記ローカルに利用可能な秘密鍵の連結の第二ハッシュを計算し、かつ、前記第二ハッシュを前記第一ハッシュの代わりに使用するように、さらに構成されている、請求項5の第一デバイス。
- 当該第一デバイスが、
セッション鍵とデジタル著作権管理データを有するコンテナを構築し、前記コンテナに、前記第一デバイスの前記公開鍵に対応する秘密鍵によって署名し、前記署名されたコンテナを、前記第二デバイスの前記公開鍵によって暗号化し、かつ、前記署名されかつ暗号化されたコンテナを前記第二デバイスに送信するための、セッション確立手段、
をさらに有する、請求項1の第一デバイス。 - 当該第一デバイスが、
署名されかつ暗号化されたコンテナを前記第二デバイスから受信し、前記コンテナを、前記第一デバイスの前記公開鍵に対応する秘密鍵によって暗号解読し、前記署名を、前記第二デバイスの前記公開鍵によって検証し、かつ、セッション鍵とデジタル著作権管理データを前記コンテナから取得するための、セッション確立手段、
をさらに有する、請求項1の第一デバイス。 - 遠隔デバイスを認証する方法であって、当該方法が、
・ 前記遠隔デバイスの公開鍵を有する証明書を前記遠隔デバイスから受信するステップと、
・ 認証局の公開鍵が利用可能である場合には、前記認証局の前記公開鍵による前記受信された証明書の検証が成功したときに、前記遠隔デバイスを保護が強いデバイスとして認証し、かつ、ローカルに利用可能な公開鍵による前記受信された証明書の検証が成功したときに、前記遠隔デバイスを保護が弱いデバイスとして認証するステップ、
を有する、方法。 - 請求項9の方法をプロセッサに実行させるように構成されているコンピュータプログラム製品。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP01202382A EP1271875A1 (en) | 2001-06-21 | 2001-06-21 | Device arranged for exchanging data, and method of manufacturing |
| PCT/IB2002/002415 WO2003001764A1 (en) | 2001-06-21 | 2002-06-20 | Device arranged for exchanging data, and method of authenticating |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004533194A true JP2004533194A (ja) | 2004-10-28 |
Family
ID=8180511
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003508037A Pending JP2004533194A (ja) | 2001-06-21 | 2002-06-20 | データを交換するように構成されたデバイスおよび認証の方法 |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US20040187001A1 (ja) |
| EP (2) | EP1271875A1 (ja) |
| JP (1) | JP2004533194A (ja) |
| KR (1) | KR20030027066A (ja) |
| CN (1) | CN1518825A (ja) |
| BR (1) | BR0205665A (ja) |
| RU (1) | RU2295202C2 (ja) |
| WO (1) | WO2003001764A1 (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009520438A (ja) * | 2005-12-20 | 2009-05-21 | ソニー エリクソン モバイル コミュニケーションズ， エービー | ユニバーサルプラグアンドプレイ及びインターネットマルチメディアサブシステムネットワークのための通信ネットワーク装置 |
| WO2010109763A1 (ja) * | 2009-03-23 | 2010-09-30 | 日本電気株式会社 | 暗号化通信システムにおける通信方法および装置 |
Families Citing this family (64)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4600042B2 (ja) * | 2002-12-06 | 2010-12-15 | ソニー株式会社 | 記録再生装置およびデータ処理装置 |
| US7388958B1 (en) * | 2002-12-19 | 2008-06-17 | Palomar Products, Inc. | Communication system segregating communications by security level |
| FR2854016A1 (fr) * | 2003-04-17 | 2004-10-22 | Thomson Licensing Sa | Methode de transmission des messages de reinitialisation de bus ieee 1394 et appareil implementant la methode |
| US7694330B2 (en) | 2003-05-23 | 2010-04-06 | Industrial Technology Research Institute | Personal authentication device and system and method thereof |
| US20130059541A1 (en) * | 2003-06-10 | 2013-03-07 | Abbott Diabetes Care Inc. | Wireless Communication Authentication for Medical Monitoring Device |
| KR100953160B1 (ko) | 2003-06-26 | 2010-04-20 | 삼성전자주식회사 | 네트워크 장치 및 이를 이용하는 상이한 저작권 관리방식을 갖는 네트워크 장치간의 컨텐츠 호환성 제공 방법 |
| US8015399B2 (en) | 2003-09-30 | 2011-09-06 | Ricoh Company, Ltd. | Communication apparatus, communication system, certificate transmission method and program |
| KR100567827B1 (ko) * | 2003-10-22 | 2006-04-05 | 삼성전자주식회사 | 휴대용 저장 장치를 사용하여 디지털 저작권을 관리하는방법 및 장치 |
| US7296296B2 (en) * | 2003-10-23 | 2007-11-13 | Microsoft Corporation | Protected media path and refusal response enabler |
| JP4350549B2 (ja) * | 2004-02-25 | 2009-10-21 | 富士通株式会社 | デジタル著作権管理のための情報処理装置 |
| US20060242406A1 (en) | 2005-04-22 | 2006-10-26 | Microsoft Corporation | Protected computing environment |
| CN1918526B (zh) | 2004-04-30 | 2012-03-14 | 富士通半导体股份有限公司 | 信息管理装置以及信息管理方法 |
| US7877608B2 (en) * | 2004-08-27 | 2011-01-25 | At&T Intellectual Property I, L.P. | Secure inter-process communications |
| JP4895346B2 (ja) | 2004-11-19 | 2012-03-14 | キヤノン株式会社 | 通信装置及びシステムならびにそれらの制御方法 |
| FR2879780B1 (fr) * | 2004-12-17 | 2007-06-08 | Canon Europa Nv Naamlooze Venn | Procede de restriction de l'acces a au moins un contenu, produit programme d'ordinateur et dispositif recepteur correspondants |
| US9436804B2 (en) | 2005-04-22 | 2016-09-06 | Microsoft Technology Licensing, Llc | Establishing a unique session key using a hardware functionality scan |
| US9363481B2 (en) | 2005-04-22 | 2016-06-07 | Microsoft Technology Licensing, Llc | Protected media pipeline |
| KR100925732B1 (ko) * | 2005-05-27 | 2009-11-11 | 엘지전자 주식회사 | 장치관리에서의 부트스트랩 메시지 보안 전송 방법 및 장치 |
| KR20080021834A (ko) * | 2005-06-29 | 2008-03-07 | 엔엑스피 비 브이 | 다수의 디바이스들을 포함하는 적어도 하나의 구성의무결성을 보호하는 보안 시스템 및 방법 |
| US20070014403A1 (en) * | 2005-07-18 | 2007-01-18 | Creative Technology Ltd. | Controlling distribution of protected content |
| US7634816B2 (en) * | 2005-08-11 | 2009-12-15 | Microsoft Corporation | Revocation information management |
| EP1758337B1 (fr) * | 2005-08-23 | 2012-08-01 | Alcatel Lucent | Procédé de transmission securisée de données, via des reseaux, par échange d'informations d'encryptage, et dispositif d'encryptage/decryptage correspondant |
| JP4663497B2 (ja) * | 2005-12-01 | 2011-04-06 | 株式会社日立製作所 | 情報処理システムおよび情報処理装置の割当管理方法 |
| CN1984482B (zh) * | 2006-05-24 | 2010-05-12 | 华为技术有限公司 | 限制用户对媒体对象操作的方法及移动终端 |
| JP2008059561A (ja) * | 2006-08-04 | 2008-03-13 | Canon Inc | 情報処理装置、データ処理装置、および、それらの方法 |
| US7817802B2 (en) * | 2006-10-10 | 2010-10-19 | General Dynamics C4 Systems, Inc. | Cryptographic key management in a communication network |
| EP1921557A1 (en) * | 2006-11-13 | 2008-05-14 | Jaycrypto Limited | Certificate handling method and system for ensuring secure identification of identities of multiple electronic devices |
| US8079071B2 (en) * | 2006-11-14 | 2011-12-13 | SanDisk Technologies, Inc. | Methods for accessing content based on a session ticket |
| US8423789B1 (en) * | 2007-05-22 | 2013-04-16 | Marvell International Ltd. | Key generation techniques |
| EP2001188A1 (en) * | 2007-06-08 | 2008-12-10 | F.Hoffmann-La Roche Ag | Method for authenticating a medical device and a remote device |
| CZ306790B6 (cs) * | 2007-10-12 | 2017-07-07 | Aducid S.R.O. | Způsob navazování chráněné elektronické komunikace mezi různými elektronickými prostředky, zejména mezi elektronickými prostředky poskytovatelů elektronických služeb a elektronickými prostředky uživatelů elektronických služeb |
| CN100495964C (zh) | 2007-12-03 | 2009-06-03 | 西安西电捷通无线网络通信有限公司 | 一种轻型接入认证方法 |
| KR101456698B1 (ko) * | 2007-12-13 | 2014-10-31 | 주식회사 케이티 | 디지털 컨텐츠 제공 방법 및 방법 프로그램을 저장한기록매체, 디지털 컨텐츠 제공 시스템 및 가입자 단말 장치 |
| KR20100112131A (ko) * | 2008-01-21 | 2010-10-18 | 소니 주식회사 | 정보 처리 장치, 디스크, 및 정보 처리 방법, 및 프로그램 |
| DE102008006840A1 (de) * | 2008-01-30 | 2009-08-13 | Continental Automotive Gmbh | Datenübertragungsverfahren und Tachographensystem |
| US8510560B1 (en) | 2008-08-20 | 2013-08-13 | Marvell International Ltd. | Efficient key establishment for wireless networks |
| KR101595043B1 (ko) | 2008-09-18 | 2016-02-17 | 마벨 월드 트레이드 리미티드 | 적어도 부분적으로 부팅 동안에 어플리케이션들을 메모리에 프리로딩하는 방법 |
| CN101499908B (zh) * | 2009-03-20 | 2011-06-22 | 四川长虹电器股份有限公司 | 一种身份认证及共享密钥产生方法 |
| DE102009022233A1 (de) * | 2009-05-20 | 2010-11-25 | Feustel, Dietmar | Verwendung einer Zeichenkette in Sytemen der Kryptographie, der Statistik, der Simulation, der Randomisierung, von Spielautomaten und dgl. |
| US8914628B2 (en) | 2009-11-16 | 2014-12-16 | At&T Intellectual Property I, L.P. | Method and apparatus for providing radio communication with an object in a local environment |
| WO2011117677A1 (en) * | 2010-03-24 | 2011-09-29 | Nokia Corporation | Method and apparatus for device-to-device key management |
| US8930692B2 (en) * | 2010-07-23 | 2015-01-06 | Silicon Image, Inc. | Mechanism for internal processing of content through partial authentication on secondary channel |
| US9077734B2 (en) * | 2010-08-02 | 2015-07-07 | Cleversafe, Inc. | Authentication of devices of a dispersed storage network |
| US8645716B1 (en) | 2010-10-08 | 2014-02-04 | Marvell International Ltd. | Method and apparatus for overwriting an encryption key of a media drive |
| US9436629B2 (en) | 2011-11-15 | 2016-09-06 | Marvell World Trade Ltd. | Dynamic boot image streaming |
| US8843740B2 (en) | 2011-12-02 | 2014-09-23 | Blackberry Limited | Derived certificate based on changing identity |
| US9203609B2 (en) * | 2011-12-12 | 2015-12-01 | Nokia Technologies Oy | Method and apparatus for implementing key stream hierarchy |
| EP2608477B1 (en) * | 2011-12-23 | 2014-03-19 | BlackBerry Limited | Trusted certificate authority to create certificates based on capabilities of processes |
| US9026789B2 (en) | 2011-12-23 | 2015-05-05 | Blackberry Limited | Trusted certificate authority to create certificates based on capabilities of processes |
| US9798695B2 (en) | 2012-08-07 | 2017-10-24 | Nokia Technologies Oy | Access control for wireless memory |
| CN104737570B (zh) * | 2012-10-19 | 2018-08-31 | 诺基亚技术有限公司 | 生成用于第一用户设备和第二用户设备之间的设备对设备通信的密钥的方法和设备 |
| US9575768B1 (en) | 2013-01-08 | 2017-02-21 | Marvell International Ltd. | Loading boot code from multiple memories |
| US9264222B2 (en) * | 2013-02-28 | 2016-02-16 | Apple Inc. | Precomputing internal AES states in counter mode to protect keys used in AES computations |
| US9736801B1 (en) | 2013-05-20 | 2017-08-15 | Marvell International Ltd. | Methods and apparatus for synchronizing devices in a wireless data communication system |
| US9521635B1 (en) | 2013-05-21 | 2016-12-13 | Marvell International Ltd. | Methods and apparatus for selecting a device to perform shared functionality in a deterministic and fair manner in a wireless data communication system |
| US9836306B2 (en) | 2013-07-31 | 2017-12-05 | Marvell World Trade Ltd. | Parallelizing boot operations |
| GB2586549B (en) * | 2013-09-13 | 2021-05-26 | Vodafone Ip Licensing Ltd | Communicating with a machine to machine device |
| US9223942B2 (en) | 2013-10-31 | 2015-12-29 | Sony Corporation | Automatically presenting rights protected content on previously unauthorized device |
| US10979412B2 (en) | 2016-03-08 | 2021-04-13 | Nxp Usa, Inc. | Methods and apparatus for secure device authentication |
| CN106961446A (zh) * | 2017-05-08 | 2017-07-18 | 浙江敢尚网络科技有限公司 | 一种网上交易系统及方法 |
| KR102415628B1 (ko) * | 2018-10-18 | 2022-07-01 | 한국전자통신연구원 | Dim을 이용한 드론 인증 방법 및 장치 |
| CN111314051B (zh) * | 2018-12-11 | 2023-09-12 | 北京思源理想控股集团有限公司 | 一种加解密方法和装置 |
| CN111314050B (zh) * | 2018-12-11 | 2023-06-30 | 北京思源理想控股集团有限公司 | 一种加解密方法及装置 |
| CN112100611A (zh) * | 2020-08-14 | 2020-12-18 | 广州江南科友科技股份有限公司 | 一种密码生成方法、装置、存储介质和计算机设备 |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5949883A (en) * | 1995-09-28 | 1999-09-07 | Entrust Technologies Ltd. | Encryption system for mixed-trust environments |
| WO1998047259A2 (en) * | 1997-03-10 | 1998-10-22 | Fielder Guy L | File encryption method and system |
| US6105131A (en) * | 1997-06-13 | 2000-08-15 | International Business Machines Corporation | Secure server and method of operation for a distributed information system |
| US7095851B1 (en) * | 1999-03-11 | 2006-08-22 | Tecsec, Inc. | Voice and data encryption method using a cryptographic key split combiner |
| PL354839A1 (en) * | 1999-05-21 | 2004-02-23 | Ibm | Method and apparatus for initializing secure communications among, and for exclusively pairing wireless devices |
| AU6097000A (en) * | 1999-07-15 | 2001-02-05 | Frank W Sudia | Certificate revocation notification systems |
| US6871278B1 (en) * | 2000-07-06 | 2005-03-22 | Lasercard Corporation | Secure transactions with passive storage media |
-
2001
- 2001-06-21 EP EP01202382A patent/EP1271875A1/en not_active Withdrawn
-
2002
- 2002-06-20 EP EP02735904A patent/EP1402701A1/en not_active Withdrawn
- 2002-06-20 CN CNA028123824A patent/CN1518825A/zh active Pending
- 2002-06-20 BR BR0205665-8A patent/BR0205665A/pt not_active IP Right Cessation
- 2002-06-20 KR KR10-2003-7002566A patent/KR20030027066A/ko not_active Application Discontinuation
- 2002-06-20 JP JP2003508037A patent/JP2004533194A/ja active Pending
- 2002-06-20 US US10/480,337 patent/US20040187001A1/en not_active Abandoned
- 2002-06-20 RU RU2004101416/09A patent/RU2295202C2/ru not_active IP Right Cessation
- 2002-06-20 WO PCT/IB2002/002415 patent/WO2003001764A1/en not_active Application Discontinuation
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009520438A (ja) * | 2005-12-20 | 2009-05-21 | ソニー エリクソン モバイル コミュニケーションズ， エービー | ユニバーサルプラグアンドプレイ及びインターネットマルチメディアサブシステムネットワークのための通信ネットワーク装置 |
| WO2010109763A1 (ja) * | 2009-03-23 | 2010-09-30 | 日本電気株式会社 | 暗号化通信システムにおける通信方法および装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| US20040187001A1 (en) | 2004-09-23 |
| WO2003001764A1 (en) | 2003-01-03 |
| EP1271875A1 (en) | 2003-01-02 |
| RU2004101416A (ru) | 2005-06-20 |
| CN1518825A (zh) | 2004-08-04 |
| KR20030027066A (ko) | 2003-04-03 |
| EP1402701A1 (en) | 2004-03-31 |
| BR0205665A (pt) | 2003-07-29 |
| RU2295202C2 (ru) | 2007-03-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| RU2295202C2 (ru) | Устройство, сконфигурированное для обмена данными, и способ аутентификации | |
| KR101366243B1 (ko) | 인증을 통한 데이터 전송 방법 및 그 장치 | |
| RU2352985C2 (ru) | Способ и устройство для санкционирования операций с контентом | |
| US7139918B2 (en) | Multiple secure socket layer keyfiles for client login support | |
| KR100601703B1 (ko) | 브로드캐스트 암호화를 이용한 기기의 인증 방법 | |
| US20060155991A1 (en) | Authentication method, encryption method, decryption method, cryptographic system and recording medium | |
| KR20060020688A (ko) | 개선된 안전 인증 채널 | |
| US8010792B2 (en) | Content transmission apparatus, content reception apparatus and content transmission method | |
| US20050086504A1 (en) | Method of authenticating device using certificate, and digital content processing device for performing device authentication using the same | |
| JP2007528658A (ja) | 改良されたドメインマネージャ及びドメイン装置 | |
| JP2007525748A (ja) | コンテンツへのアクセスを認証する方法 | |
| KR101452708B1 (ko) | Ｃｅ 장치 관리 서버, ｃｅ 장치 관리 서버를 이용한ｄｒｍ 키 발급 방법, 및 그 방법을 실행하기 위한프로그램 기록매체 | |
| JP2004362547A (ja) | スマートカードを用いた装置認証によりホームドメインを構成する方法、及びホームドメインを構成するためのスマートカード | |
| KR20090002227A (ko) | 컨텐츠 디바이스의 폐기 여부를 확인하여 데이터를전송하는 전송 방법과 시스템, 데이터 서버 | |
| JP2009505243A (ja) | 取り消し情報管理 | |
| JP2004512735A (ja) | コンテンツ保護のための複数認証セッション | |
| JP2005503717A (ja) | Ｕｓｂ認証インタフェース | |
| JP2004519882A (ja) | 認証方法及びデータ伝送システム | |
| US10521564B2 (en) | Operating a device for forwarding protected content to a client unit | |
| JP4731034B2 (ja) | 著作物保護システム、暗号化装置、復号化装置および記録媒体 | |
| JP2007049759A (ja) | 暗号化装置 | |
| JP5787201B2 (ja) | 情報処理装置および方法、並びに記録媒体 | |
| WO2010119549A1 (ja) | コンテンツデータ再生システム、及び記録装置 | |
| WO2007043014A1 (en) | Method of encrypted communication using a keystream | |
| WO2006073250A2 (en) | Authentication method, encryption method, decryption method, cryptographic system and recording medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050526 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20060710 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080228 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20080526 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20080602 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080828 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080925 |