Overview

Due to the nature of our product, Trinsic is charged with the protection of highly-sensitive data. Security is baked deep into Trinsic's platform as a top-level concern. Our security philosophy can be described by a few core tenets:

1. If it's software, it can be hacked ("Assume Breach")

This is an obvious -- if unfortunate -- observation, from which the rest of our philosophy naturally flows. Modern software is incredibly complex, and is written primarily by fallible humans (that's us). While it is theoretically possible to create software with no security vulnerabilities, the unfortunate reality is that every real-life system can likely be hacked with a certain amount of resources, effort, skill, and luck.

This is also known as an "Assume Breach" paradigm: assume that your system will be breached, such that you can minimize the damage when one occurs.

Of course, it is always best to never have a security breach in the first place. This is our top priority; one we pour considerable effort into.

2. Data we don't have access to is data that cannot be stolen

In the event a breach does occur, Trinsic's approach to data security (including novel mechanisms described below) serves to significantly minimize the volume of data that is vulnerable.

We don't store data unless we truly need to for a legitimate product function that benefits you or your users. We do not sell user data to anyone, so we have no interest in hoarding it.

For the data we do have to store, we take care to store it for the least amount of time necessary. Of course, we employ industry-standard at-rest data encryption for our database and cache.

However, while at-rest data encryption is useful, it still encrypts data in such a way that we have access to it at rest, because we have access to the key (or HSM) necessary to decrypt the data. Any data that an organization has access to is data that a successful attacker also has access to.

Therefore, for as much data as possible, we store it in such a way that we cannot access it ourselves. This is explained in further detail below.

3. Build on best practices

Trinsic's data security solution involves some proprietary approaches which we believe significantly elevate our level of security compared to the industry at large. However, we recognize that industry best practices are designated as such for a reason, and it would be irresponsible not to make use of them.

The total security of any software system is composed of a number of layers. Each layer has different strengths and weaknesses, and no layer is ever invulnerable. By incorporating many layers of security -- and ensuring each of those layers is based on solid security foundations and is strong -- systems can be built to be highly secure, if not entirely invulnerable. Most of these layers are formed by properly implementing best practices.

Trinsic's "assume breach" philosophy places a special focus on minimizing the damage of a hypothetical catastrophic breach, and employs a number of novel techniques to do so. However, we also put great care into ensuring our system is as resilient to breach as possible by making use of industry best practices.

Basic

This section covers industry-standard ways in which we protect user data.

At-Rest Encryption

Per industry standards, all sensitive data is encrypted at rest using AES-256 with integrity checks provided by our Cloud infrastructure provider.

Application-Level Encryption

All sensitive data is encrypted at the application layer using AES-256-CBC + HMAC-SHA256 (encrypt-then-MAC) with integrity and context checks. We use separate keys for encryption and signing.

It should be noted that little data is protected solely by application-level encryption. User identity data is protected by the Session Data Vault approach described in Advanced , encrypted in such a way that Trinsic cannot decrypt it at rest.

Key Rotation

Our application-level encryption key is rotated on a monthly basis. All rotation events are carefully controlled, logged, and alerted to prevent silent failure of this system.

Application-level encryption keys are stored in Azure Key Vault; access to this vault is highly restricted with a principle of least privilege.

Keys are retained for 2 months after they are rotated away to allow for asynchronous re-encryption of data.

Data Scope & Lifetime

As mentioned above, we store as little data as possible, for as little time as possible.

Once identity data ceases to be of use to you or your user, it ceases to be of use to us -- so we delete it.

Redaction

We employ a mandatory data redaction policy with a maximum lifetime of 1 month, which is the longest amount of time a session's data will be stored in our systems.

Sessions can be redacted at any time prior to their scheduled redaction via the API, potentially reducing the total time data is present on Trinsic's servers to seconds.

Monitoring and Alerting

We employ industry standard monitoring and alerting to aid with detection of a breach or other security concerns.

Advanced

This section covers enhanced techniques that Trinsic employs to protect user data.

End-to-End Encryption

Session Data Vault

When a user begins a session, we create a secure data vault specific to that session. This data vault can only be accessed with a key that is itself encrypted by our system key and stored securely in the user's cookies, and which we do not save or log anywhere in our backend -- we do not retain it.

Whenever the user is interacting with our product (that is, sending an HTTP request to our backend), we have access to the vault's key in-memory, allowing us to store and retrieve data to or from it. However, at rest (that is, outside the context of an HTTP request from said user), we have no access to the key necessary to access the data, meaning an attacker also would not be able to access it.

This approach allows us to store sensitive data in our backend during the context of a user session, while allowing the user's browser to manage the actual encryption key to access the vault. Our backend has access to the vault only when the user is "on the line".

Although our servers inherently must process user data in-memory, this data is never stored in such a way that our systems can decrypt it at rest. Without the resultsAccessKey for a session, or a user "on the line" in an active HTTP request, we (and therefore attackers) truly cannot decrypt user data.

Our session data vault approach significantly reduces the blast radius of a complete database, cache, log, and system encryption key compromise. Barring an in-memory breach or traffic sniffing attack, user data cannot be decrypted by attackers. Even in the event of a total server hijack or traffic exfiltration, data leakage is limited solely to that which flowed through our systems during the breach period.

This approach -- intentionally blinding ourselves to user data, despite increased operational cost -- is the natural conclusion of Trinsic's philosophy on user data: it is not ours to hoard, to lose, or to sell.

Results Access Key

When your user completes a session, Trinsic needs to save the resultant identity data in such a way that it can be delivered to you when you call the Get Session Results API.

To ensure that Trinsic cannot access this data at rest, we store the identity results in the aforementioned session data vault, and embed the decryption key in the resultsAccessKey that is delivered to you via our clientside SDKs, redirect URL, or upon session creation.

We do not save or log the decryption key for the identity data, and so can only access the data during the course of the Get Session Results API call.

Regulatory Audit Logs

Some Identity Providers offered through Trinsic's platform have terms or legal regulations which require Trinsic maintain records of all verifications for some time.

To comply with these laws while maintaining user privacy at rest, Trinsic employs a "cold storage" logging system, whereby said audit logs are encrypted asymmetrically against a public key. Access to the corresponding private key is strictly limited and separated from Trinsic’s operational infrastructure.

The encryption scheme employed is X25519 Key Agreement, with AES-256-CBC + HMAC-SHA256 (encrypt-then-MAC) as the symmetric cipher. We use separate keys for encryption and signing. We are eagerly anticipating proven post-quantum asymmetric schemes, and will adopt them when appropriate and responsible.

The above applies only to those specific Identity Providers for which Trinsic is legally required to keep such logs.

Dashboard Data Visibility

When customers have end-to-end encryption turned on, the results of their verifications are not accessible by Trinsic at rest; this also means Trinsic can't display the results in the Dashboard. Therefore, we give customers the option to turn end-to-end encryption mode off in cases where customers need to view the results of their verifications in the Dashboard. To accomplish this, Trinsic retains a read-only copy of the resultsAccessKey for any given session.

This feature provides a compromise between functionality and security for scenarios where it's important to view verification results in the dashboard. For production apps, we recommend you only disable end-to-end encryption if viewing verification data in the dashboard is an absolute necessity.

Conclusion

End-to-end encryption allows Trinsic to store data for a legitimate user-focused purpose without having access to it at rest. This approach allows us to drastically reduce the data that is accessible by our systems (and therefore by a hypothetical attacker), which ultimately helps ensure the safety of your and your users' data. Automatic and manual data redaction significantly reduces the lifetime of user data on the platform.