I tried to configure a bonding pincode on my Movesense 2.0.0 sensor and I was expecting being asked for it when trying to connect to the sensor with MDS or apps like nRF Connect.
But what I got looks identical to Just Works mode, and the bonding PIN is being asked only if I try to pair the device through system's Bluetooth settings. Does it happen because in the first case there's only connection and no pairing? What are the pros/use cases for having the sensor paired at system-level?
I'm looking for a way to prevent unauthorized access (connections, API requests) to sensors from devices not knowing a secret access code (like a PIN). Do BLE/Movesense provide such a mechanism?
Neither Bluetooth nor Movesense offer a way to securely "log in with a secret password". The passkey bonding mechanism that is present in Bluetooth, is only designed with the purpose of avoiding man in the middle attacks, and the passkey must be random everytime since the protocol reveals the key after each attempt. A static passkey which some people use is not allowed per the specification. It might keep away your grandmother from accessing the device, but is not secure at all at a protocol level.
If you bond the device at a system level, the further communication will be secure (encrypted and authenticated) and will for example prevent spoofing attacks. It will also result in quicker device connection setup since GATT caching can be used.
You are not saying what "system" you are using so this is just a general answer.
Related
As I was testing an android app controls door lock over Bluetooth, I deployed HMAC SHA256 on both the door lock controller and the android app to ensure integrity and authentication of message. Also I have the door lock controller to generate random access token per connection to avoid replace attack.
I would like to replace to the Bluetooth with WiFi and test the application with FIWARE. I found I may need to provide a device name, id and password when provisioning a device with an IoT agent. However I am not sure what may be the measures in place to insure integrity and authentication of message and to avoid replay attack. Can you shed some light? Thanks.
This talk (https://youtu.be/Kbpx5CbQL74) seems to answer my question. The token is created with the device id(username) and password, which may be fixed, I am afraid.
And this link https://guided-tour-smartsdk.readthedocs.io/en/latest/sensors/cloudino/
The docs say:
"Include this key if your app requires (or specifically prohibits)
access to the networking features of the device."
It uses WiFi when available, but also 3G / mobile data.
I am afraid if I specify this key, it effectively means that the app doesn't work without a WiFi connection. Which would be wrong. It just requires internet access.
My iPhone connects over adhoc wifi to a wifi sensor module.
The challenge is to code an app that uses this sensor module. But I'm not sure what specific API's to use to best architect this implementation.
I've started looking into the CocoaAsyncSocket class as it seems to be an appropriate tool for such use.
Does the user always have to manually connect to the adhoc wifi device? (through the Settings app) or can my own app handle the searching, making, and breaking of the wifi connection?
I doubt iOS lets me programmatically toggle whether Wifi is on/off.
Once the sensor data is being received, what container would best handle the stream?
For example, on other platforms, I coded a rotating queue buffer.
Thanks for your input.
Edit: The protocol in question is straight CSV formatted ASCII. Not HTTP, FTP, etc. Just raw data. The app is to simply open a port on the connected IP, and read/write.
Your application cannot turn wifi on/off, or select a wifi network.
Without more information on what protocols this wifi sensor module speaks, it will be impossible for anyone to give more than vague recommendations. If the module can serve data over an http connection, that would probably be ideal. If it requires your software to open a connection on a specific port and communicate over something other than http or ftp, your job will be a bit more complicated. CFNetwork and projects derived from it's usage, such as CocoaAsyncSocket which you mentioned. You can see another implementation of an HTTP connection over CFNetwork in ASIHTTPRequest, that may help as a reference for handling download streams, queuing operations, etc.
As for storing the data, again it's hard to give any concrete recommendations without more information. If you want to store the data to the filesystem of the iOS device, NSData will probably meet your needs. If you need/prefer to use a queue for buffering data, there is a simple category on NSArray which provides queue semantics. The link to CHCircularBuffer in that SO article is dead, but this github project appears to have it.
edit: Here is the official version of the CHDataStructures. I don't know if it's an improvement over the previous link, but it appears to be updated for the more recent iOS SDK.
Add the SSID of your wifi ad hoc networks in settings. When you see the SSID of the network, click the arrow and choose connect automatically. After this, the phone will automatically connect whenever it comes in range. After this, the two devices can communicate using regular socket APIs.
When Apple's Remote app tries to connect to a Mac (running iTunes) on a local network (using WiFi), the user needs to enter a passcode provided by the iPhone as a security measure. This approach has been adopted by a number of other apps (e.g., Rowmote, Pastebot, ...). Is there an API that provides this way of working?
Assuming Bonjour is in play, how does an iPhone checks if the passcode entered on a Mac is correct without resolving the NSNetService the Mac is publishing? Or does the iPhone resolve the NSNetService a Mac is publishing and waits for the passcode to be confirmed before processing any other packets that might be sent via the NSNetService (packets other than the passcode).
I have a solution for my problem, but I would like to know if there's an API I have overlooked that provides a ready-made solution.
Advice and pointers are welcome.
Thanks in advance,
Bart
I don't believe there is an Apple provided API for this. I simply use the Bonjour APIs to open a connection between two devices, then have one randomly create a 4 digit passcode and ask the other device for it. The other device presents a UI to ask the user for the passcode, then transmits it back and waits for an answer. If they match, the devices store each other's identifiers to skip over this process the next time they connect.
Edit: Thanks to tc for pointing out that this implementation isn't totally secure. I'm now having one device create a unique, random password, and send it over to the other device, then store the SHA1 hash of the password for future reference. Then the other device stores the password and sends it back over whenever it connects for authentication. The user does the number code thing once in order to let the devices know that they should trust each other in the future, but now in order for a reverse engineer to connect to a device they would have to know both the identifier of and password for a valid, connected device. (Or they'd have to have access to both devices and do the number code thing; there isn't really a way to stop anyone from doing that, obviously).
Could someone suggest a tutorial/sample on how an Iphone application can send data to a remote server using Carrier Data Network only? In other words is there a way an application can programmatically force to enable Carrier Data Network communication, use it to send its request to the remote server and switch it back to user specific communication settings.
I am taking this approach because my application needs to send user's personal info to my server and sending it over public WiFi does not sound right. Please let me know if there is better approach to it....
Thanks
Since no one's writing a full answer ...
I don't know if it's possible to detect CDN vs Wi-Fi, although at some level it must be because the App Store is capable of determining such to prevent large CDN downloads. Of course, the App Store app has access to the private APIs; this functionality may not be exposed publicly. (I don't know if that is the case or not, but be sure you do not use private APIs for your app; the store won't accept it.)
That said, think about the use case of your app, and the marketplace. The iPhone OS and the iPhone App Store are more than just the phones themselves -- they're the iPhone and iPod Touch devices. iPod Touches do not have a CDN; they're Wi-Fi only for connectivity.
As Marc W said in a comment, not all Wi-Fi is public, not all public Wi-Fi is free, and you will likely upset a significant portion of your audience -- people (presumably and hopefully) giving you money.
A better solution would be to use SSL to provide encryption of the private data during transport. This is widely available, works over CDN or Wi-Fi, and provides all the security you should need.
If you look at the Apple Reachability example code, you can test for how you would access a host - however I agree with the other posters that you should consider encrypting your data and let your user's determine how they want to connect to the Internet, and not force one form of connection.
-t