Figure 1. Under Microsoft's Crypto API architecture, applications use services packaged into one of five subsystems.
If you have been following the evolution of security solutions for a hyperconnected world, you are certain to be familiar with the basic concepts of public key cryptography. You are probably also aware that this technology has been broadly accepted as the basis for corporate- and Internet-based security infrastructures. Despite their acceptance, security infrastructures based on public key cryptography are immature, and tools and technologies supporting these infrastructures are evolving rapidly. In fact, I just read a comprehensive Burton Group report that detailed the challenges that must be overcome before public key infrastructure (PKI) can be widely adopted.
The Burton Group report (available at www.tbg.com/login/entrust.htm) discusses why public key cryptography technology provides a sound basis for the authentication, authorization, encryption, and key management functions that a sound security infrastructure requires. It goes on to describe various features of PKI and discusses the areas where work still needs to be done to make it comprehensive, efficient, and robust. In particular, the Burton Group report points to the need for standards in the areas of digital signatures, certificate and certification revocation list (CRL) formats and protocols, certificate management protocols, and application programming interfaces.
These are all areas that I have been concerned about lately, as Iıve built the infrastructure for a business-to-business trading community. While my current work spans system engineering and planning and software development, my main focus has always been the development side. My interest in application development, together with our companyıs business focus, led me to evaluate the APIs available for ensuring authenticity, authorization, and privacy a year ago. APIs define how applications use network and storage protocols to consume PKI services. Developers would use an API to access PKI services when their applications need to obtain an individualıs public key, request certification revocation information, or request certification. Early this year PKI APIs became a topic of widespread interest when significant movement occurred in the standards arena and providers of e-commerce and security technologies announced supporting product initiatives.
When we conducted our evaluation of security APIs, we chose RSA Data Securityıs BSafe toolkit, both because it offered a broad range of capabilities and algorithms and because associating ourselves with the RSA name lent a great deal of credibility to the security of our offering. Late last year, we educated ourselves about APIs that offered to provide a single standard interface for each category of security solution. This approach promised to confer such benefits as making the conversion of our encryption process to a new algorithm a trivial exercise, should we decide to do so because of cost, performance, or security considerations. At the time, we were considering Intelıs Common Data Security Architecture (CDSA) and Microsoftıs Crypto API (CAPI). We gravitated toward the API that appeared to give us access to the largest share of the market; at the time, that appeared to be CAPI. As the Burton Group points out, this common tendency results in APIs defined by successful infrastructure products and reduces the likelihood of standardization on a single API. While Intelıs solution appeared to be powerful and comprehensive, we believed that the Microsoft offering would garner the predominant developer support simply by virtue of its ubiquity. Like many of the infrastructure capabilities I have discussed in these pages, Microsoftıs CAPI is an integral part of the Win32 platform and is available to applications running on that platform.
In January 1998, two significant events occurred that shifted most of the industryıs focus to CDSA. First, the Open Group (www.opengroup.org) adopted Intelıs CDSA 2.0 specification as an industry-accepted specification for the development of secure applications that are interoperable, extensible, and offer cross-platform support. The Open Group announcement stated that IBM, Netscape, Entrust, Trusted Information Systems Inc., Motorola, Hewlett-Packard, Sun, Shell Co., and JP Morgan would be among the companies supporting CDSA. A week after the Open Group announcement, Security Dynamics (www.securitydynamics.com) and RSA announced at the RSA security conference that they would join IBM in building CDSA support into their products as well as developing and delivering toolkits that include support for CDSA. Security Dynamics and RSA have historically been among the most significant vendors of security solutions, and IBM is, well, IBM. Their joint announcement and their commitment to ensure that their respective security services integrate was a significant statement of support for the benefits of a common API and a powerful indication of the marketplace momentum that CDSA has generated over the past six months.
From a technical perspective, CDSA and CAPI have both similarities and differences. Insofar as CAPI relies on a variety of other services provided by Windows to provide a complete security architecture, its probably more fair to compare CDSA to CAPI plus the Windows security infrastructure. In such a comparison, CDSAıs platform neutrality is a significant differentiating factor.
The CAPI system architecture comprises five different major functional areas, as depicted in Figure 1.
An application can communicate with any of these subsystems through the access functions that they expose. The base cryptographic functions, in turn, rely upon cryptographic service providers (CSPs) to provide the necessary cryptographic algorithms and to provide secure storage for any cryptographic session or public or private keys that may be generated. CSPs are independent modules that perform the real cryptographic work. At a minimum, they consist of a dynamic-link library (DLL) and a signature file. The signature file is necessary to ensure that CAPI recognizes the CSP. CAPI validates this signature periodically to ensure that nothing has tampered with the CSP.
Each base cryptographic function that communicates with a CSP takes a parameter that specifies which CSP to use. You can think of CSPs as drivers that support vendor-specific implementations of the services that the API defines. Just as well-behaved applications are not allowed to communicate directly with graphics device drivers and hardware, well-behaved applications cannot directly access CSPs and cryptographic hardware. Ideally, CSPs are written to be completely independent of any particular application; conversely, an application should be capable of using a variety of CSPs.
Like CDSA, CAPI provides developers with tools to build applications on top of a certificate-based PKI. A Certification Authority issues a certificate to an entity (for example, a person or corporation) after it has determined authenticity. The certificate is a data set that uniquely describes the entity and usually incorporates that entityıs public key. CAPIıs certificate encode/decode functions and the certificate store functions support certificate management and certificate-based authentication. The simplified message functions, low-level message functions, and base cryptographic functions make encryption/decryption facilities and the ability to sign data available to the application developer digitally.
Some CSPs implement portions of their functionality either in an address-separated service called through a local remote procedure call (RPC) or in hardware called through a system-device driver. Isolating global key-state and central cryptographic operations in hardware or in a service keeps keys and operations safe from tampering within the application data space. Application developers need to take care not to let their code become dependent on characteristics of a specific CSP. For example, Microsoft supplies a base cryptographic provider with CAPI (licensed from RSA) that currently uses 40-bit session keys and 512-bit public keys. When applications manipulate these keys, they should be careful not to make assumptions about the amount of memory needed to store them. Otherwise, the application is likely to fail when the user loads a different CSP onto the system. Thus CAPI places some responsibility on the application developer for ensuring that applications maintain their robustness and reliability in the face of changes to the underlying CSPs.
CDSA came out of Intel Architecture Laboratories, where it was designed as an overall infrastructure for data security across computer systems. Intelıs architects built CDSA on the assertion that all applications implementing security must use cryptographic services, certificate services, data storage, and trust policy. These services have been components of CDSA since its initial specification. Cryptographic Services are the heart of security services and protocols. Identity, authentication, and integrity are embodied in digital credentials (such as certificates). A userıs certificates must be stored persistently and securely so that they can be used as credentials over relatively long periods of time. Organizations and institutions will establish policies to govern how and when the credentials can be used. An application must address each of these aspects of security in order to provide a robust security model.
CDSA defines a three-tier architecture. (See Figure 2.) Itıs easiest to describe CDSA by discussing the middle tier first. This layer consists of the Common Security Services Manager (CSSM), with a CSSM Security API making CSSM services available to client services and applications and a series of module interfaces that allow plug-in modules to carry out specific cryptographic services. Intelıs architects partitioned CSSM itself into a set of core services, context management services, integrity services, and a set of basic module managers. Core services common to all categories of security services include verifying, identifying, and dynamically attaching add-in security modules.
Module managers match API calls to one or more security provider interface (SPI) calls that result in an add-in service module performing the requested service. There is one module manager (MM) for each functional subset of the CSSM API, including the Cryptographic Services Manager, Trust Policy Services Manager, Certificate Services Manager, and Data Store Services Manager. Each of these module managers controls plug-in modules that implement the functionality defined by each API subset. The top layer of the CDSA model includes application-level security services and tools, which reside between application and basic CSSM services. Software at this layer may implement secure applications, provide security services for other applications, package CSSM services for developers using languages besides C, or provide tools to manage the security infrastructure.
Applications can invoke the CSSM APIs directly or use these top layer services to access services managed by CSSM. One common application for these services is to hide the addition of security capabilities to legacy services. For instance, developers can enhance services like the Sockets protocol and HTTP with security features for privacy and authentication. By accomplishing this without changing the service interface, they provide application developers significant enhancements without requiring changes to the application code. Another application for layered security services is a Java package, which defines object-oriented classes and methods by which Java applications and Java applets can use security functionality, provided by and through CSSM.
The bottom layer of the infrastructure is populated by various security add-in modules, which will be offered by vendors with specific capabilities and expertise with a particular cryptographic function. Each module will provide a set of services that conforms to one of the subsets of the CSSM API described above. The scope of services of each type of module is effectively predefined, although its implementation is not. As in CAPI, CSPs perform the basic crypto services needed to enable PKI, including bulk encryption, digital signature, and message digest (hashing). CSPs also provide secure key storage for local storage of private keys. A security provider can deliver a CSP as a piece of software, a hardware device, or a combination of both hardware and software.
Unlike CAPI, CDSA provides a mechanism for authorities and institutions to establish trust policies. Organizations establish trust policies to permit users or groups to perform specific actions, or classes of actions, such as creating a transaction or accessing a report. Trust Policy Modules implement these policies and establish the level of trust required to carry out specific actions. Certificate Library Modules will let applications create, sign, and verify certificates and certificate revocation lists. Because the data format of a given certificate determines these operations, developers will need to create modules for specific certificate formats. Data Storage Library modules provide stable storage for security-related data objects including certificates, keys, and policy objects. They may store these objects in the file system, a database, or on custom hardware devices.
Itıs important to note that CDSA defines an extensible architecture, which has allowed it to evolve over time. The most straightforward mechanism for extending CDSA has been through the definition of new Module Managers within the CSSM infrastructure and the development of Security Plug-ins that implement the new Module Managerıs API. A notable example of this development has been the collaboration of Intel and IBM on key recovery extensions to CDSA. This effort has resulted in the addition of a newly introduced Key Recovery Module Manager in CDSA version 2.0, the IBM Key Recovery Service Provider. KRSP is a plug-in module to IBMıs Keyworks framework, a CDSA-compliant security infrastructure. KRSP lets applications create key recovery fields, and works in conjunction with the IBM Key Recovery Server, which reconstructs keys from key recovery fields.
When my development team and I first became familiar with CDSA and CAPI, we were skeptical of the benefits that would accrue to us by rewriting our software to use one or the other of them. After all, the developers had worked hard to integrate RSAıs BSafe into our products. We were happy with the results and concerned that rewriting our applications to support an API would impose a performance penalty at the cost of obtaining capabilities that we were not certain we needed. Having gained the perspective of having more time pass since we completed our initial implementation, and having invested additional consideration into our overall security architecture, we now appreciate the benefits that an API approach offers.
For instance, we have come to realize that a purely software-based PKI has some disadvantages. Iıve become a believer in smart card technologies and expect to see businesses starting to install card-enabled keyboards over the next 18 months. Our software currently maintains keys in files that reside in the computerıs file system. Before the availability of an API-based security capability, we would have had to write largely distinct functions to generate, retrieve, and manage keys stored in the file system vs. those stored on smart cards. Smart-card based keys are more secure than software keys because they live in their ownersı pockets and are only revealed when necessary for encryption processes; they are also portable and can be used at any workstation with a compatible card reader. With the advent of an API and the availability of products that adhere to it, we only need to write these functions once, regardless of the underlying storage technology. We can even let customers plug in the desired technology when they install our products, based on their own security concerns and policies.
Other opportunities that have become increasingly important to us are international markets and businesses that want to deploy our solutions on non-Windows platforms. CDSA addresses both of these opportunities particularly well. Itıs possible to produce exportable applications using the approach I alluded to in the previous paragraph: Write the application to call security functions but do not distribute encryption algorithms (or distribute weak or restricted key encryption functions) with the application. If we do not distribute strong encryption, we do not need to apply for export authority. Instead we can let customers obtain and install strong encryption algorithms locally, in accordance with regulations and concerns. CDSA facilitates this mechanism by requiring that the security module manager in the CSSM and the module itself must authenticate themselves to each other when they load into memory. This authentication is based on the digital signature of each component and assures developers like us that our CDSA-compatible applications will be used with trusted, compatible security modules.
Vendor support for security frameworks is critical to ensure their extension to multiple platforms and fulfill the promise of allowing developers to implement once and use their solutions repeatedly. With respect to CDSA, IBM has taken the lead in commercializing the technology. It has announced that its implementation of a CDSA-compliant CSSM, the Secure Cryptography and Certificate Services (SCCS) toolkit, will be available for Solaris, HP-UX, and Win32, in addition to IBMıs own AIX, MVS, and OS/400 operating systems. IBMıs emphasis on Java, as well as a conversation I had with their Keyworks product manager, led me to believe that the company is working on a Java implementation as well.
In discussing IBMıs selection of CDSA as its security architecture, a couple of points struck me as salient. First, as a global provider of systems solutions, IBM determined that adopting an architecture that it could deploy globally without repeatedly obtaining regulatory approval was critical. Secondly, IBM was reacting internally to its own experience developing one-off cryptographic solutions for each of its products, all the while it was preaching reuse to its customers. For a company that delivers a product like Domino on 15 different platforms, this problem appears in spades. CDSA presented itself as a technology that IBMıs infrastructure team could use to offer significant benefits to developers of specific solutions within the company. In addition to Domino, IBMıs e-commerce suite, the certificate suite, and its SSL implementation will use its SCCS toolkit as the framework for security services.
IBMıs relationship with RSA and Security Dynamics in the rollout of this technology bears some further mention. RSAıs new Certificate Security Suite components and tools for developing certificate-based applications will incorporate IBMıs implementation of CDSA, including the KeyWorks key recovery extensions, and will provide support for IBMıs Key Recovery Service Provider technology. The Certificate Security Suite will include IBMıs CSSM implementation as well as CDSA-compliant security, such as RSAıs BSafe crypto engine for encryption and digital signature functions, an LDAP interface for seamless access to X.500 certificate directories, and a basic module for trust policy. RSA will also provide modules to access Security Dynamicsı own CDSA-compliant enterprise security solution, SecurSight.
The broad support for CDSA reflects the fact that it embodies an entire security framework. Not only is this a cross-platform solution, but it allows for third-party developers to participate in the development of pluggable infrastructure components and provides a business framework for vendor cooperation. CAPI is just the API to application-level security functions, and depends on the Windows NT security framework, including the Microsoft Certificate Server, to provide an entire security infrastructure. Nevertheless, we all know that Windows is the most widely deployed desktop operating system and presents a significant opportunity for developers of security solutions to offer CSPs.
Datakey Inc. has announced support for both CAPI and CDSA. The firmıs SignaSure CSP product uses that companyıs smart card or smart key tokens in a public key infrastructure to process and store private cryptographic data that enables user identification and authentication, secure data exchange, and information validation. It includes a hardware token, a reader/writer that connects to a computerıs serial port, and interface software that is recognized and validated by the API. Rainbow Technologies, developer of the "CryptoSwift" line of cryptographic accelerators geared primarily for commerce servers, provides plug-in modules for access from both the CAPI and CDSA. Both these firms are examples of a growing trend toward support of both APIs.
Both the CSSM API and CAPI provide an abstraction layer for security services, allowing applications to work consistently while remaining independent of underlying PKI implementations. But both CSSM API and CAPI are low-level interfaces that mainstream business application developers will find difficult to use. This barrier creates an opportunity for services that encapsulate these APIs and provide an additional abstraction layer.
For example, a JavaBean could abstract the use of a certificate. Vendors are developing implementation of entire security services, such as Secure Electronic Transaction (SET), on top of CDSA and CAPI. Instead of calling the API directly, an electronic commerce application can simply call the SET service. The SET service will use the underlying API to employ specific crypto services, such as digital signature and certificate retrieval, needed to complete secure transactions. While an attractive idea, high-level interfaces and toolkits based on standard (at least de facto standard) APIs have not yet become widely available.
As one of my colleagues at RSA pointed out, PKI and the information security industry that will implement it are both relatively immature. Over the next suggested months, we will see a virtual explosion of smart card solutions, security-enabled applications, single sign-on technologies, and certificate management systems. At the same time, the underlying frameworks and standards will continue to evolve. Given the tools available today, it would be prudent to experiment with developing a small-scale PKI and developing test applications using CAPI from Microsoft or early versions of CDSA from IBM or another CDSA provider. Once you are comfortable with the concept, you will want to consider whether a Windows-based solution will suffice for your organizations or whether you should step up to an enterprise-class CDSA solution. By then, CDSA CSSMs and CSPs should be available to support your work.
Figure 1. Under Microsoft's Crypto API architecture, applications use services packaged into one of five subsystems.
Figure 2. Intel's CDSA provides a layered architecture that defines common services in an extensible framework managed by independent Modules Managers.
What did you think of this article? Send a letter to the editor.