Fiction (maybe): Who will refuse to break a secure element?

Apple is refusing to break an iPhone for the FBI. I believe that they are right to do so, but also that this position isn’t that easy to stand for everybody. So, here is a little fiction (well, I think it is fiction) about this.

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?


Fashion statement

I am just out of the Cartes show. A bit depressing, mostly because of the current circumstances and the number of “Absent exhibitors”. However, there werea few interesting highlights. One of them came in the Wearable and IoT conference track, in a presentation from Oberthur’s Olga Titova Candel about Wearable Payments for Fashion. The main […]


About PIN, the iPhone is about 20 years behind smart cards

I was astonished when I read this article on breaking the iPhone PIN. Some guy has built a device that can guess your iPhone PIN, and he is using a very old trick that was performed on cards years ago. Of course, the exercise is pointless; as noted in the original article, Apple can (will) […]


Did Apple just boost mobile security?

I have been working on mobile security for many years, and things haven’t moved much: justifying mobile security is always painful. Whyshould Ispend more money? There aren’t that many attacks! Some business use cases seemed like a good justification, but the economics are unclear and remain in the order of “if youget hacked, it could […]


The Off-Card Bytecode Verifier is fine, thank you!

REWRITTEN on 23 Nov. 2013. A few weeks ago, a friend sent me a link to the Cardis program, with the message “A bug in the verifier?”. Looking at the program, I saw a paper entitled Manipulating frame information with an Underflow attack undetected by the Off-Card Verifier, by Thales Communications and Security. This sounded […]


Twitter going feudal on security

I have recently experienced security issues with Twitter, as my account was in some way hacked. And I am not happy of the way Twitter handles this situation. First, here are the facts that I know: Two weeks ago, a got an e-mail from a colleague warning me that he just received a spam Direct […]


Experimenting NFC, things

Following my little NFC rants, I have kept on experimenting with Android NFC applications and reading about the Internet of Things (experimenting remains harder, here). The combination is trendy these days, as this week will see the launch of a new initiative in France with the French chapter of ACM SIGOPS (in French). I won’t […]


NFC Tags to Empower Users in The Internet of Everything Else

Here is a continuation to my ramblings about the solely private use of NFC tags. I have already mentioned that there would be many benefits in considering some tags as public goods, and now, I wll focus on tags to be associated to things, as owned by companies or individuals. I have pompously called this […]


NFC tags as Public Goods

I have now seen a number of NFC applications, and they all have something in common: they consider their tags as a private and exclusive property. They believe that they will be the only application using this tag. That may be true in some cases, where tags are deployed inside the premises of a company […]


POPWings again, after MWC

I now have two POPWings cards, as I made a new one with my professional contact information on Gemalto’s MWC booth yesterday. I also have had the ability to “pop” one or two persons, giving me a better experience of the application. So, I owe an apology to POPWings here. When I first tried their […]