SMS encryption over GSM - encryption

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.

Related

Are BLE devices required to respond to a SCAN_REQ requests?

I have a BLE device that doesn't respond to SCAN_REQ and am working it out with the vendor independently per https://github.com/espressif/esp-idf/issues/10660.
When I use Nordic nRD Connect iphone app as a client I can see that device in the scan list and can connect to it. However, when I use a different client, a python Windows one, that client doesn't show the device in its scan list and doesn't connect to it if I specify the exact address.
My question is, are BLE 4 devices required to respond to SCAN_REQ requests to be discoverable and connectable or is it just optional response to provide additional advertisement data?
EDIT, I believe that Emil's answer below (thanks) refers to this quote
Yes, it's required to reply with a scan response. That is defined in Bluetooth Core v5.3, Vol 6 Part B (Link Layer), section 4.4.2.3, using the word "shall".
There is one exception though. There is a Filter Accept List in the controller which can contain addresses of centrals allowed to scan and/or connect. There are four combinations the host can set (advertising filter policy) that control if this list shall be used for filtering incoming SCAN_REQ and CONNECT_IND packets, respectively. If you don't use this filtering mechanism, then the device must send a scan response to every scan request.
There are two possible approaches to scanning—Passive Scanning or Active Scanning.
Passive Scanning is when Scanners receive advertising packets and process the contents.
In the case of Active Scanning, however, a device may decide it wants to know more about an advertising device and respond to the initial advertising packet by sending a Scan Request GAP protocol data unit (PDU). This basically means ‘Tell me more.’ The device receiving the Scan Request can send back a Scan Response PDU with more information, once again in the form of a collection of AD types.
The above has been extracted from: https://www.bluetooth.com/blog/advertising-works-part-1/ [the emphasis mine].

Once BLE bonding is comptete, can I use encryption keys to encrypt a broadcast message?

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.

Implement notification in BLE

How do I implement notification in BLE?
I have a smartphone, and every hour it will send notification to all nearby BLE devices (smartwatch, RFduino, etc) for time synchronization purpose.
Other devices are server now (since it provides data), and smartphone is the client that collect the data.
Could I piggyback into the advertisement packages? For example, the smartphone always broadcast an advertisement packet to annoucement its presence (that's how other devices can find it). Can I modify that packet to be a time sync?
In order to send notifications or advertisements, your smartphone has to act as a server, which also means that in order to be able to receive notifications or scan for advertisements, your peripheral devices must act as clients.
This can be a bit tricky, because if two devices act as client and server, they may not simultaneously fulfil the other role. You need to switch roles whenever needed, which is an open field for all kinds of problems.
Also, I am not convinced that it is really the optimal choice to let the smartphone regularly notify all devices in the vicinity. Each of the devices that wants to receive the notification has to be connected with the device in order to receive the notification, and this connection has to be already active when the notification is sent in order to really get the correct time. So all these devices need to connect in advance to the expected notification time, and hold up the connection until the notification has come.
It might be better to just advertise the current time, but remember that you can't connect to the smartphone as a server while it is advertising, because the link layer may not be in scanning and advertising mode at the same time, and you may also not be connected when advertising for a similar reason.
If you want to do it that way, you can include the time information in the advertising data. See the Supplement to the Bluetooth Core Specification v6, Part A for further information on the structure of the advertising data. You could put it in the manufacturer specific data.
However, another option would be to write the time directly to the device using a write request. You can define your own service and characteristics. You can include a "time synch necessary" information in the advertisement data of the servers, and when the smartphone evaluates the advertisement, it can connect to the corresponding device and send the time directly.
The advantage of this procedure is that time is only updated if you really need it on the device, and that you do not have to switch client/server roles, because the device in server role may advertise as normal, and the smartphone can always stay in client role.

ANT+ Single Channel Encryption example

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.

Transmit or Simulate SMS-CB (Short Messaging Service-Cell Broadcast)

Can a cell phone transmit SMS-CB (Short Messaging Service-Cell Broadcast) ?
If not, Can I get a device that can transmit SMS-CB messages ?
Else, Is there a good simulator that can simulate SMS-CB transmission and receiving mobile phones ?
Thank You
NOTE: Cell Broadcast (SMS-CB) is designed for simultaneous delivery of messages to multiple users in a specified area. For example, information such as Location, Tower name, Ads or Emergency messages can be transmitted.
Technically, the SMS-CB messages originate at a device called "Cell Broadcast Centre (CBC)", which is part of the network operators equipment. It sends the SMS-CB through the Base Station Controller (BSC). This cannot be done over the air, it is something which happens inside the mobile operators network. It would probably be too much to explain all GSM/3G/UMTS network components here, you might want to read up on mobile network architecture.
So the simple answer is no, a handset (mobile phone) cannot directly send SMS-CB messages.
Now the question is, how to tell the CBC to send an SMS-CB to some network cells. There exist some standardized interfaces for that, which are used for emergency alerting, e.g. the Commercial Mobile Alert System (CMAS) in the US. If these interfaces are designed sensibly, they cannot be abused by just about anyone using a mobile handset. But I would not be surprised if there were security gaps in some operator's networks which would allow unauthorized parties to send SMS-CB, e.g. via insecure Internet/SS7 gateways. But that is wild speculation. Normally, it should not be possible to send unauthorized SMS-CB from outside of the operator's network.

Resources