Security issues for the IoT

dealing with Mobile Payments

and Secure Element for Objects

[email protected]
CoFounder of the Ethertrust Company
Venezia, Italy, October 9th 2016
Pascal Urien 1
Part One: Mobile Payments

Pascal Urien 2
Background

Pascal Urien 3
 Smartcard Genesis
• 1980, First BO’ French bank card, from CP8
RAM
• 1988, SIM card specification EEPROM R
• 1990, First ISO7816 standards
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) chip, 1997
Pascal Urien 4
 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 EXAMPLE: NXP PN532
GP (Global Platform)
ROM 160 KB
EEPROM 72 KB
RAM 4KB
Crypto-processor
3xDES, AES, RSA, ECC
Certification CC (Common Criteria) EAL5+
Security Certificates EMVCo

Pascal Urien 5
 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
Pascal Urien 6
 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.
ISO 14443
V= 2 π fc S µo H Contactless Mode
READER
H = 5 A/m
ISO 7816 fc= 13,56 MHz
S= 40.10-4
Contact Mode V= 2,2V
Pascal Urien 7
 About Inductive Coupling

Primary Circuit Secondary Circuit

Neumann formula

Φ1 L1 M i1
=
Φ2 L2 M i2
No energy propagation,
The Energy is conservative, i.e. implies vicinity proof.
The Energy delivered by the primary circuit PPRI = i1 . ( M ω i2 ),
Pascal Urien
is equal to the energy consumed by the secondary circuit PSEC = i2 . ( M ω i1 ). 8
Propagation -d/λ
Po S /4πd2 e
S
d

Po

Pascal Urien 9
Secure Elements Market

Pascal Urien 10
 NFC Standards Overview
NDEF

14443 SNEP
ISO 14443-2A ISO 14443-2A
-2B
ISO 14443-3A ISO 14443-3A
14443 LLCP
FELICA
-3B
NFC-SEC

DEP
Passive Mode
NFCIP-1 ISO 14443-4 NFCIP-1 Active Mode
NFCIP-1
*ISO/IEC_18092 standard and NFCIP-1 standards are similar
DEP: Data Exchange Protocol Pascal Urien 11
SIM-Centric Legacy Paradigm

Pascal Urien 12
HID NFC White Paper: SIM Centric Services
Trusted
Service
Manager

- Payment
- Access Control
- Transport

Pascal Urien 13
Cloud of Secure Elements
• Remote use
of Secure
Elements
hosted in the
cloud
through
secure TLS
channel

Pascal Urien 14
 About TLS Stack for
Secure Element

User’s CA
INTERNET
Certificate Certificate
TLS Sessions
5 mm

RSA Private Key

TLS Stack

CLOUD RESOURCES
JAVA VIRTUAL
MACHINE Get-KeysBlock
Get-CipherSuite

Pascal Urien 15
About Mobile Payments

US payment cards market

2011: 21 trillion $

Pascal Urien 16
 Some Figures
• According to the French national bank ("Banque de France"), the France gross domestic
product (GDP) was about 1900 billion € in 2013.
• The global amount of financial transactions was about 27 000 billion €.
• 1,7% of these operations were performed with bank cards (leading to about 450 billion
€).
• Nine billion of card transactions were performed in 2013, with an average value of 50€.
• The number of payment cards in France was about 86 million, more than the
population.
• In France in 2015
– About 0,025 billion of NFC payment operations
– 10 € in average
– 0,25 billion €
– 0,05 % of payment card transactions

Pascal Urien 17
About the EMV Payment Four Corner
Architecture
ACQUIRER Bank
Merchant Account
Merchant Bank
Payment Processor

Credit Card Network

ISSUER Bank
Card Issuer
CHIP
Payment
terminal
EMV Card
Pascal Urien 18
 A typical EMV transaction comprises
five steps
• 1) Selection of the PPSE (Proximity Payment Systems Environment)
application, which gives the list of embedded payment EMV
applications identified by their AID.
• 2) Selection of an EMV payment application.
• 3) Reading of the application capacities, thanks to the GPO (Get
Processing Options) command, which also returned the structure of
embedded information organized according to a records/files scheme.
• 4) Reading of records and files via the ReadRecord command.
Certificates are checked and a DDA procedure may be used as non
cloning proof.
• 5) Generation of payment cryptograms, triggered by GenerateAC or
CDA commands. Pascal Urien 19
 Legacy EMV
• According to iso7816 standards EMV applications are identified by
AID (Application IDentifier) attributes, 16 bytes at the most.
• An EMV application embeds an index of a certification authority (such
as VISA or MasterCard), an issuer certificate signed by the CA, and an
ICC (integrated circuit card) certificate delivered (and signed) by the
issuer.
• The ICC certificate authenticates most of information stored within
the EMV application (PAN, bearer's name, validity dates...), encoded
according to the ASN.1 syntax.
• An ICC private RSA key is available and used for non cloning proof,
thanks to a dedicated command called DDA (Dynamic Data
Authentication), in which a 32 bits random is encrypted by the ICC
private key.
Pascal Urien 20
 Legacy EMV
• Financial transactions are associated with cryptogam
generation based on symmetric 3xDES cryptographic
algorithm.
• One or two dedicated commands (GenerateAC) are
required by a payment operation, whose input
parameters include, among others, the amount and the
date.
• DDA and GenerateAC may be combined in a single
procedure called CDA (Combined Dynamic
Authentication).
Pascal Urien 21
 EMV ISO7816 main commands
EMV Binary (hexadecimal) Encoding
Iso7816 request CLA INS P1 P2 P3
SELECT AID 00 A4 04 00 P3=AID-length AID
GetProcessingOptions 80 A8 00 00 P3=parameters-length
ReadRecord 00 B2 P1 P2 00
P1=record number
(P2-4)/8 = file number (FSI)
GenerateAC 80 AE P1 00 P3=parameters length
P1= type of cryptogram

Pascal Urien 22
 PayPass Mag Stripe (PMS)
• PMS is an adaptation of EMV standards to magnetic stripe.
• It generates a dynamic Card Validation Code (named CVC3).
• A PayPass transaction comprises the five following operations:
– 1) Selection of the PPSE application.
– 2) Selection of the PayPass application.
– 3) Issuance of the GPO command.
– 4) Reading of the record one, file one, which contains the track1 and track 2
equivalent data
– 5) Issuance of the Compute Cryptographic Checksum (CCC) iso7816 request,
including an unpredictable number. The PayPass application returns the CVC3
value.
• Contrary to EMV the PMS profile does not embed certificates or RSA private
key. Thanks to CVC3 it is compatible with legacy magnetic card networks.
Pascal Urien 23
 Customer’s
Google Card Not Present transaction (CNP) Issuer Bank
Acquirer

Google Card
Issuer Network
Customer‘s Acquirer’s Bank
Cards
The
Google Google
Virtual
Cloud of PVC
prepaid
card
Wallet 2
Bank Cards
MasterCard (2012)
Pascal Urien 24
 Google PrePaid Card Transaction
// SELECT 2PAY.SYS.DDF01
>> 00A404000E325041592E5359532E4444463031
<< 6F2C840E325041592E5359532E4444463031A51ABF0C1761154F10A000000004
1010AA54303200FF01FFFF8701019000

6F File Control Information (FCI) Template

84 Dedicated File (DF) Name
325041592E5359532E4444463031
A5 File Control Information (FCI) Proprietary Template
BF0C File Control Information (FCI) Issuer Discretionary Data
61 Application Template
4F Application Identifier (AID) – card
A0000000041010AA54303200FF01FFFF
87 Application Priority Indicator
01

Pascal Urien 25
 Google PrePaid Card Transaction
// Select MasterCard Google Prepaid Card
>> 00A4040010A0000000041010AA54303200FF01FFFF
<<
6F208410A0000000041010AA54303200FF01FFFFA50C500A4D617374657243617
2649000

6F File Control Information (FCI) Template

84 Dedicated File (DF) Name
A0000000041010AA54303200FF01FFFF
A5 File Control Information (FCI) Proprietary Template
50 Application Label
MasterCard

Pascal Urien 26
// Get Processing Options
>> 80A80000028300
<< 770A 8202 0000 9404 08010100 9 000
Google PrePaid
AIP=0000 AFI= 08010100
Card Transaction
// Reader Record one File one Track 1 data
>> 00B2010C00
<< 706A9F6C0200019F62060000000000389F63060000000003C64 5629 235343330
3939393930393937393939395E202F5E31373131313031303031303030303030
303030309F6401049F650200389F660203C6 9F6B13 5430 999909979999 D 1711 1
01 0010000000000F 9F670104 9000 Track 2 data PAN= 999909979999
Validity Date= 1711
// COMPUTE Cryptographic Checksum (CVC3)
>> 802A8E8004 00000080
<< 770F9F6102 0038 9F6002 0038 9F3602 0012 9000
CVC3 Track 2 CVC3 Track 1 Pascal ATC
Urien 27
 VISA MSD
• VISA VCPS (Visa Contactless Payment Specification) MSD (Magnetic Stripe Data),
is an adaptation of EMV standards to magnetic stripe for contactless payments.
• It generates a dynamic Card Verification Value (dCVV, a three digits code) based
on a 3xDES (112 bits) secret key.
• A VISA MSD transaction comprises the four following operations:
– 1) Selection of the PPSE application.
– 2) Selection of the VISA MSD application.
– 3) Sending of the GPO command with payment attributes (amount, date...).
– 4) Reading of the record one, file one, which contains the track 2 equivalent data.
This file includes a dCVV computed after the previous GPO.
• Contrary to EMV the VISA MSD profile does not embedded certificate or RSA
private key. Thanks to dCVV it is compatible with legacy magnetic card networks.

Pascal Urien 28
 Apple Pay
Select PPSE
00A404000E 325041592E5359532E4444463031
6F 23 […] 9000
6F File Control Information (FCI) Template
84 Dedicated File (DF) Name
325041592E5359532E4444463031
A5 File Control Information (FCI) Proprietary Template
BF0C File Control Information (FCI) Issuer Discretionary Data
61 Application Template
4F Application Identifier (AID) – card
A0000000031010
87 Application Priority Indicator
01

Pascal Urien 29
 Apple Pay
Select VISA MSD
00A4040007 A0000000031010
6F 39 […] 9000
6F File Control Information (FCI) Template
84 Dedicated File (DF) Name
A0000000031010
A5 File Control Information (FCI) Proprietary Template
9F38 Processing Options Data Object List (PDOL)
9F6604 9F0206 9F0306 9F1A02 9505 5F2A02 9A03 9C01 9F3704 9F4E14
BF0C File Control Information (FCI) Issuer Discretionary Data
9F4D Log Entry
1401
9F5A Unknown tag
1108400840

Pascal Urien 30
 Apple Pay
GPO
80 A8 00 00 37 83 35 [...]
83 35
86 00 00 80
00 00 00 00 00 01
00 00 00 00 00 00
04 80
00 00 00 00 00
04 80
14 08 18
01
4A 94 57 1A
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

80 06 00 80 08 01 01 00 9000
AIP = 0080 , MSD mode
AFL = 08010100, one record one file

Pascal Urien 31
 Apple Pay
//Read Record 1 file 1
00 B2 01 0C 00

701A 57 13 40 71 23 13 11 22 33 44 D2 00 32 01 00 00 05 09 00 02 5F 5F 20
02 20 2F 90 00

70 EMV Proprietary Template

57 Track 2 Equivalent Data
DAN dCVV
407123131122334 4D 2003 201 0 0000 509 00025 F
5F20 Cardholder Name
/

Pascal Urien 32
//Select PPSE
00A404000E325041592E5359532E444446303100 EMV
6F23840E325041592E5359532E4444463031A511BF0C0E610C4F07A00000000
410108701019000

6F File Control Information (FCI) Template

84 Dedicated File (DF) Name
325041592E5359532E4444463031
A5 File Control Information (FCI) Proprietary Template
BF0C File Control Information (FCI) Issuer Discretionary Data
61 Application Template
4F Application Identifier (AID) – card
A0000000041010
87 Application Priority Indicator
01
Pascal Urien 33
 EMV
// Select Master Card
>> 00A4040007A000000004101000
<< 6F388407A0000000041010A52D500A4D6173746572436172648701015F2D0266
729F1101019F120A4D617374657263617264BF0C059F4D020B0A9000

Pascal Urien 34
6F File Control Information (FCI) Template
84 Dedicated File (DF) Name EMV
A0000000041010
A5 File Control Information (FCI) Proprietary Template
50 Application Label
MasterCard
87 Application Priority Indicator
01
5F2D Language Preference
fr
9F11 Issuer Code Table Index
01
9F12 Application Preferred Name
Mastercard
BF0C File Control Information (FCI) Issuer Discretionary Data
9F4D Log Entry
0B0A
Pascal Urien 35
GPO
80A8000002830000
7716 8202 1980 9410 08010100100101011801020020010100 9000 EMV
77 Response Message Template Format 2
82 Application Interchange Profile
94 Application File Locator (AFL)

82 (AIP - Application Interchange Profile)

1000 (Byte 1 Bit 5) Cardholder verification is supported
0800 (Byte 1 Bit 4) Terminal risk management is to be performed
0100 (Byte 1 Bit 1) CDA supported
0080 (Byte 2 Bit 8) EMV and Magstripe Modes Supported

94 (AFL - Application File Locator)

List of records that should be read by the terminal.
Each record is identified by the pair (SFI - short file indicator, record number)
SFI 1 record 1, SFI 2 record 1, SFIPascal
3 records
Urien 1-2, SFI 4 record 1 36
P1=record number, (P2-4)/8 = file number (SFI) EMV
// read record 1, file 1
00 B2 01 0C 00
Records
// read record 1, file 2 and Files
00 B2 01 14 00

// read record 1, file 3

Reading
00 B2 01 1C 00

// Read record 2, file 1

00 B2 02 1C 00

// Read record 1 file 4

00 B2 01 24 00
Pascal Urien 37
EMV Certificate Chain

Pascal Urien 38
// P1= Generate TC (01xx) + CDA signature Request (xxx1)= 50
80AE50002B 0000000006290 000000000000 250 0000000000 0978 150610 00 90B4
E0D2 25 0000 0000000000000000 1F0302 00

000000000690 Amount
000000000000 Cashback
250 Country Code
EMV
0000000000 Terminal Verfication Result
0978 Currency code
150610 Transaction Date
00 Transaction Type
90B4E0D2 Unpredictable Number
25 Terminal type
0000 Data Authentication Code
0000000000000000 ICC Dynamic Number
1F0302 Cardholder Verification Method
00 LE

//CDOL1 tag 8C
9F0206 9F0306 9F1A02 9505 5F2A02 9A03Pascal
9C01 9F3704 9F3501 9F4502 9F4C08 9F3403
Urien 39
7781 91

9F27 01 80 Cryptogram Information Data

EMV
9F36 02 001F Application Transaction Counter
9F4B 70 Signed Dynamic Application Data
9E92DE44738A7C5533D5E29A7A6D230A
CDA
0E2123F3EE1DCD83C868551D4F01C1D2
4979BBAA978F95589731C1CA73DA77DD
80E3B49D7B0CEA3B4CFE711D021DA8F9
4BE408C44EF614EB5F150FDDFE6DA8C8
920E041F8401E3DE0D313EB15DC7C6C9
DCD0279F4EF450D39F8CA12361065124

9F10 12 Issuer Application Data (optionnal)

0F10
A04003223000000000000000000000FF

9000 Pascal Urien 40

6a
05
01
Signed Data Format
Hash Algorithm Indicator
EMV
26
08
ICC Dynamic Data Length (LDD)
ICC Dynamic Number Length CDA
a1 bb 29 ce d6 89 95 7c ICC Dynamic Number
80 Cryptogram Information Data
ec e9 3c d4 a0 80 34 c8 TC

09 a1 86 bd eb 56 60 ba 15 b2 b2 8d 9f 1c b2 e4 74 a6 8d 8c
Transaction Data Hash Code

bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb Padding

154fb6d9d774f5e6f7eef512b557eaf754c9c8f3bc Signature

Pascal Urien 41
signature= 154fb6d9d774f5e6f7eef512b557eaf754c9c8f3bc =sha1 EMV
{ 05012608a1bb29ced689957c80
|| ece93cd4a08034c8
|| 09a186bdeb5660ba15b2b28d9f1cb2e474a68d8c
CDA
|| 49 x bb (49 = 0x70 - 0x26 - 25)
|| 90B4E0D2 } // Unpredictable Number

Transaction Data Hash code = hash of

-The values of the data elements specified by, and in the order they appear in
the PDOL, and sent by the terminal in the GET PROCESSING OPTIONS
command
- The values of the data elements specified by, and in the order they appear in
the CDOL1, and sent by the terminal in the first GENERATE AC command.
- The tags, lengths, and values of the data elements returned by the ICC in the
response to the GENERATE AC command in the order they are returned, with
the exception of the Signed DynamicPascal
Application
Urien Data. 42
 EMV
CDA
Transaction Data Hash code= sha1 (
0000000006290000000000000250000000000009781506100090B4E0D2220000000
00000000000001F0302
|| 9F27 01 80
|| 9F36 02 001F
|| 9F10 12 0F10A04003223000000000000000000000FF )
= 09 a1 86 bd eb 56 60 ba 15 b2 b2 8d 9f 1c b2 e4 74 a6 8d 8c

Pascal Urien 43
The SIMulation Project

Pascal Urien 44
Pascal Urien 45
 Scope
• Remote use of Secure Elements hosted in the
Cloud through secure TLS channel
RACS
NFC TLS
HCE
TCP
IP

Pascal Urien 46
 Architecture
• Four Components
– Legacy payment terminal
– Android Mobile
• Host Card Emulation
• Mobile API for SIM interface
– SIM card
• Delivering a TLS stack
– Payment servers
• Built over RACS server and legacy payment card
Pascal Urien 47
 RACS
seid
racs.com:port

seid
TLS-SE

connect
HCE VirtualCard API CLOUD
(AID)

APP init
HCE-SIM Mobile API

set tls.cap (javacard)

racs.com:port MobileAPI files
Config seid
Pascal Urien 48
 RACS
• The idea is to put secure elements in the Cloud
• RACS works over TLS
• Splitting between Access Control (authorization) and Services
– The risks (Fraud…) are managed in two separate plans (access and
service)
– Remote resources are monitored
• Giving an identifier to a secure element in the cloud
– A WEB of Secure Elements
– RACS://Server.com:Port/SEID

Pascal Urien 49
 Introducing RACS
• The RACS protocol is in the perspective of
these former experiments.
• It has been designed for efficient and
secure remote use of secure elements via ISO7816
the internet. APDU

• It also provides smartcard readers TLS

virtualization, and therefore facilitates TCP

secure elements deployment in IP
environments dealing with virtual
machines and cloud computing.

Pascal Urien 50
 RACS Uniform Resource Identifier
• RACS setups a secure (TLS) connection with a remote server, it
collects the list of hosted secure elements, and thereafter it powers
on a secure element, resets the device and exchanges APDU
requests and responses.
• RACS defines an URI (Uniform Resource Identifier), such as
• ServerName:Port/SEID
• It comprises the server name or IP address, the TCP port and a SE
identifier (the SEID).
• Therefore it creates a concept somewhat similar to a WEB of secure
elements, or a WEB of cryptographic procedures.

Pascal Urien 51
 A PKI Infrastructure
• In order to perform strong mutual authentication both
RACS client and server are equipped with X509
certificates, dealing with asymmetric cryptography
(RSA or elliptic curves).
• The client SUBJECT attribute, more precisely the
Common Name (CN) field of this attribute identifies a
legitimate client, and is associated within the server to
an index UID, the user identifier.

Pascal Urien 52
Key Diversification Data
How to
allocate
SEID
Reader Serial Number

SIM-Server SlotID 725

Pascal Urien 53
 RACS Commands
Command SEID Comment
BEGIN no First request command
END no Last Request command
GET-VERSION no Return current version
SET-VERSION no Set current version
ECHO no Request the server to perform an echo

LIST no Return the list of authorized secure

elements
SHUTDOWN yes Shutdown a secure element
POWERON yes Power on a secure element
RESET yes Reset a secure element
APDU yes Perform an ISO7816 request
Pascal Urien 54
RACS Requests and Responses

LIST
SEID
RESET POWERON
SHUTDOWN
APDU IO

Pascal Urien 55
 APDU
Command
• No Script !

Pascal Urien 56
 Security Policy
• Only users equipped with valid certificates successfully establish TLS
sessions.
• A user identifier (UID) is derived from the certificate Common Name (CN)
attribute.
• A TLS session is identified by a unique identifier (the SID).
• Every secure element has two states, unlocked and locked.
– The SHUTDOWN command forces the unlocked state; the POWERON
command switches the SE state from locked to unlocked.
– In the locked state the SE may be only used by the SID that previously locked
it.
• At the end of a TLS session all used SEs are unpowered and unlocked.

Pascal Urien 57
 SEID Locking
Unlocked Locked(SID)
Power Off Power On
POWERON(SID) POWERON
(Other-SID)
SHUTDOWN(All-SID)
DENIED
END Of TLS SESSION(SID)

Pascal Urien 58
 Access Control
• The server manages two kinds of table:
– The Users-Table stores for each CN a list of
authorized SEIDs.
– Each SEID is linked to a SEID-Table storing for
every AID (embedded application) a list of
authorized CNs.

Pascal Urien 59
 uid
UID, SID, AID, Filter
TLS

sid sid
POWERON

seid seid
SELECT

aid aid

Filter
Pascal Urien
Filter 60
 Experimental
Platform

Pascal Urien 61
 SEID files

Reader.txt file ReaderSN.txt file

ATR.txt File

CardSN.txt File
Pascal Urien 62
Access Control Files

Users.txt file

SEID.txt file

Filter.txt file
Pascal Urien 63
•
The Open MobileAPI
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.
• SEService seService = new SEService(this,this)
• public void serviceConnected(SEService service)
• seService.shutdown()
• 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.
• Reader[] readers = seService.getReaders()
• The Session is opened and closed with a Reader. It establishes the logical path with the SE managed by
the Reader.
• Session session = readers[0].openSession()
• session.close() or readers[0].closeSessions()
• The Channel is associated with an application running in the SE and identified by an ID (the AID=
Application IDentifier)
• Channel channel = session.openLogicalChannel(aid)
• byte[] response channel.transmit(byte[] command)
• channel.close()
Pascal Urien 64
OpenMobileAPI: The SIM File System
MF (3F00)
|-EF-DIR (2F00) --> reference to DF-PKCS#15
|
|-DF-PKCS Access Control Main File #15 (7F50)
|-ODF (5031) --> reference to DODF
|-DODF (5207) --> reference to EF-ACMain
|-EF-ACMain (4200) --> reference to EF-ACRules
|-EF-ACRules (4300) --> reference to EF-ACConditions
|-EF-ACConditions1 (4310)
|-EF-ACConditions2 (4311)
|-EF-ACConditions3 (4312)

Pascal Urien 65
 EF-ACRules
30 10
A0 08 // aid
04 06
A0 00 00 01 51 01 // Application Identifier (AID)
30 04
04 02
43 10 // EF-ACCondition File
30 10 A0 08 04 06 A0 00 00 01 51 02 30 04 04 02 43 11
30 10 A0 08 04 06 A0 00 00 01 51 03 30 04 04 02 43 11
30 08
82 00 // other
30 04
04 02
43 12 // file
FF FF FF 90 00

Pascal Urien 66
 No access to any application
Tx: 00 A4 00 04 02 43 10 // Select AC-Conditions1
Rx: 61 20
Tx: 00 C0 00 00 12
Rx: 62 1E 82 02 41 21 83 02 43 10 A5 06 C0 01 00 DE 01 00 61 0E
Tx: 00 B0 00 00 00 // Read AC-Conditions1 - empty file, no access to any application
Rx: 6C 1E
Tx: 00 B0 00 00 1E
Rx: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF 90 00

Pascal Urien 67
 Access to a single application
Tx: 00 A4 00 04 02 43 11 // Select AC-Conditions2
Rx: 61 20
Tx: 00 C0 00 00 20
Rx: 62 1E 82 02 41 21 83 02 43 11 A5 06 C0 01 00 DE 01 00 8A 01
05 8B 03 6F 06 02 80 02 00 1E 88 00 90 00
Tx: 00 B0 00 00 00 // Read AC-Conditions2,
Rx: 6C 1E
Tx: 00 B0 00 00 1E
Rx: 30 16
04 14
11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11
// CertHash
FF FF FF FF FF FF 90 00 Pascal Urien 68
 Access by any application
Tx: 00 A4 00 04 02 43 12 // Select AC-Conditions3
Rx: 61 20
Tx: 00 C0 00 00 20
Rx: 62 1E 82 02 41 21 83 02 43 12 A5 06 C0 01 00 DE 01 00 8A 01 05 8B
03 6F 06 02 80 02 00 1E 88 00 90 00
Tx: 00 B0 00 00 00 // Read AC-Conditions3, access by any application
Rx: 6C 1E
Tx: 00 B0 00 00 1E
Rx: 30 00 // empty condition entry,
FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF
90 00 Pascal Urien 69
 Host Card Emulation

LEGACY Google Nexus S

Host Card Emulation

Pascal Urien 70
 HCE Service
<service
android:name=".MyHostApduService"
android:exported="true"
android:permission="android.permission.BIND_NFC_SERVICE" >
<intent-filter>
<action android:name="android.nfc.cardemulation.action.HOST_APDU_SERVICE" />
</intent-filter>
<meta-data
android:name="android.nfc.cardemulation.host_apdu_service"
android:resource="@xml/apduservice" />
</service>

Pascal Urien 71
 HCE Service
<host-apdu-service
xmlns:android= "http://schemas.android.com/apk/res/android"
android:description="@string/servicedesc"
android:requireDeviceUnlock="false" >
<aid-group
android:category="other"
android:description="@string/aiddescription" >
<aid-filter android:name= "325041592E5359532E4444463031" />
<aid-filter android:name= "a0000000041010aa54303200ff01ffff" />
</aid-group>
</host-apdu-service>

The HCE service implements two methods for NFC communication:

- public byte[] processCommandApdu(byte[] apdu, Bundle extras).
- public void sendResponseApdu(byte[] responseAPDU).

Pascal Urien 72
 User’s Experience
Selection of Connection Ready for Fidelity Card Payment
a bank card to server payment Reading Transaction

Pascal Urien 73
 About Virtual Fidelity Cards
• A virtual fidelity card is associated
with an application AID registered
with the payment application.
• The merchant terminal selects
this virtual card (via the dedicated
iso7816 SELECT command) before
the transaction.
• The returned information
includes a card number to which
the payment would be bound.

Pascal Urien 74
 Legacy Timing
• A legacy contactless transaction consumes about 400ms,
and requires 8 ISO7816 requests, which are detailed below:
– Selection of the PPSE application.
– Selection of the NFC payment application.
– Issuance of the GPO command.
– Four ReadRecord commands used for collecting four files
located in two records.
– One GenerateAC request, realizing a CDA operation.
• About 50% of the transaction time (200 ms) is consumed by
the CDA computing.
Pascal Urien 75
 TERMINAL RACS Script
Transparent Remote
Processing
Mode APDU
BEGIN APDUScript
APDU
END

RACS Server

RACS Script
executed BEGIN ResetScript
after the SHUTDOWN SEID
connection POWERON SEID
to the server END
Pascal Urien SEID 76
 Transparent Mode
• In the transparent mode every iso7816
request is forwarded to the server
• What leads to an extra time cost of about
250ms (in average) per APDU
• Total duration is about 8x250+400= 2400ms.

Pascal Urien 77
TERMINAL RACS Script executed
SELECT PPSE
for cryptographic
SELECT AID Local (CDA) computing
GPO Processing
READ-RECORD(s) BEGIN CdaScript
APDU [GPO]
GENERATE-AC APDU [GENERATE-AC]
END
Cache
RACS Server
Mode
RACS Script BEGIN ResetScript
executed SHUTDOWN SEID
after the POWERON SEID
connection SELECT SEID AID
to the server ENDPascal Urien SEID 78
 Cache Mode
• The mobile application manages a cache; the seven first iso7816 requests,
which return static information, are locally processed by the smartphone.
• Each operation needs about 30ms; therefore seven APDUs cost 210ms,
which is nearly equivalent to the legacy transaction.
• The last request (GenerateAC) is forwarded to the remote server, which
implies a delay ranging between 350 and 650 ms, according to the
following repartition:
– 200 ms are burnt by the remote CDA operation
– 100-250 ms are spent by the platform components (mobile phone, server
operating system and network components)
– 50-200 ms are consumed by the latency of 3G/4G cellular network.
• Total: 560-860ms

Pascal Urien 79
Part II – Secure Elements For
Object

Pascal Urien 80
 About the Internet of Things (IoT)
• Pretz, K. (2013). “The Next Evolution of the
Internet”

The Internet of Things (IoT) is a

network of connected things.

Pascal Urien 81
 Beyond The Horizon
• The IoT is the death of the Moore Law.
• Waldrop M. "More Than Moore", Nature February 2016
Vol 530
– The semiconductor industry will soon abandon its pursuit of
Moore’s Law.
• "Rebooting the IT Revolution: A Call to Action" (SIA/SRC),
2015
– "Security is projected to become an even bigger challenge in the
future as the number of interconnected devices increases... In
fact, the Internet of Things can be viewed as the largest and
most poorly defended cyber attack surface conceived by
mankind"
Pascal Urien 82
 *W= ½ Nq x V
Trillion Sensors q = 1,6 10-19
10-14 J == 125,000 electrons

• In current mainstream systems, the lower-edge

system-level energy per one bit *transition is ~10-14
J, which is referred as the "benchmark".

Towards
Cyber
Physical
Systems
(CPS)

Pascal Urien 83
 Internet Of Things
JSON (JavaScript Object Notation) Communication
is a lightweight, text-based, Stack
language-independent data
interchange format
JSON Schema
JSON Data Interchange Format
REST protocol
Application
Framework Electronics
Operating
System Board
Pascal Urien 84
EXAMPLE 1: NEST
Pascal Urien 85
 https://www.threadgroup.org
DTLS + J-PAKE
Authentification

J-PAKE is a password-
authenticated key exchange
(PAKE) with “juggling” (hence
the “J”).
It essentially uses elliptic
curve Diffie-Hellmann for key
agreement and Schnorr
signatures as a NIZK (Non-
Interactive Zero-Knowledge)
proof mechanism
Pascal Urien 86
Pascal Urien 87
 6LoWPAN deals with IPv6 and
Mesh networks
IEEE 802.15.4
MAC Frame Size 127 Bytes
IpV6 header 40 Bytes
TCP header 20 Bytes

Pascal Urien 88
•
IEEE 802.15.4
Coordinator is assumed to be the Trust Center (TC) and
provides
– Cryptographic key establishment
– Key transport
– Frame protection
– Device management
• Cryptographic Keys
– Master , basis for long term security used for symmetric
key establishment. It is used to keep confidential the Link
Keys exchange between two nodes in the Key
Establishment Procedure (SKKE).
– Link, shared exclusively between two network peers for
Unicast communication.
– Network, used for broadcast communication security.
Pascal Urien 89
THREAD BOARD

http://www.silabs.com/

Pascal Urien 90
Example 2: Open Connectivity
Foundation (OCF)

Pascal Urien 91
 https://openconnectivity.org/
The Open Connectivity Foundation
(OCF) is creating a specification
and sponsoring an open source project to
make this possible.
The OCF sponsors the IoTivity open
source project which includes a reference
implementation of our specification
available under the Apache 2.0 license.

Create, Read, Update, Delete, Notify: CRUDN

Open Interconnect Consortium (OIC) Pascal Urien 92
IOTIVITY
https://www.iotivity.org/
Unified Block (UB) stack Thin Block (TB) stack

IoTivity is an open source software framework enabling seamless device-to-

device connectivity to address the emerging needs of the Internet of Things.
It supports multiple operating systems : Linux, Android, Tize, Arduino
Pascal Urien 93
Smartphone Bulb Interaction

Pascal Urien 94
 CoAP /HTTP

rt: Resource Type ID

if: Interface
Pascal Urien 95
Access Control List (ACL)

Pascal Urien 96
Secure Storage
It is strongly recommended that IoT device makers provide reasonable
protection for Sensitive Data so that it cannot be accessed by unauthorized
devices, groups or individuals for either malicious or benign purposes.
In addition, since Sensitive Data is often used for authentication and
encryption, it must maintain its integrity against intentional or accidental
alteration
Device Authentication with DTLS
Device Authentication with Symmetric Key Credentials
Device Authentication with Raw Asymmetric Key Credentials
Device Authentication with Certificates

Secure Boot
In order to ensure that all components of a device are operating properly and
have not been tampered with, it is best to ensure that the device is booted
properly. There may be multiple stages of boot. The end result is an
application running on top an operating system that takes advantage of
Pascal Urien
memory, CPU and peripherals through drivers. 97
IPv4/IPv6 Issue

Pascal Urien 98
Example 3. MBED

Pascal Urien 99
MBED stack from the ARM company

Pascal Urien 100

 IoT Protocols
• HTTP (most of today IP objects)
– As an illustration some connected plugs work with the
HNAP (Home Network Administration Protocol) protocol
based on SOAP and used in CISCO routers. In 2014 HNAP
was infected by" The Moon".
• MQTT protocol, is a Client Server publish/subscribe
messaging transport protocol that is secured by
TLS.
Pascal Urien 101
 CoAP, RFC 7252
• CoAP ( Constrained Application Protocol) , RFC 7252 is designed according to
the Representational State Transfer (REST) architecture , which encompasses
the following six features:
– 1) Client-Server architecture;
– 2) Stateless interaction;
– 3) Cache operation on the client side;
– 4) Uniform interface ;
– 5) Layered system ;
– 6) Code On Demand.
• CoAP is an efficient RESTfull protocol easy to proxy to/from HTTP, but which is
not understood in an IoT context as a general replacement of HTTP.
– It is natively secured by DTLS (the datagram adaptation of TLS), and works over a
DTLS/UDP/IP stack. Nerveless the IETF is currently working on a CoAP version
compatible with a TLS/TCP/IP stack.
Pascal Urien 102
 CoAP
Details
Version (V): protocol version (01).
Type (T) message type :
Confirmable (CON), Non-confirmable (NON), Acknowledgement (ACK) or Reset.
Token Length (TKL)/ is the length of the Token field (0-8 bytes).
The Code field: identifies the method and is split in two parts a 3-bit class and a 5-bit detail
documented as "c.dd" where "c" is a digit from 0 to 7 and "dd" are two digits from 00 to 31.
0.01 GET, 0.02 POST, 0.03 PUT and 0.04 DELETE.
Message ID: matches messages ACK/Reset to messages CON/NON previously sent.
The Token (0 to 8 bytes): is used to match a response with a request.
Options: give additional information such as Content-Format dealing with proxy operations.
Pascal Urien 103
 LWM2M

• LWM2M (Lightweight Machine to Machine Technical Specification) is a framework based on CoAP dealing with
objects hosted by LWM2M clients and communicating with LWM2M servers
• LWM2M manages the following interfaces
– Bootstrap
– Client Registration (with servers)
– Device management
– Information Reporting
• Two transport mechainsm ("transport channel bindings“)
– UDP/IP
– SMS
Pascal Urien 104
Example 4. Home Kit

Pascal Urien 105

HOME Kit (Apple)
Protocol Security
- End-to-end encryption
- Initial setup secured directly
between iOS and accessory
- Perfect forward secrecy
- Standard cryptography

The HAP (HomeKit

Accessory Protocol) initial
pairing exchange is based on
the Secure Remote Password
procedure (SRP, RFC 5054)
which deals with a 8 digits PIN
code available for every
Pascal Urien
accessory. 106
Example 5. Brillo & Weave

Pascal Urien 107

 Brillo & Weave
Brillo is an OS from
Google for building
connected devices.
35MB Memory
Footprint (minimum)

The Intel® Edison Board Made for Brillo.

Weave is a communications protocol that

supports discovery, provisioning, and
authentication so that devices can connect
and interact with one another, the Internet,
and your mobile platforms. Pascal Urien 108
 Brillo and Weave
Weave is a communications platform for
IoT devices Brillo is Simpler… Smaller…IoT
- Device setup, phone-to-device-to-cloud Focused
communication - C/C++ environment
- User interaction from mobile devices and - Binder IPC No Java
the web Applications, framework, runtime
- Transports: 802.15.4 (zigbee, threads), -No Graphics
BLE, WiFi, Ethernet, Others possible - 35MB Memory Footprint
- Schema Driven (json) Associates Weave (minimum)
XMPP requests with application function
invocations
- Web apps may be written with Google*
API support
- OAuth 2.0 Authentication, Google as AS
Pascal Urien 109
Client Server
Client Hello (Client Random)

Server Hello (Server Random, SessionID)

Flight1

Client
About TLS
Server
Server CA
KPubS KPubCA Client Hello (ClientRandom, SessionID) Flight1
*Certificate
Flight2
Certificate Request
Server Hello (ServerRandom, SessionID)
ServerHelloDone
ChangeCipherSpec
Flight2
Client Encrypted Server Finished Message
*Certificate KPubC

ClientKeyExchange {PreMasterSecret}KPubS Encrypted Client Finished Message

Flight3 Flight3
*CertificateVerify {MessagesDigest} KPrivC ChangeCipherSpec

ChangeCipherSpec
Encrypted and HMACed RECORD
Encrypted Client Finished Message
Encrypted And HMACed RECORD
ChangeCipherSpec

Flight4
Encrypted Server Finished Message

Encrypted and HMACed RECORD

Encrypted and HMACed RECORD

Pascal Urien 110

TLS/DTLS Security Modules

Pascal Urien 111

 About DTLS
The two first number
are respectively the
record sequence
number and the epoch
field.

The optional third

number is the message
sequence used by a
handshake message.
Pascal Urien 112
Handshake cryptographic calculations are insensitive to
DTLS
fragmentation operations.
cryptographic
According to finished messages (either client or server) have no
sensitivity to fragmentation. There are computed as if each details
handshake message had been sent as a single fragment, i.e.
with Fragment-Length set to Length, and Fragment-Offset set to
zero ; the Message-Sequence field is not used in these
procedures.

It also should be noticed that the DTLS-HelloVerifyRequest

message and the previous associated DTLS-ClientHello are not
taken into account by the Handshake cryptographic
calculation.

Pascal Urien 113

DTLS Handshake and Record Layer

Pascal Urien 114

 Client Server
EAP-Request-Identity
About EAP-Response-Identity

EAP- EAP-Request-EAP-TLS, Flags-Start

EAP-Response-EAP-TLS, Flags, TLS Flight1
TLS EAP-Request-EAP-TLS, Flags, TLS Flight2
EAP-Response-EAP-TLS, Flags, TLS Flight3
TLS
EAP-Request-EAP-TLS, Flags, TLS Flight4 Exchanges

EAP-Response-EAP-TLS, Flags

EAP-Success
Pascal Urien 115
 EAP-TLS Flags Field
Segmentation Reassembly Procedures

- The L bit (length included) is set to indicate the presence of the four-
octet TLS flight length field, and is set for the first fragment of a
fragmented TLS message or set of messages.
- The M bit (more fragments) is set on all but the last fragment.
- The S bit (EAP-TLS start) is set inPascal
anUrien
EAP-TLS Start message. 116
 Client Server

EAP-Request-EAP-TLS, Flags-Start
EAP-Response-EAP-TLS, Flags, DTLS Flight1
EAP-DTLS EAP-Request-EAP-TLS, Flags, DTLS Flight2
EAP-Response-EAP-TLS, Flags, DTLS Flight3

EAP-Request-EAP-TLS, Flags, DTLS Flight4 DTLS

Exchanges
EAP-Response-EAP-TLS, Flags, DTLS Flight5
EAP-Request-EAP-TLS, Flags, DTLS Flight6

EAP-Response-EAP-TLS, Flags

EAP-Success
Pascal Urien 117
 Client Server

Encryption EAP-Request-EAP-TLS, Flags, Application data

EAP-Response-EAP-TLS, Flags, Record Packet

Decryption EAP-Request-EAP-TLS, Flags, Record Packet

EAP-Response-EAP-TLS, Flags, Application data

Pascal Urien 118

 About Secure Elements
• Secure Elements are tamper resistant
microcontrollers, whose security is enforced by
multiple hardware and software countermeasures.
• Their security level is ranked by evaluations
performed according to the Common Criteria
standards, whose level range from one to seven.
• The chip area is typically 25mm2 (5mm x 5mm). The
power consumption is low , as an illustration for SIM
module 1.8V-0,2 mA (3.6mw) in idle state and no
more than 1.8V-60mA (108 mW) in pike activity. 119
Pascal Urien
 About Secure Elements
• Secure microcontrollers comprise a few hundred KB of ROM,
about one hundred KB of non volatile memory (E2PROM, Flash)
and a few KB of RAM.
• Most of them include a Java Virtual Machine and therefore run
applications written in the Javacard language, a subset of the
java language.
• A TLS/DTLS stack is an application, typically a javacard
application, stored and executed in a secure element. Its logical
interface is a set of APDUs exchanged over the IO link.
• We previously designed EAP-TLS smartcards, which compute
TLS flights encapsulated in EAP-TLS messages, until the
generation of server and client finished messages.
Pascal Urien 120
Illustration of (TLS) Encryption and
(DTLS) Decryption Operations

Pascal Urien 121

 APPLICATION TLS SECURITY
MODULE
TLS

RAMCPU
PACKETS EAP-TLS
TLS PACKETS E2PROM
EAP-TLS
BRIDGE ROM

APPLICATION DTLS SECURITY

MODULE
DTLS EAP-TLS

RAMCPU
PACKETS DTLS PACKETS E2PROM
EAP-TLS
BRIDGE ROM
Pascal Urien 122
 Experimental Platform
The cryptographic module (Gemalto TOP-IM_GX4 )is based on
the Samsung S3CC9TC chip. It includes:
- a 16 bits CPU
- 72 KB of EEPROM
- 384 KB of ROM
- 8 KB of RAM for the CPU
- 2 KB of RAM for the crypto processor

Pascal Urien 123

 Performances
The booting of a TLS/DTLS session (until the delivering of
finished messages) should cost about 878 ms (1300 ms
measured) consumed by the following operations:
- 556 ms for RSA procedures, one RSA private key
encryption and two public key decryptions (510+ 23 + 24)
-322 ms for hash procedures, requiring the computing of
230 MD5 et 230 SHA1 block
The measured time for a resume session (75 SHA blocks+ 75
MD5 blocks = 105 ms ) setting is 360 ms
Pascal Urien 124
 Performances
The processing of encrypted record packets, with a 1024 bytes
size, should require about 143 ms (415 ms measured),
according to the following relations :
- 135 ms (64 x 2,1) for the encryption/decryption of 64 blocks of
data.
- 18 ms (20 x 0,9) for the HMAC (SHA1) processing of 20 (16+4)
blocks of data

Pascal Urien 125

 Example of Application
eLock KeyServer
COAP COAP HTTP
DTLS SIM DTLS SIM TLS
Server Client TCP
NFC NFC IP

“Innovative DTLS/TLS Security Modules Embedded in SIM Cards

for IoT Trusted and Secure Services”, to appear, IEEE CCNC 2016
Pascal Urien 126
 USE Case 1. CoAP Key
Secure Element as a CoAP Client
Secure Element as a TLS client
Urien, P.; "Innovative DTLS/TLS Security Modules Embedded in SIM Cards
for IoT Trusted and Secure Services", IEEE CCNC 2016, Las Vegas, NV, USA
Urien, P.; "Towards Secure Elements For The Internet of Things: The eLock Use
Case", IEEE MobiSecServ 2016, Gainesville, FL, USA

Pascal Urien 127

 Issues to Solve
In the Internet • What is a Key in the Internet of Things ?
• A Mobile Application ?
of Thing (IoT) • Where is stored the Key ?
a lock is a • In a Secure Element (SIM)
COAP Server • Who is generating the Key ?
• A Key server generates
So the Key KeyContainers
is a COAP • What about security and trust
Client – COAP client and dual TLS/DTLS stack
are running in a Secure Element

Pascal Urien 128

IEEE CCNC 2016 Demonstration

Pascal Urien 129

User’s Experience

Pascal Urien 130

 Double TLS with RACS Server for Key
Provisionning
SIM COAP
NFC Lock TLS/DTLS Security Module RACS Server
COAP Server

DTLS 2xTLS
COAPTLS
DTLS TLS Session
COAP POST is transferred Get
KeyValue to the Mobile KeyContain
COAP ACK OK
er
DTLS Close
Write KeyContainer in the SIM
DTLS Close

Pascal Urien 131

 Use Case 2. TLS Server
for Operated Connected Plug
Secure Element as TLS Server Stack

Pascal Urien 132

 A Connected Plug

ePlug.java
TLS-SE API HTTP
TLS Server
JAVA 1.5
TCP
PCSC- Virtual IP
Lite Hub
Debian OS
TLS
Pascal Urien 133
 Switches
Power In AmpMeter
TLS

Raspberry Pi
Power Out Pascal Urien 134
Questions ?
Pascal Urien
October 9th 2016

Pascal Urien 135