• The device performs its tasks normally, but the attacker also runs other software on it, for instance to make it participate to DDoS attacks.
• The device apparently works normally, but its behavior is somehow altered, for instance by providing wrong information.
• The device doesn’t work or obviously dysfunctions, for instance a car that won’t start.

A second factor to analyze the consequence of an attack is the duration of the attack, or the delay until recovery. Here, we can consider four situations:

• Until next reboot. I am confident that the firmware hasn’t been modified, so a reboot will remove the attack vector from RAM and address the problem.
• Until next hard reset. I am confident that the device will not boot on modified firmware, so a hard reset will restore a « good Â» copy of the last known correct firmware.
• Until next update. I am not sure about the full firmware, but I know that a firmware update will remain possible and will address the issue.
• Until replacement. The firmware update mechanism is corrupted as well (or the device is permanently damaged), so the only solution is to replace the device.

We could go further, but let’s stop here for now. The impact looks essential, but the differences between the three scenarios aren’t that great. An obvious dysfunction is bad, but a device whose behavior has been altered by an attacker can be just as bad, and a device that is controlled by a hacker can easily become dysfunctional. In all three situations, it is obvious that some fix is required.

That’s where duration and recovery are important. The two first options (reboot and hard reset) are only temporary fixes. Even if the attack is transient and can be removed, the vulnerabilities that made the attack possible are still present, and the attack can be reproduced easily. Ideally, a reboot or reset/restore must be accompanied with some operational restrictions (like a “safe mode”) until an update is performed.

What we are analyzing here with recovery methods is resilience, or according to Random House, “the power or ability to return to the original form, after being [attacked]”. It is a valuable property for systems that are submitted to high levels of stress. Resilience is about recovery, in opposition to resistance, which is about protection.

Resilience and resistance are complementary. Resilience is often considered easier to achieve than resistance, but maybe more importantly, resilience may still happen when resistance has failed. Even if an attack on a system has been successful, its recovery is possible is the system is resilient to that attack.

We can here use an analogy with resilience against natural disasters. Although a hurricane can cause massive destruction to coastal areas, (resistance is limited), most U.S. coastal areas are resilient against hurricanes because hurricane evacuation routes have been defined, and shelters are ready to host evacuated people. Such resilience measures rarely fail, and we are shocked when this occurs, like in New Orleans after Katrina.

For an embedded device, resilience is mostly about:

• Secure boot, to restart from a clean sheet upon reboot, and detect a potentially persistent attack.
• Firmware update, to load a new version that is not vulnerable to the attack.

More generally, resilience can be achieved through simple infrastructure means like roads and shelters. In the case of connected devices, resilience can be achieved through low-level features, within or below the operating system, and highly independent of the use case.

However, although resilience mechanisms are simple, they also need to be very robust. A hurricane shelter must be built on high ground with strong material like reinforced concrete that offer strong guarantees of resistance against a hurricane. Similarly, the secure boot and firmware updates of a connected device must be designed and implemented to resist attacks. In both cases, this resistance is easier to build because it is applied on a smaller scale, and it is mutualized:

• Smaller scale. A shelter is a single building, typically used for other purposes (like a stadium) that is relatively easy to reinforce. Similarly, a secure boot is a small mechanism, so is the security-critical subset of a firmware update mechanism. These mechanisms offer a small attack surface, and are therefore easier to protect than an entire software stack.
• Mutualized. A shelter is shared by all members of a community, who will use it together in case of emergency. Similarly, secure boot and firmware update are independent of the device’s role and application. The development and reinforcement efforts can therefore be mutualized, reducing the cost for every device.

Resilience must be proactive

Resilience is the capacity to recover from an attack, and as such, appears to be a highly reactive technology, that comes after the fact. It is of course true that resilience mechanisms are triggered after the fact, but in order to succeed, they need to be proactively prepared.

Just like evacuation routes and shelters need to be planned in advance and designed to resist a hurricane, resilience measures in IoT devices similarly need to be prepared beforehand. A firmware update mechanism is crucial, and it needs to be prepared with great care proactively. In particular, this mechanism must be designed to be highly resistant against attacks.

In the world of connected devices, we know that resistance to attacks will be difficult to achieve, because it requires a very large investment from vendors to fix all vulnerabilities and make their systems resistant to attacks. Resilience, on the other hand, can be achieved on a wide scale with a limited budget, and has the ability to provide a strong basis on which IoT security can gradually be built.

• Personal. Mobile phones are becoming some kind of personal hub, on which all communications means are concentrated, in particular around social networks. A teenager’s mobile phone is likely to be the electronic device she uses most throughout the day.
• Universal. Everybody has one. In some countries, this has been a reality for adults since a few years, but it has now expanded to most of the world, and in developed countries to most kids 10 years old and over. The trend is easy to see.
• Connected. By definition, a mobile phone is connected. Internet connections are becoming more and more common, almost universal in some regions of the world. And in other regions, the SMS medium is available and used for a wide variety of services.
• Generative. Mobile phones generate content, from pictures and audio/video recordings to positioning data and movement information. More sensors are added regularly, endlessly increasing the device’s awareness of its operating environment.

All of these features, when put together, make us realize that mobile devices are becoming ready to be used in our everyday life to establish a bridge between the real and the virtual world. As Google’s Eric Schmidt commented when discussing the addition of NFC connectivity to Android, “these things are so highly personal and (…) location-aware” that we now need to think “mobile first.”

What excites people like Eric Schmidt about mobile phones is the ability to accompany the consumer throughout the buying decision process, until the final transaction between a consumer and a merchant. This ability to conduct transactions in the real worldis the main difference between a mobile and a desktop.

And of course, as we start talking about transactions, money becomes involved, and trust becomes an issue for all stakeholders. If you consider Internet payments, banks and vendors have recently introduced additional verification methods in order to restore trust. Similarly, a significant percentage of Internet users remain afraid on shopping on Internet, often because they don’t want to disclose their credit card number.

The challenge for mobile trust is to address these issues better, designing a solution that allows the establishment between stakeholders, in a way that is trusted by all these stakeholders. This challenge is not an easy one, but some systems are emerging with partial solutions, that we can use to illustrate the design principles.

The first example is the M-Pesa mobile financial system used in Africa. It allows individuals to exchange money using their mobile phones in a very simple way, providing a financial infrastructure to countries in which banks are rare.

The second one is the Bump application, which allows two individuals to connect (or agree on a transaction’s terms) by simply bumping their phones together. This is a simple, straightforward technique, uses the generative capacity of a mobile to bridge the real and virtual worlds.

Now, here are the design principles:

• Make mobility matter in the real world. Mobile trust is not about simplifying the entry of credit card numbers by selecting a virtual card in a mobile wallet. It is about using the qualities of a mobile to establish trust between two individuals, like Bump does, or between an individual and a (local) service provider.
• Focus on the details of the actual service. Mobile banking is boring. Mobile money transfer between individuals already sounds better, and it sounds even better with the detailed description of a very simple mechanism, like the M-Pesa process. So, let’s be specific and work on the details of the user experience very early in the design process.
• Put the human at the center. Trust is essentially needed between humans, and the process necessarily involves humans. So the human must be at the center. First through the user experience, making sure that our service is usable, without cumbersome steps. Second through our brain and psychology, using our intelligence and intuition in the trust establishment process.
• Design around trust, not security. The essence of a transaction system is to establish the trust between two entities; the result is the trust relation, not the security. And we must always remember that the very definition of trust is to reduce the security measures once it is established.
• Build it securely. Last but not least, we need to deal with the implementation. That’s where security becomes important, making sure that we are able to build a system that matches our security assumptions. The main difficulty is here to correctly assess the level of risk, and to choose the security measures accordingly.

This is the recipe for success in mobile trust. All we need to do now is to define a list of ingredients, in order to bake a tasty and tangy mobile transaction service. Of course, we’ll also need to sell our produce, but that’s another story.

On the technical side, these financial applications are all SIM Toolkit applications. This means that the applications are actually running on the SIM card, simply delegating the interaction part to the mobile. The interface with the remote servers is usually performed using SMS. Of course, this is a financial system, so the level of security must be sufficient to reduce fraud to a minimum.

Among the features that contribute to the security of the system, we have:

• Private network. Mobile networks are private, which makes them more the information that circulates on them more difficult to attack than the information that flows on Internet.
• Application running on the SIM, with some cryptography. SIM cards aren’t the most secure smart cards, but getting access to the data stored on a SIM card remains a long and difficult process, even for card evaluators. So, stealing/forging keys is hard.
• SIM Toolkit driver buried deep in the phone’s software. Since the application logic is on the SIM card, the mobile phone only provides a generic driver that manages the user interaction. This driver is handled by the phone’s baseband processor, which is usually not the most accessible piece of software. As a result, it is difficult to attack this interaction

Don’t get me wrong; I am not claiming that the system cannot be attacked. I am just claiming that the inherent security properties of SIM Toolkit applications are sufficient to guarantee the security of the small data transfers performed daily in developed countries. Now, if you want to use that system to buy a €500,000 house, I may want to take a very different stand.

Actually, the main reason for which this reasoning cannot be extended to developed countries is that SIM Toolkit definitely went out of fashion with the advent of smartphones. The STK text-based interface is simply not acceptable on today’s phones, where we expect fully interactive applications.

That means that our current status is quite different with our smartphone applications:

• Internet connectivity. Forget the private network, we are connected directly to the Internet, and that’s where we want to do our transactions.
• Mobile applications. We get our applications from our local application store, so protecting data (both in storage and in communication) is a bit hard.
• Customized interactions. We like our interactions to be customized for each application. In many cases, the interaction at least partly comes from Internet, and HTML5 is going to make this more common. Here, no need to attack a low-level device driver to get to our stuff.

So far, this is fear-inducing rhetoric. You should be afraid, because your applications are not secure. Yet, there aren’t that many attacks, and mobile transactions are becoming more common on phones. With the announced success of NFC and the announced Google wallet, the future is looking bright in 2011. One of the reasons is that secure elements are becoming fashionable again on smartphones. Another one is that Apple, Google, and the others are keeping a rather tight control on our devices, and the users feel safe. Jailbreakers pose a small problem, but this is marginal for transactions (hint: if a payment application gets hacked on your jailbroken phone, “losing” the phone and denying the jailbreak sounds like a good option). Overall, I have no problem performing transactions with my phone today.

The really interesting question is: Would I feel just as safe if one of the financial app became as popular as M-Pesa is in Africa? A financial transaction application installed by 50 million users in Europe and the U.S. would sure make a tempting target for hackers around the world, especially with the average balance of our accounts.

In such a case, I would be tempted to say that the various stakeholders would like to have a few additional guarantees. The smart card and security industries have some answers to that: Let’s perform Common Criteria security certifications on cards to prove their security! Let’s add a security layer in the phone to enhance its security! Let’s obfuscate this application to make it more difficult to hack!

All of these things work, and some of them even work well. Each counteremasure makes the cost of attacking the system slightly higher. But all these things provide incremental improvements, and they are definitely not disruptive. Disruption is more likely to come from the outside, from the “hundreds of start-up companies” promised by Eric Schmidt around NFC.

An example: Bump. It is not about NFC, but it is a mobile security measure that “makes connecting as simple as bumping two phones into each other”. It relies on humans to perform most of the security checks, and leverages this on Internet. This is the way to go as our mobile devices become more personal, as they get closer to actually representing us on the Internet; the human being who holds the device will need to participate actively in the security protocols, and not only be entering a code. Disruption will come from those who make the security experience better, not from those who make the mobile experience more secure.

The first question is to understand how privacy and trust are similar and different from the typical security issue. A first interesting thing is that the smart card industry is one of the rare industries that is able to ship 4 billion personalized objects every year. That makes it suitable for use with companies like Google or Yahoo! who deal with hundreds of millions of customers.

The kind of things that smart card vendors usually propose in the Web arena are the following:

• Two-factor authentication. This can be provided in the form of OTP (one-time-password) applications, or solutions reusing the eID infrastructure using in goverment applications.
• Privacy enhancements. A card may securely store credentials, and only release them as needed and required (with appropriate proof), without disclosing the entire information. Think of a system that would simply assure that you are over 18, without disclosing your name.
• Identity management. Identity with a token can improve authentication with Web mail, instant messaging, and more, and then allow the enforcement of better access control policies.

The next issue is to figure out how this matches the needs of digital security, which are as follows:

• Protecting our digital identities. That’s something where smart objects can bring an immediate value, as we have seen ajust above.
• Protecting our digital assets. Our assets on the Web are very varied (contacts, images, and all kinds of content) need to be protected, from other people, and also from the Web service providers, who may be tempted to abuse them.
• Protecting our e-transactions. Online transactions today are often very simple, and involve a low-level of security. There are proposals from the smart card industry, but they do not always match the requirements of Web service providers.

This view is very valid, but it is also a very traditional view of digital security. It may be more interesting to look at the things that become possible when our digital assets are well protected. By bringing more security, we bring more value and more freedom to the users, because there will be new ways to exploit these assets, which are not possible today. Eventually, mandating a higher level of digital security brings more choices to the end user, not less choices.

If we dig a bit deeper into Web services, we all love them because of their ubiquity. They are accessible from anywhere, they don’t put constraints on us like updates and backups. We love this, but we also need to be aware that there is a tradeoff between availability and security.

As an example, the tendency towards free, viral services that later monetize their user’s data suffers a few exceptions. In particular, there are few such services around money management and personal health record management. This means that most users don’t place enough trust in Web services to allow them to manage what they regard as their most sensitive data. The kind of issues that Web services face include the following:

• No network, no service. This is slowly becoming a thing of the past. Slowly in some cases (roaming, for instance). We can provide solutions, but they should not be our main focus.
• Security limited to username and password. There isn’t much worse in terms of security.
• Privacy. Users basically have no choice. You need to accept the service provider’s conditions, or use another service.
• Trust. There are no standard metrics to establish trust like there can be in the smart card business.

If we focus even more on security, privacy and trust, the challenges for Web services are as follows, from the user’s prospective:

• Identity theft.
• Unclear data access control
• Unclear service definition
• Unclear terms and conditions

Another aspect of things is data protection, which is another set of user worries:

• Storage. Where is my data? What is the disaster process? How are permissions set? How can I control the access to my data?
• Revision Management. Is there a tracability of the changes? A possibility to be warned of canges? A possibility to track changes and review them later?
• Life cycle (retention/termination). How to terminate hosting data?

Next, we get into the heart of the topic: what is it possible to offer from the smart secure devices point of view? The first initiative is about transforming the World Wide Web into My Web, by combining several aspects that restrict accesses:

• IP Geo-Localization. Make some services accessible only when I am located in a given area or set of areas.
• Appliances ID restricted access. Make some services accessible only from some computer (based on a more or less secure characteristic of the computer).
• Time restricted access. Make some service accessible only at a given time, like allowing children to access instant messaging only between 4:00PM and 8:00PM.

Next, there are solutions for data protection:

• Data encryption, RAID applied to data centers, with smart secure devices controlling it.
• Smart Secure Devices acting as Proxy server. Re-route SOAP messaging via a proxy, and apply some filtering at that level.

The last idea consists in plugging a Smart Card Web Server into a fixed device (for instance, a home gateway, or “box”), and to make it accessible from Internet. Such a device can have many uses, and its main advantage is that it is not with you at all times. There are many applications for this, ranging from basic secure proxy/filter to two-factor authentication. Of course, there is a trick here, since your second factor is actually on the Internet, so you will need to use a different kind of credential on these things, to prove who you are. One of them, provided by Xavier Larduinat, consists in presenting you the pictures of 20 random Facebook members, including your friend Alice, and to ask you to click on Alice’s picture. I’ll come back on authentication in later posts, because there are many new ideas in this area.

To conclude, Eurosmart pushes in favor or regulation, in particular at the European level:

• Rules about identity ownership and accountability.
• Data protection as a fundamental right

Such regulations could be interesting, mostly because they would facilitate the establishment of trust between users and service providers, which would in turn make the development of new services, based on that new trust, that could grealty enhance the user experience.

Basically, telecom operators are often taking the dreaded role of “pipe” operator, as they don’t really sell anything to their users beside connectivity. In the end, could this become an opportunity?

The lack of control of operators over their customers can become an advantage if operators start acting on their customer’s side, and help them build relationships with other entities, basically acting as a fourth party. Trust is an important component here, and operators are usually trusted by their customers, at least in some respects. After all, they are the ones that guarantee that we only get billed for what we consume, and they protect us against the bad guys out there on the net. And this trust can help them become a fourth party, which can bring an interesting revenue, as all lawyers know.

Of course, major operators also have a bad reputation of trying to squeeze every cent out of their customers’ pockets, and to use the ARPU as main measure of performance. The solution could be to setup a MVNO or a VISP, in order to start clean with a company that has no bad user relation history.

Of course, other actors have had problems selling advertising and connecting to partners. Microsoft, for instance, could attempt something on behalf of users. Of course, that would imply that Microsoft is able to honestly take their users’ side. Unlikely.