I'm working with ANT+ protocol, to connect a smartphone with an ANT+ USB dongle, which is connected to PC where with SimulANT+. SimulANT+ is simulating a heart-rate sensor, which sends data to my phone.
Until now I have been using a non-encrypted channel to communicate, but there is also an option to make a secure connection between devices as is written in ANT Message Protocol and Usage document. It's called Single Channel Encryption. Do someone have some code examples on how to establish this type of connection?
It is true that ANT protocol can use a single encrypted channel - however this is not the case for ANT+. (See the differences between ANT/ANT+ here: http://www.thisisant.com/developer/ant-plus/ant-antplus-defined)
If you use encryption for your device it is no longer ANT+ compliant and therefore you are not allowed to use the ANT+ Network Key or frequency.
This is because ANT+ aims to ensure interoperability between different manufacturers sensors/displays. If the channels were allowed to be encrypted, this would defeat the purpose ANT+.
Therefore if your goal is to use your device with SimulANT+ (or any existing ANT+ sensor) it will not work. In fact, SimulANT+ does not even allow the utilization of encrypted channels.
Related
I want two BLE devices to connect to each other, and exchange data bi-directionally.
These devices are exactly equivalent - this is basically a serial cable between two peers.
There is not one 'store of data', or hierarchy between the two.
Both ends basically transmit data to each other (there is no polling for 'read' data), and no acknowledgement is required.
BLE documentation refers to the Characteristic Properties as:
A Client can send data to the server with 'write'
A Server uses a 'notify' characteristic (which the Client subscribes to)
So basically I have just one question:
Can I just have one Characteristic, with two properties
'Notify' (writing to Client) and
'Write' (writing to Server)
That the Peripheral advertises, and this will enable two-way write behavior?
First a few things to make everything clear, in case somebody wonders:
BLE has the concept of Central and Peripheral. Peripherals advertise their presence. Centrals scan and discover peripherals which they then connect to. Once the connection is created, these link layer roles do not really matter in terms of GATT and L2CAP Connection oriented channels, which are both used to transfer data.
Every device (including centrals) supporting connections over BLE must have a GATT server. While it is far more common that the peripheral only uses the GATT server role, it can act as GATT client. Centrals can also act as GATT servers. Furthermore, the both GATT roles can be supported simultaneously. Both sides can for example expose an identical GATT server characteristic with the write property. Not sure if this is a common approach though.
Now, back to your question. You can definitely have one characteristic both having the "write" and "notify" capabilities. When you write, I would suggest using "Write without response" since that has better throughput than "Write with response", since it does not require an acknowledgement between every write. Over the link layer, all kinds of packets are still sent "reliably", meaning there will be no packet drops unless the whole connection drops.
I would however suggest you to have one characteristic per direction. The reason is that some Bluetooth stacks can not in a thread-safe way both send and receive data on one single characteristic, due to the API design structure. In particular, Android's API has one method to set data on a characteristic and another method to send the current data of a characteristic. If a notification arrives in between these calls (where the bluetooth stack internally assigns the new data to the characteristic), the write operation will send the data that was just notified, instead of the intended data.
You could also check out L2CAP Connection oriented channels (introduced in Bluetooth v4.2) which is a good way to transfer raw data byte packets, when the GATT structure is not appropriate.
I'm doing a security analysis project on an IoT device that uses an unencrypted BLE connection (with ATT protocol) and I want to spoof an individual BLE packet with the source address of an already connected device. Is there some tool or API that would allow me to do this easily? I've already tried gatttool and spooftooph but they seem to be connection based and don't allow you to send out single packets with modified fields (as far as I could tell).
You will need some hardware where you can access the radio peripheral directly. What you basically need to do is to find or write a ble sniffer firmware, with the modification that it at a given moment sends a packet on the connection it is currently listening to. But note that the signal strength must be stronger than the original device's signal so it doesn't interfere.
The only open source project I'm aware of is Ubertooth. You will also be able to do this with an nRF52 but then you need to write your own sniffer firmware since Nordic Semiconductor's is closed source.
I can't comment on Emils reply yet, < 50 rep:
Nordic Semis nRF Sniffer v2 needs only the nRF52DK and wireshark to work as a general BLE sniffer. At 40$ it's not that expensive. I know for a fact they will release a new dongle soon that will sell for ~10-15 bucks if you can wait a a month or two.
At the flowcharting stage of my program. I would like to save energy by sending a couple of attributes in my advertising broadcast message but am worried that a radio closer to my central could spoof my message and supply bogus data using my advertisers address. Can I pair then bond and then use encryption keys to encrypt my two attributes in the broadcast message? Please refer me to a more appropriate forum if this question does not belong here.
The normal Bluetooth Core standard does not define any way of securing advertising data. The encryption keys exchanged at pairing can only be used for securing an established connection.
You have to invent your own layer or use for example Bluetooth Mesh.
I want use Alljoyn to communicate between devices in smart factory.
However,it seems there is no such use cases not yet.
So,i want to know if Alljoyn can't be used in factory for some technical reasons,
for instance,stability or performance.
In my case, I need device can communicate directly.
So,publish-subscribe-based protocol,like MQTT,wouldn't work for me.
I don't get the specific problem of your case. But I'm going to answer anyway.
AllJoyn runs on the proximal network (local network) by using Wi-Fi, Ethernet or Power Line (PLC). And AllJoyn does not require a cloud to function, cloud network connection is optional. It works in your case as long as the local network functions properly.
Transport name Value Description
TRANSPORT_NONE 0x0000 No transport.
TRANSPORT_LOCAL 0x0001 The local transport.
TRANSPORT_TCP 0x0004 Transport using TCP as the underlying mechanism.
TRANSPORT_UDP 0x0100 Transport using UDP as the underlying mechanism.
TRANSPORT_EXPERIMENTAL 0x8000 Select a release-specific experimental transport.
TRANSPORT_IP 0x0104 Allow the system to decide between TCP or UDP.
TRANSPORT_ANY 0x0105 Allow the system to choose any appropriate transport.
AllJoyn supports both TCP/IP and UDP/IP transport mechanisms. While developing your app, you can decide to use which transport mechanism you want.
AllJoyn documentation states that;
If an AllJoyn application desires to only use TCP as the underlying
layer 4 mechanism, it can do so by specifying TRANSPORT_TCP in
advertisement, discovery and Session join and bind options.
As TCP guarantees all sent network packages will reach their destination in the correct order. In your case you can choose TCP communication as a more reliable option.
I have read this somewhere:
Most mobile operators encrypt all mobile communication data, including SMS messages In GSM, messages are encrypted using A5/1 but even when encrypted, the data held by SMS is readable for the operator. Mobile phone operators have the ability to filter and modify short messages during delivery. Also, it is possible that the operator might not filter messages on purpose but might use equipment that cannot handle encrypted messages.
I want to know..is it true..?
Can someone explain how this filtering is done..? and is there any solution to avoid such loss of messages on the network..?
A5/1 is being used on the radio link between mobile and base station controller (BSC, the network entity entity that manages the radio resources). The radio link transports a couple of higher level protocols, among them MAP which is used to transport SMS.
The BSC is relaying SMS over MAP into the core network. The protocol stack between BSC and core network is not encrypted as well as the communication inside the core network. This was deemed as not needed at time GSM was designed, the links are supposed to be mobile operators very own property and territory and therefore assumed being secure.
The core network typically delivers SMS to an SMSC (short message service center) which is reponsible for routing messages to receipients.
A network operator can read SMS in clear text in various places, e.g.
With a protocol analyzer, tapping links between network nodes
On the SMSC, in message queues (databases...) or even log files
On an MSC when tracing MAP messages
Message filtering and modification may happen on the SMSC, depending on the network operator needs.