On the road to Bandol » Security

Twitter going feudal on security

Eric Vétillard — Fri, 04 Oct 2013 14:46:07 +0000

I have recently experienced security issues with Twitter, as my account was in some way hacked. And I am not happy of the way Twitter handles this situation.

First, here are the facts that I know:

Two weeks ago, a got an e-mail from a colleague warning me that he just received a spam Direct Message from me and that my account may have been hacked
I immediately looked at Twitter, just to find that another one of my followers had received spam
I then changed my password, and started to review the authrozations I gave
My authorizations were not looking good. Over the years, I had authorized many companies, usually those building Twitter clients. Some of them sported exotic names, and had the “read, write, and direct message” privileges.
I removed privileges to all these guys, and many more, and only kept the ones that I use daily and are issued by supposedly “good” companies, like Twitter and HTC, and service that I had used recently, such as Pullquote.
At this stage, I was hoping that this minimal work was sufficient to solve this hack thing (Disclosure: I am currently recovering from eye surgery, and at that time, my vision was very bad).

Well, I am not sure that these measures were sufficient to stop hackers, but none of my friends/followers have complained about receiving direct messages after that day. And knowing the proportion of security people in this crowd, this makes me feel quite good.

But then, Twitter kicked in:

Two hours after I fixed things, I received a “Your password has been reset” e-mail from Twitter, explaining me that my account may have been hacked, and that I should change my password. That sounded about right, so I changed my password (again), as instructed.
The next day, I received the same e-mail again: “Twitter has reset your password”. That got me a bit worried, so I took a few additional steps. First, I considered the possibility of spam: instead of clicking on the password reset link directly, I copy-pasted it into the browser and hand-typed the https://twitter.com/ part, just in case. I also made a more drastic review of my authorizations, only keeping the clients on my phone and iPad.

Everything went fine for 5 days. And just as I was thinking that the issue was over, I got another “Your password has been reset” e-mail from Twitter. This time, it was just not fun, and I had recovered a bit, so I investigated a bit more.

Since I knew that some contacts had received direct messages from me, I checked my direct messages, and no spam appeared there. This is strange, since my non-spam DMs sent from authorized clients do appear there.
I checked all the links provided in the e-mails, and I have not been able to find any useful information, or any way to ask for details.
I Google’d the problem, found other people with the same problem (or worse), but no clue of a solution.

So, in the end, I know that (1) my account has been hacked about two weeks ago, (2) Twitter noticed it somehow and reset my password, (3) Twitter then found two more reasons to reset my password in a week, and (4) the only thing that I can do is hope that this is over, because I don’t have a way to get any additional information about the problem.

So, I do believe that this is an instance of what Bruce Schneier calls feudal security. The Lords of Twitter provide me some security in exchange of me using their service and reading a few ads, and as a good serf, I am not allowed to ask any question or participate to the defense.

This is a bit scary to me. I like the Twitter service, and I am a rather happy user, exchanging information on this social network. But what am I to do if the Twitter police keeps resetting my password? How do I know whether this is a mistake, or I am really getting hacked? In such a situation, I guess that the only way would be to either stop using Twitter, or get a new handle. None of these solutions look good to me.

So, I can only hope that the Lords of Twitter protect me well, that the Prince of Facebook does the same. But mixing this kind of desperate hope with my professional hope that the Internet of Things becomes a reality is not reassuring. Feudal security is not a good future.

RFID in schools, or Security vs. Transparency

Eric Vétillard — Thu, 29 Nov 2012 12:16:04 +0000

I recently became enthusiastic about how wonderful transparent security would be. I still feel that way, but we also need to define limits on transparency. The example of a girl being expelled from her school because she refuses to wear a RFID badge (through @stoweboyd) is interesting.

The issue is rather simple. A school has issued RFID badges to track attendance, a student refuses to wear the badge, she gets expelled, a judge issues a stay, an we are now waiting for the trial. I also wear a RFID badge at work every day, and that doesn’t bother me much (well, it bothers me a bit: I usually wear it “visibly”, but not too much, as I don’t like the idea of the dangling name tag around my neck). This badge helps me getting into offices; it could also help me get connected to internet, and many other things. However, there is a big difference: my badge is a proximity badge. When I want to enter a room, I wave it to a reader; when I want to access internet, I insert it in a card reader. I can be tracked, but there are clear limits on what can be tracked. In that particular schoool’s case, things are different: the badges are designed to be read from a distance, without any badgeholder interference.

This is transparency, of course, and it could make your life easier. Think about a restricted area’s door opening just because you are arriving: sounds nice, doesn’t it? That makes it more convenient than a standard badge. However, this convenience implies that you trust the badge’s issuer, at least enough to believe that they won’t read your badge to monitor your every movement, like how much time do you spend in your office (working), or elsewhere (potentially not working). Here, the issue is the lack of user engagement from the user. With such a system, the user ends up believing/fearing that she is the victim of pemanent surveillance, and this may just be true.

This problem is not specific to this case. Gemalto has a technology called eGo that faces similar issues. This technology communicates through the body to establish a secure link between a reader and a personal device. To take the access control example, a door could open when you touch it. It is better than simply using RFID, but not much. With this technology, you can be tracked whenever you touch something, and some people will (understandably) not like it. Of course, it is easy to design limits. For instance, one could imagine a specific, clearly marked pad that you have to touch in order to start the authentication: then, there is a specific gesture, which can be interpreted as an acknowledgement. For RFID, this is more difficult to do, especially in crowded areas like schools, where several badges are likely to be readable at any time.

This post is actually turning into advertisement for Natural Security. This startup proposes a contactless device that communicates with a fingerprint reader that can be integrated in a variety of envionments. When you swipe your finger, you are authenticated, and then a transaction can occur. You don’t need to take the card out of your pocket or purse, but you are doing a specific simple gesture to acknowledge your intention to do something. On top of that, you are authenticated, which is a nice bonus. Security, naturally and esaily; I guess that this is where the company name comes from.

Once again, no system is foolproof, and heavy surveillance could be achieved with most products, just like fraud remains possible in most cases. However, good security systems should allow/encourage the institutions and corporations who use them to respect their users’ privacy, just as much as they should encourage/force the end users to comply to the security rules. As I mentioned in the previous post, end users aren’t security providers’ customers, but they have rights, which are often hard to understan, and it is also our responsibility to help our customers respect these rights.

One final note about RFID at school. If this system is installed, it is likely that it will soon replace human checks, and sudents will be able to escape class or other oblgations by swapping badges or putting their badge in somebody else’s pocket. Why? Because a human being looking at badges performs an authentication by matching the ace on the badge and the face of the person wearing it, where a RFID system simply counts badges, and doesn’t care about human beings. What a package: you get less privacy and less security.

Chip to Cloud, day 1: Cloud security panel

Eric Vétillard — Wed, 19 Sep 2012 11:06:08 +0000

A few bits from Helmut Scherzer, from G&D:

The digital natives don’t want to escape the Web. We went from visual Web to the social Web, and they will go to the next step with the semantic web, where knowledge is well classified and organized.
big companies are very big. The CEO of Toshiba estimatee that it would take them 10 years to build the same computing power than Goole. Quite an advantage. Plus, of course, Google has a lot of your data, and their CEO told that people are waiting for Google to tell them what to do next.
Privacy is not absolute. google Street View made a privacy scandal in Germany, but as Audi introduced Street View in cars, people became interested in seeing their home on it. You can buy people beyond privacy.
There is http://pleaserobme.com/ service that is really a nice tool to show how people tell everybody that they are far away from home (no, I am not far away, and there is someone at home)
Babyboomers wanted to improve the world and own cars, Generation X want to fin themselves and have been used to computers, and digital natives have grown in computers, and this is true in all aspects of their life.
The network has become a moral instance, and pressure from social network is increasing. Network is also not forgiving, as everything gets recorded, and this does not look like a good evolution (especially if you don’t conform with the net morals).

He finished with a wish list for the future, from which my favorite item was “security without doing anything for it”.

Next speaker is Peter Hustinx, European Data Protection Supervisor, about making data protection more effective and consistent across EU. Of course, he talks about upcoming new regulations that would address some issues outlined just before.

The first one is to put the user in control, with the right to access, remove data, being forgotten, and much more.
Next thing is to make providers responsible, with mandatory assessments./li>
Effective supervision is required, with more powerful national organizations, and more cooperation between countries
Finally, Europe is only one part of setting up a Global Privacy framework, by setting up instruments for adequate protection, and of course, more cooperation, for instance, between the EC and the FTC.

Next speaker is Joerg Borchert, from Infineon and Trusted Computing Group, rapidly presenting the TCG, including the following statement:

The cloud means the mix of trust and multi-tenancy, with a root in hardware at the server level.

Final speaker is Detlef Houdeau, from Eurosmart and Infineon, talking about a whitepaper recently deployed on cloud security.

Cloud security is a combination of computing security, network security, and information security. Very different points of views.
There are many actors around cloud security, both at the European level and at the industry level, but these efforts don’t focus on the cloud issues. Thisleads to risks, such as the lackof EU guidelines.
Eurosmart recommends to work on privacy, security, and data protection

Well, this conference leaves me frustrated, as I didn’t get the same impression of consistency as in the first panel. The speakers sounded a bit like everybody is proposing solutions without listening much to the others. Also, I am not convinced that we have done the work of linking the societal aspects of the cloud, as expressed in the first talk, with clear societal objectives. Instead, we are jumping directly to technical proposals. The legal framework may make the link, by defining incentives to develop the “right” technological answers. Still, privacy by design is a nice idea, that we have to make flexible enough to match the lifestyles of our digital natives. We of course want to avoid falling into Big Brother’s arms, but we also have to make sure that we create an environment in which we can be free to share things freely. And that is a challenge.

Protecting your contactless card

Eric Vétillard — Mon, 20 Feb 2012 08:35:11 +0000

As I mentioned in NFC Payments 101, current contactless cards aren’t protected against the simple attack that consists in performing a transaction while your card is in your pocket. Since some models don’t require anything else than tapping the card, the attack is workable.

Well, that may change. researchers for the University of Pittsburgh’s RFID Center for Excellence have invented a on/off switch for cards, that simply requires you to put your finger on a specific spot on a contactless card to allow it to work (see a picture here).

Comment on the various articles around the topic are quite typical, ranging from the “This is very dumb because it is unpractical” to the “You have to give up some practicality for security”, and all variants in the middle. I would have liked to see the inventors’ arguments, but I haven’t found a reference to a paper/report.

From previous experience, user experience often wins, in particular when, like with contactless cards, practicality is a selling point of a technology.Also, since the idea is to protect your cards in your wallet, I would think that it is easier for security-conscious to use wallets that include some kind of wire mesh or other wave-blocking technology. Since the on/off switch requires you to actually get the card out of your wallet, it is more or less equivalent, and it only annoys security-conscious people. The other guys will still be able totap their wallet (until, of course, they start having several contactless cards in there, in which case this optimization may not work any more).

This invention does not look flexible enough. The threat of someone performing transactions without you knowing is not significant enough to justify this kind of generalized measure for payment cards. On the other hand, it sounds much better as privacy-protecting technology on ID cards, since an ID card. Ensuring that the data about your identity will not leak from your wallet is interesting, and since an ID card is typically pulled out of the wallet before to be used, the technology is not an annoyance any more. But of course, in research like in politics, the fears associated to credit card theft remain more powerful than those associated to privacy protection (although identity theft is gaining traction).

The misuse of bytecode verification

Eric Vétillard — Wed, 19 Oct 2011 08:42:21 +0000

Bytecode verification has been an interesting debate since the very beginning of Java Card. Back then, in 1997, Java was very much about Java applets, and the bytecode verifier was the essential piece of software that allowed untrusted code to run in a browser efficiently (i.e., without doing expensive runtime checks, and without having to setup a complex process of applet vetting). We inherited this view of bytecode verification in Java Card, and the verifier was integrated in the Java Card virtual machine.

Since then, there have been many debates about bytecode verification, and my own position has evolved over the years. Today, my opinion is a bit contrasted, some may even say contradictory. Nevertheless, here it is:

Bytecode verification has limited use for Java Card runtime security.
Extended bytecode verification is a very good tool for application vetting.

Let me give a few more details about these two opinions.

Bytecode verification and runtime security

The idea of runtime verification is that it is performed after getting the code, and right before to run it. The code that runs is therefore known correct, at least regarding bytecode execution (unrelated attacks remain possible, of course).

The first big issue with bytecode verification is that, in Java Card, with the split virtual machine model, verification is not performed on the card, but outside of the card, before/during/after converting the application into Java Card’s specific binary format (CAP file). Then, the application is sent to the card over some channel that may be attacked. Here, we rely on GlobalPlatform’s cryptography-based security to protect the integrity of the code. So, basically, we still need to establish trust, and we must say goodbye to the power of running untrusted code from arbitrary developers.

This is not a big issue in practice, because there is no business model that allows arbitrary code to be loaded on cards. However, this causes an organizational problem, as the verification process needs to be well organized. Researchers from Nijmegen and Limoges have shown that it is possible to fool the verification process with fake export files, and then load on a card verified code that will perform type confusion attacks.

Going beyond that, some people have designed applications that can be verified, but have been designed to be attacked through hardware attacks (fault induction, usually). Such attacks, usually known as hybrid attacks, completely fool the bytecode verification process.

Most security experts will then remind you at this point of the discussion that bytecode verification is only one part of the process, that GlobalPlatform is also important, that the origin of code is usually known, that this makes it very difficult to include attack code in an application, etc. By doing this, they are just about accepting the fact that bytecode verification is useless or at best marginally useful: the real security of cards is in the trust between issuers and application providers, and some cryptographic process. Basically, this works because the ecosystems are small enough to be controlled (which is true for cards, and fine for me).

Finally, some vendors claim to have developed defensive virtual machines, which do not require a bytecode verifier, and perform enough runtime verifications to accept any bytecode, good or bad, without any risk. In that case, bytecode verification is really useless, and I believe that it makes things much simpler. Of course, such virtual machines are difficult to design and implement efficiently, but this is definitely possible, and I think that it has been done in the past (or at least that some people has come very close to it).

To conclude, I will get back many years ago. In 2000, Trusted Logic was very proud of its on-card bytecode verifier; the technology worked, but it has not been widely adopted. I believe that the first factor was performance, as verification made the loading and linking process much slower. I also believe that a second factor, less obvious, is that on-card bytecode verification makes the card’s security more brittle, by encouraging VM developers to rely too much on static verification rather than runtime checks (which also prevent other runtime attacks, for instance using fault induction). More than ten years later, most people admit that this was not the way to go, and I just go one step further by stating that bytecode verification is not that useful for runtime security.

Bytecode verification and application vetting

Bytecode verification simply consists of a very simple static analysis of the application code. Basically, this is is a program proof, but a very simple one, whose complexity can be controlled. The objective of such simple proofs is not to demonstrate that a program is correct with respect to its specification, but that this program obeys a predefined set of properties.

For Java bytecode verification, these properties are related to the proper ues of the bytecode instructions. However, the same algorithms can be extended in order to prove many more properties, covering many aspects of application security. Among the things that can be proven, we have the following:

Method M is not called.
Method M is not called with arguments A1, …, An.
Method M is always called before/after method N.
Method M never throws a NullPointerException (or any other exception).
Command INS can only return status codes SW1, …, SWn
Toolkit buffers are only used when they are available.
and many more.

Of course, there is no magic. When extending static analysis to many properties, it becomes more and more difficult to avoid false positives, i.e. errors that are caused by weaknesses in the algorithms. Put simply, an application is rejected although it is in fact correct.

Apart from working on the algorithms to make them better, there are two ways to deal with this issue:

Providing the verification tool to developers, together with explanations about the rules to follow. Usually, it is rather simple for developers to ensure that their application can be verified, provided that they can use the tool throughout the development process.
Use the tool in a vetting process as a guide for evaluators, who then perform additional verifications. In that case, broken rules are considered as warnings, and then verified by the evaluators. Simple applications can usually be verified easily, and more complex verification requires a few checks, simplified by the fact that the most boring tasks are performed automatically.

I believe in both approaches, but the second one has been proven efficient by my then colleagues of Trusted Labs. By using such a static analysis tool, they are able to optimize the vetting process of Java Card applications (and MIDlets, but this is another story) significantly, by allowing them to focus on the the most important parts of the applications.

In addition, this approach allows us to include many more security rules. For instance, hybrid applications must include code that can be modified into attack code through a simple attack. It is possible to build a library of patterns of such code sequences, and to check for them statically. Then, evaluators can be warned of the possible presence of an hybrid attack and check for it. This can be promising, because such checks (very boring to do, but very unlikely to lead to anything) are usually poorly performed by humans.

Finally, extended bytecode verification, or static analysis, has been proven to be a very efficient optimization tool. All optimizing compilers include a static analysis phase to perform their most complex optimizations. Java Card can take great advantage of this, because of the isolation between applications, and also because of the closed world hypothesis that is sometimes possible, when cards are closed (no additional applications can be downloaded).

So, bytecode verification has many uses in Java Card, but runtime security just isn’t the most compelling.

PINs still under attack!

Eric Vétillard — Sat, 27 Aug 2011 20:38:15 +0000

This summer was very interesting for new attacks. There are two that I really liked, for very different reasons. They are also both attacks on PIN codes, yet they are quite different.

The first one is an attack on ATMs, with a thermal camera, hoping that your fingers stay on the keys long enough to heat them up. Well, it seems that if all conditions are good, the trick can work. The great thing about this attack is that it naturally captures the order (the warmest key is the last one). The attack even works well in optimal conditions (recovering half of the PIN codes after one minute), which sounds good, even a bit alarming.

Luckily, it is quite sensitive to various conditions, like the material in which the keys are made (plastic seems better for the attack than metal, which conducts heat away too easily). Having cold fingers also is a good security measure, since the amount of heat transferred is lower. The researchers haven’t tried it, but the temperature of the environment should also have some influence. So, against this attack, I guess that selecting an ATM in full sun, with metal keys (the authors’ recommendation) and wearing gloves should make it.

The second attack is about using a smartphone’s motion sensor to guess a PIN code typed on it. Of course, when you type on a smartphone while holding it, you apply some pressure on the screen, and the result in terms of movement depends on where you type. It doesn’t work as well as the previous attacks, but apparently, they get over 70% of the digits typed on a 10-digit keyboard.

The obvious countermeasure is to make sure that your phone is safely lying on a table, which will severely limit any movement. In terms of countermeasure, this also raises the bar for people who are developing systems that protect the touchscreen: well, you may as well protect the motion sensors, because if a hacker controls that, he may just get the PIN code that we want to protect. Of course, that ‘s until another attack comes, using another sensor.

For me, these two attacks have in common to be absolutely obvious. You just read the title of the paper and you think “Of course, this is nice”. And yet, they are quite practical, and they can become a real problem for real people. They also both rely on using a disruptive attack technology: PIN protection requirements usually don’t consider thermal cameras and motion sensors as potential threats, but they may in he future. This is another reminder that security is a wonderful job, because as soon as you have covered all known threats, new ones come up that you also need to cover.

The government wants us to protect our assets

Eric Vétillard — Wed, 06 Apr 2011 16:01:18 +0000

The French government has recently published a law, and some details of the application degree have led to strong reactions from the industry, including a suit by the French association of social online services. The suit is about a recent law that forces sites to retain a lot of information about their users, and to give it to law enforcement on request, and in some cases without any involvement from a judge.

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

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

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

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

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

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

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

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

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

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

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

About e-Smart: Java Card attacks

Eric Vétillard — Tue, 28 Sep 2010 20:09:36 +0000

I was not at e-Smart this year, but here are some early reports from colleagues who attended the sessions. Over the coming days, I will comment on a few selected presentations. First, one of my favorite topics, which was covered Friday morning: attacks on the Java Card platform. There were two presentations this morning on this topic, both of them challenging the often accepted simplistic view on bytecode verification.

The first presentation was given by Guillaume Barbu, from Oberthur, about combined attacks on Java Card 3 Connected. Combined attacks are interesting in principle, because they suppose that the attackers are intelligent enough to avoid bytecode verification, while still having the possibility to perform attacks.

A very short reminder on what this is about: in a combined attack, a legal Java Card application is designed to include code that is vulnerable by design to well-known hardware attacks. When the hardware attacks are applied, the legal application becomes a malicious application and performs an attack on the hosting card.

Nothing new here. Guillaume made a first presentation about this last year, and we made presentation about the same topic at Cardis in April. The novelty comes from the exploitation that Guillaume makes of combined attacks. Since he is targeting Java Card 3 Connected, his target is the pool of interned strings. Since strings are everywhere in JC3 Connected, and since they are often used to make security decisions, this attack could be very powerful. For instance, the parameters of permissions are strings, and playing with these strings could greatly extend the permissions granted to an application. These attacks are interesting, but, from the feedback I got, the countermeasures proposed by Guillaume are a bit weak. Well, this reminds us that Java Card 3 Connected remains an implementation challenge.

The other presentation was given by Emilie Faugeron, from Thales ITSEF. Thales has found a bug in a bytecode verifier, and discusses the consequences of such a bug. This story has been unfolding for a while, as the bug has been known from the card security community for a while. I am glad that it finally becomes public, which allows us to comment on it.

When there is a bug in the verifier, it means that a potential attacker could load a malicious applet on a card without being detected by the verifier. The consequences are basically the same as for combined attacks, with the advantage that there is no hardware attack to perform after the loading.

The question is here to know what we should do about it. Thales proposes to evaluate the bytecode verifiers (on-card and off-card) during a Common Criteria process. This sounds obvious at first, but there are significant differences between a bytecode verifier and a Java Card Virtual Machine:

First, a bytecode verifier is a highly standardized piece of software. On other platforms, VM vendors are not allowed to modify the verifier’s reference implementation. The specification of a verifier is always the same, and it changes very rarely.
In Java Card, there is an exception with on-card verifiers. Because of the high level of optimization required, a few differences may be expected. For instance, Trusted Logic’s verifier requires an initial normalization phase before to load the application; however, the combination of normalizer and verifier implements exactly the same specification as other verifiers.
There are very few implementations of verifiers that are publicly used. The verifiers are always the same, and I would assume that Oracle’s verifier is the most commonly used. In that context, building a viable certification environment is hard.
There already exists significant test suites for Java Card bytecode verifiers. Trusted Logic has one, of course, to test its own verifier. Oracle has a very significant one, which it uses to test its verifiers. And obviously, Thales has one now. And I assume that other actors have some.
Testing a bytecode verifier is a hard task. A bytecode verifier is a static code analysis tool, and these tools are well-known to be very difficult to test, because of the level of abstraction required.

So, what can we do? One option is to follow Thales’ advice. This sounds tempting for me; I have strong ties with Trusted Labs, which could perform such evaluations, we have access to a test suite, and we have been developing and testing static analysis tools for about ten years. If I am wrong about the potential business, this is likely to happen.

The alternative way is to remind ourselves that a bytecode verifier should follow a reference design, preferably provided b yOracle. This is what happens on all other platforms, and there is no reason to keep a Java Card exception. For such pieces of sofftware, which evolve very slowly, nothing beats public scrutiny. There are many researchers (for instance, wy friends from Limoges and Nijmegen) who would love to take a look at a bytecode verifiers and its tests.

I don’t have a plan for this, but it really looks like, in this matter, collaboration between all actors sounds much better than competition between evaluation laboratories. We’ll see what happens.

Live from Oracle OpenWorld: Cloud and Identity

Eric Vétillard — Wed, 22 Sep 2010 20:42:49 +0000

At midday, it is time for a little break in my smart card day, and go listen to an Oracle OpenWorld session. I might as well leverage today’s professional look to blend better into OOW’s suit-dominated crowds. The funny thing is that every OOW session I have seen ended up turning into a blatent advertising session for some Oracle product. No exception on that session, which was about Identity in the cloud. Here are a few highlights of that session (before the advertising part), provided about raw:

74% of people are worried about security in the cloud, in particular because of the loss of control that comes from moving your applications into Software-as-a-Service, or even only when you are only getting to Infrastructure-as-a-Service. But, the worries come from the classic security approach with perimeter defense: your security is based on high walls keeping people out.

Cloud computing introduces a disruption, but it only means that perimeter defnse has become obsolete, and that other things are required. Security now needs to be secured by policies, not only based on the topology of the network.

For an SME, the perceived risks (from ENISA) include vendor/service lock-in (am I stuck forever with Amazon?), malicious insiders (who is accessing my data?), management interface compromise (could someone impersonate my IT manager?), or legal risks (where is my data stored?). Another point is that shared services can be more attractive to hackers, because they can be granted access to several actors.

Of course, according to the speaker, identity is the solution. His main idea is to extend the (Oracle) identity management system used in the enterprise into the cloud. For instance, for federation, SAML-based federations can be used to get into the cloud.

Privileged account management is very important. Cloud services come with “superuser” accounts that have the ability to completely manage a service. These accounts should only be accessible through a mechanism that can track, monitor and control access.

For other accounts, account lifecycle management can be an extension of the standard enterprise system.

Something very interesting is to use claims-based identity. Claims-based provisioning can get the necessary identity information through a single SAML token, without having to directly connect to the enterprise systems. More importantly, identity assertions (such as attributes and roles) can be used for authorization purposes. However, this is not necessarily accepted by all cloud providers. When supported, XACML allows enterprises to export their internal policies to the cloud service provider.

Ultimately, the enterprise can become an Identity Services Provider, leveraging the IAM services available internally to cloud applications, or to partner applications outside of the enterprise. The objective is here to promote a loose coupling between the services and the low-level authentication.

Then, we get into Oracle advertising, reminding that identity management is part of Oracle’s offer, and provides all the services mentioned previously.

Live from JavaOne: Identity for Services in the Cloud

Eric Vétillard — Wed, 22 Sep 2010 04:16:33 +0000

The next talk was about Identity for Services in the Cloud, by Jiandong Guo and Symon Chang. Their focus was to promote their favorite solution, which has been around for a while, and whose objective is to clearly separate authentication from authorization using standards. Their scheme is quite classical:

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

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

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

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

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

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