A Framework for the Service Model of NFC Stack

Ying-Jue Cai and Jie Shen

1.Introduction

Near field communications (NFC) is a brand-new technology which enables short-range wireless communications between devices and tags at a distance of a few centimeters for data exchanging.NFC, building on the radio frequency identification (RFID) standard (ISO/IEC 14443), is able to power and read NFC compatible smartcards, so that information can be exchanged between peers.

Generally, the NFC technology can be used to replace manual typing, menu selections, and other user interface actions with acts of touching[1], the basis of which is data exchanging and communications.To make communications between various NFC-enabled devices possible and interoperable, NFC Forum has formulated several data formats for NFC applications.Thus, an NFC data exchange format (NDEF)[2]structure is specified by NFC Forum.

1.1 NFC Data Exchange Format

NDEF defines the data formats (called NDEF records)for the exchange of information.An NDEF record consists of a header field and a payload field for the actual data.The payload field of an NDEF record is formatted according to the type of information, which is then represented by record type definition (RTD)[3].The RTDs are designed for well-known use cases and facilitate any NFC interactions.The following lists 5 kinds of RTDs that are commonly used and are also supported in our service model:

· Text RTD[4]: A text data that includes language information.For example, the string “Hello, world!” is encoded in 20 bytes (4 bytes for the NDEF header, 3 bytes for language information, and 13 bytes for the string) in NDEF format.

· Universal resource identifier (URI) RTD[5]: A resource identifier indicating the Internet address, e-mail address,telephone numbers, SMS messages, etc.For example, the URL “http://www.nfc.org” is encoded in 12 bytes (4 bytes for the NDEF header, 1 byte for URI header code, and 7 bytes for the URL which are encoded as “nfc.org”) in the NDEF format.

· Smart poster RTD[6]: A combination of text and URI RTD to build a complete informative record that is capable of taking an action such as opening a web page.

· Generic control RTD[7]: A compound RTD which provides a way to request an action from an NFC-enabled device from another NFC tag or device.For example, it can activate the vibrate mode with an AT command understood by most phones.

· Signature RTD[8]: An RTD that provides integrity to NDEF records.The mechanism used by this record is based on the digital signature and certificates.The data of signature algorithm, digital signature, and certificate chains are serialized and formatted in this record.It is currently the only way to provide confidentiality in NFC applications.

1.2 NFC Data Flow on Android

At present, NFC-enabled smart phones are becoming popular in the smart phone market, which makes smart phones available for contactless payment and ticket applications.Besides, it creates a new way to obtain information.For example, a series of actions can be triggered via touching an NFC-related object that contains URLs.These NFC-enabled smart phones all build on the Android system.As the result, our framework for the service model of NFC Stack is constructed on the Android operation system.

To construct the framework, we should have a better understanding of the Android NFC stack.The Android itself has provided a set of mechanisms for NFC-related operations[9], which is encapsulated as the NFC stack in its application framework layer of the system (see Fig.1).When involving NFC-related operations, such as reading and writing tags, the application will generally invoke NFC APIs (application program interfaces) in the NFC stack to interact with NFC tags or devices (see Fig.2 ①).Upon gaining the data from NFC-related objects, Android encapsulates the data in raw bytes and dispatches it to the designated application via an ‘Intent’[9]object (see Fig.2②).The application is notified once the ‘Intent’ object is received, and then the application should judge if the data,encapsulated in the ‘Intent’ object, are really what it needs.If so, the raw data, in the form of an NDEF message, are exacted and the application gets a byte array containing the serialized payload data (see Fig.2 ③) which are composed of key information and other appending NDEF information.

The next step for the application is to reconstruct the serialized data, so as to get the actual information (see Fig.2 ④).The serialized data (in the form of a byte stream) are in accordance with the RTD.The parsing of RTD, i.e.the reconstruction of an NDEF record, is a complicated procedure.The application shall decide which kind of RTDs it is and then refer to the definition of the RTD to parse the serialized data step by step.Through these complicated processes, the actual information is exacted from the NDEF record which might be a text, a URL, an operation instruction, and even an image.

Fig.1.Android OS framework model.

Fig.2.Data flow model of NFC stack.

Ultimately, after gaining the final information, the application will generally perform corresponding actions according to different scenarios and information (see Fig.2⑤).For example, a designated webpage will be opened if the information is a URL serialized in a URI record.However, when the cellular network is deactivated, the URL will be saved as a bookmark in the Internet browser.In another word, a context-awareness[10]feature should be taken into consideration to take actions accordingly.Through statistics, the proposed actions, executed on gaining the information from NFC-related objects, are simply alike.These actions include the followings: making a phone call, sending SMS messages, sending an E-mail,downloading files from a designated URL, opening a webpage, launching a designated application or file on the device, and saving the gained information.Now that every application will perform similar actions, it seems apparently that they are just doing unnecessary and redundant works repeatedly.And usually, more than one action is executed upon gaining data by NFC.How to organize each action logically according to the context is also a difficult issue.

Through the above analysis, it can be concluded that the application framework layer of Android has completed part of the work needed for NFC applications, including the bottom-level I/O operation, and the encapsulation and dispatch of NDEF messages.But much of the work is left undone to the application itself, in another word, for the programmer, which requires lots of knowledge about NFC technology and RTDs.This makes it difficult for the programmer to develop NFC-related applications on Android only by utilizing NFC APIs in the NFC stack.

In addition to that, the NFC stack has not provided any mechanism for security issues of NFC, making an NFC-enabled smart phone vulnerable for attacks and phishing.Possibly, the content of an NFC tag can easily be overridden for malicious reasons.By, for instance,manipulating Internet addresses or telephone numbers in smart poster tags, it is possible to redirect the user to a forged website for phishing user credentials or trick the user into sending an SMS message to a costly premium rate service[11].Due to the lack of security mechanisms, the user will not receive any warnings and may be taken in on these occasions, which leads to possible loss of property.As a consequence, it is indispensible to ensure the integrity and reliability of the data gained.

In conclusion, the existing NFC stack on Android is defective in some extent.It does not provide any features for later data processing and a security mechanism for NFC,therefore a brand-new framework for the service model of NFC is proposed by this paper, which never exists before.

2.Overview of the Brand-New Framework

Based on the analysis of the existing NFC stack on Android, the later data processing is proposed to be added,thus following features are to be considered:

· Reconstruction of RTD payload to exact information.

· A logical, organized, and universal way to describe various actions executed after gaining the information.

· A security mechanism to ensure the integrity and reliability of the data gained via NFC.

· A less complicated way to utilize NFC for applications.

All these proposed features depend on the existing NFC stack which provides raw data gained from NFC tags or devices.Besides, actions can only be performed on the premise that information has already been exacted from the RTD payload.It is not difficult to conclude that the data or information needed for each feature relies on a lower-level one.Its data flow model (see Fig.2) can be easily associated to a multilevel model which is able to provide a logical and organized way to expand the existing NFC stack.Therefore, a three-layer model is concluded to enhance the existing NFC stack.The core idea of the model is to utilize NFC for applications, which are capable of providing high-level services for users, so we call it the service model of the NFC stack (see Fig.3).

As shown in Fig.3, the architecture is a three-layer structure.At the bottom of the architecture lies the NFC stack layer which derives from the existing NFC stack on Android.This layer performs bottom-level operations and interacts with NFC tags or devices.Upon gaining the data,it delivers the raw data encapsulated in an ‘Intent’ object to the upper lever, the RTD parsing & encapsulation layer.The upper layer parses the ‘Intent’ object’s payload data (in forms of byte array) and formulates a corresponding data structure which is then delivered to the service description layer.Information, that origins from payload data and is reconstructed according to RTD specifications, makes up of the data structure (to be defined in the next section).As the service description layer gets the actual information, it will perform the user-defined procedure for later data processing.For instance, if it gets a telephone number, this top layer may launch a phone call accordingly.Of course, it can also send SMS messages only if this action is specified in an acceptable way.

Fig.3.Architecture for service model of NFC stack.

With this service model, the programmer no longer needs to care about how to fetch and parse the NFC data and only lays emphasis on utilizing the data.The process of reconstruction and serialization of RTD payload is completed in the RTD parsing & encapsulation layer.Combing with XML language, the service description layer presents a creative pattern for later data processing which can be deemed to be intelligent with a context-awareness model.A security mechanism (NFC signature verification[12])is also included in this layer to enhance the integrity and reliability of the information.The whole framework masks many complicated operations in lower level, which undoubtedly facilitates the development of NFC-related applications and shortens development cycle.

3.Explicit Implementation of the Framework

As described in the previous section, the framework for the service model of NFC stack shall be divided into two parts.The NFC stack layer can be seen as one part.It is the fundamental part of the whole framework, which, however,needn’t be detailed here (for complete documentation, refer to Android API Guides[13]).On the contrary, the other part is the newly planned expansion which is composed of the service description layer and the RTD parsing &encapsulation layer.The detailed design of this part is to be stated separately.

3.1 RTD Parsing & Encapsulation Layer

This layer is an intermediate in the whole framework.It parses the RTD payload and provides the structured data to the upper layer.As shown in Fig.3, Text, URI, Smart Poster,Signature, and Generic Control RTD are pre-processed and corresponding instances of data structures are formulated and then delivered to the service description layer.In accordance with object-oriented programming, a Java class,which contains the structured data and provides accessibility,is proposed to represent the abstract NDEF record.Each RTD possesses a corresponding instance of the class, the actual information of which is easy to access by the service description layer.

To illustrate, the RTDTextRecord class is formulated to describe the Text RTD.Its UML class diagram is shown in Fig.4.To construct an instance of RTDTextRecord, an NdefRecord[13]object should be passed in.This parameter is provided by the NFC stack, which is exacted from the‘Intent’ object.By invoking the constructor, the RTD payload data is parsed, where an exception is thrown when encountering errors and its actual information parsed can be gained by invoking other member functions.

The process of constructing an RTDTextRecord object is shown in Fig.5.This flow chart describes the algorithm used to exact the actual text in payload data, the whole process of which is performed in the constructor.The reverse process, constructing an NdefRecord object according to a given text for writing into a tag, is performed in the static function createTextRecord, the process of which can also refer to Fig.5 and will not be detailed here.

Once the actual text is gained by utilizing the RTDTextRecord class, the service description layer may apply this information for further use.Other data structures to implement other RTDs are also available.An RTDUriRecord class is used to instantiate a URI RTD.Its class diagram is shown in Fig.6.

Another commonly used RTD, smart poster RTD, is represented by the RTDSmartPosterRecord class whose class diagram is shown in Fig.7.

Fig.4.UML class diagram of RTDTextRecord.

Fig.5.Process of constructing an RTDTextRecord object.

Fig.6.UML class diagram of RTDUriRecord.

Fig.7.UML class diagram of RTDSmartPosterRecord.

Fig.8.UML class diagram of RTDSignatureRecord.

The signature RTD is added to provide a security mechanism that ensures the integrity and reliability of NFC data.Its class diagram is shown in Fig.8.

Similarly, the RTDGenericCtrlRecord class is introduced to describe a generic control RTD.The detailed class diagram needs not to be detailed here.

Generally speaking, the RTD parsing & encapsulation layer has completed all the works needed to extract information from raw data.RTDSmartPosterRecord,RTDTextRecord, RTDUriRecord, RTDSignatureRecord,and RTDGernericCtrlRecord classes make up this layer,where algorithms used to parse RTDs are all encapsulated in their constructor.Due to limited paper length, the process of parsing each RTD is not all described here.But the principles of their algorithm are similar.

3.2 Service Description Layer

After gaining the actual information from RTD payloads, it is consecutively the work of the service description layer to provide post-processing.To define its function, several factors should be taken into account.

Initially, to implement the whole framework, it is needed to configure an NFC adapter[13], the process of which is executed by the NFC configuration rather than the application itself.It has completed many complex initializations that are needed to utilize NFC features.

In normal case of NFC-related applications, acquiring the parsed data is commonly required for the utilization of information.However, for different applications,requirements vary a lot.For instance, a download manager may need the URL and size data, contained in a smart poster tag, so that it can download data via the URL and users can be notified the size of the data in advance.In another case, the URL and text data of a smart poster RTD is intended to be saved as a bookmark in the Internet browser.Therefore, parsed data acquisition is implemented in the service description layer to satisfy various requirements and supply correct information.

Despite that, filtering the type of information, i.e.the RTD type, is also needed in many cases.For instance, some NFC-related applications are only interested in NFC tags that contain a URL, however, others are interested in a text tag.Though, the Android SDK (software development kit)has provided accesses to filtering[13], it does not include filtering different RTD types.As the result, the RTD type filter is included in the service description layer.

Moreover, when the correct information is gained, it is necessary to perform post-processing services which may trigger complex actions such as making a phone call based on the telephone number, and launching a designated webpage.The whole procedure is a service execution process.More than one action may be performed consecutively and logically.Despite that, the mobile phone is on an ever-changing environment, it is inevitable to be aware of the context information.As described in the first section, the application has to decide whether to launch a webpage or save as a bookmark when a URL is gained from an NFC tag.Considering these factors, the service flow description is responsible for the post-processing with context-awareness.

Ultimately, taking security factors into consideration,the service description layer should provide certain mechanisms.A universal method to protect data is the digital signature, which gives a series of bytes as its signature to the signed data according to a certain encryption algorithm.Once the public key is known, it can be applied to verify the signature so that little changes of the original data can be detected.Consequently, the layer implements the NFC signature to provide quick access to verify the digital signature of the protected data.

To apply all the features mentioned above, normal ways of interactions, such as providing a set of APIs, can no longer fit to describe the whole procedure accurately.So a universal and accurate way is proposed.By utilizing XML,the whole service process can be described as an XML document.Once the service description layer parses the pre-defined XML document with document object model(DOM) or simple API for XML (SAX)[14], it interprets the service process accurately and correctly.However, before defining the structure of the XML document, a context-awareness model should be proposed first to implement the service flow description.

As it can be seen in Fig.9, the model of service flow description is associated to a two-level priority structure.The primary level (e.g.Service 1, Service 2, …) is made up of different services, the affiliated actions of which will be executed consecutively.The secondary level (e.g.Actions 2.1, Action 2.2, …) is affiliated to each service.These actions are arranged according to priority, which means not all actions are to be executed.Taking Service 2 as an example, Service 2 will be executed beginning with Action 2.1 (followed by Action 2.2, Action 2.3, …) and ends up when an action is executed successfully or the service finishes.More specifically, when Action 2.1 fails,Action 2.2 will be triggered.This procedure will continue until Action 2.X (2＜X＜N) is successfully executed or Action 2.N is executed.Metaphorically, the execution sequence can be compared to preorder traversal of a binary tree, but not exactly the same though.

Combing with this model, the service flow description will be equipped with context-awareness features[15].Actions that must be executed should be organized as the first action in different services.For instance, sending SMS messages is implemented as an action and otherwise making a phone call if SMS messages fail to be sent.These two actions should be organized belonging to Service 1,where SMS messages sending is arranged in Action 1.1 and making a phone call in Action 1.2.Once Action 1.1 is executed, the service description flow will listen to the broadcast of the system which has a flag for whether messages are successfully sent or not.If it fails, making a phone call (Action 2.2) will start executing.Otherwise,Action 2.2 will never be executed.In another case, the application intents to send SMS messages and simultaneously making a phone call.They should be arranged in Action 1.1 and Action 2.1 separately.Despite listening to the system broadcast[9], this model can detect the network state to determine the next action.As shown in the example, with this model, the service flow description has the capability to detect the physical situation in order to act and respond in a proactive and intelligent way, which is what the context-awareness demonstrates.

Now that the model of service flow description is defined, the whole structure of the XML document can be constructed as shown in Fig.10.Its document type definition (DTD) is defined in Fig.11.Each element’s introduction is as follows:

Fig.9.Context-awareness model of service flow description.

Fig.10.Element structure of the XML document.

Fig.11.DTD for the XML document.

· NFCInflator: The root element of the XML document,which has no properties.

· NFCAdapter: The direct child of the root element.It represents an implementation of the service description layer.More than one “NFCAdapter” element may appear with the serial number from 0 to N.Combing with APIs of the framework, applications is able to utilize different implementations dynamically.

· TagSignatureCheck: An empty child element of NFCAdapter.It is used to indicate the configurations of NFC signature verification.The “CheckType” property defines when to perform signature verification (always,never, or if signature exists).The “CertificatePath” property indicates the absolute path of the X.509 certificate[16]used to verify the signature.The “CheckFailAction” indicates the action triggered when verification fails.An alert or a toast, decided by “AlertType”, may be shown when setting to a designated value.The “CheckAlgorithm” points out the name of encryption algorithm used for verification.The text to be shown in the alert or toast when verification fails can be modified by changing the value of “AlertText”property.

· RecordTypeFilter & Record: Elements used to implement the RTD type filter.A list of RTD types intended to receive is positioned below “RecordTypeFilter”, while the value of “Record” element indicates the name of intended RTDs.The application will not receive the RTD which does not emerge in “RecordTypeFilter”.

· ParsedContentList & Content: Elements used to implement the Parsed Data Acquisition.It is used to indicate what information, gained from the RTD parsing &encapsulation layer, the application intents to obtain.For example, if the application needs the URL, text, and size information, it may set the “ParsedContentList” element as follows:

＜ParsedContentList＞

＜Content Value = “URI” /＞

＜Content Value = “Text” /＞

＜Content Value = “Size” /＞

＜/ParsedContentList＞

By invoking the function getParsedData() provided by APIs of the framework, the application will get a String array which contains the URL, text, and size information,presented in the array in order of the appearance in the“ParsedContentList” element.

· Service & Action: Elements used to implement the service flow description.It is based on the context-awareness model proposed previously, where actions are represented by “Action” elements and services by “Service” elements.The “Action” element has several properties.Its “ActionDescription” property indicates what to be executed.The action code[6],[7]included in the smart poster record and generic control record, presents the category of proposed actions.The “Action” element can determine whether to execute according to the action code.When “IgnoreActionCode” property is assigned “Yes”,actions will be executed ignoring the proposed action code.“Target” and “Source” is a pair of properties to indicate the target and source data needed when executing.It can be assigned “#URI” or “#Text”, indicating that the data comes from URI or text information in the RTD.A user-defined text can also be assigned.For example, when“SendSMSMessage” is assigned to “ActionDescription”,the “Target” value is “13438281560”, and the “Source”value is “#Text”, which means that an SMS message will be sent to the phone whose telephone number is 13428281560 and the text body of the message comes from the text record.

With all elements mentioned above, entire features needed for a NFC-related application is satisfied by using the XML document to describe the whole service flow.But one thing is left in order to associate the application with the framework for the service model of NFC stack.

3.3 APIs to Invoke the Framework

In addition to the whole features, a set of APIs should be provided to invoke the entire framework.Only by applying this set of APIs in applications can the framework be utilized and access the XML document that is used to describe the NFC-related services.

Similarly, a class which encapsulates the whole procedure is proposed.Inside the class, it interacts with the RTD parsing & encapsulation layer by implementing the classes provided, parses the XML document to formulate the service map, and finally triggers the service flow and signature verification.The class is called NFCXmlInflator,which can replace original APIs provided by the NFC stack.The class diagram is shown in Fig.12.

When invoking the constructor of NFCXmlInflator, an instance, which represents the whole framework for the service model of the NFC stack, is initialized by passing in a) the activity itself which intends to utilize the framework,b) the path of the XML document, and c) the absolute path of the certificate file when not indicated in the XML document.If no exceptions are thrown, the initialization has been successfully completed.The getParsedData() function will return a String array which contains the information needed and specified in the “ParsedConentList” elements of the XML document.Different “NFCAdapter” elements,where “ParsedConentList” elements lies in, can be selected by setting the parameter NFCAdapterID, and an Intent object, sent to the activity, should also be a parameter.Similarly, the doNFCTagAction() function is invoked when the application intends to trigger the service flow defined in the XML document.The first parameter needed is a Handler[17]object, which is used to perform post-processing of asynchronous actions (e.g.when download finishes).The NFCXmlInflator object will send relative messages to the handler in many cases so that the application is able to respond and react.Its last two parameter is similar to the homonymous parameters in getParsedData().The getNFCAdapterInfo() will return an instance of NFCAdapterInfo class, defined inside the NFCXmlInflator.The NFCAdapterInfo class contains the parsed information of the XML document, which can be used by the application for further use.

Fig.12.UML class diagram of NFCXmlInflator.

4.An Easy Example: An Emergency Assistant on Highways

With the aim of showing the characteristics of the proposed framework, its application to a very simple example will be described with the purpose of not including an extension and complexity not needed.

The basic idea of the example is that, with an application (called emergency assistant) installed on the mobile phone, the user can ask for help in an easy, quick and intuitive way when encountering accidents on the highway, just by touching an NFC tag put on the roadside.The application will send an SMS message which specifies the approximate location (contained and specified in NFC tags) and make a phone call to the emergency centre of the highway.

The complete requirement of the application involved in this simple example contains two services: a) a phone call to the emergency number contained in the NFC tag, b)sending an SMS message to the emergency centre to state the approximate location, and c) once the SMS message fails to be sent, it is saved as a draft in the text box.

In addition, the application intends to verify the signature of the data contained in NFC tags to check if the information is modified unofficially.Besides the data is formulated as a smart poster, an RTD type filter should be added to filter out unmatched tags.

Fig.13.Full definition of the XML document.

To utilize the service model of the NFC stack, the XML document defined to describe the whole service flow is shown in Fig.13.

In the emergency assistant application, APIs provided to invoke the framework should be embedded in the Activity class, which represents instances of a controller of the application’s user interface (UI) (see Fig.14).The XML document, named “nfcService.xml” and defined in Fig.13,is passed to the instance of NFCInflator, and then its content is parsed at the same time.Initialization being completed, the function onNewIntent() is invoked when an NFC tag is touched, and the raw data is passed in as the parameter (intent), which comes from the NFC stack layer.By invoking the doNFCTagAction(), the services defined in the XML document is executed automatically.It is apparent that the application does not need to be programmed to make a phone call or send SMS messages any more, which has already been done by the service description layer.More importantly, the context-awareness model has been implemented while executing these actions, which reduces all the procedures to a few lines of codes and facilitates the development of the application.

Equally, if the application wants to modify the services flow for upgrade reasons, a new XML document can be customized and replace the original one, which makes the software maintenance of the application more convenient.

5.Conclusions and Discussion

Fig.14.Part of Java code of the application.

A brand-new way of interacting with NFC-related devices is presented.Although, the NFC technology is still in development stage yet, combing with the proposed framework, it could sharply modify the interaction mode with the NFC hardware and simplify the whole service process.The framework of service model of NFC stack also integrates a context-awareness model, where the application automatically takes environment factors into consideration.

The characteristic of the framework is that services and the bottom-level hardware are effectively combined and constructed in a universal architecture, and a user-friendly interface is provided to unify and utilize the whole service flow.Although this paper mainly discusses its structure, the internal structure is easy to build combining several related technologies such as XML parsing and Android SDKs.The implementation of the internal structure is partially omitted in this paper due to limited paper length, which gives the universal property and extensibility to the framework.Based on the Android platform, the service model can be transplanted to other platforms by modifying the internal APIs that used to interact with the system.

Currently, its completeness and the transplantable model are still being researched in order to equip the framework with the ability to adapt to different platforms and more context-awareness rules.

[1]J.Riekki, I.Sanchez, and M.Pyykk?nen, “NFC-based user interfaces,” in Proc.of the 4th Int.Workshop on Near Field Communication, Restaurant P??posti, 2012, pp.3-9.

[2]NFC Forum.(July 2006).NFC data exchange format(NDEF).NFC Forum Technical Specification.[Online].Available: http://www.nfc-forum.org/specs/spec_list/

[3]NFC Forum.(July 2006).NFC record type definition(RTD).NFC Forum Technical Specification.[Online].Available:http://www.nfc-forum.org/specs/spec_list/

[4]NFC Forum.(July 2006).Text record type definition.NFC Forum Technical Specification.[Online].Available:http://www.nfc-forum.org/specs/spec_list/

[5]NFC Forum.(July 2006).URI record type definition.NFC Forum Technical Specification.[Online].Available:http://www.nfc-forum.org/specs/spec_list/

[6]NFC Forum.(July 2006).Smart poster record type definition.NFC Forum Technical Specification.[Online].Available: http://www.nfc-forum.org/specs/spec_list/

[7]NFC Forum.(July 2006).Generic control record type definition.NFC Forum Technical Specification.[Online].Available: http://www.nfc-forum.org/specs/spec_list/

[8]NFC Forum.(July 2006).Signature record type definition.NFC Forum Technical Specification.[Online].Available:http://www.nfc-forum.org/specs/spec_list/

[9]S.Komatineni, D.MacLean, and S.Y.Hashimi, Pro Android 3, New York: Apress, 2010.

[10]H.-T.Pu, W.Diao, and M.-Q.Fan, “Reseach on context model of information system intelligent interaction in IoT environment,” Electronic Power IT, vol.9, no.8, pp.61-64,2011.

[11]M.Roland and J.Langer, “Digital signature records for the NFC data exchange format,” in Proc.of the 2nd Int.Workshop on Near Field Communication, Monaco, 2010, pp.71-76.

[12]R.Hunt, “Technological infrastructure for PKI and digital certification,” Computer Communications, vol.24, no.14,pp.1460-1471, 2001.

[13]Google.NFC Basics, NFC, Connectivity, API Guides.[Online].Available: http://developer.android.com/guide

[14]G.Li, Crazy XML, 2nd ed.Beijing: Publishing House of Electronic Industry, 2011, pp.291-334.

[15]P.C.Garrido, G.M.Miraz, I.L.Ruiz, and M.á.Gómez-Nieto, “A model for the development of NFC context-awareness applications on Internet of things,” in Proc.of the 2nd Int.Workshop on Near Field Communication, Monaco, 2010, pp.9-14.

[16]R.Housley, W.Ford, W Polk, and D.Solo, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, RFC 2459, Jan.1999.

[17]Google.Handler, Android.OS, Android APIs, References.[Online].Available: http://developer.android.com/reference/android/