当前位置:首页 >> 信息与通信 >>

pkcs-11v2-20


PKCS #11 v2.20: Cryptographic Token Interface Standard
RSA Laboratories 28 June 2004

Table of Contents
1 2 3 4 5 6 INTRODUCTION ............................................................................................................................ 1 SCOPE ............................................................................................................................................... 2 REFERENCES.................................................................................................................................. 3 DEFINITIONS .................................................................................................................................. 7 SYMBOLS AND ABBREVIATIONS........................................................................................... 10 GENERAL OVERVIEW ............................................................................................................... 12 6.1 6.2 6.3 6.4 6.5 6.6 6.6.1 6.6.2 6.7 6.7.1 6.7.2 6.7.3 6.7.4 6.7.5 6.7.6 6.7.7 6.8 6.9 7 8 INTRODUCTION......................................................................................................................... 12 DESIGN GOALS ......................................................................................................................... 13 GENERAL MODEL ..................................................................................................................... 13 LOGICAL VIEW OF A TOKEN ...................................................................................................... 15 USERS ...................................................................................................................................... 16 APPLICATIONS AND THEIR USE OF CRYPTOKI ........................................................................... 17 Applications and processes ................................................................................................ 17 Applications and threads .................................................................................................... 18 SESSIONS .................................................................................................................................. 19 Read-only session states ..................................................................................................... 19 Read/write session states .................................................................................................... 20 Permitted object accesses by sessions ................................................................................ 21 Session events ..................................................................................................................... 22 Session handles and object handles.................................................................................... 23 Capabilities of sessions ...................................................................................................... 23 Example of use of sessions.................................................................................................. 24 SECONDARY AUTHENTICATION (DEPRECATED)........................................................................ 26 FUNCTION OVERVIEW ............................................................................................................... 27

SECURITY CONSIDERATIONS ................................................................................................ 30 PLATFORM- AND COMPILER-DEPENDENT DIRECTIVES FOR C OR C++ ................. 31 8.1 8.2 STRUCTURE PACKING ............................................................................................................... 31 POINTER-RELATED MACROS ..................................................................................................... 32 CK_PTR .................................................................................................................................. 32 CK_DEFINE_FUNCTION...................................................................................................... 32 CK_DECLARE_FUNCTION .................................................................................................. 32 CK_DECLARE_FUNCTION_POINTER ................................................................................ 32

? ? ? ?

Copyright ? 1994-2004 RSA Security Inc. License to copy this document is granted provided that it is identified as “RSA Security Inc. Public-Key Cryptography Standards (PKCS)” in all material mentioning or referencing this document.

ii
? ?

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD
CK_CALLBACK_FUNCTION ................................................................................................ 33 NULL_PTR.............................................................................................................................. 33 8.3 SAMPLE PLATFORM- AND COMPILER-DEPENDENT CODE ........................................................... 33 8.3.1 Win32.................................................................................................................................. 33 8.3.2 Win16.................................................................................................................................. 34 8.3.3 Generic UNIX..................................................................................................................... 35

9

GENERAL DATA TYPES............................................................................................................. 36 9.1

9.2

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

9.3

9.4

9.5

9.6

9.7

GENERAL INFORMATION .......................................................................................................... 36 CK_VERSION; CK_VERSION_PTR ...................................................................................... 36 CK_INFO; CK_INFO_PTR .................................................................................................... 37 CK_NOTIFICATION .............................................................................................................. 38 SLOT AND TOKEN TYPES ........................................................................................................... 38 CK_SLOT_ID; CK_SLOT_ID_PTR........................................................................................ 38 CK_SLOT_INFO; CK_SLOT_INFO_PTR.............................................................................. 39 CK_TOKEN_INFO; CK_TOKEN_INFO_PTR....................................................................... 40 SESSION TYPES ......................................................................................................................... 46 CK_SESSION_HANDLE; CK_SESSION_HANDLE_PTR ..................................................... 46 CK_USER_TYPE .................................................................................................................... 46 CK_STATE .............................................................................................................................. 47 CK_SESSION_INFO; CK_SESSION_INFO_PTR.................................................................. 47 OBJECT TYPES .......................................................................................................................... 48 CK_OBJECT_HANDLE; CK_OBJECT_HANDLE_PTR ....................................................... 48 CK_OBJECT_CLASS; CK_OBJECT_CLASS_PTR ............................................................... 48 CK_HW_FEATURE_TYPE..................................................................................................... 49 CK_KEY_TYPE....................................................................................................................... 49 CK_CERTIFICATE_TYPE...................................................................................................... 50 CK_ATTRIBUTE_TYPE.......................................................................................................... 50 CK_ATTRIBUTE; CK_ATTRIBUTE_PTR.............................................................................. 51 CK_DATE................................................................................................................................ 51 DATA TYPES FOR MECHANISMS ................................................................................................ 52 CK_MECHANISM_TYPE; CK_MECHANISM_TYPE_PTR .................................................. 52 CK_MECHANISM; CK_MECHANISM_PTR......................................................................... 52 CK_MECHANISM_INFO; CK_MECHANISM_INFO_PTR .................................................. 53 FUNCTION TYPES ...................................................................................................................... 54 CK_RV..................................................................................................................................... 55 CK_NOTIFY............................................................................................................................ 55 CK_C_XXX.............................................................................................................................. 55 CK_FUNCTION_LIST; CK_FUNCTION_LIST_PTR; CK_FUNCTION_LIST_PTR_PTR... 56 LOCKING-RELATED TYPES ........................................................................................................ 58 CK_CREATEMUTEX.............................................................................................................. 58 CK_DESTROYMUTEX ........................................................................................................... 58 CK_LOCKMUTEX and CK_UNLOCKMUTEX ..................................................................... 58 CK_C_INITIALIZE_ARGS; CK_C_INITIALIZE_ARGS_PTR ............................................... 60

10

OBJECTS ........................................................................................................................................ 62 10.1 CREATING, MODIFYING, AND COPYING OBJECTS ...................................................................... 63 10.1.1 Creating objects............................................................................................................. 63 10.1.2 Modifying objects........................................................................................................... 65 10.1.3 Copying objects ............................................................................................................. 65 10.2 COMMON ATTRIBUTES.............................................................................................................. 66 10.3 HARDWARE FEATURE OBJECTS ................................................................................................ 67 10.3.1 Definitions...................................................................................................................... 67

Copyright ? 2004 RSA Security Inc.

June 2004

iii
Overview ........................................................................................................................ 67 10.3.2 10.3.3 Clock .............................................................................................................................. 67 10.3.4 Monotonic Counter Objects........................................................................................... 68 10.3.5 User Interface Objects ................................................................................................... 69 10.4 STORAGE OBJECTS ................................................................................................................... 71 10.5 DATA OBJECTS ......................................................................................................................... 72 10.5.1 Definitions...................................................................................................................... 72 10.5.2 Overview ........................................................................................................................ 72 10.6 CERTIFICATE OBJECTS .............................................................................................................. 73 10.6.1 Definitions...................................................................................................................... 73 10.6.2 Overview ........................................................................................................................ 73 10.6.3 X.509 public key certificate objects ............................................................................... 74 10.6.4 WTLS public key certificate objects ............................................................................... 76 10.6.5 X.509 attribute certificate objects.................................................................................. 78 10.7 KEY OBJECTS ........................................................................................................................... 79 10.7.1 Definitions...................................................................................................................... 79 10.7.2 Overview ........................................................................................................................ 79 10.8 PUBLIC KEY OBJECTS................................................................................................................ 81 10.9 PRIVATE KEY OBJECTS ............................................................................................................. 82 10.10 SECRET KEY OBJECTS ............................................................................................................... 84 10.11 DOMAIN PARAMETER OBJECTS ................................................................................................. 87 10.11.1 Definitions...................................................................................................................... 87 10.11.2 Overview ........................................................................................................................ 87 10.12 MECHANISM OBJECTS............................................................................................................... 88 10.12.1 Definitions...................................................................................................................... 88 10.12.2 Overview ........................................................................................................................ 88 11 FUNCTIONS................................................................................................................................... 89 11.1 FUNCTION RETURN VALUES...................................................................................................... 90 11.1.1 Universal Cryptoki function return values .................................................................... 90 11.1.2 Cryptoki function return values for functions that use a session handle ....................... 91 11.1.3 Cryptoki function return values for functions that use a token...................................... 92 11.1.4 Special return value for application-supplied callbacks ............................................... 92 11.1.5 Special return values for mutex-handling functions ...................................................... 93 11.1.6 All other Cryptoki function return values ...................................................................... 93 11.1.7 More on relative priorities of Cryptoki errors............................................................. 100 11.1.8 Error code “gotchas”.................................................................................................. 101 11.2 CONVENTIONS FOR FUNCTIONS RETURNING OUTPUT IN A VARIABLE-LENGTH BUFFER ........... 101 11.3 DISCLAIMER CONCERNING SAMPLE CODE............................................................................... 102 11.4 GENERAL-PURPOSE FUNCTIONS.............................................................................................. 102 ? C_Initialize ............................................................................................................................ 102 ? C_Finalize ............................................................................................................................. 104 ? C_GetInfo .............................................................................................................................. 105 ? C_GetFunctionList ................................................................................................................ 106 11.5 SLOT AND TOKEN MANAGEMENT FUNCTIONS ......................................................................... 106 ? C_GetSlotList ........................................................................................................................ 106 ? C_GetSlotInfo........................................................................................................................ 108 ? C_GetTokenInfo .................................................................................................................... 109 ? C_WaitForSlotEvent ............................................................................................................. 110 ? C_GetMechanismList ............................................................................................................ 111 ? C_GetMechanismInfo............................................................................................................ 112 ? C_InitToken........................................................................................................................... 113 ? C_InitPIN .............................................................................................................................. 115 ? C_SetPIN............................................................................................................................... 116

June 2004

Copyright ? 2004 RSA Security Inc.

iv
11.6

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD
SESSION MANAGEMENT FUNCTIONS ....................................................................................... 117 C_OpenSession...................................................................................................................... 117 C_CloseSession ..................................................................................................................... 118 C_CloseAllSessions ............................................................................................................... 120 C_GetSessionInfo .................................................................................................................. 120 C_GetOperationState ............................................................................................................ 121 C_SetOperationState ............................................................................................................. 123 C_Login................................................................................................................................. 125 C_Logout............................................................................................................................... 127 OBJECT MANAGEMENT FUNCTIONS ........................................................................................ 128 C_CreateObject..................................................................................................................... 128 C_CopyObject ....................................................................................................................... 130 C_DestroyObject................................................................................................................... 131 C_GetObjectSize ................................................................................................................... 132 C_GetAttributeValue ............................................................................................................. 133 C_SetAttributeValue.............................................................................................................. 135 C_FindObjectsInit................................................................................................................. 136 C_FindObjects ...................................................................................................................... 137 C_FindObjectsFinal.............................................................................................................. 138 ENCRYPTION FUNCTIONS ........................................................................................................ 139 C_EncryptInit ........................................................................................................................ 139 C_Encrypt.............................................................................................................................. 140 C_EncryptUpdate.................................................................................................................. 141 C_EncryptFinal..................................................................................................................... 141 DECRYPTION FUNCTIONS........................................................................................................ 144 C_DecryptInit........................................................................................................................ 144 C_Decrypt ............................................................................................................................. 145 C_DecryptUpdate.................................................................................................................. 146 C_DecryptFinal..................................................................................................................... 146 MESSAGE DIGESTING FUNCTIONS ........................................................................................... 148 C_DigestInit .......................................................................................................................... 148 C_Digest................................................................................................................................ 149 C_DigestUpdate .................................................................................................................... 150 C_DigestKey.......................................................................................................................... 150 C_DigestFinal ....................................................................................................................... 151 SIGNING AND MACING FUNCTIONS ........................................................................................ 152 C_SignInit ............................................................................................................................. 152 C_Sign ................................................................................................................................... 153 C_SignUpdate ....................................................................................................................... 154 C_SignFinal .......................................................................................................................... 154 C_SignRecoverInit ................................................................................................................ 155 C_SignRecover ...................................................................................................................... 156 FUNCTIONS FOR VERIFYING SIGNATURES AND MACS ............................................................ 157 C_VerifyInit........................................................................................................................... 157 C_Verify ................................................................................................................................ 158 C_VerifyUpdate..................................................................................................................... 159 C_VerifyFinal........................................................................................................................ 159 C_VerifyRecoverInit.............................................................................................................. 161 C_VerifyRecover ................................................................................................................... 161 DUAL-FUNCTION CRYPTOGRAPHIC FUNCTIONS ...................................................................... 163 C_DigestEncryptUpdate ....................................................................................................... 163 C_DecryptDigestUpdate ....................................................................................................... 165

11.7

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

11.8

11.9

11.10

11.11

11.12

11.13

Copyright ? 2004 RSA Security Inc.

June 2004

v
C_SignEncryptUpdate........................................................................................................... 169 C_DecryptVerifyUpdate........................................................................................................ 171 11.14 KEY MANAGEMENT FUNCTIONS ............................................................................................. 174 ? C_GenerateKey ..................................................................................................................... 175 ? C_GenerateKeyPair .............................................................................................................. 176 ? C_WrapKey ........................................................................................................................... 178 ? C_UnwrapKey....................................................................................................................... 180 ? C_DeriveKey ......................................................................................................................... 182 11.15 RANDOM NUMBER GENERATION FUNCTIONS .......................................................................... 184 ? C_SeedRandom ..................................................................................................................... 184 ? C_GenerateRandom .............................................................................................................. 184 11.16 PARALLEL FUNCTION MANAGEMENT FUNCTIONS ................................................................... 185 ? C_GetFunctionStatus ............................................................................................................ 185 ? C_CancelFunction ................................................................................................................ 186 11.17 CALLBACK FUNCTIONS........................................................................................................... 186 11.17.1 Surrender callbacks ..................................................................................................... 186 11.17.2 Vendor-defined callbacks ............................................................................................ 187 12 MECHANISMS ............................................................................................................................ 188 12.1 RSA ....................................................................................................................................... 193 12.1.1 Definitions.................................................................................................................... 193 12.1.2 RSA public key objects................................................................................................. 193 12.1.3 RSA private key objects................................................................................................ 194 12.1.4 PKCS #1 RSA key pair generation .............................................................................. 196 12.1.5 X9.31 RSA key pair generation.................................................................................... 197 12.1.6 PKCS #1 v1.5 RSA....................................................................................................... 197 12.1.7 PKCS #1 RSA OAEP mechanism parameters ............................................................. 198 ? CK_RSA_PKCS_MGF_TYPE; CK_RSA_PKCS_MGF_TYPE_PTR.................................... 198 ? CK_RSA_PKCS_OAEP_SOURCE_TYPE; CK_RSA_PKCS_OAEP_SOURCE_TYPE_PTR199 ? CK_RSA_PKCS_OAEP_PARAMS; CK_RSA_PKCS_OAEP_PARAMS_PTR ..................... 200 12.1.8 PKCS #1 RSA OAEP ................................................................................................... 200 12.1.9 PKCS #1 RSA PSS mechanism parameters ................................................................. 201 ? CK_RSA_PKCS_PSS_PARAMS; CK_RSA_PKCS_PSS_PARAMS_PTR............................. 201 12.1.10 PKCS #1 RSA PSS ....................................................................................................... 202 12.1.11 ISO/IEC 9796 RSA....................................................................................................... 203 12.1.12 X.509 (raw) RSA .......................................................................................................... 203 12.1.13 ANSI X9.31 RSA........................................................................................................... 205 12.1.14 PKCS #1 v1.5 RSA signature with MD2, MD5, SHA-1, SHA-256, SHA-384, SHA-512, RIPE-MD 128 or RIPE-MD 160 .................................................................................................... 206 12.1.15 PKCS #1 RSA PSS signature with SHA-1, SHA-256, SHA-384 or SHA-512 .............. 207 12.1.16 ANSI X9.31 RSA signature with SHA-1 ....................................................................... 208 12.2 DSA....................................................................................................................................... 209 12.2.1 Definitions.................................................................................................................... 209 12.2.2 DSA public key objects ................................................................................................ 209 12.2.3 DSA private key objects ............................................................................................... 210 12.2.4 DSA domain parameter objects ................................................................................... 211 12.2.5 DSA key pair generation.............................................................................................. 212 12.2.6 DSA domain parameter generation ............................................................................. 212 12.2.7 DSA without hashing ................................................................................................... 213 12.2.8 DSA with SHA-1 .......................................................................................................... 213 12.2.9 FORTEZZA timestamp................................................................................................. 214 12.3 ELLIPTIC CURVE..................................................................................................................... 214 12.3.1 EC Signatures .............................................................................................................. 216 12.3.2 Definitions.................................................................................................................... 216

? ?

June 2004

Copyright ? 2004 RSA Security Inc.

vi

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD
ECDSA public key objects ........................................................................................... 217 12.3.3 12.3.4 Elliptic curve private key objects ................................................................................. 218 12.3.5 Elliptic curve key pair generation................................................................................ 219 12.3.6 ECDSA without hashing .............................................................................................. 220 12.3.7 ECDSA with SHA-1 ..................................................................................................... 220 12.3.8 EC mechanism parameters .......................................................................................... 221 12.3.9 Elliptic curve Diffie-Hellman key derivation ............................................................... 224 12.3.10 Elliptic curve Diffie-Hellman with cofactor key derivation ......................................... 224 12.3.11 Elliptic curve Menezes-Qu-Vanstone key derivation ................................................... 225 12.4 DIFFIE-HELLMAN ................................................................................................................... 226 12.4.1 Definitions.................................................................................................................... 226 12.4.2 Diffie-Hellman public key objects................................................................................ 227 12.4.3 X9.42 Diffie-Hellman public key objects ..................................................................... 228 12.4.4 Diffie-Hellman private key objects .............................................................................. 229 12.4.5 X9.42 Diffie-Hellman private key objects .................................................................... 230 12.4.6 Diffie-Hellman domain parameter objects .................................................................. 231 12.4.7 X9.42 Diffie-Hellman domain parameters objects ...................................................... 232 12.4.8 PKCS #3 Diffie-Hellman key pair generation ............................................................. 233 12.4.9 PKCS #3 Diffie-Hellman domain parameter generation............................................. 233 12.4.10 PKCS #3 Diffie-Hellman key derivation...................................................................... 234 12.4.11 X9.42 Diffie-Hellman mechanism parameters............................................................. 235 ? CK_X9_42_DH1_DERIVE_PARAMS, CK_X9_42_DH1_DERIVE_PARAMS_PTR........... 235 ? CK_X9_42_DH2_DERIVE_PARAMS, CK_X9_42_DH2_DERIVE_PARAMS_PTR........... 236 ? CK_X9_42_MQV_DERIVE_PARAMS, CK_X9_42_MQV_DERIVE_PARAMS_PTR ......... 238 12.4.12 X9.42 Diffie-Hellman key pair generation................................................................... 239 12.4.13 X9.42 Diffie-Hellman domain parameter generation.................................................. 239 12.4.14 X9.42 Diffie-Hellman key derivation ........................................................................... 240 12.4.15 X9.42 Diffie-Hellman hybrid key derivation................................................................ 241 12.4.16 X9.42 Diffie-Hellman Menezes-Qu-Vanstone key derivation ...................................... 242 12.5 KEA....................................................................................................................................... 243 12.5.1 Definitions.................................................................................................................... 243 12.5.2 KEA mechanism parameters........................................................................................ 243 ? CK_KEA_DERIVE_PARAMS; CK_KEA_DERIVE_PARAMS_PTR.................................... 243 12.5.3 KEA public key objects ................................................................................................ 244 12.5.4 KEA private key objects ............................................................................................... 244 12.5.5 KEA key pair generation.............................................................................................. 246 12.5.6 KEA key derivation ...................................................................................................... 246 12.6 WRAPPING/UNWRAPPING PRIVATE KEYS ................................................................................ 248 12.7 GENERIC SECRET KEY............................................................................................................. 251 12.7.1 Definitions.................................................................................................................... 251 12.7.2 Generic secret key objects ........................................................................................... 251 12.7.3 Generic secret key generation ..................................................................................... 252 12.8 HMAC MECHANISMS ............................................................................................................. 252 12.9 RC2 ....................................................................................................................................... 253 12.9.1 Definitions.................................................................................................................... 253 12.9.2 RC2 secret key objects ................................................................................................. 253 12.9.3 RC2 mechanism parameters ........................................................................................ 254 ? CK_RC2_PARAMS; CK_RC2_PARAMS_PTR..................................................................... 254 ? CK_RC2_CBC_PARAMS; CK_RC2_CBC_PARAMS_PTR ................................................. 254 ? CK_RC2_MAC_GENERAL_PARAMS; CK_RC2_MAC_GENERAL_PARAMS_PTR ......... 255 12.9.4 RC2 key generation...................................................................................................... 255 12.9.5 RC2-ECB ..................................................................................................................... 255 12.9.6 RC2-CBC ..................................................................................................................... 256 12.9.7 RC2-CBC with PKCS padding .................................................................................... 257

Copyright ? 2004 RSA Security Inc.

June 2004

vii
General-length RC2-MAC ........................................................................................... 258 12.9.8 12.9.9 RC2-MAC .................................................................................................................... 259 12.10 RC4 ....................................................................................................................................... 259 12.10.1 Definitions.................................................................................................................... 259 12.10.2 RC4 secret key objects ................................................................................................. 260 12.10.3 RC4 key generation...................................................................................................... 260 12.10.4 RC4 mechanism ........................................................................................................... 261 12.11 RC5 ....................................................................................................................................... 261 12.11.1 Definitions.................................................................................................................... 261 12.11.2 RC5 secret key objects ................................................................................................. 262 12.11.3 RC5 mechanism parameters ........................................................................................ 262 ? CK_RC5_PARAMS; CK_RC5_PARAMS_PTR..................................................................... 262 ? CK_RC5_CBC_PARAMS; CK_RC5_CBC_PARAMS_PTR ................................................. 263 ? CK_RC5_MAC_GENERAL_PARAMS; CK_RC5_MAC_GENERAL_PARAMS_PTR ......... 263 12.11.4 RC5 key generation...................................................................................................... 264 12.11.5 RC5-ECB ..................................................................................................................... 264 12.11.6 RC5-CBC ..................................................................................................................... 265 12.11.7 RC5-CBC with PKCS padding .................................................................................... 266 12.11.8 General-length RC5-MAC ........................................................................................... 267 12.11.9 RC5-MAC .................................................................................................................... 268 12.12 AES ....................................................................................................................................... 268 12.12.1 Definitions.................................................................................................................... 268 12.12.2 AES secret key objects ................................................................................................. 268 12.12.3 AES key generation...................................................................................................... 269 12.12.4 AES-ECB...................................................................................................................... 270 12.12.5 AES-CBC ..................................................................................................................... 271 12.12.6 AES-CBC with PKCS padding..................................................................................... 272 12.12.7 General-length AES-MAC ........................................................................................... 272 12.12.8 AES-MAC..................................................................................................................... 273 12.13 GENERAL BLOCK CIPHER ........................................................................................................ 274 12.13.1 Definitions.................................................................................................................... 274 12.13.2 DES secret key objects................................................................................................. 275 12.13.3 CAST secret key objects ............................................................................................... 276 12.13.4 CAST3 secret key objects ............................................................................................. 277 12.13.5 CAST128 (CAST5) secret key objects .......................................................................... 277 12.13.6 IDEA secret key objects ............................................................................................... 278 12.13.7 CDMF secret key objects ............................................................................................. 278 12.13.8 General block cipher mechanism parameters ............................................................. 279 ? CK_MAC_GENERAL_PARAMS; CK_MAC_GENERAL_PARAMS_PTR ........................... 279 12.13.9 General block cipher key generation........................................................................... 280 12.13.10 General block cipher ECB........................................................................................... 280 12.13.11 General block cipher CBC........................................................................................... 281 12.13.12 General block cipher CBC with PKCS padding .......................................................... 282 12.13.13 General-length general block cipher MAC.................................................................. 283 12.13.14 General block cipher MAC .......................................................................................... 284 12.14 KEY DERIVATION BY DATA ENCRYPTION – DES & AES........................................................ 284 12.14.1 Definitions.................................................................................................................... 285 12.14.2 Mechanism Parameters ............................................................................................... 285 12.14.3 Mechanism Description ............................................................................................... 286 12.15 DOUBLE AND TRIPLE-LENGTH DES ....................................................................................... 286 12.15.1 Definitions.................................................................................................................... 286 12.15.2 DES2 secret key objects............................................................................................... 287 12.15.3 DES3 secret key objects............................................................................................... 288 12.15.4 Double-length DES key generation ............................................................................. 288 12.15.5 Triple-length DES Order of Operations ...................................................................... 289

June 2004

Copyright ? 2004 RSA Security Inc.

viii

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD

Triple-length DES in CBC Mode ................................................................................. 289 12.15.6 12.15.7 DES and Triple length DES in OFB Mode .................................................................. 290 12.15.8 DES and Triple length DES in CFB Mode .................................................................. 290 12.16 SKIPJACK ............................................................................................................................ 291 12.16.1 Definitions.................................................................................................................... 291 12.16.2 SKIPJACK secret key objects ...................................................................................... 292 12.16.3 SKIPJACK Mechanism parameters............................................................................. 293 ? CK_SKIPJACK_PRIVATE_WRAP_PARAMS; CK_SKIPJACK_PRIVATE_WRAP_PARAMS_PTR....................................................................... 293 ? CK_SKIPJACK_RELAYX_PARAMS; CK_SKIPJACK_RELAYX_PARAMS_PTR............... 294 12.16.4 SKIPJACK key generation........................................................................................... 295 12.16.5 SKIPJACK-ECB64....................................................................................................... 295 12.16.6 SKIPJACK-CBC64 ...................................................................................................... 296 12.16.7 SKIPJACK-OFB64 ...................................................................................................... 296 12.16.8 SKIPJACK-CFB64....................................................................................................... 297 12.16.9 SKIPJACK-CFB32....................................................................................................... 297 12.16.10 SKIPJACK-CFB16....................................................................................................... 298 12.16.11 SKIPJACK-CFB8......................................................................................................... 298 12.16.12 SKIPJACK-WRAP ....................................................................................................... 299 12.16.13 SKIPJACK-PRIVATE-WRAP ...................................................................................... 299 12.16.14 SKIPJACK-RELAYX.................................................................................................... 299 12.17 BATON ................................................................................................................................. 299 12.17.1 Definitions.................................................................................................................... 299 12.17.2 BATON secret key objects............................................................................................ 300 12.17.3 BATON key generation ................................................................................................ 301 12.17.4 BATON-ECB128.......................................................................................................... 301 12.17.5 BATON-ECB96............................................................................................................ 302 12.17.6 BATON-CBC128.......................................................................................................... 302 12.17.7 BATON-COUNTER ..................................................................................................... 303 12.17.8 BATON-SHUFFLE ...................................................................................................... 303 12.17.9 BATON WRAP ............................................................................................................. 304 12.18 JUNIPER............................................................................................................................... 304 12.18.1 Definitions.................................................................................................................... 304 12.18.2 JUNIPER secret key objects ........................................................................................ 304 12.18.3 JUNIPER key generation............................................................................................. 305 12.18.4 JUNIPER-ECB128 ...................................................................................................... 306 12.18.5 JUNIPER-CBC128 ...................................................................................................... 306 12.18.6 JUNIPER-COUNTER.................................................................................................. 307 12.18.7 JUNIPER-SHUFFLE................................................................................................... 307 12.18.8 JUNIPER WRAP.......................................................................................................... 308 12.19 MD2 ...................................................................................................................................... 308 12.19.1 Definitions.................................................................................................................... 308 12.19.2 MD2 digest................................................................................................................... 308 12.19.3 General-length MD2-HMAC ....................................................................................... 308 12.19.4 MD2-HMAC ................................................................................................................ 309 12.19.5 MD2 key derivation ..................................................................................................... 309 12.20 MD5 ...................................................................................................................................... 310 12.20.1 Definitions.................................................................................................................... 310 12.20.2 MD5 digest................................................................................................................... 310 12.20.3 General-length MD5-HMAC ....................................................................................... 311 12.20.4 MD5-HMAC ................................................................................................................ 311 12.20.5 MD5 key derivation ..................................................................................................... 311 12.21 SHA-1 ................................................................................................................................... 312 12.21.1 Definitions.................................................................................................................... 312 12.21.2 SHA-1 digest ................................................................................................................ 313

Copyright ? 2004 RSA Security Inc.

June 2004

ix
General-length SHA-1-HMAC..................................................................................... 313 12.21.3 12.21.4 SHA-1-HMAC .............................................................................................................. 313 12.21.5 SHA-1 key derivation ................................................................................................... 314 12.22 SHA-256 ............................................................................................................................... 315 12.22.1 Definitions.................................................................................................................... 315 12.22.2 SHA-256 digest ............................................................................................................ 315 12.22.3 General-length SHA-256-HMAC................................................................................. 315 12.22.4 SHA-256-HMAC .......................................................................................................... 316 12.22.5 SHA-256 key derivation ............................................................................................... 316 12.23 SHA-384 ............................................................................................................................... 316 12.23.1 Definitions.................................................................................................................... 316 12.23.2 SHA-384 digest ............................................................................................................ 316 12.23.3 General-length SHA-384-HMAC................................................................................. 317 12.23.4 SHA-384-HMAC .......................................................................................................... 317 12.23.5 SHA-384 key derivation ............................................................................................... 317 12.24 SHA-512 ............................................................................................................................... 317 12.24.1 Definitions.................................................................................................................... 317 12.24.2 SHA-512 digest ............................................................................................................ 317 12.24.3 General-length SHA-512-HMAC................................................................................. 318 12.24.4 SHA-512-HMAC .......................................................................................................... 318 12.24.5 SHA-512 key derivation ............................................................................................... 318 12.25 FASTHASH .......................................................................................................................... 318 12.25.1 Definitions.................................................................................................................... 318 12.25.2 FASTHASH digest ....................................................................................................... 318 12.26 PKCS #5 AND PKCS #5-STYLE PASSWORD-BASED ENCRYPTION (PBE)................................ 319 12.26.1 Definitions.................................................................................................................... 319 12.26.2 Password-based encryption/authentication mechanism parameters........................... 320 ? CK_PBE_PARAMS; CK_PBE_PARAMS_PTR .................................................................... 320 12.26.3 MD2-PBE for DES-CBC ............................................................................................. 320 12.26.4 MD5-PBE for DES-CBC ............................................................................................. 321 12.26.5 MD5-PBE for CAST-CBC ........................................................................................... 321 12.26.6 MD5-PBE for CAST3-CBC ......................................................................................... 321 12.26.7 MD5-PBE for CAST128-CBC (CAST5-CBC).............................................................. 321 12.26.8 SHA-1-PBE for CAST128-CBC (CAST5-CBC) ........................................................... 322 12.26.9 PKCS #5 PBKDF2 key generation mechanism parameters ........................................ 322 ? CK_PKCS5_PBKD2_PSEUDO_RANDOM_FUNCTION_TYPE; CK_PKCS5_PBKD2_PSEUDO_RANDOM_FUNCTION_TYPE_PTR......................................... 322 ? CK_PKCS5_PBKDF2_SALT_SOURCE_TYPE; CK_PKCS5_PBKDF2_SALT_SOURCE_TYPE_PTR .................................................................... 323 ? CK_ PKCS5_PBKD2_PARAMS; CK_PKCS5_PBKD2_PARAMS_PTR.............................. 323 12.26.10 PKCS #5 PBKD2 key generation................................................................................. 324 12.27 PKCS #12 PASSWORD-BASED ENCRYPTION/AUTHENTICATION MECHANISMS ........................ 324 12.27.1 SHA-1-PBE for 128-bit RC4........................................................................................ 326 12.27.2 SHA-1-PBE for 40-bit RC4.......................................................................................... 326 12.27.3 SHA-1-PBE for 3-key triple-DES-CBC ....................................................................... 326 12.27.4 SHA-1-PBE for 2-key triple-DES-CBC ....................................................................... 327 12.27.5 SHA-1-PBE for 128-bit RC2-CBC............................................................................... 327 12.27.6 SHA-1-PBE for 40-bit RC2-CBC................................................................................. 328 12.27.7 SHA-1-PBA for SHA-1-HMAC .................................................................................... 328 12.28 RIPE-MD .............................................................................................................................. 329 12.28.1 Definitions.................................................................................................................... 329 12.28.2 RIPE-MD 128 digest.................................................................................................... 329 12.28.3 General-length RIPE-MD 128-HMAC ........................................................................ 329 12.28.4 RIPE-MD 128-HMAC ................................................................................................. 330 12.28.5 RIPE-MD 160 .............................................................................................................. 330

June 2004

Copyright ? 2004 RSA Security Inc.

x

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD
General-length RIPE-MD 160-HMAC ........................................................................ 330 12.28.6 12.28.7 RIPE-MD 160-HMAC ................................................................................................. 331 12.29 SET........................................................................................................................................ 331 12.29.1 Definitions.................................................................................................................... 331 12.29.2 SET mechanism parameters......................................................................................... 331 ? CK_KEY_WRAP_SET_OAEP_PARAMS; CK_KEY_WRAP_SET_OAEP_PARAMS_PTR . 331 12.29.3 OAEP key wrapping for SET ....................................................................................... 332 12.30 LYNKS ................................................................................................................................. 332 12.30.1 Definitions.................................................................................................................... 332 12.30.2 LYNKS key wrapping ................................................................................................... 333 12.31 SSL........................................................................................................................................ 333 12.31.1 Definitions.................................................................................................................... 333 12.31.2 SSL mechanism parameters ......................................................................................... 334 ? CK_SSL3_RANDOM_DATA................................................................................................. 334 ? CK_SSL3_MASTER_KEY_DERIVE_PARAMS; CK_SSL3_MASTER_KEY_DERIVE_PARAMS_PTR..................................................................... 334 ? CK_SSL3_KEY_MAT_OUT; CK_SSL3_KEY_MAT_OUT_PTR .......................................... 335 ? CK_SSL3_KEY_MAT_PARAMS; CK_SSL3_KEY_MAT_PARAMS_PTR............................ 335 12.31.3 Pre_master key generation .......................................................................................... 336 12.31.4 Master key derivation .................................................................................................. 337 12.31.5 Master key derivation for Diffie-Hellman.................................................................... 338 12.31.6 Key and MAC derivation ............................................................................................. 339 12.31.7 MD5 MACing in SSL 3.0 ............................................................................................. 340 12.31.8 SHA-1 MACing in SSL 3.0........................................................................................... 341 12.32 TLS........................................................................................................................................ 341 12.32.1 Definitions.................................................................................................................... 341 12.32.2 TLS mechanism parameters......................................................................................... 342 ? CK_TLS_PRF_PARAMS; CK_TLS_PRF_PARAMS_PTR ................................................... 342 12.32.3 TLS PRF (pseudorandom function) ............................................................................. 342 12.32.4 Pre_master key generation .......................................................................................... 343 12.32.5 Master key derivation .................................................................................................. 343 12.32.6 Master key derivation for Diffie-Hellman.................................................................... 344 12.32.7 Key and MAC derivation ............................................................................................. 345 12.33 WTLS.................................................................................................................................... 347 12.33.1 Definitions.................................................................................................................... 347 12.33.2 WTLS mechanism parameters ..................................................................................... 347 ? CK_WTLS_RANDOM_DATA; CK_WTLS_RANDOM_DATA_PTR .................................... 347 ? CK_WTLS_MASTER_KEY_DERIVE_PARAMS; CK_WTLS_MASTER_KEY_DERIVE_PARAMS _PTR .................................................................. 348 ? CK_WTLS_PRF_PARAMS; CK_WTLS_PRF_PARAMS_PTR............................................. 348 ? CK_WTLS_KEY_MAT_OUT; CK_WTLS_KEY_MAT_OUT_PTR....................................... 349 ? CK_WTLS_KEY_MAT_PARAMS; CK_WTLS_KEY_MAT_PARAMS_PTR......................... 350 12.33.3 Pre master secret key generation for RSA key exchange suite .................................... 351 12.33.4 Master secret key derivation........................................................................................ 351 12.33.5 Master secret key derivation for Diffie-Hellman and Elliptic Curve Cryptography ... 352 12.33.6 WTLS PRF (pseudorandom function).......................................................................... 353 12.33.7 Server Key and MAC derivation .................................................................................. 354 12.33.8 Client key and MAC derivation.................................................................................... 355 12.34 MISCELLANEOUS SIMPLE KEY DERIVATION MECHANISMS ...................................................... 356 12.34.1 Definitions.................................................................................................................... 356 12.34.2 Parameters for miscellaneous simple key derivation mechanisms .............................. 357 ? CK_KEY_DERIVATION_STRING_DATA; CK_KEY_DERIVATION_STRING_DATA_PTR357 ? CK_EXTRACT_PARAMS; CK_EXTRACT_PARAMS_PTR ................................................. 357 12.34.3 Concatenation of a base key and another key ............................................................. 357

Copyright ? 2004 RSA Security Inc.

June 2004

xi
Concatenation of a base key and data ......................................................................... 359 12.34.4 12.34.5 Concatenation of data and a base key ......................................................................... 360 12.34.6 XORing of a key and data ............................................................................................ 361 12.34.7 Extraction of one key from another key ....................................................................... 362 12.35 CMS ...................................................................................................................................... 364 12.35.1 Definitions.................................................................................................................... 364 12.35.2 CMS Signature Mechanism Objects ............................................................................ 364 12.35.3 CMS mechanism parameters ....................................................................................... 365 ? CK_CMS_SIG_PARAMS, CK_CMS_SIG_PARAMS_PTR................................................... 365 12.35.4 CMS signatures............................................................................................................ 366 12.36 BLOWFISH .............................................................................................................................. 367 12.36.1 Definitions.................................................................................................................... 368 12.36.2 BLOWFISH secret key objects..................................................................................... 368 12.36.3 Blowfish key generation............................................................................................... 369 12.36.4 Blowfish -CBC ............................................................................................................. 369 12.37 TWOFISH ................................................................................................................................ 369 12.37.1 Definitions.................................................................................................................... 370 12.37.2 Twofish secret key objects............................................................................................ 370 12.37.3 Twofish key generation ................................................................................................ 370 12.37.4 Twofish -CBC............................................................................................................... 371 13 CRYPTOKI TIPS AND REMINDERS ...................................................................................... 371 13.1 13.2 13.3 13.4 A B OPERATIONS, SESSIONS, AND THREADS .................................................................................. 371 MULTIPLE APPLICATION ACCESS BEHAVIOR ......................................................................... 372 OBJECTS, ATTRIBUTES, AND TEMPLATES................................................................................ 372 SIGNING WITH RECOVERY ...................................................................................................... 373

MANIFEST CONSTANTS .......................................................................................................... 375 TOKEN PROFILES ..................................................................................................................... 382 B.1 B.2 B.3 GOVERNMENT AUTHENTICATION-ONLY ................................................................................. 383 CELLULAR DIGITAL PACKET DATA ........................................................................................ 383 OTHER PROFILES .................................................................................................................... 384 FORTEZZA CIPG, REV. 1.52 .............................................................................................. 385 GCS-API ............................................................................................................................... 387

C

COMPARISON OF CRYPTOKI AND OTHER APIS............................................................. 385 C.1 C.2

D

INTELLECTUAL PROPERTY CONSIDERATIONS............................................................. 389

E METHOD FOR EXPOSING MULTIPLE-PINS ON A TOKEN THROUGH CRYPTOKI (DEPRECATED).................................................................................................................................... 390 F REVISION HISTORY ................................................................................................................. 391

List of Figures
FIGURE 1, GENERAL CRYPTOKI MODEL..............................................................................14 FIGURE 2, OBJECT HIERARCHY ...........................................................................................15 FIGURE 3, READ-ONLY SESSION STATES ............................................................................20 FIGURE 4, READ/WRITE SESSION STATES ...........................................................................21 FIGURE 5, OBJECT ATTRIBUTE HIERARCHY ........................................................................62

List of Tables
June 2004 Copyright ? 2004 RSA Security Inc.

xii

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD

TABLE 1, SYMBOLS.............................................................................................................10 TABLE 2, PREFIXES .............................................................................................................10 TABLE 3, CHARACTER SET .................................................................................................12 TABLE 4, READ-ONLY SESSION STATES .............................................................................20 TABLE 5, READ/WRITE SESSION STATES ............................................................................21 TABLE 6, ACCESS TO DIFFERENT TYPES OBJECTS BY DIFFERENT TYPES OF SESSIONS .......22 TABLE 7, SESSION EVENTS .................................................................................................22 TABLE 8, SUMMARY OF CRYPTOKI FUNCTIONS ..................................................................27 TABLE 9, MAJOR AND MINOR VERSION VALUES FOR PUBLISHED CRYPTOKI SPECIFICATIONS37 TABLE 10, SLOT INFORMATION FLAGS ...............................................................................39 TABLE 11, TOKEN INFORMATION FLAGS ............................................................................42 TABLE 12, SESSION INFORMATION FLAGS ..........................................................................48 TABLE 13, MECHANISM INFORMATION FLAGS ...................................................................54 TABLE 14, C_INITIALIZE PARAMETER FLAGS .....................................................................61 TABLE 15, COMMON FOOTNOTES FOR OBJECT ATTRIBUTE TABLES .....................................66 TABLE 16, COMMON OBJECT ATTRIBUTES .........................................................................67 TABLE 17, HARDWARE FEATURE COMMON ATTRIBUTES ...................................................67 TABLE 18, CLOCK OBJECT ATTRIBUTES .............................................................................68 TABLE 19, MONOTONIC COUNTER ATTRIBUTES .................................................................69 TABLE 20, USER INTERFACE OBJECT ATTRIBUTES .............................................................70 TABLE 21, COMMON STORAGE OBJECT ATTRIBUTES .........................................................71 TABLE 22, DATA OBJECT ATTRIBUTES ...............................................................................72 TABLE 23, COMMON CERTIFICATE OBJECT ATTRIBUTES....................................................73 TABLE 24, X.509 CERTIFICATE OBJECT ATTRIBUTES.........................................................75 TABLE 25: WTLS CERTIFICATE OBJECT ATTRIBUTES........................................................77 TABLE 26, X.509 ATTRIBUTE CERTIFICATE OBJECT ATTRIBUTES ......................................78 TABLE 27, COMMON KEY ATTRIBUTES ..............................................................................79 TABLE 28, COMMON PUBLIC KEY ATTRIBUTES ..................................................................81 TABLE 29, MAPPING OF X.509 KEY USAGE FLAGS TO CRYPTOKI ATTRIBUTES FOR PUBLIC KEYS.............................................................................................................................82 TABLE 30, COMMON PRIVATE KEY ATTRIBUTES ................................................................82 TABLE 31, COMMON SECRET KEY ATTRIBUTES .................................................................85 TABLE 32, COMMON DOMAIN PARAMETER ATTRIBUTES ...................................................88 TABLE 33, COMMON MECHANISM ATTRIBUTES .................................................................88 TABLE 34, MECHANISMS VS. FUNCTIONS .........................................................................188 TABLE 35, RSA PUBLIC KEY OBJECT ATTRIBUTES ..........................................................193 TABLE 36, RSA PRIVATE KEY OBJECT ATTRIBUTES ........................................................194 TABLE 37, PKCS #1 V1.5 RSA: KEY AND DATA LENGTH ..............................................198 TABLE 38, PKCS #1 MASK GENERATION FUNCTIONS .....................................................199 TABLE 39, PKCS #1 RSA OAEP: ENCODING PARAMETER SOURCES ...............................199 TABLE 40, PKCS #1 RSA OAEP: KEY AND DATA LENGTH ...........................................201 TABLE 41, PKCS #1 RSA PSS: KEY AND DATA LENGTH ...............................................202 TABLE 42, ISO/IEC 9796 RSA: KEY AND DATA LENGTH ...............................................203 TABLE 43, X.509 (RAW) RSA: KEY AND DATA LENGTH ................................................205 TABLE 44, ANSI X9.31 RSA: KEY AND DATA LENGTH .................................................206

Copyright ? 2004 RSA Security Inc.

June 2004

xiii TABLE 45, PKCS #1 V1.5 RSA SIGNATURES WITH VARIOUS HASH FUNCTIONS: KEY AND DATA LENGTH............................................................................................................207 TABLE 46, PKCS #1 RSA PSS SIGNATURES WITH VARIOUS HASH FUNCTIONS: KEY AND DATA LENGTH............................................................................................................208 TABLE 47, ANSI X9.31 RSA SIGNATURES WITH SHA-1: KEY AND DATA LENGTH .......208 TABLE 48, DSA PUBLIC KEY OBJECT ATTRIBUTES ..........................................................209 TABLE 49, DSA PRIVATE KEY OBJECT ATTRIBUTES........................................................210 TABLE 50, DSA DOMAIN PARAMETER OBJECT ATTRIBUTES ...........................................211 TABLE 51, DSA: KEY AND DATA LENGTH ......................................................................213 TABLE 52, DSA WITH SHA-1: KEY AND DATA LENGTH .................................................214 TABLE 53, FORTEZZA TIMESTAMP: KEY AND DATA LENGTH ......................................214 TABLE 54, MECHANISM INFORMATION FLAGS .................................................................214 TABLE 55, ELLIPTIC CURVE PUBLIC KEY OBJECT ATTRIBUTES........................................217 TABLE 56, ELLIPTIC CURVE PRIVATE KEY OBJECT ATTRIBUTES .....................................218 TABLE 57, ECDSA: KEY AND DATA LENGTH .................................................................220 TABLE 58, ECDSA WITH SHA-1: KEY AND DATA LENGTH ............................................221 TABLE 59, EC: KEY DERIVATION FUNCTIONS ..................................................................221 TABLE 60, DIFFIE-HELLMAN PUBLIC KEY OBJECT ATTRIBUTES ......................................227 TABLE 61, X9.42 DIFFIE-HELLMAN PUBLIC KEY OBJECT ATTRIBUTES ...........................228 TABLE 62, DIFFIE-HELLMAN PRIVATE KEY OBJECT ATTRIBUTES ....................................229 TABLE 63, X9.42 DIFFIE-HELLMAN PRIVATE KEY OBJECT ATTRIBUTES .........................230 TABLE 64, DIFFIE-HELLMAN DOMAIN PARAMETER OBJECT ATTRIBUTES ........................231 TABLE 65, X9.42 DIFFIE-HELLMAN DOMAIN PARAMETERS OBJECT ATTRIBUTES ...........232 TABLE 66, X9.42 DIFFIE-HELLMAN KEY DERIVATION FUNCTIONS .................................235 TABLE 67, KEA PUBLIC KEY OBJECT ATTRIBUTES .........................................................244 TABLE 68, KEA PRIVATE KEY OBJECT ATTRIBUTES........................................................245 TABLE 69, KEA PARAMETER VALUES AND OPERATIONS.................................................247 TABLE 70, GENERIC SECRET KEY OBJECT ATTRIBUTES ...................................................251 TABLE 71, RC2 SECRET KEY OBJECT ATTRIBUTES ..........................................................253 TABLE 72, RC2-ECB: KEY AND DATA LENGTH ..............................................................256 TABLE 73, RC2-CBC: KEY AND DATA LENGTH ..............................................................257 TABLE 74, RC2-CBC WITH PKCS PADDING: KEY AND DATA LENGTH ..........................258 TABLE 75, GENERAL-LENGTH RC2-MAC: KEY AND DATA LENGTH ..............................259 TABLE 76, RC2-MAC: KEY AND DATA LENGTH .............................................................259 TABLE 77, RC4 SECRET KEY OBJECT...............................................................................260 TABLE 78, RC4: KEY AND DATA LENGTH .......................................................................261 TABLE 79, RC5 SECRET KEY OBJECT...............................................................................262 TABLE 80, RC5-ECB: KEY AND DATA LENGTH ..............................................................265 TABLE 81, RC5-CBC: KEY AND DATA LENGTH ..............................................................266 TABLE 82, RC5-CBC WITH PKCS PADDING: KEY AND DATA LENGTH ..........................267 TABLE 83, GENERAL-LENGTH RC2-MAC: KEY AND DATA LENGTH ..............................267 TABLE 84, RC5-MAC: KEY AND DATA LENGTH .............................................................268 TABLE 85, AES SECRET KEY OBJECT ATTRIBUTES..........................................................269 TABLE 86, AES-ECB: KEY AND DATA LENGTH ..............................................................270 TABLE 87, AES-CBC: KEY AND DATA LENGTH..............................................................271 TABLE 88, AES-CBC WITH PKCS PADDING: KEY AND DATA LENGTH ..........................272
June 2004 Copyright ? 2004 RSA Security Inc.

xiv

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD

TABLE 89, GENERAL-LENGTH AES-MAC: KEY AND DATA LENGTH ..............................273 TABLE 90, AES-MAC: KEY AND DATA LENGTH ............................................................273 TABLE 91, DES SECRET KEY OBJECT ..............................................................................275 TABLE 92, CAST SECRET KEY OBJECT ATTRIBUTES .......................................................276 TABLE 93, CAST3 SECRET KEY OBJECT ATTRIBUTES .....................................................277 TABLE 94, CAST128 (CAST5) SECRET KEY OBJECT ATTRIBUTES .................................277 TABLE 95, IDEA SECRET KEY OBJECT ............................................................................278 TABLE 96, CDMF SECRET KEY OBJECT...........................................................................279 TABLE 97, GENERAL BLOCK CIPHER ECB: KEY AND DATA LENGTH ..............................281 TABLE 98, GENERAL BLOCK CIPHER CBC: KEY AND DATA LENGTH..............................282 TABLE 99, GENERAL BLOCK CIPHER CBC WITH PKCS PADDING: KEY AND DATA LENGTH283 TABLE 100, GENERAL-LENGTH GENERAL BLOCK CIPHER MAC: KEY AND DATA LENGTH284 TABLE 101, GENERAL BLOCK CIPHER MAC: KEY AND DATA LENGTH ..........................284 TABLE 102, MECHANISM PARAMETERS ............................................................................285 TABLE 103, DES2 SECRET KEY OBJECT ATTRIBUTES......................................................287 TABLE 104, DES3 SECRET KEY OBJECT ATTRIBUTES......................................................288 TABLE 105, OFB: KEY AND DATA LENGTH .....................................................................290 TABLE 106, CFB: KEY AND DATA LENGTH .....................................................................291 TABLE 107, SKIPJACK SECRET KEY OBJECT .................................................................292 TABLE 108, SKIPJACK-ECB64: DATA AND LENGTH .....................................................296 TABLE 109, SKIPJACK-CBC64: DATA AND LENGTH .....................................................296 TABLE 110, SKIPJACK-OFB64: DATA AND LENGTH .....................................................297 TABLE 111, SKIPJACK-CFB64: DATA AND LENGTH .....................................................297 TABLE 112, SKIPJACK-CFB32: DATA AND LENGTH .....................................................298 TABLE 113, SKIPJACK-CFB16: DATA AND LENGTH .....................................................298 TABLE 114, SKIPJACK-CFB8: DATA AND LENGTH .......................................................299 TABLE 115, BATON SECRET KEY OBJECT ......................................................................300 TABLE 116, BATON-ECB128: DATA AND LENGTH ........................................................302 TABLE 117, BATON-ECB96: DATA AND LENGTH ..........................................................302 TABLE 118, BATON-CBC128: DATA AND LENGTH ........................................................303 TABLE 119, BATON-COUNTER: DATA AND LENGTH ...................................................303 TABLE 120, BATON-SHUFFLE: DATA AND LENGTH.....................................................304 TABLE 121, JUNIPER SECRET KEY OBJECT ....................................................................304 TABLE 122, JUNIPER-ECB128: DATA AND LENGTH ......................................................306 TABLE 123, JUNIPER-CBC128: DATA AND LENGTH......................................................307 TABLE 124, JUNIPER-COUNTER: DATA AND LENGTH .................................................307 TABLE 125, JUNIPER-SHUFFLE: DATA AND LENGTH ..................................................307 TABLE 126, MD2: DATA LENGTH ....................................................................................308 TABLE 127, GENERAL-LENGTH MD2-HMAC: KEY AND DATA LENGTH ........................309 TABLE 128, MD5: DATA LENGTH ....................................................................................311 TABLE 129, GENERAL-LENGTH MD5-HMAC: KEY AND DATA LENGTH ........................311 TABLE 130, SHA-1: DATA LENGTH .................................................................................313 TABLE 131, GENERAL-LENGTH SHA-1-HMAC: KEY AND DATA LENGTH......................313 TABLE 132, SHA-256: DATA LENGTH .............................................................................315 TABLE 133, GENERAL-LENGTH SHA-256-HMAC: KEY AND DATA LENGTH..................316 TABLE 134, SHA-384: DATA LENGTH .............................................................................317
Copyright ? 2004 RSA Security Inc. June 2004

xv TABLE 135, SHA-512: DATA LENGTH .............................................................................318 TABLE 136, FASTHASH: DATA LENGTH ........................................................................319 TABLE 137, PKCS #5 PBKDF2 KEY GENERATION: PSEUDO-RANDOM FUNCTIONS.........323 TABLE 138, PKCS #5 PBKDF2 KEY GENERATION: SALT SOURCES ................................323 TABLE 139, RIPE-MD 128: DATA LENGTH .....................................................................329 TABLE 140, GENERAL-LENGTH RIPE-MD 128-HMAC: ..................................................330 TABLE 141, RIPE-MD 160: DATA LENGTH .....................................................................330 TABLE 142, GENERAL-LENGTH RIPE-MD 160-HMAC: ..................................................331 TABLE 143, MD5 MACING IN SSL 3.0: KEY AND DATA LENGTH ..................................340 TABLE 144, SHA-1 MACING IN SSL 3.0: KEY AND DATA LENGTH................................341 TABLE 145, CMS SIGNATURE MECHANISM OBJECT ATTRIBUTES....................................364 TABLE 146, BLOWFISH SECRET KEY OBJECT................................................................368 TABLE 147, TWOFISH SECRET KEY OBJECT .....................................................................370

June 2004

Copyright ? 2004 RSA Security Inc.

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. 2. 3. 4. Publish carefully written documents describing the standards. Solicit opinions and advice from developers and users on useful or necessary changes and extensions. Publish revised standards when appropriate. 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:

June 2004

Copyright ? 2004 RSA Security Inc.

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

Copyright ? 2004 RSA Security Inc.

June 2004

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/ISO. American National Standard for Programming Languages – C. 1990. Accredited Standards Committee X9. Digital Signatures Using Reversible Public Key Cryptography for the Financial Services Industry (rDSA). 1998. Accredited Standards Committee X9. Public Key Cryptography for the Financial Services Industry: Agreement of Symmetric Keys Using Discrete Logarithm Cryptography. 2003. Accredited Standards Committee X9. Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA). 1998. Accredited Standards Committee X9. Public Key Cryptography for the Financial Services Industry: Key Agreement and Key Transport Using Elliptic Curve Cryptography. 2001. 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/ Ameritech Mobile Communications et al. Cellular Digital Packet Data System Specifications: Part 406: Airlink Security. 1993.

ANSI C ANSI X9.31

ANSI X9.42

ANSI X9.62

ANSI X9.63

CC/PP

CDPD

FIPS PUB 46–3 NIST. FIPS 46-3: Data Encryption Standard (DES). October 25, 1999. URL: http://csrc.nist.gov/publications/fips/index.html

June 2004

Copyright ? 2004 RSA Security Inc.

4 FIPS PUB 74

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD 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 NIST. FIPS 81: DES Modes of Operation. December 1980. URL: http://csrc.nist.gov/publications/fips/index.html NIST. FIPS 113: Computer Data Authentication. May 30, 1985. URL: http://csrc.nist.gov/publications/fips/index.html

FIPS PUB 81 FIPS PUB 113

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 (GCSAPI), 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. MeT PTD Definition – Personal Trusted Device Definition, Version 1.0, February 2003. URL: http://www.mobiletransaction.org

MeT-PTD

Copyright ? 2004 RSA Security Inc.

June 2004

3. REFERENCES PCMCIA PKCS #1 PKCS #3

5 Personal Computer Memory Card International Association. PC Card Standard, Release 2.1,. July 1993. RSA Laboratories. RSA Cryptography Standard. v2.1, June 14, 2002. URL: http://www.rsasecurity.com/rsalabs/pkcs/pkcs-1/index.html RSA Laboratories. Diffie-Hellman Key-Agreement Standard. v1.4, November 1993. URL: http://www.rsasecurity.com/rsalabs/pkcs/pkcs3/index.html RSA Laboratories. Password-Based Encryption Standard. v2.0, March 25, 1999. URL: http://www.rsasecurity.com/rsalabs/pkcs/pkcs5/index.html RSA Laboratories. Cryptographic Message Syntax Standard. v1.5, November 1993. URL: http://www.rsasecurity.com/rsalabs/pkcs/pkcs7/index.html RSA Laboratories. Private-Key Information Syntax Standard. v1.2, November 1993. URL: http://www.rsasecurity.com/rsalabs/pkcs/pkcs8/index.html RSA Laboratories. PKCS #11: Conformance Profile Specification, October 2000. URL: http://www.rsasecurity.com/rsalabs/pkcs/pkcs11/index.html RSA Laboratories. PKCS #11 Profiles for mobile devices, June 2003. URL: http://www.rsasecurity.com/rsalabs/pkcs/pkcs-11/index.html RSA Laboratories. Personal Information Exchange Syntax Standard. v1.0, June 1999. URL: http://www.rsasecurity.com/rsalabs/pkcs/pkcs12/index.html B. Kaliski. RFC 1319: The MD2 Message-Digest Algorithm. RSA Laboratories, April 1992. URL: http://ietf.org/rfc/rfc1319.txt R. Rivest. RFC 1321: The MD5 Message-Digest Algorithm. MIT Laboratory for Computer Science and RSA Data Security, Inc., April 1992. URL: http://ietf.org/rfc/rfc1321.txt J. Linn. RFC 1421: Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures. IAB IRTF PSRG, IETF PEM WG, February 1993. URL: http://ietf.org/rfc/rfc1421.txt Freed, N., and N. Borenstein. RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. November 1996. URL: http://ietf.org/rfc/rfc2045.txt T. Dierks & C. Allen. RFC 2246: The TLS Protocol Version 1.0. Certicom, January 1999. URL: http://ietf.org/rfc/rfc2246.txt F. Yergeau. RFC 2279: UTF-8, a transformation format of ISO 10646 Alis Technologies, January 1998. URL: http://ietf.org/rfc/rfc2279.txt
Copyright ? 2004 RSA Security Inc.

PKCS #5

PKCS #7

PKCS #8

PKCS #11-C

PKCS #11-P PKCS #12

RFC 1319 RFC 1321

RFC 1421

RFC 2045

RFC 2246 RFC 2279

June 2004

6 RFC 2534

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD Masinter, L., Wing, D., Mutz, A., and K. Holtman. RFC 2534: Media Features for Display, Print, and Fax. March 1999. URL: http://ietf.org/rfc/rfc2534.txt R. Housley. RFC 2630: Cryptographic Message Syntax. June 1999. URL: http://ietf.org/rfc/rfc2630.txt J. Linn. RFC 2743: Generic Security Service Application Program Interface Version 2, Update 1. RSA Laboratories, January 2000. URL: http://ietf.org/rfc/rfc2743.txt J. Wray. RFC 2744: Generic Security Services API Version 2: Cbindings. Iris Associates, January 2000. URL: http://ietf.org/rfc/rfc2744.txt Standards for Efficient Cryptography Group (SECG). Standards for Efficient Cryptography (SEC) 1: Elliptic Curve Cryptography. Version 1.0, September 20, 2000. Standards for Efficient Cryptography Group (SECG). Standards for Efficient Cryptography (SEC) 2: Recommended Elliptic Curve Domain Parameters. Version 1.0, September 20, 2000. IETF. RFC 2246: The TLS Protocol Version 1.0 . January 1999. URL: http://ietf.org/rfc/rfc2246.txt WAP. Wireless Identity Module. — WAP-260-WIM-20010712-a. July 2001. URL: http://www.wapforum.org/ WAP. Wireless PKI. — WAP-217-WPKI-20010424-a. April 2001. URL: http://www.wapforum.org/ WAP. Wireless Transport Layer Security Version — WAP-261-WTLS20010406-a. April 2001. URL: http://www.wapforum.org/. ITU-T. Information Technology — Open Systems Interconnection — The Directory: Overview of Concepts, Models and Services. February 2001. Identical to ISO/IEC 9594-1 ITU-T. Information Technology — Open Systems Interconnection — The Directory: Public-key and Attribute Certificate Frameworks. March 2000. Identical to ISO/IEC 9594-8 ITU-T. Information Technology — Abstract Syntax Notation One (ASN.1): Specification of Basic Notation. July 2002. Identical to ISO/IEC 8824-1 ITU-T. Information Technology — ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER). July 2002. Identical to ISO/IEC 8825-1

RFC 2630 RFC 2743

RFC 2744

SEC 1

SEC 2

TLS WIM WPKI WTLS X.500

X.509

X.680

X.690

Copyright ? 2004 RSA Security Inc.

June 2004

4. DEFINITIONS

7

4

Definitions

For the purposes of this standard, the following definitions apply: API Application ASN.1 Attribute BATON BER CAST CAST3 CAST5 Application programming interface. Any computer program that calls the Cryptoki interface. Abstract Syntax Notation One, as defined in X.680. A characteristic of an object. MISSI’s BATON block cipher. Basic Encoding Rules, as defined in X.690. Entrust Technologies’ proprietary symmetric block cipher. Entrust Technologies’ proprietary symmetric block cipher. Another name for Entrust Technologies’ symmetric block cipher CAST128. CAST128 is the preferred name. Entrust Technologies’ symmetric block cipher. Cipher-Block Chaining mode, as defined in FIPS PUB 81. Commercial Data Masking Facility, a block encipherment method specified by International Business Machines Corporation and based on DES. A signed message binding a subject name and a public key, or a subject name and a set of attributes. Cryptographic Message Syntax (see RFC 2630) A device storing cryptographic information and possibly performing cryptographic functions. May be implemented as a smart card, smart disk, PCMCIA card, or with some other technology, including software-only. The Cryptographic Token Interface defined in this standard. A library that implements the functions specified in this standard. Distinguished Encoding Rules, as defined in X.690.

CAST128 CBC CDMF

Certificate CMS Cryptographic Device

Cryptoki Cryptoki library DER

June 2004

Copyright ? 2004 RSA Security Inc.

8

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD DES DSA EC ECB ECDH ECDSA ECMQV FASTHASH IDEA IV JUNIPER KEA LYNKS MAC MD2 MD5 Mechanism MQV OAEP Object PIN PKCS PRF PTD RSA RC2 RC4 Data Encryption Standard, as defined in FIPS PUB 463. Digital Signature Algorithm, as defined in FIPS PUB 186-2. Elliptic Curve Electronic Codebook mode, as defined in FIPS PUB 81. Elliptic Curve Diffie-Hellman. Elliptic Curve DSA, as in ANSI X9.62. Elliptic Curve Menezes-Qu-Vanstone MISSI’s FASTHASH message-digesting algorithm. Ascom Systec’s symmetric block cipher. Initialization Vector. MISSI’s JUNIPER block cipher. MISSI’s Key Exchange Algorithm. A smart card manufactured by SPYRUS. Message Authentication Code. RSA Security's MD2 message-digest algorithm, as defined in RFC 1319. RSA Security's MD5 message-digest algorithm, as defined in RFC 1321. A process for implementing a cryptographic operation. Menezes-Qu-Vanstone Optimal Asymmetric Encryption Padding for RSA. An item that is stored on a token. May be data, a certificate, or a key. Personal Identification Number. Public-Key Cryptography Standards. Pseudo random function. Personal Trusted Device, as defined in MeT-PTD The RSA public-key cryptosystem. RSA Security’s RC2 symmetric block cipher. RSA Security’s proprietary RC4 symmetric stream cipher.

Copyright ? 2004 RSA Security Inc.

June 2004

4. DEFINITIONS RC5 Reader Session SET SHA-1 SHA-256 SHA-384 SHA-512 Slot SKIPJACK SSL Subject Name SO TLS Token User UTF-8 RSA Security’s RC5 symmetric block cipher. The means by which information is exchanged with a device. A logical connection between an application and a token. The Secure Electronic Transaction protocol. The (revised) Secure Hash Algorithm with a 160-bit message digest, as defined in FIPS PUB 180-2. The Secure Hash Algorithm with a 256-bit message digest, as defined in FIPS PUB 180-2. The Secure Hash Algorithm with a 384-bit message digest, as defined in FIPS PUB 180-2. The Secure Hash Algorithm with a 512-bit message digest, as defined in FIPS PUB 180-2. A logical reader that potentially contains a token. MISSI’s SKIPJACK block cipher. The Secure Sockets Layer 3.0 protocol.

9

The X.500 distinguished name of the entity to which a key is assigned. A Security Officer user. Transport Layer Security. The logical view of a cryptographic device defined by Cryptoki. The person using an application that interfaces to Cryptoki. Universal Character Set (UCS) transformation format (UTF) that represents ISO 10646 and UNICODE strings with a variable number of octets. Wireless Identification Module. Wireless Transport Layer Security.

WIM WTLS

June 2004

Copyright ? 2004 RSA Security Inc.

10

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD

5

Symbols and abbreviations

The following symbols are used in this standard: Table 1, Symbols Symbol N/A R/O R/W Definition Not applicable Read-only Read/write

The following prefixes are used in this standard: Table 2, Prefixes Prefix C_ CK_ CKA_ CKC_ CKD_ CKF_ CKG_ CKH_ CKK_ CKM_ CKN_ CKO_ CKP_ CKS_ CKR_ CKU_ CKZ_ h ul p pb ph pul Description Function Data type or general constant Attribute Certificate type Key derivation function Bit flag Mask generation function Hardware feature type Key type Mechanism type Notification Object class Pseudo-random function Session state Return value User type Salt/Encoding parameter source a handle a CK_ULONG a pointer a pointer to a CK_BYTE a pointer to a handle a pointer to a CK_ULONG

Copyright ? 2004 RSA Security Inc.

June 2004

5. SYMBOLS AND ABBREVIATIONS Cryptoki is based on ANSI C types, and defines the following data types: /* an unsigned 8-bit value */ typedef unsigned char CK_BYTE; /* an unsigned 8-bit character */ typedef CK_BYTE CK_CHAR; /* an 8-bit UTF-8 character */ typedef CK_BYTE CK_UTF8CHAR; /* a BYTE-sized Boolean flag */ typedef CK_BYTE CK_BBOOL; /* an unsigned value, at least 32 bits long */ typedef unsigned long int CK_ULONG; /* a signed value, the same size as a CK_ULONG */ typedef long int CK_LONG; /* at least 32 bits; each bit is a Boolean flag */ typedef CK_ULONG CK_FLAGS;

11

Cryptoki also uses pointers to some of these data types, as well as to the type void, which are implementation-dependent. These pointer types are: CK_BYTE_PTR CK_CHAR_PTR CK_UTF8CHAR_PTR CK_ULONG_PTR CK_VOID_PTR /* /* /* /* /* Pointer Pointer Pointer Pointer Pointer to to to to to a a a a a CK_BYTE */ CK_CHAR */ CK_UTF8CHAR */ CK_ULONG */ void */

Cryptoki also defines a pointer to a CK_VOID_PTR, which is implementationdependent: CK_VOID_PTR_PTR /* Pointer to a CK_VOID_PTR */

In addition, Cryptoki defines a C-style NULL pointer, which is distinct from any valid pointer: NULL_PTR /* A NULL pointer */

It follows that many of the data and pointer types will vary somewhat from one environment to another (e.g., a CK_ULONG will sometimes be 32 bits, and sometimes perhaps 64 bits). However, these details should not affect an application, assuming it is compiled with Cryptoki header files consistent with the Cryptoki library to which the application is linked.

June 2004

Copyright ? 2004 RSA Security Inc.

12

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD

All numbers and values expressed in this document are decimal, unless they are preceded by “0x”, in which case they are hexadecimal values. The CK_CHAR data type holds characters from the following table, taken from ANSI C: Table 3, Character Set Category Letters Numbers Graphic characters Blank character Characters ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz 0123456789 !“#%&‘()*+,-./:;<=>?[\]^_{|}~ ‘‘

The CK_UTF8CHAR data type holds UTF-8 encoded Unicode characters as specified in RFC2279. UTF-8 allows internationalization while maintaining backward compatibility with the Local String definition of PKCS #11 version 2.01. In Cryptoki, the CK_BBOOL data type is a Boolean type that can be true or false. A zero value means false, and a nonzero value means true. Similarly, an individual bit flag, CKF_..., can also be set (true) or unset (false). For convenience, Cryptoki defines the following macros for use with values of type CK_BBOOL: #define CK_FALSE 0 #define CK_TRUE 1 For backwards compatibility, header files for this version of Cryptoki also defines TRUE and FALSE as (CK_DISABLE_TRUE_FALSE may be set by the application vendor): #ifndef CK_DISABLE_TRUE_FALSE #ifndef FALSE #define FALSE CK_FALSE #endif #ifndef TRUE #define TRUE CK_TRUE #endif #endif

6
6.1

General overview
Introduction

Portable computing devices such as smart cards, PCMCIA cards, and smart diskettes are ideal tools for implementing public-key cryptography, as they provide a way to store the

Copyright ? 2004 RSA Security Inc.

June 2004

6. GENERAL OVERVIEW

13

private-key component of a public-key/private-key pair securely, under the control of a single user. With such a device, a cryptographic application, rather than performing cryptographic operations itself, utilizes the device to perform the operations, with sensitive information such as private keys never being revealed. As more applications are developed for public-key cryptography, a standard programming interface for these devices becomes increasingly valuable. This standard addresses this need. 6.2 Design goals

Cryptoki was intended from the beginning to be an interface between applications and all kinds of portable cryptographic devices, such as those based on smart cards, PCMCIA cards, and smart diskettes. There are already standards (de facto or official) for interfacing to these devices at some level. For instance, the mechanical characteristics and electrical connections are well-defined, as are the methods for supplying commands and receiving results. (See, for example, ISO 7816, or the PCMCIA specifications.) What remained to be defined were particular commands for performing cryptography. It would not be enough simply to define command sets for each kind of device, as that would not solve the general problem of an application interface independent of the device. To do so is still a long-term goal, and would certainly contribute to interoperability. The primary goal of Cryptoki was a lower-level programming interface that abstracts the details of the devices, and presents to the application a common model of the cryptographic device, called a “cryptographic token” (or simply “token”). A secondary goal was resource-sharing. As desktop multi-tasking operating systems become more popular, a single device should be shared between more than one application. In addition, an application should be able to interface to more than one device at a given time. It is not the goal of Cryptoki to be a generic interface to cryptographic operations or security services, although one certainly could build such operations and services with the functions that Cryptoki provides. Cryptoki is intended to complement, not compete with, such emerging and evolving interfaces as “Generic Security Services Application Programming Interface” (RFC 2743 and RFC 2744) and “Generic Cryptographic Service API” (GCS-API) from X/Open. 6.3 General model

Cryptoki's general model is illustrated in the following figure. The model begins with one or more applications that need to perform certain cryptographic operations, and ends with one or more cryptographic devices, on which some or all of the operations are actually performed. A user may or may not be associated with an application. 从一个或多个需要执行特定密码学操作的应用丆到一个或多个加密设备。

June 2004

Copyright ? 2004 RSA Security Inc.

14

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD

Application 1 Other Security Layers

Application k Other Security Layers

Cryptoki

Cryptoki

Device Contention/Synchronization

Slot 1

Slot n

Token 1 (Device 1)

Token n (Device n)

Figure 1, General Cryptoki Model Cryptoki provides an interface to one or more cryptographic devices that are active in the system through a number of “slots”. Each slot, which corresponds to a physical reader or other device interface, may contain a token. A token is typically “present in the slot” when a cryptographic device is present in the reader. Of course, since Cryptoki provides a logical view of slots and tokens, there may be other physical interpretations. It is possible that multiple slots may share the same physical reader. The point is that a system has some number of slots, and applications can connect to tokens in any or all of those slots. 应用通过slot连接到token A cryptographic device can perform some cryptographic operations, following a certain command set; these commands are typically passed through standard device drivers, for instance PCMCIA card services or socket services. Cryptoki makes each cryptographic device look logically like every other device, regardless of the implementation technology. Thus the application need not interface directly to the device drivers (or even know which ones are involved); Cryptoki hides these details. Indeed, the underlying “device” may be implemented entirely in software (for instance, as a process running on a server)—no special hardware is necessary. 使各种加密设备在逻辑上看起来一致丆忽略其具体实现 Cryptoki is likely to be implemented as a library supporting the functions in the interface, and applications will be linked to the library. An application may be linked to Cryptoki directly; alternatively, Cryptoki can be a so-called “shared” library (or dynamic link

Copyright ? 2004 RSA Security Inc.

June 2004

6. GENERAL OVERVIEW

15

library), in which case the application would link the library dynamically. Shared libraries are fairly straightforward to produce in operating systems such as Microsoft Windows and OS/2, and can be achieved without too much difficulty in UNIX and DOS systems. 被实现为接口函数库丆可以是静态库、动态库、共享库 The dynamic approach certainly has advantages as new libraries are made available, but from a security perspective, there are some drawbacks. In particular, if a library is easily replaced, then there is the possibility that an attacker can substitute a rogue library that intercepts a user’s PIN. From a security perspective, therefore, direct linking is generally preferable, although code-signing techniques can prevent many of the security risks of dynamic linking. In any case, whether the linking is direct or dynamic, the programming interface between the application and a Cryptoki library remains the same. The kinds of devices and capabilities supported will depend on the particular Cryptoki library. This standard specifies only the interface to the library, not its features. In particular, not all libraries will support all the mechanisms (algorithms) defined in this interface (since not all tokens are expected to support all the mechanisms), and libraries will likely support only a subset of all the kinds of cryptographic devices that are available. (The more kinds, the better, of course, and it is anticipated that libraries will be developed supporting multiple kinds of token, rather than just those from a single vendor.) It is expected that as applications are developed that interface to Cryptoki, standard library and token “profiles” will emerge. Logical view of a token token的逻辑视角是一个能够存储对象和执行密码学功能的设备 Cryptoki’s logical view of a token is a device that stores objects and can perform cryptographic functions. Cryptoki defines three classes of object: data, certificates, and keys. A data object is defined by an application. A certificate object stores a certificate. A key object stores a cryptographic key. The key may be a public key, a private key, or a secret key; each of these types of keys has subtypes for use in specific mechanisms. This view is illustrated in the following figure: Object 6.4

Data

Key

Certificate

Public Key

Private Key

Secret Key

Figure 2, Object Hierarchy

June 2004

Copyright ? 2004 RSA Security Inc.

16

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD

Objects are also classified according to their lifetime and visibility. “Token objects” are visible to all applications connected to the token that have sufficient permission, and remain on the token even after the “sessions” (connections between an application and the token) are closed and the token is removed from its slot. “Session objects” are more temporary: whenever a session is closed by any means, all session objects created by that session are automatically destroyed. In addition, session objects are only visible to the application which created them. Further classification defines access requirements. Applications are not required to log into the token to view “public objects”; however, to view “private objects”, a user must be authenticated to the token by a PIN or some other token-dependent method (for example, a biometric device). See Table 6 on page 22 for further clarification on access to objects. A token can create and destroy objects, manipulate them, and search for them. It can also perform cryptographic functions with objects. A token may have an internal random number generator. It is important to distinguish between the logical view of a token and the actual implementation, because not all cryptographic devices will have this concept of “objects,” or be able to perform every kind of cryptographic function. Many devices will simply have fixed storage places for keys of a fixed algorithm, and be able to do a limited set of operations. Cryptoki's role is to translate this into the logical view, mapping attributes to fixed storage elements and so on. Not all Cryptoki libraries and tokens need to support every object type. It is expected that standard “profiles” will be developed, specifying sets of algorithms to be supported. “Attributes” are characteristics that distinguish an instance of an object. In Cryptoki, there are general attributes, such as whether the object is private or public. There are also attributes that are specific to a particular type of object, such as a modulus or exponent for RSA keys. 6.5 Users

This version of Cryptoki recognizes two token user types. One type is a Security Officer (SO). The other type is the normal user. Only the normal user is allowed access to private objects on the token, and that access is granted only after the normal user has been authenticated. Some tokens may also require that a user be authenticated before any cryptographic function can be performed on the token, whether or not it involves private objects. The role of the SO is to initialize a token and to set the normal user’s PIN (or otherwise define, by some method outside the scope of this version of Cryptoki, how the normal user may be authenticated), and possibly to manipulate some public objects. The normal user cannot log in until the SO has set the normal user’s PIN.

Copyright ? 2004 RSA Security Inc.

June 2004

6. GENERAL OVERVIEW

17

Other than the support for two types of user, Cryptoki does not address the relationship between the SO and a community of users. In particular, the SO and the normal user may be the same person or may be different, but such matters are outside the scope of this standard. With respect to PINs that are entered through an application, Cryptoki assumes only that they are variable-length strings of characters from the set in Table 3. Any translation to the device’s requirements is left to the Cryptoki library. The following issues are beyond the scope of Cryptoki: ? ? Any padding of PINs. How the PINs are generated (by the user, by the application, or by some other means).

PINs that are supplied by some means other than through an application (e.g., PINs entered via a PINpad on the token) are even more abstract. Cryptoki knows how to wait (if need be) for such a PIN to be supplied and used, and little more. 6.6 Applications and their use of Cryptoki

To Cryptoki, an application consists of a single address space and all the threads of control running in it. An application becomes a “Cryptoki application” by calling the Cryptoki function C_Initialize (see Section 11.4) from one of its threads; after this call is made, the application can call other Cryptoki functions. When the application is done using Cryptoki, it calls the Cryptoki function C_Finalize (see Section 11.4) and ceases to be a Cryptoki application. 6.6.1 Applications and processes

In general, on most platforms, the previous paragraph means that an application consists of a single process. Consider a UNIX process P which becomes a Cryptoki application by calling C_Initialize, and then uses the fork() system call to create a child process C. Since P and C have separate address spaces (or will when one of them performs a write operation, if the operating system follows the copy-on-write paradigm), they are not part of the same application. Therefore, if C needs to use Cryptoki, it needs to perform its own C_Initialize call. Furthermore, if C needs to be logged into the token(s) that it will access via Cryptoki, it needs to log into them even if P already logged in, since P and C are completely separate applications. In this particular case (when C is the child of a process which is a Cryptoki application), the behavior of Cryptoki is undefined if C tries to use it without its own C_Initialize call. Ideally, such an attempt would return the value CKR_CRYPTOKI_NOT_INITIALIZED; however, because of the way fork() works, insisting on this return value might have a
June 2004 Copyright ? 2004 RSA Security Inc.

18

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD

bad impact on the performance of libraries. Therefore, the behavior of Cryptoki in this situation is left undefined. Applications should definitely not attempt to take advantage of any potential “shortcuts” which might (or might not!) be available because of this. In the scenario specified above, C should actually call C_Initialize whether or not it needs to use Cryptoki; if it has no need to use Cryptoki, it should then call C_Finalize immediately thereafter. This (having the child immediately call C_Initialize and then call C_Finalize if the parent is using Cryptoki) is considered to be good Cryptoki programming practice, since it can prevent the existence of dangling duplicate resources that were created at the time of the fork() call; however, it is not required by Cryptoki. 6.6.2 Applications and threads

Some applications will access a Cryptoki library in a multi-threaded fashion. Cryptoki enables applications to provide information to libraries so that they can give appropriate support for multi-threading. In particular, when an application initializes a Cryptoki library with a call to C_Initialize, it can specify one of four possible multi-threading behaviors for the library: 1. The application can specify that it will not be accessing the library concurrently from multiple threads, and so the library need not worry about performing any type of locking for the sake of thread-safety. 2. The application can specify that it will be accessing the library concurrently from multiple threads, and the library must be able to use native operation system synchronization primitives to ensure proper thread-safe behavior. 3. The application can specify that it will be accessing the library concurrently from multiple threads, and the library must use a set of application-supplied synchronization primitives to ensure proper thread-safe behavior. 4. The application can specify that it will be accessing the library concurrently from multiple threads, and the library must use either the native operation system synchronization primitives or a set of application-supplied synchronization primitives to ensure proper thread-safe behavior. The 3rd and 4th types of behavior listed above are appropriate for multi-threaded applications which are not using the native operating system thread model. The application-supplied synchronization primitives consist of four functions for handling mutex (mutual exclusion) objects in the application’s threading model. Mutex objects are simple objects which can be in either of two states at any given time: unlocked or locked. If a call is made by a thread to lock a mutex which is already locked, that thread blocks (waits) until the mutex is unlocked; then it locks it and the call returns. If more than one thread is blocking on a particular mutex, and that mutex becomes unlocked, then exactly one of those threads will get the lock on the mutex and return control to the caller (the other blocking threads will continue to block and wait for their turn).

Copyright ? 2004 RSA Security Inc.

June 2004

6. GENERAL OVERVIEW See Section 9.7 for more information on Cryptoki’s view of mutex objects.

19

In addition to providing the above thread-handling information to a Cryptoki library at initialization time, an application can also specify whether or not application threads executing library calls may use native operating system calls to spawn new threads. 6.7 Sessions

Cryptoki requires that an application open one or more sessions with a token to gain access to the token’s objects and functions. A session provides a logical connection between the application and the token. A session can be a read/write (R/W) session or a read-only (R/O) session. Read/write and read-only refer to the access to token objects, not to session objects. In both session types, an application can create, read, write and destroy session objects, and read token objects. However, only in a read/write session can an application create, modify, and destroy token objects. 两种session都可以读写session对象和读token对象丆但只有RW session可以写token对象。 After it opens a session, an application has access to the token’s public objects. All threads of a given application have access to exactly the same sessions and the same session objects. To gain access to the token’s private objects, the normal user must log in and be authenticated. session所创建的所有session对象随session一起销毁丆包括正在被使用的。 When a session is closed, any session objects which were created in that session are destroyed. This holds even for session objects which are “being used” by other sessions. That is, if a single application has multiple sessions open with a token, and it uses one of them to create a session object, then that session object is visible through any of that application’s sessions. However, as soon as the session that was used to create the object is closed, that object is destroyed. Cryptoki supports multiple sessions on multiple tokens. An application may have one or more sessions with one or more tokens. In general, a token may have multiple sessions with one or more applications. A particular token may allow an application to have only a limited number of sessions—or only a limited number of read/write sessions-- however. An open session can be in one of several states. The session state determines allowable access to objects and functions that can be performed on them. The session states are described in Section 6.7.1 and Section 6.7.2. 6.7.1 Read-only session states

A read-only session can be in one of two states, as illustrated in the following figure. When the session is initially opened, it is in either the “R/O Public Session” state (if the application has no previously open sessions that are logged in) or the “R/O User Functions” state (if the application already has an open session that is logged in). Note that read-only SO sessions do not exist.

June 2004

Copyright ? 2004 RSA Security Inc.

20

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD

Open Session Login User

R/O Public Session
Logout

Close Session/ Device Removed

Open Session

R/O User Functions

Close Session/ Device Removed

Figure 3, Read-Only Session States The following table describes the session states: Table 4, Read-Only Session States State R/O Public Session Description The application has opened a read-only session. The application has read-only access to public token objects and read/write access to public session objects. R/O User Functions The normal user has been authenticated to the token. The application has read-only access to all token objects (public or private) and read/write access to all session objects (public or private). Read/write session states

6.7.2

A read/write session can be in one of three states, as illustrated in the following figure. When the session is opened, it is in either the “R/W Public Session” state (if the application has no previously open sessions that are logged in), the “R/W User Functions” state (if the application already has an open session that the normal user is logged into), or the “R/W SO Functions” state (if the application already has an open session that the SO is logged into).

Copyright ? 2004 RSA Security Inc.

June 2004

6. GENERAL OVERVIEW

21

R/W SO Functions
Open Session Login SO Logout

Close Session/ Device Removed

Open Session

R/W Public Session
Login User Logout

Close Session/ Device Removed

Open Session

R/W User Functions

Close Session/ Device Removed

Figure 4, Read/Write Session States The following table describes the session states: Table 5, Read/Write Session States State Description R/W Public Session The application has opened a read/write session. The application has read/write access to all public objects. R/W SO Functions The Security Officer has been authenticated to the token. The application has read/write access only to public objects on the token, not to private objects. The SO can set the normal user’s PIN. R/W User The normal user has been authenticated to the token. The Functions application has read/write access to all objects. 6.7.3 Permitted object accesses by sessions

The following table summarizes the kind of access each type of session has to each type of object. A given type of session has either read-only access, read/write access, or no access whatsoever to a given type of object. Note that creating or deleting an object requires read/write access to it, e.g., a “R/O User Functions” session cannot create or delete a token object.

June 2004

Copyright ? 2004 RSA Security Inc.

22

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD

Table 6, Access to Different Types Objects by Different Types of Sessions
R/O Public R/W R/O Type of session R/W R/O Public User R/W R/W R/W R/W R/O R/O R/W User R/W R/W R/W R/W R/W SO R/W R/W

Type of object Public session object Private session object Public token object Private token object

As previously indicated, the access to a given session object which is shown in Table 6 is limited to sessions belonging to the application which owns that object (i.e., which created that object). 6.7.4 Session events

Session events cause the session state to change. The following table describes the events: Table 7, Session Events Event Occurs when... Log In SO the SO is authenticated to the token. Log In User the normal user is authenticated to the token. Log Out the application logs out the current user (SO or normal user). Close Session the application closes the session or closes all sessions. Device Removed the device underlying the token has been removed from its slot. 设备拔出后丆所有session都会关闭丆应用不能在token离线时持有session When the device is removed, all sessions of all applications are automatically logged out. Furthermore, all sessions any applications have with the device are closed (this latter behavior was not present in Version 1.0 of Cryptoki)—an application cannot have a session with a token that is not present. Realistically, Cryptoki may not be constantly monitoring whether or not the token is present, and so the token’s absence could conceivably not be noticed until a Cryptoki function is executed. If the token is reinserted into the slot before that, Cryptoki might never know that it was missing. In Cryptoki, all sessions that an application has with a token must have the same login/logout status (i.e., for a given application and token, one of the following holds: all sessions are public sessions; all sessions are SO sessions; or all sessions are user sessions). When an application’s session logs into a token, all of that application’s sessions with that token become logged in, and when an application’s session logs out of a token, all of that application’s sessions with that token become logged out. Similarly, for example, if an application already has a R/O user session open with a token, and then opens a R/W session with that token, the R/W session is automatically logged in. 一个应用中指向特定token的所有session必须保持相同的login/logout状态丆 若这些session中的某一个改变了登录状态丆其他的session也会自动保持一致 新打开的session与已经打开的session保持一致
Copyright ? 2004 RSA Security Inc. June 2004

6. GENERAL OVERVIEW

23

一个应用不能同时拥有针对一个token的SO session 和 user session This implies that a given application may not simultaneously have SO sessions and user sessions open with a given token. It also implies that if an application has a R/W SO session with a token, then it may not open a R/O session with that token, since R/O SO sessions do not exist. For the same reason, if an application has a R/O session open, then it may not log any other session into the token as the SO. 不存在 R/O SO session
6.7.5 Session handles and object handles

A session handle is a Cryptoki-assigned value that identifies a session. It is in many ways akin to a file handle, and is specified to functions to indicate which session the function should act on. All threads of an application have equal access to all session handles. That is, anything that can be accomplished with a given file handle by one thread can also be accomplished with that file handle by any other thread of the same application. Cryptoki also has object handles, which are identifiers used to manipulate Cryptoki objects. Object handles are similar to session handles in the sense that visibility of a given object through an object handle is the same among all threads of a given application. R/O sessions, of course, only have read-only access to token objects, whereas R/W sessions have read/write access to token objects. Valid session handles and object handles in Cryptoki always have nonzero values. For developers’ convenience, Cryptoki defines the following symbolic value: CK_INVALID_HANDLE 6.7.6 Capabilities of sessions

管理员操作、对象管理操作、密码学操作 Very roughly speaking, there are three broad types of operations an open session can be used to perform: administrative operations (such as logging in); object management operations (such as creating or destroying an object on the token); and cryptographic operations (such as computing a message digest). Cryptographic operations sometimes require more than one function call to the Cryptoki API to complete. In general, a single session can perform only one operation at a time; for this reason, it may be desirable for a single application to open multiple sessions with a single token. For efficiency’s sake, however, a single session on some tokens can perform the following pairs of operation types simultaneously: message digesting and encryption; decryption and message digesting; signature or MACing and encryption; and decryption and verifying signatures or MACs. Details on performing simultaneous cryptographic operations in one session are provided in Section 11.13.

A consequence of the fact that a single session can, in general, perform only one operation at a time is that an application should never make multiple simultaneous function calls to Cryptoki which use a common session. If multiple threads of an application attempt to use a common session concurrently in this fashion, Cryptoki does not define what happens. This means that if multiple threads of an application all need to

June 2004

Copyright ? 2004 RSA Security Inc.

24

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD

use Cryptoki to access a particular token, it might be appropriate for each thread to have its own session with the token, unless the application can ensure by some other means (e.g., by some locking mechanism) that no sessions are ever used by multiple threads simultaneously. This is true regardless of whether or not the Cryptoki library was initialized in a fashion which permits safe multi-threaded access to it. Even if it is safe to access the library from multiple threads simultaneously, it is still not necessarily safe to use a particular session from multiple threads simultaneously. 6.7.7 Example of use of sessions

We give here a detailed and lengthy example of how multiple applications can make use of sessions in a Cryptoki library. Despite the somewhat painful level of detail, we highly recommend reading through this example carefully to understand session handles and object handles. We caution that our example is decidedly not meant to indicate how multiple applications should use Cryptoki simultaneously; rather, it is meant to clarify what uses of Cryptoki’s sessions and objects and handles are permissible. In other words, instead of demonstrating good technique here, we demonstrate “pushing the envelope”.
应用程序A和B?C线程A1、A2?CB1、B2

For our example, we suppose that two applications, A and B, are using a Cryptoki library to access a single token T. Each application has two threads running: A has threads A1 and A2, and B has threads B1 and B2. We assume in what follows that there are no instances where multiple threads of a single application simultaneously use the same session, and that the events of our example occur in the order specified, without overlapping each other in time.
1.

A1 and B1 each initialize the Cryptoki library by calling C_Initialize (the specifics of Cryptoki functions will be explained in Section 10.12). Note that exactly one call to C_Initialize should be made for each application (as opposed to one call for every thread, for example). is the first session to be opened for A, it is a public session.

1. 每个应用需要首先调用 C_Initialize?C一个应用中的多个线程只需调用一次 2. A1 opens a R/W session and receives the session handle 7 for the session. Since this 2. A1线程打开一个RW session?C收到句柄7。这是A打开的第一个session?C因此是public session?G 3. A2 opens a R/O session and receives the session handle 4. Since all of A’s existing

sessions are public sessions, session 4 is also a public session.
3. A2线程打开一个RO session?C收到句柄4。因为A已存在的session都是public session?C因此session 4也一样丟 4. A1 attempts to log the SO into session 7. The attempt fails, because if session 7

becomes an SO session, then session 4 does, as well, and R/O SO sessions do not exist. A1 receives an error code indicating that the existence of a R/O session has blocked this attempt to log in (CKR_SESSION_READ_ONLY_EXISTS).
4. 因为所有session的登录状态要一致丆同时不存在R/O SO session?C所以session 4导致session 7不能以SO登录丟 5. A2 logs the normal user into session 7. This turns session 7 into a R/W user session,

and turns session 4 into a R/O user session. Note that because A1 and A2 belong to
5. 同一个应用下丆A1和A2对session 4 和 7 拥有相同的操作能力。A2将session 7 登录到user用户丆 同时session 4 也自动变成RO user session?G

Copyright ? 2004 RSA Security Inc.

June 2004

6. GENERAL OVERVIEW

25

the same application, they have equal access to all sessions, and therefore, A2 is able to perform this action.
6.

A2 opens a R/W session and receives the session handle 9. Since all of A’s existing sessions are user sessions, session 9 is also a user session.

6. A2打开一个RW session?C收到句柄9。session 9 获得A已有的user登录状态丟 7. A1 closes session 9. 7. A1关闭session 9?G 8. B1 attempts to log out session 4. The attempt fails, because A and B have no access

rights to each other’s sessions or objects. B1 receives an error message which indicates that there is no such session handle (CKR_SESSION_HANDLE_INVALID).
8. B1尝试登出session 4会失败丆因为A和B不具有互相访问对方的session或对象的权限丆B1不持有session 4的句柄丟 9. B2 attempts to close session 4. The attempt fails in precisely the same way as B1’s

attempt to log out session 4 failed CKR_SESSION_HANDLE_INVALID error code).
9. B2尝试关闭session 4?C失败原因同8?G 10. B1 opens a R/W session and receives

(i.e.,

B2

receives

a

10. B1打开一个RW session获得句柄7?C注意丗A的session 7与B的session 7没有任何关联丟

the session handle 7. Note that, as far as B is concerned, this is the first occurrence of session handle 7. A’s session 7 and B’s session 7 are completely different sessions. and has no effect on either of A’s sessions.

11. B1 logs the SO into [B’s] session 7. This turns B’s session 7 into a R/W SO session,
11. B1登录SO到B的session 7?C使B的session 7成为R/W SO session?C这不会影响A的session?G

12. B2 attempts to open a R/O session. The attempt fails, since B already has an SO

session open, and R/O SO sessions do not exist. B1 receives an error message 应该是B2吧 indicating that the existence of an SO session has blocked this attempt to open a R/O session (CKR_SESSION_READ_WRITE_SO_EXISTS).
12. 因为B已经有了一个SO session?C因此B2若尝试打开一个RO session会失败丟 13. A1 uses [A’s] session 7 to create a session object O1 of some sort

and receives the object handle 7. Note that a Cryptoki implementation may or may not support separate spaces of handles for sessions and objects.

13. A1使用session A7建立一个session对象O1?C获得句柄7?C注意Cryptoki在实现中未要求隔离或不隔离session和对象的句柄空间丟 14. B1 uses [B’s] session 7 to create a token object O2 of some sort and receives the

14. B1使用session B7建立token对象O2?C获得句柄7?C和session句柄一样丆不同应用之间不能访问对方的对象句柄丆 因为B1是SO session?C不能创建私有对象丆所以O2必须是公共对象丟 15. B2 uses [B’s] session 7 to perform some operation to modify the object associated

object handle 7. As with session handles, different applications have no access rights to each other’s object handles, and so B’s object handle 7 is entirely different from A’s object handle 7. Of course, since B1 is an SO session, it cannot create private objects, and so O2 must be a public object (if B1 attempted to create a private object, the attempt would fail with error code CKR_USER_NOT_LOGGED_IN or CKR_TEMPLATE_INCONSISTENT). with [B’s] object handle 7. This modifies O2.

15. B2使用session B7对对象句柄为B7的对象执行一些修改操作丆对象O2将被修改丟 16. A1 uses [A’s] session 4 to perform an object search operation to get

a handle for O2. The search returns object handle 1. Note that A’s object handle 1 and B’s object handle 7 now point to the same object.

16. A1使用session A4执行对象搜索操作来获得O2的句柄丆获得的对象句柄为1?C现在A的句柄1和B的句柄7指向同一个对象丟

June 2004

Copyright ? 2004 RSA Security Inc.

26

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD

17. A1 attempts to use [A’s] session 4 to modify the object associated with [A’s] object

handle 1. The attempt fails, because A’s session 4 is a R/O session, and is therefore incapable of modifying O2, which is a token object. A1 receives an error message indicating that the session is a R/O session (CKR_SESSION_READ_ONLY).
17. A1尝试使用session A4修改句柄为1的对象丆由于session A4是一个RO session?C不能修改token object O2?C因此操作失败丟 18. A1 uses [A’s] session 7 to modify the object associated with [A’s] object handle 1.

This time, since A’s session 7 is a R/W session, the attempt succeeds in modifying O2.
18. A1用session A7修改句柄为1的对象丆因为session A7是RW session?C所以能够成功修改对象O2?G 19. B1 uses [B’s] session 7 to perform an object search operation to find O1. Since

O1 is

a session object belonging to A, however, the search does not succeed.
19. B1使用session B7执行对象搜索操作查找O1?C由于O1是属于A的session对象丆因此查找失败丟 20. A2 uses [A’s] session 4 to perform some operation to modify the object associated

with [A’s] object handle 7. This operation modifies O1.
20. A2使用session A4修改对象句柄为A7的对象丆这个操作可以修改O1?G 21. A2 uses [A’s] session 7 to destroy the object associated with [A’s] object handle 1.

This destroys O2.
21. A2使用session A7销毁句柄为A1的对象丆这将销毁对象O2?G 22. B1 attempts to perform some operation with

the object associated with [B’s] object handle 7. The attempt fails, since there is no longer any such object. B1 receives an error message indicating that its object handle is invalid (CKR_OBJECT_HANDLE_INVALID). session, and turns A’s session 7 into a R/W public session.

22. B1尝试对句柄为B7的对象执行一些操作丆由于这个对象已经不存在了丆因此操作失败丟 23. A1 logs out [A’s] session 4. This turns A’s session 4 into a R/O public

23. A1登出session A4?C导致session A4成为RO public session?C同时session A7也会成为RW public session?G 24. A1 closes [A’s] session 7. This destroys the session object O1, which was created by

A’s session 7.
24. A1关闭session A7?C这将销毁由session A7建立的session对象O1?G 25. A2 attempt to use [A’s] session 4 to perform

some operation with the object associated with [A’s] object handle 7. The attempt fails, since there is no longer any such object. It returns a CKR_OBJECT_HANDLE_INVALID.

25. A2尝试用session A4对句柄为A7的对象执行一些操作丆因为这个对象已经不存在了丆操作失败丟 26. A2 executes a call to C_CloseAllSessions. This closes [A’s] session 4. At this point,

if A were to open a new session, the session would not be logged in (i.e., it would be a public session).
26. A2执行调用 C_CloseAllSessions?C这将关闭session A4?C这时丆如果A打开了一个新的session?C它将不会被登录丟 27. B2 closes [B’s] session 7. At this point, if B were to open a new session, the session

would not be logged in.
27. B2关闭session B7?C这时丆如果B打开了一个新的session?C它将不会被登录丟 28. A and B each call C_Finalize to indicate that they are done 28. A、B各自调用C_Finalize结束。

with the Cryptoki library.

6.8 Note:

Secondary authentication (Deprecated) This support may be present for backwards compatibility. Refer to PKCS11 V 2.11 for details.

Copyright ? 2004 RSA Security Inc.

June 2004

6. GENERAL OVERVIEW 6.9 Function overview

27

The Cryptoki API consists of a number of functions, spanning slot and token management and object management, as well as cryptographic functions. These functions are presented in the following table: Table 8, Summary of Cryptoki Functions Category General purpose functions Function C_Initialize C_Finalize C_GetInfo C_GetFunctionList Slot and token management functions C_GetSlotList C_GetSlotInfo C_GetTokenInfo C_WaitForSlotEvent C_GetMechanismList C_GetMechanismInfo C_InitToken C_InitPIN C_SetPIN C_OpenSession Description initializes Cryptoki clean up miscellaneous Cryptokiassociated resources obtains general information about Cryptoki obtains entry points of Cryptoki library functions obtains a list of slots in the system obtains information about a particular slot obtains information about a particular token waits for a slot event (token insertion, removal, etc.) to occur obtains a list of mechanisms supported by a token obtains information about a particular mechanism initializes a token initializes the normal user’s PIN modifies the PIN of the current user opens a connection between an application and a particular token or sets up an application callback for token insertion closes a session closes all sessions with a token obtains information about the session obtains the cryptographic operations state of a session sets the cryptographic operations state of a session logs into a token logs out from a token

Session management functions

C_CloseSession C_CloseAllSessions C_GetSessionInfo C_GetOperationState C_SetOperationState C_Login C_Logout

June 2004

Copyright ? 2004 RSA Security Inc.

28 Category Object management functions

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD Function C_CreateObject C_CopyObject C_DestroyObject C_GetObjectSize C_GetAttributeValue C_SetAttributeValue C_FindObjectsInit C_FindObjects C_FindObjectsFinal C_EncryptInit C_Encrypt C_EncryptUpdate C_EncryptFinal Description creates an object creates a copy of an object destroys an object obtains the size of an object in bytes obtains an attribute value of an object modifies an attribute value of an object initializes an object search operation continues an object search operation finishes an object search operation initializes an encryption operation encrypts single-part data continues a multiple-part encryption operation finishes a multiple-part encryption operation initializes a decryption operation decrypts single-part encrypted data continues a multiple-part decryption operation finishes a multiple-part decryption operation initializes a message-digesting operation digests single-part data continues a multiple-part digesting operation digests a key finishes a multiple-part digesting operation

Encryption functions

Decryption functions

C_DecryptInit C_Decrypt C_DecryptUpdate C_DecryptFinal

Message digesting functions

C_DigestInit C_Digest C_DigestUpdate C_DigestKey C_DigestFinal

Copyright ? 2004 RSA Security Inc.

June 2004

6. GENERAL OVERVIEW Category Signing and MACing functions Function C_SignInit C_Sign C_SignUpdate C_SignFinal C_SignRecoverInit C_SignRecover Functions for verifying signatures and MACs C_VerifyInit C_Verify C_VerifyUpdate C_VerifyFinal C_VerifyRecoverInit C_VerifyRecover

29 Description initializes a signature operation signs single-part data continues a multiple-part signature operation finishes a multiple-part signature operation initializes a signature operation, where the data can be recovered from the signature signs single-part data, where the data can be recovered from the signature initializes a verification operation verifies a signature on single-part data continues a multiple-part verification operation finishes a multiple-part verification operation initializes a verification operation where the data is recovered from the signature verifies a signature on single-part data, where the data is recovered from the signature continues simultaneous multiple-part digesting and encryption operations continues simultaneous multiple-part decryption and digesting operations continues simultaneous multiple-part signature and encryption operations continues simultaneous multiple-part decryption and verification operations generates a secret key generates a public-key/private-key pair wraps (encrypts) a key unwraps (decrypts) a key derives a key from a base key

Dual-purpose cryptographic functions

C_DigestEncryptUpdate C_DecryptDigestUpdate C_SignEncryptUpdate C_DecryptVerifyUpdate

Key management functions

C_GenerateKey C_GenerateKeyPair C_WrapKey C_UnwrapKey C_DeriveKey

June 2004

Copyright ? 2004 RSA Security Inc.

30 Category Random number generation functions Parallel function management functions Callback function

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD Function C_SeedRandom Description mixes in additional seed material to the random number generator generates random data legacy function which always returns CKR_FUNCTION_NOT_PARALLEL legacy function which always returns CKR_FUNCTION_NOT_PARALLEL application-supplied function to process notifications from Cryptoki

C_GenerateRandom C_GetFunctionStatus

C_CancelFunction

7

Security considerations

As an interface to cryptographic devices, Cryptoki provides a basis for security in a computer or communications system. Two of the particular features of the interface that facilitate such security are the following: 1. Access to private objects on the token, and possibly to cryptographic functions and/or certificates on the token as well, requires a PIN. Thus, possessing the cryptographic device that implements the token may not be sufficient to use it; the PIN may also be needed. 要同时持有加密设备和PIN才能使用设备上的功能 2. Additional protection can be given to private keys and secret keys by marking them as “sensitive” or “unextractable”. Sensitive keys cannot be revealed in plaintext off the token, and unextractable keys cannot be revealed off the token even when encrypted (though they can still be used as keys). It is expected that access to private, sensitive, or unextractable objects by means other than Cryptoki (e.g., other programming interfaces, or reverse engineering of the device) would be difficult. 期望通过Cryptoki以外的接口来访问敏感对象是非常困难的 If a device does not have a tamper-proof environment or protected memory in which to store private and sensitive objects, the device may encrypt the objects with a master key which is perhaps derived from the user’s PIN. The particular mechanism for protecting private objects is left to the device implementation, however. Based on these features it should be possible to design applications in such a way that the token can provide adequate security for the objects the applications manage. Of course, cryptography is only one element of security, and the token is only one component in a system. While the token itself may be secure, one must also consider the security of the operating system by which the application interfaces to it, especially since the PIN may be passed through the operating system. This can make it easy for a rogue

对私钥和密钥的额外保护丆将他们标记为“敏感”或“不可提取”丆 前者不能以文本形式暴露于token外丆后者即使加密后也不能暴露于token外

Copyright ? 2004 RSA Security Inc.

June 2004

8. PLATFORM- AND COMPILER-DEPENDENT DIRECTIVES FOR C OR C++ application on the operating system to obtain the PIN; it is also possible that other devices monitoring communication lines to the cryptographic device can obtain the PIN. Rogue applications and devices may also change the commands sent to the cryptographic device to obtain services other than what the application requested. It is important to be sure that the system is secure against such attack. Cryptoki may well play a role here; for instance, a token may be involved in the “booting up” of the system. We note that none of the attacks just described can compromise keys marked “sensitive,” since a key that is sensitive will always remain sensitive. Similarly, a key that is unextractable cannot be modified to be extractable. An application may also want to be sure that the token is “legitimate” in some sense (for a variety of reasons, including export restrictions and basic security). This is outside the scope of the present standard, but it can be achieved by distributing the token with a built-in, certified public/private-key pair, by which the token can prove its identity. The certificate would be signed by an authority (presumably the one indicating that the token is “legitimate”) whose public key is known to the application. The application would verify the certificate and challenge the token to prove its identity by signing a timevarying message with its built-in private key. Once a normal user has been authenticated to the token, Cryptoki does not restrict which cryptographic operations the user may perform; the user may perform any operation supported by the token. Some tokens may not even require any type of authentication to make use of its cryptographic functions.

31

8

Platform- and compiler-dependent directives for C or C++

There is a large array of Cryptoki-related data types which are defined in the Cryptoki header files. Certain packing- and pointer-related aspects of these types are platform- and compiler-dependent; these aspects are therefore resolved on a platform-by-platform (or compiler-by-compiler) basis outside of the Cryptoki header files by means of preprocessor directives. This means that when writing C or C++ code, certain preprocessor directives must be issued before including a Cryptoki header file. These directives are described in the remainder of Section 8. 8.1 Structure packing

Cryptoki structures are packed to occupy as little space as is possible. In particular, on the Win32 and Win16 platforms, Cryptoki structures should be packed with 1-byte alignment. In a UNIX environment, it may or may not be necessary (or even possible) to alter the byte-alignment of structures.

June 2004

Copyright ? 2004 RSA Security Inc.

32 8.2

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD Pointer-related macros

Because different platforms and compilers have different ways of dealing with different types of pointers, Cryptoki requires the following 6 macros to be set outside the scope of Cryptoki: ? CK_PTR

指针

CK_PTR is the “indirection string” a given platform and compiler uses to make a pointer to an object. It is used in the following fashion: typedef CK_BYTE CK_PTR CK_BYTE_PTR; ? CK_DEFINE_FUNCTION
函数定义

CK_DEFINE_FUNCTION(returnType, name), when followed by a parenthesesenclosed list of arguments and a function definition, defines a Cryptoki API function in a Cryptoki library. returnType is the return type of the function, and name is its name. It is used in the following fashion: CK_DEFINE_FUNCTION(CK_RV, C_Initialize)( CK_VOID_PTR pReserved ) { ... } ? CK_DECLARE_FUNCTION
函数声明

CK_DECLARE_FUNCTION(returnType, name), when followed by a parenthesesenclosed list of arguments and a semicolon, declares a Cryptoki API function in a Cryptoki library. returnType is the return type of the function, and name is its name. It is used in the following fashion: CK_DECLARE_FUNCTION(CK_RV, C_Initialize)( CK_VOID_PTR pReserved ); ? CK_DECLARE_FUNCTION_POINTER
函数指针声明

CK_DECLARE_FUNCTION_POINTER(returnType, name), when followed by a parentheses-enclosed list of arguments and a semicolon, declares a variable or type which is a pointer to a Cryptoki API function in a Cryptoki library. returnType is the return type of the function, and name is its name. It can be used in either of the following fashions to define a function pointer variable, myC_Initialize, which can point to a C_Initialize function in a Cryptoki library (note that neither of the following code snippets actually assigns a value to myC_Initialize):

Copyright ? 2004 RSA Security Inc.

June 2004

8. PLATFORM- AND COMPILER-DEPENDENT DIRECTIVES FOR C OR C++ CK_DECLARE_FUNCTION_POINTER(CK_RV, myC_Initialize)( CK_VOID_PTR pReserved ); or: typedef CK_DECLARE_FUNCTION_POINTER(CK_RV, myC_InitializeType)( CK_VOID_PTR pReserved ); myC_InitializeType myC_Initialize; ? CK_CALLBACK_FUNCTION

33

回调函数指针声明

CK_CALLBACK_FUNCTION(returnType, name), when followed by a parentheses-enclosed list of arguments and a semicolon, declares a variable or type which is a pointer to an application callback function that can be used by a Cryptoki API function in a Cryptoki library. returnType is the return type of the function, and name is its name. It can be used in either of the following fashions to define a function pointer variable, myCallback, which can point to an application callback which takes arguments args and returns a CK_RV (note that neither of the following code snippets actually assigns a value to myCallback): CK_CALLBACK_FUNCTION(CK_RV, myCallback)(args); or: typedef CK_CALLBACK_FUNCTION(CK_RV, myCallbackType)(args); myCallbackType myCallback; ? NULL_PTR NULL_PTR is the value of a NULL pointer. In any ANSI C environment—and in many others as well—NULL_PTR should be defined simply as 0. 8.3 8.3.1 Sample platform- and compiler-dependent code Win32

Developers using Microsoft Developer Studio 5.0 to produce C or C++ code which implements or makes use of a Win32 Cryptoki .dll might issue the following directives before including any Cryptoki header files: #pragma pack(push, cryptoki, 1) #define CK_IMPORT_SPEC __declspec(dllimport)
June 2004 Copyright ? 2004 RSA Security Inc.

34

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD

/* Define CRYPTOKI_EXPORTS during the build of cryptoki * libraries. Do not define it in applications. */ #ifdef CRYPTOKI_EXPORTS #define CK_EXPORT_SPEC __declspec(dllexport) #else #define CK_EXPORT_SPEC CK_IMPORT_SPEC #endif /* Ensures the calling convention for Win32 builds */ #define CK_CALL_SPEC __cdecl #define CK_PTR * #define CK_DEFINE_FUNCTION(returnType, name) \ returnType CK_EXPORT_SPEC CK_CALL_SPEC name #define CK_DECLARE_FUNCTION(returnType, name) \ returnType CK_EXPORT_SPEC CK_CALL_SPEC name #define CK_DECLARE_FUNCTION_POINTER(returnType, name) \ returnType CK_IMPORT_SPEC (CK_CALL_SPEC CK_PTR name) #define CK_CALLBACK_FUNCTION(returnType, name) \ returnType (CK_CALL_SPEC CK_PTR name) #ifndef NULL_PTR #define NULL_PTR 0 #endif Hence the calling convention for all C_xxx functions should correspond to "cdecl" where function parameters are passed from right to left and the caller removes parameters from the stack when the call returns. After including any Cryptoki header files, they might issue the following directives to reset the structure packing to its earlier value: #pragma pack(pop, cryptoki) 8.3.2 Win16

Developers using a pre-5.0 version of Microsoft Developer Studio to produce C or C++ code which implements or makes use of a Win16 Cryptoki .dll might issue the following directives before including any Cryptoki header files: #pragma pack(1) #define CK_PTR far *

Copyright ? 2004 RSA Security Inc.

June 2004

8. PLATFORM- AND COMPILER-DEPENDENT DIRECTIVES FOR C OR C++

35

#define CK_DEFINE_FUNCTION(returnType, name) \ returnType __export _far _pascal name #define CK_DECLARE_FUNCTION(returnType, name) \ returnType __export _far _pascal name #define CK_DECLARE_FUNCTION_POINTER(returnType, name) \ returnType __export _far _pascal (* name) #define CK_CALLBACK_FUNCTION(returnType, name) \ returnType _far _pascal (* name) #ifndef NULL_PTR #define NULL_PTR 0 #endif 8.3.3 Generic UNIX

Developers performing generic UNIX development might issue the following directives before including any Cryptoki header files: #define CK_PTR * #define CK_DEFINE_FUNCTION(returnType, name) \ returnType name #define CK_DECLARE_FUNCTION(returnType, name) \ returnType name #define CK_DECLARE_FUNCTION_POINTER(returnType, name) \ returnType (* name) #define CK_CALLBACK_FUNCTION(returnType, name) \ returnType (* name) #ifndef NULL_PTR #define NULL_PTR 0 #endif

June 2004

Copyright ? 2004 RSA Security Inc.

36

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD

9

General data types

The general Cryptoki data types are described in the following subsections. The data types for holding parameters for various mechanisms, and the pointers to those parameters, are not described here; these types are described with the information on the mechanisms themselves, in Section 12. A C or C++ source file in a Cryptoki application or library can define all these types (the types described here and the types that are specifically used for particular mechanism parameters) by including the top-level Cryptoki include file, pkcs11.h. pkcs11.h, in turn, includes the other Cryptoki include files, pkcs11t.h and pkcs11f.h. A source file can also include just pkcs11t.h (instead of pkcs11.h); this defines most (but not all) of the types specified here. When including either of these header files, a source file must specify the preprocessor directives indicated in Section 8. 9.1 General information

Cryptoki represents general information with the following types: ? CK_VERSION; CK_VERSION_PTR CK_VERSION is a structure that describes the version of a Cryptoki interface, a Cryptoki library, or an SSL implementation, or the hardware or firmware version of a slot or token. It is defined as follows: typedef struct CK_VERSION { CK_BYTE major; CK_BYTE minor; } CK_VERSION; The fields of the structure have the following meanings: major minor major version number (the integer portion of the version) minor version number (the hundredths portion of the version)

Example: For version 1.0, major = 1 and minor = 0. For version 2.10, major = 2 and minor = 10. Table 9 below lists the major and minor version values for the officially published Cryptoki specifications.

Copyright ? 2004 RSA Security Inc.

June 2004

9. GENERAL DATA TYPES Table 9, Major and minor version values for published Cryptoki specifications Version 1.0 2.01 2.10 2.11 2.20 major 0x01 0x02 0x02 0x02 0x02 minor 0x00 0x01 0x0a 0x0b 0x14

37

Minor revisions of the Cryptoki standard are always upwardly compatible within the same major version number. CK_VERSION_PTR is a pointer to a CK_VERSION. ? CK_INFO; CK_INFO_PTR CK_INFO provides general information about Cryptoki. It is defined as follows: typedef struct CK_INFO { CK_VERSION cryptokiVersion; CK_UTF8CHAR manufacturerID[32]; CK_FLAGS flags; CK_UTF8CHAR libraryDescription[32]; CK_VERSION libraryVersion; } CK_INFO; The fields of the structure have the following meanings: cryptokiVersion manufacturerID Cryptoki interface version number, for compatibility with future revisions of this interface ID of the Cryptoki library manufacturer. Must be padded with the blank character (‘ ‘). Should not be null-terminated. bit flags reserved for future versions. Must be zero for this version character-string description of the library. Must be padded with the blank character (‘ ‘). Should not be null-terminated. Cryptoki library version number

flags libraryDescription

libraryVersion

June 2004

Copyright ? 2004 RSA Security Inc.

38

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD

For libraries written to this document, the value of cryptokiVersion should match the version of this document; the value of libraryVersion is the version number of the library software itself. CK_INFO_PTR is a pointer to a CK_INFO. ? CK_NOTIFICATION CK_NOTIFICATION holds the types of notifications that Cryptoki provides to an application. It is defined as follows: typedef CK_ULONG CK_NOTIFICATION; For this version of Cryptoki, the following types of notifications are defined: CKN_SURRENDER The notifications have the following meanings: CKN_SURRENDER Cryptoki is surrendering the execution of a function executing in a session so that the application may perform other operations. After performing any desired operations, the application should indicate to Cryptoki whether to continue or cancel the function (see Section 11.17.1).

9.2

Slot and token types

Cryptoki represents slot and token information with the following types: ? CK_SLOT_ID; CK_SLOT_ID_PTR CK_SLOT_ID is a Cryptoki-assigned value that identifies a slot. follows: typedef CK_ULONG CK_SLOT_ID; A list of CK_SLOT_IDs is returned by C_GetSlotList. A priori, any value of CK_SLOT_ID can be a valid slot identifier—in particular, a system may have a slot identified by the value 0. It need not have such a slot, however. CK_SLOT_ID_PTR is a pointer to a CK_SLOT_ID. It is defined as

Copyright ? 2004 RSA Security Inc.

June 2004

9. GENERAL DATA TYPES ? CK_SLOT_INFO; CK_SLOT_INFO_PTR CK_SLOT_INFO provides information about a slot. It is defined as follows: typedef struct CK_SLOT_INFO { CK_UTF8CHAR slotDescription[64]; CK_UTF8CHAR manufacturerID[32]; CK_FLAGS flags; CK_VERSION hardwareVersion; CK_VERSION firmwareVersion; } CK_SLOT_INFO; The fields of the structure have the following meanings: slotDescription character-string description of the slot. Must be padded with the blank character (‘ ‘). Should not be null-terminated.

39

manufacturerID flags hardwareVersion firmwareVersion

ID of the slot manufacturer. Must be padded with the blank character (‘ ‘). Should not be null-terminated. bits flags that provide capabilities of the slot. The flags are defined below version number of the slot’s hardware version number of the slot’s firmware

The following table defines the flags field: Table 10, Slot Information Flags Bit Flag CKF_TOKEN_PRESENT CKF_REMOVABLE_DEVICE CKF_HW_SLOT Mask Meaning 0x00000001 True if a token is present in the slot (e.g., a device is in the reader) 0x00000002 True if the reader supports removable devices 0x00000004 True if the slot is a hardware slot, as opposed to a software slot implementing a “soft token”

For a given slot, the value of the CKF_REMOVABLE_DEVICE flag never changes. In addition, if this flag is not set for a given slot, then the CKF_TOKEN_PRESENT flag for that slot is always set. That is, if a slot does not support a removable device, then that slot always has a token in it. CK_SLOT_INFO_PTR is a pointer to a CK_SLOT_INFO.

June 2004

Copyright ? 2004 RSA Security Inc.

40

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD

? CK_TOKEN_INFO; CK_TOKEN_INFO_PTR CK_TOKEN_INFO provides information about a token. It is defined as follows: typedef struct CK_TOKEN_INFO { CK_UTF8CHAR label[32]; CK_UTF8CHAR manufacturerID[32]; CK_UTF8CHAR model[16]; CK_CHAR serialNumber[16]; CK_FLAGS flags; CK_ULONG ulMaxSessionCount; CK_ULONG ulSessionCount; CK_ULONG ulMaxRwSessionCount; CK_ULONG ulRwSessionCount; CK_ULONG ulMaxPinLen; CK_ULONG ulMinPinLen; CK_ULONG ulTotalPublicMemory; CK_ULONG ulFreePublicMemory; CK_ULONG ulTotalPrivateMemory; CK_ULONG ulFreePrivateMemory; CK_VERSION hardwareVersion; CK_VERSION firmwareVersion; CK_CHAR utcTime[16]; } CK_TOKEN_INFO; The fields of the structure have the following meanings: label application-defined label, assigned during token initialization. Must be padded with the blank character (‘ ‘). Should not be null-terminated. ID of the device manufacturer. Must be padded with the blank character (‘ ‘). Should not be nullterminated. model of the device. Must be padded with the blank character (‘ ‘). Should not be null-terminated. character-string serial number of the device. Must be padded with the blank character (‘ ‘). Should not be null-terminated. bit flags indicating capabilities and status of the device as defined below maximum number of sessions that can be opened with the token at one time by a single application (see note below)

manufacturerID

model serialNumber

flags ulMaxSessionCount

Copyright ? 2004 RSA Security Inc.

June 2004

9. GENERAL DATA TYPES ulSessionCount ulMaxRwSessionCount

41 number of sessions that this application currently has open with the token (see note below) maximum number of read/write sessions that can be opened with the token at one time by a single application (see note below) number of read/write sessions that this application currently has open with the token (see note below) maximum length in bytes of the PIN minimum length in bytes of the PIN the total amount of memory on the token in bytes in which public objects may be stored (see note below) the amount of free (unused) memory on the token in bytes for public objects (see note below) the total amount of memory on the token in bytes in which private objects may be stored (see note below) the amount of free (unused) memory on the token in bytes for private objects (see note below) version number of hardware version number of firmware current time as a character-string of length 16, represented in the format YYYYMMDDhhmmssxx (4 characters for the year; 2 characters each for the month, the day, the hour, the minute, and the second; and 2 additional reserved ‘0’ characters). The value of this field only makes sense for tokens equipped with a clock, as indicated in the token information flags (see below)

ulRwSessionCount ulMaxPinLen ulMinPinLen ulTotalPublicMemory ulFreePublicMemory ulTotalPrivateMemory ulFreePrivateMemory hardwareVersion firmwareVersion utcTime

June 2004

Copyright ? 2004 RSA Security Inc.

42

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD

The following table defines the flags field: Table 11, Token Information Flags Bit Flag CKF_RNG Mask Meaning 0x00000001 True if the token has its own random number generator 0x00000002 True if the token is write-protected (see below) 0x00000004 True if there are some cryptographic functions that a user must be logged in to perform 0x00000008 True if the normal user’s PIN has been initialized 0x00000020 True if a successful save of a session’s cryptographic operations state always contains all keys needed to restore the state of the session 0x00000040 True if token has its own hardware clock 0x00000100 True if token has a “protected authentication path”, whereby a user can log into the token without passing a PIN through the Cryptoki library

CKF_WRITE_PROTECTED

CKF_LOGIN_REQUIRED

CKF_USER_PIN_INITIALIZED

CKF_RESTORE_KEY_NOT_NEEDED

CKF_CLOCK_ON_TOKEN

CKF_PROTECTED_AUTHENTICATION_PATH

Copyright ? 2004 RSA Security Inc.

June 2004

9. GENERAL DATA TYPES Bit Flag CKF_DUAL_CRYPTO_OPERATIONS

43 Mask Meaning 0x00000200 True if a single session with the token can perform dual cryptographic operations (see Section 11.13) 0x00000400 True if the token has been initialized using C_InitializeToken or an equivalent mechanism outside the scope of this standard. Calling C_InitializeToken when this flag is set will cause the token to be reinitialized. 0x00000800 True if the token supports secondary authentication for private key objects. (Deprecated; new implementations MUST NOT set this flag) 0x00010000 True if an incorrect user login PIN has been entered at least once since the last successful authentication. 0x00020000 True if supplying an incorrect user PIN will it to become locked.

CKF_TOKEN_INITIALIZED

CKF_SECONDARY_AUTHENTICATION

CKF_USER_PIN_COUNT_LOW

CKF_USER_PIN_FINAL_TRY

June 2004

Copyright ? 2004 RSA Security Inc.

44

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD Mask Meaning 0x00040000 True if the user PIN has been locked. User login to the token is not possible. 0x00080000 True if the user PIN value is the default value set by token initialization or manufacturing, or the PIN has been expired by the card. 0x00100000 True if an incorrect SO login PIN has been entered at least once since the last successful authentication. 0x00200000 True if supplying an incorrect SO PIN will it to become locked. 0x00400000 True if the SO PIN has been locked. User login to the token is not possible. 0x00800000 True if the SO PIN value is the default value set by token initialization or manufacturing, or the PIN has been expired by the card.

Bit Flag CKF_USER_PIN_LOCKED

CKF_USER_PIN_TO_BE_CHANGED

CKF_SO_PIN_COUNT_LOW

CKF_SO_PIN_FINAL_TRY

CKF_SO_PIN_LOCKED

CKF_SO_PIN_TO_BE_CHANGED

Exactly what the CKF_WRITE_PROTECTED flag means is not specified in Cryptoki. An application may be unable to perform certain actions on a write-protected token; these actions can include any of the following, among others: ? Creating/modifying/deleting any object on the token.
June 2004

Copyright ? 2004 RSA Security Inc.

9. GENERAL DATA TYPES ? ? ? Creating/modifying/deleting a token object on the token. Changing the SO’s PIN. Changing the normal user’s PIN.

45

The token may change the value of the CKF_WRITE_PROTECTED flag depending on the session state to implement its object management policy. For instance, the token may set the CKF_WRITE_PROTECTED flag unless the session state is R/W SO or R/W User to implement a policy that does not allow any objects, public or private, to be created, modified, or deleted unless the user has successfully called C_Login. The CKF_USER_PIN_COUNT_LOW, CKF_USER_PIN_COUNT_LOW, CKF_USER_PIN_FINAL_TRY, and CKF_SO_PIN_FINAL_TRY flags may always be set to false if the token does not support the functionality or will not reveal the information because of its security policy. The CKF_USER_PIN_TO_BE_CHANGED and CKF_SO_PIN_TO_BE_CHANGED flags may always be set to false if the token does not support the functionality. If a PIN is set to the default value, or has expired, the appropriate CKF_USER_PIN_TO_BE_CHANGED or CKF_SO_PIN_TO_BE_CHANGED flag is set to true. When either of these flags are true, logging in with the corresponding PIN will succeed, but only the C_SetPIN function can be called. Calling any other function that required the user to be logged in will cause CKR_PIN_EXPIRED to be returned until C_SetPIN is called successfully. Note: The fields ulMaxSessionCount, ulSessionCount, ulMaxRwSessionCount, ulRwSessionCount, ulTotalPublicMemory, ulFreePublicMemory, ulTotalPrivateMemory, and ulFreePrivateMemory can have the special value CK_UNAVAILABLE_INFORMATION, which means that the token and/or library is unable or unwilling to provide that information. In addition, the fields ulMaxSessionCount and ulMaxRwSessionCount can have the special value CK_EFFECTIVELY_INFINITE, which means that there is no practical limit on the number of sessions (resp. R/W sessions) an application can have open with the token. It is important to check these fields for these special values. This is particularly true for CK_EFFECTIVELY_INFINITE, since an application seeing this value in the ulMaxSessionCount or ulMaxRwSessionCount field would otherwise conclude that it can’t open any sessions with the token, which is far from being the case. The upshot of all this is that the correct way to interpret (for example) the ulMaxSessionCount field is something along the lines of the following: CK_TOKEN_INFO info; . . if ((CK_LONG) info.ulMaxSessionCount

June 2004

Copyright ? 2004 RSA Security Inc.

46

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD == CK_UNAVAILABLE_INFORMATION) { /* Token refuses to give value of ulMaxSessionCount */ . . } else if (info.ulMaxSessionCount == CK_EFFECTIVELY_INFINITE) { /* Application can open as many sessions as it wants */ . . } else { /* ulMaxSessionCount really does contain what it should */ . . }

CK_TOKEN_INFO_PTR is a pointer to a CK_TOKEN_INFO. 9.3 Session types

Cryptoki represents session information with the following types: ? CK_SESSION_HANDLE; CK_SESSION_HANDLE_PTR CK_SESSION_HANDLE is a Cryptoki-assigned value that identifies a session. It is defined as follows: typedef CK_ULONG CK_SESSION_HANDLE; Valid session handles in Cryptoki always have nonzero values. convenience, Cryptoki defines the following symbolic value: CK_INVALID_HANDLE CK_SESSION_HANDLE_PTR is a pointer to a CK_SESSION_HANDLE. ? CK_USER_TYPE CK_USER_TYPE holds the types of Cryptoki users described in Section 6.5, and, in addition, a context-specific type described in Section 10.9. It is defined as follows: typedef CK_ULONG CK_USER_TYPE; For developers’

Copyright ? 2004 RSA Security Inc.

June 2004

9. GENERAL DATA TYPES For this version of Cryptoki, the following types of users are defined: CKU_SO CKU_USER CKU_CONTEXT_SPECIFIC ? CK_STATE

47

CK_STATE holds the session state, as described in Sections 6.7.1 and 6.7.2. It is defined as follows: typedef CK_ULONG CK_STATE; For this version of Cryptoki, the following session states are defined: CKS_RO_PUBLIC_SESSION CKS_RO_USER_FUNCTIONS CKS_RW_PUBLIC_SESSION CKS_RW_USER_FUNCTIONS CKS_RW_SO_FUNCTIONS ? CK_SESSION_INFO; CK_SESSION_INFO_PTR CK_SESSION_INFO provides information about a session. It is defined as follows: typedef struct CK_SESSION_INFO { CK_SLOT_ID slotID; CK_STATE state; CK_FLAGS flags; CK_ULONG ulDeviceError; } CK_SESSION_INFO; The fields of the structure have the following meanings: slotID state flags ulDeviceError ID of the slot that interfaces with the token the state of the session bit flags that define the type of session; the flags are defined below an error code defined by the cryptographic device. Used for errors not covered by Cryptoki.

June 2004

Copyright ? 2004 RSA Security Inc.

48

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD

The following table defines the flags field: Table 12, Session Information Flags Bit Flag CKF_RW_SESSION CKF_SERIAL_SESSION Mask Meaning 0x00000002 True if the session is read/write; false if the session is read-only 0x00000004 This flag is provided for backward compatibility, and should always be set to true

CK_SESSION_INFO_PTR is a pointer to a CK_SESSION_INFO. 9.4 Object types

Cryptoki represents object information with the following types: ? CK_OBJECT_HANDLE; CK_OBJECT_HANDLE_PTR CK_OBJECT_HANDLE is a token-specific identifier for an object. It is defined as follows: typedef CK_ULONG CK_OBJECT_HANDLE; When an object is created or found on a token by an application, Cryptoki assigns it an object handle for that application’s sessions to use to access it. A particular object on a token does not necessarily have a handle which is fixed for the lifetime of the object; however, if a particular session can use a particular handle to access a particular object, then that session will continue to be able to use that handle to access that object as long as the session continues to exist, the object continues to exist, and the object continues to be accessible to the session. Valid object handles in Cryptoki always have nonzero values. convenience, Cryptoki defines the following symbolic value: CK_INVALID_HANDLE CK_OBJECT_HANDLE_PTR is a pointer to a CK_OBJECT_HANDLE. ? CK_OBJECT_CLASS; CK_OBJECT_CLASS_PTR CK_OBJECT_CLASS is a value that identifies the classes (or types) of objects that Cryptoki recognizes. It is defined as follows: typedef CK_ULONG CK_OBJECT_CLASS;
Copyright ? 2004 RSA Security Inc. June 2004

For developers’

9. GENERAL DATA TYPES

49

Object classes are defined with the objects that use them. The type is specified on an object through the CKA_CLASS attribute of the object. Vendor defined values for this type may also be specified. CKO_VENDOR_ DEFINED Object classes CKO_VENDOR_DEFINED and above are permanently reserved for token vendors. For interoperability, vendors should register their object classes through the PKCS process. CK_OBJECT_CLASS_PTR is a pointer to a CK_OBJECT_CLASS. ? CK_HW_FEATURE_TYPE CK_HW_FEATURE_TYPE is a value that identifies a hardware feature type of a device. It is defined as follows: typedef CK_ULONG CK_HW_FEATURE_TYPE; Hardware feature types are defined with the objects that use them. The type is specified on an object through the CKA_HW_FEATURE_TYPE attribute of the object. Vendor defined values for this type may also be specified. CKH_VENDOR_DEFINED Feature types CKH_VENDOR_DEFINED and above are permanently reserved for token vendors. For interoperability, vendors should register their feature types through the PKCS process. ? CK_KEY_TYPE CK_KEY_TYPE is a value that identifies a key type. It is defined as follows: typedef CK_ULONG CK_KEY_TYPE; Key types are defined with the objects and mechanisms that use them. The key type is specified on an object through the CKA_KEY_TYPE attribute of the object. Vendor defined values for this type may also be specified. CKK_VENDOR_DEFINED

June 2004

Copyright ? 2004 RSA Security Inc.

50

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD

Key types CKK_VENDOR_DEFINED and above are permanently reserved for token vendors. For interoperability, vendors should register their key types through the PKCS process. ? CK_CERTIFICATE_TYPE CK_CERTIFICATE_TYPE is a value that identifies a certificate type. It is defined as follows: typedef CK_ULONG CK_CERTIFICATE_TYPE; Certificate types are defined with the objects and mechanisms that use them. The certificate type is specified on an object through the CKA_CERTIFICATE_TYPE attribute of the object. Vendor defined values for this type may also be specified. CKC_VENDOR_DEFINED Certificate types CKC_VENDOR_DEFINED and above are permanently reserved for token vendors. For interoperability, vendors should register their certificate types through the PKCS process. ? CK_ATTRIBUTE_TYPE CK_ATTRIBUTE_TYPE is a value that identifies an attribute type. It is defined as follows: typedef CK_ULONG CK_ATTRIBUTE_TYPE; Attributes are defined with the objects and mechanisms that use them. Attributes are specified on an object as a list of type, length value items. These are often specified as an attribute template. Vendor defined values for this type may also be specified. CKA_VENDOR_DEFINED Attribute types CKA_VENDOR_DEFINED and above are permanently reserved for token vendors. For interoperability, vendors should register their attribute types through the PKCS process.

Copyright ? 2004 RSA Security Inc.

June 2004

9. GENERAL DATA TYPES ? CK_ATTRIBUTE; CK_ATTRIBUTE_PTR

51

CK_ATTRIBUTE is a structure that includes the type, value, and length of an attribute. It is defined as follows: typedef struct CK_ATTRIBUTE { CK_ATTRIBUTE_TYPE type; CK_VOID_PTR pValue; CK_ULONG ulValueLen; } CK_ATTRIBUTE; The fields of the structure have the following meanings: type pValue ulValueLen the attribute type pointer to the value of the attribute length in bytes of the value

If an attribute has no value, then ulValueLen = 0, and the value of pValue is irrelevant. An array of CK_ATTRIBUTEs is called a “template” and is used for creating, manipulating and searching for objects. The order of the attributes in a template never matters, even if the template contains vendor-specific attributes. Note that pValue is a “void” pointer, facilitating the passing of arbitrary values. Both the application and Cryptoki library must ensure that the pointer can be safely cast to the expected type (i.e., without word-alignment errors). CK_ATTRIBUTE_PTR is a pointer to a CK_ATTRIBUTE. ? CK_DATE CK_DATE is a structure that defines a date. It is defined as follows: typedef struct CK_DATE { CK_CHAR year[4]; CK_CHAR month[2]; CK_CHAR day[2]; } CK_DATE; The fields of the structure have the following meanings: year month day the year (“1900” - “9999”) the month (“01” - “12”) the day (“01” - “31”)

June 2004

Copyright ? 2004 RSA Security Inc.

52

PKCS #11 V2.20: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD

The fields hold numeric characters from the character set in Table 3, not the literal byte values. When a Cryptoki object carries an attribute of this type, and the default value of the attribute is specified to be "empty," then Cryptoki libraries shall set the attribute's ulValueLen to 0. Note that implementations of previous versions of Cryptoki may have used other methods to identify an "empty" attribute of type CK_DATE, and that applications that needs to interoperate with these libraries therefore have to be flexible in what they accept as an empty value. 9.5 Data types for mechanisms

Cryptoki supports the following types for describing mechanisms and parameters to them: ? CK_MECHANISM_TYPE; CK_MECHANISM_TYPE_PTR CK_MECHANISM_TYPE is a value that identifies a mechanism type. It is defined as follows: typedef CK_ULONG CK_MECHANISM_TYPE; Mechanism types are defined with the objects and mechanism descriptions that use them. Vendor defined values for this type may also be specified. CKM_VENDOR_DEFINED Mechanism types CKM_VENDOR_DEFINED and above are permanently reserved for token vendors. For interoperability, vendors should register their mechanism types through the PKCS process. CK_MECHANISM_TYPE_PTR is a pointer to a CK_MECHANISM_TYPE. ? CK_MECHANISM; CK_MECHANISM_PTR CK_MECHANISM is a structure that specifies a particular mechanism and any parameters it requires. It is defined as follows: typedef struct CK_MECHANISM { CK_MECHANISM_TYPE mechanism; CK_VOID_PTR pParameter; CK_ULONG ulParameterLen; } CK_MECHANISM;

Copyright ? 2004 RSA Security Inc.

June 2004

9. GENERAL DATA TYPES The fields of the structure have the following meanings: mechanism pParameter ulParameterLen the type of mechanism

53

pointer to the parameter if required by the mechanism length in bytes of the parameter

Note that pParameter is a “void” pointer, facilitating the passing of arbitrary values. Both the application and the Cryptoki library must ensure that the pointer can be safely cast to the expected type (i.e., without word-alignment errors). CK_MECHANISM_PTR is a pointer to a CK_MECHANISM. ? CK_MECHANISM_INFO; CK_MECHANISM_INFO_PTR CK_MECHANISM_INFO is a structure that provides information about a particular mechanism. It is defined as follows: typedef struct CK_MECHANISM_INFO { CK_ULONG ulMinKeySize; CK_ULONG ulMaxKeySize; CK_FLAGS flags; } CK_MECHANISM_INFO; The fields of the structure have the following meanings: ulMinKeySize the minimum size of the key for the mechanism (whether this is measured in bits or in bytes is mechanism-dependent) the maximum size of the key for the mechanism (whether this is measured in bits or in bytes is mechanism-dependent) bit flags specifying mechanism capabilities

ulMaxKeySize

flags

For some mechanisms, the ulMinKeySize and ulMaxKeySize f

相关文章:
cn-pkcs-10v1_7(认证请求语法标准)
20份文档 乘机安全小贴士 安全乘机指南 如何选择安全的航班 正确使用机上氧气...pkcs-7 30页 2下载券 pkcs_11v2.11中文标准 262页 1下载券喜欢...
更多相关标签: