KDE PIM/KItinerary/Thalys Barcode: Difference between revisions

From KDE Community Wiki
 
(12 intermediate revisions by the same user not shown)
Line 1: Line 1:
= General Observations =
= Format =
 
This is an ERA SSB version 3 code as described in "European Union Agency For Railways - Technical Document - Digital Security Elements For Rail Passenger Ticketing - TAP TSI TD B.12 - §7 SSB - Small Structured Barcode", with the following details/deviations:
* Issuer code is "3018" (UIC company code of Thalys).
* Always "type 1" / "IRT".
* The flag indicating whether stations are specified as numeric or alpha-numeric format is set to '0' (numeric), but the content is alpha-numeric.
* The departure time is always "0".
* The open text field contains the 17 digit CIN, followed by a space and another single digit ("5" in all samples).
* The DSA signature parameters are encoded as variable length/zero padded ASN.1/BER as found in UIC 918.3 rather than the fixed length split fields specified in ERA SSB.
 
= Obsolete (Bit Layout) =


* always exactly 114 byte
* always exactly 114 byte
* all binary, there are no recognizable ASCII strings in this
* there's two 14-15 byte variable lengths blocks towards the end with very high entropy, possibly some kind of signature
* there's two 14-15 byte variable lengths blocks towards the end with very high entropy, possibly some kind of signature
* based on currently only 4 samples, so there's limited confidence in this
* 0:4 - 2:1 (14 bit) is "3018", which is the UIC operator code of Thalys. This matches Appendix C of ANNEX B.6 of TAP TSI, but unfortunately only for the first 18 bit it seems. Might still mean a similar encoding is used, but in a different layout.
* 0:4 - 2:1 (14 bit) is "3018", which is the UIC operator code of Thalys. This matches Appendix C of ANNEX B.6 of TAP TSI, but unfortunately only for the first 18 bit it seems. Might still mean a similar encoding is used, but in a different layout.
* correlation between samples suggests 20-26 contain departure and arrival stations in an so far unknown encoding
= Bit Layout =


{| class="wikitable"
{| class="wikitable"
Line 17: Line 22:
| 5:0 - 5:7 || 0x01 or 0x02 || class ||
| 5:0 - 5:7 || 0x01 or 0x02 || class ||
|-
|-
| 6:0 - 8:7 || null || ||
| 6:0 - 9:5 || null || ||
|-
| 9:6 - 16:3 || 9 x 6bit string || ticket number ||
|-
|-
| 9:0 - 9:7 || 0x01 || || ticket/traveler count, or traveler type?
| 16:4 - 18:3 || TODO || ||
|-
|-
| 10:0 - 35:7 || TODO || ||
| 18:4 - 22:1 || 5 x 6bit string || departure station || see below
|-
|-
| 36:0 - 42:7 || null || ||
| 22:2 - 25:7 || 5 x 6bit string || arrival station || see below
|-
| 26:0 - 27:7 || TODO || ||
|-
|-
| 43:0 - 49:7 || 0x9a 0c 28 82 c8 22 b2 || || fixed in all samples
| 28:0 - 29:1 || null || ||
|-
|-
| 50:0 - 55:7 || TODO || ||
| 29:2 - 32:1 || 4 x 6bit string || train number || preceding bits might be a 5th character for this
|-
|-
| 56:0 - 58:7 || 0x0a 80 30 || || fixed in all samples
| 32:2 - 33:3 || 9bit uint || coach number || field seems a bit large for this?
|-
|-
| 59:0 - 59:7 || 0x2C or 0x2E || ||
| 33:4 - 35:5 || 3 x 6bit string || seat number ||
|-
| 35:6 - 42:6 || null || ||
|-
| 42:7 - 55:4 || 17 x 6 bit string || CIN || 17 digit number, also seen on some PDF tickets, possibly sequential, common prefix "3084060" in all samples
|-
| 55:5 - 55:7 || TODO || ||
|-
| 56:0 - 58:7 || 0x0a 80 30 || || same TLV/BER/DER-like nested signature block as used by [[KDE_PIM/KItinerary/SBB_Barcode]], 0x80 would be a null-terminated variable length block according to BER
|-
| 59:0 - 59:7 || 1 byte || length of the following data || 0x2C or 0x2E in current samples
|-
|-
|}
|}
Line 49: Line 68:


Remaining bytes are filled by null until reaching 114 bytes.
Remaining bytes are filled by null until reaching 114 bytes.
Strings:
* encoded as 6bit per character
* a character can be converted to the corresponding ASCII value by adding 32
Station identifiers:
* using Benerail identifiers, which consists of 5 upper-case letters, the first two being the ISO 3166-1 alpha 2 code
* very similar to SNCF identifiers, but there are slight differences e.g. for Amsterdam Central (NLASC vs NLAMA).

Latest revision as of 17:54, 9 May 2021

Format

This is an ERA SSB version 3 code as described in "European Union Agency For Railways - Technical Document - Digital Security Elements For Rail Passenger Ticketing - TAP TSI TD B.12 - §7 SSB - Small Structured Barcode", with the following details/deviations:

  • Issuer code is "3018" (UIC company code of Thalys).
  • Always "type 1" / "IRT".
  • The flag indicating whether stations are specified as numeric or alpha-numeric format is set to '0' (numeric), but the content is alpha-numeric.
  • The departure time is always "0".
  • The open text field contains the 17 digit CIN, followed by a space and another single digit ("5" in all samples).
  • The DSA signature parameters are encoded as variable length/zero padded ASN.1/BER as found in UIC 918.3 rather than the fixed length split fields specified in ERA SSB.

Obsolete (Bit Layout)

  • always exactly 114 byte
  • there's two 14-15 byte variable lengths blocks towards the end with very high entropy, possibly some kind of signature
  • 0:4 - 2:1 (14 bit) is "3018", which is the UIC operator code of Thalys. This matches Appendix C of ANNEX B.6 of TAP TSI, but unfortunately only for the first 18 bit it seems. Might still mean a similar encoding is used, but in a different layout.
Byte[:Bit] (MSB) Content Meaning Notes
0:0 - 4:7 0x32 F2 84 20 40 fixed in all samples
5:0 - 5:7 0x01 or 0x02 class
6:0 - 9:5 null
9:6 - 16:3 9 x 6bit string ticket number
16:4 - 18:3 TODO
18:4 - 22:1 5 x 6bit string departure station see below
22:2 - 25:7 5 x 6bit string arrival station see below
26:0 - 27:7 TODO
28:0 - 29:1 null
29:2 - 32:1 4 x 6bit string train number preceding bits might be a 5th character for this
32:2 - 33:3 9bit uint coach number field seems a bit large for this?
33:4 - 35:5 3 x 6bit string seat number
35:6 - 42:6 null
42:7 - 55:4 17 x 6 bit string CIN 17 digit number, also seen on some PDF tickets, possibly sequential, common prefix "3084060" in all samples
55:5 - 55:7 TODO
56:0 - 58:7 0x0a 80 30 same TLV/BER/DER-like nested signature block as used by KDE_PIM/KItinerary/SBB_Barcode, 0x80 would be a null-terminated variable length block according to BER
59:0 - 59:7 1 byte length of the following data 0x2C or 0x2E in current samples

After this there follow two blocks with the following variable length layout:

Byte[:Bit] (MSB) Content Meaning Notes
0:0 - 0:7 0x02 fixed
1:0 - 1:7 8bit uint length
N bytes high entropy content

Remaining bytes are filled by null until reaching 114 bytes.

Strings:

  • encoded as 6bit per character
  • a character can be converted to the corresponding ASCII value by adding 32

Station identifiers:

  • using Benerail identifiers, which consists of 5 upper-case letters, the first two being the ISO 3166-1 alpha 2 code
  • very similar to SNCF identifiers, but there are slight differences e.g. for Amsterdam Central (NLASC vs NLAMA).
Retrieved from "https://community.kde.org/index.php?title=KDE_PIM/KItinerary/Thalys_Barcode&oldid=91768"