This article combines and defines common concepts/ terms and uses them to show how :Recover and :Collaborate work together.
Introduction
The previous two Walkthroughs in this section showed you how to use :Collaborate Data Sharing, with both Organization Peers and Third Party Trusts. This article introduces you to the detailed permissions that govern :Recover Restore operation with these materials.
Because this Walkthrough builds on prior activities and concepts, we will formally define a couple of the common terms you've encountered, then use them to provide explicit insight on system activities.
Prerequisites
This article works with active state that results from STEP guidance in both the Peer Data Sharing and Third Party Trust Sharing Walkthroughs. Though it's possible to peruse these details to gain insight into the way :Recover relates to and works with :Collaborate Shared Content, results are are more effective if you're able to perform the associated tasks in the recommended order.
Defining Common Terms
In order to provide detailed insight into the operation of SSProtect, we use common terminology that carries very specific meaning. Let's start with an example ordered proceeding then return to further define the terms.
When you, "SSProtect" a resource for the first time, the Account you're using becomes the Data Owner. SSProtect encrypts your content and assigns to it a unique 16-byte FileID that's used to track the item as it changes. SSProtect also assigns a Version number to the resulting protected item, which is in this case Version 1. The resulting Version Instance, then, is comprised of the Ciphertext, the unique 16-byte FileID, and the Version of 1, often written as v1.
When you access Managed Content and make changes then save/ close, SSProtect re-encrypts your data (even if the plaintext material doesn't change) using new keys. The resulting Version Instance however retains the FileID from the source material while getting a new Version number, the value one (1) greater than the largest (and most recent) Version associated with the same FileID.*
The series of Version Instances, then, that share the same 16-byte FileID, make up a Version Chain.
As such, we can define common terms as follows:
Data Owner - The Data Owner is defined to be the Account that's active when an item is first protected.
Version Instance - A Version Instance is a specific revision of a Protected Item (Managed Content), which carries a specific and unique Version Number for a given FileID. Version Numbers are assigned starting at one (1) and incremented by one (1) for each subsequent access. Note that a new Version is created whether data is changed or not: The new Version Instance is encrypted with new Encryption Keys.
FileID - The File Identifier or Identification is a 16-byte random value assigned to the first Version Instance of a Protected/ Managed Item.
Version Chain - A Version Chain is a collection of Version Instances that share the same FileID.
* Version Chain Policy can have an impact on this progression, in some cases creating a new FileID and Version 1 instance. This is described in the article, Version Chain Policy, and covered in the next Walkthrough, Version Chains.
Operating Mode Summary
Before continuing, we need to summarize the different Operating Modes, the methods used to Convert between plaintext and ciphertext:
Optimized Offloading - Optimized Offloading is an efficient and optimized means for Converting a Managed Item, however it precludes the use of future Restore because it does not place a Version Instance in the KODiAC Managed Data Archive. Optimized Offloading is used when an item is created and :Recover is not enabled.
Double Conversion - Double Conversion is the original means for Converting a Managed Item, which stores the Version Instance in the KODiAC Managed Data Archive for future Restore operation. Double Conversion is not by default available for use, and must be specifically enabled by Support due to the way it stores Archive content.
Hybrid Conversion - Hybrid Conversion is the default Conversion Mode when using :Recover, and it combines aspects of Optimized Offloading and Double Conversion to achieve its' result. Hybrid Conversion places a Version Instance in the KODiAC Managed Data Archive for future Restore operation.
In-Place Encryption/ Protection - The automatic way that SSProtect detects end-user access to a Manage File and carries out proper authentication/ authorization without impact to the normal Application Workflow. In-Place Encryption isolates the resulting plaintext, presents it to the Managing Application, and blocks all other access until the File is closed, at which point SSProtect automatically performs a Managed Close operation to re-encrypt content and manage the Version Chain. The process ensures end-to-end isolation of Managed Content, and it operates completely independent of any Application.
General Rules for Data Conversion
When items are Converted to Ciphertext, whether or not using In-Place Encryption/ Protection, there are a few rules that govern proceedings:
- If you are the Data Owner, whether creating the first Version Instance or a new revision/ Version, the Operating Mode will be the result of your Account settings: Only the Data Owner can affect a change to the Operating Mode of an item in a Version Chain.
- If you are a Sharing Peer of any kind, any access to a Managed Item maintains the Operating Mode of the materials first accessed, i.e. with a Managed Open operation, the subsequent Managed Close operation maintains the same Operating Mode as the source material. In other words, Sharing Peers cannot affect changes to the Operating Mode of a Managed Item.*
- If as a Data Owner you first use Hybrid Conversion (with :Recover enabled) then disable :Recover and perform a Managed Access (Open/ Close) operation, v2 will be re-encrypted using Optimized Offloading. The reverse scenario is true, and as a result, enabling/ disabling :Recover switches between either Hybrid Conversion/ Double Conversion and Optimized Offloading.
* Note that Sharing Peer operation can survive Release/ Protect operations on a single item so long as the Sharing Peer doesn't perform a Hostlist Clean operation after the Release and before the Activate operation.
:Recover Access
SSProtect approaches data access by ensuring that the Data Owner can always Restore a Version Instance created with :Recover enabled. Whether or not a Data Owner can Restore a Version Instance instantiated by an authorized Sharing Peer depends, as noted below.
For example, as the Data Owner, you create Version 1 by protecting a plaintext data item (file/ document). If you share this with another User and receive back Version 2, you can't always Restore that 2nd Version. You can of course access v2 with Managed Open (or perhaps SSProtect Release), and you can Restore the subsequent instance, v3, (and also v1) but maybe not v2. There is in fact only one case that precludes Restore operation against v2:
- The Sharing Peer is a Third Party Trust and the source Version Instance was created with Hybrid Conversion.
In any other case (where :Recover is enabled for the source material) you as the Data Owner can Restore Peer-instantiated Version Instances.
Organization Peer Restore
Working from the state leftover from the previous Walkthroughs noted in Prerequisites, above, we'll take a look at Restore capability with Organization Peer Version Instances.
STEP 1: Login as Org1_User3 then navigate to Managed Files/ Restore. You should see one entry for SampleO1User3.txt:
STEP 2: Click Versions... to access the Versionlist, which shows the access history for the Managed File. It was created with :Recover enabled, then shared with an Organization Peer Org1_User1 as shown below:
Notice the right-most column, "A" for Access - both v1 and v2 have, "Y" which means both can be Restored.
STEP 3: Hold the Shift key and click on the v1 line item, then Restore. Click Open Folder to navigate to File Explorer which will have both -v1 and v2 instances present:
STEP 4: Click on SampleO1User3-v1.txt then, holding the Shift key, click SampleO1User3-v2.txt to select both. Right-click the selection then choose, SSProtect Release from the File Explorer context menu.
This will Release Protections for both v1 and v2 instances, at which point you can open each to verify content. As expected, the v1 instance does not hold the same, subsequent v2 material we entered in previous Walkthroughs.
Third Party Trust Restore
We can execute the very same procedure though view content that was shared with a Third Party Trust, which, because of the way Restore works and given we're using Hybrid Conversion and :Recover (the defaults), will operate a bit differently.
STEP 5: Choose OK to exit the Versionlist, then Refresh Login and change your Profile to Org2_Admin. Submit credentials to Login and return to the Managed Files/ Restore dialog. Choose the only entry in the list, then click Versions... to view the Versionlist:
Notice the right-most, "A" column now shows both, "-" and, "Y" for v2 and v1 instances, respectively. Since v2 is already selected, you may also have noticed the Restore button is gray: You cannot Restore v2 because this Version Instance was created by a Third Party Trust to Org2_Admin: Org1_User1 as shown in the Username column.
Because we created the Org2_Admin Account using defaults, :Recover used Hybrid Conversion which, as noted above, is the one case that uses :Recover but precludes Restore of a Third Party Trust Version Instance from a Version Chain you created.
Looking Deeper: Hybrid Conversion vs. Double Conversion
As noted in the preceding materials, Double Conversion has to be explicitly enabled by your MSP in order for it to be available for use. Double Conversion protects data differently than Hybrid Conversion. This not only affects the way content is Converted from plaintext to ciphertext, but also changes access between Organizations.
It's more than a little challenging to explain the way keys are utilized for Policy-based Zero-Configuration :Collaborate, and though patent materials explain aspects of these operations at a high level, we really only need to concern ourselves with the differing end-results.
Hybrid Conversion uses an additional isolation key for KODiAC Managed Data Archive content, and in fact, stores a different format in KODiAC than that stored on your host computer. As such, the Restore operation, when using Hybrid Conversion, requires an extra step to convert materials back to the native form you use when working with content (which by the way matches the Optimized Offloading format).
Double Conversion does not require additional steps - Restore operation places the KODiAC Managed Data Archive instance directly into your target location.
What does this mean? Ultimately, it means, as the Data Owner, you can Restore Third Party Trust Version Instances that use Double Conversion, but not Third Party Trust Version Instances that use Hybrid Conversion. You saw this in the progressions, above.
This has another impact: If you a) use Double Conversion then b) grant Third Party Trust access to an SSProtect Organization Account also a member of the MSP, you may have deduced that theoretical isolation is compromised. Note, however, there is no mechanism for accessing content beyond what you choose to share, and no application-capable mechanism for converting content without your explicit actions.
However, to maintain the theoretical, and despite the tradeoffs offered by Double Conversion, it is disabled until we as your Managed Service Provider clarify this reality with your Privileged Users. If you do not engage in any Third Party Trust relationship with our SSProtect Organization Accounts while using Double Conversion, theoretical isolation is maintained.
Note that all SSProtect Organizations Accounts are flagged. If when using Double Conversion you decide to grant Third Party Trust sharing permissions to an SSProtect Account holder that works for DefiniSec, you will be warned that theoretical isolation is compromised, and as a result have the option to cancel the operation. Else, you will see the results marked in the :Collaborate Data Sharing column with an asterisk.
IMPORTANT: There is no means for any DefiniSec SSProtect Account holder to access your content, and there is also no means for that User to decrypt your content except when you grant them Third Party Trust rights using Double Conversion and share content with them, directly.
We can illustrate the progression and subsequent warning, shown below, with the following:
- First we enable Double Conversion for the Test Org2_Admin Account
- Org2_Admin navigates to Sharing Policy/ Manage
- Org2_Admin attempts to add a DefiniSec SSProtect Account, Support, which results in the following warning:
Note that this same warning is applied if/ when the Organization switches to Double Conversion from User Administration. In fact, you receive this warning whether you are using Double Conversion or not - it's present once Double Conversion is available to your Organization (as noted through request/ review w/ Support).
We'll go ahead and accept the warning to add the Trust so you can see the results:
Notice the asterisk in the right-most, "M" column of the Third Party Trust List: This indicates that the authorized Account is a DefiniSec employee, and as a result, if/ when using Double Encryption, the sanctity of theoretical isolation is violated.
It's critically important to remember that there is no mechanism for any DefiniSec User to access your stored content then recover plaintext. The warning and this text is based on the purity of the theoretical claims we make in all other circumstances. Though in the noted case the theoretical is compromised, it's exceedingly unlikely any internal DefiniSec employee would, in the above circumstances, be able to figure out much less execute the steps required to access plaintext content. However, for the sake of integrity and because we back what we claim, it's critical to us that we share these details and let you decide.
Summary
Most software vendors claim they cannot access your cloud-stored content. That is almost never the case - most rely on internal controls that limit access to employees and operations staff. When using SSProtect with Hybrid Conversion, it doesn't matter if our staff can get to your KODiAC Managed Data Archive, the encryption mechanism and key combination is isolated such that, for all DefiniSec staff and all time, your content is protected.
Stated otherwise, Hybrid Conversion-stored data isolation is technically and theoretically sound unless an attacker - DefiniSec or otherwise - breaches both our cloud service layer and your specific host computer.
This only changes if and when you use Double Encryption and choose to share as a Third Party Trust a member of the DefiniSec Organization. Even still, you will receive the warning, will always be able to see the exception as noted above, and despite that the Third Party Trust doesn't have any means of accessing your plaintext content except when purposely shared by you.
Finally, remember that Data Sharing is not Transitive, in that you cannot grant access to Party A who then trusts Party B and expect Party B to have access to your content. This is again purposed, and built into the protective mechanism so has nothing to do with simple logic - it simply can't be done given the materials available, even if the business logic were modified. That is the essence of true isolation - the essence achieved in all but the most limited case, which still transcends the protective isolation many others have, despite all claims to the contrary.
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.
This article was updated w/ v10.7.1 of the :Foundation Client