図面 (/)

技術 認証局装置移行方法、認証局装置移行プログラム、認証局装置

出願人 富士通株式会社
発明者 竹内高志
出願日 2009年10月23日 (11年0ヶ月経過) 出願番号 2009-243969
公開日 2011年5月6日 (9年6ヶ月経過) 公開番号 2011-091656
状態 特許登録済
技術分野 暗号化・復号化装置及び秘密通信
主要キーワード 受取機 内部仕様 移行作業 運用期間 製品固有 トラストポイント 機能特徴 失効状態
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2011年5月6日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

認証局リポジトリの構成の異なる認証局装置間にて資産移行を可能とする技術を提供すること。

解決手段

この認証局装置移行の方法は、まず、移行先認証局装置が、移行元認証局装置発行した認証局証明書およびエンドエンティティ証明書を読み込んで解析して認証局発行情報を作成する。更に、移行先認証局装置は、移行元認証局装置が発行した最新の、失効した証明書リストを読み込んで解析して、認証局発行情報に失効情報を追加する。そして、移行元認証局装置および移行先認証局装置が、発行者名被発行者名が同一の証明書であって、リンク証明と同一になる証明書を相互認証証明書として発行することにより認証局装置の移行を行う。

概要

背景

一般に、電子証明書発行する機関認証局という。本明細書では、認証局において電子証明書を発行する情報処理装置認証局装置と記載する。
認証局装置の構成を図21に示す。

認証局装置は、証明書発行機能211、CRL(Certificate Revolution List、失効した証明書リスト発行機能212、証明書シリアル番号カウンタ213、証明書プロファイルテンプレート214、CRLシリアル番号カウンタ215、拇印検証機能216、署名検証機能217、プロファイル解析機能218、認証局リポジトリ証明書管理データベース)219を含んで構成される。また、認証局装置は、公開鍵(Public Key)と秘密鍵(Private Key)を備えている。

証明書発行機能211は、証明書を発行するところで、証明書プロファイルテンプレート214を用いて、証明書シリアル番号カウンタ213に格納されているシリアル番号にて証明書を発行する。また、CRL発行機能212は、すでに発行した証明書の失効情報を発行するところである。CRLの発行は定期的に行われ、CRLが発行されるたびにCRLシリアル番号カウンタ215はインクリメントされる。

拇印検証機能216は、他の認証局が発行した証明書を受け取った場合に、その証明書の正しさを確認するために、公開されている拇印とその証明書の拇印を照合してその証明書の正しさを確認するものである。

署名検証機能217は、他の認証局が発行した証明書やCRL等を受け取った場合に、その証明書等の正しさを確認するために、公開鍵を用いて受け取った証明書等の署名を検証し、その証明書の正しさを確認するものである。

プロファイル解析機能218は、受け取った証明書等のプロファイル解析するものである。
認証局リポジトリ219は、発行した証明書、CRLおよび証明書の発行に関する情報(発行情報)等を格納するところで、発行した証明書、CRL等を管理するためのデータベースである。

このような認証局装置において、鍵を更新する場合について図22を参照して説明する。同一の認証局装置内において鍵を更新する場合、古い鍵で発行された証明書を信用しているユーザと新しい鍵で発行された証明書を信用するユーザの両方に対して、証明書を検証できるようにしなければならない。そのために認証局は、新しい公開鍵に古い秘密鍵で署名した証明書 (NewWithOld) と、古い公開鍵に新しい秘密鍵で署名した証明書(OldWithNew) を発行する。このようにNewWithOld や OldWithNew などの証明書をリンク証明書という。

リンク証明書を使った、証明書の有効性検証方法について説明する。まず、古い認証局証明書信頼するユーザが、認証局が新たに発行した証明書の有効性を検証する場合、古い証明書(OldWithOld)でリンク証明書(NewWithOld)を検証する(A-1)。そして、リンク証明(NewWithOld)で新しい証明書(NewWithNew)を検証する(A-2)。

また、新しい証明書を信頼するユーザが、認証局が発行した古い証明書の信頼性を検証する場合、新しい証明書(NewWithNew)でリンク証明書(OldWithNew)を検証する(B-1)。そして、リンク証明書(OldWithNew)で古い証明書(OldWithOld)を検証する。

このようにリンク証明書によって、OldWithOld, NewWithNewの二つの証明書が存在する期間において、どちらの証明書のユーザもその有効性の検証が行うことができるようになっている。

また、図21に示した認証局装置において、異なる認証局間で相互認証を行う場合について図23を参照して説明する。

相互認証を行う場合、それぞれの認証局は互いに相手の認証局に対して証明書を発行する。この証明書を「相互認証証明書(Cross Certificate)」という。この相互認証証明書は、認証局装置内のリポジトリに格納される。証明書(認証局から発行された証明書、EE証明書(エンドエンティティ証明書))を利用するユーザは、相互認証証明書をたどることで他の認証局のユーザの証明書(EE証明書)を検証することができる。

検証したい証明書から出発して信用関係を順にたどり、自分が信用している認証局まで結ぶものを認証パスという。図23では、相互認証証明書によりユーザ1(User1)の証明書を出発して、認証局CA2まで認証パスが生成され、ユーザ2の証明書が検証することができるようになっている。

ところで、証明書を発行する認証局装置が古くなった場合などに、新しい認証局装置に入れ替える(リプレース)必要がある。認証局としての機能を継続するためには、古い認証局装置の資産、すなわち、認証局リポジトリ219に格納、管理されている情報を新しい認証局装置に移す必要がある。同一製品の認証局装置間でリプレースを行う場合には、証明書管理リポジトリ219の情報やその他ファイル等の製品固有の資産をそのまま後継製品に取り込む(インポート)することで移行が実現できる。

しかし、認証局装置間の資産移行に関する規約がないため、認証局装置を製造する各ベンダは各社固有の方法で資産管理を行っている。このため製品間の互換性がなく、別の認証局製品間で資産を移行する方法がなかった。認証局の運営者は、移行元の認証局装置を維持しながら移行先である新規の認証局装置を構築しなければならず、移行元認証局装置で発行した証明書が全て失効されるか有効期限切れになるまで並行運用が必要となり、運用コスト倍増するという問題があった。

このように別の認証局装置製品間にて移行をスムーズに行えるようにすることが求められている。しかしながら、証明書管理リポジトリ219の構成が異なる認証局装置間で移行を可能とするためには、次の(1)〜(3)の問題を解決する必要がある。

(1)発行情報の移行元認証局装置および移行先認証局装置間での連携
移行先認証局装置と、移行元認証局装置で、発行する証明書のシリアル番号の一貫性を維持しなければならない。そのために、移行元認証局装置で発行した全ての証明書の発行情報を移行先認証局装置に取り込む必要がある。発行情報を移行先認証局装置に取り込む方法として、製品固有資産を取り込む方法と、移行元認証局装置が発行した全ての証明書を移行先認証局装置に取り込む方法がある。

製品固有資産を取り込んで移行する場合、移行元認証局装置の内部仕様を公開することが前提条件となり、その仕様に合わせて移行先認証局装置に作りこみが必要となる。認証局装置の内部仕様を公開しなければならないという問題と、移行元認証局装置毎に改造が必要となるという問題がある。

また、移行元認証局装置が発行した全証明書を移行先認証局装置に取り込んで移行する場合、汎用性が高い反面、証明書の枚数が多くなると手作業では各証明書の検証が行えず、操作する作業者誤操作や不正の余地が生まれ効率が悪くなる。

(2)失効情報の移行元認証局装置および移行先認証局間装置での連携
移行先認証局装置では、移行元認証局装置で発行された証明書も失効できるようにするために、移行元認証局装置の失効情報を移行先認証局装置に取り込む必要がある。失効情報を移行先認証局装置に取り込む方法として、製品固有資産を取り込む方法と、CRL等の失効情報を取り込む方法がある。

製品固有資産を取り込んで移行する場合、移行元認証局装置が内部仕様を公開することが前提条件となり、その仕様に合わせて移行先認証局装置および移行元認証局装置に作りこみが必要になる。認証局装置の内部仕様を公開しなければならないという問題と、移行先認証局装置毎に改造が必要となるという問題がある。

また、CRL等の失効情報を取り込んで移行する方法は、汎用性が高い反面、多くの失効情報を取り込むにはCRLの枚数が多くなり、作業者の誤操作や不正の余地が生まれ効率が悪くなる。

(3)移行元認証局装置および移行先認証局装置を同一認証局であるように見せる
移行作業終了後、移行元認証局装置で発行された証明書を信用するユーザと、移行先認証局装置で発行された証明書を信用するユーザの両方に対して、その有効性を検証できるようにしておかなければならない。そのためには、移行先認証局装置と移行元認証局装置を同一認証局に見せなければならない。このような認証パスを通すために、移行元認証局装置で発行したリンク証明書を移行先認証局装置に取り込み、その証明書においてもシリアル番号の一貫性を確保する必要がある。しかし従来の認証局装置では証明書のシリアル番号の一貫性を確保するために、発行時にシリアル番号を外部から指定することはできなかった。よって、移行先認証局装置および移行先認証局装置を同一認証局に見せる認証パスは実現できなかった。

概要

認証局リポジトリの構成の異なる認証局装置間にて資産の移行を可能とする技術を提供すること。 この認証局装置移行の方法は、まず、移行先認証局装置が、移行元認証局装置が発行した認証局証明書およびエンドエンティティ証明書を読み込んで解析して認証局発行情報を作成する。更に、移行先認証局装置は、移行元認証局装置が発行した最新の、失効した証明書のリストを読み込んで解析して、認証局発行情報に失効情報を追加する。そして、移行元認証局装置および移行先認証局装置が、発行者名被発行者名が同一の証明書であって、リンク証明と同一になる証明書を相互認証証明書として発行することにより認証局装置の移行を行う。

目的

本発明は、証明書管理リポジトリの構成が異なる、認証局装置間にて移行をスムーズに行えるようにすることを目的とする

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

証明書管理リポジトリの構成が異なる認証局装置間において、移行元認証局装置資産移行先認証局装置移行するための方法であって、前記移行先認証局装置が、前記移行元認証局装置が発行した認証局証明書およびエンドエンティティ証明書を読み込んで解析して認証局発行情報を作成し、更に、該移行元認証局装置が発行した最新の、失効した証明書のリストを読み込んで解析して、該認証局発行情報に失効情報を追加し、前記移行元認証局装置および前記移行先認証局装置が、発行者名被発行者名が同一の証明書であって、移行元認証局装置の鍵を該古い鍵、移行先認証局装置の鍵を該新しい鍵とした相互認証証明書を発行する、ことを特徴とする認証局装置移行方法

請求項2

証明書管理リポジトリの構成が異なる認証局装置間で移行元認証局装置の資産の移行を行うために、移行先認証局装置を構成する情報処理装置を、前記移行元認証局装置が発行した認証局証明書およびエンドエンティティ証明書を、読み込んで解析して、前記移行先認証局装置固有の認証局発行情報を作成し、該移行元認証局装置が発行した最新の、失効した証明書のリストを読込んで解析して、該認証局発行情報に失効情報を追加する、資産移行手段と、移行作業開始後に前記移行元認証局で発行されたダミー証明書シリアル番号にて前記移行先認証局装置の認証局証明書を発行するとともに、前記認証局発行情報に発行記録としてのレコードを追加する、移行先認証局証明書発行手段と、順方向相互認証証明書発行申請書を作成し、前記移行元認証局で発行された順方向相互認証証明書を取り込み、前記認証局発行情報に該順方向相互認証証明書に対応するレコードを追加する、順方向認証パス生成手段と、前記移行元認証局で作成された逆方向相互認証証明書発行申請書に基づいて、前記順方向相互認証証明書に対応する逆方向相互認証証明書を発行するとともに、前記認証局発行情報に発行記録としてのレコードを追加する、逆方向認証パス生成手段と、して機能させるための認証局装置移行プログラム

請求項3

前記認証局発行情報は、証明書のシリアル番号、証明書の種別、証明書の被発行者名、証明書の発行者名、有効期間、証明書バイナリデータをそれぞれ格納する欄を含むレコードをリスト状にして構成されるもので、前記資産移行手段は、前記読み込んだ認証局証明書および全てのエンドエンティティ証明書から、証明書のシリアル番号、証明書の被発行者名、証明書の発行者名、有効期間をそれぞれ抽出し、対応する前記認証局発行情報のレコードの前記格納欄にそれぞれ格納し、前記認証局発行情報のレコードの証明書バイナリデータ格納欄には前記認証局証明書および全てのエンドエンティティ証明書のそれぞれの証明書自身のバイナリデータをそのまま格納することを特徴とする請求項2記載の認証局装置移行プログラム。

請求項4

前記認証局発行情報のレコードは、証明書の失効日時、失効理由を格納する欄を更に含んで構成され、前記資産移行手段は、前記認証局発行情報における証明書のシリアル番号と、前記失効した証明書のリストから得られた失効する証明書のシリアル番号が一致するレコードについて、失効日時と失効理由を追加することを特徴とする請求項3記載の認証局装置移行プログラム。

請求項5

前記順方向相互認証証明書は、前記移行元認証局装置から前記移行先認証局装置に宛てて発行される相互認証証明書であり、前記逆方向相互認証証明書は、前記移行先認証局装置から前記移行元認証局装置に宛てて発行される相互認証証明書であり、更に、前記順方向相互認証証明書および前記逆方向相互認証証明書は、発行者名と被発行者名が同一の証明書であり、同一認証局装置で古い鍵から新しい鍵に更新を行う場合に発行されるリンク証明書のように、前記移行元認証局装置の鍵を該古い鍵、前記移行先認証局装置の鍵を該新しい鍵として発行される該リンク証明書相当の証明書であることを特徴とする請求項2記載の認証局装置移行プログラム。

請求項6

前記順方向認証パス生成手段は、前記順方向相互認証証明書を取り込むのに合わせてダミー証明書を発行し、前記移行先認証局装置で証明書のシリアル番号が重複するのを回避することを特徴とする請求項2乃至請求項5いずれか一項に記載の認証局装置移行プログラム。

請求項7

証明書管理リポジトリの構成が異なる認証局装置間で移行元認証局の資産の移行を行う際の移行先側の認証局装置であって、前記移行元認証局装置が発行した認証局証明書およびエンドエンティティ証明書を、読み込んで解析して、前記移行先認証局装置固有の認証局発行情報を作成する移行元証明書の受取手段と、前記移行元認証局装置が発行した最新の、失効した証明書のリストを読み込んで解析して、前記認証局発行情報に失効情報を追加する移行元失効情報の受取手段と、移行作業開始後に前記移行元認証局で発行されたダミー証明書のシリアル番号にて前記移行先認証局装置の認証局証明書を発行するとともに、前記認証局発行情報に発行記録としてのレコードを追加する、認証局証明書の移行発行手段と、順方向相互認証証明書発行申請書を作成し、前記移行元認証局で発行された順方向相互認証証明書を取り込み、前記認証局発行情報に該順方向相互認証証明書に対応するレコードを追加する、順方向認証パス生成手段と、前記移行元認証局で作成された逆方向相互認証証明書発行申請書に基づいて、前記順方向相互認証証明書に対応する逆方向相互認証証明書を発行するとともに、前記認証局発行情報に発行記録としてのレコードを追加する、逆方向認証パス生成手段と、を含むことを特徴とする認証局装置。

技術分野

0001

本発明は、電子証明書発行する認証局装置移行するための技術に関する。

背景技術

0002

一般に、電子証明書を発行する機関認証局という。本明細書では、認証局において電子証明書を発行する情報処理装置を認証局装置と記載する。
認証局装置の構成を図21に示す。

0003

認証局装置は、証明書発行機能211、CRL(Certificate Revolution List、失効した証明書リスト発行機能212、証明書シリアル番号カウンタ213、証明書プロファイルテンプレート214、CRLシリアル番号カウンタ215、拇印検証機能216、署名検証機能217、プロファイル解析機能218、認証局リポジトリ証明書管理データベース)219を含んで構成される。また、認証局装置は、公開鍵(Public Key)と秘密鍵(Private Key)を備えている。

0004

証明書発行機能211は、証明書を発行するところで、証明書プロファイルテンプレート214を用いて、証明書シリアル番号カウンタ213に格納されているシリアル番号にて証明書を発行する。また、CRL発行機能212は、すでに発行した証明書の失効情報を発行するところである。CRLの発行は定期的に行われ、CRLが発行されるたびにCRLシリアル番号カウンタ215はインクリメントされる。

0005

拇印検証機能216は、他の認証局が発行した証明書を受け取った場合に、その証明書の正しさを確認するために、公開されている拇印とその証明書の拇印を照合してその証明書の正しさを確認するものである。

0006

署名検証機能217は、他の認証局が発行した証明書やCRL等を受け取った場合に、その証明書等の正しさを確認するために、公開鍵を用いて受け取った証明書等の署名を検証し、その証明書の正しさを確認するものである。

0007

プロファイル解析機能218は、受け取った証明書等のプロファイル解析するものである。
認証局リポジトリ219は、発行した証明書、CRLおよび証明書の発行に関する情報(発行情報)等を格納するところで、発行した証明書、CRL等を管理するためのデータベースである。

0008

このような認証局装置において、鍵を更新する場合について図22を参照して説明する。同一の認証局装置内において鍵を更新する場合、古い鍵で発行された証明書を信用しているユーザと新しい鍵で発行された証明書を信用するユーザの両方に対して、証明書を検証できるようにしなければならない。そのために認証局は、新しい公開鍵に古い秘密鍵で署名した証明書 (NewWithOld) と、古い公開鍵に新しい秘密鍵で署名した証明書(OldWithNew) を発行する。このようにNewWithOld や OldWithNew などの証明書をリンク証明書という。

0009

リンク証明書を使った、証明書の有効性検証方法について説明する。まず、古い認証局証明書信頼するユーザが、認証局が新たに発行した証明書の有効性を検証する場合、古い証明書(OldWithOld)でリンク証明書(NewWithOld)を検証する(A-1)。そして、リンク証明(NewWithOld)で新しい証明書(NewWithNew)を検証する(A-2)。

0010

また、新しい証明書を信頼するユーザが、認証局が発行した古い証明書の信頼性を検証する場合、新しい証明書(NewWithNew)でリンク証明書(OldWithNew)を検証する(B-1)。そして、リンク証明書(OldWithNew)で古い証明書(OldWithOld)を検証する。

0011

このようにリンク証明書によって、OldWithOld, NewWithNewの二つの証明書が存在する期間において、どちらの証明書のユーザもその有効性の検証が行うことができるようになっている。

0012

また、図21に示した認証局装置において、異なる認証局間で相互認証を行う場合について図23を参照して説明する。

0013

相互認証を行う場合、それぞれの認証局は互いに相手の認証局に対して証明書を発行する。この証明書を「相互認証証明書(Cross Certificate)」という。この相互認証証明書は、認証局装置内のリポジトリに格納される。証明書(認証局から発行された証明書、EE証明書(エンドエンティティ証明書))を利用するユーザは、相互認証証明書をたどることで他の認証局のユーザの証明書(EE証明書)を検証することができる。

0014

検証したい証明書から出発して信用関係を順にたどり、自分が信用している認証局まで結ぶものを認証パスという。図23では、相互認証証明書によりユーザ1(User1)の証明書を出発して、認証局CA2まで認証パスが生成され、ユーザ2の証明書が検証することができるようになっている。

0015

ところで、証明書を発行する認証局装置が古くなった場合などに、新しい認証局装置に入れ替える(リプレース)必要がある。認証局としての機能を継続するためには、古い認証局装置の資産、すなわち、認証局リポジトリ219に格納、管理されている情報を新しい認証局装置に移す必要がある。同一製品の認証局装置間でリプレースを行う場合には、証明書管理リポジトリ219の情報やその他ファイル等の製品固有の資産をそのまま後継製品に取り込む(インポート)することで移行が実現できる。

0016

しかし、認証局装置間の資産移行に関する規約がないため、認証局装置を製造する各ベンダは各社固有の方法で資産管理を行っている。このため製品間の互換性がなく、別の認証局製品間で資産を移行する方法がなかった。認証局の運営者は、移行元の認証局装置を維持しながら移行先である新規の認証局装置を構築しなければならず、移行元認証局装置で発行した証明書が全て失効されるか有効期限切れになるまで並行運用が必要となり、運用コスト倍増するという問題があった。

0017

このように別の認証局装置製品間にて移行をスムーズに行えるようにすることが求められている。しかしながら、証明書管理リポジトリ219の構成が異なる認証局装置間で移行を可能とするためには、次の(1)〜(3)の問題を解決する必要がある。

0018

(1)発行情報の移行元認証局装置および移行先認証局装置間での連携
移行先認証局装置と、移行元認証局装置で、発行する証明書のシリアル番号の一貫性を維持しなければならない。そのために、移行元認証局装置で発行した全ての証明書の発行情報を移行先認証局装置に取り込む必要がある。発行情報を移行先認証局装置に取り込む方法として、製品固有資産を取り込む方法と、移行元認証局装置が発行した全ての証明書を移行先認証局装置に取り込む方法がある。

0019

製品固有資産を取り込んで移行する場合、移行元認証局装置の内部仕様を公開することが前提条件となり、その仕様に合わせて移行先認証局装置に作りこみが必要となる。認証局装置の内部仕様を公開しなければならないという問題と、移行元認証局装置毎に改造が必要となるという問題がある。

0020

また、移行元認証局装置が発行した全証明書を移行先認証局装置に取り込んで移行する場合、汎用性が高い反面、証明書の枚数が多くなると手作業では各証明書の検証が行えず、操作する作業者誤操作や不正の余地が生まれ効率が悪くなる。

0021

(2)失効情報の移行元認証局装置および移行先認証局間装置での連携
移行先認証局装置では、移行元認証局装置で発行された証明書も失効できるようにするために、移行元認証局装置の失効情報を移行先認証局装置に取り込む必要がある。失効情報を移行先認証局装置に取り込む方法として、製品固有資産を取り込む方法と、CRL等の失効情報を取り込む方法がある。

0022

製品固有資産を取り込んで移行する場合、移行元認証局装置が内部仕様を公開することが前提条件となり、その仕様に合わせて移行先認証局装置および移行元認証局装置に作りこみが必要になる。認証局装置の内部仕様を公開しなければならないという問題と、移行先認証局装置毎に改造が必要となるという問題がある。

0023

また、CRL等の失効情報を取り込んで移行する方法は、汎用性が高い反面、多くの失効情報を取り込むにはCRLの枚数が多くなり、作業者の誤操作や不正の余地が生まれ効率が悪くなる。

0024

(3)移行元認証局装置および移行先認証局装置を同一認証局であるように見せる
移行作業終了後、移行元認証局装置で発行された証明書を信用するユーザと、移行先認証局装置で発行された証明書を信用するユーザの両方に対して、その有効性を検証できるようにしておかなければならない。そのためには、移行先認証局装置と移行元認証局装置を同一認証局に見せなければならない。このような認証パスを通すために、移行元認証局装置で発行したリンク証明書を移行先認証局装置に取り込み、その証明書においてもシリアル番号の一貫性を確保する必要がある。しかし従来の認証局装置では証明書のシリアル番号の一貫性を確保するために、発行時にシリアル番号を外部から指定することはできなかった。よって、移行先認証局装置および移行先認証局装置を同一認証局に見せる認証パスは実現できなかった。

先行技術

0025

特開2002−217901号公報
特開2001−350406号公報

発明が解決しようとする課題

0026

本発明は、証明書管理リポジトリの構成が異なる、認証局装置間にて移行をスムーズに行えるようにすることを目的とする。
この目的を実現するために、次の(1)〜(3)の問題を解決する。
(1)移行元認証局装置および移行先認証局装置間で発行情報を連携できるようにする。
(2)移行元認証局装置および移行先認証局間装置で失効情報を連携できるようにする。
(3)証明書のシリアル番号の一貫性を保ちつつ、移行元認証局装置および移行先認証局装置を同一認証局であると認識させる認証パスを生成する。

課題を解決するための手段

0027

この、証明書管理リポジトリの構成が異なる認証局装置間における移行の方法は、上記(1)〜(3)の問題をそれぞれ以下のように解決する。
(1)移行先認証局装置が、移行元認証局装置が発行した全ての証明書を読み込んで解析し、移行先認証局装置の証明書管理リポジトリ内に移行先認証局装置固有の認証局発行情報を作成して管理する。

0028

(2)移行先認証局装置が、移行元認証局が発行した最新のCRL(失効した証明書のリスト)を読み込んで解析し、移行先認証局の証明書管理リポジトリ内に管理されている認証局発行情報に追加して管理する。

0029

(3)移行元認証局装置および移行先認証局装置が同一認証局であると認識される認証パスを生成するために、同一認証局装置内における鍵の更新機能と、認証局装置間における相互認証機能を併用することによって実現する。その際、移行元・移行先認証局装置の証明書の発行者名被発行者名を一致させて、リンク証明と同一の相互認証証明書を発行する。また、移行先認証局装置が順方向相互認証証明書を取り込むのに合わせて、ダミー証明書を発行し、移行先認証局装置で証明書のシリアル番号が重複するのを回避し、証明書のシリアル番号の一貫性を保つ。

発明の効果

0030

開示の認証局装置間の移行方法は、移行元認証局装置の改造や内部仕様の開示が一切不要であり、移行先認証局装置に移行のための機能を追加するだけで実現可能である。これにより、どのような構成の認証局装置間でも移行が可能となる。今までは、証明書管理リポジトリの構成が異なる認証局装置間でリプレースを行う際には、移行先認証局装置と移行元認証局装置の両方を長期間運用しなければならず、コストや運用負荷な様々な負担があった。しかし、この開示の認証局装置の移行方法によれば、今後はその負担が削減される、という効果がある。

図面の簡単な説明

0031

実施例1のシステム構成を示す図である。
同一認証局装置での認証パスの生成を説明する図である。
異なる認証局間の認証パス生成を説明する図である。
実施例1における認証局装置間の認証パス生成を説明する図である。
同一認証局装置で鍵を更新する場合の証明書発行に関する動作と、実施例1で証明書を認証局装置間で連携させるための動作の対応関係を示す図である。
同一認証局装置で鍵を更新する場合のCRL発行に関する動作と、実施例1でCRLを認証局装置間で連携させるための動作の対応関係を示す図である。
実施例1における移行元および移行先認証局装置間での証明書、失効情報等の受け渡しの流れを説明する図である。
実施例1の全体処理フローを示す図である。
実施例1の認証局リポジトリで管理される認証局発行情報の構成を示す図である。
図6のステップS1のより詳細な説明を示すフロー図である。
図8のフローが実行される際の画面例で、新認証局を構築するか、認証局装置の移行作業を行うかを指定する画面の例である。
図8のフローが実行される際の画面例で、移行元認証局装置の証明書情報を指定する画面の例である。
図8のフローが実行される際の画面例で、移行元認証局装置の失効情報を指定する画面の例である。
移行元認証局装置が発行した証明書およびCRLから、移行先認証局装置が認証局リポジトリに情報を登録する処理について説明する図である。
図6のステップS2のより詳細な説明を示すフロー図である。
図11のフローが実行される際の画面例を示す図で、シード値を生成するための画面の例を示す図である。
図11のフローが実行される際の画面例を示す図で、鍵長を指定する際の画面の例を示す図である。
図11のフローが実行される際の画面例を示す図で、移行元認証局装置で発行したダミー証明書の指定をする画面の例を示す図である。
図11のフローが実行される際の画面例を示す図で、証明書プロファイルテンプレートに入力事項を反映する際の画面例を示す図である。
図6のステップS3のより詳細な説明を示すフロー図である。
図13のフローが実行される際の画面例を示す図で、順方向相互認証証明書の発行申請書を作成する際の画面例を示す図である。
図13のフローが実行される際の画面例を示す図で、移行先認証局装置で、順方向相互認証証明書を読み込む際の画面例を示す図である。
発行された順方向相互証明書の一例を示す図である。
図6のステップS4のより詳細な説明を示すフロー図である。
図16のフローが実行される際の画面例を示す図で、移行先認証局装置で、逆方向相互認証証明書の発行申請書を読み込む際の画面例を示す図である。
図16のフローが実行される際の画面例を示す図で、逆方向相互認証証明書が発行される際の画面例を示す図である。
発行された逆方向相互証明書の一例を示す図である。
図6のステップS5で表示される画面の一例を示す図である。
移行先認証局装置を構成する情報処理装置のハードウェア構成を示す図である。
従来の認証局装置の構成を示す図である。
同一認証局装置で鍵の更新をする場合について示す図である。
異なる認証局間で相互認証をする場合について示す図である。

0032

以下、図面を参照して、本発明の実施の形態について説明する。

0033

図1に実施例1のシステム構成を示す。
まず、移行元認証局装置2と移行先認証局装置1が存在する。
移行元認証局装置2で証明書や発行済み証明書の失効リスト(たとえばCRL)を発行した際、発行したその証明書、発行したその失効リストおよびそれぞれの発行情報等は図1には不図示の移行元認証局装置2内の認証局リポジトリに記憶されている。本実施例では移行元認証局装置2内の認証局リポジトリに記憶されているデータ等を移行先認証局装置1に移動させる際、移行元認証局装置2内の認証局リポジトリのデータを可搬型記憶媒体等に記録し、該可搬型記憶媒体等を、移行先認証局装置1を構成する情報処理装置の備える媒体駆動装置で読み出すことで、データの移動を行う。従って、図1では例えば移行元認証局装置2が発行した認証局認証書[Old RootCA Cert.]を移行先認証局装置1が直接受け取っているように描かれているが、実際には認証局の管理者等が、一方の認証局装置のデータベースからデータを可搬型記憶媒体に記録して、もう一方の認証局装置で該可搬型記録媒体からデータを読み出させる、という操作を行っている。

0034

図1に示すように、移行元認証局装置2、移行先認証局装置1はそれぞれ公開鍵(移行元:OldPublicKey(a),移行先:NewPublicKey(A))および秘密鍵(移行元:OldPrivateKey(b), 移行先:NewPrivateKey(B))を備える。

0035

また、移行先認証局装置1は、移行機能11、証明書発行機能12、CRL発行機能13、認証局リポジトリ(または、認証局管理DB。以下、認証局リポジトリと記す)14、証明書シリアル番号カウンタ15、証明書プロファイルテンプレート16、CRLシリアルカウンタ17を含む構成である。

0036

証明書発行機能12およびCRL発行機能13は、通常の認証局装置が備える機能である。認証書発行機能12は証明書を発行し、CRL発行機能13はCRLの発行を行う。
認証局リポジトリ14は、発行した証明書の情報、失効情報などをリスト状に格納し管理する。尚、認証局リポジトリ14の構成については後述するが、本実施例1では、発行した各証明書に対応する発行情報を単に「発行情報」と呼び、各発行情報に対応する各レコードからなるリストであって、該認証局リポジトリ14によって管理されるものを「認証局発行情報」(図7に例を示す)と呼ぶことにする。

0037

証明書シリアルカウンタ15は発行した証明書のシリアル番号を記憶しておくカウンタ、CRLシリアル番号カウンタ17はCRLシリアル番号を記憶しておくカウンタである。証明書プロファイルテンプレート16は、発行する証明書のプロファイルを記憶しておく記憶領域である。

0038

移行機能11は、移行のための機能であり、更に詳しくは移行元証明書の受取機能18、移行元CRLの受取機能19、認証局証明書の移行発行機能20、認証パス生成機能(順方向)21、認証パス生成機能(逆方向)22、を備える。尚、移行機能11には図1には不図示の拇印検証機能、署名検証機能、プロファイル解析機能が含まれている。これらの機能は通常の認証局装置が備えるものと同様で、移行機能11内の各機能(18〜22)が必要に応じて拇印検証機能、署名検証機能、プロファイル解析機能を使用する。
以下、移行機能11内の各機能について説明する。

0039

移行元証明書の受取機能18は、まず、移行元認証局装置2が発行した認証局証明書[Old RootCA Cert.]を読込む。認証局証明書とは、通常の証明書と同じような機能特徴を持つものであるが、該認証局証明書を発行した認証局装置が電子認証局であるという情報がその証明書の中に入っているものである。そして、移行元証明書の受取機能18は、読み込んだ認証局証明書[Old RootCA Cert.]を拇印検証機能を用いて拇印検証し、プロファイル解析機能を用いて証明書のプロファイルを抽出し、該プロファイルと、読み込んだ移行元認証局装置2の認証局証明書を認証局リポジトリ14に格納する。

0040

更に、移行元証明書の受取機能18は、証明書発行を求めたユーザ等に対して移行元認証局装置2が発行した全ての証明書[Old EE Cert.](EEはエンドエンティティの略)を読込み、署名検証機能を用いて署名検証し、解析し、認証局リポジトリ14に格納する。認証局リポジトリ14への格納については、後述するが、簡単に述べると、認証局リポジトリ14に管理されている認証局発行情報に各証明書の発行に対応するレコードを追加することによって格納が行われる。

0041

移行元CRLの受取機能19は、移行元認証局装置2が発行した最新のCRL[Old CRL]を読み込む。このとき、その他の発行済みのCRLを読み込ませてもよい。そして、移行元CRL受取機能19は、読み込んだCRLを署名検証機能を用いて署名検証する。署名検証の後、読み込んだCRLが正しいことが確認されれば、該CRLから失効する証明書のシリアル番号を抽出する。そして、認証局リポジトリ14にて管理されている認証局発行情報におけるシリアル番号と一致するレコードに対して、証明書の失効情報を登録する。この失効情報の登録についての詳細は後述する。また、最新のCRLを読み込んだ場合には、CRLのシリアル番号を抽出し、CRLシリアル番号カウンタ17に設定する。

0042

認証局証明書の移行発行機能20は、移行元認証局装置2が発行したダミー証明書[ダミー証明書]を受け取る。このダミー証明書は、通常、証明書発行を求めるユーザに対して証明書を発行するのと同様にして、移行元認証局の管理者等が移行元認証局装置2に発行させる証明書のことである。移行先認証局装置1では、該発行された証明書を認証局証明書の移行発行機能20で読み込み、署名検証機能を用いて署名検証する。そして、ダミー証明書のシリアル番号を抽出し、抽出したシリアル番号を証明書シリアルカウンタ15に設定する。また、移行元証明書の受取機能18がプロファイル解析機能を用いて抽出した認証局証明書プロファイルを証明書プロファイルテンプレート16に格納し、証明書プロファイルを設定する。そして、証明書シリアルカウンタ15に設定された値と、証明書プロファイルテンプレート16に設定されたテンプレートに基づいて移行先認証局証明書[New RootCA Cert.]を発行する。また、認証局リポジトリ14にて管理されている認証局発行情報に発行記録に対応するレコードを追加する。このように、本実施例1において移行元認証局装置2で発行されるダミー証明書によって、移行先認証局装置1で発行する認証局証明書[New Root CA Cert.]のシリアル番号が、移行元認証局装置2で今まで発行されていた証明書のシリアル番号と継続的になるようにすることができる。

0043

認証パス生成機能(順方向)21は、移行先認証局装置1で作成された順方向相互認証証明書の発行申請書に基づいて、移行元認証局装置2が発行した順方向相互認証証明書[Link/Cross Cert.2]を受け取る。上述したように「相互認証証明書」とは、異なる二つの認証局が相互に認証を行う場合に、互いの相手の認証局に対して発行される証明書のことである。ここで発行される順方向相互認証証明書は、移行元認証局装置2と移行先認証局装置1が相互認証を行うために発行するもののうち、移行元認証局装置2が移行先認証局装置1に対して発行する相互認証証明書のことをいう。そして、更にこの順方向相互認証証明書は、通常同一認証局装置で鍵を更新する際に発行されるリンク証明書と同一になるようにして発行される。本実施例1では、移行元認証局装置2は、[NewWithOld]を発行する。順方向相互認証証明書の発行者名(IssureName)と被発行者名(SubjectName)は、同一にして発行される。

0044

認証パス生成機能(順方向)21は、受け取った順方向相互認証証明書のシリアル番号を抽出し、抽出したシリアル番号を証明書シリアル番号カウンタ15に設定する。そして、証明書シリアル番号カウンタ15に基づいて、ダミー証明書[ダミー証明書]を発行し、認証局リポジトリ14にて管理されている認証局発行情報に対して発行記録に対応するレコードを追加する。そして、追加したレコードにおける証明書データ格納欄に、移行元認証局2が発行した順序方向相互認証証明書のバイナリデータを上書きする。移行先認証局装置1で発行されるダミー証明書は、通常証明書発行を求めるユーザに対して証明書を発行するのと同様にして発行される。そして、このダミー証明書の発行に対応する認証局発行情報のレコードに、移行元認証局装置2が発行した順方向相互認証証明書のバイナリデータを上書きするため、移行先認証局装置1は[NewWithOld]を保持することになる。

0045

認証パス生成機能(逆方向)22は、認証パス生成機能(順方向)21とは逆に移行先認証局装置1が相互認証証明書を発行する機能である。認証パス生成機能(逆方向)22は、移行元認証局装置2から逆方向相互認証証明書の発行申請書を受け取り、拇印検証機能を用いて拇印検証する。そして、該発行申請書の正当性が確認されると、それに基づいて逆方向相互認証証明書を発行する。逆方向相互認証証明書は、上述の順方向相互認証証明書の逆方向、つまり移行先認証局装置1が移行元認証局装置2に対して発行される相互認証証明書である。順方向相互認証証明書と同様に、リンク証明と同一になるようにして発行されるもので、移行先認証局装置1は古い公開鍵に新しい秘密鍵で署名した証明書[OldWithNew]を発行する。また、逆方向相互認証証明書の発行者名(IsuureName)と被発行者名(SubjectName)は同一である。

0046

このように、認証パス生成機能(順方向、逆方向)21、22は、同一認証局装置で古い鍵から新しい鍵に更新を行う場合に発行されるリンク証明書のように、移行元認証局装置の鍵を古い鍵、移行先認証局装置の鍵を新しい鍵として、リンク証明書相当の証明書を相互認証証明書として発行する。その際、証明書の発行者明と被発行者名は同一である。これにより、移行先認証局装置1と移行元認証局装置2は異なる認証局装置であるが、同一認証局であると認識される認証パスが生成される。

0047

以上、図1を参照して実施例1の移行先認証局装置1の構成について説明した。移行先認証局装置1は、認証局リポジトリ14の構成の異なる認証局装置間であっても、移行元認証局装置2の発行済み証明書の情報や失効情報等を移行元証明書の受取機能18および移行元CRLの受取機能19にて取り込むことが可能である。これにより、移行元認証局装置2の認証局リポジトリの構成と移行先認証局装置1のリポジトリの構成が異なっていても、移行元認証局装置が発行した証明書やCRLなどの資産を移行先認証局装置に取り込むことが可能である。また、認証局証明書の移行機能20により、移行先認証局装置1において移行元認証局装置2が発行した証明書のシリアル番号に継続するようにして認証局証明書を発行することが可能である。また、認証パス(順方向、逆方向)生成機能21、22により、移行元認証局装置2と移行先認証局装置1において同一認証局であると認識される認証パスを生成することが可能である。以上により、認証局装置の移行作業をスムーズに行うことが可能となる。

0048

更に、図1の認証パス生成機能(順方向)21、認証パス生成機能(逆方向)22での処理を分かりやすくするために、図2を参照して本実施例1における認証パスの生成について説明しておく。本実施例の認証パスの生成については、通常の場合の、同一認証局装置での認証パスの生成(同一認証局装置で鍵を更新する場合)と、異なる認証局間での認証パスの生成と、とを比較して説明すると分かりやすいため、まず通常の場合についてそれぞれ図2Aおよび図2Bを参照して説明する。その後、図2Cに、本実施例の認証パスの生成について示す。

0049

まず、通常行われる、同一認証局装置で鍵を更新する場合について図2Aに示す。図2Aにおいて、RootCAはルート認証局、[RootCA Cert.]はルート認証局証明書、[Link Cert.]はリンク証明書、[EE Cert.]はエンドエンティティ証明書(EE証明書)を示している。ここで、ルート認証局証明書は、認証局証明書のことである。またリンク証明書は、鍵の更新を行う際に発行される証明書である。またエンドエンティティ証明書は、証明書の発行を求めるユーザ等に対して発行される証明書である。

0050

ルート認証局証明書、およびリンク証明書中の発行者名(IssureName)、被発行者名(サブジェクト名、SubjectName)が同じ(A1)となっている。このように、発行者名と被発行者名が同じ場合やリンク証明の場合、認証パスはカウントされない。認証パスの階層を示す値、pathLenConstraintは0である。

0051

次に図2Bに、異なる認証局で認証ドメインを構成する場合について示す。図2Bにおいて、RootCAはルート認証局、[RootCA Cert.]はルート認証証明書、[Cross Cert.]は相互認証証明書、[EE Cert.]はエンドエンティティ証明書を示している。ここで相互認証証明書は、異なる二つの認証局が相互に認証を行う場合に、互いの相手の認証局に対して発行される証明書である。例えばRootCA1がRootCA2に発行する相互認証証明書について、発行者名と被発行者名が異なっている。このように発行者名(IssureName)と被発行者名(SubjectName)が不一致の場合、別認証局とみなされ、認証パスがカウントされる。図2Bの場合、エンドエンティティにおけるpathLenConstraintは2となる。

0052

図2Bのように、異なる認証局で認証パスを生成する場合は、通常は証明書の発行者名と被発行者名が異なるためpathLenConstraintは2となってしまい、別認証局とみなされてしまう。しかし、本実施例1においては異なる認証局装置を、同一の認証局と見なされるようにする必要があるため、次のように処理を行う。

0053

図2Cに本実施例1の認証パスの生成について示す。図2Cにおいて、[移行元認証局Cert.]は移行元認証局証明書、[移行先認証局Cert.]は移行先認証局証明書、[Link/Cross Cert. 2]は順方向相互認証証明書、[Link/Cross Cert. 1]は逆方向相互認証証明書、[EE Cert.]はエンドエンティティ証明書を示している。認証局装置は異なるが、発行者名(IsuureName)と被発行者名(SubjectName)を一致させて、リンク証明と同一となるような相互認証証明書(順方向相互認証証明書、逆方向相互認証証明書)を発行する。これにより、pathLenConstraint=0となり、移行先認証局と移行元認証局が同一認証局であると認識される認証パスが生成される。このように本実施例1では、図1に示した認証パス生成機能(順方向)21および認証パス生成機能(逆方向)22により、移行元認証局と移行先認証局が同一認証局と認識されるような認証パスが生成される。

0054

次に、図3図4図5を参照し、本実施例1における移行処理について、手順を追って説明する。
上述のように、本実施例1の認証局装置の移行は、発行された証明書だけで同一認証局装置で鍵更新を行ったように見えるように、証明書のシリアル番号等を異なる認証局装置間で連携させることにより実現する。つまり、図3の左側の表に示した、同一認証局装置での鍵更新のように認証局装置を運用する必要がある。以下に、移行先認証局装置1が行う5段階((ア)〜(オ))の処理について説明する。(尚、認証局証明書のシリアル番号は、昇順加算される認証局装置だけでなく、ランダムに採番される認証局装置もあるが、以下の説明では昇順を例に説明する。いずれの場合にも本実施例1は適用可能である。)
(ア)移行元認証局証明書(図3の右表のシリアル番号:1)
移行元認証局証明書とは、移行元認証局装置2で発行された認証局証明書のことである。図1の移行元証明書の受取機能18を使用して、正しい移行元認証局証明書を移行先認証局装置1にインポートする。より詳細には、次のように処理をする。まず、移行元証明書の拇印と移行元認証局装置が公開している拇印を比較し、取り違いがないことを確認する。次に、移行元認証局証明書のプロファイルを抽出し、移行先認証局証明書のプロファイルに適用する。そして、認証局リポジトリ14に証明書プロファイルと証明書を格納する。

0055

(イ)EE証明書(図3の右表のシリアル番号:2〜n)
図1の移行元証明書の受取機能18を使用して、証明書発行を求めたユーザに対して移行元認証局装置2が発行した全ての証明書(EE証明書、エンドエンティティ証明書)を移行先認証局装置1にインポートする。より詳細には、次のように処理をする。まず、全証明書が格納されている格納場所(指定されたフォルダなど)から、連続的にEE証明書を読込み、これらの証明書が(ア)で取り込んだ移行元認証局装置2にて署名されたものかどうか、署名検証を行い、不適切な証明書が混入しないように処理をする。証明書プロファイルを抽出し、EE証明書と共に認証局リポジトリ14に格納する。

0056

(ウ)移行先認証局証明書(図3の右表のシリアル番号:n+1)
図1の認証局証明書の移行発行機能20を使用して、移行元認証局装置2で発行されたダミー証明書のシリアル番号にて、移行先認証局装置1で移行先認証局証明書を発行する。より詳細には次のように処理をする。まず、移行先認証局装置1はダミー証明書を受け取り、該ダミー証明書が移行元認証局装置2で発行されたことを署名検証で確認する。次に、ダミー証明書のプロファイルからシリアル番号を抽出し、証明書シリアル番号カウンタ15に設定する。(ア)で取り込んだ移行元認証局証明書のプロファイルを証明書プロファイルテンプレート16に設定する。そして、証明書シリアル番号カウンタ15と証明書プロファイルテンプレート16に基づいて、移行先認証局証明書を発行する。

0057

(エ)リンク証明書(図3の右表のシリアル番号:n+2)
図1の認証パス生成機能(順方向)21を使用して、移行元認証局装置2に順方向相互認証証明書を発行させる。より詳細には次のように処理をする。まず、移行先認証局装置1で作成された順方向相互認証証明書発行申請書に基づいて、移行元認証局装置2で順方向相互認証証明書が発行される。そして、移行先認証局装置1は、該順方向相互認証証明書が移行元認証局装置2で発行されたことを署名検証で確認してから取り込む。移行先認証局装置1では順方向相互認証証明書のシリアル番号を抽出し、抽出したシリアル番号を証明書シリアル番号カウンタ15に設定する。証明書シリアル番号カウンタ15に基づいて、ダミー証明書を発行し、認証局リポジトリ14にて管理されている認証局発行情報に対してレコードを追加する。そして、追加したレコードにおける証明書データ格納欄に、移行元認証局装置2が発行した順方向相互認証証明書のバイナリデータで上書きする。これにより、順方向相互認証証明書は、上述したようにリンク証明書と同一になるように発行されているため、移行先認証局装置1内でリンク証明書を保持することと同一になる。

0058

(オ)リンク証明書(図3の右表のシリアル番号:n+3)
図1の認証パス生成機能(逆方向)22を使用して、移行元認証局装置2からの逆方向相互認証証明書の発行申請書を受け取り、移行先認証局装置1で逆方向相互認証証明書を発行する。上述したように逆方向相互認証証明書はリンク証明書と同一になるように発行される。

0059

以上の(ア)〜(オ)の5段階の処理の後、移行元認証局装置2は速やかにシステムを停止し破棄され、移行先認証局装置1は通常運用を開始する(図3の右表のシリアル番号:n+4〜)。

0060

さて、図3では、証明書のシリアル番号やプロファイルを、認証局装置間で連携させることについて説明したが、次に図4を参照し、移行元のCRLのシリアル番号や証明書の失効状態を、移行元・移行先認証局装置間で連携させることについて説明する。本実施例1では、移行元認証局装置の失効情報を移行先認証局装置に取り込むことで、二つの認証局装置間で認証書の有効性に矛盾が生じないようにしている。その際、認証局装置の運用には以下の3段階(ア)〜(ウ)がある。以下の(ア)〜(ウ)の処理は図1の移行元CRLの受取機能19にて処理される。(尚、CRLのシリアル番号は、昇順に加算される認証局装置だけでなく、ランダムに採番される認証局装置もあるが、以下の説明では昇順を例に説明する。いずれの場合にも本実施例1は適用可能である。)
(ア)移行元認証局装置での運用期間図4の右表のCRLのシリアル番号:1〜n−1)
移行元認証局装置2の正しいCRLを移行先認証局装置1にインポートする。より詳細には次のように処理する。CRLが格納されている格納場所(指定されたフォルダなど)から連続的にCRLを読込み、これらのCRLが移行元認証局2にて署名されたものかどうか、署名検証を行い、不適切なCRLが混入しないように処理する。そして、CRLプロファイルから失効リストを取り出し、失効する証明書のシリアル番号を抽出し、認証局リポジトリ14にて管理されている認証局発行情報におけるシリアル番号と一致するレコードに対して、証明書の失効情報として登録する。

0061

(イ)移行元認証局での運用期間(図4の右表のCRLシリアル番号:n)
最新のCRLを(ア)同様に取り込む。そして更に、最新のCRLのシリアル番号を抽出し、CRLシリアル番号カウンタ17に設定する。

0062

(ウ)移行先認証局装置での運用期間(図4の右表のCRLシリアル番号:n+1〜)
上記(ア)(イ)の処理の後、移行元認証局装置2は速やかにシステムを停止し破棄され、移行先認証局装置1では通常運用が開始され、CRLを発行する際にはCRLシリアル番号カウンタ17の値に1を加算してからCRLを発行する。

0063

以上のように図3図4を参照して、本実施例1における認証局装置移行の際の動作について説明したが、その全体の流れを概略的にまとめたものが図5である。図5における(1)〜(10)および(あ)〜(う)はそれぞれ図3図4中に記載した(1)〜(10)、(あ)〜(う)に対応している。説明が重複するが、再度簡単に説明すると以下のようになる。

0064

まず図5の(1)〜(10)について説明する。
図5の(1)では移行元認証局装置2の認証局証明書[Old RootCA Cert.]を移行先認証局装置1にインポートする。この際、移行元証明書の受取機能18は、拇印検証機能51を用いて移行元認証局証明書の拇印検証を行う。また、移行元認証局証明書のプロファイルを抽出し、移行先認証局のプロファイルに適用する。そして、認証局リポジトリ14に証明書プロファイルと証明書を格納するとともに、認証局リポジトリ14が管理する認証局発行情報にレコードを登録する。

0065

図5の(2)では、証明書発行を求めたユーザに対して移行元認証局装置2が発行した全ての証明書(EE証明書、エンドエンティティ証明書) [Old EE Cert.]を移行先認証局装置1にインポートする。この際、移行元証明書の受取機能18は、署名検証機能52を用いて全証明書が移行元認証局装置2にて署名されたものかを署名検証する。そして証明書プロファイルを抽出し、認証局リポジトリ14に格納するとともに、認証局リポジトリ14が管理する認証局発行情報に、各証明書に対応するレコードを追加していく。

0066

図5の(3)では移行元認証局装置2が、ダミー証明書[ダミー証明書]を発行する。
図5の(4)では、移行先認証局装置1の認証局証明書の発行機能20が、署名検証機能52を用いて移行元認証局装置2が発行したダミー証明書を署名検証してから取り込み、該ダミー証明書のシリアル番号を抽出し、そのシリアル番号を証明書シリアル番号カウンタ15に設定する。そして、図5(1)で取り込んだ移行元認証局証明書のプロファイルと同じプロファイルで移行先認証局証明書[New RootCA Cert.]を発行する。また、認証局リポジトリ14が管理する認証局発行情報に発行記録としてのレコードを追加する。
図5の(5)では、移行先認証局装置1が順方向相互認証証明書発行申請書を作成する。
図5の(6)では、移行元認証局装置2で、順方向相互認証証明書[Link/Cross Cert.2]が発行される。

0067

図5の(7)では、認証パス生成機能(順方向)21が、署名検証機能52を用いて順方向相互認証証明書を署名検証した後、取り込み、順方向相互認証証明書のシリアル番号を抽出し、抽出したシリアル番号を証明書シリアル番号カウンタ15に設定する。

0068

図5の(8)では、証明書シリアル番号カウンタ15に基づいてダミー証明書[ダミー証明書]を発行し、認証局リポジトリ14にて管理されている認証局発行情報に対してレコードを追加する。そして、追加したレコードにおける証明書データ格納欄に、移行元認証局装置2が発行した順方向相互認証証明書のバイナリデータを上書きする。

0069

図5の(9)では、移行元認証局装置2が逆方向相互認証証明書の発行申請書を作成する。
図5の(10)では、認証パス生成機能(逆方向)22が、逆方向相互認証証明書の発行申請書を、拇印検証機能51を用いて拇印検証した後取り込み、移行先認証局装置1で逆方向相互認証証明書[Link/Cross Cert.1]を発行する。そして、認証局リポジトリ14にて管理されている認証局発行情報に対してレコードを追加する。

0070

次に(あ)〜(う)について説明する。
図5の(あ)では、移行元CRLの受取機能19が、署名検証機能52を用いて移行元認証局2が発行したCRLを署名検証して、不適切なCRLが混入しないようにする。そして、CRLプロファイルから失効リストを取り出し、失効する証明書のシリアル番号を抽出し、認証局リポジトリ14にて管理されている認証局発行情報におけるシリアル番号と一致するレコードに対して、証明書の失効情報として登録する。

0071

図5の(い)では移行元認証局2で最新のCRLが発行される。
図5の(う)では、図5の(あ)と同様にCRLを移行先認証局1にインポートするが、さらにCRLのシリアル番号を抽出し、該CRLのシリアル番号をCRLシリアル番号カウンタ17に設定する。

0072

以上のように、本実施例1の構成、動作の概略について図1図5を参照して説明したが、以下にフロー図を参照して全体処理の流れについて説明する。
まず図6に本実施例1の全体処理フローを示す。

0073

まず、ステップS1で認証局資産の移行を行う。移行元認証局装置2では、通常運用を停止し、認証局証明書、発行済みの全ての証明書(エンドエンティティ証明書)とその数、移行元認証局装置2での最新のCRL,または発行済みのその他のCRLなどのデータを例えば記憶媒体に記録するなどして、移行の準備を行う。そして該記憶媒体のデータを、移行先認証局装置を構成する情報処理装置で読み出すなどして、移行先認証局装置1の認証局リポジトリ14にインポートする。このステップS1は、図5の(1)、(2)および(あ)、(い)、(う)の処理に対応する。

0074

ここで、ステップS1で移行先認証局装置1の認証局リポジトリ14に移行元認証局装置2の証明書や失効情報を格納(インポート)する処理について、図7を参照してより詳しく説明する。図7は、認証局リポジトリ14で管理される認証局発行情報の構成を示すものである。認証局発行情報の各レコードは、証明書のシリアル番号、証明書の種別、証明書の被発行者名(サブジェクト名、SubjectName)、証明書の発行者名、有効期間(開始日時、満了日時)、証明書データを含み、更に、各証明書の失効日時、失効理由を含んで構成される。

0075

ステップS1での認証局資産移行の際、まず移行元証明書の受取機能18が取り込んだ認証局証明書(der/cerファイル)を認証局リポジトリ14に格納する。このとき、該証明書のシリアル番号、種別、被発行者名、発行者名、有効期間、証明書データを図7のIで示した部分にそれぞれ格納する。次に、移行元証明書の受取機能18は、証明書発行を求めたユーザに対して移行元認証局装置2が発行した全ての証明書(EE証明書、エンドエンティティ証明書)を取り込み、認証局リポジトリ14に格納する。このとき、各証明書について認証局証明書のときと同様に、証明書のシリアル番号、種別、被発行者名、発行者名、有効期間、証明書データを図7のIIで示した部分にそれぞれ格納する。更に次に、移行元CRLの受取機能19により、移行元が発行した最新のCRLを取り込む。このとき、CRLから失効する証明書のシリアル番号を抽出し、すでに登録されている認証局発行情報における証明書のシリアル番号と一致するレコードについて失効日時と失効理由を登録する(図7のIII)。また最新のCRL以外にも既に発行されているCRLを取り込んでもよく、その場合には最新のCRLと同様に、失効する証明書のシリアル番号を抽出し、すでに登録されている認証局発行情報における証明書のシリアル番号と一致するレコードについて失効日時と失効理由を登録する(図7のIV)。

0076

図6に説明を戻す。次にステップS2で移行先認証局証明書の発行を行う。このステップS2は、図5の(3)、(4)に対応する。まず、移行元認証局装置2でダミー証明書を発行し、それを認証局証明書の移行発行機能20により取り込み、そのシリアル番号で移行先認証局証明書を発行する。このとき、移行先認証局証明書の発行記録として、認証局リポジトリ14で管理される認証局発行情報に、シリアル番号(n+1)のレコードを追加する(図7の(ii)のレコード)。

0077

次に図6のステップS3で、順方向の認証パスを生成する。このステップS3は、図5の(5)、(6)、(7)、(8)に対応する。まず、移行先認証局装置1にて順方向相互認証証明書の発行申請書を作成し、移行元認証局装置2の認証パス生成機能(順方向)21にて順方向相互認証証明書の発行を行う。移行先認証局装置1では、将来、この順方向相互認証証明書と同じシリアル番号で証明書を発行しないために、予めこのシリアル番号にてダミー証明書を発行する。そしてこのダミー証明書の発行記録として、認証局リポジトリ14で管理される認証局発行情報に、シリアル番号(n+2)のレコードが追加される(図7の(iii)のレコード)。そして、この追加されたレコードのうち証明書データ欄に、移行元認証局装置2で発行された順方向相互認証証明書の証明書データ(証明書自身のデータで、バイナリデータ)を上書きする(図7の※2)。これにより移行先認証局装置1内で移行元認証局装置2で発行された順方向相互認証証明書を保持することになる。

0078

次に図6のステップS4で、逆方向の認証パスを生成する。このステップS4は、図5の(9)、(10)に対応する。まず、移行元認証局装置2にて逆方向相互認証証明書の発行申請書を作成し、移行先認証局装置1の認証パス生成機能(逆方向)22にて逆方向相互認証証明書の発行を行う。この発行記録として、認証局リポジトリ14で管理される認証局発行情報には、シリアル番号(n+3)のレコードが追加される(図7の(iv)のレコード)。

0079

その後、図6のステップS5で、移行元認証局装置2のシステム廃棄を速やかに行い、証明書やCRLを発行しないようにする。
そして、図6のステップS6で、通常運用を再開する。すなわち移行先認証局装置1で、移行元認証局装置2が既に発行した証明書に対する失効や、CRLの発行を行うとともに、新たな証明書の発行も行い、通常運用を再開する。新たな証明書の発行に合わせて、認証局リポジトリ14には、シリアル番号(n+4)以降のレコードが順次追加されていく(図7の(vi))。

0080

以上のように、図6に本実施例1における全体処理フローを説明したが、更に各ステップについて以下に詳細に説明する。
まず図8図6のステップS1の詳細フローを示す。

0081

図8のステップS80で移行先認証局装置1において、CA(Certificate Authority)初期設定ウィザードを用いて、移行元認証局装置2の証明書情報等を入力する。CA初期設定ウィザードは、認証局装置を新たに構築する際などに用いられるソフトウェアツールであるが、本実施例1ではこのツールを拡張する形で利用する。この画面例を、図9A図9Cに示す。

0082

図9Aは、CA初期設定ウィザードにおいて、新しい認証局装置を構築するか、または認証局装置の移行であるかを選択する画面例である。実施例1では、認証局装置の移行作業を行うため、「移行」を選択している。図9Bは、移行元認証局装置2の証明書情報の指定をする画面例である。移行元認証局装置2から記憶媒体などに記録して取り出された証明書等のデータを、一旦、移行先認証局装置1を構成する情報処理装置のローカルハードディスクなどにコピーするとする。図9Bでは、移行元認証局証明書の存在場所(c:\OldCaCert.cer)、移行元認証局証明書の拇印、移行元の全証明書発行枚数(100000枚)、移行元の全証明書が格納されているフォルダ(c:\OldCerts)を指定している。図9Cは、移行元認証局装置2の失効情報の指定をする画面例である。移行元認証局装置2のCRLが格納されているフォルダ(c:\OldCRL)、移行元認証局装置2が発行した最新CRL(c:\LastCrl.crl)を指定している。

0083

このように図8のステップS80では、図9A図9Cのように移行元認証局装置2の証明書に関する情報を移行先認証局装置1に入力する。
次に、図8のステップS81で、移行元証明書の受取機能18が、トラストポイント(信頼点)として移行元認証局証明書を読込み、その拇印と比較して正しいことが確認できたら認証局リポジトリ14に登録する。

0084

更に、図8のステップS82で、移行元証明書の受取機能18は、証明書発行を求めたユーザ等に対して移行元認証局装置2が発行した全ての証明書(EE証明書、エンドエンティティ証明書)を読み込む。ステップS83で、読み込んだ証明書が移行元認証局装置2で発行されたことが署名検証で確認できるか否か、証明書の総数が画面で入力した証明書発行枚数と一致するか否かを判断する。ステップS83で、移行元認証局装置2で発行されたことが署名検証で確認できない場合や、証明書の総数が入力された証明書発行枚数と一致しない場合(エラー)にはステップS89に進み、資産移行が失敗したとして、処理を終了する。ステップS83でエラーが発生しなかった場合には、ステップS84に進み、証明書を認証局リポジトリ14に登録する。

0085

ここで、ステップS81およびステップS84で行われる証明書の認証局リポジトリ14への登録について図10を参照して説明する。
図10には証明書のフォーマットの一例を示す。証明書は、バージョン情報(version),シリアル番号(serialNumber)、署名アルゴリズム情報(signature.algorithmIdentifier)、発行認証局名(issureName)、有効期限(validity)の開始日時(notBefore)および満了日時(notAfter)、被発行者名(subjectName)、サブジェクト鍵識別子(subjectKeyIdentifire)、認証局鍵識別子(authorityKeyIdentifire)を含んで発行される。移行先認証局装置1の移行元証明書の受取機能18は、各証明書を読込み、解析して、図10の矢印で示すように、証明書の各情報を認証局リポジトリ14に管理されている認証局発行情報にレコードを追加していく。すなわち、証明書のシリアル番号(serialNumber)を認証局発行情報のシリアル番号に、証明書の発行認証局名(issureName)を認証局発行情報の発行者名に、証明書の有効期間開始日時(notBefore)を認証局発行情報の有効期間開始日時に、証明書の有効期間満了日時(notAfter)を認証局発行情報の有効期間満了日時に、証明書の被発行者名(subjectName)を認証局発行情報の被発行者名の欄に登録し、更に証明書自身のバイナリデータを認証局発行情報の証明書データとして該当欄に登録する。

0086

図8の説明に戻ると、次にステップS85で、移行元CRLの受取機能19は、移行元認証局装置2のCRLを格納フォルダから読み出す。そして、ステップS86で、読み込んだCRLが移行元認証局装置2で発行されたか否かを署名検証により確認する。ステップS86で、読み込んだCRLが移行元認証局2で発行されたことが確認されなかった場合(エラー)、ステップS89に進み、資産移行失敗として処理を終了する。ステップS86で、読み込んだCRLが移行元認証局装置2で発行されたことが確認された場合には、ステップS87に進む。ステップS87では、CRLから失効リストを取り出し、失効する証明書のシリアル番号を抽出し、認証局リポジトリ14にて管理されている認証局発行情報におけるシリアル番号と一致するレコードに対して、証明書の失効情報として、失効日時および失効理由を登録する。

0087

ここで再度図10を参照して、ステップS87で行われる失効情報の登録について説明する。
図10にはCRLのフォーマットの一例を示す。CRLは、バージョン情報(version)、署名アルゴリズム情報(signature.algorithmIdentifier)、発行認証局名(issureName)、本CRL発行日時(thisUpdate)、次回CRL発行日時(NextUpdate)、失効する証明書のシリアル番号と廃棄日時の対の集合(RevokedCertificates)、失効理由、CRLオプショナルフィールド(CRLExtentions)を含んで発行される。移行元CRLの受取機能19は、CRLを読込み、失効する証明書のシリアル番号と廃棄日時の対の集合(RevokedCertificates)のうちの、失効証明書のシリアル番号(userCertificate)を抽出し、認証局リポジトリ14の認証局発行情報に登録されているシリアル番号と一致するものに対して、CRLの、CAが失効を処理した日(revocationDate)、および失効理由(CRLreason)を登録する。

0088

図8の説明に戻ると、ステップS87の後、ステップS88で、最新のCRLについてはそのシリアル番号に1加えた数を、移行先認証局1のCRLシリアル番号カウンタ17の初期値(次回のCRLの発行時のCRLシリアル番号とする)として設定する。尚、CRLのシリアル番号は、図10に示したCRLフォーマットのCRLオプショナルフィールドにcRLNumberとして格納されている値を用いる。

0089

以上、図6のステップS1の処理について詳細に説明したが、上述の説明からも分かるように図8のステップS81〜ステップS84は移行元証明書の受取機能18が実行する処理であり、図8のステップS85〜ステップS88は移行元CRLの受取機能19が実行する処理である。

0090

次に、図6のステップS2の処理について図11に詳細フローを示す。尚、この移行先認証局証明書を発行する処理は、認証局証明書の移行発行機能20が実行する処理である。

0091

まず図11のステップS111で、移行先認証局装置1においてCA初期設定ウィザードを用いて、移行先認証局証明書の鍵ペア生成に必要な「乱数シード」値をユニーク性が確保できる方法で作成する。ユニーク性が確保できる方法とは、たとえば、マウス操作により作図を行い、その軌跡座標値からシード値を生成する方法などである。この際の画面例を図12Aに示す。

0092

次に、図11のステップS112で、作成されたシード値を使用して、CA初期設定ウィザードで指定された「鍵長」で鍵ペア(公開鍵と秘密鍵)を生成する。尚、この際の鍵長を指定するCA初期設定ウィザードの画面例を図12Bに示す。図12Bでは鍵長を4096bitに指定している。

0093

そして、図11のステップS113で、認証局リポジトリ14から移行元認証局証明書を読み出し解読し、そのプロファイルを移行先認証局証明書の初期値(証明書プロファイルテンプレート16に設定)とする。

0094

次に、図11のステップS114で、図12Cに示す画面例のようにCA初期設定ウィザードで指定された場所(c:\OldDummy.cer)からダミー証明書を読み出し、該ダミー証明書が移行元認証局装置2で発行されたことを署名検証で確認する。S114でダミー証明書が移行元認証局装置2で発行されたことが確認されない場合(エラー)、S118に進み、移行元認証局証明書の発行失敗として処理を終了する。S114でダミー証明書が移行元認証局装置2で発行されたことが確認された場合(OK),S115に進む。

0095

図11のステップS115では、ダミー証明書のシリアル番号を、証明書シリアル番号カウンタ15に設定し、証明書プロファイルテンプレートのシリアル番号として変更する。

0096

次に、図11のステップS116で、図12Dに示す画面例のように、CA初期設定ウィザードで入力された、鍵ペア、有効期間、公開鍵アルゴリズム、署名アルゴリズムを、証明書プロファイルテンプレートに反映する。

0097

そして、図11のステップS117で、証明書プロファイルテンプレート16に設定された情報に基づき、移行先認証局証明書を発行する。尚、このとき、証明書の発行記録として認証局リポジトリ14に管理されている認証局発行情報に、対応するレコードを追加する。

0098

以上、図6のステップS2の処理を詳細に説明したが、次に図6のステップS3の処理を詳細に説明する。尚、この認証パス(順方向)を生成する処理は、認証パス生成機能(順方向)21が実行する処理である。

0099

図13図6のステップS3の詳細なフローを示す。まず、ステップS131で、図14Aに示す画面例のように、CA初期設定ウィザードにて、順方向相互認証証明書の発行申請書の設定(署名アルゴリズム:sha1withRSAEncryption,申請書のファイル名:c:\NewCaCrossCerReq.txt)を入力し、順方向相互認証証明書の発行申請書を作成する。

0100

図13のステップS132で、移行先認証局装置1で作成された発行申請書を、移行元認証局装置2の管理者に提供し、その発行申請書に基づいて移行元認証局装置2で発行された順方向相互認証証明書を移行先認証局装置1の管理者が受け取る。順方向相互認証証明書の一例を図15に示す。図15は、一般的な認証証明書のフォーマットのうち、順方向相互認証証明書の特徴を示すデータについてのみ示している。ここで発行される順方向相互認証証明書は、version=V3, serialNmuber=n+2,署名アルゴリズム=sha1withRSAEncription、発行認証局名(IssuerName)=A1,有効期限=2009/1/2/0:00-2010/1/1/0:00、被発行者名(SubjectName)=A1,サブジェクト鍵識別子=A, 認証局鍵識別子=a、となっており発行者名(IsuuerName)、被発行者名(サブジェクト名、SubjectName)が同一な順方向相互認証証明書を発行している。

0101

図13のステップS133で、管理者は図14Bに示す画面例のように、順方向相互認証証明書の格納場所(c:\NewCaCrossCertReq.p7c)をCA初期設定ウィザードにて指定し、移行先認証局装置1で順方向相互認証証明書を読み込む。

0102

そして、図13のステップS134で、移行元認証局装置2が発行した順方向相互認証証明書であるか否かを署名検証で確認する。ステップS134で、順方向相互認証証明書が移行元認証局装置2で発行されたものでないと判断された場合(エラー)、ステップS137に進み、認証パスの生成失敗として処理を終了する。ステップS134で、順方向相互認証証明書が移行元認証局装置2で発行されたものと判断された場合(OK)、ステップS135に進む。

0103

図13のステップS135で、順方向相互認証証明書のシリアル番号を抽出し、これを証明書シリアル番号カウンタ15に設定したうえで、このシリアル番号でダミー証明書を発行する。またその発行に対応するレコードを認証局リポジトリ14の管理する認証局発行情報に追加する。

0104

そして図13のステップS136で、ステップS135で認証局リポジトリ14に追加したレコードにおける証明書データ欄(図7参照)部分に、移行元認証局装置2が発行した順方向相互認証証明書のバイナリデータを上書きする。

0105

以上、図6のステップS3の処理を詳細に説明したが、次に図6のステップS4の処理を詳細に説明する。尚、この認証パス(逆方向)を生成する処理は、認証パス生成機能(逆方向)22が実行する処理である。

0106

図16に、図6のステップS4の詳細なフローを示す。まずステップS161で、移行元認証局装置2で作成された逆方向相互認証証明書の発行申請書を、移行元認証局装置2の管理者から受け取る。そして、図17Aに示す画面例のように、発行申請書の格納場所(c:\OldCaCrossCertReq.txt)をCA初期設定ウィザードにて指定し、移行先認証局装置1で逆方向相互認証証明書の発行申請書を読み込む。

0107

次に、図16のS162で、図17Bに示す画面例のように、逆方向相互認証証明書の発行が指示され、移行先認証局装置1で逆方向相互認証証明書を発行する。尚、このとき、証明書の発行記録として、認証局リポジトリ14に管理されている認証局発行情報に、対応するレコードが追加される。

0108

逆方向相互認証証明書の一例を図18に示す。図18は、一般的な認証証明書のフォーマットのうち、逆方向相互認証証明書の特徴を示すデータについてのみ示している。ここで発行される逆方向相互認証証明書は、version=V3, serialNmuber=n+3,署名アルゴリズム=sha1withRSAEncription、発行認証局名(IssuerName)=A1,有効期限=2009/1/3/0:00-2019/1/1/0:00、被発行者名(SubjectName)=A1,サブジェクト鍵識別子=a, 認証局鍵識別子=A、となっており発行者名(IsuuerName)と被発行者名(サブジェクト名、SubjectName)が同一であり、更に、図15に示した順方向相互認証証明書の発行者名、被発行者名とも同一となっている。このように、移行元認証局装置と移行先認証局装置が発行者名(IssureName)と被発行者名(SubjectName)が同一である相互認証証明書を双方の認証局装置が発行することにより、双方の認証局装置が同一認証局装置であると認識される認証パスが生成される。

0109

以上、図6のステップS4の処理を詳細に説明したが、最後に図6のステップS5について説明する。ステップS5では、移行先認証局装置1の画面に図19に示すようなメッセージ(「移行元認証局から移行先認証局への移行処理が完了しました。移行元認証局は停止させ、速やかにシステム破棄してください。」)が表示される。これにより、管理者は移行元認証局装置2を廃棄する。そして図6のステップS6で、認証局システムの通常運用が再開する。

0110

以上、実施例1について図面を参照しながら説明してきたが、上述の認証局装置を実現する情報処理装置200のハードウェア構成を図20に示す。
情報処理装置200は、CPU201、メモリ202、入力装置203、出力装置204、外部記録装置205、媒体駆動装置206を含み、これらがバス208で接続される構成である。

0111

メモリ202は、たとえば、ROM(Read Only Memory),RAM(Random Access Memory)等を含み、認証局装置を実現するためのプログラムやデータを格納する。

0112

CPU201は、メモリ202を使用して図6図8図11図13図16等に示したフローを実現したプログラムを実行することにより認証局装置を構成する。
入力装置203は、例えば、キーボードポインティングデバイスタッチパネル等であり、情報の入力等に用いられる。出力装置204は、例えばディスプレイプリンタ等である。

0113

外部記憶装置205は、例えば磁気ディスク装置光ディスク装置光磁気ディスク装置等である。この外部記憶装置205に、プログラムとデータを保存しておき、必要に応じて、それらをメモリ202上にロードして使用する。この外部記憶装置205は、認証局装置の認証局リポジトリ14を含むものである。また、移行元認証局装置2の認証局リポジトリのデータ等を記録した可搬記録媒体207を、移行先認証局装置1の媒体駆動装置206で読み出し、データを一旦この外部記憶装置205に格納してから、管理者の設定入力の後、認証局発行情報が格納される。

0114

媒体駆動装置206は、可搬記録媒体207を駆動し、その記録内容アクセスする。可搬記録媒体207としては、メモリカードメモリスティックフレキシブルディスク、CR−ROM(Compact Disc Read Only Memory)、光ディスク光磁気ディスク、DVD(Digital Versatile Disk)等、任意のコンピュータ読み取り可能な記録媒体が用いられる。

0115

以上、実施例1について詳細に説明した。認証局を運営している事業者で、認証局装置製品も自主開発しているところは稀であり、多くはベンダが販売している認証局装置製品を購入して認証局を運用している。しかし、民間企業が提供している製品である以上、10〜20年先も同一製品が提供され、ハードリプレースの都度、同一認証局装置として移行が継続できるとは限らない。そこで、上述した移行機能を移行時に存在する認証局装置製品に搭載することで、常に認証局装置の移行が可能となる。上述の実施例ではでは、移行元の認証局装置製品には一切の改造や内部仕様の開示を行うことなく、移行先の認証局装置製品に移行機能を追加することで実現できるため、移行元の認証局装置製品のインターフェース等が非公開の場合でも実現可能である。今までは別製品の認証局装置をリプレースする際には移行先である新認証局装置と移行元である旧認証局装置の両方を長期間運用しなければならず、コストや運用負荷などさまざまな負担があったが、その負担が今後は削減されるという効果がある。

0116

以上のように説明してきたが、本発明は上記実施例に記載したことに限定されないことは言うまでもない。上記実施例では、相互認証証明書を移行元認証局装置および移行先認証局装置間で発行する場合に移行先認証局装置から申請したが、逆に移行元認証局装置から申請するように実施してもかまわない。また、移行先認証局装置の認証局リポジトリの構成として図7の構成を示したが、上述したような動作を認証局装置が行えるような構成であればいずれの構成でもよく、この構成に限定されない。このように、本発明の趣旨を逸脱しない範囲において様々な変更が可能である。

実施例

0117

以上の実施例を含む実施形態に関し、更に以下の付記を開示する。
(付記1)
証明書管理リポジトリの構成が異なる認証局装置間において、移行元認証局装置の資産を移行先認証局装置に移行するための方法であって、
前記移行先認証局装置が、前記移行元認証局装置が発行した認証局証明書およびエンドエンティティ証明書を読み込んで解析して認証局発行情報を作成し、更に、該移行元認証局装置が発行した最新の、失効した証明書のリストを読み込んで解析して、該認証局発行情報に失効情報を追加し、
前記移行元認証局装置および前記移行先認証局装置が、発行者名と被発行者名が同一の証明書であって、移行元認証局装置の鍵を該古い鍵、移行先認証局装置の鍵を該新しい鍵とした相互認証証明書を発行する、
ことを特徴とする認証局装置移行方法。
(付記2)
証明書管理リポジトリの構成が異なる認証局装置間で移行元認証局装置の資産の移行を行うために、移行先認証局装置を構成する情報処理装置を、
前記移行元認証局装置が発行した認証局証明書およびエンドエンティティ証明書を、読み込んで解析して、前記移行先認証局装置固有の認証局発行情報を作成し、該移行元認証局装置が発行した最新の、失効した証明書のリストを読込んで解析して、該認証局発行情報に失効情報を追加する、資産移行手段と、
移行作業開始後に前記移行元認証局で発行されたダミー証明書のシリアル番号にて前記移行先認証局装置の認証局証明書を発行するとともに、前記認証局発行情報に発行記録としてのレコードを追加する、移行先認証局証明書発行手段と、
順方向相互認証証明書発行申請書を作成し、前記移行元認証局で発行された順方向相互認証証明書を取り込み、前記認証局発行情報に該順方向相互認証証明書に対応するレコードを追加する、順方向認証パス生成手段と、
前記移行元認証局で作成された逆方向相互認証証明書発行申請書に基づいて、前記順方向相互認証証明書に対応する逆方向相互認証証明書を発行するとともに、前記認証局発行情報に発行記録としてのレコードを追加する、逆方向認証パス生成手段と、
して機能させるための認証局装置移行プログラム
(付記3)
前記認証局発行情報は、証明書のシリアル番号、証明書の種別、証明書の被発行者名、証明書の発行者名、有効期間、証明書バイナリデータをそれぞれ格納する欄を含むレコードをリスト状にして構成されるもので、
前記資産移行手段は、前記読み込んだ認証局証明書および全てのエンドエンティティ証明書から、証明書のシリアル番号、証明書の被発行者名、証明書の発行者名、有効期間をそれぞれ抽出し、対応する前記認証局発行情報のレコードの前記格納欄にそれぞれ格納し、前記認証局発行情報のレコードの証明書バイナリデータ格納欄には前記認証局証明書および全てのエンドエンティティ証明書のそれぞれの証明書自身のバイナリデータをそのまま格納することを特徴とする付記2記載の認証局装置移行プログラム。
(付記4)
前記認証局発行情報のレコードは、証明書の失効日時、失効理由を格納する欄を更に含んで構成され、
前記資産移行手段は、前記認証局発行情報における証明書のシリアル番号と、前記失効した証明書のリストから得られた失効する証明書のシリアル番号が一致するレコードについて、失効日時と失効理由を追加することを特徴とする付記3記載の認証局装置移行プログラム。
(付記5)
前記順方向相互認証証明書は、前記移行元認証局装置から前記移行先認証局装置に宛てて発行される相互認証証明書であり、
前記逆方向相互認証証明書は、前記移行先認証局装置から前記移行元認証局装置に宛てて発行される相互認証証明書であり、
更に、前記順方向相互認証証明書および前記逆方向相互認証証明書は、発行者名と被発行者名が同一の証明書であり、同一認証局装置で古い鍵から新しい鍵に更新を行う場合に発行されるリンク証明書のように、前記移行元認証局装置の鍵を該古い鍵、前記移行先認証局装置の鍵を該新しい鍵として発行される該リンク証明書相当の証明書であることを特徴とする付記2記載の認証局装置移行プログラム。
(付記6)
前記順方向認証パス生成手段は、前記順方向相互認証証明書を取り込むのに合わせてダミー証明書を発行し、前記移行先認証局装置で証明書のシリアル番号が重複するのを回避することを特徴とする付記2乃至付記5いずれか一項に記載の認証局装置移行プログラム。
(付記7)
証明書管理リポジトリの構成が異なる認証局装置間で移行元認証局の資産の移行を行う際の移行先側の認証局装置であって、
前記移行元認証局装置が発行した認証局証明書およびエンドエンティティ証明書を、読み込んで解析して、前記移行先認証局装置固有の認証局発行情報を作成する移行元証明書の受取手段と、
前記移行元認証局装置が発行した最新の、失効した証明書のリストを読み込んで解析して、前記認証局発行情報に失効情報を追加する移行元失効情報の受取手段と、
移行作業開始後に前記移行元認証局で発行されたダミー証明書のシリアル番号にて前記移行先認証局装置の認証局証明書を発行するとともに、前記認証局発行情報に発行記録としてのレコードを追加する、認証局証明書の移行発行手段と、
順方向相互認証証明書発行申請書を作成し、前記移行元認証局で発行された順方向相互認証証明書を取り込み、前記認証局発行情報に該順方向相互認証証明書に対応するレコードを追加する、順方向認証パス生成手段と、
前記移行元認証局で作成された逆方向相互認証証明書発行申請書に基づいて、前記順方向相互認証証明書に対応する逆方向相互認証証明書を発行するとともに、前記認証局発行情報に発行記録としてのレコードを追加する、逆方向認証パス生成手段と、
を含むことを特徴とする認証局装置。
(付記8)
前記認証局発行情報は、証明書のシリアル番号、証明書の種別、証明書の被発行者名、証明書の発行者名、有効期間、証明書バイナリデータをそれぞれ格納する欄を含むレコードをリスト状にして構成されるもので、
前記移行元証明書の受取手段は、前記読み込んだ認証局証明書および全てのエンドエンティティ証明書から、証明書のシリアル番号、証明書の被発行者名、証明書の発行者名、有効期間をそれぞれ抽出し、対応する前記認証局発行情報のレコードの前記格納欄にそれぞれ格納し、前記認証局発行情報のレコードの証明書バイナリデータ格納欄には前記認証局証明書および全てのエンドエンティティ証明書のそれぞれの証明書自身のバイナリデータをそのまま格納することを特徴とする付記7記載の認証局装置。
(付記9)
前記認証局発行情報のレコードは、証明書の失効日時、失効理由を格納する欄を更に含んで構成され、
前記移行元失効情報の受取手段は、前記認証局発行情報における証明書のシリアル番号と、前記失効した証明書のリストから得られた失効する証明書のシリアル番号が一致するレコードについて、失効日時と失効理由を追加することを特徴とする付記8記載の認証局装置。
(付記10)
前記順方向相互認証証明書は、前記移行元認証局装置から前記移行先認証局装置に宛てて発行される相互認証証明書であり、
前記逆方向相互認証証明書は、前記移行先認証局装置から前記移行元認証局装置に宛てて発行される相互認証証明書であり、
更に、前記順方向相互認証証明書および前記逆方向相互認証証明書は、発行者名と被発行者名が同一の証明書であり、同一認証局装置で古い鍵から新しい鍵に更新を行う場合に発行されるリンク証明書のように、前記移行元認証局装置の鍵を該古い鍵、前記移行先認証局装置の鍵を該新しい鍵として発行される該リンク証明書相当の証明書であることを特徴とする付記7記載の認証局装置。

0118

1移行先認証局装置
2移行元認証局装置
11移行機能
12証明書発行機能
13 CRL発行機能
14認証局リポジトリ(証明書管理DB)
15 証明書シリアル番号カウンタ
16 証明書プロファイルテンプレート
17 CLRシリアル番号カウンタ
18移行元証明書の受取機能
19 移行元CRLの受取機能
20認証局証明書の移行発行機能
21認証パス生成機能(順方向)
22 認証パス生成機能(逆方向)
51 拇印検証機能
52署名検証機能
53プロファイル解析機能
201 CPU
202メモリ
203入力装置
204出力装置
205外部記憶装置
206媒体駆動装置
207可搬記録媒体
208バス
211 証明書発行機能
212 CRL発行機能
213 証明書シリアル番号カウンタ
214 証明書プロファイルテンプレート
215 CRLシリアル番号カウンタ
216 拇印検証機能
217 署名検証機能
218 プロファイル解析機能
219 認証局リポジトリ

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ