SSProtect provisions keys for Accounts and Organizations when Users are created. All Users generate a set of keys associated with an Account, and the one Administrator takes on the added responsibility for generating Organization keys.
Isolating Key Generation
Though it is always prudent to generate keys in a secured environment, it is not practical to be certain that end-user hosts are secured when SSProtect is installed and Accounts are provisioned. Because of the special role the Administrator plays in provisioning Organization keys, you can isolate its' Registration to gain additional security across all related Accounts.
When an Account is provisioned and an end-user Registers on a host, he/ she creates a Password that is used with the Account's Identity (email address) to provide a 1st factor of Authentication. Because Organization membership provides immediate access to sensitive managed peer content, an Account is not available for immediate use after Registration - this first requires Validation by a Privileged User.
Validation allows qualified personnel (the Administrator or a Delegate) to verify that the proper end-user was the person taking action to Register an Account before it can be used. This should be done in-person and through a discussion, perhaps utilizing questions to determine how the procedure was carried out, where, at what time, and then validating these answers with details verified by :Assess Admin Reports.
Once satisfied, use the Administer Users interface from the SSProtect notification tray Context Menu to Validate the Account. This enables end-user Login and use. Note that this procedure is supported by cryptographic primitives that make bypassing it more challenging than simply faking the Validation signal. This procedure couples cryptographic materials with cloud-sourced information that is not available until all transaction parameters are met, from a Privileged User and his/ her actions. See the Multi-Party Trust paragraph, below, for additional clarification.
Individual Accounts and Hidden Organizations
With Individual Accounts, an Organization is created and managed behind the scenes. As you may have guessed, the Individual Account is as a result the Administrator of a one-user, hidden Organization. Key management is no different than that for an Organization Administrator, though the keys hold specific importance when Resetting your Password.
Account Keys and Password Reset
Password Reset relies on the use of both cloud and host-based keys in order to securely create and deliver a temporary password that an Account holder can use to Reset. After this process is completed, a Privileged Organization Account holder must Validate the changed password to provide assurances against attackers
When a Password Reset is requested for an Individual Account, however, the procedure is slightly different. Since there is no other Account available from which to source Organization materials, you must provide refer to previously-exported Keys to proceed. If you do not have them, you will not be able to unlock the Account. The only way to recover content, then, is to turn to Third Party Trusts and ask them to provide you with copies of the data you shared; all other materials will be unreadable.
IMPORTANT: Key Export is of absolute critical importance in maintaining ongoing access to managed content, for both Individual Accounts and Organizations. As with other SSProtect transactions, exported keys are not independently sufficient to access protected content.
Key Export is available from the notification icon's Context Menu by choosing Administer Resources, then at the top choosing Export. This allows you to export Account and/ or Organization keys. This requires a password different from the SSProtect Login password. The resulting key files, though protected with both the password and by nature of SSProtect's multi-party consent trust model (see below), should be stored in a safe archive, offline, and out of reach of attackers.
NOTE: Protecting such resources should be done using a mechanism that requires two authorized users to participate in tandem, protecting against malicious insiders. SSProtect's protections in some cases require two qualified Privileged Users (such as with LOCKDOWN), but Password Reset does not (though all actions are securely audited).
Key Import is built into SSProtect but not generally available for use. This mechanism utilizes multiple safeguards and layers of protective control, however changing keys results in a changed Identity for the affected Account and/or Organization: Despite the fact that end-users utilize email addresses for, "general" Identification, the underlying mechanism is far more complex.
If you believe you have a need to replace Account and/ or Organization keys, contact Support and we'll work together to find the most suitable path.
Flexible Content Sharing
Shared data proceedings utilize over a dozen individual keys to support flexibility. This is not typical, and it permits SSProtect to simplify data sharing for end-users. Where traditional file encryption software asks end-users to choose recipients when data is encrypted, SSProtect utilizes policies managed by the Organization Administrator and/ or Delegates, and never limits sharing as a result of the information provided when content is protected.
This combination of Account, Organization, and Cloud keys provides the multi-party consent (below) and isolation required to insulate sensitive aspects of the transaction from attackers, moving the risk proposition from the host to a highly-secured cloud environment.
Use Third Party Trusts to manage data sharing outside of an Organization, and refer to the article, Trusts, Profiles, and Server Sets for related insight.
Account and Organization keys are not alone sufficient to perform any protected operation or access any managed resource. These keys are additive in nature, and though they represent required aspects of many transactions, they alone are not sufficient for plaintext access.
This is due to the role KODiAC Cloud Services plays in contributing to transactions and protected content, generating its' own protected and isolated keys. This isolation, and the associated methodology for cryptographic offloading, makes it exceedingly difficult for attackers to recover plaintext content or compromise protected services. These and other related methods form the foundation for our data protection/ management patents.
Secure Cloud Storage
Host configuration data is managed using Account and Organization keys, then secured and stored in the cloud for later recall. When an SSProtect host Login Session expires and you are logged out of SSProtect, your configuration data is removed from the local host.* This allows SSProtect to support Remote Deployment and further protect content from host attacks.
Cloud materials are isolated with both cloud primitives and contributions from the end-user and host, making cloud exposure insufficient for recovery of any protected item or the execution of any sensitive transaction. Not unlike the host environment, materials are alone insufficient for access, and require content from, "the other side". The nature of the cooperative trust arrangement raises the effective security of managed content.
* Removing data from an SSD-backed system is nearly impossible. For more information, refer to the article, Secure Erasing Data on SSDs.
Managing Configuration Data with IT Systems
Configuration data is stored in the \AppData\Local folder rather than the \Roaming location, and it is continuously isolated from external access using a variety of layered and multiplicative methods that ensure isolation.
KODiAC however maintains multiple, isolated, secured versions of an Account's configuration data that can be automatically recovered and made available for you to use with Login Recover operations built into the software. For more information or to request access to archived configuration data, contact your DefiniSec Representative or submit a Support request.
This article was updated w/ v8.5.1 of the :Foundation Client