Ubiq is an application-layer encryption API service with integrated key management that securely safeguards highly sensitive data. Ubiq enables applications and clients (users, machines, etc.) to natively encrypt data, flexibly and safely apply and manage encryption keys, and more effectively protect sensitive data than traditional storage-based encryption tools.

For developers: Ubiq enables developers to quickly build data encryption into any application, without requiring prior encryption knowledge or expertise. The SDK accelerates development time by simplifying the process of encrypting data, removes the need to manage keys and key-to-data association, and solves for cross-language and cross-cloud encryption compatibility. There’s also a SaaS-based UI where your security team can set policies, algorithm choices, controls, and key management rules (that you don’t have to worry about.)

For security teams: Ubiq enables security teams to define encryption rules, key management policies, algorithms, and access controls in a simple UI. It eliminates the confusion and ambiguity around encryption and allows you to select proven, best-practice encryption models and policies for all of your applications in a central location. It provides key management, FIPS 140-2 compliant key storage, a complete log of key access and activity, and an elegant dashboard for viewing usage and configuration. There’s also an SDK for the developers to use when integrating into your applications so they don’t have to worry about or be responsible for implementing algorithm or key management things.

More implementation detail is available at https://dev.ubiqsecurity.com/docs

Why Ubiq Was Created

Ubiq was created to provide a new, effective way to protect data that is familiar to developers and easy for security practitioners. 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 application data that needs to be encrypted."

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.

Application-Layer Encryption (to the rescue?)

Application layer data encryption is a security technique that involves encrypting data at the application level, ensuring that data is protected before it reaches storage (on-premise or in the cloud). In application layer data encryption, the encryption and decryption processes are performed by the applications themselves, rather than relying on lower-level protocols. This means that the data remains encrypted throughout its entire life cycle – from the moment it is created by the application until it is consumed by the recipient.

Some benefits of application-layer data encryption 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.
• Granular control: Since encryption is managed at the application level, developers can implement encryption for specific data types, fields, or subsets of information, depending on the application's requirements and/or its existing RBAC or ABAC models.
• Flexibility: Application layer encryption 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 encrypting data at the application level, 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 building compliant applications from the outset.

Ubiq's Application-Layer Encryption (as a Service)

Ubiq is an application-layer encryption API that enables engineers and information security teams to seamlessly integrate data encryption into any application without needing prior knowledge or expertise in encryption, enabling the application to encrypt and decrypt 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 applications 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 application-embedded SDK. They both work like you would expect a modern SDK/SaaS application to work. The SDK was built for developers; the SaaS UI was built for security teams.

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

Goal 1. To Be Easy to Use for Developers

We’re a developer-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 Developer Client Libraries 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 developers, 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 encrypted 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 application 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.

SaaS Service

The SaaS component 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 at https://dev.ubiqsecurity.com/docs/datasets 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 application that will be encrypting or decrypting data. Where this happens is an important design decision based on the type of application, type of encryption it will be providing, and its specific use-cases. The Ubiq library is available in most common application development languages as well as for Snowflake (no application required). 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 at https://gitlab.com/ubiqsecurity

No rolling your own crypto over here =)

Key benefits of the Ubiq architecture

• Reduce the risk of data theft: Encrypt data within your application 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 protection techniques: encryption, format-preserving encryption (FPE)*, masking (e.g., all 9 digits of an SSN - $ah-o#-lqt), and partial masking (e.g, the first 5 digits of an SSN - $ah-o#-1234)
• Broad application language support: Integrate Ubiq into applications across 9+ different programming languages as well as several modern data storage solutions (e.g. Snowflake) in case there is a direct to data use case, with full cross-compatibility (encrypt in one and decrypt in another)
• 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 added to an application
• 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 any application type: Integrate encryption into mobile or IoT, front-end, mid-tier, or back-end application architectures with ease and flexibility
• 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 encryption across all of your applications 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 at https://dashboard.ubiqsecurity.com/register
2. Create your first dataset https://dev.ubiqsecurity.com/docs/datasets 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. Include the Ubiq library from your normal package manager and add a few lines of code to call the encrypt() or decrypt() methods where your application requires data encryption or decryption

And that’s it. No additional changes to your application, 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 https://dev.ubiqsecurity.com/docs, 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 application, 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 application startup and not while serving an end-user request.

For structured datasets (https://dev.ubiqsecurity.com/docs/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 (https://dev.ubiqsecurity.com/docs/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 example at https://dev.ubiqsecurity.com/docs/c-library)

📘

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 https://dev.ubiqsecurity.com/docs/snowflake-integration 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 usceptibility 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 Applications 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 Applications?

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 (even Snowflake.) So your data can be encrypted as it enters your datastore and then accessed by multiple applications, some of which may be allowed to decrypt it and others may not. You can control that access via the applications’ API keys (issued from the Ubiq SaaS platform) and what datasets those API keys are granted access to. See https://dev.ubiqsecurity.com/docs/datasets and https://dev.ubiqsecurity.com/docs/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 application 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 https://dev.ubiqsecurity.com/docs/unstructured-datasets for instructions) and then every new encrypt in every application 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 applications with minimal code modifications, making it a convenient and efficient solution for developers.
• Language and platform flexibility: Supports various programming languages and storage platforms, enabling organizations to implement the solution across diverse application 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 application, 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.