Re: Connecting to the right device

[Jonathan Kingston]

On Wednesday, 6 January 2016 16:08:34 UTC, Michiel de Jong  wrote:
> This paper came up on the b2g-internal list today and gives a good overview: 
> http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/papers/EricRescorla.pdf
>  - cross-posting here for reference.
> 
> 
> 
> On Wed, Dec 23, 2015 at 2:31 PM, Michiel de Jong  wrote:
> 
> 
> Connecting from a web browser to a web site is just a special case of using 
> "Device A", to connect to "Device B". Looking at the generic case where 
> Device A and Device B can both be anyThing ;) brings up a few interesting 
> questions:
> 
> 1) How can a certificate authority vouch for the identity of Device B, if it 
> does not have a URL? Unless we replace CA's with Web-of-Trust, this might be 
> something to think about as more devices come into play that have no URL.
> 
> 
> 2) The user might have Device B in their eye sight. Does that help?
> 
> If Device B can be many more things than just a web server in a data center, 
> then you may be able to connect to it with more accuracy. For instance, by 
> sticking a USB cable in it, touching it with your NFC reader, or pointing a 
> camera at it.
> 
> 
> 3) How can you accurately connect to a device if you have no URL, and also no 
> physical proximity?
> 
> 
> I'm not talking about how to protect Device B from unauthorized access (WPS 
> buttons on WiFi routers etc.). What interests me is how you as a user can 
> accurately identify the device you are connecting *to*.
> 
> Curious if anyone has more thoughts on this! :)
> 
> 
> 
> Cheers,
> 
> Michiel.

Very rough ideas however thought it was worth writing down...

Without public internet on both devices this becomes certainly very difficult.

For device discovery the likes of web beacons could be a good implementation:
https://dev.opera.com/articles/release-the-beacons/

This would allow the TV to announce itself to all visitors of the house etc 
whenever they are in range. This could be treated as completely insecure and 
would require the user to opt-in to connecting to the device without exposing 
the user directly.

This insecure channel could guide the user to where the device might be or just 
make them aware that pairing is possible etc. In a truly connected home using 
this along with the ultrasonic info to gauge proximity could help users 
discover sensors around the home without the need for visual queues on displays 
etc.

To pair the devices in a secure mode the user would need to doubly opt in on 
their phone by using something close range like NFC whilst they do some form of 
button click/gesture on the beacon notification/app.
This type of double opt in using two channels then will be hard to spoof 
especially as it required a approval from the user.

The local NFC communication then delivers the information for setting up a 
secure WebRTC connection.
___
dev-fxos mailing list
dev-fxos@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-fxos

Re: Connecting to the right device

[Michiel de Jong]

This paper came up on the b2g-internal list today and gives a good
overview:
http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/papers/EricRescorla.pdf
- cross-posting here for reference.

On Wed, Dec 23, 2015 at 2:31 PM, Michiel de Jong 
wrote:

> Connecting from a web browser to a web site is just a special case of
> using "Device A", to connect to "Device B". Looking at the generic case
> where Device A and Device B can both be anyThing ;) brings up a few
> interesting questions:
>
> 1) How can a certificate authority vouch for the identity of Device B, if
> it does not have a URL? Unless we replace CA's with Web-of-Trust, this
> might be something to think about as more devices come into play that have
> no URL.
>
> 2) The user might have Device B in their eye sight. Does that help?
>
> If Device B can be many more things than just a web server in a data
> center, then you may be able to connect to it with more accuracy. For
> instance, by sticking a USB cable in it, touching it with your NFC reader,
> or pointing a camera at it.
>
> 3) How can you accurately connect to a device if you have no URL, and also
> no physical proximity?
>
> I'm not talking about how to protect Device B from unauthorized access
> (WPS buttons on WiFi routers etc.). What interests me is how you as a user
> can accurately identify the device you are connecting *to*.
>
> Curious if anyone has more thoughts on this! :)
>
>
> Cheers,
> Michiel.
>
___
dev-fxos mailing list
dev-fxos@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-fxos

Re: Connecting to the right device

[Michiel de Jong]

Hi Paul,

Thanks for your detailed reply!

On Mon, Dec 28, 2015 at 4:11 AM, Paul Theriault 
wrote:

> This is an extremely important discussion! We’ve actually been struggling
> with this exact issue for the remote control on the TV.  TLS doesn’t suit
> because the TV has an internal network address only (no public DNS name).
> We’ve been discussing how to implement the trust relationship between the
> remote control web page running on an arbitrary device/browser and the TV.
> I’m not sure that this is a good solution (I’m all ears if anyone has a
> suggestion)
>
> Some (not very well structured) thoughts on your questions in line below.
>
> On 24 Dec 2015, at 12:31 am, Michiel de Jong  wrote:
>
> Connecting from a web browser to a web site is just a special case of
> using "Device A", to connect to "Device B". Looking at the generic case
> where Device A and Device B can both be anyThing ;) brings up a few
> interesting questions:
>
> 1) How can a certificate authority vouch for the identity of Device B, if
> it does not have a URL? Unless we replace CA's with Web-of-Trust, this
> might be something to think about as more devices come into play that have
> no URL.
>
>
> Even with a URL, on an internal network CAs are of limited use (works  for
> enterprise when you can pre-install a CA, but not in the general case). But
> how this “web-of-trust’ would work, I’m not sure. Exchange of CA via some
> side-channel? Or maybe exchange WebRTC SDP and then you can use
> dataConnection to securely communicate - but that doesn’t doesn’t solve the
> problem of secure code delivery in the first place. Another option might be
> to leverage an external trusted source to broker the initial communication
> (https://trustedapp.marketplace.firefox.com) but then both devices need
> access to the internet.
>
>
> 2) The user might have Device B in their eye sight. Does that help?
>
>
> If Device B can be many more things than just a web server in a data
> center, then you may be able to connect to it with more accuracy. For
> instance, by sticking a USB cable in it, touching it with your NFC reader,
> or pointing a camera at it.
>
>
> Definitely! There is much prior art for local-area identification and
> authentication. Of the top of my head (and a quick search on the web) I can
> think of:
> - exchange of pin codes (e.g. bluetooth pairing)
> - physical proximity (NFC, or use physical sensors, e.g. bluetooth signal
> strength, or physical “bumps”)
> - Visual data encoding (e.g QR codes, or
> https://www.youtube.com/watch?v=sVWlQNzU4Ak )
> - (Ultra)Sonic data encoding ( e.g.
> https://github.com/borismus/sonicnet.js)
>


Can pin codes by themselves provide protection against man-in-the-middle
attacks? Or would you have to combine them with some form of asymmetric
crypto then?

Cheers,
Michiel.


>
> It might be interesting to consider a standard approach for exchanging
> authentication information (i’d be surprised if there wasn’t any standards
> in this space actually)
>
> 3) How can you accurately connect to a device if you have no URL, and also
> no physical proximity?
>
> I'm not talking about how to protect Device B from unauthorized access
> (WPS buttons on WiFi routers etc.). What interests me is how you as a user
> can accurately identify the device you are connecting *to*.
>
>
> I don’t think you can, at least automatically unless there is some prior
> web-of-trust. It depends what you mean by ‘no physical proximity’ too. Do
> you mean too far to use a side-channel like bluetooth, but still on the
> same LAN. Or something else? Are we even talking TCP/IP here or something
> completely seperate?
>
>
> Curious if anyone has more thoughts on this! :)
>
>
> Me too! Im afraid I’ve not seen any good solutions in this space as yet
> but I’ve only just started digging.
>
>
>
>
> Cheers,
> Michiel.
> ___
> dev-fxos mailing list
> dev-fxos@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-fxos
>
>
>
___
dev-fxos mailing list
dev-fxos@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-fxos

Re: Connecting to the right device

[Paul Theriault]

For NFC there has been some discussion as part of the WebNFC. IIRC they are 
mostly around an option scheme. WebNFC is limited to NDEF NFC tags, and I 
believe the proposal was to require that a tag must have a special header 
written which indicates it can be written by a certain domain.  (Obviously 
nothing stops you from reading the tag with something other than a browser 
though)

See https://w3c.github.io/web-nfc/#dfn-web-nfc-record 
 for more details.

But when I mentioned NFC below, I was more meaning for it as a side-channel for 
authenticating devices. For example, bluetooth can use NFC for pairing, see 
http://nfc-forum.org/nfc-and-bluetooth-the-perfect-pair/ 




> On 28 Dec 2015, at 3:14 pm, Naoki Hirata  wrote:
> 
> I agree, privacy and security would definitely be a huge concern!
> 
> I wonder if we'll have to set up a trust server or service or a whitelisting 
> server?  Can we do that in a P2P method within the local network?
> 
> I could foresee NFC being used to redirect a device to another device.  The 
> main issue is hijacking and such.  How do you prevent unwanted connection...  
> Do you have to whitelist the NFC with certain devices?  Mac IP?  Would fly 
> web server have to be adjusted to also know who to trust?
> 
> 
> On Sun, Dec 27, 2015 at 7:11 PM, Paul Theriault  > wrote:
> This is an extremely important discussion! We’ve actually been struggling 
> with this exact issue for the remote control on the TV.  TLS doesn’t suit 
> because the TV has an internal network address only (no public DNS name). 
> We’ve been discussing how to implement the trust relationship between the 
> remote control web page running on an arbitrary device/browser and the TV. 
> I’m not sure that this is a good solution (I’m all ears if anyone has a 
> suggestion)
> 
> Some (not very well structured) thoughts on your questions in line below.
> 
>> On 24 Dec 2015, at 12:31 am, Michiel de Jong > > wrote:
>> 
>> Connecting from a web browser to a web site is just a special case of using 
>> "Device A", to connect to "Device B". Looking at the generic case where 
>> Device A and Device B can both be anyThing ;) brings up a few interesting 
>> questions:
>> 
>> 1) How can a certificate authority vouch for the identity of Device B, if it 
>> does not have a URL? Unless we replace CA's with Web-of-Trust, this might be 
>> something to think about as more devices come into play that have no URL.
> 
> Even with a URL, on an internal network CAs are of limited use (works  for 
> enterprise when you can pre-install a CA, but not in the general case). But 
> how this “web-of-trust’ would work, I’m not sure. Exchange of CA via some 
> side-channel? Or maybe exchange WebRTC SDP and then you can use 
> dataConnection to securely communicate - but that doesn’t doesn’t solve the 
> problem of secure code delivery in the first place. Another option might be 
> to leverage an external trusted source to broker the initial communication 
> (https://trustedapp.marketplace.firefox.com 
> ) but then both devices need 
> access to the internet.
> 
>> 
>> 2) The user might have Device B in their eye sight. Does that help?
> 
>> 
>> If Device B can be many more things than just a web server in a data center, 
>> then you may be able to connect to it with more accuracy. For instance, by 
>> sticking a USB cable in it, touching it with your NFC reader, or pointing a 
>> camera at it.
> 
> Definitely! There is much prior art for local-area identification and 
> authentication. Of the top of my head (and a quick search on the web) I can 
> think of:
> - exchange of pin codes (e.g. bluetooth pairing)
> - physical proximity (NFC, or use physical sensors, e.g. bluetooth signal 
> strength, or physical “bumps”)
> - Visual data encoding (e.g QR codes, or 
> https://www.youtube.com/watch?v=sVWlQNzU4Ak 
>  )
> - (Ultra)Sonic data encoding ( e.g. https://github.com/borismus/sonicnet.js 
> )
> 
> It might be interesting to consider a standard approach for exchanging 
> authentication information (i’d be surprised if there wasn’t any standards in 
> this space actually)
> 
>> 3) How can you accurately connect to a device if you have no URL, and also 
>> no physical proximity?
>> 
>> I'm not talking about how to protect Device B from unauthorized access (WPS 
>> buttons on WiFi routers etc.). What interests me is how you as a user can 
>> accurately identify the device you are connecting *to*.
> 
> I don’t think you can, at least automatically unless there is some prior 
> web-of-trust. It depends what you mean by ‘no physical proximity’ too. Do you 
> mean too far to use a side-channel like bluetooth, but still on t

Re: Connecting to the right device

[Naoki Hirata]

I agree, privacy and security would definitely be a huge concern!

I wonder if we'll have to set up a trust server or service or a
whitelisting server?  Can we do that in a P2P method within the local
network?

I could foresee NFC being used to redirect a device to another device.  The
main issue is hijacking and such.  How do you prevent unwanted
connection...  Do you have to whitelist the NFC with certain devices?  Mac
IP?  Would fly web server have to be adjusted to also know who to trust?


On Sun, Dec 27, 2015 at 7:11 PM, Paul Theriault 
wrote:

> This is an extremely important discussion! We’ve actually been struggling
> with this exact issue for the remote control on the TV.  TLS doesn’t suit
> because the TV has an internal network address only (no public DNS name).
> We’ve been discussing how to implement the trust relationship between the
> remote control web page running on an arbitrary device/browser and the TV.
> I’m not sure that this is a good solution (I’m all ears if anyone has a
> suggestion)
>
> Some (not very well structured) thoughts on your questions in line below.
>
> On 24 Dec 2015, at 12:31 am, Michiel de Jong  wrote:
>
> Connecting from a web browser to a web site is just a special case of
> using "Device A", to connect to "Device B". Looking at the generic case
> where Device A and Device B can both be anyThing ;) brings up a few
> interesting questions:
>
> 1) How can a certificate authority vouch for the identity of Device B, if
> it does not have a URL? Unless we replace CA's with Web-of-Trust, this
> might be something to think about as more devices come into play that have
> no URL.
>
>
> Even with a URL, on an internal network CAs are of limited use (works  for
> enterprise when you can pre-install a CA, but not in the general case). But
> how this “web-of-trust’ would work, I’m not sure. Exchange of CA via some
> side-channel? Or maybe exchange WebRTC SDP and then you can use
> dataConnection to securely communicate - but that doesn’t doesn’t solve the
> problem of secure code delivery in the first place. Another option might be
> to leverage an external trusted source to broker the initial communication
> (https://trustedapp.marketplace.firefox.com) but then both devices need
> access to the internet.
>
>
> 2) The user might have Device B in their eye sight. Does that help?
>
>
> If Device B can be many more things than just a web server in a data
> center, then you may be able to connect to it with more accuracy. For
> instance, by sticking a USB cable in it, touching it with your NFC reader,
> or pointing a camera at it.
>
>
> Definitely! There is much prior art for local-area identification and
> authentication. Of the top of my head (and a quick search on the web) I can
> think of:
> - exchange of pin codes (e.g. bluetooth pairing)
> - physical proximity (NFC, or use physical sensors, e.g. bluetooth signal
> strength, or physical “bumps”)
> - Visual data encoding (e.g QR codes, or
> https://www.youtube.com/watch?v=sVWlQNzU4Ak )
> - (Ultra)Sonic data encoding ( e.g.
> https://github.com/borismus/sonicnet.js)
>
> It might be interesting to consider a standard approach for exchanging
> authentication information (i’d be surprised if there wasn’t any standards
> in this space actually)
>
> 3) How can you accurately connect to a device if you have no URL, and also
> no physical proximity?
>
> I'm not talking about how to protect Device B from unauthorized access
> (WPS buttons on WiFi routers etc.). What interests me is how you as a user
> can accurately identify the device you are connecting *to*.
>
>
> I don’t think you can, at least automatically unless there is some prior
> web-of-trust. It depends what you mean by ‘no physical proximity’ too. Do
> you mean too far to use a side-channel like bluetooth, but still on the
> same LAN. Or something else? Are we even talking TCP/IP here or something
> completely seperate?
>
>
> Curious if anyone has more thoughts on this! :)
>
>
> Me too! Im afraid I’ve not seen any good solutions in this space as yet
> but I’ve only just started digging.
>
>
>
>
> Cheers,
> Michiel.
> ___
> dev-fxos mailing list
> dev-fxos@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-fxos
>
>
>
> ___
> dev-fxos mailing list
> dev-fxos@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-fxos
>
>
___
dev-fxos mailing list
dev-fxos@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-fxos

Re: Connecting to the right device

[Paul Theriault]

This is an extremely important discussion! We’ve actually been struggling with 
this exact issue for the remote control on the TV.  TLS doesn’t suit because 
the TV has an internal network address only (no public DNS name). We’ve been 
discussing how to implement the trust relationship between the remote control 
web page running on an arbitrary device/browser and the TV. I’m not sure that 
this is a good solution (I’m all ears if anyone has a suggestion)

Some (not very well structured) thoughts on your questions in line below.

> On 24 Dec 2015, at 12:31 am, Michiel de Jong  wrote:
> 
> Connecting from a web browser to a web site is just a special case of using 
> "Device A", to connect to "Device B". Looking at the generic case where 
> Device A and Device B can both be anyThing ;) brings up a few interesting 
> questions:
> 
> 1) How can a certificate authority vouch for the identity of Device B, if it 
> does not have a URL? Unless we replace CA's with Web-of-Trust, this might be 
> something to think about as more devices come into play that have no URL.

Even with a URL, on an internal network CAs are of limited use (works  for 
enterprise when you can pre-install a CA, but not in the general case). But how 
this “web-of-trust’ would work, I’m not sure. Exchange of CA via some 
side-channel? Or maybe exchange WebRTC SDP and then you can use dataConnection 
to securely communicate - but that doesn’t doesn’t solve the problem of secure 
code delivery in the first place. Another option might be to leverage an 
external trusted source to broker the initial communication 
(https://trustedapp.marketplace.firefox.com) but then both devices need access 
to the internet.

> 
> 2) The user might have Device B in their eye sight. Does that help?

> 
> If Device B can be many more things than just a web server in a data center, 
> then you may be able to connect to it with more accuracy. For instance, by 
> sticking a USB cable in it, touching it with your NFC reader, or pointing a 
> camera at it.

Definitely! There is much prior art for local-area identification and 
authentication. Of the top of my head (and a quick search on the web) I can 
think of:
- exchange of pin codes (e.g. bluetooth pairing)
- physical proximity (NFC, or use physical sensors, e.g. bluetooth signal 
strength, or physical “bumps”)
- Visual data encoding (e.g QR codes, or 
https://www.youtube.com/watch?v=sVWlQNzU4Ak 
 )
- (Ultra)Sonic data encoding ( e.g. https://github.com/borismus/sonicnet.js 
)

It might be interesting to consider a standard approach for exchanging 
authentication information (i’d be surprised if there wasn’t any standards in 
this space actually)

> 3) How can you accurately connect to a device if you have no URL, and also no 
> physical proximity?
> 
> I'm not talking about how to protect Device B from unauthorized access (WPS 
> buttons on WiFi routers etc.). What interests me is how you as a user can 
> accurately identify the device you are connecting *to*.

I don’t think you can, at least automatically unless there is some prior 
web-of-trust. It depends what you mean by ‘no physical proximity’ too. Do you 
mean too far to use a side-channel like bluetooth, but still on the same LAN. 
Or something else? Are we even talking TCP/IP here or something completely 
seperate?

> 
> Curious if anyone has more thoughts on this! :)

Me too! Im afraid I’ve not seen any good solutions in this space as yet but 
I’ve only just started digging.


> 
> 
> Cheers,
> Michiel.
> ___
> dev-fxos mailing list
> dev-fxos@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-fxos

___
dev-fxos mailing list
dev-fxos@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-fxos