安全协议与标准2009, 10 PKCS#11 and moreOverviewAPI Usage: SessionFunctions Summary Functions Detail/ExampleMechanisms: Algorithm, ProtocolComparison Implementation GSS-APIGCS-API CDSAMS-CAPI DEP OverviewIn cryptography, PKCS#11 is one of the family of standards called Public-Key Cryptography Standards (PKCS), published by RSA Laboratories. It defines a platform-independent API to cryptographic tokens, such as Hardware Security Modules and smart cards. (The PKCS#11 standard names the API Cryptoki, but is often used to refer to the API as well as the standard that defines it.)Since there isnt a real standard for cryptographic tokens, this API has been developed to be an abstraction layer for the generic cryptographic token. The PKCS#11 API defines most commonly used cryptographic object types (RSA keys, X.509 Certificates, DES/Triple DES keys, etc.) and all the functions needed to use, create/generate, modify and delete those objects. -PKCS#11 is largely adopted to access smart cards and HSMs. Most commercial Certification Authority software uses PKCS#11 to access the CA signing key or to enroll user certificates. Cross-platform software that needs to use smart cards uses PKCS#11, such as Mozilla Firefox and OpenSSL (using an extension). NSS(in Firefox)“pkcs-11v2-20.doc” BackgroundPortable 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 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. kaMemory cardSmart cardPCMCIA/CardBusUSB flash driveUSB KeyExpressCardPCI Express 口令之外口令登录指纹登录智能卡登录登录次数的限制PIN和lock功能SSO 其他生物识别认证技术 抽象：TokenThe 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 token is a device that stores objects and can perform cryptographic functions.（cryptoki是token的接口） General Cryptoki Model Object HierarchyCryptoki defines three classes of object UsersThis version of Cryptoki recognizes two token user types.One type is a Security Officer (SO).The other type is the normal user. The role of the SO is to initialize a token and to set the normal users PIN, and possibly to manipulate some public objects. 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. SessionCryptoki requires that an application open one or more sessions with a token to gain access to the tokens objects and functions. A session provides a logical connection between the application and the token. Cryptoki supports multiple sessions on multiple tokens. A session can be a read/write (R/W) session or a read-only (R/O) session. Session eventsSession events cause the session state to change. The following table describes the events:EventOccurs when.Log In SOthe SO is authenticated to the token.Log In Userthe normal user is authenticated to the token.Log Outthe application logs out the current user (SO or normal user).Close Sessionthe application closes the session or closes all sessions.Device Removed the device underlying the token has been removed from its slot. Read-Only Session States Read/Write Session States Access to Different Types Objects by Different Types of Sessions Type of sessionType of objectR/O PublicR/W PublicR/O UserR/W UserR/W SOPublic session objectR/WR/WR/WR/WR/WPrivate session objectR/WR/WPublic token objectR/OR/WR/OR/WR/WPrivate token objectR/OR/W with fork()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. if C needs to use Cryptoki, it needs to perform its own C_Initialize call. (and then C_Finalize after some other operations)if it has no need to use Cryptoki, it should immediately call C_Initialize and then call C_Finalize. with multi-threadCryptoki 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: Summary of Cryptoki Functions CategoryFunctionDescriptionGeneralpurposeFunctionsC_Initializeinitializes CryptokiC_Finalizeclean up miscellaneous Cryptoki-associated resourcesC_GetInfoobtains general information about CryptokiC_GetFunctionListobtains entry points of Cryptoki library functions Slot and token anagement functionsSlot andtokenmanagementfunctionsC_GetSlotListobtains a list of slots in the systemC_GetSlotInfoobtains information about a particular slotC_GetTokenInfoobtains information about a particular tokenC_WaitForSlotEventwaits for a slot event (token insertion, removal, etc.) to occurC_GetMechanismListobtains a list of mechanisms supported by a tokenC_GetMechanismInfoobtains information about a particular mechanismC_InitTokeninitializes a tokenC_InitPINinitializes the normal users PINC_SetPINmodifies the PIN of the current user Session Management FunctionsSession managementFunctionsC_OpenSessionopens a connection between an application and a particular token or sets up an application callback for token insertionC_CloseSessioncloses a sessionC_CloseAllSessionscloses all sessions with a tokenC_GetSessionInfoobtains information about the sessionC_GetOperationStateobtains the cryptographic operations state of a sessionC_SetOperationStatesets the cryptographic operations state of a sessionC_Loginlogs into a tokenC_Logoutlogs out from a token Object management functionsObjectmanagementfunctionsC_CreateObjectcreates an objectC_CopyObjectcreates a copy of an objectC_DestroyObjectdestroys an objectC_GetObjectSizeobtains the size of an object in bytesC_GetAttributeValueobtains an attribute value of an objectC_SetAttributeValuemodifies an attribute value of an objectC_FindObjectsInitinitializes an object search operationC_FindObjectscontinues an object search operationC_FindObjectsFinalfinishes an object search operation Encryption/Decryption functionsEncryptionfunctionsC_EncryptInitinitializes an encryption operationC_Encryptencrypts single-part dataC_EncryptUpdatecontinues a multiple-part encryption operationC_EncryptFinalfinishes a multiple-part encryption operationDecryptionfunctionsC_DecryptInitinitializes a decryption operationC_Decryptdecrypts single-part encrypted dataC_DecryptUpdatecontinues a multiple-part decryption operationC_DecryptFinalfinishes a multiple-part decryption operation Message digesting functionsMessagedigestingfunctionsC_DigestInitinitializes a message-digesting operationC_Digestdigests single-part dataC_DigestUpdatecontinues a multiple-part digesting operationC_DigestKeydigests a keyC_DigestFinalfinishes a multiple-part digesting operation Signing and MACing functionsSigningand MACingfunctionsC_SignInitinitializes a signature operationC_Signsigns single-part dataC_SignUpdatecontinues a multiple-part signature operationC_SignFinalfinishes a multiple-part signature operationC_SignRecoverInitinitializes a signature operation, where the data can be recovered from the signatureC_SignRecoversigns single-part data, where the data can be recovered from the signature Functions for verifying signatures and MACsFunctionsfor verifyingsignaturesand MACsC_VerifyInitinitializes a verification operationC_Verifyverifies a signature on single-part dataC_VerifyUpdatecontinues a multiple-part verification operationC_VerifyFinalfinishes a multiple-part verification operationC_VerifyRecoverInitinitializes a verification operation where the data is recovered from the signatureC_VerifyRecoververifies a signature on single-part data, where the data is recovered from the signature Dual-purpose cryptographic functionsDual-purposecryptographicfunctionsC_DigestEncryptUpdatecontinues simultaneous multiple-part digesting and encryption operationsC_DecryptDigestUpdatecontinues simultaneous multiple-part decryption and digesting operationsC_SignEncryptUpdatecontinues simultaneous multiple-part signature and encryption operationsC_DecryptVerifyUpdatecontinues simultaneous multiple-part decryption and verification operations Key management functionsKeymanagementfunctionsC_GenerateKeygenerates a secret keyC_GenerateKeyPairgenerates a public-key/private-key pairC_WrapKeywraps (encrypts) a keyC_UnwrapKeyunwraps (decrypts) a keyC_DeriveKeyderives a key from a base key Random number generation functionsRandomnumbergenerationfunctionsC_SeedRandommixes in additional seed material to the random number generatorC_GenerateRandomgenerates random data Parallel function management FunctionsParallel function managementFunctionsC_GetFunctionStatuslegacy function which always returns CKR_FUNCTION_NOT_PARALLELC_CancelFunctionlegacy function which always returns CKR_FUNCTION_NOT_PARALLEL Callback functionCallback functionapplication-supplied function to process notifications from Cryptoki Functions detailCK_DEFINE_FUNCTION(CK_RV, C_Initialize)( CK_VOID_PTR pInitArgs);CK_DEFINE_FUNCTION(CK_RV, C_Finalize)( CK_VOID_PTR pReserved); ExampleCK_INFO info;CK_RV rv;CK_C_INITIALIZE_ARGS InitArgs;InitArgs.CreateMutex = &MyCreateMutex;InitArgs.DestroyMutex = &MyDestroyMutex;InitArgs.LockMutex = &MyLockMutex;InitArgs.UnlockMutex = &MyUnlockMutex;InitArgs.flags = CKF_OS_LOCKING_OK;InitArgs.pReserved = NULL_PTR;rv = C_Initialize(CK_VOID_PTR)&InitArgs);assert(rv = CKR_OK);rv = C_GetInfo(&info);assert(rv = CKR_OK);if(info.version.major = 2) /* Do lots of interesting cryptographic things with the token */ . .rv = C_Finalize(NULL_PTR);assert(rv = CKR_OK); Mechanisms: AlgorithmRSA / DSA / EC / D-HKEA / Key derivation HMACRC2 / RC4 / RC5 / AES / 2/3DES / SKIPJACK / BATON / JUNIPER /Blowfish / Twofish MD2 / MD5 / SHA-1 / SHA-256 / SHA-384 / SHA-512 / FASTHASH / RIPE-MDPKCS#5 / PKCS#12 / LYNKS Mechanisms: ProtocolSETSSL / TLS / WTLSCMS Comparison of Cryptoki and other APIs:GCS-API vs. Cryptoki GCS-APICryptoki implementationretrieve_CCrelease_CCgenerate_hashC_DigestInit, C_Digestgenerate_random_numberC_GenerateRandomgenerate_checkvalueC_SignInit, C_Sign, C_SignUpdate, C_SignFinalverify_checkvalueC_VerifyInit, C_Verify, C_VerifyUpdate, C_VerifyFinaldata_encipherC_EncryptInit, C_Encrypt, C_EncryptUpdate, C_EncryptFinaldata_decipherC_DecryptInit, C_Decrypt, C_DecryptUpdate, C_DecryptFinal create_CCderive_keyC_DeriveKeygenerate_keyC_GenerateKeystore_CCdelete_CCreplicate_CCexport_keyC_WrapKeyimport_keyC_UnwrapKeyarchive_CCC_WrapKeyrestore_CCC_UnwrapKeyset_key_stategenerate_key_pattern verify_key_patternderive_clear_keyC_DeriveKeygenerate_clear_keyC_GenerateKeyload_key_partsclear_key_encipherC_WrapKeyclear_key_decipherC_UnwrapKeychange_key_contextload_initial_keygenerate_initial_keyset_current_master_keyprotect_under_new_master_keyprotect_under_current_master_key initialise_random_number_generatorC_SeedRandominstall_algorithmde_install_algorithmdisable_algorithmenable_algorithmset_defaults ImplementationPKCS#11 ProviderPKCS#11 Wrapper ImplementationopenCryptoki http:/sourceforge.net/projects/opencryptokiopenCryptoki is a PKCS#11 implementation for Linux. It includes drivers and libraries to enable IBM cryptographic hardware as well as a software token for testing. gpkcs11 http:/gpkcs11.sourceforge.net/ GNU implementation of PKCS#11 standard based on OpenSSL PKCS#11 in Javahttp:/java.sun.com/javase/6/docs/technotes/guides/security/p11guide.html IAIK PKCS#11 Provider/WrapperPaKChoiShttp:/www.manyfish.co.uk/pakchois/ PKCS#11 For MuscleCard Frameworkhttp:/sourceforge.net/projects/pkcs11 Firefox + opencryptokiin ubuntu NSSOpen Source PKI Projects/NSS/JSShttp:/www.mozilla.org/projects/security/http:/www.mozilla.org/projects/security/pki/nss/To implement ALL your security features. NSS includes a framework to which developers and OEMs can contribute patches, such as assembler code, to optimize performance on their platforms. NSS 3.x has been certified on 18 platforms. NSS: Proven Application Security ArchitectureNSS provides a complete open-source implementation of the crypto libraries used by AOL, Red Hat, Sun, and other companies in a variety of products, including the following: The Mozilla client products, including Mozilla Suite, Firefox, and Thunderbird. The Netscape browsers AOL Communicator and AOL Instant Messenger (AIM) Open source client applications such as Evolution, Gaim, and OpenOffice. Server products from Red Hat: Red Hat Directory Server, Red Hat Certificate System, and the mod_nss SSL module for the Apache web server. Server products from the Sun Java Enterprise System, including Sun Java System(SJS) Web Server, SJS Directory Server, SJS Portal Server, SJS Messaging Server, and SJS Application Server. Build Firefox with NSSWindows XPVisual Studio 6/7.1/8MozillaBuildMozilla/Firefox Source Codemozillasecuritynss制作配置文件 .mozconfig（备注行）运行 start-msvc71.bat$make -f client.mk build耗时编译好的在 .ff-opt-staticdistbin绿色版 PKCS#11 wrappersSince PKCS#11 is a complex C API many wrappers exist that let the developer use the API from various languages.PyKCS11 - A wrapper for PythonPython object-oriented wrapper for PKCS11 (Cryptoki)Java 5.0 includes a wrapper for PKCS#11 APIpkcs11-helper - A simple open source C interface to handle PKCS#11 tokens. Open-source PKI Bookhttp:/sourceforge.net/projects/ospkibook/ Open Source PKIhttp:/www.mozilla.org/projects/security/pki/ GSS-API by IETFGeneric Security Services Application Programming InterfaceGSS-API is an application programming interface for programs to access security services.The GSSAPI is an IETF standard that addresses the problem of many similar but incompatible security services in use today. -compatible interfaceThe GSSAPI, by itself, does not provide any security. Instead, security service vendors provide GSSAPI implementations usually in the form of libraries installed with their security software. These libraries present a GSSAPI-compatible interface to application writers who can write their application to use only the vendor-independent GSSAPI. If the security implementation ever needs replacing, the application need not be rewritten. GSSAPI tokensThe definitive feature of GSSAPI applications is the exchange of opaque messages (tokens) that hide the implementation detail from the higher level application. The client and server sides of the application are written to convey the tokens given to them by their respective GSSAPI implementations. GSSAPI tokens can be sent over an insecure network because the mechanisms guarantee inherent message security. After some number of tokens have been exchanged, the GSSAPI at both ends inform their local application that a security context has been established. security contextOnce a security context is established, sensitive application messages can be wrapped (encrypted) by the GSSAPI for secure communication between client and server. Typical protections guaranteed by GSSAPI wrapping include confidentiality (secrecy) and integrity (authenticity). The GSSAPI can also provide local guarantees about the identity of the remote user or remote host. History of the GSS-APIJuly 1991: IETF Common Authentication Technology (CAT) Working Group meets in Atlanta, led by John Linn September 1993: GSSAPI version 1 (RFC 1508, RFC 1509) May 1995: Windows NT 3.51 released, includes SSPI June 1996: Kerberos mechanism for GSSAPI (RFC 1964) January 1997: GSSAPI version 2 (RFC 2078) October 1997: SASL published, includes GSSAPI mechanism (RFC 2222) January 2000: GSSAPI version 2 update 1 (RFC 2743, RFC 2744) August 2004: KITTEN working group meets to continue CAT activities May 2006: Secure Shell use of GSSAPI standardised (RFC 4462) GSS-API in RFCRFC 2743 The Generic Security Service API Version 2 update 1 RFC 2744 The Generic Security Service API Version 2: C-Bindings RFC 1964 The Kerberos 5 GSS-API mechanism RFC 4121 The Kerberos 5 GSS-API mechanism: Version 2 RFC 4178 The Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) RFC 2025 The Simple Public-Key GSS-API Mechanism (SPKM) RFC 2847 LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM Key conceptsName A binary string that labels a security principal (i.e. user or service program) - see access control and identity. For example, Kerberos uses names like userREALM for users and service/hostnameREALM for programs. Credentials Information that proves an identity; used by an entity to act as the named principal. Credentials typically involve a secret cryptographic key. Context The state of one end of the authenticating/authenticated protocol. May provide message protection services, which can be used to compose a secure channel. Tokens Opaque messages exchanged either as part of the initial authentication protocol (context-level tokens), or as part of a protected communication (per-message tokens) Mechanism An underlying GSSAPI implementation that provides actual names, tokens and credentials. Known mechanisms include Kerberos, NTLM, Distributed Computing Environment (DCE), SESAME, SPKM, LIPKEY. Initiator/acceptor The peer that sends the first token is the initiator; the other the acceptor. Generally, the client program is the initiator while the server is the acceptor. about 45 procedure callsSignificant ones include:GSS_Acquire_cred - obtains the users identity proof, often a secret cryptographic key GSS_Import_name - converts a username or hostname into a form that identifies a security entity GSS_Init_sec_context - generates a client token to send to the server, usually a challenge GSS_Accept_sec_context - processes a token from GSS_Init_sec_context and can generate a response token to return GSS_Wrap - converts application data into a secure message token (typically encrypted) GSS_Unwrap - converts a secure message token back into application data Standardize The GSSAPI has been standardized for the C and Java languages.Limitations of the GSSAPI include that it standardizes only authentication, and not authorization, and that it assumes a client-server architecture.Anticipating new security mechanisms, the GSSAPI includes a negotiating pseudo mechanism, SPNEGO, that can discover and use new mechanisms not present when the original application was built. GSS & KerberosThe dominant GSSAPI mechanism implementation in use is Kerberos. Unlike the GSSAPI, the Kerberos API has not been standardized and various existing implementations use incompatible APIs. The GSSAPI allows Kerberos implementations to be API compatible.GSSAPI成为不同Kerberos的API Implementation Java Generic Security Services (Java GSS-API) http:/doc.javanb.com/javasdk-docs-6-0-en/technotes/guides/security/jgss/jgss-features.html Java GSS-API and JAAS for Use with KerberosSingle Sign-on Using Kerberos in Java 手册书：Google(“Solaris开发者安全性指南”)Also: http:/www.opensolaris.org/os/project/crypto/ Next Generation GSS-APIKitten working group - next generation GSS-API http:/www.ietf.org/html.charters/kitten-charter.html The Common Authentication Technology Next Generation Working Group (Kitten) will work on standardizing extensions and improvements to the core GSSAPI specification and language bindings that the IETF believes are necessary based on experience using GSSAPI over the last 10 years. Extensions may be published as separate drafts or included in a GSSAPI version 3. While version 2 of the GSSAPI may be clarified, no backward incompatible changes will be made to this version of the API. GCS-API by X/OpenGeneric Cryptographic Service API from X/Open. http:/www.opengroup.org/pubs/catalog/se.htm to provide cryptographic services in support of both algorithm unaware and algorithm aware applications. As such, the interface specification is provided for use by programmers who develop applications that rely on cryptographic services and key management services. API GCS-API implementthe GCS-API is designed for cryptographic-aware applicationsGCS-API is not recommended for general applications CDSACommon Data Security Architecture (CDSA)by Intel Open Grouphttp:/www.opengroup.org/security/l2-cdsa.htmCDSA安全体系架构CDSA是一个安全体系架构规范标准说明，解释了CDSA的结构，各模块需要完成的功能，以及各接口的函数名称、调用模式、参数数量和名称。广泛支持 CDSA标准与规范Common Security: CDSA and CSSM, Version 2 (with Corrigenda)http:/www.opengroup.org/publications/catalog/c914.htm http:/www.opengroup.org/onlinepubs/9690989599/toc.pdf (maybe) 1034pages four-layer architectureCDSA defines a horizontal, four-layer architecture:1. Applications2. Layered services and middleware3. Common Security Services Manager (CSSM) infrastructure4. Security Service Provider Modules CDSA：安全体系架构图 The CDSAv2.3 is organized into 15 parts1. The CDSA architecture 2. Common Security Services Manager (CSSM) APIs for core services3. Cryptographic Service Providers (CSP)4. Trust Policy Services (TP)5. Authorization Computation Services (AC)6. Certificate Library Services (CL)7. Data Storage Library Services (DL)8. Module Directory Service (MDS)9. Key Recovery Services (KR)10. Embedded Integrity Services Library (EISL) 11. Signed Manifest 12. Object Identifiers for Certficate Library Modules13. Elective Module Manager (EMM)14. Add-in Module Structure and Administration15. Appendices, Glossary, and Index CDSA优缺点工业标准：通用性、可扩展性、安全性：单一模式的安全解决方案，不足性能：难以适应小环境 CDSA实现CDSA实现http:/sourceforge.net/projects/cdsa/cdsacode_314.zip / cdsadocs_314.zipcdsa_man.zip / cts_313.zipBuild CDSA in linux建议Redhat 9OpenSSL with RC5./config enable-rc5 -prefix=/usr/local/ssl#. configure （在cdsa目录make之前）还要修改几个小bugvoid main()，少include了sha.h等，真ft The Security Forum in X/Open (open group)Working GroupsAuto Compliance ExpertCOA FrameworkCOA Reference Arch.Ecosystem for SecurityRisk Mgmt - FAIRSecure Enterprise 2.0Secure Mobile Arch.Security Arch (ESA)Security Design PatternsSecurity GuidesSecurity StrategySOA and SecurityTrust Mgmt & ClassnUpdate-XDAS MS-CAPISoftware written for Microsoft Windows may use the platform specific MS-CAPI API instead. MS-CAPIThe Cryptographic Application Programming Interface (also known variously as CryptoAPI, Microsoft Cryptography API, or simply CAPI) is an application programming interface included with Microsoft Windows operating systems that provides services to enable developers to secure Windows-based applications using cryptography. It is a set of dynamically-linked libraries that provides an abstraction layer which isolates programmers from the code used to encrypt the data.CryptoAPI supports both public-key and symmetric key cryptography. It includes functionality for encrypting and decrypting data and for authentication using digital certificates. It also includes a cryptographically secure pseudorandom number generator function CryptGenRandom.CryptoAPI works with a number of CSPs (Cryptographic Service Providers) installed on the machine. CSPs are the modules that do the actual work of encoding and decoding data by performing the cryptographic functions. CSPCryptoAPI works with a number of CSPs (Cryptographic Service Providers) installed on the machine. CSPs are the modules that do the actual work of encoding and decoding data by performing the cryptographic functions.CSP/DLL MS对CSP/DLL的签名 CAPI结构图 CAPI例子程序 5003.exe MSDN example 5003.zip 改正了一个bug加密/解密一个文件相关CAPI函数CryptAcquireContextCryptReleaseContextCryptEncryptCryptDecrypt Cryptography API: Next Generation (CNG)Windows Vista features an update to the Crypto API known as Cryptography API: Next Generation (CNG). It has better API factoring to allow the same functions to work using a wide range of cryptographic algorithms, and the inclusion of a number of newer algorithms that are part of the National Security Agency (NSA) Suite B. It is also flexible, featuring support for plugging in custom cryptographic APIs into the CNG runtime. CNG works in both user and kernel mode, and also supports all of the algorithms from the CryptoAPI. The Microsoft provider that implements CNG is housed in Bcrypt.dll. CNG also supports Elliptic Curve Cryptography which is also secure and uses shorter keys than RSA. The CNG API integrates with the smart card subsystem by including a Base Smart Card Cryptographic Service Provider (Base CSP) module which encapsulates the smart card API. Smart card manufacturers just have to make their devices compatible with this, rather than provide a from-scratch solution. DPAPI: Data protection APIDP APIa relatively easy-to-use cryptography API available as a standard component in Microsoft Windows 2000 and later versions of Windows operating systems.示例程序连接库 “Crypt32.lib” DPAPI例子main()DATA_BLOB in, out, in2;in.pbData = (BYTE*)my input text as if none;in.cbData = strlen(my input text as if none)+1;BOOL b = CryptProtectData(&in, NULL, NULL, NULL, NULL, 0, &out);if (b)b = CryptUnprotectData(&out, NULL, NULL, NULL, NULL, 0, &in2);if (b)puts(char*)(in2.pbData);elseputs(err);return 0; Data Execution Prevention (DEP)DEPa security feature included in modern Microsoft Windows operating systems that is intended to prevent an application or service from executing code from a non-executable memory region. This helps prevent certain exploits that store code via a buffer overflow, for example.DEP was introduced in Windows XP SP2, also in Windows Server 2003 SP1 and Windows Vista. Later versions of the operating systems support this feature as well. XP：数据执行保护boot.inimulti(0)disk(0)rdisk(0)partition(1)WINDOWS=Microsoft Windows XP Pro /noexecute=optin /fastdetect Linux中的“DEP”, and moreData Execution Prevention (DEP)in Linux in CPUNX: No eXecute by AMDXD: eXecute Disable by Intel (Open) Cryptographic LibrariesOpenSSL, NSS, POSSE, OpenSSH, GnuTLS, MatrixSSL, cryptlib, GNU Crypto, Crypto+, BeeCrypt, Cryptlib, Cryptix, LibTomCrypt, libgcrypt, MIRACL, Cryptix, borZoi,Try some of these Crypto in Java/JDK/JREJava SE Security homepagehttp:/java.sun.com/javase/technologies/security/JDK 6 Security-related APIs & Developer Guideshttp:/java.sun.com/javase/6/docs/technotes/guides/security/ REFdebian:# aptitude search crypt | wc 80 632 6480 推荐阅读/实验：OpenSC了解OpenSC项目的背景、功能、子项目；了解智能卡的应用背景和主要相关技术；实验报告http:/www.opensc-project.org/ Q & A