pkcs #11

PKCS#11标准定义了与密码令牌（如硬件安全模块（HSM）和智能卡）的独立于平台的API，并将API本身命名为“Cryptoki”（来自“加密令牌接口”，发音为“crypto-key” - 但是“PKCS#11”通常用于指代API以及定义它的标准）。 API定义了最常用的加密对像类型（RSA密钥，X.509证书，DES / 三重DES密钥等）以及使用，创建/生成，修改和删除这些对象所需的所有功能。

简介在密码系统中，PKCS#11是公钥加密标准（PKCS, Public-Key Cryptography Standards）中的一份子 ，由RSA实验室(RSA Laboratories)发布[1]，它为加密令牌定义了一组平台无关的API ，如硬件安全模块和智能卡。

由于没有一个真正的标准加密令牌，这个API已经发展成为一个通用的加密令牌的抽象层。 PKCS#11 API定义最常用的加密对象类型（ RSA密钥，X.509证书，DES /三重DES密钥等）和所有需要使用的功能，创建/生成，修改和删除这些对象。注意：pkcs#11只提供了接口的定义， 不包括接口的实现，一般接口的实现是由设备提供商提供的，如usbkey的生产厂商会提供 符合PKCS#11接口标准的API的实现。这样你只要通过接口调用API函数即可实现其功能。1

适用范围本标准为那些保存密码信息，执行密码函数的设备确定一种程序设计接口（API），该接口称做Cryptoki。Cryptoki发“Crypto-Key”音，是cryptographic token interface （密码令牌接口）的缩写，它遵循一种基于对象的简单方法，提出技术独立性（各种各样的设备）和资源共享（多个应用程序访问多个设备）的目标，把设备的一种通用的逻辑视图，即密码令牌，提供给应用程序。2

本文档通过使用ANSI C程序语言确定适用于需要密码服务的应用程序的数据类型和函数。这些数据类型和函数将由Cryptoki库的供应者通过C字头文档提供。Cryptoki的通用ANSI C字头文件可在PKCS网页上得到。该文档和Crypto的最新勘误表都可在同一地方得到。

附加文档可提供一个通用的语言独立的Cryptoki界面和/或Cryptoki与其它程序设计语言间的联编。

Cryptoki 把应用从密码设备的详细资料中隔离出来。应用程序不必转换成另一种不同设备的接口或在不同环境下运行，因此，应用程序是很轻便的。Cryptoki怎样提供这种隔离超出了本文档的描述范围，尽管在这里和可能在其他文档中找到某些支持多种设备的协定。

本版本支持许多密码机制。除此之外，新机制能在不改变通用界面的情况下添加进来。可能其它的机制会在不同的文档中发表，也有可能令牌的提供者确定他们自己的机制（即使由于相互合作、通过PKCS处理的注册更可取的缘故）。

Cryptoki 2.1版本用来连接单个用户的密码设备，所以省略了某些通用目的界面中的特点。例如，Cryptoki 2.1 版本没有区别众多用户的方式。重点在单个用户的密钥以及可能与这些密钥相关的证书。况且，重点在加密上。当设备执行有用的非加密函数时，这些函数放到了其它界面上。

应用PKCS#11主要是应用于智能卡和HSM 。大多数商业证书颁发机构软件使用PKCS#11访问CA的签名密钥或注册用户证书。跨平台的软件需要使用的PKCS #11的智能卡，如Mozilla Firefox和OpenSSL （扩展使用） PKCS#11 。为微软Windows编写的软件或许会用特定平台的MS-CAPI API来取代

Cryptoki 为一个或多个密码设备提供一个接口，这些设备通过大量的槽在系统中运行。每个对应于一个物理阅读器或另一个设备接口的槽可包含一个令牌。当一台密码设备存在于阅读器中，一个令牌就存在于该槽中。当然，由于Cryptoki提供槽和令牌的逻辑视图，所以可能有其它的物理译码。多个槽可能共享一个阅读器。问题在于一个系统有相当多的槽，应用程序能连接到这些槽的其中任何一个或全部槽的令牌上。

密码设备可以按照某一命令集执行某些密码操作，这些命令通常要经过标准设备驱动程序，例如PCMCIA卡服务程序或槽服务程序。Cryptoki使每个密码设备看起来逻辑上很象其它设备，而不管什么技术实现的。因此，应用程序不必直接与设备驱动器接口（或甚至不必知道包括那些设备）；Cryptoki 隐藏了这些细节。的确，基础设备完全能用软件来实现，（例如，在一个服务器上运行的处理程序），不须专用硬件。

Cryptoki 或许可以作为支持接口功能的库来实现，而应用程序则与该库连接。应用程序可以直接与Cryptoki 连接，或者，Cryptoki 是一个所谓的“共享”库（或动态连接库），在这种情况下，应用程序动态地连接库。用Microsoft Windows和OS/2操作系统可以比较容易地生成数据库，并且在UNIX和DOS中也可相对容易地生成“共享”库。

由于新库可以使用，所以动态方法有许多优点；但从安全的角度来说，也有一些缺点。要特别指出的是，如果库能较容易地被替换，攻击者有可能用恶意制造的假库取而代之，以截取用户的PIN。即使编码签名技术能防止许多动态连接的安全危险，从安全角度来说，一般采用直接连接。总之，应用程序和Cryptoki 库之间的程序设计接口是相同的。

设备的种类和所支持的能力的种类将取决于专用Cryptoki 库。本标准只定义库的接口，不定义库的特征。要特别指出的是，并不是所有的库支持这个接口（因为不是所有的令牌支持所有的机制）中定义的机制（算法）。并且库也许只支持可使用的所有密码设备的一个子集。（当然，可以预料更多更好的设备种类将被开发，以支持多种令牌，而不是单个供应商提供的令牌。）只要开发出应用程序，就会形成Cryptoki 的接口、标准数据库和令牌“轮廓”（profile）。

关系KMIP该密钥管理互操作协议（KMIP）定义了具有类似的功能的PKCS#11 API一个有线协议。这两个标准最初是独立开发的，但现在由OASIS技术委员会管理。PKCS#11和KMIP委员会的明确目标是在切实可行的情况下对准标准。例如，PKCS#11敏感和可提取属性正在添加到KMIP 1.4版本中。两个技术委员会成员之间有相当大的重叠。

本词条内容贡献者为:

王沛 - 副教授、副研究员 - 中国科学院工程热物理研究所