preloader

Search Here

Not All Encryptions Are Created Equal

blog-image

Not All Encryptions Are Created Equal

  • Posted on July 26, 2018

In today’s volatile digital security world, encryption has become a standard security measure to keep your data protected. Many in the security industry would even goes as far to say that it is one of the most important methods for providing data security, especially for end-to-end protection of data transmitted across networks. The core foundation of encryption focuses on converting information or data into a form unreadable by anyone except the intended recipient. Once a file or data piece is encrypted, it becomes difficult for external sources to get access/understand the encrypted information.

While highly touted, encryption is hardly a new strategy with the origins of hidden messages and cryptography dating back to the 19th century. Since then, it has evolved and there are many different types of encryption algorithms that are used. However, not all of these are created equal or are completely secure. Below are several types of today’s popular encryption algorithms all of which have security loopholes.

Homomorphic Encryption

Homomorphic encryption requires a public key to enable search. This also means it requires a keystore to hold the private key to enable the encryption. The person with access to the keystore has access to your data! This means you are putting your data at risk to internal misuse and in the hands of who owns the keystore. You don’t believe you would have an internal person who abuse this power? Nor did the CIA until Edward Snowden fled the country.

Data Masking

Data masking has generally been created as an intermediate layer between the data store and the user and is becoming more common as part of the GDPR regulations. The masking gateway accesses the data as an administrator and transforms (masks) the data on a user query. However, the stored data remains in clear text and is vulnerable. Simply put, this is really just application redaction.

TDE – Transparent Data Encryption

This technology encrypts the data file on disk, stopping anyone from reading it, while it is at rest on the disk drive. HOWEVER, as soon as it is loaded in to the database, it is decrypted and available to be viewed by all who have admin privileges. This puts the encrypted data at risk to internal misuse as admins have approved access to the keys and could decide to capitalize on this access to sensitive information.

Column Level Data Encryption

Column level data encryption is generally implemented with a keystore, which means that those with access to the store also have access to the data. However, just as importantly, if this is implemented post production, it requires whole-sale changes to the database and the calling applications, leading many implementations to remain incomplete, as well as expensive.

As you can see, many of these encryption tools are lacking in complete external and internal security.

At ShieldIO, we believe that the parties at the two ends of a data message – the sender and requester – should be the only ones who have access to that data message. We believe encryption should be dynamic. In other words, your keystore should be dismantled and the encryption keys, IV’s Salts, should be created by the application based on different criteria at that moment in time. This means that each piece of data, each network message, or each file is encrypted to a unique key, so it doesn’t leave your data open on your key store and accessible to unauthorized employees. Dynamic key creation encryption that has no reliance on web security or keystores is a cornerstone of ShieldIO’s data security service. Every data request is isolated from the requestor and is encrypted using transient keys that are destroyed after each transaction. This means the original data request never has direct access to the company network or backend database and terminates intercepting party connections and renders partial data a third party may get access to useless, making it very difficult for to steal useable data (including a database admin). Further, by uniquely providing field level security, removing these fields from the source, storing the encrypted data and separately, without changing the underlying database structure or using a keystore to manage the encryption keys, which removes not only the hacker threat to the data, but also the more prominent insider threat.

As such, despite being popular in the security industry, it’s clear that many of the current encryption methods that have backdoors, especially for internal misuse. If you are interested in more about ShieldIO’s keystore-less encryption method that makes these security loopholes obsolete, reach out to learn more.