Novell's Controlled Cryptographic Services
Articles and Tips: article
01 Dec 1998
Discusses the enhanced security features in NetWare 5 which are built on NICI infrastructure and are written to the CCS API. Because these security features are built on NICI, it enables developers to solve difficult problems in providing exportable cryptography in applications. In short, Novell has done the "hard work" in making cryptography easy to use in applications, thus freeing the developer and the network administrator form these concerns.
- Introduction
- Novell International Cryptographic Infrastructure (NICI)
- The Controlled Cryptographic Services API
- Conclusion
Introduction
For a long time, the use of cryptography for supporting security services has been a problem for international software developers. Cryptographic technologies have been restricted by US and international laws. The restrictions have been so severe in some cases as to force developers to remove the cryptography from their products before they are allowed to ship internationally. Cryptography is the cornerstone of security services, but unfortunately its use and compliance with international regulations has complicated software development efforts.
The primary restrictions on exporting cryptography for world-wide consumption are:
Algorithm and key usage restrictions according to geographic region
Restrictions on replacing provided cryptographic algorithms with stronger algorithms
Stringent key recovery requirements
The Novell International Cryptographic Infrastructure, or NICI, is systematically designed to overcome these restrictions in a way that is secure and transparent to the application developer.
The value of NICI to third-party developers lies in its ability to solve the developer's use of standard cryptographic interfaces. Providing cryptographic algorithms through dynamic link libraries (such as DLLs or NLMs) allows circumvention or replacement of the approved cryptographic algorithms with unapproved or stronger algorithms. This is commonly referred to as "crypto-with-a-hole."
Historically, developers have solved the crypto-with-a-hole problem by statically linking the approved cryptography with their application into a single package that prevents replacement of the cryptographic libraries. Of equal concern has been the restrictions on algorithm and key usage, forcing developers to statically define the strength of the cryptography used. Traditional cryptographic libraries are of limited benefit if the libraries must be copied and modified for every instance of their use to service both domestic and export markets. This approach has forced developers to produce different versions of their products to meet different regional requirements. Different versions of the software also mean increased maintenance costs as well as increased production and distribution expenses.
With NICI, developers are able to package applications for export without the necessary cryptographic libraries hard linked into the application. Developers benefit from a dynamically linkable library where the restrictions on the use of cryptography are enforced internally by NICI. This allows developers to maintain a single, commodity version of their software product for worldwide distribution.
NICI utilizes a policy-based architecture. Key usage and key archiving is enforced through dynamically loadable policies. The application is independent of, and yet controlled by, the internal governing policies. This means that restrictions on the use of cryptography are transparent to the application developer.
NICI is also a modular architecture, supporting replaceable cryptographic algorithms. Replaceable cryptographic algorithms can provide for special cryptographic needs, both present and future, alleviating the developer from these concerns. Developers receive the benefits of flexible and current technologies without modifying their software products, and can also be confident that their customers are receiving the strongest cryptography available on a regional basis. NICI ensures infrastructure integrity through an integral Operating System loader and module verification. Module verification uses strong digital signatures based on a public key infrastructure, which is supported through a high assurance root certification authority.
The export of strong cryptography (e.g. DES, Triple-DES, etc.) for general purposes of data confidentiality is currently restricted by U.S. export laws to systems which incorporate mandatory and integral key recovery capabilities. NICI currently implements key recovery for purposes of user-oriented disaster recovery and has been designed to facilitate law-enforcement oriented key recovery (key escrow) in the future, if required. Disaster key recovery is the ability to restore keys critical to recovery of data that is required to restore operations of a customer's business. This requirement is independent of key recovery for law enforcement purposes which is typically addressed through some form of key escrow. The ability to export strong cryptography world-wide by virtue of integral key recovery is attainable with NICI. None of these features are significant without assurances in the security of the infrastructure supporting the cryptographic services, in particular the policy enforcement mechanisms.
Assurances in the security of the infrastructure require rigorous design based on sound security principles, and independent third party evaluations of the system against industry accepted standards for secure systems. Cryptographic services provided by NICI are integrated with Novell Directory Service (NDS), Novell Public Key Infrastructure Services (PKIS), and Secure Authentication Services (SAS). These components synergistically provide the foundation for secure network services.
The value of NICI's architecture is evidenced in its contributions as viewed by import/export approval agencies. However, security of network services (specifically cryptographic services) used by applications will become more pronounced as the demand for E-commerce and other security-reliant Internet applications increase. NICI provides this level of assurance, and applications developed to the CCS interface can expect to receive favorable consideration for US export, and import into many restrictive world regions.
Novell International Cryptographic Infrastructure (NICI)
The NICI concept was introduced to the U.S. Government in a report where three fundamental aspects of NICI were identified:
Cryptographic loadable and replaceable modules
Key generation SDK
Cryptographic key controls
With NICI, the cryptography embedded in NetWare and the cryptographic services provided by or added to NetWare are modular. Cryptographic functions are encapsulated in the form of dynamically loadable modules that are replaceable and extensible only by Novell and authorized third parties as necessary to conform to the appropriate national policies, and to provide various cryptographic technologies in response to customer needs.
The replacement of cryptographic modules is controlled. The only cryptographic functions that are accessible are those standard APIs where policies govern their use, and the policies are those that are specially licensed by Novell or Novell-authorized agencies. A digital key certification hierarchy based on cryptographically strong digital signatures is used to separately license cryptographic modules and policies, thus facilitating third party cryptographic module development (this authentication of modules, of course, refers to modules in the infrastructure, and not applications written to use the services).
NICI is a layered, hierarchical infrastructure which divides cryptographic functionality among four distinct layers. The functionality of each layer is provided by dynamically-loadable, digitally-signed modules of the type: Cryptography Library (XLIB) modules which implement particular uses of cryptography and can provide interfaces to untrusted applications; Cryptography Manager (XMGR) modules which implement key management, enforce key use policies, and provide algorithm management services to XLIBs; Cryptography Engine (XENG) modules which implement the actual cryptographic algorithms; and Cryptography Engine Support (XSUP) modules which supply a restricted subset of operating system services to XENG modules. Each layer supports segregation of modules by authenticating the digitally-signed modules before loading, and by controlling the hierarchy of modules through controlled interfaces. NICI controls access to the cryptographic functionality through this hierarchy of interfaces, as well as access to the keying materials. Thus, the services offered by CCS are restricted in what it can do, and what it can access.
Novell is providing a Common Cryptographic Services (CCS) API to developers. CCS is an XLIB with an interface (API) that is a higher level abstraction of cryptographic services provided by the cryptography manager. Access to the CCS APIs is controlled through a dynamic linking and binding mechanism with the application. Application developers must statically link a small footprint CCS access library into their applications in order to dynamically access the CCS cryptographic APIs. Novell licensing restrictions and the CCS SDK binding mechanism protect the integrity of the infrastructure, satisfying the requirement that cryptographic functionality is protected from modification and replacement.
Additionally, private and secret keys generated by NICI are accessible only in wrapped form outside of the infrastructure (i.e., to applications). A NICI wrapped key includes the key value itself as well as control attributes, which are bound together. The wrapping process provides confidentiality for the key itself and integrity protection for the control attributes. Keys are wrapped to insure that control attributes of the keys can be verified at time of use. Policies govern algorithm and key usage, as well as key archiving, by referencing these control attributes. The integrity of the NICI architecture provides assurances in policy enforcement; and controlled access of the keys insures the integrity of the control attributes used in policy enforcement. In this way, import/export concerns on key usage and archival requirements are satisfied. Integral key archiving provides the basis for key escrow capability in future releases to meet whatever changing import/export requirements might exist in the future.
Policies are required to govern algorithm and key usage, and to insure integral key archiving for secure key recovery and the enabling of key escrow. The separation of policy enforcement from module integrity verification is a unique feature of the NICI architecture. Dynamically loadable policies are digitally signed separately from modules to allow separation of certifying authorities. Separate signing of modules and policies facilitates third party development of certain modules, such as the cryptographic engines, whose actions are constrained by the policies. The cryptographic engines (XENG) are constrained by key usage policies; and key generation through the cryptography manager (XMGR) is governed by archiving policies. Because policies are changeable within NICI, policy enforcement is transparent to, and unaffected by applications, which forms the basis for favorable import/export licensing consideration. Applications that use the CCS library enjoy these benefits.
The Controlled Cryptographic Services API
The CCS API provides an interface for cryptography and key management that is independent of any specific cryptographic algorithm. This API is intended to provide a stable platform for the development of applications consuming cryptographic services where modular replacement of the underlying implementation will not affect the interface definitions. The types of services provided by the CCS API include:
Interface initialization and configuration
Random number generation
Information about available algorithms
Encryption and Decryption
Obfuscation and De-obfuscation
Message Digesting
Signature and Verification
Key Management
Symmetric key generation
Asymmetric public/private key Generation
Key wrapping
Certificate Management
Create and sign public-key certificates
Create and sign public-key certificate from PKCS#10 requests
Load and verify certificates
Secure Socket Layer Support Services
The complete CCS development kit will be available through the Novell Software Developer Kit (SDK) that may be used from native language such as "C" and through a Java class.
Conclusion
Novell has built all its enhanced security features in NetWare 5 on the NICI infrastructure and all these services are written to the CCS API. These services include Novell's Public Key Infrastructure Services, Novell Secure Authentication Services, and Secure Socket Layer services. Additionally, packet signatures are implemented in NetWare 5 using the NICI infrastructure and the CCS APIs.
Because these security features are built on NICI, it has allowed Novell to deliver and maintain a single set of server modules for NetWare 5 for world-wide consumption. This benefits Novell in reducing configuration management, operational, and packaging expenses. It also benefits developers and network administrators by solving the three difficult problems in providing exportable cryptography in applications: 1) geographic region difference in cryptographic algorithms, 2) removing cryptography from the application in a way that does not promote crypto-with-a-hole, and 3) complying with stringent key recovery requirements. Additionally, because applications written to the CCS API contain no cryptography within them, application developers can expect to receive expedited U.S. export approval. In short, Novell has done the "hard work" in making cryptography easy to use in applications, and thus freeing the developer and the network administrator from these concerns.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.