Another way that Meridian generates electricity

Discussion in 'NZ Computing' started by jasen, Nov 20, 2006.

  1. jasen

    jasen Guest

    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
    jasen, Nov 20, 2006
    #1
    1. Advertising

  2. jasen

    peterwn Guest

    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.
    peterwn, Nov 20, 2006
    #2
    1. Advertising

  3. jasen

    Don Hills Guest

    In article <>,
    "peterwn" <> 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
    Don Hills, Nov 20, 2006
    #3
  4. jasen

    peterwn Guest

    Don Hills wrote:
    > In article <>,
    > "peterwn" <> 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.
    peterwn, Nov 21, 2006
    #4
  5. jasen

    Don Hills Guest

    In article <>,
    "peterwn" <> 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
    Don Hills, Nov 21, 2006
    #5
  6. jasen

    peterwn Guest

    Don Hills wrote:
    > In article <>,
    > "peterwn" <> 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.
    peterwn, Nov 22, 2006
    #6
  7. jasen

    Don Hills Guest

    In article <>,
    "peterwn" <> 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
    Don Hills, Nov 22, 2006
    #7
  8. jasen

    peterwn Guest

    Don Hills wrote:
    > In article <>,
    > "peterwn" <> 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.
    peterwn, Nov 22, 2006
    #8
  9. In message <>, 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.
    Lawrence D'Oliveiro, Nov 22, 2006
    #9
  10. jasen

    peterwn Guest

    Lawrence D'Oliveiro wrote:
    > In message <>, 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.
    peterwn, Nov 22, 2006
    #10
  11. In message <>, peterwn
    wrote:

    > I have used 'encrypted' to mean 'authenticated' as well since I assumed
    > that one would encrypt to authenticate.


    The two serve different purposes. They are built on the same basic
    mechanisms, but used in different ways.

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


    This is an addressing issue, which is separate from encryption and
    authentication issues. This could be handled the same way the Internet
    deals with it. Presumably it would be built on IPV4 (or better, IPV6)
    protocols anyway.

    > There would need to be some 'rolling' system so a
    > hacker cannot play back a sniffed message.


    There are standard ways of dealing with that. For instance, Kerberos adds a
    timestamp to its messages. This works as long as clocks are kept reasonably
    accurate--which could be ensured as a side-effect of the regular ping
    heartbeat, for instance.

    > I also envisaged that the rolling authentication key/seed for broadcast
    > messages could be changed unit by unit if need be...


    If each message exchange is short, then it's not clear what the point of
    this "rolling" key might be.

    For longer exchanges, it is common to randomly generate a new session key
    for each exchange. But the session key still needs to be exchanged using
    the (unchangeable) public/private key pairs of the participants. If the
    amount of data being passed in the actual message exchange is not much more
    than that required just to establish the session key, then the session key
    becomes a waste of time.

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


    What would be the point of "backup" keys? The loss of the regular keys has
    already compromised the entire system.
    Lawrence D'Oliveiro, Nov 22, 2006
    #11
  12. jasen

    peterwn Guest

    Lawrence D'Oliveiro wrote:

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

    >
    > What would be the point of "backup" keys? The loss of the regular keys has
    > already compromised the entire system.


    Because you can completely replace the keys and reseed the units
    without having to send someone round to replace keys etc on site.
    Moreover you can do it far quicker than field visits which is essential
    if someone is continuing to wreak chaos with the units.

    An example is the Ving card hotel lock. Hidden under the cover is a
    normal lock sylinder for emergency use - it will even open a room
    double locked from the inside, but specially arranged that the
    emergency key van be changed by pulling the old key out at (say) the 10
    o'clock position and putting a new key in and turning it back to the
    normal position. It is possible to do this 8 to 32 odd times before
    having to get a locksmith in to re-pin these cylinders. Since the
    emergency keys would be cut on special blanks and there would only be a
    few in circulation, these cylinders would remain completely secure for
    a decade or more.

    By the way another poster questioned the economic need for lots of
    security.

    A certain prominent gentleman must be rueing over apparent lack of
    security systems regarding E-mails and this has now been lethal to his
    political career.
    peterwn, Nov 23, 2006
    #12
  13. In message <>, peterwn
    wrote:

    > Lawrence D'Oliveiro wrote:
    >
    >> > ... 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.

    >>
    >> What would be the point of "backup" keys? The loss of the regular keys
    >> has already compromised the entire system.

    >
    > Because you can completely replace the keys and reseed the units
    > without having to send someone round to replace keys etc on site.


    And whoever managed to compromise the original keys can do exactly the same
    thing. They've got the head start between their effecting the compromise,
    and your discovering it, to do it before you do.

    > Moreover you can do it far quicker than field visits which is essential
    > if someone is continuing to wreak chaos with the units.


    Unfortunately field visits will be the only reliable way to recover from a
    key compromise. Therefore backup keys are a waste of time.
    Lawrence D'Oliveiro, Nov 23, 2006
    #13
  14. jasen

    jasen Guest

    On 2006-11-22, Lawrence D'Oliveiro <_zealand> wrote:

    >> I also envisaged that the rolling authentication key/seed for broadcast
    >> messages could be changed unit by unit if need be...

    >
    > If each message exchange is short, then it's not clear what the point of
    > this "rolling" key might be.
    >
    > For longer exchanges, it is common to randomly generate a new session key
    > for each exchange. But the session key still needs to be exchanged using
    > the (unchangeable) public/private key pairs of the participants. If the
    > amount of data being passed in the actual message exchange is not much more
    > than that required just to establish the session key, then the session key
    > becomes a waste of time.


    I envisage the setup to be based on a connectionless model (like UDP)

    key exchange seems pointless when the longest payload I can envisage is
    shorter than any reasonable key.


    Bye.
    Jasen
    jasen, Nov 23, 2006
    #14
  15. jasen

    ~misfit~ Guest

    Don Hills wrote:
    > In article <>,
    > "peterwn" <> 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.


    Hi Don, got your email, I hadn't looked at this thread.

    I have a pre-pay meter with Contact Energy, they call it "Prepower". It's
    the 'enter a 20-digit number sequence type'. There are in fact two meters at
    the property, one in the box outside and one on the wall inside. They both
    have keypads and both display the same thing. AFAIK, the outside meter's
    never been checked in the 5 years I've lived here.

    Cheers,
    --
    Shaun.
    ~misfit~, Nov 23, 2006
    #15
  16. In message <ek3bpn$gj3$-a-geek.org>, jasen wrote:

    > On 2006-11-22, Lawrence D'Oliveiro <_zealand>
    > wrote:
    >
    >>> I also envisaged that the rolling authentication key/seed for broadcast
    >>> messages could be changed unit by unit if need be...

    >>
    >> If each message exchange is short, then it's not clear what the point of
    >> this "rolling" key might be.
    >>
    >> For longer exchanges, it is common to randomly generate a new session key
    >> for each exchange. But the session key still needs to be exchanged using
    >> the (unchangeable) public/private key pairs of the participants. If the
    >> amount of data being passed in the actual message exchange is not much
    >> more than that required just to establish the session key, then the
    >> session key becomes a waste of time.

    >
    > I envisage the setup to be based on a connectionless model (like UDP)
    >
    > key exchange seems pointless when the longest payload I can envisage is
    > shorter than any reasonable key.


    Actually, thinking about it, a session key could still be useful in this
    situation. Presumably the customer units will be uploading billing/usage
    data on a regular basis (daily would seem quite reasonable). A session key
    could be used to encrypt/authenticate this, and perhaps renegotiated at
    random intervals of around a few days or even longer, depending on the
    amount of data being transmitted.
    Lawrence D'Oliveiro, Nov 23, 2006
    #16
  17. jasen

    Don Hills Guest

    In article <ek3hd9$f3s$>,
    "~misfit~" <> wrote:
    >
    >Hi Don, got your email, I hadn't looked at this thread.
    >
    >I have a pre-pay meter with Contact Energy, they call it "Prepower". It's
    >the 'enter a 20-digit number sequence type'. There are in fact two meters at
    >the property, one in the box outside and one on the wall inside. They both
    >have keypads and both display the same thing. AFAIK, the outside meter's
    >never been checked in the 5 years I've lived here.


    Thanks, Shaun. Just because you haven't seen a meter reader doesn't mean it
    isn't being read every few months. There's always someone home here, often
    in the room through the wall from the meter box, next to a noisy gate which
    has to be opened to gain access, yet neither of us have seen the meter
    reader in at least 3 years.

    --
    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
    Don Hills, Nov 23, 2006
    #17
  18. jasen

    ~misfit~ Guest

    Don Hills wrote:
    > In article <ek3hd9$f3s$>,
    > "~misfit~" <> wrote:
    > >
    > > Hi Don, got your email, I hadn't looked at this thread.
    > >
    > > I have a pre-pay meter with Contact Energy, they call it
    > > "Prepower". It's the 'enter a 20-digit number sequence type'. There
    > > are in fact two meters at the property, one in the box outside and
    > > one on the wall inside. They both have keypads and both display the
    > > same thing. AFAIK, the outside meter's never been checked in the 5
    > > years I've lived here.

    >
    > Thanks, Shaun. Just because you haven't seen a meter reader doesn't
    > mean it isn't being read every few months. There's always someone
    > home here, often in the room through the wall from the meter box,
    > next to a noisy gate which has to be opened to gain access, yet
    > neither of us have seen the meter reader in at least 3 years.


    Good point. However, with the amount of nasty dogs in this area (and a pit
    bull living out back) normally anyone who wants to come into the section
    starts yelling from the gate. The meter box is on the side of the house, not
    the front facing the road, The dog goes nuts as soon as he hears the chain
    on the gate rattle and most people back off through the gate again until I
    either tell them it's OK to come in or I go out to them. I remember now,
    thinking about it, once a guy read the meter (actually he was testing for a
    fault or something but he went to the meter box). That was about three years
    ago.
    --
    Shaun.

    "Peace cannot be kept by force. It can only be achieved by understanding"
    Albert Einstein
    ~misfit~, Nov 23, 2006
    #18
  19. jasen

    jasen Guest

    On 2006-11-23, Lawrence D'Oliveiro <_zealand> wrote:
    >>
    >> I envisage the setup to be based on a connectionless model (like UDP)
    >>
    >> key exchange seems pointless when the longest payload I can envisage is
    >> shorter than any reasonable key.

    >
    > Actually, thinking about it, a session key could still be useful in this
    > situation. Presumably the customer units will be uploading billing/usage
    > data on a regular basis (daily would seem quite reasonable). A session key
    > could be used to encrypt/authenticate this, and perhaps renegotiated at
    > random intervals of around a few days or even longer, depending on the
    > amount of data being transmitted.


    yeah I guess so, I hadn't considered it, but there's no reason why a session
    can't last for months, or even years.

    Bye.
    Jasen
    jasen, Nov 24, 2006
    #19
  20. In message <ek5vuf$ndq$-a-geek.org>, jasen wrote:

    > I hadn't considered it, but there's no reason why a
    > session can't last for months, or even years.


    The whole point about session keys is to minimize the use made of the keys
    that are hardest to change--the keys belonging to the unit and to the HQ.
    The more material you encrypt with a key, the more opportunities you offer
    to third parties to exploit weaknesses and crack those keys. Hence the
    reason for using them for little more than to exchange session keys, and
    then using those session keys for the rest of the encryption.

    For the same reason, it's not advisable to continue using a session key for
    too long. Ideally, you would renegotiate the session key at random
    intervals--it would be good if the protocol were designed so that an
    eavesdropper can't tell when this happens. That makes it harder for the
    eavesdropper to figure out which messages are encrypted with which keys.
    Lawrence D'Oliveiro, Nov 24, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Guest
    Replies:
    1
    Views:
    605
    Alec Waters
    Apr 7, 2004
  2. Guest
    Replies:
    0
    Views:
    586
    Guest
    Apr 7, 2004
  3. WCH

    mouse generates speaker noise

    WCH, Aug 17, 2005, in forum: Computer Support
    Replies:
    2
    Views:
    3,944
    Vanguard
    Aug 17, 2005
  4. Guest
    Replies:
    1
    Views:
    764
    Alec Waters
    Apr 7, 2004
  5. Guest
    Replies:
    0
    Views:
    767
    Guest
    Apr 7, 2004
Loading...

Share This Page