Skip to main content

Client Server Design Patterns

Introduction​

MTE Web is a breakthrough technology that completely protects information between endpoints from any sort of intrusion or compromise. When used in a client server application, certain design patterns may be utilized based on your specific requirements. This document describes several alternatives that can assist you in building your architecture.

tip

Eclypses has created an implementation helper called Relay that makes client server implementations trivial. This is by far the easiest way to get MTE implemented into a web environment and is what Eclypses recommends using. If a web implementation needs more control or customization then see the detailed best practices below.

Terminology​

First, here is a short list of definitions that are used throughout this document.

  • Endpoint: A computing device or system that either creates or consumes information that must be transmitted between them for inspection or processing. In a client/server application these are typically:
    • Browser Based App A web browser based app using either traditional architecture, or Single Page (SPA).
    • Mobile App An application written for iOS, Android, or other mobile platform.
    • Relay Server A server that forwards requests on to another server or service.
    • MTE Relay A plug-and-play implementation helper library that takes care of MTE implementation for you.
    • Processing Server A server application that processes requests from a client.
  • Conversation The exchange of information in a unique client / server encounter between a distinct pair of endpoints. This starts with initial contact and ends after either a specified time, or after the client disconnects.
  • Transmission A single one-way exchange between two endpoints.
  • Pairing: The process that links two endpoints and ensures that they are in sync.
  • Entropy: A truly random set of byte values used in the endpoint pairing process. The more random this is, the better level of security you will encounter. This is a private value and should be guarded like an encryption key.
  • Nonce: A numeric value that adds additional instantiation data to change the MTE starting point. This value should not be repeated and does not have to be unique, but uniqueness adds to the security.
  • Personalization Value: A value that adds additional instantiation data to change the MTE starting point.
  • Pairing Values: The Entropy, Nonce, and Personalization Value which are values that create a unique and secure relationship between two MTE endpoints.
  • Initialization: The process of creating an empty MTE instance.
  • Instantiation: The process of instancing up MTE endpoints with the pairing values to create a uniquely paired set of MTEs.
  • Encoder An instance of the MTE that converts clear data into uniquely encoded data.
  • Decoder An instance of the MTE that converts uniquely encoded data into clear data.
  • State: An optional collection of bytes that are saved or restored to re-instantiate MTE to a specific point in operation. This is a private value and should be guarded like an encryption key.
  • Encoding: The process of applying MTE to protect a collection of bytes within a paired endpoint to transmit to another endpoint for Decoding.
  • Decoding: The process of applying MTE to unprotect a collection of bytes from a paired endpoint to allow it to be inspected or processed.

Plug-and-play - MTE Relay Implementation Library​

CONSIDERATIONS NOTE: Pro Less than an hour of implementation NOTE: Con Generic implementation of MTE - one size fits all NOTE: Link to Relay Dev Guide

Conversation Pairing Pattern​

In a conversation based pattern, each conversation is treated as a unique pairing with zero previously maintained knowledge of the endpoints involved in the conversation. The client should initiate the conversation with an authentication request. The data flow is as follows:

  • The end user with the client endpoint starts the application.
  • The client application creates a unique identifying value and some information that can be used as a public key to send to the server. The unique identifying value is used as the Personalization Value.
  • The client requests the server to return some information that it uses as a public key, and a numeric value to use as the Nonce.
  • The server receives the request and does the following:
    • The server generates the Nonce. This is a great job for a two-factor authentication service that will send the nonce over SMS pulling in a separate communication stream to increase authentication and security.
    • The server creates some information that can be used as a public key to return to the client.
    • The server generates a secret value based on the client's public key and its private key that is used for Entropy. This Entropy value should be handled securely as a loss or disclosure of entropy will lead to complete loss of security of MTE.
    • The server uses the Nonce, Entropy and the Personalization Value as the Pairing Values to create an MTE Encoder and an MTE Decoder. It is recommended to alter one of the pairing values between the Encoder and Decoder so they are not the exact same pairing. A simple way to do this is to increment the Nonce for the Encoder on the server and Decoder on the client.
    • Once the pairing process has been successfully executed the Pairing Values should be discarded and over-written in memory (zeroized) to prevent exposure.
    • The server securely saves the initial state of the Encoder and Decoder associated with some identifier for the client (Personalization Value could be a good candidate). State should be handled securely as a loss or disclosure of state will lead to complete loss of security of MTE.
    • The server returns its public key and the Nonce to the client.
  • The client uses the server's public key along with its private key value to generate the same secret value to use as Entropy. This Entropy value should be handled securely as a loss or disclosure of entropy will lead to complete loss of security of MTE.
  • The client uses the returned Nonce, the generated Entropy and the Personalization Value as the Pairing Values to create an MTE Encoder and an MTE Decoder. It is recommended to alter one of the pairing values between the Encoder and Decoder so they are not the exact same pairing. A simple way to do this is to increment the Nonce for the Decoder on the client and Encoder on the server.
  • Once the pairing process has been successfully executed the Pairing Values should be discarded and over-written in memory (zeroized) to prevent exposure.
  • The client may now exchange encoded information with the server by encoding prior to sending the information, and decoding upon retrieval to allow for processing.
  • Prior to encoding or decoding on the server, the state must be restored in the appropriate Encoder or Decoder. This entails retrieving the stored state from the persistent secure store that is associated with the incoming client's transmission. Be careful when handling state as a loss or disclosure of the state will lead to complete loss of security of MTE.
  • After each encoding or decoding the server must save the state so that it can be restored at the next transmission in the conversation.
  • If possible, the client should send a finalization (logout) message to the server so that it can clear its persisted state values.
  • The server should have a reasonable time-out value on its stored state values so that if they are not accessed after a certain time span, they are cleared from whatever persistent secure store they are kept in.
  • If the server receives a request from a client and the specific state cannot be found in its persistent secure store (either it aged out, or there was a problem), the server should notify the client that it must go through the pairing process from the beginning.

Pros of this pattern​

Some of the advantages of this pattern include the following.

  • It requires zero knowledge of the client endpoint by the server.
  • Between conversations, no artifacts are found on any endpoint, which saves memory and storage.
  • A client endpoint intrusion cannot attempt to spoof a user since at the end of each conversation all artifacts are removed.
  • The server does not need to keep information pertaining to registered endpoints, so client maintenance is simplified.

Cons of this pattern​

Some of the disadvantages of this pattern are as follows.

  • For each conversation, prior to using the MTE, the pairing process must take place which involves an extra round-trip.
  • Care must be used in the client application to ensure that once a conversation is finished, all artifacts must be expunged from memory and storage on both the client and server.
  • Timeouts may frustrate the user on the client. If the server clears its state due to a timeout exceeded, the client must re-initiate the conversation.

Device Registration Pattern​

In a Device Registration Pattern there is a data flow that involves capturing some information about a specific endpoint so that state information can be persisted across conversations. Once a device is registered and authenticated, its unique MTE state is persisted in a secure hard store, such as a database, so that upon the next conversation the pairing process can be avoided. State must be stored securely and a loss or disclosure of state will lead to complete loss of security. The data flow is something like this:

  • A client chooses to register their device and / or account.
    • A registration form is presented by the app.
    • The app goes through a pairing process. This could be similar to the conversation pattern using a public key exchange method or it could be done in a more elaborate way since it is only happening once. An example of this could be the Entropy provided via a validation email that the user manually enters and the nonce provided via a two-factor authentication code sent over SMS. This incorporates two other disconnected communications which enhances authentication and security.
      • The Personalization Value is not a one-time unique value, but rather it is a value associated with the specific endpoint and user account (such as a device serial number and/or hash of username and password).
    • If the server finds a state value in its persistent secure store for that specific Personalization Value, the registration attempt returns an error informing the user that the device is already registered. This is important to protect against account takeovers from unauthorized devices that may have the correct credentials (e.g., SIM swap attack)
    • If the server does not find the state values for this endpoint, then it is assumed to be a new registration.
    • The account details are then validated, and if all is well, the server saves the state information in its persistent secure store associated with an endpoint identifier (Personalization Value). The state must be stored securely as a loss or disclosure of state will lead to complete loss of security.
    • If all goes well, the client device must also securely save the state information in a local store. In the case of a browser based client that would probably be an encrypted cookie, but this may be difficult if cookies are cleared (or not allowed) in which case the application may have to require the user to register this browser again.
    • Once the pairing process has been successfully executed the Pairing Values should be discarded and over-written in memory (zeroized) to prevent exposure.
    • If an application requires a re-registration of an endpoint, it may choose to have a different route to the server that follows the conversation pattern described above, but asks the user for some other form of verification such as the answer to a security question. In that case, if the credentials are correct, the state may then be saved on the server associated with the endpoint Personalization Value.
  • Once an endpoint device is registered, the application now uses the saved state to encode and decode all subsequent conversations without the need to pair every time.
  • If the endpoint device is reset, it must be re-registered.

Pros of this pattern​

Some of the advantages of this pattern include the following.

  • An application can ensure that only approved endpoints can access the server / API.
  • The registration process can be enhanced by using a multi factor authentication scheme to allow the server to return the Nonce to the client, thereby increasing registration security.
  • A PIN may be used by the application for initial contact in conversations (secured by the existing MTE) to make the subsequent startup of the application simpler for the user. This PIN can be part of the registration process where the transmission of the PIN is protected by the MTE and the hash of the PIN is stored with the user account information at the server.

Cons of this pattern​

Some of the disadvantages of this pattern are as follows.

  • The registration process can be complex to implement and maintain.
  • User account maintenance at the server is a bit more complex.
  • The secure storage facility at the client endpoint may be troublesome (especially if the client is a browser).
  • The server data structure should allow multiple registered client endpoints per user account.
  • Account maintenance (orphaned endpoints) can be troublesome at the server leading to excess storage requirements.

Conversation Once and Done Pattern​

In a Conversation Once and Done Pattern each conversation is treated as a series of single unique transmissions. The conversation uses the pairing process to establish Entropy and Personalization Value, however MTE state is not saved.

  • The client application makes a first contact using the same process as the conversation pattern.
  • When the server gets this initial request, it encrypts the Entropy and saves it in a persistent secure store associated with the Personalization Value. The entropy value must be stored securely as a loss or disclosure of entropy will lead to complete loss of security.
  • The client also saves the encrypted Entropy and Personalization Value in memory or in a secure storage facility. The entropy value must be stored securely as a loss or disclosure of entropy will lead to complete loss of security.
  • Prior to each transmission, the client does the following:
    • Retrieve the Entropy and Personalization Value from its secure storage.
    • Generate a one time use numeric Nonce value.
    • Instance up a new MTE Encoder.
    • Encode the data.
    • Transmit the encoded data and the Nonce.
    • Clear out the memory associated with the Encoder.
  • Upon receipt of the payload at the server, the server must do the following:
    • Retrieve the Entropy and Personalization Value from its secure storage.
    • Instance up a new MTE Decoder with the stored Entropy and Personalization Value and the received Nonce.
    • Decode the data.
    • Clear out the memory associated with the Decoder.
  • For the duration of this conversation, the process described above should continue changing the Nonce value with each transmission so that the MTE never starts in the same place.
  • At the end of the conversation (time out or logoff), the pairing values must be cleared from their storage at both the client and the server.

Pros of this pattern​

Some of the advantages of this pattern include the following.

  • Simpler process to implement and maintain since each conversation is unique, and each transmission within a conversation is unique.
  • May be combined with features of the registration process in that the Personalization Value may be permanently associated with the client endpoint or account.
  • In a busy client / server application there is less pressure on server memory for large pools of connected clients.

Cons of this pattern​

Some of the disadvantages of this pattern are as follows.

  • In a busy client / server environment there is more pressure on the server's CPU cycles due to the frequent instantiation of encoders and decoders.
  • Logic on the server must prevent the saved pairing values from existing in perpetuity. A timeout, or a sweep mechanism must ensure that these values have a limited lifetime.

Transmission Once and Done Pattern​

In a Transmission Once and Done Pattern each transmission is treated as a completely unique and isolated exchange. Prior to each transmission, the Pairing process must succeed.

  • The client application captures some data to send to the server.
  • The client initiates a pairing process with the server.
  • The server instantiates an MTE decoder and securely stores (in cache) the state of the decoder associated with the incoming client. The state must be handled securely as a loss or disclosure of the state will lead to complete loss of security.
  • The client instantiates an MTE encoder with the pairing values and encodes some data.
  • The client clears out its memory of both the pairing values and the encoder.
  • The client sends the encoded packet to the server.
  • The server decodes the incoming packet.
  • The server clears its cache of all remnants (the cached state as well as the actual decoder).
  • Each subsequent transmission follows this same process.

Pros of this pattern​

Some of the advantages of this pattern include the following.

  • Simplest process for a client application.
  • Requires no preregistration.
  • Does not keep any artifacts on either client or server side.
  • Extremely secure on the client.

Cons of this pattern​

Some of the disadvantages of this pattern are as follows.

  • Only viable for a one-way conversation since the server cannot initiate a pairing with a client (websockets are possible, but very complex).
  • Requires an additional round trip for every transmission.
  • Because of the additional round trip, there is an elevated chance of compromise for the pairing process.
  • If the MTE Decoder state is securely stored in cache at the server, the server must either be a single source, or sticky sessions must be enforced.
  • In a busy client / server environment there is more pressure on the server's CPU cycles due to the frequent instantiation of decoders.

Conclusion​

These are some patterns that may be used to incorporate the MTE within your client server environment. You may decide to use features of all of these patterns or devise your own, the MTE is quite flexible and the only requirements are:

  • Ensure that pairing is unique between endpoints to avoid cross-contamination.
  • Ensure that if a server farm is part of your architecture, the securely stored information (State or Pair Values) can be retrieved by all servers in the farm.
  • Ensure that the servers have a way of identifying which client they are conversing with (Personalization Value is a good candidate for that).
  • Ensure that any information (State or Pair Values) stored on any endpoint is done in a secure fashion.