#40 AbstractLDSFile.getEncoded() returns different array than from creation

[Arnljot]

Due to peculiarities in how datagroups are decoded vs encoded differences LDS file content can arise between input and output.

This is a problem for BCS if getEncoded() is used to generate hash digest to check against in SOD.

We observe this in JMRTD 0.6.4 that we're using.

Here are some examples of what we have observed:

• DG2: JP2000 pictures in DG2 often have 0 as width and height. DG2File will set default values 600x800 if read sizes are 0. getEncoded() will then generate LDS file byte contents different from what was read from the chip, and signed into the SOD. This is one example of observed introduced differences. I'm not sure if there are other sources.
• DG11/12: Hungarian passports Hex encode dates. When JMRTD encodes these dates, it encodes it according to ICAO, and thus the file is different from what was read from the chip.
• DG14: Also here we see constant differences between what is read from the chip and generated from JMRTD. I have not been able to trace through the code to pinpoint where the change arises.

It's probably possible for this to happen with the other objects as well, but these are the goups we see it happen most frequently with. We've found a workaround by holding the original data for later when we're verifying SOD hashes vs the LDS file contents. But this is a heads up for other users, and also default values (like width and height) in DG2 is unfortunate, and it varies if the Hex date format triggers warn logging or not (DG11 doesn't DG12 does).

The base64 encoded text below is from a specimen that has different input from output when testing it with DG14File class. The LDS file is taken from a specimen, but it's the same for production data.

We are investigating the SOD object as well, if we can have instances in getEContent() that are similar to this. We have suspicions but nothing conclusive yet.

=== START===
boIDdzGCA3MwggFFBgkEAH8ABwICAQIwggEzMIHsBgcqhkjOPQIBMIHgAgEBMCwGByqGSM49AQECIQD/////AAAAAQAAAAAAAAAAAAAAAP///////////////zBEBCD/////AAAAAQAAAAAAAAAAAAAAAP///////////////AQgWsY12Ko6k+ez671VdpiGvGUdBrDMU7D2O848PifSYEsEQQRrF9Hy4SxCR/i85uVjpEDydwN9gS3rM6D0oTlF2JjClk/jQuL+Gn+bjufrSnwPnhYrzjNXazFezsu2QGg3v1H1AiEA/////wAAAAD//////////7zm+q2nF56E87nKwvxjJVECAQEDQgAE1/qneM0gxHwQ7GMu0kTrQhlsufy/Wwq7w4IkBPPRIJuz7vCXi/ImeLwk/Dg161u/wqVy+rrP2ORHcNiwW34XygIBADCCAccGCQQAfwAHAgIBAjCCAbUwggFNBgcqhkjOPQIBMIIBQAIBATA8BgcqhkjOPQEBAjEA//////////////////////////////////////////7/////AAAAAAAAAAD/////MGQEMP/////////////////////////////////////////+/////wAAAAAAAAAA/////AQwszEvp+I+5+SYjgVr4/gtGRgdnG7+gUESAxQIj1ATh1rGVjmNii7RnSqFyO3T7CrvBGEEqofKIr6LBTeOscce8yCtdG4dO2KLp5uYWfdB4IJUKjhVAvJdv1UpbDpUXjhydgq3NhfeSpYmLG9dnpi/kpLcKfj0Hb0omhR86doxE7XwuMAKYLHOHX6BnXpDHXyQ6g5fAjEA////////////////////////////////x2NNgfQ3Ld9YGg2ySLCneuzsGWrMxSlzAgEBA2IABDMRRbFKHkxAG2JdIfsC2PeDHJhnU55olMvEZv5kLfj9+W3GoDb/RwVoH47GrfN6zkTUsX1L1vDfOuj8cK/5PnlNDNNb65Zzb3b4HOvbV0XxC93TWeYIApfgEfipTqRUlwIBATASBgoEAH8ABwICAwIBAgEBAgEAMBIGCgQAfwAHAgIDAgQCAQECAQEwDQYIBAB/AAcCAgICAQEwEgYKBAB/AAcCAgQCBAIBAgIBEDASBgoEAH8ABwICBAQEAgECAgEN
=== END ===

[Martijn Oostdijk]

Yes, decoding and then encoding again is not guarenteed to yield the original byte[].