 |
|
|
nCipher provides a range of hardware-based security products designed to provide both performance acceleration for secure operations - such as SSL connections and digital signature verification - and secure storage and management of critical keys. The latest versions also provide a secure code execution capability within the hardware module itself. The product range includes:
Via load balancing, all nCipher products scale linearly. When multiple hardware modules are installed on a single server, for example, it is possible to handle up to 2000 RSA signatures per second. As part of this test, we looked at both the nShield F2 (PCI, max 150tps) and the nShield F3 UltraSign (SCSI, max 400tps). Since the nature of the products are the same, and there is no difference in installation or operation between the two, the remainder of this report will concentrate on the nShield F3. The nShield F3 is provided as a self-contained SCSI device, which can be mounted internally to the host server or attached externally when mounted in its own cabinet. Two external enclosures are available: a desktop enclosure, which is capable of supporting one nShield HSM and a rack mount enclosure which can support two HSMs, and features dual power supplies for maximum resilience.
The nShield itself sports only a status LED, a clear button and smart card slot on the front panel, and when provided as an external module the rear panel houses two SCSI connectors, ID selector, initialisation button and power switch. In order to be validated to FIPS 140-2 Level 3, nShield has to demonstrate a high degree of tamper protection. Holographic seals on the product's external casing allow administrators to detect if any attempt has been made to physically tamper with the device, and the internal circuitry is encased in a special epoxy-based security potting to guard against a physical attack on the electronic components. If any attempt is made to break through the potting, the contents of the device are destroyed. With nShield, it is possible to create, store, back up, restore and remove application keys in secure hardware and impose strict controls over the management of these keys using two-factor authentication based on smart cards and pass phrases. The use of a device such as nShield ensures that private cryptographic keys are stored in dedicated hardware while in use and encrypted with triple-DES when idle. Private keys never leave the module unencrypted and are therefore never exposed to the outside world. Installation is pretty straightforward, especially if there is already a SCSI adapter installed in the host PC. All that is required is to connect the SCSI and power cables and switch on, following which the support software can be installed. The PCI version is installed in any spare PCI slot - no additional adapters or cabling is necessary (except to connect the external smart card reader via the cable supplied). The security architecture underlying nCipher�s Hardware Security Modules is known as Security World, whilst the management interface used to configure and control it is known as KeySafe. All nCipher key management software uses the nCipher Security World paradigm to provide a secure environment with both application independence and platform independence for all module and key management operations. The Security World provides a framework that permits any number of nCipher's hardware security modules, smart card sets and keys to be brought together and managed as part of a single system. Security World provides the basis for implementing a security policy. This allows an organisation to define a set of rules and internal controls that specify how responsibility and authority is shared and delegated across a potentially large team of security administrators and system operators, often in different locations. A Security World consists of:
These elements are linked by the Security World Key, which is unique to each World. Distributing the encrypted keys over different storage media means that a Security World can recover from the loss of any one element. It also increases the difficulties faced by an attacker, who needs to obtain all of the elements before gaining any information. The nCipher Security World framework enables administrators to manage an unlimited numbers of keys across multiple HSMs that may be distributed on multiple servers if different geographical locations. In order to achieve this flexibility without compromising security, all keys under the protection of a Security World are �wrapped� - triple-DES encrypted using the Security World Key - for storage outside the HSM itself. The resulting encrypted data is known as a key blob. This might sound contrary to the idea behind an HSM - that private keys remain in the HSM at all times - but nCipher has simply extended this idea to ensure that keys should not appear in the clear outside of the HSM. Keys that only ever reside inside an HSM offer a potential single point of failure - steal or cripple the HSM and the key (which is used to protect other data or to prove identity) is lost forever. Therefore, to ensure cryptographic key availability without compromising key security, nCipher�s Security World simply uses the well established principles of cryptography to ensure that private keys do not appear in plain text outside of the HSM. Once they are encrypted and wrapped they can be safely stored under the control of the Security World to which they belong. In addition to the key being encrypted using the Security World key (which resides in the module), each key blob can be encrypted a second time using a second encryption key that is split into a number of components (known as logical tokens). Each of these tokens is then stored on a separate, pass-phrase protected, smart card known as an Operator Card.
In order to load a key ready for use inside the HSM it is necessary to:
Finally each key blob has its own Access Control List (ACL). The ACL specifies a list of operations which can be performed using the key as well as in which situations those operations may be performed The Security World uses smart cards for two different purposes. One set of cards, called the Administrator Card Set, is used to control access to recovery functions. All Security World data is stored on the host in encrypted format, along with recovery data for the Security World Key. The latter is protected by the keys on the Administrator Card Set, thus allowing backup and recovery operations to be carried out by holders of those cards (usually such operations will require multiple cards to be present from the set). The Administrator Card Set can also be used (along with the encrypted Security World data) to replace existing, or add new, modules in a Security World. The remaining cards are divided into sets, called Operator Card Sets, that are used to control access to application keys. The smart cards used as Operator Cards employ the Security World Key to perform a challenge response protocol with the module. This means that Operator Cards can only be used by a module belonging to the same Security World. One excellent new feature in the latest release is the concept of the �remote operator�. nShield devices in remote locations can be configured to be part of a local Security World, communicating over secure channels across a public or private network. When it is necessary to insert multiple smart cards, a holder of an appropriate card at a remote location can insert his card in an nShield device there, and it can be recognised in the local Security World and used to authenticate a �k of n� operation. This combination of features ensures that valuable cryptographic keys are always available to perform their various functions without compromising key security or imposing a restrictive security model on the organisation using HSMs in their applications. Cards, keys, and even modules can be added or removed at any time, providing a very scalable and flexible solution. Administrators can simply install the number of modules required to meet current needs, and then add more as requirements grow. Each legitimate user can authorise the HSM to perform key operations (such as signing or encryption) on keys protected by the Security World and the keys protected by their Operator Card Set. They cannot access keys protected by other Operator Card Sets. By keeping private keys in secure hardware while in use and encrypting them with triple-DES when idle, the nShield protects keys against compromise from unwanted �key finding� attacks. For added security, those same keys can be protected by multiple (pass phrase enabled) smart cards thus supporting �split responsibility� for key activation. This technique (known as �k of n� secret sharing) can be integrated with an organisation�s existing security policy. For example, responsibility for approving private key use can be spread across three people, requiring any two to insert their smart cards to activate the key. The Security World has been designed to ensure that keys remain secure throughout their life cycle. Because the Security World uses multiple interlocking keys, each key is always protected by another key, even during recovery operations. The Security World architecture also provides fault tolerance in a multiple-HSM implementation. If a device becomes unavailable while in service for any reason, built-in �fail over� capability simply passes all of the processing activities to the next nCipher module. If a Security World has only one module, it is a simple matter to move the World to a different module (under control of the master Administrator Card Set) following hardware failure, or if it is required to upgrade to a newer HSM. This logical separation of the security data from the underlying hardware makes the Security World paradigm incredibly flexible and resilient. The Security World itself has no knowledge of how the keys under its control will ultimately be used. The Security World only controls the protection for a specific key, and it is the external application that determines how the key will be used. Each key can only belong to one application (and will only ever be used by that application), but any number of keys can be created in a Security World for any number of applications. Control of the Security World and all its components including the nShield and its key management options is available via a number of command line utilities or a simple, Java-based graphical user interface known as KeySafe. Whilst HSMs provide for the security of keys, they do not completely address the issue of how keys are created, used, managed, stored and destroyed. This process of controlling key lifecycles - known as key management - requires a layer of software that interfaces between the HSM and the �real world�.
The process of mediation between the physical environment of the HSM, the logical environment of the computer system whose keys the HSM protects, and the end-user organisation itself, requires careful design. This is the need filled by the Security World technology, and its management software, KeySafe. The interface has improved considerably from the last time we had this product in our labs, being much cleaner in appearance and with a handy hierarchical display of the Security World in the left hand pane below the main menu buttons. Key, card, and module operations all take place in the right hand pane. KeySafe allows companies to create, store, import, back-up, restore or remove application keys securely through an easy-to-use graphical interface, delivering complete life-cycle key management. KeySafe controls the Security World framework for managing multiple dispersed devices and allows responsibility to be delegated and shared between teams of administrators. This flexibility helps organisations develop security policies that can be easily policed and successfully sustained. With KeySafe the administrator can create, store, import, back up, restore or remove application keys in hardware and, for added security, protect them using sets of smart cards. At present, KeySafe supports the following applications and key types:
KeySafe uses the Security World facilities to allow application keys to be protected by the �master� Security World Key or additionally by Operator Card Sets, and the choice comes down to the level of protection that is required, balanced against availability. By protecting an application key with the Security World Key, it ensures that the application will be available to all users in a particular Security World at all times. No pass phrase is required to use the application key, and this ensures that the application remains available even following a power cycle or reset of the host computer. When protecting an application using an Operator Card Set, it restricts access to the application key to a specific user or group of users (when �k of n� secret sharing is employed). The appropriate number of cards must thus be present when the key is first accessed, and the correct pass phrase must be entered (if one has been set). Once again, the remote user capability can be employed if cards are distributed across multiple physical locations. Whilst offering a higher level of protection, this mode of operation is less suitable for high availability applications such as Web servers, where the application must be constantly available, even following a power cycle. Normally, keys protected by a card set require that the card (or the last card loaded in the case of multiple card sets) is present in the nShield module. As a security measure, as soon as the card is removed, the keys are automatically removed from the module. This can be inconvenient on occasion (only keys protected by one operator card set can be loaded in a single module at any one time, for example). Therefore card sets can be designated as �persistent�, meaning that the keys remain active in the module even after the smart card has been removed.
Keys protected by a persistent card are automatically removed from the module either when the application that loaded the Operator Card Set closes the connection to the module, or after a specified time limit or if the user clears the module. An application can also choose to remove these keys. All of these capabilities are accessible through KeySafe�s intuitive Java-based graphical interface, which - whilst not adhering to the �standard� Windows conventions - is still very easy to get to grips with. The opening screen provides a triple-pane view, with five menu buttons in the top left hand pane: Introduction, Keys, Cards, Modules and Exit. Below this is another pane containing a hierarchical view of the Security World itself. The right hand pane is used to actually configure and manage various elements of that Security World. If KeySafe is started with one or more modules in a pre-initialisation or initialisation state (set using the rear-panel button on the external module), KeySafe automatically selects the Modules option, from where the Security World can be initialised, and modules added to or removed from it. If no modules are in this state, the options in this menu are disabled.
Using the remaining menu options in KeySafe, the administrator can:
Recovery data is protected by the cryptographic keys on the Administrator Card Set, whereas working data is protected by the cryptographic keys on the Operator Card Sets and/or on the module. For example, working keys on Operator Card Sets are duplicated and protected by recovery keys. Failed or mislaid operator cards can thus be replaced - and the original working keys recovered - using the Administrator Card Set in conjunction with KeySafe. Most KeySafe operations are covered by �wizards� which walk the administrator through the options page by page. For example, when generating keys, the administrator is first prompted for the application, and then for the key parameters such as key type (AES, RSA, DSA, DH, DES, Triple-DES, CAST, SHA-1, El Gamal, MD2, MD5, HMAC, RIPEMD-160), key size, how the key is to be protected (smart card or module), whether or not to allow key recovery, and the key name. Finally, the administrator is prompted to insert the Operator Card Set that will be used to protect this key. Application keys can also be imported from an outside source, if required. Although it is not difficult to perform most of these operations from the command line (a range of command line tools is available for those who prefer the non-graphical approach to management), KeySafe certainly makes managing Security Worlds, keys and card sets that much more straightforward. In addition, the nCipher Software Developer Kit (SDK) provides e-commerce application developers with the means for their applications to make use of nCipher Hardware Security Modules. These capabilities are provided through industry standard application programming interfaces (APIs), including:
The nCipher nShield Hardware Security Module has a number of possible applications in its current incarnation. Secure Web servers can quickly become bogged down with encryption tasks when they have to support hundreds of SSL (Secure Socket Layer) connections per second. As an example, there follows a list of the operations performed whenever a user attempts to connect to a secure Web server using SSL:
Cryptographic tasks such as encryption and decryption of the session keys can be offloaded to the nCipher HSM, thus relieving the host server of processor-intensive activities and thus improving performance and scalability. Web Services are enterprise applications that use languages and protocols based on a universally accepted standard called XML to describe themselves, not only to other applications but also to the outside world. Because Web Services provide far reaching integration and access (often to a company�s most sensitive data), IT vulnerabilities become a major concern. The confidentiality of private keys used to implement signing and encryption underpins the security of cryptographic processes in XML. Cryptography relies upon the relevant key being available only to appropriate and authorised parties and processes. Therefore, the security and management of encryption and signing keys themselves is critical to the security of any business deploying Web Services. nCipher�s nShield module provides the key security required to ensure the integrity of the XML messages as well as the performance requirements to cope with the typically large numbers of messages sent from machine to machine in an XML deployment. The security foundations of the digital certificates used by SSL are the private keys used to establish identity and protect SSL sessions. It is critical that SSL private keys are kept absolutely secret to ensure the privacy of online transactions. In effect, a Web server's identity cannot be trusted unless it�s private SSL key is kept secret. Many organisations make the mistake of leaving their SSL keys exposed on the host server, relying purely on the security of the operating system to protect them. This approach is vulnerable to key finding attacks from attackers - both external and internal. The nShield HSM integrates with most commercial Web servers via standard APIs such as PKCS#11, OpenSSL and MSCAPI. nCipher�s Security World architecture can then be used to protect access to and use of the private key associated with the Web server certificate. In addition the HSM can provide SSL acceleration which radically improves the Web server�s SSL transaction performance. Secure Sockets Layer (SSL), the protocol that secures the world of e-commerce, is now emerging as a leading contender in the VPN space. SSL includes client and server authentication and data encryption for Web based applications - it can thus more easily provide the fine grained access control that remote access and extranet VPNs require. SSL VPNs also deliver user-level authentication, ensuring that the right people have access only to the right resources. Since SSL is included in the standard Web browser, SSL VPNs also offer the possibility of a �zero footprint� solution, with no software required at the client-side other than the Web browser itself. The HSM provides the performance capabilities required when deploying SSL VPNs, as well as the capacity for cryptographic key storage and management. Without Hardware Security Modules like nShield, the root keys of Certification Authorities must be kept on the CA machine itself. Even with the best protection in the world, there is always the chance that the private keys could be compromised. At the end of the day, the trust that can be placed on a digital certificate depends on the secrecy of the private key, and the trust that can be placed on the reliability of a validation response depends on the secrecy of the private signing key. The HSM is an essential part of any serious PKI solution, and can provide both crypto acceleration and secure key management. The Security World paradigm provides full role-based access control of keys, with multi party authentication (�K of N�). This provides high security private key protection that increases confidence in the legitimacy of digital signatures and certificates The nShield also brings scalability and fault tolerance to the PKI, providing the capability to manage thousands of keys, automatic fail over with multiple HSMs, key sharing between multiple HSMs, and key sharing between geographic locations. Accelerated digital signing and OCSP validation removes bottlenecks in high-throughput transaction and validation servers Increasingly businesses and organisations are required to comply with data access control, privacy and security requirements. These include several privacy regulations and industry guidelines that mandate controlling access to sensitive data, including:
Through the fine grained access control and key usage controls associated with each Key�s Access Control List and overall security properties of the nCipher Security World, the nShield HSM brings the capability of protecting data at rest (such as data in corporate databases) down to an individual field level if required. In addition, the acceleration properties of the nShield can enhance the speed of accessing encrypted data in performance critical database applications. This can permit highly sensitive information to be served from untrusted environments since the data in the database is encrypted using keys held safely inside the trusted FIPS 140-2 Level 3 validated HSM. Within secure automated applications (such as stock trading systems) it is often necessary to delegate the right to use a cryptographic key to an application, with no human intervention to check that all is going well. When private keys are used without the explicit intervention of a user, there is no way for the securing HSM to know or validate the source of an instruction. While the HSM provides secure storage for keys, which can lock and unlock data, or certify or verify information, there is no way in most security architectures for the HSM to know with which program it is communicating. More importantly, there is no way for the HSM to know what that program is and is not allowed to do. How can the HSM know that the application requesting the use of a signature, key or authorisation has permission to do so? The program which runs on the host server may have been compromised or replaced in a manner which the HSM cannot detect. Although the HSM is well able to protect the private keys stored within it, security gaps may be created elsewhere in the infrastructure. Ideally, therefore, the instructions to the HSM - as well as the channel over which those instructions pass - should come from a source that is as trustworthy as the HSM itself. This gap between the application running on the host and the HSM is a classic security gap, which could be exploited to attack the system as a whole. nCipher�s Secure Execution Engine (SEE) can be used to protect application software since it is executed within the security boundary of the nShield HSM, and can prevent unauthorised programs from gaining access to a computer or its secure resources.
As a further example, consider a large-scale PKI, with several Registration Authorities at branch offices communicating with one Certification Authority at the head office. It is impossible for the security officer to oversee all the transactions in this large-scale system, therefore the CA application code interfaces to the HSM to generate keys and issue certificates without operator intervention. RA servers in the branch offices check the credentials of users and then issue requests for a new certificate to the head office's CA server. The head office server issues a new certificate when it receives a signed certificate request from the Registration Authority servers in the branch offices. The CA is an unattended process running on a server, to which an HSM is attached, the HSM holding the CA's signing key. The CA application will examine the signed request, and compare it to the security policy management document. If the request received by the Certification Authority carries a valid signature and is acceptable, according to the policy document, a certificate will be issued. However, if the policy checking is subverted, or the policy document is corrupted, bogus certificates could be issued. In this case, although the root key is intact in the HSM and there is no evidence of an attack on the HSM itself, the PKI has still been compromised by �tricking� the HSM into using its protected keys in a manner which is not consistent with the organisation�s security policy. By placing the policy checking within the HSM as an SEE application, this type of attack can be avoided. SEE technology is delivered as part of the CodeSafe Developer Kit, which includes the tools required for developers to �SEE-enable� their applications. SEE technology is built on top of the nCipher secure environment, protected by the nCipher Security World key management environment, a combination of the nShield HSM and the KeySafe key management software. SEE extends the concept of access control within the Security World to include application code which is loaded into the module, using a process of delegating rights held in access control lists. The process of loading the program itself is not controlled - instead, any piece of code is limited to actions which are allowed by its signing key (i.e. those actions permitted by the access control lists which contain that signing key as an authorised party). If the key which has signed the application does not have permission to do something (via an ACL) the application will not be able to do it either. Parties in an access control list are identified by their signature keys. If a signature key is used to sign the program code, any rights in any access control lists are delegated to the signed code. In this way, code signed by a key has the right to perform the actions listed in any access control list which contains that key. It is therefore possible to tailor the level or breadth of access granted to any program according to the needs, by using a key with the appropriate level or quantity of access. If the signing key has rights in several ACLs, SEE will permit application code signed by that key the same access to data. SEE itself sits between the program code and the key resources. Applications never have direct access to the key resources and cannot tamper with them or compromise them. By signing applications and delegating the authority held by the signing key to the application, it can operate as a trusted agent enabling it to operate securely without live supervision. SEE can control and secure any program which is required to operate within the security perimeter. This can be either a single nShield HSM or a networked nCipher Security World (where several HSMs are used together with the same key set and security officer to create a larger-scale installation). In addition to PKI policy enforcement, real-world SEE applications include digital rights management, secure content distribution, secure audit logging and closing protocol gaps between two systems where previously encrypted data is exposed in the clear at the server in order to fulfil an operation or request. Other examples are detailed below: Protocol Conversion A prime example of a protocol gap is the so-called WAP gap, where the end-to-end security that is taken for granted in SSL is broken at the wireless gateway to allow the wireless security protocol (WTLS) to be bridged to the SSL protocol. By placing this activity within SEE perimeter, this gap too can be closed with all plain text kept secure within the confines of the nShield HSM.
All decryption takes place inside the nShield HSM, ensuring data does not appear in the clear. Re-encryption also takes place inside the module, delivering end-to-end encryption and protecting data from compromise Proprietary Algorithms & Secrets The nShield HSM contains a large number of commonly used cryptographic algorithms by default. However, the SEE environment provides the user with the ability to code his own cryptographic algorithms to be used inside the HSM. For example, the nCipher payShield HSM was developed using SEE technology in order to deliver the specific algorithms and key types required for VISA�s �Verified by Visa� and MasterCard�s SecureCode online payments programmes. CodeSafe SSL The deployment of hardware security modules to protect private cryptographic keys is an established a best practice. However while hardware protection of SSL keys prevents an attacker from eavesdropping on secure sessions or spoofing the Web server, SSL termination can still expose sensitive data as clear text on the server after the SSL decryption has taken place. All too often this decryption occurs on an unprotected server or network appliance outside the secure zone, either in the network or DMZ, vulnerable not only to internal threat but also to external attack. Using the CodeSafe SSL toolkit, data presented via an SSL connection can be decrypted and subsequently re-encrypted within the secure boundary of the HSM, preventing snooping of sensitive information on the server. In addition the CodeSafe SSL toolkit allows the development of custom logic to process a PIN or password inside the boundary of the HSM. Such functions might include validation using PVV, or comparison against entries in an encrypted password database. Using CodeSafe SSL sensitive information is only decrypted inside the HSM. Time Stamping and Audit Logging The reliance on time-sensitive operations, such as the submission of important documents, the execution of a critical command, or the time of online share deals, typically requires an evidentiary trail associated with how and when the event took place. Secure time stamping technology provides a highly accurate and tamper-resistant source of time that can be applied in such a way as to establish provability on any electronic entity - including digital signatures, document files, transactions on stock purchases, document filings or invoice payments. Playing a pivotal role in the e-security infrastructure for a wide range of security sensitive applications, time stamps have become an obvious target for cyber-criminals attempting to fraudulently manipulate business operations. It is thus essential that time stamps used in critical applications are accurate, secure and auditable. Secure time stamps apply three attributes to documents, transactions, or any other digital entities, providing important advantages over traditional computer clock based time stamps:
The nShield HSM has on board a secure real time clock for secure time stamping applications. Combining this with the FIPS 140-2 Level 3 validated security that the nShield offers to an audit log signing key provides full evidentiary and time stamping security. It is hard to see how there can be any justification for not considering the use of a Hardware Security Module (HSM) when implementing a PKI and other cryptographic systems such as SSL VPN�s, Database Encryption and XML security. Whilst the performance and scalability enhancements of the cryptographic acceleration capabilities can be ignored in low-volume implementations, the security enhancements cannot. Any PKI lives and dies by the security of its Certification Authority Root Signing Key. If the Root Key is compromised in any way, then none of the certificates issued by the CA can be trusted. Nor it is prudent to add the HSM later in the life of the CA, since without an audited root key generation ceremony that can demonstrate the absolute security of the root key, the integrity of the CA can be subsequently called into question. The HSM is thus one piece of equipment - like the CA computer and the PKI software itself - that must be factored into the equation of any PKI from the outset. The nCipher nShield provides the highest levels of physical security - validated to FIPS 140-2 Level 3 - and, with the KeySafe software, offers extremely flexible key management capabilities enabling smart card authenticated administration of customised security policies. The KeySafe user interface has been improved considerably since our last test, and new features such as Remote Operator makes the HSM even more flexible. The Security World paradigm provides for not only a simplified management interface, but also enhanced performance and fault tolerance through the ability to add extra modules as and when required. Whilst not the fastest device on the market - individual modules can support up to 400 signing operations per second - performance scales in a linear manner with the addition of each module, providing transparent load balancing and automatic fail over. Finally, the new Secure Execution Engine is an exciting technology platform that can extend the security perimeter to include security-sensitive code by moving it into the HSM itself, where it has direct access to the keys for which it has been authorised. There is also the opportunity to bring user-specific data into the HSM too, allowing banks and on-line retailers for the first time to store user names, passwords and credit card details securely on a DMZ until they are ready to be processed by back-end servers inside the protection of the corporate firewall. This feature alone opens up a whole new area for the HSM, extending its usefulness outside the realms of hardware protection of cryptographic keys and acceleration of cryptographic functions to protecting security sensitive code, audit logging and implementing business logic. Whilst we consider such a device to be essential in any PKI implementation, it will quickly become equally essential in any on-line operation where secure execution of code and storage of customer data is required outside the protection of the retailer�s private network. Company name:
nCipher Corporation Ltd. nCipher Inc Click here to return to the PKI Index Section |
Security Testing |
Send mail to webmaster
with questions or
|