Some people don’t like phone security

It seems that FBI isn’t able to perform smudge attacks very well. Apparently, they have been defeated by Android’s “pattern lock” on a Samsung phone. Well, my friends must be smarter than the FBI, because both of the guys who tried to defeat my pattern lock using a smudge attack succeeded.

The fun part is of course that the FBI is now going after Google to find a solution to this problem, asking them plenty of information about the device and about the use that the bad guy did of it. Most of the things that they are requesting may indeed be in Google’s hands, if the bad guy is not very smart: e-mails, text messages, Web history, contacts, etc. Unless of course, the bad guy has been using non-default apps.

But it gets even more interesting when we get to the part asking for “Verbal and/or written instructions for overriding the ‘pattern lock’ installed on the” phone. Since this is a Samsung phone, does Google have this information? What if there is no way to override this? I am not sure that the people who design security protocols for Trusted Execution Environments and/or for Secure Elements actually include a backdoor everywhere. After all, in some cases, not having a backdoor makes security easier to enforce. Of course, in this particular case, the pattern lock can be overridden by the owner’s Google account, so I guess that Google has the information.

But, in a more general term, it brings us back to the question of the “right” security level. If there is an open market for TEE/SE applications, the “superlock” application definitely sounds like a good one. It will certainly benefit our privacy, and it will just as certainly annoy anybody who wants to violate someone’s privacy, with the same debates as usual regarding the limits of the law. I am not completely sure where I stand on this, since I don’t like the idea of letting police look at my information, but I don’t really like the idea that my wonderful security products are used by bad guys to protect their content from police Of course, we can trust most bad guys to be like regular guys and make blatant security mistakes, but sometimes, it just won’t work. Oh well, we’ll see, and it should be interesting.


Protecting your contactless card

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


NFC Payments 101

I have been writing a few posts about NFC payments, and I am lacking a basic background post showing where I come from, so here it is: my own little NFC Payments 101. It may not be fully objective, not even fully correct (I haven’t directly worked on this topic for a while). You are


Google Wallet has a Vulnerability (not on SE)

The game has started for Google Wallet. Some guys are looking for vulnerabilities, and of course, finding some. You can read the papers to get all the details on this attack. Basically, they have been smart enough to use a salt before hashing the PIN value to avoid brute-force attacks. However, they haven’t been smart


E-smart becomes Chip-to-Cloud

After over 10 years, e-Smart is changing its name to become the Chip-to-Cloud Security Forum (which will also replace the other conferences from the Smart Event). This looks like a welcome move from card-centered business to application-centered business, reflecting what is happening in the industry. The technology is now ready, and it has not evolved


No memory, no chocolate!

There has been some excitement lately about the fact that more and more phones are now getting embedded SE’s (eSE’s), associated to a NFC interface. Some of this excitement came from the ability to manage third-party applications on this embedded SE, as enabled by a whole range of GlobalPlatform specifications, and by the emergence of


Best wishes and post-holiday rant

First, since this is my first post of the year, let me wish you all the best for 2012, hoping that it will bring a lot of interesting things around mobile security, Java Card, and all these things. My first post will be a rant about something that is very-much holiday-related for me: package deliveries.


Google’s vision of Secure Elements

Google has launched its Google Wallet service, which uses a secure element in the phone to provide some security. Of course, Java card is in every one of these secure elements, but it is not the point today. I have just stumbled upon the Google Wallet page. Initially, I was looking for information about how


My first week at Oracle

The break is over! After a month spent on various family activities, I am back to work. My new job is related to the Product Management of Java Card at Oracle. This is at the same time very close to what I did previously (Java Card has been close to the center of my activities


Java Card is 15 years old

I just realized that I missed Java Card’s 15th birthday. This birthday was sometime in the end of October, 1996. I don’t have the exact date, because the only document I have is the Java Card API: Specification of the Java Virtual Machine and Application Programmer’s Interface, version 0.13, dated October 10, 1996. Although this