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 Administrator privileges - who has complete access to all resources on the host - can get to the decryption keys and access the encrypted content.
SSProtect isolates the decryption keys and the encrypted content then requires two-factor authentication to combine the two. 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 factor - and in this case, when the attacker attempts to access the 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 keys are returned so SSProtect can decrypt and present plaintext to an authorized user for review and editing. 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 at which point the request reaches timeout and gets rejected. Protected content remains protected, and the access logs in the cloud reflect the failed attempt. The attacker is powerless to erase his/ her failed attempt, and over time perhaps 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.
Text Messages from Web Services
The numeric values generated by the token are in fact the same as the 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, which is a 6- or 8-digit number. 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. This 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).
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, or c) wait for the user to access plaintext content and try to steal it while loaded in memory. Note however that SSProtect provides process isolation and plaintext data access protections as well, though these details are beyond the scope of this article. This is however fairly unique, and specifically unique when considering SSProtect compatibility with most any application. DRM solutions that provide protected plaintext access are typically limited to Adobe PDFs and/ or Microsoft Office documents, as they rely on specific toolkits and features of the applications. These solutions also use custom secure viewers, requiring additional training while limiting compatibility with existing infrastructure.
Another possible way to beat the system is to breach the KODiAC cloud service layer to steal the USB token secret that the service layer stores. Note however that KODiAC has been specifically design 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, the 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...
Additional details are quite extensive and well beyond the scope of this article. Stated another way, it's very unlikely that the token will not achieve its' purpose. If however a compromise or theft does 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. No matter the outcome of this and other related operations, there exists a perfect record 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 an :Assess report showing all files accessed during that timeframe which represents the worst-case potential for unauthorized disclosure. For all other protected files, materials remained isolated and thus protections remain theoretically intact.
This simple reality saves 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 sometimes the answer is, "maybe". SSProtect replaces this aspect of the investigation, greatly reducing complexity and increasing accuracy. This reduces breach impact by insuring quick and accurate scope of a breach relative to protected content.
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. 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. Protective 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 and provide the credentials before quietly copying the encrypted materials and decryption keys from your system. This is part of what took place during the Hacking Team breach, which involved acquiring data protected by TrueCrypt, touted as the most secure host data encryption solution available. It does not however approach the levels of protection SSProtect provides until you incorporate Smart Cards, which are more complicated to manage than a simple USB token. Check out our summary of an attacker's breach that specifically waits for a user to unlock TrueCrypt before stealing content here.
2. Physical presence is significant. If the USB token didn't require you to press a button, and you left it in your computer, an attacker could programmatically request the 6-digit passcode required by KODiAC to offer up the decryption keys. Though there is a secure and precise auditing mechanism, and integrated solutions can extend SSProtect to 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. If encrypted sensitive content's decryption keys are held locally on the host and the 2nd-factor is used to, "unlock" the locally stored decryption keys, then in many circumstances the 2nd-factor offers no protection at all. There are some variations of this approach that can be theoretically secure, but losing the USB token would then, in most practical cases, result in the permanent loss of protected content. Though there are ways around this, they pollute the purity of the solution, offsetting its' potential value.
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. For more information, send email to email@example.com and we will work with you to help address your questions, concerns, and needs. In the meantime, consult the Enhanced Login 2FA and Configuring 2FA for Data Protection articles in this section to get started with hardware-based protections that greatly inhibit host-based threats.
This article was updated w/ v4.5.2 of the :Foundation Client