I was affected by the Oyster problem on Saturday, 12 July.

An error message "30" appeared on the display at the gate,  at Kings
Cross Station. I was told that I could go through the barriers as the
staff member on duty said that the error message referred to the the
system wide error that affected Oyster.

At Clapham Common Station, I was told by a lady there that I *had* to
renew my card there and then, as the card would never work anywhere
else. The transaction took over 30 minutes while a queue of angry
people behind me stood, accusing me of being a difficult customer and
that I must have been training the man behind the counter in how to
deal with problem passengers. At no point did any staff defend me or
explain to the people that I was only following LU staff
instructions.

To add insult to injury, my replacement card now *apparently* offers
fewer benefits than the original. My original card was an Annual Gold
Card issued by South West Trains at Wimbledon Station. I was able to
join their Gold Service and obtain Network Card discounts as well as
additional benefits from South West Trains. Today I was told that I am
no longer a member of their Gold Service, my ticket is NOT valid as a
Network Card, I am no longer entitled to Network Card discounts and
that if I want my original ticket restored, I have to get it replaced
AGAIN, by South West Trains - at a charge! Is this really correct?

More insult, more injury - I discovered that I did not have to have my
card replaced in the first place, and that I could have waited till
today to do it in my own time, rather than standing at Clapham Common
Station at 1115PM!

On 13 Jul, 11:12, Railist  wrote:
> An error message "30" appeared on the display at the gate,  at Kings
> Cross Station. I was told that I could go through the barriers as the
> staff member on duty said that the error message referred to the the
> system wide error that affected Oyster.

...which, at the time, they thought it did.

> At Clapham Common Station, I was told by a lady there that I *had* to
> renew my card there and then, as the card would never work anywhere
> else.

...which, by then, they'd realised was the case. I'm not sure what the
"code 30" issue is, but it does mean that an unspecified number of
unfortunate types like yourself need a new physical Oyster card.

> The transaction took over 30 minutes while a queue of angry
> people behind me stood, accusing me of being a difficult customer and
> that I must have been training the man behind the counter in how to
> deal with problem passengers. At no point did any staff defend me or
> explain to the people that I was only following LU staff
> instructions.

Why didn't /you/ explain to the people that this was what you were
doing, if it bothered you so much?

> To add insult to injury, my replacement card now *apparently* offers
> fewer benefits than the original. My original card was an Annual Gold
> Card issued by South West Trains at Wimbledon Station. I was able to
> join their Gold Service and obtain Network Card discounts as well as
> additional benefits from South West Trains. Today I was told that I am
> no longer a member of their Gold Service, my ticket is NOT valid as a
> Network Card, I am no longer entitled to Network Card discounts and
> that if I want my original ticket restored, I have to get it replaced
> AGAIN, by South West Trains - at a charge! Is this really correct?

You've presumably got the Gold Card Record Card issued by SWT at the
same time as they issued your original Oyster season? If so, then
you're fine - it's the record card that's required to demonstrate Gold
Card eligibility, not the Oyster.

I'm not sure what the legal rather than practical situation is, but
I'd be amazed if it were different - LUL staff aren't really trained
in the mysterious vagaries of National Rail, and don't tend to have a
clue about Gold Cards, Network Cards, etc.

> More insult, more injury - I discovered that I did not have to have my
> card replaced in the first place, and that I could have waited till
> today to do it in my own time, rather than standing at Clapham Common
> Station at 1115PM!

Well, clearly, as long as you can get out of the system - did you ask
the staff at Clapham to let you through last night and they
refused...?

--
John Band
john at johnband dot org
www.johnband.org

On Jul 13, 1:10 pm, John B  wrote:
> On 13 Jul, 11:12, Railist  wrote:
>
> > An error message "30" appeared on the display at the gate,  at Kings
> > Cross Station. I was told that I could go through the barriers as the
> > staff member on duty said that the error message referred to the the
> > system wide error that affected Oyster.
>
> ...which, at the time, they thought it did.
>
> > At Clapham Common Station, I was told by a lady there that I *had* to
> > renew my card there and then, as the card would never work anywhere
> > else.
>
> ...which, by then, they'd realised was the case. I'm not sure what the
> "code 30" issue is, but it does mean that an unspecified number of
> unfortunate types like yourself need a new physical Oyster card.

I very much doubt that this information was clarified between me
touching in at Kings Cross at around 2230hrs, and getting off at
Clapham Common.

> > The transaction took over 30 minutes while a queue of angry
> > people behind me stood, accusing me of being a difficult customer and
> > that I must have been training the man behind the counter in how to
> > deal with problem passengers. At no point did any staff defend me or
> > explain to the people that I was only following LU staff
> > instructions.
> Why didn't /you/ explain to the people that this was what you were
> doing, if it bothered you so much?

Because angry people tend not to listen to the person they perceive is
the source of their anger.

> > To add insult to injury, my replacement card now *apparently* offers
> > fewer benefits than the original. My original card was an Annual Gold
> > Card issued by South West Trains at Wimbledon Station. I was able to
> > join their Gold Service and obtain Network Card discounts as well as
> > additional benefits from South West Trains. Today I was told that I am
> > no longer a member of their Gold Service, my ticket is NOT valid as a
> > Network Card, I am no longer entitled to Network Card discounts and
> > that if I want my original ticket restored, I have to get it replaced
> > AGAIN, by South West Trains - at a charge! Is this really correct?
>
> You've presumably got the Gold Card Record Card issued by SWT at the
> same time as they issued your original Oyster season? If so, then
> you're fine - it's the record card that's required to demonstrate Gold
> Card eligibility, not the Oyster.

No, LUL, despite your claim of being vague about National Rail did say
that they had to keep the original record card, and that the new one
would be fine, despite my doubts.
>
> I'm not sure what the legal rather than practical situation is, but
> I'd be amazed if it were different - LUL staff aren't really trained
> in the mysterious vagaries of National Rail, and don't tend to have a
> clue about Gold Cards, Network Cards, etc.
>
> > More insult, more injury - I discovered that I did not have to have my
> > card replaced in the first place, and that I could have waited till
> > today to do it in my own time, rather than standing at Clapham Common
> > Station at 1115PM!
>
> Well, clearly, as long as you can get out of the system - did you ask
> the staff at Clapham to let you through last night and they
> refused...?

Because I had another bus journey to make, so when she said I couldn't
use the card again, I, for some reason, believed her.
Then on the bus the driver told everyone not to bother swiping in as
Oyster wasn't working.

> --
> John Band
> john at johnband dot orgwww.johnband.org

On Sun, 13 Jul 2008, Railist wrote:

> I was affected by the Oyster problem on Saturday, 12 July.

That sounds completely bloody awful. You've made a complaint, right? If 
they don't fix everything for you, for free, in a timely manner (which i'm 
sure they will), small-claims them.

tom

-- 
THE DRUMMER FROM DEF LEPPARD'S ONLY GOT ONE ARM!

On 13 Jul, 13:19, Railist  wrote:
> > > An error message "30" appeared on the display at the gate,  at Kings
> > > Cross Station. I was told that I could go through the barriers as the
> > > staff member on duty said that the error message referred to the the
> > > system wide error that affected Oyster.
>
> > ...which, at the time, they thought it did.
>
> > > At Clapham Common Station, I was told by a lady there that I *had* to
> > > renew my card there and then, as the card would never work anywhere
> > > else.
>
> > ...which, by then, they'd realised was the case. I'm not sure what the
> > "code 30" issue is, but it does mean that an unspecified number of
> > unfortunate types like yourself need a new physical Oyster card.
>
> I very much doubt that this information was clarified between me
> touching in at Kings Cross at around 2230hrs, and getting off at
> Clapham Common.

True - in which case the person at KX was at fault, there were posters
up at Whitechapel by 1900 saying that anyone whose card came up with a
Code 30 would need a new one.

> > > To add insult to injury, my replacement card now *apparently* offers
> > > fewer benefits than the original. My original card was an Annual Gold
> > > Card issued by South West Trains at Wimbledon Station. I was able to
> > > join their Gold Service and obtain Network Card discounts as well as
> > > additional benefits from South West Trains. Today I was told that I am
> > > no longer a member of their Gold Service, my ticket is NOT valid as a
> > > Network Card, I am no longer entitled to Network Card discounts and
> > > that if I want my original ticket restored, I have to get it replaced
> > > AGAIN, by South West Trains - at a charge! Is this really correct?
>
> > You've presumably got the Gold Card Record Card issued by SWT at the
> > same time as they issued your original Oyster season? If so, then
> > you're fine - it's the record card that's required to demonstrate Gold
> > Card eligibility, not the Oyster.
>
> No, LUL, despite your claim of being vague about National Rail did say
> that they had to keep the original record card, and that the new one
> would be fine, despite my doubts.

Hmm. In that situation I wouldn't have handed the record card over in
a million years. However, the woman was still wrong: LUL-issued annual
Travelcards are also valid as Gold Cards on National Rail. At
absolutely worst, you've lost the SWT-specific benefits.

www.tfl.gov.uk/assets/downloads/Fares-and-ticketing-supplementary-info-07-07.pdf

> > > More insult, more injury - I discovered that I did not have to have my
> > > card replaced in the first place, and that I could have waited till
> > > today to do it in my own time, rather than standing at Clapham Common
> > > Station at 1115PM!
>
> > Well, clearly, as long as you can get out of the system - did you ask
> > the staff at Clapham to let you through last night and they
> > refused...?
>
> Because I had another bus journey to make, so when she said I couldn't
> use the card again, I, for some reason, believed her.
> Then on the bus the driver told everyone not to bother swiping in as
> Oyster wasn't working.

So she was right that you couldn't use the card again.

--
John Band
john at johnband dot org
www.johnband.org

On Jul 13, 1:10 pm, John B  wrote:
> ...which, by then, they'd realised was the case. I'm not sure what the
> "code 30" issue is, but it does mean that an unspecified number of
> unfortunate types like yourself need a new physical Oyster card.

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.
Curious how this unique event has occured only a couple of weeks after
some hackers claim to have cracked the system.

B2003

In message 
, at 
01:36:46 on Mon, 14 Jul 2008, thagor2008@googlemail.com 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, thagor2008@googlemail.com 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/14/oyster_computer_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. :o)

B2003

On Sun, Jul 13, 2008 at 05:10:34AM -0700, John B wrote:

> ...which, by then, they'd realised was the case. I'm not sure what the
> "code 30" issue is, but it does mean that an unspecified number of
> unfortunate types like yourself need a new physical Oyster card.

But the best thing is that those can only be issued at tube stations,
which sucks if you live in Croydon and only use Oyster for local buses.
Such people have to either say bye-bye to whatever credit was left on
their now broken card, or make a special journey, paying the cash
penalty fare, to a tube station (see the fifth paragraph here:
http://www.tfl.gov.uk/tfl/news/oyster.aspx).

More proof, not that we needed it, that Oyster was never thought out
properly and that people living in south London don't matter to TfL's
management.  A well-designed system fails gracefully.  Oyster doesn't.

> I'm not sure what the legal rather than practical situation is, but
> I'd be amazed if it were different - LUL staff aren't really trained
> in the mysterious vagaries of National Rail, and don't tend to have a
> clue about Gold Cards, Network Cards, etc.

Perhaps they should be, if they're going to try to do stuff with
National Rail tickets.  And vice versa, of course.

-- 
David Cantrell | Enforcer, South London Linguistic Massive

Perl: the only language that makes Welsh look acceptable

On 14 Jul, 11:46, thagor2...@googlemail.com 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. :o)


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, thagor2008@googlemail.com 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 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.

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 14 Jul, 23:14, Tom Anderson  wrote:
> > 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?

To be pedantic, the MIFARE chip is undeniably an ASIC, because that
simply means the chip it's custom designed. I think what you're asking
is whether the protocol and encryption algorithms are implemented in
hardware (using state machine principals) or MPU+software. It looks
like encryption and some of the communication protocol is indeed
implemented using state machines, but I'm not certain about the higher
level functionality, though I'm leaning towards state machine also.
Some of the later models are definitely microprocessor-based, though.

(although being really pedantic, a microprocessor is just a fancy
state machine)

U

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

In message , at 
23:14:56 on Mon, 14 Jul 2008, Tom Anderson  
remarked:
>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.

Lots of people these days take the precaution of making firmware 
upgradeable, but that's not part of the definition - which is 
non-volatile software providing the lower levels of API (not the user 
interface) to a dedicated bit of hardware.
-- 
Roland Perry

On Jul 14, 11:14 pm, Tom Anderson  wrote:
> 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.

Firmware is any built in software that controls the low level
functionality of a piece of hardware. Doesn't matter how its stored.

> 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.

So what do you think will be running the encryption processor? I don't
know what a circuit hardwired to do something like 3DES or Blowfish or
whatever encryption Oyster uses would look like, but I suspect it
would be a nightmare to design and debug if it were even possible.

> > 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?

Most ASICs these days have embedded CPUs.

B2003

In article ,
	thagor2008@googlemail.com  wrote:
> So what do you think will be running the encryption processor? I don't
> know what a circuit hardwired to do something like 3DES or Blowfish or
> whatever encryption Oyster uses would look like, but I suspect it
> would be a nightmare to design and debug if it were even possible.

Hardware crypto accelerators have been around for ages and ages and
ages.  I remember in the late '90s seeing one that hooked up to the
SCSI bus - it was aimed at the web server market.

These days there are off-the-shelf x86 compatible CPUs that can do
it (at least for AES, anyway).

I don't know if they'd count as 'hardwared' mind you - I would
expect them to consist of odd specialized hardware coupled with a
general purpose CPU and to split the workload between them.

-- 
Shenanigans!  Shenanigans!    Best of 3!
	-- Flash

On Tue, 15 Jul 2008, thagor2008@googlemail.com wrote:

> On Jul 14, 11:14 pm, Tom Anderson  wrote:
>
>> 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.
>
> So what do you think will be running the encryption processor? I don't 
> know what a circuit hardwired to do something like 3DES or Blowfish or 
> whatever encryption Oyster uses would look like, but I suspect it would 
> be a nightmare to design and debug if it were even possible.

But design and debug them they have. Indeed, one of the criteria in the 
AES competition was ease of hardware implementation. Here are 78 such 
beasts:

http://www.hardware-ciphers.com/en/aes/

tom

-- 
As Emiliano Zapata supposedly said, "Better to die on your feet than
live on your knees." And years after he died, Marlon Brando played him
in a movie. So just think, if you unionize, Marlon Brando might play
YOU in a movie. Even though he's dead. -- ChrisV82

On Jul 15, 4:20 pm, Tom Anderson  wrote:
> But design and debug them they have. Indeed, one of the criteria in the
> AES competition was ease of hardware implementation. Here are 78 such
> beasts:
>
> http://www.hardware-ciphers.com/en/aes/

I won't even pretend I understand much of that , but looks like some
very smart people have been
very busy. I suppose in theory its possible to hardwire any algorithm
but I guess the question is
why would you bother if you could use an off the shelf microcontroller
and some software in ROM.
I still think Oyster probably has software in it but since the
smartcard manufacturer arn't likely to
tell I guess we'll never know! :)

B2003

thagor2008@googlemail.com wrote:
> On Jul 15, 4:20 pm, Tom Anderson  wrote:
>> But design and debug them they have. Indeed, one of the criteria in the
>> AES competition was ease of hardware implementation. Here are 78 such
>> beasts:
>>
>> http://www.hardware-ciphers.com/en/aes/
> 
> I won't even pretend I understand much of that , but looks like some
> very smart people have been
> very busy. I suppose in theory its possible to hardwire any algorithm
> but I guess the question is
> why would you bother if you could use an off the shelf microcontroller
> and some software in ROM.
> I still think Oyster probably has software in it but since the
> smartcard manufacturer arn't likely to
> tell I guess we'll never know! :)
> 
> B2003

Wasn't the problem with MiFare (and thus Oyster) being cracked that 
rather than use a standard commercial encryption they used a weak 
algorithm they invented and then failed to realise that you could 
reverse-engineer it from microscopically examining the chip on the card?

Tom

On Tue, 15 Jul 2008, thagor2008@googlemail.com wrote:

> On Jul 15, 4:20 pm, Tom Anderson  wrote:
>
>> But design and debug them they have. Indeed, one of the criteria in the 
>> AES competition was ease of hardware implementation. Here are 78 such 
>> beasts:
>>
>> http://www.hardware-ciphers.com/en/aes/
>
> I won't even pretend I understand much of that , but looks like some 
> very smart people have been very busy. I suppose in theory its possible 
> to hardwire any algorithm but I guess the question is why would you 
> bother if you could use an off the shelf microcontroller and some 
> software in ROM.

Well, firstly, if someone's already designed a circuit for doing it, why 
not license that rather than the microcontroller? I suspect it'll do a lot 
better in terms of bytes per second/square micron/watt/whatever.

Secondly, if you look at the structure of most modern ciphers, you'll find 
something that's actually highly amenable to hardware implementation. 
There aren't a lot of branches or manipulation of memory or whatever else 
microprocessors are good at, just lots and lots of moving small numbers of 
bits from one place to another in a fixed way, combining bits with fixed 
operations, and lookup tables. For instance (he said, cribbing furiously 
from wikipeda), AES has a state consisting of a four-by-four matrix of 
bytes, and does four steps in each round:

SubBytes - take each byte, use it as an index into a lookup table, and 
replace it with the result

ShiftRows - move the bytes in each row left a certain number of places 
(wrapping round)

MixColumns - take the columns as degree-3 polynomials over the field 
GF(2^8), and multiply by a special constant polynomial

AddRoundKey - xor each byte with the corresponding byte of the round key

That sort of thing is ideal for custom hardware - not too complicated, not 
at all branchy, highly parallelisable. The polynomial bit sounds 
complicated, but it turns out that doing maths with polynomials over 
GF(2^8) all boils down to shifts and xors, and is really easy and fast 
(much easier to implement than to explain!).

> I still think Oyster probably has software in it but since the smartcard 
> manufacturer arn't likely to tell I guess we'll never know! :)

A floor down and about a hundred yards across from where i sit are some of 
the most powerful electron microscopes in London [1]. An Oster card, a 
scalpel, and a pint to the right person, and we have our answer ...

tom

[1] Okay, probably an exaggeration.

-- 
As Emiliano Zapata supposedly said, "Better to die on your feet than
live on your knees." And years after he died, Marlon Brando played him
in a movie. So just think, if you unionize, Marlon Brando might play
YOU in a movie. Even though he's dead. -- ChrisV82

On Jul 15, 5:19 pm, Tom Anderson  wrote:
> Secondly, if you look at the structure of most modern ciphers, you'll find
> something that's actually highly amenable to hardware implementation.

I suppose really the question is , what is hardwired or hardware
implemented or rather , where does software end and hardware start?
For example x86 processors can do trig as well as multiply and divide
etc. But intel use microcode to carry out the operations internally.
Does microcode count as hardware or software? Beats me. Answers on a
postcard...

B2003

In message 
, at 
01:31:16 on Wed, 16 Jul 2008, thagor2008@googlemail.com remarked:
>where does software end and hardware start?

There are grey areas, as well as black and white.

>For example x86 processors can do trig as well as multiply and divide
>etc. But intel use microcode to carry out the operations internally.
>Does microcode count as hardware or software?

Microcode is Software, but it probably also counts as Firmware (which is 
simply that subset of built-in software performing certain low-level 
functions). The engine that the microcode is driving is Hardware.
-- 
Roland Perry

On Jul 16, 11:30 am, Roland Perry  wrote:
> In message
> , at
> 01:31:16 on Wed, 16 Jul 2008, thagor2...@googlemail.com remarked:
>
> >where does software end and hardware start?
>
> There are grey areas, as well as black and white.

True.

>
> >For example x86 processors can do trig as well as multiply and divide
> >etc. But intel use microcode to carry out the operations internally.
> >Does microcode count as hardware or software?
>
> Microcode is Software, but it probably also counts as Firmware (which is
> simply that subset of built-in software performing certain low-level
> functions). The engine that the microcode is driving is Hardware.

From wikipedia:

"A control store is the part of a CPU's control unit that stores the
CPU's microprogram"

"A control store is usually implemented as a diode-array of read-only
memory"

So I guess at that level you could put forward a valid argument for it
being hard wired diodes, or software in the sense of the way the
diodes are wired. Or both! But then again I suppose you could say the
same about any read only ROM.

B2003

In message 
, at 
05:47:38 on Wed, 16 Jul 2008, thagor2008@googlemail.com remarked:

>From wikipedia:
>
>"A control store is the part of a CPU's control unit that stores the
>CPU's microprogram"
>
>"A control store is usually implemented as a diode-array of read-only
>memory"

I'm a fan of Wikipedia, but that stuff is just gibberish.

>So I guess at that level you could put forward a valid argument for it
>being hard wired diodes, or software in the sense of the way the
>diodes are wired. Or both! But then again I suppose you could say the
>same about any read only ROM.

There any many technologies that can be used to implement a ROM, 
including the presence and absence of diodes in a matrix, and even the 
ability to erase or restore such diodes in the field. This is 
ludicrously technology-specific, however, and who is to say what a 
generic CPU uses to store its microcode. (If you had asked me yesterday, 
I might have said "the presence of absence of conductors between logic 
gates").
-- 
Roland Perry

"Roland Perry"  wrote in message 
news:hxPpp8yK3cfIFA15@perry.co.uk...
> In message 
> , at 
> 01:31:16 on Wed, 16 Jul 2008, thagor2008@googlemail.com remarked:
>>where does software end and hardware start?
>
> There are grey areas, as well as black and white.
>
>>For example x86 processors can do trig as well as multiply and divide
>>etc. But intel use microcode to carry out the operations internally.
>>Does microcode count as hardware or software?
>
> Microcode is Software, but it probably also counts as Firmware (which is 
> simply that subset of built-in software performing certain low-level 
> functions).

I would suggest that it is that subset of software that is hardcoded, one 
time only, into a device to perform a specific function (low level or 
otherwise).

It used to be the case that any software inside an 'embedded' system was 
firmware, but the trend to provide for software updates has muddied that 
boundary.

>The engine that the microcode is driving is Hardware.

The engine that any software drives is hardware :-)

tim

On Jul 16, 4:22 pm, Roland Perry  wrote:
> In message
> , at
> 05:47:38 on Wed, 16 Jul 2008, thagor2...@googlemail.com remarked:
>
> >From wikipedia:
>
> >"A control store is the part of a CPU's control unit that stores the
> >CPU's microprogram"
>
> >"A control store is usually implemented as a diode-array of read-only
> >memory"
>
> I'm a fan of Wikipedia, but that stuff is just gibberish.
>
> >So I guess at that level you could put forward a valid argument for it
> >being hard wired diodes, or software in the sense of the way the
> >diodes are wired. Or both! But then again I suppose you could say the
> >same about any read only ROM.
>
> There any many technologies that can be used to implement a ROM,
> including the presence and absence of diodes in a matrix, and even the
> ability to erase or restore such diodes in the field. This is
> ludicrously technology-specific, however, and who is to say what a
> generic CPU uses to store its microcode. (If you had asked me yesterday,
> I might have said "the presence of absence of conductors between logic
> gates").

This all might as well be a foreign language to me, but ... does one
or other hypothesis explain why a card can be permanently disabled by
being touched on a pad rather than being able to be reset?

In message , at 18:24:55 on Wed, 16 
Jul 2008, tim.....  remarked:
>> Microcode is Software, but it probably also counts as Firmware (which is
>> simply that subset of built-in software performing certain low-level
>> functions).
>
>I would suggest that it is that subset of software that is hardcoded, one
>time only, into a device to perform a specific function (low level or
>otherwise).

Lots of firmware is upgradeable, and specific-function software like 
Windows, when supplied in ROM for a low-cost laptop, isn't Firmware.
-- 
Roland Perry

"MIG"  wrote in message 
news:03c6d963-a166-4c57-b1ab-2780cdf3c743@z72g2000hsb.googlegroups.com...
On Jul 16, 4:22 pm, Roland Perry  wrote:
> In message
> , at
> 05:47:38 on Wed, 16 Jul 2008, thagor2...@googlemail.com remarked:
>
> >From wikipedia:
>
> >"A control store is the part of a CPU's control unit that stores the
> >CPU's microprogram"
>
> >"A control store is usually implemented as a diode-array of read-only
> >memory"
>
> I'm a fan of Wikipedia, but that stuff is just gibberish.
>
> >So I guess at that level you could put forward a valid argument for it
> >being hard wired diodes, or software in the sense of the way the
> >diodes are wired. Or both! But then again I suppose you could say the
> >same about any read only ROM.
>
> There any many technologies that can be used to implement a ROM,
> including the presence and absence of diodes in a matrix, and even the
> ability to erase or restore such diodes in the field. This is
> ludicrously technology-specific, however, and who is to say what a
> generic CPU uses to store its microcode. (If you had asked me yesterday,
> I might have said "the presence of absence of conductors between logic
> gates").

This all might as well be a foreign language to me, but ... does one
or other hypothesis explain why a card can be permanently disabled by
being touched on a pad rather than being able to be reset?

-------------------------------------------------------------------------

Nope.  There is no reason why touching your card on an incompatible pad 
would render the card unusable, unless the software was written to do this 
(by accident or design) in the same way as say entering your bank (or mobile 
phone) PIN in incorrectly.

Issuing such cards with no way to reset them by software would be remiss of 
the designers.

My guess is that the reset requires the card to be attached to special 
hardware and they decided that collecting all the cards and doing this 
centrally was easer than doing it at every Underground station.

tim

In message 
, at 
10:56:22 on Wed, 16 Jul 2008, MIG  
remarked:
>This all might as well be a foreign language to me, but ... does one
>or other hypothesis explain why a card can be permanently disabled by
>being touched on a pad rather than being able to be reset?

That's a different question, which has been explored over the last few 
days. I'm of the view that I wouldn't be surprised if the Oyster Card 
had a "suicide" feature that meant that once disabled it could not be 
re-enabled. That's because with tens of millions of the things in 
circulation you can't easily keep a list of all the disabled ones in 
every reader, in order to refuse it "on the fly" every time it's 
presented in the future.
-- 
Roland Perry

On Jul 16, 9:18 pm, Roland Perry  wrote:
> That's a different question, which has been explored over the last few
> days. I'm of the view that I wouldn't be surprised if the Oyster Card
> had a "suicide" feature that meant that once disabled it could not be
> re-enabled. That's because with tens of millions of the things in
> circulation you can't easily keep a list of all the disabled ones in
> every reader, in order to refuse it "on the fly" every time it's
> presented in the future.

Indeed. As soon as you've disabled one you delete it from the list and
don't have to worry about it again. Of course what they're forgetting
is anyone smart enough to hack a smartcard will have probably sussed
any suicide features and disabled them (unless its something built
into the hardware and has no software control) so I'm not sure just
how much use it'll be.

B2003

"tim....."  wrote in message 
news:6e6riqF5kidoU1@mid.individual.net...
> Nope.  There is no reason why touching your card on an incompatible pad 
> would render the card unusable, unless the software was written to do this 
> (by accident or design) in the same way as say entering your bank (or 
> mobile phone) PIN in incorrectly.

You can mungle the data on a card though. Corrupt the cypher or something 
like that. Break one of the application areas although there is no reason 
you cant fix it with a programmer.

> Issuing such cards with no way to reset them by software would be remiss 
> of the designers.

I have never disabled a *card* of this type - its normally remove the CSN 
from the system and the card is then usless - you can't re-use the card for 
something else unless you know the cypher to access the application areas to 
re-write the data.

Some smart cards are 'fused' but I've only ever seen something like this on 
active cards (Those with the battery inside them) Iclass and MIFARE cards 
are fused but the fuses only relate to the changing of the cyphers not 
killing the card.

> My guess is that the reset requires the card to be attached to special 
> hardware and they decided that collecting all the cards and doing this 
> centrally was easer than doing it at every Underground station.

You would normally need a proper programmer (like we have for ACS) where you 
can change the keys and application area content, the normal read/writers 
won't fix the card you need a proper programmer terminal.

Have a look at http://www.quantasoft.com/Documents/HID/0028_an_en.pdf - This 
should give you an idea. Its the memory map for the HID Iclass cards. - 
There is no application note on the HIDCorp site for the MIFARE