 |
|
|
Safelayer is a Spanish-based company which has developed a range of solutions for companies, institutions and public entities, that allow the execution of secure commercial transactions between them and their customers. The KeyOne product family is designed to generate, use and manage digital certificates using recognised standards and protocols (SSL, X509, S/MIME, PKCS). The KeyOne architecture is both flexible and scalable, and allows the development of different models of certification, providing the means to:
In addition to its range of PKI products, Safelayer has also created a SET (Secure Electronic Transactions) solution, providing the means to make secure credit card payments across the Internet. All SET components have received SETco approval. The KeyOne PKI solution consists of the following components:
Note that Scryptor and the PSS are basic architectural components and are not available separately. There are two modes of operation for the CA � on-line and off-line mode � each handled by different CA and RA modules. In off-line mode, the CA and RA components are completely separate, and communication between them is effected via the use of batch files. This allows organisations to implement a PKI where the CA is isolated and operates without being connected to a network, thus increasing security. In on-line mode, the RA and CA communicate directly to eliminate the need for administrator intervention at the CA. This can be far more convenient, though requires the CA and RA to be able to communicate directly over the network. The model that is chosen will depend entirely on the needs of the customer. Note that there is no auto-registration component provided as part of the KeyOne system since Safelayer maintains that that is not the target market for this product (although a future version will include this functionality). With the current version, Safelayer is aiming KeyOne at those organisations where rigorous and often manual checking at the RA is always carried out before a certificate application is approved. Many of these components manage internal databases which are constructed using the Safelayer 3D integrity system (i3D). The i3D technology protects critical databases from unauthorised manipulations of the contents via sophisticated hashing and signing mechanisms. i3D also guarantees non-repudiation of the operations performed in the database by the KeyOne system. The main function of the PSS is to provide a secure storage area for certificates and security-sensitive data. The PSS can store any kind of signed objects � such as certificates (along with the complete hierarchy for validation purposes) and CRLs � as well as other critical data such as private keys. The PSS also keeps a history of expired certificates, along with the corresponding private keys if available, thus allowing �old� data to be decrypted long after the enciphering key has been superseded.
The PSS can be stored on different media, such as disk, smartcard or Hardware Security Module (HSM), and all the contents of the PSS are protected from unauthorised access and tampering using a mixture of Triple DES encryption, hashing and digital signatures. KeyOne CA is a certification authority whose main function is to issue certificates and revocation lists. Without the CA Online Server module an on-line interaction with the CA is not permitted. Instead, access to its services is accomplished in an off-line mode through the exchange of input and output batch files. This enables KeyOne to support PKI deployments where the RA and CA functions are both logically and physically separate from one another, since batch files can be exchanged via shared directories, TCP sessions, e-mail or even floppy disks. First, the CA receives an input batch file containing a set of certification or revocation requests from the RA. At the request of the administrator, it processes the input file, generating the X.509 certificates, PKCS#12 keys (if requested), and an output batch file for the RA which allows it to publish the issued certificates and provide the means for the end users to acquire their certificates via the Web interface. KeyOne CA always has an associated PSS where certificates, private keys and CRLs are stored. The CA�s PSS can optionally have a PKCS#11 device associated with it. When the cryptographic device is present, the CA private keys are not stored in the PSS but in the PKCS#11 device instead, and only a reference to those private keys is stored on the PSS itself. KeyOne RA is the Registration Authority component whose main functions are to receive and record certification and revocation requests coming from end users, to approve or reject those requests, to construct request batches for processing by the CA, to receive processed batches from the CA, and to publish issued certificates and CRLs. KeyOne RRA acts as a browser-based �remote approver� allowing the RA administrator to perform several key tasks that would otherwise require the full RA, including:
This is a connection module that provides on-line access direct to the CA services from the RA. Batch communication is still used, but the transfer of batches between RA and CA is automatic and instantaneous. Upon receiving a request batch through HTTPS from the RA, the Online Server processes it immediately without any administrator intervention. The corresponding reply batch is also generated automatically and returned to the RA immediately via the HTTPS connection. KeyOne CA Online Browsing Server This is a module that provides direct read access to the CA internal database contents and makes them available as HTML pages through an HTTPS-authenticated connection. Thus, an external application can browse details of issued certificates via a remote Web browser or application. It is possible to restrict access to database contents in order to ensure that an RA can only view the certificates that it has issued. This is the RA component that is used as part of the on-line CA model. Its operation differs considerably from the off-line RA in that it does not maintain an internal database, and thus all interaction with the CA is in real-time rather than through off-line batches. The scripts that determine how the LRA works are also stored on the CA host server, not on the LRA machine. Each time the LRA is fired up, it connects to the CA via HTTPS and downloads all the scripts and images that it needs to operate. This mechanism provides a high degree of flexibility, since it is possible to modify the scripts at the CA to change the way the LRA works � the new mode of operation will then be adopted automatically from the next time the LRA connects to the CA. Updating or upgrading all the LRAs that are associated with a particular CA is also made easier, since the scripts need modifying only once at the CA. KeyOne WEB is a connection module that allows the construction of HTML pages able to access services offered by KeyOne RA through a standard CGI interface. The creation of such HTML pages allows end users to make certification requests and to retrieve certificates and CRLs by using their browser. This component consists of two modules: the Request Module and the Publication Module. The Request Module stores end user certification requests in the KeyOne WEB database in order to later import these records to the RA. The Publication Modules publishes certificates and CRLs that have been exported from the RA to the KeyOne WEB database in the corporate Web pages. The KeyOne Desktop is a client-side application that is integrated with Windows Explorer to provide the capability to encrypt, decrypt and digitally sign files on the desktop, as well as verify digital signatures. It also provides the capability to view a certificate verification path, and browse an LDAP directory for PKI-related information. The various KeyOne Toolkits provide the means for developers to integrate PKI functionality into both client and server applications. Each toolkit provides different capabilities: Toolkit KeyOne Cert (x.509, PSS) � This provides basic cryptography functionality and administration of the PSS:
Toolkit KeyOne File (PKCS) - Provides generation and processing of secure content with a PKCS#7 format:
Toolkit KeyOne Mail (S/MIME) - Provides generation and processing of secure messages with S/MIME format:
Toolkit KeyOne Channel (SSL) � Provides both client and server Secure Sockets Layer (SSL) capabilities:
Toolkit KeyOne for SAP R/3 - This toolkit provides public key cryptography for SAP users through GSS-API and PKCS #7 standards. This toolkit is compliant with both SNC (Secure Network Communications) and SSF (Secure Store & Forward) interface. Security is implemented using standard PKCS #7 data structures and SSL TCP/IP connections. KeyOne SmartTokens (PKCS #11 and CSP) - These SmartTokens provide PKCS #11 (RSA) and CSP (Microsoft Cryptographic Service Provider) cryptographic libraries for G&D (Giesecke & Devrient GmbH) StarcOS S2.1 and StarcOS SPK2.3 Smart Cards, for the Spanish TIBC standard (Tarjeta Inteligente para Bancos y Cajas), and for a plain disk emulation token. In the NSS test the PKCS #11 SmartToken for both StarcOS S2.1 and StarcOS SPK2.3 were tested with the LRA. Scryptor provides an interpreter and scripting language that is capable of providing cryptographic capabilities, SQL database access, HTTP connectivity, SMTP connectivity, LDAP connectivity, access to the NT/Windows 2000 Registry and file systems, and so on. This is one of the most interesting components of the KeyOne system, and is the key to its power and flexibility. Although a default CA configuration can be run out of the box, most KeyOne systems are sold via systems integrators who will provide extensive customisation via the scripting capabilities in order to fit the PKI closely to the requirements of the customer. A number of different script files are associated with various parts of the KeyOne system. Most of these remain untouched apart from modification to a few key variables and parameters, but others are designed specifically to extend the processing of the KeyOne system. For example, an important feature of the Batch Processing Module (the component that provides the communication between the CA and RA) is that it can be customised by adding code to a set of pre-defined �Callback� functions in the config_ca_callbacks.ws Scryptor file. These functions � which contain no code by default � are called by the system at key moments during the batch processing loop :
As you can see, it is possible to considerably extend � or even replace portions of � the default operation of the KeyOne system in order to suit almost any circumstance. In the current version, for example, there is no built in key archive capability, so Safelayer provides a version of KeyOne with suitable Callbacks to write encrypted keys and passwords out to disk if required for manual archiving. Naturally, with such a powerful means of altering the way KeyOne performs it duties, it is vital that the integrity of the system is protected against intruders introducing scripts into the system which would take certificates, private keys and passwords and mail them outside the organisation each time a certificate is issued. This is achieved by digitally signing each and every executable and script in the system using the PSS Root key. Whenever a script is modified, it must be re-signed before it can be used. Should the system come across any script where the signature cannot be verified successfully, it will cease to function until the problem has been rectified. As with any PKI solution, it is necessary to put some careful thought and effort into the installation process. The actual physical installation of the software packages is not difficult, following a simple process of inserting the requisite CDs (of which there are many) and running the SETUP program. Prior to that, it is also necessary to install the underlying database (Oracle or SQL Server), the Scryptor scripting environment, Web server and LDAP server. The documentation is extensive and helpful when it comes to installation (despite some minor Spanish-English translation niggles). However, we would like to see all the documentation replicated on every CD, or a separate CD dedicated to documentation - we found it difficult to locate specific manuals amongst the rather large pile of CDs we had available. For this evaluation, the test environment was entirely Windows 2000, and we were running KeyOne 2.1, Microsoft SQL Server 7.0, Netscape Directory Server 4.1/3.51, and Internet Information Server 5. On the hardware front, we used an nCipher nShield Hardware Security Module (HSM) to protect the CA, splitting root keys across several smart cards. At the RA, we used three card reader devices to provide hardware protection for the online registration facility:
The smart cards themselves were PKCS #11 v2.01 devices running StarcOS S2.1 and StarcOS SPK2.3 with Safelayer PKCS #11 drivers. Having installed the basic software and hardware, the next step is to ensure that all the necessary configuration scripts have been modified to set key parameters such as initial certificate serial number, password timeouts, date and time formats, and so on, before configuring and enabling the batch connectors to provide communications between CA and RA modules. These processes can be time consuming and error prone, and they include a significant amount of playing with directory permissions and script files. However, they are only once to do, and the documentation is excellent. The final step is to ensure that certification templates and Callback scripts have been modified to customise the behaviour of the KeyOne system if necessary. This process would usually be carried out by professional services staff from either Safelayer or one of its distributors. Once everything has been installed it is time to generate the CA hierarchy and PSS. Our Root CA keys were protected by a split key (two of four) group in the nCipher nShield module. This meant we had to provide two smart card and PIN combinations in order to gain access to the root CA (this configuration is completely user-definable, of course, via the nCipher administration interface). The PSS generation program is run from the command line in order to generate the root CA according to parameters entered in the CA Properties text file. The same program is used to generate subordinate CAs, but using a different parameter file, and this time the process also generates a number of certificate requests. The subordinate CA has its own certificate-signing certificate, CRL-signing certificate, digital signature certificate, data encipherment certificate, and a root SSL server certificate for local administration. These requests must be processed by the Root CA to generate the certificates, before being installed in the subordinate CA. Once the CA hierarchy has been defined, the database tables can be initialised and the PSS itself can be generated. Once again, although the documentation is excellent, this whole start-up process is long winded and occasionally confusing and error prone due to the fact that there is a significant amount of text file editing and copying certificate files back and forth. It would be nice to see this process automated using a graphical interface although, as we have said before, it is not a process that needs to be carried out very often. The off-line CA is used when it is required to have a logical gap between the CA and RA � perhaps if the two are being operated by separate companies, and therefore each requires its own database, or when it is required to operate the CA with no connection to the network for security reasons. When running KeyOne CA on a day to day basis there are always two modules involved, both of which run on the CA host machine and communicate via HTTPS. The server side component is the actual CA �engine�, whilst the client-side component is a browser-based front end through which the administrator manages and communicates with the CA. When the server-side component is started, it automatically fires up an instance of the default Internet browser from which the administration interface is run, and only requests coming from this browser (on the same host) will be accepted by the CA engine. The CA keys can be protected either on disk or via smart card or Hardware Security Module. The administrator interface is clear and intuitive, with a list of menu options down the left hand side of the screen covering login, PSS management, policies, RA management, batches, certificates, CRLs and �miscellaneous� (viewing log files). The PSS Management option is there to provide management of root and subordinate CA entities, certificate management, key and certificate regeneration, and handling of certification requests for root and subordinate CAs. Note that it is not possible to define different �roles� for different administrators to provide multiple levels of administrative access. Any administrator with access to the correct keys can effectively perform any function within the CA administration interface. RA Management is another option that will be used infrequently, and is there to provide the means to certify an RA �Responsible� (the term for the highest level RA administrator) from a certificate signing request, as well as allowing or inhibiting policies for individual RAs. Policies define constraints on certain types of certification requests accepted by the CA � perhaps restricting certificates to encryption only, or signing only - as well as the properties of the certificates themselves. A number of default policies are provided out of the box, but it is very easy to modify these via the Policies option in the CA menu. The policy properties are presented in a GUI form, allowing the administrator to select or deselect specific items such as the signing algorithms supported, certificate serial number generation method, and so on. For those familiar with the Scryptor scripting language, it is possible to edit the text version of the policy directly, and this also provides the means to create brand new policies and certification templates. Request batches received by the CA can come from two sources. First, there are those batches generated by a recognised RA. Second, it is possible to generate �bulk request� batches from existing data (such as external database tables) via Scryptor scripts. In a similar way, it is possible for the CA, using a script, to generate a bulk return batch for export to an external database or smart card printing unit. A duly certified RA may request a CA to issue, renew, suspend, enable or revoke a series of certificates via an operation batch. Revocation is via Version 1 or Version 2 CRLs, OCSP (via the Safelayer OCSP responder or third parties such as Valicert) or Certificate Revocation Trees (Valicert). KeyOne CA processes input batches containing one or more certification requests and generates output batches containing responses to those requests. Batches are processed via the menu option of the same name in the CA front-end. The batches from the RA are placed in the batch input folder and the Load Pending Batches option is selected to load them into the CA database. During this procedure, the digital signature applied by the RA is checked along with the complete certification chain. A list of batches can be browsed via the View Batches screen. Batches listed on this screen can be filtered according to status, or date and time accepted, and their contents viewed right down to the individual certificate requests. The batches can then be accepted or denied by the CA administrator, and once accepted, the CA begins the certification procedure according to the policy in force. Processed output batches, containing the issued certificates and/or CRLs (or a rejection, should the batch have been denied by the CA), are then returned to the RA via the Generate Output option. Once there, they must be loaded into the RA database to enable to certificates and CRLs to be published. Note that there is no built in key archive and recovery capability in the current version of KeyOne. Safelayer has implemented a rudimentary archive system using the Callback capabilities which seems to work quite well, but a full integrated archive and recovery feature will be built in to a future release.
Via the Certificates menu option, it is also possible to issue a single certificate and PKCS#12 via a certificate request coming directly from a third party, and not via a RA. The third party can generate a key pair and request a certificate (X.509, PKCS#10 or text-based request), which is then processed as an individual �auxiliary batch� within the CA. Alternatively, the third party can request both a certificate and a key pair, in which case the CA generates the key pair, issues the certificate, and then generates a PKCS#12 containing the certificate and corresponding private key. In addition to user certification, this form of single certificate issue is used mainly for certifying organisational entities such as departments, VPN devices, and even other CAs for cross certification purposes. Note that cross certification is available only at root level in the hierarchy. Also from the Certificates menu option, it is possible to browse the issued certificates, and these can be filtered by date and time issued, or by status. Status can be either Issued, Revoked or Suspended, and whilst viewing certificate details, it is possible to revoke, suspend, unsuspend or export it to a binary file (if the PKCS#12 is available, this too can be exported containing the certificate and its private key).
As with certificates, CRL templates can be defined via text files in KeyOne, and revocation lists can be viewed and managed via the CRL option in the main menu. The CRL browser provides a list of all CRLs issued, displaying the CRL template name, date issued, date of next update, CRL number, CRL distribution point, and the number of entries (certificate serial numbers) in the CRL itself. From the browsing screen individual CRLs can be selected in order to view the contents, export them to a binary (.CRL) file, or view the revoked certificates. Although CRLs are updated automatically when output batches are generated, it is also possible to force an immediate update from the CA administration front end, even if the previous CRL has not yet expired. KeyOne CA Online is a connection module which provides direct on-line accessibility to the CA�s services. Unlike the off-line CA module, the CA Online does not have a client-side itself, just a server-side component that communicates directly with the RA via HTTPS. In order to do this, it requires a special version of the RA � known as the LRA (Local Registration Authority) � to provide complete automation of the batch sending and receiving process over a secure channel. Because the CA Online runs on the same database, PSS and PKCS#11 device as the normal CA, a specific administration front-end is not required. Thus all administration tasks are performed via the KeyOne CA component, as already described in the previous section. When a request batch is received by the CA Online server, it is immediately processed and returned without requiring any intervention from the administrator. The general batch communication and processing is identical to that used by the off-line CA, with the sole difference being that the request batch is now processed as soon as it is received, and the answer batch is generated immediately and sent back through the HTTPS connection. Note, we are not talking about auto-registration here. The registration process is still performed as normal, with all the usual manual checks and procedures that should be performed prior to approval of the registration request. Instead, CA Online merely streamlines the certificate and CRL issuing process where it is not necessary to have the CA completely disconnected from the network. During the on-line processing of a request batch, the same set of Callback functions is executed as with the off-line CA, but the code is taken from a different script file. Thus is it possible to customise the processing features of the on-line and off-line CAs in different ways. One other major distinction between the on-line and off-line CA components, is that CA Online controls the function of the LRA by means of a set of scripts which are stored at the CA and transmitted to the LRA each time a connection is established. Because the LRA does not have its own local database, as would the normal KeyOne RA, it is also necessary to provide access to the certificate table of the CA Online internal database over an HTTPS connection, and this is achieved by running the KeyOne CA Online Browsing Server component alongside the CA Online server. In order to handle the two CA models � off-line and on-line � it is necessary to employ two different Registration Authority applications: KeyOne RA and KeyOne LRA respectively. In KeyOne RA two roles have been defined so that administrators with different tasks and privilege levels can be created. There is a Responsible profile, which has the right to perform any action on the RA, and an Approver profile, which is only allowed to process end user requests and to publish certificates and CRLs. Each RA must have one Responsible administrator and can have zero, one or more Approvers, which can only be created by the Responsible. Note that these roles are fixed, and the level of administrative access cannot be restricted or enhanced further for either role. Approvers approve or deny certification requests from end users, make revocation requests, make suspension or unsuspension requests, and finally publish certificates and CRLs. In addition, they digitally sign every transaction they perform for the RA in order to provide a secure audit trail and guarantee non-repudiation of their actions. A Responsible can perform the same actions as an Approver, and in addition he can create Approvers, build request batch files addressed to the CA, and process certificate batch files coming from it. Furthermore, the Responsible ciphers and signs the batch he constructs for the CA in order to ensure authenticity and confidentiality. Similarly, he will decipher and check the digital signature of the incoming batches sent by the CA. Request batch files can be transported to the CA via HTTP, FTP, SMTP/POP3 mail, or even via floppy disk. Response batches can be returned in the same way. When starting the application, a PIN or password is necessary to access the PSS, which can either be stored on hard disk or in a Hardware Security Module (such as the nCipher nShield used in testing). As with the CA, administration is achieved via a secure HTTPS session between a local instance of the browser and the RA �engine�.
The KeyOne RA component administers Certificate Signing Requests (CSRs) from Web system users (via the KeyOne WEB interface, for example) or via third party applications via the API (perhaps for bulk registrations). All requests received in the correct format will be stored in the database table, and the Publication Management option in the main menu provides the means to determine if there are any outstanding requests. If it is desirable for the RA to actively alert the administrator when new requests are received, this can be achieved via scripting. Once these have been downloaded, the Requests Management option provides the means to approve or deny them. The Request Browsing screen provides a list of outstanding requests in a table, each line containing details of the request such as the request ID, applicant name, status, and the requested certification policy. Further information (such as the actual X.509 certification request fields) can be displayed by clicking on the Applicant column of the desired request. From here, individual (or groups of) requests can be approved or denied, and previously issued certificates can be viewed, suspended, unsuspended or revoked. Following this, the Batch menu can be used to generate request batches for the CA containing the various certification, suspension, unsuspension, revocation or update requests. Generated batches can be viewed in details � right down to the individual certificate or certificate signing request details if required � and can then be exported to the CA either directly (via any one of the active KeyOne connectors � such as HTTPS), or by exporting to a file for an �out of band� delivery such as e-mail of floppy disk. Having been processed by the CA, the batches are returned for the last time to the RA for publication. The Batches menu provides the means to update certificates and CRLs on the Web and in the LDAP database, thus allowing them to be accessed by external users. Users who have a pending certificate request will be notified via e-mail that their certificate is ready for collection. Issued certificates can be viewed within the RA application, allowing the certificates (.CRT), PKCS#7 and PKCS#12 (where applicable) objects to be exported, The RA can send out automatic certificate expiration notices to existing users whose certificates are due to expire shortly, thus giving them time to apply for a new one via a special URL contained within the notification e-mail. Note that although all administration functions must be performed locally on the RA host itself, the day-to-day activities such as certification request approval and denial, certificate suspension and unsuspension, and certificate revocation, can all be performed by an authorised Responsible or Approver via a remote Web interface called KeyOne RRA. KeyOne LRA is used in conjunction with the KeyOne CA Online. The LRA has no internal database of its own but, in order to operate, it does require a PSS where its own certificates and keys (for data encipherment, digital signing and SSL communication) will be stored. This would usually be an external PKCS#11 device. As with most of the KeyOne components, the LRA is actually divided into two modules � the server-side �engine� and the client-side user interface, both of which must reside on the same host. The user interface is browser-based, and communicates with the engine using SSL. The main difference between the LRA and the RA is that the LRA communicates with the CA in real-time in order to provide �instant� registration. The two components therefore share a single database, and this naturally requires that the CA is connected to the network in some way to allow it to be accessed from the LRA host. This model would therefore not be suitable for those organisations that require the highest levels of security, where the CA is physically disconnected from the network. Unlike the KeyOne RA, the behaviour of the LRA is determined by a number of Scryptor scripts which are downloaded from the CA each time the LRA starts up. This means that it is possible to change both the appearance and the functionality of the LRA from a single central location, and have it applied each time the LRA starts. Access to the certificate database � perhaps to look up certificate details in order to suspend or revoke � can be accomplished via a connection to the KeyOne CA Online Browsing Server which provides remote access to the CA database via HTTPS connections.
Because the LRA�s behaviour depends almost entirely on the scripts downloaded from the CA Online, an LRA could fulfil almost any function that can be programmed using the Scryptor language. Nevertheless, in the current release the scripts are designed to provide Registration Authority functionality:
Normally, with the off-line model, the user requesting the certificate will enter his personal details in the browser front-end provided by the KeyOne WEB connector, before submitting the request to the RA, where it will be approved or rejected. In the LRA, the certificate request is generated immediately from details entered into the on-screen form or retrieved from a file. As soon as those details have been entered, the LRA communicates with the CA in real time to issue the certificate, and the certificate and private key details are written immediately to a PKCS#11 device. Both the KeyOne CA and RA provide the means to view log files which record all the significant operations generated by the administration applications. Entries can be filtered on date and time and ordered by date or event type. Each line displays a severity indicator, data and time, event ID and a description. A hyperlink against each line provides the means to call up more detailed information on each individual event. The information presented is fairly basic, however, and there is no way to print this out or export to a disk file for processing by other applications. Standard third party reporting utilities (i.e. Crystal Reports) can be used, however, to create custom reports through access to automatically generated plain SQL mirror tables. KeyOne has been designed as an open CA product, and therefore it does not include a client element that is required for PKI functions. Instead, it relies on the standard Web browser model, or PKI-enabled applications that can take advantage of KeyOne functionality. A number of tool kits are provided for this purpose (see Architecture section). KeyOne WEB is the component that provides an HTML interface for the user through which he can interact with the Registration Authority to make certificate requests, revocation requests, consult published policies and CRLs, and install certificates received from the RA. KeyOne WEB also enables users to request certificates for various servers, such as Netscape, IIS, Apache, NCSA, Oracle and so on. The KeyOne RA receives certification requests from KeyOne WEB for approval. Once approved, they are forwarded to the CA which will generate the private keys and already certified public keys, or only the certified public keys should the user already have the key pair. The RA is also responsible for keeping data from issued certificates and data associated with requests. Personal Certificate Operations KeyOne WEB allows the end user to request a certificate for personal use in a Web browser or e-mail application, and the public and private keys can be generated either by the user�s browser or by the KeyOne CA. In the former case, the user�s public key will be certified by the KeyOne CA component and the certificate associated with this key will be sent to the user who requested certification. If the keys are generated by the CA, then the user will receive a PKCS#12 containing the key pair (or pairs) and associated certificate(s). When requesting a personal certificate, the user is presented with an HTML form in which to enter the required details. There are a number of information fields (definable by the administrator in the policy), including name, e-mail address, organisation, department, country, certificate renewal password, cryptographic provider and the type of certificate or policy to be applied. A number of default policies are available out of the box, including generic, digital signing, encryption, or developer. The policies made available through the Web interface must first be defined within the CA and associated with the appropriate RA before they can be applied. As the data is submitted, the browser will generate the keys before packaging the request and sending it on to the RA. Certificates can also be requested in PKCS#12 form, where the keys will be generated at the CA, in which case the user is also prompted for a PIN number to access the issued PKCS#12 object. Once the RA has approved the request and the CA has issued the certificate and returned it to the RA, the user is notified via e-mail that the certificate is ready for retrieval. The e-mail notification will include a URL from where the certificate can be downloaded as well as a unique reference number that identifies the requester to the RA. When the user follows the URL link, he will be prompted for the reference number, at which point the certificate will be downloaded and installed automatically. If a PKCS#12 was requested, then the file can be saved to disk or opened within the browser (using the PIN number specified during registration) to complete installation of the certificate and keys.
Shortly before the certificate is due for renewal, the user will receive a notification e-mail from the RA. On selecting the Certificate Renewal option in KeyOne WEB, the user is prompted for the certificate ID (from the notification e-mail) and the renewal password (selected when the original certification request was made). The rest of the process is similar to a normal certificate issue. Other options in KeyOne WEB include the ability to download the Root certificate, download CRLs, and view published certification policies. KeyOne Desktop is a Windows application that provides the means to sign, verify, encrypt and decrypt files, view the PSS database and navigate the LDAP directory from the user�s PC. KeyOne Desktop integrates fully with the Windows environment by adding icons to the system task tray and options to the context menus. Information that can be encrypted and signed can be obtained from the Clipboard (via the task tray icon) or by right clicking on a file or desktop icon and selecting an option from the Windows Explorer context menu. The deciphering and signature verification processes are performed in a similar way. The LDAP Navigator is a separate application that provides the means to browse a Windows Explorer-style hierarchical view of an LDAP server right down to the individual entry attributes and user certificate details. Safelayer KeyOne 2.1 is designed as an enterprise level PKI solution that will be at home in any large organisation or as the basis for an outsourced PKI service. It achieves a high degree of flexibility by virtue of the fact that so much of its functionality is based on configuration files and scripts. Thus, by creating new scripts for the Callback functions, or replacing or modifying existing scripts and HTML pages, it is possible to customise the capabilities (as well as the �look and feel�) of the entire KeyOne PKI system. Thus KeyOne would be of particular interest to PKI service providers who are looking to offer a unique �branded� experience for each customer. Our major criticisms would revolve around the lack of automatic key histories and an integrated key backup and recovery system. These can be implemented at present via Scryptor scripts, but they are to be provided as fully integrated capabilities in the next release. More minor criticisms can be levelled at the lack of fully automated installation tools, and the documentation which � whilst generally excellent in content � shows signs of poor translation from Spanish into English. Auditing and reporting could also be improved, especially by the addition of a formatted print output option. Also, there is no automatic registration functionality to enable end users to submit requests and have the information automatically validated and the certificate issued with no RA or CA intervention. This may mean that the current release of KeyOne is unsuitable for some applications, but an Automatic RA capability will be added to a future release. However, KeyOne has enough positive features to override any of these minor negative opinions. In addition to the unparalleled flexibility mentioned earlier, KeyOne also offers two completely different models out of the box � on-line (where the RA and CA communicate directly to provide streamlined face-to-face registrations) and off-line (where the CA is not connected to the network at all for the highest levels of security). Price, too, appears extremely competitive for larger implementations, though somewhat expensive up to the 1,000 user mark. Overall, KeyOne is well worth a look. Company:
Safelayer Secure Communications, S.A. Click here to
go to the Safelayer Checklist |
Security Testing |
Send mail to webmaster
with questions or
|