3% of all of the Market submissions that have been analyzed could allow an application to send unknown premium SMS messages without the user’s interaction or authorization.

Premium messages, without the user’s authorization. That’s actually true, but not really scary about the applications. This corresponds to the number of applications that request the SEND_SMS privilege (1356 out of 48694). That’s the way Android works: once you have allowed an application to send SMS’s, the application can send any SMS, including premium ones, and this happens without any further user interaction. Abuse attempts are likely, but Google is likely to turn on the kill switch before the bad guy can make any real money.

Similarly, the guys at Smobile have identified real spyware, which actually fowards to another phone all the SMS’s sent and received from a given phone. This application actually describes itself as spyware (search for “spy” on Market, and you’ll find several). All the permissions is needs to do that are SEND_SMS, RECEIVE_SMS, and INTERNET. I am sure that you can do a few things using these permissions. When roaming, I could use a messaging application that uses Internet when available and reverts back to SMS when nothing else is available.

Enough of that. I think that Smobile is pointing at a real issue: once you authorize an Android application to do something (like sending SMS’s or recording audio), it can do it freely until uninstalled. Eventually, a smarter than average hacker will design a good Trojan horse and make some money.

The problem with these reports is that they mislead many people into believing that Android is full of malware. Of course, the reality is that the Android Market is full of apps that could be malware. They just aren’t.

I am a strong supporter of static code analysis, and I think that Android applications definitely are a good target for static analysis. However, the analysis must be much deeper that looking at the permissions requested by the application. For instance, identifying the numbers to which a SMS is sent is much more discriminating. If an application sends messages to a premium number without warning users, it is much closer to qualify as malware. Let’s get that working, and I am sure that we will learn interesting things.

Securing Web servers is hard work, as OWASP periodically reminds us. Of course, this applies to smart card web servers, regardless of the underlying technology. I received a comment from someone who noticed that some of the Java Card 3.0 Connected sample applications have really bad security. Basically, all the attacks from OWASP’s book that can apply will apply.

Of course, one can claim that a piece of sample code is here to show a very basic implementation, not a fully secure application. On the other hand, I often claim that security should be built in from the ground up in applications. Now, here are the problems noticed by Blaufish:

• Servlet does not validate data in doGet(). That’s really bad, of course. Any HTML injection will work at that stage. The problem is that solving this issue is far from simple. The libraries that provide adequate protection against attacks are actually rather large and/or require significant resources, unless of course we oversimplify them, resulting in strong restrictions.
• Servlet does not encode output in doGet(). That’s also bad, especially since nothing is done on input. The problem is the same as above.
• Servlet performs write upon GET, HTTP guidance violation. OK, this is typically due to sample code simplicity.
• Servlet does not implement anti-XSRF tokens. This is actually rather easy to do in Java Card, and we would expect all SCWS applications to actually include a random string in request in order to avoid XSRF forgeries.
• Database layer does not validate data. Combined with the absence of validation and encoding in doGet, this is of course unacceptable, since it would allow really terrible attacks. The issue is the same as for other validations, but a solution needs to be found.
• No user authentication/authorization/session model. Here, my first thought was that there were other opportunities to add security in this application, in particular in the Web descriptor. However, since the operations are specified as query parameters, things may not be that easy. Except that the application is so “stupid” that any access control would be very basic, most likely a binary decision.

So, what should we do? Including complex validation code in basic examples definitely isn’t the solution. However, mentioning that the application is a basic sample that doesn’t include the security measures required in any deployed application, regardless how simple, that could be done, and it may actually already be done. Also, we must recall that not all samples are that simple, and that some of them actually include some security (at least declarative security); we should make sure that there exists at least one example that include state-of-the-art security.

The real challenge, though, is to find appropriate countermeasures, i.e., countermeasures that will work on real applications, running on real cards. That means that they must protect against major attacks, while allowing most uses, and fitting in the card.

Another issue is to identify which attacks actually apply, especially in the limiting context of OMA SCWS, where the mobile phone is the only possible client of the servers. Obviously, some attacks are not a problem: for instance, no risk of denial-of-service attacks. It also reduces the impact of some attacks, because the owner of the phone is the likely victim of most attacks, and many such attacks need to be performed by the owner. A SCWS Web application will not be as exposed as a classical Web application. However, depending on the usage patterns, there is a residual risk, which needs to be identified and countered.

Possibly not a minor challenge. I am not too worried about the first applications; we’ll manage to get them right (well, if we think about security in the first place). But if SCWS spreads, we will have to define a systematic way of including this security, which could be more difficult. Let’s see what happens.

Here’s a grabbag from Internet today. First, the good side, with two Microsoft articles pointed by Bruce Schneier:

• The first one is about the authorization dialogs that we face when an application, native or web-based, requires us to take a decision. I was discussing recently with a colleague the fact that these dialogs are sometimes very technical, and that most people are likely to take a decision based on the reputation of the developer or their envy to see the application work. The article is very interesting, and it outlines the interest of graphical interfaces, with icons. It also serves as a reminder that security is often about getting the user to understand what it is about.
• The second one is a bit more specific, and looks at how we can allow an application to use device sensors, and in particular, cameras. Once again, the trick is to make sure that the user is aware of the use that an application makes of a sensor, in particular when it may violate the device owner’s privacy.

These works are interesting, and shows that Micrososft cares about them. However, since they are advanced research works and they are not very conclusive, they also show that the road to good security interactions is going to be long and bumpy.

On the bad news side, there seems to be a surge in fraudulent premium SMS’s (in French). This time, apparently, the fraudsters are sending a SMS that contains a URL, this URL points to a Web page that opens in a browser, and one of the links in this browser triggers the sending of a multimedia message to the victim’s mobile, which is billed 4,50€. I haven’t seen the thing directly, so I don’t get it directly. However, I am a bit curious of the code of this Web page, because I don’t know how a simple click can cost me 4.50€ without me entering any data, and without a direct link to my operator.

Maybe that the solution is in another piece of news. Orange is making some effort to attract developers with APIs, and these APIs seem to cover messaging among other things. However, looking at the definition rapidly, I did not find a way to bill the user.

All of this leads us to an interesting and potentially dangerous future. With BONDI and the like, the boundary between local and web-based applications is going to become very blurry, and all these applications will be able to use and abuse a lot of sensors and billing systems.

I think that I’m going to look into the static analysis of Javascript one of these days. And all this research in security user interfaces is really becoming important.

This sounds interesting, and I will be listening to the show (maybe not live, but I will definitely get the podcast). I listened many times to France Culture’s science shows, and they are usually serious and interesting. Of course, the question (in English, how to enhance the security of bank cards?) is already a bit aggressive, and I am sure that some people would even challenge that question, claiming that there isn’t much to be enhanced. Well, we’ll see on Friday.

TPM. Somebody asked the question about the relationship of TPM and smart card. The latest TPM specifications give the impression that they are exending their scope in order to embrace the role of generic cryptographic token for a PC platform, possibly in replacement to smart cards. This of course may be true, as every technology tries to gain ground on the others. However, there also are goof arguments that go agaisnt this view. First, a TPM is tied to a machine rather than a person, and this makes it quite difficult to be a representative of a person like a smart card can be. Then, and most importantly, the TPM is a device that is here to guarantee the integrity of a system, whereas the smart card is an identity device. This means that the basic mechanisms that are implemented are fundamentally different. They may be combined, of course, but there is no real reason behind that.

Smart card, storage, and locality. The idea of linking smart cards to storage isn’t new, and we have again talked about it, in particular with the possibility to link a smart card to storage, for instance through a secure MicroSD card. There are advantages to that, but allso drawbacks, as linking two elements reduces the flexibility for the buyer, who is then faced with fewer options. In a similar/opposed question, somebody pointed out the opposition between the perceived “locality” advantage of smart cards and the fact that everything is now available in the cloud. I believe that these discussions are heavily linked, and are also linked to the way in which we see storage.

Today, many people consider that their main storage is on their PC, with a possible backup in the cloud. We may in a while get to a situation where we consider that our main storage is in the cloud, and that the local storage on our PC and other devices simply is a local mirror of that main storage. What we need to understand is that this doesn’t mean that local storage is useless. For instance, we are far from being able to get the appropriate bandwidth to stream a HD video form anywhere, and it will take a while before we get there. Overall, this means that we will keep having local storage for a long time.

Internet of Things. Some people are seeing an interest for smart cards in the Internet of Things, for at least two reasons. The first one is the one that I have been defending for a while: a smart card, in particular one including the latest Java Card and GlobalPlatform technologies, is an incredibly optimized and secure platform, that can be used in a wide variety of ways, in particular as the heart of a small connected device. The second one is that many people in the Internet of Things community don’t focus much on the security aspects of their fields, that smart cards could bring. The main question is here to understand whether there is indeed no compelling reason to secure a network of sensors, or this is just a question of timing, which means that security issues will come up as soon as the main functional/practical issues will be addressed.

My feeling is of course that the second option is the right one; in that case, delaying the security considerations may once again be a big mistake, because a smart card core could of course bring the required security, but it could also do more than that, by providing an application framework and application management capabilities. Of course, if the smart card is only added later, it will only be considered as a security token.

This is of course yet another demonstration of the “ghetto effect” through which smart cards are solely considered for their security features, and never for anything else, although their computing power is often comparable to that of other chips.

Virtualized smart cards. The last discussion was about virtualized smart cards, a topic that I completely overlooked in my presentation. One of the views of a virtual smart cards is to consider several virtual smart cards within a given smart card. This could be interesting, for instance in the context of NFC, as a way to manage a card with several providers. We could even imagine to host several virtual cards with different configurations on a single hardware SE. Another view of virtualized smart cards, which is a bit more science-fiction, is to consider that we could have virtual smart cards in the cloud, with many cards hosted on some faraway secure device. I have no clue what that would lead to, but it sounds like an interesting thing to investigate.

Interestingly, the current presenter is Guillaume Barbu, from Oberthur, who is presenting an interesting attack based on the same principle: we load a perfectly legal application on the card, and “magically” make it illegal by using a physical attack. My technique is to replace an instruction with a nop, and his technique is to block the throwing of an exception (execution continues even though it should have failed).

This doesn’t sound very interesting, and not a real novelty. After all, we were already able to get type confusion with simple logical attacks. The main difference is here that the applications we use are actually legal, and that their behavior is modified dynamically (one of my colleagues calls them mutant applications, which makes this really scary). In the microcosm of evaluation labs, this is a game changer, because the main argument used against logical attacks until now was “Bytecode verification is mandatory, so your attacks won’t work”. With mutant applications, this argument doesn’t hold anymore.

But does it really change things when we get out of the evaluation lab? Not really. Writing an attack application may be easy, but exploiting it remains very hard. Smart cards are highly controlled environments, and traceability remains the norm. Our attacker A must be an insider in a company that actually develops an applications. This attacker A then needs to plant a Trojan horse in one of his company’s applications, and have it loaded on a number of platforms. So far, so good.

The problems come by when the attack is actually exploited: with the kind of traceability we have on smart cards, as soon as the attack will be triggered, it will be noticed, and labs will trace the attack back to that application. If you combine that with the fact that this attack required physical access to the smart card that is being attacked, its practical impact becomes quite limited. It is mostly useful if you have a brittle security system, in which disclosing a key breaks the entire system. But in that case, the problem is not really in the Java Card implementation, but in the system itself. Even without this attack, this key would have been compromised.

The main focus of the talk is about sharing between applications in such a setting. This started by a description of Java Card’s sharing mechanism, and of Multos mechanism (for those of you who don’t know, the Multos sharing mechanism is based on delegating APDUs: the client application creates an APDU command, asks the server application to process it, and gets the APDU response).

These sharing mechanisms have one thing in common: they provide the same access level to all clients, without any notion of privileges. Of course, this is something that we want to fix in a usable model, where a hierarchical model is preferable (dynamic, of course).

Another thing that they want to modify is the relationship between the applications and the runtime environment. The applications should only be authorized to use the features that they have been allowed to by their provider, and the system should be limited to the required access (which is not a requirement in the current Java Card specification).

Privacy is another issue, with three subproblems: application scanning (an application should not be able to discover other applications), profiling user (an application should not be able to profile how users are using other applications), information leakage (no information should leak between applications when they do not actually communicate).

The proposal is here to define a new firewall, associated with resource managers, and in which SIOs are associated to ACLs. Sharing sessions need to be initiated with an explicit binding mechanism, in which the client only gets access to a resource for a limited time, and there is also a delegation mechanism.

Apart for delegation, this looks a lot like the Java Card 3.0 model. But, as the presenter answered to my question, they bring quite a few new things, including their focus on the end user and the formalization of the restrictions between applications and runtime environments, and the explicit binding and delegation. Maybe some good ideas for next releases of Java Card in this…

The talk starts on an interesting property of security certification. The FIPS140-2 certification scheme mandates the testing of random-number generation (RNG) features before they can be used by an application. By forcing this extensive testing, FIPS140 makes the random number generators more sensitive to side-channel attacks, because the tests intenely use the feature that should be protected.

This is a very nice example of systemic failure. In this case, the risk actually comes from the very security certification that is supposed to reduce risk. Nothing new, but another confirmation that is is extremely hard to design security principles (or certification schemes) that can be universally applied to a wide variety of devices.

This is proven again by the fact that the new smart card platform protection profile (BSI-PP-0035) raises this issue of testing and addresses it. You get a better view of things when you are closer.

Here is a transcript of my invited presentation at Cardis2010, or at least the things that I thought about before getting there. The slides are available on SlideShare.

I entered the smart card business writing Prolog virtual machines at a time when virtual machines were starting to migrate into smart cards. That was more than 12 years ago, and since then, I have been working a lot on card application frameworks. So, today, I want to take the opportunity to recall some of the history of these card application frameworks, and to derive a few answers to the question that is asked right here.

Everything started in the mid-nineties with the definition of the SIM Toolkit framework. SIM Toolkit was truly visionary, and a miracle for smart card vendors. The idea was to manage the user interactions on the phone directly from the SIM card.

This was made possible by the weakness of the handsets at that time, and it created the need for card application frameworks. The first frameworks were proprietary. At Gemplus, we had one based on the Forth language, and every vendor had its own framework.

Then, in 1996, came Java. A bunch of maniacs at Schlumberger figured that this rich and heavy language was the right choice for smart cards. Of course, they had strong constraints so the product that they created was very limited, and mostly allowed developers to write simple scripts.

These scripts were compiled into bytecode and then executed on the card. This introduced platform independence, and therefore platform interoperability and application portability. Well, this did not really happen, since no other vendor ever built a card compliant to Java Card 1.0.

And, they did not target SIM cards, at least at first.

A few months later, other vendors jumped on the bandwagon, and in April 1997, the Java Card Forum was created to work with Sun on a more advanced specification. By the end of 1997 we had released Java Card 2.0, which did not survive much. It took us another year and a half to get Java Card 2.1, which laid all the foundations that we needed.

The spec introduced the split VM model, the binary-level interoperable CAP file format, as well as the applet model that we still use today.

However, with this spec, we were still painfully interpreting APDU commands all the time.

Then came Java Card 2.2, around 2001, introducing Java Card RMI. It was now possible to write application using a clean model based on remote method invocation. No more APDU mess, and the future was bright.

But RMI, and even more Java Card RMI, is far from being a universal protocol, so there was still some room for improvement.

Improvement came from OMA, with the Smart Card Web Server.

Now, the applications communicate with HTTP, TLS, all these great universal protocols. Applications are now servlets rather than applets, and it is possible to include standard content on cards.

However, the model is very limited, there are many servlet features that can’t be used. And also, the underlying protocol remains APDU-based, which is a little slow.

Here comes Java Card 3.0, and in particular its Connected Edition. Now, all the limitations are gone, we have a 32-bit VM, a full-blown Web server, TCP/IP over USB, and even more that I don’t recall.

As of today, it is the ultimate card platform.

But, it cannot work by itself, because applications need to be managed.

Application management work started in the late 90’s, under the leadership of Visa. This led to the creation of the GlobalPlatform consortium in 2000, and the issuance of the GlobalPlatform 2.0.1’ specification. This introduced the notion of interoperable card management, allowing issuers to security load, install, and delete applications.

However, there were few provisions for multiple providers.

Here comes GlobalPlatform 2.2. As it exists today, GlobalPlatform 2.2 is the ultimate application management platform for NFC.

However, GP 2.2 remains APDU-based.

That will be addressed in 2010 by the release of GlobalPlatform 3.0, which is a companion spec for Java Card 3.0, and will support Smart Card Web Servers, while being fully based on IP over USB.

This is the ultimate card management platform, promising an even brighter future than Java Card 3.0 alone.

The result is impressive, as we have a framework with a lot of incredible qualities, making smart cards incredibly appealing for all kinds of services.

But …

These qualities may not be the ones required by our users.

Open sounds good, but not everybody likes this.

Consider China’s mobile operators. They have created their own application frameworks; more limited than Java, but better suited to their local market. They are proprietary, but the operators are big enough to motivate card vendors to develop these profiles for them.

Interoperability is something that everybody needs. Even the Chinese operators have specs that are detailed enough to allow vendors to develop interoperable products.

However, the problem with interoperability is that it is very difficult to achieve, and that it always results from a very long process. Functional interoperability takes years to achieve, and security interoperability remains a dream today.

Multiple applications. Well, obviously, very few people care, because there haven’t been that many applications. When there are multiple applications, they are often all activated throughout the lifetime of the card.

There have been a few use cases in the SIM area, but they remain quite limited.

What about supporting multiple providers. When you think about it naively, this is a killer feature. However, when you start considering liability, brand management, and other crucial factors, multiple providers are at least annoying.

NFC is bringing great hope in this area, because the whole NFC story requires multiple application providers to be represented on the same card or token. However, there still isn’t any guarantee that this issue is not going to kill the NFC story.

High-level protocols. Well, here, the pain almost gets personal. At one point, I was one of the promoters of Java Card RMI, and I remain proud of our 1997 demo. 10 years later, we know for sure that nobody ever used it commercially, and last year, I even asked Sun to deprecate it officially from the Java Card spec.

Basically, smart card developers have no say in application frameworks.

Standard protocols are very standard elsewhere, but the standard for cards is APDUs.

Adoption of Smart Card Web Server has been minimal so far, and the main blocking point is that handset vendors have been very slow to support SCWS on their devices, and also that they are reluctant to support a high-speed interface with the SIM.

All of this may have sounded extremely negative, so some explanation is required here

First, cards are tokens. The primary use of a banking card is authentication; a banking card may be a programmable authentication token, but few people tend to see it as an open software platform.

Of course, this first example is a bit simplistic

A SIM card definitely is more than a token. Many people realize that applications can be downloaded into it. In fact, operators have been using STK applications for many things, and they largely benefitted from it.

Well, that may in fact be part of the problem. The mobile operator is the only one that benefits from the SIM card, sometimes with a few close partners. In an open and connected world, such a closed platform rapidly loses value. This business model was very nice last century, but it doesn’t look like the best one for this century. And also, handsets have largely overcome the limitations that led to SIM Toolkit in the first place

Basically, STK is toast, it’s a thing of the past.

NFC, of course, will solve all that. Sure, NFC will be put on SIM cards. If you have the impression that you have seen large NFC deployments with mature business models, please let me know. Most of the ideas I have heard about are very much closed and competitive, bringing little value on the card, except the dematerialization of already existing cards.

In such a context, innovation is a true challenge.

OK, all that did not seem that optimistic, so is there a future for cards?

First, cards have a few assets. They are secure, of course, and this conference is going to be all about this. They are also small and relatively cheap; even high-end smart card you can imagine only costs a few dollars to produce, which makes it one of the cheapest computers available. In addition, because of the application frameworks, and because of GlobalPlatform and similar specifications, smart cards are manageable: protocols exist to manage the content on these cards.

Finally, cards are personalizable. The smart card industry is very good at producing billions of tokens every year, putting one person’s data on each token, and sending the token to the right person. Mobile phone manufacturers don’t know how to do that.

Overall, a smart card is the ultimate personal device. It is interesting because it is attached to a person, and this is its most defining property.

The environment is also changing rapidly. All our services are moving to the cloud, where everything is more or less interconnected, and where all data is readily accessible. The cloud solves a lot of problems, but it also raises one, about identity. Just like for cards, many technologies exist, but nobody seems to be able to find the appropriate business model. Maybe there’s something here.

Then, there is the mobile. When we are using our mobile, we are most often thinking of here and now. When I look for a restaurant on my home computer, I may be looking for a restaurant to organize a birthday party in 3 months. If I do it with my mobile, I am most likely looking for a place to eat in the next few minutes. In addition, a mobile is a generative device, that we, or at least our children, use to create new content and publish it instantly. Finally, a mobile is interactive; we can interact with it, but more importantly, we can use it to interact with others, like the Paypal mobile application where we bump phones.

If we combine that, we all live in a cloud. In this cloud, there is ME, and things become interesting because there is also YOU. Things become really really interesting because we are both HERE. And then, we get in a relationship, and we want everything in this relationship to happen naturally. And especially, we don’t want this cloud to get in our way.

To make things happen naturally, we need at least two things: First, we need context, with the right mix of local and distant factors to make a great user experience. Today, this user experience often involves a mobile application and a few sensors. Then, we need trust, and here, we need to remember what trust is about: trust is about lowering security barriers because of the current context.

Now, this opens a few doors.

Well, these doors may be opening, but I wouldn’t say that everything is clear in that direction. So, let’s take some time to look at a few research challenges.

First, open card platforms. I said earlier that the technology was here. Well, I was lying. Some things are missing.

One of the main issues we face today is making sure that the security level of a smart card, token, service, whatever, is predictable. Or at least, predictable enough to ensure that we get the security that we need to implement a service. This is the main shortcoming that we face today in terms of interoperability: platforms can be guaranteed to do the same thing, but it remains hard to ensure that they present a common level of security.

And when that will be addressed, we will then need to ensure that this security level remains predictable over time, both in the presence of new attacks and in the presence of hardware and software evolutions. Here, we have challenges across the board, and in particular in the area of certification, which becomes very hard to manage in an interoperable and maintainable way, AND with a sustainable cost. Basically, what we need here is not sustainable development, but also sustainable certification.

Next, let’s remember that we are interested in developing smart card applications, so we should also concentrate on the competitive advantages of smart cards in comparison to smart phones, the cloud, and other devices. Well, one of them is the privacy that can be achieved through a good level of confidentiality and integrity. Some things can be kept more private on my card than anywhere else, just because smart cards are more difficult to break into.

Another one is availability. If you are a traveling smart phone addict like me, you know what I mean. All these wonderful cloud-based services disappear when your operator tells you that it will cost you 50 euros for 2 days of unlimited data roaming. And then, you get angry that Google Maps is not able to use a cache to hold map information that you looked at just before to go, and that has become unavailable when you most need it. Well, maps may not be the best example, but local data stored on a smart card is always there when you need it.

Another one is control. You can decide for instance that some content in the cloud may be available to others, but only after an explicit authorization from yourself. Well, if the crypto key required for the authorization is stored on your local smart card, you know that the only way to access your data is to go through that key. Nobody can access my private data when my phone is off.

That may not be the best use of locality, but it is compelling in the sense that it provides a level of assurance that is difficult to achieve with a cloud-based application. Finding these uses definitely is a strong challenge for the smart card community.

OK, the next challenge starts by admitting that “We will not win”. Mobile devices will be around, and applications will continue their migration to the cloud. A card is never by itself, including when managing security. Let’s consider mobile authentication: in most cases, some interaction is required, which will be handled on the mobile device, possibly through a specific secure UI, which offers some level of security guarantees. Also, in most cases, a remote server will be used to verify the signature or whatever proof of authentication has been generated by the card.

What I mean here is that smart card security must be thought at the system level, at least to make sure that the use of the card actually brings some value to the system. For instance, let’s consider a One Time Password System, in which a password is displayed on a mobile phone in order to allow a user to connect to a mobile banking Web site on a PC. We can claim that computing this password on the SIM card is mandatory for security, but the reality is that the security improvement comes from the fact that the credential is computed on the phone and used on the PC: what is the probability that a hacker has taken control over both your PC and your phone? Low, or at least much lower than that it has taken control of your PC. And that’s what count: making attacks more difficult. So, when thinking about smart card systems, let’s not forget that the smart card is inserted in a larger system.

To take a recent example, Cambridge’s man-in-the-middle attack on Chip&PIN is a perfect example of system integration gone wrong. The EMV protocol is correct, but it makes it hard to implement correctly, and of course, some banks didn’t implement it correctly. This should be predictable, so why did it take so long to find this out?

Now, let’s consider one of the most interesting factors in the system: the human. We humans are an endless source of bugs and problems, and most likely the most unpredictable part of the system. This means that one of the major objectives of any computer system should be to make sure that the human factor will actually work.

For security, this is extremely important. Humans will choose 1234 as passwords; if you force them to use complex passwords, they will write them down or use the same password everywhere. People who don’t understand that end up forcing us to change our complex passwords all the time and make our lives miserable.

Understanding the human side of security and trust is extremely important, especially in a mobile environment, because we focus on human interactions.

The final challenge is by far the hardest: how to get to trust, of course using smart cards?

Basically, trust is about protocols between users, devices, and servers. And it’s about authentication and authorization. The idea is here to ensure that we have the protocols that we need, and that they provide the appropriate security level. I don’t want to deploy a full PKI infrastructure just to control how photos of me get tagged on Internet, but I would like to have some control over this. So, how should I do that? There is definitely room.

On that area, I am a big fan of Telenor’s work on Wifi-enabled SIM card, and in particular of Thomas Carlyle’s Master’s Thesis about trust models in Wifi-enabled smart card Web servers. It is just a starting point, but it links important things.

One last point here is the research community also happens to be a community of educators, who teach students, write textbooks, etc. Here, there is a tremendous work to be done on the education of users on trust topics: how to make users actually care about this important problem? And in return, maybe that we can learn from the users about how to propose solutions that actually meet their requirements.

We are getting close to the end, and no mention so far about app stores. So, where is our smart card app store? Well, you may have guessed that it is quite unlikely to come. I am not saying that smart card software will never come together with an app store application, but we all have to realize that smart cards are actually in most cases part of an infrastructure, like SIM cards are an important part of a network operator’s security infrastructure.

As such, they are important, but they won’t get app stores, because they are lacking one important thing:

Color. Interactivity. What users want to get from an app store are services, interactive services. These services may use smart cards in their implementation, some may even rely heavily on smart card services, like SIM Toolkit or another technology. But in the end, users want a mobile application.

This doesn’t mean that smart cards and smart card research are useless. The computing infrastructure behind internet has never been as complex as today, and smart cards have an important role to play in bringing trust and locality to these systems.

But sorry, no app store for us.

Now, let’s go for the (live) meat. With cloud computing, it is hard to figure out where my computer is in the world, mostly for fiscal/manpower costs reasons. However, this has an impact on government, because governments may want to control where the data actually is.

In terms of security, the three words that come to mind are: Identity, Policy, Privacy. More precisely, Privacy comes with control, choice, and ownership; policy comes with rights, law, commerce, justice; and Identity comes with authentication, authority, reputation, persona.

In the cloud, the new social order is about virtual machines talking to other virtual machines. We started with personal computers, with a model centered on the individual, we then move to networks, centered on the group, and the current network of virtual machines is centered on congregations, close to full human societies.

Next, we get an overview of Maslow’s Pyramid, with a long explanation of bulla (mesopotamian smart cards). Now the question is: how does this scale apply to computers, as they get organized in complex societies, closer to human societies?

Next, Bertrand outlines the link between identity and trust. The first kind is differential identity, or trust by causality (basially, what you are): the second one is experiential identity, or trust by process (basically, what you own/get, this has been formalized in subjective logic). Something interesting is that humans have in history been identified mostly by process, whereas computers are more in causality. More and more, computers are being identified through reputation, and humans through biometrics.

Next recreation, about the compared trust infrastructures of United States and France/Europe. The Declaration of Independance and Déclaration des droits de l’homme et du citoyen are basic trust infrastructures, on which constitutions were built, and then, law systems, etc. It shows that the trust infrastructure is on top, followed by policy infrastructure, and that the same thing should apply to computing.

We then get to the main slide, about emotion and identity. Bertrand introduces a paper by Sheldon Stryker, Integrating Emotion into Identity Theory (2004). Identity is here about status, and when status goes down, emotion kicks in because we get upset. The main thing is about mirror neurons, in which the same neurons re excited when we eat and when we see somebody else eating. And this process is important, because it is about sharing emotions.

Next, privacy. The main statement is that “Privacy is the provisioning of identity”.

Finally, we get a Maslow scale of computer needs, which of course is topped by Computer Theology (recursive trust/policy infrastructure), reputation, and intimacy.

Well, that’s it, and that was pure Ducastel: cluttered, confusing, but full of interesting and inspiring bits.