MacLockPick is a $500 USB flash drive from SubRosaSoft. It claims to be

a valuable tool for law enforcement professionals to perform live forensics on Mac OS X systems…. with as little interaction or trace as possible.

You insert the USB drive into a Mac, run some software, and it will copy a bunch of sensitive information to the flash drive. Among the information copied:

• the user password of the logged in user
• passwords for encrypted disk images, iTunes music store and iChat login
• login and passwords for web sites, email accounts, online stores and .Mac accounts
• a list of all the key user folders, with their creation dates and date of the most recent access
• paths to files opened in the Preview application
• recent applications, documents and servers
• contacts stored in Address Book
• search terms from Safari’s Google search bar
• Safari bookmarks
• web cookies, which may include login information to secure sites
• web browsing history

Wow. That’s a phenomenal amount of sensitive information available. Is it possible that you can thwart such a device with two mouse-clicks?

The device “is not for sale to the general public” and anyone buying it must prove they “are a licensed law enforcement professional”. No word on what proof is required. (I got to the point in the order process where I was asked for my eBay payment information, without any request for some kind of proof.)

From what I can tell (there is understandably little detailed information on SubRosaSoft’s website), much of the application (all the password stuff) works by taking advantage of Mac OS X keychain’s default settings. You, Mr. or Ms. Mac user, have a “keychain” that stores all of your logins and passwords, and an application (called, intuitively enough, “Keychain Access”) to manage those items. You only have to remember one password (the keychain’s) instead of dozens or hundreds of individual ones, and application developers don’t have to write dozens or hundreds of different ways of storing secure information: they just use the keychain.

By default, when you log in, your default keychain is unlocked for you. It re-locks automatically after your computer’s been idle for some time. The keychain resets to the default “unlocked” setting when you wake your computer from sleep. This means if the keychain happened to be locked when you put your computer to sleep, it will, by default, be unlocked upon wake.

This is meant as a convenience to you: when you’re actively using your computer and an application needs a stored username or password, the application gets that information from the keychain without interrupting your work. When you’re not using the computer actively, the keychain is locked, protecting your secure information from casual attackers.

This convenience appears to be the vector SubRosaSoft uses for MacLockPick:

Once awakened a Mac will return its keychain access levels to the default state found when it was initially put to sleep. Suspects often (and usually) transport portable systems in this sleeping state.

If my assumption is correct (I’ve asked SubRosaSoft to confirm or deny this; I’ll let you know if I hear back), thwarting MacLockPick is as simple as checking two boxes in the Keychain Access (found in /Applications/Utilities):

You’ll find these checkboxes in Keychain Access under the Edit > Change Settings for Keychain “login” menu.

The first checkbox (“Lock after # minutes”) will lock your keychain after the set period of time. After five minutes (in this example), any application needing access to your keychain will result in a prompt for your keychain password.

With the second checkbox (“Lock when sleeping”), applications needing access to your keychain after your machine’s awoken from sleep will likewise prompt for your keychain password.

Both items make it more likely that at any given period your keychain is locked, and therefore unaccessible to applications without your direct intervention. What you lose in convenience you gain in security. (And yes, actually setting this to five minutes will certainly drive you batty if your applications need stored passwords a lot.)

Why would I write about a way to potentially thwart a supposed law enforcement device?

First, the default settings for Keychain Access are less secure than they could be. Clearly Apple made a conscious choice here, coming down on the side of user convenience in leaving the two options off by default. That’s probably the right choice, one I’ve never had the need to rethink until now.

Second, I’m merely pointing out two checkboxes Apple has included in Keychain Access. They’re clearly there for those who wish to enhance their computer’s security. In fact, the National Security Agency (NSA) Systems and Network Analysis Center (SNAC) have this very recommendation in their “Mac OS X Security Configuration For Version 10.4 or Later, Second Edition”.

If this method prevents covert access via MacLockPick to sensitive information (and I still don’t have confirmation that it does), law officials will still have other methods of accessing the information, while I have some piece of mind that MacLockPick won’t be misused on my machine by some unscrupulous guy sitting next to me in a coffee shop.

Unfortunately, this would still leave much of your sensitive information ripe for the picking. Enabling OS X features like Safari’s Private Browsing, or the use of encrypted disk images come to mind immediately. I would suggest a thorough reading of the NSA/SNAC security configuration guide. I’ll write about some of my security escalation plans in the next couple of days.

Deeper-geek aside: The piece I’m unsure about is how MacLockPick has access to your keychain information without you giving it access. Any application can write to an (unlocked) keychain, but requires permission (in the form of asking for your password) to access any keychain item other than its own. It’s possible SubRosaSoft is bypassing the keychain APIs and using a much lower-level set of functions (the open source Common Data Security Architecture (CDSA) and the Common Security Services Manager (CSSM), which the keychain protocols are built on).

I’ll be looking into this detail using Apple’s Developer Connection website, where documentation on reading and writing to and from the keychain is available for application developers.

Update: A comment on Digg pointed me to another author’s take on this, along with that author’s suggestions for further securing your Mac.

Technorati Tags: Apple, CDSA, CSSM, Keychain Access, Law enforcement, Mac OS X, Macintosh, MacLockPick, Privacy, Security, SubRosaSoft