This article describes SSProtect credentials, cryptographic keys, and its' use of two-factor authentication.
SSProtect utilizes multiple sets of keys and credentials to protect managed content and simplify user and administrative involvement in protected transactions. The software implements a patented multi-party trust model that combines cryptographic inputs from a host computer and KODiAC Cloud Services with embedded, fine-grained two-factor authentication to securely manage content. By design, compromise of host cryptographic material is not sufficient for access to protected content.
For a high level overview, refer to the article, Our Technology.
Protected Host and Cloud Storage
Host keys associated with SSProtect Accounts are stored using multiple layers of protection beyond the scope of this article. Some of this content is uploaded to and securely stored in the cloud, though retains total theoretical isolation from cloud resources. This removes the need to use host-based backup and restore services for :Foundation Client configuration data.
RSA Keys for Cloud Isolation
Accounts and Organizations utilize RSA key pairs to both isolate protected content from KODiAC Cloud Services and to facilitate zero-configuration secure data sharing between Organization peers.
Cloud isolation protects your data from exposure to the Service Provider, in this case DefiniSec, and protects against any legal proceeding that requires us to provide decryption keys. In this case, your data will retain obfuscation since decryption requires materials managed by and isolated on your host computers. As a result, you will always know when your content is accessed, since legal proceedings will thus have to be extended to request decryption keys from your company.
RSA Keys for Secure Sharing
Key use for Secure Sharing provides a way for SSProtect to remove end-user procedures that specify for whom content is destined before it is encrypted, common with many encryption solutions. By utilizing a more complex set of key relationships and the multi-party trust model, SSProtect removes the burden of policy making from end-users and places it in the hands of more qualified personnel (Administrators and Delegates).
Third Party Trust associations utilize these and other resources to extend data sharing authorization to Accounts outside an Organization. These are also dynamically managed by Administrators and Delegates, and can be created, enabled/ disabled, and removed on the fly with immediate impact. For more information, see the article, Protected Data Sharing.
Key Generation and Import/ Export
RSA key pairs are generated during Account Registration, and the one Administrator Account for an Organization manages Organization-specific RSA key pair generation. Keys are exported as part of 1st Time Use proceedings, and export is critical when operating as an Individual Account since keys are required to recover a lost Account Password.
Key Import is not generally enabled, though utilized in specific cases, such as password recovery for an Individual Account or Organization Administrator that has no Delegate peers.
When you use SSProtect, you start by establishing a Session using your Account Password for Login. Each Session remains valid for a configurable period of time. After your Session ends - whether due to Logout or expiration from timeout - you will be prompted to Login again only when you perform an operation that uses the software (for example by opening a protected file).
Enhanced Two-Factor Login Authentication
SSProtect supports two-factor authentication for Account Login using Duo Security service integration. Referred to here as Enhanced 2FA, the procedure invokes Duo Security services from KODiAC Cloud Services after you provide your Account Password during SSProtect Login. This transaction requires external authentication verified by Duo Security, with results delivered back to KODiAC Cloud Services, completing the authentication request. If the additional Duo Security authentication factor is not satisfied, the cloud rejects the Login request.
Enhanced 2FA is managed by an Administrator (not a Delegate). It can be configured for all Organization Accounts, and enabled/ disabled for each individually. For details, see the article, Enhanced Login 2FA with Duo Security.
Significance of Integrating Enhanced 2FA from the Cloud
The use of KODiAC Cloud Services to dispatch an authentication request to Duo Security services provides isolation from host attackers that, in some cases and with a reasonable amount of capability, would otherwise be able to intercept direct host requests and bypass authentication. This is a standard mistake unfortunately used throughout industry, which when coupled with the concept of a, "Login Gate" i.e. one-time authentication to unlock access to managed content, creates a false sense of security by offering very little effective protection.
For more insight into various pitfalls surrounding improper use of two-factor authentication, see the Spiceworks Spotlight on IT article, No Single Weakness: File protection best practices for the worst-case scenario.
Two-Factor Transaction Authentication
SSProtect uses two-factor authentication for all qualified transactions.
When you perform an operation managed by SSProtect, it will always compute and use a one-time password in accordance with IETF RFC-4226. Entitled, HOTP: an HMAC-Based One-Time Password Algorithm, this is the standard that is used to create the 6- and 8- digit codes (OTPs) you receive on a mobile phone or in an email and use to login to protected web services, for example.
SSProtect generates and uses OTPs with software or hardware, depending on your Account configuration. Software-based 2FA is automatically configured when you Register your Account. When you configure a hardware 2nd-factor token, the system switches from use of software OTPs to use of the more secure hardware token.
Warning: Fallacy of Mobile Application 2FA Codes
We don't support the notion that mobile phones with 4226-based OTPs provide viable protection. In fact, our foundation patent awarded in May 2018 uses language from the original 2014 filing specifically calling this out as problematic. Since that time, there have been numerous far-reaching breaches that take advantages of related shortcomings.
Our use of software-based OTPs offers a path to hardware-isolated protections that can be enabled by further configuring hardware-based 2FA, built directly into our secure protocol and the heart of our encryption/ decryption facilities. See below for more.
Software-based Two-Factor Authentication
Software 2FA proceedings can be exposed to Organization Account users, resulting in a prompt that must be acknowledged as part of any SSProtect transaction. If the prompt is not acknowledged, the OTP is not computed and the submitted transaction fails the authenticating prerequisite. For details, refer to the article, Simulating the 2nd Factor.
Note that the process of prompting an end-user for a 2nd-factor simulates a hardware token's physical presence requirement of pressing a button on a USB key, or similar, as a prerequisite to emitting its' resulting OTP.
Hardware-based Two-Factor Authentication
You can configure hardware tokens for use with all SSProtect 2nd-factor authentication requests, replacing software-based 2FA for every Account. The underlying authentication mechanism will automatically switch to use the more secure hardware token when it is configured and enabled. Hardware 2nd-factor Authentication Tokens are managed by Administrators and Delegates, as described in the article, Hardware 2FA.
The SSProtect implementation of RFC-4226 utilizes a 12-bit Identifier, an 8-byte Moving Factor (counter), and a 20-byte shared secret. SSProtect :Assess reports display the managing Token ID for every event (alongside the email identity for the associated Account).
Software 2FA token attributes are stored with secured :Foundation Client configuration data, and thus securely backed-up in the cloud (in fact removed from the host when a Session terminates).
Hardware 2FA token attributes are not stored on the host since they are isolated and maintained (most often) by externally connected devices (that often utilize a write-only capability for the shared secret). See below for details on how sensitive attributes are isolated from potential cloud system exposure.
RFC-4226 Shared Secret and OTP Matching
RFC-4226 relies on the use of a shared secret to verify OTPs. These work by having requesting parties calculate and submit the resulting one-time password's 6- or 8-digit code, while the authenticating party uses the token identifier to lookup the shared secret and associated counter to compute its' own OTP. The authenticating party then compares its' expected result with that submitted by the requesting party, and when a match is found, the authenticating party has a high-degree of assurance that the caller holds the token managing the shared secret, so long as the token and subsequent SSProtect configuration were done in a secure fashion (a prerequisite to the use of any similarly functioning hardware authentication device).
OTP Counters and Reset
Counter-based OTPs can get out of sync for a variety of reasons. When this occurs, and independent from considerations regarding potential attacks, Administrators and Delegates can submit a request for an Account's 2nd-factor counter to be reset. This is done from the Administer Users UI available in the context menu associated with the notification panel's SSProtect icon. After this request is submitted, the next attempt by the target Account to authenticate with its' 2nd-factor should succeed. If it does not, the counters are too far out of sync which can be a strong indication of a greater issue. In this case, the process can be retried, though most likely the token will have to be reconfigured and/ or replaced.
Note that, though this can happen with software 2FA, the safeguards utilized by SSProtect should not lead to any scenario where this occurs naturally, such as using batch or bulk conversion. In fact, the software utilizes special provisions to ensure that the software 2nd-factor and hardware counters are properly maintained in these circumstances. As such, if you encounter problems, contact Support so we can help you recognize if and when these dynamics are as a result of malice or other related dynamics.
Protected Cloud OTP Attribute Storage
SSProtect does not store hardware 2FA Identifiers, counters, or shared secrets in plaintext form. Access to this information requires input from the requesting party, i.e. the end-user and resources associated with the SSProtect Account he/ she uses. This limits cloud exposure of sensitive 2FA details, which is critical if storage systems are compromised by those who manage cloud infrastructure used to host KODiAC Cloud Services.
Displaying and Managing 2FA Resources
The software 2nd-factor ID and Moving Factor are displayed in the Administer Users display for Organization Accounts, and the Account Configuration display for the Account associated with the active SSProtect Login Session. Both are accessible using the context menu associated with the notification tray icon.
User Import/ Export and Credentials
Exported User lists also contain the software 2nd-factor ID and Moving Factor, and have a placeholder for the 20-byte secret that you can specify for new user Import, though a secret is created for new Accounts when one isn't provided.
Credentials in :Assess Reports
Hardware 2FA use is reflected in :Assess report entries by use of the hardware Token ID for transactions that use hardware 2FA. The actual Authentication line item utilizes an (H) to depict the attempted use of a hardware 2nd-factor, whereas software 2FA execution uses an (S) qualifier.
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 email@example.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/ v8.5.1 of the :Foundation Client