 |
|
|
UniCERT is Baltimore Technologies’ flagship product, a Certificate Authority (CA) used in PKI systems to provide full-strength security for a wide variety of� eCommerce and enterprise security systems. Using X.509v3 digital certificates, UniCERT provides key management, authentication and non-repudiation facilities for services such as secure e-mail, Internet commerce, secure Web banking, on-line trading and Virtual Private Networks (VPN). The architecture of UniCERT has been designed to be as flexible as possible in order to help it fit a wide range of business and legislatory requirements.� The result is a modular structure that allows new components to be individually added, modified, upgraded or removed as the organisation needs evolve. Separate components can be run on the same machine or can be placed on separate machines to reduce bottlenecks and allow distribution of workload. All modules communicate either through the underlying Oracle database or via secured (PKIX) TCP/IP connections. The core UniCERT modules (as distributed on the main UniCERT CD) are: Certificate Authority (CA) – Signs and publishes certificates and Certificate Revocation Lists (CRL). The CA operates according to its own flexible policy, which is controlled by the Certification Authority Operator (CAO).�� Certificate Authority Operator (CAO) – The Certification Authority Operator (CAO) module is the Security Officer of the PKI. The CAO controls all of the administration functions and grants privileges to other UniCERT modules and operators. There can be several CAO’s if required. Registration Authority (RA) – The Registration Authority acts as a router between Registration Authority Operators (RAO’s), a Gateway and the CA. RA’s divide the PKI system into operational domains. Each operational domain is a separate structure linked to the CA. Intradomain confidentiality is maintained. The RA obeys its operational policy, which is either maintained locally or at the CA. Registration Authority Operator (RAO) –The Registration Authority Operator's (RAO) primary function is to approve certificate requests to be certified by the CA. Each RAO has rights to issue certificates according to the policies that the CAO has pushed out to it Gateway –The UniCERT Gateway consists of three distinct and separate parts: the Web Gateway, the E-mail Gateway and the Virtual Private Network (VPN) Gateway. The three parts can reside on the same machine and act as one integrated module.� The Gateway’s function is to receive remote requests (from Web browsers, via e-mail or from VPN devices) and return certificates and informational messages Token Manager - The Token Manager module is designed to manage the various security and cryptographic functions of smartcards and HSM's (tokens). The Advanced modules are additional components which can be added to the Core UniCERT components, they are sold separately to Core UniCERT. Each module is packaged separately. The modules are: Archive Server –The purpose of this optional module is to securely store end users' private encryption keys. This permits the retrieval of keys at a later date should their keys become corrupted or if it is necessary for some authority to decrypt their data. Keys are only placed in the Archive Server if the policy dictates it WebRAO – The Web Registration Authority Operator (WebRAO) module allows operators to approve certificate requests using a standard web browser. The WebRAO can communicate with the rest of UniCERT over the Internet in complete security WebRA Server – Acts as a conduit of information between an RA and all the WebRAO’s in its domain Unix (Solaris) CA – This is the CA Component compiled to operate on a Sun Solaris OS. UniCERT is not a pre-requisite for these modules, they can be used independently of UniCERT. SiteSecure – Attribute Certificate Server. Timestamp Server – Provides time stamping functions. Before installing UniCERT it is necessary to acquire a copy of Oracle 7.34 or 8, which is used as the underlying database system. Client licenses are also required for each machine (such as a CAO or RAO) that needs to access the Oracle database.� Although this is not usually an issue for some organisations, who may already have installed Oracle, it is a consideration for those deploying from scratch.� To make life easier, however, Baltimore resells both Oracle and a number of third party directory servers�– we tested with the Isocor Global Directory Server. The directory server is only necessary if it is required to publish certificates and CRL’s for LDAP clients – all certificate and CRL data is also stored in the Oracle database. As UniCERT uses the PKIX�standard for secure communications, it is possible to configure it for Intranet or Internet usage. The UniCERT�components – such as the CA, RA, CAO, RAO, Gateway, and so on - can be run on separate computers or together on a single system. Installation is a lengthy process, but relatively straightforward, though minimal knowledge of Oracle is required since it is necessary to create Oracle accounts for the CA and RA. For any serious PKI implementations, the optional Archive Server should be installed too (available separately), and the root CA keys should be protected by Hardware Security Modules (HSM) such as the Baltimore HSP 4000, nCipher nFast or Chrysalis Luna Tokens, which can also be supplied by Baltimore. If an HSM is used, this must be installed prior to UniCERT. Baltimore recommends that the CA be installed on a separate machine and physically secured to prevent access by unauthorised users. The UniCERT CA functions as an NT service, and the administrator can choose between having the CA service start automatically whenever the machine is booted or manually starting it.� Running the CA service in automatic mode stores all its logon information, including the database logon pass phrase and the pass phrase to unlock the CA's private key, in the NT registry. In this case, the access security to the CA configuration is provided only by the security of the machine - its physical security, logon and screen passwords. If the machine is ever compromised, the Certification Authority is compromised too.� If the CA is in manual mode, its service goes to “sleep” on start-up and waits for the administrator to provide the correct initialisation information using the Control Panel applet. When the CA service is run in manual mode, the database logon pass phrase, the CA's pass phrase and the pseudo-random seed data are not stored in the NT registry and must be entered at start-up - however, it does store the other logon information, including the location of the CA's Personal Secure Environment (PSE) file.� As the pass phrases themselves are not in the registry, running the CA service manually provides additional security should the machine ever be compromised.� Once installed, it is necessary to initialise the CA configuration, during which a key pair is generated for the CA itself and the CA Officer (CAO), and a CA profile is completed. The CA profile specifies such things as the distinguished name, key pair size and algorithm, key pair usage, certificate, CRL and directory options, and so on. Key pairs can be generated in software or on a smartcard/token. Automatic certificate rollover for the CA is not supported in the current version (planned for a future release). The resulting Personal Secure Environment (PSE) file holds the CA’s certificate and key information. The PSE can be stored on disk or on a PKCS#11 smartcard/token. When key pairs are generated in the software, the PSE contains both the key pairs and the certificates. In UniCERT v3.0.5, it is possible to have the CA's PSE file split into multiple components and protected by more than one user's pass phrase. In this way, the responsibility for creating or running the CA(s) is shared among two or more trusted security officers.� One person cannot load the PSE if he knows only his own pass phrase and the PSE has been saved as individual components, each protected by a different person's pass phrase. Once the initialisation process has been completed (it needs doing only once) the CAO utility can be run. The random number generator is seeded each time the CAO is run (by capturing random keystrokes and mouse movements) and the PSE file can then be loaded from an encrypted file or a hardware based PKCS#11 token or smartcard.
The UniCERT CA is the nicest one to manage of all those tested - no geeky command-line or sluggish Java-based admin interfaces here. Instead there is a slick graphical Windows utility – the PKI Editor - that allows you to effectively “draw” your PKI structure on screen.� On entering the CAO the administrator is presented with icons for the CA and CAO (referred to as the “CAO Superuser”) generated during the initialisation process. Other CAO’s can be created, and these can be assigned a subset of the tasks available to the Superuser – for instance, they may only be able to create and edit policies, and may not be allowed to edit the PKI itself or revoke certificates. A toolbar allows additional icons to be dragged onto the screen to represent CA, RA, CAO, RAO, Database, Cross-Certification, Archive Server, UniCERT Gateway, PKI-Plus application, and Archive Server Security Officer entities. Some of these icons�– such as the Database – are there for information only and to allow the diagram to represent a complete PKI. Others – such as the RA and RAO – are necessary components and have a number of attributes associated with them.� To create a new RA, the icon is dragged and dropped to the screen, connected to the correct CA, and the properties defined accordingly. For instance, when creating a new RA it is necessary to specify the distinguished name, algorithm (RSA, ECDSA or DSA), key size (from 512 to 2048 bits) and key usage (if applicable).� The key source can also be specified as software (hence the requirement to re-seed the random number generator each time the CAO is started), Racal 722, PKCS#11 token, or PKCS#11 smartcard, if a HSM is selected then Key Generation occurs within the Secure components of that device. The smartcards can also be used to store the PSE file after it has been generated in the software.�
Once the attributes have been stored, it is possible to generate certificates and key pairs for the new object.� The Personal Secure Environment�(PSE) file holds the entity's certificate and key information. The PSE file can be stored on disk or on a PKCS#11 smartcard/token. When the key pair is generated in software, the PSE file contains both the private key and the certificate. UniCERT allows a hierarchical system of CA's on different machines, with the certificate of each CA down the hierarchy being generated by its parent CA. Sub-CA and Sub-RA components are used to create the hierarchy in the PKI Editor by dragging new CA or RA components and connecting them to the parent CA/RA as required.� Peer-to-peer cross certification is accomplished by creating a Cross Certification object on the PKI diagram and connecting it to the local CA. A menu option then appears allowing the CAO to initiate cross certification, at which point the necessary request can be generated in PKCS#10, PKIX or certificate format. The request file is transmitted to the remote CAO out of band and a reply is returned, at which point it can be imported to complete the cross certification process In UniCERT v3.0.5 – as well as support for standard CRL’s and OCSP – it is possible to define CRL Distribution Points (CDP’s) in the CAO. Distribution Points allow CRL’s to be broken down into sub CRL’s and have the CA publish them (or make them available to a third-party application that publishes them) to various locations depending on the policy being used for the issued certificates.� When the CDP extension is used, the CA can place a CRL in a location where it can be retrieved via an e-mail address, a URL, or by other means. For those who require key backup and recovery, Archive Server is an optional UniCERT component (new for V3.0.5)which allows storage of end users' private encryption keys securely in encrypted form, and retrieval as needed. The Archive Server is connected to the CA in the PKI, and RAO’s pass the keys to be archived to the Archive Server via the CA.� An Archive Security Officer (ASO) is required to perform key recovery functions. In the current version, only one ASO is supported. Recovered keys can be saved in a range of formats (PKCS#12, PKCS#1, etc.) and all key recovery operations are securely logged. Once the PKI has been defined and all the necessary certificates and key pairs generated, it is time to define policy. A policy is a set of criteria that must be fulfilled before a CA will generate a certificate for a user or entity.� Specific types of end users or entities may need their own policy defining their access rights and certification requirements. For example, Cisco routers can send remote certificate requests via the UniCERT Gateway using the CEP support feature; the security policy for a Cisco router requires that it be allowed to send only its Dname since the router groups all the information it sends to the UniCERT Gateway as its Dname. Similarly, a separate policy may be required for all end users requesting certificates via an IPSec Virtual Private Network (VPN). The Policy Editor (another menu option in the CAO utility) allows the CAO to define extensions and additional fields that will appear on the certificate.� Once again, this is accomplished by dragging and dropping items from the tool bars onto the on-screen “certificate”, which starts life with the bare essential attributes required to specify its distinguished name.� Other attributes and extensions can be added quickly and easily and their properties defined. These include such items as key length, algorithm, key usage, policy ID, basic constraints, an instruction to automatically archive the secret key, generic extensions, and so on. Many of these items have multiple permissible values, and these can either be locked down by the CAO as part of the policy, or left as selectable lists for the RAO to determine at registration time. The Registration Components toolbar contains the basic components that can be used for end user identification, including a radio button, check box, edit box (for a generic text entry), list box, descriptive text and scan (which allows the RAO to scan an official document or photograph of the subscriber to be stored in the database). These registration components are used purely to add the criteria required for registration and are stored in the database only - they do not become part of the certificate itself.� This ability to construct an extensive registration utility out of the box to collect data that is stored in the Oracle database but not in the certificate is unique to UniCERT. The Policy Editor for remote requests�contains the same options and works in exactly the same manner as that for face-to-face requests. It is also possible to copy existing policies and then amend the copies, making it easy to generate a number of different policies that differ slightly. Once the policies have been defined, they are “pushed” down to the appropriate RAO’s. Using the PKI Editor utility again, the administrator simply selects an RAO and selects from a list of available policies.� Those that are already available to the RAO are ticked. Additional ones can be selected and pushed immediately, and it is also possible to remove policies that were previously allowed.� The changes happen immediately, making it easy for a CAO to control enterprise-wide policy from a single, central location. An option also exists to refresh all policies, which pushes all recent changes to existing policies down to the appropriate RA’s in a single operation.� The last option on the CAO main screen, Administer Certificates, allows the administrator to manage all the certificate processing as required. This includes revoking certificates, suspending or unsuspending certificates (a “temporary revocation), viewing certificate details and event log entries, and verifying events in the event log. We found that UniCERT provided the easiest means of all the products tested to create custom registration policies and certificates. The Registration Authority (RA) acts as a router in that it routes face-to-face requests from the RA Operator to the CA, and Web, mail and VPN requests from the UniCERT Gateway to the CA. In the opposite direction, it sends replies to the Gateway, which in turn sends them to the end users (remote requests only). It also keeps track of all events in its database, which the RA Operator(s) can access as needed. The actual RA process is something of a “black box” that simply needs to be started each time the RA machine boots.� The UniCERT RA Operator, on the other hand, is the interface through which requests for certification are received and processed. These requests may be received via e-mail, WWW (remote Web or VPN requests) or in person (face-to-face requests).� The RA Operator (RAO) must process these requests and perform whatever steps are deemed necessary to ensure that the information and credentials provided by the requester are valid as defined in the Certificate Practice Statement (CPS). Once that validity has been satisfactorily established, the request can be accepted and is duly recorded in the RA database before being passed to the CA for signing. If the credentials supplied are not satisfactory, the RAO can reject the request, and no further processing is performed. When the RAO user first accesses the RAO he will be required to seed the random number generator and open the appropriate PSE file. He is then presented with a list of available security policies, one of which is selected – this determines the information to be collected and the type (and content) of certificate to be issued.� Once this has been done, all the certificate processing carried out by the RAO user is accessed via four options on the RAO main menu: Process Remote Requests - �Used to manage certificate requests sent via the Web, from VPN devices, or by e-mail to the UniCERT Gateway.� Face-to-face Requests - Enables the RAO to enter the certificate request details directly and collect approved certificates for the end users.� Multi-Authorisation Requests – Allows the RAO user to process those requests which require more than one user to approve or reject them.� Browse Records - Allows the RAO user to view both operational events and lists of certified users. When processing face-to-face requests, the RAO user fills in the appropriate fields as specified by the policy selected and generates a key pair (either in software or using a PKCS#11 token or smart card). If either a PKCS#11 Token or PKCS#11 Smartcard was used, then the key pair is generated on the device. If no hardware token was used, then the key pair is stored in a password protected PKCS#12 file on disk. Alternatively, the end user may elect to use a key pair that was generated remotely as the basis of their certificate request, in which case the key pair can be loaded from the appropriate source. Whichever method is used to acquire the key pair, the public key is passed to the CA for signing at this point.�
When using the PKCS#12 file option, the RAO can generate a temporary self-signed certificate that can be used to establish an initial trust with other users until the real certificate is received. Once the certificate has been issued by the CA, it can overwrite the one stored in the PKCS#12 file. Having been processed by the RA, the RAO user retrieves the certificate and installs it into the key store (PKCS#12 file or PKCS#11 device) that was used during the initial key generation process, overwriting the self-signed certificate that was placed there originally. The registration process is then complete. Remote certificate requests are automatically routed to the RAO and can be retrieved from a list of pending requests and processed according to the available remote policies. Any additional validation can be performed at this point before the request is passed on the to RA and CA. Certificates issued for remote requests received by e-mail or Web are automatically routed back to the requester (rather than the RAO) via the UniCERT Gateway.� Once certificates are issued, the RAO user can perform additional tasks as needed. These include browsing the event and certified users logs and revoking, suspending and unsuspending certificates. The CA and RA do not have to be running in order for face-to-face or remote requests to be processed. If a request is handled when the RA is down, it is stored in the Oracle database until the RA is started, at which point the RA will retrieve the request automatically and continue the certification process. One of the configuration options available when the RA is created is “The RA automatically accepts all certification requests”, which allows total automation of the certification process for remote requests. Instead of putting the requests in the database and marking them for the RA Operator to approve, the RA sends all remote requests directly onto the CA, and no policy is associated with the certificate requests. This option is set by the RAO who controls the RA application. Having the RA accept all requests means it will be necessary to have an application external to UniCERT that can check the criteria for certificate requests and forward the requests to the UniCERT Gateway, which then passes them to the RA. Baltimore's PKI-Plus Developer Toolkit can be used to write such applications. Baltimore have just released an additional component, the Advanced Registration Module (ARM), which allows remote requests to be processed through strict policies. This module can be programmed to communicate with back end databases to validate the certificate request and provides total flexibility when customising registration policies. Where an organisation cannot support registration officers on the corporate network for some reason, Baltimore also offers WebRAO, a web-based system for Registration Authority Operators. UniCERT WebRAO lets operators use a standard web browser (Internet Explorer) to send certificate requests securely across the Internet for processing by UniCERT.� WebRAO provides a range of certificate request functions via a Java-based PKI Certificate Wizard applet, including:
UniCERT WebRAO is able to process face-to-face certification requests as well as remote requests from web browsers and secure mail programs. Certificate events can be filtered and viewed from the main CAO utility. Events can be filtered on: Severity: A drop-down list contains three options: All, Error and Informational. Informationalentries in the log deal with the everyday running of the CAO, generating requests and receiving replies and policy updates. Error�messages generally deal with operational errors. Text string: The filter will search through the log and display entries that contain the specified text. Date range: By entering start and end dates in the fields provided, a time limit can be specified for the search of events that occurred. If the default values are selected in the search dialogue, then all events are displayed, and the results can be sorted in chronological or reverse chronological order. It is also possible to validate the digital signature (as applied by the CA) on any event in the log.� Since UniCERT has been designed as an open CA product it does not include a specific client element, instead relying on the standard Web browser model, or third party PKI-enabled applications that can take advantage of UniCERT functionality. A number of tool kits are provided for this purpose. PKI-Plus is the primary tool kit for developing PKI-enabled applications, and is available as C++ or Java classes (J/PKI-Plus). PKI-Plus provides a high-level API offering full encryption and digital signature capabilities to the developer. The built-in policy-enforcement system allows an organisation to dictate security policy at application and desktop level. Being completely standards-based, PKI-Plus applications will work with any standards-based CA, not just UniCERT. Additional tool kits are available to address XML and WAP (wireless) applications. With the general lack of PKI-aware applications at present, however, most end users will acquire certificates via their browser, and there is a useful set of default Web pages provided with UniCERT to allow Web-based registration out of the box. These require minimal customisation to make them useful in most environments. The default registration home page allows the user to download and install the Root CA certificate, to request browser certificates for Netscape or Microsoft browsers, to request a PKCS#10 VPN certificate, or to revoke a certificate. Revocation is accomplished by entering the user name and e-mail address, pass phrase and certificate serial number, following which the appropriate certificate is retrieved for confirmation and the revocation request can be submitted. Of course, first the user must request a certificate, and this is achieved by completing a registration form, generating a key pair and submitting the public key (along with the registration information) to be signed by the CA.� It travels via the Gateway to the RA where it can be auto-approved or held for manual checking and approval by the RAO.� Once the request has been approved, the user receives an e-mail from the CA containing a URL. The user has only to access the URL in order to install the certificate in his or her browser.
There is no option on the default Web page to allow the end user to manually request certificate renewal. However, when the registration policy is defined it is possible to specify an attribute that forces automatic certificate rollover at specific intervals. In order that users are not solely reliant on the Web browser model or third party software vendors, Baltimore has also produced a range of PKI-aware applications that take advantage of UniCERT functionality, as well as being interoperable with other standards-based CA’s: MailSecure – A plug-in application that adds full-strength security to the most popular desktop mail clients, including Notes, Outlook, Exchange and Eudora. Enhanced functionality of the mail client includes the ability to sign and encrypt messages and attachments, as well as validate digital signatures with fully-automatic on-line CRL checking. During testing we combined MailSecure with the Valicert responder and Content Technologies’ SecretSweeper. This combination provided a very powerful security environment where all mail was checked for viruses and signed on the way in and out of the organisation, and digital signatures were validated fully, with completely automatic CRL checking via Valicert. MailSecure Enterprise – Rather than operate at individual client level, MailSecure Enterprise works in conjunction with an existing mail server to provide centralised e-mail security for the organisation. MailSecure Enterprise automatically secures or de-secures email messages - using MIME and S/MIME standards - as they move to and from the mail server and the Internet.� FileSecure - FileSecure takes all incoming objects - which may be presented as files or e-mail - secures them, and then presents them either to be sent out, collected or stored.� Using industry-standard S/MIME and full-strength cryptography, FileSecure can sign and optionally encrypt objects, check signatures and decrypt, or just pass objects through untouched. FileSecure can handle multiple attachments in incoming and outgoing e-mail.� FormSecure - FormSecure is a security system that allows organisations to build public key cryptographic security into any of their Web forms without any programming. This is ideal for protecting sensitive information, such as PIN numbers or passwords, entered into browser-based forms. WebSecure - WebSecure is designed to enhance almost any web server-to-browser communication to provide full 128-bit encryption. Click here to view checklist.� Details of base products: UniCERT is the Certificate Authority software, and consists of a number of modules such as CA, RA, CAO, RAO, Gateways and Token Manager. Details of options: Optional UniCERT modules are available, including WebRAO, Key Archive Server, Attribute Certificate Server, Advanced Registration Module. Toolkits such as PKI-Plus, SMT, J/CRYPTO, X/Secure, W/Secure, etc. MailSecure (S/MIME-compliant plug-in application for Outlook/ Exchange, Notes and Eudora), MailSecure-Enterprise, FormSecure, FileSecure How the products are licensed: 1.����� Purchase the technology modules to create the infrastructure 2.����� Purchase a license to use the infrastructure - either Enterprise User or Commercial Service Provider; license fees vary by infrastructure size and application Cost of base products: CA��������� $25,000 RA��������� $5,000 CAO������� $3,000 RAO������� $1,500 Cost of options: Web gateway����������������������� $3,000 E-mail gateway��������������������� $3,000 VPN gateway���������������������� $10,000 DAP Drivers������������������������� $3,000 WebRAO�������������������������������� $500 WebRAO Server������������������� $4,000 Key Archive Server������������� $22,000 Attribute Certificate Server��� $18,000 Advanced Registration Mod.� $20,000 License costs per user (assuming two certificates per user) for the following quantities of users: 100�������� free (incl. in cost of CA module) 1000���������������������������������� $20,000 10,000������������������������������� $90,000 100,000���������������������������� $400,000 1,000,000������������������������� $500,000 This price structure assumes Enterprise use (for employee, supplier, customer or associated party use where certificates are not sold or otherwise charged for). Commercial Service Providers (where certificates will be sold on or charged for) pay a license fee of US$ 250,000 plus an agreed percentage or royalty figure on the certificate charge price. Annual support and maintenance is charged at 18 per cent of the sale value. Sample total costs per user (assuming all base modules, Web/E-mail/VPN gateways, Key Archive Server, and two certificates per user) for the following quantities of users: 100 - $72,500������������������������ 1000 - $92,500 10,000 - $162,500 100,000 - $472,500 1,000,000 - $572,500� Please note that the price of the Oracle server/client license(s) (from $3000 for Oracle Server) and an LDAP directory server (optional – from $2000 for Netscape Directory Server) must also be added to these costs if not already deployed within your organisation. Note that the above pricing is per user (unlimited certificates) for Enterprise customers, reverting to a per-certificate pricing model only for commercial organisations that intend to charge for certificates. This makes UniCERT one of the most cost-effective products we have tested.� The simplicity of configuration of UniCERT hides the tremendous complexity and power hidden beneath the hood. A powerful database-driven policy engine, coupled with the excellent PKI Editor, makes UniCERT the most flexible CA solution out of the box of all those we have tested, yet it lacks none of the features we expect to see in a high-end PKI solution. Other products allow similar functionality to be achieved via extensive Java coding or the use of tool kits, but UniCERT provides a vastly superior “out of the box” experience, as well as offering the necessary tool kits for those who want to take things even further via custom development. If we had any criticism of the current release, it would be that automatic key update is not available at the CA, though this is planned for the next release. Apart from that, UniCERT offers everything you need. More than any other product, UniCERT encourages a mix-and-match philosophy, sticking firmly to standards in an attempt to remain as interoperable as possible. This does mean that it may be necessary to purchase the Oracle RDBMS and a directory server (which is optional) if not already available within the organisation, though Baltimore does resell these items if required. Overall, we found UniCERT to be hard to beat in terms of value for money, features, flexibility and ease of use.
Company name: Baltimore Technologies IFSC
House The Square 1050 Winter Street 5th Floor Click here to return to the PKI Index Section
|
 |
Send mail to [email protected] with
|
