Innovation

This article explains SSProtect/ KODiAC and the Innovation that sets it apart from traditional offerings.

Introduction

Encryption, done properly (not a foregone conclusion), can be effective in limiting unauthorized access to sensitive data. Industry efforts have, however, resulted in trade-offs that limit practical end-use, application compatibility, effectiveness, or more commonly some undesired combination of the three.

SSProtect addresses these challenges with effective host application data protection that's easy to use, deploy, and administer.

Super Simple Security

SSProtect is a Unified Data Protection and Management System made up of the :Foundation Client and KODiAC Cloud Services. The :Foundation Client is a small application you as an end-user run on your Windows desktop whereas KODiAC is the SaaS foundation it uses, deployed and managed by DefiniSec.

SSProtect stands for both Simple Security - Protect and also Super Simple - Protect. These were placeholder monikers used by our team as reminders that end-user workflow integration had to be trivial and non-intrusive. As we shared Early Adopter releases, feedback was positive so we kept the name.

KODiAC Cloud Services

What if you could put Smart Card capabilities in the cloud, then extend the cloud with its' relatively limitless capacity? You could then:

1. Identify Users then authenticate and authorize associated requests using central configuration, administration, and execution
2. Implement policy-based data sharing, doing away with traditional and complex, "encrypt to recipients" 
3. Audit and securely store service request records, isolating content from potentially compromised hosts
4. Store data instances when encrypting content for users, making content available for future recall
5. Build Response/ Recovery services with secure audit information and stored content

KODiAC is our SaaS platform, the set of Cloud Services we develop, deploy, and maintain, for you to protect and manage host application data.

:Foundation Client

The :Foundation Client is a small software application (~10MB) that runs on your Windows desktop to coordinate requests with KODiAC Cloud Services. Protect sensitive data from File Explorer context menus, a Bulk Protection UI, or integrate automatic protection using our :Expand API. The :Foundation Client handles the rest.

This empowers you to use protected/ managed content without major changes: The :Foundation Client monitors and intercepts access requests then dispatches services to KODiAC for processing. For protected data access, end-user impact is limited to authentication - whether establishing an SSProtect Login Session (once every so often) or acknowledging fine-grained two-factor authentication (with each request), the rest remains relatively the same, independent of the application software you use to work with content.

And there's more, but we'll come back to that in a moment.

Patented Cryptographic Offloading

In order to offload encryption requests, like a Smart Card, we created and patented a set of methods that distribute keys between a host computer and KODiAC Services deployed in the cloud. The noted methods can be summarized as follows:

1. Encrypt plaintext content on the host computer using a unique AES key that remains on the host
2. Upload host-encrypted content to KODiAC Cloud Services
3. Encrypt the host-encrypted content in the Cloud using another unique AES key that remains in the cloud
4. Return the double-encrypted result to the host computer

Note that KODiAC can optionally retain the double-encrypted result as a Version Instance that can at a later time be securely recalled by the Data Owner. These terms are more specifically defined in the Walkthrough, :Recover w/ Shared Content.

Cryptographic offloading, in this fashion, implements a multi-party consent trust model that requires an attacker to breach both the host computer and KODiAC Cloud Services in order to, "steal" plaintext content. This also ensures that KODiAC Cloud Services never holds enough information, by itself, to access your plaintext data.

It also has the effect of ensuring that legal subpoena of Cloud Service Provider keys doesn't give up your plaintext data, keeping government agencies from surveilling your content without your knowledge. Though this doesn't make us very popular with certain factions around the globe, our commitment is to your Privacy.

In-Place Encryption

When you want to access managed (encrypted) content, the :Foundation Client submits your identity, requires you to provide authentication materials (often in the form of 2FA acknowledgment), then dispatches the request to KODiAC for authorization before coordinating the cryptographic offloading process noted above.

But there's more. SSProtect doesn't stop with, "at-rest" encryption: When you attempt to access plaintext, the :Foundation Client not only coordinates, "conversion" from ciphertext to plaintext, but also isolates plaintext, only permitting access by the managing software used to review/ edit plaintext content. This blocks other Windows services, processes, and applications, greatly limiting the host-resident attackers.

As you would then expect, when you save/ close managed content, the :Foundation Client coordinates re-encryption (and other security measures) on your behalf, releasing the resulting ciphertext for use by Windows services and resources.

Looking Deeper: Innovating In-Place Encryption

Application-independent In-Place Encryption, providing end-to-end workflow integration and protection, is...unusual and unique, though perhaps that may not align with perception. Allow us to explain.

Around 2014/ 2015, there was a parade of newcomers to the security industry. The thinking goes something like this, "We revolutionized (pick an industry, i.e. gaming), and we're smart - we'll show security people how easy this problem is". They learned the hard way the problem isn't easy; security practioners aren't, "hacks", it's a complex problem.

This however led to claims like, "transparent encryption", which weren't altogether inaccurate, the problem was that the transparent part was extended to most of the rest of the world, invalidating the primary goal of Confidentiality.

In-Place Encryption addresses this - and more, a Trade Secret we hold, based on 18 months of R&D and practical testing/ scaling. We're happy to talk about it and explain how we do it - we do that all the time. There isn't a, "trick"; it's a combination of numerous innovations to ensure both reliability and performance.

And this isn't normal at all. Many new to the security industry, or to the idea of host-based application data encryption, see what we have and say, "So what" thinking, "That's how it should work, surely everyone does that."

Nope - look around: When you get right down to it, In-Place Encryption is extensively unique and innovative, not to mention effective.

Remember, though, that we allow you to protect application data stored, "anywhere" - within reason. Whether local mass storage, storage-connected devices, thumb drives, network-attached storage - no problem. This is also unusual - you may note that a lot of cloud-bound encryption uses a, "target folder", i.e. Dropbox and those that followed. This dramatically improves performance, though we were able to address that matter as well, using something called Adaptive Filtering.

Host Adaptive Filtering

Stated at the highest level, there is no real way to programmatically say, "give me control when someone attempts to open a file that's being managed by SSProtect". Though some may counter that there are Windows-based calls to do this, they aren't suitable (at all) for making certain you as the, "subscriber" get notified first. Without deterministic ordering, you can't use the facility to manage secured content.

Ultimately, you get a different type of notification, one that says, "part of your file is going to be accessed by xyz process, to do abc". When you open a document, many dozens of these requests happen within the first second. To complicate matters, applications like Microsoft Word open and close the file, rename and/ or move/ delete interim content before finally engaging in the, "open for user access" to read content.

Figuring out which events represent, "end-user access with an application", without coding specifics about qualified applications, presents a significant challenge. At the same time, the mechanism needs to very quickly determine whether or not the target is an SSProtect-managed item, minimizing the impact of associated processing. This mechanism also has to, "interrupt" or inhibit other requests in a fashion that doesn't break core Windows services while precluding them from reading interim managed plaintext...

We solved the first hard part of this with what we call Adaptive Filtering, another Trade Secret integrated with In-Place Encryption (required for, we should say). In fact, without Adaptive Filtering, the act of protecting a dozen files, anywhere in your mass storage device, and attempting to execute In-Place Encryption, imposes a performance impact far greater than attempting to read/ write data while performing a full anti-virus scan of all your files. Unacceptable.

Today, with Adaptive Filtering, which is automatic, you can manage many thousands of files on a single host computer. Most users don't notice the performance difference with and without SSProtect.

Blocking Sync And Sharing Apps

Back to that deterministic thing we mentioned above: If you protect content then move it to a file sync and sharing target folder, access with SSProtect blocks the sync and sharing application from reading plaintext and writing that to the cloud.

A nice, "side effect"? No, by design: This allows you to ensure that end-user mistakes don't accidentally expose plaintext content to the file sync and sharing provider or to those who are sharing content stored in your target folder. Instead, they see, "new" ciphertext.

That means you can still use file sync and sharing software with SSProtect, though without the worry of accidentally exposing sensitive information to those that might not manage it appropriately.

Two-Factor Authentication

This near-native application experience authenticates using your SSProtect Login Password, and can also use a second authentication factor in the form of a USB key that requires you to touch it before emitting cryptographic material. This mechanism protects against attackers using stolen credentials since remote software control cannot fulfill a physical presence requirement for the USB key. And because data retains decoupling from the 2nd factor, administrative controls can be used to easily enable, disable, and replace lost or stolen keys.

KODiAC Challenges and Custom Secure Networking

We haven't, however, talked about the challenges associated with offloading to the cloud. Some will read this and think, "there's no way this system performs well at all". Frankly, we weren't sure we could pull it off but mid-2015 started to see the fruits of our labor. There are however many other issues, such as:

1. Cloud service requests must be submitted securely
2. Cloud services must be reliable and constantly available to respond to requests
3. Network latency must be minimized to ensure performance does not inhibit end-user activities
4. Managed content can never be available, in plaintext form, using Cloud service resources
5. The system must support global scalability, which implies replication and additional performance considerations

We addressed a lot of this by building our own custom secure networking protocol and stack, tightly-coupled with the services we developed and integrated with highly specialized cloud, "receivers" that process :Foundation Client requests. In 2015 testing, we were able to show that our networking outperformed TLS even when configuring TLS to use hardware acceleration for underlying cryptographic operations.

We haven't, however, recently compared performance with TLS 1.3, which is quite a bit faster than previous TLS offerings. We do however feel that TLS 1.3 will offer suitable performance and are looking at offering it as an alternative, though plan to retain our own implementation for those that are not comfortable relying on elliptic curve cryptography.

To that end, it's important to know that our network stack offers the same degree of protection you'd find in any viable alternative (such as TLS or IKE/ IPsec), which includes:

• Data Integrity Protection
• Data Confidentiality w/ E2EE (see below)
• Message Authenticity
• Anti-Replay Protection
• Non-Repudiation

It's worth noting the E2EE - or End-to-End Encryption - is nothing to celebrate: Educated practitioners have utilized the very same techniques for secured data transports since ...the very first secure transports were implemented. That someone turned it into a feature and promoted it as a differentiator is more an indicator of the skills gap than anything else. We however believe our industry has grown past a lot of those pains, mostly well-served by informed and educated individuals rather than the influx of newcomers racing to create, "the next new thing" when security spending dramatically increased as a result of high-profile breaches like Target, Sony - even the Heartbleed Bug - around 2013/ 2014.

No Open Source, No Programmatic Frameworks; Patch Decoupling

KODiAC faces other challenges, such as the latency associated with waiting for cloud storage commits before responding to aspects of a :Foundation Client transaction request. We've implemented a number of innovated approaches, across the board - both in the :Foundation Client and KODiAC, specifically aimed at addressing these realities. Results have been well-received, and we're happy to share some of those details with you as necessary.

It's worth noting that we achieved some of this by avoiding the use of open source software and popular programmatic frameworks - including C#/ .NET which isn't used in the core :Foundation Client.

This is a tradeoff between building everything from scratch, which takes more time and requires extensive testing/ verification and increases security audit costs - but at the same time decouples the software from library patches and framework 0-day exploits that almost everyone else is prone to. For example, something like the Heartbleed Bug in OpenSSL wouldn't have impacted SSProtect in any way, though a good part of the world suffered its shortcoming. It's naive to think nation states weren't exploiting it prior to public disclosure.

Combination of Services Backed by Innovation

SSProtect, then, is the combination of security and system services aimed at helping you secure desktop data. It is this unique set of services, the way they work together, and that they are all available in a system that's easy to deploy, use, and administer, that makes it especially unique.

Whereas some of the individual pieces may be replicated elsewhere, many of our critical innovations aren't available elsewhere. When you put them all together, they provide, with a single vendor and single solution, a formidable presence against the most capable attackers.

Additional Resources

You can search this site for more information on various topics, or use this link to submit a specific request. You can also send email directly to support@definisec.com, and our staff will respond to your needs as soon as possible.

In the meantime, don't forget to check out our primary website and Insights columns for information on current trends, security topics, and how our technologies relate.