ISO/IEC 20248 Automatic Identification and Data Capture Techniques – Data Structures – Digital Signature Meta Structure is an international standard specification under development by ISO/IEC JTC 1/SC 31/WG 2. This development is an extension of SANS 1368, which is the current published specification. ISO/IEC 20248 and SANS 1368 are equivalent standard specifications. SANS 1368 is a South African national standard developed by the South African Bureau of Standards. ISO/IEC 20248 [and SANS 1368] specifies a method whereby data stored within a barcode and/or RFID tag is structured and digitally signed. The purpose of the standard is to provide an open and interoperable method, between services and data carriers, to verify data originality and data integrity in an offline use case. The ISO/IEC 20248 data structure is also called a "DigSig" which refers to a small, in bit count, digital signature. ISO/IEC 20248 also provides an effective and interoperable method to exchange data messages in the Internet of Things [IoT] and machine to machine [M2M] services allowing intelligent agents in such services to authenticate data messages and detect data tampering.
Description ISO/IEC 20248 can be viewed as an X.509 application specification similar to S/MIME. Classic digital signatures are typically too big (the digital signature size is typically more than 2k bits) to fit in barcodes and RFID tags while maintaining the desired read performance. ISO/IEC 20248 digital signatures, including the data, are typically smaller than 512 bits. X.509 digital certificates within a public key infrastructure (PKI) is used for key and data description distribution. This method ensures the open verifiable decoding of data stored in a barcode and/or RFID tag into a tagged data structure; for example JSON and XML. ISO/IEC 20248 addresses the need to verify the integrity of physical documents and objects. The standard counters verification costs of online services and device to server malware attacks by providing a method for multi-device and offline verification of the data structure. Examples documents and objects are education and medical certificates, tax and share/stock certificates, licences, permits, contracts, tickets, cheques, border documents, birth/death/identity documents, vehicle registration plates, art, wine, gemstones and medicine. A DigSig stored in a QR code or near field communications (NFC) RFID tag can easily be read and verified using a smartphone with an ISO/IEC 20248 compliant application. The application only need to go online once to obtain the appropriate DigSig certificate, where after it can offline verify all DigSigs generated with that DigSig certificate. A DigSig stored in a barcode can be copied without influencing the data verification. For example; a birth or school certificate containing a DigSig barcode can be copied. The copied document can also be verified to contain the correct information and the issuer of the information. A DigSig barcode provides a method to detect tampering with the data. A DigSig stored in an RFID/NFC tag provides for the detection of copied and tampered data, therefore it can be used to detect the original document or object. The unique identifier of the RFID tag is used for this purpose.
The DigSig envelope ISO/IEC 20248 calls the digital signature meta structure a DigSig envelope. The DigSig envelope structure contains the DigSig certificate identifier, the digital signature and the timestamp. Fields can be contained in a DigSig envelope in 3 ways; Consider the envelope DigSig{a, b, c} which contains field sets a, b and c.
a fields are signed and included in the DigSig envelope. All the information (the signed field value and the field value is stored on the AIDC) is available to verify when the data structure is read from the AIDC (barcode and/or RFID). b fields are signed but NOT included in the DigSig envelope - only the signed field value is stored on the AIDC. Therefore the value of a b field must be collected by the verifier before verification can be performed. This is useful to link a physical object with an barcode and/or RFID tag to be used as an anti-counterfeiting measure; for example the seal number of a bottle of wine may be a b field. The verifier needs to enter the seal number for a successful verification since it is not stored in the barcode on the bottle. When the seal is broken the seal number may also be destroyed and yielded unreadable; the verification can therefore not take place since it requires the seal number. A replacement seal must display the same seal number; using holograms and other techniques may make the generation of a new copied seal number not viable. Similarly the unique tag ID, also known is the TID in ISO/IEC 18000, can be used in this manner to prove that the data is stored on the correct tag. In this case the TID is a b field. The interrogator will read the DigSig envelope from the changeable tag memory and then read the non-changeable unique TID to allow for the verification. If the data was copied from one tag to another, then the verification process of the signed TID, as stored in the DigSig envelope, will reject the TID of the copied tag. c fields are NOT signed but included in the DigSig envelope - only the field value is stored on the AIDC. A c field can therefore NOT be verified, but extracted from the AIDC. This field value may be changed without affecting the integrity of the signed fields.
The DigSig data path Typically data stored in a DigSig originate as structured data; JSON or XML. The structured data field names maps directly on the DigSig Data Description (DDD). This allows the DigSig Generator to digitally sign the data, store it in the DigSig envelope and compact the DigSig envelope to fit in the smallest bits size possible. The DigSig envelope is then programmed in an RFID tag or printed within a barcode symbology. The DigSig Verifier reads the DigSig envelope from the barcode or RFID tag. It then identifies the relevant DigSig certificate, which it uses to extract the fields from the DigSig envelope and obtain the external fields. The Verifier then performs the verification and makes the fields available as structured data for example JSON or XML.
Examples
… excerpt ends here. Continue reading the full article.
