[Cryptography] [FORGED] Re: Schneier's Internet Security Agency - bad idea because we don't know what it will do

Kevin W. Wall kevin.w.wall at gmail.com
Mon Feb 27 18:59:22 EST 2017


On Sun, Feb 26, 2017 at 7:28 PM, Peter Gutmann
<pgut001 at cs.auckland.ac.nz> wrote:
> Kevin W. Wall <kevin.w.wall at gmail.com> writes:
>
>>For starters, I'd like to see it mandated that any IoT device that is sold
>>will NOT try to connect to the Internet by default.
>
> That'll never fly, it would take any IoS device and reduce it to just a S
> device.  It looks like you're thinking of "smart" TVs and the like, but most
> IoS devices are "I" so you can monitor and/or control them via your phone, for
> which disabling the I bit defeats the whole point of their existence.  Even
> something like "must be explicitly enabled by the user" doesn't help, because
> no-one's going to not enable it, the whole point of getting it was the I part.

Well, true, I didn't have in mind things like 'sensors' that pretty much
have to communicate to the Internet. But lots of IoT devices really,
really don't unless you intend to use that aspect of their functionality.
E.g., smart refrigerators or ovens. I've even seen ads for "smart" hairbrushes
and vibrators! (Really? Some people _really_ don't care for personal privacy.)

>>Second thing is that they should not be permitted to be sold unless they have
>>a mechanism to update their firmware and they should be required to support it
>>for the expected life of the device (and not just the warranty period).
>
> And then you run into this (scroll down to "Update Mechanism"):
>
> https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project#IoT_Attack_Surface_Areas
>
> The lack if ability to update is actually a security feature in many devices.

Well, sure, if you write a shitty, non-encrypted, non-authenticated update
mechanism, then you certainly adding to the problem, but to me, that's like
arguing that automotive manufacturers shouldn't add safety features like
side air bags because they could accidentally deploy and actually _cause_
a wreck. While I agree that they can add to the attack service, if done
properly, they can also address the other insecure components. So I definitely
would not call it a security "feature" by any stretch. If you do and this
wasn't meant tongue-in-cheek, then I guess we'll just have to agree to
disagree here.

>>So for that reason, I'd prefer not to put this into the hands of a regulatory
>>body.
>
> I'm not so much worried about the government-surveillance angle, but more the
> fact that commercial vendors are very good at co-opting regulatory bodies to
> create barriers to entry that lock out anyone but them.

Ah. Excellent point. That too. Of course, that already comes from lobbyists
even when there is no regulatory body, but that probably would make it worse.

-kevin
--
Blog: http://off-the-wall-security.blogspot.com/    | Twitter: @KevinWWall
NSA: All your crypto bit are belong to us.


More information about the cryptography mailing list