Skip to main content

Best Practices

Introduction​

Congratulations, you have selected to implement the most secure method for exchanging information between two endpoints - the Eclypses MTE. Before you start, there are some things you need to consider ensuring that your system is as secure as you need. This document serves as a roadmap to assist you in that implementation.

Terminology​

Let us first define a few common terms.

  • Endpoint: A computing device or system that either creates or consumes information that must be transmitted between them for inspection or processing.
  • 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. A great nonce is a timestamp.
  • 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.
  • State: An optional collection of bytes that are saved or restored to re-instantiate MTE to a specific point in operation.
  • 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.

Questions you must answer

The following questions must be considered as you begin.

What is my overall architecture?​

The MTE behaves exactly the same regardless of your technology or architecture, however, you must take special considerations to maintain State based on your architecture.

Point to Point​

The most basic architecture is a single endpoint that communicates with one and only one other endpoint. An example of this might be a sensor communicating with a control. Only one sensor emits a value, it is protected by the MTE and the control that receives it acts on the information received. This is simple as once you have paired, the MTE stays in memory and you never have to re-instantiate it with State.

Many to One​

If you have a client application such as an iOS, Android, Browser, or other program that is distributed to many endpoints, yet it sends its information to a single server for processing, then you must consider managing state for each connected endpoint. Since the server is not in control of the order or frequency of the transmissions from the client, it must be able to identify which endpoint is the origin of the incoming message. After each message is encoded or decoded, the state must be persisted for use in the next encounter with the paired endpoint. The MTE can handle asynchronous requests at the server from any endpoint by utilizing the sequencing verifier and configuring it correctly.

One to Many​

Similar to many to one, a single endpoint may wish to broadcast messages to multiple endpoints. A prime example of this would be a mesh network of sensors that has one master node for orchestrating communication to a server. In this situation each slave node would have an MTE decoder instance that is exactly the same. This way the Master node could forward any message it received from the server to all the slave nodes and only must encode it once. The master node and the server would have a unique MTE pairing and the master node would be the only endpoint that could communicate with the server.

What technologies are my endpoints?​

The MTE is available in the following technologies and can be included as either a dynamic library or a static library to link into your application. Language interfaces are provided to hide many low-level details and to allow a consistent interface to an application developer. These language interfaces are provided as source code so they can be fine-tuned to your specific application. Please refer to the MTE Developers Guides for the specifics of each technology. There are five developer guides, one for the core MTE, one for the Fixed-Length add-on, one for the Managed Key Encryption add-on, and one for ECDH and Kyber add-ons. Each of the Developers guides include a chapter specific to each supported language and all four are included in the MTE SDK within the docs folder. It is important to understand the entirety of the core guide before moving on to any of the add-on guides. The underlying MTE works the same regardless of the technology, so mixed platforms for endpoints are fully supported.

  • C: The base library is written in a combination of C and Assembly, and a pure C language wrapper is available that handles memory management.
  • C++: A C++ language wrapper is available that takes advantage of some object-oriented features.
  • C#: A C# language wrapper is available for use with .Net. Additionally, a NuGet package is also available.
  • Java: A java language wrapper is available for systems that require it.
  • WASM: A WASM object and corresponding JavaScript and Typescript wrappers are available for use in Browser based applications or Node servers. Additionally, an NPM package is also available.
  • Go: A Go language wrapper is available for systems that require that language.
  • Python: A Python language wrapper is available for systems that require that language.
  • Objective C: An Objective C language wrapper is available for systems that require that language.
  • Swift: A Swift language wrapper is available for systems that require that language.
  • Others: Since the MTE is available as a static or dynamic library, other language wrappers may be included in the future.

What hardware / OS are my endpoints?​

The MTE is built and tested on the following hardware platforms. The language wrappers (as detailed above) may or may not be available on a specific OS, so if in doubt, please contact Eclypses tech support.

  • Desktop and Server (e.g., Linux, Mac, Windows)
  • Mobile Devices (e.g., Android, iPhone)
  • Single-board computers (e.g., Raspberry Pi, Rock64, MIPS)
  • System on chip (e.g., ESP32)

Basic Process

Now that the architecture and environment have been established the following process should be followed. For purposes of this section, we should consider the two endpoints as the Transmitter and the Receiver. Any endpoint may take on both roles, but it is easier to think about them as a one-way conversation.

Pairing​

The specific process of pairing is implementation dependent and highly specific to the systems in question.

Establish pairing values​

The only requirement from the MTE is that the three Pairing Values (entropy, nonce, and personalization value) match on the two endpoints (transmitter and receiver) that wish to communicate. How these values are established is up to the implementing developer, but all security considerations should be observed during their creation. Eclypses can provide recommendations and examples for how this process could look for your specific environment if needed.

Create MTE instances and instantiate them​

Now that the Pairing Values have been established, they need to be known by both the Transmitter and Receiver. How this information is known by each endpoint or exchanged is up to the implementing developer but again Eclypses can provide guidance. On the transmitter an MTE Encoder needs to be created and instantiated with the three Pairing Values. On the Receiver an MTE Decoder needs to be created and instantiated with the three Pairing Values. Once the pairing process has been successfully executed the Pairing Values should be discarded and over-written in memory (zeroized) to prevent exposure.

Exchanging Information​

Once the MTE pairing has been established you are ready to begin exchanging information.

Transmitter​

  • Gather the information you wish to send.
  • Encode the information with MTE.
  • Send the resulting MTE packet to the Receiver.

Receiver​

  • Accept the information from the Transmitter.
  • Decode the incoming MTE packet.
  • Inspect or process the data - it is now in the clear.
  • Wait for the next transmission and do it all again.

Security Considerations

The following are some considerations your application should use to ensure the best security.

Choose your options wisely.​

  • Deterministic Random Bit Generator (DRBG) - These cryptographic modules are the heart of the MTE technology and are what produce the random bits the MTE utilizes. Determining which DRBG to use depends on your security requirements and the hardware within your endpoints. You must choose if you would like 128bit, 192bit, or 256bit security strength and then whether you want the generating algorithm to be AES or SHA based. The MTE can take advantage of hardware accelerators within endpoints so knowing if your endpoints have such capabilities can be crucial for knowing which algorithm to choose.
  • Cipher - These cryptographic algorithms are used by the Managed Key Encryption (MKE) add-on to encrypt and decrypt pieces of data. Choosing which one to use depends on the level of security you desire for the system. The MKE offers AES algorithms of the following security strengths 128bit, 192bit, or 256bit, each having three different modes of operation to choose from ECB, CBC, or CTR. Eclypses always suggests using the most secure option that your system allows.
  • Hash - The hash functions inside of the MTE are used for various authentication tasks and should be chosen based on the level of authentication you desire within your system. The algorithms available from least to most authentication are SHA1, SHA256, and SHA512. CRC32 is also available for non-cryptographic authentication if SHA is not practical for the system in question.
  • Token size - When using the core MTE to secure data, this value determines the size of the replacement value that will substitute each byte of a sensitive piece of data. The increased token size also increases the security of a communication and the overall resilience of the system, but at the cost of message size. Eclypses recommends using the largest token size practical for the application, up to the security strength of the DRBG.
  • Sequence Verification - This option allows the MTE to handle dropped or out of order packets and should be used if you anticipate either of these happening. If you can count on synchronous transmissions, use a positive integer for the sequence window. In this forward-only mode of sequencing, the MTE can skip the dropped, hijacked, or otherwise missing message and decode the next packet it receives (if it has a sequence integer within the set window). If you are expecting asynchronous requests from your Transmitter, or otherwise cannot ensure that transmissions will arrive in the same order that they were created, use a negative value for your sequence window. This sets up async sequencing mode allowing packets that have a sequence integer within the window to be decoded in any order. For either mode of sequencing to work you must ensure that all MTE packets are the exact same size. When using MTE an easy way to ensure this is by using the fixed-length add-on. MKE takes care of this issue inherently and therefore does not need special consideration.
  • Timestamp Verification - This option will include a timestamp in every MTE packet that lets the decoder determine if the packet is still valid. In scenarios where transmissions are time sensitive, and their contents should be ignored after a certain period of time then this option should be used. For this option to be effective you need to be sure that your Transmitter and Receiver can both obtain the same consistent time value. Use Timestamp verification to ensure that messages are not held hostage by Man-in-the-middle attack (MITM) and released later. Time sensitive exchanges should use this capability if the hardware can support reasonably synced timestamps.
  • Checksum Verification - This option will include a checksum of the MTE packet within each transmission. This is to protect against any injection or packet manipulation that may get through the MTE decode function. This option is highly beneficial when using smaller token sizes, adding an extra level of authentication since smaller tokens have less resilience.
  • Fast Crypto - This option allows the MTE to take advantage of hardware implementations of the various algorithms MTE utilizes, known as Processor Algorithm Acceleration (PAA). Fast crypto should be utilized whenever it can to improve the efficiency and latency of the MTE technology, but resource constrained devices may want to turn this feature off to reduce library size. It is not possible for the MTE to evaluate if PAA exists in all situations (e.g., Android) and it is up to the application developer to ensure that they exist and are accessible before turning on Fast Crypto.

Use a cryptographically secure algorithm to generate Entropy.​

This only needs to happen when two endpoints pair but Entropy creation should result in a truly random value. There are limitless ways to generate entropy and pair two endpoints, the process is highly specific to the system in question. Consider the following examples when considering how your system will generate entropy and pair its endpoints.

Devices​

In device situations (e.g., key fob, IoT sensor) a Random Number Generator (RNG) may be used. Eclypses provides a Random Number Add-on. Then both endpoints may be setup simultaneously or the value could be burned into the device at manufacture time and supplied to the other endpoint (e.g., car, server) when the device is deployed.

Zero-knowledge​

In on-demand zero-knowledge pairings (e.g., web, mobile) algorithms such as Elliptical Curve Diffie Hellman (ECDH) and Crystals-Kyber are good candidates. To ease the effort and increase consistency across languages, Eclypses provides an ECDH Add-on and a Kyber Add-on for these situations.

Never keep secret information any longer than necessary.​

Once an endpoint is paired, the Entropy, Nonce, and possibly the Personalization Value should be cleared out of memory. Also, if your technology allows the over-writing of memory, do so with binary zeroes. To properly achieve zeroization the pairing information should be held in byte arrays to allow more control, since strings cannot be deterministically zeroized in many languages.

Only store State if required​

If you are in a Point-to-Point architecture, you may not need to store State since your endpoint is only paired with a single partner.

Encrypt MTE State and Entropy​

If you are managing multiple transmitting endpoints, you must store the State and associate it with the Transmitter, since the re-instantiation of the MTE from State allows for subsequent processing. If you are storing the State in a database or Memcache, this must be done in a secure way and encrypting prior to storage and decrypting it upon retrieval is a good way to achieve that. If this is a Web or API Receiver consider time-bombing the stored State and then if a subsequent request comes from the same Endpoint force a re-pairing process. MTE state and Entropy must be secured like a private key. A loss or disclosure of the state of entropy will lead to complete loss of security.

Use the MKE Add-on for large messages​

To enhance performance on large pieces of data, using the MKE reduces your payload size significantly. In fact, for payloads larger than 16 bytes, you will begin to see significantly smaller payload sizes.

Use the Fixed-length add-on to prevent eavesdropping​

A common attack on communication is to monitor packet size to determine what is being sent without ever knowing what the data is. Taking the voting use case for instance. A hacker may be able to tell who someone voted for just by observing the size of the message they send. With the fixed-length add-on this is not possible. Every MTE packet that travels between two endpoints will be the same exact size no matter what data is secured.

Use SDR add-on to remove reliance on OS​

The MTE Secure Data Replacement (SDR) Add-On uses the MTE Managed-Key Encryption Add-On to create a secure SDR in memory or on storage. This SDR can hold files securely without depending on the operating system or other mechanisms, which may be prone to security flaws that attackers exploit. Due to the design of MTE, the information needed to unlock the SDR can be split and stored in separate locations, none of which are on the device where the SDR exists. This design protects the SDR against typical attacks on device operating systems. SDR lives within an application (mobile app webpage, etc.) and secures data before it is held in memory, stored as a cookie, or passed to the OS for long term storage, protecting the data from OS zero days, rogue apps, or exposure from a lost or stolen device. Due to the design of MTE, the information needed to unlock SDR can be split and stored in separate locations, enabling the application server to have more control if necessary. This design protects SDR against typical attacks on device operating systems.