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.

Here is the sentence that first drew my attention:

A wallet you can lock. Stay safe with the Google Wallet PIN and with secure underlying technology.

This started again my love/hate relationship with Google. A wallet you can lock? It’s just brilliant, far better than anything else I have seen on the same topic. Where do they find these things? Now, let’s see how the rest fares, from their Security section.

Google Wallet stores your encrypted payment card credentials on a computer chip on your phone called the Secure Element.

Sounds good. The Secure Element is explicitly defined as a separate chip. I find it interesting that they feel the need to mention that the credentials are encrypted.

Think of the Secure Element as a separate computer, capable of running programs and storing data. The Secure Element is separate from your Android phone’s memory.

Once again, all of this sounds good. Very nice way to describe a smart card.

The chip is designed to only allow trusted programs on the Secure Element itself to access the payment credentials stored therein.

Uh oh! I really recognize my favorite Java Card firewall, isolating applications from each other. But I am a bit disappointed to read that the “chip” is designed to support that. Yes, the chip’s memory can only be accessed from the chip itself; but on the chip, the isolation is software-based.

Next step, the FAQ’s Security and Privacy section. Among basic questions about lost phones, there are two good questions related to secure elements:

• What is the Secure Element and how secure is it?
• Could a malicious application access my credit card on the Secure Element?

You can read the complete answers there. However, here is what should be the most important sentence, since it ends the answers to both questions:

There are multiple levels of protection for data stored on the Secure Element and it is protected at the hardware level from snooping or tampering.

Of course, smart card specialists know about all the terrible attacks hidden behind the “snooping and tampering”, and how to protect from them. But the sole mention of data is a bit disappointing.

The answers also mention several times that only the Google Wallet (and other authorized programs) can access the Secure Element, and that this access control is strictly enforced. This is good, and we all like the fact that access control is present.

Now, what’s missing? You may have guessed it from my “data only” disappointment. There is no mention of the fact that the secure element can do more than payment. So, Google, if you are reading this, I will go as far as writing the missing FAQ piece:

Can I use my Secure Element for protecting other assets?

Your Secure Element is a small but powerful chip, which runs its own applications to manage sensitive data. It can even host several applications, to provide different security-related services. Of course, since the access to the Secure Element is strictly controlled, only authorized developers can write applications for it. We have selected a limited number of partners, who provide applications that rely on the Secure Element to manage their security credentials. These offers include VPN application, secure authentication applications, and much more.

Hoping that it will become useful someday. And if you need more material on Java Card, just let me know.

On the technical side, these financial applications are all SIM Toolkit applications. This means that the applications are actually running on the SIM card, simply delegating the interaction part to the mobile. The interface with the remote servers is usually performed using SMS. Of course, this is a financial system, so the level of security must be sufficient to reduce fraud to a minimum.

Among the features that contribute to the security of the system, we have:

• Private network. Mobile networks are private, which makes them more the information that circulates on them more difficult to attack than the information that flows on Internet.
• Application running on the SIM, with some cryptography. SIM cards aren’t the most secure smart cards, but getting access to the data stored on a SIM card remains a long and difficult process, even for card evaluators. So, stealing/forging keys is hard.
• SIM Toolkit driver buried deep in the phone’s software. Since the application logic is on the SIM card, the mobile phone only provides a generic driver that manages the user interaction. This driver is handled by the phone’s baseband processor, which is usually not the most accessible piece of software. As a result, it is difficult to attack this interaction

Don’t get me wrong; I am not claiming that the system cannot be attacked. I am just claiming that the inherent security properties of SIM Toolkit applications are sufficient to guarantee the security of the small data transfers performed daily in developed countries. Now, if you want to use that system to buy a €500,000 house, I may want to take a very different stand.

Actually, the main reason for which this reasoning cannot be extended to developed countries is that SIM Toolkit definitely went out of fashion with the advent of smartphones. The STK text-based interface is simply not acceptable on today’s phones, where we expect fully interactive applications.

That means that our current status is quite different with our smartphone applications:

• Internet connectivity. Forget the private network, we are connected directly to the Internet, and that’s where we want to do our transactions.
• Mobile applications. We get our applications from our local application store, so protecting data (both in storage and in communication) is a bit hard.
• Customized interactions. We like our interactions to be customized for each application. In many cases, the interaction at least partly comes from Internet, and HTML5 is going to make this more common. Here, no need to attack a low-level device driver to get to our stuff.

So far, this is fear-inducing rhetoric. You should be afraid, because your applications are not secure. Yet, there aren’t that many attacks, and mobile transactions are becoming more common on phones. With the announced success of NFC and the announced Google wallet, the future is looking bright in 2011. One of the reasons is that secure elements are becoming fashionable again on smartphones. Another one is that Apple, Google, and the others are keeping a rather tight control on our devices, and the users feel safe. Jailbreakers pose a small problem, but this is marginal for transactions (hint: if a payment application gets hacked on your jailbroken phone, “losing” the phone and denying the jailbreak sounds like a good option). Overall, I have no problem performing transactions with my phone today.

The really interesting question is: Would I feel just as safe if one of the financial app became as popular as M-Pesa is in Africa? A financial transaction application installed by 50 million users in Europe and the U.S. would sure make a tempting target for hackers around the world, especially with the average balance of our accounts.

In such a case, I would be tempted to say that the various stakeholders would like to have a few additional guarantees. The smart card and security industries have some answers to that: Let’s perform Common Criteria security certifications on cards to prove their security! Let’s add a security layer in the phone to enhance its security! Let’s obfuscate this application to make it more difficult to hack!

All of these things work, and some of them even work well. Each counteremasure makes the cost of attacking the system slightly higher. But all these things provide incremental improvements, and they are definitely not disruptive. Disruption is more likely to come from the outside, from the “hundreds of start-up companies” promised by Eric Schmidt around NFC.

An example: Bump. It is not about NFC, but it is a mobile security measure that “makes connecting as simple as bumping two phones into each other”. It relies on humans to perform most of the security checks, and leverages this on Internet. This is the way to go as our mobile devices become more personal, as they get closer to actually representing us on the Internet; the human being who holds the device will need to participate actively in the security protocols, and not only be entering a code. Disruption will come from those who make the security experience better, not from those who make the mobile experience more secure.

First, the upcoming Nexus S will support NFC. This is big, because one of Google’s objectives (the main one?) with Nexus phones is to provide a reference design for Android devices. And now, NFC is part of that reference design (and of Gingerbread, Android’s upcoming release).

Then, Eric Schmidt talked about NFC. He started by a tag reading demo; of course, it didn’t work, because the network was too slow (typical in such environments). He gave a little description, and then switched to contactless payments, even mentioning the use of a secure element. Now, that was nice: Google is not only thinking about reading tags.

Later in his speech, he mentioned how the combination of location-aware, tag reading and mobile payment could change the way commerce works, using terms that would have been largely appreciated at a NFC conference.

To please me even more, he even threw in a mention of voluntarily provided information, which is of course limited by the fact that Google is an unlikely VRM supporter. But yes, if the system is able to integrate that I am actually looking for a new pair of pants, it may provide me with very useful information.

Finally, Eric Schmidt went as far as mentioning security several times, and even saying that “the technology has to be secure,” which is nice to hear for many of my colleagues. And his reason is rather simple: there is money involved directly, so security is a must.

One of the best parts of his vision is to remind us that mobile is personal, secure, and an aggregating technology. So when we think about what we can do with NFC or whatever we add to that, we need to figure out what it brings to the big picture, and how the technology can best be used with all the other mobile technologies.

OK. Enough ramblings. Here is an approximative transcript of what he said about Android (a bit raw, so if you have 10 minutes to spare, take a look at the video):

Q: There has been a lot of talk about a new operating system aligned with a potential hardware device, coming from Google. We’d love to see it if that was possible.

ES: OK. How about instead a demonstration of some software.? So, I happen to have here an unannounced product that I carry around with me. That is an Android device, and we have taped over its origin.

You see, this is a placemark [showing a placemark panel, obviously with a tag in it]. The neat thing you could do with this new technology called NFC (which stands for Near Field Communication), and we think that Android should support that. It’s been around for a while, by the way.What you do is, these are chips that are embedded in things, eventually in clothes to prevent people from stealing. These chips are senders, and we are incorporating support for the reader-writer, so the way it works is you turn this thing on and you basically just tap like that, and it tells you, in the particular case, where you are.

What’s neat about the NFC chip is that the whole notion of location takes an entirely new meaning, because now I can just tap, I don’t have to take a picture, I don’t have to scan a barcode.

Q: So this is basically gonna be in presumably many of the new Android phones.

ES: It’s actually gonna be in the new operating system called Gingerbread that comes out in the next few weeks. So we think that the overall mobile market, which is already extraordinarily excited about these payment systems, will benefit from having those, because it is a secure element, and the secure element really is very hard to steal if you will.

Q: So, the secure element allow you basically to do payment.

ES: One way to think about this is that is that it will replace your credit card. The term of the industry is called tap and pay. The theory of the case is that you will be able to take these mobile devices from everybody, to walk into stores, do commerce, you’ll be able to figure out where you are, again, with your permission, all that kind of stuff.

Q: Effectively, bump for everything.

ES: Yes, bump for everything, and eventually, replace credit cards.

Q: It also turns the phone into a much more powerful form of identification.

ES: It’s an example of what I have talked about for a while, which is “mobile first”. I don’t think that people understood how much more powerful these mobile devices are going to be than the desktops. You think of the desktop machine as having all this power and tremendous network, beautiful screen, but because these things are so highly personal, and because they are location aware, …

Q: They also have network

ES: Yes, with LTE networks coming to the United States, first in the world, for a change, roughly in January-February around the country, it is a really really god day for mobile.

Q: With the theme of points of control, it strikes us that one of the points of control is having tons and tons of credit card numbers; Amazon has tons, Paypal has tons, Apple has a lot. Combined with this kind of technology, it strikes me that it could possibly change the game. Do you agree with that, and where does Google stand with that.

ES: Well, we see ourselves as a technology provider in this, we’re not trying to compete in those spaces, but ultimately this technology is personal, it’s secure, and it’s an aggregating technology. So it makes sense that you put everything in it and carry it around. It has to be secure, because it’s obviously going to be used as money repository.

Q: But still, if you are doing payment, somebody is doing the payment processing.

ES: There are industrial partners for all the initiatives in the industry, with very sophisticated payment processors, and regulations, and all

Q: You expect to be a partner there rather than …

ES: Absolutely.

Q: But you do have Google checkout.

ES: Remember, Google checkout is just a piece of this. Payment processors do something different. They actually deal with the merchants, moving the money around, you know with fraud and so forth. The reason why this NFC dhip is so interesting is because the credit card industry thinks that the loss rate is going to be much better, because they are fundamentally more secure. And ultimately, the money that brings us all to this wonderful venue comes out of commerce in one way or another; advertising in Google’s case. My guessis that there will be 500 new startups in the mobile payment space as these platforms emerge, with all these new and interesting things that we can do.

Q: What I’ve been fascinating by is the idea that this is gonna change is shorten the loop between the search and acquisition of a product. Right now, we see this in buying an app: you search for the app and then you buy it on the phone. But this really makes it possible in the real world. You can search for something, and …

ES: But, forget search. Well, I shouldn’t exactl say that, but that’s a joke. Imagine I am walking down the street, and instead of typing my search, my phone is giving me information all the time, and it happens to know that I need new pants or something. You can imagine all sorts of linkages between autonomous search, and location-based search, where you are, where your favorite stores are, what your preferences are, again if you opt in to these situations. Its likely to drive a very very large mobile commerce business and mobile e-commerce business. And the scale of commerce is 14 trillion dollars, which is the global GDP, so some large amount of money is to be gotten in these new platforms over time.

Q: And you can really how this could be a fabulous tie with groupon, because it tells you that there is a crowdsourced offer.

ES: Again, if you look at groupon as a very good example of a very very successful local merchant, they today use e-mail as their primary acquisition mechanism, but they have competitors which are using other techniques. What we know is that people like a deal.

Q: One last question on Android. What are you dissatisfied about with regard to the platform, and what do you think need to be fixed, if anything.

ES: You score Android against the historically leader in the space, which is the iPhone, and I do this as a proud former board member of the Apple world. There is a set of things that the iPhone really did a brilliant job of bringing out in a closed system. Brilliant design, the app store, the platform and so on. So most people judge Android by how we are doing relative to that. And it’s clear that from a reach, choice, and so forth, we are in great shape. The next real focus is at the applications layer. So I think that if I want to be critical, I would have liked to put more emphasis on the application side earlier. It’s hard, because remember, the application decisions are made based on developers, who do it based on volume. So you have to establish volume first, which is something that I think we have done with Android. And for all of these players at the third-party level, and again I know that we have a lot of developers here in the audience, it’s fundamentally about the math of the platform. So we understand platforms very well, we think that Android will be, if not the leading platform, a leading platform.

Q: That brings up a question that I have been thinking about. As there are more and more applications, it becomes a search problem to figure out which one to choose, and that’s one of your sweet spots. But you don’t have some of the same mechanisms for identifying the best apps. How are you thinking about search as a competitive advantage as the application space grows, where the Android Market is the Google of the app space?

ES: We don’t think of it as a competitive edge, we just try to do it better, and the competitive environment will win. As a comment, I think people are obsessed with the competitive landscape, where what they should really be focusing on is how much bigger the market is getting. And because it’s, including the leadership that you guys did with Web 2.0 so many years ago, this is a very large universe, that is getting much larger very quickly, bringing more and more people into it. So the competition is healthy, what’s really happening is you’re growing the market. So with respect to the applications and application search, there’s all sorts of interesting ways of doing that; Admob, for instance, is doing on the order of a billion ad impressions a day now, and that kind of information, in theory, is useful as part of a search problem, because ads have a real value, and we really believe that. There are many many ways in which the information people are using, usage patterns, can be used to provide better choices. But you’re correct that these markets tend to overcorrect; They have millions of apps, whatever, but then ultimately, the leaders emerge.

Q: One of the things that Steve and Apple did right is the about divorce from the carriers, the ability to pretty much say: I don’t want your stuff on my phone. Do you think that Android is ever going to be truly free of that …

ES: I certainly hope so, in the sense that the Android model is different from the Apple model, very distinctly on pretty much every point. It’s open system vs. Closed system, and closed systems have their advantages, and open systems have their advantages. Google made a bet on open systems. We are willong to let the vendors, the carriers, and so forth, set their pricing, set their distribution terms, and so forth. I think that ‘s the right model.

A security and forensics company has recently looked into mobile applications, and got some coverage.

Theyhave been studying banking and payment applications, from major banks and service like Wells Fargo and Paypal, and they found some flaws. Nothing big so far, as flaws are to be expected. The problem is that finding flaws was quite easy:

• One of the application stores the username and password in cleartext on the device. Twitter doesn’t want apps to do that, so one would think that banking apps are more careful than that.
• Another one of the appplications opens a SSL connection, but it doesn’t check the certificate, which makes it vulnerable to man-in-the-middle attacks, for instance on WiFi networks.

These flaws have been there forever, and we have identified them from the very beginning of mobile security evaluations. The SSL flaw is particularly common, and I am surprised to see it today, now that even browsers have a tendency to perform checks on certificates.

The only satisfying thing is that the reviewer hasn’t reported any backdoor into these programs. A few years ago, such back doors were very common, allowing developers to use their applications in “debug mode”.

If these backdoors have disappeared, we are moving in the right direction. But still, we are moving slowly.

The idea of the Mobile Telephony API is that we now live in a connected world, and that we want to get applications that would allow us to control the way our device communicates, for instance to setup conference calls within an application.

In standard MSA 1.0, we get the ability to use HTTP(S), or Web Services. We also have the ability to use SATSA to communicate with a SIM card that, in turn, would have SIM Toolkit applications written in Java Card. This is interesting to work on mobile telephony and payment, but how can we do better with dedicated APIs?

The Payment API is a common front-end that is complemented by payment adapters, representing a particular payment method. It is oriented towards micropayment, and the idea is to use a simple API, and to put all the configuration information in the JAD file (that’s interesting for a security guy, because JAD files are not signed, so there may be some opportunities to get free stuff).

The Mobile Telephony is used to control calls, receive event changes of network state (YES, an application may know when we are roaming!), and a few more things. There is even a package that allows an application to get information about the money that a call costs; this is quite surprising, because this is well known for being very difficult to figure out. Like the payment API, the API is very simple, which looks quite good.

The real problem is mobile support for these optional APIs. We’ll have to see if support picks up with the maintenance release.

The questions about security remain, especially on the European market. If the American market is targeted (or any other non-EMV market), than it’s a fine product, which just has a buzz deficit when compared to Square. Now, if we are talking about Europe, then there is a “Chip & PIN” issue. At least in France, for many people who don’t travel abroad, swiping and signing would at least be an extremely awkward way to pay. And legally, I am not sure that such transactions would be valid.

And also, some European banks (for instance, in France) have (too?) high expectations regarding security, that are unlikely to be met by a bunch of Apple and Android devices that can be jailbroken or hacked. I asked to get the newsletter from these guys, and I’ll keep you posted.

The basic idea is to allow anybody (with an iPhone, but Android and Blackberry to follow, if we can believe the open positions) to accept a payment using any U.S. credit card. The iPhone application has a few advantages:

• With a very small attachment, you can swipe the card. Without it, you just need to enter the card data on the phone.
• The customer signs on the iPhone, with a finger.
• If the customer is a Square member, the vendor gets a picture for the authentication.
• They even do automatic loyalty by mentioning the fact that a customer is a return customer.

Easy payments for individuals is just great. It allows me to accept payments from anybody with a payment card, and that’s really new. It makes NFC and mobile payment look sooo 20th century; who really wants another way to pay?

In the meantime, the smart card payment guys read the latest Ross Anderson paper.

A few thoughts about Square after the jump.

First, some good news: if you are in the USA; it is quite likely that Square will eventually work with your contactless card. It may even become the default interface if iPhone’s and other devices, if NFC becomes widely available. Why? Simply because in the USA, contactless cards simply emulate the magstripe, so the application can work in almost the same way: swipe and sign. The only difference is here the swiping gesture.

In Europe and elsewhere, things won’t be that easy, because we use the more complex EMV transactions, also known as “Chip & PIN” in some countries. I am not sure that Square can’t be done with EMV, but here are a few factors that will make it more difficult:

• Keys on payment terminals. In EMV, terminals perform cryptographic computations, which means that they need to store keys. Of course, such keys could be managed on the SIM card, but this is not obvious.
• PIN entry. In EMV, a PIN is entered on the terminal, and actually, a lot of the terminal’s security requirements are related to the fact that the terminal is a PED (PIN Entry Device). And well, an iPhone is far from being an acceptable PIN entry device.

Of course, there are security issues around Square, not all equal:

• When signing up, one need to provide the iPhone’s unique identifier. If this thing is used for security purposes, it gets me worried that somebody may use a jailbroken iPhone to mount attacks.
• If somebody uses a fake application, they may get an image of my magstripe and my signature. Well, anybody in a restaurant can do the same thing, so I guess that the risk is limited.
• What if somebody pays me with a fake card? Who is liable for that? This is insurance matter, but it becomes one of my concerns if a become a “merchant”, and Square’s service agreement does not promise much.

Finally, I may be wrong, but from the information I have, I think that we (in France) will have to wait quite a while before being able to use Square in our country. Hopefully, we will find a workaround, and we will be able to get a similar application, because this is just something that I would love to use.

What about Ross? Well, I’ll get back to that soon, after discussing it around.

To make things short, the service works by opening an account, putting money on it, and then sending SMS’s to Obopay containing the phone number of whoever you want to send money to and an amount. Easy, huh? Of course, there is a catch: you can send money to people who don’t have an Obopay account, but they will need to open one to get the money.

Obopay offers other interesting services in the U.S., like the ability to obtain a prepaid MasterCard that makes it easy to spend the money on your account, as well as family accounts, which can be associated to several cards (one for each kid), which can be loaded as needed by the parents.

Doesn’t it sound too good?

Something I don’t like about this solution (and many others) is that it forces me to have a specific account, which contains some money. I don’t like the fact that we all need an Obopay account, a Paypal account, and many more in which our money just sits.

On the other hand, I like the simplicity of the solution, which could become a great way to exchange money with friends. And of course, the advantage of having a dedicated account containing a limited amount of money is evident in terms of security, as it limits the amount of a possible theft.

Nokia seems to primarily target countries with a limited banking infrastructure, focusing on people who have a mobile phone but no bank account. This also sounds very good, as this is a huge market, in which Nokia remains a dominant actor (Apple may cause them trouble in the smartphone business, but Nokia still reigns on low-cost phones). And anyway, some guy in the PR states that the service will be available “on virtually any mobile phone”, including non-Nokia phones. In parallel, Nokia is building a network of Nokia Money agents that will be used to deposit/withdraw cash from a Nokia Money account.

I would have loved to talk about the solution’s security, but I don’t have enough information to state anything interesting. I would just like to know how payment orders are confirmed, because sending a SMS from a phone is rather simple for any application.

Finally, I am wondering how this will be integrated with applications. If all it takes is sending a SMS, then triggering a payment may be extremely simple. Wouldn’t you love adding a little “Pay with Nokia Money” icon on your next iPhone application?

I guess that we will all need to watch for this at next week’s Nokia World event.