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.
Trust
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 DirectTrust.org.