In message
, at
01:36:46 on Mon, 14 Jul 2008, remarked:
Looks like LUL have been disabling various Oyster cards. I wonder if a
load have been hacked to give free journeys and LUL were just
disabling any in a specific id range. I can't see any other reason why
they'd require people to get whole new cards since it should be fairly
easy to soft reset the ones they've got. No doubt we'll just get some
spin about "system problems" however and never hear any more about it.

That's a fascinating conspiracy theory, but the only cards that are
supposed to be disabled are ones that were actually used early on
Saturday. Won't news leak out if lots of cards are disabled that weren't
used on Saturday?

Curious how this unique event has occured only a couple of weeks after
some hackers claim to have cracked the system.

As it seems very likely that the problem was a software update gone
wrong, that update might have indeed been about hacked cards - even if
the idea wasn't to disable all the hacked cards [1] by stealth (in
addition to making hacked cards easier to spot).

[1] And a hundred thousand non-hacked ones as collateral damage.
--
Roland Perry

On Jul 14, 10:02 am, Roland Perry wrote:
That's a fascinating conspiracy theory, but the only cards that are
supposed to be disabled are ones that were actually used early on
Saturday.

If the mechanism for permanently disabling a card means they have to
be touched to a gate that would rather follow wouldn't it?

As it seems very likely that the problem was a software update gone
wrong, that update might have indeed been about hacked cards - even if
the idea wasn't to disable all the hacked cards [1] by stealth (in
addition to making hacked cards easier to spot).

Software update to what, the cards or the gates? If the latter how can
that brick a card? If it was the former and they were doing a firmware
update to all the cards then they obviously learnt the hard way that
firmware updates should only be done very carefully, and preferably
not at all unless its really really essential. Given LULs track record
however I wouldn't put it past them to do something that dumb.
Alternatively perhaps the cards have some sort of irreversable kill
switch or flag that was enabled by mistake. Either way , I suspect
we're not going to get the whole story.

B2003

In message
, at
03:03:47 on Mon, 14 Jul 2008, remarked:
On Jul 14, 10:02 am, Roland Perry wrote:
That's a fascinating conspiracy theory, but the only cards that are
supposed to be disabled are ones that were actually used early on
Saturday.

If the mechanism for permanently disabling a card means they have to
be touched to a gate that would rather follow wouldn't it?

So you think the idea was to disable *some* cards, but the system had a
brainstorm and disabled *all* of them?

As it seems very likely that the problem was a software update gone
wrong, that update might have indeed been about hacked cards - even if
the idea wasn't to disable all the hacked cards [1] by stealth (in
addition to making hacked cards easier to spot).

Software update to what, the cards or the gates? If the latter how can
that brick a card?

I don't know if you can update the firmware in the cards. Do they even
have something to update?

If it was the former and they were doing a firmware
update to all the cards then they obviously learnt the hard way that
firmware updates should only be done very carefully, and preferably
not at all unless its really really essential.

That is always the case with any kind of critical update.

Given LULs track record however I wouldn't put it past them to do
something that dumb. Alternatively perhaps the cards have some sort of
irreversable kill switch or flag that was enabled by mistake.

This is more consistent with their inability to "reverse" the process.
It's more scalable to do it that way than to have a blacklist of cards
available at every single Oyster reader.

Either way , I suspect we're not going to get the whole story.

I have a feeling we haven't heard the end of this.

http://www.theregister.co.uk/2008/07...uter_problems/
--
Roland Perry

On Jul 14, 11:22 am, Roland Perry wrote:
If the mechanism for permanently disabling a card means they have to
be touched to a gate that would rather follow wouldn't it?

So you think the idea was to disable *some* cards, but the system had a
brainstorm and disabled *all* of them?

That would be my guess - a simple programming mistake caused some
isThisADodgyCard() test always to return true so it killed them all.

I don't know if you can update the firmware in the cards. Do they even
have something to update?

Some simple cards are hardwired with just a couple of numeric
registers to carry values but Oysters will have onboard software
because they have to store a simple database of places and times
visited plus there's encryption going on. Whether that software is in
ROM or something read-write akin to flash that can be updated I dunno.
Obviously it has some sort of R/W memory to store the DB , balance etc
anyway.

This is more consistent with their inability to "reverse" the process.
It's more scalable to do it that way than to have a blacklist of cards
available at every single Oyster reader.

Yup.

I have a feeling we haven't heard the end of this.

Certainly not from the poor buggers who got stranded with a broken
card either. )

B2003

On 14 Jul, 11:46, wrote:
On Jul 14, 11:22 am, Roland Perry wrote:

If the mechanism for permanently disabling a card means they have to
be touched to a gate that would rather follow wouldn't it?

So you think the idea was to disable *some* cards, but the system had a
brainstorm and disabled *all* of them?

That would be my guess - a simple programming mistake caused some
isThisADodgyCard() test always to return true so it killed them all.

I don't know if you can update the firmware in the cards. Do they even
have something to update?

Some simple cards are hardwired with just a couple of numeric
registers to carry values but Oysters will have onboard software
because they have to store a simple database of places and times
visited plus there's encryption going on. Whether that software is in
ROM or something read-write akin to flash that can be updated I dunno.
Obviously it has some sort of R/W memory to store the DB , balance etc
anyway.

This is more consistent with their inability to "reverse" the process.
It's more scalable to do it that way than to have a blacklist of cards
available at every single Oyster reader.

Yup.

I have a feeling we haven't heard the end of this.

Certainly not from the poor buggers who got stranded with a broken
card either. )


I am not a techy, and I was thinking at first that surely there is
something that can be reset rather than having to replace the card.

But I wonder if it's something like the way that (the surely soon to
be extinct because useless) CDs and DVDs become useless if a write
operation fails. Like some sector that tells the reader where to look
next is corrupt, rather than just a readable setting that says the
card is invalid.

On Mon, 14 Jul 2008, wrote:

On Jul 14, 11:22 am, Roland Perry wrote:
If the mechanism for permanently disabling a card means they have to
be touched to a gate that would rather follow wouldn't it?

So you think the idea was to disable *some* cards, but the system had a
brainstorm and disabled *all* of them?

That would be my guess - a simple programming mistake caused some
isThisADodgyCard() test always to return true so it killed them all.

I don't know if you can update the firmware in the cards. Do they even
have something to update?

Some simple cards are hardwired with just a couple of numeric registers
to carry values but Oysters will have onboard software because they have
to store a simple database of places and times visited plus there's
encryption going on. Whether that software is in ROM or something
read-write akin to flash that can be updated I dunno. Obviously it has
some sort of R/W memory to store the DB , balance etc anyway.

I thought they were basically just memory, with the chip being a memory
controller, and all the authentication and encryption being done in the
gate. Oyster is based on MIFARE Standard:

http://en.wikipedia.org/wiki/MIFARE

That article isn't outrageously detailed or specific, but taking it
together with the generic article on smart cards, i'd say that Oyster is
basically just memory, with a chip for accessing it and doing some
encryption. I would imagine it doesn't have firmware, BICBW.

tom

--
Let us learn to dream, gentlemen, and then perhaps we will learn the
truth. -- Friedrich Kekule

On 14 Jul, 18:42, Tom Anderson wrote:
That article isn't outrageously detailed or specific, but taking it
together with the generic article on smart cards, i'd say that Oyster is
basically just memory, with a chip for accessing it and doing some
encryption. I would imagine it doesn't have firmware, BICBW.

Where do you think the encryption algorithm and the communication
protocol are stored? They're called "smart" because they have a
microprocessor running software that decodes commands and reads,
encrypts and transmits the requested data.

(Although whether this software is rewritable over the air is another
matter)

U

--
http://londonconnections.blogspot.com/
A blog about transport projects in London

On Mon, 14 Jul 2008, Mr Thant wrote:

On 14 Jul, 18:42, Tom Anderson wrote:

That article isn't outrageously detailed or specific, but taking it
together with the generic article on smart cards, i'd say that Oyster is
basically just memory, with a chip for accessing it and doing some
encryption. I would imagine it doesn't have firmware, BICBW.

Where do you think the encryption algorithm and the communication
protocol are stored?

In a ROM. To my mind, it has to be modifiable to be firmware, which makes
code in a ROM not firmware. Although thinking about it, my mind is
probably wrong on this point.

Or it could be done with an ASIC that isn't a microprocessor. It doesn't
need to be any more than a memory controller with an encryption processor
glued on the side.

They're called "smart" because they have a microprocessor running
software that decodes commands and reads, encrypts and transmits the
requested data.

Microprocessor or ASIC?

tom

--
Get my pies out of the oven!

On Mon, 14 Jul 2008 18:42:25 +0100, Tom Anderson
wrote:

That article isn't outrageously detailed or specific, but taking it
together with the generic article on smart cards, i'd say that Oyster is
basically just memory, with a chip for accessing it and doing some
encryption. I would imagine it doesn't have firmware, BICBW.

So, a lot more basic than, say, Chip & PIN, which uses a Java-based (I
think) card that is actually a computer in its own right, thus giving
a far higher level of security than a card with just a PIN number
stored in memory on it. (You can't, for instance, retrieve the PIN
from a C&P card, only ask it if the PIN you give is correct, and you
can only do that 3 times before it locks).

If true, that is genuinely surprising.

Neil

--
Neil Williams
Put my first name before the at to reply.