What? This includes my kids’ Honor-branded phones, and as far as I know, a significant portion of the kids in their middle school, as Honor has been proposing phones with a great value for a few years, and they are popular in that population who are usually not getting the top-of-the-line models.

I could also have titled this blog more provocatively as “Google denies basic security to their customers,” “Donald Trump throws millions of kids in hackers’ hands,” or “Evil Americans exercise extra-territorial power over people around the world.” There are plenty of opportunities here to be angry, but the problem is elsewhere.

There is here a trust and liability issue. When I buy an Android phone, I expect some service from the vendor, but I also expect some services from Google. In my professional life, I am battling for improving IoT security, making updates mandatory and secure, among other things. Until now, this was a battle against slackers and profiteers, but today, politics is getting in the way. If hackers benefit from this, who can be held liable? Is this just Huawei? Doesn’t Google share some responsibility for stopping their support? My kids have done nothing, for sure.

Most comments seem to emphasize that Google dealt a big blow to Huawei, but Google has also dealt a big blow to themselves: Huawei didn’t cut my kids’ updates, Google did. This really has some consequences on the Android model: When you buy a phone with Android, you introduce a dependency between you and both the device vendor and Google, and you will be a collateral victim if their relationship turns sour. This almost sounds like Apple; when you get an iPhone, you belong to Apple, but at least, only to Apple.

It makes me rethink seriously my dependency on Google, so it’s time to take some strong decisions. I will switch my family streaming subscription from Google Play Music to Spotify, just to make sure that my kids still enjoy music on their unsupported phones. And if this madness continues, I will move them to Huawei’s app store as well…

The article demonstrates how easy it is to hijack’s someone’s phone number. And of course, once this is done, you can get the authentication SMS and get in. The article points to a solution that really makes your phone a second factor, such as the Google Authenticator application. It generates a one-time password every 30 seconds, without depending on any communication: you simply need to run the app.

But SMS-based second factor isn’t that bad, and it is definitely better than nothing, and Wired fails to tell us why:

• In the case of a big leak of a few million passwords, any second factor works to protect you against the robots who will check that the password is working before putting it for sale.
• However, it doesn’t protect you well from that guy who is chasing YOU. In that case, the SMS is definitely easier to hack than other methods that require physical access.

Unless you are famous or you are being unfriendly to hackers, it is quite unlikely that you will be targeted personally by a hacker (at least these days, this may change in a few years…).

So,if you are using SMS-based 2-factor authentication, you may think about other methods if they are available (Fido is great). But if you don’t use 2-factor authentication at all, please start by using this SMS thing, it will protect you at least against the major leaks that we are seeing these days.

Wondering which services you can protect with 2-factor authentication? Check this page and realize that most of the sites you use can be protected.

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.

The reasoning goes on with a comparison of the security merits of a credit card number stored on Passbook and a real card. Read the paper for the details, but an obvious comparison is that a real card is easier to lose/steal (because we stick to our phone more than we stick to our wallet), and also easily accessible (the phone will be at least somehow encrypted, requiring some technical skillls to access the card numbers). In addition, credit cards are easily replaceable, and they usually entail a zero liability insurance for the end-user.

What surprised me is the conclusion: “convenience wins in the consumer mind”, and more specifically, “convenience may win out over a little risk”. From the risk analysis, my feeling is that using Passbook is actually less risky than carrying real cards, and even if one doesn’t agree with that, zero-liability means that, for the customer, the risk is the same: zero.

Although we agreee that security is a way to reduce risk globally, there are many different ways to reduce risk for every actor. For the end-user, in that specific case, the key aspect is the zero-liaility insurance offered by the credit card company. If there is a major security flaw in Passbook, there may be a problem between Apple and credit card companies, but end users should remain largely unaffected. The worst thing that could happen to them is to lose the convenience of Passbook if credit card companies deny to Apple the right to store card numbers in it.

Just another friendly reminder that our job as security providers is not just to randomly increase security of things, but to actually reduce the level of risk for an actor, which should be our customer. Banking smart cards are sold to banks, not to end users, and there is not reason to change this relationshp when the cards are dematerialized into software: our customers are the banks, and we need to reduce their risk (which, hopefully, can help them offer a zero-liability insurance to their customers at a better cost).

Disclosure: I just finished reading Brice Schneier’s Liars and Outliers: Enabling the Trust That Society Needs to Thrive, which may explain why I have this unusual high-level view of security. Good book, by the way.

The fun part is of course that the FBI is now going after Google to find a solution to this problem, asking them plenty of information about the device and about the use that the bad guy did of it. Most of the things that they are requesting may indeed be in Google’s hands, if the bad guy is not very smart: e-mails, text messages, Web history, contacts, etc. Unless of course, the bad guy has been using non-default apps.

But it gets even more interesting when we get to the part asking for “Verbal and/or written instructions for overriding the ‘pattern lock’ installed on the” phone. Since this is a Samsung phone, does Google have this information? What if there is no way to override this? I am not sure that the people who design security protocols for Trusted Execution Environments and/or for Secure Elements actually include a backdoor everywhere. After all, in some cases, not having a backdoor makes security easier to enforce. Of course, in this particular case, the pattern lock can be overridden by the owner’s Google account, so I guess that Google has the information.

But, in a more general term, it brings us back to the question of the “right” security level. If there is an open market for TEE/SE applications, the “superlock” application definitely sounds like a good one. It will certainly benefit our privacy, and it will just as certainly annoy anybody who wants to violate someone’s privacy, with the same debates as usual regarding the limits of the law. I am not completely sure where I stand on this, since I don’t like the idea of letting police look at my information, but I don’t really like the idea that my wonderful security products are used by bad guys to protect their content from police Of course, we can trust most bad guys to be like regular guys and make blatant security mistakes, but sometimes, it just won’t work. Oh well, we’ll see, and it should be interesting.

Well, that may change. researchers for the University of Pittsburgh’s RFID Center for Excellence have invented a on/off switch for cards, that simply requires you to put your finger on a specific spot on a contactless card to allow it to work (see a picture here).

Comment on the various articles around the topic are quite typical, ranging from the “This is very dumb because it is unpractical” to the “You have to give up some practicality for security”, and all variants in the middle. I would have liked to see the inventors’ arguments, but I haven’t found a reference to a paper/report.

From previous experience, user experience often wins, in particular when, like with contactless cards, practicality is a selling point of a technology.Also, since the idea is to protect your cards in your wallet, I would think that it is easier for security-conscious to use wallets that include some kind of wire mesh or other wave-blocking technology. Since the on/off switch requires you to actually get the card out of your wallet, it is more or less equivalent, and it only annoys security-conscious people. The other guys will still be able totap their wallet (until, of course, they start having several contactless cards in there, in which case this optimization may not work any more).

This invention does not look flexible enough. The threat of someone performing transactions without you knowing is not significant enough to justify this kind of generalized measure for payment cards. On the other hand, it sounds much better as privacy-protecting technology on ID cards, since an ID card. Ensuring that the data about your identity will not leak from your wallet is interesting, and since an ID card is typically pulled out of the wallet before to be used, the technology is not an annoyance any more. But of course, in research like in politics, the fears associated to credit card theft remain more powerful than those associated to privacy protection (although identity theft is gaining traction).

You can read the papers to get all the details on this attack. Basically, they have been smart enough to use a salt before hashing the PIN value to avoid brute-force attacks. However, they haven’t been smart enough when they decided to store the salt just next to the hashed PIN value. Of course, with these two pieces of information, it takes at most 10,000 attempts to find the PIN (just check the video of the attack if you doubt that this is a very small number).

But hey, it’s just an attack/vulnerability. Maybe the first one, most likely not the last one. What surprises me most is that all these wallet programs insist on Common Criteria certifications of the Secure Elements, very complex certification programs for SE applications, and yet they leave behind this kind of basic vulberability in the mobile application, whose security does not seem to be formally evaluated by anyone. At least, the SIM/eSE security specialists should be able to sleep well for a while: they are unlikely to be the best target for real attackers, with such low-hanging fruit.

What really puzzled me from the zvelo guys is their analysis of what needs to be done. Their first step is correct: this PIN (which is used to open the wallet, not to validate a transaction) should be stored and verified in the Secure Element. Now, what surprises me more is their next statement:

Basically, by moving the PIN verification into the SE itself, this might constitute a “change of agency” responsible for keeping the PIN secure. The fear is that Google might no longer be responsible for the security of the PIN, but rather the banks themselves. If this is in fact the case, then the banks may need to follow their own policies and regulations regarding ATM PIN security which obviously, and rightly, receive a great deal of scrutiny.

Now, this doesn’t look good. First, about the ownership of the SE. I am not sure what the deal between Google and the phone vendors is, but I would say that the SE is owned either by Google or by the phone vendor. After all, they are the ones who control the SE’s master keys.

Even if we don’t consider that, Google would not store the PIN in somebody else’s application. I am sure that they have their own app in the SE, that they would use this app to manage their little PIN. This is very easy to do with Java Card, and I am sure that they can develop this addendum easily.

Finally, as mentioned above, this PIN is not an ATM PIN, because it is not linked to a specific transaction. When you enter the PIN, it opens the wallet, but it does not authorize a transaction. It is the digital equivalent to putting a four-digit combination lock on your wallet (which is exactly what Google is claiming).

Nevertheless, the story remains interesting, and it reminds us of the complex ecosystem behind NFC payments. For instance, did the banks consider the Google PIN in their risk analysis of the Google wallet? Well, if they did, the Google PIN is now a bit weaker. It is not broken, though: a combination of malware and physical access to the phone is still required to make a fraudulent transaction.

To conclude on a positive note, the end of the zvelo article is a good list of recommendations. If you keep your phone clean and locked, the bad guys will have to find a better vulnerability.

Just imagine a world where a company can deploy its preferred network security application on all devices, while benefitting from SE-based security, or where innovative ccompanies ccan design security applications that rely on SE applications. Sounds good? Well, too good, because this is just not our world, at least not today.

There is an obvious reason for this: the “owners” of these eSE’s, whether they are phone vendors (Nokia, Samsung, …), wallet vendors (Google, Isis, …), or others, are not opening their devices. It is therefore very difficult to load applications on them. The most open environment that I know is in France, with AFSCM, but as far as I know, this is an operator-dominated, SIM-based world, which has a long history of managing resource-constrained SIM cards.

So, why is it different with the relatively new players who own/manage embedded Secure Elements? My gut feeling is that memory limitations are part of the problem, if not the entire problem. If you think of an iPhone, memory is almost infinite: if you are missing memory, simply remove one or two songs out of the 2000 that your phone contains, and it fits. On an eSE, things are different: think of a 64k SE. If it already contains 4 applications, each using 15k of memory, there is no way to add a fifth one. The numbers are here very different, and the choices are much more limited. I don’t think that many iPhone users ever get to the point where they need to eliminate content that they really need to fit another content that they also really need. On a card, no such luck. And for a platform manager, this is very difficult to deal with, so their priority will be to get their applications on this, or at least the applications that can bring them immeddiate and/or obvious returns.

The problem is very different with a Trusted Execution Environment (TEE). Applications are here stored in the phone’s main memory, so there is no shortage of memory. This means that, for TEEs, it should not be too hard to actually use app stores or similar infrastructures. For eSE’s, we will need to work a bit more in order to achieve the same result.