pros and cons of secure element and hce february, 2014 ... · february, 2014! micheal gargiulo, tng...
TRANSCRIPT
NFC Credentials in the Cloud Pros and Cons of Secure Element and HCE February, 2014!
Micheal Gargiulo, TNG Technologies [email protected]
Page 2
Preamble
“Price is what you pay. Value is what you get.” Warren Buffe,
Page 3
Discussion Assumptions
n Track data is US magnetic stripe
n The Smartphone OS is NOT secure
n Use case is mobile proximity payments using NFC as the physical layer
n Smartphone is OS independent
n Secure Element is UICC based
n The payment scheme is provided by an existing network
n Hackers and fraudsters are everywhere
n HCE / NCI routing issues not considered
Page 4
Information Exchange Basics – Near Field
n Physical antenna design stores energy in an electromagnetic field rather than radiating it into space.
― Sensitive data is whispered rather than shouted.
― Smaller attack surface at the physical layer due to the rapid energy fall off with distance from the antenna
n Inductive coupling used for power transfer (NFC Tag) and information exchange
n Communication protocols include ISO 14443 A &B and Felica
n Services include, Mifare, NDEF tags, PayPass, PayWave, Zip and Express Pay
Morse code style Near Field Communication
Page 5
The Secure Element
UICC
NFC
Modem/CLF
SWP/HCI
n Designed to reside “behind enemy lines” so it MUST be secure
― Carriers have depended on the SE for more than 20 years to provide network authentication based on a locally stored private key (Ki)
― Certified to Common Criteria and payment network standards
― Global Platform standards are utilized to securely manage application lifecycles in the execution environment
― Communication on the contactless interface (SWP) is isolated from the Smartphone OS
― TSM provides OTA security and remote application management
n Dedicated microprocessor that provides secure processing independent of the smartphone
n Dedicated OS and memory including RAM, ROM and EEPROM
n JavaCard or MultOS execution environments
n Optional dedicated crypto processor
Page 6
HCE / Cloud Based Credentials
Payment Reader NFC Antenna
APDU / NCI
Base band
OS
Wallet APDU
Modem CLF
APDU generator
Process manager
Database
HCE Service
Cellular data, WiFi TCP/IP
TCP/IP
n DoS attack at the HCE service could block transactions at the POS because the service must be open to the public.
n Card emulation specification published in 2006, Blackberry version of HCE routing working in 2010. NFC NCI specification published in 2012.
n Data at rest in the HCE resides in friendly territory however data in motion is vulnerable to many attacks at the OS layer in the Smartphone
n It is unknown if the payment schemes would require existing JCOP applets such as PPSE and payment applets to function in the cloud
n Connectivity and communication latency are important issues. Some markets still only support GPRS or EDGE.
Page 7
SE Based Proximity Payment Flow
Reader SE Modem/CLF
Select PPSE
Send AcFve Card AID
Select AcFve Card
Send Track Data
Wallet
SE API
GP Access Control Stack
SE
OS
n PPSE and payment applet are safely stored locally in the secure element.
n Credential will be reliably delivered in far less than one second.
n Customer authentication can also be done with a credential stored locally in the SE
n The active payment credential is selected by the local wallet client and stored in the PPSE via the GP access control stack located at root level of the OS. Access control rules are stored in the SE.
Page 8
Online HCE Based Proximity Payment Flow
Reader CLF/NCI RouFng
Select PPSE
Send AcFve Card API
Select AcFve Card
Send Track Data
Wallet HCE
n Problem: How to securely identify the customer to the HCE server?
n There is an attack surface at the application layer and below that could negatively impact card selection and the payment data itself.
n For highest security the PPSE and track data generation functions are executed in the HCE server with round trip credential delivery not guaranteed to be under a second.
n Card selection requires connectivity update the PPSE and is also not guaranteed to be quick
Page 9
n Problem: How to securely identify the customer when offline?
n Proprietary temporary tokens that are pre-fetched from the HCE are stored locally. These tokens are reconciled on the backend before auth submission. Merchant must be online.
n There is an attack surface at the application layer and below that could negatively impact card selection and the security of the tokens. EMV could improve
Offline HCE Based Proximity Payment Flow Reader CLF/NCI RouFng
Select PPSE
Send AcFve Card AID
Select AcFve Card
Send Token
Token ReconciliaFon Wallet Auth Server
Account data
Page 10
Offline HCE Algorithms
n The underlying Smartphone OS should not be considered secure. Updates that plug security holes are not guaranteed to be delivered to the device.
n Truly secure algorithms that generate tokens or short term virtual cards locally depend upon keys that remain secure
n A TEE could potentially be used to keep offline keys secure. This is both a business and technical problem as there are no functional TEEs yet and the payment networks have not approved their security for any use case.
n Algorithms that combine two factor authentication on the client side to generate a short term virtual card that is reconciled by a second back end server have not been approved by any payment scheme. Algorithms that execute in an unsecure environment cannot be assured to produce a true result.
n The offline card selection function (PPSE) that resides on the Smartphone OS also cannot be trusted
Page 11
Summary
n The SE has existed for more than 20 years, has vetted standards and a proven track record for security
n Credentials from an SE will be reliably delivered in far less than one second.
n SE rent and management adds cost to the business model for a service
n DoS attacks at the HCE service could block transactions at the POS because the service must be open to the public.
n Credentials from an HCE server are not guaranteed to be delivered in a timely fashion
n Magnetic stripe track data delivered from the HCE server is subject to security holes in the OS
n Offline HCE algorithms including customer verification are not standardized, vetted or approved by any payment scheme
Secure Element
HCE
NFC n Smaller attack surface than FFC at the physical layer due to the rapid energy fall off with distance
from the antenna.
Page 12
Conclusions
n SE business issues can be negotiated to produce a workable solution.
n HCE is still a work in progress. With the addition of EMV, enhanced offline standards and vetting the technology may become viable for the mass market.
n HCE currently depends on the security of a Smartphone’s OS that is not assured. Published security breaches may sour consumers.
n HCE depends on wireless connectivity to back end services and the quality
and / or availability of connectivity cannot be assured. Poor reliability may also sour consumers.
n Low value applications such as merchant based offers and loyalty programs
may be viable for HCE due to low risk in an unsecure environment n TEE support could bolster the HCE use case but the business issues are
similar to those of the SE
Page 14
Information Exchange Basics – Far Field (Backup)
n Physical antenna design converts electron flow into electromagnetic waves that are radiated into the air
n Fundamental attack surface at the physical layer due to broadcast range from approximately 1m to infinity. Sensitive data is shouted rather than whispered.
n Security generally provided by encryption at an upper layer except for mag stripe contactless.
n Supports many communication protocols including Bluetooth, WiFi and cellular protocols
Morse code style Far Field Communication