I started with ibeacon-based(actually— lock) device development+iOS application. I can provide to iOS app the minor and major+ UUID of beacon. But, it is good only for testing.
And what if the customer bought my device and want to pair with self.iOS application. For having a unique key to opening/closing device? Sure, i can write in code the common major/minor for all my devices, but it is foolish and insecure, right? Any user with my app can open the lock with 1 tap.
So, can you help me to understand how i can pair 1 unique iPhone with 1 unique ibeacon(but they all mine) to have an 1 unique pair to communicate?
I need to do it at the 1st time after unboxing the lock.
Why don't you require the user to register to a web service after app installation, and then download the UUID/major/minor from the web service and store the identifiers in the app?
If you are distributing user-specific hardware beacons, you can have an activation code associated with each beacon that is entered as part of the registration process. One code must be tied to a UUID/major/minor on the back end.
Keep in mind that once the beacon is transmitting, anybody can read the beacon identifiers over the air using Android, Linux or OSX. So make sure your system is adequately secure.
Related
I would like to get notified when ios app is in range of other ios app even if they are both in the background mode. I know that I cannot advertise successully as a ibeacon after my ios app has gone to background because advertisement data is put in 'overflow' area. But the question is if we can extend the time that it is possible to advertise/simulate iBeacon? Are there any workarounds for this?
For example can I connect the devices in range by knowing their proximity UUID without user even knowing it? That would allow me exchange data between devices because my plan is that every user device will advertise with the same proximity UUID and the way I will identify users will be mix of major and minor ids.
Thanks in advance!
While iOS devices may not advertise iBeacon in the background, they can advertise what is known as the Overflow Area advertisement, which contains 128 bits of data. These Overflow Area advertisements are readable by backgrounded apps on other iPhones in the vicinity, provided those iPhones have their screen illuminated. (This happens even when phones are unused, as screens are typically illuminated briefly after a notification comes in.)
This makes it possible for one backgrounded iPhone app to read another backgrounded iPhone app's unique identifier passively in the background with no user interaction.
Advanced techniques are needed to configure Overflow Area advertisements, and to encode/decode unique identifiers inside them. Fortunately, I wrote up a detailed blog post of how this works, and created an open-source reference app you can use as a starting point to building your own app. This way, you don't need to master the complexities yourself to get this working.
If you build and run the reference app on two iPhones, it will assign a unique numeric identifier to each phone, and then you will see that Phone A detects the unique identifier of phone B and vice versa.
From Android documentation:
Caution: When a user pairs their device with another device using BLE, the data that's communicated between the two devices is accessible to all apps on the user's device.
For this reason, if your app captures sensitive data, you should implement app-layer security to protect the privacy of that data.
Is this also true for iOS? I haven't found anything on it and I assumed because iOS doesn't show the true MAC addresses of devices this wouldn't be an issue, but just wanted to check. Thanks
Yes, iOS also works in a similar way. And if you want private communication, you also need to maintain app layer security. Thus android wear, galaxy watch, and other similar devices use encrypted communication in the app layer.
If you already know the details. BLE communication works via Gatt Characteristics.
Consider there are two health applications running on an iOS device and the user also using an activity tracker device. In that case if the user wants to connect both of the health apps with that tracker, he certainly can do it. Both apps will be able to communicate with the activity tracker and get sensor data using the CBCentral module. Look at the diagram for Details.
On the other hand, In general, vice versa will not possible. Because if both iOS apps use Peripheral Role they will register two different instances of BLE-Service even if using the same UUID. Thus it will force two apps to communicate with completely different characteristics instances. However, it is also possible to work with two peripheral apps with the same UUID but this is not what the BLE developers ever wanted.
you need to provide app level security based on Service UUID, so that devices having the app with only same service UUID can connect.
I have written a Solution that contains two Apps,
the first app acts like a remote control app and the second app display some stuff depending on the selection of the first app.
State Now:
Currently, both apps communicate over a Bluetooth connection using the MultipeerConnectivity.framework.
Problem:
I have always to pair both apps manually starting the apps.
Solution:
Starting both apps, they should detect each other and be paired automatically.
How could I solve my Problem, is there any alternative to the Bluetooth connection or can I set up the connection to have trusted devices or something like that?
It's up to you as the developer how the pairing is implemented. You could even code a solution which requires no approval from the user; the app could pair automatically with any device looking for other peers (although this probably wouldn't be a good idea for a variety of reasons).
One possible solution for your problem:
The first time your devices pair, you generate a random UUID and save it on both devices for later use.
The next time your devices discover one another, they check to see if they have any matching UUIDs stored; if they do find a matching pair then you can let them connect automatically.
I am trying to develop one app with using a lot of beacons like say in any muti floor shopping mall. In this situation how can I control these
Suppose someone clones a beacon and starts advertsing the signal with same UUID, major, and minor, how to prevent that and what are the other security measures that can be taken?
How to avoid mutiple notifications, suppose somewhere conflicted by two beacons any area is common to more than one beacons, how to control that in app?
The iBeacon standard does not provide any built-in ways to prevent cloning. Apple restricts iOS devices from seeing iBeacons except for ones where the ProximityUUID is known, suggesting this may have been a rudimentary security attempt. But since other operating systems (Android, OSX Mavericks, Linux) allow reading identifiers of all iBeacons, this restriction seems rather silly. It is possible to read identifiers using a tool like Android iBeacon Locate and deploy your own iBeacon with the same identifiers.
Four common approaches to address this:
Do nothing. This is appropriate for most use cases where cloned beacons will cause minor consequences or for low profile deployments where the risk of someone doing this is minimal.
Rotate the iBeacon identifiers. You can do this manually by replacing beacons or manually changing their identifiers periodically. This does not eliminate the problem, but it limits the risk and impact on time.
Use an automated rotating identifier combined with an automated system for validating/converting it to a trusted identifier.
Abandon the iBeacon standard and use a proprietary beacon technology using encryption. This should be considered a last resort, because this choice makes it impossible to use widely available open source and commercial tools for working with iBeacons, and locks you into a single vendor.
Before you choose any option other than the first, be sure you carefully evaluate the risk and consequences of cloning, and be sure any countermeasure you take is really worth the downsides.
The multiple notification problem described in the question is generally not an issue in the absence of intentional cloning. Simply design the ProximityUUID/major/minor numbers of your beacons to be unique for each event you wish to give to users and make your app respond appropriately.
For beacon clone:
customize your beacon firmware and encrypt major/minor with a random key. If beacon and app both can access to cloud, maybe exchange random key via cloud to encrypt/decrypt the major/minor id. If no cloud is involved, beacon and app need to deal with a random key generating algorithm, ex use time as a seed.
(Encrypt with a forever fixed key is useless because clone or replay beacon advertising data still can cheat app)
Rotate UUID with a predefined table-based list. This just reduces the risk with a periodically changing UUID but not really fix the security issue. And the UUID list has a limited size because all UUIDs in list may need to pre-register in App, ex iOS, to let iOS take it as a recognized region and then pass data to your App.
For Multi-notification:
Usually, this should be handled by App.
When enter a region or beacon trigger callback, app should check if it is a duplicated region by uuid-major-minor info. App should also check if it is related notification/info has been sent to user or not to avoid user be bothered by duplicated notification.
There are 2 iPhone applications. One application running in the foreground and the other running in the background. Is there any way to get the background application to send data over USB without coming into foreground? Ideally we want to keep the foreground app in the foreground, while the background app process some data. Once the data is processed it will inform the foreground app that the data has been processed.
No it cannot. It cannot even do this without the use of private frameworks, unless you're in the Made for iPhone program. If you are, then your organization will know, based on the documentation made available to you, what you can and cannot access, when and how.
Should you be in the Made for iPhone program, and are unclear as to what you have access to and when, contact the person in your organization who is the technical contact with Apple for this program, they will be able to give you the details.
If the task is started while the app is in the foreground and you call the appropriate beginBackgroundTask/endBackgroundTask methods, you should be able to have it continue running after the app is backgrounded.
Note that access to USB is restricted (see jer's answer) and that there's no officially sanctioned way to communicate between different apps on the same device. Also, you can only buy/download one app at a time in the App Store and I can't see Apple approving an app that required you to download a second app for it to work. So you may have bigger problems to solve first.
It would help significantly if you told us what you actually wanted to achieve. For example, "I want MyApp on the user's phone to communicate with MyApp on the user's computer".
The absolute easiest way is to send data between the phone and a computer is to require that they're both on the same Wi-Fi network. Several iPhone apps incorporate a web server (this was the easiest way of "file sharing" before OS 3.2), and many more iPhone apps connect to a computer running server software.
Your other options, more or less:
Reverse-engineer the Bluetooth side of GameKit and reimplement it on the computer-side. I'm not aware of anyone who's done this. Loosely, I think it's IP over Bluetooth PAN plus some sort of Bluetooth service discovery.
Audio input/output, e.g. the headphone jack or certain pins on the dock connector. I'm not entirely sure how the mic side works (the resistance was a bit high for a carbon mic when I checked), but you might get lucky and find a way to turn it into "line in" or find "line in" pins on the dock connector.
A webcam pointing at the iDevice screen (and the iDevice camera pointing at the computer screen). Ewwwww.
Join the MFi program.