 |
|
|
RSA Keon is broadly split into two offerings, both of which we look at here: Keon Certificate Authority, and Keon Advanced PKI. Keon Certificate Authority is 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. Keon Advanced PKI extends the scope of the Certificate Authority by providing integrated desktop components � Keon Desktop � and advanced authentication and PKI features through Keon Security Server and associated authentication agents for third party products such as Oracle and SAP/R3. Keon Advanced PKI is made up of a number of components: On February 1, 2001 RSA Security announced that it had signed an agreement to acquire Xcert International, Inc., a privately held company that developed digital certificate-based products for securing e-business transactions. With this acquisition, Xcert Sentry became a member of the RSA Keon family of PKI products, and is now known as RSA Keon Certificate Authority
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. There are five main components to the CA:
System data, certificates and CRLs are stored in the integrated CA repository � known as 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 included in the basic CA product). Hardware-based key management is supported via an HSM from third-party hardware vendors such as Chrysalis and nCipher. Although all necessary Registration Authority (RA) functionality is included within the CA itself, RSA 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.� It verifies the credentials of certificate requests and provides certificates to the requester. 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 while moving the approval process closer to the users. This process significantly reduces the risk of approving certificates to unauthorised parties. 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. 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 and the Netscape Directory Server, though 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 such things as on-line banking applications, where customers are effectively pre-approved via the banks normal account application procedures, and subsequently need to acquire a digital certificate with the minimum of delay and f WebSentry plugs into an organisation�s current Web server to offer user authentication through digital certificates. Web administrators can 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 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. 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.� Web PassPort combines elements of OneStep, WebSentry and the Keon Desktop to provide automated registration, user authentication, and secure storage of digital credentials in a virtual smartcard, but without the need for any software on the client PC. Web PassPort is thus designed for environments where a desktop footprint is not appropriate and interoperability with applications like browsers, mail clients, and web authorisation systems is a must. The small, plug-in � which can be dynamically downloaded each time a digital identity is requested � seamlessly integrates with browsers, mail clients, and other applications to enable digital signing, user-authenticated SSL, secure email (S/MIME), and VPN.
The Web PassPort system includes several components. The user�s credentials are initially created by the Web PassPort Virtual Card Manager and securely stored 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 keys. To do this, the user authenticates to a Web page that is protected by 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, retrieves the user�s digital credentials from an LDAP-compliant directory, and securely delivers them to the user along with the Web PassPort plug-in. The Web PassPort plug-in is a small, mobile code program that enables the transparent use of certificates with web browsers, mail clients, and other applications, simplifying the environment for the end user. When used with the Keon Certificate Authority, the optional OneStep Module enables the auto-enrolment and pickup of certificates in one hit. At the heart of RSA Keon Web PassPort is the Virtual Smart 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. For enhanced security, the user�s Virtual Smart Cards are never written to the user�s local file system, and the download is accomplished over standard HTTP sockets, meaning that firewall policies are not affected. 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 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. 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. From the administrator�s point of view, however, it still has some rough edges. Installation was difficult (mainly due to problems integrating it with the LDAP directory), and it is necessary to manually add the virtual smart card credential store to the LDAP directory each time a new certificate is created. This can be scripted, of course, but it would be nice to see this whole area more closely integrated with the CA operation out of the box. RSA has promised that future implementations of Web PassPort will address this.
The Keon Security Server is the centre of the system, providing the following services: Authentication: The Security Server evaluates the login data that users provide (such as passwords or PIN's) to establish their ownership of credentials stored on the Smartcard or in the server�s own database (in the form of a Virtual Card). When the result is positive, the credentials are �unlocked� and the user is given access to the system. Authorisation: The Security Server stores records (controlled by the security administrator) that specify the application servers each user is authorised to access. (Such application servers must be controlled by Keon Agents; this service is not relevant to configurations that lack Agents.) Certificate Validation: The Security Server maintains and periodically downloads to each Desktop the certificate of each CA it can trust. (This package of certificates is called the Issuing Authority (IA) table.) The Desktop uses a CA�s own certificate to authenticate the CA�s signature on the certificates it issues. Credential Management: The Security Server keeps track of all Smartcard assignments; it also stores Virtual Cards and downloads the credentials they contain to the user through the Desktop. Event Logging: All events in a Keon domain are reported to the Security Server so that all logged information is available in one location. The Security Server does its work through the following subsystems: Authentication Subsystem: The authentication subsystem processes authentication requests from Keon Desktops or Agents that are passed to it (in an encrypted session). The subsystem is multi-threaded and supports authentication based on digital signatures (RSA authentication) as well as SecurID authentication. Certificate validation and maintenance of the list of trusted CA's is also part of the authentication subsystem. Authorisation Subsystem: The authorisation subsystem works with Keon Agents (in configurations that include secure application access) to validate access requests against the records that determine which applications a user has permission to access. For Keon 5.0 Agents, the subsystem creates and sends to the Desktop a PAC (privilege attribute certificate) that identifies the user, specifies the applications, and defines the period (generally short) during which the certificate is valid. The Desktop presents the certificate to the Agent, which returns it to the Security Server for validation. Event Subsystem: The event subsystem consolidates all event handling in Keon components into one subsystem. Its extensible design allows the addition of custom event forwarding, event viewers, trap generation, and notification requests. Database Subsystem: The database subsystem stores the information that links users with credentials and, where relevant, with application access rights, and the information logged by the event subsystem. Although only one copy of the database is necessary, the database subsystem provides for replication of data to copies of the Security Server running on other machines. Security administrators can manage the Keon database through the Management Console, a Java application capable of running on any machine that can connect securely to the enterprise system. To enable the maintenance of a security domain on a UNIX platform, RSA Security offers the Keon UNIX Platform Security Server. This is not a UNIX version of the Keon Security Server, but a separate component that runs in addition to the Security Server on UNIX platforms. Besides the Security Server, the other component essential to any Keon installation is the Keon Desktop, which must run on every machine connected, whether internally or remotely, to the Keon system. On the user�s behalf, the Desktop conducts dialogues with the Security Server and with Keon Agents to provide single sign-on, authentication, authorisation and encryption services. Keon Agents are software components installed either on the application server they protect or on a proxy server in front of the application server. The Agents handle all communication between the Desktop and the application. Working with the Desktop and the Security Server, Agents provide the following services: Session Encryption: The Agent communicates with the Desktop to establish a unique session encryption key to encrypt all communication between the application server and the Desktop for the duration of the session (that is, until the user signs out of the application). At the end of the session, the key is discarded. Automated Sign on: Parsing data in the user�s PAC (privilege attribute certificate), the Agent transparently signs the user in to the application. For each application a user accesses, the appropriate agent retrieves the appropriate information from the PAC to perform this service. Authentication: The Agent verifies the user�s certificate by examining the digital signature on the PAC. Event Logging: All transactions carried out by the Agent on behalf of the user are reported to the event subsystem in the Keon Security Server. The Security Server is thus a central location for gathering enterprise-wide data on application access. RSA provides a ready-made Agents for SAP R/3. This Agent, described as a �wrapper agent,� enables the SAP/R3 application - which has no native awareness of public key infrastructures - to function within a Keon-protected system. To protect applications for which no ready-made Agents are available, RSA Security offers a range of free SDKS - the Keon Agent SDK (software developer�s kit), Line Encryption SDK (to create a SSL encrypted tunnel), and a Single Sign-On client-side SDK. Installation can be a lengthy process, depending on which components are required, but 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 Server installation procedure. The basic CA software (which originated from Xcert) is extremely easy 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, and takes the installer through a very straightforward configuration wizard to get things going. This process will be streamlined even further in the next release. 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. CRLs can also be made available to HTTP clients via the CRL Server component. RSA sells the Netscape Directory Server, which is provided as part of the Web PassPort option. Of course, if you want the full-blown Advanced PKI, as tested here, then there are additional modules to be installed, but most of them are almost as straightforward as the CA, and with excellent documentation (PDF only) to back up the process. The exception to this is Web PassPort, which we found to be confusing in the area of integrating the CA with the LDAP directory used for the secure credential store. The documentation here is inadequate, and it took a few support calls before we had this working correctly. It should be noted that the Keon Security Server and Desktop will work together with basic self-signed certificates independently of the CA if required, and will also work with other standards-compliant CA�s. Since everything can be purchased separately, it is thus possible to opt for the basic CA, just the Security Server and Desktop or the full-blown Advanced PKI system. Once installed, the Keon CA is managed entirely via an intuitive and very usable browser interface. During installation, an administrator�s certificate is issued and signed by the Administrative 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.
The Administrative CA issues both administrator and vettor certificates.� 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 four main menu options � known as �Workbenches� � selected via icons along the top of the screen. The first two are used rarely. System Configuration allows the creation and modification of Access Control Lists (restricting access to files and directories on the CA or other Web servers on a per-certificate or per-group basis), LDAP rules and logging parameters. Administrator Options provide the means to approve, reject and maintain the special Administrator, Vettor 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 CA�s (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:
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. Before leaving the CA, however, 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 �backend� 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, and policies enforced at the CA will be carried over to each RA associated with it. 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. 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 select the appropriate CA and 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 profile (which determines the uses to which the certificate can be put) and extensions - or override those selected by the requestor. 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. 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. 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. 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 which CAs end-users can request certificates from, what information 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. On selecting this option, the user is presented with a simple 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 is 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). 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. 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 browse All in all, the Web interface to the Enrolment Server is pretty standard stuff, very straightforward to use, and not difficult to customise. The Keon Security Server (SS) can be deployed with or without the Certificate Authority, and is designed to manage all users, digital credentials, CA trust relationships, CRL verification and management reporting from a central location. It is important to realise that, because SS operates independently of the Keon CA, it is quite possible to deploy it alongside any standards based CA or directory from any other vendor (contact RSA for details of compatibility with other products), or even to use outsourced certification services from organisations such as VeriSign.
For any organisation which is serious about its security, the Keon SS is an essential add-on to the basic Keon CA � together (along with the Keon Desktop) they make up the Advanced PKI solution. SS will even provide added value for those organisations which have already deployed alternative CA products to the basic Keon offering. Acting as the trust manager for the enterprise, SS determines which CA�s are to be trusted and provides one central point from which these issuing authority relationships are controlled and updated. One of the biggest problems in today�s networks � with or without PKI � is the provision of secure authentication mechanisms for log on, file encryption, e-mail, and so on. Traditional passwords are no good, since if they are of a length that is easily remembered by the user, they are also easy to attack by the outsider. One-time password hardware token devices have been available for some time from RSA (formerly Security Dynamics), and whilst these are adequate for remote access implementations they are not able to have a digital identity associated with them. Digital certificates provide a solution to the identity problem, but introduce problems of their own in current implementations. Until smartcard readers become standard issue on today�s PC, our digital ID is locked into the browser on a particular machine. Roaming users need to become proficient in exporting their digital certificates and private key-store from one machine to another. But if the legitimate user can do it, so can anyone else, thus rendering the digital ID useless. Where enterprises are deploying smartcards and readers, RSA SecurID smartcards (or any PKCS#11 compliant device) can be used to store and carry the users� credentials. Alternatively, the Keon Security Server can provide a unique virtual smartcard, called the Credential Store. The Credential Store is an encrypted software repository for a user�s digital certificate, private keys and other unique authorisation attributes. It can be securely and automatically delivered from the Security Server to wherever the mobile worker logs in, without dependency on a smartcard reader. In either case, Keon Security Server allows central policy management over how users gain access to their critical private keys and credentials.
Each Credential Store can be protected by a password or a much more secure one-time SecurID pass code/PIN number (using the optional ACE/Server component). Access can be allowed using one only or either of these methods, and the administrator can determine whether the user will be allowed to access their digital credentials off-line or not. This means that it is possible to prevent users from logging on should the Security Server not be available for any reason, thus ensuring that the appropriate and most up-to-date policy is always applied. High availability implementations will overcome the inherent single point of failure in this model. Secure replication capabilities provides support for distributed management structures as well as automatic fail over and load balancing for large, mission-critical environments. Keon Agents provide �wrappers� for existing legacy applications that have no native awareness of PKI protocols. Via Keon Agents, applications can communicate with Security Server to participate in a Keon PKI and provide secure client-server authentication, single sign-on, encryption and access control where required. RSA Security provides a ready-made Agent for SAP R/3 and SDK�s to for PKI-enabling other applications. Management of the Keon Security Server is via the Java-based Keon Administration utility that allows creation, modification and deletion of Keon Desktop accounts, as well as managing digital credentials such as virtual and physical smartcards. This utility would be easy to use were it not for the fact that the Java Virtual Machine regularly consumed 100 per cent of available CPU time, making the console slow and painful to run. Make sure you install this one on a real high-end Pentium machine.
Whilst the Security Server provides centralised management of user credentials, Keon Desktop is the client-side application that communicates with SS to provide a secure end-to-end solution. Through its Local Security Service (LSS), the Desktop displays a GUI dialogue box in place of the normal Windows login to prompt for user name and password or SecurID Pass code. When this information is verified by the Security Server, the Desktop opens the Smartcard or Virtual Card and communicates with other system components to make Keon security services available to the user. The Desktop can be configured for integrated login, where the same Desktop login dialog logs the user in to his or her operating system account as well as to Keon security services (i.e. single sign-on), or for on-demand login, where the user accesses the operating system account in the standard way, and the Desktop initiates its own login dialogue only when a service is requested that requires Smartcard or Virtual Card credentials. The Desktop may store users� Virtual Cards even though the Security Server is the authoritative repository for these credentials. We would prefer to see credential stores wiped from the machine automatically once the user logs out (a copy of the credential store remains on disk, although credential details are wiped securely from memory). As soon as a user name is entered, the Desktop communicates with the Security Server to determine if it has the most recent version of that user�s Virtual Card - if not, the card is immediately downloaded.
Besides performing these services, the Desktop includes APIs that work with the PKCS #11 and Microsoft CryptoAPI programming interfaces. Applications that use these APIs can interact with the LSS, making it possible for Netscape or Microsoft email and browser products (or any applications that conform to the Netscape or Microsoft security architecture) to use the digital certificates and private keys stored in Keon cards. Users no longer have to export from one application to import to another, and thus their credentials and private keys are always held securely. Another huge benefit is that machines which are used for �hot desking� applications (i.e. which have multiple users logging in to them regularly) can now provide instant access to digital credentials for each user, and only the user that is currently logged in. For instance, Bob logs into the PC and runs Internet Explorer � Bob�s digital certificate is automatically made available to him via Keon Desktop. When Alice logs into the machine later the same day, IE will only present her certificate, Bob�s is no longer available. The Desktop also provides two forms of file encryption. The first is manual encryption, where the user can manually encrypt specific files, producing a self-extracting .exe image that is password-protected. This provides a partial substitute for the security available with secure email when, for instance, the Keon configuration does not include this service, or when an outside recipient does not participate in a PKI system.
With automatic encryption, the user can designate directories in which all files are to be automatically encrypted when stored and decrypted when accessed by an application. This process is transparent to the application and the user. To an authorised Desktop user the files and directories appear as normal, whilst to an unauthorised Desktop user, Security Server displays a message indicating that they do not have access to those files. To any other standard user (without the Desktop component installed) the encrypted files simply appear to contain garbage. Note that the combination of Keon Security Server and Desktop also provides an alternative method of key recovery, if required, since all credentials and private keys are maintained centrally by the Security Server in individual Triple DES-encrypted credential stores. Keon Desktop also stores session keys for file encryption, encrypting them separately with the public key of the Key Recovery Officer. A separate utility then provides the means for the KRO to recover session keys and decrypt data for users who have lost their own decryption keys. Lost passwords for virtual smartcards can be recovered by the Keon Security Server administrator using a unique Password Unlocking Key (PUK). An alternative to the full-blown CA-level cross certification is also on offer, simply by importing the appropriate root certificates into the Security Server. The new trust relationships are then pushed down to the Keon Desktop clients at next logon, thus accomplishing the required �cross certification� automatically. Keon Desktop also allows the support of the sort of features we would like to see as standard in all PKI implementations. For instance, as well as offering the secure mobile credential store for each user, it also provides centralised trust management, and dynamically checks the respective CRLs across the trust hierarchy. The Security Server acquires the appropriate CRLs on demand and then caches them for the specified validity period, from then on acting as an instant responder for other clients checking the same CRL. This CRL checking is completely automatic and transparent to the end user, and means that digital signatures can be verified completely and accurately at all times. For many, the thought of deploying yet another client-side component to every machine in their organisation will be an unattractive proposition. RSA has attempted to make this process as painless as possible by providing a �pack� option. The procedure is simple. The administrator installs and configures a single client. The Pack Wizard then takes him step-by-step through what parts of the configuration (if any) the end-user is allowed to override at install time before creating a self-extracting .EXE file. This file can then be deployed to each workstation via whatever software distribution tools are normally used. The installation takes only a couple of minutes, and the whole process can be completely �silent� if required, the user being completely unaware of what is taking place until the reboot prompt at the end. Click here to view Checklist Sample pricing by number of users (irrespective of number of certificates per user):
Note that these are guide prices only. As with other PKI products, professional services to cover such things as deployment and integration work will incur an additional cost. With the acquisition of Xcert, the RSA Keon CA � previously the weakest part of the Keon Advanced PKI system - has finally been given the chance to shine in its own right. With all 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 � it can now stand on its own as an enterprise-level CA. It also makes for an even better all-round package when combined with the Keon Security Server and Desktop in the Advanced PKI offe Providing you are willing to deploy a desktop component, the Advanced PKI solution provides all the functionality you would expect to find in other PKI solutions and quite a few that you might not. Some of these capabilities may not work the way you are used to seeing them work in other PKI systems, but the combination of the Security Server and Desktop allows Keon Advanced PKI to provide a secure and robust solution, with a number of important advantages. For instance, it provides capabilities missing from PKI implementation without a desktop component, such as fully automatic CRL checking, automatic key histories, and signature verification, as well as a unique secure credential store that moves around the network with the user. For anyone who has already deployed a CA, the Keon Security Server and Desktop will add similar value, since they will work alongside any standards-compliant CA and directory. However, it should be noted that whilst the Security Server and Desktop components were essential components of earlier RSA CA implementations, the latest version of the CA is more than capable of standing on its own, and provides all the features you would expect of an enterprise-level CA. Prices for the Advanced PKI solution do appear daunting at first, but the unlimited certificate/ server/ application model employed by RSA means that there is only a one-off payment required, and no more to pay no matter how many certificates are deployed nor how frequently they are renewed. This may actually work out to be more cost-effective for certain applications. Corporate
Headquarters: Europe, Middle
East and Africa Sales: European Local
Country Offices: RSA Security -
Denmark RSA Security -
Finland� RSA Security -
France RSA Security -
Germany RSA Security -
Italy RSA Security -
Netherlands RSA Security -
Norway RSA Security -
Poland, Central & Eastern Europe RSA Security -
Spain RSA Security -
Sweden RSA Security -
Switzerland Click here to return to the PKI Index Section
|
 |
Send mail to webmaster
with questions or�
|
