JP2009517922A - 変化する識別子を使用したセキュアな電子商取引 - Google Patents

変化する識別子を使用したセキュアな電子商取引 Download PDF

Info

Publication number
JP2009517922A
JP2009517922A JP2008542420A JP2008542420A JP2009517922A JP 2009517922 A JP2009517922 A JP 2009517922A JP 2008542420 A JP2008542420 A JP 2008542420A JP 2008542420 A JP2008542420 A JP 2008542420A JP 2009517922 A JP2009517922 A JP 2009517922A
Authority
JP
Japan
Prior art keywords
key
payment
vendor
request
authenticator
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
JP2008542420A
Other languages
English (en)
Other versions
JP2009517922A5 (ja
Inventor
セラーズ,ウィリアム
マリナ,リチャード
コックラン,ウィリアム
Original Assignee
イマジニア・ソフトウェア,インコーポレーテッド
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 イマジニア・ソフトウェア,インコーポレーテッド filed Critical イマジニア・ソフトウェア,インコーポレーテッド
Publication of JP2009517922A publication Critical patent/JP2009517922A/ja
Publication of JP2009517922A5 publication Critical patent/JP2009517922A5/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/085Payment architectures involving remote charge determination or related payment systems
    • G06Q20/0855Payment architectures involving remote charge determination or related payment systems involving a third party
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/12Payment architectures specially adapted for electronic shopping systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/12Payment architectures specially adapted for electronic shopping systems
    • G06Q20/123Shopping for digital content
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821Electronic credentials
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821Electronic credentials
    • G06Q20/38215Use of certificates or encrypted proofs of transaction rights
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827Use of message hashing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829Payment protocols; Details thereof insuring higher security of transaction involving key management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401Transaction verification
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • G06Q30/0601Electronic shopping [e-shopping]
    • G06Q30/0609Buyer or seller confidence or verification
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • G06Q30/0601Electronic shopping [e-shopping]
    • G06Q30/0613Third-party assisted
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10Services
    • G06Q50/18Legal services
    • G06Q50/188Electronic negotiation

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Tourism & Hospitality (AREA)
  • Software Systems (AREA)
  • Technology Law (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Multimedia (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Primary Health Care (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Storage Device Security (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

変化識別子を使用して電子商取引を行う方法およびシステム。1つの方法は、第1の変化識別子で購入者取引データを暗号化するステップと、購入者取引データを認証者デバイスへ送信するステップと、購入者取引データを解読するステップと、支払い要求を生成するステップと、第3の変化識別子で支払い要求を暗号化するステップと、支払い要求を支払い認証者デバイスへ送信するステップとを含むことができる。

Description

関連出願
本願は、2005年11月23に出願された米国特許出願11/286890からの優先権を主張し、米国特許出願11/286890は、2004年5月26日に出願された米国特許出願10/854604の一部継続出願であり、米国特許出願10/854604は、2002年2月27日に出願された米国仮特許出願60/360023の優先権を主張する2003年2月27日に出願された米国特許出願10/248894の一部継続出願である。上記出願の全内容はすべて参照により本願に組み込まれる。
本発明の実施形態は、コンテンツ(テキスト、音声、映像、マルチメディア素材など)の配布に関する。より詳細には、本発明は、コンテンツ所有者の著作権および他の同様の法的権利が守られることを保証する方式でそのようなコンテンツを配信することに関する。
デジタル形態で配信されるコンテンツが増加しており、また、イントラネット、インターネット、ケーブルTVネットワーク等の私設および公衆のネットワークを通じて配信されるデジタル・コンテンツが増加している。そのようなコンテンツの消費者に対して、デジタルのバージョン(アナログ、紙コピー、および他の形態と相対する)は、忠実度の向上、再生の選択肢の改良と増加、対話性その他といった様々な利益をもたらす。オンライン配信またはネットワーク配信は、一般に、より高い利便性と適時性を提供する。オンライン配信はまた、他の配信方法よりも低コストでもあり、この事はコンテンツの発行者にとって利益となる。
現在のデジタル配信コンテンツおよび今後行われる可能性のあるデジタル配信コンテンツの大半は、大半の書籍と同じように、一般には発行者または所有者が、コンテンツを消費者に付与または販売するような形で配信されるが、そうしたコンテンツは、コンテンツが消費者の物理的管理下のみに置かれた後もコンテンツを使用する権利を制限し続ける。例えば、典型的には、コンテンツ所有者がコンテンツの著作権を保持し、そのため、消費者は、許可を得ずにコンテンツを合法的に再生または公開することはできない。他形態のメディアと異なり、デジタル・コンテンツでは、消費者が恒久的なコピーを作ることを許されるか、または配信時にコンテンツを視聴することのみを許されるかに応じて、コンテンツ所有者が価格設定を調整することができる。
デジタルおよびネットワーク配信の価値のある特性にも関わらず、デジタル・コンテンツの不正な複製、海賊行為、および配布(例えばNapsterのユーザにより行われたような配布)が非常に容易であるため、コンテンツ所有者は、なおも一般には、コンテンツ、特に高価値のコンテンツをネットワークを介して配布することに消極的である。アナログのレコーダや、複写機、他の旧来のデバイスと違って、現在の技術では、デジタル・コンテンツの劣化のない(pristine)コピーを無制限に作製することができる。しかも、大半の事例では、デジタル・コンテンツのコピーは、非常に迅速に、あるいはほぼ瞬時に作製されることができる。更に、公開鍵暗号法や、デジタル多用途ディスクに使用されるコンテンツ・スクランブル・システム(「CSS」)等の現在の保護措置さえも破られている。
更に、暗号化されたコンテンツを解除する鍵が一旦合法的または不法に入手または発見されると、そのコンテンツは永久に危険にさらされてしまう。そのようにコンテンツに自由にアクセスできると、鍵の所有者は、解読されたコンテンツのコピーを無限数作製し、配布することが可能になる。鍵が使用されてコンテンツ・アイテムの不法なコピーを出回らせた場合には、最初にその鍵を所有した者まで、不法に配布されたコンテンツをさかのぼることは一般には非現実的である。
コンテンツの配布に加えて、インターネットなどのネットワーク化されたシステムの使用可能性と普及は、商業の地勢を変えた。電子商取引(「e−commerce」)は、ビジネスの大きく且つ重要な部分へと成長した。電子商取引機能を提供することは、企業が全国規模および世界規模で競争するための必須事項となっている。
電子商取引機能の提供に加えて、企業は、セキュアな電子商取引機能を提供することも求められる。大半の購入者は、自分のデータがセキュアに保たれることを保証されない限り、電子商取引を完了するための課金情報や機密情報を提供しない。多くの現在の電子商取引プロトコルは、公開鍵交換プロトコルの一種を用いる。このプロトコルは、買い手と売り手の間にセキュアな接続を確立する。セキュアな接続が確立されると、機密情報(例えばクレジット・カード番号や口座番号等)が買い手から売り手に通信される。そして、売り手は、その情報を使用して企業(例えばクレジット・カード会社や金融機関)から支払いを得る。
しかし、上記のプロトコルでは、クレジット・カード情報あるいは機密情報が一旦売り手に提供されると、売り手は、その情報を無期限に所有する。そのような情報のセキュリティの信用が落ちている事例が発生している。そのようなセキュリティの信用の下落は、消費者が電子取引に慎重になる等の幾つかの問題を呈する。
上記に照らして、コンテンツ所有者の権利が守られることを保証するコンテンツの配布方法およびシステムを提供する必要性がある。また、窃盗者を追跡し、コンテンツの不法な配布を思いとどまらせる機構を提供する必要性もある。更に、セキュアな電子商取引を行う方法およびシステムを提供する必要性がある。
本発明は、特に、コンテンツを配布するための複数パーティー(多当事者)システムを提供する。一実施形態では、消費者、コンテンツ提供者、および認証者の3つの当事者がこのシステムに関係する。コンテンツ提供者から消費者へのコンテンツの配布は、所定のプロトコル、変化するID(mutating ID、変化ID)、およびライセンスを使用して実施される。認証者は、変化IDの配布を管理し、両当事者のアイデンティティ(識別)を検証する。
別の実施形態では、コンテンツを配布するための多当事者システムには4つの当事者が関係する。このシステムは、消費者、サービス・プロバイダ(サービス提供者)、認証者、およびコンテンツ・プロバイダ(コンテンツ提供者)を含む。サービス提供者のサービスを通じてのコンテンツ提供者から消費者へのコンテンツの配布は、所定のプロトコル、変化ID、およびライセンスを使用して実施される。認証者は、変化IDの配布を管理し、1または複数の当事者の識別を検証する。
実施形態は、コンテンツを配布する方法も提供する。コンテンツを配布する一つの方法は、コンテンツ提供者が、消費者へコンテンツを送信する要求を行うことを含む。この要求は、送信されるべきコンテンツの暗号化された識別子を含む。この要求に応答して、消費者は、その要求を暗号化して認証要求を作成し、その認証要求を認証者へ送信する。認証者は、認証要求を確認し、有効である場合には、最初の要求で識別される暗号化コンテンツを消費者へ送信するようにコンテンツ提供者に通知する。認証者は、消費者がコンテンツを解読して視聴または消費することができるように、消費者へ解読鍵を送信する。
別の実施形態では、この方法は、消費者が、サービス提供者へコンテンツ要求を行い、その要求をコンテンツ提供者に中継することを含む。要求に応答して、コンテンツ提供者は、サービス提供者に関する識別情報と、要求されるコンテンツを識別する暗号化情報とを含むライセンスを作成する。ライセンスは、サービス提供者へ送信される。サービス提供者は、コンテンツ提供者からのライセンスを暗号化し、そのメッセージを消費者へ送信する。消費者は、メッセージを暗号化して認証要求を作成し、その認証要求を認証者へ送信する。認証者は、認証要求を確認し、有効である場合には、そのライセンスで指定される暗号化コンテンツを消費者へ送信するようにコンテンツ提供者に通知する。認証者は、消費者がコンテンツを解読して消費できるように、消費者へ解読鍵を送信する。
本発明の実施形態は更に、コンテンツを配布する方法を提供し、この方法では、コンテンツのそれぞれのコピーに一意に透かしが入れられる。この方法は、消費者が、サービス提供者にコンテンツ要求を行い、その要求をコンテンツ提供者に中継することを含む。要求に応答して、コンテンツ提供者は、サービス提供者に関する識別情報と、要求されるコンテンツを識別する暗号化情報と、一意の透かしとを含むライセンスを作成する。ライセンスは、サービス提供者へ送信される。サービス提供者は、サービス提供者からのライセンスを暗号化し、そのメッセージを消費者へ送信する。消費者は、メッセージを暗号化して認証要求を作成し、その認証要求を認証者へ送信する。認証者は、認証要求を確認し、有効である場合、受信されたライセンスで指定される透かしにより透かしが入れられた暗号化コンテンツを消費者へ送信するように、コンテンツ提供者に通知する。認証者は、消費者が透かしの入ったコンテンツを解読して視聴できるように、消費者へ解読鍵を送信する。
別の実施形態では、本発明は、認証者とコンテンツ提供者と消費者を含むコンテンツ配布システムを提供する。コンテンツ提供者は、コンテンツとコンテンツ識別子を有し、そのコンテンツ識別子に関連した第1の変化識別子を生成する。このシステムは消費者デバイスも含み、この消費者デバイスは、コンテンツを受信する要求をコンテンツ提供者へ送信するように、およびコンテンツ提供者からコンテンツを受信するように、動作可能である。消費者デバイスは、要求(リクエスト)の形態でコンテンツ提供者から第1の変化識別子を受信し、第1の変化識別子に関連した第2の変化識別子を生成し、その第2の変化識別子を認証者へ配布する。認証者は、要求の有効性を検証し、その後、要求の有効性について消費者に通知する。要求が有効である場合、コンテンツ提供者はその後コンテンツを暗号化し、暗号化されたコンテンツを消費者へ送信し、認証者は解読コードを消費者へ送信する。
別の実施形態では、本発明は、認証者とコンテンツ提供者を含むコンテンツ配布システムを提供する。コンテンツ提供者は、コンテンツとコンテンツ識別子を有し、そのコンテンツ識別子に関連した第1の変化識別子を生成する。このシステムは、コンテンツの要求を生成するように動作可能な消費者デバイスも含む。また、このシステムは、サービス提供者を含む。サービス提供者は、消費者デバイスから要求を受信し、コンテンツ提供者から第1の変化識別子を受信し、第1の変化識別子に関連した第2の変化識別子を生成し、第2の変化識別子を消費者デバイスへ配布する。消費者デバイスは、第2の変化識別子に関連した第3の変化識別子を生成し、第3の変化識別子を認証者へ配布する。認証者は、要求の有効性を検証し、その後、要求の有効性をサービス提供者に通知する。要求が有効である場合、コンテンツ提供者はその後コンテンツを暗号化し、暗号化されたコンテンツを消費者へ送信し、認証者は、消費者へ解読コードを送信する。
追加的な実施形態は、変化識別子を使用して電子商取引を行う方法を提供する。1つの方法は、第1の変化識別子で購入者取引データを暗号化するステップと、購入者取引データを認証者デバイスへ送信するステップと、購入者取引データを解読するステップと、支払い要求を生成するステップと、第3の変化識別子で支払い要求を暗号化するステップと、支払い要求を支払い認証者デバイスへ送信するステップとを含むことができる。
別の実施形態は、第1のデバイスと第2のデバイスの間に通信を確立する方法を提供する。1つの方法は、取引鍵を求める要求を生成するステップと、要求を第1のデバイスの第1の変化識別子で暗号化するステップと、暗号化された要求を認証者デバイスへ送信するステップと、取引鍵を生成するステップと、取引鍵を含む第1のメッセージを生成するステップと、第1のメッセージを第1のデバイスの第1の変化識別子で暗号化するステップとを含むことができる。
実施形態は、変化識別子を使用して電子商取引を行う方法も提供する。1つの方法は、第1の変化識別子で購入者取引データを暗号化するステップと、購入者取引データを認証者デバイスへ送信するステップと、購入者の証明(credential)を第1の取引鍵で暗号化するステップと、購入者の証明を支払い認証者デバイスへ送信するステップとを含むことができる。この方法は、ベンダ取引データを第2の変化識別子で暗号化するステップと、ベンダ取引データを認証者デバイスへ送信するステップと、ベンダの証明を第2の取引鍵で暗号化するステップと、ベンダの証明を支払い認証者デバイスへ送信するステップとも含むことができる。更に、この方法は、購入者取引データを解読するステップと、ベンダ取引データを解読するステップと、支払い認証者デバイスへの支払い要求を生成するステップと、支払い要求を第3の変化識別子で暗号化するステップと、支払い要求を支払い認証者デバイスへ送信するステップとを含むことができる。また、この方法は、支払い要求を解読するステップと、購入者の証明を解読するステップと、ベンダの証明を解読するステップと、購入者の証明、ベンダの証明、および支払い要求に基づいて第1の応答を生成するステップと、購入者の証明、ベンダの証明、および支払い要求に基づいて第2の応答を生成するステップと、第1の応答を購入者デバイスへ送信するステップと、第2の応答を購入者デバイスへ送信するステップとを含むことができる。
更に別の実施形態は、電子商取引システムを提供する。1つのシステムは、ベンダ・デバイスと、購入者取引データを第1の変化識別子で暗号化し、購入者取引データを認証者デバイスへ送信するように構成された購入者デバイスと、支払い要求を承認または拒絶し、購入者デバイスへの第1の応答を生成し、ベンダ・デバイスへの第2の応答を生成し、第1の応答を購入者デバイスへ送信し、第2の応答をベンダ・デバイスへ送信するように構成された支払い認証者デバイスと含むことができる。認証者デバイスは、購入者取引データを解読し、支払い認証者デバイスへの支払い要求を生成し、支払い要求を支払い認証者デバイスの第3の変化識別子で暗号化し、支払い要求を支払い認証者デバイスへ送信するように構成されることができる。
本発明の一代替実施形態は、暗号化を伴うが、変化識別子は伴わない。一例示的方法は、第1の購入者鍵で購入者取引データを暗号化するステップと、購入者取引データを認証者デバイスへ送信するステップと、購入者の証明を第1の取引鍵で暗号化するステップと、購入者の証明を支払い認証者デバイスへ送信するステップとを含むことができる。この方法は、ベンダ鍵でベンダ取引データを暗号化するステップと、ベンダ取引データを認証者デバイスへ送信するステップと、ベンダの証明を第2の取引鍵で暗号化するステップと、ベンダの証明を支払い認証者デバイスへ送信するステップも含むことができる。更に、この方法は、購入者取引データを解読するステップと、ベンダ取引データを解読するステップと、支払い認証者デバイスへの支払い要求を生成するステップと、支払い要求鍵で支払い要求を暗号化するステップと、支払い要求を支払い認証者デバイスへ送信するステップを含むことができる。また、この方法は、支払い要求を解読するステップと、購入者の証明を解読するステップと、ベンダの証明を解読するステップと、購入者の証明、ベンダの証明、および支払い要求に基づいて、第1の応答を生成するステップと、購入者の証明、ベンダの証明、および支払い要求に基づいて、第2の応答を生成するステップと、第1の応答を購入者デバイスへ送信するステップと、第2の応答を購入者デバイスへ送信するステップとを含むことができる。
変化識別子は好ましいものであるが、前の段落に記載される代替形態は、例えば非対称暗号化方式で実装されることができる。また、鍵が全く変更されないか、ごく時折変更される対称システムを使用することも可能である。本明細書に記載される他の電子商取引プロトコル、システム、および方式もそのように、即ち、非対称暗号化、非変動鍵、または時折変更される鍵を使用するように変更されてよい。
本発明の実施形態は、詳細な説明と図面を考察することにより明らかになろう。
本発明の実施形態を詳細に説明する前に、本発明の適用は、以下の説明に述べられる、または図面に示される構成要素の構造および配置の詳細に限定されないことを理解されたい。本発明は、更に他の実施形態が可能であり、各種の方式で実施または実行されることが可能である。また、本明細書で使用される語句および用語は、説明を目的とするものであり、制限的なものとみなすべきでないことも理解されたい。
特に、本発明は、パーソナル・コンピュータや家庭用コンピュータ、サーバ、および、プロセッサを備え、プログラムや命令セットを実行することが可能な、例えばセット・トップ・ボックスなどの特殊目的のデバイスを含む他のデバイス等の各種コンピュータ・デバイスを使用して実装されることを理解されたい。一般に、本発明は、既存のハードウェア、または当業者により容易に作製されることが可能なハードウェアを使用して実装されてよい。従って、例示的デバイスのアーキテクチャは、一般にはプロセッサと、メモリ(何らかの種)と、入出力デバイスとを有するということを指摘する以外には、詳細には説明しない。幾つかの事例では、デバイスは、オペレーティング・システムと、オペレーティング・システムにより管理されるアプリケーション・プログラムも有する場合がある。ハードウェア・デバイスは一般には、実装される本発明の特定の実施形態におけるそのデバイスの役割に応じて、データを圧縮や、圧縮解除(伸張)し、データを符号化したり暗号化データを復号するいくらかの能力も必要とする。多くの事例では、伸張機能は、ハードウェア実装のMPEGコーデックなどの使用可能なコーデックを使用して提供されることができる。暗号解読機能(解読機能)は、選択された暗号化アルゴリズムを使用して暗号化されたデータを解読することが可能な解読用ハードウェアやソフトウェア・モジュールを使用して提供されることができる。本発明の実施形態で使用するのに適した暗号化アルゴリズムの1つは、Rijndaelアルゴリズムであり、その一例は、http://www.esat.kuleuven.ac.be/ 〜rijmen/rijndael/rijndaelref.zipで入手することができる。
図1は、ネットワークを通じてコンテンツを配布するように構成された例示的システム20を示す。当業者には明らかなように、実際には、インターネット、電話システム、ワイヤレス・ネットワーク、衛星ネットワーク、ケーブルTVネットワーク、および各種の他の私設および公衆のネットワーク等の1または複数のネットワークや通信システムが各種の組み合わせで使用されて、本発明の実施形態または実装をなすために要求または必要とされる通信リンクを、提供することができる。従って、本発明は、特定のネットワークまたはネットワークの組み合わせに限定されない。しかし、使用されるネットワークや通信システムは、データがRijndael暗号化の1つのバージョンで暗号化された通信、セキュア・ソケット・レイヤ(「SSL」)通信、または他の通信などのような、セキュアな通信を支援する能力を有することが好ましい。更に、データは、配線、デジタル衛星サービス(「DSS」)、または物理的に1人の当事者から別の当事者へ物理的に運搬される物理媒体で、1人の当事者から別の当事者へ送られることができる。
図1に示す実施形態では、システム20は、コンテンツ所有者またはプロバイダ(提供者)22、ケーブル会社やインターネット・サービス・プロバイダ等のサービス提供者(プロバイダ)24、消費者26、および認証者28、の4つの参加者(関係者)を含む。1つのみのコンテンツ提供者、サービス提供者、および消費者が示されているが、本発明の大半の実装では、多数のコンテンツ提供者、サービス提供者、および消費者が関係する。更に、必須なのは1つのみであるが、複数の認証者があってもよい。実際には、次の関係、すなわち、認証者の数<コンテンツ提供者の数<サービス提供者の数<消費者の数、が存在する可能性が高いが、ここでも、関係者の数の制限や、各種関係者の数の間の特定の関係の要件はない。
図2に示す別の実施形態では、システム20は、コンテンツ所有者または提供者22、消費者26、および認証者28、の3つの関係者を含む。図には1つのコンテンツ提供者と消費者が示されるが、本発明の大半の実装では、多数のコンテンツ提供者と消費者が関係する。更に、上で述べたように、必須なのは1つのみであるが、2つ以上の認証者があってもよい。ここでも、関係者の数の制限や、各種の関係者の数の間の特定の関係の要件はない。
関係者22、24、26、28は、双方向リンク30、32、34、36、38を介して相互に接続される。これらのリンクは、上記のネットワークのすべてまたは一部から構築される。システム20は、鍵方式の暗号化アルゴリズムを使用し、Rijndaelアルゴリズムなどの現在使用可能なアルゴリズムが使用されてよい。使用されるアルゴリズムの最終的な選択は、アルゴリズムの強度(解読されるという観点から見た)と速度(選択されたアルゴリズムで必要とされる数学演算を行うプロセッサの能力から見た)とのトレードオフを含む各種の要因に応じて決まる。
本発明の一実施形態では、消費者は、例えば「セット・トップ・ボックス」、家庭用コンピュータ、または他のデバイスの形態をとりうる復号プロセッサまたは同様のデバイスを有するものとする。同じ実施形態において、消費者が復号プロセッサの権利管理機能を改竄または他の方法で回避しようとする可能性があると言う意味で、復号プロセッサは「敵対環境」にあるものと想定される。そのため、復号プロセッサは、その内部への侵入を検出する能力を有する容器に収容されることが好ましい。また、復号プロセッサは、電力が供給されなくなった後もデータが損なわれずに保たれる不揮発性RAM、EPROM、または他の記憶機構などの「永続的」なメモリを有することも好ましい。永続メモリは、識別情報を記憶するために使用され、識別情報は、好ましくは時間の経過と共に変化する「変化ID(mutating ID)」であってよい。
好ましい実施形態では、システム20は、乱数発生器を使用して、このシステムで実装または準拠されるプロトコルで使用される何らかの数を生成する。乱数発生器は、本発明の実装に使用される特定の技術で可能な限り真にランダムな数を生成することが好ましい。一実施形態では、コンテンツを入手するための消費者からの要求などのような通信トラフィックを使用して乱数を作成する。そのような要求は、一般には、予測不能な形で発生する。そのため、そのようなトラフィックに基づいて生成される乱数は、アルゴリズム的な方法で生成される擬似乱数と異なり、真またはほぼ真にランダムになる。
図の例示的実施形態では、システム20のそれぞれのパーティー(当事者)22〜28は、異なる責任を有し、それぞれの当事者は認証者28を信頼するものと想定される。更に、コンテンツ提供者22、サービス提供者24、および消費者26には、変化または変動する識別子(「ID」)が割り当てられることが好ましい。この識別子については下記で更に説明する。
コンテンツ提供者(“アリス(Alice)”)
コンテンツ提供者(コンテンツ・プロバイダ)22は、映画製作会社や、録音会社、あるいは電子的にコンテンツを配信することを望む任意の他のエンティティ等のエンティティである。一般には、コンテンツ提供者22は、コンテンツの著作権または他の知的財産権を所有するか、または、そのような権利の所有者によりコンテンツの配布を許可されているものと想定される。コンテンツ提供者22は、システム20を使用して配布される自身のコンテンツの各コピーについて公正に支払いを受けることを望むものと想定する。また、コンテンツ提供者22は、そのコピーが割り当てられたサービス提供者24と消費者26の両方まで自身のコンテンツの提供済みの各コピーを追跡することを望むものと仮定する。従って、本発明の一実施形態では、システム20は、コンテンツ提供者22が変化ID(一般には必要時に作成される)のリストを使用してコンテンツのライセンスの仮想目録を生成することができるように構成され、各ライセンスは、提供されたコンテンツのコピーを視聴する、または一部の事例では維持する、という権限を付与する。仮想目録(またはライセンスのセット)は、1または複数のサービス提供者等の各種の配布エンティティに割り当てられることができる。仮想目録が消費されると、何れのサービス提供者24がその消費者の1人にコンテンツのコピーを提供したかを記録、ログにとる、または記すために、その消費が追跡される。例えば、仮想メモリを追跡することにより、ケーブル会社と衛星放送会社に配布権を販売した映画製作会社などのコンテンツ提供者は、それらエンティティ、即ち、ケーブル会社と衛星放送会社のどちらがそのコンテンツを対象消費者に配布したかを判断することができる。好ましい実施形態では、コンテンツ提供者22が自身のコンテンツの唯一の暗号化実施者(encrypter)であり、下記で更に説明するように、例えば要求を拒絶することにより、コンテンツの復号を制御する。
本発明の別の実施形態では、システム20は、コンテンツ提供者22が透かし(watermark)のリストを生成し、自身のコンテンツの各コピーに一意の透かしを適用し、変化ID(一般には必要時に作成される)のリストを使用して、透かしが入れられたコンテンツについてのライセンスの仮想目録を生成することができるように構成される。ここで、各ライセンスは、提供された透かし入りコンテンツのコピーを視聴する権限、または事例によっては保持する権限を付与する。仮想目録(即ち、ライセンスのセット)は、1または複数のサービス提供者などの各種の配布側エンティティに割り当てられることができる。仮想目録が消費されると、何れのサービス提供者24がその消費者の1人にコンテンツのコピーを提供したか、更にはどの消費者が特定の透かし入りコンテンツを受信したかを記録、ログにとる、または記すために、その消費が追跡される。例えば、仮想メモリを追跡することにより、ケーブル会社と衛星放送会社に配布権を販売した映画製作会社などのコンテンツ提供者は、それらエンティティ、即ち、ケーブル会社と衛星放送会社のどちらがそのコンテンツを対象消費者に配布したかを判断することができる。透かし入りのコンテンツは特定の消費者に対応付けられる(マップする)ことができるので、追跡システムは、個々の消費者の消費活動を記録またはログ記録することも可能にする。
サービス提供者(“ボブ(Bob)”)
図の実施形態では、サービス提供者(サービス・プロバイダ)24が、コンテンツ提供者のコンテンツを配布する。しかし、サービス提供者は、変化IDによる自身と対象コンテンツの識別を含む幾つかの追加的な責任を負ってもよい。ここで説明する実施形態では、適切な変化IDを持たない消費者26等のユーザは、コンテンツを復号することができない。多くのシナリオでは、サービス提供者24は、サービス提供者24にとってローカルな記憶デバイスから、要求されたコンテンツを提供する。しかし、本発明では、コンテンツの場所は何れの特定の場所にも限定されず、コンテンツは、コンテンツ提供者22のストレージから取り出され、その後消費者26に転送されてもよい。本発明の好ましい実施形態では、すべてのサービス提供者24がシステム20内の消費者からの各要求を見て、認証者28から認証を受信する。一部の実施形態では、特定の実施形態におけるサービス提供者の何れか1つが、コンテンツを消費者へ発送または転送する役割を担ってよい。これにより、コンテンツ提供者は、望まれる場合には、自身のコンテンツをサービス提供者に配信する必要性を回避することができる。即ち、サービス提供者24は、消費者から注文されたコンテンツを(ローカルのストレージに暗号化されたコピーを保持すること等により)所有する必要がない。
消費者(“キャロル(Carol)”)
少なくとも一部の消費者が代金を支払わずにコンテンツを視聴または消費することを望む、または、試みる場合があるものと想定する。そのため、不正なコンテンツの消費を防止するための措置が提供される。上述の変化IDは、コンテンツの復号、および、従ってコンテンツの消費を規制するための1つの機構を提供する。複数の変化IDをカプセル化することにより、下記でより詳細に説明するように、セット・トップ・ボックスは、認証者28に対して、1)そのセット・トップ・ボックスが、認可されたコンテンツのデコーダであること、2)サービス提供者24が認可されたコンテンツの配布者であること、および、3)コンテンツ自体が、消費者のためにコンテンツ提供者22により使用を認可されたこと、を証明することができる。
認証者(“トレント(Trent)”)
認証者28は、特定のコンテンツ、または適用可能な場合には透かし入りのコンテンツを復号するために必要なデータを保持するリポジトリである。ここで論じる実施形態では、認証者28は、対象消費者26に復号の情報を送信する前に、消費者26、サービス提供者24、およびコンテンツをそれらの変化IDで検証する。認証者28は、変化IDの供給元でもあり、データベースあるいは同様の機構を使用してそのIDを追跡する。
変化ID
例示的な変化ID38が図3aに示されている。変化ID38は、第1の部分40と第2の部分42の2つの部分を有する識別子である。第1の部分40は、識別番号であり、これは乱数である。第2の部分42は、符号化/復号化鍵であり、これも乱数であり、好ましくは対称暗号鍵である。本明細書で論じる実施形態で実装される場合、変化IDは、1回のみ使用されることができ、その後再度使用できない。変化IDは、認証者28により生成され、追跡される。変化IDは、使い捨て(one−time−use、一回使用)の機構なので、サービス提供者または消費者または他のエンティティが自身に供給された分の変化IDを使用してしまうと、認証者28から追加的な変化IDを入手しなければならない。変化ID中のデータは、すべての変化IDの確率を等しくしてランダムに選択される。特定のコンテンツの要求または復号が行われると、3つの変化ID(消費者、サービス提供者、コンテンツ)が破棄され、下記でより詳細に説明する要領で、更なる取引のための新しい変化IDが生成される。システム20の当事者にどのように変化IDが配布されるかに関する情報も図3bおよび3cで提供される。具体的には、このシステムのエンティティは、望まれる使用に応じて、多数の変化IDまたは単一の変化IDを受け取ることができる。本発明の一実施形態では、コンテンツ提供者とサービス提供者の両方の機能を行うことができる提供者43が、認証者に複数の数/鍵の対を要求することができる。コンテンツ・アイテムの各コピーは、一意の数/鍵の対から作られる一意のライセンスを持たなければならないため、それぞれの提供者43は、多数の数/鍵の対を必要とする。認証者は、提供者43が要求する数だけの変化IDを作成し、対のリスト26を提供者43に送り返す。提供者43は、要求した数/鍵の対の数量と各対のサイズを把握しており、リストを個々の数/鍵の対に分ける。本発明の他の実施形態では、コンテンツ配布システムの各エンティティは、自身を認証者に対して識別するために変化IDを必要とし、1つの変化IDを使用すると、エンティティは、認証者に新しい変化IDを要求する。1つの新しい変化IDがそのエンティティへ送信され、その新しい変化IDがエンティティの以前の変化IDに取って代わる。
明らかなように、本発明の実施形態は、対称鍵システムである。対称鍵システムは、通例、システムのエンティティ数が増えるにつれて、鍵管理の問題が生じる。例えば、n個のエンティティからなるネットワークは、すべてのエンティティが互いと通信することを可能にするためにn(n−1)/2個の鍵を必要とする。従って、1000個のエンティティのシステムで、すべてのエンティティが同じコンテンツをすべての他のエンティティへ送信したい場合には、50万個近くの鍵が必要となる。
しかし、ここに開示される実施形態は、システムのすべてのエンティティ対に対して別個の鍵を必要としない。下記で例示するように、各エンティティと配布されるコンテンツは、1つの鍵を受け取り、その鍵は1回使用されるごとに変更される。1000個のエンティティからなるシステムの場合は、以前の対称鍵システムにおける50万個近くの鍵と比べて、わずか2000個の鍵で済む。また、認証者は、変化IDのビット列全体を記憶する必要はない。認証者は、ハッシュ関数または単に位置のインデックスを使用して、変化IDの各鍵パーティションを、対応する数に基づくメモリ記憶位置に対応付けることができる。
本発明の実施形態と以前のセキュリティ・システムとの他の違いは、速度と、特定の攻撃に対する脆弱性の低下とに関する。対称鍵の使用により高速の計算も可能になり(公開鍵システムと比べて)、選択平文攻撃の影響を低減させる。本発明の実施形態は、公開鍵ではなく対称鍵を使用するため、比較的高速である。公開鍵システムの背後にある基本的な概念は、一方向関数の使用である。一方向関数は、計算が容易であるが、逆方向に計算するのが難しい。公開鍵システムは、逆方向に一方向関数を計算するための鍵を提供するトラップドア一方向関数を使用する。公開鍵システムは、自由に使用され、メッセージに適用する一方向関数として使用される公開鍵を、各関係者に提供する。公開鍵システムは、一方向関数の計算を与えられたメッセージを計算するために、プライベート鍵(少なくとも当初の考えでは公開鍵からは導出できない)も各関係者に提供する。公開鍵システムのセキュリティは、公開鍵からプライベート鍵を導出できないことに依拠する。この要件を維持するために、公開鍵システムで使用される一方向関数は複雑である。しかし、この複雑性の増大は、計算時間が増すという代償となる。公開鍵システムは、しばしば、対称鍵システムよりも1000倍低速である。
攻撃への脆弱性が低下することに関しては、選択平文攻撃は、侵入者が暗号鍵または暗号化プロセスへのアクセス権を持ち、暗号化する特定の平文を選択し、暗号化されたテキストから知識を得ることを試みる時に発生する。公開鍵システムでは、一人の個人の公開鍵は、通信システム内のすべての関係者に知られる。どの侵入者でも、個人の公開鍵を使用して無限数のメッセージを暗号化することができる。攻撃者がある個人の公開鍵で適当なメッセージを暗号化し、その後、その個人へ送信される暗号化メッセージを傍受した場合、侵入者は、傍受したメッセージを、自身が作成したメッセージと比較することができる。傍受メッセージが、侵入者により作成された暗号化メッセージと一致する場合、そのメッセージは危険にさらされたことになり、侵入者は、自分宛ではないメッセージを読むことができるようになる。この攻撃は、少数の適当なメッセージが存在する場合には容易で効果的であるが、メッセージの数が、侵入者が暗号化することが可能なメッセージの数または傍受した暗号化メッセージと比較することが可能なメッセージの数よりも多い場合でも、傍受された暗号化メッセージが特定のメッセージと対応しないということが分かることだけでも、侵入者には有用な情報が得られたこととなる。何れの状況でも、侵入者は、その個人のプライベート鍵は推測できないが、その個人へ送信されるメッセージまたはそのメッセージに関する情報は推測できる可能性がある。本発明の実施形態は対称鍵システムを使用し、暗号鍵が公に知られていないので、選択平文攻撃を適用することができない。
従来の対称鍵システムおよび公開鍵システムには別の問題もある。権限のないエンティティが、権限のある鍵へのアクセス権を得ると、その権限のないエンティティは、その汚された鍵で暗号化されたすべてのメッセージを復号することができ、そして恐らくはより危険なことには、偽のメッセージを暗号化してそのシステムの他のエンティティをだますことができる。変化IDプロトコルは、使用された後にそれぞれの対称鍵を変化させることにより、この脆弱性を低減する。鍵が汚された場合でも、汚された鍵は、認証者により使用済みとしてマークされ、メッセージの暗号化には二度と使用されないため、将来のメッセージの生成にも将来のメッセージの解読にも使用されることができない。
プロトコル
システム20は、プロトコルを使用してエンティティ間の通信を制御する。各エンティティには、認証者28により以前に変更されたIDにタグ付けされる使い捨て(ワンタイム・ユーズ)の数/鍵の対、即ち、変化ID(図3aに示す識別子あるいはID38)がランダムに割り当てられる。先に述べたように、それぞれの変化IDは、乱数40と、それに対応するランダムの符号化鍵42を含む。使い捨ての数/鍵の対は、変更されたハッシュの形態をとることができる。ランダムであることに加えて、使い捨ての数/鍵の対またはハッシュは、一度解読されるごとに直ちに破棄される。言い換えると、このプロトコルは、ハッシュまたは使い捨ての数/鍵が必要とされる時には、それまでに使用されたことのない新しい乱数を生成する。コンテンツ配布システムに参加するエンティティを識別することに加えて、使い捨ての数/鍵は、それを使用するエンティティとは完全に無関係のハッシュでもある。即ち、このハッシュは、エンティティの識別に関する何の情報も含まない。このようにして、エンティティの識別は、認証者28を除いてはどの関係者にも公開されない。
認証者28は、システム20を通じて配布されるコンテンツの暗号鍵も生成する。コンテンツの配布を希望するエンティティは、何れも鍵を要求する。コンテンツを送信する側のエンティティは、配布するコンテンツの関数または識別文字列を認証者に供給し、認証者は、関連した鍵で応答する。鍵は、変化IDと同様に、その鍵が暗号化するコンテンツには関係しない。コンテンツの関数またはランダムの識別子のみが提供されるので、認証者も真のコンテンツについての知識を持たない。認証者は、コンテンツの鍵および関連した関数、または識別文字列を記録する。認証者は、合法な要求を行うシステム20の許可されたエンティティに鍵を供給する。コンテンツ・アイテムに関連した鍵を求める要求は、そのコンテンツ・アイテムの関数または識別文字列への参照を含む。認証者28は、要求に示される関数または識別文字列と一致する鍵を探し、見つかった鍵を返す。
システム20の特定の実施形態は、暗号化アルゴリズムおよび乱数発生器とともに実装される。暗号化アルゴリズムは、好ましくは、対称鍵に基づく暗号化アルゴリズムである。鍵は、順列の識別、オフセット、およびスキップである。これら3つすべてがまとめられて、「鍵」と呼ばれる1つのオブジェクトにされることができる。従って、本発明の実施形態では、任意の鍵方式の暗号化アルゴリズムが使用されることができる。新しい暗号化アルゴリズムの導入は、非常に時間がかかるプロセスである可能性があるので、システム20は、既存の試験済みの鍵方式暗号化アルゴリズムの使用を可能にするように作成された。
乱数の発生に関して、ここに示す実施形態では、3つの異なる手順が使用される。無論、乱数の手順の他の組み合わせを使用して乱数を発生させてもよい。第1の乱数発生手順は、標準的な合同法乱数である。第2の乱数発生手順は、ランダム・ストリームのサンプリング・レートを決定するために使用される乱数を生成する。
ランダム・ストリームの入手は、困難である可能性がある。従来の定義によると、ランダム・ストリームまたは数の集合は、その集合が、それらの数を表す最もコンパクトな方式である時に限り、ランダムとみなされる。例えば、集合2、4、6、8、10、
Figure 2009517922
を与えられた場合には、よりコンパクトな表現は、{2i|i∈Z+}、即ち、正の整数の集合中のすべての偶数となる。これを示す別の方法は、識別可能な「パターン」が存在しない数の集合である。暗号化通信の目的は、送信される暗号化データからすべてのパターンを取り除き、それにより、知的な推測を使用して暗号化送信データを解読することができないようにすることである。システム20の実施形態では、認証者28が、コンテンツの配布および送信で使用されるすべての乱数を提供する。より詳細に述べるように、生成される数の数列は、乱数の数列、即ち、ランダム・ストリームであるか、または、少なくとも、ランダム・ストリームに近似したものである。
乱数発生器の第3のプロセスは、次の数を取り出すための決定的な方法がないことを保証することである。認証者28に到来し、認証者28から出て行くランダム・ストリームは、暗号化されており、それにより暗号化データを含んでいる。ランダム・ストリームを生成するために使用されるこの非決定的な機構は、乱数の数列がそれよりコンパクトな表現で表せないことを保証し、従って、ランダム・ストリームを定義することを助ける。
例えば、認証者28は、コンテンツを復号する要求を受け取るように設計される。それらの要求は、ランダムな順序で認証者28に到着する。例えば、消費者Xが映画Yの鍵を要求し、消費者Wが歌曲Zの鍵を要求する等と想定する。これらの要求は、意図的に任意とするか又は任意の鍵で暗号化されるかの何れかになるように任意に選択された数の列として、プロトコルにより形式付けられる。要求は本質的に任意であり、任意に処理されるため、必然的に乱数のストリームが生成される。このストリームを準任意の方式(即ち、合同法乱数)でサンプリングすることにより、良好な乱数の数列が生成される。
一実施形態では、システム20で使用されるプロトコルは、パケット組立/分解生成器即ちPAD、鍵のペアリング、およびRC4ランダム・ストリーム暗号を組み合わせる。より具体的には、あるデータ・ウィンドウ中の情報を暗号化するには、PAD生成器が選択されるとPADの数列が生成される。そのPADの数列に基づいて次のように第2のランダム・ストリームPが生成される。
Figure 2009517922
ここでpは、Pの数列のk番目のエレメントであり、pad(kj)modnは、PADの数列のj番目のエレメントである。即ち、Pの数列のエレメントはすべて、PAD生成器で生成された数列のエレメントの排他的論理和(排他的OR)の組み合わせとなっている。鍵の対は、一般に、公開鍵とプライベート鍵を含む。それらの鍵は、数学的関係は持たない。それらの鍵はランダムに、かつ互いからは独立して生成される。鍵自体は、単に、20桁以上の数である。各エンティティは、一意の鍵の対を有する。
次いでプロトコルの例示的実施形態をより詳細に説明する。図1に示す実施形態では、コンテンツ提供者22が暗号化を行う(時に「暗号者」と呼ぶ)。コンテンツ提供者22は、特定の鍵または鍵のセットKでコンテンツを暗号化する。コンテンツ提供者22が鍵のセットKを記憶または保持するか、あるいはそれに代えて認証者28が鍵のセットを保持してもよい。認証者28に保持される場合、認証者28は、鍵のセットKを秘密に保持する。コンテンツ提供者のコンテンツには、秘密の識別ラベル(例えば一般には決して変化しない数)が割り当てられる。このラベルが認証者28に与えられ、認証者は、ラベルを、暗号化されたコンテンツを復号するのに必要とされる鍵に関連付ける。関連付けのプロセスは実際の鍵へのエンティティのアクセスは提供しないため、この関連付けは、間接的である。コンテンツの解読に必要な実際の鍵を持っているのがコンテンツ提供者と認証者のみであるため、これで、暗号化されたコンテンツは、権限のない復号が行われる恐れなく、サービス提供者24または別のエンティティへ与えられることができる。この時点で、コンテンツ提供者22は、コンテンツの仮想目録を作成する。この作成には、コンテンツ提供者22が必要とする又は持つことを望む数だけの変化IDを認証者28に要求することが、伴う。それぞれの変化IDは、正確に1度のコンテンツの使用または消費を許可するライセンスに相当する。先に述べたように、変化IDは、数と鍵である。コンテンツ提供者22は、変化ID鍵で識別ラベルを暗号化し、変化IDの数と暗号化された識別ラベルとを、「暗号化識別子」と称される1つのデータにまとめ、このデータは、ここでは「Econtent」(Eコンテンツ)と表される。
1つのコンテンツが消費されると、認証者28は、その特定のコンテンツの供給元であったサービス提供者24を追跡し、そのような復号があるたびにコンテンツ提供者22に復号を通知する。サービス提供者24は、コンテンツを受信すると、消費者26に配布する前に、それぞれの暗号化コンテンツを他の識別データと組み合わせる。それぞれのサービス提供者24は、その特定のサービス提供者を識別するために使用される変化IDの集合を手元に保持する。すべての他の変化IDと同様に、それらの変化IDは、認証者28により作成され、追跡される。サービス提供者24は、各コンテンツについてのEcontent識別子のリストも有する。要求されると、サービス提供者24は、未使用のEcontent識別子と、所有する未使用変化IDの1つとを選択する。サービス提供者は、選択した変化IDの鍵でEcontent識別子を暗号化し、関連した数を付加して、本明細書で「配布可能コンテンツ」または「Edistrib」(E配布)と称するデータを作成する。サービス提供者24は、Edistribコンテンツを消費者26へ送信し、復号を許可する認証者28からの確認信号を待つ。
確認信号は、Edistribコンテンツを作成するために使用された変化ID鍵で解読されることができる、暗号化されたデータのまとまり(parcel、パーセル)として受信される。確認信号は、サービス提供者24と認証者28により設定された、合意済みの秘密のバイトのセットである。確認信号が受信され検証されると、サービス提供者24は、暗号化コンテンツ即ちEcontent識別子を消費者26へ送信することができる。
上記で述べたように、消費者26がシステム20に不正を働こうとしていると仮定する。この理由から、消費者26と認証者28間のすべての通信は、何らかの暗号化通信方法で暗号化される。消費者26には、1度に1つのみの変化IDが与えられる。消費者26が何らかのコンテンツを視聴または受信したい時、消費者26は、消費者26の場所に配備されたセット・トップ・ボックスまたはハードウェアを使用して、所望のコンテンツの選択を行う。ハードウェア・デバイスは次いで、サービス提供者24にそのコンテンツを要求し、サービス提供者24は、特定の復号のためにEdistribコンテンツを送信する。Edistribコンテンツが消費者26に受信されると、Edistribコンテンツは、消費者の変化ID鍵で暗号化され、変化IDの数と結合されて、Econsumer(E消費者)識別子と称される消費者識別子とされる。Econsumer識別子は、次いで検証のために認証者28へ送信される。検証されると、認証者28は、消費者のセット・トップ・ボックスが対象コンテンツを消費することを認可されていることを、セキュアな通信路でサービス提供者24に通知する。認証者28はまた、現在のセット・トップ・ボックスの変化IDを破棄し、セット・トップ・ボックスに新しい未使用の変化IDを送信する。
消費者26は、同時に別々の供給元から、暗号化されたデータと、そのデータを解読するために必要な鍵を受信する。これにより、復号デバイスは、要求したコンテンツを復号することができる。
変化IDの生成とその追跡は、認証者28の主要な作業である。コンテンツ提供者とサービス提供者への変化IDの配布は、それぞれの受信者だけに変化IDが秘密に保たれる限り、両者へのどのような許容可能な手段を介して扱われてもよい。消費者が絶対に1つより多くの変化IDを持たないことを確実にするために、Econsumer識別子が正確なものであると検証されると、新しい変化IDは、その消費者の現在の変化ID鍵を使用して暗号化され、消費者26へ送信される。そして、消費者は、次の取引にそのIDを使用することができる。認証者28は、すべての変化IDを常に把握しているので、Econsumer識別子が有効な要求であること、または有効な要求を含んでいることを検証することができる。検証するために、認証者28は、Econsumer識別子の中の数に関連した鍵を見つけ、その鍵を解読し、Econsumer識別子を明らかにする。鍵が見つからない場合、認証者28は、「失敗」と返す。全く同じプロセスを使用して、認証者28は、Econtent識別子を復元する。鍵が見つからない場合は、認証者28は「失敗」を返す。再度、認証者28は、可能であれば、Econtent識別子を解読する。解読が可能であれば、認証者28は、サービス提供者24の確認コードを調べ、サービス提供者24により使用される変化ID鍵でその確認コードを暗号化し、サービス提供者へ返す。次いで、新しい変化IDが送信され、続いて復号用のデータが送信される。認証者28は次いで、課金の目的で、その取引に関わるすべての関係当事者、時刻、およびコンテンツを記載または他の方法で記録する。
上記で述べたように、本発明の一態様は、コンテンツのコピーが、権限のないエンティティまたは認可されていないエンティティに入手されないことを保証することである。ここで論じる実施形態では、コンテンツの不正コピーを入手するには、個人またはエンティティは、メッセージを傍受し、次いで、暗号化されたコンテンツを解読することが必要となる。コンテンツが傍受された(これは些細な作業ではない)場合でもそのコンテンツを復号することは非常に難しいので、少なくとも実際的な意味では上記の事は不可能である。その理由は、一つには、ここで論じられる乱数と暗号化アルゴリズムを使用すると、解読に非常に長い時間(数年単位、本発明者の意見では数千年)を要する暗号化データを作成することが可能なためである。種々の攻撃は、一般に、Econsumer識別子を正しく推測するか、または他の形で入手することを必要とする。しかし、それぞれの変化IDは、そのIDの管理者により一回しか使用されないため、別のEconsumerを調べることにより或るEconsumer識別子を推測する方法はない。更に、変化IDは、ランダムになるように計算される(乱数発生器の限界まで)ので、別の変化IDから或る変化IDを計算することは不可能である。
高度のセキュリティを提供することに加えて、このプロトコルは、それぞれの立場の当事者が入れ替え可能であることを考慮する。即ち、複数のコンテンツ提供者が、複数のサービス提供者を使用して、すべての当事者に同意された認証者28を使用して複数の消費者に接触することができる。更に、立場は、多くの異なる配布モデルに適合するように容易に併合または変更されることができる。しかし、一般には、仮想目録はコンテンツ提供者22および/またはサービス提供者により保持されることが要求される。上記で述べたように、仮想目録は、秘密の変化IDを含むリストであることが好ましい。仮想目録は、他の商品のように取引されてよい。そのため、個々のデータは、所望のコンテンツの実際のデジタル・コンテンツであるのではなく、個々のデータは、そのコンテンツを1回視聴させることになる特定の事象のセットにより構築されるEconsumer識別子になる。Econsumer識別子は、間係する全ての当事者の協力なしには構築されることができないので、すべての当事者は、消費者26の要求時に、交渉し、デジタル・コンテンツの消費について相互に利益をもたらす取り決めに達するための能力を有する。1人の当事者が不参加を決めた場合には、認証者28との通信は、1または複数の当事者の同意を取り下げることにより、復号を阻止することができる。
上記で述べたように、システム20は、4つの当事者のみに限定されない。より多くの配布層が導入され、同じ方式で解明プロセスを通じて検証されることができる。例えば、1つのサービス提供者24が、別のサービス提供者に配布を行うことができる。認証者28は、コンテンツ提供者22を見つけるまでEconsumer識別子を解き続けることができる。これは、Econsumer識別子を作成するために使用される単純な再帰アルゴリズムにより達成されることができる。重要な特徴は、認証者28のインプリメンテーションが、Econsumer識別子に基づいてコンテンツの最終的な復号を制御することである。コンテンツ提供者22またはサービス提供者24がダウンストリームの配布を制御したい場合、特定の状況ではコンテンツの復号を拒否することを認証者28に伝えることにより、容易に制御することができる。
次いで、本発明の実施形態を数例を使用して説明する。
通信プロトコルの多くの説明と同様に、このプロトコルで使用される各種エンティティ(またはそれらのエンティティに関連したコンピュータ・システム)には名前が割り当てられる。一実施形態では、アリス(A)、ボブ(B)、およびキャロル(C)が、プロトコルの様々な関係者を表し、トレント(T)が信頼される通信の調整者(arbiter)を表す。下の表、表1は、このプロトコルの複数の実施形態を説明するために本文献で使用される他の記号の一覧である。
Figure 2009517922
このプロトコルの例示的実施形態は、上記のエンティティのうちの3つに関係する。エンティティ・アリスまたはAがコンテンツ提供者22の役割を行い、エンティティ・キャロルまたはCが消費者26の役割を行い、エンティティ・トレントまたはTが認証者28の役割を行う。この提案されるプロトコルは信頼される権限者に依拠するため、アリスとキャロルはトレントを信頼する。また、アリスは、数(N)と、何らかの対称暗号の鍵(K)との、2つの秘密を有する。同様に、キャロルは、秘密の数(N)と鍵(K)を有する。更に、すべての割り当てられる数と鍵は、トレントにより割り当てられ、知られる。
この例のみの目的で、アリスが電子メール・メッセージPをセキュアにキャロルへ送信したいとする。無論、アリスは、各種のコンテンツ・アイテムを配布することを必要とする任意のエンティティを表すものでもよい。テキスト・メッセージの他に、アリスは、本明細書に記載されるプロトコルを使用して、音楽、画像、映像、データ等を配布することもできる。
初めに、アリスがメッセージPをキャロルへ送信したい場合、アリスは、メッセージP用の鍵、すなわち、Pを暗号化するためにアリスが使用するものであり且つPを解読するためにキャロルが使用する鍵を、要求する。そのために、アリスは、メッセージのハッシュを作成する関数を使用してメッセージPのラベルを作成し、そのラベルを彼女のKで暗号化し、Nを先頭に付加する。
A→T:NE(K,H(P))
トレントがアリスからの要求を受信すると、トレントは、アリスの秘密を知っているので、Nに関連した鍵を調べ、メッセージPに使用される鍵の要求を復号する。しかし、トレントは、メッセージPは受信せず、メッセージPのハッシュのみを受信する。トレントは次いで、鍵KP1を生成し、今後の参照のために、その鍵KP1を、供給されたハッシュに関連付けることができる。このプロトコルを使用すると、メッセージはトレントからさえセキュアに保たれ、トレントにより生成された鍵は、その鍵がその後暗号化するデータに関して何の有用な情報も提供しない。トレントは、アリスにより生成されたメッセージを直接知ることを可能にする情報や、アリスにより生成されたメッセージを望まれない当事者へ送信することによりシステムを損壊させることを可能にする情報は、受信しない。各数/鍵の対は1回の使用に有効なので、アリスは、新しい変化IDも要求する。トレントは、メッセージPのための鍵KP1と、新しい秘密の数(N’)と、新しい秘密鍵(K’)をアリスに供給する。トレントは、これら3つのエレメントをアリスの元の秘密鍵で暗号化し、そのメッセージをアリスに送り返す。
T→A:E(KN’K’P1
アリスは、トレントから受信した自身の新しい秘密の数と鍵を認識し、メッセージPのハッシュを新しい秘密鍵K’で暗号化し、N’を先頭に付加し、メッセージをキャロルへ送信する。
A→C:N’E(K’,H(P))
キャロルは、アリスからのメッセージを受信すると、自身の秘密鍵Kでそのメッセージを暗号化し、自身の秘密の数Nを先頭に付加し、メッセージをトレントへ送信する。
C→T:NE(K,N’E(K’,H(P)))
トレントは、Nがキャロルのものであることを認識し、キャロルにより行われた外側の暗号化を解読することができる。トレントは、N’がアリスの秘密鍵であることを認識しているので、アリスにより行われた内側の暗号化も解読することができる。解読すると、トレントは、H(P)がアリスが以前へ送信したメッセージのハッシュであり、自分が以前にそのために鍵KP1を作成したことを判断する。トレントは次いで、アリスがキャロルへメッセージPを送信してよいことを知らせるための、アリスへの受領証を生成し、メッセージPのために以前に生成された鍵とメッセージPのハッシュとをキャロルへ送信する。トレントがアリスのために生成する受領証は、メッセージのハッシュ(キャロルがそのメッセージのハッシュのための解読鍵を要求している)、この例ではH(P)と、キャロルの識別Cidとを含む。メッセージとそのメッセージを受信するエンティティの両方を識別することにより、アリスは、正しい受信者が正しいメッセージを受信することを保証される。キャロルが意図する受信者ではないか、またはメッセージのハッシュがキャロル宛のメッセージではない場合、アリスは、トレントにより生成された受領証に含まれる情報に基づいて、メッセージPを送信しないことを選択してよい。アリスがメッセージPをキャロルへ送信しないことを選択した場合は、キャロルがトレントからそのメッセージ用の解読鍵KP1を受信していても、メッセージPは汚されない。キャロルが受信する鍵(トレントが生成)は、それにより暗号化することになっていたメッセージに関する情報は含んでいない。そのため、アリスがメッセージPを送信しない場合、キャロルは、鍵KP1を持っていることだけではメッセージPの内容を推定することはできない。アリスとキャロルはどちらも自分の現在の秘密鍵と数を使用してしまったので、トレントは、アリスとキャロルの両方に新しい数/鍵の対も生成する。トレントは、受領証(アリスの新しい秘密の数N’’と秘密鍵K’’)を連結し、連結したエレメントをアリスの現在の秘密鍵K’で暗号化し、メッセージをアリスへ送信する。トレントは、メッセージP(キャロルの新しい秘密の数N’と秘密鍵K’)の解読鍵KP1を連結し、連結したエレメントをキャロルの現在の秘密鍵Kで暗号化し、メッセージをキャロルへ送信する。
T→A:E(K’,N’’K’’H(P)Cid
T→C:E(K,N’K’P1H(P))
トレントからのメッセージを受信すると、アリスは、メッセージを復号し、受領証でトレントから彼女へ返されたハッシュH(P)が、彼女がキャロルへ送信したハッシュと同じであるかどうかを判断することができる。これは、アリスに、メッセージを送信する前に、メッセージと意図される受信者とを再確認する機会を与える。上述したように、受領証の何れかの部分が不正であるように思われる場合、例えば、メッセージのハッシュが、アリスがキャロルへ送信したかったメッセージではない場合や、キャロル以外の受信者がメッセージの解読鍵を要求している場合に、アリスは、単に、トレントが生成した鍵で暗号化されたメッセージPを送信しなければよい。すべてが正しく思われる場合、アリスは、トレントにより生成された鍵KP1でメッセージPを暗号化し、暗号化したメッセージをキャロルへ送信することができる。
A→C:E(KP1,P
アリスからの暗号化メッセージPとトレントからの解読鍵を受信すると、キャロルは、受信した解読鍵を受信した暗号化メッセージに適用することにより、メッセージPを復元することができる。
recovered=D(KP1,E(KP1,P))
キャロルは、メッセージのラベルを作成するためにアリスが最初に使用した関数を知っている場合には、アリスから受信したメッセージを検証することもできる。具体的には、キャロルは、Precovered(P復元)のハッシュを、アリスから受信したメッセージPのハッシュと比較することができる。2つのハッシュが同一であれば、キャロルは、アリスから受信した暗号化メッセージが、キャロルとトレントの両方へ送信された最初のメッセージ・ハッシュH(P)に関連していると結論を出すことができる。2つのハッシュが同一でない場合、キャロルは、コンテンツ配布システム内で不正行為が進行中であると確信するだけの理由を得ることになる。
上に挙げた電子メールの例は、より一般的な問題に拡張できる。このプロトコルは、例えば、ネットワークを介してサーバから提供される資源を使用するコンピュータを認証するために使用されることができる。ネットワーク上で接続された多くのユーザは、セキュアな通信のために仮想私設網(「VPN」)に依存するアプリケーションを使用している。VPNのセキュリティは、オープン・システム相互接続(「OSI」)モデルで定義される通信モデルのネットワーク層に組み込まれている。アプリケーション層で変化IDを使用することにより、VPNに代えて仮想私設アプリケーション(“VPA”)を作り出すことができる。VPAを使用すると、電子メール、ファイル・システム、および他のビジネス・レベルのエンドユーザ・アプリケーションは、複雑なネットワーキングを必要とせずに認証することができる。アプリケーション層の通信をセキュアにすることにより、ローカル・エリア・ネットワーク(「LAN」)層でより高いセキュリティが得られる。これは、また、エンドユーザに対するワイド・エリア・ネットワーク(「WAN」)とLANのセキュリティを簡素化する。
変化IDの別の使用は、取引の関係者を認証する際のものである。アリスが、クライアント・コンピュータであるキャロルが使用できる資源を備えたサーバであるとする。ボブは、クライアント・コンピュータであるキャロルのユーザであり、キャロルに特定の資源を使用するように指示するものとする。トレントは、引き続きプロトコルの認証者である。アリス、キャロル、およびボブはすべて、先に述べたように秘密の数Nと秘密鍵Kを有するものとする。更に、トレントはすべての秘密を知っており、アリス、キャロル、ボブは互いの秘密を知らないものとする。
アリスは一度に多くのクライアントに対応する必要があるため、数/鍵の対の大きなリストを必要とする。アリスがすでに1つの数/鍵の対を持っているものと仮定すると、アリスは、認証者トレントと交渉して多くの数/鍵の対を得ることができる。アリスはまず、彼女が適格なサーバであることをトレントに証明する必要がある。そのために、アリスは、アリスに属するものとトレントが認識する何らかの識別子を、x個の数/鍵の対を求める要求とともに暗号化する。
A→T:NE(K,Aid,x個の数/鍵の対を送信)
トレントは、要求の有効性を確認すると、図3bに示すように、数/鍵の対を生成し、それらをKで暗号化して、対のリストをアリスへ送り返す。
T→A:E(K,N ...)
これで、アリスは、数/鍵の対N/Kを破壊してよく、トレントはそれらを使用済みとマークする。このプロトコルは任意の時に実行して、サーバが、要求に対応するのに十分な数/鍵の対を有することを保証することができる。
ユーザであるボブが、彼を識別する証明(例えばパスワード、ユーザ識別子)を、クライアント・コンピュータであるキャロルのクライアント・ソフトウェアへ供給し、キャロルは、ボブの証明と彼女の識別とを彼女の現在の秘密鍵で暗号化し、彼女の現在の数を先頭に付加する。次いで、それが、要求されたサーバ、アリスへ送信される。
C→A:NE(K,Bcredid
(C→A:NE(K,B証明C識別))
次いで、アリスは、受信したメッセージを、彼女の鍵の1つで暗号化し、その鍵に関連した数を先頭に付加する。それが、次いで、認証者トレントへ送信される。
A→T:NE(K,NE(K,Bcredid))
トレントは、メッセージの暗号化を解いて、ボブが、サーバのアリスにあるサービスの使用を希望していることを判断することができる。この時点で、トレントは、ボブとキャロルの識別(ID)を検証し、ボブとキャロルの両方がサーバ、アリスを使用する権限を持つことを確認することができる。識別と許可用の証明とが確認され、承認されると、トレントは、次いで2つのメッセージを生成することができる。第1のメッセージは、キャロル、即ちクライアント・コンピュータ宛であり、Kで暗号化された、新しい数/鍵の対、サーバであるアリスの識別、およびセッション鍵Kを含む。第2のメッセージは、アリス、即ちサーバ宛であり、ユーザであるボブの識別子、クライアント・コンピュータのキャロルの識別、およびKを含む。すべてのコンポーネントは、次いでKで暗号化される。
T→C:E(K,AidN’
(T→C:E(K,A識別N’))
T→A:E(K,Bidid
(T→A:E(K,B識別C識別K))
この時点で、クライアント・コンピュータのキャロルは、鍵Kが、サーバ・アリスとのすべての通信を暗号化するために使用するのに安全であることを知る。更に、アリスは、クライアント・コンピュータのキャロルと、ユーザのボブとのID(識別)がトレントにより確認済みであることを知る。
明らかなように、本発明の上記の実施形態を使用する非セキュアなシステム内のエンティティ間のセキュアな有効性確認は、最小限のステップ数を必要とする。キャロルがアリスとの通信をセキュアに開始するために、キャロルは、アリスに1つのメッセージを送信し、アリスは次いで有効性確認のための要求をトレントへ送る。要求が確認されると、トレントは、キャロルとアリスの両方に、通信に使用するための変化IDを送信する。また、アリスが、要求側エンティティへ発行するために必要とされる彼女の数/鍵の対を、このプロトコルを通じていつでも入手できるようにすることにより、必要なステップ数が減る。アリスは、エンティティが認証者に数/鍵の対を求めるためのサービスを要求することを待つ必要がなく、また、エンティティも、アリスが必要時に一度に1つずつ数/鍵の対を入手することを待つ必要がない。
それと比較して、2つのエンティティ間に正当性が確認された通信を確立するために使用される現行のシステムは、より多くのステップ数を必要とし、そのステップ数は、多数のサービスとサービスを要求するエンティティとを伴うシステムに適用された場合には、高い率で増加する。現行のシステムの中には、サービスと直接通信することを許可される前にエンティティが複数のエンティティとの間で要求を確認しなければないものもある。ログ・オン等の単純な作業に必要とされるステップの数ですら、システムに関連するエンティティやサービス等のコンポーネントの数に対して二次的に増加し得る。多くの現行システムは、すべての関係当事者間のタイムスタンプとクロック同期にも依拠する。エンティティ間で内部クロックが異なる場合、エンティティは、自身を再度認証し、新しいセッション鍵を得ることを要求される場合があり、それが、サービスの使用の正当性を確認するために必要とされる通信を更に増加させる。多数のエンティティが多数のサービスについての確認を要求する際、現行のシステムで発生するオーバーヘッドは、同様の状況で上記の変化IDシステムで必要とされるオーバーヘッドより大きいと考えられる。
このプロトコルの別の実施形態は、先に述べた4つのエンティティすべてに関係する。この実施形態では、アリス即ちAがコンテンツ提供者22の役割を行い、エンティティのボブ即ちBがサービス提供者24の役割を行い、エンティティのキャロル即ちCが消費者26の役割を行い、エンティティのトレント即ちTが認証者28の役割を行う。ここで提案されるプロトコルは、信頼される権限者に依拠するため、アリス、ボブ、およびキャロルは、トレントを信頼する。また、アリスは、数(N)と何らかの対象暗号のための鍵(K)の2つの秘密を有する。ボブも、数(N)と何らかの対称暗号のための鍵(K)の2つの秘密を有する。同様に、キャロルも秘密の数(N)と鍵(K)を有する。更に、すべての割り当てられる数と鍵は、トレントにより割り当てられ、知られている。
この例のみの目的で、アリスが、映画Mを所有する映画製作者であるとする。アリスは、ボブのケーブル会社(例えばビデオ・オン・デマンド)を使用して映画Mを配布することを希望しており、ボブの消費者の1人であるキャロルは、映画Mを受信し、鑑賞したいと思っている。無論、アリスは、各種のコンテンツ・アイテムを配布することを必要とされる任意のエンティティを表すものとすることができる。アリスは、本明細書に記載されるプロトコルを使用して、電子メール・メッセージ、音楽、画像、データ等を配布することができる。
初めに、アリスが彼女のコンテンツを配布したい場合、アリスは、トレントに多数の数/鍵の対を要求する。要求するために、アリスは、その要求を知らせるメッセージPを作成し、その要求を自身のKで暗号化し、Nを先頭に付加する。要求をアリス自身の秘密鍵で暗号化することにより、トレントは、許可された者だけに数/鍵の対が付与されることを確かめることができる。次いでアリスはメッセージをトレントへ送信する。
A→T:NE(K,P
アリスからのメッセージを受信すると、トレントは、アリスの秘密を知っているので多数の数/鍵の対のを要求する要求を解読する。図3bを参照すると、トレントは、ライセンスのリストを生成し、そのリスト全体を、トレントとアリスとの両方に知られているアリスの鍵Kで暗号化してアリスに送り返す。
T→A:E(K,{N ,K )})
そして、アリスは、トレントと連携して、彼女の映画Mの各コピーを暗号化する鍵を受信する。アリスは、Mのラベルを生成し、現在の実施形態ではMのハッシュが使用され、これが映画Mの識別子として使用される。アリスは、何れかの任意の数/鍵の対jを取り出し、MのハッシュをK で暗号化し、N を先頭に付加し、そのメッセージをトレントへ送信する。
A→T:N E(K ,H(M))
アリスは、このプロトコルの他のエンティティに知られている映画Mの一意の識別子Midを、トレントへ送信されるメッセージに含めてもよい。識別子を加えることにより、暗号化コンテンツを要求する要求の突き合わせおよび許可のための機構が、トレントに提供される。
A→T:N E(K ,H(M)Mid
アリスからメッセージを受信すると、トレントは、映画Mのハッシュに関連した鍵Kを生成し、その鍵をK で暗号化してアリスに送り返す。トレントは、送信した鍵Kが映画Mのハッシュ(そして、提供される場合には一意の識別子Mid)に関連付けられていることを記録する。トレントは、暗号化コンテンツの鍵を生成しているにも関わらず、コンテンツは決して受信しない。トレントが受信するのは、映画Mのハッシュと、可能性としては、システムのすべてのエンティティに知られている一意の識別子のみである。トレントは、コンテンツ提供者から提供されるコンテンツに関する他の有用な情報は得ない。トレントは、コンテンツ提供者の介在と許可なしにコンテンツを直接配布することを可能にする情報は持たない。
T→A:E(K ,K
ここでアリスは、彼女とトレントだけがKを知っていることを確信して、MをKで暗号化することができる。アリスはKでMを暗号化し、ボブへ送信する。
A→B:E(K,M)
アリスはまた、ボブに、暗号化されたコピーに対応する一次ライセンスを送信する。このコンテンツ提供者から送信されるライセンスは、配布される前にサービス提供者により更に認証される場合もあるため、一次ライセンスと呼ぶ。アリスは、映画Mのハッシュを鍵K で暗号化し、トレントにより生成されたリストから任意に選択された数/鍵の対kの数N を先頭に付加することにより、それぞれの一次ライセンスを作成する。アリスは、それぞれの一次ライセンスをボブへ送信する。
A→B:N E(K ,H(M))
ボブは、暗号化コンテンツとそれに対応する一次ライセンスの両方を受信しているが、まだ解読鍵は知らず、そのため、アリスが知らないMのコピーを配布することができない。ボブは、暗号化されたコンテンツまたは一次ライセンスの何れかを、アリスまたはトレントからの介入なしに、彼が望むだけの数の消費者へ配布することができる。しかし、消費者は、暗号化されたコンテンツを視聴することも、一次ライセンスを使用することもできない。また、ボブは、暗号化されたコピーからも、一次ライセンスからも、アリスが提供するコンテンツに関する情報を得ない。ボブにライセンスを提供することにより、アリスは、ボブが配信できるコンテンツのコピー数を制限することができる。なぜなら、各ライセンスは消費者に対して発行されると、トレントにより使用済みとマークされるからである。アリスからの有効なライセンスを用いて、サービス提供者および消費者はコンテンツを入手することはできない。アリスには、トレントに知られた数/鍵の対が少なくとも1つ残っているはずである。アリスがより多くの数/鍵の対を必要とする場合は、残っているその1つの数/鍵の対を使用してトレントに更に対を要求することができる。
ボブは、Mの暗号化されたコピーと、それに対応するアリスにより署名された一次ライセンスを受信すると、アリスから送信されたそれぞれの一次ライセンスを更に認証して、ライセンスが消費者へ配布される前に、そのコンテンツに彼の所有権を設定する。ボブにそれぞれの一次ライセンスを更に認証させることは必須ではないが、それによりアリスの映画Mについての保護が増大される。なぜなら、アリスは、コンテンツ・アイテムに対する要求が、許可された配布者を通じて適正に開始されたことを保証することができるからである。それぞれの一次ライセンスに更に高い権限を付加するために、ボブはまず、アリスが上記で定義した多数の数/鍵の対を入手した際と同様の方式でトレントに多数の数/鍵の対を要求する。ボブは、その要求を示すメッセージPを作成し、要求を彼のKで暗号化し、Nを先頭に付加する。次いで、ボブは、メッセージをトレントへ送信する。
B→T:NE(K,P
トレントがボブからのメッセージを受信すると、トレントはボブの秘密を知っているので、Nに関連した鍵を調べ、要求を解読する。そして、トレントは、要求された多数の数/鍵の対を生成し、Kで暗号化してボブに送り返す。
T→B:E(K,{N ,K )})
明らかに、ボブは、アリスから暗号化されたコピーを受信する前に数/鍵の対を要求しても、受信した後に要求してもよい。ボブは、トレントに数/鍵の対を要求するために、アリスから受信するものは何も送信する必要がない。ボブは単に、数/鍵の対を要求および受信することが可能なエンティティとして、トレントに識別可能であればよい。
ボブは、トレントから数/鍵の対を受信すると、トレントから受信したリストから任意の数/鍵の対mを選択し、アリスから受信した暗号化された識別子を鍵K で暗号化し、選択された数/鍵の対mの数N を先頭に付加することにより、配布可能ライセンス、即ち、要求側の消費者へ配布することができるライセンスを、作成することができる。
E(K ,N E(K ,H(M)))
ボブは、彼が配布したい配布可能ライセンスの数だけ、またはアリスにより配布を許可された配布可能ライセンスの数だけこの手順を繰り返す。
この時点でボブはコンテンツを有するので、このプロセスの次のステップについて説明する。キャロルは、コンテンツMの視聴を望んでおり、映画Mの一意の識別子を含む、Mを求める要求をボブへ送信する。
C→B:Midを送信
キャロルからのコンテンツの要求は、破損から保護するために符号化されてよい。要求を符号化しないと、キャロルの要求は傍受され、変更される可能性があり、キャロルは、購入するつもりのなかったコンテンツを受け取る可能性がある。キャロルは、ボブとキャロルの間で共有される秘密鍵で要求を暗号化することにより、要求を保護することができる。キャロルは、本発明の先に開示した実施形態の1つを使用してボブに要求を送信することもできる。概して、キャロルは、任意のセキュリティ機構を使用して彼女の要求のセキュリティを保護することができる。
ボブは、キャロルからの要求を受信し、キャロルの要求に含まれる一意の識別子Midで識別される映画Mのために以前ボブが生成した配布可能ライセンスの1つを選択することにより、返答する。ボブは、配布可能ライセンスをキャロルへ送信し、そして、そのライセンスが使用され、キャロルへ送信されたことを記録する。
B→C:N E(K ,N E(K ,H(M)))
キャロルは、ボブから配布可能ライセンスを受信すると、そのライセンスを彼女の鍵Kで暗号化し、彼女の番号Nを先頭に付加する。キャロルは、暗号化した配布可能ライセンスをトレントへ送信する。
C→T:NE(K,N E(K ,N E(K ,H(M)))
キャロルから暗号化された配布可能ライセンスを受信すると、トレントは、キャロル、ボブ、およびアリスの秘密を知っているので暗号化をすべて解くことができ、そして、キャロルが有効なライセンスを受信しており、コンテンツMの解読鍵を必要としていることを、判断することができる。この情報を復元することにより、トレントは、ボブへの受領証を生成することができ、この生成は、ボブの一次ライセンスをキャロルの識別(ID)と連結して、それを最初に署名された鍵K で暗号化し、ボブがライセンスに署名した時に最初に先頭に付加された数N を先頭に付加することによりなされる。トレントは受領証をボブへ送信する。
T→B:N E(K ,N E(K ,H(M))Cid
ボブがトレントから受け取る受領証は、キャロルが消費者として権限を与えられていることをボブに通知するだけでなく、ハッシュH(M)で指定されるコンテンツの対応する暗号化コピーをキャロルへ送信することをボブに指示する。ボブは、キャロルがトレントへ送った配布可能ライセンスは、ボブが初めにキャロルへ送信した配布可能ライセンスと同じライセンスであることを、検証することもできる。キャロルは別の配布可能ライセンスに置き換えることはできず、また、キャロルがボブから受け取った配布可能ライセンスを別の消費者が使用することもできない。ボブは、トレントからの受領証を検査すると、要求される暗号化コピーをキャロルへ送信する。
B→C:E(K,M)
キャロルは、受信したMの暗号化されたコピーを解読するのに必要な解読鍵と、新しい数/鍵の対との両方を必要とし、それにより、彼女は第2のコンテンツ要求を行えるようになる。なぜなら、彼女は、古い変化IDを映画Mの要求に消費してしまったからである。トレントは、要求されたコンテンツMと、Mのコピーを暗号化するために使用される鍵とを知っており(作成したのがトレントであるため)、トレントは、その鍵を、将来の要求に使用される新しい数/鍵の対とともにキャロルへ送信する。トレントは、新しい数/鍵の対を、Mの暗号化されたコピーに対して必要な鍵と連結し、それらのエレメントをキャロルの現在の鍵Kで暗号化する。トレントは、キャロルに割り当てられた数Nを先頭に付加する必要はない。なぜなら、キャロルは1つしか数/鍵の対を持っておらず、アリスとボブと同様に、数/鍵の対のリストから、数を与えられた一致する鍵を探す必要がある。従って、トレントは、下記のものをキャロルへ送信する。
T→C:E(K,N’K’
あるいは、アリスが、暗号化コンテンツに対しての、キャロルに知られている一意の識別子をトレントに提供した場合、トレントは、解読鍵を送信する前に、コンテンツについての最終的な誓約をキャロルに要求することができる。トレントは、新しい数/鍵の対と、トレントがキャロルから受け取った配布可能ライセンスで指定されたコンテンツに対応する一意の識別子Midとを、キャロルへ送信することができる。
T→C:E(K,N’K’id
この一意の識別子は関係する全エンティティに知られているので、キャロルは、トレントから受信しようとする解読鍵が、彼女が要求したコンテンツの鍵であることを検証することができる。識別子が、要求したコンテンツに対応しない場合、キャロルは、彼女の最初の要求が欠陥を含んでいたか、または損なわれたことを知り、彼女は、トレントがコンテンツの解読鍵を提供するのを止めさせることができる。解読鍵を送信する前に最終的な許可を要求することにより、キャロルは、希望しなかったコンテンツに対する課金を回避することができる。そうでなく、識別子が、要求したコンテンツと一致する場合、キャロルは、解読鍵の送信をトレントに許可することができる。
C→T:E(K,許可)
T→C:E(K,K
これで、キャロルは、映画Mを見るのに必要とするものをすべて持つ。
トレントは、この時点でアリスへの受領証を生成して、アリスが特定のコンテンツまで消費者を追跡できるようにしてもよい。トレントは、Mのラベルとキャロルの識別Cとを連結し、すべてのエレメントをアリスの鍵K で暗号化し、キャロルへ送信されたライセンスで使用される数N を先頭に付加することができる。
T→A:N E(K ,H(M)Cid
トレントは、取引中に遭遇されるすべての数/鍵の対({K ,N },{K ,N },{K,N})を使用済みとマークすることもでき、それにより、将来それらの1つに遭遇した場合には何かがおかしいことが分かる。即ち、トレントは、それぞれの数/鍵の対が1度のみ使用されることを確実にすることができる。従って、対が再使用されることは、エンティティまたは個人がシステムに不正を試みていることの印となる。
この時点で、アリスは、ボブが映画Mのコピーをキャロルへ配布したことを知る。しかし、アリスは、映画Mの特定のコピーをボブまたはキャロルまで追跡することはできない。映画Mの不法に配布されたコピーが市場に出現した場合、そのコピーを、特定のサービス提供者または消費者までたどることはできない。アリスができるのは、そのコンテンツのライセンスを付与したエンティティのリストを生成することのみである。追跡されないということは、映画Mのコピーを合法に購入した消費者が、その入手したコピーを不法に配布することを助長する。
別の実施形態では、アリスは、作成され配布されるそれぞれのコピーに一意に透かしを入れることにより、サービス提供者および消費者までコンテンツ・アイテムの特定のコピーをたどることができる。特定の消費者まで特定のコピーを追跡する手段をアリスに提供することにより、合法にコンテンツを購入した消費者が入手したコピーを不正に複製することを思いとどまらせることができる。
透かしを入れる一実施形態では、エンティティ・アリス即ちAが再びコンテンツ提供者22の役割を行い、エンティティ・ボブ即ちBがサービス提供者の役割を行い、エンティティ・キャロル即ちCが消費者26の役割を行い、エンティティ・トレント即ちTが認証者28の役割を行う。
4つのエンティティを伴う透かしを入れない実施形態と同様に、アリスは、暗号化されたメッセージPでトレントに多数の数/鍵の対を要求する。
A→T:NE(K,P
トレントは、アリスからのメッセージを受信すると、数/鍵の対のリストを生成し、リスト全体をアリスに送り返す。
T→A:E(K,{N ,K )})
アリスが多数の数/鍵の対を受信すると、アリスは、Mのそれぞれのコピーに一意の透かしを適用することにより、彼女のコンテンツを更に保護することを選択することができる。アリスは、透かしのリストD,D,...,Dと、彼女の映画Mの透かし方式Wを生成する。アリスは次いで、Mの多数の異なるハッシュ(それぞれの透かしに1つずつ)を生成することができる。次を考察されたい。
=W(D,M)
=W(D,M)
=W(D,M) ・・・
透かしを入れない実施形態と異なり、アリスは、彼女の映画Mを暗号化するための1つの鍵を受信する代わりに、次いで、トレントと連携して、彼女の映画Mの透かし入りのそれぞれのコピーを暗号化する鍵を受信するようにする。アリスは、Mのラベルと、それぞれの透かしD,D,...,Dのハッシュとを生成し、何らかの任意の数/鍵の対jを選択する。アリスは、Mのハッシュと個々の透かしDのハッシュとの両方をK で暗号化し、N を先頭に付加し、メッセージをトレントへ送信する。
A→T:N E(K ,H(M)H(D))
前の実施形態で述べたように、アリスは、トレントへのメッセージで映画の既知の識別子Midを提供することができ、それにより、トレントは後にその識別子を使用して消費者に最終的な許可を要求できる。
A→T:N E(K ,H(M)H(D)Mid
アリスからのメッセージを受信すると、トレントは、映画Mのハッシュに関連した鍵KM1を生成し、その鍵をK で暗号化してアリスへ送り返す。トレントは、送信した鍵KM1が映画Mのハッシュと透かしDのハッシュ(および、既知の識別子Midが提供される場合はそれも)に関連付けられていることを、記録する。トレントは、暗号化された透かし入りコンテンツのための鍵を生成しているにも関わらず、解読された透かし入りコンテンツは受信しない。ここでも、トレントは、アリスから提供されるコンテンツに関する何の有用な情報ももたない。
T→A:E(K ,KM1
アリスは次いで、M、即ち、透かし入りのコンテンツを暗号化し、それをボブへ送信することができる。
A→B:E(KM1,M
アリスは、ボブに、暗号化された透かし入りのコピーのための対応する一次ライセンスも送信する。アリスは、透かしを入れない実施形態と同じ形式でこの一次ライセンスを作成するが、透かしのハッシュを映画Mのハッシュと連結する。
A→B:N E(K ,H(M)H(D))
ボブは、暗号化された透かし入りのMのコピーと、それに対応するアリスにより署名された一次ライセンスとを受信すると、透かしを入れない実施形態と同様に、それぞれの一次ライセンスを認証する。上記で述べたように、ボブによるそれぞれの一次ライセンスの認証は必須ではないが、通信システムに一層の保護とセキュリティをもたらす。ボブはまず、トレントへメッセージPを送信することにより、トレントから多数の数/鍵の対を入手する。
B→T:NE(K,P
先と同様に、トレントは、ボブからのメッセージを受信し、要求される多数の数/鍵の対を生成し、それらをKで暗号化してボブに送り返す。
T→B:E(K,{N ,K )})
ここでも、ボブは、アリスから暗号化された透かし入りのコピーを受信する前にこの数/鍵の対を要求しても、後に要求してもよい。
透かしを入れない実施形態と同様に、ボブは、トレントから数/鍵の対を受信すると、配布可能ライセンスを作成することができる。
E(K ,N E(K ,H(M)H(D)))
ボブは、彼が配布したい配布可能ライセンスの数だけ、またはアリスにより配布を許可された配布可能ライセンスの数だけこの手順を繰り返す。
キャロルがコンテンツMを視聴したい場合、キャロルは、Mの要求(Mを求める要求)をボブへ送信する。
C→B:Midを送信
先に述べたように、キャロルの要求にさらなる暗号化を適用して、キャロルのメッセージが損なわれないことを保証することもできる。
先と同様に、ボブは、キャロルからの要求を受信し、彼が以前に生成した配布可能ライセンスの1つを選択することにより、応答する。ボブは、配布可能ライセンスをキャロルへ送信する。
B→C:N E(K ,N E(K ,H(M)H(D)))
ボブから配布可能ライセンスを受信すると、キャロルは、透かしを入れない実施形態と全く同様に、そのライセンスを彼女の鍵Kで暗号化し、彼女の数Nを先頭に付加し、暗号化した配布可能ライセンスをトレントへ送信する。
C→T:NE(K,N E(K ,N E(K ,H(M)H(D)))
キャロルから暗号化された配布可能ライセンスを受信すると、トレントは、その暗号化をすべて解くことができる。なぜなら、彼は、キャロル、ボブ、およびアリスの秘密を知っているからであり、彼は、キャロルが有効なライセンスを受け取ったこと、及び透かしDで透かしが入れられたコンテンツMの解読鍵を必要としていることを、判断することができる。透かしを入れない実施形態と同様に、トレントはボブへの受領証を生成する。
T→B:N E(K ,N E(K ,H(M)H(D))Cid
ボブがトレントから受信する受領証は、キャロルが消費者として権限(許可)を与えられていることをボブに通知するだけでなく、ハッシュH(M)およびH(D)で指定されるコンテンツの対応する暗号化コピーをキャロルへ送信することをボブに指示する。
B→C:E(KM1,M
透かしを入れない実施形態と同様に、トレントは、キャロルがボブから受信する映画の暗号化された透かし入りのコピーの解読鍵を、キャロルが今後の要求に使用できる新しい数/鍵の対とともに、送信する。
T→C:E(K,N’K’M1
先に述べたように、トレントは、要求されたコンテンツの、全エンティティに知られている識別子を知っている場合には、この時点で最終的な許可を追加的に要求することもできる。トレントは、キャロルへその識別子を提供し、キャロルは、彼女が受け取ろうとしている解読鍵が、彼女が要求したコンテンツのものであることを、検証することができる。トレントは、キャロルの確認を受信すると、必要とされる解読鍵を送信することができる。
これで、キャロルは、映画Mを見るために必要なものをすべて持つ。
先と同様に、トレントは、この時点でアリスへの受領証を生成して、アリスが特定の透かし入りコピーまで消費者を追跡できるようにしてもよい。トレントは、Mのラベルと、透かしのハッシュH(D)と、キャロルの識別Cとを連結し、すべてのエレメントをアリスの鍵K で暗号化し、キャロルへ送信したライセンスで使用された数N を先頭に付加することができる。
T→A:N E(K ,H(M)H(D)Cid
トレントは、取引中に遭遇されるすべての数/鍵の対({K ,N },{K ,N },{K,N})と透かしDとを使用済みとマークすることもでき、それにより、それらがその後に使用されると不正行為と認識できる。
あるいは、別の透かしの実施形態では、アリスではなくボブがコンテンツのコピーに透かしを適用する。アリスは、ボブに、映画Mの暗号化されたバージョンを1つ送信し、適用する透かしのリストも提供してよい。次いで、ボブは、トレントと連携してコンテンツの解読鍵を受信する。解読鍵を受信すると、ボブは、暗号化されたコンテンツを復号し、解読されたコンテンツに透かしを適用し、透かしを入れたコンテンツを、アリスにより使用された最初の鍵とは異なる別の暗号鍵で暗号化する。ボブが配布可能コンテンツに透かしを入れられるようにすることにより、コンテンツ提供者とサービス提供者の間で必要とされる通信が少なくなり、送信されるデータが少なくなる。サービス提供者は、コンテンツの要求がなされた時にオンザフライで解読と透かしの適用を行ってもよい。必要時にコンテンツに透かしを入れることにより、サービス提供者は、コンテンツの暗号化された透かし入りのバージョンを複数個保持する必要がなくなるので、サービス提供者に必要とされる記憶量が減る。アリスは、暗号化されているが透かしは入れない状態で彼女のコンテンツを提供するので、アリスのコンテンツを解読し、透かしを適用し、消費者へ送信される前に透かし入りコンテンツを再度暗号化するために、本プロトコルの別のエンティティが信頼されなければならない。この解読および透かしの適用を行うためにボブが信頼されてもよいが、アリスは、ボブに、アリスのコンテンツのセキュリティを保護する特殊なハードウェアを使用するように、要求してもよい。解読と透かしの適用がハードウェア(サービス提供者からはアクセスできない)でリアル・タイムで行われることを必要とすることにより、アリスのコンテンツのセキュリティが保たれる。コンテンツは、サービス提供者の特殊なハードウェアへ送信され、そのハードウェアが、コンテンツを復号し、透かしを適用し、コンテンツを再び符号化する。このハードウェアは、サービス提供者が解読されたコンテンツにアクセスすることを阻止する。なぜなら、コンテンツは、ハードウェアに暗号化された状態で入り、透かしが入れられ且つ暗号化された状態でハードウェアを出るからである。プロトコルを機能させるために、コンテンツ提供者は、この特殊なハードウェアのセキュリティを信頼しなければならない。アリスから提供されたコンテンツを復号して透かしを入れる、権限のある特殊ハードウェアまたは復号を行うエンティティを、以下の詳細な例ではB’または「ブレンダ」と表記する。
先と同様に、アリスは、彼女の映画Mの配布を希望しており、彼女の映画の特定のコピーまで消費者を追跡したい。しかし、ボブは、暗号化され、透かしの入ったアリスのコンテンツのコピーを複数受け取り、記憶することは望まない。アリスとボブとの間の通信とデータ・トラフィックを減らすために、ボブは、アリスから提供されたコンテンツに透かしを入れ、暗号化する。
先の2つの実施形態と異なり、アリスは、暗号化された透かしのリストを作成するために彼女が使用する多数の数/鍵の対をトレントに要求することから、開始する。アリスは、数/鍵の対をトレントから受信すると、映画Mの暗号鍵を要求する。また、アリスは、透かしを適用するために、誰が映画の復号を許されるのかを、トレントへの要求で指定することができる。現在の例では、ブレンダが透かしの適用を許可される。アリスは、解読情報を送信する前に要求の正当性を確認するために、トレントに使用されることができる映画の既知の識別子Midも含めてよい。
A→T:NE(K,H(M)MidB’)
トレントは、映画の暗号鍵Kで応答する。
T→A:E(K,K
アリスは、暗号鍵Kを受信すると、映画Mと映画のハッシュH(M)とを暗号化し、暗号化したコンテンツをボブへ送信することができる。
A→B:E(K,H(M)M)
アリスは、暗号化コンテンツのコピーに適用される透かしD、D、...,Dのリストも生成する。それぞれの透かしは、映画のハッシュH(M)と、可能性としては映画の既知の識別子Midと連結される。連結されたそれぞれのリストは、アリスがトレントから受信した数/鍵の対の1つで暗号化される。アリスは、暗号化された透かしのリストをボブへ送信する。あるいは、アリスは、ボブに、アリスのコンテンツに適用する透かしを生成させることもできる。ボブに透かしを作成させることにより、アリスとボブとの間で通信される通信とデータが更に少なくなる。
A→B:N E(K ,H(M)Did),N E(K ,H(M)Did),...,N E(K ,H(M)Did
ボブは、この時点で、ブレンダのみにより解読されることが可能な暗号化された透かしのリストと暗号化された映画Mとを得ている。ブレンダのみによる解読が可能なのは、それがアリスからトレントへの要求でアリスにより指定されたからである。コンテンツの配布を準備するために、ボブとブレンダは、トレントに多数の数/鍵の対を要求する。
ボブは、キャロルから映画Mの要求を受信すると、暗号化透かしをブレンダに提供する。暗号化透かしは、トレントから提供されたリストから任意に選択された数/鍵の対で暗号化されたものであり、ボブがアリスから受信したものである。
B→B’:N E(K ,N E(K ,H(M)Did))
ブレンダは、トレントにより生成されたリストから任意の数/鍵の対を選択し、ボブから受信した二重に暗号化された透かしを更に暗号化する。ブレンダは次いで、三重に暗号化された透かしをトレントへ送信する。
B’→T:N B’E(K B’,N E(K ,N E(K ,H(M)Did)))
トレントは、全員の秘密を知っているので、暗号化したものをすべて復号し、映画のハッシュH(M)、透かしD、映画を復号する鍵K、映画を符号化するための新しい鍵KM’、およびボブの識別Bidを、ブレンダに返す。
T→B’:E(K B’,H(M)DM’id
ブレンダも、ボブから受信した同じ二重に暗号化された透かしを、任意に選択された別の数/鍵の対で暗号化する。ブレンダは、この第2の三重に暗号化された透かしをキャロルへ送信する。
B’→C:N B’E(K B’,N E(K ,N E(K ,H(M)Did)))
キャロルは、受信したメッセージを彼女の1つの数/鍵の対で暗号化し、先と同様に、暗号化したメッセージをトレントへ送る。
C→T:NE(K,N B’E(K B’,N E(K ,N E(K ,H(M)Did))))
トレントは、暗号化をすべて解き、キャロルがそのメッセージで識別される映画を確かに入手するつもりであることを確認する。
T→C:E(K,N’K’id
キャロルは、コンテンツ識別子Midが、彼女が要求したコンテンツに対応する場合、許可をもって応答する。
C→T:E(K,許可)
次いで、トレントは、解読鍵Kをキャロルへ送信し、ボブへの受領証を生成する。ボブの受領証は、キャロルの識別と共に、ボブが初めにキャロルへ送信した暗号化された透かしを含んでいる。
T→B:N E(N E(K ,H(M)Did)Cid
トレントは、アリスが映画Mの透かし入りのコピーをキャロルに関連付けることができるように、アリスへの受領証も生成する。アリスの受領証は、映画のハッシュH(M)、適用された透かしD、および消費者の識別子Cidを含む。アリスの受領証は、キャロルにライセンスが付与されたコンテンツに関連付けられることになる透かしを暗号化するためにアリスが使用した数/鍵の対で、暗号化される。
T→A:N E(K ,H(M)Did
トレントから受領証を受信すると、ボブは、アリスから受信した暗号化された映画をブレンダへ送信する。
B→B’:E(K,H(M)M)
ブレンダは、トレントから解読鍵Kを受信しているので、暗号化された映画を解読する。ブレンダは、映画を復号して映画Mを復元し、透かしDを適用し、透かし入りの映画W(D,M)を新しい暗号鍵Kで暗号化する。映画とともにアリスが暗号化した映画のハッシュH(M)により、ブレンダは、その映画が別の映画と取り替えられておらず、また、トレントから受信した解読鍵が暗号化コンテンツのための一致する鍵であることを、確認することができる。映画Mが解読され、透かしが入れられ、暗号化されると、ブレンダは、その暗号化され、透かしが入れられたコンテンツをキャロルへ送信する。
B’→C:E(KM’,W(D,M))
キャロルは、トレントからすでに解読鍵を受け取っているため、暗号化され、透かしが入ったコンテンツを解読して、映画Mを視聴することができる。
キャロルが、受信したコンテンツの不法なコピーを作製して配布することを決めた場合、キャロルが配布した市場で見つかる不法コピーは、何れも、コンテンツに適用された透かしによりキャロルまでたどられることができる(透かしを適用するために使用される本発明のこの特定の実施形態に関係なく)。ボブとアリスはともに、特定の透かしを特定の消費者にリンクする受領証を受け取る。コピーがキャロルまでたどられることができるため、この事を知っていることにより、キャロルは、コンテンツの不法コピーの配布を思いとどまる可能性がある。キャロルはまた、誰かが自分のコンテンツを手に入れ、不法に配布しないように、彼女のコピーをより厳重に監視することもできる。透かしの使用を通じて、コンテンツ提供者とサービス提供者との権利が強化される。
不法コピーの量を減らすことが可能な別の構成は、映画またはコンテンツのリアル・タイムの復号を必要とするようにすることである。選択されるハードウェア実装によっては、リアル・タイムの復号が可能であり得、その復号では、ここに提案されるシステムを介してダウンロードされたコンテンツを記録するために、そのコンテンツを意図される再生速度で視聴または消費するために必要な時間と同じ時間を必要とする。復号出力は、その後の記録の忠実度を低下させるアナログ信号として実施されることもできる。
次いで、本発明の実施形態の追加的な態様について、図4〜16に関して説明する。
図5は、本発明の一実施形態でコンテンツを要求する消費者26のプロセス全体を示す。初めに、消費者26は、特定のコンテンツに対する要求を行う(ステップ50)。この要求は、消費者が検索エンジンまたは使用可能コンテンツのカタログを使用して見つけた特定のコンテンツに関連した識別子またはラベルを含むことができる。ラベルは、映画の題名や歌曲の題名などのコンテンツの題名であってもよい。サービス提供者24は次いで、所望されるコンテンツに関連した暗号化ライセンス52をコンテンツ提供者22に要求する。サービス提供者は、ライセンス52を消費者26へ送信する(ステップ54)。消費者のハードウェア(例えばセット・トップ・ボックス)は、変化ID(認証者28から事前に受信)でライセンス52を暗号化し、その二重に暗号化されたライセンス52を認証者28へ送信する(ステップ56)。認証者28は、ライセンス52が有効であるかどうかを確認する。ライセンスが有効である場合、認証者28は、サービス提供者にその旨を通知する(ステップ58)。サービス提供者は次いで、コンテンツを消費者26へ送信する(ステップ60)。同時に、またはほぼ同時に、認証者28は、消費者26へ復号の情報を送信する(ステップ62)。
上記の説明から明らかなように、ライセンス52は、複数回暗号化されるという意味で複数回の変形を施される。図4にこのプロセスを示す。コンテンツ提供者は、特定のコンテンツの要求を受信するとライセンス52を作成する。ライセンスは、コンテンツ提供者がその対象のコンテンツのために作成した、ランダムに決定された秘密の識別子の暗号化されたものである。この時点で1回暗号化されたバージョンのライセンス(図4のライセンス63)は、サービス提供者24へ送信される。サービス提供者24は、ライセンスを再度暗号化し(図4のライセンス64)、この時点で二重に暗号化されたバージョンが消費者26へ送信される。二重に暗号化されたライセンスは、消費者の変化IDで暗号化されて、3重に暗号化されたバージョンを作成する(図4のライセンス65)。次いで、ライセンスの認証または検証、および情報の最終的な配信と復号が、図5に関して上記の説明で述べたように行われる。図6に、複数回の暗号化ステップを含むこのプロセスの別の図を提供する。
図7は、本発明の実施形態が複数のサービス提供者を含んでよいことを示す。更に、サービス提供者は、他のサービス提供者が所望する可能性のある独自のコンテンツまたは特定のコンテンツのライセンスを有してよいことが企図される。そのため、システム20に参加する各種のサービス提供者の最終的な消費者に対して、多種のコンテンツを使用可能にするために、ライセンスを求める各種の要求とライセンスの転送と(図示)を、サービス提供者の間で行うことができる。
図8は、本発明の一実施形態で変化IDが実装される方式を示す。図示するように、消費者26に第1の変化ID100が割り当てられる。消費者はその変化IDを使用して自身の識別を裏づける(図5のステップ56に対応する枠102に示す)。しかし、ライセンス100が使用されると、枠104に示すように、認証者は、ライセンス100に変更を加える、即ち、消費者に新しい鍵の対を送信する。新しい鍵の対は、事実上、新しい変化ID106を作る。
図9aおよび図9bは、コンテンツ鍵を管理する方式の1つを説明する。要求される場合、システム20は、コンテンツ提供者22がコンテンツ鍵のリストを認証者28に提供するように設定または構成されてよい。システム20がそのように実装された場合、消費者26によりなされたコンテンツの要求は、コンテンツ提供者22に転送される(1または複数の仲介のサービス提供者および/または他のコンテンツ提供者を通じて)(図9bのステップ110)。そして、コンテンツ提供者は、ライセンスを消費者26へ送信する(この場合も1または複数の仲介のサービス提供者を通じて)(ステップ112)。そして、消費者26は、正当性の検証または認証のために自身のコンテンツ・ライセンスを認証者へ送信する(ステップ114)。正当性が検証された場合は、検証情報がコンテンツ提供者22へ送信される(ステップ116)。次いで、認証者28は、コンテンツが復号され、視聴されることができるようにコンテンツ鍵を消費者26へ送信する(ステップ118)。
図10aおよび図10bは、別の鍵管理方式を説明する。認証者28へ鍵が送信されず、コンテンツ提供者22で保持されること以外、全体のプロセスは、図9aおよび図9bに関して述べたものと同様である。
図11〜図13は、望まれるされる場合には、サービス提供者とコンテンツ提供者がコンテンツを共有できる方式を説明する。コンテンツを共有する方式の1つは、それぞれのコンテンツ提供者が特定のコンテンツの権利を保持して、所望のコンテンツの要求を受信するとライセンスを作成するものである(図11)。あるいは、コンテンツ提供者は、所定数のライセンスを下流の提供者に配布して、コンテンツ提供者がそれぞれの要求に個別に応答しなくてよいようにして、それにより、下流の提供者が、末端の消費者から受け取る個々の要求に対して、承認(承認は、ライセンスの供給を拒否する行為により、否定される可能性がある)を得る必要なく、あるコンテンツの一定数の「コピー」を配布する能力を持てるようにする(図12および図13)。
図14は、透かしの入ったコンテンツのライセンスを生成し、使用するプロセスを説明する。上記で述べたように、コンテンツのライセンスは、複数回暗号化されるという意味で複数回の変形を施される。コンテンツ提供者22は、特定のコンテンツの要求を受信すると、または消費者26による将来の要求に備えて、ライセンスを作成する。このライセンスは、コンテンツ提供者が対象コンテンツに対して作成したランダムに決定される秘密の識別子130と、そのコンテンツのコピーに適用される透かし132の関数とを暗号化したバージョンである。この時点で1回暗号化されたバージョンのライセンス(図14のライセンス134)は、サービス提供者24へ送信される。サービス提供者24は、再度ライセンスを暗号化し(図14のライセンス136)、この時点で二重に暗号化されたバージョンが消費者26へ送信される。二重に暗号化されたライセンスは、消費者の変化IDで暗号化されて、三重に暗号化されたバージョン(図14のライセンス138)を作成する。次いで、ライセンスの認証または検証と、情報の最終的な配信と復号とが、図5に関して上記の説明で述べたように行われるが、暗号化されたコンテンツと解読の情報が、ライセンス中で識別される透かし入りコンテンツに固有であることをが異なる。図15に、複数回の暗号化ステップを含むこのプロセスの別の図示を提供する。
図16は、コンテンツを配布するために使用されるデバイスの例示的実施形態を示す。消費者26は、セット・トップ・デバイス150として示される。セット・トップ・デバイス150は、コンテンツを表示することが可能なディスプレイ151に結合され、リモート・コントロール152を通じてセット・トップ・デバイスとのインタフェースを提供する。ユーザ153は、リモート・コントロール152を使用してセット・トップ・デバイス150と対話する。ユーザ153は、リモート・コントロール152を使用して、使用可能なコンテンツのリストを閲覧し、ディスプレイ151で視聴するコンテンツを選択する。リモート・コントロール152の使用を通じてアクセスされるインタフェースはまた、ディスプレイ151上で選択されたコンテンツの名前を強調表示または点滅させることにより、ユーザ153がコンテンツの選択を行った時に表示する。
ユーザ153がコンテンツを選択すると、セット・トップ・デバイス150は、選択されたコンテンツの要求を生成する。要求は次いで、コンテンツ提供者22へ送信される。コンテンツ提供者22のデバイスは、プロセッサ156、メモリ・モジュール158、および入出力モジュール160を備えるサーバとして示されている。メモリ・モジュール158は、コンテンツ提供者22のコンテンツ・アイテムと少なくとも1つの変化識別子を保持している。コンテンツ提供者22が認証者28に多数の変化識別子を要求した場合には、メモリ・モジュール158は、他の変化識別子を保持し得る。メモリ・モジュール158は、1または複数の形態のROM、1または複数のディスク・ドライブ、RAM、他のメモリ、またはそれらの組み合わせ等の不揮発性メモリを含み得る。
コンテンツ提供者22は、入出力モジュール160を通じて要求を受信し、その要求をプロセッサ156へ送る。プロセッサ156は、メモリ・モジュール158にアクセスして変化識別子を入手する。この変化識別子は、同じくメモリ・モジュール158に記憶された当該コンテンツ・アイテム用のライセンスを暗号化するために使用する。プロセッサ156は、ライセンスを暗号化し、入出力モジュール160を通じてライセンスを消費者26へ送る。
消費者26は、暗号化されたライセンスを受信し、暗号化されたライセンスを処理し(下記で説明する)、暗号化されたライセンスを認証者28へ送る。認証者は、プロセッサ162、メモリ・モジュール164、および入出力モジュール166を備えるサーバとして示されている。コンテンツ提供者22のメモリ・モジュール158と異なり、認証者28のメモリ・モジュール164は、配布されるコンテンツは保持しない。この場合も、メモリ・モジュール162は、1または複数の形態のROM、1または複数のディスク・ドライブ、RAM、他のメモリ、またはそれらの組み合わせ等の不揮発性メモリを含み得る。
認証者28のプロセッサ162は、入出力モジュール166で受信された暗号化ライセンスを解読して、要求されるコンテンツと当該配布に関わるエンティティを明らかにする。関係エンティティの識別が分かると、プロセッサ162は、それらの識別を検証し、コンテンツ提供者22への受領証を生成する。プロセッサはまた、ライセンスで識別されるコンテンツに関連した解読鍵にアクセスし、メモリ・モジュール164の1または複数の新しい変化識別子にアクセスする。プロセッサは次いで、受領証、1または複数の新しい変化識別子、および解読鍵が、入出力モジュール166から個々の当事者へ送信されるように指示する。また、認証者のプロセッサ162は、現在の取引で使用される変化識別子がすでに使用されており、今後に遭遇された場合は受理されるべきことを、メモリ・モジュール164内で示す。
消費者26は、解読鍵と新しい変化識別子を受け取り、コンテンツ提供者22は、要求したコンテンツ・アイテムの受領証と、必要な場合は新しい変化識別子を受け取る。次いで、コンテンツ提供者22は、暗号化されたコンテンツを消費者26へ送信し、消費者26がコンテンツを受信したことを記録することができる。
消費者26がコンテンツ提供者から暗号化コンテンツを受信すると、消費者26はこの時点で映画を視聴するために必要なものをすべて持っている。そして、セット・トップ・デバイス150は、接続されたディスプレイ151に映画を表示することができる。
図17は、セット・トップ・デバイス150で使用されることが可能なハードウェアを示す。図の例示的コンフィギュレーションでは、セット・トップ・デバイス150は、プロセッサ170、メモリ・モジュール172、入出力モジュール174、およびリモート・コントロール・モジュール175を含む。このハードウェアは、この他のモジュールも含んでよい。
メモリ・モジュール172は、消費者26の変化識別子を保持するために使用され、また、コンテンツ提供者22および/または認証者28から送信されたコンテンツ、メッセージ、鍵を保持するためにも使用されてよい。メモリ・モジュール172は、1または複数の形態のROM、1または複数のディスク・ドライブ、RAM、他のメモリ、またはそれらの組み合わせ等の不揮発性メモリを含み得る。
プロセッサ170は、要求を生成し、受信したメッセージを暗号化し、メモリ・モジュール172にアクセスしてデータを記憶し、受信したコンテンツを解読するように構成される。入出力モジュール174は、システムの他のエンティティ(即ちコンテンツ提供者22と認証者28)および表示デバイス151とインタフェースをとるように構成される。リモート・コントロール・モジュール175は、コンテンツの要求を開始するためにユーザ153により使用されるリモート・コントロール152とインタフェースをとるように構成される。
プロセッサはメモリと対にされ、この配布システムで使用される3つのデバイスすべてについて入出力モジュールが示されているが、当業者には、ハードウェア、ソフトウェア、またはそれらの組み合わせが使用されて、関係するエンティティ間でコンテンツを通信および配布してよいことが明らかであろう。プロセッサは、集積回路、マイクロプロセッサ、またはコンテンツを配布するために必要な動作を行うことができるハードウェアとソフトウェアの組み合わせ等である。
明らかなように、システム20とその実装に使用されるプロトコルは、コンテンツのセキュアな配布以外の各種の用途で使用されることができる。電子メールから、テレビ会議およびマルチメディア会議、データおよび遠隔測定データの収集、およびその他のものにわたっての、多種の通信が、セキュリティと信頼性を強化するという利益を、システム20のすべてまたは一部を使用することから得られる。そうした追加的な用途の幾つかを次いで説明する。
地理的位置の確定
周知のように、多くの人間の活動は、人間の関係者が他の関係者を信頼することに依存する。更に、関係者は、他の関係者が信頼でき(即ち詐欺者や偽者でなく)、なされる約束や誓約を破らないことについて安心できなければならない。大半の活動が直接会って行われた時代には、信頼性についての不安の多くは軽減された。例えば、電話やインターネットが存在する以前には、詐欺師は、だまそうとする相手に物理的に会い、欺かなければならなかった。現代の通信では、当事者が、実際に通信している相手や、それらの当事者がいる場所を知ることが不可能であることが多い。
信頼性と信用に関する不安に対処するために使用されることができる各種のバイオメトリック・デバイスおよび他のデバイスが存在し、そうしたデバイスの多くは、ここに記載されるシステム20の実施形態と共に、または実施形態に追加して使用されることができる。しかし、システム20は、信頼性の不安を軽減する固有の機能も備える。そうした機能の1つは、コンテンツを注文している消費者の場所を、少なくとも比較的具体的な地点までたどれることである。
先に述べたように、本発明の実施形態では変化IDが実装され、消費者26に第1の変化ID100が割り当てられる。その後の変化IDは、消費者がコンテンツの入手を希望するたびに割り当てられる。更に、それぞれの消費者26は、復号用のプロセッサまたは同様のデバイス(例えばセット・トップ・ボックス、家庭用コンピュータ等)を持ち、消費者の住所と名前がそのハードウェアに関連付けられる。それぞれのサービス提供者とコンテンツ提供者も実際の物理的な場所と住所を持つ。システム20の実施形態は、多重暗号化かつカプセル化された識別子を解明することに依拠するので、消費者の場所は、少なくとも、その消費者のサービス提供者のサービス・エリアまではたどることができる。
例えば、顧客または窃盗者が顧客のハードウェアをサービス提供者24のサービス・エリア外の場所に移動し、コンテンツを要求した場合、新しいサービス提供者は、そのハードウェアに記憶された変化IDに基づいて復号に必要とされる適切な鍵を送信することができないので、多重暗号化され、カプセル化された識別子の解明は失敗する。
リアル・タイムのユーザ認証とリアル・タイムのコンテンツ再生
先に述べたように、現在の通信システムに伴う困難の1つは、通信当事者の信頼性を保証することである。本発明の一実施形態では、システム20が使用されて、1つの当事者から別の当事者へ送信される電子メール・メッセージ等の情報を符号化することができる。送信側の当事者がコンテンツ提供者/サービス提供者のような役割を果たし、受信側の当事者が顧客のような役割を果たす。
信頼性の追加的な保証を提供する方法の1つは、何らかのランダムの情報を受信側当事者へ送信し、受信者がその情報を、価値のある情報の通信が始まる前に、処理し、送信者へ送り返すことを要求するものである。例えば、合衆国憲法やゲティスバーグの演説からランダムに選択されたテキスト箇所、更に言えば議会図書館にある何千もの文書の任意のテキストを、受信側当事者へ送信することができる。有価値のコンテンツまたは情報が受信側当事者へ送信される前に、ランダムに選択されたテキストが正しく解読されなければならず、その情報の複製が受信者へ送り返されねばならない。受信側当事者がこれを行うことができない場合は、不適正な通信接続がなされているか、または、受信側当事者が、例えば、真の受信者の通信リンクを傍受しているかまたは通信リンクに侵入している詐欺者であることになる。しかし、適正な変化IDを所有しないと、ランダムのテキストの解読は行うことができない。
システム20に追加されることが可能な追加的なセキュリティ機能は、コンテンツのリアル・タイムの再生である。先に述べたように、著作権および他の法的権利の保持者にとっての問題の1つは、デジタル・コンテンツは(少なくとも理論的には)無限の回数にわたってコピーされることができ、それぞれのコピーを作製するのに必要な時間が非常に短いことである。例えば、70分間の音楽を保持しているCDは、数分間で完全にコピーされることができる。圧縮ファイルは、更に高速にコピーされることが可能である。このために、潜在的な犯罪者にとっては、コンテンツを大規模に不法コピーすることが非常に魅力的となっている。価値のあるコンテンツのコピーが1つ入手されると、何百、可能性としては何千もの劣化のないコピーが迅速に作製され、販売される可能性がある。
システム20の実施形態では、消費者26または受信者のコンテンツの復号は、リアル・タイム方式で行われる。つまり、システム20における再生は、最終的な視聴者または消費者に対して意図されるコンテンツの再生速度を超えない速度で行われる。従って、ある映画の上映時間が2時間20分である場合には、消費者へ送信されるこのコンテンツを記録するには、それと同じ時間量がかかり、それによりコンテンツの大規模なコピーを阻止する。また、このシステムは、行われる解読の回数を制限するように構成されることにも留意されたい。一般には、1回のみの解読が顧客により行われることができる。これは不正コピーを減らす助けとなる。また、コンテンツは、暗号化される前に、周知のコピー保護機構またはコードを含んでよいことにも留意されたい。その機構が使用されて、同様に不法コピーを防止または低減することができる。
データおよびテレメトリ(遠隔測定データ)の収集
先に述べたように、本発明の実施形態は、3つの当事者のみが関与する場合に実装されることが可能である。それらの当事者は、認証者、送信側当事者(類推によると、コンテンツ提供者およびサービス提供者の役割と機能とを包含する)、および、受信側当事者(類推によると、消費者の役割と機能とを包含する)を含む。先に述べたように、システム20は、セキュアな電子メール・システムを実装するように構成されることができる。明らかであるように、システム20は、電気メータおよびガス・メータからのデータの収集や、機器および人間の監視システム、他のデータおよびテレメトリ収集の用途等、セキュアな通信が有用であり得る各種の他の用途で実装されることもできる。一般に、多くの既存のシステムは、ここに記載される多重暗号化およびカプセル化された識別子のアーキテクチャを使用した通信を可能にするように、既存の処理および通信のハードウェアで容易に変更されることができる。
電子商取引
変化識別子は、電子商取引のプロトコルでも使用されることができる。一部の実施形態では、4つの関係者(コンテンツ提供者、サービス提供者、消費者、および認証者)の役割の名前を、ベンダ、購入者、支払い認証者、および認証者を含むように変更できる。変化識別子は、ベンダ、購入者、および支払い認証者が取引を完了できるようにするために、認証者により発行および管理されることができる。
図18は、電子商取引を行うように構成された例示的システム200を示す。実際には、当業者には明らかなように、インターネット、電話システム、ワイヤレス・ネットワーク、衛星ネットワーク、ケーブルTVネットワーク、および各種の他の私設および公衆ネットワーク等の1または複数のネットワークまたは通信システムが、各種の組み合わせで使用されて、本発明の実施形態または実装を作り出すために要求または必要とされる通信リンクを提供することができる。従って、本発明は、何れの特定のネットワークまたはネットワークの組み合わせにも限定されない。しかし、使用されるネットワークまたは通信システムは、Rijndael暗号化の1バージョンでデータが暗号化される通信や、セキュア・ソケット・レイヤ(「SSL」)通信、またはその他等のセキュアな通信を支援する能力を有することが好ましい。更に、データは、有線、デジタル衛星サービス(「DSS」)、または1つの当事者から別の当事者へ物理的に搬送される物理的媒体で1つの当事者から別の当事者へ送られることができる。
図18に示す実施形態では、システム200は、ベンダ220、クレジット・カード会社や金融機関等の支払い認証者240、購入者260、および認証者280、の4つの関係者を含む。図には1つのみのベンダ220、支払い認証者240、および購入者260が示されるが、大半の実装では、多数のベンダ、支払い認証者、および購入者が関係する。更に、必須なのは1つのみであるが、複数の認証者280があってよい。実際には、次の関係、すなわち、[認証者の数<支払い認証者の数<ベンダの数<購入者の数]、が存在する可能性が高いが、ここでも、関係者の数の制限や、各種関係者の数の間の特定の関係の要件はない。
一部の実施形態では、ベンダ220、支払い認証者240、および購入者260は、双方向リンク300、320、340で認証者280に接続される。ベンダ220と購入者260は、双方向リンク360を介しても接続される。これらのリンクは、上述のネットワークのすべてまたは一部から構築されることができる。一部の実施形態では、リンク360は、非セキュアなハイパーテキスト転送プロトコル(「HTTP」)リンクを含む。
ベンダ220は、自身の商品および/またはサービスを電子的に販売することを望む小売会社等のエンティティである。ベンダ220は、システム20を使用して交換される商品および/またはサービス(以下では両方を「商品」と称する)について公正に支払いを受けることを望むとものとする。そのため、本発明の一実施形態では、システム200は、ベンダ220が販売された商品の売渡証を生成できるように構成される。売渡証は、取引識別子を含むことができる。一部の実施形態では、取引識別子は、ベンダ識別子を含む。
購入者とベンダは、売渡証と価格について合意する。購入者260は、売渡証に掲載された商品の合意された価格での取引の掛け売り(financing)を許可することができる。購入者、ベンダ、および支払い認証者は、上記のように、偽造不可能な取引の受領証を受け取ることができる。少なくとも一部の購入者は、支払いをせずに、あるいはその購入者が管理する権限のない口座からの資金で、電子的に商品を購入することを望んだり試みたりすると想定される。また、購入者は、支払い情報が損なわれることのないセキュアな取引を要求するものと想定される。従って、商品の不正な購入を防止し、セキュアな取引を提供するための措置が提供される。変化IDは、購入を制御するための機構を提供する。
支払い認証者240は、取引にに対する金融処理で使用できる口座(金銭または他の支払いの形態または機構の形)を保持するクレジット・カード会社や金融機関などのエンティティである。支払い認証者240は、口座から電子商取引の金融処理を行うことに同意することができ、従って、口座識別子は機密に保たれる。そのため、本発明の一部の実施形態では、システム200は、購入者260と支払い認証者240が、購入者260の口座についての秘密の口座識別子に合意するように、構成される。更に、口座からの取引の支払いの許可は、変化IDで暗号化される。
認証者280は、セキュアな電子取引を行うために必要なデータを保持するリポジトリである。ここで論じる実施形態では、認証者280は、電子商取引が行われるのを許可する前に、ベンダ220、支払い認証者240、および購入者260を、それらの変化IDで検証する。認証者280は、購入者、ベンダ、および支払い認証者の受領証を検証することができる。認証者280はまた、購入者の口座情報や取引の詳細を知ることなく、上記の動作を行うことができる。認証者280は、変化IDの供給元でもあり、データベースまたは同様の機構を使用してそのようなIDを追跡する。
次いで、数個の例を使用して本発明の例示的実施形態を説明する。
通信プロトコルの説明の多くのように、このプロトコルで使用される各種エンティティ(またはそれらのエンティティに関連したコンピュータ・システム)には名前が割り当てられる。一実施形態では、ボブ(B)、ヴェラ(V)、およびキャロル(C)が、プロトコルの様々な関係者を表し、トレント(T)は、信頼される通信の調整者を表す。下記の表、表2は、このプロトコルの複数の実施形態を説明するために本文献で使用される他の記号の一覧である。
Figure 2009517922
このプロトコルの例示的な実施形態は、上記の4つの関係者に関連する。エンティティ・ボブ(「B」)が購入者260の役割を行い、エンティティ・ヴェラ(「V」)がベンダ220の役割を行い、エンティティ・キャロル(「C」)が支払い認証者240の役割を行い、エンティティ・トレント(「T」)が認証者280の役割を行う。このプロトコルは、ボブがヴェラから商品を購入することに関連する。ボブは、キャロルにより保持されている口座を使用して商品の購入、またはその支払いをする。トレントは、ボブ、ヴェラ、キャロルの間の通信を調整する。このプロトコルは、信頼される権限者に依拠するので、ボブ、ヴェラ、およびキャロルは、トレントを信頼する。更に、割り当てられる数と鍵は、すべてトレントにより割り当てられ知られる。ボブ、ヴェラ、キャロルはそれぞれ、トレントにより発行された秘密の数/鍵の対(N,K)、(N,K)、および(N,K)をすでに保持しているものとする。
この例では、ボブがヴェラから商品を購入したいとする。ボブとヴェラは、売渡証(S)に合意する。ボブは、キャロルに保持されている口座から引き出される資金で支払いをすることを希望する。口座は、証明(Bcred)で識別される。証明(Bcred)は、ボブ、キャロル、およびトレントのみに知られている、または認識可能な秘密である。一部の実施形態では、証明(Bcred)は、ボブの口座番号を表す。他の実施形態では、証明(Bcred)は、トレントにより割り当てられる。プロトコルを機能させるために、トレントは、先天的又は事前に証明を「知る」必要はない。一部の実施形態では、トレントは、キャロルに証明を転送するのみである。更に、一部の実施形態では、トレントは、証明に含まれるデータ(口座番号等)を入手することができない。これは、プロトコルのセキュリティを高める助けとなる。
証明(Bcred)は、ボブ、トレント、キャロルのみに知られているので、トレントとキャロルは、証明(Bcred)を使用して、ボブが特定のメッセージを作成したことを検証することができる。キャロルは、証明(Bcred)を使用してボブの口座番号を検証してもよい。一部の実施形態では、証明(Bcred)は、ボブとキャロルのみに知られた秘密(ボブの口座番号等)から構築される。証明(Bcred)は、現在の取引に関する詳細から構築されることもできる。一部の実施形態では、証明(Bcred)は、次のように決定される。
cred=E(H(x),H(S)P)
上記の数式で、xは、ボブとキャロルのみに知られた秘密(ボブの口座番号等)であり、Sは売渡証であり、Pは、売渡証に含まれる商品の合意された価格である。一部の実施形態では、ボブは、ハッシュではなく、平文バージョンの売渡証および/または価格から、彼の証明(Bcred)を構築する。しかし、ハッシュを使用すると、取引の詳細を抽象化することができる。証明を決定するために、更なる数式や機構が使用されてよいことを理解されたい。
ボブとキャロルはx(および適用可能な場合は、ハッシュ関数)を知っているので、ボブとキャロルは、証明(Bcred)を解読し、ボブの口座に関するセキュアな情報を得ることができる。一部の実施形態では、トレントとヴェラは、ボブの口座や、価格等の取引の詳細に関するセキュアな情報を、得ることができない。
ボブは、取引ごとに証明(Bcred)を生成することができ、キャロル(ボブの口座番号を知っており、H(x)を生成することができる)は、証明(Bcred)を解読して、売渡証とそれに対応する価格を得ることができる。一部の実施形態では、キャロルが、それぞれ口座番号x、x、...,xを有するボブの口座を複数個保持している場合、キャロルは、それぞれの口座番号に対するハッシュを生成する。それらハッシュの1つが証明(Bcred)を解読できる場合、キャロルは、何れの口座から資金を引き出すべきかが分かる。ボブは、証明(Bcred)に口座識別子を先頭に付加して、特定の口座を識別するようにもできる。
一部の実施形態では、口座のハッシュを作成することは、H(x)=H(x)で、かつ、xがxに等しくない場合に、ハッシュの衝突を発生させる可能性がある。ハッシュの衝突は、口座を作る際に検出されることができ、ハッシュの衝突を防止するために、衝突する口座番号は生成し直すことができる。
図19に示すように、購入プロセスを開始するために、ヴェラは、署名されたベンダ取引データをボブへ送信する。一部の実施形態では、ベンダ取引データは、売渡証(S)および/またはその売渡証(S)に対応する合計価格(P)を含む。平文の売渡証(S)と対応する価格(P)に加えて、またはその代わりに、ベンダ取引データは、売渡証(S)および/または価格(P)のハッシュを含むことができる。一部の実施形態では、ベンダ取引データは、ヴェラの証明(Vcred)も含む。ヴェラの証明(Vcred)は、ヴェラ、キャロル、およびトレントのみに知られた、または認識可能な秘密である。一部の実施形態では、上記のように、ヴェラの証明(Vcred)は、ヴェラの口座番号等の、ヴェラとキャロルのみに知られた秘密から構築されることができる。他の実施形態では、トレントが、ヴェラに証明(Vcred)を割り当てることができる。キャロルとトレントは、ヴェラの証明(Vcred)を使用して、ベンダ取引データがヴェラにより生成されたことを検証することができる。ベンダ取引データは、取引に関連する購入者(例えばボブ)および/または支払い認証者(例えばキャロル)の識別子も含むことができる。ヴェラは、ベンダ取引データに「署名」するが、これは、そのデータを彼女の秘密鍵(K)で暗号化し、自身の秘密の数(N)を先頭に付加することによりなされる。ヴェラは、署名したベンダ取引データをボブへ送信する。
V→T:SNE(K,H(S)P)
署名されたデータをヴェラから受信すると、ボブは、ヴェラが行ったのと同じように、署名された購入者取引データを提供する。購入者取引データは、売渡証を含み、この売渡証は、ボブが適正かつ誠実に振舞った場合には、ヴェラにより署名された売渡証と同一または等価となる。ボブは、彼の証明(Bcred)と、彼以外の取引の関係者(即ちヴェラとキャロル)の識別も、購入者取引データに含めることができる。ボブは購入者取引データに署名するが、これは、そのデータを彼の秘密鍵(K)で暗号化し、彼の秘密の数(N)を先頭に付加することによりなされる。ボブは、署名した購入者取引データを、ヴェラにより署名されたベンダ取引データと連結し、連結したメッセージをトレントへ送信する。
B→T:NE(K,H(S)P)BcredididE(K,H(S)P)
ボブが購入プロセスを開始することもできることを、理解されたい。一部の実施形態では、ボブは、ヴェラへ、ヴェラとキャロルの識別を含む署名された購入者取引データを送信する。ヴェラは、ボブから提供された署名データに、署名されたベンダ取引データを追加し、連結したメッセージをトレントへ送る。
トレントは、連結されたメッセージを展開することができる(トレントはボブとヴェラの秘密鍵を知っているから)。一部の実施形態では、トレントは、ボブから送信された購入者取引データまたはその一部(例えば、売渡証、価格、および/または、売渡証および/または価格のハッシュ)が、ヴェラから送信されたベンダ取引データまたはその一部と一致することを検証する。データが一致しない場合は、ヴェラとボブが共通の売渡証および/または関連する価格において合意しなかった可能性があり、トレントは、その不一致をボブとヴェラに通知することができる。
データが一致する場合、トレントは、支払い要求を生成する。一部の実施形態では、支払い要求は、ボブとヴェラの間の取引の支払いを要求するためにキャロルへ送信される。支払い要求は、ヴェラ、ボブ、キャロルへの受領証を含むことができる。それぞれの受領証は、3つの関係者のうち2つの鍵(即ち、その受領証が対象としない関係者の鍵)、売渡証、および価格を含むことができる。一部の実施形態では、それぞれの受領証は、受信者および/または他の関係者の証明も含む。受信者は、証明を使用して、受領証がトレントにより生成されたことを検証することができる。取引のセキュリティと秘密性を更に増すために、平文データに代えて、鍵、売渡証、価格、および/または証明のハッシュが含まれることも可能であることを、理解されたい。ハッシュが提供された場合、トレントは、ハッシュは入手することができるが、取引の詳細は解読することができない。ヴェラ、ボブ、キャロルへの例示的な受領証は、次のように構成されることができる。
=E(K,H(KP)H(S)P)
=E(K,H(KP)H(S)P)
=E(K,H(KP)H(S)P)
支払い要求は、ヴェラ、ボブ、キャロルへの新しい数/鍵の対を含むこともできる。
=E(K,N’K’
=E(K,N’K’
=E(K,N’K’
支払い要求は更に、ボブとヴェラへ送信するキャロルのためのメッセージを含むことができる。一部の実施形態では、トレントは、1つの「受理」メッセージと1つの「拒絶」メッセージを生成する。キャロルは、取引の支払いの要求を彼女が受け入れる場合には、「承認(approved)」メッセージまたはその一部を、ボブとヴェラへ送信し、支払い要求を受け入れない場合は、「拒絶(declined)」メッセージまたはその一部を、ボブとヴェラへ送信する。
approved=E(K,“承認”)E(K,“承認”)
declined=E(K,“拒絶”)E(K,“拒絶”)
トレントが生成する支払い要求は、これより多くの又は少ないメッセージを含んでよいことを理解されたい。例えば、トレントは、それぞれの関係者につき受領証と新しい数/鍵の対の両方を含むメッセージを生成することができる。トレントは、ボブとヴェラからの別々の「承認」メッセージおよび「拒絶」メッセージを生成することもできる。
トレントは、ボブの証明(Bcred)と売渡証の価格(P)も復号する。一部の実施形態では、トレントは、ボブの証明(Bcred)を復号することができず、従って、キャロルに保持されているボブの口座に関する機密情報を得ることができない。この理由から、トレントは、ボブの証明(Bcred)は入手するが、ボブの口座情報を入手することはできない。
支払い要求は、ボブの証明(Bcred)と価格(P)とを含む証明メッセージも含むことができる。トレントは、キャロル以外の者にその証明メッセージに含まれるデータを入手させないために、キャロルの秘密鍵(K)で証明メッセージを再度暗号化する。トレントは、キャロルの秘密の数(N)を証明メッセージの先頭に付加することもできる。
cred=E(K,BcredP)
支払い要求は、取引関係者(キャロル以外)の識別も含むことができる。
トレントは、支払い要求をキャロルへ送信する。一部の実施形態では、トレントは、キャロルに、支払い要求に含まれるメッセージと受領証とを個別に送信することもできる。一部の実施形態では、トレントは、キャロルの秘密鍵(K)で支払い要求(または個々のメッセージおよび/または受領証)を暗号化する。トレントは、支払い要求を復号する方法をキャロルに指示するために、キャロルの秘密の数(N)を先頭に付加することもできる。
T→C:NE(K,Bidid)(R)(M)(Macceptdecline)(Mcred))
キャロルは、支払い要求を受信し、その売渡証の支払いを承認するかどうかを決定する。一部の実施形態では、キャロルは、ボブの口座(Bcredで識別される)にその売渡証の価格(P)をまかなうのに十分な資金があるかどうかを判断することにより、支払いを承認するか否かを決める。ボブの口座に、価格をまかなうのに十分な資金がある場合、キャロルは、ボブの口座からヴェラの口座へ資金を送る。一部の実施形態では、キャロルは、エスクロー(escrow)の役目を果たすことができ、売渡証に含まれる商品がボブに発送および/または提供されたことをヴェラがキャロルに通知するまで、ボブの口座からの資金を保持することができる。商品がボブに提供されると、キャロルは、ボブの口座からの資金をヴェラの口座に転送することができる。支払いを承認すると、キャロルは、受領証、新しい数/鍵の対、および承認メッセージを含む応答を、ボブとヴェラの両方へ送信することができる。
C→B:(K,“承認”)M
C→V:(K,“承認”)M
ボブ、ヴェラ、およびキャロルは、取引の検証のために、この取引で使用した数(N、N、またはN)、価格、および、各自の受領証を、トレントに呈示することができる。例えば、トレントは、それらの受領証が同じであることを検証することができる。
ボブの口座に、価格をまかなうのに十分な資金がない場合、キャロルは、ボブの口座からヴェラの口座に資金を転送しない。しかし、キャロルは、新しい数/鍵の対と拒絶メッセージとを含む応答を、ボブとヴェラの両方へ送信する。キャロルは、ボブとヴェラに、取引の拒絶を知らせる受領証を送信することもできる。
C→B:E(K,“拒絶”)M
C→V:E(K,“拒絶”)M
図19は、別の例示的な通信プロトコルを模式的に示す。この例示的プロトコルは、ボブが、キャロルにより保持されている口座を使用して、ヴェラから売渡証(S)にリストされた商品を購入することに関連する。この場合も、トレントが、ボブ、ヴェラ、およびキャロルの間の通信を調整する。また、この提案されるプロトコルは、信頼される権限者に依拠するので、ボブ、ヴェラ、キャロルは、トレントを信頼する。更に、割り当てられる数および鍵はすべて、トレントにより割り当てられ、トレントに知られる。
この例では、ボブがヴェラから商品を購入したいものとする。先の例と異なり、ヴェラとボブが商品を交換するために、トレントは初めに、ボブとヴェラとの間にセキュアな通信を確立する。
ボブは、トレントに、取引鍵の要求を送信する。要求は、ボブが通信したいベンダの識別を含むことができる。一部の実施形態では、ボブは、彼の秘密鍵(K)で彼の要求を暗号化し、彼の秘密の数(N)を先頭に付加する。
セキュリティを更に保証するために、ボブは、更なる要求識別データXを、要求に含めることができる。一部の実施形態では、データXは、ランダムまたは擬似ランダムなデータを含む。例えば、データXは、ボブとトレントのみに知られたボブの秘密の証明を含むことができる。データXを使用してトレントを認証することができる。要求はボブの秘密鍵で暗号化されるので、ボブとトレントだけがメッセージを復号することができる。トレントは、自身が認証者であることを証明することができ、それは、ボブの要求を復号し、ボブへの応答にデータXを含めることにより、なされる。従って、トレントは、彼がボブの要求を復号したことを証明する。
データXは、トレントからの応答を、特定の要求と関連付けるために使用されることもできる。トレントは、ボブが彼の要求で識別するベンダに、データXを渡すこともできる。
B→T:NE(K,VidX)
一部の実施形態では、ボブは、トレントが通信を望むベンダ(例えばヴェラ)に、取引鍵を求める要求(取引鍵の要求)を送信することができ、ベンダはベンダ自身の、取引鍵の要求を、連結することができる。ベンダにより生成された要求は、最初の取引鍵の要求をベンダへ送信した購入者の識別を含むことができる。ベンダにより生成された要求は、要求識別データYを含むこともでき、データYは、ランダムまたは擬似ランダムのデータを含むことができる。例えば、データYは、ベンダとトレントのみに知られたベンダの秘密の証明を含むことができる。ベンダは、自身の秘密鍵(K)で取引鍵の要求を暗号化し、自身の秘密の数(N)を先頭に付加することができる。そして、ベンダは、連結後の取引鍵の要求を、トレントへ送信することができる。トレントは、連結された要求を使用して、それぞれの当事者が取引鍵の確立に同意することを確認することができる。
トレントは、ボブからの取引鍵の要求を解読し、そして、ボブとヴェラが通信して取引の交渉を行うために使用することができる秘密の取引鍵KBVを、生成する。トレントは、ボブとヴェラの新しい数/鍵の対も生成することができる。トレントは、鍵と、新しい数/鍵の対とを、ボブの鍵とヴェラの鍵とで、それぞれ、暗号化して、2つのメッセージを作成する。このメッセージは、受信者からの取引鍵の要求においてメッセージの受信者により提供された秘密データ(例えば、証明)を含むことができる。上記のように、受信者は、この秘密データを使用して、トレントがそのメッセージを生成したことを検証することができる。トレントは、1つのメッセージをボブへ送信し、1つのメッセージをヴェラへ送信する。トレントは、それらメッセージを連結したものをヴェラまたはボブへ送信することもできる。一部の実施形態では、連結されたメッセージの第1の部分(NE(K,BidBVXN’K’))は、ヴェラの情報を含むことができ、連結されたメッセージの第2の部分(E(K,KBVN’K’))は、ボブの情報を含む。連結されたメッセージを受信した者(ヴェラまたはボブ)は、何れのものであっても、連結されたメッセージから自身の暗号化メッセージを取り出し、残りの連結メッセージをもう一方の参加者に渡すことができる。
T→V:NE(K,BidBVXN’K’)E(K,KBVN’K’
例えば、ヴェラがメッセージを受信し、メッセージの第1の部分を解読することができる。しかし、メッセージの第2の部分はボブの秘密鍵Kで暗号化されているので、ヴェラは第2の部分は解読することができない。メッセージの第1の部分を解読すると、ヴェラは、ヴェラとボブとが通信するようにトレントにより生成された秘密の取引鍵KBVを、復元することができる。ヴェラは、メッセージの第2の部分をボブに転送する。上記で述べたように、一部の実施形態において、トレントがメッセージの第1の部分にデータXを含めた場合は、ヴェラは、秘密鍵KBVで暗号化されたデータXをボブへ送ることもできる。
V→B:E(K,KBV,N’K’)E(KBV,X)
ボブとヴェラとが各自のメッセージをトレントおよび/または互いから受信した後には、ボブとヴェラは、取引を交渉するために使用できる秘密鍵(KBV)を共有している。図19に示すように、ボブとヴェラは、秘密鍵(KBV)を使用して取引の交渉を行い、購入者情報とベンダ情報とを交換することができる。購入者情報は、購入者から提供された輸送情報を含むことができる。ボブとヴェラが取引について合意すると、ボブとヴェラは、支払いの交渉をできる状態となる。
ある口座に関連したすべての取引は、購入者が他の者を除外するように購入者自身を識別することを必要とするものと想定する。従来の商取引では、これには、特定の口座番号と署名の入ったカードを使用することを伴う。電子商取引では、口座番号および他のデータ(課金用の住所の郵便番号など)が使用されて購入者を識別する。
一部の実施形態では、購入者(ボブ)は、取引で同時に識別される。購入者を識別するために静的な口座番号を使用する代わりに、購入者と取引とのエレメントが組み合わせられて、購入者の証明を生成する。一部の実施形態では、購入者と、購入者の口座を保持する支払い認証者とのみに知られた購入者のエレメント(例えばxとy)、ベンダのエレメント(Vid)、売渡証(S)、および同意された価格(P)が組み合わせられて、購入者の証明(Bcred)を生成する。購入者は、購入時にこの証明を計算することができる。
例えば、xとyがボブの口座番号の一部分であるとする。販売時に、ボブは、自分の証明を次のように生成することができる。
cred=E(x,yidH(SP)P)
を知っている者のみがこのメッセージを復号することができる。一部の実施形態では、ボブとキャロルだけがx(およびy)を知っているので、このメッセージは、安全にトレントに渡されることができる。なぜなら、トレントは、メッセージを復号することができず、従って、口座情報を入手することができないからである。
一部の実施形態では、ボブが価格をごまかさないことを保証するために、ヴェラは、同様の証明を生成する。キャロルは、ヴェラの証明を使用して、ボブとヴェラとが売渡証(S)および価格(P)に合意することを確認することができる。
cred=E(x,yidH(SP)P)
ボブとヴェラは、例えば、電子商取引プロトコルの先の実施形態で説明した機構などのような他の機構を使用して、各自の証明を構築できることを理解されたい。
購入プロトコルを開始するために、ヴェラは、ボブへ、署名されたベンダ取引データを送信する。ベンダ取引データは、売渡証および価格のハッシュ(H(SP))とヴェラの証明(Vcred)を含むことができる。価格を平文ではなくハッシュに含めることにより、トレントは、売渡証とそれに対応する価格を知らされない。ヴェラは、彼女の秘密鍵(K’)でデータを暗号化し、暗号化したデータに彼女の秘密の数(N’)を先頭に付加する。
V→B:N’E(K’,H(SP)Vcred
ボブは、このメッセージを、署名された購入者取引データと連結する。購入者取引データは、ボブの証明(Bcred)と、売渡証と価格の別のハッシュ(H(SP))を含むことができる。購入者取引データは、キャロルの識別(Cid)も含むことができる。ボブは、彼の署名を提供するために、彼の秘密鍵(K’)で購入者取引データを暗号化し、彼の秘密の数(N’)を先頭に付加する。ボブは、連結されたベンダ取引データと購入者取引データをトレントへ送信する。
B→T:N’E(K’,CidH(SP)BcredN’E(K’,H(SP)Vcred))
ボブが購入プロセスを開始することもできることを理解されたい。一部の実施形態では、ボブは、署名された購入者取引データをヴェラへ送信する。ヴェラは、署名されたベンダ取引データを、受信したデータに連結し、連結したデータをトレントへ送ることができる。
一部の実施形態では、セキュリティを保証するためのトレントへの制約の一部として、トレントは、取引の詳細を知ることができない。しかし、トレントは、受領証を検証するために取引データを識別することはできる。トレントは、取引データを使用して、ボブとヴェラとが取引について価格と売渡証とに合意したかどうかを判定することができる。売渡証と価格とのハッシュを作成することにより、トレントは、取引データを受信するが、売渡証および/または関連する価格の詳細は判断することができない。
ベンダ取引データと購入者取引データとを含むメッセージを受信すると、トレントは、データを復号し、購入者取引データとベンダ取引データとを復元する。一部の実施形態では、トレントは、ボブとヴェラとが売渡証と価格について合意したことを検証する。売渡証および/または価格がハッシュとして提供された場合は、トレントは、ヴェラにより提供されたハッシュが、ボブから提供されたハッシュと一致するかどうかを判定する。
一部の実施形態では、トレントは、ボブの口座番号(xおよびy)を知らないので、ボブの証明(Bcred)を復号することができない。同様に、トレントは、ヴェラの証明(Vcred)を導出することができない。
取引データを復号した後、トレントは、支払い要求を生成する。トレントは、ボブとヴェラとの間の取引の支払いを要求するために、キャロルへ支払い要求を送信することができる。支払い要求は、ボブ、ヴェラ、キャロルに対しての受領証を含むことができる。それぞれの受領証は、署名入りバージョンの取引データを提供することができる。一部の実施形態では、受領証は、売渡証と価格とのハッシュを含む。それぞれの関係者(参加者)の受領証は、他の2人の関係者の2つの数/鍵の対で暗号化される。例えば、キャロルに対する取引の受領証は、次のようになる。
=N’E(K’,N’E(K’,BididH(SP)))
受領証は、ボブとヴェラとの両方の秘密鍵を必要とするので、トレントだけがこの値を構築することができる。この意味では、受領証は、認知できるように偽造できない。
同様に、トレントは、ボブとヴェラへの受領証を作成することができる。
=NE(K,N’E(K’,CididH(SP)))
=N’E(K’,NE(K,BididH(SP)))
支払い要求は、ボブとヴェラとの識別と証明、取引データ、キャロルの受領証、キャロルの新しい数/鍵の対、および/または、売渡証および/または価格のハッシュを含むこともできる。トレントは、キャロル以外の者が要求に含まれるデータを入手できないようにするために、キャロルの現在の秘密鍵(K)で支払い要求を暗号化することができる。トレントは、キャロルの秘密の数(N)を要求の先頭に付加することもできる。一部の実施形態では、キャロルは、複数の認証者により発行された秘密の数/鍵の対を有し、トレントは、キャロルが要求の復号に使用すべき秘密鍵を識別するために、キャロルの秘密の数を先頭に付加することができる。
=NE(K,BidcredidcredH(SP)RN’K’
一部の実施形態では、支払い要求は更に、ボブとヴェラとへ送信するキャロルのメッセージを含む。一部の実施形態では、トレントは、ボブへの2つのメッセージとヴェラへの2つのメッセージを生成する。それぞれのメッセージの対は、「受理」メッセージと「拒絶」メッセージを含む。キャロルは、取引の支払いの要求を引き受ける場合は、ボブとヴェラへ「受理」メッセージを送信する。キャロルは、支払いの要求を引き受けない場合は、ボブとヴェラへ「拒絶」メッセージを送信する。「受理」メッセージはボブとヴェラとへの受領証を含み、従って、支払いの要求が引き受けられる場合、ボブとヴェラとが取引の受領証を受け取る。「受理」メッセージと「拒絶」メッセージとは両方とも、ボブとヴェラとの両方への新しい数/鍵の対も含むことができる。下記のような、新しい数/鍵の対および/または受領証を含む別々のメッセージが生成されて、送信されることもできる。
=E(K’,“承認”RN’’K’’
M’=E(K’,“拒絶”RN’’K’’
=E(K’,“承認”RN’’K’’
M’=E(K’,“拒絶”RN’’K’’
トレントは、キャロルへ支払い要求を送信する。
T→C:MM’M’
キャロルは、要求を受信すると、ボブとヴェラとの証明(BcredおよびVcred)を取り出すことができる。キャロルは、ボブとヴェラとの口座番号を知っているので、両方の証明を解読することができる。キャロルは、ボブとヴェラとが売渡証と価格に合意することも検証することができる。更に、キャロルは、支払いの要求を引き受けるかどうかを決定することができる。キャロルが支払いの要求を引き受ける場合、キャロルは、それぞれに「承認」メッセージを含む応答を、ボブとヴェラとへ送信する。
C→B:M
C→V:M
逆に、キャロルが支払いの要求を引き受けない場合、キャロルは、それぞれに「拒絶」メッセージを含む応答を、ボブとヴェラへ送信する。
C→B:M’
C→V:M’
キャロルが支払いの要求を引き受ける場合、キャロルはまた、価格Pで示されるように、ボブの口座とヴェラの口座との間で資金を移転する。一部の実施形態では、キャロルは、エスクローの役目を果たすことができ、そして、売渡証に含まれる商品がボブへ発送および/または提供されたことをヴェラがキャロルに通知するまで、ボブの口座からの資金を保持することができる。
上記のプロトコルは、少数の通信と接続とを伴うセキュアな電子商取引プロトコルを説明する。しかし、状況によっては、このプロトコルの適用は、不適当あるいは非効率的である。例えば、上記のプロトコルでは、ヴェラは、彼女の口座情報を、キャロルに到達する前にボブとトレントの両方を通じて、送信する。これは完全に安全であるが、たとえ口座情報がセキュアな暗号化された形態であったとしても、口座情報の配布を回避することが好ましい場合もある。
上記のプロトコルは、ボブとヴェラとの両方が機密性のある口座情報を直接キャロルに通信するように、変更が加えられることができる。図20は、システム200の別の実施形態を示し、この実施形態は、購入者260、ベンダ220、支払い認証者240、および認証者280を含む。図18と比べると、図20に示すシステム200は、それぞれの関係者をシステム200のすべての他の関係者と接続している。ベンダ220、支払い認証者240、購入者260は、それぞれ、双方向リンク300、380、360を介して認証者280に接続される。購入者260は、双方向リンク360と380を介してベンダ220と支払い認証者240にも接続される。更に、ベンダ220は、双方向リンク400を介して支払い認証者240に接続される。これらのリンクは、上述のネットワークのすべてまたは一部から構築されることができる。
図21は、図20に示すシステムで使用される通信プロトコルを説明する。ボブとヴェラが売渡証と支払い方法について合意すると、2人は、トレントを通じて間接的にではなく、それぞれ直接キャロルと通信する。一部の実施形態では、これは、キャロルとボブの間、およびキャロルとヴェラの間で秘密の取引鍵を確立することにより達成されることができる。例えば、ボブは、ボブが直接キャロルと通信することを可能にする取引鍵(KBC)の要求を、トレントへ送信する。ヴェラも、キャロルと直接通信できるように、トレントに取引鍵(KCV)を要求することができる。取引鍵(KBCおよびKCV)が確立されると、ヴェラとボブとの証明がキャロルへ直接に送信されることができる。
証明は直接にキャロルへ提供されることができるので、上記のプロトコルは、口座データがトレントを通じて間接的に送信されないように、変更されることができる。ヴェラとボブとが売渡証(S)および価格(P)に合意すると、ヴェラは、ベンダ取引データに署名し、署名したデータをボブへ送信する。一部の実施形態では、ベンダ取引データは、売渡証と価格とのハッシュ(H(SP))を含む。
V→B:N’E(K’,H(SP))
上記のプロトコルと異なり、ヴェラは、ベンダ取引データに彼女の証明を含めるのではなく、彼女の証明をトレントから発行された秘密鍵(KCV)で暗号化して直接にキャロルへ送信する。
V→C:E(KCV,Vcred
ヴェラから署名されたベンダ取引データを受信すると、ボブは、ヴェラから受信した署名されたベンダ・データを、彼の秘密の鍵/数の対で署名された購入者取引データと連結する。一部の実施形態では、購入者取引データは、売渡証と価格とのハッシュを含む。購入者取引データは、キャロルの識別も含むことができる。ボブは、連結した購入者取引データとベンダ取引データとをトレントへ送信する。
B→T:N’E(K’,CidH(SP)N’E(K’,H(SP)))
また、ボブはキャロルとセキュアに直接通信することができるので、ボブはキャロルへ彼の証明(取引の詳細を含むことができる)を送信する。ボブは、彼の証明を、キャロルと共有する秘密鍵(KBC)で暗号化する。
B→C:E(KBC,Bcred
トレントは、連結された取引データを受信し、キャロルへの支払い要求を作成する。この支払い要求は、ボブの証明およびヴェラの証明以外は、上記のプロトコルで説明した情報と同じ情報を含むことができる。
トレントからの支払い要求とボブおよびヴェラからの証明とを受信すると、キャロルは、先のプロトコルで受信した情報と同じ情報を持つことになるが、この情報は異なる通信路または接続を通じて受信している。何者かがキャロルに提供されるメッセージの1つを不法に入手し、再送した場合でも、キャロルは、支払いを承認する前に、それぞれの関係者からのメッセージを受信し、検証しなければならない。更に、トレントからの支払い要求は変化識別子を含んでおり、そのため、キャロルは、不法に再送されたトレントからのメッセージを復号することができない。なぜなら、変化識別子は前回の使用以降に変動または変化しているからである。
そして、キャロルは、その取引の支払いの要求を引き受けるかどうかを決定する。キャロルが支払いの要求を引き受ける場合、キャロルは、「承認」メッセージを含む応答をボブとヴェラへ送信する。キャロルは、支払いの要求を引き受けない場合、「拒絶」メッセージを含む応答をボブとヴェラへ送信する。一部の実施形態では、キャロルは、トレントにより発行された秘密の鍵でボブおよびヴェラへの応答を暗号化して、取引を更にセキュアにする。例えば、キャロルが支払いの要求を引き受ける場合は、次の応答を送信する。
C→B:E(KBC,M
C→V:E(KCV,M
キャロルが要求を受け入れる場合、キャロルは、ボブの口座からヴェラの口座へ資金を送る。しかし、一部の実施形態では、キャロルは、エスクローの役目を果たすことができ、ボブの口座からヴェラの口座に資金を送る前に、その取引に含まれる商品がボブへ発送および/または提供された旨の通知をヴェラおよび/またはボブから受信するまで待つ。
一方、キャロルが支払いの要求を受け入れない場合は、次の暗号化した応答を送信する。
C→B:E(KBC,M’
C→V:E(KCV,M’
理解されるように、上記のプロトコルを使用して、電子商取引と非電子商取引との両方で、セキュアな商取引を行うことができる。更に、認証者と支払い認証者との役割は組み合わせられることもできることを理解されたい。例えば、それぞれの支払い認証者は、その支払い認証者自身の変化識別子を、そのクライアント(口座を保持する個人)に提供することができる。
また、上記のプロトコル(またはその一部)は、組み合わせられることが可能であることも理解されたい。例えば、コンテンツ提供者またはサービス提供者からのデジタル・コンテンツの購入に、電子商取引が含められることもできる。また、電子商取引に透かしを入れて、取引データとそれに対応する受領証との一意性を保証することができる。更なる組み合わせおよびコンフィギュレーションも可能である。
送信されるデータの可能な限り最良のセキュリティを保証するために、変化IDの秘密鍵(例えば、K、K、K)は、秘密に保たれる必要がある。例えば、トレントがボブに、ボブの現在の秘密鍵(例えばK)で暗号化された新しい変化IDを提供する場合、ボブの現在の秘密鍵を特定した盗聴者は、トレントから提供されるボブの新しい変化IDを入手することができる。そして、盗聴者は、新しい変化IDを使用して、偽のデータを送信すること及び/又はボブとトレントとの間で交換されるその後のデータの平文を入手することができる。
理論的には、1人または複数の盗聴者が、力任せ攻撃(brute force attack、ブルート・フォース攻撃/総当たり攻撃)を行うことにより特定のデータを暗号化するために使用される鍵を特定する(または特定を試みる)ことが可能である(本文献の先の部分で述べたように現実性はごく低いが)。図22に示すように、ブルート・フォース攻撃は、整合性のあるデータまたは認識可能なデータ(例えば、人間に読めるデータ)を生成する鍵が見つかるまで、すべての可能な鍵で暗号文を解読することを含む。図22に示すように、盗聴者は、最初の候補の鍵、即ち、ゼロの候補鍵を決定する(ステップ400)。盗聴者は次いで、その候補鍵を使用して暗号文を解読する(ステップ402)。暗号文を解読すると、盗聴者は、その結果(即ち、候補の平文)を調べて、候補鍵で解読された暗号文が、整合性のある平文または整合性のあるパターンを生成するかどうかを判定する(ステップ404)。盗聴者が、入手された暗号文に対応する平文(またはその一部またはパターン)を入手している又は知っている場合、正しい候補鍵が見つかったかどうかをより容易に判定することができる。例えば、盗聴者が暗号文を入手し、その暗号文が、個人名と、その後に続く4桁の暗証番号(「PIN」)を含むことを知っている場合、盗聴者は、候補の鍵が、個人名を含む平文を生成するまで候補鍵を適用することができる。そして、盗聴者は、生成された平文に含まれる残りの情報がそのPINに対応することを、ある程度の確実性をもって推測することができる。
図22に示すように、盗聴者が、特定の候補鍵で暗号文を解読することにより生成された候補の平文中に整合性のあるパターンを見つけると(ステップ406)、盗聴者は、現在の候補鍵が、暗号文を生成するのに使用された鍵と等しい、またはその鍵であることをある程度の確実性で知る(ステップ407)。
盗聴者が、特定の候補鍵で暗号文を解読することにより生成された候補の平文に整合性のあるパターンを見つけられない場合(ステップ406)、盗聴者は、候補鍵に変更を加え(例えば、候補鍵を増分し)(ステップ408)、変更を加えた候補鍵を使用して暗号文を解読し(ステップ402)、生成された候補平文に整合性のある平文または整合性のあるパターンがあるか調べる(ステップ404)。十分な処理力と時間とがあれば、盗聴者は、特定の候補鍵が整合性のある平文または整合性のあるパターンを有する候補平文を生成するまで、このプロセスを継続することができ、従って、暗号文を生成するために使用された鍵を特定することができる。
しかし、盗聴者が平文または平文のパターンについて何の知識も持たない場合(即ち、内容の手がかりを持たない場合)、正しい候補鍵が見つかったかどうかを判定する盗聴者の能力は大きく低下し、恐らくは、なくなる。例えば、平文が、特定の鍵で暗号化された乱数を含む場合には、盗聴者がブルート・フォース攻撃で何個の鍵を試みても、盗聴者には、候補の平文が、暗号文に対応する真の平文であるかどうかを判定する手段がない。暗号化された乱数を任意の候補鍵で解読すると乱数が生成され、その乱数は、他の候補鍵で生成される他の乱数のような、当初の乱数のようなものである。
ボブ、ヴェラ、トレントに関連する上記の取引鍵を交換する例を参照すると、暗号化されたメッセージの何れかの部分が認識可能であるか、既知であるか、既知になるか、または何らかの内容の手がかりを含む場合、盗聴者は、暗号化されたメッセージに平文攻撃または部分平文攻撃を行い、そのメッセージを暗号化するために使用されたボブまたはヴェラの秘密鍵を発見できる可能性がある。例えば、ボブが次のメッセージをトレントへ送信し、このメッセージが盗聴者に傍受されるとする。
B→T:NE(K,VidX)
盗聴者は、ヴェラの識別Vidと上記メッセージの形式とが既知であるか、あるいは公開されているので、傍受したメッセージにブルート・フォース攻撃を行うことができる。従って、盗聴者は、ボブの秘密鍵KとデータXを入手することができる。更に、盗聴者は、ボブの秘密鍵Kを入手すると、ボブの現在の秘密鍵Kを使用して、ボブの次の変化ID(例えばN’およびK’)などのような、ボブの現在の秘密鍵Kで暗号化されたすべてのデータを入手することができる。
盗聴者は、暗号化されたメッセージまたは暗号化されたメッセージを生成するために使用された通信プロトコルについての他の知識を使用して、ブルート・フォース攻撃を行うことができる。例えば、盗聴者は、暗号化しないで渡される変化IDの数(例えばN)を使用してブルート・フォース攻撃を行うことができる。盗聴者は、変化IDの数を生成するために使用されるアルゴリズムについての知識も使用して、ブルート・フォース攻撃を行うこともできる。
上記で指摘したように、発見不可能なデータ(すなわち、ランダムのデータまたは内容の手がかりを持たないデータ)を暗号化するために使用された鍵は、ブルート・フォース攻撃を使用して特定または発見されることはできない。なぜなら、盗聴者は、正しい候補鍵が見つかった時にそれを判断することができないからである。しかし、発見可能データ(即ち、既知のデータ、後に開示される可能性のあるデータ、認識可能なデータ、または既知の形式や容易に推測される形式を持つデータ)を暗号化するために使用された鍵は、ブルート・フォース攻撃を使用して特定されることができる(理論的には)。発見可能データおよび発見不可能データが、一緒に、または同じ暗号鍵で暗号化された場合、発見可能データを使用してブルート・フォース攻撃を通じて特定される鍵は、発見不可能データを暗号化するために使用された鍵でもあり、従って、発見不可能データが発見されることができる。
暗号化データのセキュリティを高め、盗聴者がブルート・フォース攻撃を使用して暗号鍵を入手するのを阻止するために、本発明の実施形態は、変化IDに含まれる秘密鍵などのような発見不可能データのセキュリティを保護する暗号化方式を提供する。
図23は、暗号化されるデータに含められることが可能なデータの種類を示す。暗号化され、特定の受信者へ送信されるデータ420は、データのタイプまたはクラスに区分される。第1のクラスのデータは、発見不可能データ、即ち、秘密データのクラス430を含む。秘密データ・クラス430は、秘密に保たれ、権限のあるエンティティのみに知られたデータを含むことができる。例えば、秘密データ・クラス430は、変化IDの秘密鍵および/またはエンティティの証明を含むことができ、これらは両方ともランダムであり、認証者および/または支払い認証者と、その証明および秘密鍵の所持者とのみにより知られ得る。
第2のクラスのデータは、発見可能データ・クラス440を含む。発見可能データ・クラス440は、既知のデータ、後に知られる可能性のあるデータ、認識可能な(例えば、人間が読める)データ、または既知の形式や容易に推測される形式を持つデータを含むことができる。一部の実施形態では、発見可能データ440は更に、幾つかの下位クラスに分割される。例えば、発見可能データ・クラス440は、第1のタイプの発見可能データを含む第1の発見可能データ・サブクラス442を含むことができる。第1のタイプの発見可能データは、標準化されたヘッダや、既知のパターンや、他の公的に使用可能な形式等のような、容易に区別される特徴を有するデータを含み得る。一部の実施形態では、第1の発見可能データ・サブクラス442は、エンティティ間で送信されるコンテンツと、認証者により提供される変化IDの数(例えば、N、N、N)を含む。
発見可能データ・クラス440は、第2のタイプの発見可能データを含む第2の発見可能データ・サブクラス444を含むこともできる。第2のタイプの発見可能データは、第1のタイプの発見可能データを含むメッセージを暗号化するために使用された鍵を含むことができる。一部の実施形態では、第2の発見可能データ。サブクラス444は、変化IDの秘密鍵(例えば、K、K、K)を含む。例えば、取引鍵の交換プロトコルに関して上記で述べたように、ボブは、彼の秘密鍵Kで暗号化されたヴェラの公に知られた識別子Vidを含むメッセージを、トレントへ送信する。
B→T:NE(K,VidX)
ヴェラの識別子Vidは、公に知られており、従って、第1のタイプの発見可能データであることから、ボブの秘密鍵Kは、第2のタイプの発見可能データと考えることができる。なぜなら、ボブの秘密鍵Kは、第1のタイプの発見可能データを暗号化しているからである。
発見可能データ・クラス440は更に、第3の発見可能データ・サブクラス446を含むことができ、このサブクラスは、本来は発見不可能なデータであるが、第2のタイプの発見可能データとみなされる鍵で暗号化されているために発見可能になるデータを含む。例えば、ボブからトレントへ送信される上記のメッセージに示すように、データXは、ランダムにボブに割り当てられ、ボブとトレントのみに知られる。従って、データXは、発見不可能である。しかし、データXはボブの秘密鍵K(これは、発見可能データ(例えばVid)を暗号化するために使用されるため、第2のタイプの発見可能データである)で暗号化されているので、データXは、第3のタイプの発見可能データと考えられることができる。
図24および図25は、発見不可能データのセキュリティを保護する暗号化方式を説明する。発見不可能データ、即ち、秘密データのセキュリティを保護するために、別個の鍵が使用されて異なるタイプのデータを暗号化する(以後「分離暗号化プロトコル」と称する)。例えば、1または複数の鍵(例えば、1または複数の変化ID)が使用されて発見不可能データを暗号化し、1または複数の鍵(例えば、1または複数の変化ID)が使用されて発見可能データを暗号化することができる。下記で述べるように、発見不可能データと発見可能データとを暗号化するために同じ鍵は決して使用されないので、第3のタイプの発見可能データがなくなる。
図24に示すように、秘密データ・クラス430に含まれるデータは、秘密データ・クラス430に含まれるデータの暗号化のみに使用される1または複数の鍵450(この例では以後「発見不可能データ鍵450」と称する)で暗号化されることができる。オプションとして、発見可能データ・クラス440に含まれるデータは、発見可能データ・クラス440に含まれるデータの暗号化のみに使用される1または複数の鍵460(この例では以後「発見可能データ鍵460」と称する)で暗号化されることができる。秘密データ・クラス430に含まれるデータを暗号化するために使用される発見不可能データ鍵450は、発見可能データ・クラス440に含まれるデータを暗号化するために使用される発見可能データ鍵460から特定されることはできない(即ち、鍵460とは無関係である)ことを理解されたい。データ420は、そのデータ420の個々の部分が所属するデータ・クラスに従って分けて、連続したデータ・ブロックに入れるようにする必要はないことも理解されたい。図25に示すように、秘密データ・クラス430と発見可能データ・クラス440とに含まれるデータは、混在させた幾つかの部分に分割されることができる。
上記で述べたように、発見不可能データから発見可能データを分離し、発見不可能データを、発見可能データを暗号化するために使用された発見可能データ鍵460と異なる発見不可能データ鍵450で暗号化することにより、発見可能データ鍵460は発見不可能データの暗号化には決して使用されないので、第3のタイプの発見可能データがなくなる。従って、発見可能データを暗号化するために使用された発見可能データ鍵460がブルート・フォース攻撃を使用して特定されたとしても、その特定された発見可能データ鍵460を使用して、発見不可能データまたは秘密データを入手することはできない。
例えば、ボブが、ヴェラとの通信に使用する取引鍵をトレントに要求したいと思っており、従って、ボブがトレントへデータXとヴェラの識別子Vidとを送信するとする。また、ボブが、発見不可能データのみに使用される数NB1とそれに対応する鍵KB1(この例では、以後それぞれを「発見不可能データの数NB1」、「発見不可能データ鍵KB1」と称する)を含む変化IDと、第1のタイプおよび第2のタイプの発見可能データのみに使用される数NB2と鍵KB2(この例では、以後それぞれ「発見可能データの数NB2」、「発見可能データ鍵KB2」と称する)を含む変化IDを有するとする。ヴェラの識別子Vidは第1のタイプの発見可能データ(即ち、公に知られている)なので、ボブは、彼の発見可能データ鍵KB2でヴェラの識別子Vidを暗号化することができる。同様に、ボブは、彼の発見不可能データ鍵KB1でデータXを暗号化することができる。ヴェラの識別子Vidは、データXとは別に暗号化されることから、データXは、発見可能データを暗号化する鍵で暗号化されないので、上記のようにもはや第3のタイプの発見可能データとはみなされない。従って、データXは、発見不可能データになる。一部の実施形態では、ボブはまた、トレントに対してボブ自身とメッセージの個々の部分とを識別するために、別々に暗号化された部分に、発見不可能データの数NB1と発見可能データの数NB2を付加する。ボブは、その結果として作成されたメッセージをトレントへ送信することができる。
B→T:NB1E(KB1,X)NB2E(KB2,Vid
盗聴者が、ボブからトレントへ送信される上記の送信を入手した場合、盗聴者は、ヴェラの識別子Vidを暗号化した発見可能データ鍵KB2を、ブルート・フォース攻撃を使用して入手することができる(理論的には)。しかし、第2の秘密鍵KB2を知ることでは、盗聴者は発見不可能データ鍵KB1を取得することはできず、従って、同じく、発見不可能データ鍵KB1で暗号化されたデータXまたは他のデータは取得できない。上記で述べたように、ボブは、ヴェラの識別子Vidを暗号化せず、平文で送信することを選択することもできる。
鍵の交換を完了するために、ヴェラが、発見不可能データのみに使用される数NV1およびそれに対応する鍵KV1を含む変化ID(この例では、以後それぞれを「発見不可能データの数NV1」および「発見不可能データ鍵KV1」と称する)と、発見可能データのみに使用される数NV2および鍵KV2(この例では、以後それぞれ「発見可能データの数NV2」、「発見可能データ鍵KV2」と称する)を含む変化IDと、ヴェラおよびトレントのみに知られたデータYとを有するものとする。
トレントは、ボブとヴェラに割り当てられた変化IDを知っており、ボブからのメッセージを解読することができ、ボブとヴェラへの取引鍵KBVを生成することができる。取引鍵KBVは、第1のタイプの発見可能データを暗号化するためにボブおよび/またはヴェラにより使用される可能性があるので、取引鍵KBVは、第2のタイプの発見可能データと考えることができ、ボブとヴェラの発見可能データ鍵(例えば、KB2およびBV2)で暗号化されることができる。トレントは、別々の応答で、取引鍵KBVをボブとヴェラとへ提供する。
一部の実施形態では、トレントのボブへの応答は、取引鍵KBVと、データXと、発見不可能データのみに使用されるボブの新しい数NB1’および新しい鍵KB1’(この例では、以後それぞれを「新しい発見不可能データの数NB1’」および「新しい発見不可能データ鍵KB1’」と称する)を含む変化IDと、第1のタイプおよび第2のタイプの発見可能データのみに使用されるボブの新しい数NB2’および新しい鍵KB2’(この例では、以後それぞれを「新しい発見可能データの数NB2’」および「新しい発見可能データ鍵KB2’」と称する)を含む変化IDとを含む。取引鍵KBVは、第1のタイプの発見可能データを暗号化するために使用されることができるので、トレントは、ボブの現在の発見不可能鍵KB1で取引鍵KBVを暗号化する。データXも発見不可能データなので、トレントは、データXもボブの現在の発見不可能データ鍵KB1で暗号化する。更に、ボブの新しい発見不可能データ鍵KB1’は発見不可能データと考えられるので(発見不可能データの暗号化のみに使用されるランダムの秘密鍵だから)、トレントは、ボブの現在の発見不可能データ鍵KB1で新しい発見不可能データ鍵KB1’を暗号化する。しかし、新しい発見不可能データの数NB1’と新しい発見可能データの数NB2’とは、暗号化されないで渡されるため、第1のタイプの発見可能データである。従って、トレントは、ボブの現在の発見可能データ鍵KB2で、新しい発見不可能データの数NB1’と新しい発見可能データの数NB2’を暗号化する。また、ボブの新しい発見可能データ鍵KB2’は第1および第2のタイプの発見可能データを暗号化するために使用されるので、トレントは、ボブの現在の発見可能データ鍵KB2を使用して、鍵KB2’を暗号化する。オプションとして、トレントの応答は、ヴェラの識別子Vidを含むことができ、ヴェラの識別子Vidは第1のタイプの発見可能データなので、トレントは、ボブの現在の発見可能データ鍵KB2を使用してヴェラの識別子Vidを暗号化することができる。一部の実施形態では、トレントは、ボブの現在の発見不可能データの数NB1を、ボブの現在の発見不可能データ鍵KB1で暗号化された応答の部分に付加し、ボブの現在の発見可能データの数NB2を、ボブの現在の発見可能データ鍵KB2で暗号化された応答の部分に付加して、応答の別々の部分を識別するようにする。トレントは、次いで応答をボブへ送信することができる。
T→B:NB1E(KB1,KB1’X)NB2E(KB2,NB1’NB2’KB2’VidBV
トレントは、同様の応答を生成し、ヴェラへ送信することができる。
T→V:NV1E(KV1,KV1’Y)NV2E(KV2,NV1’NV2’KV2’BidBV
上記のプロトコルは、メッセージ単位で何れのプロトコルに対しても一般化されることができる。例えば、NE(K,D...)が送信されようとするメッセージであるとし、Nは、オプションのパラメータであるとする。上記の分離暗号化プロトコルを使用してこのメッセージを送信するために、メッセージの元の形式に基づいて、データD、D、...を発見不可能なデータと3つのタイプの発見可能データに分ける。例えば、D 、D ,...を発見不可能データであるとし、D 、D ,...を第1のタイプおよび第2のタイプの発見可能データであるとし、D 、D ,...を第3のタイプの発見可能データであるとする。そして、発見不可能データ(D 、D ,...)と第3のタイプの発見可能データ(D 、D ,...)とを第1の鍵Kで暗号化し、第1のタイプおよび第2のタイプの発見可能データ(D 、D ,...)を第2の鍵Kで暗号化することにより、メッセージが構築されることができ、ここで、第1の鍵Kと第2の鍵Kとは異なり、互いから計算で導出することはできない。
一部の実施形態では、エンティティが、第2のタイプの発見可能データを更に保護することを望む可能性がある。例えば、上記のように、トレントが取引鍵KBVをボブに提供する際、トレントは、ボブの現在の発見可能データ鍵KB2で取引鍵KBVを暗号化する。しかし、発見可能鍵KB2は、公に知られているヴェラの識別子Vidの暗号化にも使用される。そのため、盗聴者が、ボブの現在の発見可能データ鍵KB2で暗号化されたトレントからの応答の部分にブルート・フォース攻撃を行い、KB2だけでなく、取引鍵KBVも入手することができる。この技術を使用して、盗聴者は、取引鍵KBVがボブまたはヴェラに使用される前に、または、ボブおよび/またはヴェラが発見可能データを暗号化するために取引鍵KBVを使用しなくとも、取引鍵KBVを入手することができる。
上記の問題を克服することを試みるために、第2のタイプの発見可能データは、第1のタイプの発見可能データの暗号化に使用される鍵とは別の鍵で暗号化されることができる。一部の実施形態では、第2のタイプの発見可能データの暗号化のみに使用される数と秘密鍵を含んだ別個の変化IDが、エンティティに割り当てられる。例えば、ボブが、第2のタイプの発見可能データの暗号化のみに使用される代替の数NB3と代替の鍵KB3を含む代替の変化IDを持っているとすると、トレントからボブへ送信される上記の応答は、代替の鍵KB3で暗号化された取引鍵KBVを含むように変更されることができる。
T→B:NB1E(KB1,KB1’X)NB2E(KB2,NB1’NB2’KB2’Vid)NB3E(KB3,KB3’KBV
取引鍵KBVと第1のタイプの発見可能データ(例えば、NB1’、NB2’、およびVid)を別々に暗号化することにより、盗聴者は、トレントからボブへの応答にブルート・フォース攻撃を行うことで取引鍵KBVを入手することはできない。応答に対するブルート・フォース攻撃で第2のタイプの発見可能データが明らかになるのを阻止するために、発見可能データ鍵KB2’および/または他の第2のタイプの発見可能データは、発見可能データ鍵KB2で暗号化するのではなく、代替の鍵KB3で暗号化されることもできることを理解されたい。
一部の実施形態では、第2のタイプの発見可能データを暗号化するための代替の変化IDを受け取る代わりに、エンティティは、1回使用されるたびに又は別の時程で(例えば、何回かの使用後や、特定の期間後など)変動する又は変動しない一つの代替の鍵を受け取る。この代替鍵は、認証者と、その代替鍵を割り当てられたエンティティとのみに知られる秘密鍵である。一部の実施形態では、エンティティは、その代替鍵を使用して、第2のタイプの発見可能データを直接に暗号化する。他の実施形態では、エンティティは、自身の代替鍵と発見不可能データ鍵とを使用して、第2のタイプの発見可能データの暗号化に使用される新しい鍵を生成する。例えば、ボブが、ヴェラと取引鍵の交換を開始することを希望しており、従って、ボブがトレントへヴェラの識別子VidとデータXを送信するものとする。また、ボブが、発見不可能データのみに使用される数NB1とそれに対応するデータ鍵KB1(この例では、以後それぞれを「発見不可能データの数NB1」、「発見不可能データ鍵KB1」と称する)を含む変化IDと、第1のタイプの発見可能データのみに使用される数NB2と鍵KB2(この例では、以後それぞれ「発見可能データの数NB2」、「発見可能データ鍵KB2」と称する)を含む変化IDと、取引鍵KBV等のような第2のタイプの発見可能データの暗号化のみに使用される代替鍵Lとを有するものとする。一部の実施形態では、ボブは、彼の発見可能データ鍵KB2を自身の代替鍵Lとして使用する。他の実施形態では、ボブは、データXを彼の代替鍵Lとして使用することができる。ボブの発見不可能データ鍵KB1、発見可能データ鍵KB2、および代替鍵Lは、すべてトレントに知られており、1回使用されるたびに又は別の時程で変動する(即ち、トレントにより再度割り当てられる)ことができる。
上記のように、取引鍵の交換を開始するために、ボブは、データXとヴェラの識別子Vidを含む要求を生成する。ボブは、上記のように要求を分け、暗号化することができる。ボブは、トレントへその要求を送信する。
要求を受信すると、トレントは、要求される取引鍵KBVを生成することができる。ボブへ取引鍵KBVを送信するために、トレントは、新しい暗号鍵を生成するために、ボブの発見不可能データ鍵KB1とボブの代替鍵KB3(またはL)のXORを生成することができる。
XOR(KB1,KB3
XOR演算では、ボブの発見不可能データ鍵KB1とボブの代替鍵KB3とのビット単位の排他的「or」演算を行う。従って、このXOR演算では、ボブの発見不可能データ鍵KB1とボブの代替鍵KB3とのうちの、より長い鍵の長さと等しい長さのビット列を生成する。生成されるビット列のそれぞれのビット位置は、ボブの発見不可能データ鍵KB1とボブの代替鍵KB3との対応する位置が同じ(即ち、両方とも「0」または両方とも「1」)である場合に「0」と等しくなり、ボブの発見不可能データ鍵KB1とボブの代替鍵KB3との対応する位置が同じでない場合に「1」に等しくなるように設定される。XOR演算は、一般に、入力の1つ(例えば、ボブの発見不可能データ鍵KB1またはボブの代替鍵KB3)が既知でない場合に、不可逆となる。
トレントは、生成されたビット列(即ち、XOR演算の結果)を使用して、取引鍵KBVを暗号化する。トレントは、暗号化された取引鍵KBVを応答でボブへ送信する。トレントは、上記のように応答を分け、暗号化することができる。
T→B:NB1E(KB1,KB1’X)NB2E(KB2,NB1’NB2’KB2’Vid)E(XOR(KB1,KB3),KBV
ボブは、解読鍵を生成し、取引鍵KBVを入手するために、トレントと同じXOR演算を行うことができる。盗聴者が、取引鍵KBVを入手し、ブルート・フォース攻撃を通じて暗号鍵(即ち、XOR演算の結果として得られるビット列)を入手しようとしても、盗聴者は、盗んだ鍵を使用して、ボブの発見不可能データ鍵KB1、ボブの代替鍵KB3、データXを入手することはできない。また、ボブの発見不可能データ鍵KB1とボブの代替鍵KB3との少なくとも一方が、1回の使用ごとに又は別の時程で変動する場合には、盗まれた鍵は、その後のメッセージに含まれるデータの暗号化には使用されない。従って、盗まれた鍵を使用して、そのようなメッセージに含まれるデータを入手することはできない。
一部の実施形態では、さらなるセキュリティを提供するために、発見可能データと発見不可能データを暗号化するために使用される異なる鍵は、入れ子(ネスト)にされる(以後「入れ子型分離暗号化プロトコル」と呼ぶ)。例えば、上記のようにボブが次のメッセージをトレントへ送信するとする。
B→T:NB1E(KB1,X)NB2E(KB2,Vid
このメッセージは、2つの別個の部分を含む。例えば、このメッセージは、暗号化された発見不可能データを含む第1の部分NB1E(KB1,X)と、暗号化された発見可能データを含む第2の部分NB2E(KB2,Vid)を含む。これらの部分は、別々に暗号化され、ともに連結されるので、盗聴者は、それら部分を別々に攻撃することができる。
例えば、盗聴者は、第2の部分にブルート・フォース攻撃を行うことができ(ヴェラの識別子Vidが公に知られているため)、ボブの発見可能データ鍵KB2を入手することができる。ボブの発見可能データ鍵KB2を入手すると、盗聴者は、ボブがトレントへ送信した要求の詳細を入手することができる。恐らくは、より損害が大きいが、盗聴者は、中間者攻撃(man−in−the−middle attack)を行うこともできる。中間者攻撃は、盗聴者が送信データを傍受し、そのデータを読むこと及び/又は改変することを試みる場合に起き、多くの場合、データの送信者と意図されるデータの受信者とに知られずに行われる。例えば、盗聴者は、ボブの盗まれた発見可能データ鍵KB2を使用して、ボブのメッセージの第2の部分を、ボブの発見可能データ鍵KB2で暗号化された盗聴者の識別子に置き換えることにより、ボブのメッセージの第2の部分を改変または再構築することができる。そして、盗聴者は、改変されたメッセージをトレントへ送信することができる。
トレントは、改変されたメッセージを入手すると、それぞれの部分を解読し、要求される処理を行う。メッセージの第1の部分と第2の部分とは基本的に関係しないので、トレントは、第2の部分に含まれる証明が正当なものであるかどうかを判断する手段を持たない。
上記の状況を克服するために、ボブは、発見不可能データ鍵KB1と発見可能データ鍵KB2とを使用して、入れ子構造の暗号化を行うことができる。例えば、ボブが、データXとヴェラの識別子Vidとを含むトレントへの要求を生成するとする。ボブは、発見不可能データ鍵KB1でデータX(即ち、発見不可能データ)を暗号化することができる。一部の実施形態では、ボブは、彼の発見不可能データの数NB1を、暗号化の結果に付加する。そして、ボブは、暗号化したデータXにヴェラの識別子Vidを付加し、その結果を、発見可能データ鍵KB2で暗号化することができる。そして、ボブは、その結果に、彼の発見可能データの数NB2を付加することができる。
B→T:NB2E(KB2,VidE(KB1,X))
上記の要求は、発見不可能データと発見可能データとの両方に依存する。なぜなら、両形態のデータが最終的な暗号化ステップで含められるからである。入れ子化は、どちらの方向にも行えることを理解されたい。例えば、ボブは、ヴェラの識別子Vidを発見可能データ鍵KB2で暗号化し、データXをその結果に付加し、その組み合わせを発見不可能データ鍵KB1で暗号化することができる。
B→T:NB1E(KB1,XE(KB2,Vid))
上記のメッセージに示すように、一部の実施形態では、エンティティは、変化IDの鍵(例えば、KB1およびKB2)が入れ子にされる場合には、自身をメッセージの発信者として識別するために1つの変化IDの数(例えばNB1)のみを必要とすることもある。例えば、ボブには、発見不可能データのみまたは発見可能データのみを暗号化するためにボブが使用することができる1つの数Nおよび1つの秘密鍵Kを含む1つの変化IDと、その変化IDの秘密鍵Kで暗号化されないデータ・タイプを暗号化するためにボブが使用することができる代替鍵L等のような一つの別の鍵とが、割り当てられることができる。ボブは、代替鍵Lを使用して、秘密鍵Kで暗号化されたデータの中に入れ子にされたデータを暗号化することができる。そして、ボブは、その結果に、彼の数Nを付加することができる。
B→T:NE(K,XE(L,Vid))
上記のプロトコル(例えば、変化IDプロトコル、分離暗号化プロトコル、および入れ子型分離暗号化プロトコル)は、ブルート・フォース攻撃を困難にするか、そのような攻撃の有用性を低下させる機能を含むことができることを理解されたい。例えば、上記のプロトコルは、ブルート・フォース攻撃が成功して鍵が発見されるまでに何日も何ヶ月も、あるいは何年も必要とするような、強い暗号化技術を用いることができる。そのため、理論的には攻撃の手段になると思われるものが、実際的にはそれの使用が困難あるいは不可能となりうる。
また、盗聴者がブルート・フォース攻撃を行うために必要とされる時間の間にエンティティと認証者の間で複数のメッセージが送信される可能性があるため、盗聴者に傍受されたメッセージに関連した変化IDは、そのエンティティに割り当てられた現在の変化IDとは異なる可能性がある。従って、あるエンティティに割り当てられた現在の変化IDを暴くことを試みる盗聴者は、メッセージをたどって、現在の変化IDを入手するには、そのエンティティと認証者の間で送信されるすべてのメッセージを追跡し、記憶しなければならない。例えば、盗聴者がブルート・フォース攻撃を使用してあるエンティティの変化IDの特定を試みる場合に、認証者は、盗聴者がブルート・フォース攻撃を行っている間に、複数回変化IDを割り当て直すこと、即ち、変動させることができる。盗聴者が最も新しい変化IDの鍵を欲する場合、盗聴者は、現在割り当てられている変化IDを特定するには、現在は無効になっている過去の変化IDを一旦入手すると、その発見した変化IDを使用して、認証者からエンティティへ送信されたそれぞれのメッセージを解読し、変動または割り当て直されたそれぞれの変化IDを入手しなければならない。そのようなトレースを行うための追跡と記憶の要件は、ブルート・フォース攻撃を行うことを試みる盗聴者にとって非常に厳しいものであり得る。
また、盗聴者は、「有用な」情報を発見するためには複数回のブルート・フォース攻撃を行わなければならない可能性がある。例えば、上記の分離暗号化プロトコルでは、盗聴者は、取引鍵(例えばKBV)で暗号化されたメッセージにブルート・フォース攻撃を行うことができ、従って、取引鍵(例えばKBV)を入手できる可能性がある。しかし、その取引鍵を使用してエンティティの秘密鍵を入手するには、盗聴者は、認証者から送信されたメッセージ、すなわち、そのエンティティの秘密鍵で暗号化された、現在既知となったその取引鍵を含むメッセージに、第2のブルート・フォース攻撃を行うことを必要とされる。上記のように、1回のブルート・フォース攻撃は、計算に何日も何ヶ月も、あるいは何年も要する可能性があり、従って、第2のブルート・フォース攻撃を行うと、「有用な」情報(例えば、変化IDの秘密鍵)を入手するのに必要な時間が倍になり得る。更に、盗聴者は、「有用な」情報を入手するために、入れ子になったブルート・フォース攻撃を行わなければならない可能性もあり、その場合、盗聴者は、それぞれの第1の候補鍵を試し、それぞれの第1の候補鍵について、それぞれの第2の候補鍵を試すことが必要となる。例えば、上記の入れ子型分離暗号化プロトコルでは、下記のメッセージからデータXを入手するには、盗聴者は、外側の暗号化結果E(K,XE(L,Vid)について、すべての候補鍵を試し、そして、外側の暗号化結果の候補鍵ごとに、入れ子になった暗号化結果E(L,Vid)についてすべての候補鍵を試す必要がある。
B→T:NE(K,XE(L,Vid))
1回のブルート・フォース攻撃にN個の処理時間単位が必要とされる場合、1回の入れ子型のブルート・フォース攻撃(即ち、別のブルート・フォース攻撃の中に入れ子になった1回のブルート・フォース攻撃)には、約N個の処理時間単位が必要となり得、その結果、盗聴者にとってブルート・フォース攻撃は、処理要件から見て、非実際的または不可能になり得ることを理解されたい。
上記から理解できるように、種々の実施形態は、セキュリティとコンテンツ所有者の法的権利を保護する機能を備える、コンテンツおよび情報を配布するシステムおよび方法を提供する。実施形態は、セキュリティと、取引関係者の機密性のある金融情報を保護する機能を備える電子商取引を行うシステムおよび方法も提供する。本発明の追加的な特徴と態様は、特許請求の範囲に示される。
図1は、4つのエンティティが通信に関係する、本発明の一例示的実施形態のシステムの概略図である。 図2は、3つのエンティティが通信に関係する、本発明の別の例示的実施形態のシステムの概略図である。 図3aは、本発明の一実施形態で使用されるビット・ストリーム(「変化識別子」と称される)の図である。 図3bおよび図3cは、変化IDを配布する方式の説明図である。 図3bおよび図3cは、変化IDを配布する方式の説明図である。 図4は、本発明の一例示的実施形態のためのライセンス構造の概略図である。 図5は、図1に示されるシステムの一部の概略図である。 図6は、図1に示されるシステムで使用される通信プロトコルの説明図である。 図7は、図1に示されるシステムの一部の概略図であり、複数のサービス提供者へのライセンスの配布を説明する。 図8は、本発明の一形態で使用される変化識別子のサイクルの説明図である。 図9aは、本発明の一実施形態におけるコンテンツ鍵の管理の例示的な説明図である。 図9bは、図9aに示される状況でコンテンツが要求された時に発生するデータの流れの例示的説明図である。 図10aは、本発明の別の実施形態におけるコンテンツ鍵の管理の例示的説明図である。 図10bは、図10aに示される状況でコンテンツが要求された時に発生するデータの流れの例示的説明図である。 図11は、コンテンツ要求の例示的説明図である。 図12は、承認段階を示すコンテンツ要求の例示的説明図である。 図13は、配信段階を示すコンテンツ要求の例示的説明図である。 図14は、透かしが使用される、本発明の別の例示的実施形態のライセンス構造の説明図である。 図15は、コンテンツに透かしを入れることを追加した、図1に示されるシステムで使用される通信プロトコルの説明図である。 図16は、3つのエンティティが通信に関係する場合におけるコンテンツを配布するために使用されるデバイスの例示的実施形態の概略図である。 図17は、図16に示される周辺機器の1つの内部のハードウェアの概略図である。 図18は、4つのエンティティが電子商取引を行うための通信に関係する、本発明の例示的一実施形態のシステムの説明図である。 図19は、図18に示されるシステムで使用される通信プロトコルの説明図である。 図20は、4つのエンティティが電子商取引を行うための通信に関係する、本発明の別の例示的実施形態のシステムの説明図である。 図21は、図20に示されるシステムで使用される通信プロトコルの説明図である。 図22は、本発明の一実施形態によるブルート・フォース手法を説明する。 図23は、本発明の一実施形態により暗号化されるデータに含まれるデータのタイプを示す。 図24および25は、本発明の一実施形態による、発見不可能データのセキュリティを保護する暗号化方式を示す。 図24および25は、本発明の一実施形態による、発見不可能データのセキュリティを保護する暗号化方式を示す。

Claims (78)

  1. 変化識別子を使用して電子商取引を行う方法。
  2. 請求項1に記載の方法であって、
    第1の変化識別子で購入者取引データを暗号化するステップと、
    前記購入者取引データを認証者デバイスへ送信するステップと、
    前記購入者取引データを解読するステップと、
    支払い要求を生成するステップと、
    第3の変化識別子で前記支払い要求を暗号化するステップと、
    前記支払い要求を、支払い認証者デバイスへ送信するステップと
    を更に備える方法。
  3. 請求項2に記載の方法であって、第2の変化識別子でベンダ取引データを暗号化し、前記ベンダ取引データを前記認証者デバイスへ送信するステップを更に備える方法。
  4. 請求項3に記載の方法であって、前記ベンダ取引データを解読するステップを更に備える方法。
  5. 請求項2に記載の方法であって、前記支払い要求を生成する前記ステップは、ベンダ・デバイスの識別とベンダの証明とを含む支払い要求を生成するステップを含む、方法。
  6. 請求項2に記載の方法であって、第2の受領証をベンダ・デバイスへ送信するステップを更に備える方法。
  7. 請求項2に記載の方法であって、第5の変化識別子をベンダ・デバイスへ送信するステップを更に備える方法。
  8. 請求項2に記載の方法であって、前記支払い認証者デバイスが前記支払い要求を承認する場合、承認メッセージをベンダ・デバイスへ送信するステップを更に備える方法。
  9. 請求項2に記載の方法であって、前記支払い認証者デバイスが前記支払い要求を拒絶する場合、拒絶メッセージをベンダ・デバイスへ送信するステップを更に備える方法。
  10. 請求項2に記載の方法であって、前記支払い要求を生成する前記ステップは、購入者デバイスの識別と購入者の証明とを含む支払い要求を生成するステップを含む、方法。
  11. 請求項2に記載の方法であって、第1の受領証を購入者デバイスへ送信するステップを更に備える方法。
  12. 請求項2に記載の方法であって、第4の変化識別子を購入者デバイスへ送信するステップを更に備える方法。
  13. 請求項2に記載の方法であって、前記支払い認証者デバイスが前記支払い要求を承認する場合、購入者デバイスへ承認メッセージを送信するステップを更に備える方法。
  14. 請求項2に記載の方法であって、前記支払い認証者デバイスが前記支払い要求を拒絶する場合、購入者デバイスへ拒絶メッセージを送信するステップを更に備える方法。
  15. 請求項2に記載の方法であって、第3の受領証を前記支払い認証者デバイスへ送信するステップを更に備える方法。
  16. 請求項2に記載の方法であって、第6の変化識別子を前記支払い認証者デバイスへ送信するステップを更に備える、方法。
  17. 請求項2に記載の方法であって、前記支払い認証者デバイスが前記支払い要求を承認する場合、第1の口座と第2の口座との間で資金を転送するステップを更に備える方法。
  18. 請求項2に記載の方法であって、前記支払い認証者デバイスが前記支払い要求を承認する場合、エスクロー・サービスを提供するステップを更に備える方法。
  19. 第1のデバイスと第2のデバイスとの間で通信を確立する方法であって、
    取引鍵を求める要求を生成するステップと、
    前記取引鍵の要求を、前記第1のデバイスの第1の変化識別子で暗号化するステップと、
    暗号化された前記取引鍵の要求を認証者デバイスへ送信するステップと、
    取引鍵を生成するステップと、
    前記取引鍵を含む第1のメッセージを生成するステップと、
    前記第1のメッセージを、前記第1のデバイスの前記第1の変化識別子で暗号化するステップと
    を備える方法。
  20. 請求項19に記載の方法であって、前記第1のデバイスの第3の変化識別子を生成するステップを更に備え、前記第1のメッセージは前記第3の変化識別子を含む、方法。
  21. 請求項20に記載の方法であって、前記第1のメッセージを前記第1のデバイスへ送信するステップを更に備える方法。
  22. 請求項19に記載の方法であって、前記取引鍵を含む第2のメッセージを生成し、前記第2のデバイスの第2の変化識別子で前記第2のメッセージを暗号化するステップを更に備える方法。
  23. 請求項22に記載の方法であって、前記第2のデバイスの第4の変化識別子を生成するステップを更に備え、前記第2のメッセージは前記第4の変化識別子を含む、方法。
  24. 請求項23に記載の方法であって、前記第2のデバイスへ前記第2のメッセージを送信するステップを更に備える方法。
  25. 請求項19に記載の方法であって、前記取引鍵の要求を生成する前記ステップは、取引鍵の要求を生成するステップを含み、前記取引鍵の要求は、要求を識別するデータを含む、方法。
  26. 請求項25に記載の方法であって、前記取引鍵を含む第1のメッセージを生成する前記ステップは、前記取引鍵と前記要求を識別するデータとを含む第1のメッセージを生成するステップを含む、方法。
  27. 変化識別子を使用して電子商取引を行う方法であって、
    第1の変化識別子で購入者取引データを暗号化するステップと、
    前記購入者取引データを認証者デバイスへ送信するステップと、
    第1の取引鍵で購入者の証明を暗号化するステップと、
    前記購入者の証明を、支払い認証者デバイスへ送信するステップと、
    第2の変化識別子でベンダ取引データを暗号化するステップと、
    前記ベンダ取引データを認証者デバイスへ送信するステップと、
    第2の取引鍵でベンダの証明を暗号化するステップと、
    前記ベンダの証明を、支払い認証者デバイスへ送信するステップと、
    前記購入者取引データを解読するステップと、
    前記ベンダ取引データを解読するステップと、
    支払い認証者デバイスに対しての支払い要求を生成するステップと、
    第3の変化識別子で前記支払い要求を暗号化するステップと、
    前記支払い要求を、前記支払い認証者デバイスへ送信するステップと、
    前記支払い要求を解読するステップと、
    前記購入者の証明を解読するステップと、
    前記ベンダの証明を解読するステップと、
    前記購入者の証明、前記ベンダの証明、および前記支払い要求に基づいて、第1の応答を生成するステップと、
    前記購入者の証明、前記ベンダの証明、および前記支払い要求に基づいて、第2の応答を生成するステップと、
    前記第1の応答を購入者デバイスへ送信するステップと、
    前記第2の応答をベンダ・デバイスへ送信するステップと
    を備える方法。
  28. 請求項27に記載の方法であって、前記ベンダ取引データを暗号化する前記ステップは、売渡証および価格を暗号化するステップを含む、方法。
  29. 請求項27に記載の方法であって、前記支払い要求を生成する前記ステップは、前記ベンダ・デバイスの識別と前記購入者デバイスの識別とを含む支払い要求を生成するステップを含む、方法。
  30. 請求項27に記載の方法であって、前記購入者の証明の有効性を検証するステップおよび前記ベンダの証明の有効性を検証するステップを更に備える方法。
  31. 請求項27に記載の方法であって、前記支払い要求を生成する前記ステップは、前記購入者デバイスに対する第1の受領証を含む支払い要求を生成するステップを含む、方法。
  32. 請求項31に記載の方法であって、前記第1の応答を生成する前記ステップは、前記第1の受領証を含む第1の応答を生成するステップを含む、方法。
  33. 請求項27に記載の方法であって、前記支払い要求を生成する前記ステップは、前記購入者デバイスの第4の変化識別子を含む支払い要求を生成するステップを含む、方法。
  34. 請求項33に記載の方法であって、前記第1の応答を生成する前記ステップは、前記第4の変化識別子を含む第1の応答を生成するステップを含む、方法。
  35. 請求項27に記載の方法であって、前記第1の応答を生成する前記ステップは、前記購入者デバイスに対しての承認メッセージおよび拒絶メッセージの少なくとも一方を含む第1の応答を生成するステップを含む、方法。
  36. 請求項27に記載の方法であって、前記購入者取引データを暗号化する前記ステップは、売渡証および価格を暗号化するステップを含む、方法。
  37. 請求項27に記載の方法であって、前記購入者取引データを暗号化する前記ステップは、前記支払い認証者デバイスの識別を暗号化するステップを含む、方法。
  38. 請求項27に記載の方法であって、前記支払い要求を生成する前記ステップは、前記ベンダ・デバイスに対しての第2の受領証を含む支払い要求を生成するステップを含む、方法。
  39. 請求項38に記載の方法であって、前記第2の応答を生成する前記ステップは、前記第2の受領証を含む第2の応答を生成するステップを含む、方法。
  40. 請求項27に記載の方法であって、前記支払い要求を生成する前記ステップは、前記ベンダ・デバイスに対しての第5の変化識別子を含む支払い要求を生成するステップを含む、方法。
  41. 請求項40に記載の方法であって、前記第2の応答を生成する前記ステップは、前記第5の変化識別子を含む第2の応答を生成するステップを含む、方法。
  42. 請求項27に記載の方法であって、前記第2の応答を生成する前記ステップは、前記ベンダ・デバイスへの承認メッセージおよび拒絶メッセージの少なくとも一方を含む第2の応答を生成するステップを含む、方法。
  43. 請求項27に記載の方法であって、前記支払い要求を生成する前記ステップは、前記支払い認証者デバイスに対しての第3の受領証を含む支払い要求を生成するステップを含む、方法。
  44. 請求項27に記載の方法であって、前記支払い要求を生成する前記ステップは、前記支払い認証者デバイスに対しての第6の変化識別子を含む支払い要求を生成するステップを含む、方法。
  45. 請求項27に記載の方法であって、前記支払い認証者が前記支払い要求を承認する場合、第1の口座から第2の口座へ資金を転送するステップを更に供える、方法。
  46. 請求項27に記載の方法であって、前記支払い認証者が前記支払い要求を承認する場合、エスクロー・サービスを提供するステップを更に備える、方法。
  47. 電子商取引システムであって、
    ベンダ・デバイスと、
    第1の変化識別子で購入者取引データを暗号化し、前記購入者取引データを認証者デバイスへ送信するように構成された購入者デバイスと、
    支払い要求を承認または拒絶し、前記購入者デバイスへの第1の応答を生成し、前記ベンダ・デバイスへの第2の応答を生成し、前記第1の応答を前記購入者デバイスへ送信し、前記第2の応答を前記ベンダ・デバイスへ送信するように構成された支払い認証者デバイスと
    を備え、
    前記認証者デバイスは、前記購入者取引データを解読し、前記支払い認証者デバイスに対しての支払い要求を生成し、前記支払い認証者デバイスの第3の変化識別子で前記支払い要求を暗号化し、前記支払い要求を前記支払い認証者デバイスへ送信するように構成される、
    システム。
  48. 請求項47に記載のシステムであって、前記ベンダ・デバイスは更に、第2の変化識別子でベンダ取引データを暗号化し、前記ベンダ取引データを前記認証者デバイスへ送信するように構成される、システム。
  49. 請求項48に記載のシステムであって、前記認証者デバイスは更に、前記ベンダ取引データを解読するように構成される、システム。
  50. 請求項47に記載のシステムであって、前記ベンダ・デバイスは更に、第2の取引鍵でベンダの証明を暗号化し、前記ベンダの証明を前記支払い認証者デバイスへ送信するように構成される、システム。
  51. 請求項50に記載のシステムであって、前記支払い認証者デバイスは更に、前記ベンダの証明を解読するように構成される、システム。
  52. 請求項50に記載のシステムであって、前記支払い認証者デバイスは更に、前記第2の取引鍵で前記第2の応答を暗号化するように構成される、システム。
  53. 請求項47に記載のシステムであって、前記認証者デバイスは更に、前記支払い要求にベンダの証明を含めるように、構成される、システム。
  54. 請求項53に記載のシステムであって、前記支払い認証者デバイスは更に、前記ベンダの証明の有効性を検証するように構成される、システム。
  55. 請求項47に記載のシステムであって、前記認証者デバイスは更に、前記ベンダ・デバイスの第5の変化識別子を前記支払い要求に含めるように、構成される、システム。
  56. 請求項55に記載のシステムであって、前記支払い認証者デバイスは更に、前記第5の変化識別子を前記ベンダ・デバイスへ送信するように構成される、システム。
  57. 請求項47に記載のシステムであって、前記支払い認証者デバイスは更に、承認メッセージおよび拒絶メッセージの少なくとも一方を前記第2の応答に含めるように、構成される、システム。
  58. 請求項47に記載のシステムであって、前記購入者デバイスは更に、第1の取引鍵で購入者の証明を暗号化し、前記購入者の証明を前記支払い認証者デバイスへ送信するように構成される、システム。
  59. 請求項58に記載のシステムであって、前記支払い認証者は更に、前記購入者の証明を解読するように構成される、システム。
  60. 請求項58に記載のシステムであって、前記支払い認証者デバイスは更に、前記第1の取引鍵で前記第1の応答を暗号化するように構成される、システム。
  61. 請求項47に記載のシステムであって、前記認証者デバイスは更に、前記支払い要求に購入者の証明を含めるように、構成される、システム。
  62. 請求項61に記載のシステムであって、前記支払い認証者デバイスは更に、前記購入者の証明の有効性を検証するように構成される、システム。
  63. 請求項47に記載のシステムであって、前記認証者デバイスは更に、前記購入者デバイスの第4の変化識別子を前記支払い要求に含めるように、構成される、システム。
  64. 請求項63に記載のシステムであって、前記支払い認証者デバイスは更に、前記第4の変化識別子を前記購入者デバイスへ送信するように構成される、システム。
  65. 請求項47に記載のシステムであって、前記支払い認証者デバイスは更に、承認メッセージおよび拒絶メッセージの少なくとも一方を前記第1の応答に含めるように、構成される、システム。
  66. 請求項47に記載のシステムであって、前記認証者デバイスは更に、前記支払い認証者デバイスへの第3の受領証を前記支払い要求に含めるように、構成される、システム。
  67. 請求項47に記載のシステムであって、前記認証者デバイスは更に、前記支払い認証者デバイスの第6の変化識別子を前記支払い要求に含めるように、構成される、システム。
  68. 請求項47に記載のシステムであって、前記支払い認証者デバイスは更に、前記支払い要求を承認すると、第1の口座と第2の口座との間で資金の転送を行うように構成される、システム。
  69. 請求項47に記載のシステムであって、前記支払い認証者デバイスは更に、前記支払い要求を承認すると、エスクロー・サービスを提供するように構成される、システム。
  70. 変化識別子を使用して電子商取引を行う方法であって、
    第1の変化識別子で取引データを暗号化するステップと、
    前記取引データを認証者デバイスへ送信するステップと、
    支払い認証者デバイスから応答を受信するステップと
    を備える方法。
  71. 変化識別子を使用して電子商取引を行う方法であって、
    取引データを含む支払い要求を認証者デバイスから入手するステップであって、前記支払い要求は第1の変化識別子で暗号化されている、ステップと、
    前記支払い要求を解読するステップと、
    前記取引データを検証するステップと、
    応答を送信するステップと
    を備える方法。
  72. 変化識別子を使用して電子商取引を行う方法であって、
    第1の変化識別子で暗号化する取引データを入手するステップと、
    前記取引データを解読するステップと、
    前記取引データの少なくとも一部を含む支払い要求を生成するステップと、
    前記支払い要求を支払い認証者デバイスへ送信するステップと
    を備える方法。
  73. 第1のデバイスと第2のデバイスとの間に通信を確立する方法であって、
    取引鍵の要求を生成するステップと、
    前記第1のデバイスの第1の変化識別子で前記取引鍵の要求を暗号化するステップと、
    暗号化された前記取引鍵の要求を認証者デバイスへ送信するステップと、
    前記第1の変化識別子で暗号化する取引鍵を含むメッセージを受信するステップと
    を備える方法。
  74. 第1のデバイスと第2のデバイスとの間に通信を確立する方法であって、
    前記第1のデバイスから取引鍵の要求を入手するステップであって、前記取引鍵の要求は第1の変化識別子において暗号化されている、ステップと、
    前記取引鍵の要求を解読するステップと、
    前記取引鍵を含む第1のメッセージを生成するステップと、
    前記第1のデバイスの前記第1の変化識別子で前記第1のメッセージを暗号化するステップと、
    前記第1のメッセージを前記第1のデバイスへ送信するステップと
    を備える方法。
  75. 電子商取引を遂行する方法であって、
    第1の購入者鍵で購入者取引データを暗号化するステップと、
    前記購入者取引データを認証者デバイスへ送信するステップと、
    第1の取引鍵で購入者の証明を暗号化するステップと、
    前記購入者の証明を支払い認証者デバイスへ送信するステップと
    を備える方法。
  76. 請求項75に記載の方法であって、
    ベンダ鍵でベンダ取引データを暗号化するステップと、
    前記ベンダ取引データを認証者デバイスへ送信するステップと、
    第2の取引鍵でベンダの証明を暗号化するステップと、
    前記ベンダの証明を、支払い認証者デバイスへ送信するステップと
    を更に備える方法。
  77. 請求項76に記載の方法であって、
    前記購入者取引データを解読するステップと、
    前記ベンダ取引データを解読するステップと、
    支払い認証者デバイスに対して支払い要求を生成するステップと、
    支払い要求鍵で前記支払い要求を暗号化するステップと、
    前記支払い要求を前記支払い認証者デバイスへ送信するステップと
    を更に備える方法。
  78. 請求項77に記載の方法であって、
    前記支払い要求を解読するステップと、
    前記購入者の証明を解読するステップと、
    前記ベンダの証明を解読するステップと、
    前記購入者の証明、前記ベンダの証明、および前記支払い要求に基づいて、第1の応答を生成するステップと、
    前記購入者の証明、前記ベンダの証明、および前記支払い要求に基づいて、第2の応答を生成するステップと、
    前記第1の応答を前記購入者デバイスへ送信するステップと、
    前記第2の応答を前記購入者デバイスへ送信するステップと
    を更に備える方法。
JP2008542420A 2005-11-23 2006-11-22 変化する識別子を使用したセキュアな電子商取引 Pending JP2009517922A (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/286,890 US7725404B2 (en) 2002-02-27 2005-11-23 Secure electronic commerce using mutating identifiers
PCT/US2006/045110 WO2007120215A2 (en) 2005-11-23 2006-11-22 Secure electronic commerce using mutating identifiers

Publications (2)

Publication Number Publication Date
JP2009517922A true JP2009517922A (ja) 2009-04-30
JP2009517922A5 JP2009517922A5 (ja) 2010-01-21

Family

ID=38609962

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008542420A Pending JP2009517922A (ja) 2005-11-23 2006-11-22 変化する識別子を使用したセキュアな電子商取引

Country Status (4)

Country Link
US (1) US7725404B2 (ja)
EP (1) EP1955280A4 (ja)
JP (1) JP2009517922A (ja)
WO (1) WO2007120215A2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014158300A (ja) * 2011-04-05 2014-08-28 Apple Inc 電子的アクセスクライアントを記憶する装置及び方法

Families Citing this family (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040177042A1 (en) * 2003-03-05 2004-09-09 Comverse Network Systems, Ltd. Digital rights management for end-user content
US7761921B2 (en) * 2003-10-31 2010-07-20 Caterpillar Inc Method and system of enabling a software option on a remote machine
US7356567B2 (en) * 2004-12-30 2008-04-08 Aol Llc, A Delaware Limited Liability Company Managing instant messaging sessions on multiple devices
US7784086B2 (en) * 2006-03-08 2010-08-24 Panasonic Corporation Method for secure packet identification
US7818264B2 (en) * 2006-06-19 2010-10-19 Visa U.S.A. Inc. Track data encryption
US20070294170A1 (en) * 2006-06-02 2007-12-20 Luc Vantalon Systems and methods for conditional access and digital rights management
US8102863B1 (en) 2006-06-27 2012-01-24 Qurio Holdings, Inc. High-speed WAN to wireless LAN gateway
US8615778B1 (en) 2006-09-28 2013-12-24 Qurio Holdings, Inc. Personalized broadcast system
US7983440B1 (en) 2006-11-02 2011-07-19 Qurio Holdings, Inc. Selection of I-frames for client-side watermarking
US7738676B1 (en) 2006-11-02 2010-06-15 Qurio Holdings, Inc. Client-side watermarking using hybrid I-frames
US7802306B1 (en) 2006-11-30 2010-09-21 Qurio Holdings, Inc. Multiple watermarks for digital rights management (DRM) and content tracking
US8000474B1 (en) 2006-12-15 2011-08-16 Quiro Holdings, Inc. Client-side protection of broadcast or multicast content for non-real-time playback
US8135947B1 (en) 2007-03-21 2012-03-13 Qurio Holdings, Inc. Interconnect device to enable compliance with rights management restrictions
US9191605B1 (en) 2007-03-26 2015-11-17 Qurio Holdings, Inc. Remote monitoring of media content that is associated with rights management restrictions
US8682797B1 (en) * 2007-04-27 2014-03-25 Hewlett-Packard Developmenet Company, L.P. Methods and systems for distributing digitally encoded information
EP2151126A4 (en) * 2007-05-11 2011-03-16 Ice L L C METHOD AND SYSTEM FOR PROCESSING BUSINESS TRANSACTIONS IN AN INTERACTIVE ENVIRONMENT
US7895442B1 (en) 2007-06-18 2011-02-22 Qurio Holdings, Inc. Interconnect device to enable compliance with rights management restrictions
US8613044B2 (en) * 2007-06-22 2013-12-17 4Dk Technologies, Inc. Delegating or transferring of access to resources between multiple devices
WO2009018512A1 (en) * 2007-08-02 2009-02-05 Imagineer Software, Inc. Systems and methods for implementing a mutating transport layer security protocol
US7933808B2 (en) 2008-01-07 2011-04-26 Garcia John Andrew Rental network security system and method
EP2316180A4 (en) 2008-08-11 2011-12-28 Assa Abloy Ab SECURE WIEGAND INTERFACE COMMUNICATIONS
US8843415B2 (en) * 2008-10-03 2014-09-23 Sap Ag Secure software service systems and methods
US8762708B2 (en) 2008-10-11 2014-06-24 David L. Blankenbeckler Secure content distribution system
EP2189932B1 (en) * 2008-11-24 2020-07-15 BlackBerry Limited Electronic payment system using mobile wireless communications device and associated methods
US10748146B2 (en) * 2009-06-16 2020-08-18 Heartland Payment Systems, Llc Tamper-resistant secure methods, systems and apparatuses for credit and debit transactions
US10284679B2 (en) * 2010-01-07 2019-05-07 Microsoft Technology Licensing, Llc Maintaining privacy during personalized content delivery
TWI422206B (zh) * 2010-05-31 2014-01-01 Intercity Business Corp 包容式金鑰認證方法
US20130104197A1 (en) 2011-10-23 2013-04-25 Gopal Nandakumar Authentication system
US8819062B2 (en) * 2012-01-03 2014-08-26 Yext, Inc. Providing enhanced business listings with structured lists to multiple search providers from a source system
GB2501229A (en) * 2012-02-17 2013-10-23 Elendra Raja A method verifying the authenticity of a data source
US10122710B2 (en) * 2012-04-19 2018-11-06 Pq Solutions Limited Binding a data transaction to a person's identity using biometrics
WO2014028510A2 (en) * 2012-08-16 2014-02-20 Kumar Himalesh Cherukuvada System and method for secure transactions
US9721244B2 (en) * 2013-03-15 2017-08-01 Maher Pedersoli Authentication system
US9369470B2 (en) * 2013-10-08 2016-06-14 Adobe Systems Incorporated User collision detection and handling
US10762156B2 (en) 2015-07-07 2020-09-01 Yext, Inc. Suppressing duplicate listings on multiple search engine web sites from a single source system triggered by a user
GB201522762D0 (en) * 2015-12-23 2016-02-03 Sdc As Data security
WO2017184160A1 (en) * 2016-04-22 2017-10-26 Entit Software Llc Authorization of use of cryptographic keys
US10728026B2 (en) * 2016-11-24 2020-07-28 Samsung Electronics Co., Ltd. Data management method
US10452877B2 (en) 2016-12-16 2019-10-22 Assa Abloy Ab Methods to combine and auto-configure wiegand and RS485
US10341304B1 (en) 2017-01-04 2019-07-02 Snap Inc. Device independent encrypted content access system
CN106952409B (zh) * 2017-04-27 2022-10-11 济南大学 一种按流量计费的售水系统及方法
US10659225B2 (en) 2017-06-30 2020-05-19 Microsoft Technology Licensing, Llc Encrypting existing live unencrypted data using age-based garbage collection
US10764045B2 (en) * 2017-06-30 2020-09-01 Microsoft Technology Licensing, Llc Encrypting object index in a distributed storage environment
US10387673B2 (en) 2017-06-30 2019-08-20 Microsoft Technology Licensing, Llc Fully managed account level blob data encryption in a distributed storage environment
CN109886812B (zh) * 2019-02-15 2021-04-20 航天恒星科技有限公司 基于区块链的数据交易系统及方法
CN111815454B (zh) * 2020-08-21 2020-12-11 支付宝(杭州)信息技术有限公司 数据上链方法及装置、电子设备、存储介质

Family Cites Families (77)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4182933A (en) * 1969-02-14 1980-01-08 The United States Of America As Represented By The Secretary Of The Army Secure communication system with remote key setting
US4661980A (en) * 1982-06-25 1987-04-28 The United States Of America As Represented By The Secretary Of The Navy Intercept resistant data transmission system
US4568914A (en) * 1983-09-26 1986-02-04 The United States Of America As Represented By The Secretary Of The Army Expanded multilevel noise code generator employing butting
US4731840A (en) * 1985-05-06 1988-03-15 The United States Of America As Represented By The United States Department Of Energy Method for encryption and transmission of digital keying data
USH1586H (en) * 1990-01-30 1996-09-03 The United States Of America As Represented By The Secretary Of The Army Methods of and systems for encoding and decoding a beam of light utilizing nonlinear organic signal processors
JPH04196848A (ja) 1990-11-28 1992-07-16 Hitachi Ltd 電子メールシステム
US5351293A (en) * 1993-02-01 1994-09-27 Wave Systems Corp. System method and apparatus for authenticating an encrypted signal
US5689641A (en) * 1993-10-01 1997-11-18 Vicor, Inc. Multimedia collaboration system arrangement for routing compressed AV signal through a participant site without decompressing the AV signal
US6611607B1 (en) * 1993-11-18 2003-08-26 Digimarc Corporation Integrating digital watermarks in multimedia content
JPH07295800A (ja) * 1994-04-22 1995-11-10 Advance Co Ltd ソフトウエアプロテクト方式
US5826241A (en) * 1994-09-16 1998-10-20 First Virtual Holdings Incorporated Computerized system for making payments and authenticating transactions over the internet
US6002772A (en) * 1995-09-29 1999-12-14 Mitsubishi Corporation Data management system
US5715314A (en) * 1994-10-24 1998-02-03 Open Market, Inc. Network sales system
JPH08263438A (ja) * 1994-11-23 1996-10-11 Xerox Corp ディジタルワークの配給及び使用制御システム並びにディジタルワークへのアクセス制御方法
US5943422A (en) * 1996-08-12 1999-08-24 Intertrust Technologies Corp. Steganographic techniques for securely delivering electronic digital rights management control information over insecure communication channels
CN101359350B (zh) * 1995-02-13 2012-10-03 英特特拉斯特技术公司 用于安全地管理在数据项上的操作的方法
US6157721A (en) * 1996-08-12 2000-12-05 Intertrust Technologies Corp. Systems and methods using cryptography to protect secure computing environments
US6658568B1 (en) * 1995-02-13 2003-12-02 Intertrust Technologies Corporation Trusted infrastructure support system, methods and techniques for secure electronic commerce transaction and rights management
US5892900A (en) * 1996-08-30 1999-04-06 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
US7124302B2 (en) * 1995-02-13 2006-10-17 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
US5717756A (en) * 1995-10-12 1998-02-10 International Business Machines Corporation System and method for providing masquerade protection in a computer network using hardware and timestamp-specific single use keys
US5671279A (en) * 1995-11-13 1997-09-23 Netscape Communications Corporation Electronic commerce using a secure courier system
US5673316A (en) * 1996-03-29 1997-09-30 International Business Machines Corporation Creation and distribution of cryptographic envelope
US6085320A (en) * 1996-05-15 2000-07-04 Rsa Security Inc. Client/server protocol for proving authenticity
US5745575A (en) * 1996-05-20 1998-04-28 The United States Of America As Represented By The Secretary Of The Army Identification-friend-or-foe (IFF) system using variable codes
US5729594A (en) * 1996-06-07 1998-03-17 Klingman; Edwin E. On-line secured financial transaction system through electronic media
US6029150A (en) * 1996-10-04 2000-02-22 Certco, Llc Payment and transactions in electronic commerce system
US5889860A (en) * 1996-11-08 1999-03-30 Sunhawk Corporation, Inc. Encryption system with transaction coded decryption key
US6192131B1 (en) * 1996-11-15 2001-02-20 Securities Industry Automation Corporation Enabling business transactions in computer networks
GB9624127D0 (en) * 1996-11-20 1997-01-08 British Telecomm Transaction system
US5915021A (en) * 1997-02-07 1999-06-22 Nokia Mobile Phones Limited Method for secure communications in a telecommunications system
US5920630A (en) * 1997-02-25 1999-07-06 United States Of America Method of public key cryptography that includes key escrow
US6178505B1 (en) * 1997-03-10 2001-01-23 Internet Dynamics, Inc. Secure delivery of information in a network
US5903721A (en) * 1997-03-13 1999-05-11 cha|Technologies Services, Inc. Method and system for secure online transaction processing
US6014688A (en) * 1997-04-25 2000-01-11 Postx Corporation E-mail program capable of transmitting, opening and presenting a container having digital content using embedded executable software
US5999285A (en) * 1997-05-23 1999-12-07 The United States Of America As Represented By The Secretary Of The Army Positive-operator-valued-measure receiver for quantum cryptography
US6125185A (en) * 1997-05-27 2000-09-26 Cybercash, Inc. System and method for encryption key generation
JP3595109B2 (ja) * 1997-05-28 2004-12-02 日本ユニシス株式会社 認証装置、端末装置、および、それら装置における認証方法、並びに、記憶媒体
US5847677A (en) * 1997-07-07 1998-12-08 The United States Of America As Represented By The Secretary Of The Army Random number generator for jittered pulse repetition interval radar systems
US6233685B1 (en) * 1997-08-29 2001-05-15 Sean William Smith Establishing and employing the provable untampered state of a device
US5991399A (en) * 1997-12-18 1999-11-23 Intel Corporation Method for securely distributing a conditional use private key to a trusted entity on a remote system
US6226750B1 (en) * 1998-01-20 2001-05-01 Proact Technologies Corp. Secure session tracking method and system for client-server environment
US6230269B1 (en) * 1998-03-04 2001-05-08 Microsoft Corporation Distributed authentication system and method
US6315195B1 (en) * 1998-04-17 2001-11-13 Diebold, Incorporated Transaction apparatus and method
US6938821B2 (en) * 2000-09-18 2005-09-06 E-Micro Corporation Method and apparatus for associating identification and personal data for multiple magnetic stripe cards or other sources
US6330670B1 (en) * 1998-10-26 2001-12-11 Microsoft Corporation Digital rights management operating system
US6382357B1 (en) * 1998-12-14 2002-05-07 Ncr Corporation Retail system for allowing a customer to perform a retail transaction and associated method
US6327578B1 (en) * 1998-12-29 2001-12-04 International Business Machines Corporation Four-party credit/debit payment protocol
US6477647B1 (en) * 1999-02-08 2002-11-05 Postx Corporation System and method for providing trade confirmations
US6801999B1 (en) * 1999-05-20 2004-10-05 Microsoft Corporation Passive and active software objects containing bore resistant watermarking
US6367010B1 (en) * 1999-07-02 2002-04-02 Postx Corporation Method for generating secure symmetric encryption and decryption
US6675153B1 (en) * 1999-07-06 2004-01-06 Zix Corporation Transaction authorization system
US7366702B2 (en) * 1999-07-30 2008-04-29 Ipass Inc. System and method for secure network purchasing
US6647417B1 (en) * 2000-02-10 2003-11-11 World Theatre, Inc. Music distribution systems
CA2287871C (en) * 1999-11-01 2007-07-31 Ibm Canada Limited-Ibm Canada Limitee Secure document management system
US6847953B2 (en) * 2000-02-04 2005-01-25 Kuo James Shaw-Han Process and method for secure online transactions with calculated risk and against fraud
US7627531B2 (en) * 2000-03-07 2009-12-01 American Express Travel Related Services Company, Inc. System for facilitating a transaction
US7778934B2 (en) * 2000-04-17 2010-08-17 Verisign, Inc. Authenticated payment
US7194759B1 (en) * 2000-09-15 2007-03-20 International Business Machines Corporation Used trusted co-servers to enhance security of web interaction
JP2002183125A (ja) * 2000-12-14 2002-06-28 Hitachi Ltd 文書情報管理方法および装置
US6957384B2 (en) * 2000-12-27 2005-10-18 Tractmanager, Llc Document management system
KR100392089B1 (ko) 2001-02-02 2003-07-22 스톰 씨엔씨 인코포레이티드 통신상에서 불법 유통되는 디지털 음악파일에 의해 음반의판매량이 감소되는 것을 방지하는 방법
US20020133468A1 (en) * 2001-03-13 2002-09-19 I - Nvite Communications Inc. Method of electronic commerce transaction verification
US7184555B2 (en) 2001-04-11 2007-02-27 Magiq Technologies, Inc. Quantum computation
US7246240B2 (en) * 2001-04-26 2007-07-17 Massachusetts Institute Of Technology Quantum digital signatures
US7113967B2 (en) * 2001-05-29 2006-09-26 Magiq Technologies, Inc Efficient quantum computing operations
US7581103B2 (en) * 2001-06-13 2009-08-25 Intertrust Technologies Corporation Software self-checking systems and methods
US7225156B2 (en) * 2001-07-11 2007-05-29 Fisher Douglas C Persistent dynamic payment service
US7111789B2 (en) * 2001-08-31 2006-09-26 Arcot Systems, Inc. Enhancements to multi-party authentication and other protocols
WO2003062960A2 (en) * 2002-01-22 2003-07-31 Digimarc Corporation Digital watermarking and fingerprinting including symchronization, layering, version control, and compressed embedding
US6996544B2 (en) * 2002-02-27 2006-02-07 Imagineer Software, Inc. Multiple party content distribution system and method with rights management features
US7376624B2 (en) * 2002-02-27 2008-05-20 Imagineer Software, Inc. Secure communication and real-time watermarking using mutating identifiers
US8543511B2 (en) * 2002-04-29 2013-09-24 Contentguard Holdings, Inc. System and method for specifying and processing legality expressions
US7336784B2 (en) * 2002-12-20 2008-02-26 Brite Smart Corporation Multimedia decoder method and system with authentication and enhanced digital rights management (DRM) where each received signal is unique and where the missing signal is cached inside the storage memory of each receiver
US20050065876A1 (en) * 2003-05-12 2005-03-24 Pulkit Kumar Airbank, pay to anyone from the mobile phone
US7273168B2 (en) * 2003-10-10 2007-09-25 Xilidev, Inc. Point-of-sale billing via hand-held devices
US7255264B2 (en) * 2004-04-24 2007-08-14 De Leon Hilary Laing Cellular phone-based automatic payment system

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014158300A (ja) * 2011-04-05 2014-08-28 Apple Inc 電子的アクセスクライアントを記憶する装置及び方法
US9332012B2 (en) 2011-04-05 2016-05-03 Apple Inc. Apparatus and methods for storing electronic access clients
US9686076B2 (en) 2011-04-05 2017-06-20 Apple Inc. Apparatus and methods for storing electronic access clients

Also Published As

Publication number Publication date
US7725404B2 (en) 2010-05-25
EP1955280A2 (en) 2008-08-13
WO2007120215A3 (en) 2008-08-28
EP1955280A4 (en) 2011-05-04
WO2007120215A2 (en) 2007-10-25
US20060173794A1 (en) 2006-08-03

Similar Documents

Publication Publication Date Title
US7725404B2 (en) Secure electronic commerce using mutating identifiers
US7376624B2 (en) Secure communication and real-time watermarking using mutating identifiers
US7706540B2 (en) Content distribution using set of session keys
US7404084B2 (en) Method and system to digitally sign and deliver content in a geographically controlled manner via a network
EP2770455B1 (en) Method and system to exercise geographic restrictions over the distribution of content via a network
US7415721B2 (en) Separate authentication processes to secure content
US9418376B2 (en) Method and system to digitally sign and deliver content in a geographically controlled manner via a network
US7536563B2 (en) Method and system to securely store and distribute content encryption keys
US7389531B2 (en) Method and system to dynamically present a payment gateway for content distributed via a network
US7237255B2 (en) Method and system to dynamically present a payment gateway for content distributed via a network
US7228427B2 (en) Method and system to securely distribute content via a network
US20060031175A1 (en) Multiple party content distribution system and method with rights management features
US20100153273A1 (en) Systems for performing transactions at a point-of-sale terminal using mutating identifiers
Waller et al. Securing the delivery of digital content over the Internet
AU2007234627B2 (en) Methods and systems to distribute content via a network utilizing distributed conditional access agents and secure agents, and to perform digital rights management (DRM)
AU2007234620B2 (en) Methods and systems to distribute content via a network utilizing distributed conditional access agents and secure agents, and to perform digital rights management (DRM)

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20091124

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20091124

A072 Dismissal of procedure [no reply to invitation to correct request for examination]

Free format text: JAPANESE INTERMEDIATE CODE: A073

Effective date: 20110328