Skip to main content

Role Dynamics

Overview of User Roles​

Roles are a tag to define the user seniority in the system.

Regardless of the role, the user retains the same permissions. For example, if "John" has 24 permissions as a User and is promoted to Admin, he will retain 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 in the system using User Profiles. So that whenever a user gets promoted or demoted and changes the profile, it will 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 with 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 make an account using the signed digital key from Tera Insights team.

This role is separate from the main system because it serves the purpose of signing keys for escrow operations or digital certificates for special actions requiring private key recoveries 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 usually penetrated using the forgot my password option. tiCrypt has an escrow mechanism that ensures full security during a private key recovery via the public key + the site key + escrow key. The sum of multiple escrow members' keys, a digitally signed key from Tera Insights along with the execution of Super-admins is commonly involved in the recovery process. The system forces members to communicate traditionally to prevent impersonation and social engineering attacks. The process has a simple UI requiring several recovery steps for lost account access.

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 are never alone as they are part of an escrow group.

Each user in the system no matter their role is assigned to an escrow group in order to be able to have their private keys escrowed in case they are locked out of their accounts.

Escrow groups release escrow certificates, there are minimum three escrow groups per deployment in each institution for security purposes.

Each escrow group is formed by three to five escrow users who hold a part of the key. In other words, the escrow key of each escrow group put together with the Site-key Admin's digital signature and Super-admin's execution is the only way to recover a user's lost private key. This is a slow process in a traditional way, drastically minimizing 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.

Super Admin​

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

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

Super-admins oversee the whole 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 Sys Admins to run commands for the backend, perform system checks and ensure smooth use 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 an 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 an easy time carrying out both simple and complex projects. Both Super-admins and Admins are not needed to manage the system 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 in the front-end. They are not required to use command lines to navigate their vault or virtual machine environments.

Auditing & CTO Reporting​

Super-admins can perform direct reporting to decision-makers at anytime by generating an audit report at a press of a button. The results will showcase how users behaved if they did their homework and how far the system infrastructure evolved from the installation day.

This operation allows comprehensive system data forecasts. (i.e., If a user does X repeatedly in the future, it will trigger a Y trend in the infrastructure.)

Once a report has been made, it leaves a compliant trace in the tiCrypt Audit. tiAudit will keep track of all actions of all users roles in the main system and make the system engineer and the 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.

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).

A powerful functionality in tiCrypt for Admins is the variety of workflows that can achieve similar objectives. Admins can maintain user permissions via User Profiles. They can 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 on their local machine. The Admin monitors the user, it does not micro-manage the user.

Admins manage users' team ownership, authentication, and access authorization.
They grant users' activation status and collaboration collectives 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 infrastructure to filter security. (i.e.: Having a project unlocked or access controlled, or access control + cryptographically secured at the same time).

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 enables resource constraints for a collection of users. This management belongs to the Sub-admins, enabling one 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 rely on their project memberships to be part of a project including the Sub-admin. Project memberships can be given only by the Admin, the group creator, or the Sub-admin assigned to run the project.

User​

User is the default role for anybody added to the system, and has no default permissions or priviledges 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.

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

Virtual Machines functionality​

Virtual machines operate on isolated single ports to the local machine without any internet connection. This architectural tunnel avoids any data leakage or penetration possibility. Users still have internet connection, aka their local machines.

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.