Security Principles and Compliance Specifics Governing tiCrypt

Executive Summary

Judging by the continuous stream of data breaches, the security mechanisms widely deployed, such as backend network security, perimeter defenses, and security permission management, are ineffective. These traditional mechanisms fail to address what happens if you have a single point of failure, i.e., if the backend server is compromised or the risk is posed internally.

The primary assumption behind the tiCrypt design is that backend servers and network infrastructures can easily be compromised. The only mechanisms that tiCrypt trusts and what it builds the security of the system on are based on strong encryption controlled by the user. Since the decryption keys are not stored on the server, the data cannot be compromised if the server is breached. In tiCrypt, a compromised admin account does not translate into a data breach.

Security Principles

• Data Confinement through Encryption: Rather than directly hardening of the system through traditional means, tiCrypt utilizes encryption to ensure data confinement. System resources such as files, drives, and communication channels use an independent AES-256 encryption key.
• Public-Key Cryptography: Data confinement requires independent keys for each resource. The critical management nightmare is avoided in tiCrypt through public key cryptography. Upon account creation, each user creates an RSA-2048 key; this key is the primary means of secure data control.
• End-to-end encryption for security: This is defined as encrypting a file at the earliest stage and decrypting it as late as possible. tiCrypt heavily relies on end-to-end encryption to guarantee that data is maximally protected, ensuring that even system administrators do not have access to users’ data.

Advanced Security Features

• Public Key Signing and Chain of Trust: All public keys are digitally signed to ensure authenticity.
• Crowd Security: The client remembers the fingerprints of public keys to prevent user impersonation.
• Key Escrow: Advanced key recovery mechanism based on multi-party authentication.
• Secure Virtual Machines: Secure data processing using encrypted drives, connection to user data, and SSH tunnels.

Auditing and Monitoring Features

• Advanced Audits: tiCrypt provides detailed, efficient auditing and monitoring capabilities. tiCrypt's built-in audit tool can process hundreds of millions of entries per second; even large audit logs can be mined efficiently for usage patterns, compliance, and more.
• Compliance and Regulations: tiCrypt was built to meet organizations' sensitive data needs by complying with the major regulatory departments (HIPAA, FISMA, FIPS).

System Scalability

• Software Scalability: The tiCrypt software is designed to be completely scalable with its hosting hardware's capacity. The only limiting factor to the software's performance and scale is the size of the hardware on which it is deployed.

• Hardware Expansion Compatibility: Upgrading your Controlled Unclassified Information (CUI) system with tiCrypt is a straightforward process. It primarily involves expanding the hardware footprint by adding more servers to host virtual machines or enhancing the storage space on the distributed filesystem. tiCrypt is engineered to seamlessly scale and integrate with any hardware enhancements, making expansion a smooth and efficient process.

• Licensing Simplicity: To keep licensing simple and efficient, tiCrypt is offered under a single deployment license that covers the entire institution. This eliminates the need for license renegotiation or additional licensing fees as your CUI system expands. We aim to provide clarity and consistency in our licensing agreements, reducing administrative burdens.

Security Landscape, today!

tiCrypt's approach to the problem of securing a system is fundamentally different.

Across the globe, reports of hacks and data breaches have become commonplace in media headlines. No business is immune. In the last two years alone, high-profile companies with security budgets upwards of $150 million have seen their systems compromised and data breached. No amount of armed guards, sophisticated locks, firewalls, or intrusion detection systems effectively protects the system.

Traditional security systems primarily focus on three types of mechanisms: backend network security (VLANs, secure networks, etc.), perimeter defense (intrusion detection, firewalls, etc.), and security permission management (access control lists, business rules, etc.). The hope is that outside attacks are prevented by keeping the Perimeter secured.
By employing sophisticated permission management, the intent is to confine insiders to their data. The problem is that the perimeter defenses can be defeated or avoided altogether by an inside attack. Once an admin account is compromised, the perimeter defense and permission management offer no protection; there is little stopping the attackers from accessing all the information within the Perimeter. This reaffirms that traditional data security models, including perimeter defense, are fundamentally flawed. Each occurring breach, compromised server, or hijacked admin account mounts evidence against the traditional model.

Unfortunately, despite evidence mounting against the traditional model, businesses are reluctant to learn from their mistakes. The go-to response after a hack is to improve and strengthen security features to prevent the occurrence. This mentality evokes the unending cycle of poor solutions. Rethinking the fundamental approach to security is essential to correct this flaw and give companies the best chance of avoiding another incident.

The one thing the hackers (and arguably even governments) are not capable of breaching is strong encryption. If the data on the server is encrypted at all times with keys controlled by individual users, a data breach would reveal very little to an attacker. For this reason, the primary defense mechanism in tiCrypt is the reliance on user-controlled end-to-end encryption, not server security. When coupled with traditional defense mechanisms, tiCrypt offers a much more secure data storage, sharing, and processing solution. In effect, an attacker has to defeat both the encryption-based and the perimeter-based defenses to steal data–a much more challenging task for one to succeed.

Encryption on modern systems

While encryption has been long recognized as a good solution for data security, encryption is believed to be too inefficient for most situations, particularly for the client. With the implementation of hardware of the AES-256 algorithm on both Intel and AMD processors, encryption and decryption are greatly accelerated. 200-300 MB/second speeds are possible on laptops and 1GB/second on servers. tiCrypt takes advantage of these advances and incurs no significant penalty for the extensive use of encryption. Since encryption is feasible on the client, the server is unburdened by the need to perform such operations across the entire usable space. Furthermore, client encryption is highly desirable from a security standpoint since the server is the primary hacking target.

Key management using public key cryptography

One of the main problems when employing encryption is managing the encryption keys of various components. Key management becomes a severe problem if the user must remember passwords for each independent entity that needs to be encrypted. Even more importantly, secure sharing requires a secure hand-off of encryption keys to another party. Sending such keys through other means (email, phone, etc.) would significantly undermine the system's security. The elegant Solution tiCrypt uses is based on public key cryptography: each user, at account creation time, creates a public-private key pair. Secure hand-off of encryption keys to a second party is as easy as encrypting the resource key with the public key of the intended data recipient. Public-private key pairs for all participants can solve a much larger set of problems in a system like tiCrypt. In fact, all security features in tiCrypt are rooted in public key cryptography.

Secure components vs. End-to-end encryption

Regarding system security, the traditional approach is to secure each component independently, hoping that this will translate into good overall security. Typical security terms are network security (securing the network such that an attacker cannot snoop on the transmitted data), encryption-at-rest (securing the stored data through encryption so that storage devices cannot be accessed if removed from the system), and application security (securing the data while used by the application so that the information cannot be accessed by an attacker watching the application behavior). Security problems arise at the junction points and, more importantly, can be compromised by the users controlling the juncture points. tiCrypt's approach uses end-to-end encryption: data is encrypted by the user as early as possible and decrypted by the intended destination. No other participant, including admins and hackers, can decrypt the data, whether in transit, stored, or used by the application.

Strongly encrypt all data

A classic mistake is to allow multiple levels of security for the data. In tiCrypt, all data has the same security level, equivalent to top security. While this seems restrictive, powerful sharing mechanisms in tiCrypt allow easy sharing with a large number of other participants. Since differences in performance for performing strong encryption are minor (20% speed difference between AES-128 and AES-256), there is no practical reason to downgrade security, even for low-security resources.

The above ideas allow tiCrypt to provide extreme levels of data confinement. The access to each file, drive, or message is entirely under the control of the user that created the resource and independent of all other resources in the system. Without a cryptographically secure key exchange initiated by the data owner, nobody (including the system administrators) can effectively access the data. When coupled with advanced auditing facilities in tiCrypt, this property allows confinement and deep knowledge of any data leak. In the rest of this document, we discuss the properties of various mechanisms deployed in tiCrypt to ensure data security and confinement.

Security Principles

tiCrypt is based on three security principles: data confinement, public-key cryptography, and end-to-end encryption. Combining these principles is at the core of all tiCrypt security features.

Data Confinement Through Encryption

The key idea behind data confinement is to isolate resources from each other. In particular, knowledge about accessing a resource should not indicate how to access another. The traditional way to enforce data confinement is through access control lists (ACLs). The main drawback of ACLs is that administrators have complete control over them and can bypass any ACL-based mechanisms. Unfortunately, hackers impersonate admins who have the same power, thus effectively breaking data confinement.

tiCrypt primarily employs cryptographic methods to enforce data confinement. Each file, upon creation, gets encrypted with a unique, independently generated AES-256 key. These keys get encrypted with the public keys of the users (and groups) accessing the file and are then stored on the server. End-to-end encryption is performed before moving the data onto the server, while the decryption only occurs at the destination. The existence of an encrypted key on the server now serves the role of the ACL, but, more importantly, the file key can be recovered only if the private key is used.

File sharing is performed by a secure key exchange in the browser of the file owner (as opposed to a server operation):

• The encrypted key is accessed from the server.
• The encrypted key is decrypted using the owner's private key. Then the key is encrypted with the destination's public key.
• The key encrypted with the destination's public key is deposited on the server. Notice that this mechanism always keeps the private key on the owner's side; only public keys are available to all other users.

tip

With tiCrypt, each file or drive gets encrypted with a unique AES-256 key. These keys get encrypted with the public keys of the users (and groups) accessing the file. End-to-end encryption is performed before the data is moved onto the server, and the decryption occurs at the destination.

Public Key Cryptography

THE DEFINITION OF PUBLIC KEY CRYPTOGRAPHY

Public key cryptography uses two keys per user: a public key known to everyone and a private key known only to the particular user. For example, if user Tom wants to share a message with Jim, he uses Jim's public key to encrypt the message and send it securely. Decrypting the message requires knowledge of the private key, which only Jim has, making him the only user able to read the message. Until 1977, such public-private key schemes were believed to be impossible. Such cryptographic systems were introduced through the pioneering work of Rivest, Shamir, and Adleman. Mathematically, a public key cryptosystem needs a core problem that is easy to solve in one direction but hard in the other. In the case of RSA, multiplying primes is relatively easy, but factoring a product of large primes is very hard. The public key is a fixed exponent $e$ and the product of the primes $n= pq$. The private key is ${d = \dfrac{(p - 1)(q - 1)}{e}}$ and $n$.The public and private keys are opposites of each other: messages encrypted with one have to be decrypted with the other. Specifically, for $m$ a message, $m^e$ mod $n$ is the encrypted message; it can be decrypted by performing $d(m^e)$ mod $n = m$ mod $n$. Conversely, $d^m$ mod $n$ is a digital signature that can be verified by performing $e(d^m)$ mod $n = m$ mod $n$.

Beyond the mathematical details, two rules must be remembered when using any public key system. When data is first encrypted with the public key and decrypted with the private key, we call it process encryption. When data is first encrypted with the private key but decrypted with the public key, we call the process digital signature. tiCrypt uses both mechanisms to achieve secrecy and authentication.

USING PUBLIC KEY ENCRYPTION

Public key encryption is at the core of all security mechanisms used within the modern-day web. Parts or all of its principles are used, from banking to social media. Public key encryption principles allow:

• Checking the authenticity of a website through SSL certificates
• Establishing a secure communication channel with the web server
• Digitally signed and certified messages

Public key encryption removes the need for passwords or secrets to authenticate users, establish secure communication, or sign messages. The private key of the pair is now the means to achieve security. The pair's public key is made widely available and stored in plain text on servers, client computers, or even business cards. The magic of public key encryption is that everybody can encrypt using the public key, but only the private key holder can decrypt. Conversely, documents can be digitally signed using the private key, where the authenticity of the signature can be verified with the public key.

Of course, the larger the key, the more secure the data encrypted with that key is. It is estimated that it would take half a million desktop computers running for 13 billion years to derive the private key from an RSA-2048 public key. This is the type of key each user has within tiCrypt and the type recommended for government use by the NIST FIPS 140-2 publication.

tip

A digital signature scheme typically consists of 3 algorithms

1. A key generation algorithm selects a private key uniformly at random from a set of possible private keys. The algorithm outputs the private key and a corresponding public key.
2. A signing algorithm that, given a message and a private key, produces a signature.
3. A signature verifying algorithm that, given the message, public key, and signature, either accepts or rejects the message's claim to authenticity.

KEYS ALLOW FOR FEATURES

Since public key encryption is versatile, it makes sense to give each user a key. This allows users to do the following securely:

• Authenticate/Login: To authenticate, the user first enters the password to decrypt the private key stored on their computer. Next, the private key is used to sign a challenge generated by the server. Finally, the server checks the signature against the user's public key on the server. If it matches, the person has proven to hold the private key and is thus authenticated.
• Share Files: Sharing occurs without a file password/secret. Encrypting the file's symmetric key with the other user's public key ensures that only the recipient can decrypt their key to the file.
• Issue Certificates: Certificates are a list of instructions digitally signed using the private key. They entitle other users to perform operations on the owner's behalf.

End-to-end Encryption

End-to-end encryption refers to the security principle that requires the data to be encrypted as soon as possible and decrypted as late as possible. Only the intended recipient of the data should have the decryption keys and should perform the decryption just before they plan to use the data. In this form, end-to-end encryption ensures maximum data security since it reduces to a minimum the opportunity for an attacker.

• Since encryption occurs on the client side with a key controlled by the user, end-to-end encryption is possible and entirely under user control.
• Man-in-the-middle attacks, otherwise known as interception attacks, are prevented independently of SSL. Even if the SSL certificate is compromised, the communication is still secure.

End-to-end encryption is strictly more secure than encryption in transit because the files are not decrypted until the verified recipient views them. Encryption in transit allows admins and any hacker with access to the proper certificates to decrypt the files. In all cases, tiCrypt implements end-to-end encryption, even if the file is accessed or shared multiple times. Should a file be needed multiple times, it is decrypted multiple times with no copies residing in unsecured storage, each time implementing end-to-end encryption.

Advanced Security Features

tiCrypt has several advanced security features that address sophisticated attacks and allow key recovery under strict situations.

Public Key Signing and Chain of Trust

While using public key cryptography such as RSA-2048 ensures significant hardening of the system, there is still a considerable vulnerability an attacker can exploit: exchanging a user's public key with a public key controlled (i.e., for which the private key is known) by the attacker. Should a file be shared with the fake user, the attacker can decrypt the data. This attack requires a compromise of the server. It only applies to future file sharing (files shared with the correct key cannot be decrypted), but it is a vulnerability nonetheless. As a preventive measure, tiCrypt uses digital signatures in the following manner to ensure that fake keys cannot be substituted:

• The system uses a site key that is itself signed by a Tera Insights private key verifiable with a hardwired (in both the frontend and backend) public key. The site key is used to bootstrap the security of the entire software deployment. The public part of the site key is readily available to all parts of the system. Its integrity can be checked by checking the digital signature using the hardwired Tera Insights public key.

• The signed key upon creation signs the first super-admin key and its integrity can be checked using the site key.

• Any new account needs to be approved by an administrator. Upon approval, the public key associated with the account is signed by the individual approving (using their private key), thus cryptographically proving the account is valid. This effectively forms a chain of trust for each public key linking to the hardwired Tera Insights key.

• At any point in time, any user can require the digital signatures for the entire chain of trust and validate, on the client side, each key along the way. An attacker cannot inject a fake key unless it controls an administrator key.

Crowd Security

To further strengthen the public key integrity, tiCrypt employs a form of crowd security. In particular, the front end (usually the browser) will store locally, out of reach of the system administrators, fingerprints of the public keys of users previously interacted with. When a file is shared with a user, the tiCrypt frontend will request the user's public key from the server and check that the fingerprint is the same. tiCrypt uses SHA-256 as a secure fingerprinting technique, a NIST FIPS 140.2 recommended secure hashing scheme. The chain of trust combined with crowd security provides a formidable mechanism that is hard for any attacker to defeat. Any irregularity in the use of keys is likely to be discovered quickly, allowing any possibility for a leak to be removed.

Secure JavaScript Delivery

For high availability across platforms, the tiCrypt frontend is web-based and employs technologies such as HTML5, AngularJS, ASM-JS, etc. While this provides a modern, highly functional frontend, using web technologies opens a significant potential vulnerability: injecting malicious JavaScript code that steals private keys.

tiCrypt uses multiple mechanisms to mitigate the risk of compromised JavasScript:

• The tiCrypt frontend bundles up all dependencies and does not refer to outside JavaScript, CSS, or HTML resources. Compromising online JavaScript libraries would not affect packaged tiCrypt frontends.

• The tiCrypt frontend bundle is delivered as a digitally signed Zip archive. The digital signature keys are controlled by two top-level Tera Insights technology executives. This ensures the integrity and security of the JavaScript code.

• Because tiCrypt has multiple client-side configurations and content security checks, we provide users with an application, tiCrypt Connect. tiCrypt Connect serves the frontend locally and will automatically update it whenever it detects a new version. Additionally, clients control which tiCrypt versions are available to their users. Finally, tiCrypt Connect works in tandem with the front end to establish secure VM connections and ensure that all traffic is authenticated, locking down sessions if unauthenticated.

Key Escrow

Since the loss of a private key translates into a loss of data access in tiCrypt, a key recovery mechanism – key escrow – is needed to prevent data loss. In contrast, a key recovery mechanism that is too easy is a significant security risk. In tiCrypt, the key recovery using the escrow mechanism is designed to require the cooperation of multiple people to protect against individual key loss. Specifically, tiCrypt requires a minimum of three escrow keys to be used. These escrow keys need to be signed with the site key (not with any of the admin keys) and can be used exclusively for escrow activities (i.e., not for regular user activities). A user key is placed in escrow using the following mechanism:

1. When the user key needs to be (re)escrowed, the escrow keys with their digital signatures are downloaded from the server.
2. Digital signatures of all escrow keys are verified against the site key (which is itself previously verified against the hardwired key).
3. An AES-256 random key is generated for each escrow key and then encrypted with the corresponding escrow public key. These encrypted keys are stored on the server.
4. The combination of the AES-256 random keys, one for each escrow key, is used to encrypt the user's private key and then store it on the server.

tip

An essential part of this scheme is that the private keys cannot be recovered if any part is missing.

To recover the user's private key, all escrow key holders have to securely transfer their part of the key to a designated party. An essential part of this scheme is that the private keys cannot be recovered if any part is missing. Moreover, none of the escrow key holders can recover the key – only the designated party can.

Secure Virtual Machines

tiCrypt allows secure computation through the use of secure virtual machines. The specific mechanism employed is fundamentally different from existing cloud solutions. In particular:

• Securing at start-up: The VM controller will secure the VM during the start-up sequence by changing all passwords and blocking any ports except for port 22.

• Accessing VMs: For security reasons, virtual machines in tiCrypt cannot be accessed using traditional methods. In particular, direct connections to the VM console, SSH logins, or other remote server technology are not allowed since the admins can control it, and thus hackers impersonate them. The only means of communication is through a secure channel that only the owner of the VM can connect to via proxy within tiCrypt:

  • When a VM starts, it gets the owner's public key.
  • During secure channel setup, the VM and the user co-authenticate each other using the respective public and private keys.
  • A secret channel key is negotiated (Diffie-Helman protocol) and used for communication.

• Encrypted Drives: In order for the VM to perform efficient computation, it needs access to fast, secure storage. This is provided in the form of encrypted drives. When using encrypted drives, regular applications are secured since their input, output, and intermediate results are now protected by cryptography. The drive encryption keys are generated and manipulated in the same manner as the file keys. The user-VM encrypted channel transmits such keys to the VM during the start-up sequence. This way, the user fully controls the drive encryption; even admins are prevented from accessing the data.

• Access to the data store: The VMs can access the main data store through secure sub-sessions created by the client and file keys passed through the encrypted user-VM channel.

• Secure TLS-Based Tunnels: Using the user-VM secure channel, the VM controller can set up a proprietary FIPS-180 compliant TLS tunnel between the user's computer and the virtual machine. The TLS tunnel uses exclusively public-key-based login and temporary private keys. All traffic between a user's computer and the virtual machine is sent through this tunnel. Effectively, any communication between them is now possible with no possibility of snooping by any other party (including the system administrator). This method is even more restrictive than SSH, as the protocol does not allow any commands to be run on the remote machine.

• Restricted outbound Internet access: The VMs have severely restricted Internet access: only the tiCrypt backend and licensing servers can be accessed directly. The main reason is to protect against accidental or intentional information leaks. Even if a VM is hijacked, the only way to leak information is through the main vault, which is audited.

tip

Using secure virtual machines in tiCrypt, it is possible to run and securely communicate to remote versions of any Windows or Linux distributions. The virtual machines are cryptographically and physically isolated from the outside world; only the user has access through tiCrypt.

Principles of concern:

1. The most important principle is: VMs are owned by the user- a dedicated owner; and not by the admins. Compromising the admin doesn't give you implicit access to the resources in the system.
2. Authenticated network access is not dependent on measly passwords; but rather on highly controlled public key infrastructure.
3. No open ports on the VM to block everything implicitly.

Now comes the question, how is the VM usable if no ports are opened?

• By blocking all the ports, we essentially have a bunker at our hands, and we need a special mechanism to talk.
  This can be done by binding the VM with a public key, which is further bound to the user's public key. tiCrypt enables the communication between the front end and the VM by exchanging the secret using Diffie-Hellman plus Digital Signatures to facilitate co-authentication. This sets up a symmetric encryption key used for communication moving forward. Thus, as a consequence, a double encrypted channel is set up. tiCrypt uses encrypted web sockets; data is encrypted with the symmetric key. Rest encryption is achieved with the derived secret, and transport encryption is achieved with Diffie Hellman exchanged secret. The backend only comes into play during the first call, and post that, it never comes into the picture of communication between the front end and the VM. All snooping- whether from external actors or from the infrastructure is avoided.

• The mechanism mentioned above is completely password-less, but at times OS in VMs does demand the presence of passwords. In these minute use cases, passwords are always programmatically generated, quite complicated, and managed while being ephemeral in nature.

• Images used as a boot image are immutable and reset automatically on boot, providing an extra layer of security and eliminating any persistent internal risk.

Data Migration

Tera Insights has thoughtfully designed tiCrypt with a variety of secure data migration methods, giving users the flexibility to choose the most convenient option that aligns with their operational needs. Here are the three primary ways to securely transfer data into tiCrypt from external sources:

• Upload via Browser into Vault: This method allows for smaller files to be uploaded directly into the user’s Vault via the browser running the tiCrypt application.

• SFTP or Inbox Credentials: This method allows users to generate Secure File Transfer Protocol (SFTP) or Inbox credentials. With these credentials, external users can directly send files to the user's Vault in the tiCrypt system. This secure import mechanism uses the user’s public key to encrypt the files, ensuring that only the user who set up the SFTP or Inbox credentials can access and decrypt them. Notably, the tiCrypt SFTP server or Inbox can be hosted separately from the tiCrypt backend server. Once data is securely imported into the Vault, users can then move it to specific Virtual Machines (VMs) within the tiCrypt system.

• VM SFTP via tiCrypt Connect: If users have the tiCrypt Connect application running, they can generate SFTP credentials to directly transfer data into a VM. This process requires an active user account and the tiCrypt application running, as the connection to the VM and the proxy connections are managed and controlled by the application. This method provides an efficient direct path for data transfer into the desired VM.

• External Drive Builder: The tiCrypt Drive Builder tool allows users to create and populate virtual drives externally from the tiCrypt system. The user can sign and encrypt these drives using their public key. Once the virtual drive is ready, it can be copied over into the tiCrypt drive pool and made visible to the user. This option is particularly useful when dealing with large amounts of data, as it allows for bulk import.

• External Cloud Services (Dropbox, Google Cloud, OneDrive.): Users can link their external cloud service accounts to tiCrypt, facilitating a secure and direct one-way transfer of data into the user's Vault within the tiCrypt system. This method provides an easy and familiar route for users to import data, leveraging their existing cloud storage solutions. As with other methods, this process ensures the data remains secure during the transfer, maintaining the confidentiality and integrity of the data.

Each of these methods prioritizes security and user control, ensuring that data migration into tiCrypt is not only flexible and efficient but also maintains the integrity and confidentiality of the data throughout the process.

Infrastructure

The tiCrypt system consists of a back-end server and multiple servers that host virtual machines. Each of these servers acts as a service, performing independent actions, with the notable exception of services that rely on each other, like the file manager and storage. The system is designed to be resilient, ensuring that an error in one service does not affect the entire system.

tiCrypt is designed to run in isolation from other resources in your organization and to have strictly controlled entry points. The system utilizes a distributed file system to connect the main server with the VM servers.

tiCrypt can be deployed on new or existing hardware clusters as a private cloud solution for your researchers. Additionally, if a cloud option is preferred, tiCrypt can be deployed in AWS on BareMetal infrastructure.

System Requirements

1. Software Requirements:
   • RedHat Enterprise, CentOS, Rocky, or Springdale
   • Distributed file system tuned for specific system workflows
   • Java JRE version 8 or higher.
   • Libvirt and QEMU installed on all VM servers.
   • SSH installed on all VM servers (libvirt management uses SSH).

2. Network Requirements:
   • External connectivity: 1Gbit/s or better (10Gbit/s preferred).
   • Internal connectivity: 10Gbit/s or Infiniband (Infiniband preferred).
   • TLS connectivity for the REST interface and static assets.
   • A range of ports (10-100) for SSH Proxying opened on the public-facing server.
   • A firewall protecting the installation in front of the public server.

System REST Service

The system uses a central AUTH service for authentication. All requests and transactions go through AUTH to validate them. Users interact with the system through a REST service, which then delegates tasks to relevant services. For example, a request to start a VM will go through the REST service, be authenticated by AUTH, and then be sent to the VM service.

Three services - AUTH, FILE MANAGER, and VM - utilize and store data in a database. Each service has its specific configuration files that dictate the preferences related to the service. These files are stored in /etc/ticrypt and are named according to the service they correspond to.

Distributed File System & Storage

tiCrypt's storage management revolves around two primary components: the tiCrypt Vault and Encrypted Drives in Libvirt. Here is a concise overview of how these components function:

1. tiCrypt Vault

The tiCrypt Vault is an advanced file system-like facility. It maintains all metadata, such as file properties, directory entries, access information, and decryption keys, in a MongoDB database utilized by the tiCrypt-file storage service.

Files within the Vault are divided into 8MB chunks, each individually encrypted with a unique file key. These chunks are stored in a directory structure, accessible only to the tiCrypt backend. This setup ensures that without the corresponding decryption keys, the content of the chunk files remains indecipherable.

The tiCrypt Vault offers flexibility in terms of storage filesystem and integration with other systems. However, to ensure compliance, it is recommended to restrict access to only the tiCrypt backend.

2. Encrypted Drives in Libvirt

tiCrypt employs Libvirt to manage virtual machines' disk images and encrypted drives. These are stored as files in the distributed file system accessible to all Libvirt host servers. Libvirt, and by extension tiCrypt, is not particular about the choice of file system where various disk pools are defined.

Newly created tiCrypt disks are left blank, with their formatting deferred until their first attachment to a tiCrypt virtual machine. This process is a deliberate design decision to ensure that the encryption/decryption key for the encrypted drive remains confidential, even from the infrastructure, including the tiCrypt backend and Libvirt.

The formatting process is handled differently based on the underlying operating system:

• Windows: An NTFS file system is created, and BitLocker is immediately enabled, ensuring all subsequent data is encrypted. BitLocker uses full volume encryption, including metadata, limiting the information visible to external tools.
• Linux: The Linux Unified Key Setup (LUKS) full disk encryption mechanism is utilized. LUKS places an encryption block layer between the raw drive and the file system, usually EXT4, ensuring all information on the disk is encrypted.

Bootstrapping the System

The system uses a site key, signed by a Tera Insight’s private key, to bootstrap the security of the entire software deployment. The process involves the following steps:

• Generation of Site Key: The site key must be generated and handed over to Tera Insights for countersigning. This key is used to bootstrap the entire system and is a very important security component.
• Adding Escrow Groups: From the site key interface, escrow groups need to be added. These groups allow redundancy in key recovery efforts.
• Adding Escrow Users: Escrow users need to be added. These users allow key recovery in case of loss or malice.
• Creation of Super-admin Accounts: At least one, but preferably two, super-admin accounts have to be created. Super-admins coordinate the rest of the bootstrapping process, activate accounts, and change roles.

Combining tiCrypt with traditional defense mechanisms

Since tiCrypt is a software-based solution, it can be easily combined with traditional defense mechanisms like multi-factor authentication and perimeter defenses in order to provide extra layers of protection. An attacker must defeat all these mechanisms for a data breach, which is a much more challenging task.

• Multi-factor authentication:
  tiCrypt has very strong security; leaked private keys can still result in the loss of the information covered by the key. The attacker can use the stolen key to impersonate and access all user files. As an added layer of protection, extra authentication factors that are independent of tiCrypt keys and the passwords protecting them can be added to the system. Since, typically, organization-wide or token-based second-factor authentication is already in place, tiCrypt can leverage the existing mechanism as an extra authentication factor.

  The primary mechanism to accommodate extra authentication factors is to detect when the private key is used unusually. Specifically, if a key is used from a machine that was inactive for a set period by the same user or was never used, the tiCrypt authentication protocol will require the use of the extra factors to prove the authenticity of the request independently. If a private key is stolen and used from another computer, the second-factor mechanisms will catch that and still deny access.

• Perimeter and server defense:

  First, the tiCrypt deployment does not require regular user accounts on the hosting server; most server-side vulnerabilities are eliminated. Only system administrators need access to the server; thus, access can be highly restricted. Moreover, strong authentication based on SSH public keys can be deployed for management purposes, thus rendering most password-based vulnerabilities ineffective.

  Second, the server running the tiCrypt backend requires only two entry points: SSH access for management used exclusively by the administrators and HTTPS access for the tiCrypt interface. All other ports can and should be blocked to reduce the server's attack surface further.

  Third, tiCrypt is a software-based solution with encryption controlled by the client. It does not require special security appliances or unique setups on the server. All existing security mechanisms, like firewalls, intrusion detection, system auditing, etc., are compatible with tiCrypt and can be used to strengthen the server. Organizations can leverage all existing expertise in system security to add these extra layers of protection.

Threat Model and Solutions

With current events running rampant with news on cybersecurity attacks and hacks, we have researched cybersecurity breaches from 2007-2015 and analyzed why a specific breach was able to occur and how tiCrypt use would have prevented it.

Problem: Server Misconfiguration

Over a short time, one or multiple servers are misconfigured, not using two-factor authentication, or left unsecured. There are no formal systems to check for misconfigurations, and a server rebooting improperly is often enough to cause this problem.

Solution: In tiCrypt, if a server is misconfigured, it will lock the system. Breaking into the backend servers provides no benefit and is not helpful in any way to an attacker. Even if the authentication fails completely (for example, the authentication server somehow forgets to authenticate), the accessible data is useless without the private keys held only by the various users. In no scenario can tiCrypt leak present or future unencrypted data.

Problem: Insider Threats

If admins have access to all the data, any of them can steal before being noticed. Audit logs are useless since they require too many person-hours to review and keep up-to-date. Unless unforgeable audits are used for files, traditional records will not effectively serve as a deterrent. Even if everything is logged, a perfect solution for log analysis must be in place. Otherwise, it will be months before any rogue activity is noticed. Edward Snowden managed to steal tens of thousands of documents from a system with higher security than FISMA, all because he was a systems admin.

Solution: In tiCrypt , isolating the system administrators from the standard users is trivial. Based on the audit log, we can formally check that the system administrators do not have access to any user information. Since any legitimate access happens through the tiCrypt system, log mining will reveal any irregularity within minutes.

Problem: Authentication Attacks

The authentication server becomes another point of failure. If data in the system is valuable enough (medical data is valued at $50-500 per medical record), protecting the server becomes a serious problem. When using fake authentication certificates, anybody can be impersonated without any existing password cracking.

Solution: In tiCrypt, all public keys are digitally signed, and fingerprints of public keys are stored on the client for all users. An attacker cannot switch keys in an attempt to trick users into sharing information using keys controlled by the attacker. The fingerprinting is particularly hard to fool since this data is stored client-side, outside the server's reach.

Notice that a user attempting to share information with another user can validate the key of the destination even with a compromised server. The validity of the trust chain can be established independently of the server and cannot be compromised without breaking public key cryptography.

Problem: Zero Day Exploits

If zero-day exploits, which are undisclosed vulnerabilities that could be exploited, are found for any of the servers, data on that server can be stolen. If such exploits are found for the authentication server, data on all servers can be stolen. While audit logs help identify what was compromised, they do nothing to prevent the attack. If the security is based on foolproof authentication alone, this becomes very problematic. If the data on the server is valued at upwards of $10 million (as it often is when medical data is stored on the server), such high-end attacks are probable.

Solution: tiCrypt thwarts all backend attacks using end-to-end encryption, even if attackers controlled the servers for months. This is because the decryption keys are not available on the server; the server is never involved in either encryption or decryption of data. At worst, a breach of the server makes the system unavailable but not insecure.

Compliance and Monitoring

tiCrypt is built to be HIPAA, FISMA, and FIPS compliant. With the use of our high-powered data engine, tiCrypt's audit logs can be mined and reviewed for irregularities and suspicious activities. 30+ types of events are tracked at the millisecond time stamp level to ensure a complete record of all actions.

• Compliance within tiCrypt: tiCrypt was built to meet the needs of organizations with sensitive data. tiCrypt adheres to HIPAA, FISMA, NIST 800-71, and FIPS compliance requirements where appropriate. It is FIPS 140-2 certified in the Mozilla browser with FIPS mode enabled in settings. tiCrypt utilizes NIST 800-71 guidelines for access control, identification and authentication, and audit and accountability. The system has been certified by the University of Florida. For more compliance information or to request to view the System Security Plan (SSP), please contact info@terainsights.com.

• Secure Log Authentication: While protecting files against rogue employees and outside attacks is crucial, providing an audit trail of who accessed what information is essential. While most regulatory agencies mandate basic audits, tiCrypt goes beyond this minimum requirement and offers detailed, secure audits combined with forensic tools to analyze the logs.

• Securing the Log: Using secure hashing (SHA-256), log entries are chained much like Bitcoin transactions. Knowledge of the hashes ensures that admins or hackers cannot change or forge the history. Should anybody change the log entries, the hashing of the modified block will have a conflicting hash, making the change detectable upon running a log audit.

• Events Audited: More than thirty events are monitored in the Audit Logs, giving the System Admin a full profile of events:

  • Requesting, challenging, looking up, or deleting a certificate session or sub-session
  • Creating, deleting, renaming, adding, or removing a directory entry ƒƒ
  • Creating, deleting, or registering a proxy for virtual machines ƒƒ
  • Attaching, detaching, creating, or deleting a virtual drive – and adding, retrieving, or deleting a key to a virtual drive ƒƒ
  • Creating or deleting a file – and adding, retrieving, or deleting a key to a file – and reading or writing a chunk of the file
  • Creating, deleting, or modifying members and permissions of a group; Adding, deleting, or modifying permissions of a user