 |
|
|
RSA Keon is a family of digital certificate management solutions, the heart of which is the Keon Certificate Authority, a certificate management system that unites a key management engine, a certificate engine, a certificate repository and a certificate revocation database together into a single package. Keon Certificate Authority provides the trust management foundation for PKI-enabled applications both from third parties or developed in-house using the RSA BSAFE developer tools. RSA Keon PKI is made up of a number of components: Keon CA runs on Windows NT 4.0, Windows 2000 or Solaris servers. It includes a secure Web server for Web-based administration and enrolment and a secure Lightweight Directory Access Protocol (LDAP) directory. The Keon CA enrols users and issues them digital certificates that conform to the X.509 v3 standard. It also generates Certificate Revocation Lists (CRLs) and contains an OCSP responder for more timely distribution of revocation information, as well as a Simple Certificate Enrolment Protocol (SCEP) server that provides automatic enrolment for issuing certificates to SCEP-compliant Virtual Private Network (VPN) devices.
Keon CA consists of four main servers: the Web Server, the Logging Server, the CMP Server and the Secure Directory Server. The Web Server is an Apache-based server and provides the primary interface to Keon CA. Although it is one physical entity, the Web Server is divided into six virtual servers:
The Logging Server securely logs PKI and system events. This provides an audit trail for the Keon CA Auditor. Log data is stored in local files, which are digitally signed by the Logging Server, providing an additional layer of security. The Secure Directory Server is an LDAP directory server that stores all the information for the PKI. It performs the following functions:
System data, certificates and CRLs are stored in the Secure Directory Server for access by other Keon components. This server is not recommended for external access, however (though it could be used for certificate retrieval in a pilot implementation), and so publication of certificates and CRLs to an LDAP server for external queries and certificate retrieval would normally be performed as a separate operation to a third party directory server (which is not sold by RSA Security). The Secure Directory Server can be accessed through the Keon CA Web Server interface, or through a standard LDAP client, such as Netscape Address Book or an OpenLDAP client. Within Keon CA, the Administration Server has full access to the Secure Directory Server, while the Enrolment Server has only limited access. The SCEP Server also has limited access, and the CRL Server has no access. Finally, the Certificate Management Protocol (CMP) Server is used for certificate enrolment and related tasks by end-entities (people and devices) and registration authority (RA) applications. The CMP Server is a stand alone server that has been implemented in Keon CA as a gateway to the backend CA services. Hardware-based key management is supported via an HSM from third-party hardware vendors such as Chrysalis and nCipher (the only two supported at the time of writing). Multiple CAs are supported on a single host, making Keon a good solution for hosting situations. CAs under Keon can be logically partitioned into multiple �Jurisdictions� if required. A Jurisdiction is a set of configurations that define the form and content of the certificates issued under it, the life cycle management of those certificates, and the look and feel that end-users will find when enrolling. The use of multiple Jurisdictions allows an administrator to distribute certificate management tasks throughout an organisation (each Registration Authority - and the administrators under it - is tied to a specific Jurisdiction). Every CA has at least one Jurisdiction (even the System CA, Administrative CA and Key Recovery CA). Although each Jurisdiction is mapped to only one CA, each CA can be mapped to multiple Jurisdictions. Vettors can also vet certificate enrolment requests for multiple Jurisdictions.
In smaller organisations, a single Jurisdiction is probably sufficient for the CA. In this case, a single, corporate-level Jurisdiction is created, and one or more Vettors manage all end-users of the CA. Larger organisations may require multiple Jurisdictions. For example, Engineering and Finance groups may both need certificates for secure e-mail, yet the Finance group may also need their certificates for controlled access to financial databases. The two groups of employees naturally fit into two different Jurisdictions. In this example, the administrator would configure the Finance Jurisdiction in such a way that certificates issued in this Jurisdiction would confer access to the financial databases. This can be achieved by creating certificate profiles that contain the appropriate extensions, or by establishing Distinguished Name (DN) requirements that permit access to the financial databases. With multiple Jurisdictions, it is also possible to set different criteria for authenticating the identity of end-users requesting certificates. For example, Jurisdictions for groups needing to access sensitive information can require more stringent criteria. To further enhance security, the administrator can assign certificate management responsibility to different Vettors for each Jurisdiction. Although all necessary Registration Authority (RA) functionality is included within the CA itself, RSA Security still includes the RSA Keon RA software. This provides an independent RA component that works with the CA to streamline the enrolment process for handling large volumes of end-user certificate requests in a distributed implementation. It enables the RA Officer (RAO) to verify the credentials of certificate requests and provides certificates to the requestor. The RSA Keon RA software enables organisations to set up either remote or local standalone enrolment centres for large user implementations at distributed geographic locations, thereby allowing the organisation to scale its certificate management system (by distributing to multiple RAOs and Vettors) while moving the approval process closer to the users (which can reduce significantly the risk of approving certificates to unauthorised parties). If the business requires that the RA server be accessible to end-entities outside the domain of the CA, then Keon RA can operate on the public side of a firewall while the CA is secured behind the firewall. Each RA is tied to a specific Jurisdiction in order to define policy for the RA. Many enterprises deploying digital certificate management systems must be able to retrieve encrypted data as part of their disaster recovery operations or to meet regulatory requirements. The RSA Keon Key Recovery Module (KRM) software, an optional component of the RSA Keon CA software, provides a way to securely archive and recover private encryption keys of users, thereby eliminating the risk of serious data loss in the event that the encryption key is lost, misplaced, corrupted or if a user leaves an organisation. The Keon KRM provides key recovery capabilities by automatically adding an encryption key option to the Keon CA enrolment process. During enrolment, the user simply accesses a specified URL through the Web browser and downloads a certificate. The user then selects the encryption key option and a second key pair/certificate is obtained. The first-issued certificate is used for both signing and authentication for obtaining the private encryption key and certificate. The private encryption key is centrally generated on the Keon KRM hardware (a third party HSM device) and then securely distributed to the end user along with the encryption certificate, as well as being stored in a strongly encrypted form in the CA�s database. The key used to encrypt and decrypt these private keys is protected by the HSM. The RSA Keon Key Recovery Module provides a secure means of recovering encrypted data by offering features such as a highly secure hardware-based encryption key generation and a smart card-based �m of n� collaborative encryption key retrieval process. The collaborative key retrieval system requires that a certain minimum number of duly constituted Key Recovery Operators (KROs), acting together, can recover a stored private encryption key. This multi-tiered approach provides tightly controlled access to private encryption keys, ensuring additional security to the key recovery process and minimising opportunities for abuse of the KRO privileges. This is enhanced by the fact that is it impossible to turn off logging on key recovery operations, and thus these operations are impossible to hide. Note that Key recovery operator (KRO) certificates cannot be requested through the standard end user certificate request form. Instead, they are available through special request forms on the Keon CA Enrolment Server.
Keon KRM only archives private encryption keys since it is not desirable to archive authentication (signing) private keys as this would compromise non-repudiation. Private encryption keys are kept strongly encrypted in secure storage on the hardware security module such that even compromises to the server�s operating system will not jeopardise the security of the key database. OneStep provides a flexible framework that organisations can use to authenticate, approve, issue and install digital certificates automatically by utilising existing authentication systems and data sources. Once operational, the entire enrolment, authentication and installation process can be accomplished in a single operation without manual intervention by a certificate administrator for approval. Out of the box, OneStep is capable of supporting RSA SecurID for strong, two-factor user authentication, or can use password authentication to an LDAP directory such as Sun One Directory Server (the data for the certificate can also be retrieved from the LDAP Directory). However, with modifications it is capable of handling most authentication systems (smartcards, biometrics, Windows passwords) and back-end databases (including relational databases and LDAP directories). In a typical enrolment scenario, the individual requesting a certificate would enter his user name and password, and perhaps another unique ID (such as a PIN or social security number) into the enrolment Web page. OneStep, via a DLL plug-in, then uses this to look up the corresponding user information in the company�s human resources and security databases, and compares the two. If there is a match, OneStep then extracts from the databases all the data required for a certificate, plus the key generated by the browser, passes it to the Keon CA and requests a certificate. When the certificate is ready, OneStep automatically sends it to the user�s browser, all without administrator intervention. OneStep is perfect for situations such as on-line banking applications, where customers are effectively pre-approved via the banks normal account application procedures, or for large-scale internal roll out within a company where all the necessary enrolment data is already stored in HR databases. Keon WebSentry is a plug-in that works with Keon CA to PKI-enable Web servers and offer user authentication through digital certificates. Web administrators can thus use certificates to limit access to private or sensitive files stored on their Web sites.
When a user attempts to access a Web page or file that is secured, WebSentry established a secure SSL connection, checks the status of the user�s certificate, and then checks against their Access Control List (ACL) rules. If they have a valid certificate and permission, the user can access the site. The entire verification procedure occurs before the page requested by the end user is displayed. Keon WebSentry is flexible enough to let Web administrators use either the Access Control Lists (ACLs) already in place with their Web server or to centrally manage all ACLs through the CA. WebSentry also eliminates the usual latency problems associated with CRLs. With WebSentry, as soon as a certificate is revoked by the CA, it becomes instantly invalid at all Web servers across the enterprise, without the need to issue updated CRLs. Similar to Keon CA, Keon WebSentry logs events according to pre-set configuration options. Logged events are easily accessed through the Web server�s logging facilities. Installation is made extremely easy by the fact that as much as possible is automated. For instance, although Keon uses an underlying SSL-LDAP Directory Server as its secure internal repository, the installer is never exposed to that at all. The LDAP server is installed and configured automatically during the Certificate Authority installation procedure. The basic CA software is very straightforward to install, and if the CA is all you require it is possible to be up and running in minutes � one of the quickest and easiest CA products we have ever installed. The installation program is completely browser-based (apart from a short �bootstrap� process which runs from CD at the start), and takes the installer through a simple configuration wizard to get things going. As soon as the wizard is completed, the CA is ready to roll, but note that there is no LDAP directory included in the box for publication of certificates and CRLs. Keon CA is compatible with a wide range of well-known LDAP servers and can be configured to allow the automatic publishing of issued certificates and CRLs to any existing LDAP service or directly to Microsoft Active Directory. CRLs can also be made available to HTTP clients via the CRL Server component. By and large, the documentation provided with Keon is excellent, although we still found some problems with that covering the Web PassPort installation, particularly in the area of integrating the CA with the LDAP directory used for the secure credential store. Documentation is now provided as PDF files only, which is a shame. However, this clearly allows RSA to update the manuals at more frequent intervals, and in the US RSA has a partnership with a print-on-demand company who can produce a complete set of manuals for a nominal cost. This is a good compromise, providing a quick and cost-effective means for those customers who prefer hard copy manuals to obtain a set, and customers outside the US should press their local RSA offices for a similar capability. Keon CA users fall into four main groups:
It is possible for one person to assume more than one role, that is, the person responsible for performing Administrator tasks may perform Vettor and Auditor tasks as well. By default, anyone applying for an Administrator certificate is also able to perform Vettor and Auditor roles; anyone applying for a Vettor certificate is only able to perform the Vettor role; and anyone applying for an Auditor certificate is only able to perform the Auditor role. Two CAs are created automatically during installation of Keon CA: the System CA and the Administrative CA. If RSA Keon Key Recovery Module (Keon KRM) is installed, the Key Recovery CA is also created. These CAs are not normally included in a CA hierarchy - instead, they serve distinct purposes within Keon CA itself. The System CA serves three purposes within Keon CA:
Only one System CA is created for each Keon CA installation. The System CA is not normally used after installation except to re-sign the certificates that it issued during installation. The Administrative CA is limited to the important role of signing the end-entity certificates that grant Administrators, Vettors, and Auditors access to their respective administration areas. The Administrative CA certificate is issued by the System CA during installation of Keon CA. That certificate is the only one that allows access to the administration interface - other people who wish to help manage the PKI must request a certificate from the Administrative CA. Only one Administrative CA is generated for each Keon CA installation. The Key Recovery CA is created if the RSA Keon Key Recovery Module (Keon KRM) is installed. The Key Recovery CA is limited to the role of signing Key Recovery Operator (KRO) certificates. Multiple KRO certificates are required to recover a private key.
Once installed, the Keon CA is managed entirely via an intuitive and very usable browser interface. Administrators have full access to Keon CA and can create CAs, set access control rules, vet certificate requests, and perform all other operations available through the administration interface. Vettors only have access to the certificate operations � they can vet certificate requests and manage issued certificates for all CAs or a selection of CAs. ACLs can be used to customise the access available to each Vettor and administrator to provide a role-based approach to controlling administrative functions. Once access has been gained to the administrator�s console, there are five main menu options � known as �Workbenches� � selected via icons along the top of the screen:
As mentioned above, the availability of the Workbenches is entirely dependent on the user level as verified by the digital certificate used to authenticate to the administrator�s console.
The System Configuration Workbench provides the Keon CA Administrator with functions for configuring Web Server and LDAP access control lists (restricting access to files and directories on the CA or other Web servers on a per-certificate or per-group basis), PKI logging, the database backup schedule, extension profiles, and the Jurisdiction defaults. Extension profiles allow the administrator to specify which certificate extensions are mandatory, optional, recommended or forbidden, and for each set of extensions a script is available to determine their use (i.e. are they visible, are they editable, what are the values, etc.). Should it be necessary to alter the defaults this is the most complex part of the administrative process, and it is just as well that it need not be performed too often, since editing the scripts is not a job for the fainthearted. It would be nice to see this part of the interface converted to a point-and-click GUI.
The Jurisdiction defaults enable the administrator to apply Jurisdiction-wide policies covering Certificate Attributes configuration (are the attributes included in the subject DN, are they visible to the user during enrolment, are they editable by the user, and so on), e-mail notifications, appearance of the enrolment interface, which extension profiles are available, certificate renewal policy, certificate publishing options, and MS Exchange/Outlook integration. The Auditor Operations Workbench provides Auditors with functions for managing audit logs. These include copying the contents of an audit log to a secondary file, verifying all signatures in an audit log, verifying the integrity of an audit log, and deleting audit logs. The Administrator Options Workbench provides the means to approve, reject and maintain the special Administrator, Vettor, Auditor and Installation certificates used by the CA itself. The remaining two options are more concerned with the day-to-day running of the CA. The CA Operations Workbench provides the means to view existing CAs (selected from a drop-down menu) and create new ones, export and import certificates, generate CRLs, view active and revoked certificates, modify the certificate renewal policy, and perform various cross certification functions (hierarchical, peer-to-peer and hybrid models are supported). When creating a new CA, the administrator is presented with a simple form where he can:
The Jurisdiction under which the CA is created determines the certificate policy, which controls the default profile options for end-entity certificates issued by the new CA. CA root keys can be generated, stored and protected in software (password protected), or in hardware (token/smart card protected). Software-based CA certificates and private keys can be exported from Keon CA as PKCS #12 objects. PKCS #12 objects can also be imported into Keon CA, thus providing the same key backup and portability features available for CA keys stored on tokens and smart cards.
The final option in the CA administrator console is a nice touch, and a unique feature amongst the PKI products we have reviewed. The Certificate Operations Workbench effectively provides full Registration Authority functionality within the CA itself, for viewing, approving, refusing, suspending and revoking end user certificates. This means that for those organisations where it is not required to have a distributed registration function, it is not necessary to purchase or deploy separate RA components. Of course, where separate RA functionality is desirable, RSA does provide an optional Registration Authority module � this will be covered in the next section. One problem we did note in the current release is that requests to a particular RA do not show up when active requests are listed at the CA level - we believe that even if the CAO is not able to authorise those requests directly, he should be able to at least see all of the outstanding requests at all the RAs under his control. Before leaving the CA, it is worth covering certificate and CRL publication. Keon CA publishing uses the LDAP protocol for information management and, as such, is compatible with any LDAP-compliant directory server. RSA Keon CA can be configured to allow the automatic publishing of issued certificates to any LDAP service. In order to allow adequate distinguished name (DN) compatibility across a number of LDAP services, RSA Keon CA provides a configurable DN translation mechanism. Although the publishing facility is integrated with the CA services, it is useful to think of PKI object publication as a separate activity. The configuration of the publication functions thus has no bearing on local PKI operations, and errors resulting from publication attempts are logged but do not affect the behaviour of local CA operations in any way. The facilities of the CA publication back end have been designed to push objects into any directory server having an LDAP front end and a conventional directory structure. These operations are initiated by certain certificate operations (such as creating a new CA, creating a new certificate, revoking a certificate and generating a CRL) performed through the Administration Server. In addition to publication in the LDAP directory, CRLs can also be made available via HTTP through the CRL Server. Note that CRL publication is not the only means of providing certificate validation capabilities within Keon CA. An integrated OCSP responder is also provided, simplifying the status checking process by providing a central location for CRLs, rather than having them distributed to multiple locations. Using the Keon OCSP responder, certificate status may be checked not only on-line, but also in real-time. The responder has been implemented with the ability to query the CA certificate directory directly, instantly returning the latest status information. This removes the latency inherent in other OCSP implementations, meaning that the instant a certificate is revoked, the owner will be denied access to all systems and resources covered by that certificate. As mentioned in the previous section, the Keon CA incorporates all the usual RA functions within the Certificate Operations Workbench, and for many organisations issuing certificates for their own employees only, that will be adequate. However, an optional Registration Authority (RA) component is also available to streamline the enrolment process when handling large volumes of end-user certificate requests. The aim of the RA module is to enable the RA Officer (RAO) to verify the credentials of certificate requests, and provide certificates to the requestor. The RA enables organisations to create either local or remote stand-alone enrolment centres for large user implementations at distributed geographic locations. This allows the organisation to scale its certificate management system while moving the approval process closer to the users, thus minimising the risk of approving and issuing certificates to unauthorised parties. The Keon RA contains the same architecture and functionality as the CA, except that it cannot sign certificate requests directly. Instead, requests must be passed to the Keon CA for signing before the final certificates are issued to the requestor either by the CA or RA. The CA database remains the primary storage and lookup location for issued certificates, although a copy of each certificate issued is also stored at the appropriate RA in a similar Secure Directory Server. Although the Keon CA can have multiple RAs attached to it, each instance of the Keon RA can only process certificate requests for one CA. Policies enforced at the CA will be carried over to each RA associated with it via the Jurisdiction under which the RA is created. Authentication between CA and RA is enforced by the RA requesting a certificate during initial configuration, which must then be signed by the appropriate CA before the RA can be used. Keon CA�s Enrolment Server allows end-users to enrol in the PKI by requesting certificates. The request process varies slightly, depending on the browser and whether a token or smart card is available on the client computer. The Enrolment Server is a server-authenticated server, meaning it presents its certificate to the end-user to prove its identity, but does not require the end-user to provide a certificate to prove their identity.
After an end-entity certificate request is made, it must be vetted by the RAO. Vetting is the process of reviewing a certificate request, editing it if necessary, and determining if the CA should issue the certificate based on its security policies. Various options are open to the RAO once the requestor�s credentials have been examined - to issue a certificate, defer the request for further vetting, refuse the request, or delete the request. The administration interface for the RA is virtually identical to that of the CA, the main difference being the absence of the CA Operation Workbench, for obvious reasons. The RAO � or vetting � functions are carried out in the Certificate Operations Workbench, and are limited to a single Jurisdiction. This provides a very simple user interface which allows the RAO to list all active (i.e. awaiting initial processing), deferred, refused and approved requests. Drop-down lists allow the RAO to enter selection criteria based on certificate content in order to limit searches to make the results more manageable. Most of the time, of course, it will be a matter of merely selecting the �list all active requests� option.
Once the list has been generated, selecting any of the hyperlinks in the list brings up the corresponding request details, and provides the RAO with a similar form to that presented to the requestor. Here, the RAO can override any of the data fields in the request, check and/or amend the proposed certificate expiry date, and apply the appropriate certificate extensions. The Jurisdiction determines automatically the certificate profile which is applied. The request can then be approved, refused, deferred or deleted as appropriate and, if approved, the request is passed to the CA for certificate generation and signing before being returned to the requestor. The remaining menu options provide the means for the RAO to query the secure repository for active, suspended or revoked certificates. Once again, drop down menu boxes provide the means to filter the output to make the results more manageable. The list contains the status, the certificate owner, e-mail address and expiry date for each certificate found, and detailed information can be retrieved for each certificate by selecting the appropriate hyperlink. This also provides the means to suspend, revoke, or delete the selected certificate, or customise its renewal policy. Unfortunately, as with most queries within the Keon CA, the results are screen-based only, with no option to produce printed output. Custom reports can be created, however, by using the administration scripting language for Keon CA � X-Parse The Keon CA Logging Server records log entries for PKI events, signs them with a certified private key, and distributes logs in XML or comma-separated value format. The Logging Server accepts secure connections from logging clients and processes requests to add log events.
Log data is stored in local files on the Logging Server host, separate files being created for each day (this time period is configurable). If the Logging Server is not available, PKI event log messages are recorded by the Event Log service on Windows NT/Windows 2000 or syslogd on Solaris. It is possible to specify which events should be recorded by the Logging Server from the System Configuration Workbench in the Administration Server. Available events include:
Unfortunately there is no built in report generator, and so the raw log files must be exported to and parsed by a third party reporting tool. This is one area in the Keon CA that would benefit from some additional development work. The latest release of Keon has provided for the implementation of a separate auditor function, with its own certificate and separate menu system. As with other CA offerings, Keon provides support for Web-based applications for browser, server, mail and device (i.e. VPN) certificates. Default Web page templates are provided for enrolment, and these can be easily customised if required on a per-Jurisdiction basis.
For example, in addition to changing the look and feel of the Web pages, it is also possible to customise some of the processing, such as the information which the Enrolment Server requests from users (perhaps renaming the User ID field to request a membership or account number, or deleting the field entirely), and what options are available to the certificate users. It may also be desirable to configure Keon CA to send an e-mail notice to a CA administrator whenever a new certificate request is submitted. More complex modifications to processes and workflow can be accomplished by using the administrator�s scripting language, X-Parse. The default Web page provides the usual options for installing the CA certificate and CRL signing certificate into the browser, make a PKCS#10 certificate request (on behalf of a security device) or viewing the latest CRL. There is also an option to install an OCSP signer certificate. Once the appropriate singing certificates have been installed, the user is ready to make a request for an end-entity certificate. If directed to a CA enrolment page, the user may be prompted for the Jurisdiction - if directed to an RA enrolment page, the Jurisdiction is fixed for each RA, and it is not necessary for the user to select it. The user is then presented with a simple certificate enrolment form in which he is prompted for basic details such as name, e-mail address, organisation, and so on. There is also a section of the form where, if allowed, the user can specify which certificate profile and V3 extensions should be applied. In most cases, this would be fixed, so the user cannot tamper, or no profile applied at all, in which case the Vettor will be responsible for completing this operation. Even if the end user is allowed to select a profile, the Vettor is able to check and override it if necessary before the certificate is issued.
Finally, of course, is the prompt for the cryptographic provider. The usual Microsoft Base Cryptographic Provider can be used, or Keon will support any PKCS#11 device such as a smartcard (physical or virtual). RSA can supply a range of smartcard devices for use with Keon. The request is then forwarded to the Certificate Administrator for approval. Once approved, the subscriber will receive an e-mail containing a URL from where the certificate can be retrieved. Accessing the URL provides the means to install the certificate directly into the default browser, smart card or virtual smart card. Also on the Subscriber Services page are menu options for re-issuing (renewing) and revoking certificates. Authentication is via the digital certificate on which the operation is to be performed, so revocation and renewal can only be performed if the appropriate certificate is available to the local browser. All in all, the Web interface to the Enrolment Server is pretty standard stuff, very straightforward to use, and not difficult to customise. Where it gets really clever in the latest release is with the Exchange Server and Outlook integration. Depending the configuration of the Keon CA installation, the user may download one or two certificates: either a single certificate to be used for both signing and encryption, or one certificate for signing and one for encryption (as is the case when Keon KRM is installed). The publication of the end-user�s encryption certificate to the GAL and modifications to their Microsoft Outlook client are also configurable.
When the user retrieves the certificate, a small utility is downloaded to modify their Microsoft Outlook client. An explanatory page is displayed containing a note explaining the changes to be made to the Outlook client depending on the Jurisdiction configuration, namely:
As the encryption certificate is installed into the browser, it is also published to the Microsoft Exchange Global Address List (GAL) depending on the Jurisdiction's configuration. In this way, digital certificates and public keys are made available instantly across the network, and someone can obtain a copy of any end-users encryption certificate and thereby send an encrypted e-mail. Naturally, when two certificates are issued, only the encryption certificate is published in the GAL, and not the signing certificate. A minimal amount of configuration is required by the administrator at a Jurisdiction level in order to enable Outlook/Exchange integration in this way. A special set of MS Exchange certificate extensions are added to each certificate as it is issued in order to provide the level of integration required.
This is one of the areas into which RSA Security has put a lot of effort since the last release, and it shows. For Microsoft Exchange Server environments, this represents the most simple and effective way of issuing certificates, ensuring that every end-user is ready to send and received signed and encrypted messages as soon as their certificate has been issued. It is not necessary for the end user to perform any configuration tasks in their Outlook mail client, nor is it necessary for the administrator to ensure that certificates are available in a central location for everyone to access - both of these tasks are automated completely, and when coupled with OneStep automated enrolment, it makes RSA Keon one of the simplest PKI systems out of the box to roll out in a Microsoft environment. Web PassPort provides automated registration, user authentication, Web Single Sign-On (SSO) and secure storage of digital credentials in a �virtual smartcard�, but without the need for any permanent software on the client PC. It is thus designed for environments where a desktop footprint is not appropriate (roaming users, Internet cafes, and so on) and interoperability with applications like browsers, mail clients, and web authorisation systems is a must. Web PassPort is now RSA Security�s only roaming-user �virtual smartcard� solution since it sold off the Keon Desktop and Keon Secure Server product set. The Web PassPort system includes several components. At the heart of system is the Virtual Card, a secure container with the user�s X.509 encrypting and signing certificates and associated private keys. Sensitive components of the container are encrypted with 112 bit 3DES (Data Encryption Standard), and the container itself is encrypted with a 256 bit RC5 symmetric key. The user�s credentials are initially created by the Web PassPort Virtual Card Manager and stored securely in an LDAP-compliant directory.
The user can then authenticate from any PC and gain access to a secure credential store � a �virtual smart card�, in effect � containing digital certificates and private keys. Whenever a user attempts to access a protected resource (one which requires the use of a digital signature) the user is prompted to authenticate to the Web PassPort Server. Clearly with such sensitive data as private encryption and signing keys at stake then a secure means of authentication � such as a SecurID token � is recommended, although the use of both tokens and passwords is supported. The Web PassPort Server authenticates the user against credentials stored in an LDAP directory and downloads the plug-in. This is a small, mobile code program that enables the transparent use of certificates with Web browsers, mail clients, and other applications to enable digital signing, user-authenticated SSL, secure email (S/MIME), and VPN. The download is accomplished over standard HTTP sockets, meaning that firewall policies are not affected. The password or two-factor authentication is used to validate the user�s credentials against the central LDAP database. Once this has been done, the Web PassPort Server retrieves the user�s Virtual Card from the LDAP directory and downloads it to the user�s computer. The Virtual Card remains on the user�s computer for a limited (administrator-defined) amount of time as a security measure, and should the Virtual Card time out and the user attempt to access it, he is prompted to re-authenticate to the Web PassPort Server. When the user authenticates successfully, the Virtual Card is downloaded again to the user�s computer. By default, the user�s Virtual Smart Cards are never written to the local file system (since this would present a potential security risk - albeit a slight one), but a new feature in the latest version provides for �persistent� Virtual Cards. If the Server has been configured to allow this feature, users can keep secure copies of their Virtual Cards on their local hard disk. If the Virtual Card becomes inactive (or if the user logs out of the Web PassPort Plug-In), the Virtual Card is locked and can only be re-opened if the user enters a password in the Web PassPort Plug-In. Persistent Virtual Cards are especially useful for users who frequently work offline, but they may be considered a potential security risk in certain environments. Another clever feature of Web PassPort is its ability to integrate with OneStep to ensure that not only are users provided with roaming credentials, but that they are automatically enrolled the first time they try to use the feature.
If the user�s Virtual Card contains a �general� certificate (i.e. the user has not yet enrolled), the Web PassPort Server redirects the user to a CA to be enrolled for an end-entity certificate. The administrator can configure certificate enrolment to be performed manually (with the user entering enrolment information himself) or automatically using the Web PassPort OneStep Plug-In. In the latter case, the user�s enrolment information is retrieved directly from an LDAP directory or Microsoft Active Directory and the certificate issued automatically. Once enrolment has been completed, the general certificate in the Virtual Card is replaced by the new end-user certificate, and a copy of the modified Virtual Card is uploaded to the directory to replace the outdated Virtual Card. When a user authenticates successfully, the RSA Keon Web PassPort Server stores cookies in the user�s Web browser. The cookies act as �tickets� to ensure that users are not prompted to re-authenticate each time they try to access a protected resource. The period of time that the cookies remain valid (from one minute up to 24 hours) can be configured on the Web PassPort Server. It is also possible for the users to receive a cookie from every participating domain in the security �realm�, allowing them to access protected resources on any Web PassPort Server in the realm without being prompted to re-authenticate. Web PassPort supports multiple Virtual Smart Cards per user, which enables the user to access different B2B environments that do not trust each other. Certificates and signing functions can be accessed by multiple applications from vendors such as Microsoft and Netscape, enabling users to easily mix and match browsers, mail clients, and VPN software using the same credentials. No client or server modifications are required, as the plug-in talks natively to the application via a Microsoft Cryptographic Service Provider (CSP) or RSA PKCS #11 Cryptographic Token Interface. The PKCS #12 import utility also enables users to import their existing digital credentials into the RSA Keon Web PassPort Virtual Smart Card. These credentials are then encrypted and securely uploaded to the LDAP compliant directory server to support credential mobility. We tested Web PassPort by using a simple Web-based signing application written for an RSA customer. An area of our Web site was protected using Web PassPort, the access parameters being specified via a Web PassPort plug-in to the IIS administration GUI. Once activated, each time we attempted to access the protected area of the Web site we were presented with an authentication page first. Since we had installed the ACE Server component, we authenticated using a user name and SecurID token combination. Once authenticated, the Web PassPort plug-in � a very small downloadable program � was downloaded and installed on the local host to provide a secure local credential store, following which our �virtual smart card�, containing our certificates and keys, was downloaded to that store. As soon as our digital certificate became available from our virtual smart card we were authenticated again using the certificate, and then permitted access to the restricted area of the Web site. From that point on, our certificate was also available for encryption and signing operations, just like any other certificate that had been installed in the local browser or on a physical smartcard. However, the virtual store can be configured to remove itself (and all certificates and keys contained within it) automatically after periods of inactivity or when the user logs off. From the user�s point of view, we found that Web PassPort worked flawlessly, providing mobile access to a secure credential store without having to worry about physical smart cards or a local client. Note that Web PassPort currently works with IIS only, however. SecurID Passage is smart card middleware that provides secure user logon to networks and computer systems, digital signing, secure e-mail, and secure Web access. Via the use of the smartcard with a PIN, Passage provides both desktop logon with a Windows logon account on the card, and cryptographic logon with a digital certificate on the card. SecurID Passage operates with a cryptographic service provider (CSP) for Internet Explorer or a PKCS #11 module for Netscape. The RSA SecurID smart cards supplied are designed to protect user credentials, including public and private cryptographic keys, X.509 digital certificates, and network operating system authentication information. The smart cards are shipped blank, except for a default PIN, which users should personalise. In order to use a smart card with SecurID Passage, it is necessary to set up a logon account on the smart card that matches a logon account on the user�s computer or the network. The smart card can hold up to three accounts, which should be enough for most users for network logon, since a single domain logon usually provides access to all network resources. Once SecurID Passage has been installed, the Windows logon is replaced with a version that is capable of accessing username and password from the smart card. Once the card is inserted into the reader the user is prompted for a PIN number to access the card. Once that has been entered correctly, the user credentials are accessed from the card and the user is logged on automatically. If required, the PC is locked whenever the smart card is removed, and the user is prompted for the PIN number to unlock the PC as the card is re-inserted. It is also possible to configure a timeout on the PIN, forcing the user to re-authenticate each time the card is accessed for credentials.
SecurID Passage Logon does not require a digital certificate, though obviously the card is capable of storing them to enable sending and receiving encrypted e-mail, accessing secure Web sites, and file signing. SecurID Passage also provides the Password Manager, which allows users to store passwords for Windows applications and Web pages on the smart card and have it fill in and submit the appropriate username and password when they access the associated application or page. By storing the passwords on the smart card, users do not have to remember the passwords for multiple applications or Web pages. When the �Learn Password� feature is enabled, user name and password fields are detected automatically by Passage and the values can be �screen scraped� and stored in the smart card for automatic re-use later. The number of passwords that can be saved to the smart card depends on the space available on the card, up to a maximum of 15 passwords. To use a digital certificate with Passage for secure e-mail, secure Web access, or file signing, the certificate must first be registered on the computer. Registering the certificate makes it available to the Web browser, whilst unregistering makes it unavailable to the Web browser, thereby ensuring that no unauthorised user can gain access to the certificate. Certificate registration and unregistration are checked by default during Passage installation. With these settings enabled, digital certificates are registered automatically when the user logs on with Passage or with certificate-based logon on Windows 2000 or Windows XP, and they are unregistered automatically when the user logs off. This ensures that no unauthorised user can gain access to the certificate without the user first authenticating to the smart card. RSA e-Sign is a developer�s toolkit that enables end-users to digitally sign and optionally encrypt Web-based forms. Designed as a downloadable Web browser applet with server-side libraries for C and Java, RSA e-Sign enables organisations to rapidly integrate digital signing and encryption into their business transactions. The RSA e-Sign client module is placed on a Web server and made available to end-users as a downloadable applet that can be accessed from any workstation with access to the server. RSA e-Sign can then sign any content that can be passed to it from a Web page. For example, once a user has entered information into a form and clicked on the �Submit� button, the e-Sign applet signs the form using the user�s digital credential. The completed form can be displayed to the user in non-modifiable form for verification before the signing is confirmed. It is also possible to encrypt the form, using the public key of a person who has been designated as the recipient of the form by the developer. e-Sign server-side libraries (APIs) can perform signature verification and certificate validation when the signed form reaches the Web server and/or when a user accesses the signed form. This enables users to determine whether the form was altered after it was signed, and whether the signer�s digital certificate is valid. Keon CA has continued to improve steadily since the acquisition of Xcert, and it includes most of the features you would expect of a high-end solution � especially when options like the Key Recovery Module, OneStep, WebSentry and Web PassPort are included. Still missing on the client side is support for automatic key update and key histories. The configuration and use of Jurisdictions has been improved considerably for this release. Jurisdictions provide the ability to separate out functions and distribute amongst multiple administrators, and this is now fully configurable within the console, whereas it used to require a separate configuration file. The effect of Jurisdictions is more readily visible throughout the system in this release, and their use simplifies the deployment of large distributed PKI implementations or hosted PKI services (multiple virtual CAs can also be supported on a single host in hosted PKI situations). There is, however, a heavy reliance on an underlying Microsoft environment for many of the newer functions such as integration with Active Directory, Microsoft Exchange and Outlook, as well as the roaming credentials feature provided by Web PassPort. Having said that, RSA Security has carried out interoperability work with over a hundred non-Microsoft applications, including non-Microsoft directories, Netscape, Novell, and Apache. It is also worth noting that the company will soon be providing similar levels of integration to Lotus Notes and Domino as is currently provided for Outlook and Exchange Server. Prices for the RSA Keon PKI solution are extremely competitive (especially for low number of certificates), and the unlimited certificate / server / application model means that there is only a one-off payment required. There is no more to pay no matter how many certificates are deployed nor how frequently they are renewed, and no additional charges for the server software. We were very impressed with the number of client-side improvements available in this latest release, particularly the high level of Exchange/Outlook integration. PKI is not rocket science, but it might as well be given the complexity of rolling it out to every desktop. RSA Security is one of the few to have attempted to address this by making it as straightforward as possible for the administrator to configure and manage (most of the tasks can be automated very simply, if required), whilst making the enrolment process as streamlined as possible for the user. The fact that the entire enrolment process can be automated (albeit with some minor development work required for OneStep) and that the certificates are actually usable - in a very real and practical sense - by the end user the instant they have been issued makes this one of the friendliest systems we have had in our labs when it comes to deployment (at least in a pure Microsoft environment). For once, we are looking at a PKI system that reduces the deployment problems and increases the probability of actually being used at the desktop, and for that RSA Security is to be commended. Company name:
RSA Security Inc. Click here to
go to the RSA Checklist |
Security Testing |
Send mail to webmaster
with questions or
|