Skip to content. Skip to main navigation.


  • April 10 2012

    The Direct Project: A modular view - part two

    In part one of this series, I dissected the Direct Project into discrete modules and provided a relatively in-depth view of the backbone transport and message gateway. In this post, I'll dive into the lifeblood of Direct: security and trust.

    Security and Trust

    The core value proposition of Direct is securely transporting authenticated messages between mutually trusted parties, and implicitly describes a component called the security and trust agent. This agent is responsible for implementing security and trust specifications.

    Message Security

    First, messages must be delivered securely, quite a general and ambiguous statement. In Direct, a secure message is one that has been encrypted and signed. Because Direct uses MIME messages as its payload over SMTP, it needs a way to secure the message but remain in compliance with MIME standards. Fortunately, a MIME extension called secure MIME (S/MIME) exists and is defined by RFC5751. S/MIME has attributes that cover both security and message authenticity, but I'll focus first on security.

    Direct specifications state that all messages on the backbone protocol have a MIME content type of application/pkcs7-mime – the content type of an encrypted S/MIME message. The security and trust agent is responsible for encrypting and decrypting all outgoing and incoming messages, respectively, using PKI and X509 certificates. For the purpose of S/MIME, certificates contain the keys that are used to encrypt and decrypt messages.

    Every endpoint in Direct is associated with one or more X509 certificates. When a message is addressed to a recipient, the message is encrypted using the recipient's public key contained in the associated certificate using S/MIME standards. This is an oversimplification of the process, but the result is an S/MIME-encrypted message envelope that contains the original message. The encrypted payload is then sent to the recipient's HISP using SMTP over public networks. When the recipient's HISP receives the message, the recipient's certificate is obtained along with its corresponding private key. The message is then decrypted, and the original message is extracted. The asymmetric attributes of the public and private keys ensure that only the recipient's private key can decrypt the message.

    Why PKI and S/MIME instead of other cryptography technologies (like TLS) over SMTP? The most notable reason is that although SMTP supports a secure version of the protocol, most public SMTP servers do not use or require it. Direct is all about ubiquitous support. Almost every public SMTP server supports transport over a non-encrypted channel. Because the line is unencrypted, however, the message payload itself must be encrypted to protect against eavesdropping and ensure message integrity, and S/MIME provides both of these functions.

    Message Authentication

    In Direct, message authentication equates to asserting the authenticity of the message, meaning the source address of the message is the true source of the message. When a message is received by a HISP from a remote HISP, it inspects certain headers in the SMTP envelope to determine the source address in question. There are well known methods where an email client or server can spoof a message's source, and message authenticity gives a level of assurance that the message is indeed from the real person or system that attests to creating the message. Message authenticity is another feature provided by S/MIME using a concept called a message signature.

    In S/MIME, a message signature is a blob of bits that can validate the authenticity of the message. Without going too deep, the message signature is created by generating a cryptographic hash, or digest, of the original message. The digest is just a fixed-length sequence of numbers or alpha numeric characters that, in theory, uniquely represent the message. Because the digest is a function of the message content, each message generates a unique digest. Saying the digest will be unique for every message is not entirely true, though, practically, the probability of two different messages creating the same digest (called collision) is relatively low. The digest is then encrypted with the sender's private key. When the message is received by the recipient's HISP, the security and trust agent obtains the X509 certificate associated with the sender, decrypts the digest, and validates the message signature. Only the sender's public key will be able to decrypt the digest and validate the signature. A digest is then taken of the original message and compared against the decrypted digest. If the digests match and the signature validated, the message is declared authentic.

    To summarize, message signatures provide two functions:

    • They ensure the message was not tampered with by using a comparison of digests.
    • They ensure the message source is authentic using the public key of the sender's X509 certificate to validate the signature.

    Certificate Discovery

    I have made several references to certificates being "discovered" for encryption, decryption and signature operations. PKI can be difficult to implement, and certificate discovery is just one small piece of the puzzle. There are two use cases of certificate discovery in Direct: private and public discovery. Private discovery refers to accessing a certificate along with its private key and is only applicable to addresses maintained by a HISP. It is up to the HISP to implement proper protection of private keys and the methods to access them. Direct implements a few certificate resolvers for discovering private certificates, but they do not meet policy requirements of legitimate PKIs (more on policy later).

    Public discovery refers to finding certificates that are not managed by the HISP and is a much more interesting problem. Public discovery has three problems to overcome:

    • Where a certificate is stored
    • What protocol to use
    • How to uniquely identify the certificate with a query

    Additionally, a universal discovery method is desirable to reduce variance and ensure interoperability. Because Direct wanted to use existing and ubiquitous standards, DNS using CERT-type records was originally selected as the preferred method. LDAP was added later as a secondary method and standardized by the S&I Framework initiative. HISPs can utilize either DNS or LDAP servers to publish Direct certificates, but they must support both discovery methods from a client perspective.


    Arguably the most important aspect of the security and trust specification is the trust model. The encryption and message signature algorithms ensure a message is securely transported from one location to another without being compromised or tampered with, but what value is a message if you do not trust its contents? In theory, anyone can set up a HISP, create certificates, and claim to have some type of authoritative credential, such as being a covered entity. Message sources may be able to irrefutably attest to their identity assigned to them by their HISP using a certificate, but how does a receiving participant know that they can trust the content of the dialog? In other words, if I receive a message from Dr. Bob, how do I know the public certificate that signed the message actually represents Dr. Bob? The attributes in the certificate say it is Dr. Bob, but is the HISP that gave Dr. Bob that certificate actually trustworthy? What if the Dr. Bob in question is really a malicious hacker who stood up his own HISP to spoof the real Dr. Bob's legitimate healthcare organization?

    The security and trust model allows HISPs to filter and accept messages only from other HISPs that they deem trustworthy. Transitively, a HISP should only allow the creation of addresses for participants that they deem trustworthy. This leads into the subject of identity proofing, certificate policies and PKI trust frameworks. These are outside the scope of the trust model as defined by the applicability statement, but there are efforts in the Direct community solely focused on this topic. However, as a rule of thumb, only HISPs that follow and can prove to abide by good certificate practices and identity proofing procedures should be deemed trustworthy. Trust is not an absolute indicator of truth, but subjective only in how much a recipient wants to trust a sender. In the context of health care data, trust of a message's content can result in a life-changing decision, and in the extreme, a case of life or death.

    The security and trust model provides a great deal of flexibility in determining trust relationships between HISPs and/or individual participants. Because messages are signed using the sender's X509 certificate, PKI algorithms "filter" messages based on entities called trust anchors. Every X509 certificate is issued by an entity called a certificate authority, and a certificate authority can be used to validate the authenticity of the issuer of an X509 certificate. In the simplest case, a certificate authority (CA) is a trust anchor. If a HISP trusts a particular trust anchor, then all certificates created by that anchor are considered to be trusted. A HISP's filter may become more granular from this point using whitelists and blacklists.

    Depending on the PKI implementation of a HISP, a trust anchor may be assigned to represent an entire HISP, but generally a trust anchor is created per email domain hosted by a HISP. Technically, setting up a trust relationship between HISPs is as simple as the HISPs exchanging trust anchors in a secure manner and adding the anchors to their trust stores. A trust store is just a set of trust anchors that a HISP has deemed trustworthy. In practice, the process of establishing trust between HISPs is much more complex and requires due diligence in determining if a HISP is legitimate and is following required policies and procedures. Applying this to messages, any message signed with a certificate that is issued by a trusted anchor is deemed trusted.

    Putting It Together

    A little order is now called for. Direct uses the following simplified pseudo algorithm when sending messages:

    • The message is validated for all proper MIME content.
    • The sender's private key is discovered, and a message signature is generated.
    • The recipient's or recipients' certificates are discovered and the message and signature are encrypted into an S/MIME envelope.
    • The encrypted message is sent to the recipients' HISP(s) using the message gateway.

    Conversely, Direct uses the following simplified pseudo algorithm when receiving messages:

    • The encrypted message is received by the message gateway and handed off to the security and trust agent.
    • The recipient's or recipients' private keys are discovered, and the message is decrypted.
    • The sender's certificate is discovered, and the message signature is verified.
    • The sender's certificate is checked against the trust store to ensure the sender is from a trusted HISP.

    A failure in any of the steps results in the message being discarded, and an appropriate action is taken by the sending or receiving HISP.

    In the next and final part of this series, I will cover the edge protocols and clients and give a brief overview of policies and governance.

    The first part of this series discusses Direct's backbone transport and message gateway.

    Greg is a director and principal architect at Cerner. He’s responsible for the HISP architecture of the Cerner Direct solution and remains actively engaged in development/coding and mentoring new software engineers and upcoming architects. Also responsible for the Direct Project Java reference implementation architecture and a primary source contributor, Greg serves as co-chair for the Direct reference implementation workgroup and is a contributing member of ONC's Standards and Interoperability (S and I) Framework initiative and

    • Comments (0) | Rating: 0/5
  • Comment
  • Bookmark
  • Print