SSProtect was designed to manage and protect sensitive data, maintaining integrity and high availability (:Recover) while protecting against unauthorized access (:Access) and disclosure (:Confidential). Backed by fine-grained, secure auditing (:Assess) and monitoring (Honeypots) enhanced by event analysis (:Respond) and disaster recovery (:xRecovery), this unified set of scalable services reduces data breach impact and operational disruptions without reliance on existing or future IT applications and/ or infrastructure.
Symmetric and Asymmetric Cryptography
Proper/ secure key management presents one of the greater challenges associated with data protection. Encryption algorithms utilize encryption and decryption keys (among other inputs) for data confidentiality. Symmetric cryptography uses a single key for encryption and decryption, whereas asymmetric cryptography uses different keys, most often in the form of a public and private key pair.
SSProtect utilizes these primitives to isolate and distribute cryptographic materials, which can complicate attacker motives. When done properly, this can be a highly effective method for increasing protective posture, though it is only one aspect of a much more complex problem.
Encryption algorithms are plentiful and come in many forms, some using different operating modes - for example Cipher Block Chaining (CBC), Electronic Codebook (ECB), Galois/Counter Mode (GCM), to name a few (symmetric). Operating mode are designed for specific purposes, and present various tradeoffs - in some cases shortcomings that render practical use ineffective.
Traditional encryption was not specifically designed to combine host-based computing with cloud-based service offerings, and even still encryption alone is not sufficient for complete data protection. SSProtect delivers a platform of patented methods that combine the power, flexibility, and effectiveness of distributed computing together with innovation in cryptographic primitives to maintain business continuity in the face of today's inevitable data breach dynamics.
Generic Composition (as applied to Cryptography, not poetry) is a name given to the act of combining two or more individual cryptographic algorithms to achieve additive results. Though it may seem practical to link encryption, authentication, and/ or integrity protection in a serial fashion, one must take care to avoid violating essential assumptions and requirements lest end results suffer deficiencies not obvious outside the realms of cryptographic experts.
This has proven to be historically significant and problematic, and we've seen standards bodies suffer limitations as a direct result. SSL/ TLS, IPsec, and SSH have, for example, each suffered direct and specific limitations that have since been addressed with adjustments to the way these considerations are managed.
In-Place Encryption and Protection
SSProtect hides management details to simplify use and operation, allowing you to retain focus on your business rather than take on the daunting tasks associated with key management and/ or integrated cryptographic operation. Our data security methods deliver application-independence and continuous protection while maintaining protective control over content while it's in-use. The foundation for these integrated services is referred to as In-Place Encryption and Protection.
Encryption alone is insufficient for protecting data, and though we often refer to this mechanism using the shorter form, In-Place Encryption, we are always making reference to the combined set of security services that together increase data protection while also removing end-use burdens associated with traditional endpoint encryption software.
SSProtect encrypts end-user content using the Advanced Encryption Standard (AES), and by default uses a 128-bit key. Use the Licensing and Components interface to enable AES-256, when required.
Note however that AES-256 has been observed to take as much as 40% more overhead than AES-128, though with SSProtect it can be as little as 15% (depending on your environment and hardware). Research indicates that certain side-channel attacks on AES-256 can reduce its' effectiveness to that of AES-128 or even less. The theory behind this is interesting to some, boring to others, important for all, yet not particularly significant in most cases. Because of the way SSProtect manages cryptographic offloading (see below), AES-256 need not be used except when required by standards.
Cipher Block Chaining
SSProtect uses AES in a modified cipher block chaining (CBC) mode. AES-CBC breaks source data into blocks and encrypts (or decrypts) each in succession. With AES-CBC, the output from one block operation provides an input for the next block operation, chaining them together. This creates a contiguous encrypted (or decrypted) result. AES-CBC uses a single Key and a unique Initialization Vector to encrypt and decrypt data.
SSProtect offloads aspects of cryptographic operation to remote (cloud) servers. Servers operate in closely monitored and strictly maintained environments less exposed to intrusion than most business computing resources. Cryptographic offloading increases key management facilities and thus protection, else keys would be limited to host computing equipment where encrypted content is stored. In such a case, even if host keys are, "protected", attacker host compromise exposes host keys, providing access to, "protected" content.
Offloading not only isolates and protects sensitive decryption keys, but also serves as a central point of control in support of precise, accurate auditing, secure data sharing, secure data backup/ restore, disaster recovery, and disclosure analysis - features exposed by modular and scalable/ optional system components.
Cloud Offloading Communcations Protocol
SSProtect utilizes a custom secure data communications protocol between the host operating environment and cloud services. By designing offloading transactions directly into the protocol's foundation, from the ground up, our team has been able to minimize latency and maximize reliability while adhering to the most stringent data security requirements possible. This reduces ongoing risk from 0-day exploits in open source software, programmatic technology frameworks, and protocol standards to delivery a strong security posture without relying on operating system patches and security updates for sustainability.
This is in fact the philosophy brought to bear in all applied cryptographic operations, though it's critical to recognize that the fundamental building blocks utilize known, proven and accepted algorithms, transforms, and techniques. Though our team has access to those who can and have delivered encryption algorithms that are the standards of today, there is no compelling reason to deviate from best practices or use, "custom" crypto. It's worth noting, however, that a proper system should deliver alternatives on the chance that new discoveries reduce the effectiveness of a one-dimensional approach.
Our protocol adheres to best practices to (for example) provide data confidentiality, integration protection, (anti-) replay protection, so-called non-repudiation, and of course perfect forward secrecy while also implementing mitigating facilities for Denial of Service attacks and other ongoing threats.
For details, contact Support and we'll be happy to work with you to show how and why we are able to maintain infrastructure compatibility with a high degree of certainty, reliability, and performance.
To properly utilize remote servers (in the cloud), the software first encrypts source material at the host while storing the host encryption key locally. This insures that the cloud service layer never has access to plaintext material. There are many cloud encryption solutions on the market today, and not all of them (surprisingly few) encrypt data before transporting it to the cloud. SSL/TLS alone does not address this issue, since the receiving end acquires content in the same form supplied at the host. As such, content in plaintext form - if even briefly - becomes a point of opportunity for malicious insiders and attackers. This is a prevalent point of weakness addressed by first encrypting host content, then uploading.
As noted before, storing decryption keys with encrypted content offers little practical protection. SSProtect uploads the encrypted file to remote servers (in the cloud) then performs another encryption operation using an independent server key. This key is kept on the remote server (in the cloud) while the double-encrypted result is returned for storage on the host.
When data is later accessed, :Access manages the request using 2-factor authentication before performing partial cloud decryption then finishing at the host. This inhibits impersonation (i.e. an attacker pretending to be an authorized user with use of a stolen password, for example).
NOTE: Hybrid Conversion is now the preferred method for :Recover operation, though both Modes are available and supported. See below for more.
Ineffectiveness of Login Gates
Though 2FA is offered by some providers, SSProtect applies 2FA to every privileged request rather than unlocking a sensitive archive of data with a single 2FA-enabled Login operation. This latter approach only serves to open an archive for long-term access, which exposes content to attackers lying in wait. For a real-world example, with an attacker statement on this very reality, see our review of The Hacking Team breach.
SSProtect provides an alternative mode of operation - Optimized Offloading - to increase performance when :Recover is not being used. This approach utilizes a modified Cipher Block Chaining mode of AES to encrypt blocks on the host while at the same time partially offloading block encryption to remote servers. The first block is always double server(cloud)-encrypted, and from there individual blocks can also be offloaded to the cloud to provide a random distribution of host/ server participation. This minimizes the amount of data transfer and also reduces the need for complete redundant encryption while retaining the advantage of server-isolated keys (with respect to the host where encrypted content is stored).
Why not upload the file and encrypt once? We do not permit service provider access to your plaintext material, since no amount of procedural control or sandboxing will stop a malicious insider at all times. The only suitable path is to make sure your plaintext data isn't available in the cloud, which remains a fundamental and ongoing requirement for managed data.
Starting with v7.2, Hybrid Conversion replaces Double Encryption as the preferred Operating Mode. Hybrid combines aspects of Optimized Offloading and Double Conversion Modes to more than double the performance of Double Encryption. However, when using Hybrid Conversion, owners using :Recover cannot Restore instances created by sharing peers without first acquiring changes (directly from the sharing peer) and accessing changes.
When using Double Conversion, this is not the case: You can directly Restore shared instances created by peers who have modified content you own.
Refer to the Re-Protection Policies section of the article, Protected Data Sharing, for more information, and speak with Support who can enable Double Conversion for you, if so desired.
SSProtect utilizes encryption as part of its' protective proposition. Because protected content retains flexible use, it will be exposed to malice and corruption. AES Decryption, alone, can detect some data modification, but not all. As such, with ordinary AES encryption/ decryption, it's quite possible to open a corrupted file and never know it. In fact, corruption in these terms is not always observable.
SSProtect integrates HMAC-SHA512 into the core mechanism used for data protection, providing assurances that data integrity has been retained. This is a configurable setting that can be adjusted in the License and Components interface. When enabled, if you attempt to access a protected file that has been corrupted or modified, the operation fails, protecting you against malice and/ or corruption.
Overriding Integrity Protection for Troubleshooting
You can override Integrity Protection failures to access plaintext content by enabling the override in the Account Configuration dialog (Individual Accounts) or Administer Users display (Organization Accounts). Override only applies when performing a Release Protection operation, and always requires that you choose whether to proceed or abort (by responding to a prompt so you have absolute insight that corruption has been found).
Integrity Override changes for Individual Accounts are temporary, valid only for the duration of a single SSProtect Login Session. Overrides for Organization Users are configured for each specific Account, however remain in effect until disabled.
NOTE: Use this feature with caution, and never continue forward with content accessed after an Integrity Check failure, since it will be corrupted even if not observable. Contact a DefiniSec Representative for details.
Performance and Flexibility
Optimized Offloading is by far the better performing mechanism. You can in fact configure the system to dynamically switch from Double Encryption to Optimized Offloading when target files transcend a certain size threshold. Configure these options using the Account Configuration display accessible from the notification icon's context menu. There you can set the threshold and choose to automatically switch from Double Encryption to Optimized Offloading, deny the dynamic switch altogether, or ask to be prompted to decide on the fly. When this mechanism is disabled, you can also set a high-limit threshold for encryption operation, failing when target file sizes exceed the limit you configure. This can help when managing :Recover Quota limits.
IMPORTANT: Don't forget that Optimized Offloading will NOT keep a backup copy of your protected content, thus you will not be able to utilize :Recover to retrieve any file instance you choose to protect with Optimized Offloading. This may be OK for certain circumstances, which is when the Prompt option for dynamic switching may be more suitable.
When sharing content between two Accounts, Conversion Modes may not be the same. Shared, managed re-encryption utilizes the policies set forth by the data owner when content was last protected. At present, reprotected content retains its' association with the owner's :Recover Archive and thus Quota. If a hard Quota Limit is exceeded, reprotection will fallback to Optimized Offloading and send a note to the Owner that his/ her Quota Limit has been reached.
At the present time, when using :Recover and Hybrid Conversion, shared instance content is not available for owner Restore. This is not the case when using Double Conversion. Note however that, with Hybrid Conversion, the original owner only needs to execute a managed open/ close operation at which point the modified data will be server-retained and available for Restoration.
These states can be enumerated using the Managed Files/ Restore display: Versionlist items will have a non-zero size when they are stored in the server (cloud) Archive. All three panes - the Hostlist, Versionlist, and Archivelist - use context-sensitive Restore/ Replicate buttons based on the target selection, indicating items available for Restoration.
Effective use of encryption together with access control can provide a suitable barrier against challenging attack dynamics. Isolated encryption is not enough, and when cryptographic offloading is introduced to an already effective integrated solution, capability rises to levels suitable for the most advanced threats known today. SSProtect offers these capabilities with options - Double and Hybrid Conversion for those that want the convenience of backup and restore, Optimized Offloading for those who have more stringent performance requirements, and the ability to switch between the two on-demand while incorporating Data Integrity validation and maintaining continuous protection, independent of an item's managing container - each unique across the industry, and the cornerstone on which additional unified security services are based.
Intellectual Property Disclosure
In-Place Encryption and Protection, cryptographic offloading techniques, and other critical aspects of SSProtect, KODiAC, and its' components are protected by U.S. Patent No. 9,961,048: A system and associated software for providing advanced data protections in a defense-in-depth system by integrating multi-factor authentication with cryptographic offloading.
This article was updated w/ v9.1.3 of the :Foundation Client