Compact Certificates for NFC Tags by FAQ15Hv2

VIEWS: 19 PAGES: 3

									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 consider 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        Innovision     NXP Mifare    Sony Felica          NXP
Compatible       Topaz          UL                                 DESFire/NXP
Products                        NXP Mifare                         SmartMX-JOCP
                                UL-C                               Calypso B
                                Infineon SLE
                                66RxxP
Memory Size      96 Bytes       64 Bytes      1,4, 9 KB            2KB, 4KB, 8KB,
                 512 Bytes      192 Bytes                          32KB
                                2048 Bytes
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 cases 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 certificate 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 the root certificate to extract the public key and
verify the signature per the Signature RTD.

Table 2 proposes a compact fixed length encoding using ECQV per SEC4 in 40
bytes.

                         Table 2: Fixed Length Encoding for ECQV.

Field                                                                         Size (bytes)

Version                                                                       1
This field describes the version of the encoded certificate
Issuer Identifier                                                             2
The issuer field identifies the root certificate authority.
ValidTo                                                                       4
The certificate is valid until this date.
Subject Identifier                                                            8
The subject identifies the owner of the private key that corresponds to the
public key in this certificate
Public Key Reconstruction Value                                               25

Total Certificate Size                                                        40


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 certificate 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 recognized CA. Under this interpretation we envision 216 = 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 some 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

								
To top