Unfortunately there’s no information about hash algorithms, or salt mechanisms.

This post outlines why and how travelers with laptops, especially business travelers, are put at risk by border police searches of their computers.

I also attempt to present some techniques as to how this risk can be avoided, or at least mitigated.

Thus Far

The United States Transportation Security Agency, and the United Kingdom’s Regulation of Investigatory Powers Act (RIPA) have one thing in common — they expose travelers carrying sensitive information to risk.  A few relevant links on the subject:

Security researcher Moxie Marlinspike profiled and detained, equipment confiscated (later returned)

Wikileaks volunteer and developer David Appelbaum detained, equipment confiscated (some of it returned)

ACLU mounts lawsuit against baseless border laptop searches (a warrant is required since 2009)

UK man jailed under RIPA for refusing to hand over encryption keys to laptop

The USA and UK are by far not the only countries where user laptop or portable device data is put in danger.  In other nations, individuals may encounter draconian police laws (e.g. in totalitarian states) or corruption, and some other developed, stable, democratic countries occasionally make legal provision for confiscation of devices or investigation of data.  For example, in 2006, Brazilian federal police raided the offices of Credit Suisse, as well as the homes of several senior bankers.  What kind of access this gave them to business-critical data is open to speculation.

A Hypothetical Situation At the Border

The scenario that most concerns us is as thus:

A user (let’s say a busy manager) boards a flight.  He is on a way to a business meeting, to negotiate a merger.  On the flight, he relaxes and opens his laptop to get a bit of work done, editing his presentation for the first meeting, then becoming a bit distracted and looking over pictures of his little daughter playing in a kiddie pool.  The manager is annoyed at his chatty neighbor trying to crane his neck to get a look at his monitor, but his privacy screen blocks prying eyes.  30 minutes before landing, he closes his laptop lid and opens a paperback.

Upon entering customs, an official looks at his passport and picks up the phone.  He mumbles something about “additional screening”.  Two uniformed officers appear and very politely ask the confused executive to please follow them.  He is escorted to a windowless room, whose walls are lined with posters extolling the mission and professionalism of the bordeabr patrol, and warning against importation of illegal substances.  The manager is asked about his identity, and prompted to empty his pockets and open his bag on a table; while an inspector rifles efficiently through his carry-on, a second official looks on.  The manager’s questions and protestations are met with bland reassurances about “standard protocol”.

The first inspector finds the laptop, and walks out the door with it.  As the manager moves to stop him, the second inspector scowls and blocks his way.  Within a minute, two more officials enter, and begin talking about a suspicion of child pornography, and what serious consequences it harbors.  They mention that a fellow passenger reported having seen “suspicious” images on the laptop, and “encourage” the manager to cooperate, bringing up vague hints of terrible punishments, no-fly lists, and harassment.  He is presented with a form and a pen, and asked to write down his laptop screen lock password.   The manager looks at his watch — he has not slept much and needs a shave; his limousine charter has probably left by now.  His requests to make a phone call are politely but firmly denied.

Periodically, someone re-enters the room to ask about another password to an application (email, etc.)  An investigator inquires as to the password of his PGP-encrypted virtual disk.  The man’s protests are met with stern reminders that he must cooperate.  The executive has heard that it might be a good idea to have a lawyer in this country, but as a foreigner, he does not know how to go about it, and must be present at his meeting tomorrow.  In any case, he could not contact an attorney.  He does not think of asking to leave.  After four hours of this, punctuated by short interviews asking him to clarify, his laptop and phone are returned to him and he is allowed to leave.

What now?

Do we know that the data was removed upon failure to show any child pornography, incitement to money laundering, or terrorist literature (insofar as any of the above are not protected by free speech anyway)?  When the above user is the CEO of a multibillion dollar corporation, or his fully authorized deputy, are we sure that no information was passed on to a national champion or other competing firm?

Ideological Disclaimer

However, the United States and UK are the two largest, most economically significant liberal democracies to give their police and border protection enough leeway in terms of data interception and confiscation to constitute a real danger to anyone carrying sensitive data (or just those who feel that what’s on their laptop is nobody’s business; whether those contents are legal or not is beyond the scope of this article.)

Full disclosure:  I am vehemently against search and seizure laws that do not require a warrant.  I oppose border inspections of personal digital data unless they are extremely tightly controlled, as I believe laptops are very personal items.  It is my opinion that law enforcement (particularly border control) authorities should be held to a very high standard, so they can be trusted to maintain the high professional standards they claim to adhere to, to safeguard data and privacy, and to consistently respect rules of evidence.  Nonetheless, I suspect that border patrol and law enforcement agencies in much of the world have at least at some point acted as agents of industrial espionage.  I have strong ideological convictions in this regard, and do not hide these.

My objections are not so much addressed at places like China or Saudi Arabia, which openly engage in totalitarian, intrusive aspects of data analysis and censorship (and possibly theft), or Venezuela or Indonesia, where corruption and arbitrary measures can be expected.  You know what expects you when you visit an authoritarian or corrupt country.

These are my personal opinions.  I will be happy to provide my reasoning elsewhere.  This post, however, is no more than a discussion of technical and procedural controls that allow individuals and companies to reduce their exposure from mobile device seizure and data analysis.  For the purposes of those who claim that “those who have nothing to hide won’t mind security measures”, I say that

1. no security is engendered by this.  It is nonsense “risk management” or investigatory technique
2. it sets a very dangerous precedent in any society making even a small pretense as to individual liberty and freedom from arbitrary search and seizure, and questions the idea of the fundamental human right to travel
3. it puts a burden on host countries, insofar as illusory, ineffective, intrusive security mechanisms discourage travelers from visiting and bringing money and business, and
4. from now on, you will leave the door to your toilet open every time you go to take a dump

For the purposes of this article, we do not care what kind of data you have.  We will assume that you want to protect it, and that users are sort-of-but-not-highly technically versed.  Furthermore, I cannot address mobile phones, embedded tablet PCs (iPads e.g.) or PDAs, because I am unfamiliar with security mechanisms supported by various operating systems (IOS, Android, BlackBerry OS), so we’ll focus on generic mechanisms for laptop operating systems, with a few concrete examples.

Hardware Exploits, Rootkits, and Keyloggers

First of all, the as soon as someone has unsupervised physical access to your device, it is possible to implant keylogging hardware.  Although the supposed Dell laptop keystroke logger was a hoax, small hardware keyloggers are a fairly mature technology.  Interrupt detection won’t work, as the keylogger isn’t being installed stealthily (remember, the device is out of your possession / sight, and no attempt at stealth is being made.  If it’s rebooted, it’s rebooted.)  We assume the device is being carried, rather than checked in luggage, a stupid thing to do in any case — as such, the whole problem with border patrol or police temporary confiscation of laptops is that it is done in the open.

Even without manipulation of hardware, the hypervisor rootkit model presented by Joanna Rutkowska (“Blue Pill” — more here) would allow persistent access to even an otherwise “secure” laptop operating system, with full bypass of its security capabilities (e.g. by intercepting monitor signals or keystrokes).  I am unfamiliar with any functioning examples of such an exploit, but that does not make the concept any less valid or dangerous, or mean that it does not exist.

If there is any suspicion of the above, there’s not much point to reading the rest of this article.  The instant that something leaves your possession and sight, it can be assumed compromised.  The only mitigating factors are

• hardware keyloggers cost money.  You may not be worthwhile (does not necessarily apply to, say, a senior executive)
• installation takes at least a bit of time.  I do not know whether a rootkit could be slipped onto a drive without imaging the entire system
• there is a tiny risk of detection if done inexpertly — if you are ultra-paranoid and have opened up your device, noting down component serial numbers, you may be able to detect new hardware
• certain types of hardware require user interaction to get around drive-level encryption; cracking these is not feasible in a short period of time.  Then again, someone may just demand a user’s boot password under threat of prosecution or harassment, and walk off with it.
• hardware keyloggers that are hard to detect must be prepared.  An investigator would have trouble having clandestine-ready hardware for any given laptop model ready.

A software keylogger or spyware program / trojan can equally be installed, but a number of methods exist for detecting these with a reasonable degree of reliability, including virus scanners, and cryptographic checksums that can be compared with a central server, e.g. some equivalent of Tripwire or another host-based intrusion detection system (HIDS).

Most importantly, though, the moment something like a keylogger or other hardware exploit is on your laptop, it does not matter what other security measures you take.  Someone will always have access to your laptop from now on.

If the above applies, there is not much point to reading the rest of this article — it is the equivalent of telling a friend a Gmail password, then changing it — while he is watching.  The only ways to deal with this are

• buy a new laptop
• assume that all communications are bugged, all files can be intercepted / opened, and only work with data that does not matter

Data Dumps and Stuff

Be hind the scenes of the fictitious episode above, a forensic investigator took a full image of the user’s laptop.  There was no effort made to hide what was going on, nobody told him about his rights concerning search and seizure, habeas corpus and illegal detention, customs regulation, court and government rulings regarding data investigation, etc.  He was simply coerced into providing access to his information.  All attempts to encrypt, or hide, data on his laptop, and all mechanisms to foil intruders, came to naught.  The government in question, regardless of the (il)legality of its customs agents’ actions, now has a full dump of the user’s laptop, which may or may not include saved passwords for his webmail account, confidential company materials, a (weakly) password-protected Excel list of passwords, personal photographs, contacts, etc.

I’ll leave it to the imagination of the reader why this might be a bad thing.

If you maintain constant visual contact with a confiscated laptop, and can determine, with 100% assurance, that nobody has managed to slip something dodgy on to it, great.

However, the best way to secure yourself against compromise is to assume that any data on a laptop is forfeit and to avoid having any information on the laptop to start out with.  Remember — even if nobody installs anything, it’s pretty easy and quick to just dump a full storage device and play around with its contents later.

User Education

No amount of confidential information is worth the life, safety, or freedom of the person holding it (aside from exceptional situations — we’ll assume there’s not much wartime spying going on here.)

It is the responsibility of an employer to teach any business traveler two things:

1. Cooperate with authorities — regardless of what the situation is, nobody on the road for work should have to be a hero
2. Understand basic data protection techniques, including taking due care with creation of information so nothing described in this article actually becomes an issue

The point of all this is to avoid having to not cooperate or having to worry about data while on the road.

First Baby Steps

A few simple things might provide some degree of protection, but not a whole lot.

Set up a dummy account.  Keep it logged in.  Ensure that your login window does not show a list of users, but rather a username/password field, e.g. not this

but rather this:

When prompted to log in, do so with the dummy account.

Note that this will only fool idiots.

One-Way Encryption

A user cannot give up a key that he does not have.  Bruce Schneier wrote about this idea — allow a user to encrypt his laptop / files with a random key at some point before he is at risk of having his laptop accessed at the border.  Give someone else the password.  After passing the border, call this person to retrieve the password.

The downside to this is that, under something like RIPA, a user may face legal consequences for having encrypted material in his possession for which he cannot / will not provide the password.  The law puts the onus on the holder of the data.

Furthermore, this may expose the person carrying the information to harassment and difficulty entering the country.

External Media

A 64-GB thumbdrive, or a DVD containing personal/confidential data, could be hidden somewhere in a user’s luggage, or mailed out of band (e.g. FedEx).  However, that carries with it risk of interception.  If it is found on a user’s person or baggage, the user can also be coerced into giving up an access code.  If it is mailed separately, it may be very difficult to crack (e.g. PGPDisk) but there is still the risk that the wrong persons get their hands on it.

Pre-Trip Backups

All data on a user’s laptop should be backed up before he leaves.  This can take the form of incremental backups, or a full disk imaging.  This is useful in case a full restore from scratch to a new laptop is necessary.

All users should be storing their important work data on a network drive anyway, see a little further down as to why.

Remote / Travel Laptop Builds

A properly paranoid company will make a travel build available for its international travelers.  This is a stripped down OS configuration, containing as few hints as possible as to the nature of the company and its business.

It makes sense to do this anyway to avoid loss of confidentiality from lost/stolen laptops.  Make sure that someone on the road only has what they absolutely need on their laptop.  It’s understandable that someone wants to work on a presentation or document on the plane, but in this case, it is important to educate users about the need to only carry the data that is absolutely necessary for the current trip.

Unfortunately, that covers locally archived emails, and breaks down on trips involving multiple clients.  Furthermore, if the files a user is working on, say, during a flight on in a departure lounge, are actually highly confidential (e.g. the example of the merger negotiation)

Boy, the consultants will scream about this one.

Virtualization

Use virtual machines, such as VirtualBox, or VMWare.  At the very least, this allows reasonably quick restore of compromised working environments, and can be used to restrict access to a host OS by dodgy websites.  No particular benefit to travelers, except to add another layer of obfuscation — it is conceivable that an encrypted VM could be used for something like the “One-Way Encryption” environment above, completely masking what files / applications / sites are used.

Secure Remote Desktop

Most mobile users have access to remote working tools via VPN.

I once completed an architecture project that provided a Citrix environment over an IPSEC VPN to users.  A limited desktop, located on a hardened server in a DMZ, was presented to users.  Someone connecting remotely had access to their data, could work remotely, and download folders and individual files.

These could be the files that were backed up / copied to the network drive earlier.

Webmail interfaces (SSL-protected, via IPSEC) allow users to get around having to keep mail archives on laptops — unfortunately, most companies do not understand the concept of sufficiently large server mail quotas.  Disk is cheap.  Buy some.

Data Segmentation

For added peace of mind, users traveling to a country whose border patrol or police are known as a source of risk should be limited, via profile, to a subset of data on the remote desktop server.  Allow users to copy their files by project — and specify, either via user interaction, or via centralized management, which elements they have access to.

Most consulting firms already have “Chinese Walls” in place in order to prevent conflicts of interest, i.e. sanitizing one client’s data before using it with another so as to avoid exposing trade secrets.  The user mentality is thus already in place.

Access Logging and Monitoring

Companies should ensure strict logging of all access events, as well as all user activity.  Companies should maintain access profiles and correlate user activity with what is expected — a sudden attempt to dump entire file trees via remote access may be cause for alarm.

This ensures that, in case of a break-in by a foreign law enforcement agency using stolen credentials, it’s clear what was compromised.  This is good practice in any case; in the Brazilian example earlier, police had presumably unfettered access to a major corporation’s international network — many major global companies have some sort of poor segmentation between country networks.  Imagine the amount of scrambling and incident response work required to find out exactly what information they were able to obtain?  A single user is no different, if you don’t know that he has been forced to divulge access, or if your external VPN connectivity uses weak authentication and credentials are extracted from a copied laptop drive.

Two-Factor Authentication

Require users to use two-factor auth (e.g. RSA SecurID cards, chip cards, etc.) — this reduces risk from exposure of saved passwords or persistent authentication cookies dumped from a laptop.

Duress Passwords

In the extreme case that a user is forced to log into a corporate network via remote access, he should be given a a “panic account“.

This could take the form of “salomon.john” as opposed to “john.salomon”.  Keep passwords the same to keep things simple – complexity causes people to become nervous and give things away.  This account could even have access to the same dataset as the “real” account, while setting off all kinds of alerts and informing administrators that shenanigans are in progress.

User training is a strong prerequisite to make this work.

Remote Data Wipe

Many laptops have a SIM card slot.  In the case of the Apple iPad 3G, one of the few reasonable security measures is the central remote wipe capability.  Use it.  Whether as part of a duress code mechanism, or in case of unexpected activity, it may be wise to err on the side of caution and just nuke anything via remote management.

Third-Party VPN Termination

This is an extreme solution to what is, at best, a paranoid situation, but it might be interesting for companies to set up VPN connections to trusted intermediaries located offsite.

This is a bit of a separate issue, but a user connecting to an IPSEC concentrator with an IP registered to a given Swiss bank may raise the curiosity of law enforcement agencies who like to know, out of principle, what a Swiss bank executive is doing in their country — thus giving cause for additional searches the next time the user passes through a choke point like an airport.  Connections to an innocuous IP, however, may avoid such attention.

If the intermediary is trusted, a separate IPSEC connection can then be established from his servers to the corporate DMZ.

Conclusions

Controls of user laptops need not follow rational justifications — even developed countries have shown that their police and border investigations can be arbitrary.  While it is unlikely that a given traveler’s laptop may be investigated in depth, if it happens to you, the probability of it becomes academic.

No company should ever expose its mobile users to danger through their mobile data.  However, there are sensible ways to limit the potential fallout from unauthorized exposure by foreign law enforcement agencies to data that is simply none of their business.  It just takes a bit of investment and willingness to change mobile working habits.

Partially this stems from the desire to apply financial metrics to risk and security, partially from the need of managers lacking a strong technical background or the ability to acquire this to have easy-to-understand, purely numerical descriptions and graphs of where their money is going.

One of my colleagues recently came up with the concept of an abstract measure of security investment (time, effort, grief, etc.) — the securitron.  As in (hold hands zombie-like out front and repeat in a robot manager voice), “we’re going to need more securitrons!  Throw two hundred additional securitrons at this project!”

For some reason, this came up again during a meeting to discuss increased efficiency of risk management paperwork.  The upshot of this meeting, as with pretty much any business meeting consisting of over three people (and not taking place by the coffee machines, where most productive work gets done), was (a) use your own damn judgment, that’ s what you’re paid for, these are only suggestions, (b) if you still have questions, ask your colleagues, that’s why we sit together, and (c) when will this damn meeting end?

However, an interesting point did arise — the idea that security, risk management, and compliance work tends to end up with reams of paper that may or may not ever be read.  This was the case with all medical regulatory and compliance work I’ve ever done, as well as with pretty much every experience I’ve had in financial services since 2000.

The conclusion?  My personal view is that documentation and paperwork does not make much sense unless it’s in an easily accessible format (e.g. a well-organized database schema accessible by very flexible views to whomever wants to use and evaluate the data.)

Another very important point that my colleague raised, though, was the concept of the “thunk test” — i.e. if a security policy is dropped on a desk and makes a “thunk”, it’s too big to be of any use.  Nothing that heavy can possibly have the elegance and simplicity to be easily enough understood for practical everyday application.  At the risk of advocating the development of tired business doublespeak, I could see a use for a plainly worded non-mealy-mouthed type of goals and rules statement (“don’t leave passwords lying around.  Never talk to strangers.  Don’t pet strange dogs”) for security organizations that actually fits on a single piece of A4 paper (or at least in a document that makes no more than a soft whisper as it’s dropped.)

Now, we are working on finding a good name for a measure of the quantitative relationship between securitrons and reams of paper.

“As a general view, they have excellent memory and strong attention to detail. They are persistent and good at following structures and routines”

So, I got to thinking; one of the discussions I had with colleagues following a recent meeting with a provider of managed security services (see previous post) dealt with the idea that building and maintaining a decent SOC and log/event management procedure is a near-impossible task, due to the difficulty of creating a sustainable operations process; one of my co-workers made the point that most people would tend to get bored with the repetitive nature of looking through logfiles, or even dealing with things like security advisories and updates.

I countered with the assertion that your basic event management and intelligence correlation should, to a large degree, be automated anyway (whether non-dedicated companies can do this as well as, or better than, dedicated outsourcers is a separate discussion that’s probably best investigated on a case-by-case basis.)  However, the routine nature of any IT operations-type job aside, he did have a point that (a) even when you do automate everything, you’ll still want a degree of human second-guessing, and (b) that gets mighty dull.

It seems like a logical conclusion that if Thorkil Sonne is right, and autists (is that a word?) can really be excellent at work that requires focus, consistent attention to detail despite the drudgery involved, and clear rules, why not use these guys for exactly the tasks described above?  Someone who is excellent at pattern detection, and is willing to follow the same process day after day after day would seem to be ideal for an SOC monitoring / log & event analysis position.

I don’t want to come across as somehow insensitive, since I know next to nothing about autism, but purely going by the value proposition put forward by Specialisterne, it seems like a rational conclusion to hire the best people for any given job — whether or not the fact that they are qualified at what they do stems from extraordinary dedication, experience, or a mental condition should be completely irrelevant.  And in the process, maybe do some good for someone who might be difficult to employ otherwise.

]]> http://www.chakraborty.ch/best-practices/autistic-security-event-monitoring/feed/ 1 http://www.chakraborty.ch/development/modularizing-security-functionalities/ http://www.chakraborty.ch/development/modularizing-security-functionalities/#comments Fri, 27 Mar 2009 12:27:23 +0000 john http://www.chakraborty.ch/blog/?p=77 Okay, I made up “modularizing”, but I think it nicely fits the idea of this article.

I am a huge fan of the concept of abstracting functions — i.e. clearly defining what it is you are trying to accomplish with your various bits of software & hardware, defining clear categories for their functionalities, separating them, either physically or logically, and ensuring that everything communicates via clearly defined, standards-compliant interfaces and APIs.

During several early projects of mine, I noticed that the temptation was strong for managers to create all-in-one tools in order to sell the widest package of application functionality conceivable.  This is bad design, if only because different uses and scenarios can have different requirements; addressing these may have unintended network effects on other components of a product, thereby slowing down the whole analysis, development and QA process.

One of my clients has taken the path of a pluggable, modular configuration tool for some of their systems; this is a good model insofar as it allows clear access to different components from a single interface, but the components themselves are not interdependent.

For the purposes of this article, I’d consider using very basic distinguishing criteria like “network / communications device”, “end-user application”, “remote support tool”, whatnot — and in the scope of this article, “security device” and “other.”  I realize that these are fairly theoretical, academic distinctions, but it’s my firm belief that the idea applies in real life. Such a matrix can be multidimensional — criteria could include, on the one hand, what the application is used for, and on the other, how it is deployed or managed, OS type, manufacturer, etc.

For example, one of my projects involved the development of a small network security appliance for a specialized scenario (protecting proprietary devices subject to strong regulatory requirements.)  There was constant pressure from sales & marketing to avoid having multiple physical boxes; the field service types also wanted to prevent having to maintain additional distinct hardware.  This was a good example of when it was right to not listen to our customer and push them to accept the idea of having another little small piece of hardware; integrating the security into pre-existing products would have required a huge amount of adaptation, porting, maintenance, testing and other effort, over multiple architectures, teams, countries, whatnot.

“Security” is a compelling argument for the separation of protective functions from what’s being guarded; there may not be a clear, identifiable exploit that you are addressing, but, using the example of network defense, knowing that your authentication, detection, encryption and filtering tools are autonomous from each other reduces the possibility of single points of failure.  I’m not arguing for an eggshell model of security (crunchy on the outside, squishy on the inside), but it makes things much easier to be able to address an application server’s security requirements without the need to assume that whatever security you implement on an application level is all you will have.

An even more significant reason to keep things separate (physically, via dedicated, standards-compliant hardware, or virtually, via VMs) is cost reduction — support and development are simplified.  Despite the appearance of increased complexity from more components, if you are able to quickly and easily swap out a defective element, or create added functionality whose impact on an unrelated system is controlled through a standardized network interface or code API, you no longer have to worry about breaking things that should be out of scope for whatever it is you’re doing at the moment.

Don’t get me wrong, aside from the bloat I love FF.  It’s like Apache — it’s a resource hog, but it does what you want nicely, and it’s kind of like a pair of old underpants that you can’t quite bear to throw away.  But this one particular bit of chicanery just stinks.

In case you forgot, when faced with a certificate signed by a CA whose root certificate is not in FF’s certificate store, you receive an obnoxious set of messages (here on a Mac:)

Oh noes, a cop.  It must be bad!

“Legitimate…other public sites will not ask you to do this.”  Screw you.

“This site attempts to identify itself with invalid information.”

I am doing no such thing.  Rather, I am attempting to encrypt your data transmission.  My site has no reason to identify itself to a client.  Yes, this goes away after the first time, but boy, what a way to scare off potential visitors?

Like Opera, and in contrast to Google Chrome, Firefox does not use any OS built-in certificate stores, such as Windows’ MSCAPI.DLL or MacOS X’s keychain access.  I assume this is for ease of cross-platform maintenance) but it does make it less likely that anyone will use certificates installed universally as part of a Mac package or Windows MSI installer or equivalent.

Thankfully, StartCom Certification Authority is now included by default; CACert, in addition to providing fairly short-lived certs (full disclosure:  I am a CACert assurer of some sort, or at least I was before I completely forgot about it) appears to have failed an audit at one point; Axel Eble points out that Ian Grigg, of Financial Cryptography, is currently conducting an open audit of CACert.

As far as free certificate issuers’ root certificate inclusion in Microsoft products goes, the company’s CA certification policy is pretty hairy — looking at the technical and audit requirements, an open candidate for inclusion in the Windows / Internet Explorer certificate store will have to muster significant financial resources.  Even if this were the case, there’s the interesting catch-all near the end of the requirements, disqualifying

“CAs who fail to meet the burden of proof for the broad business value of their offering to Microsoft customers.”

Without any criteria on what this constitutes.  At least IE’s self-signed certificate warning is a bit less cumbersome.

Commercial certificates cost a fair amount of money, starting at USD $150 for a 1-year basic SSL cert from Thawte, essentially for no incremental cost once they’ve passed their audits.  It’s a money machine, although I can’t fault them for it; I’d try to make money off a broken model too, if I could.

Why is this an issue?  Because the more the use of encryption permeates the Internet, the better.  Call it a distrust of authority, a desire to see increasing amounts of personal data secured out of general principle, a fundamental interest in an overall increase in entropy (let’s not get into the reasons why hiding, obfuscating and protecting your data is necessary — I will simply revert to the old and invincible argument about “you close your door when you use the toilet, don’t you?  What do you have to hide?”)  I want to see everyone and their dog use cryptography, if only for the purpose of letting Joe Schmoe acclimatize himself to the fact that it is not only possible and perfectly legitimate, but actually a very good idea, to encrypt things.

A big scary looking warning creates fear and distrust in the minds of nontechnical users when they visit a site with a self-signed certificate whose purpose is really only to keep the transmission of data-that’s-nobody-else’s-business secure (in addition to being a very small pain in the ass to those of us who have to click through the annoyance every time we want to log into our private web services from a different browser.)  Is that the point?  What about this?

Nice one, PGP.  Might want to talk to your customer services provider (that is, or at least was at time of writing, their actual site.)

Ian Grigg makes a good point — “I despise and loathe the idea that to use crypto you have to know me.”  As such, I agree with the idea that it’s pretty dumb to combine the handling of credentials used for encryption and identification of sites.  From what I can tell, the latter is Mozilla’s main concern with the hoops a nontechnical user has to go through to make sure a site is “legit.”

I understand the idea of wanting to make it clear that a certificate not signed by a “reputable” CA may be masking a phishing or otherwise fraudulent site.  However, one way around this would be to have two classes of warnings — one a simple check whether the FQDN of the website is identical to that of the host the certificate is created for, with a big friendly easy-to-understand information message stating something along the lines of “this certificate is for host xyz.com, please make sure the address in your browser bar is the same” with a simple list of cautions below it.

Bonus points for separating the authentication and encryption portions of an SSL connection — tell the user “the site claims to be xyz.com but may not be, but your transmission is encrypted, do not enter sensitive data, such as credit card or personal information, unless you’re sure whom you’re talking to” and basta.

The second use case, for certificates authenticating a site and encrypting a connection, should check far more strictly that the issuer is legitimate.  In this case, the end-user has a genuine need to know that the certificate issuance process is tightly controlled via a trusted party — the CA root cert included in the browser store.  Fair enough.

Yes, the average “user” may not have much clue, but excessive mollycoddling at the expense of usability is bound to be counterproductive — it scares people away from increased use of crypto, and annoys the rest of us with way more obstacles than are necessary.

Authentication Basics 101

First, some three-point lists to re-hash the elements of authentication, mainly for my own memory-jogging purposes.

An individual who wants to gain access to data or facilities goes through a three-stage process:

• Identification (”Hi I’m Bob!  Let me in!”)
• Authentication (”OK, I verify that you are indeed Bob.”)
• Authorization (”Bob, I verify that you are among those permitted to enter.”)

Authentication can be done using any combination of the following three ingredients:

• something you know (e.g. password, PIN code)
• something you have (e.g. key, smart card)
• something you are (e.g. fingerprint)

It’s been a given for a while that two-factor authentication is a good way of massively raising security of information or premises at a comparatively low cost, by reducing the impact from losing or disclosing any part of the authentication process.  If I drop my access badge on the train, big deal, because I also need a secret passcode to enter the office.

Some Problems (PKI / Certificate Example)

As a quick side-track, during every single PKI-related project involving token-based authentication (usually smart cards) that I’ve ever worked on, two major issues inevitably arose:

First, how do we adapt peoples’ credentials to changing circumstances.  For example, the subject marries and changes their name.  Signing keys used in authentication certificates can be expired or revoked, even though this requires maintenance of a functioning certificate revocation list, something a lot of enterprises don’t seem to be capable of, and which can be technically daunting in any case once you start dealing with multiple thousands of revoked certificates.  However, data signed and encrypted before the expiration or revocation date must be accessible or verifiable in perpetuity, no matter if Jane Smith is now called Jane Smith-Jones.

Continuing the certificate example, this is solved by using something like friendly names on certificates (where the user’s name is not part of the certificate’s LDAP distinguished name (DN), or unique numerical identifiers that are mapped to an actual name in a database accessible by other applications that use the certificate.  There are many ways to skin a cat, or a user who changes their name.  However, this falls squarely into the “bad planning” department that seems to be an attribute of many PKI deployments; architects often don’t make allowance for future requirements, such as extended key attributes (thanks for the tip, Arjo), thus raising the need for additional certificate rollouts and system redesigns.

Second, what happens when the user loses his chip card?  No problem, get him a new one.  Even better, prevent him from losing it in the first place, by combining his authentication token with something he is definitely not going to forget, like the bathroom access pass or his lunch card (but whatever you do, please PLEASE don’t put the company logo or address on his access badge.)

What to do, though, when he’s on a service visit to a missile silo at the North Pole, or with a client in Colombia, and can’t access his laptop?  What about one-man branch offices in Timbuktu?  This is where we start facing increasingly complicated problems with issuing emergency credentials via cell phones (a great medium for secondary authentication — they’re tied to a person, they’re at least somewhat secure against casual attackers via GSM encryption and PIN code access, and they’re one of the least likely items to be forgotten at home.)

Moving beyond the scope of digital certificates, biometric authentication offers a tempting solution for both of the above problems..  Passports can be forgotten, passwords extorted, and unless you’re using a system that doesn’t check for heat or blood flow (useful in the case of the Malaysian Mercedes owner several years ago whose fingers were severed by robbers to gain access to his fingerprint-protected car) or which can be fooled by fake biometric credentials, biometric authentication immediately and reasonably reliably identifies and authenticates a user in one go.  Unless he loses his hands or voice or has his eyes gouged out, but that eventuality doesn’t look so nice in the authentication product marketing brochure, so we’ll conveniently ignore it.

Passwords are Annoying

Passwords have their own problems; I agree that people should use pass phrases instead of passwords whenever possible [1],[2].  Furthermore, I believe that excessively strict password complexity and rotation rules lead people to do stupid things like (with all due respect to Bruce Schneier) writing down passwords in obvious places.  Very few individuals have the time, knowledge or intelligence to write down passwords in a way that keeps them safe (plus, the “YOUR PASSWORD WILL EXPIRE IN 5 DAYS” warnings on Windows workstations tend to catch people when they’re most stressed and hurried to log in and get to their meeting.  Furthermore, password vaults tend to be impractical if, like me, you access similar resources from different workstations, laptops, interfaces, etc.

Biometric authentication gets around all this; in the case of a lot of low-end applications, such as unlocking laptops, it is a thoroughly convenient mechanism that allows administrators to get around the expense and complexity of dealing with things like BIOS/startup authentication, or the aforementioned user failings in dealing with password security rules.

So Where’s the Problem?

There are a number of classic arguments against biometric technology — principal among them being that, in case of identity theft, it is not possible for a user to change his credentials, ever.  My major objection to most uses of biometric authentication, however, is the excessive trust placed in it, combined with the absence of non-repudiation.  While most technologies involved are technologically sound and deployed in a well-meaning manner, these related failings bear the probability of inevitable negative, unintended side effects.

By virtue of its perception as an advanced, “futuristic” technology, there is a tendency to ascribe some degree of infallibility to biometric authentication.  Errors are viewed as improbable; since there are no longer external factors (knowledge or objects) involved in authentication transactions, the person logging in with a thumbprint must perforce be the owner of the thumb who was registered as such.

As an analogy, DNA matching by police suffers from a similar weakness; first, we cannot discount concerns about false positives.  Even if there is a one-in-a-billion chance that a DNA sample from a crime scene matches an innocent person as well as the perpetrator, statistically this may be acceptable, but wouldn’t it suck if you were that innocent person?  Is this tolerable?  Furthermore, as the John Schneeberger case demonstrates, even if the technology were flawless, completely circumventing the context within which DNA matching functions, by means of such shenanigans as introducing fake DNA, the entire usefulness of an otherwise good system is thrown out the window.  This is similar to the famous analog hole argument about why media digital rights management is a fundamentally broken concept; even if the hardware and software works just fine, a method completely out of its scope will render its deployment irrelevant.

In the case of biometric authentication, there are a number of conceivable (and, in my case, for lack of greater expertise, purely theoretical) situations where its employment breaks down; this xkcd cartoon demonstrates one such eventuality in a fairly insightful manner.  Given that many people will be subconsciously awed and intimidated by the cool sci-fi retinal scanners at airports, or palm readers in front of offices, this translates into a disregard for the possibility that something will go wrong with the system — dangerous because, even if the security of the system itself were flawless (which no system is) it can probably be circumvented, somehow.  This brings us to the second, and greater danger, that of the lack of non-repudiation in biometric authentication.

By means of overview, digital identifiers are used in two related but different ways to determine the authenticity of data — signing tells the recipient of data, “the information you received is the same that was sent, and it is I who sent it.”  This comes in the form of MD5 checksums, PGP signatures, etc., or in archaic terms, the royal seal on an envelope — in x.509 terminology, signing keys with an authentication bit set in their certificate containers are normally used for certificate authentication (as the key is used to sign a set of credentials transmitted to an application and to guarantee their inviolability.)

Non-repudiation means that a recipient of information can be assured that the originator cannot deny that he provided certain information; the recipient can prove that something not only originated with a given person, but that person is not able to reneg on the information.  Signatures on credit card slips or notarized contracts are the most common real-world examples of this.  There is a subtle difference between the two — signing assures the recipient that information and sender data are correct, non-repudiation guarantees the recipient that the sender will abide by the terms of the information received.

Authentication by biometrics introduces the idea of non-repudiation into a transaction where it usually has no business.  A user is first identified, then authenticated.  Both of these components of the authentication transaction three-step process take place using the same single medium — part of the user’s body.  This is bad.  As the user is identified as who he is, the authentication process suddenly and automatically includes an audit trail — which cannot, by definition, be contested.

When John Smith, average employee, sits down to log into his company workstation, he enters his username and password.  Even though his username may be “smithj”, which is tied his employer’s Active Directory to his username and photo, the disconnect between the person and the authentication framework means that he is not treated as an individual, but rather as an anonymous construct that possesses, hopefully legitimately, John Smith’s authentication credentials.  Can I prove that someone did not steal John Smith’s username and password?  Not really.  Maybe he wrote it down — perhaps that’s a firing offense in itself, but there is at least the reasonable doubt that it was he who logged in.

Not so with biometric ID.  The moment he swipes his palm across the door entry plate, or looks into the airport retina scanner, even if there is some doubt that it is, indeed, John Smith requesting authorization, that doubt enters the realm of the statistically irrelevant.  Fine for criminal prosecution, but decidedly suboptimal if you are John Smith who spent his Sunday in bed with a book rather than breaking into his workplace with a fiendishly clever copy of his thumbprint, or by jury-rigging the actual scanner with a battery and a bunch of wires.  The fact that it was a physical part of John Smith that was used (in the mind of the authentication system) to open the door or unlock the workstation means that the audit trail automatically associates him with his action.

This extends to a person’s movements between countries, his use of a cell phone, his travel in a car, his purchasing habits — all of which can be plausibly denied and repudiated if physical or virtual items, such as passports and PIN codes, are used to authenticate the user.  Identity theft at this point may be unlikely, but fatal for the victim.

How to Fix This

Biometric authentication is not fundamentally bad.  It has its place, if properly planned and implemented, and if the consequences of its use are known.

For example, authentication can be insular and local.  That is, the process does not register a user’s physical characteristics anywhere centrally, but rather uses a locally cached checksum of, say, a thumbprint to unlock a laptop or smart card — similar to what many Windows-based thumbprint login mechanisms already use.  A kerberos exchange is made with a domain controller, as with a username/password or smart card login, but the actual physical characteristic is not associated in its “raw” form with any central user profile.

Second, biometric authentication must absolutely under no circumstances be tied to audit trails; the tracking of a user’s actions and movements is information desired by law enforcement, human resources, marketing wonks, scammers and any other number of other parties, but there is no reason to tie a user himself, through his physical qualities, to his actions.  I want to be able to deny that I used my credit card in Indonesia last Tuesday; the moment this ability falls due to the authority of a retinal verification for a card transaction that was somehow falsified, I have a huge problem.

Next, such authentication must not cause anyone to come to harm.  As with the Mercedes example above — people are (usually) more important than objects or data.  If you evaluate your security needs and believe it’s a good idea to force someone to go through a burly Secret Service guy to get to the nuclear launch codes, that makes sense.  However, endangering someone’s safety for a car or laptop when it’d get stolen anyway, no matter what they do, would be callous and pointless.

Lastly, authentication credentials must not be tied to any other stored instance of a person’s biometric information.  This sounds paranoid, but physical characteristics, since as we see above these are refutable only with difficulty, and credentials can’t be changed.  The instant someone is able to abuse biometric credentials, a user’s entire financial credibility, his workplace history, and any number of other valuable combinations of reputation and resources may suffer.

1) Transparency and usability of security mechanisms whenever possible
2) Prevention of unauthorized access
3) Anonymity
4) Easy replacement of lost or compromised assets or data
5) Plausible deniability by users of data on their systems
6) Traceability
7) Ease of management and support of users and assets
8) Expandability and portability of the solution

Any mobile environment should be usable by all users, regardless of their security profile, so we will be relying on as much automation and build standardization as possible.

We start by breaking down the productivity requirements into two classes: sensitive (having to do with company-internal infomation) and general (contact to others via Internet.)

The basic functions that we want are thus:

• Basic office productivity tools (documents, spreadsheets, presentations, similar tools)
• Mail (secure when needed)
• Other communiation and collaboration with internal users and external persons (such as chat and VoIP — secure when needed)
• Browsing (secure Intranet sites)
• Browsing (other)
• Secure document & data storage (local and remote)

So essentially, we can group all these requirements into two rough clusters:  “stuff that needs to be very secure” and “stuff that doesn’t need to be that secure” (beyond the usual protection from everyday badness.)

The solution we came up with for all these requirements was a multi-tiered model, using a couple of commonly available tools.  Yet another short ingredients list:

• Layered access control (boot sector protection, full disk crypto, a strong authentication model) for the laptop itself
• An “inviolate” stronghold (such as VMWare ACE) running on the laptop — this is the only environment from which the more secure internal functions, such as corporate groupware and file sharing can be run
• Integrity policy (mixture of Microsoft AD GPOs and Check Point integrity client)
• A relayed VPN connection — via an offshore VPN gateway — so casual sniffers have trouble tracking the destination of your VPN link
• Live remote AD logon — Check Point, and possibly other vendors do a really nice thing called “SDL”, or Secure Domain Logon, where your Windows AD credentials are taken from the MSGINA into a “holding pattern” until a VPN connection is established (via a “shim GINA” that comes right after the MSGINA), at which point you are given a full live AD logon, as opposed to authenticating to the locally cached auth credentials
• PGP-based optional mail and file crypto, allowing for greater flexibility with removable devices (corporate ADKs, or additional decryption keys, deal with all those pesky recovery issues)
• Terminal-server based applications and filestorage for sensitive material; Citrix or Microsoft Terminal Server both do the trick here.  The point is to add another layer of security between the laptop and the crown jewels, and to remove the need for remote workers to store unnecessary but sensitive materials locally.

That’s it for today, class.  At some point I’ll go into what to do about remove laptop recovery, allowing users to have data auto-destruct without incriminating them or garnering accusations of impeding investigations, and other cool topics.

Not all governments welcome the presence of high net worth private banking client advisors, or representatives of competitors to national champions in their jurisdiction, and such individuals should worry about industrial espionage. Furthermore, countries such as the United States have enacted restrictive immigration policies during the past few years, which allow pretty much unfettered access to laptops of business travellers. Several colleagues of mine entering the US for security conferences have been harassed upon identifying themselves as security consultants or experts.

Additionally, the maintenance of a fixed office may simply not be economical in certain regions, especially when individual sales reps, consultants or other professionals cover large geographical areas. The laptop should thus function as a completely secure, untraceable, self-contained office environment, giving the user access to all functionality he would have at a fixed, secure office but without endangering company data, user safety or corporate infrastructure.

One of my on-again off-again projects is the design of a secure mobile platform. Beyond the usual full-disk crypto + VPN solutions used by most companies with executives on the road, I believe that a true mobile architecture involves several more parts that are often ignored.

The Jericho Forum proposes ‘de-perimeterization’ as the removal of fixed barriers to the core network; they do not, however, offer a great deal of substance or concrete suggestions. To this end they are occasionally criticized, although in this particular case I can’t agree with the author. IPSEC may have its weaknesses, but solution elements such as Check Point’s Secure Domain Logon (which uses a “shim GINA” to establish a VPN connection to a corporate internal network before Windows authentication credentials are actually passed through from the XP GINA) both make PKI and smart-card authentication feasible and allow full integration of most types of mobile clients.

As the above hints at, the goal of a mobile solution must be to extend the corporate perimeter without sacrificing any security or usability, something which I believe is entirely doable and which, in fact, we’ve gotten nicely working on a number of occasions. However, as important as the integrity and security of a given laptop, are the maintenance of anonymity and discretion, and the manageability of a given workstation. Neither the laptop nor a user’s regular everyday actions should give any clues as to the provenance of a laptop, and in no way should compromise of a laptop construe a threat to the integrity of data on the laptop or corporate infrastructure.

In Part II, I’ll discuss individual elements of such a solution.

The handbook is currently in version 1.0, downloadable from the site, although some of the other resources (risk analysis guide, repository) are in development. The SOBF (Security Officer’s Best Friend) — a risk reporting and analysis tool is also in beta, but looks to be nearly usable. I am going to have a closer look at this to see how it can work together with more technology-specific risk analysis tools like Symantec’s, or with methods such as CERT’s OCTAVE. As it stands, it might be an interesting start for companies who’re out to build their own custom tools and methodologies anyway.

I hope this doesn’t go the way that the OpenCA/OpenPKI project did a while ago (published a handbook that was a great start, but stagnated for a long time, although there seems to have been some work going on recently.) Check it out.

Edit: Adrian Wiesmann from SOMAP just wrote me a nice note to tell me that they’re working on the second version of SOBF, and are looking for a project manager in Switzerland as of present (25.11.2006.) “To make it less possible that the project stops again right after starting, we are actively looking for a project manager which would coordinate the contributors, manage timelines and subprojects.” So if you’re interested, drop them a line via their website.