Community

Mny thnks Karl. I overlooked the "host" part. 

Geez, I am rusty on Host Card Emulation but yes, now I remember. That takes us back to the first digital wallet wars when Google was forced into HCE because the handset vendors wouldn't allow access to the NFC chips. 

Do we really want to do all this again? 

I know that granting access to the NFC chips is hard. So it should be! But the effort needs to be weighed against the reward of proper hardware security, which HCE cannot provide.

Or can it?  

The article states:

"Apple would create the necessary APIs to allow equivalent access to the NFC components in the Host Card Emulation mode, a technology issued to securely store payment credentials and complete transactions, without relying on an in-device secure element."

I want to query the part about 'not relying on an in-device secure element'. 

As I understand Host Card Emulation, it does use a secure element, just not the same one as in the EMV smartcard. That is, the protocol will use Apple's iPhone enclave.

For a bank and a handset vendor to agree to use an NFC chip set to emulate an EMV card, thebank must satisfy itself that the NFC chips are more or less equivalent to EMV chips as "secure elements". 

It will bethesame logic when a handset's NFC chip set isused to hold an (emulated) eID, e-passport or mDL. 

If I am correct, then the article might be misleading for it implies that the Apple NFC offering would foresake a secure element. 

Steve Wilson, Lockstep Consulting. 

Can people please identity themselves? It's hard to thread conersatyions when it's "a finextra member". At least sign off your comments using some handle please. 

"Finextra member" commented
"But until now, there hasn't been a payment terminal in everyone's pocket...? When you say 'merchant, doesn't this open things up for mass P2P payments, such as paying a friend?"

No, it really doesn't. "Merchant" in a card scheme is a business that has signed up to the scheme Merchant Services Agreement via an Acquiring Bank. This is the guts of my original point: the party that can accept payments in a scard scheme is tightly regulated by the scheme, and must operate under a highly standardised set of rules and contracts. 

In particular, the merchaint must only use scheme-approved termnals or gateways. I reckon the guts of the Apple announcement must be that a scheme has approved the iPhone (plus a merchant app of some sort) as a terminal. As someone else said, authentication is a must; only approved merchants can be allowed to run such an iPhone app to accept payments.  

Some people are wondering if this announcement as paving the way to p2p credit card payments, but I only interpret it as meaning the iPhone is now able to perform the physical activity of reading the card, and presumably doing the necessary mutual authentication, maybe even secure PIN entry too. If the iPhone can thus act as a merchant terminal, then AFAIK it would still need to be running a card scheme-approved card acceptance app, which would connect to the card scheme network, after authenticating the *merchant* and thus helping to enforce the Merchant Services Agreement. 

It is great to see iPhones reading NFC payment cards -- this has been a long time coming. Now can we extrapolate to reading verifiable cryptographic credentials more broadly? The mDL standard will bring NFC based driver licensing, with embedded attributes like age and residencey. Some eID cards are NFC-capable now.  With a little standardisation push, we could see a transformation to "tap-and-prove" for all personal credentials. https://www.linkedin.com/pulse/tap-prove-stephen-wilson

I bet you just open the app and read off the PAN.

The "numberless card will make online transaction easier because users will simply copy and paste the details from the Curve app".  Really? 

This seems like yet another lost opportunity to make online payments as secure and as convenient as Card Present chip transactions! 

Why not use the cryptography in the card to verify the cardholder PAN? They should secrete the PAN inside a digital certificate and use an associated private key in the card chip to digitally sign online transactions, thus binding the PAN to the transaction payload.  The signature would prove possession and capture consent at the same time. 

See my paper "Calling for a Uniform Approach to Card Fraud Offline and On"  in The Journal of Internet Banking and Commerce, http://www.icommercecentral.com/open-access/calling-for-a-uniform-approach-to-card-fraud-offline-and-on.php?aid=38132. 

I've got several reservations about this class of identity proofing. Alarm bells ring when someone claims that biometrics are "infinitely more secure".  More secure in what way precisely? We need specifics.

Biometrics are not intrinsically immune to spoofing, and they continue to pose major headaches for disaster recovery. Once stolen (or synthesised by AI) they're still impossible to restore. 

AI/Machine Learning is creating "Deep Fakes" which threaten face and voice biometrics.  The anti-spoofing arms race has only just begun; we need to treat anti-spoofing with a grain of salt.  

And where is the ID document matching taking place? These solutions genberally take a picture of your government ID document and match your selfie against that.  Where are the pics stored? What are security arrangements? Some solutions send the photo ID off to a third party for document verification.  What do we know about thoese transactions, the privacy promises and the side effects? 

You're in for a wild ride with these solutions along the personal information supply chain. 

ENISA warns that "key management and encryption are still largely the same" challemnge with blockchain as traditional security. Well, yes and no. 

Certainly many blockchain pundits overlook key management.  I sifted through twenty-odd blockchain-for-healthcare proposals in the US Dept of Health & Human Service blockchain challenge last year, and attended the two day symposium at NIST headquarters. I was shocked at how few teams looked at key management. I don't just mean private key hygiene in hardware wallets and the like, but the management task of knowing which keys go with which users. See https://www.constellationr.com/blog-news/blockchain-healthcare-and-leading-edge-rd.

And here's the deep problem: blockchain's Proof of Work algorithm was designed so there is no need for key management.  It doesn't matter to the system which key goes with which user, because Bitcoin is electronic cash. Possession of the private key is all that matters.  Famously, you cannot recover lost Bitcoin balances if you lose your key, for there is no administrator. The absence of an administrator makes it necessary to crowd-source the overseeing of all currency movements (to stop Double Spends). That's what Proof of Work "consensus" does - it's the crowd satisfying itself that all spends are OK. 

When you hybridise blockchain, and adfold back in traditional key management and encryption (not to mention persmissions management for private blockchains), you take away the reason for being of the consensus algorithm. Why have crowd-sourced consensus when an administrator has already been able to oversee which key goes with which user?  As your selves: What is the real point of the original public blockchain? 

Consensus in the public blockchains as designed today becomes moot when you have key management. So yes, key management in blockchain technologies is much the same as with traditional security; just beware of where it leaves public blockchain architecture which was designed to expel all administration. Many hybrid blockchains look rather like solar powered race cars retrofitted with petrol engines to make them go faster.