(57)【要約】  許可に従って、安全なストレージと、データストリームの送信と、同様に複数のデータストリームへの段階的なアクセスとを可能にする技術である。データストリームは対称鍵の鍵ストリームに従って、異なる対称鍵で実行される対称暗号化を使って暗号化することができる。ネイティブデータは安全のため廃棄することができる。鍵ストリームの全体または一部は、各データストリームまたはその一部にアクセスするための許可を有する、権限のあるエンティティの公開鍵を使って暗号化されてもよい。対応する秘密鍵のみが、暗号化されたデータストリームを復号するために必要な暗号化鍵ストリームを復号することができる。したがって厳格なアクセス制御が提供される。サーバー上のデータストリームファイルにアクセスするＩＴ担当者または、悪意を持ってファイルを入手しようとする侵入者はデータストリームを得ることができない。固有のリスクに関わらず、クラウドサービスを使って機密のデータストリームを格納することができる。
2018534879.tif 000002
【特許請求の範囲】
【請求項１】
信頼できないネットワークを通じたユーザーによるストリーミングデータへのアクセスを制御する方法であって、信頼できるネットワーク領域において、
ａ．暗号化データのシーケンシャル部分を含む、第一の対称的に暗号化されたデータストリームを生成するため、第一データストリームの各シーケンシャル部分を暗号化する、第一の複数の異なる対称暗号化鍵を含む第一対象暗号化鍵ストリームを、暗号化コンピュータシステムが鍵ジェネレータから得るステップを備え、
ｂ．信頼できないネットワークを通じて各リモートコンピュータシステムから少なくとも一つの公開非対称暗号化鍵を受信するステップを備え、
ｃ．それぞれの非対称的に暗号化された第一鍵ストリームを生成するため、少なくとも一つの公開非対称暗号化鍵のそれぞれを使用して、暗号化コンピュータシステムによって第一対称暗号化鍵ストリームをデジタル暗号化することによって、非対称的に暗号化された鍵ストリームデータを生成するステップを備え、非対称的に暗号化された第一鍵ストリームが少なくとも一つの公開非対称暗号化鍵のそれぞれで暗号化され、その非対称的に暗号化された鍵ストリームデータが、非対称的に暗号化された第一鍵ストリームの各々を含み、
ｄ．暗号化コンピュータシステムから、信頼できないネットワークを通じて、非対称的に暗号化された鍵ストリームデータを送信するステップを備えることを特徴とする方法。
【請求項２】
請求項１に記載の方法であって、信頼できるソースとの信頼できる接続を通じて、第一データストリームを暗号化コンピュータシステムで受信するステップをさらに備え、暗号化コンピュータシステムにおいて、第一の複数の異なる対称暗号化鍵のそれぞれで、第一データストリームの各シーケンシャル部分をデジタル暗号化することによって、第一暗号化データストリームが生成されることを特徴とする方法。
【請求項３】
請求項１または２に記載の方法であって、非対称的に暗号化された鍵ストリームデータを生成するステップが、複数の異なる対称暗号化鍵を、暗号化データの各シーケンシャル部分と同期させることを含むことを特徴とする方法。
【請求項４】
請求項３に記載の方法であって、複数の異なる対称暗号化鍵を暗号化データの各シーケンシャル部分と同期させるステップが、非対称的に暗号化された第一鍵ストリームにおいて、複数の異なる対称暗号化鍵のそれぞれに対して、暗号化データの各シーケンシャル部分への時間リファレンスを提供することを含むことを特徴とする方法。
【請求項５】
請求項１から４のいずれかに記載の方法であって、
ａ．暗号化コンピュータシステムにおいて、少なくとも一つの公開非対称暗号化鍵の各々を使って第一対称暗号化鍵ストリームをデジタル暗号化するより前に、第一データストリームにアクセスするための許可と関連付けられているかどうかを、少なくとも一つの公開非対称暗号化鍵のそれぞれについて決定するために、電子アクセス許可ディレクトリを調べるステップをさらに備え、特定の公開非対称暗号化鍵がデータストリームにアクセスするための許可と関連付けられているという決定に応じて、少なくとも一つの公開非対称暗号化鍵のそれぞれについて、対称暗号化鍵ストリームの暗号化が選択的に実行されることを特徴とする方法。
【請求項６】
請求項５に記載の方法であって、信頼できるネットワーク領域において、
ａ．暗号化データのシーケンシャル部分を含む、第二の暗号化データストリームを生成するため、第二データストリームの各シーケンシャル部分を暗号化する、第二の複数の異なる対称暗号化鍵を含む第二の対象暗号化鍵ストリームを、暗号化コンピュータシステムで鍵ジェネレータから得るステップと、
ｂ．第二データストリームにアクセスするための許可と関連付けされているかどうかを、少なくとも一つの公開非対称暗号化鍵のそれぞれについて決定するために、電子アクセス許可ディレクトリを調べ、少なくとも一つの公開非対称暗号化鍵の適切なサブセットが第二データストリームにアクセスするための許可と関連付けられていることを決定するステップと、
ｃ．それぞれの非対称的に暗号化された第二鍵ストリームを生成するために、暗号化コンピュータシステムにより、適切なサブセット内の公開非対称暗号化鍵のみで、第二対称暗号化鍵ストリームをデジタル暗号化するステップとを備え、
非対称的に暗号化された第二鍵ストリームを生成するため、それらは適切なサブセット内の公開非対称暗号化鍵の各々で暗号化され、非対称的に暗号化された鍵ストリームデータが、非対称的に暗号化された第二鍵ストリームを含むことを特徴とする方法。
【請求項７】
請求項６に記載の方法であって、暗号化コンピュータで第二データストリームを受信するステップをさらに備え、第二データストリームの各シーケンシャル部分を第二の複数の異なる対称暗号化鍵のそれぞれでデジタル暗号化することによって、第二の暗号化データストリームが暗号化コンピュータシステムで生成されることを特徴とする方法。
【請求項８】
請求項１から７のいずれかに記載の方法であって、
ａ．非対称的に暗号化された鍵ストリームデータをレポジトリ内に格納するステップと、
ｂ．信頼できないネットワークを通じて第三者のコンピュータから送られてくる第一データストリームに対するリクエストに応じて、そのリクエストを検証し、第三者の公開鍵で暗号化された、非対称的に暗号化された第一鍵ストリームを送信するステップとをさらに備えることを特徴とする方法。
【請求項９】
請求項８に記載の方法であって、
ａ．非対称的に暗号化されたストリームデータをレポジトリ内に格納するステップと、
ｂ．第三者のコンピュータから送られてくる第一データストリームに対するリクエストに応じて、信頼できないネットワークを通じて第三者のコンピュータに第一の暗号化データストリームを送信するステップとをさらに備えることを特徴とする方法。
【請求項１０】
請求項８または９に記載の方法であって、レポジトリが、信頼できないネットワーク内にあるリモートレポジトリであることを特徴とする方法。
【請求項１１】
請求項８に記載の方法であって、レポジトリが、信頼できるネットワーク領域内の信頼できるレポジトリであり、この方法が、信頼できないネットワークを通じてアクセス可能なリモートコンテンツサーバーに、非対称的に暗号化されたストリームデータを格納するステップをさらに備えることを特徴とする方法。
【請求項１２】
請求項１に記載の方法であって、信頼できるソースとの信頼できる接続を通じて、第一暗号化データストリームを暗号化コンピュータシステムで受信するステップをさらに備え、その信頼できるソースが鍵ジェネレータを含み、第一対称暗号化鍵ストリームが、信頼できる接続を通じて信頼できるソースから得られることを特徴とする方法。
【請求項１３】
請求項１２に記載の方法であって、信頼できるソースが監視カメラであり、信頼できるネットワーク領域がＤＭＺによって保護される監視カメラネットワークであることを特徴とする方法。
【請求項１４】
請求項１から１１のいずれかに記載の方法であって、鍵ジェネレータが暗号化コンピュータシステムによって実行可能なプログラムモジュールであり、鍵ジェネレータから第一対称暗号化鍵ストリームを得ることが、暗号化コンピュータシステムで鍵ジェネレータのプログラムモジュールを実行することを含むことを特徴とする方法。
【請求項１５】
信頼できないネットワークを通じたユーザーによるストリーミングデータへのアクセスを、信頼できるネットワーク領域において制御する操作のための暗号化コンピュータシステムであって、
暗号化コンピュータシステムが、汎用処理ユニットに指示を与えるための指示を含む、コンピュータ読み取り可能な記憶媒体に格納された、コンピュータ読み取り可能な指示を含み、この指示は汎用処理ユニットに対し、
ａ．暗号化データのシーケンシャル部分を含む第一暗号化データストリームを生成するため、第一データストリームの各シーケンシャル部分を暗号化する第一の複数の異なる対称暗号化鍵を含む、第一対称暗号化鍵ストリームを鍵ジェネレータから入手するように指示し、
ｂ．信頼できないネットワークを通じてリモートコンピュータシステムの各々から少なくとも一つの公開非対称暗号化鍵を受信するように指示し、
ｃ．各々の非対称的に暗号化された第一鍵ストリームを生成するため、少なくとも一つの公開非対称暗号化鍵のそれぞれを使用して第一対称暗号化鍵ストリームをデジタル暗号化することによって、非対称的に暗号化された鍵ストリームデータを生成するように指示し、その非対称的に暗号化された第一鍵ストリームのそれぞれが、少なくとも一つの公開非対称暗号化鍵のそれぞれで暗号化され、非対称的に暗号化された鍵ストリームデータは、非対称的に暗号化された第一鍵ストリームのそれぞれを含み、
ｄ．非対称的に暗号化された鍵ストリームデータを信頼できないネットワークを通じて送信するよう指示するものであることを特徴とする方法。
【請求項１６】
請求項１５に記載の暗号化コンピュータシステムであって、汎用処理ユニットに指示を与えるための指示を含むコンピュータ読み取り可能な記憶媒体に格納された、コンピュータ読み取り可能な指示をさらに含み、この指示は汎用処理ユニットに対し、
ａ．信頼できるソースとの信頼できる接続を通じて第一データストリームを暗号化コンピュータシステムで受信するように指示し、
ｂ．第一の複数の異なる対称暗号化鍵のそれぞれで、第一データストリームの各シーケンシャル部分をデジタル暗号化するように指示するものであることを特徴とする暗号化コンピュータシステム。
【請求項１７】
請求項１５または１６に記載の暗号化コンピュータシステムであって、汎用処理ユニットに指示を与えるための指示を含む、コンピュータ読み取り可能な記憶媒体に格納された、コンピュータ読み取り可能な指示をさらに含み、この指示は汎用処理ユニットに対し、複数の異なる対称暗号化鍵を暗号化データの各シーケンシャル部分と同期させるよう指示するものであることを特徴とする暗号化コンピュータシステム。
【請求項１８】
請求項１７に記載の暗号化コンピュータシステムの方法であって、汎用処理ユニットに指示を与えるための指示を含む、コンピュータ読み取り可能な記憶媒体に格納された、コンピュータ読み取り可能な指示をさらに含み、この指示は汎用処理ユニットに対し、複数の異なる対称暗号化鍵と暗号化データの各シーケンシャル部分とを同期するよう指示するものであるが、このコンピュータ読み取り可能な指示が、非対称的に暗号化された第一鍵ストリームのそれぞれにおける、複数の異なる対称暗号化鍵のそれぞれについて、暗号化データの各シーケンシャル部分への時間リファレンスを提供するように汎用処理ユニットに指示を与えるための指示を含むコンピュータ読み取り可能な記憶媒体に格納された、コンピュータ読み取り可能な指示を含むことを特徴とする方法。
【請求項１９】
請求項１５から１８のいずれかに記載の暗号化コンピュータシステムであって、電子アクセス許可ディレクトリをさらに含み、汎用処理ユニットに指示を与えるための指示を含む、コンピュータ読み取り可能な記憶媒体に格納された、コンピュータ読み取り可能な指示をさらに含み、この指示は汎用処理ユニットに対して、
ａ．少なくとも一つの公開非対称暗号化鍵のそれぞれを使って第一対称暗号化鍵ストリームをデジタル暗号化する前に、電子アクセス許可ディレクトリを調べ、少なくとも一つの公開非対称暗号化鍵のそれぞれについて、第一データストリームにアクセスするための許可と関連付けられているかどうかを決定するように指示し、
ｂ．特定の公開非対称暗号化鍵がデータストリームにアクセスするための許可と関連付けられているという決定に応じて、少なくとも一つの公開非対称暗号化鍵の特定のそれぞれについて、特定の非対称暗号化鍵を選択的に使用して、対称暗号化鍵ストリームを暗号化するよう指示するものであることを特徴とする暗号化コンピュータシステム。
【請求項２０】
請求項１９に記載の暗号化コンピュータシステムであって、汎用処理ユニットに指示を与えるための指示を含むコンピュータ読み取り可能な記憶媒体に格納された、コンピュータ読み取り可能な指示をさらに含み、この指示は汎用処理ユニットに対して、
ｃ．暗号化データのシーケンシャル部分を含む第二暗号化データストリームを生成するため、第二データストリームの各シーケンシャル部分を暗号化する、第二の複数の異なる対称暗号化鍵を含む、第二の対称暗号化鍵ストリームを鍵ジェネレータから得るように指示し、
ｄ．少なくとも一つの公開非対称暗号化鍵の各々について、第二データストリームにアクセスするための許可と関連付けられているかどうかを決定するため、電子アクセス許可ディレクトリを調べるように指示し、少なくとも一つの公開非対称暗号化鍵の少なくとも一つの適切なサブセットが、第二データストリームにアクセスするための許可と関連付けられていることを決定するよう指示し、
ｅ．非対称的に暗号化された第二鍵ストリームを生成し、各々の非対称的に暗号化された第二鍵ストリームを生成するため、暗号化コンピュータシステムによって、適切なサブセット内の公開非対称暗号化鍵のみで、第二対称暗号化鍵ストリームをデジタル暗号化するように指示するものであり、その非対称的に暗号化された第二鍵ストリームの各々は、適切なサブセット内の公開非対称暗号化鍵のそれぞれで暗号化されており、非対称的に暗号化された鍵ストリームデータは、非対称的に暗号化された各々の第二鍵ストリームを含むことを特徴とする暗号化コンピュータシステム。
【請求項２１】
信頼できないネットワークを通じてストリーミングデータにアクセスする方法であって、
ａ．暗号化されたデータのシーケンシャル部分を含む、対称的に暗号化されたデータストリームをエージェントステーションで受信するステップを備え、
ｂ．公開鍵で暗号化された非対称的に暗号化された鍵ストリームをエージェントステーションで受信するステップを備え、その非対称的に暗号化された鍵ストリームは、データストリームの各シーケンシャル部分を対称的に暗号化されたデータストリームに暗号化する、複数の異なる対称暗号化鍵を含む、暗号化された対称暗号化鍵ストリームを含み、
ｃ．エージェントステーションで、複数の異なる対称暗号化鍵を含む、対称暗号化鍵ストリームを得るために、非対称的に暗号化された鍵ストリームを秘密鍵で復号するステップを備え、
ｄ．データストリームの少なくとも一部を得るために、複数の異なる対称暗号化鍵のそれぞれで暗号化データの各シーケンシャル部分を復号することによって、対称暗号化鍵ストリームを使用して、非対称的に暗号化されたデータストリームをエージェントステーションで復号するステップを備え、
ｅ．エージェントステーションで、データストリームの少なくとも一部を処理するステップを備えることを特徴とする方法。
【請求項２２】
請求項２１に記載の方法であって、
ａ．データストリームに対するリクエストを生成し、そのデータストリームに対するリクエストを信頼できないネットワークを通じて送信するステップをさらに備え、そのリクエストの送信に応じて、対称的に暗号化されたデータストリームをエージェントステーションで受信することを特徴とする方法。
【請求項２３】
請求項２２に記載の方法であって、リクエストを送信するということに、クラウドサーバーにリクエストを送信することを含むことを特徴とする方法。
【請求項２４】
請求項２１から２３のいずれかに記載の方法であって、非対称的に暗号化された鍵ストリームがサーバーから受信され、その方法が、非対称的に暗号化された鍵ストリームをエージェントステーションで受信する前に、公開鍵をサーバーに送信するステップをさらに備えることを特徴とする方法。
【請求項２５】
請求項２１から２４のいずれかに記載の方法であって、データストリームに含まれる情報をユーザーに提示するステップをさらに備えることを特徴とする方法。
【請求項２６】
請求項２５に記載の方法であって、データストリームに含まれる情報をユーザーに提示するステップが、ビデオストリームをデコードして表示することを含むことを特徴とする方法。
【請求項２７】
請求項２１から２６のいずれかに記載の方法であって、公開鍵が第一公開鍵であり、非対称的に暗号化された鍵ストリームが第一の非対称的に暗号化された鍵ストリームであり、その方法がさらに、
ａ．第三者エンティティに属する第三者の公開暗号鍵をエージェントステーションで受信するステップを備え、その第三者の公開暗号化鍵は、第三者によって秘密に所有される第三者の秘密鍵を含む、第三者の秘密―公開鍵のペアに属し、
ｂ．第二の非対称暗号化鍵ストリームを生成するため、第三者の公開鍵を使って、対称暗号化鍵ストリームの少なくとも一つのサブセットの非対称暗号化をエージェントステーションで実行するステップを備え、
ｃ．信頼できないネットワークを通じて、第二の非対称暗号化鍵ストリームを送信するステップを備えることを特徴とする方法。
【請求項２８】
請求項２７に記載の方法であって、第三者の公開鍵が第三者から受信され、第二の非対称暗号化が第三者に送信されることを特徴とする方法。
【請求項２９】
請求項２７に記載の方法であって、第三者の公開鍵がビデオ監視サーバーから受信され、第二の非対称暗号化がビデオ監視サーバーに送信されることを特徴とする方法。
【請求項３０】
請求項２７から２９のいずれかに記載の方法であって、第二の非対称暗号化鍵ストリームが、対称暗号化鍵ストリームに含まれる対称暗号化鍵の適切なサブセットのみを含むように、第三者の公開鍵を使って対称暗号化鍵ストリームの少なくとも一つのサブセットの非対称暗号化をエージェントステーションで実行するステップが、対称暗号化鍵ストリームの適切なサブセットについて実行されることを特徴とする方法。
【請求項３１】
請求項３０に記載の方法であって、第三者エンティティと関連付けられるアクセス許可を決定するステップと、そのアクセス許可に基づいて、対称暗号化鍵の適切なサブセットを決定するステップとをさらに備えることを特徴とする方法。
【請求項３２】
汎用処理ユニットに指示を与えるための指示を含む、コンピュータ読み取り可能な記憶媒体に格納された、コンピュータ読み取り可能な指示を含む、信頼できないネットワークを通じてストリーミングデータにアクセスするためのコンピュータシステムであって、その指示は汎用処理ユニットに対して、
ａ．暗号化データのシーケンシャル部分を含む、対称的に暗号化されたデータストリームをエージェントステーションで受信するように指示し、
ｂ．公開鍵で暗号化された非対称的に暗号化された暗号化鍵ストリームを、エージェントステーションで受信するように指示し、その非対称的に暗号化された鍵ストリームは、データストリームの各シーケンシャル部分を対称的に暗号化されたデータストリームに暗号化する、複数の異なる対称暗号化鍵を含む、暗号化された対称暗号化鍵ストリームを含み、
ｃ．複数の異なる対称暗号化鍵を含む対称暗号化鍵ストリームを得るために、非対称的に暗号化された鍵ストリームを秘密鍵で復号するように指示し、
ｄ．少なくともデータストリームの一部を得るために、複数の異なる対称暗号化鍵のそれぞれで、暗号化データの各シーケンシャル部分を復号することによって、対称暗号化鍵ストリームを使って、対称的に暗号化されたデータストリームを復号するように指示し、
ｅ．データストリームの少なくとも一部を処理するように指示するものであることを特徴とする方法。
【請求項３３】
請求項３２に記載のコンピュータシステムであって、汎用処理ユニットに指示を与えるための指示を含む、コンピュータ読み取り可能な記憶媒体に格納された、コンピュータ読み取り可能な指示をさらに含み、その指示は汎用処理ユニットに対して、
ａ．データストリームに対するリクエストを生成し、そのデータストリームに対するリクエストを信頼できないネットワークを通じて送信するように指示するものであり、そのリクエストの送信に応じて、対称的に暗号化されたデータストリームをエージェントステーションで受信することを特徴とするコンピュータシステム。
【請求項３４】
請求項３３に記載のコンピュータシステムであって、リクエストを送信するということに、クラウドサーバーにリクエストを送信することを含むことを特徴とするコンピュータシステム。
【請求項３５】
請求項３２から３４のいずれかに記載のコンピュータシステムであって、非対称的に暗号化された鍵ストリームがサーバーから受信され、そのコンピュータシステムが、サーバーに公開鍵を送信するように汎用処理ユニットに指示を与えるための指示を含む、コンピュータ読み取り可能な記憶媒体に格納された、コンピュータ読み取り可能な指示をさらに含むことを特徴とするコンピュータシステム。
【請求項３６】
請求項３２から３５のいずれかに記載のコンピュータシステムであって、データストリームの少なくとも一部を処理するということに、データストリームに含まれる情報をユーザーに提示することを含むことを特徴とするコンピュータシステム。
【請求項３７】
請求項３６に記載のコンピュータシステムであって、データストリームの少なくとも一部を処理するということに、ビデオストリームの表示をデコードすることと、ビデオストリームを表示させることとを含むことを特徴とするコンピュータシステム。
【請求項３８】
請求項３２から３６のいずれかに記載のコンピュータシステムであって、公開鍵が第一公開鍵であり、非対称的に暗号化された鍵ストリームが第一の非対称的に暗号化された鍵ストリームであり、コンピュータシステムが汎用処理ユニットに指示を与えるための指示を含む、コンピュータ読み取り可能な記憶媒体に格納された、コンピュータ読み取り可能な指示をさらに含み、その指示は汎用処理ユニットに対して、
ａ．第三者エンティティに属する第三者の公開暗号化鍵をエージェントステーションで受信するように指示し、その第三者の公開暗号化鍵は、第三者によって秘密に所有される第三者の秘密鍵を含む、第三者の秘密―公開鍵ペアに属し、
ｂ．第二の対称暗号化鍵ストリームを生成するため、対称暗号化鍵ストリームの少なくとも一つのサブセットの非対称暗号化を第三者の公開鍵を使ってエージェントステーションで実行するように指示し、
ｃ．信頼できないネットワークを通じて、第二の非対称暗号化鍵ストリームを送信するように指示するものであることを特徴とするコンピュータシステム。
【請求項３９】
請求項３８に記載のコンピュータシステムであって、第三者の公開鍵が第三者から受信され、第二の非対称暗号化が第三者に送信されることを特徴とするコンピュータシステム。
【請求項４０】
請求項３８に記載のコンピュータシステムであって、第三者の公開鍵がビデオ監視サーバーから受信され、第二の非対称暗号化がビデオ監視サーバーに送信されることを特徴とするコンピュータシステム。
【請求項４１】
請求項３８から４０のいずれかに記載のコンピュータシステムであって、第二の非対称暗号化鍵ストリームが、対称暗号化鍵ストリームに含まれる対称暗号化鍵の適切なサブセットのみを含むように、第三者の公開鍵を使用する対称暗号化鍵ストリームの少なくとも一つのサブセットの暗号化が、対称暗号化鍵ストリームの適切なサブセットについて実行されることを特徴とするコンピュータシステム。
【請求項４２】
請求項４１に記載のコンピュータシステムであって、汎用処理ユニットに指示を与えるための指示を含む、コンピュータ読み取り可能な記憶媒体に格納された、コンピュータ読み取り可能な指示をさらに含み、その指示は汎用処理ユニットに対して、第三者エンティティと関連付けられたアクセス許可を決定し、そのアクセス許可に基づいて対称暗号化鍵の適切なサブセットを決定するように指示するものであることを特徴とするコンピュータシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、２０１５年１１月２０日に出願した米国仮特許出願第６２／２５８，０２２号の優先権の利益を主張する。
【０００２】
本出願はネットワークインフラを通じたデータのストリーム（例えばセキュリティネットワークにおける映像やその他のストリーム）の分配に関する。本出願はさらに、データストリームの安全な保管と分配に関する。本出願はさらに、データストリームへのアクセスを制御することと、多数のデータストリームへの差別化されたアクセスを、多数のユーザーに提供することに関する。
【背景技術】
【０００３】
安全にデータストリームを分配するため、数多くの固有の挑戦がなされてきた。例えば、ビデオ監視フィードやソーシャルメディアフィードなどの大量のストリーミングデータを蓄積するシステムは、要求に応じてストリーミング用に保管および回収可能でなければならない大容量のデータを処理する必要がある。ストリーミングデータが極秘データである場合、とりわけ、ビデオ監視システムにおいては、これらの大容量のデータを非常に安全に保管しなければならず、不正アクセスは避けられなければならない。概して、データストリームは大きく、無限のデータセットである可能性さえある。データストリームは多くの場合、ストリームを同時に作り上げる要素に分割される。例えば、ビデオストリームはビデオフレームから作り上げることができる。これらの要素は多くの場合、長さに限りがあるが、データストリームのタイプに応じて、所定のサイズの要素または任意の（限りある）サイズの要素から作り上げられる可能性がある。
【０００４】
データストリームの分配に固有の挑戦は、データのストリーム内に埋め込まれた個人情報（ＰＩＩ）に対していかに捜査官によりアクセスされ、共有され、用いられ、保持されるかということについて、感度を高めることによってさらに加速される。捜査官は、データストリーム（例えば、警察官、検察官、警備業務や民兵組織の一員、警備会社、私立探偵、法医学検査または監査ができるよう契約が結ばれたベンダー、犯罪アナリスト、マーケティングまたはビジネス情報アナリスト、捜査官の役割を果たす自動システムなど）のコンテンツ、情報およびそれらを組み合わせたものを調べることに興味を抱く一人のユーザーである。米国国務省のＮＩＳＴ（特殊出版８００−１２２）によると、ＰＩＩは「個人についてのすべての情報・・・（１）個人の身元を識別したり追跡したりするために用いることのできる、すべての情報や・・・（２）個人にリンクされたりリンク可能なその他のすべての情報を含む・・・リンクされた情報は、個人の、または個人に関連するリンクされた情報は、個人についての情報であり、これは他の個人についての情報と論理的に関連付けられる。これとは対照的に、リンク可能な情報は、個人のまたは個人に関連する情報であり、個人についての他の情報と論理的関係にある可能性がある」。
【０００５】
データストリームの分配に固有の、データ管理の挑戦は、ＰＩＩが発信元の団体によって獲得されて、データストリームに含まれる情報、またはデータストリームについての情報の集約、合成および理解のために１人以上の第三者のアグリゲーターに供給される状況において、さらに深刻になる可能性がある。例として、発信元はソーシャルメディアのサービスのプロバイダや小売商となる可能性があり、それらのクライアントの特定のＰＩＩが、合法的に必要な場合にのみ、捜査官によってアクセスされるということが保証されることに興味を持つ可能性がある。
【０００６】
実際的には、このことが概して意味するのは、データストリームのシステムを有するために、ストリームデータを安全に保管することのできるデータセンターを有することも必要であり、そこからストリームデータへのアクセスを確実に制御することが可能であることが必要である。ビデオ監視システムにおいて、これが意味するのは、ビデオストリームや他の監視データがデータの所有者の管理下である現場か、または安全な場所に保管されるということである。これは監視システムを購入した者にとって極めて面倒となり得る。例えば住宅所有者や小企業のオーナーなどの小規模の購入者は、セキュリティカメラのネットワークを持ちたいかもしれないが、必ずしも監視だけのためにデータセンターをセットアップし、所有し、維持するための負担まで負いたいわけではないかもしれない。そのうえ、データを安全なものとするには、それのリダンダントコピーを有することが望ましいが、単一の場所の顧客にとってはそれが困難となり得る。多数のカメラや他のデータ源を有する、例えば広範囲にわたる広域施設などの大企業のような、広大なセキュリティシステムネットワークの所有者は、データセンターを稼働させるために技術スタッフを雇うかもしれない。しかしながら、さらに大きな監視装置のネットワーク（または他のデータストリーミング源）となると、データ量が非常に大きくなり、今度は非常に巨大で高価なデータセンターが必要となる。
【０００７】
クラウドコンピューティングの出現により、データストレージとデータアクセスのための拡張可能な解決策がもたらされた。クラウドコンピューティングサービスは、小容量または大容量のデータを格納する能力と、オンラインでのストリーミングアクセスとを提供する。さらに、クラウドコンピューティングは、津波や停電、自然災害などからデータストレージに影響を与え得る問題に対する、堅固な復元力を確保するために不必要な安全対策を提供することができる。クラウドコンピューティングは自己運営されるデータセンターにとって魅力的な代替手段を提示する。これにより購入者は信頼性でき、拡張性があり、非常に豊富なストレージを入手することができるようになり、これは２４時間年中無休でアクセス可能である。
【０００８】
しかしながら、クラウドコンピューティングは信用問題に悩まされている。特にクラウドコンピューティングでは、第三者からオンデマンドサービスを購入することを含むのが通常であるが、これは、一定の安全を保証することはできるものの、結局のところ、購入者がその制御をすることはできない。セキュリティカメラからのビデオストリームや他のセキュリティ関連のデータなどの極秘データについては、組織の完全性の核心部である可能性があり、ストレージのために外部のサービスを利用するには抵抗がある。他の懸念事項の中でも、ハッカーや司法管轄外のアクセスに対する脆弱性が、一定の産業におけるストリーミングデータのストレージに、クラウドコンピューティングを採用することを思いとどまらせてきた。
【０００９】
アクセス制御は、ストリーミングデータ管理、とりわけビデオ監視データ管理に直面するもう一つの課題である。例えば、ビデオ監視システムにおいて、警備員が特定のカメラからビデオフィードにアクセスすることはできるが、一方で例えば、より機密性の高いエリアにおいて、他のカメラのフィードを、ユーザーの一部を除くすべてのユーザーがアクセスできない状態にしておくことが望ましい場合がある。
【００１０】
同様に、例えば法的な理由により監視されない可能性のあるエリアが存在する場合があるが、そこでは例えば令状により特定の条件下で監視データが使用される可能性がある。例えば、管轄区域によっては、公共の場や他の個人的な施設をフィルムに収めることが違法となる可能性がある。しかしながら、窃盗犯が公共の場や個人的な施設からやってくる可能性のある場所で窃盗が起きた場合、捜査官が合法的にその場所のビデオを見直すことができれば、捜査官にその場所のビデオを提供できるようにすることが望ましいであろう。
【００１１】
例えばオンラインビデオコンテンツのストリーミングサービスなどの、多くの集中型のストリーミングサービスは、中央サービスが信頼されて、エンドユーザーのステーションは信頼されていないという原則に基づいて運営している。
【００１２】
現在、当業者に知られている保障手段とアーキテクチャとは、概してセッションに基づくものである。そのようなシステムの一例が図１に示されている。ストレージサービス内のそのような補償についての重大な責任は、アカウントの検証とファイルサーバーコンポーネントとに置かれ、後者には、ファイルストレージサービスをさらに全体として脆弱にする、コンピュータによるオーバーヘッドの負担をかけている。さらに、アーカイブサーバーは、鍵や認証情報その他の保障スキームを管理するために作成されるのが通常であるが、大体のアクセス権を除くすべてをアーカイブされたコンテンツに付与することが多い。共有されるコンテンツに関する、より深い機密情報も同様に、より高度で微妙な共有の形式、制限および権利の管理を防止することに概して欠けている。
【発明の概要】
【００１３】
第一側面によると、信頼できないネットワークを通じたユーザーによるストリーミングデータへのアクセスを制御する方法を提供する。この方法は、信頼できるネットワーク領域において、暗号化データのシーケンシャル部分を含む、第一の対称的に暗号化されたデータストリームを生成するため、第一データストリームの各シーケンシャル部分を暗号化する、第一の複数の異なる対称暗号化鍵を含む第一対象暗号化鍵ストリームを、暗号化コンピュータシステムが鍵ジェネレータから得るステップを備える。この方法はさらに、信頼できるネットワーク領域において、信頼できないネットワークを通じて各リモートコンピュータシステムから少なくとも一つの公開非対称暗号化鍵を受信するステップを備える。この方法はさらに、信頼できるネットワーク領域において含む。この方法はさらに、信頼できるネットワーク領域で、それぞれの非対称的に暗号化された第一鍵ストリームを生成するため、少なくとも一つの公開非対称暗号化鍵のそれぞれを使用して、暗号化コンピュータシステムによって第一対称暗号化鍵ストリームをデジタル暗号化することによって、非対称的に暗号化された鍵ストリームデータを生成するステップを備え、非対称的に暗号化された第一鍵ストリームの各々が少なくとも一つの公開非対称暗号化鍵のそれぞれで暗号化され、その非対称的に暗号化された鍵ストリームデータが、非対称的に暗号化された第一鍵ストリームの各々を含む。この方法はさらに、信頼できるネットワーク領域で、暗号化コンピュータシステムから、信頼できないネットワークを通じて非対称的に暗号化された鍵ストリームデータを送信するステップを備える。
【００１４】
別の広い一側面によると、信頼できないネットワークを通じた、ユーザーによるストリーミングデータへのアクセスを制御するための、信頼できるネットワーク領域における操作のための暗号化コンピュータシステムが提供される。この暗号化コンピュータシステムは、汎用処理ユニットに指示を与えるための指示を含む、コンピュータ読み取り可能な記憶媒体に格納された、コンピュータ読み取り可能な指示を含む。この指示は汎用処理ユニットに対して、暗号化データのシーケンシャル部分を含む第一暗号化データストリームを生成するため、第一データストリームの各シーケンシャル部分を暗号化する、第一の複数の異なる対称暗号化鍵を含む、第一対称暗号化鍵ストリームを鍵ジェネレータから入手するように指示するものである。その暗号化コンピュータシステムはまた、汎用処理ユニットに指示を与えるための指示を含む、コンピュータ読み取り可能な記憶媒体に格納された、コンピュータ読み取り可能な指示を含む。この指示は汎用処理ユニットに対して、信頼できないネットワークを通じて各々のリモートコンピュータシステムから少なくとも一つの公開非対称暗号化鍵を受信するように指示する。その暗号化コンピュータシステムはまた、汎用処理ユニットに指示を与えるための指示を含む、コンピュータ読み取り可能な記憶媒体に格納された、コンピュータ読み取り可能な指示を含む。この指示は汎用処理ユニットに対して、各々の非対称的に暗号化された第一鍵ストリームを生成するため、少なくとも一つの公開非対称暗号化鍵のそれぞれを使用して第一対称暗号化鍵ストリームを、デジタル暗号化することによって、非対称的に暗号化された鍵ストリームデータを生成するように指示するものであり、非対称的に暗号化された第一鍵ストリームのそれぞれが、少なくとも一つの公開非対称暗号化鍵のそれぞれで暗号化されており、非対称的に暗号化された鍵ストリームデータは、非対称的に暗号化された第一鍵ストリームのそれぞれを含む。その暗号化コンピュータシステムはまた、汎用処理ユニットに指示を与えるための指示を含む、コンピュータ読み取り可能な記憶媒体に格納された、コンピュータ読み取り可能な指示を含む。この指示は汎用処理ユニットに対して、非対称的に暗号化された鍵ストリームデータを信頼できないネットワークを通じて送信するよう指示する。
【００１５】
他の広い一側面によると、信頼できないネットワークを通じた、ストリーミングデータにアクセスする方法が提供される。この方法は、暗号化データのシーケンシャル部分を含む、対称的に暗号化されたデータストリームをエージェントステーションで受信するステップを備える。この方法はさらに、公開鍵で暗号化された、非対称的に暗号化された鍵ストリームをエージェントステーションで、受信するステップを備える。その非対称的に暗号化された鍵ストリームは、データストリームの各シーケンシャル部分を、対称的に暗号化されたデータストリームに暗号化する、複数の異なる暗号化鍵を含む、暗号化された対称暗号化鍵ストリームを含む。この方法はさらに、複数の異なる対称暗号化鍵を含む、対称暗号化鍵ストリームを得るために、エージェントステーションにおいて、非対称的に暗号化された鍵ストリームを秘密鍵で復号するステップを備える。この方法はさらに、データストリームの少なくとも一部を得るために、複数の異なる対称暗号化鍵のそれぞれで、暗号化データの各シーケンシャル部分を復号することによって、対称暗号化鍵ストリームを使用して、対称的に暗号化されたデータストリームをエージェントステーションで復号するステップを備える。この方法はさらに、エージェントステーションで、少なくともデータストリームの一部を処理するステップを備える。
【００１６】
他の広い一側面によると、汎用処理ユニットに指示を与えるための指示を含む、コンピュータ読み取り可能な記憶媒体に格納された、コンピュータ読み取り可能な指示を含む、信頼できないネットワークを通じてストリーミングデータにアクセスするためのコンピュータシステムが提供される。その指示は汎用処理ユニットに対して、暗号化データのシーケンシャル部分を含む、対称的に暗号化されたデータストリームをエージェントステーションで受信するように指示するものである。このコンピュータシステムはさらに、汎用処理ユニットに指示を与えるための指示を含む、コンピュータ読み取り可能な記憶媒体に格納された、コンピュータ読み取り可能な指示を含み、その指示は汎用処理ユニットに対して、公開鍵で暗号化された非対称的に暗号化された鍵ストリームをエージェントステーションで受信するように指示するものであり、その非対称的に暗号化された鍵ストリームは、データストリームの各シーケンシャル部分を、対称的に暗号化されたデータストリームに暗号化する、複数の異なる対称暗号化鍵を含む、暗号化された対称暗号化鍵ストリームを含む。このコンピュータシステムはさらに、汎用処理ユニットに指示を与えるための指示を含む、コンピュータ読み取り可能な記憶媒体に格納された、コンピュータ読み取り可能な指示を含み、その指示は汎用処理ユニットに対して、複数の異なる対称暗号化鍵を含む、対称暗号化鍵ストリームを得るために、非対称的に暗号化された鍵ストリームを秘密鍵で復号するように指示するものである。このコンピュータシステムはさらに、汎用処理ユニットに指示を与えるための指示を含む、コンピュータ読み取り可能な記憶媒体に格納された、コンピュータ読み取り可能な指示を含み、その指示は汎用処理ユニットに対して、少なくともデータストリームの一部を得るために、複数の異なる対称暗号化鍵のそれぞれで、暗号化データの各シーケンシャル部分を復号することによって、対称暗号化鍵ストリームを使って、対称的に暗号化されたデータストリームを復号するように指示するものである。このコンピュータシステムはさらに、汎用処理ユニットに指示を与えるための指示を含む、コンピュータ読み取り可能な記憶媒体に格納された、コンピュータ読み取り可能な指示を含み、その指示は汎用処理ユニットに対して、データストリームの少なくとも一部を処理するよう指示するものである。
【図面の簡単な説明】
【００１７】
本発明は、添付の図面を参照しつつ以下の発明の実施例の詳細な説明により、よりよく理解することができる。
【００１８】
【図１】図１は通信システムに基づく先行技術のセッションのブロック図を示す。
【図２ａ】図２ａは限定されない例による、カメラによって監視されるセキュリティ監視エリアの概念図を示す。
【図２ｂ】図２ｂは図２ａのエリアの監視区域の概念図を示す。
【図３】図３は限定されない例による、ビデオ監視システムを説明するブロック図を示す。
【図４】図４は限定されない例による、図３のシステムと関連して使用されるブロック図を示す。
【図５】図５は限定されない例による、許可テーブルの概念図である。
【図６】図６は限定されない例による、図３のシステムの別のブロック図である。
【図７】図７は限定されない例による、図３のシステムと関連する信頼できるネットワーク領域のブロック図である。
【図８】図８は限定されない例による、図３のシステムと関連するユーザーシステムのブロック図である。
【図９】図９は限定されない例による、ビデオ監視システムを説明するブロック図である。
【図１０】図１０は交換されるデータを示すビデオ監視システムのブロック図である。
【図１１】図１１は限定されない例による、ストリームのブロック図である。
【図１２】図１２は視聴許可が与えられた部分と視聴許可が与えられなかった部分とのビデオシーケンスの概念図である。
【図１３ａ】図１３ａは視聴許可が与えられなかったセクションを含むリッチテキストファイルの説明図である。
【図１３ｂ】図１３ｂは図１３ａの許可が与えられたリッチテキストファイルの説明図である。
【発明を実施するための形態】
【００１９】
図２ａと図２ｂは、ビデオ監視ネットワークが稼働する場所の施設２５を概念的に説明している。ビデオ監視ネットワークは、複数のデータストリーム源５０を備え、この例においては、施設２５内の様々な場所にビデオ監視カメラが設置されている。このような監視は、例えば監視や、一定の領域を保護することに関連する理由や、所定の区切られた場所で起こる出来事をアーカイブするため、またはその他の目的などの様々な理由で望ましい場合がある。概して監視は、セキュリティカメラや他のストリーミング信号を生成させることのできる装置などのストリーム源５０に端を発する。各ストリーム源５０は一つ以上のストリームをキャプチャすることができる。ビデオデータのほかに、データソース５０はオーディオデータなどの他のタイプのデータを提供することができる。ストリーミングデータは、適切なフォーマットに従ってデータストリームを構成する。動画専門家集団（ＭＰＥＧ）はビデオ／オーディオストリームのいくつかのフォーマットを特定し、それらの多くがビデオ監視によく用いられている。生の画像データやサンプリングされた音声データはビットストリームにおいてストリームすることも可能であるが、これはさらに大きな帯域幅を必要とする。
【００２０】
他のタイプのデータ源は、異なるタイプのデータを提供することもできる。例えばビデオストリームは、出力の際にビデオに視覚的に重ね合わせるための追加の情報を提供する、オーバーレイストリームを伴うこともできる。このオーバーレイは、元となるビデオ（例えばそれらが機密情報を含む場合）とは、異なる許可レベルで関連付けすることができる。他のタイプのストリームは、（例えば移動する車両またはカメラの場所に対応する）ＧＰＳ座標、ビデオマスキングオーバーレイ、（例えば音声をテキスト化した）字幕または他のテキストキャプションなどの位置ストリーム、モーションセンサーによってキャプチャされたモーションレベル、マイクロホンによりキャプチャされたオーディオレベル、（例えばドアが開いたことや動いたことの検出などのアクセス制御イベントのストリーム、またはビデオ解析イベントのストリームなどの）イベントストリーム、ナンバープレートリーダーによって（例えば交通カメラから）読み取られるナンバープレートなどを含むことができる。これらのいずれのタイプのデータに関しても、時間またはシーケンスにおける特定の位置と関係するフレームとして機能する、データを格納するための構造を設計することによって、ストリームを形成することができる。その結果、例えば時間の経過とともに連続的にネットワークを通じてストリームとして転送され、フレームに順番にアクセスすることができる。
【００２１】
このストリームは、一連のフレームを含むファイルとして格納され、例えば現在の再生時間Ｔｘに従って、連続して読み込まれてもよい。一実施例として、各ストリームの各フレームを、異なるストリームを同期させるために用いることのできる特定のタイムスタンプと関連付けてもよい。例えば、メモリから読み取られる一つ以上のストリームに対して、ストリームの同期された部分を経時的に探すため、異なるストリーム間で使用することのできる再生時間に従って、アクセスすることができる。同様に、ネットワークを通じてストリーミングされ、ネットワークインターフェースで受信されるストリームが、共通の再生時間Ｔｘに従ってバッファリングされたり再生されたりしてもよい。再生されるストリームの一つのフレームが利用できないことにより、すべてのストリームに影響を与える可能性のあるバッファリングを引き起こす可能性があり、またはそのストリームが単独でバッファされる可能性があり、バッファされる場合、他のものに追い付こうと前方にシークする。ストレージがアクセスできるところに格納されたストリームの場合、再生時間Ｔｘを変更するためにストリーム内を前方または後方にシークすることができる。多重ストリームを同期させるための他の機構を用いることもできる。
【００２２】
コンピュータファイル全体のようなコンテンツを参照すると、データストリームが有限である場合がある。あるいは、そのデータストリームが、ライブの監視カメラからキャプチャされたビデオのように無限であるか、または不特定の継続時間を有する可能性がある。通常、このようなストリームは、例えば一定時間（例えば３０分）または一定のデータ量（パケット数またはバイト数など）に対応するファイル中に、アーカイブにおける複数のファイルとして格納することができる。概して本実施例では、データ源はキャプチャ機器に由来し、データ消費はリモートのワークステーションで発生する。しかしながら、別の実施例として、データストリームはワークステーションで一人以上のユーザーまたは購読者によって提供されてもよい。このような場合、ユーザーまたは購読者とそれらのワークステーションは、データ源の役割を果たすことができる。これらのワークステーションは、例えば安全な施設内の物理的に信頼できるチャネルを通したり、安全な暗号化されたウェブアップロードポータルを介したり、または暗号化された第三のファイル転送アプリケーションを経由したりするなど、そうするために適切なインターフェース手段を使ってデータストリームの発信元となるか、またはストリームを生成した実際の送信元から受信し、ワークステーションに提供した可能性がある。
【００２３】
一つ以上のストリームがネットワークを通すなどの、任意の適切な手段によって実施例にアップロードまたは転送されてもよい。このストリームやこのストリームの一部は、単一の受信者またはユーザー／購読者を対象としたり、特定のユーザー／購読者のセットを対象としたりすることができる。別の実施例として、ユーザーが（１）ストリーム、（２）そのストリームの任意の部分または（３）ストリームについての情報、およびそのような（時間制限などの）アクセスを管理している追加的な条件または制限にアクセスすることができるといったような詳細について管理するため、許可マネジメントの機構をユーザー／購読者のインターフェース内に実装することができる。一実施例として、各ストリームまたはその任意の部分に対するユーザーのアクセス／許可リストは、ユーザー／購読者インターフェース内で、それぞれのストリームおよびその中のストリームの任意の組み合わせを特定されてもよい。他の実施例として、ユーザー／購読者は、概して所有者の権限を有する最初のアップローダーまたは団体によって、ストリームを特定のストリームを通じて中央システムまたは他のユーザーが許可した権限を有する者に転送することができる。同様に、アクセス／許可などを修正することができ、それに応じてフィードの暗号化ポリシーおよびその後の各ストリームのフィードのアクセスのしやすさに影響を与える可能性がある。これについては後でさらに論じる。
【００２４】
データストリームの送信中のセキュリティは、インテグリティへの不正アクセスや、ストリーミングのアップロードまたは転送のプロセス途中でのストリームへのアクセスを避けるために重要であり、これについてはさらに後述する。データ源５０は、様々な実施例について論じるように、ビデオ／データのストリームの生成についての、ひとつの基礎としての役割を有する。ビデオ／データのストリームの生成は、任意のストリーム源５０から生まれるデータストリームを参照することができる。また、その生成は同様に、任意の特定のビデオまたはその他の編集工程、後工程、強化またはその他の操作に続くストリームの結果を包含してもよい。
【００２５】
図３は特定の実施例による、ビデオ監視システム１０を説明するブロック図である。信頼できるネットワーク領域２０は、暗号化コンピュータシステム３０を備える。この暗号化コンピュータシステム３０は、例えばビデオ監視サーバーなどのサーバーに含むことができる。この特定の例では、信頼できるネットワーク領域２０は、不正アクセスを妨げるように制御される、信頼できる接続またはアクセスを通じて通信する、ルーターやコンピュータデバイスなどの相互接続されたネットワーク構成要素を備える。信頼できるネットワーク領域におけるネットワーク構成要素は、信頼できる構成要素とすることができ、ここから得られるデータは本物でありかつ悪意の無いデータとして信頼することができる。信頼できるネットワーク領域。具体的には、この例における信頼できるネットワーク領域２０は、顧客の施設４０にあるローカルエリアネットワークの一部であり、これは信頼できるネットワーク領域を信頼できないネットワーク領域７５またはネットワークエリア７５から分離する非武装地帯（ＤＭＺ）３５によって保護されており、この実施例ではラージ４５でのインターネットである。概して言えば、信頼できるネットワーク領域は、データハッキングなどの悪意あるアクティビティの源でないと信頼することのできる機器を備えることができ、それらの間の接続は安全であるとして信頼することができる。信頼できる機器は、制御される場所や、（例えばコンピュータの場合）そこで稼働しているソフトウェアを通じた制御や、（例えばＩＰカメラの場合）既知の起源または構成を有すること等を理由として信頼することができる。また、信頼できる接続は、制御エリア（例えば顧客の施設４０）において物理的に統合されたり、暗号化によって安全にされたり、トンネリング（例えばＶＰＮ）などを理由として、信頼することができる。
【００２６】
この特定の場合において、ここではカメラ６０であるストリーミングデータ源もまた、信頼できるネットワーク領域２０に配置されており、暗号化コンピュータシステム３０と通信できるように接続されている。暗号化コンピュータシステム３０とカメラ６０との間に直接接続が示されているが、この接続は実際にはパケット交換方式のネットワークを経由するネットワーク（例えばＬＡＮやＷＡＮ）とすることができる。
【００２７】
この特定の例において、暗号化コンピュータシステム３０は、セキュリティサーバーとして動作し、セキュリティサービスソフトウェアを実施するコンピュータステーションを備える。これは、様々なデータ源５０からストリーミングデータへアクセスするためのユーザー許可だけでなく、様々なデータ源５０からデータストリームを管理している。
【００２８】
様々なデータ源５０に由来するストリームデータは、鍵暗号化システムを使って暗号化される。より具体的には、ストリームデータは、一定期間にわたって連続的に提供される、複数の異なる暗号化鍵を含む鍵ストリームを使って暗号化される。この実施例では、ストリームデータは、対称な暗号化鍵のストリームである対称暗号化鍵ストリームを使用して対称的に暗号化される。この鍵ストリームは、例えば無作為に生成される新しい鍵の、非循環の鍵ストリームとすることができる。データストリームは、データストリームの部分に分割することができ、この部分は予め設定したり、または任意ではあるが有限の長さに（例えば、ビデオストリームのためのビデオフレームの数）したりすることができる。各部分は個別の無作為の対称鍵によって暗号化されてもよい。データストリームを暗号化する対象鍵のシーケンスが、鍵ストリームを構成してもよい。
【００２９】
そのように暗号化されたストリームデータは、暗号化コンピュータシステム３０に格納されてもよいが、この特定の実施例では、そのストリームデータが暗号化された後に、インターネット４５を通じて送信されて、ビデオアーカイブサーバー７０に格納される。このビデオアーカイブサーバーは、任意の適切なデータサーバー／ストレージであってもよく、信頼できても信頼できなくてもよい。このビデオアーカイブサーバー７０はここでは単一の個別の機器として示しているが、これは単にこの実施例のビデオアーカイブサーバーとしての説明を簡単にするためであり、これは実際には未知の場所で、リダンダントコピーとともにサーバーのネットワークを通じて格納データを分配することのできる、購入されたクラウドサーバーサービスを使って実装される。この実施例のビデオアーカイブサーバー７０は、制御の範囲内にないため、信頼することができないと考えられる。それは実際には顧客の施設の外側にあり、出所不明のソフトウェアを実行し、データセキュリティと完全性測定とを顧客の制御の範囲外に有し、顧客が制御できない接続を通じて通信する。
【００３０】
本明細書でより詳細に説明するように、例えばストリームデータの安全な通信やストレージを提供したり、権限を与えられたエージェントのみにアクセスを制限したりするなど、ストリームデータへのアクセスを制御するために、鍵ストリームそれ自体が暗号化される。より具体的には、ストリームデータへのアクセスは、非対称暗号化の公開鍵―秘密鍵のペアにおいてとりわけ公開鍵と関連付けられたエンティティに限定される。当のエンティティは、ユーザーまたは特定のワークステーションのような、任意の種類のエージェントであってもよい。本実施例では、データ源５０からストリームデータにアクセスすることのできる複数のエージェントワークステーション６５が存在する。しかし、これらはストリームデータの異なる部分にアクセスできるようにする、異なるアクセス権限をそれぞれ有することができる。各エージェントワークステーション６５は、それぞれの公開鍵ペアを有し、第三者がエージェントワークステーション６５で秘密鍵を使用し、復号可能な方法でデータを暗号化させられるようにする。
【００３１】
この実施例では、各公開鍵は、特定のデータアクセス許可を有するエンティティ（この例ではエージェントワークステーションであるが、公開鍵は秘密鍵を通じて適切なユーザークセス制御を使用し、特定のユーザーとより具体的に関連付けられてもよい）と関連付けられる。各エンティティは、例えば特定のデータ源５０から提供するストリームデータなどの、特定のストリームデータにアクセスする権限を有する。また、その各エンティティは暗号化コンピュータシステム３０にそれらの公開鍵を提供することができ、その後、暗号化コンピュータシステム３０は、特定のストリームデータが公開鍵で暗号化されたもので鍵ストリームを暗号化し、非対称に暗号化された鍵ストリームを生成することができる。この非対称に暗号化されたデータストリームは、ビデオアーカイブサーバー７０、または暗号化コンピュータシステム３０などの他の場所にも格納することもできる。
【００３２】
図４は本実施例におけるデータ１００の機構を説明するブロック図である。この実施例では、概してデータ源５０からのストリームデータに関連するデータ１００と、ストリームデータが暗号化された暗号化鍵に関連するデータとが存在する。
【００３３】
データストリーム１０５は特定のデータ源５０からのストリームデータを含むことができる。この特定の実施例では、データストリーム１０５は特定の監視カメラからのビデオデータを含む。データストリーム１０５は、暗号化コンピュータシステム３０で鍵ストリームを使用して暗号化されてもよい。この実施例では、そのように暗号化されたデータストリームが複数存在するため、データストリーム１０５は暗号化される第一のデータストリームである。別の実施例として、ストリーム形式で結合された場合、データストリームが複数のデータ源５０からのデータを含むことができる。同様に、単一のデータ源５０は例えばビデオ（ＭＰＥＧ−４，  ＨＥＶＣ等）の多重エンコーディングなどのデータの多重ストリーム、または多数のセンサーからの出力ストリームを提供することができる。
【００３４】
ストリームデータ１０５は対応する第一鍵ストリーム、特に、異なる対称暗号化鍵を含む第一対称暗号化鍵ストリーム１１０を使って暗号化される。この異なる対称暗号化鍵はデータストリーム１０５の各部分、概して連続する部分、特に時間的な連続（例えば特定の時間の連続部分からのビデオフィード）またはデータの連続（例えばデータストリームの一連の連続バイト）に対応する。この実施例では、データストリーム１０５は複数のシーケンシャル部分で定義することができるストリームデータを含み、その各々は、第一対称暗号化鍵ストリームの異なる暗号化鍵の異なる一つで暗号化される。概して、シーケンシャル部分はキャプチャ時間に従って配列されてもよいが、別の面では、例えば送信時間に従って配列され、キャプチャ時間とは異なる順番にするのであれば、例えばアプリケーションのパケット層や他のパケット層に従って配列するなど、データの他の論理構成に従って配列することができる。
【００３５】
第一データストリーム１０５は、第一の対称暗号化鍵ストリーム１１０の異なる対称暗号化鍵のそれぞれでデジタル暗号化されることにより、第一の対称暗号化鍵ストリーム１１０を使って暗号化され、第一の対称的に暗号化されたデータストリーム１１５を生成するための第一データストリーム１０５の各シーケンシャル部分を・・・。第一の対称暗号化されたデータストリーム１１５は、このように第一対称暗号化鍵ストリーム１１０における対称暗号化鍵のシーケンスを使って、対称的に暗号化される。第一の対称暗号化データストリーム１１５は暗号化データのシーケンシャル部分を含む。これらの部分は、必ずしも順番に組織されているわけではないが、この実施例では、それらは第一データストリーム１０５のシーケンシャル部分の暗号化バージョンを含み、各々は第一対称暗号化鍵ストリーム１１０からの異なる暗号化鍵で暗号化されている。
【００３６】
特定の一実施例として、第一対称暗号化データストリーム１１５は、リアルタイムトランスポートプロトコル（ＲＴＰ）を使って転送される、Ｈ．２６４でエンコードされたビデオを含むビデオストリームである。このＲＴＰストリームは、暗号化されていないヘッダとペイロードとを含むＲＴＰパケットに分割される。このビデオデータの場合、とりわけＨ．２６４ビデオフレームの場合、ペイロードはストリームされるデータを含む。特にこの実施例では、ペイロードが一つ以上の、概してＩフレームで始まるいくつかのＨ．２６４ビデオフレームを含み、前のＲＴＰパケットにおけるデータから独立してデコーディングできるようにしている。好都合なことに、ユーザーに許可されたストリームへのアクセスは、一つ以上のＲＴＰパケットに限定されてもよく、これは独立してデコードすることができる。Ｈ．２６４フレーム全体が暗号化されており、復号鍵を持たないエンティティがＲＴＰペイロードのコンテンツを使用できないようにしている。
【００３７】
この実施例では、ＲＴＰパケットのヘッダは、コンテンツストリームに属する時間を表示するタイムスタンプを含む、いくつかのフィールドと、ペイロードタイプ（ここではペイロードがＨ．２６４ビデオであることを示す）と、データストリームを鍵ストリームに同期させるために使用する鍵インデックス（ＭＫＩ）とを含む。ヘッダに格納することのできる他のデータとしては、ストリームが表すもの（例えば「カメラ１のビデオストリーム」や「１階廊下」など）を慣習に従って識別するストリーム識別子を含む。
【００３８】
この実施例では、音声データは映像データとは別々に暗号化され、別個のＲＴＰストリームに送信される。これにより、音声と映像について異なる許可レベルを設定することが容易となる。例えば、場合によっては、コントロールセンター内の警備員はカンファレンスルームからの映像データを視ることはできるが、カンファレンスルームで進行中の議論を伝達する音声データを聞くための許可を有さなくてもよい。しかしながらその代わりに、ＲＴＰストリームは、そのペイロードにおける結合（例えば映像＋音声）ストリームの多重ストリームまたは多重部分を結合させることができる。
【００３９】
第一対称暗号化データストリーム１１５などの他のデータストリームは、上記の方法で共存することができ、または他のプロトコルに従って送信されてもよい。
【００４０】
この実施例では、リアルタイムストリーミングプロトコル（ＲＴＳＰ）を使ってＲＴＰストリームを管理する。
【００４１】
上記の通り、この特定の実施例では、Ｈ．２６４（または他のタイプのストリーム）が暗号化され、ＲＴＰパケットのペイロード部分に伝送される。また上記の通り、その暗号化は変化する対称鍵に従って実行される。特にこの実施例では、各ＲＴＰパケットのペイロードは、単一鍵で暗号化されたデータを含む。多重ＲＴＰパケットは特定の鍵をシェアすることができる（必要に応じて、ＲＴＰパケットと鍵との間の関係が１：１である場合がある）が、この例では、ＲＴＰパケットのコンテンツは単一鍵で暗号化されたものから、ペイロードの途中で別の鍵で暗号化されたものに転換することはない。したがって、ＲＴＰパケットのヘッダのＭＫＩ（鍵インデックス）フィールドは、鍵ストリームからの単一鍵を示すのみである。このように、この実施例では、復号鍵へのアクセスを許可することによって、ストリームの一部へのアクセスが少なくとも一部に提供されている。このため、一つ以上の鍵によって暗号化されたストリームの一部へのアクセスが許可され、この実施例ではこれらの部分は、ＲＴＰパケット全体のうちの有限のパケット数を示す。暗号化鍵を変える頻度（例えば時間やパケット数またはフレーム数などのデータ量に基づいて）（例えば３０秒ごとに、または９００フレームごとに）を選択することにより、特定の鍵によってアクセス可能なデータストリームの量に影響を与え、この実施例では、ＲＴＰパケット内に含まれ得る最小のデータストリーム量を生成する。
【００４２】
鍵の変更頻度の独立性とＲＴＰパケット編成とを支えるため、ＲＴＰパケットと併せて、他の鍵（例えば他の鍵インデックスなど）に関する付加的な情報と、ペイロードデータにおいて一つの鍵から次に移行する点がどこであるかの表示とを提供することができる。
【００４３】
現在、ビデオ監視システムは多重データ源５０と、多重データストリームを処理する暗号化コンピュータシステム３０とを有する。データストリームは許可レベルによって体系化することができる。特定の一実施例として、ひとつの特定の許可グループ内のすべてのデータストリームを、同じ暗号化鍵ストリームを使ってそれぞれ暗号化するとともに、データストリームが許可グループに従って分類される。このことは、それらが必ず同時に暗号化されるということを意味するのではなく、むしろ、それらが同じ暗号化鍵で個別に暗号化されてもよいということを意味する（許可グループにおいて個別のストレージを許可し、異なる暗号化データストリームへのアクセスを許可する）。しかしながら本実施例では、すべてのデータストリームが異なる各々の暗号化鍵ストリームで暗号化される。
【００４４】
暗号化コンピュータシステム３０は、エンティティとデータストリームへのアクセスとの間の関連付けを格納する、電子アクセスの許可ディレクトリにアクセスすることができる。本実施例では、電子アクセス許可ディレクトリは、図５に示すように、暗号化コンピュータシステム３０のコンピュータ読み取り可能なストレージに格納された、許可ディレクトリ８０の表である。この表のリンクは、システム１０における各データストリームに対するエントリと、各データストリームに対するエンティティ値のリストとを含む。このエンティティ値は、各データストリームへのアクセス権を有するエンティティであることを示す。この特定の実施例では、アクセス可能な、すなわち読み取りアクセス可能な一つのタイプのみ存在する。しかしながら、別の実施例では、そのディレクトリが各データストリームに対する各エンティティのアクセスが許可されるタイプの表示を含むことができる。例えば、その表は各データストリームのエントリについて、読み取りアクセス、上書きアクセスおよび削除アクセスのそれぞれに関するエンティティ値のリストを含むことができる。
【００４５】
本実施例では、エンティティはそれらの公開鍵によってディレクトリに示される。したがって、エンティティを表すエンティティ値は公開鍵であり、対称暗号化鍵ストリームはその公開鍵で暗号化されて、エンティティに対応するデータストリームへのアクセスを提供する。別の実施例として、顧客のワークステーション６５のユーザーＩＤやＩＰアドレスなどの他の識別子を使用することができる。このような場合、ディレクトリは各識別子について公開鍵を格納するためのエントリも同様に含み、対称暗号化鍵ストリームを暗号化するのに使用される公開鍵を、暗号化コンピュータシステム３０が発見して入手できるようにする。
【００４６】
本実施例では、公開鍵が、対応するデータストリームの全部または一部にアクセスする許可と紐付けられている場合、暗号化コンピュータシステム３０は、特定の公開鍵で鍵ストリームを暗号化するのみである。例えば、暗号化コンピュータシステム３０が第一データストリーム１０５を受信するとき、暗号化コンピュータシステム３０は許可ディレクトリ８０を調べて、どの公開鍵またはエンティティが第一データストリームにアクセスできるよう許可されているかを判断する。この実施例では、第一データストリーム１０５はビデオカメラフィード１である。暗号化コンピュータシステム３０のロジックは、第一データストリーム１０５と関連付けられた識別子を使ってビデオカメラフィード１（第一データストリーム１０５）を調べる。さらに、この実施例では、第一データストリーム１０５とともに提供され、ビデオカメラフィード１の下のディレクトリ８０に格納されるＭＡＣアドレスと、３つの公開鍵が第一データストリーム１０５へのアクセスと関連付けられた、ディレクトリ８０内の識別子、すなわちPub＿Key＿135、Pub＿Key＿057およびPub＿Key＿169とを使ってビデオカメラフィード１（第一データストリーム１０５）を調べる。それに応じて、暗号化コンピュータシステム３０のロジックは、これらの３つの公開鍵のそれぞれを使用して第一対称暗号化鍵ストリーム１１０を暗号化する。
【００４７】
別の実施例では、許可ディレクトリは、例えば許可が与えられる期間などの追加のフィールドを含む、より複雑なデータベースとなる場合がある。この期間はキャプチャ時間に対応してもよく、このキャプチャ時間は、暗号化データストリームのヘッダ内のエントリとして保存されたデータストリームのパケットヘッダ内のタイムスタンプなどによって示されるようなものである。したがって、特定のエンティティまたはエージェントが就業時間後にプライベートオフィスからカメラフィードにアクセスすることは許可されてもよいが、就業時間中は許可されなくてもよい。他のデータ源５０から得られる他のイベントに基づく状況を示す変数などのストリーミングデータへのアクセスを制御するため、データアクセスについて制限の他の表示が暗号化コンピュータシステム３０によってディレクトリ内に格納されて読み出されてもよい。例えば、データ源５０の場所が、従業員が就労施設を出入りする際に従業員によって使用される電子カードリーダーであるとき、特定のエンティティによるオフィスのカメラフィードへのアクセスが、オフィスの占有者による退出を電子カードリーダーが登録してから、電子カードリーダーが入場を登録した時までの時間の間の時間に限定されてもよい。このように、暗号化コンピュータシステム３０は、例えばデータ源５０からストリーミングデータなどのデータを表示するためのロジックを含むことができる。また、暗号化コンピュータシステム３０は、その表示データに基づいて、データ源５０から特定のデータストリームと関連付けられた特定の鍵ストリームを選択的に暗号化するためのロジックを含むことができる。その代わりに、またはその上、暗号化コンピュータシステムは表示データに基づいて鍵ストリームを選択的に送信することもできる。
【００４８】
手近な例に戻ると、第一対称暗号化鍵ストリーム１１０と、すべての他の対称暗号化鍵ストリームとは、対応するデータストリームにアクセスするための許可と関連付けられた非対称暗号化鍵で非対称的に暗号化される。このように、第一公開鍵１２０（本実施例ではPub＿Key＿135）で生成される非対称的に暗号化された第一鍵ストリームが生成される。第一データストリーム１０５へのアクセスと関連付けられるすべての他の公開鍵に関して、対応する非対称的に暗号化された第一鍵ストリームが存在する。他の鍵ストリーム（本実施例では個々のデータストリームと関連付けられるが、その代わりに全体の許可グループと関連付けられる場合もある）に関して、対応するデータへのアクセスと関連付けられる公開鍵ごとに一つの、非対称暗号化鍵ストリームの別のセットが生成されてもよい。
【００４９】
この特定の例によれば、第一対称暗号化鍵ストリーム１１０はユーザーの公開鍵を使用して、または、より一般的には非対称暗号化アルゴリズムに従って、エンティティの公開鍵を使用して暗号化される。さて、この実施例では、特定の公開鍵１２０を使って非対称的に暗号化された第一鍵ストリームは、非暗号化部分と暗号化部分とを含むパケット（ここでは便宜のため「鍵パケット」と呼ぶ）を生成することによって作られる。その非暗号化部分は、この暗号化された鍵ストリームと関連付けられたエンティティを識別するサムプリントを含む。例えばそのサムプリントは、エンティティの公開証明書／公開鍵を含むことができる。これは、データストリームに対し、リクエスタに対応する暗号化された鍵ストリームに対応する暗号化鍵ストリームを識別し、それと同じものをリクエスタに送るための要求を受信した場合に使用することができる。
【００５０】
さて、この実施例では、暗号化された鍵ストリームの各鍵パケットは、単一の暗号化された暗号化鍵を含む。この実施例では、第一対称暗号化鍵ストリーム１１０からの対称鍵と、特定の公開鍵１２０を使用して非対称的に暗号化された第一鍵ストリームのパケット（鍵パケット）とが１：１の関係にある。別の実施例として、暗号化された鍵ストリームは別々に編成されてもよい。ここで、しかしながら、暗号化された鍵ストリームにおける鍵パケットの非暗号化部分はまた、パケット内に含まれる暗号化鍵（この場合、パケットの暗号化鍵）の使用可能期間を示す存続期間データを含む存続期間フィールドを含む。上記したように、対称暗号化鍵は特定の頻度で変更され、絶えず変化する対称鍵でデータストリームを暗号化する（したがって鍵ストリーム）。存続期間データは、対応する（対称）暗号化鍵で暗号化されたデータストリームの部分の継続（例えば時間またはフレームの数またはその他）表示を提供する。
【００５１】
鍵パケットの暗号化された部分は暗号化鍵を含み、この実施例においては単一の暗号化鍵を含む。しかしながら、他の情報が鍵ストリームの対称暗号化鍵とともに暗号化されてもよい。この特定の実施例において、暗号化された部分はまた、暗号化されたデータストリームをどのように処理するかということについての情報を含むことができる。例えば、暗号化されたデータのタイプの表示する情報、およびそれをどのように処理するかという情報、またはデータストリームを暗号化するために用いられた暗号化プロトコルの表示の情報を含むことができる。ここで、暗号化された部分は、暗号化されたデータストリームを送信するために用いられるプロトコルがどういったものであるかを示すプロトコルの情報、そして必要に応じてプロトコルパラメータを含む。この実施例では、ＳＲＴＰプロトコルが用いられる。
【００５２】
この特定の実施例において、鍵パケットは対応する暗号化データストリームに提供される鍵インデックスに対応する鍵インデックス（ＭＫＩ）を同様に含む。これはパケットの暗号化されていない部分にあってもよい。ＭＫＩは受信デバイスによって使用され、暗号化されたデータストリームの対応する部分（この場合、ＲＴＰパケット）に復号鍵を同期させ、各部分が正しい復号鍵を使って復号されることを保証する。実際に、タイムスタンプは両方のストリームからのパケットとともに提供されてもよく、それは同期のために使用されてもよい。しかしながら、場合によっては、間違った鍵を用いてデータストリームの一部を復号したとき、結果として生じる文字化けがデータを処理するデコーダ（例えばＭＰＥＧデコーダ）をクラッシュさせる可能性がある。したがって、適切な同期を確保するため、受信者によってＭＫＩインデックスがクロスチェックされ、暗号化されたデータストリームの任意の部分を復号するための適切な鍵が使用されることを確保する。特に、受信者は、変化する（例えば時間で変化する）対称暗号化鍵ストリームに基づいて、対称暗号化で暗号化された暗号化データストリームを受信する。この暗号化鍵ストリームは、復号鍵ストリームからの復号鍵とそれぞれ関連付けられた（この場合、復号鍵は暗号化鍵と同じである）、暗号化データストリームの個々の部分を含み、そして復号鍵ストリームにおいて対応する復号鍵と関連付けられた鍵インデックスを含む。受信デバイスは、各復号鍵と関連付けられた部分を含む復号鍵ストリームを含んだ、暗号化鍵ストリームを受信する。復号鍵はこの実施例において、ストリーム内の復号鍵とともに提供される鍵インデックスを有することによって、各鍵インデックスと関連付けられる。受信デバイスは、暗号化データストリームの各部分について鍵インデックスを分離し、鍵インデックスと関連付けられた復号鍵を識別する。この場合、これは鍵ストリームから鍵インデックスを分離し、関連付けられた鍵を入手し、秘密の非対称復号鍵を使って関連付けられた鍵を復号することによってなされ、ようやくそのデバイスが鍵インデックスと関連付けられた、復号された対称復号鍵を使って、同じ鍵インデックスに関連付けられた暗号化データストリームの一部または各部分を復号する。
【００５３】
鍵ストリームの暗号化について、一つの特定の鍵ストリーム（第一対称暗号化鍵ストリーム１１０）に関して、そして一つの特定の非対称暗号化鍵について説明してきた。しかしながら、前述したことを他の非対称暗号化鍵の鍵ストリームの暗号化に適用し、対応するデータストリームへのアクセスを他のエンティティに提供することができることは当然理解できるはずである。同様に、上記内容を他のデータストリームに対応するほかの対称鍵ストリームに適用することができる。
【００５４】
対称鍵ストリームは、一つ以上の非対称公開鍵で暗号化した後で廃棄されてもよい。これにより、その後、アクセス権限を有するエンティティのみがストリームを復号および別の公開鍵を使って再暗号化し、別のエンティティにそのデータストリームへのアクセスを提供することができる。これは遠隔サーバー（例えばエンティティに対して暗号化されたデータストリームや暗号化された鍵ストリームのストリーミングすることを制御するサーバーなど）へのリクエストと組み合わせることが可能で、他のエンティティに権限を提供し、そのエンティティがリクエストに応じて対応するデータストリームや鍵ストリームを受信することができる。
【００５５】
この特定の実施例において、データストリームは暗号化コンピュータシステム３０によって受信された後すぐに暗号化され（代わりに、それらはデータ源５０での作成時に暗号化されてもよい）、暗号化されていないデータは複製されない。鍵ストリームは安全な場所に保管され、この例においては暗号化される場合を除いて、決して送信されることのないように外部から隔離される。このように、別のエンティティの公開鍵によって暗号化された第一対称暗号化鍵ストリーム１１０のひとつのバージョンが存在しないことにより、他のエンティティが鍵ストリームを入手したり、第一非対称暗号化データストリーム１１５を復号したりすることができないようにする。たとえそのような第三者が（許可なしに）（データストリーム１０５の唯一格納されたバージョンである）第一対称暗号化データストリーム１１５を入手した場合であっても、そして、たとえそのような第三者が任意の合法的な公開鍵で暗号化された非対称的に暗号化された第一鍵ストリームを入手した場合であっても、そのような第三者は、中のデータを開錠してそれを復号することができないため、データについて何もすることができない。また、その当事者の公開鍵では決して暗号化されていないため、第一鍵ストリームを復号することはできず、その結果、データストリームの復号に必要な鍵ストリームを入手することはできない。
【００５６】
したがって、システム１０は、ビデオアーカイブサーバー７０のセキュリティにあまり頼らないようにすることのできる固有の内蔵安全装置から恩恵を受ける。結果として、別の十分には信頼できないストレージのためのシステムと、ストリームデータへの分散型アクセスとを使用することができる。
【００５７】
なお、対称暗号化は概して非対称暗号化よりもかなり計算集約的に劣っている。暗号化は、それがシステムにかける負荷が原因で、ストリーミングアプリケーションに使用されることはあまりない。実際、非対称暗号化はそのサイズを著しく増大させ、それゆえ暗号化／復号の操作にかかる重い計算負荷をかけている間のストリームに必要な帯域幅を大きくする。このように、高いデータ容量を有し、効率的な復号とデコーディングとを必要とするストリーミングアプリケーションに関して、そのような暗号化スキームを広く採用するには負荷がかかりすぎることを示してきた。反対に、対称暗号化はより「軽い」解決策であり、計算負荷が小さく、より小さな要素によってサイズ／帯域幅を大きくすることができる。しかしながら、対称化鍵の符号化のみでは、鍵の伝達が必要であるため、安全性が低い。鍵の傍受により、単一の対称鍵で暗号化されたストリーム全体が不正アクセスされるであろう。このため、データストリームが一連の対称鍵ストリームで暗号化され、鍵ストリームが特定のエンティティのために非対称的に暗号化される本システム１０は、純粋な非対称暗号化よりもはるかに負担が少ないにも関わらず、とりわけ堅固なシステムである。
【００５８】
有利なことに、データストリームが鍵ストリームで対称的に暗号化され、その鍵ストリームが、対象とするデータストリームの受信者の公開鍵で非対称的に暗号化される、この暗号化スキームは、対称鍵を安全に交換するための端点間の安全なトンネルの確立に依存しない。なお、データストリームが非対称的に暗号化される場合、使用される公開暗号化鍵のそれぞれについて、各データストリームの暗号化バージョンが異なる必要があることに留意されたい。反対に、システム１０においては、ストリームデータの単一コピーのみが必要であり、これは信頼できないサーバーに安全に格納できるように対称的に暗号化されており、信頼できないネットワークを通じて送信可能である。
【００５９】
概して、本明細書で教示した技術によれば、鍵ストリームは、エンコードするために使用されるデータストリームよりもはるかに小さい。第一データストリーム１０５と比べて、第一対称暗号化鍵ストリーム１１０ははるかに小さい。非対称暗号化の後でさえも、非対称的に暗号化された第一鍵ストリームはまだ比較的軽いファイルである。それゆえ、比較的低い負荷で格納および通信することができる。特定の一実施例として、ビデオストリームは１Ｍｂｐｓの帯域幅を使用する。この実施例において、ＡＥＳ１２８の暗号化を使って急速に変化する鍵でそのストリームを暗号化し、これは１２８ｂｐｓの鍵ストリームを提供する。その鍵はデータストリームよりも非対称暗号化により適している。
【００６０】
なお、鍵ストリーム、暗号化鍵ストリーム、データストリームおよび暗号化データストリームは、実際には、単一のファイルに格納される必要はないことに留意されたい。これらは、ストリーム全体の部分を含む複数のファイルに分解されてもよい。一実施例として、暗号化されたデータストリームはそれぞれ１５分のデータを含む１セットのファイルとしてアーカイブに格納することができる（一実施例として、そのデータはビデオまたは音声データであり、それぞれのファイルが１５分のビデオまたは音声を含む）。この実施例において、暗号化鍵ストリームは（必要に応じて）１５分のデータストリームを保有する、対応するファイルの鍵を含むファイルに同様に格納されてもよい。別の方法として、鍵ファイルの分解とデータファイルの分解とを別にすることができる。
【００６１】
図６は、非限定的な実施例によるシステム１０の概要を示す論理ブロック図である。図に示したように、システムは信頼できるネットワーク領域２０を含む。ここに示した特定の構成において、ビデオアーカイブを使用して、暗号化されたストリームデータと非対称的に暗号化された鍵ストリームとの両方を格納することができる。この実施例ではユーザーシステム４００である、典型的なエージェントステーション６５は、ビデオアーカイブサーバー３００を通じてストリームデータにアクセスすることができる。
【００６２】
図７は信頼できるネットワーク領域の拡大図を示す。この特定の実施例において、データ源５０は監視カメラ２１０であり、信頼できるネットワーク領域２０内にある。前の実施例の暗号化コンピュータシステム３０は、単一のワークステーションまたはサーバーコンピュータシステムであったが、別の実施例において、それは複数の構成部分に渡って分散されてもよい。図７に示す実施例では、暗号化コンピュータシステム３０は、ストリームバッファ２１５と、対称暗号化エンジン２３０と、公開鍵暗号化エンジン２４０と、インターフェースゲートウェイ２５０とによるデータ入力を含むものとして示される。また対称鍵生成ロジック２２０形式の対称鍵源は、暗号化コンピュータシステム３０の一部でもあるが、別の実施例では外部モジュールであってもよい。
【００６３】
上記したように、暗号化コンピュータシステム３０は、監視カメラ２１０に接続し、そこからストリーミングデータを受信するための入力を含む。また上述したことであるが、データ源５０との接続がネットワーク接続であってもよい。この目標を達成するため、その入力は、インターフェースゲートウェイ２５０と分離することができるネットワークインターフェースを採用することができ、この実施例では、それを用いて信頼できないネットワーク４５とインターフェース接続することができる。その代わりに、入力はデータ源５０への直接接続であってもよい。この実施例ではデータ源はパケットベースのプロトコルを通じてストリームを提供し、入力ストリームバッファ２１５は着信パケットを蓄積し、それらを適切に順序付ける。この特定の実施例では、入力ストリームバッファ２１５を使ってネットワーク層パケットをアンラップ（ｕｎｗｒａｐ）して、アプリケーション層パケットを得ることもできる。
【００６４】
対称鍵ジェネレータ２２０は、対称暗号化鍵ストリームを構成する対称暗号化鍵（Ｓ1，Ｓ2，Ｓ3，．．．）を生成するためのロジックを含む。場合によっては、対称鍵ジェネレータは、例えば、暗号化コンピュータシステム３０との、またはストリームデータの暗号化を（例えばデータ源５０で）実行する別のシステム部分との、信頼できる通信関係にある外部のサービスよって対外的に提供される。しかしながら本実施例では、対称鍵ジェネレータ２２０は暗号化コンピュータシステムにあり、例えば有形のコンピュータ読み取り可能なストレージに格納されたソフトウェアコードを含み、鍵生成アルゴリズムに従って汎用（すなわちプログラム可能な）処理エンティティに対して対称暗号化鍵（Ｓ1，Ｓ2，Ｓ3，．．．）を生成するよう指示を与える指示を含む。この実施例ではＭｉｃｒｏｓｏｆｔ（登録商標）ＣｒｙｐｔｏＡＰＩが使用される。
【００６５】
暗号化エンジン２３０は、対称鍵ジェネレータ２２０によって提供される対称暗号化鍵を使用する監視カメラ２１０によって提供されるストリームデータに対して、暗号化アルゴリズムを適用するためのロジックを含む。本実施例では、暗号化エンジン２３０は、暗号化コンピュータシステムにあり、例えば有形のコンピュータ読み取り可能なストレージに格納されたソフトウェアコードを含み、汎用処理エンティティに対して暗号化を実行するように指示を与える指示を含む。その目的を達成するため、監視カメラ２１０からのストリームデータはシーケンシャル部分（Ｖa，Ｖb，Ｖc，．．．）に分けられる（この実施例では、これは暗号化エンジン２３０によってなされる）。シーケンシャル部分の各々は、それぞれの暗号化鍵によって暗号化される。この実施例では、ストリームデータはＨ．２６４でエンコードされたビデオストリームであり、Ｉフレームで始まる多数のフレームを構成するように各シーケンシャル部分（Ｖa，Ｖb，Ｖc，．．．）が選択される。この特定の実施例では、各シーケンシャル部分（Ｖa，Ｖb，Ｖc，．．．）は、暗号化エンジン２３０によってペイロード部分に細分されて、一旦暗号化されると、ＲＴＰパケットの個々のペイロードを作り出す。このペイロード部分は、（例えば時間やフレームの数に関する）サイズファクターによって細分されてもよい。一実施例として、暗号化エンジン２３０はフレーム数およびＩフレームの存在に基づいてサイズを選択する。ここで具体的には、暗号化エンジン２３０は最小のフレーム数をカウントし、その後、次のペイロード部分となる次のＩフレームを選択し、選択された次のＩフレームの前にすべてのフレームをペイロード部分に配置し、これを特定のシーケンシャル部分（Ｖa，Ｖb，Ｖc，．．．）がすべて使い尽くされるまで繰り返す。
【００６６】
暗号化エンジン２３０は対称鍵ジェネレータ２２０から対称暗号化鍵のストリームを受信する。暗号化エンジン２３０は各シーケンシャル部分（Ｖa，Ｖb，Ｖc，．．．）のそれぞれの対称鍵で暗号化し、対称的に暗号化されたデータストリームを生成する。実際のところ、この特定の実施では、鍵（Ｓ1，Ｓ2，Ｓ3，．．．）を要求するようにセグメント化された特定のシーケンシャル部分ごとに、暗号化エンジン２３０が対称鍵ジェネレータ２２０を必要とする。それは、それが特定のシーケンシャル部分を暗号化することで、引き換えに対称鍵ジェネレータ２２０から受信する。この呼び出し（ｃａｌｌｉｎｇ）はソフトウェアによって行われてもよく、例えば別の対称鍵ジェネレータクラスの機能を呼び出すことによって行われたり、また例えば、ＣｒｙｐｔｏＡＰＩへのリクエストを生成することによって行われてもよい。
【００６７】
本実施例では、暗号化エンジン２３０がデータストリーム２１６のそれぞれ個別のシーケンシャル部分（Ｖa，Ｖb，Ｖc，．．．）をそれぞれの暗号化鍵（Ｓ1，Ｓ2，Ｓ3，．．．）で暗号化し、暗号化されたデータ（Ｓ1（Ｖa），Ｓ2（Ｖb），Ｓ3（Ｖc），．．．）のシーケンシャル部分から構成される対称的に暗号化されたデータストリーム２３２を生成する。本実施例では、暗号化エンジン２３０は、暗号化されていないデータストリーム２１６の複製を保持せずに、鍵ストリームに基づいた暗号化を、リアルタイムにデータストリーム２１６に適用する。
【００６８】
とりわけこの実施例では、暗号化エンジン２３０は、ＲＴＰパケットに配置するチャンク中の各シーケンシャル部分を暗号化する。具体的には、暗号化エンジンが個別のペイロード部分を処理する。必要に応じて、それは暗号化データストリームにおいて暗号化されるメタデータなどの他の情報をペイロード部分に加えることができる。暗号化エンジン２３０は、この実施例では、ＡＥＳ１２８暗号化を使ってペイロード部分の対称暗号化を適用する。そして暗号化エンジン２３０はパケット、この場合、タイムスタンプをヘッダに配置するＲＴＰパケットを生成し（これはストリームデータとともに受信することができ、またはストリームデータから得られる、または暗号化エンジン２３０で生成される）、同様に、含まれるペイロードタイプと鍵インデックスとを示すペイロードタイプの情報を生成し、それは鍵ジェネレータ２２０から受信してもよいし、またはそれ自体を生成してもよい。
【００６９】
この実施例では、公開鍵１２０を使用して非対称的に暗号化された第一鍵ストリームのような非対称暗号化鍵ストリームのそれぞれが、一つの鍵ストリームのみを構成したが、例えばすべての鍵ストリームなどの多重鍵ストリームが、ひとつの特定のエンティティの（またはグループの）許可レベルまたはそのサブセットと関連付けられることは当然理解できることである。とりわけ暗号化された鍵ストリームは、特定のエンティティがアクセス許可を有する、同時に存在するデータストリームについて、すべての鍵ストリームを含むように、例えばエンティティの公開鍵でそれらを一緒に暗号化することによって生成されてもよい。
【００７０】
公開鍵暗号化エンジン２４０は、データストリーム２１６へのアクセス権限を有するエンティティの公開鍵に対してアクセスすることができる（図示せず）。これらは任意の適切な通信システムを介してエージェントステーション６５によって直接的に提供されてもよい。なお、公開鍵は概してデータ暗号化にのみ使用することができ、復号には使用できないため、安全に移動される必要はないことに留意されたい。公開鍵暗号化エンジン２４０もまた対称鍵ストリーム２２２を受信するが、それで何かを暗号化することを目的とするのではなく、むしろ対称鍵ストリーム２２２それ自体を暗号化するためである。この目的を達成するため、公開鍵暗号化エンジン２４０は暗号化アルゴリズムを対称暗号化鍵ストリーム２２２に適用するためのロジックを含む。この対称暗号化鍵ストリーム２２２は、対称鍵ジェネレータ２２０によって公開非対称暗号化鍵のそれぞれに提供され、公開非対称暗号化鍵を使用する対称暗号化鍵で暗号化されたデータストリームにアクセスするための許可と紐付けられる。本実施例では、公開鍵暗号化エンジン２４０は、暗号化コンピュータシステムにあり、例えば有形のコンピュータ読み取り可能なストレージなどに格納されるソフトウェアコードを含み、暗号化を実施するように汎用の処理エンティティに指示を与える指示を含む。本実施例で用いられる暗号化アルゴリズムは、非対称のＲＳＡ暗号化である。このアルゴリズムは対称暗号化鍵ストリーム２２２を必要とし、ストリーム２２２に対して公開鍵Ｐを使用する暗号化を適用し、非対称的に暗号化された鍵ストリーム２４２を生成する。この特定の実施例では、非対称的に暗号化された鍵ストリーム２４２が非対称的に暗号化された対称鍵（Ｐ（Ｓ1），Ｐ（Ｓ2），Ｐ（Ｓ3），．．．）の一つのストリームであるように、暗号化は対称鍵ずつの基準で適用される。その結果として得られる、暗号化された証明書固有の鍵ストリームは、鍵ストリームの非対称的に暗号化された選択であり（さらに本明細書で説明するように、非対称的に暗号化された鍵ストリームは特定のデータストリームに対応する対称鍵のサブセットのみを含むことができ、このサブセットは、公開鍵証明書の保有者に対してアクセスが許可されるデータストリームのサブセットに対応する）、これは意図されたユーザーに対し、対応する暗号化データストリームの選択セグメントを復号するための能力を提供する。
【００７１】
この鍵ストリームの生成と、データストリームの暗号化と、鍵ストリームの公開鍵の暗号化（許可に適した公開鍵の各々に対する）とは、追加のデータストリームについて繰り替えされてもよい。許可レベルをシェアするデータストリームについて、実施例に存在する場合、その生成された鍵ストリームは多重データストリームに再利用されてもよく、鍵ストリームの新たな暗号化を必要としない。
【００７２】
同様に、エンティティのグループ、例えばユーザーグループなどは、認証／公開鍵を共有することができ、それぞれがグループに基づく許可レベルを提供するための対応する秘密の復号鍵を有する。その代案として、この実施例における場合には、グループはグループのメンバー各自に対して暗号化鍵ストリームを生成することと、各メンバーと関連付けられたグループ関連付けを格納することとによってシンプルに管理することができる。
【００７３】
インターフェースゲートウェイ２５０は、暗号化コンピュータシステム３０からのデータの通信を指示するロジックを含む。本実施例として、暗号化コンピュータシステム３０は、対称的に暗号化されたデータストリーム２３２と、非対称的に暗号化された鍵ストリーム２４２とを含む。これら両方は、エージェントステーション６５によってアクセス可能であるが、特にこの実施例では、対称的に暗号化されたデータストリーム２３２と、非対称的に暗号化された鍵ストリーム２４２とは、ビデオアーカイブサーバー７０に格納され、この場合、そのサーバーは信頼できないネットワーク４５を通じてクラウドコンピューティングサービスとして提供される。
【００７４】
この目的のため、インターフェースゲートウェイ２５０は、信頼できないネットワーク４５を通じて通信するためのネットワークインターフェースを含み、その場でのストレージのため、例えばストリーミングプロトコル、対称的に暗号化されたデータストリーム２３２および非対称的に暗号化された鍵ストリーム２４２によって、遠隔のビデオアーカイブサーバー７０にログオンし、そこへ送信するためのロジックを含む。保管用にそこへ送信する。本実施例では、インターフェースゲートウェイ２５０は暗号化コンピュータシステム３０にあり、例えば有形のコンピュータ読み取り可能なストレージに格納されたソフトウェアコードを含み、通信を実施するように汎用処理エンティティに指示を与えるための指示を含む。
【００７５】
インターフェースゲートウェイ２５０は、信頼できるネットワーク領域２０を信頼できないネットワーク４５から適切に遮蔽するためのセーフガードを実装することもできる。これは、ファイヤーウォールのロジック、プロキシのロジック、パケットのサニタイジングのロジック、再カプセル化のロジックおよびＤＭＺの実装のためのロジックを含むことができる。暗号化コンピュータシステム３０、より広義には信頼できるネットワーク領域２０は、信頼できるネットワーク２０と信頼できないネットワーク４５との間のインターフェースに実装された、ＤＭＺの後ろでより具体的に保護されてもよい。
【００７６】
別の一実施例として、非対称的に暗号化された鍵ストリーム２４２は、ビデオアーカイブサーバー７０を通さずに、エージェントステーション６５に提供されてもよい。例えば、それは暗号化コンピュータシステム３０によって直接的にエージェントステーション６５に提供されてもよい。この目的を達成するため、インターフェースゲートウェイ２５０は、非対称的に暗号化された鍵ストリーム２４２に関して、エージェントステーション６５からリクエストを受信するのに適している可能性がある。この目的を達成するために、エージェントステーション６５は、例えばユーザー入力、特定のデータストリームまたはその部分に基づいて、リクエストを生成するためのロジックを含むことができる。このリクエストは、特定のストリームの組み合わせ、または特定のストリームの部分の組み合わせに対するものであってもよい。これらの目的を達成するため、リクエストはデータストリームを識別するデータ、ストリームの部分またはその組み合わせ、およびリクエストエンティティ（この実施例ではリクエストエンティティの公開鍵／証明書を識別するリクエスタ識別子）を含む。受信したとき、暗号化コンピュータシステムは、リクエストエンティティがリクエストされたストリームデータにアクセスできる権限を与えられているかどうかを検証する。これは従来の検証プロセスを含み、例えば許可テーブルにおいてリクエスタ識別子を検索する。しかしながら、この実施例において、暗号化コンピュータシステムは、リクエストされたストリームデータのための暗号化鍵ストリームにアクセスするためのロジックを含み、サムプリント情報を読み込んで識別子（この場合、公開鍵／証明書）を発見し、リクエスタ識別子とサムプリントで発見される識別子とを比較し、ポジティブマッチを発見すると、暗号化データストリームまたはリクエストされた部分を、暗号化鍵ストリームとともにリクエスタに送信する。一実施例として、データストリームの全部または一部が、発信元のエンティティによって保持され、そして２つの鍵のマッチングが成功したとき、ストリームデータのアクセスできない部分が発信元のネットワークから検索される。実施例によっては、リクエスタ識別子とサムプリントで発見される識別子との間にポジティブマッチが無く、リクエスタ識別子とサムプリントで発見される識別子との間でミスマッチしているときは、自動的に除外リクエストまたは除外許可に変換され、その後、同意または拒絶について審査などの仲裁権限を有するところに転送される。実施例によっては、両方のストリームを送るというよりも、暗号化コンピュータシステム３０が、例えばクラウドベースのストレージから一つまたは両方を送信させることができる。この検証は一回実行されてもよいが、この実施例では、リクエストされたデータストリームまたはその部分の、すべてのシーケンシャル部分（Ｖａ，Ｖｂ，Ｖｃ，．．．）について実行され、その結果、アクセスがデータストリームの一部についてのみ認められている場合、その部分のみが提供される。
【００７７】
データストリームの暗号化はシステム１０の様々な点で行われてもよい。この特定の実施例では、暗号化は信頼できるネットワーク領域内で行われる。さらに具体的には、この実施例では、暗号化コンピュータシステム３０がストリームデータのデータ暗号化を実行する。この目的を達成するため、暗号化コンピュータシステム３０は、データ源５０からストリームデータを受信するための入力インターフェースや、信頼できるネットワーク領域２０内で通信するためのＬＡＮインターフェースなどのネットワークインターフェースを含む。なお、上記実施例で説明したが、データストリームの暗号化は、サーバーまたはワークステーションに具現化される暗号化コンピュータシステム３０で行われるが、暗号化コンピュータシステム３０を分散させて、そのいくつかの機能が、例えばデータ源５０の内部で行われてもよいということは理解できることである。例えば、図７を参照すると、入力ストリームバッファ２１５と暗号化エンジン２３０とは、監視カメラ２１０を含むデータ源５０内に含まれてもよい。対称鍵ジェネレータ２２０は外部ソースであってもよいが、この別の実施例では、それはデータ源５０のモジュールでもある。このようにデータ源５０は対称暗号化鍵ストリームと同様に、暗号化されていないデータの複製を保存せずにリアルタイムで暗号化された暗号化データストリームを出力する。このデータ源は暗号化コンピュータシステム３０の外側にあるとみなすこともできる。対称暗号化鍵ストリームは、必要に応じて暗号化コンピュータシステム３０への暗号化接続を使用して、信頼できるリンクを通じて提供されてもよく、これは対称暗号化鍵ストリームを検索し（必要であればそれらを復号して）、許可するのに適したエンティティの公開鍵を使ってそれらを暗号化するように進む。
【００７８】
また別の例として、信頼できるネットワーク領域２０内であってさえも、暗号化されていないデータが送信されることがないようにするため、この機能とインターフェースゲートウェイ２５０のそれすらも、各データ源５０にストリームデータと鍵ストリームの両方に必要な暗号化を適用しつつ、データ源５０に移動させることができる。この実施例について、集中型の制御ロジックを実装することは有益となり得る。これはユーザー／エンティティおよびそれらの各々の公開鍵の収集と分散を管理し、さらにデータ源５０全体の暗号化コンピュータシステム３０のすべての分散された部分間で最新の許可ディレクトリを確保するためである。
【００７９】
図７の実施例に戻ると、この実施例において制御ロジック（図示せず）も実装され、ユーザー／エンティティおよびそれらの公開鍵の収集を管理し、許可ディレクトリ８０が最新であることを保証する。制御ロジックは、許可を追加したり解除したりするためのロジックを含むことができる。そしてこの目的を達成するため、それは有形のコンピュータ読み取り可能なストレージに格納されるコンピュータ読み取り可能な指示を含むソフトウェアモジュールであってもよい。この指示は汎用処理ユニットに対して許可ディレクトリ８０をアップデートするように指示を与え、エントリを追加、修正または削除させ、さらに、許可の変更に対応して非対称的に暗号化された鍵ストリームの対応する追加、修正または削除をさせるものである。例えば、特定のデータストリームについて（例えば特定の期間）特定の公開鍵に対して新たな許可が与えられる場合、対応するエントリが許可ディレクトリ８０に追加され、対称暗号化鍵ストリームがメモリ内でアクセスされる。その鍵ストリームは暗号化コンピュータシステム３０でローカルに格納されてもよく、または図６の実施例のように、ビデオアーカイブサーバー７０でローカルに格納されてもよい。いずれにしても、暗号化コンピュータシステムが鍵ストリームにアクセスできるようにして、それらを再暗号化して許可を修正しつつ、データセキュリティを提供するためには、暗号化コンピュータシステム３０（対応する秘密鍵を有する暗号化コンピュータシステム３０）に属する公開鍵を使ってそれらを暗号化して格納することができる。当の鍵ストリームが一旦引き出されると（そしてもし必要な場合、復号されると）、制御ロジックからの指示の下、暗号化コンピュータシステムは公開鍵で鍵ストリームのコピーを暗号化し、許可が与えられる。
【００８０】
データストリームのサブセット（または部分）のみに関して許可が与えられる場合、これは暗号化データストリームにアクセスすることによってなされてもよい。上記したように、暗号化データストリームは暗号化されていない部分を含み、それは異なる部分および対応する暗号化鍵を識別するデータを含むことができる。暗号化コンピュータシステム３０はデータを識別する部分に基づいてデータストリームのサブセットを発見し、データを識別する鍵に基づいて鍵ストリームの対応する部分を発見する。例えば、上記の特定の実施例において、データストリームは、暗号化されてないヘッダ、タイムスタンプおよび鍵インデックスを含むＲＴＰパケットを含むシーケンシャル部分（Ｖａ，Ｖｂ，Ｖｃ，．．．）を含む。暗号化コンピュータシステム３０は、データストリームの特定の時間サブセットに関するリクエストを受信するためのロジックを含むことができ、またタイムスタンプに基づいて対応するシーケンシャル部分（Ｖａ，Ｖｂ，Ｖｃ，．．．）を選択することができる。暗号化コンピュータシステム３０は、エンティティ識別子に基づいて対応する暗号化鍵ストリームを識別するためのロジックをさらに含むことができる。それのエンティティ識別子はその暗号化されていない部分に格納されている。この特定の場合、その暗号化されていない部分は公開鍵／証明書それ自体を含むことができる。暗号化コンピュータシステム３０は、当のデータストリームの部分に対応する特定の鍵（この場合、暗号化鍵ストリームの一部である）を識別するためのロジックをさらに含むことができる。そしてその自己の秘密鍵を使って鍵を含む暗号化鍵ストリームの部分を復号し、リクエスタの公開鍵を使ってこれらの鍵を再暗号化し、本明細書に記載したように新規の暗号化鍵ストリームを生成する。したがって、新規に生成された鍵ストリームは、エレメンタリストリームを通じて許可されたデータの見える範囲を例えば一定期間のビデオストリームにのみ制限するため、最初の対称鍵のサブセットのみ保有することができる。このようにして許可の粒度が実装されてもよく、それにより異なる第三者が異なるストリームにアクセスできるだけでなく、ストリームの異なるサブセットにもアクセスすることができる。この実施例では、ストリームがそのように分割され、対称鍵の変化によって範囲が定められるサブセットに分割される結果、許可が与えられるストリームのサブセットがストリームの一部または複数の部分に対応し、それぞれが全体的に各対称鍵に対応する。本実施例では、サブセットの鍵ストリームは暗号化鍵ストリームを復号し再暗号化することによって上述の通り生成されるが、対称鍵ストリームが複数の公開鍵を使って同時に（例えば公開鍵暗号化モジュール２４０によって）暗号化され、最初から複数の異なるアクセス許可を生成することも考えられる。そのような場合、対称鍵ストリーム２２２の異なるサブセット部分に異なる公開鍵を使用し、異なるエンティティに関連するデータストリームへの粒度の細かい（ｇｒａｎｕｌａｒ）／区別できるアクセスを提供することができる。
【００８１】
暗号化コンピュータシステム３０によって新規の許可が提供されると説明してきたが、一実施例として、暗号化コンピュータシステム３０は公開／秘密鍵のペアを有さない。それは、本明細書で説明したように対称鍵ストリームを暗号化することは可能かもしれないが、一旦暗号化が完了すると、暗号化されていない鍵ストリームのコピーを保持することはできない。上記した許可を与える機能とロジックとは、エージェントステーション６５に提供されてもよい。この実施例では、特定のデータストリームまたはその部分へのアクセスが可能なエンティティのみが、別のエンティティへのアクセスを許可することができる。この目的を達成するため、エージェントステーション６５は暗号化エンジン２３０を含むことができる。したがって、他の階層へのアクセスを許可するために、暗号化鍵ストリームへのアクセス権限を有するエンティティから、許可が付与されることに依存するほうを選択し、暗号化されていない鍵ストリームを破棄してもよい。同様に、データストリームの危殆化（ｃｏｍｐｒｏｍｉｓｅ）となるリスクを最小限にするため、暗号化されたデータストリームのみを保持して暗号化されていないデータストリームを破棄してもよい。
【００８２】
したがって、エージェントステーション６５は、第三者に対して特定のデータストリームへのアクセスを許可するためのリクエストを受信することができる。このリクエストはシステム３０、第三者または他の場所から来てもよい。この目的を達成するため、エージェントステーション６５は第三者の公開―秘密鍵のペアに属する、第三者の公開鍵を受信することができる。この第三者の公開―秘密鍵のペアには、第三者の秘密鍵が第三者によって秘密に保持されているため、例えばエージェントステーション６５などには知られない。エージェントステーション６５は、リクエストを受信し、上記したような第三者の公開鍵を使用した対応する鍵ストリームの復号と、鍵ストリームの再暗号化とを含む許可を与えるためのロジックを含むことができる。さらに、エージェントステーション６５は、例えばテーブルを使うかまたは上記した他の手段によって、最初に許可の検証を行うことができるため、例えば熟練のプログラマーによってそのためにプログラムされたソフトウェア命令の形式のロジックを含むことができる。その許諾は、第三者がデータストリームにアクセスする権限を有するということについての判定に基づいて行われてもよい。反対に、その第三者が権限を有さないと判定した場合、許諾は行われなくてもよい。当然ではあるが、リクエストはデータストリームの一部のみに関するものであってもよく、それに応じて対応する鍵ストリームの対応する部分のみが再暗号化されてもよい。また、検証により第三者がデータストリームのサブセット部分のみについて権限を有するということを示すことができ、この場合、許諾はデータストリームの一部に対応する鍵ストリームの一部についてのみ実施することができ、第三者は検証によって決定されるとおりにアクセスが許可される。鍵ストリーム（またはその一部）を再暗号化した後、エージェントステーション６５は、第三者またはビデオ監視サーバーなどのサーバーのいずれかに対し、例えば信頼できないネットワークを通じて再暗号化鍵ストリームを送信することができる。ここでも、エージェントステーション６５による許諾が行われるところで、アクセスが許可されたデータストリームのサブセットのみを再暗号化することによって上記のように粒度が実装されてもよい。その結果として生じる再暗号化された鍵ストリームは、アクセスが許可されるデータストリームのサブセット部分に対応する対称鍵を含む。
【００８３】
エージェントステーション６５は本明細書で説明するロジックを含み、このロジックはコンピュータシステムであってもよく、熟練のプログラマーによってプログラムされうるような、汎用プロセッサに対して本明細書で説明する機能を実行するよう指示を与えるための有形の記憶媒体に格納される、コンピュータ読み取り可能な指示で具体化することができる。ひとつの限定されない実施例として、エージェントステーションは汎用コンピュータ上で実行するビデオ監視クライアントソフトウェアを含む。エージェントステーション６５はデータストリームを処理して有益なことや具体的なことをするためのロジックを含むことができる。例えばエージェントステーションは、データストリームに含まれる情報を例えば図表や音声でユーザーに提供するためのソフトウェアのコードなどのロジックを含むことができる。例えばエージェントステーション６５は、ビデオストリームを復号するためのビデオや音声の復号器を含むことができ（例えばＭＰＥＧに準拠した復号器）、同様に、ユーザーに対してモニターにビデオを表示するためのソフトウェアやグラフィックスハードウェアを含むことができる。同様に、エージェントステーション６５は、ユーザーに対してスピーカーを通じて音声を出力させるのに必要なロジックを含むことができる。
【００８４】
ビデオアーカイブサーバー７０は、この実施例では、非対称的に暗号化された鍵ストリームとともに、対称的に暗号化されたデータストリームを保持する。このデータは、例えばクラウドストレージを介してデータを提供することによって、エージェントステーション６５でエンティティに対してアクセス可能とされ、これは、他の手段によってクラウドストレージ自体にユーザーの検証／ログインおよび許可の検証を実装させてもよい。そのような場合、特にクラウドストレージの不正アクセスに備えて、二層の暗号化方式が追加のセキュリティを提供する。暗号化コンピュータシステム３０でローカルアーカイブする場合でさえも、その二層の暗号化は有利である。例えば、技術者は彼らの仕事の一部として、アーカイブに格納されたデータにアクセスすることはできる。しかしながら、極秘データのストリームは暗号化されて格納されることによって依然としてそれらから遮断することができる。したがって、強制的な許諾はきわめて堅牢である。そして、アーカイブシステムそれ自体がハッキングまたは不正アクセスされる場合、そのシステムは許可されていないアクセスに対する追加の保護を提供とする。
【００８５】
このように、一実施例によると、ストレージサーバーが元のデータおよび鍵ストリームを格納するにあたって信頼できない場合、我々は新規の暗号化された公開鍵固有の鍵ストリームを生成する。（例えばエージェントステーション６５で）計画的に最初に権限が与えられたエンティティが、権限が与えられた別のエンティティに対して暗号化公開鍵固有の鍵ストリームを生成してもよく、これは対称鍵ストリームの全てまたはサブセットのみに対応する。この目的を達成するため、エンティティはストレージサーバー３００に格納される、最初に許可されたエンティティの公開鍵を使って暗号化された対称鍵ストリームにアクセス可能であり、その秘密鍵を使って暗号化された対称鍵ストリームまたはそのサブセットを復号し、また、第二の許可されたエージェントの公開鍵を使って、暗号化された対称鍵ストリームまたはそのサブセットを再暗号化することができる。その結果として生じる再暗号化された鍵はストレージサーバー３００などの中央サーバーに公開されてもよい。
【００８６】
ここで図８を参照すると、図６のユーザーシステム４００がより詳細に示されている。図に示すように、ユーザーシステム４００は暗号化コンピュータシステム３０に提供される公開鍵Ｐkに対応する、秘密鍵Ｐ-1j４１２を格納する秘密鍵源４１０を含む。そのユーザーシステム４００は、少なくとも１つのネットワークを通じて通信するためのネットワークインターフェース（図示せず）、例えばこの実施例では、信頼できないネットワーク４５を含み、対称暗号化ストリームデータと、対応する非対称暗号化鍵ストリームデータとを入手することができる。
【００８７】
説明のため、一実施例として、ユーザーシステム４００は公開鍵Ｐｕｂ＿Ｋｅｙ＿１３５を有し、第一ストリームデータ１０５へのアクセスを要求する。この実施例では、ビデオアーカイブサーバー７０はこの両方のデータを格納する。ユーザーシステム４００でのユーザーの入力に応じて、ユーザーシステム４００のネットワークインターフェースは、第一ストリームデータ１０５に対するビデオアーカイブサーバー７０へのリクエストを定式化する。データストリームは、例えばストリームのグローバル一意識別子（ＧＵＩＤ）を使うなどの任意の適切な方法によって識別されてもよい。それに応じて、ビデオアーカイブサーバー７０は、そのメモリから第一対称暗号化データストリーム１１５を読み出す。
【００８８】
特定の一実施例として、すべての鍵ストリームが暗号化されているため、コンテンツに対するリクエストについて、リクエストの検証を行わなければならないというよりは、暗号化されたコンテンツ（例えば第一対称暗号化データストリーム１１５）が、対応する暗号化鍵ストリーム（例えば使用されるすべての公開鍵を使って暗号化されるような、非対称的に暗号化された第一鍵ストリーム）すべてに応じて一緒に送信される。非対称的に暗号化された鍵ストリームはデータ的にはそれほど大きくないので、特にいくつかの異なるエンティティまたは許可グループが存在する場合に、これは適切な解決策である。このように、ユーザーエンティティ４００はすべての暗号化された鍵ストリームを受信する。これらは、暗号化鍵ストリームの暗号化に使用された公開鍵を識別することができ、例えばヘッダフィールドにおいて、セッション鍵の復号モジュール４４０が各暗号化鍵ストリームについて秘密鍵４１２で復号可能かどうかを判定できるようにする。あるいは、セッション鍵の復号モジュール４４０は、受信されたすべての暗号化鍵ストリームを復号するよう単純に試み、利用可能なデータを提供するものを識別することができる。
【００８９】
しかしながら、その代わりに、ビデオアーカイブサーバー７０はリクエスタの識別を検証するためのアクセスコントロールを実装し、そのリクエストが公開鍵に対応する場合または、例えば対応する非対称的に暗号化された鍵ストリームを有するデータストリームへのアクセス権限を有するエンティティに、そのリクエストが対応する場合にのみ、暗号化データストリームを提供する。一実施例として、データストリームについて、すなわち、より具体的には、データストリームに対する復号鍵に関するリクエストを受信するデバイス（例えばビデオアーカイブサーバー７０であるが、暗号化鍵ストリームが保持される場所にある場合、その代わりに暗号化コンピュータシステム３０）が、リクエスタの公開鍵／証明書とともに受信する。また、そのデバイスはストリームに対応する公開鍵／証明書を含む暗号化鍵ストリームのフィールドと、公開鍵／証明書とを比較するためのロジック（例えばソフトウェアコード、例えば汎用プロセッサに対するコンピュータ読み取り可能な指示など）を含む。これが唯一の検証であってもよいし、または、例えば許可ディレクトリ（例えば暗号化鍵ストリームを各エンティティと照合する鍵ストリームテーブルを含むディレクトリ）においてリクエスタと関連付けられた識別子（公開鍵など）を最初に調べた後に実行される冗長検証であってもよい。
【００９０】
別の一実施例として、暗号化コンピュータシステム３０は暗号化鍵をローカルに格納する。この実施例では、ユーザーシステム４００のネットワークインターフェースは、データリクエストを例えばプロキシサーバーの許可バリデータに送信することができる。この許可バリデータは、本明細書で説明する技術などを使って許可を認証し、そのリクエストの認証と同時に、承認されたアクセスのリクエストを暗号化コンピュータシステム３０に送信することができる。また、そのバリデータは（暗号化されたデータストリームがビデオアーカイブサーバー７０に格納される場合および、これが暗号化コンピュータシステム３０と分離している場合）、承認されたアクセスのリクエストをビデオアーカイブサーバー７０に送信することができる。このビデオアーカイブサーバー７０は、これらのエンティティの両方に対して、データストリームを得るために必要なデータの各部分をリクエスタに送信するように指示を与える。プロキシサーバーに提供されるというよりは、許可バリデータが暗号化コンピュータシステム３０の一つかまたは（もし分離していれば）ビデオアーカイブサーバー７０のどちらかに提供されてもよい。またその代わりに、これらの各々が上述のようにリクエスタの許可を検証するタスクを独立して実行することができる。
【００９１】
図９はビデオアーカイブサーバーが暗号化コンピュータシステム３０内に含まれているシステムを示す。したがって、ビデオアーカイブサーバー７０のロジックは暗号化コンピュータシステム３０内に含まれても良い。リクエストの検証はビデオアーカイブサーバー３０で実行される。
【００９２】
特定の一実施例として、暗号化されたデータストリームは、暗号化と同時に、暗号化コンピュータシステム３０によって、エージェントステーション６５に（そして例えば他の承認された受信者にも）直接、ストリーミングされてもよい。これはサーバーが暗号化コンピュータシステム３０の内側にあっても外側にあっても、ビデオアーカイブサーバー７０で保存する前または保存と同時にされてもよい。暗号化データストリームおよび暗号化鍵ストリームの送信は、たとえ同じエンティティに格納される場合であっても、別々にすることができる。特定の一実施例として、暗号化データストリームは、暗号化鍵ストリームと同時にすべての受信者にマルチキャストすることができ、これは異なる受信者によって異なっていてもよく、例えばエージェントステーションなどの各クライアントと１対１の関係を通じて送信される。なお、アーカイバーは決してデータストリームや鍵ストリームを復号することはできず、（例えば暗号化されていない復号鍵にアクセスできないことによって）そのような能力を有していなくてもよいということに留意されたい。特に、対称鍵と暗号化されていないデータストリームが持続されることはないかもしれない。このような場合、上述したように、暗号化鍵ストリームを復号することができる、既に承認されたエンティティによって新たな許可の承認がなされてもよい。
【００９３】
セッション鍵の復号モジュールは秘密鍵を使って非対称的に暗号化された鍵ストリームを復号するためのロジックを含む。このロジックは有形のコンピュータ読み取り可能なストレージに格納される、コンピュータ読み取り可能な指示の形式であってもよい。このコンピュータ読み取り可能なストレージは、汎用な処理エンティティに対して復号を実行するよう指示を与える指示を含む。公開鍵１２０を使って非対称的に暗号化された第一鍵ストリームを受信すると同時に、セッション鍵の復号モジュールが（例えばＲＳＡなどの）アルゴリズムを適用して暗号化鍵ストリームを復号し、第一対称暗号化鍵ストリーム１１０、Ｓnを読み出す。
【００９４】
セッション鍵の復号モジュールはビデオストリーム復号モジュール４５０を含み、モジュール４５０はネットワークインターフェースによって得られる暗号化ストリームデータを復号するための、上記したコンピュータ読み取り可能な指示形式のロジックを含む。この実施例では第一対称暗号化データストリーム１１５が受信され、暗号化されたデータＳn（Ｖa）のシーケンシャル部分を含む。
【００９５】
一実施例として、暗号化されたデータＳn（Ｖa）の各シーケンシャル部分は、対応する一以上のアプリケーション層パケットに送信される。このアプリケーション層パケットは、例えば暗号化されたデータＳn（Ｖa）の特定のシーケンシャル部分についての特定の時系列の値を示すタイムスタンプなどのタイミング情報を含むことができ、また同様に鍵インデックスを含むこともできる。復号された対称暗号化鍵ストリームＰk（Ｓn）の対称暗号化鍵Ｓnは、例えばタイムスタンプや鍵インデックスなどの、それらの暗号化データＳn（Ｖa）の各シーケンシャル部分に対する時間参照系と関連付けられる。
【００９６】
鍵同期モジュール４３０の検索により、各アプリケーション層パケット内、本実施例では、暗号化データストリームの各ＲＴＰパケットのヘッダ内で鍵インデックスを識別する。必要に応じて、鍵同期モジュールがヘッダ内のタイムスタンプを識別することもできる。鍵同期モジュールは暗号化データストリームのそれぞれ特定の部分に対応する鍵ストリーム内で鍵を発見する。この目的を達成するため、鍵同期モジュールは鍵インデックスを検索する。この鍵インデックスは暗号化鍵ストリームの暗号化されていない部分に存在する場合もあるが、直近の実施例では鍵ストリームの暗号化された部分に存在する。セッション鍵の復号モジュール４４０は暗号化鍵ストリームの暗号化部分を復号するので、鍵インデックスは鍵同期モジュールによって検索可能である。必要に応じて、鍵同期モジュール４３０は暗号化データストリームからのタイムスタンプデータを利用し、データの対応する部分に近い（例えば特定の閾値内にある）（存在する場合は）タイムスタンプを有する鍵のみを検索することによって、復号される鍵の検索を絞ることができる。あるいは、鍵同期モジュール４３０はそのタイムスタンプを使って開始点を選択することができ、そしてタイムスタンプの時間からさらに進むことによって鍵ストリームを検索することができる。鍵同期モジュール４３０はまた、特にどの程度の長さの非対称鍵が使用されるのかということ、すなわち、暗号化データストリームのどの程度のものであるのかということを導き出すことができる。例えば、ＲＴＰパケットが（先のものに比べて）新しい鍵インデックスを指し示す場合、鍵同期モジュール４３０は、ＲＴＰパケットが新たな鍵インデックスを有するまで、対応する鍵をアサインすることができる。または、鍵同期モジュール４３０は鍵ストリーム内に格納された鍵についての存続期間情報を使用して、どの程度の期間、その鍵が使用されなければならないかを決定することができる。鍵同期モジュール４３０はまた両方を使うことができ、例えば暗号化されたデータストリーム内で新規の鍵インデックスが発見されるか、または存続期間が尽きるかのいずれかまで鍵を継続的にアサインすることができる。鍵インデックスの代わりに、鍵同期モジュール４３０は他の値を例えばタイムスタンプのみに一致させてもよい。
【００９７】
ユーザーシステム４００はストリーム復号エンジン４５０、この実施例ではビデオストリーム復号エンジンをさらに含むことができるが、これは他のタイプのストリームデータを復号するためのものとすることもできる。このストリーム復号エンジン４５０はネットワークインターフェースから受信した暗号化ストリームデータ（この実施例では、これは第一対称暗号化データストリーム１１５に対してなされる）に復号アルゴリズムを適用するためのロジックを含む。本実施例では、ストリーム復号エンジン４５０はエージェントステーション６５にあり、汎用処理エンティティに対して復号を行うように指示を与える指示を含む、例えば有形のコンピュータが読み取り可能なストレージに格納されたソフトウェアコードを含む。この目的を達成するため、この実施例ではビデオアーカイブサーバー７０から受信される暗号化データＳn（Ｖm）のシーケンシャル部分を含む、暗号化ストリームデータが受信されて、もし分割されていなければ、その暗号化データＳn（Ｖm）のシーケンシャル部分に分割される。
【００９８】
概して言えば、ストリーム復号エンジン４５０は復号アルゴリズムを適用し、それによって暗号化ストリームデータが復号鍵ストリームを使って復号される。この特定の実施例では、ストリーム復号エンジン４５０は暗号化データＳn（Ｖm）の各シーケンシャル部分について、鍵インデックス、タイムスタンプまたはその両方を抽出することによって、そしてそれを鍵同期モジュール４３０に提供することによって、暗号化データＳn（Ｖm）のシーケンシャル部分を復号するための対称鍵ストリームから適切な対称鍵Ｓnを識別する。それに応じて、鍵同期モジュールはストリーム復号モジュール４５０に対し、暗号化データＳn（Ｖm）のシーケンシャル部分を復号するための適切な鍵Ｓnを提供することができる。その後、ストリーム復号モジュール４５０は（例えばＡＥＳ１２８ビットなどの）復号アルゴリズムを適用し、暗号化データのシーケンシャル部分において暗号化されたデータストリームの特定のシーケンシャル部分を読み出す。これは、例えばそれらがネットワークインターフェースから受信されるときに（それらはバッファリングのため、または後で同様に復号するためローカルに格納されてもよく、この場合、それらはローカルメモリから受信されてもよい）、暗号化データＳn（Ｖm）の各シーケンシャル部分について連続的に繰り返される。
【００９９】
この特定の実施例では、ストリームデータはビデオデータである。そのように復号されたデータは次に、ストリームデコーダーモジュール４６０に送られる。ストリーム復号モジュール４６０は例えばこの実施例では、シーケンシャル部分（Ｖa，Ｖb，Ｖc，．．．）の形式で現在暗号化されているストリームデータを受信する音声デコーダーやその他のものを含むことができるが、本実施例では例えばビデオデコーダー（例えばＭＰＥＧ４／ＡＶＣデコーダー）であり、それらをディスプレイに表示するためにデコードすることができる。
【０１００】
他の実施例についてこれから説明する。別の一つのアーキテクチャとして、非対称的に暗号化された鍵ストリームデータを、信頼できないネットワーク４５を通じてアクセス可能な別個の鍵サーバー３００に格納することができる。図１０に関して、図示した実施例におけるシステム１０は（例えば、クラウドサービス内でデータアーカイブサーバー７１と呼ばれるものと一緒に）一つ以上の物理データサーバーを含むことができる。このサーバーは、入ってくるデータフィード２２５を受信し、これらのフィードを格納するか、またはリターンフィード４２５を経由してユーザーまたは購読者に対し、即座にこれらのフィードを提供する能力を有する。リターンフィード４２５はデータサーバー７１によって提供され、同時に鍵サーバー３００は上記した非対称的に暗号化された鍵ストリームなどの暗号化鍵ストリーム２７５を安全なデータベース内に格納する。鍵サーバー３００は特定のリターンフィード４２５を復号するための暗号化鍵２７５ａに安全にアクセスし、さらに許可を受けられるユーザー／購読者に暗号化鍵２７５ａを送信することができる。なお、リターンフィード４２５はデータアーカイブサーバー７１に入るフィード２２５と同一であってもよく、そのフィード２２５は暗号化コンピュータシステム３１によって送信される暗号化データストリーム２２５であることに留意されたい。暗号化鍵２７５ａとリターンデータ４２５は、ユーザー／購読者がライブフィードをストリームしたいかどうか、あるいはデータアーカイブサーバー７１内にアーカイブされたフィードを見たいかどうかを問わず、ユーザー／購読者に送信される。このように、データビデオアーカイブサーバー７１は、例えばその場ですぐ再生するため、ストリームを受信して即座にストリームデータ（そして必要に応じて他の実施例では暗号化鍵ストリームデータ）をエージェントステーション６５に対して再放送するための再送信技術で構成される。有利なことに、十分な帯域幅を備えるデータアーカイブサーバー７１は、それゆえ、ストリームデータのアーカイブと再送信とを同時にすることができ、エージェントステーション６５に対して（場合によっては鍵サーバー３００と並行して）単一の接点としての機能を果たすことができる。
【０１０１】
データアーカイブサーバー７１は、暗号化された形式４２５で格納されるストリームデータを含む。なお当然に理解できることではあるが、暗号化されていない形式のデータをサーバーが維持する場合と比べて、そのような暗号化によって、格納されたコンテンツに対して権限のない団体がさらにアクセスできないようにすることができる。さらに、データアーカイブサーバー７１の記憶媒体またはそれらが収容されている施設でさえも、破壊されたり、またはそうでなければ不正アクセスされたりした場合に、それらの暗号化されたコンテンツは攻撃者予備軍に対してアクセスできないままである。
【０１０２】
引き続き図１０を参照すると、一つ以上のデータ源５０がストリームデータ１０１を生成し、ストリームデータ１０１は暗号化コンピュータシステム３１に提供される。暗号化コンピュータシステム３１は、この実施例では外部の鍵源３５０によって提供される、対称暗号化鍵でストリームデータ１０１を暗号化する。鍵源３５０は暗号化コンピュータシステム３１の施設であってもよく、または信頼できる接続を通して信頼できる外部サービスによって提供されてもよい。鍵源３５０は暗号化コンピュータシステム３１に一つ以上の対称暗号化鍵ストリーム１７５を提供する。暗号化コンピュータシステム３１はストリームデータ１０１を暗号化するために対称暗号化鍵ストリーム１７５を使用し、同様に、ストリームデータ１０１へのアクセスと関連付けられた公開鍵を使ってそれらを暗号化する。その後、暗号化鍵ストリーム２７５が暗号化コンピュータシステム３１によって鍵サーバー３００に送信される。この実施例では、その鍵（鍵ストリーム）は、鍵サーバーに格納される前に、非対称暗号化を使って暗号化される。コンテンツへのアクセスが許可されたユーザーの公開鍵を使って鍵ストリームを暗号化する。別個の鍵ストリームは、データへのアクセスを許可された各ユーザーと、各データストリームとに対して生成される。
【０１０３】
ユーザーはユーザー／購読者インターフェース５００を経由してサービスに接続するのが通常である。ユーザーは（ユーザーの各暗号化鍵ストリームにアクセスを提供することに加えて）鍵サーバー３００によって提供される鍵検証機能を経由してデータアーカイブサーバー７１内に格納されたコンテンツにアクセスすることができ、それと同時に、データアーカイブサーバー７１はリターンデータ４２５をストリーミングするか、またはそうでなければ移動させる。例えばユーザーの公開鍵で暗号化された鍵ストリームを有するユーザーのみが、暗号化データストリームや鍵ストリームにアクセスできることを確保するため、本明細書で説明した検証方法または既知の検証方法を使用することができる。通常は、例えばユーザー／購読者のワークステーションのローカルで、本明細書に提供した技術を使うなどして、データストリーム復号モジュール４５０を使ってその復号が起こる。
【０１０４】
データストリーム１０１は、ビデオまたは他のマルチメディアのデータを含むことができる。なお当然理解できることであるが、他のタイプのデータフィードまたはデータストリームが、必要に応じて他の実施例において同様にデータストリーム１０１内に含まれてもよい。そのようなデータフィードは、開示されているか専有されているかに関わらず、ビデオ、音声、テキストまたは任意のフォーマットを使って表現されたりカプセル化されたりした任意の他のデータの任意の組み合わせを非限定的に含むことができる。加えて、ユーザー／購読者に対してストリーミングされるリターンデータ４２５は、データアーカイブサーバー７１内にあらかじめ格納され、無事に認証されたユーザー／購読者のインターフェース５００に対してオンデマンドで提供されてもよい。同様に、リターンデータ４２５は、そのユーザー／購読者インターフェース５００にストリーミングされるすぐ前に生成されてもよい。
【０１０５】
任意のデータ源５０から実施例に導入されたデータストリーム１０１と、任意のあり得る安全な暗号化トランジット手段を通じて実施例に導入されたデータストリーム１０１とは、その後、暗号化コンピュータシステム３１に移動される。暗号化コンピュータシステム３１は、鍵ストリーム１７５を使って受信したストリーム１０１を暗号化する。ここで鍵ストリーム１７５はデータストリームの復号に使用することもできる。
【０１０６】
さらなる一実施例として、様々な暗号化のスキームおよび範囲の中から選択するため、パラメータはユーザー／購読者インターフェース内で規定されてもよい。本願明細書の任意の実施例に関して、別段の定めがない限り、または技術的に実行不可能なものでない限りは、暗号化の仕様（例えばＡＥＳ−１２８，ＡＥＳ−１９２，ＡＥＳ−２５６）、署名または鍵交換（例えばＲＳＡ  ２０４８）または整合性チェック（例えばＳＨＡ−２５６暗号学的ハッシュ関数）について、技術上の特定の限定は想定されない。
【０１０７】
別の一実施例として、暗号化ポリシーは、ビットストリームの仕様または暗号化するためのビデオストリームのフォーマットを考慮することによって有利に実装され得る。例えば暗号化は、暗号化されていない様々なシーケンスのヘッダ３３０，３３０’および、基本的に価値あるメタデータをあまり含まないシーケンストレーラー３３２をそのままにして、ストリームの様々なシーケンスペイロード３３１，３３１’に対して排他的に向けられてもよい。なお当然容易に理解できることであるが、この概念は、ビットストリームの仕様または階層の低層に対し、より大きな区別および粒度で適応および適用されてもよく、したがって、この概念が個々のシーケンスペイロード３３１のコンテンツに向けられてもよい。このような場合、個々のフレームのヘッダ３３３とトレイラー３３５は暗号化されないままであってもよいが、他方でフレーム３３４，３３４’自体は、一つ以上の鍵２７５で暗号化される。同様に、画像ヘッダ３３６とトレイラー３３８を暗号化されていない状態にしたまま、暗号化鍵２７５が個々のフレーム３３４の画像ブロック３３７，３３７’に対して排他的に割り当てられてもよい。このようなスキームのアプリケーションは、補足のヘッダデータを暗号化しないことによってではなく、上述した基本的な原理を維持しながら、すなわち送信するデータのボディまたはペイロードを暗号化することによって他のフォーマットを包含するよう適合されてもよい。補足のヘッダデータのコンテンツは上記ペイロードの任意の部分を明らかにするためにリバースエンジニアリングされない。なお、そのアプリケーションは、キャプチャされたもの５０または生成されたもの１０１のどちらか一方のストリーム１００の様々なフォーマットに適応および適用されてもよい。例えば、前述の概念をＭＰＥＧビデオ、およびこれらに限定されないが、特定のブロック、マクロブロック、Ｐフレームまたはシーケンス内のピクチャー群に対して適用することは、さらに検討されて実装されてもよい。同じような方法で、別個の暗号鍵２７５または鍵２７５のストリームが検討されてＩフレームおよびＢフレームに向けられてもよく、他方で残りのＭＰＥＧビデオシーケンスが暗号化されていない形式でビデオアーカイブサーバーに送信され、ビデオアーカイブサーバー内に格納され、ビデオアーカイブサーバーから読み出される。
【０１０８】
概して、本明細書で説明した通り、本明細書では鍵は鍵ストリームの文脈で使用され、それによって一連の暗号鍵１７５において、各鍵はストリーム１００の連続部分と関連付され、シーケンシャルアクセスまたはストリームの再生のために生成されてもよい。例えば、単一の鍵によって特定のビデオストリームの３０秒の復号を可能にすることができる。全体として、ビデオストリームの全体を再生するためには、ストリーミング用の鍵源２５０によって生成された鍵ストリーム１７５のすべての暗号鍵が、潜在的なユーザー／購読者にとって入手可能でなければならない（すなわち、彼はアクセスするために必要な権限／許可を有するか、またはその鍵を有していなければならない）。
【０１０９】
上記のテーマについて変形例も同様に考慮することができる。例えば図１２はストリーム１０１を復号して完全に見るために必要な２つの鍵のうち１つのみをユーザーが有するという仮定のシナリオを示す。見ようとしているストリーム１０１は、ユーザーがアクセスできない鍵（例えば、彼はその鍵を有する許可を与えられていないか、または、彼はその鍵を得ることを省略した）を必要とする中間の区分で３つの暗号化区分に細分されている。ビデオ（またはテキストまたは他のデータ）ストリームの一部または全部の区分にわたって、合成された視覚的または聴覚的な通知メッセージを置換することを含むが、これに限定されない様々な処理技術が考えられる。そのようなメッセージまたは不十分なアクセス特権マーカー２８８は、ユーザー／購読者に対して、復号するために必要な復号鍵１７５の欠如により、見ようとしているストリームの特定の区分について復号が実行されないということを知らせることができる。さらなる実施例として、その欠けている鍵１７５についての識別情報、または制限を解除するための他の情報が、不十分なアクセス特権マーカー２８８に供給されてもよく、それによって許可されたユーザー／購読者がサポートしたり他の救済をしたりするために、許可された職員に接触することができる。
【０１１０】
コンテンツが純粋にビデオ機能ではない要素を含むストリームに対して、同様の特権制限の処理プロセスが考えられる。図１３ａと図１３ｂは、ファイルのコンテンツの一部を復号するために必要な鍵、すなわち鍵２７５を保有しないユーザーに対してアクセスが許可されていない区分を含む、リッチテキストファイルを特色とする一実施例を示す。上述の実施例と類似した方法で、適切なアクセス特権の不足したマーカー２８８は、復号のために追加の鍵２７５を要するリッチテキストファイルの区分に現れる。
【０１１１】
特定の鍵ポリシーを使って実装および実施するためのストリーム１００のアクセスポリシーは、任意の適切なユーザーまたは要員によって適切なモジュール内に指定されてもよい。限定されない一実施例として、そのような機能は、一つ以上のストリームを管理する直接的責任を有する一人以上の個人がアクセス可能なユーザー／購読者インターフェース５００内に含まれてもよい。別の一実施例として、単一で、デフォルトのポリシーがすべてのストリームについて実施されてもよい。そのような鍵がユーザー／購読者に提供されることによるプロセスについては、さらに本明細書で議論する。
【０１１２】
一旦、鍵ポリシーが確認されたり特定されたりすると、鍵源２５０は暗号化コンピュータシステム３１が受信する鍵１７５を生成するか、そうでなければ供給することができ、暗号化コンピュータシステム３１は鍵１７５でデータストリームを暗号化する。一旦、データの暗号化が（事前に決定された任意のアクセスポリシーやサポートする暗号化スキームに従って）実行されると、実施例における暗号化コンピュータシステム３１は、一つ以上の暗号化鍵ストリーム２７５（データストリームを復号することのできる各ユーザーまたはユーザーの集団につき一つの鍵ストリーム）を、暗号化鍵ストリーム２７５を格納するための鍵サーバー３００の中に発行し、データアーカイブサーバー７１および／または、同時にユーザー／購読者インターフェース５００のどちらかに向けて送信するため、対応する暗号化ビデオ２２５（または他の暗号化されたデータタイプ）を準備する。実施例（あるいは状況）によっては、後者のユーザー／購読者インターフェース５００への同時送信が望ましい場合がある。すなわち、特定のストリームにおいてキャプチャされた、イベントのライブストリーミングであって、相当な数の同時購読の個々のユーザー／購読者インターフェース５００に向けたものが、別の面では、本願明細書に開示される従来のアーキテクチャ全体に過度のパフォーマンスを加えるような場合に、望ましい可能性がある。
【０１１３】
実施例では、暗号化コンピュータシステム３１は、クラウドまたはシステムレベルのメンテナンス要員によって暗号化コンピュータシステム３１を設定可能にするための機能を含むことができる。そのような機能は、これに限定されないが、暗号化データパケットを送信する宛先（例えばＵＲＬ）に関する設定情報を含むことができる。宛先は概して、一つ以上のデータアーカイブサーバー７１や一つ以上のユーザー／購読者インターフェース５００（後者は、エージェントステーション６５がデータをリクエストするための「ダイヤルイン」について責任を負う場合には必要ないかもしれないが）を含むことができる。なお当然理解できることであるが、追加的な一実施例として、一つ以上の宛先が一度に特定されてもよい。これは、例えば、後で読み出せるようにアーカイブサーバー内にストリームが格納される場合に加え、ストリームが複数の（他の）ユーザー／購読者５００によってシェアされるライブである場合などに起こり得ることである。暗号化コンピュータシステム３１は、既に本明細書で説明したように、ユーザー／購読者５００のユーザー証明書／公開鍵の暗号化を受信し、構成し、使用するためのロジックを含むことができる。ユーザーの検証に関してだけではなく、例えば公開鍵の使用などに関しても同様である。
【０１１４】
その構成設定を特定したり修正したりするための許可を与えることのみならず、暗号化コンピュータシステム３１内に含まれる様々な構成設定の性質は、特定の実施例のニーズにふさわしいものであるとして理解されるべきである。一実施例として、構成設定は例えばデータストリームに適用される様々な利用可能な暗号化方法および基準の中から選択する可能性を含む。暗号化データフィードを送信するための、一つ以上のデフォルトのデータアーカイブサーバー７１を特定するよい機会が同様に存在するかもしれない。同様に、暗号化コンピュータシステム３１内で利用可能な任意の一つ以上の構成設定が、適切なポリシー制限を受けてもよく、同時に、ユーザー／購読者インターフェース５００を通すときに、例えばサービスメンテナンス要員、ストリームを最初にアップロードするユーザー／購読者、およびそのストリームにアクセスする別のユーザー／購読者などの一人以上の関係者のみに特定の設定が共有されたり、あるいはアクセス可能にしたりすることができる。なお、当然に理解できることであろうが、多くの実施例では復号されたビデオストリームを（彼ら自身のそれぞれのユーザー／購読者インターフェース５００を通じて）見る個人は、暗号化コンピュータシステム３１に対して制御入力や、ある種の構成データを提供することはできず、そのような構成はネットワーク管理者やその他の信頼できるサービスメンテナンス要員に確保されている。このような構成設定は、アクセス可能である場合、ユーザー／購読者インターフェース５００の適切な部分または専用の部分内でアクセスされ、特定され、または見られてもよい。上述の内容を考慮すると、特定の実施例についての展開のニーズと一致して、任意のあり得る変更を想定して実装することができる。
【０１１５】
なお、当然理解できることであろうが、任意の数の可能な暗号化実施が、暗号化モジュール２００によって生成される暗号化鍵について想定されてもよい。また、当然理解できることであろうが、本明細書で説明したアーキテクチャの任意の部分を、任意の現存するまたは将来の暗号やセキュリティの標準（これに限定されないが、ＨＩＰＡＡ，ＨＩＴＥＣＨ，ＮＥＲＣ  ＣＩＰなどを含む）に準拠させることができ、さらに任意の一つ以上の特定のフィールドにおける使用に適合させることができる。さらなる実施例として、複数の暗号化タイプ、カテゴリおよび組み合わせは、例えばその実施例の管理者によってインターフェース５００を通じて特定されてもよい。他の受信ユーザー／購読者と暗号化フィードを共有することを目的とする特定の許可について同様に、ユーザー／購読者インターフェース５００内に規定されてもよく、このとき、その受信ユーザー／購読者がフィード４２５をダウンロード５０２し、フィード４２５の対応する鍵２７５と２７５ａとをダウンロード５０１し、ローカルで復号するために復号モジュールをエンゲージさせて、適切な宛先ディスプレイデバイス６００でそれらを開いて／表示する６０１ときまでは、フィードを暗号化されたままの状態にしておくことができる。
【０１１６】
特に大規模な実施例では、多数のデータストリーム２２５と（対応する）鍵ストリーム１７５とが存在するのが通常であり、ユーザー／購読者に提供され得る、暗号化鍵ストリーム１７５および対応する暗号化データストリーム２２５の両方の頑強なアクセス管理を実装するために必要なリソースを、鍵サーバー３００に装備することができる。ユーザーの認証機能は概して、任意の数の適切なユーザー／購読者の認証情報を受信する、ユーザー／購読者インターフェース５００内に実装される。さらに、そのような機能は概して、企業情報を保護するための強力な認証を供給することを視野に入れて、当業者によく知られている技術や最良の実施例を使う実施例において実装される。ユーザー／購読者インターフェース５００に対する認証プロセスは、実施例では、有利かつ個別にユーザー／購読者となる者の鍵サーバー３００への認証から考慮されてもよい。
【０１１７】
暗号化モジュール２００から（あるいは別の実施例として鍵源２５０自体から）鍵ストリーム１７５を受信することに加え、鍵サーバー３００はトランザクションを管理し、それによって一つ以上の鍵ストリーム１７５を読み出すためのユーザーのリクエストが、認証情報によって許可されるアクセス権限または許可に従って、実現されるかまたは否定される。したがって、鍵サーバー３００はインターフェース５００から、ログインと認証３５０の認証情報の少なくとも一部を受信し、それらを検証する。一実施例として、鍵サーバー３００によって無効な認証情報が受信された場合、鍵サーバー３００は対応するリクエストを拒絶し、ユーザー／購読者に対して、その認証試行が成功しなかったことについての理由を詳細に述べるエラーメッセージまたはステータスメッセージで応答することができる。既に述べたように、認証は、例えばＡＤＦＳを使ったり、識別プロバイダ（例えばＧｏｏｇｌｅ，Ｍｉｃｒｏｓｏｆｔ，Ｆａｃｅｂｏｏｋなど）を使ったりしてプロキシまたはアクティブディレクトリで行うことができる。
【０１１８】
（ユーザー／購読者によって示された認証情報が検証されて）ログイン試行が成功した後、ユーザー／購読者に対して、データストリームのコンテンツを入手するための、一つ以上の暗号鍵をリクエストして入手する機会が与えられてもよい。なお、当然理解できることであるが、実施例において、そのようなリクエストが示され、特定され、選択され、または定式化できるような、特定の選択インターフェースは異なっていてもよい。その選択インターフェースは、本明細書でさらに説明する鍵サーバー３００、ユーザー／購読者インターフェース５００およびビデオアーカイブサーバー４００の任意の組み合わせによって実装されてもよい。
【０１１９】
限定されない一実施例として、選択メニューがユーザー／購読者に提示されてもよい。このメニューは、様々な暗号化データフィードの各々と関連付けられたメタデータ（例えば氏名、ファイルサイズ、データおよびタイプなど）を表示することができる。この暗号化データフィードには、前述の認証情報を使ってアクセスすることができる。そして、一つ以上の鍵はリクエストするユーザー／購読者によって所有され、そうでなければリクエストするユーザー／購読者にとってアクセス可能である。一つ以上のフィードをストリーミングしたり転送したりするための始点および終点をさらに特定する可能性が、さらに提供されてもよい。前述の機能は、データストリーム２２５の性質がそれを可能とする場合（例えばリクエストする暗号化データフィードがビデオストリームに対応する場合など）、一実施例において実装されてもよい。
【０１２０】
別の一実施例として、鍵サーバー３００は、各ユーザー／購読者に対して、そのユーザー／購読者がアクセス可能な一つ以上の鍵ストリーム１７５を含むことができる。１セット、１シーケンスまたは一連の鍵ストリーム１７５は、単一の識別子の論理コンテナに分類することができる。この論理コンテナは、とりわけ多数の暗号化鍵２７５が生成２５１されたフィード４２５の任意の部分または全部を後で復号することなどを主題の目的として、組み立てられたりもしくは一緒に結合されたりする、複数の個別の暗号化鍵ストリーム１７５を含む。
【０１２１】
前述した認証情報の検証が成功したときに、またはその後のセッションの間の任意の段階において、読み出すための鍵または鍵ストリーム１７５の識別子は、通常はユーザー／購読者インターフェース５００によって鍵サーバー３００へのリクエストとして一実施例で提供されてもよい。
【０１２２】
鍵ストリームを供給する鍵サーバー３００によって、ユーザー／購読者の検索リクエストが成功したことに応答して、鍵サーバー３００はそのリクエストを受諾し、対応する鍵（ストリーム）１７５がリクエストしたユーザー／購読者のインターフェース５００へと送信され、その後それに応じて、その鍵ストリーム２７５を受信５０１する。したがって、鍵サーバー３００はリクエストされた識別子に対応する鍵または鍵ストリーム１７５を提供する。同様に鍵サーバー３００は、リクエストしたユーザー／購読者のインターフェース５００への転送を開始するため、インデックス数（index numbers）３２５を使って通常表示される構成要素であるファイルブロック上のビデオアーカイブサーバー４００に指示を同時に転送３２６する。ファイルブロックのインデックス３２５は、ビデオアーカイブサーバー４００から一斉に読み出すための暗号化フィード４２５の一部を表示するのが通常であり、それに応じて暗号化フィード４２５はユーザー／購読者インターフェース５００に送信される現行鍵によって復号される。
【０１２３】
実施例では複数の鍵サーバー３００が一つ以上の実装の戦略的目標に従って配備されてもよい。そのような目標として、例えば、唯一の鍵サーバー３００に過度に負担をかける輻輳（ふくそう）の転換または緩和を含むことができ、さもなければそれによって鍵サーバー３００のパフォーマンスに影響が出る、あるいは鍵を提供する負荷または特定の負荷を特定のトラフィック処理ポリシーの実装を通じて、一つ以上の別の鍵サーバー３００に迂回させることができる。ビデオアーカイブサーバー４００は暗号化モジュール２００から、実施例によっては最初のストリーム１００のアップロードのときに、暗号化データフィード２２５を受信する。ビデオアーカイブサーバー４００の実装は、アーキテクチャ、インフラストラクチャ、レイアウトまたは構成に関するどのような考慮によっても制約される必要がない。ビデオアーカイブサーバー４００は、本明細書でさらに説明する、ユーザー／購読者の認証情報のインターフェース５００による検証が成功したとき、暗号化データフィード４２５を出力４２６する。ビデオアーカイブサーバー４００の操作の重要な部分は、ビデオアーカイブサーバー４００の、鍵サーバー３００とのタンデム相互作用（図３を参照）であり、その鍵サーバー３００は、リクエストした（一度検証された）ユーザー／購読者に対して、ビデオアーカイブサーバー４００内に格納された、入ってくるフィード２２５を最終的に復号するために必要な暗号鍵２７５を発行する。なお、当然理解できることであるが、本明細書で説明した実施例の鍵ベースのアーキテクチャから生じる理由により、ビデオアーカイブサーバー４００が鍵サーバー３００と結びつけられる必要はない。同様に、ビデオアーカイブサーバー４００は鍵サーバー３００にごく接近して設置される必要はない（任意の安全な施設内にある必要もない）。なぜならば、任意のあり得る攻撃、侵害または他のビデオアーカイブサーバー４００の侵害だけで、危険な状態に陥ったり、またはビデオアーカイブサーバー４００が含む暗号化データフィード２２５に付随する脆弱性をもたらしたりすることはないはずだからである。したがって一実施例として、ビデオアーカイブサーバー４００と鍵サーバー３００とを、物理的に地球の反対側に配置してもよい。さらに、本明細書で説明した暗号鍵の実施例（および、図７で例示して説明したような、途切れ途切れに有効な暗号鍵の実施例）に基づいて、アーカイブサーバー４００は公的にアクセス可能なＦＴＰサーバーであってもよく、そのコンテンツの暗号化された性質は、対応する正しい暗号の復号鍵２７５ａを所有していなければ、ほとんど理解できないも同然である。一組のサーバー３００とサーバー４００とは、リンクされることのみが必要であり、検証に成功したユーザー／購読者に対して、対応する適切な鍵ストリーム２７５、２７５ａを供給するためにユーザーのリクエスト２７６ａを実現させるために協働し、直接的または（インターネットなどの）ネットワークを通じて相互接続されているかどうかは問わない。
【０１２４】
ユーザー／購読者の有効なリクエストがインターフェース５００から受信され、その鍵または鍵ストリーム２７５、２７５ａの検索操作（さらに本明細書で説明する）が鍵サーバー３００によって処理（２７９、２８０）されるとき、フィード検索操作（３２６、４０２）の対応するシーケンスが、ビデオアーカイブサーバー４００によって処理される（後者のシーケンスは、鍵サーバー３００との部分的な連携で発生する）。成功したフィード検索操作（３２６、４０２、４２６）の間、ビデオアーカイブサーバー４００は鍵サーバー３００から鍵インデックス３２５を受信３２６する。鍵サーバー３００によって発行３２６されるインデックス３２５は、さらなる実施例ではコマンドを含んだり、暗号化フィード４２５（またはその部分）を明確に識別するために必要な識別子を含むことができたりする。暗号化フィード４２５は検索のために要求され、現行鍵２７５ａを使用してそれに応じて暗号化される。その暗号化フィード４２５および現行鍵２７５ａの両方が、リクエストしたユーザー／購読者インターフェース５００に同時に送信されてもよいが、例えば本明細書で説明した同期技術を使う場合、それらが同時に送信される必要はない。別の一実施例として、インデックス３２５のリクエストが、ユーザー／購読者インターフェース５００によってビデオアーカイブサーバー４００に対して直接発行されてもよく、それとともに、そのリクエストについて同時の独自検証３５０を鍵サーバー３００で実施することができる。
【０１２５】
読み出す暗号化フィード４２５が一旦識別され、暗号鍵または鍵ストリーム２７５ａに対応するインデックス３２５が確認されると、暗号化フィード４２５がビデオアーカイブサーバー４００からユーザー／購読者インターフェース５００に送信され、後者は通常、ユーザー側のユーザー／購読者のワークステーション上で実行する。本明細書で説明したように、暗号化フィード４２５に加えてフィード全体を復号するのに必要な鍵２７５ａ（特にフィード４２５が有限である場合）、あるいは鍵２７５ａのシーケンスまたはストリームがインターフェース５００に対して同時に送信されてもよい（２８０、５０１、４２６、５０２）。
【０１２６】
鍵２７５のシーケンシャル番号をユーザー／購読者インターフェース５００に送信することにより、それぞれが暗号化フィード４２５の間欠的な部分を復号するが、これが望ましい場合がある。そのような間欠性は、ビデオストリームなどのフィードの連続する断片や部分を復号するために異なる鍵２７５ａが必要となる場合や実施例で特に有益である（図７）。さらなる限定しない実施例として（図５）、複数の鍵２７５の断続的な送信によって提供される制御可能性は、同様に、別々の部分４２５ａまたはすべての対応するビデオストリーム４２５が特定のポリシーに従って検閲される必要のある場合に活用することができる。そのようなポリシーによって保護される限定されない実施例は動画におけるシーンを含むことができる。この動画におけるシーンは、図形または露骨なコンテンツ、監視ビデオ内の興味のある時間範囲または領域、法の執行によって分類されるコンテンツまたは、他については、検閲されるコンテンツを含むその他のビデオファイル（図８、図９）に限定されない。
【０１２７】
図５に関して、当然に理解できることであるが、暗号化フィード４２５ａの全部または個別の部分と暗号学的に適合する鍵または鍵ストリーム２７５ａは、十分な時間オフセット５５５またはリードタイムをとって、ユーザー／購読者インターフェース５００のノードで受信されるべきであり、フィード４２５ａの対応する個別の部分の受信と復号モジュール５００の操作とを適切に構成しかつ適応させて、復号されたフィード５７５をそれに続くディスプレイ６００にタイムリーに生成することを確保することができる。別の一実施例として、ストリーム４２５ａとその対応する鍵２７５ａの両方のかなりの部分がユーザー／購読者インターフェース５００のノードで受信される前に、復号や再生が開始されないようにするため、適切なセーフガードまたはバッファリング機構が実装されてもよい。理想的にはそのような一実施例は、数ある中でも、ネットワークの行動に基づく進行予測とユーザー側の計算リソースとを使って、（鍵２７５、２７５ａおよび暗号化フィード４２５、４２５ａの任意の未処理量の）任意の残りの転送が再生時間を超えないで、時間ウインドウ内で完了することを保証しようとするべきである。そのようなタイムリーな配信を保証することができない場合、例えば他のユーザー／購読者からの新規のリクエストの処理の遅延や、一時的または最終的に、リクエストされた暗号化フィード４２５の、より小さい帯域幅集中型のバリアント（variant）にシフトすることなどの、全体のユーザー／購読者の体験に与える悪影響を減らすようにシステム側のステップを取られてもよい。
【０１２８】
一実施例として、フィードの特定の区分や部分を復号するための暗号鍵２７５ａは、その鍵が適合するフィード４２５ａの部分との組み合わせるための（全ての場合か（ライブ）ビデオ再生の場合であるかを問わず、十分な加工／処理の時間マージンオフセット５５５内の）インターフェースで受信されるべきではない。復号は起こらない可能性があり、すなわち、欠落している暗号鍵２７５ａが適合するフィードの部分に関しては何も起こらない。これは特に、本明細書の実施例についてさらに説明する不十分なアクセス特権マーカー２８８に対する実装およびサポートが欠落している一つ以上の実施例の場合にあてはまる。したがって、そのような実施例に関しては、フィードの対応する部分が暗号化されかつ回復できない「パッチ」のままであってもよい。一実施例として、復号されていないかまたは解読できないビデオは、その「パッチ」の継続時間にわたって再生されないだけではなく、例えばブランクスクリーンまたは他の適切なプレースホルダーなどの、特に前述のマーカー２８８よりも少ない情報を含むものと置き換えられてもよい。なお、当然理解できることであるが、とりわけ前述したことと本明細書で詳細に説明したことの観点から、本明細書で考慮するアーキテクチャについて、アーカイブサーバー４００は比較的最小限のセキュリティポリシーによって制御されるシンプルなＦＴＰサーバーを有利に含むことができる。ビデオのわずか数秒またはリッチテキストのコンテンツの数パラグラフのみを構成する小さな侵害を含む可能性のあるシナリオでは、単一鍵の侵害でさえも、悪意あるユーザーに暗号化フィードの個別の部分４２５ａを復号できるようにする可能性がある。
【０１２９】
別の一実施例として（特に前述の解読できないパッチの発生が避けられる場合）、鍵ストリーム２７５が、個々の暗号鍵２７５の断続的かつタイムリーな発行よりも好ましい場合がある。従って、ストリームにおける鍵２７５のバルク転送が、いくつかの理由で望ましい場合がある。この理由として、ビデオストリーム再生において発生し得る妨害を最小化できること、効率性または潜在的なパフォーマンスを高められること、または、送信される個々の鍵の数を単純に減らせることを含むが、これらに限定されない。
【０１３０】
本明細書で開示した様々なモジュールに関する議論の中で述べたように、ユーザー／購読者インターフェース５００は、実施例によっては最小限必要なクライアント、または包括的なアプリケーションであってもよく、このアプリケーションはユーザー／購読者の場所で実行し、そのユーザー／購読者がセッションを開始（ログイン）および終了（ログアウト）できるようにする。任意の可能性のあるセッション間の相互作用も同様である。そのような相互作用は実施例によっては本明細書で述べたすべての機能的な可能性を含むことができる。例えば、データストリームをアップロードしたり転送したりすること、共有ポリシーを特定すること、転送リクエストを開始すること、およびもっと顕著には、鍵や鍵ストリーム１７５や復号４２５する暗号化データフィードに対応する暗号化鍵ストリーム２７５の検索／受信、暗号化ビデオフィードの受信、およびタンデム暗号鍵の処理／復号し、暗号化データを暗号化されていないものにし、ディスプレイ６００が理解できるデータにすることを含むが、これに限定されない。ビデオアーカイブサーバー４００に存在する特定のフィード４２５への有効なアクセスの後、暗号化フィードの個別の部分と紐づけられた一つ以上のインデックス３２５値を発行することによって貧弱なネットワーク品質を克服する必要があるとき、ユーザー／購読者インターフェース５００は、その暗号化フィード４２５の一部または全部のアーカイブサーバー４００からの再送信をリクエストしてもよい。
【０１３１】
「ユーザー」と「購読者」という用語は、様々な集団の役割が重複する本明細書では相互に交換可能に使用することができる。ユーザーが特定のストリームまたはビデオアーカイブサーバー４００内に格納されたコンテンツを購読したい場合、彼はそのコンテンツを復号するために必要な鍵または鍵のストリーム１７５または暗号化鍵ストリーム２７５へのアクセスが認められるようにリクエストすることができる。彼は彼がアクセスすることのできるユーザー／購読者インターフェース５００のノードを通じてこれをすることができ、ユーザーインタフェースを、ビデオアーカイブサーバー４００内に格納された選択可能なカタログまたは入手可能な暗号化ビデオフィード４２５のリストに提供することができる。彼はそこから購読リクエストを定式化することができる。そのリクエストは検証と承認のために、ユーザー／購読者インターフェース５００から鍵サーバー３００へと安全に送信される。承認にあたり、暗号化フィードを復号するため、購読者は鍵または鍵ストリームを受信することができる。そして彼はそれに応じてビデオを購読することができる。さらなる実施例として、暗号化フィードに適合する鍵（ストリーム）が現行のおよび／または有効なままであることを確実にするため、管理に関連するタスクをユーザー／購読者インターフェース５００に分け与えることができる。これは特に暗号化フィード４２５にとって重要であり、その暗号化フィード４２５の対応する鍵１７５は断続的に有効であるか、または定期的に変化さえする。特定のユーザー／購読者インターフェース５００と鍵サーバー３００とによって、鍵１７５の任意の必要な再リクエスト、リフレッシュまたはアップデートと他の付随する検証が実行されてもよい。特定の暗号化フィード４２５を復号するための鍵１７５へのアクセスが、特定のポリシーの結果としてもはや許可されるべきでない場合、リクエストした購読者にユーザー／購読者インターフェース５００内で適切なメッセージが通知されてもよい。
【０１３２】
実施例では、ユーザー／購読者インターフェース５００でコンテンツ４２５を受信したい（そのようにするための許可ポリシーと一致する権限を有する）個人は、正確に言えば、コンテンツの一つ以上のレイヤーに対する「購読」と言われても良い。これは特に、コンテンツを復号するための暗号鍵を受信することなどによって、ストリームのコンテンツ６０１への権限が与えられたそれらの個人に言えることである。購読の持つ一時的な、契約上の、範囲の定められた性質は実施例でさらに強制される。この実施例では一人以上の個人に再分配することのできるストリームや他のファイル（図１３ａと図１３ｂを参照）の一部（例えば、図１２に示すような時間または他の量的に制限されるセグメント）のみ復号するのに有効な、一つ以上の暗号鍵が有効である。
【０１３３】
ユーザー／購読者インターフェース５００に関連するトランザクションは、このようにログインや認証手続きを必要とするのが普通であり、例えばユーザーネーム／パスワードの一組を介するなどの、当業者に知られた任意の適切な方法を使って実装されてもよい。トランザクションが成功すると、ビデオアーカイブサーバー４００上で入手可能な、ユーザー／購読者が復号する権限を有するコンテンツを、ユーザー／購読者に復号させられる（あるいは暗号化コンピュータシステム３１から直接的にライブストリーミングを受信する）ようにするのが通常である。
【０１３４】
認証が成功することにより、ユーザー／購読者が暗号化フィード４２５を検索できるようするのに適したすべてのアクションを含む実施例と、ユーザー／購読者とが関係するようし、別の実施例では暗号化フィード４２５を格納できるようにする。ファイルまたはストリームがローカルで開かれるとき、インターフェース５００はクラウドから受信した暗号化データフィード４２５，４２５ａを復号し、ローカルで開いたり再生したりするための、ローカルでアクセス可能なユーザー／購読者のメモリにそれを入れる。
【０１３５】
なお、当然理解できるように、インターフェース５００によって使用されるパスワードは、ユーザー／購読者のＩＤを検証するためにローカルで利用されてもよい。そのパスワードは、同様に、インターフェース５００によって、別の特別に安全なパスワードサーバーに送られ、その結果、そのように権限の与えられた（すなわち彼は鍵２７５を得ることによって権限を有することができた）任意のユーザー／購読者は、アーカイブサーバー４００上に存在する特定の暗号化データフィード４２５をリクエストすることができ、さらにそのフィードを復号５５１したり、開いたり、そうでなければフィードにアクセス６０１したりすることができる。
【０１３６】
認証が成功すると、暗号化データフィード４２５はビデオアーカイブサーバー４００によって、受信ユーザーの一人（ユニキャスト）または複数人（マルチキャスト）に供給される。実施例では、特定のフィードを復号５５１したり、特定のフィードにアクセス６０１したりすることを要求する複数の受信ユーザーの各々に、求まれている鍵または鍵ストリーム２７５が提供されてもよい。なお、当然理解できることであるが、特定の実施例では、単一の鍵または鍵ストリーム２７５が鍵源２５０によって生成されてもよく、また特定のフィードを復号５５１するためにユーザー／購読者インターフェース５００に単一の鍵または鍵ストリーム２７５が提供されてもよい。別の実施例として、たとえそうすることが技術的に可能である場合でも、異なる暗号鍵または鍵ストリーム２７５を使ってそのフィードを再暗号化（繰り返される可能性がある）することよりも、むしろ同じ暗号化フィードを復号するための複数の鍵または鍵２７５の並列セットを生成することが有益であるかまたは望ましい場合がある。そのような鍵２７５の並列セットを発行／生成することや、それらを鍵サーバー３００からユーザー／購読者に送信することは、例えば柔軟性のある、またはさらに頑強なアクセスポリシーを設けて強化するという点においては有益となり得る。その際、所与の鍵（ストリーム）２７５が権限のある受信ユーザーの一つの集団には発行されてもよいが、別の集団には発行されなくてもよい。これは受信ユーザー／購読者のセットを特定するため、復号アクセスを許可し、無効にし、または条件付きでアクティブにすることによって、有益なスキームを提供することができる。そのようなアクセスポリシーの差別化が望ましい場合がある。例えばその場合とは、一方で、一人以上のユーザー／購読者に対し、ビデオ（例えば図７）の所与の期間またはファイルの一部を復号することのできる鍵２７５とともに、暗号化フィード４２５へのアクセスを提供したり、他方で、他のユーザー／購読者に対して全体のフィードのための単一鍵２７５を提供したりする場合である。
【０１３７】
本明細書でさらに説明するように、前述のアクセスポリシーの差別化はさらに、ビットストリーム（図１１）の特定の部分またはレイヤーのみを対象とすることができる任意の暗号化スキームと並行して、または任意の暗号化スキームと区別して実装されてもよい。
【０１３８】
前述のアクセスポリシー差別化の概念の限定されない一つのシナリオとして、様々な範囲の場所２５からの、一つ以上のセキュリティカメラフィードへのアクセスが提供される捜査官を考慮してもよい。その捜査官はそれに応じて彼に割り当てられたユーザー／購読者インターフェース５００を使って仕事をする。そのインターフェース５００は本明細書で実質的に説明したように機能する。彼のインターフェース５００は、一旦ローカルで復号されると、彼が様々なカメラによってキャプチャされたフレームを見たり、一時停止／停止したり、比較したり、関連付けたり、または再生したりすることができるようにする機能をさらに提供することができる。しかしながら、ならず者の捜査官は彼の権限を越える方法で、そのソース５０によってキャプチャされた特定の個人をストーキングするかまたは活動を観察することによって、彼の立場を悪用したくなる可能性がある。そのような可能性に対処するため、すべての捜査官に実装されるアクセスポリシーによって、所与の任務または特定の施設２５内のすべてのビデオ監視カメラから集められるすべてのフレームを復号する能力を捜査官に付与することができ、そのコンテンツがビデオアーカイブサーバー４００内に格納される。同様に、およびその任務にしたがって、警備員（あるいは彼のビデオウォールを提供したり、さもなければ備える、特定のユーザー／購読者インターフェース５００に対応するネットワークノード）に割り当てられた所定のポリシーおよび鍵（または鍵２７５）が、前の１時間内にキャプチャされた監視ビデオのみを復号して見ることができるように彼を制限したり、あるいは警備員のシフトの最初からのみ復号して見ることができるようにしたりすることができる。
【０１３９】
別のシナリオでは、公共の場（または公共の場を一部に含むもの）から監視カメラ映像を集めるビデオカメラが法律によって禁止される可能性がある。しかしながら、組織のセキュリティのニーズによっては、任意の刑事犯罪またはセキュリティを危険にさらす事件がキャプチャされて、犯人が特定されて起訴されることを先制して確実にするため、そのエリアの占拠を強く動機づけする可能性がある。そのような場合、一連のカメラ５０は、様々なストリーム１００をキャプチャ１０１し、同時にストリーム１００を暗号化モジュール２００によって暗号化２０１する。そして、その結果生じる暗号化フィード２２５はビデオアーカイブサーバー４００に送信２２６される。暗号化フィードを復号するための鍵２７５は鍵サーバー３００に格納されてもよく、通常は法執行機関当局にのみアクセス可能であり、その法執行機関当局の役割は、ストリーム１００からキャプチャされた（またはキャプチャされる可能性のある）出来事に関連する任意の事件を調査することである。このシナリオの変形例として、法執行機関の職員が高画質、高帯域幅のストリーム５７５の変形例を見る６０１ことができるようにする鍵２７５を（法的執行部隊に特有のユーザー／購読者インターフェース５００を介して）、通行人の顔を不鮮明にする低品質の変形例のための鍵とともに提供することを含むことができ、これは特定の地域に割り当てられたプライベートのセキュリティ要員（プライベートなセキュリティ要員に固有のユーザー／購読者インターフェース５００を介してフィードを見る、プライベートセキュリティ要員に）に対して提供される。別の一実施例として、法執行機関に提供される鍵２７５はプライベートなセキュリティ要員に提供されるものとは異なる鍵サーバー３００に格納されてもよい。その異なる鍵サーバー３００は、さらなる実施例において完全に異なる管理構造を有することができる。
【０１４０】
さらなる実施例として、法執行機関は鍵源２５０および鍵サーバー３００を直接的に管理してもよい。そのような一実施例として、鍵２７５は鍵サーバー３００（この場合鍵源２５０を含んでもよい）と暗号化モジュール２００との間の安全な接続を通じて、法執行機関によって簡潔かつ短命に共有されてもよい。この共有する時間ウインドウの間、暗号化モジュール２００はストリーム１００を暗号化ビデオフィード２２５に変換し、それ２２５をビデオアーカイブサーバー４００に送信する。
【０１４１】
単一のまたは並列のセットの有効な鍵２７５が単一の暗号化フィードについて生成され発行されるかどうかに関わらず、ユーザーは通常、ビデオアーカイブサーバー４００から暗号化フィードを受信することができる。なお当然理解できることであるが、実施例によっては、ユーザー／購読者インターフェース５００は暗号化モジュール２００から直接的に暗号化フィードを受信することができるが、ライブでストリーミングされるビデオストリームを含む暗号化ストリームについて、アーキテクチャ最適化のために、暗号化ストリームがビデオアーカイブサーバー４００内部に格納され、ビデオアーカイブサーバー４００からユーザー／購読者インターフェース５００（または複数のそれら）に対して発行されるのが望ましく、このように各モジュールのそれぞれの役割の励行を促している。そうすることにより、原理上は待ち時間を増やす可能性があるものの（その待ち時間はライブストリーミングされようとしているフィードにとって特に望ましくないものである）、構造および配置について努力することにより、そのような望ましくない影響を比較的無視できる状態にするため、そのような待ち時間を最小化して相殺することができる。
【０１４２】
各モジュールの役割を厳格に実施することにより、モジュール間の相互作用に加えて、各モジュールに固有の機能と特殊性とを最適化することによって、操作上の負担を集中させる機会を提供する可能性もある。例えばビデオアーカイブサーバー４００は通常、受信を処理しなければならず、とりわけ、一度に大容量のデータを供給しなければならない。結果として、帯域幅の考慮は特に重要であり、とりわけ暗号化フィードが同時に送信されなければならない多数のユーザー／購読者インターフェース５００で重要である。この子試みにおいて当然に理解できることであるが（図５に注目されたい）、そのようなフィードの送信が、ユーザー／購読者インターフェース５００に対する復号鍵２７５の発行と大抵同時に（シナリオによっては断続的に）発生するであることを確保するが、十分な優先的な遅延または時間オフセット５５５が鍵２７５ａの受信と、復号に適合するフィード４２５ａの受信とを確実に分離するということを確保することは考慮すべき重要なことである。同様に、鍵サーバー３００は通常、ネットワーク内の様々なノードに配置された数多くのユーザー／購読者インターフェース５００に由来するリクエストを処理する。よって鍵サーバー３００はその操作を実行し、最小限の応答時間と待ち時間で最適にそのようにする必要がある。鍵サーバー３００がユーザー認証を実行することと、鍵リクエストを許可することとが、ビデオアーカイブサーバー４００が暗号化フィードをユーザー／購読者に供給することよりも、全体として著しく小さい帯域幅集約プロセスであると仮定すると、前者の鍵サーバー３００の帯域幅に関するニーズは後者のビデオアーカイブサーバー４００よりもかなり弱い。
【０１４３】
なお当然理解できることであるが、本明細書で検討したトポロジーの実施例が最適な操作シナリオを提供する。鍵管理操作からストレージを分離することにより、任意の予想外の（暗号化）データの提供や（暗号化）データの侵害の負担を著しく減らすことができ、その影響を弱めることができる。したがって、データアクセスのインテグリティを保持するための責任の大部分は、信頼できるユーザー／購読者インターフェース５００に置かれる。さらに、復号モジュールによって行われる復号プロセスはユーザー／購読者インターフェース５００のノードに存在しており、このノードは完全に異なる場所における鍵および暗号化フィードの格納と結合され、それらが消費されるノードでそれらを復号プロセスに結び付け、セキュリティとパフォーマンスについて最適化された、まさにうってつけのトポロジーのアーキテクチャを提供する。
【０１４４】
別の一実施例として、複数のストリームを合成することが望ましい場合がある。合成は本質的に、破壊的であるかまたは破壊的でないかのいずれかである。複数のストリームのコンテンツを混合する可能性を含む一実施例として、例えばひとつの映像レイヤーと３つの音声レイヤーとを混合することで新規の合成出力を生成することができる。ユーザー／購読者は、例えばユーザー／購読者インターフェース５００のノードで、４つの構成要素であるレイヤーのそれぞれを取得したり復号したりする権利を有する（すなわち、鍵１７５を取得するための許可を有する）。復号の後、４つのレイヤーの合成または混合は、ユーザー／購読者インターフェース５００にとってローカルにある（そして適切に信頼できる）プロセッサ上で行われる。なお当然理解できることであるが、その合成の結果生じた新規のストリーム１００は順番に暗号化されてもよい。一実施例において、暗号化モジュール２００は暗号化のためにユーザー／購読者インターフェース５００にアクセス可能とされてもよい。必要な鍵２７５は同様に鍵源２５０によって生成され、その結果生じた鍵２７５は本明細書で詳細に説明した機能にしたがって、鍵サーバー３００に格納される。
【０１４５】
一実施例として、ユーザー／購読者インターフェース５００は新規のアカウントを作成するための機能を提供することができる。アカウントの削除も同様に、インターフェース５００の一部に実装することができる。そして、さらなる実施例では、アカウントの削除が各ユーザーの排他的権利であってもよく、またはその代わりにサービスメンテナンス要員によって実行されるポリシーで共有されてもよい。
【０１４６】
なお当然理解できることであるが、暗号化モジュール２００とユーザー／購読者インターフェース５００とを組み合わせて、個人のコンピュータまたはモバイルプラットフォームなどの任意のプラットフォーム上でアクセス可能な、単一のユーザー側のアプリケーションにすることができる。また、当然理解できることであるが、別のシリーズの実施例として、彼が同時にインスタンス生成することのできる多重セッションの数において、単一のユーザー／購読者またはアカウントが許可されたり、禁止されたり、または制限されたりする可能性がある。
【０１４７】
なお、当然理解できることであるが、あり得る実施例の実装は、本明細書で議論したかどうかに関わらず、とりわけ、ユーザー／購読者の数やビデオアーカイブサーバー４００に格納するデータ量が非常に大きな割合に達する場合、拡張性を目的として、提供した説明からいくらか逸脱するものであっても良い。例えば、ネットワークまたは実施例が展開される可能性のあるネットワークはＬＡＮ，ＷＡＮやインターネットを含むことができるが、これに限定されない。このテクノロジーは、信頼できないネットワークを通じたデータへの安全なアクセスを提供するのに非常に適しているが、当然理解できることであるが、信頼できないネットワークが使用される場所（例えば、信頼できないネットワークを通じて通信が行われる場所）で、代わりに信頼できるネットワークを使用することもできる。そのような場合、本願のテクノロジーは許可に基づくアクセスコントロールと同様に、付加的なレイヤーのセキュリティをさらに提供することができる。
【０１４８】
本明細書で提供したコンピュータ読み取り可能な記憶媒体は、チップベースまたはディスクベースの記憶媒体などの有形のコンピュータ読み取り可能な記憶媒体であってもよく、またＣＰＵなどの処理エンティティによってアクセス可能であってもよい。
【０１４９】
ビデオアーカイブサーバー７０はそのように名づけたが、これは主に便宜のためである。なお、当然理解できることであるが、データストリームや、より広義にはデータを格納するための市販のデータストリームアーカイブサーバーを表すこともできる。本明細書では単一の暗号化コンピュータシステム３０とビデオアーカイブサーバー７０とを示したが、多重暗号化コンピュータシステムがビデオアーカイブサーバー７０を共有してもよく、または概してその逆の場合とは少ないということは当然理解できることである。さらに、これらのエンティティの両方は冗長バージョンを有することができる。冗長な暗号化コンピュータシステムは、オリジナルの暗号化コンピュータシステム３０のように、生データストリームを受信することができ、データや鍵ストリームを独立して暗号化することができる。補助アーカイバーが、暗号化データストリームや暗号化鍵ストリームの追加の複製を格納するためのビデオアーカイブサーバー７０に対するクライアントとして提供されてもよい。
【０１５０】
したがって、当然理解できることであるが、本願のテクノロジーによって、差別化された許可アクセスを有するデータストリームの安全な保管および転送が可能になる。データストリームは非常に大きな、すなわち境界のない／無限となる可能性があり、自由裁量によって、または任意の適切なパターンに従って、有限のセグメントに分割することができる。なお、ストリームの部分は通常、それ自体がストリームであることを理解されたい。したがって、特定のストリームで実行されるといわれるものが、そのストリームの一部のみについて実行されてもよく、それが実行される部分がストリームである。これは明らかなはずであるが、例えば潜在的に無限のストリームについて論じる場合、本願で説明した技術をその一部に適用することができる場合、それ自体がストリームである。
【０１５１】
対称暗号化は巨大なデータセットについては効率的であるが、信頼性の問題につながる秘密鍵を共有することを伴う。非対称暗号化は巨大なデータセットについては効率的ではないが、より良く制御することができる。本願のテクノロジーは巨大なデータセットを暗号化する対称鍵を非対称的に暗号化することによる、非対称暗号化のセキュリティと対称暗号化の大雑把な効率性とで巨大なデータセットを保護することによって、これらの技術の両方の利益を提供することができる。
【０１５２】
本願のテクノロジーは、データが保管されているときと、転送されるときとの両方でデータが暗号化されているため、クラウドの信用問題の効率的な処理も可能とする。中央の保管所（例えばクラウド）は、暗号化されていないデータにアクセスすることはできず、一実施例では、その保管所自体によっては新規のユーザーに対して新規のアクセス許可を与えることはできない。信頼できるエージェントは巨大なデータセットに有利に直接アクセスする必要のないプロセスにおいて許可を与える任務を負っている。有利なことに、オリジナルデータと対称鍵の暗号化されていない複製を保持する必要はなく、特別なデータ保全のために廃棄される。
【０１５３】
データの分配と共有は拡張可能であり、共有はデータストリーム自体の復号を必要とせず、鍵ストリームの復号のみを必要とする。さらに、共有と許可の付与は、データストリームまたは全セットの一部についてきめ細かく実行することができる。データストリームは特定の長さ（例えば１分間）のセグメントに分割され、各セグメントはランダムな対称鍵（これは共に鍵ストリームを形成する）で暗号化されて、暗号化データストリームを生成する。これは進行中のプロセスであってもよく、これにより新規のセグメントが存在する度（例えば毎分）に新規の対称鍵が生成され、鍵ストリームに追加される。鍵ストリームまたはその一部は、権限の与えられたエンティティの証明書における公開鍵で非対称的に暗号化され、暗号化された証明書固有の鍵ストリームを生成することができる。権限のあるエンティティがこの鍵ストリームを共有することができ（または安全に格納されたり広く分配されたりする）、権限のあるエンティティがデータストリームの対応する部分にアクセスできるようにする。
【０１５４】
様々な実施例を示してきたが、これは本願発明を説明することを目的とするものであって、限定することを目的とするものではない。様々なあり得る修正および異なる構成は当業者にとって明らかとなるとともに本願発明の範囲内にあり、付属の請求項によってより具体的に規定される。
【図１】
2018534879.tif 000003
【図２】
2018534879.tif 000004
【図３】
2018534879.tif 000005
【図４】
2018534879.tif 000006
【図５】
2018534879.tif 000007
【図６】
2018534879.tif 000008
【図７】
2018534879.tif 000009
【図８】
2018534879.tif 000010
【図９】
2018534879.tif 000011
【図１０】
2018534879.tif 000012
【図１１】
2018534879.tif 000013
【図１２】
2018534879.tif 000014
【図１３】
2018534879.tif 000015
【国際調査報告】
2018534879.tif 000016
2018534879.tif 000017