Shield and Sword in RBS systems

Security issues in remote banking systems (RBS) is no secret to anyone. Where money is at stake, information security is tested for durability especially often. The main attack vector in the RBS systems is directed to the client software, since it runs in an insecure environment. Different methods were used to protect the client workplace at different times. The evolution of the means of attack and defenses used in the RBS, I will try to describe in this topic. Mainly, technical means will be considered to protect the client part of RBS.


Passwords
The first RBS systems were protected with a regular password. Sometimes an additional payment password was used to make a payment. Now a similar scheme is used in some payment systems. I think it is not necessary to explain how the attack was built. Keylogger was quite enough to get access to someone else's account.

The keys of the signature in the file.
For some time, DBO systems began to appear, where it was necessary to generate an electronic signature under the payment order to confirm the payment. The keys to form the signature were stored in encrypted files. It was recommended to store them on external media. A similar scheme is still used in some banks. The scheme of attack began to look different. The password for the key file was also intercepted by the keylogger, and the key itself was stolen by spyware.
')
Keys on a “regular” token.
It is worth giving a little introductory information. Roughly all the tokens can be divided into two types. Some tokens can only store signature keys in their protected memory, other tokens can generate signature keys and perform a signature operation in hardware, so that the private key never leaves the token. Even the owner of the token cannot retrieve the private key from it.
In the beginning, of course, simpler versions of tokens appeared. They certainly made life difficult for intruders, but they did not solve the problems. In response to the introduction of tokens, more “sensible” spyware has begun to appear, targeting specific RBS systems. This software had the opportunity to steal keys from the computer’s RAM at the time when the user performed a legitimate signature operation. Then the development of remedies went the way the introduction of additional means of confirmation of payment. I will return to these tools later.

Onboard cryptography token
The final point in the theft of signature keys can put cryptography tokens on board, but so far they have a weak distribution. There are objective reasons for this. Yes, indeed, they will not allow the attacker to steal the signature keys, but they cannot solve the main task - to stop the theft of money in the RBS systems. Yes, they can greatly reduce the number of thefts, but only for a while. The scheme of money theft is already gaining momentum, in which the signature of the payment order is carried out directly on the user's computer while the token is connected. This is done either by using a remote computer control, or using USB-over-IP technology, or by replacing a payment order at the time of signing.

Additional payment confirmation
The main idea of ​​the additional confirmation is to use a computer independent device. One-time passwords - OTP (One Time Password) are most widely used. The implementation could be different, it could be SMS messages with a confirmation code, OTP tokens, tables with one-time passwords. By the way, terribly infuriating not coming on time SMS. :) The attackers had to look for new ways to attack RBS systems. With such defense mechanisms, purely technical attack methods began to be combined with social engineering. The most common way to attack a scheme with one-time passwords is phishing. On the phishing site, the user gets a one-time password, which is immediately used to conduct their payment. The main disadvantage of the protection scheme with OTP is the lack of a relationship between the password and the contents of the payment order.

Of course, followed by other devices that already knew how to generate a confirmation code based on the data of the payment order. For example, a person must enter the account number and the amount of payment on some external device and receive a code, which he then needs to enter into the RBS system. The solution is quite safe, but the usability of this solution does not fit into any framework. In the picture the instruction to one such device.
One payment can still be made, and ten?

Last squeak
This year, new devices to protect RBS appeared on the Russian market. These are trusted digital signature generation devices. The devices are equipped with a screen for displaying payment information and buttons to confirm payment and refuse to conduct a payment. In the photo device Rutoken PINPad.



The meaning of this device is that the information entering the device is displayed on the screen, verified by the user, if it is correct, confirmed by the user, then hardware-hashed and signed. This approach allows you to completely eliminate the possibility of substitution of a payment order when signing, and also eliminates the possibility of forming a signature using remote computer control. An interesting solution, however, is not being exploited anywhere. The implementation comes in several banks.

I think the use of such devices will solve the problem of theft of money using spyware. However, if the technical ability to steal disappears, methods based on social engineering will be more actively used. The majority of users have a poor understanding of information security, and this is good ground for various kinds of frauds.