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 |
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 |
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 |
expiry_date | { "fieldid": "issue_date", "type": "date" } |
2020-07-04
Date as UNIX timestamp: |
32 bits
01011110111111111010101001 |
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 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 |
|
UserMem | 0001101010001101100110110111101100111001 0010001000011000011110011110001111011011 1011000010110010010010101101100100111011 0100101011000000010000001111011110000100 0010010100011010101001000011110001010010 0111001101110001001010100101100101111000 1110101110100100010110110011110011000010 1110001010100000000000000100001001101101 1100011101000000000000110000100110000000 1110000000101111001111100001010000110001 0100011000011011011011100011101000100011 111100000100001000101100011 |
|
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 } } }
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" } }