Why a Secure Server May Provide the Most Protection for Your Mission Critical Applications

Those outside the IT industry have embraced the idea that the Internet, LANs, and WANs are now inherently secure, thanks to SSL and other encryption technologies. End-users go about their merry way sending credit card numbers, sensitive documents, and just about every other type of data imaginable across those trusted cables and into and out of server systems. They have no idea that these systems process this sensitive information using "clear text" copies of the data while being trusted to maintain its confidentiality and integrity.

Industry insiders and IT professionals, on the other hand, are a little more knowledgeable about such things. They know that not all software can be trusted, that many systems are prone to outside attack, and that one of the industry's little secrets is that most systems are far more susceptible to insider attacks than they would ever dare to admit. Because encrypted data must be converted to clear text to be used by applications, somewhere along the line it is in a form that is far more susceptible to theft or alteration. Secure hardware and software is a necessity if users are to trust these systems for sensitive company, customer, and partner data, as well as high-dollar B2B and B2C transactions. ASPs and their subscribers need to be assured of the overall security and integrity of the systems they are placing their trust in.

Buying the best safe in the world to keep your money in wouldn't protect your assets if you wrote the combination on a yellow sticky-note posted on its door. It's obviously the whole system that makes for a secure end solution. Many precautions can and should be taken in both hardware and software to protect data, including keeping the servers themselves in a secure environment. However, that environment's security also depends on who has access to it. Unfortunately, those who would tamper with your data from inside the server room can't always be spotted by their appearance or their resumes.

Building what we'll refer to in this paper as a Trusted Platform does not require the development of customized processors and motherboards. In fact, using non-standard or custom hardware can increase the cost of such a platform, putting it beyond the financial reach of many enterprises and requiring developers to write code that specifically addresses it. The best approach is to start with commercial off-the-shelf technology, such as Intel® processors, compatible motherboards, and standard device configurations such as PCI. To this basic foundation, we must add hardware security, access control, and software security.

Taking advantage of hardware security techniques used in cryptography can keep saboteurs from dismantling servers and either stealing data or destroying it. In the area of physical security, a number of mechanisms can be applied. The first is somewhat obvious - rather than using screws or other standard fasteners that allow the case to be easily dismantled, welds and rivets should be used wherever possible. Where disassembly is required for servicing, devices such as keyed screws ensure that a would-be thief would need a special tool to access the box. It shouldn't come apart with a standard screwdriver. Tamper-detect ion switches should also be used in enclosures. As soon as the enclosure detects that an attempt has been made to disassemble it, the system should go through a process called "zero-ization," which essentially zeros all of the sensitive cryptographic information.

Federal Information Processing Standards (FIPS) 140-2 Level 3 mechanical design criteria can be applied to standard 1U and 2U rack-mount enclosures. These security features include double louvered air vents to keep intruders from seeing into the enclosure; controls that are hidden beneath a flip-down lockable faceplate; and fan mounts and I/O mounts that are constructed in a tamper-resistant manner with baffles behind them so that intruders cannot remove an interface and have access to the interior of the box.

In many cases, it may also be unwise to use standard I/O devices such as floppy disk and CD-ROM drives, which can potentially give a saboteur a means to introduce damaging software into the system. Disabling access to these devices can also be important in keeping an intruder from installing a means to gain access to data. These are security measures that you wouldn't normally find in a standard server implementation - yet seem obvious if you are interested in building a secure server. These security measures can and should be transparent to application developers. It is sufficient to know that a physical attack will disable the processor, preventing any software from executing.

A Hardware Security Module (HSM) protects non-volatile, long-lived, sensitive information in the event that the Trusted Platform is physically penetrated or stolen. A FIPS 140-2 Level 3 validated device should be used to hold the sensitive information (such as Certificate Authority root keys). The idea behind an HSM is that, even if someone were able to gain access to the inside of the server and remove the hard drive, they would not be able to get to the cryptographic information because it isn't on the drive to begin with. It's stored securely on the tamper-proof HSM.

An HSM provides a secure co-processor that can offload cryptographic operations without exposing keys to the main processor. Hardware secured key generation, storage, backup, and digital signing further enhance the security of the Trusted Platform. The HSM can also be used to provide the Trusted Platform with a unique identity. A public/private key pair should be generated during manufacture. This cryptographically verifiable identity can be used to authenticate a server, preventing impersonation and increasing the security level of the system.

HSMs typically use industry standard physical interfaces, such as PCI, and software interfaces that include PKCS #11, OpenSSL, and JCA. Application developers using these APIs can easily migrate their software to support hardware secured cryptography.

The Trusted Platform must protect against insider attacks, for example, the actions of a rogue employee with administrative privileges. A number of security measures can be implemented to ensure that access is only achieved under controlled circumstances by authorized users.

The first means of access control is Two-Factor Authentication with Trusted Path Identification. The philosophy behind this type of control is that administrative access to the system requires the user to possess something that is unique (such as smart card or biometric identification) and to know something unique (such as a PIN, password, or personal secret). These two items must be presented to securely identify the user. To prevent theft of the user's PIN and password information, a trusted path must exist between the keypad and cryptographic device (HSM). The keypad on an ATM machine is an example of this methodology. It ensures that the information a user must present to gain access to an account cannot be electronically snooped as it is entered.

The next important method of access control has to do with Enforced Operational Roles. A Trusted Platform must avoid the concentration of administrative power into the hands of a single "trusted" user. Operational and administrative roles must be divided among several people to prevent unilateral action or a single point of failure within the operational security model.

Finally, it is important to implement Multi-Person Access Control. Two or more authorized employees must be present to access the hardware and software within a server. Most of us are familiar with this type of scenario from scenes in movies where two people with two keys must type in two PIN codes before an important action like launching a missile can take place. While most servers don't handle tasks as critical as a missile launch, data such as credit card numbers and other financial, corporate, or military data is certainly mission critical.

A Trusted Platform can force a number of people to participate in accessing the server. The advantage of this type of access restriction is that no one person can compromise the data. For example, if you have a disgruntled employee or someone who's been bribed and wants to steal or damage data, they will have to collude with at least one other person, depending on how the policy is set. This provides a much higher level of security than that of a typical data center where the IT personnel generally have all the root passwords for the mission critical servers, physical access to the data center, and the ability to cause damage without anyone else present in the room.

Once you've secured a server physically and restricted access to it through two-factor authentication, multi-person access control, and the other means discussed previously, the next step is to look at software security. Software security attempts to protect against the code corruption feared from traditional culprits such as hackers. Trusted Platforms provide three mechanisms to protect the code itself. First, secure software requires the use of a secure operating system environment, such as Security Enhanced Linux*. SE Linux is a version of Red Hat Linux* which includes a series of extensions and hardenings by the NSA. They have provided mechanisms for doing things like specifying software processes that have access to which resources on the server, which can be controlled at the OS level. The application developer provides, in addition to the RPM, a characterization of the processes the application will undertake so that the SE Linux kernel can enforce security policies - providing a place in which well-be haved, trusted software, can execute. For example, if an application is characterized as being resident within a given machine and has no reason to access the network, an attempt at network access would be considered a security breach for that application and not allowed.

To ensure a pristine software execution environment, a Secure Boot Mechanism must be used. The purpose of Secure Boot is to ensure that the machine boots into a known state on power-up. If, for example, an intruder has managed to replace the boot ROM and causes the machine to attempt to boot into a state that isn't known, a cryptographic mechanism would detect that situation and prevent the server from booting. Application developers are assured that there is no way intruders can tell the machine to boot into a state that would allow them to steal or damage data by inserting malicious code into the system. The Trusted Computing Platform Alliance (TCPA), formed by Compaq, HP, IBM, Intel and Microsoft, is an example of an industry coalition that is attempting to put security features such as Secure Boot Mechanisms on the market.

The third mechanism, called Secure Code, uses the Public Key Infrastructure (PKI) to cryptographically sign all code modules that will be executed in the secure server environment. Each application developer has their own PKI and their own root key, which they use to sign all the executables that can be legitimately put into execution in the Trusted Platform. The public key that corresponds to that root key is loaded on every box that gets shipped. Application developers are therefore required to sign software releases. As code modules are introduced, the loader in the machine goes through a cryptographic validation of every one of the execution modules. If it receives a module that wasn't signed by the publisher's root key, that module is rejected and is not loaded into execution. Microsoft's Authenticode is one example of using PKI to sign code modules.

Chrysalis-ITS, a leading provider of Hardware Security Modules - including Luna* SA - has built a Trusted Platform that fits all the criteria described in this paper, called the Ultimate Trust* Security Platform (UTSP). The benefits of a server environment that achieves the security level offered by Chrysalis' UTSP class of products is obvious. It gives organizations the confidence that their data is secure whether a potential saboteur manages to breach security and gain access to the secure server room, a disgruntled employee attempts to steal data using passwords gained legitimately, or a hacker attempts to breach security and introduce a devastating virus such as a Trojan Horse onto a mission critical server. This unprecedented level of security also paves the way for new applications to emerge within the secure server market space.

UTSP is a secure server designed to create and maintain a trusted platform for running applications. What distinguishes UTSP from other products is that it allows a means by which a given application no longer runs unprotected on a generic application server somewhere in the network, but actually executes inside a secure computing environment co-located with a cryptographic HSM. This type of hardware/software packaging model exposes interesting new realms for the distribution of applicat ions and can be of benefit to a number of different types of application and service providers..

UTSP provides the ability for a service or software provider to pre-package their software in an appliance form factor that is strongly tamper-resistant and that only they have administrative control over. That administrative control can be accomplished over the network, so if the provider wants to upgrade the software on a remote appliance, UTSP can serve as a service distribution beachhead over which they have control. The service provider doesn't have to be concerned about the facilities or the operational procedures that are employed at the physical location where the service is being distributed.

Another potential use for UTSP would be in a network-based identity service. Cryptography is the predominant mechanism for securing, authenticating, and validating electronic transactions, and the ability to handle cryptography in a highly secure manner is inherent to the UTSP secure server. In some situations, a service provider may want to offer its users roaming capabilities; however, it can be difficult to allow users to carry their cryptographic credentials around. One way around that challenge is for the service providers to construct and house their subscribers' digital credentials within their network on secure servers. Users gain access to that network's capabilities and remotely instruct the service provider's equipment to execute transactions on their behalf using their network-based digital credentials. For example, users could gain access to the system with something as simple as a cell phone. Using a WAP browser and a PIN code, a user could authorize the purchase of a music CD. Other uses for UTSP's cryptographic capabilities would be in the B2B segment, where purchases and transfers of goods could be accomplished in a highly secure fashion through a number of different access methods.

Because the UTSP is built around industry-standard Intel® Pentium® processors and motherboards, it is compatible with the majority of applications written by developers worldwide. By using the platform as a means for delivering software in a secure appliance form factor, software providers simplify the deployment process as well as increasing the overall security of the system.

The UTSP is a whole new class of secure server. It can serve as a network security device, a highly secure cryptographic gateway for both B2B and B2C commerce, and as an appliance into which a company could load their product and co-locate it with other servers on site. Regardless of the application, however, the security inherent in the UTSP is unprecedented.

George Walsh is a veteran technical editor and writer with experience in fields ranging from embedded systems programming to CAD. As a freelance researcher and writer he has provided his expertise to clients in a wide variety of markets.