Try Buy

Security Overview

Evimetry uses standard OpenSSL PKI certificates to identify and authenticate its software components and users. In turn, these PKI keys are used by the the Evimetry protocol to provide cryptographically secure, compressed, high-speed transport of evidence, using industry standard cryptographic TLS 1.2 communications over TCP/IP, configured by default to Suite B (US NSA, Australian ASD) ciphersuite specifications.

Evimetry comes preconfigured with default PKI certificates, such that system components may communicate securely out of box. Each of the Controller, Dead Boot Agent, Live Agent, Filesystem Bridge, and Cloud Agent hold the following PKI entities:

  • A Root Issuer X509 Certificate, PEM or DER formatted. (Common to all)
  • A Client X509 Certificate, PEM or DER formatted
  • A Client Private key, PEM formatted

Don't run in production with the default keys. Anyone who has ever downloaded Evimetry has received a copy of the default keys.

Evimetry uses different certificates and keys depending on software role:

  • Controller: ca.cer, controller.cer, controller.key, fsbridge.cer, fsbridge.key
  • Cloud agent: ca.cer, agent.cer, agent.key
  • Deadboot agent: ca.cer, agent.cer, agent.key
  • Live agent: ca.cer, lightAgent.cer, lightAgent.key

All Client X509 Certificates must contain information on their intended use and the application that will use the certificates as authentication. Only controllers and agents with the same common Root Issuer Certificate may communicate. This scheme limits the ability for impersonation with compromised keys. For example, should an endpoint running a live agent be compromised, the compromised live agent key material would only be good for impersonating a live agent. Those keys would not work to authenticate a Controller, Deadboot agent, or Cloud agent.

Creating you own keys

Evimetry ships with a set of default certificates which are useful for testing, however it is strongly recommended that users generate their own set.

A sample script is provided which can be used for generating a minimal certificate authority and key set (certs.sh and certs.cmd). These scripts are located in the C:\Program Files\Evimetry\certs\ folder for Controller installs on Windows, and /Applications/EvimetryController.app/Contents/Eclipse/certs/ on MacOS.

On Windows, the certs.cmd script assumes that the the SLP Win32 OpenSSL binary distribution is installed at c:\opt\OpenSSL-Win32. If it is installed at a different path, edit the script accordingly.

The following sections describe the specifics of creating a working key set in detail. Use the section as a guide for modifying the sample script, or do it manually.

Root Issuer Certificate Generation

The Root Issuer Certificate is used by all nodes to ensure that the remote client certificate being presented shares a common and trusted issuer of all certificates being used.

Generation of a Root Issuer Certificate can be performed with the following steps:

$ openssl ecparam -name secp521r1 -out ca_plaintext.key -genkey
$ openssl ec -in ca_plaintext.key -out ca.key -aes256
$ rm ca_plaintext.key
$ openssl req -x509 -new -key ca.key -out ca.cer -outform PEM -days 365 -sha384 -subj '/C=AU/ST=Queensland/L=Brisbane/O=SchatzForensic/OU=Development/CN=RootCACert/emailAddress=ca@schatzforensic.com.au'

Edit the subject name ("-subj") parameter in the above to reflect your own organisation. While the example uses "/C=AU/ST=Queensland/L=Brisbane/O=SchatzForensic/OU=Development/CN=RootCACert/emailAddress=ca@schatzforensic.com" as the Subject Name for the Root Issuer, one could equally use a much simpler subject name, such as "/O=AcmeCoUSA/CN=RootCA/emailAddress=ca@acmeco.com". (See the OpenSSL manual for more information on the formatting of the SUBJ parameter).

The Root Issuer Certificate is generated with the appropriate options to ensure the correct cipher suite is used during connection handshake with TLS v1.2. In the above example, the Issuer Certificate is valid for 365 days, and the private key is password protected and the key is encrypted with AES-256.

As the client applications check their certificates for intended usage, it is not possible to use the CA certificates with the client applications, other than for ensuring a common root certificate exists.

Client Device Key and Certificate Generation

The Client Device Key and Certificate is used to both encrypt data and provide mutual authentication of both nodes during connection establishment.

Generation of an Agent Client Certificate can be performed with the following steps:

$ openssl ecparam -name secp521r1 -out agent.key -genkey
$ openssl req -new -key agent.key -out agent.csr -sha384 -subj '/C=AU/ST=Queensland/L=Brisbane/O=SchatzForensic/OU=Development/CN=AgentDevice/emailAddress=agent@schatzforensic.com.au'
$ openssl x509 -req -days 30 -sha384 -in agent.csr -CA ca.cer -CAkey ca.key -extfile agent.cnf -out agent.cer -CAcreateserial -CAserial ca.srl
$ openssl x509 -in agent.cer -text -noout

Update the -subj field with appropriate company information per the previous section.

The operations above being performed are:

  • Generate a new device private key
  • Generate a client device certificate request
  • Generate a client device certificate, signing with/against the Root Issuer certificate
  • Display the client device certificate details to ensure parameters are set correctly.

The Device Certificate is generated with the appropriate options to ensure the correct cipher suite is used during connection handshake with TLS v1.2. In this example the Device Certificate is valid for 30 days.

It is recommended that a unique Device Certificate and Private Key is created for each device node being utilised during operation.

Note: The above example is for an Agent Client Certificate. The extensions file parameter -extfile agent.cnf contains the intended use information for the certificate. The following configuration files are predefined and are used during the certificate generation process to determine the intended nature of the certificate:

  • controller.cnf - Controller Application
  • agent.cnf - Deadboot & Cloud agents
  • lightAgent.cnf - Light Agent Application
  • fsbridge.cnf - Filesystem Bridge Application

When generating Client Certificates, please ensure the correct extensions definition file is selected for the intended use of the certificate.

Attributing examiner access

The use of Controller keys and certificates enables one to limit access to the Evimetry fabric. One can attribute access by issuing a separate key and certificate to each examiner for installation into their Controller. On successful authentication, the associated SubjectName is logged in the associated Agent.

Per examiner Controller certificates may be created based on the following:

export CERTS_DIGEST=sha512
export CERTS_START_DATE=20100101000000Z
export CERTS_EXPIRE_DAYS=7200
export CONTROLLER_SN="/O=SchatzForensic/CN=Bradley Schatz/emailAddress=bradley@evimetry.com"
export CONTROLLER_CERT_BASE_NAME=controller.blschatz

openssl ecparam -name secp521r1 -out ${CONTROLLER_CERT_BASE_NAME}.key -genkey
openssl req -new -key ${CONTROLLER_CERT_BASE_NAME}.key -out ${CONTROLLER_CERT_BASE_NAME}.csr -${CERTS_DIGEST} -subj "${CONTROLLER_SN}"
openssl ca -batch -config ca.cnf -in ${CONTROLLER_CERT_BASE_NAME}.csr -out ${CONTROLLER_CERT_BASE_NAME}.cer -extfile controller.cnf -startdate ${CERTS_START_DATE} -notext -days ${CERTS_EXPIRE_DAYS}
openssl x509 -in ${CONTROLLER_CERT_BASE_NAME}.cer -text -noout
		

Update the -subj field with appropriate company information per the previous section.

Live Agent Device Key and Certificate Generation

The Live Agent Device Key and Certificate is used to both encrypt data and provide mutual authentication of a Live Agent with an Agent or Controller during connection establishment.

Generation of an Live Agent Client Certificate can be performed with the following steps:

export CERTS_DIGEST=sha512
export CERTS_START_DATE=20100101000000Z
export CERTS_EXPIRE_DAYS=7300
export LITEAGENT_SN="/O=SchatzForensic/CN=nitrogen.schatzforensic.local"
export LITEAGENT_CERT_BASE_NAME=lightAgent.nitrogen

openssl ecparam -name secp521r1 -out ${LITEAGENT_CERT_BASE_NAME}.key -genkey
openssl req -new -key ${LITEAGENT_CERT_BASE_NAME}.key -out ${LITEAGENT_CERT_BASE_NAME}.csr -${CERTS_DIGEST} -subj "${LITEAGENT_SN}"
openssl ca -batch -config ca.cnf -in ${LITEAGENT_CERT_BASE_NAME}.csr -out ${LITEAGENT_CERT_BASE_NAME}.cer -extfile lightAgent.cnf -startdate ${CERTS_START_DATE} -notext -days ${CERTS_EXPIRE_DAYS}
openssl x509 -in ${LITEAGENT_CERT_BASE_NAME}.cer -text -noout

Update the -subj field with appropriate company information per the previous section.

Deploying key material

We STRONGLY recommend creating the key material offline, and keeping it in a secure place.

Evimetry Agents will only take these files via command line argument, and do not use the underlying JVM keystore for key management. (This is to allow easy and rapid replacement of keys). The certificate location is set via the preferences dialog in the Evimetry Controller.

Copy only the specific keys your application needs per the roles above. The default locations for these are:

Controller (Windows) C:\Program Files\Evimetry\certs\
Controller (MacOS) /Applications/EvimetryController.app/Contents/Eclipse/certs/
Deadboot agent /certs/
Cloud agent /opt/evimetry/agent/certs/
Live agent Same folder as the live agent executable

In the Controller, the paths to the certificates is additionally configurable via the application preferences.

For agents, the path to key material may be additionally configured by command line arguments per the following:

  • --cacert= - The location for the common Root Issuer Certificate.
  • --publickey= - The location for the client public X509 Certificate.
  • --privatekey= - The location for the client private key.

For the persistent cloud agent, it is recommended that you store your keys in the /etc heirarchy rather than overwriting the default certs.


Cryptosystem specifics

The cryptosystem utilised by Evimetry is based on recommendations from the Australian Signals Directorate (ASD) Australian Government Information Security Manual (Controls) (August 2013). By utilising this resource we can ensure that the cryptosystems being utilised are sufficient in operation to prevent information loss or theft during operation.

By default Evimetry Agents and Controllers will connect only using TLS v1.2 for secure communications with the following constraints:

  • Traffic Encryption: AES-256 (or better)
  • Hashing Algorithm: SHA384 (or SHA512 if available)
  • Digital Signature: ECDSA (NIST P-384)
  • Key Exchange: ECDH (NIST P-384)

Other encryption algorithms, hashing algorithms, digital signatures and key exchange technologies (eg RSA, DH) are not permitted to be utilised for the initial connection between agents and controllers. There is currently no method to reduce these requirements through configuration. However, once communications has been established between agents and controllers, other encryption algorithms may be selected as required (either No encryption, 3DES, AES-128 or AES-256) on a per connection session basis based on operational requirements.