Closed philipdev closed 3 years ago
Hello Philip,
Sorry to hear that, but keep in mind you may always ask questions on our mailing list: https://groups.google.com/g/eid-middleware-dev
The algoritm is indeed different between 1.7 and 1.8 cards:
In 1.8 cards SHA-384 will be used, on older cards it can be either SHA-256 or SHA-1 (it often matches the hash algo of the photo hash in the ID file, but not always (SHA-1 cards can get their address file changed later, and then a SHA-256 hash might have been used to create the new address signature ) )
From the 1.8 documentation (but I presume that is where you found it): 6.2.5. EF(SGN#Address) This transparent elementary file contains the signature of the EF(ID#Address) by the National Register. EF(SGN#ID) is first appended to EF(ID#Address) before signing, in order to ensure the consistency with the file EF(ID#RN). If zero bytes are present at the end of EF(ID#Address), they need to be removed first. Signature format: ECDSA P-384 with SHA-2-384
Thank you for reporting the CS example issue, I'll have a look at it.
I've checked the C# example, though it is just a brief example that lacks e.g. error checking, its integrity check should not have issues with TAG 0. All data is store in byte arrays, and using Array.Copy() to copy them. (btw, the SGN#ID files can also contain zeroes)
Toke me a while to figure out how to verify the address signature:
Also the v1.8 card data documentation seems to contradict the algorithm. Also if the TAG 0 with version would be introduced the integrity check in the CS example would fail (premature ending the file), with some implementation too