JP2005223953A - 暗号方式、暗号情報生成装置、暗号情報送信装置、および方法、並びにコンピュータ読み取り可能な記録媒体 - Google Patents
暗号方式、暗号情報生成装置、暗号情報送信装置、および方法、並びにコンピュータ読み取り可能な記録媒体 Download PDFInfo
- Publication number
- JP2005223953A JP2005223953A JP2005125611A JP2005125611A JP2005223953A JP 2005223953 A JP2005223953 A JP 2005223953A JP 2005125611 A JP2005125611 A JP 2005125611A JP 2005125611 A JP2005125611 A JP 2005125611A JP 2005223953 A JP2005223953 A JP 2005223953A
- Authority
- JP
- Japan
- Prior art keywords
- encryption
- key
- information
- lock
- group
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
【課題】 グループ内での情報の共有化およびグループ外に対する機密性を保持しながら、暗号情報の通信、共有を可能とする。
【解決手段】 平文を共通鍵暗号方式における共通鍵Kにより暗号化した暗号情報K(D)と、1以上のメンバMi(i=1〜n)を構成員とするグループに属するメンバ個々の公開鍵暗号方式における公開鍵Piによって、共通鍵Kを暗号化した1以上の暗号鍵情報Pi(K)とを含む暗号情報を生成し送受信する。本構成により、各メンバMi(i=1〜n)は、暗号鍵情報Pi(K)をメンバ個々の公開鍵暗号方式における秘密鍵Siによって復号し共通鍵Kを取得し、暗号情報K(D)の復号により、データ(D)を取得でき、グループ内と外との間では高度な機密性を保ち、グループ内のメンバは暗号情報を共有することが可能となる。
【選択図】 図11
【解決手段】 平文を共通鍵暗号方式における共通鍵Kにより暗号化した暗号情報K(D)と、1以上のメンバMi(i=1〜n)を構成員とするグループに属するメンバ個々の公開鍵暗号方式における公開鍵Piによって、共通鍵Kを暗号化した1以上の暗号鍵情報Pi(K)とを含む暗号情報を生成し送受信する。本構成により、各メンバMi(i=1〜n)は、暗号鍵情報Pi(K)をメンバ個々の公開鍵暗号方式における秘密鍵Siによって復号し共通鍵Kを取得し、暗号情報K(D)の復号により、データ(D)を取得でき、グループ内と外との間では高度な機密性を保ち、グループ内のメンバは暗号情報を共有することが可能となる。
【選択図】 図11
Description
本発明は、共通鍵暗号方式および公開鍵暗号方式の組み合わせ構成を持つ暗号方式、暗号情報生成装置、暗号情報送信装置、および方法、並びにコンピュータ読み取り可能な記録媒体に関する。
公開鍵暗号と呼ばれる暗号方式が特許文献1(米国特許4,200,700号)に記載されている。公開鍵暗号は、平文を暗号化する際に用いる公開鍵と、暗号を平文に復号する際に用いる秘密鍵とを有する。公開鍵と秘密鍵とは異なる鍵であり、公開鍵は、文字通り公開され、公知の状態においておくことが可能である。従来の暗号方式は、暗号化および復号に同一の鍵が使用されており、暗号化の際の鍵の機密性を保つことが重要な課題であったが、この公開鍵暗号方式では、暗号化の鍵の機密性は不要となる。また、暗号文書を通信する人数がn人であった場合、従来の暗号化、復号共通鍵方式であるとn×(n−1)÷2個の鍵が必要となるが、公開鍵暗号方式ではn個の鍵で済むといった利点がある。また、各人の署名、すなわち各人による秘密鍵による暗号化処理においても同じ枠組みを用いることができるといった特徴がある。例えば秘密鍵Aを有する暗号通信メンバPが、通信文Xを秘密鍵Aで変換し、変換した文書Yと通信文Xを他のメンバQに送付し、メンバQは、メンバPの公開鍵Bで変換文書Yを変換し、Yの変換結果がXと一致すれば、その文書は、確かにメンバPによって送付されたものであることが確認できる。このように公開鍵暗号方式には、従来の暗号方式には無いいくつかの優れた点を有する。
また、特許文献2(特開平7−297818号公報)に、グループに対する公開鍵と秘密鍵の割り当てについての構成が記載されている。これは、カードのような物理的実態にグループ秘密鍵を埋め込み、カードをグループのメンバが確実に所持することを前提としたシステムである。すなわち、上述の秘密鍵と公開鍵の暗号システムをカードという実態を利用した構成とすることによって、個人という恒久的な存在から分離したカードという物理的実態を利用して鍵の管理を実現している。
米国特許4,200,700号公報
特開平7−297818号公報
公開鍵暗号方式では、個人のような恒久的な存在を独立した単位として設定している。従って、個人以外の例えば複数のメンバを一つの単位として設定する必要がある場合等には十分な機能を果たし得ない。また、上述のようなカードを使用したシステムにおいては、カードというハードウェアを用いなければならないこと、カード自体の管理の問題、カードの紛失、盗難等に起因するカード所有者の正当性の問題、すなわちカード保有者がカードの正当な所有者であるかどうかの判断が困難であるという問題が発生する。
例えば、企業のように、部、課、あるいは係といった組織は協同作業単位であり、またそのような組織とは独立に成り立つタスクフォースといった複数の個人から構成される協同作業単位である。これら協同作業単位では、情報も共有される必要がある。すなわち、協同作業単位の内部と外部との関係では、情報の機密性を維持する必要があるが、内部の各メンバ間での情報の流通は必要となる。従って、その協同作業単位の任意の構成員が共有情報に対する復号処理、あるいは署名処理を行えるような暗号方式が必要となる。
さらに、協同作業単位の構成員は追加や削除といった変更が発生することがあるため、暗号方式は、これら構成員の変更にも対応可能な方式であることが必要である。また、協同作業単位と同様に、企業内における人事部長のような役割を果たすために、ある時点においてその役割を果たしている特定の個人とは独立な、すなわちその役割を果たしている個人の変更に対応可能な形で、その役割に応じた特定かつ継続的な機密状態を保持する必要がある。
本発明は、上記の問題を解決する暗号方式を提供する。本発明は、少なくとも平文を共通鍵暗号方式における共通鍵Kにより暗号化した暗号情報K(D)と、1以上のメンバMi(i=1〜n)を構成員とするグループに属するメンバ個々の公開鍵暗号方式における公開鍵Piによって前記共通鍵Kを暗号化した1以上の暗号鍵情報Pi(K)とを有する構成データを暗号情報として生成し、送受信することで、公開鍵暗号方式を個人を単位とするのではなく、個人およびグループを要素とする集合であるグループにおいて使用可能とし、特定のグループに属する構成員(メンバ)が復号可能な暗号情報を利用可能とした暗号方式、暗号情報生成装置、暗号情報送信装置、および方法、並びにコンピュータ読み取り可能な記録媒体を提供することを目的とする。
本発明の第1の側面は、少なくとも平文を共通鍵暗号方式における共通鍵Kにより暗号化した暗号情報K(D)と、1以上のメンバMi(i=1〜n)を構成員とするグループに属するメンバ個々の公開鍵暗号方式における公開鍵Piによって前記共通鍵Kを暗号化した1以上の暗号鍵情報Pi(K)と、を有する構成データを暗号情報として構成したことを特徴とする暗号方式にある。
本発明の第2の側面は、少なくとも平文を共通鍵暗号方式における共通鍵Kにより暗号化した暗号情報K(D)と、1以上のメンバMi(i=1〜n)を構成員とするグループに属するメンバ個々の公開鍵暗号方式における公開鍵Piによって前記共通鍵Kを暗号化した1以上の暗号鍵情報Pi(K)とを生成する暗号手段と、前記暗号手段から、前記暗号情報K(D)と、前記暗号鍵情報Pi(K)を入力し、前記暗号情報K(D)と、前記暗号鍵情報Pi(K)を構成データとして有する暗号情報を生成する暗号情報生成手段とを有することを特徴とする暗号情報生成装置にある。
本発明の第3の側面は、少なくとも平文を共通鍵暗号方式における共通鍵Kにより暗号化した暗号情報K(D)と、1以上のメンバMi(i=1〜n)を構成員とするグループに属するメンバ個々の公開鍵暗号方式における公開鍵Piによって前記共通鍵Kを暗号化した1以上の暗号鍵情報Pi(K)とを生成する暗号手段と、前記暗号手段から、前記暗号情報K(D)と、前記暗号鍵情報Pi(K)を入力し、前記暗号情報K(D)と、前記暗号鍵情報Pi(K)を構成データとした暗号情報を送信する暗号情報送信手段とを有することを特徴とする暗号情報送信装置にある。
本発明の第4の側面は、少なくとも平文を共通鍵暗号方式における共通鍵Kにより暗号化した暗号情報K(D)と、1以上のメンバMi(i=1〜n)を構成員とするグループに属するメンバ個々の公開鍵暗号方式における公開鍵Piによって前記共通鍵Kを暗号化した1以上の暗号鍵情報Pi(K)とを有する構成データを暗号情報として送受信する構成を有することを特徴とする暗号情報通信システムにある。
本発明の第5の側面は、暗号手段において、少なくとも平文を共通鍵暗号方式における共通鍵Kを適用して暗号化し、暗号情報K(D)を生成するステップと、暗号手段において、1以上のメンバMi(i=1〜n)を構成員とするグループに属するメンバ個々の公開鍵暗号方式における公開鍵Piを適用して、前記共通鍵Kを暗号化した1以上の暗号鍵情報Pi(K)を生成するステップと、暗号情報生成手段において、前記暗号手段の生成する前記暗号情報K(D)と、前記暗号鍵情報Pi(K)を入力し、前記暗号情報K(D)と、前記暗号鍵情報Pi(K)を構成データとして有する暗号情報を生成するステップとを有することを特徴とする暗号情報生成方法にある。
本発明の第6の側面は、暗号手段において、少なくとも平文を共通鍵暗号方式における共通鍵Kを適用して暗号化し、暗号情報K(D)を生成するステップと、暗号手段において、1以上のメンバMi(i=1〜n)を構成員とするグループに属するメンバ個々の公開鍵暗号方式における公開鍵Piを適用して、前記共通鍵Kを暗号化した1以上の暗号鍵情報Pi(K)を生成するステップと、暗号情報送信手段において、前記暗号手段の生成する前記暗号情報K(D)と、前記暗号鍵情報Pi(K)を入力し、前記暗号情報K(D)と、前記暗号鍵情報Pi(K)を構成データとして有する暗号情報を生成するステップとを有することを特徴とする暗号情報送信方法にある。
本発明の第7の側面は、暗号情報の生成処理をコンピュータ上で実行させるコンピュータ・プログラムを記録したコンピュータ読み取り可能な記録媒体であり、暗号手段において、少なくとも平文を共通鍵暗号方式における共通鍵Kを適用して暗号化し、暗号情報K(D)を生成するステップと、暗号手段において、1以上のメンバMi(i=1〜n)を構成員とするグループに属するメンバ個々の公開鍵暗号方式における公開鍵Piを適用して、前記共通鍵Kを暗号化した1以上の暗号鍵情報Pi(K)を生成するステップと、暗号情報生成手段において、前記暗号手段の生成する前記暗号情報K(D)と、前記暗号鍵情報Pi(K)を入力し、前記暗号情報K(D)と、前記暗号鍵情報Pi(K)を構成データとして有する暗号情報を生成するステップとを実行させるプログラムを記録したコンピュータ読み取り可能な記録媒体にある。
本発明の構成によれば、共通鍵暗号方式および公開鍵暗号方式の組み合わせ構成を持つ暗号方式を実現し、平文を共通鍵暗号方式における共通鍵Kにより暗号化した暗号情報K(D)と、1以上のメンバMi(i=1〜n)を構成員とするグループに属するメンバ個々の公開鍵暗号方式における公開鍵Piによって共通鍵Kを暗号化した1以上の暗号鍵情報Pi(K)とを、構成要素として含む暗号情報を生成して、この暗号情報を送受信する構成とすることで、各メンバMi(i=1〜n)は、暗号鍵情報Pi(K)を自己の保持するメンバ個々の公開鍵暗号方式における秘密鍵Siによって復号して共通鍵暗号方式における共通鍵Kを取得して、暗号情報K(D)の復号により、データ(D)を取得することができ、グループ内と外との間では高度な機密性を保ちながら、グループ内のメンバ間ではメンバであることの確認の基に暗号情報を共有することが可能となる。
本発明の概要をまず述べる。以下の説明において個人の集合をグループと呼び、グループの要素、すなわち構成員である個人をメンバと呼ぶ。本発明は、公開鍵暗号方式において、グループの概念を導入したものである。すなわち、特定のグループに属する任意のメンバが復号可能である暗号化と、特定のグループに属する任意のメンバによる署名を代表的な機能とする暗号方式である。本発明では、グループ秘密鍵による署名を可能とすることにより、実際に署名したメンバを明確にせずグループ内のメンバによる署名であることのみを明らかにできるという利点を有する。
グループに対応する秘密鍵と公開鍵のペアを提供し、それぞれをグループ秘密鍵、グループ公開鍵と呼ぶ。グループ秘密鍵をすべてのメンバの個人公開鍵でそれぞれ暗号化し、その暗号化されたグループ秘密鍵の集合を作り、この暗号化されたグループ秘密鍵の集合は、少なくとも各メンバが入手可能なものとしておく。これにより、グループ内の任意のメンバは、自分自身の個人秘密鍵を用いて、対応する個人公開鍵で暗号化されたグループ秘密鍵を復号すること、すなわち獲得することができる。よって、グループ公開鍵で任意の情報を暗号化すれば、グループのメンバは、その暗号化された情報を上記の手法で獲得したグループ秘密鍵を使用して復号することができる。同様に、グループのメンバは、グループ秘密鍵を使用して署名を行うことができる。
本発明は、これらの機能を実現するために必要となるグループ秘密鍵およびグループ公開鍵のペアの生成、グループ公開鍵による暗号化処理、グループ秘密鍵による復号処理、さらにグループのメンバの追加、削除等の変更の際の処理について明らかにする。
情報の暗号化により、情報の機密性を保持しようとする場合には、暗号化された情報自体の所在は問わない、すなわち明らかにされない。このことは、一旦、暗号化された情報を、何らかの理由により、暗号化し直さなければならない機構は受け入れがたいことを意味する。なぜなら、所在を問わないということは、暗号化し直さなければならない情報の所在の特定が困難であるからである。そのため、本発明ではグループの構成員であるメンバに変更があった場合は、一旦、暗号化された情報の再暗号化ではなく、鍵の作り直しで対応することになる。従来の個人を単位とする公開鍵暗号方式では、恒久的な存在である個人と鍵が1体1対応であり、鍵の作り直しという要請はなかったが、本発明では、グループ対鍵という対応関係が発生し、グループの構成要素の変更に基づく鍵の変更要請が発生する。
本発明の暗号および署名方式は、上述のグループ単位の暗号化および署名のみではなく、組織内の特定の役割を果たすポジションにある個人、例えば企業内の人事部長といった役割に対応する鍵を提供する場合にも有効な機能を持つ。例えば、人事部長の役割に対応する鍵があり、人事部長を努める個人が変更された場合には、人事部長という役割に対応する鍵を変更することによって実世界の変更に対応可能である。人事部長に対して暗号化文書を送付する側は、従来からの当該役割(人事部長)に対応する公開鍵を使用して情報を暗号化すればよい。また、新たな人事部長は、すでに暗号化されている情報を変更することなく、過去に当該役割に対応する公開鍵を使用して暗号化された情報を参照することが可能となる。
企業内のプロジェクト等ある目的を有するグループにおいては、複数人による協同作業や役割に基づいた作業が重要であり、その協同作業グループのメンバや、役割を果たす個人は固定的なものではない。従って、グループの中と外との機密性保持能力はより高度なものが要求される。
また、情報ネットワークサービスにおいて公証局と呼ばれる公開鍵に対する所定レベルの保証を与えるシステムが利用されつつあるが、本発明においては、公証局を利用することによって無効となった鍵の排除が可能である。
次に、本発明を構成する各要素について説明する。説明は以下の項目について行う。
(1)複合錠
(2)グループ錠
(3)個人錠
(4)個人錠の秘密鍵
(5)複合錠リスト
(6)信用体
(7)公証局
(1)複合錠
(2)グループ錠
(3)個人錠
(4)個人錠の秘密鍵
(5)複合錠リスト
(6)信用体
(7)公証局
(1)複合錠
複合錠は、次に説明するグループ錠(役割錠)、個人錠を実現する錠の総称であり、具体的には以下の要素を持つ電子データである。
複合錠は、次に説明するグループ錠(役割錠)、個人錠を実現する錠の総称であり、具体的には以下の要素を持つ電子データである。
a.名前
複合錠に対応する実世界の実態を意味する人間が可読な文字列であり、複合錠の識別子としての役割を有する。人間が異なる文字列を同一と誤って判断することを防ぐためスペースあるいは混同されやすい文字列の使用はしないことが好ましい。
複合錠に対応する実世界の実態を意味する人間が可読な文字列であり、複合錠の識別子としての役割を有する。人間が異なる文字列を同一と誤って判断することを防ぐためスペースあるいは混同されやすい文字列の使用はしないことが好ましい。
b.作成日時、作成者
複合錠を作成した日時、および複合錠の作成者である。作成者は、作成した複合錠全体に対する署名を行う。署名の手順には、複合錠を構成する電子データを作成者の個人鍵で暗号化することが含まれる。
複合錠を作成した日時、および複合錠の作成者である。作成者は、作成した複合錠全体に対する署名を行う。署名の手順には、複合錠を構成する電子データを作成者の個人鍵で暗号化することが含まれる。
c.秘密鍵のリスト
複合錠の秘密鍵を、メンバの公開鍵で暗号化し、メンバの名前(メンバを識別するデータであればよい)をラベルとして付与したもののリストである。メンバの秘密鍵によって復号することにより、複合錠の秘密鍵を獲得できる。複合錠の秘密鍵を用いて他から送付された暗号の復号が可能である。
複合錠の秘密鍵を、メンバの公開鍵で暗号化し、メンバの名前(メンバを識別するデータであればよい)をラベルとして付与したもののリストである。メンバの秘密鍵によって復号することにより、複合錠の秘密鍵を獲得できる。複合錠の秘密鍵を用いて他から送付された暗号の復号が可能である。
d.公開鍵
複合錠の公開鍵である。情報を暗号化する際には、この公開鍵によってデータ変換を実行し、暗号とする。
複合錠の公開鍵である。情報を暗号化する際には、この公開鍵によってデータ変換を実行し、暗号とする。
e.変更錠の秘密錠リスト
情報の機密性保持等に用いる公開鍵と秘密鍵のペアとは独立に、複合錠の変更権を制御するための公開鍵と秘密鍵とのペアが必要となる。このペアを変更錠と呼ぶ。この変更錠の秘密鍵を、変更権所有者の公開鍵で暗号化し、変更権所有者の名前をラベルとして付与したもののリストを複合錠は保持する。複合錠の変更権所有者のみが、その複合錠の変更、例えば、メンバの追加、削除等を行い新しいバージョンの複合錠を作成することが許される。この変更権所有者は予め指定される。ある複合錠が変更権所有者によって変更され、新しいバージョンとなったときは、旧バージョンの錠を信用している人は、新バージョンの錠を自動的に信用するように設定できる。これを自動信用機構と呼ぶ。錠の信用については後述する。正当な変更権所有者によって複合錠の変更が行われたことを明確にするために、変更に際しては、変更錠の秘密鍵による署名を行う。ただし、複合錠のメンバ全員がその複合錠の変更権を有する場合には、機密保持用のペアを用いる。この場合には、現バージョンの秘密鍵による署名を行う。
情報の機密性保持等に用いる公開鍵と秘密鍵のペアとは独立に、複合錠の変更権を制御するための公開鍵と秘密鍵とのペアが必要となる。このペアを変更錠と呼ぶ。この変更錠の秘密鍵を、変更権所有者の公開鍵で暗号化し、変更権所有者の名前をラベルとして付与したもののリストを複合錠は保持する。複合錠の変更権所有者のみが、その複合錠の変更、例えば、メンバの追加、削除等を行い新しいバージョンの複合錠を作成することが許される。この変更権所有者は予め指定される。ある複合錠が変更権所有者によって変更され、新しいバージョンとなったときは、旧バージョンの錠を信用している人は、新バージョンの錠を自動的に信用するように設定できる。これを自動信用機構と呼ぶ。錠の信用については後述する。正当な変更権所有者によって複合錠の変更が行われたことを明確にするために、変更に際しては、変更錠の秘密鍵による署名を行う。ただし、複合錠のメンバ全員がその複合錠の変更権を有する場合には、機密保持用のペアを用いる。この場合には、現バージョンの秘密鍵による署名を行う。
f.変更錠の公開鍵
上述の変更錠の秘密鍵とペアを構成するものであり、上記の変更錠の秘密鍵による署名された複合錠の復号等に使用され、署名の確認が可能となる。なお、以上に加えて複合錠の有効期限や公証局と交信できないオフライン期間における有効期間を付加し、複合錠の利用を制御するようにしてもよい。
上述の変更錠の秘密鍵とペアを構成するものであり、上記の変更錠の秘密鍵による署名された複合錠の復号等に使用され、署名の確認が可能となる。なお、以上に加えて複合錠の有効期限や公証局と交信できないオフライン期間における有効期間を付加し、複合錠の利用を制御するようにしてもよい。
(2)グループ錠
グループ錠とは、実世界のグループに対応する複合錠である。グループは一般に複数のメンバを含む。役割錠(例えば人事部長の役割)としても機能する。
グループ錠とは、実世界のグループに対応する複合錠である。グループは一般に複数のメンバを含む。役割錠(例えば人事部長の役割)としても機能する。
(3)個人錠
個人錠は、個人に対応する複合錠である。個人錠も複合錠により実現される。個人錠としての複合錠のメンバは、供託者を指定する。供託者とは、その個人以外の人に対して条件付きでその個人と同一の権利が与えられた人のことである。これは、その個人がパスフレーズを忘れた場合等、その個人の代理者としての役割を果たしうる人を供託者として情報の復号を可能とする。これは、例えば企業内での情報の機密性、および復号可能性を1人の個人に託する危険性を考慮したものである。また、情報の監査や検閲を行うために用いることも可能である。供託者が個人錠を利用することができる条件として複数の指定された供託者の承認を必要とするといった設定も可能である
個人錠は、個人に対応する複合錠である。個人錠も複合錠により実現される。個人錠としての複合錠のメンバは、供託者を指定する。供託者とは、その個人以外の人に対して条件付きでその個人と同一の権利が与えられた人のことである。これは、その個人がパスフレーズを忘れた場合等、その個人の代理者としての役割を果たしうる人を供託者として情報の復号を可能とする。これは、例えば企業内での情報の機密性、および復号可能性を1人の個人に託する危険性を考慮したものである。また、情報の監査や検閲を行うために用いることも可能である。供託者が個人錠を利用することができる条件として複数の指定された供託者の承認を必要とするといった設定も可能である
(4)個人錠の秘密鍵
個人錠の秘密鍵はパスフレーズと呼ばれる利用者のみが知っている文字列をキーとして暗号化された形でのみ存在する。個人錠の秘密鍵が必要になった時点で、パスフレーズが入力され、個人錠の秘密鍵が直接入手できる。
個人錠の秘密鍵はパスフレーズと呼ばれる利用者のみが知っている文字列をキーとして暗号化された形でのみ存在する。個人錠の秘密鍵が必要になった時点で、パスフレーズが入力され、個人錠の秘密鍵が直接入手できる。
(5)複合錠リスト
個人が所有する信用度が明確な複合錠リストである。複合錠とその対応する信用度がペアとして保持される。複合錠を利用するときは、このリスト中の信用度により判断される。ここに存在しない複合錠の信用度は不明であると解釈される。例えば、暗号文の復号を許容する個人またはグループをこの複合錠リストで指定し、対応する複合錠からその公開鍵を取得して暗号化秘密鍵を生成する際に用いられる。すなわち、この複合錠のリストは信用した個人やグループの公開鍵を間接的に登録した公開錠リストであり、個人やグループの公開鍵を直接登録するものであってよい。なお、複合錠そのものは、装置に記憶されたもの以外に、遠隔に位置する装置に記憶されたものを参照するものでもよく、装置内および装置外に記憶された複合錠を混在して用いるものであってもよい。
個人が所有する信用度が明確な複合錠リストである。複合錠とその対応する信用度がペアとして保持される。複合錠を利用するときは、このリスト中の信用度により判断される。ここに存在しない複合錠の信用度は不明であると解釈される。例えば、暗号文の復号を許容する個人またはグループをこの複合錠リストで指定し、対応する複合錠からその公開鍵を取得して暗号化秘密鍵を生成する際に用いられる。すなわち、この複合錠のリストは信用した個人やグループの公開鍵を間接的に登録した公開錠リストであり、個人やグループの公開鍵を直接登録するものであってよい。なお、複合錠そのものは、装置に記憶されたもの以外に、遠隔に位置する装置に記憶されたものを参照するものでもよく、装置内および装置外に記憶された複合錠を混在して用いるものであってもよい。
(6)信用体
本発明におけるグループにおいて使用される複合錠は、誰でも生成できるが、信用されないと有効な錠とは成り得ない。複合錠を信用するとは、実世界の実態として存在するグループ(役割を含む)と、そのグループに対応するであろう複合錠とが実際に対応することを信用するという意味である。具体的には、単にグループと複合錠とが対応するだけではなく、信用する時点での実世界のグループのメンバと複合錠に含まれるメンバとが一致しなければならない。例えば「人事部人事1課」という名称の複合錠があったとする。「人事部人事課」という実世界のグループは存在するが、「人事部人事1課」という実世界のグループは存在しないかもしれない。「人事部人事1課」という実世界のグループが存在したとしても、それに対応する正当な複合錠は存在していないかもしれない。よって複合錠の名称のみを根拠に複合錠を信用することはできない。また、「人事部人事1課」内のメンバが変更されたにもかかわらず複合錠のメンバ中に過去のメンバが残っているような場合には信用することができない。
本発明におけるグループにおいて使用される複合錠は、誰でも生成できるが、信用されないと有効な錠とは成り得ない。複合錠を信用するとは、実世界の実態として存在するグループ(役割を含む)と、そのグループに対応するであろう複合錠とが実際に対応することを信用するという意味である。具体的には、単にグループと複合錠とが対応するだけではなく、信用する時点での実世界のグループのメンバと複合錠に含まれるメンバとが一致しなければならない。例えば「人事部人事1課」という名称の複合錠があったとする。「人事部人事課」という実世界のグループは存在するが、「人事部人事1課」という実世界のグループは存在しないかもしれない。「人事部人事1課」という実世界のグループが存在したとしても、それに対応する正当な複合錠は存在していないかもしれない。よって複合錠の名称のみを根拠に複合錠を信用することはできない。また、「人事部人事1課」内のメンバが変更されたにもかかわらず複合錠のメンバ中に過去のメンバが残っているような場合には信用することができない。
どの複合錠が信用できるかについての情報を信用情報という。また、信用情報自体の信用度を示す情報も信用情報である。信用情報を保持する主体を信用体という。信用情報、および複合錠を何を根拠として信用するのかは信用体の任意である。信用体には、個人と以下の(7)で説明する公証局の2種類が存在する。信用体は他の信用体を信用することができる。このとき信用される信用体を被信用体と呼ぶ。信用体は、複合錠を信用しているときにのみ、この複合錠を利用することになる。信用体がその複合錠に対する直接の信用情報を持たない場合は、信用している信用体がその複合錠を信用している場合には信用する。とすることが可能である。
例えば、個人「田中さん」および公証局「X商事」がいずれも信用体であるとき、個人「田中さん」が公証局「X商事」を信用しているとき、公証局「X商事」が信用しているものは、個人「田中さん」は自動的に信用する。しかし、逆に個人「田中さん」が信用しているものを公証局「X商事」が信用するとは限らない。という関係である。
信用の程度には種類があり、信用レベルと呼ばれる。この信用レベルを使用して信用度の未知の複合錠の信用度を演算によって求めることが可能である。このとき使用される信用レベルは、例えば以下に示す信用レベルである。
レベル◎:完全に信用する(ex.自分自身)。
レベル○:十分に信用する。
レベル△:ある程度信用する。
レベル?:不明。
レベル×:信用しない。
レベル○:十分に信用する。
レベル△:ある程度信用する。
レベル?:不明。
レベル×:信用しない。
信用レベルが未知の複合錠に対する信用レベルを同一の複合錠に対する独立した異なる2つの信用体、例えば2人の個人A、Bの有するその複合錠に対する信用レベルから求める場合の例を図1に示す。図1の第1行は個人A、左端列は個人Bの信用レベルを示すもので、それぞれの場合についての結果が表として示されている。例えば個人Aの設定した信用レベルが○であり、Bが設定した信用レベルが?である複合錠の信用レベルは○となる。
また、信用体に対する信用レベルと、その信用体の他の信用体への信用レベルまたは複合錠への信用レベルを使用した信用レベルの演算には、例えば図2に示すような演算規則が使用される。図2の第1行は信用体に対する信用レベル、左端列はその信用体の他の信用体への信用レベルまたは複合錠への信用レベルを示すもので、それぞれの場合についての結果が表として示されている。例えばその信用体の信用レベルが○であり、その信用体が設定した信用レベルが?である複合錠の信用レベルは?となる。このような図1あるいは図2で示す演算規則を用いて信用度が未知の信用体あるいは複合錠の信用度を決定することが可能である。
(7)公証局
公証局は、上述のように信用体の1つである。公証局の提供する機能は、例えばある暗号システムが使用されている企業や組織といった単位での公の信用を表現、提供することである。公証局における複合錠の信用基準は、当該公証局を運営する企業や組織が任意に決定する。この信用基準の決定方式には、次に述べるようないくつかの方式が考えられる。以下の説明において「保証する」とは、登録されようとする複合錠が正当であることを登録者以外の個人が証明する行為をいう。
公証局は、上述のように信用体の1つである。公証局の提供する機能は、例えばある暗号システムが使用されている企業や組織といった単位での公の信用を表現、提供することである。公証局における複合錠の信用基準は、当該公証局を運営する企業や組織が任意に決定する。この信用基準の決定方式には、次に述べるようないくつかの方式が考えられる。以下の説明において「保証する」とは、登録されようとする複合錠が正当であることを登録者以外の個人が証明する行為をいう。
a)公証局の特定の管理者による何らかの手続により正当であることを確認する。確認がなされた場合に、公証局がその複合錠を信用する。ここで何らかの手続とは、実世界における任意の手続である。例えば申請用紙に拇印がおされていること、あるいは、申請者の身分証明書の確認手続による等である。この他、名前の重複確認、登録者毎に指定されている他の特定の個人による保証、予め決められた人数以上の保証、または、公証局の信用している個人の署名が予め決められた人数以上の場合等に信用して登録するようにしてもよい。
以下、グループ錠を用いた暗号方式の実施例を示す。なお、ここでは、上述の説明における複合錠の中のグループ錠を取り上げて説明するが、複合錠のもう1つの種類である個人錠においても、グループ錠におけるメンバが供託者に変更になる他は、同様の構成、手続で暗号方式が構成される。また、グループ錠の特殊な用途として上述した役割錠があるが、グループ錠を役割錠として機能させるためには、グループ錠の構成メンバ数を1とし、その唯一のメンバとして、現在その役割を果たしている個人とすればよい。ただし、副社長の役割錠のメンバに副社長自身の他にその秘書を含めるといった運用も可能である。
本発明の暗号方式を利用する各人は2つの錠リストを有する。すなわち、a)各人が信用しているグループ錠および個人錠のリストである「公開錠リスト」、および、b)各人が自身の秘密鍵を元に直接もしくは間接に秘密鍵を獲得できるグループ錠のリストである「秘密錠リスト」である。ここでは、簡単のために、「公開錠リスト」に含まれているグループおよび個人錠は信用しているものとし、「やや信用している」といった中程度の信用を与えることはしない。また、信用するか否かは、上述の信用程度の演算規則を用いたものあるいは利用者の判断等に基づくものとし、以下の実施例中での詳細な説明は省略する。ただし、グループ錠を変更した際に、直前のグループ錠を信用している場合における自動信用機構、すなわち変更前のグループ錠を信用している場合は、変更後のグループ錠を自動的に信用するものとする。また、上述の公証局への登録手続についても以下の実施例中では直接触れないが、上述した説明のようにネットワーク中に公証局がある場合には、生成、あるいは変更された錠については、公証局への登録がなされる。ただし、この登録手続は、本発明の必須要件ではない。
まず、この実施例の全体構成を図3により説明する。本実施例の基本的な機能は、個人対個人で、情報を正確に機密性を保持して伝達することである。ただし、個人は、グループに所属していることもある。情報の伝達は、メールのような直接伝送する方法でも、ファイルサービスを介した間接的な方法でも良い。
図3に示すように個人間で伝達するものは、暗号だけでなく、必要に応じて個人公開鍵や、グループ錠も伝達する。個人公開鍵やグループ錠はともに、それが実世界に実在する個人やグループとの正しい対応関係にあるか否かの判断を必要とする場合には、その判断手続を確立することが必要となる。
図3に示す「個人」における平文から暗号への暗号化の際には、復号可能とすべき個人やグループを自身が保持する錠に対応する錠を錠リストから選択して、暗号化する。これにより、選択した個人や、選択したグループに属する個人が復号可能な暗号が生成される。または、共通鍵KAによって平文を暗号化するとともに、この暗号の復号に必要な復号鍵KBを復号可能とすべき個人やグループを自身が保持する錠に対応する錠を錠リストから選択して、暗号化し、これらを送付する。
伝達された暗号化情報を復号する際には、得られた暗号が自身の個人秘密鍵によって直接復号可能であれば、自身の個人秘密鍵を用いて復号する。自身が間接もしくは直接に属するグループによって復号可能であれば、自身の個人秘密鍵を用いてグループ錠をグループ秘密鍵に変換することでグループ秘密鍵を獲得し、それを用いて復号する。グループ秘密鍵は利用後直ちに捨て、単独では保持しない。本方式において、「個人」に秘密遵守を要請されるのは、個人秘密鍵だけである。共通鍵KAによって暗号化が実行された場合には、まず、復号に必要な復号鍵KBを自身の個人秘密鍵を用いて復号する。自身が間接もしくは直接に属するグループによって復号可能であれば、自身の個人秘密鍵を用いてグループ錠をグループ秘密鍵に変換することでグループ秘密鍵を獲得し、それを用いて復号鍵KBを獲得し、この復号鍵KBによって平文を復号する。
[グループ錠]
本実施例におけるグループ錠の構造を図4に示す。図4における各記号の説明を次に示す。
本実施例におけるグループ錠の構造を図4に示す。図4における各記号の説明を次に示す。
LG:このグループ錠のラベル
文字列である。ある個人の錠リストの中では重複を許さない。全体としては重複は生じうるので、識別子として利用することはしない。ただし、ラベルが一致しなければ公開鍵も一致しないため、そのことを利用して処理を高速化することはできる。
文字列である。ある個人の錠リストの中では重複を許さない。全体としては重複は生じうるので、識別子として利用することはしない。ただし、ラベルが一致しなければ公開鍵も一致しないため、そのことを利用して処理を高速化することはできる。
PG:このグループ錠の公開鍵
利用する公開鍵暗号システムに応じた公開鍵であり、一般に512ビットから2048ビット程度の固定長のデータ列である。このグループに直接もしくは間接に属するすべての個人に復号可能な暗号化を行う際には、この公開鍵を用いて暗号化する。また、このグループに直接もしくは間接に属する任意の個人として署名されたものを確認する際には、この公開鍵を用いて署名の確認を行う。公開鍵はグループ錠の中に、そのままの形式で含まれており、誰でもが参照できる。
利用する公開鍵暗号システムに応じた公開鍵であり、一般に512ビットから2048ビット程度の固定長のデータ列である。このグループに直接もしくは間接に属するすべての個人に復号可能な暗号化を行う際には、この公開鍵を用いて暗号化する。また、このグループに直接もしくは間接に属する任意の個人として署名されたものを確認する際には、この公開鍵を用いて署名の確認を行う。公開鍵はグループ錠の中に、そのままの形式で含まれており、誰でもが参照できる。
SG:このグループ錠の秘密鍵
利用する公開鍵暗号システムに応じた秘密鍵であり、一般に512ビットから2048ビット程度の固定長のデータ列である。対応する公開鍵で暗号化された暗号を復号する際に用いる。また、このグループに直接もしくは間接に属する任意の個人として署名する際にも用いる。この秘密鍵は、直接もしくは間接的に個人の秘密鍵により暗号化されており、利用する際には、個人の秘密鍵を用いて逐次復号して獲得し、利用後はすぐに捨て去り、単独で保持することはしない。
利用する公開鍵暗号システムに応じた秘密鍵であり、一般に512ビットから2048ビット程度の固定長のデータ列である。対応する公開鍵で暗号化された暗号を復号する際に用いる。また、このグループに直接もしくは間接に属する任意の個人として署名する際にも用いる。この秘密鍵は、直接もしくは間接的に個人の秘密鍵により暗号化されており、利用する際には、個人の秘密鍵を用いて逐次復号して獲得し、利用後はすぐに捨て去り、単独で保持することはしない。
Mi:このグループのメンバ
概念上の存在であり、データ構造には直接現れない。メンバには個人およびグループがなり得る。なお、前述のようにグループ錠ではなく個人錠の場合には、このメンバは供託者となる。
概念上の存在であり、データ構造には直接現れない。メンバには個人およびグループがなり得る。なお、前述のようにグループ錠ではなく個人錠の場合には、このメンバは供託者となる。
PU:このグループ錠変更用の公開鍵
利用する公開鍵暗号システムに応じた公開鍵であり、一般に512ビットから2048ビット程度の固定長のデータ列である。グループはメンバの追加もしくは削除といった変更を行う必要がある。その変更を行える権利を持つ人を識別する方法として、専用の公開鍵と秘密鍵の対を利用する。これはその公開鍵である。グループ錠には、変更用の秘密鍵が、変更権を所有する個人の個人秘密鍵により直接もしくは間接に暗号化されて含まれている。グループ錠を変更したときには、新しいグループ錠をその変更用秘密鍵により署名する。変更用秘密鍵は変更権の所有者でなければ入手できないため、その署名が確認できれば正当な変更権の所有者による変更であることが確認できる。この確認処理は、以前のグループ錠を信用していれば自動的に行うことができる。この変更用公開鍵は、そのままの形式で含まれているため誰でも参照できる。
利用する公開鍵暗号システムに応じた公開鍵であり、一般に512ビットから2048ビット程度の固定長のデータ列である。グループはメンバの追加もしくは削除といった変更を行う必要がある。その変更を行える権利を持つ人を識別する方法として、専用の公開鍵と秘密鍵の対を利用する。これはその公開鍵である。グループ錠には、変更用の秘密鍵が、変更権を所有する個人の個人秘密鍵により直接もしくは間接に暗号化されて含まれている。グループ錠を変更したときには、新しいグループ錠をその変更用秘密鍵により署名する。変更用秘密鍵は変更権の所有者でなければ入手できないため、その署名が確認できれば正当な変更権の所有者による変更であることが確認できる。この確認処理は、以前のグループ錠を信用していれば自動的に行うことができる。この変更用公開鍵は、そのままの形式で含まれているため誰でも参照できる。
SU:このグループ錠変更用の秘密鍵
利用する公開鍵暗号システムに応じた秘密鍵であり、一般に512ビットから2048ビット程度の固定長のデータ列である。機能は、PUの説明に記載のとおりである。
利用する公開鍵暗号システムに応じた秘密鍵であり、一般に512ビットから2048ビット程度の固定長のデータ列である。機能は、PUの説明に記載のとおりである。
V:このグループ錠のバージョン番号
自然数である。新規にグループ錠を生成したときには、1となる。グループ錠のバージョンを示す。変更するとバージョン番号は基準となったバージョンより1多い数とする。
自然数である。新規にグループ錠を生成したときには、1となる。グループ錠のバージョンを示す。変更するとバージョン番号は基準となったバージョンより1多い数とする。
F:直前のバージョンの扱いを示す値
「不要」、「必要」、「抹消」のいずれかの値を取る。グループ錠の変更を行った際、直前のバージョンを持つ個人は、新しいバージョンを入手することにより直前のバージョンを適切に扱う必要がある。「不要」は、直前のバージョンが不要となることを意味する。「必要」は、直前のバージョンにより作られた暗号を復号するため、直前のバージョンによりなされた署名を確認するために必要である。この場合には、新たに暗号化や署名を行うときには最新のバージョンを使わなければならない。「抹消」は、「必要」に近いが、自身が新しいバージョンの秘密鍵を獲得できない場合には、直前のバージョンを削除しなければならないことを意味する。新規にグループ錠を生成したときには、この値は意味を持たない。
「不要」、「必要」、「抹消」のいずれかの値を取る。グループ錠の変更を行った際、直前のバージョンを持つ個人は、新しいバージョンを入手することにより直前のバージョンを適切に扱う必要がある。「不要」は、直前のバージョンが不要となることを意味する。「必要」は、直前のバージョンにより作られた暗号を復号するため、直前のバージョンによりなされた署名を確認するために必要である。この場合には、新たに暗号化や署名を行うときには最新のバージョンを使わなければならない。「抹消」は、「必要」に近いが、自身が新しいバージョンの秘密鍵を獲得できない場合には、直前のバージョンを削除しなければならないことを意味する。新規にグループ錠を生成したときには、この値は意味を持たない。
Uiこのグループの変更権所有者
概念上の存在であり、データ構造には直接現れない。変更権所有者には、個人およびグループを指定できる。
概念上の存在であり、データ構造には直接現れない。変更権所有者には、個人およびグループを指定できる。
LMi:Miのラベル
文字列である。このグループ錠の直接のメンバである、他のグループ錠もしくは個人公開鍵のラベルである。個人錠については、本実施例においては明記しないが、対応する個人が管理する秘密鍵と、公開する公開鍵とからなり、少なくとも公開鍵にはラベルが付与されているとする。
文字列である。このグループ錠の直接のメンバである、他のグループ錠もしくは個人公開鍵のラベルである。個人錠については、本実施例においては明記しないが、対応する個人が管理する秘密鍵と、公開する公開鍵とからなり、少なくとも公開鍵にはラベルが付与されているとする。
PMi:Miの公開鍵
利用する公開鍵暗号システムに応じた公開鍵であり、一般に512ビットから2048ビット程度の固定長のデータ列である。このグループの直接のメンバの公開鍵である。
利用する公開鍵暗号システムに応じた公開鍵であり、一般に512ビットから2048ビット程度の固定長のデータ列である。このグループの直接のメンバの公開鍵である。
PMi(SG):PMiで暗号化されたSG
利用する公開鍵暗号システムに応じた暗号処理により、SGを暗号化した結果である。これを用いてSGを獲得するためには、PMiに対応する秘密鍵SMiが必要である。これは、対応するLMiをインデックスとした配列により保持する。
利用する公開鍵暗号システムに応じた暗号処理により、SGを暗号化した結果である。これを用いてSGを獲得するためには、PMiに対応する秘密鍵SMiが必要である。これは、対応するLMiをインデックスとした配列により保持する。
LUi:Uiのラベル
文字列である。このグループ錠の変更権所有者である個人の個人錠のラベルである。
文字列である。このグループ錠の変更権所有者である個人の個人錠のラベルである。
PUi:Uiの公開鍵
利用する公開鍵暗号システムに応じた公開鍵であり、一般に512ビットから2048ビット程度の固定長のデータ列である。このグループ錠の変更権所有者である個人の公開鍵もしくはグループ錠の公開鍵である。
利用する公開鍵暗号システムに応じた公開鍵であり、一般に512ビットから2048ビット程度の固定長のデータ列である。このグループ錠の変更権所有者である個人の公開鍵もしくはグループ錠の公開鍵である。
PUi(SUi):Uiの公開鍵で暗号化されたSU
利用する公開鍵暗号システムに応じた暗号処理により、SGを暗号化した結果である。これを用いてSGを獲得するためには、PUiに対応する秘密鍵SUiが必要である。これは、対応するLUiをインデックスとした配列により保持する。なお、本実施例では、パケット通信におけるパケットのデータ構造のように、秘密鍵に対してデータを識別するための情報を付加した上で暗号化を行う。従って、この暗号化秘密鍵を復号した際に付加的情報に基づいて秘密鍵が正常に復号されたか否かを容易に判別することができる。
利用する公開鍵暗号システムに応じた暗号処理により、SGを暗号化した結果である。これを用いてSGを獲得するためには、PUiに対応する秘密鍵SUiが必要である。これは、対応するLUiをインデックスとした配列により保持する。なお、本実施例では、パケット通信におけるパケットのデータ構造のように、秘密鍵に対してデータを識別するための情報を付加した上で暗号化を行う。従って、この暗号化秘密鍵を復号した際に付加的情報に基づいて秘密鍵が正常に復号されたか否かを容易に判別することができる。
Sig(SU):全体に対するSUによる署名
署名を示すデータ列である。ここで全体とは、LG、PG、V、F、PU、LMi、PMi(SG)、LUi、PUi(SU)である。署名とは、秘密鍵SUによる暗号化処理である。公開鍵暗号システムでは、通常と逆に、秘密鍵により暗号化し、それを公開鍵で復号することができる。公開鍵で復号できるには、秘密鍵により暗号化しなければならないため、公開鍵で復号できることを確認することにより、秘密鍵により署名されたことを確認できる。実際には、メッセージダイジェストをその対象範囲に対して行い、その処理結果に対して、秘密鍵SUにより署名する。メッセージダイジェストとは、署名の対象範囲を全て暗号化するにはコストがかかるために、対象範囲のデータサイズには独立に、対象範囲の内容に応じて128ビット程度の情報を生成する処理である。メッセージダイジェスト処理アルゴリズムは公開されたものを用い、鍵も利用しない。よって確認の際には、対象データをメッセージダイジェストし、署名を復号した結果と一致するか否かを確認することになる。メッセージダイジェストの処理は、チェックサムに類似した処理であるが、処理過程において一方方向関数を用いることにより、同じ結果を生成する入力データを偽造することを困難にしている。また、生成されるデータサイズが大きいため、総当たり的な入力データの偽造も困難である。「メッセージダイジェスト」という名称は、暗号関連においては一般的な名称であり、良く知られた方式である。Sig(SU)はメッセージダイジェスト処理関数をfmdとし、対象とするデータの複合操作を算術和で表現するとし、SUを用いた署名を関数SUで表現すると、次の処理を施した結果となる。
署名を示すデータ列である。ここで全体とは、LG、PG、V、F、PU、LMi、PMi(SG)、LUi、PUi(SU)である。署名とは、秘密鍵SUによる暗号化処理である。公開鍵暗号システムでは、通常と逆に、秘密鍵により暗号化し、それを公開鍵で復号することができる。公開鍵で復号できるには、秘密鍵により暗号化しなければならないため、公開鍵で復号できることを確認することにより、秘密鍵により署名されたことを確認できる。実際には、メッセージダイジェストをその対象範囲に対して行い、その処理結果に対して、秘密鍵SUにより署名する。メッセージダイジェストとは、署名の対象範囲を全て暗号化するにはコストがかかるために、対象範囲のデータサイズには独立に、対象範囲の内容に応じて128ビット程度の情報を生成する処理である。メッセージダイジェスト処理アルゴリズムは公開されたものを用い、鍵も利用しない。よって確認の際には、対象データをメッセージダイジェストし、署名を復号した結果と一致するか否かを確認することになる。メッセージダイジェストの処理は、チェックサムに類似した処理であるが、処理過程において一方方向関数を用いることにより、同じ結果を生成する入力データを偽造することを困難にしている。また、生成されるデータサイズが大きいため、総当たり的な入力データの偽造も困難である。「メッセージダイジェスト」という名称は、暗号関連においては一般的な名称であり、良く知られた方式である。Sig(SU)はメッセージダイジェスト処理関数をfmdとし、対象とするデータの複合操作を算術和で表現するとし、SUを用いた署名を関数SUで表現すると、次の処理を施した結果となる。
SU':前バージョンのSU
利用する公開鍵暗号システムに応じた秘密鍵であり、一般に512ビットから2048ビット程度の固定長のデータ列である。直前のバージョンの変更用秘密鍵である。機能は、SUと同様である(詳細は、PUの説明参照)。
利用する公開鍵暗号システムに応じた秘密鍵であり、一般に512ビットから2048ビット程度の固定長のデータ列である。直前のバージョンの変更用秘密鍵である。機能は、SUと同様である(詳細は、PUの説明参照)。
Sig(SU'):全体に対するSU'による署名
署名を示すデータ列である。ここで全体とは、LG、PG、V、F、PU、LMi、PMi(SG)、LUi、PUi(SU)、Sig(SU)である。これは、新規に作成された場合には、付与されない。Sig(SU)と同様に表記すると、次のように表せる。
署名を示すデータ列である。ここで全体とは、LG、PG、V、F、PU、LMi、PMi(SG)、LUi、PUi(SU)、Sig(SU)である。これは、新規に作成された場合には、付与されない。Sig(SU)と同様に表記すると、次のように表せる。
なお、本実施例ではデータ全体に対して署名を行うようにしたが、改竄を防ぎたい一部データに対して署名を行うようにしてもよい。
[公開錠リスト]
図5に本実施例における公開錠リストの構造を示す。公開錠リストとは各個人が独立に所有するもので、その個人が信用しているグループ錠および個人錠を、その錠のラベルをインデックスとした配列で保持するものである。
図5に本実施例における公開錠リストの構造を示す。公開錠リストとは各個人が独立に所有するもので、その個人が信用しているグループ錠および個人錠を、その錠のラベルをインデックスとした配列で保持するものである。
図5に示すように、公開錠リストは、Gi:信用しているグループ錠、LGi:グループ錠Giのラベル、Ii:信用している個人の公開鍵、LIi:個人の公開鍵Iiに対応するラベルから構成される。
公開錠リストへの新たなデータの追加の際に必要な錠の信用は、本実施例においては公開錠リストの所有者の判断に任されるものとする。ただし、既に信用しているグループ錠の次バージョンの自動信用は行うこととする。前述の信用レベルに関する演算規則を用いて信用できる錠あるいは信用体を決定することも可能である。この場合前述の公証局に登録された信用関係を利用することにより確実かつ容易に信用レベルを求めることが可能となる。
暗号化の際に、復号可能なグループおよび個人を指定するが、それは対応するグループ錠もしくは個人錠を1個以上、この公開錠リストから選択することにより指定する。
署名の正当性を確認する際には、署名時に用いられた秘密鍵に対応する公開鍵をこの公開錠リストから取り出して利用する。
[秘密錠リスト]
図6に本実施例における秘密錠リストの構造を示す。秘密錠リストとは各個人が独立に所有するもので、その個人が秘密鍵を獲得できるグループ錠を、そのグループ錠のラベルをインデックスとした配列で保持するものである。秘密鍵の獲得は、その個人の個人秘密鍵を、グループ錠に直接もしくは間接に適用することにより行われる。
図6に本実施例における秘密錠リストの構造を示す。秘密錠リストとは各個人が独立に所有するもので、その個人が秘密鍵を獲得できるグループ錠を、そのグループ錠のラベルをインデックスとした配列で保持するものである。秘密鍵の獲得は、その個人の個人秘密鍵を、グループ錠に直接もしくは間接に適用することにより行われる。
図6に示すように、秘密錠リストは、Gi:秘密鍵が利用可能なグループ錠、、LGi:グループ錠Giのラベルから構成される。
秘密錠リストへの追加は、公開錠リストへのグループ錠の追加処理の中で、自身の個人秘密鍵を直接もしくは間接に適用することによりそのグループ錠内部のグループ秘密鍵を獲得可能であるならば追加することにより行う。よって利用者は追加処理を意識する必要はない。自身の個人秘密鍵により、そのグループ錠内部のグループ秘密鍵が獲得できるからといって、そのグループ錠を信用する根拠にはならないことには注意が必要である。
復号の際に、復号可能性の判断を秘密錠リストを用いることにより高速化する。また、実際の復号処理においても、必要なグループ秘密鍵の獲得処理にこの秘密錠リストを利用する。
署名の際には、自身の個人秘密鍵を用いる以外にも、この秘密錠リスト中のグループ秘密鍵を用いて署名することができる。このようにすれば、暗号文の受け手側で送り手の個人やグループを識別することができる。また、署名とともに署名に用いた秘密錠の公開鍵を添付すると署名の確認が容易になるとともに、署名を確認することなく公開鍵のみで送り手を容易に確認することができる。
[暗号]
本実施例における暗号の構造を図7に示す。本実施例においては、グループ錠のLMiとPMi(SG)のペアのリストと同様の構造を持たせることにより、複数の秘密鍵のいずれかを用いることにより復号可能としている。これにより、複数人に開示したい情報を暗号化する際に、必ずしもグループ錠を作成する必要をなくしている。すなわち、公開錠リストから任意に選択した個人やグループで構成される受け手のグループを一時的に作成することができる。
本実施例における暗号の構造を図7に示す。本実施例においては、グループ錠のLMiとPMi(SG)のペアのリストと同様の構造を持たせることにより、複数の秘密鍵のいずれかを用いることにより復号可能としている。これにより、複数人に開示したい情報を暗号化する際に、必ずしもグループ錠を作成する必要をなくしている。すなわち、公開錠リストから任意に選択した個人やグループで構成される受け手のグループを一時的に作成することができる。
図7中の各記号の意味を以下に説明する。
Pi:復号できるグループ錠もしくは個人の公開鍵
利用する公開鍵暗号システムに応じた公開鍵であり、一般に512ビットから2048ビット程度の固定長のデータ列である。
Pi:復号できるグループ錠もしくは個人の公開鍵
利用する公開鍵暗号システムに応じた公開鍵であり、一般に512ビットから2048ビット程度の固定長のデータ列である。
Li:Piのラベル
文字列である。
文字列である。
D:平文(機密を保持すべき情報)
任意のデータ列である。
任意のデータ列である。
K:平文Dを暗号化した共通鍵
公開鍵暗号は、暗号化処理および復号処理が遅いため、共通鍵暗号で平文を暗号化し、その共通鍵のみを公開鍵暗号により暗号化するハイブリッド方式を採用することが一般的である。このKは、その共通鍵である。本実施例においては、KをPiでそれぞれ暗号化することにより、複数のグループもしくは個人による復号を可能とする。
公開鍵暗号は、暗号化処理および復号処理が遅いため、共通鍵暗号で平文を暗号化し、その共通鍵のみを公開鍵暗号により暗号化するハイブリッド方式を採用することが一般的である。このKは、その共通鍵である。本実施例においては、KをPiでそれぞれ暗号化することにより、複数のグループもしくは個人による復号を可能とする。
Pi(K):Piで暗号化したK
K(D):で暗号化したD
K(D):で暗号化したD
S:暗号化処理を行った人が利用可能な秘密鍵
暗号に署名を付与する際に用いる、秘密鍵である。自身の個人秘密鍵か、秘密錠リストに含まれているグループ錠の秘密鍵のうちの1つを用いる。
暗号に署名を付与する際に用いる、秘密鍵である。自身の個人秘密鍵か、秘密錠リストに含まれているグループ錠の秘密鍵のうちの1つを用いる。
P:署名に用いた秘密鍵Sと対になる公開鍵P
署名の確認の際には、署名者が署名に用いたと主張する秘密鍵に対応する公開鍵を利用する。その公開鍵を特定するために保持する。暗号文の受け手側においてその公開鍵が自身の公開錠リストに含まれていれば、自身が信用しているグループもしくは個人により署名されていることを確認することができ、暗号文の発信者または発信したグループを確認することができる。
署名の確認の際には、署名者が署名に用いたと主張する秘密鍵に対応する公開鍵を利用する。その公開鍵を特定するために保持する。暗号文の受け手側においてその公開鍵が自身の公開錠リストに含まれていれば、自身が信用しているグループもしくは個人により署名されていることを確認することができ、暗号文の発信者または発信したグループを確認することができる。
Sig(S):全体に対するSによる署名
署名を示すデータ列である。ここで全体とは、Li、Pi(K)、K(D)である。署名に関しては、グループ錠の構造のSig(SU)の項を参照。同様の表記に従えば、Sig(S)は次のように表せるものである。
署名を示すデータ列である。ここで全体とは、Li、Pi(K)、K(D)である。署名に関しては、グループ錠の構造のSig(SU)の項を参照。同様の表記に従えば、Sig(S)は次のように表せるものである。
[処理の流れ]
本実施例の具体的な処理の流れを以下、図8から図16に示されるフローチャートによって説明する。
本実施例の具体的な処理の流れを以下、図8から図16に示されるフローチャートによって説明する。
[グループ錠生成]
グループ錠生成についてのフローを図8に示す。グループを作成するとき(追加変更するときも同様)には、新しく指定するメンバに対応するグループ錠もしくは個人の公開鍵は作成者が信用している必要がある。そのため、新しく指定するメンバのグループ錠もしくは個人の公開鍵を信用していないときには、グループ錠の作成に先立って、信用すること、すなわち錠リストへの追加を行わなければならない。
グループ錠生成についてのフローを図8に示す。グループを作成するとき(追加変更するときも同様)には、新しく指定するメンバに対応するグループ錠もしくは個人の公開鍵は作成者が信用している必要がある。そのため、新しく指定するメンバのグループ錠もしくは個人の公開鍵を信用していないときには、グループ錠の作成に先立って、信用すること、すなわち錠リストへの追加を行わなければならない。
作成したグループ錠は、まず自身の錠リストに追加される。錠リストとは、公開錠リストと秘密錠リストの総称である。さらに必要な者(作成したグループ向けに暗号化された暗号を復号する際に、グループのメンバはこのグループ錠が必要である。逆にこのグループ向けに暗号化する際にもグループ錠が必要となる。暗号化は任意の人が行える。そのためメンバおよびこのグループ向けの暗号化を行う可能性のある人への配布が必要となる)へ配布する。離れたセンタで保管し、暗号文の送り手や受け手の必要に応じて複合錠を送ったり、複合錠の必要な情報のみを送るようにしてもよい。本実施例においては、配布機構の説明は省略する。
図8のフローについて詳細に説明する。まずステップ101において生成するグループ錠のラベルを入力する。ステップ102では、入力されたラベルと同じラベルの錠がすでに錠リスト中にあるかが検討される。重複するラベルの錠の作成は拒否されることになり、すでに錠リスト中に同じラベルのものがある場合はステップ113に進みグループ錠の作成が中止される。同じラベルのものが無い場合は、ステップ103に進む。
ステップ103およびステップ104では、メンバMiと変更権所有者Uiが指定される。メンバは、このグループ錠を使用した暗号システムを利用するメンバであり、変更権所有者は、このグループ錠の変更、例えばメンバの追加、削除等を行う権利を有する者である。メンバ、および変更権所有者は、いずれも個人に限らずグループでの登録が可能であり、グループ錠生成者が有する公開錠リストの中から1つ以上のグループ錠もしくは個人の公開鍵を選択して指定される。
ステップ105では、生成されるグループ錠の秘密鍵SGと公開鍵PGを生成する。ステップ106では、生成された秘密鍵SGをメンバMiのそれぞれの公開鍵PMiで暗号化したPMi(SG)を生成し、それぞれにラベルLMiを対応させる。
ステップ107では、生成するグループ錠の変更用秘密鍵SUと変更用公開鍵PUが生成される。ステップ108では、生成されたグループ錠変更用秘密鍵SUを変更権所有者の公開鍵PUiによって暗号化し、PUi(SG)を生成し、それぞれにラベルLUiを対応させる。
ステップ109では、生成されるグループ錠のバージョン番号を設定する。ステップ110では、それぞれのステップで生成された、LG,PG,SG,SU,PU,V,PMi(SG),PUi(SU)の各データを一体とする。ステップ111では、一体となった前データに対する変更用秘密鍵SUによる署名、すなわちデータ変換が実行される。ステップ112でグループ錠生成者の錠リストにグループ錠を登録追加することでグループ錠の生成が終了する。生成されたグループ錠は先に説明した図4に示す構成を有する。
[錠リストへの追加]
図9に錠リストへの追加手続のフローを示す。錠リストへの追加は、信用できるグループ錠もしくは個人の公開鍵だけについて行われる。この処理は、自身が生成および変更(新しいバージョンの作成)したグループ錠の追加、他者から得たグループ錠の追加のいずれにおいても用いられる。
図9に錠リストへの追加手続のフローを示す。錠リストへの追加は、信用できるグループ錠もしくは個人の公開鍵だけについて行われる。この処理は、自身が生成および変更(新しいバージョンの作成)したグループ錠の追加、他者から得たグループ錠の追加のいずれにおいても用いられる。
本実施例では、公証局を用いて鍵を配布したり、電子メールやフロッピを介して鍵を配布したりという配布に関する処理は含めていない。また、鍵に対する署名を利用し、その署名者に対する信頼度、署名者の鍵に対する信用度の演算を行い、鍵の信用度を算出するような処理は省略してある。前述した信用度の演算による信用度レベルの獲得をこのフロー中に含め、信用度の判断に用いることは可能である。本実施例においては、既に信用しているグループ錠の新しいバージョンの自動的な信用手続きについては示してある。ここでは、新しいバージョンが、直前のバージョンの変更用秘密鍵によって署名されていることが確認できた場合にのみ自動的に信用している。
秘密錠リストへの追加は、信用できたグループ錠の中から、自身の個人秘密鍵を用いることにより直接もしくは間接に、そのグループ錠の秘密鍵を獲得できるものだけを追加する。
図9に示すフローを詳細に説明する。ステップ201で追加する錠の指定が行われると、ステップ202,203,204において、直前のバージョンの錠の変更用秘密鍵SU'による署名の有無、信用の有無、署名の正確性について判断され、いずれかが「いいえ」の場合に、ステップ214に進み、追加する錠を信用するか否かを、信用錠の所有者自身が判断して入力する。信用する場合は、ステップ210に進み、信用しない場合は、錠リストへの追加は実行しない。ステップ214および215において前述の信用度を獲得するための演算を用いることができる。
ステップ205〜209は、以前のバージョンの扱いを決定するステップである。新しいバージョンのグループ鍵を追加するときには、以前のバージョンのグループ錠を適切に扱う必要がある。これは新しいバージョンのグループ鍵に含まれているFの値により判断する。Fの値にかかわらず、以前のバージョンは古いため、新たに暗号化したり、署名したりすることは行ってはならない。そのため、公開錠リストや、秘密錠リストは、最新のものと、それ以外に分けておくべきである。本実施例においては、その分類は省略し、利用する際に最新という指定をするにとどめている。Fの値に応じた対応は次の通りである。
a)F=「必要」の場合には、古いバージョンのグループ錠は残される。
b)F=「不要」の場合には、古いバージョンのグループ錠は削除される。
c)F=「抹消」の場合には、自身が新しいバージョンの秘密鍵を獲得できれば、残される。そうでなければ削除される。
b)F=「不要」の場合には、古いバージョンのグループ錠は削除される。
c)F=「抹消」の場合には、自身が新しいバージョンの秘密鍵を獲得できれば、残される。そうでなければ削除される。
ステップ210〜213は、公開錠リストへの追加を行い、追加される錠の秘密鍵の利用可能性を判断し、利用可能な場合には、秘密錠リストへの追加も併せて行うことを示すステップである。
[秘密錠の利用可能性判断]
図10に秘密鍵の利用可能性を判断するフローを示す。これは指定された任意のグループ錠の中に暗号化されて含まれている秘密鍵を、自身の個人秘密鍵を直接もしくは間接に適用することにより獲得することができるかどうかの判断を行う処理である。
図10に秘密鍵の利用可能性を判断するフローを示す。これは指定された任意のグループ錠の中に暗号化されて含まれている秘密鍵を、自身の個人秘密鍵を直接もしくは間接に適用することにより獲得することができるかどうかの判断を行う処理である。
この処理は、あるグループ錠を、秘密錠リストに含めて良いか否かの判断(図9のステップ212およびステップ213)に用いる。他にも、復号の際にグループ鍵を利用可能か否かを判断するためなどにおいて、この処理と同じ判断が必要である。しかし、秘密錠リストに含まれているグループ錠が、その時点において知っている限りにおいて、自身が秘密鍵を獲得できる全てのグループ錠であることを利用して、秘密錠リストに含まれているか否かという簡便な処理で済むことが多く、この処理を直接利用しなければならないことは多くない。
処理の内容は、まず自身の個人秘密鍵を直接用いて与えられたグループ錠の秘密鍵を獲得できるか否かを判断する。それで獲得できない場合には、自身の秘密錠リスト中の各グループ鍵を直接用いて与えられたグループ錠の秘密鍵を獲得できるか否かを判断する。秘密錠リスト中のグループ錠の秘密鍵を利用可能であることが判明しているので、判断するだけであれば、この手順で処理すれば良い。
図10のフローを詳細に説明する。ステップ301では、判断の対象とするグループ錠を指定し、ステップ302で、自身の個人錠が判断対象であるグループ錠のメンバであるかが検討され、メンバであれば利用可能であるとされる。メンバでない場合は、ステップ303からステップ305において、現在の秘密錠リストの要素Giについて検討されGiが判断対象の鍵のメンバであるかが検討される。ステップ303,304,305は、Giのiを順次インクリメントして繰り返し実行することを意味する。この繰り返しステップ中、いずれかのGiが判断対象の鍵のメンバである場合には、利用可能と判断される。
[暗号化]
図11に情報の暗号化処理フローを示す。ここで入力するべきものは次の3つである。
a)平文
b)復号可能者
公開錠リストに含まれる最新のグループ錠もしくは個人の公開鍵を合わせて一つ以上指定する。
c)署名者
自身の個人秘密鍵か、秘密錠リストに含まれる最新のグループ錠を一つだけ指定する。署名しなければ指定する必要はない。
図11に情報の暗号化処理フローを示す。ここで入力するべきものは次の3つである。
a)平文
b)復号可能者
公開錠リストに含まれる最新のグループ錠もしくは個人の公開鍵を合わせて一つ以上指定する。
c)署名者
自身の個人秘密鍵か、秘密錠リストに含まれる最新のグループ錠を一つだけ指定する。署名しなければ指定する必要はない。
署名とは、署名対象であるデータをメッセージダイジェストし、その結果である署名ブロックを秘密鍵によって署名することである。秘密鍵による署名とは、秘密鍵による暗号化である。詳細については、データ構造「暗号」と、データ構造「グループ錠」のSig(SU)の項参照。
図11のフローについて詳細に説明する。ステップ401では、機密を保持する情報Dを入力し、ステップ402で、復号を可能とする最新のグループおよび個人に対応する公開鍵Piを、自身の公開錠リストから1つ以上選択する。これは、暗号化されたデータの復号を可能とするメンバを選択するものである。
ステップ403では、共通鍵Kを生成し、Kを鍵とする共通鍵暗号方式による情報Dの暗号化を実行する。これは前述の[暗号]の欄で述べたように、公開鍵暗号は、暗号化処理および復号処理が遅いため、共通鍵暗号で平文を暗号化し、その共通鍵のみを公開鍵暗号により暗号化するハイブリッド方式を採用していることによるものである。なお、この共通鍵Kは暗号化を行う毎に生成するものでなくてもよく、必要に応じて生成するものであったり、あるいは予め決められた固定的なものであってもよい。
ステップ404ではKを各復号可能者の公開鍵Piで暗号化しPi(K)を生成し、それぞれに対応するラベルを付与する。ステップ405でその生成された暗号に対する署名を行うか判断し、行わない場合は、ステップ410で各データのまとめを実行し、暗号化処理を終了する。署名を実行する場合は、ステップ406に進む。
ステップ406〜409は署名の処理ステップであり、署名を行うデータのメッセージダイジェスト処理(ステップ406)を行い、署名用の鍵を秘密錠リストから選択(ステップ407)し、選択した秘密鍵による署名を実行(ステップ408)し、配列K(D)と署名済みメッセージダイジェスト(=署名ブロック)をまとめる(ステップ409)処理である。以上のステップにより暗号化処理が終了する。
[復号可能性判断]
図12に任意の暗号を自身が復号可能であるか否かを判断する処理フローを示す。このフローは、例えば、暗号ファイルのリストをしたとき、自身が復号可能なものがどれであるのかを確認したいとき等に使用される。このフローは復号可能性の判断を高速に実行する処理である。具体的には、ラベルが一致しなければ復号できないことを利用し、まずラベルの一致を確認し、ラベルが一致した場合に限り復号を試みる。一般にラベルの選定方法を適切に決めれば、この方法で十分な性能が得られる。もしラベルの選定方法を規定できないならば、「暗号」にラベルだけでなく、暗号化に利用した公開錠を付与することにより、高速化する方法もある。
図12に任意の暗号を自身が復号可能であるか否かを判断する処理フローを示す。このフローは、例えば、暗号ファイルのリストをしたとき、自身が復号可能なものがどれであるのかを確認したいとき等に使用される。このフローは復号可能性の判断を高速に実行する処理である。具体的には、ラベルが一致しなければ復号できないことを利用し、まずラベルの一致を確認し、ラベルが一致した場合に限り復号を試みる。一般にラベルの選定方法を適切に決めれば、この方法で十分な性能が得られる。もしラベルの選定方法を規定できないならば、「暗号」にラベルだけでなく、暗号化に利用した公開錠を付与することにより、高速化する方法もある。
処理は、まず自身の個人秘密鍵の適用を試み、復号できなければ自身の秘密錠リスト中の各グループ錠の適用を試みる。ここにおける復号は、「暗号」中のラベルLiに対応するPi(K)のみの復号である。ここでは、平文を得ることは目的ではないので、K(D)の復号は行わない。
図12の復号可能性判断フローについて詳細に説明する。ステップ501で復号可能性を判断する暗号を指定する。ステップ502、503で暗号中のラベルLiと自身の個人錠のラベルとの一致があるかが判断される。一致がある場合は、ステップ509へ進み、復号を試みる。ここで復号できない場合、およびステップ502、503において一致するラベルがなかった場合は、ステップ504、505において所有する秘密錠ラベルとの一致が判断される。一致するラベルLGiがあったときは、ステップ511に進み、ラベルLGiに対応するGiの秘密鍵SGiを獲得し、ステップ512,513で復号を試みる。復号が成功しない場合は、ステップ506,507に進み、他の所有秘密錠リストのラベルとの一致および個人錠のラベルとの一致について調べることとなる。なお、ステップ506はステップ504と同一の処理を異なるラベルについて繰り返すことを示し、ステップ507はステップ502について異なるラベルについて繰り返すことを示している。ステップ510あるいは、ステップ513において復号できたときは、ステップ514で復号できるとの判断がなされる。
[グループ錠中の秘密鍵の獲得]
図13に秘密錠リスト中に存在するグループ錠の秘密鍵SGを獲得するフローを示す。グループ錠の秘密鍵は暗号情報の復号や署名の際などに用いる。
図13に秘密錠リスト中に存在するグループ錠の秘密鍵SGを獲得するフローを示す。グループ錠の秘密鍵は暗号情報の復号や署名の際などに用いる。
秘密錠リストには、個人の秘密鍵を直接もしくは間接に適用することにより、その秘密鍵を獲得できるグループ錠のみが含まれているので、獲得できることは明らかである。
処理は、まず自身の個人秘密鍵を直接適用することを試みる。それが失敗した場合には、秘密錠リスト中のグループ錠を適用することを試みる。グループ錠の適用の試みにおいては、この処理を再帰的に呼び出す。グループをノードとし、メンバというグループ間の包含関係を有向アークとして形成される有向グラフは、ループを持たない。よって、この処理で秘密鍵を獲得することができる。
図13の秘密鍵SGiの獲得フローについて詳細に説明する。まずステップ601で秘密錠リスト中のグループ錠Giを指定する。ステップ602で自身の個人錠がグループ錠Giのメンバに含まれるかが検討され、含まれる場合は、ステップ607に進み、グループ錠Gi中にある個人公開鍵でグループ秘密鍵を暗号化したPMj(SG)を抽出し、これを個人秘密鍵で復号し、グループ秘密鍵SGを獲得する。
ステップ602において、自身の個人錠がグループ錠Giのメンバに含まれない場合は、ステップ603〜605において、秘密錠リストのすべての要素Gkにたいして、GkがGiのメンバであるかが検討される。これは、自身の保有する「秘密錠が利用可能なグループ錠Gk」各々について、グループ錠Giのメンバとして含まれているかを検討するステップである。ステップ604でグループ錠GiのメンバであるGkが検出されたときは、ステップ608でGkの秘密鍵SGkを獲得し、ステップ609でグループ錠Gi中にある暗号化したPMj(SG)を抽出し、これを秘密鍵SGkで復号し、グループ秘密鍵SGを獲得する。
[復号]
図14に任意の暗号を復号する際のフローを示す。図14に示すフローは、前述した「復号可能性判断」処理とほぼ等しいフローである。ステップ701〜713は、図12の復号可能性判断フロー中のステップ501〜513に対応する。ただし、ステップ714において、共通鍵暗号の鍵Kを用いて、K(D)を復号し、平文Dを獲得する。暗号が署名がされている場合、必要ならば、平文Dを獲得するとともに、署名の確認を行う。
図14に任意の暗号を復号する際のフローを示す。図14に示すフローは、前述した「復号可能性判断」処理とほぼ等しいフローである。ステップ701〜713は、図12の復号可能性判断フロー中のステップ501〜513に対応する。ただし、ステップ714において、共通鍵暗号の鍵Kを用いて、K(D)を復号し、平文Dを獲得する。暗号が署名がされている場合、必要ならば、平文Dを獲得するとともに、署名の確認を行う。
[署名確認]
図15に署名確認のフローを示す。署名対象にメッセージダイジェスト処理を施した結果と、署名ブロック(署名処理により付与されたデータ)を署名の際に用いられたとされる秘密鍵に対応する公開鍵で復号した結果と比較する。その2つの結果が等しければ署名が正しくなされ、署名対象が改竄されていないことが確認できる。
図15に署名確認のフローを示す。署名対象にメッセージダイジェスト処理を施した結果と、署名ブロック(署名処理により付与されたデータ)を署名の際に用いられたとされる秘密鍵に対応する公開鍵で復号した結果と比較する。その2つの結果が等しければ署名が正しくなされ、署名対象が改竄されていないことが確認できる。
ただし、署名に用いられた秘密鍵に対応する公開鍵を信用していなければならない。自身の公開錠リストに含まれていれば良い。信用していなければ、署名の確認はできない。
メッセージダイジェストの結果と、復号した結果が等しくないときには、署名対象が改竄されていることが分かる。
図15に示す署名確認フローについて説明する。まずステップ801で、署名対象をメッセージダイジェストする。メッセージダイジェストとは前述のように、署名の対象範囲を全て暗号化するにはコストがかかるために、対象範囲のデータサイズと独立に、対象範囲の内容に応じて128ビット程度の情報を生成する処理である。次にステップ802において、署名に使用する秘密鍵に対応する公開鍵の信用について判断する。公開鍵を信用していない場合は、ステップ806で署名確認は不可能と判断される。
ステップ802において、公開鍵の信用性が確認されれば、ステップ803に進み、署名ブロックを署名の際に用いられたとされる秘密鍵に対応する公開鍵で復号し、ステップ804とでメッセージダイジェストとの同一性判断がなされる。これが実際上の署名確認ステップとなる。このステップ804において同一性がないと判断されればステップ807において署名は正しいものではない。すなわち、署名を行った秘密鍵は正しいものではないと判断される。ステップ804においてメッセージダイジェストと復号結果が等しいと判断されれば、ステップ805においてその署名は正当に行われたと結論づけられる。
[グループ錠変更]
図16にグループ錠の変更フローについて示す。グループ錠の変更には、次の4種類がある。フローチャートにおいて、4本の処理に分岐している部分の左側からの順序で示す。
図16にグループ錠の変更フローについて示す。グループ錠の変更には、次の4種類がある。フローチャートにおいて、4本の処理に分岐している部分の左側からの順序で示す。
A.今から追加
新たにメンバを追加する。追加された新たなメンバは、追加以前に暗号化された暗号を復号することはできない。この場合には、新しい秘密鍵と公開鍵の対を新しいバージョンのグループ錠のSGとPGとする。また、Fの値は「必要」となる。よって、新しいバージョンを受け取った個人は、以前のバージョンを削除しない。これは、追加以前に暗号化された暗号を、以前からのメンバが復号するために必要であるためである。
新たにメンバを追加する。追加された新たなメンバは、追加以前に暗号化された暗号を復号することはできない。この場合には、新しい秘密鍵と公開鍵の対を新しいバージョンのグループ錠のSGとPGとする。また、Fの値は「必要」となる。よって、新しいバージョンを受け取った個人は、以前のバージョンを削除しない。これは、追加以前に暗号化された暗号を、以前からのメンバが復号するために必要であるためである。
B.遡って追加
新たにメンバを追加する。追加された新たなメンバは、追加以前に暗号化された暗号も復号することができる。この場合には、以前のSGとPGをそのまま利用する。そのため、Fの値は「不要」となる。よって、新しいバージョンを受け取った個人は、以前のバージョンを削除する。以前に暗号化された暗号を復号する場合にも新しいバージョンを用いれば良い。
新たにメンバを追加する。追加された新たなメンバは、追加以前に暗号化された暗号も復号することができる。この場合には、以前のSGとPGをそのまま利用する。そのため、Fの値は「不要」となる。よって、新しいバージョンを受け取った個人は、以前のバージョンを削除する。以前に暗号化された暗号を復号する場合にも新しいバージョンを用いれば良い。
C.今から削除
既存のメンバを削除する。削除されたメンバは、削除以前に暗号化された暗号を復号することができる。当然、削除以降に暗号化されたものは復号できない。この場合には、新しい秘密鍵と公開鍵の対を新しいバージョンのグループ錠のSGとPGとする。また、Fの値は「必要」となる。よって、新しいバージョンを受け取った個人は、以前のバージョンを削除しない。これは、削除以前に暗号化された暗号を、削除されたメンバも含めた以前のメンバが復号するために必要であるためである。
既存のメンバを削除する。削除されたメンバは、削除以前に暗号化された暗号を復号することができる。当然、削除以降に暗号化されたものは復号できない。この場合には、新しい秘密鍵と公開鍵の対を新しいバージョンのグループ錠のSGとPGとする。また、Fの値は「必要」となる。よって、新しいバージョンを受け取った個人は、以前のバージョンを削除しない。これは、削除以前に暗号化された暗号を、削除されたメンバも含めた以前のメンバが復号するために必要であるためである。
D.遡って削除
既存のメンバを削除する。削除されたメンバは、削除以前に暗号化された暗号も復号することができない。この場合には、新しい秘密鍵と公開鍵の対を新しいバージョンのグループ錠のSGとPGとする。また、Fの値は「抹消」となる。よって新しいバージョンを受け取った個人は、以前のバージョンを削除しない。これは、削除以前に暗号化された暗号を、削除されたメンバを除いた以前のメンバが復号するために必要であるためである。ただし、受け取った個人が新しいバージョンの秘密鍵を獲得できない場合、すなわち削除されたメンバであった場合には、削除する。これは、削除以前に暗号化された暗号も削除されたメンバが復号できないようにするためである。この削除されたメンバが以前のバージョンのグループ錠を削除することは数学的に保証するものではなく、システムとして削除を促進することはできるという性格のものである。
既存のメンバを削除する。削除されたメンバは、削除以前に暗号化された暗号も復号することができない。この場合には、新しい秘密鍵と公開鍵の対を新しいバージョンのグループ錠のSGとPGとする。また、Fの値は「抹消」となる。よって新しいバージョンを受け取った個人は、以前のバージョンを削除しない。これは、削除以前に暗号化された暗号を、削除されたメンバを除いた以前のメンバが復号するために必要であるためである。ただし、受け取った個人が新しいバージョンの秘密鍵を獲得できない場合、すなわち削除されたメンバであった場合には、削除する。これは、削除以前に暗号化された暗号も削除されたメンバが復号できないようにするためである。この削除されたメンバが以前のバージョンのグループ錠を削除することは数学的に保証するものではなく、システムとして削除を促進することはできるという性格のものである。
グループ錠を変更したときには、Fの値が意味を持つだけでなく、以前のバージョンの変更用秘密鍵で署名する。これは前述したように、以前のバージョンを信用している場合に、新しいバージョンを自動的に信用できるようにするためである。グループ錠を変更したときには、必要な者に速やかに配布する。
図16および図17に示すグループ錠変更フローについて詳述する。ステップ901、902において変更するグループ錠を特定し、変更の種類を判別する。ステップ902において追加と削除の処理のいずれかを選択することとなるが、メンバの入れ替えのように追加、削除が同時に発生するような場合は、メンバごとに順序を設定して1メンバごとに処理を実行する。
ステップ902において変更がメンバの追加である場合は、ステップ903へ進み、公開錠リストから追加するメンバに対応するグループもしくは個人の公開鍵を選択する。次にステップ904においてこの追加が現在からの追加でよいか、あるいは過去に溯って追加する必要があるかについて判断される。すなわち、過去の暗号情報の復号を可能とするか否かについて決定するものである。ステップ904の判断が「いいえ」すなわち現時点以降の追加となる場合は、ステップ905でグループ公開鍵PGとグループ秘密鍵SGが生成され、ステップ906でグループ錠の直前バージョン扱いを示す「F」を必要と設定する。これは、新たなバージョンのグループ錠と元の旧バージョンのグループ錠が共存することを示している。一方ステップ904の判断が「溯って追加」である場合は、ステップ907、908へ進み、現在変更中のグループ錠のSG、PGをそのまま変更されたグループ錠のSG、PGとして設定し、Fを「不要」と設定する。これは、旧バージョンのグループ錠が新バージョンのグループ錠に完全に置き換えられたことを示している。次にステップ909で、グループ秘密鍵SGを追加メンバを含めたメンバの公開鍵PMiで暗号化し、PMiに対応するラベルLMiをインデックスとするPMi(SG)の配列を形成する。
次にステップ910で新しい変更権所有者の設定、ステップ911で変更鍵の秘密鍵と公開鍵のペアの生成、ステップ912で新たな変更権所有者の公開鍵を用いて変更鍵の秘密鍵を暗号化する。
さらに、ステップ913でバージョン番号Vの更新、ステップ914で各データの一体化、ステップ915で一体化されたデータに対する変更秘密鍵による署名を実行し、署名結果Sig(SU)とし、ステップ916でさらに署名結果を加えたデータの一体化を行う。ステップ917で、変更前バージョンの変更用秘密鍵SU'で署名し、Sig(SU')とし、ステップ918で変更されたグループ錠を作成者の信用錠リストに追加してグループ錠の変更手続を終了する。
ステップ902において変更がメンバの削除である場合は、ステップ919へ進み、削除するメンバを選択する。次にステップ920においてこの削除が現在からでよいか、あるいは過去に溯る必要があるかについて判断される。すなわち、過去の暗号情報の復号を可能とするか否かについて決定するものである。ステップ920の判断が「いいえ」すなわち現時点以降の削除となる場合は、ステップ921でグループ公開鍵PGとグループ秘密鍵SGが生成され、ステップ922でグループ錠の直前バージョン扱いを示す「F」を必要と設定する。これは、新たなバージョンのグループ錠と元の旧バージョンのグループ錠が共存することを示している。一方ステップ920の判断が「溯って削除」である場合は、ステップ923、924へ進み、現在変更中のグループ錠のSG、PGをそのまま変更されたグループ錠のSG、PGとして設定し、Fを「抹消」と設定する。次にステップ925で、グループ秘密鍵SGを削除メンバを削除したメンバの公開鍵PMiで暗号化し、PMiに対応するラベルLMiをインデックスとするPMi(SG)の配列を形成する。以下の手続きであるステップ910以降は追加の場合と同様である。
以上、本発明の実施例を説明したが、例えば複号錠の生成、あるいは変更は、暗号化装置、復号装置、あるいはその他の第3局における装置等いずれにおいて実行されてもよく、他のこの公開鍵暗号方式において用いられる他の構成要素、例えば各種の錠リスト等についても同様である。
以上説明したように、本発明の構成においては、共通鍵暗号方式および公開鍵暗号方式の組み合わせ構成を持つ暗号方式を実現し、平文を共通鍵暗号方式における共通鍵Kにより暗号化した暗号情報K(D)と、1以上のメンバMi(i=1〜n)を構成員とするグループに属するメンバ個々の公開鍵暗号方式における公開鍵Piによって共通鍵Kを暗号化した1以上の暗号鍵情報Pi(K)とを、構成要素として含む暗号情報を生成して、この暗号情報を送受信する構成とすることで、各メンバMi(i=1〜n)は、暗号鍵情報Pi(K)を自己の保持するメンバ個々の公開鍵暗号方式における秘密鍵Siによって復号して共通鍵暗号方式における共通鍵Kを取得して、暗号情報K(D)の復号により、データ(D)を取得することができ、グループ内と外との間では高度な機密性を保ちながら、グループ内のメンバ間ではメンバであることの確認の基に暗号情報を共有することが可能となる。
101 個人
102 平文
103 暗号
104 錠リスト
105 個人秘密鍵
102 平文
103 暗号
104 錠リスト
105 個人秘密鍵
Claims (7)
- 少なくとも平文を共通鍵暗号方式における共通鍵Kにより暗号化した暗号情報K(D)と、
1以上のメンバMi(i=1〜n)を構成員とするグループに属するメンバ個々の公開鍵暗号方式における公開鍵Piによって前記共通鍵Kを暗号化した1以上の暗号鍵情報Pi(K)と、
を有する構成データを暗号情報として構成したことを特徴とする暗号方式。 - 少なくとも平文を共通鍵暗号方式における共通鍵Kにより暗号化した暗号情報K(D)と、1以上のメンバMi(i=1〜n)を構成員とするグループに属するメンバ個々の公開鍵暗号方式における公開鍵Piによって前記共通鍵Kを暗号化した1以上の暗号鍵情報Pi(K)とを生成する暗号手段と、
前記暗号手段から、前記暗号情報K(D)と、前記暗号鍵情報Pi(K)を入力し、前記暗号情報K(D)と、前記暗号鍵情報Pi(K)を構成データとして有する暗号情報を生成する暗号情報生成手段と、
を有することを特徴とする暗号情報生成装置。 - 少なくとも平文を共通鍵暗号方式における共通鍵Kにより暗号化した暗号情報K(D)と、1以上のメンバMi(i=1〜n)を構成員とするグループに属するメンバ個々の公開鍵暗号方式における公開鍵Piによって前記共通鍵Kを暗号化した1以上の暗号鍵情報Pi(K)とを生成する暗号手段と、
前記暗号手段から、前記暗号情報K(D)と、前記暗号鍵情報Pi(K)を入力し、前記暗号情報K(D)と、前記暗号鍵情報Pi(K)を構成データとした暗号情報を送信する暗号情報送信手段と、
を有することを特徴とする暗号情報送信装置。 - 少なくとも平文を共通鍵暗号方式における共通鍵Kにより暗号化した暗号情報K(D)と、
1以上のメンバMi(i=1〜n)を構成員とするグループに属するメンバ個々の公開鍵暗号方式における公開鍵Piによって前記共通鍵Kを暗号化した1以上の暗号鍵情報Pi(K)と、
を有する構成データを暗号情報として送受信する構成を有することを特徴とする暗号情報通信システム。 - 暗号手段において、少なくとも平文を共通鍵暗号方式における共通鍵Kを適用して暗号化し、暗号情報K(D)を生成するステップと、
暗号手段において、1以上のメンバMi(i=1〜n)を構成員とするグループに属するメンバ個々の公開鍵暗号方式における公開鍵Piを適用して、前記共通鍵Kを暗号化した1以上の暗号鍵情報Pi(K)を生成するステップと、
暗号情報生成手段において、前記暗号手段の生成する前記暗号情報K(D)と、前記暗号鍵情報Pi(K)を入力し、前記暗号情報K(D)と、前記暗号鍵情報Pi(K)を構成データとして有する暗号情報を生成するステップと、
を有することを特徴とする暗号情報生成方法。 - 暗号手段において、少なくとも平文を共通鍵暗号方式における共通鍵Kを適用して暗号化し、暗号情報K(D)を生成するステップと、
暗号手段において、1以上のメンバMi(i=1〜n)を構成員とするグループに属するメンバ個々の公開鍵暗号方式における公開鍵Piを適用して、前記共通鍵Kを暗号化した1以上の暗号鍵情報Pi(K)を生成するステップと、
暗号情報送信手段において、前記暗号手段の生成する前記暗号情報K(D)と、前記暗号鍵情報Pi(K)を入力し、前記暗号情報K(D)と、前記暗号鍵情報Pi(K)を構成データとして有する暗号情報を生成するステップと、
を有することを特徴とする暗号情報送信方法。 - 暗号情報の生成処理をコンピュータ上で実行させるコンピュータ・プログラムを記録したコンピュータ読み取り可能な記録媒体であり、
暗号手段において、少なくとも平文を共通鍵暗号方式における共通鍵Kを適用して暗号化し、暗号情報K(D)を生成するステップと、
暗号手段において、1以上のメンバMi(i=1〜n)を構成員とするグループに属するメンバ個々の公開鍵暗号方式における公開鍵Piを適用して、前記共通鍵Kを暗号化した1以上の暗号鍵情報Pi(K)を生成するステップと、
暗号情報生成手段において、前記暗号手段の生成する前記暗号情報K(D)と、前記暗号鍵情報Pi(K)を入力し、前記暗号情報K(D)と、前記暗号鍵情報Pi(K)を構成データとして有する暗号情報を生成するステップと、
を実行させるプログラムを記録したコンピュータ読み取り可能な記録媒体。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2005125611A JP2005223953A (ja) | 2005-04-22 | 2005-04-22 | 暗号方式、暗号情報生成装置、暗号情報送信装置、および方法、並びにコンピュータ読み取り可能な記録媒体 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2005125611A JP2005223953A (ja) | 2005-04-22 | 2005-04-22 | 暗号方式、暗号情報生成装置、暗号情報送信装置、および方法、並びにコンピュータ読み取り可能な記録媒体 |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP9164506A Division JPH1115373A (ja) | 1997-06-20 | 1997-06-20 | 公開鍵暗号方式 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2005223953A true JP2005223953A (ja) | 2005-08-18 |
Family
ID=34999170
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2005125611A Pending JP2005223953A (ja) | 2005-04-22 | 2005-04-22 | 暗号方式、暗号情報生成装置、暗号情報送信装置、および方法、並びにコンピュータ読み取り可能な記録媒体 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2005223953A (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9407431B2 (en) | 2006-11-07 | 2016-08-02 | Security First Corp. | Systems and methods for distributing and securing data |
-
2005
- 2005-04-22 JP JP2005125611A patent/JP2005223953A/ja active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9407431B2 (en) | 2006-11-07 | 2016-08-02 | Security First Corp. | Systems and methods for distributing and securing data |
US9774449B2 (en) | 2006-11-07 | 2017-09-26 | Security First Corp. | Systems and methods for distributing and securing data |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JPH1115373A (ja) | 公開鍵暗号方式 | |
JP2000124887A (ja) | グループ単位の暗号化・復号方法および署名方法ならびに装置 | |
Callas et al. | OpenPGP message format | |
US7739501B2 (en) | Cryptographic key construct | |
KR100568233B1 (ko) | 인증서를 이용한 기기 인증 방법 및 상기 방법을 이용하여기기 인증을 수행하는 디지털 컨텐츠 처리 기기 | |
US20190377889A1 (en) | Verifiable version control on authenticated and/or encrypted electronic documents | |
US20110145576A1 (en) | Secure method of data transmission and encryption and decryption system allowing such transmission | |
US20100005318A1 (en) | Process for securing data in a storage unit | |
CN109981255B (zh) | 密钥池的更新方法和系统 | |
JP4788212B2 (ja) | デジタル署名プログラム及びデジタル署名システム | |
Callas et al. | RFC 4880: OpenPGP message format | |
CN110557248A (zh) | 基于无证书密码学的抗量子计算签密的密钥更新方法和系统 | |
JP3984570B2 (ja) | 署名/検証システムにおける鍵管理サーバおよび検証装置を制御するプログラム | |
JPH11308213A (ja) | 暗号データ回復方法および装置 | |
JP4229082B2 (ja) | 複合錠生成方法、複合錠変更方法、および情報処理装置、並びにコンピュータ読み取り可能な記録媒体 | |
JP2005223953A (ja) | 暗号方式、暗号情報生成装置、暗号情報送信装置、および方法、並びにコンピュータ読み取り可能な記録媒体 | |
JP2005223954A (ja) | 復号装置、および復号方法、並びにコンピュータ読み取り可能な記録媒体 | |
EP2575287A1 (en) | Method for publishing content over a communication network | |
CN111556079B (zh) | 基于身份加密的可控匿名通信方法 | |
JPH1155247A (ja) | 送信者匿名性確保秘密情報伝達方法、その装置及びそのプログラム記録媒体 | |
JP3919700B2 (ja) | 暗号システム及びその暗号文処理方法 | |
JP2005222321A (ja) | データ通信装置、サーバ及びデータ検証システム | |
KR101674643B1 (ko) | 폐기 기능을 갖는 무한한 계층적 id 기반 암호화 시스템 | |
JP2000134195A (ja) | 暗号化装置、復号化装置、方法及びその記録媒体 | |
JP2002344442A (ja) | データ送信装置、データ受信装置および通信システム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080520 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080717 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080819 |