I am attempting to create UUID's that incorporate security measures that prevent replay attacks. I plan to attach a timestamp to the UUID and Encrypt the beacon. The encryption creates a 16 byte object but The Beacon Transmitter requires the UUID to be a string of consistent length. Is there a way I can transmit a Byte object instead of string. Also, I need the encrypted beacon to change with the time. Should I do a:
beaconTransmitter.startAdvertising(beacon);
timeout(1 second);
beaconTransmitter.stopAdvertising(beacon);
and recursively call my beacontransmit method?
If your encryption really makes a 16 byte object, then you should be able to convert it to a UUID, which is also 16 bytes long. It should be as simple as:
Identifier uuid = Identifier.fromBytes(byteArrayOfLength16, 0, 15, false);
However, encryption algorithms typically make a much longer byte array as the output. You could remove all but 16 of the bytes from the encrypted output to make a hash (this is basically what Eddystone-EID does), but this won't be able to be decrypted. The receiving device would have to perform the same encryption calculation for a given timestamp to see if it calculates the same value. If it does, it knows it has found a match.
Yes, the approach of starting advertising based on one timestamp, waiting for a delay, and starting advertising based on a new timestamp is certainly the way to go.
Related
I understand that in Android, the MTU for writing data to a Characterisitc is around 23 bytes (3 bytes used so you have around 20 bytes free) and that you can request a higher MTU (up to 512) to allow you to write/send larger data packets to a bluetooth device.
However, do you also need to do this when reading data from a characterisitic?
Both Reading and Notification updates?
If say, I have a characteristic that sends data in 123 byte chunks, but I only ever have to send at most 2 bytes to it, do I need to negotiate a large MTU?
I can recommend you to read the ATT and GATT chapters in the Bluetooth Core standard. Those explain the protocol.
By default Android does not negotiate a larger MTU than the default (23 bytes). You can do that yourself though by calling the requestMtu function.
Android automatically under the hood uses "Write Long Characteristic Values" and "Read Long Characteristic Values" when the MTU is not big enough when reading/writing values in order to transfer the whole value. However these procedures are very inefficient since they require multiple roundtrips. The read operation also is not atomic.
Notifications and Indications don't have any "Long" variant with multiple roundtrips, so these will be truncated to fit the MTU.
How can I access the raw payload data of a Scanned Beacon using the altbeacon library?
The Android Beacon Library is not designed for this purpose, so the APIs to do what you want are a little awkward.
Upon detection the library automatically parses payload and converts the bytes to a beacon object. But because the library also supports transmission it has utilities to convert a beacon object right back to bytes. If using iBeacon, you can convert a detected beacon back to raw bytes like this:
BeaconParser iBeaconParser = new BeaconParser()
.setBeaconLayout("m:2-3=0215,i:4-19,i:20-21,i:22-23,p:24-24");
byte[] payloadBytes = iBeaconParser.getBeaconAdvertisementData(beacon);
In general, this is a lossless process, as beacon formats typically use up every byte of the payload. In the unlikely event that you have a custom beacon format that does not use all the bytes, you would need to alter the format slightly to add extra data fields at the end so that the full payload is parsed into the beacon. Otherwise you will lose these extra bytes in the conversion.
In the application I am looking forward Bluetooth in Beacon is very good option as I want to collect PH from different sources to the application so I can't pair my android device with all the BLE devices at a time as it will be around 20-30.
But I can see that if there is Beacon then Android can scan all of them and also get the RSSI of all devices without being paired with them.
So is it possible that we add few other parameter for example PH, Temperature, Humidity and 3-4 other parameters so Beacon is going to broadcast all these parameter along with RSSI and in Android app I can collect all the information?
I am not sure if this is feasible solution or not and if it is then how to achieve this in beacon?
Bluetooth beacons generally rely upon advertisement packets to send data, which are limited in the number of bytes available. For manufacturer advertisements, you basically have 24 usable bytes to work with, although you need to reserve some of these as a flag to indicate it is your beacon format, and not somebody else's beacon format.
You can look at the AltBeacon spec as an example. This format uses two bytes to identify itself (the "beacon code"), 20 bytes of beacon identifiers, one byte of data and one byte for reference RSSI. You probably still want a unique identifier for each beacon so you know which beacon sent you the information. But you might be able to cut this down to four bytes for your purposes, which would allow you to have 2^32 different beacons sending this information.
The Android Beacon Library lets you both transmit and receive beacons using arbitrary formats you can define using the BeaconParser class. A beacon format that uses a four byte identifier, two bytes each for PH, Temperature and Humidity data fields, and two bytes each for five other data fields might look like this:
m:2-3=abcd,i:4-7,d:8-9,d:10-11,d:12-13,d:14-15,d:16-17,d:18-19,d:20-21,d:22-23,p:24-24
Is there someone using blob request (long read) from an android device?
We work with a CC2540 from TI, connected to a android 4.4.
We try to read a long characteristic value (size more than 23 bytes). In the android API for BLE, we have not seen a readBlob or readLong method.
We expect that the Android BLE Stack do the job for us, by reading a characteristic presentation format (same way has notification), but it doesn't works.
We have no idea how to send Blob Request through Android.
Let me make this clear that Android has only one method to read the value of a characteristic, readCharacteristic(characteristic). You can use this method to get the value of a characteristic of any length. Android takes care of forming a ReadBlob request; it's all in the back end. You'd have to change the code of your CC2540 though, to make it work with ReadBlob request. Once you make all the required changes at your CC2540 end, on calling readCharacteristic() from Android, you'll get the entire value of the characteristic which you can access in the onCharacteristicRead() callback.
You can´t, BLE characteristic values are limited at 20 bytes. So if you want to send or receive more than 20 bytes, you have to split it into 20 byte chunks. See this topic on the issue.
Does anyone know how to print/read/get the value of a Byte stored in a BluetoothGattCharacteristic? I am receiving data from a BT Sensor and need to figure out what the correct read format should be: ex. SINT8, UINT8, FLOAT.
I am hoping that once I get that byte value, that will clue me into the equation needed to convert that value to a usable unit of measure.
Thanks
You could try BluetoothGattCharacteristic.getDescriptor() for UUID 0x2904, i.e Characteristic Format.
This descriptor value, if present, will describe the format of the BluetoothGattCharacteristic value.
See https://developer.bluetooth.org/gatt/descriptors/Pages/DescriptorViewer.aspx?u=org.bluetooth.descriptor.gatt.characteristic_presentation_format.xml
In most cases the set of bytes is just going to be quite literally just that. It is dependent on how the client device decides to write the data onto the characteristic. The one thing that should probably be taken into account is if its little endian or big endian, because any convertor that you use in Android would be big-endian I believe.