Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > NZ Computing > Another way that Meridian generates electricity

Reply
Thread Tools

Another way that Meridian generates electricity

 
 
jasen
Guest
Posts: n/a
 
      11-20-2006
Powermanager is a pre-paid electricity setup run by meridian energy in
Christchurh, it uses a smartcard (with gold contacts etc) to tranfer billing
information between the ATM like payment kiosk and the power manager terminal

the cards aren;t lasting like they should, (my first card failed after
about 6 uses, even the cheapest flash is good for 1000 writes)

I was playing with the defective card and noticed a "clicking sound" as
it passed between my fingertips, so I go out into the hallway where
it's dark and the clicking turns out to be a visible electrostatic discharge,

no wonder the things don't last if they build a static charge that easily.

Bye.
Jasen
 
Reply With Quote
 
 
 
 
peterwn
Guest
Posts: n/a
 
      11-20-2006

jasen wrote:
> Powermanager is a pre-paid electricity setup run by meridian energy in
> Christchurh, it uses a smartcard (with gold contacts etc) to tranfer billing
> information between the ATM like payment kiosk and the power manager terminal
>

Actually, these may be obsolete soon.

Meridian seems to have succeeded in the 'holy grail' of metering
technology, that is a remote reading / tariff change / control device
for installation in households. Various groups have been working on
this sort of thing for the last 10 - 15 years, and while there have
been some limited successes, this seems to be the first successful
comprehensive type system.

Meridian IMO has the smartest brains in the business (especially the
CEO), so much so, they outsmarted others during a previous shortage
(and in the process ensured there was output when they needed it for
their customers) and seems to have scored a coup with this one.

Instead of a special meter into which you have to feed a card, the
office computer will simply keep an eye on consumption, warn you by
phone etc when you are running low and finally send out a 'disconnect'
signal when you run out of credit.

 
Reply With Quote
 
 
 
 
Don Hills
Guest
Posts: n/a
 
      11-20-2006
In article <(E-Mail Removed). com>,
"peterwn" <(E-Mail Removed)> wrote:
|
|Instead of a special meter into which you have to feed a card, the
|office computer will simply keep an eye on consumption, warn you by
|phone etc when you are running low and finally send out a 'disconnect'
|signal when you run out of credit.

Yummy. Fresh meat for hacking.

--
Don Hills (dmhills at attglobaldotnet) Wellington, New Zealand
"New interface closely resembles Presentation Manager,
preparing you for the wonders of OS/2!"
-- Advertisement on the box for Microsoft Windows 2.11 for 286
 
Reply With Quote
 
peterwn
Guest
Posts: n/a
 
      11-21-2006

Don Hills wrote:
> In article <(E-Mail Removed). com>,
> "peterwn" <(E-Mail Removed)> wrote:
> |
> |Instead of a special meter into which you have to feed a card, the
> |office computer will simply keep an eye on consumption, warn you by
> |phone etc when you are running low and finally send out a 'disconnect'
> |signal when you run out of credit.
>
> Yummy. Fresh meat for hacking.
>

Actually, that thought did cross my mind. It is pretty obvious that
the signals would be well encrypted with a separate key for each unit,
perhaps with a remotely changable rolling 'masterkey' for bulk
transmission of emergency signals (eg to shut off power if a pylon
falls down) or tariff broadcast signals. Now doubt excessive
signalling to units would be detected by the units and reported to
'mothership'. The easiest hacking method would be cutting the seal and
interfering with the innards, but again that could send a tamper
message. The biggest risk would be the hacking of the central computer
holding the encryption keys.

It seems the prepayment systems using swipe cards, smart cards or
entering 20 digit strings have not been hacked in practice. One
hacking I heard of was where a use once magstrip card ws 'hacked' by
cutting the card down the middle and using the two halves on different
occaions.

 
Reply With Quote
 
Don Hills
Guest
Posts: n/a
 
      11-21-2006
In article <(E-Mail Removed) .com>,
"peterwn" <(E-Mail Removed)> wrote:
>>

>Actually, that thought did cross my mind. It is pretty obvious that
>the signals would be well encrypted with a separate key for each unit,
>perhaps with a remotely changable rolling 'masterkey' for bulk
>transmission of emergency signals (eg to shut off power if a pylon
>falls down) or tariff broadcast signals. Now doubt excessive
>signalling to units would be detected by the units and reported to
>'mothership'. ...


Do you really think they have gone to that amount of trouble in their
implementation? I doubt it, but I'd be happy to be proved wrong.

>It seems the prepayment systems using swipe cards, smart cards or
>entering 20 digit strings have not been hacked in practice.


There's no incentive. The amount you actually use is recorded on the meter,
and sooner or later it will be reconciled against the amount you have paid
for.

Actually, I wasn't thinking of "electricity theft" when I made my earlier
comment. I was thinking more of the potential for maliciously cutting off
service, for example. A DOS attack...

--
Don Hills (dmhills at attglobaldotnet) Wellington, New Zealand
"New interface closely resembles Presentation Manager,
preparing you for the wonders of OS/2!"
-- Advertisement on the box for Microsoft Windows 2.11 for 286
 
Reply With Quote
 
peterwn
Guest
Posts: n/a
 
      11-22-2006

Don Hills wrote:
> In article <(E-Mail Removed) .com>,
> "peterwn" <(E-Mail Removed)> wrote:
> >>

> >Actually, that thought did cross my mind. It is pretty obvious that
> >the signals would be well encrypted with a separate key for each unit,
> >perhaps with a remotely changable rolling 'masterkey' for bulk
> >transmission of emergency signals (eg to shut off power if a pylon
>>falls down) or tariff broadcast signals. Now doubt excessive
> >signalling to units would be detected by the units and reported to
> >'mothership'. ...

>
> Do you really think they have gone to that amount of trouble in their
> implementation? I doubt it, but I'd be happy to be proved wrong.


Yes, because it is pretty bleeding obvious that if someone successfully
hacks these units they can cause total and utter mayhem. It does not
take a rocket scientist to realise that, and Dr Keith Turner
(Meridian's CEO) would have been among the top rocket scientists if he
had chosen that career path. I am sure he would be most concerned that
the signalling is highly secure.

>
> >It seems the prepayment systems using swipe cards, smart cards or
> >entering 20 digit strings have not been hacked in practice.

>
> There's no incentive. The amount you actually use is recorded on the meter,
> and sooner or later it will be reconciled against the amount you have paid
> for.


It is too late when the hacker has moved out, and in any case these
meters might only be read regularly and only then if easily accessible.

>
> Actually, I wasn't thinking of "electricity theft" when I made my earlier
> comment. I was thinking more of the potential for maliciously cutting off
> service, for example. A DOS attack...


I was thinking just that. If you could easily knock off someone's
supply, this would destroy the credibility of the whole system and that
would be the last thing Meridian wants. There are likely to be two
signal codes to cause a cutoff - an individual code and a master code.
If I were designing the units, the master codes would use a rolling
algorithm which could be re-seeded via an individual code ie the one
for individual meter reading and control. I would also have a back-up
code unique to each unit, merely to re-seed the other codes in an
emergency if need be - as it would be infrequently used, breaking it by
'sniffing' traffic would not be possible. I would use 'public' and
'private' type keys to prevent reverse engineering of the codes if
someone opens up a unit. This may sound complicated but is well within
modern microcontroller technology. I would also have a case alarm in
addition to a multi strand wire crimp seal.

I have not had anything to do with this project, so I am merely taking
intelligent guesses at how it would be designed - in an earlier
incarnation I looked after 100,000 or so meters for a few years. I
also noted the USA groups who broke Japanese codes during WW2. They
had non-standard code wheels for use in their machines reserved purely
for messages related with code breaking. As there was relatively
little traffic using that cypher and as it did not 'line up' with major
events, communiques etc, there was inadequate material for a successful
hacking attempt.

 
Reply With Quote
 
Don Hills
Guest
Posts: n/a
 
      11-22-2006
In article <(E-Mail Removed) .com>,
"peterwn" <(E-Mail Removed)> wrote:
>
>Yes, because it is pretty bleeding obvious that if someone successfully
>hacks these units they can cause total and utter mayhem. It does not
>take a rocket scientist to realise that, and Dr Keith Turner
>(Meridian's CEO) would have been among the top rocket scientists if he
>had chosen that career path. I am sure he would be most concerned that
>the signalling is highly secure.


I guess we better find out, instead of guessing.

>It is too late when the hacker has moved out, and in any case these
>meters might only be read regularly and only then if easily accessible.


Same answer. I'll ask Shaun.

>I have not had anything to do with this project, so I am merely taking
>intelligent guesses at how it would be designed - in an earlier
>incarnation I looked after 100,000 or so meters for a few years.


I'll bet the security is no better than it's worth, in other words a given
level of security shouldn't cost more to implement than the likely losses
from not having it.

--
Don Hills (dmhills at attglobaldotnet) Wellington, New Zealand
"New interface closely resembles Presentation Manager,
preparing you for the wonders of OS/2!"
-- Advertisement on the box for Microsoft Windows 2.11 for 286
 
Reply With Quote
 
peterwn
Guest
Posts: n/a
 
      11-22-2006

Don Hills wrote:
> In article <(E-Mail Removed) .com>,
> "peterwn" <(E-Mail Removed)> wrote:


> I'll bet the security is no better than it's worth, in other words a given
> level of security shouldn't cost more to implement than the likely losses
> from not having it.
>

Agreed, it comes down to studying costs and benefits. High signalling
security may require the next size up processor and extra memory to
hold the various keys and seeds.

A serious breach of security may mean:
1. Sending people round to reset and refresh the units. This means
having a reasonable supply of people, vehicles, handhelds, sealing
crimp tools etc available and accounting for the gear.
2. Loss of customer confidence.
3. Loss of sales opportunities to other organisations.

You can form a tentative view on how the costs and benefits weigh up
from this.

 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      11-22-2006
In message <(E-Mail Removed) .com>, peterwn
wrote:

> It is pretty obvious that
> the signals would be well encrypted with a separate key for each unit,
> perhaps with a remotely changable rolling 'masterkey' for bulk
> transmission of emergency signals (eg to shut off power if a pylon
> falls down) or tariff broadcast signals.


It's worth looking at what does and doesn't need to be encrypted:
* billing/usage information sent from the customer's premises back to HQ --
yes, this needs to be encrypted for confidentiality, as well as
authenticated so HQ knows who it's coming from.
* turn-on/turn-off signals from HQ to the unit at the customer's premises --
doesn't need to be encrypted, but it must be authenticated to prevent
spoofing.
* tariff information from HQ to the unit--I don't see why this needs to be
encrypted, but again it does need to be authenticated.
* regular "are you there?" queries from HQ, and "yes I am here" responses
from the unit--should be authenticated in both directions, though probably
not encrypted. If HQ doesn't get a valid response from the unit within a
reasonable time, that would be grounds for sending someone out to see what
the problem might be. If the unit doesn't get a request from HQ within some
reasonable interval, then maybe it could display an alarm light or
something to alert the customer.

All this could be handled by public-key encryption (e.g. RSA). Before each
box is sent out to the customer's premises, it is given its private key,
and its public key is saved at HQ, so they can authenticate messages coming
from it, and encrypt messages that are only meant for it. Similarly HQ's
public key is copied to the box, so it can authenticate messages coming
from HQ, and encrypt messages that can only be read by HQ.

I don't think it should be possible to remotely tell the box to accept a new
public key (what you described as a "master key") from HQ. That kind of
feature probably opens up more problems than it solves.

> The biggest risk would be the hacking of the central computer
> holding the encryption keys.


You could reduce this risk with rigid separation of functions. Have a server
whose sole purpose is to hold HQ's public and private keys, the public keys
of all the units, and perform functions related to them, and nothing else
(cf the KDC in Kerberos). Make sure that server is carefully sequestered
from the rest of the network and the world, both physically and logically.

 
Reply With Quote
 
peterwn
Guest
Posts: n/a
 
      11-22-2006

Lawrence D'Oliveiro wrote:
> In message <(E-Mail Removed) .com>, peterwn
> wrote:
>
> > It is pretty obvious that
> > the signals would be well encrypted with a separate key for each unit,
> > perhaps with a remotely changable rolling 'masterkey' for bulk
> > transmission of emergency signals (eg to shut off power if a pylon
> > falls down) or tariff broadcast signals.

>
> It's worth looking at what does and doesn't need to be encrypted:
> * billing/usage information sent from the customer's premises back to HQ --
> yes, this needs to be encrypted for confidentiality, as well as
> authenticated so HQ knows who it's coming from.
> * turn-on/turn-off signals from HQ to the unit at the customer's premises --
> doesn't need to be encrypted, but it must be authenticated to prevent
> spoofing.


I have used 'encrypted' to mean 'authenticated' as well since I assumed
that one would encrypt to authenticate. agreed there would be similar
options.

> * tariff information from HQ to the unit--I don't see why this needs to be
> encrypted, but again it does need to be authenticated.
> * regular "are you there?" queries from HQ, and "yes I am here" responses
> from the unit--should be authenticated in both directions, though probably
> not encrypted. If HQ doesn't get a valid response from the unit within a
> reasonable time, that would be grounds for sending someone out to see what
> the problem might be. If the unit doesn't get a request from HQ within some
> reasonable interval, then maybe it could display an alarm light or
> something to alert the customer.
>
> All this could be handled by public-key encryption (e.g. RSA). Before each
> box is sent out to the customer's premises, it is given its private key,
> and its public key is saved at HQ, so they can authenticate messages coming
> from it, and encrypt messages that are only meant for it. Similarly HQ's
> public key is copied to the box, so it can authenticate messages coming
> from HQ, and encrypt messages that can only be read by HQ.
>
> I don't think it should be possible to remotely tell the box to accept a new
> public key (what you described as a "master key") from HQ. That kind of
> feature probably opens up more problems than it solves.


I perhaps used 'masterkey' where I meant a broadcast message for tariff
change or emergency disconnects - there would not be time to address
units individually. There would need to be some 'rolling' system so a
hacker cannot play back a sniffed message.

I also envisaged that the rolling authentication key/seed for broadcast
messages could be changed unit by unit if need be noting that during
the changeover two 'broadcast' messages would be needed for each
function.
>
> > The biggest risk would be the hacking of the central computer
> > holding the encryption keys.

>
> You could reduce this risk with rigid separation of functions. Have a server
> whose sole purpose is to hold HQ's public and private keys, the public keys
> of all the units, and perform functions related to them, and nothing else
> (cf the KDC in Kerberos). Make sure that server is carefully sequestered
> from the rest of the network and the world, both physically and logically.


Agreed. Also I envisage a further separation of the 'backup' keys but
these would only be required if the normal key server was hacked or
keys otherwise stolen. These could be kept on CD's or DVD's obtained
straight from the manufacturing production line of the units.

>If HQ doesn't get a valid response from the unit within a
>reasonable time, that would be grounds for sending someone out to see what
>the problem might be. If the unit doesn't get a request from HQ within some
>reasonable interval, then maybe it could display an alarm light or something to alert the >customer.


The unit is most likely to 'die' if it goes wrong making the light a
bit useless. The units would be effectively pinged when a reading is
requested and 'dead' or disconnected units would become apparent then.
They could be 'pinged' more frequently if need be (eg as they near the
end of their lifespan - they need to have a 30 year lifespan IMO - that
is the approximate lifespan of a magnetic bearing disc meter).


































r
something to alert the customer.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
problem in running a basic code in python 3.3.0 that includes HTML file Satabdi Mukherjee Python 1 04-04-2013 07:48 PM
Re: Best way to connect a Cisco router to a Norstar Meridian Cisco 0 04-07-2004 02:38 PM
Re: Best way to connect a Cisco router to a Norstar Meridian VOIP 0 04-07-2004 02:38 PM
Re: Best way to connect a Cisco router to a Norstar Meridian VOIP 1 04-07-2004 11:45 AM
Re: Best way to connect a Cisco router to a Norstar Meridian Cisco 1 04-07-2004 11:45 AM



Advertisments