So, until some “velocity checks” (counters) are added to CVV2 validators, this is the lowest hanging card. The funny thing is that, since it only takes 6 seconds, changing the CVV every hour doesn’t really work, here, so the new Motion Code is not a good countermeasure.

Smart card hardliners will tell you that this isn’t a smart card issue. Sure, but it’s related, mostly because however high, there is always a lowest hanging card. Smart cards (with EMV) have been quite efficient at curbing card-present fraud, because the chip computes a dynamic verification code for every transaction. During the EMV rollout, fraud was taking place in countries where smart cards were not used. As this rollout is getting closer to completion, this opportunity is slowly going away.

The new lowest hanging fruit is online transactions. EMV doesn’t work online, mostly because all attempts to introduce card readers on normal PC’s have failed, so our smart cards are useless here. And because consumers haven’t been used to use their cards’ chips during online transactions, they won’t do it on mobile transactions either.

Sadly, commerce is moving online these days, so it is not good news to find the lowest hanging fruit there. The CVV2 check will be fixed, and more merchants will use 2-channel verification methods like “Verified by Visa”. Then, it is not obvious to know what will be the new lowest hanging fruit.

One solution is to use mobile payment, which offers a much better security these days. It works for in-person payments, and it is starting to work for online payments made on phones. I haven’t seen mobile payment used for to verify online transactions not made on a phone, but this would be very easy to do.

The main message of this presentation is that payment in wearables is going beyond basic plastic bands and special watches. The new trend is now that payment is being integrated into normal fashion accessories, like the Swatch deployment in China, or the integration of payment in the latest Jawbone UP4. These deployments are linked to a payment scheme: China Union Pay for Swatch, and American Express for Jawbone. Still, it is exciting to see mobile payment integrated into generic devices that you mostly get for other things (like, you like the watch, or you like the fitness tracking features and band design. Here, payment is just an extra feature, which is likely not the main reason for selecting the object.

From a sales point of view, this looks important to me. If payment is successful in these first deployments, it could lead the way to many more similar objects. As a longtime user of vision glasses, my glasses would be the perfect object for payment, as I wear them in almost all circumstances (plus, the form factor is interesting for fitting an antenna).

This does raise a few security-related questions:

• Transfer. Such devices all come with some kind of enrollment process, for instance through the UP mobile application for Jawbone. This is nice, but the life of the object continues beyond enrollment. A fitness tracker may be given or sold to another person, and it is reasonable to expect that the payment feature will need to be disabled, and potentially reenabled later (and again).
• Loan. A fitness tracker is very personal, a watch a bit less (my teenage daughter can borrow mine if she happens to like the design), and I am sure that some other payment-enabled wearables will be shared, at least in a limited community. I am happy to share my watch, but I want the payment feature to be disabled when that happens.
• Steal or lose. Here, the problem is that these payment-enabled objects become an extension of our wallet. Losing one is very much like losing a wallet, and this may become dangerous, especially for people who only use the payment feature very occasionally. Also, checking that the person using such an object is legit will be difficult or at least different.

I don’t own any of these devices, so I don’t know how they handle that. Maybe that all these issues, and more, have already been sorted out technically. Yet, there is a human aspect to that will also need to be field-tested. The users need to be aware that they are wearing payment cards. Not much of an issue when you only have one payment-enabled object, but this could become a problem if we get more and more such objects.

But then, these are interesting problems, and I can’t wait to find my own payment-enabled fashion statement, and to see how this evolves in the near future.

I have been quite happy to hear a few weeks ago that Gemalto finally decided to consider NFC as more than secure services, by launching their POPWings service. I immediately ordered one of their business cards, excited to get a new NFC service.

So, I got a card with my blogger identity, and I scanned it with my Nexus S. This opened my Popwings page in the browser, showing my information. I was even able to link directly to my blog, open Twitter on my feed, everything was fine for a Web part.

Next step: download the application from the Play store. I just did that, and I have to admit that the feeling was not the same. I expected the application to do more than the simple link, and as far as I know, it doesn’t. OK, it will store locally my POPWings contacts, instead of showing them one by one. But as soon as I open this application, I am stuck in POPWings world. In particular, what hurts most is the inability to add this contact to my phone’s contacts. Let me be clear on this: it took me forever to get a contact database that will synchronize between my different accounts, and I definitely don’t want to change that.

It looks that POPWings is trying to deal with customers the Apple way: first, you buy a product from us, and then you are stuck in our ecosystem. That kinda works for Apple: I just got an iPod that I love as a device, but I hate Apple’s dysfunctional Windows software (disclosure: I am an Amazon fanboy for music, including the cloud player, and the primary reason for getting an iPod is the ultra lightweight form factor).

The problem with Popwings is not in the application, but in the philosophy behind it: it limits me rather than empowering me. I bought a new-generation business card, and what I got is a contactless smart card with my name on it, that doesn’t even work as a standard business card, since my contacts can’t easily put its content in their list of contacts.

UPDATED: Although the application is more open than I initially experienced, it still attempts to create a new and private ecosystem, which doesn’t seem to be the way to go. More on this in the update.

As you may have guessed, I wouldn’t bet on Popwings today, especially With the current application. Nevertheless, the idea remains good, and I would love to see it turn into a wildly successful ventures. Here are some suggestions:

• Market to the end-user. Actually, Popwings got this one right: adoption will come to end-users, and the best way to force ourselves into making useful NFC applications is the need to convince them to buy our product.
• Don’t lock the end-user. This is where Popwings fails. It would be so much better if it allowed me to add a contact to my contact list, or to interface it with other applications: the more, the merrier.
• Encourage new uses. This is where Popwings can become a platform more than a mere application. By encouraging others to develop applications that leverage Popwings business cards or to integrate Popwings cards in their application, these NFC business cards can become a de facto standard, unlocking a huge market.
• Focus on the platform, not the app. A first-year student can write can write the Popwings app, but it takes slghtly more effort to build a platform that correctly manages NFC business cards or other cards for use in Web/mobile applications.

My 2 cents.

The reasoning goes on with a comparison of the security merits of a credit card number stored on Passbook and a real card. Read the paper for the details, but an obvious comparison is that a real card is easier to lose/steal (because we stick to our phone more than we stick to our wallet), and also easily accessible (the phone will be at least somehow encrypted, requiring some technical skillls to access the card numbers). In addition, credit cards are easily replaceable, and they usually entail a zero liability insurance for the end-user.

What surprised me is the conclusion: “convenience wins in the consumer mind”, and more specifically, “convenience may win out over a little risk”. From the risk analysis, my feeling is that using Passbook is actually less risky than carrying real cards, and even if one doesn’t agree with that, zero-liability means that, for the customer, the risk is the same: zero.

Although we agreee that security is a way to reduce risk globally, there are many different ways to reduce risk for every actor. For the end-user, in that specific case, the key aspect is the zero-liaility insurance offered by the credit card company. If there is a major security flaw in Passbook, there may be a problem between Apple and credit card companies, but end users should remain largely unaffected. The worst thing that could happen to them is to lose the convenience of Passbook if credit card companies deny to Apple the right to store card numbers in it.

Just another friendly reminder that our job as security providers is not just to randomly increase security of things, but to actually reduce the level of risk for an actor, which should be our customer. Banking smart cards are sold to banks, not to end users, and there is not reason to change this relationshp when the cards are dematerialized into software: our customers are the banks, and we need to reduce their risk (which, hopefully, can help them offer a zero-liability insurance to their customers at a better cost).

Disclosure: I just finished reading Brice Schneier’s Liars and Outliers: Enabling the Trust That Society Needs to Thrive, which may explain why I have this unusual high-level view of security. Good book, by the way.

The motivation of myIDP is to reduce the amount of redundant data that we have to enter in various sites, especially related ot e-government, which is error-prone and leads to many validation problems. In the SuisseID, the idea is to add another claim assertion service. With myIDP, users can save data entered on e-forms that have been accepted by a service provider, for reuse in other circumstances. The idea behind it is that information that has already been accepted somewhere is more likely to be correct. Interestingly, the user has access to the recorded attributes, and can decide to remove some that she doesn’t want to be recorded.

MyIDP can function as an attribute provider or as a claim proxy . As an attribute provider, a service provider requests an attribute, MyIDP then asks the user to confirm the use of a recorded attribute, and signs it before to return it. As a claim proxy, the service provider request comes with a claim list request. MyIDP then returns the signed attribute together with a claim list URI, from which the service provider can download information about where the information has previously been accepted as valid, and use this information to decide how trustworthy the attribute is.

This project sounds really good, because once again, we are movng from hard identity to soft identity, where data is not 100% trusted but nevertheless more trusted than data entered manually. And of course, this model is very nice because, the more it is used, the more trustworthy it gets. The quality of attributes grows as they are getting used, and this is an important property.

Internet banking has now taken over as the main interface with banks, with of course a shift to mobile devices in the recent years. In the end, banking is adapting quite fast to technology, because customers expect them to move fast (if they don’t, customers can switch).

So, the banking ecosystem has adapted to integrate new technologies, and they do that fast. Of course, at least according to Vasco, the problem is fraud, and the solution is authentication. Vasco’s answer includes platgorm evaluation (jailbroken or not?), user evaluation (2-factor authentication), transaction evaluation (2-factor authentication again) and finally validation.

The next idea is to use NFC to improve 2-factor authentication, for instance to provision keys, to perform WYSIWYS checks. On the opposite, 2-factor authentication can benefit to NFC, by providing flexible authentication.

That all sounds interesting, but I will need a bit more technical information to undrstand what they are saying. In particular, I am always careful with solutions in which one of the 2 factors needed for authentication isnthe device on which I want to do something. This may not be very rational, bit I am not feeling good about it.

Of course, this presentation was a lot about advertising, and yiu can better understand where Vasco is going to by getting to MyDigipass. This offer sounds interesting for securing online accounts. Maybe that I will consider giving it a try.

To celebrate that, I have decide to attend the opening session this year. We started by an enthusiastic eID spporter from European Union, promising us all regulations and standards ready for 2014, which sounds interesting. After all, there are very interesting deployment in countries like Belgium and Estonia, which could be extended.

Then, we get a panel, with the question below. Speakers are Christian van der Valk, from TrustWeaver, Herrmann Sterzinger, from G&D, Massimo Cappelli, from Global CyberSecurity Center, and Marie Figarella, from Gemalto.

Why has eIAS services not been a success to date?

• Is it really the case? There haven’t been failures, there are many services ready to,use, and a lack of recognition, with a common perception that digital signature ismore difficult than it actually is.
• Citizen certificates are too expensive, and the use cases are not compelling enough. Thisis changing in some places, like in Austria, where the state pays the citizen certificate.
• Market fragmentation and lack of trust and confidence are the two main issues. They may even be linked because the fragmentation does not allow the development of global solutlons, deployed across Europe.
• Issues have been legal and societal, not technical. Fragmentation and lacking use case are the most important,

How would the new electronic identification and trust services regulation improve on this situation?

• Moving from directive to regulation is important
• Making it global would be good, but also hittin some limits, in particular regarding discrepancies in privacy requirements.
• Moving to a regulation will limit fragmentation, the scope will be larger, going beyond signatures to seals, timestamps, and more. Mobility between states will also be greatly improved. Finally, supervision should be improved.

What additional key actions would be necessary to make eIAS a success?

• Sharing identity and authentication between public and private spheres would help. Also,aligning with the global market with help, including private support, like Adobe. Also, the recognition of non-PKI solutions would be required (that sounds interesting)
• Moving beyond web authentication is required. Moving to global regulation loses things, such as already deployed eIDs, which do not comply to the new regulation, and also existing standads and existing profiles.
• Bureaucratic simplification associated to eIAS would be great help. We are also missing a common framework of expertise, with collaboration between national agencies. Thereisalso a digital and cultural divide, which hurts wide adoption. Finally, including soft identity would increase the use of strong identity, if it can be used in our everyday life.
• Associate reliable digital identity with a portable secure elemnt, to allow 2-factor authentication. Build an open and interoperale secure Internet. Privacy by design. Push digital identity on all SIM cards to benefit from NFC

Now, that’s quite interesting. The views from the panelists are quite consistent. The question that puzzles me most is the relationship between national and private identity. I am left wondering what opportunities will be given to private companies and web providers to leverage this eID. Making this happen would be a great boost to eIAS.

I also liked Gemalto’s analysis and proposals, which was short and to the point, except the last point, of course; mandating SIM-based identity for NFC is ludicrous and pure lobbying, at least because the SIM is not the only way to access NFC.

So, an interesting first panel, although there haven’t been many suprises and illuminating discussions.

Every card is identified by a card number, an expiration date, and a cardholder name. Naturally, there is more to it, and the interesting thing is that this “more” depends on the card you have and the way you use it. Let’s consider three examples of payment in the US:

• In a standard store. In such an interaction, your card is present. You swipe it, and provide a signature if required. In that case, the security code is encoded in your card’s magstripe. This code is often called CVC1 in jargon (Card Verification Code 1).
• On Internet. In such an interaction, the merchant can’t see your card: this is a card-not-present transaction. Therefore, you need to provide the code. Here, it is the 3- or 4-digit code that is printed somewhere on your card. This code is different from the one on the magstripe, and it is called CVC2 in jargon.
• In a store with contactless payment. In that case, instead of swiping your card, you tap it. When you do that, the card generates a Dynamic CVC, based on a secret it contains and on a random number provided by the terminal. In that case, a different code is generated on each transaction.

On every transaction, there is a code, but this code depends on the transaction type. The two first ones are easy to steal from you: The CVC2 is printed on your card, and the CVC1 can be read in 2 seconds with a $5 skimmer. Naturally, in that case, this security measure is only a small part of risk management, and there is more. For instance, since merchants have the best opportunity to steal these codes from you, banks are very good at detecting that fraudulent transactions come after a transaction at a given merchant.

With a contactless card, the code is generated dynamically for each transaction. This means that, even if someone intercepts your communication (which remains rather easy, since it happens over-the-air), the code that they intercept can only be used for this particular transaction, an not for a new one. Basically, it is useless.

In the US, mobile NFC payment uses the same technology as other contactless payments, which makes it rather secure. In addition, it is not possible to turn off a contactless card, whereas a mobile phone’s card emulation mode is usually only active when the phone’s screen is on (i.e., when you actively use it).

Outside the US, things are even better, because card transactions use a more sophisticated cryptographic protocols, which include an authentication of the cardholder (the (in)famous PIN). This is actually quite efficient, and fraud statistics in France show that most fraud is based on magstripe and Internet sales.

Finally, one last authentication method. Chip-based payment cards can also be used to secure Internet transactions. Some companies like Vasco sell small card readers that generate authentication codes dynamically, allowing these codes to be used to secure a single Internet transaction. This brings the security of in-person EMV payment to Internet payments.

Naturally, like usually in security, this is all a question of trade-offs. It is only worth investing in such technologies if the fraud is high enough. Card companies seem to believe that something is needed in the US now, since chip-based credentials will be required by 2015 in the US.

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.

From Onzo’s Tim Holley and Oracle’s Jean-Yves Bitterlich, this is about Project Hydra. The project starts by healthcare issues caused by an aging population. The problem is to figure out what we can do at the infrastructure level to help addressing tomorrow’s growing helath issues of our elderly. This basically means being proactive.

Telehealth is possible, but the data needs to get out of the home. And since we are not talking about highly connected people, smart meters seem to be a solution. Smart meters bring a communication path into every home, and telehealth only transfers little data. The idea is to integrate new sensors (health sensors, like a scale or blood pressure) into the devices accessible from the smart meter infrastructure.

The idea is to add value-added services into smart meters, making it possible to get a better return on investment on the deployment of smart meters. This is the goal of Project Hydra in the UK. The idea is to integrate telehealth services of weight and blood pressure. The project combines a local Zigbee network to an external GPRS connection at the communication gateway shared by all the meters.

So, why smart cards in this project? The platform need to be able to evolve over time, with remote software updates, or added support for new devices over time. Of course, security is important as well, and isolating the applications from each other sounds like a good idea (the utility company doesn’t need to know about your blood pressure). All of this sounds good for Java Card:

• Protecting valuable assets. Yes, smart cards do that.
• Devices distributed in uncontrolled environment. Yes, we know how to handle that.
• Personalisation during deployment. GlobalPlatform has everything it takes to do that.
• Protecting assets of multiple stakeholders. Easy with a good firewall and a few Security Domains.
• Remote software updates. This one is trickier, but why not …
• High volume, low cost. Yes, we know how to do that.

All these issues have already been addressed by the smart card industry. An interesting bonus is here that smart cards also address some basic smart meter issues, (security in tariff upgrades, management of pre-paid accounts, protection against hacking, etc.)

Naturally, combining Java Card applets and GlobalPlatform security domains, every application gets its own little home in the home gateway. One interesting remark is that the smart card becomes a one-stop shop for people who want to deploy new applications into the smart meters. But then, this raises the question: who controls the smart card in the smart meter? In a deregulated market like in the UK, this question may not be as simple as it seems.

An important point is that applets may address some privacy issues by performing some basic processing directly in the home, and to only transfer select information (for instance, when blood pressure is over a given threshold).

In the architecture, the smart card is pretty much in control, and they have defined a SIM Toolkit-like way of working, in which the smart card provides the terminal with instructions about things to do, like send this data to the outside, or wake me up for the next measurement 24 hours from now.

Java Card 3 Connected would also allow the user to access its own data directly from a Web browser. This provides a partial answer to one of my favorite questions: Would the (younger) family members be allowed to get the information? They have more incentives than clinicians to actually use the information, and such a use raises very interesting security issues, and even more interesting privacy issues, because the elderly have a right to privacy, even with respect to their children.

Surprisingly, the main problem is here to be ready on time, because in many countries, the deployments are scheduled before 2020, which is awfully close when you don’t even have a specification.

Good luck to this project!