I'm about to start a new project in which I have to make two Android devices exchange data assuming no internet connection. I've seen the Nearby Connections API which seems perfect for my case.
Since the data the devices exchange are private, I would like to understand how Nearby secure the communication. On the website is written:
Connections between devices are high-bandwidth, low-latency, and fully encrypted to enable fast, secure data transfers.
No additional information are provided. Does anyone knows how Nearby enforces communication encryption?
Thanks
When one device requests a connection with another, both devices are given the exact same token and asked to, independently, accept the connection. Users are expected to confirm this token somehow (eg. Show the token on both screens with a confirmation prompt).
This step is required for every connection request; there's no way to reconnect (yet).
Related
I am pretty confused here trying to find a solution to this problem.
There is a wifi enabled micro controller and a client (android app), both connected to the same wifi network. The official android app sends some instructions to the microcontroller through GET params.
Now i want only and only the official app to be able to send meaningful data across. To prevent man-in-the-middle attack i can encrypt this data using asymmetric keys. The micro-controller will generate the public and private keys and give out the public key through the server when asked for.
But then comes the problem. Can't the attacker send data to the device (micro-controller) too if he knows the public key? The attacker can simply get the code of the app through reverse eng. and send meaningful data through his browser to the device.
Some limitations -
I cant make any sort of white-list on the device.
There is no internet connection. Just LAN available.
The device has no sense of time.
Some properties-
The devices have a unique 8 digit id. In scenario of multiple devices, the right one is targeted using this id. The devices' used IP address is mapped to this ID.
The android app (client) sends numeric strings in GET params for the devices to perform operations.
Can this be solved using a fool-proof method?
Thank you in advance.
I am doing registration in my app using HTTP. If I do registration via MOBILE DATA my cookies are not coming from server But If i do the same task via WIFI cookies are coming properly. And this problem is being faced on just one handset i.e. "SONY XPERIA M". On other handset, cookies are coming on both via mobile data and via wifi too.
Why so?
It is almost impossible to answer this question with this little information, but here's some general help to get your problem sorted out:
Take a look at your cookie parameters. The domain, path, etc have to match the domain, path, etc. you are serving the page from. Some devices may be more lenient, others may not be.
Try to route your internet traffic via a VPN, so you bypass any wonky filtering or CGN your network provider may apply.
Switch your application to HTTPS. HTTPS cannot be manipulated by intermediaries, so your cookies should be safe.
Do extensive traffic logging on the server if possible. You can capture packets from your mobile device if you know it's IP address using tcpdump and then display them in Wireshark. This should enable you to piece together why it isn't working.
In the traffic dump take a look at the headers sent from the client. Be suspicious of any headers that may indicate the presence of proxies. Also take a look if the IP address your device thinks has is the same the traffic is coming from. If it isn't, a NAT or transparent proxy is in place.
Try to sniff the traffic directly on the device and compare it to what the server sees. If the traffic differs, there is some proxying in place. There are some android apps for that.
I hope this helps. If you need additional help, please post a lot more information, especially the exact cookie header you are sending out.
Wonder if anyone here happen to know the ip range of google's gcm server (for android push notification)?
I need the information so that our network team can open the firewall port for our UAT environment for incoming UAT test.
I tried to lookup from developer.android.com/google/gcm/ but no luck.
Our network team refused to open all ip range from asn 15169 which is a rather huge list.
I think there is an existing question IP address for Google Cloud Messaging server and the person found out that those are not published by Google. I also tried to look for it once but couldn't find. I might be wrong but I am pretty sure they don't publish that. Maybe instead of using corporate wifi, you can use direct 3G or 4G data plan.
In a comment on why GCM is not giving push notification in android device? question someone has mentioned that He opened the ports 5258,29,30 and then he was able to receive the regId from GCM server behind firewall.
Also I think the answer by #Eran on Which port and protocol does Google Cloud Messaging (GCM) use? will be of help. It says:
The device accesses the GCM servers on ports 5228-5230. If your organization has a firewall that restricts the traffic to or from the Internet, you'll need to configure it to allow connectivity with GCM. The ports to open are: 5228, 5229, and 5230. GCM typically only uses 5228, but it sometimes uses 5229 and 5230. GCM doesn't provide specific IPs. It changes IPs frequently. We recommend against using ACLs but if you must use them, take a broad approach such as the method suggested in this support link.
This is relevant if your device is connected to the internet via WiFi.
Hope this helps a bit.
Update:
As per Mark Whitaker answer to a similar question here, he mentions that:
Newer versions of Android also fall back to port 443 if ports 5228-5230 are blocked by a firewall.
Although there doesn't seem to be an official list still.
To add to what Shobhit Puri already said, I've also tried to find the answer to this question to be able to poke the appropriate holes in my firewall and am extremely disappointed with Google after concluding that the IP address used for Google Cloud Messaging is not obtained using a DNS request, or are obtained using DNS requests that subvert the Always On VPN functionality in Android.
By using the Always On VPN function in later versions of Android, I made sure that all traffic went through one of my servers. This also allowed me to use that server as a DNS Resolver and by activating query logging and rebooting the phone I was able to get a list of all of the DNS requests that it makes. Then, with some scripting magic I checked all of them, but none of them resolved to the IP address(es) that show up in my firewall logs with outbound port 5228 drops.
This leads me to conclude that the IP addresses used for GCM are obtained using a method other than DNS, such as Google Play Store web traffic.
Edit (Solution?): After running a script through all of my firewall logs going back as far as I have them and pulling out all of the dstport 5228 entries, I've been able to compile a list of IP addresses that GCM has tried to connect to. I can't say that this is a complete list, it will likely change based on geographic location, but notice the pattern...
74.125.28.188
74.125.129.188
74.125.20.188
173.194.79.188
74.125.142.188
74.125.192.188
74.125.140.188
74.125.139.188
74.125.137.188
74.125.134.188
74.125.130.188
173.194.68.188
173.194.76.188
I've created a group for all of those IP addresses and have configured my firewall to use that for my GCM whitelist. I have also setup a report to check for any dstport 5228 drops to let me know if I ever need to revisit this.
For WPA/WPA2, wpa_supplicant can give message of wrong-password when the connection fails in the HANDSHAKE procedure.
But when I try the WEP with a wrong password, the wpa_supplicant can get to the COMPLETED state without reporting any error.
I've searched on the internet and the only useful information I got is that someone said that iwconfigcan give the undecrypted packets in the Rx invalid crypt field.
But when I using WEP and I type iwconfig, the Rx invalid crypt field is 0.
I'm wondering how do those handsets judge wether the WEP password is wrong...
WEP network can of two types WEP-Open and WEP-Shared.
In the 802.11 standard, a device first Authenticates to the AP, and then Associates. The original designers intended that there would be a number of different Authentication methods to control who could use an AP.
In the 1999 version of the standard, 2 Authentication methods are defined: Open and Shared. In Open, any device can Authenticate to the AP. In Shared, only devices with the WEP key can successfully Authenticate.
The problem with Authenticate, is that were it is in the process of establishing connectivity, none of the higher-level protocols, like 802.1X can be run inside of the Authenticate 802.11 frames. So 802.11i does not use it, just uses Open Authenticate.
Shared Authenticate has a serious flaw, in that it is a simple challenge/response protocol. This design is very open to offline dictionary attacks. A WEP key would easily be exposed. Additionally, even in Open Authentication, a device that did not have the WEP key would not be able to communicate via the AP, as the AP would discard all data packets from the device.
I'm using C2DM in my Application to send data from mobile to mobile
But C2DM uses Google server(lacks data confidentiality) to redirect messages to device.
Is there any other way for sending data from mobile to mobile directly without any third party server?
I dont want to use SMS in my App.
Base on requirement (1) Without third party server (2) Between 2 mobiles.
Your options are limited to these:
WiFi Direct (Ad Hoc Network)
http://developer.android.com/guide/topics/wireless/wifip2p.html
Bluetooth
http://developer.android.com/guide/topics/wireless/bluetooth.html
NFC
http://developer.android.com/guide/topics/nfc/index.html
You clearly said "no third party server". But may I suggest xmpp. I've had good luck with smack derived jars and OpenFire. You get a lot of flexible and easy to use functionality out of the box. It may be your best bet for chat type applications.
We host our own instance of OpenFire and authenticate against Active Directory. The XMPP protocol provides the user/device addressing, routing, and, optionally, store and forward capabilities.
It also makes it easy to exchange device data with applications written for other operating systems and in other languages. XMPP IQ packets can be used for lookup type transactions without the overhead of a Chat type connection (no presence information, back end XEP-114 plug ins to connect with server side resources).
Not really: your device has to know which device to connect to. You could theoretically do that if you know the IP of the device, but with mobile phones this changes frequently and I'm not even sure if mobile providers will let you connect directly to devices on their network. So, you're at least going to need a 'step' in between the two phones that you can trust to be stable.
What you could do is set up your own server, and let a user (user1) upload messages to your server addressed to a specific sender (user2). When the message is received, you can use C2DM to send a signal to user2's phone, and attach the message's unique identifier to this. When user2's app receives this message, you can proceed to download the message content from your webserver.
If you don't want to use any webserver at all, you're limited to the options mentioned by Calvin: WiFi, bluetooth or NFC.
Unfortunately having a direct socket connection between mobiles phones is almost impossible as they invariably are behind firewall. BTW also look at https://www.alljoyn.org/ Its an interesting technology as well.