4168 posts • joined 9 Mar 2007
One solution for it is obvious
Just track the eyes, then have 2 screens for your eyes, one that's low res and large for the background, and one higher resolution one which is optically placed at the point where you see the sharpest and at a focal distance that's close to the object you're looking at.
This would dramatically cut back the amount of data you need to generate.
Why stop there?
Re: Anyone seen a single line C program ?
That's actually something companies do in the car industry. They have to give out the code for contract reasons, but then they uglify it before sending it out for insanity reasons.
Re: Trivial? Hmmm.
"For instance, one might need to program X-Y-Z axis motion with millisecond accuracy to control log and saw movement in a sawmill."
Yes, but a millisecond is a long time in a computer, and any cheap microprocessor will guarantee you timing that precise easily. In the end 99% of it is nothing more than control loops with the desired input changing at times. The actually complex stuff is not done by the SCADA people, the complex stuff is done by the people working out the best processes. Whatever they find out usually is just a bunch of numbers the SCADA people code into their software. (or have as settings)
SCADA systems typically are fairly trivial at their core, you only need to gather, display and perhaps log data. The logic to act uppon is so simple that most of those systems could be implemented with simple analog cicruity. In the hands of not quite mature programmers that's actually very dangerous as they will try to fill the boredom and come up with terrible ways to do trivial things....
.... one of those ways is OPC or OPC-UA which offers a highly complex object oriented broker like structure to distribute values and events. It nicely fills the void of boredom and keeps those programmers occupied re-implementing complex interfaces instead of simply pushing around lines of text. This however fills experienced programmers with disgust, so they tend to not want to touch this. The end result is that you have lots of inexperienced programmers trying to solve problems you wouldn't have if they were more experienced in the first place. However most experienced programmers will either leave your project or not even get anywhere close to it.
Now add mobile apps and you get the intersection between app developers and people who touch SCADA with a not to long stick, and you'll probably get only the worst of developers out there.
They are already using it for decades.
Traffic analysis, even of encrypted traffic has been done for decades if not centuries. Workarounds for it also have been deployed for those times. A good example are "number stations". Those broadcast messages encrypted as numbers. If they would broadcast only when something has happened, the opponent could determine the amount of "chatter". Therefore they broadcast at precise schedules.
A simmilar thing has been done during the cold war. You make a passenger plane steer a bit into enemy country, then look at where you suddenly get radar pulses from you previously didn't. Those are previously hidden radar stations. If your enemy is rather stupid you can even find new radio communications links being established.
Well Cisco wants to make more money
Obviously you cannot get richt just by selling those (probably already overpriced) products. You can get way more money by selling customers data.
It's not that hard
"Can someone explain how, if this works"
Imagine going do a map service website over https. Your browser will load the tiles from the website over TLS links. In the extreme case of bad HTTP(s) implementations, you create a connection, send your get, and get your tile. Since it's encrypted you don't know what's inside that tile.
However all those tiles are encoded in JPEG (or PNG) which means that their filessizes differ. Encryption doesn't obscure the filesize so you'll be able to see how big that tile was. Since your browser likely loads tiles from roughly the same location, you can use the file sizes to find out what tiles were loaded.
With malware the hope is that the malware will always behave predictibly. For example an initial state always loads a secondary stage that is 123532 octets big, then after 3,21 seconds a terciary stage that's 4235431 octets in size. The idea is that if you 2 downloads 3,21 seconds appart of those sizes in succession, you'll have detectet the malware...
...obviously that's extremely trivial to circumvent, just add padding or other forms of randomness.
This is not a new attack for encryption, but a common thing encryption cannot do by itself.
Re: Yes, there are concepts for that...
"the typical required level of effort"
We are talking about software here, not locks. You only need to put in the effort once. Compared to the other efforts you need to put in (like writing a CNC-Server, designing protocols, etc) this is only a tiny amount of extra effort, and no extra effort per use. It's just a minor change to a tool.
The "lock" analogy is rather bad here, as with locks you have a few generic tools which require lots of effort per use, with IT security it's usually the other way round, all the effort goes into making those tools, using them is comparatively simple.
Re: Yes, there are concepts for that...
"Problem is, in cyberspace, burglars tend to blog their exploits,"
Actually one of the first things you learn at any decent cyber security course is how to circumvent malware scanners. It's something we teach early on to make sure they understand that those solutions cannot work.
Re: Yes, there are concepts for that...
"Will it rise the difficulty of entry beyond what typical burglars are willing to deal with?"
Well actually probably not, because it's not much effort to randomize your traffic. Essentially it's a few random sleeps here and there and some calls to random() instead of using constant values. It takes maybe 10 minutes to circumvert such a problem, and it'll probably take days for companies like Cisco to catch up.
This is not "one lock" you need to stand 10 minutes in front of, this is 10 minutes for a solution which works globally.
Yes, there are concepts for that...
... but no, they don't really work against malware.
Essentially the idea is that you could fingerprint certain traffic patterns, just like you can fingerprint the HTTP-requests going out from visiting a website. That way you can, for example, determine what Google-Maps place people are looking at....
However we are talking about malware here. The attacker will just get one of those systems and tweak their malware until it won't get detected anymore. Or they will randomize and adapt their traffic so much, there is no way to differentiate it from normal web traffic.
So as with many such ideas, it's great for any oppressive government, but rather useless for security.
Ohh and don't forget REDABAS
The "Relationales Datenbanksystem" from Robotron from the GDR. It was 100% compatible to dBase II (and later III). Even the binary offsets usually were the same.
Well there are also missing dBase and Paradox
I'm sure both are in the same range as Oracle. I mean one rarely hears about Oracle after they lots that gig providing Teletext to ITV.
...actual mobile device security is so bad that, given some effort, you could probably break it.
I mean look at areas where manufacturers actually care about "security": Games Consoles. Despite those using sophisticated measures to prevent you from using them yourself, they regularly get broken.
Just look at any of the papers or talks about console hacking:
There is little reason to believe that smartphones have better "security".
It's an obvious mistake to make
I mean surely as the NSA I would try to "nudge" the processor designers into not looking into the ramifications of having speculative branching and caching.
I could very well understand that they simply didn't care about that in 1995 as, most computers running Intel CPUs were simple single-user machines with protected mode only seen as a crash containment technology, not as a security feature.
Re: What Annoys Me...
No, first of all the problems are different, it's a class of problems nobody bothered looking for, so obviously you will find them at virtually every processor manufacturer using out of order execution as well as some sort of MMU.
Just like in early cryptography many different people were making the same mistakes.
Re: THAT Price for one View?
Well believe me, our stations also pay insane amounts of money. It's just that the valuable games varry from region to region.
Re: only one name?
I'd actually say that more most professional users thickness is completely irrelevant. It's not like you're going to put your laptop into an envelope, or cram 10 of them into a backpack.
An easy to replace battery and an ethernet port are _much_ more useful than shaving off a couple of centimetres.
I mean I distinctly remember from a BBC documentary that Game of Thrones was written by Shakespeare and that he's already dead. So how can he write new things?
Also what has this to do with HBO, doesn't John Snow work for Channel 4? (actually probably ITN)
Re: Not only Chip Makers...
Well if the sandboxing depends on broken features of your CPU, then one CPU problem can cause all of that. We need to finally accept that running untrustable code from webservers on the client was a _really_ bad idea.
Hmm, If I was working at a secret agency
I would be trying to make sure CPU designers "overlook" that problem deliberately. I mean all CPU vendors have plausible deniability since this could just as likely have been an accident.
It's just like UEFI or ME. It looks like simple stupidity, but it greatly benefits certain agencies.
Re: Not only Chip Makers...
Well languages are essentially created equal, while exploits using this in JS might be less stable, there is no hard reason why it shouldn't be possible. After all, you only need attempts at memory access.
Re: " don't run untrusted code"
"For 99.9% of the planet that could be tricky."
That's actually a very big problem. For years people have believed that you can somehow "sandbox" code, so it won't be able to harm your system, and for years people have warned that this might be an illusion. Now we actually see yet another proof that it was.
This is why FOSS hardware designs...
are actually working on verifying that the designs are correct.
Re: Can't we just get rid of UEFI?
"trying for things like built-in OS-agnostic drivers"
That's a feature in "Open Firmware" which typically was around 20-30 kilobytes of Forth code. It's not hard to do that. BTW even the old BIOS provided that in some limited form. It was good enough to have a GUI installer with access to the graphics mode of graphics cards.
Re: Can't we just get rid of UEFI?
Well you can rationalize that "feel".
Essentially the biggest problem in IT is complexity. Complexity means high costs when you develop something, high costs for maintain it, as well as lots of bugs, both security critical or not. Therefore it is wise to avoid it.
On the other hand, changes can mean new features. A wise person would weigh those features against the cost of complexity and choose accordingly. Dumb persons ignore the cost of complexity.
UEFI is a typical example where it does add magnitudes of complexity, while essentially doing exactly the same as the old BIOS. There is very little on the "feature" side, but a lot on the complexity side.
UNIX has lots of features which are the opposite. Features like piping are of only minor complexity cost, but allow the functionality to explode. Just add a tiny bit of code to your software, code you often need anyway, and it can be easily combined with other programs.
Can't we just get rid of UEFI?
It simply is, and always was, a phenomenally bad idea. Just scrap it and build something based on OpenFirmware, which is small, functional and makes it easy for an OS to use its features.
8 times longer battery times in mobile phones
I find that highly dubious as we could already have much longer battery times if we just fitted propper batteries and used propper operating systems.
For example hackerspaces have the problem that they want multiple people to get in and they want to be able to grant and revoke access easily. An electric lock would be ideal for them...
...however this consumer oriented product surely wouldn't do as it probably relies on external services/software to set it up.
Hackerspaces usually have their own version of this, made from the mechanical guts of commercial solutions with some self-made electronics.
That seems fast
Mobile phone generations usually are roughly 10 years appart. GSM came out around 1990 and first design studies have been made in the early 1980s. 3G came out around 2000, based on the ideas of the early 1990s. (that's why 3G standards originally didn't have packet modes, only isochronous streams)
"Stick a LED under each key and the battery life is dramatically cut. - Unacceptable"
Actually no, if you that you can radically reduce the brightness of every LED and therefore radically reduce the power you need to drive it. In essence it doesn't matter how many LEDs you need, what matters is the total amount of light you need.
The Pyra, for example, uses a middle ground. It uses some LEDs for the keyboard, with a diffuser in between.
We'd need a truely free browser
unfortunately instead of making the web better, Mozilla actively works on new ways to extend the complexity of browsers, making sure the oligopoly of browser engines still holds.
Re: Now this would be a great idea...
"The article itself notes that DNSSEC doesn't help if the ISP is willing to block DNSSEC at its level by port-checking"
Considering that in most countries where ISPs block DNSSEC or external DNS queries, they also likely break HTTPS, I don't think it's much of an advantage.
Re: Now this would be a great idea...
"ALL cryptography is complex*. There are so many ways to get it wrong in lots of non-obvious ways."
Yes, but putting ASN.1 into it certainly doesn't make it easier.
Now this would be a great idea...
...if HTTPs wasn't built on TLS for these reasons:
1. TLS is to complex to be implemented without security critical bugs, so in the end this may enable all kinds of attacks. Remember Heartbleed?
2. TLS is based on CA infrastructures which only are safe, when every single CA is safe. Though you can work around this by having your own CA for DNS.
It just seems like DNSSec would solve most of those problems with far less effort.
Re: Well so where's the problem?
"but I'm not aware of any laws anywhere giving an end user the right to root access on computer controlled devices."
Actually the German constitutional court derived the right of "Integrity and secrecy of information processing systems" some years ago. Just because there aren't any explicit laws, doesn't mean you don't have a right.
Well so where's the problem?
Those boxes are strictly in the local network an if I pay for that device I damn well have every right to be root on it.
It should be noted that the most likely attacker (the vendor) probably already has root access in the form of potentially malevolent firmware updates. There have been many examples of vendors taking away features or deliberately or accidentally bricking devices. That seems to be much more common than fixing actual security bugs.
If ME would be the first feature Intel wouldn't charge extra
I mean, OK, there are actually reasons for wanting to have ME, but so far Intel has chosen to charge extra for every desirable feature. Want ECC-RAM, get a server chip, want virtualisation, get a server chip.
Re: Internet-Email is so much simpler than X.400.
Well actually integrity is provided in E-Mail by PGP... which essentially encodes your UTF-8 text into ASCII Text, at minimal complexity.
That's why one should reduce the total complexity
Just outsourcing complexity to libraries won't make it go away. That's why movements to increase complexity, from HTTP/2 to ME are so problematic.
The Internet was created as a way to reduce complexity, Internet-Email is so much simpler than X.400. HTTP/HTML used to be simple protocolls you could implement easily.
So to summarize: Complexity is bad, there may be good reasons to add some complexity, but without a _really_ good justification you shouldn't add more complexity to any system.
Why did they even choose Java?
I mean, seriously most Apps either are so trivial they could be written in some cut-back GUI language, or they deliver their code as a binary blob of machine code.
Now the big problem with using Java or any other "modern" "OOP" language is that its programmers typically haven't reached a level of maturity yet where they understand that complexity is evil. Therefore you have dozends of components involved in doing simple things like turning on the vibrator motor. The result is a fairly slow system, full of security critical bugs.
Networks cannot provide "security"
As obviously everyone can just sniff the lines, and the network provided encryption has encryption keys inside the network.
The big problem is billing, you could be falsely billed for something.
Re: We do. It can't cover everything.
"Aside from that, the CPU often isn't even involved as these are DMA transfers."
Obviously the DMA also would need to comply to this, you couldn't just plug in any old PCI-card.
Re: maybe ... just maybe we need better hardware ?
"I'm not sure I agree. Would this mean that more hardware is out of the control of the user/administrator? Imho, that would be the last thing we need. I don't want more ME type issues. "
No, ME/SecureBoot/etc aren't security features. This would work a lot more differently.
Essentially you'd have something like tagged type architectures where the CPU stores values along with their types. Essentially the CPU would be able to know where memory areas end. Additionally you could add tags like "private, not to be put on the network", and functions that encrypt data could add an "encrypted data" tag to it. That way you could put a filter on your network card to only let out private data that's encrypted. Such filters could even work in hardware.
However the big problem is that you loose all compatibility with existing systems. Considering the number of written from scratch full blown operating systems having been developed in the last 20 years was 0, that's quite some work to do.
It's a basic problem with "security software"
Any increase in complexity means more bugs and more security critical bugs. In "security software" this is particularly bad, as that software handles data you otherwise wouldn't handle.
(half OT) I think it was some police in Germany that seriously considered patrouling the streets via StreetView.
Re: Mistrust goes in what direction ?
"And, like with DRM, I fail to see why I'd want to pay extra money to have diminished authority over my possessions."
Because it's capitalism, and capitalism in an industrialized world means that they can dictate what products are available.
Looks like a toy
that could be rather fun, once you hack it and replace the controller/firmware with something more fun/useful
Ultrasound might be more reliable
You could make that sensor hit a little "bell" which creates an ultrasound ring. Unlike this, it doesn't need to be in a field to create a "backscatter" signal, but could actively transmit a signal by siphoning energy from the squirting.
Early remote controls in the US were made that way. You pushed a button and a little ultrasonic glockenspiel would go off. Later those were replaced by transistorized generators.