Portland, OR

Given the tremendous amount of press Apple’s feud with the FBI is receiving, I thought it would be helpful to explain what user data and information Apple makes available to law enforcement and how law enforcement can acquire this information. In the first part of this article, I simply provide factual information that Apple outlines in its Legal Process Guidelines from Sept. 25, 2015. I break the information into three parts: how law enforcement requests information, what data from physical iOS devices is available, and what data stored on Apple’s servers is available (including iCloud and non-iCloud data). After providing the factual information, I also provide some analysis and and recommendations on how to keep your data safe on iOS devices.

I’ve thought carefully about this topic and have decided not to significantly address Apple’s participation in any of NSA’s secretive programs, including PRISM. There is ample evidence from the press that Apple has participated, and I recommend people read Bill Blunden’s article on Apple’s relationship with the U.S. government (as well as all the articles he cites) if you want to know more. My general belief is there is little you can do to protect yourself from NSA data collection, unless you never connect your iOS device to WiFi or cellular networks. (Feel free to consider email from a provider like protonmail.ch or voice and text services from Silent Circle as enhancing privacy, however.) Although unclear, it appears the FBI and local law enforcement do not generally have access to NSA data, and therefore, there is significant value in reviewing how those types of agencies can access your data from Apple. With that in mind, let’s begin.

Requests for Information

Officially, requests for information go through subpoenas@apple.com (Legal Process Guidelines, p. 3), which is part of Apple’s Privacy and Law Enforcement Compliance Group. Only law enforcement personnel can use this email for subpoenaing information.

In addition to subpoenaing information, law enforcement can ask Apple to preserve existing information about an Apple ID account. Apple will preserve the information for 90 days, and upon request, for an additional 90 days (for a total of 180 days). This is compliant with 18 U.S.C. § 2703(f) statutory requirements. (p. 4-5)

However, if the request for information is an emergency, Apple, at its discretion, may disclose requested information without a search warrant. These types of requests go through exigent@apple.com. (p. 5)

If a law enforcement agency wants Apple to delete a a customer’s Apple ID account, the agency must provide a warrant or court order requiring the deletion. (p. 5)

Apple will tell its customers that a law enforcement agency is requesting information about their accounts, unless such a disclosure is prohibited by law, court order, or if Apple believes disclosure creates a risk of injury or death to identified individuals. (p. 5) This is generally true for delaying disclosure in emergency circumstances, as well. (p. 6)

Apple can provide law enforcement with information related to Apple Retail and Online Store transactions, iTunes Store transactions, use of gift cards, interactions with AppleCare and other customer support, as well unverified contact information linked to particular devices (p. 6-7).

Data on iOS devices

Apple will not extract data that resides on a passcode-locked iOS device if the device is running iOS 8.0 or later. Apple would need to have the passcode in order to retrieve the data. (p. 9)

Even if Apple can retrieve this data, it still cannot provide law enforcement with the device’s passcode. (p. 13)

If Apple can retrieve data from a device, it puts the data on an external FireWire drive (provided by law enforcement) and gives the hard drive to law enforcement. Apple does not keep a copy of the data it extracts. (p. 10)

Apple does not track geolocation (GPS data) of devices. (p. 14)

Data in iCloud

Apple says that it encrypts all iCloud customer data on its servers, and in the event that the data is stored on 3rd party servers, the decryption keys remain on Apple servers in the United States. (p. 8)

Law enforcement can retrieve basic iCloud subscriber information, such as name, mailing address, email address, and telephone number. Connection logs for the iCloud account, including IP addresses, are available and retained for up to 30 days. (p. 8)

Mail logs, which identify incoming and outgoing email transactions, sender and receiver email addresses, date and time, and IP addresses, are retained for up to 60 days. They are accessible with a court order under 18 USC § 2703(d). (p. 8)

Apple indicates that actual email messages are stored on Apple’s servers (and therefore accessible with a search warrant) so long as the customer doesn’t delete the email. Apple writes that, “Apple does not retain deleted content once it is cleared from Apple’s servers. Apple is unable to provide deleted content.” (p. 8) However, Apple does not disclose how long it keeps deleted messages.

Apple can, however, intercept users’ email communications upon receipt of a valid wiretap order (p. 14).

If a user chooses to keep other iCloud-related data in iCloud, Apple maintains this data on its servers, and the data is accessible in response to a search warrant. Examples of data users could choose to keep in iCloud are photos, documents, contacts, calendars, and bookmarks. (p. 8)

In addition to regular iCloud data, users can choose to back up their iOS devices to iCloud. If they do, those device backups may include photos and videos in the users’ camera roll, device settings, app data, iMessage conversations, SMS messages, MMS messages, and voicemails. (Note that developers can choose to exclude their apps’ data from iCloud backups, but without specifically programming this functionality into their apps, iCloud backup will back up the app data.) (p. 8)

Apple again says that “Apple does not retain deleted content once it is cleared from Apple’s servers.” It does not indicate how long the deleted data is stored on its servers. (p. 8)

Find My iPhone: Apple maintains connection logs to this service, as well as transaction requests to remotely lock or erase devices, for about 30 days. This information is available with a search warrant. Apple does not maintain maps or email alerts provided through the service. Finally, Apple cannot remotely enable the “Find My iPhone” service. (p. 9)

Other Data

Apple can also provide Game Center connection logs with IP addresses with a valid subpoena. A search warrant is required if the agency wants Apple to provide the specific games played. (p. 11)

Some device identification information, such as IP address and ICCID/SIM numbers are stored on Apple’s servers when a person activates a device or performs an operating system upgrade. This data is available with a subpoena. (p. 11)

Apple keeps logs from user interaction on My Apple ID and iForgot websites. Connection logs with IP addresses can be obtained with a subpoena. Transactional records can be obtained with a court order under 18 USC § 2703(d). Apple does not indicate how long it keeps these logs. (p. 11)

Apple has limited information it can share about FaceTime connections. FaceTime communications are end-to-end encrypted, so Apple cannot decrypt FaceTime data when it is in transit between devices. Apple does have call invitation logs that it keeps for 30 days, but the logs do not indicate whether the call is ever completed or how long a completed call lasts. (p. 12)

Unfortunately, Apple’s users voluntarily store much of the data they hold dear in iCloud, such as photos, emails, and contacts. Even if Apple makes it impossible to retrieve this kind of data from a locked phone, Apple can easily hand over much of the same data to law enforcement because users choose to keep a copy of the data in the cloud. If you use iCloud for email and contact syncing, and if you use iCloud Photo Library or even My Photo Stream, Apple can turn over your emails, the phone numbers of everyone you know, and all the photos you have ever taken to law enforcement — even if the company can’t unlock your phone.

Other data users may care about, such as iMessages, text messages, voicemails, and third-party app data is not normally accessible to Apple. But if a user chooses to use iCloud for device backup, Apple can extract that data from the backups users voluntarily store on Apple’s servers.

What are some best practices for people who want to continue to use iOS devices and preserve their privacy?

First, use a strong alphanumeric passcode for your iOS device. Do not use the four-digit passcode. Ideally, do not use the six-digit passcode. Choose a long, alphanumeric passcode with a mix of upper and lowercase letters, numbers, and symbols. This greatly increases the time law enforcement must spend trying to attack your passcode via brute force.

Even if Apple is able to create and install a version of iOS on your device that doesn’t self destruct after 10 failed passcode attempts or artificially slow the input speed of passcodes, a 30-character alphanumeric passcode is going to take a prohibitive amount of time to crack compared to a four-digit code.

Set your iOS device to erase all data with ten failed passcode attempts.

Keep your iOS operating system up to date and immediately update to iOS 9 if you are running iOS 7 or earlier (and have a device compatible with iOS 9).

Ideally, do not use iCloud. Period. It is easiest for Apple to provide law enforcement with your data when you store it in iCloud.

If you must use iCloud, bear in mind that each service you turn on (email, contact syncing, iCloud Photo Library, etc.) is a service that stores your data on Apple’s servers. The more services you use, the more data Apple can disclose.

DO use iMessage. This appears to be Apple’s most secure service. Apple says it cannot decrypt your iMessages, and there’s no mention of Apple keeping logs that track who communicates with whom.

Using FaceTime for audio and video calls could also be a good idea. Apple cannot decrypt the calls (which should mean law enforcement cannot, either), although Apple may be able to tell law enforcement who you have attempted to call in the last month (even if the company can’t tell the agency whether you successfully placed the call).

Do not use iCloud for backing up your data. Once you do, all the iMessages you send and receive (among other things) become accessible to Apple. Of course, when you exchange iMessages with others, they may choose to use iCloud for backups, which means your messages may be preserved in their accounts for Apple to access. Whether law enforcement can figure out who you’re communicating with and get a search warrant to retrieve those people’s backups is a different question.

Before you decide this means you should store backups in iTunes, keep in mind that forensics data software can decrypt encrypted iTunes backups. A best practice would be to encrypt the entire contents of the drive on which both your copy of iTunes and the device backups exist. Using a strong alphanumeric passcode for your backup also helps prevent the software from being able to decrypt the backup.

There you have it. If you feel I have provided incorrect information or that I have failed to cover an important aspect of Apple's guidelines, please let me know.

For anyone using FileVault on Mac OS X, the security benefits are obvious: FileVault encrypts the entire boot volume, which prevents an unauthorized user from reading any of the data. Historically, if you were to pull the hard drive out of your Mac and hook it up to another machine with an external enclosure, you could read all the data from the drive. A careful thief could copy the entire contents of your hard drive without you ever knowing—and without ever having to know your administrator password. FileVault prevents this.

The problem with FileVault, however, is that the computer needs to constantly use a decryption key to turn the encrypted data into readable data. It would be unrealistic to ask the user to constantly enter her password for the system to decrypt data, so this decryption key is held in RAM while the system is running. The decryption key will even remain in memory while the machine is asleep so that a user can simply bring the machine out of sleep without a password.

Unfortunately, it is possible for a hacker with sophisticated software to access the contents of your RAM (and therefore get the decryption key) if the hacker has physical access to your machine and your machine has a FireWire or Thunderbolt port. Thus, even though you have FileVault turned on, it is possible for a dedicated hacker to try to access your data. Luckily, there are some steps you can take to mitigate this security hole, though doing so requires trading away some conveniences.

I assume you've already enabled FileVault, but if you haven't, you can do so in the Security & Privacy section of System Preferences. You'll need to reboot your Mac after enabling FileVault so that the system can begin encrypting the boot drive (whether it's a spinning hard drive or an SSD).

Then (still in the Security & Privacy section), go to the "General" tab and choose to require a password after sleep or the screen saver begins. For maximum security, set it to immediately. Otherwise, set it to something reasonable for this. This ensures that when you put your machine to sleep, no one can immediately wake it up and begin using it.

The next thing you need to decide, and this is a critical decision, is how you want to handle hibernation mode. While your Mac is asleep, the decryption key is still in memory, and with the right software and hardware, a hacker could access this data. You need to tell your Mac to delete the decryption key while in hibernation mode so that it becomes inaccessible to the hacker. The question is whether you want to do this immediately upon entering sleep or after a period of time. Once the decryption key is destroyed, you will have to enter your password twice before you can use your Mac again. (The first time you enter the password, it allows the Mac to decrypt the RAM contents, and the second time is to access your account.)

To tell your Mac to destroy the FIleVault decryption key when in hibernation mode, open up Terminal and enter this command:sudo pmset -a destroyfvkeyonstandby 1

Alternatively, if you want to have your Mac stay in sleep mode (where you can simply wake your Mac up without having to put in the FileVault password to decrypt memory) for a period of time, enter these two commands:sudo pmset -a hibernatemode 3sudo pmset -a standbydelay XXX (where XXX is the number of seconds you want to delay the process; the default is 3 hours, which would be 10800 seconds).

There are a few caveats worth discussing here. First, while all modern Macs can go into hibernation mode, they don't enter the mode under all circumstances. Apple has a support article explaining the process your Mac naturally takes to enter hibernation mode. For example, unless you make the changes listed above, a Mac laptop will enter hibernation mode only after being asleep for three hours AND the laptop doesn't have its power cord plugged in AND there is nothing plugged into its ports. So, you can't make your MacBook, MacBook Air, or MacBook Pro enter hibernation mode if you've got a USB device plugged in, a Thunderbolt device plugged in, or external power. Those are Apple's rules. Even if you change the hibernation mode to occur after a one-second delay, you will need to disconnect everything to make your laptop enter hibernation mode. Desktop Macs are a little less strict: as long as you don't have external media (hard drives, DVDs, flash storage, etc.) mounted, these Macs can enter hibernation mode.

There are also many anecdotal reports that entering hibernation mode immediately (hibernatemode 25) causes kernel panics. I have not had that experience, but I will say that if I use hibernatemode 25 on my MacBook Air, I have a pretty limited period of time (less than an hour) where I can wake up my Mac without the machine completely turning off (and therefore shutting down in a less than graceful manner). So, if your security requirements allow it, consider using hibernatemode 3 with a reasonable delay until hibernation begins.

One other thing to consider is simply the time it takes to enter and wake from hibernation. As already mentioned, you'll have to enter your FileVault password twice to wake up from hibernation mode, compared to a single time to wake from sleep (or zero times if you're not requiring it at all, which is a serious security risk). When you enter or wake from hibernation, your Mac has to write the contents of your RAM to disk (and then read it again when waking). It will take much longer to do this if you have 16 GB RAM vs. 2 GB, and writing the data to a spinning hard drive is much slower than to an SSD. So, it may annoy you that it takes an extra 2-10 seconds to complete this process.

One advantage of using the firmware password is that if the SSD and the RAM are soldered (meaning, they cannot be physically removed from the machine), a firmware password prevents someone from booting your Mac from an external drive and creating an image of your encrypted disk. A hacker could take that encrypted disk image back with them and try to brute-force decrypt the data using GPU-accelerated software. If they can't boot from an external source or put the Mac into target disk mode to read the data, you have better protection. Unfortunately, if you have a Mac that has removable RAM, the firmware password can be disabled. Further, if your Mac has a removable hard drive or SSD inside it, a hacker could simply remove the drive to image it before replacing it in your machine.

Note: There is conflicting evidence on whether enabling the firmware password disables DMA mode on the FireWire or Thunderbolt port. From what I can gather, enabling the firmware password will prevent someone from putting the Mac in target disk mode but will not prevent the Mac from passing the contents of RAM, so you must still destroy the FileVault key on hibernate to fully protect yourself.

Paranoid advice: If you want the absolute best protection for your Mac at this point, here's the advice: only buy a Mac with a soldered SSD drive and soldered RAM, enable FileVault with a strong password, enable the firmware password with a strong password, and immediately shut down your computer whenever you are done using it.

when HFS+ was the cool, new kid on the Mac file system block.

My first Mac was a 512ke. That’s being a bit unfair: it was my dad’s Mac, and he let me use it. I was eight years old, and his 512ke was at least two years old (he had a previous 512k stolen and saved up again to purchase the enhanced version). At the time, we had two 400k floppy drives: one built into the 512ke and one connected externally. No hard drive. Apple did make a 20 megabyte hard drive at that time, but it cost a cool $1500. The interface was the Apple DB-19 connector, a zombie port not used again, once the Mac Plus could connect external SCSI hard drives. When the Apple HD 20 surfaced in 1985, Apple needed a file system for the drive, so they came up with HFS (Hierarchal File System). From what I’ve read, much of it was based on the Apple III file system.

The smallest file size on a disk formatted with HFS is 1/65,535 of the size of the hard drive. When a hard drive is only 20 MB, that math gives us a number less than the theoretical minimum of 512 bytes. That means you need two empty files to take up 1 kilobyte of space on your drive. Not too big a deal.

But what happens when you suddenly have a 2 GB hard drive? Now the smallest file size is 32 KB, even if you have a single byte of data in the file. It doesn’t take a mathematician to figure out that’s an unsustainable allocation size. So, Apple engineers needed a better file system. In January 1998 (almost 15 years after the introduction of HFS), Apple introduced HFS+ in the Mac OS 8.1 system update. The conventional name for HFS+ is Mac OS Extended, and HFS was renamed Mac OS Standard. Besides improving the minimum file allocation size, there are numerous changes and improvements in HFS+. There are numerous problems in HFS+, too. I won’t get into that discussion, but if you’re interested in more details, you should basically just read anything John Siracusa has written on the subject.

When Apple debuted HFS+ in the Mac OS 8.1 update, there were two caveats worth mentioning. First, Apple had transitioned from the 680x0 family of processors to the PowerPC processors in the mid 1990s. Mac OS 8 and 8.1 needed at least a 68040 processor (officially) to run, and 8.1 was the final version of Mac OS that ran on the 680x0 family of processors. 68040 Macs could use HFS+ formatted partitions, but they couldn’t boot from them. To this day, I have never been able to learn what the technical limitation was that prevented my Centris 610 from booting an HFS+ formatted volume. I can’t believe it’s the logic board’s ROM code, since all PowerPC Macs could boot from HFS+ volumes, but they debuted years before Apple wrote the code for the HFS+ system. The only thought I’ve had is that 68040 Macs couldn’t use virtual memory swap files from HFS+ volumes, and by Mac OS 8.1, swap files were an integral (if not required) part of the operating system. If anyone actually knows why 68K Macs couldn’t boot HFS+ volumes, though, I’d love to know.

The second caveat was Apple needed a graceful way of handling what a System 7 user (or Mac OS 8.0 user) saw when he or she hooked up an HFS+ formatted external hard drive to his/her System 7 machine. Since System 7 knew nothing of HFS+, the system would have asked the user to format the hard drive every time it was connected to the computer, and that would have been a terrible idea. So, Apple devised an HFS “wrapper” that would go around the HFS+ volume that the old System 7 computers could read. The wrapper volume would contain a single file entitled, “Where_have_all_my_files_gone?” You couldn’t see any of the files on the HFS+ volume, but you could open this single file on the HFS wrapper volume, and it would explain that you needed a computer running at least Mac OS 8.1 to be able to view the hard drive.

Years later, when Mac OS X debuted, HFS+ hung tough. Back in the days of 10.0, 10.1, and 10.2, Apple shipped Macs with both Mac OS 9 and OS X preinstalled, and HFS+ needed to be the format of choice. When Apple’s Disk Utility initialized partitions, it still included the “Where_have_all_my_files_gone?” HFS wrapper. That changed when Apple released Mac OS X 10.5, and no Mac shipping that required 10.5 or later had the wrapper.

I wondered, however, if it was possible that a Mac running Yosemite today could still have the wrapper on its disk, and it appears that the answer is theoretically yes: thanks to Mactracker, I found that the Mid 2007 iMac first shipped with Mac OS X 10.4.10, so if you got one of those Macs in August or September 2007 before Apple released Leopard in October 2007 (and bundled it on all new Macs), you got a machine with the HFS wrapper. Well, it appears that the Mid 2007 iMac is the only Mac that originally shipped with Mac OS X 10.4 that can still run the latest version of Mac OS X. That means if you upgraded the iMac to 10.5, then to 10.6 (and 10.6.8), you could install 10.10 on the system and still have the HFS wrapper on your hard drive.

Despite all that has been written about HFS+ over the years, I think it’s pretty cool (scary?) that a Mac in 2015 could be using a file system introduced in 1998, wrapped in a file system introduced in 1985.

Long ago, Apple decided to deprecate openssl. Since then, it has still released three new versions of Mac OS X, including three new versions of OS X Server. To this day, the web server in OS X Server remains apache2, and openssl continues to provide the encryption transport for the served sites. This makes no sense, since even in Yosemite, Apple only ships openssl 0.9.8za, which doesn’t include support for TLS 1.1, TLS 1.2, or their updated ciphers.

That’s right: you can’t build an OS X Server web server with anywhere near the security virtually any other server could provide years ago. Apple could have rewritten the web server to take advantage of SecTransport, Apple’s newer framework that Safari uses on Mac OS X and iOS to connect to other servers that support TLS 1.2. But, they didn’t, and it doesn’t appear that will ever change. I have to wonder, though: how long does Apple intend to charge $20 for a server package that allows corporations to create MDM servers for iOS devices, while allowing those servers to become more and more vulnerable to SSL exploits? We shall see.

In the mean time, I wanted to see if I could construct a virtual host file that would allow me to get a decent score at Qualsys SSL Labs’s SSL Test.The best score I’ve been able to achieve is B grade, with 100 points for the certificate, 70 points for protocol support, and 90 each for key exchange and cipher strength (this also assumes you’re using a commercial, rather than self-signed, certificate). More importantly, it is possible to construct a configuration file that supports only TLS 1.0 (the highest layer security OS X Server offers) and perfect forward secrecy on many browsers, with the notable exceptions of IE on Windows and old Java clients. While IE does support forward secrecy ciphers, it does not support any of the TLS 1.0 forward secrecy ciphers in openssl 0.9.8za.

This configuration file gives you forward secrecy as far back as Safari in Mac OS X 10.6.8 and in iOS 6, as well as modern versions of Firefox and Chrome on all platforms. My virtual host file is below. This file is in /Library/Server/Web/Config/apache2/sites/\ 0000_any_443_www.example.com.conf. This assumes your server name is www.example.com (which obviously will be different) and assumes your OS X Server configuration is on your boot volume (which is normal). In the config file below, replace “example.com” with the name of your domain. Note the “example” text in the certificate lines, as well. You’d need to use your certificates.

The SSLProtocol line tells apache to turn off all forms of SSL encryption and then to turn back on TLS 1.0. This prevents the client from requesting a weaker form of encryption, such as SSL 2 or SSL 3.

The SSLCipherSuite line lists a series of compatible cipher suites that the server can use to encode and decode the data. For anyone wondering, this is based off the Intermediate compatibility list at Mozilla’s Wiki. Many of the ciphers are not available to TLS 1.0 (they require TLS 1.1 or 1.2). Apache just discards the unavailable ciphers.

Then, when we add the SSLHonorCipherOrder line, apache will try to use the ciphers in the order they were written on the SSLCipherSuite line. The list of ciphers have already been written in the order from most secure to least secure, so we want to honor this order.

If you’re not sure how to edit this entire file, then just copy and paste those four lines. If any of the lines already exist in your file, you’ll want to overwrite them. I don’t generally recommend copying and pasting the lines, though, because there are other lines that could interfere with this setup. For example, if you have a line about SSLCompression being on or off, that will prevent your site from loading, since we’ve disabled SSL altogether.

What did we achieve?

Forward secrecy on modern Apple platforms, Android platforms, and Windows platforms running Firefox or Chrome. That means you could use OS X Server as an MDM server and actually have somewhat secure connections.

Avoided Heartbleed (because openssl on OS X is so old).

Mitigated BEAST to a large degree.

Eliminated POODLE attack by turning off SSL 3.

What’s missing?

Despite increasing our SSL security, there are some things we can’t do:

We can’t further mitigate against BEAST attacks, since we can’t use TLS 1.1 or 1.2.

We can’t completely eliminate weak, RC4 ciphers, unless we are willing to eliminate compatibility with IE 8 on XP or Android 2.3.

We can’t further mitigate against TLS downgrade attacks because we can’t use high enough levels of TLS to begin with!

We can’t use Strict Transport Security (HSTS), and we can’t use OCSP stapling.

I continue to hope that Apple will one day officially support a web server that uses TLS 1.2, but until that day comes, this is the most secure you can get. If you have any questions (or if I made errors), please get in touch.