Protect and Index Sensitive Data with Polymorphic Encryption

What if you could run real-time queries on data that remains safely encrypted? That might seem nonsensical at first — doing anything with encrypted data is usually cumbersome, resource-intensive, and slow. But real-time queries on sensitive data aren’t just possible, they’re very practical, especially when working with sensitive personal data (PII). The key is polymorphic encryption, and it should be a part of any modern data privacy stack.

In this article, I’ll discuss what polymorphic encryption offers to developers and how it balances the need to use data with the need to protect data. To understand polymorphic encryption, we should start with a look at homomorphic encryption, which also aims to address data security and data usability.

Homomorphic Encryption: A Flawed Ideal?

Homomorphic encryption is widely considered to be the “gold standard” of encryption because it supports arbitrary operations on encrypted data without first decrypting it. The idea is that you perform operations (like multiplication and addition) on two encrypted values to get an encrypted result. Then, you can decrypt that result to the same value you’d get if you performed that operation on plain-text values.

With the most extensive homomorphic encryption schemes, there’s a wider range of operations available that can be performed repeatedly. On the surface, it seems like this lets you both secure sensitive data and use it.

But, there are some issues with homomorphic encryption. And looking at these issues makes it clear why homomorphic encryption isn’t more widely used. While it’s often referred to as a “gold standard,” it has some practical shortcomings — just like the monetary gold standard has practical shortcomings in economics.

With polymorphic encryption, the data is encrypted in multiple forms, with multiple keys, with specific functions for the data associated with each encryption set.

One issue with homomorphic is that it requires too much computing power for most companies to use. The computing resources required for fully homomorphic encryption mean that even with massive computing power, user experiences relying on it are incredibly slow. How slow? Slow enough that most companies would avoid it because of latency issues. Microsoft even notes in their homomorphic encryption library docs that homomorphic encryption isn’t efficient. Such performance issues make homomorphic encryption unworkable for most business applications.

So why does homomorphic have these performance challenges? It’s because homomorphic encryption is the expression of an ideal — to be able to run nearly any operation on encrypted data — that is divorced from the actual needs of most developers. The actual need often faced by developers is to run a few well-known operations on sensitive data. How often do you really need to support running a wide range of computations on sensitive data? And, why should your encryption scheme perform poorly to support these unneeded operations?

For example, you might need to determine the location of a customer by running a matching operation on their encrypted phone number, examining the country code or area code. But, I can’t think of a good reason to ever perform multiplication or addition on a customer’s phone number. So, why endure slow performance to support that operation?

The real issue with homomorphic encryption lies in its goal: to run a wide range of operations on encrypted data, while choosing which operations to support after encryption.

Polymorphic Encryption Compared to Homomorphic Encryption

Homomorphic encryption borrows its first term from the mathematical idea of homomorphism, which refers to the mapping of one mathematical object to another while preserving the structure of the first object. With homomorphic encryption, only one set of encrypted data is created and only one key can be used to decrypt the data. This is powerful but inflexible and computationally slow.

Polymorphic encryption gets its name from the computer science concept of polymorphism, where a single interface or symbol represents many data types. With polymorphic encryption, the data is encrypted in multiple forms, with multiple keys, with specific functions for the data associated with each encryption set. This is equally powerful, but much more flexible, secure, and computationally much faster.

So, while it’s similar to homomorphic encryption in some ways, there are a few important differences with polymorphic encryption:

• Operations on partial data: Sometimes you don’t need to perform operations on an entire record, only part of it, like when you are determining a customer’s location using only a phone number’s area code. Supporting operations on partial records makes sense when you consider that many numbers are in fact data structures composed of multiple identifiers, instead of integers that you need to add or subtract. A phone number, for example, consists of a country code, an area code, and a local code. It might be commonly stored as an integer, but it is really a data structure. Operations on partial data don’t require full data access because you only need, for example, an area code projection to compare area codes. By not decrypting full records when you only need partial data, polymorphic encryption enhances data privacy and security.
• High-performance support for selected operations: Because polymorphic only supports the operations you know you’ll need before encrypting, it offers much better performance than homomorphic encryption.

Polymorphic Encryption In Action

A few examples of how a business might use polymorphic encryption help to illuminate how you can manage what seems like the intractable conflict between the need to secure data and the need to use it:

• ID Verification: Consider a customer service agent (CSA) who needs to use the last four digits of an SSN to confirm identity. With polymorphic encryption, they can ask a customer for their last four SSN digits and confirm their identity in real-time, without decrypting a list of customer SSNs (or even the full SSN). With homomorphic encryption, they would need to wait too long for this exact match operation for it to be practical. In systems without data protection or encryption, where CSAs have access to full SSNs, it’s only a matter of time before you have a data breach.
• Credit Check: Picture a banker reviewing a customer’s credit score to approve a loan. They don’t need the full credit score, only to know if it is above or below a given threshold. With polymorphic encryption, they can determine whether a customer’s score meets the requirements for a given loan without ever seeing it. All that they see is a “yes” or “no” response to whether the credit score meets or exceeds the requirements for the loan.

In both of these scenarios, polymorphic encryption lets you support business workflows without decrypting data. You aren’t decrypting an entire field from your SSN or credit score table, let alone fetching these values for all customers.

This is great from a data security perspective because the last thing any chief information security officer wants, other than a data breach, is employees decrypting more data than they need and caching it locally because that’s the path of least resistance to do their jobs.

Conclusion

Balancing the need for data privacy and data usability requires us to take a new approach to storing and encrypting data — and acknowledge that data security that doesn’t support critical workflows isn’t really robust security.

Polymorphic encryption delivers what homomorphic encryption promises because it’s scoped to what business workflows actually need from sensitive data. It provides a better-performing solution because it doesn’t support unnecessary operations on your most sensitive encrypted data. Instead, it supports and secures operations needed for key business workflows, like comparison and exact match on partial records.

Note: This article discusses polymorphic data encryption. Polymorphic data encryption is distinct from polymorphic key encryption, in which encryption keys rotate, but data is unusable unless you fully decrypt it.