 |
|
|
IBM SecureWay Trust Authority 3.1 is part of the IBM FirstSecure family which includes virus protection, intrusion detection, access control, traffic content control, encryption, digital certification, firewall technology, and application development toolkits. These functions are delivered from IBM’s family of security products as well as through offerings from other vendors.� Trust Authority (TA) provides both encryption and digital certification functions providing applications with the means to authenticate users and ensure trusted communications A Trust Authority system can run on IBM AIX/6000 and Microsoft Windows NT server platforms. The main modules that make up a TA system are as follows: Trust Authority server� - The Trust Authority server is the central server that ties the other components together. It maintains the configuration database and provides utilities for administering the system. Registration Authority - The Registration Authority (RA) is the server component that manages the registration process. It enforces local business policies to ensure that certificates are issued only to approved entities and used only for approved purposes.� Certificate Authority - The Certificate Authority (CA) is the server component that manages the certification process. Audit subsystem - The Audit subsystem provides support for logging security-relevant actions. WebSphere Application Server - WebSphere is a security-aware collection of products, including the IBM HTTP Server, that provides a trusted base for network transactions. The IBM WebSphere Application Server (WAS) is a Java application server designed to facilitate the management and deployment of Web applications. WAS makes use of a Java development and run-time environment on the host machine allowing WebSphere to execute the Java programs used by the Trust Authority registration application. In a Trust Authority system, the Web server software must be installed on the same machine as the Registration Authority, providing a secure boundary between protected programs and the users who attempt to access them.� Using Hypertext Transfer Protocols (HTTP and HTTPS) and Secure Sockets Layer (SSL) technology, the Web server can encrypt communications between the clients and the server. It can also authenticate connections to prevent unauthorised access or data tampering. Database system - Trust Authority uses IBM DB2 Universal Database (DB2) as its storage base. The server components maintain separate databases for configuration data, registration data, certificate data, audit data, and Directory data. DB2 offers extensive security features and storage capacity. For example, it enables Trust Authority to store registration data in an encrypted format and to perform integrity checks on stored audit records. Directory server – The IBM SecureWay Directory integrates with DB2 to maintain information about certificates in a centralised location. Through its integration with IBM DB2, the Directory can support millions of directory entries (tested to over 30 million by IBM). It also allows client applications, such as Trust Authority, to perform database storage, update, and retrieval transactions. Client components – TA provides browser-based enrolment as well as a Java-based Trust Authority Client for use when standard Web browsers are not available. In smaller systems, all of the main server components can reside on a single machine – this is how TA was tested in the NSS labs. In large-scale implementations, however, the three main components – Trust Authority/RA, Directory and CA/Audit servers – can reside on separate machines to provide enhanced performance and scalability. The PKIX implementation in Trust Authority is based on the Common Data Security Architecture (CDSA) from The Open Group. CDSA supports multiple trust models, certificate formats, cryptographic algorithms, and certificate repositories. Its primary advantage is that it enables organisations to write PKI-compliant applications that support their business policies. Trust Authority uses the PKIX Certificate Management Protocol (CMP) for communications between the RA and CA servers and for communications between the RA server and Trust Authority Clients. While CMP uses TCP/IP as its primary transport mechanism, an abstraction layer over sockets exists, enabling support for additional polling transports. CMP defines message formats to support the entire certificate life cycle. It also specifies how message protection should be handled independently of the transport mechanism. In Trust Authority, the RA server uses LDAP to communicate with the Directory server. The RA publishes certificates, certificate revocation lists, and other information about registered entities and certification policies in the Directory on a scheduled periodic basis. This is an important point in TA – certificates and other directory entries are not always published immediately. Security in a Trust Authority system is assured through the use of code signing, message signing, data encryption, and the secure storage of keys and passwords. Code signing - Core Trust Authority code is signed at the time it is manufactured. When code is signed with a factory-generated private key, it becomes a static and protected object. It cannot be altered or replaced without detection.� Other code objects are able to use the corresponding public key and the internal verification library to authenticate the communication before any exchange of data takes place. Message signing - To provide even greater authentication services, the configuration process generates signing keys for the RA, CA, and Audit servers. This ensures that all inter-component communications are signed. For example, all messages exchanged between the RA and CA can be authenticated on the basis of each component’s signature. Data encryption - All information stored in KeyStores is encrypted. By using DB2, much of the information stored in the Trust Authority databases is also encrypted. KeyStores - Trust Authority provides support for KeyStores, secure areas that store private keys, certificates, message authentication codes (MACs), and other security-relevant objects.� Distinct KeyStores exist for the CA and Audit components and for several server agents that help carry out server transactions. Information in each KeyStore is encrypted and accessible only through a password that is established for that KeyStore.� The KeyStores are accessed via CDSA, and include support for Smartcards for hardware based key protection. This trust model helps ensure system integrity by protecting objects that are stored in KeyStores. It also helps ensure the confidentiality of those objects by allowing only a trusted system component — one that was signed with a factory-generated key — to access the KeyStore and the encrypted data in it.� Access Control Lists (ACL’s) provide a mechanism for limiting the use of specific resources to authorised users. TA components that make use of ACL’s are the CA, the RA and the Directory.� The CA uses ACL’s to restrict access to CA functions such as certificate creation. The RA uses ACL’s to restrict access to RA functions such as request approval. The Directory uses ACL’s to restrict access to various portions of the Directory that may contain sensitive information. Installation of TA is a lengthy process due to all the prerequisites that must be installed to support the PKI. However, although tedious, it is not particularly difficult providing you follow the detailed installation notes. The starting point is either AIX/6000 4.3.2 or NT 4.0 with Service Pack 5 (the latter is the platform tested here). Various hardware configurations are recommended by IBM depending on the expected load. Before installation of TA code, the supporting software must be installed in the following order:
This represents the lengthiest part of the installation process – installation of the Trust Authority code is straightforward once the prerequisites have been installed and tested. The latest versions of all the above software (apart from NT Server, of course) are provided as part of the TA distribution. Once all the software has been installed there is a Java-based wizard process to take you through the configuration step by step. Trust Authority relies a great deal on Java, so you need to have the latest JVM installed on your machine and configure your browser to allow Java script. Most of the problems we encountered during our testing of TA were Java-related – this is still not the write-once-run-anywhere panacea promised to us by Sun! It does, however, provide a single, cross-platform solution for IBM that will run on both NT and AIX. Once the configuration wizard has been finished, a command line process is spawned to actually perform all the configuration tasks, such as creating the appropriate databases in DBS, populating them, assigning access control lists, and so on. This continual spawning of command line programs – so strange to hardened Windows users – is another slightly annoying trait of TA necessitated by the cross-platform approach. Given the length of time it took to complete the automated configuration process, we did begin to think that perhaps it was not the most efficient method of implementing a Windows application. At least this stage only has to be performed once. During and after installation, most problems can be solved by referring to the excellent documentation.� The Certificate Authority (CA) is the server component that manages the certification process. The CA acts as a trusted third party to ensure that users who engage in e-business can trust each other by vouching for the identity of users through the certificates it issues. In addition to proving the identity of the user, the certificate includes a public key that enables the user to verify and encrypt communications, and is signed by the CA to ensure its integrity. TA supports X.509v3 certificates in the following categories:
Each certificate issued has a lifecycle determined by the business policy currently in force. The lifecycle ends when the certificate is revoked or expires. In the current version, there is no facility for automatic key/certificate renewal – the user must manually issue a renewal request to the RA. Automatic certificate renewal will be a feature of the next release in Q1 2000. Trust Authority certificates support most of the fields and extensions defined in the X.509 version 3 (X.509v3) standard. In addition, X.509v3 certificate extensions provide methods for associating additional attributes with users or public keys and for managing the CA hierarchy. The X.509v3 format also allows user communities to define private or common extensions to carry information unique to those communities. Each extension in a certificate can be designated as critical or non-critical. A system using X.509v3 format certificates must reject a certificate if it encounters a critical extension it does not recognise; however, a non-critical extension can be ignored. There are three types of certificate extensions. They are: Standard Extensions – These are the extensions defined in RFC2459, such as key usage, private key usage period, subject alternative name, basic constraints, and name constraints. Common Extensions - Extensions that are unique to Trust Authority, such as host identity mapping. This extension associates the subject of a certificate with a corresponding identity on a host system. Private Extensions - Extensions that an application can use to identify an online validation service that supports the issuing CA. To support specific registration policies unique to each organisation, Trust Authority also provides the ability to customise and define certificate extensions. For example, it is possible change the extensions that are specified in the default certificate profiles, or create profiles that return certificates with different extensions. To ensure the uniqueness of a certificate, the CA generates a serial number for each new certificate and for each renewed certificate. This serial number is a unique identifier that is not stored as part of the distinguished name (DN) in the certificate. In order to track the certificates it issues, the CA then maintains an issued certificate list (ICL). The ICL stores a secure copy of each certificate, indexed by serial number, in a DB2 database. To protect against data tampering, the CA computes a message authentication code (MAC) for each record written to the database. The MAC helps ensure the integrity of the database by enabling the administrator to detect when data in it has been altered or deleted. Certificates may be revoked when their validity period is over, or if they are suspected of being compromised. At this point, the status of the certificate is changed in the ICL and at the scheduled time, the CA creates the CRL containing the serial number and issuing CA DN of the certificate that has been revoked. Although a certificate and its information are changed in the ICL when the certificate is revoked, no revocation is final until the CRL is issued and published to the Directory (which could be some time later). The lifetime of a published CRL and the time period between CRL publications is set and can be modified in the CA configuration file. Just as it signs certificates, the CA digitally signs all CRLs to vouch for their integrity. Obviously CA root key protection is vital in large scale PKI implementations, and IBM provides the IBM SecureWay 4758 PCI Cryptographic Coprocessor hardware solution for just that purpose. The 4758 coprocessor performs extensive RSA- and DES-based cryptographic functions within an enclosed, tamper-detecting, high-security processor on-board the hardware. It provides cryptographic data protection, key management, and custom application support. It also supports the MD5 and SHA-1 hash algorithms. The IBM 4758 helps extend comprehensive protection to keys by including:
The cryptographic processes are performed within a secure enclosure on the card. The card is designed to meet the stringent requirements of the FIPS PUB 140-1 level 4 standard, and software can run within the secure enclosure. In Trust Authority, the 4758 provides CA signing key generation, and keys generated by 4758 are protected by the card by encrypting the key using the 4758 master key. The CA keys can be stored either in the KeyStore or the 4758.� Unfortunately, Trust Authority support for the 4758 is available for the AIX version only at the time of writing (though the 4758 card itself will work on both platforms). Hardware protection for CA root keys under NT would have to be via smartcard at the time of writing. If an organisation has discrete applications for which a single CA would suffice, Trust Authority supports self-signed CA certificates. In this scenario, the CA is responsible for all of the certification activity within its administrative domain. If an organisation has interleaving or hierarchical chains of authority, however, it is possible to configure the CA to work with other CA’s via cross certification. Cross certification can be via a trust hierarchy, whereby one CA is located at the top of the tree structure and an unlimited number of subordinate CA’s are located below. When users or servers are registered with a CA they receive a certificate signed by that CA and inherit the certification hierarchy of the layers above. TA can participate in a hierarchy by having its root certificate signed by� another CA. Cross certification is allowed in a peer model also, allowing CA’s that trust one another to accept each other’s certificates as proof of authenticity. Although cross certification can be enabled in both directions using PKIX protocols, TA only allows one-way cross certification via PKCS 7/10 requests at present. Unfortunately, it is also executed by yet another command line utility. Administration of the CA is not particularly friendly, since it consists totally of command line utilities to perform such tasks as changing CRL settings, generating cross certification requests, maintaining administrators and checking logs. Despite (or perhaps because of) the fact that CA administration does not generally need to be performed on a regular basis, it would be nice to see a GUI interface for these tasks to make life simpler for the administrator. AIX users may be used to this sort of approach, but it will certainly not be popular with NT administrators, who are used to a much more feature rich and user-friendly admin interface. The Registration Authority (RA) is the server component that manages the registration process. It enforces local business policies to ensure that certificates are issued only to approved entities and used only for approved purposes.� A set of Java pages provides a default framework for the registration process, and these can be customised to support the business policies of individual organisations. Each TA system has a single registration domain, and in the current release can support only a single RA server. The primary means of enrolment in TA is via a collection of Java-based forms that allow users to request and obtain certificates through their own Web browsers. The enrolment process authenticates the client and server identities and delivers certificates to approved entities, with end-to-end encryption of all request data.�
TA provides a set of default request profiles, each of which controls the attributes and processing of an enrolment request. Each request profile also includes a certificate template that defines the intended purpose of the certificate and the certificate’s validity period. Profiles are provided to support the delivery of certificates through the Secure Sockets Layer (SSL) for use with applications that are accessed from a Web browser or Web server, or through the PKIX Certificate Management Protocol (CMP) for use in a PKIX client application or to store on smartcards. Internet Protocol Security (IPSec) certificates can be served for use with secure VPN applications or IPSec-enabled devices, as well as certificates that support Secure Multipurpose Internet Mail Extensions (S/MIME), for use with secure e-mail applications. The other form of enrolment that is supported out of the box is known as preregistration, a process that enables one user, typically an administrator, to request a PKIX-compliant certificate for another user.� The administrator retrieves a transaction ID, password and the URL of the RA that approved the request, and this can be passed on to the preregistered user face to face, by phone or by e-mail, or can be supplied as a preregistration file. Using the Trust Authority Client application, the end user can easily obtain the approved certificate without the use of a browser or the need to be knowledgeable about the enrolment process. RA administration is performed via the Registration Authority Desktop (RA Desktop). This is a Java-based GUI interface allowing authorised administrators to review applications for certificates, approve or reject requests, renew certificates, query the certificate database, and permanently or temporarily revoke certificates. Creating RA administrators is a job for the CA administrator, and any number can be created, each with his or her own responsibilities. For example, you may allow one RA administrator to approve and reject requests only, but allow another RA administrator to revoke certificates as well. Unfortunately, as with other areas of CA administration, this task must be performed using a command line interface.
Although a functional RA is provided out of the box, most organisations will need to customise it in some way. It is possible to change the enrolment forms or registration processes to reflect an organisation’s specific goals for digital certification. Customisation can range from displaying a corporate logo on the browser enrolment form to changing certificate profiles to support extensions that are relevant to the class of users, servers, or devices required. TA also offers support for policy exits, which enable organisations to call their own programs during the enrolment process for further customisation In Trust Authority, the Audit subsystem provides support for logging security-relevant actions.� The Audit server handles the following audit-related activity:
One thing TA is really lacking at present is a good GUI-based reporting tool. Although there is plenty of information stored in the DB2 database, you must purchase a separate license for DB2 and a reporting tools to extract it and make use of it.� Rather than giving a completely free copy of DB2 with Trust Authority, the use is limited and the available reports are not particularly extensive. Most end users will acquire certificates via their browser, and there are a useful set of default Web pages provided to allow Web-based registration out of the box.� The user is first prompted to install the CA root certificate in the browser (necessary only if it has been self-signed by the CA), following which the Web page collects all the information necessary to submit a certificate request. Once the request has been submitted to the RA, the user is provided with a unique request ID and challenge/response which can be used to check on the status of the request.� If the business policy allows automatic registration the request is authorised and actioned by the CA. Otherwise, it remains in the RA queue until authorised by an administrator. Once the certificate has been issued, it is automatically installed in the user’s browser the next time the status is checked.� The same Web page can also be used by the user to request certificate renewal or revocation (there is no automatic certificate renewal option in the current version). If a browser is not available for any reason, the Trust Authority Client application is provided. This application runs on any Microsoft Windows platform (95, 98, or NT) and provides the user interface for requests that use the PKIX Certificate Management Protocol (CMP). When a user submits a request to obtain, renew, revoke, or delete a certificate, the Client application communicates the request to the Registration Authority. When the RA issues a certificate, the application stores it on the user’s virtual or physical smartcard.
Because not all users have access to smartcard hardware, the Trust Authority Client includes a virtual smartcard that acts the same as a physical smartcard. TA uses PKCS #11 version 2.01 - which provides functionality for key pair generation, data storage, and signing - to support virtual smartcard operations. In some organisations users will not be expected to make direct certificate requests via their browser. In these cases, an administrator will gather information about the user and, using the browser enrolment forms provided with Trust Authority, will submit a preregistration request. When the request is approved, the RA returns either a transaction ID and a password, or a preregistration file and a password. The administrator then provides this information to the user. While running the Client application, the user submits a request for the certificate and specifies the previously provided registration information. At that time, the application automatically installs the certificate on the user’s active smartcard.� With preregistration, the approval process takes place up front, at the time information about the user is collected, not at the time the certificate is issued. With the TA Client, users can view summary information about all their certificates, including:
The Client application also allows users to export certificates to existing PKI-aware applications, such as Microsoft Internet Explorer or Netscape Communicator, as well as move certificates to, from, or between smartcards. This feature provides flexible and extensible support for multiple Internet-accessible applications, such as secure e-mail. Whenever a smartcard – virtual or physical – is opened by the Client, any certificates that are due to expire within a specified time (default is 30 days) will be flagged as requiring renewal. As with the browser approach, renewal requests must be made manually by the user. Trust Authority V3.1 is licensed per user for all of the components described in the Architecture section of this paper. For each user, you are allowed to install as many server components as needed (registration facility, certificate authority, etc), and are allowed to issue as many certificates as needed. For each user, you are allowed to install one copy of the Trust Authority Client. A User is defined as an entity with a unique Distinguished Name. Trust Authority V3.1 is available under IBM's Passport Advantage program, which provides for different levels of discounts based on total purchases of IBM Software. In addition to the different discount rates, customer may choose to purchase support and/or subscription for one or two years.� As a rule of thumb, a large average IBM customer in the United States would have a Category G Discount Rate. For one year subscription, the price is $10 per user for an unlimited number of certificates. 100 - $1,000 USD 1000 - $10,000 USD 10,000 - $100,000 USD 100,000 - $700,000 USD ($7 USD per user) 1,000,000 - $7,000,000 USD ($7 USD per user) In effect the prices range from $18 per user with no volume commitments and a two year subscription down to $7 per user with a $700,000 commitment and a one year subscription. The commitment is for total IBM Software purchases, not just for Trust Authority purchases. The IBM Trust Authority offers a functional PKI solution out of the box for a reasonable price, though the pricing model begins to break down over 10,000 users compared to some of the competition. The client and RA operations are particularly straightforward and easy to use. There are, however, a couple of significant drawbacks with the current version. The first may not be considered a drawback by everyone, but we would suggest that the reliance on Java is far too heavy given the sluggish performance and general browser-to-browser compatibility problems (we had to upgrade to the latest Microsoft JVM in order to complete the testing) that plague the Java world today. The JVM on the server frequently consumed in excess of 95 per cent of the available CPU capacity and the client/RA utilities seem to take forever to load and run. It should be noted, however, that this problem relates only to the RA Desktops and Trust Authority Clients - users who request certificates do not need Java Another criticism we had which may not bother everyone is the fact that there are simply too many command line utilities in TA, which is likely to be a major concern for NT sites. As a result of this, we found that administration of the CA is neither intuitive nor user-friendly. On a slightly more serious note, there are certain features missing in the current version, which sports no automated key renewal, key backup and recovery, or key histories (all of which are promised Q1 2000). On the positive side, TA offers extensive customisation capabilities due to the fact that the RA is represented by a number of Java scripts, Web pages and text configuration files. Configuration is in no way straightforward, but at least TA is flexible. Pricing is extremely cost-effective for low number of users, but quickly becomes prohibitive for larger implementations unless you are issuing large number of certificates to each user (prices are per user with unlimited certificates).� Given the omission of some key features that would be of particular interest to the large enterprise (automatic certificate renewal, key backup and recovery, and so on) we feel large enterprises should gain commitments from IBM in these areas (as well as investigating the possibility of volume discounts) before scaling up to hundreds of thousands of users. For the time being, IBM’s Vault Registry offering is the superior choice for large scale PKI implementations. Company
name: IBM Click here to return to the PKI Index Section
|
 |
Send mail to webmaster
with questions or�
|
