What could possibly go wrong... ;)

[Ned Latham]

Sylvia Else wrote:
> keithr0 wrote:

----snip----

It's not rocket surgery, you sign all messages with a 2048 bit RSA
private key, that positively identifies the sender. Add a pseudo random
rolling code to prevent replay attacks and wrap the whole lot in a 256
bit AES. Not hard at all really, it just takes a bit more effort.

The problem here is that then it's only as secure as the private key is,
which means that the integrity of the traffic light system depends on
hackers not getting access to the key.

Given that it shouldn't be necessary to update the critical firmware
anyway, other than for things like changes to speed limits (affects the
yellow/orange timing), which are local in nature, it's far safer just
not to allow remote updates at all.

And that (the rarity of updates) is the deciding factor. Given that the
updates must be checked individually, onsite updates would probably be
cheaper than remote updates anyway.

 

[Wotawonderfulworld]

Dechucka <Dechucka1@hotmail.com> wrote in
news:Z_2dnUqYJOQ5LhPAnZ2dnUU7-KXNnZ2d@westnet.com.au:

On 28/09/2019 11:05 am, Wotawonderfulworld wrote:
Dechucka <Dechucka1@hotmail.com> wrote in
news:M_GdnaNybZYwDhPAnZ2dnUU7-TnNnZ2d@westnet.com.au:

On 28/09/2019 8:49 am, Je�us wrote:
"Traffic and transport infrastructure, ATMs, and environmental
infrastructure get green light to connect to nbnâ„¢ access
network

NBN Co today announced that operators of traffic signals, automatic
teller machines and a range of other specialised devices can now
connect to select services over the nbnâ„¢ access network
through their retail service providers"

https://www.nbnco.com.au/corporate-information/media-centre/media-st
at ements/network-extensions


I can't see - buffering, buffering, buffering - any problems. Of
course I don't know anything about the NBN because living 1/2 way
between Sydney and Canberra we are so isolated that we are only
offered satellite. If you've got kids at school or uni + want to run
a business and want to work during the day/peak hours it is useless
because the packs don't give enough data. ADSL rules OK (sometimes)


Ah you must be a neighbour. Same problem, I miss the old adsl, all
you could eat for $29.95 pm and it loaded a web page so much quicker
than Sky Muster can, and now i get 80gig for $74,95 a month. OOohh so
lucky the NBN came here.

How much of that is off-peak? There are lots of plans that offer 150
Gb but when you look at them it is only 30Gb on peak. Even doing
research now most sites are hugely graphics heavy, most of them just
pretty corporate pictures, so it does take more download than it used
to.

There is a good 120gig odd in off peak, but at my age i don't sit up at
1:00am gamining, so offpeak is totally useless to me unless i decide to
start pirating movies..

So basically i'm paying over $1 a gig for the internet, with added pitiful
response time, after i had better response time and $29.95 unlimited.

I love the NBN, it really has opened up a class system in australia.

 

[Dechucka]

On 1/10/2019 11:11 am, Wotawonderfulworld wrote:

Dechucka <Dechucka1@hotmail.com> wrote in
news:Z_2dnUqYJOQ5LhPAnZ2dnUU7-KXNnZ2d@westnet.com.au:

On 28/09/2019 11:05 am, Wotawonderfulworld wrote:
Dechucka <Dechucka1@hotmail.com> wrote in
news:M_GdnaNybZYwDhPAnZ2dnUU7-TnNnZ2d@westnet.com.au:

On 28/09/2019 8:49 am, Je�us wrote:
"Traffic and transport infrastructure, ATMs, and environmental
infrastructure get green light to connect to nbnâ„¢ access
network

NBN Co today announced that operators of traffic signals, automatic
teller machines and a range of other specialised devices can now
connect to select services over the nbnâ„¢ access network
through their retail service providers"

https://www.nbnco.com.au/corporate-information/media-centre/media-st
at ements/network-extensions


I can't see - buffering, buffering, buffering - any problems. Of
course I don't know anything about the NBN because living 1/2 way
between Sydney and Canberra we are so isolated that we are only
offered satellite. If you've got kids at school or uni + want to run
a business and want to work during the day/peak hours it is useless
because the packs don't give enough data. ADSL rules OK (sometimes)


Ah you must be a neighbour. Same problem, I miss the old adsl, all
you could eat for $29.95 pm and it loaded a web page so much quicker
than Sky Muster can, and now i get 80gig for $74,95 a month. OOohh so
lucky the NBN came here.

How much of that is off-peak? There are lots of plans that offer 150
Gb but when you look at them it is only 30Gb on peak. Even doing
research now most sites are hugely graphics heavy, most of them just
pretty corporate pictures, so it does take more download than it used
to.



There is a good 120gig odd in off peak, but at my age i don't sit up at
1:00am gamining, so offpeak is totally useless to me unless i decide to
start pirating movies..

So basically i'm paying over $1 a gig for the internet, with added pitiful
response time, after i had better response time and $29.95 unlimited.

I love the NBN, it really has opened up a class system in australia.

Luckily I have the time so ADSL is OK for me. I suppose one day I'll be
forced onto satellite :-(

 

[keithr0]

On 9/29/2019 9:58 AM, Computer Nerd Kev wrote:

In aus.electronics Sylvia Else <sylvia@email.invalid> wrote:
On 28/09/2019 7:25 pm, news18 wrote:
On Sat, 28 Sep 2019 12:31:42 +1000, Sylvia Else wrote:

The expectation is that the basic rules of operation that ensure that
only one direction gets green, and defines the period that a light stays
yellow/orange, are built into the system hardware/firmware, with the
latter only capable of being modified on site.

Might apply to HW designs, but I'm wondering how many are all but SW
these days.


If I wanted to do it in software, I'd have one[*] microcontroller that's
responsible for the control of the lights, and a separate one handling
the networking and communication. The latter is considerably more
complicated than the former.

From the link that I posted earlier about a system hacked in the US:
"The main components of wirelessly networked traffic lights are:
Sensors that detect cars and inspect infrastructure. Those sensors
are generally connected to traffic controllers that read the inputs
and control light states. Those controllers, usually in a metal
cabinet by the roadside, communicate with each other and a central
server. Radios, operating at 900 MHz or 5.8 GHz, are frequently
used for wireless communication in point-to-point or
point-to-multipoint configurations.

-Then there's malfunction
management units (MMUs) that can override the controller if there
are conflicting green lights and force traffic lights into a
"known-safe configuration" like blinking red lights."
https://www.csoonline.com/article/2466551/hacking-traffic-lights-with-a-laptop-is-easy.html

What made that hack so easy wasn't just that they were using
unencrypted wifi to communicate with/between traffic lights, but they
were using the default password which was printed in the manual!

The use of "MMUs" indicates that the hardware designers _might_ have
had an idea of what they're doing, but the software designers and
system installers certainly weren't considering hacking at all.

Who knows what the state of the industry is in Australia.

Hackers are people who exploit others fuckups. Don't fuckup and you
don't get hacked. These people fucked up on so many levels that they
deserved to get hacked.

 

[Sylvia Else]

On 3/10/2019 3:54 pm, keithr0 wrote:

On 9/29/2019 9:58 AM, Computer Nerd Kev wrote:
In aus.electronics Sylvia Else <sylvia@email.invalid> wrote:
On 28/09/2019 7:25 pm, news18 wrote:
On Sat, 28 Sep 2019 12:31:42 +1000, Sylvia Else wrote:

The expectation is that the basic rules of operation that ensure that
only one direction gets green, and defines the period that a light
stays
yellow/orange, are built into the system hardware/firmware, with the
latter only capable of being modified on site.

Might apply to HW designs, but I'm wondering how many are all but SW
these days.


If I wanted to do it in software, I'd have one[*] microcontroller that's
responsible for the control of the lights, and a separate one handling
the networking and communication. The latter is considerably more
complicated than the former.

 From the link that I posted earlier about a system hacked in the US:
"The main components of wirelessly networked traffic lights are:
  Sensors that detect cars and inspect infrastructure. Those sensors
  are generally connected to traffic controllers that read the inputs
  and control light states. Those controllers, usually in a metal
  cabinet by the roadside, communicate with each other and a central
  server. Radios, operating at 900 MHz or 5.8 GHz, are frequently
  used for wireless communication in point-to-point or
  point-to-multipoint configurations.

-Then there's malfunction
  management units (MMUs) that can override the controller if there
  are conflicting green lights and force traffic lights into a
  "known-safe configuration" like blinking red lights."
https://www.csoonline.com/article/2466551/hacking-traffic-lights-with-a-laptop-is-easy.html


What made that hack so easy wasn't just that they were using
unencrypted wifi to communicate with/between traffic lights, but they
were using the default password which was printed in the manual!

The use of "MMUs" indicates that the hardware designers _might_ have
had an idea of what they're doing, but the software designers and
system installers certainly weren't considering hacking at all.

Who knows what the state of the industry is in Australia.

Hackers are people who exploit others fuckups. Don't fuckup and you
don't get hacked. These people fucked up on so many levels that they
deserved to get hacked.

Do other people deserve to get their lives messed up in consequence.

The aviation industry might originally have taken the view that
mechanics should install parts the right way around. After all, how hard
can it be?

But eventually, after people died, it became realised that it was better
just to make it impossible to install parts the wrong way around.

Mind you, even that doesn't always work. A non-return valve was found
installed the wrong way around in a crashed aircraft. The valve had an
interference pin designed into it to ensure that it could not be
installed backwards. It was determined that someone had cut it to make
it shorter - apparently because they could get it to fit otherwise.

Still, the principle remains valid. The less scope there is for making
mistakes, the fewer mistakes will be made, whether due to human
fallibility, or just incompetence.

Sylvia.

 

[Xeno]

On 3/10/19 4:01 pm, Sylvia Else wrote:

On 3/10/2019 3:54 pm, keithr0 wrote:
On 9/29/2019 9:58 AM, Computer Nerd Kev wrote:
In aus.electronics Sylvia Else <sylvia@email.invalid> wrote:
On 28/09/2019 7:25 pm, news18 wrote:
On Sat, 28 Sep 2019 12:31:42 +1000, Sylvia Else wrote:

The expectation is that the basic rules of operation that ensure that
only one direction gets green, and defines the period that a light
stays
yellow/orange, are built into the system hardware/firmware, with the
latter only capable of being modified on site.

Might apply to HW designs, but I'm wondering how many are all but SW
these days.


If I wanted to do it in software, I'd have one[*] microcontroller
that's
responsible for the control of the lights, and a separate one handling
the networking and communication. The latter is considerably more
complicated than the former.

 From the link that I posted earlier about a system hacked in the US:
"The main components of wirelessly networked traffic lights are:
  Sensors that detect cars and inspect infrastructure. Those sensors
  are generally connected to traffic controllers that read the inputs
  and control light states. Those controllers, usually in a metal
  cabinet by the roadside, communicate with each other and a central
  server. Radios, operating at 900 MHz or 5.8 GHz, are frequently
  used for wireless communication in point-to-point or
  point-to-multipoint configurations.

-Then there's malfunction
  management units (MMUs) that can override the controller if there
  are conflicting green lights and force traffic lights into a
  "known-safe configuration" like blinking red lights."
https://www.csoonline.com/article/2466551/hacking-traffic-lights-with-a-laptop-is-easy.html


What made that hack so easy wasn't just that they were using
unencrypted wifi to communicate with/between traffic lights, but they
were using the default password which was printed in the manual!

The use of "MMUs" indicates that the hardware designers _might_ have
had an idea of what they're doing, but the software designers and
system installers certainly weren't considering hacking at all.

Who knows what the state of the industry is in Australia.

Hackers are people who exploit others fuckups. Don't fuckup and you
don't get hacked. These people fucked up on so many levels that they
deserved to get hacked.

Do other people deserve to get their lives messed up in consequence.

The aviation industry might originally have taken the view that
mechanics should install parts the right way around. After all, how hard
can it be?

But eventually, after people died, it became realised that it was better
just to make it impossible to install parts the wrong way around.

Mind you, even that doesn't always work. A non-return valve was found
installed the wrong way around in a crashed aircraft. The valve had an
interference pin designed into it to ensure that it could not be
installed backwards. It was determined that someone had cut it to make
it shorter - apparently because they could get it to fit otherwise.

You make something foolproof, then find out fools are damned ingenious!

Still, the principle remains valid. The less scope there is for making
mistakes, the fewer mistakes will be made, whether due to human
fallibility, or just incompetence.

Sylvia.

--

Xeno


Nothing astonishes Noddy so much as common sense and plain dealing.
(with apologies to Ralph Waldo Emerson)

 

[keithr0]

On 10/3/2019 4:45 PM, Xeno wrote:

On 3/10/19 4:01 pm, Sylvia Else wrote:
On 3/10/2019 3:54 pm, keithr0 wrote:
On 9/29/2019 9:58 AM, Computer Nerd Kev wrote:
In aus.electronics Sylvia Else <sylvia@email.invalid> wrote:
On 28/09/2019 7:25 pm, news18 wrote:
On Sat, 28 Sep 2019 12:31:42 +1000, Sylvia Else wrote:

The expectation is that the basic rules of operation that ensure
that
only one direction gets green, and defines the period that a
light stays
yellow/orange, are built into the system hardware/firmware, with the
latter only capable of being modified on site.

Might apply to HW designs, but I'm wondering how many are all but SW
these days.


If I wanted to do it in software, I'd have one[*] microcontroller
that's
responsible for the control of the lights, and a separate one handling
the networking and communication. The latter is considerably more
complicated than the former.

 From the link that I posted earlier about a system hacked in the US:
"The main components of wirelessly networked traffic lights are:
  Sensors that detect cars and inspect infrastructure. Those sensors
  are generally connected to traffic controllers that read the inputs
  and control light states. Those controllers, usually in a metal
  cabinet by the roadside, communicate with each other and a central
  server. Radios, operating at 900 MHz or 5.8 GHz, are frequently
  used for wireless communication in point-to-point or
  point-to-multipoint configurations.

-Then there's malfunction
  management units (MMUs) that can override the controller if there
  are conflicting green lights and force traffic lights into a
  "known-safe configuration" like blinking red lights."
https://www.csoonline.com/article/2466551/hacking-traffic-lights-with-a-laptop-is-easy.html


What made that hack so easy wasn't just that they were using
unencrypted wifi to communicate with/between traffic lights, but they
were using the default password which was printed in the manual!

The use of "MMUs" indicates that the hardware designers _might_ have
had an idea of what they're doing, but the software designers and
system installers certainly weren't considering hacking at all.

Who knows what the state of the industry is in Australia.

Hackers are people who exploit others fuckups. Don't fuckup and you
don't get hacked. These people fucked up on so many levels that they
deserved to get hacked.

Do other people deserve to get their lives messed up in consequence.

The aviation industry might originally have taken the view that
mechanics should install parts the right way around. After all, how
hard can it be?

But eventually, after people died, it became realised that it was
better just to make it impossible to install parts the wrong way around.

Mind you, even that doesn't always work. A non-return valve was found
installed the wrong way around in a crashed aircraft. The valve had an
interference pin designed into it to ensure that it could not be
installed backwards. It was determined that someone had cut it to make
it shorter - apparently because they could get it to fit otherwise.

You make something foolproof, then find out fools are damned ingenious!

Still, the principle remains valid. The less scope there is for making
mistakes, the fewer mistakes will be made, whether due to human
fallibility, or just incompetence.

Sylvia.

When you set up a system, first you test that it does what it should,
then you test that it doesn't do anything that it shouldn't . Too many
miss the last step.

 

[noel]

On Thu, 03 Oct 2019 15:54:27 +1000, keithr0 wrote:

Hackers are people who exploit others fuckups. Don't fuckup and you
don't get hacked. These people fucked up on so many levels that they
deserved to get hacked.

uhg ... bullshit...
most people who expolit others are not hackers, they are script kiddies,
ridding off the back of someone elses scripting that exploit dumb arsed
programmers who write insecure code crappy code.

in years gone by in previous life as ISP network admin, we banned php
gallery becasue it had more holes than a pallet of swiss cheese and was
every single time tehr eason someone got fucked up hte arse.

todays version of phpgallery is wordpress.. or more specifically,
wordpress plugins, written by clueless incompetent fucktarts who think
their hot shit coders when hte truth is they are only just shit.

 

[keithr0]

On 10/7/2019 12:22 AM, noel wrote:

On Thu, 03 Oct 2019 15:54:27 +1000, keithr0 wrote:


Hackers are people who exploit others fuckups. Don't fuckup and you
don't get hacked. These people fucked up on so many levels that they
deserved to get hacked.


uhg ... bullshit...
most people who expolit others are not hackers, they are script kiddies,
ridding off the back of someone elses scripting that exploit dumb arsed
programmers who write insecure code crappy code.

The hackers make the exploits, the script kiddies simply follow the
ready made exploits.

in years gone by in previous life as ISP network admin, we banned php
gallery becasue it had more holes than a pallet of swiss cheese and was
every single time tehr eason someone got fucked up hte arse.

todays version of phpgallery is wordpress.. or more specifically,
wordpress plugins, written by clueless incompetent fucktarts who think
their hot shit coders when hte truth is they are only just shit.

That is basically what I was saying, of course, if you see all these
problems, you could do something about fixing them, if you have the
talent that is.

 

[Sylvia Else]

On 7/10/2019 10:46 am, keithr0 wrote:

That is basically what I was saying, of course, if you see all these
problems, you could do something about fixing them, if you have the
talent that is.

Sometimes that's not so straight forward, requiring structural changes.
Duck typing and SQL string literals have a lot to answer for, but
eliminating them would meet with a lot of resistance, particularly
amongst those who cannot handle more formal techniques.


Sylvia.

 

[Computer Nerd Kev]

In aus.electronics Sylvia Else <sylvia@email.invalid> wrote:

On 7/10/2019 10:46 am, keithr0 wrote:

That is basically what I was saying, of course, if you see all these
problems, you could do something about fixing them, if you have the
talent that is.

Sometimes that's not so straight forward, requiring structural changes.
Duck typing and SQL string literals have a lot to answer for, but
eliminating them would meet with a lot of resistance, particularly
amongst those who cannot handle more formal techniques.

Not to mention that "seeing all the problems" implies that you've
actually looked though _all_ of the code used. True this would be
quite possible with what my idea of a traffic light controller would
be. but apparantly they now want WiFi. So that's a WiFi chipset
driver, TCP/IP, support for whatever existing protocols they may want
to use, and (should be) encryption. Are they expected to look through
all of the external code that they call in to do that? Are they
expected to understand the endless complexities of practical data
encryption well enough to identify bugs in that code?

They might decide to use Linux, do they have to check all the code
used in that themselves as well?

No argument that using unencrypted WiFi was something within any
programmer's abilities to identify as a security weakness. But to
guarantee security against hacking while fulfilling requirements
like supporting WiFi is hardly an easy enough task to consider it
a basic indicator of talent.

--
__ __
#_ < |\| |< _#

 

[Ned Latham]

Computer Nerd Kev wrote:
> Sylvia Else wrote:

----snip----

Sometimes that's not so straight forward, requiring structural changes.
Duck typing and SQL string literals have a lot to answer for, but
eliminating them would meet with a lot of resistance, particularly
amongst those who cannot handle more formal techniques.

Not to mention that "seeing all the problems" implies that you've
actually looked though _all_ of the code used. True this would be
quite possible with what my idea of a traffic light controller would
be. but apparantly they now want WiFi. So that's a WiFi chipset
driver, TCP/IP, support for whatever existing protocols they may want
to use, and (should be) encryption. Are they expected to look through
all of the external code that they call in to do that?

The answer to that is the answer to this: are they competent?

Are they
expected to understand the endless complexities of practical data
encryption well enough to identify bugs in that code?

Are they competent?

> They might decide to use Linux,

What? And forego the delights and safety of Windows, the OS that's had
so many upgrades to its stabilty and power and robustness and security
that it must surely be perfect by now?

> do they have to check all the code used in that themselves as well?

Do they want secure?

No argument that using unencrypted WiFi was something within any
programmer's abilities to identify as a security weakness. But to
guarantee security against hacking while fulfilling requirements
like supporting WiFi is hardly an easy enough task to consider it
a basic indicator of talent.

It's a basic matter of competence, and having the strength to reject
the corporate crap that is the root of these security problems.

 

[Computer Nerd Kev]

In aus.electronics Ned Latham <nedlatham@woden.valhalla.oz> wrote:

Are they
expected to understand the endless complexities of practical data
encryption well enough to identify bugs in that code?

Are they competent?

They might decide to use Linux,

What? And forego the delights and safety of Windows, the OS that's had
so many upgrades to its stabilty and power and robustness and security
that it must surely be perfect by now?

No, as opposed to writing code to run directly in real-time, without
an operating system. Quite sensible for a basic traffic light
controller, but if you want to add things like WiFi, then running
Linux or another OS suitable for low-power embedded applications
(not Windows) would make development easier and more flexible.

do they have to check all the code used in that themselves as well?

Do they want secure?

No argument that using unencrypted WiFi was something within any
programmer's abilities to identify as a security weakness. But to
guarantee security against hacking while fulfilling requirements
like supporting WiFi is hardly an easy enough task to consider it
a basic indicator of talent.

It's a basic matter of competence, and having the strength to reject
the corporate crap that is the root of these security problems.

Dream on if you think that every programmer should be able to
reliably assess all the code required to implement a WiFi device
using networking and encrypted communication. A practical approach
is to hire an expert in software security to assess the system
independently of the developers, but there's still no complete
certainty when the device is on a public network, or otherwise
theoretically accessible by any man in the street.

For a system as important as traffic lights, where a widespread
hack could have extremely serious consequences to the national
economy, I would prefer a dedicated secure physical network which
can not be easily accessed by people who are unauthorised and
unidentifiable. But some country out there will have to get badly
bitten before that sort of thing will start being considered.

--
__ __
#_ < |\| |< _#

 

[Sylvia Else]

On 9/10/2019 9:06 am, Computer Nerd Kev wrote:

In aus.electronics Ned Latham <nedlatham@woden.valhalla.oz> wrote:

Are they
expected to understand the endless complexities of practical data
encryption well enough to identify bugs in that code?

Are they competent?

They might decide to use Linux,

What? And forego the delights and safety of Windows, the OS that's had
so many upgrades to its stabilty and power and robustness and security
that it must surely be perfect by now?

No, as opposed to writing code to run directly in real-time, without
an operating system. Quite sensible for a basic traffic light
controller, but if you want to add things like WiFi, then running
Linux or another OS suitable for low-power embedded applications
(not Windows) would make development easier and more flexible.

do they have to check all the code used in that themselves as well?

Do they want secure?

No argument that using unencrypted WiFi was something within any
programmer's abilities to identify as a security weakness. But to
guarantee security against hacking while fulfilling requirements
like supporting WiFi is hardly an easy enough task to consider it
a basic indicator of talent.

It's a basic matter of competence, and having the strength to reject
the corporate crap that is the root of these security problems.

Dream on if you think that every programmer should be able to
reliably assess all the code required to implement a WiFi device
using networking and encrypted communication. A practical approach
is to hire an expert in software security to assess the system
independently of the developers, but there's still no complete
certainty when the device is on a public network, or otherwise
theoretically accessible by any man in the street.

For a system as important as traffic lights, where a widespread
hack could have extremely serious consequences to the national
economy, I would prefer a dedicated secure physical network which
can not be easily accessed by people who are unauthorised and
unidentifiable. But some country out there will have to get badly
bitten before that sort of thing will start being considered.

Any communications channel should be treated as not being trusted, and
that certainly applies to things like Wifi. If that philosophy is
followed, then the worst that should be possible by hacking it is a
denial of service. In the context of traffic lights, that should only
mean that the phasing cannot be changed by a manned control centre in
response to traffic conditions. Even there, the effect would be limited
if the normal daily traffic flow patterns are built into the trusted
part of the system as a default.

Sylvia.

 

[Computer Nerd Kev]

In aus.electronics Sylvia Else <sylvia@email.invalid> wrote:

On 9/10/2019 9:06 am, Computer Nerd Kev wrote:

For a system as important as traffic lights, where a widespread
hack could have extremely serious consequences to the national
economy, I would prefer a dedicated secure physical network which
can not be easily accessed by people who are unauthorised and
unidentifiable. But some country out there will have to get badly
bitten before that sort of thing will start being considered.

Any communications channel should be treated as not being trusted, and
that certainly applies to things like Wifi. If that philosophy is
followed, then the worst that should be possible by hacking it is a
denial of service. In the context of traffic lights, that should only
mean that the phasing cannot be changed by a manned control centre in
response to traffic conditions.

What if hackers were spoofing commands which the traffic lights think
are coming from the control centre (assuming that they have found a
vulnerability in whatever system should be used to authenticate such
commands)? They could configure them to cause maximum disruption even
if they can't stop them working altogether.

--
__ __
#_ < |\| |< _#

 

[Sylvia Else]

On 9/10/2019 1:45 pm, Computer Nerd Kev wrote:

In aus.electronics Sylvia Else <sylvia@email.invalid> wrote:
On 9/10/2019 9:06 am, Computer Nerd Kev wrote:

For a system as important as traffic lights, where a widespread
hack could have extremely serious consequences to the national
economy, I would prefer a dedicated secure physical network which
can not be easily accessed by people who are unauthorised and
unidentifiable. But some country out there will have to get badly
bitten before that sort of thing will start being considered.

Any communications channel should be treated as not being trusted, and
that certainly applies to things like Wifi. If that philosophy is
followed, then the worst that should be possible by hacking it is a
denial of service. In the context of traffic lights, that should only
mean that the phasing cannot be changed by a manned control centre in
response to traffic conditions.

What if hackers were spoofing commands which the traffic lights think
are coming from the control centre (assuming that they have found a
vulnerability in whatever system should be used to authenticate such
commands)? They could configure them to cause maximum disruption even
if they can't stop them working altogether.

Authentication of cryptographically signed commands is, at its core,
very simple. The complexity in the system used for things like TLS
derives from the need to allow multiple algorithms, and the use of
session keys. None of that is necessary for authentication traffic light
commands, and there should be no difficulty implementing such a system
with no vulnerabilities [*].

If the hackers were able to obtain the signing key, then they could get
more control over the system, but still only to the extent of changing
the phasing within preset limits, where those limits themselves depend
on the time of day.

Sylvia.

[*] As long as the factorisation problem remains unsolved.

 

[Jasen Betts]

On 2019-10-08, Computer Nerd Kev <not@telling.you.invalid> wrote:

For a system as important as traffic lights, where a widespread
hack could have extremely serious consequences to the national
economy, I would prefer a dedicated secure physical network which
can not be easily accessed by people who are unauthorised and
unidentifiable. But some country out there will have to get badly
bitten before that sort of thing will start being considered.

VPN seems easier and almost as good.

--
When I tried casting out nines I made a hash of it.

 

[Sylvia Else]

On 9/10/2019 3:23 pm, Jasen Betts wrote:

On 2019-10-08, Computer Nerd Kev <not@telling.you.invalid> wrote:

For a system as important as traffic lights, where a widespread
hack could have extremely serious consequences to the national
economy, I would prefer a dedicated secure physical network which
can not be easily accessed by people who are unauthorised and
unidentifiable. But some country out there will have to get badly
bitten before that sort of thing will start being considered.

VPN seems easier and almost as good.

VPN is only as good as the software that implements it.

Sylvia.

 

[Computer Nerd Kev]

In aus.electronics Sylvia Else <sylvia@email.invalid> wrote:

On 9/10/2019 1:45 pm, Computer Nerd Kev wrote:
In aus.electronics Sylvia Else <sylvia@email.invalid> wrote:

Any communications channel should be treated as not being trusted, and
that certainly applies to things like Wifi. If that philosophy is
followed, then the worst that should be possible by hacking it is a
denial of service. In the context of traffic lights, that should only
mean that the phasing cannot be changed by a manned control centre in
response to traffic conditions.

What if hackers were spoofing commands which the traffic lights think
are coming from the control centre (assuming that they have found a
vulnerability in whatever system should be used to authenticate such
commands)? They could configure them to cause maximum disruption even
if they can't stop them working altogether.


Authentication of cryptographically signed commands is, at its core,
very simple. The complexity in the system used for things like TLS
derives from the need to allow multiple algorithms, and the use of
session keys. None of that is necessary for authentication traffic light
commands, and there should be no difficulty implementing such a system
with no vulnerabilities [*].

If the hackers were able to obtain the signing key, then they could get
more control over the system, but still only to the extent of changing
the phasing within preset limits, where those limits themselves depend
on the time of day.

I see what you're getting at, but there are opposing goals in that
approach where it takes away from the degree of flexibility that the
system was designed to implement in the first place. For example what
about when road works or traffic accidents cause traffic to be
rerouted, does it have to be needlessly held up at lights which are
forced to preference flow through the usual traffic routes?

> [*] As long as the factorisation problem remains unsolved.

I took this as an excuse to look far too deeply into the current
state of attacks on encryption:

I think the current bet is on quantum computers simply becoming
powerful enough to adequately implement one of the solutions that
use them.

It's still a long way from the being useful, but going from being
able to factorise 143 in 2012 to having one realise that 659 571s
make 376,289 last year seems a decent rate of advancement to my
uneducated eye. Of course the key thing is that these computers find
the answer in only a few seconds.
https://crypto.stackexchange.com/a/59796
-Granted the author of that Stack Exchange answer has a different
view.

This paper estimates the minimum specs for a quantum computer able
to break the factorisation problem for RSA, and also the alternative
Eliptic curve method (which turns out to be easier for quantum
computers to beat):
https://www.microsoft.com/en-us/research/publication/quantum-resource-estimates-computing-elliptic-curve-discrete-logarithms/
-Page 21 for results summarised in table 2.

That caims that a quantum computer with at least a few thousand
qbits would be required to effictively attack currently used
encryption systems. The current top-end seems to be 72qb. Though
the metric of qbits is complicated in the case of the "Quantum
annealing" D-Wave computer that found the factors of 376,289,
because this actually has 2048qb. However it works in a different
way (more akin in principle to an old fashioned analogue computer,
but using "quantum magnetism" instead of analogue electrical
signals - at least that's how I'm reading it) compared to "universal"
quantum computers from other manufacturers, and the relationship of
qbits to computing power isn't (at least directly) comparable between
them. Nevertheless in this task it seems that quantum annealing
currently has the edge.
https://en.wikipedia.org/wiki/List_of_quantum_processors
https://www.eetimes.com/document.asp?doc_id=1326592
https://en.wikipedia.org/wiki/Quantum_annealing

IARPA, the equivalent of DARPA for the American intelligence
agencies, is very involved in the development of quantum
computing research, probably in combination with manufacturers of
commercial quantum computers. So it seems likely that the true state
of the art might be at least one step ahead of what's public.
https://www.iarpa.gov/index.php/research-programs/quantum-programs-at-iarpa
https://en.wikipedia.org/wiki/Intelligence_Advanced_Research_Projects_Activity#Research_fields

Maybe to say that a universal quantum computer with thousands of
qbits is currently impossible today is akin to a German saying that
a computer built from 1,600 valves was impossible in 1944, while
Colossus was whirring away decrypting all of their war plans.

In any case, quantum computers are already being bought by companies
looking to use them for improved methods of encryption:
https://dwavefederal.com/temporal-defense-systems-purchases-first-d-wave-2000q-quantum-computer/

And this new chip designed for "post-quantum encryption" might even
be suited for use in a traffic light controller if it were on the
market:
http://news.mit.edu/2019/securing-internet-things-in-quantum-age-0301

https://en.wikipedia.org/wiki/Post-quantum_encryption

--
__ __
#_ < |\| |< _#

 

[Computer Nerd Kev]

In aus.electronics Sylvia Else <sylvia@email.invalid> wrote:

On 9/10/2019 3:23 pm, Jasen Betts wrote:
On 2019-10-08, Computer Nerd Kev <not@telling.you.invalid> wrote:

For a system as important as traffic lights, where a widespread
hack could have extremely serious consequences to the national
economy, I would prefer a dedicated secure physical network which
can not be easily accessed by people who are unauthorised and
unidentifiable. But some country out there will have to get badly
bitten before that sort of thing will start being considered.

VPN seems easier and almost as good.

VPN is only as good as the software that implements it.

Indeed. Might still be a good idea to use it _on_ the dedicated
physical network though - perhaps the same secure physical network
could be used for other targets likely to be hacked by attacters
with the aim of economic disruption, like power and water
distribution. Some have already been "bitten" on those fronts, but
not badly enough to make the world take the security of these things
seriously.

--
__ __
#_ < |\| |< _#