In the following years, we wasted a lot of time working on a much more ambitious version of Java Card, which never made it, but we never worked on addressing this issue of unverified bytecode, mostly because we had the cryptographic protections provided by GlobalPlatform. If nobody can load unverified bytecode, where is the problem?

As an evaluator, this allowed me to reverse engineer many types of Java Card, as I was allowed to download unverified (and very much illegal) bytecode into cards. Over time, most virtual machines have included runtime countermeasures, and some implementations have been difficult to attack with illegal bytecode for quite a while.

Yet, Java Card has become an industry standard. Strong implementations exist, in which loading unverified bytecode is about impossible, and then, exploiting unverified bytecode is challenging. But on the other hand, weaker platforms also exist, and recently, following a combination of mistakes from various stakeholders, one of them was broken; luckily, by a researcher, not by a criminal.

The real surprise is not that this has happened. It is that it took over 25 years for it to happen. The lack of on-card verification has always been a weakness in the Java Card story. Over the past 25 years, there have been a few attempts to address the issue, but the industry never adopted them. Isn’t a solution to this issue a bit overdue?

The smart card industry is a small industry, with few actors, and Java Card has been a great success, its interoperability providing the basis for the deployment of billions of products every year. But the industry has been complacent, and although I am not part of it any more, I bear some of this responsibility since I have headed the Java Card Forum’s Technical Committee for a few years. I defended off-card bytecode verification many times, for instance in 2011 and quite vehemently in 2013.

But that was over 10 years ago, and I would now argue that it’s time to fix this issue. Despite minor updates, the core Java Card technology is over 25 years old. The similarity between the latest version of the Java Card Virtual Machine specification with its first interoperable version is striking. There have been almost no changes. The CAP file format is antiquated, and an update could allow all vendors to ensure that no illegal bytecode is allowed to run on the any card.

From a now outsider’s viewpoint, I believe that after the recent developments and an issue impacting the security of millions of unsuspecting users, the usual denials sound really out of touch with reality, so I am asking the Java Card community a simple question: Since you are pushing for Java Card to be the basis for our personal security, and asking us to trust you with our sensitive data, including our identity, isn’t it now the right time to put this bytecode issue behind us once and for all?

What? This includes my kids’ Honor-branded phones, and as far as I know, a significant portion of the kids in their middle school, as Honor has been proposing phones with a great value for a few years, and they are popular in that population who are usually not getting the top-of-the-line models.

I could also have titled this blog more provocatively as “Google denies basic security to their customers,” “Donald Trump throws millions of kids in hackers’ hands,” or “Evil Americans exercise extra-territorial power over people around the world.” There are plenty of opportunities here to be angry, but the problem is elsewhere.

There is here a trust and liability issue. When I buy an Android phone, I expect some service from the vendor, but I also expect some services from Google. In my professional life, I am battling for improving IoT security, making updates mandatory and secure, among other things. Until now, this was a battle against slackers and profiteers, but today, politics is getting in the way. If hackers benefit from this, who can be held liable? Is this just Huawei? Doesn’t Google share some responsibility for stopping their support? My kids have done nothing, for sure.

Most comments seem to emphasize that Google dealt a big blow to Huawei, but Google has also dealt a big blow to themselves: Huawei didn’t cut my kids’ updates, Google did. This really has some consequences on the Android model: When you buy a phone with Android, you introduce a dependency between you and both the device vendor and Google, and you will be a collateral victim if their relationship turns sour. This almost sounds like Apple; when you get an iPhone, you belong to Apple, but at least, only to Apple.

It makes me rethink seriously my dependency on Google, so it’s time to take some strong decisions. I will switch my family streaming subscription from Google Play Music to Spotify, just to make sure that my kids still enjoy music on their unsupported phones. And if this madness continues, I will move them to Huawei’s app store as well…

There is also intent. A vulnerability is only dangerous when an attacker actually decides to exploit it. The problem with intent is that it is definitely not obvious to measure, especially on new risks by new kinds of attackers. Here we can oppose two theses, between Bruce Schneier’s core theory from Click Here to Kill Everybody and James Andrew Lewis’ theory from his 2016 Managing Risk for the Internet of Things CSIS report.

Terrorists and Enemies

Lewis’ reasoning is that we have been promised major cyber disruptions on traditional internet for a long time and that we are still waiting to see one. His reasoning about terrorists is interesting, as he explains that terrorists tend to prefer tactics that include “direct action, bloodshed, and political drama.” I agree with him, but I still think that a terrorist group with the same financial means as the 9/11 commandos could very well use IoT today as an amplifier of their attacks, for instance by having a botnet contribute to the chaos by attacking key services.

The main difference between Lewis and Schneier, though, is about the likelihood of exploitation of IoT vulnerabilities in the context of war. Here, the assumptions are different, as Lewis considers that a massive cyber attack would be deterred by potential response from the U.S. whereas Schneier considers that (1) it could be useful in the case of an already started war, and (2) that the difficulty to attribute an attack could lead to misguided retaliation or to the absence of retaliation.

Consequences

There are also a few significant differences between Lewis and Schneier on other topics, which I outline below:

• About consequences, Lewis mentions that “most vulnerabilities found on IoT devices lead to events that would qualify as pranks.” He acknowledges that botnets can be created, but he dismisses them by mentioning improved defenses against DDoS attacks. Schneier is much more cautious, and I would be as well. Botnets could be used for other things than traditional DDoS, for instance for attacking other vulnerable devices.
• About cyberwar, the same difference in considering only repetitions of existing attacks leads to similar differences, where Lewis dismisses the risk of potential consequences of a full-scale cyberwar.
• Finally, Lewis considers that the risk will decrease as we get more familiar with the technology, and our experience grows. This is partly true, but it is only valid if we build experience fast enough to offset the increase of risk due to continued deployment of new technologies, which is not obvious today.

At this level, we are talking about opinions and predictions. Depending on whether you believe that history repeats itself or that we always get interesting new things, the conclusions are different. Well, my motto for 2019 still is “The times, they are a changin’ “, so I believe in the unpredictable.

Does it matter?

Note that it doesn’t matter that much. The conclusion from James Lewis does not differ greatly from Bruce Schneier’s. In the end, he recommends that the government “can accelerate risk reduction with the same methods we use for general cybersecurity: research, liability, infrastructure and regulation.”

The IoT insecurity issue may not be of apocalyptic scale, but it nevertheless remains an issue that needs to be considered by governments.

In this early 2019, the Road to Bandol can be quite dangerous, as exemplified by the video below:

Yep, that’s the Bandol toll barrier burning during a gilets jaunes demonstration. I am not sure to be fully sympathetic to these gilets jaunes, but they represent the French way to signal major unease in the population: rioting.

What they want is not clear, but what they express is very clear: it was better before. And I have to admit that the latest serious books that I have read kinda make me feel somewhat like this:

• Bruce Schneier’s Click Here to Kill Everybody: Security and Survival in a Hyper-Connected World promises us an IoT apocalypse that sounds just plausible to me.
• Yuval Harari’s Homo Deus: A Brief History of Tomorrow promises us another dystopian future, where AI is the scary thing, and gives a good background to the gilets jaunes by his description of the current failure of the capitalist religion.
• Research book Agnotology: The Making and Unmaking of Ignorance provides chilling insights into how fake news is just one of the ways to build ignorance of the masses willfully for the benefit of a few.

I guess that the year 2019 is going to be interesting, but it takes me a lot of positive energy to be optimistic about the near future. But then, who knows, because

The times, they are a changing…

So let’s go for a good change.

This is not the new normal, just a pit stop on the way to decades and decades of deteriorating conditions.

Nothing that I didn’t know, but a nice way to remind us that talking about the “new normal” is completely wrong: Things will become much worse before they get any better. And the more we wait to act, the more painful the impact of changing climate will be.

As a citizen of a developed country and most likely a member of the world’s 1% richest, I am not doing much to curb our energy consumption. I proudly bike to work, I try to isolate my house, but I still put my entire family on an intercontinental flight for the vacations. I feel the need to act on the climate, but I don’t seem to be able to decide what to do. I can blame my government (easy), Donald Trump (easier), I can request action, but in terms of actions, I am most likely not doing my share.

I am not a climate expert, and that may explain my questioning. Maybe that I should ask one of these experts: What should I do, myself, very practically? What are you doing yourself?

Beyond climate change, we have other, smaller threats to face, like IoT (in)security. And this time, I am an expert. Interestingly, IoT security shares some characteristics with climate change, including at least:

• It’s a time bomb, as the insecure devices that we deploy today will still be around tomorrow, and may come to haunt us in a few years.
• The problem is global; anyone’s vulnerable device can be used to attack somebody else’s IT service, just like any person’s CO2 contributes in the same way to global warming.
• Many citizens understand the risk (security is a top concern for IoT), but very few know what to do to lower that risk.

As an IoT security expert and a user of IoT devices, then I need to ask myself the question: Eric, what do you do about IoT security?

• I monitor my network. I have a device at home that lets me know when unknown devices come on my network or when strange things happen. I caught a few things with this, so I am happy about it.
• I use diversified passwords, and sometimes, 2FA (two-factor authentication). However, it took me years to move away from bad practices; I am still not using 2FA wherever I can, and I am still not forcing my family members to use 2FA. I even haven’t changed at least one password that appears on haveibeenpwned . Overall, I am not too happy about this.
• I have no clue about the security of the devices I use. This is bad, but I am just a customer here: my hacking skills are rusty, so I am not going to pentest all the devices that I buy and deploy at home. I have no other way to know, and I am not happy about it.

Since the beginning of 2018, I moved into a job working on the definition of security certification for IoT. When I started, my perspective was to maximize security vertically, making products more secure; that sounded natural for a chip vendor with a strong security background. After only a few months, my priority is now to maximize security horizontally, reaching as many products as possible; that is just as good for my company because our high-security chipsets are useless in a world full of default passwords and other trivially exploitable vulnerabilities.

We need security certification, we need it to be as simple as possible, we need it to be as mandatory as possible, and we need it as soon as possible. Simple? Because some good people trying to implement IoT security fail at it, and we must help them. Mandatory? Because some people think that IoT security is not their problem, and we must force them to act. Soon? Because as the clock is ticking, vulnerable devices are accumulating.

Finally, what can you even if you are not an expert? You can try to apply some good practices, and you can also ask your elected representatives to act on behalf of the community. And as you’re at it, also ask them to act on climate change.

Until recently, life was easy, and we could define levels easily. Since 3 is a magic number for levels, here is a definition that I penned myself:

• Low. Risks on individual goods and personal assets.
• Medium. Risks on collective good and community assets.
• High. Risk on human lives.

This classification can be (and has been) criticized, but it shows the idea. If something can only hurt your belongings, it is less sensitive than a thing that can impact, let’s say, your city’s traffic lights, and much less sensitive than a device that can kill you. And of course, you expect to spend less money on certification for anything with low risk.

If you work on IoT devices, then it is easy to apply this classification. My connected toothbrush is low, so is my personal security camera. The school’s security camera is medium, though, and a hospital’s connected syringes are high.

But wait. Didn’t Mirai exploit cameras to take down community assets like OVH servers? That’s the IoT issue: my camera as a personal security device to protect my house has a low risk level, but the same camera as a member of a botnet has at least a medium risk level, possibly a high if the next bad guy decides to attack emergency services instead of Web hosting services.

This is very hard to capture in a 3-level unidimensional classification. Yet, as we move towards certification of IoT devices, we need to include this collective risk. It is not enough today to consider what a device is supposed to do (watch my house), but we must consider what the device could do after being hacked, and even more importantly, what a large number of the same device could do after being hacked.

Here are three examples with different risks:

• IT risk. Any permanently connected device can be targeted by a Mirai-like malware and end up attacking any part of our digital infrastructure.
• Human risk. Anything with a battery may be led to overheat and possibly explode, and multiplying this could lead to havoc and multiple injuries.
• Economic risk. Sending Brickerbot (which destroys what it infects) to a large number of simple but essential connected parts (for instance, car parts) could lead to a shortage of parts and major economic damage (for instance, if cars can’t be fixed).

These risks are hard to capture, but they are significant. However, it is just not possible to label every connected object as high risk, because certification constraints are too high.

One solution is to define a Low or Basic level that includes a significant level of protection against hacking and malicious exploitation. Even this apparently simple solution is hard to define, but thinking about the problem in such terms is already a big step ahead.

So, remember: A single connected device is cute, but collectively, they can be very dangerous.

Terrorists are not easy to distinguish from normal drivers before it’s too late

In the real life of a security consultant, terrorists are a problem in a risk analysis. Whatever technology you think about can be somehow abused by terrorists, and terrorists are really an annoying kind of attacker:

• Terrorists don’t care about being caught or killed, which greatly limits the efficiency of many countermeasures, which are designed to make sure that the bad guys eventually get caught (like good logs). With terrorists in a car, the only countermeasure that works is the one that stops them immediately.
• Terrorists are often “bad users” rather than intruders, which means that countermeasures against them must be applied against users. If a car decides to crash itself following a perceived attack, it better be sure that it is actually driven by a terrorist, not just a careless driver.
• Any drastic countermeasure that is designed against terrorists may be misused by other attackers (or even by terrorists themselves) to create havoc. Self-destructing cars are not a pretty sight.

In the end, because of these and similar issues, in a classical risk analysis, terrorists are not listed among the bad guys, and if they are, they are explicitly ignored. Yet, Mark Cuban’s question makes sense, so should we do something about it? I have browsed some of the answers to his question, and I am now reaching my own conclusions:

• First, whatever we will do on vehicles now will not affect older vehicles, so terrorists will still have access to a large number of weapons for many years to come.
• The first consequence is that it is necessary to work on the infrastructure. In Nice, the Promenade des Anglais is now protected physically against weaponized vehicles. They have done a rather good job, using small poles and palm trees as obstacles.
• Also, infrastructure has an IoT component, such as the V2I (vehicle-to-infrastructure) communication. The infrastructure can therefore emit an emergency signal to surrounding vehicles when it detects a potential attack.
• Beyond responding to such infrastructure events, adding countermeasures in cars is difficult. The guy who drives on the sidewalk may be escaping from terrorists, so such countermeasures would still be hard to define.
• Any measure based on deep learning and analysis of drivers’ behavior is also very hard to define and enforce without moving straight to a police state.
• In the long term, full and mandatory automation sounds like a good countermeasure, which also addresses many more problems.

But then, none of this is easy. If we consider the emergency signal sent by the infrastructure in case of attack, there are many potential issues:

• If someone simply crashes into a barrier, who will decide that it is not an attack, and how long will that take?
• Emergency vehicles should not be directly affected by the emergency signal. But then, we need to ensure that terrorists don’t steal emergency vehicles.
• How can we refrain bad guys (terrorists or not) from sending emergency signal just to stop traffic?

There is always a trade-off between our protection and our freedom

In the end, I am not sure that we are ready yet to do anything to deter terrorists from weaponizing our vehicles. The main reason is that the security measures required to do so impose strong contraints on us. So far, we have accepted additional constraints in airports and planes, but we balk at a laptop ban in long-haul flights. And I am quite sure that our tolerance threshold in our cars is very low.

So, we should of course protect our cars from terrorists, but I am afraid that we will not do anything about it for now.

When you think about an online service’s lifecycle, it all makes sense. The service is deployed on servers sitting in a secure data center, then to more servers if needed; then, the service is updated to a new version, possibly moved to a new cloud provider, and all of this is quite transparent to users. Basically, security must be part of the normal lifecycle, continuously adapting to the new hardware, new software, and new threat environment.

IoT security is different, of course. IoT is about objects, not services, and securing objects is different. Their hardware is fixed, and people buy an object with a set of features, not a service. Things are evolving, of course: Tesla is selling an Autopilot service, complete with security and functional updates. Many smaller devices also come with online services. For instance, a remote thermostat comes with a service that monitors meteorological data, in-house presence, and many other parameters to optimize target temperatures. For such services, security is, of course, a process, like for any other online service.

Yet, most people buy cars, even Tesla models; people buy connected thermostats, even if they are useless without the accompanying online service. For most consumer connected devices, the online service is free (for life, whatever that means), but the consumer has little guarantees that it will keep working for a long time. Naturally, professional contracts are a bit clearer: companies pay for the connected devices and for the related services, but they get additional guarantees, for instance, that the service will run and support their devices for at least 5 years.

Companies usually have a business view of it: a device is supposed to last for 5 years, so it is financed over 5 years, including support and associated services. After 5 years, the device is evaluated; either it is replaced with a new one, or it still works fine and its support and associated services can be continued for a few more years. The U.S. Senate is trying to formalize this for federal suppliers.

What happens when a consumer’s connected car ages?

So, what happens when a consumer’s connected object ages? Let’s consider a connected car, for example:

• For a few years, everything goes fine. The manufacturer regularly updates the car software. The features may evolve or not, but security threats are taken care of. The servers also keep working without problems.
• After a few years, things become more difficult. Some services start to disappear, either because they are outdated and the server doesn’t work anymore, or because they are flawed and cannot be fixed. But the car keeps working.
• Then someday, maybe after 10 years, a key hardware component gets defeated by hackers, to a point that software can’t fix/mitigate. From then on, the car is accessible to hackers. So, what should be done? Should the manufacturer disable the hardware (i.e. the car)? Should they be forced to design a replacement part based on more robust/recent hardware? But then, for how long?

Basically, the problem comes from the mismatch between hardware and software. Let’s make a parallel between computers and connected cars: In 2037, using Autopilot on a 2017 Tesla will be like running a 1997 version of Apache on a 200MHz Pentium Pro/Windows 95 machine in 2017: a very risky business.

The difference between consumer and business IoT is the ownership model (or more generally, the business model). Some people may always lease new cars and basically act like businesses, but some people keep their cars for 10 or 20 years, and some people buy used cars.

IoT security is a process is a service

Connecting cars is a great idea, but it doesn’t work well with the current car business model. There are many reasons that would push us not to own cars in the near future, and security is one of them: We shouldn’t own connected cars, and simply use a transportation service. Then, things become much clearer: It is the service provider’s duty to maintain the cars, software, and hardware, and to replace the cars when they are not secure/safe anymore.

More generally, IoT is a service, and IoT security is a process. The IoT « devices » are just a part of the hardware required to implement a given IoT service, even the big ones; they are just like the servers on the backend side, under the responsibility of the service provider, and their sourcing and maintenance should be under their responsibility.

Alain Colmerauer passed away this week. I have plenty of memories about him, starting from classes with him in Marseille, where his way to present constraint programming was as strange as it was passionate. Even before that, during my studies at Marseille’s Groupe d’Intelligence Artificielle, heavy on logic and Prolog, Alain Colmerauer was the name that made us all dream about research and fame.

Constraint programming at Prologia was intended to solve practical problems, in scheduling, optimization, and other NP-complete problems. That was fun for me, but Alain didn’t care: for him, what counted most was the beauty of the language, the ability to describe the language with the simplest theory possible. Prolog III, the first constraint language he developed, used linear programming on rational numbers, which could not solve all problems, but was mathematically exact.

In Prolog IV, we wanted to solve more general problems, and we started using intervals on less exact floating-point numbers. Alain was not enthusiastic at first, but things got better when we realized that floating-point numbers are actually rational numbers (i.e., exact numbers, not some approximation).

While I was writing my dissertation, I spent some evenings with Alain discussing potential formalizations of our constraints, and we ended up defining a notion of approximation to map a set to a smaller set of approximated values, and building something on it. I was quite proud of it, and I still am, but Alain was disappointed by the fact that the properties defining an approximation was too complex.

For me, that’s the legacy of Alain Colmerauer: even in the most complex thing, program, or language, a simple and elegant view of it is carefully hidden, and can be uncovered if you look for it carefully enough.

RIP, Alain.

These methodologies present many advantages, and one of the most obvious ones is their ability to have a quantitative side, where a value can be assigned to a risk or threat, or to a countermeasure, allowing management decisions to be taken.

Top-down is an owner’s view, not an attacker’s view

However, the top-down approach has some limits, especially when doing a threat analysis, and when getting closer to implementation. The top-down approach has two big problems, which limit how it models reality.

First, a top-down approach doesn’t faithfully represent the way in which attackers work, which is often much more opportunistic. An attacker often has an abstract goal, for instance to break into a system or harm some company’s reputation. This is because the attacker is in fact an attacker ecosystem, with many actors involved. Some people actually perform attacks on actual targets, but other actors identify vulnerabilities attack paths by investing in security research. The market for 0-day attacks on major software components is an example of this market. In that case, the researcher does not have any idea of the way in which the attack will be exploited, and doesn’t care.

Second, and maybe more importantly, a top-down analysis privileges intent over reality, and it can’t represent the blatant bugs that essential to many vulnerabilities. When a developer assesses the difficulty or cost of an attack, his view is necessarily optimistic. The attacker will not consider that he will make a stupid mistake, or that his algorithm is flawed. In real life, though, many vulnerabilities are linked to such situations.

Attackers are opportunistic

Let’s consider an example. We use an attack graph, because it better matches the reality of an attacker ecosystem, building complete attack paths from smaller attacks and vulnerabilities. Graphs can show how attacks are interconnected. If individual attack edges are weighted with the cost of the attack, then the attacker’s job is to identify the path with the smallest cost, or at least one of the smallest costs. This is shown on the left, with two paths that are better than others (total costs of 8 and 9, respectively), but the differences are not that great, with the costliest path at 11.

Now, look on the right. The graph has been corrected by simply taking into consideration one single stupid bug that makes one attack much easier than expected. And suddenly, a new path appears, that was not initially considered, because it was supposed unlikely, with a much lower total cost of 5. This minor change can lead developers to reconsider some of their hypotheses about threats.

And we have been nice, here. In real life, new attack edges and nodes are likely to be added to the attack graph, defining shortcuts to existing attacks, and often leading to completely unexpected attack paths.

Build attacks from low-level vulnerabilities

That’s where a bottom-up analysis can greatly help. The idea is to look at individual components and security measures, identify how they could be abused, what vulnerabilities are likely, in the most practical way possible. Such an analysis can be a bit messy, with many directions, so they will not yield a nice set of slides to show to a manager or customer. However, they are likely to identify a few interesting threats and attacks that cannot be identified through a top-down approach.

Later in the development cycle, similar results can be achieved through a security evaluation, especially in black-box testing. As the evaluators look at their target, they will have an opportunistic approach by first trying to find a few easy vulnerabilities.

[EDITED] Eric Diehl published a very good article about white-box testing vs. black-box testing, that I have to agree with. It changes a bit my last reference about black-box testing: white-box testing is generally more efficient than black-box testing, and if you are in a position to use it, a bounty program also is more efficient than black-box testing. Yet, I still believe that a foray into black-box testing can be useful to get a different insight into a product’s security.

If you are not familiar with threat analysis or modeling, try Adam Shostack’s Threat Modeling: Designing for Security. It really helped me when I started working on threats, and it provides good tools for a bottom-up analysis.