163 blogs的博客：ePass1000, ePass2000, ePassNG, Shuttle对Container处理的不同及延续

在1k里，container没有对应的文件单独存储。

container里有秘钥和证书。那么有相同CKA_ID值的对象表示组成一个container.container名字或者取CKA_ID值，或者取秘钥模的哈希值作为名字（根据CKA_ID是否为可识别字符来选择策略）。
container刚刚创建，是空的。因为container对象在卡上没有对应的p11对象来表示，所以创建container的同时创建一个CKO_DATA类型的对象，作为Container的占位符以说明这个名字的 container已创建过（以特殊字符+container名作为data对象的label）。一旦container里有了对象（如创建了秘钥），则马上把此占位的data对象删除.创建秘钥或证书时设置其CKA_ID值为container名字。这时container里有对象了，应用第一条规则。

因此，1k只支持单证。

因为1k是存储卡，所以key和p11对象二者合一，天生对应。

因为2k有密码芯片，key是密码芯片负责管理的，与p11对象分开存放，所以它们之间必须要有对应关系。所以在2k的全系列卡上，文件系统里ID为1的文件有特殊作用。这个文件通过写一个keyid和p11对象起始文件的fid的表，记录了keyid与对象的对应关系。

FT1/FT10:

ey index	0	1	2	3	4	5	6	7	8
key ID	0×84	0×85	0×86	0×87	0×88	0×89	0x8A	0x8B	0x8C
file ID	0	x	0	x	x	x	x	0	0

FT2:

key index	0	1	2	3	4	5	6	7	8
key ID	1	2	3	4	5	6	7	8	9
file ID	0	x	0	x	x	x	x	0	0

2k的pkcs#11中没有单独的属性存储Container Name，而是在CSP中用CKD_ID属性存储Container Name。

NG和Shuttle里Container单独存储为一个文件，Container文件属性为3。因为其他对象没有记录container名字，而只记录container的FID,所以读取时，container先于其他对象读取，写入时先于其它对象写入,否则无法设置对象的CKA_CONTAINER_NAME属性。在NG里，container有对应的文件。文件内容是：

字段长	1	1	名字长度	1	1
字段名	（名字长度＋1）高字节	（名字长度＋1）低字节	名字	\0	引用计数

秘钥和证书对象里有一个属性CKA_CONTAINER_NAME,记录了它所在container的名字。（实际往卡上存储时，没有在此字段里存储字符串，只存储了一个container文件的file ID）

当使用CSP时，这时container先创建出来了，容器内的秘钥和证书的CKA_ID为:

containername+“1” 如果AT_KEYEXCHANGE
containername+“2” 如果AT_SIGNATURE
containername+“1” 如果AT_SIGNATURE|AT_KEYEXCHANGE。

所以NG支持双证.

类似于2k,NG里的每一个卡也记录了kid与p11对象的关系：

FT11/FT12/ePass3000/ePass3000nd:

key index	0	1	2	3	4	5	6	7	8
key ID	0	0	0	0	0	0	0	0	0
file ID	0	x	0	x	x	x	x	0	0

但是，虽然卡上存储的是以上内容，tsp获取keyid时动态的把index+1作为keyID，所以与FT2的相同。

FT1/FT10:

key index	0	1	2	3	4	5	6	7	8
key ID	0×84	0×85	0×86	0×87	0×88	0×89	0x8A	0x8B	0x8C
file ID	0	x	0	x	x	x	x	0	0

FT2:

key index	0	1	2	3	4	5	6	7	8
key ID	1	2	3	4	5	6	7	8	9
file ID	0	x	0	x	x	x	x	0	0

特别的，1knd也是存储卡，其kid和对象天生对应，故没有kid文件。

公钥存储时比1k中间件多出一个CKA_CONTAINER_NAME属性。