Definitions and Terminology
Pi Soft
Pi Soft is a three-step encryption process in which data is encrypted using a unique cryptographic key, the key is then encrypted, and finally the link between the data and the key is encrypted. The data, key and link are then stored, remaining encrypted while in storage. Decrypting the encrypted data, so that it can be read, involves decrypting the link, matching the key to the data, decrypting the key and then decrypting the data using the key. Protected data can only be decrypted and read by authorized users performing authorized transactions. As a result, stored data accessed by unauthorized users cannot be decrypted.
Pi Soft Suite#### Pi Soft kS
In the Pi Soft Suite, the Pi Soft kS (key service) performs all cryptographic key management functions (key generation, key exchange, and the encryption and decryption of keys and links). The Pi Soft kS can also perform data encryption and decryption as requested. These functions are performed in response to transaction requests received from Pi Soft rE. Data can be encrypted via requests from the Tricryption Agent. The specific services, or modules which are listed in more detail in the next section are:
- An Authentication Module
- An Authorization Module
- A Key Manager Module
- A Communications Module
- A Logging Module
- A Persistency Module
- A Cryptographic Service Provider Module
Pi Soft dS
Pi Soft dS works within the operating system at the same level as most anti-virus products. When using anti-virus solutions, the file to be saved to disk is scanned for possible virus signatures before being written to the hard disk. Pi Soft dS works in a similar fashion. The operating systems of computers using Pi Soft dS will allow only encrypted data to be saved, copied and transferred to areas within the trusted environment. Removable media taken outside the trusted environment will be encrypted and unusable to any other computer. For each data file, a unique key is created, stored and managed by the Pi Soft kS. To access the data within the trusted environment, users must have appropriate privileges to the key (and by extension to the file) and Pi Soft dS must be able to reach the appropriate kS . Specifically, the Pi Soft dS consists of the following components:
- Remote Engine (rE) which provides encryption and decryption and communicates with the kS to obtain keys
- File System Filter Driver is a kernel component which determines if a file should be encrypted or decrypted and if so calls the rE
- dS Manager which is the GUI for managing the local environment and authenticating to the kS.
- Command Line Utilities which replicate the functionality of the dS Manager to manage client workstations remotely or for use in command or shell scripts.
Pi Soft rE
Pi Soft rE (remote engine) is a module within the Pi Soft dS that transmits cryptographic key requests from a computer to the Pi Soft kS and uses the keys to encrypt and decrypt data stored on the client computer. Use of the Pi Soft rE is required for communicating with the Pi Soft dS. Tricryption rE can be used to offload data encryption/decryption from the Pi Soft kS.
kS Manager
Administration of the Pi Soft kS is performed primarily through the kS Manager. The kS Manager is a GUI application written in Java coded around the Pi Soft API. Using the application's interface, application administrators can maintain areas such as user authentication and authorization, pooling, system monitoring and automatic alert transmission. These tasks and many others enable administrators to optimize the application's performance and security. The kS Manager provides a default separation of Roles: ks physical administration versus from Pi Soft system administration. Operations which change the physical administration: database connections, pooling, threading, etc. are managed by an Administrator. Operations which affect system access and configuration: ACL Templates, user Roles, etc. are managed by a Security Officer
Pi Soft sdk
The Pi Soft Software Development Kit is an essential resource for developers using the Pi Soft Suite.
Tricryption Agent
The Pi Soft Agent is an integration component that transmits only cryptographic transaction requests to the key services (kS) or client remote engines (rE) from applications utilizing the Pi Soft SDK created functionality. The Tricryption Agent does not perform any encryption or decryption requests. Available in Java, C++ and C versions. The Pi Soft SDK includes extensive development documentation and code samples.
Pi Soft Suite Modules#### Authentication Module
The Authentication Module is a very flexible software module which allows organizations to choose their preferred method of Authentication to the system. Authentication Module supports:
- Native Authentication (Secure Remote Password: first-party SRP-6a with SHA-384): A user can be assigned a separate, specifically for Pi Soft username and password combination. This could be beneficial to provide separation of duties
- LDAP (Kerberos): Existing directory credentials can be used to access the Pi Soft system. Availability is build-dependent — Native (SRP) and X509 Certificate are the self-authenticating types every kS provides; the directory authenticator is not present in every shipped kS.
- X509 Certificates: Pi Soft can authenticate users who have PKI certificates issued by a corporate CA if the CA is designated as “trusted” by an Pi Soft Administrator. These certificates are stored in files.
Pi Soft protects communications between system components using TLS 1.3 (server-pinned minimum). The Authentication Module works with the CSP module to establish a TLS 1.3 channel.
Authorization Module
The Authorization Module determines whether a user has the right to execute a specific operation (read, write, update ACL, encrypt, decrypt, check-out keys) on a specific object in the system. It implements RBAC (Role Based Access Control) and DAC (Discretionary Access Control) security models. Authorization both RBAC and DAC can be inherited through Group membership.
Communications Module
The Communications Module exposes the functionality of the key services to the external world through TCP/IP protocol. The Communications Module is built to support multi-threaded mode of operation. It manages flexible pools of TCP/IP sockets and “worker threads”. Parameters of the pools (minimum and maximum size) are configurable through the kS Manager; therefore the administrator can optimize system performance based on available resources and load. To provide protection for TCP/IP channel the Communications Module works with the CSP Module to implement TLS 1.3.
Cryptographic Service Provider Module (CSP)
The Cryptographic Service Provider Module (CSP) module is responsible for the generation and protection of cryptographic keys, in addition to performing encryption, decryption and hashing. The CSP is also responsible for random number generation. Tricryption uses standard cryptographic algorithms:
- OpenSSL 3.0 (library)
- HSMs through a vendor-neutral, in-process PKCS#11 module (SoftHSM-verified)
Encryption Framework for Enterprises (EFE) provides an abstraction layer between the application and cryptographic tool sets to automate, standardize and provide a scalable encryption solution for enterprise application without the need to manage specific cryptographic details.
Key Manager Module
The Key Manager Module executes the Pi Soft process and orchestrates all the functions of the other software modules comprising the key server. The Key Manager module performs key life-cycle management such as creation of system or session keys, key storage in the key database, key identification and key retrieval, and ACL creation and modification. The Key Manager module utilizes all the cryptographic functions provided by the CSP including random number generation, and encryption/decryption using the symmetric encryption algorithms provided by the CSP. This module is written in platform independent C++ for speed and flexibility.
Logging Module
The Logging Module logs all operations performed. The log can be kept in the key database or in another database. These log records are time-stamped and signed. Log entries are recorded in the te_AuditLogEx table which is a table in the key database or can be in a separate database.
Persistency Module
The Persistency Module provides an interface between the kS and the key database. The kS was designed using object oriented paradigm and the key databases used are relational, hence the most important function of the Persistency Module is the object relational mapping. To scale properly with increased load the Persistency Module manages a flexible pool of database connections. Parameters of the pool (minimum and maximum size) are configurable through the kS Manager. The Persistency Module supports multiple database back-ends via the database-adapter layer.
Pi Soft Concepts#### Key Database
The key database is a database of encrypted keys and the Key IDs assigned to the encrypted keys. It can be any of the multiple back-ends supported via the database-adapter layer. The key database contains all the information necessary to rebuild the kS as a result of the stateless nature of the key services. Pointing a new installation of a kS to an existing key database (and having credentials to unlock the Master Key Container) allows the administrator to create a clone kS. This procedure is used either to recover from a catastrophic failure or to create additional instances of the kS to participate in a load-balanced scaling node.
The types of data stored in the key database include keys (encrypted), ACLs, audit logs, user credentials, Roles, Group information, and configuration information. All records are signed to prevent tampering and time-stamped to allow multi-tiered storage. Existing backup and fail-over methods and architecture can be re-utilized.
Principal Trust Matrix
Multiple key services can form trust relationships so that users who access keys from completely different key databases may share encrypted information. The visibility of principals can be controlled by user, Group, and global policies which serve to protect or expose the identity of users sharing encrypted data as revealed through Access Control Lists and ACL Template management. The interaction between user, group, and global policies set within each trusted server results in an exposure matrix.
Secure Folders
Secure folders are feature rich allowing for automatic, specific encryption and decryption of files. The Secure Folders component will automatically monitor file system read and write requests on the client and encrypt and decrypt the associated file just before the requested action occurs, on the fly. All files saved to a Secure Folder are automatically encrypted when first written to the folder.
Access Control Lists (ACLs)
Access Control Lists (ACLs) are access policies that define which users can decrypt which files and documents and under what conditions. ACLs can include a time frame and/or the number of times a document/file can be decrypted. They can also allow users to give other users' access to the document or file. ACLs can be changed real-time so that access is revoked instantly and list Groups of users so that access is inherited through Group membership.
ACL Templates
ACL Templates are patterns for creating Access Control Lists so that an ACL is created automatically and without user action as files and documents are encrypted. ACL Templates can be associated with Groups, specific users, or to file locations. As files are encrypted ACL Templates provide the basis for an automatically created ACL. For example, an ACL Template includes both the Marketing and Sales Departments. The ACL Template is associated the Marketing Department. It.is used as the pattern for ACLs for all files created by the members of the Marketing Department regardless of where the file is saved. Members of either the Sales Department or the Marketing Department can decrypt the file when needed. Alternatively, an ACL Template can be associated with a particular Windows or Samba share. The ACL Template will create ACLs for all files saved to the share regardless of who created or encrypted the file. For example, an ACL Template that lists the members of the Sales Department is associated with a directory to which confidential reports are automatically generated, only the Sales employees will be able to read the reports. Even the person who generated the reports will not be able to open them. ACLs and ACL Templates work independently of Secure Folders, but using Secure Folders provides automatic and transparent encryption and decryption among those included in the ACL.
Trusted Servers
The Trusted Servers feature allows the establishment of trust relationships between multiple different Pi Soft kS. This enables users who use one Pi Soft kS to share their encrypted data with users who use a different Pi Soft kS. This feature may require the use of a common, mutually trusted certificate authority (CA), which issues new certificates to all servers involved in the trust relationship.
Pi Soft Keys Concepts#### Key Hierarchy
Pi Soft key hierarchy consists of four types of keys. These are from the lower level of the hierarchy going up: the Session Keys, the System Keys, the Master Keys and the System Protector. The Session Keys are created by users (automatically and invisibly) for the encryption of documents and files. System Keys are used to encrypt Session Keys and Key IDs. Master Keys encrypt the System Keys. The System Protector protects the Master Key.
Key ID
A Key ID is an identifier assigned to an encrypted key stored in the key database.
Master Keys
The key service has a variety of Master Keys. Each Master Key performs a different function in the system. These Master Keys are:
- A System Key Encryption Key (AES-256 by default; AES-128/192 selectable) which encrypts the System Keys
- A HMAC Encryption Key (AES-256 by default; AES-128/192 selectable) which signs records in the key database
- An SRP Key (AES-256 by default; AES-128/192 selectable)
- The Private Key (RSA) of the internal System Certificate Authority
- The Private Key (RSA) of the key service used to obtain a certificate from the internal CA
- The Private Key (RSA) of the key service used to obtain a certificate from an external CA (for establishing trust relationships with other key servers)
All Master Keys reside inside the Master Key Container which is protected with a System Protector.
Session Keys
Information, that is a file or data base record or field, is protected using symmetrical keys known in this system as the Session Keys (AES-256 by default; AES-128/192 selectable at installation). Session Keys are the most numerous type of keys in Tricryption. A new Session Key is created for each new data element to be encrypted. Each Session Key has a unique Key ID, created by the CSP random number generator. The Session Key is encrypted with one of the randomly selected System Keys and stored in a table in the key database along with its clear-text Key ID. Each Session Key ID is itself encrypted with a randomly selected System Key. The resulting encrypted Session Key ID is the main component of the T-Tag.
System Keys
Symmetrical System Keys (AES-256 by default; AES-128/192 selectable at installation) encrypt the Session Keys and the Session Key IDs. The System Keys are created at the time of installation. The administrator selects the number of System Keys to create; the default number of System Keys is 100, but can be increased (but not ever decreased) at any time by the system administrator. Each System Key has a unique System Key ID. The System Key is encrypted with a Master Key, and the encrypted System Key and its clear-text System Key ID are stored in a table in the key database. During run-time, the System Keys are used in a random fashion to encrypt the Session Keys, and to encrypt the Session Key IDs. Session Keys and their Session Key IDs are not encrypted with the same System Key but with two randomly selected System Keys.
System Protector
The Key Container can be either a software key container or a hardware key container. The System Protector can be:
- Windows Protector - the container key is secured via the Windows Local Security Authority (LSA) / OS key store.
- Password Protector - Master Key Container is protected with a strong password (encrypted with a symmetrical key derived from the password using PKCS#5)
- Shared Secret Protector – the Master Key Container is protected with k of m shared secret scheme (of LaGrange Interpolating Polynomial type); the secret is spread through m (e.g. 5) tokens, and during the start up of the system you need to assemble k of them (k<m, e.g. 3) to unlock the Master Key Container.
- Hardware Security Module Protector - the Master Key Container is protected using an HSM through a vendor-neutral, in-process PKCS#11 module
T-Tag
Pi Soft requires a link between the data and the cryptographic key used to encrypt it. A T-tag is formed when the Key ID is encrypted. The T-tag is a composite entity consisting of the encrypted Session Key ID with the System Key ID and the Pi Soft System ID prepended to it. The T-tag is sent back to the calling application to be bundled and stored with the encrypted data. The T-tag allows the system to find the Session Key which encrypts the data by extracting the System ID to find the key server (when using Trusted Servers) which controls the key, then find the System Key, then find the Session Key. The T-tag may be used in either a RAW or Base64 format depending upon the function or method.
General Security#### Discretionary Access Control (DAC)
Discretionary access control (DAC) is a method of regulating or restricting access to information (or other resources) based on the identity of users and/or Groups to which the users belong. Controls are discretionary in the sense that a subject with certain access permission is capable of passing that permission (directly or indirectly) to any other subject. For the Pi Soft Suite, the information is the cryptographic keys and the users are the Pi Soft users. Every key is assigned an owner (by default, the user who initially encrypted a data element associated with a key through the T-tag). This user can, at their discretion, authorize other users to retrieve the key.
Role Based Access Control (RBAC)
Role based access control (RBAC) is a method of regulating or restricting access to information (or other resources) based on the roles of individual users within an enterprise. In this context, access is the ability of an individual user to perform a specific task, such as view, create, or modify a file. Roles are defined according to job competency, authority, and responsibility within the organization. For the Tricryption Suite, the information is the cryptographic keys and the roles relate to cryptographic and administrative functions within the Tricryption environment.
Mandatory Access Control (MAC)
Mandatory access control (MAC) is a method of regulating or restricting access to information (or other resources) that is built into the underlying system. Pi Soft is based upon the concept of mandatory access control because key or other object access and manipulation is regulated by access policies.
Certificate Authority
As part of a public key infrastructure, a certificate authority governs the issuance, management and verification of digital certificates which are used to authenticate the identity of the certificate holder. A certificate authority is optional and used only to provide a trust between Pi Soft Trusted Servers or to provide authentication of users who have certificates issued by the CA.