Magnetic stripe encoding

[alphaomega]

I'm doing some research into magnetic stripe encoding as part of my uni degree and haven't been able to find a great deal of information about the encoding of data on the magnetic stripes of train tickets. The most I've found is from a reply by barrykas here, and quoted below:

The magstripe on a standard ticket holds a massive...192 bits of data, broken down as follows:
Header : 16 bits
Rail Settlement Plan Data : 72 bits
London Underground Data : 80 bits
Checksum : 8 bits
Trailer : 16 bits

The full spec can be found on the password protected bit of the ATOC website.

Cheers,

Barry

Does anyone have further information? Or perhaps a link to the full spec or how to access it? I've signed up to the data feed and DTD portal on the ATOC site however am unable to find the reference document that Barry mentions.

Any help would be much appreciated.

 

[450.emu]

I'm doing some research into magnetic stripe encoding as part of my uni degree and haven't been able to find a great deal of information about the encoding of data on the magnetic stripes of train tickets. The most I've found is from a reply by barrykas here, and quoted below:



Does anyone have further information? Or perhaps a link to the full spec or how to access it? I've signed up to the data feed and DTD portal on the ATOC site however am unable to find the reference document that Barry mentions.

Any help would be much appreciated.

I imagine TOCs would keep that information fairly close to their chests in case any Tom, Dick or Harry gets hold of an old Swecoin ticket printer and starts making railcards and tickets for himself :roll:

 

[alphaomega]

I imagine TOCs would keep that information fairly close to their chests in case any Tom, Dick or Harry gets hold of an old Swecoin ticket printer and starts making railcards and tickets for himself :roll:

I imagine so though the quoted post does seem to suggest that a specification does exist that is available somewhere.

 

[bb21]

I imagine so though the quoted post does seem to suggest that a specification does exist that is available somewhere.

... but probably not in the public domain.

If you wish to use it for research purposes, why not get in touch with ATOC? If such information is meant to be disclosed to the general public then I am sure they will only be more than happy to help, or point you in the right direction.

 

[alphaomega]

... but probably not in the public domain.

If you wish to use it for research purposes, why not get in touch with ATOC? If such information is meant to be disclosed to the general public then I am sure they will only be more than happy to help, or point you in the right direction.

I suspect I shall have to do so, I just wanted to see if there was anything more either in way of information or advice as common knowledge first.

 

[route:oxford]

I'm doing some research into magnetic stripe encoding as part of my uni degree and haven't been able to find a great deal of information about the encoding of data on the magnetic stripes of train tickets.

I've got to ask why are you wasting time with it? Magstrip is a dead technology that only persists because it is cheap.

Header : 16 bits
Rail Settlement Plan Data : 72 bits
London Underground Data : 80 bits
Checksum : 8 bits
Trailer : 16 bits

Just looking at with a 1970s "hat on" what you have there it's all quite obvious what is what.

The Header & Trailer allows the equipment to identify which direction the card was swiped and thus decode the data in the correct order.

Rail Settlement Plan Data isn't encrypted, so simply capturing the data from a few tickets and comparing it to the front of the ticket will be helpful.

Logically it must at least have:-

Departure station
Arrival station
Start Date
Ticket type

And with 72 bits available, it's got 7 characters available, so the format probably going to be:-

DDAASST

Sticking with 95 "printable charcters" in the ASCII codeset (always best to avoid bell and linebrakecodes etc - even on electronic coding), it allows:-

9025 Destination Stations
9025 Arrival Stations
9025 Start Dates - I'd guess that they cycle every 10 years so only use 3650(ish)
95 Ticket types

A checksum is what it says it is. Usually X/Y should leave a remainder of z.

Of course, that's just pure guesswork - but there's only so much you can do with 7 characters.

 

[alphaomega]

I've got to ask why are you wasting time with it? Magstrip is a dead technology that only persists because it is cheap.

Definitely. It's security related research.

Just looking at with a 1970s "hat on" what you have there it's all quite obvious what is what.

The Header & Trailer allows the equipment to identify which direction the card was swiped and thus decode the data in the correct order.

Rail Settlement Plan Data isn't encrypted, so simply capturing the data from a few tickets and comparing it to the front of the ticket will be helpful.

Logically it must at least have:-

Departure station
Arrival station
Start Date
Ticket type

And with 72 bits available, it's got 7 characters available, so the format probably going to be:-

DDAASST

Sticking with 95 "printable charcters" in the ASCII codeset (always best to avoid bell and linebrakecodes etc - even on electronic coding), it allows:-

9025 Destination Stations
9025 Arrival Stations
9025 Start Dates - I'd guess that they cycle every 10 years so only use 3650(ish)
95 Ticket types

A checksum is what it says it is. Usually X/Y should leave a remainder of z.

Of course, that's just pure guesswork - but there's only so much you can do with 7 characters.

I have read data from a number of tickets, unfortunately it's not ASCII encoded nor in a standard ISO format for magstripes. From what I've seen so far I've been able to isolate some fields, mainly related to the tickets last use which is written to the ticket by the gate.

 

[route:oxford]

Definitely. It's security related research.



I have read data from a number of tickets, unfortunately it's not ASCII encoded nor in a standard ISO format for magstripes. From what I've seen so far I've been able to isolate some fields, mainly related to the tickets last use which is written to the ticket by the gate.

It doesn't really have to be ISO when it was a proprietory format designed in the 70s for economy..

The data is divisible by 8 for a reason, so logic indicates that there has to be 7 characters of some kind in there. From the extracts of RSPS3000 that I can pick up, two ASCII characters are used for the ticket type - the first two of the ticket type, which can cause rejection errors when the third "missing" character is important.

On the return portion of a ticket the arrival and destination are swapped around - so that may help your reading of the data.

 

[Paul Kelly]

Magnetic stripe encoding and security are completely incompatible so I'm curious about what the research is trying to prove! I seem to remember reading somewhere that IBM purposely encouraged the adoption of basic and insecure magnetic stripe encoding for early credit cards as they saw it as an opportunity to sell more computers to analyse transaction data and detect the obvious fraud that was going to happen. Not sure if that's true.

 

[alphaomega]

It doesn't really have to be ISO when it was a proprietory format designed in the 70s for economy..

The data is divisible by 8 for a reason, so logic indicates that there has to be 7 characters of some kind in there. From the extracts of RSPS3000 that I can pick up, two ASCII characters are used for the ticket type - the first two of the ticket type, which can cause rejection errors when the third "missing" character is important.

On the return portion of a ticket the arrival and destination are swapped around - so that may help your reading of the data.

Interesting, perhaps I shall look further into some of the data being ASCII. You mention RSPS3000, do you have a copy of it?

Why is it that you think it's 7 characters though? 72 is indeed divisible by 8 but that would suggest 9 characters rather than 7.

Magnetic stripe encoding and security are completely incompatible so I'm curious about what the research is trying to prove! I seem to remember reading somewhere that IBM purposely encouraged the adoption of basic and insecure magnetic stripe encoding for early credit cards as they saw it as an opportunity to sell more computers to analyse transaction data and detect the obvious fraud that was going to happen. Not sure if that's true.

Not 'prove', so to speak, but more to look into areas where the completely insecure form of data encoding is still being used today. Credit cards being the most common example although the use of magstripes for purchasing is much rarer in the UK now and compared to the US.

 

[Paul Kelly]

Not 'prove', so to speak, but more to look into areas where the completely insecure form of data encoding is still being used today. Credit cards being the most common example although the use of magstripes for purchasing is much rarer in the UK now and compared to the US.

Fair enough. Rail tickets are indeed a very good example of this and it's interesting the emphasis that is put on installation of automatic ticket gates by DfT and other parties as a measure to prevent ticketless travel, given how completely insecure and easy to fool the magnetic stripe format is.

 

[jopsuk]

as pointed out, 72/8 = 9, so that would allow stations to be the 3-letter codes

 

[yorksrob]

I've got to ask why are you wasting time with it? Magstrip is a dead technology that only persists because it is cheap.

And because they've not come up with anything that's better.

 

[route:oxford]

Interesting, perhaps I shall look further into some of the data being ASCII. You mention RSPS3000, do you have a copy of it?

Why is it that you think it's 7 characters though? 72 is indeed divisible by 8 but that would suggest 9 characters rather than 7.

You are absolutely right. I double-deducted the checksum.

 

[Mojo]

I imagine TOCs would keep that information fairly close to their chests in case any Tom, Dick or Harry gets hold of an old Swecoin ticket printer and starts making railcards and tickets for himself :roll:

There are plenty of people with counterfeit 7 day Travelcards printed on NR stock. The numbers have died down a bit as the BTP cracked a couple of Eastern European gangs in the last few years, but there's still plenty about.

Most of the ones I've seen (and I came across a fair few about three years ago) involve someone buying a real ticket and then making a load of clones.

 

[alphaomega]

And because they've not come up with anything that's better.

I've heard the self-print tickets use a AZTEC barcode on which the data is encrypted using a public / private key system. That seems more secure.

 

[Mojo]

I've heard the self-print tickets use a AZTEC barcode on which the data is encrypted using a public / private key system. That seems more secure.

Of the few ticket gates that are fitted with code scanners, you get significantly fewer customers through the gates per minute, and having watched people attempting to use them, the success rate seems less than 75%.

 

[alphaomega]

Of the few ticket gates that are fitted with code scanners, you get significantly fewer customers through the gates per minute, and having watched people attempting to use them, the success rate seems less than 75%.

I agree, I've definitely seen and experienced similar. It is interesting that ATOC will be introducing CCST with barcodes on and no magstripes though. I wonder if they will be used in conjunction with new scanners functioning more like the current CCST gates.