PKCS #11 -標準プランの紹介
PKCS #11 とは、暗号情報を保管して暗号関数を実行するデバイスのために、Cryptoki という名前のアプリケーション・プログラミング・インターフェース (API) を規定した標準です。 Cryptoki API は、シンプルなオブジェクト・ベースの手法に従っています。 この手法では、テクノロジーの独立性とリソースの共有という目標を達成するために、デバイスを表す共通の論理的視点 (暗号トークン) をアプリケーションに与えます。
Cryptoki は、アプリケーションを暗号デバイスの細部から切り離します。 デバイスの種類に応じてアプリケーションのインターフェースを変更したり別の環境で実行したりする必要はありません。 つまり、アプリケーションがポータブルになります。Cryptoki API の関数は、以下のとおりに分類されます。
- 汎用関数 (4 つの関数)
- スロットおよびトークン管理機能 (9 つの機能)
- セッション管理機能 (8 つの機能)
- オブジェクト管理機能 (9 つの機能)
- 暗号化機能 (4 つの機能)
- Decryption 関数 (4 つの関数)
- メッセージ・ダイジェスト関数 (5 つの関数)
- 署名、検証、および MAC 機能 (12 機能)
- 二重目的暗号関数 (4 つの関数)
- 鍵管理機能 (5 つの機能)
- 乱数生成関数 (2 つの関数)
- 並列機能管理機能 (2 つの機能)
PKCS #11 のすべての関数が IBM Cloud® Hyper Protect Crypto Services に実装されているわけではありません。 実装されている PKCS #11 関数については、サポートされている PKCS #11 関数を参照してください。
PKCS #11 標準の資料については、以下を参照してください。
- Cryptographic Token Interface Usage Guide バージョン 2.40
- Cryptographic Token Interface Base Specification Version 2.40 Plus Errata 01
- 暗号トークン・インターフェースの現行メカニズム仕様バージョン 2.40 プラス・エラッタ 01
PKCS #11 実装コンポーネント
PKCS #11 API を接続して使用するには、Hyper Protect Crypto Services に実装されている PKCS #11 API について理解し、この API と GREP11 API の関係についても理解する必要があります。 詳しくは、PKCS #11 API と GREP11 API の比較を参照してください。 PKCS #11 API をサポートするため、PKCS #11 標準を使用する既存のアプリケーションは変更不要です。Hyper Protect Crypto Services では、PKCS #11 機能によって生成された暗号キーを保管するための分離されたキー・ストアもご用意しています。 これらの鍵はマスター鍵で保護されるので、アプリケーションがローカルで鍵ファイルを認識することはありません。
PKCS #11 の API を使用するには、最初に PKCS #11 ライブラリーをインストールします。 この方法で、PKCS #11 アプリケーションが PKCS #11 ライブラリーと対話し、ライブラリーが、Hyper Protect Crypto Services に実装されている暗号関数を gRPC 経由で呼び出せるようになります。 以下の図に、Hyper Protect Crypto Services の PKCS #11 ライブラリーに実装されている主なコンポーネントと、さまざまなコンポーネント間で行われる対話を示しています。
これ以降のセクションでは、PKCS #11 の各コンポーネントについて詳しく説明します。
アプリケーション
1 つのアプリケーションは 1 つのアドレス・スペース内で実行されます。 すべての制御スレッドがアプリケーション内で実行されます。 いずれかのスレッドから Cryptoki の関数 C_Initialize
を呼び出すと、そのアプリケーションは Cryptoki アプリケーションになります。 この呼び出しを行うと、アプリケーションは他の Cryptoki 関数を呼び出せるようになります。 Cryptoki の使用が終了したら、アプリケーションは Cryptoki
の関数 C_Finalize
を呼び出し、Cryptoki アプリケーションであることを止めます。
IBM Z (s390x) プラットフォームで SunPKCS11 プロバイダーを使用して Java PKCS #11 アプリケーションを実行する場合は、アプリケーションの開始時に必ず最新の IBM Semeru JVM を使用し、 -Xjit:noResumableTrapHandler
Java オプションを指定してください。 IBM Semeru Runtime Downloads ページで 「Architecture」 フィルター・フィールドを s390x に変更することにより、 IBM Semeru JVM の最新バージョンである s390x をダウンロードできます。
ユーザー
PKCS #11 標準では、セキュリティー・オフィサー (SO) と一般ユーザーという 2 つのタイプのログイン・ユーザーが規定されています。Cryptoki の関数 C_Login
を使用してログインしないユーザーは、匿名ユーザーとも呼ばれます。一般ユーザーのみがトークンのプライベート・オブジェクトにアクセスできますが、そのアクセスはその一般ユーザーが認証されないと許可されません。 Hyper Protect Crypto Services の
PKCS #11 実装では、セキュリティー・オフィサーと一般ユーザーは API キーを使用して認証を受けます。 匿名ユーザーもサポートされます。PKCS #11 のユーザー・タイプをセットアップする方法については、PKCS #11 のユーザー・タイプをセットアップするためのベスト・プラクティスを参照してください。
セッション
Cryptoki API では、トークンのオブジェクトおよび関数にアクセスするために、アプリケーションがトークンとのセッションを 1 つ以上開く必要があります。 セッションは、アプリケーションとトークンの間に論理的な接続を提供します。 セッションは、読み取り/書き込み (R/W) のセッションにするか、読み取り専用 (R/O) のセッションにすることができます。
トークンのプライベート・オブジェクトにアクセスするには、通常のユーザーがログインする必要があり、認証されます。 セッションの詳細については、「 PKCS #11 Cryptographic Token Interface Usage Guide 」を参照してください。
鍵オブジェクト
キー・オブジェクトは、PKCS #11 アプリケーションに存在するインメモリー・キー・ストアかデータベース支援型のキー・ストアのいずれかに保管されます。鍵オブジェクトの CKA_TOKEN 属性を true
に設定した場合、その鍵オブジェクトはデータベース・ベースの鍵ストアに保管されます。 そうでない場合、鍵オブジェクトはインメモリー鍵ストアに保管されます。
メモリー内の鍵ストア内の鍵オブジェクトは、マスター鍵のローテーション後に自動的にローテートされません。 サービス・インスタンスで PKCS #11 鍵ストアが有効になっている場合は、マスター鍵のローテーションの完了後に、すべてのアクティブな PKCS #11 アプリケーションを再始動して、メモリー内の鍵ストアをクリアする必要があります。
以下の図に示すように、PKCS #11 の鍵オブジェクトは、PKCS #11 のオブジェクト・クラスの例の 1 つです。
- データ: データ・オブジェクトは、アプリケーションで定義されます。
- 証明書: 証明書オブジェクトには証明書が保管されます。
- 鍵: 鍵オブジェクトには暗号鍵が保管されます。キーには、パブリック・キー、プライベート・キー、シークレット・キーがあります。 これらの鍵のタイプごとに、特定のメカニズムで使用するためのサブタイプがあります。
- 公開鍵: 鍵ペアの秘密鍵のほうにアクセスできる特定の受信者に宛てたメッセージを暗号化するために誰でも使用できる、鍵ペアの公開コンポーネント。 公開鍵は、秘密鍵で作成された署名の検証にも使用されます。
- 秘密鍵: メッセージの復号に使用される、鍵ペアの非公開コンポーネント。 秘密鍵は、署名の作成にも使用されます。
- 共通鍵: 共通鍵は、メッセージの対称的な暗号化と復号に使用するために生成されたビット列です。
Cloud Identity and Access Management
IBM の Cloud Identity and Access Management (IAM) で、PKCS #11 の API 実装のためのユーザー認証とアクセス制御を行うことができます。PKCS #11 ライブラリーは API キーを使用して、Cryptoki の API 呼び出しの実行に使用するベアラー・トークンを取得します。
この PKCS #11 の実装では、API キーがユーザーの PIN に相当します。 サービス ID および対応する API キーのセットアップの詳細については、SO ユーザー、一般ユーザー、匿名ユーザーのサービス ID の作成を参照してください。
暗号サービス
PKCS #11 ライブラリーの初期設定プロセスの一部として、PKCS #11 ライブラリーから IBM Cloud への gRPC 接続が確立されます。 gRPC 接続により、PKCS #11 ライブラリーが Cryptoki 関数 (C_Encrypt
、C_Decrypt
、C_Sign
、C_Verify
など) を呼び出せるようになりますが、これにはハードウェア・セキュリティー・モジュール
(HSM) を使用する必要があります。
キーストア
2 つの主要なタイプの鍵ストアを利用できます。
- インメモリー鍵ストア: 鍵オブジェクトをメモリー内に一時的に保管します。 インメモリー鍵ストアに保管された鍵オブジェクトは、セッション・オブジェクト とも呼ばれます。 特定のセッションのセッション・オブジェクトは、そのセッションで
C_CloseSession
関数を呼び出すと破棄されます。C_Finalize
関数を呼び出すと、すべてのセッションのセッション・オブジェクトが破棄されます。 - データベース・ベース鍵ストア: 鍵オブジェクトをデータベースに保管します。 データベース・ベース鍵ストアに保管された鍵オブジェクトは、トークン・オブジェクト とも呼ばれます。
sessionauth
パラメーターが有効で、鍵ストアのパスワードが構成されている場合、データベース・ベース鍵ストアは暗号化されて認証されます。 デフォルトでは、sessionauth
パラメーターは無効になっています。 サービス・インスタンスごとに、最大 5 つの鍵ストアの認証がサポートされます。sessionauth
パラメーターを有効にすると、生成された鍵を暗号化して鍵ストアに保管したり、鍵を使用する前に復号したりすることができます。 パスワードは 6 文字から 8 文字にできます。
鍵ストアのパスワードはサービス・インスタンスに保管されません。 鍵ストア管理者は、パスワードのローカル・コピーの保守を担当します。 パスワードを失くした場合は、サポート・チームに連絡して鍵ストアをリセットする必要があります。これは、鍵ストア内のすべてのデータがクリアされることを意味します。
インメモリー鍵ストアとデータベース・ベース鍵ストアの両方が、以下のタイプの鍵ストアで構成されます。
- パブリック鍵ストア: 機密性が低く、すべてのユーザー・タイプからアクセスされる鍵を保管します。
- プライベート鍵ストア: 機密データを暗号化し、一般ユーザーのみからアクセスされる鍵を保管します。
ユーザー・タイプと鍵属性の設定に応じて、生成される鍵が異なる鍵ストアに保管されます。 以下のリストは、鍵の保管方法の基準を要約したものです。
-
CKA_TOKEN 属性値は、生成された鍵がインメモリー鍵ストアとデータベース・ベース鍵ストアどちらに保管されるかを設定します。
データベース・ベース鍵ストアに鍵を保管する場合は、鍵または鍵ペアの生成テンプレートで CKA_TOKEN を
TRUE
に設定します。 PKCS #11 ライブラリーの初期設定プロセスで、IBM Cloud との gRPC 接続が確立されます。これによって、データベース・ベースの鍵ストアで行う鍵オブジェクトの保管や取得が簡単になります。 デフォルトでは、CKA_TOKEN はFALSE
に設定されます。つまり、鍵オブジェクトは、PKCS #11 アプリケーションのプロセス・アドレス・スペース内部のインメモリー鍵ストアに保管されます。 -
CKA_PRIVATE 属性値は、通常のユーザーによって生成される鍵がパブリック鍵ストアとプライベート鍵ストアのどちらに保管されるかを決定します。
デフォルトでは、ユーザーが通常のユーザーとしてログインしている場合、生成された鍵はプライベート鍵ストアに保管されます。ただし、CKA_PRIVATE が
FALSE
に設定されている場合は除きます。 ユーザーが SO ユーザーとしてログインしているか、ログインしていない (匿名ユーザーと呼ばれる) 場合、生成された鍵は常にパブリック鍵ストアに保管されます。 SO ユーザーまたは匿名ユーザーが鍵生成テンプレートで CKA_PRIVATE をTRUE
に指定すると、サーバーからエラーが返されます。非対称鍵ペアの場合、公開鍵と秘密鍵の両方で CKA_PRIVATE 属性を別個に設定する必要があります。つまり、鍵ペアを異なる鍵ストアに保管することができます。
ユーザー・タイプ、鍵属性、鍵ストアの間の関係、および鍵の保管方法について詳しくは、以下の表を参照してください。
ユーザー・タイプ | CKA_TOKEN | CKA_PRIVATE | 鍵の鍵ストア | プライベートかパブリックか |
---|---|---|---|---|
SO ユーザー | FALSE |
N/A | インメモリー・キー・ストア | パブリック |
SO ユーザー | TRUE |
N/A | データベース支援型キー・ストア | パブリック |
匿名ユーザー | FALSE |
N/A | インメモリー・キー・ストア | パブリック |
匿名ユーザー | TRUE |
N/A | データベース支援型キー・ストア | パブリック |
一般ユーザー | FALSE |
FALSE |
インメモリー・キー・ストア | パブリック |
一般ユーザー | FALSE |
TRUE |
インメモリー・キー・ストア | プライベート |
一般ユーザー | TRUE |
FALSE |
データベース支援型キー・ストア | パブリック |
一般ユーザー | TRUE |
TRUE |
データベース支援型キー・ストア | プライベート |
ポスト量子暗号化後のサポート
PKCS #11 API を使用して、 量子暗号後 操作を実行することもできます。 従来の暗号化は、従来のコンピューターでは解決が難しい複雑な数学的問題に依存しています。 しかし、コンピューティング能力によって、量子コンピューターはこれらの問題を解決することができます。 ポスト量子暗号化後は、量子コンピューターからの暗号分析攻撃に対して抵抗性があると考えられています。 通常は非対称アルゴリズムを使用し、複数のアプローチがあります。
PKCS #11 API には、量子暗号化後のための Dilithium アルゴリズム が用意されています。 これは、格子ベースのデジタル署名スキームであり、署名の生成と検証に使用できます。 現在、 高セキュリティー・バージョンのラウンド 2 Dilithium のみがサポートされており、 C_SignUpdate
および C_VerifyUpdate
の操作には使用できません。
Dilithium アルゴリズムは、IBM 4769 暗号カード (Crypto Express 7S (CEX7S) とも呼ばれる) でのみサポートされます。 CEX7S 暗号カードが使用されている仮想プライベート・クラウド (VPC) ベースのリージョンでインスタンスを作成する場合は、PKCS #11 API を使用して、ポスト量子暗号化後の Dilithium アルゴリズムを使用できます。 VPC ベースのリージョンのリストについては、地域とロケーションを参照してください。
PKCS #11での Dilithium アルゴリズムのサポートについて詳しくは、PKCS #11 API リファレンスを参照してください。 Dilithium アルゴリズムのコード例は、 GitHub サンプル・リポジトリーにもあります。