Tuesday, December 10, 2024

Confidentially yours:

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

St. Joseph’s Hospital needed an edge. The 524-bed teaching hospital based in Marshfield, Wisc., vies with major health care centers in four neighboring cities for patients.

While the fact that 70% of St. Joseph’s patients drive more than 30 miles to reach the hospital was encouraging, it wasn’t enough to guarantee continued success. So to make its facility more attractive to the doctors, the hospital decided a year ago to let physicians get information on their hospitalized patients through a standard Web interface, version 4.0 or higher of either Netscape or Internet Explorer. By providing such convenient access to data like test results, diagnoses, and treatment plans, St. Joseph’s hoped that physicians would find it beneficial to direct patients to its facility.

AT A GLANCE: St. Joseph’s Hospital Ministry Health Care

The company: Based in Marshfield, Wis., St. Joseph’s Hospital is a 524-bed teaching hospital and the largest member of Ministry Health Care, a regional system in Wisconsin and Minnesota.

The problem: In order to attract referrals from physicians in its region, St. Joseph’s developed a Web site for easy access to patient information. The hospital needed a way to safeguard that sensitive data.

The solution: St. Joseph’s implemented a public key infrastructure solution from Arcot Systems Inc., of Palo Alto, Calif., in March 1999. Only a few physicians are currently using the system, but the potential number is over a thousand.

The IT infrastructure: Arcot’s WebFort is a complete, drop-in PKI solution. Verisign Inc. provides certificate authentication, while GTE provides local telephone service and AT&T provides long distance. The hospital is part of the University of Wisconsin network (WiscNet), which provides the medical center’s two T-1 lines to the Internet. St. Joseph’s uses OutReach from IDX Systems Corp. of Burlington, Vt., which provides Web access and is also the vendor of its information system. OutReach makes the patient data available on the Web and integrates it with the rest of the system. The standard interface is version 4.0 or higher of either Netscape or Internet Explorer.

The only hitch was keeping patient data confidential. “We needed to go beyond a simple password approach,” says CIO Steve Pelton. “The real fear was how would we ever be able to secure information.”

Pelton’s concern–common among IT professionals–was that while passwords and IDs are the linchpin of enterprise security, anyone who gets hold of a user name and password can access the hospital’s system and its sensitive information. St. Joseph’s answer has been to heighten security dramatically with a public key infrastructure (PKI).

PKI is an approach to achieving two security goals at the same time: user authentication and secure communications. The purpose of user authentication is to confirm that senders of messages are who they claim to be. Certification authorities (CAs), which issue digital certificates–electronic documents that include a user’s digital signature–provide authentication. Secure communications uses encryption to render data indecipherable to anyone who illicitly intercepts it. To decode and read a message, both a public key (included in the digital certificate) and a private key (possessed only by the intended recipient) are required.

In March of this year, St. Joseph’s went live with WebFort, a complete, drop-in PKI solution from Arcot Systems Inc., of Palo Alto, Calif. WebFort provides camouflaging technology that requires a PIN number to use the private key. If someone gives the wrong PIN number, the system provides a fake private key, so the digital signature will be invalid and the unauthorized user won’t be able to read any messages. VeriSign Inc., in Mountain View, Calif., provides certificate authentication. While only a few physicians are using the PKI system now, the potential number is over a thousand.

PKI software sales are growing rapidly, from $58 million in 1997 to an expected $328 million in 1999, according to Giga Information Group Inc., of Norwell, Mass., estimates. Contributing to this growth are vendors of mission-critical applications. As they move to integrate Internet capabilities, they’re considering PKI as a solution for secure communications. Whether their software is for ERP, supply chain planning, or human resources, security is an issue.

“As companies roll out these applications, PKI gets pulled along with them,” says Abner Germanow, a senior analyst, Internet security at International Data Corp. in Framingham, Mass.

E-commerce drives security boom


“We needed to go beyond a simple password approach. The real fear was how would we ever be able to secure information.”
–Steve Pelton, CIO, St. Joseph’s Hospital

But rapid growth can’t mask PKI’s pitfalls, such as incompatibility among the many available implementations. Still, a public key infrastructure can offer valuable security capabilities to a company migrating key data to the Web–as long as the promises of vendors and the technology itself are served with a grain of salt.

Although PKI was invented in the 1970s, until recently it was only used in niche areas where security was paramount, such as military communications. Most organizations conducting electronic business–like electronic data interchange (EDI) with vendors and large customers–did so over dial-up lines, leased lines, or virtual private networks (VPNs). Such lines often offer a high level of physical security, making it difficult for hackers to intercept data.

Today, the business drivers for widespread adoption of PKI are explosive growth of the Internet and e-commerce. Companies suddenly find themselves doing business on public networks rather than via secure private lines. As e-commerce expands, so do the risks companies face. As the risks increase, so has the interest in PKI.

Boston-based Safety Insurance was one company that faced increased online security risks. With 2,500 independent agents working from 600 offices throughout Massachusetts, the 20-year-old insurer needed better interoffice communication links, so officials turned to PKI, creating a Web portal in Oct. 1998 to bolster secure communications.

Before the portal was implemented, when agents had questions for Safety, they had to play telephone tag with the customer service department. Web access provided agents instant information–and opened the door for potential security breaches. After visiting a few agents, the company decided that password protection was insufficient security.

“Being in agents’ offices, seeing those yellow Post-it notes with passwords all over the place convinced us [PKI] was a better approach,” says John Almeida, assistant vice president of MIS at Safety. The company decided to use a PKI system since digital certificates do not require the user to remember, let alone enter, IDs or passwords.


Standards, anyone?

Electronic business places a premium on systems that work across the entire Internet. Unfortunately, although PKI is meant to enable e-commerce, it ends up creating isolated islands of security in the vast World Wide Web. While PKI uses standards in some areas, public key infrastructure implementations are so diverse that individual systems are often incompatible.

True, digital certificates are governed by a standard, ITU X.509, which defines basic, mandatory data like the digital signature and private key. But X.509 also allows for vendor-defined data that varies by PKI system, such as someone’s business title or a driver’s license number. If two PKI implementations make different uses of this optional data, they won’t be 100% compatible.

Even cryptography algorithms vary among PKI implementations. Some systems use RSA (Rivest, Shamir, and Adleman, inventors of the technique); others depend on DSS (Digital Signature Standard) encryption; still others employ DES (Data Encryption Standard). These methods do not interoperate.

A further complication is that PKI implementations involve business practices as well as technology. For two PKI systems to interoperate, their certification authorities (CAs) must be able to vouch for each other. But if two CAs have different business practices–such as initial identification requirements for users or the frequency of updates to revocation lists–they might not honor each other’s certificates.

Efforts are underway to create some interoperability among CAs and PKI software. PKI Exchange (PKIX) is an emerging standard for PKI interoperability on the Internet. The National Institute of Standards and Testing (NIST) has also been developing federal government standards that are a subset of PKIX, as well as tests for PKI software interoperability under its standards. While the NIST standards would be compatible with PKIX, some PKIX implementations might not be compatible with NIST.

But some question whether PKI vendors are actually striving for compatibility. Michael Rothman, executive vice president of SHYM Technology Inc. of Needham, Mass., says that at least to some extent, cooperation on standards is for show. “None of the PKI vendors or certification authority service providers want real interoperability,” says Rothman, whose company sells PKI interoperability software. The greater the interoperability, the harder it is for certification authority providers to differentiate themselves, he believes.

Kathy Lyons-Burke, lead on PKI applications for the NIST, has a similar perspective. “When the people who buy the PKIs start demanding the interoperability, it will appear. If [vendors] can sell more of their product by not being interoperable, then they will not be interoperable,” she says. Similarly, they will become interoperable if they can sell more of their product that way, Lyons-Burke says.

If vendors don’t hammer out interoperability issues, users could find it necessary to manage multiple digital certificates on their machines, a task they shouldn’t relish. –E.S.




“Being in agents’ offices, seeing those yellow Post-it notes with passwords all over the place convinced us [PKI] was a better approach.”
–John Almeida, assistant vice president of MIS, Safety Insurance

Safety is using AssureWeb, a product from Entegrity Solutions Corp. of San Jose, Calif., that adds PKI security to Web sites. New York City-based Bell Atlantic Corp. provides certification authenticity and telecommunications services for Safety. While relying on vendors to implement PKI saves the expense of putting security experts on payroll, Almeida does think it leaves Safety too dependent on those companies. He hopes that future standards will allow greater interoperability of PKI systems, indirectly making it easier for Safety to change vendors if necessary.

Securing international payments

For companies like Ruesch International Inc., e-commerce is the core of the business model. With U.S. headquarters in Washington, D.C., Ruesch expedites international trade for its 25,000 worldwide clients by providing currency exchange and international banking services. For example, the company enables its clients to check payment histories to existing vendors or to set up automatic payments to new vendors. Two-and-a-half years ago, Ruesch decided to develop online services for existing customers; in Feb. 1999, the company launched its Web site.

Authentication and privacy are important issues for Ruesch, and not just because clients expect sensitive data to be protected. The company falls under U.S. banking industry regulations, so any tampering with data could trigger legal action by the government. But Ruesch didn’t want to go overboard with security, since a system that’s a burden to customers could drive away business.

Ruesch considered a number of technologies, including biometrics, which employs specialized scanners to check unique physical characteristics such as users’ fingerprints or retinal patterns. Unfortunately, while biometrics provides solid authentication, the technique requires intrusive scanners that fit on a finger or over an eye.

The company finally settled on a PKI system, building it with pieces from a number of different vendors. This choice provided an additional benefit: the ability to disprove any false claims by customers that they did not make specific transactions. The PKI system can refute false claims by producing evidence that the customer’s unique digital certificate was indeed presented during the transaction.

Ruesch’s first step in implementing PKI was to choose vendors. The company started working with GTE Internetworking Inc., a Cambridge, Mass., unit of GTE Corp., almost three years ago to set up VPNs among Ruesch’s branch offices in the United States. Ruesch decided to continue using GTE Internetworking as its ISP and as host of its Web site.

In addition, another division of GTE had bought CyberTrust of Needham Heights, Mass., a certification authority. So Ruesch chose CyberTrust over competing CAs like VeriSign Inc. and Entrust Technologies Inc., in Plano, Texas. Outsourcing PKI services also was more appealing to Ruesch than buying software from a vendor like Baltimore Technologies PLC, with U.S. headquarters in Plano, Texas, and creating an in-house CA. “It seemed like a nice marriage,” says Ronald Szoc, senior vice president of technology at Ruesch.

GTE hosts both the Web and PKI servers, with the former tied back to Ruesch’s headquarters through a VPN. CyberTrust issues a certificate to a Ruesch customer, who then goes to Ruesch’s Web server. This server passes the certificate to the PKI server, which authenticates the certificate with CyberTrust. If approved, the customer is allowed through the firewall to use Ruesch’s services. Using GTE for certificates and Web hosting allows Ruesch to avoid the cost and trouble of building PKI expertise in-house.

The digital devil is in the details

Lessons learned about public key infrastructure

Hire expert help or partner with a PKI expert, because the PKI learning curve is steep.

Recognize that organizational and business process issues are as much a part of PKI as technology.
Plan on technical support for those using digital certificates on a PKI system.
Prepare a robust IT architecture, including full network directory services.

But picking PKI services is more than a question of convenience. The business practices of certification authorities vary greatly, and this can determine the level of security available to the CAs’ customers. One pivotal practice is a CA’s requirements for the issuance of a certificate to an end user. Will the CA take a telephone request? Does the CA demand a fax of paper forms of identification, like a birth certificate or driver’s license? Must someone apply in person for a digital certificate?

There is no right or wrong answer–and there is no standard that all CAs must follow. What is adequate security for one is expensive overkill–or even impossible–for another. Imagine if Amazon.com required each customer to meet with a company representative.

Businesses also have to decide how long certificates will remain valid, matching the certificates’ “lifetime” to the habits and profiles of its customers. “If you set your lifetime too long and you have a lot of turnover… you end up having a huge revocation list,” says Michael Froh, chief scientific officer at CyberSafe Canada Corp., in Ottawa, Ont., a division of CyberSafe Corp., an Issaquah, Wash., a vendor of enterprise security software. The revocation list, which enumerates certificates that have been voided, must be checked each time a certificate is used. The longer the revocation list, the more overhead the PKI system incurs.

There is also the issue of how often revocation lists are updated. Immediate notification from the CA when a certificate is no longer valid means more bandwidth and infrastructure expense. “Not a lot of organizations will need that degree of revocation checking,” adds Froh.

Is it safe?

Aside from operational issues, some people worry that PKI can lull companies into a false sense of security. For example, a public key infrastructure isn’t self-sufficient; it depends on other IT resources, like the network directory, which is necessary for storing the certificates.


How PKI works

Public key infrastructure (PKI) serves two security purposes for many companies: to confirm that senders of messages are who they say they are (authentication), and to encode messages so that they cannot be read by anyone who illicitly intercepts them (encryption).

Suppose a company has implemented PKI. When users first visit the company’s Web site to do business (#1 in diagram), they are referred to a certification authority (CA) (#2). The users apply to the CA for digital certificates that will identify them to the company (#3). Assuming the users meet the CA’s criteria for positive identification, the CA issues certificates (#4), which are then installed on users’ machines.

Once a user has obtained a certificate, software on the user’s computer automatically sends a copy of the certificate whenever the user communicates with the company (#5).

The certificate identifies its owner to the company’s PKI system and tells the company when the certificate expires. If the user’s signature is authentic and the certificate is still valid, the PKI system gives the go-ahead for the user and the encrypted message to pass through the company’s firewall (#6).

That’s how PKI works, in broadest outline. The details of public key infrastructure are byzantine. Here’s the minimum you need to know if you’re thinking about implementing PKI.

A critical element in any PKI system is the digital certificate, an electronic document that follows International Telecommunications Union standard X.509. Each certificate includes the user’s digital signature. The recipient’s software uses the public encryption key, also contained in the certificate, to check the signature for authenticity. Anyone may use a public key to encrypt a private message for secure transmission. But to decode and read the message, both the public key and a private key are required. Only the intended recipient possesses the private key.

Web browsers and e-mail programs are the most common applications that support digital certificates. Browsers like Netscape Communication Corp.’s Navigator (now owned by America Online Inc.) and Microsoft Corp.’s Internet Explorer use Secure Sockets Layer (SSL) to manage digital certificates. E-mail packages like Microsoft’s Outlook or Qualcomm Inc.’s Eudora with Secure MIME (S-MIME) also support certificates.

Companies using a PKI must create and manage digital certificates. These functions are performed by a certification authority, which may be a hired third party or an in-house department. The CA has various responsibilities; it creates the digital certificates and keys, and sets policy on what identification users must produce to obtain a certificate and how that identification may be presented. Some CAs accept a phone request from a user for a digital certificate; others require faxed identification such as a driver’s license; still others might demand an in-person application. In some implementations, the CA passes identification information to the company for approval.

To maintain security, the CA must flag invalid certificates by building a revocation list and checking it each time a certificate is used. The CA invalidates certificates when unauthorized people get hold of private keys, or when a person leaves a job that required a certificate, for example. The CA also maintains a repository of keys in case one is lost. –E.S.

St. Joseph’s uses Novell Directory Services (NDS) on its own Novell servers. In addition, the hospital uses OutReach from IDX Systems Corp. of Boston, the vendor of its hospital information system. (This is the hospital equivalent of an ERP system.) OutReach makes the patient data available on the Web and integrates it with the rest of the system.

“You can’t have a PKI without a solid directory because you can’t scale,” says Greg Shanton, director of the Information Security Lab at the AMS Center for Advanced Technologies, a division of consulting firm American Management Systems Inc., Fairfax, Va. “If you have one or two geographic locations and five to 10,000 [users], LDAP [lightweight directory access protocol] is fine. But if you’re going to have locations throughout the world, then an LDAP directory won’t cut it.” For worldwide coverage, an X.500 directory is the best option.

There’s another vulnerability in most PKI implementations: The digital certificate resides on the end user’s computer. This means that anyone using that machine will appear to be the person described by the certificate. Digital certificates can be encrypted, requiring a PIN number for their use, as St. Joseph’s and Safety Insurance’s certificates do, but this extra security is worthless if users give out their PINs. And according to experts, hackers can crack encryption PINs by trial and error, because they’re made up of very short strings of characters. In fact, there are PIN-cracking utilities available for free download from the Internet.

And so much depends upon the end users. Wells Fargo Bank of San Francisco has a thriving credit card business. The bank was building Web-based services for businesses that use its credit card processing services and wanted strong authentication. Because Wells Fargo had previous experience with digital certificates, its biggest difficulty was with the people using the certificates.

“The level of sophistication of the merchants requesting these certifications varies. Things that we thought were clear weren’t,” says Tim Knowlton, Wells Fargo vice president of business development and technical products. For example, customers would ignore repeated warnings that their certificates were about to expire. The bank was also surprised at how often the encryption keys were inadvertently erased by glitches in the merchants’ hardware or software. “You really need to make sure you have customer services in place, [that] you have multiple contacts [at customer sites], and [that you] constantly look at the types of issues customers have. It’s an evolutionary process.”

In short, PKI can offer enhanced security benefits to businesses. “We feel more confident [about security because of PKI],” says St. Joseph’s Pelton. “Eighteen months ago, there was a great deal of fear in the health care world about using the Internet with patient information. [There has] been a fairly significant transformation of the industry in a relatively small period of time.”

However, it is easy for management to lower its guard and expect the technology to do more than it can. “The thing that bothers me about PKIs is that they have two main purposes in life. One is authentication, and that’s digital signatures. The second one is just the distribution of… keys for encryption,” complains AMS Center’s Shanton. “And we have to put this huge infrastructure in place to manage it all. I would think we could come up with a better way to do all this.” //

Erik Sherman is a freelance writer and photographer living in Marshfield, Mass. His new book, “Home Networking: I Didn’t Know You Could Do That!” will be available from Sybex in the fall. He can be reached at esherman@reporters.net.



Subscribe to Data Insider

Learn the latest news and best practices about data science, big data analytics, artificial intelligence, data security, and more.

Similar articles

Get the Free Newsletter!

Subscribe to Data Insider for top news, trends & analysis

Latest Articles