Print-friendly Version

This article provides an overview of security APIs, SPIs, and frameworks for the Solaris OS. The overview is intended for developers who work on consumer applications or service modules. The information in this article comes from the Solaris Security for Developers Guide. The article also discusses security-related code examples that can be obtained from the Sun Download Center.

• Introduction
• Developing Consumer Applications and Service Modules That Plug Into the Cryptographic Framework
• Authenticating Entry to a System With PAM
• Secure Communication Between Peer Applications Using GSS-API
• Secure Communication Between Peer Applications Using SASL
• Developing IFD Handlers for Smart Card Terminals
• Limiting Access to Privileged Applications Through Process Privileges
• Java Cryptography Extension

The Solaris Operating System (OS) provides a rich suite of security features with interfaces for consuming or providing security services. These features include various cryptographic services, interfaces for writing privileged applications under the least privilege model, and the PAM interfaces for using or writing pluggable authentication modules.

In case you are unfamiliar with the security development terms used in this article, the following definitions are provided. An application, library, or kernel module that uses security services is called a consumer. An application, library, or kernel module that provides security services to consumers 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 an algorithm but includes the manner in which the algorithm is to be applied. A framework is an infrastructure provided by the operating system usually with both an application programming interface (API) that provides functions for consumers and a service provider interface (SPI) that provides functions for providers.

The Solaris OS security features provide the following interfaces:

• Solaris Cryptographic Framework -- The Solaris Cryptographic Framework lets developers write cryptographic consumers and providers that plug into the framework. The framework provides a public API and SPI at the user level. Currently, the API and SPI at the kernel level are private, but are available for early access by sending email to solaris crypto api@sun.com. The framework is based on the libpkcs11.so library, which implements the RSA Security Inc. PKCS#11 Cryptographic Token Interface (Cryptoki), v2.11 specification.

• GSS-API -- The Generic Security Service Application Programming Interface (GSS-API) provides a means for applications to protect data to be sent to peer applications. GSS-API is supported for both consumer and provider applications and is compatible with the Solaris Cryptographic Framework.

• SASL - SASL (Simple Authentication and Security Layer) is a security framework. SASL, pronounced "sassel," provides authentication services and optionally integrity and confidentiality services to connection-based protocols. SASL is supported for both consumer and provider applications and is compatible with the Solaris Cryptographic Framework.

• PAM -- Pluggable authentication modules (PAM) provide system entry applications with authentication and related security services. The pam(3PAM) API supports consumers. The pam_sm(3PAM) SPI supports providers.

• Smart Card Framework API -- The Solaris OS provides a smart card framework, based on the PC/SC (personal computer/smart card) specification in which smart card terminals communicate with consumer applications by means of an interface device (IFD) handler.

• Process Privileges -- A process privilege is a discrete right that can be granted to an application that enables the application to override system controls. The Solaris OS provides a number of interfaces for using privileges.

• Java Cryptography Extension (JCE) -- Java JCE provides a framework and implementations for encryption, key generation and key agreement, and Message Authentication Code (MAC) algorithms.

The Solaris Cryptographic Framework is the portion of the Solaris OS that provides cryptographic services from Sun Microsystems, Inc. and third-party suppliers. The cryptographic framework architecture provides the following services:

• Message encryption and message digest

• Message authentication codes (MACs)

• Digital signing

• APIs for accessing cryptographic services

• SPIs for providing cryptographic services

• An administration command for managing cryptographic resources

The cryptographic framework has two parts: the user cryptographic framework for user-level applications and the kernel cryptographic framework for kernel-level modules. All interactions with the framework whether at the user or kernel level are based on the RSA Security Inc. PKCS#11 Cryptographic Token Interface (Cryptoki).

The framework eliminates the need for security consumer developers to write, maintain, and optimize cryptographic algorithms. Consumers of the cryptographic framework need no special knowledge of the installed cryptographic mechanisms. Consumers include security protocols, certain mechanisms, and applications that need to perform cryptography.

Providers plug into the framework with no special code necessary for the different types of consumers. Providers include cryptographic mechanisms as well as other mechanisms in hardware and software plug-ins.

The following diagram provides a logical view of the Solaris cryptographic framework.

Figure 1: Solaris Cryptographic Framework Architecture

The elliptical elements in the diagram represent third-party consumers and providers. The rectangular elements are portions of the framework that are provided by the operating system. The elements are used as follows:

• User-level consumers -- User-level consumer applications can request services directly from the framework or can go through an intermediate layer such as GSS-API or SASL. Some standard security applications that use the framework include SSL, Secure Shell, IKE, Kerberos, and Java JCE.

• User-level cryptographic framework -- This portion of the framework is the Cryptoki file, that is, the libpkcs11.so library. Cryptoki implements the RSA PKCS#11 v2.11 of the standard. Cryptoki provides an API for consumers and an SPI for providers.

• User-level plug-ins -- Cryptographic services can be plugged into the cryptographic framework at the user level with PKCS #11.

• Solaris soft token -- The Solaris OS supplies cryptographic mechanisms at the user level through pkcs11_softtoken.so, a private shared object. This plug-in includes user-level implementations of popular cryptographic mechanisms such as DES, 3DES, and AES.

• Solaris kernel bridge -- Cryptographic services in the kernel are available to user-level consumers through the pkcs11_kernel.so bridge, which is a private shared object.

• Kernel-level cryptographic framework -- The portion of the framework at the kernel level. The kernel programmer interface is used by kernel-level consumers of cryptographic services, such as the IPSec protocol and the kerberos GSS mechanism. The server provider interface is used by providers of kernel-level cryptographic services, which can be implemented on either hardware or software.

• Kernel-level consumers -- Kernel-level cryptographic modules such as IPSec can get services from the kernel portion of the framework.

• Solaris crypto plug-in -- The Solaris OS provides kernel-level cryptographic services including popular cryptographic mechanisms.

• Kernel-level plug-ins -- Cryptographic mechanisms in both software and hardware can be provided as services through the kernel portion of the framework. To use the SPI, a provider must import special routines from the Solaris kernel for registering and removing services and for receiving state change notifications. The framework also requires that providers export certain routines for receiving requests.

For more information on the Solaris Cryptographic Framework, see the BigAdmin article entitled "Solaris Cryptographic Framework" and the following two chapters in the Solaris Security for Developers Guide: "Chapter 8: Introduction to the Solaris Cryptographic Framework" and "Chapter 9: Adding Cryptography to User Applications."

The following working examples are available from the Sun Download Center to help you use the cryptographic framework:

• efexample1.c -- Consumer that demonstrates message digests.

• efexample2.c -- Consumer that demonstrates symmetric encryption.

• efexample-gk.c -- Consumer that demonstrates sign and verify.

• efexample-rand_1.c -- Consumer that demonstrates random byte generation.

• demo provider - A working provider that can open PKCS#11 sessions and create objects. When linked with a library containing the MD5Init(), MD5Update(), and MD5Final() functions, the provider can perform digest operations by using the CKM_MD5 mechanism.

The pluggable authentication modules (PAM) framework is used for the initial authentication of a user to a system. PAM can be applied to system entry by GUI, command line, or any other means.

A diagram of the PAM framework is shown below.

Figure 2: PAM Framework

The PAM framework consists of the following elements:

• Consumer applications -- Applications that provide entry to a system such as login, ftp, and telnet.

• PAM library -- A framework that exports the pam(3PAM) API, imports the pam.conf(4) master configuration file, and imports the pam_sm(3PAM) SPI, which is exported by the service modules.

• PAM configuration file -- The pam.conf(4) configuration file configures PAM service modules for system services, such as login, rlogin, su, and cron. The system administrator manages this file. The ordering of this file is crucial to successful functioning of the authentication services.

• PAM service modules -- Also referred to as providers, the PAM service modules fall into four categories:

• Authentication service modules, for granting users access to an account or service. Modules that provide this service authenticate users and set up user credentials.

• Account management modules, for determining whether the current user's account is valid. Modules that provide this service can check password or account expiration and time-restricted access.

• Session management modules, for setting up and terminating login sessions.

• Password management modules, for enforcing password strength rules and performing authentication token updates.

For a more complete description of PAM, see "Chapter 3: Writing PAM Applications and Services" in the Solaris Security for Developers Guide and the man pages for the pam(3PAM) API, the pam.conf(4) master configuration file, and the pam_sm(3PAM) SPI.

For examples of a PAM consumer, a PAM conversation function, and a PAM service module, see the Sun Download Center.

The GSS-API interface is a layer that provides secure communication between peer applications, as shown in the following diagram.

Figure 3: Role of GSS-API in the Architecture

The GSS-API provides authentication, integrity, and confidentiality protection services as well. The Solaris implementation of the GSS-API works with Kerberos v5, SPNEGO, and Diffie-Hellman encryption. The GSS-API is primarily used to design or implement secure application protocols. GSS-API can provide services to other kinds of protocols, such as SASL. Through SASL, GSS-API provides services to LDAP.

GSS-API is typically used by two peer applications that are communicating over a network after the initial establishment of credentials has occurred. GSS-API is used by login applications, NFS, and ftp, among other applications.

See "Chapter 4: Writing Applications That Use GSS-API" in the Solaris Security for Developers Guide for an introduction to GSS-API. "Chapter 5: GSS-API Client Example" and "Chapter 6: GSS-API Server Example" provide the source code descriptions of two typical GSS-API applications. "Appendix A: Sample C--Based GSS-API Programs" presents the code listings for the GSS-API examples. "Appendix B: GSS-API Reference" provides reference material for GSS-API. "Appendix C: Specifying an OID" demonstrates how to specify a mechanism other than the default mechanism.

For working examples of a GSS-API client and a GSS-API server, see the Sun Download Center.

The simple authentication and security layer (SASL) is used largely by protocols, for authentication, privacy, and data integrity. SASL is intended for higher-level network-based applications that use dynamic negotiation of security mechanisms to protect sessions. LDAP is one of the better-known consumers of SASL. SASL is similar to GSS-API. SASL is on a somewhat higher level than GSS-API. SASL consumes GSS-API services.

See "Chapter 7: Writing Applications That Use SASL" in the Solaris Security for Developers Guide. For working examples of a SASL client and a SASL server, see the Sun Download Center.

To provide access to smart card terminals, developers need to write special device drivers called interface device (IFD) handlers. The IFD handlers plug into the smart card framework so that their services can be provided to consumers as shown in the following diagram.

Figure 4: IFD Handlers and Smart Card Framework

"Chapter 10: Using the Smart Card Framework" in the Solaris Security for Developers Guide describes how to develop IFD handlers. See also the man pages with the IFDH prefixes in the man page section: Extended Libraries.

The PS/SC (personal computer/smart card) API provides functions for smart card sessions. See the GEMPLUS PC/SC portal for the PC/SC specification.

Process privileges provide an alternative to the standard, superuser-based UNIX model for granting access to privileged applications. In the superuser model, a user must first become superuser to use a privileged application. As superuser, that user can run any application on the system, which is a major security risk. Under the least privilege model, the system administrator assigns the least number of process privileges to a user that are necessary for the user to perform his or her normal functions, according to the organization's security policy.

A process privilege is a discrete right that can be granted to an application. With the privilege, a process can perform an operation that would otherwise be prohibited by the Solaris OS. For example, a process cannot normally open data files without the proper file permission. The file_dac_read privilege provides a process with the ability to override the UNIX file permissions for reading a file. Privileges are enforced at the kernel level.

Privileges are assigned to users by an administrator and are enabled programmatically. At login or when the user enters profile shell (a special shell for using privileged applications), the administrator's privilege assignments apply to any commands that are executed in the shell. When an application is run, privileges should be turned on or turned off programmatically as needed. If a new program is started through the exec() function, that program can potentially use all of the parent process's privileges that are permitted to be inherited. However, that program cannot add any new privileges.

Developers who create new privileged applications should now test for specific privileges instead of checking for UID = 0.

The use of privileges is discussed thoroughly in "Chapter 2: Developing Privileged Applications" in the Solaris Security for Developers Guide. See setppriv(2), getppriv(2), getpflags(2), and setpflags(2) in man page section: 2. See also those interfaces with the prefix priv_ in section: 3C.

A sample application that demonstrates privilege use can be obtained by downloading the least privilege bracketing example from the Sun Download Center.

The Java Cryptography Extension (JCE) is a set of packages that provide a framework and implementations for encryption, key generation and key agreement, and MAC algorithms. Support for encryption includes symmetric, asymmetric, block, and stream ciphers. The software also supports secure streams and sealed objects.

JCE is designed so that other qualified cryptography libraries can be plugged in as service providers, and new algorithms can be added seamlessly. Qualified providers are signed by a trusted entity.

With the J2SE 5.0 release, JCE is the default crypto provider for Java applications that need encryption. On the Solaris platform, JCE plugs into the Solaris Cryptographic Framework and can take advantage of any mechanism available in the framework.

The following algorithms are supported by the SunJCE provider:

• DES
• DESede
• AES (with Java 2 SDK, v 1.4.2)
• Blowfish
• PBEWithMD5AndDES
• PBEWithMD5AndTripleDES
• Diffie-Hellman key agreement among multiple parties
• HmacMD5
• HmacSHA1

For more information, see the JCE page on java.sun.com.

John Stearns is a senior technical writer in the Information Products group at Sun Microsystems, Inc.