What could possibly go wrong... ;)

On 28/09/2019 8:56 am, Dechucka wrote:
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-statements/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.

I have friends who can see the Federal Parliament from their house and
they could only use satellite. Of course their house is on a scrub
covered hill 25 minutes from Parliament House in the scrub surrounding
Canberra so no surprise there....

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)
 
On Sat, 28 Sep 2019 13:42:16 +0700, Jeßus wrote:

On Fri, 27 Sep 2019 19:51:11 -0500, Ned Latham
nedlatham@woden.valhalla.oz> wrote:


Kinda depends on what software they're operating. Our banks, govt depts,
shops, supermarkets, travel operators, indeed just about every
enterprise in the nation use Microsoft systems; inherently unstable,
errorprone and insecure. These additions gonna be any different?

Intruder heaven.

Let's not even mention https://en.wikipedia.org/wiki/Stuxnet

Stuxnet didn't travel over the internet or any comms network.
It was delivered by feet on a usb stick carried by a dutchman under
israeli pay, apparently multiple times as they were able to keep throwing
versions at it.
 
On Sat, 28 Sep 2019 12:31:42 +1000, Sylvia Else wrote:

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-
statements/network-extensions


In theory, this shouldn't present that much of an issue. Take traffic
lights, for example.

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.
 
On 28/09/2019 7:25 pm, news18 wrote:
On Sat, 28 Sep 2019 12:31:42 +1000, Sylvia Else wrote:

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-
statements/network-extensions


In theory, this shouldn't present that much of an issue. Take traffic
lights, for example.

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.

Don't provide a way for the second one to update the first, so that the
first has to be updated on site (though why an update should ever be
necessary, is beyond me - how hard is it to get such things right in the
first place?).

Of course, the temptation is to use one processor for both, because
doing that saves money.

Sylvia

[*] Or 3, configured so that any 2 can determine which lights are on,
providing both redundancy and protection from a single one going rogue
due to a fault.
 
On 9/28/2019 9:14 AM, Je�us wrote:
On Sat, 28 Sep 2019 08:56:42 +1000, Dechucka <Dechucka1@hotmail.com
wrote:

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-statements/network-extensions


I can't see - buffering, buffering, buffering - any problems.

Never mind when - not if - security becomes compromised by some bunch
of teenagers or foreign government.

Even back when I worked on ATMs (late 80s - early 90s) all comms from
ATMs were encrypted. DES or triple DES in those days, I would hope that
these days it would be 256 bit AES or 2048 bit RSA. The messages are
also protected by message authentication code, very hard to crack. Most
ATMs in those days communicated over POTS far less secure than NBN.

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.

Yes, we have NBN Skymuster back in Tassie. In truth, it's been quite
reliable. Had it since 2012 (I think). Although I've noticed speeds
and latency quality dropping lately.

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)

ATMs use very little bandwidth, and the latency inherent in the system
is far greater than is likely to be experienced from the NBN.
 
In aus.electronics keithr0 <user@account.invalid> wrote:
On 9/28/2019 9:14 AM, Je?us wrote:

Never mind when - not if - security becomes compromised by some bunch
of teenagers or foreign government.

Even back when I worked on ATMs (late 80s - early 90s) all comms from
ATMs were encrypted. DES or triple DES in those days, I would hope that
these days it would be 256 bit AES or 2048 bit RSA. The messages are
also protected by message authentication code, very hard to crack. Most
ATMs in those days communicated over POTS far less secure than NBN.

Continuing on the movie theme, albeit now with one that nobody's
heard of, I'm reminded of Prime Risk (1985):
https://www.imdb.com/title/tt0087942/

A neat part of the plot is that they actually take advantage of an
RF leak associated with key presses on the keypad on an ATM in order
to "listen in" to credit card pin codes. Not to say that everything
else made perfect technical sense, but they tried harder than most.

--
__ __
#_ < |\| |< _#
 
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.

Don't provide a way for the second one to update the first, so that the
first has to be updated on site (though why an update should ever be
necessary, is beyond me - how hard is it to get such things right in the
first place?).

Of course, the temptation is to use one processor for both, because
doing that saves money.

Given the customers that these companies are dealing with, they
probably mark up the cost of their systems by some unjustifiable
multiple anyway.

--
__ __
#_ < |\| |< _#
 
On Sat, 28 Sep 2019 23:58:16 +0000 (UTC), not@telling.you.invalid
(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.

Don't provide a way for the second one to update the first, so that the
first has to be updated on site (though why an update should ever be
necessary, is beyond me - how hard is it to get such things right in the
first place?).

Of course, the temptation is to use one processor for both, because
doing that saves money.

Given the customers that these companies are dealing with, they
probably mark up the cost of their systems by some unjustifiable
multiple anyway.

Best traffic lights I came across were mechanically timed and set so
if you stayed at speed limit you got a green light every time, ok at
night time a bit senseless, but only once, then once onto a route
number (Auckland has/had easy to follow numbered routes to take) no
more red lights.
If you sped you went from one red light to another.

Of course nowadays when nothing was broken it had to be "fixed" to
running with no rhyme nor reason
--
Petzl
Good lawyers know the law
Great lawyers know the judge
 
snip

Best traffic lights I came across were mechanically timed and set so
if you stayed at speed limit you got a green light every time,

When ASIO gave you your top secret direct hot-line batphone didn't they
give you the code to turn all the traffic lights on your trip green? I
got the code when I joined the 'Stonecutters' of course I have to put it
in backwards as they drive on the wrong side of the road.
 
On Sun, 29 Sep 2019 10:55:58 +1000, Dechucka <Dechucka1@hotmail.com>
wrote:

snip

Best traffic lights I came across were mechanically timed and set so
if you stayed at speed limit you got a green light every time,

When ASIO gave you your top secret direct hot-line batphone didn't they
give you the code to turn all the traffic lights on your trip green? I
got the code when I joined the 'Stonecutters' of course I have to put it
in backwards as they drive on the wrong side of the road.

Can't do that with mechanical lights
They do, do this in Sydney which has controlled lights for when he and
his druggy mates drove from Canberra to Kings Cross the "biggest bed
in Australia" where the limo parked in no parking zone underneath it's
veranda
--
Petzl
As Winston Churchill once said;

The Monarchy is important,
not for the power it wields,
but for the power it denies others”.
 
On 29/09/2019 12:39 pm, Petzl wrote:
On Sun, 29 Sep 2019 10:55:58 +1000, Dechucka <Dechucka1@hotmail.com
wrote:

snip

Best traffic lights I came across were mechanically timed and set so
if you stayed at speed limit you got a green light every time,

When ASIO gave you your top secret direct hot-line batphone didn't they
give you the code to turn all the traffic lights on your trip green? I
got the code when I joined the 'Stonecutters' of course I have to put it
in backwards as they drive on the wrong side of the road.

Can't do that with mechanical lights

Sydney lights are electronic, that's how the globes light on

They do, do this in Sydney which has controlled lights for when he and
his druggy mates drove from Canberra to Kings Cross the "biggest bed
in Australia" where the limo parked in no parking zone underneath it's
veranda

Hey don't dis Fred Nile
 
On 29/9/19 12:39 pm, Petzl wrote:
On Sun, 29 Sep 2019 10:55:58 +1000, Dechucka <Dechucka1@hotmail.com
wrote:

snip

Best traffic lights I came across were mechanically timed and set so
if you stayed at speed limit you got a green light every time,

When ASIO gave you your top secret direct hot-line batphone didn't they
give you the code to turn all the traffic lights on your trip green? I
got the code when I joined the 'Stonecutters' of course I have to put it
in backwards as they drive on the wrong side of the road.

Can't do that with mechanical lights
They do, do this in Sydney which has controlled lights for when he and
his druggy mates drove from Canberra to Kings Cross the "biggest bed
in Australia" where the limo parked in no parking zone underneath it's
veranda

Watch out Pizzle, don't the Jews control the traffic lights?
 
On 29/09/2019 4:29 pm, Henry Briggs wrote:
On 29/9/19 12:39 pm, Petzl wrote:
On Sun, 29 Sep 2019 10:55:58 +1000, Dechucka <Dechucka1@hotmail.com
wrote:

snip

Best traffic lights I came across were mechanically timed and set so
if you stayed at speed limit you got a green light every time,

When ASIO gave you your top secret direct hot-line batphone didn't they
give you the code to turn all the traffic lights on your trip green? I
got the code when I joined the 'Stonecutters' of course I have to put it
in backwards as they drive on the wrong side of the road.

Can't do that with mechanical lights
They do, do this in Sydney which has controlled lights for when he and
his druggy mates drove from Canberra to Kings Cross the "biggest bed
in Australia" where the limo parked in no parking zone underneath it's
veranda

Watch out Pizzle, don't the Jews control the traffic lights?

That's why us Gentiles get a better run from sunset Friday till the 3
stars on Saturday night
 
On Sun, 29 Sep 2019 16:29:55 +1000, Henry Briggs <HJBriggs@gmail.com>
wrote:

On 29/9/19 12:39 pm, Petzl wrote:
On Sun, 29 Sep 2019 10:55:58 +1000, Dechucka <Dechucka1@hotmail.com
wrote:

snip

Best traffic lights I came across were mechanically timed and set so
if you stayed at speed limit you got a green light every time,

When ASIO gave you your top secret direct hot-line batphone didn't they
give you the code to turn all the traffic lights on your trip green? I
got the code when I joined the 'Stonecutters' of course I have to put it
in backwards as they drive on the wrong side of the road.

Can't do that with mechanical lights
They do, do this in Sydney which has controlled lights for when he and
his druggy mates drove from Canberra to Kings Cross the "biggest bed
in Australia" where the limo parked in no parking zone underneath it's
veranda

Watch out Pizzle, don't the Jews control the traffic lights?

More importantly "our" media
--
Petzl
"It cannot be overstated, Bolsheviks committed the greatest human slaughter in modern history, and the fact that the world is largely ignorant
and uncaring about this fact is proof that the global media are in the hands of the perpetrators"

Russian Gulag survivor, novelist, historian, and short story writer. A. Solzhenitsyn - Gulag Archipelago
 
On 29/09/2019 5:23 pm, Petzl wrote:
On Sun, 29 Sep 2019 16:29:55 +1000, Henry Briggs <HJBriggs@gmail.com
wrote:

On 29/9/19 12:39 pm, Petzl wrote:
On Sun, 29 Sep 2019 10:55:58 +1000, Dechucka <Dechucka1@hotmail.com
wrote:

snip

Best traffic lights I came across were mechanically timed and set so
if you stayed at speed limit you got a green light every time,

When ASIO gave you your top secret direct hot-line batphone didn't they
give you the code to turn all the traffic lights on your trip green? I
got the code when I joined the 'Stonecutters' of course I have to put it
in backwards as they drive on the wrong side of the road.

Can't do that with mechanical lights
They do, do this in Sydney which has controlled lights for when he and
his druggy mates drove from Canberra to Kings Cross the "biggest bed
in Australia" where the limo parked in no parking zone underneath it's
veranda

Watch out Pizzle, don't the Jews control the traffic lights?

More importantly "our" media

How do they do this? Who are the Jews behind it, maybe Soros? BTW you do
know Thunburg is a Jewish name shortened from Thunburgstein don't you?
 
On Sun, 29 Sep 2019 17:28:58 +1000, Dechucka <Dechucka1@hotmail.com>
wrote:

On 29/09/2019 5:23 pm, Petzl wrote:
On Sun, 29 Sep 2019 16:29:55 +1000, Henry Briggs <HJBriggs@gmail.com
wrote:

On 29/9/19 12:39 pm, Petzl wrote:
On Sun, 29 Sep 2019 10:55:58 +1000, Dechucka <Dechucka1@hotmail.com
wrote:

snip

Best traffic lights I came across were mechanically timed and set so
if you stayed at speed limit you got a green light every time,

When ASIO gave you your top secret direct hot-line batphone didn't they
give you the code to turn all the traffic lights on your trip green? I
got the code when I joined the 'Stonecutters' of course I have to put it
in backwards as they drive on the wrong side of the road.

Can't do that with mechanical lights
They do, do this in Sydney which has controlled lights for when he and
his druggy mates drove from Canberra to Kings Cross the "biggest bed
in Australia" where the limo parked in no parking zone underneath it's
veranda

Watch out Pizzle, don't the Jews control the traffic lights?

More importantly "our" media

How do they do this? Who are the Jews behind it, maybe Soros? BTW you do
know Thunburg is a Jewish name shortened from Thunburgstein don't you?

Thunburg maybe don't think so
--
Petzl
"It cannot be overstated, Bolsheviks committed the greatest human slaughter in modern history, and the fact that the world is largely ignorant
and uncaring about this fact is proof that the global media are in the hands of the perpetrators"

Russian Gulag survivor, novelist, historian, and short story writer. A. Solzhenitsyn - Gulag Archipelago
 
snip

Watch out Pizzle, don't the Jews control the traffic lights?

More importantly "our" media

How do they do this? Who are the Jews behind it, maybe Soros? BTW you do
know Thunburg is a Jewish name shortened from Thunburgstein don't you?

Thunburg maybe don't think so

What don't you think?
>
 
On 9/28/2019 9:22 PM, Sylvia Else wrote:
On 28/09/2019 7:25 pm, news18 wrote:
On Sat, 28 Sep 2019 12:31:42 +1000, Sylvia Else wrote:

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-
statements/network-extensions


In theory, this shouldn't present that much of an issue. Take traffic
lights, for example.

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.

Don't provide a way for the second one to update the first, so that the
first has to be updated on site (though why an update should ever be
necessary, is beyond me - how hard is it to get such things right in the
first place?).

Of course, the temptation is to use one processor for both, because
doing that saves money.

Sylvia

[*] Or 3, configured so that any 2 can determine which lights are on,
providing both redundancy and protection from a single one going rogue
due to a fault.

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.
 
On 30/09/2019 8:15 pm, keithr0 wrote:
On 9/28/2019 9:22 PM, Sylvia Else wrote:
On 28/09/2019 7:25 pm, news18 wrote:
On Sat, 28 Sep 2019 12:31:42 +1000, Sylvia Else wrote:

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-
statements/network-extensions


In theory, this shouldn't present that much of an issue. Take traffic
lights, for example.

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.

Don't provide a way for the second one to update the first, so that
the first has to be updated on site (though why an update should ever
be necessary, is beyond me - how hard is it to get such things right
in the first place?).

Of course, the temptation is to use one processor for both, because
doing that saves money.

Sylvia

[*] Or 3, configured so that any 2 can determine which lights are on,
providing both redundancy and protection from a single one going rogue
due to a fault.

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.

Sylvia.
 
On 9/30/2019 9:28 PM, Sylvia Else wrote:
On 30/09/2019 8:15 pm, keithr0 wrote:
On 9/28/2019 9:22 PM, Sylvia Else wrote:
On 28/09/2019 7:25 pm, news18 wrote:
On Sat, 28 Sep 2019 12:31:42 +1000, Sylvia Else wrote:

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-
statements/network-extensions


In theory, this shouldn't present that much of an issue. Take traffic
lights, for example.

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.

Don't provide a way for the second one to update the first, so that
the first has to be updated on site (though why an update should ever
be necessary, is beyond me - how hard is it to get such things right
in the first place?).

Of course, the temptation is to use one processor for both, because
doing that saves money.

Sylvia

[*] Or 3, configured so that any 2 can determine which lights are on,
providing both redundancy and protection from a single one going
rogue due to a fault.

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.

If you can't defend your own system, you are stuffed, there are plenty
of ways of making such keys unobtainable to outsiders.

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.

Sylvia.
 

Welcome to EDABoard.com

Sponsor

Back
Top