User Roles

Prerequisites

• Access Level: User, Sub-admin, Admin, Super-admin.

Overview

Roles define user seniority in the system.

Changing a user's role does not automatically change their permissions. For example, if "John" has 24 permissions as a User and is promoted to Admin, he retains those 24 permissions until a Super-admin updates them. John could also have a regular User role with 125 permissions, similar to a Super-admin. The only exception is the Super-admin role, which has access to all permissions and can bypass restrictions.

As a best practice, Super-admins should configure predefined permission sets for each role using User Profiles, so that whenever a user is promoted or demoted and their profile changes, they inherit the custom permissions for that profile automatically.

When a user is demoted from Super-admin to another role, they inherit the permissions previously associated with that role.

note

You must have the same role or higher as the user you want to promote or demote.

For compliance purposes, user role changes are permanently audited in tiCrypt from the installation date onward and cannot be erased by any user role.

Site Key Admin

The Site-Key Admin is always the first user to create an account, using the signed digital key from the Tera Insights team.

This role is separate from the main system because it is dedicated to signing keys for escrow operations and digital certificates for actions requiring private key recovery or super-admin escrowing.

The Site-key Admin is the only one in the system that owns the site-key, which is used for digital signatures as part of the escrow network.

Role of the site-key

Systems are commonly compromised through password recovery mechanisms. tiCrypt has an escrow mechanism that ensures full security during private key recovery via the public key + the site key + escrow key. Recovery requires the combined keys of multiple escrow members, a digitally signed key from Tera Insights, and execution by Super-admins. The system forces members to communicate out of band to prevent impersonation and social engineering attacks. The process has a simple UI with several recovery steps for lost account access.

To Remember

Site Key Admin

• The most critical user in the system.
• Partially responsible for enrolling escrow users and groups.
• Responsible for lost user private key recovery.
• Responsible for issuing digital signatures in the escrow process.

Escrow Users

Escrow Users play a vital role in de-escrowing activities and maintaining the escrow system within tiCrypt.

Escrow Users are separate from the main system because their role is to help users, sub-admins, admins, and super-admins recover their lost private keys. Escrow users never act alone, as they are always part of an escrow group.

Each user in the system, regardless of their role, is assigned to an escrow group so that their private keys can be escrowed in case they are locked out of their accounts.

Escrow groups release escrow certificates. There are a minimum of three escrow groups per deployment at each institution for security purposes.

Each escrow group is formed by three to five escrow users who each hold a part of the key. In other words, the escrow keys of each group combined with the Site-key Admin's digital signature and the Super-admin's execution is the only way to recover a user's lost private key. This is an intentionally slow, out-of-band process that minimizes the risk of social engineering attacks.

Key Functions of Escrow Users

• Monitoring Escrow Status: Escrow users can view details about available key escrows for each tiCrypt user, ensuring they stay informed about key management status.

• Key Sharing Among Group Members: They are responsible for sharing their group key with other members within the same escrow group, a necessary step particularly when new escrow users are integrated into the group.

• Key Recovery Assistance: Escrow users can share their group key with a designated escrow user tasked with recovering a specific tiCrypt user's key, provided they have acquired the necessary keys from all related groups.

Important Considerations

• Key Recovery Conditions: A group key can only be recovered by an escrow user when it is explicitly shared with them.

• Escrow User Key Authorization: Generating an escrow user key does not grant automatic permissions within tiCrypt. For an escrow user key to be recognized, it must be counter-signed by the site-key administrator.

• Multi-factor Authentication (MFA): If enabled, using a recovered user private key requires meeting the multi-factor authentication requirements.

To Remember

Escrow Users

• Partially responsible for recovering lost user private keys.
• Always work as part of an escrow group.
• Do not have access to the main user interface.
• Work together with the Super-admin and the Site-key Admin in the key recovery process.

Super Admin

Super-admins bypass all permission requirements and can promote or demote users to any role, including creating and demoting other super-admins.

They can create escrow requests for users that are then signed by the Site-key Admin with the help of the escrow groups.

Super-admins oversee the entire system but do not have access to user, sub-admin, or admin data. Their role is to ensure that every user has the appropriate permissions to carry out their research.

Super-admins work closely with system administrators to run backend commands, perform system checks, and ensure smooth operation of the system infrastructure.

Escrowing Keys

Super-admins are partially tasked with managing key escrow activities to ensure the security and compliance of user data. Super-admins will only sign an escrow key upon receiving it but cannot actively create escrow keys for users without the involvement of both the escrow groups and the Site-key Admin.

Once an escrow request is performed, the escrow key will appear in the escrow group interface, separate from the main tiCrypt system. The generated escrow key will be used for private key recovery in the future and is now the responsibility of the escrow group and Site-key Admin.

• Escrow Activation: Super-admins enable the escrowing of a user's key by setting the user’s state to "Escrow on next login," initiating the escrow process during the user's next login.
• Escrow Removal: Super-admins can remove existing user key escrows by deleting the encrypted group keys shared with escrow users, effectively revoking access to the escrowed keys.
• Order Execution: Super-admins apply orders signed by the Site-key Admin, ensuring they are executed exactly as issued, without modifications.

The tiCrypt escrow process is designed to minimize administrative power.

If a Super-admin declines to change the user's state to Active and Escrow on Next Login, the escrow recovery key will not be generated, preventing future recovery of the user's account.

Security and Compliance Considerations

• Control Over Orders: Super-admins can submit site-key signed orders but cannot modify them, ensuring the integrity of administrative actions.
• Security Violations: Submitting a valid but improperly signed certificate constitutes a security violation and is automatically reported via the tiCrypt Audit system.
• Limited Role in De-Escrowing: Super-admins have a deliberately limited role in the de-escrowing process to prevent potential misuse of power access.

Management Simplicity

The management structure is user-centric, giving users a straightforward experience for both simple and complex projects. Super-admins and Admins are not needed for day-to-day system management but rather to perform the following actions:

• Build workflows.
• Oversee the infrastructure.
• Check audit reports.
• Assist users on rare occasions.

Users never interact with the backend directly. They are not required to use command lines to navigate their vault or virtual machine environments.

Auditing & CTO Reporting

Super-admins can generate reports for decision-makers at any time at the press of a button. The results show user activity, compliance status, and how the system infrastructure has evolved since the installation date.

This operation allows comprehensive system data forecasting (e.g., if a user repeats a pattern of activity, it will trigger a corresponding trend in the infrastructure).

Once a report has been generated, it leaves a compliant trace in tiCrypt Audit. tiAudit tracks all actions across all user roles in the main system, keeping the system engineer and audit team fully aware of what is happening in real time.

tiAudit is a separate system from the main system, therefore, audit users log in separately. Every action is audited from the installation day of tiCrypt until the present moment. Audit logs cannot be discarded due to high security.

To Remember

Super-Admin

• Has system responsibilities.
• Can change anyone's permissions.
• Has access to system settings.
• Has access to global settings (i.e. add external servers, change key caching policy).

Admin

Admins can view and manage everything in the system, provided they have the necessary permissions. They are similar to Super-admins but remain under permission control.

Admins are responsible for maintaining the system and overseeing sub-admins as follows.

• Promote or demote users.
• Make global announcements to users.
• Delegate projects and teams to sub-admins.
• Activate newly created user accounts.
• Set up the necessary hardware to create virtual machines and drives.
• Report any suspicious user or sub-admin behavior to Super-admins (e.g., a user frequently leaves their desk without logging out).

tiCrypt offers Admins a variety of workflows to achieve similar objectives. Admins can maintain user permissions via User Profiles, export data in various formats, and communicate with users via announcements.

Due to tiCrypt's design against social engineering attacks, Admins have no control over users' groups, private files in vaults, or data in users' virtual machines and drives.

Although highly user-intuitive, the infrastructure protects Users from Admins through groups, projects, and virtual machines.
It is the user's responsibility to install tiCrypt Connect on their local machine. The Admin monitors users; they do not micro-manage them.

Admins manage users' team ownership, authentication, and access authorization.
They manage users' activation status and collaboration structures like teams and projects.

Most Admin actions can be performed in bulk, thanks to tiCrypt's scalable infrastructure.

note

User permissions function as ACLs (access control lists) over the underlying PKI (public-key infrastructure).

Management operations are cryptographically secured and access-controlled. For example, Groups and VMs are cryptographic, while Teams and Projects are access-controlled.

tiCrypt goes beyond access control and cryptography, allowing a combination of access control and cryptography in a single container for doubled security.

The current infrastructure of Virtual Machine Hosts allows full housing for ITAR, FISMA, Medical Research, DoD projects, and other similar field research deployments.

Using the Filtering Power

Admins can use filters in the management section to locate users, teams, groups, projects, classified projects, workflows, and other metadata.

Criteria can be customized in the management section, leveraging the tiCrypt backend. This operation does not strain the system in any way.

Admins can use tiCrypt to filter by security level (e.g., projects that are unlocked, access-controlled, or both access-controlled and cryptographically secured).

To Remember

Admin

• Has management responsibilities.
• Similar to Super-admin except:
  • Cannot change/modify global settings.
  • Cannot stop/restart system services (and microservices).
  • Cannot modify super-admin settings.

Sub-Admin

Sub-admins can be assigned to view and manage specific parts of the system normally only accessible by Admins and Super-admins.

Sub-admins are assigned to a team, project, or both by an Admin or Super-admin. This allows sub-admins to partially act as admins within the scope of their assigned objects.

Sub-admins have limited visibility and execution rights compared to Admins and Super-admins.
For example, a sub-admin can manage only the team object assigned to them, while a super-admin can manage all team objects in the system.

Advanced functions, such as XML descriptions and system settings, are reserved to Admins and Super-admins.

Objects Mechanism

Admins and Super-admins assign managed objects to sub-admins via the Sub-admin Managed Objects, enabling them to act as "Administrators" for specific teams or projects.

With the appropriate permissions, Sub-admins can access the Vault, groups, teams, and projects they manage, as well as the Management section associated with these resources.
Sub-admins can manage VMs, be assigned the Manager role, and oversee resources like drives that belong to the teams or projects they manage.

Other responsibilities

• Sub-admins can activate team members, change permissions, manage projects, and perform other admin actions for their assigned team only.
• Sub-admins cannot interfere with other research projects.
• Cryptographic principles ensure that sub-admins and admins cannot access data unless explicitly uploaded or shared with them by the users.

Team Mechanism

Teams enable resource constraints for a collection of users. Sub-admins manage teams, enabling them to add or remove users and edit the resource limits.

If a user is deactivated and belongs to no team

• Sub-admins can onboard and activate the user by adding them to their team.
• This prevents sub-admins from managing users outside their assigned team.

If a user explicitly belongs to a team

• Sub-admins can directly manage the user.

If a user is removed from a team and is no longer a member of any team

• The user account is deactivated, and default permissions are restored.
• A Super-admin or Admin must update the role to reactivate the account.
• This rule prevents unauthorized permission changes.

Sub-admins can create new teams, but these teams will have a default quota that must be increased by a Super-admin or an Admin.

Projects Mechanism

Projects tag resources and seal them via access control, enabling authorization solely for certified members of the project. This mechanism allows drives, VMs, groups and files to be protected and only shared with other users who are part of that project.

Once a project label has tagged a resource, the way it can be manipulated or accessed is significantly restricted.

Sub-admins independently handle:

• Project members
• Subprojects
• Member Certifications

The security requirements and security levels are usually set by the Admins.

• Sub-admins must grant access to users joining a project, whether tagged or untagged.
• The key difference between Users and project managers (Sub-admins) lies in file declassification and complete project tag removal.
• Adding a new Sub-admin to a project with manager roles automatically assigns the project to the Sub-admin.

All project members, including the Sub-admin, rely on their project memberships to be part of a project. Project memberships can be granted only by the Admin, the group creator, or the Sub-admin assigned to run the project.

To Remember

Sub-Admin

• Has team or project responsibilities.
• Manages and modifies user permissions and projects under their own team only.
• Can have multiple sub-admins in the same team. (e.g., ABC Team as preferred).

User

User is the default role for anybody added to the system, and has no default permissions or privileges beyond what they are assigned.

A User is anyone registered in the system. Typically users are researchers simply conducting their work in virtual machines, storing data in their vaults.

Users can independently have their own groups or projects if they are permitted, and must be part of a team to be active in the system.

As a best practice, each team of users or project should have a Sub-admin managing it.

Virtual Machines functionality

Virtual machines operate on isolated single-port connections to the user's local machine without direct internet access. This architectural tunnel prevents data leakage or external intrusion. Users retain internet access on their local machines outside the VM.

User role in escrowing their key

All tiCrypt resources are encrypted under PKI (public-key infrastructure). At its core, each User has a private key that can be used to decrypt the user's copy of the resource encryption key. If a User loses their key, the data files, messages, and drives become unrecoverable due to the theoretical limits of the encryption. To allow Users to regain access to their data in case of private key loss or to enable data access for law enforcement in extenuating circumstances, tiCrypt provides a sophisticated key-escrow mechanism that can recover a User's private key and thus re-establish access. This is achieved through segregation of duties and limiting Admin power, imposing increased friction to reduce the risk of fraud.

User Ethical Considerations

Users should act responsibly and thoughtfully when using tiCrypt. For example, leaving a physical machine open and logged in could result in a physical security breach due to user negligence.

To Remember

User

• Uses the Vault to store the research data.
• Uses Virtual Machines to perform secure research.
• Is part of a team run by a Sub-admin.
• May be part of a project run by a Sub-admin.