Unique ID for Pi to validate in Android app

[arjunm009]

Is there a way to give a unique encrypted ID to a Pi for home automation purpose, so that when an Android/iOs app searches for it in a network, it only detects it as a separate device and not as a generic raspberry pi?

Like Sonos, even though it is a Upnp device, if you use its app and power up first time to connect it to home wifi, it wont detect other Upnp devices, so to speak.

How do they do that?

At present if I have to connect a raspberry pi to my wifi for first time, i use a temporary hotspot which transmits only ssid and possibly mac address.

If I select that network, it prompts me to enter my home wifi.

Now, even before entering my home wifi , how can i make sure in the app, it will detect only my custom configured Pi and not my other Pi's built for other purposes.

Is there any projects which does this?

[ghans]

May your other , non-customized Pis be visible to scanners like nmap or Fing or need they be to be completely invisible to scanner apps ?

ghans

[arjunm009]

I was thinking it should transmit some custom broadcast id while the mobile app is trying to look for it.
I dont know how devices like sonos, Google home work but only their respective apps can discover them.

So something like that. Some way for the pi to broadcast it is a different pi.

[hippy]

Is there a way to give a unique encrypted ID to a Pi for home automation purpose

Should be possible as each Pi has a random serial number assigned and each would presumably be given its own unique IP address on the network it is on. SD Cards should also have their own unique ID numbers. Add a DS18B20 or other one-wire device and that will supply an additional unique 48-bit serial number.

[ghans]

The simplest way would be to use a special hostname , or to append a pattern to the hostname. The app would scan the subnet , do reverse lookups and discard everything not matching the pattern.

Another way would be to install Avahi (mDNS/ Zeroconf) and writing a config file which advertises the service your app needs. You must check the Avahi docs how that works.
Your problem is what Zeroconf was designed as solution for in the first place.

After that , Androids Zeroconf facilities could be used (at least mDNS resolution should work out-of-the-box) to dicover your specialised Pi.

See also :
http://www.zeroconf.org/ZeroconfAndUPnP.html

ghans

[Bosse_B]

All RPi units have a serial number that is unique (used among others for the MPEG1 license).
You can find it using this:

Code: Select all

cat /proc/cpuinfo | grep Serial

Another unique ID is the Ethernet MAC address and also the WiFi MAC address if you have a RPi3 with built-in WiFi:

Code: Select all

 ifconfig | grep HWaddr

These are absolutely unique and since they are soldered onto the RPi board not easily changed.
HTH

[DougieLawson]

They are unique (for 2^24 units) but can be easily spoofed, so are not secure.

[arjunm009]

The simplest way would be to use a special hostname , or to append a pattern to the hostname. The app would scan the subnet , do reverse lookups and discard everything not matching the pattern.

Another way would be to install Avahi (mDNS/ Zeroconf) and writing a config file which advertises the service your app needs. You must check the Avahi docs how that works.
Your problem is what Zeroconf was designed as solution for in the first place.

After that , Androids Zeroconf facilities could be used (at least mDNS resolution should work out-of-the-box) to dicover your specialised Pi.

See also :
http://www.zeroconf.org/ZeroconfAndUPnP.html

ghans

Yes I was thinking of that but even if I generate a long unique SSID, I can simply reuse that name for another pi's ssid when setting up as temporary AP.

[ghans]

You do not want to connect your specialised Pi to networks via Ethernet cable , ever ?

ghans

[arjunm009]

Is there a way to give a unique encrypted ID to a Pi for home automation purpose

Should be possible as each Pi has a random serial number assigned and each would presumably be given its own unique IP address on the network it is on. SD Cards should also have their own unique ID numbers. Add a DS18B20 or other one-wire device and that will supply an additional unique 48-bit serial number.

Using a eeprom can be considered but how to later identify it through app.
Some kind of custom handshaking is required.
Absolutely cannot use that as a Ssid for temp AP as it is easy as copying the name itself to another pi.

Simple stuff but those sonos, GH guys surely put in something clever!

[ghans]

Why do you think Sonos devices cannot be discoverd by traditional network scanners
like nmap and fing ? Why do you think that third parties cannot detect , connect to , configure and control Sonos devices ? (I'm just curious , perhaps Sonos devices are actually heavily secured).

ghans

[arjunm009]

You do not want to connect your specialised Pi to networks via Ethernet cable , ever ?

ghans

Router is inconveniently placed in a corner. Dont want to bother with more wires.

Thats why only wifi option is considered even from the start.

But please tell how using Ethernet can do this. It would be similar for the app to know that it is a normal pi?

[arjunm009]

Why do you think Sonos devices cannot be discoverd by traditional network scanners
like nmap and fing ? Why do you think that third parties cannot detect , connect to , configure and control Sonos devices ? (I'm just curious , perhaps Sonos devices are actually heavily secured).

ghans

Not that way. Only their apps can see sonos specific upnp or Google home specific cast devices. If there is another diy upnp/cast device, it wont show.
In that manner i was referring.
Similar with philips bulbs. if there a diy smart bulb using the same protocol, it wont show in the hue app.

[arjunm009]

They are unique (for 2^24 units) but can be easily spoofed, so are not secure.

Not secure that is true.
But how do you perform handshaking those values with an app? It needs to communicated some way when setting a Hue bulb or Sonos speaker for first time over wifi?

They use a different protocol with a temp AP in their devices?

[ghans]

So i think we all agree this has little to do with "security" but with filtering the results of a network scan ?

What do you think of following approach (Pseudocode) ?

Code: Select all

while not connected to network:
     switch to wifi client mode
     scan for wifi networks
     save list of available networks
     switch to WiFi AP mode
     start captive portal / config page
     let user select network + enter wifi key
     switch to client mode
     try to connect in client mode with key
     if successful : break

[hippy]

Only their apps can see sonos specific upnp or Google home specific cast devices. If there is another diy upnp/cast device, it wont show.

Those apps are probably using some form of SSDP. But that doesn't stop equipment faking being something it is not. I have had my Pi identifying itself as a Tivo, as a Chromecast, and other things besides. It is fairly trivial to do that.

Proving that something is what it claims to be is the more difficult challenge.

It is also fairly likely that a DIY app can make Sonos and Google Home devices reveal themselves.

Similar with philips bulbs. if there a diy smart bulb using the same protocol, it wont show in the hue app.

I have never tried it but I am sure a DIY smart bulb could be made to do so.

[arjunm009]

It is also fairly likely that a DIY app can make Sonos and Google Home devices reveal themselves.

That maybe. Or maybe not. I haven't seen an approach. I have tried to search for a solution.

But even it is, it would be interesting to know how the app knows its device.

[arjunm009]

So i think we all agree this has little to do with "security" but with filtering the results of a network scan ?

What do you think of following approach (Pseudocode) ?

Code: Select all

while not connected to network:
     switch to wifi client mode
     scan for wifi networks
     save list of available networks
     switch to WiFi AP mode
     start captive portal / config page
     let user select network + enter wifi key
     switch to client mode
     try to connect in client mode with key
     if successful : break

?
That was not i was talking about.

[ghans]

Again , i think we are all in agreement that this has nothing with "security" but with filtering the results of a network / WiFi scan ?

If yes , the answer is quite obvious : get all hostnames / WiFi SSIDs / Zeroconf broadcasts and drop those from the list which do not fit a certain pattern / do not advertise a certain service.

ghans

[hippy]

it would be interesting to know how the app knows its device.

For SSDP the app would send out a multicast 'M-SEARCH' request asking all devices, or all devices of a certain type, to respond, wait for the responses, then filter those to only display what it wants to display.