• Reduced commuting times and costs
• Better balance of work and family
• Improved motivation
• Better employee retention
• Reduced office space costs
• Improved continuity of operations (during disasters, pandemics, relocation)
• Fuel savings and lower CO2 emissions
• Less traffic congestion and fewer automobile accidents

Boot-from-USB solutions are getting serious attention from organizations who are considering various teleworking technology options. Convenience, security, and further cost savings are envisioned as employees can use their home computers with a secure USB device rather than having to be issued a managed laptop. However, the type of boot-from-USB solution that is chosen can have a great impact on the productivity of the teleworker and hence the bottom line of the teleworking arrangement.

While the benefits for teleworking are significant there are also challenges that both the teleworker and the employer will face. When at home, the teleworker is going to be physically isolated from co-workers, and will need to rely on being digitally connected. This is a big impact on communication and directly affects the ability to convey ideas and interact with others. A study by the Journal of Applied Psychology (http://hartfordbusiness.com/news2961.html) also advises that the positive effects of social interaction are important factors for employee happiness, loyalty, and productivity.

I see the effects of good communication technology every day. My kids prefer to connect to their friends on video whenever they have the opportunity rather than using IM or email. At MXI Security, videoconferencing is a tool we use regularly to connect remote offices for meetings. It will be very important for effective teleworking to be able to interact with co-workers using all forms of collaboration technologies; web conferencing, video chats, shared desktops, etc. In addition to communication technologies, it is vital to have a good computing experience for the teleworker, meaning that he has access to as many applications as needed and that they perform well. The last thing you want to do is increase the frustration level of your isolated employee.

What does this have to do with boot-from-USB? My argument is that booting into a native OS (such as in Stealth ZONE Microsoft Windows Embedded Standard Edition) is a key technology for successful teleworking. Let’s take a look at why.

Boot-from-USB into a native OS (rather than a virtualized or remote access solution) offers direct access to the hardware resources of the host machine which has many positive implications. First, you will have access to the host machine sound and microphone so that teleconferencing is an option without relying on the availability or expense of the user’s home phone. You will have good native graphics performance. This means your employee won’t have to wait for the screen to scroll as he is browsing or working on documents. He will be able to use his applications at full resolution so he can view two documents at once instead of one. He will be able easily to use his graphics tools to sketch up ideas and share them. Applications will be able to use all of the available CPU power and memory which means more applications can be run and they will be faster (some heavy-duty applications won’t even install in a virtual environment). You will have access to web cameras and microphones so that employees can connect with others using videoconferencing. Finally, the ability to install and run applications locally is also very important for productivity. You do not want to rely on the employee’s home Internet provider to be always available for your employee to be able to work.

All of these elements add up to an optimal experience for the teleworker and ultimately contribute to the employee’s happiness, motivation, productivity, and your bottom line.

I can think of two common remote kill scenarios that organizations are interested in:
· Lost or stolen device
· Rogue employee

If a device goes missing, there is great peace of mind in knowing that the data on the device is completely inaccessible should it end up in the hands of anyone but the owner.  Remote kill would certainly ensure that this is the case.  However, strong authentication mechanisms and policies (password rules, retry limits, device blocking on too many bad attempts, etc.), and hardware based encryption, can achieve the same level of assurance that your data is safe and inaccessible without deploying remote kill.  That being said, if you hadn’t set up your authentication polices properly or your device security is not fully implemented in hardware then a remote kill feature would definitely be a good remedy in this situation.

The rogue employee scenario is where it starts getting a bit complicated.  To understand why, we need to look at how remote kill works for a USB device.  Making remote kill 100% effective over the Internet requires some kind of policy enforcement server to be involved in every attempt to access the device (by 100% effective I mean that when an administrator wants to kill a device, the policy takes effect immediately and kills the device the next time it is accessed).  The policy server would ideally take part in the authentication process and a user would not be able to access the device without the server also permitting it.  At this level of involvement the remote kill function can be a message from the policy server to execute a data destruct or block command on the device, instead of the usual authentication.

Unlike cell phones USB storage devices do not have an “always on” connection to some central location.  They are only Internet accessible if the machine that it is plugged into has a connection.  You could enforce a strict connection policy but it would mean that employees cannot access their removable storage in off-line environments like on a plane.  To address the need to have off-line access some remote kill implementations allow grace periods where you are allowed to access your device for a certain period of time or a certain number of times before you need to make a connection to the policy server.

The rogue employee scenario makes the policy decision rather difficult.  Say you want to terminate the employee.  You’d like to be able to disable all access to sensitive information immediately.  The employee, knowing that he is about to be terminated and knowing that there are grace periods, simply needs to disconnect from the network and copy all the data from his USB device in one session.  Unfortunately, in this situation, the grace period allows remote kill to be easily defeated just when you need it the most.

There are options that help mitigate the risks while providing more off-line flexibility.  For example you may allow grace periods for frequent travelers but not for other employees.  Alternatively, grace periods could be disabled for office employees or teleworkers because network connectivity is required for productivity anyway.  You might only allow removable storage devices to be used on managed machines even when they are off-line (McAfee ePO has this capability with MXI Security USB devices).  This approach works if you have also implemented good data leakage prevention on the corporate machines. 
 
You can’t get away from the fact that there are always risk/cost/productivity tradeoffs when it comes to security policies and remote kill is no exception.  If you are looking at remote kill for USB devices, be aware of the limitations and think about whether the available policies are going to suit your security needs.
 

• Knowledge (passwords, PINs, etc.)
• Possession (driver’s license, token, corporate badge, etc.)
• Being (biometric: face, finger, voice, retina, etc.)

You will likely come across conflicting opinions of whether one factor is better than another. For example some people might consider passwords better than biometrics while others will argue the opposite. But who is correct? Is there one factor that is better than all of the others?

The answer is that it really depends on what criteria you are using to measure the authentication mechanism against, and there are many dimensions to consider. For example you could compare biometrics and passwords with respect to accuracy, convenience, ability to share, presence of a live person, usability, susceptibility to replay attacks, and so on. Your choice of what is important will determine which single factor is better than another. Worse still, there can be variations even within a particular factor type. The following diagram illustrates this point.

In the plot above I have chosen convenience and accuracy as measures. You can see immediately that a complex password, say “%SPc_87snwi$”, is more accurate (harder to guess) than a simple password, like “Hello” but you pay the price in convenience. Similar trade-offs occur in biometric technologies. A retina scan is considered to be more accurate than voice recognition but you have to shine a light at the back of your eyeball to provide a sample which is quite a bit more invasive than speaking into a microphone. A DNA sample (using enough markers) is in theory orders of magnitude more accurate but you might have to wait a few days for the results, which I consider a huge inconvenience when logging into your workstation.

With only two measures; accuracy and convenience, there are valid arguments for favoring either factor over the other. Imagine the difficulty in deciding which mechanism is better when you consider a dozen of more different threats.

One thing to realize is that there are advantages and disadvantages among each factor of authentication. No single factor of authentication is perfect. What is interesting is that biometrics and passwords have some very complimentary properties. That is, a weakness in one factor can actually be a strength of the other. This is what makes multi-factor authentication so compelling for security because the effect of combining them creates something much stronger than either factor on its own could possibly attain.

To illustrate this I have chosen a handful of security threats and highlighted the weaknesses and strengths of biometric, password and both combined. A red brick indicates that the method is vulnerable to the corresponding threat and a green brick means it is not.

I have deliberately selected software-based password authentication and a hardware-based (fingerprint) biometric as my two factors in order to more acutely demonstrate their complementary nature with respect to the list of threats. You can see that when they are combined, the resulting two-factor authentication is resistant to all of the listed threats.

If strong authentication is critically important to you I highly recommend multi-factor authentication because it is without a doubt, the best authentication security you can get.

Let’s start with the very basics.  User authentication is the front line of security.  If authentication is weak, it doesn’t matter how strong your encryption is, or how impenetrable the hardware is that protects the encryption key.  If there is no authentication, there may as well be no encryption at all.  Authentication is the “key to the key” so to speak.

Since the authentication process itself manipulates sensitive information, such as passwords and biometric templates, it only makes sense that it occur in a trustworthy environment.  Even strong, multi-factor authentication becomes weakened and even defeated if the user’s credential information is compromised.  Your managed corporate desktop should be a trustworthy environment.  This is why entering a password to login to your domain normally isn’t a problem.  However the situation is drastically different for a secure flash drive.  Being a portable device, it can be exposed to many untrustworthy environments where malicious software may be capturing keystrokes or passwords in memory. 

The best place for the authentication to occur in such a device is within the hardware.  Of course the more secure the hardware the better.  Some people are suggesting that the FIPS certification is meaningless given that the recent security flaw is associated with FIPS validated devices.   There is nothing wrong with the FIPS process but it must be understood that it only deals with what happens inside the cryptographic boundary and there is much more to consider when looking at overall security (see this blog entry for some more insight http://www.mxisecurity.com/blog/cto/2008/07/14/fips-validated-is-more-than-a-check-box/).

At MXI Security we strive to deliver the best authentication technology in the industry.  Our portable devices are capable of password, biometric, and multi-authentication, all within the secure hardware environment of the device.  You can take these devices anywhere but you will still need to be aware that key loggers can still be a threat as password entry is done from a keyboard.  It’s good practice to change your password to mitigate the efficacy of such attacks (we provide password rules to let you enforce such things as regular changes and password reuse).

Since biometric authentication is done completely on the device it is immune even from key loggers.  For those that want the strongest authentication possible, biometric and password authentication can be combined (2-factor) so that even a compromised password isn’t enough to break in.

If you are interested I have other blogs entries on authentication (see http://www.mxisecurity.com/blog/cto/2008/07/10/is-it-two-factor-or-three-factor-authentication/ and http://www.mxisecurity.com/blog/cto/2008/06/03/beware-of-biometric-images/).

Have you ever wondered what kind of damage an attacker could do if they have your web credentials?  Here are some questions to consider if you care to measure your exposure.  How many web site logins do you have?  How strong are your passwords?  How many times do you reuse the same password for different sites?  Do you ever use the same password that you use as your login at work?  How many sites do you have accounts on that you can no longer remember?  Do you find yourself storing lists of user IDs and passwords so you can keep track of them?

We are taught by security professionals (and maybe common sense) that your passwords should be different for each web site, they should be complex, and you shouldn’t store them or write them down.  Obviously this isn’t practical and the problem has been recognized by the industry which has responded with new web identity paradigms such as OpenID, and InfoCard (a.k.a. CardSpace in Microsoft). 

These initiatives may take years to become widely adopted so what can we do in the meantime?  IE and Firefox offer one solution via password managers that they build into the browser.  They will remember your login credentials and automatically fill them into forms as required.   I don’t use these because I don’t trust having password vaults sitting on my machine where they are easily accessible and are ripe targets for attack (see http://www.securityfocus.com/infocus/1882 for a nice survey of password manager risks).

I have a wish.  Instead of passwords I’d like to use certificates to authenticate to all of these web sites that use self-managed credentials (i.e. the ones that let me pick my own user ID and password).  I’m not suggesting that we force everyone to use a certificate.  But if you have one, why not give you the choice?  My reasons are the following:

1) Security
2) Convenience
3) It should be easy to enable…

You’re probably thinking that I’ve gone off the deep end, especially on that last point, but hear me out.  From an identity theft perspective you can’t beat certificate authentication since there is nothing exchanged in an authentication transaction for an attacker to steal.  So right away we’ve eliminated the password problem.

I happen to carry a portable PKI token around with me all the time.  It’s built into my Stealth MXP Portable Security device.  I can easily go to VeriSign, and for a small fee, obtain a digital ID (a PKI certificate) that I can install on my device and use within IE or a portable version of Firefox which happens to be installed on my device.  The whole setup is very convenient for me (I also use a finger swipe biometric instead of a password to unlock my device) but the real bonus is the security.  My private key is generated in FIPS validated hardware, it cannot be exported, and it is protected with strong authentication.  Absolutely no one is going to be able to access this private key without my willing participation.  So I have everything I need to make my web transactions secure and convenient.

This brings us to the third point.  My argument here is that the plumbing to make this grand scheme all happen is already in place and is just waiting to be turned on.  Certificates for client side SSL authentication are supported in all major browsers and enabling client side SSL authentication in the majority of deployed web servers (Apache and Microsoft) is as easy as a setting a check box.  I know that this perspective seems a bit naïve but we are talking about unmanaged credentials. This means that service providers don’t need to change very much.  They only need to associate your digital ID that you present (and prove that you own the private key) with your account and trust the authority that issued you the certificate.  I don’t see much of a difference from their current sign up process where you create your own ID and password.  Yes, I’m ignoring details like revocation lists and exceptions (how to handle my lost device, etc) but you get the idea.

If this were in place then I’d be very happy.  I could focus my worries instead on choosing a certificate authority that had a good identity proofing process to ensure that imposters cannot apply for digital IDs in my name.  I’d also be careful not to register to a Phishing site that might want to gather other personal information.

Sadly, this wish will probably never happen.  In the meantime, I don’t want to be a sitting duck while I wait for the next web Identity Metasystem to become adopted.  I’m willing to compromise.  Instead, I’ll wish for a portable password manager that uses my MXP device to carry and secure (and possibly generate) my web passwords.  At the very least, it gives me the equivalent of two-factor authentication (ownership of the device and authentication to it), portability, and it provides strong protection for my sensitive login information.  It’s a compromise but I’m confident that this wish can happen and I’m looking forward to reducing my web anxiety.

I wrote a little crypto application that encrypts and decrypts graphical images.  The encryption algorithm (call it algorithm X) is “home-grown” and was designed to be visually appealing rather than secure.  I will use it to illustrate some weaknesses in its encryption and to highlight a couple of essential properties of a good crypto algorithm.

Algorithm X is a simple permutation of pixels in the image.  Each iteration or frame will permute the pixels a bit more.  The permutation rule is designed so that the pixels appear to move and collide with each other like billiard balls, which is what makes it visually appealing.  After many rounds the image becomes more scrambled and at some point you could say it is “encrypted”.  Simply running the rule in reverse decrypts the image.  The following shows the input and resulting images produced by running algorithm X and AES.

Figure 1: Input Image

Figure 2: Encrypted with Algorithm X

Figure 3: Encrypted with AES

With algorithm X you can still see some of the original information.  For example, you may notice that the color information has not changed and that the pixels are merely scrambled.  You can also still see some clustering of pixels around where the flag and FIPS logo were originally.  This is because the permutations are very local and it takes many “rounds” (frames) for the pixels to become dissipated.  AES does a much better job at diffusing the information very quickly and using the entire range of colors uniformly so there is no discernable pattern relating to the input.  In fact randomness of the output of an algorithm was one of the criteria used by NIST when selecting the AES algorithm.

That being said I could conceivably modify algorithm X to produce similar looking images to the AES version but that is no indication of security.  Looks are only skin deep and the real security of an algorithm is also determined by other factors such as the soundness of the mathematical implementation, and its resistance to cryptanalysis.  Even so, public algorithms also spend years of being in the public domain where they should survive the test of time.

But once again, Algorithm X was designed to be entertaining not secure, which brings us to the fun part of the discussion.  If you download the application (download link) you can try the encryption and decryption of the sample above.

Challenge:
In the Visual Crypto application there is a secret image that has been password protected.  To decrypt the message you will need the correct password.  Using the clues below you can construct the password (Tip: search our recent press releases and device literature on our web site for answers).

Clues:
1. The password is thirteen characters (all upper case)
2. The name of the security evaluation for the UK Government that the Stealth M550 is undergoing: (4)
3. Acronyms of the U.S. Government smart cards that can be used as authentication factors for MXI Security devices: (3 + 3)
4. Family of devices that combine secure storage, strong authentication, digital identity services, and management functions?  (3)

The idea is that you no longer need “your” laptop to be productive when you are away from the office.  You just need “a” machine as long as it has an accessible USB port for you to plug your device into.  Either by rebooting the machine or running within a virtual machine, or an abstracted operating system, you have access to your full corporate desktop and operating environment “running from the stick”.  To be clear the OS does not actually run within the stick but uses the CPU of the host machine.  The trick is that nothing gets (or should get) installed on the host and ideally, no trace of the portable desktop remains once the device is removed.  In effect the machine becomes a monitor, keyboard and mouse while your USB device becomes the “C” drive. 

The concept of portable computing has been around for some time.  There’s been remote computing where you need to connect to a server to access your desktop, and we’ve had portable applications which may give you some productivity but needs to run within a non-trusted OS.  The large memory capacities that are now available in flash drive form factors are making it feasible to carry full blown operating systems such as Windows on a stick.

I can imagine a utopian world of portable desktops where there are public machines sprinkled around airports and coffee shops like wireless access points.  People could use them with their own computing environments that they carry on flash drives - no need to carry a laptop anymore.  Perhaps this may never happen but in the corporate environment the scenario could be very real.  The IT department would manage desktops on USB sticks instead of managing the machines.  Not only that, but employees could also work from home using their own computers. 

With the right portable desktop implementation even that uncontrolled, malware infected machine that the kids use to play video games could be used and the IT department wouldn’t care.  It is easiest to understand how this is possible by looking at a “boot from USB” portable desktop as an example.  When you reboot the machine from USB you take full control since the hard disk of the host machine isn’t even used.  Provided the portable desktops are fully managed, the organization still has full control over the employee’s computing environment.

If you are seriously contemplating deploying portable desktops here is a list of essential security requirements to look for in a solution:

• The USB devices are fully managed
• No trace of information is left on the host.
• No data can leak from the portable desktop to the host machine.
• No malicious code residing on the host machine can access the portable desktop
• The desktop is fully encrypted (or at least the sensitive parts)
• Strong user authentication is required to access the encrypted desktop
• The desktop is not accessible unless it is actually running. 

That last point is worth an interesting final note.  It implies that you should not be able to see or manipulate the desktop data just by plugging the USB device into a machine (even after authenticating to the device).  Otherwise you would have an exposure to corporate data leaking from the desktop or malicious code infecting the desktop in an uncontrolled environment.  Think of it behaving like an internal hard disk of a PC when it is turned off.  This is contrary to a flash drive’s normal operation, which is to allow data to be transferred on and off.  It looks like a flash drive, but it’s not acting like one…

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.

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.

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.