1. Introduction

This document is intended for IT system architects who would like to have a detailed understanding about the security features of the Techila Distributed Computing Engine (TDCE) solution.

If you are unfamiliar with the terminology used in this document, please see the following documents for more information:

2. Techila Distributed Computing Engine Architecture

This Chapter contains an overview of the Techila Distributed Computing Engine (TDCE) system architecture. For more detailed information about the TDCE system architecture, please refer to Techila Distributed Computing Engine IT System Architecture.

TDCE environments can be divided in to three different categories:

  • On-premises

  • Hybrid

  • Full-cloud

In an on-premises environment, the Techila Server and all Techila Workers are deployed inside the organization intranet. This means that no computational data will be transferred outside the intranet. Depending on the Techila License type, a connection to an external Techila License Server might be required. Information transferred to the Techila License Server only includes CPU usage statistics meaning no sensitive data will be transferred.

In a hybrid environment, the Techila Server is deployed inside the organization intranet. Techila Workers can either be computers that are on-premises or Techila Workers can be deployed on instances provided by public cloud providers.

In a full-cloud environment, the Techila Server and all Techila Workers are deployed on instances provided by public cloud providers.

Techila Worker nodes in the cloud are provisioned by the administrator (or by End-Users given sufficient permission).

Upon deployment, the Worker node is installed using a clean image. The Techila Worker software is installed on top of that fresh image on each deployment. Once the usage of the node is done and the node shutdown, all information is lost.

Techila Worker nodes deployed in cloud environments are not, by default, accessible from the Internet directly.

When deploying a Techila Worker node in a cloud environment, the latest image of the operating system is used automatically. Techila Worker nodes in cloud environments are not typically running continuously for extended periods of time and therefore operating system updates are handled when the nodes are redeployed.

The following figure illustrates the structure of the on-premises/hybrid environment.


3. Authentication

In a Techila Distributed Computing Engine (TDCE) environment, network connections are established between the following communication end-points:

  • Techila Worker -→ Techila Server

  • Techila End-User -→ Techila Server

All network connections are encrypted using industry standard two-way Transport Layer Security (TLS) technology. The TLS version is the default version used by Java. Current TDCE environments (Service Pack 2015-11 and newer) use Java 8, which has TLS 1.2 as default.

Cipher suites used/enabled are those enabled by default in Java:

All communication end-points are authenticated using public-key infrastructure (PKI) technology. This authentication is part of the of the TLS protocol. Additionally, the End-User → Techila Server connection is authenticated inside the HTTPS tunnel.

More detailed information about the RSA key generation process can be found in the following Chapters.

The following terminology will be used this document:

Keystore - Java keystore (JKS) files, which are used to store the keys used for authentication in the TDCE system.

Key - Entities consisting of a private key and certificates (1024 bits), which typically have a certificate chain leading to the Root Certificate Authority of the TDCE environment.

Certificate - Public keys, which have been signed with another key. In a TDCE environment, the certificates are issued by Techila Administrators.

The image illustrates the contents of one keystore file, containing a private key and a certificate with a corresponding certificate chain. Please see Chapters End-User Key and Administrator Key for additional information about storing the Techila keys.

3.1. Techila Server

The Techila Server creates the following keys automatically during the Techila Server installation process:

  • Techila Administrator key

  • Techila Server key

The Techila Administrator key is self-signed and represents the Root Certificate Authority for the TDCE environment. The Techila Administrator key will be automatically used to sign the Techila Server key. This signing process will create the Techila Server certificate.

The Techila Server certificate will be used to authenticate Techila Server to the Techila Workers when the connection is established for the first time. The Techila Workers will store the Administrator certificate on the Worker’s local hard drive when connection to the Techila Server is established for the first time. On subsequent connections Techila Workers will use the Administrator certificate to authenticate the Techila Server.

3.2. Techila Worker

The Techila Worker is authenticated to the Techila Server with a unique Techila Worker certificate. The Techila Worker certificate is self-signed and is generated automatically when the Techila Worker software is started for the first time. The Worker certificate will be transferred to the Techila Server when connection is established for the first time. The Techila Server will store the Worker certificates in the Techila Server database and use these certificates to validate subsequent connections.

The Techila Worker software uses a dedicated user account on the Worker machine to run all TDCE related processes. On computers with a Windows operating system, the Techila Worker service is authenticated to the operating system with the password defined for the user. On computers with Linux operating systems, the Techila Worker process is started directly using 'su' to run on the dedicated user and no password is used.

3.3. Techila Server and Techila Worker Authentication

This Chapter contains illustrations how the Techila Server and Techila Workers are authenticated. The image below illustrates the situation where the Techila Server is already installed and running and a new Techila Worker is added to the system by installing the Techila Worker software on a computer.


By default, the Techila Server will automatically trust new Techila Worker certificates that are received. When using a non-dedicated computing environment, security can be increased by replacing the automatic trusting mechanism with manual approval performed by the Techila Administrator. Disabling the automatic trusting feature will increase protection against man-in-the-middle attacks, as this will prevent malicious 3rd parties from adding Techila Workers to the TDCE environment.

The image below illustrates the situation where a Techila Worker re-establishes the connection with the Techila Server. This scenario typically occurs if the operating system of the Techila Worker is rebooted.


3.4. End-User

Each End-User in the TDCE environment has a personal End-User Key, which will be used for authentication when connecting to the Techila Server. These End-User Keys are generated by the Techila Administrator and signed with the Techila Administrator private key. All End-User Keys will need to have a certificate chain leading to the Techila Administrator key. During the key generation process, the End-User certificate will be stored on the Techila Server.

Each End-User will also need a Techila Account, which will be linked with End-User certificate. The Techila Account will be used to configure resource management policies that are applied for the End-User. Authentication to the Techila Web Interface is done using login and password pairs that are defined by the Techila Administrator.

Every Bundle transferred to the Techila Server must be signed with the End-User’s private key. This means that all data transferred to the Techila Server is authenticated with a valid signature. The signature also defines the ownership of the Bundle, which means each Bundle can be traced back to the original creator. Each End-User should store their Techila keystore files in a place where no other can access them.

A copy of each End-User’s certificate with a complete certificate chain can be downloaded from the Techila Web Interface by the Techila Administrator.

Techila Technologies has its own key hierarchy which contains Techila Developer keys. Every Core Bundle is signed with a Techila Developer key. The signature of each Core Bundle is checked on the Techila Server and on the Techila Worker.

3.5. End-User and Techila Server Authentication

This Chapter contains an illustration how the identity of End-Users is authenticated when accessing the TDCE environment.

The process is started when the End-User accesses their user credentials in the password protected keystore file. After opening the keystore file, a network connection will be established with the Techila Server. This connection will validated by sending an encrypted package to the Techila Server and checking if the package can be decrypted with the public part linked to the End-Users Techila Account. If the package can be decrypted, the connection will be marked as valid and the End-User can access the computational environment.


4. Authorization

4.1. Techila Users and Techila Administrators

Users are divided into different categories based on the settings of their Techila Accounts and based on type of the Techila key they are using. Techila keys used for authorization are divided in the following categories:

The digital signature algorithm used is SHA1withRSA. Keys can be revoked by using the Techila Keytool (commands "revoke" and "gencrl"). The generated CRL file can be uploaded to the Techila Server from where it is automatically distributed to the Techila Workers.

Techila Accounts can be given the following permissions:

  • Bundles (Allows user to transfer signed Bundles to the Techila Server)

  • Projects (Allows user to create computational Projects)

  • Cloud (Allows user to deploy Techila Workers in hosted environments provided by public cloud platforms, such as Windows Azure, Amazon EC2 and Google Compute Engine)

  • Admin (Allows user to perform administrative actions in the Techila Web Interface)

Typically End-Users are always given the 'Bundles' and 'Projects' permissions, which are both required in order to create computational Projects. The 'Projects' permission allows a user to create new Projects, execute them and download the results. The 'Bundle' permission allows a user to create, upload and approve new Bundles, which are used to transfer data used in the computational Projects.

Techila keys are divided into separate hierarchies; one for the customer and one for Techila Technologies. Both of these hierarchies are private and not linked to any public Certificate Authority. The figure below illustrates the two separate hierarchies.


The functionality associated with each key type is explained in the following Chapters.

4.1.1. End-User Key

End-User Keys are used for authentication and for signing Bundles which are used to transfer computational data during Projects. Bundles uploaded to the Techila Server are checked for a valid signature; Bundles without signature or with an invalid signature are not authorized and are discarded.

Each End-User should store their Techila keystore files in a place where no other can access them, typically in their home directory.

End-User Keys cannot be used to sign Core Bundles and therefore normal user cannot replace the core components.

4.1.2. Administrator Key

Administrator Keys are used to sign End-User Keys. Administrator Keys are also used for signing other keys that are used in the TDCE environment, including additional Sub-Administrator Keys.

Each administrator should store their Techila keystore file in a place where no other can access them.

Administrator Keys should not be used to sign Bundles.

4.1.3. Techila Root Key

The Techila Root Key is used to validate Core Bundles used by the TDCE system.

Core Bundles are bundles that contain all the core functionality of the TDCE system, including components required for communication, database handling and security features. All Core Bundles and updates to Core Bundles are signed with a key, which has a signed path leading to the Techila Root Key.

The Techila Root certificate is included in each Techila Server and Techila Worker installation. The certificate is used to validate the signature of the Core Bundles used to update the TDCE system.

Core bundles are published as a Service Pack on the Techila Extranet web site and if required hotfix Bundles are also made available on the Techila Extranet. The customer administrator can download the Service Pack file and upload it to the Techila Server. Once uploaded and approved on the Techila Server, the core bundles are automatically updated to the Techila Worker nodes.

4.2. Techila Worker

The Techila Worker software is installed and executed using a dedicated user account, which does not have administrative permissions.

This dedicated user account requires access to the following directories:

  • Home directory of the dedicated user account

  • Techila Worker installation directory

  • Other directories required for code execution (Windows DLL files, Linux shared libraries).

Access to any other directory should be restricted.

When the Techila Worker software is installed on a computer with a Windows operating system, the installation process (by default) creates a dedicated user account with the required access rights. This account is not allowed to log on to the system interactively.

On computers with a Linux operating system, the dedicated user account is manually created by the administrator. The dedicated user account should be given access to the directories listed above.

4.3. Bundle Transfers

Bundles are used to transfer data in a TDCE environment. Bundles are typically transferred between the following peers in a TDCE environment:

  • End-User -→ Techila Server

  • Techila Server -→ Techila Workers

Before Bundles are transferred, a secure TLS channel is created between the peers based on the authentication mechanisms described in Chapters Techila Server and Techila Worker Authentication and End-User and Techila Server Authentication. After peers have been authenticated and a TLS channel has been created, Bundles can be transferred.

After a Bundle has been transferred, each receiving peer will validate the Bundle signature. If the signature validation fails, the Bundle will be rejected and the transferred file will be deleted. This means that the signature validation is two-tiered, which increases data management security compared to single-tiered architectures. The Bundle transfer and signature validation process is illustrated below. However, in secure environments such as clusters, this checking can be disabled for performance reasons.


5. Accounting

Information about computational Projects is logged in the Techila Server database. This data includes the following accounting information:

  • Project input parameters

  • Bundle dependency trees

  • Project ownerships

  • Job assignment details

This information provides traceability, meaning administrators can retrieve execution times of all Jobs and also find out which Techila Worker executed the Job. Project ownership details will contain information which End-User created the computational Project. Bundle dependency tree provides a hierarchical structure which contains information on which Bundles were imported in the Project and which End-User created the Bundles.

The Techila Server will also create operation logs, which contain detailed information about operations executed on the Techila Server and the timestamp associated with each operation. This includes both automatic operations related to the standard operation of the Techila Server and manual operations executed by the Administrators and End-Users. Different logging levels can be selected to specify the level of detail stored in the log files. Log files are stored in the Techila Server installation directory.

Similar logging mechanics are available on the Techila Worker. Automatic and manual operations are logged and stored in the log files. The level of logging can also be controlled by specifying the desired log level. Log files are stored in the Techila Workers installation directory. The log files can be viewed using the Techila Web Interface.