Nfc Technologies and Systems

SJB Research

By Sarah Clark

A clear and comprehensive guide to how NFC works, the technical options available and how to unlock its commercial potential

This report and many others are available free of charge at the NFC World+ Knowledge Centre https://members.nfcworld.com

https://members.nfcworld.com

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

http://www.nfcworld.com

http://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

http://www.sjb.co.uk

TABlE OF CONTENTS

NFC TECHNOlOGIES AND SYSTEMS Page 1

Table of contents

1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51.1 The three modes of NFC devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61.1.1 Read/write mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81.1.1.1 Example use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

1.1.1.1.1 Collect a coupon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81.1.1.1.2 Obtain information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81.1.1.1.3 Check in to a location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91.1.1.1.4 Purchase a product or sign up for a service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91.1.1.1.5 Initiate an action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91.1.1.1.6 Initiate multiple actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91.1.1.1.7 Create dependent actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.1.1.1.8 Personalize an action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.1.1.1.9 Read a contactless card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.1.2 Peer-to-peer mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.1.2.1 Example use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.1.2.1.1 Social networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.1.2.1.2 Device and equipment pairing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.1.2.1.3 P2P payments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.1.3 Card emulation mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.1.3.1 Example use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.1.3.1.1 Payments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.1.3.1.2 Tickets and passes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.1.3.1.3 Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.1.3.1.4 Keys and credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.2 The building blocks of NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.2.1 NFC phones and other devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.2.2 NFC tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.2.3 NFC terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.2.4 NFC reader/writers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.2.5 The secure element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.2.6 The mobile wallet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.2.7 NFC applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241.2.8 NFC platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251.2.9 The TSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261.2.10 The NFC infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

1.3 Creating value with NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2 NFC PAIRING AND SHARING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.1 NFC tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.1.1 The four NFC Forum tag types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.1.2 Emerging tag types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

© SJB Research ltd 2012-2014 • All rights reserved

TABlE OF CONTENTS

NFC TECHNOlOGIES AND SYSTEMSPage 2

2.1.2.1 Cheaper production technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.1.2.2 New tag formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.1.2.3 Non-standard chips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.1.2.4 Dynamic tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.2 Writing to NFC tags and cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.2.1 NFC tag data formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.2.1.1 The NFC Data Exchange Format (NDEF) specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.2.1.2 The NFC Record Type Definition (RTD) specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.2.1.3 The URI Record Type Definition specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.2.1.4 The Text Record Type Definition specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.2.1.5 The Generic Control Record Type Definition specification . . . . . . . . . . . . . . . . . . . . . . . . . 382.2.1.6 The Smart Poster Record Type Definition specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.2.1.7 The Signature Record Type Definition specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.3 Peer-to-peer mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.3.1 The logical link Control Protocol (llCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.3.2 The Connection Handover Protocol (CHP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.3.3 The Simple NDEF Exchange Protocol (SNEP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.4 Sharing and pairing apps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.4.1 The JSR 257 Contactless Communications API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.4.2 Smartphone apps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3 THE SECURE ELEMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.1 What can be stored in a secure element? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.2 How secure elements keep sensitive data secure . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.3 Secure element certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.4 The SIM as secure element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.4.1 The three parties on an NFC SIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.4.1.1 The mobile network operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.4.1.2 The Confidential Key loading Authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.4.1.3 The Supplementary Security Domain (SSD) owners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.4.2 Types of Supplementary Security Domain owners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.4.2.1 Mobile network operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.4.2.2 Mobile virtual network operators (MVNOs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.4.2.3 Third parties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.4.2.4 Service providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.4.3 Creating a supplementary security domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.4.3.1 Fully preloaded SSDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.4.3.2 SSDs created partially over-the-air . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.4.3.3 SSDs created fully over-the-air . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.4.3.4 SSD creation modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.4.3.4.1 Simple Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.4.3.4.2 Delegated Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.4.3.4.3 Authorized Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.4.4 Distributing the keys to the new domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.4.4.1 SSD created and assigned at the factory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.4.4.2 SSD created at factory but not assigned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.4.4.3 SSD created over-the-air . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.5 Embedded secure elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.6 External secure elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.7 Trusted Execution Environments (TEEs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4 NFC PHONES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.1 The antenna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.1.1 NFC antenna design constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.1.1.1 Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.1.1.2 location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.1.1.3 Interference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.1.2 Types of NFC antenna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64


TABlE OF CONTENTS


4.2 The NFC controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.2.1 Future developments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.2.1.1 Combo controller chips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.2.1.2 Baseband controller chips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.2.2 Supporting multiple secure elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.3 The main processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.3.1 The NFC protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.3.2 The mobile wallet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.4 NFC phone security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.4.1 HCI and SWP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.4.1.1 The Single Wire Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.4.1.2 The Host Controller Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.4.2 The JSR 177 Security and Trust Services API (Satsa) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.5 NFC phone certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.5.1 The NFC Forum device certification programme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.5.2 Vertical market certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744.5.3 local market certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.6 Adding NFC to existing phones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754.6.1 MicroSD card solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754.6.2 NFC cases and sleeves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.6.3 SIM+antenna solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.6.4 All-in-one NFC SIMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.6.5 Bluetooth and WiFi peripherals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.6.6 Contactless stickers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.7 Other NFC devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5 DELIVERING NFC SERVICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.1 Pre-launch requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805.1.1 NFC platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805.1.1.1 Secure element issuer platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.1.1.2 Service provider platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825.1.1.3 Connecting the dots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

5.1.2 App approval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.2 Enabling customers to request the NFC service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.2.1 Via a smart poster or tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.2.2 At the point of service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.2.3 Via consumer request to a contact centre or website . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.2.4 In response to marketing and advertising campaigns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.2.5 Via direct distribution of an NFC add-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.2.6 Via an app store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.2.7 Via the mobile wallet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.2.8 Viral distribution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

5.3 NFC app delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.3.1 Checking phone and contract compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.3.2 loading the NFC app onto the customer’s device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.3.2.1 Fully and partly pre-loaded NFC applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.3.2.2 loading NFC applications over-the-air . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

5.4 Maintaining and upgrading an NFC service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905.4.1 Managing customer service enquiries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915.4.2 lost/stolen phone blocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915.4.3 Change of SIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925.4.4 Change of phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925.4.5 Cancellation of mobile network service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95


WEB lINKS


A word about web links

We’ve 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 you’ll 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 you’re reading the printed version of this document you’ll need to type the links into your browser manually. We have used a link shortener to make this easier; you’ll notice that the address bar on your browser will change to reflect the page’s 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 [email protected] and we’ll fix them where possible. Doing this will benefit you and all other users of this report.


http://www.nearfieldcommunicationsworld.com

http://www.nearfieldcommunicationsworld.com

mailto:info%40sjb.co.uk?subject=Broken%20link%28s%29%20in%20research%20report

INTRODUCTION


1 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 low-cost 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.


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 phone’s processor to enable it to leverage the phone’s NFC capabilities.

• A mobile wallet that lets the phone’s 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:


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.


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 device’s 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.


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 user’s 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 shopper’s 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 phone’s 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 driver’s preferences for seating position, radio station and mirrors.


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 user’s 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.


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.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 contact’s 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


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 friend’s 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


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 customer’s 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.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:


INTRODUCTION


• Pay now. NFC enables a digital version of a debit card to be stored in a phone’s secure element, allowing purchases to be automatically debited from the user’s 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 merchant’s 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.


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 Visa’s PayWave and MasterCard’s 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, cost-effective 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.


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.


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.


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


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 retailer’s 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.


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 phone’s 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 consumer’s credit card details, is kept safe from hackers and fraudsters.


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 provider’s data is stored within the secure element in that provider’s own secure compartment, known as a “Supplementary Security Domain”, ensuring that each company’s 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 provider’s 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


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 phone’s main memory within an independently provided app, thus allowing businesses to offer services which use only NFC tag reading and/or peer-to-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 don’t fit into a traditional wallet.


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.


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 provider’s logo can be displayed on the phone’s 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 device’s secure element. It contains two elements — application code specific to the NFC service and personal data relating to the individual user of the device.


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 phone’s 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 consumer’s details to be securely sent from the service provider’s back office system over-the-air to that consumer’s 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.


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 today’s 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 over-the-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 issuer’s 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


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 provider’s NFC application into a new domain, provision it with an individual user’s 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


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 country’s 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


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


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 in-depth 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 NFC’s 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.


NFC PAIRING AND SHARING


2 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.




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.




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 NXP’s 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 Sony’s 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




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.




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 contact’s 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 buyer’s 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




to an NFC tag. NDEF, along with the NFC Forum’s 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 Forum’s 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 individual’s 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.




• 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 Forum’s 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 Forum’s 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.




2.2.1.4 The Text Record Type Definition specification

The NFC Forum’s 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 Forum’s 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.




The Smart Poster RTD sets out the way in which a tag built into a smart poster should be programmed so that the smart poster’s 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 device’s 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.




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 NFC-equipped 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 Forum’s 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




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 Sony’s TransferJet to enable information to be transferred both easily and quickly.

The NFC Forum’s 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




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 peer-to-peer connection is established. The recipient doesn’t 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 phone’s NFC interface into their programs.

NFC sharing and pairing applications do not need to have access to the phone’s secure element, so applications of this type can be executed entirely on the phone’s 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 don’t need any special permissions in order to write NFC apps of this type. Access to programming




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 phone’s 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 phone’s Bluetooth features. JSR 257, also referred to as the Contactless Communications API, builds on the NFC Forum’s 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 device’s 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 issuer’s app on the handset when a consumer first touches their phone to a point-of-sale terminal, to allow the issuer’s logo to be displayed to the user.




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.


THE SECURE ElEMENT


3 The secure element

The secure element is the key to ensuring that sensitive data stored on an NFC phone, such as a consumer’s 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 GSMA’s 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.


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 technology’s 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 Sony’s 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 device’s 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 consumer’s 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


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 chip’s memory may only be accessed if the chip’s 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


THE SECURE ElEMENT


organisation’s applications stored securely in their own, independent area of the card’s 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 world’s 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 phone’s 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 provider’s 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 customer’s credit card account details does need to be shared, all communications use secure routes and employ the latest encryption standards.


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.

GlobalPlatform’s 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 customer’s mobile device to enable the operator to establish a link between each individual customer and their preferred choice of handset.


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 user’s 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 customer’s phone bill or deduct funds accurately from a prepaid account balance.

Because the SIM is central to the mobile network operator’s 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 phone’s 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 GlobalPlatform’s 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


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 SIM’s over-the-air (OTA) provisioning capabilities, to facilitate the creation and assignment of Supplementary Security Domains and to provide overall management of the SIM’s 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 provider’s Supplementary Security Domain is secured by its own set


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 GlobalPlatform’s 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 SIM’s 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


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 doesn’t 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 operator’s 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.


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 consumer’s 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 provider’s 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


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 customer’s 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 provider’s 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.


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 customer’s 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.


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 issuer’s secure elements being installed with a particular service provider’s 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 provider’s key over-the-air. 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 provider’s back office system either via a


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 consumer’s 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 customer’s 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.


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 device’s 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 phone’s application processor that can be used to store


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 Group’s 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 phone’s 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 device’s screen. The consumer would then be able to input their PIN using their phone’s keypad without compromising security.


NFC PHONES


4 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 user’s 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 phone’s 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


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 phone’s battery to power up the NFC tag. Here, the phone acts as the primary coil and the phone’s 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 phone’s 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 phone’s 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.


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 phone’s 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


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 device’s 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 device’s 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 phone’s main baseband or application processor, allowing applications that make use of tag reading/writing and peer-to-peer functionality to be stored in the phone’s 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.


NFC PHONES


4.2.1 Future developments

Current generation NFC phones use dedicated NFC controller chips, specifically designed to manage the phone’s 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.


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 today’s simpler feature phones as well as some leading edge smartphones, contain a single chip which handles both mobile communications and application processing. Most of today’s mobile phones, however, contain two main processors, an application processor and a baseband processor.


NFC PHONES


The application processor hosts the phone’s 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 phone’s 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 phone’s subscriber identity module.

For NFC applications to be able to leverage a mobile phone’s 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 phone’s NFC controller and its secure element. This enables the phone, and NFC applications stored in the phone’s 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 phone’s 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 phone’s 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 phone’s main memory to provide security and to provide the phone’s 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 phone’s 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 phone’s 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 don’t speak a common language and may in fact be built using fundamentally different principles. This is similar to the function


NFC PHONES


performed by the TCP/IP protocol stack which forms the foundation of the internet’s 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 phone’s 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 Google’s Android and Apple’s 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 phone’s 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,


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 phone’s 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 phone’s 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.


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 retailer’s 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 phone’s 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 phone’s 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


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 phone’s NFC controller and, from there, via the phone’s 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 aren’t 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.


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 phone’s 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:


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-of-sale terminals.

• The data cannot be tampered with in transit without the SIM knowing. This is done by using the SIM’s 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.


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 Forum’s 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 Forum’s specifications and certification programme cover a device’s 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 Visa’s 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 phone’s functionality, including both security and performance benchmarks.


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 today’s 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.


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 handset’s 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 device’s 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 full-size 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.


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 user’s 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.


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.


DElIVERING NFC SERVICES


5 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 operator’s 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




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 consumer’s details to be securely sent from the service provider’s back office system over-the-air, or through other means, to that consumer’s 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




network operator in the country in which it operates, since the bank’s 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 provider’s 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 customer’s 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 customer’s 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 subscriber’s 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




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 today’s services.

5.1.1.2 Service provider platforms

The complexity of a service provider’s 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 customer’s 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 customer’s existing card number and data. This ID can be loaded onto the secure element during manufacturing and then tied to a customer’s 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.




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 provider’s 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 operator’s 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 operator’s 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 operator’s NFC OTA platform and a service provider’s 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.




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 customer’s 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




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 phone’s contactless interface and could be combined with downloading the application to the phone from the terminal, again using the phone’s 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 operator’s 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 provider’s 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




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 customer’s 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




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 consumer’s 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 consumer’s 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 customer’s mobile phone number to the customer’s 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 provider’s 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 customer’s secure element and the customer ID number used by the service provider.

5.3.2 Loading the NFC app onto the customer’s device

A number of different options are available for downloading an NFC application to a consumer’s 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 device’s 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 customer’s personal data.




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 provider’s 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 customer’s 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 customer’s 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 provider’s 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.




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 customer’s 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 customer’s handset by, for instance, requesting the customer’s 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 customer’s phone will support the service provider’s application, if the customer’s mobile phone contract includes NFC service provision and if there is sufficient space in the customer’s 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




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 customer’s 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 customer’s SIM is replaced by the mobile network operator, for example, when the customer’s 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 customer’s phone is lost or stolen and when they upgrade their phone. And, from a service provider’s point of view, procedures must also be established for what happens if the customer’s 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.




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 consumer’s 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 phone’s 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.




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 customer’s 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 consumer’s 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 handset’s 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.




5.4.5 Cancellation of mobile network service

Finally, where the mobile network operator is the issuer of the secure element, cancellation of a consumer’s 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.



NFC TECHNOlOGIES AND SYSTEMSPage 94© SJB Research ltd 2012-2014 • All rights reserved

INDEx


Symbols

3G 49, 63

A

access control 5, 7, 8, 13, 21, 47Action record 39active 7, 66advertising 5, 39, 84, 85AFSCM 29, 91, 93. See also CityziAndroid 68, 73antenna 5, 17, 18, 32, 34, 48, 59, 61, 62, 63, 64, 67,

71, 75, 76, 77anti-collision 71APDU 72API 31, 43, 44, 72, 83Apple 68application 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. See APIApplication Protocol Data Unit. See APDUapp store 12, 24, 25, 43, 84, 86, 87Association Française pour le Sans Contact

Mobile. See AFSCMATMs 12, 19authenticates 47Authorized 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, 73battery 18, 32, 33, 34, 62, 64, 77BlackBerry 73Bluetooth 9, 11, 12, 40, 41, 43, 63, 65, 67, 75, 77boarding passes 13, 14Broadcom 33

bus 8, 14, 39

C

card emulation 5, 13, 17, 20, 46, 62, 75, 76, 77, 78Card Emulation Mode 7Cardlet 24car parking 19CDMA 49certification 49, 70, 73, 74, 75check in 9, 16, 20check out 16China UnionPay 75chip 6, 17, 18, 20, 21, 32, 33, 34, 45, 47, 48, 49, 58,

61, 65, 66, 68, 73, 76chip and pin 21, 45, 48, 49, 73CHP 41Cityzi 28, 29, 49, 87, 89, 90. See also AFSCMCKLA 50, 51, 52cloud 13coil 32, 62combo chip 65, 66Confidential Key Loading Authority. See CKLAConnection Handover Protocol. See CHPcontactless card 5, 7, 8, 10, 13, 14, 17, 18, 19, 20,

32, 33, 35, 46, 61, 62, 63contactless interface 85contactless terminal 7, 19, 85Controlling Authority Security Domain 51, 52coupon 5, 8, 20, 20–93, 22, 23, 41, 42, 69, 70, 85credential 16, 27, 46, 49credit 13, 14, 20, 45, 48, 53, 56, 78, 79cryptographic 47, 52cryptography 47, 72

D

data transfer rate 11, 33Delegated Mode 55, 56DES 40, 73digital signature 40, 47, 73domain 21, 27, 48, 50, 51, 52, 53, 54, 55, 56, 57,

58, 59, 88, 89

Index


INDEx


drivers license 15dynamic tag 33, 34

E

embedded secure element 45, 59, 60, 66, 73, 92EMV 21, 48EMVCo 49encryption 26, 47, 48, 50, 52, 53, 70, 71, 72, 73, 83ETSI 70, 71ETSI TS 102 613 70. See also SWPETSI TS 102 622 71. See also HCIEuropean Telecommunications Standards

Institute. See ETSI

F

Facebook 11FeliCa 13, 33, 46ferrite 64framework 27

G

Generic Control Record Type Definition 38GlobalPlatform 27, 49, 50, 52, 56, 60Google 23, 68, 73Google Wallet 23, 73government 5, 13, 15government benefits 15GPS 63, 65, 67GSM 49, 70GSMA 45, 49, 66, 70, 74

H

handset maker 21, 28handshake 18Hardware Security Module. See HSMHCI 70, 71healthcare 9, 15, 34Host Controller Interface. See HCIHSM 57, 58

I

IBM 68Icon record 39ID 5, 7, 13, 15, 19, 21, 23, 46, 49, 50, 68, 78, 79,

82, 87, 89identification 13, 15, 71, 81identity 21, 45, 47, 49, 57, 67, 69, 77, 81idTech 89infrastructure 24, 25, 26, 27, 28, 29, 31, 45, 57, 75,

80, 83, 91infrastructure manager 24, 83initiator 40, 41, 62initiator mode 40, 41inlay 32Innovision Research & Technology 33

Integrated Circuit Card Identifier (ICC-ID) 50interference 63, 64International Mobile Subscriber Identity (IMSI)

50iOS 68iPhone 76ISD 51, 54Isis 28ISO/IEC 14443 13, 33, 46ISO/IEC 15693 13, 46ISO/IEC 18092 7Issuer Security Domain. See ISD

J

Java 24, 43, 67, 68, 72Java ME 43Java Runtime Environment 43, 67, 68Java Specification Request (JSR) 43jpeg 36, 39JSR 82 43JSR 177 72, 73, 83JSR 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 56kiosks 85

L

LinkedIn 11LLCP 40, 41, 42locks 19, 52Logical Link Control Protocol. See LLCPloyalty 5, 7, 10, 19, 22, 23, 38, 46, 52

M

magnetic field 48, 62, 64MasterCard 15, 46, 74membership 5, 10, 15, 19, 22Message Begin 36Message End 36MicroSD 17, 21, 59, 66, 75, 76, 85middleware 67, 68Midlet 24, 43Mifare 33, 46MIME 36, 37, 39MNO 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. See MNOmobile virtual network operator. See MVNOmobile wallet 6, 17, 21, 22, 23, 27, 61, 67, 68, 69,

70, 86, 91MP3 12


INDEx


mpeg 36MSISDN 50MVNO 54

N

NDEF 35, 36, 37, 38, 39, 40, 42NFC Business Models 29NFC controller 6, 17, 61, 64, 65, 66, 67, 68, 70,

71, 72, 75NFC Data Exchange Format. See NDEFNFC-F 46NFC Forum 7, 10, 11, 19, 31, 32, 33, 34, 35, 36,

37, 38, 40, 41, 42, 43, 73, 74NFC Forum Certification Mark 74NFCIP-1 7N-Mark 74Nokia 64non-repudiation signature 73NXP 33

O

open loop 15operating system. See OSOS 6, 24, 28, 31, 43, 44, 45, 67, 68, 81, 84, 92OTA 6, 14, 15, 16, 22, 25, 26, 43, 50, 51, 55, 56,

57, 58, 67, 78, 80, 81, 83, 84, 86, 88, 89, 93over the air. See OTA

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, 33passports 13, 15, 46payload 36, 37, 39PayPass 15, 46PayWave 15, 46peer-to-peer. See P2PPeer-to-Peer Mode 7personal data 24, 25, 27, 48, 61, 68, 82, 84, 87, 88personalization 10, 21, 47, 55, 56, 57, 79, 85, 88,

89PIN 14, 60, 72platform 25, 26, 29, 44, 47, 59, 79, 80, 81, 82, 83,

84point of sale. See POSpoll 40POS 10, 13, 14, 18, 19, 20, 21, 22, 41, 43, 47, 60,

62, 71, 72, 73, 78, 85prepaid 13, 14, 22, 23, 24, 50, 53, 88primary coil 62protocol 6, 17, 18, 19, 61, 67, 68protocol stack 6, 17, 61, 67, 68provisioning 26, 27, 50, 51, 84, 85, 89proximity 5, 8, 10, 12, 18, 32, 40, 48, 62, 64

public key cryptography 47, 72

R

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

S

SaaS 54Samsung 64satellite navigation 9Satsa. See JSR 177SDK 24, 44secondary coil 62secure 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 9self service 19, 85sensors 34Signature Record Type Definition 39SIM 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, 76Simple Mode 55, 56, 58Simple NDEF Exchange Protocol. See SNEPSingapore 29Single Wire Protocol. See SWPSize record 39smart card 21, 33, 45, 46, 47, 48, 49, 50, 58smart poster 24, 32, 34, 35, 36, 38, 39, 42, 84Smart Poster Record Type Definition 38SMS 38, 39, 83SMS-C 83SNEP 42social media 20social networking 5, 9, 11software-as-a-service. See SaaSsoftware development kit. See SDKSony 13, 33, 41, 46


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, 89SSD manager 52standards 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, 78subscriber identity module. See SIMsupplementary security domain. See SSDsupplementary security domain manager.

See SSD managerSWP 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 20target 40, 41, 62target mode 40, 41TCP/IP 68TEE 59, 60telephone number 8, 38terminal 5, 6, 7, 8, 10, 13, 14, 18, 19, 20, 21, 22,

41, 43, 47, 48, 61, 62, 67, 71, 72, 73, 78, 85Text Record Type Definition 38The Open Group 74ticket 13, 14, 15, 18, 19, 26, 46, 69, 76ticketing 5, 7, 8, 11, 19, 21, 46, 47, 52, 85Title record 39TNF 37Topaz 33train 14, 84TransferJet 41transportation 5, 7, 14, 15, 19, 26, 29, 74, 76Trusted Computing Group 60trusted environment 24, 60Trusted Execution Environment. See TEEtrusted service manager. See TSMtrusted token 27TSM 26, 27, 28, 29, 51, 52, 53, 56, 80, 81, 83TV 12, 42Twitter 11Type Name Format. See TNFType record 39

U

UICC 49, 70, 71Universal Integrated Circuit Card. See UICCURI 36, 37, 38, 39URI Record Type Definition 37URL 4, 8, 35, 38, 84USB 20

US Department of Defense 21

V

vCard 11, 36, 39vending 19vEvent 36vicinity card 46video 11, 12, 36, 41viral 11, 84, 86virtual private network. See VPNVisa 15, 46, 74voucher 8, 13, 23VPN 58, 83vTodo 36

W

WAP 83, 85website address 36, 37, 38WiFi 9, 11, 41, 63, 65, 75, 77


Nfc Technologies and Systems

Documents