Engage Security

Security in Engage is a broad category covering a variety of areas and use-cases:

Technology, Regulatory Items, and Disclaimer

Before we delve into specifics of Engage security, we need to cover what we use for security and regulatory considerations.

Technology

All of our components use the open-source OpenSSL library. Specifically, we use version 3.0.8 of this library (as of Engage 1.240), compiled from it's unmodified, original source code. We build OpenSSL specifically for our purposes using existing options provided by the OpenSSL build environment - meaning that we exclude capabilities, algorithms, and other features of OpenSSL that Engage does not use. This results in the smallest, most performant implementation possible.

The resulting build of the OpenSSL library is statically linked with our software - meaning that we do not utilize security features (or lack thereof) offered by a particular OS or hardware platform. Also, using exactly the same crypto library across all platforms means that we have a single, consistent, and interoperable platform on which to base our security. (It also means that should regulatory considerations require inspection, that there is nothing specific to a particular platform that has to be individually evaluated.)

With the release of OpenSSL 3.0.8 Engage supports NIST-approved FIPS 140-2 operation. The NIST CMVP validation document is #4282 and can be viewed on the NIST web site at https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4282. Please note that OpenSSL only allows for the FIPS provider to be delivered and utilized as a shared binary object. On Windows platforms, it is named rts-fips.dll, *nix is rts-fips.so, and Darwin(ish) as rts-fips.dylib. FIPS 140-2 operation is not supported on Android, iOS, or WASM as of this writing.

Regulatory

Export and import of encryption technologies is a hairy subject and varies in complexity across a variety of use-cases, source of export, and target of import. In addition, we do not sell or license our technologies to end-customers. Rather, we license to OEM partners who then incorporate our technologies into their products which are, in turn, sold/licensed to end-users. As a result, we do not provide details of compliance with export or import regulations as it is the responsibility of our OEM partners to seek the necessary approvals or exclusions on a case-by-case or product-by-product basis.

We are open to inspection of our source code by authorized organizations, agencies, and individuals for compliance purposes. These are taken on a case-by-case basis. Please contact [email protected] for assistance in this regard.

Disclaimer

Please remember that export/import and/or use of strong cryptography software, providing cryptography hooks, or even just communicating technical details about cryptography software is illegal in some parts of the world. So when you import Engage software to your country, re-distribute it from there or even just email technical suggestions or software sources us or other people you are strongly advised to pay close attention to any laws or regulations which apply to you. Rally Tactical Systems, Inc. is not liable for any violations you make here. So be careful, it is your responsibility.

Encryption

Symmetric Encryption

In general, all symmetric encryption in Engage is performed using the AES (Advanced Encryption Standard) algorithm with 256-bit keys operating in CBC (Cipher Block Chaining) mode.

Asymmetric Encryption

Asymmetric encryption is used in Engage during the TLS encryption setup phase between a client application and a Rallypoint. The algorithm used in this phase uses a cipher that the Rallypoint and client agree upon based on the X.509 certificates they present to each during the handshake.

Symmetric Key Derivation

Encryption keys are never stored or transmitted by Engage. Rather, keys are algorithmically derived using the NIST-approved PBKDF2 algorithm. Here, Engage takes the incoming passphrase/password/PIN (we refer to this as "Baseline Key Material" or simply "BKM") provided by the user application, combines it with a 128-bit salt, and performs 15,000 iterations of the algorithm (NIST recommends 10,000 iterations) to arrive at the derived, 256-bit, key.

Baseline Key Material is binary!

Engage is not limited to only printable characters for baseline key material. Rather, the software supports the full 256-bit range of binary data for BKM. For example, many encryption systems utilize passwords, passphrases, or PIN codes. This generally means that they need to be human-readable in some form and, therefore, printable. As Engage is not interacting directly with humans in this regard, the application using the Engage Engine can use any method appropriate to its use-case to obtain BKM from a user or from non-human entities such as provisioning systems.

Baseline Key Material Transport

Transportation of BKM is the domain of the application using the Engage Engine. For example: implementations where human-processable data such as passwords, passphrases, and numbers are concerned; that information can be conveyed through out-of-band means such as one-on-one interactions between team members, secured emails, and a variety of other methods. Some implementations could choose to use more exotic transport methods such as encrypted QR codes where the QR code is itself protected by a password known only to those using the QR code.

Traffic Encryption

Channels (or "groups" as we refer to them) that are encrypted, use AES256-CBC as described above. When the traffic is conveyed over UDP, the entire UDP payload is encrypted, with each packet preceded by a 16-byte random Initialization Vector (IV). This means that an attacker has no reliable way to know if the traffic is a known format (such as RTP) or a custom format implemented by the Engage Engine or the application using the Engine (in the case of "raw" group types). Also, even if the attacker assumes correctly that the payload is a standards-based format such as RTP, because even the RTP headers are encrypted, and the entire payload preceded by an initialization vector produced uniquely for each packet; the task of cryptanalysis is exponentially more computationally expensive.

When traffic is conveyed over TCP - in the case of client connections to Rallypoints as well as peer connections between Rallypoints operating in a mesh - that traffic is secured with TLS 1.3. This TLS-provided encryption is in addition to whatever encryption is already present for a group. Therefore, if the traffic for a group is encrypted, Engage will always encrypt it and, when that traffic then flows through TLS, the traffic is encrypted once again.

It should be noted that Engage generally views all traffic as packets conveyed over UDP. So, even if the packets are conveyed over TCP, they are still treated by Engage as, atomically, UDP. Essentially, Engage views TLS connections as secured tunnels (not unlike VPN connections) over which regular UDP is conveyed as a TCP stream.

Rallypoint UDP Streaming

A recent addition to Rallypoint connections is the optional capability to convey media traffic over UDP rather than multiplexed inside the Rallypoint TCP tunnel. The encryption for this traffic stream is somewhat different than described above however and summed up as follows:

Crypto Type	Algorithm	IV Bytes	Encryption Overhead Bytes	Comments
1	AES-256 Full IV	16	16 + (Data Size % 16)	Default. Least efficient.
2	AES-256 Indexed IV	16	2 + (Data Size % 16)	More efficient than AES-256 Full IV.
3	ChaCha20 Full IV	16	16	More efficient than AES-256 Indexed IV.
4	ChaCha20 Indexed IV	16	2	Most efficient.

First, instead of using only the AES encryption algorithm (which operates in block mode), we also offer the option of using use the more modern ChaCha20 stream cipher which has been widely accepted for some years now, offers better performance than AES, is equally (if not more) secure, and occupies less bandwidth due to its stream nature rather than the block nature of AES. ChaCha20 is not the default, though - Rallypoint UDP streaming defaults to AES256 Full IV encryption unless otherwise specified.

Second, UDP streams to/from Rallypoints are optionally not preceded by the IV for each block. In this use-case, each end of the UDP stream derives a local IV table based on a previously-derived symmetric key which, itself, is derived from a master password randomly generated by the Rallypoint. The size of this random master password ranges from 1,204 - 2,048 bits in size. the content of it is, of course, random. (Bear in mind that the password is not the symmetric key, but rather a component used to generate the symmetric key.)

The size of the IV table is randomly determined by the Rallypoint and communicated to the far-end when the connection is established and can range from 65,536 - 320,0000 bits. Each end then generates an anonymously-agreed, deterministic random number field using the master password as a baseline.

When transmitting traffic, the sender chooses a random index in its IV table, using the following (random) 128 bits of data from that offset as the IV for input to the AES OR ChaCha20 algorithm and, together with the symmetric key, encrypts the traffic. That index is then encoded into the packet being sent. The receiver, uses that index to reference the IV position in its own table which happens to match the sender's IV table. Hence, rather than sending the full IV, the position of the IV in the logically "shared" IV table is transmitted.

X.509 Certificates

Engage uses X.509 certificates extensively for purpsoes of encryption, authentication, verification, and data creation. At minimum, an Engage Engine has a default certificate that it uses for all these purposes but it is possible to use individual certificates for specialized purposes. For example, connections to different Rallypoints (say within and external to an enterprise) can use different certificates.

Certificate Storage

When configuration (in the form of JSON) is provided by an application to the Engage Engine, the various certificates to be used may be passed directly in the certificate as PEM-encoded text. This certificate data often, however, includes the private key with the certificate. Applications or the platforms they execute on may not always meet government or enterprise stringent data protection guidelines. To deal with this, Engage offers a set of certificate management APIs that secure certificates and private keys in an encrypted storage container known as a certificate store. This certificate store is typically physically implemented as an operating system file which may, in turn, be stored securely by the underlying operating system. That OS-provided secure storage notwithstanding, Engage encrypts this file following a sophisticated security algorithm where the encryption key (AES256-CBC) for the file is comprised of 3 components: an application-provided (binary) password/passphrase/PIN, a 512-bit algorithmically-generated salt contained within the Engage Engine, and a 128-bit initialization vector embedded into the certificate store itself.

Also, the initialization vector changes every time the file is modified by Engage, effectively creating a dynamic keying material baseline upon every store modification operation.

To aid in protecting against unauthorized certificate store modification, Engage embeds a SHA-256 digest in the certificate store and also validates each element in the store every time that store is opened. Therefore, for an adversary to obtain access to the content of the store - or to modify it in any way, they would have to know the application-defined passphrase, the algorithmically-generated Engage-provided salt, the IV inside the certificate store, and (finally) understand the method in which the encryption key is generated.

Each certificate (and its private key if applicable), is de-referenced with an application-provided identifier which is then used within the JSON configuration to "point" to the certificate. For example, JSON containing the actual PEM certificate could be represented as:

.
.
   "security":{
      "certificate":"-----BEGIN CERTIFICATE-----\nMIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQQDAjB9MQswCQYDVQQGEwJCRTEPMA0G\n .... ",
      "certificateKey":"-----BEGIN EC PARAMETERS-----\nBgUrgQQAIw==\n-----END EC PARAMETERS-----\n-----BEGIN EC PRIVATE KEY-----\nMIHbAgEBBEGXac ... "
   }
.
.

Or, a certificate store can be used that contains a certificate (and private key) identified with an application-defined value such as "PrimaryX509". In this case, the JSON would look as follows:

.
.
   "security":{
      "certificate":"@certstore://PrimaryX509",
      "certificateKey":"@certstore://PrimaryX509"
   }
.
.

In this case, Engage will extract the certicate and key for "PrimaryX509" from the active certificate store and insert it directly into its internal configuration without the certificate or key ever being exposed - even to the application itself.

Defaulting Using Certificate Store Tags

That all said, there's another way in which Engage can be instructed to use certificates from the certificate store without specifying anything either in the Engine's policy or the group configuration. In other words, there's way to forgoe the security JSON element altogether (as well as certificate-related details in Rallypoint configurations). This is done through tagging of elements in the certificate store.

Tagging is simply the process of attaching a well-known identifier (or set of identifiers) to a certificate element in the certificate store and then forcing Engage to retrieve elements from the active store using these well-known identifiers. If you leave a security element empty, Engage will look in the active certificate store for the first element it finds with the appropriate tag and use it's contents.

For example: Let's say we have a security element which is blank (or simply not in the configuration at all) as below:

.
.
   "security":{
      "certificate":"",
      "certificateKey":""
   }
.
.

When Engage encounters this situation it will look in the active certificate store for the first element that has the tag enginedefault. If it finds that element, it will use it. Pretty straightforward.

Of course, now the onus is on the certificate store to have the elements correctly tagged. If they're not present, the above will result in Engage complaining about not having security-related information.

There are presently 2 tags that the Engage Engine will look for:

• -enginedefault : A certificate, including private key, used for general X.509 operations.
• -cadefault: A CA certificate.

On a Rallypoint, the same logic applies but with a slightly different name:

• -rpdefault : A certificate, including private key, used for general X.509 operations.
• -cadefault: A CA certificate.

With this understanding in mind, assume we have empty security configuration as shown in the example above. Now, the certificate store needs to have it's elements tagged and Engage instructed to use that store. For example, if we were to use ecstool (described below) to configure a certificate store with the correct tagging, we'd have something like this:

./ecstool all-rts-certs.certstore list
---------------------------------------------------------------------------------
Engage Certstore Tool version 1.191.9028 [RELEASE] for darwin_x64
Copyright (c) 2019 Rally Tactical Systems, Inc.
Build time: Nov 25 2020 @ 14:54:18
---------------------------------------------------------------------------------
id................: {415ffe01-efe5-4592-b984-c839b8fb074e}
fileName..........: all-rts-certs.certstore
version...........: 1
3 CERTIFICATES
	rtsCA  (CERTIFICATE ONLY) [-cadefault]
	rtsFactoryDefaultRpSrv  (CERTIFICATE  + PRIVATE KEY) [-rpdefault]
	rtsFactoryDefaultEngage  (CERTIFICATE  + PRIVATE KEY) [-enginedefault]

We can use this certificate store for Engage Engines as well as Rallypoints because, in this case, our store contains all the certificates we have for our organization.

• Notice how rtsCA is tagged as -cadefault, telling Engage and Rallypoints that rtsCA is the default CA certificate to use.
• rtsFactoryDefaultRpSrv is tagged as -rpdefault which tells Rallypoints using the certificate store that rtsFactoryDefaultRpSrv is the default certificate to use.
• Finally, rtsFactoryDefaultEngage is tagged as -enginedefault which tells Engage Engines to use rtsFactoryDefaultEngage as the default certificate.

This capability is purposefully simple in nature and designed for those situations where using defaults is sufficient for normal operation. For more sophisticated environments such as using multiple and/or different certificates, CAs, and so forth; defaulting security is not sufficient and you will need to specificy security-related information.

Certificate Store Loading & Distribution

Depending on the use-case of the application using the Engage Engine, implementors can choose to implement importing of certificates from within the application. Or, they may choose to use the ecstool command-line utility which uses the Engage Engine to manage certificate store files. Those files may then, in turn, be distributed to end-user devices, servers, and the like using the customer's preferred distribution mechanism such as an MDM, ActiveDirectory, LDAP, dedicated servers, clouds, file copying, shared drive access, etc. Even public means of distribution - such as email, social media, and public drives - may be used because, ultimately the certificate store has self-contained security accessible only to Engage Engines and then only those Engines where the above-mentioned constraints are satisfied.

Data Signing and Message Authentication

Signing and verification of messages and other secured data elements in Engage is driven by certificates as well. At this time, Engage uses message-signing for an additional level of authentication between clients and Rallypoints, as well as signing of timeline events for anti-tampering purposes such as chain-of-evidence preservation. In both cases, Engages uses the Elliptic Curve Digitial Signature Algorithm (EDCSA) to both sign and verify signed data.

In the case of TLS connections, Engage implements additional guards against attacks by using a message-signing strategy that incorporates keying material negotiated by the session's TLS handshake - and which is unique to that session. This is done in compliance with RFC 5705 whereby a portion of the session's unique key material is incorporated into session management messages and then signed with ECDSA.

For timeline signing, each timeline file (stored as a JSON or RIFF file depending on content) incorporates the public portion of the signing certificate in PEM format along with the ECDSA signature for the content based on the certificate public/private key pair.

FIPS 140-2 Operation

As noted above, all of our software offers support for FIPS 140-2 operation through dynamic loading of a NIST-approved module at runtime. Engage-based or Rallypoint software is configured for FIPS mode at process start time and cannot be changed once operational. In other words, to switch away from FIPS mode, the process must be fully restarted and configured appropriately. Similarly, switching to FIPS mode after process startup also requires a process restart.

When running in FIPS mode, the software has limited support for certain cryptographic-related specifications such as key sizes, X.509 certificate types, ciphers, and elliptic curves. These limitations - imposed by the FIPS specifications - generally should not affect your systems' operation. However, care must be taken that crypto-related components are in FIPS compliance. For example, CA certificates must be explicitly marked as CA usage, only NIST-approved ciphers and curves must be specified, and so on. Please refer to NIST-published documents for further information on FIPS 140-2 compliance requirements.