Ubiq is a SaaS-delivered data-level security solution that enables the individual encryption, tokenization, and masking (partial encryption) of sensitive data.

Ubiq includes fully integrated key management, providing secure key storage and automating compliance-driven key management practices, eliminating the need and cost of managing your own KMS or HSM.

Ubiq integrates with Identity Providers (IDPs) such as Okta and Entra ID, allowing you to define which specific users and groups can access sensitive data through fine-grained access controls backed by robust cryptographic mechanisms, enabling a Zero Trust data security strategy.

Ubiq offers low-code or no-code integration across various data environments, including applications, databases, data warehouses, API gateways, and third-party tools, enabling quick and easy integration.

Why Ubiq Was Created

Ubiq was created to provide a more effective way to secure sensitive data. For nearly two decades, the standard approach to protecting sensitive data has been to apply encryption at the storage layer. Transparent data encryption (TDE) and full disk encryption (FDE) have been the go-to solutions for security, infrastructure, and engineering teams worldwide. However, despite implementing these controls, data breaches continue to occur as external threat actors and insider threats bypass them with ease. Tired of seeing the same breach scenario play out over and over, we were inspired to develop a more effective way for information security and engineering teams to protect sensitive data.

Traditional Data-at-Rest Encryption (fail)

One of the biggest known myths in cybersecurity is that "data at-rest encryption is a solved problem." In reality, it is not. Sadly, it is nothing more than security theater for most, with no meaningful benefit other than to check a box (no offense, compliance friends).

In most companies, the conversation surrounding data protection typically plays out as follows:

Someone responsible: "We've identified sensitive data that needs to be secured (encrypted, tokenize, or masked)."

The DevOps/Infrastructure team: "Easy. Use transparent data encryption for the DB, full disk encryption for the server, and server-side encryption for cloud storage."

Easy? Yes. Effective? No.

Unfortunately, traditional at-rest encryption controls such as transparent data encryption, full disk encryption, and server-side encryption (even with integrations into key management services) provide no meaningful benefit in running systems. Why? Because they implicitly trust admins and key processes, including:

• Database admins
• Database server
• Cloud admins
• System admins
• VM hypervisor hosts
• Infrastructure or cloud provider, etc.

Implicit trust means that if any of them request access to the plain text data (spoiler alert), the storage will comply. Every. Single. Time.

This implicit (blind?) trust renders them ineffective against modern attacks. Attackers know this, so they exploit this design flaw by stealing admin credentials. Once they have the admin credentials, the encryption controls transparently decrypt the data for the attackers, allowing them to access and steal sensitive data.

(Another spoiler alert) all major databases, data warehouses, and file storage systems (on-premise or in the cloud) suffer from the same flaw in their storage encryption models. So much for a solved problem.

Data-level security (to the rescue?)

Data-level security is a technique that focuses on protecting individual data elements as close to the source and access layers as possible, ensuring that sensitive information is secured before it reaches storage (on-premise or in the cloud). In data-level security, the encryption, tokenization, or masking processes are performed on the data itself. This approach ensures that the data remains protected throughout its entire life cycle – from the moment it is created or imported by any process or application until it is accessed by an authorized user, service, or system.

Some benefits of data-level security include:

• Neutralizes the design flaws in storage-based encryption controls: Even if an attacker compromises admin credentials to a database, data warehouse, or cloud account, the data remains encrypted and protected from exposure. Data remains encrypted even when it is at rest, protecting it against unauthorized access to stored data and potential security breaches.
• Fine-grained, Granular control: Integration with an existing IDP ensures that only authenticated and authorized users can access sensitive data through cryptographic controls, minimizing the risk of insider threats and unauthorized access.
• Flexibility: Data-level security can be used in conjunction with other security measures, such as access controls and data segmentation, to provide additional layers of protection. Yes, you can even leave FDE on in case someone steals your disk. ;)
• Reduced reliance on infrastructure: By securing data individually, organizations can better ensure the privacy and security of their information, regardless of the underlying network infrastructure or third-party services. Especially when leveraging cloud service providers.

You can read about some popular use cases here.

Who Ubiq Was Created For

Ubiq was created for people who appreciate storage-layer encryption is useless outside of the physical theft of disks and servers. In particular:

• Information security and data protection teams seeking to minimize breach risk without hindering innovation.
• Engineers who recognize the complexities associated with cryptography and key management and prefer to avoid catastrophic decisions.
• Compliance teams aiming to stay ahead of regulatory requirements and reduce compliance scope (PCI anyone?) by ensure robust data security across all data environments.

Ubiq's Identity-driven, Data-level Security (as a Service)

Ubiq enables information security and engineering teams to seamlessly integrate data encryption into their infrastructure without needing prior knowledge or expertise in encryption, enabling critical systems to secure its own data, without the data leaving your environment.

The Ubiq API is supported by a SaaS-based software layer that simplifies the complex world of cryptography and encryption. This is achieved through an intuitive and user-friendly dashboard that allows users to become operational quickly..

The dashboard offers users the ability to choose from proven, best-practice encryption models and policies for all their data environments in a centralized location. Additionally, it provides fully integrated key management and FIPS 140-2 compliant key storage, as well as a comprehensive log of key access and activity.

Ubiq Architecture

The Ubiq service has a two-component architecture made up of a SaaS service and an API-based integration. They both work like you would expect a modern SDK/SaaS tool to work.

The architectural goals of the Ubiq platform are three-fold:

Goal 1. To Be Easy to Use for Implementers

We’re a customer-focused company and we know that not all developers are security experts and not all developers have the time or flexibility to become experts at encryption algorithms, key management, and data protection techniques. Goal #1 of the Ubiq platform (the SDKs especially) is for them to be easy to use and familiar to a developer. Using our SDK should be no different than experiences most software developers have with other major SDKs.

To start with, we publish our integration docs publicly and we open-source our SDKs for transparency. See the Libraries and Integrations section for our implementation guides. Include from your package manager, use a set of API keys issued from our SaaS backend, and use one of two simple methods - encrypt() or decrypt(). No selection of algorithm, no selection of keys, no keeping track of what key was used for what data, and no changes needed when one or more of those things change later. Setup should literally be minutes, though your mileage will vary for complex design patterns.

Goal 2. To Be Easy For Database/Storage Teams To Implement

For implementation to be easy for customers, we also believed that the implementation had to be zero-impact to the storage layer that your data is stored in. Our second architectural goal is to ensure that you can continue to store your data (now ciphertext) wherever it currently lives with no changes to the underlying data storage. Database changes are hard, costly, and stop even the most well-intentioned application projects, especially if those databases are shared or critical. We achieve this by supporting both an unstructured and a NIST-approved structured data encryption algorithm. The unstructured mode is great for files, blobs, streams, media, or anything else that does not have length or encoding restrictions. Structured allows you to retain a strict length and character set of your ciphertext, ensuring that you can still store your secured data in the same database column of your legacy relational database. It’s also a great alternative to tokenization or masking.

Goal 3. To Avoid Exposing Your Data (even to us)

We’re also a security-obsessed company, and we do not want your data to go anywhere new (and take on new risk) in your efforts to protect it. For this reason, our architecture is designed so that we never see your data. The path that your data takes through your data environment remains untouched while integrating Ubiq into your app. Your data is never sent to our SaaS backend and we never alter its course. Not only is this good for security, it’s also great for performance and reliability. As a result, your data is encrypted before it gets to its resting place (database, S3 bucket, filesystem, etc.) and anyone who has access to that storage can no longer get to it - all they get is ciphertext.

Policy WebUI Component

The WebUI is where security rules are defined - including creation and assignment of cryptographic “primary” keys (sometimes known as master encryption keys or root keys), provisioning of access/API keys, and organizing “datasets” that encrypt and decrypt actions can be taken on. See our how-to guides on creating a dataset for more definitions and examples.

Typically, a security engineer or policy team will define the rules and setup in the backend and then provision API keys that a development or engineering team will work with. Once those rules are established, the technical team never has to interact with keys, key management, or any of the cryptographic configurations.

SDK/Library Component

The SDK or library is the second component of the Ubiq platform, which is implemented in the data environment that will be encrypting or decrypting data. Where this happens is an important design decision based type of data security it will be providing and its specific use-cases. The Ubiq library is available in most common application development languages, leading data warehouse and database vendors, API gateways, and a variety of third-party tools. In all cases, the SDK provides two methods - a simple encrypt() and decrypt()with only the API access key and the name of the dataset being worked on needed. No cryptographic keys or knowledge is required of the developer.

📘

All of our libraries are 100% open source for transparency and leverage industry-wide cryptography libraries and NIST-approved algorithms. Check them out here.

No rolling your own crypto over here =)

Key Management Component

Ubiq includes a robust key management system that handles the storage, rotation, and lifecycle management of master encryption keys:

• Secure Storage: Master encryption keys are stored in highly secure environments such as hardware security modules (HSM) or secure key vaults.
• Key Rotation: Encryption keys are rotated periodically to maintain security and comply with best practices.
• Key Lifecycle Management: Ubiq manages the entire lifecycle of keys, from creation and distribution to activation, deactivation, and destruction, ensuring they are used securely and appropriately.

Enhanced Real-World Use Case

Banking/Payment Fintech Setting
In a banking or payment fintech setting, Ubiq provides a comprehensive security solution:

• Integrated Authentication: Financial service providers and customers authenticate using Okta or Entra ID, ensuring seamless and secure user verification through single sign-on (SSO) and multi-factor authentication (MFA).
• Access Control: Role-based access is managed through Okta or Entra ID and extended to applications, databases, and data warehouses, ensuring only authorized users can access sensitive financial information.
• Primary Data Security Use Cases:
  • Encryption: Transaction data, account details, and personal customer information are encrypted with strong algorithms to protect data confidentiality.
  • Tokenization: Sensitive information like credit card numbers and bank account details are tokenized to prevent exposure and facilitate secure transactions.
  • Data Masking: Partial data masking is used to protect sensitive data elements while allowing their partial use for analytics and processing, such as showing only the last four digits of a credit card number.
• Encryption and Key Management: Master encryption keys are securely stored and managed, with periodic rotation and comprehensive lifecycle management to prevent key compromise.
• Broad System Integration: The security framework extends to the bank’s financial applications, data warehouses storing transaction data, databases, API gateways for data exchange, and Kubernetes for managing containerized services.
• Monitoring: Access logs are continuously monitored across all integrated systems to detect and respond to suspicious activities.
• Key Lifecycle Management: Encryption keys are rotated and managed to ensure their security throughout their lifecycle, reducing the risk of key compromise and ensuring compliance with regulatory requirements.

Key benefits of the Ubiq architecture

• Reduce the risk of data theft: Encrypt data within your data infrastructure, so attackers, insider threats, cloud providers, and not even Ubiq have access to your data or keys
• Protect all data types, anywhere: Encrypt structured or unstructured data, wherever it lives - databases, data warehouses, files - on-premise or in the cloud. While fully preserving data format and length
• Support for various data security techniques: encryption, format-preserving encryption (FPE)*, tokenization, and partial encryption (masking) (e.g, the first 5 digits of an SSN - $ah-o#-1234)
• Identity-driven, fine grained data access: Grant access to sensitive data through fine-grained access permissions, and support for SAML based integrations with leading IDP providers such as Okta and Entra ID.
• Easy to use, hard to misuse: It requires no previous cryptography knowledge and is designed to be integrated within a few minutes, with nothing more than a software library (and a few lines of code for application integrations)
• No changes required to your data layer: Does not require any changes to your data storage - RDBMS, file system, storage bucket, etc. – or your existing data models and data flows
• Integrate into various data environments: Integrate encryption into applications, data warehouses, databases, API gateways, and third-party applications, with full cross-compatibility (encrypt in one and decrypt in another)
• Integrated key management: Efficiently manage key lifecycle and algorithm usage, and leverage FIPS 140-2 compliant HSM key storage
• Your Data never leaves your environment: the only communication with the Ubiq backend is for key exchange.
• Centralized management: Manage data seurity across all of your data environments in a single dashboard, supported by comprehensive audit and logging capabilities

*We believe structured data (format-preserving) encryption makes tokenization obsolete. Leverage ciphertext as a token, and no longer manage two sets of the same data – the plaintext version and a tokenized version.

If you’d like to dig into some of the popular use cases customers use Ubiq for, you can check them out here.

How to get up and running (in under 30 min)

Yep. Most of our users run full POCs in less than 30 min.

1. Sign up for an account
2. Create your first dataset by answering 4-5 questions (mostly about the type of data you want to encrypt) in under 2 minutes (unstructured is even less questions)
3. Grab your API keys
4. Integrate the Ubiq SDK/API into your data environment

And that’s it. No additional changes to your data environment, data model, data flow, or data storage layers are needed. Reminder: Your data never leaves your environment.

Example: Web Application Integration

In a typical 3-tier web application (front-end, APIs, and backend), the most common way to implement the Ubiq SDK is at the API layer (where the data access happens.) The more centralized the implementation, the fewer places in the application that need to be changed. In most cases, there are no changes required to the data storage layer (RDBMS, storage bucket, filesystem, etc.) and in all cases, the data is never transmitted back to Ubiq. If an ORM is in use, adding the Ubiq library directly at the data access layer and enforcing encryption at data read and write is ideal.

The first thing to note about web application (or mobile application) integrations is that we generally see clients integrating at the API / web app layer and not at the client / browser / mobile app layer. While this may not be appropriate for all use-cases, it is generally the most simple and provides a good tradeoff of complexity-to-security. Integrating at the client is possible, but browser compatibility and performance adds complexity (if a web app) and mobile app credential management and update lifecyle adds complexity (if a mobile app.) If we assume a typical SPA-style web application or MVC-style application, the Ubiq SDK is most typically added in the model/DAL layer so that it can be invoked right before data is stored and right after data is retrieved. This reduces the amount of impact to other areas of the application because as the data is used elsewhere, it is (in memory) in its plaintext form.

Client Data Flow

The client data flow remains unchanged (we keep saying this) - the web form or mobile app or other client input goes from the client to the API or web app just like it does today. No changes to your data flow.

Ubiq SDK Instantiation

When working in the context of a web application, the assumption is that multiple pieces of data are processed, such as a form being filled out that has multiple fields or documents being uploaded that are all attached to the same customer. Generally, these implementations prefer to optimize for performance and ensure that those actions can be completed quickly with virtually no additional overhead to the end-user. This is accomplished by instantiating the Ubiq SDK only once per app scope - the instantiation is where the SDK authenticates to our backend and retrieves encryption keys that will be used during each encrypt() or decrypt() call. That interaction is the slowest (speed of light and RESTful calls and all that), so they should be avoided in each web call if possible. Once the SDK is instantiated, it is used statically (no communication back to our backend) until it needs to retrieve more configuration info or new keys.

📘

Every language, and many frameworks, provide techniques for managing singletons; we’ve seen them in everything from .NET dependency-injection to Java Spring bean scopes, but you should use techniques that are best-suited to your application stack.

📘

There are some implementations that optimize for key uniqueness over performance and in these cases they choose to instantiate on every request, but that is a design/application decision.

Ubiq SDK Encrypt / Decrypt

During data retrieval and storage, the Ubiq SDK is used most commonly in a Model / DAL to encrypt data just before it is saved or to decrypt data right after it is retrieved. This allows other application logic that might be acting on the data to remain intact because as the data is used elsewhere, it is already in its original/plaintext form.

📘

Example

Each of the Ubiq SDKs (per language) has language-specific syntax and can be found in the Developer Client Libraries section of the documents, but generally the pseudo-code will look like:

Include the Ubiq SDK from the language-specific package manager npm install ubiq-security

Instantiate the SDK in a shared-memory (singleton) area of the application. Use good practices for managing the credentials (like automation from your pipeline and not putting them in the codebase)
const credentials = new Credentials('<access_key_id>', '<secret_signing_key>', '<secret_crypto_access_key>')

In the model/methods where data is saved, encrypt it first const encrypted_data = await ubiq.encrypt(credentials, plaintext_data)

And in the model/methods where data is retrieved, decrypt it after const plaintext_data = await ubiq.decrypt(credentials, encrypted_data)

Encryption Modes

Ubiq supports both unstructured and structured data encryption modes and datasets. For RDBMS-stored data, structured data offers NIST-compliant, format-preserving encryption that maintains data structure after encryption. This ensures that a 10-character plaintext string will remain a 10-character string when encrypted, preserving RDBMS encoding and data length requirements. For larger data such as files, streams, media, or blobs, unstructured data employs typical AES encryption with unique data keys per encryption event and complete data portability (no attached metadata is required with the encrypted content). Ubiq currently supports NIST-compliant FF1 and AES-GCM-256 and AES-GCM-128 libraries for most use cases.

Performance

Performance overhead is a critical consideration for any library that is added to your data environment, and we expect anyone adding the Ubiq SDK to have high expectations of our performance. The overhead of our SDK is measured in two parts:

1. Instantiation (with communication to our SaaS APIs) overhead
2. Decrypt / encrypt of data

Instantiation Performance

Instantiation performance can be calculated based on the below components, though response times will vary slightly based on geolocation and proximity to our hosting regions. The average API call response time is 250ms.

📘

As noted in the Ubiq SDK Instantiation section, warming-up the SDK cache is an important design consideration in order to absorb the instantiation performance impact at startup and not while serving an end-user request.

For structured datasets:

• Two API calls are made for each structured dataset that is used. These calls will be opportunistically made when an encrypt or decrypt is done for that dataset.
• One API call is made for each new decryption key that is needed. These are also opportunistically fetched when a piece of data is decrypted and requires a new key.

For unstructured datasets:

• One API call will be made for each encryption or decryption event unless piecewise encryption is used, which will only make a single API call to encrypt the number of data elements specified (see the C library example)

📘

The Snowflake library uses a very different caching approach to facilitate database-centric use-cases (not covered in this paper) and the above (and below) performance guidelines do not apply. See the Snowflake Integration Guide or get in touch with us for more detail.

Decrypt / Encrypt Performance

Measuring the performance overhead of structured data encryption or decryption is much simpler than the instantiation impact and design. Generally, encrypt and decrypt performance will be comparable to native-language encryption methods; precise measurements will differ by infrastructure being run, but on average, all SDKs will have:

• Structured data encrypt of 10 microseconds (0.01ms) per 25 characters
• Structured data decrypt of 10 microseconds (0.01ms) per 25 characters

Unstructured data encrypt / decrypt performance varies much more widely based on infrastructure, some of which now has chip-level AES instructions. For a general performance benchmark:

• Unstructured data encryption/decryption in a non-compiled language without AES instruction sets will perform at about 500ms per 100mb of data (this is the slowest scenario)
• Unstructured data in a compiled language with AES instruction sets will perform closer to 500ms per 1gb of data

Both encryption types (structured and unstructured) scale sub-linearly, so larger datasets perform more efficiently.

Security benefits and How Ubiq Helps

Application Vulnerabilities We Help Protect Against

Application vulnerabilities can lead to severe data breaches and loss of trust. This section explores key vulnerabilities that Ubiq can help protect against, including Identification and Authentication Failures, Broken Access Control, and Injection attacks. By utilizing Ubiq's encryption API services, you can significantly reduce susceptibility to these application vulnerabilities, helping ensure sensitive data is protected, even in the event of a breach.

• Identification and Authentication Failures: An attacker performs a credential stuffing attack to gain access to privileged accounts and plaintext data.
• Broken Access Control: An attacker modifies an access control check or metadata to get access to privileged accounts and plaintext data.
• Injection: The use of a blind trust application framework allows an attacker to exploit a vulnerable query and get access to plaintext data.

Threats We Help Protect Against

Threats to data security can come from various sources, both internal and external. This section delves into the threats that Ubiq can help defend against, such as Insider Threats, Supply Chain Attacks, and Advanced Attackers. By making data unreadable to unauthorized individuals, Ubiq provides a robust layer of protection against these potential risks.

• Insider threats: An employee or contractor with (database, cloud, etc.) admin access can easily access plaintext data.
• Supply chain attacks: Your cloud provider suffers a security breach, which grants attackers access to plaintext data.
• Advanced attackers: You suffer a security breach, and the attackers compromise (database, cloud, etc.) admin credentials to access plaintext data.

Common Questions

We get lots of questions, from the “why” to the “how,” and while we can’t answer all of them in a single paper, we feel it’s important to try to address some of the more challenging and common ones. Transparency is something we strongly believe in.

Multiple Data Environments Accessing the Same Data

In many real-world scenarios, there will not be a single application that accesses data, but there will be multiple applications doing so. These might be an ETL and a reporting application or a web app and a background processing job. These apps might need different levels of access to data and might even be built in different languages. The question at hand is Can Data Encrypted With Ubiq Be Shared Between Data Environments?

And the answer is a short YES

The Ubiq SDKs are 100% cross-compatible. Data encrypted with one may be decrypted with another. All languages, all platforms. So your data can be secured as it enters your datastore and then accessed by multiple data environments, some of which may be allowed to decrypt it and others may not. You can control that access via API keys (issued from the Ubiq SaaS platform) or through existing user and group policies from your IDP. See Datasets and API Keys for more info.

Rotating Keys

As part of good security hygiene cryptographic keys should be rotated periodically - primary and data encryption keys. Typically, this is a painful event - code update, pushing out new keys, expiring old ones, and all of the administrative work that comes along with that. The question here is What is the Impact When Rotating Keys With Ubiq?

The answer is One Button Click

Our encryption modes are all entirely “portable,” meaning that the key material used to perform the encryption is retrievable from only the ciphertext itself (even in structured data encryption where it might be only a 10-character ciphertext string.) Because of this, rotating the cryptographic keys has no impact to the decrypt-ability of existing data and no impact to the code/implementation. The Ubiq SaaS UI has a button to “rotate key now” or can automatically rotate keys on a set interval, and in either case, the rotation is completely transparent to the technical implementation. The Ubiq SDK paired with the ciphertext knows what key to use to decrypt data and what key to use to encrypt new data.

Future Algorithms (i.e. Quantum-Resiliency)

Similar to the typical pain of key rotation / changes, algorithm changes are an unavoidable, yet unpleasant part of data security. Not only does an algorithm change require re-keying (re-encrypting) of existing data in order to take advantage of it, but it also requires adding that algorithm to every data environment or codebase that is encrypting or decrypting data. This question is What is the Impact When Changing Algorithms With Ubiq?

The answer here, too is One Button Click

Very similar to how our encryption algorithms are portal from a key perspective, they are identifiable and portable from algorithms too. Keep in mind that the #1 goal of our SDK architecture is to make the implementation simple for developers, so when using the SDK, the developer does not choose what algorithm to use - that’s set in the SaaS platform and the SDK is “told” what to do at the time it does an encrypt. If a new security policy wants to enforce the use of a new algorithm, it is as simple as updating the algorithm on the dataset (see here for instructions) and then every new encrypt in every data environment using that dataset will immediately begin using the new algorithm.

For transparency-sake, re-keying is easier but not automatic. We do not have access to your data, and changing the algorithm for an already-encrypted piece of content can’t be done automatically. Once an algorithm is changed, each piece of data you wish to re-key needs to be accessed/decrypted/encrypted to pick up the new algorithm. This is achieved by simply decrypting the data and re-encrypting it. Upon re-encryption, the new algorithm will be used.

Tl;dr

We built Ubiq so that we can tip the balance of power back in favor of the good guys, and away from adversaries.

We hope the insight we’ve shared here helps highlight how our approach addresses the inherent shortcomings of traditional data-at-rest encryption methods, providing enhanced security, flexibility, and control.

In summary, we designed Ubiq to offer:

• Straightforward integration: Designed for easy integration into existing data environments with minimal modifications, making it a convenient and efficient solution for implementers.
• Language and platform flexibility: Supports various programming languages and storage platforms, enabling organizations to implement the solution across diverse data environments.
• Integrated and automated key management: Offers a centralized key management system that streamlines the process of managing and rotating encryption keys, maintaining a high level of security.
• Scalability: Constructed to scale with your data environment, ensuring it can handle the increasing demands of your business without sacrificing data security.
• Compliance friendly: Designed to enable organizations to meet data protection regulations, such as PCI, GDPR, HIPAA, CCPA, PDPA, and others and minimizes the risk of non-compliance penalties.

As an industry, there is still much to do, and we look forward to going on this journey together with our customers and community. If you’ve worked on similar systems or projects, we’d love to chat and trade notes! Please drop us a line.