Skip Navigation Links | |
Exit Print View | |
Developer's Guide to Oracle Solaris Security Oracle Solaris 11 Express 11/10 |
1. Oracle Solaris Security for Developers (Overview)
2. Developing Privileged Applications
3. Writing PAM Applications and Services
4. Writing Applications That Use GSS-API
7. Writing Applications That Use SASL
8. Introduction to the Oracle Solaris Cryptographic Framework
Oracle Solaris Cryptography Terminology
Overview of the Cryptographic Framework
Components of the Cryptographic Framework
What Cryptography Developers Need to Know
Requirements for Developers of User-Level Consumers
Requirements for Developers of User-Level Providers
Avoiding Data Cleanup Collisions in User-Level Providers
9. Writing User-Level Cryptographic Applications and Providers
10. Introduction to the Oracle Solaris Key Management Framework
A. Sample C-Based GSS-API Programs
D. Source Code for SASL Example
This section describes the requirements to develop the four types of applications that can plug into the Oracle Solaris cryptographic framework.
To develop a user-level consumer, do all of the following:
Include <security/cryptoki.h>.
Make all calls through the PKCS #11 interfaces only.
Link with libpkcs11.so.
Libraries should not call the C_Finalize() function.
See Chapter 9, Writing User-Level Cryptographic Applications and Providers for more information.
To develop a user-level provider, do all of the following:
Design the provider to stand alone. Although the provider shared object need not be a full-fledged library to which applications link, all necessary symbols must exist in the provider. Assume that the provider is to be opened by dlopen(3C) in RTLD_GROUP and RTLD_NOW mode.
Create a PKCS #11 Cryptoki implementation in a shared object. This shared object should include necessary symbols rather than depend on consumer applications.
It is highly recommended though not required to provide a _fini() routine for data cleanup. This method is required to avoid collisions between C_Finalize() calls when an application or shared library loads libpkcs11 and other provider libraries concurrently. See Avoiding Data Cleanup Collisions in User-Level Providers.
Apply for a certificate from Sun Microsystems, Inc. See To Request a Certificate for Signing a Provider.
Use the certificate with elfsign to sign the binary. See To Sign a Provider.
Package the shared object according to Sun conventions. See Appendix F, Packaging and Signing Cryptographic Providers.
To develop a kernel-level consumer, do all of the following:
Include <sys/crypto/common.h> and <sys/crypto/api.h>.
Make all calls through the kernel programming interface.
To develop a kernel-level provider, do all of the following:
Include <sys/crypto/common.h> and <sys/crypto/api.h>.
Import required routines for registering, unregistering, and providing status.
Export required routines to provide entry points for kernel cryptographic framework.
Export data structure with descriptions of supported algorithms.
Create loadable kernel module.
Apply for a certificate from Sun Microsystems, Inc. See To Request a Certificate for Signing a Provider.
Use the certificate with elfsign to sign the binary. See To Sign a Provider.
Package the kernel module according to Sun conventions. See Appendix F, Packaging and Signing Cryptographic Providers.