This article explains how SSProtect uses two-factor authentication for host data protection.
How do you protect information on a host computer that is compromised by an attacker? Make sure it isn't there.
In some respects, this is what SSProtect provides - the ability to present a protected asset - or file - on a host computer that is inaccessible to anyone but an authorized user. Hosts compromised by attackers that use stolen credentials won't be able to remotely acquire access to content because this access requires the use of two-factor authentication, which can require a physical presence at the console in order to succeed.
How does this work?
Data encryption utilizes an encryption key and a decryption key. Sometimes these are the same, sometimes they are not. This gets fairly complicated, so we'll set that aside for now. The important thing to know is that decryption keys cannot be stored with the data that's protected if you want to retain protections when the host is compromised. Else, the attacker with stolen Administrator privileges - which generally have access to all resources on the host - can get to the decryption keys and access the encrypted content.
SSProtect isolates managed content decryption keys, and acquisition requires two-factor authentication to combine them w/ managed ciphertext (encrypted data). This second factor is the inhibiting component in the equation, and the scenario plays out as described below.
Accessing Protected Data
When you access an SSProtect'd file, you first Login to SSProtect using your account Username - your email address - and your Password, a secret phrase known only to you. When the host is compromised, the attacker can install and run a keylogger which then steals your Password as you type it in. When you leave for lunch, the attacker, who is monitoring your system, recognizes that you are gone and executes the same login procedure using your Username and the stolen Password. As a result, the attacker can now access protected content, and the compromise is complete - your new invention is now in the hands of a leading counterfeit manufacturer, and in 2 weeks you see an infomercial peddling your new floating beer koozie for $19.99 and free shipping.
Enter the 2nd-factor
SSProtect, however, employs a second authentication factor. In this case, when the attacker attempts to access managed data, the 2nd-factor prompts you (him/her) to touch a USB key you have plugged into your machine. Though the key remains attached, you aren't there to touch the button that then generates a seemingly random number that is nearly impossible to guess. This number would normally be dispatched to KODiAC Cloud Services for processing. If the number matches the expected value, decryption is carried out using cloud-stored/ isolated keys (and a set of patented methods to maintain protected isolation).
Resulting plaintext would then be presented for an authorized user to review and edit. But since the attacker cannot touch the button on the USB key, and since the attacker can't guess the proper value, he/she sits and watches the UI prompt countdown to 0 (or enters a guess that fails) at which point the request reaches timeout and gets rejected. Protected content remains protected, and the KODiAC Cloud Services audit records reflect the failed attempt. The attacker is powerless to erase his/ her failed attempt, and over time, maybe a pattern emerges showing multiple failed attempts at lunchtime on different hosts. This may lead to discovery, and perhaps the attacker later gets expelled from the system.
Why the 2nd-factor Works
The 2nd-factor, as noted, generates a seemingly random number when a USB button is pressed. The USB token is designed so that there is no programmatic interface for reading information from the token. The token only allows you to change the configuration, but you can never read it. Why doesn't the attacker reprogram the token? It requires you to press the button when committing new changes...
What is it that's programmed into the token? A secret key and a counter. The secret key and counter together generate a sequence of values that can only be predicted by someone who also holds the same secret and counter. To everyone else, the sequence is seemingly random. The secret key is a very, very large number that cannot be guessed, and the counter simply increased with each request.
See RFC 4226: HOTP: An HMAC-Based One-Time Password Algorithm for one of the many accepted methods of achieving this result.
Text Messages from Web Services
The numeric values generated by the token may in fact be based on the same algorithm used to generate numbers you receive in mobile phone text messages when logging into a web service - after you login, you are prompted to enter the number you receive, usually 6- or 8-digits in length. Sometimes these numbers come from a mobile application that is installed on your phone and associated with your account, and still other times the sequence is generated by tapping a USB token to the phone so that Near-Field Communications can be used to acquire the value from the token itself.
The latter process uses a secret stored in the USB token while the former uses a secret stored in the phone. Either way, it is a second form of authentication supplementing your password. SSProtect and KODiAC cloud services perform the same operation with the same algorithms (and thus the same type of USB token).
Mobile 2FA Passcodes
Phone-based 2FA One-Time Password applications are NOT typically secure, as noted in our patent specific to the protection scheme we employ with KODiAC Cloud Services and a variety of attacks that were executed and publicly disclosed years later. Hardware-based use of these algorithms, with proper (isolated) software service coordination, can offer a high degree of secure authentication.
But Wait, There's More...
The only practical ways to work around this protection scheme are to a) steal the token secret and counter so you can generate the required sequence, b) steal and use the token yourself, c) find a weakness in the implementation to exploit, or d) wait for the user to access plaintext content and try to steal it while loaded in memory.
SSProtect provides process isolation and continuous stored plaintext data access protections in addition to the cloud-based isolation methodology that supports most system services. Details are (well) beyond the scope of this article, but this approach remains unique.
And because of this approach, SSProtect retains compatibility with most any host software application that reads/ writes local data files. Digital Rights Management solutions, on the other hands, do in fact provide protected plaintext access but are limited (often) to Adobe PDFs and/ or Microsoft Office documents since they rely on specific toolkits and features of the target host software applications. These solutions also use custom secure viewers and editors, which often fall very short in terms of flexibility and functionality offered by native software.
IMPORTANT: SSProtect applies 2FA and related protections in an application-independent manner, maintaining continuous protection while plaintext content is natively utilized.
Alternative Approaches to Bypassing Protections
Another possible way to beat the system is to breach KODiAC Cloud Services to steal the USB token secret that the service layer stores. Note however that KODiAC has been specifically designed to be extremely hard to penetrate, avoiding the use of common and error-prone libraries that may present 0-day exploits opportunities for well-financed operations. The system also utilizes a specially designed, highly-secure protocol (as opposed to TLS/SSL, which continues to offer new opportunities for attackers). Ultimately, supporting systems are guarded by a well-trained team that monitors services around the clock. And even still, if somehow an attacker gets in, as it turns out the token secret is...of course encrypted and no, the decryption keys are not stored or available except when SSProtect submits a 2nd-factor authentication value while an authorized user is present...
Stated another way, SSProtect employs extensive measures to make certain 2FA tokens maintain the isolation and protection required to deliver on their promise. That said, there is no such thing as perfect security, and should a system compromise or theft take place, SSProtect Administrators and Delegates can disable an Account's 2nd-factor instantly.
Impact of Auditing and Cryptographic Offloading
Though not necessarily specific to 2nd-factor authentication, this is a good time to recognize part of the inherent value of cryptographic offloading to KODiAC Cloud Services. This is in fact the foundation we're discussing, and that is moving sensitive operations to the cloud and isolating materials until Access Controls permit their combined presence. This provides for secure, precision auditing in the cloud.
As a result, independent from the outcome of protective operations, there exists a fine-grained set of audit records generated and stored in the cloud which can be utilized to immediately determine data disclosure risk. If for example your security team determines that your corporate network was compromised for a three-month period, you can generate a :Respond Report showing all files accessed during that timeframe which then represents the worst-case potential for unauthorized disclosure. For all other protected files, materials remained isolated and thus protections remain theoretically intact due to the underlying design.
This combined reality can save 10s if not 100s of thousands of dollars in costs associated with a response team that shows up on-site to investigate a breach. This often takes a small team weeks if not months to complete, and most often answers include a strong, "maybe" element. SSProtect seeks to replace this aspect of the investigation, greatly reducing complexity and increasing accuracy. This together with Remote Profile Deployment reduces breach impact with assurances for quick and accurate scoping of a breach while maintaining business continuity.
Two-Factor Authentication, Defined
Two-factor Authentication is a method of asking for two different forms of authenticating information that are of two different types or authentication classes. Candidate types include:
1. Something you know, such as a password
2. Something you have, such as a USB token
3. Something you are, such as your fingerprint or retinal pattern
By asking for two forms of authentication that are different, attack complexity dramatically increases. While it's fairly easy, in some cases, to steal a user's Password, it may be next to impossible to steal the USB token that holds the secret required to generate a 6-digit authentication factor. Note also that the 2nd factor utilizes an, "out of band" channel, i.e. a mobile phone or a USB token - different from Password entry to the localhost. Ultimately, almost every system using 2-factor authentication supports near-immediate revocation to manage stolen, lost, or compromised 2nd-factor credentials.
Important Factors In Summary
No pun intended, there are numerous aspects of proper two-factor authentication to consider:
1. 2FA granularity is significant. If you only have to provide a 2nd-factor when logging in, and as a result all protected content then becomes available, an attacker only needs to wait for you to login before quietly copying the now-available archive of, "protected" materials and/ or decryption keys from your system. This is part of what took place during the Hacking Team Breach, which involved acquiring data protected by TrueCrypt, at the time touted as the most secure host data encryption solution available. This is a misnomer, as it serves a different purpose - which didn't stop people (and still doesn't) from improperly deploying it and relying on a false sense of security from common attacks.
2. Physical presence is significant. If the USB token didn't require you to press a button, and you left it in your computer (almost always reality), an attacker could programmatically request the 6-digit passcode required by KODiAC to engage decryption. Though there is a secure and precise auditing mechanism, and integrated solutions can extend SSProtect to help put a limit on the amount of data being accessed over time, the attacker still gets away with at least some information. It helps to have a record of this and know specifically what information was lost - reducing Incident Response costs - but this isn't good enough for us. A required physical presence changes the protective profile more than a little.
3. Cryptographic Offloading is Required, and as we've seen with hardware-specific attacks against Core-integrated secure isolation, it should be done with external devices/ equipment. Otherwise, encrypted and sensitive content's decryption keys are locally exposed, which then means the 2nd-factor merely unlocks local access to intruders that impersonate authorized users. As such, the 2nd-factor would then offer almost no protection at all.
Though for a newcomer this article offers a lot of information related to the way 2-factor authentication contributes to the security of SSProtect'd content, many more factors must be considered when analyzing the resulting protective capabilities of a system. Though we've presented some here and our goal is to offer the most complete and powerful protections known, attackers are going to get in and data is going to be taken. The trick, we believe, is to minimize exposure and manage these dynamics - the priority goal of unified SSProtect component services.
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 firstname.lastname@example.org, 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/ v9.1.3 of the :Foundation Client