message GetMechanismListRequest {
    }
    message GetMechanismListResponse {
      repeated uint64 Mechs = 2;
    }
    

    CK_RV m_GetMechanismList (
      CK_SLOT_ID slot,
      CK_MECHANISM_TYPE_PTR mechs, CK_ULONG_PTR mechslen,
      target_t ターゲット
    );
    

C_GetMechanismList は、トークンでサポートされるメカニズム・タイプのリストを取得します。 SlotID はトークンのスロットの ID、pulCount はメカニズムの数を受け取る場所のポインターです。

アプリケーションで C_GetMechanismList を呼び出すには、2 つの方法があります。

1. pMechanismList を NULL_PTR にすると、C_GetMechanismList は、メカニズムのリストを返すことなく、メカニズムの数だけを (* pulCount で) 返します。 この場合、C_GetMechanismList に入力する *pulCount の内容に意味はなく、呼び出しでは CKR_OK の値が返されます。
2. pMechanismList が NULL_PTR (R) でない場合、*pulCount には、pMechanismListが指すバッファーのサイズ (CK_MECHANISM_TYPE エレメントに関する) が含まれている必要があります。 そのバッファーがメカニズムのリストを保持できる大きさであれば、リストがそこに戻され、CKR_OK が返されます。 そうでない場合は、C_GetMechanismList の呼び出しで値 CKR_BUFFER_TOO_SMALL が返されます。 いずれにしても、*pulCount にはメカニズムの数が設定されます。

C_GetMechanismList は独自のスペースを割り振らないため、アプリケーションでは C_GetMechanismList を 2 回呼び出すことが多くなります。 ただし、この動作は必須ではありません。

    CK_DEFINE_FUNCTION(CK_RV, C_GetMechanismList)(
      CK_SLOT_ID slotID,
      CK_MECHANISM_TYPE_PTR pMechanismList,
      CK_ULONG_PTR pulCount
    );
    

    message GetMechanismInfoRequest {
      uint64 Mech = 2;
    }
    message GetMechanismInfoResponse {
      MechanismInfo MechInfo = 3;
    }
    

    CK_RV m_GetMechanismInfo (
      CK_SLOT_ID slot,
      CK_MECHANISM_TYPE mech,
      CK_MECHANISM_INFO_PTR mechInfo,
      target_t ターゲット
    );
    

C_GetMechanismInfo は、トークンによってサポートされる可能性がある特定のメカニズムに関する情報を取得します。slotID はトークンのスロットの ID、type はメカニズムのタイプ、pInfo は、メカニズム情報を受け取る場所を指します。

    CK_DEFINE_FUNCTION(CK_RV, C_GetMechanismInfo)(
      CK_SLOT_ID slotID,
      CK_MECHANISM_TYPE type,
      CK_MECHANISM_INFO_PTR pInfo
    );
    

    message GenerateKeyRequest {
      Mechanism Mech = 1;
      map<uint64,AttributeValue> Template = 6;
    }
    message GenerateKeyResponse {
      bytes KeyBytes = 4;
      bytes CheckSum = 5;
    }
    

PKCS #11 C_GenerateKey の実装。

TDES 鍵が生成され、適切なパリティーも生成されますが、このパリティーはホストからは見えません。 しかし、このパリティーは適切な相互運用性を確保するために必要です。他の PKCS #11 実装では、パリティーの問題がある DES 鍵を拒否する必要があります。

オブジェクトをセッションに結び付ける場合は、そのセッションへの Login で (pin, plen) が返される必要があります。 pin を NULL のままにすると、ログイン・セッションにバインドされない共通オブジェクトが作成されます。

(key, klen) は、キー blob を返します。(csum, clen) には、キーのチェックサム、つまりキーによって暗号化されたオールゼロ・ブロックの最上位バイトが含まれます。 例えば、CKA_CHECK_VALUE パラメーターのない対称鍵メカニズム (RC4 など) の場合には、NULL の clen にすることもできます。

ptempl を使用するのは、鍵の長さ (つまり CKA_VALUE_LEN 属性) が必要なメカニズムの場合に限られます。 鍵のサイズが暗黙的に指定されるメカニズムの場合は、ptempl のサイズはチェックされません。

DSA と DH のパラメーター生成では、(csum, clen) が無視され、パラメーター構造だけが生成されます。

DSA と DH のパラメーター (CKM_DSA_PARAMETER_GEN): 属性の CKA_PRIME_BITS でモジュラス・ビット・カウントが渡されます。 P、Q、G 構造が (BLOB ではなく) 平文出力として書き込まれます。

pin の BLOB は、Login からの出力です。

PKCS #11 の phKey はどの EP11 パラメーターにもマップされません (ホスト・ライブラリーで、ラップされた鍵をハンドルにバインドする必要があります)。

    CK_RV m_GenerateKey (
      CK_MECHANISM_PTR mech,
      CK_ATTRIBUTE_PTR template, CK_ULONG templatelen,
      const unsigned char *pin, size_t pinlen,
      unsigned char * key、size_t * keylen、
      unsigned char *checkSum、size_t *checkSumlen、
      target_t ターゲット
      );
    

C_GenerateKey は、シークレット・キーまたはドメイン・パラメーター・セットを生成し、新規オブジェクトを作成します。hSession はセッションのハンドル、pMechanism は生成メカニズム、pTemplate は新しいキーまたはドメイン・パラメーター・セットのテンプレート、ulCount はテンプレート内の属性の数、phKey は新しいキーまたはドメイン・パラメーターのセットのハンドルを受け取るロケーションを指します。

生成メカニズムがドメイン・パラメーター生成用である場合は、CKA_CLASS 属性の値は CKO_DOMAIN_PARAMETERS となり、それ以外の場合は値は CKO_SECRET_KEY となります。

生成する鍵またはドメイン・パラメーターのタイプは生成メカニズムに暗黙的に定義されているので、テンプレートで鍵のタイプを指定する必要はありません。 生成メカニズムと矛盾するキー・タイプが指定されている場合は、C_GenerateKey は失敗し、エラー・コード CKR_TEMPLATE_INCONSISTENT を返します。 CKA_CLASS 属性は同様に扱われます。

指定された正確なテンプレートに対応していない場合、C_GenerateKey の呼び出しは失敗し、オブジェクトを作成せずに戻ります。

C_GenerateKey の呼び出しが成功してオブジェクトが作成されると、そのオブジェクトの CKA_LOCAL 属性が CK_TRUE に設定されます。

    CK_DEFINE_FUNCTION(CK_RV, C_GenerateKey)(
      CK_SESSION_HANDLE hSession
      CK_MECHANISM_PTR pMechanism,
      CK_ATTRIBUTE_PTR pTemplate,
      CK_ULONG ulCount,
      CK_OBJECT_HANDLE_PTR phKey
      );
    

    message GenerateKeyPairRequest {
      Mechanism Mech = 1;
      map<uint64,AttributeValue> PrivKeyTemplate = 7;
      map<uint64,AttributeValue> PubKeyTemplate = 8;
      }
    message GenerateKeyPairResponse {
      bytes PrivKeyBytes = 5;
      bytes PubKeyBytes = 6;
    }
    

PKCS #11 C_GenerateKeyPair の実装。

鍵ペアのパラメーターは、pmech、ppublic、pprivate の各パラメーターから取得されます。 RSA 鍵の場合は、ppublic でモジュラス・サイズを指定します。

FIPS モードでは、1024+256 n ビットの RSA モジュラーのみがサポートされます (整数 N)。 非 FIPS モードでは、メカニズム・パラメーター・リストの制限内で偶数ビットの鍵を生成できます。

パブリック・キーは、ほとんどのライブラリーで読み取り可能な標準 SPKI (サブジェクト・パブリック・キー情報) としてフォーマットされます。 さらに、SPKI 自体に含まれていない転送鍵固有の MAC によって整合性が確保されます。 DSA パラメーター生成では、非 SPKI 構造が公開鍵フィールドに返されます。

オブジェクトをセッションに結び付ける場合は、そのセッションへの Login で (pin, plen) が返される必要があります。 pin を NULL のままにすると、ログイン・セッションの後も残る共通オブジェクトが作成されます。

ラップされた秘密鍵が (key, klen) に返され、公開鍵が MAC 署名付きの ASN.1/DER 構造として (pubkey, pklen) に返されます。

以下のサポートされているパラメーターの組み合わせと特別な注意点は、PKCS #11 の文書に記載されていないものです。

RSA 鍵は 17 (0x11) より小さい公開鍵指数を拒否します。 制御点によって、有効な最小値がさらに制限される場合もあります。 Fermat4 指数 0x10001 は、FIPS 186-3 (セクション B.3.1) の公開指数制限に合致する特定の制御点によって制御されます。

EC 鍵 (CKM_EC_KEY_PAIR_GEN): 曲線パラメーターを OID またはシンボル名 (namedCurve バリアント) として指定できます。 サポートされているシンボル名は、NIST 曲線の場合は P-nnn (nnn はサポートされている基本ビット・カウントで、192 から 521 までの範囲)、通常の BP 曲線の場合は BP-nnnR です。 (名前は、ゼロ終了なしの ASCII 文字列として指定する必要があります。)

DSA 鍵 (CKM_DSA_KEY_PAIR_GEN): 公開属性の CKA_IBM_STRUCT_PARAMS 属性として P、Q、G 構造を渡します。 個々の P、Q、G パラメーターを通常の PKCS #11 パラメーターで渡すことはできません。これらのパラメーターを 1 つの構造体にまとめる必要があります。

DH 鍵 (CKM_DH_PKCS_KEY_PAIR_GEN): 公開属性の CKA_IBM_STRUCT_PARAMS 属性として P、G 構造を渡します。 個々の P、G パラメーターを通常の PKCS #11 パラメーターで渡すことはできません。これらのパラメーターを 1 つの構造体にまとめる必要があります。 秘密鍵 (X) ビット・カウントを選択する場合は、XCP_U32_VALUE_BITS 属性を使用してください。 指定しない場合や、明示的に 0 を指定した場合は、ビット・カウントが P ビット・カウントに基づいて選択されます。

標準的な方法でセッションを使用する代わりにセッション (ログイン) の状態を使用できます。 マッピングはライブラリーの有効範囲外になります。

pin の BLOB は、Login からの出力です。

PKCS #11 の hSession はどの EP11 パラメーターにもマップされません (呼び出しはどのセッションにも直接は関連付けられません)。

PKCS #11 の phPublicKey はどの EP11 パラメーターにもマップされません (ホスト・ライブラリーで公開鍵 (SPKI) をハンドルに関連付ける必要があります)。

PKCS #11 の phPrivateKey はどの EP11 パラメーターにもマップされません (ホスト・ライブラリーで秘密鍵をハンドルに関連付ける必要があります)。

    CK_RV m_GenerateKeyPair (
      CK_MECHANISM_PTR mech,
      CK_ATTRIBUTE_PTR pubKeyTemplate, CK_ULONG pubKeyTemplatelen,
      CK_ATTRIBUTE_PTR privKeyTemplate, CK_ULONG privKeyTemplatelen,
      const unsigned char *pin, size_t pinlen,
      unsigned char *privKey、size_t *privKeylen、
      unsigned char *pubKey、size_t *pubKeylen、
      target_t ターゲット
      );
    

C_GenerateKeyPair は、パブリック・キーとプライベート・キーのペアを生成し、新しいキー・オブジェクトを作成します。hSession はセッションのハンドル、pMechanism はキー生成メカニズム、pPublicKeyTemplate はパブリック・キーのテンプレート、ulPublicKeyAttributeCount はパブリック・キー・テンプレートの属性数、pPrivateKeyTemplate はプライベート・キーのテンプレート、UlPrivateKeyAttributeCount はプライベート・キー・テンプレートの属性数、phPublicKey は新しいパブリック・キー・のハンドルを受け取るロケーション、phPrivateKey は新しいプライベート・キーのハンドルを受け取るロケーションを指します。

生成する鍵のタイプは鍵ペア生成メカニズムに暗黙的に定義されているので、テンプレートで鍵のタイプを指定する必要はありません。 いずれかのテンプレートがキー生成メカニズムと矛盾するキー・タイプを提供している場合は、C_GenerateKeyPair は失敗し、エラー・コード CKR_TEMPLATE_INCONSISTENT を返します。 CKA_CLASS 属性も同様に処理されます。

指定された正確なテンプレートに対応していない場合、C_GenerateKeyPair の呼び出しは失敗し、鍵オブジェクトを作成せずに戻ります。

C_GenerateKeyPair の呼び出しでは、1 つの鍵だけが作成されて戻るということはありません。 呼び出しが失敗して鍵が作成されないか、呼び出しが成功して対応する公開鍵/秘密鍵ペアが作成されるかのどちらかです。

C_GenerateKeyPair の正常な呼び出しによって作成されたキー・オブジェクトの CKA_LOCAL 属性は、CK_TRUE に設定されます。

C_GenerateKeyPair の引数の順序に注意してください。 最後の 2 つの引数の順序は、元の Cryptoki バージョン 1.0 の文書に記載されている順序と同じではありません。 これらの二つの引数の順序で、混乱が引き起こされた不幸な事例があります。

    CK_DEFINE_FUNCTION(CK_RV, C_GenerateKeyPair)(
      CK_SESSION_HANDLE hSession,
      CK_MECHANISM_PTR pMechanism,
      CK_ATTRIBUTE_PTR pPublicKeyTemplate,
      CK_ULONG ulPublicKeyAttributeCount,
      CK_ATTRIBUTE_PTR pPrivateKeyTemplate,
      CK_ULONG ulPrivateKeyAttributeCount,
      CK_OBJECT_HANDLE_PTR phPublicKey,
      CK_OBJECT_HANDLE_PTR phPrivateKey
      );
    

    message DeriveKeyRequest {
        Mechanism Mech = 1;
        bytes BaseKey = 3;
        bytes Data = 4;
        map<uint64,AttributeValue> Template = 8;
    }
    message DeriveKeyResponse {
        bytes NewKeyBytes = 6;
        bytes CheckSum = 7;
    }
    

PKCS #11 C_DeriveKey の実装。

basekey、bklen の BLOB を PKCS #11 の hBaseKey パラメーターからマップする必要があります。

PKCS #11 の hSession はどの EP11 パラメーターにもマップされません (呼び出しはどのセッションにも直接は関連付けられません)。

PKCS #11 の phKey はどの EP11 パラメーターにもマップされません (ホスト・ライブラリーで、返される鍵をハンドルにバインドする必要があります)。

    CK_RV m_DeriveKey (
        CK_MECHANISM_PTR mech,
        CK_ATTRIBUTE_PTR template, CK_ULONG templatelen,
        const unsigned char *baseKey, size_t baseKeylen,
        const unsigned char *data, size_t datalen,
        const unsigned char *pin, size_t pinlen,
        unsigned char *newKey、size_t *newKeylen、
        unsigned char *checkSum、size_t *checkSumlen、
        target_t ターゲット
    );
    

C_DeriveKey は、新しいキー・オブジェクトを作成して、ベース・キーからキーを導出します。hSession はセッションのハンドル、pMechanism はキー導出メカニズムを指定する構造、hBaseKey はベース・キーのハンドル、pTemplate は新しいキーのテンプレート、ulAttributeCount はテンプレートの属性数、phKey は導出されたキーのハンドルを受け取るロケーションを指します。

基本鍵の CKA_SENSITIVE、CKA_ALWAYS_SENSITIVE、CKA_EXTRACTABLE、KA_NEVER_EXTRACTABLE の各属性の値に応じて、新しく導出される鍵についてこれらの属性に保持できる値が変わります。 このタイプの制約については、PKCS #11 API 仕様のセクション 5.16.2 にある個々のキー導出メカニズムの説明を参照してください。

指定された正確なテンプレートに対応していない場合、C_DeriveKey の呼び出しは失敗し、鍵オブジェクトを作成せずに戻ります。

C_DeriveKey の呼び出しが成功して鍵オブジェクトが作成されると、そのオブジェクトの CKA_LOCAL 属性が CK_FALSE に設定されます。

    CK_DEFINE_FUNCTION(CK_RV, C_DeriveKey)(
        CK_SESSION_HANDLE hSession,
        CK_MECHANISM_PTR pMechanism,
        CK_OBJECT_HANDLE hBaseKey,
        CK_ATTRIBUTE_PTR pTemplate,
        CK_ULONG ulAttributeCount,
        CK_OBJECT_HANDLE_PTR phKey
    );
    

    message WrapKeyRequest {
        bytes Key = 1;
        bytes KeK = 2;
        bytes MacKey = 3;
        Mechanism Mech = 4;
    }
    message WrapKeyResponse {
        bytes Wrapped = 5;
    }
    

    CK_RV m_WrapKey (
        const unsigned char *key, size_t keylen,
        const unsigned char *keK, size_t keKlen,
        const unsigned char *macKey, size_t macKeylen,
        const CK_MECHANISM_PTR mech,
        CK_BYTE_PTR wrapped, CK_ULONG_PTR wrappedlen,
        target_t ターゲット
    );
    

C_WrapKey は、プライベート・キーまたはシークレット・キーをラップ (つまり暗号化) します。hSession はセッションのハンドル、pMechanism はラッピング・メカニズム、hWrappingKey はラッピング・キーのハンドル、hKey はラップ対象キーのハンドル、pWrappedKey はラップされたキーを受け取るロケーション、pulWrappedKeyLen はラップされたキーの長さを受け取るロケーションを指します。

C_WrapKey は、PKCS #11 API 仕様のセクション 5.2 で説明されている出力の生成に関する規則を使用します。

ラッピング鍵の CKA_WRAP 属性 (鍵がラッピングをサポートするかどうかを示す属性) は、CK_TRUE でなければなりません。 ラップ対象の鍵の CKA_EXTRACTABLE 属性も CK_TRUE でなければなりません。

CKA_EXTRACTABLE 属性が CK_TRUE に設定されていても、トークン固有の理由で鍵をラップできない場合は、エラー・コード CKR_KEY_NOT_WRAPPABLE で C_WrapKey は失敗します。 単に鍵長が原因で、指定されたラッピング鍵とラッピング・メカニズムで鍵をラップできない場合は、エラー・コード CKR_KEY_SIZE_RANGE で C_WrapKey は失敗します。

C_WrapKey を使用できるのは、以下の場合です。

• 暗号化と復号をサポートする公開鍵で共通鍵をラップする場合。
• 他の共通鍵で共通鍵をラップする場合。 鍵のサイズとメカニズムの強度を考慮する必要があります。トークンによっては操作が可能でない場合があるからです。
• 共通鍵で秘密鍵をラップする場合。

どのタイプの鍵をどのメカニズムでラップできるかは、トークンによって異なります。

ラッピング・キーをパーティション化して、抽出可能なキーのサブセットのみをラップできるようにするには、ラッピング・キーで属性 CKA_WRAP_TEMPLATE を使用して、ラッピング対象キーの属性と比較できる属性セットを指定します。 属性マッチングの C_FindObject ルールに基づいてすべての属性が一致すると、ラップ処理が開始されます。 この属性の値は属性テンプレートであり、サイズはテンプレート内の項目数に CK_ATTRIBUTE のサイズを乗算した値になります。 この属性を指定しなければ、どのテンプレートも受け入れられます。 存在しない属性はチェックされません。 鍵をラップしようとしたときに属性の不一致が発生すると、関数から CKR_KEY_HANDLE_INVALID が返されます。

    CK_DEFINE_FUNCTION(CK_RV, C_WrapKey)(
        CK_SESSION_HANDLE hSession,
        CK_MECHANISM_PTR pMechanism,
        CK_OBJECT_HANDLE hWrappingKey,
        CK_OBJECT_HANDLE hKey,
        CK_BYTE_PTR pWrappedKey,
        CK_ULONG_PTR pulWrappedKeyLen
    );
    

    message UnwrapKeyRequest {
        bytes Wrapped = 1;
        bytes KeK = 2;
        bytes MacKey = 3;
        Mechanism Mech = 5;
        map<uint64,AttributeValue> Template = 9;
    }
    message UnwrapKeyResponse {
        bytes UnwrappedBytes = 7;
        bytes CheckSum = 8;
    }
    

PKCS #11 C_UnwrapKey の実装。

uwmech は、ラップされたデータの復号に使用される暗号化メカニズムを指定します。ptempl は key(pair) パラメーター・リストで、アンラップされたデータを新しいキーに変換する方法を指定します (CKA_KEY_TYPE が含まれていること)。

生成されたオブジェクトは、BLOB として (unwrapped, uwlen) に返されます。 対称鍵では、鍵のチェックサム (3 バイト) が (csum, cslen) に返されます。公開鍵オブジェクトでは、公開鍵が SPKI として (csum, cslen) に返されます。 どちらの形式の場合も、アンラップした鍵のビット・カウントをエンコードした 4 バイトのビッグ・エンディアン値が後に続きます。

SPKI を MAC 署名付き SPKI に変換する場合は、アンラップ・メカニズムとして CKM_IBM_TRANSPORTKEY を使用する必要があります。 このモードでは、ラップしたデータとして未加工の SPKI を指定します。KEK は無視されます。

UnwrapKey では、パリティーで調整された DES 鍵が (BLOB 内に) 生成されますが、パリティーが正しくない入力も許容されます。

    CK_RV m_UnwrapKey (
        const CK_BYTE_PTR wrapped, CK_ULONG wrappedlen,
        const unsigned char *keK, size_t keKlen,
        const unsigned char *macKey, size_t macKeylen,
        const unsigned char *pin, size_t pinlen,
        const CK_MECHANISM_PTR mech,
        const CK_ATTRIBUTE_PTR template, CK_ULONG templatelen,
        unsigned char * unwrapped、size_t * unwrappedlen、
        CK_BYTE_PTR checkSum, CK_ULONG *checkSumlen,
        target_t ターゲット
    );
    

C_UnwrapKey は、ラップされたキーをアンラップ (復号) して、新しいプライベート・キーまたはプライベート・キー・オブジェクトを作成します。hSession はセッションのハンドル、pMechanism はアンラップ・メカニズム、hUnwrappingKey はアンラップ・キーのハンドル、pWrappedKey はラップされたキー、ulWrappedKeyLen はラップされたキーの長さ、pTemplate は新しいキーのテンプレート、ulAttributeCount はテンプレートの属性数、phKey はリカバリーされたキーのハンドルを受け取るロケーションを指します。

アンラッピング鍵の CKA_UNWRAP 属性 (鍵がアンラッピングをサポートするかどうかを示す属性) は、CK_TRUE でなければなりません。

新しい鍵では、CKA_ALWAYS_SENSITIVE 属性が CK_FALSE に設定され、CKA_NEVER_EXTRACTABLE 属性も CK_FALSE に設定されます。 CKA_EXTRACTABLE 属性は、デフォルトでは CK_TRUE に設定されます。

変更や変更の試行ができるメカニズムもあります。 キーがアンラップされると同時に、pMechanism 構造の内容もアンラップされます。

指定された正確なテンプレートに対応していない場合、C_UnwrapKey の呼び出しは失敗し、鍵オブジェクトを作成せずに戻ります。

C_UnwrapKey の呼び出しが成功して鍵オブジェクトが作成されると、そのオブジェクトの CKA_LOCAL 属性が CK_FALSE に設定されます。

キーのサブセットのみをアンラップできるようにアンラッピング・キーをパーティション化するには、アンラッピング・キーで属性 CKA_UNWRAP_TEMPLATE を使用して、アンラップ対象キーの属性に追加される属性セットを指定します。 これらの属性が、pTemplate 内のユーザー指定の属性テンプレートと矛盾しない場合は、アンラップ処理が開始されます。 この属性の値は属性テンプレートであり、サイズはテンプレート内の項目数に CK_ATTRIBUTE のサイズを乗算した値になります。 この属性がアンラップ鍵に存在しない場合、追加の属性は追加されません。 キーをアンラップしようとしたときに属性の競合が発生した場合は、関数 SHALL は CKR_TEMPLATE_INCONSISTENT を返します。

    CK_DEFINE_FUNCTION(CK_RV, C_UnwrapKey)(
        CK_SESSION_HANDLE hSession,
        CK_MECHANISM_PTR pMechanism,
        CK_OBJECT_HANDLE hUnwrappingKey,
        CK_BYTE_PTR pWrappedKey,
        CK_ULONG ulWrappedKeyLen,
        CK_ATTRIBUTE_PTR pTemplate,
        CK_ULONG ulAttributeCount,
        CK_OBJECT_HANDLE_PTR phKey
    );
    

    message RewrapKeyBlobRequest {
    	bytes WrappedKey = 1;
    }
    message RewrapKeyBlobResponse {
    	bytes RewrappedKey = 1;
    }
    

    message GetAttributeValueRequest {
        bytes Object = 1;
        map<uint64,AttributeValue> Attributes = 3;
    }
    message GetAttributeValueResponse {
        map<uint64,AttributeValue> Attributes = 4;
    }
    

PKCS #11 C_GetAttributeValue の実装。

(BLOB に含まれている) セッションに対応していない、またはセッションを必要としないので 、hSession パラメーターは使用しません。

EP11 では、汎用的なデコードの方法ではなく、実際の値を列挙するなどの、より単純なデコードの方法を使用します。

    CK_RV m_GetAttributeValue (
        const unsigned char *object, size_t objectlen,
        CK_ATTRIBUTE_PTR attributes, CK_ULONG attributeslen,
        target_t ターゲット
    );
    

C_GetAttributeValue は、オブジェクトの 1 つ以上の属性の値を取得します。hSession はセッションのハンドル、hObject はオブジェクトのハンドル、pTemplate は取得する属性値を指定し、属性値を受け取るテンプレート、UlCount はテンプレートの属性数を指します。

テンプレート内のトリプル (type、pValue、ulValueLen) ごとに、C_GetAttributeValue は以下のアルゴリズムを実行します。

1. 機密オブジェクトや抽出不能なオブジェクトであるために、指定された属性 (つまり、type フィールドで指定された属性) を確認できない場合は、そのトリプルの ulValueLen フィールドが、値 CK_UNAVAILABLE_INFORMATION を保持できる長さに変更されます。
2. そうではなく、オブジェクトの指定された値が無効な場合 (オブジェクトにそのような属性がない場合) は、そのトリプルの ulValueLen フィールドが、値 CK_UNAVAILABLE_INFORMATION を保持できる長さに変更されます。
3. そうではなく、pValue フィールドの値が NULL_PTR である場合、ulValueLen フィールドが、オブジェクトの指定された属性の正確な長さに変更されます。
4. そうではなく、ulValueLen に指定された長さが、オブジェクトの指定された属性の値を保持できる長さである場合は、その属性が pValue にあるバッファーにコピーされ、ulValueLen フィールドが属性の正確な長さに変更されます。
5. そうではない場合は、ulValueLen フィールドが、値 CK_UNAVAILABLE_INFORMATION を保持できる長さに変更されます。

要求されたいずれかの属性がケース 1 に該当する場合は、呼び出しで値 CKR_ATTRIBUTE_SENSITIVE が返される必要があります。 要求されたいずれかの属性がケース 2 に該当する場合は、呼び出しで値 CKR_ATTRIBUTE_TYPE_INVALID が返される必要があります。 要求されたいずれかの属性がケース 5 に該当する場合は、呼び出しで値 CKR_BUFFER_TOO_SMALL が返される必要があります。 複数のエラー・コードが該当する場合は、通常どおり、Cryptoki からそのすべてが返されます。 CKR_OK が返されるのは、要求されたいずれの属性もどのケースにも該当しない場合に限られます。

値が配列 (CKA_WRAP_TEMPLATE など) である属性の特殊なケースで、NULL ではなく pValue で渡される場合は、その配列のエレメントの pValue が NULL_PTR であれば、配列のエレメントの ulValueLen は必要な長さに設定されます。 配列内の要素の pValue が NULL_PTR でない場合は、配列内の属性の ulValueLen 要素が、対応する pValue が指すスペースを反映していなければならず、十分なスペースがある場合は pValue に値が設定されます。 したがって、そのような配列値を取得するために C_GetAttributeValue が呼び出される前に、バッファーの内容を初期化することが重要です。 配列内の ulValueLen の大きさが十分でない場合は、値が CK_UNAVAILABLE_INFORMATION に設定され、関数から CKR_BUFFER_TOO_SMALL が返されます。これは、pTemplate 引数の属性の ulValueLen が小さすぎる場合と同じ動作です。 属性の配列を値として持つ属性は、属性タイプに CKF_ARRAY_ATTRIBUTE を設定することで識別できます。

エラー・コード CKR_ATTRIBUTE_SENSITIVE、CKR_ATTRIBUTE_TYPE_INVALID、CKR_BUFFER_TOO_SMALL は、C_GetAttributeValue の実際のエラーではありません。 C_GetAttributeValue の呼び出しでこの 3 つの値のいずれかが返された場合は、C_GetAttributeValue に渡したテンプレート内のすべての属性が処理されています。 C_GetAttributeValue の呼び出しで値を返すことができるテンプレート内の各属性が、C_GetAttributeValue の呼び出しで返されます。

    CK_DEFINE_FUNCTION(CK_RV, C_GetAttributeValue)(
        CK_SESSION_HANDLE hSession,
        CK_OBJECT_HANDLE hObject,
        CK_ATTRIBUTE_PTR pTemplate,
        CK_ULONG ulCount
    );
    

    message SetAttributeValueRequest {
        bytes Object = 1;
        map<uint64,AttributeValue> Attributes = 3;
    }
    message SetAttributeValueResponse {
        bytes Object = 1;
    }
    

PKCS #11 C_SetAttributeValue の実装。

属性パッキング: _GetAttrValue を参照してください。

現在のところ Ep11 では、送信されるのはブール属性だけで、他のすべての属性はホストによって処理されます (WRAP_TEMPLATE などの配列は変更されません)。

(BLOB に含まれている) セッションに対応していない、またはセッションを必要としないので、PKCS #11 の hSession パラメーターは使用しません。

    CK_RV m_SetAttributeValue (
        unsigned char *object, size_t objectlen,
        CK_ATTRIBUTE_PTR attributes, CK_ULONG attributeslen,
        target_t ターゲット
    );
    

_SetAttributeValue は、オブジェクトの 1 つ以上の属性の値を変更します。hSession はセッションのハンドル、hObject はオブジェクトのハンドル、pTemplate は変更する属性値とその新しい値を指定するテンプレート、ulCount はテンプレートの属性数を指します。

変更できないオブジェクトもあります。 そのようなオブジェクトに対して C_SetAttributeValue を呼び出すと、エラー・コード CKR_ACTION_PROHIBITED が返されます。 アプリケーションは、オブジェクトの CKA_MODIFIABLE 属性に基づいて、オブジェクトが変更可能かどうかを判別できます。

読み取り専用セッションで変更できるのはセッション・オブジェクトだけです。

テンプレートでは、変更可能なオブジェクトの任意の属性の新しい値を指定できます。 オブジェクトの他の既存の属性と互換性のない属性の値がテンプレートに指定されている場合は、呼び出しは失敗し、リターン・コード CKR_TEMPLATE_INCONSISTENT が返されます。

すべての属性を変更できるわけではありません。詳細については、PKCS #11 API 仕様セクション 4.1.2 を参照してください。

    CK_DEFINE_FUNCTION(CK_RV, C_SetAttributeValue)(
        CK_SESSION_HANDLE hSession,
        CK_OBJECT_HANDLE hObject,
        CK_ATTRIBUTE_PTR pTemplate,
        CK_ULONG ulCount
    );
    

    message GenerateRandomRequest {
        uint64 Len = 1;
    }
    message GenerateRandomResponse {
        bytes Rnd = 1;
    }
    

PKCS #11 C_GenerateRandom の実装。

GenerateRandom は元の PKCS #11 関数と同じです。 内部では、ハードウェアでシードされたエントロピーが、FIPS 準拠の DRNG (Clic のバージョンに応じて ANSI X9.31 か ISO 18031 のどちらか) で渡されます。

適切な機能がホストで有効になっていれば、バックエンドに送ることなくホスト・ライブラリーで乱数を生成できます。 現在の実装ではこれは実行されません。

この関数はサイズの照会をサポートしていません。

    CK_RV m_GenerateRandom (
        CK_BYTE_PTR rnd, CK_ULONG rndlen,
        target_t ターゲット
    );
    

    CK_DEFINE_FUNCTION(CK_RV, C_GenerateRandom)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pRandomData,
        CK_ULONG ulRandomLen
    );
    

    message EncryptInitRequest {
        Mechanism Mech = 2;
        bytes Key = 3;
    }
    message EncryptInitResponse {
        bytes State = 1;
    }
    

PKCS #11 C_EncryptInit の実装。

(key, klen) の BLOB には、公開鍵のオブジェクトまたは秘密鍵の BLOB を指定できます。 鍵のタイプは pmech と整合していなければなりません。

公開鍵のメカニズムの場合は、(key, klen) に SPKI を指定する必要があります。 この SPKI は、GenerateKeyPair または UnwrapKey で返される MAC 鍵によって整合性が確保されています。 Encrypt の状態は、セッション制限なしで作成されます。

秘密鍵メカニズムの場合、Encrypt の状態は、(key, klen) からオブジェクト・セッション制限を継承します。

state、slen の BLOB を PKCS #11 の hSession パラメーターからマップする必要があります。

(key, klen) は鍵の BLOB でなければなりません。

    CK_RV m_EncryptInit (
        unsigned char * state、size_t * statelen、
        CK_MECHANISM_PTR mech,
        const unsigned char *key, size_t keylen,
        target_t ターゲット
    );
    

C_EncryptInit は、暗号化操作を初期化します。hSession はセッションのハンドル、pMechanism は暗号化メカニズム、hKey は暗号キーのハンドルを指します。

暗号鍵の CKA_ENCRYPT 属性 (鍵が暗号化をサポートするかどうかを示す属性) は、CK_TRUE でなければなりません。

アプリケーションは C_EncryptInit を呼び出した後に、C_Encrypt を呼び出して 1 部構成のデータを暗号化するか、C_EncryptUpdate をゼロ回以上呼び出してから C_EncryptFinal を呼び出して複数部構成のデータを暗号化することができます。 暗号化操作は、アプリケーションが C_Encrypt または C_EncryptFinal の呼び出しを使用して最終的な暗号文を取得するまでアクティブです。 (1 部構成または複数部構成の) データを追加で処理するには、アプリケーションはもう一度 C_EncryptInit を呼び出す必要があります。

    CK_DEFINE_FUNCTION(CK_RV, C_EncryptInit)(
        CK_SESSION_HANDLE hSession,
        CK_MECHANISM_PTR pMechanism,
        CK_OBJECT_HANDLE hKey
    );
    

    message EncryptRequest {
        bytes State = 1;
        bytes Plain = 2;
    }
    message EncryptResponse {
        bytes Ciphered = 3;
    }
    

PKCS #11 C_Encrypt の実装。

(state, slen) は更新されません。

state、slen の BLOB を PKCS #11 の hSession パラメーターからマップする必要があります。

state の BLOB は、EncryptInit からの出力です。

    CK_RV m_Encrypt (
        const unsigned char *state, size_t statelen,
        CK_BYTE_PTR plain, CK_ULONG plainlen,
        CK_BYTE_PTR ciphered, CK_ULONG_PTR cipheredlen,
        target_t ターゲット
    );
    

C_Encrypt は、シングルパート・データを暗号化します。hSession はセッションのハンドル、pDATA はデータ、ulDataLen はデータのバイト単位の長さ、pEncryptedData は暗号化されたデータを受け取るロケーション、pulEncryptedDataLen は暗号化されたデータのバイト単位の長さを保持するロケーションを指します。

C_Encrypt は、PKCS #11 API 仕様のセクション 5.2 で説明されている出力の生成に関する規則を使用します。

暗号化操作を C_EncryptInit で初期化する必要があります。 C_Encrypt を呼び出すと、必ずアクティブな暗号化操作が終了します。ただし、暗号化テキストを保持するために必要なバッファーの長さを判別するために CKR_BUFFER_TOO_SMALL が返されるか、または呼び出しが成功した場合 (つまり CKR_OK が返された呼び出し) を除きます。

複数部構成の操作を終了するために C_Encrypt を使用することはできません。この関数は、C_EncryptInit の後に、C_EncryptUpdate の呼び出しを挟まずに呼び出す必要があります。

一部の暗号化メカニズムでは、入力プレーン・テキスト・データに一定の長さの制約があります (メカニズムは比較的短いプレーン・テキストのみを暗号化できるため、またはメカニズムの入力データは整数のブロック数で構成される必要があるため)。 この制約を満たしていないと、C_Encrypt は戻りコード CKR_DATA_LEN_RANGE で失敗します。

プレーン・テキストと暗号化テキストは同じ場所に置くことができます。つまり、 pData と pEncryptedData が同じ場所を指していれば問題ありません。

ほとんどのメカニズムでは、C_Encrypt は、一連の C_EncryptUpdate 操作の後に C_EncryptFinal を実行するのと同じです。

    CK_DEFINE_FUNCTION(CK_RV, C_Encrypt)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pData,
        CK_ULONG ulDataLen,
        CK_BYTE_PTR pEncryptedData,
        CK_ULONG_PTR pulEncryptedDataLen
    );
    

    message EncryptUpdateRequest {
        bytes State = 1;
        bytes Plain = 2;
    }
    message EncryptUpdateResponse {
        bytes State = 1;
        bytes Ciphered = 3;
    }
    

PKCS #11 C_EncryptUpdate の実装。

state、slen の BLOB を PKCS #11 の hSession パラメーターからマップする必要があります。

state の BLOB は、EncryptInit からの出力です。

    CK_RV m_EncryptUpdate (
        unsigned char *state, size_t statelen,
        CK_BYTE_PTR plain, CK_ULONG plainlen,
        CK_BYTE_PTR ciphered, CK_ULONG_PTR cipheredlen,
        target_t ターゲット
    );
    

C_EncryptUpdate はマルチパートの暗号化操作を続行し、別のデータ・パートを処理します。hSession はセッションのハンドル、pPart はデータ・パート、ulPartLen はデータ・パートの長さ、pEncryptedPart は暗号化されたデータ・パートを受け取るロケーション、pulEncryptedPartLen は暗号化されたデータ・パートの長さ (バイト単位) を保持するロケーションを指します。

C_EncryptUpdate は、PKCS #11 API 仕様のセクション 5.2 で説明されている出力の生成に関する規則を使用します。

暗号化操作を C_EncryptInit で初期化する必要があります。 この関数は、連続して何度でも呼び出せます。 C_EncryptUpdate を呼び出して CKR_BUFFER_TOO_SMALL 以外のエラーが発生すると、現在の暗号化操作が終了します。

平文と暗号文を同じ場所に配置できます。つまり、pPart と pEncryptedPart が同じ場所を指していてもかまいません。

    CK_DEFINE_FUNCTION(CK_RV, C_EncryptUpdate)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pPart,
        CK_ULONG ulPartLen,
        CK_BYTE_PTR pEncryptedPart,
        CK_ULONG_PTR pulEncryptedPartLen
    );
    

    message EncryptFinalRequest {
        bytes State = 1;
    }
    message EncryptFinalResponse {
        bytes Ciphered = 2;
    }
    

PKCS #11 C_EncryptFinal の実装。

(state, slen) は更新されません。

state、slen の BLOB を PKCS #11 の hSession パラメーターからマップする必要があります。

state の BLOB は、EncryptInit および EncryptUpdate からの出力です。

    CK_RV m_EncryptFinal (
        const unsigned char *state, size_t statelen,
        CK_BYTE_PTR ciphered, CK_ULONG_PTR cipheredlen,
        target_t ターゲット
    );
    

C_EncryptFinal は、マルチパートの暗号化操作を終了します。hSession はセッションのハンドル、pLastEncryptedPart は、最後に暗号化されたデータ・パートがあれば受け取るロケーション、pulLastEncryptedPartLen は最後に暗号化されたデータ・パートの長さを保持するロケーションを指します。

C_EncryptFinal は、PKCS #11 API 仕様のセクション 5.2 で説明されている出力の生成に関する規則を使用します。

暗号化操作を C_EncryptInit で初期化する必要があります。 C_EncryptFinal を呼び出すと、必ず、アクティブな暗号化操作が終了します。ただし、呼び出しで CKR_BUFFER_TOO_SMALL が返された場合や、暗号文を保持するのに必要なバッファー長を確認するために呼び出して成功した場合 (つまり CKR_OK が返された場合) は別です。

一部のマルチパート暗号化メカニズムでは、入力プレーン・テキスト・データに一定の長さの制約があります。これは、メカニズムの入力データが整数のブロック数で構成されている必要があるためです。 この制約を満たしていないと、C_EncryptFinal は戻りコード CKR_DATA_LEN_RANGE で失敗します。

    CK_DEFINE_FUNCTION(CK_RV, C_EncryptFinal)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pLastEncryptedPart,
        CK_ULONG_PTR pulLastEncryptedPartLen
    );
    

    message EncryptSingleRequest {
        bytes Key = 1;
        Mechanism Mech = 2;
        bytes Plain = 3;
    }
    message EncryptSingleResponse {
        bytes Ciphered = 4;
    }
    

Encrypt の非標準のバリアント。 1 回の呼び出しで一度にデータを処理します。 暗号化されたデータだけがホストに返され、状態は返されません。

XCP 対応アプリケーションには、データを一度に暗号化するこの方法をお勧めします。 機能的には、これは EncryptInit の直後に Encrypt を実行するのと同じですが、往復、ラップ、アンラップの処理を行わずに済みます。

バックエンドが常駐鍵をサポートしている場合は、この鍵を常駐鍵のハンドルとして使用することも可能です。

Encrypt、EncryptInit、DecryptSingle も参照してください。

key の BLOB は、GenerateKey および UnwrapKey からの出力です。

    CK_RV m_EncryptSingle (
        const unsigned char *key, size_t keylen,
        CK_MECHANISM_PTR mech,
        CK_BYTE_PTR plain, CK_ULONG plainlen,
        CK_BYTE_PTR ciphered, CK_ULONG_PTR cipheredlen,
        target_t ターゲット
    );
    

    message ReencryptSingleRequest {
        bytes DecKey = 1;
        bytes EncKey = 2;
        Mechanism DecMech = 3;
        Mechanism EncMech = 4;
        bytes Ciphered = 5;
    }
    message ReencryptSingleResponse {
        bytes Reciphered = 6;
    }
    

Encrypt の非標準のバリアント。 1 回の呼び出しで一度にデータを処理します。 再暗号化されたデータだけがホストに返され、状態は返されません。

元のキーを使用してデータを復号し、クラウド HSM の別のキーで raw データを暗号化します。

    CK_RV m_ReencryptSingle (
        const unsigned char * dkey、size_t dkeylen、
        const unsigned char * ekey、size_t ekeylen、
        CK_MECHANISM_PTR decmech,
        CK_MECHANISM_PTR encmech,
        CK_BYTE_PTR in, CK_ULONG inlen,
        CK_BYTE_PTR ciphered, CK_ULONG_PTR cipheredlen,
        target_t ターゲット
    );
    

    message DecryptInitRequest {
        Mechanism Mech = 2;
        bytes Key = 3;
    }
    message DecryptInitResponse {
        bytes State = 1;
    }
    

    CK_RV m_DecryptInit (
        unsigned char * state、size_t * statelen、
        CK_MECHANISM_PTR mech,
        const unsigned char *key, size_t keylen,
        target_t ターゲット
    );
    

C_DecryptInit は、復号操作を初期化します。hSession はセッションのハンドル、pMechanism は復号メカニズム、hKey は復号キーのハンドルを指します。

復号鍵の CKA_DECRYPT 属性 (鍵が復号をサポートするかどうかを示す属性) は、CK_TRUE でなければなりません。

アプリケーションが C_DecryptInit を呼び出すと、アプリケーションは C_Decrypt を呼び出してシングルパートのデータを復号するか、または C_DecryptUpdate を 0 回かそれ以上呼び出してから、C_DecryptFinal を呼び出してマルチパートのデータを復号できます。 復号操作は、アプリケーションが C_Decrypt または C_DecryptFinal の呼び出しを使用して最終的な平文を取得するまでアクティブです。 (1 部構成または複数部構成の) データを追加で処理するには、アプリケーションはもう一度 C_DecryptInit を呼び出す必要があります。

    CK_DEFINE_FUNCTION(CK_RV, C_DecryptInit)(
        K_SESSION_HANDLE hSession,
        CK_MECHANISM_PTR pMechanism,
        CK_OBJECT_HANDLE hKey
    );
    

    message DecryptRequest {
        bytes State = 1;
        bytes Ciphered = 2;
    }
    message DecryptResponse {
       bytes Plain = 3;
    }
    

PKCS #11 C_Decrypt の実装 (state, slen) は更新されません。

state、slen のバイナリー・ラージ・オブジェクト (BLOB) を PKCS #11 の hSession パラメーターからマップする必要があります。 state の BLOB は、DecryptInit からの出力です。

    CK_RV m_Decrypt (const unsigned char *state, size_t slen,
        CK_BYTE_PTR cipher, CK_ULONG clen,
        CK_BYTE_PTR plain, CK_ULONG_PTR plen,
        target_t ターゲット
    );
    

C_Decrypt は、1 部構成の暗号化されたデータを復号します。

• hSession はセッション・ハンドルです。
• pEncryptedData は暗号化されたデータのポインターです。
• ulEncryptedDataLen は暗号化されたデータの長さです。
• pData は、復元されたデータを受け取る場所のポインターです。
• pulDataLen は、復元されたデータの長さを保持する場所のポインターです。

C_Decrypt は、PKCS #11 API 仕様のセクション 5.2 で説明されている出力の生成に関する規則を使用します。

復号操作を C_DecryptInit で初期化する必要があります。 C_Decrypt を呼び出すと、 CKR_BUFFER_TOO_SMALL が返されるか、プレーン・テキストを保持するために必要なバッファーの長さを判別するために CKR_OK が返される正常な呼び出しでない限り、アクティブな暗号化解除操作が常に終了します。

複数部構成の操作を終了するために C_Decrypt を使用することはできません。この関数は、C_DecryptInit の後に、C_DecryptUpdate の呼び出しを挟まずに呼び出す必要があります。

暗号化テキストとプレーン・テキストは同じ場所に置くことができます。つまり、 pEncryptedData と pData が同じ場所を指している場合にも許容されます。

入力の暗号データの長さが適切でないために復号できない場合は、CKR_ENCRYPTED_DATA_INVALID または CKR_ENCRYPTED_DATA_LEN_RANGE のいずれかが返される可能性があります。

    CK_DEFINE_FUNCTION(CK_RV, C_Decrypt)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pEncryptedData,
        CK_ULONG ulEncryptedDataLen,
        CK_BYTE_PTR pData,
        CK_ULONG_PTR pulDataLen
    );
    

    message DecryptUpdateRequest {
        bytes State = 1;
        bytes Ciphered = 2;
    }
    message DecryptUpdateResponse {
        bytes State = 1;
        bytes Plain = 3;
    }
    

PKCS #11 C_DecryptUpdate の実装。

state、slen の BLOB を PKCS #11 の hSession パラメーターからマップする必要があります。

state の BLOB は、DecryptInit からの出力です。

    CK_RV m_DecryptUpdate (
        unsigned char *state, size_t statelen,
        CK_BYTE_PTR ciphered, CK_ULONG cipheredlen,
        CK_BYTE_PTR plain, CK_ULONG_PTR plainlen,
        target_t ターゲット
    );
    

C_DecryptUpdate は、別の暗号化データ・パートを処理して、マルチパートの復号操作を続行します。hSession はセッションのハンドル、pEncryptedPart はデータの暗号化されたパート、ulEncryptedPartLen はデータの暗号化されたパートの長さ、pPart はデータのリカバリーされたパートを受け取るロケーション、pulPartLen はデータのリカバリーされたパートの長さを保持するロケーションを指します。

C_DecryptUpdate は、PKCS #11 API 仕様のセクション 5.2 で説明されている出力の生成に関する規則を使用します。

復号操作を C_DecryptInit で初期化する必要があります。 この関数は、連続して何度でも呼び出せます。 C_DecryptUpdate を呼び出して CKR_BUFFER_TOO_SMALL 以外のエラーが発生すると、現在の復号操作が終了します。

暗号化テキストとプレーン・テキストは同じ場所に置くことができます。つまり、 pEncryptedPart と pPart が同じ場所を指していれば問題ありません。

    CK_DEFINE_FUNCTION(CK_RV, C_DecryptUpdate)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pEncryptedPart,
        CK_ULONG ulEncryptedPartLen,
        CK_BYTE_PTR pPart,
        CK_ULONG_PTR pulPartLen
    );
    

    message DecryptFinalRequest {
        bytes State = 1;
    }
    message DecryptFinalResponse {
        bytes Plain = 2;
    }
    

PKCS #11 C_DecryptFinal の実装。

(state, slen) は更新されません。

state、slen の BLOB を PKCS #11 の hSession パラメーターからマップする必要があります。

state の BLOB は、DecryptInit および DecryptUpdate からの出力です。

    CK_RV m_DecryptFinal (
        const unsigned char *state, size_t statelen,
        CK_BYTE_PTR plain, CK_ULONG_PTR plainlen,
        target_t ターゲット
    );
    

C_DecryptFinal は、マルチパートの復号操作を終了します。hSession はセッションのハンドル、pLastPart は最後にリカバリーされたデータ・パートがあれば受け取るロケーション、pulLastPartLen は最後にリカバリーされたデータ・パートの長さを保持するロケーションを指します。

C_DecryptFinal は、PKCS #11 API 仕様のセクション 5.2 で説明されている出力の生成に関する規則を使用します。

復号操作を C_DecryptInit で初期化する必要があります。 C_DecryptFinal の呼び出しは、 CKR_BUFFER_TOO_SMALL を戻すか、またはテキスト・プレーン・テキストを保持するために必要なバッファーの長さを判別するための正常な呼び出し (つまり、 が CKR_OKを戻す呼び出し) でない限り、常にアクティブな暗号化解除操作を終了します。

入力の暗号データの長さが適切でないために復号できない場合は、CKR_ENCRYPTED_DATA_INVALID または CKR_ENCRYPTED_DATA_LEN_RANGE のいずれかが返される可能性があります。

    CK_DEFINE_FUNCTION(CK_RV, C_DecryptFinal)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pLastPart,
        CK_ULONG_PTR pulLastPartLen
    );
    

    message DecryptSingleRequest {
        bytes Key = 1;
        Mechanism Mech = 2;
        bytes Ciphered = 3;
    }
    message DecryptSingleResponse {
        bytes Plain = 4;
    }
    

Decrypt の非標準のバリアント。 1 回の呼び出しで一度にデータを処理します。 復号されたデータだけがホストに返され、状態は返されません。

XCP 対応アプリケーションには、データを一度に暗号化するこの方法をお勧めします。 機能的には、これは DecryptInit の直後に Decrypt を実行するのと同じですが、往復、ラップ、アンラップの処理を行わずに済みます。

バックエンドが常駐鍵をサポートしている場合は、この鍵を常駐鍵のハンドルとして使用することも可能です。

Decrypt、DecryptInit、EncryptSingle も参照してください。

key の BLOB は、GenerateKey および UnwrapKey からの出力です。

    CK_RV m_DecryptSingle (
        const unsigned char *key, size_t keylen,
        CK_MECHANISM_PTR mech,
        CK_BYTE_PTR ciphered, CK_ULONG cipheredlen,
        CK_BYTE_PTR plain, CK_ULONG_PTR plainlen,
        target_t ターゲット
    );
    

    message SignInitRequest {
        Mechanism Mech = 2;
        bytes PrivKey = 3;
    }
    message SignInitResponse {
        bytes State = 1;
    }
    

    CK_RV m_SignInit (
        unsigned char * state、size_t * statelen、
        CK_MECHANISM_PTR mech,
        const unsigned char *privKey, size_t privKeylen,
        target_t ターゲット
    );
    

C_SignInit) は署名操作を初期化しますが、署名はデータの付録です。hSession はセッションのハンドル、pMechanism は署名メカニズム、hKey は署名キーのハンドルを指します。

署名鍵の CKA_SIGN 属性 (鍵が署名の付属をサポートするかどうかを示す属性) は、CK_TRUE でなければなりません。

アプリケーションは C_SignInit を呼び出した後に、C_Sign を呼び出して 1 部構成のデータに署名するか、C_SignUpdate を 1 回以上呼び出してから C_SignFinal を呼び出して複数部構成のデータに署名することができます。 署名操作は、アプリケーションが C_Sign または C_SignFinal の呼び出しを使用して署名を取得するまでアクティブです。 (1 部構成または複数部構成の) データを追加で処理するには、アプリケーションはもう一度 C_SignInit を呼び出す必要があります。

    CK_DEFINE_FUNCTION(CK_RV, C_SignInit)(
        CK_SESSION_HANDLE hSession,
        CK_MECHANISM_PTR pMechanism,
        CK_OBJECT_HANDLE hKey
    );
    

    message SignRequest {
        bytes State = 1;
        bytes Data = 2;
    }
    message SignResponse {
        bytes Signature = 3;
    }
    

PKCS #11 C_Sign の実装。

(state, slen) は更新されません。

state、slen の BLOB を PKCS #11 の hSession パラメーターからマップする必要があります。 (ホスト・ライブラリーで、保存されている状態にセッションをマップしなければなりません)。

state の BLOB は、SignInit からの出力です。

    CK_RV m_Sign (
        const unsigned char *state, size_t statelen,
        CK_BYTE_PTR data, CK_ULONG datalen,
        CK_BYTE_PTR signature, CK_ULONG_PTR signaturelen,
        target_t ターゲット
    );
    

C_Sign は、署名がデータの付録であるシングル・パートでデータに署名します。hSession はセッションのハンドル、pDATA はデータ、ulDataLen はデータの長さ、pSignature は署名を受け取るロケーション、pulSignatureLen は署名の長さを保持するロケーションを指します。

C_Sign は、PKCS #11 API 仕様のセクション 5.2 で説明されている出力の生成に関する規則を使用します。

署名操作を C_SignInit で初期化する必要があります。 C_Sign を呼び出すと、必ず、アクティブな署名操作が終了します。ただし、呼び出しで CKR_BUFFER_TOO_SMALL が返された場合や、署名を保持するのに必要なバッファー長を確認するために呼び出して成功した場合 (つまり CKR_OK が返された場合) は別です。

複数部構成の操作を終了するために C_Sign を使用することはできません。この関数は、C_SignInit の後に、C_SignUpdate の呼び出しを挟まずに呼び出す必要があります。

ほとんどのメカニズムでは、C_Sign は、一連の C_SignUpdate 操作の後に C_SignFinal を実行するのと同じです。

    CK_DEFINE_FUNCTION(CK_RV, C_Sign)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pData,
        CK_ULONG ulDataLen,
        CK_BYTE_PTR pSignature,
        CK_ULONG_PTR pulSignatureLen
    );
    

    message SignUpdateRequest {
        bytes State = 1;
        bytes Data = 2;
    }
    message SignUpdateResponse {
        bytes State = 1;
    }
    

state、slen の BLOB を PKCS #11 の hSession パラメーターからマップする必要があります。 (ホスト・ライブラリーで、保存されている状態にセッションをマップしなければなりません)。

state の BLOB は、SignInit からの出力です。

    CK_RV m_SignUpdate (
        unsigned char *state, size_t statelen,
        CK_BYTE_PTR data, CK_ULONG datalen,
        target_t ターゲット
    );
    

C_SignUpdate はマルチパート署名操作を続行し、別のデータ・パートを処理します。hSession はセッションのハンドル、pPart はデータ・パート、ulPartLen はデータ・パートの長さを指します。

署名操作を C_SignInit で初期化する必要があります。 この関数は、連続して何度でも呼び出せます。 C_SignUpdate を呼び出してエラーが発生すると、現在の署名操作が終了します。

    CK_DEFINE_FUNCTION(CK_RV, C_SignUpdate)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pPart,
        CK_ULONG ulPartLen
    );
    

    message SignFinalRequest {
        bytes State = 1;
    }
    message SignFinalResponse {
        bytes Signature = 2;
    }
    

PKCS #11 C_SignFinal の実装。

(state, slen) は更新されません。

state、slen の BLOB を PKCS #11 の hSession パラメーターからマップする必要があります。 (ホスト・ライブラリーで、保存されている状態にセッションをマップしなければなりません)。

state の BLOB は、SignInit および SignUpdate からの出力です。

    CK_RV m_SignFinal (
        const unsigned char *state, size_t statelen,
        CK_BYTE_PTR signature, CK_ULONG_PTR signaturelen,
        target_t ターゲット
    );
    

C_SignFinal はマルチパートの署名操作を終了し、署名を返します。hSession はセッションのハンドル、pSignature は署名を受け取るロケーション、pulSignatureLen は署名の長さを保持するロケーションを指します。

C_SignFinal は、PKCS #11 API 仕様のセクション 5.2 で説明されている出力の生成に関する規則を使用します。

署名操作を C_SignInit で初期化する必要があります。 C_SignFinal を呼び出すと、必ず、アクティブな署名操作が終了します。ただし、呼び出しで CKR_BUFFER_TOO_SMALL が返された場合や、署名を保持するのに必要なバッファー長を確認するために呼び出して成功した場合 (つまり CKR_OK が返された場合) は別です。

    CK_DEFINE_FUNCTION(CK_RV, C_SignFinal)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pSignature,
        CK_ULONG_PTR pulSignatureLen
    );
    

    message SignSingleRequest {
        bytes PrivKey = 1;
        Mechanism Mech = 2;
        bytes Data = 3;
    }
    message SignSingleResponse {
        bytes Signature = 4;
    }
    

非標準の拡張機能であり、SignInit と Sign の組み合わせです。 1 回の呼び出しで一度にデータに署名または MAC 署名を付けます。中間のダイジェスト状態は作成されません。 結果だけがホストに返され、状態は返されません。

これがお勧めする署名方法です。往復、暗号化、および復号を追加で行う必要がないからです。 機能的には、SignSingle は、SignInit の直後に Sign を実行するのと同じです。

(key, klen) の BLOB と pmech のメカニズムを一緒に SignInit に渡せなければなりません。

HMAC 署名および CMAC 署名の複数データ要求がサポートされます (サブ変数 2 および 3)。

SignInit、Sign、VerifySingle も参照してください。

    CK_RV m_SignSingle (
        const unsigned char *privKey, size_t privKeylen,
        CK_MECHANISM_PTR mech,
        CK_BYTE_PTR data, CK_ULONG datalen,
        CK_BYTE_PTR signature, CK_ULONG_PTR signaturelen,
        target_t ターゲット
    );
    

    message VerifyInitRequest {
        Mechanism Mech = 2;
        bytes PubKey = 3;
    }
    message VerifyInitResponse {
        bytes State = 1;
    }
    

PKCS #11 C_VerifyInit の実装。 鍵の BLOB (key, klen) を指定して、(state, slen) で検証セッションの状態を初期化します。 鍵の BLOB には、公開鍵オブジェクトまたは HMAC 鍵バイトを指定できます。 鍵の BLOB のタイプは pmech と整合していなければなりません。

公開鍵のメカニズムの場合は、(key, klen) に SPKI を指定する必要があります。 この SPKI の CKA_UNWRAP は、MAC 署名付きのもの (GenerateKeyPair で返されたものなど) でも、SPKI 自体 (証明書などの外部ソースから取得されたもの) でもかまいません。

HMAC 操作が初期化される場合は、Verify オブジェクトのセッション制限が HMAC 鍵から継承されます。 SPKI はセッションに結び付けられないので、公開鍵の Verify の状態にはセッションはありません。

key、klen の BLOB を PKCS #11 の hKey パラメーターからマップする必要があります。

注: SignInit および VerifyInit は、 HMAC およびその他の symmetric/MAC メカニズムの場合も同じです。

    CK_RV m_VerifyInit (
        unsigned char * state、size_t * statelen、
        CK_MECHANISM_PTR mech,
        const unsigned char *pubKey, size_t pubKeylen,
        target_t ターゲット
    );
    

C_VerifyInit は検証操作を初期化しますが、署名はデータの付録です。hSession はセッションのハンドル、pMechanism は検査メカニズムを指定する構造、hKey は検査キーのハンドルを指します。

検証鍵の CKA_VERIFY 属性 (署名が付属しているデータの検証を鍵がサポートしているかどうかを示す属性) は、 CK_TRUE でなければなりません。

アプリケーションは C_VerifyInit を呼び出した後に、C_Verify を呼び出して 1 部構成のデータの署名を検証するか、C_VerifyUpdate を 1 回以上呼び出してから C_VerifyFinal を呼び出して複数部構成のデータの署名を検証することができます。 検証操作は、アプリケーションが C_Verify または C_VerifyFinal を呼び出すまでアクティブです。 (1 部構成または複数部構成の) データを追加で処理するには、アプリケーションはもう一度 C_VerifyInit を呼び出す必要があります。

    CK_DEFINE_FUNCTION(CK_RV, C_VerifyInit)(
        CK_SESSION_HANDLE hSession,
        CK_MECHANISM_PTR pMechanism,
        CK_OBJECT_HANDLE hKey
    );
    

    message VerifyRequest {
        bytes State = 1;
        bytes Data = 2;
        bytes Signature = 3;
    }
    message VerifyResponse {
    }
    

PKCS #11 C_Verify の実装。

(state, slen) は更新されません。

データと署名の相対順序が逆になります。 VerifySingleに送信されます。

state、slen の BLOB を PKCS #11 の hSession パラメーターからマップする必要があります。 (ホスト・ライブラリーで、保存されている状態にセッションをマップしなければなりません)。

state の BLOB は、VerifyInit からの出力です。

    CK_RV m_Verify (
        const unsigned char *state, size_t statelen,
        CK_BYTE_PTR data, CK_ULONG datalen,
        CK_BYTE_PTR signature, CK_ULONG signaturelen,
        target_t ターゲット
    );
    

C_Verify は、シングルパート操作で署名を検証しますが、署名はデータの付録です。hSession はセッションのハンドル、pDATA はデータを指し、ulDataLen はデータの長さ、pSignature は署名、ulSignatureLen は署名の長さを指します。

検証操作を C_VerifyInit で初期化する必要があります。 C_Verify を呼び出すと、必ず、アクティブな検証操作が終了します。

C_Verify の呼び出しが成功すると、CKR_OK (指定された署名が有効であることを示す値) または CKR_SIGNATURE_INVALID (指定された署名が無効であることを示す値) が返される必要があります。 長さだけが理由で署名が無効な場合は、CKR_SIGNATURE_LEN_RANGE が返される必要があります。 どの場合も、アクティブな署名操作は終了します。

複数部構成の操作を終了するために C_Verify を使用することはできません。この関数は、C_VerifyInit の後に、C_VerifyUpdate の呼び出しを挟まずに呼び出す必要があります。

ほとんどのメカニズムでは、C_Verify は、一連の C_VerifyUpdate 操作の後に C_VerifyFinal を実行するのと同じです。

    CK_DEFINE_FUNCTION(CK_RV, C_Verify)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pData,
        CK_ULONG ulDataLen,
        CK_BYTE_PTR pSignature,
        CK_ULONG ulSignatureLen
    );
    

    message VerifyUpdateRequest {
        bytes State = 1;
        bytes Data = 2;
    }
    message VerifyUpdateResponse {
        bytes State = 1;
    }
    

PKCS #11 C_VerifyUpdate の実装。

state、slen の BLOB を PKCS #11 の hSession パラメーターからマップする必要があります。 (ホスト・ライブラリーで、保存されている状態にセッションをマップしなければなりません)。

state の BLOB は、VerifyInit からの出力です。

    CK_RV m_VerifyUpdate (
        unsigned char *state, size_t statelen,
        CK_BYTE_PTR data, CK_ULONG datalen,
        target_t ターゲット
    );
    

C_VerifyUpdate はマルチパートの検査操作を続行し、別のデータ・パートを処理します。hSession はセッションのハンドル、pPart はデータ・パート、ulPartLen はデータ・パートの長さを指します。

検証操作を C_VerifyInit で初期化する必要があります。 この関数は、連続して何度でも呼び出せます。 C_VerifyUpdate を呼び出してエラーが発生すると、現在の検査操作は終了します。

    CK_DEFINE_FUNCTION(CK_RV, C_VerifyUpdate)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pPart,
        CK_ULONG ulPartLen
    );
    

    message VerifyFinalRequest {
        bytes State = 1;
        bytes Signature = 2;
    }
    message VerifyFinalResponse {
    }
    

PKCS #11 C_VerifyFinal の実装。

(state, slen) は更新されません。

state、slen の BLOB を PKCS #11 の hSession パラメーターからマップする必要があります。 (ホスト・ライブラリーで、保存されている状態にセッションをマップしなければなりません)。

state の BLOB は、VerifyInit および VerifyUpdate からの出力です。

    CK_RV m_VerifyFinal (
        const unsigned char *state, size_t statelen,
        CK_BYTE_PTR signature, CK_ULONG signaturelen,
        target_t ターゲット
    );
    

C_VerifyFinal は署名を検査して、マルチパート検査操作を終了します。hSession はセッションのハンドル、pSignature は署名、ulSignatureLen は署名の長さを指します。

検証操作を C_VerifyInit で初期化する必要があります。 C_VerifyFinal を呼び出すと、必ず、アクティブな検証操作が終了します。

C_VerifyFinal の呼び出しが成功すると、CKR_OK (指定された署名が有効であることを示す値) または CKR_SIGNATURE_INVALID (指定された署名が無効であることを示す値) が返される必要があります。 長さが理由で署名が無効な場合は、CKR_SIGNATURE_LEN_RANGE が返される必要があります。 どの場合も、アクティブな検証操作は終了します。

    CK_DEFINE_FUNCTION(CK_RV, C_VerifyFinal)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pSignature,
        CK_ULONG ulSignatureLen
    );
    

    message VerifySingleRequest {
        bytes PubKey = 1;
        Mechanism Mech = 2;
        bytes Data = 3;
        bytes Signature = 4;
    }
    message VerifySingleResponse {
    }
    

非標準の拡張機能であり、VerifyInit と Verify の組み合わせです。 1 回の呼び出しで一度にデータに署名または MAC 署名を付けます。中間のダイジェスト状態は作成されません。 検証結果だけがホストに返され、状態は返されません。 この関数はブール値を返すので、サイズの照会はできません。

これがお勧めする署名の検証方法です。往復、暗号化、および復号を追加で行う必要がないからです。 機能的には、VerifySingle は、VerifyInit の直後に Verify を実行するのと同じです。

(key, klen) の BLOB と pmech のメカニズムを一緒に VerifyInit に渡せなければなりません。

公開鍵のメカニズムの場合は、(key, klen) に SPKI を指定する必要があります。 この SPKI は、MAC 署名付きのもの (GenerateKeyPair で公開鍵として返されたものなど) でも、SPKI 自体 (証明書などの外部ソースから取得されたもの) でもかまいません。

VerifyInit、Verify、SignSingle も参照してください。

    CK_RV m_VerifySingle (
        const unsigned char *pubKey, size_t pubKeylen,
        CK_MECHANISM_PTR mech,
        CK_BYTE_PTR data, CK_ULONG datalen,
        CK_BYTE_PTR signature, CK_ULONG signaturelen,
        target_t ターゲット
    );
    

    message DigestInitRequest {
        Mechanism Mech = 2;
    }
    message DigestInitResponse {
        bytes State = 1;
    }
    

PKCS #11 C_DigestInit の実装。

ラップされたダイジェスト状態を作成します。

注: サイズの照会がサポートされます。ただし、ほとんどのサイズの照会では実際の出力ではなく出力のサイズが返されるのに対し、この関数では、常に、ラップされた状態がバックエンドから返されます。 Digest の状態は小さいので、転送のオーバーヘッドが問題になることはありません。

サイズの照会では、単に、戻された状態をホストが破棄して BLOB のサイズ (len) を報告します。 BLOB が戻されるときに、戻されるサイズと len が比較されます。

state、len の BLOB を PKCS #11 の hSession パラメーターからマップする必要があります (ホスト・ライブラリーで BLOB をセッションに結び付けなければなりません)。

    CK_RV m_DigestInit (
        unsigned char * state、size_t * len、
        const CK_MECHANISM_PTR mech,
        target_t ターゲット
    );
    

C_DigestInit は、メッセージ・ダイジェスト生成操作を初期化します。hSession はセッションのハンドル、pMechanism はダイジェスト・メカニズムを指します。

アプリケーションは C_DigestInit を呼び出した後に、C_Digest を呼び出して 1 部構成のデータのダイジェストを生成するか、C_DigestUpdate をゼロ回以上呼び出してから C_DigestFinal を呼び出して複数部構成のデータのダイジェストを生成することができます。 メッセージ・ダイジェスト生成操作は、アプリケーションが C_Digest または C_DigestFinal の呼び出しを使用してメッセージ・ダイジェストを取得するまでアクティブになります。 (1 部構成または複数部構成の) データを追加で処理するには、アプリケーションはもう一度 1C_DigestInit1 を呼び出す必要があります。

    CK_DEFINE_FUNCTION(CK_RV, C_DigestInit)(
        CK_SESSION_HANDLE hSession,
        CK_MECHANISM_PTR pMechanism
    );
    

    message DigestRequest {
        bytes State = 1;
        bytes Data = 2;
    }
    message DigestResponse {
        bytes Digest = 3;
    }
    

PKCS #11 C_Digest の実装。

ダイジェスト・オブジェクトの作成後に、ゼロ・バイト転送の任意の組み合わせで、ちょうど 0 (ゼロ) バイトがそのオブジェクトの末尾に追加された場合でも、ワン・パス・ダイジェストを実行できますが、厳格な実装ではそのオブジェクトは拒否される必要があります。

(state, slen) は更新されません。

実装は以下を実行できます DigestUpdate、 DigestFinal、またはホスト・コード内の平文ダイジェスト・オブジェクトに対する Digest 呼び出し (HSM バックエンド全体をバイパスする)。 この選択はホスト・コードで認識してもしなくてもかまいません。操作のセキュリティーには影響しません (平文オブジェクトでは機密データのダイジェストを生成できないからです)。

state、slen の BLOB を PKCS #11 の hSession パラメーターからマップする必要があります。 state の BLOB は、DigestInit からの出力です。

    CK_RV m_Digest (
        const unsigned char *state, size_t statelen,
        CK_BYTE_PTR data, CK_ULONG datalen,
        CK_BYTE_PTR digest, CK_ULONG_PTR digestlen,
        target_t ターゲット
    );
    

C_Digest は、データをシングル・パートにダイジェスト化します。hSession はセッションのハンドル、pData はデータ、ulDataLen はデータの長さ、pDigest はメッセージ・ダイジェストを受け取るロケーション、pulDigestLen はメッセージ・ダイジェストの長さを保持するロケーションを指します。

C_Digest は、PKCS #11 API 仕様のセクション 5.2 で説明されている出力の生成に関する規則を使用します。

ダイジェスト生成操作を C_DigestInit で初期化する必要があります。 C_Digest を呼び出すと、必ず、アクティブなダイジェスト生成操作が終了されます。ただし、呼び出しで CKR_BUFFER_TOO_SMALL が返された場合、およびメッセージ・ダイジェストを保持するのに必要なバッファー長を確認するために呼び出して成功した場合 (つまり CKR_OK が返された場合) は別です。

複数部構成の操作を終了するために C_Digest を使用することはできません。この関数は、C_DigestInit の後に、C_DigestUpdate の呼び出しを挟まずに呼び出す必要があります。

入力データとダイジェスト出力を同じ場所に配置できます。つまり、pData と pDigest が同じ場所を指していてもかまいません。

C_Digest は、一連の C_DigestUpdate 操作の後に C_DigestFinal を実行するのと同じです。

    CK_DEFINE_FUNCTION(CK_RV, C_Digest)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pData,
        CK_ULONG ulDataLen,
        CK_BYTE_PTR pDigest,
        CK_ULONG_PTR pulDigestLen
    );
    

    message DigestUpdateRequest {
        bytes State = 1;
        bytes Data = 2;
    }
    message DigestUpdateResponse {
        bytes State = 1;
    }
    

PKCS #11 C_DigestUpdate の実装。

DigestUpdate はポリモアフィックです。 ラップされたダイジェスト・オブジェクトまたはクリアされたダイジェスト・オブジェクトの両方を受け入れ、同じ形式で状態を更新します。

state、slen の BLOB を PKCS #11 の hSession パラメーターからマップする必要があります。 (ホスト・ライブラリーで、保存されている状態にセッションをマップしなければなりません)。

state の BLOB は、DigestInit、DigestUpdate、DigestKey からの出力です。

DigestInit も参照してください。

    CK_RV m_DigestUpdate (
        unsigned char *state, size_t statelen,
        CK_BYTE_PTR data, CK_ULONG datalen,
        target_t ターゲット
    );
    

C_DigestUpdate はマルチパートのメッセージ・ダイジェスト生成操作を続行し、別のデータ・パートを処理します。hSession はセッションのハンドル、pPart はデータ・パート、ulPartLen はデータ・パートの長さを指します。

メッセージ・ダイジェスト生成操作を C_DigestInit で初期化する必要があります。 この関数と C_DigestKey の呼び出しは、任意の順序で何度でも繰り返せます。 C_DigestUpdate を呼び出してエラーが発生すると、現在のダイジェスト生成操作が終了します。

    CK_DEFINE_FUNCTION(CK_RV, C_DigestUpdate)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pPart,
        CK_ULONG ulPartLen
    );
    

    message DigestFinalRequest {
        bytes State = 1;
    }
    message DigestFinalResponse {
        bytes Digest = 2;
    }
    

PKCS #11 C_DigestFinal の実装。

DigestFinal は多様な性質を持つ関数です。ラップされたダイジェスト・オブジェクトと平文のダイジェスト・オブジェクトの両方を受け入れます。

(state, slen) は更新されません。

state、slen の BLOB を PKCS #11 の hSession パラメーターからマップする必要があります。

state の BLOB は、DigestInit、DigestUpdate、DigestKey からの出力です。

    CK_RV m_DigestFinal (
        const unsigned char *state, size_t statelen,
        CK_BYTE_PTR digest, CK_ULONG_PTR digestlen,
        target_t ターゲット
    );
    

C_DigestFinal はマルチパートのメッセージ・ダイジェスト生成操作を終了し、メッセージ・ダイジェストを返します。hSession はセッションのハンドル、pDigest はメッセージ・ダイジェストを受け取るロケーション、pulDigestLen はメッセージ・ダイジェストの長さを保持するロケーションを指します。

C_DigestFinal は、PKCS #11 API 仕様のセクション 5.2 で説明されている出力の生成に関する規則を使用します。

ダイジェスト生成操作を C_DigestInit で初期化する必要があります。 C_DigestFinal を呼び出すと、必ず、アクティブなダイジェスト生成操作が終了されます。ただし、呼び出しで CKR_BUFFER_TOO_SMALL が返された場合、およびメッセージ・ダイジェストを保持するのに必要なバッファー長を確認するために呼び出して成功した場合 (つまり CKR_OK が返された場合) は別です。

    CK_DEFINE_FUNCTION(CK_RV, C_DigestFinal)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pDigest,
        CK_ULONG_PTR pulDigestLen
    );
    

    message DigestSingleRequest {
        Mechanism Mech = 1;
        bytes Data = 2;
    }
    message DigestSingleResponse {
        bytes Digest = 3;
    }
    

非標準の拡張機能であり、DigestInit と Digest の組み合わせです。 1 回の呼び出しで一度にデータのダイジェストを生成します。中間のダイジェスト状態を作成することも、不要な往復を行うこともありません。

XCP 対応アプリケーションで平文のダイジェストを生成するには、この方法をお勧めします。 機能的には、DigestSingle は、DigestInit の直後に Digest を実行するのと同じです。

この関数は鍵の BLOB を処理しないので、鍵のダイジェストを生成する場合は、DigestInit と DigestKey を使用する必要があります。

ダイジェスト結果だけがホストに返され、状態は返されません。 すべて PKCS #11 呼び出しから直接使用するため、PKCS #11 以外のパラメーターはありません。

    CK_RV m_DigestSingle (
        CK_MECHANISM_PTR mech,
        CK_BYTE_PTR data, CK_ULONG datalen,
        CK_BYTE_PTR digest, CK_ULONG_PTR digestlen,
        target_t ターゲット
    );