Keywords

15.1 Introduction

This paper is based in part on a paper published by WCECS [1]. Asynchronous messaging describes communication that takes place between one or more applications or systems, in which the sender does not receive feedback from the receiver during transmission of a message. This is in contrast to synchronous communication, in which the sender of a message waits for acknowledgement or a response from the receiver before completing the transmission.

There is no assumption about which layers asynchronous and synchronous communication take place in or how these relate to each other. It is possible to implement synchronous communication using an asynchronous messaging service or an asynchronous messaging service using synchronous communication channels. In practice, asynchronous messaging often uses an underlying synchronous channel.

A common asynchronous messaging design involves one system placing a message in a message queue and continuing its processing. At the completion of message transmission, the sender does not know when or whether the receiver received it. The message queuing system is responsible for delivering the message to the recipient. Some systems use two or more queues or intermediaries.

15.1.1 Some Advantages of Asynchronous Communication

Asynchronous messaging solves the problem of intermittent connectivity. If the receiving equipment fails or is unavailable, the message remains in a message queue and is delivered after the failure is corrected. This is especially useful for transmission of large data files, in which failures are more likely and retransmissions more costly.

An asynchronous messaging system with built-in intelligence may transform the content and/or format of the message automatically to conform to the receiving system’s requirements or needed protocol but still successfully deliver the message to the recipient. This intelligence is used to provide a higher level of understanding of the content, which allows translation into other formats and protocols. Complicated transformations are better suited to asynchronous communication than synchronous communication because they may increase latency and cause connectivity problems or other underlying protocol failures for synchronous systems.

15.1.2 Some Disadvantages of Asynchronous Communication

The disadvantages of asynchronous messaging include the additional component of a message broker or transfer agent to ensure the message is received. This may affect both performance and reliability. Another disadvantage is the response time, which may be inconvenient and not consistent with normal dialog communication.

15.2 High Assurance Issues

There are several high assurance security principles that must be maintained for asynchronous communication.

  1. 1.

    Know the players—in synchronous (two way communication) this is done by enforcing bi-lateral end-to-end authentication. For synchronous communication Enterprise Level Security the certificate is PKI.

  2. 2.

    Maintain Confidentiality—in synchronous Communications this entails end-to-end encryption using Transport Layer Security (TLS).

  3. 3.

    Enforce Access and Privilege—in synchronous (two way communication) this is done by the use of an authorization credential. For synchronous communication Enterprise Level Security the certificate is SAML.

  4. 4.

    Maintain Integrity—know that you received exactly what was sent—know that content has not been modified—For synchronous communication and enterprise level end-to-end TLS encryption the use of message authentication codes is enforced. Packages are signed and signatures are verified and validated. Credentials of signers are verified and validated.

15.3 Prior Work

A proliferation of standards [2] for asynchronous messaging has caused interoperability problems, with each major vendor having its own implementations, interface, and management tools. Java EE systems are not interoperable, and Microsoft’s MSMQ (Microsoft Message Queuing) does not support Java EE. Many of these are reviewed and compared in [3]. A few of the numerous standard protocols used for asynchronous communication as defined in the Internet Assigned Numbers Authority (IANA) protocol registries [4] are in the Table 15.1.

Table 15.1 Messaging ports
Full size table

15.3.1 Java Standard Messaging Protocol

Java Messaging System (JMS) is a message-oriented middleware API for communication between Java clients. It is part of the Java Platform Enterprise Edition. It supports point-to-point communication as well as publish-subscribe.

15.3.2 De-Facto Standard Microsoft Message Queuing

Microsoft Message Queuing (MSMQ) allows applications running on separate servers/processes to communicate in a failsafe manner. A queue is a temporary storage location from which messages can be sent and received reliably, as and when conditions permit. This enables communication across networks and between computers running Windows, which may not always be connected. By contrast, sockets and other network protocols require permanent direct connections.

15.3.3 Open Source Messaging Protocols

In addition to Java and Microsoft, different open source solutions exist [2]. RabbitMQ is an open source messaging solution that runs on multiple platforms and multiple languages. It implements Advanced Message Queueing Protocol (AMQP), in which messages are queued on a central node before being sent to clients. It is easy to deploy, but having all traffic pass through a single central node can hinder scalability.

ZeroMQ is another cross-platform, cross-language messaging solution that can use different carrier protocols to send messages. It can support publish-subscribe, push-pull, and router-dealer communication patterns. It can be more difficult to set up, but it provides more control and granularity at the lower levels to tune performance.

ActiveMQ is a compromise between the ease of use of Rabbit MQ and the performance of ZeroMQ. All three support multiple platforms and have client APIs for C++, Java,.Net, Python, and others. They also have documentation and active community support. There are many other implementations, including Sparrow, Starling, Kestrel, Beanstalkd, Amazon Simple Queue Service (SQS), Kafka, Eagle MQ, and IronMQ.

15.3.4 Emerging Standard Advanced Message Queuing Protocol

Advanced Message Queuing Protocol (AMQP) is an open standard application layer protocol for message-oriented middleware [5]. It is an emerging technology addressing the standardization problem. Implementations are interoperable. It includes flexible routing and common message paradigms like publish/subscribe, point-to-point, request-response, and fan-out.

The defining features of AMQP are message orientation, queuing, routing (including point-to-point and publish-and-subscribe), reliability, and security. AMQP mandates the behavior of the messaging provider and client to the extent that implementations from different vendors are truly interoperable, in the same way as SMTP, HTTP, FTP, and others have created interoperable systems.

15.4 Asynchronous Messaging Security

Asynchronous messaging can provide authentication of the sender and receiver identities and the integrity and confidentiality of the message content if the holder of the queue is trusted. One key challenge in asynchronous messaging systems is that a third party is often involved in the transaction, which may or may not be trusted to speak for the sending or receiving entities or view or modify content in transit. As a result, security models often require a trusted third party, which restricts deployment options. In contrast, synchronous web traffic relies on routers and other infrastructure to deliver messages, but the use of TLS provides end-to-end security without the need to trust these intermediate nodes.

15.4.1 Security for Server Brokered Invocation

Server brokered invocation uses web server middleware to manage message queues. The sender and receiver both communicate directly through secure synchronous channels to the server to send and receive messages. This model is shown in Fig. 15.1. Asynchronous message security must be from sender to receiver, not just from sender to server and server to receiver. The latter fails to provide end-to-end authentication, integrity, and confidentiality, which are required for a high assurance environment.

Fig. 15.1
figure 1

Security considerations for server brokered invocation

Full size image

In order for the parties involved in the transaction to provide accountability, integrity, and confidentiality, the service requester must authenticate itself to the receiver, encrypt the message so only the service provider can receive this message, and provide verifiable integrity checks on the full message content. The service provider must confirm that the message is from a known identity, decrypt the content with a valid key, and verify the integrity checks before that entity can take action on the message.

This is accomplished by invoking two cryptographic techniques. The first is the use of a digital signature by the sender. When the message signature is verified, the service provider knows the identity of the sender and that the content has not been altered by another entity after it was signed. The second is the encryption of the message using the public key of the service provider. This requires that the requester know the public key of the target. A response to the requester must similarly be signed and encrypted using the public key of the requester.

The use of asymmetric encryption is paired with more efficient symmetric encryption, where content is encrypted with a random symmetric key, which is itself encrypted using the receiver’s public key. Additional security can be provided by message expiration deadlines within queues and central auditing of all messages sent and received.

15.4.2 Security for Publish Subscribe Systems

In a Publish Subscribe System (PSS) the queue server acts as an intermediary between sender and receiver to manage many-to-many instead of just many-to-one communications. Senders and receivers communicate with the PSS through a secure synchronous channel. The PSS collects messages and makes them available to entities based on subscriptions. This model is shown in Fig. 15.2.

Fig. 15.2
figure 2

Publish-subscribe push model

Full size image

The PSS is an active entity and registered in the Enterprise Service Directory. Active entities act on their own behalf and are not a proxy. To preserve the end-to-end accountability chain for messages, the original publisher signs the message. However, unlike server-brokered invocation, no single public key can be used for all potential receivers. One solution to address this is for the PSS to encrypt the content to the receivers. The sender’s signature remains intact, preserving integrity, but end-to-end confidentiality is not guaranteed.

A PSS may use the web server broker as shown in Fig. 15.3. The web server broker is used only for notification messages, so it does not require security like the main channel. The transmission of the actual message is still done through the secure synchronous channel. The storage queue must be encrypted using the PSS’s public key. This is piecemeal confidentiality, because the sender encrypts to the PSS, and the PSS encrypts to the receiver. This relies on trust of the PSS.

Fig. 15.3
figure 3

Publish-subscribe pull model

Full size image

15.5 Pss Rock and Jewel

The following is an approach developed to maintain high security assurances with the use of an untrusted PSS. In this formulation, the sender and receiver maintain end-to-end security because the PSS is unable to impersonate either endpoint or view or modify the content. The key concepts are the use of “rocks” and “jewels” to provide security guarantees. The “rocks” are encrypted content blocks, and the “jewels” are the decryption keys for these rocks, encrypted using public keys for the intended recipients.

15.5.1 Claims for Targeted Content (PSS)

After authentication through TLS v1.2 or later versions and authorization based on SAML claims, the sender accesses PSS services. The PSS will offer either publish or retrieve based on the values in the SAML content claim. If there are no SAML content claims, the subscriber will only receive basic services based on identity.

Publishing of content for a targeted list, as used by software publishers, is based upon registered delivery. The targeted list requires the following steps:

  1. 0.

    Publisher does a bi-lateral authentication and establishes a TLS 1.2 session with SAML authorizations for session establishment with the PSS. The PSS identifies him as a publisher. He may also be a subscriber, or he may be modifying a previous publish or he may be retrieving messages, so the PSS ascertains the reason for his session.

  2. 1.

    Content to be published will be digitally signed by the publisher.

  3. 2.

    The publisher will generate an AES-256 encryption key and encrypt the content.

  4. 3.

    Encrypted Content is placed in a queue based on an access claim and list name. The publisher will keep such lists. The PSS will assist in developing claims.

  5. 4.

    Access is based on a list of targets and claims. A target may be an individual subscriber or a group queue. The publisher may establish a new queue based on claims and the list for retrieval. This new queue requires an identity and a claims establishment for retrieval (see 3 above). Additional content may be published as needed.

  6. 5.

    Expiration time of targeted content is determined by the publisher or the messaging system.

  7. 6.

    The PSS will provide PKI certificates for each of the targets for the content (if the publisher needs them and they are already registered in the PSS). The publisher should check all certificates on the list for currency and revocation. If invalid certificates are discovered, the list should be pruned.

  8. 7.

    The publisher will prepare encrypted key sets (jewels) by wrapping the AES encryption key in each target’s public key.

  9. 8.

    The publisher will publish the encrypted material (rocks) and the encrypted key sets (jewels) for the targets. The PSS will link these to the encrypted material and the target(s).

  10. 9.

    The PSS will provide notification, if desired, to the subscriber list. The PSS will assist with message selection and target details, or the publisher may script his own.

  11. 10.

    The publisher closes the session.

Note: the target must be on the list and have authorization to view content. The steps are shown in Fig. 15.4.

Fig. 15.4
figure 4

Publishing of targeted content

Full size image

15.5.2 Retrieving Content for Known Claimants

Retrieval of targeted content may be achieved without the targeted identities contacting the publisher. The following steps are followed:

  1. 0.

    Subscriber does a full bi-lateral authentication using TLS 1.2 with SAML authorizations for session establishment with the PSS. The claims identify him as a subscriber. He may also be a publisher, so the PSS ascertains the reason for his session.

  2. 1.

    The PSS offers subscriber content available for the claims in queues for which the claimant has an encrypted key available, and the subscriber chooses and retrieves the encrypted content (rock).

  3. 2.

    The PSS provides the encrypted key package (jewel).

  4. 3.

    The PSS notifies the publisher. When expiration time occurs, the server deletes the packages and notifies the publisher which packages were not delivered. The publisher may republish to that list if desired.

  5. 4.

    The subscriber decrypts the content encryption key (jewel) with his private key and accesses the content (rock) decryption key.

  6. 5.

    The subscriber decrypts the content.

  7. 6.

    The subscriber verifies and validates signature.

  8. 7.

    The subscriber closes the session or retrieves additional content.

Note: the target must be on the list and have a content claim. The steps are shown in Fig. 15.5.

Fig. 15.5
figure 5

Subscriber retrieval(s) from a known target

Full size image

15.5.3 Retrieving Content for Unknown Claimants

Unknown claimants cannot retrieve the content until registering with the content provider. The steps in that process are described below:

  1. 0.

    The subscriber does a full bi-lateral authentication TLS 1.2 with SAML authorizations for session establishment with the PSS. The authentication identifies him as a subscriber. He may also be a publisher, so the PSS ascertains the reason for his session.

  2. 1.

    The PSS checks the content claims available and the subscriber chooses and retrieves the content for which full packages exist.

  3. 2.

    For the unknown list, the encrypted key package is not available. The PSS replies “the publisher has no record of your membership. I need to contact the publisher. I will send you a notice if the publisher agrees.”

  4. 3.

    The PSS stores a message for the publisher and notifies him that he has a message.

  5. 4.

    The PSS and subscriber await publisher action.

  6. 5.

    The subscriber closes the session or retrieves additional content.

Note: the target has a content claim, but is not on the list. The steps are shown in the Fig. 15.6.

Fig. 15.6
figure 6

Subscriber retrieval(s) from an unknown target

Full size image

15.5.4 Adjusting Publishing Targets (Untrusted PSS)

Publishers must add receivers to the distribution list before they can be provided messages. The steps in that process are described below:

  1. 0.

    The publisher does a full bi-lateral authentication through TLS 1.2 with SAML authorizations for session establishment with the PSS. The authorization process identifies him as a publisher. He may also be a subscriber, or he may be modifying a previous publish or he may be retrieving messages, so the PSS ascertains the reason for his session.

  2. 1.

    Retrieve messages. These are retrieved one by one with action taken (or not) and deletion of the message.

    • The publisher asks for credentials of previously unknown claimants he wishes to add to his lists.

      • The publisher may add claimants to the publisher’s list

      • The publisher computes jewels.

      • The publisher posts jewels.

      • The PSS notifies the subscriber that he has content available. This makes the entity a known target and Sect. 15.5.2 applies.

    • PSS provides messages to requester.

  3. 2.

    The publisher closes the session.

The steps are shown in Fig. 15.7.

Fig. 15.7
figure 7

Publisher message retrieval and subsequent actions

Full size image

15.5.5 Distribution of Burdens

Several burdens are incurred in this high security mode. The publisher has to do key management and list maintenance. The publisher has to frequently contact the PSS for messages for publishers. The PSS must maintain message queues for publishers. The PSS has to keep a linked wrapped key package by target with published content. The PSS is responsible for additional notifications that are sent out. The unknown claimant may have a delay in receiving content to which he has claims.

15.6 Summary

We have reviewed the basic approaches to asynchronous communication in computing environments. We have also described high assurance approaches to the process. The proliferation of standards in this area has created a problem with high assurance. In many instances the high assurance elements require additional steps in the asynchronous process, but they provide a way to proceed when some intermediaries are untrusted. This work is part of a body of work for high assurance enterprise computing using web services. Elements of this work are described in [6–19].