NFC Technologies and Systems

By Sarah Clark
This report and man

y others are
available free of ch
arge at the
NFC World+ Know
ledge Centre
https://members.n
fcworld.com
A clear and comprehensive guide to how

NFC works, the technical options available
and how to unlock its commercial potential
SJB Research
NFC Technologies and Systems
by Sarah Clark
Published by SJB Research
Sarah Clark is the editor of NFC World, the international, independent and objective trade
publication for those that design, supply, buy or use NFC-based products.
Sarah is also the author of The NFC Report, of which this research report forms a part, and is a
seasoned analyst who has been commentating on emerging technologies such as smart cards and
biometrics in areas as diverse as banking, retail and transport for more than 25 years.
Read NFC World at www.nfcworld.com and find out about The NFC Report at www.sjb.co.uk
NFC Technologies and Systems
ISBN 978-0-9564762-4-1 (Book)

ISBN 978-0-9564762-5-8 (PDF)
First published in the UK in April 2012
Reprinted September 2012
Copyright SJB Research 2012-2014
The right of Sarah Clark to be identified as the author of this work has been asserted by her in
accordance with the Copyright, Designs and Patents Act 1988.
All rights reserved. No part of this publication may be reproduced, stored in or introduced
into a retrieval system, or transmitted, in any form, or by any means (electronic, mechanical,
photocopying, recording or otherwise) without the prior written permission of the publisher. Any
person who does any unauthorised act in relation to this publication may be liable to criminal
prosecution and civil claims for damages.
Whilst every care has been taken to ensure that the contents of this document are correct, no
responsibility or liability on the part of SJB Research can be assumed.
This publication is designed to provide accurate and authoritative information in regard to the
subject matter covered. It is sold with the understanding that the publisher is not engaged in
rendering legal, accounting or other professional advice.
SJB Research
Y Plas
Plas Machynlleth
Machynlleth
SY20 8ER
UNITED KINGDOM
Tel: +44 1341 760123
Fax: +44 1341 760124
www.sjb.co.uk
Table of contents
Table of contents
1
1.1
1.1.1
1.1.1.1
1.1.1.1.1
1.1.1.1.2
1.1.1.1.3
1.1.1.1.4
1.1.1.1.5
1.1.1.1.6
1.1.1.1.7
1.1.1.1.8
1.1.1.1.9
1.1.2
1.1.2.1
1.1.2.1.1
1.1.2.1.2
1.1.2.1.3
1.1.3
1.1.3.1
1.1.3.1.1
1.1.3.1.2
1.1.3.1.3
1.1.3.1.4
1.2
1.2.1
1.2.2
1.2.3
1.2.4
1.2.5
1.2.6
1.2.7
1.2.8
1.2.9
1.2.10
1.3
INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
The three modes of NFC devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Read/write mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Example use cases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Collect a coupon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Obtain information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Check in to a location. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Purchase a product or sign up for a service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Initiate an action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Initiate multiple actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Create dependent actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Personalize an action. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Read a contactless card. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Peer-to-peer mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Example use cases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Social networking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Device and equipment pairing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
P2P payments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Card emulation mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Example use cases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Payments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Tickets and passes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Keys and credentials. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
The building blocks of NFC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
NFC phones and other devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
NFC tags. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
NFC terminals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
NFC reader/writers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
The secure element. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
The mobile wallet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
NFC applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
NFC platforms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
The TSM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
The NFC infrastructure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Creating value with NFC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2
2.1
2.1.1
2.1.2
NFC PAIRING AND SHARING. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

NFC tags. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
The four NFC Forum tag types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Emerging tag types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
NFC TECHNOLOGIES AND SYSTEMS
SJB Research Ltd 2012-2014 All rights reserved
Page 1
Table of contents
2.1.2.1
2.1.2.2
2.1.2.3
2.1.2.4
2.2
2.2.1
2.2.1.1
2.2.1.2
2.2.1.3
2.2.1.4
2.2.1.5
2.2.1.6
2.2.1.7
2.3
2.3.1
2.3.2
2.3.3
2.4
2.4.1
2.4.2
Cheaper production technologies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

New tag formats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Non-standard chips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Dynamic tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Writing to NFC tags and cards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
NFC tag data formats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
The NFC Data Exchange Format (NDEF) specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
The NFC Record Type Definition (RTD) specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
The URI Record Type Definition specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
The Text Record Type Definition specification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
The Generic Control Record Type Definition specification. . . . . . . . . . . . . . . . . . . . . . . . . . 38
The Smart Poster Record Type Definition specification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
The Signature Record Type Definition specification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Peer-to-peer mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
The Logical Link Control Protocol (LLCP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
The Connection Handover Protocol (CHP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
The Simple NDEF Exchange Protocol (SNEP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Sharing and pairing apps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
The JSR 257 Contactless Communications API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Smartphone apps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3
3.1
3.2
3.3
3.4
3.4.1
3.4.1.1
3.4.1.2
3.4.1.3
3.4.2
3.4.2.1
3.4.2.2
3.4.2.3
3.4.2.4
3.4.3
3.4.3.1
3.4.3.2
3.4.3.3
3.4.3.4
3.4.3.4.1
3.4.3.4.2
3.4.3.4.3
3.4.4
3.4.4.1
3.4.4.2
3.4.4.3
3.5
3.6
3.7
THE SECURE ELEMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

What can be stored in a secure element?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
How secure elements keep sensitive data secure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Secure element certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
The SIM as secure element. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
The three parties on an NFC SIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
The mobile network operator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
The Confidential Key Loading Authority. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
The Supplementary Security Domain (SSD) owners. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Types of Supplementary Security Domain owners. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Mobile network operators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Mobile virtual network operators (MVNOs). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Third parties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Service providers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Creating a supplementary security domain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Fully preloaded SSDs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
SSDs created partially over-the-air . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
SSDs created fully over-the-air. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
SSD creation modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Simple Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Delegated Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Authorized Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Distributing the keys to the new domain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
SSD created and assigned at the factory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
SSD created at factory but not assigned. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
SSD created over-the-air. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Embedded secure elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
External secure elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Trusted Execution Environments (TEEs). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4
4.1
4.1.1
4.1.1.1
4.1.1.2
4.1.1.3
4.1.2
NFC PHONES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
The antenna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
NFC antenna design constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Interference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Types of NFC antenna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Page 2
Table of contents
4.2
4.2.1
4.2.1.1
4.2.1.2
4.2.2
4.3
4.3.1
4.3.2
4.4
4.4.1
4.4.1.1
4.4.1.2
4.4.2
4.5
4.5.1
4.5.2
4.5.3
4.6
4.6.1
4.6.2
4.6.3
4.6.4
4.6.5
4.6.6
4.7
The NFC controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Future developments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Combo controller chips. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Baseband controller chips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Supporting multiple secure elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
The main processor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
The NFC protocol stack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
The mobile wallet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
NFC phone security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
HCI and SWP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
The Single Wire Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
The Host Controller Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
The JSR 177 Security and Trust Services API (Satsa). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
NFC phone certification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
The NFC Forum device certification programme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Vertical market certification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Local market certification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Adding NFC to existing phones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
MicroSD card solutions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
NFC cases and sleeves. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
SIM+antenna solutions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
All-in-one NFC SIMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Bluetooth and WiFi peripherals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Contactless stickers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Other NFC devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5
5.1
5.1.1
5.1.1.1
5.1.1.2
5.1.1.3
5.1.2
5.2
5.2.1
5.2.2
5.2.3
5.2.4
5.2.5
5.2.6
5.2.7
5.2.8
5.3
5.3.1
5.3.2
5.3.2.1
5.3.2.2
5.4
5.4.1
5.4.2
5.4.3
5.4.4
5.4.5
DELIVERING NFC SERVICES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Pre-launch requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
NFC platforms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Secure element issuer platforms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Service provider platforms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Connecting the dots. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
App approval. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Enabling customers to request the NFC service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Via a smart poster or tag. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
At the point of service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Via consumer request to a contact centre or website. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
In response to marketing and advertising campaigns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Via direct distribution of an NFC add-on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Via an app store. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Via the mobile wallet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Viral distribution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
NFC app delivery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Checking phone and contract compatibility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Loading the NFC app onto the customers device. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Fully and partly pre-loaded NFC applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Loading NFC applications over-the-air . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Maintaining and upgrading an NFC service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Managing customer service enquiries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Lost/stolen phone blocking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Change of SIM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Change of phone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Cancellation of mobile network service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
INDEX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Page 3
Web links
A word about web links
Weve included web links throughout this research report to help you with further reading.
In the PDF version of the report they are all live, clickable links. Just click and your browser will
open and youll be taken to the relevant source material. Your PDF reader may warn you that the
document is trying to connect to an internet-based resource; this is normal behaviour and should
be allowed if you want to use our live links. You may also want to ask your PDF reader software to
Remember my action for this site to prevent future warnings on these links.
If youre reading the printed version of this document youll need to type the links into your
browser manually. We have used a link shortener to make this easier; youll notice that the address
bar on your browser will change to reflect the pages true address as you load it.
Our shortened links are in two forms:
1. nfcw.net/s/xxxx these are links to articles on our NFC World industry news website at www.
nfcworld.com
2. sjb.co.uk/xxxx these are links to third party websites which are routed through our own
link shortening service. Please note that we have no control over the content of these third
party websites.
If you notice any broken links when using our shortened URLs it is the nature of the web that
links decay over time as organisations reorganise their sites please let us know by sending email
to info@sjb.co.uk and well fix them where possible. Doing this will benefit you and all other users
of this report.
Page 4
Introduction
Introduction
Near field communication (NFC) is a short-range wireless communication

technology that enables two devices to communicate with each other by simply
bringing one into close proximity with the other.
NFC technology built into mobile phones and other electronic devices enables a wide
range of new services to be introduced, from mobile payments to advertising and
marketing, transportation ticketing, social networking, access control and more.
NFC-enabled phones, and other devices, can be used for these new services because
they provide three new functions:
Card emulation: NFC-enabled phones can emulate plastic cards, such as
payments cards, transportation cards, government and employee ID cards,
membership and loyalty cards and more.
Tag reading and writing: NFC-enabled phones can read and write to lowcost NFC tags which can be affixed to posters, marketing materials, product
packaging, signage and more. By simply touching an NFC phone to an NFC tag,
consumers can quickly and easily access information online, download a coupon,
or discover more about the world around them.
Peer-to-peer communication: NFC-enabled phones can communicate with each
other using peer-to-peer (P2P) communication. When two devices are held close
to each other, business cards, photos and other information can be instantly
exchanged.
To make these new functions possible, NFC capable devices contain five new
elements that are not found in standard phones:
A short-range radio antenna that operates on a frequency of 13.56MHz, making it
compatible with contactless cards, terminals and a number of RFID tags.
Page 5
Introduction
A secure element, which acts as a digital vault to store personal and sensitive data
in a highly secure manner.
An NFC protocol stack installed on the phones processor to enable it to leverage
the phones NFC capabilities.
A mobile wallet that lets the phones user view NFC-related information stored on
the device.
An NFC controller chip that sends and receives information and routes it to the
correct location within the mobile phone.
NFC services use a combination of NFC phones, tags and terminals to provide
businesses and consumers with easy, flexible ways to interact with the world around
them. NFC systems that use only the tag reading and writing features can be built
quite simply, and consumers can even program their own NFC tags without having
technical skills.
Systems that use a secure element, however, are much more complex because:
Secure NFC services require that top levels of security are provided end to end
throughout the system within the phone itself, in back-office systems that
communicate with the phone, and whenever information is sent to the phone
over the air.
Standard mobile phones are inherently insecure. Most smartphones do not come
with a high level of security built in and, once delivered to their owners, they
are outside the control of the mobile network operator, the manufacturer and
application developers. Fraudsters and hackers can work on cracking the security
in a mobile app in the privacy of their own homes.
A number of different businesses need to work together in order to provide secure
NFC applications. Mobile network operators, handset manufacturers, operating
system developers, and businesses developing secure applications must all agree
on standard procedures to ensure that security is maintained from one end of the
chain to the other.
1.1
The three modes of NFC devices
NFC devices are designed to operate in three different modes. These three modes
enable an NFC device to:
Page 6
Introduction
Read and write to NFC tags and contactless cards (Read/Write Mode). In this
mode, the device can provide operating power to a passive tag or card.
Transfer data between itself and a second NFC device (Peer-to-Peer Mode).
Optionally, act as a virtual equivalent of a payments, loyalty, transit, access control
or other contactless card (Card Emulation Mode). In this mode the NFC device
appears to the terminal to be a contactless card.
Specifications for these three modes of operation have been set by the NFC Forum,
an international trade association established in 2004 (see www.nfc-forum.org). The
specifications are designed to ensure that any NFC device will work with any other
NFC device and with any NFC tag, contactless card or terminal that also conforms to
NFC Forum specifications.
The NFC Forum specifications are built on a core standard known as ISO/IEC
18092, Near Field Communication Interface and Protocol-1, or NFCIP-1 for short,
which was approved in December 2004 (see sjb.co.uk/axc5).
NFCIP-1 specifies that communication between an NFC device and an NFC tag,
card terminal or another NFC device must take place over a radio (RF) link using the
13.56MHz frequency. It also defines the communication parameters of the RF link for
all NFC devices in all three modes and allows communication between two powered
(active) devices, such as two mobile phones, and between an active device and a
passive device such as an NFC tag.
While all NFC communications take place at 13.56MHz, radio signals are modulated
differently and data is transferred in a different format by each of the numerous types
of card and tag that uses this RF frequency.
The NFC Forum specifications, therefore, build on NFCIP-1 to set out the way in
which tags, devices and terminals communicate with each other in each of the three
NFC modes. This provides manufacturers and systems designers with two advantages.
They can make NFC devices and information systems that work together in a
standard way and they can also enable those systems and devices to work in a way
which is consistent with other, existing standards. NFC devices and service providers
can therefore take advantage of the existing installed base of contactless terminals, ID
systems and transportation ticketing equipment as well as a host of other contactless
systems.
Page 7
Introduction
1.1.1
Read/write mode
In read/write mode, an NFC device can do one of three things:

It can read data stored in an NFC tag and automatically act upon the information
received.
It can read data stored on a contactless card, enabling it to act as a mobile
merchant terminal, ticketing machine, or access control device provided it is
equipped with the relevant software.
It can write new or updated data to an NFC tag or contactless card, provided
settings allow.
Reading an NFC tag opens up an array of new opportunities for interacting with the
world around us. At one end of the scale, an NFC tag can be used to simply store
information, such as the URL of a website or the telephone number of a colleague or
helpline. At the other, a tag can be used to allow a complex series of instructions to be
performed.
1.1.1.1
Example use cases
1.1.1.1.1
Collect a coupon
An NFC tag can be written with the details of a money-off coupon or other special
offer, or with the URL of a website where the latest special offer coupon or voucher
can be obtained. When an NFC device is brought into close proximity with the tag,
the device can read the URL and then automatically visit the URL to download
current promotional offers to the devices memory.
1.1.1.1.2
Obtain information
An NFC device can download an app or detailed information about a product or

location directly from a tag, or a tag may contain the URL of a site from which an
app or detailed information can be obtained. For example, touching an NFC device
to a tag might provide real-time data indicating the time the next bus will arrive at a
particular bus stop or the full ingredients list of a recipe or a meal at a restaurant.
Page 8
Introduction
1.1.1.1.3
Check in to a location
NFC tags can be used in both consumer and business-to-business environments to

register the presence of an NFC device user. Tags placed at the entrances to stores,
venues and events can be set so that an NFC device user can check in to the location
and alert staff of their arrival. Tags can be preprogrammed to also update the users
status on social networking services and friends or colleagues can also be informed
of their location. Rewards can also be offered by the location owner as an incentive to
check in.
This same approach can be used in a business-to-business environment. A security
guard can be required to check in to locations on his rounds, for instance, and NFC
tags can also be used to confirm that a home healthcare visit has been made.
1.1.1.1.4
Purchase a product or sign up for a service
NFC tags attached to product packaging, to products, or to merchandising displays

can be used to enable consumers to enrol in a service or purchase a particular item.
When the tag is read, the item can be ordered for delivery to the shoppers home
address or added to a self-checkout basket. The shopper can also be automatically
directed to a website or app store to register for a service or download an app.
1.1.1.1.5
Initiate an action
Tags can be used to initiate other types of action, beyond just taking the user to a
URL. Touching a tag at the entrance to a conference room, for example, can put a
mobile phone into quiet mode. Registering the time a staff member arrives on site
or speed dialing a colleague or friend are other examples.
1.1.1.1.6
Initiate multiple actions
An NFC tag can be programmed so that a series of instructions will be performed

when it is read. A single tap of an NFC phone to a car dashboard, for instance, can
switch on the phones Bluetooth radio, disable WiFi and start the satellite navigation
app all in one go. In the future, it could even be used to set the drivers preferences for
seating position, radio station and mirrors.
Page 9
Introduction
1.1.1.1.7
Create dependent actions
NFC tags can also be programmed so that the action taken depends on whether an
application has already been downloaded onto a phone.
A tag issued by a loyalty program provider that promotes a members-only offer, for
instance, can first initiate a search to discover if the device has a valid membership
card stored in it. If the app has already been installed, the promotional offer is
downloaded directly to the device. If not, a request to download the application will
first be made, and the offer will then be added to the app.
1.1.1.1.8
Personalize an action
The information delivered to an NFC phone user when they read a tag can be varied
according to a set of predetermined preferences stored on the device. This would
allow, for instance, a list of the ingredients in a food product to be compared with a
list of the device users allergies. An alert can then be generated when the user reads a
tag on a food product containing a particular ingredient.
1.1.1.1.9
Read a contactless card
The NFC Forum standards specify that, as well as being able to read approved NFC
tags, an NFC device must also be able to read standard contactless cards. This means
that NFC devices can also be used to read many contactless cards, provided the device
has the correct type of software installed.
With the addition of specific application software, and with the required security
approvals in place, an NFC device could in the future also be used as a portable
point-of-sale (POS) terminal, enabling merchants to accept payments via contactless
cards and NFC phones. For smaller merchants, this means card payments could be
processed without the need to acquire a dedicated terminal. For larger merchants,
staff equipped with NFC phones or tablets could provide information and complete
purchases without requiring the customer to visit a cash desk.
1.1.2
Peer-to-peer mode
In peer-to-peer (P2P) mode, two NFC devices are able to exchange information with
each other when they are brought into close proximity.
Page 10
Introduction
With NFC P2P, establishing a connection between two NFC devices is quick and easy.
NFC is not designed to have a fast data transfer rate, however, so NFC specifications
are also designed to allow NFC to be used to establish a connection between two
devices and then hand over to faster transfer technologies, such as Bluetooth or WiFi,
if larger amounts of data need to be exchanged.
A standard way for NFC devices to operate in P2P mode has only recently been
approved by the NFC Forum so this NFC mode is, to date, one of the least explored
in a commercial setting. Numerous early applications of NFC P2P mode have been
created, however, and its potential in social networking and in pairing devices and
equipment has been widely explored.
NFC P2P mode can also be used to exchange payments information between
two devices. This application area has been less explored since both core NFC
standards and payments security approvals are required before P2P payments can
be commercially introduced. Its potential, however, is likely to impact not just the
payments industry but also merchants, travel and ticketing services and a wide array
of other businesses.
1.1.2.1
Example use cases
1.1.2.1.1
Social networking
Phone-to-phone information exchange in NFC P2P mode allows two people with
NFC-enabled devices to exchange information stored in their devices.
In a business environment, this means that virtual business cards stored in standard
vCard format can be exchanged, avoiding the need to type a new contacts details into
a database. Touching two phones together can also be used to automatically generate
a request to connect on networks such as LinkedIn or Twitter.
The same process can also be used in a social context, to enable two friends to swap
phone numbers and become friends on social networks like Facebook or to exchange
photos and other media.
Larger files can also be exchanged using a combination of NFC and Bluetooth or
WiFi, allowing video, images and other files to be exchanged between friends and
contacts.
NFC P2P mode can also be used as a way to facilitate viral distribution of apps.
Simply touch two phones together and a game or utility app can be transferred from
Page 11
Introduction
one device to the other. Or, to enable tracking and payments for apps, a link to a
games page within an app store can be shared using NFC so that the recipient can
easily and instantly download the app and begin to play with or against a friend.
Levels, points and rewards can also be shared in the same way.
1.1.2.1.2
Device and equipment pairing
Leading consumer electronics and business device manufacturers are now working on
adding NFC capabilities to a range of devices to make it easier to set up a connection
to share data and resources.
Connecting or pairing two devices with NFC is quick and simple, since they only
need to be brought into close proximity with each other with NFC, even the least
technically aware consumers can easily set up connections between their phone or
remote control and a vast range of consumer electronics devices around the home.
Everything from MP3 players, TVs, game controllers and remote controls to printers,
DVRs, cameras, keyboards, tablets, exercise machines, ATMs, Bluetooth headsets,
and watches can be equipped with NFC technology, making it easy to share user
preferences, settings, and resources such as hardware, software and entertainment
products all at a touch.
With NFC, a photo stored in a digital camera can be sent to a printer by simply
placing the two devices within a few centimetres of each other, a video can be
displayed on an NFC-enabled TV, a game running on two NFC devices can be
displayed on a shared, large screen and a music library can be played on a friends
speakers.
Two NFC devices can also share live information, as well as static data. This recent
development is expected to bring a wide range of new functions to NFC P2P mode
that improve the user experience. A consumer watching a video on an NFC phone,
for example, can transfer both the video itself and the point in the video that was
being watched to an NFC-enabled tablet or TV to watch it on a larger screen. The
video will then begin playing on the new device at the same point that it was playing
on the first device, with no interruption to the viewing experience.
1.1.2.1.3
P2P payments
NFC P2P mode can be used in secure environments such as payments, in addition
to the more open environments typically used for data exchange and pairing
Page 12
Introduction
applications. Simply touching two phones together can enable funds to be transferred
from one person to another.
P2P mode can also enable multiple simultaneous functions to be performed when
an NFC device user makes a purchase in a retail store. Here, P2P mode enables
both devices to send information to the other at the same time so that, for instance,
a special offer voucher can be sent from a point-of-sale (POS) terminal to the
customers NFC device at the same time as payments details are sent from the NFC
device to the POS terminal.
P2P is also being investigated as a way to deliver mobile payments in general. It has
the potential to avoid the complexities of NFC card emulation mode by using P2P
mode to identify the customer at the point-of-payment. The payment process would
then be managed in the cloud, rather than directly at the point-of-sale.
1.1.3
Card emulation mode
NFC devices can emulate a wide range of different types of contactless cards that
conform to the ISO 14443 standard used by payments and a wide range of other card
issuers around the world. In some instances, they are also able to emulate Sony FeliCa
contactless cards, widely used in Japan, as well as cards conforming to the ISO 15693
standard employed by the majority of access control cards used in employee ID and
hotel room key systems around the world (see www.iso.org).
As well as being able to emulate existing contactless cards, NFC devices can also be
used to replace a wide array of other forms of security and identification documents
that have not traditionally been available in card format. This allows the use cases
for NFC to be expanded to include account numbers, passports and other forms of
government ID, insurance documents, keys to buildings, rooms and vehicles, concert
tickets, airline boarding passes and more.
1.1.3.1
Example use cases
1.1.3.1.1
Payments
NFC devices can be used to emulate all standard types of contactless payments card,
including debit cards, credit cards and prepaid cash cards, allowing them to be used
by consumers to:
Page 13
Introduction
Pay now. NFC enables a digital version of a debit card to be stored in a phones
secure element, allowing purchases to be automatically debited from the users
bank account. No PIN or signature is usually required for small items, making it
fast and easy to use NFC to pay for a coffee, newspaper, or the daily visit to the
corner store.
Pay later. NFC phones can also be used to make larger purchases. A variety of
credit cards can be stored safely in an NFC device, allowing the user to charge
higher value items to their account of choice. Today, it is usually still necessary
to enter a PIN at the merchants point-of-sale terminal. In the future, it will be
possible to enter a PIN on the phone itself, bringing the speed and convenience of
small NFC payments to larger credit card purchases as well.
Pay before. Today, in most countries, small items are most commonly paid for in
cash. NFC can be used to keep a supply of electronic cash in a mobile phone so
that funds can be transferred in advance of purchases to the prepaid stored value
account and then used like cash. Accounts can also be topped up instantly over
the air or by transferring funds between two accounts, eliminating a stop at the
cash machine.
1.1.3.1.2
Tickets and passes
NFC devices can be used to emulate a wide range of tickets. These include both public
transportation passes that are already commonly delivered in contactless card format
and new electronic ticket types that are currently delivered in other formats, such as
airline boarding passes, concert and theatre tickets, sporting event passes and more.
This wide variety of NFC tickets and passes fall into four broad categories:
Individual tickets. Travellers can purchase a ticket to travel on a particular service
at a particular date and time, or a ticket to a concert or sporting event, and then
receive their ticket in digital format over the air. The ticket is then stored safely
on their mobile phone until needed. Ticket holders can then simply touch their
phone to the turnstile or a ticket validation machine when they board a train or
enter an entertainment venue.
Stored value cards. Here, an amount of money is transferred onto the card
in advance. The cost of each journey is then deducted either on entry or on
departure from a bus, train, or subway. With NFC, travellers can top up the
balance on their card from their mobile phones instantly, avoiding the need to line
up at the station or top up via the internet before making a journey.
Page 14
Introduction
Passes. With NFC, a pass can be bought in advance for use on a particular travel
route for a set period of time, or to provide access to a gym or other membership
club. The details of the route or membership level purchased and the expiry date
of the pass are then stored in the phone. The pass can then be amended and
extended over the air by the pass holder or the issuer.
Open loop cards. A number of transportation operators around the world
are now moving away from issuing their own travel passes and tickets. Instead,
they will accept contactless open loop payments cards, such as Visas PayWave
and MasterCards PayPass, instead of dedicated cards or tickets issued by the
transportation operator. These open loop cards can also be stored on an NFC
phone and allow operators to accept NFC for ticket purchases without having to
develop their own secure NFC app.
1.1.3.1.3
Identity
NFC can be used to store a wide range of types of identification securely in a mobile
phone, making it easier for consumers and ID document issuers to manage, update
and renew ID documents:
Government ID. City, regional and central government organizations can provide
NFC-based identification to both identify the citizen and provide efficient, costeffective access to services. NFC phones are able to safely store drivers licenses,
passports and national ID cards as well as proof of entitlement to government
benefits and healthcare services.
Ecommerce and eGovernment. ID information stored on an NFC phone can be
automatically transferred to a website so that online order forms, tax returns and
payments information can be automatically completed by simply touching the
phone to an NFC-enabled personal computer. Payment and address details stored
on an NFC phone can be used in the same way to speed up online transactions,
eliminating the need for consumers to enter their card and delivery details when
they place an order with an online retailer.
Employee ID. Companies can provide staff with NFC-enabled employee ID cards
that allow them to access physical locations such as offices and meeting rooms
as well as gain access to password-protected data via their PC, laptop or mobile
phone.
Page 15
Introduction
1.1.3.1.4
Keys and credentials
NFC devices can be used to deliver keys and other credentials over-the-air, with
either a long-term or short-term lifespan. These can be used to provide access to:
Hotel rooms. Hotels can send keys over the air to guests after they have booked
a room, allowing them to bypass the check-in desk and enter their room with
a touch of their NFC-enabled phone. When leaving, the guest simply taps the
phone against a tag in reception or in their room to check out.
Cars. Vehicle manufacturers can use NFC phones or other NFC-enabled devices
as replacements for traditional car keys. A car owner can then be provided with
virtual keys to a new car and the same technology can also be used to provide the
keys to a rental car, or a car shared by a group of employees, over the air.
Buildings. Virtual keys can be sent over-the-air to NFC devices in order to access
homes as well as commercial premises. Over-the-air capabilities can be used to
update which areas of a building can be accessed by an NFC device in order to
provide keys to a new office when an employee changes roles, or to a conference
room that has been booked for a meeting.
1.2
The building blocks of NFC
NFC systems range from the very simple to the extremely complex, depending on the
levels of security required in the system and the number of parties that are required to
be involved.
At one end of the scale, an individual consumer or software developer can use their
NFC phone to write to NFC tags supplied with their handset so that they can, for
example, simply touch their phone to a tag in order to dial a particular number. Here,
no other parties need to be involved.
At the other end of the scale, mass market deployments of NFC services employing
secure data such as card account numbers require the involvement of multiple service
providers and technology suppliers as well as buy-in from merchants, mobile network
operators and others.
This section looks at each of the individual building blocks that can be incorporated
into an NFC system in order to create a solution that delivers value to both users and
service providers.
Page 16
Introduction
1.2.1
NFC phones and other devices
NFC devices contain five elements that are not present on standard phones: a short
range radio frequency antenna, an NFC controller chip, an NFC protocol stack and,
usually, a secure element and a mobile wallet. These five elements are connected
by industry-approved secure communications channels to ensure that sensitive
information contained within the phone is kept secure.
In order to meet industry standards, an NFC device must be able to operate in both
read/write and peer-to-peer mode. Card emulation capabilities are currently classed
as an optional extra.
As well as devices that have NFC functionality built into them by the manufacturer, a
number of ways have also been developed for adding NFC functionality to standard
mobile phones. These enable phones to be retrofitted with the ability to emulate
contactless cards, using specialist microSD format devices, cases, stickers and other
techniques. Some also include the ability to read NFC tags.
Tablets and laptops as well as a host of other non-mobile devices that provide support
for NFC functionality are now also appearing on the market, widening the use cases
for NFC beyond just mobile phones to a full array of consumer electronics and
business devices.
Specialist NFC devices are also available that perform NFC functions without having
mobile communications capabilities. These usually include the ability to perform in
just one or two NFC modes and are available in a number of different form factors
from different suppliers. Options include, for example, small devices that are able
to collect information from tags and then download that information to a PC at the
end of the day, or devices that provide tag reading and specialist software that can be
rented out to tourists so they can explore in detail a particular attraction or walking
route.
How NFC phones work, the different elements that go into an NFC phone, the way
in which a secure environment is created within an NFC phone as well as the ways
in which NFC functionality can be added to existing mobile phones are described in
detail in Chapter 4.
Page 17
Introduction
1.2.2
NFC tags
Four types of NFC tag are available, each of which conform to international RFID
or contactless card standards. They are designed to be low cost and to have a long
lifespan so that they can be placed in the widest possible range of environments.
NFC tags contain a radio frequency antenna and a small silicon chip but no battery
or power supply. They are powered up by an NFC device when the device is brought
into close proximity with the tag. This allows information to be read from the NFC
tag or written to it by the NFC device without any need to wire the tag into any
form of communications network or electrical circuit. This means that NFC tags
can be deployed at lower cost and with greater flexibility than existing interactive
information systems that require connecting to a server, internet service or other back
office system.
NFC tags are typically delivered as a small, square or circular package measuring as
little as 15mm across that is ready for printing on and for attaching to or embedding
into objects such as posters, merchandising displays and products.
A wide range of new forms of tag are now also under development and the search
is on for tags that can be produced for a low enough cost that they could be printed
on to every day objects such as cereal boxes, business cards and pharmaceutical
containers.
In-depth information on the four types of NFC tag currently available, and the tag
technologies expected to arrive in the future, as well as details of the way in which
data is formatted for writing to an NFC tag so that it can be read by any NFC phone,
is set out in Chapter 2.
1.2.3
NFC terminals
When an NFC device comes into close proximity with a compatible point-of-sale
terminal, contactless entry system or other NFC compatible security system, the
two perform a handshake that lets the NFC device identify the type of reader or
terminal. The device then talks to the terminal using one of the protocols stored
in its memory, presenting the information in exactly the same way as information is
presented by a contactless card.
The terminal then responds to the NFC device in exactly the same way as it responds
to a contactless card. It also handles a transaction, request, or ticket validation in the
Page 18
Introduction
same way, regardless of whether the user is identified by a contactless card or a virtual
equivalent stored on their mobile phone.
This means that the terminal does not distinguish between a phone and a standard
contactless card the two appear to the terminal to be exactly the same. No upgrade
to existing contactless terminals and readers is therefore required in order to begin
allowing NFC devices to be used alongside existing contactless cards, providing the
terminal meets current contactless standards for its sector.
Standard contactless terminals are designed to support one particular type of
contactless protocol. Each type of terminal is therefore designed with the specific
needs of its application in mind and will work only with contactless cards and NFC
phones that also support that protocol.
Current generation contactless terminals that can be used with NFC phones, provided
the right kind of app has been installed on the phone, include:
Payments. Contactless POS terminals, vending machines, car parking machines,
ATMs and other self-service points can all interact with NFC phones.
Ticketing. Contactless transportation ticketing barriers, ticket machines, airport
security systems, stadium access gates and more can all work with NFC phones.
ID. Door locks in homes, offices, cars and hotels equipped to work with contactless
cards can all also operate with NFC phones. Everything from PCs to school
registration systems, car locks, and membership card terminals can also be
equipped to work with NFC devices.
Unlike contactless terminals, which are designed to work with a specific type of
contactless card and usually in only one particular type of application, NFC terminals
can handle multiple contactless card protocols and/or multiple functions. A standard
contactless POS terminal, for example, can process payments made via contactless
payments cards and NFC phones emulating contactless payments cards.
An NFC POS terminal, on the other hand, will also be able to offer a range of
additional capabilities such as:
Read and write to multiple types of contactless card. An NFC terminal attached
to a retailers cash register could be configured to accept as loyalty identifiers a
full range of contactless card types, from retailer-issued cards to transport tickets
and even library cards. NFC reader/writers attached to PCs, meanwhile, can both
read and write to NFC phones and to a full range of contactless cards and tags
conforming to NFC Forum standards.
Page 19
Introduction
Processing multiple payments types and marketing functions. NFC POS

terminals can do more than simply process a payment. They can be configured
to handle numerous current and emerging payments types as well as to provide
for social media check-ins and the redemption of coupons issued by a wide array
of marketing services. They can also do both functions at the same time using
P2P mode, a coupon can be issued to a customer at the same time that a payment
is being processed.
NFC devices equipped with card processing software can also act as single and
multi-function NFC terminals. This capability can provide small businesses and
people working in the field or visiting customers homes, for example, with the ability
to process payments without needing dedicated payment terminals. They will be
able to simply use their NFC-enabled phone to capture payment information from
customers NFC phones or contactless cards.
Both NFC phones and NFC-enabled tablets are also expected to be used by larger
merchants to equip in-store staff with portable payments devices that they can carry
with them to both access detailed information about a product via the internet and to
complete sales without needing to visit the cash desk.
1.2.4
NFC reader/writers
NFC reader/writers are simpler and lower cost than NFC terminals since they are
designed to only allow data to be read or written to in NFC read/write mode and/or
NFC P2P mode and do not have the security requirements of NFC terminals which
operate in card emulation mode.
For personal and small business use, NFC reader/writers can be built in, or attached
via USB, to a wide range of equipment. When attached to a personal computer, for
example, they can be used to write a coupon downloaded from the internet to an
NFC phones memory or to read data collected by an NFC phone during the day.
NFC reader/writer capabilities can also be built into manufacturing equipment so that
large volumes of NFC tags can be both programmed and printed on at the same time.
1.2.5
The secure element
A secure element is a tamper-resistant security chip which is designed to ensure that

sensitive data stored on an NFC phone, such as a consumers credit card details, is
kept safe from hackers and fraudsters.
Page 20
Introduction
Secure element chips are based on the same highly secure smart card technology that
is used in EMV chip and pin payments cards, mobile phone subscriber identity
modules (SIMs), US Department of Defense common access cards and a host of
other secure applications.
The security of stored data is at the heart of smart card technology. Strict guidelines
and regulations have been put in place by both global and specialist standards bodies
which cover every aspect of their production, personalization and distribution as well
as for the way in which they interact with equipment such as point-of-sale terminals,
ticketing machines and access control devices.
Each secure element is issued by a single business entity, such as a mobile network
operator, handset maker or a joint venture company set up by a number of businesses
with the specific aim of delivering NFC services to consumers as well as to other
service providers such as banks, retailers, transport operators and brands.
Each secure element is able to store data and applications belonging to a number of
different service providers. Each service providers data is stored within the secure
element in that providers own secure compartment, known as a Supplementary
Security Domain, ensuring that each companys data is kept private and cannot
be accessed by fraudsters, by other service providers or by the issuer of the secure
element.
Secure elements are available in a number of different form factors, but they all have
the same highly secure smart card technology at their heart. Secure elements can be
built into the SIMs issued by many mobile network operators to their subscribers,
they can be embedded into a mobile phone by the manufacturer at the factory or they
can retrofitted at a later date to a standard mobile phone. Here, secure elements can
be built into microSD devices and mobile phone cases as well as into a range of other
formats.
How secure elements work, how data is stored securely within them and how an
individual service providers data is kept private is explained in detail in Chapter 3.
1.2.6
The mobile wallet
The term mobile wallet is used to describe both a virtual version of a traditional
leather wallet and the contents of that wallet, such as cards, passes, keys and ID.
Mobile wallet software acts in a similar role to a real world leather wallet, in that it is
a way to organise and view items which an individual wishes to carry with them in
Page 21
Introduction
a secure manner. Unlike a leather wallet, however, secure items are not themselves
stored in the mobile wallet application. They are instead stored in the secure element.
In an NFC phone or other secure NFC device, therefore, the mobile wallet acts as
a window on the secure element, enabling the user to organise the contents and to
view information on the status of their secure NFC services, such as the balance on a
prepaid card account.
As well as storing secure data, a mobile wallet can also be used to store non-secure
items such as vouchers and coupons, receipts, and transaction histories. This is
designed to make it easy to keep everything in one place and, for example, to both
make a payment and automatically redeem a coupon with one touch of a mobile
phone to a point-of-sale terminal.
Non-secure items do not have to be stored in a mobile wallet, however. They can also
be stored in the phones main memory within an independently provided app, thus
allowing businesses to offer services which use only NFC tag reading and/or peerto-peer functionality without needing to enter into a commercial agreement with a
secure element issuer.
Like a conventional wallet, a mobile wallet contains a number of different
compartments, each of which stores information about a different type of service. A
mobile wallet allows the user to:
Store cash. Users can see how much cash they have, what they spent it on and top
up with more cash over-the-air without needing to visit a cash machine.
Store payments cards. Users can see what payments cards they have available,
pick the card they wish to use for a particular transaction and set a default
payment card that will be used for most transactions.
Store a variety of loyalty and membership cards. These can be used to identify
the consumer as being eligible to receive a particular benefit when they frequent a
merchant or club.
Store coupons, receipts, library cards, photo IDs and all the other items which are
typically found in a wallet.
An NFC mobile wallet can also be used to:
Store items like car keys and paperwork that dont fit into a traditional wallet.
Page 22
Introduction
Provide the user with a view of the transactions they have made as well as the
current balance available on prepaid accounts and details of the coupons and
special offers they have collected.
Conveniently organize the contents into categories, such as payments cards,
transport and travel, coupons and offers, ID documents, and others.
Set up default preferences for which payment card should be used in each
circumstance. This would allow, for example, a business executive to choose to
have their business charge card set as the default for airline bookings and hotel
charges. Their personal debit card would then be used for all other purchases.
Using the mobile wallet, the user will then be able to choose to use a different card
for any particular purchase.
Automatically present coupons and other entitlements to rewards and benefits
without the user needing to remember that they have collected a voucher or have
a loyalty card or stamp card in their wallet
Provide greater security. The mobile wallet app itself does not store sensitive data;
this data is stored safely in the secure element. The mobile wallet app simply
provides a way for the user to view information about the contents of their wallet.
NFC mobile wallets can be designed in a number of ways and, at this stage of
development of the NFC market, a number of different approaches are being taken.
Recent Google Wallet exploits, for example, have shown that the way in which a
mobile wallet application is implemented is critical to ensuring the overall security
of an NFC service. Any system will always only be as secure as its weakest link and
secure NFC services need to be built so that security is maintained throughout the
system, with no weak links in the chain.
NFC mobile wallet technology is also still evolving and significant improvements in
functionality are expected to appear in the coming months. Two key innovations now
under development are likely to have a particularly important impact:
Mobile wallets will be able to work with more than one secure element, allowing
users to view in one place information on services stored in secure elements
managed by multiple parties.
Mobile apps will be able to draw on data held in a secure element, allowing users
to view their transaction history from within their banking app, for instance,
rather than having to directly access the mobile wallet itself.
Page 23
Introduction
1.2.7
NFC applications
For tag reading/writing and peer-to-peer applications, the process of developing and
delivering an NFC application is similar to the standard process for developing any
mobile phone app. Developers of mobile phones and operating systems that include
NFC functionality provide software development kits (SDKs) that allow developers
to write programs that take advantage of NFC. A number of independently produced
software development kits are also available and the makers of some of the most
popular mobile application development frameworks are now adding extensions to
support NFC.
Completed apps can then be uploaded to the relevant app store and distributed to
consumers and business users in the usual way. Alternatively, or additionally, they
can also be promoted to NFC phone users using smart posters and other NFC-based
marketing campaigns.
Developing applications that use an NFC secure element is a considerably more
complex task, however. To ensure end-to-end security, all aspects of secure
applications must be managed throughout their lifecycle.
Strict rules concerning the way in which secure NFC applications are written, the
types of security processes they must support and the maximum amount of memory
they must use are set by the NFC infrastructure manager, the organisation responsible
for commercialising NFC services in a particular country or type of operating system.
Secure NFC applications are developed on the basis that the secure element is
considered by the system to be a trusted environment. The main application
processor, however, is not it is treated as insecure and untrusted. Therefore, secure
NFC applications are written in two parts:
The NFC app, known as a Midlet in Java feature phones, contains generic
application software common to all users and provides a graphical interface to the
service so that, for instance, the service providers logo can be displayed on the
phones screen when the user performs an NFC action or the latest balance on a
prepaid card can be viewed. Different formats and versions of the NFC app may
be needed for different handset models and operating systems.
The second part, the NFC Cardlet, is stored in the devices secure element. It
contains two elements application code specific to the NFC service and
personal data relating to the individual user of the device.
Page 24
Introduction
This two part approach means that sensitive data can be separated out and stored
securely in the secure element while generic data can be stored in the phones less
secure but more spacious and powerful main application processor.
How secure NFC applications are structured, how they are distributed and how
personal, sensitive data is securely added to the secure element in an NFC device is
covered in detail in Chapter 3.
1.2.8
NFC platforms
Before service providers can begin providing NFC services to their customers, back
office systems need to be put in place to enable applications and, where required,
personal data to be delivered to NFC phones and secure elements. And, depending on
the type of service to be introduced, new platforms or upgrades to existing platforms
may also be required in order to process NFC actions.
For pairing and sharing applications, the process of providing an NFC app to
customers can be as simple as uploading an application to the relevant app store so
that customers can then download the app to their NFC phone and begin using it to
collect information and to share information with friends and contacts.
For secure NFC services, and to enable pairing and sharing applications to
be distributed via tag reading, platforms need to be put in place that allow
communication with the NFC phone to be made over the air (OTA).
The exact nature of the platforms required to support NFC services will differ
according to the type of service to be offered and the way in which an NFC
infrastructure has been established.
In a typical secure NFC service scenario, however, NFC platforms will be required by
both the secure element issuer and each service provider.
These platforms are integrated, as required, with existing customer records systems to
allow an individual consumers details to be securely sent from the service providers
back office system over-the-air to that consumers mobile phone.
Depending on the type of application to be provided, additional back office systems
may also need to be put in place in order to process transactions. NFC is built on the
concept that it is an enabling technology, allowing new functions and new customer
benefits to be created with the minimum amount of change to existing processes and
infrastructures. Wherever practical, therefore, NFC is designed to be compatible with
existing ways of doing business and to sit on top of existing processing systems.
Page 25
Introduction
In practice, this means that in many cases the task of processing an NFC action
requires no additional work to be done. A payment made at a retailer using a card
stored on an NFC phone, for example, will be processed in exactly the same way as a
payment made with a traditional plastic card.
As NFC has moved towards commercial adoption, however, it has become clear
that the technology also offers the potential to transform the way in which certain
processes are currently performed. Public transportation operators are looking
to NFC to eliminate the need to manage their own ticket issuing infrastructures
altogether, online payments services are investigating ways to reduce the cost of
processing in-store payments, marketers are creating new ways for companies to
communicate with their customers, leveraging NFC to build new experiences that
generate maximum appeal to todays connected consumers.
Developing services that take maximum advantage of the potential of NFC
technology requires an in-depth knowledge of how the technology works. The ways
in which NFC applications can be delivered to consumers, the types of platform
required to deliver services and how secure NFC services are managed in the field are
covered in detail in Chapter 5.
1.2.9
The TSM
Trusted Service Managers (TSMs) are specialist, independent third party suppliers
with a background in managing highly secure data and in creating systems that
ensure data is kept secure in transit between one secure system and another.
TSMs have particular expertise in secure element technology, in encryption, in overthe-air communications and in the provision of secure production facilities. They are
typically appointed by the issuer of a secure element to manage access to the secure
element on the issuers behalf, to provide both the issuer and service providers who
wish to use the secure element with confidence that the data will be kept safe from
hackers and fraudsters, as well as from other service providers and the issuer of the
secure element itself even when that data is being sent over the air to a consumers
mobile phone.
Depending on the way in which an NFC system is set up, service providers may
also be able to appoint their own TSM to act on their behalf. These service provider
TSMs work with the secure element issuers TSMs to create a link between the service
providers database of account numbers or other secure identifiers and the secure
element on which that data is to be stored. This allows service providers to retain
Page 26
Introduction
control over the way in which their data is handled and to work with existing, trusted
suppliers.
And, in a recent twist on this model put forward by industry association
GlobalPlatform, TSMs may soon work directly for consumers too. Here, the idea is
that consumers would be able to choose their own trusted token, managed by their
choice of trusted service manager. This could put the consumer in direct control of
who has access to their mobile credentials, what can be stored on their mobile wallet
and who can use their personal data.
TSMs are able to perform a number of key roles which ensure that sensitive data is
handled at all times with the highest possible levels of security. TSMs can:
Create the domains on a secure element in which service providers will store
their sensitive data, and issue keys to those domains to service providers, when a
consumer signs up for a new secure service.
Load a service providers NFC application into a new domain, provision it with an
individual users personal data and manage the application on an on-going basis.
Establish and manage secure connections between mobile network operators,
secure element issuers and service providers.
Act as a middleman between the parties, making it simpler for a service provider
to set up technical, operational and commercial relationships with all the secure
element issuers used by its customers.
1.2.10
The NFC infrastructure
A key requirement of NFC services is they must be easy and simple for the consumer
to use. For this to happen, a framework needs to be created that will allow all the
individual NFC elements to be tied together in a standard manner to ensure that each
element works in an interoperable manner with all the other elements it will be used
with.
At one end of the scale, where just one secure element issuer such as a mobile
network operator, handset manufacturer or bank and one service provider, such
as a card issuer or public transport operator, partner to deliver a single service to
consumers, an NFC infrastructure can be quite simple.
The more open the system is to multiple service providers and multiple secure
element issuers, however, the more successful it is likely to be in the long term in
Page 27
Introduction
terms of consumer and service provider adoption. The level of complexity involved,
and the costs incurred, rise exponentially with the number of service providers/secure
element issuers involved and with the number of types of service provider and/or
secure element issuers involved, however.
Organizations that bring commercial NFC services to market may choose from
several options for putting an NFC infrastructure into place. The option they choose
depends on their business model and, at this stage of the evolution of the NFC
market, on how simply they wish to begin.
Options include:
A single service provider and a single secure element provider team up to provide
an NFC service. This is the simplest option, especially as a first move into NFC,
but is also likely to be limited in terms of consumer reach.
A single secure element supplier teams up with multiple service providers. This
option can bring competitive advantage to the secure element issuer. But, again,
it is likely to be limited in terms of consumer reach to only those consumers who
are customers of the mobile network operator, handset maker/operating system
provider or other secure element issuer.
Multiple secure element issuers provide NFC services to multiple service
providers. This is the most complex option to establish, but also the route that
holds most promise in terms of consumer reach.
Several different approaches have been taken to creating infrastructures that enable
multiple secure element issuers to provide NFC solutions to multiple service
providers:
MNO joint ventures. Here, all or most of the mobile network operators in a
country team up to create a single joint venture company in which they all have
a shareholding. This joint venture company can then appoint a single TSM
to manage secure NFC services on behalf of all the partners and to provide
economies of scale. This approach has been adopted by the Isis joint venture
between US carriers AT&T, Verizon and T-Mobile as well as by groups of mobile
network operators in a number of countries around the world.
MNO frameworks. In France, one of the earliest movers in NFC, the countrys
mobile network operators have taken a standards-based approach to delivering
interoperable services. All the French mobile network operators provide
compatible NFC services under the Cityzi brand name, but there is no joint
Page 28
Introduction
venture company. Instead, each carrier is a member of the AFSCM, an association

set up with the specific remit of developing NFC service standards. Each operator
offers their own NFC service within the Cityzi umbrella and each service provider
can choose to appoint or develop its own TSM or to contract with one of the
carriers to supply secure services.
Centralized systems. One of the earliest business models explored for bringing
NFC to market called for the creation of a single, national TSM to which all
service providers and all secure element issuers could connect. This concept has
now been abandoned in favour of solutions that provide individual players with
greater flexibility in terms of who they choose to provide their NFC services. In
Singapore, however, a more modern version of this approach has been adopted
in a bid to fast track NFC adoption. Here, a contract to build a national TSM has
been awarded to a consortium of companies. The twist is that there is a limit on
the time this consortium will have sole rights to providing TSM services other
companies will then be able to enter the market and the system is required to
be fully open to all potential secure element issuers and service providers.
Ultimately, to deliver maximum consumer reach and customer convenience, NFC
infrastructures will need to cater for all types of secure element issuer and all types
of service provider in a way which enables each company to fully differentiate its
offering.
The ways in which NFC infrastructures are being built today and the ways in which
this fundamental aspect of delivering NFC services will develop in the future is
examined in detail in our companion report NFC Business Models.
1.3
Creating value with NFC
These different elements of an NFC system provide numerous options to create value
for consumers and businesses, for both those providing NFC platforms and secure
elements and for their customers the banks, retailers, brands, transportation
operators and other service providers who wish to offer NFC services to consumers.
How the different NFC elements available are mixed and matched with each other,
as well as how they are combined with both existing services and with other new and
existing technologies, also provide numerous ways for one company to differentiate
its products and services from another
Page 29
Introduction
Key to gaining maximum advantage is to remember that NFC is an enabling

technology. Creating value with NFC is not about providing an NFC service. Rather,
it is about using NFC alongside other business assets to provide services that are not
available in any other way.
This report is designed to provide executives seeking to discover how NFC can benefit
their business with the technical knowledge needed to understand how NFC works,
what the different options available are and where the potential to create value lies.
Chapter 2 of this report examines NFC pairing and sharing applications, looking indepth at the types of NFC tag available, the standards that ensure tags can be written
to and read by any NFC device and how data can be shared between two different
NFC devices.
Many NFC applications can be created without needing to take advantage of NFCs
ability to store data in a highly secure manner. The ability to store sensitive data in
an NFC phone, however, opens up a realm of possibilities. An understanding of how
NFC secure elements work is critical to understanding the full potential of NFC and
this subject is covered in depth in Chapter 3.
How secure elements are built into NFC phones along with the other new elements
required to add functionality to mobile phones and other devices is covered in
Chapter 4, along with details of alternative methods of adding NFC to existing
phones.
Chapter 5 examines the back office systems and processes that need to be put in place
to deliver compelling user experiences, including the different ways in which NFC
services can be promoted to consumers and the methods that have been developed
for sharing winning customer service between mobile network operators and service
providers.
The research carried out for this report fundamentally changed our understanding of
the potential of NFC. We hope it will change yours too.
Page 30
NFC pairing and sharing
NFC devices use a set of specifications and application programming interfaces

(APIs) set out by the NFC Forum, by providers of NFC-enabled mobile phone
operating systems, and by NFC infrastructure managers to read and write to a wide
range of NFC tags as well as to exchange information between two NFC devices in a
standard manner.
These specifications and APIs are designed to provide application developers with the
means to build NFC pairing and sharing capabilities into their programs, making it
possible for businesses to provide applications to their customers that will work in a
predictable manner with any NFC device and with any type of NFC tag.
The NFC Forum specifications cover NFC tags, NFC devices and a set of core NFC
commands that are used to write to NFC tags. Together with APIs provided by
mobile operating system providers and specifications set by individual infrastructure
managers, they provide programmers with a set of rules and programming tools they
can use to develop applications that will work reliably on multiple operating systems,
multiple mobile phone models and multiple types of NFC tag.
This chapter explains the types of NFC tag that are available on the market today, as
well as the NFC tag types that are expected to arrive on the market in the future. It
explains how NFC data is formatted to ensure it can be exchanged between any NFC
device and any NFC tag as well as how it is formatted and exchanged between two
NFC devices. This chapter also explains the tools available to developers wishing to
include NFC functionality in their programs.
Page 31
2.1
NFC tags
NFC tags conform to international RFID or contactless card standards and work
without a battery or any other power supply. They are low cost (currently less than
US$0.50 when purchased in volume) and have a long lifespan.
Each tag contains a radio frequency antenna usually a simple loop or coil of copper
wire and a tiny silicon chip. Tags remain in a passive state, using no power, until
an NFC device is brought into close proximity. The NFC device then powers up the
tag so that the data stored on the tag can be read by the NFC device. This means that
NFC tags can be widely distributed without the need to provide ongoing maintenance
or support.
NFC tags typically come with a chip and an antenna which are mounted on a
substrate known as an inlay. This unit is then incorporated into a square, oblong or
circular package measuring as little as 15mm across. The tags are ready for printing
on, attaching to, or embedding in everyday objects. In a smart poster, for instance, the
tag is either placed behind the printed, front side of the poster or between the front
and a backing material. The artwork on the front of the poster is then used to indicate
to the consumer where to touch the NFC device to read the tag.
NFC tags can be affixed to, or embedded in, a variety of other materials and locations.
Possibilities include in-store product labels, security control points, and business
assets. As lower-cost printed RFID tag technology becomes widely available in the
next few years, NFC tags are ultimately expected to be found printed onto everything
from cereal boxes and cleaning products to product catalogues and business cards.
2.1.1
The four NFC Forum tag types
To help ensure that there is an open market for NFC tags, the NFC Forum has
selected four tag types and specified that NFC devices must be capable of reading and
writing to each of these four types. This requirement is designed to provide a basis for
interoperability between NFC tag providers and NFC device manufacturers, in order
to promote a uniform user experience.
The four tags are based on existing, commercially available products that come in
a range of shapes and sizes and in a variety of formats, including a traditional card
shape, as well as round, square and oblong stickers.
Page 32
All four tags are of the passive variety of RFID tag, meaning that they do not have
their own power supply. Instead, power is supplied to them as needed by the tag
reader in this instance, the NFC device. This means that they do not need to
include a battery, enabling them to be produced inexpensively and to have a long life
in the field.
Type 1 tags are based on technology developed by Innovision Research & Technology,
now part of Broadcom. These Topaz tags have a memory capacity of either 96Bytes or
512Bytes and conform to the ISO/IEC 14443A international standard for contactless
cards. Topaz tags can be configured to be read only or to be both read and written to
by an NFC device. They have a data transfer rate of 106Kbps.
Type 2 tags are based on NXPs Mifare technology. They also conform to ISO/IEC
14443A and can be configured to be either read only or read/write. They have a data
transfer rate of 106Kbps and are available with memory capacities of between 48Bytes
and 2KBytes.
Type 3 tags are based on Sonys FeliCa technology. They are preconfigured during
manufacturing to be either read only or read/write and have a faster data transfer rate
of either 212Kbps or 424Kbps.
Type 4 tags are based on ISO standards rather than on proprietary technology and
are available for any company to implement without license fees. They may be either
ISO/IEC 14443 Type A or Type B and can be implemented on standard smart cards.
Type 4 tags are preconfigured during manufacturing to be either read only or read/
write. They are available from a number of manufacturers and in a range of tag sizes,
memory capacities, data transfer capabilities and security technologies.
2.1.2
Emerging tag types
Beyond the four NFC Forum tag types and their traditional card and sticker
formats, a number of innovations are under way with the aim of widening the
potential use cases for NFC tags and reducing their costs. These innovations are
grouped into four main categories: cheaper production technologies, new tag formats,
non-standard chip types and dynamic tags.
2.1.2.1
Cheaper production technologies
New ways of manufacturing standard NFC tags hold the promise of cutting the
current cost of individual tags by a factor of ten. The ultimate goal is to enable NFC
Page 33
tags to be produced cheaply enough that they can be incorporated into every day
consumer products such as cereal boxes, toothpaste tubes and more. The main focus
currently is on developing ways to print an NFC antenna directly onto items such as
product packaging or to electroplate an antenna directly on to the individual pads of
an RFID chip, removing the need to separately assemble the individual elements of an
NFC tag.
2.1.2.2
New tag formats
Current NFC tags are produced as individual packages that can then be attached to
or built into items such as business cards and smart posters. In the future, demand
for NFC tags is expected to go beyond printed products to include markets where
this kind of packaging is unsuited. Scientists are now working on a range of ways
to incorporate an NFC antenna into alternative types of products by, for example,
weaving the copper wire used to make an antenna into fabrics and other flexible
materials during their manufacture.
2.1.2.3
Non-standard chips
Demand is also emerging for solutions that will allow NFC phones to interact with
other types of chip which operate at a frequency of 13.56MHz but are not included
in the four NFC Forum tag types. One particularly major potential market that
this could open up is in the field of healthcare, where NFC phones could be used to
interrogate diagnostic sensors.
2.1.2.4
Dynamic tags
The NFC Forum standard tag types are designed to work without a battery, providing
the benefit of a long lifespan without the cost or need for their own power supply. In
certain markets, however, the inclusion of a battery and/or access to a power supply
has advantages. A number of companies have now developed dynamic NFC tags
that can be built into devices such as weighing scales, smart meters and temperature
monitors to allow a live reading to be captured and transferred to an NFC device.
Here, the advantage lies with the elimination of the need to purchase a dedicated,
specialist reading device as all the user needs in order to collect data is a standard
NFC phone.
Page 34
2.2
Writing to NFC tags and cards
NFC devices can write new or updated information to any NFC tag or contactless
card, provided the tag has been configured by the issuer to permit writing. NFC
devices typically ship with easy-to-use tag writing software as well as a number of
blank tags. This allows even non-technical consumers to write data to their tags and
program them to perform an instruction.
A number of commercial NFC tag writing programs are also available, either as
standalone solutions or as modules within mainstream application programming
tools used by mobile app developers.
Simple applications include writing a contacts phone number to a tag or storing a
local WiFi passcode. Some tags can be written to multiple times, offering the option
to replace the data with new information at a later date. Alternatively, the tag can be
programmed so that it will work in read-only mode once data has been written to it.
NFC tags can also be written to in volume, where widespread distribution of tags
is required for smart posters, marketing campaigns and information services
applications. For low to medium volumes, tag writing can be performed in-house
using NFC reader/writers which can be attached to standard PCs as a peripheral.
For both short runs and large volumes, tags can also be bought in from NFC tag
suppliers and specialist printers, both preprogrammed and custom printed to the
buyers requirements. Customers simply provide the information they wish to
have stored on the tag and they are then delivered formatted according to industry
standards and printed as specified.
Tracking codes can also be applied to URLs stored in NFC tags, allowing the issuer to
track where and when a tag is read.
2.2.1
NFC tag data formats
The NFC Forum has produced a series of technical specifications that set out the
ways in which communications between an NFC device and an NFC tag should be
handled. They specify how information should be exchanged between an NFC device
and tag and how information can be stored in a tag to ensure that it can be read by
any NFC device.
Individual NFC devices as well as high volume tag programming systems use the
NDEF (NFC Data Exchange Format) specification set by the NFC Forum to write
Page 35
to an NFC tag. NDEF, along with the NFC Forums RTD (Record Type Definition)
specification, enables information stored on a compatible tag to be transferred to an
NFC device in industry-standard formats. The standards also specify how to enable
tags to deliver instructions to an NFC device so that the device will perform a specific
action when a particular tag is read.
Standards have also been specified for how web addresses should be stored in an NFC
tag, how smart posters should be designed to allow promotional information to be
collected in a standard manner and how security can be implemented to avoid the
risk of NFC tags being tampered with in the field.
2.2.1.1
The NFC Data Exchange Format (NDEF) specification
The NFC Forums NFC Data Exchange Format (NDEF) technical specification sets
out a common data format for information stored in NFC tags and NFC devices. The
NDEF specification provides rules for constructing a valid NDEF message so that
information can be exchanged in a standard manner between two NFC devices, or
between an NFC device and an NFC tag.
The common data format defined by the NDEF specification allows both consumers
and businesses to customize NFC tags to their own requirements. For instance,
a particular tag can be used to store an individuals contact details or a link to a
particular website.
NDEF messages are designed to enable one or more payloads of data to be
exchanged between two devices or a device and a tag. Each NDEF message comprises
a single or multiple NDEF records. The first record in a message is marked with an
MB (Message Begin) flag and the last record in the message is marked with an ME
(Message End) flag.
Each NDEF record contains its payload of information as well as an optional payload
type identifier, a payload length descriptor and an optional payload identifier:
The payload type identifier indicates the type of information that will be written
to the tag. It can be set to identify the payload as a Universal Resource Identifier
(URI) such as a website address, a MIME media type or an NFC-specific payload
type which is used only for NFC applications. MIME media type formats enable
a wide range of data types to be stored in a standard manner. They include audio,
graphical and video content such as jpeg and mpeg files, as well as standardised
formats for contact data exchange such as vCard for business card details, vTodo
for tasks and vEvent for calendar information.
Page 36
The payload length provides the reading device with information on the amount
of data the payload contains.
The payload identifier is used when multiple NDEF records are contained in
a single NDEF message. It is optional and, where used, enables the multiple
payloads to be associated and cross-referenced.
2.2.1.2
The NFC Record Type Definition (RTD) specification
The NFC Forums NFC Record Type Definition (RTD) technical specification
provides detailed guidelines for identifying NFC-specific types of information that
will be stored in an NDEF record.
Each NDEF record contains a record type string field that contains the name of the
record type. These record type names can be specified in several formats, known as
Type Name Formats (TNFs). Options include MIME media types and URIs as well as
two NFC-specific Type Name Formats. These TNFs are used in cases where there are
no existing standards for referring to the type of information stored in a tag or where
message size limitations mean a very short name is required. These two NFC-specific
TNFs are:
Well-known NFC type names, called Record Type Definitions (RTDs).
External type names that can be defined by third parties. These enable
organizations to self-allocate a name space to use for their own purposes. This
allows the potential use cases for NFC tag reading and writing to be widened
beyond the use cases originally imagined by those involved in creating the RTD
specification.
2.2.1.3
The URI Record Type Definition specification
The NFC Forums URI Service RTD technical specification sets out the way in which
a URI, such as a website address, should be stored within an NFC tag or device in
NDEF record format, allowing the URI to be retrieved by any NFC standard device.
The URI Record Type allows the amount of data that needs to be stored on a tag to
be reduced by using standardized address shorteners. Programmers first define the
record type as a URI Record Type by entering u as the well-known type name. The
website or other URI to which a reading device should be directed is then shortened
by using one of a series of shorteners that enable frequently used subsets of a URI
such as http://www. and https://www. to be replaced with single digit alternatives.
Page 37
2.2.1.4
The Text Record Type Definition specification
The NFC Forums Text Record Type Definition (RTD) technical specification sets out
the way in which a free form text description of the data stored on an NFC tag can
be included in an NDEF record, using an NFC Forum well-known type for plain text
data.
2.2.1.5
The Generic Control Record Type Definition specification
The Generic Control Record Type Definition (RTD) specification is designed to

enable the widest possible range of functions supported by an NFC device to be
activated when a tag is read. This specification enables developers to use NFC tag
reading to initiate actions that fall outside standardized instructions and minimizes
the need for new external record types to be created for specialist functions.
The Generic Control RTD specification extends the potential use cases for NFC tag
reading beyond actions such as mailto: and other standard instruction formats. For
example, it could be used to add a number of points to a loyalty application when a
consumer checks into a store or to switch the phone into silent mode when entering a
movie theatre.
This specification also enables multiple actions to be initiated via a single tag read.
Reading a tag can, for instance, initiate a check to see if the relevant application is
already stored in the phone, download the app if it is not already present and then
perform the desired action.
2.2.1.6
The Smart Poster Record Type Definition specification
The NFC Forums Smart Poster Record Type Definition (RTD) technical specification
defines an NFC Forum well-known type for storing URLs, SMS numbers and/or
phone numbers on an NFC Forum tag and for transferring this kind of information
between two devices.
The smart poster RTD builds on the URI Service RTD to provide a way to convey to a
reading device:
The website address or telephone number stored in the tag.
The action that the device should take once it has obtained the website address,
telephone number or other information stored in the tag.
Page 38
The Smart Poster RTD sets out the way in which a tag built into a smart poster should
be programmed so that the smart posters payload is an NDEF message which can
consist of several NDEF records. Under the Smart Poster RTD specification, each
smart poster can have none, one, or more than one of the following components:
An optional Title record for the service, stored according to the requirements of
the Text RTD.
A URI record that forms the core of the smart poster. Each smart poster tag must
contain one, and no more than one, URI.
An optional Action record that describes the action that should take place when
the URI record is read, such as send a text to the stored SMS number or open
a browser and go to the URI. The specification allows this to be set so that the
device can perform the action immediately, save it for later, or open the content
for editing. For example, the device may immediately perform an action, such as
visiting a website, instantly transferring the URI from the poster to the devices
memory. Alternatively, it may instead save the information to be used later or
open the information on the device for editing.
An optional Icon record that enables an icon or other image to be stored in a
standard MIME format, such as a jpeg image, so that it can be retrieved from the
tag by an NFC device and displayed to the user.
An optional Size record that can be used by the reading device to decide if it has
the capacity to process the object referenced by the smart poster, such as whether
it has the memory available to download and store a new NFC application.
An optional Type record that can be used to tell the reading device what kind of
object it can expect to receive before it opens a connection, to avoid downloading
an object it does not have the capability to handle.
The specification also allows for other records, such as a vCard contact card and other
MIME types, to be included in a smart poster, as required.
2.2.1.7
The Signature Record Type Definition specification
NFC tags are expected to be placed in stores, at bus stops and in traditional
advertising poster locations where it is not possible to monitor the tags for signs of
tampering. This raises the concern that fraudsters could be able to reprogram the
tags or replace the tag in a poster with a new tag that delivers a different, and possibly
malevolent, instruction to NFC devices that read it.
Page 39
The NFC Forum developed the Signature RTD specification to provide a way for an
NFC device to be able to validate the authenticity and integrity of data stored within
an NDEF message of a tag and ensure that the data stored on it has not been changed
before any of the information stored on the tag is acted upon. The specification sets
out the format to be used when digitally signing single or multiple NDEF records and
also provides details of digital signature algorithms and certificate types, such as RSA
and DES algorithms, that can be used to provide proof to the reading device that an
NFC tag has not been tampered with.
2.3
Peer-to-peer mode
In peer-to-peer (P2P) mode, two NFC-enabled devices can exchange data with each
other in a standard manner, using standard communications modes developed by the
NFC Forum.
P2P mode is currently used primarily to exchange data between two NFC phones. It
can also be used to exchange data between an NFC phone and a second type of NFCequipped device or between two non-mobile NFC devices, enabling a wide range of
use cases for P2P mode to be developed.
All NFC phones have the ability to initiate and manage a peer-to-peer information
exchange, provided the necessary firmware has been provided by the manufacturer.
This section explains how P2P mode works and how it can be used to enable
innovative NFC applications.
2.3.1
The Logical Link Control Protocol (LLCP)
The NFC Forums Logical Link Control Protocol (LLCP) enables two devices to begin
exchanging information more quickly and easily than technologies such as Bluetooth
because no user input is required. The two devices simply need to be brought into
close proximity with each other for a connection to be made.
When two devices exchange information using P2P mode, the connection between
them is set up on a master and slave basis: One of the NFC devices, known as the
initiator, is the master device in charge of an individual P2P data exchange while the
second device takes on a secondary role as the target device.
NFC devices are usually in target mode. Periodically, however, a device switches
into initiator mode and scans (polls) the environment for NFC targets. If no targets
Page 40
are found, the device falls back into target mode. If the device finds a target while in
initiator mode, it submits an initiation sequence to establish the communication and
then starts exchanging data.
P2P NFC communication shares similarities with NFC tag reading, where the NFC
device is the initiator and the tag is the target. The two NFC devices communicating
using P2P mode, however, are both intelligent devices and LLCP takes advantage of
that by providing for a two-way exchange of information to be established.
In P2P mode, information can also be exchanged simultaneously so that, for instance,
two new acquaintances can exchange their contact details with each other at the same
time or a coupon can be issued by a POS terminal to a customer at the same time as
card details are being transmitted from a phone to a merchant terminal.
2.3.2
The Connection Handover Protocol (CHP)
NFC makes it easy for two devices to pair with each other in order to exchange
information, but NFC data transfer rates are significantly slower than technologies
like Bluetooth and WiFi.
When large quantities of data such as video content or a mobile app need to
be exchanged, therefore, NFC is used in conjunction with a second, faster
communications technology. This allows the ease of pairing provided by NFC to be
combined with the higher data transfer rates provided by technologies like Bluetooth
and emerging solutions like Sonys TransferJet to enable information to be transferred
both easily and quickly.
The NFC Forums Connection Handover Protocol (CHP) sets out a standard way for
two NFC devices to establish a connection using NFC and then transfer data using
a higher speed communications technology. When two NFC devices are brought
together to exchange a large quantity of data, the Connection Handover Protocol is
used to:
Manage the initial set-up of the data exchange between the two devices
Enable the devices to discover which networking functions they both have
Enable the devices to choose the networking solution best suited for the transfer,
based on the highest speed communications technologies available to both
devices
Page 41
2.3.3
The Simple NDEF Exchange Protocol (SNEP)
The Simple NDEF Exchange Protocol (SNEP), developed by the NFC Forum, sets out
a standard format for packaging data which is to be transferred between two NFC
devices operating in peer-to-peer mode.
SNEP builds on both the Logical Link Control Protocol and the existing NDEF
commands used in NFC tag writing so that data can be packaged in the same way
for transfer between any NFC tag and any NFC device, as well as between two
NFC devices. This gives developers one standard method for packaging NFC data,
regardless of whether it is to be transferred from a tag or an NFC device, and extends
NFC standardisation in three key ways:
Standardised, simplified transfer of contact information. An NFC phone can be
configured to automatically send business card information when an NFC peerto-peer connection is established. The recipient doesnt have to do anything other
than to accept the business card and allow it to be entered into his phone book.
Collecting information and promotional coupons for later use. A consumer could
get a link to a movie trailer from an NFC tag on, say, a smart poster. When they
get home, they could watch the trailer on their TV by simply tapping their phone
to an NFC-enabled TV remote control.
Viral transfer of information. Because the same format is used for both tag
reading/writing and peer-to-peer, information collected from an NFC tag can
also be exchanged with other NFC phones. A coupon, special offer, or links
to promotional trailers, games or other marketing material stored on a smart
poster could therefore be passed virally from one consumer to another by simply
touching their two phones together.
2.4
Sharing and pairing apps
To write NFC applications, software developers need a set of tools that let them
incorporate interactions with a phones NFC interface into their programs.
NFC sharing and pairing applications do not need to have access to the phones
secure element, so applications of this type can be executed entirely on the phones
application processor, in the same way that other non-NFC apps are handled. Since
no access to the secure element is required, software developers also dont need any
special permissions in order to write NFC apps of this type. Access to programming
Page 42
tools can be provided to any developer interested in writing NFC apps and completed
programs can be simply uploaded to an app store for any NFC phone user to
download and use.
Applications for feature phones, and other phones providing a Java Runtime
Environment, are able to make use of the long-established JSR 257 Contactless
Communications API (see sjb.co.uk/6ww) as a standard means for incorporating calls
to and from the phones NFC interface. Smartphone operating system providers, on
the other hand, need to provide NFC APIs which are specific to that operating system
before developers can begin developing NFC apps.
2.4.1
The JSR 257 Contactless Communications API
NFC applications for feature phones and low end phones that operate under a Java
Runtime Environment are written in Java ME, a version of the widely used Java
programming language specifically designed for embedded systems such as mobile
phones. Once code has been written, it is packaged into a standard format Midlet
suite for distribution to mobile phones over-the-air, via a download from an app
store.
Java ME includes a wide array of Java Specification Requests (JSRs) that provide a
standard way for programmers to call on particular mobile phone features. JSR 82,
for example, provides programmers with the ability to call on a phones Bluetooth
features. JSR 257, also referred to as the Contactless Communications API, builds on
the NFC Forums tag reading and writing specifications to provide programmers with
a defined set of instructions they can use to write software applications that make use
of a devices NFC capabilities.
With JSR 257, programs can be written so that actions are automatically initiated
when an NFC tag is read, allowing the program to be launched automatically, for
example, when an NFC tag is read.
Because JSR 257 is designed for sharing and pairing applications, it cannot be used
to transmit sensitive information. It is used, however, in card transactions to start the
card issuers app on the handset when a consumer first touches their phone to a pointof-sale terminal, to allow the issuers logo to be displayed to the user.
Page 43
2.4.2
Smartphone apps
Each smartphone operating system provider develops a set of APIs that can be
used to write programs for that platform. They provide programmers with either a
software development kit (SDK) specifically designed for that operating system or a
programming toolbox that provides support for multiple operating systems.
Therefore, before programmers can write NFC pairing and sharing programs for
a particular mobile operating system, the developer of the OS must first provide
an equivalent to the JSR 257 Contactless Communications API for their operating
system. These are usually made available by the operating system provider either at
the same time that the first NFC device running that operating system is introduced,
or in advance of the introduction so that software can be developed and ready for use
on the day of launch.
APIs enabling developers to write programs that make use of a secure element are
also usually made available by operating system suppliers. Unlike pairing and sharing
APIs, however, access to secure element APIs is restricted and generally only available
on request.
Page 44
The secure element
The secure element
The secure element is the key to ensuring that sensitive data stored on an NFC phone,
such as a consumers credit card details, is kept safe from hackers and fraudsters.
Several different types of secure element can be used in a mobile phone, but they are
all based on the same highly secure smart card technology that is used in chip and
pin contactless payments cards, mobile phone subscriber identity modules (SIMs)
and a host of other secure applications.
Early NFC phones, as well as the phones used in the non-NFC standard mobile
contactless systems originally used in Japan and Korea, use an embedded secure
element a dedicated chip that is built into the device during manufacturing. In
2007, the GSMA the international association of mobile network operators (see
www.gsma.com) called for the development instead of mobile phones that use the
SIM as a secure element and, from then until 2010, the industry focused most of its
attention on the development of technology supporting the GSMAs requirements.
The use of an embedded secure element has now regained ground as handset
manufacturers and operating system suppliers have identified this route as a
way to enable them to create a value adding role for themselves within an NFC
infrastructure. Service providers, meanwhile, are examining the potential of a range
of products that enable NFC functionality to be retrofitted to existing mobile phones
and enable them to take charge of their own value added NFC services.
In terms of specifications, standards and systems design, work is most advanced on
the use of the SIM as the secure element. This chapter, therefore, looks first at NFC
SIMs, since this is where a standardized approach to NFC implementation in a mobile
phone is most developed. It then goes on to examine embedded secure elements and
to introduce the options available for adding external secure elements to standard
mobile phones.
Page 45
The secure element
3.1
What can be stored in a secure element?
Payment cards are the most obvious item that can be stored in an NFC secure
element, but this is just the tip of the iceberg in terms of the technologys potential.
In card emulation mode, NFC devices can act as a virtual version of any plastic card
that conforms to the core international standard for contactless smart cards, ISO/IEC
14443 A/B.
The ISO/IEC 14443 standard is used by not only Visa and MasterCard for their
PayWave and PayPass contactless payments cards but also by the widely used Mifare
transport ticketing system and a range of other contactless card applications around
the world.
All ISO/IEC 14443 cards use the 13.56MHz frequency, but there are variations in the
way in which they actually communicate. Known as ISO/IEC 14443 Type A and Type
B, NFC devices are expected to support both.
NFC devices can also provide support for Sonys FeliCa contactless card technology.
This technology is not included in the ISO/IEC 14443 standard but is sometimes
referred to as NFC-F or Type C and is widely used in Japan for both contactless card
payments and for mobile payments.
Support for cards conforming to the ISO/IEC 15693 vicinity card standard, enabling
NFC devices to emulate widely used contactless employee ID cards, is also now in the
process of being added to some NFC phones.
Beyond this, a wide range of other services that are not currently delivered via a
contactless card can take advantage of an NFC devices card emulation capabilities,
provided they are designed to conform to one of the supported card standards or
technologies. In this way, NFC phones can be used to emulate loyalty cards, library
cards, drivers licenses, airline tickets, online account credentials and, eventually, even
passports.
3.2
How secure elements keep sensitive data secure
The ability to use a consumers mobile phone to store a wide range of applications
from a variety of service providers is fundamental to the market potential of NFC
technology. At the same time, however, concerns raised by potential service providers
over how securely their customers data would be stored in a multi-application NFC
Page 46
The secure element
secure element have also proved to be a major stumbling block to the deployment of
the technology.
The technology on which secure elements are based is not new, however. Similar chips
have been used in secure smart cards deployed around the world for many years.
The security of stored data is at the heart of smart card technology. Strict guidelines
and regulations have been put in place by both global and specialist standards bodies
which cover every aspect of smart card production, personalization and distribution
as well as for the way in which they interact with equipment such as point-of-sale
terminals, ticketing machines and access control devices.
Information stored in a smart card chips memory may only be accessed if the
chips microprocessor is first assured that the device requesting the information has
the proper authority to do so. This microprocessor therefore acts as a intelligent
gatekeeper. It authenticates every request for information, ensuring that only the
minimum amount of data required to perform a transaction or other operation is
ever divulged, that this data is not released until the identity of the source requesting
the data has been verified as a trusted source and that all data is encrypted before it is
sent.
This means that NFC secure elements are able to ensure that:
No information will be released until a device has proved that it is authorized
to receive it. And, for an NFC phone, this includes all other components of the
handset and its application processor.
Once a device has proved it is authorized to receive data, all information sent
between a secure element and a terminal, device or back office platform will only
be communicated in an encrypted format.
Smart cards come in a variety of different formats and vary in the level of security
that they are able to provide. At one end of the scale, simple smart cards that do
not include a microprocessor are widely used for applications such as transport
ticketing. At the other end of the scale, the most sophisticated smart cards include
cryptographic processors that can create digital signatures. These are used to sign
each transaction and to encrypt data using public key cryptography methods that
meet the requirements of even the most sensitive military applications.
These smart cards are also able to handle multiple applications delivered by one card
issuer and multiple applications issued by a number of different businesses, with each
Page 47
The secure element
organisations applications stored securely in their own, independent area of the cards
memory.
Smart cards also come with different types of communications interfaces. Contact
smart cards, such as those used in EMV chip and pin bank cards, have physical
contacts on the surface of the card. When the card is inserted in a reader, the contacts
establish a connection between the card and the reader so that data can be exchanged
between the two.
Contactless cards, and the terminals capable of reading them, replace these contacts
with an antenna that generates a magnetic field when the card is brought into close
proximity with the reader so that data can be exchanged wirelessly between them.
Smart card technology is also at the heart of the SIMs (Subscriber Identity Modules)
issued by the majority of the worlds mobile network operators to their customers.
SIMs are used to provide a link between the subscriber and their mobile phone and,
thereby, to track usage of their mobile networks and generate accurate bills.
For a mobile phone to act as a replacement for a physical card, the issuer has to be
fully confident that the personal information stored in the phones secure element will
be stored as securely as if it was stored on a smart card. They also need to be assured
that, whenever the phone is used to make a card transaction, for example, the data
exchanged between the phone and the reader is managed to the same high level of
security that is required for exchanges between a card and a reader.
The secure elements used to enable a mobile phone to handle NFC transactions,
therefore, use top of the range multi-application smart card microprocessors to enable
the maximum levels of security to be maintained.
NFC secure elements are designed to enable a complete end-to-end security solution
to be implemented. They ensure that the information stored in each service providers
supplementary security domain cannot be accessed by other service providers or by
the mobile network operator which issued it. Only the minimum amount of personal
data is ever revealed, therefore. When confidential information such as a customers
credit card account details does need to be shared, all communications use secure
routes and employ the latest encryption standards.
Page 48
The secure element
3.3
Secure element certification
Issuers of high-security credentials like bank cards, door keys, and corporate ID
credentials are not generally willing to accept that NFC secure elements offer
sufficient security without having proof.
Before they can be used to store secure NFC data, therefore, NFC secure elements
must undergo extensive testing to ensure that they meet all necessary security
requirements.
The responsibility for setting core secure element security specifications lies
with GlobalPlatform (see www.globalplatform.org), an international smart
card specifications body whose technical specifications for cards, devices and
systems are used in more than 300 million smart cards and over two billion SIM
cards. GlobalPlatform members include mobile network operators and handset
manufacturers as well as the major payments networks.
GlobalPlatforms specifications have been adopted by the mobile network operators
managing the French Cityzi project (see www.afscm.org). It also has reciprocal
agreements in place with a number of other standards bodies and associations
including the NFC Forum, the GSM Association (see www.gsma.com) and EMVCo, the
organisation responsible for chip and pin payment card standards (see www.emvco.org).
3.4
The SIM as secure element
A Subscriber Identity Module, known officially as a UICC (Universal Integrated

Circuit Card) in 3G phone networks, is the most common way of identifying mobile
phone subscribers in GSM and 3G mobile networks. Over two billion of them have
been issued to date by mobile network operators around the world. Versions of GSM
standard SIMs are also used in some CDMA mobile networks, although in others the
subscriber identity function is tied permanently to a particular phone by embedding
it into the device during manufacturing.
Both standard and NFC SIMs are based on smart card technology but use a smaller
footprint than a standard smart card. They are designed to be issued by a mobile
network operator and then inserted into a customers mobile device to enable the
operator to establish a link between each individual customer and their preferred
choice of handset.
Page 49
The secure element
Each SIM has its own unique serial number, known as an Integrated Circuit Card
Identifier (ICC-ID) and contains a unique International Mobile Subscriber Identity
(IMSI) number, tied to the users phone number, technically known as an MSISDN.
These unique reference numbers are used to identify which customer is making
or receiving a mobile phone call, accessing the mobile internet or performing any
other form of chargeable operation. This information is then used to generate the
customers phone bill or deduct funds accurately from a prepaid account balance.
Because the SIM is central to the mobile network operators ability to bill its
customers for usage of the mobile network, security is a key requirement. SIMs are
based on smart card technology that has been tailored to the specific needs of mobile
network operators. These include features that are used to create core building blocks
of NFC service provision including:
The ability to update the content of the SIM over-the-air (OTA) via the mobile
network after it has been issued to a customer.
A user interface that enables the subscriber to access data stored on the SIM, such
as the contents of an address book, and to display the information on the screen
of the mobile phone.
The creation of a secure communications channel between the SIM and the
mobile phones main baseband processor, which ensures that any sensitive data
sent to or from the SIM is encrypted and secured against tampering.
Phones equipped to handle NFC functions require a specialist SIM designed
specifically to handle the needs of NFC services. These NFC SIMs handle all the
standard functionality of a traditional SIM and also contain a completely separate
area used only for NFC applications.
Within this separate NFC area on the SIM, service providers such as banks, transit
operators, retailers and others can be issued with their own private area, known as a
Supplementary Security Domain (SSD). Each SSD is protected by its own set of keys
and is separated by a firewall from all other areas of the SIM.
3.4.1
The three parties on an NFC SIM
A critical component in the design of GlobalPlatforms specifications is the

requirement for an independent third party, known as a Confidential Key Loading
Authority (CKLA), to have a presence on each NFC SIM. This allows the keys to a
domain to be loaded in a confidential manner and can be used to both minimize the
Page 50
The secure element
level of control that the mobile network operator has over the NFC portion of the
SIM and maximise the independence of each service provider.
NFC SIMs, therefore, are designed to include three separate areas one for
the mobile network operator, known as the Issuer Security Domain, one for the
Confidential Key Loading Authority (known as the Controlling Authority Security
Domain) and one that is set up to allow a number of service providers to have their
own Supplementary Security Domains.
3.4.1.1
The mobile network operator
The Issuer Security Domain (ISD) is used by the mobile network operator and/
or their appointed trusted service manager (TSM) to manage the SIMs over-theair (OTA) provisioning capabilities, to facilitate the creation and assignment of
Supplementary Security Domains and to provide overall management of the SIMs
functions. The Issuer Security Domain has a number of unique privileges and
responsibilities, tied to the fact that the mobile network operator is the issuer of the
SIM.
They include:
The sole ability to create, or authorize the creation of, Supplementary Security
Domains for service providers.
The ability to decide what rights a service provider will have over its domain,
based on the type of service agreement that has been signed between the two.
Options range from only limited rights to full autonomy over a domain and
depend on both the business relationship between the operator and the service
provider and on the level of involvement in the management of its domain that
the service provider wishes to have.
Responsibility for managing the overall mapping of the memory allocation on the
SIM, enabling it to keep track of how much free memory remains on the SIM and
perform checks to make sure that there is sufficient memory on a SIM before an
application is downloaded to it.
3.4.1.2
The Confidential Key Loading Authority
Fundamental to the concept of an NFC SIM is that, like in an apartment block, access
to each service providers Supplementary Security Domain is secured by its own set
Page 51
The secure element
of keys and that the landlord in this case the mobile network operator does not
have access to those keys.
Ensuring that the keys to each domain are issued and managed in a totally
secure manner is a core function defined in GlobalPlatforms NFC specifications.
GlobalPlatform has set out a precise methodology for how the keys to each
domain should be created and then distributed to the service provider, or to the
Supplementary Security Domain Manager (SSD Manager) acting on its behalf. This
methodology ensures that, once a Supplementary Security Domain has been created
for a service provider, the mobile network operator will have no way of gaining access
to it.
This level of confidentiality is made possible by the inclusion within each NFC SIM
of a separate security domain which is outside the control of the mobile network
operator. This separate domain is known as the Controlling Authority Security
Domain and is managed by an independent third party known as a Confidential Key
Loading Authority (CKLA).
GlobalPlatform requires this third party to be independent of the mobile network
operator and all the service providers that may wish to use the SIM to offer NFC
services to their customers. The role is, therefore, most likely to be carried out by the
SIM manufacturer or by a technology provider acting in the role of Trusted Service
Manager (TSM) on behalf of the mobile network operator.
During manufacturing, the Confidential Key Loading Authority creates a set of seed
keys which it uses to prime the SIMs cryptographic processor and provide it with
the ability to automatically generate new keys to the doors of new Supplementary
Security Domains as they are required.
When a service provider enters a request to create a domain on a particular SIM for
the first time, keys to that domain are delivered to the service provider using a highly
secure, fully encrypted and internationally standardized key distribution process. For
additional security, on receipt of the keys, the service provider can then use these keys
to change the locks to its domain and generate a new set of keys that no-one else has
ever had access to.
3.4.1.3
The Supplementary Security Domain (SSD) owners
A Supplementary Security Domain can house one NFC application issued by

an organisation, such as a transport ticketing application for a particular public
transport operator or a customer loyalty programme for a particular retailer. Or, a
Page 52
The secure element
Supplementary Security Domain can house several applications issued by one service
provider. For example, a credit, debit and prepaid card account issued by the same
bank can share one Supplementary Security Domain, so that the bank doesnt need
separate domains requiring separate sets of keys to handle each of its applications.
A number of sub-domains can also be created within each Supplementary Security
Domain. Each of these sub-domains can also be secured with its own set of keys,
enabling a mobile network operator or other business entity to use its Supplementary
Security Domain to provide managed NFC services to service providers who do not
need or want to get involved in managing their own domain.
3.4.2
Types of Supplementary Security Domain owners
3.4.2.1
Mobile network operators
A mobile network operator issuing NFC SIMs is not required to own any of the
Supplementary Security Domains itself. It may, however, choose to take ownership
of one or more of the available domains in order to provide NFC services to its
own customers. It can then offer managed NFC services to other service providers,
providing them with their own sub-domain within the operators own Supplementary
Security Domain.
Each of these sub-domains can be secured with its own set of keys, which only the
service provider will have access to. In this scenario, however, there are a number of
restrictions that service providers will need to consider:
With an individually owned Supplementary Security Domain, service providers
have the option of excluding the mobile network operator entirely from the key
distribution process so that the operator never has access to the keys, even in
encrypted form, at any point. With a sub-domain, the mobile network operator
or their appointed Trusted Service Manager will be involved in the creation
and distribution of the keys albeit in a way that ensures the keys are always
encrypted and the operator does not ever get to see them unencrypted (in the
clear).
As the manager of the Supplementary Security Domain, the mobile network
operator retains a number of rights over the sub-domains which it does not have
over independent sub-domains. These include the ability to block or unblock
access to the whole of the Supplementary Security Domain.
Page 53
The secure element
There are also advantages to this approach for the service provider. Both up-front
investment costs and on-going ownership will be lower than if the service provider
was to take ownership of its own Supplementary Security Domain. For instance, the
mobile network operator would take responsibility for loading an application onto a
consumers SIM and for delivering the key to the domain to the service provider (or,
in a fully managed service, would retain this in order to manage the service on the
providers behalf). This would free the service provider from the investment required
to perform this process itself.
3.4.2.2
Mobile virtual network operators (MVNOs)
A mobile virtual network operator (MVNO), which provides mobile network services
to customers under its own brand name via a wholesale arrangement with a licensed
mobile operator, is also able to provide NFC services to consumers and service
providers. The way in which this is done will not always be the same, however, since
MVNO arrangements are often set up so that the mobile network operator retains a
SIM management role. In these instances, the mobile network operator would own
the Issuer Security Domain and the MVNO would use a Supplementary Security
Domain to offer its own or third party NFC services to its customers.
3.4.2.3
Third parties
As well as supplying Supplementary Security Domains to individual service

providers, mobile network operators can also assign the rights to a domain to a third
party who could then use the domain to offer managed NFC services to its own base
of service provider customers.
In this case, the third party would be responsible for distributing keys to each of its
customers sub-domains and for loading applications onto consumers SIMs. It would
retain overall management rights to the domain and would have the potential to offer
fully managed services to businesses, perhaps using a software-as-a-service (SaaS)
business model.
3.4.2.4
Service providers
An individual service provider wishing to have maximum control over its NFC
service can choose to take ownership of its own Supplementary Security Domain
within a SIM. This route offers a service provider the greatest level of autonomy,
although the mobile network operator still holds the master keys to the SIM. It offers
Page 54
The secure element
the service provider three options for handling the delivery of keys to its domain and
loading a new application onto a SIM, known as Simple Mode, Delegated Mode and
Authorized Mode.
3.4.3
Creating a supplementary security domain
Three options are available to service providers who wish to own a Supplementary
Security Domain on an NFC SIM. SSDs can be created in the secure element at the
factory during the manufacturing process. They can also be created over-the-air, as
required, after the secure element has been issued to a consumer. A mixture of the
two options can also be adopted, allowing the service provider to have part of the
workload performed at the factory and part at a later date.
3.4.3.1
Fully preloaded SSDs
In this instance, a Supplementary Security Domain is created for a particular service

provider at the factory during the secure element manufacturing process. The service
provider can also opt at this point to have its secure NFC application loaded into the
secure element at the same time. The service provider can also choose at this point to
personalize the application with an individual customers data.
This option provides a solution which is closest to the way in which plastic cards are
produced today. It is therefore the easiest for a service provider to implement and
avoids the need to put systems in place to handle this process over-the-air.
3.4.3.2
SSDs created partially over-the-air
In a partial over-the-air (OTA) situation, the service providers secure NFC

application is pre-loaded onto the secure element in the factory.
The service provider can then opt to have the application stored from day one in
a separate Supplementary Security Domain. Alternatively, the application can be
stored in free memory controlled by the secure element issuer and only moved into a
Supplementary Security Domain if and when the end customer requests the service.
This means that the application does not need to be downloaded over-the-air when
a customer requests a service. Instead, when a customer does sign up, the service
provider only needs to personalize the application over-the-air, rather than also
having to send the application.
Page 55
The secure element
3.4.3.3
SSDs created fully over-the-air
With full OTA, all aspects of creating the Supplementary Security Domain,
downloading the application to the secure element and personalizing the application
to the end-user is performed over-the-air.
3.4.3.4
SSD creation modes
Three ways to manage the process of creating a Supplementary Security Domain have
been set down by GlobalPlatform, each of which offers different levels of control to
the service provider.
3.4.3.4.1
Simple Mode
In Simple Mode, the secure element issuer or its appointed TSM takes responsibility
for all aspects of installing a new NFC application on a customers mobile phone.
It also takes responsibility for either creating the Supplementary Security Domain
over-the-air or for activating an existing domain and handles all aspects of key
management, leaving the service provider responsible only for personalizing the
application with data such as credit card number and expiry date and for
receiving and then updating the keys to its new domain.
3.4.3.4.2
Delegated Mode
In both Delegated Mode and Authorized Mode, the service provider or its TSM
is able to perform the entire process of both creating a Supplementary Security
Domain and loading the application itself, rather than relying on the secure element
issuer to perform it.
In Authorized Mode, the service provider is able to perform this process without
reference to the secure element issuer. In Delegated Mode, however, although the
service provider has the right to load, install or delete an application itself, it must
obtain permission in advance from the secure element issuer each time it wishes to do
so.
Here, whenever the service provider receives a request from a customer to add an
NFC application to their mobile phone, it first contacts the secure element issuer
to request a set of tokens that it can use at each stage of the over-the-air application
loading process to prove to the secure element that it has permission to communicate
with it and to provide it with instructions.
Page 56
The secure element
When the secure element issuer receives a request from a service provider, it first
checks that the service provider is authorised to load an application in delegated
mode and that the application it wishes to load has been approved. It then sends
the service provider the set of tokens needed to install the application. The
service provider then, either at each stage of the process or when installation and
personalization is complete, notifies the secure element issuer of the actions it has
taken.
3.4.3.4.3
Authorized Mode
In Authorized Mode, the service provider is not required to request tokens from
the secure element issuer. Instead, it is provided in advance with the right to create
a Supplementary Security Domain, load/install an application and personalize it
without any reference to the secure element issuer.
3.4.4
Distributing the keys to the new domain
The ability to securely distribute the keys to a Supplementary Security Domain to

the service provider which owns it is a vitally important requirement of an NFC
infrastructure.
Several methods have been developed for the secure distribution of domain keys,
each of which depends on the way in which Supplementary Security Domains are
created and the stage at which that process is performed.
3.4.4.1
SSD created and assigned at the factory
Where a service provider and a secure element issuer have an on-going relationship
that will see all or most of an issuers secure elements being installed with a particular
service providers application, a Supplementary Security Domain can be created for a
service provider and an application can be pre-loaded and, even, personalized at
the factory.
Since the identity of the service provider who will own a particular domain is already
known at this stage, there is no need to transmit the service providers key over-theair. Instead, a specialist black box known as a Hardware Security Module (HSM),
managed by the service provider or its supplier, can be installed at the manufacturing
plant which can be linked to the service providers back office system either via a
Page 57
The secure element
secure communications link such as a virtual private network (VPN) or via a physical
data transfer technique.
3.4.4.2
SSD created at factory but not assigned
If the Supplementary Security Domains within the secure element are created during
manufacturing but not assigned to a particular service provider, temporary keys
to each domain are generated and loaded onto the SIM during the manufacturing
process. A copy of the keyset is then maintained in the Hardware Security Module at
the factory, ready to be transferred securely to the service provider who takes control
of that domain when the domain is assigned to it.
Once the service provider has received its temporary key to the door, it is then able
to communicate with the secure element and prove that it has the right to access
its particular domain. At that point, the service provider can then also change the
temporary key it has received to a new keyset of its own choosing.
3.4.4.3
SSD created over-the-air
When a Supplementary Security Domain is created in the field, the way in which the
key to the door of a new domain is handled depends on the mode being employed.
In Simple Mode, the secure element issuer is responsible for creating the domain,
assigning it to the service provider and loading the application onto the consumers
mobile phone. Here, the secure element issuer would retain responsibility for
managing the distribution of the key to the new domain to the service provider and,
once the application was live on the customers phone, would forward the key to the
service provider who could then change this temporary key to a new keyset that only
it had access to.
3.5
Embedded secure elements
Embedded secure elements share many of the same characteristics of an NFC SIM
and, in many cases, will even use the same secure smart card chip technology so
that, in terms of function and performance, they are essentially the same product.
Unlike an NFC SIM, however, they can be issued by handset manufacturers and other
entities, enabling other types of company to build a business around the supply of
services to third parties.
Page 58
The secure element
As explained above, an NFC secure element can include multiple security domains
with access to each secured by a set of keys known only to the owner of that domain.
But only one entity has access to the master keys that enable a domain to be created
for a service provider or third party supplier. With an NFC SIM, the mobile network
operator is in a default ownership position of the master keys since the SIM forms
part of its billing and relationship platform with its subscribers.
With an embedded NFC secure element, however, there is no default relationship
with the mobile network operator. This has the advantage of enabling the embedded
secure element issuer to create a direct relationship with the phone owner, provided
the mobile network operator supplying the device to the end user agrees to this
arrangement. It also requires that mechanisms be put in place to enable that direct
relationship to be created mechanisms that need to be built from the ground up.
3.6
External secure elements
As well as NFC SIMs and embedded secure elements, a third option is available which
allows a secure element to be housed within an external device.
Two approaches are being taken here. In the first, both an antenna and a secure
element are housed within the external device so that NFC functionality can be
retrofitted to existing mobile phones. In the second, a secure element housed within a
microSD device is inserted into an NFC phone that has its own built-in antenna. This
option reduces the cost of providing an external secure element while still allowing a
third party to own an NFC secure element.
The various ways in which NFC functionality can be added to mobile phones via
external secure elements are discussed in the following chapter.
3.7
Trusted Execution Environments (TEEs)
Current NFC systems are designed around the assumption that the mobile devices
baseband/application processor is a fundamentally insecure environment and that no
sensitive information should ever be made available to it in the clear.
As mobile devices become more sophisticated, however, and the range of ways in
which they are used has expanded, a growing need has been identified to provide a
secure environment within a phones application processor that can be used to store
Page 59
The secure element
sensitive information and to drive secure communications between the phone and,
say, the keypad and screen.
A number of proprietary methods of creating a trusted environment within a
mobile device have already been developed and, through the Trusted Computing
Groups Mobile Phone Work Group, work is under way on the development of an
internationally standardized approach (see www.trustedcomputinggroup.org).
Ultimately, it is hoped that this work will lead to the ability to build a secure element
into the main baseband/application processor itself or to design a separate secure
element that can be directly connected to the processor removing the need for a
separate embedded secure element within the mobile device.
As a first step along the way, a specification for the introduction of a Trusted
Execution Environment (TEE) was introduced by GlobalPlatform in August 2010.
This TEE is not yet suited to replacing the secure element itself, but it does enable a
secure area to be created within the application processor that can be used to store,
process and protect a range of sensitive information on the phones main processor.
For payments applications, for instance, the TEE enables solutions to be developed
that permit consumers to enter their PIN on their NFC phone rather than on a
point-of-sale device. In this case, a trusted user interface would be created that can be
used by a mobile payment application to display payment information in a trusted
window on the mobile devices screen. The consumer would then be able to input
their PIN using their phones keypad without compromising security.
Page 60
NFC Phones
NFC phones
NFC phones can operate in the three NFC modes and perform NFC functions
because they contain five elements that are not present on standard phones: a short
range radio frequency antenna, an NFC controller chip, an NFC protocol stack and,
usually, a secure element and a mobile wallet. These five elements are connected
by industry-approved secure communications channels to ensure that sensitive
information contained within the phone is kept secure.
The antenna provides the handset with its core contactless functionality and the
secure element provides a way to ensure that the users personal data is kept securely.
The NFC controller acts as the central switch for data sent and received via near field
communication. The controller is connected to the antenna, to the secure element
and to the phones main baseband processor. It works in conjunction with the NFC
protocol stack, to enable NFC application developers to build NFC functionality into
their software.
This chapter looks at each of these five elements, explaining how they work and how
they are integrated into a mobile phone to provide a secure environment in which
sensitive data can be safely stored. It also examines the wide range of external secure
element and antenna solutions that have been developed to enable NFC functionality
to be retrofitted to existing, standard mobile phones. Finally, this chapter also looks
at the NFC world beyond mobile phones at other types of business and consumer
electronics devices that also offer NFC functionality.
4.1
The antenna
The antenna provides NFC phones as well as RFID tags, contactless cards and
terminals with their ability to communicate with each other by simply bringing
Page 61
NFC Phones
one into close proximity with the other. At heart, an NFC antenna is quite simple.
Designing an NFC antenna for integration into a mobile phone, however, is a
complex process that requires a number of design constraints to be overcome in order
to achieve reliable performance.
An NFC antenna is a length of wire, usually made of copper, which is wound into a
coil or loop and then embedded into the phone. Near field communication is able to
take place whenever two NFC antennas are placed within centimetres of each other,
so long as one of the antennas has a power supply.
The antenna with a power supply is referred to as the primary coil. The second
antenna, known as the secondary coil, is powered up by the first antenna when the
two are brought into close proximity. In an NFC phone, depending on which mode it
is operating in, the antenna can function as both a primary coil, in which case it is the
initiator of an NFC action, and as a secondary coil, in which case it is the target
for an NFC action.
When an NFC phone is used to read a tag, the antenna in the NFC phone draws on
the phones battery to power up the NFC tag. Here, the phone acts as the primary coil
and the phones battery provides the power supply to the antenna. In this instance,
therefore, it is the phone which generates the magnetic field and is the initiator.
In card emulation mode, depending on how the system has been implemented and
the type of application functionality required, the secure element in an NFC phone
can either draw on the phones battery or it can be powered up by a contactless
terminal that either has its own battery or is connected to a mains electricity supply.
Here, when an NFC device is brought into close proximity with a terminal that has
its own power supply such as a POS device or turnstile the action of moving the
device into the magnetic field automatically induces voltage in the phones antenna.
This voltage can then be used to power up the secure element to enable data to be
transferred between the two. This means that the NFC functionality in a phone can,
in theory, still be used when it is switched off or when the battery is dead, in the same
way that a contactless card can be used to make a payment without requiring any
form of in-built power supply.
For payments applications, to deliver additional security benefits and functionality
as well as to meet system requirements, issuers are increasingly specifying that
the phone itself must have power during a transaction, however. Transportation
operators, on the other hand, are tending to prefer to allow passengers to make a
journey even if their battery is flat.
Page 62
NFC Phones
4.1.1
NFC antenna design constraints
A number of design constraints exist for mobile phone manufacturers looking to

incorporate an NFC antenna into their devices. These constraints include the size
of the antenna, the need to avoid signal interference and the location of the antenna
within the body of the mobile device.
4.1.1.1
Size
The required size of an antenna is directly related to the frequency at which it is

required to operate. An antenna designed to work with high frequencies, for example,
can be much smaller than an antenna required to operate at low frequencies.
In mobile phone terms, the 13.56MHz frequency used by NFC is very low. Bluetooth,
for instance, operates in the 2.4GHz band 177 times higher than NFC while 3G
UMTS networks operate at up to 2.1GHz, over 150 times higher than NFC.
This means that, by mobile phone standards, NFC antennas need to be very large.
Ideally, they will be similar in size to those used in contactless cards a serious issue
when it comes to designing them into devices as tightly packed as mobile phones.
4.1.1.2
Location
The location of the antenna within the mobile phone will affect the ease with which
a consumer can use their phone to conduct an NFC transaction or operation. If
the antenna is located at one end of the device, for instance, then they will need to
orientate their phone so that the end of the phone containing the antenna is placed
closest to the tag or reader. If the antenna is located on the back of the phone, then it
is the back of the phone that will need to be aligned with the tag or reader.
4.1.1.3
Interference
NFC creates two issues for manufacturers when it comes to interference with the
other aspects of their devices functionality.
Most mobile phones already include at least two wireless communications antennas
the phones main mobile network communications modem and a second antenna
designed to handle functions like Bluetooth, WiFi and GPS.
In the same way that the waves created by dropping two pebbles next to each other
in a pond will create an interference pattern, each antenna in a mobile phone will
Page 63
NFC Phones
interfere with each other and performance will be impaired, unless each antenna is
carefully located.
Further constraints are created by the presence of metal elements in a mobile
phone. Metal acts as a block to a magnetic field and, more seriously, a magnetic field
generated in proximity to a metal element can also induce eddies in the metal that can
interfere with the core functionality of the phone.
This interference can, however, be eliminated by placing a layer of ferrite material
between the antenna and the metal element. The use of ferrite material adds to the
cost, but also enables phone designers to use the flat surface of the devices battery as a
location for the antenna without the battery creating interference.
4.1.2
Types of NFC antenna
Current generation NFC phones employ a range of locations and designs of NFC
antenna. Samsung has chosen to use a flat, rectangular antenna which is located on
the inside centre back of the phone. The antenna in current Nokia phones, on the
other hand, is located towards the top of the device. RIM uses two antenna positions.
One is located centre back, like the Samsung option, while the second type is located
on the lower back of the phone.
4.2
The NFC controller
The NFC controller sits at the heart of an NFC phone. It connects together all the
pieces of the devices NFC functionality and acts as a switchboard, enabling data to be
sent to and from the phone and the outside world. The NFC controller is connected
to:
The antenna. The NFC controller enables data to be sent via the antenna, from the
NFC phone to the outside world and to the NFC phone from the outside world.
The baseband processor. The NFC controller has a direct connection to the
phones main baseband or application processor, allowing applications that make
use of tag reading/writing and peer-to-peer functionality to be stored in the
phones main memory.
The secure element. The NFC controller has a direct, dedicated, high-security
connection to the secure element. This connection allows sensitive data to be
transmitted and received over short distances in a highly secure manner.
Page 64
NFC Phones
4.2.1
Future developments
Current generation NFC phones use dedicated NFC controller chips, specifically
designed to manage the phones interaction with the outside world via near field
communication. In the future, as the technology develops, phone manufacturers
are also expected to have the option of choosing combo chips that combine NFC
functionality with other functions all in one piece of silicon, as well as controller
functions built into baseband processors.
4.2.1.1
Combo controller chips
There is a crossover between some of the circuitry employed in NFC controller chips
and that required for other, more established short range wireless communications
technologies such as Bluetooth, WiFi and GPS. Like NFC, these functions involve
converting incoming and outgoing analogue radio communications signals into
digital signals. A substantial amount of space could be freed up in the mobile phone,
and costs could be reduced, if these functions were combined onto one chip so that
similar processes could be shared between different communications functions.
Combo chips are mass market products, however, and it only makes economic sense
for a combo chip supplier to invest in adding NFC to its product if there is very high
volume demand from phone manufacturers for the technology. Historically, short
range communications technologies have gradually migrated from standalone chips
to combo chips once they have become an almost standard feature in mainstream
mobile phones, when there is sufficient volume demand from manufacturers to justify
its inclusion in mass market combo chips.
Combo chips are generally designed to have a long lifespan and are most suited to
stable technologies where innovation is no longer taking place rapidly. With NFC,
innovation is still taking place frequently, particularly in terms of the types of RFID
tags and secure elements that devices will need to support.
This support can be added more readily to a dedicated chip which can be
manufactured cost-effectively in lower volumes and, therefore, updated more
frequently. Once combo chips arrive on the market, while some manufacturers will
choose the lower cost combo chip option, others are expected to continue to choose
to use dedicated NFC chips for some time to come.
Page 65
NFC Phones
4.2.1.2
Baseband controller chips
In the future, as well as being able to choose combo chips which incorporate
NFC controller functionality, phone manufacturers will also be able to choose a
main baseband/application processor which comes with built-in NFC controller
functionality. The first of this new generation of processors is due to reach the market
during 2012 and will provide an alternative option for device manufacturers seeking
to reduce costs and maximise space savings.
4.2.2
Supporting multiple secure elements
Early NFC controllers were able to support just one secure element. They then
evolved to provide support for both NFC SIMs and embedded secure elements but
were only able to actively support one of those secure elements at a time. This meant
that, for any one NFC phone, secure NFC services could only be delivered by one
secure element issuer, even if the phone was equipped with both an NFC SIM and an
embedded secure element.
NFC controllers that can support multiple secure elements at the same time are now
arriving on the market, however. These chips hold the promise of allowing multiple
secure elements, including NFC SIMs, embedded secure elements and external
microSD format secure elements, to be actively supported at the same time.
Their arrival may deliver a step change in the NFC market, as they could allow
consumers to choose to use multiple mobile wallets. Mobile network operator handset
requirement specifications published by the GSMA, however, currently stipulate that
no more than one secure element may be active at any time and that phones should
ship with the NFC SIM set as the default secure element.
4.3
The main processor
The main processor is the heart of a mobile phone. It provides the phone with both
its core mobile communications functionality and its ability to execute applications.
Early mobile phones, and some of todays simpler feature phones as well as some
leading edge smartphones, contain a single chip which handles both mobile
communications and application processing. Most of todays mobile phones, however,
contain two main processors, an application processor and a baseband processor.
Page 66
NFC Phones
The application processor hosts the phones operating system or, in a Java feature
phone, its Java Runtime Environment and provides the phone with the ability to
run software applications. The baseband processor, meanwhile, handles the phones
mobile communications functionality.
The baseband processor and application processor are directly connected to each
other, to form one unit. They are also directly connected to components such as the
screen, keyboard and camera as well as to specialist chips responsible for handling
functions such as Bluetooth and GPS and to the phones subscriber identity module.
For NFC applications to be able to leverage a mobile phones standard capabilities,
the main processor needs to be equipped with specialist software known as an NFC
protocol stack and to be physically connected to the phones NFC controller and its
secure element. This enables the phone, and NFC applications stored in the phones
memory, to work with incoming and outgoing short range NFC communications, via
the NFC controller and the NFC antenna, as well as long range communications sent
over-the-air to and from the secure element.
The phones user also needs to be provided with a way to view and manage their NFC
services. Pairing and sharing applications that do not make use of a secure element
can be stored as individual apps in the phones main memory. But, since secure NFC
services come in two parts with one stored in main memory and one stored on the
secure element, communications between the two parts need to be handled in a
secure manner. These applications are, therefore, usually gathered into a single mobile
wallet application that sits in the phones main memory to provide security and to
provide the phones user with an easy way to access and manage their secure NFC
services.
4.3.1
The NFC protocol stack
The NFC protocol stack is a specialist piece of software that provides an industry
standard mobile phone processor with the ability to leverage the phones NFC
capabilities.
NFC protocol stacks contain drivers for each type of card, tag and terminal that the
phone will communicate with and provide the link between the phones operating
system and its NFC functionality.
NFC protocol stacks are a type of middleware software that enables two devices
to work together even though they dont speak a common language and may in fact
be built using fundamentally different principles. This is similar to the function
Page 67
NFC Phones
performed by the TCP/IP protocol stack which forms the foundation of the internets
ability to connect devices as varied as PCs, Macs, IBM mainframes and mobile
phones.
In an NFC phone, this middleware provides a bridge between the NFC controller
and the operating system or Java Runtime Environment installed on the phones main
processor.
Because they work at a fundamental engineering level, NFC protocol stacks need to
be written to meet the specific needs of the operating system used by an application
processor as well as for each NFC controller chip that it will be used with.
Early NFC protocol stacks were written to meet the needs of one particular NFC
controller and to work with simple feature phones. These early NFC feature phones
all used the Java programming language as standard. This meant that one NFC
controller and its accompanying protocol stack could be used in any phone. Each
NFC controller supplier, therefore, wrote its own NFC stack and made this available
to phone manufacturers as a single controller and protocol stack package.
The arrival of NFC smartphones and the move to volume manufacturing of NFC
phones led to a need for alternative options. While some smartphones provide
support for Java, others do not. For smartphone operating systems that do not
support Java, notably Googles Android and Apples iOS, an NFC protocol stack must
be specially configured to work with that operating system before NFC capabilities
can be added to devices work which has now been completed for Android but has
yet to be made available for iOS.
4.3.2
The mobile wallet
The term mobile wallet is commonly used to describe both a virtual version of a
traditional leather wallet and the contents of that wallet, such as cards, passes and ID.
While the term is generally used to cover both these elements of a traditional wallet,
however, an NFC mobile wallet has a quite different technical architecture.
Secure NFC applications are written in two parts, with only generic code applicable to
all users stored in a phones main memory and sensitive, personal data stored in the
secure element.
An NFC mobile wallet, therefore, is the virtual equivalent of the leather wallet itself,
but not of its contents. This means that, unlike a traditional wallet where the cards,
Page 68
NFC Phones
passes, cash and other items contained in it can be viewed in full detail by anyone
who picks it up, a mobile wallet adds an additional layer of privacy and security.
By gathering all these features together into one application, a mobile wallet makes
it possible to provide consumers with a single icon or button on their phone that
provides access to all the NFC applications held on a secure element, so that balances
can be checked and preferences can be set, and also to manage their generic NFC
settings and preferences.
Each NFC application also contains an identifier that allows it to be categorized by the
type of service it provides. Mobile wallet apps use this identifier to sort consumers
various application into categories, allowing the user to view and organise all their
coupons, all their payments cards or all their tickets from within one section of the
wallet app.
Within each category, the user can then also sort their various applications into
priority order. This allows a default payment card to be set, for instance, so that
purchases will be automatically charged to that account unless the user manually
chooses to use an alternative card for a particular purchase.
In feature phones and other low-end devices, a simple mobile wallet app can be stored
on an NFC SIM. In this instance, the wallet operates as a simple, text based interface
and has a similar look and feel to a SIM-based phone number storage system.
NFC smartphones are able to provide a much improved mobile wallet experience
by storing the wallet app in the phones main memory. This allows extra features,
such as a slick graphical user interface, to be added to the user experience. This also
allows each service provider to assert brand identity by storing a full colour logo in
the wallet so that, each time their service is used, their logo will appear on the phones
screen.
While current NFC phones use only one secure element and, therefore, one mobile
wallet, technology is now becoming available that will enable NFC phones to make
use of more than one secure element. But, as yet, solutions have not been developed
that will allow the contents of more than one secure element to be viewed in a single
mobile wallet application. Work is underway to develop mobile wallets that can
combine information from multiple secure elements to enable consumers to have one
mobile wallet that provides access to all their secure applications on multiple secure
elements but, at this time, no date for the arrival on the market of such a solution has
been set.
Page 69
NFC Phones
Work is also underway to decouple the mobile wallet from the secure element. This
will enable service providers to integrate data stored in a secure element into their
mobile apps. For instance, a mobile banking app would be able to draw account status
data from the secure element and a retailers app could include details of coupons and
offers stored in the secure element.
4.4
NFC phone security
The use of NFC technology to deliver secure mobile services is built on its ability to
provide end-to-end security throughout the system, both outside the mobile phone
and within it.
NFC phones employ internationally recognised ways of managing sensitive data
whenever it is transmitted internally within the phone. NFC phones include a
dedicated physical connection between the secure element and the NFC controller
and communications sent along this connection are encrypted according to
international standards.
Communications between the phones main processor and the secure element
are also conducted in an internationally standardised secure manner and phone
manufacturers are expected to submit their devices for certification before being used
to deliver secure NFC services.
4.4.1
HCI and SWP
Two international standards, known as the Single Wire Protocol (SWP) and the Host
Controller Interface (HCI), specify the way in which communications between an
NFC SIM and a phones NFC controller are managed.
4.4.1.1
The Single Wire Protocol
The Single Wire Protocol, commonly referred to as SWP, and the Host Controller
Interface, known as HCI, were developed at the behest of the GSM Association.
They have been standardized on an international level by ETSI, the European
Telecommunications Standards Institute (see www.etsi.org), as:
ETSI TS 102 613 (Smart Cards; UICC Contactless Front-end (CLF) Interface;
Part 1: Physical and data link layer characteristics), and
Page 70
NFC Phones
ETSI TS 102 622 (Smart Cards; UICC Contactless Front-end (CLF) interface;
Host Controller Interface (HCI))
Together, they define a standard communications interface between the SIM
(subscriber identification module) and the phones NFC controller and, from there,
via the phones antenna, to the wider world beyond.
Although SWP was originally developed specifically to connect the NFC controller
to the SIM, in order to use the SIM as the secure element, SWP is now increasingly
being adopted as a method of connecting both embedded and external secure
elements to NFC controller chips as well.
Under the Single Wire Protocol, the SIM and the NFC controller are physically
connected using a single wire which provides a direct connection between one of the
contacts on the SIM and the NFC controller. The Single Wire Protocol also sets out
on an engineering level, using both a physical transmission layer for electrical signals
and a data link layer for information exchange, the way in which the SIM and the
NFC controller should communicate with each other in order to ensure that security
is maintained at all times.
4.4.1.2
The Host Controller Interface
The Host Controller Interface (HCI) specification sets out the chain of events that
should take place when a transaction is carried out using a SIM, or another type of
secure element compatible with the Single Wire Protocol, as the secure element in an
NFC phone.
When a transaction is made with a payment card whose details have been stored on
the SIM, for example, the HCI specification requires that the following sequence of
events takes place:
When the phone user places his device within range of a contactless point-of-sale
terminal, the NFC controller detects that a radio frequency field is present and
informs the SIM that it has detected a field.
The NFC controller then begins an initialization and anti-collision process, to
ensure that it has a clean field of play and that there arent multiple cards or NFC
phones trying to use the same POS terminal at the same time.
Once that process is complete, the NFC controller begins collecting encrypted
data from the POS terminal related to the transaction the user wishes to make,
then forwards this data to the SIM over a secure connection.
Page 71
NFC Phones
The SIM then responds by sending the necessary card data required to process
the transaction to the NFC controller, again in an encrypted format, which then
forwards the data to the POS terminal.
These last two steps may then be repeated several times. If, for example, the
user is required to enter his PIN on the POS terminal, then the NFC controller
will receive PIN data from the terminal in encrypted format and ask the SIM to
verify if the PIN entered is correct. The SIM will then respond with a yes or
no, ensuring that the PIN data stored in the SIM is never revealed even in
encrypted format.
Once the transaction has been completed, and if the POS terminal supports
this function, the process will end when the NFC controller sends the SIM a
deactivation message informing it that no more information exchanges are
required for this transaction.
If, at any time during this process, the NFC controller finds that the RF field is no
longer present, it informs the SIM using a field off message and the process is
stopped.
4.4.2
The JSR 177 Security and Trust Services API (Satsa)
The level of security in a system is only as a strong as the weakest link in the chain.
NFC systems are therefore designed to ensure that they maintain the highest levels of
security, from one end of the system to the other.
For NFC, that means a totally secure environment must be created for
communicating sensitive data between the different internal parts of the phone as
well as when this information is communicated with the outside world.
Information sent between the secure element and the phones main processor is sent
over a secure communications channel using internationally standardised APDU
(Application Protocol Data Unit) commands.
In Java environments, where the subscribers SIM is used as the secure element, a
standard means of establishing this secure communications channel, known as the
JSR 177 Security and Trust Services API or Satsa for short has been developed
(see sjb.co.uk/0epj). Satsa uses a public key cryptography system to ensure that
information sent between the SIM and the baseband processor is fully secured at all
times:
Page 72
NFC Phones
To prevent eavesdropping, all data sent between the secure element and the
baseband is sent in encrypted format, using a combination of encryption
algorithms such as DES and RSA that are already widely used to encrypt
communications between chip and pin or contactless bank cards and point-ofsale terminals.
The data cannot be tampered with in transit without the SIM knowing. This is
done by using the SIMs ability to generate digital signatures that can then be used
by the SIM to check that data sent from the baseband/application processor has
not been changed during transmission.
The SIM can use a combination of both data encryption and digital
signatures to verify that the data it receives has indeed been sent to it by the
baseband/application processor, rather than by a fraudulent third party.
Proof that the transaction has taken place can be provided so that one of the
parties cannot say at a later date that it did not actually occur. This is done using
a particular kind of digital signature known as a non-repudiation signature and,
again, uses a combination of data encryption and digital signature functions.
BlackBerry NFC smartphones also make use of JSR 177. For Android phones,
however, the situation is more complex and still developing. Google has implemented
its own proprietary solution for devices running its Google Wallet app with an
embedded secure element but has not made available a wider solution for Android
phones using SIM-based NFC.
4.5
NFC phone certification
Neither consumers nor providers of secure NFC services are generally willing to take
on trust, however, that a device is secure from the threat of hackers and fraudsters. A
series of global, vertical market and local certification and approval processes are now
being put in place that will allow phone makers to prove to both potential buyers and
potential service providers that their device conforms to requirements.
4.5.1
The NFC Forum device certification programme
The NFC Forum device certification programme provides a way for manufacturers of
NFC devices to prove that their products meet the requirements of the NFC Forum
specifications.
Page 73
NFC Phones
Companies whose devices pass the certification process are able to display the NFC
Forum Certification Mark on their websites, manuals, marketing and packaging
materials to denote compliance and only companies whose products pass certification
testing are able to display the Forums N-Mark on their devices.
To have a device certified as NFC Forum compliant, manufacturers must be members
of the organisation at least at Implementer level. They can then choose to submit
their device for testing at an NFC Forum approved lab or to buy in their own test
tools from an approved supplier and then perform compliance testing in-house. The
results of these tests are then submitted to The Open Group, a vendor-neutral and
technology-neutral consortium which provides independent checking of test results,
before the device certification process is complete.
4.5.2
Vertical market certification
The NFC Forums specifications and certification programme cover a devices ability
to handle core NFC functions in an approved manner. Before they can be used to
store sensitive customer data, however, they must also be certified as meeting the
security and performance requirements of each particular vertical market in which
they will be used.
In the payments arena, for instance, Visa and MasterCard have put certification
programmes in place for both NFC phones and NFC secure elements and both
must pass before a device can be used to make mobile payments. An NFC version of a
Visa card, for instance, can only be stored on a secure element hat has passed security
tests specified by Visa, in an NFC phone that has also passed Visas security and
compatibility tests.
Public transportation operators also have requirements that NFC phones must meet,
although in this instance it is transaction speed which is the key consideration, and
as the NFC market expands other vertical markets are expected to develop their own
performance requirements.
Mobile network operator association the GSMA has also put together a list of
requirements (see sjb.co.uk/q6e2) that its members wish an NFC phone to meet
before they are willing to put a device on sale. These requirements cover all aspects of
a phones functionality, including both security and performance benchmarks.
Page 74
NFC Phones
4.5.3
Local market certification
As well as having to comply with international specifications and standards, secure

elements and NFC phones are also subject to local requirements set by NFC
infrastructure managers. These organisations specifications are typically built on top
of international standards, to ensure that the phones and secure elements provided to
consumers in any particular country meet both international standards and local laws
and requirements.
4.6
Adding NFC to existing phones
The slow arrival of commercially available NFC phones has led to the development
of various ways of retrofitting NFC functionality to existing mobile phones. The five
main solutions that have been developed are: MicroSD card based solutions, NFC
cases, SIM+antenna solutions, all-in-one NFC SIMs and Bluetooth/WiFi peripherals.
Simple contactless stickers also provide a sixth, less expensive but less flexible option
for certain card emulation mode applications.
Depending on the format employed and the particular product chosen, these
solutions vary in their ability to provide full NFC functionality. Some offer just one
of the three NFC modes while others can provide the means of delivering two or all
three modes of operation.
Originally expected to be simply temporary solutions, bridging the gap until
NFC phones became widely available, microSD format devices in particular are
now increasingly seen as long-term solutions. Chinese payments network China
UnionPay, for example, has developed its own NFC specification that calls for the use
of microSD devices issued by Chinese banks that can be inserted into phones with
built-in NFC antennas and controllers so that card issuers can retain control over
their own secure element.
4.6.1
MicroSD card solutions
A number of suppliers have developed ways of incorporating both an NFC antenna

and an NFC secure element into a microSD format package that can be simply
inserted into the microSD slot provided in most of todays mobile phone models.
Depending on the individual product or supplier involved, these solutions can also
provide an amount of free memory capacity so that consumers can use their microSD
slot to provide both added memory capacity and NFC functionality.
Page 75
NFC Phones
On a hardware level, these devices can work with any phone equipped with a
microSD slot. In practice, in order to provide a good experience to both users and
issuers, software is also installed on the handsets main processor and this requires
tailoring for particular types of phone.
MicroSD solutions tend to have a shorter operational range than mobile phones with
built-in antennas, however. This issue can be addressed via the addition of a signal
booster, an additional stick-on antenna that improves the devices range.
MicroSD solutions are also available for use with phones that already include an NFC
antenna, allowing the secure element in the microSD card to be powered up by a fullsize antenna.
Here, the microSD device provides the potential for a third party such as a bank,
payments processor or corporate security solution provider to become the secure
element issuer in a way that would not otherwise be available.
MicroSD solutions vary in functionality. Card emulation is a standard feature and is
the easiest to implement as it requires less power. MicroSDs with tag read/write and
peer-to-peer mode support are also available, but from a limited number of suppliers.
4.6.2
NFC cases and sleeves
NFC cases and sleeves have also been developed, primarily to support the addition
of NFC functionality to the iPhone, which does not include a microSD slot. One
approach is a sleeve or case arrangement that fits around the back of the phone and
includes the antenna and secure element chip. A second approach is a slot-on solution
that can be fitted onto the bottom or top of a phone.
4.6.3
SIM+antenna solutions
SIM+antenna solutions are widely used in the mass transportation market in China
and a number of other countries. With this approach, the SIM-based secure element
is attached to an antenna via a thin flexible cable. Users replace their existing SIM
with the new SIM and then place the linked antenna inside the back cover of their
phone.
These solutions are commonly supplied with a single NFC application pre-loaded
onto the SIM so that users can collect the SIM+antenna kit from an agent, such as a
transportation ticket office, and begin using their phone to make payments straight
away.
Page 76
NFC Phones
4.6.4
All-in-one NFC SIMs
SIMs that incorporate standard subscriber identity functions, an NFC secure element
and an antenna all in one package are now beginning to arrive on the market,
allowing mobile network operators to provide customers with a way to add NFC
functionality to existing mobile phones.
Because SIMs have such a small form factor, the antenna must also be very small in
size. The new all-in-one SIMs therefore also include signal boosting technology that
amplifies the radio frequency signal generated by the built-in antenna.
4.6.5
Bluetooth and WiFi peripherals
The first three NFC add-on solutions require the new NFC solution to be inserted
into a mobile phone. Bluetooth and WiFi-based NFC peripherals take a different
approach. These solutions place NFC functionality into a dedicated NFC device and
then use technologies such as Bluetooth and WiFi to transfer data to and from a users
standard mobile phone.
A number of different formats have been explored. At one end of the scale are stickers
that attach to the back of a mobile phone and then communicate over a very short
distance using Bluetooth. At the other end are devices that can take on forms such as
wristbands, watches and key fobs that allow the phone to be kept in the consumers
pocket while making an NFC transaction.
With the need to reduce space no longer a core requirement, these solutions offer the
key advantage of including a battery that can be used to power up the NFC device
so that it can operate in all three modes. This same advantage also comes with a
disadvantage, however. The device will be able to conduct only a limited number of
operations before the battery needs replacing or recharging. Consumer acceptance
levels will therefore depend on consumers willingness to adopt yet another device
that requires regular recharging.
That acceptance, in turn, will depend on how much the NFC functionality is
appreciated by the consumer.
4.6.6
Contactless stickers
For card emulation only applications, a simple contactless sticker can be affixed to
the back of a mobile phone to provide a low cost way of enabling a form of card
emulation.
Page 77
NFC Phones
The stickers can be used for applications where a simple ID number is used to
identify a consumer at the point-of-purchase. An online connection is then made by
a terminal at the point-of-sale to a back office database containing the details of the
customer issued with that ID number.
Solutions can also be built with this approach that do not require any device to be
issued to a consumer at all. Instead, the consumer can tie their choice of existing
contactless device a transport pass, ID card or other device to their database
record and then use that device to identify themselves at the point-of-sale.
4.7
Other NFC devices
Mobile phones offer the advantage of over-the-air communications capabilities as

well as NFC all in one device. Thus, NFC-enabled phones are expected to become
the ultimate format of choice for most consumers, especially once NFC becomes a
standard function in the majority of phones on the market and there is no additional
cost for its inclusion.
Mobile phones are not the only way in which consumers can be provided with NFC
capabilities, however, and a number of NFC specific, non-mobile devices have now
been developed. These devices have usually been developed to fulfil the NFC needs
of a particular demographic group, as a way to create a critical mass of consumers
equipped with NFC capabilities.
Examples include a unit designed specifically to meet the needs of tourists visiting
a particular attraction and a thick credit card-sized device that combines card
emulation and tag reading functions to deliver a range of marketing and promotions
solutions. Devices aimed specifically at both social and business networking are also
now on the market, providing a low cost way to take advantage of NFC-based contact
sharing and information collection.
NFC capability can also be built into any kind of business and consumer electronics
device. Tablets with built-in NFC capabilities are now appearing on the market and
everything from smart meters to blood pressure monitors, TVs to games machines
and vehicles to watches are now being equipped to handle NFC communications.
Page 78
Delivering NFC services
Before a consumer with an NFC phone can begin to use an NFC service, they need
to be able to add NFC applications to their phone. To do this, they need to be able
to request a particular NFC service and to have the main application downloaded to
their phone. The application may then also need to be personalized with their own
details, such as their credit card number or ID.
Once the application has been installed on their NFC phone, systems also need to
be put in place to allow the issuer to maintain and upgrade the application and to
provide the consumer with a smooth transition should he switch mobile network
operators, lose or upgrade his handset.
Before that can all happen, service providers need to develop NFC applications that
will appeal to their customer base and, if access to a secure element is required,
they also need to put platforms in place to enable information stored on back office
databases to be safely transferred onto customers mobile phones, regardless of which
make or model of NFC phone they use or which mobile network operators services
they subscribe to.
This chapter examines the functions, processes and platforms that currently need to
be put in place to enable a service provider to offer NFC services to its customers and
examines each of the options available. It looks at how consumers can request an NFC
service and how NFC applications are downloaded to consumers NFC phones. It also
examines the systems that need to be established to allow excellent customer service
to be provided, whether the customer calls their service provider or their carrier to
raise an issue as well as what happens if an NFC phone is lost or stolen.
When it comes to NFC service delivery, however, the industry is still very much in
the early stages of discovering what best practice will ultimately be. Technology is
still evolving rapidly and the way in which NFC services are delivered in the future
Page 79
is likely to be both simpler and provide more opportunity for individual service
providers to differentiate their offerings than current platforms permit.
5.1
Pre-launch requirements
Pre-launch preparations for NFC pairing and sharing applications can be as simple as
developing the application and then uploading it to the relevant app stores.
For NFC services that will make use of a secure element, however, the process
is, again, more complicated. Before service providers can begin providing NFC
applications to their customers, back office systems need to be put in place that will
create a link between existing customer records and secure element issuers systems.
On the business side, commercial agreements will also need to be made between the
service provider and each of the secure element issuers who provide NFC services to
its customers. Detailed approval processes must also be undergone before a secure
NFC application can be permitted to be downloaded to a secure element, to ensure
that only applications that comply fully with security requirements can gain access.
5.1.1
NFC platforms
The exact nature of the platforms required to support NFC services will differ
according to the type of service to be offered and the way in which an NFC
infrastructure has been established. Whatever the type of NFC infrastructure
involved, however, in a secure NFC service scenario NFC platforms in one form or
another will be required by:
The secure element issuer (and/or its appointed trusted service manager)
The service provider (and/or its appointed trusted service manager)
These platforms can be integrated, as required, with existing customer record
systems to allow an individual consumers details to be securely sent from the service
providers back office system over-the-air, or through other means, to that consumers
mobile phone.
A secure service provider will also need to create a secure connection between its own
systems and each secure element issuer. For a bank to roll out NFC services to all its
customers, for instance, it will need to establish secure connections to each mobile
Page 80
network operator in the country in which it operates, since the banks customers will
not all be customers of the same mobile network operator.
Here, trusted service managers (TSMs) can play a role in reducing the complexity of
the installation requirements. TSMs are able to establish connections with all mobile
network operators and secure element issuers on behalf of service providers so that
a secure connection needs only to be established between the service providers
back office systems and the TSM, and not to each individual operator. And, for each
platform required, the work may well be performed by a TSM appointed by the
mobile network operator, the service provider or other secure element issuer rather
than by the individual company involved.
5.1.1.1
Secure element issuer platforms
In order for a mobile network operator to provide NFC services via the SIMs it
issues to its subscribers, a platform needs to be put in place that will enable it to
communicate with each customers secure element. This will typically mean that an
NFC module will be added to its existing OTA (over-the-air) platform.
All carriers already have OTA platforms that they use to communicate with each
customers SIM or embedded identification module. These are used by the mobile
network operator to manage the identity module on an on-going basis.
Depending on the business model adopted by the mobile network operator, this
NFC platform will vary in its level of complexity. Some carriers are looking to simply
enable NFC services for customers as a way to increase their overall service offering
and will implement the minimum required to do that. Others are making a strategic
bet on NFC and are building more complex systems. These are designed to enable
them to differentiate their service by also offering turnkey NFC solutions to business
customers seeking to offer NFC services, as well as to provide a range of value added
services to their subscribers.
While mobile network operators already have OTA platforms that allow them to
communicate with a subscribers SIM over the air, this is not the case for other secure
element issuers such as handset manufacturers, operating system suppliers, payments
networks and other third parties. These secure element issuers need to put equivalent
systems into place to enable service providers to be able to interact with their
embedded secure elements.
It is still very early days in terms of the commercial availability of NFC services
employing embedded and external secure elements, however. The same level of
Page 81
information has not been made available by companies following this route regarding
how their systems work and proprietary, rather than standardised, solutions are most
widely used in todays services.
5.1.1.2
Service provider platforms
The complexity of a service providers platform requirements, and the level of

investment required to begin offering services, will depend on the type of application
to be provided as well as on the way in which that service is currently delivered.
Early adopters of NFC technology had to build their own platforms and figure out
from first principles how to integrate their existing systems. Increasingly, however,
NFC is being offered as an optional, add-on module to existing suppliers systems,
reducing the need to develop an NFC platform from scratch.
Ways of implementing NFC that minimize the amount of integration with existing
back office systems are also being developed. Suppliers of plastic card issuing systems,
for example, are working to integrate NFC into their solutions so that a customers
details can be prepared in exactly the same way and using exactly the same systems,
regardless of whether their personal data is to be written to an NFC phone or to a
standard plastic card.
Ways of avoiding, or reducing to a minimum, the amount of integration with back
office systems are also available and have been used in a number of early commercial
NFC services. An unassigned ID number, for example, can be stored on the NFC
phone rather than the customers existing card number and data. This ID can be
loaded onto the secure element during manufacturing and then tied to a customers
account at a later stage, such as when a customer actually signs up for the service.
In this way, integration with the back office is not needed for loading the NFC
application the ID number and the customer are simply linked together by
customer services when the service is switched on.
5.1.1.3
Connecting the dots
NFC technology specifications have been established that provide for a number of
ways in which service providers can opt to set up connections from their back office
systems to NFC platforms provided by mobile network operators and other secure
element issuers in order to load an NFC application onto their customers NFC
phones, personalize it, and manage the application on an on-going basis.
Page 82
The options available will depend on how a particular NFC infrastructure is

designed. In centralised systems, for instance, service providers will need to create a
connection to a single trusted service manager appointed by the NFC infrastructure
manager. In more distributed systems, where a number of secure element issuers
all appoint or run their own TSMs, connections will need to be made to each TSM.
Here, service providers are likely to have the option of choosing to use one of these
TSMs to manage their NFC services or to appoint their own potentially creating
an infrastructure in which tens or even hundreds of NFC platforms need to be
connected together.
Connections between a service providers back office systems, the secure element
issuer and a mobile network operator are made using secure point to point virtual
private networks (VPNs). These VPNs are established between a service provider and
each secure element issuer, or between TSMs acting on behalf of the service provider
and/or the secure element issuers and mobile network operators.
As well as connections between the parties NFC platforms, connections may also
need to be made between a mobile network operators existing SMS-C gateway and
the service provider so that information and files can be sent to the end user via
SMS. A connection to the operators WAP gateway may also be included, to provide
support for legacy phones.
All requests, responses and notifications are then exchanged over this virtual private
network in encrypted formats and in accordance with established security standards.
Communications between a mobile network operators NFC OTA platform and a
service providers NFC platform, for instance, are double encrypted by both the
NFC service provider and the mobile network operator.
5.1.2
App approval
Any application that involves access to the secure element will need to go through an
approval process so that secure element issuers can be assured that the application
does not break any security rules. The exact nature of those rules will vary between
NFC infrastructures but will typically require that the app must only communicate
with the secure element using the JSR 177 Security and Trust Services API (Satsa)
or its equivalent and that all apps must be digitally signed before deployment on the
phone, to ensure that they come from a trusted source. Individual infrastructures may
also put restrictions in place regarding the maximum size of the application package
that is to be stored on a secure element.
Page 83
At the same time that an application is submitted for approval, the service provider
will also need to provide a list of the devices and/or operating systems with which its
service is compatible. This information can then be used when a customer requests a
service to see if the customers handset will support the application before sign up is
completed and an attempt to download the application is made.
5.2
Enabling customers to request the NFC service
Once an application has been developed and approved and any necessary platforms
and secure connections have been put in place, mechanisms are also needed to allow
customers to sign up for the new service. Both secure services and pairing/sharing
applications can be made available to customers to download from an app store. With
a secure application, however, only the generic application code will be downloaded
from the app store. The secure element package and personal data will be delivered
separately over-the-air, as part of the provisioning process.
NFC offers far more opportunities to market an application to potential customers
than just uploading the app to an app store and leaving potential customers to
discover it, however. Both secure NFC services and pairing/sharing applications
can be promoted widely using a range of marketing channels, including the service
providers own website, via smart posters and tags, at the point of service, via direct
marketing channels and mobile advertising campaigns, by directly pushing the
application to customers and by viral distribution from customer to customer.
5.2.1
Via a smart poster or tag
NFC tags can be attached to or embedded in a wide range of media and programmed
with the details of the URL from which a service request can be initiated. An array of
options is available here.
Smart posters and advertising boards, for instance, can be located anywhere that a
consumer is likely to consider signing up for a particular NFC service, such as in a
store, in a train or subway station, in a bank branch, on a university campus or other
location that suits the particular application.
NFC tags can also be directly attached to product packaging and registration for an
NFC service can also be tied in to promotional campaigns. A customer tapping a
smart poster to obtain a special offer, for instance, can be sent the required application
Page 84
automatically before a coupon is downloaded if they have not already signed up for a
particular marketing program.
5.2.2
At the point of service
Requests for service provision can also be handled by service staff at bank counters,
at the point-of-sale and at other locations, or via self-service kiosks equipped with
contactless terminals. Here, the service request would be made via the phones
contactless interface and could be combined with downloading the application to the
phone from the terminal, again using the phones contactless interface.
Where a service provider is also involved in distributing NFC add-ons to consumers,
customer service staff can be equipped to register new consumers for the service,
to provide the add-on to the consumer and to perform any set-up and installation
required in the same way that transport ticketing staff currently handle the issue of
travel cards to consumers.
5.2.3
Via consumer request to a contact centre or website
Services can also be set up so that a consumer can simply phone the service provider
or mobile network operators contact centre or enter their details on a website or WAP
site in order to initiate the download of an application.
5.2.4
In response to marketing and advertising campaigns
Both mobile advertising techniques and printed direct mail can be used to market an
NFC service to customers. With a mobile advertising campaign, the consumer would
simply need to hit a yes, please sign me up button to download the application.
With direct mail, the consumer could be directed to the service providers website
or contact centre or, by incorporating an NFC tag into the direct mail piece, the
consumer could simply touch their NFC phone to the tag to initiate downloading of
the application.
5.2.5
Via direct distribution of an NFC add-on
With NFC add-ons that are easy for a consumer to install, such as microSD format
devices, there is the potential to simply distribute the add-on to customers in the mail,
pre-loaded with a particular application or applications and already personalized to
the individual consumer. The customer would then simply detach the add-on from
Page 85
the carrier packaging, insert it into their phone and begin making NFC transactions
straight away.
5.2.6
Via an app store
Both secure NFC services and pairing/sharing apps can be made available to
customers via an app store in the same way that standard mobile phone applications
are delivered. With a secure NFC service, however, only part of the application would
be downloaded from the app store: the secure element package would be distributed
separately and securely over-the-air.
5.2.7
Via the mobile wallet
Mobile network operators and other mobile wallet providers can also promote NFC
applications through the mobile wallet itself. Here, the icon and an overview of the
application would be made available within the relevant section of the wallet along
with an option to subscribe to a service or download the app.
5.2.8
Viral distribution
NFC peer-to-peer mode can also be used to promote an NFC service to consumers.
In this instance, a link to an app store or other location from which an application can
be downloaded or registered for can be passed from an existing user to a friend or
contact by simply placing two NFC phones together, allowing usage of an application
to be increased via social, viral marketing means.
5.3
NFC app delivery
Once a customer has signed up for an NFC service, their request for an NFC service
must then be fulfilled.
The first step in this process is to check whether the customers phone will support
the application being requested. In situations where a mobile network operator is
the secure element issuer, a check to discover whether their mobile phone contract is
suitable for NFC services may also take place.
For pairing and sharing applications, the process of downloading the application
is quite straightforward since it can be performed without the need for secure
Page 86
systems to be put in place or personal data to be transferred. The app can simply be
downloaded from an app store.
For secure NFC services, a number of options are available and depend, in particular,
on whether the service provider has opted to fully or partly pre-load the application
onto secure elements during the manufacturing process.
5.3.1
Checking phone and contract compatibility
Before downloading a secure application to a consumers mobile phone, a check may

need to be made to ensure that the customer has a suitable mobile network contract
in place, as well as to ensure that their phone is equipped to handle NFC services, to
ascertain what type of phone the customer has so that the correct version of the NFC
application for that handset is delivered and to check if there is sufficient space on the
consumers secure element for any personal information needed by the application.
Mobile network operators maintain databases providing details of the type of phone
each of their subscribers uses although, where the consumer did not purchase the
phone from the operator, this may not always be the case. For instance, in the French
Cityzi system (see www.afscm.org) the service provider can send an automated request
containing the customers mobile phone number to the customers mobile network
operator asking if the phone will support its application and, if so, which version of
the application should be delivered.
On receipt of the service providers request, the mobile network operator will reply
with a yes or no and also send the service provider an ID number for the customer
that can be used to tie together the customers secure element and the customer ID
number used by the service provider.
5.3.2
Loading the NFC app onto the customers device
A number of different options are available for downloading an NFC application to

a consumers NFC device and, again, the processes involved are different for pairing
and sharing apps compared to secure NFC applications.
For pairing and sharing apps, there is just one application package to be downloaded
to the devices main memory. For secure NFC applications, there are three parts to
be downloaded: the NFC app which is to be stored in main memory within a mobile
app, the secure element package and the customers personal data.
Page 87
All or part of a secure NFC package and its data can be pre-loaded onto a secure
element during manufacturing. All or part of the package can also be downloaded
over-the-air as required, in response to a customer request for a service. The whole
process can also be performed over-the-air.
5.3.2.1
Fully and partly pre-loaded NFC applications
An NFC secure element package can be installed directly onto the secure element
during the manufacturing process by the manufacturer of the secure element or by
an independent third party. In this way, the creation of a Supplementary Security
Domain for the service provider, the creation and delivery of the keys to the domain
to the service provider and the installation of the NFC package containing the secure
half of the providers NFC application can all be put in place without the need for an
over-the-air application delivery system.
In some circumstances, the task of personalizing the application with the customers
personal data can also be performed at this stage although this depends on both
the type of secure element being used and whether the user of the secure element
is known during manufacturing. In the case of an NFC SIM being produced for a
mobile network subscriber, for instance, a black box installed at the manufacturing
plant and controlled by an entity trusted by the service provider could be used to
install the customers personal data for a particular service.
Optionally, the application can also be stored on the secure element but not installed
into a particular Supplementary Security Domain. Instead, a domain is created for a
service provider only when a consumer requests a particular service. The application
is then copied into the domain, rather than having to be sent over-the-air, and is then
personalized to the individual customer.
Alternatively, an application could also be loaded into a Supplementary Security
Domain during manufacturing but not activated until a later date. In this way, an
application which does not need to be personalized to the end-user such as a
prepaid travel pass, for example could be pre-installed on the secure element but
only activated when the consumer loads funds onto the pass for the first time.
Here, the service providers application would be loaded onto the secure element in
the factory. A Supplementary Security Domain can also be created for the service
provider at this stage too, or this process can be left until the consumer requests the
service at a later date.
Page 88
When the consumer requests the NFC service, therefore, the application itself does
not need to be downloaded. Instead, the service provider simply needs to personalize
the application to the particular customer or link a pre-installed ID number to the
customers database record.
5.3.2.2
Loading NFC applications over-the-air
The whole process of creating a supplementary security domain, downloading the

NFC application, the secure element package and personalizing the application to the
individual can be carried out over-the-air in response to a request for service from the
customer.
Here, the service provider and the secure element issuer need to work hand in hand
to create a seamless customer experience.
In the French Cityzi service, for instance, customers can contact either the service
provider or their mobile network operator to request a particular NFC service.
If they contact the service provider, the process works in the following way:
The first step is to identify the customers handset by, for instance, requesting
the customers mobile phone number and asking for permission to contact their
mobile network operator. This step can be performed manually by a customer
services representative or automatically when, for instance, a customer requests a
service via a website.
The service provider contacts the mobile network operator to request a unique
ID number for that customer, known as an idTech, which will be used during
the application downloading and personalization process. Again, this step can be
automated.
The mobile network operator checks to see if the customers phone will support
the service providers application, if the customers mobile phone contract
includes NFC service provision and if there is sufficient space in the customers
secure element.
If all requirements are met, the mobile network operator sends the service
provider the idTech and the over-the-air application delivery and personalizing
begins.
If there is a problem, the mobile network operator informs the service provider
of the reason for the problem. If the reason is that they do not have the right kind
Page 89
of mobile phone or service package, the mobile network operator can also take
the opportunity to discuss subscription package and handset options with the
customer and upgrade them if required.
The Cityzi system also allows for customers to make initial contact with the mobile
network operator to request a particular service. This allows the mobile network
operator to promote NFC services to its customers and provide them with details of
newly available services. Using the compatibility information provided by the service
provider during the application approval process, the carrier can also ensure that
individual customers are only presented with service options that work with their
particular handset.
When a customer requests a particular service, the same process outlined above is
performed in the reverse direction. Once all the elements of the NFC service have
been downloaded to the customers phone, the application is then activated and the
customer can begin using their new NFC application.
5.4
Maintaining and upgrading an NFC service
Once a customer has a working NFC application stored on his mobile phone,
processes also need to be in place to handle on-going maintenance and upgrade
requirements. Systems are required to handle situations where the customers SIM is
replaced by the mobile network operator, for example, when the customers mobile
phone number changes or when they decide to switch mobile network operator, bank
account or handset.
Most importantly from a customer service point of view, systems must be put into
place to handle situations where a customers phone is lost or stolen and when
they upgrade their phone. And, from a service providers point of view, procedures
must also be established for what happens if the customers mobile phone service is
cancelled altogether or if their service is cut off.
A well thought out procedure for how to handle customer service enquiries is also
required, to ensure that consumers with a query or an issue that they need to raise are
not sent backwards and forwards between their mobile network operator and their
NFC service provider.
Page 90
5.4.1
Managing customer service enquiries
To avoid customer confusion, the question of who to contact when a consumer has
a query regarding their NFC services is one that needs to be clearly addressed by
all parties involved in providing an NFC service to an end-user. Some queries, such
as those regarding overall NFC service supply, will clearly need to be handled by
the secure element issuer or their appointed representative. Others will need to be
addressed to the consumers mobile network operator while only the provider of a
particular service will be able to answer questions regarding issues with that service.
It is clear that the consumer is unlikely in many cases to be able to work out who
he should contact in the first instance with a query. As yet, no standard means
of addressing this question has been agreed upon. The French AFSCM (see
www.afscm.org), for instance, has made it a requirement that mobile network operators
and service providers should provide a way to connect their respective customer
support services so that any enquiry can be handled via one request from a consumer,
regardless of who they contact in the first instance. Providing customer service
contact details for each service provider from within the mobile wallet application
is another option, allowing the consumer to simply look up who to contact on his
mobile phone.
5.4.2
Lost/stolen phone blocking
Putting in place a procedure for swiftly closing down access to a phones NFC
features if it is lost or stolen is a key requirement of an NFC infrastructure. Current
best practice suggests that a two tier approach is employed in this instance. First,
the secure element issuer should be able to send a system wide lock instruction to
the secure element a process which mobile network operators already have in
place for their SIMs. Then, as a backup in case the secure element issuer experiences
problems, service providers are also expected to be able to individually lock their own
applications.
The AFSCM recommends that the mobile network operator, after locking the NFC
SIM, also contacts each service provider to advise them of the loss or theft and, for
payments related applications, the consumer is also recommended to contact their
payments service provider directly to inform them of the loss. The service provider
would then put a block on that account from within its own back office system.
Page 91
5.4.3
Change of SIM
Changing the secure element requires the secure element package for each NFC
application to be re-installed by each service provider, or their supplier, using the
same process established for loading an application onto a customers secure element
when they first requested the service. A back office database maintained by the
secure element issuer can be used in these circumstances to allow this process to be
automated, by sending an update instruction to each service provider rather than
requiring the customer to contact each provider individually.
5.4.4
Change of phone
The processes involved in transferring a consumers NFC services to a new phone will
depend on the type of secure element used in both the old and new phones.
Where both phones employ an NFC SIM and a contract remains in place with the
same mobile network operator, for instance, the SIM will not need to be replaced it
can simply be transferred from the old phone to the new phone. New NFC apps will,
however, still need to be downloaded to the new handsets main memory, but this
process is likely to be automated so that the user does not need to contact individual
service providers in order to initiate the downloads. When the SIM is inserted
into the new handset, the presence of each application stored on the SIM could be
detected so that the download of the new apps is triggered automatically.
Where embedded or external secure elements are used in either the new or the old
phone, however, the process will be different and the way in which it will be managed
has not yet been standardized. If both phones ran the same operating system
and employed secure elements managed by the same entity, the process could be
straightforward a central store of the NFC applications stored on the embedded
secure element could be used to generate an automatic download of new apps and
secure element packages to the new handset when the customer first registers and
logs onto their new device.
For instances where a consumer is switching between secure element types and/or
secure element issuer types, however, no set procedures have yet been put in place so
that, today, no simple process for transferring applications between the old and the
new phone exist.
Page 92
5.4.5
Cancellation of mobile network service
Finally, where the mobile network operator is the issuer of the secure element,
cancellation of a consumers mobile service either because they are switching
mobile service or their connection has been terminated or suspended by the operator
creates a requirement for the content of the SIM to be deleted and, ideally, for the
SIM to also be disposed of in a secure manner.
Deletion of the applications held on a SIM can be performed over-the-air by the
mobile network operator provided the SIM remains in the phone although this
will not always be the case and the AFSCM suggests that both service providers
and mobile network operators write into their service agreements that the consumer
is responsible for securely disposing of the SIM at the end of its life. Whether this will
be practical, however, remains to be seen especially in situations where a consumer
has had their service cancelled or has switched operator due to dissatisfaction with
the level of service provided.
Page 93
Page 94
Index
Index
Symbols
bus 8, 14, 39
3G 49, 63
card emulation 5, 13, 17, 20, 46, 62, 75, 76, 77, 78
Card Emulation Mode 7
Cardlet 24
car parking 19
CDMA 49
certification 49, 70, 73, 74, 75
check in 9, 16, 20
check out 16
China UnionPay 75
chip 6, 17, 18, 20, 21, 32, 33, 34, 45, 47, 48, 49, 58,
61, 65, 66, 68, 73, 76
chip and pin 21, 45, 48, 49, 73
CHP 41
Cityzi 28, 29, 49, 87, 89, 90. See alsoAFSCM
CKLA 50, 51, 52
cloud 13
coil 32, 62
combo chip 65, 66
Confidential Key Loading Authority. SeeCKLA
Connection Handover Protocol. SeeCHP
contactless card 5, 7, 8, 10, 13, 14, 17, 18, 19, 20,
32, 33, 35, 46, 61, 62, 63
contactless interface 85
contactless terminal 7, 19, 85
Controlling Authority Security Domain 51, 52
coupon 5, 8, 20, 2093, 22, 23, 41, 42, 69, 70, 85
credential 16, 27, 46, 49
credit 13, 14, 20, 45, 48, 53, 56, 78, 79
cryptographic 47, 52
cryptography 47, 72
access control 5, 7, 8, 13, 21, 47

Action record 39
active 7, 66
advertising 5, 39, 84, 85
AFSCM 29, 91, 93. See alsoCityzi
Android 68, 73
antenna 5, 17, 18, 32, 34, 48, 59, 61, 62, 63, 64, 67,
71, 75, 76, 77
anti-collision 71
APDU 72
API 31, 43, 44, 72, 83
Apple 68
application 6, 8, 9, 10, 11, 12, 13, 15, 19, 21, 22,
23, 24, 25, 26, 27, 30, 31, 35, 36, 38, 39, 40,
41, 42, 43, 44, 45, 46, 47, 48, 50, 51, 52, 53,
54, 55, 56, 57, 58, 59, 60, 61, 62, 64, 66, 67,
68, 69, 70, 73, 75, 76, 77, 78, 79, 80, 82, 83,
84, 85, 86, 87, 88, 89, 90, 91, 92, 93
Application Programming Interface. SeeAPI
Application Protocol Data Unit. SeeAPDU
app store 12, 24, 25, 43, 84, 86, 87
Association Franaise pour le Sans Contact
Mobile. SeeAFSCM
ATMs 12, 19
authenticates 47
Authorized Mode 55, 56, 57
B
back office 18, 25, 30, 47, 57, 78, 79, 80, 81, 82,
83, 91, 92
baseband 50, 59, 60, 61, 64, 65, 66, 67, 72, 73
battery 18, 32, 33, 34, 62, 64, 77
BlackBerry 73
Bluetooth 9, 11, 12, 40, 41, 43, 63, 65, 67, 75, 77
boarding passes 13, 14
Broadcom 33
D
data transfer rate 11, 33
Delegated Mode 55, 56
DES 40, 73
digital signature 40, 47, 73
domain 21, 27, 48, 50, 51, 52, 53, 54, 55, 56, 57,
58, 59, 88, 89
Page 95
Index
drivers license 15
dynamic tag 33, 34
E
embedded secure element 45, 59, 60, 66, 73, 92
EMV 21, 48
EMVCo 49
encryption 26, 47, 48, 50, 52, 53, 70, 71, 72, 73, 83
ETSI 70, 71
ETSI TS 102 613 70. See alsoSWP
ETSI TS 102 622 71. See alsoHCI
European Telecommunications Standards
Institute. SeeETSI
F
Facebook 11
FeliCa 13, 33, 46
ferrite 64
framework 27
G
Generic Control Record Type Definition 38
GlobalPlatform 27, 49, 50, 52, 56, 60
Google 23, 68, 73
Google Wallet 23, 73
government 5, 13, 15
government benefits 15
GPS 63, 65, 67
GSM 49, 70
GSMA 45, 49, 66, 70, 74
H
handset maker 21, 28
handshake 18
Hardware Security Module. SeeHSM
HCI 70, 71
healthcare 9, 15, 34
Host Controller Interface. SeeHCI
HSM 57, 58
I
IBM 68
Icon record 39
ID 5, 7, 13, 15, 19, 21, 23, 46, 49, 50, 68, 78, 79,
82, 87, 89
identification 13, 15, 71, 81
identity 21, 45, 47, 49, 57, 67, 69, 77, 81
idTech 89
infrastructure 24, 25, 26, 27, 28, 29, 31, 45, 57, 75,
80, 83, 91
infrastructure manager 24, 83
initiator 40, 41, 62
initiator mode 40, 41
inlay 32
Innovision Research & Technology 33
Page 96
Integrated Circuit Card Identifier (ICC-ID) 50

interference 63, 64
International Mobile Subscriber Identity (IMSI)
50
iOS 68
iPhone 76
ISD 51, 54
Isis 28
ISO/IEC 14443 13, 33, 46
ISO/IEC 15693 13, 46
ISO/IEC 18092 7
Issuer Security Domain. SeeISD
J
Java 24, 43, 67, 68, 72
Java ME 43
Java Runtime Environment 43, 67, 68
Java Specification Request (JSR) 43
jpeg 36, 39
JSR 82 43
JSR 177 72, 73, 83
JSR 257 43, 44
K
key 13, 16, 21, 22, 23, 27, 42, 45, 47, 49, 50, 52,
53, 54, 55, 56, 57, 58, 59, 72, 74, 77, 88, 91
key management 56
kiosks 85
L
LinkedIn 11
LLCP 40, 41, 42
locks 19, 52
Logical Link Control Protocol. SeeLLCP
loyalty 5, 7, 10, 19, 22, 23, 38, 46, 52
M
magnetic field 48, 62, 64
MasterCard 15, 46, 74
membership 5, 10, 15, 19, 22
Message Begin 36
Message End 36
MicroSD 17, 21, 59, 66, 75, 76, 85
middleware 67, 68
Midlet 24, 43
Mifare 33, 46
MIME 36, 37, 39
MNO 6, 16, 21, 27, 28, 30, 45, 48, 49, 50, 51, 52,
53, 54, 59, 77, 79, 80, 81, 82, 83, 85, 86, 87,
89, 90, 91, 92, 93
mobile network operator. SeeMNO
mobile virtual network operator. SeeMVNO
mobile wallet 6, 17, 21, 22, 23, 27, 61, 67, 68, 69,
70, 86, 91
MP3 12
Index
mpeg 36
MSISDN 50
MVNO 54
public key cryptography 47, 72
radio frequency. SeeRF

reader 4, 18, 19, 20, 33, 35, 48, 63
read/write 8, 17, 20, 33, 76
read/write mode 7, 8, 20
receipts 22
Record Type Definition. SeeRTD
remote control 12, 42
rewards 12, 23
RF 7, 17, 18, 32, 61, 71, 72, 77
RFID 5, 18, 32, 33, 34, 61, 65
rights 29, 51, 53, 54
RIM 64
RSA 40, 73
RTD 36, 37, 38, 39, 40
NDEF 35, 36, 37, 38, 39, 40, 42

NFC Business Models 29
NFC controller 6, 17, 61, 64, 65, 66, 67, 68, 70,
71, 72, 75
NFC Data Exchange Format. SeeNDEF
NFC-F 46
NFC Forum 7, 10, 11, 19, 31, 32, 33, 34, 35, 36,
37, 38, 40, 41, 42, 43, 73, 74
NFC Forum Certification Mark 74
NFCIP-1 7
N-Mark 74
Nokia 64
non-repudiation signature 73
NXP 33
O
open loop 15
operating system. SeeOS
OS 6, 24, 28, 31, 43, 44, 45, 67, 68, 81, 84, 92
OTA 6, 14, 15, 16, 22, 25, 26, 43, 50, 51, 55, 56,
57, 58, 67, 78, 80, 81, 83, 84, 86, 88, 89, 93
over the air. SeeOTA
P
P2P 5, 10, 11, 12, 13, 17, 20, 22, 24, 40, 41, 42, 64,
76, 86
pairing 11, 12, 25, 30, 31, 41, 42, 43, 44, 67, 80,
84, 86, 87
passive 7, 32, 33
passports 13, 15, 46
payload 36, 37, 39
PayPass 15, 46
PayWave 15, 46
peer-to-peer. SeeP2P
Peer-to-Peer Mode 7
personal data 24, 25, 27, 48, 61, 68, 82, 84, 87, 88
personalization 10, 21, 47, 55, 56, 57, 79, 85, 88,
89
PIN 14, 60, 72
platform 25, 26, 29, 44, 47, 59, 79, 80, 81, 82, 83,
84
point of sale. SeePOS
poll 40
POS 10, 13, 14, 18, 19, 20, 21, 22, 41, 43, 47, 60,
62, 71, 72, 73, 78, 85
prepaid 13, 14, 22, 23, 24, 50, 53, 88
primary coil 62
protocol 6, 17, 18, 19, 61, 67, 68
protocol stack 6, 17, 61, 67, 68
provisioning 26, 27, 50, 51, 84, 85, 89
proximity 5, 8, 10, 12, 18, 32, 40, 48, 62, 64
S
SaaS 54
Samsung 64
satellite navigation 9
Satsa. SeeJSR 177
SDK 24, 44
secondary coil 62
secure element 6, 14, 17, 20, 21, 22, 23, 24, 25, 26,
27, 28, 29, 30, 42, 44, 45, 46, 47, 48, 49, 55,
56, 57, 58, 59, 60, 61, 62, 64, 65, 66, 67, 68,
69, 70, 71, 72, 73, 74, 75, 76, 77, 79, 80, 81,
82, 83, 84, 86, 87, 88, 89, 91, 92, 93
secure element issuer 22, 25, 27, 28, 29, 55, 56,
57, 58, 59, 66, 76, 80, 81, 83, 86, 89, 91, 92
security guard 9
self service 19, 85
sensors 34
Signature Record Type Definition 39
SIM 21, 45, 48, 49, 50, 51, 52, 53, 54, 55, 58, 59,
66, 67, 69, 70, 71, 72, 73, 75, 76, 77, 81, 88,
90, 91, 92, 93
SIM+antenna 75, 76
Simple Mode 55, 56, 58
Simple NDEF Exchange Protocol. SeeSNEP
Singapore 29
Single Wire Protocol. SeeSWP
Size record 39
smart card 21, 33, 45, 46, 47, 48, 49, 50, 58
smart poster 24, 32, 34, 35, 36, 38, 39, 42, 84
Smart Poster Record Type Definition 38
SMS 38, 39, 83
SMS-C 83
SNEP 42
social media 20
social networking 5, 9, 11
software-as-a-service. SeeSaaS
software development kit. SeeSDK
Sony 13, 33, 41, 46
Page 97
Index
specification 7, 11, 31, 35, 36, 37, 38, 39, 40, 43,
45, 49, 50, 52, 60, 66, 71, 73, 74, 75, 82
SSD 48, 50, 51, 52, 53, 54, 55, 56, 57, 58, 88, 89
SSD manager 52
standards 5, 6, 7, 10, 11, 13, 17, 18, 19, 21, 24, 27,
28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39,
40, 41, 42, 43, 45, 46, 47, 48, 49, 50, 52, 60,
61, 63, 65, 67, 68, 70, 71, 72, 75, 76, 77, 78,
82, 83, 86, 91, 92
sticker 17, 32, 75, 77, 78
subscriber identity module. SeeSIM
supplementary security domain. SeeSSD
supplementary security domain manager.
SeeSSD manager
SWP 70, 71
T
tag 5, 6, 7, 8, 9, 10, 16, 17, 18, 19, 20, 22, 24, 25,
30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41,
42, 43, 61, 62, 63, 64, 65, 67, 76, 78, 84, 85
tamper-resistant 20
target 40, 41, 62
target mode 40, 41
TCP/IP 68
TEE 59, 60
telephone number 8, 38
terminal 5, 6, 7, 8, 10, 13, 14, 18, 19, 20, 21, 22,
41, 43, 47, 48, 61, 62, 67, 71, 72, 73, 78, 85
Text Record Type Definition 38
The Open Group 74
ticket 13, 14, 15, 18, 19, 26, 46, 69, 76
ticketing 5, 7, 8, 11, 19, 21, 46, 47, 52, 85
Title record 39
TNF 37
Topaz 33
train 14, 84
TransferJet 41
transportation 5, 7, 14, 15, 19, 26, 29, 74, 76
Trusted Computing Group 60
trusted environment 24, 60
Trusted Execution Environment. SeeTEE
trusted service manager. SeeTSM
trusted token 27
TSM 26, 27, 28, 29, 51, 52, 53, 56, 80, 81, 83
TV 12, 42
Twitter 11
Type Name Format. SeeTNF
Type record 39
US Department of Defense 21
V
vCard 11, 36, 39
vending 19
vEvent 36
vicinity card 46
video 11, 12, 36, 41
viral 11, 84, 86
virtual private network. SeeVPN
Visa 15, 46, 74
voucher 8, 13, 23
VPN 58, 83
vTodo 36
W
WAP 83, 85
website address 36, 37, 38
WiFi 9, 11, 41, 63, 65, 75, 77
U
UICC 49, 70, 71
Universal Integrated Circuit Card. SeeUICC
URI 36, 37, 38, 39
URI Record Type Definition 37
URL 4, 8, 35, 38, 84
USB 20
Page 98

NFC Technologies and Systems

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NFC Technologies and Systems

Uploaded by

Copyright:

Available Formats

By Sarah Clark

This report and man

A clear and comprehensive guide to how

NFC Technologies and Systems

Published by SJB Research

NFC Technologies and Systems

ISBN 978-0-9564762-4-1 (Book)

NFC PAIRING AND SHARING. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

NFC TECHNOLOGIES AND SYSTEMS

SJB Research Ltd 2012-2014 All rights reserved

Cheaper production technologies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

THE SECURE ELEMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

NFC TECHNOLOGIES AND SYSTEMS

SJB Research Ltd 2012-2014 All rights reserved

The NFC controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

DELIVERING NFC SERVICES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

NFC TECHNOLOGIES AND SYSTEMS

SJB Research Ltd 2012-2014 All rights reserved

A word about web links

NFC TECHNOLOGIES AND SYSTEMS

SJB Research Ltd 2012-2014 All rights reserved

Near field communication (NFC) is a short-range wireless communication

SJB Research Ltd 2012-2014 All rights reserved

The three modes of NFC devices

NFC TECHNOLOGIES AND SYSTEMS

SJB Research Ltd 2012-2014 All rights reserved

NFC TECHNOLOGIES AND SYSTEMS

SJB Research Ltd 2012-2014 All rights reserved

In read/write mode, an NFC device can do one of three things:

Example use cases

An NFC device can download an app or detailed information about a product or

NFC TECHNOLOGIES AND SYSTEMS

SJB Research Ltd 2012-2014 All rights reserved

NFC tags can be used in both consumer and business-to-business environments to

Purchase a product or sign up for a service

NFC tags attached to product packaging, to products, or to merchandising displays

Initiate multiple actions

An NFC tag can be programmed so that a series of instructions will be performed

NFC TECHNOLOGIES AND SYSTEMS

SJB Research Ltd 2012-2014 All rights reserved

Create dependent actions

Read a contactless card

NFC TECHNOLOGIES AND SYSTEMS

SJB Research Ltd 2012-2014 All rights reserved

Example use cases

SJB Research Ltd 2012-2014 All rights reserved

Device and equipment pairing

NFC TECHNOLOGIES AND SYSTEMS

SJB Research Ltd 2012-2014 All rights reserved

Card emulation mode

Example use cases

NFC TECHNOLOGIES AND SYSTEMS

SJB Research Ltd 2012-2014 All rights reserved

Tickets and passes

NFC TECHNOLOGIES AND SYSTEMS

SJB Research Ltd 2012-2014 All rights reserved

NFC TECHNOLOGIES AND SYSTEMS

SJB Research Ltd 2012-2014 All rights reserved

Keys and credentials

The building blocks of NFC

NFC TECHNOLOGIES AND SYSTEMS

SJB Research Ltd 2012-2014 All rights reserved

NFC phones and other devices