JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Developer's Guide to Oracle Solaris 10 Security     Oracle Solaris 10 1/13 Information Library
search filter icon
search icon

Document Information


1.  Oracle Solaris Security for Developers (Overview)

2.  Developing Privileged Applications

3.  Writing PAM Applications and Services

4.  Writing Applications That Use GSS-API

5.  GSS-API Client Example

6.  GSS-API Server Example

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

Requirements for Developers of Kernel-Level Consumers

Avoiding Data Cleanup Collisions in User-Level Providers

9.  Writing User-Level Cryptographic Applications and Providers

10.  Using the Smart Card Framework

A.  Sample C-Based GSS-API Programs

B.  GSS-API Reference

C.  Specifying an OID

D.  Source Code for SASL Example

E.  SASL Reference Tables

F.  Packaging and Signing Cryptographic Providers



Oracle Solaris Cryptography Terminology

An application, library, or kernel module that obtains cryptographic services is called a consumer. An application that provides cryptographic services to consumers through the framework is referred to as a provider and also as a plug-in. The software that implements a cryptographic operation is called a mechanism. A mechanism is not just the algorithm but includes the way in which the algorithm is to be applied. For example, the DES algorithm when applied to authentication is considered a separate mechanism. DES when applied to block-by-block encryption would be a different mechanism.

A token is the abstraction of a device that can perform cryptography. In addition, tokens can store information for use in cryptographic operations. A single token can support one or more mechanisms. Tokens can represent hardware, as in an accelerator board. Tokens that represent pure software are referred to as soft tokens. A token can be plugged into a slot, which continues the physical metaphor. A slot is the connecting point for applications that use cryptographic services.

In addition to specific slots for providers, the Solaris implementation provides a special slot called the metaslot. The metaslot is a component of the Solaris cryptographic framework library ( The metaslot serves as a single virtual slot with the combined capabilities of all tokens and slots that have been installed in the framework. Effectively, the metaslot enables an application to transparently connect with any available cryptographic service through a single slot. When an application requests a cryptographic service, the metaslot points to the most appropriate slot, which simplifies the process of selecting a slot. In some cases, a different slot might be required, in which case the application must perform a separate search explicitly. The metaslot is automatically enabled and can only be disabled through explicit action by the system administrator.

A session is a connection between an application that use cryptographic services and a token. The PKCS #11 standard uses two kinds of objects: token objects and session objects. Session objects are ephemeral, that is, objects that last only for the duration of a session. Objects that persist beyond the length of a session are referred to as token objects.

The default location for token objects is $HOME/.sunw/pkcs11_softtoken. Alternatively, token objects can be stored in $SOFTTOKEN_DIR/pkcs11_softtoken. Private token objects are protected by personal identification numbers (PIN). To create or change a token object requires that the user be authenticated, unless the user is accessing a private token object.