Skip to content

A new use for the (micro) SIM?

One of the numerous articles from Wired commenting Apple’s new iPad is about its SIM card. Rather than using traditional SIM cards, they will be using a Micro-SIM form factor, which is slightly smaller than a traditional SIM card.

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.

Posted 06 February 2010 ‡ Comments (0)
§ News
° Tagged: ,

Greetings from China

The Java Card Forum is meeting in China this week. This is a first for me, so I can’t tell how much Beijing has changed in the past 10 or 15 years, because I don’t know how it used to be. So, here is what I have seen (from a very naive point of view):

  • Consumerism has hit in full force. Advertising is everywhere, including subway handles. Brands are also very present; I can see very large Cartier and Dolce&Gabbana storefronts from my room.
  • Police is not very visible. We see a few police cars around, a few officers here and there, but not more than in the U.S. .
  • Internet is (almost) present. Of all the sites I use daily, Twitter and Wired are the only ones absent. Internet is a bit slow (filtering?), but nothing unacceptable.

Basically, from a naive European view, Beijing is just another modern Asian city, with no Twitter support (for those who haven’t been there in a few years, there are high-rise buildings everywhere, and more cards than bikes, even on Tiananmen Square).

However, we also have interesting information about China, from this Google attacks. The attacks may have been directly state-sponsored, or sponsored by an enthusiastic defender of Chinese interests, I am not sure that we will ever know. In fact, I am almost sure that I don’t care.

The real thing that we should all realize is that nothing we do on Internet can be kept private from our states. We may want to hail the Chinese hackers for their great expertise, but I am sure that there are quite a few states that would be able to perform the same hacks. And if we get similar attacks coming from the U.S. or from one of their allies, would Google take the same position to protect a few people, especially if they are labeled as “potential terrorists”? I don’t know, but I would not bet on it.

This situation gets me a bit worried about cloud computing. If we start putting more and more information in the cloud, it means that we make this information available to people who have enough money to pay for a zero-day vulnerability and a few hackers.

Now, here is a question for the security people: If we use smart cards (with or without Web servers), trusted execution environments, and other client-side “strong” security solutions, how much more difficult canwe make it for these hackers?

I have no answer to that question. One thing I know is that we can’t do anything against server-side bugs that make data accessible. That leaves us with many other means of protection, but how efficient are they?

Posted 26 January 2010 ‡ Comments (1)
§ Discussions § News
° Tagged: ,

OMTP TR1 gaining support in the UK

Yesterday, I attended the Mobile Barcamp on Security at ETSI. Even though attendance was rather low, the exchanges were interesting, and the unconference format made them even more interesting. It was my first Barcamp, and I really enjoyed it.

Among the news and messages spread during the meeting, one struck me, even though it is not all that new. OMTP has issued the OMTP TR1 set of recommendations for an Advanced Trusted Environment. These recommendations are quite significant, and include a full Trusted Execution Environment (TEE) that is able to run trusted code on the device.

The interesting news comes from the UK Home Office. Back in May 2009, when the latest version of OMTP TR1 was issued, the Home Secretary issued a congratulation note, encouraging the use of TR1, with numerous quotes from various crime fighting units, as well as executives from Vodafone and Motorola. So far, nothing really big.

Things have gotten better in October, when the Crime Reduction unit from Home Office issued the Contactless mobile phone payments - Best practice guidelines document. The document is interesting, proposing a few classical security guidelines, like mandating PIN code for transactions over £10 or requiring a single number to report the theft or loss of a mobile, and of course to disable any payment app related to the mobile, together with the mobile subscription.

But the interesting point is here that this document somehow assumes that the mobile device follows the OMTP TR1 requirements, and therefore include a trusted environment. Here is the paragraph:

It is expected that user verification (for example a passcode) for contactless mobile transactions above the prevailing payment industry agreed maximum contactless value (currently £10) will be required so as to add an additional level of security to that already provided in the mobile device. (1)

Of course, the (1) is a reference to OMTP TR1, through the previously cited endorsement by the Home Office. Having TR1 “already provided in the mobile device” would be really interesting, and a step in the right direction for security. Now, let’s just wait for and hope that this actually happens in the mobile payment deployments in the UK and elsewhere.

Posted 21 January 2010 ‡ Comments (0)
§ Mobile Security
° Tagged:

Racing the neighborhood

For years, I have wanted to use a racing game that would provide realistic driving in my neighborhood. Well, The first game like that is coming soon on Ovi Store. This is a 2D top view, which reminds me of the original GTA (I loved that game, even though it didn’t have the 3D experience that made the latest versions big hits). Not quite what I was expecting, but definitely a good first step.

I now hope that Google will be up to the challenge, and that a few guys at Google are using their “free” time to develop such a game using Google Maps data. I guess that, if these things don’t come, it must mean that 3D programming is indeed difficult; or it could be that gamers expect full 3D game with nice models of the buildings, trees and scenery. For me, the idea is not to have the best 3D experience with the exact buildings (although that would be nice too). The precision I want is on the road itself and on the simulation, because I know the road very well in real life.

Another reason may be price. The use of Google Maps is free, but I am not sure how much Google would charge to build a game with Google Maps data. After all, all these mapping companies are supposed to be worth a lot of money.

This kind of ideas are funny, because they remind us that execution is sometimes very hard. I am sure that some game executives already had the idea to develop such a game. But it hasn’t happened yet, and I am still waiting to be able to race up La Gineste with a few friends from the good ol’ time. Until then, I will keep racing in San Francisco or London with two kids sitting on my lap.

Posted 17 January 2010 ‡ Comments (0)
§ News
° Tagged:

One less flaw in secure USB keys

We all know by now that some German testers have broken certified USB keys.

Breaking a secure product is not big news. Breaking a certified product is less common, so it makes the news. Now, the reactions are worth analyzing, because it is very hard to figure out what certification is about, in particular when related to security. Certification schemes are not perfect, but they still have plenty of advantages.

I am not going to describe the attack. All we need to know is that (1) the crypto algorithm in the USB drive was not borken, and (2) the authentication has been broken, but not by a brute force attack.

Now, about the certification. We are here talking about a FIPS 140-2, Level 2 certification. First advantage of the certification, some trace is available on the Web, giving very a brief summary of the evaluation results, as well as a security policy.

Of course, these documents tell us many things. For instance, that authentication is password-based:

Password Only: The module persistently stores the password hashed and AES encrypted in FLASH, which is outside of the cryptographic boundary.

Then, it defines the strength of the mechanism:

The probability that a random attempt will succeed or a false acceptance will occur is 1/62^4, which is less than 1/1,000,000. The user is locked out after no more than 100 contiguous login failures, therefore the random success rate for multiple retries is 1/62^4 divided by a customer specified number ≤ 1001, which is less than 1/100,000.

OK. The “62^4″ seems to mean that a 4-character alphanumeric password is required (26 letters, uppercase + lowercase, + 10 digits, that makes 62 symbols), which represents a bit over 14 million combinations. I don’t really get the “customer specified number ≤ 1001″ bit, but divided 14 millions by 100 (possible tries) yields a number greater than 100000, so the statement is about right.

Next, we can look at the certificate, which states:

Roles, Services, and Authntication: Level 2

So, this means that this authentication mechanism has been evaluated, and that it satisfies Level 2. I am not a FIPS140-2 specialist, so I need to look at the certification’s definition document what that means:

For Security Level 2, a cryptographic module shall employ role-based authentication to control access to the module.

So far, so good. The roles are here basic, but they are present. Of course, the specification says more than that. Here are the basic requirements for authentication:

The strength of the authentication mechanism shall conform to the following specifications:

  • For each attempt to use the authentication mechanism, the probability shall be less than one in 1,000,000 that a random attempt will succeed or a false acceptance will occur (e.g., guessing a password or PIN, false acceptance error rate of a biometric device, or some combination of authentication methods).
  • For multiple attempts to use the authentication mechanism during a one-minute period, the probability shall be less than one in 100,000 that a random attempt will succeed or a false acceptance will occur.
  • Feedback of authentication data to an operator shall be obscured during authentication (e.g., no visible display of characters when entering a password).
  • Feedback provided to an operator during an attempted authentication shall not weaken the strength of the authentication mechanism.

This definitely reminds us of the security policy, which satisfies all these rules. Now, what is missing? Well, the attack that succeeded is missing. There is no mention of the protection of the authentication mechanism against tampering. The standard only defines the properties of the normal use of the authentication mechanism, but not the properties of its defenses.

This is because FIPS140-2 focuses on cryptography, and not on ancillary functions. Maybe that a Common Criteria (CC) certification would have been better at finding this flaw, because CC looks at all security functions, beyond cryptography, and all labs know that authentication often is the weakest point of the crypto products. Of course, we will never know what CC would have found.

Now, we know one good point about certification: it only took us a few minutes to find the relevant information (security policy, certificate, and FIPS140-2 definition). And a security-literate computer professional would only need a few minutes to understand what features have been analyzed or not. Of course, very few people ever do that kind of analysis.

One of Schneier’s commenters mentions the fact that these products don’t really deserve to be blamed because “to err is human” and the vendors have acted swiftly after the discovery of the flaw.

Well, this may also be a very good point about certification. When NIST sees headlines about FIPS-certified products getting broken, it is quite likely that they take some action to analyze the problem, and that they get in contact with the vendor. And that’s a pretty good incentive in favor of action from these vendors.

So, overall, the certification brought some advantages to the customers, even to those who do not understand much about security. And the other good news is that now, their product is likely to be more secure, once they will have applied the corrective actions suggested by the vendors.

Posted 09 January 2010 ‡ Comments (0)
§ News
° Tagged: ,

Let’s tax Google! All of us!

I am French, and I must admit that my government spends a lot of time innovating about technology, in particular in relation with artistic creation. After enacting a wonderful antipiracy law that will cause problems to people with poorer network security skills than their neighbors, a recent report is suggesting to tax Google because it is making money from people who search about artists (musicians, in particular). So, I searched about a few of them, just to see how Google coudl make money out of this.

A search for “Beatles” returned a surprisingly small amount of adds; “Michael Jackson” brought tabloid stuff, and “Muse” worked great. All advertisements were about Muse concert tickets and merchandising. So, OK, Google is making money, but it is also helping Muse make money, as well as legal concert ticket resellers. Actually, I was quite amazed that there would be no reference to ancient Greece or general culture on the first page search for “muse”.

One last search for Florida bluesman “Sauce Boss” led me to his Web site and many references to him on the Web, but Google didn’t make much money, because the advertisements were about “Hugo Boss” and some sauce, which I was not interested in. However, it worked for me, because that’s exactly how I found the guy, more than 15 years after last seeing one of his concerts, and it worked for him, because I .

Our government seems to be spending a lot of energy on saving one problematic business model, but things are hard for many of us, including the companies I work for. SIM card vendors are having a hard time with these Google guys, who are moving all our nice SIM Toolkit applications (and their value) away from our SIM cards and into their Android phones, which do not even support SIM toolkit. This is almost antitrust matter: not supporting SIM Toolkit basically means that they are refusing competition.

So, taxing Google definitely looks like a universal good idea, and many of us could gain from it. Maybe we could save the last Minitels that way. However, we all need to get our act together and make money from Google by working with Google. The examples above show how Google can benefit to both big and small music acts. I am sure that somebody will also find a way to make money from them with security in a way or another, and I hope that I can be part of it somehow.

Posted 08 January 2010 ‡ Comments (3)
§ Discussions § Mobile Security
° Tagged:

How to secure Santa’s database?

I read very alarming news today, for a lot of kids around the world: Santa’s naughty-nice database has been hacked. The very good article shows all the typical issues related to privacy, and also to the fact that some records are grossly incorrect; all typical issues encountered when such a massive leak occurs.

Now, here is a perfect example of a database that we all would like to trust, because of the great service it provides (free gifts for kids on Christmas). But then, one must ask the question: shall we entrust this strange old man with such sensitive information?

As a supporter of secure (mobile) devices, my first temptation is to say no, of course. These naughty-nice records should not sit somewhere on a database, where a single leak has the potential to ruin my kid’s life for many years. And how do we know that Santa has a good policy for removing older “naughty” records, and that this policy is correctly applied.

Maybe that making the database accessible, so that we can check its contents, would make things better. But who should perform these checks? Our kids, or their trusted representatives (i.e., us, their parents). The fact that this database holds data about minors certainly doesn’t make things easier.

Maybe that this database should be local. I have been advocating that for a long time. My own private data should be managed on my own devices, under my control, and maybe that the same principles should hold for my kids. By storing this data on their own devices (mobile phones, MP3 players, etc; all kids who are old enough to speak own one of these, or soon will), we have a guarantee that no massive leak can occur. Of course, a local leak remains possible, but it will then need to be a highly targeted attack, one kid at a time.

Of course, there must be a choice of disclosure. A kid may want to hide its naughty-nice record, possibly for privacy reasons. One may even want not to maintain such a record. What would the consequences be? Well, they are quite likely to lose the advantage of being on Santa’s list: Christmas presents. Privacy has a price((And kids, like all of us, are quite unlikely to accept that price.)).

And now, my favorite part: kids may be tempted to hack their local database in order to remove the naughty bits that don’t look good on their record. If they are able to do so, Santa’s entire business model becomes compromised. This means that there must be some way to secure that local database on every kid’s mobile device (not only the storage, but also its processing, as well as the interactions with the kids and with the other interfaces).

Rejoice, SIM merchants, TEE peddlers, smart object salesmen, for there is a wonderful customer awaiting your products in this end of year: Santa needs you!

I wish you all a wonderful Christmas, and great holidays!

P.S. For serious people, replace “Santa” by “Credit rating bureau”, and this post may become more interesting than it seems at first.

Posted 24 December 2009 ‡ Comments (1)
§ Mobile Security § News
° Tagged:

Unleashing Android on a Nook

Using an open system to develop a closed device is nothing new, and it is working. We can therefore hardly call Barnes&Noble innovators for basing their Nook e-book reader on the Android operating system. In another community, opening closed devices (and especially those that run on an open system) is also a well-known sport, and Apple’s jailbreakers are among the most active.

So, Nook has been rooted, and some clever guys have hacked it to basically turn it into a Web-browing, Facebooking, and Twittering machine. Apparently, some things, like Google Maps, don’t work, because some libraries are missing (in other words, it will take a it longer to put them in).

Two things drew my attention to that attack, though, and both of them are related to the design of the Nook offer.
Continue Reading »

Posted 18 December 2009 ‡ Comments (0)
§ Mobile Security § News
° Tagged: ,

The Leyio PSD

The mobile security community already know about PTDs (personal trusted devices), but do we know about, but until very recently, I didn’t know what a PSD was. It seemed obvious from the ad I received from one of my favorite e-commerce sites, so I looked up the device.

The Leyio has been launched a few months ago, and it is of course a Personal Sharing Device. The videos on the site explain it better than I could do it, but the idea is to have a device that can contain some data (16Gb in the standard version), and share it with many other devices. Here are some examples of what it can do:

  • Share files with USB keys. You connect a USB key on the USB port, and hop, you can exchange files.
  • Share files with phones. You connect the phone on the USB post, and hop, you can exchange files (well, I guess, only if your phone is able to exchange files with a PC without any additional driver.
  • Share files with iPods. You connect an iPod, and hop, you can exchange files. Wait? All files? In both directions? I don’t know, but if this is the case, then welcome to the wonderful world of Palm Pre and to the war of updates between Apple and Leyio (if Apple thinks that you are significant enough).
  • Share files with PCs. You select the files that you want to share, and they are copied into a small USB key that you transfer to the PC. Now, that sounds like a good feature, allowing one to select the files to be shared.
  • Share files with PCs (2). You connect the Leyio to a PC, and you can see all its content, organize it, etc.
  • Share files with another Leyio. The Leyio includes a radio link that allows two Leyio to share data. This is done by shaking the device, like you are throwing the content at the other guy.

This is a nice device, but is it worth it at 129€?
Continue Reading »

Posted 13 December 2009 ‡ Comments (0)
§ Mobile Security § News
° Tagged:

Cartes, day 1

Today was the first day of the 2009 edition of the Cartes show, the greatest smart card show on earth. Not much time to look around, but I didn’t catch a lot of excitement this time. There aren’t that many new things going on, and everybody looks like the first golden era of the smart card is over.

Will there be a next one? Maybe, but maybe not. Handset vendors don’t seem to hurry for supporting NFC, Smart Card Web Servers, and other USB interfaces for SIM cards. NFC seems to be moving, but definitely not fast. Android seems to be the only good news for the industry. At last, there are phones on which we can play with the software, including the drivers we want, the missing software layer, and anything else that is required for a good demo.

The numbers aren’t that bad, though. Part of my day was spent sitting on a Java Card Forum panel, and some of the figures shown by Sun sound good: 5 billion smart cards in 2009, including almost 2 billion with Java Card. And the marlet is still growing, with a forecast of 7.5 billion cards including 3 billion with Java in 2012. Wait, over 70% of these are SIM cards, and although the volume is growing, the associated revenue may not grow that much, as SIM cards become real commodities, with price as the last differentiator.

I guess that this is enough gloom for tonight. Tomorrow, I will start saving the smart card industry. First by going to look at a few Sesames winners, in particular Sagem’s Internet-of-Things demo, and Neowave for their ID product. And second, by looking positively at potential new applications for our beloved SIM cards.

Posted 17 November 2009 ‡ Comments (2)
§ News
°