With NICI It's All Holes Barred
Articles and Tips:
01 Dec 1998
Novell International Cryptographic Infrastructure (NICI) is the sort of name that you don't forget, even after seeing or hearing it only once. The full name of this NetWare 5 feature is too much of a mouthful to go unnoticed, and the acronym--NICI--is too catchy to forget. If you are like most network administrators, however, you know very little about this new NetWare 5 feature.
As the name suggests, NICI is a modular infrastructure of network cryptographic services. (For definitions of NICI and NICI-related terms, see "Crypto Lingo.") NICI already supports a number of cryptographic algorithms--including Data Encryption Standard (DES); Triple DES; RC2; RC4; Rivest, Shamir, and Aldeman (RSA)--and has the potential to support countless more. And here's perhaps the best news: NICI complies with the international import and export restrictions governing the use of cryptography. You realize what that means, don't you? With NICI, you can use the strongest cryptographic algorithm legally allowed in the country in which you're running NetWare 5.
As laws restricting the use of cryptographic algorithms relax, NICI will allow you to easily upgrade the cryptography on your company's network without worrying about complying with local cryptographic laws: Each Novell-approved upgrade to NICI will be legal. As laws relax and new algorithms emerge, Novell and other third-party developers will create new NICI NetWare Loadable Modules (NLMs) that contain the new cryptographic algorithms. When you install the new NICI NLMs, all of the NICI-based applications on your company's network will automatically have access to the newer and stronger algorithms on these NLMs.
NICI also simplifies network management, particularly global network management. To comply with the wide range of international restrictions on cryptographic products today, you might have to run multiple versions of the same application that provides cryptographic services. That is, you might have to run a different version for every country in which your company has a branch office. In contrast, you need run only one version of a NICI-based application for any of your branch offices--whether those offices are located in the United States, Germany, France, Argentina, or even Russia.
Although NICI may be good news for you, it's even better news for developers. In fact, "if you were to ask, 'Who will most likely be excited about NICI?" says Roger Schell, corporate security architect at Novell, "the answer would be 'developers.'" Developers should be excited about NICI for several reasons:
Developers who want to create an application that provides cryptographic services for worldwide consumption can build and ship just one version of this application.
Developers who build NICI-based applications will obtain export approval in less time and with less hassle because NICI has already met the U.S. government regulations on the exportation of cryptographic products.
Developers who write NICI-based applications can save money. Typically developers who write applications that provide cryptographic services have to purchase rights to use a cryptographic library from a company that provides such libraries, such as RSA Data Security Inc. In contrast, developers who write NICI-based applications pay no royalties for the use of cryptographic code. And that pragmatic point, Schell claims, is precisely "why developers will care about NICI."
MODULAR CRYPTO
Before you can determine how you or anyone else will benefit from NICI, you need to understand how it works. (See Figure 1 .) And to understand how NICI works, you need at least a brief introduction to the dynamically loadable NLMs that comprise NICI:
Figure 1: The architecture of NICI
Cryptography Library or XLIB modules
Cryptography Manager or XMGR modules
Cryptography Engine or XENG modules
Cryptography Engine Support or XSUP module
Cryptography Interface Manager or XIM module
Technically, any one server running NetWare 5 could have more than one of each of the following NICI NLMs: XLIB, XMGR, and XENG. But there is only one XSUP and only one XIM for every NetWare 5 server.
The discussion that follows is a general introduction to NICI architecture and, as such, is far from exhaustive. However, this discussion should provide you with enough details about the purpose of each NICI module for you to gain at least a basic understanding of NICI architecture.
XLIB--THE MIDDLEMAN BETWEEN APPLICATIONS AND NICI
An XLIB is a collection of cryptographic services, such as user data encryption and decryption services. Applications request XLIB services via an XLIB Application Program Interface (API). To deliver the services that applications request, the XLIB communicates with an XMGR, which in turn communicates with an XENG. In other words, an XLIB is the middleman between applications and NICI: XLIBs accept requests for cryptographic services and interact with NICI to provide these services to applications. Applications have no contact with NICI except through an XLIB.
NetWare 5 currently ships with only one XLIB, the Controlled Cryptography Services (CCS) XLIB. Most of the cryptographic services an application might need are available in the CCS XLIB via the CCS API. Novell has included the CCS API in the Novell Developer Kit (NDK) since October 1998. (For more information about the CCS API, see http://developer.novell.com/ndk/cryptlib.htm. If you are a developer, you might want to click the Documentationlink, which allows you to download a .pdf document titled "Controlled Cryptography Services Software Development Specification.")
The CCS API supports the development of server-based cryptographic applications for NetWare. This API provides an interface for the following cryptographic services:
Encryption
Decryption
Certificate creation
Certificate verification
Signature verification
Message digest creation
Random number generation
The CCS API also includes options for various algorithms and algorithm key types. Because the U.S. Department of Commerce has granted Novell approval to export NICI as a mass-market product, NICI-based applications are subject to a comparatively short, one-time export review process. U.S. developers need only demonstrate that in building their NICI-based application they used the CCS API properly and they included no additional cryptographic functionality. (Naturally, developers outside the U.S. are subject to the export review processes conducted in their own country.)
Although NetWare 5 includes only one XLIB, Novell recognizes that the need for application-specific XLIBs may arise. As a result, Novell and other third-party developers can develop application-specific XLIBs. However, Novell intends to expand the CCS XLIB and the CCS API to provide additional services rather than writing numerous application-specific XLIBs.
By providing only the CCS XLIB, Novell offers developers a more flexible development environment. If Novell wrote application-specific XLIBs, Novell alone could provide the particular services contained in these XLIBs. For example, if Novell built an application-specific XLIB for Secure Sockets Layer (SSL) support, Novell alone could provide SSL, explains Schell.
"In other words," Schell sums up, "we could have said, 'We've got SSL, and no one else can build SSL on top of NICI.' But that's not what we think makes sense." What makes sense to Novell is providing one XLIB and one API that enables developers to access any NICI service. That way, developers can write their own version of SSL and other services.
XENG--THE NICI WORKHORSE
In the hierarchical order of the NICI modules, XMGRs are next because XLIBs access only XMGRs, which in turn access XENGs on that system. (See Figure 1.) However, understanding XENGs will help you better understand what XMGRs do.
An XENG is a NICI workhorse: An XENG processes the actual algorithms used to provide cryptographic services, such as encryption, decryption, message digest creation, and digital signature verification. NICI provides several XENGs, which include a variety of cryptographic algorithms such as DES, Message Digest 5 (MD5), and RSA.
How Do You Take Your Crypto?
NICI currently provides three XENGs to accommodate the laws of the various regions in which Novell ships NetWare 5. Novell cannot ship the same XENG all over the world because certain countries, notably France and Russia, restrict the importation or use of U.S. cryptography.
To resolve the dilemma caused by these restrictions, Novell includes different levels of cryptography in NetWare 5. The level of cryptography you get with NetWare 5 depends on the country in which your company operates. Novell offers three levels of cryptography provided by three XENGs:
The Null XENG provides no cryptography for countries that restrict the importation or use of U.S. cryptography (including France and Russia).
The Worldwide XENG includes the Null XENG and also provides 40-bit encryption for countries that allow the importation of 40-bit encryption. For example, Novell ships the Worldwide XENG to most European countries.
The Domestic XENG includes the Null XENG and provides both 40-bit and 128-bit encryption for the United States and Canada.
The Null XENG--What's the Point?
After reading the descriptions of the XENGs NICI provides, you might justifiably ask: "What's the point of the Null XENG? After all, it provides no encryption." The Null XENG enables Novell to ship only one version of NetWare 5--without having to rewrite code in the applications that depend on NICI.
Without the Null XENG, Novell would have to release a version of NetWare 5 that did not include NICI for countries to which Novell is unable to ship NICI. If Novell shipped versions of NetWare 5 that did not include NICI, Novell and third-party developers would no longer be able to build one application for worldwide use. Instead, Novell and third-party developers would have to rewrite application code to tell the application what to do when NICI is not available.
The Null XENG ensures that applications will not break or abend the server: Applications just use whichever XENG is available--even if that means using an XENG that provides no cryptography. Hence, the Null XENG enables you to run the same version of a NICI-based application in all branch offices, regardless of where those offices are located.
The Level of Security Lies in the Key
As mentioned earlier, the Worldwide and Domestic XENGs provide 40-bit and 128-bit encryption, respectively. These bit sizes refer to the size of the key that is legally allowed for use with symmetric algorithms for encrypting and decrypting user data.
In the context of cryptography, a key is one value in a large range of possible values. The strength of a key depends on how large the range of possible values is. The range of possible values and, therefore, the strength of a key is defined by the key's bit-size.
For example, with a 56-bit key, only one value among 256possible values is the correct key. Likewise, for a 128-bit key, only one value among 2128possible values is the correct key. As you have probably deduced, the larger the possible number of values, the stronger the key. (For more information about keys, see the sidebar "The Key to Security,"NetWare Connection, Feb. 1998, p. 12. You can download this sidebar from http://www.nwconnection.com/feb.98/vpn28/thekey28.html.)
In cryptography, key-based cryptographic algorithms use keys for user data encryption and decryption, message digest creation, data signature verification, and other cryptographic functions. Two types of key-based algorithms are available: symmetric algorithms and asymmetric algorithms.
In symmetric algorithms, the encryption key can be calculated from the decryption key and vice versa. The Worldwide XENG and the Domestic XENG contain a number of symmetric algorithms, including DES, RC2, and RC4. In addition, the Domestic XENG includes Triple DES. (Triple DES cannot be included on the Worldwide XENG due to U.S. export restrictions.)
In asymmetric algorithms, the key used for encryption is different from the key used for decryption, and the decryption key cannot practically be calculated from the encryption key. These algorithms are often called public-key algorithms because the encryption key can be made public. The decryption key, however, must remain private. Today the Worldwide XENG and the Domestic XENG contain only the RSA public-key algorithm.
Countries sometimes establish certain restrictions for key sizes that are used to encrypt and decrypt user data and other restrictions for key sizes that are used to authenticate users or to encrypt other keys. For example, the United States allows the exportation of only a 40-bit symmetric key for encrypting user data but a 64-bit symmetric key (or 512-bit asymmetric key) to encrypt other keys.
When Novell says that the Worldwide XENG provides 40-bit encryption and the Domestic XENG provides 128-bit encryption, Novell means that the Worldwide XENG enables applications to use a symmetric key of 40 bits to encrypt and decrypt user data. Likewise, the Domestic XENG enables applications to use a symmetric key of 128 bits to encrypt and decrypt user data. The keys NICI uses for other cryptographic purposes (such as keys used to encrypt other keys before transmitting them) are stronger. (For more information about the keys NICI uses internally for key management, see "A Key for Every Occasion.")
Upgrading to Stronger Cryptography
The U.S. laws in effect at the time NICI was developed dictated the use of 40-bit encryption for export and 128-bit encryption for the United States and Canada. Because NICI has a modular architecture, however, you can easily add a NICI XENG when you need to upgrade to a higher strength cryptography. As Novell and other third-party developers create additional XENGs, you will be able to purchase and install these XENGs as your company's needs and government regulations change.
When you install new XENGs, all of the applications on your company's network that use NICI will automatically have access to the new cryptography available on the XENG(s) you install. (For more information about the applications included with NetWare 5 that use NICI services, see "NetWare 5's NICI Consumers.")
In fact, if your company received the NetWare 5 CD-ROM that included only Null and 40-bit encryption, you might soon be able to upgrade to 56-bit DES encryption. Novell began making plans for such an upgrade weeks after the Sept. 16 statement from the U.S. Office of the Press Secretary. (You can download this press statement from http://www.jya.com/wh091698.htm.)
This statement announced that the Clinton Administration had relaxed the policies regarding the use and exportation of cryptography. The new guidelines "allow encryption hardware and software products with encryption strength up to 56-bit DES or equivalent to be exported without a license" to all users (except those in the seven countries to which the United States prohibits the exportation of any product, namely Iran, Iraq, Libya, Syria, Sudan, North Korea, and Cuba).
Novell reacted immediately to this news, seeking verification from the U.S. government that it could provide 56-bit DES encryption or the equivalent--which is 64,000 times more powerful than 40-bit encryption--to its customers in countries where these export guidelines apply. By Nov., the U.S. government had given Novell approval, and Novell began fine-tuning an upgrade.
XMGR--THE NICI POLICE
In addition to receiving service requests from XLIBs, XMGRs enforce NICI policies, which dictate the size and use of the keys that can be used with the cryptographic algorithms in XENGs. One XMGR, the Key Generation XMGR, actually generates some of the keys that NICI uses. (For more information about the keys NICI uses, see "A Key for Every Occasion.")
Novell creates all NICI policies, which are based on the U.S. government restrictions governing the size of the key that can be used with a particular algorithm and for a particular purpose.
NICI policies are inextricably bound to XENGs. This interdependency and the fact that Novell alone writes the policies is one of the reasons the U.S. government granted Novell export approval for NICI as a mass-market product. Novell will not ship an XENG without a NICI policy, which controls exactly how the cryptographic algorithms in that XENG can be used. If an XENG did not have an accompanying NICI policy created and signed by Novell, you could not load the XENG.
XMGRs also select the appropriate algorithm to complete an XLIB request. Not all algorithms are well-suited for all cryptographic functions. For example, although Digital Signal Algorithm (DSA) can implement sign and verify functions (functions used to digitally sign an object and to verify digital signatures), DSA cannot implement encrypt or decrypt functions on user data. Similarly, although DES is a good choice for data encryption, DES might not be the best choice for digitally signing an object.
For each requested cryptographic function, an XMGR has a set of algorithms from which to choose. An XMGR selects one of these algorithms unless an application specifies a particular algorithm.
For example, suppose a company in the United Kingdom were running NICI and that an application on the company's server requested to encrypt a user data file. The XLIB would send this request to the XMGR, which would immediately check the policy associated with the server's XENG--in this case, the Worldwide XENG. This policy would specify that the Worldwide XENG in use on this server could use a 40-bit symmetric key to encrypt the data. The XMGR would then probably select the DES symmetric algorithm (unless the application explicitly requested another algorithm) and employ a 40-bit key to encrypt the user data file.
XSUP and Other Operating System Services
In summary, XLIBs accept requests for services from applications and forward these requests to XMGRs. Only XMGRs can communicate with XENGs, and XMGRs administer NICI policies to ensure that the algorithms the XENG contains are used appropriately at all times. If XLIBs can communicate with XMGRs and XMGRs can communicate with XENGs, which NICI module can the XENG communicate with? Only one: the XSUP module. XENGs do not have access to the NetWare operating system. Instead, XENGs can access only the XSUP, which supplies a restricted subset of operating system services, such as memory and thread management services.
Providing a restricted subset of operating system services to the XENG ensures that the particular XENG remains untouchable (except by the XMGR) and, therefore, more secure. Because Novell provides these operating system services in a separate module, government authorities can inspect these services in isolation from the rest of the NetWare operating system.
Some of the NICI modules--namely XLIB, XMGR, and XSUP--are statically linked to another subset of operating system services. Although these operating system services are not technically part of the NICI architecture, they do serve a NICI-related purpose.
Why is it necessary to have this second subset of operating system services? Actually, if Novell planned to offer NICI only on the NetWare platform, this subset of operating system services would not be necessary. But with an eye toward the future, Novell made it possible to port NICI to other platforms without having to rewrite any source code.
"When we move NICI to a different operating system," says Schell, "we won't have to change anything except that abstraction of operating services." Whether NICI runs on NetWare 5, Windows NT, or UNIX, the NICI modules will have the operating services they need.
XIM CHECKS ID BEFORE ADMITTING
The XIM is part of the NetWare 5 NLM loader and is responsible for loading legitimate NICI modules. Before the XIM installs NICI modules and every time it loads NICI modules, the XIM checks the digital signature appended to the XLIB, XMGR, XENG, and XSUP modules, ensuring that these modules are legitimate and unchanged.
NICI's Certificate Authority Hierarchy
How does checking the digital signatures of NICI modules ensure that they are legitimate and unchanged? To answer that question, you first need a better understanding of digital signatures and their connection to digital certificates.
Digital certificates are chunks of information that a Certificate Authority (CA) binds together using a digital signature. Each NICI module is accompanied by a digital certificate that has been generated by a Novell-based CA hierarchy. The certificates NICI uses include information such as the name of the party that created the certificate, which should be Novell or a Novell-authorized agent, and the certificate quality, which indicates the security level of the system that generated the certificate.
A program called the NICI Module Signer generates and signs NICI certificates. The NICI Module Signer runs on an XTS-300 Trusted Computing System from Wang Government Services Inc. This system is stored in a highly restricted area at Novell and maintained by Novell Operations. The National Computer Security Center (NCSC) has rated this system as providing a B3 security level.
The NCSC is a U.S. government organization that evaluates computer systems to determine their level of trust. To conduct these evaluations, the NCSC uses an international standard called the Trusted Computer System Evaluation Criteria (TC-SEC, otherwise known as the Orange Book).
The TC-SEC are divided into four divisions: D, C, B, and A. The divisions are hierarchical, with the highest, Division A, reserved for systems that provide the most comprehensive security.
Divisions C through A include subdivisions, which are called classes: C1, C2, B1, B2, B3, and A1. These six classes are also hierarchical: The higher the number, the greater the level of protection provided. In other words, B3 is the highest level of trust a B-division system can provide and second only in level of trust to an A1 system, which provides the highest level of trust available in any system. (For more information about the NCSC and its security ratings, see "NetWare 4: The Climb to C2,"NetWare Connection, Nov./Dec. 1995, pp. 6-14. You can download this article from http://www.nwconnection.com/nov-dec.95/nw4clin5.)
Novell's high-assurance Wang system houses the public and private key pairs of a CA hierarchy that is one of the things that makes NICI unique. The proposed root of this hierarchy is a commercial CA that will provide certification services and associated liability protection. Novell is currently involved in discussions with a commercial CA that may take over the root of this CA hierarchy. For now, however, Novell itself acts as the root CA.
Underneath this proposed commercial root are two subhierarchies:
The Key Escrow CA
The Novell CA
The Key Escrow CA includes an RSA key pair that the Novell Key Generator (another program that runs on the Wang system) generates from random data. All NICI key archival keys, which are used to encrypt and sign any NICI-generated keys that need to be archived, stem from this root Key Escrow RSA key pair.
The Novell CA includes the root public and private key pair from which other NICI key pairs are generated. This root key pair is an RSA key pair (with each key being 2,048 bits) that the Novell Key Generator generates from random data. The private key from this Novell CA RSA key pair remains on the Wang system. The public key and its public-key certificate are embedded in the NICI XIM. The XIM uses the Novell CA public key and associated certificate to verify the digital signatures on NICI modules before loading these modules.
Signed, Sealed, Delivered
A digital signature is appended to each NICI certificate to identify and authenticate the sender (which should be Novell) of that certificate (which is one in a hierarchy of certificates). To digitally sign the NICI certificate, the NICI Module Signer uses a one-way hash function to generate a string of bits called a hash-code from the certificate. The NICI Module Signer then encrypts the hash-code with the Novell CA private key, which is stored on the Wang system.
When an XIM receives a NICI module, the XIM uses the Novell CA's public key (which is embedded in the XIM code) to decrypt the certificate and the hash. The XIM then recomputes the hash-code from the certificate, again using the Novell CA's public key.
The hash-code the XIM computes will be identical to the hash-code accompanying the NICI certificate only if the certificate (and, therefore, the NICI module) has not been modified in transit. If the two hash-codes are equal, the XIM knows the NICI module has not been corrupted and it was in fact signed by Novell.
CRYPTO-WITH-A-HOLE?
Given the modular design of NICI and its dynamically loadable modules, how does Novell ensure that you or somebody else doesn't subvert the legal cryptographic services NICI provides by substituting unlicensed, illegal cryptographic services? This problem, called crypto-with-a-hole, is a potential problem for any product that provides cryptographic services and a problem that the U.S. government diligently searches for during an export review process.
According to Schell, urban legend holds that the term crypto-with-a-hole arose from an incident involving cellular phones. According to this legend, a cellular phone company wanted to export cellular phones that had encryption chips, but the U.S. government said "No." Purportedly, an engineer skirted the U.S. government's explicit restriction by including a socket on the cellular phone board so someone else could insert the encryption chip of their choice. "Clearly," Schell adds with a chuckle, "this subverted the intent of what the government was trying to do."
Whether or not this legend is true, it could have happened and could happen still were it not for current U.S. government regulations. These regulations prohibit companies from shipping hardware or software products that have a cryptographic hole that someone else could plug with any type and strength of cryptography. Other countries such as France have similar import restrictions that prohibit companies from importing products with holes that might enable users to insert their own cryptography.
To avoid this crypto-with-a-hole problem, developers who want to write applications for worldwide consumption typically have little choice but to write a different version of the same application. Each version would have to support the type and strength of cryptography acceptable to each country's import and export laws for cryptography. In the best case scenario, developers would write two versions of their application: one version to appease the restrictions on the use of cryptography in their own country and another version to pass their country's export restrictions or the import restrictions of the country to which developers wanted to ship their product.
Ideally, developers would like a modular approach to cryptography. However, dynamically loadable modules create the threat of crypto-with-a-hole: Pop out the module executing the cryptographic algorithms, pop in your own module, which executes a stronger version of that algorithm, and voil--you have subverted the cryptography provided by that particular application. Good luck trying to pull a stunt like that with NICI. NICI ensures crypto-without-a-hole.
As stated a number of times, NICI has earned an export license from the U.S. government and has been approved for use in countries such as France and Russia, both of which have tight cryptographic import restrictions. In part, NICI has managed to gain these licenses because NICI guards against crypto-with-a-hole. How? NICI ensures that you and others cannot subvert the cryptographic services it provides through several means.
For example, the CA hierarchy housed on the Wang system ensures that NICI cannot be subverted. According to Schell, the Wang system enables Novell to stake its corporate life on the security of the private key at the root of the CA hierarchy. The security of this private key is essential: Armed with the private key at the root of the CA hierarchy, someone could forge a signature on a non-NICI cryptographic module. But because the private key is absolutely secure, the U.S. government feels confident that no one will be able to subvert NICI by forging digital signatures.
The XIM further ensures that NICI cannot be subverted. Because the XIM checks the digital signature on the certificates that accompany NICI modules before loading these modules, the XIM ensures that no one could substitute a nonauthorized module for a NICI module. This ability to verify the legitimacy of NICI modules before installing and loading them is assurance against crypto-with-a-hole and one of many reasons the U.S. government gave Novell approval to export NICI worldwide.
NO HOLES WHEN MABLE'S AROUND
Another defense against crypto-with-a-hole and another reason Novell gained U.S. export approval is NICI's use of Module Authentication and Binding Library Extensions (MABLE) technology. MABLE technology is arguably Novell's leading defender against the threat of someone subverting NICI cryptographic services. MABLE authenticates the NICI CCS XLIB to an application and continually binds the two, creating a dynamic link that is essentially as strong as a static link. This strong link ensures that someone using a NICI-based application cannot easily replace or subvert NICI's cryptographic components.
MABLE uses a public-key challenge-response authentication protocol to authenticate NICI to an application when the application is initialized and before that application uses any NICI services. This authentication process proves to the application that it is about to use legitimate NICI services. In other words, Schell explains, "The application makes sure it is talking to the real NICI."
After this initial authentication, MABLE provides ongoing binding between the NICI application and the CCS XLIB to ensure that the application continues to speak to the real NICI for the duration of a session. "It's one thing to authenticate at the beginning of a session," explains Dan Fritch, NICI development manager, "but you have to ensure that somebody doesn't just authenticate at the beginning of a session and then later say, 'I'll jump in during the middle of the session and use NICI however I want.' So we have to do an ongoing binding. That way, you can't just trivially replace a NICI module after you've authenticated it."
SEEING PAST THE CRYPTIC NATURE OF THE NICI ARCHITECTURE
Not surprisingly, the NICI architecture is a bit cryptic. However, the following thumbnail sketch of the NICI architecture at work might help make the essence of NICI a bit more plain: Suppose an application requested to encrypt a particular file. The application would access the CCS XLIB's data encryption service via the CCS API. The CCS XLIB would then speak to an XMGR, saying, in essence, "I want this file encrypted."
After receiving the request for user data encryption, the XMGR would check the policy dictating the use of keys and algorithms on that particular server. Assuming the application were running on a server installed in the United States or Canada, the XMGR could select 128-bit Triple DES on the Domestic XENG.
The XMGR would then send the request to the appropriate interface on the Domestic XENG, which would execute the algorithm to encrypt the file and return the results to the XMGR. The XMGR would return the results to the CCS XLIB, which would, in turn, return the results to the application.
START SINGING
Three groups primarily benefit from NICI: Novell, NetWare 5 administrators, and NetWare 5 developers. Novell benefits from NICI because Novell can create one version of NetWare 5 applications and services for worldwide use. When applications are written to use the services the CCS XLIB has to offer, those applications can run on any NetWare 5 server, in any country, using whatever level of cryptography that NICI provides on that particular server.
NetWare 5 administrators benefit because upgrading their company's cryptographic services is as easy as installing a new NICI module. Once the upgrade is in place, all of the applications that use cryptographic services will automatically have access to the latest, greatest, and strongest cryptography available. In addition, NetWare 5 administrators have to manage only one version of NetWare 5 and only one version of any NICI-based applications they are running.
Finally, NetWare 5 developers will benefit because they can write one version of an application that uses cryptographic services and that version can be used worldwide. Because the application uses NICI services, rather than providing its own cryptographic services, developers save time in the development cycle and in the export approval process. Furthermore, developers who use NICI save money because they don't have to find a cryptographic supplier and pay that supplier for use of a cryptographic library.
In short, NICI will have many of you singing new words to the 1980s song "Mickey": "Hey NICI you're so fine. You're so fine you blow my mind! Hey NICI!"
Linda Boyer Kennard works for Niche Associates, an agency that specializes in writing and editing technical documents. Niche Associates is located in Sandy, Utah.
NetWare Connection, December 1998, pp. 8-20
Crypto Lingo
Authentication. In the context of digital security, authentication refers to the act of ascertaining the origin of a message to verify that the message actually comes from who it claims to come from. Authentication ensures that an intruder cannot masquerade as someone else. Digital certificates provide one way of ensuring the authenticity of a message. (See also confidential, integrity, and nonrepudiation.)
Certificate Authority (CA). A trusted party (typically a company) that issues digital certificates to other parties (organizations or individuals) to allow those parties to prove their identity. A CA might be an external company, such as VeriSign, or an internal organization, such as a corporate IS department.
Confidential. In the context of digital security, confidential describes a message that is undecipherable to all except those for whom the message is intended. Keeping messages confidential is the primary purpose of cryptography. (See also integrity, authentication, and nonrepudiation.)
Cryptography. The art and science of keeping messages secure.
Crypto-With-a-Hole. Refers to a potential problem in cryptographic products. The cryptography that is legally allowed within the country where the product is being used may have a "hole." Users can then fill the "hole" with whatever type and strength of cryptography they choose. NICI avoids the crypto-with-a-hole problem in several ways, including using MABLE technology and checking the digital certificate of each digitally signed NICI module before loading that module. (See also digital signature and Module Authentication and Binding Library Extensions.)
Digital Certificate. Multiple pieces of information that are bound together using a digital signature and sent with a message so that, upon checking the certificate, the recipient of the message can verify the authenticity and integrity of that message. The pieces of information bound together in an X509 certificate (which is the type that accompany all NICI modules) include the sender's name and public key.
NICI certificates also include the following attributes: key quality, certificate quality, and enterprise ID. These attributes indicate the security level of the system that generated the public-private key pair and the certificate, and also identify the organization responsible for generating the certificate.
Digital Signature. Extra data appended to a message that identifies and authenticates the sender and message data. Digital signature is the technology used to bind together the information in a digital certificate. To digitally sign a message, the sender uses a one-way hash function to generate a string of bits called the hash-code from the message data. The sender then encrypts the hash-code. The receiver decrypts the hash (and possibly the data) and recomputes the hash-code.
The hash-code the receiver computes will only be identical to the hash-code from the sender if the message has not been modified in transit. If the two hash-codes are equal, the receiver can be sure that the data has not been corrupted and that it came from the claimed sender.
Encryption. The process of disguising a message to ensure its contents remain secret from all but those intended to see that message.
Integrity. In the context of digital security, integrity describes a message that has not been modified in transit. The receiver of a message should be able to check the integrity of that message so that intruders cannot substitute false messages for legitimate ones. Digital signatures provide one way of ensuring the integrity of messages. (See also digital signature, confidential, authentication, and nonrepudiation.)
Module Authentication and Binding Library Extensions (MABLE). Novell technology that authenticates an application module to a NICI cryptographic library module before allowing the application to use NICI. MABLE also provides an ongoing binding mechanism between the two modules. Together MABLE authentication and binding provide a coupling between an application and supporting cryptographic library that is virtually as strong as a static link. Because of this strong binding, NICI cryptographic components cannot be easily replaced or subverted, hence NICI wards off the crypto-with-a-hole problem.
Nonrepudiation. In the context of digital security, nonrepudiation is the assurance that the sender of a message cannot later falsely deny having sent that message. (See also authentication, confidential, and integrity.)
Novell International Cryptographic Infrastructure (NICI). An infrastructure of network cryptographic services for worldwide consumption, NICI supports multiple cryptographic technologies that offer fundamental security features, including confidentiality, integrity, authentication, and nonrepudiation. NICI complies with diverse national import and export restrictions on the use of cryptography and enables the use of the strongest cryptography legally allowed within the country in which NICI is being used.
NICI has met import and export restrictions worldwide. Applications developed in the United States that provide NICI services for worldwide consumption will be subject only to a one-time export review process because the application itself does not include cryptography. NICI services are exposed through the Controlled Cryptographic Services (CCS) Application Program Interface (API) included in the latest version of the Novell Developer Kit (NDK). (For more information about the NDK, visit http://developer.novell.com/ndk.)
Public-Key Encryption. An encryption scheme in which each party exchanging messages gets a pair of keys: a public key and a private key. As these names suggest, public keys are published, and private keys are secret. Private keys are never transmitted or shared. The sender encrypts a message using the recipient's public key, and the receiver can only decrypt that message using his or her private key.
NetWare Connection, December 1998, p. 18
A Key For Every Occasion
Novell International Cryptographic Infrastructure (NICI) has a key for every occasion. NICI relies on separate categories of keys that are used with both symmetric and asymmetric algorithms, which are commonly called public-key algorithms. (For more information about symmetric and public-key algorithms, see the "The Level of Security Lies in the Key" section in the main article.)
The keys in each category serve unique purposes and have different strengths:
Data confidentiality and integrity keys
Key management keys
Key archival keys
Public-key certification keys
NICI operational keys
DATA CONFIDENTIALITY AND INTEGRITY KEYS
NICI uses data confidentiality and integrity keys to encrypt and decrypt user data and to sign and verify encrypted data for applications that request such services from a NICI XLIB. (For more information about the XMGR and XLIB, see the "Modular Crypto" section in the main article.) A NICI XMGR module called the Key Generation XMGR generates data confidentiality and integrity keys, which can be either symmetric keys or public-private key pairs.
This XMGR module generates the data confidentiality and integrity keys when the XLIB forwards an application's request for encryption/decryption and signing/verifying services. The XLIB also indicates the strength of the key the application is requesting. However, the strength of the key the application actually gets might or might not match the requested strength.
The strength of data confidentiality and integrity keys depends upon NICI policies, which accompany all XENGs. The specific details contained in these policies vary, depending on several factors, including which XENG your company is using. For example, data confidentiality and integrity policies embedded in the Domestic XENG enable NICI to use up to 128-bit symmetric keys. The Worldwide XENG, in contrast, uses only up to 40-bit symmetric data confidentiality keys.
KEY MANAGEMENT KEYS
NICI uses key management keys to encrypt other keys when those keys are passed to applications for storage outside of NICI or distributed between servers. The Key Generation XMGR generates key management keys, which can be either symmetric keys or public-private key pairs. The XMGR generates key management keys when NICI is installed.
The strength of the key management keys that the XMGR generates depends on which XENG your company is using. If your company is using the Domestic XENG, NICI uses either Triple Data Encryption Standard (DES) with 192-bit keys or Rivest, Shamir, and Aldeman (RSA) with 1,024-bit keys. If your company is using the Worldwide XENG, NICI uses either DES with 64-bit keys or RSA with 512-bit keys.
KEY ARCHIVAL KEYS
NICI uses key archival keys to encrypt keys that the Key Generation XMGR generates before the XMGR archives those generated keys. (The Key Generation XMGR archives the keys it generates in a key archive file, which is located in the SYS:SYSTEM directory.)
Novell generates key archival keys, which are public-private key pairs, on an XTS-300 Trusted Computing System from Wang Government Services Inc. The National Computer Security Center (NCSC) has rated this system as a B3 system, which is only one level away from the most secure system available today (an A1 system). Public key archival keys are installed when NICI is installed, and the Wang system retains the ability to recreate the associated private keys.
The key archival keys used with the Domestic XENG are 1,024-bit asymmetric keys. The key archival keys used with the Worldwide XENG are 512-bit asymmetric keys.
PUBLIC-KEY CERTIFICATION KEYS
Public-key certification key pairs are installed on each NICI server and act as the certificate authority (CA) for that server. These certification keys digitally sign and verify public key certificates for all key pairs that the Key Generation XMGR generates on that server. Like the key archival keys, public-key certification keys are generated on the Wang system at Novell.
NICI public-key certification keys are 1,024-bit RSA key pairs (for both the Domestic and the Worldwide XENGs).
NICI OPERATIONAL KEYS
NICI uses the operational keys to enforce its control of cryptography. That is, operational keys digitally sign and verify the NICI modules, NICI policies, and public key certificates for NICI's key archival keys and public-key certification keys. NICI operational keys are public-private key pairs that are generated on the Wang system.
NICI operational public keys are installed with NICI (as part of the XIM) and embedded in the NICI modules. When installing and loading NICI modules, the XIM uses the NICI operational public key to verify the signature on each of the modules the XIM loads.
NICI operational keys are 2,048-bit RSA key pairs (for both the Domestic and Worldwide XENGs).
NetWare Connection, December 1998, p. 10
NetWare 5's NICI Consumers
In general, applications use cryptography for security purposes. But for what, specifically, do applications use cryptography? For one thing, applications use cryptography for authentication purposes, which means the applications use cryptographic functions to prove the identify of persons or to prove the legitimacy of various objects, such as files or messages.
For example, Novell Directory Services (NDS) authenticates users to the network by sharing a secret, in the form of a password, with a user. To ensure that this user alone knows the secret (and no one else discovers and falsely uses it), NDS encrypts the password before transmitting it. Similarly, Novell International Cryptographic Infrastructure (NICI) ensures that no one discovers the keys it uses to encrypt and decrypt security data (such as passwords and keys): NICI encrypts the keys it generates before transmitting these keys to other servers or to storage areas outside of NICI parameters.
Applications also use cryptography to encrypt and decrypt user data and to sign and verify both encrypted security and user data. Signing encrypted data ensures that data remains unchanged. (See digital signature in "Crypto Lingo.")
The following NetWare 5 protocols, services, and applications use the cryptographic services NICI provides for unique, security-related purposes:
Public-Key Infrastructure Services (PKIS)
Secure Authentication Services (SAS)
NetWare Core Protocol (NCP) packet signatures
Service Location Protocol (SLP)
Secret Store for NDS
PUBLIC KEY INFRASTRUCTURE SERVICES (PKIS)
NICI provides cryptographic services for the new PKIS, which is a NetWare Loadable Module (NLM) and a snap-in module to the NetWare Administrator (NWADMIN) utility. PKIS enables your company to establish and manage its own certificate authority (CA)--rather than use a third-party CA. PKIS also works with most commercial CAs, such as VeriSign.
By establishing a CA in your company's NDS tree, PKIS enables you to request, generate, manage, and store your own public-key certificates and their associated key pairs for use within your company. For example, you can use these certificates to sign and verify confidential files, so that recipients can verify that the source of the file is legitimate and that its contents are unchanged.
PKIS uses the cryptography services provided by NICI. That is, using the Controlled Cryptography Services (CCS) Application Program Interface (API), PKIS calls the CCS XLIB to complete functions such as generating certificates.
SECURE AUTHENTICATION SERVICES (SAS)
SAS is another NICI consumer. SAS is an infrastructure that supports both existing and emerging authentication mechanisms, such as biometric systems and token-authentication systems. In NetWare 5, SAS provides support for Secure Sockets Layer (SSL) version 3. (SSL is a protocol designed by Netscape Communications. SSL enables encrypted, authenticated communications between web browsers and servers across the Internet.)
Server applications use SAS to establish SSL connections. For example, Novell's LDAP Services for NDS uses SAS to establish SSL-secured Lightweight Directory Access Protocol (LDAP) connections to NDS. (Incidentally, PKIS also plays a part in supporting SSL. Through PKIS, you generate and manage the public-key certificates and associated private keys that SSL uses.)
SAS is built entirely on NICI. For example, when establishing an SSL connection, SAS uses the CCS API to call the CCS XLIB for encryption services. Because SAS is built on NICI, the strength of the encryption algorithms and keys being used will always be the strongest allowed in the country where NetWare 5 is being run.
NETWARE CORE PROTOCOL (NCP) PACKET SIGNATURES
The NCP packet signature is another NICI consumer. A feature of NetWare 3.1 and above, NCP is a series of procedures that NetWare servers follow to accept and respond to client requests, such as requests to create or destroy a service connection or to manipulate a file or directory.
The NCP packet signature prevents forgery of NCPs by requiring the server and the client to attach a digital signature to each NCP packet. If an NCP packet contains an incorrect signature, NetWare discards the packet without breaking the client's connection to the server. The NCP packet signature offers one line of defense against unauthorized users accessing the network.
Because NetWare 5 can use IP, Novell had to rebuild the NCP packet signature for IP. To rebuild this security feature, Novell linked NCP to the CCS API, which calls the CCS XLIB to ask NICI to generate the packet signature for each NCP packet.
The NICI-based NCP packet signature is for IP environments. The existing cryptographic code for the IPX-based NCP packet signature remains unchanged and, therefore, does not use NICI.
SERVICE LOCATION PROTOCOL (SLP)
SLP is also a NICI consumer. Clients and servers in a NetWare 5 IP environment use SLP to discover network services. SLP maintains a registry of available services in NDS and registers a particular service's availability only once when that service first becomes available on the network. SLP uses two agents to discover and add available network services to the registry in NDS:
Service agents
Directory agents
Service agents check the network for available network services and create SLP messages to notify directory agents about which services are available. Directory agents add the available services to the registry in NDS. (For more information about SLP, see "Service Location Protocol: Discovering Services in a Pure IP Environment," NetWare Connection, July 1998, pp. 32-37. You can download this article from http://www.nwconnection.com/jul.98/slp78.)
Service agents generate digital signatures and append these signatures to SLP messages. Directory agents verify the digital signatures to ensure that the source of the message is legitimate and the message is unchanged. Using the CCS API, SLP calls the CCS XLIB to request NICI services for signing and verifying SLP messages.
SECRET STORE FOR NDS
Novell plans to release Client NICI soon. What will the Client NICI provide that the server version of NICI does not? For one thing, the Client NICI will provide a set of cryptographic APIs that run on the client. As you would expect, the current server version of NICI provides APIs only for applications running on the server. If an application that is running on a client requires cryptographic services, that application cannot get these services from NICI--that is, until Client NICI is available.
Client NICI will also be highly cooperative in client-server applications that require cryptographic services. Novell expects that one of the first uses of Client NICI as a cooperative client will stem from Secret Store for NDS. (Secret Store for NDS will be available soon.)
Secret Store for NDS will enable developers to write applications that use the authenticated NDS connection to provide proof of identity to the applications. An application will then be able to check NDS for the secrets (for example, passwords, tokens, or private keys) users would otherwise have to enter to log in to that application--after logging in to the network. In other words, Secret Store for NDS will enable a single sign-on.
Secret Store for NDS will extend the NDS schema to store users' secrets securely as properties of User objects. Through Client NICI, Secret Store for NDS will also ensure that these secrets are transmitted securely between server and client. When a user attempts to open an application that requires the entry of a secret, the application will query Secret Store for NDS via an NDS-authentication connection for the user's secret. The application will then authenticate the user--without requiring the user to enter another secret.
For example, suppose you attempted to access GroupWise, which would ordinarily prompt you for your GroupWise password. If GroupWise were written to use the Secret Store for NDS API, GroupWise would not need to prompt you for your password. Instead, GroupWise would call the Secret Store for NDS API on the client to request your GroupWise password. The Secret Store for NDS API would access the Secret Store in your NDS User object and return your secret GroupWise password.
Instead of reading the password that you would otherwise enter on the keyboard, GroupWise would get your password from NDS and then proceed as usual. Through Secret Store for NDS, Novell will provide single sign-on capabilities for Entrust/PKI applications soon. In the future, Novell also plans to provide single sign-on capabilities for other applications such as GroupWise.
* Originally published in Novell Connection Magazine
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.