Why do we need personal servers? Facebook.

I just read a very impressive speech by Eben Moglen. Here is an excerpt that is music to the ears of people supporting personal Web servers:

What do we need? We need a really good webserver you can put in your pocket and plug in any place. In other words, it shouldn’t be any larger than the charger for your cell phone and you should be able to plug it in to any power jack in the world and any wire near it or sync it up to any wifi router that happens to be in its neighborhood. It should have a couple of USB ports that attach it to things. It should know how to bring itself up. It should know how to start its web server, how to collect all your stuff out of the social networking places where you’ve got it. It should know how to send an encrypted backup of everything to your friends’ servers. It should know how to microblog. It should know how to make some noise that’s like tweet but not going to infringe anybody’s trademark. In other words, it should know how to be you …oh excuse me I need to use a dangerous word - avatar - in a free net that works for you and keeps the logs. You can always tell what’s happening in your server and if anybody wants to know what’s happening in your server they can get a search warrant.

And if you feel like moving your server to Oceana or Sealand or New Zealand or the North Pole, well buy a plane ticket and put it in your pocket. Take it there. Leave it behind. Now there’s a little more we need to do. It’s all trivial. We need some dynamic DNS and all stuff we’ve already invented. It’s all there, nobody needs anything special. Do we have the server you can put in your pocket? Indeed, we do. Off the shelf hardware now. Beautiful little wall warts made with ARM chips. Exactly what I specked for you. Plug them in, wire them up. How’s the software stack in there? Gee, I don’t know it’s any software stack you want to put in there.

In fact, they’ll send it to you with somebody’s top of the charts current distro in it, you just have to name which one you want. Which one do you want? Well you ought to want the Debian Gnu Linux social networking stack delivered to you free, free as in freedom I mean. Which does all the things I name - brings itself up, runs it’s little Apache or lighttpd or it’s tiny httpd, does all the things we need it to do - syncs up, gets your social network data from the places, slurps it down, does your backup searches, finds your friends, registers your dynamic DNS. All is trivial. All this is stuff we’ve got. We need to put this together. I’m not talking about a thing that’s hard for us. We need to make a free software distribution device. How many of those do we do?

We need to give a bunch to all our friends and we need to say, here fool around with this and make it better. We need to do the one thing we are really really really good at because all the rest of it is done, in the bag, cheap ready. Those wall wart servers are $99 now going to $79 when they’re five million of them they’ll be $29.99.

Then we go to people and we say $29.99 once for a lifetime, great social networking, updates automatically, software so strong you couldn’t knock it over it you kicked it, used in hundreds of millions of servers all over the planet doing a wonderful job. You know what? You get “no spying” for free. They want to know what’s going on in there? Let them get a search warrant for your home, your castle, the place where the 4th Amendment still sort of exists every other Tuesday or Thursday when the Supreme Court isn’t in session. We can do that. We can do that. That requires us to do only the stuff we’re really really good at. The rest of it we get for free. Mr. Zuckerberg? Not so much.

More a Marvell plug than a Smart Card Web Server, but still, the reasons leading to it are interesting. This speech is really, really worth reading entirely.

Android fragmentation

Things are starting to get ugly on the Android fragmentation front. Worse yet, I just got hit by the problem with my good ol’ Touch (about one year old, i.e., an antique by Android standards). A good friend just pointed to stickybits, a promising service (at least if you are not in the NFC industry) that allows you to associate digital objects to any barcode, or indirectly to the physical object that the barcode is attached to.

I got all excited, clicked on the Android button, scanned the QR-Code, and Android Market opened. Things were looking good, but the application was not found. That looked strange, so I went back to the Android page and read the text.

Works with Android version 2.0+

Now, I feel bad, really bad. There is an iPhone version, that I could load on my iPod Touch. But then, a barcode app that I can only use at home by entering the digits is just not fun.

Now, not everything is bad, but it doesn’t look very good:

  • BAD. It doesn’t work on my phone.
  • BAD. I have no clue if I will ever have the opportunity to upgrade to Android 2.0+ on my phone.
  • GOOD. It didn’t allow me to load the application and be disappointed.
  • BAD. “Not found” does not properly describe the problem in the app store.
  • BAD. It seems that even today, some phones are delivered with older versions of Android.

This is just the beginning: versioning is pretty easy to do. I still remember the first application that I got on the Android Market, which tried to address the physical keyboard that my phone doesn’t have. This gets me a bit afraid about future NFC APIs: Will there be a reference set of APIs to be included? Will they include both a way to address the contactless interface and the Secure Element? It would be nice to have a regular interface on all devices. Gemalto has joined OHA (in the Semiconductor category, which sounds odd, but I guess that the other categories are no better fit), so something is bound to happen at some point. Let’s wait and see.

P.S. If one of you can actually try stickybits, let me know how the thing is. App Store comments seem to refer to privacy issues (everybody sees what you have scanned), which sounds interesting, as it shows room for improvement.

Hadopi, Google, and a few illegal things

We European have strange laws. The French Hadopi law is a law that is intended to protect copyright owners against big bad teenage copiers. That law has been voted, and it is in the process of being enacted. Of course, it won’t work; such laws just don’t work.

ReadWriteWeb has published an article about Hadopi economics (in French, sorry). I will try to provide a quick outline here, but it’s far better to read the full thing.

Before Hadopi, the music industry was losing money because many French youngsters exchanged “free” music through P2P, helped by The Pirate Bay and similar organizations, who made no real money out of this. Then came the law, directly targeting the use of P2P tools. Such exchanges are now monitored, and it looks quite dangerous to continue doing it (after all, if you get caught three times, you can lose your Internet connection).

Well, using P2P is dangerous, but using direct downloads from servers sitting outside of France remains safe (it seems to tbe the way the law is applied). So now, the effect of the law is to promote a new technology. So far, nothing big: the law is just not working, and it isn’t the first one. It gets better when you realize that the companies providing the new technology are actually making money from it. Pirates are paying for the ability to download content illegally.

Now, that makes a big difference. The law has created a viable business model, possibly an entire ecosystem. Most likely illegal in France, but hosted in countries in which such laws can’t be enforced, and ready to move in a few minutes when needed. And guess what? On the other side, the music industry still doesn’t have a viable business model for selling their music. Conclusion; the law is not only inefficient, it is counter-productive, because it builds a viable (although illegal) alternative to the legal music industry.

In Italy, they have privacy laws that prohibit the publication of images that make fun of people, especially if they can’t defend themselves; such a law defends human dignity. That’s a good law, and it got some Google executives comdemned to suspended prison terms over the publication of an offending video on Youtube. Google calls this a serious threat to the Web, and gathered support from many. That’s because their role is very limited in this; after all, they only acted as a hosting platform. That’s true, but … they also made money from that video, because Google also is an ad broker who displays advertising on Youtube pages. And when I look at it from that perspective, I don’t just see a hosting platform operator.

I see a company that makes money by exploiting illegal material in a highly profitable ecosystem. The internet is great: with all its shades of grey, we have to love it.

Here and Now !

Ajit Jaokar has published a post on Mobile Cloud Computing, in which he asks some questions about mobile computing. I found his questions very interesting, so here are my answers (I kept them short, but I will try to develop some things later):

a) Is ‘mobile cloud computing’ a distinct domain in itself? Or is it more about ‘Web Cloud providers going mobile’
Mobile cloud computing relies on the same principles than standard cloud computing, with one major differences at the client level: Mobile clients a link btween the real world and the virtual world, because they are always connected, and they are with us. The consequence is that our requests are very often about where I am now, what I am doing now, who I am with, and similar things. Basically, mobile cloud comuting is about “Here and Now”

b) Do mobile providers have any advantages over web providers (like Amazon)?
Yes, if they take advantage of specific mobile characteristics to actually establish links between the cloud and the world we live in. Things like location and proximity (for instance, the ability to exchange with a neighbor). Otherwise, no advantage.

c) What are the key issues and key advantages for mobile cloud computing?

  • Issues: Leveraging the available information. Connectivity Issues (i.e., local caching) Adequacty of user interaction (quantity, presentation).
  • Advantages: Availabiliy of the user. Link with physical interaction.

d) Will mobile cloud computing be about privacy in addition to security?
Privacy is a big issue for cloud computing in general. Adding information like location, proximity of others, or similar information, makes privacy more important, but the principles remain the same.

e) What are the biggest privacy and security threats to mobile cloud computing?
I see two levels of problems: first, we need to define the proper access controls. Cloud computing is can be made more interesting by making some information available to services/ partners/ friends, but both service providers and end users must ensure that the proper access controls are defined.

The second level is to properly enforce these controls. At that level, the easy part (maybe) is to implement software correctly on servers and mobile devices. The hard part is to make all users understand the importance of privacy and access controls.

g) Will providers use Mobile Cloud computing to ask payment for granular features(like access to voicemail) aka the Ryanair business model for Cloud computing!
The Ryanair business model can work for a few crucial services, and possibly in some professional settings, in exchange for a better quality of service. Micro-payments (or better, micro-accounting), would be far better.

h) Will enterprises be the key drivers for Mobile Cloud Computing?
As users, most likely not. Most enterprise jobs are static, but we all move around in our personal lives. As service providers, it would be nice to see “classical” businesses being able to do something.

i) Mobile Cloud computing can be implemented at many levels in the Telecoms stack: The Device/Platform, the Operator; The Mobile Web; Infrastructure; SIM. Any more potential ways in which mobile cloud computing can be implemented? And what are the pros and cons of the approaches?

This is a crucial question, and I would love to read other people’s answers, because mine are still confuse at this day. Among the other ways to implement mobile cloud computing, there may be some things to do with small embedded servers (Java Card 3.0 of course, but not only); also, the Device/Platform category may be too vague, because there are several actors there, including the application framework, the Trusted Execution Environment, and more.

j) Which applications would be most likely to benefit from Mobile Cloud Computing?
Most likely not the obvious ones, like mapping or very obvious uses of local information. Combinations of social aspects with location, content sharing are sound to me like winners, but I can’t really see how.

k) Would PCs/Sub netbooks and other ‘non phone’ devices covered by Mobile broadband be impacted by this trend and if so, how?
If they are able to include the information about “Here and now”, why not? It’s not the device that counts, it’s the connectivity. Other devices, like cameras or MP3 players, could also get involved. If they are connected to the network (directly or indirectly) and if they know about “Here and now”, they can do things.

l) Many providers use ‘data backup’ as a stepping stone to cloud services. Will these services evolve beyond the ‘data backup’ i.e. for instance will customers trust their backup providers with personalized information leading to other services
Data backup is a first step, which could/should/will be reversed. The main copy of the data is in the cloud, and there is a cache on the device. However, it should be possible to protect some information (for instance, by only storing it encrypted in the cloud).

Another question is about the “ownership” of the data in the cloud. Users would benefit from having much more data in the cloud, potentially shareable with others. Think about shopping lists, medical files, and much more. Of course, if we consider such sensitive data, then filtering and presentation becomes very important. But then, by giving more data to be correlated in the cloud, we also increase the potential value of services.

j) How important is end to end security for Cloud computing?
End-to-end? Of course, it’s important. And it basically depends a lot on the data to be protected.

k) How important is the management of the client on diverse devices important for end to end cloud security?
Very important, but not more than for any other kind of mobile application. The data may be in the cloud, but some of it is likely to be cached, making it available through standard vulnerabilities.

l) Is the Mobile Web a good client for Cloud computing?
Is Mobile Web good enough for enforcing access control? Maybe not, unless it is complemented with mobile apps, or with high-level widgets.

m) Will emerging markets adopt Cloud computing services?
Yes, most likely not the same ones. The fact that in many markets, mobile phones are more prevalent than any other high-tech device makes mobile cloud computing a good candidate for a lot of new applications, adapted to the needs of every market, including emerging ones.

n) Will low spec devices (ex feature phones) benefit from ‘thin client’ cloud computing services?
Yes. More than the device, is issue is the connectivity offered by the operator. The price of mobile connectivity can be a strong deterrent, but it is likely to go away, in particular if it is restricted to a limited number of cloud services.

o) Identity and the Cloud.
On a mobile device, the username/password model is even more broken than on a PC. So, mobile devices may push strong identities on the cloud. Another important thing is that identity is not only useful between a user and a service provider, but also between two users, before to trust each other.

Chip And PIN Is Broken (A Little)

By now, there has been sufficient hype around Ross Anderson’s latest attack on EMV banking cards. Once again, the Cambridge guys have scored a good one here, as the simplicity of the attack is outright incredible: Intercept the PIN Presentation command, make the terminal believe that the PIN is correct (i.e., return Status Word 9000), while never sending the APDU to the card. After that, the terminal thinks that the PIN was presented correctly, and the card thinks that no PIN was presented. OK, let’s stop here for a minute.

Most of us, who don’t know the EMV specs by heart, would believe that the PIN authentication is part of the card applet’s state machine. After all, Chip and PIN seem to be very tightly connected to each other. Well, it isn’t the case, and PIN verification is just something that may happen, or not. So, the discrepancy can go unnoticed.

When looking at the EMV protocol in greater details, like they do in the article, we notice that the information is actually present, but that we are missing a method to consolidate the various bits of information. Some items are optional, while some others (the IAD) use proprietary formats, and are not intended to be parsed on the terminal. Basically, there are solutions to counter the attack, but they are not obvious to implement. If you want all the technial details, refer to the full paper.

Now, what does this attack tell us about the EMV Protocol? Well, it has a vulnerability, like many (all?) other security protocols, at least in the way it is most often implemented in practice. It’s a rather big one, too, which shows that smart card protocols most likely get less interest than others. It also shows that simple is not only beautiful, but also secure, or at least that the complexity of systems like EMV, with all its options, is becoming a real security issue.

Then, another issue is that the ability to perform over-the-air software updates to fix vulnerabilities is becoming standard, on computers, on phones, and even on some TVs and soud systems, provided that they are connected to Internet. Well, such things remain hard to do on payment terminals, and also on smart cards, even though th security of these devices is critical. Can we really expect card operating systems to become more complex if we aren’t able to maintain them over their lifetime? Probably not, and that transition is going to be tough.

Another thing that this attack reminds us of is that smart cards are just another security measure, which cannot be perfect. The paper contains the usual attacks against UK banks who, according to the authors, make customers liable as soon as PIN authentication is used on a bad transaction. Here, the problem is not the technology, it is the system around it. Magstripe technology is far more broken, but if the insurance provided by US banks is better, then the consequence is that the customer, in the end, is better off with the lower security, because their insurance provided by their banks is better.

About PIN security itself, it is in fact very easy to guess the number typed by a person on a keypad, even without seeing the keypad. You can make the experience in any European supermarket line: simply try to guess the PIN typed by the people in front of you. You will notice that in many cases, you have the feeling that you got a lot of information about that PIN. Add to that the fact that you are far from being a trained professional, and you can get an idea of the problem: protecting a PIN is difficult. As far as I know, in France, where Chip and PIN has been the rule for many years, it is not too hard to avoid liability even if our PIN has been disclosed. The PIN is not a miracle, and it cannot solve all problems.

Finally, a positive note. We are getting quite a lot of attacks on smart cards these days. The program of Cardis 2010 includes 6 papers on attacks, and the published state-of-the-art is getting closer to the laboratories’ state-of-the-art. Some might say that this is dangerous for cards, but some others will say that this is actually a positive evolution, moving away from the “smart cards are secure” dogma into a “smart card can help build good security models” logic. And if we use that logic to build business models that ultimately benefit final customers, then all of this will have been a step in the right direction.

What about iCharge?

Well, it seems that I was wrong on Europe and swiping. A European company is getting ready to launch iCharge, which looks like a clone of Square for many of its features: small card swiper, on-screen signature, location-based, … They don’t mention pictures and loyalty, but I guess that it’s coming next.

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.

Magstripe: 1. Chip: -1

Being from the smart card industry, I usually don’t spend much time looking at things that work better by swiping cards than by using a good old smart card. Then, a few minutes ago, I looked at the promotional video for the Square payment service. Well, it’s definitely worth watching.

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.
Continue Reading »

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.

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?

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.