The Wayback Machine - https://web.archive.org/all/20050306042849/http://www.entrust.com:80/news/reprints/network_keys_for_security.htm

Entrust

Entrust in the News

Network Keys to Security


The manufacturers of modern Public Key Infrastructure solutions promise secure enterprise networks thanks to network keys. Three current solutions had to prove themselves in our Real World Labs at the University of Applied Sciences in Stralsund.

Asymmetric encryption methods should ensure secure internal communication via public and private networks in companies. Such public key systems work with a public and a private key. Encryption is carried out with one key and decryption with the other. The great advantage to this method is that only one of the two keys - the private key - must be continually protected. The public key can be published at any time without the risk of encrypted messages being spied upon by unauthorized third parties. The "trick" here is that certain computational procedures are used which are simple in one direction but very compute-intensive in the other. An example of this is the expression of whole numbers as the product of their prime factors. Each whole number has exactly one prime factorization. This means that calculation in the "opposite direction", while not impossible, is extremely compute-intensive. If the numbers chosen are large enough, a computer can carry out the multiplication in a very short period of time, but the time needed for calculating the factorization can take billions of years, even for supercomputers.

The aim of our Real World Labs test at the University of Applied Sciences in Stralsund was to show what these sophisticated encryption methods can achieve today and how they stand up in actual practice. To this end, we announced a comparative test and asked all relevant IT security manufacturers to provide us with their PKI solutions. In response to this announcement, a number of products from various manufacturers reached our test laboratory. In the end, only three solutions fulfilled all of the essential criteria of our test specification. With "AccessMaster PKI 6.0", Evidian placed a product in the running which the manufacturer has positioned as a comprehensive administrative solution for commercial third-party CAs. Beyond this, however, the solution itself also supplies the components necessary for realizing one's own PKI. The product was used in this way in our test. The "Keon Certificate Authority 6.0" from RSA Security also took part in the test, with the "iPlanet 5.1" LDAP server from Sun, an independent product, rounding out the test version of this solution. The third candidate in the test group was Entrust with its "Entrust/Authority 6.0.1". A separate LDAP server, the "Critical Path Directory Server 4.0", was integrated here as well.

Report card: PKI solutions

Focal points of the test
The goal of our current PKI test was to set up a Public Key Infrastructure which would realize secure communication via insecure channels on the basis of certificates. The encryption of e-mail and WWW traffic was to be examined in detail.. The test focused on the installation of the solutions, as well as on the configuration of the systems in the test environment, handling during the creation and management of certificates, and how the work of administrators was supported through logging and product documentation.

Installation and configuration
The Evidian solution should definitely be installed and commissioned by trained personnel with the appropriate product-specific insider knowledge, because the majority of the components involved must be precisely coordinated with one another, and the documentation CD is practically useless as an installation guide. The basic configuration involves everything from the use of graphical tools, through the command line, to the manual editing of various configuration files. The situation with the other test participants was somewhat different. Here, too, it was generally assumed that the installation and configuration would be handled by specialized system integrators, but no major hurdles were encountered when commissioning these systems in our test environment.

The PKI solution from Entrust is designed in a way which enables it to run with LDAP servers from various manufacturers. For this to be possible, the internal structure of the respective servers must be individually adapted to the Entrust PKI. For our test, Entrust provided a Critical Path LDAP server that had been adapted accordingly. This was also put into operation without any major difficulties. The only hitch came when an attempt was made to use a dash in the organization name when creating the directory structure; this met with no success and was refused. This unexpected problem was solved by adjusting the names accordingly in the test environment. The Informix database and the Entrust/CA and Entrust/RA PKI components were installed without a problem.

RSA impressively demonstrated just how quickly and easily a PKI can be set up. The Keon CA software was installed in just a few minutes, and in the subsequent initial configuration via the Web browser, only a few entries were needed for completing the system CA. This CA is not used to create user certificates, however, but rather to set up the actual "production" CA. Finally, the LDAP server had to be installed, and communication between the CA and the directory service had to be configured. The system was then operational.

Creating and managing user certificates
The representation of the company structure in the directory service was realized directly on the LDAP server. This could be easily expanded later on in the course of the test. In order to be able to store the generated user certificates in different organizational units, the Entrust/RA also had to be configured accordingly.

Certificates were created depending on their purpose. At this point in the process, it must be established whether the user certificate will represent a person or a Web server. A person is defined by their name and, optionally, by their e-mail address and a serial number. This serial number may also be a component of the DN. By default, certificates are issued with pre-defined settings regarding the subsequent use of the certificate, but individual attributes can also be defined in templates and assigned to certificates. In response to such a request, the system generates a reference number and an authorization code. With this data, users can create certificates themselves at their workstations using Entrust Desktop Entelligence 6.0. This application is generated beforehand on the Entrust server using the Entrust Desktop Solution. It is provided as an installation file. In addition to its actual functionality for creating and managing certificates, it can also include a plug-in for the Qualcomm Eudora and Outlook e-mail clients. With this plug-in, issued certificates can be used transparently when sending e-mail, and users never have to handle the certificates directly.

If the certificates are to be used in other applications which Entrust does not support directly (such as Outlook Express), the user can export his or her key pair to a PKCS#12 file using Desktop Entelligence and then import it in this way into the local Outlook Express address book. This export functionality is not available by default, however; it must be activated by selecting an appropriately configured policy when creating the certificates.

With the AccessMaster PKI from Evidian, the hierarchical organizational structure is created in the database before the user certificates are actually generated. This is realized by means of a central configuration tool, the "Integrated User Manager", or IUM for short. Users are set up separately within this structure. Additional user information - such as e-mail addresses - must be entered during this operation or certificates will not be able to be issued later. The automatically pre-determined DN name of the new user should also be checked at this point, because this name may be incorrect in relation to the position of the user in the name structure.

A request for the creation of a key pair is then generated via the administration GUI. This request is processed by the LRA, and the keys that are created are certified by the CA. Templates for various key pair tasks can be easily pre-configured and equipped with the necessary attributes when creating key pairs. If the CA is run in online mode, this takes place without the need for further action by the administrator. In offline mode, the administrator still has the ability to view incoming requests separately and reject them where appropriate.

In the tested version, however, there was no way to store revoked certificates in a Certificate Revocation List (CRL). According to the manufacturer, this feature should be available in the next version in combination with third-party products.

The PKI solution from RSA enables users to be involved in the certificate creation process up to a certain point by allowing them to provide the enrollment server with their personal data (name, organization or e-mail address) themselves via a Web interface. This data is then transmitted securely via HTTPS. An administrator can fill individual fields with default values that are either fixed or can be edited by users.

The requests are then submitted to the CA, and the administrator has the ability to issue the requested certificates, make any necessary changes to the data or completely discard the request. After their applications have been processed, users can be automatically informed via e-mail whether their certificate has been issued or refused. If the message is positive, the e-mail will contain a URL from which users can download their certificate.

Creating server certificates
The creation of certificates for Web servers differs from the creation of certificates for people in that a certificate request is generated with the Web server and signed by the CA. RSA realizes this process via the same website that is used for issuing user certificates. Here, however, the certificate request generated by the Web server is forwarded to the CA as a PKCS#10 request and viewed by the administrator. A certificate is then issued which can in turn be downloaded using the browser and installed on the Web server.

Entrust realizes this task in basically the same way, but somewhat more effort is involved. The Entrust/WebConnector must be installed on a system in combination with a Web server. The Entrust/CA provides a reference number and the associated authentication code, which the WebConnector can use to activate and download the new certificate in order to install it on the Web server. The Evidian solution does not provide for this method of server certification, and no one could advise us on a comparable method when we asked.

Using the certificates
Evidian offers an elegant and secure method for using the certificates: a PKCS#11 module is loaded in Netscape Navigator, and the PKI certificates are made available transparently via this interface. Alternatively, a special application can be used to download a user's private keys as a PKCS#12 file to the local workstation, where they can be used in the respective application. Authentication via passwords, which are to be specified together with the user account, is carried out with the PKI prior to this download. After a definable number of failed log-in attempts, the respective account is blocked. This security feature can easily turn into a source of interference, however, if an unauthorized person deactivates the pre-defined administrator account in this way. This has far-reaching consequences because when the server is restarted, some of the services necessary for the functionality of the PKI can no longer be launched, as they are dependent on the use of this account.

In our test environment, public keys were published using the integrated LDAP server of the AccessMaster PKI. However, the system would not launch this service automatically in our test. Only a manual start-up prompted the LDAP server to begin its work. Afterwards, it was possible to access this directory service via the Outlook Express address book and to retrieve and use both the e-mail address and the digital ID of the desired user.

Attempts to restrict searches to a specific branch of the LDAP tree were also unsuccessful; all users were displayed every time. This can be attributed to the rudimentary implementation of the LDAP server. According to the manufacturer, if the commercial products supported by Evidian are used, this problem should disappear.

When issuing certificates, it is possible to send applicants an e-mail containing the URL from which the issued certificate can be downloaded and installed on the local system. This operation is protected by an HTTPS connection and is only possible using the browser from which the certificate was requested.

It was not possible to use the public keys at first go, because the request sent to the LDAP server with Outlook Express returns users' e-mail addresses but does not provide the digital IDs. However, a glance at the directory tree with the separate LDAP browser revealed that the certificates are stored there.

In the end, it turned out that the e-mail address of the applicant was not integrated into a certificate by default when certificates were issued. This prevented Outlook Express from considering the integrated certificate valid. After these settings were made in the corresponding template, all newly issued certificates could be used directly in Outlook Express.

Alternatives
Besides the products that were tested, there are several other manufacturers who offer solutions for the creation and management of certificates. However, they are often specialized in certain products or product groups, such as VPN gateways or e-mail solutions. These companies include Hisolutions with the "Enterprise CA" and Glück & Kanja with "CryptoEx". In addition to our regular group of test products, we also looked at solutions from these companies in our test laboratory.

The Hisolutions product is a certificate generator for issuing X.509 certificates which can be used for e-mail communication, for example, as well as for authentication between Web servers and the corresponding browsers. At the start of the testing period, it was not yet possible to connect to an LDAP directory service, so this could not be taken into account in the test. According to the manufacturer, however, this feature should be realized in the near future.

CryptoEx from Glück & Kanja is a PKI based on PGP keys for use in e-mail communication. This solution generates PGP keys and handles their submission to a PGP key server. Furthermore, a plug-in allows the PKI to be used in connection with Microsoft Outlook.

An LDAP replicator is available for publishing the keys in the LDAP directory service. After the necessary adjustments were made on the preferred LDAP server, the keys could also be distributed in this way. Due to the focus on PGP keys, there is currently no possibility of server and client authentication on the Web and in other areas where certification is based on X.509 certificates.

How Network Computing carried out the test
Our test scenario examined the extent to which the solutions fulfilled the requirements of the brief and could be used to implement a Public Key Infrastructure involving certificates that were centrally created and managed, as well as how these certificates could be used in standard applications such as e-mail or the Internet.

We realized the network in our test environment with 2424M and 4000M ProCurve switches from Hewlett-Packard, while a ProLiant ML350 server with a Pentium III CPU (1.2 GHz / 384 MB RAM) and a ProLiant ML370 server with two Pentium III processors (1.2 GHz / 768 MB RAM) from Compaq provided the hardware platform for the various servers and clients under the Windows 2000 and SuSE Linux 8.0 operating systems.

Summary
Authority 6.0.1 from Entrust is a comprehensive solution with which practically all the focal points of our test scenario could be realized without any great effort or difficulties. The integrated support for Qualcomm Eudora and Outlook makes it possible to protect e-mail communication cryptographically without the need to manually handle the user certificates.

The web-based approach of the Keon Certificate Authority 6.0 from RSA allows for extremely flexible use which enables the end user to be actively involved in the creation and management of the certificates. However, this flexibility demands increased security awareness on the part of end users, because users practically manage their private keys themselves on their workstations, and they must also protect these keys from external access. Thanks to the use of generally available services such as e-mail and the World Wide Web on the basis of SSL encryption, there is no need for additional client software. No insurmountable problems were encountered with the Keon CA in our test scenario and, in the end, the solution left nothing major to be desired.

The lack of support for a Certificate Revocation List (CRL) and for processing PKCS#10 requests in the AccessMaster PKI 6.0 from Evidian is responsible for the gap between it and the other participants. Added to this is the fact that the work of the PKI can be seriously interrupted through the malicious deactivation of the administrator account. According to the manufacturer, this problem should be corrected in the next version to be released. Otherwise, the scope of performance of the AccessMaster PKI was equal to that of the other participants in the test. However, it should be noted that in practical use within a company, this solution is combined with other commercial products. Beyond this, the Evidian solution also offers additional functionalities in the area of single sign-on, but this did not play a role in the current test and was therefore not taken into account in the assessment. However, this complexity is reflected in the increased effort required for configuration and administration which, on account of the number of components involved, should not be underestimated.
Dipl.-Ing. (University of Applied Sciences) Thomas Rottenau