Re: Access control for IoT

Tony Arcieri <[email protected]> Mon, 18 Jan 2016 10:59:44 -0800
Newsgroups gmane.comp.capabilities.general
Message-ID <CAHOTMVKRm=kvsHd+_FMKmJJN+Qi7RMMFodf4M4sMV0kDw_E7Sw@mail.gmail.com>
--===============7545796788656516357==
Content-Type: multipart/alternative; boundary=001a1136ae7c5688ba0529a05c72

--001a1136ae7c5688ba0529a05c72
Content-Type: text/plain; charset=UTF-8

On Mon, Jan 18, 2016 at 10:42 AM, Valerio Bellizzomi <[email protected]>
wrote:

> most devices used for IoT come with 32K of memory, do not run true
> operating system, they run small programs that provide only the required
> control/information functionality. Those devices have ethernet or wifi
> links. How do you implement access control given that the device will
> connect to a local server?


As I said in my last message:


> > All that said, as far as I can tell there really isn't anything to
> > recommend so far that remotely resembles a real option in this space. The
> > best I can recommend are half-baked research projects.


As to how these research projects are trying to solve these constraints:

- Minimize cryptographic primitives: instead of bundling both a hash
function and symmetric cipher (possibly as hardware), use a hash function
to implement an Even-Mansour stream cipher
- Minimalistic transport encryption: abandon TLS and ship a tiny,
constrained transport encryption protocol
- Software update framework: support incremental download, data-at-rest
authentication, and reflashing of device firmware with a fallback to the
old firmware on error

Even without the IoT constraints these are challenging engineering goals in
and of themselves. I'll point to transport encryption (specifically key
exchange) as the thing that's most routinely screwed up with homebrewed
protocols.

Just getting the above right forms the baseline of a secure system, and is
already exceedingly difficult to the point few systems manage to do it in a
remotely secure manner. User-friendly access control is gravy.

-- 
Tony Arcieri

--001a1136ae7c5688ba0529a05c72
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Jan 18, 2016 at 10:42 AM, Valerio Bellizzomi <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">most devices used for I=
oT come with 32K of memory, do not run true<br>
operating system, they run small programs that provide only the required<br=
>
control/information functionality. Those devices have ethernet or wifi<br>
links. How do you implement access control given that the device will<br>
connect to a local server?</blockquote><div><br></div><div>As I said in my =
last message:</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span cl=
ass=3D"im HOEnZb">&gt; All that said, as far as I can tell there really isn=
&#39;t anything to<br>
&gt; recommend so far that remotely resembles a real option in this space. =
The<br>
&gt; best I can recommend are half-baked research projects.</span></blockqu=
ote><div><br></div><div>As to how these research projects are trying to sol=
ve these constraints:=C2=A0</div></div><div class=3D"gmail_extra"><br></div=
>- Minimize cryptographic primitives: instead of bundling both a hash funct=
ion and symmetric cipher (possibly as hardware), use a hash function to imp=
lement an Even-Mansour stream cipher</div><div class=3D"gmail_extra">- Mini=
malistic transport encryption: abandon TLS and ship a tiny, constrained tra=
nsport encryption protocol<br clear=3D"all"><div>- Software update framewor=
k: support incremental download, data-at-rest authentication, and reflashin=
g of device firmware with a fallback to the old firmware on error</div><div=
><br></div><div>Even without the IoT constraints these are challenging engi=
neering goals in and of themselves. I&#39;ll point to transport encryption =
(specifically key exchange) as the thing that&#39;s most routinely screwed =
up with homebrewed protocols.</div><div><br></div><div>Just getting the abo=
ve right forms the baseline of a secure system, and is already exceedingly =
difficult to the point few systems manage to do it in a remotely secure man=
ner. User-friendly access control is gravy.</div><div><br></div>-- <br><div=
 class=3D"gmail_signature">Tony Arcieri<br></div>
</div></div>

--001a1136ae7c5688ba0529a05c72--

--===============7545796788656516357==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk

--===============7545796788656516357==--