Skip to main content

Privacy and Security

Our Encrypted Domain approach ensures that:

  • We ​never ​have access to ​any ​sensitive user data.
  • The user has full control over their data.
  • The user’s data is robustly tied back to a single human being.

We accomplish this with a state-of-the-art ​distributed system — not a massive central database vulnerable to attack and privacy violations. This is the real magic of Unum ID.

Encrypted Domain#

Encrypted Domain: You use SDKs to interact with our Identity Engine cloud. We never have access to sensitive user data. See the Architecture section for more information about each component.

A user’s Unum ID

A credential is a collection of data about a person. It's issued by a company (i.e. created and sent to a user) and stored in the company's app, on that user's device.
+ More...
Example: ACME Bank issues a KYC verification credential to Richard (an ACME user). This includes Richard's contact information and account numbers, as well as a level of confidence in the accuracy of the data.
Components: A company issues credentials using the Server SDK, and an app stores credentials using the Mobile SDK.
credentials are stored locally on their device, in an app using our Mobile SDK. The only ones who ever have access to the sensitive data in each credential are:

  1. the company that issued the credential
  2. the user the credential was issued to
  3. companies the user shares the credential with

The upshot is this: Unum ID coordinates sharing of verified identity data, but we are never able to interact with that data in plaintext. Our sharified identity™ solutions come with unparalleled privacy and security.

Example#

Issuing a Credential#

When you issue (send) a

A credential is a collection of data about a person. It's issued by a company (i.e. created and sent to a user) and stored in the company's app, on that user's device.
+ More...
Example: ACME Bank issues a KYC verification credential to Richard (an ACME user). This includes Richard's contact information and account numbers, as well as a level of confidence in the accuracy of the data.
Components: A company issues credentials using the Server SDK, and an app stores credentials using the Mobile SDK.
credential to a user, that credential is encrypted with the user’s public key. (The Server SDK does this locally on your server and sends the encrypted version to us.) We temporarily store and route the encrypted credential to the correct user’s app but have no ability to decrypt the data. The user’s app then receives and decrypts the credential. See the diagram below.

Issuance: The Server SDK encrypts a credential with a user’s public key before sending it to us. This ensures that only you and that specific user have access to the plaintext data — Unum ID never does.

Sharing a Credential#

note

The shared credential is actually contained in a

A presentation is a set of one or more credentials. It's shared with (or presented to) a company by a user.
+ More...
Example: Richard shares a presentation of a KYC verification credential (which ACME Bank issued to him) with Hooli FinTech.
Components: A user's app shares (or presents) presentations using the Mobile SDK, and a company verifies presentations using the Server SDK.
presentation object, but this is unimportant jargon in this context. See the Mobile SDK and Server SDK docs for full details.

Then, when a user responds to a

A request (or presentation request) is a request for a presentation. It's sent by a company to a user, who chooses whether to share a presentation in response.
+ More...
Example: Hooli FinTech sends Richard a request for (a presentation of) a KYC verification credential from ACME Bank.
Components: A company creates requests using the Server SDK and routes them to users using the Web SDK. A user's app responds to requests using the Mobile SDK.
request for a credential, that credential is encrypted with your public key.(The Mobile SDK does this locally on the user’s device and sends the encrypted version to us.) We store nonsensitive metadata about the encrypted credential and route it to you, but we have no ability to decrypt the data. You then receive and decrypt the credential. See the diagram below.

Sharing: The Mobile SDK encrypts a credential with your public key before sending it to us. This ensures that only the user and you have access to the underlying plaintext data — Unum ID never does.

important

The encryption described above is ​in addition to the standard encryption like TLS that applies to all data in transit and at rest. This encryption is done with a specific public key and ensures only the holder of the corresponding private key can decrypt the data.

Features#

Unum ID solutions have best-in-class privacy and security features. Some of these are detailed below.

Multi-Layer Encryption#

Standard encryption like TLS applies to all data in transit and at rest, but there’s an additional layer. When you send a

A credential is a collection of data about a person. It's issued by a company (i.e. created and sent to a user) and stored in the company's app, on that user's device.
+ More...
Example: ACME Bank issues a KYC verification credential to Richard (an ACME user). This includes Richard's contact information and account numbers, as well as a level of confidence in the accuracy of the data.
Components: A company issues credentials using the Server SDK, and an app stores credentials using the Mobile SDK.
credential to a user, it’s encrypted locally on your server such that only that user’s device can decrypt it (using your app). When the user shares the credential, it’s encrypted locally on their device (in your app) so that only the intended recipient can decrypt it. In other words, Unum ID coordinates sharing of verified identity data, but ​we ​never h​ave access to sensitive data in plaintext.

Secure Mobile Hardware#

A user’s credentials are stored locally on their device, encrypted in your app. This is tied to the trusted execution environment (TEE) and secure hardware of the user’s phone so that the credentials can only be accessed or shared by passing a biometric or passcode check.

note

The secure hardware in a mobile device has the amazing property that an app can ask it to create key pairs and use the private keys without ever directly accessing those private keys. The private keys never leave the device, and even the manufacturer has no ability to access them.

Unum ID uses this to enable end-to-end public key cryptography. But, crucially, we package it behind a simple user experience so that users never need to even know what a public key is.

Privacy and Consent#

Data is ​only ​shared with full consent of the user. Unum ID goes far beyond what’s needed for compliance with GDPR, CCPA, and other privacy regulations.

Local Cryptography#

All cryptography (key generation, signing, encryption, etc.) is done locally, on your server or in your app on the user’s device. We provide software that makes this easy to do, but all operations are done independently of Unum ID. This ensures ​your security is under your control.

No Shared Secrets#

We use zero shared secrets: no passwords, passcodes, PINs, or otherwise. Unum ID instead uses ​public key cryptography tied to the secure hardware of users’ phones. This completely eliminates common account takeover attacks like SIM swapping and behavioral fraud more generally. How? Because there’s no secret to intercept. See our white paper ​How Unum ID Stops Account Takeover​ for more.

Bi-Directional Auth#

The security of our passwordless auth solution (​Beyond Passwordless​™) applies to ​all ​interactions in Unum ID. This authentication is bi-directional: y​ou authenticate the user, ​and ​the user authenticates you! This eliminates phishing attacks because the user is unable to share data with anyone other than your company, no matter how convincing the phishing material may be.