By Scott Stuewe, DirectTrust President and CEO
DirectTrust manages trust in identity for millions of providers and healthcare facilities in the US so they can safely exchange sensitive data on their patients and coordinate care across organizations. The patients themselves want to be a part of such communications as well, and as such, many consumers have the same ability to communicate with their providers using Direct Secure Messaging (aka Direct).
Direct Secure Messaging is different and much more secure than encrypted email. Why? Trust-in-identity – essential for push messaging in particular – is just one of the differentiators between the use of the DirectTrust network and commercial encrypted email.
The Direct Standard™ grew out of the efforts of a dedicated group of policy people and technologists called the Direct Project which sought to create a simple, yet secure, mechanism for communicating health data. Transactions could flow between systems operating under a “trust community” – a group of participants in exchange that agree to common operating rules and trust principles.
Speaking (somewhat) more technically, Direct exchange uses email internet protocols and a Public Key Infrastructure (PKI) to allow systems to exchange data safely. Messages are pushed from source to destination utilizing the same basic capabilities utilized in email, but with encryption enabled by X.509 Digital Certificates. In Direct exchange, only the intended recipient can decrypt a transmitted message. The only routing that is needed is for the sender (or sending system) to use the Direct Address of the recipient. Commercial email systems may offer encryption, but lack the trust-in-identity features and the built-in-to-systems characteristics that are present in the Direct Standard.
The infrastructure for Direct Secure Messaging is provided by the many Health Information Service Providers (HISPs) accredited by DirectTrust. These companies operate the servers that support the exchange and house the certificates on behalf of their clients and their clients’ users. HISPs augment the capabilities of EHR systems (and other systems) to provide these messaging capabilities. Some EHRs built this HISP capability into their systems.
Foundational to this type of messaging is that each system or individual wanting to exchange on the network must be identity-proofed. This is so senders can know with certainty the identity of the destination server or person, and receivers can know senders are also accurately representing themselves.
In the beginning, “trust” was established by each of the HISPs making agreements with all of the others. With a community of 40 or so HISPs, and with a changing landscape of participants, managing these “one-off” agreements was too difficult and inhibited growth of the network. Agreements and practices varied and there wasn’t a consensus on what standard of care was needed, particularly for identity-proofing. As an outgrowth of the Direct Project, a Rules-of-the-Road workgroup formed to establish consensus expectations for the various players who supported deployment of the Standard. DirectTrust was incorporated as a result of the work of this group. In the next few years, DirectTrust would create the policies and the accreditation programs that would enforce the rules with which network operators must comply.
DirectTrust accredited network operators can play three roles:
- First, HISPs operate messaging servers and safeguard health information, certificates and private keys according to DirectTrust policies.
- Second, Certificate Authorities issue Digital Certificates according to the DirectTrust Certificate Policy, which stipulates (among other things) the level of identity assurance expected.
- Third, Registration Authorities identity-proof users and systems (at the prescribed assurance level) prior to the certificates being issued.
DirectTrust Accreditation of these three network operator roles is the foundation of our trust framework. All of the certificates “chain” to a trust anchor in the DirectTrust Accredited Trust Anchor Bundle. Inclusion in the bundle requires that a HISP complies with all policies.
Before a message can be sent in the DirectTrust network, the sending process will be able to “discover” the certificate that is bound to the Direct address of the receiver and can check that it chains to an anchor in the bundle and is therefore “trusted”. Then, the sending HISP will encrypt the message using the public key of the receiver and digitally sign it with their own private key. In this way, every recipient has digital verification of the sender’s identity. This makes some of the most common ways of hacking such traffic (“spoofing” or “man-in-the-middle attacks”) impossible.
As this demonstrates, trust-in-identity begins with identity-proofing, but does not end there. The use of cryptographic means and audited processes to harden systems so that misrepresentation and fraud are minimized is also essential. Some have referred to the legal rules that participants in a trust community agree to follow as the “trust framework”. The common technical and cryptographic elements in use by all participants in such a community can be called a “trust fabric”. Both components are fundamental requirements not just for Direct Secure Messaging, but for all communication of sensitive or confidential information on the internet.
This post is part of a series examining trust-in-identity. Join us for the next post where we examine why regular email and instant messaging cannot be trusted and why trust is so important for communication and exchange.