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/
Related
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.
I need to send remote APNS notifications from my server application to my iPhone applications. I want to know the frequency with which I can send remote APNS notifications in the following scenarios:
From my server application to the iPhone application on the same device.
From my server application to the iPhone applications on different devices.
I know that Apple has set some limit on this, but I do not know the limit.
Thanks
As per my information Apple has not specified any specific limit but following text in programming guide of service.
Apple Push Notification service continually monitors providers for irregular behavior, looking for sudden spikes of activity, rapid connect-disconnect cycles, and similar activity. Apple seeks to notify providers when it detects this behavior, and if the behavior continues, it may put the provider’s certificate on a revocation list and refuse further connections. Any continued irregular or problematic behavior may result in the termination of a provider's access to APNs.
Following paragraph is given here
If you find any further details then post here......
I want to write an iOS app that can act as a client and a server to other iPhones over the cellular data network (i.e., without a typical centralized server). The goal is to share series of about 200 short event messages, one at a time, from the iPhone server to multiple iPhone clients by some means of notification. Apple Push Notification service would be fine for such notifications, but there is no need to use it specifically.
I think sending push notifications from one iPhone to another is possible by connecting to gateway.push.apple.com from the serving iPhone as described in the Local and Push Notification Programming Guide, but I can't find anyone else discussing this approach (maybe it's too obvious?).
The reason for all this is an attempt to avoid the overhead of infrastructure. If this isn't feasible, alternatives which minimize or avoid additional hardware are welcome.
Requirements:
Communication must be [strictly] over cellular data network
Wi-Fi isn't available
Bluetooth doesn't have enough range
Unidirectional communication with an iPhone server multicasting to many iPhone clients
No jailbreaking
Ideally the serving phone's battery will be able to handle this without a recharge
Update 5/4/11 2:12 AM EST: Just to be clear, I don't have any particular requirement to use APNs; I thought it may have been feasible in this setup, but from the discussion below, it sounds like that's not the case. However, I'm still interested in any other system that could help me achieve the same end result with some type of message passing or similar form of communication.
Theoretically you should be able to write a iOS app that can connect to the APNS and send notifications to other devices running your applications. However, your main problem will be to actually acquire the 'tokens' of other devices. When you have a centralized server doing the job, its always online and thus, the clients can 'talk' to it via http and register them self (giving their tokens to the server in the process). Thus the server knows the client token and it can use them to send notifications to the clients via APNS.
However this is not possible in the scenario you are talking about. But this is not to say its impossible. May be you could use an email account X, to store all client tokens. Every client will send a email to this account with their token in it. So when a another 'client' want to send a notification to another client, it can find out the token by reffering to the inbox of the email account (you can cache this stuff and optimize it in a zillion ways of course).
But the point is some how a (third party(ex: email service provider)/your own) server that is online 24/7 will be involved in the process.
Let us know how you progress with this. It would be interesting to know.
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