Using RFID and DigSigs for EVI

RFID and DigSigs for EVI

There are many applications for DigSigs in the domain of Electronic Vehicle Identification(EVI). This includes possible solutions for parking, access control, tolling and passive tracking strategies.

In this article we will describe how passive UHF RFID windshield label stickers can be used in conjunction with DigSigs to provide vehicle identification solution where:

  • Vehicles can be uniquely identified driving at high speeds
  • Tags are protected against the possibility of cloning
  • All vehicle and licensing information is stored and read from the tags dynamic DigSig data structure

Electronic vehicle identification can be a real challenge especially in remote stations or underground sites where connectivity is severely limited. The old strategy of simply reading the ID from a tag and then performing a database lookup for it simply is not good enough. The DigSig standard allows for offline and on site decoding of the data structure, translation and human readable display for users. By cryptographically verifying the digital signature stored in the RFID user memory data bank we we can also be sure that the tag was not cloned.

A typical EVI data structure

A DigSig is a complex binary data structure that is self identifying, and may contain complex multi tier data structures and field of several data types.

For our example we will design a DigSig data structure using the ISO/IEC 20248 DigSig Definition Descriptor (DDD) language. This language not only describes the fields found in a DigSig, but it also describes the fields that was signed into the signature but whos values were not included in the DigSig itself.

Using the DDD language fields can also be described in such a way so that they are distributed over several data banks of a selected medium.

Create DDD field descriptors for each identified field

The data fields for a typical EVI solution can be described using the ISO/IEC 20248 DDD language. In this section we will show how much data storage we will need for each field by creating an appropriate data descriptor for each of the fields and calculating the data requirements for each such field.

 Field  DDD field  Sample value presented to encoding library Optimised binary encoding using ISO/IEC 20248 
 license_plate
{
  "fieldid": "license_plate",
  "type": "string",
  "range":"[A-Z0-9]"
  "binaryformat": "{1,8}"
}
 “ABC123AA” 54 bits
10100000000000000100001001
10110111000111010000000000
00
colour
{
  "enumvalues": [
    "brown",
    "blue",
    "gold",
    "gray",
    "green",
    "orange",
    "pink",
    "purple",
    "red",
    "silver",
    "white",
    "yellow"
  ],
  "fieldid": "colour",
  "type": "enum"
}
 “brown” 4 bits
0000

Note how the use of enums
drastically reduce space requirements

form_factor
{
  "enumvalues": [
    "VAN",
    "COUPE",
    "PICKUP",
    "SALOON",
    "S.WAGON",
    "LORRY/TRUCK",
    "MOTOR CYCLES"
  ],
  "fieldid": "form_factor",
  "type": "enum"
}
 “SALOON” 3 bits
011

Note how the use of enums
drastically reduce space requirements

 vin
{
  "fieldid": "vin",
  "range": "[A-Z0-9]",
  "type": "string"
}
 “A2B45C789D123E567F9” 125 bits
11000010011000000011100000
00101111001111100001010000
11000101000110000110110110
11100011101000100011111100
000100001000101100011

 

Note that by limiting the alphabet of the
string we greatly improved the storage requirements
of the field

 expiry_date
{
  "fieldid": "issue_date",
  "type": "date"
}
2020-07-04

Date as UNIX timestamp:
1593813600

32 bits

01011110111111111010101001
100000

We should at this point also note the system fields which also need to be stored in the DigSig
Field DDD field Sample value presented to encoding library Optimised binary encoding using ISO/IEC 20248
timestamp
{
  "fieldid": "daid"
}
 1530799687  32 bits
daid
{
  "fieldid": "daid"
}
 “QC TRUE”  40 bits
1100000010011000000101010011001000110110
cid
{
  "fieldid": "cid"
}
 811  16 bits
0000000001100100
signature
{
  "fieldid": "signature",
  "type": "bstring",
  "binaryformat": "{256}"
}

 

We specify the binary format to indicate to limit the length of the field to exactly 256 bits. This way we save more space for not having to add the overhead required by the default variable length binary format

 Go2bezkiGHnj27CyStk
7SsBA94QlGqQ8UnNxKll466Q=

 

This sample signature value
is fictitious, a real one will
be generated during signing.

Base64 URL encoding

0001101010001101100110110111101100111001
0010001000011000011110011110001111011011
1011000010110010010010101101100100111011
0100101011000000010000001111011110000100
0010010100011010101001000011110001010010
0111001101110001001010100101100101111000
1110101110100100

 

256 bits

  • daid – The DAID is a code that uniquely identifies the domain authority. DigSig Certificates required for decoding should be obtained from the domain authority.
  • cid – The DigSig Certificate Id which is unique per domain authority
  • signature – The Digital signature data field that is used to cryptographically verify the integrity of the data fields and to authenticate its contents.

Tag programming profile

By using the “readmethod” pragma feature as described in the ISO/IEC 20248 specification the DigSig will be automatically broken up so that it can be written into the various selected databanks of the chosen media.

For our example we will break up the DigSig into 2 snips, a short snip to be written into the shorter but more accessible UII/EPC memory bank and then another but longer snip intended for the UserMem bank.

Storage required for UII/EPC: 40 + 16 + 4 + 3 + 32 = 95 bits
Storage required for User Memory: 256 + 32 + 54 + 125 = 467 bits

We shall use the DDD “struct” mechanism to group all of the fields intended for the user memory bank together into one data structure. We will then use the readmethod pragma feature to instruct a verifier to fetch the contents of this struct from a separate data bank.

{
  "fieldid": "usermem",
  "type": "struct",
  "pragma": {
    "readmethod": {
      "methodname": "ISO/IEC 18000-63",
      "methoddesc": {
        "en": "User memory bank"
      },
      "methodmemory": [
        3
      ],
      "methodoffset": 0,
      "methodlength": 595
    }
  },
  "fields": [
      …
      …
      … FIELDS TO BE STORED ON USER MEMORY
      …
      …
   ]
}

Example of how a readmethod can be used to describe data fields stored in the rfid UserMem bank

  • methodname – The type of technology to use to collect this data. In this case ISO/IEC 18000-63
  • methodoffset – The data begins at the beginning of the user memory bank. Therefore a zero offset is needed
  • methodlength – The length of the read method is specified to be 595 bits. This way a reader won’t read more than it has to
  • methodmemory – Instructs the reader to fetch this data from memory bank address 3 which is the user memory
 Data bank  Bits  Legend
 EPC/UII 1100000010011000000101010011001000110110
0000000001100100000001101011110111111111
010101001100000
 

  • daid
  • cid
  • colour
  • form_factor
  • expiry_date
 UserMem 0001101010001101100110110111101100111001
0010001000011000011110011110001111011011
1011000010110010010010101101100100111011
0100101011000000010000001111011110000100
0010010100011010101001000011110001010010
0111001101110001001010100101100101111000
1110101110100100
010110110011110011000010
11100010
10100000000000000100001001101101
1100011101000000000000
110000100110000000
1110000000101111001111100001010000110001
0100011000011011011011100011101000100011
111100000100001000101100011
 

  • signature 256 bits
  • timestamp 32 bits
  • license_plate 54 bits
  • vin 125 bits

The final binary result of the memory structure that will be written into the UserMem bank

Including the RFID TID field

We can also craft a readmethod which describes the reading of the TID memory of the RFID tag. By including the data of this databank into the DigSig we can effectively “sign” the TID data into the produced signature thereby forever linking this tag to the signature. By doing so we can protect the tag from forgery.

{
  "fieldid": "tid",
  "fieldname": {
    "en": "Tag ID"
  },
  "type": "bstring",
  "binaryformat": "{96}",
  "pragma": {
    "readmethod": {
      "methodname": "ISO/IEC 18000-63",
      "methoddesc": {
        "en": "Plate serialisation (TagID), memory bank 2."
      },
      "methodmemory": [
        2
      ],
      "methodoffset": 0,
      "methodlength": 96
    }
  }
}
DDD field using a readmethod to describe the collection of data from the TID databank

Full example – DigSig Data Descriptor (DDD)

We can also craft a readmethod which describes the reading of the TID memory of the RFID tag. By including the data of this databank into the DigSig we can effectively “sign” the TID data into the produced signature thereby forever linking this tag to the signature. By doing so we can protect the tag from forgery.

{
  "datafields": [
    {
      "fieldid": "specificationversion"
    },
    {
      "fieldid": "dauri"
    },
    {
      "fieldid": "daid"
    },
    {
      "fieldid": "cid"
    },
    {
      "enumvalues": [
        "brown",
        "blue",
        "gold",
        "gray",
        "green",
        "orange",
        "pink",
        "purple",
        "red",
        "silver",
        "white",
        "yellow"
      ],
      "fieldid": "colour",
      "type": "enum"
    },
    {
      "enumvalues": [
        "VAN",
        "COUPE",
        "PICKUP",
        "SALOON",
        "S.WAGON",
        "LORRY/TRUCK",
        "MOTOR CYCLES"
      ],
      "fieldid": "form_factor",
      "type": "enum"
    },
    {
      "fieldid": "expiry_date",
      "type": "date"
    },
    {
      "fieldid": "usermem",
      "type": "struct",
      "pragma": {
        "readmethod": {
          "methodname": "ISO/IEC 18000-63",
          "methoddesc": {
            "en": "User memory bank"
          },
          "methodmemory": [
            3
          ],
          "methodoffset": 0,
          "methodlength": 595
        }
      },
      "fields": [
        {
          "fieldid": "signature",
          "type": "bstring",
          "binaryformat": "{256}"
        },
        {
          "fieldid": "timestamp"
        },
        {
          "fieldid": "license_plate",
          "type": "string",
          "range": "[A-Z0-9]",
          "binaryformat": "{1,8}"
        },
        {
          "fieldid": "vin",
          "range": "[A-Z0-9]",
          "type": "string"
        }
      ]
    },
    {
      "fieldid": "tid",
      "fieldname": {
        "en": "Tag ID"
      },
      "type": "bstring",
      "binaryformat": "{96}",
      "pragma": {
        "readmethod": {
          "methodname": "ISO/IEC 18000-63",
          "methoddesc": {
            "en": "Plate serialisation (TagID), memory bank 2."
          },
          "methodmemory": [
            2
          ],
          "methodoffset": 0,
          "methodlength": 96
        }
      }
    }
  ],
  "digsiginfo": {
    "cid": 811,
    "daid": "QC TRUE",
    "dauri": "https://dauri1.20248.info",
    "revocationuri": "https://dauri1.20248.info/revoke",
    "specificationversion": "ISO/IEC 20248:2018",
    "verificationuri": "https://v1.20248.info"
  }
}
In trying to keep the DDD short for the example we did not include any field names, descriptions and/or translations thereof in this DDD.