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].
Sample of
Compatible
Products
Memory Size
Pricing*
Table 1: NFC Tag Types
Type 1 Tag
Type 2 Tags
Type 3 Tag
Innovision
NXP Mifare
Sony Felica
Topaz
UL
NXP Mifare
UL-C
Infineon SLE
66RxxP
96 Bytes
64 Bytes
1,4, 9 KB
512 Bytes
192 Bytes
2048 Bytes
Low
Low
High
Type 4 Tag
NXP
DESFire/NXP
SmartMX-JOCP
Calypso B
2KB, 4KB, 8KB,
32KB
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
The certificate is valid until this date.
Subject Identifier
The subject identifies the owner of the private key that corresponds to the
public key in this certificate
4
8
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 32bits.
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.nfcforum.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