Solutions for Portable Security

Some people may be confused when scanning MXI Security product literature. Sometimes we say that with Stealth MXP you get two-factor authentication and other times we say three-factor authentication. It is the same device so what is going on?

As a reminder, authentication consists of proving your identity using one or more of the following:

* Something you know (passwords, PINs, etc.)
* Something you own (driver’s license, token, corporate badge, etc.)
* Something you are (biometric: face, finger, voice, retina, etc.)

With Stealth MXP you have on-board, a biometric and/or a password to unlock the device depending on the policy your administrator has set. For this discussion let’s assume that the policy is set to require a password and a biometric. That is definitely two-factor authentication. But isn’t the device itself considered a factor? After all, I own it and that would make three factors, right?

The answer is it depends. If you are just accessing the files on the private drive then you are using two-factor authentication. However if you are using a piece of data on the device (such as a private key) to login to a system then that would be three-factor authentication. Authentication is about proving to another entity that you have a particular identity. If the device isn’t involved in this process, then it is not a factor.

Ownership is a tricky concept in authentication. In the digital world it can be somewhat abstract and mean owning a piece of data such as cryptographic key, rather than something physical. This is how some solutions claim that a “software” token is two-factor authentication. In this case one factor (a password) is used to unlock the “token” before the correct result can be presented to an authentication server. Since the result depends on a computation based on the cryptographic key, you have ownership of this key being a factor. Of course storing this key in a hardware protected device is much better than storing the key in a file that is software protected.

On the other hand, pure hardware is not necessarily a strong factor of authentication. Consider the Startup Key option with Vista BitLocker drive encryption. Here the user must insert a USB flash drive containing the Startup key in order for the computer to boot. The problem is that anyone who finds (or steals) your laptop along with your USB Startup key immediately has access to decrypt your disk. Technically speaking this is authentication via ownership but it is very weak. Unfortunately BitLocker doesn’t allow password entry for USB flash drives. Your best bet for the Startup key option is to use a device like the Stealth MXP, where the key is protected by hardware with biometric authentication. By the way that happens to be two-factor authentication.

There are many examples of three-factor authentication that can be achieved with Stealth MXP today; logging into Citrix with RSA SecurID, “smart card” login to Microsoft Windows, SSL client side authentication to web sites. In all these scenarios, there is a digital credential (an RSA SecurID token seed, or an RSA private key) owned by the user, securely stored in MXP hardware and protected with biometric and password access. Hope this makes things a little clearer.

Recently there was an article published whereby several USB sticks with biometric authentication were found to be completely insecure (See “Easy to crack” http://www.heise-online.co.uk/security/Secure-USB-sticks-cracked–/features/110280/0).

In the article it was demonstrated how on some “secure” USB devices biometric authentication can be bypassed completely. Rest assured that biometric devices from MXI Security do not fall into this category. We have secure implementations of biometric and encryption technology within our devices.

I want to delve into this topic a bit deeper and provide a bit of insight for readers who want to be better equipped to challenge biometric technology vendors on the security of their implementation.

I like to categorize the deployment of biometric technology in four ways based on where the biometric matching is actually done.

1. Match-on-PC
2. Match-on-Server
3. Match-on-Card (on a smart card that is)
4. Match-on-Device

First, matching is not the only part of a biometric process. There is also image capture whereby an image of a biometric sample is captured from a sensor, and template creation where the image is processed to extract the important features for the matching algorithm. Template creation is actually done in two places within the overall biometric system; a) to create enrollment templates when you first register your biometric, and b) to create verification templates that are used in the actual matching when you are attempting to authenticate. For the best biometric security, all three of these processes (image capture, template creation, and matching) must be done in a trustworthy environment.

Here is a useful fact that is generally true for biometric technology and can help you read between the lines: matching is computationally much cheaper than template creation.

In Match-on-PC the local host system is used to do the biometric comparison. What does this mean? Well it means that your enrollment templates and your verification templates are compared in software on the PC, out in open, and exposed to the seething pool of malware that might be on the system. Furthermore, it probably means that template creation is also done on the PC because if the matching needs to be done there, most likely there is no where else to do the template creation either. If your biometric templates are compromised it could be bad news for whatever systems you are protecting with biometric authentication. Tip: don’t ever use a Match-on-PC implementation at an Internet Café. Until PCs become trustworthy platforms I would never contemplate using this mode.

Match-on-Server is much better than Match-on-PC. Assuming the server is protected and trusted, it is a safe environment to do the biometric matching. Most often though the server will have a database of user templates, which raises privacy concerns for many people. Unfortunately server implementations can be expensive to deploy because of the need to protect biometric information in transit, and the need to provide scalability, fault tolerance, and high-availability. Another thing to watch out for in a Match-on-Server implementation - and this is important - is that template creation has to occur somewhere. I’ll bet that 90% of the time it won’t be on the server because of the extra processing requirements. So where is it done? It might be on the PC where the sensor is attached which would be bad. If instead it is done on the biometric sensing device then there needs to be a good reason to have a server since the device probably has the power to also do the matching. A couple of potential reasons could be: a) the biometric devices are not portable and since many users use the machines the templates need to be stored centrally, or b) the server is doing biometric identification (checks against many templates, not just yours), for some reason or other.

Match-on-Card is rather interesting. Smart cards are very secure platforms in which to perform any kind of security function. Biometric matching has been tough to achieve on a smart card because of the processing requirements but there are several implementations now available on the market. Smart cards don’t have biometric sensors built into them and they certainly don’t have the power to do template creation. So again, a Match-on-Card solution needs a trustworthy environment (outside of the card) where the other parts of the biometric processing can occur securely. One option here is a portable device that contains the smart card chip or a secure smart card reader with the biometric sensor and processing power built in.

Match-on-Device can be the most deployable and the most secure type of biometric implementation. Here the image capture, template creation and matching are all done within hardware (preferably a hardware device with certified security). No biometric information ever leaves the device. Furthermore as mentioned above, this can also be a good hybrid solution with a Match-on-Card technology. Because of the portability and no requirement for a server infrastructure it is a very attractive solution from a cost and usability perspective. In addition, the enrollment templates are carried securely in the possession of the user so there are no privacy issues to be concerned about.

This brings me back to the title of this article and why you should be wary of biometric images. If you see a biometric image being displayed in a user interface while your sample is being captured, then your biometric information is being exposed to the system that is displaying the user interface. I know it’s cool to see your fingerprint displayed, but think about where the software is running.

I’ve been doing some more thinking about secure online banking. Being in the security industry I’m very familiar with the endless cycle of new threats, attacks and countermeasures and I keep wondering if we’ll ever be able to win the computer security arms race. I wonder if computers will be able to provide more security as they get more sophisticated and powerful. Will phishing become obsolete because artificial intelligence will simply filter all the bad stuff out, or will it become worse because artificial intelligence will be helping to craft phishing emails targeted to you with such precision that its authenticity can’t be distinguished from legitimate emails?

In “The Age of Spiritual Machines”, Ray Kurtzweil predicts that by the year 2019, a $1,000 computing device will be as powerful as a human brain. With the right “software” you’d be able to have your own personal digital assistant equipped with artificial intelligence that could handle mundane tasks such as keeping your LinkedIn profile up to date or interacting with your friends on Facebook when you can’t be bothered. It might even manage your finances. After all, it could do a far better job at paying bills on time, picking the right investment, and minimizing tax implications.

I’m going fast forward to 2019 and paint a scenario. Let’s say my artificial intelligence makes an investment that turned bad due to “unforeseeable” market changes. It’s not to blame but I get upset and decide to change my bank login credentials anyway so it doesn’t have access anymore. Can the personal assistant do anything about it? It can certainly try. It knows my voice and has a really good sound card installed so it calls the bank. The following interaction ensues between the Artificial Intelligence (AI) and the Bank Representative (BR):

BR: Thank you for calling online bank, can I help you?
AI: Um, yeah, it’s Larry Hamid calling and I forgot my login password.
BR: OK Mr. Hamid, can I have your bank ID number?
AI: Sure. Here it is…182938389423965
BR: I need to ask you some questions to confirm your identity if you don’t mind.
AI: No problem.(After collecting basic personal information, the Bank Representative digs for information that should be less commonly known.)
BR: Can you list any products or services that you currently use at online bank?
AI: Yeah. I have a mortgage, a savings account, a checking account, two lines of credit, two credit cards, a…
BR: That’s good enough. Can you tell me some bank transactions or credit card purchases you made recently?
AI: No problem, we can start with the $22.93 purchase at the pharmacy on Wednesday night, seven other purchases totalling $159.24 on the debit card, a money transfer of $2,469.09 into the line of credit which I optimized to reduce the number of minimum payments from 22 to 17, a…
BR: Would you hold on for just a minute?..(music plays on phone)
BR: ….Sorry for the wait Mr. Hamid. I have one more question.
AI: OK.BR: What was the interest accumulated on the credit card balance between the dates of Feb 9 and March 2 on the top 5 most expensive purchases? You have 5 seconds to answer.
AI: That’s easy, $13.98035…oh…
BR: I’m sorry. I won’t be able to reset your password at this time. Thank you for calling.

Lucky for me I included the Turing Test option when I purchased my bank’s fraud prevention service.

I’ve been doing some thinking about online banking and what, if anything, an average user can do to make the online banking experience more secure. I want something that has tangible protection for banking credentials (even if slightly inconvenient) without waiting for your bank to provide a solution.

A huge amount of malicious code and phishing activity is targeted at acquiring your personally identifiable information; bank accounts, passwords, credit card numbers, mother’s maiden name, etc. The motivation behind all of this activity is financial gain. The bad guys want to get into your account and perform a few money transfers.

Despite the pressures from industry and regulatory bodies there is still a logic that banks will use to determine if it is in their interest to deploy strong authentication for their online customers. It goes something like this:

Let X be the cost of deploying a strong authentication solutionLet Y be the estimated cost of not deploying a solution (direct losses to fraud, account resets, legal actions, etc.)If X is less than Y then it is worth deploying. Otherwise they will tolerate the fraud and any impact it might have on their customers (at least until online reputation becomes something of value on the Internet).

Sometimes banks will provide their high net worth customers with strong authentication (such as one-time-password) tokens and leave the rest of us to make do with static login credentials. I happen to be in the second class of online bankers. I worry every time I login about some man-in-the-middle (MITM) or man-in-the-browser (MITB) stealing my credentials. Even if I did qualify to get an OTP token from the bank I know that MITM attacks that have been proven to defeat them so I’d still be somewhat worried.

What can you do if you want better protection? Here’s a do-it-yourself recipe for a solution that will give you pretty good protection against MITM attacks and some protection against MITB. Before I give the recipe, let’s look quickly at the nature of the attacks I’m talking about.

Some MITM attacks are transparent to the end user and require no social engineering. These include protocol downgrade and cipher downgrade attacks on SSL that weaken the encryption enough so that an attacker can discover the keys (with some effort) and decrypt all of the captured traffic. Another transparent attack can occur from within the browser. By having a malicious certificate installed in the browsers certificate store the attacker can spoof web sites without causing any certificate warnings so the attack can really go unnoticed.

That being said, many people don’t know how to deal with certificate warnings and often say “OK” and to trust the certificate anyway. Unfortunately, many legitimate servers really do have problems with their certificates, such as being expired, having non-matching common name with the server host, or they are self-signed. As a result many users are accustomed to accepting certificates with problems for legitimate servers. Exploiting this tendency an attacker to presents a spoofed certificate in the start of an SSL session in the hope that a user accepts it out of habit. If the user accepts, the attacker simply relays all the traffic between the client and the server that it sees in the clear.

Recipe:

1) Obtain a USB flash drive with some security features. At a minimum, it should be configurable with a true read-only area where you can lock down software.

2) Obtain a good portable browser (I’ll use Portable Firefox for this recipe) and unpack it somewhere on a “trustworthy” machine.

3) Go into the encryption tag under Advanced Options and make sure that the Use SSL 3.0 and TLS 1.0 options are checked (this prevents older versions SSL to be used).

4) Go into the Security options and enable security warnings for information that is submitted that’s not encrypted.

5) Configure the browser certificate store to contain the certificates of the sites you want to interact with. You can do this by visiting the site, viewing its certificate and adding it to your trusted certificates.

6) This is the longest step but if you really want to lock things down so that only the sites you want to visit won’t give you a warning, go into the certificate manager on all certificates in the authorities list and disable the “This certificate can identity web sites” option.

7) Package up this configuration and install it on the read-only area of the flash drive.

Now you’re ready to do your online banking with the following security defences.

1) Your portable browser is resistant to MITB attacks. Because it is installed in a read-only area, it cannot be permanently infected. Any malware that attacks it will only survive until the device is removed.

2) You have a white list of trusted SSL web sites. Any other site that you visit, even legitimate sites with valid certificates, will present you with a warning.

3) You will also be presented with a warning if you are on a login page that allows credentials in a non-encrypted session.

Provided you use this configured browser from the USB device you can visit your banking site, establish a trusted SSL session, enter your banking credentials (even an OTP) and be safe from MITM.

You should still exercise caution. No other site should be asking for your bank login credentials except sites that you trust. So don’t visit URLs from suspicious sources without using your secure browser. You’ll know if it isn’t trusted because your browser will tell you. Pay attention to the warnings because now they really do mean something shouldn’t be trusted!

Unfortunately, there are nastier problems on the horizon besides phishing and MITM. The next wave of attacks will come from malware in the machine and the bad guys won’t even care about capturing your login credentials. Instead, these attacks will wait until you’ve logged in and will then go to work behind the scenes altering your transactions and setting up their own money transfers from your account. But that’s a problem to solve for another day.