Wanted: sub-$10 *networked* boards

USB hardware is very cheap (no magnetics, low power) and usually present all but the cheapest SoCs, so why not do IP over USB directly without messing around with Ethernet?  With 10baseT and higher you need an Ethernet hub or switch anyway, and you could fairly easily make an IPoUSB bridge/router that has a bunch of USB host ports to connect to your devices plus an Ethernet up-link.  The b/router would perform the polling needed to see if devices have upstream IP packets.

I thought something like this might be a nice way to network a classroom filled with RasPi Model A boards.

I've heard lots of talk about the Internet of Digital Things (IDioT), but I haven't seen standards or chips for handling the 'torking (my first neologism for 2014, an abbreviation of "networking" based on its common Internet mis-spelling "newtorking").

Regarding Internet of Things, stripping off all the frills and hype and decoration (we're pretty immune to hype anyway here, fingers crossed), it's just IPv6 on everything at extremely low cost through integration.  Viewed that way, IoT documentation is already 100%.  (IoT organizations typically push IoT middleware, but that's actually just decoration around what is no more than plain IP.)

Note: IoT on IPv4 is just a wave to the past so that the poor old 98% of IP users don't feel too disenfranchised.

Note that my $10 goal doesn't come even close to embracing IoT in a proper way.  The aim should be sub-$1 if networking is to be omnipresent in everything that isn't by design isolated permanently.  (There are many extremely important applications where such isolation by design is important, indeed crucial, particularly in this post-Snowden era).  Sub-$1 IoT devices are perfectly possible even today, given that many microcontroller families have members that cost a fraction of a dollar.  But for 2014, I'm happy to aim towards just the relatively unambitious $10 niche.

So, don't get hung up by IoT vendor machinations and nods to the past.  It's just highly integrated IPv6.

Morgaine.

John Beetem wrote:

Morgaine Dinova wrote:

 

Yes you do! 

Oh no, I don't

Touche'!

< Rest of infinite-length cultural exchange elided through Run-Length Encoding. >

There are two kinds of devices: isolated devices and hackable devices.

That's actually very accurate, and insightful.

But wait, what's an "isolated" device?  The NSA is crossing air gaps these days with quite awesome (in the sense of "psychopathic") side-channel attacks.  We're going to have to modify your observation just a little:

There are two kinds of devices: output-only devices and hackable devices.

(Fully isolated devices aren't actually in your universe, so we needed to make the tenet more useful.)

This shackles us a bit, umph!  (And I'm not yet ready to deal with the related reports of SoC hardware containing hacks or deliberate weakening of security at gate level, which may reduce everything to "hackable".  Yes, we have to deal with this issue, but one thing at a time.)

Output-only isn't a complete barrier to powerful networking, it just requires understanding that protocol data received back during a protocol exchange doesn't need to feed back to the source of the payload.  As an example from years gone by, when a DTE receives CTS from a DCE to indicate that it can send the DCE data, the CTS clearly has limited potential to affect the payload because RTS/CTS is side-channel signaling.  This continues to be true when in-channel flow-control is used and a stop byte is sent back from the DCE to hold off DTE transmission -- the start/stop machinery can be completely separate from the source of the data, and hence intrinsically isolated from operation of the DTE equipment.  It's true that the messaging can be subverted by MITM or other means so that the external world sees the wrong information, but at least your networked but output-only furnace won't be told to burn your house to the ground.

Exactly the same is true in an IP instead of RS232 scenario.

Moving to the case of bidirectional monitoring and full control, the situation isn't as bleak as it might seem from the unfortunately true observation that "everything connected is hackable".  There are in the universe these beings called "engineers", and they're not all stupid.  In fact, many of them can focus on issues very clearly and ensure that certain requirements are met, provably so, such as isolation requirements at one level despite equipment being connected at a lower level.  And yeah, that's what we're here for, to safeguard the world from itself.

There's a lot to be said for caution, especially after a very worrying 2013, but I think we're very far away from giving up and admitting defeat just because there are bad people out there wanting to subvert our equipment.  It's an arms race, I agree, but with good design and avoiding development that blindly embraces "cool", we aren't yet bludgeoned into a corner of hopelessness.

Morgaine.

Morgaine Dinova wrote:

• Your TV and TV usage would benefit enormously from full-capability IP networking.

Actually it would be highly detrimental. As it would require owning a TV to begin with

• Your central heating furnace can work far more efficiently when networked to sensors throughout the house, and even more efficiently when it can control radiators and hot air ducts to direct heat where needed.  In fact it's always connected to at least one thermostat if it was manufactured in the last millennium, and IP networking just adds greater capability to it, for your benefit.

While I might agree in principle that it would be useful to have heating networked to various sensors in order to make things more efficient, I most certainly want that network fully isolated from everything else, especially the internet.  The idea that someone could compromise the system, turn the heating off causing burst pipes and all sorts of damage isn't a good one. Equally someone could turn it on causing large and unwanted energy bills.

There's a range of other similar things where the idea of networking is really good, but the likely abuse of that capability is a problem.

Morgaine Dinova wrote:

There are in the universe these beings called "engineers", and they're not all stupid.  In fact, many of them can focus on issues very clearly and ensure that certain requirements are met, provably so, such as isolation requirements at one level despite equipment being connected at a lower level.  And yeah, that's what we're here for, to safeguard the world from itself.

From an engineering perspective I agree. Unfortunately engineers are regularly overruled for 'business' reasons, or simply not given the time/budget to do the right thing, or even forced to implement requirements that are detrimental to the end users security/privacy.

Then there's the problem of governments deliberately subverting things which is difficult to deal with.

Agreed on all points.  Indeed I mentioned every single one earlier.

But don't throw the baby out with the bathwater.  Network defeatism isn't called for yet.  There's a lot that good engineers can do to reduce risks to almost nothing through effective design with security as a #1 requirement.  The main difficulty may be to summon up the courage to tell management that no, low-cost insecure crap and wishful thinking is not a design option for us.  Yes, it can have a personal cost, but knowingly doing wrong does as well.

Morgaine.

Morgaine Dinova wrote:

 

The main difficulty may be to summon up the courage to tell management that no, low-cost insecure crap and wishful thinking is not a design option for us.  Yes, it can have a personal cost, but knowingly doing wrong does as well.

One disagreement I had with management at one of my favorite jobs was that he wanted to toss out our in-house software, for which we had full source code and institutional knowledge, and replace it with a standard RTOS and purchased comm stacks.  The salesmen of said products assured him that it was trivial to merge them into our product.  I managed to stave off this catastrophe while I was with the company, but when I left to try some new things they went with the RTOS plus purchased stacks and a few years later actually had it working

However, usually management wins the battle right away and you're stuck with a purchased product with opaque stacks.  Go try to find the security flaws in those suckers, even if you have the 3 million lines of source code.

Regarding provability of software: good luck.  I took John McCarthy's Recursive Programming and Proving course at Stanford (though not from Dr. McCarthy himself).  One of the nastiest assignments was proving that two versions of a simple list reverse function were equivalent.  I suppose software proving has improved a little since then, but the cleverness of hackers has improved much more from what I can tell.  JMO/YMMV

I've always enjoyed reading "locked room" mysteries, where the victim has apparently committed suicide in a room locked from the inside.  However, it's always a case of murder, a fiendishly clever murder, and there's always a physical opening somewhere.  It's not a truly "locked room" unless there is no opening whatsoever, no matter how small.  The master of these mysteries is John Dickson Carr, who also wrote as Carter Dickson.

Using the same cleverness, a hacker can get in though amazing openings.  But there's no reason to leave doors and windows wide open.

Haha, indeed.  Alas, managers are often easily deceived by snake oil merchants, especially those that say "Just pay us X and we'll handle all your problems".  Also, the prospect of blaming an external third party is very enticing compared to accepting that your own team is at fault and that therefore you carry part of the blame.  As a contractor, I've met so many different managers that I recognize that there is no simple reason for management "doing the wrong thing", and they're certainly not all clueless.  Some are extremely alert, well informed and very reasonable, and still do the wrong thing ("wrong" meaning that something or someone is harmed, unnecessarily).  It's complex.

John Beetem wrote:

 

Regarding provability of software: good luck.

Oh I know!   I taught EE final years Software Engineering, and I tried to highlight the (very severe!) limits of our capability, and the fact that there is no silver bullet so a defensive approach is needed at every step.  Engineers seem to understand this intrinsically anyway, possibly because error detection, negative feedback and correction are so engrained in the engineering psyche.  CompSci students have less of this worldview --- it's not quite as bad as "if it compiles, it'll work", but there is an element of uncalled-for optimism there.  Z and VDM may have increased that fantasy a while ago, but not in my class.

But by the same token, there are very good if slightly tarnished bullets of commonsense, and it's trivial to prove mathematically in one line that hacked state X and equipment state Y are disjoint when there is no path between them.  Of course this just passes the buck to the premise, but if that's "obvious" by inspection then commonsense wins.  I'm not defeatist on this at all, because all that's needed is to raise the stakes into "highly unlikely" territory.  It's something that cryptographers don't appreciate being pointed out, but cryptographic security is just security by obscurity with a very low probability of hitting gold by guessing because the space is so large.  It's not intrinsically more secure than obscurity, but just stacks the odds extremely highly in our favour ... as long as you're not using an NSA-endorsed random number generator.

Using the same cleverness, a hacker can get in though amazing openings.  But there's no reason to leave doors and windows wide open.

+1.

Morgaine.

Morgaine Dinova wrote:

 

but cryptographic security is just security by obscurity with a very low probability of hitting gold by guessing because the space is so large.  It's not intrinsically more secure than obscurity, but just stacks the odds extremely highly in our favour

cryptography is Snake Oil..  Even if you can prove the cryptography itself is sound, there's always a 'management' decision lurking in the wings that renders it moot.  Debian ssh key problems, WPS, MD5 collisions, RSA weaknesses, Virtual machine cache timing side channel attacks to recover private keys from a different VM on the same physical hardware.  History is littered with the failures.

Ultimately it's the illusion of security that it provides that's a problem. People assume they're safe

selsinork wrote:

 

cryptography is Snake Oil.

I know what you mean, but careful with putting it just that bluntly because those who don't know the details might think you mean that crypto doesn't work as advertised, and then they won't use it and chaos will ensue.  It's exactly as you say though, that side channels and poor key management and bad policies (and NSA shenanigans) can undermine the properly working crypto.

Ultimately it's the illusion of security that it provides that's a problem. People assume they're safe

It's what Schneier meant when he said that you can't buy security, because it's a process.  Unless you go through the process diligently, all you have is an illusion of security.

Morgaine.

Morgaine Dinova wrote:

 

I know what you mean, but careful with putting it just that bluntly because those who don't know the details

People don't know the details, mostly they don't care either, they see a padlock in the browser and have been trained to associate that with an idea. Whether the idea is true or not isn't relevant.

Even the most superficial look at the details is troubling.

Of course none of that means cryptography is worthless. But does mean that people need to be aware of the pros and cons and understand at least some of the details.

Morgaine Dinova wrote:

 

selsinork wrote:

 

cryptography is Snake Oil.

 

I know what you mean, but careful with putting it just that bluntly because those who don't know the details might think you mean that crypto doesn't work as advertised, and then they won't use it and chaos will ensue.  It's exactly as you say though, that side channels and poor key management and bad policies (and NSA shenanigans) can undermine the properly working crypto.

 

See CVE -CVE-2013-4576 and Acoustic cryptanalysis for another recent example.

Morgaine Dinova wrote:

 

selsinork wrote:

 

cryptography is Snake Oil.

 

I know what you mean, but careful with putting it just that bluntly because those who don't know the details might think you mean that crypto doesn't work as advertised, and then they won't use it and chaos will ensue.  It's exactly as you say though, that side channels and poor key management and bad policies (and NSA shenanigans) can undermine the properly working crypto.

 

See CVE -CVE-2013-4576 and Acoustic cryptanalysis for another recent example.