Re: What could possibly go wrong... ;)

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.

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 f***ed 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.

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

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.

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.

----snip----

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

Are they competent?

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

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

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.

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.

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.

VPN seems easier and almost as good.

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

Sylvia.

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?

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.

-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):

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

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.

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:

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:

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.

No ned to look for quantum computing when there is surplus processing power going to waste on disruptive events at commant (DDOD, etc) that could be put to "good" use as another distributed computing problem, as are a few volantary enrolled computers aimed as "scientific" analysis.

I looked into options when trying to figure out accessing the VPN that Tesla uses to control my Powerwall (no progress made).

I think the factorising problem is so intractable that even using all the conventional computing power in the world can't address it for the currently recommended key length (2048 bits).

Sylvia.

Don't they have a sabath setting like my fridge, :)