The proliferation of always connected, increasingly smart devices had led to a dramatic increase in the amount of highly sensitive information stored in manufacturers’ cloud accounts. Apple, Google, and Microsoft are the three major cloud providers who also develop their own hardware and OS ecosystems. In this report, we’ll see how these companies protect their users’ highly sensitive information compared to each other.

Storage encryption

First and foremost, everything stored in the cloud is always encrypted, whether you are using an Apple, Google or Microsoft ecosystem. Information stored in the cloud is broken into chunks, and each chunk is securely encrypted. The encryption key are never stored on the same physical device as the data. Similar encryption techniques are employed by Google and Microsoft.

For example, in the case of Apple iCloud, the data chunks are stored on servers controlled by third-party service providers such as Amazon, Microsoft, AT&T, or the Chinese government. However, the encryption keys are physically stored on Apple’s own servers in Cupertino, making the data impossible to decrypt for anyone who gains physical access to any such server. This is what Apple has to say about storage encryption:

iCloud secures your information by encrypting it when it’s in transit, storing it in iCloud in an encrypted format, and using secure tokens for authentication. […] In some cases, your iCloud data may be stored using third-party partners’ servers—such as Amazon Web Services or Google Cloud Platform—but these partners don’t have the keys to decrypt your data stored on their servers.

The important thing is that, at least for some data, both the data and the encryption keys are under the cloud vendor’s control, making it possible for vendors to serve government requests. In addition, any user can access the data by signing in with the login and password (and, in most cases, passing two-factor authentication). We make tools for that: Elcomsoft Phone Breaker (Apple iCloud and Microsoft Accounts) and Elcomsoft Cloud Explorer (Google Accounts).

Storage encryption summary: user data in cloud services is encrypted, which protects against unauthorized physical access to underlying hardware. Vendors have the encryption key, and they also have full access to user data. Government requests are served.

End-to-end encryption

End to end encryption is used as an additional protection layer to safeguard some of the most sensitive information against unauthorized access even if the intruder knows the login and password to the user’s cloud account. Data protected with end-to-end encryption requires an additional secret to unlock the encryption key. In today’s implementations of end-to-end encryption used by Apple and Google that additional secret is the user’s user’s screen lock passcode, the very PIN code that one types to unlock their device. For Apple, which tightly controls its entire ecosystem, it could also be the password to a Mac computer. This is how Apple defines end-to-end encryption in iCloud Security Overview:

For certain sensitive information, Apple uses end-to-end encryption. This means that only you can access your information, and only on devices where you’re signed into iCloud. No one else, not even Apple, can access end-to-end encrypted information.

The important difference between storage encryption and end-to-end encryption is that no one, not even the cloud vendor, can access end-to-end encrypted data without knowing the secret. As a result, when serving legal requests, vendors could only return encrypted data without means to decrypt.

End-to-end encryption summary: user data is encrypted with storage encryption; on top of that, an extra layer of encryption is applied. Vendors do not have the encryption key, and they don’t have access to any end-to-end encrypted data. Government requests result in encrypted, useless data that cannot be decrypted.

How Apple, Google and Microsoft use end-to-end encryption

There are stark differences in how Apple, Google and Microsoft handle end-to-end encryption of user data.

Apple uses end-to-end encryption to protect the following:

• iCloud keychain (stored passwords for Web sites, apps, social networks, accounts and instant messengers; keys, tokens, certificates etc.)
• Cloud messages (SMS and iMessage)**
• Health data
• Home data
• Screen Time*
• Significant locations*
• Voice memos
• Apple Maps (searches, routes,
• Safari browsing history (since iOS 14)

What about the types of data marked with a *? Interestingly, some categories (at least Screen Time and Significant Locations) appear to be synchronized via a different mechanism, and are, in a sense, the only “truly end-to-end encrypted” types of data. We were unable to decrypt these categories even with the screen lock passcode.

For Messages specifically, Apple put the following note:

Messages in iCloud also uses end-to-end encryption. If you have iCloud Backup turned on, your backup includes a copy of the key protecting your Messages. This ensures you can recover your Messages if you lose access to iCloud Keychain and your trusted devices. When you turn off iCloud Backup, a new key is generated on your device to protect future messages and isn’t stored by Apple.

We were unable to verify this claim. However, if what Apple says is correct, one could technically access at least the Messages category even without access to the trusted circle and/or passcode.

So if there are “truly end-to-end encrypted” types of data, what about the rest? Those other types of data (except those marked with a *) can be accessed from any authorized device that is part of the “trusted circle”. In order to enroll the device into the trusted circle, one must provide a screen lock passcode or system password from any device that’s already in the circle. Effectively, this makes the encryption key unlockable with a passcode to any device in the trusted circle, and not just the one device that originated the data.

Technically speaking, these “other” categories are, in fact, protected only by Apple’s goodwill and their promise not to attempt decrypting the data. Since the encryption keys are based on the user’s screen lock passcode (whose typical length is merely 6 digits), should Apple decide to break in, in most cases it would be able to do so in a matter of minutes. This is precisely why we fail to recognize Apple’s “end-to-end encryption” as true end-to-end encryption.

Apple mentions several additional categories using end-to-end encryption. These are:

• Apple Card transactions (requires iOS 12.4 or later)
• Memoji (requires iOS 12.1 or later)
• Payment information
• QuickType Keyboard learned vocabulary (requires iOS 11 or later)
• Siri information
• W1 and H1 Bluetooth keys (requires iOS 13 or later)

So far, we’ve been unable to access any of these categories, with or without a passcode.

Interestingly, Apple is NOT using end-to-end encryption to protect FileVault 2 recovery keys, which potentially allows to access encrypted partitions on Mac computers.

• No end-to-end encryption: FileVault 2 recovery keys

Google, on the other hand, applies end-to-end encryption differently. Since the release of Android 9 in August 2018, Google has been encrypting cloud backups produced by Android phones running Android 9 or newer. The backups are encrypted with a key derived from the user’s screen lock passcode.

This is what Google has to say about end-to-end encryption of Android backups:

Easily restore your data or switch phones at any time. Your backup includes apps, app data, call history, contacts, device settings (including Wi-Fi passwords and permissions), and SMS.

Your backups are uploaded to Google and encrypted using your Google Account password. For some data, your device’s screen lock PIN, pattern, or password is also used for encryption.

App data can be any data that an app has saved (based on developer settings), including data such as contacts, messages, and photos.

In Android, backups contain certain types of data that are synchronized by other companies (e.g. Apple). By default, only the following categories are protected with end-to-end encryption:

• Android backups (requires Android 9 or newer)
• Text messages (SMS only) since these are not synced but stored in Android backups
• Call logs (again, since these are not synced but stored in Android backups)

In addition, users can set up end-to-end encryption to protect their Chrome passwords by choosing to encrypt the password database with a password instead of account credentials.

• Optional: Chrome passwords

The following information is NOT protected by end-to-end encryption, and is fully accessible to Google proper, law enforcement officials and just about anyone with valid authentication credentials:

• Chrome passwords (in default configuration)
• Health data (Google Fit)
• Screen Time (Digital Wellbeing)
• Location data (lots of it)
• Searches and Chrome browsing history
• All other information in the user account

Microsoft is not currently using end-to-end encryption to protect data. As a result, the following sensitive information may be exposed if an intruder gains access to the user’s authentication credentials:

• Messages (Skype conversations)
• Passwords (Edge Legacy, Edge Chromium)
• BitLocker recovery keys

More than just encryption

While storage encryption and end-to-end encryption of user accessible data are well documented, there are some types of data that never make it to the end user. Examples of such data include FaceTime logs, iCloud connection logs, Apple Store visits and a few more bits and pieces. These data are not made available to the end user. Law enforcement agencies can obtain the data by serving a government request. Neither of these data appear to be end-to-end encrypted.

Conclusion

As one can see, the three major cloud vendors approach end-to-end encryption in discretely different ways. While Apple appears to be moving more and more data under the end-to-end encryption umbrella, Google only allows end-to-end encryption for Android 9 and later device backups and, optionally, for Chrome passwords. Microsoft currently does not support end-to-end encryption at all, not even for passwords.