Security Principles governing tiCrypt

Executive Summary

Judging by the continuous stream of data breaches, the security mechanisms widely deployed, such as back-end 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 posed internally.

The primary assumption behind the tiCrypt design is that back-end 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 a direct 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 key management nightmare is avoided in tiCrypt through public key cryptography. Each user, upon account creation, 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, and this ensures 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 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 the needs of organizations with sensitive data by complying with the major regulatory departments (HIPAA, FISMA, FIPS).

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. It seems that 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. It seems that no amount of armed guards, sophisticated locks, firewalls or intrusion detection systems effectively protect 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. To truly correct this flaw and give companies the best chance of avoiding another incident, rethinking the fundamental approach to security is essential.

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 solution to data storage, sharing, and processing. 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 be successful at.

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 on the client. With the implementation in hardware of AES-256 algorithm on both Intel and AMD processors, encryption and decryption are greatly accelerated. Speeds of 200-300 MB/second are possible on laptops and 1GB/second on servers. tiCrypt takes great 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 security of the system. 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. Using 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 the use of public key cryptography.

Secure components vs. End-to-end encryption

When it comes to system security, the traditional approach is to secure each component independently in the hope 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 is to use 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 it is 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 the large number of other participants. Since differences in performance for performing strong encryption are small (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 fully 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. The combination of 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 full control over them and can bypass any ACL-based mechanisms. Unfortunately, hackers impersonate admins 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. Using end-to-end encryption, the encryption is performed before moving the data onto the server while the decryption only takes place at the destination. Existence of an encrypted key on the server serves now 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. With end-to-end encryption, the encryption is performed before moving the data onto the server, and the decryption takes place 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 is 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 need to 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. From banking to social media, parts or all of its principles are seen in use. 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

The use of 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 who has 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 the public key of a user 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 front-end 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, tiCrypt front-end 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 front end, the use of 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 front-end 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 front-end 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 configuration and content security checks, we provide users with an application, tiCrypt Connect. tiCrypt Connect serves the front-end 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 to ensure that all traffic is authenticated, locking down sessions if unauthenticated.

Key Escrow

Since the loss of private key translates into 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 big 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 important part of this scheme is the fact that the private keys cannot be recovered if any part is missing.

In order 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 the fact 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 is not allowed since the admins can control it, and thus by hackers impersonating 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 the 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. 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: The VM controller, using the user-VM secure channel, 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 virtual machine is sent through this tunnel. Effectively, any communication between 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 by 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 noo 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 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 which is then used for communication now forward. Thus, as a consequence, a double encrypted channel is set up. tiCrypt uses encrypted web sockets, and 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 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 hence avoided.

• The above-mentioned mechanism 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 are 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, eliminating any persistent internal risk.

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 further reduce the server's attack surface.

  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 period of 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. 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 to share 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 due to the fact that 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.

tiCrypt’s 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 guidelines for NIST 800-71 for access control, identification and authentication, and audit and accountability. The system has been certified by the University of Florida. For more information on Compliance or to request to view the System Security Plan (SSP), please contact info@terainsights.com.

• Secure Log Authentication: While it is crucial to protect files against rogue employees and outside attacks, 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 the history cannot be changed or forged by admins or hackers. 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