These are the apps that I will install first on pretty much any new Mac that I get. I’m a huge fan of free and open source software, and no other platform has free software of the same quality and caliber as Mac OS X. Most of these are Mac-only apps (a couple are cross-platform). I’m listing free applications wherever possible, but if there is a paid-for app that I consider best-of-breed, I mention those too. Hopefully this list will help all of the techie switchers get the apps they need quickly. This list is a work-in-progress, so I’ll be adding to this it over time.
If you’re only interested in my recommended security apps, they’re at the bottom! Feel free to post in the comments if you have any you think are worth mentioning.
Last updated: 27/10/2012
The guys at GPGTools have taken control of the MacGPG2, GPGMail, GPG Keychain Access and GPG Services projects, and have released a single unified installer that installs all of these apps. They are maintaining these tools, which are all 64-bit and Snow Leopard compatible. The package also include Enigmail, a GPG-compatible plugin for Thunderbird (Mozilla’s free email client).
For more information, check out my tutorial on using GPGMail to send encrypted emails on Mac OS X.
Ever since the release of the IronKey I’ve been drooling over the device (good thing it’s waterproof I guess). Due to not wanting to pay so much for a USB key, I decided to make my own. I grabbed myself a 32GB USB key, and got to work on making it as close to the IronKey as possible.
When Snow Leopard came around, it completely broke support for GPGMail, and there were no other solutions that enabled similar functionality. This caused a significant issue for Snow Leopard users needing GPG functionality. The original developer of GPGMail unfortunately did not have the time to update the plugin and restore support for Snow Leopard.
Since then the GPGMail project has been handed over to a new team of developers who have been working on restoring the full functionality of the plugin under 10.6. This tutorial shows you how to easily install GPGMail and start sending and receiving encrypted emails!
[Updated 21/01/2011] The team at GPGTools have now created a unified installer which consolidates MacGPG2, GPG Keychain Access, GPGMail and GPG Service. Their all-in-one installer simplifies the install process, and installs everything you need for encrypting/signing files and emails.
If you’ve used the GPGTools package, please post your experiences in the comments!
After logging into my MobileMe account today I was greeted with a small banner in the left-hand menu announcing an upcoming Mail Beta. Although I haven’t yet been upgraded to the Beta, it appears that Apple have been hard at work on turning MobileMe Mail into a full blown web email client… it’s about time.
Additions include proper formatting capability, improved layout and display, e-mail rules, and persistent SSL. With regards to that last one, although MobileMe supports SSL at the login screen to protect your credentials, all subsequent information (read: all your emails are belong to us) is sent in cleartext – an issue I posted about a long time ago. Google enabled the option to use persistent SSL for its Gmail service back in mid-2008 (although it is an option you have to specifically set in your Gmail preferences).
From my initial impressions of the beta, it definitely looks much better to begin with. The ability to view your inbox in the three (classic, compact, widescreen) views will probably be quite popular. The search field also works better. They finally allow you to scroll fluidly through your mailbox folders, however it only loads a certain number of message at a time. Now, this wouldn’t be too bad except that in this case it takes a bit too long for that loading to happen. Apart from that the persistent SSL also works nicely, so once they fix any small bugs and improve performance, I’ll consider myself happy.
Oh… and there’s rumors that MobileMe might become free. THAT would make me happy too!
Note: This is a 2008 post I managed to recover from my archive of Securethoughts.net
A team of researchers at Princeton University have devised a way to compromise disk encryption mechanisms, and even other disk image encryption mechanisms, by recovering latent data such as encryption keys, that remain in RAM after a computer has been rebooted/turned off. They’ve tested their attacks against encryption mechanisms such as Microsoft’s BitLocker, TrueCrypt, Linux’s dm-crypt and Apple’s FileVault.
This technique is ingeniously simple, and they’ve written a tool from which they can boot a computer, and do a memory-dump of the latent memory data, which they then run through another utility which searches the memory dump for encryption keys, which can then be used to decrypt the encrypted drive/images.
With regards to Mac OS X 10.4 and 10.5, the group discovered that the system stores multiple copies of users’ login passwords in active memory, making them vulnerable to such imaging attacks. Those passwords are often used to protect the keychain, which stores many of users’ other passwords, including the FileVault password, and potentially other encrypted disk images. This is potentially something Apple should address, and they don’t really want to be storing passwords and keys in memory, if they don’t have to. Keeping as little sensitive data in active memory as possible would greatly reduce the chances of it being compromised in imaging attacks such as these.
Check out their great video below, and read more about it after the jump!
This research was performed by J. Alex Halderman , Seth D. Schoen, Nadia Heninger, William Clarkson, William Paul, Joseph A. Calandrino, Ariel J. Feldman, Jacob Appelbaum, and Edward W. Felten. A combined team from Princeton, the Electronic Frontier Foundation (EFF), and Wind River Systems (specialists in decide software optimisation).
Although their paper focuses on recovering encryption keys, naturally this technique can be applied to any other sensitive information that may be stored in RAM at the time. They’ve also used data reconstructions algorithms to recover data that has already decayed from RAM. According to their paper, keys with 10% of bits decayed can be reconstructed to nearly any 128-bit AES key within a few seconds. On average, they found that memory was legible for up to 20 seconds on some hardware, but this number could extend into several minutes. By drastically reducing the temperature of the memory modules, they were able to reliably recover data up to 10 minutes after removing the RAM chip. Particularly interesting is their research with ECC memory, where they found that machines that support ECC memory tended to wipe RAM upon boot, which is done to avoid errors in the case of uninitialised reads of the memory. Unfortunately this is a characteristic of ECC-enabled machines, and not the memory modules themselves, meaning that ECC memory inserted into non-ECC hardware was still recoverable.
The software developed by the team, presumably with the particular help of Wind River Systems, allowed them to recover the memory dumps in several ways including: over a PXE network boot, which would send the data in UDP packets over the network; using a USB drive to run a small memory-dumping program; or using an EFI bootloader, such as those used on Intel Macs, which also allowed data transfer over netboot.
I highly recommend their paper, particularly the first and last thirds of it, as they are quite legibly written (the middle is mainly about recovering different encryption algorithm keys). It will be interesting to see what kind of innovation will come about in attempts to defend against such attacks. No doubt we will be seeing some papers on that subject soon.