基本数据类型：CK_BYTE、CK_ULONG、CK_CHAR 等

PKCS#11 标准从 C 语言里选了十几个基础类型，然后包了一层别名。说白了，就是告诉你“别直接用 C 的 unsigned char，给我用 CK_BYTE”。

刚开始接触这个的时候，我总觉得多此一举。后来跨平台遇到过坑，才明白这些别名是给接口上保险的。今天咱们把这些类型捋一遍，后面写 SDK 对接时心里就有底了。

类型总览

类型名	C 底层	位宽	常见用途
CK_BYTE	unsigned char	8 bit	原始数据缓冲区、密钥材料
CK_ULONG	unsigned long	32 或 64 bit（平台相关）	长度、句柄、标志位、计数
CK_CHAR	char	8 bit（ANSI）	固定长度字符串（如标签、厂商ID）
CK_BBOOL	CK_BYTE	8 bit	布尔值（CK_TRUE / CK_FALSE）
CK_VOID_PTR	void*	指针（平台相关）	通用数据指针、模板传递
CK_SESSION_HANDLE	CK_ULONG	同 CK_ULONG	会话标识
CK_OBJECT_HANDLE	CK_ULONG	同 CK_ULONG	对象标识
CK_MECHANISM_TYPE	CK_ULONG	同 CK_ULONG	算法机制编号
CK_KEY_TYPE	CK_ULONG	同 CK_ULONG	密钥类型编号

类型细节与实战注意

CK_BYTE

这就是无符号字节，最基础的砖块。我习惯把它当作“不解释含义的原始二进制”。加密后的密文、密钥字节数组都离不开它。

// 声明一个 32 字节的缓冲区
CK_BYTE keyData[32];

CK_ULONG

嗯，这个坑最多。unsigned long 在 Windows 上永远是 32 位，Linux 上 64 位环境是 64 位。我记得有一次在 X64 机器上把 sizeof(CK_ULONG) 打印出来，发现两边对不上，数据直接传错了。

CK_CHAR

PKCS#11 里用到 CK_CHAR 的地方基本都是固定长度的“C 风格字符串”。比如 CKA_LABEL 最多 32 字节。它不考虑终止符！如果你用 strcpy 去填，长度不够时会把后面的内存干掉。

CK_CHAR label[32];
memset(label, ' ', 32);          // 先清空，默认空格
memcpy(label, "MyKey", 5);       // 手动拷贝，不加 '\0'

CK_BBOOL

底层其实是 CK_BYTE，但只能取两个值：CK_TRUE（1）和 CK_FALSE（0）。千万别自作聪明直接写 attr->ulValueLen = 0 当 false，在某些 HSM 上会触发未定义行为。我踩过这个坑，查了一天才发现是布尔值赋值不对。

句柄类型：CK_SESSION_HANDLE / CK_OBJECT_HANDLE

本质上都是 CK_ULONG，但 PKCS#11 把它们单独拎出来，意思是“别拿它做加减法”。句柄是 HSM 内部管理的索引，你只管传，别解析。

CK_VOID_PTR

万能指针。用来传递模板数组 CK_ATTRIBUTE 里的 pValue，或者某些函数的输入/输出缓冲区。定义模板时经常这样用：

CK_ATTRIBUTE template[] = {
    {CKA_CLASS,    &classVal,       sizeof(classVal)},
    {CKA_KEY_TYPE, &keyTypeVal,     sizeof(keyTypeVal)},
    {CKA_VALUE,    byteArray,        32}
};

数据类型体系图

下面这张图帮梳理了常用类型之间的关系。从基础计算类型（左）到专用句柄（中），再到上层应用类型（右）。

看到这个图你应该能明白：底层的 CK_BYTE、CK_ULONG、CK_CHAR 支撑了所有上层结构，而句柄类型只是 CK_ULONG 的语义包装。掌握了这些基础，后面理解模板、会话、对象就容易多了。