Tony Rosati, RIM

hamburgerfensuckedΑσφάλεια

20 Νοε 2013 (πριν από 3 χρόνια και 8 μήνες)

84 εμφανίσεις

Compact Certificates for NFC Tags

Tony Rosati, RIM


Background


The Signature RTD specifies the use of an X.509 certificate in the signature record
either on the tag or reference by URI. Ideally we want the certificate on the tag
for security and usability. IE the phone does not have to have
Internet

access to
retrieve the certificate.


The challenge with X.509 certificates is that they are large on the order of 1000
bytes for 1024 RSA or 500 bytes for 192 ECDSA. If we conside
r the tag sizes in
table 1, the signature record will only fit on the more expensive type 3 and 4 tags

[1]
.


Table 1: NFC Tag Types


Type 1 Tag

Type 2 Tags

Type 3 Tag

Type 4 Tag

Sample of

Compatible
Products

Innovision
Topaz

NXP Mifare
UL

NXP Mifare

UL
-
C

Infineon SLE
66RxxP

Sony Felica

NXP
DESFire/NXP
SmartMX
-
JOCP

Calypso B

Memory Size


96 Bytes

512 Bytes

64 Bytes

192 Bytes

2048 Bytes

1,4, 9 KB

2KB, 4KB, 8KB,
32KB

Pricing*

Low

Low

High

High


*NFC chips can be incorporated in any tag form factor
such as a sticker or key
fob. Prices vary dramatically depending on volumes and the final form factor.
“Low” here means less than $0.50 in volume, “High” means more than $1 in
volume (and in some ca
ses more that $2 in volume)
.


In addition tags have low
reading speed (e.g. for type A tags which is the case for
NFC
-
Forum Type1, Type2 and Type4A) of 106 Kbit/s max. The net throughput
may be half or less. In addition polling period of reader needs to be added. If we
consider usability for reading tags should

be less than 0.5 second then we should
put maximum ~1,5KB information on the tag including the signature record.


We can develop a certificate format that is much smaller and is able to fit on all
tag types if we relax the requirement for an X.509 certif
icate format.




ECQV Fixed Length Encoding


The Elliptic Curve Qu
-
Vanstone implicit certificate
scheme (ECQV) defined in
SEC 4[2
] is well suited for NFC tags where memory and bandwidth is limited.
ECQV provides a more efficient alternative to traditional certificates. It
conserves memory by issuing a public key reconstruction value (the implicit
certificate). The verifier uses th
e root certificate to extract the public key and
verify the signature per the Signature RTD.


Table 2 proposes a compact fixed length encoding using ECQ
V per SEC4 in 4
0

bytes.


Table 2: Fixed Length Encoding for ECQV
.


Field

Size (bytes)

Version

This
field describes the version of the encoded certificate

1

Issuer
Identifier

The issuer field identifies the
root certificate authority.

2

ValidTo

The certificate is valid until this date.

4

Subject Identifier

The subject identifies the owner of the
private key

that corresponds to the
public key in this certificate


8

Public Key Reconstruction Value

25

Total Certificate Size

4
0


Notes on the fields


Version



we will fix the initial version field value of 0x01. This indicates a first
version and implies a fixed structure certificate defined here. It also requires that
a fixed curve secp192r1 and a fixed hash function SHA
-
1 (or SHA
-
256) be used.
The certif
icate format can ultimately be extended by the creation of a new
certificate version number.


Issuer Identifier



while two bytes is probably insufficient to identify CA’s
appropriately, we will interpret this value as an index value into the NFC
Forum’s r
ecognized CA. Under this interpretation we envision 2
16

= 65536 to be
more than adequate as a lookup into the NFC Forum’s recognized CA.

The CA’s
could be represented in a traditional certificate store as a root CA indexed by
Issuer Identifier defined in

this certificate structure.


Valid to



we will make the convention that all certificates are valid from the
moment they are created and just use a 4 byte value to indicate
the expiration.
We should discuss as a group how we want to encode a valid to
date using 32
-
bits.


Subject ID



we use the convention of 8
bytes that

has widely been adopted as a
subject identifier size in ZigBee and ISA SP100.11a. There they use the OUI
-
64
bit address of the 802.15.4 radio. Regardless, 8 bytes is

more than sufficient to
identify the signers of NFC tags.


Public Key Reconstruction Value



is the 25 bytes required to hold a
compressed public key for the desired security level on the curve secp192r1.


NOTE: If we adopt a stronger security level

at so
me future date
, say 128
-
bits, the
public key reconstruction value grows to 33 bytes on secp256r1, increasing the
overall certificate size to 48 bytes.


References



[1] Elliptic Curve Certificates and Signatures for NFC Signature Records

http://www.nfc
-
forum.org/resources/white_papers/Using_ECQV_ECPVS_on_NFC_Tags.pdf



[2]
SEC 4
: Elliptic Curve Qu
-
Vanstone Implicit Certificate Scheme (ECQV)

http://www.secg.org/download/aid
-
785/sec4
-
0.97.pdf