iOS

New Privacy Features in iOS 14

About Bruce Schneier

I am a public-interest technologist, working at the intersection of security, technology, and people. I’ve been writing about security issues on my blog since 2004, and in my monthly newsletter since 1998. I’m a fellow and lecturer at Harvard’s Kennedy School and a board member of EFF. This personal website expresses the opinions of neither of those organizations.

iDevices finally get key-based protection against account takeovers

iDevices finally get key-based protection against account takeovers

For the past couple of years, iPhone and iPad users have been relegated second-class citizens when it comes to a cross-industry protocol that promises to bring effective multi-factor authentication to the masses. While Android, Windows, Mac, and Linux users had an easy way to use the fledgling standard when logging in to Google, GitHub, and dozens of other sites, the process on iPhones and iPads was either painful or non-existent.

Apple’s reticence wasn’t just bad for iPhone and iPad users looking for the most effective way to thwart the growing scourge of account takeovers. The hesitation was bad for everyone else, too. With one of the most important computing platforms giving the cold shoulder to WebAuthn, the fledgling standard had little chance of gaining critical mass.

And that was unfortunate. WebAuthn and its U2F predecessor are arguably the most effective protection against the growing rash of account takeovers. They require a person logging in with a password to also present a pre-enrolled fingerprint, facial scan, or physical security key. The setup makes most existing types of account takeovers impossible, since they typically rely solely on theft of a password.

Developed by the cross-industry FIDO alliance and adopted by the World Wide Web consortium in March, WebAuthn has no shortage of supporters. It has native support in Windows, Android, Chrome, Firefox, Opera, and Brave. Despite the support, WebAuthn has gained little more than niche status to date, in part because of the lack of support from the industry’s most important platform.

Now, the standard finally has the potential to blossom into the ubiquitous technology many have hoped it would become. That’s because of last week’s release of iOS and iPadOS 13.3, which provide native support for the standard for the first time.

More about that later. First, a timeline of WebAuthn and some background.

In the beginning

The handheld security keys at the heart of the U2F standard helped prepare the world for a new, superior form of MFA. When plugged into a USB slot or slid over an NFC reader, the security key transmitted “cryptographic assertions” that were unique to that key. Unlike the one-time passwords used by MFA authenticator apps, the assertions transmitted by these keys couldn’t be copied or phished or replayed.

U2F-based authentication was also more secure than one-time passwords because, unlike the authenticator apps running on phones, the security keys couldn’t be hacked. It was also more reliable since keys didn’t need to access an Internet connection. A two-year study of more than 50,000 Google employees a few years ago concluded that cryptographically based Security Keys beat out smartphones and most other forms of two-factor verification.

U2F, in turn, gave way to WebAuthn. The new standard still allows cryptographic keys that connect by USB or NFC. It also allows users to provide an additional factor of authentication using fingerprint readers or facial scanners built into smartphones, laptops, and other types of hardware the user already owns.

A plethora of app, OS, and site developers soon built WebAuthn into their authentication flows. The result: even when a password was exposed through user error or a database breach, accounts remained protected unless a hacker with the password passed the very high bar of also obtaining the key, fingerprint, or facial scan.

As Google, Microsoft, key maker Yubico, and other WebAuthn partners threw their support behind the new protocol, Apple remained firmly on the sidelines. The lack of support in macOS wasn’t ideal, but third-party support from the Chrome and Firefox browsers still gave users an easy way to use security keys. Apple’s inaction was much more problematic for iPhone and iPad users. Not only did the company provide no native support for the standard, it was also slow to allow access to near-field communication, a wireless communication channel that makes it easy for security keys to communicate with iPhones.

Poor usability and questionable security

Initially, the only way iPhones and iPads could use WebAuthn was with a Bluetooth-enabled dongle like Google’s Titan security key. It worked—technically—but it came with deal-breaking limitations. For one, it worked solely with Google properties. So much for a ubiquitous standard. Another dealbreaker—for most people, anyway—the installation of a special app and the process of pairing the keys to an iPhone or iPad was cumbersome at best.

Then in May, Google disclosed a vulnerability in the Bluetooth Titan. That vulnerability made it possible for nearby hackers to obtain the authentication signal as it was transmitted to an iPhone or other device. The resulting recall confirmed many security professionals’ belief that Bluetooth lacked the security needed for MFA and other sensitive functions. The difficulty of using Bluetooth-based dongles, combined with the perception that they were less secure, made them a non-starter for most users.

In September, engineers from authentication key-maker Yubikey built a developer kit that added third-party programming interfaces for WebAuthn. The effort was valiant, but it was also kludgey, so much so that the fledgling Brave browser was the only one to make use of it. Even worse, Apple’s steadfast resistance to opening up third-party access to NFC meant that the third-party support was limited to physical security keys that connected through the Lightning port or Bluetooth.

NFC connections and biometrics weren’t available. Worst of all, the support didn’t work with Google, Facebook, Twitter, and most other big sites.

iPhones and iPads finally get key-based protection against account takeovers

iPhones and iPads finally get key-based protection against account takeovers

For the past couple of years, iPhone and iPad users have been relegated to second-class citizenship when it comes to a cross-industry protocol that promises to bring effective multi-factor authentication to the masses. While Android, Windows, Mac, and Linux users had an easy way to use the fledgling standard when logging in to Google, GitHub, and dozens of other sites, the process on iPhones and iPads was either painful or non-existent.

Apple’s reticence wasn’t just bad for iPhone and iPad users looking for the most effective way to thwart the growing scourge of account takeovers. The hesitation was bad for everyone else, too. With one of the most important computing platforms giving the cold shoulder to WebAuthn, the fledgling standard had little chance of gaining critical mass.

And that was unfortunate. WebAuthn and its U2F predecessor are arguably the most effective protection against the growing rash of account takeovers. They require a person logging in with a password to also present a pre-enrolled fingerprint, facial scan, or physical security key. The setup makes most existing types of account takeovers impossible, since they typically rely solely on theft of a password.

Developed by the cross-industry FIDO alliance and adopted by the World Wide Web consortium in March, WebAuthn has no shortage of supporters. It has native support in Windows, Android, Chrome, Firefox, Opera, and Brave. Despite the support, WebAuthn has gained little more than niche status to date, in part because of the lack of support from the industry’s most important platform.

Now, the standard finally has the potential to blossom into the ubiquitous technology many have hoped it would become. That’s because of last week’s release of iOS and iPadOS 13.3, which provide native support for the standard for the first time.

More about that later. First, a timeline of WebAuthn and some background.

In the beginning

The handheld security keys at the heart of the U2F standard helped prepare the world for a new, superior form of MFA. When plugged into a USB slot or slid over an NFC reader, the security key transmitted “cryptographic assertions” that were unique to that key. Unlike the one-time passwords used by MFA authenticator apps, the assertions transmitted by these keys couldn’t be copied or phished or replayed.

U2F-based authentication was also more secure than one-time passwords because, unlike the authenticator apps running on phones, the security keys couldn’t be hacked. It was also more reliable since keys didn’t need to access an Internet connection. A two-year study of more than 50,000 Google employees a few years ago concluded that cryptographically based Security Keys beat out smartphones and most other forms of two-factor verification.

U2F, in turn, gave way to WebAuthn. The new standard still allows cryptographic keys that connect by USB or NFC. It also allows users to provide an additional factor of authentication using fingerprint readers or facial scanners built into smartphones, laptops, and other types of hardware the user already owns.

A plethora of app, OS, and site developers soon built WebAuthn into their authentication flows. The result: even when a password was exposed through user error or a database breach, accounts remained protected unless a hacker with the password passed the very high bar of also obtaining the key, fingerprint, or facial scan.

As Google, Microsoft, key maker Yubico, and other WebAuthn partners threw their support behind the new protocol, Apple remained firmly on the sidelines. The lack of support in macOS wasn’t ideal, but third-party support from the Chrome and Firefox browsers still gave users an easy way to use security keys. Apple’s inaction was much more problematic for iPhone and iPad users. Not only did the company provide no native support for the standard, it was also slow to allow access to near-field communication, a wireless communication channel that makes it easy for security keys to communicate with iPhones.

Poor usability and questionable security

Initially, the only way iPhones and iPads could use WebAuthn was with a Bluetooth-enabled dongle like Google’s Titan security key. It worked—technically—but it came with deal-breaking limitations. For one, it worked solely with Google properties. So much for a ubiquitous standard. Another dealbreaker—for most people, anyway—the installation of a special app and the process of pairing the keys to an iPhone or iPad was cumbersome at best.

Then in May, Google disclosed a vulnerability in the Bluetooth Titan. That vulnerability made it possible for nearby hackers to obtain the authentication signal as it was transmitted to an iPhone or other device. The resulting recall confirmed many security professionals’ belief that Bluetooth lacked the security needed for MFA and other sensitive functions. The difficulty of using Bluetooth-based dongles, combined with the perception that they were less secure, made them a non-starter for most users.

In September, engineers from authentication key-maker Yubikey built a developer kit that added third-party programming interfaces for WebAuthn. The effort was valiant, but it was also kludgey, so much so that the fledgling Brave browser was the only one to make use of it. Even worse, Apple’s steadfast resistance to opening up third-party access to NFC meant that the third-party support was limited to physical security keys that connected through the Lightning port or Bluetooth.

NFC connections and biometrics weren’t available. Worst of all, the support didn’t work with Google, Facebook, Twitter, and most other big sites.

Apple’s new Screen Time Communication Limits are easily beaten with a bug

iOS 13 on an iPhone 11 Pro.

Enlarge / iOS 13 on an iPhone 11 Pro.
Samuel Axon

A bug in iOS 13.3 allows children to easily circumvent the restrictions their parents or guardians set with the Communications Limit feature in Screen Time. Apple has said it plans to fix the problem in a future software update.

The iOS 13.3 update released earlier this week added the ability for parents to whitelist contacts for their kids to communicate with. Kids need the parents to input a passcode to talk to anyone not on the list, with an exception made for emergency services like 911. It was the flagship feature of the update.

Yesterday, CNBC published a report detailing a bug that allowed kids to easily circumvent the restrictions. It turns out that when contacts are not set to sync with iCloud by default, texts or calls from unknown numbers present children with the option to add the number as a new contact. Once that step has been taken, they can communicate freely with the contact.

Further, kids with access to an Apple Watch can ask Siri on the Watch to text or call a number on the paired iPhone, regardless of whether the number is whitelisted or not. CNBC notes that this does not work when Downtime, another parental control feature, is enabled, however.

Apple offered the following statement to CNBC as news of the issue spread:

This issue only occurs on devices set up with a non-standard configuration, and a workaround is available. We’re working on a complete fix and will release it in an upcoming software update.

Apple has faced a generally rocky launch with iOS 13 and its numerous subsequent smaller updates, such that the company has made plans to change how it tests and builds new software internally to avoid future problems. Our earlier report on that noted that sources close to Apple said the company had been happier with its software since the release of iOS 13.2. However, iOS 13.2 had a widespread memory issue affecting background apps, and iOS 13.3 now has this new ScreenTime issue, meaning the two recent feature updates each came with a major bug.

Apple has released more bug fix updates since the iOS 13 launch than is usual after an annual update.

Apple releases macOS Catalina 10.15.2, iOS, and iPadOS 13.3

The 2019 16-inch MacBook Pro with the lid closed

Enlarge / The 2019 16-inch MacBook Pro.
Samuel Axon

As has become a custom, Apple has simultaneously released software updates for nearly its entire suite of consumer products today—including iOS 13.3, iPadOS 13.3, macOS Catalina 10.15.2, watchOS 6.1.1, tvOS 13.3—and an update for HomePods. All updates should be available to all users by the end of the day.

iOS 13.3 and iPadOS 13.3 together make for arguably the most notable update. They introduce yet another feature that was originally pitched by Apple as part of iOS 13 but was delayed before that annual update’s release this September: Communication Limits in ScreenTime. Parents can now whitelist contacts for their kids’ accounts, which allows them to block their kids from communicating with anyone outside the list on Apple-made apps like Messages and FaceTime, with exceptions for emergency calls and services like 911.

These two updates also introduce new layouts for certain publications in Apple News+, adds a new interface for liking or disliking stories in News, and expands on the news options and coverage in the Stocks app.

macOS Catalina 10.15.2 gets most of these same News and Stocks features, plus the restoration of the column browser view in Apple Music and the addition of Apple Remote app support for the Music and TV apps on Macs.

Additionally, tvOS 13.3 is a somewhat notable update for recent Apple TV streaming boxes. It includes a slight homescreen redesign for video previews as well as a change to the top shelf of content visible on that screen. Whereas it previously showed you the next items in your TV app queue while that app was selected, it will now recommend new content there by displaying trailers and previews. However, an option has been adding to settings to let you switch back to the old way.

Today’s HomePod update improves voice recognition for family members and “allows individual family members to enable/disable personal requests.” watchOS 6.1.1 is a minor update that contains unspecified bug fixes and optimizations. Apple also released a security update for watchOS 5 for users who do not have an iPhone capable of running iOS 13, as watchOS 6 requires the latest iPhone software.

All of the updates today also have a plethora of bug fixes and security updates for their respective platforms, which you can find in Apple’s release notes below.

iOS and iPadOS 13.3 release notes

iOS 13.3 includes improvements, bug fixes, and additional parental controls for Screen Time.

Screen Time

  • New parental controls provide more communication limits over who their children can call, FaceTime, or Message
  • Contact list for children lets parents manage the contacts that appear on their children’s devices

Apple News

  • New layout for Apple News+ stories from The Wall Street Journal and other leading newspapers
  • Easily like or dislike stories with a tap

Stocks

  • Stories from Apple News are now available in Canada in English and French
  • Continue reading with links to related stories or more stories from the same publication
  • Breaking and Developing labels for Top Stories

This update also includes bug fixes and other improvements. This update:

  • Enables the creation of a new video clip when trimming a video in Photos
  • Adds support for NFC, USB, and Lightning FIDO2-compliant security keys in Safari
  • Fixes issues in Mail that may prevent downloading new messages
  • Addresses an issue that prevented deleting messages in Gmail accounts
  • Resolves issues that could cause incorrect characters to display in messages and duplication of sent messages in Exchange accounts
  • Fixes an issue where the cursor may not move after long-pressing on the space bar
  • Addresses an issue that may cause screenshots to appear blurry when sent via Messages
  • Resolves an issue where cropping or using Markup on screenshots may not save to Photos
  • Fixes an issue where Voice Memos recordings may not be able to be shared with other audio apps
  • Addresses an issue where the missed call badge on the Phone app may not clear
  • Resolves an issue where the Cellular Data setting may incorrectly show as off
  • Fixes an issue that prevented turning off Dark Mode when Smart Invert was enabled
  • Addresses an issue where some wireless chargers may charge more slowly than expected

What the newly released Checkra1n jailbreak means for iDevice security

What the newly released Checkra1n jailbreak means for iDevice security

It has been a week since the release of Checkra1n, the world’s first jailbreak for devices running Apple’s iOS 13. Because jailbreaks are so powerful and by definition disable a host of protections built into the OS, many people have rightly been eyeing Checkra1n—and the Checkm8 exploit it relies on—cautiously. What follows is a list of pros and cons for readers to ponder, with a particular emphasis on security.

The good

First, Checkra1n is extremely reliable and robust, particularly for a tool that’s still in beta mode. It jailbreaks a variety of older iDevices quickly and reliably. It also installs an SSH server and other utilities, a bonus that makes the tool ideal for researchers and hobbyists who want to dig into the internals of their devices.

“I expected it to be a little rougher around the edges for the first release,” Ryan Stortz, an iOS security expert and principal security researcher at the firm Trail of Bits, said in an interview. “It’s really nice to be able to install a new developer beta on your development iPhone and have all your tooling work out of the box. It makes testing Apple’s updates much much easier.”

Another benefit of Checkra1n is that it promises to work reliably on a wide array of hardware. Those models include devices from the iPhone 5s all the way to the iPhone X running iOS 12.3 or later. (At the moment, the Checkra1n beta doesn’t support the iPad Air 2, first generation iPad Pro, and fifth generation iPad. Users may also experience problems when running this beta on the iPhone 5s, iPad mini 2, and iPad mini 3. These incompatibilities will likely be fixed in time, as new Checkra1n updates become available.)

Also significant, Checkm8-based jailbreaks will work permanently on these devices. Unlike most jailbreaks, which exploit vulnerabilities in iOS, Checkm8 targets a flaw in the Boot ROM, which is the first code that runs when an iDevice is turned on. This code is burned into the hardware itself and can’t be patched. This is the reason Checkra1n will work with every new release of iOS over the lifetime of a vulnerable phone.

This means that people can continue to enjoy the benefits and security fixes available in new iOS releases without losing the ability to jailbreak their devices (new versions of iOS inevitably fix jailbreaking vulnerabilities). This is a far cry from jailbreaks over the past decade that forced users to run outdated versions of iOS. The last time a jailbreak targeted the Boot ROM was in 2010 when hacker George Hotz (aka Geohot) developed one for the iPhone 3GS and iPhone 4.

Checkra1n is also helpful because it makes it painfully obvious it has been used. A large Checkra1n logo displays during bootup. And the home screen will include the Cydia and Checkra1n apps, neither of which appear when an iDevice runs normally.

And like all Checkm8-based jailbreaks, Checkra1n requires physical access to the vulnerable device and a reboot, which means user data and Touch ID and Face ID are inaccessible until the next time a PIN is entered to unlock the device. This means that remote exploits aren’t possible.

The bad

Checkm8-based jailbreaks, including Checkra1n, come with some notable limitations that many jailbreaking enthusiasts consider deal-breakers. First, Checkm8 doesn’t work on iDevices introduced in the past two years, specifically those with A12 and A13 CPUs. That limits the jailbreak to older devices, most of which—but not all—are no longer sold in retail outlets.

The other major limitation is that Checkm8-based jailbreaks are “tethered,” meaning they don’t survive a reboot. Each time the device is restarted, it must first be connected to a Mac—eventually Windows versions of Checkra1n are expected—and jailbroken all over again. Untethered jailbreaks, by contrast, are much more popular because they allow iDevices to boot normally, without being connected to a computer each time.

Another drawback to any jailbreak is that it’s an inevitably risky thing, since it unbinds an iDevice from the protections and quality assurances Apple has painstakingly built into iOS over more than a decade. Apple warns here that jailbreaking can “cause security vulnerabilities, instability, shortened battery life, and other issues.” The stakes are raised further by the beta status of Checkra1n. The Checkra1n website warns: “This release is an early beta preview and as such should not be installed on a primary device. We strongly recommend proceeding with caution.”

Then there are the risks of error by inexperienced users who are drawn to Checkra1n’s reliability, robustness, and its promise to work—on older devices, anyway—in perpetuity.

“The biggest threat from Checkra1n is how easily a non-technical user can jailbreak their device, which then leaves it vulnerable to additional attacks,” Christoph Hebeisen, head of security research at mobile security provider Lookout, said. One protection that Checkra1n deactivates is the iOS sandbox, which cordons off sensitive parts of iOS from the apps it runs. The risk is heightened by the ability of jailbroken devices to run any app. Normally iPhones and iPads can run only apps that are available in the App Store, which vets submissions for security and stability before allowing them in.

One other warning: the site checkrain[.]com is an imposter site that installs a malicious profile onto the end-user device. Readers should steer clear.

The (more subtly) bad

There’s a more subtle threat posed by Checkra1n’s ease in almost completely unpairing a device from the protections that have made iOS arguably the world’s most secure OS. As noted earlier, it would be hard for someone to use this jailbreak maliciously against someone else. But Stortz, the iOS security expert at Trail of Bits, said that Checkra1n’s release demonstrates just how powerful it could be should its capabilities fall into the wrong hands.

“The threat is more real now because a sophisticated exploit is available to everyone,” he said. He went on to theorize cases of attackers reverse-engineering Checkra1n and combining its jailbreaking capabilities with rootkits or other malicious code. All attackers might need to use this malicious Checkra1n-derived jailbreak is very brief access to an iDevice. This type of attack could covertly steal text messages, login credentials, cryptographic keys, and all kinds of other sensitive data. These attacks would be particularly effective against iPhones and iPads that don’t use fingerprints or face scans for unlocking. He explained:

Checkm8 allows someone to undermine the trust of the iOS secure boot chain. Checkra1n makes it easy to do. It’s true that checkra1n puts a nice logo on it and installs development tools, but that doesn’t need to happen. Someone will modify checkra1n to remove the logo and install a rootkit instead. [In that scenario] having a PIN-only passcode is a poor choice. You’ll pick up your phone [after Checkra1n is surreptitiously installed] and unlock it, allowing the rootkit full access to your personal data.

It has been possible to create this type of malicious jailbreak since late September, when the Checkm8 exploit became public. But that kind of attack required huge amounts of time and skill. Now, Stortz said, “no one would do that when Checkra1n exists and is so well done.”

The take-away from the sort of scenario Stortz hypothesizes is this: for journalists, dissidents, and other high-value targets who use iOS devices and can afford to, it’s best to use hardware that has an A12 or higher CPU. An iDevice introduced in the past two years will ensure that it’s safe from Checkra1n-derived attacks at border crossings, in hotel rooms, or in other situations that involve brief separations.

For iOS users who can’t afford a newer iPhone or iPad, using Touch ID or Face ID can lower the chances of malicious jailbreaks since users can be tipped off that something is amiss if the iDevice unexpectedly requires a PIN. And whenever the device has been out of the user’s control, even briefly—or users suspect anything else is amiss—they should reboot it.

This level of scrutiny is probably overkill for most users of vulnerable iPhones and iPads. Unfortunately, for users belonging to more targeted groups, these precautions are a natural consequence of a post-Checkra1n era.