Links to other parts of the study
- (Are you here)
This article completes the cycle of publications devoted to ensuring the information security of bank non-cash payments. Here we look at the generic threat models referenced in :
- .
- .
- .
- .
HABR-WARNING!!! Dear Khabrovites, this is not an entertaining post.
40+ pages of materials hidden under the cut are called upon help with work or study people who specialize in banking or information security. These materials are the final product of the study and are written in a dry formal tone. In fact, these are blanks for internal documents on information security.Well, the traditional “The use of information from the article for illegal purposes is punishable by law”. Productive reading!
Information for readers who read the study starting with this publication.
What is the study about
You are reading a guide for a specialist responsible for ensuring the information security of payments in a bank.
Presentation Logic
At the beginning in и the description of the object of protection is given. Then in it tells how to build a protection system, and talks about the need to create a threat model. IN It tells about what threat models are and how they are formed. IN и analysis of real attacks is given. и contain a description of the threat model built taking into account the information from all previous parts.
TYPICAL THREATS MODEL. NETWORK CONNECTION
The protection object for which the threat model is applied (scope)
The object of protection is data transmitted through a network connection operating in data networks built on the basis of the TCP/IP stack.
Architecture
Description of architecture elements:
- "end nodes" — nodes exchanging protected information.
- "Intermediate nodes" - elements of the data transmission network: routers, switches, access servers, proxy servers and other equipment - through which network connection traffic is transmitted. In general, a network connection can function without intermediate nodes (directly between end nodes).
Top level security threats
Decomposition
U1. Unauthorized access to transmitted data.
U2. Unauthorized modification of transmitted data.
U3. Violation of the authorship of the transmitted data.
U1. Unauthorized access to transmitted data
Decomposition
U1.1. <...>, carried out on final or intermediate nodes:
U1.1.1. <…> by reading the data while it is in the storage devices of the node:
U1.1.1.1. <…> in RAM.
Explanations to V1.1.1.1.
For example, during data processing by the node's network stack.
U1.1.1.2. <…> in non-volatile memory.
Explanations to V1.1.1.2.
For example, when storing transmitted data in the cache, temporary files or paging files.
Y1.2. <…> carried out on third-party data network nodes:
U1.2.1. <...> by capturing all packets that fall on the network interface of the node:
Explanations to V1.2.1.
All packets are captured by switching the network card to promiscuous mode (promiscuous mode for wired adapters or monitor mode for wi-fi adapters).
U1.2.2. <…> by carrying out man-in-the-middle (MiTM) attacks, but without modifying the transmitted data (not counting the service data of network protocols).
Y1.2.2.1. Link: .
Y1.3. <...>, carried out due to information leakage through technical channels (TCUI) from physical nodes or communication lines.
U1.4. <...>, carried out for the installation of special technical means (STS) on the final or intermediate nodes, intended for the covert removal of information.
U2. Unauthorized modification of transmitted data
Decomposition
Y2.1. <...>, carried out on final or intermediate nodes:
Y2.1.1. <...> by reading and modifying the data while it is in the storage devices of the nodes:
Y2.1.1.1. <...> in RAM:
Y2.1.1.2. <…> in non-volatile memory:
Y2.2. <...> carried out on third-party data network nodes:
U2.2.1. <…> by performing Man-in-the-Middle (MiTM) attacks and redirecting traffic to the malicious host:
Y2.2.1.1. The physical connection of the attackers' equipment to break the network connection.
Y2.2.1.2. Implementation of attacks on network protocols:
Y2.2.1.2.1. <…> virtual local area network (VLAN) management:
Y2.2.1.2.1.1. .
Y2.2.1.2.1.2. Unauthorized modification of VLAN settings on switches or routers.
Y2.2.1.2.2. <…> traffic routing:
Y2.2.1.2.2.1. Unauthorized modification of the static routing tables of routers.
Y2.2.1.2.2.2. Announcement of fake routes by attackers through dynamic routing protocols.
Y2.2.1.2.3. <…> automatic configuration:
Y2.2.1.2.3.1. .
Y2.2.1.2.3.2. .
Y2.2.1.2.4. <…> addressing and name resolution:
Y2.2.1.2.4.1. .
Y2.2.1.2.4.2. .
Y2.2.1.2.4.3. Making unauthorized changes to local hostname files (hosts, lmhosts, etc.)
U3. Violation of the authorship of the transmitted data
Decomposition
Y3.1. Neutralization of mechanisms for determining the authorship of information by indicating false information about the author or data source:
Y3.1.1. Changing the information about the author contained in the transmitted information.
Y3.1.1.1. Neutralization of cryptographic protection of the integrity and authorship of the transmitted data:
Y3.1.1.1.1. Link: .
Y3.1.1.2. Neutralization of the protection of the transmitted data authorship, implemented using one-time confirmation codes:
Y3.1.1.2.1. .
Y3.1.2. Changing information about the source of transmitted information:
Y3.1.2.1. .
Y3.1.2.2. .
TYPICAL THREATS MODEL. INFORMATION SYSTEM BUILT ON THE BASIS OF CLIENT-SERVER ARCHITECTURE
The protection object for which the threat model is applied (scope)
The object of protection is an information system built on the basis of the client-server architecture.
Architecture
Description of architecture elements:
- "Client" - a device on which the client part of the information system operates.
- "Server" - a device on which the server part of the information system operates.
- "Data store" - part of the server infrastructure of the information system, designed to store data processed by the information system.
- "Network connection" — an information exchange channel between the Client and the Server passing through the data transmission network. For a more detailed description of the element model, see .
Restrictions
When modeling an object, the following restrictions are set:
- The user interacts with the information system within finite periods of time, called work sessions.
- At the beginning of each session, the user is identified, authenticated and authorized.
- All protected information is stored on the server part of the information system.
Top level security threats
Decomposition
U1. Attackers committing unauthorized actions on behalf of a legitimate user.
U2. Unauthorized modification of protected information during its processing by the server part of the information system.
U1. Attackers committing unauthorized actions on behalf of a legitimate user
Explanation
Usually in information systems, the correlation of actions with the user who performed them is carried out using:
- system logs (logs).
- special attributes of data objects containing information about the user who created or modified them.
In relation to a work session, this threat can be decomposed into:
- <…> performed within the user session.
- <…> performed outside the user session.
A user session can be initiated:
- By the user himself.
- Intruders.
At this stage, the intermediate decomposition of this threat will look like this:
U1.1. Unauthorized actions performed within the user session:
U1.1.1. <…> set by the attacked user.
U1.1.2. <…> installed by attackers.
Y1.2. Unauthorized actions were performed outside the user's session.
From the point of view of information infrastructure objects that can be affected by intruders, the decomposition of intermediate threats will look like this:
Elements
Threat Decomposition
Y1.1.1.
Y1.1.2.
Y1.2.
Customer
Y1.1.1.1.
Y1.1.2.1.
network connection
Y1.1.1.2.
Server
Y1.2.1.
Decomposition
U1.1. Unauthorized actions performed within the user session:
U1.1.1. <…> set by the attacked user:
U1.1.1.1. Attackers independently acted from the Client:
У1.1.1.1.1 The attackers used standard information system access tools:
Y1.1.1.1.1.1. The attackers used the Client's physical input/output means (keyboard, mouse, monitor or touch screen of a mobile device):
Y1.1.1.1.1.1.1. The attackers acted during periods of time when the session is active, I/O facilities are available, and the user is away.
Y1.1.1.1.1.2. The attackers used remote administration tools (standard or provided by malicious code) to manage the Client:
Y1.1.1.1.1.2.1. The attackers acted during periods of time when the session is active, I/O facilities are available, and the user is away.
Y1.1.1.1.1.2.2. The attackers used remote administration tools, the operation of which is invisible to the attacked user.
U1.1.1.2. The attackers spoofed the data in the network connection between the Client and the Server, modifying them in such a way that they were perceived as the actions of a legitimate user:
Y1.1.1.2.1. Link: .
Y1.1.1.3. The attackers forced the user to perform the actions they specified using social engineering methods.
U1.1.2 <…> set by attackers:
Y1.1.2.1. The attackers acted from the Client (И):
Y1.1.2.1.1. The attackers neutralized the access control system of the information system:
Y1.1.2.1.1.1. Link: .
Y1.1.2.1.2. Malefactors used regular means of access of information system
U1.1.2.2. The attackers acted from other nodes of the data transmission network, from which it is possible to establish a network connection with the Server (И):
Y1.1.2.2.1. The attackers neutralized the access control system of the information system:
Y1.1.2.2.1.1. Link: .
Y1.1.2.2.2. The attackers used non-standard means of accessing the information system.
Explanations Y1.1.2.2.2.
The attackers could install a regular information system client on a third-party node or could use non-standard software that implements standard exchange protocols between the Client and the Server.
P1.2 Unauthorized actions performed outside the user's session.
S1.2.1 Attackers performed unauthorized actions, and then made unauthorized changes to the information system operation logs or special attributes of data objects, indicating that the actions they committed were performed by a legitimate user.
U2. Unauthorized modification of protected information during its processing by the server part of the information system
Decomposition
U2.1. Attackers modify protected information using standard information system tools and do this on behalf of a legitimate user.
Y2.1.1. Link: .
Y2.2. Attackers modify protected information by using data access mechanisms that are not provided for by the regular operation of the information system.
U2.2.1. Attackers modify files containing protected information:
Y2.2.1.1. <…> using the file handling mechanisms provided by the operating system.
Y2.2.1.2. <...> by provoking the restoration of files from an unauthorized modified backup.
U2.2.2. Malefactors modify the protected information stored in the database (И):
Y2.2.2.1. Attackers neutralize the DBMS access control system:
Y2.2.2.1.1. Link: .
Y2.2.2.2. Attackers modify information using standard DBMS interfaces to access data.
Y2.3. Malefactors modify the protected information by unauthorized modification of algorithms of work of the software processing it.
Y2.3.1. Modifications are made to the source code of the software.
Y2.3.1. Modifications are made to the machine code of the software.
Y2.4. Attackers modify protected information by exploiting vulnerabilities in the information system software.
Y2.5. Attackers modify the protected information when it is transferred between the components of the server part of the information system (for example, the database server and the application server):
Y2.5.1. Link: .
TYPICAL THREATS MODEL. ACCESS CONTROL SYSTEM
The protection object for which the threat model is applied (scope)
The protection object for which this threat model is applied corresponds to the protection object of the threat model: “Typical threat model. An information system built on the basis of a client-server architecture.
The user access control system in this threat model is understood as an information system component that implements the following functions:
- User identification.
- User authentication.
- User authorizations.
- Logging user actions.
Top level security threats
Decomposition
U1. Unauthorized establishment of a session on behalf of a legitimate user.
U2. Unauthorized elevation of user privileges in the information system.
U1. Unauthorized session establishment on behalf of a legitimate user
Explanation
The decomposition of this threat in the general case will depend on the type of user identification and authentication systems used.
In this model, only the user identification and authentication system using text login and password will be considered. In this case, we will assume that the user's login is public information known to attackers.
Decomposition
U1.1. <…> by compromising credentials:
U1.1.1. The attackers compromised the user's credentials while they were being stored.
Explanations Y1.1.1.
For example, credentials could be written on a sticky note taped to the monitor.
U1.1.2. The user accidentally or maliciously passed access details to attackers.
Y1.1.2.1. The user spoke the credentials aloud as they entered.
U1.1.2.2. The user intentionally passed their credentials:
Y1.1.2.2.1. <…> colleagues at work.
Explanations Y1.1.2.2.1.
For example, so that they can replace it with a period of illness.
Y1.1.2.2.2. <…> to the counterparties of the employer performing work on the objects of the information infrastructure.
Y1.1.2.2.3. <…> to third parties.
Explanations Y1.1.2.2.3.
One, but not the only way to implement this threat is to use social engineering methods by attackers.
U1.1.3. The attackers brute-forced the credentials:
Y1.1.3.1. <…> using regular access mechanisms.
U1.1.3.2. <...> by previously intercepted codes (for example, password hashes) for storing credentials.
U1.1.4. The attackers used malicious code to intercept the user's credentials.
U1.1.5. Attackers extracted credentials from a network connection between the Client and the Server:
Y1.1.5.1. Link: .
U1.1.6. Attackers extracted credentials from records of work monitoring systems:
U1.1.6.1. <…> video surveillance systems (in case keystrokes on the keyboard were recorded during operation).
U1.1.6.2. <…> systems for monitoring the actions of employees at the computer
Explanations Y1.1.6.2.
An example of such a system is .
U1.1.7. The attackers compromised the user's credentials due to flaws in the transmission process.
Explanations Y1.1.7.
For example, the transmission of passwords in clear text by e-mail.
U1.1.8. The attackers learned the credentials by monitoring the user's session using remote administration systems.
U1.1.9. The attackers extracted the credentials as a result of their leakage through technical channels (TCUE):
U1.1.9.1. The attackers spied how the user enters credentials from the keyboard:
E1.1.9.1.1 The attackers were located in close proximity to the user and saw the entry of credentials with their own eyes.
C1.1.9.1.1 Explanations
Such cases include the actions of colleagues at work or the case when the user's keyboard is visible to visitors to the organization.
E1.1.9.1.2 The attackers used additional technical means, such as binoculars or an unmanned aerial vehicle, and saw the entry of credentials through a window.
U1.1.9.2. The attackers extracted credentials from the records of the radio exchange between the keyboard and the system unit of the computer if they were connected via the radio interface (for example, Bluetooth).
U1.1.9.3. The attackers intercepted the credentials by leaking them through the channel of spurious electromagnetic radiation and pickups (PEMIN).
Explanations Y1.1.9.3.
Attack examples и .
U1.1.9.4. The attacker intercepted the input of credentials from the keyboard through the use of special technical means (STS) designed to covertly remove information.
Explanations Y1.1.9.4.
Examples .
U1.1.9.5. The attackers intercepted the input of credentials from the keyboard using
analysis of the Wi-Fi signal modulated by the process of pressing the keys by the user.
Explanations Y1.1.9.5.
Example .
U1.1.9.6. The attackers intercepted the input of credentials from the keyboard by analyzing the sounds of keystrokes.
Explanations Y1.1.9.6.
Example .
U1.1.9.7. The attackers intercepted the input of credentials from the keyboard of a mobile device by analyzing the accelerometer readings.
Explanations Y1.1.9.7.
Example .
U1.1.10. <...> previously saved on the Client.
Explanations Y1.1.10.
For example, a user could save a username and password in the browser to access a particular site.
U1.1.11. The attackers compromised credentials due to flaws in the user access revoke process.
Explanations Y1.1.11.
For example, after the dismissal of a user, his accounts remained not blocked.
Y1.2. <…> by exploiting vulnerabilities in the access control system.
U2. Unauthorized elevation of user privileges in the information system
Decomposition
P2.1 <...> by making unauthorized changes to data containing information about the user's privileges.
U2.2 <…> by exploiting vulnerabilities in the access control system.
Y2.3. <…> due to flaws in the user access control process.
Explanations Y2.3.
Example 1. A user was given more access to work than he needed due to official needs.
Example 2: After transferring a user to another position, the previously granted access rights were not revoked.
TYPICAL THREATS MODEL. INTEGRATION MODULE
The protection object for which the threat model is applied (scope)
Integration module - a set of information infrastructure objects designed to organize the exchange of information between information systems.
Given the fact that in corporate networks it is not always possible to unambiguously separate one information system from another, the integration module can also be considered as a link between components within one information system.
Architecture
The generalized scheme of the integration module looks like this:
Description of architecture elements:
- "Exchange Server (CO)" – a node / service / component of an information system that performs the function of exchanging data with another information system.
- "Intermediary" - a node / service designed to organize interaction between information systems, but not part of them.
Examples "Intermediaries" can be e-mail services, enterprise service bus / SoA architecture, third-party file servers, etc. In the general case, the integration module may not contain "Intermediaries". - "Data processing software" - a set of programs that implements data exchange protocols and format conversion.
For example, converting data from the UFEBS format to the ABS format, changing message statuses during transmission, etc. - "Network connection" corresponds to the object described in the "Network Connection" typical threat model. Some network connections from those presented in the diagram above may not be.
Examples of integration modules
Scheme 1. Integration of ABS and AWP KBR through a third-party file server
To execute payments, an authorized employee of the bank uploads electronic payment documents from the ABS and saves them to a file (of its own format, for example, SQL dump) on the network folder (…SHARE) of the file server. Then this file is converted into a set of files in the UFEBS format using a converter script, which are then read by the CBD AWP.
After that, an authorized employee - a user of the AWS CBD - encrypts and signs the received file and sends them to the payment system of the Bank of Russia.
Upon receipt of payments from the Bank of Russia, the AWP of the CBR decrypts them and checks the electronic signature, after which it writes them as a set of files in the UFEBS format to the file server. Before importing payment documents into the ABS, they are converted using a script-converter from the UFEBS format to the ABS format.
We will assume that in this scheme, the ABS operates on one physical server, the CBD workstation operates on a dedicated computer, and the script converter operates on a file server.
Correspondence of the objects of the considered scheme to the elements of the model of the integration module:
"Exchange servers from the ABS side" - ABS server.
"Exchange servers from the side of the AWP KBR" - computer workstation KBR.
"Intermediary" - third-party file server.
"Data processing software" - script converter.
Scheme 2. Integration of ABS and AWS KBR when placing a shared network folder with payments on AWS KBR
Everything is similar to Scheme 1, but a separate file server is not used; instead, a network folder (…SHARE) with electronic payment documents is located on a computer with AWS CBD. The script-converter also works on AWP CBD.
Correspondence of the objects of the considered scheme to the elements of the model of the integration module:
Similar to Scheme 1, but "Intermediary" not used.
Scheme 3. Integration of ABS and AWS KBR-N through IBM WebSphera MQ and signing of electronic documents "on the ABS side"
The ABS operates on a platform not supported by CIPF SKAD Signature. Outgoing electronic documents are signed on a special electronic signature server (ES Server). The same server verifies the electronic signature under documents incoming from the Bank of Russia.
The ABS uploads to the ES Server a file with payment documents in its own format.
The ES server, using a converter script, converts the file into electronic messages in the UFEBS format, after which the electronic messages are signed and transmitted to IBM WebSphere MQ.
AWS KBR-N accesses IBM WebSphere MQ and receives signed payment messages from there, after which an authorized employee - a user of AWS KBR - encrypts them and sends them to the payment system of the Bank of Russia.
Upon receipt of payments from the Bank of Russia, AWP KBR-N decrypts them and verifies the electronic signature. Successfully processed payments in the form of decrypted and signed electronic messages in the UFEBS format are transferred to IBM WebSphere MQ, from where they are received by the ES Server.
The ES server verifies the electronic signature of received payments and saves them to a file in ABS format. After that, an authorized employee - the ABS user - uploads the resulting file to the ABS in the prescribed manner.
Correspondence of the objects of the considered scheme to the elements of the model of the integration module:
"Exchange server from the ABS side" - ABS server.
"Exchange server from the side of the AWP KBR" - computer workstation KBR.
"Intermediary" – ES server and IBM WebSphere MQ.
"Data processing software" – script-converter, CIPF SCAD Signature on the ES Server.
Scheme 4. Integration of the RBS Server and ABS through the API provided by a dedicated exchange server
We assume that the bank uses several remote banking systems (RBS):
- "Internet Client-Bank" for individuals (ICB FL);
- "Internet Client-Bank" for legal entities (ICB LE).
In order to ensure information security, all interaction of the ABS with RB systems is carried out through a dedicated exchange server operating within the framework of the ABS information system.
Next, we will consider the process of interaction of the RBS system of the ICB LE with the ABS.
The RBS server, having received a duly certified payment order from the client, must create an appropriate document in the ABS based on it. To do this, using the API, it transfers information to the exchange server, which, in turn, enters data into the ABS.
When the balances on the client's account change, the ABS generates electronic notifications, which are transmitted to the RBS server using the exchange server.
Correspondence of the objects of the considered scheme to the elements of the model of the integration module:
"Exchange server from RBS" – RBS server IKB YUL.
"Exchange server from the ABS side" - exchange server.
"Intermediary" - missing.
"Data processing software" – RB Server components responsible for using the exchange server API, exchange server components responsible for using the ABS API.
Top level security threats
Decomposition
U1. The introduction of false information by malefactors through the integration module.
U1. The introduction of false information by attackers through the integration module
Decomposition
U1.1. Unauthorized modification of legitimate data during its transmission over network connections:
U1.1.1 Link: .
Y1.2. Transfer of false data through communication channels on behalf of a legitimate exchange participant:
U1.1.2 Link: .
Y1.3. Unauthorized modification of legitimate data during their processing on the Exchange Servers or the Intermediary:
Y1.3.1. Link: .
U1.4. Creation on the Exchange Servers or the Intermediary of fake data on behalf of a legitimate exchange participant:
Y1.4.1. Link:
Y1.5. Unauthorized modification of data during their processing using data processing software:
U1.5.1. <…> due to the introduction of unauthorized changes by intruders into the settings (configuration) of the data processing software.
U1.5.2. <…> due to the intruders making unauthorized changes to the executable files of the data processing software.
U1.5.3. <...> due to the interactive control of data processing software by attackers.
TYPICAL THREATS MODEL. CRYPTOGRAPHIC INFORMATION PROTECTION SYSTEM
The protection object for which the threat model is applied (scope)
The object of protection is the cryptographic information protection system used to ensure the security of the information system.
Architecture
The basis of any information system is application software (software) that implements its target functionality.
Cryptographic protection in this case is usually implemented by calling cryptographic primitives from the business logic of the application software, which are located in specialized libraries - crypto-kernels.
Cryptographic primitives include low-level cryptographic functions such as:
- encrypt/decrypt data block;
- create / verify the electronic signature of the data block;
- calculate the hash function of the data block;
- generate / upload / upload key information;
- etc.
The business logic of the application software, using cryptographic primitives, implements a higher-level functionality:
- encrypt the file with the keys of the selected recipients;
- establish a secure network connection;
- inform about the results of verification of the electronic signature;
- etc.
The interaction of business logic and crypto-core can be performed:
- directly, by calling cryptographic primitives from the dynamic libraries of the cryptokernel (.DLL - for Windows, .SO - for Linux) by the business logic;
- directly, through cryptographic interfaces - wrappers, for example, MS Crypto API, Java Cryptography Architecture, PKCS # 11, etc. In this case, the business logic refers to the crypto interface, and it translates the call to the corresponding crypto core, which in this case is called crypto provider. The use of cryptographic interfaces allows application software to abstract from specific cryptographic algorithms and be more flexible.
There are two typical schemes for organizing a cryptocore:
Scheme 1 - Monolithic crypto-core
Scheme 2 - Split Crypto Core
The elements in the above diagrams can be either separate software modules running on the same computer, or network services interacting within a computer network.
When using systems built according to scheme 1, the application software and the crypto-core work within a single environment for the operation of a crypto-means (CFC), for example, on the same computer running the same operating system. The user of the system, as a rule, can run other programs within the same operating environment, including those containing malicious code. In such conditions, there is a serious risk of leakage of private cryptographic keys.
To minimize the risk, scheme 2 is used, in which the cryptocore is divided into two parts:
- The first part, together with the application software, works in an untrusted environment where there is a risk of infection with malicious code. We will call this part “software part”.
- The second part works in a trusted environment on a dedicated device that contains a private key store. We will refer to this part as the “hardware part” from now on.
The division of the crypto-kernel into software and hardware parts is very conditional. There are systems on the market built according to the scheme with a split crypto-core, but the "hardware" part of which is presented in the form of a virtual machine image - virtual HSM ().
The interaction of both parts of the cryptocore occurs in such a way that private cryptographic keys are never transferred to the software part and, accordingly, cannot be stolen using malicious code.
The interaction interface (API) and the set of cryptographic primitives provided to the application software by the cryptocore are the same in both cases. The difference lies in the way they are implemented.
So, when using a scheme with a divided cryptocore, the interaction between software and hardware is performed according to the following principle:
- Cryptographic primitives that do not require the use of a private key (for example, calculation of a hash function, verification of an electronic signature, etc.) are performed by the software.
- Cryptographic primitives that use a private key (creating an electronic signature, decrypting data, etc.) are performed by the hardware.
Let's illustrate the operation of a split cryptocore using the example of creating an electronic signature:
- The software part calculates the hash function of the signed data and transmits this value to the hardware via the exchange channel between the crypto-cores.
- The hardware part, using the private key and hash, generates the value of the electronic signature and transfers it to the software part via the exchange channel.
- The software part returns the received value to the application software.
Features of checking the correctness of an electronic signature
When the receiving party receives data signed with an electronic signature, it must carry out several stages of verification. A positive result of verification of an electronic signature is achieved only if all stages of verification are successfully completed.
Stage 1. Control of data integrity and data authorship.
Stage content. The electronic signature of the data is verified according to the corresponding cryptographic algorithm. Successful completion of this stage indicates that the data has not been modified since they were signed, and that the signature was made with a private key corresponding to the public key for verifying the electronic signature.
Location of the stage: cryptokernel.
Stage 2. Control of trust in the public key of the signer and control of the validity period of the private key of the electronic signature.
Stage content. The stage consists of two intermediate sub-stages. The first one establishes whether the public key for verifying the electronic signature was trusted at the time of signing the data. The second one establishes whether the private key of the electronic signature was valid at the time of signing the data. In the general case, the validity periods of these keys may not coincide (for example, for qualified certificates of electronic signature verification keys). Methods for establishing trust in the signer's public key are determined by the rules of electronic document management adopted by the interacting parties.
Location of the stage: application software / crypto-kernel.
Stage 3. Control of the signer's authority.
Stage content. In accordance with the established rules of electronic document management, it is checked whether the signatory had the right to certify the protected data. For example, consider the situation of violation of authority. Suppose there is an organization where all employees have an electronic signature. The internal electronic document management system receives an order from the head, but signed by the electronic signature of the warehouse manager. Accordingly, such a document cannot be considered legitimate.
Location of the stage: application software.
Assumptions made when describing the object of protection
- Information transfer channels, with the exception of key exchange channels, also pass through application software, API and crypto-core.
- Information about trust in public keys and (or) certificates, as well as information about the authority of public key owners, is placed in the public key store.
- The application software works with the public key storage through the crypto-kernel.
An example of an information system protected with CIPF
To illustrate the previously presented schemes, consider a hypothetical information system and select all the structural elements on it.
Description of the information system
The two organizations decided to introduce legally binding electronic document management (EDF) between them. To do this, they entered into an agreement in which they stated that the documents would be transmitted by e-mail, and at the same time they must be encrypted and signed with a qualified electronic signature. As a means of creating and processing documents, office programs from the Microsoft Office 2016 package should be used, and as means of cryptographic protection - CIPF CryptoPRO and encryption software CryptoARM.
Description of the organization's infrastructure 1
Organization 1 decided that it would install CryptoPRO CIPF and CryptoARM software on the user's workstation - a physical computer. Encryption and electronic signature keys will be stored on the ruToken key carrier operating in the retrievable key mode. The user will prepare electronic documents locally on his computer, after which they will be encrypted, signed and sent using a locally installed mail client.
Description of the organization's infrastructure 2
Organization 2 decided to move the functions of encryption and electronic signature to a dedicated virtual machine. In this case, all cryptographic operations will be performed automatically.
To do this, two network folders are organized on a dedicated virtual machine: “…In”, “…Out”. Files received from the counterparty in open form will be automatically placed in the “…In” network folder. These files will be decrypted and the electronic signature will be verified on them.
In the “…Out” folder, the user will place files that need to be encrypted, signed and sent to the counterparty. The user will prepare the files themselves on his workstation.
To perform encryption and electronic signature functions, CryptoPRO CIPF, CryptoARM software and a mail client are installed on the virtual machine. Automatic management of all elements of the virtual machine will be carried out using scripts developed by system administrators. The work of scripts is logged in log files (logs).
The cryptographic keys of the electronic signature will be placed on a token with a JaCarta GOST non-retrievable key, which the user will connect to his local computer.
The token will be forwarded to the virtual machine using specialized USB-over-IP software installed on the user's workstation and on the virtual machine.
The system clock on the user's workstation in organization 1 will be adjusted manually. The system clock of the dedicated virtual machine in organization 2 will be synchronized with the system clock of the hypervisor, which in turn will be synchronized over the Internet with public time servers.
Allocation of structural elements of CIPF
Based on the above description of the IT infrastructure, we single out the structural elements of the CIPF and write them down in a table.
Table - Correspondence of the elements of the CIPF model with the elements of information systems
Item Name
Organization 1
Organization 2
Application software
CryptoARM software
CryptoARM software
The software part of the cryptokernel
CIPF CryptoPRO CSP
CIPF CryptoPRO CSP
The hardware part of the cryptokernel
no
JaCarta GOST
API
MS CryptoAPI
MS CryptoAPI
Public key storage
User workstation:
- HDD;
- standard Windows certificate store.
Hypervisor:
- HDD.
Virtual machine:
- HDD;
- standard Windows certificate store.
Private key storage
Key carrier ruToken operating in the mode of extractable key
JaCarta GOST key carrier operating in non-retrievable key mode
Public key exchange channel
User workstation:
- RAM.
Hypervisor:
- RAM.
Virtual machine:
- RAM.
Private key exchange channel
User workstation:
- USB bus;
- RAM.
no
Exchange channel between crypto-cores
absent (no cryptocore hardware)
User workstation:
- USB bus;
- RAM;
- USB-over-IP software module;
- network interface.
Corporate network of the organization 2.
Hypervisor:
- RAM;
- network interface.
Virtual machine:
— network interface;
- RAM;
- USB-over-IP software module.
Open data exchange channel
User workstation:
- means of input-output;
- RAM;
- HDD.
User workstation:
- means of input-output;
- RAM;
- HDD;
- network interface.
Corporate network of the organization 2.
Hypervisor:
— network interface;
- RAM;
- HDD.
Virtual machine:
— network interface;
- RAM;
- HDD.
Secure data exchange channel
The Internet.
Corporate network of the organization 1.
User workstation:
- HDD;
- RAM;
- network interface.
The Internet.
Corporate network of the organization 2.
Hypervisor:
— network interface;
- RAM;
- HDD.
Virtual machine:
— network interface;
- RAM;
- HDD.
Time channel
User workstation:
- means of input-output;
- RAM;
- system timer.
The Internet.
Corporate network of the organization 2,
Hypervisor:
— network interface;
- RAM;
- system timer.
Virtual machine:
- RAM;
- system timer.
Control command transmission channel
User workstation:
- means of input-output;
- RAM.
(GUI of CryptoARM software)
Virtual machine:
- RAM;
- HDD.
(Automation scripts)
Channel for receiving work results
User workstation:
- means of input-output;
- RAM.
(GUI of CryptoARM software)
Virtual machine:
- RAM;
- HDD.
(Log files for automation scripts)
Top level security threats
Explanation
Assumptions made in the decomposition of threats:
- Strong cryptographic algorithms are used.
- Cryptographic algorithms are used securely in the correct modes of operation (for example, does not apply to encrypting large amounts of data, the allowable load on the key is taken into account, etc.).
- Malefactors know all used algorithms, protocols and public keys.
- Attackers have access to all encrypted data.
- Attackers are able to reproduce any program elements in the system.
Decomposition
U1. Compromise of private cryptographic keys.
U2. Encryption of fake data on behalf of a legitimate sender.
U3. Decryption of encrypted data by persons who are not legitimate recipients of data (intruders).
U4. Creation of an electronic signature of a legitimate signer under false data.
U5. Obtaining a positive result of checking the electronic signature of false data.
U6. Erroneous acceptance of electronic documents for execution due to problems in the organization of electronic document management.
U7. Unauthorized access to protected data during their processing by CIPF.
U1. Compromise of private cryptographic keys
U1.1. Get the private key from the private key store.
Y1.2. Obtaining a private key from the objects of the environment of functioning of the cryptographic tool, in which it can be temporarily located.
Explanations Y1.2.
Objects that can temporarily store a private key would include:
- RAM,
- temporary files,
- paging files,
- hibernation files,
- snapshot files of the "hot" state of virtual machines, including files of the contents of the RAM of virtual machines that have been paused.
U1.2.1. Retrieving private keys from working RAM by freezing RAM modules, extracting them, and then reading the data (freeze attack).
Explanations Y1.2.1.
Example .
Y1.3. Obtaining a private key from a private key exchange channel.
Explanations Y1.3.
An example of the implementation of this threat will be given .
U1.4. Unauthorized modification of the crypto-core, as a result of which private keys become known to attackers.
Y1.5. Compromise of the private key as a result of the use of technical channels of information leakage (TCLE).
Explanations Y1.5.
Example .
U1.6. Compromise of the private key as a result of the use of special technical means (STS) designed for secret retrieval of information ("bugs").
Y1.7. Compromise of private keys during their storage outside the CIPF.
Explanations Y1.7.
For example, a user keeps their key media in a desktop drawer, from which they can be easily retrieved by intruders.
U2. Encryption of fake data on behalf of a legitimate sender
Explanation
This threat is only considered for data encryption schemes with sender authentication. Examples of such schemes are indicated in the recommendations for standardization. . For other cryptographic schemes, this threat does not exist, since encryption is performed on the public keys of the recipient, and they are generally known to attackers.
Decomposition
Y2.1. Compromise of the sender's private key:
Y2.1.1. Link: .
Y2.2. Substitution of input data in the open data exchange channel.
Notes U2.2.
Examples of the implementation of this threat are given below. и .
U3. Decryption of encrypted data by persons who are not legitimate recipients of data (intruders)
Decomposition
Y3.1. Compromise of private keys of the recipient of encrypted data.
U3.1.1 Link: .
Y3.2. Substitution of encrypted data in a secure data exchange channel.
U4. Creation of an electronic signature of a legitimate signer under false data
Decomposition
Y4.1. Compromise of private keys of the electronic signature of a legitimate signer.
U4.1.1 Link: .
Y4.2. Substitution of signed data in the open data exchange channel.
Note U4.2.
Examples of the implementation of this threat are given below. и .
U5. Obtaining a positive result of checking the electronic signature of false data
Decomposition
Y5.1. Malefactors intercept in the channel of transmission of results of work the message on negative result of check of the electronic signature and replace it with the message with positive result.
Y5.2. Attackers carry out an attack on trust in signing certificates (SCENARIO - all elements are required):
Y5.2.1. Attackers generate a public and private key for an electronic signature. If the system uses electronic signature key certificates, they generate an electronic signature certificate that is as similar as possible to the certificate of the alleged sender of the data whose message they want to forge.
U5.2.2. Attackers make unauthorized changes to the public key store, endowing the public key generated by them with the necessary level of trust and authority.
Y5.2.3. Attackers sign fake data with a previously generated electronic signature key and embed it into a secure data exchange channel.
Y5.3. Attackers carry out an attack using expired electronic signature keys of a legal signer (SCENARIO - all elements are required):
Y5.3.1. Attackers compromise the expired (not currently valid) private keys of the legitimate sender's electronic signature.
Y5.3.2. Attackers replace the time in the time transmission channel with the time at which the compromised keys were still valid.
Y5.3.3. Attackers sign fake data with a previously compromised electronic signature key and embed it into a secure data exchange channel.
Y5.4. Attackers carry out an attack using compromised electronic signature keys of a legal signer (SCENARIO - all elements are required):
Y5.4.1. The attackers make a copy of the public key store.
Y5.4.2. Attackers compromise the private keys of one of the legitimate senders. He notices the compromise, revokes the keys, information about the revocation of the key is placed in the public key store.
Y5.4.3. The attackers replace the public key store with the previously copied one.
Y5.4.4. Attackers sign fake data with a previously compromised electronic signature key and embed it into a secure data exchange channel.
U5.5. <...> due to the presence of errors in the implementation of the 2nd and 3rd stages of electronic signature verification:
Explanations Y5.5.
An example of the implementation of this threat is given .
U5.5.1. Verification of trust in the certificate of the electronic signature key only by the presence of trust in the certificate with which it is signed, without CRL or OCSP checks.
Explanations Y5.5.1.
Implementation example .
Y5.5.2. When building a chain of trust for a certificate, the authority of issuing certificates is not analyzed
Explanations Y5.5.2.
An example of an attack against SSL/TLS certificates.
The attackers bought a legitimate certificate for their e-mail. They then made a fraudulent website certificate and signed it with their own certificate. If the credentials check is not carried out, then when checking the chain of trust, it will turn out to be correct, and, accordingly, the fraudulent certificate will also be correct.
Y5.5.3. When building a certificate trust chain, intermediate certificates are not checked for revocation.
Y5.5.4. CRLs are updated less frequently than the certificate authority issues them.
U5.5.5. The decision to trust the electronic signature is made before the OCSP response about the status of the certificate is received, sent on a request made later than the signature generation time or earlier than the next one after the CRL signing is received.
Explanations Y5.5.5.
In the regulations of most CAs, the certificate revocation time is considered to be the time of issuance of the nearest CRL containing information about the revocation of the certificate.
U5.5.6. Upon receipt of signed data, the ownership of the certificate by the sender is not checked.
Explanations Y5.5.6.
Attack example. For SSL certificates, it may not check if the address of the called server matches the value of the CN field in the certificate.
Attack example. The attackers compromised the electronic signature keys of one of the participants in the payment system. After that, they hacked the network of another participant and, on his behalf, sent payment documents signed with compromised keys to the settlement server of the payment system. If the server analyzes only trust and does not check for compliance, then fraudulent documents will be considered legitimate.
U6. Erroneous acceptance of electronic documents for execution due to problems in the organization of electronic document management.
Decomposition
U6.1. The receiving party does not detect duplication of received documents.
Explanations Y6.1.
Attack example. Malefactors can intercept the document transferred to the recipient, even if it is cryptographically protected, and then repeatedly send it to the secure data transmission channel. If the recipient does not detect duplicates, then all received documents will be perceived and processed as different documents.
U7. Unauthorized access to protected data during their processing by CIPF
Decomposition
U7.1. <…> due to information leakage through third-party channels (side channel attack).
Explanations Y7.1.
Example .
U7.2. <...> due to the neutralization of protection against unauthorized access to information processed on CIPF:
Y7.2.1. Operation of CIPF with violations of the requirements described in the documentation for CIPF.
Y7.2.2. <…> implemented due to the presence of vulnerabilities in:
Y7.2.2.1. <…> means of protection against unauthorized access.
Y7.2.2.2. <…> the CIPF itself.
Y7.2.2.3. <...> the environment for the functioning of the cryptographic tool.
Examples of attacks
The scenarios discussed below obviously contain errors in the organization of information security and serve only to illustrate possible attacks.
Scenario 1. An example of the implementation of threats U2.2 and U4.2.
Description of the object
ARM KBR software and CIPF SCAD Signature are installed on a physical computer that is not connected to a computer network. The FKN vdToken is used as a key carrier in the mode of operation with a non-retrievable key.
The settlement regulation assumes that the settlement specialist from his work computer downloads electronic messages in clear text (the scheme of the old KBR AWS) from a special secure file server, then writes them to a removable USB flash drive and transfers them to the KBR AWP, where they are encrypted and signs. After that, the specialist transfers secure electronic messages to a transferable medium, and then, through his work computer, writes them to a file server, from where they get to UTA and then to the payment system of the Bank of Russia.
In this case, the channels for exchanging open and secure data will include: a file server, a specialist's work computer, and a transferable media.
Атака
Unauthorized attackers install a remote control system on the specialist’s work computer and, at the time of recording payment orders (electronic messages) on the transferable medium, openly replace the contents of one of them. The specialist transfers the payment orders to the AWS of the KBR, signs and encrypts them without noticing the substitution (for example, due to the large number of payment orders on the flight, fatigue, etc.). After that, the fake payment order, having passed through the technological chain, enters the payment system of the Bank of Russia.
Scenario 2. An example of the implementation of threats U2.2 and U4.2.
Description of the object
The computer with the installed AWS KBR, SKAD Signature and the connected key carrier of the FKN vdToken operates in a dedicated room without access from the staff.
The settlement specialist connects to the AWS of the KBR in the remote access mode via the RDP protocol.
Атака
Attackers intercept the details, using which the settlement specialist connects and works with the KBR automated workplace (for example, due to malicious code on his computer). Then they connect on his behalf and send a fake payment order to the payment system of the Bank of Russia.
Scenario 3. An example of the implementation of the threat U1.3.
Description of the object
Let us consider one of the hypothetical options for the implementation of ABS-KBR integration modules for the new scheme (ARM KBR-N), in which the electronic signature of outgoing documents occurs on the side of the ABS. In this case, we will assume that the ABS operates on the basis of an operating system that is not supported by the CIPF SKAD Signature, and, accordingly, the cryptographic functionality is placed on a separate virtual machine - the ABS-CBR integration module.
A regular USB token operating in the removable key mode is used as a key carrier. When the key carrier was connected to the hypervisor, it turned out that there were no free USB ports in the system, so it was decided to connect the USB token through a network USB hub, and install a USB-over-IP client on the virtual machine that will communicate with the hub.
Атака
The attackers intercepted the private key of the electronic signature from the communication channel between the USB hub and the hypervisor (the data was transmitted in clear text). Having a private key, the attackers generated a fake payment order, signed it with an electronic signature and sent it to the KBR-N automated workplace for execution.
Scenario 4. An example of the implementation of threats U5.5.
Description of the object
Consider the same circuit as in the previous scenario. We will assume that e-mails coming from the KBR-N workstation end up in the …SHAREIn folder, and those that are sent to the KBR-N workstation and further to the Bank of Russia payment system go to …SHAREout.
We will also assume that when implementing the integration module, the lists of revoked certificates are updated only when cryptographic keys are reissued, and also that electronic messages received in the …SHAREIn folder are checked only for integrity control and trust control to the public key of the electronic signature.
Атака
The attackers, using the keys stolen in the previous scenario, signed a fake payment order containing information about the receipt of money on the account of a fraudulent client and introduced it into a secure data exchange channel. Since there is no verification that the payment order is signed by the Bank of Russia, it is accepted for execution.
Source: habr.com