Linux in Government: Open Source Innovation within the DoD

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.
Open-Source Components
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.
The Other Shoe Falls
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."
Getting the Project Together
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.
Aims
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.
Tasks
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.
Accomplishments
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:

• Advanced Encryption
  Standard (AES) Algorithm: Certification #146
• Data Encryption
  Standard (DES) Validated Implementations: Cert
  #258
• Triple Data
  Encryption Algorithm (TDEA, a.k.a. "Triple DES"): Cert
  #256
• Digital Signature Algorithm (DSA) Validation System: Cert #108
• Secure Hash Algorithm
  (SHS) Validation System: Cert #235

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.

Effective 1 January 2001, preference shall be given to the acquisition
of COTS IA and IA-enabled IT products (to be used on systems entering,
processing, storing, displaying, or transmitting national security
information) which have been evaluated and validated, as appropriate,
in accordance with:

• The International Common Criteria for Information Security Technology
  Evaluation Mutual Recognition Arrangement;
• The National Security Agency (NSA)/National Institute of Standards
  and Technology (NIST) National Information Assurance Partnership (NIAP)
  Evaluation and Validation Program; or
• The NIST Federal Information Processing Standard (FIPS) validation
  program.

Heads of U.S. Departments and Agencies are responsible for ensuring
compliance with the requirements of this policy.

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.

Tom Adelstein lives in Dallas, Texas, with his wife, Yvonne, and works as a
Linux and open-source software consultant locally and nationally. He's
the coauthor of the upcoming book Exploring Linux with the Java Desktop
System, published by O'Reilly and Associates. Tom also has written
numerous articles as a guest editor for a variety of publications on
Linux technical and marketing issues.