To celebrate that, I have decide to attend the opening session this year. We started by an enthusiastic eID spporter from European Union, promising us all regulations and standards ready for 2014, which sounds interesting. After all, there are very interesting deployment in countries like Belgium and Estonia, which could be extended.

Then, we get a panel, with the question below. Speakers are Christian van der Valk, from TrustWeaver, Herrmann Sterzinger, from G&D, Massimo Cappelli, from Global CyberSecurity Center, and Marie Figarella, from Gemalto.

Why has eIAS services not been a success to date?

• Is it really the case? There haven’t been failures, there are many services ready to,use, and a lack of recognition, with a common perception that digital signature ismore difficult than it actually is.
• Citizen certificates are too expensive, and the use cases are not compelling enough. Thisis changing in some places, like in Austria, where the state pays the citizen certificate.
• Market fragmentation and lack of trust and confidence are the two main issues. They may even be linked because the fragmentation does not allow the development of global solutlons, deployed across Europe.
• Issues have been legal and societal, not technical. Fragmentation and lacking use case are the most important,

How would the new electronic identification and trust services regulation improve on this situation?

• Moving from directive to regulation is important
• Making it global would be good, but also hittin some limits, in particular regarding discrepancies in privacy requirements.
• Moving to a regulation will limit fragmentation, the scope will be larger, going beyond signatures to seals, timestamps, and more. Mobility between states will also be greatly improved. Finally, supervision should be improved.

What additional key actions would be necessary to make eIAS a success?

• Sharing identity and authentication between public and private spheres would help. Also,aligning with the global market with help, including private support, like Adobe. Also, the recognition of non-PKI solutions would be required (that sounds interesting)
• Moving beyond web authentication is required. Moving to global regulation loses things, such as already deployed eIDs, which do not comply to the new regulation, and also existing standads and existing profiles.
• Bureaucratic simplification associated to eIAS would be great help. We are also missing a common framework of expertise, with collaboration between national agencies. Thereisalso a digital and cultural divide, which hurts wide adoption. Finally, including soft identity would increase the use of strong identity, if it can be used in our everyday life.
• Associate reliable digital identity with a portable secure elemnt, to allow 2-factor authentication. Build an open and interoperale secure Internet. Privacy by design. Push digital identity on all SIM cards to benefit from NFC

Now, that’s quite interesting. The views from the panelists are quite consistent. The question that puzzles me most is the relationship between national and private identity. I am left wondering what opportunities will be given to private companies and web providers to leverage this eID. Making this happen would be a great boost to eIAS.

I also liked Gemalto’s analysis and proposals, which was short and to the point, except the last point, of course; mandating SIM-based identity for NFC is ludicrous and pure lobbying, at least because the SIM is not the only way to access NFC.

So, an interesting first panel, although there haven’t been many suprises and illuminating discussions.

What? No standard on the digits that may/may not be disclosed? I couldn’t get the facts from EMV or others (if you know, I am interested), but I noticed that although the digits printed on most of my (French) credit card receipts are the same (9 digits following the pattern xxxx xx00 0000 000x), some of my receipts include the infamous 4 last digits, and an Italian receipt includes the 8 first digits. Just with these few examples, I would say that, either there is no standard about which digits to show/hide, or the standard is not applied anyway. It is not difficult to guess that this is most likely not better on Internet, and not only at Amazon.

On this particular issue, I would blame Apple, because the information they require to grant access to an iCloud account is not sufficient (e-mail, billing address, partial credit card number). In particular, Apple allows you to forget the answers to your security questions, which doesn’t sound very good.

Mat Honan recommends in his paper to move beyond passwords and to adopt two-factor authentication. This sounds sensible, and I approve this move. However, in the present case, how useful would that be? If a cloud vendor uses two-factor authentication, then there must be a procedure for lost tokens. And this procedure better be good.

Not that it’s that complicated to design a procedure that works. We can for instance rely on existing infrastructure, like the Post Office. You can request your password to be snailmailed to you in a Certified Letter, which will require in-person delivery at your home or authentication with a government ID at the post office. This works perfectly against hackers, because they are not good at physical actions that require real presence.

However, this has some trade-offs: delay and price. Changing a password online is about free and instantaneous, whereas sending a physical letter has a cost, and it will take at least one day. I am ready to accept this delay and this cost to protect my most important cloud accounts, because I have some understanding of the risks. Not everybody does.

This actually represents an interesting role for two-factor authentication tokens: end-user education. Because they are a physical object, any user will understand that a new one needs to be sent if it is lost or compromised. And although they won’t be happy, they may/should/will associate the cost and delay associated to the token replacement to the security of their account.

The best part is about the data you provide when subscribing (you can find a copy of the original decree in this article). Here is a rough translation of this part of the text:

3° For persons abovementioned in 1 and 2 of I in the same article, information provided when subscribing a contract by a user, or for creation of an account:
a) The idenfier of the connection, at the moment of the account creation;
b) The first name and last name or the business name;
c) The associated postal addresses;
d) The pseudonyms used;
e) The associated electronic mail addresses or account identifiers;
f) The phone numbers;
g) The password as well as the data allowing to verify and modify it, in their latest up-to-date version ;

All of this is pretty scary, but the last one is the scariest: the government wants my password! This is going to simplify the gathering of evidence for anti-terrorist teams (they are the ones who don’t require a warrant or any judge order to get the information): they can just login as you and send the incriminating e-mail. This part of the story has been widely discussed on French media, with wide-ranging opposition to the measure, so it is not very interesting.

I would like, however, to point to a sentence that we can found at the very bottom of the decree:

Data mentioned in 3° and 4° only need to be kept if the persons [sites] usually keep them.

OK. So, they will get any information that I give to Internet sites. However, it should be more difficult for the government to get access our passwords, forat least two possible reasons:

• Good service providers hash/encrypt passwords. This means that the government will get data that allows them to perform dictionary attacks, but not the passwords directly, because the service providers simply don’t keep that data as such.
• Federated identity doesn’t use passwords. Nothing in the list mentions authentication tokens or things like that, so this is a good way not to disclose your passwords.

This last sentence can therefore be considered as a reminder to be very careful about our authentication methods on Internet. Even if this decree eventually gets repelled and/or modified, you can never be sure that your next government is not going to do something similar. So, here are some reminders:

• Use good passwords. It is the only way to protect yourself from dictionary attacks.
• Use different passwords. Do not use the same passwords on all sites. This is another layer of protection against dictionary attacks, but also an obvious protection once one of your passwords is disclosed and/or compromised.
• Use a federated identity provider, like an OpenId service. If possible, use one that is not represented in your country, in order to make sure that your passwords are out of reach of your government.
• Use alternative authentication methods. Choicces are difficult, but there are programs that will generate random passwords, manage them for you in a secure manner (that’s the tough part), and have you authenticate in original ways (n-factor, biometry, etc).

All of this is sound advice, and it will also contribute to protecting you against other bad guys.

To conclude, I will make a political comment, which is unusual here: I hate the sentence just above, and I hate to consider my government as one of the “bad guys”. I am French, European, and I believe that government should be on our side. However, having a government that promotes the use of Internet for “freedom fighters” in oppressed countries and collects passwords from “terrorists” at home is a bit scary, as we all know that someone’s terrorists often are someone else’s freedom fighters. And, as mentioned by Simon Phipps, the U.S. is not doing any better by developing an Internet panic button for democracy activists that is probably illegal in the U.S.

• The client gets a SAML token from Security Token Service (STS) using WS-Trust protocol.
• The client puts the SAML token into the message.
• The server verifies SAML token and makes authentication and authorization decision.

Of course, the actual authentication occurs in the first step, between the client and the STS. After that, it is all a question of trust between the server and the STS that has generated the SAML token. With this scheme, we can avoid direct authentication between the client and the server.

Nothing really new, but I really liked their explanation, based on a parallel with the JavaOne conference badges. When you arrive to JavaOne, you first go to registration. There, you need to prove your identity by showing an officla ID to the attendant, who will then prepare the badge that grants you access to the conference. In addition, the attendant will add some ribbons that describe your specific attributes. For instance, I have the “Speaker” and “Alumni” ribbons. These ribbons are attributes that complement your basic identification, and allow you to get authorized in some circumstances. For instance, I can get into the speaker lounge, and I got an alumni jacket.

The conference badge acts like a SAML token: the basic badge shows that you have been authenticated, and the additional attributes describe some of your characteristics.

The model can be slightly enhanced by using two levels of STS. The idea is that the user will get a SAML token from a local STS, and use that token. The server will then get that token to another STS (local to the server), and get in return another SAML token, suited to its needs. With this scheme, both the client and the server only need to trust a single STS. The business of trust is entirely delegated to the two STS’s, who need to share each other. This clearly separates the trust issues from the rest.

Interesting presentation, but I still don’t feel enlightened about identity in the cloud. There is another session tomorrow on the topic, I hope that I will be thrilled.

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.