SafeGuard Disk Encryption for Mac 5.5

8:37:00 PM

Sophos SafeGuard Disk Encryption for Mac offers full-disk encryption (FDE) for the Mac, with protection at boot time from unauthorized access. FDE scrambles the entire contents of a disk drive, rendering it ostensibly unrecoverable without access to the long encryption key used, or a shorter account passphrase that unlocks that key.

FDE makes your data secure when someone gains unauthorized physical access to it while your computer is shut down. If a computer with an FDE-protected drive is booted and running, the data is still susceptible to various forms of extraction using forensic tools, even if there's a password lock enabled in OS X. But when the computer is shut down, it's as close to Fort Knox as one could hope.

With Lion, you have the option to use the built-in FileVault 2 FDE that replaces the directory-only encryption provided in the original FileVault system introduced in OS X 10.3 Panther. FileVault 2 works quite well, is integrated into system accounts and system boot time, and relies on AppleCare support as an optional backstop to help with extreme cases in which an account password fails or is forgotten and a separate emergency recovery key has been lost.

SafeGuard, compatible with Lion in version 5.5, has to scale a mountain to convince users to purchase a feature that's otherwise built into the OS. A third-party encryption tool has to do the job right, but also have features or options that set it apart from FileVault 2. (SafeGuard provides a separate installer for Mac OS X 10.5 and 10.6. If you upgrade from Snow Leopard to Lion, it is vitally important to follow Sophos's instructions. An upcoming SafeGuard 6.0 release will work on 10.5 through 10.7, however, according to Sophos.)

Sophos requires that you create unique accounts, separate from Mac OS X, including at least one administrative account.

SafeGuard doesn't quite get there. There are enough rough edges and confusing bits that don't place it anywhere near the ease with which Apple enables FileVault 2, which make SafeGuard hard to recommend highly. Sophos could sand down the interface and documentation friction, while adding a couple of compelling features. However, SafeGuard is a good choice for anyone who prefers not to rely on Apple for their encryption needs for whatever reason.

Using SafeGuard

Sophos relies on its own user accounts set up as User and Admin categories, which means extra account management instead of using Mac OS X authentication. This is clearly required because at startup time SafeGuard has to rely only on what its own system can manage—it can't access Mac OS X or accounts. We can’t ding the product for that, but it's more complicated than Apple's integrated ability.

You set up at least one Admin account to start encrypting the drive with a single click. There's an option to use Fast Mode, which has no explanation in the program or documentation as to what "fast" means. I had to query the company, which explained that with Fast Mode disabled, disk encryption takes a back seat to whatever the user is doing. In Fast Mode, encryption consumes all available computational power, which might slow down other activities.

Admin accounts can enable and disable encryption on partitions, and create and delete regular users. A User can log in at startup. User accounts can be backed up with a third form of account, Recovery, which are one-time use logins assigned to specific User accounts, and which are meant to help in case you forget or lose the password for a User account.

Sophos could provide a more sensible handholding walkthrough here. It should have the option of an assistant that guides you through creating an Admin user, and gives you the opportunity to create a regular User and one or more Recovery accounts. Instead, I had to stumble through the documentation to figure out the precise relationship.

Any FDE system needs to offer tools to help you when things go awry, as normal disk utilities won't work. Sophos includes options in its program's Users tab in a gear pop-up menu, but they're rather hard to parse there and in longer explanations in the documentation. I sorted it out, but I don't expect that even an advanced user will find the explanation straightforward.

Sophos has three recovery options, but it's really two ways to make bootable media, with a third menu item to export your encryption and authentication data. You can either create a generic bootable image without your login bits (which lets you separately attach your authentication data), or you can create one that's bootable and has the necessary credentials for the specific computer from which the disk was exported.

What Sophos doesn't explain is that you need to take the disk image and create a bootable volume from it. This is trivial in Disk Utility. Drag the disk image into Disk Utility, where it shows up in the bottom of the list at left. Insert some kind of media, such as a USB thumb drive, that you're willing to erase one or more partitions of. Select the disk image icon, and then drag the partition of the drive you're using into the Destination field. Click Restore. This creates an EFI-formatted bootable drive you can select at startup time by holding down the Option key. Would that these instructions (with some screen captures and more detail) were in the manual.

Sophos has its own EFI-based boot process that lets you enter a user or administrator account to start up Mac OS X. Only the keyboard works; mice and trackpads are unavailable.

I tested booting from a recovery image and performing various recovery operations, and they worked just fine. As with the rest of SafeGuard, the actual function is there masked by an unpolished interface. You can decrypt a drive quite simply, too. While logged in as an administrator, click Decrypt.

Limitations

SafeGuard also warns you in the documentation against backing up certain files in Time Machine, but doesn't provide a tool to exclude those automatically. SafeGuard can't encrypt external drives. And it requires the use of the keyboard in its boot manager, which makes it feel a bit more like using a newer PC BIOS than a Mac. Ostensibly, they didn't want to include mouse and trackpad drivers.

SafeGuard makes it simple to encrypt or decrypt an entire drive.

The only compelling reason to choose SafeGuard over FileVault 2 relates to boot-drive partitions. FileVault 2 only works on a Mac OS X's boot volume in which the Lion Recovery partition is installed and working. You cannot use a custom partition scheme, and users have reported all sorts of problems if they've messed with Lion partitions. SafeGuard doesn't have this problem. You can encrypt any number of partitions on the boot drive, and a Lion Recovery partition isn't a requirement.

encryption

How to keep your Mac safe from Web security flaws

9:05:00 PM

How to ensure rogue security certificates don't subvert your encryption

This year there have been numerous reports suggesting that the fundamental security infrastructure of the Web is on shaky ground. In March we heard about a collection of stolen security certificates, and in August the release of more than 500 improperly issued certificates came to light.

\Whenever you connect to a secure Internet site, your computer and the remote server need to exchange a strong encryption key in order to prevent eavesdropping by third parties. It’s a clever jig performed hundreds of billions of times a day among hundreds of millions of programs and servers—but the web of trust that makes it work is in peril like never before.

The good news is that changes are afoot to make connections safer than they’ve ever been. But until browser and operating system makers fix the teetering system, you can take some matters in your own hands to improve your own security. (If you don’t want to know this whole system works, skip the next section and go straight to our advice on how to secure your Mac.)

Trust, but verify

If you’re exchanging information over the Internet, you have to assume all communications could be monitored by criminals, trolls, and governments. How can you start this dance if you can’t be sure you’re asking the right partner to participate? The trick devised not long after Web browsing hit the mainstream in the mid-1990s was known as SSL (Secure Sockets Layer); it’s since been updated, and has a new name, TLS (Transport Layer Security).

SSL/TLS relies on digital certificates that provide the cryptographic information for a server to send a session key safely to a client. The certificate is bound to a given domain name, like google.com, and can’t be used at any other domain. These certificates are issued and countersigned by certificate authorities (CAs), of which hundreds exist worldwide. CAs affix a kind of permanent seal (a digital signature) to a certificate that can be checked against a list of trusted CAs built into all major operating systems, whether desktop or mobile. Some browsers maintain their own, separate lists, too. (Safari consults Mac OS X’s list, while Firefox consults an internal table.)

Mozilla's green bar. Safari displays the same information in green text at the right end of the URL field.

Let’s take a typical scenario. google wants to offer secure Web logins. It signs up with GeoTrust to receive a SSL/TLS certificate that works for any domain that ends in google.com. GeoTrust uses some method of verifying that google’s technical chief or IT department should be allowed to receive such a certificate, typically by sending email to a google.com address noted in the domain’s registration. CAs may also request additional information, such as a fax of a business license or driver’s license. For “Extended Validation” (EV) certificates, businesses have to provide even more documentation about themselves, for which they are rewarded with a “green bar” that shows up in most browsers. (To see this bar in a browser, visit Mozilla’s add-on site.)

When the certificate is issued, signed by the CA,google installs it on its servers that handle secure connections. Google.com retains a private part of the key, never shared with the CA, that allows it to decrypt incoming messages used to set up secure sessions. Whenever someone visits the secure site, the certificate is transmitted. It contains only public information, including a public key that corresponds to google’s private one, as well as a signature from the CA that vouches for it.

A browser receives the document, and confirms using built-in CA information that the certificate was correctly signed, and thus that the public key contained in it is valid. These CA signatures are currently considered unforgeable. The browser and server can now privately exchange a long session key and use that to encrypt all the data during the session.

That all sounds dandy. Checks and balances ensure a closed loop. But the problem lies in a couple areas of trust. First, operating systems believe anything they are told about how a domain name (google.com) translates into the underlying Internet protocol (IP) address (58.2.2.1.1) used to make the actual connection. It’s easy to “poison” DNS on a local network, such as at a coffee shop, or for an entire country, such as Iran. You simply need to position bad information at the choke point between where queries are sent by a computer for the lookup of a domain name, and from where the reply is returned.

A certificate that has a domain name other than the one assigned to a server feeding out a secure connection prompts browsers to provide dire warnings that can’t simply be clicked to ignore.

The SSL/TLS certificates are resistant to this, however. You can poison DNS, but you can’t forge a CA-signed certificate. If you visit a server that your computer has been subverted into believing is google.com, and it provides a certificate for another domain or one that hasn’t been signed, then your browser barfs up a message warning about the mismatch. These warnings typically require serious effort to bypass, as opposed to the usual “horrible security flaw: click OK to continue” sorts of messages.

Since CAs control the issuing of certificates, this shouldn’t be a problem—if we could trust every CA equally. Over 600 parties worldwide act as a CA for at least some combinations of browsers and operating systems; Apple’s products honor nearly 200. Every CA can sign off on any domain, and can delegate authority to lesser parties. A security document created by any of these anointed or delegated CAs will look legitimate to all browsers worldwide.

If a CA is subverted or issues a certificate under duress because a government demands it, and a network (whether cafe or country) has poisoned DNS, the entire transaction looks legitimate to a browser. The machine swears it’s a Gmail server and it has a validly signed Gmail certificate from a trusted CA. Thus, the browser doesn’t squawk.

This is the root of all of those scary news stories about rogue certificates. In the last year, several CAs have been compromised, some potentially by government-sponsored crackers. A major certificate issuer, Comodo, had a breach through an affiliate in March, leading to valid but illegitimate certificates being issued for domains controlled by Google, Skype, Yahoo, and others. In August, the Dutch CA DigiNotar was found to have issued over 500 improper certificates, including one for all google.com domains, without providing proper disclosure nor keeping good records. There are almost certainly more revelations to come.

When a bad certificate is issued, whether an improper one such as the examples above, or one simply created with the wrong details in an administrative error, a CA can issue a revocation that is supposed to block browsers from accepting a certificate as valid. But revocations aren’t typically built into browsers or operating systems. To check whether a certificate remains valid, a browser or other software has to communicate with a CA’s revocation servers to either ask about that particular certificate or download a full list of revoked documents. Those servers may be easily blocked by malicious parties or nations—or simply not provide a response fast enough for the client software’s liking. Browsers and Mac OS X are configured to ignore an inability to check whether a certificate is revoked, rather than to make a stink about not knowing the answer.

Because of this, Apple, Microsoft, Mozilla (Firefox), and other operating system and browser makers released updates both to block specific certificates hijacked from Comodo, and to remove DigiNotar from the CA list entirely for desktop systems.

Secure yourself

So what can you do to prevent your Mac from being the subject of a man-in-the-middle snooping attack? Plenty.

First, turn on revocation checking in Mac OS X and in your browser. This may cause some disappointment on slow networks when a CA’s revocation servers aren’t as responsive as they should be.

For Mac OS X as a whole (including Safari, Google Chrome, Mail, and other programs that use secure connections), you need to use the Keychain Access app, located within the Utilities folder inside your Applications folder. From the Keychain Access menu, select Preferences. Click the Certificates tab. You’ll see options you can set for OCSP and CRL. OCSP allows a brief query about a single certificate, while CRL downloads a full list if a cached one from that CA is out of date. Apple sets these to Best Attempt by default, which means a failure is ignored. Instead, choose Require If Certificate Indicates for both OCSP and CRL. Also choose Require Both from the Priority pop-up menu. (The Require for All Certificates option is available if you hold down the Option key, but that doesn’t guarantee such a server can be found if it’s not specified in the certificate. A certificate may be obtained illegitimately, but the CA that issues it will still include revocation server information.)

The only problem with forcing a check of revoked certificates is that Apple has a flaw in how it validates Mac App Store updates. With the option selected as shown in the figure below, you may be unable to perform updates through the App Store program. To fix that, launch Keychain Access, change the preferences to Best Attempt, update your apps, and then reset to the stricter setting. This is something Apple should clearly fix, since all the components of this situation are under its control.

Set OCSP and CRL to always check if a certificate has revocation server information, and make sure both kinds of revocation services are consulted.

In Firefox, select Firefox -> Preferences, then click the Advanced icon. Click the Validation button. Make sure “Use… OCSP” is checked, and Validate a Certificate If It Specifies an OCSP Server is selected. Also check When an OCSP Server Connection Fails, Treat the Certificate as Invalid. Click OK. In using this setting for some weeks, I’ve found a handful of times I’ve had to reload a webpage to get a proper OCSP response.

Firefox doesn’t allow downloading a list, but checks each certificate for revocation.

Chrome has a separate option (Chrome -> Preferences, click Under the Hood, scroll down to HTTPS/SSL) where you can check or uncheck Check for Server Certificate Revocation. Keep that box checked. It doesn’t appear that you can force Chrome to retrieve a list of revoked items, but the documentation is unclear, and it’s hard to rely on in practice. It relies on Mac OS X for certificate management.

Second, if you use Firefox, you can test out a new approach in validating whether a certificate is correct without relying entirely on certificate authorities. Two projects let you install add-ons that use “notary” servers that constantly retrieve certificates and keep track of the signatures on them to alert you if a certificate doesn’t seem to be correct. The Perspectives Project alerts you if your browser receives a certificate for a site that’s different than one found over the last 30 days. Convergence also relies on notaries, but over time will allow other kinds of integrity checks.

Perspectives tracks certificate signatures over time, and warns you if the one retrieved by your browser is different from those stored over the last 30 days by multiple notary servers.

Third, if you use Chrome, Google has and continues to add additional certificate checks. The current release of Chrome only allows certain CAs to vouch for Gmail’s certificate, and blocks other attempts. Expect more along these lines. (In fact, this Chrome feature is what alerted an Iranian user to an apparent use of a DigiNotar obtained google.com certificate on an Iranian network.)

Removing CAs

So what happens if you read a news report about a compromised CA and want to pluck the CA out of your browser as soon as possible? To change Mac OS X’s settings, and thus affect Safari, Chrome, Mail, and other programs that rely on these values, follow these steps.

You can change the value of any built-in certificate authority to avoid letting it vouch for the integrity of secure connections.

Open the Keychain Access app as before, and click the System Roots item under Keychains at upper left. Select the certificate in question from the list, and select File -> Get Info. Click the expand triangle next to the word Trust near the top. From the When Using This Certificate pop-up menu, choose the item Never Trust. When prompted for a password, enter it, and click Modify Keychain (which you are prompted for just the first time). Then enter the password when prompted and click Change Settings. You’ll see a small red “x” in the certificate’s mini-icon.

There’s one flaw, however: Even if you distrust a root certificate, Safari will ignore this lack of trust if a website presents an EV certificate. That’s illogical, and presumably Apple will fix this bug in the future. The only way to ensure that an improperly issued EV certificate won’t be accepted even when you’ve ostensibly blocked the CA that produced it is to stop using Safari until the bug is fixed.

In Firefox, choose Firefox -> Preferences, click the Advanced icon, and then click the Authorities tab. Scroll through this list to find the CA you want to remove. Select it, and then either click the Edit Trust button or the Delete or Distrust button. Edit Trust lets you retain the certificate, but disallow its use. Delete or Distrust removes all trust from built-in certificate authority information, or removes a manually entered CA. (Some companies and other entities may choose to trust a CA separately from the global chain of trust built into the browser.)

You can remove the trust from any certificate authority in Firefox.

What about your phone? Sadly, you’re out of luck. The greatest disappointment in all this certificate authority nonsense is that both iOS and Android have lagged behind on dropping support for suborned certificates and hacked CAs. (Windows Phone 7 never included DigiNotar on its approved list.)

Future Efforts

You might despair after reading about the scope of this problem, and the complexity in managing some of the fixes yourself. But don’t lose hope. With the exposure of these flaws, companies that sell hundreds of billions of dollars of goods a year over the Internet are aware that they can’t allow trust to seep away. Browser and operating system developers are also moving into higher gear to avoid putting customers into compromised situations.

Built-in notary support. Future browsers could include the kind of checks that Perspectives and Convergence offer. Better, you might be able to choose the notary servers you trust, so that you can place your faith in the security of particular organizations. The Electronic Frontier Foundation, which has conducted certificate research, could offer a notary service, for instance. The more notaries, the better, as it increases heterogeneity, which improves the chances of problems being spotted instantly.

Domain pinning. You may see browsers including more support for domain pinning, which allows only specific CAs to vouch for a given domain. Google built in a fixed pin for Gmail’s certificate into Chrome’s recent releases so that only three CAs are recognized as valid countersigners, and has a setting that lets you pin domains manually. One could see Apple, Microsoft, Mozilla, and others pinning domains that relate to their own businesses, and working with other companies and organizations to support a global pinned directory. This tremendously reduces the risk of rogue or suborned CAs.

Fewer CAs. It’s very likely that fewer and fewer CAs will be given the blind trust currently offered. Fewer CAs lead to a smaller risk profile and less exposure.

DNSSEC/DANE. A complicated effort is underway that will allow websites to put digital signatures for their certificates into secured DNS (Domain Name System) records. DNS is used to connect a domain name to a machine-readable IP address, and a decade-long effort to provide a cryptographic underpinning (to kill DNS poisoning, among other matters) is nearing fruition.

Dynamic CAs. Microsoft chose to use dynamic lists of CAs starting with Microsoft Vista. It’s also found in Windows 7 and Windows Server 2008. Instead of having a fixed list of CAs that an OS update is required to modify, Microsoft only caches CAs temporarily, for seven days, using a secured service it operates. On visiting a secured website, if the CA that signed its certificate isn’t cached, Windows consults Microsoft’s list, downloads the validation, and then affirms the website’s certificate. Microsoft was able to dump DigiNotar right away, while Apple took weeks to push out a security update that took care of the problem.

These fixes could all have been in place earlier. But it’s the same motivation that puts a traffic light at an intersection only after pedestrians are repeatedly hit by cars. Late—but better late than never.

Computer^News^FAQ

SafeGuard Disk Encryption for Mac 5.5

Using SafeGuard

Limitations

How to keep your Mac safe from Web security flaws

How to ensure rogue security certificates don't subvert your encryption

Trust, but verify

Secure yourself

Removing CAs

Future Efforts

About me

Follow Us

Press

recent posts

Text Widget

Pages

PCWorld How-To's and Tips

PCWorld Latest Technology Reviews

Like us on Facebook

Flickr Images

Computer^News^FAQ

SafeGuard Disk Encryption for Mac 5.5

Using SafeGuard

Limitations

How to keep your Mac safe from Web security flaws

How to ensure rogue security certificates don't subvert your encryption

Trust, but verify

Secure yourself

Removing CAs

Future Efforts

About me

Follow Us

Press

recent posts

Text Widget

Subscribe To

Pages

PCWorld How-To's and Tips

PCWorld Latest Technology Reviews

Like us on Facebook

Flickr Images