Prior to implementing an integrated software solution for its hospitals in 1993, the military experienced bottlenecks in its computer services. Each branch of the armed services used different legacy systems and manual procedures to control the flow of medical supplies and equipment, facilities, contractors and record keeping. Then, the Department of Defense (DoD) automated the processes with a common standard platform to conduct medical logistics for every branch of service. When you manage as many hospitals and health-care facilities as the military does, standards-based solutions and coordinated automation are essential.

The Assistant Secretary of Defense for Health Affairs embraced what is referred to as the DoD information superiority initiative. Simply stated, as service members are deployed into various theaters of operations, new and better standards became essential. That's where the Defense Medical Logistics Standard Support (DMLSS) program comes into play. The DMLSS System is an automated information system used by the four major branches of the service to provide medical logistics support to military hospitals and other medical facilities.

DMLSS provides the four services with a common, standard platform for conducting medical logistics. It provides end-to-end information technology that enables the services to order and receive products and services electronically as well as to create and release invoices for payment. DMLSS also provides record keeping services, such as inventory control. The system complies with the accounting standards of the DoD, allowing the Comptroller's office to more efficiently compile its financial records. Finally, DMLSS serves as a source of record for DoD medical assets.

The Program Management Office (PMO) for DMLSS is located in Falls Church, Virginia. Continuing development and support facilities exist at Ft. Detrick, Maryland, at the Joint Medical Logistics Functional Development Center. At Ft. Detrick, programmers support open-source components in applications that require cryptography. They open-source components include Stunnel, Apache, ModSSL and OpenSSL.

Although Stunnel does not contain any cryptographic code itself, it relies on external SSL libraries, such as OpenSSL. ModSSL provides strong cryptography for the Apache 1.3 WebServer by way of the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols, with some help from the open-source SSL/TLS toolkit, OpenSSL. The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured and open-source toolkit that implements the SSL v2/v3 and TLS v1 protocols, as well as a full-strength general purpose cryptography library.

The PMO supported the use of open source and saw it as an enabling technology. As DMLSS became the standard throughout the military, the department heads enjoyed the success of their program. It has won 17 awards, beginning with the 1997 Government Information Technology Leadership Award and most recently winning the E-Business Transformation Award in 2003.

Some of us may find it hard to imagine, but in January 2000 members of the National Security Agency promulgated a policy that required any military program using information assurance to have its products validated by National Institute of Standards and Technology (NIST). The open-source components of DMLSS lacked such validation, called a FIPS 140-2 validation.

That led Steve Marquess, the technical manager of DMLSS, to the job of finding replacements for the OpenSSL libraries so prominently used in DMLSS. It also led him on a journey that blended serendipity with the realities of DoD chains of command. After months of research, Steve says he "discovered two things: not much commercial software was available and what existed was very expensive. Secondly, OpenSSL had already been validated multiple times."

Because OpenSSL has a BSD-style license, many vendors simply grabbed the source code and incorporated it into their proprietary products. Those vendors wanted literally hundreds of thousands of dollars in licensing fees. As Steve attests, "as a taxpayer, I felt very annoyed. But it made me realize a couple of things. First, if OpenSSL had been validated, then it was possible for us to do it again. Secondly, if we could do it we could save a lot of money for the program."

Steve took the idea to his superiors: Debbie Bonner, Director of Operations in the PMO, and Colonel Dan Magee, the DMLSS Program Manager at the time. Both actively encouraged Steve to go forward. Steve said, "The path of least resistance [for Debbie Bonner and Col. Magee] would have been to fork over a pile of taxpayer dollars for proprietary software, but they backed this out of the box move instead. That took guts, I think, especially when we were being told by nearly everyone that it couldn't be done."

Steve tried unsuccessfully to interest various vendors and organizations in collaborating on the project. In particular the program's vendor at HP seems somewhat reluctant. But Jeff Cohen, the HP account representative for DMLSS, wanted to see the program go forward. So, Jeff reached Gary Gross in HP's Common Criteria group (see here for the Common Criteria definition) and arranged for internal funding and allocation of resources to help pay for the project.

Although he now had the backing of his PMO and some funding from HP, Steve still needed a way to contract out the work. He called Bruce Perens, who worked at HP at the time, and asked for help. After listening to the idea, Bruce decided he liked it and recommended the Open Source Software Institute as a sole-source vendor.

Bruce also recommended Ben Laurie of the OpenSSL project to prepare the libraries for testing. A conference call ensued amongst the four parties, and the project got underway. John Weathersby of the Open Source Software Institute became the sole-source provider and handled all administration and non-technical management roles. Additionally, OSSI became the single point of contact for the project.

One of the project's first objectives was to make the open-source libraries available to the rest of the DoD and other government agencies affected by the required National Security Agency in NSTISSP No. 11 (see note below). That involved figuring out a way to obtain validation for software distributed as source code. One really could not do that, however. So, the testing lab received source code instead of binaries. This allowed the lab to compile the code, create a binary on two representative platforms (SuSE Linux and HP UX) and validate the binaries produced by the code. They then could throw away the binaries.

Usually with FIPS 140 validation the vendor supplies binary code that is validated as if it were distributed to customers. FIPS 140 requires a runtime integrity check of the binary code. But open-source software is distributed in source code form. The trick here, then, was to produce a mechanism by which cryptographic fingerprints could be chained from the original source code all the way to the final runtime executable.

The project team had to reach several milestones, which took approximately 18 months. The milestones included source code modifications, writing the security policy and running validation tests. Ben Laurie wrote the source code modifications. First, he had to sequester the critical parts of the source code so they would not be modified in the course of routine maintenance. That allowed the OpenSSL project to maintain the FIPS code for people wanting to compile it. Secondly, Ben had to write test drivers to process over 270 test vectors to prove the worthiness of the algorithms.

Steve wrote the Security Policy Document, which later was split into the Security Document and the User Guide. He also wrote the Vendor Evidence Document, which required completing a lengthy template. Finally, Steve provided the source to Christian Brych, FIPS 140 Program Manager at DOMUS IT Security Laboratory for testing.

On Monday, May 10, 2004, the National Institute of Standards and Technology (NIST) posted a notice that the AES, DES, 3DES, DSA and SHA-1 algorithms for OpenSSL have been validated. The validation notices can be found on the following NIST sites:

Although successful validation of the algorithms does not mean that OpenSSL has received FIPS 140-2 validation, NIST validation of these algorithms does signify a major milestone. Steve Marquess waits patiently for the final validation of OpenSSL. If that validation comes, Steve wants to see the open-source distribution model enhanced. He said, "while all validations in the past have been treated as proprietary data, we're going to publish the test drivers, input and output test vectors and the Vendor's Evidence document. And while I found plenty of Security Policy documents available, I never saw a single Vendor Document. So, I hope this will make the next person's effort easier."

Notes: National Security Telecommunications and Information Systems Security Policy (NSTISSP) No. 11 some pertinent information related to the "other shoe" can be found here.

In addition to funding by DMLSS, HP and John Weathersby, Doc Shankar of IBM, through the Linux Technology Center, contributed financially to the testing of the X86 platform on SuSE Linux.