Solutions for Portable Security

From time to time customers ask us what the transfer speeds are of our secure USB storage devices. It’s a legitimate question but one that is difficult to give a straight answer to. Vendors typically quote read/write transfer speeds on their product boxes and datasheets and you’ll see numbers anywhere in the range of 5 MB/s to 29 MB/s. Hopefully speed isn’t the only criteria you use to select which secure USB stick to deploy, but if speed is an important factor you definitely should not make a decision based on the quoted speeds on the box.

If you read them carefully most transfer speeds are qualified with an “up to”, or a footnote disclaimer saying that speeds vary based on host hardware, software, and usage. These are very important qualifiers because your “real world” usage may result in significant (even orders of magnitude) differences from what is quoted.

To illustrate the disparity I have benchmarked a number of devices using a “real world” file copy test in a Windows environment. I only focused on writes because they are generally slower than reads in flash technology. Knowing that smaller file transfers are much less efficient than large file transfers, my tests involved copying many files of a given size and seeing what kind of throughput the devices achieved as the file size changed. The results are shown in the graph below. I also pulled out some samples and put them in a table so you can see the lower end numbers.

The trend is very clear. You get better throughput when you transfer large files, than if you transfer lots of small files. In fact the difference can be astounding. Let’s look at Vendor A for example. If you were to copy 128 MB of data onto vendor A’s product, the theoretical best case time for the copy would be 128 MB /(19 MB/s) = 6.74 seconds. The reality however is that it would take almost 4.5 hours if that 100 MB were made up of 2 KB files. The best case (from the table) is that this 128 MB consists of four 32 MB files to copy and would take just over 15 seconds.

Why is there such a discrepancy? It turns out that there is a lot of overhead in copying many files. File copies are not just about writing the data contained in the files, but also require updates to the file system data structures to keep track of the files and pieces of files. The result is that the device is hit with many extra reads and writes. The more files you have, the more overhead there is and when the files are very small, the overhead becomes significant. That being said, some devices handle the overhead much better than others. Vendor C for could handle the 2 KB file set in 39 minutes. I’d rather wait 39 minutes than 4.5 hours.

You might think that having so many 2 KB files is unrealistic so I decided to check my Internet Explorer Temporary Internet Files cache to see a sample of real data. It reported 130 MB in 2,268 files which is an average file size of about 60 KB. Rounding up to 64 KB and using the table here is how the vendors would stack up if I were to copy this directory onto each device:

Vendor A: 8.3 minutes
Vendor B: 2.2 minutes
Vendor C: 52 seconds
Vendor D: 3.0 minutes
Vendor E: 3.5 minutes

Your day to day information comes in all sizes. Browser cookies are on the order of hundreds of bytes while my Outlook .pst file is pushing 2 GB. It’s important to realize that such a range can have a drastic effect on transfer speeds.

Unfortunately, the only numbers you probably see quoted are optimal numbers, derived in contrived test situations that in most cases are far from the reality that you work in. It reminds me of some car commercials where you see a single car driving at enormous speed on an infinite, flat, empty plain. It looks fantastic, except you know that you’ll be stuck in traffic jams every day and the mileage and experience won’t be the same.

Who hasn’t marveled at the high-tech spy gadgets Q developed for James Bond. Biometric technology was something we once envisioned as only being used in secret facilities and spy agencies, like the CIA or MI-6.

In reality, biometric products have been commercially available for more than a decade. “Lowcost” desktop fingerprint scanners appeared on the market as early as 1995 and soon there was a proliferation of biometric companies and advances in cool technologies such as finger, iris, face, voice recognition and even some not-so-glamorous types, such as smell (body odor) and gait (walking stride).

People and companies became keenly interested in the possible uses of biometrics, making it clear that solutions were needed, not just technology. Vendors quickly responded by demonstrating numerous solutions, including biometric logins, single sign-on, time and attendance and integration with
PKI. Few deployments ever happened though. While there were significant advances in technology, biometrics was just too hard and expensive to deploy.

Now, finally, this situation has changed and we are seeing biometric products that are very deployable. The big deployment issues facing organizations are security, cost, interoperability and usability. One thing that hasn’t changed much is the difficulty of assessing the security of a biometric solution. A first step is to understand whether the technology is accurate enough for your security needs. How good is it at accepting genuine matches and rejecting imposters?

While biometric performance is quantifiable, vendor claims of false acceptance and rejection rates are often exaggerated and biased. The details about how many features are captured or whether it is pattern-based or uses a neural network, and so on, are interesting but not relevant to the performance.

Biometric technology can be treated as a black box — with biometric image samples going in and scores coming out. It is best to turn to independent, third-party technology evaluations that have done the hard work to develop trustworthy comparative numbers based on this black box approach.

The biometric performance is only one dimension of its security. A poor implementation of a product, even with great technology, can still leave an organization with unacceptable security risks. If you can find them, products with security certifications are best. Barring that, there should at least be reviews by industry analysts and respected publications. Fortunately, the industry has matured and a lot of hype has been replaced with scrutiny, allowing well-informed decisions to be made.

Technological advancements have dramatically changed the ability to successfully deploy fingerprint biometrics. Several years ago, fingerprint technology required host computer processing power along with a relatively expensive (around $100) peripheral to scan fingers. Not only does this imply touching all the desktops to install biometric software and device drivers, but there are serious security issues that are practically impossible to solve. Anytime a host computer is required to manipulate a biometric sample, you expose your authentication data to malicious code. Think of the threat like a Trojan virus that captures your password and has the additional severe consequence that you cannot change your biometric if it is compromised. Hostbased processing of biometric information is now a big security risk, since malicious code and cyber crime are undergoing explosive growth.

Today, fingerprint technology is packed into dedicated chips with inexpensive, high performance swipe sensors that can handle every part of the biometric processing (image capture, template creation, matching). This advancement has enabled the development of self-contained portable authentication devices that not only process the biometric in a secure environment (within the device) but also provide secure storage for fingerprint templates. While central fingerprint databases caused privacy concerns and were barriers to deployment, these issues no longer exist when biometric information never leaves the device.

Interoperability has taken a quantum leap, but surprisingly not from biometric standards. It used to be that applications needed to become biometrically aware in order to leverage the technology. This meant major software changes and to do it right, the industry needed standards so that the biometrically-
enabled applications could easily use different technology. Lots of effort has gone into biometric standards, but the uptake by applications has been very disappointing.

The irony is that applications are being augmented with biometric authentication without the need to
implement biometric standards. This is possible through other (non-biometric) standards that have been widely implemented throughout the industry; namely Microsoft CAPI and PKCS#11. These are cryptographic standards that allow hardware devices (tokens) to be used to enhance the security of crypto operations. The trick is that self-contained biometric authentication devices that also have cryptographic token functionality can be plugged into these interfaces and used as strong authentication tokens.

Applications get biometric authentication for free, without any additional complexity. This is really significant because we suddenly have many off-the-shelf applications: workstation logins, e-mail encryption, SSL Web authentication, enterprise single signon, etc., where biometrics can now be
used. By selecting the right biometric product, corporations can contemplate deploying biometric authentication across many applications that support the crypto standards.

Ultimately, it is the end-user that will either reject or accept the deployment of biometric technology. Here too there are big changes in usability, above-and-beyond the performance improvements of the technology. Portable biometric devices allow more mobility and convenience than ever before. The ability to go to any machine, plug-in the device and biometrically authenticate to a remote corporate server is a reality today. The fact that a multitude of applications are suddenly biometrically-enabled means that the user has a single, simplified experience. Whether it is digitally signing an e-mail, logging into a workstation, decrypting a file or launching a remote desktop, the authentication to each is the same for the user. When increased security actually becomes easier for a user, you have a winning situation for the user and the corporation.

In the case of fingerprint biometrics, the cost reduction, development of dedicated chips and the creation of fully-portable secure devices are technological advancements that have propelled biometrics to being deployable to the enterprise with huge gains in security, interoperability and usability. Fingerprint biometrics may have been the first, but may be not the last to undergo this transformation.

If you belong to a U.S. Federal Government organization looking to purchase a cryptographic product to protect sensitive data, then you are probably aware that you need to buy a product that is FIPS 140-x validated (currently FIPS 140-1, or FIPS 140-2, and soon FIPS 140-3). The FIPS validation process is long and expensive for many vendors trying to tap the government security market, especially when trying to achieve higher levels of validation. Knowing that customers often treat the FIPS requirement as a check box some vendors have taken the path of least resistance to achieve certification.

Before you make the impulse buy after seeing the word “FIPS” on the product literature you should do some basic due diligence on the products that you are considering. Some FIPS validated products may not be suitable for the type of security you need or cannot operate in a FIPS approved mode in the environments that you have. Worse yet, I have seen products that contain FIPS validated modules that are atrocious implementations of security.

Here’s a quote from the actual standard, FIPS PUB 140-2 advising users to be vigilant: “While the security requirements specified in this standard are intended to maintain the security provided by a cryptographic module, conformance to this standard is not sufficient to ensure that a particular module is secure. The operator of a cryptographic module is responsible for ensuring that the security provided by a module is sufficient and acceptable to the owner of the information that is being protected and that any residual risk is acknowledged and accepted.”

Don’t fret over this. There are some simple checks you can do to cover the basics.

The first check isn’t optional. You must verify that the product really is FIPS validated or at least contains a FIPS validated module. Sometimes you will see the word “FIPS” used in statements like, “FIPS compliant”, or “implements FIPS approved algorithms”, but these statements don’t mean validated. Validated modules must have a certificate. If it is not stated clearly in the claim then ask the vendor for the certificate number and go and find it on the NIST Computer Security Division web site http://csrc.nist.gov/groups/STM/cmvp/validation.html.

Once you pass that gate the next easy step is to look at the overall validation level. There are 4 levels of validation that cover a wide range of security requirements. Here is a summary of some of the key differences:

• Level 1: The lowest level – provides basic assurance that algorithms are correct – no physical security or authentication requirements – can be software only
• Level 2: Adds physical security with tamper evidence – at least role based operator authentication
• Level 3: Stronger physical security with tamper detection and response for covers and doors – identity based operator authentication
• Level 4: Strongest physical security with tamper detection and response for the entire enclosure

Without getting into gritty detail you should know is that there is a big difference between level 1 and level 2. Typically, level 1 validations are just software modules. There is no requirement for physical security and no requirement for any operator authentication which means you need to be very careful about where and how you deploy it. You need to have additional security controls in place that the level 1 module does not provide. On the other hand, level 2 includes physical protection and operator authentication and therefore can be used in higher risk environments.

Here’s an example with USB encrypted flash drives. Stealth MXP is FIPS 140-2 level 2 validated. Being a self-contained hardware module with built in user authentication you can use it anywhere knowing that a software attack is not going to compromise it. If instead you use a plain flash drive with level 1 validated software encryption, that software is exposed to whatever malicious code might be on the machine. Stealth MXP can be used in riskier, untrustworthy environments than the level 1 module with much more security for your data.

From here on, the checks get more complicated. Every validated module has a security policy published that tells you about the module and how it should be deployed to be in FIPS approved mode (if you are a die-hard, check out our security policy for Stealth MXP: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2007.htm#748). Security policies can tell you a lot about the implementation of a module, sometimes with surprising revelations.

Here’s an example that is pretty twisted. I came across a security policy for a level 1 module (that shall not be named) which consists of Microsoft Enhanced CSP (already validated – certificate #238) and another dll. This other dll contains a proprietary crypto algorithm. The only validated algorithms in this validated module are ones contained within the Microsoft component while the proprietary algorithm is not approved. So this module adds no apparent value for the government considering the Microsoft CSP is already present on your system. This was one of those “path of least resistance” implementations I was referring to earlier.

What is rather disturbing is that this module is included in another product and no one is likely aware that a non-approved algorithm is being used. Things get difficult is when products only contain a validated module but are not validated themselves. Since the product itself is not validated there is no public document like the Security Policy that clearly states what you need to know. It is up to you to do a considerable amount of due diligence to ensure that:

a) the product is utilizing the module correctly
b) the product is actually meeting the customer’s security requirements

So when you are in the market to buy a FIPS validated solution it is wise to do more than looking for “FIPS” as a check box item. The security of your information is at stake.

Here’s a good FAQ if you want to learn more: http://csrc.nist.gov/groups/STM/cmvp/faqs.html.

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.