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. It is also used when other Operating Modes fail, for example if they exceed the :Recover Quota or a host-specific :Recover Limit as described in the article, Managing Your Account.
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 Managed 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 he/ she creates with :Recover enabled. Whether or not a Data Owner can Restore a Version Instance instantiated by an authorized Sharing Peer depends on the Operating Mode and sharing relationship, 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 authorized to access content, and he/ she does so, this creates the Version 2 instance. You can of course access that instance when the sharing peer delivers the v2 instance back to you, but you can't always Restore v2 independently.
There is in fact only one case that precludes v2 (from a Third Party Trust) Restore - and that is when using Hybrid Conversion. Thus:
- When you, as the Data Owner of an item, share a Version Instance created with Hybrid Conversion, you CANNOT Restore instances subsequently created by Third Party Trust access.
Note that you can Restore Version Instances created by Organization Peer access. In fact, in any other case that :Recover is enabled for the source material, you as the Data Owner can Restore Version Instances - versions you create, versions instantiated by Organization Peers, and versions created by Third Party Trust access (so long as the source material used Double Conversion). As such, the following is true:
- When you, as the Data Owner of an item, share a Version Instance created with Double Conversion, you CAN ALWAYS Restore instances subsequently created by Third Party Trust access.
This is one of the major use-case differences between Double Conversion and Hybrid Conversion. The other major consideration is specific to the way content is stored in the KODiAC Data Archive. When using Double Conversion -AND- when authorizing an Account associated with the KODiAC Cloud Services MSP, the theoretical plaintext separation claim is violated. While plaintext remains inaccessible to the MSP, the materials necessary to access plaintext content do not achieve the same level of strict Zero Trust adherence achieved by the use of Hybrid Conversion.
More information can be found in the article, Using Shared Data , in the Looking Deeper... section below, and also through detailed discussions with our team, coordinated through your DefiniSec Representative.
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: Log In 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: With the v2 item selected, hold the Shift key and click the v1 line to select both items, 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. While still holding the Shift key, right-click the selection and 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 Log In 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 (given our definisec+test1u1@gmail.com Account uses the Profile/ Alias Org1_User1).
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 - or any MSP resources, for that matter - to access your content, and there is also no means for that User (or anyone else) to decrypt your content except when you grant them Third Party Trust rights and share content with them, directly.
We can illustrate the progression and subsequent warning, shown below, by doing the following:
- First, the MSP enables Double Conversion for the Test Org2_Admin Account
- Org2_Admin navigates to Sharing Policy/ Manage
- Org2_Admin attempts to Trust 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 (or Managed Service Provider) employee, and as a result, if/ when using Double Encryption, the sanctity of theoretical isolation is violated.
It's important enough to state more than once: There is no mechanism for any DefiniSec User - or anyone else - to access your stored content to recover plaintext data. 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. This would of course, by design, trigger a variety of internal protective warnings, and for obvious reasons access to different aspects of internal operations is highly segmented and restricted to trusted resources that undergo aggressive scrutiny.
However, for the sake of integrity and because we back what we claim, it's critical to us that we share these details so you can make properly informed data management decisions.
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 internal staff can get to your KODiAC Managed Data Archive, the encryption mechanism and key combination is isolated such that, for all staff and all time, your content is protected. With access to all KODiAC Cloud Services content, it's by design theoretically impossible to reconstruct plaintext. They decryption keys aren't there, and never have been.
Stated another way, Hybrid Conversion-stored data isolation is technically and theoretically sound unless an attacker - DefiniSec or otherwise - breaches both KODiAC Cloud Services and also very specific end-user host computer(s).
This only changes if and when you use Double Encryption and choose to authorize as a Third Party Trust a member of the KODiAC Cloud Services operations team using SSProtect. Even still, you will receive a warning when trusting such resources and at the same time can maintain peace of mind knowing that there is no mechanism for accessing the materials required to reconstruct plaintext content. Doing so by attempting to access internal materials would be difficult to achieve without detection, which is on par with what most protection claims achieve.
And don't forget 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 business logic was modified.
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