図2aと図2bは、ビデオ監視ネットワークが稼働する場所の施設25を概念的に説明している。ビデオ監視ネットワークは、複数のデータストリーム源50を備え、この例においては、施設25内の様々な場所にビデオ監視カメラが設置されている。このような監視は、例えば監視や、一定の領域を保護することに関連する理由や、所定の区切られた場所で起こる出来事をアーカイブするため、またはその他の目的などの様々な理由で望ましい場合がある。概して監視は、セキュリティカメラや他のストリーミング信号を生成させることのできる装置などのストリーム源50に端を発する。各ストリーム源50は一つ以上のストリームをキャプチャすることができる。ビデオデータのほかに、データソース50はオーディオデータなどの他のタイプのデータを提供することができる。ストリーミングデータは、適切なフォーマットに従ってデータストリームを構成する。動画専門家集団(MPEG)はビデオ/オーディオストリームのいくつかのフォーマットを特定し、それらの多くがビデオ監視によく用いられている。生の画像データやサンプリングされた音声データはビットストリームにおいてストリームすることも可能であるが、これはさらに大きな帯域幅を必要とする。
他のタイプのデータ源は、異なるタイプのデータを提供することもできる。例えばビデオストリームは、出力の際にビデオに視覚的に重ね合わせるための追加の情報を提供する、オーバーレイストリームを伴うこともできる。このオーバーレイは、元となるビデオ(例えばそれらが機密情報を含む場合)とは、異なる許可レベルで関連付けすることができる。他のタイプのストリームは、(例えば移動する車両またはカメラの場所に対応する)GPS座標、ビデオマスキングオーバーレイ、(例えば音声をテキスト化した)字幕または他のテキストキャプションなどの位置ストリーム、モーションセンサーによってキャプチャされたモーションレベル、マイクロホンによりキャプチャされたオーディオレベル、(例えばドアが開いたことや動いたことの検出などのアクセス制御イベントのストリーム、またはビデオ解析イベントのストリームなどの)イベントストリーム、ナンバープレートリーダーによって(例えば交通カメラから)読み取られるナンバープレートなどを含むことができる。これらのいずれのタイプのデータに関しても、時間またはシーケンスにおける特定の位置と関係するフレームとして機能する、データを格納するための構造を設計することによって、ストリームを形成することができる。その結果、例えば時間の経過とともに連続的にネットワークを通じてストリームとして転送され、フレームに順番にアクセスすることができる。
このストリームは、一連のフレームを含むファイルとして格納され、例えば現在の再生時間Txに従って、連続して読み込まれてもよい。一実施例として、各ストリームの各フレームを、異なるストリームを同期させるために用いることのできる特定のタイムスタンプと関連付けてもよい。例えば、メモリから読み取られる一つ以上のストリームに対して、ストリームの同期された部分を経時的に探すため、異なるストリーム間で使用することのできる再生時間に従って、アクセスすることができる。同様に、ネットワークを通じてストリーミングされ、ネットワークインターフェースで受信されるストリームが、共通の再生時間Txに従ってバッファリングされたり再生されたりしてもよい。再生されるストリームの一つのフレームが利用できないことにより、すべてのストリームに影響を与える可能性のあるバッファリングを引き起こす可能性があり、またはそのストリームが単独でバッファされる可能性があり、バッファされる場合、他のものに追い付こうと前方にシークする。ストレージがアクセスできるところに格納されたストリームの場合、再生時間Txを変更するためにストリーム内を前方または後方にシークすることができる。多重ストリームを同期させるための他の機構を用いることもできる。
コンピュータファイル全体のようなコンテンツを参照すると、データストリームが有限である場合がある。あるいは、そのデータストリームが、ライブの監視カメラからキャプチャされたビデオのように無限であるか、または不特定の継続時間を有する可能性がある。通常、このようなストリームは、例えば一定時間(例えば30分)または一定のデータ量(パケット数またはバイト数など)に対応するファイル中に、アーカイブにおける複数のファイルとして格納することができる。概して本実施例では、データ源はキャプチャ機器に由来し、データ消費はリモートのワークステーションで発生する。しかしながら、別の実施例として、データストリームはワークステーションで一人以上のユーザーまたは購読者によって提供されてもよい。このような場合、ユーザーまたは購読者とそれらのワークステーションは、データ源の役割を果たすことができる。これらのワークステーションは、例えば安全な施設内の物理的に信頼できるチャネルを通したり、安全な暗号化されたウェブアップロードポータルを介したり、または暗号化された第三のファイル転送アプリケーションを経由したりするなど、そうするために適切なインターフェース手段を使ってデータストリームの発信元となるか、またはストリームを生成した実際の送信元から受信し、ワークステーションに提供した可能性がある。
一つ以上のストリームがネットワークを通すなどの、任意の適切な手段によって実施例にアップロードまたは転送されてもよい。このストリームやこのストリームの一部は、単一の受信者またはユーザー/購読者を対象としたり、特定のユーザー/購読者のセットを対象としたりすることができる。別の実施例として、ユーザーが(1)ストリーム、(2)そのストリームの任意の部分または(3)ストリームについての情報、およびそのような(時間制限などの)アクセスを管理している追加的な条件または制限にアクセスすることができるといったような詳細について管理するため、許可マネジメントの機構をユーザー/購読者のインターフェース内に実装することができる。一実施例として、各ストリームまたはその任意の部分に対するユーザーのアクセス/許可リストは、ユーザー/購読者インターフェース内で、それぞれのストリームおよびその中のストリームの任意の組み合わせを特定されてもよい。他の実施例として、ユーザー/購読者は、概して所有者の権限を有する最初のアップローダーまたは団体によって、ストリームを特定のストリームを通じて中央システムまたは他のユーザーが許可した権限を有する者に転送することができる。同様に、アクセス/許可などを修正することができ、それに応じてフィードの暗号化ポリシーおよびその後の各ストリームのフィードのアクセスのしやすさに影響を与える可能性がある。これについては後でさらに論じる。
データストリームの送信中のセキュリティは、インテグリティへの不正アクセスや、ストリーミングのアップロードまたは転送のプロセス途中でのストリームへのアクセスを避けるために重要であり、これについてはさらに後述する。データ源50は、様々な実施例について論じるように、ビデオ/データのストリームの生成についての、ひとつの基礎としての役割を有する。ビデオ/データのストリームの生成は、任意のストリーム源50から生まれるデータストリームを参照することができる。また、その生成は同様に、任意の特定のビデオまたはその他の編集工程、後工程、強化またはその他の操作に続くストリームの結果を包含してもよい。
図3は特定の実施例による、ビデオ監視システム10を説明するブロック図である。信頼できるネットワーク領域20は、暗号化コンピュータシステム30を備える。この暗号化コンピュータシステム30は、例えばビデオ監視サーバーなどのサーバーに含むことができる。この特定の例では、信頼できるネットワーク領域20は、不正アクセスを妨げるように制御される、信頼できる接続またはアクセスを通じて通信する、ルーターやコンピュータデバイスなどの相互接続されたネットワーク構成要素を備える。信頼できるネットワーク領域におけるネットワーク構成要素は、信頼できる構成要素とすることができ、ここから得られるデータは本物でありかつ悪意の無いデータとして信頼することができる。信頼できるネットワーク領域。具体的には、この例における信頼できるネットワーク領域20は、顧客の施設40にあるローカルエリアネットワークの一部であり、これは信頼できるネットワーク領域を信頼できないネットワーク領域75またはネットワークエリア75から分離する非武装地帯(DMZ)35によって保護されており、この実施例ではラージ45でのインターネットである。概して言えば、信頼できるネットワーク領域は、データハッキングなどの悪意あるアクティビティの源でないと信頼することのできる機器を備えることができ、それらの間の接続は安全であるとして信頼することができる。信頼できる機器は、制御される場所や、(例えばコンピュータの場合)そこで稼働しているソフトウェアを通じた制御や、(例えばIPカメラの場合)既知の起源または構成を有すること等を理由として信頼することができる。また、信頼できる接続は、制御エリア(例えば顧客の施設40)において物理的に統合されたり、暗号化によって安全にされたり、トンネリング(例えばVPN)などを理由として、信頼することができる。
この特定の場合において、ここではカメラ60であるストリーミングデータ源もまた、信頼できるネットワーク領域20に配置されており、暗号化コンピュータシステム30と通信できるように接続されている。暗号化コンピュータシステム30とカメラ60との間に直接接続が示されているが、この接続は実際にはパケット交換方式のネットワークを経由するネットワーク(例えばLANやWAN)とすることができる。
この特定の例において、暗号化コンピュータシステム30は、セキュリティサーバーとして動作し、セキュリティサービスソフトウェアを実施するコンピュータステーションを備える。これは、様々なデータ源50からストリーミングデータへアクセスするためのユーザー許可だけでなく、様々なデータ源50からデータストリームを管理している。
様々なデータ源50に由来するストリームデータは、鍵暗号化システムを使って暗号化される。より具体的には、ストリームデータは、一定期間にわたって連続的に提供される、複数の異なる暗号化鍵を含む鍵ストリームを使って暗号化される。この実施例では、ストリームデータは、対称な暗号化鍵のストリームである対称暗号化鍵ストリームを使用して対称的に暗号化される。この鍵ストリームは、例えば無作為に生成される新しい鍵の、非循環の鍵ストリームとすることができる。データストリームは、データストリームの部分に分割することができ、この部分は予め設定したり、または任意ではあるが有限の長さに(例えば、ビデオストリームのためのビデオフレームの数)したりすることができる。各部分は個別の無作為の対称鍵によって暗号化されてもよい。データストリームを暗号化する対象鍵のシーケンスが、鍵ストリームを構成してもよい。
そのように暗号化されたストリームデータは、暗号化コンピュータシステム30に格納されてもよいが、この特定の実施例では、そのストリームデータが暗号化された後に、インターネット45を通じて送信されて、ビデオアーカイブサーバー70に格納される。このビデオアーカイブサーバーは、任意の適切なデータサーバー/ストレージであってもよく、信頼できても信頼できなくてもよい。このビデオアーカイブサーバー70はここでは単一の個別の機器として示しているが、これは単にこの実施例のビデオアーカイブサーバーとしての説明を簡単にするためであり、これは実際には未知の場所で、リダンダントコピーとともにサーバーのネットワークを通じて格納データを分配することのできる、購入されたクラウドサーバーサービスを使って実装される。この実施例のビデオアーカイブサーバー70は、制御の範囲内にないため、信頼することができないと考えられる。それは実際には顧客の施設の外側にあり、出所不明のソフトウェアを実行し、データセキュリティと完全性測定とを顧客の制御の範囲外に有し、顧客が制御できない接続を通じて通信する。
本明細書でより詳細に説明するように、例えばストリームデータの安全な通信やストレージを提供したり、権限を与えられたエージェントのみにアクセスを制限したりするなど、ストリームデータへのアクセスを制御するために、鍵ストリームそれ自体が暗号化される。より具体的には、ストリームデータへのアクセスは、非対称暗号化の公開鍵―秘密鍵のペアにおいてとりわけ公開鍵と関連付けられたエンティティに限定される。当のエンティティは、ユーザーまたは特定のワークステーションのような、任意の種類のエージェントであってもよい。本実施例では、データ源50からストリームデータにアクセスすることのできる複数のエージェントワークステーション65が存在する。しかし、これらはストリームデータの異なる部分にアクセスできるようにする、異なるアクセス権限をそれぞれ有することができる。各エージェントワークステーション65は、それぞれの公開鍵ペアを有し、第三者がエージェントワークステーション65で秘密鍵を使用し、復号可能な方法でデータを暗号化させられるようにする。
この実施例では、各公開鍵は、特定のデータアクセス許可を有するエンティティ(この例ではエージェントワークステーションであるが、公開鍵は秘密鍵を通じて適切なユーザークセス制御を使用し、特定のユーザーとより具体的に関連付けられてもよい)と関連付けられる。各エンティティは、例えば特定のデータ源50から提供するストリームデータなどの、特定のストリームデータにアクセスする権限を有する。また、その各エンティティは暗号化コンピュータシステム30にそれらの公開鍵を提供することができ、その後、暗号化コンピュータシステム30は、特定のストリームデータが公開鍵で暗号化されたもので鍵ストリームを暗号化し、非対称に暗号化された鍵ストリームを生成することができる。この非対称に暗号化されたデータストリームは、ビデオアーカイブサーバー70、または暗号化コンピュータシステム30などの他の場所にも格納することもできる。
図4は本実施例におけるデータ100の機構を説明するブロック図である。この実施例では、概してデータ源50からのストリームデータに関連するデータ100と、ストリームデータが暗号化された暗号化鍵に関連するデータとが存在する。
データストリーム105は特定のデータ源50からのストリームデータを含むことができる。この特定の実施例では、データストリーム105は特定の監視カメラからのビデオデータを含む。データストリーム105は、暗号化コンピュータシステム30で鍵ストリームを使用して暗号化されてもよい。この実施例では、そのように暗号化されたデータストリームが複数存在するため、データストリーム105は暗号化される第一のデータストリームである。別の実施例として、ストリーム形式で結合された場合、データストリームが複数のデータ源50からのデータを含むことができる。同様に、単一のデータ源50は例えばビデオ(MPEG−4, HEVC等)の多重エンコーディングなどのデータの多重ストリーム、または多数のセンサーからの出力ストリームを提供することができる。
ストリームデータ105は対応する第一鍵ストリーム、特に、異なる対称暗号化鍵を含む第一対称暗号化鍵ストリーム110を使って暗号化される。この異なる対称暗号化鍵はデータストリーム105の各部分、概して連続する部分、特に時間的な連続(例えば特定の時間の連続部分からのビデオフィード)またはデータの連続(例えばデータストリームの一連の連続バイト)に対応する。この実施例では、データストリーム105は複数のシーケンシャル部分で定義することができるストリームデータを含み、その各々は、第一対称暗号化鍵ストリームの異なる暗号化鍵の異なる一つで暗号化される。概して、シーケンシャル部分はキャプチャ時間に従って配列されてもよいが、別の面では、例えば送信時間に従って配列され、キャプチャ時間とは異なる順番にするのであれば、例えばアプリケーションのパケット層や他のパケット層に従って配列するなど、データの他の論理構成に従って配列することができる。
第一データストリーム105は、第一の対称暗号化鍵ストリーム110の異なる対称暗号化鍵のそれぞれでデジタル暗号化されることにより、第一の対称暗号化鍵ストリーム110を使って暗号化され、第一の対称的に暗号化されたデータストリーム115を生成するための第一データストリーム105の各シーケンシャル部分を・・・。第一の対称暗号化されたデータストリーム115は、このように第一対称暗号化鍵ストリーム110における対称暗号化鍵のシーケンスを使って、対称的に暗号化される。第一の対称暗号化データストリーム115は暗号化データのシーケンシャル部分を含む。これらの部分は、必ずしも順番に組織されているわけではないが、この実施例では、それらは第一データストリーム105のシーケンシャル部分の暗号化バージョンを含み、各々は第一対称暗号化鍵ストリーム110からの異なる暗号化鍵で暗号化されている。
特定の一実施例として、第一対称暗号化データストリーム115は、リアルタイムトランスポートプロトコル(RTP)を使って転送される、H.264でエンコードされたビデオを含むビデオストリームである。このRTPストリームは、暗号化されていないヘッダとペイロードとを含むRTPパケットに分割される。このビデオデータの場合、とりわけH.264ビデオフレームの場合、ペイロードはストリームされるデータを含む。特にこの実施例では、ペイロードが一つ以上の、概してIフレームで始まるいくつかのH.264ビデオフレームを含み、前のRTPパケットにおけるデータから独立してデコーディングできるようにしている。好都合なことに、ユーザーに許可されたストリームへのアクセスは、一つ以上のRTPパケットに限定されてもよく、これは独立してデコードすることができる。H.264フレーム全体が暗号化されており、復号鍵を持たないエンティティがRTPペイロードのコンテンツを使用できないようにしている。
この実施例では、RTPパケットのヘッダは、コンテンツストリームに属する時間を表示するタイムスタンプを含む、いくつかのフィールドと、ペイロードタイプ(ここではペイロードがH.264ビデオであることを示す)と、データストリームを鍵ストリームに同期させるために使用する鍵インデックス(MKI)とを含む。ヘッダに格納することのできる他のデータとしては、ストリームが表すもの(例えば「カメラ1のビデオストリーム」や「1階廊下」など)を慣習に従って識別するストリーム識別子を含む。
この実施例では、音声データは映像データとは別々に暗号化され、別個のRTPストリームに送信される。これにより、音声と映像について異なる許可レベルを設定することが容易となる。例えば、場合によっては、コントロールセンター内の警備員はカンファレンスルームからの映像データを視ることはできるが、カンファレンスルームで進行中の議論を伝達する音声データを聞くための許可を有さなくてもよい。しかしながらその代わりに、RTPストリームは、そのペイロードにおける結合(例えば映像+音声)ストリームの多重ストリームまたは多重部分を結合させることができる。
第一対称暗号化データストリーム115などの他のデータストリームは、上記の方法で共存することができ、または他のプロトコルに従って送信されてもよい。
この実施例では、リアルタイムストリーミングプロトコル(RTSP)を使ってRTPストリームを管理する。
上記の通り、この特定の実施例では、H.264(または他のタイプのストリーム)が暗号化され、RTPパケットのペイロード部分に伝送される。また上記の通り、その暗号化は変化する対称鍵に従って実行される。特にこの実施例では、各RTPパケットのペイロードは、単一鍵で暗号化されたデータを含む。多重RTPパケットは特定の鍵をシェアすることができる(必要に応じて、RTPパケットと鍵との間の関係が1:1である場合がある)が、この例では、RTPパケットのコンテンツは単一鍵で暗号化されたものから、ペイロードの途中で別の鍵で暗号化されたものに転換することはない。したがって、RTPパケットのヘッダのMKI(鍵インデックス)フィールドは、鍵ストリームからの単一鍵を示すのみである。このように、この実施例では、復号鍵へのアクセスを許可することによって、ストリームの一部へのアクセスが少なくとも一部に提供されている。このため、一つ以上の鍵によって暗号化されたストリームの一部へのアクセスが許可され、この実施例ではこれらの部分は、RTPパケット全体のうちの有限のパケット数を示す。暗号化鍵を変える頻度(例えば時間やパケット数またはフレーム数などのデータ量に基づいて)(例えば30秒ごとに、または900フレームごとに)を選択することにより、特定の鍵によってアクセス可能なデータストリームの量に影響を与え、この実施例では、RTPパケット内に含まれ得る最小のデータストリーム量を生成する。
鍵の変更頻度の独立性とRTPパケット編成とを支えるため、RTPパケットと併せて、他の鍵(例えば他の鍵インデックスなど)に関する付加的な情報と、ペイロードデータにおいて一つの鍵から次に移行する点がどこであるかの表示とを提供することができる。
現在、ビデオ監視システムは多重データ源50と、多重データストリームを処理する暗号化コンピュータシステム30とを有する。データストリームは許可レベルによって体系化することができる。特定の一実施例として、ひとつの特定の許可グループ内のすべてのデータストリームを、同じ暗号化鍵ストリームを使ってそれぞれ暗号化するとともに、データストリームが許可グループに従って分類される。このことは、それらが必ず同時に暗号化されるということを意味するのではなく、むしろ、それらが同じ暗号化鍵で個別に暗号化されてもよいということを意味する(許可グループにおいて個別のストレージを許可し、異なる暗号化データストリームへのアクセスを許可する)。しかしながら本実施例では、すべてのデータストリームが異なる各々の暗号化鍵ストリームで暗号化される。
暗号化コンピュータシステム30は、エンティティとデータストリームへのアクセスとの間の関連付けを格納する、電子アクセスの許可ディレクトリにアクセスすることができる。本実施例では、電子アクセス許可ディレクトリは、図5に示すように、暗号化コンピュータシステム30のコンピュータ読み取り可能なストレージに格納された、許可ディレクトリ80の表である。この表のリンクは、システム10における各データストリームに対するエントリと、各データストリームに対するエンティティ値のリストとを含む。このエンティティ値は、各データストリームへのアクセス権を有するエンティティであることを示す。この特定の実施例では、アクセス可能な、すなわち読み取りアクセス可能な一つのタイプのみ存在する。しかしながら、別の実施例では、そのディレクトリが各データストリームに対する各エンティティのアクセスが許可されるタイプの表示を含むことができる。例えば、その表は各データストリームのエントリについて、読み取りアクセス、上書きアクセスおよび削除アクセスのそれぞれに関するエンティティ値のリストを含むことができる。
本実施例では、エンティティはそれらの公開鍵によってディレクトリに示される。したがって、エンティティを表すエンティティ値は公開鍵であり、対称暗号化鍵ストリームはその公開鍵で暗号化されて、エンティティに対応するデータストリームへのアクセスを提供する。別の実施例として、顧客のワークステーション65のユーザーIDやIPアドレスなどの他の識別子を使用することができる。このような場合、ディレクトリは各識別子について公開鍵を格納するためのエントリも同様に含み、対称暗号化鍵ストリームを暗号化するのに使用される公開鍵を、暗号化コンピュータシステム30が発見して入手できるようにする。
本実施例では、公開鍵が、対応するデータストリームの全部または一部にアクセスする許可と紐付けられている場合、暗号化コンピュータシステム30は、特定の公開鍵で鍵ストリームを暗号化するのみである。例えば、暗号化コンピュータシステム30が第一データストリーム105を受信するとき、暗号化コンピュータシステム30は許可ディレクトリ80を調べて、どの公開鍵またはエンティティが第一データストリームにアクセスできるよう許可されているかを判断する。この実施例では、第一データストリーム105はビデオカメラフィード1である。暗号化コンピュータシステム30のロジックは、第一データストリーム105と関連付けられた識別子を使ってビデオカメラフィード1(第一データストリーム105)を調べる。さらに、この実施例では、第一データストリーム105とともに提供され、ビデオカメラフィード1の下のディレクトリ80に格納されるMACアドレスと、3つの公開鍵が第一データストリーム105へのアクセスと関連付けられた、ディレクトリ80内の識別子、すなわちPub_Key_135、Pub_Key_057およびPub_Key_169とを使ってビデオカメラフィード1(第一データストリーム105)を調べる。それに応じて、暗号化コンピュータシステム30のロジックは、これらの3つの公開鍵のそれぞれを使用して第一対称暗号化鍵ストリーム110を暗号化する。
別の実施例では、許可ディレクトリは、例えば許可が与えられる期間などの追加のフィールドを含む、より複雑なデータベースとなる場合がある。この期間はキャプチャ時間に対応してもよく、このキャプチャ時間は、暗号化データストリームのヘッダ内のエントリとして保存されたデータストリームのパケットヘッダ内のタイムスタンプなどによって示されるようなものである。したがって、特定のエンティティまたはエージェントが就業時間後にプライベートオフィスからカメラフィードにアクセスすることは許可されてもよいが、就業時間中は許可されなくてもよい。他のデータ源50から得られる他のイベントに基づく状況を示す変数などのストリーミングデータへのアクセスを制御するため、データアクセスについて制限の他の表示が暗号化コンピュータシステム30によってディレクトリ内に格納されて読み出されてもよい。例えば、データ源50の場所が、従業員が就労施設を出入りする際に従業員によって使用される電子カードリーダーであるとき、特定のエンティティによるオフィスのカメラフィードへのアクセスが、オフィスの占有者による退出を電子カードリーダーが登録してから、電子カードリーダーが入場を登録した時までの時間の間の時間に限定されてもよい。このように、暗号化コンピュータシステム30は、例えばデータ源50からストリーミングデータなどのデータを表示するためのロジックを含むことができる。また、暗号化コンピュータシステム30は、その表示データに基づいて、データ源50から特定のデータストリームと関連付けられた特定の鍵ストリームを選択的に暗号化するためのロジックを含むことができる。その代わりに、またはその上、暗号化コンピュータシステムは表示データに基づいて鍵ストリームを選択的に送信することもできる。
手近な例に戻ると、第一対称暗号化鍵ストリーム110と、すべての他の対称暗号化鍵ストリームとは、対応するデータストリームにアクセスするための許可と関連付けられた非対称暗号化鍵で非対称的に暗号化される。このように、第一公開鍵120(本実施例ではPub_Key_135)で生成される非対称的に暗号化された第一鍵ストリームが生成される。第一データストリーム105へのアクセスと関連付けられるすべての他の公開鍵に関して、対応する非対称的に暗号化された第一鍵ストリームが存在する。他の鍵ストリーム(本実施例では個々のデータストリームと関連付けられるが、その代わりに全体の許可グループと関連付けられる場合もある)に関して、対応するデータへのアクセスと関連付けられる公開鍵ごとに一つの、非対称暗号化鍵ストリームの別のセットが生成されてもよい。
この特定の例によれば、第一対称暗号化鍵ストリーム110はユーザーの公開鍵を使用して、または、より一般的には非対称暗号化アルゴリズムに従って、エンティティの公開鍵を使用して暗号化される。さて、この実施例では、特定の公開鍵120を使って非対称的に暗号化された第一鍵ストリームは、非暗号化部分と暗号化部分とを含むパケット(ここでは便宜のため「鍵パケット」と呼ぶ)を生成することによって作られる。その非暗号化部分は、この暗号化された鍵ストリームと関連付けられたエンティティを識別するサムプリントを含む。例えばそのサムプリントは、エンティティの公開証明書/公開鍵を含むことができる。これは、データストリームに対し、リクエスタに対応する暗号化された鍵ストリームに対応する暗号化鍵ストリームを識別し、それと同じものをリクエスタに送るための要求を受信した場合に使用することができる。
さて、この実施例では、暗号化された鍵ストリームの各鍵パケットは、単一の暗号化された暗号化鍵を含む。この実施例では、第一対称暗号化鍵ストリーム110からの対称鍵と、特定の公開鍵120を使用して非対称的に暗号化された第一鍵ストリームのパケット(鍵パケット)とが1:1の関係にある。別の実施例として、暗号化された鍵ストリームは別々に編成されてもよい。ここで、しかしながら、暗号化された鍵ストリームにおける鍵パケットの非暗号化部分はまた、パケット内に含まれる暗号化鍵(この場合、パケットの暗号化鍵)の使用可能期間を示す存続期間データを含む存続期間フィールドを含む。上記したように、対称暗号化鍵は特定の頻度で変更され、絶えず変化する対称鍵でデータストリームを暗号化する(したがって鍵ストリーム)。存続期間データは、対応する(対称)暗号化鍵で暗号化されたデータストリームの部分の継続(例えば時間またはフレームの数またはその他)表示を提供する。
鍵パケットの暗号化された部分は暗号化鍵を含み、この実施例においては単一の暗号化鍵を含む。しかしながら、他の情報が鍵ストリームの対称暗号化鍵とともに暗号化されてもよい。この特定の実施例において、暗号化された部分はまた、暗号化されたデータストリームをどのように処理するかということについての情報を含むことができる。例えば、暗号化されたデータのタイプの表示する情報、およびそれをどのように処理するかという情報、またはデータストリームを暗号化するために用いられた暗号化プロトコルの表示の情報を含むことができる。ここで、暗号化された部分は、暗号化されたデータストリームを送信するために用いられるプロトコルがどういったものであるかを示すプロトコルの情報、そして必要に応じてプロトコルパラメータを含む。この実施例では、SRTPプロトコルが用いられる。
この特定の実施例において、鍵パケットは対応する暗号化データストリームに提供される鍵インデックスに対応する鍵インデックス(MKI)を同様に含む。これはパケットの暗号化されていない部分にあってもよい。MKIは受信デバイスによって使用され、暗号化されたデータストリームの対応する部分(この場合、RTPパケット)に復号鍵を同期させ、各部分が正しい復号鍵を使って復号されることを保証する。実際に、タイムスタンプは両方のストリームからのパケットとともに提供されてもよく、それは同期のために使用されてもよい。しかしながら、場合によっては、間違った鍵を用いてデータストリームの一部を復号したとき、結果として生じる文字化けがデータを処理するデコーダ(例えばMPEGデコーダ)をクラッシュさせる可能性がある。したがって、適切な同期を確保するため、受信者によってMKIインデックスがクロスチェックされ、暗号化されたデータストリームの任意の部分を復号するための適切な鍵が使用されることを確保する。特に、受信者は、変化する(例えば時間で変化する)対称暗号化鍵ストリームに基づいて、対称暗号化で暗号化された暗号化データストリームを受信する。この暗号化鍵ストリームは、復号鍵ストリームからの復号鍵とそれぞれ関連付けられた(この場合、復号鍵は暗号化鍵と同じである)、暗号化データストリームの個々の部分を含み、そして復号鍵ストリームにおいて対応する復号鍵と関連付けられた鍵インデックスを含む。受信デバイスは、各復号鍵と関連付けられた部分を含む復号鍵ストリームを含んだ、暗号化鍵ストリームを受信する。復号鍵はこの実施例において、ストリーム内の復号鍵とともに提供される鍵インデックスを有することによって、各鍵インデックスと関連付けられる。受信デバイスは、暗号化データストリームの各部分について鍵インデックスを分離し、鍵インデックスと関連付けられた復号鍵を識別する。この場合、これは鍵ストリームから鍵インデックスを分離し、関連付けられた鍵を入手し、秘密の非対称復号鍵を使って関連付けられた鍵を復号することによってなされ、ようやくそのデバイスが鍵インデックスと関連付けられた、復号された対称復号鍵を使って、同じ鍵インデックスに関連付けられた暗号化データストリームの一部または各部分を復号する。
鍵ストリームの暗号化について、一つの特定の鍵ストリーム(第一対称暗号化鍵ストリーム110)に関して、そして一つの特定の非対称暗号化鍵について説明してきた。しかしながら、前述したことを他の非対称暗号化鍵の鍵ストリームの暗号化に適用し、対応するデータストリームへのアクセスを他のエンティティに提供することができることは当然理解できるはずである。同様に、上記内容を他のデータストリームに対応するほかの対称鍵ストリームに適用することができる。
対称鍵ストリームは、一つ以上の非対称公開鍵で暗号化した後で廃棄されてもよい。これにより、その後、アクセス権限を有するエンティティのみがストリームを復号および別の公開鍵を使って再暗号化し、別のエンティティにそのデータストリームへのアクセスを提供することができる。これは遠隔サーバー(例えばエンティティに対して暗号化されたデータストリームや暗号化された鍵ストリームのストリーミングすることを制御するサーバーなど)へのリクエストと組み合わせることが可能で、他のエンティティに権限を提供し、そのエンティティがリクエストに応じて対応するデータストリームや鍵ストリームを受信することができる。
この特定の実施例において、データストリームは暗号化コンピュータシステム30によって受信された後すぐに暗号化され(代わりに、それらはデータ源50での作成時に暗号化されてもよい)、暗号化されていないデータは複製されない。鍵ストリームは安全な場所に保管され、この例においては暗号化される場合を除いて、決して送信されることのないように外部から隔離される。このように、別のエンティティの公開鍵によって暗号化された第一対称暗号化鍵ストリーム110のひとつのバージョンが存在しないことにより、他のエンティティが鍵ストリームを入手したり、第一非対称暗号化データストリーム115を復号したりすることができないようにする。たとえそのような第三者が(許可なしに)(データストリーム105の唯一格納されたバージョンである)第一対称暗号化データストリーム115を入手した場合であっても、そして、たとえそのような第三者が任意の合法的な公開鍵で暗号化された非対称的に暗号化された第一鍵ストリームを入手した場合であっても、そのような第三者は、中のデータを開錠してそれを復号することができないため、データについて何もすることができない。また、その当事者の公開鍵では決して暗号化されていないため、第一鍵ストリームを復号することはできず、その結果、データストリームの復号に必要な鍵ストリームを入手することはできない。
したがって、システム10は、ビデオアーカイブサーバー70のセキュリティにあまり頼らないようにすることのできる固有の内蔵安全装置から恩恵を受ける。結果として、別の十分には信頼できないストレージのためのシステムと、ストリームデータへの分散型アクセスとを使用することができる。
なお、対称暗号化は概して非対称暗号化よりもかなり計算集約的に劣っている。暗号化は、それがシステムにかける負荷が原因で、ストリーミングアプリケーションに使用されることはあまりない。実際、非対称暗号化はそのサイズを著しく増大させ、それゆえ暗号化/復号の操作にかかる重い計算負荷をかけている間のストリームに必要な帯域幅を大きくする。このように、高いデータ容量を有し、効率的な復号とデコーディングとを必要とするストリーミングアプリケーションに関して、そのような暗号化スキームを広く採用するには負荷がかかりすぎることを示してきた。反対に、対称暗号化はより「軽い」解決策であり、計算負荷が小さく、より小さな要素によってサイズ/帯域幅を大きくすることができる。しかしながら、対称化鍵の符号化のみでは、鍵の伝達が必要であるため、安全性が低い。鍵の傍受により、単一の対称鍵で暗号化されたストリーム全体が不正アクセスされるであろう。このため、データストリームが一連の対称鍵ストリームで暗号化され、鍵ストリームが特定のエンティティのために非対称的に暗号化される本システム10は、純粋な非対称暗号化よりもはるかに負担が少ないにも関わらず、とりわけ堅固なシステムである。
有利なことに、データストリームが鍵ストリームで対称的に暗号化され、その鍵ストリームが、対象とするデータストリームの受信者の公開鍵で非対称的に暗号化される、この暗号化スキームは、対称鍵を安全に交換するための端点間の安全なトンネルの確立に依存しない。なお、データストリームが非対称的に暗号化される場合、使用される公開暗号化鍵のそれぞれについて、各データストリームの暗号化バージョンが異なる必要があることに留意されたい。反対に、システム10においては、ストリームデータの単一コピーのみが必要であり、これは信頼できないサーバーに安全に格納できるように対称的に暗号化されており、信頼できないネットワークを通じて送信可能である。
概して、本明細書で教示した技術によれば、鍵ストリームは、エンコードするために使用されるデータストリームよりもはるかに小さい。第一データストリーム105と比べて、第一対称暗号化鍵ストリーム110ははるかに小さい。非対称暗号化の後でさえも、非対称的に暗号化された第一鍵ストリームはまだ比較的軽いファイルである。それゆえ、比較的低い負荷で格納および通信することができる。特定の一実施例として、ビデオストリームは1Mbpsの帯域幅を使用する。この実施例において、AES128の暗号化を使って急速に変化する鍵でそのストリームを暗号化し、これは128bpsの鍵ストリームを提供する。その鍵はデータストリームよりも非対称暗号化により適している。
なお、鍵ストリーム、暗号化鍵ストリーム、データストリームおよび暗号化データストリームは、実際には、単一のファイルに格納される必要はないことに留意されたい。これらは、ストリーム全体の部分を含む複数のファイルに分解されてもよい。一実施例として、暗号化されたデータストリームはそれぞれ15分のデータを含む1セットのファイルとしてアーカイブに格納することができる(一実施例として、そのデータはビデオまたは音声データであり、それぞれのファイルが15分のビデオまたは音声を含む)。この実施例において、暗号化鍵ストリームは(必要に応じて)15分のデータストリームを保有する、対応するファイルの鍵を含むファイルに同様に格納されてもよい。別の方法として、鍵ファイルの分解とデータファイルの分解とを別にすることができる。
図6は、非限定的な実施例によるシステム10の概要を示す論理ブロック図である。図に示したように、システムは信頼できるネットワーク領域20を含む。ここに示した特定の構成において、ビデオアーカイブを使用して、暗号化されたストリームデータと非対称的に暗号化された鍵ストリームとの両方を格納することができる。この実施例ではユーザーシステム400である、典型的なエージェントステーション65は、ビデオアーカイブサーバー300を通じてストリームデータにアクセスすることができる。
図7は信頼できるネットワーク領域の拡大図を示す。この特定の実施例において、データ源50は監視カメラ210であり、信頼できるネットワーク領域20内にある。前の実施例の暗号化コンピュータシステム30は、単一のワークステーションまたはサーバーコンピュータシステムであったが、別の実施例において、それは複数の構成部分に渡って分散されてもよい。図7に示す実施例では、暗号化コンピュータシステム30は、ストリームバッファ215と、対称暗号化エンジン230と、公開鍵暗号化エンジン240と、インターフェースゲートウェイ250とによるデータ入力を含むものとして示される。また対称鍵生成ロジック220形式の対称鍵源は、暗号化コンピュータシステム30の一部でもあるが、別の実施例では外部モジュールであってもよい。
上記したように、暗号化コンピュータシステム30は、監視カメラ210に接続し、そこからストリーミングデータを受信するための入力を含む。また上述したことであるが、データ源50との接続がネットワーク接続であってもよい。この目標を達成するため、その入力は、インターフェースゲートウェイ250と分離することができるネットワークインターフェースを採用することができ、この実施例では、それを用いて信頼できないネットワーク45とインターフェース接続することができる。その代わりに、入力はデータ源50への直接接続であってもよい。この実施例ではデータ源はパケットベースのプロトコルを通じてストリームを提供し、入力ストリームバッファ215は着信パケットを蓄積し、それらを適切に順序付ける。この特定の実施例では、入力ストリームバッファ215を使ってネットワーク層パケットをアンラップ(unwrap)して、アプリケーション層パケットを得ることもできる。
対称鍵ジェネレータ220は、対称暗号化鍵ストリームを構成する対称暗号化鍵(S1,S2,S3,...)を生成するためのロジックを含む。場合によっては、対称鍵ジェネレータは、例えば、暗号化コンピュータシステム30との、またはストリームデータの暗号化を(例えばデータ源50で)実行する別のシステム部分との、信頼できる通信関係にある外部のサービスよって対外的に提供される。しかしながら本実施例では、対称鍵ジェネレータ220は暗号化コンピュータシステムにあり、例えば有形のコンピュータ読み取り可能なストレージに格納されたソフトウェアコードを含み、鍵生成アルゴリズムに従って汎用(すなわちプログラム可能な)処理エンティティに対して対称暗号化鍵(S1,S2,S3,...)を生成するよう指示を与える指示を含む。この実施例ではMicrosoft(登録商標)CryptoAPIが使用される。
暗号化エンジン230は、対称鍵ジェネレータ220によって提供される対称暗号化鍵を使用する監視カメラ210によって提供されるストリームデータに対して、暗号化アルゴリズムを適用するためのロジックを含む。本実施例では、暗号化エンジン230は、暗号化コンピュータシステムにあり、例えば有形のコンピュータ読み取り可能なストレージに格納されたソフトウェアコードを含み、汎用処理エンティティに対して暗号化を実行するように指示を与える指示を含む。その目的を達成するため、監視カメラ210からのストリームデータはシーケンシャル部分(Va,Vb,Vc,...)に分けられる(この実施例では、これは暗号化エンジン230によってなされる)。シーケンシャル部分の各々は、それぞれの暗号化鍵によって暗号化される。この実施例では、ストリームデータはH.264でエンコードされたビデオストリームであり、Iフレームで始まる多数のフレームを構成するように各シーケンシャル部分(Va,Vb,Vc,...)が選択される。この特定の実施例では、各シーケンシャル部分(Va,Vb,Vc,...)は、暗号化エンジン230によってペイロード部分に細分されて、一旦暗号化されると、RTPパケットの個々のペイロードを作り出す。このペイロード部分は、(例えば時間やフレームの数に関する)サイズファクターによって細分されてもよい。一実施例として、暗号化エンジン230はフレーム数およびIフレームの存在に基づいてサイズを選択する。ここで具体的には、暗号化エンジン230は最小のフレーム数をカウントし、その後、次のペイロード部分となる次のIフレームを選択し、選択された次のIフレームの前にすべてのフレームをペイロード部分に配置し、これを特定のシーケンシャル部分(Va,Vb,Vc,...)がすべて使い尽くされるまで繰り返す。
暗号化エンジン230は対称鍵ジェネレータ220から対称暗号化鍵のストリームを受信する。暗号化エンジン230は各シーケンシャル部分(Va,Vb,Vc,...)のそれぞれの対称鍵で暗号化し、対称的に暗号化されたデータストリームを生成する。実際のところ、この特定の実施では、鍵(S1,S2,S3,...)を要求するようにセグメント化された特定のシーケンシャル部分ごとに、暗号化エンジン230が対称鍵ジェネレータ220を必要とする。それは、それが特定のシーケンシャル部分を暗号化することで、引き換えに対称鍵ジェネレータ220から受信する。この呼び出し(calling)はソフトウェアによって行われてもよく、例えば別の対称鍵ジェネレータクラスの機能を呼び出すことによって行われたり、また例えば、CryptoAPIへのリクエストを生成することによって行われてもよい。
本実施例では、暗号化エンジン230がデータストリーム216のそれぞれ個別のシーケンシャル部分(Va,Vb,Vc,...)をそれぞれの暗号化鍵(S1,S2,S3,...)で暗号化し、暗号化されたデータ(S1(Va),S2(Vb),S3(Vc),...)のシーケンシャル部分から構成される対称的に暗号化されたデータストリーム232を生成する。本実施例では、暗号化エンジン230は、暗号化されていないデータストリーム216の複製を保持せずに、鍵ストリームに基づいた暗号化を、リアルタイムにデータストリーム216に適用する。
とりわけこの実施例では、暗号化エンジン230は、RTPパケットに配置するチャンク中の各シーケンシャル部分を暗号化する。具体的には、暗号化エンジンが個別のペイロード部分を処理する。必要に応じて、それは暗号化データストリームにおいて暗号化されるメタデータなどの他の情報をペイロード部分に加えることができる。暗号化エンジン230は、この実施例では、AES128暗号化を使ってペイロード部分の対称暗号化を適用する。そして暗号化エンジン230はパケット、この場合、タイムスタンプをヘッダに配置するRTPパケットを生成し(これはストリームデータとともに受信することができ、またはストリームデータから得られる、または暗号化エンジン230で生成される)、同様に、含まれるペイロードタイプと鍵インデックスとを示すペイロードタイプの情報を生成し、それは鍵ジェネレータ220から受信してもよいし、またはそれ自体を生成してもよい。
この実施例では、公開鍵120を使用して非対称的に暗号化された第一鍵ストリームのような非対称暗号化鍵ストリームのそれぞれが、一つの鍵ストリームのみを構成したが、例えばすべての鍵ストリームなどの多重鍵ストリームが、ひとつの特定のエンティティの(またはグループの)許可レベルまたはそのサブセットと関連付けられることは当然理解できることである。とりわけ暗号化された鍵ストリームは、特定のエンティティがアクセス許可を有する、同時に存在するデータストリームについて、すべての鍵ストリームを含むように、例えばエンティティの公開鍵でそれらを一緒に暗号化することによって生成されてもよい。
公開鍵暗号化エンジン240は、データストリーム216へのアクセス権限を有するエンティティの公開鍵に対してアクセスすることができる(図示せず)。これらは任意の適切な通信システムを介してエージェントステーション65によって直接的に提供されてもよい。なお、公開鍵は概してデータ暗号化にのみ使用することができ、復号には使用できないため、安全に移動される必要はないことに留意されたい。公開鍵暗号化エンジン240もまた対称鍵ストリーム222を受信するが、それで何かを暗号化することを目的とするのではなく、むしろ対称鍵ストリーム222それ自体を暗号化するためである。この目的を達成するため、公開鍵暗号化エンジン240は暗号化アルゴリズムを対称暗号化鍵ストリーム222に適用するためのロジックを含む。この対称暗号化鍵ストリーム222は、対称鍵ジェネレータ220によって公開非対称暗号化鍵のそれぞれに提供され、公開非対称暗号化鍵を使用する対称暗号化鍵で暗号化されたデータストリームにアクセスするための許可と紐付けられる。本実施例では、公開鍵暗号化エンジン240は、暗号化コンピュータシステムにあり、例えば有形のコンピュータ読み取り可能なストレージなどに格納されるソフトウェアコードを含み、暗号化を実施するように汎用の処理エンティティに指示を与える指示を含む。本実施例で用いられる暗号化アルゴリズムは、非対称のRSA暗号化である。このアルゴリズムは対称暗号化鍵ストリーム222を必要とし、ストリーム222に対して公開鍵Pを使用する暗号化を適用し、非対称的に暗号化された鍵ストリーム242を生成する。この特定の実施例では、非対称的に暗号化された鍵ストリーム242が非対称的に暗号化された対称鍵(P(S1),P(S2),P(S3),...)の一つのストリームであるように、暗号化は対称鍵ずつの基準で適用される。その結果として得られる、暗号化された証明書固有の鍵ストリームは、鍵ストリームの非対称的に暗号化された選択であり(さらに本明細書で説明するように、非対称的に暗号化された鍵ストリームは特定のデータストリームに対応する対称鍵のサブセットのみを含むことができ、このサブセットは、公開鍵証明書の保有者に対してアクセスが許可されるデータストリームのサブセットに対応する)、これは意図されたユーザーに対し、対応する暗号化データストリームの選択セグメントを復号するための能力を提供する。
この鍵ストリームの生成と、データストリームの暗号化と、鍵ストリームの公開鍵の暗号化(許可に適した公開鍵の各々に対する)とは、追加のデータストリームについて繰り替えされてもよい。許可レベルをシェアするデータストリームについて、実施例に存在する場合、その生成された鍵ストリームは多重データストリームに再利用されてもよく、鍵ストリームの新たな暗号化を必要としない。
同様に、エンティティのグループ、例えばユーザーグループなどは、認証/公開鍵を共有することができ、それぞれがグループに基づく許可レベルを提供するための対応する秘密の復号鍵を有する。その代案として、この実施例における場合には、グループはグループのメンバー各自に対して暗号化鍵ストリームを生成することと、各メンバーと関連付けられたグループ関連付けを格納することとによってシンプルに管理することができる。
インターフェースゲートウェイ250は、暗号化コンピュータシステム30からのデータの通信を指示するロジックを含む。本実施例として、暗号化コンピュータシステム30は、対称的に暗号化されたデータストリーム232と、非対称的に暗号化された鍵ストリーム242とを含む。これら両方は、エージェントステーション65によってアクセス可能であるが、特にこの実施例では、対称的に暗号化されたデータストリーム232と、非対称的に暗号化された鍵ストリーム242とは、ビデオアーカイブサーバー70に格納され、この場合、そのサーバーは信頼できないネットワーク45を通じてクラウドコンピューティングサービスとして提供される。
この目的のため、インターフェースゲートウェイ250は、信頼できないネットワーク45を通じて通信するためのネットワークインターフェースを含み、その場でのストレージのため、例えばストリーミングプロトコル、対称的に暗号化されたデータストリーム232および非対称的に暗号化された鍵ストリーム242によって、遠隔のビデオアーカイブサーバー70にログオンし、そこへ送信するためのロジックを含む。保管用にそこへ送信する。本実施例では、インターフェースゲートウェイ250は暗号化コンピュータシステム30にあり、例えば有形のコンピュータ読み取り可能なストレージに格納されたソフトウェアコードを含み、通信を実施するように汎用処理エンティティに指示を与えるための指示を含む。
インターフェースゲートウェイ250は、信頼できるネットワーク領域20を信頼できないネットワーク45から適切に遮蔽するためのセーフガードを実装することもできる。これは、ファイヤーウォールのロジック、プロキシのロジック、パケットのサニタイジングのロジック、再カプセル化のロジックおよびDMZの実装のためのロジックを含むことができる。暗号化コンピュータシステム30、より広義には信頼できるネットワーク領域20は、信頼できるネットワーク20と信頼できないネットワーク45との間のインターフェースに実装された、DMZの後ろでより具体的に保護されてもよい。
別の一実施例として、非対称的に暗号化された鍵ストリーム242は、ビデオアーカイブサーバー70を通さずに、エージェントステーション65に提供されてもよい。例えば、それは暗号化コンピュータシステム30によって直接的にエージェントステーション65に提供されてもよい。この目的を達成するため、インターフェースゲートウェイ250は、非対称的に暗号化された鍵ストリーム242に関して、エージェントステーション65からリクエストを受信するのに適している可能性がある。この目的を達成するために、エージェントステーション65は、例えばユーザー入力、特定のデータストリームまたはその部分に基づいて、リクエストを生成するためのロジックを含むことができる。このリクエストは、特定のストリームの組み合わせ、または特定のストリームの部分の組み合わせに対するものであってもよい。これらの目的を達成するため、リクエストはデータストリームを識別するデータ、ストリームの部分またはその組み合わせ、およびリクエストエンティティ(この実施例ではリクエストエンティティの公開鍵/証明書を識別するリクエスタ識別子)を含む。受信したとき、暗号化コンピュータシステムは、リクエストエンティティがリクエストされたストリームデータにアクセスできる権限を与えられているかどうかを検証する。これは従来の検証プロセスを含み、例えば許可テーブルにおいてリクエスタ識別子を検索する。しかしながら、この実施例において、暗号化コンピュータシステムは、リクエストされたストリームデータのための暗号化鍵ストリームにアクセスするためのロジックを含み、サムプリント情報を読み込んで識別子(この場合、公開鍵/証明書)を発見し、リクエスタ識別子とサムプリントで発見される識別子とを比較し、ポジティブマッチを発見すると、暗号化データストリームまたはリクエストされた部分を、暗号化鍵ストリームとともにリクエスタに送信する。一実施例として、データストリームの全部または一部が、発信元のエンティティによって保持され、そして2つの鍵のマッチングが成功したとき、ストリームデータのアクセスできない部分が発信元のネットワークから検索される。実施例によっては、リクエスタ識別子とサムプリントで発見される識別子との間にポジティブマッチが無く、リクエスタ識別子とサムプリントで発見される識別子との間でミスマッチしているときは、自動的に除外リクエストまたは除外許可に変換され、その後、同意または拒絶について審査などの仲裁権限を有するところに転送される。実施例によっては、両方のストリームを送るというよりも、暗号化コンピュータシステム30が、例えばクラウドベースのストレージから一つまたは両方を送信させることができる。この検証は一回実行されてもよいが、この実施例では、リクエストされたデータストリームまたはその部分の、すべてのシーケンシャル部分(Va,Vb,Vc,...)について実行され、その結果、アクセスがデータストリームの一部についてのみ認められている場合、その部分のみが提供される。
データストリームの暗号化はシステム10の様々な点で行われてもよい。この特定の実施例では、暗号化は信頼できるネットワーク領域内で行われる。さらに具体的には、この実施例では、暗号化コンピュータシステム30がストリームデータのデータ暗号化を実行する。この目的を達成するため、暗号化コンピュータシステム30は、データ源50からストリームデータを受信するための入力インターフェースや、信頼できるネットワーク領域20内で通信するためのLANインターフェースなどのネットワークインターフェースを含む。なお、上記実施例で説明したが、データストリームの暗号化は、サーバーまたはワークステーションに具現化される暗号化コンピュータシステム30で行われるが、暗号化コンピュータシステム30を分散させて、そのいくつかの機能が、例えばデータ源50の内部で行われてもよいということは理解できることである。例えば、図7を参照すると、入力ストリームバッファ215と暗号化エンジン230とは、監視カメラ210を含むデータ源50内に含まれてもよい。対称鍵ジェネレータ220は外部ソースであってもよいが、この別の実施例では、それはデータ源50のモジュールでもある。このようにデータ源50は対称暗号化鍵ストリームと同様に、暗号化されていないデータの複製を保存せずにリアルタイムで暗号化された暗号化データストリームを出力する。このデータ源は暗号化コンピュータシステム30の外側にあるとみなすこともできる。対称暗号化鍵ストリームは、必要に応じて暗号化コンピュータシステム30への暗号化接続を使用して、信頼できるリンクを通じて提供されてもよく、これは対称暗号化鍵ストリームを検索し(必要であればそれらを復号して)、許可するのに適したエンティティの公開鍵を使ってそれらを暗号化するように進む。
また別の例として、信頼できるネットワーク領域20内であってさえも、暗号化されていないデータが送信されることがないようにするため、この機能とインターフェースゲートウェイ250のそれすらも、各データ源50にストリームデータと鍵ストリームの両方に必要な暗号化を適用しつつ、データ源50に移動させることができる。この実施例について、集中型の制御ロジックを実装することは有益となり得る。これはユーザー/エンティティおよびそれらの各々の公開鍵の収集と分散を管理し、さらにデータ源50全体の暗号化コンピュータシステム30のすべての分散された部分間で最新の許可ディレクトリを確保するためである。
図7の実施例に戻ると、この実施例において制御ロジック(図示せず)も実装され、ユーザー/エンティティおよびそれらの公開鍵の収集を管理し、許可ディレクトリ80が最新であることを保証する。制御ロジックは、許可を追加したり解除したりするためのロジックを含むことができる。そしてこの目的を達成するため、それは有形のコンピュータ読み取り可能なストレージに格納されるコンピュータ読み取り可能な指示を含むソフトウェアモジュールであってもよい。この指示は汎用処理ユニットに対して許可ディレクトリ80をアップデートするように指示を与え、エントリを追加、修正または削除させ、さらに、許可の変更に対応して非対称的に暗号化された鍵ストリームの対応する追加、修正または削除をさせるものである。例えば、特定のデータストリームについて(例えば特定の期間)特定の公開鍵に対して新たな許可が与えられる場合、対応するエントリが許可ディレクトリ80に追加され、対称暗号化鍵ストリームがメモリ内でアクセスされる。その鍵ストリームは暗号化コンピュータシステム30でローカルに格納されてもよく、または図6の実施例のように、ビデオアーカイブサーバー70でローカルに格納されてもよい。いずれにしても、暗号化コンピュータシステムが鍵ストリームにアクセスできるようにして、それらを再暗号化して許可を修正しつつ、データセキュリティを提供するためには、暗号化コンピュータシステム30(対応する秘密鍵を有する暗号化コンピュータシステム30)に属する公開鍵を使ってそれらを暗号化して格納することができる。当の鍵ストリームが一旦引き出されると(そしてもし必要な場合、復号されると)、制御ロジックからの指示の下、暗号化コンピュータシステムは公開鍵で鍵ストリームのコピーを暗号化し、許可が与えられる。
データストリームのサブセット(または部分)のみに関して許可が与えられる場合、これは暗号化データストリームにアクセスすることによってなされてもよい。上記したように、暗号化データストリームは暗号化されていない部分を含み、それは異なる部分および対応する暗号化鍵を識別するデータを含むことができる。暗号化コンピュータシステム30はデータを識別する部分に基づいてデータストリームのサブセットを発見し、データを識別する鍵に基づいて鍵ストリームの対応する部分を発見する。例えば、上記の特定の実施例において、データストリームは、暗号化されてないヘッダ、タイムスタンプおよび鍵インデックスを含むRTPパケットを含むシーケンシャル部分(Va,Vb,Vc,...)を含む。暗号化コンピュータシステム30は、データストリームの特定の時間サブセットに関するリクエストを受信するためのロジックを含むことができ、またタイムスタンプに基づいて対応するシーケンシャル部分(Va,Vb,Vc,...)を選択することができる。暗号化コンピュータシステム30は、エンティティ識別子に基づいて対応する暗号化鍵ストリームを識別するためのロジックをさらに含むことができる。それのエンティティ識別子はその暗号化されていない部分に格納されている。この特定の場合、その暗号化されていない部分は公開鍵/証明書それ自体を含むことができる。暗号化コンピュータシステム30は、当のデータストリームの部分に対応する特定の鍵(この場合、暗号化鍵ストリームの一部である)を識別するためのロジックをさらに含むことができる。そしてその自己の秘密鍵を使って鍵を含む暗号化鍵ストリームの部分を復号し、リクエスタの公開鍵を使ってこれらの鍵を再暗号化し、本明細書に記載したように新規の暗号化鍵ストリームを生成する。したがって、新規に生成された鍵ストリームは、エレメンタリストリームを通じて許可されたデータの見える範囲を例えば一定期間のビデオストリームにのみ制限するため、最初の対称鍵のサブセットのみ保有することができる。このようにして許可の粒度が実装されてもよく、それにより異なる第三者が異なるストリームにアクセスできるだけでなく、ストリームの異なるサブセットにもアクセスすることができる。この実施例では、ストリームがそのように分割され、対称鍵の変化によって範囲が定められるサブセットに分割される結果、許可が与えられるストリームのサブセットがストリームの一部または複数の部分に対応し、それぞれが全体的に各対称鍵に対応する。本実施例では、サブセットの鍵ストリームは暗号化鍵ストリームを復号し再暗号化することによって上述の通り生成されるが、対称鍵ストリームが複数の公開鍵を使って同時に(例えば公開鍵暗号化モジュール240によって)暗号化され、最初から複数の異なるアクセス許可を生成することも考えられる。そのような場合、対称鍵ストリーム222の異なるサブセット部分に異なる公開鍵を使用し、異なるエンティティに関連するデータストリームへの粒度の細かい(granular)/区別できるアクセスを提供することができる。
暗号化コンピュータシステム30によって新規の許可が提供されると説明してきたが、一実施例として、暗号化コンピュータシステム30は公開/秘密鍵のペアを有さない。それは、本明細書で説明したように対称鍵ストリームを暗号化することは可能かもしれないが、一旦暗号化が完了すると、暗号化されていない鍵ストリームのコピーを保持することはできない。上記した許可を与える機能とロジックとは、エージェントステーション65に提供されてもよい。この実施例では、特定のデータストリームまたはその部分へのアクセスが可能なエンティティのみが、別のエンティティへのアクセスを許可することができる。この目的を達成するため、エージェントステーション65は暗号化エンジン230を含むことができる。したがって、他の階層へのアクセスを許可するために、暗号化鍵ストリームへのアクセス権限を有するエンティティから、許可が付与されることに依存するほうを選択し、暗号化されていない鍵ストリームを破棄してもよい。同様に、データストリームの危殆化(compromise)となるリスクを最小限にするため、暗号化されたデータストリームのみを保持して暗号化されていないデータストリームを破棄してもよい。
したがって、エージェントステーション65は、第三者に対して特定のデータストリームへのアクセスを許可するためのリクエストを受信することができる。このリクエストはシステム30、第三者または他の場所から来てもよい。この目的を達成するため、エージェントステーション65は第三者の公開―秘密鍵のペアに属する、第三者の公開鍵を受信することができる。この第三者の公開―秘密鍵のペアには、第三者の秘密鍵が第三者によって秘密に保持されているため、例えばエージェントステーション65などには知られない。エージェントステーション65は、リクエストを受信し、上記したような第三者の公開鍵を使用した対応する鍵ストリームの復号と、鍵ストリームの再暗号化とを含む許可を与えるためのロジックを含むことができる。さらに、エージェントステーション65は、例えばテーブルを使うかまたは上記した他の手段によって、最初に許可の検証を行うことができるため、例えば熟練のプログラマーによってそのためにプログラムされたソフトウェア命令の形式のロジックを含むことができる。その許諾は、第三者がデータストリームにアクセスする権限を有するということについての判定に基づいて行われてもよい。反対に、その第三者が権限を有さないと判定した場合、許諾は行われなくてもよい。当然ではあるが、リクエストはデータストリームの一部のみに関するものであってもよく、それに応じて対応する鍵ストリームの対応する部分のみが再暗号化されてもよい。また、検証により第三者がデータストリームのサブセット部分のみについて権限を有するということを示すことができ、この場合、許諾はデータストリームの一部に対応する鍵ストリームの一部についてのみ実施することができ、第三者は検証によって決定されるとおりにアクセスが許可される。鍵ストリーム(またはその一部)を再暗号化した後、エージェントステーション65は、第三者またはビデオ監視サーバーなどのサーバーのいずれかに対し、例えば信頼できないネットワークを通じて再暗号化鍵ストリームを送信することができる。ここでも、エージェントステーション65による許諾が行われるところで、アクセスが許可されたデータストリームのサブセットのみを再暗号化することによって上記のように粒度が実装されてもよい。その結果として生じる再暗号化された鍵ストリームは、アクセスが許可されるデータストリームのサブセット部分に対応する対称鍵を含む。
エージェントステーション65は本明細書で説明するロジックを含み、このロジックはコンピュータシステムであってもよく、熟練のプログラマーによってプログラムされうるような、汎用プロセッサに対して本明細書で説明する機能を実行するよう指示を与えるための有形の記憶媒体に格納される、コンピュータ読み取り可能な指示で具体化することができる。ひとつの限定されない実施例として、エージェントステーションは汎用コンピュータ上で実行するビデオ監視クライアントソフトウェアを含む。エージェントステーション65はデータストリームを処理して有益なことや具体的なことをするためのロジックを含むことができる。例えばエージェントステーションは、データストリームに含まれる情報を例えば図表や音声でユーザーに提供するためのソフトウェアのコードなどのロジックを含むことができる。例えばエージェントステーション65は、ビデオストリームを復号するためのビデオや音声の復号器を含むことができ(例えばMPEGに準拠した復号器)、同様に、ユーザーに対してモニターにビデオを表示するためのソフトウェアやグラフィックスハードウェアを含むことができる。同様に、エージェントステーション65は、ユーザーに対してスピーカーを通じて音声を出力させるのに必要なロジックを含むことができる。
ビデオアーカイブサーバー70は、この実施例では、非対称的に暗号化された鍵ストリームとともに、対称的に暗号化されたデータストリームを保持する。このデータは、例えばクラウドストレージを介してデータを提供することによって、エージェントステーション65でエンティティに対してアクセス可能とされ、これは、他の手段によってクラウドストレージ自体にユーザーの検証/ログインおよび許可の検証を実装させてもよい。そのような場合、特にクラウドストレージの不正アクセスに備えて、二層の暗号化方式が追加のセキュリティを提供する。暗号化コンピュータシステム30でローカルアーカイブする場合でさえも、その二層の暗号化は有利である。例えば、技術者は彼らの仕事の一部として、アーカイブに格納されたデータにアクセスすることはできる。しかしながら、極秘データのストリームは暗号化されて格納されることによって依然としてそれらから遮断することができる。したがって、強制的な許諾はきわめて堅牢である。そして、アーカイブシステムそれ自体がハッキングまたは不正アクセスされる場合、そのシステムは許可されていないアクセスに対する追加の保護を提供とする。
このように、一実施例によると、ストレージサーバーが元のデータおよび鍵ストリームを格納するにあたって信頼できない場合、我々は新規の暗号化された公開鍵固有の鍵ストリームを生成する。(例えばエージェントステーション65で)計画的に最初に権限が与えられたエンティティが、権限が与えられた別のエンティティに対して暗号化公開鍵固有の鍵ストリームを生成してもよく、これは対称鍵ストリームの全てまたはサブセットのみに対応する。この目的を達成するため、エンティティはストレージサーバー300に格納される、最初に許可されたエンティティの公開鍵を使って暗号化された対称鍵ストリームにアクセス可能であり、その秘密鍵を使って暗号化された対称鍵ストリームまたはそのサブセットを復号し、また、第二の許可されたエージェントの公開鍵を使って、暗号化された対称鍵ストリームまたはそのサブセットを再暗号化することができる。その結果として生じる再暗号化された鍵はストレージサーバー300などの中央サーバーに公開されてもよい。
ここで図8を参照すると、図6のユーザーシステム400がより詳細に示されている。図に示すように、ユーザーシステム400は暗号化コンピュータシステム30に提供される公開鍵Pkに対応する、秘密鍵P-1 j412を格納する秘密鍵源410を含む。そのユーザーシステム400は、少なくとも1つのネットワークを通じて通信するためのネットワークインターフェース(図示せず)、例えばこの実施例では、信頼できないネットワーク45を含み、対称暗号化ストリームデータと、対応する非対称暗号化鍵ストリームデータとを入手することができる。
説明のため、一実施例として、ユーザーシステム400は公開鍵Pub_Key_135を有し、第一ストリームデータ105へのアクセスを要求する。この実施例では、ビデオアーカイブサーバー70はこの両方のデータを格納する。ユーザーシステム400でのユーザーの入力に応じて、ユーザーシステム400のネットワークインターフェースは、第一ストリームデータ105に対するビデオアーカイブサーバー70へのリクエストを定式化する。データストリームは、例えばストリームのグローバル一意識別子(GUID)を使うなどの任意の適切な方法によって識別されてもよい。それに応じて、ビデオアーカイブサーバー70は、そのメモリから第一対称暗号化データストリーム115を読み出す。
特定の一実施例として、すべての鍵ストリームが暗号化されているため、コンテンツに対するリクエストについて、リクエストの検証を行わなければならないというよりは、暗号化されたコンテンツ(例えば第一対称暗号化データストリーム115)が、対応する暗号化鍵ストリーム(例えば使用されるすべての公開鍵を使って暗号化されるような、非対称的に暗号化された第一鍵ストリーム)すべてに応じて一緒に送信される。非対称的に暗号化された鍵ストリームはデータ的にはそれほど大きくないので、特にいくつかの異なるエンティティまたは許可グループが存在する場合に、これは適切な解決策である。このように、ユーザーエンティティ400はすべての暗号化された鍵ストリームを受信する。これらは、暗号化鍵ストリームの暗号化に使用された公開鍵を識別することができ、例えばヘッダフィールドにおいて、セッション鍵の復号モジュール440が各暗号化鍵ストリームについて秘密鍵412で復号可能かどうかを判定できるようにする。あるいは、セッション鍵の復号モジュール440は、受信されたすべての暗号化鍵ストリームを復号するよう単純に試み、利用可能なデータを提供するものを識別することができる。
しかしながら、その代わりに、ビデオアーカイブサーバー70はリクエスタの識別を検証するためのアクセスコントロールを実装し、そのリクエストが公開鍵に対応する場合または、例えば対応する非対称的に暗号化された鍵ストリームを有するデータストリームへのアクセス権限を有するエンティティに、そのリクエストが対応する場合にのみ、暗号化データストリームを提供する。一実施例として、データストリームについて、すなわち、より具体的には、データストリームに対する復号鍵に関するリクエストを受信するデバイス(例えばビデオアーカイブサーバー70であるが、暗号化鍵ストリームが保持される場所にある場合、その代わりに暗号化コンピュータシステム30)が、リクエスタの公開鍵/証明書とともに受信する。また、そのデバイスはストリームに対応する公開鍵/証明書を含む暗号化鍵ストリームのフィールドと、公開鍵/証明書とを比較するためのロジック(例えばソフトウェアコード、例えば汎用プロセッサに対するコンピュータ読み取り可能な指示など)を含む。これが唯一の検証であってもよいし、または、例えば許可ディレクトリ(例えば暗号化鍵ストリームを各エンティティと照合する鍵ストリームテーブルを含むディレクトリ)においてリクエスタと関連付けられた識別子(公開鍵など)を最初に調べた後に実行される冗長検証であってもよい。
別の一実施例として、暗号化コンピュータシステム30は暗号化鍵をローカルに格納する。この実施例では、ユーザーシステム400のネットワークインターフェースは、データリクエストを例えばプロキシサーバーの許可バリデータに送信することができる。この許可バリデータは、本明細書で説明する技術などを使って許可を認証し、そのリクエストの認証と同時に、承認されたアクセスのリクエストを暗号化コンピュータシステム30に送信することができる。また、そのバリデータは(暗号化されたデータストリームがビデオアーカイブサーバー70に格納される場合および、これが暗号化コンピュータシステム30と分離している場合)、承認されたアクセスのリクエストをビデオアーカイブサーバー70に送信することができる。このビデオアーカイブサーバー70は、これらのエンティティの両方に対して、データストリームを得るために必要なデータの各部分をリクエスタに送信するように指示を与える。プロキシサーバーに提供されるというよりは、許可バリデータが暗号化コンピュータシステム30の一つかまたは(もし分離していれば)ビデオアーカイブサーバー70のどちらかに提供されてもよい。またその代わりに、これらの各々が上述のようにリクエスタの許可を検証するタスクを独立して実行することができる。
図9はビデオアーカイブサーバーが暗号化コンピュータシステム30内に含まれているシステムを示す。したがって、ビデオアーカイブサーバー70のロジックは暗号化コンピュータシステム30内に含まれても良い。リクエストの検証はビデオアーカイブサーバー30で実行される。
特定の一実施例として、暗号化されたデータストリームは、暗号化と同時に、暗号化コンピュータシステム30によって、エージェントステーション65に(そして例えば他の承認された受信者にも)直接、ストリーミングされてもよい。これはサーバーが暗号化コンピュータシステム30の内側にあっても外側にあっても、ビデオアーカイブサーバー70で保存する前または保存と同時にされてもよい。暗号化データストリームおよび暗号化鍵ストリームの送信は、たとえ同じエンティティに格納される場合であっても、別々にすることができる。特定の一実施例として、暗号化データストリームは、暗号化鍵ストリームと同時にすべての受信者にマルチキャストすることができ、これは異なる受信者によって異なっていてもよく、例えばエージェントステーションなどの各クライアントと1対1の関係を通じて送信される。なお、アーカイバーは決してデータストリームや鍵ストリームを復号することはできず、(例えば暗号化されていない復号鍵にアクセスできないことによって)そのような能力を有していなくてもよいということに留意されたい。特に、対称鍵と暗号化されていないデータストリームが持続されることはないかもしれない。このような場合、上述したように、暗号化鍵ストリームを復号することができる、既に承認されたエンティティによって新たな許可の承認がなされてもよい。
セッション鍵の復号モジュールは秘密鍵を使って非対称的に暗号化された鍵ストリームを復号するためのロジックを含む。このロジックは有形のコンピュータ読み取り可能なストレージに格納される、コンピュータ読み取り可能な指示の形式であってもよい。このコンピュータ読み取り可能なストレージは、汎用な処理エンティティに対して復号を実行するよう指示を与える指示を含む。公開鍵120を使って非対称的に暗号化された第一鍵ストリームを受信すると同時に、セッション鍵の復号モジュールが(例えばRSAなどの)アルゴリズムを適用して暗号化鍵ストリームを復号し、第一対称暗号化鍵ストリーム110、Snを読み出す。
セッション鍵の復号モジュールはビデオストリーム復号モジュール450を含み、モジュール450はネットワークインターフェースによって得られる暗号化ストリームデータを復号するための、上記したコンピュータ読み取り可能な指示形式のロジックを含む。この実施例では第一対称暗号化データストリーム115が受信され、暗号化されたデータSn(Va)のシーケンシャル部分を含む。
一実施例として、暗号化されたデータSn(Va)の各シーケンシャル部分は、対応する一以上のアプリケーション層パケットに送信される。このアプリケーション層パケットは、例えば暗号化されたデータSn(Va)の特定のシーケンシャル部分についての特定の時系列の値を示すタイムスタンプなどのタイミング情報を含むことができ、また同様に鍵インデックスを含むこともできる。復号された対称暗号化鍵ストリームPk(Sn)の対称暗号化鍵Snは、例えばタイムスタンプや鍵インデックスなどの、それらの暗号化データSn(Va)の各シーケンシャル部分に対する時間参照系と関連付けられる。
鍵同期モジュール430の検索により、各アプリケーション層パケット内、本実施例では、暗号化データストリームの各RTPパケットのヘッダ内で鍵インデックスを識別する。必要に応じて、鍵同期モジュールがヘッダ内のタイムスタンプを識別することもできる。鍵同期モジュールは暗号化データストリームのそれぞれ特定の部分に対応する鍵ストリーム内で鍵を発見する。この目的を達成するため、鍵同期モジュールは鍵インデックスを検索する。この鍵インデックスは暗号化鍵ストリームの暗号化されていない部分に存在する場合もあるが、直近の実施例では鍵ストリームの暗号化された部分に存在する。セッション鍵の復号モジュール440は暗号化鍵ストリームの暗号化部分を復号するので、鍵インデックスは鍵同期モジュールによって検索可能である。必要に応じて、鍵同期モジュール430は暗号化データストリームからのタイムスタンプデータを利用し、データの対応する部分に近い(例えば特定の閾値内にある)(存在する場合は)タイムスタンプを有する鍵のみを検索することによって、復号される鍵の検索を絞ることができる。あるいは、鍵同期モジュール430はそのタイムスタンプを使って開始点を選択することができ、そしてタイムスタンプの時間からさらに進むことによって鍵ストリームを検索することができる。鍵同期モジュール430はまた、特にどの程度の長さの非対称鍵が使用されるのかということ、すなわち、暗号化データストリームのどの程度のものであるのかということを導き出すことができる。例えば、RTPパケットが(先のものに比べて)新しい鍵インデックスを指し示す場合、鍵同期モジュール430は、RTPパケットが新たな鍵インデックスを有するまで、対応する鍵をアサインすることができる。または、鍵同期モジュール430は鍵ストリーム内に格納された鍵についての存続期間情報を使用して、どの程度の期間、その鍵が使用されなければならないかを決定することができる。鍵同期モジュール430はまた両方を使うことができ、例えば暗号化されたデータストリーム内で新規の鍵インデックスが発見されるか、または存続期間が尽きるかのいずれかまで鍵を継続的にアサインすることができる。鍵インデックスの代わりに、鍵同期モジュール430は他の値を例えばタイムスタンプのみに一致させてもよい。
ユーザーシステム400はストリーム復号エンジン450、この実施例ではビデオストリーム復号エンジンをさらに含むことができるが、これは他のタイプのストリームデータを復号するためのものとすることもできる。このストリーム復号エンジン450はネットワークインターフェースから受信した暗号化ストリームデータ(この実施例では、これは第一対称暗号化データストリーム115に対してなされる)に復号アルゴリズムを適用するためのロジックを含む。本実施例では、ストリーム復号エンジン450はエージェントステーション65にあり、汎用処理エンティティに対して復号を行うように指示を与える指示を含む、例えば有形のコンピュータが読み取り可能なストレージに格納されたソフトウェアコードを含む。この目的を達成するため、この実施例ではビデオアーカイブサーバー70から受信される暗号化データSn(Vm)のシーケンシャル部分を含む、暗号化ストリームデータが受信されて、もし分割されていなければ、その暗号化データSn(Vm)のシーケンシャル部分に分割される。
概して言えば、ストリーム復号エンジン450は復号アルゴリズムを適用し、それによって暗号化ストリームデータが復号鍵ストリームを使って復号される。この特定の実施例では、ストリーム復号エンジン450は暗号化データSn(Vm)の各シーケンシャル部分について、鍵インデックス、タイムスタンプまたはその両方を抽出することによって、そしてそれを鍵同期モジュール430に提供することによって、暗号化データSn(Vm)のシーケンシャル部分を復号するための対称鍵ストリームから適切な対称鍵Snを識別する。それに応じて、鍵同期モジュールはストリーム復号モジュール450に対し、暗号化データSn(Vm)のシーケンシャル部分を復号するための適切な鍵Snを提供することができる。その後、ストリーム復号モジュール450は(例えばAES128ビットなどの)復号アルゴリズムを適用し、暗号化データのシーケンシャル部分において暗号化されたデータストリームの特定のシーケンシャル部分を読み出す。これは、例えばそれらがネットワークインターフェースから受信されるときに(それらはバッファリングのため、または後で同様に復号するためローカルに格納されてもよく、この場合、それらはローカルメモリから受信されてもよい)、暗号化データSn(Vm)の各シーケンシャル部分について連続的に繰り返される。
この特定の実施例では、ストリームデータはビデオデータである。そのように復号されたデータは次に、ストリームデコーダーモジュール460に送られる。ストリーム復号モジュール460は例えばこの実施例では、シーケンシャル部分(Va,Vb,Vc,...)の形式で現在暗号化されているストリームデータを受信する音声デコーダーやその他のものを含むことができるが、本実施例では例えばビデオデコーダー(例えばMPEG4/AVCデコーダー)であり、それらをディスプレイに表示するためにデコードすることができる。
他の実施例についてこれから説明する。別の一つのアーキテクチャとして、非対称的に暗号化された鍵ストリームデータを、信頼できないネットワーク45を通じてアクセス可能な別個の鍵サーバー300に格納することができる。図10に関して、図示した実施例におけるシステム10は(例えば、クラウドサービス内でデータアーカイブサーバー71と呼ばれるものと一緒に)一つ以上の物理データサーバーを含むことができる。このサーバーは、入ってくるデータフィード225を受信し、これらのフィードを格納するか、またはリターンフィード425を経由してユーザーまたは購読者に対し、即座にこれらのフィードを提供する能力を有する。リターンフィード425はデータサーバー71によって提供され、同時に鍵サーバー300は上記した非対称的に暗号化された鍵ストリームなどの暗号化鍵ストリーム275を安全なデータベース内に格納する。鍵サーバー300は特定のリターンフィード425を復号するための暗号化鍵275aに安全にアクセスし、さらに許可を受けられるユーザー/購読者に暗号化鍵275aを送信することができる。なお、リターンフィード425はデータアーカイブサーバー71に入るフィード225と同一であってもよく、そのフィード225は暗号化コンピュータシステム31によって送信される暗号化データストリーム225であることに留意されたい。暗号化鍵275aとリターンデータ425は、ユーザー/購読者がライブフィードをストリームしたいかどうか、あるいはデータアーカイブサーバー71内にアーカイブされたフィードを見たいかどうかを問わず、ユーザー/購読者に送信される。このように、データビデオアーカイブサーバー71は、例えばその場ですぐ再生するため、ストリームを受信して即座にストリームデータ(そして必要に応じて他の実施例では暗号化鍵ストリームデータ)をエージェントステーション65に対して再放送するための再送信技術で構成される。有利なことに、十分な帯域幅を備えるデータアーカイブサーバー71は、それゆえ、ストリームデータのアーカイブと再送信とを同時にすることができ、エージェントステーション65に対して(場合によっては鍵サーバー300と並行して)単一の接点としての機能を果たすことができる。
データアーカイブサーバー71は、暗号化された形式425で格納されるストリームデータを含む。なお当然に理解できることではあるが、暗号化されていない形式のデータをサーバーが維持する場合と比べて、そのような暗号化によって、格納されたコンテンツに対して権限のない団体がさらにアクセスできないようにすることができる。さらに、データアーカイブサーバー71の記憶媒体またはそれらが収容されている施設でさえも、破壊されたり、またはそうでなければ不正アクセスされたりした場合に、それらの暗号化されたコンテンツは攻撃者予備軍に対してアクセスできないままである。
引き続き図10を参照すると、一つ以上のデータ源50がストリームデータ101を生成し、ストリームデータ101は暗号化コンピュータシステム31に提供される。暗号化コンピュータシステム31は、この実施例では外部の鍵源350によって提供される、対称暗号化鍵でストリームデータ101を暗号化する。鍵源350は暗号化コンピュータシステム31の施設であってもよく、または信頼できる接続を通して信頼できる外部サービスによって提供されてもよい。鍵源350は暗号化コンピュータシステム31に一つ以上の対称暗号化鍵ストリーム175を提供する。暗号化コンピュータシステム31はストリームデータ101を暗号化するために対称暗号化鍵ストリーム175を使用し、同様に、ストリームデータ101へのアクセスと関連付けられた公開鍵を使ってそれらを暗号化する。その後、暗号化鍵ストリーム275が暗号化コンピュータシステム31によって鍵サーバー300に送信される。この実施例では、その鍵(鍵ストリーム)は、鍵サーバーに格納される前に、非対称暗号化を使って暗号化される。コンテンツへのアクセスが許可されたユーザーの公開鍵を使って鍵ストリームを暗号化する。別個の鍵ストリームは、データへのアクセスを許可された各ユーザーと、各データストリームとに対して生成される。
ユーザーはユーザー/購読者インターフェース500を経由してサービスに接続するのが通常である。ユーザーは(ユーザーの各暗号化鍵ストリームにアクセスを提供することに加えて)鍵サーバー300によって提供される鍵検証機能を経由してデータアーカイブサーバー71内に格納されたコンテンツにアクセスすることができ、それと同時に、データアーカイブサーバー71はリターンデータ425をストリーミングするか、またはそうでなければ移動させる。例えばユーザーの公開鍵で暗号化された鍵ストリームを有するユーザーのみが、暗号化データストリームや鍵ストリームにアクセスできることを確保するため、本明細書で説明した検証方法または既知の検証方法を使用することができる。通常は、例えばユーザー/購読者のワークステーションのローカルで、本明細書に提供した技術を使うなどして、データストリーム復号モジュール450を使ってその復号が起こる。
データストリーム101は、ビデオまたは他のマルチメディアのデータを含むことができる。なお当然理解できることであるが、他のタイプのデータフィードまたはデータストリームが、必要に応じて他の実施例において同様にデータストリーム101内に含まれてもよい。そのようなデータフィードは、開示されているか専有されているかに関わらず、ビデオ、音声、テキストまたは任意のフォーマットを使って表現されたりカプセル化されたりした任意の他のデータの任意の組み合わせを非限定的に含むことができる。加えて、ユーザー/購読者に対してストリーミングされるリターンデータ425は、データアーカイブサーバー71内にあらかじめ格納され、無事に認証されたユーザー/購読者のインターフェース500に対してオンデマンドで提供されてもよい。同様に、リターンデータ425は、そのユーザー/購読者インターフェース500にストリーミングされるすぐ前に生成されてもよい。
任意のデータ源50から実施例に導入されたデータストリーム101と、任意のあり得る安全な暗号化トランジット手段を通じて実施例に導入されたデータストリーム101とは、その後、暗号化コンピュータシステム31に移動される。暗号化コンピュータシステム31は、鍵ストリーム175を使って受信したストリーム101を暗号化する。ここで鍵ストリーム175はデータストリームの復号に使用することもできる。
さらなる一実施例として、様々な暗号化のスキームおよび範囲の中から選択するため、パラメータはユーザー/購読者インターフェース内で規定されてもよい。本願明細書の任意の実施例に関して、別段の定めがない限り、または技術的に実行不可能なものでない限りは、暗号化の仕様(例えばAES−128,AES−192,AES−256)、署名または鍵交換(例えばRSA 2048)または整合性チェック(例えばSHA−256暗号学的ハッシュ関数)について、技術上の特定の限定は想定されない。
別の一実施例として、暗号化ポリシーは、ビットストリームの仕様または暗号化するためのビデオストリームのフォーマットを考慮することによって有利に実装され得る。例えば暗号化は、暗号化されていない様々なシーケンスのヘッダ330,330’および、基本的に価値あるメタデータをあまり含まないシーケンストレーラー332をそのままにして、ストリームの様々なシーケンスペイロード331,331’に対して排他的に向けられてもよい。なお当然容易に理解できることであるが、この概念は、ビットストリームの仕様または階層の低層に対し、より大きな区別および粒度で適応および適用されてもよく、したがって、この概念が個々のシーケンスペイロード331のコンテンツに向けられてもよい。このような場合、個々のフレームのヘッダ333とトレイラー335は暗号化されないままであってもよいが、他方でフレーム334,334’自体は、一つ以上の鍵275で暗号化される。同様に、画像ヘッダ336とトレイラー338を暗号化されていない状態にしたまま、暗号化鍵275が個々のフレーム334の画像ブロック337,337’に対して排他的に割り当てられてもよい。このようなスキームのアプリケーションは、補足のヘッダデータを暗号化しないことによってではなく、上述した基本的な原理を維持しながら、すなわち送信するデータのボディまたはペイロードを暗号化することによって他のフォーマットを包含するよう適合されてもよい。補足のヘッダデータのコンテンツは上記ペイロードの任意の部分を明らかにするためにリバースエンジニアリングされない。なお、そのアプリケーションは、キャプチャされたもの50または生成されたもの101のどちらか一方のストリーム100の様々なフォーマットに適応および適用されてもよい。例えば、前述の概念をMPEGビデオ、およびこれらに限定されないが、特定のブロック、マクロブロック、Pフレームまたはシーケンス内のピクチャー群に対して適用することは、さらに検討されて実装されてもよい。同じような方法で、別個の暗号鍵275または鍵275のストリームが検討されてIフレームおよびBフレームに向けられてもよく、他方で残りのMPEGビデオシーケンスが暗号化されていない形式でビデオアーカイブサーバーに送信され、ビデオアーカイブサーバー内に格納され、ビデオアーカイブサーバーから読み出される。
概して、本明細書で説明した通り、本明細書では鍵は鍵ストリームの文脈で使用され、それによって一連の暗号鍵175において、各鍵はストリーム100の連続部分と関連付され、シーケンシャルアクセスまたはストリームの再生のために生成されてもよい。例えば、単一の鍵によって特定のビデオストリームの30秒の復号を可能にすることができる。全体として、ビデオストリームの全体を再生するためには、ストリーミング用の鍵源250によって生成された鍵ストリーム175のすべての暗号鍵が、潜在的なユーザー/購読者にとって入手可能でなければならない(すなわち、彼はアクセスするために必要な権限/許可を有するか、またはその鍵を有していなければならない)。
上記のテーマについて変形例も同様に考慮することができる。例えば図12はストリーム101を復号して完全に見るために必要な2つの鍵のうち1つのみをユーザーが有するという仮定のシナリオを示す。見ようとしているストリーム101は、ユーザーがアクセスできない鍵(例えば、彼はその鍵を有する許可を与えられていないか、または、彼はその鍵を得ることを省略した)を必要とする中間の区分で3つの暗号化区分に細分されている。ビデオ(またはテキストまたは他のデータ)ストリームの一部または全部の区分にわたって、合成された視覚的または聴覚的な通知メッセージを置換することを含むが、これに限定されない様々な処理技術が考えられる。そのようなメッセージまたは不十分なアクセス特権マーカー288は、ユーザー/購読者に対して、復号するために必要な復号鍵175の欠如により、見ようとしているストリームの特定の区分について復号が実行されないということを知らせることができる。さらなる実施例として、その欠けている鍵175についての識別情報、または制限を解除するための他の情報が、不十分なアクセス特権マーカー288に供給されてもよく、それによって許可されたユーザー/購読者がサポートしたり他の救済をしたりするために、許可された職員に接触することができる。
コンテンツが純粋にビデオ機能ではない要素を含むストリームに対して、同様の特権制限の処理プロセスが考えられる。図13aと図13bは、ファイルのコンテンツの一部を復号するために必要な鍵、すなわち鍵275を保有しないユーザーに対してアクセスが許可されていない区分を含む、リッチテキストファイルを特色とする一実施例を示す。上述の実施例と類似した方法で、適切なアクセス特権の不足したマーカー288は、復号のために追加の鍵275を要するリッチテキストファイルの区分に現れる。
特定の鍵ポリシーを使って実装および実施するためのストリーム100のアクセスポリシーは、任意の適切なユーザーまたは要員によって適切なモジュール内に指定されてもよい。限定されない一実施例として、そのような機能は、一つ以上のストリームを管理する直接的責任を有する一人以上の個人がアクセス可能なユーザー/購読者インターフェース500内に含まれてもよい。別の一実施例として、単一で、デフォルトのポリシーがすべてのストリームについて実施されてもよい。そのような鍵がユーザー/購読者に提供されることによるプロセスについては、さらに本明細書で議論する。
一旦、鍵ポリシーが確認されたり特定されたりすると、鍵源250は暗号化コンピュータシステム31が受信する鍵175を生成するか、そうでなければ供給することができ、暗号化コンピュータシステム31は鍵175でデータストリームを暗号化する。一旦、データの暗号化が(事前に決定された任意のアクセスポリシーやサポートする暗号化スキームに従って)実行されると、実施例における暗号化コンピュータシステム31は、一つ以上の暗号化鍵ストリーム275(データストリームを復号することのできる各ユーザーまたはユーザーの集団につき一つの鍵ストリーム)を、暗号化鍵ストリーム275を格納するための鍵サーバー300の中に発行し、データアーカイブサーバー71および/または、同時にユーザー/購読者インターフェース500のどちらかに向けて送信するため、対応する暗号化ビデオ225(または他の暗号化されたデータタイプ)を準備する。実施例(あるいは状況)によっては、後者のユーザー/購読者インターフェース500への同時送信が望ましい場合がある。すなわち、特定のストリームにおいてキャプチャされた、イベントのライブストリーミングであって、相当な数の同時購読の個々のユーザー/購読者インターフェース500に向けたものが、別の面では、本願明細書に開示される従来のアーキテクチャ全体に過度のパフォーマンスを加えるような場合に、望ましい可能性がある。
実施例では、暗号化コンピュータシステム31は、クラウドまたはシステムレベルのメンテナンス要員によって暗号化コンピュータシステム31を設定可能にするための機能を含むことができる。そのような機能は、これに限定されないが、暗号化データパケットを送信する宛先(例えばURL)に関する設定情報を含むことができる。宛先は概して、一つ以上のデータアーカイブサーバー71や一つ以上のユーザー/購読者インターフェース500(後者は、エージェントステーション65がデータをリクエストするための「ダイヤルイン」について責任を負う場合には必要ないかもしれないが)を含むことができる。なお当然理解できることであるが、追加的な一実施例として、一つ以上の宛先が一度に特定されてもよい。これは、例えば、後で読み出せるようにアーカイブサーバー内にストリームが格納される場合に加え、ストリームが複数の(他の)ユーザー/購読者500によってシェアされるライブである場合などに起こり得ることである。暗号化コンピュータシステム31は、既に本明細書で説明したように、ユーザー/購読者500のユーザー証明書/公開鍵の暗号化を受信し、構成し、使用するためのロジックを含むことができる。ユーザーの検証に関してだけではなく、例えば公開鍵の使用などに関しても同様である。
その構成設定を特定したり修正したりするための許可を与えることのみならず、暗号化コンピュータシステム31内に含まれる様々な構成設定の性質は、特定の実施例のニーズにふさわしいものであるとして理解されるべきである。一実施例として、構成設定は例えばデータストリームに適用される様々な利用可能な暗号化方法および基準の中から選択する可能性を含む。暗号化データフィードを送信するための、一つ以上のデフォルトのデータアーカイブサーバー71を特定するよい機会が同様に存在するかもしれない。同様に、暗号化コンピュータシステム31内で利用可能な任意の一つ以上の構成設定が、適切なポリシー制限を受けてもよく、同時に、ユーザー/購読者インターフェース500を通すときに、例えばサービスメンテナンス要員、ストリームを最初にアップロードするユーザー/購読者、およびそのストリームにアクセスする別のユーザー/購読者などの一人以上の関係者のみに特定の設定が共有されたり、あるいはアクセス可能にしたりすることができる。なお、当然に理解できることであろうが、多くの実施例では復号されたビデオストリームを(彼ら自身のそれぞれのユーザー/購読者インターフェース500を通じて)見る個人は、暗号化コンピュータシステム31に対して制御入力や、ある種の構成データを提供することはできず、そのような構成はネットワーク管理者やその他の信頼できるサービスメンテナンス要員に確保されている。このような構成設定は、アクセス可能である場合、ユーザー/購読者インターフェース500の適切な部分または専用の部分内でアクセスされ、特定され、または見られてもよい。上述の内容を考慮すると、特定の実施例についての展開のニーズと一致して、任意のあり得る変更を想定して実装することができる。
なお、当然理解できることであろうが、任意の数の可能な暗号化実施が、暗号化モジュール200によって生成される暗号化鍵について想定されてもよい。また、当然理解できることであろうが、本明細書で説明したアーキテクチャの任意の部分を、任意の現存するまたは将来の暗号やセキュリティの標準(これに限定されないが、HIPAA,HITECH,NERC CIPなどを含む)に準拠させることができ、さらに任意の一つ以上の特定のフィールドにおける使用に適合させることができる。さらなる実施例として、複数の暗号化タイプ、カテゴリおよび組み合わせは、例えばその実施例の管理者によってインターフェース500を通じて特定されてもよい。他の受信ユーザー/購読者と暗号化フィードを共有することを目的とする特定の許可について同様に、ユーザー/購読者インターフェース500内に規定されてもよく、このとき、その受信ユーザー/購読者がフィード425をダウンロード502し、フィード425の対応する鍵275と275aとをダウンロード501し、ローカルで復号するために復号モジュールをエンゲージさせて、適切な宛先ディスプレイデバイス600でそれらを開いて/表示する601ときまでは、フィードを暗号化されたままの状態にしておくことができる。
特に大規模な実施例では、多数のデータストリーム225と(対応する)鍵ストリーム175とが存在するのが通常であり、ユーザー/購読者に提供され得る、暗号化鍵ストリーム175および対応する暗号化データストリーム225の両方の頑強なアクセス管理を実装するために必要なリソースを、鍵サーバー300に装備することができる。ユーザーの認証機能は概して、任意の数の適切なユーザー/購読者の認証情報を受信する、ユーザー/購読者インターフェース500内に実装される。さらに、そのような機能は概して、企業情報を保護するための強力な認証を供給することを視野に入れて、当業者によく知られている技術や最良の実施例を使う実施例において実装される。ユーザー/購読者インターフェース500に対する認証プロセスは、実施例では、有利かつ個別にユーザー/購読者となる者の鍵サーバー300への認証から考慮されてもよい。
暗号化モジュール200から(あるいは別の実施例として鍵源250自体から)鍵ストリーム175を受信することに加え、鍵サーバー300はトランザクションを管理し、それによって一つ以上の鍵ストリーム175を読み出すためのユーザーのリクエストが、認証情報によって許可されるアクセス権限または許可に従って、実現されるかまたは否定される。したがって、鍵サーバー300はインターフェース500から、ログインと認証350の認証情報の少なくとも一部を受信し、それらを検証する。一実施例として、鍵サーバー300によって無効な認証情報が受信された場合、鍵サーバー300は対応するリクエストを拒絶し、ユーザー/購読者に対して、その認証試行が成功しなかったことについての理由を詳細に述べるエラーメッセージまたはステータスメッセージで応答することができる。既に述べたように、認証は、例えばADFSを使ったり、識別プロバイダ(例えばGoogle,Microsoft,Facebookなど)を使ったりしてプロキシまたはアクティブディレクトリで行うことができる。
(ユーザー/購読者によって示された認証情報が検証されて)ログイン試行が成功した後、ユーザー/購読者に対して、データストリームのコンテンツを入手するための、一つ以上の暗号鍵をリクエストして入手する機会が与えられてもよい。なお、当然理解できることであるが、実施例において、そのようなリクエストが示され、特定され、選択され、または定式化できるような、特定の選択インターフェースは異なっていてもよい。その選択インターフェースは、本明細書でさらに説明する鍵サーバー300、ユーザー/購読者インターフェース500およびビデオアーカイブサーバー400の任意の組み合わせによって実装されてもよい。
限定されない一実施例として、選択メニューがユーザー/購読者に提示されてもよい。このメニューは、様々な暗号化データフィードの各々と関連付けられたメタデータ(例えば氏名、ファイルサイズ、データおよびタイプなど)を表示することができる。この暗号化データフィードには、前述の認証情報を使ってアクセスすることができる。そして、一つ以上の鍵はリクエストするユーザー/購読者によって所有され、そうでなければリクエストするユーザー/購読者にとってアクセス可能である。一つ以上のフィードをストリーミングしたり転送したりするための始点および終点をさらに特定する可能性が、さらに提供されてもよい。前述の機能は、データストリーム225の性質がそれを可能とする場合(例えばリクエストする暗号化データフィードがビデオストリームに対応する場合など)、一実施例において実装されてもよい。
別の一実施例として、鍵サーバー300は、各ユーザー/購読者に対して、そのユーザー/購読者がアクセス可能な一つ以上の鍵ストリーム175を含むことができる。1セット、1シーケンスまたは一連の鍵ストリーム175は、単一の識別子の論理コンテナに分類することができる。この論理コンテナは、とりわけ多数の暗号化鍵275が生成251されたフィード425の任意の部分または全部を後で復号することなどを主題の目的として、組み立てられたりもしくは一緒に結合されたりする、複数の個別の暗号化鍵ストリーム175を含む。
前述した認証情報の検証が成功したときに、またはその後のセッションの間の任意の段階において、読み出すための鍵または鍵ストリーム175の識別子は、通常はユーザー/購読者インターフェース500によって鍵サーバー300へのリクエストとして一実施例で提供されてもよい。
鍵ストリームを供給する鍵サーバー300によって、ユーザー/購読者の検索リクエストが成功したことに応答して、鍵サーバー300はそのリクエストを受諾し、対応する鍵(ストリーム)175がリクエストしたユーザー/購読者のインターフェース500へと送信され、その後それに応じて、その鍵ストリーム275を受信501する。したがって、鍵サーバー300はリクエストされた識別子に対応する鍵または鍵ストリーム175を提供する。同様に鍵サーバー300は、リクエストしたユーザー/購読者のインターフェース500への転送を開始するため、インデックス数(index numbers)325を使って通常表示される構成要素であるファイルブロック上のビデオアーカイブサーバー400に指示を同時に転送326する。ファイルブロックのインデックス325は、ビデオアーカイブサーバー400から一斉に読み出すための暗号化フィード425の一部を表示するのが通常であり、それに応じて暗号化フィード425はユーザー/購読者インターフェース500に送信される現行鍵によって復号される。
実施例では複数の鍵サーバー300が一つ以上の実装の戦略的目標に従って配備されてもよい。そのような目標として、例えば、唯一の鍵サーバー300に過度に負担をかける輻輳(ふくそう)の転換または緩和を含むことができ、さもなければそれによって鍵サーバー300のパフォーマンスに影響が出る、あるいは鍵を提供する負荷または特定の負荷を特定のトラフィック処理ポリシーの実装を通じて、一つ以上の別の鍵サーバー300に迂回させることができる。ビデオアーカイブサーバー400は暗号化モジュール200から、実施例によっては最初のストリーム100のアップロードのときに、暗号化データフィード225を受信する。ビデオアーカイブサーバー400の実装は、アーキテクチャ、インフラストラクチャ、レイアウトまたは構成に関するどのような考慮によっても制約される必要がない。ビデオアーカイブサーバー400は、本明細書でさらに説明する、ユーザー/購読者の認証情報のインターフェース500による検証が成功したとき、暗号化データフィード425を出力426する。ビデオアーカイブサーバー400の操作の重要な部分は、ビデオアーカイブサーバー400の、鍵サーバー300とのタンデム相互作用(図3を参照)であり、その鍵サーバー300は、リクエストした(一度検証された)ユーザー/購読者に対して、ビデオアーカイブサーバー400内に格納された、入ってくるフィード225を最終的に復号するために必要な暗号鍵275を発行する。なお、当然理解できることであるが、本明細書で説明した実施例の鍵ベースのアーキテクチャから生じる理由により、ビデオアーカイブサーバー400が鍵サーバー300と結びつけられる必要はない。同様に、ビデオアーカイブサーバー400は鍵サーバー300にごく接近して設置される必要はない(任意の安全な施設内にある必要もない)。なぜならば、任意のあり得る攻撃、侵害または他のビデオアーカイブサーバー400の侵害だけで、危険な状態に陥ったり、またはビデオアーカイブサーバー400が含む暗号化データフィード225に付随する脆弱性をもたらしたりすることはないはずだからである。したがって一実施例として、ビデオアーカイブサーバー400と鍵サーバー300とを、物理的に地球の反対側に配置してもよい。さらに、本明細書で説明した暗号鍵の実施例(および、図7で例示して説明したような、途切れ途切れに有効な暗号鍵の実施例)に基づいて、アーカイブサーバー400は公的にアクセス可能なFTPサーバーであってもよく、そのコンテンツの暗号化された性質は、対応する正しい暗号の復号鍵275aを所有していなければ、ほとんど理解できないも同然である。一組のサーバー300とサーバー400とは、リンクされることのみが必要であり、検証に成功したユーザー/購読者に対して、対応する適切な鍵ストリーム275、275aを供給するためにユーザーのリクエスト276aを実現させるために協働し、直接的または(インターネットなどの)ネットワークを通じて相互接続されているかどうかは問わない。
ユーザー/購読者の有効なリクエストがインターフェース500から受信され、その鍵または鍵ストリーム275、275aの検索操作(さらに本明細書で説明する)が鍵サーバー300によって処理(279、280)されるとき、フィード検索操作(326、402)の対応するシーケンスが、ビデオアーカイブサーバー400によって処理される(後者のシーケンスは、鍵サーバー300との部分的な連携で発生する)。成功したフィード検索操作(326、402、426)の間、ビデオアーカイブサーバー400は鍵サーバー300から鍵インデックス325を受信326する。鍵サーバー300によって発行326されるインデックス325は、さらなる実施例ではコマンドを含んだり、暗号化フィード425(またはその部分)を明確に識別するために必要な識別子を含むことができたりする。暗号化フィード425は検索のために要求され、現行鍵275aを使用してそれに応じて暗号化される。その暗号化フィード425および現行鍵275aの両方が、リクエストしたユーザー/購読者インターフェース500に同時に送信されてもよいが、例えば本明細書で説明した同期技術を使う場合、それらが同時に送信される必要はない。別の一実施例として、インデックス325のリクエストが、ユーザー/購読者インターフェース500によってビデオアーカイブサーバー400に対して直接発行されてもよく、それとともに、そのリクエストについて同時の独自検証350を鍵サーバー300で実施することができる。
読み出す暗号化フィード425が一旦識別され、暗号鍵または鍵ストリーム275aに対応するインデックス325が確認されると、暗号化フィード425がビデオアーカイブサーバー400からユーザー/購読者インターフェース500に送信され、後者は通常、ユーザー側のユーザー/購読者のワークステーション上で実行する。本明細書で説明したように、暗号化フィード425に加えてフィード全体を復号するのに必要な鍵275a(特にフィード425が有限である場合)、あるいは鍵275aのシーケンスまたはストリームがインターフェース500に対して同時に送信されてもよい(280、501、426、502)。
鍵275のシーケンシャル番号をユーザー/購読者インターフェース500に送信することにより、それぞれが暗号化フィード425の間欠的な部分を復号するが、これが望ましい場合がある。そのような間欠性は、ビデオストリームなどのフィードの連続する断片や部分を復号するために異なる鍵275aが必要となる場合や実施例で特に有益である(図7)。さらなる限定しない実施例として(図5)、複数の鍵275の断続的な送信によって提供される制御可能性は、同様に、別々の部分425aまたはすべての対応するビデオストリーム425が特定のポリシーに従って検閲される必要のある場合に活用することができる。そのようなポリシーによって保護される限定されない実施例は動画におけるシーンを含むことができる。この動画におけるシーンは、図形または露骨なコンテンツ、監視ビデオ内の興味のある時間範囲または領域、法の執行によって分類されるコンテンツまたは、他については、検閲されるコンテンツを含むその他のビデオファイル(図8、図9)に限定されない。
図5に関して、当然に理解できることであるが、暗号化フィード425aの全部または個別の部分と暗号学的に適合する鍵または鍵ストリーム275aは、十分な時間オフセット555またはリードタイムをとって、ユーザー/購読者インターフェース500のノードで受信されるべきであり、フィード425aの対応する個別の部分の受信と復号モジュール500の操作とを適切に構成しかつ適応させて、復号されたフィード575をそれに続くディスプレイ600にタイムリーに生成することを確保することができる。別の一実施例として、ストリーム425aとその対応する鍵275aの両方のかなりの部分がユーザー/購読者インターフェース500のノードで受信される前に、復号や再生が開始されないようにするため、適切なセーフガードまたはバッファリング機構が実装されてもよい。理想的にはそのような一実施例は、数ある中でも、ネットワークの行動に基づく進行予測とユーザー側の計算リソースとを使って、(鍵275、275aおよび暗号化フィード425、425aの任意の未処理量の)任意の残りの転送が再生時間を超えないで、時間ウインドウ内で完了することを保証しようとするべきである。そのようなタイムリーな配信を保証することができない場合、例えば他のユーザー/購読者からの新規のリクエストの処理の遅延や、一時的または最終的に、リクエストされた暗号化フィード425の、より小さい帯域幅集中型のバリアント(variant)にシフトすることなどの、全体のユーザー/購読者の体験に与える悪影響を減らすようにシステム側のステップを取られてもよい。
一実施例として、フィードの特定の区分や部分を復号するための暗号鍵275aは、その鍵が適合するフィード425aの部分との組み合わせるための(全ての場合か(ライブ)ビデオ再生の場合であるかを問わず、十分な加工/処理の時間マージンオフセット555内の)インターフェースで受信されるべきではない。復号は起こらない可能性があり、すなわち、欠落している暗号鍵275aが適合するフィードの部分に関しては何も起こらない。これは特に、本明細書の実施例についてさらに説明する不十分なアクセス特権マーカー288に対する実装およびサポートが欠落している一つ以上の実施例の場合にあてはまる。したがって、そのような実施例に関しては、フィードの対応する部分が暗号化されかつ回復できない「パッチ」のままであってもよい。一実施例として、復号されていないかまたは解読できないビデオは、その「パッチ」の継続時間にわたって再生されないだけではなく、例えばブランクスクリーンまたは他の適切なプレースホルダーなどの、特に前述のマーカー288よりも少ない情報を含むものと置き換えられてもよい。なお、当然理解できることであるが、とりわけ前述したことと本明細書で詳細に説明したことの観点から、本明細書で考慮するアーキテクチャについて、アーカイブサーバー400は比較的最小限のセキュリティポリシーによって制御されるシンプルなFTPサーバーを有利に含むことができる。ビデオのわずか数秒またはリッチテキストのコンテンツの数パラグラフのみを構成する小さな侵害を含む可能性のあるシナリオでは、単一鍵の侵害でさえも、悪意あるユーザーに暗号化フィードの個別の部分425aを復号できるようにする可能性がある。
別の一実施例として(特に前述の解読できないパッチの発生が避けられる場合)、鍵ストリーム275が、個々の暗号鍵275の断続的かつタイムリーな発行よりも好ましい場合がある。従って、ストリームにおける鍵275のバルク転送が、いくつかの理由で望ましい場合がある。この理由として、ビデオストリーム再生において発生し得る妨害を最小化できること、効率性または潜在的なパフォーマンスを高められること、または、送信される個々の鍵の数を単純に減らせることを含むが、これらに限定されない。
本明細書で開示した様々なモジュールに関する議論の中で述べたように、ユーザー/購読者インターフェース500は、実施例によっては最小限必要なクライアント、または包括的なアプリケーションであってもよく、このアプリケーションはユーザー/購読者の場所で実行し、そのユーザー/購読者がセッションを開始(ログイン)および終了(ログアウト)できるようにする。任意の可能性のあるセッション間の相互作用も同様である。そのような相互作用は実施例によっては本明細書で述べたすべての機能的な可能性を含むことができる。例えば、データストリームをアップロードしたり転送したりすること、共有ポリシーを特定すること、転送リクエストを開始すること、およびもっと顕著には、鍵や鍵ストリーム175や復号425する暗号化データフィードに対応する暗号化鍵ストリーム275の検索/受信、暗号化ビデオフィードの受信、およびタンデム暗号鍵の処理/復号し、暗号化データを暗号化されていないものにし、ディスプレイ600が理解できるデータにすることを含むが、これに限定されない。ビデオアーカイブサーバー400に存在する特定のフィード425への有効なアクセスの後、暗号化フィードの個別の部分と紐づけられた一つ以上のインデックス325値を発行することによって貧弱なネットワーク品質を克服する必要があるとき、ユーザー/購読者インターフェース500は、その暗号化フィード425の一部または全部のアーカイブサーバー400からの再送信をリクエストしてもよい。
「ユーザー」と「購読者」という用語は、様々な集団の役割が重複する本明細書では相互に交換可能に使用することができる。ユーザーが特定のストリームまたはビデオアーカイブサーバー400内に格納されたコンテンツを購読したい場合、彼はそのコンテンツを復号するために必要な鍵または鍵のストリーム175または暗号化鍵ストリーム275へのアクセスが認められるようにリクエストすることができる。彼は彼がアクセスすることのできるユーザー/購読者インターフェース500のノードを通じてこれをすることができ、ユーザーインタフェースを、ビデオアーカイブサーバー400内に格納された選択可能なカタログまたは入手可能な暗号化ビデオフィード425のリストに提供することができる。彼はそこから購読リクエストを定式化することができる。そのリクエストは検証と承認のために、ユーザー/購読者インターフェース500から鍵サーバー300へと安全に送信される。承認にあたり、暗号化フィードを復号するため、購読者は鍵または鍵ストリームを受信することができる。そして彼はそれに応じてビデオを購読することができる。さらなる実施例として、暗号化フィードに適合する鍵(ストリーム)が現行のおよび/または有効なままであることを確実にするため、管理に関連するタスクをユーザー/購読者インターフェース500に分け与えることができる。これは特に暗号化フィード425にとって重要であり、その暗号化フィード425の対応する鍵175は断続的に有効であるか、または定期的に変化さえする。特定のユーザー/購読者インターフェース500と鍵サーバー300とによって、鍵175の任意の必要な再リクエスト、リフレッシュまたはアップデートと他の付随する検証が実行されてもよい。特定の暗号化フィード425を復号するための鍵175へのアクセスが、特定のポリシーの結果としてもはや許可されるべきでない場合、リクエストした購読者にユーザー/購読者インターフェース500内で適切なメッセージが通知されてもよい。
実施例では、ユーザー/購読者インターフェース500でコンテンツ425を受信したい(そのようにするための許可ポリシーと一致する権限を有する)個人は、正確に言えば、コンテンツの一つ以上のレイヤーに対する「購読」と言われても良い。これは特に、コンテンツを復号するための暗号鍵を受信することなどによって、ストリームのコンテンツ601への権限が与えられたそれらの個人に言えることである。購読の持つ一時的な、契約上の、範囲の定められた性質は実施例でさらに強制される。この実施例では一人以上の個人に再分配することのできるストリームや他のファイル(図13aと図13bを参照)の一部(例えば、図12に示すような時間または他の量的に制限されるセグメント)のみ復号するのに有効な、一つ以上の暗号鍵が有効である。
ユーザー/購読者インターフェース500に関連するトランザクションは、このようにログインや認証手続きを必要とするのが普通であり、例えばユーザーネーム/パスワードの一組を介するなどの、当業者に知られた任意の適切な方法を使って実装されてもよい。トランザクションが成功すると、ビデオアーカイブサーバー400上で入手可能な、ユーザー/購読者が復号する権限を有するコンテンツを、ユーザー/購読者に復号させられる(あるいは暗号化コンピュータシステム31から直接的にライブストリーミングを受信する)ようにするのが通常である。
認証が成功することにより、ユーザー/購読者が暗号化フィード425を検索できるようするのに適したすべてのアクションを含む実施例と、ユーザー/購読者とが関係するようし、別の実施例では暗号化フィード425を格納できるようにする。ファイルまたはストリームがローカルで開かれるとき、インターフェース500はクラウドから受信した暗号化データフィード425,425aを復号し、ローカルで開いたり再生したりするための、ローカルでアクセス可能なユーザー/購読者のメモリにそれを入れる。
なお、当然理解できるように、インターフェース500によって使用されるパスワードは、ユーザー/購読者のIDを検証するためにローカルで利用されてもよい。そのパスワードは、同様に、インターフェース500によって、別の特別に安全なパスワードサーバーに送られ、その結果、そのように権限の与えられた(すなわち彼は鍵275を得ることによって権限を有することができた)任意のユーザー/購読者は、アーカイブサーバー400上に存在する特定の暗号化データフィード425をリクエストすることができ、さらにそのフィードを復号551したり、開いたり、そうでなければフィードにアクセス601したりすることができる。
認証が成功すると、暗号化データフィード425はビデオアーカイブサーバー400によって、受信ユーザーの一人(ユニキャスト)または複数人(マルチキャスト)に供給される。実施例では、特定のフィードを復号551したり、特定のフィードにアクセス601したりすることを要求する複数の受信ユーザーの各々に、求まれている鍵または鍵ストリーム275が提供されてもよい。なお、当然理解できることであるが、特定の実施例では、単一の鍵または鍵ストリーム275が鍵源250によって生成されてもよく、また特定のフィードを復号551するためにユーザー/購読者インターフェース500に単一の鍵または鍵ストリーム275が提供されてもよい。別の実施例として、たとえそうすることが技術的に可能である場合でも、異なる暗号鍵または鍵ストリーム275を使ってそのフィードを再暗号化(繰り返される可能性がある)することよりも、むしろ同じ暗号化フィードを復号するための複数の鍵または鍵275の並列セットを生成することが有益であるかまたは望ましい場合がある。そのような鍵275の並列セットを発行/生成することや、それらを鍵サーバー300からユーザー/購読者に送信することは、例えば柔軟性のある、またはさらに頑強なアクセスポリシーを設けて強化するという点においては有益となり得る。その際、所与の鍵(ストリーム)275が権限のある受信ユーザーの一つの集団には発行されてもよいが、別の集団には発行されなくてもよい。これは受信ユーザー/購読者のセットを特定するため、復号アクセスを許可し、無効にし、または条件付きでアクティブにすることによって、有益なスキームを提供することができる。そのようなアクセスポリシーの差別化が望ましい場合がある。例えばその場合とは、一方で、一人以上のユーザー/購読者に対し、ビデオ(例えば図7)の所与の期間またはファイルの一部を復号することのできる鍵275とともに、暗号化フィード425へのアクセスを提供したり、他方で、他のユーザー/購読者に対して全体のフィードのための単一鍵275を提供したりする場合である。
本明細書でさらに説明するように、前述のアクセスポリシーの差別化はさらに、ビットストリーム(図11)の特定の部分またはレイヤーのみを対象とすることができる任意の暗号化スキームと並行して、または任意の暗号化スキームと区別して実装されてもよい。
前述のアクセスポリシー差別化の概念の限定されない一つのシナリオとして、様々な範囲の場所25からの、一つ以上のセキュリティカメラフィードへのアクセスが提供される捜査官を考慮してもよい。その捜査官はそれに応じて彼に割り当てられたユーザー/購読者インターフェース500を使って仕事をする。そのインターフェース500は本明細書で実質的に説明したように機能する。彼のインターフェース500は、一旦ローカルで復号されると、彼が様々なカメラによってキャプチャされたフレームを見たり、一時停止/停止したり、比較したり、関連付けたり、または再生したりすることができるようにする機能をさらに提供することができる。しかしながら、ならず者の捜査官は彼の権限を越える方法で、そのソース50によってキャプチャされた特定の個人をストーキングするかまたは活動を観察することによって、彼の立場を悪用したくなる可能性がある。そのような可能性に対処するため、すべての捜査官に実装されるアクセスポリシーによって、所与の任務または特定の施設25内のすべてのビデオ監視カメラから集められるすべてのフレームを復号する能力を捜査官に付与することができ、そのコンテンツがビデオアーカイブサーバー400内に格納される。同様に、およびその任務にしたがって、警備員(あるいは彼のビデオウォールを提供したり、さもなければ備える、特定のユーザー/購読者インターフェース500に対応するネットワークノード)に割り当てられた所定のポリシーおよび鍵(または鍵275)が、前の1時間内にキャプチャされた監視ビデオのみを復号して見ることができるように彼を制限したり、あるいは警備員のシフトの最初からのみ復号して見ることができるようにしたりすることができる。
別のシナリオでは、公共の場(または公共の場を一部に含むもの)から監視カメラ映像を集めるビデオカメラが法律によって禁止される可能性がある。しかしながら、組織のセキュリティのニーズによっては、任意の刑事犯罪またはセキュリティを危険にさらす事件がキャプチャされて、犯人が特定されて起訴されることを先制して確実にするため、そのエリアの占拠を強く動機づけする可能性がある。そのような場合、一連のカメラ50は、様々なストリーム100をキャプチャ101し、同時にストリーム100を暗号化モジュール200によって暗号化201する。そして、その結果生じる暗号化フィード225はビデオアーカイブサーバー400に送信226される。暗号化フィードを復号するための鍵275は鍵サーバー300に格納されてもよく、通常は法執行機関当局にのみアクセス可能であり、その法執行機関当局の役割は、ストリーム100からキャプチャされた(またはキャプチャされる可能性のある)出来事に関連する任意の事件を調査することである。このシナリオの変形例として、法執行機関の職員が高画質、高帯域幅のストリーム575の変形例を見る601ことができるようにする鍵275を(法的執行部隊に特有のユーザー/購読者インターフェース500を介して)、通行人の顔を不鮮明にする低品質の変形例のための鍵とともに提供することを含むことができ、これは特定の地域に割り当てられたプライベートのセキュリティ要員(プライベートなセキュリティ要員に固有のユーザー/購読者インターフェース500を介してフィードを見る、プライベートセキュリティ要員に)に対して提供される。別の一実施例として、法執行機関に提供される鍵275はプライベートなセキュリティ要員に提供されるものとは異なる鍵サーバー300に格納されてもよい。その異なる鍵サーバー300は、さらなる実施例において完全に異なる管理構造を有することができる。
さらなる実施例として、法執行機関は鍵源250および鍵サーバー300を直接的に管理してもよい。そのような一実施例として、鍵275は鍵サーバー300(この場合鍵源250を含んでもよい)と暗号化モジュール200との間の安全な接続を通じて、法執行機関によって簡潔かつ短命に共有されてもよい。この共有する時間ウインドウの間、暗号化モジュール200はストリーム100を暗号化ビデオフィード225に変換し、それ225をビデオアーカイブサーバー400に送信する。
単一のまたは並列のセットの有効な鍵275が単一の暗号化フィードについて生成され発行されるかどうかに関わらず、ユーザーは通常、ビデオアーカイブサーバー400から暗号化フィードを受信することができる。なお当然理解できることであるが、実施例によっては、ユーザー/購読者インターフェース500は暗号化モジュール200から直接的に暗号化フィードを受信することができるが、ライブでストリーミングされるビデオストリームを含む暗号化ストリームについて、アーキテクチャ最適化のために、暗号化ストリームがビデオアーカイブサーバー400内部に格納され、ビデオアーカイブサーバー400からユーザー/購読者インターフェース500(または複数のそれら)に対して発行されるのが望ましく、このように各モジュールのそれぞれの役割の励行を促している。そうすることにより、原理上は待ち時間を増やす可能性があるものの(その待ち時間はライブストリーミングされようとしているフィードにとって特に望ましくないものである)、構造および配置について努力することにより、そのような望ましくない影響を比較的無視できる状態にするため、そのような待ち時間を最小化して相殺することができる。
各モジュールの役割を厳格に実施することにより、モジュール間の相互作用に加えて、各モジュールに固有の機能と特殊性とを最適化することによって、操作上の負担を集中させる機会を提供する可能性もある。例えばビデオアーカイブサーバー400は通常、受信を処理しなければならず、とりわけ、一度に大容量のデータを供給しなければならない。結果として、帯域幅の考慮は特に重要であり、とりわけ暗号化フィードが同時に送信されなければならない多数のユーザー/購読者インターフェース500で重要である。この子試みにおいて当然に理解できることであるが(図5に注目されたい)、そのようなフィードの送信が、ユーザー/購読者インターフェース500に対する復号鍵275の発行と大抵同時に(シナリオによっては断続的に)発生するであることを確保するが、十分な優先的な遅延または時間オフセット555が鍵275aの受信と、復号に適合するフィード425aの受信とを確実に分離するということを確保することは考慮すべき重要なことである。同様に、鍵サーバー300は通常、ネットワーク内の様々なノードに配置された数多くのユーザー/購読者インターフェース500に由来するリクエストを処理する。よって鍵サーバー300はその操作を実行し、最小限の応答時間と待ち時間で最適にそのようにする必要がある。鍵サーバー300がユーザー認証を実行することと、鍵リクエストを許可することとが、ビデオアーカイブサーバー400が暗号化フィードをユーザー/購読者に供給することよりも、全体として著しく小さい帯域幅集約プロセスであると仮定すると、前者の鍵サーバー300の帯域幅に関するニーズは後者のビデオアーカイブサーバー400よりもかなり弱い。
なお当然理解できることであるが、本明細書で検討したトポロジーの実施例が最適な操作シナリオを提供する。鍵管理操作からストレージを分離することにより、任意の予想外の(暗号化)データの提供や(暗号化)データの侵害の負担を著しく減らすことができ、その影響を弱めることができる。したがって、データアクセスのインテグリティを保持するための責任の大部分は、信頼できるユーザー/購読者インターフェース500に置かれる。さらに、復号モジュールによって行われる復号プロセスはユーザー/購読者インターフェース500のノードに存在しており、このノードは完全に異なる場所における鍵および暗号化フィードの格納と結合され、それらが消費されるノードでそれらを復号プロセスに結び付け、セキュリティとパフォーマンスについて最適化された、まさにうってつけのトポロジーのアーキテクチャを提供する。
別の一実施例として、複数のストリームを合成することが望ましい場合がある。合成は本質的に、破壊的であるかまたは破壊的でないかのいずれかである。複数のストリームのコンテンツを混合する可能性を含む一実施例として、例えばひとつの映像レイヤーと3つの音声レイヤーとを混合することで新規の合成出力を生成することができる。ユーザー/購読者は、例えばユーザー/購読者インターフェース500のノードで、4つの構成要素であるレイヤーのそれぞれを取得したり復号したりする権利を有する(すなわち、鍵175を取得するための許可を有する)。復号の後、4つのレイヤーの合成または混合は、ユーザー/購読者インターフェース500にとってローカルにある(そして適切に信頼できる)プロセッサ上で行われる。なお当然理解できることであるが、その合成の結果生じた新規のストリーム100は順番に暗号化されてもよい。一実施例において、暗号化モジュール200は暗号化のためにユーザー/購読者インターフェース500にアクセス可能とされてもよい。必要な鍵275は同様に鍵源250によって生成され、その結果生じた鍵275は本明細書で詳細に説明した機能にしたがって、鍵サーバー300に格納される。
一実施例として、ユーザー/購読者インターフェース500は新規のアカウントを作成するための機能を提供することができる。アカウントの削除も同様に、インターフェース500の一部に実装することができる。そして、さらなる実施例では、アカウントの削除が各ユーザーの排他的権利であってもよく、またはその代わりにサービスメンテナンス要員によって実行されるポリシーで共有されてもよい。
なお当然理解できることであるが、暗号化モジュール200とユーザー/購読者インターフェース500とを組み合わせて、個人のコンピュータまたはモバイルプラットフォームなどの任意のプラットフォーム上でアクセス可能な、単一のユーザー側のアプリケーションにすることができる。また、当然理解できることであるが、別のシリーズの実施例として、彼が同時にインスタンス生成することのできる多重セッションの数において、単一のユーザー/購読者またはアカウントが許可されたり、禁止されたり、または制限されたりする可能性がある。
なお、当然理解できることであるが、あり得る実施例の実装は、本明細書で議論したかどうかに関わらず、とりわけ、ユーザー/購読者の数やビデオアーカイブサーバー400に格納するデータ量が非常に大きな割合に達する場合、拡張性を目的として、提供した説明からいくらか逸脱するものであっても良い。例えば、ネットワークまたは実施例が展開される可能性のあるネットワークはLAN,WANやインターネットを含むことができるが、これに限定されない。このテクノロジーは、信頼できないネットワークを通じたデータへの安全なアクセスを提供するのに非常に適しているが、当然理解できることであるが、信頼できないネットワークが使用される場所(例えば、信頼できないネットワークを通じて通信が行われる場所)で、代わりに信頼できるネットワークを使用することもできる。そのような場合、本願のテクノロジーは許可に基づくアクセスコントロールと同様に、付加的なレイヤーのセキュリティをさらに提供することができる。
本明細書で提供したコンピュータ読み取り可能な記憶媒体は、チップベースまたはディスクベースの記憶媒体などの有形のコンピュータ読み取り可能な記憶媒体であってもよく、またCPUなどの処理エンティティによってアクセス可能であってもよい。
ビデオアーカイブサーバー70はそのように名づけたが、これは主に便宜のためである。なお、当然理解できることであるが、データストリームや、より広義にはデータを格納するための市販のデータストリームアーカイブサーバーを表すこともできる。本明細書では単一の暗号化コンピュータシステム30とビデオアーカイブサーバー70とを示したが、多重暗号化コンピュータシステムがビデオアーカイブサーバー70を共有してもよく、または概してその逆の場合とは少ないということは当然理解できることである。さらに、これらのエンティティの両方は冗長バージョンを有することができる。冗長な暗号化コンピュータシステムは、オリジナルの暗号化コンピュータシステム30のように、生データストリームを受信することができ、データや鍵ストリームを独立して暗号化することができる。補助アーカイバーが、暗号化データストリームや暗号化鍵ストリームの追加の複製を格納するためのビデオアーカイブサーバー70に対するクライアントとして提供されてもよい。
したがって、当然理解できることであるが、本願のテクノロジーによって、差別化された許可アクセスを有するデータストリームの安全な保管および転送が可能になる。データストリームは非常に大きな、すなわち境界のない/無限となる可能性があり、自由裁量によって、または任意の適切なパターンに従って、有限のセグメントに分割することができる。なお、ストリームの部分は通常、それ自体がストリームであることを理解されたい。したがって、特定のストリームで実行されるといわれるものが、そのストリームの一部のみについて実行されてもよく、それが実行される部分がストリームである。これは明らかなはずであるが、例えば潜在的に無限のストリームについて論じる場合、本願で説明した技術をその一部に適用することができる場合、それ自体がストリームである。
対称暗号化は巨大なデータセットについては効率的であるが、信頼性の問題につながる秘密鍵を共有することを伴う。非対称暗号化は巨大なデータセットについては効率的ではないが、より良く制御することができる。本願のテクノロジーは巨大なデータセットを暗号化する対称鍵を非対称的に暗号化することによる、非対称暗号化のセキュリティと対称暗号化の大雑把な効率性とで巨大なデータセットを保護することによって、これらの技術の両方の利益を提供することができる。
本願のテクノロジーは、データが保管されているときと、転送されるときとの両方でデータが暗号化されているため、クラウドの信用問題の効率的な処理も可能とする。中央の保管所(例えばクラウド)は、暗号化されていないデータにアクセスすることはできず、一実施例では、その保管所自体によっては新規のユーザーに対して新規のアクセス許可を与えることはできない。信頼できるエージェントは巨大なデータセットに有利に直接アクセスする必要のないプロセスにおいて許可を与える任務を負っている。有利なことに、オリジナルデータと対称鍵の暗号化されていない複製を保持する必要はなく、特別なデータ保全のために廃棄される。
データの分配と共有は拡張可能であり、共有はデータストリーム自体の復号を必要とせず、鍵ストリームの復号のみを必要とする。さらに、共有と許可の付与は、データストリームまたは全セットの一部についてきめ細かく実行することができる。データストリームは特定の長さ(例えば1分間)のセグメントに分割され、各セグメントはランダムな対称鍵(これは共に鍵ストリームを形成する)で暗号化されて、暗号化データストリームを生成する。これは進行中のプロセスであってもよく、これにより新規のセグメントが存在する度(例えば毎分)に新規の対称鍵が生成され、鍵ストリームに追加される。鍵ストリームまたはその一部は、権限の与えられたエンティティの証明書における公開鍵で非対称的に暗号化され、暗号化された証明書固有の鍵ストリームを生成することができる。権限のあるエンティティがこの鍵ストリームを共有することができ(または安全に格納されたり広く分配されたりする)、権限のあるエンティティがデータストリームの対応する部分にアクセスできるようにする。
様々な実施例を示してきたが、これは本願発明を説明することを目的とするものであって、限定することを目的とするものではない。様々なあり得る修正および異なる構成は当業者にとって明らかとなるとともに本願発明の範囲内にあり、付属の請求項によってより具体的に規定される。