PKCS#11 v2.20：RSA加密令牌接口标准概览

5星 · 超过95%的资源需积分: 15 72 浏览量更新于2024-07-26 收藏 1.2MB PDF 举报

PKCS #11 v2.20是RSA Security Inc.于2004年6月28日发布的Public-Key Cryptography Standards (PKCS)系列标准之一，专注于加密令牌接口（Cryptographic Token Interface Standard）。该标准定义了用于软件安全模块（Smart Card Readers, HSMs, 或其他硬件安全设备）与应用程序之间的接口，以实现加密、密钥管理以及其他密码学功能。首先，版权信息表明文档可复制的条件是必须在提及或引用时明确标识为“RSASecurityInc. Public-Key Cryptography Standards”。标准的目标在于提供一个通用的接口，使得不同的加密硬件能够与各种软件应用程序无缝协作，确保数据的安全性。 6.1部分介绍了标准的背景，强调了它作为加密技术在现代安全环境中的重要性，包括对传统加密算法如DES（Data Encryption Standard）的支持，以及对新兴加密技术的兼容性。设计目标涉及跨平台、易用性、安全性以及互操作性。 6.3部分阐述了标准的总体模型，它定义了一个逻辑上的抽象层，将硬件令牌的底层实现细节隐藏起来，仅向上层应用暴露必要的接口。这使得开发者无需关心具体的硬件实现，只需要遵循PKCS #11规范即可。 6.4中，逻辑视图展示了令牌如何通过API与应用程序交互，包括用户认证、会话管理、对象操作等核心组件。用户模型区分了只读和读写会话状态，并规定了不同类型的会话可以访问的权限级别。会话事件和处理机制也在此处详细说明。 6.8提到了已过时的二级认证功能，尽管如此，了解其历史背景对于理解完整标准是必要的。随着更高级别的安全措施的发展，这个功能可能已被替代或改进。 7.0章节着重于安全考虑，包括如何保护敏感数据、防止未授权访问、以及如何在不同的系统和编译环境下保持一致性。这部分内容对于开发者在实际应用中实施PKCS #11至关重要。 8.0则针对C++编程语言给出了平台和编译器依赖的指令，指导开发者如何正确地在他们的代码中集成PKCS #11接口，以确保兼容性和性能。 PKCS #11 v2.20是一个全面且细致的标准，为密码学令牌与软件之间的交互提供了清晰的指导，确保了跨平台的互操作性和安全性。理解并遵循这个标准对于开发基于硬件安全模块的应用程序是至关重要的。

1. INTRODUCTION 1

1 Introduction

As cryptography begins to see wide application and acceptance, one thing is increasingly

clear: if it is going to be as effective as the underlying technology allows it to be, there

must be interoperable standards. Even though vendors may agree on the basic

cryptographic techniques, compatibility between implementations is by no means

guaranteed. Interoperability requires strict adherence to agreed-upon standards.

Towards that goal, RSA Laboratories has developed, in cooperation with representatives

of industry, academia and government, a family of standards called Public-Key

Cryptography Standards, or PKCS for short.

PKCS is offered by RSA Laboratories to developers of computer systems employing

public-key and related technology. It is RSA Laboratories' intention to improve and

refine the standards in conjunction with computer system developers, with the goal of

producing standards that most if not all developers adopt.

The role of RSA Laboratories in the standards-making process is four-fold:

1. Publish carefully written documents describing the standards.

2. Solicit opinions and advice from developers and users on useful or

necessary changes and extensions.

3. Publish revised standards when appropriate.

4. Provide implementation guides and/or reference implementations.

During the process of PKCS development, RSA Laboratories retains final authority on

each document, though input from reviewers is clearly influential. However, RSA

Laboratories’ goal is to accelerate the development of formal standards, not to compete

with such work. Thus, when a PKCS document is accepted as a base document for a

formal standard, RSA Laboratories relinquishes its “ownership” of the document, giving

way to the open standards development process. RSA Laboratories may continue to

develop related documents, of course, under the terms described above.

PKCS documents and information are available online at

http://www.rsasecurity.com/rsalabs/PKCS/. There is an electronic

mailing list, “cryptoki”, at rsasecurity.com, specifically for discussion and

development of PKCS #11. To subscribe to this list, send e-mail to

majordomo@rsasecurity.com with the line “subscribe cryptoki” in the

message body. To unsubscribe, send e-mail to majordomo@rsasecurity.com

with the line “unsubscribe cryptoki” in the message body.

Comments on the PKCS documents, requests to register extensions to the standards, and

suggestions for additional standards are welcomed. Address correspondence to:

2 PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD

PKCS Editor

RSA Laboratories

174 Middlesex Turnpike

Bedford, MA 01730 USA

pkcs-editor@rsasecurity.com

http://www.rsasecurity.com/rsalabs/PKCS

It would be difficult to enumerate all the people and organizations who helped to produce

PKCS #11. RSA Laboratories is grateful to each and every one of them. Special thanks

go to Bruno Couillard of Chrysalis-ITS and John Centafont of NSA for the many hours

they spent writing up parts of this document. Thanks also for the many other technical

descriptions provided by many industry specialists. The reviewers of the document,

without whose help the quality of the content would not be as great, must also be

acknowledged and thanked. The review effort cannot be underestimated especially for a

document so large.

For Version 1.0, PKCS #11’s document editor was Aram Pérez of International

Computer Services, under contract to RSA Laboratories; the project coordinator was Burt

Kaliski of RSA Laboratories. For Version 2.01, Ray Sidney served as document editor

and project coordinator. Matthew Wood of Intel was document editor and project

coordinator for Version 2.10 and Version 2.11. Simon McMahon from Eracom was

editor for Version 2.20 while Magnus Nystrom of RSA coordinated the project.

2 Scope

This standard specifies an application programming interface (API), called “Cryptoki,” to

devices which hold cryptographic information and perform cryptographic functions.

Cryptoki, pronounced “crypto-key” and short for “cryptographic token interface,”

follows a simple object-based approach, addressing the goals of technology

independence (any kind of device) and resource sharing (multiple applications accessing

multiple devices), presenting to applications a common, logical view of the device called

a “cryptographic token”.

This document specifies the data types and functions available to an application requiring

cryptographic services using the ANSI C programming language. These data types and

functions will typically be provided via C header files by the supplier of a Cryptoki

library. Generic ANSI C header files for Cryptoki are available from the PKCS Web

page. This document and up-to-date errata for Cryptoki will also be available from the

same place.

Additional documents may provide a generic, language-independent Cryptoki interface

and/or bindings between Cryptoki and other programming languages.

Cryptoki isolates an application from the details of the cryptographic device. The

application does not have to change to interface to a different type of device or to run in a

different environment; thus, the application is portable. How Cryptoki provides this

3. REFERENCES 3

isolation is beyond the scope of this document, although some conventions for the

support of multiple types of device will be addressed here and possibly in a separate

document.

A number of cryptographic mechanisms (algorithms) are supported in this version. In

addition, new mechanisms can be added later without changing the general interface. It

is possible that additional mechanisms will be published from time to time in separate

documents; it is also possible for token vendors to define their own mechanisms

(although, for the sake of interoperability, registration through the PKCS process is

preferable).

Cryptoki is intended for cryptographic devices associated with a single user, so some

features that might be included in a general-purpose interface are omitted. For example,

Cryptoki does not have a means of distinguishing multiple users. The focus is on a single

user’s keys and perhaps a small number of certificates related to them. Moreover, the

emphasis is on cryptography. While the device may perform useful non-cryptographic

functions, such functions are left to other interfaces.

3 References

ANSI C ANSI/ISO. American National Standard for Programming Languages

– C. 1990.

ANSI X9.31 Accredited Standards Committee X9. Digital Signatures Using

Reversible Public Key Cryptography for the Financial Services

Industry (rDSA). 1998.

ANSI X9.42 Accredited Standards Committee X9. Public Key Cryptography for

the Financial Services Industry: Agreement of Symmetric Keys Using

Discrete Logarithm Cryptography. 2003.

ANSI X9.62 Accredited Standards Committee X9. Public Key Cryptography for

the Financial Services Industry: The Elliptic Curve Digital Signature

Algorithm (ECDSA). 1998.

ANSI X9.63 Accredited Standards Committee X9. Public Key Cryptography for

the Financial Services Industry: Key Agreement and Key Transport

Using Elliptic Curve Cryptography. 2001.

CC/PP W3C. Composite Capability/Preference Profiles (CC/PP): Structure

and Vocabularies. World Wide Web Consortium, January 2004. URL:

http://www.w3.org/TR/CCPP-struct-vocab/

CDPD Ameritech Mobile Communications et al. Cellular Digital Packet

Data System Specifications: Part 406: Airlink Security. 1993.

FIPS PUB 46–3 NIST. FIPS 46-3: Data Encryption Standard (DES). October 25,

1999. URL: http://csrc.nist.gov/publications/fips/index.html

4 PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD

FIPS PUB 74 NIST. FIPS 74: Guidelines for Implementing and Using the NBS Data

Encryption Standard. April 1, 1981. URL:

http://csrc.nist.gov/publications/fips/index.html

FIPS PUB 81 NIST. FIPS 81: DES Modes of Operation. December 1980. URL:

http://csrc.nist.gov/publications/fips/index.html

FIPS PUB 113 NIST. FIPS 113: Computer Data Authentication. May 30, 1985.

URL: http://csrc.nist.gov/publications/fips/index.html

FIPS PUB 180-2 NIST. FIPS 180-2: Secure Hash Standard. August 1, 2002. URL:

http://csrc.nist.gov/publications/fips/index.html

FIPS PUB 186-2 NIST. FIPS 186-2: Digital Signature Standard. January 27, 2000.

URL: http://csrc.nist.gov/publications/fips/index.html

FIPS PUB 197 NIST. FIPS 197: Advanced Encryption Standard (AES). November

26, 2001. URL: http://csrc.nist.gov/publications/fips/index.html

FORTEZZA CIPG NSA, Workstation Security Products. FORTEZZA Cryptologic

Interface Programmers Guide, Revision 1.52. November 1995.

GCS-API X/Open Company Ltd. Generic Cryptographic Service API (GCS-

API), Base - Draft 2. February 14, 1995.

ISO/IEC 7816-1 ISO. Information Technology — Identification Cards — Integrated

Circuit(s) with Contacts — Part 1: Physical Characteristics. 1998.

ISO/IEC 7816-4 ISO. Information Technology — Identification Cards — Integrated

Circuit(s) with Contacts — Part 4: Interindustry Commands for

Interchange. 1995.

ISO/IEC 8824-1 ISO. Information Technology-- Abstract Syntax Notation One (ASN.1):

Specification of Basic Notation. 2002.

ISO/IEC 8825-1 ISO. Information Technology—ASN.1 Encoding Rules: Specification

of Basic Encoding Rules (BER), Canonical Encoding Rules (CER),

and Distinguished Encoding Rules (DER). 2002.

ISO/IEC 9594-1 ISO. Information Technology — Open Systems Interconnection — The

Directory: Overview of Concepts, Models and Services. 2001.

ISO/IEC 9594-8 ISO. Information Technology — Open Systems Interconnection — The

Directory: Public-key and Attribute Certificate Frameworks. 2001.

ISO/IEC 9796-2 ISO. Information Technology — Security Techniques — Digital

Signature Scheme Giving Message Recovery — Part 2: Integer

factorization based mechanisms. 2002.

Java MIDP Java Community Process. Mobile Information Device Profile for Java

2 Micro Edition. November 2002. URL:

http://jcp.org/jsr/detail/118.jsp

MeT-PTD MeT. MeT PTD Definition – Personal Trusted Device Definition,

Version 1.0, February 2003. URL: http://www.mobiletransaction.org

剩余406页未读，继续阅读

mikeiii

粉丝: 5
资源: 93

PKCS#11 v2.20：RSA加密令牌接口标准概览

PKCS #11 v2.20: Cryptographic Token Interface Standard 概览

PKCS#11v2.20密码学令牌接口标准

PKCS #11 v2.20：加密令牌接口标准草案

Header files for PKCS #11 v2.20

PKCS#11 v2.20：加密令牌接口标准详解

RSA PKCS #11 v2.20：加密令牌接口标准概览

pkcs_11v2.11-CH.pdf.zip_PKCS11 PDF_pkcs-11v2-20.pdf_pkcs11_pkcs_

pkcs-11v2-20fd

pkcs-11v2-20d3.rar_PKCS#1_PKCS#11 USBKey_RSA PKCS_pkcs_usbkey

如何理解PKCS#11标准在密码学中的作用，并且如何通过《pkcs#11 v2.20中文标准》来深入学习这一标准？

最新资源