HSM用ミドルウェア Conduit Toolkitの概要と使い方

HSM用ミドルウェア
Conduit Toolkitの概要と
使い方
2009-07-03
Sarion Systems Research
ソフトウェア開発部中村浩士
Copyright © 2009 Sarion Systems Research All rights reserved.

内容
1. SEEのプログラミングモデル
1-1. SEEの仕組み
1-2. プログラミングモデル
1-3. SEE開発の注意点
2. HSM用ミドルウェアConduit Toolkitの機能と利点
2-1. Conduit Toolkitとは
2-2. Conduit Toolkitのプログラミングモデル
2-3. 機能と利点
2-4. Conduit Toolkitを利用したシステム構成
2-5. プログラミングモデルの比較
3. Conduit Toolkitによる開発の流れ
4. 最後に

1. SEEのプログラミングモデル

クライアントホスト nCipher HSM
• Thales社のnCipher HSMには、暗号処理機能、
鍵管理機能、NVRAM、 RTCが備わっている
（nCore API経由で利用）
• 加えて、独自処理をHSM内部に実装・実行可能
（CodeSafe API経由で利用）
暗号処理モジュール
鍵管理モジュール
NVRAM
RTC
ホスト
プロセス
SEE
プロセス
nCore API
CodeSafe API
nCore API

SEEプロセスのライフサイクル
1. SEEのプログラミングモデルに従って開発後、
gccでクロスコンパイル。
2. HSM起動時にHSM内部に読み込む。
3. ホストプロセスからの指示により、読み込んでお
いたコードを、SEEプロセスとして初期化。
4. コマンド入力キュー、出力キューの2つを介して
通信。他に外界との接点なし。
5. プロセス終了するまで動作。1HSMに同時に存
在し得るのは1SEEプロセスのみ。
ホストプロセス
nCipher HSM
他
クライアントホスト
SEEプロセス
LAN/PCILAN/PCI
SEEコード

SEEコード開発のプログラミングモデルとして、
以下のいずれかを利用する
A) 汎用SEEライブラリ(seelib): 従来からのモデル。
ホスト、SEE共に、専用APIによる開発。
B) BSDライブラリ(bsdlib): Ver. 11で追加された。
SEEアプリをUnix BSDライブラリを使って開発。

A) 汎用SEEライブラリのモジュール構成
• SEEアプリの機能は、ホストアプリから、
CodeSafe APIの通信制御APIにより利用
ホストアプリ
（C/C++またはJava言語）
nCipher HSM
NVRAM
RTCCodeSafe
SEE
CodeSafe
SEEアプリ
（C言語）
LAN/PCILAN/PCI
専用プロトコル専用プロトコルCipherTools
nCore API
nCore API CodeSafe API CodeSafe API

B) BSDライブラリのモジュール構成
• SEEアプリが、ホスト上のproxyを介してソケット、
標準入出力を公開し、ホストアプリや外部から利用
• SSLサーバライブラリが利用可能で、
SSLエンドポイントをHSM内部に引き込める
ホストアプリ
（言語は任意）
nCipher HSM
NVRAM
RTC
CodeSafe
SEE
TCP
proxy
SEEアプリ
（C言語）
PCIPCI
専用プ
ロトコル
専用プ
ロトコル
CipherTools
bsdlib
TCP
ncssl
nCore API
nCore APIUnix socket API
Unix socket API

BSDライブラリの制限（Ver 11.10）
現行バージョンでは、BSDライブラリはnetHSMで
は動作しない。nShieldでのみ利用可能。
SSLサーバライブラリにはX.509証明書サポートは
含まれない。そのためクライアント認証は個別実
装する必要がある。
利用可能であれば、セキュリティプロトコルの変換
フィルタに適している。

1. SEEアプリの動作環境がHSMに守られており、
外界との通信、開発中のデバッグ、実稼働中の
障害分析に手間がかかる。
2. nCipher HSMの鍵管理の仕組み（ホストアプリ
との協調動作）を理解していないと、性能問題を
引き起こし易い。（SEEでの処理のほとんどは、鍵
を利用した暗号処理）
3. 可用性確保のための設計が必要。

2. HSM用ミドルウェアCONDUIT
TOOLKITの機能と利点

1. SEEアプリを利用する上で必要となる各種機能を
ソフトウェアライブラリとしてパッケージ化
• アプリケーション開発を支援する機能を提供し
開発期間の短縮化、高品質化に貢献
2. 水平展開による可用性向上
3. 弊社開発での利用実績

• 汎用SEEライブラリを拡張
• ホスト側、SEE側にライブラリ提供
• ホスト – SEE間はRPC通信
ホストアプリ
（C/C++またはJava言語）
nCipher HSM
NVRAM
RTC
CodeSafe
SEE
CodeSafe
SEEアプリ
（C言語）
LAN/PCILAN/PCI
専用プロトコル専用プロトコル
CipherTools
Conduit
Toolkit Core
Part
Conduit
Toolkit
Stub Part
拡張プロトコル拡張プロトコル
RPCRPC
nCore API
nCore API

SEE開発の注意点に照らしつつ、
Conduit Toolkitの機能を紹介
1. アプリケーション開発サポート機能
A) RPC通信管理
B) サイドストリームロギング
C) 鍵管理
2. 可用性向上機能
D) 冗長化対応（負荷分散および障害回復）
E) 複数クライアント対応

a) ホスト – SEE間通信でのトラブル
• 一度に送信可能なデータサイズが8K弱に
制限されている（bsdlibでは制限なし）
• ホストからポーリングする生の半二重通信で、
手続きミスによる通信エラーでトラブルになり易い
（bsdlibではUnixスタイルのソケット）
• データタイプのサポートがなく、構造化データの
送受信処理が煩雑
（通常、エラーコード、ユーザ情報、鍵データ、
暗号化パラメータ、署名結果などの転送が必要）

A) RPC通信管理機能
• ホスト – SEE間で、RPCによる通信を可能に
• RPCコードジェネレータ（ホスト側、SEE側）
• RPC通信管理ライブラリ
• SEE側は、Cの関数として独自処理を実装
• ホスト側から、Cの関数、またはJavaのメソッドと
して透過的に呼び出し可能
ホストアプリ
nCipher HSM
NVRAM
RTCCodeSafe
SEE
CodeSafe
SEEアプリ
LAN/PCILAN/PCI
CipherTools
Core PartStub Part 拡張プロトコル拡張プロトコル
Sun RPCSun RPC

b) デバッグ、実稼働中の障害分析でのトラブル
• HSM環境をデバッグオプション付きで構成すれば、
SEEアプリからのprintf出力バッファが利用可能。
• バッファサイズに3KBの制限があり、
実行トレースを保存するには足りない。
• 実行後、コマンド呼び出しによる参照が必要で
手間がかかる。
• 実働環境での利用は想定しづらい。

B) サイドストリームロギング機能
• SEE用ログメッセージAPIをライブラリとして提供
• SEE内部で出力したログを、セキュアかつ自動的
にホスト側に転送し、ファイル出力。
• RPC通信と共存する透過的なログ転送機構
ホストアプリ
nCipher HSM
NVRAM
RTCCodeSafe
SEE
CodeSafe
SEEアプリ
LAN/PCILAN/PCI
CipherTools
ログ
ログAPI

c) 鍵管理でのトラブル
• nCipher HSMの鍵管理の仕組みを理解していな
いと、性能問題を引き起こし易い
• SEEアプリでの鍵の利用
1.ホスト側でnCore APIを利用し鍵を
HSMに読み込み、チケット入手。（遅い）
2.SEE側にチケットを転送。
3.SEE側でチケットから鍵を復元・利用。
• カタログ性能を出すには、ホスト側でチケット
のキャッシュが必須だが、設計上、簡単には
実現できない場合が往々にして存在する
• アクセス権限APIが複雑かつデバッグが困難なた
め、SEE側で権限不足によるトラブルが起こり易い

C) 鍵管理機能
• RPC構造体として鍵オブジェクトを定義
ホスト側では鍵IDのみ渡せばよい。
• SEE側への転送時、自動的にチケットの取得
とキャッシュを行う。 HSMを再起動した場合で
も、必要に応じて自動的に再キャッシュ。
• SEE専用鍵の自動構成
• SEE専用鍵を利用するために必要な証明書を
自動送信・自動インポート
ホストアプリ
nCipher HSM
NVRAM
RTCCodeSafe
SEE
CodeSafe
SEEアプリ
LAN/PCILAN/PCI
CipherTools
鍵ID 鍵チケット

d) 可用性確保に関するトラブル
• nCore APIによる暗号モジュール利用には負荷
分散機能があるが、SEE利用時には効果がない
• 必要な場合はホスト側で、処理の振り分け、
障害検知、回復を独自実装する必要がある。
• 1つのSEEプロセスに、複数クライアントから接続
できない（共用不可）
• SEEの暗号処理機能を、冗長化されたアプリ
ケーションサーバ等から利用する際に問題と
なる。
• 複数クライアントから利用可能にするため、
接続のたびにSEEプロセスを初期化すると、
大幅な性能劣化。

nCore APIによる暗号処理の負荷分散
• クライアントとnShieldは1対1
• クライアントとnetHSMは多対多
• 障害発生時は他のモジュールに自動で処理を振
り分け
クライアント
netHSM
クライアント
netHSM
nShield
クライアント
クライアント

CodeSafe APIによるSEE通信の負荷分散
• SEEプロセスに関する制限が厳しい
• ホストプロセスとSEEプロセスは1対1
• 1HSMにつき同時に最大1SEEプロセス
• SEEプロセスと通信できるのは、それを起動し
たホストプロセスだけ
nShieldクライアント
netHSMクライアント
netHSMクライアント

D) 冗長化対応（負荷分散および障害回復）
Conduit Toolkitによる可用性向上
• 複数HSMに同一SEEを配備しての負荷分散に
対応。
• HSMの稼動状態をモニタリングし、障害・復旧の
検知と自動リカバリ。
• 運用管理機能を、コマンドラインプログラムとして
提供。

E) 複数クライアント対応
外部システムでの冗長化環境への対応
• 冗長化された複数のアプリケーションサーバプロ
セスから、1つのSEEプロセスを共有可能。

• 3つの構成が可能
• 必要な機能に応じた構成を選択
機能 A) 単一構成 B) SEE共有構成 C) 冗長化構成
障害回復 ○ ○ ○
複数クライアント × ○ ○
負荷分散 × × ○
モニタリング ○ ○ ○

A) 単一構成
ホストアプリ
nCipher HSM
暗号処理
鍵管理
NVRAM
RTC
SEEアプリ
LAN/PCILAN/PCI
Core Part
冗長化
クライアント
RPCRPC
冗長化
サーバー
拡張
プロトコル
拡張
プロトコル
SSL
相互認証
SSL
相互認証
• 冗長化サーバー
• HSM障害・復旧の検出とリカバリ。
• クライアントとHSMの中間に位置して、
鍵キャッシュ機能を提供。
• 冗長化クライアント
• 正常に動作している冗長化サーバーにのみ、
処理リクエストを振り分け。

B) SEE共有構成
• 冗長化サーバーを別ホストに分離。
• 複数クライアントから接続可能。
nCipher HSM
クライアント
ホスト
LAN/PCILAN/PCI
冗長化
サーバー
ホスト
クライアント
ホスト
LANLAN
LANLAN
ホストアプリ
nCipher HSM
暗号処理
鍵管理
NVRAM
RTC
クライアント
ホスト
SEEアプリ
Core Part
冗長化
クライアント
RPCRPC
冗長化
サーバー
拡張
プロトコル
拡張
プロトコル
SSL
相互認証
SSL
相互認証
冗長化
サーバー
ホスト
LANLAN LAN/PCILAN/PCI

C) 冗長化構成
• 冗長化サーバーとHSMのペアを水平展開。
nCipher HSM
クライアント
ホスト
拡張プロトコル
LAN/PCI
拡張プロトコル
LAN/PCI
冗長化
サーバー
ホスト
クライアント
ホスト
SSL相互認証
LAN
SSL相互認証
LAN
nCipher HSM
冗長化
サーバー
ホスト
nCipher HSM
冗長化
サーバー
ホストクライアント
ホスト
クライアント
ホスト

障害発生時の挙動: HSMが停止
• 冗長化サーバーがHSMの障害を検出した後は、
冗長化クライアントからの処理要求にエラー通知。
• 冗長化クライアントは他の冗長化サーバーに
処理を再送する。
• 以後該当サーバーへの処理振り分けは行わない。
nCipher HSM
クライアント
ホスト
冗長化
サーバー
ホスト
クライアント
ホスト
nCipher HSM
冗長化
サーバー
ホスト
nCipher HSM
冗長化
サーバー
ホスト
クライアント
ホスト

障害発生時の挙動: 冗長化サーバーが停止
• 冗長化クライアントが切断を検出し、
他の冗長化サーバーに処理を再送する。
• 以後該当サーバーへの処理振り分けは行わない。
nCipher HSM
クライアント
ホスト
冗長化
サーバー
ホスト
クライアント
ホスト
nCipher HSM
冗長化
サーバー
ホスト
nCipher HSM
冗長化
サーバー
ホスト
クライアント
ホスト

障害からの復旧
• 冗長化サーバーは障害を検知したHSMに対し、
定期的に初期化を実行。
• 冗長化クライアントは定期的に冗長化サーバーの
ステータスをチェック。
• 復旧した冗長化サーバーを振り分け対象に戻す。
nCipher HSM
クライアント
ホスト
冗長化
サーバー
ホスト
クライアント
ホスト
nCipher HSM
冗長化
サーバー
ホスト
nCipher HSM
冗長化
サーバー
ホスト
クライアント
ホスト

seelib bsdlib
Conduit
Toolkit
通信独自ソケット RPC
ログ取得独自対応
ホスト上に
標準エラー出力
ホスト上に
ファイル出力
鍵管理支援 × × ○
障害回復 × × ○
複数クライアント × △(*1) ○
負荷分散 △(*2) × ○
netHSM対応 ○ × ○
(*1) 複数クライアントから同時にTCP通信することが可能だが、セキュアにするためにはncsslなどを
利用し、独自に認証、暗号化、署名が必要になる。
(*2) 独自に複数HSMとの接続を管理し、個別に読み込んだ鍵チケットを1つにマージした上で利用
する、という対応が必要。障害に弱い。

3. Conduit Toolkitによる開発
の流れ
3-1. コーディング
3-2. サービス配備

3-1. コーディング
1. 関数呼び出しインタフェース定義
（RPC記述ファイル作成）
2. RPCスタブコード生成
3. ホスト側プログラム開発（関数呼び出し側）
4. SEE側プログラム開発（関数の実装）
サンプル
• 指定した鍵により、SEE内部で独自アルゴリズ
ムによる署名を行う。
• SEE専用鍵として構成し、SEE外部からは利用
できないようにする。

1. 関数呼び出しインタフェース定義
typedef unsigned char message<>;
typedef unsigned char signature<>;
enum sign_ret_enum {
SIGN_RET_OK = 0,
SIGN_RET_FAIL = 1,
SIGN_RET_ARGS = 2,
SIGN_RET_NOMEM = 3,
SIGN_RET_MAX
};
typedef enum sign_ret_enum sign_ret;
struct sign_response {
sign_ret retcode;
signature signature;
};
struct sign_request {
message msg;
PSCKeyInfo key;
};
署名対象と署名のデータ型定義
署名結果定義
署名関数定義
program SIGN_PROG {
version SIGN_PROG_VER {
sign_response
do_sign(sign_request) = 1;
}= 1;
} = 0x20000001;
署名結果構造体: 署名結果 + 署名
署名リクエスト: 署名対象 + 鍵

2. RPCスタブコード生成
C:¥> C:¥PrimeSignerConduit¥bin¥psrpcgen ‐M sign.x
生成ファイル:
sign.h
ホストプログラム・SEEプログラム共通ヘッダーファイル
sign_psdr.c
ヘッダーファイルで定義されたデータ型の変換を行うモジュール
sign_clnt.c
ホストプログラム側スタブコード
sign_svc.c
SEEプログラム側スタブコード
SIGN_PROG_1.java
ホストプログラム側スタブクラス
message.java、sign_ret.java、signature.java、
sign_response.java、sign_ret_enum.java、sign_request.java
定義した個々のデータ型に対応するクラス

3. ホスト側プログラム開発（C/C++言語）
...
client = clnt_psrpc_create("localhost", SIGN_PROG, SIGN_PROG_VER,
"psconduit");
PSCKeyInfo_construct(&request.key);
PSCString_set(&request.key.keyname, strlen(keyname), keyname);
request.msg.message_len = (u_int)strlen(signedMessage);
memcpy(request.msg.message_val, signedMessage,
request.msg.message_len);
rv = do_sign_1(client, &request, &response);
if (rv == RPC_SUCCESS) {
printf("%d bytes¥n", response.signature.signature_len);
clnt_psrpc_freeres(client, psdr_sign_response, &response);
}
PSCKeyInfo_destruct(&request.key);
...
RPC通信の初期化
SEEに渡す署名鍵を指定
署名対象を指定
SEE側署名関数を呼び出し

3. ホスト側プログラム開発（Java言語）
...
final SIGN_PROG_1 proxy = new SIGN_PROG_1();
final PSCKeyInfo keyinfo = new PSCKeyInfo() ;
keyinfo.setKeyName( keyname ) ;
final message msg = new message();
msg.setValue(signedMessage.getBytes());
final sign_request request = new sign_request();
request.setKey(keyinfo);
request.setMsg(msg);
sign_response res = proxy.do_sign(request);
if (res.getRetcode().getValue() != sign_ret_enum.SIGN_RET_OK) {
System.out.println("error: " + res.getRetcode().getValue());
return;
}
System.out.println("succeeded");
System.out.println(encoder.encode(res.getSignature().getValue()));
...
proxyオブジェクトの生成
SEEに渡す署名鍵を指定
署名対象を指定
SEE側署名関数を呼び出し

4. SEE側プログラム開発
...
bool_t do_sign_1_svc(sign_request *argp, sign_response *res)
{
M_KeyID keyid = 0;
if (argp‐>msg.message_len == 0) {
WARN_LOG("empty message");
res‐>retcode = SIGN_RET_ARGS;
return TRUE;
}
res‐>retcode = redeem_ticket(&argp‐>key, &keyid);
if(res‐>retcode != SIGN_RET_OK){
return TRUE;
}
res‐>retcode = sign(&argp‐>msg, keyid, &res‐>signature);
destroy_key(keyid);
return TRUE;
}
...
ホストから呼び出される関数の定義
argp->keyの中に、自動的に取得された
鍵チケットがセットされている
チケットから鍵ハンドルを取得する
（nCore APIプログラミング部分は省略）
鍵ハンドルを利用して
独自アルゴリズム署名を行う（省略）

3-2. サービス配備
1. ホストアプリのビルド
• Visual Studio等ホスト側コンパイラでコンパ
イルし、Conduit Toolkitのライブラリと共に
リンク
2. SEEアプリのビルド
• gccでのクロスコンパイル後、Conduit
Toolkitのライブラリと共にリンク
• CodeSafeに添付のツールを利用し、
SEEコードを生成
• 冗長化サーバーに、SEEコードを指定
（自動読み込みのため）
3. 冗長化サーバーの起動

4. 最後に
4-1. Conduit Toolkitの利点
4-2. HSMを活かした独創的なサービスの構築を

4-1. Conduit Toolkitの利点
• コード開発の難易度が下がる
• 煩雑な通信処理、鍵管理処理がカプセル化される
• プログラマはアプリケーションロジックに専念できる
• 開発工数の削減
• 下請けルーチンがライブラリとして提供される
• デバッグを支援する機能が提供される
• 設計が容易になる
• Conduit ToolkitのRPCモデルに従って設計をする
• 可用性確保が容易になる
• nCipher HSMの稼動原理と、負荷分散、障害回復
実装テクニックの詳細が隠蔽される
• サービス開始後に性能が足りなくなってからの
水平展開

4-2. HSMを活かした独創的なサービスの構築を
サービスの実現、運用、継続のため
必要なセキュリティーレベルに応じた選択肢
構築するサービスの例要件 HSM活用
署名・暗号化による
サービス間連携
鍵の漏洩防止が必要 nCipher HSM
複数サービスでHSMを共有鍵の不正利用防止も必要 + SEE
クレジット会社からカード番号
とパスワードを預かる
鍵だけではなく、データの漏
洩防止も必要
+ SEE
サービス運用が外部委託
鍵だけではなく、プログラム
の改ざん防止も必要
+ SEE
開発リスクを低減したい
素早くプロトタイプ実装で
フィージビリティーチェック
+ Conduit Toolkit
自動運用で耐障害性が必須
必要な性能に応じた導入計画
性能向上、耐障害性向上を
狙った水平展開
+ Conduit Toolkit

お問い合わせ
• 株式会社サリオンシステムズリサーチ
• 〒101-0054 東京都千代田区神田錦町3-23 西
本興産錦町ビル14F
• 電話: 03-5217-2980（代） FAX: 03-5217-3590
• お問い合わせ: prod_contact@sarion.co.jp
• Web: http://www.sarion.co.jp
※本セミナーの弊社資料は、
上記ウェブサイトからダウンロードできます。

HSM用ミドルウェア Conduit Toolkitの概要と使い方

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to HSM用ミドルウェア Conduit Toolkitの概要と使い方

Similar to HSM用ミドルウェア Conduit Toolkitの概要と使い方 (20)

More from Hiroshi Nakamura

More from Hiroshi Nakamura (9)

HSM用ミドルウェア Conduit Toolkitの概要と使い方