I've been looking for BLE materials to get answer to this. But I could not get in any. Though practically/logically speaking, peripheral should decide I want to see if it is documented some where. Any links with this information will be very helpful.
On iOS, at least, if the peripheral specifies that encryption is required for a characteristic then iOS Central will initiate a pairing operation when access is attempted. If encryption isn't required then no pairing takes place - The central can just initiate a connection.
So, in summary -
The peripheral 'decides' if pairing is required through the definition of its characteristics.
The central manages the pairing process when required.
On "Just Works"; my understanding is that this is pairing where neither device can display a passkey, or allow the user to input one. It is NOT an unencrypted connections.
While your general iOS device can do both, many devices, such as an toothbrush handle, can't, but can still require "just works" pairing and bounding. This is also called unauthenticated pairing with encryption. It appears that iOS will prompt the user to accept a pairing request if the peripheral can't display a passkey.
Related
I use the Ble library, but I want to connect/pair only the first device/phone. After this only the first device is allowed to reconnect. How do I implement this? Is there a best practice? Do I need to filter the deviceid? Or are there better ways to acchieve this?
That can be achieved using the Filter Accept List (previously known as White List), which is standard in the BLE spec. How to use it depends on the Bluetooth stack you are using, so you should check the manual for the Bluetooth stack you are using (you didn't mention).
If you want to support Random Resolvable addresses, you can use the Resolving List where you put the corresponding IRKs.
But a personal opinion is to instead always let any device connect to your device, and then secure sensitive services using MITM-secure authentication instead (pairing). That could potentially lead to a better experience for the user, because otherwise any connection attempt from "wrong" device will just lead to a unknown connection error from the user which might be hard to understand.
I want to know if my BLE 5 (low energy, not "typical"/core bluetooth) embedded system uses (preferably asymmetric) encryption, if encrypted at all.
I'm using this ble module that is communicating with an SOC. My SOC is capable of encryption but the FAE of the BLE module product couldn't come up with any useful information.
My program doesn't appear to have a bonding/pairing process, but I could be wrong since I did not take a closer look at the HAL layer program.
My question is, does BLE 5 require encryption?
If not, how do I find out if my connection is encrypted or not, using methods other than sniffers? For example are there any steps which must be gone through to facilitate encryption, in which case I should check if these steps were skipped or not? (If skipped then surely my communication is in plain texts).
ETA: The target BLE module is based on nrf52832, don't know what BLE stack/softdevice they are using. My soc is STM32WB55 series, using a rather comprehensive BLE stack that supports most functions of which name I couldn't recall for the moment.
BLE does not require encryption for a connection to be made.
At first, every BLE connection starts in Security Mode 1, Level 1 which does not use any encryption at all. Every message will be sent in cleartext. To increase the security two devices have to "pair". Security keys are exchange during the pairing process. There are multiple different pairing methods with different requirements. Have a look at this article for a starting point.
The pairing process is usually not started manually but automatically as soon as a device tries to access a secured characteristic. If you are using a phone to access such a characteristic you will be prompted with a pairing request popup. Based on your description I would assume that your connection is currently not encrypted.
To enable encryption on your SoC please have a look at the function aci_gatt_add_char. This document (direct download link) refers to this function on page 55 and shows that it takes Security_Permissions as an argument. The next page states the possible options as:
0x00: ATTR_PERMISSION_NONE
0x01: Need authentication to read
0x02: Need authorization to read
0x04: Link should be encrypted to read
0x08: Need authentication to write
0x10: Need authorization to write
0x20: Link should be encrypted for write
I've been working on a device that includes an ESP32. I set up a secure GATT server similar to the Secure Gatt Server Example with a custom service with Man in the Middle (MITM) based encryption. Currently pairing setup is Just Works, and when a client connects to the device they are prompted to pair and thus are bonded with key exchange (although it looks like Justworks disables MITM when I did more investigation for this question).
We do not have any real IO except for one button on the device, but I would like to limit pairing to a certain window of time after the Pairing button is pressed, or to have a "pairing mode" that the device enters (I have worked on another device that may have more of a classic pairing mode that was easier to work with). I know that's not explicitly part of the IDF API, but I'm looking for some guidance on how to approach something like a "pairing mode."
Would setting the IO capability to ESP_IO_CAP_IO work for using a button for the Yes/No? I don't see anything relevant in the documentation about how to configure this. In fact the enum does not appear elsewhere in the IDF sourcecode, nor does the mentioned relevant file stack/btm_api.h help.
Is there a way to disable / enable pairing on command? Would it be some type of change to advertising?
The Cloud IOT online documentation page "Device Security" describes a device provisioning process where a "Provisioner" creates a key pair, and distributes the private key to the Device. They go a step further and recommend using a revolving key strategy for added security. All steps in this device creation process can be automated using IOT core API's, with the exception of the key distribution step.
This alludes to there being a way to safely create the key pair, and transmit the private key to the device programatically for thousands of new devices rather than by hand for each device. Similarly there must be a way to generate and transmit new key pairs in the revolving key strategy.
Any suggestions on how to do this? Perhaps there is a standard method that I am not aware of. Thanks in advance for any feedback.
This alludes to there being a way to safely create the key pair, and
transmit the private key to the device programatically for thousands
of new devices rather than by hand for each device.
I believe the language here is deliberately less specific to allow room for cases when a device builder has a secure or unique way (e.g. encrypted radio) of transmitting keys to devices. In many cases, you will have a hardware-specific or OS-specific solution for updating device firmware and this mechanism is the best approach and allows you to revoke and recover compromised devices.
I think there are really two core buckets of approaches to distribution of the private key to a given device:
Distribution / initialization at manufacture / late-manufacture stage (secure)
Distribution post-manufacture (e.g. after device has been purchased / installed / deployed)
For distribution at manufacture or late manufacture, you generally are going to be installing the keys to the device using something that is physically connected to the device in a secure environment. At manufacture, I would imagine at the manufacture facility the (contract) manufacturer calls the API using delegated credentials to send Google the public key and then securely installs the private key on device. At late manufacture, the same registration process and secure installation of the private key occurs, it's just done outside of the manufacture facility by the person contracting to manufacture the device.
In both cases of device registration at manufacture, you can register multiple certificates per-device so that you can "change your password" effectively over time by rotating through the certificates associated to the device by expiring certificates or can revoke suspicious certificates, using additional on-device credentials. In some circumstances, this is good because if only one of the on-device credentials leaks, you can switch to an on-device, secured-at-manufacture alternate. There is a minor trade-off to this approach in that if multiple credentials for a given device can leak, you will have the banal risk of having multiple credentials leak at once. And this leads us to the second bucket of key distribution, post-manufacture.
For distribution of the private key after manufacture, it gets a bit more complicated because you're effectively creating another channel for devices to be managed in your registry. For this reason, it's difficult to advise on what to do should you not have an established secure channel for completely recovering a compromised device remotely.
What all would be the requirements for the following scenario:
A GSM modem connected to a PC running
a web based (ASP.NET) application. In
the application the user selects a
phone number from a list of phone nos.
When he clicks on a button named the
PC should call the selected phone
number. When the person on the phone
responds he should be able to have a
conversation with the PC user.
Similarly there should be a facility
to send SMS.
Now I don't want any code listings. I just need to know what would be the requirements besides asp.net, database for storing phone numbers, and GSM modem.
Any help in terms of reference websites would be highly appreciated.
I'll pick some points of your very broad question and answer them. Note that there are other points where others may be of more help...
First, a GSM modem is probably not the way you'd want to go as they usually don't allow for concurrency. So unless you just want one user at the time to use your service, you'd probably need another solution.
Also, think about cost issues - at least where I live, providing such a service would be prohibitively expensive using a normal GSM modem and a normal contract - but this is drifting into off-topicness.
The next issue will be to get voice data from the client to the server (which will relay it to the phone system - using whatever practical means). Pure browser based functionality won't be of much help, so you would absolutely need something plugin based.
Flash may work, seeing they provide access to the microphone, but please don't ask me about the details. I've never done anything like this.
Also, privacy would be a concern. While GSM data is encrypted, the path between client and server is not per default. And even if you use SSL, you'd have to convince your users trusting you that you don't record all the conversations going on, but this too is more of a political than a coding issue.
Finally, you'd have to think of bandwidth. Voice uses a lot of it and also it requires low latency. If you use a SIP trunk, you'll need the bandwidth twice per user: Once from and to your client and once from and to the SIP trunk. Calculate with 10-64 KBit/s per user and channel.
A feasible architecture would probably be to use a SIP trunk (they optimize on using VoIP as much as possible and thus can provide much lower rates than a GSM provider generally does. Also, they allow for concurrency), an Asterisk box (http://www.asterisk.org - a free PBX), some custom made flash client and a custom made SIP client on the server.
All in all, this is quite the undertaking :-)
You'll need a GSM library. There appear to be a few of these.
e.g. http://www.wirelessdevstudio.com/eng/
Have a look at the Ekiga project at http://www.Ekiga.org.
This provides audio and or video chat between users using the standard SIP (Session Initiation Protocol) over the Internet. Like most SIP clients, it can also be used to make calls to and receive calls from the telephone network, but this requires an account with a commercial service provider (there are many, and fees are quite reasonable compared to normal phone line accounts).
Ekiga uses the open source OPAL library to implement SIP communications (OPAL has support for several VoIP and video over IP standards - see www.opalvoip.org for more info).