Legacy fields added to temporary access cards
Description
Some departments have reported issues with older readers not working and their inability to reprogram them. They are strongly encouraged to reprogram them (following card FAQ doc) or replace them if unable to reprogram.
Andrew Vella (DevOps) did some experimentation on the engineering departments affected readers (now replaced) and concluded the following:
Rob, Dave and myself have looked into this issue in a bit more detail. Thus far we have been able to determine:
• Reader type 3 (EEDB - Royce Antenna Door) correctly reads the MIFARE_NUMBER from Sector 1 block 2 when counting from the start of sector 1, corresponding to block 6 when counting from the start of the card.
• Reader type 1, 2, 4 (EEDB - Ground Rear to Offices, EEDB - Sigma SEM Rm 41, EEDB - Royce Electrical Lab) relies on the data in all blocks of sector 1 (blocks 0, 1, 2) in order to return the MIFARE_NUMBER. As a result, as we phase out the legacy_cardholder_id (currently written to block 0) the readers will return the wrong value for MIFARE_NUMBER.
• Filling dummy data into sector 1 block 0 did not work, as readers 1, 2, 4 appear to compute a hash from the value in sector 1 block 0, 1 in order to return the MIFARE_NUMBER (I don’t know why this approach was taken, possible a reflection of how the original MIFARE_NUMBER was generated from the hash of legacy_cardholder_id).
Some experimentation work was done to see if the newer style access cards were the UCam card ID is generated from the Mifare ID (hard coded manufacturer ID) could have block 0 and 1 values generated.
From @ek599
block 0 - Legacy cardholder identifier
block 1 - Issue number
block 2 - UCam card ID / "Mifare Number"
Based on that message from Andrew, it does sound as though the readers are computing the block 2 from blocks 0 and 1 instead of reading block 2, or it's comparing this computation to block 2.
For the personal cards this won't be a problem as the legacy id is still generated by the API and set in block 0. The issue number is written to block 1 and the ucam card id written to block 2 is generated from these 2 values.
The new temporary access cards do not touch the API and we thus cannot generate a legacy id to then compute block 2. Block 2 is generated from a hash of the manufacturer's number by the supplier.
Since your last email I've spent a bit of time experimenting to see if it was possible to create a reverse legacy id from the value in block 2 of the temporary access cards. I believe it is possible for some cards. The algorithm used to generate block 2 is unusual and it's not possible to create all possible values for block 2. Depending on how the card readers generate the value somewhere between 65% and 80% of cards from the supplier could have a legacy id reverse generated.
Reverse generating the access cards block 0 and 1 values is much prefered to changing the temporary access cards UCam card ID algorithm as doing so would potentially further increase the chance of UCam card ID collisions.
Having the printer client print a special temp access card image for cards that could have block 0 and 1 values generate and skipping or printing a normal temp access card image for those couldn't would be one way to do this in "production".
Populating legacy and issue values has not yet been confirmed to work for effected readers. Confirming this with one or more test cards would need to be first action.
A crude snippet of code that can reverse generate the block 0 and 1 values:
https://gitlab.developers.cam.ac.uk/uis/devops/iam/card-database/printer-client/-/snippets/275
Links/references
Engineering complaint in regards to access cards (resolved by replacing readers that couldn't be updated) https://gitlab.developers.cam.ac.uk/uis/devops/iam/card-database/feedback/-/issues/839
Department of Zoology - readers not programmed correctly https://gitlab.developers.cam.ac.uk/uis/devops/iam/card-database/feedback/-/issues/866