Re: Access control for IoT
Matt Rice <[email protected]> Tue, 19 Jan 2016 00:59:47 -0800
| Newsgroups | gmane.comp.capabilities.general |
|---|---|
| Message-ID | <CACTLOFrCu8+wzBtKU-cj1Q_ex3ei-OLYtZw9bvpouxm2xkic6g@mail.gmail.com> |
--===============2179100564561966349== Content-Type: multipart/alternative; boundary=001a11c2eb5a69369a0529ac1798 --001a11c2eb5a69369a0529ac1798 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 18, 2016 at 10:47 PM, Matt Rice <[email protected]> wrote: > > > On Mon, Jan 18, 2016 at 10:16 PM, William ML Leslie < > [email protected]> wrote: > >> >> On 19/01/2016 5:07 pm, "Valerio Bellizzomi" <[email protected]> wrote: >> > >> > well, it is secure as it is, because no one can reflash your device >> > remotely, you have to do it by hand. >> >> There are three vectors that need to be considered here, and for >> different products they each carry different risks. For example, security >> cameras that are outside your house should not be reflashable with physical >> access. >> >> The other two vectors are the automatic update delivery mechanism, which >> is the most scary IMO, and the API the device exposes. >> > FWIW security of remote updates is not exactly a new problem, space craft > has long had the same issue, I'm not sure if the computer history museum > where the last friam was held still has any association with moffet field, > > But I recall from a conversation with someone from there that they > essentially used a jump table I'm not sure how close of an analogy can be > made to the keykos primordial system image though. > > Anyhow it is a well researched field for mission critical applications... > the primary difference is that the remoteness of space makes physical > attacks difficult.. > I should probably elaborate on this, What I recall is that the signal sent authenticate, place parameters in a known location and specify an offset into a jump table then jump to the appropriate location... part of the rationale for this was it was easy to overwrite an entry into the jump table when a signal was no longer going to be sent e.g. because a newer version of that rpc call had been placed in a different offset in the jump table... presumably the authentication mechanism didn't include per-offset/per authority W/X bits since I don't see space programs needing it... nor do I know if they had anything similar to the keykos checkpointing mechanism for working sets... but it seems reasonable to me with an appropriate authentication mechanism the offset into jump table is not terribly dissimilar to a cap id for a fixed number of caps system. I'm guessing its quite possible that there was a distinction between functions that were called by rpc and those that were relied upon by the devices main loop --001a11c2eb5a69369a0529ac1798 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo= te">On Mon, Jan 18, 2016 at 10:47 PM, Matt Rice <span dir=3D"ltr"><<a hr= ef=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>>= </span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .= 8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div = class=3D"gmail_extra"><div><div class=3D"h5"><br><div class=3D"gmail_quote"= >On Mon, Jan 18, 2016 at 10:16 PM, William ML Leslie <span dir=3D"ltr"><= <a href=3D"mailto:[email protected]" target=3D"_blank">william.l= [email protected]</a>></span> wrote:<br><blockquote class=3D"gmail_quo= te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"= ><span><p dir=3D"ltr"><br> On 19/01/2016 5:07 pm, "Valerio Bellizzomi" <<a href=3D"mailto= :[email protected]" target=3D"_blank">[email protected]</a>> wrote:<br= > ><br> > well, it is secure as it is, because no one can reflash your device<br= > > remotely, you have to do it by hand.</p> </span><p dir=3D"ltr">There are three vectors that need to be considered he= re, and for different products they each carry different risks. For example= , security cameras that are outside your house should not be reflashable wi= th physical access.</p> <p dir=3D"ltr">The other two vectors are the automatic update delivery mech= anism, which is the most scary IMO, and the API the device exposes.<br> </p></blockquote></div></div></div>FWIW security of remote updates is not e= xactly a new problem, space craft has long had the same issue, I'm not = sure if the computer history museum where the last friam was held still has= any association with moffet field,<br><br></div><div class=3D"gmail_extra"= >But I recall from a conversation with someone from there that they essenti= ally used a jump table I'm not sure how close of an analogy can be made= to the keykos primordial system image though.<br><br></div><div class=3D"g= mail_extra">Anyhow it is a well researched field for mission critical appli= cations...<br></div><div class=3D"gmail_extra">the primary difference is th= at the remoteness of space makes physical attacks difficult..<br></div></di= v> </blockquote></div><br></div><div class=3D"gmail_extra">I should probably e= laborate on this,<br><br></div><div class=3D"gmail_extra">What I recall is = that the signal sent authenticate, place parameters in a known location and= specify an offset into a jump table then jump to the appropriate location.= ..<br><br></div><div class=3D"gmail_extra">part of the rationale for this w= as it was easy to overwrite an entry into the jump table when a signal was = no longer going to be sent e.g. because a newer version of that rpc call ha= d been placed in a different offset in the jump table...<br><br></div><div = class=3D"gmail_extra">presumably the authentication mechanism didn't in= clude per-offset/per authority W/X bits since I don't see space program= s needing it...<br><br></div><div class=3D"gmail_extra">nor do I know if th= ey had anything similar to the keykos checkpointing mechanism for working s= ets...<br><br></div><div class=3D"gmail_extra">but it seems reasonable to m= e with an appropriate authentication mechanism the offset into jump table i= s not terribly dissimilar to a cap id for a fixed number of caps system.<br= ><br></div><div class=3D"gmail_extra">I'm guessing its quite possible t= hat there was a distinction between functions that were called by rpc and t= hose that were relied upon by the devices main loop<br></div></div> --001a11c2eb5a69369a0529ac1798-- --===============2179100564561966349== 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 --===============2179100564561966349==--