Comments
Description
Transcript
より安全な暗号に対応した電子認証系システム
暗号 暗号技術の活用に向けた取り組み 危殆化 電子認証 より安全な暗号に対応した電子認証系システム NTT情報流通プラットフォーム研究所では，安心・安全な情報流通を支え よ し だ よしひろ まさもと ひ ろ し 吉田 芳浩 /政本 廣志 る基盤として，暗号技術を利用した電子認証系のシステムを研究開発してい ます．最近話題になりつつある暗号アルゴリズムの危殆化による影響や課題 NTT情報流通プラットフォーム研究所 と,それに対する取り組みについて紹介します． ほかの誰でもが復号することができま デジタル署名を付与して証拠として保 す．これを応用して署名や認証（本人 持する第三者機関としての電子公証局 確認）ができることになります．このと があると便利です．さらにその時刻を ネットワーク社会で安心・安全な情 き，公開鍵が誰のものであるかを第三 証明するためには，タイムスタンプを 報流通を実現するためには，暗号技術 者機関が証明し，それを公開する必要 発行するタイムスタンプ局が使われま を使った暗号化（秘匿）とデジタル署 があります．そのための仕組みや規約 す．NTT情報流通プラットフォーム研 名が必須です．デジタル署名には公開 が PKI（ Public Key Infrastructure： 究所ではこれらの基盤を構築するため 鍵暗号という方式が使われますが，こ 公開鍵基盤）です（図１）． のプロダクトとして電子認証システム 安心・安全な情報流通を支える 電子認証系システム れはもとの文を暗号化する鍵と異なる PKIの重要な構成要素は，公開鍵 T r u s t - C A N P ， 電 子 公 証 システム （ただし一対の）鍵で復号する暗号方 の持ち主を証明する証明書を発行する Trust-CYNOS，時刻証明システム 式です．この特徴を利用して一方の鍵 CA（ Certificate Authority： 電 子 Trust-STLなどの電子認証系システム を秘密に保管（秘密鍵）し，他方を 認証局）です．また電子文書などのデー を提供しています．以上これらのプロ 公開（公開鍵）することにより，秘密 タが存在した事実やデータを送受信し ダクト機能は暗号技術に立脚しており， 鍵を持つ人だけがつくり得る暗号文を， た事実を証明するためには，データに より安全な暗号アルゴリズムに常に対 電子認証局（CA） 鍵の持ち主がA で あることを証明 利用者A 利用者B ①鍵対を作成し，秘密鍵は保管 公開鍵 ⑤ CAから利用者Aの公開鍵を取得 （公開鍵証明書として） ②公開鍵を第三者機 関であるCAへ登録 Aの公開鍵 秘密鍵 ⑥署名検証を行い，「改ざん」や「なりす まし」がないことを確認 ③元の文（平文）に秘密鍵で署名 平文 ハッシュ 平文 暗号化 ハッシュ 値 署名 署名 平文 ④送信 署名処理 ハッシュ 復号 署名 ハッシュ 値 一致す ハッシュ ればOK 値 署名検証処理 利用者 利用者 図１ デジタル署名とPKIの基本 16 NTT技術ジャーナル 2005.12 特 集 応しておき，いつでも切替可能な状態 にしておく必要があります． 電子認証局（CA） 電子認証系システムで使用する 暗号技術 (1) CA署名鍵 登録局 （RA） 発行申請例 ⑤証明書作成 ⑥CA署名付与 公開鍵 証明書 秘密鍵 電子認証システムTrust-CANP 公開鍵と，公開鍵と対になる秘密鍵 耐タンパ署名装置（HSM） 公開鍵 発行申請例 ②本人性の審査 ③鍵対生成 ④発行申請 CA署名 発行申請例 ①申請 の持ち主の対応関係を証明するのに， 発行申請例 ⑦証明書と秘密鍵を ICカード等に格納 ⑧申請者に配付 IC 公開鍵証明書を自らの署名を付与し 利用例 ③文書を受信 ④リポジトリ等経由で失効 情報を取得 ⑤署名検証，有効性確認 証明書 て発行するのがCAです．CAの基本機 秘密鍵 能である鍵対の生成，公開鍵の登録， 利用者 公開鍵証明書の発行等を行うのが電子 署名付き 文書 利用例 ①秘密鍵で文書に署名 ②証明書を添付して送付 認証システムTrust-CANPです（図 利用者 証明書 HSM：Hardware Security Module RA：Registration Authority 図２ 電子認証システムと利用例 ２）．行政系のシステムなどで活用さ れています． (2) 電 子 公 証 システムT r u s t CA CYNOS デジタル署名技術を使い，事実関係 TSA タイムスタンプ HSM 公証局の証明書 を証明し，事後否認を防止するのが電 子 公 証 局 です． 電 子 公 証 システム 申請書 Trust-CYNOSは，文書に署名を施す 署名付き 文書 ことで存在を証明したり，送受信者の ①存在証明等を 依頼する文書 を暗号通信に より送信 公証署名鍵 電子証書 署名付き 文書 公証局 タイム の署名 スタンプ 秘密鍵 （図３）．なおサーバ−クライアント間 署名付き 文書 公証局 の署名 情報と合わせて署名することで文書配 達の事実を証明することができます 電子証書 保管 ②文書に署名して保管 ③文書取得要求に応じて， 公証局署名やタイムスタ ンプを付与し，暗号通信 により返信 タイム スタンプ 利用者 TSA：Time Stamp Authority 利用者 図３ 電子公証システムと利用例 では共通鍵を使った暗号通信を行って います．これらは，電子入札システム， 電子申請システムなどで使用されてい ます． 時刻配送局（TA） (3) 時刻証明システムTrust-STL 正確な時刻 他TSA データの存在時刻と以降の無改ざん 集約局等 タイムスタンプ局 （TSA） 性をタイムスタンプにより保証するの タイムスタンプ発行 のイベント情報 がタイムスタンプ局です．タイムスタン HSM プはユーザデータのハッシュ値に，正 確な時刻を供給する時刻配送局からの 発行申請例 ①申請 対象データの ハッシュ 時刻情報を組み合わせて，タイムスタ ンプ局の署名を施したものです．時刻 データ TSA署名鍵 タイムスタンプ ハッシュ＋ 時刻情報 発行申請例 ②ハッシュ＋時刻情報 にTSAが署名 ③申請者に配付 ④そのイベント情報を 集約局に送付 証明システムTrust-STLはさらに，発 行 したタイムスタンプの履 歴 をハッ シュ技術を用いて集約することで，タ イムスタンプ自体の有効性を長期に保 発行申請例 ⑤イベント情報を集めてさ らにハッシュ化すること で長期に有効性を保証 （DS-IMT方式） 利用者 利用例 ①タイムスタンプ付きの 文書データを送付 データ タイムスタンプ ハッシュ＋ 時刻情報 利用例 ②受信した文書データの タイムスタンプを検証 ③検証局を介して集約情 報により有効性の維持 を確認 利用者 TA：Time Authority DS-IMT：Dynamically Sliced Incremental Merkle Tree 図４ 時刻証明システムと利用例 証できます（図４） ． NTT技術ジャーナル 2005.12 17 暗号技術の活用に向けた取り組み 表１ 電子認証系システムにおける危殆化への対策 電子認証系システムへの暗号危殆 主な利用製品 化の影響と対策 ハッシュ関数，公開鍵暗号とデジタ ハッシュ ル署名，共通鍵暗号のそれぞれについ て，危殆化の可能性が指摘されていま 署名 共通鍵 Trust-CYNOS 的には次の関数が指摘されています． SHA-256/512を利用 ・80 bit安全性以下 ・128 bit安全性以上 Hash Algorithm 1） ・公開鍵暗号・署名：1,024,bit以 Camellia/AESを利用 ・112 bit安全性以下 ・128 bit安全性 ハッシュ ・共通鍵暗号：2-key Triple DES これらは電子認証系システムでは必 対応方針 RFCやPKCSでの規定がSHA-1やMD5と なっているため，変更すると相互接続性 がなくなる 署名 ICカード，JCE，CryptoAPIなど他社ラ イブラリが未対応のため，利用プログラ ムが作成できない 共通鍵 RFCやPKCSでの規定がDES，3DESと なっているため，変更すると相互接続性 がなくなる も随所に使われているため，危殆化し る場合や認証に利用している場合 DES: Data Encryption Standard FEAL: Fast data Encipherment ALgorithm 主な課題 Adleman）暗号，署名，SHA-1 ① データを暗号化して通信してい ・128 bit安全性以上 表２ 危殆化対応における課題と対応方針 下 のR S A （ R i v e s t ─ S h a m i r ─ た場合，次のような影響が生じます． SHA-256withRSASSA-PKCS1-v1.5 （上限値3 072bit以上） Camellia/AESを一部利用 DES/3DES/FEALの利用あり SHA-1: Secure Hash Algorithm 1 MD5: Message Digest 5 AES: Advanced Encryption Standard ・ハッシュ関数：SHA-1（Secure 須の技術であり，前述のNTT製品で SHA-1あるいはMD5 Trust-STL Standards and Technology：米国 を用いる署名関数 対処後 SHA-1withRSASSA-PKCS1-v1.5 Trust-CANP， （上限値2 048bit） CYNOS，STL ・112 bit安全性 す ． NIST（ National Institute of 立標準技術研究所）によると，具体 現状 RFC: Requet for Comments PKCS: Public Key Cryptography Standards あらかじめ安全なアルゴリズムにも 対応可能としておき，NISTからの安 全性に関する勧告を受けて，RFCや PKCSなどの規定が変更されたり，他 社製品などが対応できた段階で即座 に対応 NIST: National Institute of Standards and Technology JCE: Java Cryptography Extension に，盗聴され解読やなりすましさ れる恐れが発生する． めに署名つきで保管している場合にも， やICカードなどの周辺装置が新アルゴ これから作成する公開鍵証明 署名つきデータとしての信頼性が損な リズムに未対応のものもあります． 書，タイムスタンプ，署名つき われることにより，重要情報の内容が データ等の信頼性が損なわれる． 信頼できなくなってしまいます． ② ③ 過去に作成した公開鍵証明書， 前述のような影響に対して，電子認 タイムスタンプ，署名つきデータ 証系システムでは表１に示す対策を実 等の信頼性が損なわれる． 施します．基本的には， デジタル署名は，署名生成後一定期 間データの信頼性を保証するものです が，ある時点で署名（に用いられた暗 号）の信頼性が損なわれてしまった場 合，いつから信頼性が損なわれていた ・該当暗号を利用している部分を安 全なアルゴリズムに変更 ・互換性や相互接続性が必要な部 分は従来の暗号もサポート という改造を行います． このような部分を除いて早期に対応 をすませておくことにより，規約や他 社製品での対処がなされ次第，直ちに 全体として対応することができます． この課題と対応方針については，暗 号技術ごとに整理したものを表２に示 します． 電子認証システムを利用するシス テムの移行スケジュール例 か分からなくなり，過去の署名が信頼 ただし，標準規約や事実上の標準規 暗号用途や認証のための暗号は，そ できなくなってしまい，なりすましや改 約により，現時点では古いアルゴリズ れが利用される瞬間に安全なものであ ざんが行われていた可能性を否定でき ムに限定されている部分があります． れば問題ありませんが，デジタル署名 なくなってしまいます． また電子認証系システムは市販の周辺 の場合，前述のように署名の信頼性が さらに，運用ログなどの重要情報が 装置やソフトウェアを使用している部 損なわれる前に新たな（安全な）署名 改ざんされていないことを保証するた 分がありますが，現時点では署名装置 に移行する必要があります．つまり， 18 NTT技術ジャーナル 2005.12 特 集 署名作成期限 NISTの勧告 従来アルゴリズム 従来通り利用可 従来アルゴリズム 発行 新アルゴリズム 早期対応の場合 移行勧告期限 署名利用不可 （署名検証，認証，暗号化は可） CAの運用例 利用不可 署名用途は失効管理のみ． 他用途は発行可だが期限注意 発行 ユーザ鍵と 証明書の発行・利用パターン 例 証明書有効期間 従来通り利用可 証明書有効期間 従来通り利用可 ① 移行期限で失効処理 署名利用は不可 証明書有効期間 従来通り利用可 移行期限を またがる場 合の対処案 ② あらかじめ期間を短縮して発行 署名利用は不可 従来通り利用可 ③ 新アルゴリズムで発行 失効 証明書有効期間 署名利用は不可 証明書有効期間 証明書有効期間 図５ 移行時の証明書発行パターン例 データに署名した鍵に対応する公開 易さ，移行前後の利用者への証明書 鍵証明書の有効期間を考慮して，移 更新手続き，あるいは関係法令や接続 行スケジュールを計画する必要があり システムの状況を考慮して，移行計画 ます． を策定することになります．しかしい 古いアルゴリズムの公開鍵証明書の ずれにしても，電子認証系の基盤シス 移行方法として，次のいずれかの方法 テムが先に対処されていないとシステ が考えられます（図５）． ムで利用できないため，先行して対応 ① 使用停止時期に証明書の無効 化処理を実施する． ② 使用停止時期を越えないように 有効期間を短くして発行していく． 開発を実施しています． また実際に運用されているシステム では移行時の運転停止や全データの一 斉 移 行 は困 難 な場 合 があります． 停止時期から有効期間分遡っ NTTの電子認証系システムは，複数 て旧アルゴリズムでの発行を停止 のアルゴリズムを同時利用可能とする し，新アルゴリズムに切り替える． 仕組みを従来より備えており，スムー ③ なお署名用途の場合は，署名生成 の後にその有効性を検証する必要の ある期間がありますが，無効化処理を ズな移行が可能になります． 今後の展開 行ってしまうと，生成用途だけでなく 現在開発中の成果を予定どおり提供 検証用途にも使えなくなってしまいま するとともに今後，規約や他社製品な すので注意が必要です．①，②は運用 どの課題も解決し次第対応していきま を変更することになり負担が大きいと す．また今回対応していない基盤プロ も考えられます． ダクト（属性認証システムなど）につ 実際にはシステムの状況，暗号の利 用用途，証明書の有効期間変更の容 いても，標準化や事業動向を見据えて 対応していく予定です． （左から）政本 廣志/ 吉田 芳浩 危殆化に伴う移行期限とされている 2010年は，すぐにやってきます．電子認 証系システムは利用者が暗号危殆化の問題 の重要性を十分認識していない可能性もあ ります．基盤システムとしてはこの問題に 先行して取り組む必要があり，関係部署と 協力して対応していきたいと思います． ◆問い合わせ先 NTT情報流通プラットフォーム研究所 第二推進プロジェクト TEL 046-859-3174 FAX 046-855-1533 E-mail [email protected] NTT技術ジャーナル 2005.12 19