On Securing the Public Health Information Network Messaging System

Barry Rhodes Rajashekar Kailar Associate Director For Public Health System Development Chief Technology Officer Information Resources Management Office Business Networks International, Inc. Centers for Disease Control and Prevention www.bnetal.com www.cdc.gov

Abstract

The Public Health Information Network PHINMS is operating system neutral since it is Messaging System (henceforth, PHINMS) is the implemented using Java and J2EE standards. Centers for Disease Control and Prevention’s (CDC) implementation of the ebXML 2.0 Further, it provides language neutral, queue based messaging standards [EbXML]. This system was interfaces for sending and receiving messages. The developed for the purpose of secure and reliable preferred queue implementation is an messaging over the Internet. This software has ODBC/JDBC compliant database table, but been widely deployed by CDC and its public support for queues based on XML file descriptors health partners, including state and local health also exists. PHINMS supports peer-to-peer departments, and healthcare providers. PHINMS is messaging, as well as messaging via a third party designed to leverage X.509 digital certificates using a send and poll model. issued by public key infrastructures, but does not require a single, universal PKI. In this paper we Message data security is accomplished using a discuss some of the security aspects of PHINMS. combination of encryption, end-point authentication, and access control techniques. Introduction Transport reliability is accomplished using message integrity verification, transmission retries

and duplicate detection on message receipt. The Public Health Information Network

Messaging System (PHINMS) is a CDC Since PHINMS is used to transport sensitive data developed implementation of existing standards over public un-trusted networks (e.g., Internet), it for the secure and reliable transmittal of messages is important to make sure that end-points trust across the Internet. each other, are able to identify and authenticate

each other, and that communication channels The PHINMS relies on ebXML, XML encryption preserve data confidentiality and integrity. Further, [XMLENC], XML Digital Signature [XMLDSIG], access to data sent and received should be SOAP [SOAP] and other standards. PHINMS is controlled. the primary message transport system for the

National Electronic Disease Surveillance System The balance of this paper will focus on some of [NEDSS], the Laboratory Response Network the security considerations that went into the [LRN], National Health Safety Network [NHSN] design and implementation of PHINMS. and various other public health preparedness programs within CDC.

By design, PHINMS is message data (payload) independent; hence it can be used to transport any type of data (e.g., text, binary).

Security Considerations Several security considerations went into the acceptable. In a purely PKI based authentication design, implementation and deployment of framework, a trust bridge such as the Federal PHINMS. The following is a brief description: Bridge CA could be used to address this Trust1 problem. However, while PHINMS supports PKI based authentication, it also supports other Secure messaging over public un-trusted modes of authentication, such as basic or custom networks requires messaging parties to be able authentication. to identify, authenticate and trust each other. For this, firstly, real world trust relationships need to be established between messaging organizations. PHINMS is designed to support both centralized This may include establishing written and de-centralized trust models. Decisions on agreements on service levels, liabilities, etc., identity binding and security credentialing are pursuant to OMB guidance on the Government made by the deploying organizations. Decisions Paperwork Elimination Act (GPEA) as well as on trusting the identity and security credentials the Electronic Signatures in Global and National are made mutually between messaging parties at Commerce Act (E-SIGN). Further, business the time when electronic collaborations are processes for creating and handling messages at created. each end of the messaging pipe need to be put in place. Once trust and business relationships are established in real world terms, electronic Identification, Authentication and collaboration agreements can be setup for Authorization message transport and processing. This includes setting up relationships to trust certification Identification and authentication in messaging is authorities and the identity of the sending and a difficult topic and is one that is far from receiving components (e.g., using access control mature. Since the message is typically sent by a lists). process and not necessarily triggered by an individual, the authentication dialog must be scriptable. That is, the sending application must In the centralized trust scenario, a central node be able to negotiate the exchange of credentials performs identity binding and security without human intervention. This is only credentialing, and all nodes establish trust possible for certain security tokens (e.g., relationships with a central node. In this case, hardware based one time passwords and assuming n nodes, only O(n) trust relations are biometric identities don’t lend themselves to this needed. However, in a heterogeneous kind of scripted authentication exchange). environment where trust is de-centralized, with n nodes, each node may need to establish a trust PHINMS supports automated authentication relationship and security credentials with every dialogs for client-certificate based authentication other node, and in the worst case scenario O(n2) over SSL, basic authentication, and form based trust relationships may be needed. Since authentication. The method used for mutual and messaging nodes typically belong to automated identification and authentication autonomous organizations and realms, between messaging parties is part of the establishing a globally accepted central identity electronic agreement between them, and should and trust authority may not be politically be established upfront, after the real world trust relationship has been established.

1 “Trust” in this context is more generic than what is involved in PKI based certificate chain validation. In particular, it may involve other (non-PKI) authentication mechanisms (e.g., basic or form based authentication).

PHINMS Receiver Server A Security Credential P PHINMS Sender

Security Credential Q PHINMS Receiver Server B

Each messaging node in the Public Health The web-server proxies typically reside in the Information Network (PHIN) is identified by a organization’s DMZ, and mediate all inbound globally unique identifier. As shown in the traffic for the PHINMS receiver server, diagram above, a messaging node (i.e., PHINMS authenticating the sending process. SSL with sender) may contain one or more security client-certificate based authentication is the credentials that allow it to conduct automated preferred method of authentication for PHINMS, authentication dialogs with other messaging since it is a well established standard and is nodes. In the absence of a universally trusted widely implemented by web-server proxies. authority to issue security identities and credentials, potentially, a different security Once the message sender is authenticated, it is identity and set of credentials may be needed for the responsibility of the receiving organization’s the purpose of authenticating to each message web-server proxy to ensure that an authenticated destination. The security credentials may include sender only gains access to the receiver URL. At client certificates (key-stores), passwords, etc. this time, PHINMS does not provide support for Managing these security credentials can be a attribute certificates which can be used for daunting task for the messaging administrator in authorization decisions. Authorization the face of expiring certificates, password information is stored on the receiver server, and renewals etc. Of course, certificates can be enforced by the web-server proxy based on the issued with an expiration period of years, authenticated identity of the PHINMS senders. whereas passwords typically must be changed every 90 days, so the problem with the latter is far more daunting. Authentication Factors For interactive authentication dialogs over the The recommended architecture for PHINMS Internet, generally, two factor authentication2 is messaging is one where the PHINMS receiver considered stronger and more secure than single components are protected from direct access factor authentication. from the Internet, by web-server proxies as shown in the diagram at the top of the next column:

2 Authentication mechanisms typically use secrets such as what a user knows (e.g., password), what a user has (e.g., hardware token) and what a user is (e.g., thumbprint). These are called authentication factors. For strong authentication, a combination of two of these three factors is used.

However, in the case of B2B automated security In the case of store and forward messaging, data dialog, the security value of two-factor is protected from being read by intermediaries authentication is significantly diminished, since by using asymmetric encryption using the public there is no real user behind the authentication key of the message recipient to encrypt a dialog. random symmetric key, which in turn encrypts the data. Additionally, communication is typically conducted over a Secure Sockets Layer All user factors required for the authentication (SSL) channel, ensuring that the message meta- dialogs would need to be pre-configured into the data is also protected. To ensure end-to-end software that initiates the authentication confidentiality, the channel between the web- handshake. Further, at the time of this writing, server proxy and the application server is also there are no published and accepted Internet over SSL. standards for two factor authentication in B2B transactions. While it is possible to use hardware based security modules (sometimes called HSM) Integrity and non-repudiation to emulate additional authentication factors for B2B exchanges, such mechanisms require PHINMS supports the use of XML digital additional hardware and management signatures [XMLDSIG] for message integrity complexity. and non-repudiation of message data. Signing certificates can be sent as part of the signature

meta-data facilitating verification of the Confidentiality signature, alternatively, signing certificates can be statically pre-configured at the receiving Since communication is over un-trusted public node. Additionally, communication is typically networks, protecting its confidentiality is conducted over SSL with client-certificate based important. PHINMS uses payload level authentication, which provides further message asymmetric encryption for end-to-end persistent integrity and non-repudiation assurances. confidentiality. The XML encryption standard The XML encryption standard [XMLENC] is used for encrypting the payload.

Access control The ebXML messaging standard supports message labels called “Service” and “Action”. These XML tags are part of the message envelope, and can be mapped to a service on the receiving node These XML tags are part of the message envelope, and can be mapped to a service on the receiving node.

In the PHINMS implementation, messages that are received using the receiver server are stored in database tables (queues) based on their Service and Action tags. These queues are the equivalent of an application “inbox”, and each application can only access its own inbox.

Public key infrastructure (PKI) Firewalls PHINMS is designed to leverage a PKI, but it Though firewalls are necessary for the does not require a universal PKI. For instance, a protection of resources within an enterprise, they PHINMS sending client can use a client complicate matters for a messaging system certificate issued by one certification authority trying to send messages across enterprise (CA) to authenticate itself to a PHINMS receiver boundaries. PHINMS uses two independent server, and use a client certificate issued by a pieces of code, a client capable of sending different CA to authenticate itself to a different messages and receiving real time (synchronous) PHINMS receiver server. Currently, PKI trust responses, and a server receiver that can receive relations are statically defined at the time when messages at any time. These two components collaboration is established and configured may be used in three possible scenarios. These between messaging entities. This is sometimes examples assume that the parties are in different called the “Certificate Trust List” model. organizations with separate firewalls. Ideally, public key certificates are published in an LDAP directory (need not be centralized), but 1. Both parties are located outside their PHINMS also supports a web-service interface respective firewalls (i.e., in their DMZ) to publish and retrieve certificates. As a third 2. One party is outside the firewall and the alternative, encryption public key certificates other is inside a firewall. can be distributed out of band and pre- 3. Both parties are inside their respective configured at the message sending nodes. firewalls. Public key certificates can be published in de- centralized LDAP directories as well.

In the case where both parties are located Basically a poll is where a client sends a outside their respective firewalls, messages may message to a server with some meta-data which be sent and received at any time and maps to a piece of functionality that looks to see acknowledgements send either synchronously or if the server has something for the client. asynchronously. This requires that both parties If so, the server can return the file as a response have sending and receiving components to the send. Because the client is not really installed. receiving messages, the complexity of the software is reduced and therefore the platform requirements are reduced as well.

For the situation where one party is behind a Typically the client can reside on a workstation firewall and the other party has a server receiver capable of hosting a Java application. located in the public Internet space, message sending options are slightly reduced. The client piece behind the firewall can send data much like a typical browser to a receiver and receive synchronous acknowledgements back.

Because it sits behind a firewall, the client cannot receive messages as firewalls typically block this type of “push” of information. What it can do is poll for messages.

In the case where both parties are behind firewalls, a third party server with Internet presence is required to broker the exchange. For example let’s say party A is located behind a firewall in enterprise 1 and A wants to send a message to party B in enterprise 2, where B is also behind a firewall. Then A must send a

message to an intermediary server on the When used, XML digital signatures should be Internet with a service action that states that the combined with a handshaking protocol such as server should hold the message in a queue for B. SSL, which mitigates the threat of replay attacks Then when B polls the server, it will find the and provide freshness assurances. The message from A in its queue and request it. alternative is to use SSL with client certificate based authentication. This provides per-link assurance of identity and authentication, as well Authentication Interoperability as confidentiality. Since SSL is the most widely The ebXML messaging standard specifies the accepted standard, this is the recommended structure and semantics of message meta-data mode of authentication for PHINMS. and addressing information, but for the most part, leaves the messaging security (identification and authentication) aspects to the implementers.

Acknowledgement The authors would like to thank the Public Health Information Network Messaging System team: Michele Bowman, Thomas Brinks, Dongtao Jiang, Vaughn McMullin, Thomas Russell, and John Thomas.

Summary The security design, implementation and deployment considerations of CDC’s Public

Health Information Network Messaging System As shown in the above diagram, for (PHINMS) were discussed herein. interoperability, in addition to the message structure and semantics, the security mechanisms also need to interoperate. XML digital signatures can be used to support message non-repudiation (the strength of which is dependent upon legal elements that transcend the technology), but using them may not be sufficient for authentication, since digital signatures can be replayed3.

3 A digital signature does not necessarily provide freshness evidence unless it is cryptographically bound to a freshness token, requiring time synchronization or nonce based handshakes. Without adequate freshness assurances use of DSIG in authentication may not be adequate for some applications.

References [EbXML] Message Service Specification [NHSN] National Healthcare Safety Network (NHSN)(http://www.cdc.gov/ncidod/hip/NNIS/mem Version 2.0, OASIS ebXML Messaging Services bers/nhsn.htm ) Technical Committee (http://www.ebxml.org/specs/ebMS2.pdf) [SOAP] SOAP Version 1.2 Part 0: Primer [LRN] The Laboratory Response Network Partners (http://www.w3.org/TR/2003/REC-soap12-part0- in Preparedness http://www.bt.cdc.gov/lrn/ 20030624/ )

[NEDSS] National Electronic Disease Surveillance [XMLENC] XML Encryption Requirements System, The Surveillance and Monitoring (www.w3.org/TR/xml-encryption-req) Component for the Public Health Information Network. (www.cdc.gov/nedss/) [XMLDSIG] XML-Signature Syntax Processing (www.w3g.org/TR/xmldsig-code