Secure Messaging

Many products and technologies are available today that allow agencies to secure electronic messages, but sifting through the wave of offerings to find the best fit for a particular need can be a daunting task.

Add to that secure messaging standards that are still in development and a federal public-key infrastructure (PKI) that has yet to be built, and the picture gets even more confusing.

As might be expected in such an environment, different agencies look for different levels of security. However, agencies basically agree on what they want from secure messaging: sender authentication, confidentiality and assurances that messages cannot be intercepted and read by someone other than the intended recipient.

In general, the technologies used to secure sensitive data that is sent across the network, such as encryption and digital signature, are the same technologies that are used to secure electronic messages. In addition, messaging products such as Netscape Communications Corp.'s Netscape Communicator, Microsoft Corp.'s Exchange and Lotus Development Corp.'s Notes/Domino also come with built-in security features, such as authentication and encryption.

"Secure messaging is a means to an end," said Chris Tolles, group marketing manager for network security products at Sun Microsystems Inc. subsidiary SunSoft, which recently announced its Sun Internet Mail Server 3.1.

"The requirement for security is there for almost any application." Regardless of what type of information is sent over the network, "there is a need for privacy and security," Tolles said.

A De Facto Standard

What is making secure messaging easier to do is support for a standard called Secure/Multipurpose Internet Mail Extensions (S/MIME), which has become the de facto commercial standard for signing and encrypting e-mail. The basic MIME standard defines the format for sending messages across the Internet.

"We have been working with a lot of [vendors] to try and help the market focus on a single standard," said Lynn McNulty, director of government affairs for RSA Data Security Inc. and former associate director for computer security at the National Institute of Standards and Technology.

"S/MIME is consistent with our long-standing tradition in working with vendors to build standards [that] all can build products to," McNulty said. RSA's S/MAIL, which is based on RSA's core cryptographic algorithms, lets mail vendors build the S/MIME security standard into their messaging applications.

Messaging vendors have jumped on the S/MIME bandwagon.

"Since Notes 1.0 we were signing and encrypting mail, but we weren't using S/MIME. The Notes client will support S/MIME in Release 5.0, [which is] due out in the second half of this year," said Kevin Lynch, product manager at Lotus. The company is also expanding its Domino server capability to generate certificates for any World Wide Web client.

By the end of this month, Microsoft will add support for S/MIME to Exchange. "In the Service Pack for Exchange 5.5— available by the end of March— we will also support S/MIME and X.509 Version 3 certificates," said Mitra Azizirad, systems engineer manager at Microsoft. "This means Exchange will accept X.509 certificates issued by intranet certificate authorities or Internet certificate authorities."

Netscape Communicator also supports S/MIME. "We feel S/MIME is the preferred standard," said John Menkart, regional sales manager for Netscape's government group responsible for supporting the Defense Department. He added that Netscape is currently the only vendor offering secure messaging capability that's been validated by NIST. A group of vendors is now working to merge S/MIME and the Message Security Protocol (MSP), a secure messaging standard used by DOD on the Defense Message System (DMS), a DOD-wide messaging system being developed by Lockheed Martin Corp.

Gary Van Dyke, president of J.G. Van Dyke & Associates, which is heading up the effort to merge the standards, said the initiative should make it easier for military and civilian agencies to exchange secure e-mail because S/MIME and MSP currently cannot interoperate with each other.

A prototype of the standard, called S/MIME Version 3, will be available this summer, Van Dyke said. "S/MIME will allow compatibility between military and commercial communities," he said. "There will always be, in the intelligence community, a hard-core requirement for extra-high assurance. In some quarters, MSP Version 4 will be the standard, but S/MIME will replace much of what is envisioned for MSP Version 4."

S/MIME Version 3 will include features currently found in MSP, such as security labels like "top secret" for different classes of messages and support for the Fortezza card— a PC card that supports the government's cryptographic standard— so that S/MIME can be used on DMS.

DMS currently supports X.509 certificates and MSP versions 3.0 and 4.0, but the program is moving toward supporting commercial standards, said Capt. James Day, the Navy's program manager for DMS at the Defense Information Systems Agency. "The [National Security Agency] has worked with industry to make S/MIME the functional equivalent of MSP 4," Day said. "We want to converge with industry in this area; however, we do not see wide-scale, multiple-vendor security service interoperability for another few years."

DISA is working on defining a set of Internet standards for medium-grade, medium-assurance messaging. This includes signature and encryption capability based on S/MIME.

Currently DMS provides interoperable digital signature and encryption technology using Fortezza card technology and MSP 3.0. DMS users can either sign or encrypt a message, use both technologies or neither of them. Users can also sign or encrypt a message using the DMS client software provided on the DMS contract. However, interoperability is typically limited to the user's enclave or other enclaves with the same commercial product, Day said.

Missing Infrastructure

However, according to some agencies, S/MIME and related secure messaging solutions will not be complete unless they are deployed with an underlying PKI scheme.

Public-key systems use a public key, which is publicly known and often stored in a directory, and a private key, which is kept secret. Public and private keys are mathematically related so that a message encrypted with a sender's private key can be decrypted by the recipient with the matching public key. A digital signature verifies the origin of the message and the identity of the sender.

However, while PKIs have been discussed for years, there is no standard approach. At issue is who will distribute the digital certificates containing the public key and the digital signature, and who will be responsible for maintaining the message integrity.

There cannot be secure electronic services without a PKI, said Patricia Edfors, president of PNE Associates and former champion for security and privacy for the federal Government Information Technology Services Working Group.

"You need public-key infrastructure for digital signatures and encryption," she said. "The problem now is that there is no one steering the boat, so we're having difficulty focusing on what the next steps are. It's slowing down the process."

Others agree. "I think we are on the verge of the next generation of [secure messaging] products; unfortunately, there are still differences of opinions on how security should be implemented," said Marion Royal, telecommunications specialist in the General Services Administration's Center for Electronic Messaging Technologies. "The fact that we don't have a security infrastructure to handle certificate authorities is one factor. There are still a lot of proprietary solutions out there. I think we need an infrastructure solution to overcome that."

Products from such companies as Entrust Technologies and VeriSign generate the keys needed in a PKI. However, certificates from different companies cannot interoperate with each other. Also, there is no PKI in government that would describe the framework and procedures of how the process should be managed.

However, even without a PKI, "you can still use S/MIME. It will give you some level of security without PKI behind it. It gives a level of privacy," said Brian O'Higgins, executive vice president and chief technology officer at Entrust Technologies. However, in the corporate environment, "to do it properly, you need PKI."

Still, agencies are forging ahead. Michele Rubenstein, director of electronic messaging programs at the Treasury Department, heads up a key-recovery pilot project to test the feasibility of sending digitally signed and encrypted messages containing procurement-sensitive information between the department and vendors. The next phase of the pilot— set to begin shortly— will test the interoperability of different vendors' certificates.

"I know our bureaus are looking at similar solutions," Rubenstein said. "Digital signature is paramount. Whether you use encryption depends on what information you are sending. Because of the nature of what Treasury does, we all have different approaches."

NASA has developed a secure messaging system that it is testing in all NASA centers. The agency also is testing a process that allows it to exchange secure scientific grant information with about 50 universities, and it is working with industry to develop and test secure Web capabilities that use the same public-key infrastructure technology.

The Transportation Department, meanwhile, plans to use X.509 certificates stored in the department's X.500 messaging directory. This would allow it to store digital certificates in a department-wide directory DOT is already building.

"That's why I think X.509 is compelling— because you already have an X.500 directory for e-mail that can be augmented with X.509 certificates," said George Ramick Jr., DOT's messaging manager. "Users can come into the directory and retrieve the public key."

Currently, DOT relies mainly on commercial security products and features that come with the messaging packages it uses, including Lotus cc:Mail and Microsoft Mail. But as users rely on e-mail for more of their work, a department-wide security application and more robust systems are necessities, DOT said.

DISA and NSA are testing commercial-based, medium-assurance PKI as part of the Defense Travel System pilot, which is part of an initiative to create a paperless system for processing travel expenses.

Ultimately, an agency's decision to buy a particular set of security products must be coupled with security policies, said Steve Sill, project manager for departmental mail systems at DOT.

"From what I've been able to determine, you can't apply a one-size-fits-all security solution because agencies have different needs," Sill said. "No one security solution will be the magic bullet. It will be a combination of products, but most of all it's the human element. Agencies have to create [policies] that can be enforced."

AT A GLANCE

Status: A wide range of secure messaging solutions exist, but the market currently lacks focus.

Issues: Important security standards are still developing. Also, government and industry have not come to a consensus on how to deploy a public-key infrastructure, which many agencies believe is critical.

Outlook: Good. Industry standards appear to be on track. Meanwhile, agencies are pushing ahead with security pilots.

GLOSSARY

Public-key infrastructure: The framework of law and procedures needed for the widespread use of digital signatures.

Certificate authority: An entity that issues digital certificates used to create digital signatures and public-/private-key pairs.

Digital signature: A digital seal that verifies that the message has not been altered during the transmission. If a message is altered, it voids the signature.

S/MIME: The de facto commercial standard for encrypting and signing

e-mail.

MSP: The secure messaging standard used by the Defense Department.