FUJITSU Software Systemwalker PKI Manager V12 （12.0.4） ご紹介

FUJITSU Software
Systemwalker
PKI Manager V12.0
ご紹介
2013年10月
富士通株式会社
Copyright 2013 FUJITSU LIMITED
PKI 概要




ネットワークにおける脅威
PKIにより実現されるセキュリティ
認証局とは
認証局構成モデル
1
Copyright 2013 FUJITSU LIMITED
ネットワークにおける脅威
 ネットワーク上を使用した情報のやり取りには、以下の4つの脅威がある
商談があり
ます
盗聴
横取りし
てやろう
書類は
後で作
ろう
改ざん
契約が成立
しました
そうか
だめだった
か
ＮＧにし
てやろう
否認
なりすまし
早いな
そんな報告
はしていな
いよ
おかしい
な
頼まれた
書類です
2
Copyright 2013 FUJITSU LIMITED
PKI により実現されるセキュリティ
 「盗聴」「改ざん」「なりすまし」「否認」の脅威を防止する
盗聴防止
通信内容、文書内容の
秘匿の仕組み
暗号化
改ざん防止
文書作成者の明示と
改ざん検出の仕組み
電子署名
PKI
なりすまし防止
否認防止
通信相手の
本人確認の仕組み
証明書
3
PKI（Public Key Infrastructure）
証明書／公開鍵暗号の技術によって実現される、
暗号化や認証、本人確認を行うセキュリティ基盤
Copyright 2013 FUJITSU LIMITED
認証局とは
PKIシステムの中心
公開鍵（証明書）が確かにその人のものであることを証明する機関
認証局は、個人の情報と公開鍵に署名し、証明書を発行
公開鍵を登録
鍵ペアを生成
認証局
証明書を発行
(PKCS#10/7方式)
証明書を発行
イントラネット/インターネット
(PKCS#12方式)
暗号通信
鍵ペアを生成
4
Copyright 2013 FUJITSU LIMITED
認証局構成モデル
EE(End Ｅntity)
RA(Registration
Authority)
利用者
1. 証明書
発行要求
2．鍵ペア
生成
RAO(RA Operator)
3．証明書発行審査
(PKCS#10)
4．証明書発行依頼
(CMP)
7．証明書配付
(PKCS#7)
登録局
利用者／サーバ
IA(Issuing
Authority)
5．証明書発行
認証局
CA(Certification
Authority)
LDAP
Repository
8．証明書獲得、公開鍵入手、
CRLで証明書の有効確認
PKCS: Public Key Cryptography Standard
ディレクトリサーバ
発行局
LDAP
6． 証明書を
格納・公開
LDAP: Lightweight Directory Access Protocol
CMP: Certificate Management Protocol
5
Copyright 2013 FUJITSU LIMITED
ご紹介





製品紹介 Systemwalker PKI Manager
構成例
証明書発行処理フロー
認証局コンサル及び構築概要
認証局構築についての主な検討事項
6
Copyright 2013 FUJITSU LIMITED
製品紹介 Systemwalker PKI Manager
～公開鍵基盤(PKI)を担うIA、RA機能～
運用管理部門
IA（発行局）機能
証明書、CRL(証明書失効リスト）を発行
X.509 V3準拠の証明書/X.509 V2準拠のCRLを発行
ディレクトリサーバ連携による証明書・CRLの配付
階層型IA
組織別、用途別の柔軟な導入
IA間の相互認証(CSRのSHA2署名にも対応)
複数IA
1サーバ内に複数IAの構築することによるコストダウン
RA/KRオペレータ
イベント/監視
認証局
申請の審査
証明書データ作成
信頼性運用
RA（登録局）機能
証明書発行/失効申請
RA操作員からの発行申請(GUI)
発行/失効コマンドを使用したアプリ連携による自動申請
IAへの証明書の発行/失効依頼
証明書データの作成
PKCS#12形式データとして作成
スマートカードとして作成
スマートカード工場向け発行データを作成
信頼性
一括発行申請者と承認者とのRAオペレータの役割分離
KR(Key Recovery)オペレータによる鍵破損等からの回復
FUJITSU Software
Systemwalker Centric Manager
証明書使用企業
IA/RA
Systemwalker PKI Manager
証明書/CRL公開
PKCS#12格納
LDAPﾃﾞｨﾚｸﾄﾘ
ｻｰﾊﾞ
認証局管理者
カード工場
証明書
発行申請
共通機能
イベント監視
Systemwalker Centric Managerメッセージ連携による監視
監査機能
監査ログを採取し、不正運用がされていないことを検証
PKCS#12形式の 証
明書と秘密鍵をディ
レクトリから取得
●▲■★
7
カード工場発行での証明
書・秘密鍵の大量発行
ｴﾝﾄﾞﾕｰｻﾞ
Copyright 2013 FUJITSU LIMITED
構成例
■セキュアゾーン
認証局サーバ(IA,RA)の本体を設置する区画。PKI コンポーネ
ントの心臓部で、最も高度なセキュリティが必要な部分です。通常
は無人で運用し、ネットワーク設備も最小限に留めます。
セキュアゾーン
IA、RA
ディレクトリ
・IA（Issuing Authority：発行局）
証明書の発行/失効を行います
・RA（Registration Authority：登録局）
EE を審査して証明書の発行申請や失効要求の是非を判断し、
IA に証明書の発行や失効を依頼します。
Firewall
■オペレーションゾーン
認証局操作用端末や登録局操作用端末を設置する区画。管理
者が認証局や登録局を操作したり、エンドユーザに対する証明書
発行承認・失効承認・鍵回復承認の操作などの日常の業務を行う
区画です。
オペレーションゾーン
RA Console
CA
RAO KRO
管理者端末
・認証局管理端末
IA管理者端末(IAの管理)、RAコンソール(RAの管理)
・RAO （RA Operator） 証明書申請の一括・個別申請/審査/取得
・KRO (Key Recovery Operator) 鍵回復操作の申請/審査/取得
ネットワークゾーン
P12DL
■ネットワークゾーン
EE が直接利用するサーバを配置する区画。イントラネット内の
みのアクセスなら、イントラネットからのアクセスができる区画でかま
いません。
EE
ディレクトリ
・P12DL （PKCS#12 Downloader ）
PKCS#12形式の証明書をﾃﾞｨﾚｸﾄﾘからのﾀﾞｳﾝﾛｰﾄﾞし証明書利用者に提供
Firewall
・EE（End Entity：証明書利用者端末）
8
Copyright 2013 FUJITSU LIMITED
証明書発行処理フロー(小規模)
～個別申請の場合～
登録局管理者
RAオペレータ１/２
3．発行申請（RAO2）
4．発行承認（RAO1）
ＲＡ
8．証明書取得(RAO2)
(PKCS#7ダウンロード)
2．証明書
発行依頼
(PKCS#10)
5．証明書
発行要求
証明書利用者はアプリケーションにて
鍵ペアと申請書（PKCS#10）を作成
2.
証明書利用者は作成した申請書
（PKCS#10）を、RAオペレータ２に
提供し、証明書発行を依頼(オフライン)
3.
RAオペレータ２がRAに発行申請する
4.
RAオペレータ１が証明書発行
申請を承認すると、承認情報が
RAサーバに通達される
5.
RAサーバはIAサーバに対して
証明書発行を要求する
6.
IAサーバは証明書を発行する
7.
RAサーバはIAサーバから証明書を取得
8.
RAオペレータ２がRAから証明書
（PKCS#7）を取得
9.
証明書利用者はRAオペレータ２から
証明書（PKCS#7）を受取る(オフライン)
10.
証明書利用者は証明書を
アプリケーションにインポート
IＡ
6．.証明書発行
7．証明書取得
OracleDB
9．証明書(PKCS#7)を
受け取る
Webサーバ等管理者
1．アプリケーションにて
鍵ペアと申請書作成
(PKCS#10)
1.
10．証明書(PKCS#7)を
アプリケーションへインポート
9
Copyright 2013 FUJITSU LIMITED
証明書発行処理フロー(大規模・審査有)
～管理者による一括発行～
1.
Directoryサーバまたは人事データベース
から抽出したLDIF情報を元に、申請者
一覧を作成
2.
RAオペレータ２が一度に複数の証明書
発行申請を一括で申請
3.
RAオペレータ１が証明書発行申請を承認
4.
RAサーバにて鍵ペアが作成される。
5.
RAサーバはIAサーバに対して証明書発行を
要求
IＡ
6.
IAサーバは証明書を発行
6.証明書
発行
7.
RAサーバはIAサーバより証明書を取得
8.
RAオペレータ１の要求でPKCS#12
（証明書と秘密鍵）がRAオペレータ１に渡され
る
9.
RAオペレータ２はRAサーバより自動生成
されたPINを取得
10.
RAオペレータ１は作成されたPKCS#12（証明
書と秘密鍵） をDirectoryサーバに格納
11.
RAオペレータ２はPINを証明書利用者に
通知
12.
証明書利用者はPINを利用して
PKCS#12Downloader経由でディレクトリ
サーバからPKCS#12をダウンロード
13.
証明書利用者は証明書（PKCS#12）を
アプリケーションにインポート
発行・公開・
ＰKCS#１２配付用
Ｄｉｒｅｃｔｏｒｙ
12.PKCS#12
送信
10.証明書と秘密鍵
を格納 (PKCS#12)
（RAO１）
ＰKCS#１２
Downloader
ＲＡ
2．発行申請（RAO２）
3．発行承認（RAO１）
12.PKCS#12取得
5..証明書
発行要求
4．鍵ペア
作成
7.証明書
取得
RAオペレータ１/２
8.PKCS#12入手（RAO１）
9.PIN入手（RAO２）
11.PIN通知（RAO２）
1．申請者一覧情報の抽出
OracleDB
証明書利用者
LDIF
人事情報
Ｄｉｒｅｃｔｏｒｙ
13.証明書をアプリケーションへ
インポート
10
Copyright 2013 FUJITSU LIMITED
認証局コンサル及び構築概要
設 計
構 築
運 用
Directory
・設計コンサルティング
・スキーマ設計
・アクセス制御設計
・サーバ連携設計 …etc
・Directory構築
・スキーマ設定
・アクセス制御設定
・サーバ連携設定 …etc
・メンテナンス
・導入教育
・Q&A
PKI
・
・
・
・
認証局運用規程（CPS）作成支援
認証局ファシリティ構築コンサル
認証局運用管理基準の作成支援
サービス約款の作成支援
・ 認証局ファシリティ構築
・ 認証局構築
・CAシステム構築
・証明書発行ポリシー設定
・Directory連携構築
・カスタマイズ
…etc
・メンテナンス
・導入教育
・Q&A
スマートカード
・スマートカードデザイン作成サービス
・スマートカード二次発行サービス
・メンテナンス
ご提供
サービス
PKI PROPOSE , スマートカード発行・導入サービス
11
Copyright 2013 FUJITSU LIMITED
認証局構築についての主な検討事項
■ 認証局設備について
認証局を構成するサーバ、端末のネットワーク構成、及びサーバ、端末を配置する部屋の検討。
■ 証明書の発行・配付の運用
証明書発行時の利用者又は管理者からの発行申請及び発行方法、発行した証明書の利用者への
配付方式の検討。発行には、個別発行方式と一括発行方式、配付には、オフライン（媒体）による配付
方式とオンラインによる配付方式がある。
■ 証明書の失効の運用
証明書の失効管理を行うかどうか、またアプリケーションに失効情報をどのように反映させるかの検討。
■ 証明書の記載事項
証明書に記載する発行者、所有者、有効期間、鍵用途などの項目についての検討。
■ CP/CPS（証明書ポリシ/認証実施規定）の作成
CP/CPS（証明書ポリシ/認証実施規定）について、作成するか否か、記載レベルについての検討。
CP/CPSとは、その認証局の運用方針について、RFCで規定された形式に従い、ドキュメント化するもの
です。例えば認証局を運用していく為の体制、発行する証明書の内容、証明書発行、失効時の手順等を
規定します。
認証局は、CP/CPSを公開する事で、証明書の利用者にその認証局の信頼性を明示します。特に、GtoG、
GtoC、BtoB、BtoCの申請や取引き等で利用される証明書を発行する認証局においては、必須の規定と
されています。
■ 暗号アルゴリズムの2010年問題
証明書やアプリケーションをどのように新暗号化技術に対応させて、移行を実現させるかの検討。
例： 採用する暗号化技術、移行時期、移行順序、影響範囲、アプリケーション/OSの選択
12
Copyright 2013 FUJITSU LIMITED
暗号アルゴリズムの2010年問題








暗号アルゴリズムの2010年問題の概要
暗号2010年問題：政府の移行スケジュール
今後の暗号アルゴリズム
認証局での性能改善効果
運用時の性能改善効果
対応アルゴリズム
新暗号化技術への移行の流れ
認証局での移行方式
13
Copyright 2013 FUJITSU LIMITED
暗号アルゴリズムの2010年問題の概要
■ コンピュータで使われている暗号化技術(ハッシュ関数、共通鍵、公開鍵)が、コンピュータの
性能向上や解読技術の成果により、近い将来に破られる可能性があります。
■ RSA768bitまでは2010年1月に破られており、速やかな移行が求められています。
http://www.ntt.co.jp/news2010/1001/100108a.html
[米国政府の対応]
米国国立標準技術研究所(NIST) では、2005年にハッシュ値の衝突を見つける攻撃方法が相次いで報告され
たことなどから、2010年以降、米国政府機関が使用する情報システムは、ハッシュ関数、共通鍵、公開鍵など
について、より暗号強度の高い技術に移行することを決めた。
ただし2011年1月に進展状況を踏まえて移行計画を一部修正したガイドライン(SP800-131A)が公表され、解読
リスクを許容した上で、概ね2013年末までの継続利用を認めた。
[日本政府の対応]
2008年4月に内閣官房情報セキュリティーセンター(NISC)は、政府機関の情報システムに関して、現行の暗号
方式からの移行方針を発表した※1。
その後、改訂され※2、最終的に以下の移行指針となった※3。
a. 「2014年度9月下旬以降、早期に」新たな暗号方式に切替
b. 「2015年度末までに」従来の暗号方式によって発行された証明書の検証を終了
ただし、発行済み電子証明書の有効期間が残存し、やむ得ない場合は、「2019年度末まで」検証可
※1 「政府機関の情報システムにおいて使用されている暗号アルゴリズムSHA-1及びRSA1024に係る移行指針
（平成20年4月22日情報セキュリティ政策会議決定）」
http://www.nisc.go.jp/conference/seisaku/dai17/pdf/17siryou0101.pdf
※2 「政府機関の情報システムにおいて使用されている暗号アルゴリズムSHA-1及びRSA1024に係る移行方針」に基づく検討状況について」
（平成21年2月3日情報セキュリティ政策会議決定）」
http://www.nisc.go.jp/conference/seisaku/dai20/pdf/20siryou0502.pdf
※3 「政府機関の情報システムにおいて使用されている暗号アルゴリズムSHA-1及びRSA1024に係る移行指針
(平成24年11月1日 情報セキュリティ政策会議第31回会合)」
http://www.nisc.go.jp/conference/seisaku/dai31/pdf/31seisakupress.pdf
14
Copyright 2013 FUJITSU LIMITED
暗号2010年問題：政府の移行スケジュール
「政府機関の情報システムにおいて使用されている暗号アルゴリズムSHA-1及びRSA1024に係る移行指針(平成24年11月1日 情報セキュリティ政策会議第31 回会合)」
http://www.nisc.go.jp/conference/seisaku/dai31/pdf/31seisakupress.pdf
15
Copyright 2013 FUJITSU LIMITED
今後の暗号アルゴリズム
【現状】
【ユーザ証明書】
署名アルゴリズム ：SHA-1
鍵長
：RSA1024bit
【次の主流】
【認証局証明書】
署名アルゴリズム ：SHA-1
鍵長
：RSA2048bit
鍵生成時間は約 5.6倍に増加
【ユーザ証明書】
署名アルゴリズム：SHA-2
鍵長
：RSA2048bit
【認証局証明書】
署名アルゴリズム：SHA-2
鍵長
：RSA4096bit
【その後】
【ユーザ証明書】
署名アルゴリズム：RSA-PSS(or SHA-3)
鍵長
：RSA2048bit
【認証局証明書】
署名アルゴリズム：RSA-PSS(or SHA-3)
鍵長
：RSA4096bit
16
Copyright 2013 FUJITSU LIMITED
認証局での性能改善効果
 Systemwalker PKI Manager 12.0.4では、鍵生成処理をSPARC64™ Xの
ソフトウェアオンチップ(SWoC)機能にてハードウェア化しており、
高速な証明書発行を実現します。
【次期モデル環境で100枚発行した場合】
サーバ/HSM
認証局
認証局鍵長
ユーザ鍵長
現行モデル環境
SPARC Enterprise T5220 (SafeNet LunaCA4)
Systemwalker PKI Manager 12.0.1 (Solaris10)
2048bit
鍵長を倍増
1024bit
【LunaCA4を使用】
発行申請 鍵生成
[6秒]
[66秒]
次期モデル環境
SPARC M10-1 (SafeNet LunaSA5.2※)
Systemwalker PKI Manager 12.0.4 (Solaris11)
4096bit
2048bit
【LunaSAを使用】
発行
P12生成
[135秒]
[138秒]
[工程]
発行申請 鍵生成
発行
P12生成
[工程]
約44秒
約154秒
(約1.54秒/枚) [時間]
[3秒]
[39秒]
[40秒]
[40秒]
(約0.44秒/枚)
[時間]
【LunaSAなし】
発行申請 鍵生成
発行
P12生成
[47秒]
[46秒]
[工程]
約50秒
[時間]
鍵生成は約 7/10
[3秒]
[45秒]
(約0.50秒/枚)
全体は約 1/3
※ 認証局秘密鍵の管理に使用するため、証明書発行時の署名処理だけに作用する。(4096bit鍵で 6ms/回)
17
Copyright 2013 FUJITSU LIMITED
運用時の性能改善効果
 暗号2010年問題対応のために鍵長を倍増させても、運用時間(ログイン～取得)は
従来の半分以下に短縮できます。
【１万枚の証明書を一括発行した際の内訳】
従来製品
(RSA1024bit鍵を生成)
約 1.2 [秒/枚]で発行
Systemwalker
PKI Manager 12.0.4
(RSA2048bit鍵を生成)
+
SPARC M10-1
18
Copyright 2013 FUJITSU LIMITED
対応アルゴリズム
■ Systemwalker PKI Managerでは、暗号アルゴリズムの2010年問題に対応しており、
下記アルゴリズムでの証明書発行を実現します。
スペック
従来製品
PKI Manager
鍵長
RSA512bit
RSA1024bit
RSA2048bit
RSA4096bit
○
○
○
－
－
◎
◎ 鍵のﾊｰﾄﾞ生成
◎ で高速化
公開鍵アルゴリズム
RSAEncryption
RSASSA-PSS
○
－
○
○
署名アルゴリズム
md5WithRSAEncryption
sha1WithRSAEncryption
sha256WithRSAEncryption
sha384WithRSAEncryption
sha512WithRSAEncryption
RSASSA-PSS
○
○
－
－
－
－
－
○
○
○
○
○
19
Copyright 2013 FUJITSU LIMITED
新暗号化技術への移行の流れ
ステップ１： 従来の暗号化技術を使用(移行の準備)
利用者を含むシステムのソフトウェア/ハードウェアを新しい暗号化技術に対応したもの
に順次入替え、各サーバの共有資源や利用者環境の証明書などの従来の資産を新し
い環境に移行していく。
ステップ２： 従来と新暗号化技術の両方を使用(混在運用)
利用者や各サーバの環境を、順次、新しい暗号化技術に変更し、新旧両方の暗号
化技術に対応するよう設定する。
認証局は新しい暗号化技術に対応した証明書/失効リスト(CRL)の発行を開始する。
ステップ３：新しい暗号化技術のみを使用(完全移行)
従来の暗号化技術の使用を停止する。古い証明書を失効し、すべての製品から削除
し、従来の暗号化技術を使用しないように設定を変更する。
20
Copyright 2013 FUJITSU LIMITED
認証局での移行方式(並行運用)
■ 証明書利用アプリケーションは、新旧認証局から提供される、2つの認証局証明書とCRLにて
利用者証明書を検証する。
■ 新旧認証局が異なる認証局製品でも実現できる。
■ 旧認証局で発行した証明書が以下の状態になるまで、新旧2つの認証局を並行運用する。
 全ての利用者証明書が有効期間切れになる(利用者証明書の有効期間分の移行期間が必要)。
 全ての利用者証明書を利用できないよう以下の方法で無効化する。
(a) 旧認証局証明書を信認しないようにする。
(b) ICカード(利用者秘密鍵)を回収する。
(c) 利用者証明書を利用するアプリケーションにて利用者IDを削除する。
21
Copyright 2013 FUJITSU LIMITED
認証局での移行方式(CA鍵を更新)
■
■
■
■
■
CA鍵を変え、署名アルゴリズムもSHA2に変えてCA証明書を更新(ReKey)。
証明書利用アプリケーションは、リンク証明書を経由した認証パスをサポートする必要がある。
新旧アルゴリズムの混在したリンク証明書は、アプリケーション側の対応が必要になる。
新認証局に旧認証局の発行/失効情報を移行するには、同一製品でしか実現できない。
認証局秘密鍵を暗号装置(HSM)に格納している場合は、暗号装置の互換性が必要になる。
新しい鍵
新CA
旧
22
Copyright 2013 FUJITSU LIMITED
認証局での移行方式(署名のみ変更)
■
■
■
■
■
CA鍵を変えずに、署名アルゴリズムをSHA2に変えてCA証明書を更新(Renewal)
CA鍵は変更しないので、リンク証明書は発行されない。
発行済みの利用者証明書には影響がなく、順次利用者証明書をSHA2対応に更新していく。
同一の認証局製品でなければ、実現できない。
移行後、運用規程で定めた適切な時期に、CA鍵を更新する。
23
Copyright 2013 FUJITSU LIMITED
導入事例






ICカードを使用したPKI認証基盤
電子申請ソリューション（自治体事例）
Webシステムの認証用証明書の配付
高セキュアな認証ソリューション
SafetyMAMによるICカード発行の自動運用
FUJITSU Software Systemwalker Operation Managerと業務アプリによる
自動運用
24
Copyright 2013 FUJITSU LIMITED
事例紹介 ICカードを使用したPKI認証基盤
■ 職員証（ICカード）を使った職員ポータル及びSSOシステム（Entrust GetAccess)の構築。
■ ICカード発行運用管理システム(SafetyMAM)との自動連携にてICカードを発行。
25
Copyright 2013 FUJITSU LIMITED
事例紹介 電子申請ソリューション（自治体事例）
■ 法人や住民を認証する認証局（特定認証業務認定の認証局）を構築。
■ 電子政府や自治体は、PKIによる署名や認証により、安全に電子申請・届出システムを実現。
証明書の検証により本人を保証。
「なりすまし」「否認」を防止
認証局
電子署名の検証
公開鍵の登録
申請書
電子申請・
届出システム
証明書の発行
SSL クライアント認証
により申請者側の 「な
りすまし」の防止
SSL 、S/MIME にお
ける暗号化通信によ
り「盗聴」の防止
署
法人・住民
XML文書
申請書に電子署名を付加
電子署名の付加による「改
ざん」の防止
SSL サーバ認証により
サーバの「なりすまし」の
防止
26
担当官
課長
申請書
申請書
署
署
XML文書
XML文書
電子政府・自治体
Copyright 2013 FUJITSU LIMITED
事例紹介 Webシステムの認証用証明書の配付
■ 利用者登録時に証明書発行を行い、利用者PC(Windows)の証明書管理領域に自動インポート。
■ 証明書更新時にも、証明書を再配付するとともに旧証明書を自動失効。
■ 利用者削除時には、証明書を自動失効。
利用者の
登録・削除
利用者管理
ポータル
利用者登録
利用者削除
利用者の
登録・更新・削除
証明書
更新
証明書の即時配付
利用者
証明書の自動格納で
すぐに使用可能
(Javaｱﾌﾟﾚｯﾄ)
利用者
(PKCS#12)
証明書
発行
証明書
失効
証明書管理(URP)
・発行/更新
・証明書配付
・失効
発行/失効要求
証明書取得
認証局
(Systemwalker
PKI Manager
CA/RA)
URP：User Request Program(有償のカスタマイズサービス)
27
Copyright 2013 FUJITSU LIMITED
事例紹介 高セキュアな認証ソリューション
生体認証＋ICカード＋PKIによる最高レベルのセキュリティを実現
■ 生体情報にてICカードへのアクセスを認証します。
■ ICカード内に証明書ペアを格納しておくことで、2要素認証も実現します。
■ ICカードを紛失しても、生体情報から自動算出された強固なPINが設定されており不正利用は不可能です。
■ Windowsログオン用プロファイルを証明書に設定しておくことで、スマートカードログオンも実現します。
■ SSOサーバ等のWeb認証サーバに対しても証明書認証が行えます。
①個人認証
(生体認証/ICカード認証)
手のひら静脈センサ
②Windowsスマートカード
ログオン認証※
Windowsドメイン
コントローラ
利用者PC
③業務認証
(SSL v3クライアント認証)
Web認証サーバ
(GetAccess等)
<Windows8>
SafetyCLIC
(生体情報から一意のPINに変換)
認証情報
認証情報
PIN認証
生体情報にて
ICカードへの
アクセスを認証
●▲■★
ﾕｰｻﾞ用
秘密鍵
ﾕｰｻﾞ用
証明書
※ Windowsログオンは以下のMicrosoft情報にて実現します。
「サードパーティのCAを用いてスマートカードログオンを有効にするガイドライン」 http://support.microsoft.com/default.aspx?scid=kb;JA;281245
「サードパーティの証明書をNTAuthストアにインポートする方法」 http://support.microsoft.com/kb/295663/ja
28
Copyright 2013 FUJITSU LIMITED
事例紹介 SafetyMAMによるICカード発行の自動運用
■ SafetyMAM等のICカード発行管理システムに、証明書発行/失効コマンドを登録しておくことで、
カード発行や廃棄のイベントと連動して、証明書の発行/失効を自動化することができます。
認証局連携サーバ
< Windows Server >
管理操作
券面情報の入力
ICカード管理者 (氏名,ID,写真等)
申請情報/
実行結果
SafeｔｙMAM
カード発行⇒発行
カード更新⇒発行/失効
紛失/廃棄⇒失効
証明書
(PKCS#12)
Systemwalker
PKI Manager
RAO
(証明書発行/
失効ｺﾏﾝﾄﾞ)
発行/
失効
申請
証明書
取得
認証局
(Systemwalker
PKI Manager
CA/RA)
ﾌｧｲﾙ渡し
券面印刷され
証明書が格納さ
れたICカードが
自動発行される
●▲■★
ICカード発行機
29
Copyright 2013 FUJITSU LIMITED
事例紹介 Systemwalker Operation Managerと業務アプリによる自動運用
■ Systemwalker Operation Manager等のジョブ管理システムに、証明書発行/失効コマンドを
登録しておくことで、バッチ処理として、証明書の発行/失効を自動化することができます。
■ 業務アプリにて、発行/失効コマンドに適用する申請情報ファイル(CSV形式)の自動生成と、
コマンドの実行結果ファイルの自動解析を実装することで、自動運用を行うことができます。
認証局連携サーバ
< Windows Server >
会員登録/
削除申請
証明書
(PKCS#12)
申請情報/
実行結果
業務アプリ
(会員管理/
ﾜｰｸﾌﾛｰ)
ID追加⇒発行
ID削除⇒失効
証明書
(PKCS#12)
利用者
ﾀﾞｳﾝﾛｰﾄﾞ
Systemwalker
Operation
Manager
Systemwalker
PKI Manager
RAO
(証明書発行/
失効ｺﾏﾝﾄﾞ)
発行/
失効
申請
証明書
取得
認証局
(Systemwalker
PKI Manager
CA/RA)
ﾌｧｲﾙ渡し
承認された証明書だけ
バッチジョブとして
一括申請を行う。
審査/承認
30
Copyright 2013 FUJITSU LIMITED
付録








公開鍵暗号： PKC（Public Key Cryptography)
公開鍵方式の三つの原則
公開鍵暗号の応用 （秘匿通信と本人確認）
公開鍵暗号に関する標準
公開鍵暗号に関する標準・PKCS#12とは
暗号2010年問題・秘密鍵の解読
暗号2010年問題・署名(SHA-1)の衝突問題
製品体系
31
Copyright 2013 FUJITSU LIMITED
公開鍵暗号： PKC（Public Key Cryptography)
秘密鍵
公開鍵
鍵Ａ
鍵Ｂ
① ある人が「秘密鍵」と「公開鍵」の
２つの鍵を同時にペアで生成
② 秘密鍵Ａで暗号化した文章は
公開鍵Ｂでしか解けない
③ 公開鍵Ｂで暗号化した文章は
秘密鍵Ａでしか解けない
④ 公開鍵から秘密鍵は求められない
生成した本人だけが
秘密に扱える
誰にでも取得可能な
ように公開する
二つの素数からなる積を公開鍵とし、元の二つの素数から導き出される数値を秘密鍵とする。
例： 公開鍵＝6887
秘密鍵＝71、97から導かれる数値
実際の公開鍵の桁数は、256桁等の長い鍵が使われる
32
Copyright 2013 FUJITSU LIMITED
公開鍵方式の三つの原則
公開鍵
① 全ての鍵は一対（公開鍵と秘密鍵）
になっている。
秘密鍵
② 秘密鍵は自分で保管し自分だけが使う。公開
鍵は公開し他のすべてが使う。
証明書を公開
SHA2 ﾊｯｼｭ値
平
文
平
文
改ざん
検知
③ 公開鍵で暗号化された
メッセージは対の秘密鍵でしか
復号化できない。またその逆も
可能（秘密鍵で暗号化された
メッセージはその対となる公開鍵
でしか復号化できない）
SHA2 ﾊｯｼｭ値 暗号 署名 復号 ﾊｯｼｭ値
秘密鍵
公開鍵
33
Copyright 2013 FUJITSU LIMITED
公開鍵暗号の応用 （秘匿通信と本人確認）
秘匿（暗号）通信
◆ 受信者Ｙの公開鍵ＹＢで暗号化した文書は、
受信者Ｙの秘密鍵ＹＡでしか復号化できない
◆ よって誰から来た暗号文も、秘密鍵の保持者（＝受信者Ｙ）だけが
読み出すことができる
送信者Ｘ
受信者Ｙ
ABCD･･･XYZ
ABCD･･･XYZ
ABCD･･･XYZ
ABCD･･･XYZ
秘密鍵
ＹＡ
ＹＢ
暗号
本人（発信）確認
ＹＡ
ＹＢ
復号
公開鍵
◆ 送信者Ｘの秘密鍵ＸＡで暗号化した情報は、
送信者Ｘの公開鍵ＸＢでしか復号化できない
◆ 受信者Ｙは受信した暗号化情報の送信者がＸＡの保持者Ｘであると確認できる
ABCD･･･XYZ
ABCD･･･XYZ
ABCD･･･XYZ
ABCD･･･XYZ
公開鍵
ＸＢ
ＸＡ
秘密鍵
暗号
ＸＡ
秘密鍵
34
ＸＢ
復号
Copyright 2013 FUJITSU LIMITED
公開鍵暗号に関する標準
旧RSA Security社は、 PKCS（Public-Key Cryptography
関する標準を策定しており、赤字の規格がよく使われる。
Standards）と呼ばれる公開鍵暗号に
#1 ：RSA暗号に関する標準 (RFC3447)
#5 ：パスワードベース暗号に関する標準 (RFC2898)
#7 ：暗号メッセージ構文に関する標準 (RFC2315)
#8 ：秘密鍵の形式に関する標準 (RFC5208)
#10：証明書の申請構文に関する標準 (RFC2986)
#11：暗号インターフェースに関する標準
#12：個人情報交換構文に関する標準
#13：楕円曲線暗号に関する標準
#15：スマートカードに関する標準(ISO/IEC 7816-15)
証明書の申請/配付とPKCSの関係
【PKCS#10/7方式】
【PKCS#12方式】
鍵ペア生成
CA
証明書
発行申請書
(PKCS#10)※
証明書
(PKCS#7)
CA
PKCS#12
鍵ペア生成
ICｶｰﾄﾞ
利用者
管理者
PKCS#11
※ CSR(Certificate Signing Request：署名リクエスト)ともいう。
35
Copyright 2013 FUJITSU LIMITED
公開鍵暗号に関する標準・PKCS#12とは
利用者が使用する証明書(公開鍵)と秘密鍵が格納されているファイルです。
トラストポイント(信頼点)までの認証局証明書も格納できるファイルです。
パスワード(PIN:Personal Identification Number)で暗号化されています。
PKCS#12形式のファイル
ルート認証局証明書(公開鍵)
中間認証局証明書(公開鍵)
…
パスワードにて暗号化
利用者証明書(公開鍵)
鍵ﾍﾟｱ
利用者証明書の秘密鍵
36
Copyright 2013 FUJITSU LIMITED
2010年問題・秘密鍵の解読
RSA1024bit鍵の解読
秘密鍵
(1024bit)
証明書
①公開されてい
る証明書から公
開鍵を入手
秘密鍵
証明書
公開鍵
公開鍵
ペア
ｾｷｭﾘﾃｨｶｰﾄﾞ
②公開鍵
から秘密
鍵を解読
第3者が同一の
秘密鍵を作成
悪用例：
証明書の持ち主に成りすまして、あらゆることができてしまう。
業務ｼｽﾃﾑ
①成りすましのログイン
証明書
②偽の口座変更
③偽の立替払申請
④偽の退職申請
・・・
秘密鍵
公開鍵
37
不正な処理
Copyright 2013 FUJITSU LIMITED
2010年問題・署名(SHA-1)の衝突問題
衝突問題（Collision）
署名対象
データ①
ハッシュ値計算
［SHA-1］
ハッシュ値
一致しないはずの
値が一致!!
160bit
署名対象
データ②
ハッシュ値計算
［SHA-1］
ハッシュ値
160bit
悪用例：
これに署名
してください
ｺﾘｼﾞｮﾝが起こる
ﾒｯｾｰｼﾞﾍﾟｱ
1万円/月
契約書
契約書
③
契約書
2万円/月
①
偽契約書
④偽契約書
に差し替えて
口座引き落
とし
偽契約書
署名検証も
成功！
38
②契約書への
電子署名
ﾒｯｾｰｼﾞには一定の構造を持つことが
要求されるため、実際の運用上
リスクは少ないと言われている。
Copyright 2013 FUJITSU LIMITED
製品体系
Systemwalker PKI Manager（本体のみ）
・基本モデル（100ユーザまで）
Systemwalker PKI Manager（オプション追加）
・ユーザ追加ライセンス
500, 1000, 2000, 5000, 10000, 20000, 50000, 100000の８パターン
PKI Manager オプション追加
PKI Manager本体のみ
39
Copyright 2013 FUJITSU LIMITED
40
Copyright 2013 FUJITSU LIMITED