I need to securely paired a bluetooth device to an iOS device,
I know that in Bluetooth 4.0 and 4.1 there is three way to do the pairing : Just Works, Passkey Entry and Out Of Band (OOB).
We need to use the highest security paring protocol, which it found to be the Out Of Band (OOB) method.
I know that apple used the OOB method for pairing the apple watch to an iPhone, at least they say so in the iOS Security Guide (at the end of the page 22).
So I'm wondering is there any API from apple that I can use for pairing my device with the OBB method, or maybe you can suggest me any other secure method.
Thank you so much for your help, it's highly appreciated !
The only available bonding (pairing) method in Core Bluetooth is passkey entry.
The Apple Watch uses an OOB technique involving an image captured by the phone's camera with a fallback to passkey, but this is not available to other apps.
If your device has a display and can generate a random passkey then this technique is much the same as OOB in terms of security. If your device doesn't have a display then the security depends on how the passkey is shared (e.g. fixed passkey such as 0000 for all devices, not very secure. Random passkey for each device on a sticker is more secure)
Related
I'm writing some code (C++) for ESP32, to act as a BLE beacon. The problem is this: the iPhone doesn't send out its real MAC address, but does a random-generated MAC address, for security. The thing I'm confused about is how do you know if it's a device you've previously paired with?
So let's say I detect a new BLE MAC address, and looking at the manufacturer data I can determine it's an Apple device (first 2 bytes are "4C").
Now I need to know if I've previously paired with that device, so that I can allow the ESP32 to initiate an action (for simplicity let's just say turn on an LED). If that MAC address is in a list of known devices, then I can continue, and if not, I ignore it.
The problem is, if the iPhone is not giving up the real MAC address, the detected MAC address will never match anything. As this is a security situation I'm sure the algorithm for generating those MAC addresses is not known.
To be clear: this code is being written for the ESP32, not the iPhone.
It is in fact not possible to tell if a device has been previously seen, unless you pair and establish a bond with it. Once you pair with the device, long-term keys are exchanged and are used to quickly re-establish the connection.
This is by design. MAC addresses were originally unique, but this allowed tracking people and devices without their consent. You can read more about this in the following ESP-IDF guides:
GATT security server walkthrough
GATT security client walkthrough
So are you using esp32 as a beacon? This dose not involve any pairing or iOS MAC addresses. iOS will just be able to listen and the esp32 will not even know someone is "listening" to its broadcast.
Probably iOS application can store which services it is interested to hear to; may looks like pairing.. but it is a high level application managed technique and not any related to what BT standard calls pairing.
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'm working on an iOS application (for iOS 13+), that should use the most secure BLE pairing method, Out of Band pairing (OOB) (which usually uses an NFC tag for BLE address/temporary key (TK) storage).
Unfortunately, either my Google skills suck, or there is literally no useful information on Google for OOB pairing in iOS..
From my understanding, Apple is already using some OOB technique to pair with the Apple watch (through an image rather than NFC, with fallback to passkey).
During my Google research I've found one single link to StackOverflow,
Bluetooth “out of band” (OOB) pairing on iOS?,
which raises the same question, but it's from September 2015, so the answer there is (hopefully) outdated!
Also, having had a look at CoreBluetooth API, it seems like there is no information in there on OOB pairing..
> Does anyone have more (up-to-date) information on this topic?
Any link/clue/explanation is much appreciated!
(I can't believe really, that this hasn't been implemented in iOS as of today..)
I'm hoping to create a BLE advertisement on iOS where I can control the advertisement on a byte level.
One use case would be to mimic an iBeacon advertisement. What is the iBeacon Bluetooth Profile (I want to advertise while my app is in the background which is why I'm not using CoreLocation)
I do not see a way to do this with the Core Bluetooth API. Is this correct? Are there alternatives using private API's or jailbreaking?
As the others already pointed out, there is no API on iOS that allows you to do this.
You can advertise as an iBeacon, but only when your app is in the foreground. When in background, the advertisement is removed and therefore cannot be discovered anymore (except for other iOS devices which explicitly scan for that service UUID). Also see the documentation here: Core Bluetooth Background Processing
If you would share your use case and what you want to achieve, maybe there are other ways to realise it.
My experience with iOS is that if it is something is not exposed in the API, there is no way around, except jailbreaking. For Bluetooth low energy the API is at GAP/GATT level, and very little at the lower levels (if anything) is exposed. Advertising is a LL (link layer) feature.
To illustrate how restricted the access is: When scanning for BLE devices you will not have access to the advertiser's MAC address iOS. In Android you have it.
I do not see a way to do this with the Core Bluetooth API. Is this
correct?
Since you have to set Manufacture Specific Data in order to achieve this, if nothing has changed you will experience exactly the same issue that I did. Explained here:
The advertisement key 'Manufacturer Data' is not allowed in CoreBluetooth
It is not possible.
I am currently developing an iOS app for a BLE device which will implement the Proximity Profile (which I currently don't have access to yet), but I am at a loss as to what that actually means.
I have read the pdf document from bluetooth, and know that the BLE device would be the proximity reporter and the application the proximity monitor, but what does that mean in terms of the CoreBluetooth framework?
After connecting to a BLE device, the method I am currently using to measure proximity is through calls to readRSSI on the peripheral device. Does a device which implements the proximity profile behave differently so that I don't need to make that call? There isn't much documentation around to give a better idea.
Here is a description of the GATT services related to the proximity profile: http://developer.bluetooth.org/gatt/profiles/Pages/ProfileViewer.aspx?u=org.bluetooth.profile.proximity.xml
It looks like it allows for an attribute to read the RSSI from (I think normally you can read that value from a lower level method directly from the transmitter/receiver). So you should be able to read the RSSI value on both ends of the connection.
The profile also allows for alerts to happen on both ends and you can control what level of alert occurs.
I think essentially, a "profile" is just a collection of attributes in GATT. If you have the required attributes you can state that you support that particular profile.
Here's a PDF with the little details if you want: https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=239392