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