I have a question about USSD and security in this channel.
As you know today mobile banking and many payments using USSD, I want to know is USSD safe?
If USSD transactions using a5/1 for encryption,its totally broke few years a go and now can be captured by usrp (or HackRF board) and decoded by rainbow tables created for a5/1.
I think this transactions is not really safe,but I want to know more about this protocol and encryption using at this transactions. I dont know USSD codes encoded with a5/1 or GSM-7... so my question is:
What is encryption using for USSD transactions? Is the USSD using
GSM voice encryption ( a5/1) or using GSM-7 or other?
How we can make USSD secure? is possible to add additional
encryption to transactions or what you think about securing USSD
codes and transactions.
Thanks all.
In general there are two level of security in Mobile networks (in this case GSM)
AirInterface Security
Core Network Security
For the AirInterface (Radio Interface between MS and BTS) it can be encrypted or unencrypted (depend on network setting)
https://en.wikipedia.org/wiki/A5/1
https://en.wikipedia.org/wiki/A5/2
As you can see both current encryption methods are so weak specially for financial transaction (compare to acceptable encryption methods for online banking).
The real problem for USSD messages are their MAP/SS7(Sigtran) related message in the core network.
Unfortunately all USSD messages in GSM network transfer as a plain text (as a part of MAP message) and all E1 links are easily monitor-able.
Using USSD as a transmission layer (in the lack of Data connection(GPRS-3G-LTE)on network) is possible but an encryption layer is require ( and it can be implemented on Android or IOS App)
Related
I am working on a penetration testing framework for computer games that will detect potential security vulnerabilities.
Part of the automated testing will be to verify that the network data is sent encrypted.
One approach would be to hook the Windows socket and encryption functions of the game and determine a connection between encryption and network packets based on the frequency of function calls.
Another approach would be to store the encrypted data and then check whether it is passed on to socket functions.
Are the approaches reasonable, or are there already better ways to accomplish this task?
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.
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.
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.
What is the SMPP protocol and how does it work?
I've not even seen it yet and have to start with introduction onward.
SMPP is a low-level binary Internet protocol.
The primary use of SMPP is to send and receive medium-to-high volumes of SMS texts.
SMPP uses a standard Internet connection to connect to an SMPP provider, to do away with or compliment the purchase of a GSM modem or a SIM card.
SMPP offers the following benefits over a GSM modem:
Send by a meaningful name e.g. a company name instead of phone number.
Send by a short codes; 3, 4, or 5 digit phone number instead of the normal length.
Faster processing
Software:
Kannel is an open-source client for experimenting on.
ActiveXperts Mobile Messaging Toolkit is a commercial solution with SMPP simulator.
For the record: I'm a programmer at ActiveXperts, actively involved in SMPP and SMS related developments.
Fundamentally it's the main protocol that SMS aggregator companies
(mostly!) use when communicating with different type of Gateways (GW).
Please check these links...they will definitely help you out understand SMPP more thoroughly.
http://www.simpleteam.com/downloads/SMPP_v3_4_Issue1_2.pdf
http://www.ehow.com/facts_7344160_smpp-protocol_.html
Wikipedia definition:
"SMPP is a telecommunications industry protocol for exchanging SMS messages between SMS peer entities such as short message service centers and/or External Short Messaging Entities. It is often used to allow third parties (e.g. value-added service providers like news organizations) to submit messages, often in bulk."