The iPhone is a secure device, so the best way for Apple to refuse breaking the phone is to claim that they can’t do it. Here is the story line:

• The iPhone includes a secure element.
• The security code is stored and verified in the secure element.
• The phone encryption key also is stored in the secure element.
• In order to get that key from the secure element, the security code must be presented.
• We don’t know how to break into the secure element, so we can’t bypass that security mechanism.

It is a bit technical, but it is true from the point of view of Apple and “standard” developers. But the last statement (we don’t know how to break into the secure element) may not work for everybody.

First, regardless of the secure element, physical attacks are feasible, and there are many kinds. Some of them, like power analysis, do not even require to destroy the chip in any way. Of course, many such attacks will require “opening” the secure element to expose the chip and do other things that may destroy it. In the case of the FBI, who wants to attack a single chip that they must not destroy, this is not really nice.

Then, the secure element on the iPhone is most likely based on Java Card. This means that it is possible to load applications on it. Of course, Java Card includes security measures, so the application needs to be a malicious one; well, there are malicious applications around, and here, we are working with software. This makes a big difference. Now, here is the checklist for FBI:

1. Get Apple to provide 100 secure elements configured exactly like the targeted one, with the card management keys (required to load an app).
2. Get some hacker to develop a malicious application that gets the value of the code, or bypasses the code check, or gets the value of the encryption key, …
3. Establish an attack procedure and test it on actual phones.
4. Get Apple to provide the management key for the targeted phone.
5. Run the attack on the targeted phone, and bingo!

This is slightly different. Apple still needs to collaborate, but not at the same level. Step 4, in particular, is about providing a key that can only be used on the terrorist’s phone. Step 1 is a bit more difficult, since Apple needs to support hacking efforts on their phones.

There is also a need to get a hacker. This may not be as difficult as it sounds, because as far as I know, the population of hackers capable of doing such a thing is small but includes:

• security evaluators working at labs who necessarily have ties to NIST (very close to NSA, here), or to the equivalent in another country;
• people working in various companies and institutions who depend greatly on government contracts;
• and a few real hackers, who could do some work for money, fame, or both.

All these people, for various reasons, are far more vulnerable than Apple, and it is quite likely that FBI will be able to find one to cooperate with them.

And then, what’s left? Well, the security of some secure elements and Java Card implementations are really really good, and they will be protected against more attacks, performed by most attackers. Luckily, the handful of guys who may be able to break these implementations may not be willing to do so.

Still, it sounds like a good idea to support Apple here.

Final thought

This is now a problem that every security professional/company who is involved in the development, testing, or evaluation of consumer or industrial devices must think about: How will I react to injunctions from law enforcement? Should I make sure that I don’t know how to hack my device?

The attack consists in detecting whether the PIN code is right or wrong (here, through some change in display intensity) before the number of false PIN presentations is incremented in persistent memory. Upon detection, the phone is immediately rebooted, and the increment doesn’t happen. Yeaahh!!

Similar attacks have been performed on smart cards for over 20 years. The attackers used to monitor the power consumption when verifying a PIN, and an increase in consumption (indicating a memory write) would indicate the beginning of an EEPROM update, and the right time to cut power.

The solution? Most people typically look for complex implementations, but the general solution is much simpler: just increment your counter of failed attempts before actually performing the comparison (and ensure that the actual memory update has been performed, not just cached). Then, no need to worry about power cuts and reboots, since the attacker will not get additional attempts.

I will tend to believe that most (all?) Java Card implementations of the OwnerPIN class include such countermeasures, providing adequate protection for a PIN comparison. And by the way, since recent iPhone’s include a Secure Element, this is where the PIN comparison belongs.

For more details on PIN attacks and countermeasures, you can read my tutorial JC101-12C: Defending against attacks.

With iPay, Apple just proved to many people that mobile security can have a favorable economics. By embedding a biometric sensor and putting their critical credentials on an embedded secure element, they have been able to negotiate a lower transaction fees on their payments and save millions in the future. Mobile security brings millions instead of just boring geek stuff? Now, that’s innovation.

Of course, the security of the iPhone 6 must live up to these high expectations. As much as the latest announcements bring a boost to mobile security, the announcement of a hack allowing a guy to steal a phone and use it “illegally” has the power to bring us back to the dark ages.

Wired claims that the intention behind the change is to force customers to buy two SIM cards: one for their iPhone, and one for their iPad. That’s an interesting hypothesis, and a possible new use case for SIM cards: use several formats to force customers to have several SIM cards. Of course, the network operators are accused of trying to get customers to get a mobile data subscription for each device they own.

Such a use of a SIM card certainly does not seem to make any good to anybody, and would reflect really short-term thinking from MNOs, and even worse thinking from SIM vendors if they started pushing this as an advantage of the multiple factors. Here are a few good reasons why this idea is bad:

• First, an iPhone is a phone, and an iPad isn’t. This means that, once you remove your SIM card from your iPhone, you can’t be reached on your mobile number. Unpractical, for the least.
• Then, an iPad is not as small as an iPhone, and it is much more likely to be used in WiFi than 3G, at least as long as there will not be a pricing plan that makes the use of 3G affordable.
• The contacts in the Mini-Sim and Micro-SIM are in the same configuration, which means that it is easy to build an adapter from Micro-SIM to Mini-SIM. So, if you have a Micro-SIM, you are able to use it in a device that requires a standard SIM card.

So, this definitely isn’t the killer use case that we are looking for. Locking in final customers, through formats or anything else, does not look like a promising use case for a product, and we should rather think of making these customers’ lives easier.

It sure sounds bad at first. worms are not the kind of beasts that we want to see on our mobile devices. And a worm that gets on your phone on shared WiFi connections could lead to a lot of paranoia in California’s Starbucks.

Now wait, this worm only attacks jailbroken iPhones. As such, it is at least good news for Apple, as it makes people realize that jailbreaking your iPhone may have consequences, not all good. By extension, it is good news for all the actors that rely on Apple’s closed platforms and on other similar platforms.

Now, this is not the last bit of it. Even for Apple, the news aren’t all good. The worm doesn’t affect all all jailbroken iPhones, but according to Wired,

jailbroken iPhones whose owners have installed SSH and neglected to change the default root password, “alpine.”

If this is right, it sounds quite scary. Does it really mean that iPhones are Unix-based machines that all have the same root password, that the user can’t change (unless they jailbreak their phone)? For me, that entails that if a hacker is able to somehow very very partly jailbreak an iPhone using a worm or other malware, they won’t encounter much resistance from root passwords.

This is really bad news, and could be by itself a good reason to jailbreak an iPhone. And of course, it makes me wonder about the protection of my own (Linux-based) Android phone.