Private Devices and IoT (was Proposal: Marking HTTP As Non-Secure)

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Private Devices and IoT (was Proposal: Marking HTTP As Non-Secure)

Jeffrey Walton
Hi Chris,

Sorry to dig up an old thread.

> Yes, I agree this is a problem. I am hoping to publish a proposal for
> how UAs can authenticate private devices soon (in January probably).

Were you able to publish something? I wanted to read more about what
directions the solutions are moving towards.

This just made my radar:
http://blog.kaspersky.com/internet-of-crappy-things/, and I was
wondering how much has been addressed and how much is hyperbole.

Thanks in advance.

Jeff

On Thu, Dec 18, 2014 at 2:33 PM, Chris Palmer <[hidden email]> wrote:

> On Thu, Dec 18, 2014 at 9:52 AM, jstriegel via blink-dev
> <[hidden email]> wrote:
>
>> I'd like to propose consideration of a fourth category:
>> Personal Devices (home routers, printers, IoT, raspberry pis in classrooms, refrigerators):
>>  - cannot, by nature, participate in DNS and CA systems
>>  - likely on private network block
>>  - user is the owner of the service, hence can trust self rather than CA
>>
>> Suggested use:
>>  - IoT devices generate unique, self-signed cert
>>  - Friendlier interstitial (Ie. "Is this a device you recognize?") for self-signed connections on *.local, 192.168.*, 10.*, or on same local network as browser.
>>  - user approves use on first https connection
>>  - browser remembers (device is promoted to "secure" status)
>>
>> A lot of IoT use cases could benefit from direct connection (not requiring a cloud service as secure data proxy), but this currently gives the scariest of Chrome warnings. This is probably why the average home router or firewall is administered over http.
>
> Yes, I agree this is a problem. I am hoping to publish a proposal for
> how UAs can authenticate private devices soon (in January probably).
>
> A key goal is not having to ask the user "Is this a device you
> recognize?" — I think we can get the UX flow even simpler, and still
> be strong. Watch this space...
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Private Devices and IoT (was Proposal: Marking HTTP As Non-Secure)

Adam Langley-8
On Sun, Feb 22, 2015 at 10:35 AM, Jeffrey Walton <[hidden email]> wrote:

> Hi Chris,
>
> Sorry to dig up an old thread.
>
>> Yes, I agree this is a problem. I am hoping to publish a proposal for
>> how UAs can authenticate private devices soon (in January probably).
>
> Were you able to publish something? I wanted to read more about what
> directions the solutions are moving towards.
>
> This just made my radar:
> http://blog.kaspersky.com/internet-of-crappy-things/, and I was
> wondering how much has been addressed and how much is hyperbole.

Chris has disappeared off to write a book for a few months and
promises to mostly not check email. I still have this idea in my head
but haven't written anything. In my formulation, it would be a PAKE
scheme based mutual authentication done above the TLS layer, but used
to confirm the certificate. Chris was thinking more along the lines of
a public-key hash in the URL, but wanted it to be useably short and
thus worryingly weak.


Cheers

AGL

>
> Thanks in advance.
>
> Jeff
>
> On Thu, Dec 18, 2014 at 2:33 PM, Chris Palmer <[hidden email]> wrote:
>> On Thu, Dec 18, 2014 at 9:52 AM, jstriegel via blink-dev
>> <[hidden email]> wrote:
>>
>>> I'd like to propose consideration of a fourth category:
>>> Personal Devices (home routers, printers, IoT, raspberry pis in classrooms, refrigerators):
>>>  - cannot, by nature, participate in DNS and CA systems
>>>  - likely on private network block
>>>  - user is the owner of the service, hence can trust self rather than CA
>>>
>>> Suggested use:
>>>  - IoT devices generate unique, self-signed cert
>>>  - Friendlier interstitial (Ie. "Is this a device you recognize?") for self-signed connections on *.local, 192.168.*, 10.*, or on same local network as browser.
>>>  - user approves use on first https connection
>>>  - browser remembers (device is promoted to "secure" status)
>>>
>>> A lot of IoT use cases could benefit from direct connection (not requiring a cloud service as secure data proxy), but this currently gives the scariest of Chrome warnings. This is probably why the average home router or firewall is administered over http.
>>
>> Yes, I agree this is a problem. I am hoping to publish a proposal for
>> how UAs can authenticate private devices soon (in January probably).
>>
>> A key goal is not having to ask the user "Is this a device you
>> recognize?" — I think we can get the UX flow even simpler, and still
>> be strong. Watch this space...
>>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Private Devices and IoT (was Proposal: Marking HTTP As Non-Secure)

Jeffrey Walton
On Mon, Feb 23, 2015 at 1:32 PM, Adam Langley <[hidden email]> wrote:

> On Sun, Feb 22, 2015 at 10:35 AM, Jeffrey Walton <[hidden email]> wrote:
>> Hi Chris,
>>
>> Sorry to dig up an old thread.
>>
>>> Yes, I agree this is a problem. I am hoping to publish a proposal for
>>> how UAs can authenticate private devices soon (in January probably).
>>
>> Were you able to publish something? I wanted to read more about what
>> directions the solutions are moving towards.
>>
>> This just made my radar:
>> http://blog.kaspersky.com/internet-of-crappy-things/, and I was
>> wondering how much has been addressed and how much is hyperbole.
>
> Chris has disappeared off to write a book for a few months and
> promises to mostly not check email. I still have this idea in my head
> but haven't written anything. In my formulation, it would be a PAKE
> scheme based mutual authentication done above the TLS layer, but used
> to confirm the certificate. Chris was thinking more along the lines of
> a public-key hash in the URL, but wanted it to be useably short and
> thus worryingly weak.
>
I think the public key hash could have merit, too. It sounds a lot
like self authenticating URLs (if I am parsing it correctly). Gutmann
discusses them in his book on Engineering Security
(https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf).

So those two seem like ways to verify a device, like a fridge or
thermostat, is authenticated and authorized to do something on the
home network. How do you provision them? That seems like the pain
point.

I wonder if some of those devices will be able to do the public key
stuff. How powerful does the processor need to be in a fridge or
thermostat? The price point on a fridge may make it viable to
manufacture one with the processing horsepower needed. But how about
thermostats? The thermostat use case seems like it begs a PSK (or
other PAKE).

Going back to Jason's comment:

>>> A key goal is not having to ask the user "Is this a device you
>>> recognize?"

I think that may need to be refined to "repeatedly ask the user". Or
provisioning needs to be solved (which I believe is a restatement of
the key distribution problem).

One thing I know: I definitely want to read more about it.

Jeff

>> On Thu, Dec 18, 2014 at 2:33 PM, Chris Palmer <[hidden email]> wrote:
>>> On Thu, Dec 18, 2014 at 9:52 AM, jstriegel via blink-dev
>>> <[hidden email]> wrote:
>>>
>>>> I'd like to propose consideration of a fourth category:
>>>> Personal Devices (home routers, printers, IoT, raspberry pis in classrooms, refrigerators):
>>>>  - cannot, by nature, participate in DNS and CA systems
>>>>  - likely on private network block
>>>>  - user is the owner of the service, hence can trust self rather than CA
>>>>
>>>> Suggested use:
>>>>  - IoT devices generate unique, self-signed cert
>>>>  - Friendlier interstitial (Ie. "Is this a device you recognize?") for self-signed connections on *.local, 192.168.*, 10.*, or on same local network as browser.
>>>>  - user approves use on first https connection
>>>>  - browser remembers (device is promoted to "secure" status)
>>>>
>>>> A lot of IoT use cases could benefit from direct connection (not requiring a cloud service as secure data proxy), but this currently gives the scariest of Chrome warnings. This is probably why the average home router or firewall is administered over http.
>>>
>>> Yes, I agree this is a problem. I am hoping to publish a proposal for
>>> how UAs can authenticate private devices soon (in January probably).
>>>
>>> A key goal is not having to ask the user "Is this a device you
>>> recognize?" — I think we can get the UX flow even simpler, and still
>>> be strong. Watch this space...
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Private Devices and IoT (was Proposal: Marking HTTP As Non-Secure)

Anders Rundgren-2
In reply to this post by Jeffrey Walton
On Monday, February 23, 2015 at 7:54:40 PM UTC+1, Jeffrey Walton wrote:

> On Mon, Feb 23, 2015 at 1:32 PM, Adam Langley wrote:
> > On Sun, Feb 22, 2015 at 10:35 AM, Jeffrey Walton wrote:
> >> Hi Chris,
> >>
> >> Sorry to dig up an old thread.
> >>
> >>> Yes, I agree this is a problem. I am hoping to publish a proposal for
> >>> how UAs can authenticate private devices soon (in January probably).
> >>
> >> Were you able to publish something? I wanted to read more about what
> >> directions the solutions are moving towards.
> >>
> >> This just made my radar:
> >> http://blog.kaspersky.com/internet-of-crappy-things/, and I was
> >> wondering how much has been addressed and how much is hyperbole.
> >
> > Chris has disappeared off to write a book for a few months and
> > promises to mostly not check email. I still have this idea in my head
> > but haven't written anything. In my formulation, it would be a PAKE
> > scheme based mutual authentication done above the TLS layer, but used
> > to confirm the certificate. Chris was thinking more along the lines of
> > a public-key hash in the URL, but wanted it to be useably short and
> > thus worryingly weak.
> >
> I think the public key hash could have merit, too. It sounds a lot
> like self authenticating URLs (if I am parsing it correctly). Gutmann
> discusses them in his book on Engineering Security
> (https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf).
>
> So those two seem like ways to verify a device, like a fridge or
> thermostat, is authenticated and authorized to do something on the
> home network. How do you provision them? That seems like the pain
> point.
>
> I wonder if some of those devices will be able to do the public key
> stuff. How powerful does the processor need to be in a fridge or
> thermostat? The price point on a fridge may make it viable to
> manufacture one with the processing horsepower needed. But how about
> thermostats? The thermostat use case seems like it begs a PSK (or
> other PAKE).
>
> Going back to Jason's comment:
>
> >>> A key goal is not having to ask the user "Is this a device you
> >>> recognize?"
>
> I think that may need to be refined to "repeatedly ask the user". Or
> provisioning needs to be solved (which I believe is a restatement of
> the key distribution problem).

Provisioning is overrated, all it takes is an embedded device certificate and private key.  If algorithms become "defective" the device must be upgraded which can also deal with a new certificate.

If the device vendor goes out of business you have to consider a complete replacement.

I doubt that a device that is older than 20 years is worth saving so there's probably not much reason to bother about algorithms and re-certification.

Anders

>
> One thing I know: I definitely want to read more about it.
>
> Jeff
>
> >> On Thu, Dec 18, 2014 at 2:33 PM, Chris Palmer wrote:
> >>> On Thu, Dec 18, 2014 at 9:52 AM, jstriegel via blink-dev
> >>> wrote:
> >>>
> >>>> I'd like to propose consideration of a fourth category:
> >>>> Personal Devices (home routers, printers, IoT, raspberry pis in classrooms, refrigerators):
> >>>>  - cannot, by nature, participate in DNS and CA systems
> >>>>  - likely on private network block
> >>>>  - user is the owner of the service, hence can trust self rather than CA
> >>>>
> >>>> Suggested use:
> >>>>  - IoT devices generate unique, self-signed cert
> >>>>  - Friendlier interstitial (Ie. "Is this a device you recognize?") for self-signed connections on *.local, 192.168.*, 10.*, or on same local network as browser.
> >>>>  - user approves use on first https connection
> >>>>  - browser remembers (device is promoted to "secure" status)
> >>>>
> >>>> A lot of IoT use cases could benefit from direct connection (not requiring a cloud service as secure data proxy), but this currently gives the scariest of Chrome warnings. This is probably why the average home router or firewall is administered over http.
> >>>
> >>> Yes, I agree this is a problem. I am hoping to publish a proposal for
> >>> how UAs can authenticate private devices soon (in January probably).
> >>>
> >>> A key goal is not having to ask the user "Is this a device you
> >>> recognize?" -- I think we can get the UX flow even simpler, and still
> >>> be strong. Watch this space...
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security