An Attack on Signed NFC Records and Some Necessary Revisions of
NFC Specifications
Muhammad Qasim Saeed
ISG, Department of Mathematics
Royal Holloway University of London
Egham, UKmuhammad.saeed.2010@live.rhul.ac.uk

Colin D. Walter
ISG, Department of Mathematics
Royal Holloway University of London
Egham, UK
Colin.Walter@rhul.ac.uk

Abstract
The Signature Record Type Definition was
released by the Near Field Communication (NFC)
Forum to provide integrity and authenticity to the
NFC Data Exchange Format (NDEF). It achieves
this goal by adding a digital signature andcorresponding certificates to the NDEF message.
Although the Signature Record Type Definition(Signature RTD) specifies the use of strong
cryptographic algorithms like RSA, DSA andECDSA, a few vulnerabilities have been discovered
in its implementation. A recently published Record
Composition Attack by Roland et al. (2011)
describes how data can be modified in an NDEF
message by exploiting the Type Name Format (TNF)
field even though the NDEF message is protected bya Signature Record.
This paper takes a close look at the attack andpoints out that, apart from the TNF value, a few
other fields of the NDEF header must also be
manipulated in order to implement this attack
successfully. It is shown how to do this and somenecessary modifications to the signature scheme areproposed in order to counter such attacks. Our main
contribution is proposing a revision to the Signature
specification by signing more fields but keeping theexisting NDEF specification.

The first part introduces technical aspects of Near
Field Communication (NFC), including the format
for NFC messages and the originally proposed digital
signature scheme [2]. After this, two attacks on thesignature scheme by Roland et al. [3] are presented
and some missing critical detail is identified. The
first novel contribution is a fuller presentation of
their Record Composition attack which now
certainly succeeds. More significantly, however, weneed to propose a revision of the signature scheme
which is essential to counter both of Roland's
attacks. Some detailed discussion is required tojustify the inclusion of various new elements and to
explain their construction.
Lastly, we also need to discuss implementation
issues arising from our proposed modifications inorder to integrate them within the current
infrastructure.
Our original conference report [12] on the attacks
suggested the necessity for a revision of the NDEF
specification. Here, we manage to avoid this, with its
attendant implications for the existing NFC
infrastructure, by making some further changes tothe proposals for the signature scheme. However,this proposed revision to the signature specificationis nevertheless a significant result because of its
implications for extending and renewing the current
NFC infrastructure.

1. Introduction

2. Near Field Communication

The format of Near Field Communication (NFC)
messages is covered by the NFC Data Exchange
Format (NDEF) specification [1], published by the
NFC Forum, and signatures on such messages aredefined by the Forum's Signature Record TypeDefinition (Signature RTD) in [2]. This paper takes acritical look at the signature specification, explores
some of its vulnerabilities and proposes
countermeasures to two straightforward attacks onsigned messages under the current NFC
specifications.

Near Field Communication (NFC) is a shortrange wireless technology compatible withcontactless smart cards (ISO/IEC 14443) and radiofrequency identification (RFID) [4]. NFC is on the
13.56 MHz frequency band and operates at a
distance of less than 4 cm. It uses magnetic field
induction for communication and powering the chip.
NFC technology has a number of applications
such as ticketing and payment, retrieving informationfrom information kiosks or setting up connections
between devices (so called device pairing). A wide
variety of applications is possible using thetechnology because of the different operation modes
supporting both communication from device todevice (peer-to-peer mode), communication between
a device and a passive tag (read/write mode) and an
emulation mode where a device can act like acontactless smart card [5].
NFC technology is now available on cell phones
resulting in a sharp rise in its use. It makes life easierand more convenient for consumers around the world
by making it simpler to make transactions, exchange
digital content, and connect to electronic devices
with a touch. Multiple modes allow consumers to
perform contactless transactions, connect to peer
devices for data sharing or interact with a variety ofcontactless “smart objects” through their mobile
devices. For example, a customer could initiate theprocess of buying a cinema ticket by touching his
NFC mobile phone against a smart movie poster.
NFC technology provides the capability for ticketing,banking and other applications, which were
historically installed on contactless security tokens,
to be implemented on mobile devices. These
functionalities allow NFC-enabled mobile phones tobe used as if they were contactless smart tokens, e.g.
for retail payments at point of sale (POS) terminals
or swiping an e-ticket at a turnstile. They also
provide the opportunity for a single device to containmultiple tokens [6]. This technology is highly
suitable for monetary transactions (especially micropayments) because of its shorter range andcompatibility with contactless smart cards.

problems [2]. Its main objective is to digitally sign
the data fields of an NDEF message, thus providing
integrity and authenticity.

3.1. NFC Data Exchange Format
The NFC Data Exchange Format (NDEF)
specification defines a common format and rules toexchange information in the NFC environment.
NDEF is a lightweight, binary message format thatcan be used to encapsulate one or more applicationdefined payloads of arbitrary type and size into asingle message construct. Each payload is describedby a type, its length, and an optional identifier. A
record is the unit for carrying the payload within an
NDEF message. An NDEF message contains one ormore NDEF records [1]. The structure of an NDEF
record is shown in Figure 1.

3. The NFC Forum
The NFC Forum was established in 2004 to
standardize applications which use NFC [7]. The
NFC Forum promotes sharing, pairing, andtransactions between NFC devices or tags. In June
2006, the Forum formally outlined the architecture of
NFC technology. One such use of NFC tags is in socalled Smart Posters. These contain information suchas the Title, an SMS, and a URL or electronicbusiness card. The user can access this information
simply by touching his cell phone on such tags.
Apart from displaying the information to the user,
the smart poster can also trigger an action such as
opening a specific website, calling the telephone
number stored in the poster, etc [8]. (This should, ofcourse, be subject to the consent of the user’s
security policy settings.)
With the increasing number of available
applications of NFC technology, threats of its abuse
are also emerging in parallel. In the case of abuses
related to smart posters, an attacker may replace the
URL address or the telephone number with malicious
content. Consequently, it is essential to guarantee theintegrity and authenticity of NFC data.
The NFC Forum developed the Signature Record
Type Definition (Signature RTD) in 2010 to fix such

Figure 1. NDEF Record Layout ([1], fig. 3)
The Message Begin (MB) and Message End (ME)bits indicate the first and the last record of an NDEF
message respectively. The Chunk Flag (CF) specifies
that the payload of that record is continued in thenext record. Short Record (SR) is a 1-bit flag which,if set, indicates that the size of the Payload-Length
field is one byte. In this case, the size of Payload is
restricted to between 0 and 255 bytes. Otherwise, thePayload-Length field consists of 4 bytes (as shownin Figure 1) and it determines a Payload size ranging
from 0 to 232-1 bytes. The flag IL determines
whether or not the optional ID field andcorresponding ID-Length field are present.
The Type Name Format (TNF) is a 3-bit fieldindicating the structure of the Type field which gives
the type of Payload. Its value ranges between 0 and 7with meaning as shown in Table 1. Type-Length andID-Length are unsigned 8-bit integers that specify thelength in octets of the Type field and ID field
respectively. The Type field describes the type of
Payload, and the optional ID field is a URI
reference.
Table 1. Type Name Format (TNF)
Description (cf [1], table 1)
TNF

0

1

2
3
4

5

6

7

Meaning
The record is empty and there is no
payload or type associated with thisrecord. The corresponding length fields
are set to zero. This TNF value can beused whenever an empty record is needed.
Indicates that the Type field contains avalue that satisfies the RTD type nameformat defined in the NFC Forum RTD
specification, such as Smart poster RTD,
Signature RTD, URL RTD etc.
Type is a MIME media type identifier(RFC 2406).
Type is an absolute URI (RFC 3986).
Type is an NFC Forum external type.
Type is of unknown format. It is used
when the type of the payload is unknown.
When used, the Type-Length field must be
zero and thus the Type field is omitted. In
this case, the payload is stored but notprocessed.
The record continues the payload of thepreceding chunked record. When used, the
ID-Length and ID fields are omitted, theType-Length field must be zero and there
is no Type field.
Reserved for future use.

3.2. Record Chunks
A record chunk carries a chunk of a payload. It
can be used to partition dynamically generated
contents or very large entities into multiple
sequential record chunks within an NDEF message.
Every chunked payload is encoded as an initialrecord chunk followed by zero or more middle
record chunks and concluded with a terminatingrecord chunk [1].
The initial record chunk has its CF flag set. The
Type field and the ID field (if present) indicate theType and ID of the entire payload respectively. The
Payload-Length field indicates the size of payload of
the initial record only.
The middle and terminating record chunks do nothave Type and ID fields as these are alreadyindicated in the initial chunk. Their TNF field value
is 6, indicating that the Type and ID are the same as
for the initial record chunk. Their Type-Length and
ID-Length fields are zero and absent respectively.

The CF is set for middle chunks and is clear for theterminating chunk.

4. The Signature Record Type Definition
The Signature Record Type Definition specifies
the format used when signing single or multiple
NDEF records [2]. It defines a list of suitablealgorithms and certificate types that can be used tocreate the signature. It provides users with thepossibility of verifying the authenticity and integrityof the data within the NDEF message.

4.1. The Signature Record
The contents of the payload of a signature record
consist of three parts: Version, digital Signature andCertificate Chain as shown in Figure 2. The Version
is a single byte field indicating the version of thespecification to which a signature is compliant.
Currently the only valid version is 1. The Signaturefield contains either the actual signature or a URI
reference to a signature. The signature RTD supports
RSA, DSA and ECDSA. The Certificate Chain
contains the certificate format, the total number ofcertificates, the list of certificates and an optional
URI reference.
URI
Present

Cert
FormatVersionSignature

URI
Present

Signature
Type

Numberof CertCertificate Certificate/URI
Length, Value
Store
Store

Certificate Chain

Signature/URI
Length, Value

Figure 2. Payload of an NDEF signaturerecord, based on [3], fig. 2

4.2. Use of the Signature Record in an NDEF
Message
The signature record applies to all preceding
records, starting either from the first record of an
NDEF message or from the first record following thepreceding signature record as shown in Figure 3.
Signature Record 1 signs Records 1 and 2. It also
marks the start of the signature of Record 3.
Signature Record 2 signs Record 3 only whereas
Record 4 has no signature. The signature is applied
to the Type, ID (if present) and Payload of theserecords. The NDEF header and length fields are notsigned as shown in Table 2.
In case where only a selection of records in an
NDEF message is required to be signed, an empty
signature record can be inserted into the record
sequence to act as a start marker. An empty signaturerecord has TNF=1 (as it is NFC Forum well-known

Figure 3. An NDEF message consisting ofmultiple records [3], fig. 3.
type record), Type as 'Sig' and there is no payload
associated with this record. Such a record indicatesthat the preceding records back to the start or theprevious signature record are unsigned.
Table 2. Signing an NDEF Record ([2], §3.4)
Field Name
Message Begin (MB)Message End (ME)Chunk Flag (CF)Short Record (SR) Flag
ID-Length (IL) Present Flag
Type Name Format (TNF)
Type-Length
Payload-Length
ID-Length
Type
ID
PayloadSigned/Unsigned
Not Signed
Not Signed
Not Signed
Not Signed
Not Signed
Not Signed
Not Signed
Not Signed
Not Signed
SignedSignedSigned

5. Related Work
Haselsteiner [9] discovered that the transmission
between the tag and the reader can be modified by anattacker. He pointed out that all the transmitted bits
can be modified if Manchester coding with 10%
ASK is used whereas, for Miller encoding with
100% ASK, this attack is feasible for certain bits but
impossible for others. A strong synchronization isrequired between the attacker’s device and legitimate
devices to implement this attack, making it less thanpracticable. However, the concern here is mostly
over reading tags with illegitimate content rather
than the subversion of content during transmission.
Madlmayr [5] indicates that the NDEF data isprone to various attacks if proper protection is not
used. Roland [10] carried out an analysis regarding
signing an NDEF message. He provides thejustification for signing a few selected fields of an
NDEF message. Roland in [3] exploits somevulnerabilities of the Signature RTD.
Mulliner [4] analyzes the security of NFCenabled mobile phones. He takes into account not
only the NFC-subsystem but also software
components that can be controlled through the NFCinterface. The author used the Fuzzing technique totest the NFC software of the Nokia 6131. He foundthat an NDEF payload length field with values
0xFFFFFFFF and 0xFFFFFFFE causes the phone

to crash and reset. He also exploits the size of thedisplay screen to launch some attacks on the smart
poster.
Verdult and Kooman [11] demonstrate some
practical attacks on the Nokia 6212 Classic. It allows
users to exchange digital objects easily using the
NFC interface. To do so, two phones should bewithin the proximity coupling distance of about 5
cms. This paper shows that the NFC feature thatinvokes a Bluetooth connection without user consent
can be abused to install malicious software secretly
on the phone. This results in a serious vulnerability
when smart posters start installing malicious
software or spreading viruses.
Francis et al. [6] investigate the possibility that a
Near Field Communication (NFC) enabled mobile
phone, with an embedded secure element (SE), could
be used as an attack platform. They showed how an
NFC mobile phone can be used for a tag cloning andskimming attack. Their findings indicate that theembedded SE with the existing security controls andthe available contactless APIs could be exploited toconfigure the mobile phone as a contactless attack
platform.

6. The Record Composition Attack
The Record Composition Attack is aimed atcomposing different records in such a way that thedigital signature remains valid. There are two
scenarios described by M. Roland to accomplish this
attack [3].
In the first scenario, two different smart posters
are selected in which every record has its own
signature. A malicious smart poster record can becreated by selecting only a few of the records alongwith their signatures from the first poster and otherrecords along with their signatures from the second
poster. Similarly, unrelated records along with theirrespective signatures from a number of different
posters can be combined together into a single NDEF
message. The combined NDEF message will consistof a sequence of records that may be totally
meaningless or convey misleading information, but
still have valid signatures covering the wholemessage.
In the second scenario, the Record Composition
Attack is accomplished by combining and hiding
selected records from different NDEF messages. An
adversary takes two or more smart poster records
signed by the same or different parties. Each smart
poster consists of records of various types like Text,
URI etc. followed by the signature. The attacker
takes all records from the posters and combines them
to form a new smart poster record. The new poster
will have valid signature records corresponding todata from each parent tag. The attacker theneffectively removes the unwanted records from themessage by hiding them from the viewer, but keeps
the signatures valid.
As all the records are digitally signed, the actual
removal of any record invalidates the signature.
Instead, the chosen records are retained but hiddenfrom the user by manipulating the unsigned TNF
field. The TNF value is changed from 1 to 5, i.e.
from an NFC Forum well-known type to an unknown
type. The TNF value can be changed as it is not
signed. The NDEF parser receiving an NDEF record
with a TNF value of Unknown will store the Payloadof that record without processing it. In this case the
Payload will not appear to the user. So, rather thanremoving a record, it has been hidden simply bychanging the TNF value.

the ID field is not present, as shown in Figure 4, but
in the presence of an ID field it results in a new andprobably invalid ID' field that may be detected by asemantic check. No bytes need removing or adding
to the record in these cases.

7. The Amended Attack

We propose another solution, which cannot becaught by a semantic check on either the Type fieldor the ID field. Since it has no type, the Payload
cannot fail a semantic check either. First set the IL
flag to zero if it is not already zero, and remove thebytes containing the ID-Length, as in Figure 5. Then
increment Payload-Length by (Type-Length)+(IDLength), so that the new Payload consists of theconcatenation of all the bytes formerly in the Type,ID and Payload fields. In this case, Payload' consistsof all the signed bytes.

In fact, Roland’s attack [3] described thus far does
not necessarily work because there are a few otherchanges that may have to be carried out in order tokeep the signature valid. These necessary
modifications were overlooked in [3].
For the new TNF=5 of the hidden records, theType-Length field must be zero and there can be noType field (see Table 1). This is not the case for theoriginal record (TNF ≠0,6). As the Type-Length field
is not signed it can indeed be changed to zero, but
the Type and ID fields are digitally signed andomitting or altering these fields to maintain ameaningful payload may invalidate the signature.
Specifically, in order for the signature to remain
valid, the original signature on the string
Type||ID||Payload has to be the same as thesignature on the new string ID'||Payload'. These
strings must therefore be identical, with its initialinterpretation replaced by one with a different,
possibly invalid ID' and a new, probably
meaningless, message Payload'. Quite apart from thesemantic issues, the signature verification now fails
unless the number of signed bytes is the same, i.e.
(Type-Length) + (ID-Length) + (Payload-Length)= (ID-Length') + (Payload-Length')
Therefore, apart from changing the TNF value,
some further manipulation of the NDEF header may
be required, together with adjustments to the Type-,
Payload- and ID- lengths and corresponding
removal, addition or repartitioning of bytes in thecorresponding three fields.
When the IL bit is set, one easy solution is toincrement the original value of the ID-Length or
Payload-Length field by Type-Length. This
corresponds to a reallocation of some of the signed
bytes to the ID and Payload fields. When the IL flagis zero this still works providing it is the Payloadlength field which is incremented by Type-Length asmentioned in [10], Section V(L). It works well when

MB ME CF SR IL=0TNF=1MB ME CF SR IL=0TNF=5

Type-Length=2Type-Length=0Payload-Length=7Payload-Length=9Type (2 Bytes)
Payload (9 Bytes)
Payload (7 Bytes)

Figure 4. Example changes in the NDEF
header when the ID field is absent.

MB ME CF SR IL=1

TNF=1

MB ME CF SR IL=0TNF=5

Type-Length=2Type-Length=0Payload-Length=7Payload-Length=11

ID-Length=2Type (2 Bytes)

Payload (11 Bytes)

ID (2 Bytes)
Payload (7 Bytes)

Figure 5. Example changes in the NDEF
header when the ID field is present.

8. The Record Decomposition Attack
In the second attack described by Roland et al. in[3], the payload is split (but not chunked) into twoparts and spread over two records. The second part is
hidden by using a record of unknown type, i.e.
TNF=5. Since Payload-Length is an unsigned field,
it can be changed in the first record without
detection. The signature is computed over the
concatenated bytes from the Type, ID and Payload of
all records being signed. So, for the two new records
to generate the same signature, it just requires thesecond record to have no Type or ID fields. The
unknown type does this job as a record with an
unknown type has no Type or ID fields. The only
thing required to accomplish this attack is thesuitable completion of the NDEF header fields of the
new unknown-type record.

An example of such an attack is the text of asmart poster stating, “Do not board the train until
you have a valid ticket”. This text is digitally signed
and the signature is stored using the Signature RTD.
An attacker may split this message into two separate
records as above. The first record stating “Do notboard the train” will be visible to the user, whereas
the second record stating “until you have a valid
ticket” will not appear to the user as it is sent with
the NDEF header fields stating unknown type.
However, the digital signature will remain valid andso the user will consider it as a valid message. This
attack of Roland works in its original form without
further modification of length fields such as thosedescribed in the previous attack.

9. Countermeasures
Roland proposed that the receiver should only
trust the payload bytes from a sequence of records ifthey are signed and share a common signature record[3]. But this needs very careful interpretation. As
shown in the example of the Record Decomposition
Attack in §8, the records share a common signaturebut only part of the message payload is displayed tothe user. This partially displayed message with avalid signature cannot be trusted. Hence, the user’sview of the message cannot be trusted even if all its
records share a common signature.
The easiest way to avoid these attacks would be
to sign all the header fields so that they may not bealtered, but in practice this is out of the question. For
example, the MB flag is intentionally unsigned sothat a group of signed NDEF records may be moved
to any position within an NDEF message [10]. This
enables a variety of messages to be constructed for
different target viewers around an important corecontent which is signed. However, it is unnecessary
to sign the ME flag as the end of the section of themessage which needs to have its integrity secured ismarked by the signature record, so all the records
preceding the signature record will have ME = 0.
A principle requirement of the signaturedefinition is to be able to partition an NDEF record
into multiple record chunks or vice versa as shown in
Figure 6 without affecting the validity of thesignature. This means, in particular, that only the
Payload can be included in the signature for records
after the first chunk, and that the chunk flag CF must
be omitted from any header data that is included in
the signature. The inclusion of any other field fromthe non-initial chunks, such as length fields, TNF or
CF in the signature would also invalidate thesignature. The fields from the initial chunk which are
independent of whether or not the record is chunked
are the only ones which could be included in thesignature. They are the MB, IL and TNF fields in theheader byte, the Type-Length and Type fields, andthe ID-Length and ID fields.

However, one could sum the payload lengths
from each chunk to obtain the same payload length
as in the unchunked record, and include that in thesignature because it is unaffected by chunking. This
needs to be done with care as it should be possible tocompute the signature using a block by block hashfunction without having to store every chunk
payload. The message digest and total payload lengthmust therefore be computed in parallel and, once thelast chunk has been read, the length appended as asuffix to the string to being hashed. The resulting
MAC is then signed and, if necessary, validated.
NDEF Record

Chunk 1 Chunk 2...

Signature

Chunk nSignature

Figure 6. An NDEF record appended withits digital signature is partitioned into
multiple chunk records. The signature isvalid for both cases.
Another principle which we may wish to respectin proposing any revision of specifications is to insist
that the signature is computed on the same
components of each record irrespective of chunking.
This would slightly simplify validation code, as
would omitting the payload length computation.
The last principle worth mentioning is the desire
to compute signatures directly from the concatenatedrecord bytes in the order they appear and without
alteration. It is easy to observe that the attacks above
would not work if, for example, an extra byte B of
fixed value were inserted between the Type, ID andPayload strings when necessary to separate them
before the signature is computed. Thus, when noneof the three components were the empty string, thiswould mean computing the signature of the string
Type||B||ID||B||Payload, but it would be computed onjust Payload when both Type and ID were of length
0. If this were done, the chunking process would not
disturb the calculation of a signature, but the repartitioning of bytes required in the Record
Composition attack would not work. This particularsolution becomes unnecessary if the lengths of thevarious data components are also signed.

9.1. Revision of the Signature Specification
We propose some modifications to the signature
specification. The signature is presently computed
over Type, ID and Payload fields as recalled in
Section 4. Because of the two attacks, the inclusionof additional fields is necessary. However, in orderto preserve the validity of signatures when a record ischunked, a different signature process is required for
non-initial chunks. The proposed modified signature
is compared to the existing specification in Table 3.

Table 3. Comparison of the Existing and the
Proposed Signature Record Specifications
Field Name
MB
ME
CF
SR
IL
TNF
Type-Length
Payload-Length
ID-Length
Type
ID
PayloadExisting
Proposed
Not signed
Not signed
Not signed
Not signed
Not signed
SignedNot signed(unless TNF=6)
SignedNot signed(unless TNF=6)
Signed (inNot signed
modified form)
SignedNot signed(if present)
SignedSignedSignedThe first byte of the NDEF header containing
MB, ME, CF, SR, IL, TNF cannot be added in full tothe signature as noted earlier. However, making the
TNF value immutable is wise. Its updating was thesource of problems in the Record Compositionattack. So, part of our proposal is to sign this for all
records except the non-initial chunks. For TNF≠6,
create a byte TNFB by masking the non-TNF bitsfrom the first byte of the record. This byte will besigned. TNFB will be the empty string for TNF=6,
and so not alter the signature when a record ischunked.
Next, we propose adding the Type-Length and
ID-Length fields to the existing fields for signing
except in the case of non-initial chunks, i.e. records
with TNF = 6, when they are to be omitted. Additionof these two fields to the signature process does notinvalidate the signature under the chunking process.
As noted before, Payload-Length cannot besigned unless the length is accumulated over all
chunks. Let Total-Payload-Length denote the sumof Payload-Lengths over all chunks of a chunked
record, and the normal Payload-Length for an
unchunked record. For convenience, let us define
Total-Payload similarly: it is the usual Payload for
an unchunked record and the concatenation of the
Payloads from all chunks of a chunked record. Thismeans that Total-Payload-Length and Total-Payload
are simply the Payload-Length and Payload of thecorresponding unchunked record.
In our revised signature specification, thecontribution to the signature of all chunks from achunked record is the following string:
TNFB||Type-Length||ID-Length||Type||ID||
Total-Payload||Total-Payload-Length.

The TNFB, Type and ID contributions and theirlengths are, of course, those given in the initial
chunk. The contribution of an unchunked record is
the same, but can be written more simply as
following because it is a single record.
TNFB||Type-Length||ID-Length||Type||ID||
Payload||Payload-Length.
Because of our definitions of Total-Payload andTotal-Payload-Length, the contributions to thesignature are the same for an unchunked record and a
chunked version of the same record. This means thatthe new signature could be simply defined in termsof the concatenated contributions from records in theequivalent unchunked message.
Note, finally, the ambiguity in the string used for
Total-Payload-Length. This could be up to four
bytes, and we do not know if the original unchunked
record used one or four bytes if this length is under
28. A formal specification would have to determine
how it should be given, e.g. the endianness at bit andbyte level using four bytes or using the minimum
number of bytes.

9.2. Suitability for the Record Chunking
Process
The proposed signature scheme can be
successfully used for validating messages with manyrecord chunks without the need to store payload data.
The first half of the contribution from a chunked
record, namely
TNFB||Type-Length||ID-Length||Type||IDis wholly derived from the initial chunk. Thereafter
the string for hashing is given by appending the
chunk Payloads until Total-Payload has been
appended. At the same time, a record is kept of thesum of the Payload-Lengths of the chunks. When thelast chunk has been received, this sum equals therequired Total-Payload-Length, and so its value canbe appended also.
Therefore, a record may be partitioned into
multiple chunks or vice versa without affecting thevalidity of the signature or the ease with which thesignature is computed.

10. Security Analysis of the Proposed
Specifications
The modifications need to be analyzed for thefeasibility of an attack and to justify the inclusion of
the various new fields.

10.1. Counter to the Record Composition
Attack
The main reason for the success of the Record
Composition Attack was the unsigned NDEF header
fields that could be manipulated in a specific way toaccomplish this attack (see Figures 4 and 5). In our
proposed structure, the TNF, Type-Length, PayloadLength and ID-Length fields are signed in addition to
the already signed Type, ID, and Payload fields. So
these fields can no longer be manipulated in therequired way. This makes Record Composition
Attack impossible.
Specifically, in the terminology of section 7, forthe same attack to be successful under the newsignature scheme would require at least Type-Length= Type-Length' = 0 and ID-Length = ID-Length' asthese both fields are signed and cannot be changed.
However, Type-Length = 0 cannot occur when TNF
is other than 0, 5 or 6. Although the original attack
had an initial TNF=1 being changed to TNF=5, weshould consider the possibility of attacks with theseother initial values in order to justify (or not) the
inclusion of TNFB in the proposed signature.
For TNF=0 the record should be empty. In thiscase the Payload is the empty string and making it
invisible will not make any difference to what theuser reads. For TNF=5, an update to TNF=5 also
makes no difference to the message. Finally, TNF=6
indicates that the record is a non-initial chunk.
Changing the field to have the value 5 would change
it to a non-chunked record and result in the inclusionof additional Type-Length and ID-Length fields.
Although the ID-Length field is optional in a record,
the Type-Length field is not. It contributes 1 byte in
the new signature scheme, resulting in a different
signature if TNF is changed from 6 to 5. We
conclude that, whatever the initial value of TNF,
updating it to 5 invalidates the signature under the
proposed scheme just by virtue of including theType-Length and ID-Length fields, no matter how theother fields are changed.
Of course, the user needs to be aware of where
signed messages start and finish since any signed
messages might be combined without change into alarger misleading or wrong message. The signature
specification clearly defines the starting andfinishing point of the data to be signed. It is up to theuser’s browser and security policy to make clear
where signed messages begin and end. Ideally, it
should show a single signed message at a time andindicate that the visible message is signed withnothing hidden.

10.2. Counter to the Record Decomposition
AttackIn this attack, a record payload is decomposed
into multiple parts which are completed to full(unchunked) records by the addition of relevant
header fields. The TNF value for some parts is set to5, making them inactive records. The header fields
also contain a Type-Length field with value zero. As
this one-byte field is digitally signed in the proposed
scheme, it will contribute to the string on which thesignature is computed and result in an invalid
signature. The only way to avoid this byte being partof the signature is to make the second record into a
chunk. However, this requires TNF=6 and so
prevents the value TNF=5 which is needed to hide
the record’s payload in the attack. Thus, the Record
Decomposition Attack is successfully countered in
the proposed scheme.
The specification for the unknown type record
with TNF=5 has some redundant data. The TypeLength field is always zero and therefore redundant.
This redundancy, in contrast to the record chunking
case, proves to be a mechanism preventing theRecord Decomposition Attack. If it were removed,
the heading requirement for the hidden parts of the
payload in the Record Decomposition Attack would
be the first NDEF header byte and the PayloadLength field. If none of this information were
included in the revised signature specification, datafrom the header fields would not invalidate thesignature. Therefore excluding this redundancy
would make the Record Decomposition Attack
feasible for the revised signature specification if it
excluded TNFB and Total-Payload.
In conclusion, although the Type-Length field isredundant in an unknown type record, it helps
prevent the Record Decomposing Attack.
Nevertheless, other fields in the proposed signature
specification ensure that this redundancy could besafely removed.

10.3. Other Combinations of Records
This section discusses other potentially malicious
combinations of records with respect to the proposed
signature specification. §§10.1 and 10.2 considered
all possibilities for hiding part of a signed payload.
One can ask if there are other changes to a sequence
records which would not affect the signature. The
first such combination is to sign the last of the
middle and terminating chunks (and perhaps more
subsequent records) while omitting the initial and thefirst few middle chunks. Although the signature
specification only covers the complete sequence ofchunks, it could be abused, with the first chunk to besigned being treated as the initial chunk, contributing
its values for the ID and Type, among other things.
This combination might have its Type and ID
properties changed since they are inherited from theinitial chunk which may not have been signed.
However, such a change is not allowable according
to the NDEF specification [1]. This is because thefirst record in a sequence of signed records must bethe first record of the message or be preceded by asignature record. As a signature record cannot be a
chunk (it has TNF=1, not 6), the start of the signed
sequence of records must be before the initial chunk.
Consequently, the Type and ID properties and theirlengths are always signed for the part of the payload
which is signed.
Let us now consider manipulation of theunsigned bits in the first header byte. We can ignore
the MB and ME flags as they do not affect thesemantic content of the records.
Any alteration to the SR bit changes the locationof the other signed bytes, such as the Payload. This
leads to an invalid signature unless there is acorresponding addition or removal of three PayloadLength bytes. If this changes the value of PayloadLength then the signature will be incorrect as thatvalue is signed. If that value is unchanged then the
Payload is unchanged, so that the interpretation of
the record is unchanged. Hence if the SR bit can bechanged without invalidating the signature then themessage content is unchanged.
Switching the IL bit without invalidating thesignature is not possible except for non-initial chunks
where the value is irrelevant. Moreover, the IL flag isalways zero for non-initial chunks as defined in the
NDEF specification [1]. Changing IL introduces abyte for ID-Length into the signature stream or
removes it, thereby altering the signature.
Finally, we briefly comment on the need toinclude the TNF value in the signature. For example,
without TNFB, any of the values 1, 2, 3, 4 might beinter-changed without change to the sequence ofbytes being signed. This would lead to a different
interpretation of the Type value and hence a different
interpretation of the Payload. We would then have torely on the parser flagging an inconsistency. It isquite possible, although unlikely, for the differently
interpreted payload to convey incorrect information
to the user. Thus it is still wise to include TNFB in
the signature scheme.

11. Implementation Issues
11.1. Modification
Specification

to

the

Signature

The proposed signature scheme is different fromthe existing one because of the addition of, inter alia,
Type-Length and ID-Length fields. As such, it must
be assigned a different version number in order tomaintain backward compatibility. Fortunately, in thisspecification there is a version number which can beincremented.
The payload of the signature RTD consists ofthree fields as noted in §4, Fig 2: Version, Signature
and Certificate Chain. These three fields aretransmitted in the same order, with Version in firstplace. An NDEF parser can determine the signature

specification by first analyzing the version number.
This is a single byte field so it can handle up to 256
versions of signature specification. As the existing
signature specification is the only version presently
available, the only currently valid version number is
1. So our proposed signature specification should begiven version number 2.
The proposed specification is not compatible
with version 1 because of the extra signed fields.
Hence signature validators will have to be upgraded
to enable version 2 signatures to be checked.

11.2. Modifying the NDEF Specification
Implementing changes in the NDEF specificationis tricky as there is no Version field available in the
NDEF format. This could be implemented by adding
a single byte version number prefix with mostsignificant bit 0 to distinguish it from the initial byteof the first record which has MB flag set to 1.
Alternatively a complete version record could beconstructed with additional details for parsing theinformation efficiently. However, it seems sensible
to avoid changing both the NDEF and Signature
RTD specifications when it is only necessary tochange one of them.

11.3. The User Interface
A digitally signed NDEF message should display
some information for the user at the applicationlevel. It may include the name of the signingauthority (from an x.509 certificate) with some
additional details for the assurance of the user.
Our consideration of security issues showed that
it is still important for users to be informed whether
or not messages have been signed and for theirbrowsers to make clear where individual signed
messages begin and end. It should not be possible forsigned messages to be concatenated without the user
being aware where one message has finished and thenext has started.
A signature can potentially be removed from a
tag without any indication to the user (such as in a
duplicate tag). It is up to the user whether he trusts
the contents of a message without a signature or not.
However, it is clear from the example attacks that thebrowser should be pro-active in warning the user ofpotential dangers, including the lack of any
signature.

12. Conclusion
The Record Composition and Decomposition
Attacks exploit unsigned fields in the NDEF header.
Previously proposed attacks were not fully
implementable without further modifications to theseheader fields. We refined those attacks and explained
precisely what additional changes need to be made toexploit the unsigned fields. Such attacks can becountered if the length fields of the NDEF header are
also signed. We proposed a solution that requires
modification to the Signature RTD in which,amongst others, the TNF, Type-Length, PayloadLength and ID-Length fields are included. We
presented a security analysis of the proposed scheme,
and verified that it was no longer possible to exploit
the NDEF header in attacks of the type discussed,
thus successfully countering Record Composition
and Decomposition Attacks in particular. Inclusionof the TNF field accounted for some remaining
semantic issues. Because of their impracticality, we
discarded alternative solutions involving updating
the NDEF specification.

13. References[1] NFC Forum, “NFC Data Exchange Format (NDEF):
Technical Specification”,
http://www.nfc-forum.org/specs/spec_list/, July 2006.
[2] NFC Forum, “Signature Record Type Definition:
Technical
Specification”,
http://www.nfcforum.org/specs/spec_list/, November 2010.
[3] Michael Roland and Josef Langer and Josef Scharinger,“Security Vulnerabilities of the NDEF Signature Record
Type”, Third International Workshop on Near Field
Communication, Hagenberg, Austria, February 22-23,
2011. IEEE Computer Society, 2011, pp. 65–70.
[4] C. Mulliner, “Vulnerability Analysis and Attacks on
NFC-Enabled Mobile Phones”, The Forth International
Conference on Availability, Reliability and Security,
Fukuoka, Japan, March 16-19, 2009. IEEE Computer
Society, 2009, pp. 695–700.

[5] G. Madlmayr, J. Langer, C. Kantner, and J. Scharinger,“NFC Devices: Security and Privacy”, Third International
Conference on Availability, Reliability and Security,
Technical University of Catalonia, Barcelona, Spain,
March 4-7, 2008. IEEE Computer Society, 2008, pp. 642–
647.
[6] L. Francis, G. Hancke, K. Mayes, and K.
Markantonakis, “On the security issues of NFC enabledmobile phones”, International Journal of Internet
Technology and Secured Transactions, vol. 2, Number 34, 2010. Inderscience Enterprises Ltd, 2010, pp. 336–356.
[7] NFC Forum, “NFC Forum
http://www.nfcforum.org/home/, 2004.

HomePage”,[8] NFC Forum, “Smart Poster Record Type Definition:
Technical Specification”,
http://www.nfc-forum.org/specs/spec_list/, July 2006.
[9] E. Haselsteiner and K. Breitfuß, “Security in Near Field
communication (NFC): Strengths and Weaknesses”,
Workshop on RFID Security (RFIDSec), Graz, Austria,
July 12-14, 2006.
[10] M. Roland and J. Langer, “Digital Signature Records
for the NFC Data Exchange Format”, Second International
Workshop on Near Field Communication, Monaco, April
20-22, 2010. IEEE Computer Society, 2010, pp. 71–76.
[11] R. Verdult and F. Kooman, “Practical attacks on NFC
enabled cell phones”, Third International Workshop on
Near Field Communication, Hagenberg, Austria, February
22-23, 2011. IEEE Computer Society, 2011, pp. 77–82.
[12] M. Q. Saeed and C. D. Walter, “ A Record
Composition/Decomposition Attack on the NDEF
Signature Record Type Definition, 6th International
Conference on Internet Technology and Secured
Transactions, Abu Dhabi, UAE, December 11-14, 2011.
IEEE Computer Society, 2011, pp 284-287.