 |
|
|
With the growth in use of the Internet for business transactions, the need for confidentiality and positive identification of all parties involved is increasingly vital. The use of encryption and digital signatures are important tools in the ongoing struggle to maintain privacy and confidentiality over insecure transports such as the Internet. Confidentiality of data stored on the corporate network is also becoming increasingly important for many organisations. Public key cryptography is the perfect solution for ensuring the privacy of data employed in distributed systems of all kinds. This is especially true in the kinds of systems implemented as part of e-commerce solutions, where organisations are engaging in transactions with individuals who are hitherto unknown to them, and with whom they may never have any further contact. Public key systems allow us to communicate securely between individual and organisation using keys which can be freely distributed and published anywhere � much like your telephone number in a directory. This can be augmented still further by the use of digital certificates, which bind a public key to an individual or organisation and carry the signature of a trusted Certification Authority (CA), thus verifying its authenticity. At the heart of every Public Key Infrastructure (PKI) is the Certification Authority, and the foundation of the CA is the Root Signing Key. The security of the Root Signing key is paramount, since it is used to sign all certificates issued by the CA itself. Thus, should the integrity of the Root Key ever legitimately be called into question, the certificates and CRLs issued by that CA would be suspect. At that point, the credibility of the CA itself is called into question, and in a live commercial environment that could have dire consequences. One of the main functions of a PKI is to verify the identity of its users, ensuring that they are who they claim to be. The primary use of the CA�s own digital signature is thus to provide non-repudiable proof of users� identities by binding their identity to their public key and signing it using its own private Root Signing Key � thus creating a digital certificate for the user. The signed digital certificate is undeniable proof to third parties that trust a particular CA that the user is who he represents himself to be. That trust of the CA is, of course, of vital importance. Without that trust, the digital certificates issued by a CA are worthless. The critical point of any security solution based on PKI is thus the Root Signing Key that the CA uses to sign its digital certificates. If this key is compromised, an intruder could forge certificates and use them to falsely represent himself to other users in the PKI (or other users who trust that particular CA). Once such a breach becomes public knowledge, the credibility of the CA, and of the company which operates it, is destroyed � perhaps forever. The compromise of a CA Root Key is one of the worst security breaches that can befall a company, and thus every possible precaution should be taken to ensure its protection. Clearly the security of the CA machine itself is of vital importance. It should be protected by layers of physical security such as locked doors, electronic surveillance, biometric devices to control access to specific personnel, and so on. However, whilst the CA Root Key is stored in software on the CA host server (the default state when PKI software is installed), it is still potentially vulnerable to a number of attacks: The Copy Attack: Here the attacker, having gained access to the CA host server, can copy the CA Root Key onto any unsecured media, such as floppy disk, smart card, or portable hard drive. If the location of the Root Key is not immediately obvious, attackers could simply copy the entire PKI directory structure, which can then be examined at leisure for hidden secrets. Having obtained the encrypted Root Key, various brute force attacks can be launched against it in an attempt to compromise the key. Providing the data theft is not discovered, once the key has been compromised, the attacker is free to masquerade as a bona fide user. Modification Attacks: An attacker could introduce hidden � or Trojan � software onto the host server which could monitor and record critical cryptographic traffic within the host PC. Although the cryptographic keys are themselves stored as encrypted data under a secure key, in many systems they must be decrypted and transported as plain text into memory or registers that are used in the cryptographic process. Even if the keys are split, or �disguised� somehow, if registers are monitored for these values during the cryptographic calculations, it may be possible to reconstruct the keys. Another option would be for the Trojan software to modify the cryptographic algorithms themselves � perhaps forcing them to use the same key over and over again rather than change it for each session. Once the intruder can be assured that the system is using a single, never-changing key, it provides a larger window of opportunity to launch a brute force attack against that key. Equipment Theft: The most obvious attack of the three, possession of the server running the CA software will provide the attacker with the time to brute force attack the cryptographic secrets held on the hard drive. To be honest, there is little value in going on to extract the Root Key since it is highly likely that the theft will be noticed quickly and appropriate action taken. However, the damage has been done � once the Root Key is no longer in the possession of the organisation operating the CA, it calls the integrity of the entire PKI into question, and the only recourse is to invalidate all certificates issued by that CA and start again from scratch. Reputations will suffer as a result. For Certification Authorities, the concept of �trusted path� is a critical one. The Root Signing Key must be generated securely, a backup Key created and stored securely in a trusted crypto module at an alternative site for disaster recovery purposes, and finally the key must be securely entered into the CA�s signing engine. This provides complete preservation of the trust level of the CA key both inside and outside the cryptographic processing environment. A formal CA Root Key generation ceremony should be designed to help assure the non-refutability of the integrity of each CA�s Root Key pairs and, in particular, the private signing keys. This ceremony should be witnessed by an independent external auditor, and in cases where a PKI is used as an external business-to-business service, such a ceremony offers the assurance that certificates are generated and protected in a trusted and reliable way. The Hardware Security Module (HSM) The only way to preserve this trusted path completely is to store the CA Root Signing Key in a Hardware Security Module (HSM), which offers secure storage capabilities for cryptographic keys in an external, tamper-proof environment. This module should be so constructed that no private key is ever exposed in plain text outside the module, and also that the module itself is completely tamper proof. If private keys need to be exported (for secure distribution or backup) then they should be securely encrypted and split into several parts, such that a compromise of an individual part will not reveal the original key. The standard to consider when acquiring an HSM is the Federal Information Processing Standard (FIPS) PUB 140-2, which was developed by the United States Department of Commerce's National Institute of Standards and Technology (NIST) and the Canadian Communication Security Establishment (CSE). NIST publishes and has editorial responsibility for the standard. FIPS PUB 140-2 defines eleven categories of security requirements and identifies one to four levels of security for each category. As the level increases, the security requirements become more stringent. For example, a product that meets a level 2 requirement provides more security assurance than a product that meets a level 1 requirement in the same category. Level 4 provides the highest level of protection in commonly available commercial products, and Levels 3 and 4 enforce such precautions as :
Typically, Hardware Security Modules have two main applications:
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. Take a look at what happens when a user attempts to connect to a secure Web server using SSL: The user visits a Web site using a standard browser � the Web site has an X.509 V3 digital certificate
Cryptographic tasks such as encryption and decryption of the session keys can be offloaded to the HSM, thus relieving the host server of processor-intensive activities and thus improving performance and scalability. Without Hardware Security Modules, 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, providing high security private key protection that increases confidence in the legitimacy of digital signatures and certificates The HSM 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. The Luna SA is an Ethernet-attached HSM (Hardware Security Module) Server designed to protect critical cryptographic keys and to accelerate sensitive cryptographic operations across a range of security applications. HSMs, in general, are designed to provide dedicated cryptographic functionality, including key generation, key storage, and digital signing, on a one-to-one basis to their host applications. For example, a database server using an HSM would require one HSM, and a secure website using SSL on the same network would require a second, separate HSM. As the number of secure applications requiring an HSM grows, so does the number of HSMs deployed. As an HSM Server, the Luna SA provides increased flexibility in terms of deployment by providing a FIPS 140-2 level 3 HSM which can be attached directly to the network and shared amongst multiple applications and hosts. Rather than requiring many HSMs to fulfil applications� security demands, one Luna SA can be shared among many applications simultaneously. The Luna SA is housed in a 2U rack mount chassis which, although bearing more than a passing resemblance to a normal rack mount server, has a few important security-related differences.
Inside, the Luna SA is based on a commercial off-the-shelf motherboard with a Pentium 4 processor and 256MB RAM. The hard disk is used to house the stripped-down and hardened Linux-based operating system, which runs only the minimum of services required to connect the device to the network and provide secure remote access (via SSH). Two 10/100Mbps network ports are included in order to provide direct network attachment. By default, both cryptographic and administrative processes are offered on the same port, but it is possible to divide these between the two ports if required. This allows the use of a secure management network which is completely separate from the live network over which the crypto processes are utilised. Said crypto processes are provided by an integrated FIPS 140-2 level 3 HSM, the Chrysalis-ITS K3 Cryptographic Engine. This is a PCI-based solution which Chrysalis asserts offers the same high level of security as �traditional� server-attached HSM products. The Luna SA can be supplied to operate in basic, password-protected mode, or may be a Secure Authentication & Access Control (SAAC) version that requires the separate hardware-based Luna PED (Password Entry Device) and PED Keys for authentication and access control.
In addition to the tamper protection offered by the K3 card, the Luna SA enclosure itself is designed to be highly tamper resistant. A lot of care has gone into the design of the chassis to ensure that it is not possible to gain access either via normal means (such as removing the lid) or via extraordinary means (such as probing the interior via the ventilation slots). Behind the lockable front panel is the power switch (power cycling the device initiates an orderly shutdown procedure first), serial port (for initial console access), PED port (to connect the external hardware-based PIN Entry Device for authentication) and a PC Card reader to accommodate the secure Luna backup token. Performance is rated at an amazing 1200 signings per second with 1024-bit RSA keys (a figure which was verified during our testing process), and 300 per second with 2048 bit keys. Up to 4096 bit keys are supported, and the performance can be shared amongst multiple applications. For example, if the maximum load on a given Web server is one hundred 1024 bit key signings per second, then a single Luna SA module could be shared between twelve servers. If higher levels of performance are required, this can be accomplished by load balancing multiple Luna SA devices. This configuration provides linear scaling of performance. K3 Chrysalis Cryptographic Engine With the K3 Chrysalis Cryptographic Engine, Chrysalis-ITS has introduced a highly secure cryptographic module designed to operate within a host machine such as the Luna SA. The K3 CCE embodies the same core cryptographic functions as the more �traditional� token-based HSM products, but is offered in a tamper-resistant enclosed PCI card form factor. The K3 CCE is not a self-contained standalone product - it is, in FIPS PUB 140-2 terms, a �multi-chip embedded� module that is treated separately from whatever enclosing product uses it. The K3 CCE provides the following attributes within the validated cryptographic module:
There is no front panel or keypad configuration on the Luna SA, and so a separate hardware module is used to provide two-factor authentication (via PIN and hardware token) to the HSM and to backup tokens via a separate data port. This port is located on the front panel of the appliance and provides a direct connection to the K3 cryptographic processor inside as part of FIPS 140-2 level 3 security. Whereas other solutions make use of smart cards for the authentication token, the PED uses small plastic keys, electronically-programmable memory chips, embedded in coloured, moulded plastic key-shaped cases for ease of handling. The various colours and uses of the PED Keys employed with Luna SA and Luna PED are as follows: Grey - Default key, supplied with a new Luna SA or token. The grey key contains the default password that permits first access to the HSM, allowing further actions such as initialising the HSM and imprinting other PED keys that will work with it. The grey Default PED key is normally not used once the HSM Admin (SO) PED key has been created/imprinted. The grey key will only be needed again if the Luna SA or backup token is re-initialised. Blue - HSM Administrator (also called Security Officer or SO) PED key. The first actions with a new Luna SA involve creating a SO PIN and imprinting an HSM Admin (SO) PED key. The blue HSM Admin PED key is used for further actions on the Luna HSM, such as creating Users or HSM Partition Owners and changing passwords. Blue HSM Admin PED Keys can be duplicated for backup. Black - HSM Partition Owner or User key. This PED Key, once created/ imprinted by a holder of the blue HSM Admin (SO) key, is held by regular users (HSM Partition Owners) of the Luna SA or token, and permits access to the ordinary encryption functions such as creation of encryption keys and encrypted objects. Black User PED keys can be duplicated for backup. Red - Key Cloning Vector (KCV) or Domain key. This PED Key carries the domain identifier for any group of Luna HSMs for which key-cloning/backup is to be used (thus providing the ability for one set of keys to be used with multiple HSMs, if required). The red PED key is created/imprinted with the first Luna SA Partition, and then carries the �domain� (via Luna PED) to backup tokens or other partitions which are to be initialised with the same domain, thus permitting backup and restore among those containers and tokens only. Green - M of N PED keys. The Green M of N PED keys are imprinted with �shares� of a secret and are used only if optional M of N security is declared and activated on the Luna HSM. The overall number, or pool, of shares can be as many as sixteen (N). When the token is initialised, the pool or total number of shares is declared (N), as well as the number of those shares (M) which, in the future, must be brought together to perform encryption activities with that token (i.e. perhaps two out of any five Security Officers need to be present to perform critical operations). The N different green keys are then issued to trusted individuals. Thereafter, for the HSM Admin (SO) to login to the Luna HSM requires not only the presence of the HSM Admin with the blue SO PED Key, but also the presence of quantity M other trusted persons, each supplying his or her green M of N PED Key (and thus each supplying a portion of the shared secret). Similarly, the HSM Partition Owner cannot login alone, but must have co-operation of M different M of N key holders. The use of multiple keys, each with a specific function, provides an operational role-splitting capability within the Luna SA system. Since, each PED key corresponds to a different role in the administration hierarchy of the Luna SA, this ensures that no single individual has too much operational control. The operation of the PED also enforces a more secure two-factor authorisation system whereby authentication to the HSM rests both on something the administrator knows (a PIN number) coupled with something he possesses (the physical PED key). By requiring two authentication factors in this way, it becomes considerably more difficult to gain unauthorised access. A stolen PED key is useless without the corresponding PIN, whilst a misplaced PIN will not function without the corresponding hardware token. Additionally, a third factor may be added through the use of M of N split knowledge access control. There are 7 major elements to the Luna SA's operations:
Note that the Secure Backup Token, and Secure Authentication and Access Control are options which need not be included with every system, though they were included on the system under test in our labs. K3 Chrysalis Cryptographic Engine As was mentioned in the hardware section, the Luna SA's integrated K3 Chrysalis Cryptographic Engine is used to perform cryptographic operations and provide secure storage for sensitive cryptographic keys. The K3 provides the Luna SA's HSM functionality by providing secure cryptographic storage, cryptographic acceleration, administrative access control, and policy management. The K3 can also be used in conjunction with the optional Secure Authentication and Access Control (SAAC) feature to provide FIPS 140-2 Level 3 validated HSM operation.
HSM Partitions are independent logical HSMs that reside within the Luna SA's physical K3 HSM. This is a nice feature - unique amongst the devices we have tested to date - which allows the Luna SA to be shared between multiple different applications whilst ensuring that the HSM data for each application is kept completely separate from the others. This makes the Luna SA perfect for hosted environments, for example. Each HSM Partition has its own data, access controls, security policies, and separate administration access, independent from other HSM partitions, and each partition can be connected to one or more Clients. Each HSM Partition has a special administration account, called the Owner, who manages it. Each owner is prevented by the internal controls of the K3 processor from accessing partitions to which he has not been granted access. Depending upon the configuration, each Luna SA can contain up to 20 HSM Partitions, with each HSM Partition having the capacity to hold up to 80 data objects - this could be 80 digital certificates, or 40 key-pairs, for example. HSM Partitions can be dedicated to a single client (perfect for hosting environments), or multiple clients can all share access to a single HSM Partition. Clients are applications, or application servers that connect to the Luna SA to use it's cryptographic capabilities - to sign digital certificates, for example. Examples of possible clients are an encrypted database, a secure web server (SSL), or a Certificate Authority (CA), each of which require the creation and storage of sensitive cryptographic data at the highest possible speeds. Each Client is registered to one or more HSM Partitions (a client can register to multiple partitions across multiple Luna SA devices if required), and each partition is capable of supporting multiple Clients. Clients communicate with HSM partitions on the Luna SA through Network Trust Links and authenticate to the Luna SA using IP address validation in conjunction with a digital certificate and a unique HSM partition password. Network Trust Links (NTL) are secure, authenticated network connections between the Luna SA and Clients, and the Luna SA can support multiple simultaneous NTL connections. NTLs use two-way digital certificate authentication and SSL data encryption to protect sensitive data as it is transmitted between HSM Partitions on the Luna SA and Clients. It is the NTL that provides the means for the HSM functionality to be shared across what would otherwise be a potentially insecure TCP connection. NTLs consist of three parts:
Secure Command Line Interface (SCLI) There is no graphical or Web-based administration interface to the Luna SA, since this would require the operation of a Web server on the Luna SA box which would offer an additional opportunity for compromise of the system. Instead, all configuration and management - including the creation and administration of HSM Partitions, creation of NTLs, backup, and HSM policy management - is performed via the Secure Command Line Interface (SCLI). The SCLI is accessible either through a Direct Administration Connection through the Luna SA's local console port, or it can be accessed remotely through a Network Administration Connection via one of the Luna SA�s network ports. In order to facilitate the latter, the SCLI creates a secure administration channel via SSH during administration sessions to prevent unauthorised access or snooping. Secure Authentication and Access Control (SAAC) For those who wish to ensure that the Luna SA is FIPS 140-2 Level 3 compliant, it is necessary to utilise the optional Secure Authentication and Access Control (SAAC) capability. SAAC augments the Luna SA's authentication controls with an additional level of two-factor HSM authentication. To achieve true two-factor, Trusted Path authentication, SAAC relies on the addition of the Luna PED (Pin Entry Device). As mentioned in the hardware section of this report, the PED is a handheld authentication console which requires the insertion of both a numeric PIN and one or more role-splitting key-shaped digital identification tokens. SAAC also adds (optional) M of N access control, whereby a required authentication secret is split between multiple keys, a certain combination of which is required in order to perform administrative functions. The Luna SA features an optional removable Backup Token designed for the secure backup of contents residing within HSM Partitions. HSM Partitions are backed up to Backup Tokens through a process called cloning. During this process, the contents of the HSM Partition are encrypted before being copied to the Backup Token. The Backup Token is a tamper-resistant PCMCIA card that is inserted in the PC-Card slot on the front panel of the Luna SA. Since it is not possible to segregate data under hardware control within the Backup Tokens, each HSM Partition requires it's own Backup Token. In order to comply with digital certificate laws in some countries, it is possible to specify in the Partition Policy that backup is not permitted. Secure Identity Management (SIM) Secure Identity Management (SIM) is designed to overcome the restriction of being able to store a maximum of 80 data objects per Partition (a maximum of 1600 data objects per device). This is an optional feature, and the Luna SA was not configured for this capability during our test. SIM allows the Luna SA to create and securely manage large numbers of digital identities by �wrapping� the private keys that form the basis of digital identities (such as digital certificates) through a secure, multi-stage encryption process to create a secure data object that can be exported and managed outside of the HSM. During the SIM wrapping process, the clear text identity data, and subsequent wrapping keys are never exposed outside of the Luna SA's internal HSM, allowing applications to capitalise on the security offered by the HSM while retaining the flexibility and storage capacity of a DBMS to manage objects. This is clearly a compromise in terms of the �keys in hardware at all times� axiom, since once the private keys are exposed outside the secure confines of the HSM, there is the possibility that an attempt could be made to compromise them. Although it is unlikely that such an attempt would ever be successful, that minute risk makes this mode of operation unacceptable in some environments (hence the reason it is an option). However, if it is required to manage securely thousands of key pairs (perhaps in the case where a large organisation wishes to issue e-mail signing certificates to all its employees and customers) whilst benefiting from the additional performance and security of hardware-based key generation, this is the only way to achieve it. It is also worth noting that this �key wrapping� mode is the only mode of operation in some competing products. High Availability and Load Balancing (HA) Given that many HSM functions would be considered mission critical and downtime unacceptable, it is possible to deploy multiple Luna SA's in a High Availability (HA) configuration which allows multiple Luna SA's to be grouped together to form one virtual device. As with SIM, this is another optional feature that was not configured on the device under test. When deployed in an HA configuration, two or more devices are grouped logically to appear as a single Luna SA to client applications. From an operational perspective, the members in the HA Group share the transaction load, synchronise data with each other, and gracefully redistribute the processing capacity in the event of failure in a member machine to maintain uninterrupted service to clients. When multiple Luna SAs are configured in this manner, transactions are distributed evenly between them in a �round robin� manner, and thus performance is scaled linearly - two devices provide 2400 1024 bit signings per second; three devices provide 3600 1024 bit signings per second; and so on. Should one device fail, the others take over seamlessly, providing uninterrupted service for the Clients. The only detrimental effect is a loss in performance of the cluster equivalent to the capabilities of the device which has failed. Field-installable updates for Luna SA are released in the form of a secure package which has been signed by Chrysalis-ITS. Each package is supplied on a CD containing both the secure package itself and an authorisation code A secure package update might be associated with a client software release - and therefore shipped with a software release - or it may be a stand-alone upgrade shipped separately. The different possible types of update include:
There are effectively four classes of administrative user which are recognised by the Luna SA, with each type of user possessing different access privileges and able to perform different actions on the device:
Each Administrative user plays a different role in the administration of the Luna SA. Depending on the organisation and security policy, one person may perform only one role, or possibly perform multiple roles. It is also possible to have multiple people sharing one role. When the Luna SA is first installed, the HSM Admin (the holder of the grey PED key) uses the Secure Command Line Interface (SCLI) to initialise and configure the HSM, as well as imprinting those PED keys necessary for day to day operation and which are mandated by corporate policy. Following that, the administrator will define the global HSM policy, which will enable or disable such features as masking (required for key wrapping when using the SIM feature), partition cloning, the use of non-FIPS algorithms, use of M of N authentication, and so on. If certain features are disabled at the global policy level, they cannot be overridden and enabled for an individual partition. However, enabling a feature at the HSM level does not automatically enable it for all partitions - it merely allows a feature to be enabled at the partition level. Once the global policy has been configured, one or more Partitions can be created, and each of these will have its own Policy applied. At this point, the administrator for an individual partition (the partition owner) can simply accept the default configuration applied at the HSM level, or can override those parameters which were not mandated globally. A common feature to override, for example, is Auto Activation, which is disallowed by default. Enabling Auto Activation allows the authentication settings to be retained for up to one hour in the event of a power failure, meaning that the administrator does not have to re-authenticate in order to enable the partition when power returns. Auto Activation does not remove the need to authenticate to the HSM to enable a partition following a full shutdown. Each Partition on the Luna SA behaves as if it were a completely separate HSM module to the outside world. There is thus at least one Client per HSM Partition which is allowed to access and use the contents of a specific Partition and perform operations with the contents of the Partition, such as digitally signing a file. In order to allow a Client to use a particular Partition, it is necessary to install the Client software (the Network Trust Link Agent) and create the necessary Network Trust Link (NTL) between the Client and Partition. The NTL uses digital certificates to verify the identities of connecting Clients. The global Luna SA certificate was created during the initialisation process, and each Client must generate a self-signed certificate that is bound to the client�s host name or IP address to identify it uniquely to the HSM. These certificates are exchanged by a manual secure copy process (all the tools are provided as part of the Client installation), following which they are registered against the specific HSM Partition (or partitions) that the client is allowed to access. Once this process is complete, the client can start an NTL session with the Luna SA and have visibility of (but not yet access to) the HSM partitions to which it is registered and which it is authorised to access. Other HSM partitions present on the Luna SA for which the client is not registered are inaccessible and not visible to the client. Note that access to destructive HSM commands (such as HSM initialisation) is only permitted via the administrator interface and is not permitted via the NTLA client interface. In FIPS 140-2 Level 3 validated operational mode, HSM commands also require separate two-factor authentication. Access to the HSM is separately controlled based on authentication to the appropriate HSM partition or the Security Officer role for HSM-wide configuration operations. In order for a Client to use a Partition to which it has been registered, the Partition must first be activated. This can only be accomplished by the Partition owner, using the black PED key plus an optional PIN. Once an HSM partition is activated, it remains activated until one of three things occurs: a power outage, the Luna SA is physically tampered with, or the partition owner deactivates the partition. As mentioned before, the need to reactivate the Partition in this manner following temporary power loss can be removed by enabling the Auto Activate feature. The Client authenticates to its HSM Partition by providing the Luna SA with the HSM Partition Password, a unique 16 digit code generated during the creation of an HSM Partition, after which it can access the contents (keys, digital certificates etc.) of the HSM Partition and perform operations with them. Process-level access control is also provided within an NTL-registered machine to a specified HSM partition. A combination of the HSM Partition password and a unique one-time challenge provided by the Partition are combined to calculate a one-time access token which is used by the NTL Agent running on the Client host. SSL is used in the Luna SA�s NTL architecture to establish a trusted channel between the NTL Agent (NTLA) running on the client and the NTLS within Luna SA using the mutual authentication and session encryption provided by the SSL protocol. Any application running NTLA on a client computer can be connected to the NTLS via the SSL link. However, due to the process-level password requirements mentioned above, this still would not allow an application on the platform access to the contents of the HSM. Since access to the NTLS does not provide access to key material and sensitive functions, compromise of an authorised platform�s SSL private key does not pose a risk to the security of actual key material in the HSM. If necessary, the Luna SA administrator can easily revoke the NTLS access of a compromised or suspect platform. Note also that the challenge secret on its own is not sufficient to authenticate to the HSM partition � the partition must also be activated using the PIN Entry Device (PED) and the partition PED key directly connected to the Luna SA (together with any optional PIN numbers or M of N keys optionally enabled by the customer). The Luna SA can be configured to have the activation state persistent (auto activation), allowing just the challenge-response scheme to be used for login in future or it can be configured in a way that requires PED key interaction for every login. Typically, the process will be started on the server and will then run continuously to provide the required services (CA, OCSP, etc.). The challenge secret would only be entered at the time the process is started. Thus, between Partition activation, NTL activation and process-level passwords, the Luna SA uses a comprehensive three-layer authentication and access control model to achieve extremely strong security between the host application processes and the Luna SA HSM partitions. This three-layer authentication and access control model was designed to allow the Luna SA to provide network connectivity to clients without sacrificing the security requirements of HSM operations. Bear in mind that the �traditional� HSM model has the HSM module connected directly to the client host via a SCSI or PCI bus - the use of a more open communications medium such as a shared TCP/IP network clearly introduces additional security concerns which need to be addressed.
To provide the highest levels of assurance and security, Chrysalis HSMs operate independently of their host application, APIs, and supporting hardware. To accomplish this, Chrysalis defines a clearly demarcated Security Boundary that isolates all firmware, software, and memory locations related to cryptographic processing and private key data storage on the HSM from external elements. The areas within the Security Boundary are only accessible through the HSM�s firmware to prevent exposure of cryptographic elements to the outside world. All other hardware and software components, including cables, client software, APIs, communications protocols, and authentication devices necessary for the HSM�s operation reside outside of the HSM Security Boundary and cannot directly access protected elements behind the boundary. The Security Boundary prevents components on the host system, which may be compromised, from gaining direct access to key data and cryptographic operations on the HSM. All cryptographic processing is performed within the Security Boundary to prevent unauthorised, or illegitimate access. For example, if a Chrysalis HSM is stolen and placed in a new environment for the purpose of gaining illegitimate access to the cryptographic material contained within it, the HSM will override requests from external sources if they contravene the internal security policy settings. This design practice eliminates the possibility that rogue or defective software could be inserted into the host system in an attempt to extract sensitive keys or data from the HSM. The security of the HSM is completely independent of the surrounding environment including the client software that communicates with it. The Luna SA even restricts standard PKCS#11 API access to prevent exposure of sensitive key materials or cryptographic processes. The autonomous nature of Chrysalis HSMs means that host application servers do not need to be disconnected from the network during HSM configuration or maintenance operations.
There are no built-in auditing, logging or reporting capabilities other than syslog logging on the Luna SA device. The syslog on the Luna SA records all activity on the appliance, but does not record activity on the HSM itself. The syslog includes:
Commands entered via the command line interface (lunash) - this includes HSM init, configuration settings and changes, policy settings and changes, software and firmware upgrades, partition creation/deletion, client registration and assignment, backup and restore Cryptographic function calls to the HSM can be captured from the client platform using a logging library. This is, however, intended primarily for debugging rather than audit. Luna SA is based on the Ultimate Trust Security Platform (UTSP) which is a fully programmable hardware technology platform from Chrysalis-ITS that provides a secure tamper-proof application environment, impervious to physical or electronic attack. In contrast to other HSM solutions, the Chrysalis-ITS product is unique in that it provides access to both a fully integrated HSM, and a Pentium-based execution environment. As with any PC, the Pentium processor can be used to execute applications, but in this case they can be secure applications which can take advantage of the integrated HSM for cryptographic processing functions. Chrysalis-ITS will offer platform-level programmability in two forms.
Programmability features were not available at the time of testing, but should be available by the time this report is published or shortly thereafter. The Hardware Security Module (HSM) is an essential part of any serious commercial PKI solution. Even in small-scale PKI deployments where the increased performance of hardware-accelerated key generation capabilities can be ignored, the enhanced security offered by the HSM is hard, if not impossible, to ignore. The Luna SA offers a high degree of security and performance, in a package that is easy to deploy and straightforward to manage. Logging and auditing capabilities could be improved (these are planned for a future release), and some might prefer to see a Web-based administration interface in addition to the command line interface. However, the introduction of the latter could introduce potential insecurities that would be at odds with the purpose of this device. As it stands, the administrative interface is clear and easy to use, and the documentation is excellent - Luna SA includes one of the most comprehensive and totally idiot-proof Setup Guides we have seen in our labs. In the non-FIPS version the potential to perform most of the day-to-day tasks via a secure SSH link over the network is an attractive proposition. When using the PED device, of course, it is still necessary to be in close proximity to the Luna SA itself when performing many administrative functions, and so the network-based administrative access is less attractive. What is attractive about the network-based approach, however, is the ability to share the HSM functionality amongst multiple client applications. HSM devices are expensive, and with the traditional model it is necessary to utilise one per secure host. Where that host is capable of utilising the full bandwidth of the HSM, that is not an issue, but where an HSM is capable of exceeding the average signing rate of the host application then the ability to share the excess performance amongst multiple hosts can offer huge cost savings. And the Luna SA is no slouch when it comes to performance, with a rated speed of over 1200 signings per second with 1024-bit RSA keys (which we verified during testing), and 300 per second with 2048 bit keys. The ability to cluster multiple Luna SA appliances provides linear scalability in terms of signing performance, as well as redundancy in case of hardware failure. With a one-to-one deployment of HSM to host, should the HSM fail then that host is out of action. With a redundant cluster of Luna SAs, the only effect of the failure of one of those devices is a reduction in signing performance. Of course, it is hard to argue against the fact that a network-attached HSM is potentially less secure than the direct-attached HSM, but the Luna SA architecture seems to provide an extremely secure environment for the private keys under its protection. With the inclusion of the optional Secure Authentication and Access Control (SAAC) feature via the separate hardware PED module then the device is rated to FIPS 140-2 Level 3 - and it is hard to argue with that, too. With outstanding performance, scalability, resilience and ease of use, the Luna SA is definitely worth a look for any organisation wishing to make use of PKI or secure Web applications. Company name:
Chrysalis-ITS. Click here to return to the PKI Index Section |
Security Testing |
Send mail to webmaster
with questions or
|