NFC Technologies For The Internet Of Things

Transcription

NFC Technologies for the Internet Of
Things
Pr Pascal Urien
Telecom Paristech
Co-Founder of the EtherTrust Company
Pascal Urien, SMART 2013, june 24, ROMA
1 /54
Agenda
•
•
•
•
•
Introduction to NFC technologies
About NFC standards
NFC in mobile phones
Identity For NFC
Use Case 1: NFC Keys for the Internet of
Things
• Use Case 2: The Emergence of the Cloud Of
Secure Elements (CoSE)
• Use Case 3: Security
for
the
NFC,
LLCPS
2 /54
Introduction to NFC
Technologies
3 /54
•
•
•
•
•
•
Smartcard Genesis
1980, First BO’ French bank card, from CP8
1988, SIM card specification
RAM
1990, First ISO7816 standards
R
EEPROM O
1991, First SIM devices
M CPU
1995, First EMV standards
1997, First Javacard
1988, the 21 (BO’) chip
– The javacard is a subset of the java language
– Patent US 6,308,317
• 1998, JCOP (IBM JC/OP)
• 1999, Global Platform (GP)
• 2002, First USIM cards
Siemens
(SIM)
Pascal Urien,
SMART
2013,chip,
june1997
24, ROMA
4 /54
NFC Genesis
• 1994, Mifare 1K
– In 2011 Mifare chips represent 70% of the transport
market.
• 2001, ISO 14443 Standards (13,56 Mhz)
– Type A (Mifare)
– Type B
– Type F (Felica)
• 2004, NFC Forum
– Mifare (NXP), ISO14443A, ISO14443B, Felica (Sony)
– Three functional modes :
• Reader/Writer, Card Emulation, Peer to Peer
• NFC controllers realize NFC modes
5 /54
From ISO 7816 to ISO 14443
• The basic idea of Wi-Fi design was Wireless Ethernet.
• The basic idea of ISO 14443 design was Wireless (ISO
7816) Smartcard.
– Contrary to IEEE 802.11 there is no security features at
the radio frame level.
V= 2 π fc S µo H
ISO 7816
Contact Mode
ISO 14443
Contactless Mode
H = 5 A/m
fc= 13,56 Mhz
S= 40 10-4
V= 2,2V
6 /54
What is a Secure Element ?
A Secure Element (SE) is a Secure Microcontroller,
equipped with host interfaces such as ISO7816, SPI or I2C .
OS JAVACARD JCOP
GP (Global Platform)
ROM 160 KB
EEPROM 72 KB
RAM 4KB
Crypto-processor
3xDES, AES, RSA, ECC
Certification CC EAL5+
Security Certificates EMVCo
EXAMPLE: NXP PN532
7 /54
NFC and Secure Elements
• Some NFC Controllers embed a Secure Element
– In that case the card emulation mode may be managed by the
embedded secure element
– This is the Google Secure Element Android Model
www.chipworks.com
Reader/writer ISO 14443 –A-B, MIFARE, FeliCa®, NFC Forum tags, ISO 15693
Card Emulation ISO 14443 –A-B-B’,
FeliCa
RF ,june
SWP24, ROMA
Pascal MIFARE,
Urien, SMART
2013,
RAM 5Ko, ROM 128 Ko, EEPROM 52 Ko
8 /54
The SIM card becomes an NFC device:
the Contactless Front-end (CLF)
The ETSI TS 102 613 Standard
A simplified HDLC protocol: SHDLC
A physical Link: Single Wire Protocol (SWP)
9 /54
NFC Reader/Writer
& Card Emulation
OTA(Over The Air)
Administration
SMS, GSM 3.48
SECURE
ELEMENT
NFC
CONTROLER
Secure Element
Administration
NFC
CONTROLER
Reader/Writer
SOFTWARE
Card Emulation
10 /54
NFC P2P Mode Illustration
• Android NDEF Push Protocol Specification
– Version 1, 2011-02-22
– Proprietary protocol, Android 2.3
– Replace by SNEP for Android 4.x
“The NDEF Push Protocol
(NPP) is a simple protocol
built on top of LLCP which is
designed to push an NDEF
message from one device to
Initiator
another.”
Target
11 /54
Using the Google NDEF Push
Protocol (NPP)
NFC Target
NFC Initiator
ATR_REQ, NFC-MAGIC VERSION WKS (Well-Known Service)
LTO (Link-Timeout)
ATR_RES, NFC-MAGIC VERSION WKS (Well-Known Service)
LTO (Link-Timeout)
LLCP-SYMM [0000]
CONNECT [0521 060F 636F6D2E616E64726F69642E6E7070]
DSAP=1, SSAP=33, Service=“com.android.npp”
CC (Connection Complete) [859002020078]
DSAP=33, SSAP=16, MUI (Maximum Information Unit)
Information
[432100 0100000001010000000F D1010B5402656E 6B657976616C7565]
DSAP=16, SSAP=33, N(S)=0, N(R)=0, NPP HEADER, NDEF RECORD, keyvalue
RR(1) [855001], SSAP=16, DSAP=33
DISCONNECT [4161]Pascal
DSAP=16,
Urien,SSAP=33
SMART 2013, june 24, ROMA
12 /54
Smartcard Administration: GP
Issuer
Security
Domain
Other
Security
Domain
KMC-ID (6B)
Other
Application
Mutual Authentication
ISD
The VISA Model*
KMC (DES Master Key for
Personalization Session Keys)
KENC KMAC KDEK
Select ISD
Card
Manager
Global
Platform
API
CSN (Chip Serial
Number, 4B)
Issuer
Application
Runtime
Environment
SKUENC
SKUMAC
SKUDEK
Secure Channel
Application Management
downloading - deletion
Pascal Urien,
SMART
2013,
june 24, ROMA
*EMV Card Personalization Specification
Version
1.1 July
2007
13 /54
The In2Pay Administration Model*
* http://www.devifi.com/assets/whitepaper.pdf
14 /54
The Google Platform
Reader/Writer
Card Emulation
Peer to Peer
Android Beams
NFC Tags
- EMV Magnetic
Stripe Profile
- Cloud Storage
SNEP
15 /54
HID NFC White Paper:
SIM centric Services
Trusted
Service
Manager
- Payment
- Access Control
- Transport
16 /54
About NFC
Specifications
In the NFC Jungle
17 /54
NFC Standards Overview
NDEF
ISO 14443-2A
ISO 14443-3A
14443
-2B
14443
-3B
ISO 14443-2A
ISO 14443-3A
FELICA
SNEP
LLCP
Passive Mode
Active Mode
NFCIP-1
ISO 14443-4
NFCIP-1
*ISO/IEC_18092 standard and NFCIP-1 standards are similar
DEP: Data Exchange Protocol (Supports Read/Write Operations for Tags)
NFCIP-1
18
/54
NFC Radio
ISO 14443
106 kbps
212 kbps
424 kbps
848 kbps
Standard
PCD to ICCC
Reader to Card
PICC to PCD
Card to Reader
ISO 14443-2A
NFC-A
ASK 100%
Modified Miller
Subcarrier fc/16
OOK Manchester
ISO 14443-2B
NFC-B
ASK 10%,
NRZ-L
Subcarrier fc/16
BPSK, NRZ-L
NFCIP-1
Passive
Mode
NFCIP-1
Active
Mode
Bit Rate
Initiator
Target
106 kbps
ASK 100%
Modified Miller
Subcarrier fc/16
OOK Manchester
212-424 kbps
ASK 8-30%
OOK Manchester
ASK 8-30%
OOK Manchester
Bit Rate
Initiator
Target
106 kbps
ASK 100%
Modified Miller
ASK 100%,
Modified Miller
212-424 kbps
ASK 8-30 %
ASK 8-30%,
OOK Manchester
OOK Manchester
Pascal Urien, SMART
2013, june 24, ROMA
19 /54
NFC TAGs
NDEF Format for passive TAG
•
Type 1
–
–
•
Type 2
–
–
–
•
–
Similar to Type1
Based on the Japanese Industrial Standard
(JIS) X 6319-4.
Compatible with Sony Felica
Type 4
–
–
–
•
Similar to Type1
Based on ISO 144413-A
Compatible with NXP MIFARE Ultralight.
Type 3
–
–
•
Innovision Topaz, Broadcom BCM20203
Similar to Type1
Compatible with standard ISO 14433-4
Smartcards
•
•
•
•
LLCP NDEF services
SNEP: Simple NDEF
Exchange Protocol
SNEP Requests and SNEP
Responses
LLC service access point
address 4
Service Name
“urn:nfc:sn:snep”
NXP-specific type tag
–
Mifare Classic
20 /54
LLCP: a Bridge to LAN Technologies
NCPIP-1
21 /54
1=Record
Start
1=Record
End
1=First
Chunk 1= Payload
Length
1= ID Length
Structure
of TYPE Field
1= Well Known
Identifier
describing
the TYPE of
the payload
URI reference
(RFC 3986)
NDEF: NFC Data
Exchange Format
NDEF Record Example:
(NFC Text Record Type Definition)
D1: 1 1 0 1 0 001
01: Type Length
0A: Payload Length
54: Type= ‘T’, Text
02: ID= UTF8
65 6E: “EN”
53 61 6D 70 6C 65 20: "Sample "
A summary of record TYPE may be found in “NFC Tags A technical introduction,
applications and products Rev. 1.3 - 1 December 2011 White paper”, NXP
Semiconductors.
22 /54
Example of Type2 Tag with Mifare
Mifare Ultralight
Type2 Tag
NDEF AID
Mifare Classic
Mifare Application Directory, MAD
Size 48 bytes
Pascal Urien,
SMART
2013,
juneby
24,Android
ROMA Mobiles
Mifare
tags are
read
23 /54
SNEP, Android 4.x
NFC Initiator ATR_REQ, NFC-MAGIC VERSION WKS LTO
ATR_RES, NFC-MAGIC VERSION WKS LTO
LLCP-SYMM [0000]
LLCP-SYMM [0000]
LLCP-SYMM [0000]
NFC Target
CONNECT [1120], DSAP=4, SSAP=32
CC [818402020078], DSAP=32, SSAP=4, MUI
Information , SNEP PUT
[132000 10020000000F D1010B5402656E 6B657976616C7565]
DSAP=4, SSAP=32, NS=0, NR=0, SNEP HEADER, NDEF RECORD, keyvalue
RR(1) [834401], SSAP=4, DSAP=32
Information, SNEP Success [830401 108100000000] ,
SSAP=4, DSAP=32, NS=0, NR=1
RR(1) [13600], DSAP=4, SSAP=32
DISCONNECT [1160] DSAP=4, SSAP=32
DM [C400], DSAP=16, SSAP=32
LLCP-SYMM [0000]
24 /54
NFC In Mobile Phones
25 /54
NFC and Smartphones
• Nokia
– Card Emulation and SWP
– NOKIA 6131
• Android 2.3 (Gingerbread), Android 4.0
– Reader/Writer and P2P
– Nexus S (v2.3) , Galaxy Nexus (v4.0), Galaxy S2(v2.3)
– NXP NFC Controller PN65N
• RIM JDE 7.0.0, Blackberry 10
–
–
–
–
Reader/Writter and Card Emulation
JSR 177 (SIM Access)
Blackberry Bold 9900, 9930
INSIDE SecureRead NFC Controller
• IPHONE
– External NFC Reader
– Rumors for the NFC support
NXP PN65N
26 /54
Hardware and Software Architecture
of the Nexus S Android Phone
ROM
APPLICATIONS
NFC
TELEPHONY
FRAMEWORK
/java/android/
JINI
DALVIK
LIBRAIRIES
NFC RIL
LINUX KERNEL
/dev/nfc /dev/baseband
NFC
CTL
BASE
BAND
Blue
Tooth
WiFi
FLASH
1+15
Go
RAM
512
Mo
GPS
NFC
CTL
CA
ME
RA
ACCE
LERO
METER
SCREEN
MIC
HP
CO
DEC
USB
Application
Processor (1GHz)
+ GPU
Baseband
Processor
COM
PASS
CPU core,
"Hummingbird"
Radio Layer
Interface (RIL)
SIM
Pascal Urien, SMART 2013,
june 24, ROMA
Front End
Module
(FEM)
27 /54
Proprietary Libraries
Hardware Component
Company
Orientation sensor
AKM
Wi-Fi, Bluetooth, GPS
Broadcom
Graphics
Imagination
NFC
NXP
GSM
Samsung
28 /54
RIL
Details
RIL
Daemon
http://www.kandroid.org/online-pdk/guide/telephony.html
Telephony services
(ingoing call, outgoing
calls are managed
through RIL packets
29 /54
2011, Open Mobile API
30 /54
Open Mobile API & Security Policy
• The API defines a generic framework
for the access to Secure Elements in a
mobile environment. It is based on four
main objects.
– The SEService is the abstract
representation of all SEs that are
available for applications running in the
mobile phone.
– The Reader is the logical interface with
a Secure Element. It is an abstraction
from electronics devices which are
needed for contact (ISO 7816) and
contactless (ISO 14443) smartcards.
– The Session is opened and closed with
a Reader. It establishes the logical path
with the SE managed by the Reader.
– The Channel is associated with an
application running in the SE and
identified by an ID (the AID=
Application IDentifier)
• In order to protect the USIM from a
non-authorized Android
application, an access control (AC)
mechanism based on the PKCS#15
standard is used.
– The PKCS#15 repertory (hosted by
the SIM) contains three files
defined for the access rules
– The Access Control Main File (EFACMF) gives a reference to the
Access Control Rules File (EF-ACRF)
– The Access Control Rules File (EFACRF) stores a list of Access Control
Conditions File (EF-ACCF), each of
them being associated to a
particular AID.
– Each Access Control Conditions
File (EF-ACCF), contains a SHA1
digest of the mobile application
whose access to embedded
software running in the Secure
(and identified by its AID)
Pascal Urien, SMART 2013,Element
june 24, ROMA
31 /54
is authorized.
Identity For NFC
32 /54
A NFC Identity Model (NFC-ID)
• SSL/TLS is THE Internet security standard
• A tiny SSL/TLS STACK embedded in a Secure Element
– Javacard 2.x
– WORE! Write Once, Run Everywhere !
– A small memory footprint
• 20 KB for Client only mode
• 25 KB for Client/Server mode
• A transport free from TCP/IP flavors
– Datagram like transport
– Specified by an IETF draft, draft-urien-eap-smartcard
SE
Certificate
CA
Certificate
RSA
Private Key
SSL/TLS Embedded Stack
• Each client has a Certificate
–
–
–
–
Each Secure Element has an Identity (its X509 Certificate)
Strong mutual authentication, between SE and remote server
Establishment of Secure Channels
Optional transfer of SSL/TLS session from SE to terminals (i.e. mobile)
Urien, P., "An OpenID Provider based on SSL Smart Cards", IEEE CCNC 2010.
Urien, P., “Convergent Identity: Seamless OPENID services for 3G dongles using SSL enabled USIM smart cards”, IEEE CCNC 2011
Urien, P. et All, "A breakthrough for prepaid payment: end to end token exchange and management using secure SSL channels created by
EAP-TLS smart cards", IEEE CTS 2011
Urien, P. et All, “A new keying system for RFID lock based on SSL dual interface NFC chips and android mobiles”, IEEE CCNC 2012
33 /54
NFC
SSL/TLS
Exchange
Full Mode
and
Resume
Mode
34 /54
The NFC-ID Lifecycle
Container: Information
protected (i.e.
ciphered) by the SE
public key, and signed
by a trusted entity
SE-ID Secure Element Certificate
End
of Life
User Agent
Application
Server*
IDentity
Provider
(IdP)
SSL/TLS
SSL/TLS
UserID
Application Certificate
*http://www.morpho.com/IMG/pdf/morpho_telecoms_simply_me_2p_gb.pdf
35 /54
Use Case 1 : NFC Keys for the
Internet of Things
36 /54
Dual Interface NFC Device : 3 components
JavaCard Key
Application
TLS Stack
3
MIFARE API
Key Value
2
Secure Microcontroller
1 with NFC resources
equipped with a Java Virtual Machine
NFC Mobile
Mifare
Emulation
Legacy Mifare Lock
37 /54
The CES 2012 Demonstration (30s)
http://www.facebook.com/photo.php?v=3030751173533
CES 2012, Las Vegas
38 /54
Use Case 2
The Emergence of the Cloud Of
Secure Elements (CoSE)
39 /54
About NFC Payments
• Some NFC payments are based on the
MasterCard PayPass specification
• There is two modes
– Mag Stripe, a four digits CVC3 (Card
Verification Value) is computed from a 3xDES
and various parameters (PAN, ATC counter,…)
– Contactless EMV
• The Secure Element securely performs
calculations or runs the EMV application
• Contactless payments introduce a new
paradigm, the virtualization of the bank
card.
• The merchant terminal doesn’t known
where is running the payment application
on the
mobile
side.
®
™,
Where is
running the SE
application ?
* MasterCard PayPass M/Chip, Acquirer Implementation
Requirements, v.1-A4 6/06
40 /54
Some Details with EMV Mag. Stripe*
4 digits
ATC
PAN’
SELECT 2PAY.SYS.DDF01
PAD
(Zero bit)
128b
PAN
SELECT MasterCard
Google Prepaid Card
GET PROCESSING
OPTIONS
READ first record
Left
16 digits PAN (16d)
KeyA
64b
BCD Expiry Date (4d)
Service Code (3d)
ENCRYPT
C
A
64b
xor
KeyA
COMPUTE Cryptographic
Checksum
D
G=A23FB35FC89AE3A9
23358939AFBFCAEA
2335893905152040 CVC3=233
B
KeyA
KeyB
ENCRYPT
Right
64b
DECRYPT
E
Pascal Urien,
SMART2.0.2
2013,July
june
24, ROMA
*Visa Contactless Payment Specification
Version
2006
F
ENCRYPT
G
41 /54
Google Wallet 2
Google
Acquirer
Google
Issuer
Customer’s
Issuer Bank
Card Not Present transaction (CNP)
Card
Network
Acquirer Bank
Customer‘s
Cards
Google
Virtual
prepaid card
Pascal
Urien, SMART 2013, june 24, ROMA
MasterCard
42 /54
About Relay Attack
• In 2005, G.Hancke introduced the
concept of the “Relay Attack”
• The basic idea is that a reader working
with ISO14443 device, reads a fake card
(the proxy) which is connected via radio
to an other device (the mole) working
with a legacy card .
• As a result the reader manages a
session with a remote device
READER
PROXY
ISO 14443
EMULATION
RELAY
MOLE
ISO 14443
READER
proxy
mole
LEGACY
CARD
“A Practical Relay Attack on ISO 14443 Proximity Cards” Gerhard Hancke, 2005
“Keep Your Enemies Close: Distance Bounding Against Smartcard Relay Attacks”, Saar Drimer
and Steven J. Murdoch, 2007
43 /54
Where is located a bank card ?
• In the SIM/USIM
2012 Google fees
Less than $3,000
$3,000 - $9,999.99
$10,000 - $99,999.99
$100,000 or more
– Use SWP for NFC
communication
– MNO model
• In a NFC SecureSD
– Tyfone, DeviceFidelity
• In a NFC Controller
2.9%
2.5%
2.2%
1.9%
+ $0.30
+ $0.30
+ $0.30
+ $0.30
2017 Forecasts
-Mobile Payments 1300 billions $
-NFC payments 200 billions $
– The Google Model
• Somewhere in the Cloud
– GoogleWallet2
– SimplyTapp
– EtherTrust
Mobile
Payment
Market
Pascal Urien, SMART
2013, june
24, ROMA
44 /54
Cloud Of Secure Elements
•
A cloud of secure elements (CSE) comprises the following five elements
– Applications (typically written in javacard) stored in secure elements.
– Grids of secure elements (GoSE). Secure Elements embed Issuer Security Domain, which manage
the lifecycle of applications. Applications may move from a grid to another.
– A Relay-Protocol (RP) enforces security between the GoSE and the NFC proxy, thanks to a secure
channel, such as TLS.
– The NFC Secure Proxy (NSP) controls the session with the NFC reader (or initiator) and the dialog
with the GoSE according to the relay protocol. This software entity should manage a SE located in
the smartphone.
– A NFC reader (or NFC initiator) is used by legacy applications (payment, transport,…); however
future services could work with the P2P mode.
45 /54
Experimental Platform
46 /54
EMV transaction timings, Intranet
Network Cost
<Tcost = Trelay – Tcontact – Treplay> = 51ms
Cache Operation
769 – 60 – 62 + 820 + 560 = 2027 ms
47 /54
Test with EMV magstripe profile
One TCP packet per ISO7816 command (APDU),
RTT 70 ms (Paris – Hanover)
Network Cost (Internet)
<Tcost = Trelay – Tgrid – Treplay>= 83 ms
Paris
Hanover
Trc = Tr0 + L x D
where Tr0 is a fix delay (about 20-40 ms), L is the length of exchanged data, D is the NFC
throughput (104 Kbits/s in our platform, i.e. D= 0,1ms/byte)
Trr= Trc + RTT + Tse,
Where Trc is the time consumed by the NFC proxy , RTT is the round trip time over
internet (ranging between 50ms to 100ms), and Tse is a time consumed by a legacy
secure element for the request (such as 440ms for DDA or 420ms for GenerateAC). 48
/54
Use Case 3
Security for NFC
LLCPS
urn:nfc:sn:tls:snep
49 /54
2012 LLCPS Platform
NDEF
NDEF
NDEF
SNEP
TLS
LLCP
NFCIP-1
NFCController(s)
L
L
C
P
S
SNEP
TLS
LLCP
SNEP
L
L
C
P
S
TLS
LLCP
NFCIP-1
TLS
www.youtube.com/watch?v=CVWHlxoi3eUYou
SIM
50 /54
2013, First Tests With BB 10
http://www.youtube.com/watch?v=CWS41cIZylw
51 /54
LLCPS
• The LLCPS layer manages five exclusive
processes in order to exchange TLS messages.
• The connection process (CP) and the
disconnection process (DP) are in charge of
establishing and releasing LLCP sessions with
the "com.ietf.tls.snep" service.
• The sending process (SP) sends a requested
amount of data according to a simple strategy
that performs segmentation, transmits
INFORMATION PDUs and waits for
acknowledgments (RR).
• The receiving process (RP) waits for a
requested amount of incoming data; the
reception of each incoming INFORMATION
packet is acknowledged by a RR PDU.
• The inactivity process (IP) periodically
generates SYMM symbols which may be
echoed by other processes such as IP, SP or RP.
SYMM generation is a consequence of slow TLS
processing by a secure element, or interaction
between the mobile operating system and its
user
52 /54
SNEP - Simple NDEF Exchange Protocol
& NDEF - NFC Data Exchange Format
• Once a TLS session is
established, SNEP packets
are securely exchanged.
• In our demonstration we
use only SNEP-Put and
SNEP-Success packets.
• A value, i.e. as a key
encoded according to the
NDEF format, is pushed
from the target to the
virtual lock
SNEP Put Packet
10 SNEP Version
02 Put
00 00 00 0E Payload Length
NDEF Record :
(NFC Text Record Type Definition)
D1: 1 1 0 1 0 001
01: Type Length
0A: Payload Length
54: Type= ‘T’, Text
02: ID= UTF8
65 6E: “EN”
53 61 6D 70 6C 65 20: "Sample "
53 /54
Thank You
Questions
54 /54

NFC Technologies For The Internet Of Things

Transcription

Similar documents

Dries Harnie Elisa Gonzalez Boix Lode Hoste Andoni Lombide

Hotlink TEENS 13 – 17 yrs

Wirecard Mobile Payments take up!

ROMA WITH AN EDUCATION, ROMA WITH A FUTURE.

¯ The songs always start with the ritornello, even if by exception they

our faculty hiring brochure

SCP60

Look. Donʼt touch.

Slide 0 - shop.Týden.cz

technology - Tecnoconference Europe