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,
      目标
    );
    

C_GetMechanismList 用于获取令牌支持的机制类型的列表。 SlotID 是令牌槽的标识；pulCount 指向接收机制数的位置。

有两种方法可供应用程序调用 C_GetMechanismList:

1. 如果 pMechanismList 为 NULL_PTR，那么 C_GetMechanismList 执行的所有操作都是返回机制数 (在 *pulCount中)，而不返回机制列表。 在这种情况下，进入 C_GetMechanismList 时 *pulCount 的内容没有任何褒意义，并且该调用会返回值 CKR_OK。
2. 如果 pMechanismList 不是 NULL_PTR，那么 *pulCount 必须包含 pMechanismList指向的缓冲区的大小 (根据 CK_MECHANISM_TYPE 元素)。 如果该缓冲区足够大，可以保存机制列表，那么会在其中返回该列表，并返回 CKR_OK。 否则，调用 C_GetMechanismList 会返回值 CKR_BUFFER_TOO_SMALL。 在任一情况下，值 *pulCount 都会设置为保存机制数。

由于 C_GetMechanismList 未分配任何自己的空间，因此应用程序通常会调用 C_GetMechanismList 两次。 但是，此行为绝不是必需的。

    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,
      目标
    );
    

C_GetMechanism信息 获取有关令牌可能支持的特定机制的信息。slotID 是令牌槽的标识; 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> 模板 = 6;
    }
    message GenerateKeyResponse {
      字节 KeyBytes = 4;
      bytes CheckSum = 5;
    }
    

PKCS #11 C_GenerateKey 的实现。

TDES 密钥是使用正确的奇偶性校验生成的，主机无法观察到该奇偶性校验。 但是需要它才能实现正确的互操作性: 其他 PKCS #11 实现需要拒绝具有奇偶性校验问题的 DES 密钥。

如果对象与会话绑定，那么 (pin，plen) 必须由 Login 返回到该会话。 将 pin 保留为 NULL 会创建一个未绑定到登录会话的公共对象。

(key，klen) 返回密钥 blob。(csum，clen) 包含密钥的校验和，即密钥加密的全零块的最重要字节。 例如，对于不使用 CKA_CHECK_VALUE 参数的对称密钥机制（如 RC4），可以使用 NULL clen。

仅当机制需要键长度 (即 CKA_VALUE_LEN 属性) 时，才会使用 ptempl。 如果机制隐式指定密钥大小，那么不会检查 ptempl 来获取大小。

DSA 和 DH 参数生成会忽略 (csum, clen)，以仅生成参数结构。

DSA，DH 参数 (CKM_DSA_PARAMETER_GEN): 传递属性的 CKA_PRIME_BITS 中的模数位计数。 将 P，Q，G 结构写入为 cleartext 输出 (即，不是 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
      目标
      );
    

C_GenerateKey 生成密钥或一组域参数，从而创建新对象。hSession 是会话的句柄; pMechanism 指向生成机制; pTemplate 指向新密钥或一组域参数的模板; ulCount 是模板中的属性数; phKey 指向接收新密钥或一组域参数的句柄的位置。

如果生成机制用于域参数生成，那么 CKA_CLASS 属性的值为 CKO_DOMAIN_PARAMETERS; 否则，它的值为 CKO_secret T_KEY。

由于要生成的密钥或域参数的类型在生成机制中是隐式的，因此模板不需要提供密钥类型。 如果它提供了与生成机制不一致的密钥类型，那么 C_GenerateKey 将失败并返回错误代码 CKR_TEMPLATE_CONSISTENT。 以相同方式处理 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> PrivKey模板 = 7;
      map<uint64,AttributeValue> PubKey模板 = 8;
      }
    message GenerateKeyPairResponse {
      字节 PrivKey字节 = 5;
      字节 PubKey字节 = 6;
    }
    

PKCS #11 C_GenerateKeyPair 的实现。

密钥对参数是从 pmech、ppublic 和 pprivate 参数中检索到的。 对于 RSA 密钥，ppublic 指定模数大小。

在 FIPS 方式下，仅支持 1024 + 256 n 位的 RSA 模 (整数 n)。 非 FIPS 方式可以在机制参数列表的限制之间生成任何偶数位的密钥。

公用密钥格式化为标准 SPKI (主题公用密钥信息)，可由大多数库读取。 它由特定于传输密钥的 MAC 进行完整性保护，该 MAC 并不属于 SPKI 本身。 DSA 参数生成在公用密钥字段中返回非 SPKI 结构。

如果将对象与会话绑定，那么 (pin，plen) 必须由 Login 返回到该会话。 保留 pin NULL 将创建一个公共对象，该对象在登录会话中尚存。

将打包的专用密钥返回到 (key, klen)，将公用密钥以设置了 MAC 的 ASN.1/DER 结构在 (pubkey, pklen) 中返回。

具有特殊注释的以下受支持参数组合超出 PKCS #11记录的范围:

RSA 密钥拒绝低于 17 (0x11) 的公共指数。 控制点可以进一步限制已接受的最小值。 Fergmat4 指数 (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)：将 P,Q,G 结构作为公共属性的 CKA_IBM_STRUCT_PARAMS 属性传递。 单个 P，Q，G 参数可能无法通过常规 PKCS #11 参数传递，它们必须组合到单个结构中。

DH 密钥 (CKM_DH_PKCS_KEY_PAIR_GEN)：将 P,G 结构作为公共属性的 CKA_IBM_STRUCT_PARAMS 属性传递。 个别 P，G 参数可能无法通过常规 PKCS #11 参数传递，它们必须组合到单个结构中。 选择专用密钥 (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
      无符号字符 *pubKey，size_t *pubKeylen，
      目标
      );
    

C_GenerateKey对 生成公用和专用密钥对，从而创建新的密钥对象。hSession 是会话的句柄; pMechanism 指向密钥生成机制; pPublicKeyTemplate 指向公用密钥的模板; ulPublicKeyAttributeCount 是公用密钥模板中的属性数; pPrivateKeyTemplate 指向专用密钥的模板; ulPrivateKeyAttributeCount 是专用密钥模板中的属性数; phPublicKey 指向接收新公用密钥句柄的位置; phPrivateKey 指向接收新专用密钥句柄的位置。

由于要生成的密钥类型隐含在密钥对生成机制中，因此模板不需要提供密钥类型。 如果其中一个模板提供了与密钥生成机制不一致的密钥类型，那么 C_GenerateKey对 将失败并返回错误代码 CKR_TEMPLATE_CONSISTENT。 CKA_CLASS 属性的处理方式类似。

如果对 C_GenerateKeyPair 的调用无法支持提供给它的精确模板，那么它将失败并返回而不创建任何键对象。

对 C_GenerateKeyPair 的调用从不只创建一个键并返回。 调用可能会失败，并且不会创建密钥; 或者可以成功，并创建匹配的公用和专用密钥对。

通过成功调用 C_GenerateKeyPair 创建的密钥对象将 CKA_LOCAL 属性设置为 CK_TRUE。

请仔细注意 C_GenerateKeyPair 自变量的顺序。 最后两个自变量的顺序与原始 Cryptoki V1.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> 模板 = 8;
    }
    message DeriveKeyResponse {
        字节 NewKey字节 = 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,
        无符号字符 *newKey，size_t *newKeylen，
        Unsigned char *checkSum，size_t *checkSumlen
        目标
    );
    

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,
        目标
    );
    

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，也无法对该密钥打包，那么 C_WrappKey 会失败，错误代码为 CKR_KEY_NOT_WRAPABLE。 如果密钥完全由于其长度而无法使用指定的打包密钥和机制进行打包，那么 C_WrappKey 会失败，错误代码为 CKR_KEY_SIZE_RANGE。

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> 模板 = 9;
    }
    message UnwrapKeyResponse {
        字节 UnwrappedBytes = 7;
        bytes CheckSum = 8;
    }
    

PKCS #11 C_UnwrapKey 的实现。

uwmech 指定用于解密打包数据的加密机制。ptempl 是 key (pair) 参数列表，用于指定如何将已解包的数据变换为新密钥 (必须包含 CKA_KEY_TYPE)。

生成的对象在 (unwrapped, uwlen) 下作为 BLOB 返回。 对称密钥在 (csum, cslen) 下返回其密钥校验和（3 字节）；公用密钥对象在 (csum, cslen) 中将其公用密钥作为 SPKI 返回。 这两种格式都后跟一个 4 字节的大尾数值，并对已解包密钥的位计数编码。

当 SPKI 转换为 MACed 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 * unwrap，size_t * unwrappedlen，
        CK_BYTE_PTR checkSum, CK_ULONG *checkSumlen,
        目标
    );
    

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_CONSISTENT。

    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
    );
    

    消息 RewrapKeyBlobRequest {
    	字节 WrappedKey = 1;
    }
    消息 RewrapKeyBlobResponse {
    	字节 RewrappedKey = 1;
    }
    

    message GetAttributeValueRequest {
        bytes Object = 1;
        map<uint64,AttributeValue> 属性 = 3;
    }
    message GetAttributeValueResponse {
        map<uint64,AttributeValue> 属性 = 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,
        目标
    );
    

C_GetAttributeValue 获取对象的一个或多个属性的值。hSession 是会话的句柄; hObject 是对象的句柄; pTemplate 指向一个模板，该模板指定要获取的属性值，并接收属性值; ulCount 是模板中的属性数。

对于模板中的每个 (type, pValue, ulValueLen) 三元组，C_GetAttributeValue 会执行以下算法：

1. 如果由于对象敏感或不可抽取而无法显示对象的指定属性 (即类型字段指定的属性)，那么将修改该三元组中的 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) 的特殊情况，其中传递的属性 pValue 不为 NULL，那么如果数组中元素的 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 的调用返回这三个值中的任何一个，那么调用必须已处理提供给 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> 属性 = 3;
    }
    message SetAttributeValueResponse {
        bytes Object = 1;
    }
    

PKCS #11 C_SetAttributeValue 的实现。

属性打包：请参阅 _GetAttrValue

目前，EP11 仅发送布尔值属性，其他所有属性都由主机处理（并且 EP11 不允许修改数组，例如 WRAP_TEMPLATE）。

不表示或不需要会话 (blob 的一部分)，因此不使用 PKCS #11 hSession 参数。

    CK_RV m_SetAttributeValue (
        unsigned char *object, size_t objectlen,
        CK_ATTRIBUTE_PTR attributes, CK_ULONG attributeslen,
        目标
    );
    

C_SetAttributeValue 修改对象的一个或多个属性的值。hSession 是会话的句柄; hObject 是对象的句柄; pTemplate 指向一个模板，该模板指定要修改的属性值及其新值; ulCount 是模板中的属性数。

某些对象可能未修改。 对此类对象调用 C_SetAttributeValue 会生成 CKR_ACTION_DAMAGED 错误代码。 应用程序可以查阅对象的 CKA_MODIALLOWED 属性以确定是否可以修改对象。

在只读会话期间，只能修改会话对象。

模板可以为可修改的对象的任何属性指定新值。 如果模板指定与对象的其他现有属性不兼容的属性值，那么调用将失败，返回码为 CKR_TEMPLATE_CONSISTENT。

并非所有属性都可以修改; 请参阅 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（ANSI X9.31/ISO 18031，取决于 Clic 版本）来传递以硬件为种子的熵。

如果主机上有适用的功能可用，那么主机库可以生成随机数，而不分派给后端。 在当前实现中不会这样做。

此函数不支持大小查询。

    CK_RV m_GenerateRandom (
        CK_BYTE_PTR rnd, CK_ULONG rndlen,
        目标
    );
    

    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 通过 MAC 密钥保护其完整性，如 GenerateKeyPair 或 UnwrappKey 返回的内容。 创建加密状态时，没有会话限制。

对于密钥机制，“加密”状态从 (key，klen)继承对象会话限制。

state,slen BLOB 必须从 PKCS #11 hSession 参数映射。

(key, klen) 必须是密钥 BLOB。

    CK_RV m_EncryptInit (
        无符号字符 * 状态，size_t * 状态，
        CK_MECHANISM_PTR mech,
        const unsigned char *key, size_t keylen,
        目标
    );
    

C_EncryptInit 初始化加密操作。hSession 是会话的句柄; pMechanism 指向加密机制; hKey 是加密密钥的句柄。

加密密钥的 CKA_ENCRYPT 属性（指示密钥是否支持加密）必须为 CK_TRUE。

在应用程序调用 C_EncryptInit之后，应用程序可以调用 C_Encrypt 以加密单个部件中的数据; 或者调用 C_EncryptUpdate 零次或多次，后跟 C_EncryptFinal以加密多个部件中的数据。 加密操作处于活动状态，直到应用程序使用对 C_Encrypt 或 C_EncryptFinal 的调用来获取最后一段密文。 要处理额外数据 (单部分或多部分)，应用程序必须再次调用 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,
        目标
    );
    

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 的实现。

必须从 PKCS #11 hSession 参数映射 state，slen blob。

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,
        目标
    );
    

C_EncryptUpdate 继续执行多部分加密操作，处理另一数据部分。hSession 是会话的句柄; pPart 指向数据部分; ulPartLen 是数据部分的长度; pEncryptedPart 指向接收加密数据部分的位置; pulEncryptedPartLen 指向保存加密数据部分的长度 (以字节计) 的位置。

C_EncryptUpdate 使用 PKCS #11 API 规范 的 5.2 部分中描述的关于生成输出的约定。

必须使用 C_EncryptInit初始化加密操作。 此函数可以连续调用任意次数。 如果调用 C_EncryptUpdate 生成除 CKR_BUFFER_TOO_SMALL 以外的错误，那么该调用会终止当前加密操作。

plaintext 和 ciphertext 可以位于同一位置，即，如果 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,
        目标
    );
    

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 的非标准变体。 用于通过一个调用一次性处理数据。 此函数不会将任何状态返回到主机，仅返回加密数据。

这是一次性加密 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,
        目标
    );
    

    消息 ReencryptSingle请求 {
        字节 DecKey = 1;
        字节 EncKey = 2;
        机制 DecMech = 3;
        机制 EncMech = 4;
        已引信的字节数 = 5;
    }
    消息 ReencryptSingle响应 {
        接收方的字节数 = 6;
    }
    

Encrypt 的非标准变体。 用于通过一个调用一次性处理数据。 不向主机返回任何状态，仅返回重新加密的数据。

使用原始密钥对数据进行解密，然后使用云 HSM 中的其他密钥对原始数据进行加密。

    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,
        目标
    );
    

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

    CK_RV m_DecryptInit (
        无符号字符 * 状态，size_t * 状态，
        CK_MECHANISM_PTR mech,
        const unsigned char *key, size_t keylen,
        目标
    );
    

C_DecryptInit 初始化解密操作。hSession 是会话的句柄; pMechanism 指向解密机制; hKey 是解密密钥的句柄。

解密密钥的 CKA_DECRYPT 属性（指示密钥是否支持解密）必须为 CK_TRUE。

在应用程序调用 C_DecryptInit之后，应用程序可以调用 C_Decrypt 以解密单个部件中的数据; 或者调用 C_DecryptUpdate 零次或多次，后跟 C_DecryptFinal以解密多个部件中的数据。 解密操作处于活动状态，直到应用程序使用对 C_Decrypt 或 C_DecryptFinal 的调用来获取最后一段明文。 要处理额外数据 (单部分或多部分)，应用程序必须再次调用 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,
        目标
    );
    

C_Decrypt 用于解密单部分中的加密数据。

• 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 调用。

密文和纯文本可以位于同一位置，这意味着如果 pEncrypted数据和 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,
        目标
    );
    

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,
        目标
    );
    

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 的非标准变体。 用于通过一个调用一次性处理数据。 此函数不会将任何状态返回到主机，仅返回解密数据。

这是一次性加密 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,
        目标
    );
    

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

    CK_RV m_SignInit (
        无符号字符 * 状态，size_t * 状态，
        CK_MECHANISM_PTR mech,
        const unsigned char *privKey, size_t privKeylen,
        目标
    );
    

C_SignInit 初始化签名操作，其中签名是数据的附录。hSession 是会话的句柄; pMechanism 指向签名机制; hKey 是签名密钥的句柄。

签名密钥的 CKA_SIGN 属性（指示密钥是否支持带附录的签名）必须为 CK_TRUE。

在应用程序调用 C_SignInit之后，应用程序可以调用 C_Sign 以登录单个部件; 或者调用 C_SignUpdate 一次或多次，后跟 C_SignFinal，以签署多个部件中的数据。 签名操作处于活动状态，直到应用程序使用对 C_Sign 或 C_SignFinal 的调用来获取签名。 要处理额外数据 (单部分或多部分)，应用程序必须再次调用 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,
        目标
    );
    

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,
        目标
    );
    

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,
        目标
    );
    

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 的组合。 用于通过一个调用一次性对数据签名或设置 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,
        目标
    );
    

    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 可以是 MACed (例如 GenerateKeyPair先前返回的内容) 或仅 SPKI 本身 (如果从外部源 (例如证书) 获取)。

如果初始化 HMAC 操作，那么会从 HMAC 密钥继承 Verify 对象的会话限制。 由于 SPKI 未绑定到会话，因此公用密钥验证状态与会话无关。

key,klen BLOB 必须从 PKCS #11 hKey 参数映射。

注: SignInit 和 VerifyInit 是内部 与 HMAC 和其他对称性 /MAC 机制相同。

    CK_RV m_VerifyInit (
        无符号字符 * 状态，size_t * 状态，
        CK_MECHANISM_PTR mech,
        const unsigned char *pubKey, size_t pubKeylen,
        目标
    );
    

C_VerifyInit 初始化验证操作，其中签名是数据的附录。hSession 是会话的句柄; pMechanism 指向指定验证机制的结构; hKey 是验证密钥的句柄。

验证密钥的 CKA_VERIFY 属性（指示密钥是否支持签名是数据附录的验证）必须为 CK_TRUE。

在应用程序调用 C_VerifyInit之后，应用程序可以调用 C_Verify 来验证单个部件中数据的签名; 或者调用 C_VerifyUpdate 一次或多次，后跟 C_VerifyFinal，以验证多个部件中数据的签名。 验证操作一直处于活动状态，直到应用程序调用 C_Verify 或 C_VerifyFinal。 要处理额外的数据 (单部分或多部分)，应用程序必须再次调用 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,
        目标
    );
    

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,
        目标
    );
    

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,
        目标
    );
    

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 的组合。 用于通过一个调用一次性对数据签名或设置 MAC，而不构造中间摘要状态。 此函数不会将任何状态返回到主机，仅返回验证结果。 由于此函数返回布尔值，因此没有可用的大小查询。

这是验证签名的首选方法，无需额外的双向传递，加密和解密。 在功能上，VerifySingle 等效于 VerifyInit 后跟 Verify。

(key, klen) BLOB 和 pmech 机制必须能够一起传递到 VerifyInit。

对于公用密钥机制，(key, klen) 必须包含 SPKI。 此 SPKI 可以是 MACed (例如，作为公用密钥从 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,
        目标
    );
    

    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,
        目标
    );
    

C_DigestInit 初始化消息摘要操作。hSession 是会话的句柄; pMechanism 指向摘要机制。

在应用程序调用 C_DigestInit之后，应用程序可以调用 C_Digest 来对单个部件中的数据进行摘要; 或者调用 C_DigestUpdate 零次或多次，后跟 C_DigestFinal来对多个部件中的数据进行摘要。 在应用程序使用对 C_Digest 或 C_DigestFinal 的调用来获取消息摘要之前，消息摘要操作处于活动状态。 要处理额外数据 (单部分或多部分)，应用程序必须再次调用 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 调用主机代码中的 cleartext 摘要对象，完全绕过 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,
        目标
    );
    

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,
        目标
    );
    

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,
        目标
    );
    

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 的组合。 通过一个调用一次性对数据进行摘要，而不构造中间摘要状态，避免了不必要的往返。

这是对 XCP 感知应用程序的明文进行摘要的首选方法。 在功能上，DigestSingle 等效于 DigestInit 直接后跟 Digest。

如果需要对密钥进行摘要，那么必须使用 DigestInit 和 DigestKey，因为此函数不会处理密钥 BLOB。

不会将任何状态返回到主机，仅返回摘要结果。 没有非 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,
        目标
    );