RU2704532C1 - Method and device for controlling event recording database - Google Patents

Abstract

FIELD: information technology.

SUBSTANCE: group of inventions relates to a method and a device for managing a database and can be used in engineering, where invariance of storing events (data), a timestamp of their occurrence and a registration time mark in the database is required for further analysis (including arbitration). Method comprising steps of: obtaining event information; determining a checksum of a previous event record; generating an event record; storing the generated event record in the event database and recording the time for storing the generated record in the event database, wherein the recorded event record includes adding checksum data of the previous event record and a time stamp; calculating a checksum for the stored event record based on checksum values of the previous event record and time for storing the entry in the event database; adding to the stored record information on the calculated checksum at the previous step.

EFFECT: high reliability of storing information on events.

18 cl, 2 dwg

Description

FIELD OF TECHNOLOGY

The group of inventions relates to a method and device for managing a database and can be used in the field of technology where the persistence of events (data), timestamps of their occurrence, and timestamps of registration in the database are required for subsequent analysis (including arbitration). Such works are, for example, automation of processes for performing work on maintenance schedules, performing work on technological maps, performing emergency work, fixing the receipt of goods and equipment, as well as the procedure for processing them, assembly work, etc.

BACKGROUND

The prior art method for ensuring the integrity of a set of data records described in patent RU 2 351 978 C2, publ. 04/10/2009. In this method, it is required to sign incoming data using a storage key, which must be known to at least one person. Using this approach leads to the use of the human factor, which greatly reduces the reliability of data storage (because the signing key can be compromised, for example, by chance).

 Knowing the key allows you to make a change to the database already filled with data and recalculate the checksums. Such unauthorized alteration of data cannot be identified.

 The mentioned solution does not use timestamps, which is not suitable for the method of saving events, where the sequence and times (the beginning of the event, the end, the time of registration) are fundamental and make it possible to conduct subsequent analysis.

 Another disadvantage is the ability to store the calculated checksum separately from the record, which makes it possible to change the checksum without changing the data record itself and, as a result, the possibility of changing the record with further manual adjustment of the separately stored checksum, which can provide unauthorized data changes.

 There is a method of creating an audit trail record with increased protection against unauthorized access, described in US 5978475, publ. 11/02/1999. This method uses the storage in the audit log MAC (message autefication code) using the hash function from the previous record, but has several disadvantages, in particular:

• a trusted computer is required, with which transactions are necessary at the time the audit log is generated.

• checksums are stored on a write-once device located on an untrusted computer, which eliminates the need to change a single record, but makes it possible to replace the entire recorded volume with compromised data.

• the time stamp received from the system clock of an untrusted computer is stored in the log, which can lead to a violation of the sequence of time of entries in the log through access to the system time of an untrusted computer.

• there are no arbitration copies of the audit journal, which theoretically allows compromising the data by a complete replacement in an untrusted computer.

 In the proposed solution, there is no separation of computers on which instances of the event registration database (BDS) are stored into trusted and untrusted. All copies of the BDRS have equal force and may act as an arbitration copy. Arbitration is carried out automatically periodically (i.e., at the stage of saving events, an integrity check is performed), and is also available at any time at the user's request.

 Using a pair of trusted-untrusted computers orientes the method described in US 5978475, to ensure the preservation of transactions (electronic wallets, payments on the Internet and ATMs, etc.). This is a significant limitation and will not be suitable, for example, in the case where processing of chains of physically interconnected events, separated in time, but requiring joint analysis, is required.

For example, in the case of performing work on a schedule at a remote site, for the event of the fact that the work itself was being performed, related events will be possible: the movement of personnel (from the geolocation system), the passage of the photo / video system by the personnel of the access system to the object, the fixing of the process (result) of work, etc. The processing of such events should then be carried out jointly, in a published method based on fixing transactions, each transaction is considered as unrelated.

SUMMARY OF THE INVENTION

The technical problem to which the claimed group of inventions is aimed is to provide a mechanism for storing events (structured records with time stamps) in a database with the following functions:

• a mechanism for checking the immutability of records,

• a mechanism for ensuring the continuity of the chain of records (lack of the ability to make entries between existing ones, disrupting the order),

• fixing the recording time with obtaining a time stamp from a trusted time source (such as GLONASS / GPS or an independent time server),

• formation of at least one arbitration copy of the database physically located on another computing device (or medium).

The technical result is to increase the reliability of storing information about events.

To achieve the specified technical result, a method for controlling the BDRS has been developed, comprising the steps at which:

receive information about the event;

determine the checksum of the previous event record;

form an event record;

save the generated record of the event in the BDSM and record the time of saving the generated record in the BDRS, and the data about the checksum of the previous record of the event and the time stamp containing information about the time the record was saved in the BDSRS is added to the saved record of the event;

calculate the checksum for the saved event record, taking into account the values of the checksum of the previous event record and the time the record was saved in the BDS;

add information about the calculated checksum in the previous step to the saved record.

Also developed a control device BDSS, containing:

a data receiving unit, configured to receive event information;

a data processing unit, configured to:

determine the checksum of the previous event record;

generate an event record based on information received by the data receiving unit;

save the generated record of the event in the BDSM and record the time of saving the generated record in the BDRS; moreover, the data processing unit adds the data on the checksum of the previous record of the event and the time stamp containing information about the time the record was saved in the BDRS to the saved record of the event;

calculate the checksum for the saved event record, taking into account the values of the checksum of the previous event record and the time the record was saved in the BDS;

add to the saved record information about the calculated checksum in the previous step.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the essence of the invention, and to more clearly show how it can be implemented, hereinafter, reference will be made, only as an example, to the accompanying drawings, on which:

FIG. 1 - an example of a technical diagram of a control device BDS;

FIG. 2 is an example of a BDS data structure.

DETAILED DESCRIPTION OF THE INVENTION

According to an example of a technical circuit in FIG. 1, the BDSM control device, in particular, contains sequentially connected: a data receiving unit 1, a data processing unit 2 and a BDRS 10. The data receiving unit 1 can be implemented on the basis of a transceiver, and the data processing unit can be based on a microcontroller, processor or a microprocess modified in the firmware in such a way as to perform the functions assigned to it below. These elements of the device are connected through a wired connection, for example, a data bus, and combined into a single structure, for example, by placing them in a single enclosure or on a single printed circuit board. Alternatively, wireless communication may be used as the connection between the blocks.

To register at least one event in the event registration database, information about the event 11 is supplied to the data receiving unit 1. Information about the event 11 by the data receiving unit 1 can be obtained from at least one external database, data input device, or event registration sensor for example, an RFID tag reader. To ensure validity, an automatic method of obtaining data is preferred. For example, fixing the start of work (with a timestamp) and fixing the end of work (with a timestamp) is carried out using the RFID identification mechanism (i.e., data is received only when the tag is read, which increases the reliability of the fact of the event, the time of fixing the event is stored on based on the time source of the RFID reader). Event types can be pre-classified, but previously untyped events can be recorded. Possible types of events (as an example): successful / unsuccessful carrying out of the planned work, equipment failure, repair, receipt of equipment at the warehouse / facility, personnel transfer, violation of the work schedule on the work map, lack of necessary material (device).

Further, information about event 11 is supplied to data processing unit 2, which generates an event record 8 and stores the generated event record 9 in the event registration database (see Fig. 2) with the formation of an event registration time stamp (possibly different from time stamps) the beginning / end of the event, which is an additional source of information about the reliability). The data processing unit 2, in addition, can be equipped with a mechanism for checking the registration time of the previous record to eliminate the situation of recording current data with less time. When you save the mentioned record 8 in the event registration database by the data processing unit 2, the time of saving the record in the event database to form the time stamp 13 is recorded. Time information on the data processing unit 2 can come from a trusted time source 3, for example, such as GLONASS / GPS or trusted time server by sending the corresponding request 7. The obtained time stamp 13 is added by the data processing unit 2 to the stored record of event 8 in the BDS 10.

Next, the data processing unit 2 refers to the BDRS 10, in which the aforementioned generated record is stored, in order to determine the checksum 12 of the previous record of the event 7, obtained by a cryptographically secure hash function. The use of a cryptographically robust hash function for calculating the checksum makes it possible to achieve resistance to restoring the inverse image, which ensures a high level of data invariance. The checksum 12 of the previous event record, as well as the time stamp 13, is added by the data processing unit 2 to the stored event record 8 in the event registration database. If the generated record of event 8 is the first record in the event registration database, then the checksums from the current time are calculated as the checksums of the previous record, which ensures the fixation of the moment when the database starts filling.

In addition, the data processing unit 2 calculate the checksum 14 for the saved event record 8 taking into account the checksum values of the previous event record 12 and the time the record was saved in the BDS 11 and adds information about the calculated checksum 14 to the saved record 8. Accordingly, when adding a new record of event 9 information about the calculated checksum 14 will be added to the record of event 9 and used to calculate the checksum for this record.

When changing data in any previous record, its checksum changes, which is included in the calculation of the checksum of the next record, therefore, when changing the data after generating the next records, it is possible to establish the fact of the change by comparing the saved and calculated checksums. It also prevents the possibility of adding new records between already saved records due to the fact that the checksums are calculated taking into account the time the records were saved in the BDS. Thus, increased reliability of storing information about events in the event registration database is provided.

Also, the data processing unit 2 can be performed in such a way that when receiving information about the end time of the event, compare the obtained value of the end time of the event with the current time

The difference between the current (exact time) and the end time of the event is an additional parameter for the possibility of reliability analysis in the future. For example, if the end time of an event significantly exceeds the current time, then this is an indicator of the incorrect end time either due to an incorrect time setting or due to an attempt to falsify on the side of the event source.

The event registration database management device may further comprise a record integrity checker implemented on the basis of a microcontroller, processor, or microprocessor. The integrity check of the BDRS 10 can be carried out by the unit for checking the integrity of records not only at the time of data storage by the data processing unit 2, but also at any time. The unit for checking the integrity of records can extract from the event registration database 10 information about the time the records were saved in the event database, the checksum values of the records in the event database, information about the start time of the event and the end time of the event, and calculate checksums starting from the first record and sequentially compare calculated and stored checksums. The coincidence of the checksums indicates the immutability of the data chain in the BDRS 10. The mismatch of the checksums indicates a violation of the integrity in the BDRS 10, which may be caused by an omission in the saving of records in the BDRS 10 or by intentional factors. A message is generated about the inconsistency and sent to data processing unit 2, on the basis of which a conclusion is made about the unsuccessful save operation and the administrator is informed to take measures to eliminate the accident.

The data processing unit 2 may further be configured to save an instance of the stored record 8 in at least one additional BDS 10, thereby ensuring storage of arbitration copies of the records and their backup. At the same time, to check the integrity of records, information about the time the records were saved in the event database, the checksum values of the records in the BDS or information about the time the event started and the time the event ended, the record integrity checking unit is used from different BDS 10. It is possible as a check of one record (with control matches checksums in each instance of BDS 10), and verification of all saved records.

Additionally, in the event registration database 10 there may be no functions for inserting and deleting records (only adding to the end of the database), which ensures, together with the integrity control mechanism, historical data immutability (once entered, it cannot be deleted or changed).

Claims (31)

1. A method of managing an event registration database, comprising the steps of: receive information about the event; determine the checksum of the previous event record; form an event record; save the generated event record in the event database and record the time of saving the generated record in the event database, and the data about the checksum of the previous event record and the time stamp containing information about the time the record was saved in the event database are added to the saved event record; calculate the checksum for the saved event record, taking into account the values of the checksum of the previous event record and the time the record was saved in the event database; add information about the calculated checksum in the previous step to the saved record. 2. The method according to p. 1, characterized in that it further comprises the step of determining the start time of the event and the time of the end of the event, said time stamp additionally containing information about the start and end time of the event. 3. The method according to any one of paragraphs. 1 or 2, characterized in that the storage time of the generated record in the event database, the start time of the event and / or the end time of the event is fixed by a trusted time source, such as GLONASS / GPS or a trusted time server. 4. The method according to any one of paragraphs. 1 or 2, characterized in that it further comprises the step of checking the integrity of the records. 5. The method according to claim 4, characterized in that the integrity of the records is checked based on information about the time the records were stored in the event database. 6. The method according to p. 4, characterized in that the integrity of the records is checked based on the values of the checksums of the records in the event database. 7. The method according to p. 4, characterized in that the integrity of the records is checked based on information about the start time of the event and the end time of the event. 8. The method according to p. 1, characterized in that it further comprises a step in which an instance of said stored record is additionally stored in at least one additional database, and to check the integrity of the records, information about the time the records were saved in the event database, control values the sum of the entries in the event database and / or information about the start time of the event and the end time of the event is used from various databases. 9. The method according to claim 1, characterized in that the checksum is obtained by means of a cryptographically secure hash function. 10. A device for managing an event registration database, comprising: a data receiving unit, configured to receive event information; a data processing unit, configured to: determine the checksum of the previous event record; generate an event record based on information received by the data receiving unit; save the generated event record in the event database and record the time the generated record was saved in the event database, and the data processing unit adds the checksum of the previous event record and the time stamp containing information about the time the record was saved in the database to the saved event record event data; calculate the checksum for the saved event record taking into account the checksum values of the previous event record and the time the record was saved in the event database; add to the saved record information about the calculated checksum in the previous step. 11. The device according to p. 10, characterized in that the data processing unit is further configured to determine the start time of the event and the end time of the event and include information about the start and end time of the event in the time stamp. 12. The device according to any one of paragraphs. 10 or 11, characterized in that the storage time of the generated record in the event database, the start time of the event and / or the end time of the event is fixed by the data processing unit by means of a trusted time source, such as GLONASS / GPS or a trusted time server. 13. The device according to any one of paragraphs. 10 or 11, characterized in that it further comprises a unit for checking the integrity of the records. 14. The device according to p. 13, characterized in that the integrity of the records is checked based on information about the time the records were stored in the event database. 15. The device according to p. 13, characterized in that the integrity of the records is checked based on the values of the checksums of the records in the event database. 16. The device according to p. 13, characterized in that the integrity of the records is checked based on information about the start time of the event and the end time of the event. 17. The device according to p. 10, characterized in that the data processing unit further stores an instance of said stored record in at least one additional database, and to check the integrity of the records, information about the time the records were stored in the event database, the checksum values of the records in an event database and / or information about an event start time and an event end time is used from various databases. 18. The device according to p. 10, characterized in that the checksum is obtained by means of a cryptographically secure hash function.

Images