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.

• 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?

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.

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.

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.

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.

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.

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.

First, the Nook comes with a free lifetime 3G connection, which allows users to download e-books over-the-air through the AT&T network (US only). This is nice, but the hack could offer Nook owners unlimited 3G for life. Of course ,this is unrealistic, as B&N and AT&T will find a way to make this impossible (until the next hack). However, it definitely raises the stakes about the hack, especially if it can be made accessible to many users.

Then, the Nook makes things quite easy for hardware hackers. The system is stored on a MicroSD card. Apparently, the card can’t be swapped for a larger one (too easy), but still, some things can be added to it (this is the base of the hack). Depending on what can exactly be changed on that card, we are going to see really interesting uses of the Nook. And for once, we won’t need to solder anything to have full access to the system. Nice.

I have taken a short look at the hackers’s site, and there isn’t much information about hacks at the Android level, and I am still wondering how much integrity checks that device includes. The current rooting process simply consists in enabling remote debugging of the device. Most likely, this feature could be removed from the MicroSD, but the next question would then become: Can we put it back in? That’s where integrity checks kick in, and the mechanism that performs these is better off if it sits outside of the SD itself.

One last point that I love in the hack, where the security dog bites its master. The command line recommended to disable automatic B&N updates is as follows:


mv /system/etc/security/otacerts.zip /system/etc/security/otacerts.zip.bak


Sure looks like somebody is hiding the OTA certificates used to authenticate the update site.

I will stop for now, but there are barrels of fun to come from this hack in the future.

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€?

Of course, one of the issues is security. On that part, Leyio is innovating by using a fingerprint scanner for authentication (you can also use a password if you don’t trust biometry). I really like the fact that the scanner is also used as input device. In terms of security, I just hope that there isn’t any loophole left wide open, but this device definitely is a step forward when compared to standard USB keys.

Here is a grabbag of remarks:

• Wishful thinking. Sharing with another Leyio is nice, but a Leyio ain’t an iPod, and the probability to find another one nearby is low. If that device could connect in WiFi/Bluetooth to my iPod Touch and transfer data through a free iPod application, things would be much better.
• Gadgetry. I hope that the radio link and the accelerometer don’t cost much, because in practice, they are likely to be of little use.
• No online backup. Although 16Gb is a bit small, this is a nice little backup device. In that case, associating it to storage on the cloud would ne nice.
• No wireless. What? You think that you can be cool without being wirelessly connected? This radio interface really needs some work.
• Where are my files? My files are usually on my PC somewhere. I would put on a Leyio the files that I think I am most likely to share. The question is: is 16Gb enough? Possibly, but I don’t know.

Now, will I buy one? No, not at 129€, for sure, because I am not that desparate to share. But then, even if I share more than some people, I am not a teenager, and I can’t say what teenagers would say about the device (the Leyio also offers ways to share avatars and internet links, but I have the feeling that they would find other problems to it).

To close this, here are a few suggestions for the future of that device:

• Make a corporate version. With a professional look, a strong focus on security a little less gadgetry, and a few more features, this could make it in the corporate world, at least as a more secure way to share things.
• Combine it with other features. A Leyio/Yuuwaa/Kindle combination would be nice. A thing that manages sharing (Leyio), is automatically backed up on line (Yuuwaa), and comes with a Kindle-like “free” 3G subscription so that the communication is completely transparent. Nice!

Of course, making the device disappear altogether, or get to the form factor of a standard USB key would also be nice, because I am already carrying an iPod Touch and an Android phone, so this third thing is too large.

Note to self: when launching a data-related service/object, think about using names with (almost) no consonants; smooth sounds are required, like Yuuwaa or Leyio.

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.