Currently we are setting up a Bluetooth LE device specification and we are running against the following:
The client doesn't want to pair the device via the settings menu. There is a mobile app which should connect to the peripheral.
Now the following, this is the problem:
When connecting, how do we secure our characteristics? We were thinking about prefixing a write request, but what about read requests?
We don't want everybody to see the not so sensitive data. Since it's not sensitive we don't need high security but we still need to secure it some way just in case.
Does anybody know how to do this? How to secure a characteristic?
Thanks in advance,
You could implement a challenge-response system on connection - when you connect to the peripheral you read a value from a characteristic which is randomised by the peripheral. This value has to be hashed in some way using a shared-secret and then written back to the characteristic. The peripheral then verifies the hashed value. If it matches then it populates the other characteristics and accepts write requests.
Once the central disconnects from the peripheral it ignores write requests and zeros its read characteristics until the next connection/hash handshake.
You must add Security Mode 1 Level 3 to your Services. Then, all the Service's characteristics will be protected.
Related
first of all: What i am trying to do is only for private interest.
I'd like to connect a AT-09/HM-10 BLE-Module with Firmware 6.01 to another device which provides also a BLE Module, which it is not based on the CC254X-Chip,
I am able to communicate with this Device using my Laptop with integrated Bluetooth, Linux and the bluepy-helper. I am also able to make a connection using the HM10 through a USB-RS232-Module and "Hterm", but after that quite Stuck in my progress.
By "reverse-engineering" the Android-Application for controlling this particular device i found a set of Commands, stored as Strings in Hex-Format. The Java-Application itself sends out the particular Command combined with a CRC16-Modbus-Value in addition with a Request (whatever it is), to a particular Service and Characteristic UUID.
I also have a Wireshark-Protocol pulled from my Android-Phone while the application was connected to the particular device, but i am unable to find the commands extracted from the .apk in this protocol.
This is where i get stuck. After making a connection and sending out the Command+CRC16-Value i get no response at all, so i am thinking that my intentions are wrong. I am also not quite sure how the HM-10-Firmware handles / maps the Service and Char-UUIDs from the destination device.
Are there probably any special AT-Commands which would fit my need?
I am absolutely not into the technical depths of Bluetooth and its communication layer at all. The only thing i know is that the HM-10 connects to a selected BLE-Device and after that it provides a Serial I/O and data flows between the endpoints.
I have no clue how and if it can handle Data flow to certain Service/Char UUIDs from the destination endpoint, althrough it seems to have built-in the GATT , l2cap-Services and so on. Surely it handles all the neccessary communication by itself, but i don´t know where i get access to the "front-end" at all.
Best regards !
I'm creating a web app which connects to a control device. I want to secure it to make sure no one but the user can control it. for that I want to use LE secure connection pairing with numeric comparison. But my control device doesn't have a display, so I want to send the security code to my web app so the user can check the code's there and 'ok' the connection on the web app.
I wonder if this is possible and if I don't lose security while doing it this way
How do you plan to send the security code to the web app? To do it programatically implies that you already have a secure channel to the device.
On devices without a screen I've seen the security code printed on a sticker. It isn't as secure as a code which can change every time a new pairing occurs but is better than no code at all.
If the device has a button you can require the user press it before pairing or other privileged actions are taken.
I am working on 802.11i security implementation and I am stuck quite at the beginning. My work is based on existing framework which broadcasts open WiFi network and devices are successfully able to connect.
In order to inform STAs of access restrictions, I added RSN (Robust Security Network) element into Tagged parameters of Beacons and Probe Response frames. I defined both suites (Group and Pairwise) with 802.11 standardized values setting to AES and AuthKey setting to both PSK and 802.1X.
After this frame is sent, no Authentication Request is generated from STAs and I got response on all of them (Win7, Android and iOS) that device cannot connect. I compared Wireshark traces with multiple connection establishments, and cannot figure out what doesn't add up. Only thing I modified is addition of RSN and this RSN is absolutely the same as in other production connection attempts.
What I thought is that either device rejects frame because of improper implementation/format, or it doesn't support offered security mechanisms. But then - removing RSN field (making network open) allows STAs to proceed with Authentication Req; and looking into Probe Responses from real APs, they have the exact same structure and contents of RSN.
And other interesting behavior is that Apple device (iPad) doesn't even recognize network as secured with RSN field implemented while both Win7 and Android do.
Any ideas what am I missing or misunderstanding?
Screenshots: First is working real communication, second is my implemented modification.
I am working on a project where an Arduino will send measurements and receive commands through an Ethernet interface and a REST API to open and lock a door. For all means, we can consider that the devices are protected, but that the Ethernet network may be accessed. Therefore, a Man-in-the-middle attack is plausible.
The commands to open/lock the door will be part of the reply of an HTTP GET request. In order to prevent a MITM attack where the response is faked to open the lock, I want to use some kind of encrypted response. Now, Arduinos lack the power to use HTTPS, and I want it to be Arduinos because of costs and ease of development.
I have come up with the following scheme:
Both the Arduino and the server have an identical set of index-value registers. The value will be used as a code to encrypt using AES-128.
When the Arduino sends its GET request, it also sends a randomly selected index, indicating to the server which value to use to encrypt the open/lock command.
The server sends a clear text response (JSON) where the command field is an encrypted text.
The Arduino will decode it and apply the required action.
The Arduino will also send some sensor data from time to time. In this case, it will send the index of the code it used to encrypt the data and the encrypted data.
The set of index-value keys is large, so repetitions are rare (but may occur from time to time).
My question is, is this scheme secure? Am I missing something? Is there any other more tested alternative for securing these interactions that doesn't involve using a more advanced platform?
Thanks in advance!
Use an ESP2866 based Arduino. It does not cost significantly more, it uses the same tools but you can use SSL instead of rolling your own solution. I have used the Wemos D1 boards and they work as a drop in Arduino replacement.
I am developing a mobile application which sends some encrypted data to a Bluetooth device and this Bluetooth device sends the data to server. My question is that in this case how can I prevent replay attacks. Someone might use a fake Bluetooth device to get the signals and send them to the server.
The mobile application works in offline mode and has no connection to server. So using a synchronized nonce or counter doesn't help.
I can not also use time-stamp to narrow the attack window because mobile phone's time might not be correct (synchronized with a time server).
Communication between my mobile application and Bluetooth device is one-way and my mobile application can only send data to the device.
One way to do this would be to use a counter, but allow it to skip a large number of steps. For example if the last counter value you've seen from phone A is 123 and you get something with a counter value of 156 then you accept it, but anything outside the range of [124, 1000123] you discard (1000000 being completely arbitrary and dependent on your use case).
This would prevent a replay attack, but you do have to take care that the transmissions aren't malleable or it would be trivial to forge counter numbers. This could be accomplished by having a secret per device MAC key (which would only be possible if the server and phone communicate beforehand).
It's worth stating that it would be good for the transactions to be authenticated (only phone A has the capability to generate a message saying it's from phone A) or an attacker could move up the counter very quickly and do a denial of service on phone A. However, from the way you phrased the question it sounds like it's something you've already dealt with.