(58)【調査した分野】(Int.Cl.,DB名)
前記第1クライアントが、前記暗号化データを前記情報共有システムにおける前記ブロックにアップロードする際に、前記暗号化データのファイル識別子と、前記暗号化データの保有者のユーザ識別子とをさらにアップロードし、
前記情報共有システムが、前記暗号化データと、前記ファイル識別子、及び前記保有者のユーザ識別子とを関連付け、
前記アクセス許可サーバが、前記ファイル識別子と前記保有者のユーザ識別子とに基づいて、前記情報共有システムにおける前記ブロックから前記暗号化データを取得する、
請求項1に記載の方法。
前記第1クライアントが、前記鍵の前記第1部分を前記アクセス許可サーバにアップロードする際に、前記ファイル識別子と前記保有者のユーザ識別子とをさらにアップロードし、
前記アクセス許可サーバが、前記保有者のユーザ識別子に対応する規則に従って、前記許可コードを生成し、前記許可コードと、前記鍵の前記第1部分、前記ファイル識別子、及び前記保有者のユーザ識別子とを関連付け、前記アクセス要求を受信すると、前記アクセス要求に付された前記ファイル識別子と前記保有者のユーザ識別子とに基づいて、前記アクセス要求に付された前記ファイル識別子と前記保有者のユーザ識別子とに関連付けられた前記許可コードと前記鍵の前記第1部分とを取得し、取得された前記許可コードに基づいて、前記アクセス要求に付された前記許可コードが使用可能であるか否かを決定し、取得された前記鍵の前記第1部分と、前記アクセス要求に付された前記第2部分とに基づき、前記鍵を生成する、
請求項2に記載の方法。
前記アクセス許可サーバが、前記第1クライアントから前記鍵の前記第1部分を受信する際に、ファイル識別子と前記暗号化データの保有者のユーザ識別子とをさらに受信し、
前記アクセス許可サーバが、前記暗号化データに対応する第1許可コードを生成するステップは、
前記アクセス許可サーバが、前記保有者のユーザ識別子に対応する規則に従って、前記第1許可コードを生成し、前記第1許可コードと、前記鍵の前記第1部分、前記ファイル識別子、及び前記保有者のユーザ識別子とを関連付けるステップと、
前記アクセス許可サーバが、前記アクセス要求を受信すると、前記アクセス要求に付されたファイル識別子と前記保有者のユーザ識別子とに基づいて、前記アクセス要求に付されたファイル識別子と前記保有者のユーザ識別子とに関連付けられた前記第1許可コードと前記鍵の前記第1部分とを取得するステップと、を含む、
請求項6に記載の方法。
前記アクセス許可サーバが、前記第1クライアントからの、前記暗号化データへの許可コード生成要求に応じて、前記暗号化データに対応する新たな許可コードを生成するステップと、
前記アクセス許可サーバが、前記暗号化データに対応する前記新たな許可コードを前記第1クライアントに送信するステップと、
をさらに含む請求項6に記載の方法。
前記アクセス許可サーバが、前記第1クライアントからの、前記暗号化データへの許可コード更新要求に応じて、前記暗号化データに対応する新たな許可コードを生成し、元の前記第1許可コードを前記新たな許可コードに置き換えるステップと、
前記アクセス許可サーバが、前記暗号化データに対応する前記新たな許可コードを前記第1クライアントに送信し、前記第1クライアントが元の前記第1許可コードを前記新たな許可コードに置き換えるステップと、
をさらに含む請求項6に記載の方法。
1つ又は複数のプログラムを記憶した記憶媒体であって、前記1つ又は複数のプログラムには、命令が含まれ、前記命令は、コンピューティングデバイスによって実行されると、前記コンピューティングデバイスに、請求項1〜11のいずれか1項に記載の方法を実行させる記憶媒体。
【発明を実施するための形態】
【0012】
以下では、簡潔かつ直感的な説明のために、いくつかの典型的な実施例を説明することにより、本発明の構成を述べる。しかし、すべての実施形態がここに示されるわけではない。実施例における大量の細部は、本発明の構成の理解を助けるためにのみ使用される。本発明の構成の実現は、これらの細部に限定されなくてもよい。本発明の構成を不必要に曖昧にすることを回避するために、いくつかの実施形態は、細かく説明されず、フレームワークのみが与えられる。以下では、「含む」とは、「含むが、これらに限定されない」ことを意味し、「…に基づく」とは、「少なくとも…に基づくが、…のみに基づくことに限定されない」ことを意味する。明細書及び請求の範囲における「含む」とは、ある程度で少なくとも含むことを意味し、その前に言及された特徴以外に他の特徴も存在してもよいと解釈されるべきである。
【0013】
本願の実施例では、データ共有方法が提供されている。この方法は、
図1に示すシステムアーキテクチャに適用可能である。
図1に示すように、このシステムアーキテクチャは、第1クライアント101と、第2クライアント102と、アクセス許可サーバ103と、情報共有システム104と、を含む。これらのエンティティは、インターネット105を介して通信可能である。ここで、情報共有システム104は、ユーザによりアップロードされる様々なデータを格納する。ユーザが情報共有システム104におけるデータにアクセスすることも可能である。実際のネットワークでは、多数のクライアント101/102があり得る。情報共有システム104にアップロードされた1つのデータは、1つの第1クライアント101に対応する。第1クライアント101は、このデータの保有者及びアップローダーが使用するクライアントであり、共有者クライアントとも呼ばれる。このデータは、1つ又は複数の第2クライアント102にも対応する。第2クライアント102は、このデータへのアクセスを要求するユーザが使用するクライアントであり、訪問者クライアント又は閲覧者クライアントとも呼ばれる。アクセス許可サーバ103は、直接に又はインターネット105を介して、情報共有システム104に接続可能であり、情報共有システム104へのアクセスサービス(具体的に閲覧許可サービスと呼ばれてもよい)を提供する。第2クライアント102は、そのアクセスしようとするデータを、アクセス許可サーバ103を介して、情報共有システム104から取得する。具体的には、第2クライアント102は、あるデータへのアクセス要求(具体的に閲覧要求と呼ばれてもよい)をアクセス許可サーバ103に送信する。アクセス許可サーバ103は、このアクセス要求を認証して、第2クライアント102に対応するユーザがこのデータにアクセスする権限を有するか否かを検証し(例えば、アクセス要求における許可コードを検証し)、認証を通過した場合、アクセス要求に付された鍵情報に基づいて、情報共有システム104から取得された暗号化データを復号化処理し、復号化された平文データの取得に成功できれば、この平文データを第2クライアント102に返信する。
【0014】
ここで、第1クライアント101及び第2クライアント102は、共有データにアクセス可能な様々なAPPクライアント又はブラウザであってもよい。第1クライアント101及び第2クライアント102は、PC、携帯電話、タブレットコンピュータ、パームトップコンピュータ、ウルトラブック、ウェアラブルデバイスなどを含む様々な端末機器上で実行可能である。情報共有システム104は、ブロックチェーンシステム(ブロックチェーンネットワークとも呼ばれる)、データベースシステム、ネットワークディスク/クラウドディスクシステムなどを含むが、これらに限定されない様々な集中型又は分散型のデータ記憶システムであってもよい。情報共有システム104に記憶されたデータは、デジタル資産、認証サービス、共有台帳、共有経済などのシナリオを含む様々なビジネスシナリオで生成されたデータに関わることが可能である。
【0015】
ここで、デジタル資産(Digital assets)とは、企業が所有または制御する、電子データの形で存在する非貨幣資産であって、販売のために日常活動で保有される非貨幣資産、又は生産プロセスにおける非貨幣資産を指す。デジタル資産は、オフィスオートメーションの恩恵を受けて生まれたものである。デジタル資産は、電子決済システムに頼って発展し、共有ポイント、クーポン、デジタル通貨、株式の登録などのシナリオに使用される。認証サービスは、著作権/所有権の保護、司法文書の保全、公益寄付、個人・企業の証明などのビジネスシナリオに使用される。共有台帳は、機関間清算、銀行ファクタリング、機関間協調融資、サプライチェーンファイナンス、海外送金などのビジネスシナリオに使用される。ブロックチェーンは、時系列に沿ってデータブロックを順につながっていくように結合するチェーンデータ構造であり、暗号学的な方式で確保される改ざん不可能で偽造不可能な分散型台帳である。ブロックチェーンシステムは、真新しいタイプの分散インフラストラクチャであり、ブロックチェーンデータ構造を使用してデータを検証・格納し、分散ノードコンセンサスアルゴリズムを使用してデータを生成・更新し、暗号学的な方式でデータの伝送・アクセスのセキュリティを確保し、自動化スクリプトコードで構成されるスマートコントラクトを使用して、プログラミングとデータの操作とを行う。
【0016】
いくつかのビジネスシナリオでは、情報共有システム104にアップロードするデータを暗号化する必要があり、かつ、データアクセスの許可を行う必要がある。つまり、一部のデータが条件付きで共有され、これらのデータは、例えば、個人又は機関の実名認証情報、金融口座情報、フォトアルバム、オリジナル作品、共有認証が必要な情報などであり、ユーザのプライバシーデータと呼ばれてもよい。ユーザは、これらのデータを、内容が公にならないが特定の人々間で共有可能になるように共有したいため、データを暗号化して情報共有システム104に格納し、その後、特定のユーザへの閲覧許可をする。
【0017】
本願の実施例では、端末機器の第1クライアント101に適用可能なデータ共有方法が提供されている。
図1には、第1クライアント101が1つのみ示されているが、実際の応用シナリオでは、第1クライアント101が複数、ひいては大量あり得、第1クライアント101のいずれもこの方法を実現可能である。
図2に示すように、この方法の手順200は、以下のステップを含む。
【0018】
ステップ201で、第1クライアント101は、鍵で平文データを暗号化することにより、暗号化データを取得する。
【0019】
ステップ202で、第1クライアント101は、前記暗号化データを、情報共有システム104における1つのブロックにアップロードし、前記情報共有システムはブロックチェーンシステムである。
【0020】
ここで、ユーザがデータをアップロードしたい場合、ユーザが使用する第1クライアント101は、予め設定された鍵でこのデータ(即ち、平文データ)を暗号化し、暗号化データを情報共有システム104にアップロードする。
【0021】
ステップ203で、第1クライアント101は、前記鍵の第1部分を、情報共有システム104に対応するアクセス許可サーバ103にアップロードする。
【0022】
ここで、情報共有システム104に対応するアクセス許可サーバ103とは、情報共有システム104と接続されるアクセス許可サーバ103を指す。
【0023】
ここで、鍵は文字列である。鍵とされるこの文字列を2つの文字列に分割し、この2つの文字列をそれぞれ鍵の第1部分及び第2部分としてもよい。本ステップにおいて、鍵の第1部分をアクセス許可サーバ103にアップロードする。いくつかの実例では、鍵の前半を第1部分として、鍵の後半を第2部分としてもよい。他のいくつかの実例では、鍵の後半を第1部分として、鍵の前半を第2部分としてもよい。ここで、第1部分と第2部分との長さは、同じであっても、異なっていてもよい。いくつかの実例では、鍵を分割する際に、予め設定された、文字列の長さの値(即ち、予め設定された、文字列に含まれる文字の数)に応じた長さの文字列を鍵の第1部分として分割し、残りの文字列を鍵の第2部分としてもよい。
【0024】
ステップ204で、第1クライアント101は、アクセス許可サーバ103から、前記暗号化データに対応する許可コードを受信する。
【0025】
いくつかの実例では、アクセス許可サーバ103は、第1クライアント101からアップロードされた、ある暗号化データに対する鍵の第1部分を受信すると、この暗号化データに対して許可コードを生成し、この許可コードを第1クライアント101に返信する。具体的には、アクセス許可サーバ103は、このデータをアップロードしたユーザに対応する規則に従って、許可コードを生成してもよい。
【0026】
ステップ205で、あるユーザによる前記暗号化データへのアクセスを許可する際に、第1クライアント101は、前記許可コードと前記鍵の第2部分とを前記ユーザのクライアント(即ち、対応の第2クライアント102)に送信することにより、第2クライアント102が、前記暗号化データへのアクセス要求をアクセス許可サーバ103に送信する際に、前記アクセス要求に前記許可コードと前記鍵の前記第2部分とを付するようにし、前記鍵の第2部分は前記鍵の前記第1部分を除いた残りの部分を含む。
【0027】
このように、アクセス許可サーバ103は、前記許可コードが使用可能であると決定した場合、前記鍵の前記第1部分及び前記第2部分に基づき前記鍵を生成し、生成された前記鍵で、情報共有システム104における前記ブロックから取得された前記暗号化データを復号化処理し、復号化によって取得された前記平文データを第2クライアント102に提供する。
【0028】
いくつかの実例では、あるユーザは、この暗号化データを閲覧したい場合、該ユーザが使用する第2クライアント10
2を介して、第1クライアント101に許可コードを要求し、第1クライアント101は、このユーザによるデータへの閲覧を許可すると決定した場合、この許可コードと上記鍵の第2部分とを第2クライアント102に送信する。
【0029】
いくつかの実例では、アクセス許可サーバ103は、鍵の第1部分及び第2部分を結合してもよい。これにより、鍵の第1部分及び第2部分を完全な前記鍵として組み合わせることができる。アクセス許可サーバ103は、第2クライアント102から取得された鍵の第2部分と、第1クライアント101から取得された鍵の第1部分とが、同一の鍵に属しない場合、鍵の第1部分及び鍵の第2部分を正しい鍵として結合することができず、さらに復号化に失敗することになり、第2クライアント102は、平文データを取得できない。アクセス許可サーバ103は、第2クライアント102に、失敗応答を返信してもよいし、又は暗号化データを返信してもよい。このように、第2クライアント102は、データの内容を閲覧することに成功できない。これにより、第1クライアント101からアップロードされたデータのセキュリティが効果的に確保される。
【0030】
上記の実例で提供された方法によれば、第1クライアント101が鍵及び許可コードを保有し、アクセス許可サーバ103が許可コードと鍵の第1部分とを保有し、第2クライアント102が、許可を得た場合、鍵の第2部分と、許可コードとを保有可能である。このように、第2クライアント102が、アクセス許可サーバ103を介して、相応のデータへのアクセスを要求すると、アクセス許可サーバ103は、まず、許可コードが使用可能であるか否かを検証し、許可コードが使用可能である場合、それぞれ第1クライアント101及び第2クライアント102から取得された不完全な鍵(鍵の第1部分及び第2部分)を使用して、完全な鍵を取得してもよい。第2クライアント102から提供された不完全な鍵に問題がある場合、正しい完全な鍵を取得できず、暗号化データの復号化に成功できないため、データのセキュリティが確保される。この構成では、第2クライアント102及びアクセス許可サーバ103が、それぞれ鍵の一部を保有し、両方とも暗号化データへのアクセス権限を有しなく、両者の保有する鍵情報を合わせた場合以外に完全な鍵を取得できないため、データのセキュリティ及びユーザのプライバシーが効果的に確保される。このように、情報共有システム104に格納された、ユーザが公開したくない暗号化データの場合、第1クライアント101は、アクセス許可サーバ103を介して、いくつかの第2クライアント102による暗号化データの平文へのアクセスを許可することができる。これにより、情報共有とプライバシー保護とのバランスがとれ、より良い情報共有メカニズムが提供される。
【0031】
上記の実例は、ブロックチェーンのデータ共有シナリオに適用可能である。アクセス許可サーバ103は、プライバシーデータ閲覧許可のサービスを提供している。このサービスは、共有情報システムにおけるブロックチェーンに提供される、データプライバシー保護のためのオプションサービスに属し、情報共有ブロックチェーン、デジタル資産ブロックチェーンなどのシナリオに適用可能であり、ユーザが公開したくないデータを保護すると共に、独立した許可によって、一部の人がこれらのデータを閲覧できるようにさせることもできる。ブロックチェーンが共有を原則とするものであるため、すべてのユーザがブロックチェーンにおけるデータを自由に閲覧できる。現時点で許可されているか否かを問わず、ユーザが自由に閲覧できるが、アクセス許可サーバ103を介して閲覧されたデータのみが、復号化された平文データである。あるユーザーは、ブロックチェーンにおいて直接に閲覧する場合、取得されたのが暗号化データであり、平文データを取得できない。
【0032】
いくつかの実例では、ステップ204において、第1クライアント101は、許可コードを受信した後、さらに、前記暗号化データのアクセストークン(データ閲覧トークンと呼ばれてもよい)を生成してもよい。このアクセストークンには、前記許可コードと、前記鍵の前記第2部分とが含まれる。ステップ205において、前記許可コードと、前記鍵の第2部分とを前記第2クライアント102に送信することは、具体的に、前記アクセストークンを前記第2クライアント102に送信することにより、前記第2クライアント102が前記アクセス要求に前記アクセストークンを付するようにさせる、ことを含んでもよい。このように、第1クライアント101は、許可コードと鍵の第2部分とを第2クライアント102に送信した。ここで、許可コード及び鍵のそれぞれは、数字及び/又は文字で構成される文字列であってもよく、許可コードと鍵の第2部分とから構成されるアクセストークンは、数字及び/又は文字で構成される文字列であってもよい。この実例では、第1クライアント101は、第2クライアント102にトークンを発行することにより、相応のユーザが第1クライアント101からアップロードされた暗号化データにアクセスすることを許可することができる。また、発行されたトークンに完全な鍵がなく、完全な鍵を取得して復号化処理を行うために、アクセス許可サーバ103におけるさらなる検証を行わなければならない。これにより、データのセキュリティが効果的に確保される。
【0033】
いくつかの実例では、ステップ202において、前記暗号化データを情報共有システム104にアップロードする際に、第1クライアント101は、前記暗号化データのファイル識別子と、前記暗号化データの保有者のユーザ識別子(通常、現在第1クライアント101を使用しているユーザの識別子)とをさらにアップロードすることにより、情報共有システム104が、前記暗号化データと、前記ファイル識別子、及び前記保有者のユーザ識別子とを関連付けるよう実現させ、アクセス許可サーバ103が、前記ファイル識別子と前記保有者のユーザ識別子とに基づいて、情報共有システム104から前記暗号化データを取得するようにさせる。ここで、暗号化データをアップロードする際に、暗号化データのファイル識別子と、暗号化データの保有者のユーザ識別子との両方が情報共有システム104に伝送され、情報共有システム104は、この暗号化データを格納する際に、この暗号化データと、ファイル識別子、及び保有者のユーザ識別子とを関連付ける。アクセス許可サーバ103は、情報共有システム104から、ある暗号化データを検索する際に、検索要求にファイル識別子と保有者のユーザ識別子とを付する。このように、情報共有
システム104は、ファイル識別子、及び保有者のユーザ識別子に関連付けられた暗号化データを決定して、この暗号化データをアクセス許可サーバ103に返信することができる。
【0034】
いくつかの実例では、ステップ203において、前記鍵の前記第1部分をアクセス許可サーバ10
3にアップロードする際に、第1クライアント101は、前記ファイル識別子と前記保有者のユーザ識別子とをさらにアップロードすることにより、アクセス許可サーバ103が、前記保有者のユーザ識別子に対応する規則に従って、前記許可コードを生成し、前記許可コードと、前記鍵の前記第1部分、前記ファイル識別子、及び前記保有者のユーザ識別子とを関連付けるようにさせる。アクセス許可サーバ103は、前記アクセス要求を受信すると、前記アクセス要求に付された前記ファイル識別子と前記保有者のユーザ識別子とに基づいて、前記アクセス要求に付された前記ファイル識別子と前記保有者のユーザ識別子とに関連付けられた前記許可コードと前記鍵の前記第1部分と(アクセス許可サーバ103がローカルでメンテナンスする、前記暗号化データに対応する許可コードと鍵の第1部分とであってもよい)を取得し、取得された前記許可コードに基づいて、前記アクセス要求に付された前記許可コードが使用可能であるか否かを決定し、取得された前記鍵の前記第1部分と、前記アクセス要求に付された前記第2部分とに基づき、前記鍵を生成する。
【0035】
いくつかの実例では、アクセス許可サーバ103には、各ユーザ毎に、許可コードを生成するための規則が予め設定されている。この規則では、生成する許可コードでアクセス可能なデータアドレスや失効時間などを指定してもよい。上記のデータアドレスは、例えば、ブロックチェーンにおけるブロックの高さや、ユニフォームリソースロケータ(URL)アドレスなどであってもよい。いくつかの実例では、ステップ203において、第1クライアント101が鍵の第1部分をアップロードすると、アクセス許可サーバ10
3は、同時にアップロードされた、暗号化データの保有者のユーザ識別子に基づいて、許可コードの生成に使用する規則を決定してもよい。その後、アクセス許可サーバ103は、アクセス要求を受信すると、現在アクセスが要求される暗号化データに対応する許可コード(即ち、ファイル識別子、及び保有者のユーザ識別子に関連付けられた許可コード)をローカルで検索してもよい。アクセス要求に付された許可コードと、ローカルで検索された許可コードとが一致する場合は、アクセス要求に付された許可コードが合法的であることを表す。さらに、許可コードの期限が切れているか否か(例えば、失効時間に達したか否か、又はまだ有効使用期間内にあるか否か)を検証し、及び/又は、現在アクセスが要求される暗号化データのアドレスが、許可コードに対応するアクセス可能なデータアドレスに属するか否かを検証してもよい(例えば、ブロックチェーンのシナリオでは、現在閲覧が要求されるデータのブロックの高さが、許可コードに対応するアクセス可能なブロックの高さであるか否かを検証する。また例えば、共有写真のシナリオでは、現在閲覧が要求されるアルバムフォルダが、許可コードでアクセス可能なフォルダであるか否かを検証する。)。検証を通過した場合、許可コードが使用可能であると決定する。ブロックチェーンシナリオでのいくつかの実例では、第2クライアント102から送信されたアクセス要求に、閲覧するデータのファイル識別子を付けてもよい。アクセス許可サーバ103は、ファイル識別子に基づいて、データが位置するブロックの高さを決定でき、さらに、決定されたこのデータのブロックの高さが、許可コードに対応するアクセス可能なブロックの高さであるか否かを検証できる。他のいくつかの実例では、第2クライアント102から送信されたアクセス要求に、データのブロックの高さを直接に付けてもよい。アクセス許可サーバ103は、アクセス要求に付されたブロックの高さが、許可コードに対応するアクセス可能なブロックの高さであるか否かを検証できる。
【0036】
許可コードが使用可能であると決定した場合、取得された、ファイル識別子、及び保有者のユーザ識別子に関連付けられた鍵の第1部分と、アクセス要求に付された、鍵の第2部分とを、完全な鍵として組み合わせてもよい。この組み合わせの方式は、2つの部分を簡単的に結合してもよい。
【0037】
いくつかの実例では、ステップ204において、第1クライアント101は、許可コードを受信すると、さらに、前記許可コードと前記鍵の前記第2部分とが含まれる、前記暗号化データのアクセストークンを生成し、前記アクセストークンと前記ファイル識別子とを関連付けてもよい。ステップ205において、前記許可コードと、前記鍵の第2部分とを第2クライアント102に送信することは、具体的に、前記ファイル識別子に関連付けられた前記アクセストークンを第2クライアント102に送信することにより、第2クライアント102が前記アクセス要求に前記アクセストークンを付するようにさせる、ことを含んでもよい。
【0038】
ここで、第1クライアント101では、1つ又は複数のアクセストークンがメンテナンスされ、第1クライアント101からアップロードされた各々のデータが1つのアクセストークンに対応し、即ち、各々のファイル識別子が1つのアクセストークンに関連付けられる。このように、第2クライアント102が第1クライアント101にデータアクセス許可を要求すると、第1クライアント101が許可を承認する場合、第1クライアント101は、対応のアクセストークンを決定し、このアクセストークンを第2クライアント102に発行してもよい。なお、第2クライアント102は、あるデータ、又は一定の条件に合うデータ集合、又はすべてのデータへのアクセス許可を要求する可能性があり、第1クライアント101は、対応する1つ又は複数のアクセストークンを第2クライアント102に送信してもよい。
【0039】
いくつかの実例では、ステップ204の後に、上記方法は、第1クライアント101が、前記許可コードへの取り消し要求をアクセス許可サーバ103に送信することにより、アクセス許可サーバ103が前記許可コードを失効させるようにさせる、ことをさらに含んでもよい。これと同時に、第1クライアント101も、ローカルの前記許可コードを失効させる。ここで、ある許可コードへの取り消し要求に、この許可コードに対応するファイル識別子を付けてもよい。アクセス許可サーバ103は、ファイル識別子に基づいて、このファイル識別子に対応する許可コードを決定でき、さらに、例えば、この許可コードの状態を失効に設定し、又はこの許可コードを削除するなど、この許可コードを失効させることができる。アクセス許可サーバ103は、前記許可コードを失効させた後、第1クライアント101に応答を返信してもよい。第1クライアント101は、応答を受信すると、ローカルの許可コードを失効させる。これにより、この許可コードの取り消しのプロセス全体が完了する。
【0040】
このように、第1クライアント101は、アクセス許可サーバ103が、アップロードされたデータに対して、許可コードを生成するようにさせることができるだけでなく、この許可コードの取り消しをアクセス許可サーバ103に要求することもできる。許可コードが取り消された後、第2クライアント102が、データアクセスを要求する際に、この許可コード、又はこの許可コードが含まれるアクセストークンを使用した場合、この許可コードが使用不可と検証され、アクセス要求が拒絶され、第2クライアント102が、このデータにアクセスできなく、又は、暗号化データのみを取得できるが復号化された平文データを取得できない。このように、データアクセスの動的許可方式が形成される。あるデータを共有したユーザは、必要に応じて、対応の許可コードを取り消すことができる。これにより、以前に許可コードを取得してこのデータにアクセスできたユーザは、このデータにアクセスできなくなる。
【0041】
いくつかの実例では、ある暗号化データの許可コードを取り消した後、第1クライアント101は、さらに、この暗号化データへの許可コード生成要求をアクセス許可サーバ103に送信することにより、アクセス許可サーバ103が、この暗号化データに対応する新たな許可コードを生成するようにしてもよい。その後、第1クライアント101は、アクセス許可サーバ103から、この暗号化データに対応する新たな許可コードを受信する。このように、ユーザは、以前に許可されたユーザが暗号化データの平文にアクセスできないように、許可コードを随時取り消すことができるだけでなく、ユーザによる暗号化データの平文へのアクセスを再び許可するように、新たな許可コードの生成を要求することもでき、柔軟なデータアクセス許可が実現される。
【0042】
いくつかの実例では、第1クライアント101は、許可コードを得た後、アクセス許可サーバ103に許可コードの更新を要求することもできる。このとき、第1クライアント101により取得された許可コードは、まだ削除されておらず、又は、まだ使用されていない。ここで、第1クライアント101は、ある暗号化データへの許可コード更新要求をアクセス許可サーバ103に送信することにより、アクセス許可サーバ103が、この暗号化データに対応する新たな許可コードを生成し、元の許可コードをこの新たな許可コードに置き換えるようにさせる。その後、第1クライアント101は、アクセス許可サーバ103から、この新たな許可コードを受信し、元の許可コードをこの新たな許可コードに置き換える。このように、許可コード更新プロセスによれば、第1クライアント101は、以前に許可を得たユーザが暗号化データの平文にアクセスできなくなるように、元の許可コードを取り消すことができると共に、新たな許可コードを取得でき、後続にいくつかのユーザへの許可をすることができる。
【0043】
いくつかの実例では、上記の許可コード取り消し要求、許可コード生成要求、及び許可コード更新要求が共存可能であり、ユーザが、必要に応じて、許可コードの取り消し、新たな許可コードの生成、又は許可コードの更新を選択でき、より完璧な動的許可方式が実現される。
【0044】
本願の実例では、アクセス許可サーバ103に適用可能なデータ共有方法が提供されている。
図3に示すように、この方法の手順300は、以下のステップを含む。
【0045】
ステップ301で、第1クライアント101から第1鍵の第1部分を受信し、前記第1鍵が、情報共有システム104における1つのブロックにアップロードされた暗号化データに対応するものであり、前記暗号化データが、前記第1鍵で平文データに対して暗号化処理を行うことにより取得されたものであり、前記情報共有システムがブロックチェーンシステムである。
【0046】
ステップ302で、前記暗号化データに対応する第1許可コードを生成する。
【0047】
ステップ303で、前記第1許可コードを第1クライアント101に送信することにより、第1クライアント101が、第2クライアント102による前記暗号化データへのアクセスを許可する際に、前記第1許可コードと前記第1鍵の第2部分とを第2クライアント102に送信するよう実現させ、第2クライアント102が、前記暗号化データにアクセスする際に、前記第1許可コードと前記第1鍵の前記第2部分とをアクセス要求に付するようにし、前記第1鍵の第2部分は前記第1鍵の前記第1部分を除いた残りの部分を含む。
【0048】
ステップ304で、いずれか1つのクライアント(許可を得た上記第2クライアント102である可能性があり、許可を得ていない他のクライアントである可能性もある)からの、前記暗号化データへのアクセス要求を受信すると、下記のステップを実行する。
【0049】
ステップ305で、前記アクセス要求から、第2許可コード及び不完全な鍵を取得する。
【0050】
ステップ306で、前記第2許可コードが前記第1許可コードと同じであって、かつ前記第2許可コードが使用可能である場合、前記不完全な鍵と、前記暗号化データに対応する前記第1鍵の第1部分とに基づき、第2鍵を生成し、前記不完全な鍵が前記第1鍵の第2部分と同じである場合、生成された前記第2鍵が前記第1鍵と同じである。
【0051】
ステップ307で、情報共有システム104における前記ブロックから、前記暗号化データを取得し、前記第2鍵で前記暗号化データを復号化処理し、前記第2鍵が前記第1鍵と同じである場合、復号化によって前記平文データを取得すると共に、前記アクセス要求の送信元である前記クライアントに前記平文データを送信する。
【0052】
上記の実例で提供された方法によれば、第1クライアント101が鍵及び許可コードを保有し、アクセス許可サーバ103が許可コードと鍵の第1部分とを保有し、第2クライアント102が、許可を得た場合、鍵の第2部分と、許可コードとを保有可能である。このように、あるクライアント(許可を得た第2クライアント102である可能性があり、他のクライアントである可能性もある)が、アクセス許可サーバ103を介して、相応のデータへのアクセスを要求すると、アクセス許可サーバ103は、まず、許可コードが使用可能であるか否かを検証し、許可コードが使用可能である場合、それぞれ第1クライアント101及びこのクライアントから取得された不完全な鍵(鍵の第1部分及び第2部分)を使用して、完全な鍵を取得してもよい。このクライアントから提供された不完全な鍵に問題がある場合、正しい完全な鍵を取得できず、暗号化データの復号化に成功できないため、データのセキュリティが確保される。この構成では、許可を得た第2クライアント102、及びアクセス許可サーバ103が、それぞれ鍵の一部を保有し、両方とも暗号化データへのアクセス権限を有しなく、両者の保有する鍵情報を合わせた場合以外に完全な鍵を取得できないため、データのセキュリティ及びユーザのプライバシーが効果的に確保される。このように、情報共有システム104に格納された、ユーザが公開したくない暗号化データの場合、第1クライアント101は、アクセス許可サーバ103を介して、いくつかの第2クライアント102による暗号化データの平文へのアクセスを許可することができる。これにより、情報共有とプライバシー保護とのバランスがとれ、より良い情報共有メカニズムが提供される。
【0053】
いくつかの実例では、ステップ305において、前記アクセス要求から、第2許可コード及び不完全な鍵を取得することは、具体的に、前記アクセス要求から、前記暗号化データのアクセストークンを取得し、前記アクセストークンから、前記第2許可コード及び前記不完全な鍵を取得する、ことを含んでもよい。
【0054】
いくつかの実例では、ステップ301において、前記第1クライアントから前記鍵の前記第1部分を受信する際に、アクセス許可サーバ103は、ファイル識別子と前記暗号化データの保有者のユーザ識別子とをさらに受信する。ステップ302において、前記暗号化データに対応する第1許可コードを生成することは、具体的に、前記保有者のユーザ識別子に対応する規則に従って、前記許可コードを生成し、前記許可コードと、前記鍵の前記第1部分、前記ファイル識別子、及び前記保有者のユーザ識別子とを関連付け、前記アクセス要求を受信すると、前記アクセス要求に付されたファイル識別子と保有者のユーザ識別子とに基づいて、前記アクセス要求に付されたファイル識別子と保有者のユーザ識別子とに関連付けられた前記許可コードと前記鍵の前記第1部分とを取得する、ことを含んでもよい。
【0055】
いくつかの実例では、前記ブロックが、ブロックの高さに対応するものである。ステップ302において、生成された前記第1許可コー
ドが、アクセス可能なブロックの高さ、及び/又は、期限に対応するものである。ステップ306において、前記第2許可コードが前記第1許可コードと同じである場合、前記第2許可コードに対応するアクセス可能なブロックの高さ、及び/又は、期限を取得する。前記アクセス要求の対象となる前記暗号化データのブロックの高さが、前記第2許可コードに対応する前記アクセス可能なブロックの高さとマッチし、及び/又は、前記第2許可コードが前記期限に達していない場合、前記第2許可コードが使用可能であると決定する。
【0056】
いくつかの実例では、上記方法は、第1クライアント101からの、前記許可コードへの取り消し要求に応じて、前記許可コードを失効させる、ことをさらに含んでもよい。アクセス許可サーバ103は、前記許可コードを失効させた後、第1クライアント101に応答を返信してもよい。第1クライアント101は、応答を受信すると、ローカルの許可コードを失効させる。これにより、この許可コードの取り消しのプロセス全体が完了する。このように、ユーザは、必要に応じて、いくつかのユーザ又はデータへの共有を取り消すために、いくつかのデータに対応する許可コードを取り消すことができる。例えば、あるデータの許可コードを以前に得た第2クライアント102は、この許可コードが失効した場合、再びこの許可コードでこのデータへのアクセスを要求すると、この許可コードが使用不可と検証されるため、このデータにアクセスできない。
【0057】
いくつかの実例では、上記方法は、第1クライアント101からの、前記暗号化データへの許可コード生成要求に応じて、前記暗号化データに対応する新たな許可コードを生成し、前記暗号化データに対応する前記新たな許可コードを第1クライアント101に送信する、ことをさらに含んでもよい。このように、ユーザは、あるデータの許可コードを取り消した後、いくつかのユーザによるこのデータへのアクセスを再び許可するように、新たな許可コードを要求することもでき、柔軟なデータアクセス許可が実現される。
【0058】
いくつかの実例では、上記方法は、第1クライアント101からの、前記暗号化データへの許可コード更新要求に応じて、前記暗号化データに対応する新たな許可コードを生成し、元の前記第1許可コードを前記新たな許可コードに置き換え、前記暗号化データに対応する前記新たな許可コードを第1クライアント101に送信することにより、第1クライアント101が元の前記第1許可コードを前記新たな許可コードに置き換えるようにさせる、ことをさらに含んでもよい。
【0059】
図4には、本願の一実施例におけるメッセージのやり取りの手順が示されている。
図4に示すように、この手順は、少なくとも、第1クライアント101、第2クライアント102、アクセス許可サーバ103、及び情報共有システム104の4つのエンティティに関わり、下記のような処理ステップを含んでもよい。
【0060】
ステップ401で、第1クライアント101は、暗号鍵を保有し、情報共有システム104にアップロードしようとするデータに対して暗号化処理を行うことにより、暗号化データを取得する。
【0061】
第1クライアント101は、この暗号化データを情報共有システム104にアップロードし、暗号化データをアップロードすると共に、この暗号化データに関連付けられた、この暗号化データの保有者のユーザ識別子、ファイル識別子を情報共有システム104に送信する。例えば、第1クライアント101は、保有者のユーザ識別子と、ファイル識別子と、暗号化データとが付されたデータアップロード要求を情報共有システム104に送信してもよい。ここで、前記保有者のユーザ識別子は、例えば、QQ番号、クラウドディスクアカウント、ブロックチェーンシステムアカウントなど、現在第1クライアント101にログインしているユーザの識別子であり、ファイル識別子は、暗号化データを識別するためのものである。
【0062】
情報共有システム104は、第1クライアント101からアップロードされた暗号化データを格納して、この暗号化データと、保有者のユーザ識別子、及びファイル識別子とを関連付けてもよい。これにより、この暗号化データを、保有者のユーザ識別子に対応するディレクトリに格納して、ファイル識別子でこの暗号化データを識別する。
【0063】
図5のシナリオでは、第1クライアント101がネットワークディスククライアントであり、情報共有システム104がクラウド側のネットワークディスクサーバ(又は、クラウドディスクサーバと略称される)である。ユーザは、このネットワークディスククライアントを使用して、写真、動画などのファイルをアップロードできる。例えば、コントロールユニット501をタップすると、写真をアップロードでき、コントロールユニット502をタップすると、動画をアップロードできる。ユーザは、アップロードする写真及び動画のプライバシーを確保したい場合、アップロードするデータをネットワークディスククライアントが暗号化するように設定してもよい。このように、ネットワークディスククライアントは、上記ステップ401の暗号化処理を実行することになる。
【0064】
ステップ402で、第1クライアント101は、ステップ401における暗号化に使用された鍵の前半(鍵前半と呼ばれてもよい)をアクセス許可サーバ103にアップロードし、この暗号化データに関連付けられた保有者のユーザ識別子もアクセス許可サーバに送信する。例えば、第1クライアント101は、暗号化データの保有者のユーザ識別子と鍵前半とが付された鍵アップロード要求をアクセス許可サーバ103に送信してもよい。
【0065】
アクセス許可サーバ103は、前記保有者のユーザ識別子に対応する規則に従って、許可コードを生成し、許可コードと、鍵前半、及び前記保有者のユーザ識別子とを関連付けてから、許可コードを第1クライアント101に返信する。
【0066】
ステップ403で、第1クライアント101は、ステップ401における暗号化に使用された鍵の後半(鍵後半と呼ばれてもよい)と、受信された許可コードとをデータ閲覧トークンとして組み合わせ、このデータ閲覧トークンと上記暗号化データのファイル識別子とを関連付ける。
【0067】
第1クライアント101は、上記暗号化データの平文データを第2クライアント102が閲覧可能なように許可する際に、上記データ閲覧トークンを第2クライアント102に提供してもよい。例えば、第2クライアント102は、あるデータへの閲覧許可を第1クライアント101に要求するために、ターゲットファイル情報が付された許可要求を第1クライアント101に送信し、第1クライアント101は、ターゲットファイル情報に基づいて、第2クライアント102が閲覧したいデータ集合に対応するファイル識別子集合を決定できる。このターゲットファイル情報は、ファイル識別子を含んでもよいし、フォルダの識別子又はディレクトリアドレスなどであってもよい。第1クライアント101は、相応のファイル識別子集合を決定でき、さらに、ファイル識別子集合によって、ファイル識別子集合に関連付けられたデータ閲覧トークンを決定できる。ここで、1つのファイル識別子集合(1つ又は複数のファイル識別子)は、1つのデータ閲覧トークンに関連付けられてもよい。これは、第1クライアント101が1つのファイル集合を一括して第2クライアント102に許可することを表す。1つのファイル識別子集合は、複数のデータ閲覧トークンに関連付けられてもよい。ここで、異なるファイル識別子は、異なるデータ閲覧トーク運に関連付けられる。これは、第1クライアント101がファイル毎にそれぞれデータ閲覧トークンを第2クライアント102に提供することを表す。
【0068】
ステップ404で、第2クライアント102は、上記データ閲覧トークンを保有すると、上記暗号化データの保有者のユーザ識別子と、ファイル識別子と、このデータ閲覧トークンとが付された閲覧要求をアクセス許可サーバ103に送信する。
【0069】
図6のシナリオでは、第2クライアント102が、ブロックチェーンページにアクセスするブラウザであり、情報共有システム104がブロックチェーンシステムである。ユーザは、ブロックチェーンページにアクセスすることにより、様々な情報を閲覧できる。一部の情報がプライベートであり、ユーザは、データ閲覧トークンを持っている場合にしか、平文データを閲覧できない。例えば、ユーザがコントロールユニット601をタップすると、閲覧要求を送信するために、ステップ404が実行される。閲覧要求に付されたデータ閲覧トークンには、正しい使用可能な許可コー
ドと正しい鍵後半とが含まれる場合、ブラウザは、「詳細」という項目に対応する平文データが含まれる第2ページを表示させることができる。
【0070】
ステップ405で、アクセス許可サーバ103は、受信された閲覧要求から、データ閲覧トークン、上記保有者のユーザ識別子、及びファイル識別子を抽出し、データ閲覧トークンから許可コードを抽出し、この許可コードが使用可能であるか否かを決定する。ここで、アクセス許可サーバ103が、許可コードが使用可能であるか否かを決定することは、2つの側面を含む。一、データ閲覧トークンから抽出された許可コードが、ローカルに格納されている、この保有者のユーザ識別子に関連付けられた許可コードと同じであるか否かを決定し、データ閲覧トークンから抽出された許可コードが、ローカルで検索された許可コードと一致する場合は、データ閲覧トークンに付された許可コードが合法的であることを表す。二、この2つの許可コードが同じであると決定した場合、さらに、許可コードの期限が切れているか否か(例えば、失効時間に達したか否か、又はまだ有効使用期間内にあるか否か)を検証し、及び/又は、現在閲覧が要求される暗号化データのアドレスが、許可コードに対応するアクセス可能なデータアドレスに属するか否かを検証する。
【0071】
この許可コードが使用可能であると決定した場合、アクセス許可サーバ103は、許可コードに関連付けられた鍵前半を取得し、データ閲覧トークンから鍵後半を抽出し、鍵前半と鍵後半とを完全な鍵として組み合わせる。
【0072】
また、アクセス許可サーバ103は、上記保有者のユーザ識別子と、ファイル識別子とが付された検索要求を情報共有システム104に送信することにより、情報共有
システム104が、この保有者のユーザ識別子と、ファイル識別子とに基づいて、この保有者のユーザ識別子と、ファイル識別子とに関連付けられた暗号化データを検索し、この暗号化データをアクセス許可サーバ103に送信するようにさせる。
【0073】
ステップ406で、ステップ405で取得された完全な鍵で暗号化データを復号化処理する。データ閲覧トークンから抽出された鍵後半が正確である場合、ステップ405において正確で完全な鍵を取得することができ、本ステップにおいて復号化に成功することにより、復号化データ(即ち、平文データ)を取得すると共に、第2クライアント102に復号化データを返信することができる。データ閲覧トークンから抽出された鍵後半が間違った場合、ステップ405で取得された鍵が間違ったものであり、本ステップにおいて復号化に成功できない。この場合、第2クライアント102にエラーを報告してもよいし、第2クライアント102に暗号化データを直接に返信してもよい。要するに、第2クライアント102は、平文データの閲覧に成功できない。さらに、第1クライアント101からアップロードされたデータのセキュリティが確保される。
【0074】
上記各ステップのいずれに処理が失敗しても、本手順を直接に終了すればよい。
【0075】
上記の方法の実例に基づき、本願の実施例では、上記方法を実現可能なクライアント(第1クライアント101であってもよい)も提供されている。
図7に示すように、第1クライアント700は、
鍵で平文データを暗号化することにより、暗号化データを取得する暗号化モジュール701と、
前記暗号化データを、情報共有システム104における1つのブロックにアップロードし、前記鍵の第1部分を、前記情報共有システム104に対応するアクセス許可サーバ103にアップロードし、前記情報共有システムがブロックチェーンシステムであるアップロードモジュール702と、
前記アクセス許可サーバ103から、前記暗号化データに対応する許可コードを受信し、あるユーザによる前記暗号化データへのアクセスを許可する際に、前記許可コードと前記鍵の第2部分とを第2クライアント102に送信することにより、前記第2クライアント102が、前記暗号化データへのアクセス要求を前記アクセス許可サーバに送信する際に、前記アクセス要求に前記許可コードと前記鍵の前記第2部分とを付するよう実現させ、前記アクセス許可サーバ103が、前記許可コードが使用可能であると決定した場合、前記鍵の前記第1部分及び前記第2部分に基づき前記鍵を生成し、生成された前記鍵で、前記情報共有システム104における前記ブロックから取得された前記暗号化データを復号化することにより、前記平文データを取得すると共に、前記第2クライアント102に前記平文データを返信するようにし、前記鍵の第2部分は前記鍵の前記第1部分を除いた残りの部分を含む許可モジュール703と、を備える。
【0076】
いくつかの実例では、許可モジュール703は、さらに、前記許可コードと前記鍵の前記第2部分とが含まれる、前記暗号化データのアクセストークンを生成する。ここで、前記許可モジュール703は、前記アクセストークンを前記第2クライアント102に送信することにより、前記第2クライアント102が前記アクセス要求に前記アクセストークンを付するようにさせる。
【0077】
いくつかの実例では、前記暗号化データを前記情報共有システム104にアップロードする際に、前記アップロードモジュール702は、前記暗号化データのファイル識別子と、前記暗号化データの保有者のユーザ識別子とをさらにアップロードすることにより、前記情報共有システム104が、前記暗号化データと、前記ファイル識別子、及び前記保有者のユーザ識別子とを関連付けるよう実現させ、前記アクセス許可サーバ103が、前記ファイル識別子と前記保有者のユーザ識別子とに基づいて、前記情報共有システム104から前記暗号化データを取得するようにさせる。
【0078】
いくつかの実例では、前記鍵の前記第1部分を前記アクセス許可サーバ103にアップロードする際に、前記アップロードモジュール702は、前記ファイル識別子と前記保有者のユーザ識別子とをさらにアップロードすることにより、前記アクセス許可サーバ103が、前記保有者のユーザ識別子に対応する規則に従って、前記許可コードを生成し、前記許可コードと、前記鍵の前記第1部分、前記ファイル識別子、及び前記保有者のユーザ識別子とを関連付け、前記アクセス要求を受信すると、前記アクセス要求に付された前記ファイル識別子と前記保有者のユーザ識別子とに基づいて、前記アクセス要求に付された前記ファイル識別子と前記保有者のユーザ識別子とに関連付けられた前記許可コードと前記鍵の前記第1部分とを取得し、取得された前記許可コードに基づいて、前記アクセス要求に付された前記許可コードが使用可能であるか否かを決定し、取得された前記鍵の前記第1部分と、前記アクセス要求に付された前記第2部分とに基づき、前記鍵を生成するようにさせる。
【0079】
いくつかの実例では、前記許可モジュール703は、さらに、前記許可コードと前記鍵の前記第2部分とが含まれる、前記暗号化データのアクセストークンを生成し、前記アクセストークンと前記ファイル識別子とを関連付ける。ここで、前記許可モジュール703は、前記ファイル識別子に関連付けられた前記アクセストークンを前記第2クライアント102に送信することにより、前記第2クライアント102が前記アクセス要求に前記アクセストークンを付するようにさせる。
【0080】
いくつかの実例では、前記許可モジュール703は、さらに、前記許可コードへの取り消し要求を前記アクセス許可サーバ103に送信することにより、前記アクセス許可サーバ103が前記許可コードを失効させるようにさせる。また、前記許可モジュール703は、ローカルの前記許可コードを失効させる。
【0081】
いくつかの実例では、前記許可モジュール703は、前記暗号化データへの許可コード生成要求を前記アクセス許可サーバ103に送信することにより、前記アクセス許可サーバ103が、前記暗号化データに対応する新たな許可コードを生成するようにさせる。また、前記許可モジュール703は、前記アクセス許可サーバ103から、前記暗号化データに対応する前記新たな許可コードを受信する。
【0082】
いくつかの実例では、前記許可モジュール703は、さらに、前記暗号化データへの許可コード更新要求を前記アクセス許可サーバ103に送信することにより、前記アクセス許可サーバ103が、前記暗号化データに対応する新たな許可コードを生成し、元の前記許可コードを前記新たな許可コードに置き換えるようにさせる。また、前記許可モジュール703は、前記アクセス許可サーバ103から前記新たな許可コードを受信し、元の前記許可コードを前記新たな許可コードに置き換える。
【0083】
上記の方法の実例に基づき、本願の実施例では、上記方法を実現可能なアクセス許可サーバ(例えば、上記のアクセス許可サーバ103)も提供されている。
図8に示すように、このサーバ800は、
第1クライアント101から第1鍵の第1部分を受信し、前記第1鍵が、情報共有システム104における1つのブロックにアップロードされた暗号化データに対応するものであり、前記暗号化データが、前記第1鍵で平文データに対して暗号化処理を行うことにより取得されたものであり、前記情報共有システムがブロックチェーンシステムであり、前記暗号化データに対応する第1許可コードを生成し、前記第1許可コードを前記第1クライアント101に送信することにより、前記第1クライアント101が、第2クライアント102による前記暗号化データへのアクセスを許可する際に、前記第1許可コードと前記第1鍵の第2部分とを前記第2クライアント102に送信するよう実現させ、前記第2クライアント102が、前記暗号化データにアクセスする際に、前記第1許可コードと前記第1鍵の前記第2部分とをアクセス要求に付するようにし、前記第1鍵の第2部分は前記第1鍵の前記第1部分を除いた残りの部分を含む許可モジュール801と、
いずれか1つのクライアント(例えば、第2クライアント102)からの、前記暗号化データへのアクセス要求を受信すると、前記アクセス要求から、第2許可コード及び不完全な鍵を取得し、前記第2許可コードが前記第1許可コードと同じであって、かつ前記第2許可コードが使用可能である場合、鍵モジュール803をトリガーする検証モジュール802と、
前記不完全な鍵と、前記暗号化データに対応する前記第1鍵の第1部分とに基づき、第2鍵を生成し、前記不完全な鍵が前記第1鍵の第2部分と同じである場合、生成された前記第2鍵が前記第1鍵と同じである前記鍵モジュール803と、
前記情報共有システム104における前記ブロックから、前記暗号化データを取得し、前記第2鍵で前記暗号化データを復号化処理し、前記第2鍵が前記第1鍵と同じである場合、復号化によって前記平文データを取得すると共に、前記アクセス要求の送信元である前記クライアントに前記平文データを送信する復号化モジュール804と、を備えてもよい。
【0084】
いくつかの実例では、前記検証モジュール802は、前記アクセス要求から前記暗号化データのアクセストークンを取得し、前記アクセストークンから前記第2許可コード及び前記不完全な鍵を取得する。
【0085】
いくつかの実例では、前記許可モジュール801は、前記第1クライアント101から前記鍵の前記第1部分を受信する際に、ファイル識別子と前記暗号化データの保有者のユーザ識別子とをさらに受信する。前記許可モジュール801は、前記保有者のユーザ識別子に対応する規則に従って、前記第1許可コードを生成し、前記第1許可コードと、前記鍵の前記第1部分、前記ファイル識別子、及び前記保有者のユーザ識別子とを関連付ける。前記検証モジュール802は、前記アクセス要求を受信すると、前記アクセス要求に付されたファイル識別子と前記保有者のユーザ識別子に基づいて、前記アクセス要求に付されたファイル識別子と前記保有者のユーザ識別子に関連付けられた前記第1許可コードと前記鍵の前記第1部分とを取得する。
【0086】
いくつかの実例では、前記ブロックが、ブロックの高さに対応するものであり、前記許可モジュール801により生成された前記第1許可コー
ドが、アクセス可能なブロックの高さ、及び/又は、期限に対応するものであり、前記検証モジュール802は、前記第2許可コードが前記第1許可コードと同じである場合、前記第2許可コードに対応するアクセス可能なブロックの高さ、及び/又は、期限を取得し、前記アクセス要求の対象となる前記暗号化データのブロックの高さが、前記第2許可コードに対応する前記アクセス可能なブロックの高さとマッチし、及び/又は、前記第2許可コードが前記期限に達していない場合、前記第2許可コードが使用可能であると決定する。
【0087】
いくつかの実例では、前記許可モジュール801は、さらに、前記第1クライアント101からの、前記
第1許可コードへの取り消し要求に応じて、前記第1許可コードを失効させ、前記第1クライアント101に応答を返信することにより、前記第1クライアント101がローカルの前記第1許可コードを失効させるようにさせる。
【0088】
いくつかの実例では、前記許可モジュール801は、さらに、前記第1クライアント101からの、前記暗号化データへの許可コード生成要求に応じて、前記暗号化データに対応する新たな許可コードを生成し、前記暗号化データに対応する前記新たな許可コードを前記第1クライアント101に送信する。
【0089】
いくつかの実例では、前記許可モジュール801は、さらに、前記第1クライアント101からの、前記暗号化データへの許可コード更新要求に応じて、前記暗号化データに対応する新たな許可コードを生成し、元の前記第1許可コードを前記新たな許可コードに置き換え、前記暗号化データに対応する前記新たな許可コードを前記第1クライアント101に送信することにより、前記第1クライアント101が元の前記第1許可コードを前記新たな許可コードに置き換えるようにさせる。
【0090】
上記の各モジュールの機能の実現原理は、上記に詳述されているが、ここで説明を省略する。
【0091】
いくつかの実例では、上記のクライアント700及びサーバ800は、様々なコンピューティングデバイスで実行され、該コンピューティングデバイスのメモリにロードされることが可能である。本願の実施例では、コンピューティングデバイスが提供されている。このコンピューティングデバイスは、1つ又は複数のプロセッサと、メモリと、このメモリに記憶され、前記1つ又は複数のプロセッサによって実行されるように構成される1つ又は複数のプログラムと、を備える。前記1つ又は複数のプログラムには、上記のいずれか1つの方法の実例を実行するための命令が含まれる。
【0092】
図9は、クライアント700又はサーバ800の位置するコンピューティングデバイスの構成図である。
図9に示すように、このコンピューティングデバイスは、1つ又は複数のプロセッサ(CPU)902と、通信モジュール904と、メモリ906と、ユーザインタフェース910と、これらのコンポーネントを相互に接続するための通信バス908と、を備える。
【0093】
プロセッサ902は、ネットワーク通信及び/又はローカル通信を実現するために、通信モジュール904を介して、データを送受信することができる。
【0094】
ユーザインタフェース910は、1つ又は複数の出力デバイス912を備える。1つ又は複数の出力デバイス912は、1つ又は複数のスピーカ、及び/又は、1つ又は複数の視覚的なディスプレイを含む。ユーザインタフェース910は、1つ又は複数の入力デバイス914も備える。入力デバイス914は、例えば、キーボード、マウス、音声指示入力手段又はマイク、タッチディスプレイ、タッチセンシティブ入力タブレット、モーションキャプチャカメラ、若しくは、その他の入力ボタン又はコントロールユニットなどを含む。
【0095】
メモリ906は、DRAM、SRAM、DDR RAM、又はその他のランダムアクセスソリッドステート記憶デバイスのような高速ランダムアクセスメモリ、或いは、1つ又は複数のディスク記憶デバイス、光ディスク記憶デバイス、フラッシュデバイス、又はその他の不揮発性ソリッドステート記憶デバイスのような不揮発性メモリであってもよい。
【0096】
メモリ906は、プロセッサ902が実行可能な命令セットを記憶する。この命令セットは、
各種の基本的なシステムサービスの処理、及びハードウェアの関連タスクの実行に用いられるプログラムが含まれるオペレーティングシステム916と、
様々なアプリケーションプログラムを含み、上記の各実例における処理手順を実現可能なアプリケーション918と、を含む。アプリケーション918は、例えば、
図7に示すクライアント700、及び/又は、
図8に示すサーバ800を含んでもよい。いくつかの実例では、クライアント700は、
図7に示す各モジュール701〜703の一部又は全部を含んでもよく、各モジュール701〜703には、機械実行可能命令が記憶されてもよい。プロセッサ902は、メモリ906の各モジュール701〜703における機械実行可能命令を実行することにより、上記各モジュール701〜703の機能を実現できる。いくつかの実例では、サーバ800は、
図8に示す各モジュール801〜804の一部又は全部を含んでもよく、各モジュール801〜804には、機械実行可能命令が記憶されてもよい。プロセッサ902は、メモリ906の各モジュール801〜804における機械実行可能命令を実行することにより、上記各モジュール801〜804の機能を実現できる。
【0097】
上記の実例で提供されたクライアント、サーバ、及びコンピューティングデバイスによれば、第1クライアント101が鍵及び許可コードを保有し、アクセス許可サーバ103が許可コードと鍵の第1部分とを保有し、第2クライアント102が、許可を得た場合、鍵の第2部分と、許可コードとを保有可能である。このように、第2クライアント102が、アクセス許可サーバ103を介して、相応のデータへのアクセスを要求すると、アクセス許可サーバ103は、まず、許可コードが使用可能であるか否かを検証し、許可コードが使用可能である場合、それぞれ第1クライアント101及び第2クライアント102から取得された不完全な鍵(鍵の第1部分及び第2部分)を使用して、完全な鍵を取得してもよい。第2クライアント102から提供された不完全な鍵に問題がある場合、正しい完全な鍵を取得できず、暗号化データの復号化に成功できないため、データのセキュリティが確保される。この構成では、第2クライアント102及びアクセス許可サーバ103が、それぞれ鍵の一部を保有し、両方とも暗号化データへのアクセス権限を有しなく、両者の保有する鍵情報を合わせた場合以外に完全な鍵を取得できないため、データのセキュリティ及びユーザのプライバシーが効果的に確保される。
【0098】
説明すべきものとして、上記の各手順及び各構成図では、すべてのステップ及びモジュールが必要なわけではなく、実際の必要に応じて、いくつかのステップ又はモジュールを省略してもよい。各ステップの実行順序は、固定されず、必要に応じて調整されてもよい。各モジュールの分割は、単に説明を容易にするための機能的な分割にすぎない。実際の実現では、1つのモジュールを複数のモジュールに分けて、その機能を実現してもよいが、同様に、複数のモジュールの機能を同一のモジュールによって実現してもよい。これらモジュールは、同一の機器に位置してもよく、異なる機器に位置してもよい。
【0099】
各実施例におけるハードウェアモジュールは、ハードウェア方式で、又は、ハードウェアプラットフォーム+ソフトウェアの方式で、実現されてもよい。上記ソフトウェアは、機械可読命令を含み、不揮発性記憶媒体に記憶される。このため、各実施例は、ソフトウェア製品として具現されてもよい。
【0100】
各例では、ハードウェアは、専用のハードウェア、又は、機械可読命令を実行するハードウェアによって実現されてもよい。例えば、ハードウェアは、特定の動作を完成させるための、特別に設計された恒久的な回路又はロジックデバイス(例えば、FPGAやASICのような専用プロセッサ)であってもよい。ハードウェアは、特定の動作を実行するための、ソフトウェアによって一時的に配置されるプログラマブルロジックデバイス又は回路(例えば、汎用プロセッサやその他のプログラマブルプロセッサを含む)を含んでもよい。
【0101】
また、本願の各々の実例は、データ処理機器(例えば、コンピュータ)により実行されるデータ処理プログラムによって実現されてもよい。明らかに、データ処理プログラムによって本願発明が構成されている。また、通常、記憶媒体に記憶されたデータ処理プログラムは、直接にプログラムを記憶媒体から読み出すことにより、又は、プログラムをデータ処理機器の記憶デイバイ(例えば、ハードディスク及び/又は内部メモリ)にインストール又はコピーすることにより、実行される。このため、このような記憶媒体によっても、本願発明が構成されている。本願の実施例では、本願の上記の方法の実例のいずれかを実行させることが可能なデータ処理プログラムを記憶した不揮発性記憶媒体も提供されている。
【0102】
図7及び
図8におけるモジュールに対応する機械可読命令は、コンピュータ上で動作するオペレーティングシステムなどに、ここで説明される処理の一部又は全部を実行させることが可能である。不揮発性コンピュータ可読記憶媒体は、コンピュータに挿入された拡張ボードに設けられたメモリ、又はコンピュータに接続された拡張ユニットに設けられたメモリであってもよい。拡張ボード又は拡張ユニットに搭載されているCPUなどは、命令に従って、実際の処理の一部又は全部を実行できる。
【0103】
不揮発性コンピュータ可読記憶媒体は、フロッピーディスク、ハードディスク、光磁気ディスク、光ディスク(例えば、CD−ROM、CD−R、CD−RW、DVD−ROM、DVD−RAM、DVD−RW、DVD+RW)、磁気テープ、不揮発性メモリカード、及びROMを含む。任意選択的に、通信ネットワークによって、サーバコンピュータからプログラムコードをダウンロードしてもよい。
【0104】
上記のように、特許請求の範囲は、上記に説明された実例の実施形態に限定されるべきではなく、明細書を全体として最も広い解釈が与えられるべきである。