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.

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).

First, let’s state what this is not about:

• Mobile payment. NFC is one form of mobile payment, but not the only one. In particular, I will not address the kinds of payments that are solely mobile-based, rely on SMS, Internet, or whatever. Here, I will only be talking about contactless payment, using a secure element.
• Contactless cards. Contactless cards are fun, but here, I am using NFC in its restrictive meaning, which involves a mobile device.

Next, let’s move into a few definitions (in alphabetical order):

• Bank. The financial service provider who issues a payment application. Could be a bank like Citi or a credit card specialist like American Express.
• Device vendor. Whoever provides the device through which the payment will be performed.
• Embedded Secure Element (eSE). A Secure Element that is soldered into the mobile device during production. See Secure Element.
• Merchant. Since we are considering in-person, whoever accepts to be paid through a NFC payment, and has access to the proper infrastructure to do so.
• MicroSD. A specific kind of MicroSD, which includes a Secure Element and a NFC antenna. It may be used as a NFC adapter on mobile devices that don’t natively support NFC. See Secure Element.
• Mobile device. A mobile device that includes a NFC interface, a Secure Element, as well as a Mobile Wallet, on which an end-user can perform mobile payments.
• Mobile Network Operator (MNO). A company providing network access to the mobile device. If GSM is used, the mobile device contains a SIM, which is owned by the MNO.
• Mobile Wallet. A mobile application, running on the mobile device, that allows the end user to select the card to use for a particular transaction, to register a new card, or perform similar management operations.
• Payment Application. An application running on the Secure Element that can perform a payment, usually following the EMV specification.
• Payment Terminal. A device that is used by the merchant to process NFC payments (and possibly other kinds of payments).
• Secure Element (SE). Some secure MCU, including a Java Card platform, supporting the required GlobalPlatform specifications, with the proper security certifications (Common Criteria, EMVCo, for instance). The Secure Element is used to run the Payment Applications, and possibly other applications.
• SIM. A Secure Element that includes the credentials for authenticating a device into the GSM network, provided by the MNO. See Secure Element.
• Trusted Services Manager (TSM). An entity in charge of managing the assets on a Secure Element on behalf of the owner of these assets (which may be the owner of the Secure Element itself, or simply the owner of an application on the Secure Element).

Stakes and stakeholders

In NFC payments, the stakes are rather high, since the idea is to move currency from one account to another. A single device (and in particular its Secure Element) will hold data pertaining to several payment cards in a single location. Some of this data (considered less sensitive) will be stored on the mobile device (card name, associated picture, partial number, etc. The more sensitive data, and in particular the end user PIN and associated counters, and the cryptographic keys used to authenticate the card, are stored and processed solely on the SE.

Another stakeholder is the owner of the SE. This owner depends on the kind of SE. A SIM is usually the property of a MNO, and an eSE would be expected to be the property of the device vendor (possibly transferred to another actor, like Google), and a NFC MicroSD is the property of whoever provided it to the end-user (possibly a bank, possibly another actor). In all cases, this SE owner is the one who holds the keys to the SE, and has the power to allow banks and other application providers to put their content/credentials on their SE.

Something interesting with NFC payment is that this is a significant departure from traditional cards. When deploying contactless cards, a bank selects card suppliers, verifies their credentials, tests the cards thoroughly, and then deploys the cards. The bank controls the entire process, even if most of it is outsourced to various suppliers.

With NFC, things are very different. The “card” (SIM, eSE, MicroSD) is selected by somebody else. Even worse, there may be several cards for different devices or different MNOs. Banks need to trust all these people to have done the right thing, and all that trust is not easy for them. I am not sure what the model is for applications, but it may also be similar. Is the wallet owner going to put a single copy of the Visa application, associated to one data set for each Visa bank, or is the wallet owner going to install (almost) the same code several times, to better isolate the assets of different banks? If banks need to share the same code, that will require a lot of trust.

How do you get that trust? Through a security certification. And because there are many things to evaluate and many banks to convince, the evaluation requirements need to be quite high. This leads to potential cost issues for vendors, which can become especially high if every mobile device/SE needs to be certified for every NFC payment model. Factoring these costs is going to be important; standard certification frameworks, such as Common Criteria, are the current solution, but these frameworks may lack the flexibility required for such deployments. We’ll see.

Things get really funny if we keep adding stakeholders in the picture. Consider for instance that other people may want to add applications in the SE. For instance, your company may want to put a VPN there, or I could try to sell you a very good password storage app. These applications are not sensitive (from a banker’s point of view), but bankers want to ensure that they won’t interfere with their own applications (after all, I have designed logical attacks in the past). Java Card provides some solutions, with the firewall that isolates applications, and the bytecode verifier that checks that the application isn’t malware. But most likely, this is not sufficient, and an extra step will be required to convince everybody that the application is innocuous to other applications.

The infrastructure

Before getting into an actual NFC payment, the credentials need to get to your mobile device. In some cases, the payment application may also need to get there. So, how does that work?

We can assume here that the wallet owner has control over the SE. This means that this entity is able to load new applications, instantiate them, delete them, and more. It may also authorize other entities to perform similar operations. For instance, on a SIM, the MNO will always be allowed to manage its SIM applications and whatever other applications are required for its telco operations.

Similarly, banks will be allowed to manage their own applications, or at least their own credentials. In GlobalPlatform jargon, this means that banks will have a Security Domain that represents them on the card, with the appropriate privileges. Each Security Domain has its own set of cryptographic keys, which allows it to perform secure operations independently of the other actors.

In a typical NFC deployment, the operation of Security Domains is delegated to specialized technical operators, Trusted Service Managers. There usually will be at least two types of TSMs:

• The bank TSM(s). Each bank has a TSM, in charge of managing its assets on the SE.
• The wallet owner’s TSM. This TSM manages the wallet-related applications (if any), and it is also in charge of creating Security Domains for the banks’ TSMs.

All exchanges between TSMs and between the TSMs and the SEs are standardized by GlobalPlatform, in various documents. This allows the ecosystem to work. Now, let’s imagine that a new bank wants to install a card in a user’s mobile wallet. Here are the operations that need to be performed:

• Loading the payment application. Actually, this is optional, as several banks may use the same application, for instance a standard Visa or MasterCard application. When required, this is done by transmitting a CAP file (binary format for Java Card) to the SE.
• Instantiating the payment application. For a given bank, a new instance needs to be created, in order to store all the specific information. This is a simple operation, which does not involve any sensitive information.
• Personalizing the payment application instance. Once the instance is created, this step consists in populating it with the proper data, including highly sensitive data such as cryptographic keys. This operation is always performed by establishing a secure communication channel between the Secure Element and some kind of secure factory, in which the cryptographic keys are stored/generated. The fact that the SE is actually outside of the factory when it is personalized doesn’t change this.
• Sending the non-sensitive information to the wallet. Once the payment application instance is ready on the card, more information needs to be provided to the wallet in order to be able to use it. This typically includes a logo, a name, and a reference to the payment application instance’s identifier on the card (AID). This information is stored in the mobile wallet, on the device.

This looks rather simple, but the devil is in the details. Since the information that circulates during this installation is highly sensitive, the security level of the secure channel is very important. Also, several actors need to collaborate in order to make all this happen, which makes it possible, at least in theory, to design all kinds of attacks, including social attacks on employees of the various TSMs involved. As of today, the ecosystem remains a bit small to attempt such things, but this may change in the future.

What is a NFC transaction?

There is no such thing as a standard NFC transaction, as there are many ways to perform a NFC payment. First, let’s consider a few typical requirements:

• The user must present a PIN for payments over 15 euros.
• The user must present a PIN before performing a payment.
• It must be possible to perform a small payment with the phone off.
• The user must see the amount of the transaction on the phone after the transaction.
• The user must be notified when a transaction is successful.

If all of this looks obvious, then think again. All these requirements are contradictory or close to impossible to achieve in most payment schemes. I haven’t been involved in this topic for a while, so my scenarios may be incomplete. However, the objective is here to show a few issues related in particular to usability vs. security. So, let’s look at a few examples, and analyze where things can go wrong.

Small transaction, no PIN required

This sounds simple. Here is what somebody may expect:

1. Bob takes the phone out of his pocket
2. Bob turns the screen on
3. Bob taps the phone on the payment terminal
4. The phone beeps/vibrates and displays the amount to confirm the transaction

Steps 1 to 2 are correct. Turning the phone’s screen on also activates the NFC interface (which is deactivated to save energy), including card emulation mode. At this point, a payment is possible.

Step 3 may not work with all wallets. If I understand what Google is saying about their wallet, you would then need to launch the wallet application and enter your wallet PIN to do so.

Step 4 is more difficult, at least in the U.S. . Card transactions in the U.S. actually emulate a magstripe, optionally replacing the static authentication by a dynamic one. In this transaction, the payment terminal simply reads data from the card, and does not communicate the amount to the card. In fact, the card doesn’t even know if the transaction was successful. The interface remains the same with a NFC payment: the payment application doesn’t know the amount, and it doesn’t know what happened after it sent its information. So, even if everything went fine from the phone’s point of view, the transaction may still be rejected by the payment terminal. Some user friendliness to work on.

Large transaction, PIN required (pre-authorization)

Here is another simple one:

1. Lisa takes the phone out of her pocket
2. Lisa turns on the phone and selects the mobile wallet
3. Lisa selects the card to use
4. Lisa enters this card’s PIN
5. Lisa taps the phone on the payment terminal
6. Lisa gets feedback through the payment terminal

This sequence is correct, but other options are possible. Since a PIN needs to be entered before to perform a transaction, step 2 is mandatory, as Lisa needs to turn on the phone explicitly, and select the mobile wallet (a shortcut key may be used, though). Note that this selection may require the presentation of a mobile wallet PIN, just to unlock the wallet.

Step 3, on the other hand, is optional. It should be possible to define a default card, to make a typical transaction shorter.

Step 4 is here critical, as a PIN is entered. The nice thing, from a usability point of view, is that the user can enter the PIN wile waiting at the merchant’s counter, making the actual transaction a simple tap. The bad thing, from a security point of view, is how it differs from a typical PIN entry:

• In standard transactions, PINs are entered on a PIN Entry Device (PED). The payment industry has defined specific guidelines for the security of these devices, PCI-PED. These guidelines are not easy, and mobile phones just don’t make it. It is hard to protect the PIN on a phone, as it is entered, as it is (temporarily) stored, and even after it is entered, with our screen smudges. TEE vendors will claim to be better, but they can hardly claim to be at PCI-PED level.
• The PIN is here entered before the transaction. In a “good” implementation, it will be presented to the card immediately, and erased from the mobile’s memory. However, the user most likely wants to approve a single $5 transaction at Starbucks in the next 2 minutes, and not a $2,000 transaction the next day. However, the SE doesn’t make the difference, because the SE doesn’t know about real-time. It is therefore the mobile device’s responsibility to clear the PIN status 1 or 2 minutes after it has been presented. And even then, during these few minutes, Lisa’s device is a prime candidate for an attacker, since any payment request has been preapproved.

Large transaction, PIN required (double tap)

This is a similar model, in which the PIN entry is managed differently:

1. Paul takes the phone out of his pocket
2. Paul turns the screen on
3. Paul taps the phone on the payment terminal
4. The phone beeps and asks for a PIN, because the amount is above 15 euros
5. Paul enters his PIN
6. Paul taps the phone again
7. The phone displays a recap of the transaction

You may have guessed, at least from the subtle reference to euros, that this scenario is not very American. We are here using the version of the EMV protocol in which the card is involved in the risk management decisions, and therefore knows about the amount to be paid. The decision to ask for a PIN will most likely be taken by the terminal during step 3, but some information is still available when interacting with the user.

Also, note that, although I have here simplified step 2, there may still be a full wallet opening and card selection sequence before the actual payment; I have simply assumed here that there was a single or default card, which is common in Europe.

The interesting thing here is that there is no major difference in the PIN handling, and that both security remarks made above apply here. Because the second tap is an entirely new transaction, there is no real difference. The difference is more subtle and is related to liability issues, as the user presents the PIN while knowing the amount. That is discussed below.

Small transaction with dead battery

This last one is the “killer use case”. Cards don’t have batteries, so nobody worries about cards being out of juice. For phones, the problem is different, and issuers are afraid that users relying solely on their phones for payment may be stuck in a bad situation if they run out of battery. It would be nice for them to be able to at least make a small payment, for instance to buy the train ticket to go back home.

Actually, this can be addressed. First, contactless readers provide power to cards, so they can provide power to the SEs embedded in phones. Then, if this is not enough, it is quite likely that although the battery is not charged enough to power the entire phone, it has enough power for the NFC controller. So, basically, this can work (the MicroSD case is a bit more difficult, since their antenna is too small to get power from the reader, so they need to be fully powered from the mobile device). So, here is the (very simple) transaction:

1. Ada takes the phone out of her pocket
2. Ada taps the phone on the reader
3. Ada gets feedback on the transaction from the payment terminal

So, what has happened? The mobile wallet has been transformed into a single contactless card. There is no way to select a card, there is no way to present a PIN, there is no way to prevent a transaction from being made. Yes, a NFC phone with a dead battery becomes a simple piece of plastic with a SE.

In principle, this is OK. The user simply needs to select the default card to be used in such a situation, and to select the option that allows transactions to be performed with the phone off. However, in the case of a dying battery, this choice needs to be done while the phone still works.

In terms of security, this is not bad. Claiming that it is not sufficient is equivalent to claiming that the security of all contactless cards is not sufficient.

PIN, PIN, or PIN?

We have seen that the use of PINs is an interesting part of NFC payments. However, this same name covers a number of different mechanisms, or at least different uses. Here, we will consider three distinct uses:

• Unlock your wallet. This particular PIN is a code that is used when first accessing the wallet, in order to “unlock” it. This PIN code is managed by the mobile wallet application (on the mobile device), although the PIN itself can be managed on the SE. More importantly, this PIN is provided before even choosing the payment card, which reduces its use as a “traditional” PIN.
• Authenticate the user. This use case happens when the end user can present the PIN before to actually perform a transaction, to unlock a particular card. The PIN is presented to the card, and it will authorize the next transaction for a limited time. Of course, the timing is enforced by the mobile device, since cards don’t have a real-time clock. Also, since this PIN is presented before the actual transaction, it cannot be considered as authenticating the transaction.
• Authorize the transaction. This use case is the traditional use of PIN, when it is entered on a PIN entry device, part of the payment terminal. In that case, the payment terminal first displays the amount to be paid, and then asks for the PIN. In that case, the PIN is more powerful, since it shows that the user has authenticated himself after looking at the transaction’s amount. In fact the PIN entry device security requirements are careful about protecting the PIN, and also about ensuring that the correct amount is displayed.

Of course, the difference between these three types of PIN are subtle. The user, who enters a sequence of digits, may not realize the differences. However, in terms of liability, things are different, as we are moving into more and more responsibility for the user. For instance, the first kind of PIN (opening the wallet) does not even imply that the user wants to make a payment; the user may just want to adjust a setting on a card, or register a new card. On the opposite, after entering the last kind of PIN (on a payment terminal), the bank knows that the amount has been presented to the user before he entered the PIN, so it is more difficult for the user to make a “I didn’t know” claim.

A few threats

First, let’s not forget our starting point: a contactless card. If you have a contactless payment card, a few bad things may happen. Your card may be stolen and used by somebody else. If there is no PIN to present, this will just work. Or somebody can get close to you and make a transaction directly from your pocket. They may not even need to be that close, provided that they have a powerful enough field (they will just fry your brain a little as a bonus, but they may look suspicious with their big antenna).

If things go well, dynamic card authentication should be used, which means that each transaction uses a random challenge that the card need to encrypt to prove that it has the appropriate encryption key. In that case, the good news is that you don’t have to fear about someone copying your card.

Now, if you move the payment application to a mobile device, the same threats remain: somebody may steal your mobile and use it to pay for something, or some guy may just come by and perform a transaction from your pocket.

Well, not necessarily. On an Android phone, by default, the NFC interface is only activated when the screen is on. This means that you need to turn your screen on to perform a transaction, and it also means that your phone is safe in your pocket (actually, safer than your contactless card).

And if you are using a Google Wallet, it comes with a lock. You need to know a PIN to open the wallet. Even if this mechanism can be attacked, it is still better than your traditional wallet, which usually doesn’t include a lock.

So, what’s new? Or more importantly, what’s worse? Well, the main thing is that your mobile device (and your SE) happen to be connected to Internet. This is not good, since this is a new origin for an attack. For instance, the famous relay attack can work very well there. This is not easy, of course, since it requires some mobile malware that has the privileges required to access the payment application. Still, it is possible on your phone, and not on your standard contactless card.

Naturally, everything that works on a contactless smart card also works on a Secure Element. So, expect power analysis and fault induction attacks to be around. However, unless something new happens, there is no big fear to have. And even if it does, the payment application on your mobile device is more likely to be upgraded as required than the one on your (not connected) contactless card.

Overall, I don’t see much differences so far in terms of threats. Of course, such statements are systematically proven wrong by attackers, so don’t forget to check regularly.

Conclusion

You may be more confused after reading it than before; if so, it may mean that you have been exposed to some of the complexity behind NFC payments.

All of this complexity is manageable, but not easily. Because some basic hypotheses from the previous models are broken, many stakeholders have problems adapting to the new situation. Some of these problems can be addressed by reasoning and adaptation, but it is likely that a few problems will require innovative solutions.

My personal opinion is that security certification is one of these issues that will require fresh thinking and new solutions. However, not everybody agrees with me, and the debate has already been going on for a number of years. So, there is more fun to come in this area.

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 enough when they decided to store the salt just next to the hashed PIN value. Of course, with these two pieces of information, it takes at most 10,000 attempts to find the PIN (just check the video of the attack if you doubt that this is a very small number).

But hey, it’s just an attack/vulnerability. Maybe the first one, most likely not the last one. What surprises me most is that all these wallet programs insist on Common Criteria certifications of the Secure Elements, very complex certification programs for SE applications, and yet they leave behind this kind of basic vulberability in the mobile application, whose security does not seem to be formally evaluated by anyone. At least, the SIM/eSE security specialists should be able to sleep well for a while: they are unlikely to be the best target for real attackers, with such low-hanging fruit.

What really puzzled me from the zvelo guys is their analysis of what needs to be done. Their first step is correct: this PIN (which is used to open the wallet, not to validate a transaction) should be stored and verified in the Secure Element. Now, what surprises me more is their next statement:

Basically, by moving the PIN verification into the SE itself, this might constitute a “change of agency” responsible for keeping the PIN secure. The fear is that Google might no longer be responsible for the security of the PIN, but rather the banks themselves. If this is in fact the case, then the banks may need to follow their own policies and regulations regarding ATM PIN security which obviously, and rightly, receive a great deal of scrutiny.

Now, this doesn’t look good. First, about the ownership of the SE. I am not sure what the deal between Google and the phone vendors is, but I would say that the SE is owned either by Google or by the phone vendor. After all, they are the ones who control the SE’s master keys.

Even if we don’t consider that, Google would not store the PIN in somebody else’s application. I am sure that they have their own app in the SE, that they would use this app to manage their little PIN. This is very easy to do with Java Card, and I am sure that they can develop this addendum easily.

Finally, as mentioned above, this PIN is not an ATM PIN, because it is not linked to a specific transaction. When you enter the PIN, it opens the wallet, but it does not authorize a transaction. It is the digital equivalent to putting a four-digit combination lock on your wallet (which is exactly what Google is claiming).

Nevertheless, the story remains interesting, and it reminds us of the complex ecosystem behind NFC payments. For instance, did the banks consider the Google PIN in their risk analysis of the Google wallet? Well, if they did, the Google PIN is now a bit weaker. It is not broken, though: a combination of malware and physical access to the phone is still required to make a fraudulent transaction.

To conclude on a positive note, the end of the zvelo article is a good list of recommendations. If you keep your phone clean and locked, the bad guys will have to find a better vulnerability.

The technology is now ready, and it has not evolved greatly in the past few years. Java Card and GlobalPlatform are mature, widely deployed technologies; many companies are able to develop and deploy cards. Of course, there are a few technical challenges remaining, to keep engineers busy. One of the most challenging tasks is the establishment of trust between the various actors of the industry; today, formal security certification is at the heart of this, but something a bit more innovative will most likely be required here.

The new frontier for cards and secure elements are applications. This is much harder than implementing technology, and requires a lot of innovation. Will we be able to differentiate smart cards from tags? Will we find a room for card applications between basic SIM authentication and TEE applications? Will there at some point be a way to work on this? That’s the Chip-to-Cloud challenge, and I hope to get a few interesting answers next September.

The Call for Papers is out now, so go ahead, propose things. I am convinced that this conference will remain one of the places where academics, industrial R&D, and technical marketing people are able to meet and exchange. See you there!

Just imagine a world where a company can deploy its preferred network security application on all devices, while benefitting from SE-based security, or where innovative ccompanies ccan design security applications that rely on SE applications. Sounds good? Well, too good, because this is just not our world, at least not today.

There is an obvious reason for this: the “owners” of these eSE’s, whether they are phone vendors (Nokia, Samsung, …), wallet vendors (Google, Isis, …), or others, are not opening their devices. It is therefore very difficult to load applications on them. The most open environment that I know is in France, with AFSCM, but as far as I know, this is an operator-dominated, SIM-based world, which has a long history of managing resource-constrained SIM cards.

So, why is it different with the relatively new players who own/manage embedded Secure Elements? My gut feeling is that memory limitations are part of the problem, if not the entire problem. If you think of an iPhone, memory is almost infinite: if you are missing memory, simply remove one or two songs out of the 2000 that your phone contains, and it fits. On an eSE, things are different: think of a 64k SE. If it already contains 4 applications, each using 15k of memory, there is no way to add a fifth one. The numbers are here very different, and the choices are much more limited. I don’t think that many iPhone users ever get to the point where they need to eliminate content that they really need to fit another content that they also really need. On a card, no such luck. And for a platform manager, this is very difficult to deal with, so their priority will be to get their applications on this, or at least the applications that can bring them immeddiate and/or obvious returns.

The problem is very different with a Trusted Execution Environment (TEE). Applications are here stored in the phone’s main memory, so there is no shortage of memory. This means that, for TEEs, it should not be too hard to actually use app stores or similar infrastructures. For eSE’s, we will need to work a bit more in order to achieve the same result.

My first post will be a rant about something that is very-much holiday-related for me: package deliveries. I am a big-time online shopper, which means that I often get deliveries. And of course, during the holiday season, I get a lot of deliveries, from many different vendors.

Until recently, My deliveries were all coming to the office, as this was a local tradition in our Trusted Logic office. However, now, I work in an office with much fewer people, and sometimes from home, so it is not as easy to organize deliveries at the office. So, this holiday season, I got everything shipped at home.

Of course, I live in a closed residence (some code is required to get in), and my postal address allows you to find my mailbox easily, but not necessarily my house (no street numbers). All of this makes me a perfect guinea pig for testing delivery services.

So far, the best service remains the basic Post Office service. They have the key to the mailbox, so they will use it for anything that fits in it. Just great. Of course, if it doesn’t fit, I have to run to the Post Office and stand in line for a while. Even their express service is worse, because they need a signature. So, if I’m not home, they will not leave the package, however small, and I’m back to the Post Office.

With other delivery companies, things get much worse. First, going to the Post Office is not an option, because their “regional center” is often 30 or 40 kilometers away. Then, they don’t have the key to my mailbox, so they won’t leave a package, however small.

And finally, they call you when they are blocked right in front of a locked gate, or waiting outside your door. Even for me who works close from home, this is not very easy to handle, because we are not always immediately available, and because the guy can’t wait indefinitely. In the end, the “express” package took 24 hours to rush from Hong Kong to Nice, and one full week to get delivered. Not efficient.

So, what’s missing? Let’s consider two things:

• I can’t manage the delivery. I can track the package, I can know that the delivery guy has started and will try delivering to an empty home, but I can’t do anything about it.
• I can’t sign off for a delivery when I am not home. So, the guys won’t leave the package in my mailbox.

Now, if we look at both issues, we easily find out that this is a trust issue: delivery companies are not sure of who I am, so they will not trust me. Why so? Because they are not able to associate me to my package when I am at home, in front of them.

This definitely looks like a problem that can be solved. Companies like TrustFabric already allow you to selectively share information with companies. They don’t support this yet, but there is definitely some information that I would like to share with delivery companies (possibly including a detailed map, GPS coordinates, or whatever may get them to me).

Having this link through a trusted third party also solves the other issue. If I simply associate my TrustFabric account to a public credential (OpenID or similar), I can now login to their site and update the directions for the delivery, to lead them to where I actually am, or to acknowledge the fact that I am allowing them to leave the package in my mailbox without a written signature (a digital one will do).

As TrustFabric and others are getting their offers ready, this is getting closer to reality. Let’s hope for this new year that they will cover this delivery nightmare, and I will not have to do the same rant.

Here is the sentence that first drew my attention:

A wallet you can lock. Stay safe with the Google Wallet PIN and with secure underlying technology.

This started again my love/hate relationship with Google. A wallet you can lock? It’s just brilliant, far better than anything else I have seen on the same topic. Where do they find these things? Now, let’s see how the rest fares, from their Security section.

Google Wallet stores your encrypted payment card credentials on a computer chip on your phone called the Secure Element.

Sounds good. The Secure Element is explicitly defined as a separate chip. I find it interesting that they feel the need to mention that the credentials are encrypted.

Think of the Secure Element as a separate computer, capable of running programs and storing data. The Secure Element is separate from your Android phone’s memory.

Once again, all of this sounds good. Very nice way to describe a smart card.

The chip is designed to only allow trusted programs on the Secure Element itself to access the payment credentials stored therein.

Uh oh! I really recognize my favorite Java Card firewall, isolating applications from each other. But I am a bit disappointed to read that the “chip” is designed to support that. Yes, the chip’s memory can only be accessed from the chip itself; but on the chip, the isolation is software-based.

Next step, the FAQ’s Security and Privacy section. Among basic questions about lost phones, there are two good questions related to secure elements:

• What is the Secure Element and how secure is it?
• Could a malicious application access my credit card on the Secure Element?

You can read the complete answers there. However, here is what should be the most important sentence, since it ends the answers to both questions:

There are multiple levels of protection for data stored on the Secure Element and it is protected at the hardware level from snooping or tampering.

Of course, smart card specialists know about all the terrible attacks hidden behind the “snooping and tampering”, and how to protect from them. But the sole mention of data is a bit disappointing.

The answers also mention several times that only the Google Wallet (and other authorized programs) can access the Secure Element, and that this access control is strictly enforced. This is good, and we all like the fact that access control is present.

Now, what’s missing? You may have guessed it from my “data only” disappointment. There is no mention of the fact that the secure element can do more than payment. So, Google, if you are reading this, I will go as far as writing the missing FAQ piece:

Can I use my Secure Element for protecting other assets?

Your Secure Element is a small but powerful chip, which runs its own applications to manage sensitive data. It can even host several applications, to provide different security-related services. Of course, since the access to the Secure Element is strictly controlled, only authorized developers can write applications for it. We have selected a limited number of partners, who provide applications that rely on the Secure Element to manage their security credentials. These offers include VPN application, secure authentication applications, and much more.

Hoping that it will become useful someday. And if you need more material on Java Card, just let me know.

It is not the first time that I consider joining this team (considering all kinds of positions). It never worked out with Sun, but Oracle offered me the change that I was waiting for at this time. Also, I appreciate the challenge of joining one of the leading Silicon Valley companies, even if I am only remotely connected to the heart of the company.

There are many challenges to be faced. Java Card currently dominates open smart cards, with very high penetration rates. Of course, I will work to make this domination continue, to make Java Card’s success continue in the coming years, and more importantly, to make Java Card the best answer to the challenges faced by the digital security industry.

This should be rather easy, as I still believe after 15 years that the Java Card technology is the best choice for the industry. Those who know me already know that I need to truly believe in what I sell, push, or promote. In the case of Java Card, this definitely is true, so I look forward to my new job with great envy and energy.

I will naturally attend the Cartes show in Paris. So, if you plan to attend, see you there next week. I may be stuck in meeting rooms most of the time, but you can still reach me at firstname . lastname at oracle.com .

Last but not least, I will keep this blog open for now. My bias in favor of Java Card won’t be really worse than what it already was, and hopefully, I will gain some freedom on other topics, and the tutorial will make a comeback.

Although this draft was officially authored by Sun Microsystems, Schlumberger played an important role there. This is why I am quite sure that the spec was released at the end of the month, since one of Schlumberger’s main patents on the topic was filed on October 25, 19996. The main topic of this patent is to use a high-level language to program a microcontroller, and it claims in particular the transformation of a class file into a more optimized format. Quite a good idea, at least sufficient to include this patent in the suit against Google‘s Android (which may be a proof that Android is yet another derivative of Java Card).

Good idea, but everybody trying to fit something on a card was ddoing just the same. The really brilliant idea was not to generate an optimized format, but to believe that it would be possible to start from something as different as Java. This was brilliant at the time, especially since in 1996, Java was definitely not mainstream technology, and was often considered as too expensive or too slow even on a PC. Now, that’s something for which the guys in Schlumberger can be congratulated.

Of course, they were not the only ones to try fitting unlikely things into a smart card. Researchers in Gemplus were more focused on object oriented technology, in particular Corba. And naturally, they needed to think about optimization in order to fit this into a card. They were using Forth as their base language for the Combo virtual machine. Even before that, as mentioned in this history of bytecode interpreters for smart cards, researchers at RD2P designed a bytecode interpreter, as early as 1990 (I can’t even imagine the memory sizes of cards at that time; if somebody knows, please leave a comment).

Now, the interesting part is that a patent has been filed in France (sorry, in French only). And one of the key elements of this patent was the fact that the programs are later compiled for the specific embedded virtual machine.

Not quite Java Card, though, because the patent only mentioned direct compilation from source code, not using an intermediary format (a.k.a. Java class file). The difference is slim, and I would be tempted to credit the French guys with the invention of optimized smart card code. However, there is something that the Schlumberger guys did much better: timing. The French patent, filed in 1990, was never extended into an international patent, whereas the American patent has been extended and mainained to this day.

As a final trivia note, did you smile when I mentioned that Android was a derivative of Java Card? Well, very indirectly, but somehow, a little bit. Java Card, after being initiated by Schlumberger, was maintained by Sun Microsystems. Sun’s Java Card team later convinced Sun to develop a slightly larger VM, the KVM, to address very small devices. This VM was then extended into MIDP, which became the leading platform for phones. And everybody knows that the Android team includes a number of ex-Sun employees who used to work on MIDP. So, yes, indeed, Android a a distant heir of Java Card.