\documentclass[11pt,twoside]{article}\makeatletter

\IfFileExists{xcolor.sty}%
  {\RequirePackage{xcolor}}%
  {\RequirePackage{color}}
\usepackage{colortbl}
\usepackage{wrapfig}
\usepackage{ifxetex}
\ifxetex
  \usepackage{fontspec}
  \usepackage{xunicode}
  \catcode`⃥=\active \def⃥{\textbackslash}
  \catcode`❴=\active \def❴{\{}
  \catcode`❵=\active \def❵{\}}
  \def\textJapanese{\fontspec{Noto Sans CJK JP}}
  \def\textChinese{\fontspec{Noto Sans CJK SC}}
  \def\textKorean{\fontspec{Noto Sans CJK KR}}
  \setmonofont{DejaVu Sans Mono}
  
\else
  \IfFileExists{utf8x.def}%
   {\usepackage[utf8x]{inputenc}
      \PrerenderUnicode{–}
    }%
   {\usepackage[utf8]{inputenc}}
  \usepackage[english]{babel}
  \usepackage[T1]{fontenc}
  \usepackage{float}
  \usepackage[]{ucs}
  \uc@dclc{8421}{default}{\textbackslash }
  \uc@dclc{10100}{default}{\{}
  \uc@dclc{10101}{default}{\}}
  \uc@dclc{8491}{default}{\AA{}}
  \uc@dclc{8239}{default}{\,}
  \uc@dclc{20154}{default}{ }
  \uc@dclc{10148}{default}{>}
  \def\textschwa{\rotatebox{-90}{e}}
  \def\textJapanese{}
  \def\textChinese{}
  \IfFileExists{tipa.sty}{\usepackage{tipa}}{}
\fi
\def\exampleFont{\ttfamily\small}
\DeclareTextSymbol{\textpi}{OML}{25}
\usepackage{relsize}
\RequirePackage{array}
\def\@testpach{\@chclass
 \ifnum \@lastchclass=6 \@ne \@chnum \@ne \else
  \ifnum \@lastchclass=7 5 \else
   \ifnum \@lastchclass=8 \tw@ \else
    \ifnum \@lastchclass=9 \thr@@
   \else \z@
   \ifnum \@lastchclass = 10 \else
   \edef\@nextchar{\expandafter\string\@nextchar}%
   \@chnum
   \if \@nextchar c\z@ \else
    \if \@nextchar l\@ne \else
     \if \@nextchar r\tw@ \else
   \z@ \@chclass
   \if\@nextchar |\@ne \else
    \if \@nextchar !6 \else
     \if \@nextchar @7 \else
      \if \@nextchar (8 \else
       \if \@nextchar )9 \else
  10
  \@chnum
  \if \@nextchar m\thr@@\else
   \if \@nextchar p4 \else
    \if \@nextchar b5 \else
   \z@ \@chclass \z@ \@preamerr \z@ \fi \fi \fi \fi
   \fi \fi  \fi  \fi  \fi  \fi  \fi \fi \fi \fi \fi \fi}
\gdef\arraybackslash{\let\\=\@arraycr}
\def\@textsubscript#1{{\m@th\ensuremath{_{\mbox{\fontsize\sf@size\z@#1}}}}}
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\def\abbr{}
\def\corr{}
\def\expan{}
\def\gap{}
\def\orig{}
\def\reg{}
\def\ref{}
\def\sic{}
\def\persName{}\def\name{}
\def\placeName{}
\def\orgName{}
\def\textcal#1{{\fontspec{Lucida Calligraphy}#1}}
\def\textgothic#1{{\fontspec{Lucida Blackletter}#1}}
\def\textlarge#1{{\large #1}}
\def\textoverbar#1{\ensuremath{\overline{#1}}}
\def\textquoted#1{‘#1’}
\def\textsmall#1{{\small #1}}
\def\textsubscript#1{\@textsubscript{\selectfont#1}}
\def\textxi{\ensuremath{\xi}}
\def\titlem{\itshape}
\newenvironment{biblfree}{}{\ifvmode\par\fi }
\newenvironment{bibl}{}{}
\newenvironment{byline}{\vskip6pt\itshape\fontsize{16pt}{18pt}\selectfont}{\par }
\newenvironment{citbibl}{}{\ifvmode\par\fi }
\newenvironment{docAuthor}{\ifvmode\vskip4pt\fontsize{16pt}{18pt}\selectfont\fi\itshape}{\ifvmode\par\fi }
\newenvironment{docDate}{}{\ifvmode\par\fi }
\newenvironment{docImprint}{\vskip 6pt}{\ifvmode\par\fi }
\newenvironment{docTitle}{\vskip6pt\bfseries\fontsize{22pt}{25pt}\selectfont}{\par }
\newenvironment{msHead}{\vskip 6pt}{\par}
\newenvironment{msItem}{\vskip 6pt}{\par}
\newenvironment{rubric}{}{}
\newenvironment{titlePart}{}{\par }

\newcolumntype{L}[1]{){\raggedright\arraybackslash}p{#1}}
\newcolumntype{C}[1]{){\centering\arraybackslash}p{#1}}
\newcolumntype{R}[1]{){\raggedleft\arraybackslash}p{#1}}
\newcolumntype{P}[1]{){\arraybackslash}p{#1}}
\newcolumntype{B}[1]{){\arraybackslash}b{#1}}
\newcolumntype{M}[1]{){\arraybackslash}m{#1}}
\definecolor{label}{gray}{0.75}
\def\unusedattribute#1{\sout{\textcolor{label}{#1}}}
\DeclareRobustCommand*{\xref}{\hyper@normalise\xref@}
\def\xref@#1#2{\hyper@linkurl{#2}{#1}}
\begingroup
\catcode`\_=\active
\gdef_#1{\ensuremath{\sb{\mathrm{#1}}}}
\endgroup
\mathcode`\_=\string"8000
\catcode`\_=12\relax

\usepackage[a4paper,twoside,lmargin=1in,rmargin=1in,tmargin=1in,bmargin=1in,marginparwidth=0.75in]{geometry}
\usepackage{framed}

\definecolor{shadecolor}{gray}{0.95}
\usepackage{longtable}
\usepackage[normalem]{ulem}
\usepackage{fancyvrb}
\usepackage{fancyhdr}
\usepackage{graphicx}
\usepackage{marginnote}

\renewcommand{\@cite}[1]{#1}


\renewcommand*{\marginfont}{\itshape\footnotesize}

\def\Gin@extensions{.pdf,.png,.jpg,.mps,.tif}

  \pagestyle{fancy}

\usepackage[pdftitle={Strengths and Weaknesses of Near Field Communication (NFC) Technology},
 pdfauthor={}]{hyperref}
\hyperbaseurl{}

	 \paperwidth210mm
	 \paperheight297mm
              
\def\@pnumwidth{1.55em}
\def\@tocrmarg {2.55em}
\def\@dotsep{4.5}
\setcounter{tocdepth}{3}
\clubpenalty=8000
\emergencystretch 3em
\hbadness=4000
\hyphenpenalty=400
\pretolerance=750
\tolerance=2000
\vbadness=4000
\widowpenalty=10000

\renewcommand\section{\@startsection {section}{1}{\z@}%
     {-1.75ex \@plus -0.5ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large\bfseries}}
\renewcommand\subsection{\@startsection{subsection}{2}{\z@}%
     {-1.75ex\@plus -0.5ex \@minus- .2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large}}
\renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}%
     {-1.5ex\@plus -0.35ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\large}}
\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}%
     {-1ex \@plus-0.35ex \@minus -0.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\normalsize}}
\renewcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}%
     {1.5ex \@plus1ex \@minus .2ex}%
     {-1em}%
     {\reset@font\normalsize\bfseries}}


\def\l@section#1#2{\addpenalty{\@secpenalty} \addvspace{1.0em plus 1pt}
 \@tempdima 1.5em \begingroup
 \parindent \z@ \rightskip \@pnumwidth 
 \parfillskip -\@pnumwidth 
 \bfseries \leavevmode #1\hfil \hbox to\@pnumwidth{\hss #2}\par
 \endgroup}
\def\l@subsection{\@dottedtocline{2}{1.5em}{2.3em}}
\def\l@subsubsection{\@dottedtocline{3}{3.8em}{3.2em}}
\def\l@paragraph{\@dottedtocline{4}{7.0em}{4.1em}}
\def\l@subparagraph{\@dottedtocline{5}{10em}{5em}}
\@ifundefined{c@section}{\newcounter{section}}{}
\@ifundefined{c@chapter}{\newcounter{chapter}}{}
\newif\if@mainmatter 
\@mainmattertrue
\def\chaptername{Chapter}
\def\frontmatter{%
  \pagenumbering{roman}
  \def\thechapter{\@roman\c@chapter}
  \def\theHchapter{\roman{chapter}}
  \def\thesection{\@roman\c@section}
  \def\theHsection{\roman{section}}
  \def\@chapapp{}%
}
\def\mainmatter{%
  \cleardoublepage
  \def\thechapter{\@arabic\c@chapter}
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \pagenumbering{arabic}
  \setcounter{secnumdepth}{6}
  \def\@chapapp{\chaptername}%
  \def\theHchapter{\arabic{chapter}}
  \def\thesection{\@arabic\c@section}
  \def\theHsection{\arabic{section}}
}
\def\backmatter{%
  \cleardoublepage
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \setcounter{secnumdepth}{2}
  \def\@chapapp{\appendixname}%
  \def\thechapter{\@Alph\c@chapter}
  \def\theHchapter{\Alph{chapter}}
  \appendix
}
\newenvironment{bibitemlist}[1]{%
   \list{\@biblabel{\@arabic\c@enumiv}}%
       {\settowidth\labelwidth{\@biblabel{#1}}%
        \leftmargin\labelwidth
        \advance\leftmargin\labelsep
        \@openbib@code
        \usecounter{enumiv}%
        \let\p@enumiv\@empty
        \renewcommand\theenumiv{\@arabic\c@enumiv}%
	}%
  \sloppy
  \clubpenalty4000
  \@clubpenalty \clubpenalty
  \widowpenalty4000%
  \sfcode`\.\@m}%
  {\def\@noitemerr
    {\@latex@warning{Empty `bibitemlist' environment}}%
    \endlist}

\def\tableofcontents{\section*{\contentsname}\@starttoc{toc}}
\parskip0pt
\parindent1em
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\newenvironment{reflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemsep}{0pt}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\itshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{sansreflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\itemsep}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\upshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{specHead}[2]%
 {\vspace{20pt}\hrule\vspace{10pt}%
  \phantomsection\label{#1}\markright{#2}%

  \pdfbookmark[2]{#2}{#1}%
  \hspace{-0.75in}{\bfseries\fontsize{16pt}{18pt}\selectfont#2}%
  }{}
      \def\TheFullDate{2011-02-18 (revised: 18 February 2011)}
\def\TheID{\makeatother }
\def\TheDate{2011-02-18}
\title{Strengths and Weaknesses of Near Field Communication (NFC) Technology}
\author{}\makeatletter 
\makeatletter
\newcommand*{\cleartoleftpage}{%
  \clearpage
    \if@twoside
    \ifodd\c@page
      \hbox{}\newpage
      \if@twocolumn
        \hbox{}\newpage
      \fi
    \fi
  \fi
}
\makeatother
\makeatletter
\thispagestyle{empty}
\markright{\@title}\markboth{\@title}{\@author}
\renewcommand\small{\@setfontsize\small{9pt}{11pt}\abovedisplayskip 8.5\p@ plus3\p@ minus4\p@
\belowdisplayskip \abovedisplayskip
\abovedisplayshortskip \z@ plus2\p@
\belowdisplayshortskip 4\p@ plus2\p@ minus2\p@
\def\@listi{\leftmargin\leftmargini
               \topsep 2\p@ plus1\p@ minus1\p@
               \parsep 2\p@ plus\p@ minus\p@
               \itemsep 1pt}
}
\makeatother
\fvset{frame=single,numberblanklines=false,xleftmargin=5mm,xrightmargin=5mm}
\fancyhf{} 
\setlength{\headheight}{14pt}
\fancyhead[LE]{\bfseries\leftmark} 
\fancyhead[RO]{\bfseries\rightmark} 
\fancyfoot[RO]{}
\fancyfoot[CO]{\thepage}
\fancyfoot[LO]{\TheID}
\fancyfoot[LE]{}
\fancyfoot[CE]{\thepage}
\fancyfoot[RE]{\TheID}
\hypersetup{citebordercolor=0.75 0.75 0.75,linkbordercolor=0.75 0.75 0.75,urlbordercolor=0.75 0.75 0.75,bookmarksnumbered=true}
\fancypagestyle{plain}{\fancyhead{}\renewcommand{\headrulewidth}{0pt}}

\date{}
\usepackage{authblk}

\providecommand{\keywords}[1]
{
\footnotesize
  \textbf{\textit{Index terms---}} #1
}

\usepackage{graphicx,xcolor}
\definecolor{GJBlue}{HTML}{273B81}
\definecolor{GJLightBlue}{HTML}{0A9DD9}
\definecolor{GJMediumGrey}{HTML}{6D6E70}
\definecolor{GJLightGrey}{HTML}{929497} 

\renewenvironment{abstract}{%
   \setlength{\parindent}{0pt}\raggedright
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
   \textcolor{GJBlue}{\large\bfseries\abstractname\space}
}{%   
   \vskip8pt
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
}

\usepackage[absolute,overlay]{textpos}

\makeatother 
      \usepackage{lineno}
      \linenumbers
      
\begin{document}

             \author[1]{Dr. Mohamed Mostafa Abd  Allah}

             \affil[1]{  Royal Commission, Yanbu Industrial Collage,KSA}

\renewcommand\Authands{ and }

\date{\small \em Received: 6 January 2011 Accepted: 3 February 2011 Published: 18 February 2011}

\maketitle


\begin{abstract}
        


This paper gives a comprehensive analysis of security with respect to NFC. We propose a protocol that can be used between an RFID tag and a reader to exchange a secret without performing any expensive computation. The paper introduced an NFC specific key agreement mechanism, which provides cheap and fast secure key agreement. Key agreement techniques without authentication can be used to provide a standard secure channel. This resistance against Man-in-the-Middle attacks makes NFC an ideal method for secure pairing of devices. The paper lists some of threats, which are applicable to NFC, and describes solutions to protect against these threats.

\end{abstract}


\keywords{Near Field Communication, threats, key agreement.}

\begin{textblock*}{18cm}(1cm,1cm) % {block width} (coords) 
\textcolor{GJBlue}{\LARGE Global Journals \LaTeX\ JournalKaleidoscope\texttrademark}
\end{textblock*}

\begin{textblock*}{18cm}(1.4cm,1.5cm) % {block width} (coords) 
\textcolor{GJBlue}{\footnotesize \\ Artificial Intelligence formulated this projection for compatibility purposes from the original article published at Global Journals. However, this technology is currently in beta. \emph{Therefore, kindly ignore odd layouts, missed formulae, text, tables, or figures.}}
\end{textblock*}


\let\tabcellsep& 	 	 		 
\section[{Introduction}]{Introduction}\par
ear Field Communication (NFC) is a technology for high frequency wireless short-distance pointto-point communication. The operational range for NFC is within less than 20 cm which is good from a security perspective as it diminishes the threat of eavesdropping. Other reasons to use NFC are the low cost of the necessary components and that the connecting time is negligible. It is small circuit attached to a small antenna, capable of transmitting data to a distance of several meters to a reader device (reader) in response to a query. Most RFID tags are passive, meaning that they are battery-less, and obtain their power from the query signal. They are already attached to almost anything: clothing, foods, access cards and so on. It is impossible to give a complete picture of NFC applications as NFC is just an interface. Contactless Token covers most of applications, which use NFC to retrieve some data from a passive token. The passive token could be a contactless Smart Card, an RFID label, or a key fob. In Ticketing / Micro Payment application example, the NFC interface is used to transfer some valuable information. The ticket or the micro payment data is stored in a secure device. This could be a contactless Smart Card, but could as well be a mobile phone.\par
When the user wants to perform a payment or use the stored ticket, the user presents the device to a reader, which checks the received information and processes the payment or accepts/rejects the ticket. In this application example the user device must be able to perform a certain protocol with the reader. A simple read operation will not be sufficient in most cases. Also, the user device is likely to have a second interface which is used to load money or to buy tickets. This second interface can for example be linked to the mobile phone CPU. The ticket data could then be loaded into the mobile phone via the cellular network. Because NFC is a wireless communication interface it is obvious that threat is an important issue. When two devices communicate via NFC they use RF waves to talk to each other. An attacker can of course use an antenna to also receive the transmitted signals. Either by experimenting or by literature research the attacker can have the required knowledge on how to extract the transmitted data out of the received RF signal. Also the equipment required to receive the RF signal as well as the equipment to decode the RF signal must be assumed to be available to an attacker as there is no special equipment necessary. In this paper we use a systematic approach to analyze the various aspects of security whenever an NFC interface is used. We want to clear up many misconceptions about security and NFC in various applications. The paper lists the threats, which are applicable to NFC, and describes solutions to protect against these threats. The rest of this paper is organized as follows. A brief description about NFC operation modes are given in Section \hyperref[b1]{(2)}. A list of threats technique is discussed in Section (3). Real solution against these threats and establishes a secure channel is presented in Section (4). Finally, concluding remarks are made in Section (5).  
\section[{NFC Operation Modes}]{NFC Operation Modes}\par
NFC can operate in two modes. The modes are distinguished whether a device creates its own RF field or whether a device retrieves the power from the RF field generated by another device. If the device generates its own field and has a power supply, it is called an active device; otherwise it is called a passive device. When two devices communicate three different configurations are possible (Active-Active, Active-Passive, and Passive-Active). These configurations are important because the way data is transmitted depends on whether the transmitting device is in active or passive mode.\par
In active mode the data is sent using amplitude shift keying (ASK) \hyperref[b0]{[1]}, \hyperref[b1]{[2]}. This means the base RF signal (13,56 MHz) is modulated with the data according to a coding scheme. If the baudrate is 106 kBaud, the coding scheme is the so-called modified Miller coding. If the baudrate is greater than 106 kBaud the Manchester coding scheme is applied. As shown in figure  {\ref 2}, each single data bit in both coding schemes is sent in a fixed time slot. This time slot is divided into two halves, called half bits. In Miller coding a zero is encoded with a pause in the first half bit and no pause in the second half bit. A one is encoded with no pause in the first bit, but a pause in the second half bit. In the modified Miller coding some additional rules are applied on the coding of zeros. In the case of a one followed by a zero, two subsequent half bits would have a pause. Modified Miller coding avoids this by encoding a zero, which directly follows a one with two half bits with no pause.\par
In the Manchester coding the situation is nearly the same, but instead of having a pause in the first or second half bit, the whole half bit is either a pause or modulated.\par
Besides the coding scheme also the strength of the modulation depends on the baudrate. For 106 kBaud 100\% modulation is used. This means that in a pause the RF signal is actually zero. No RF signal is sent in a pause. For baudrates greater than 106 kBaud 10\% modulation ratio is used. According to the definition of this modulation ratio \hyperref[b0]{[1]}, this means that in a pause the RF signal is not zero, but it is about 82\% of the level of a non paused signal. This difference in the modulation strength is very important from a security point of view as we will describe later on in the security analysis.\par
In passive mode the data is sent using a weak load modulation. The data is always encoded using Manchester coding with a modulation of 10\%. For 106 kBaud a subcarrier frequency is used for the modulation, for baudrates greater than 106 kBaud the base RF signal at 13.56 MHz is modulated.\par
Additionally to the active and passive mode, there are two different roles a device can play in NFC communication. NFC is based on a message and reply concept. This means one device A sends a message to another device B and device B sends back a reply. It is not possible for device B to send any data to device A without first receiving some message from device A, to which it could reply. The role of the device A which starts the data exchange is called initiator, the role of the other device is called target. Furthermore it should be mentioned that NFC communication is not limited to a pair of two devices. In fact one initiator device can talk to multiple target devices. In this case all target devices are enabled at the same time, but before sending a message, the initiator device must select a receiving device. The message must then be ignored by all non selected target devices. Only the selected target device is allowed to answer to the received data. Therefore, it is not possible to send data to more than one device at the same time (i.e. broadcasting messages are not possible). Typical communication procedure between the initiator and target can be highlighted as shown in figure  {\ref 1}. 
\section[{? Handshake:}]{? Handshake:}\par
? The interrogator sends a command to start communication with transponder in the interrogator field and also to power it (passive transponders). ? Once the tag has received sufficient energy and command from the reader, it reply's with its ID for acknowledgment. ? The reader now knows which tag is in the field and sends a command to the identified tag for instructions either for processing (read or write) or Sleep. ? Data exchange:\par
? If the tag receives processing and reading commands, it transmits a specified block data and waits for the next command. ? If the tag receives processing and writing commands along with block data, it writes the block data into the specified memory block, and transmits the written block data for verification.\par
Although contactless token systems may emerge as one of the most pervasive computing technologies, there are still a vast number of problems that need to be solved before their massive deployment. One of the fundamental issues still to be addressed is privacy. Products labeled with tags reveal sensitive information when queried by readers, and they do it indiscriminately.\par
A problem closely related to privacy is tracking, or violations of location privacy. This is possible because the answers provided by tags are usually predictable: in fact, most of the times, tags provide always the same identifier, which will allow a third party to easily establish an association between a given tag and its holder or owner. Even in the case in which tags try not to reveal any kind of valuable information that could be used to identify themselves or their holder, there are many situations where, by using an assembly of tags (constellation), this tracking will still be possible. Although the two aforementioned problems are the most important security questions that arise from NFC technology, there are some others worth to mention: 
\section[{1) Eavesdropping Threats}]{1) Eavesdropping Threats}\par
In this type of attacks, unintended recipients are able to intercept and read messages.\par
The NFC communication is usually done between two devices in close proximity. This means they are not more than 10 cm (typically less) away from each other. The main question is how close an attacker needs to be to be able to retrieve a usable RF signal. Unfortunately, there is no correct answer to this question. The reason for that is the huge number of parameters which determine the distance depends on the following parameters,\par
? RF filed characteristic of the given sender device (i.e. antenna geometry, shielding effect of the case, the PCB, the environment) ? Setup of the location where the attack is performed (e.g. barriers like walls or metal, noise floor level) Furthermore, eavesdropping is extremely affected by the communication mode. That's because, based on the active or passive mode, the transferred data is coded and modulated differently. If data is transferred with stronger modulation it can be attacked easier. Thus, a passive device, which does not generate its own RF field, is much harder to attack, than an active device.?\par
Therefore any exact number given would only be valid for a certain set of the above given parameters and cannot be used to derive general security guidelines.\par
Avoiding eavesdropping can be done by establishing a secure channel as outlined in section 4.1. This requires the establishment of a session secret key, which is not always an easy task considering the very limited devices' capacities. 
\section[{2) Data Modification Threats}]{2) Data Modification Threats}\par
As shown in figure \hyperref[fig_1]{3}, instead of just listening, an attacker can also try to modify the data which is transmitted via the NFC interface. In the simplest case the attacker just wants to disturb the communication such that the receiver is not able to understand the data sent by the other device.\par
In data modification, the attacker wants the receiving device to actually receive some valid, but manipulated data. This is very different from just data corruption.\par
The feasibility of this attack highly depends on the applied strength of the amplitude modulation. This is because the decoding of the signal is different for 100\% in modified Miller coding modulation and 10\% in Manchester coding modulation.\par
In 100\% modulation the decoder checks the two half bits for RF signal on (no pause) or RF signal off (pause). In order to make the decoder understand a one as a zero or vice versa, the attacker must do two things. First, a pause in the modulation must be filled up with the carrier frequency. This is feasible. But, secondly, the attacker must generate a pause of the RF signal, which is received by the legitimate receiver. This means the attacker must send out some RF signal such that this signal perfectly overlaps with the original signal at the receiver's antenna to give a zero signal at the receiver. This is practically impossible. However, due to the modified Miller coding in the case of two subsequent ones, the attacker can change the second one into a zero, by filling the pause, which encodes the second one. The decoder would then see no pause in the second bit and would decode this as a correct zero, because a one precedes it. In 100\% modulation an attacker can therefore never change a bit of value 0 to a bit of value 1, but an attacker can change a bit of value 1 to a bit of value 0, in case this bit is preceded by a bit of value 1 (i.e. with a probability of 0.5). In 10\% modulation the decoder measures both signal levels (82\% and Full) and compares them. In case they are in the correct range the signal is valid and gets decoded. An attacker could try to add a signal to the 82\% signal, such that the 82\% signal appears as the Full signal and the actual Full signal becomes the 82\% signal. This way the decode would decode a valid bit of the opposite value of the bit sent by the correct sender. Whether the attack is feasible depends a lot on the dynamic input range of the receiver. It is very likely that the much higher signal level of the modified signal would exceed the possible input range, but for certain situations this cannot be ruled out completely. The conclusion is that for the modified Miller encoding with 100\% ASK this attack is feasible for certain bits and impossible for other bits, but for Manchester coding with 10\% ASK this attack is feasible on all bits.\par
Protection against data modification can be achieved in various ways. By using 106k Baud in active mode it gets impossible for an attacker to modify all the data transmitted via the RF link as described above. This means that for both directions active mode would be needed to protect against data modification. While this is possible, this has the major drawback, that this mode is most vulnerable to eavesdropping. In addition, the protection against modification is not perfect, as even at 106k Baud some bits can be modified. The two other protection options might therefore be preferred. NFC devices can check the RF field while sending. This means the sending device could continuously check for such an attack and could stop the data transmission when an attack is detected. The third and probably best solution would be a secure channel as described in section 4.1. 
\section[{3) Man-in-the-Middle Threats}]{3) Man-in-the-Middle Threats}\par
In Man-in-the-Middle Attack, two parties want to talk to each other, called Alice and Bob, are tricked into a three party conversation by an attacker Eve. This is shown in Figure \hyperref[fig_1]{3}. Assuming that Alice uses active mode and Bob would be in passive mode, we have the following situation. Alice generates the RF field and sends data to Bob. In case Eve is close enough, she can eavesdrop the data sent by Alice. Additionally she must actively disturb the transmission of Alice to make sure that Bob doesn't receive the data. This is possible for Eve, but this can also be detected by Alice. In case Alice detects the disturbance, Alice can stop the key agreement protocol. Let's assume Alice does not check for active disturbance and so the protocol can continue. In the next step Eve needs to send data to Bob. That's already a problem, because the RF field generated by Alice is still there, so Eve has to generate a second RF field. This however, causes two RF fields to be active at the same time. It is practically impossible to perfectly align these two RF fields. Thus, it is practically impossible for Bob to understand data sent by Eve. Because of this and the possibility of Alice to detect the attack much earlier we conclude that in this setup a Man-in-the-Middle attacks is practically impossible.\par
The only other possible setup is that Alice uses active mode and Bob uses active mode, too. In this case Alice sends some data to Bob. Eve can list and Eve again must disturb the transmission of Alice to make sure that Bob does not receive the data. At this point Alice could already detect the disturbance done by Eve and stop the protocol. Again, let us assume that Alice does not do this check and the protocol continues. In the next step Eve would need to send data to Bob. At first sight this looks better now, because of the activeactive communication Alice has turned off the RF field. Now Eve turns on the RF field and can send the data. The problem here now is that also Alice is listening as she is expecting an answer from Bob. Instead she will receive the data sent by Eve and can again detect a problem in the protocol and stop the protocol. It is impossible in this setup for Eve to send data either to Alice or Bob and making sure that this data is not received by Bob or Alice, respectively.\par
We claim that due to the above given reasons it is practically infeasible to mount a Man-in-the-Middle attack in a real-world scenario. It is practically impossible to do a Man-in-the-Middle-Attack on an NFC link. Therefore, setup a secure channel with an active-passive communication mode as outlined in section 4.1 can be used to improve privacy and prevent tracking against Man-in-the-Middle-Attacks Additionally, the active party should listen to the RF filed while sending data to be able to detect any disturbances caused by a potential attacker.\par
IV. 
\section[{Solutions and Recommendations}]{Solutions and Recommendations}\par
In this section we present the best solutions proposed so far to solve the security problems and threats associated with the use of NFC systems. Our objective is not to give a detailed explanation of each solution, but to provide the fundamental principles and a critical review of every proposal. 
\section[{Figure4 NFC specific Key Agreement}]{Figure4 NFC specific Key Agreement}\par
Most of classical solution approach protecting the privacy of NFC communication is done by isolating them from any kind of electromagnetic waves. This can be made using what is known as a Faraday Cage (FC), a container made of metal mesh or foil that is impenetrable by radio signals (of certain frequencies). There are currently a number of companies that sell this type of solution \hyperref[b14]{[13]}. Other solution is active jamming approach that disturbing the radio channel, RF signals. This disturbance may be done with a device that actively broadcasts radio signals, so as to completely disrupt the radio channel, thus preventing the normal operation of RFID readers. 1) Secure Channel for NFC Establishing a secure channel between two NFC devices is clearly the best approach to protect against eavesdropping, data modification attack, and enhance the inherent protection of NFC against Man-in-the-Middle-Attacks. A standard key agreement protocol like Diffie-Hellmann based on RSA \hyperref[b3]{[4]} or Elliptic Curves could be applied to establish a shared secret between two devices. The shared secret can then be used to derive a symmetric key like 3DES or AES, which is then used for the secure channel providing confidentiality, integrity, and authenticity of the transmitted data. Various modes of operation for 3DES and AES could be used for such a secure channel and can be found in literature \hyperref[b2]{[3]}. 
\section[{2) Proposed NFC Key Agreement}]{2) Proposed NFC Key Agreement}\par
The proposed NFC specific key agreement does not require any asymmetric cryptography and therefore reduces the computational requirements significantly. The scheme works with 100\% ASK only where, both devices say Device A and Device B, send random data at the same time. In a setup phase the two devices synchronize on the exact timing of the bits and also on the amplitudes and phases of the RF signal. This is possible as devices can send and receive at the same time. After that synchronization, A and B are able to send at exactly the same time with exactly the same Figure5-Total signal seen on RF Field amplitudes and phases. While sending random bits of 0 or 1, each device also listens to the RF field. When both devices send a zero, the sum signal is zero and an attacker, who is listening, would know that both devices sent a zero. This does not help. The same thing happens when both, A and B, send a one. The sum is the double RF signal and an attacker knows that both devices sent a one. It gets interesting once A sends a zero and B sends a one or vice versa. In this case both devices know what the other device has sent, because the devices know what they themselves have sent. However, an attacker only sees the sum RF signal and he cannot figure out which device sent the zero and which device sent the one. This idea is illustrated in Figure  {\ref 4}.\par
In figure  {\ref 5}, the top figure shows the signals produced by A and by B. A sends the four bits: 0, 0, 1, and 1. B sends the four bits: 0, 1, 0, and 1. The lower graph shows the sum signal as seen by an attacker. It shows that for the bit combinations (A sends 0, B sends 1) and (A sends 1, B sends 0) the result for the attacker is absolutely the same and the attacker cannot distinguish these two cases. The two devices now discard all bits, where both devices sent the same value and collect all bits, where the two devices sent different values. They can either collect the bits sent by A or by B. This must be agreed on start-up, but it doesn't matter. This way A and B can agree on an arbitrary long shared secret. A new bit is generated with a probability of 50\%. Thus, the generation of a 128 bit shared secret would need approximately 256 bits to be transferred. At a baud rate of 106 k Baud this takes about 2.4 ms, and is therefore fast enough for all applications. The security of this protocol in practice depends on the quality of the synchronization which is achieved between the two devices. Obviously, if an eavesdropper can distinguish data sent by A from data sent by B, the protocol is broken. The data must match in amplitude and in phase. Once the differences between A and B are significantly below the noise level received by the eavesdropper the protocol is secure. The level of security therefore also depends on the signal quality at the receiver. The signal quality however again depends on many parameters (e.g. distance) of the eavesdropper. In practice the two devices A and B must aim at perfect synchronization. This can only be achieved if at least one of A or B is an active device to perform this synchronization.\par
V. 
\section[{Conclusion}]{Conclusion}\par
We presented typical use cases for NFC interfaces. A list of threats has been derived and addressed. NFC by itself cannot provide protection against eavesdropping or data modifications. The only solution to achieve this is the establishment of a secure channel over NFC. This can be done very easily, because the NFC link is not susceptible to the Man-inthe-Middle attack. Therefore, well known and easy to apply key agreement techniques without authentication can be used to provide a standard secure channel. This resistance against Man-in-the-Middle attacks makes NFC an ideal method for secure pairing of devices. Additionally, we introduced an NFC specific key agreement mechanism, which provides cheap and fast secure key agreement.\begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-2.png}
\caption{\label{fig_0}Figure1-}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{3}\includegraphics[]{image-3.png}
\caption{\label{fig_1}Figure 3}\end{figure}
 			\footnote{March 2011©2011 Global Journals Inc. (US)} 			\footnote{March 2011III.NFC Applications Threats©2011 Global Journals Inc. (US)} 			\footnote{March 2011©2011 Global Journals Inc. (US)} 			\footnote{March 2011} 		 		\backmatter  			  				\begin{bibitemlist}{1}
\bibitem[ LNCS, IFCA]{b9}\label{b9} 	 		\textit{},  		 FC'03.  	 	 		\textit{LNCS, IFCA}  		Springer-Verlag. 2742 p. .  	 
\bibitem[Jung et al. ()]{b12}\label{b12} 	 		‘8-bit microcontroller system with area efficient AES coprocessor for transponder applications’.  		 			M Jung 		,  		 			H Fiedler 		,  		 			R Lerch 		.  	 	 		\textit{Ecrypt Workshop on RFID and Lightweight Crypto}  		2005.  	 
\bibitem[Dimitriou ()]{b2}\label{b2} 	 		‘A lightweight RFID protocol to protect against traceability and cloning attacks’.  		 			T Dimitriou 		.  	 	 		\textit{Proc. of SECURECOMM'05},  				 (of SECURECOMM'05)  		2005.  	 
\bibitem[Juels and Weis ()]{b11}\label{b11} 	 		‘Authenticating pervasive devices with human protocols’.  		 			S Juels 		,  		 			Weis 		.  	 	 		\textit{CRYPTO'05, IACR},  				2005. Springer-Verlag. 3126 p. .  	 
\bibitem[Lee et al. ()]{b14}\label{b14} 	 		‘efficient authentication for low-cost RFID systems’.  		 			S M Lee 		,  		 			Y J Hwang 		,  		 			D H Lee 		,  		 			J I L Lim 		.  	 	 		\textit{Proc. of ICCSA'05},  				 (of ICCSA'05)  		2005. Verlag. 3480 p. .  	 
\bibitem[Choi et al. ()]{b1}\label{b1} 	 		‘Efficient RFID authentication protocol for ubiquitous computing environment’.  		 			E Y Choi 		,  		 			S M Lee 		,  		 			D H Lee 		.  	 	 		\textit{Proc. of SECUBIQ'05},  		LNCS  		 (of SECUBIQ'05)  		2005.  	 
\bibitem[Henrici and Mäuller ()]{b5}\label{b5} 	 		‘Hash-based enhancement of location privacy for radiofrequency identi¯cation devices using varying identifiers’.  		 			D Henrici 		,  		 			P Mäuller 		.  	 	 		\textit{PERSEC'04},  				2004. IEEE Computer Society. p. .  	 
\bibitem[Kinoshita et al. ()]{b13}\label{b13} 	 		‘Low-cost RFID privacy protection scheme’.  		 			S Kinoshita 		,  		 			F Hoshino 		,  		 			T Komuro 		,  		 			A Fujimura 		,  		 			M Ohkubo 		.  	 	 		\textit{In IPS Journal}  		2004. 45 p. .  	 
\bibitem[Juels ()]{b6}\label{b6} 	 		‘Minimalist cryptography for lowcost RFID tags’.  		 			A Juels 		.  	 	 		\textit{SCN'04},  				2004. Springer-Verlag. 3352 p. .  	 
\bibitem[Castelluccia and Avoine ()]{b0}\label{b0} 	 		‘Noisy Tags: A Pretty Good Key Exchange Protocol for RFID Tags’.  		 			C Castelluccia 		,  		 			G Avoine 		.  	 	 		\textit{Proceedings of CARDIS},  				 (CARDIS)  		2006. 3928 p. .  	 
\bibitem[Juels and Pappu ()]{b8}\label{b8} 	 		\textit{Privacy protection in RFID-enabled banknotes},  		 			R Juels 		,  		 			Pappu 		.  		2003.  	 	 (Squealing euros) 
\bibitem[Juels and Brainard ()]{b7}\label{b7} 	 		‘Soft blocking: Flexible blocker tags on the cheap’.  		 			J Juels 		,  		 			Brainard 		.  	 	 		\textit{WPES'04, ACM},  				2004. ACM Press. p. .  	 
\bibitem[Feldhofer et al. ()]{b3}\label{b3} 	 		‘Strong authentication for RFID systems using the AES algorithm’.  		 			M Feldhofer 		,  		 			S Dominikus 		,  		 			J Wolkerstorfer 		.  	 	 		\textit{Proc. of CHES'04},  				 (of CHES'04)  		2004. 3156.  	 
\bibitem[Juels et al. ()]{b10}\label{b10} 	 		‘The blocker tag: Selective blocking of RFID tags for consumer privacy’.  		 			R Juels 		,  		 			M Rivest 		,  		 			Szydlo 		.  	 	 		\textit{ACM CCS'03 ACM},  				2003. ACM Press. p. .  	 
\bibitem[Golle et al. ()]{b4}\label{b4} 	 		‘Universal re-encryption for mixnets’.  		 			P Golle 		,  		 			M Jakobsson 		,  		 			A Juels 		,  		 			P Syverson 		.  	 	 		\textit{CT-RSA'04},  				2004. Springer-Verlag. 2964 p. .  	 
\end{bibitemlist}
 			 		 	 
\end{document}
