Skip to content

Instantly share code, notes, and snippets.

@derhuerst
Last active February 13, 2024 19:37
Show Gist options
  • Star 6 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save derhuerst/26c1706c1bc1d9ebae76104a14d27f97 to your computer and use it in GitHub Desktop.
Save derhuerst/26c1706c1bc1d9ebae76104a14d27f97 to your computer and use it in GitHub Desktop.
how UIC barcodes work

from the Digital Security Elements for Rail Passenger Ticketing technical document:

The whole security system is based on asymmetrical key pairs: Private and Public keys. To ensure the autenthicy of the public keys the keys shall be certified by a certification authority and the certificates exchanged for the ticket control precedures.

These keys are generated on a regular base (e.g. every 6 months) by the party that wants to encrypt data using such a key ("the security provider"). To enable decryption of the encoded data, the corresponding certificate should be made available to every TCO (Ticket Controlling Organisation)

AZTEC is the better one of both because of error-correction, readability in difficult conditions and the fact that it is more variable in size. The reason that the PDF417 barcode (a so called “Stacked linear barcode”) is still in the leaflet, is because there are a lot of applications in use in both airline and railway ticketing using these barcodes.

Step 1: Collection of data elements defining the ticket (local representation of the data in the sales application) : Java, C++, ASCII, UTF-8, EBCDIC, ...

Step 2: Translate this data collection in the data structures, as defined in this document, in the specific chapter about the barcode to be used (SSB, TLB, FCB) + create the seal as defined in the same chapter. Translation of Alphanumerical data is done differently in SSB (ASCII-6) than in TLB&FCB (ASCII-8) due to binary size limitation.

Step 3a: Encode the binary chain into the AZTEC binary content (“AZTEC encoding”).

Step 3b: Translate this binary string in a graphical representation of the barcode (including error-correction data).

The seal, used in the security element, is an encrypted hash code, calculated from the open data in the message (a so-called “encrypted fingerprint”).

This “encrypted fingerprint” mechanism, is a 2-step process. First step, a unique fingerprint is generated for the set of data to be protected (changing any data results in another fingerprint). The mechanism used for this is a public available algorithm (SHA-2), to be used by all railway ticketing related companies. In the second step, this fingerprint is encrypted, also using a public available algorithm with a private key (from the security provider). This result is the so-called “seal”. The use of the asymmetric algorithm makes it impossible to generate a new seal without the private key.

In the security element, generally a barcode, the data is often grouped in 3 logical groups: a header, the ticket data and a signature.

The ticket data is the data that has to be translated in a barcode. The different chapters define how the data has to be coded or represented. (Also called “open data”)

The header makes it possible for a reader to find out which encoding is used, thus how the barcode data should be interpreted and also which (public) keys should be used to check the key.

Finally, the seal is a digital signature, preventing non-recognized railway companies to generate or modify barcodes.

  1. HEADER
  • indicating:
  • which kind of barcode
  • which security provider (often "issuer")
  • which version
  • (all of this for retrieving the right public key), and possibly which ticket type (for fixed-field barcodes - SSB, ELB).
  1. OPEN DATA
  • containing all the necessary ticket info.
  • "Open" means that the info is not encrypted and can be interpreted directly, without any additional action. Technical document TAP TSI TD B.12 ERA-REC-122/TD/02 V2.0
  • If data is structured, it can be by bit-position (SSB, ELB) or by (logical) tagging (FCB)
  • data can be a translation of the layout of the ticket (TLB)
  1. SIGNATURE / SEAL
  • to detect fraud.

5. Hash Code generation - "signature" / "encrypted seal"

5.1. General Mechanism

Encryption process is a 2 phases process:

  1. hash all data in the Header field and Open Data field with the SHA-2 xxx Algorithm.
  2. and then, to crypt the result with the DSA yyyy asymmetric cryptosystem (private-public key).

The output (called the "signature", "encrypted seal" or the "encrypted fingerprint of the data") is containing 2 (big) integer numbers, called "r" and "s" (so defined signature in the FIPS-186 standards, defining DSA).

5.2. Different versions + Size of the seal

This process is defined as (SHA-xxx, DSA-yyyy). The seal obtained is zz bytes long. Mechanisms used in international railway ticketing are:

process xxx (bits) yyyy (bits) zz (bits) zz (bytes, structured ASN-1)
SHA-160, DSA-512 160 512 (2x) 20 46
SHA-160, DSA-1024 160 1024 (2x) 20 46
SHA-224, DSA-2048 224 2048 (2x) 28 62
SHA-256, DSA-2048 256 2048 (2x) 32 70

[...]

The ASN-1 structure adds 6 bytes of data to the actual security elements (r,s). 1byte, indicating the message itself, 1 for the length, then for each of the 2 elements, 1 byte indicating that the number is an integer and 1 indicating the length of the integer (source: ITU X.509).

process SSB size TLB,FCB (V1) size TLB,FCB (V2) size
SHA-160, DSA-512 S 46
SHA-160, DSA-1024 2 (*) 46
SHA-224, DSA-2048 2 (**) 2x28 2 (**) 2x28
SHA-256, DSA-2048 2 (**) 2x32
  • “S” means Structured, “2” means 2 different integers (r and s).
  • (*): commonly used today (Sep 2017)
  • (**): Recommendation (up to 2030)

In TLB & FCB in the first version (header #UT version 1), SHA1 (1024,160) or SHA1 (512,160) are used. In TLB & FCB, in the second version (header #UT version 2), SHA2 (2048,224) or SHA2 (2048,256) are used. In SSB, SHA1 (512,160), SHA1 (1024,160) or SHA2 (2048,224) are used. In the case of the SHA2 (2048,224), there is not enough space in the barcode to put the signature in a structured format, but there is a possibility to store the signature as 2 separate numbers (r and s), where r is the first number and s the second.

In case the seal is stored as 2 separate numbers, the total size (e.g. 56 for SSB) is split in 2 (thus 28 for SSB) second number

6. Different barcodes, used in international ticketing

  • SSB Small Structured Barcode (called “AZTEC V2” in the (old) 918-2V3 leaflet)
  • FCB Flexible Content Barcode (a recent developed 2D AZTEC barcode)
  • TLB Ticket Layout Barcode (called “DST barcode” in the (old) 918-3 leaflet)
  • ELB Element List Barcode (called “PDF 417” in the (old) 918-2V3 leaflet – used by SNCF)
                               RAIL TICKET BARCODE
                           /                         \
                    AZTEC?                        (2) PDF417? (144 bytes)
                   /      \                            /           \
   (3) BIG or Flexible   (4) SMALL and Fixed   (5) Fixed-field    (6) Flex- field
      /            \          (114 bytes)             / \            |
     /              \                   |            /   \           |
(7) STRUCTURED?  (8) ticket layout?    SSB         SSB   ELB     FCB (little data)
      |                 |
     FCB               TLB
  • SSB and ELB are made following a “fixed-field, fixed-size" data encoding mechanism
  • FCB and TLB are made following a “variable-field, variable-size” mechanism

Which barcode to be used by a security provider is depending on (external) parameters.

[...]

ticket type FCB TLB SSB ELB
IRT INTEGRATED RESERVATION TICKET X X X X
RES RESERVATION X X X O(*)
NRT NON-RESERVATION TICKET X X X O
GRT GROUP TICKET (NRT) X X X O
RPT RAIL PASS TICKET X X X O
VET VEHICLE TICKET X X O(*) O
BOA BOARDING PASS X X X O
COI CHANGE OF ITENERARY X X O O
UPG UPGRADE X X O O
SUP SUPPLEMENT X X X O
TLT TRAIN LINKED TICKET X X O O
lTT LOCAL TRANSPORT TICKET X X O O
PARKING X O O O
ENDORSEMENT X O O O
ANNOTATION X O O O
DELAY CONFIRMATION X O O O
CUSTOMER CARD X O O O

X=possible, O=not possible,(*) technically possible, but not yet defined in detail

Glossary

  • 1D barcode 1 dimensional barcode (uses vertical bars for data encoding, limited data capacity)
  • 2D barcode 2 dimensional barcode (uses a 2 dimensional matrix for data encoding)
  • AEA Association of European Airlines
  • ASCII American Standard Code for Information Interchange: a character set and encoding
  • ASN.1 Abstract Syntax Notation one, see ISO/IEC 8824
  • Asymmetric key cryptography cryptography using symmetric key pairs: private and public keys. Safe since the decoding party don’t possess the encoding key, making it possible to check security without the ability to create new security elements.
  • AZTEC is a type of 2D barcode invented by Andrew Longacre, Jr. and Robert Hussey in 1995.[1] The code was published by AIM, Inc. in 1997. Although the Aztec code was patented,[1] that patent was officially made public domain.[2] The Aztec code is also published as ISO/IEC 24778:2008 standard.
  • Carrier keeps contract(CKC) (Old) mechanism, defined in TAP TSI technical document B.7. Not in use anymore.
  • Carrier makes certificate (CMC) (Old) mechanism, defined in TAP TSI technical document B.7. Not in use anymore.
  • Certificate electronic document used to prove the ownership of a public key
  • CIT International Railway Transport Committee.
  • CIV Uniform rules concerning the contract of international carriage of passengers by rail
  • Customer person/company buying the ticket/contract
  • Domestic Ticket A domestic ticket is a ticket sold by a railway undertaking (or under licence of this railway undertaking) for use on this specific railway company. These tickets are not necessary defined by UIC standards.
  • DSA DSA is an encryption algorithm using asymmetric keys and is covered by U.S. Patent 5,231,688, filed July 26, 1991 and attributed to David W. Kravitz, a former NSA employee. This patent was given to “The United States of America as represented by the Secretary of Commerce, Washington, D.C.”, and NIST has made this patent available worldwide royalty-free. see FIPS publication 186.
  • Encrypted fingerprint see Seal
  • ELB Element List Barcode
  • FCB Flexible Content Barcode
  • Hash function is a mathematical operation on a list of data, resulting in a so called hash-code that is unique for this list of data: if anything of the data set is changed, the corresponding hash will be different from the original one. A good hash function is able to detect simple and multiple changes in data. The hash is smaller is size than the original data and is sent together with the data in case of a data transfer. For detecting possible fraud, the hash has to be encrypted before it is added to the actual data.
  • Header – Open Data – Signature/Seal the 3 distinguished parts of a SiD dataset that can be translated in a barcode.
  • NSA National Security Agency
  • O/D Origin / Destination
  • Passenger person travelling with a ticket/contract
  • PDF417 is a so-called “stacked linear barcode symbol”.”PDF” stands for Portable Data File. The 417 signifies that each pattern in the code consists of 4 bars and spaces, and that each pattern is 17 units long. The PDF417 symbology was invented by Dr. Ynjiun P. Wang at Symbol Technologies in 1991. It is published as ISO standard 15438.
  • PER unaligned Packed encoding rules (PER) are ASN.1 encoding rules for producing a compact transfer syntax for data structures described in ASN.1. Unaligned encoding means that the bits are packed with no regard for octet (byte) boundaries. This guaranties maximum usage of every available bit in the data message.
  • PKI Public Key Infrastructure
  • PKMW Public Key Management Website. UIC website containing the public keys of the different security providers. The information has to be provided in a specific way and format. See publication “UIC Public Key distribution using PKMW”
  • QR code Originally invented in 1994 by Denso (A Japanese automotive component manufacturer) for part numbering applications of the different parts in stock. Since February 2015 QR code is described in ISO/IEC 18004:2015
  • RCT-2 Rail Combined Ticket V2: European standard, describing the layout of a SiP based international rail ticket
  • companycode Railway Interchange Coding System - code to identify a (railway) company
  • RU Railway Undertaking
  • Security in Paper - see SiP
  • Security in Data - see SiD
  • Security in System - see SiS
  • SiP Security in Paper. A ticket (representing the contract of carriage) is unique and printed on secured paper to avoid modification or creation by other than a railway company.
  • SiD Security in Data. A ticket contains security elements. These are created/calculated based on the content of the ticket, resulting in a non-compliant security element in case of falsification or modification. SiD tickets are usually easy to regenerate or to copy.
  • SiS Security in System. The contract is on a server. Every operation (creation, check, modification, ...) on the ticket is conducted on the record(s) on the server. Most secured system, but technically complex.
  • Security Background Background, defined by CIT, to be pre-printed on so-called secured paper (used in SiP). This background contains a number of elements making it very difficult to create this paper and impossible to just scan & print a ticket.
  • Security elements Elements allowing the TCO to check that a ticket has been created / modified by a company, allowed to do so. Used in SiD.
  • Seal/Sealing Security element as used in the barcodes in SiD
  • Structured Seal vs. Non-Structured Seal The seal in this leaflet consists of 2 numbers (integers). They can be translated in the barcode as 2 numbers (without metadata) or as a structured message (containing extra info).
  • SSB Small Structured Barcode
  • Symmetric key cryptography cryptography using symmetric keys: both sender and receiver use the same key. This results in smaller security elements, but the sender needs to trust the receiver for 100%, since the decoding key can be used for encoding purposes too.
  • SHA is a family of hash functions published by the National Institute of Standards and Technology (NIST) as a U.S. Federal Information Processing Standard (FIPS).
  • TCN Ticket Control Number
  • TCO Ticket controlling organization, allowed to check tickets before, during or after the trip.
  • TLB Ticket Layout Barcode
  • URT Universal Rail Ticket, a document, written by UIC, defining the actions and the actors involved in ticketing before, during and after the trip.
  • UTF-8 Unicode Transformation Format: variable-length character encoding for Unicode data, see [RFC3629]
  • XML Extensible Markup Language is a markup language that defines a set of rules for encoding documents or data in a format that is both human-readable and machine-readable.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment