Event log tamper-proof

Abstract

Embodiments are described for generating, by a processor, a first event record in response to a computer-executed event and generating, by the processor, a first tamper-evident record in response to generating the first event record. The first tamper-evident record includes a first signature created at least in part based on the first event record and a second signature created at least in part based on the first event record. Aspects also include verifying the first event record based on the first signature and the second signature in the first tamper-evident record in response to a request for detecting tampering with the first event record.

Description

Background Art

[0001] The present application relates to protecting records created by event loggers, and more particularly, to protecting records created by existing event loggers without affecting event log processing infrastructure.

[0002] In a system such as a server, an event logger may record event records corresponding to events, such as system events associated with the operation of the server. Enterprises may audit these recorded event records as part of regulatory compliance. To comply with regulations, the audit may have to verify that the content of the event record remains unmodified or that any changes have been tracked. Summary of the invention

[0003] The examples described throughout this application provide technical solutions to the technical problems of tamper-proofing in existing event log systems, so that enterprises can retain existing workflows and use existing log data containing event records. The provided technical solutions improve the functionality of event log systems.

[0004] The invention provides a method as claimed in claim 1, and a corresponding system and computer program as claimed in claims 9 and 10, respectively. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] These examples may be better understood with reference to the following drawings and descriptions. The components in the drawings are not necessarily to scale. In addition, in the drawings, the same reference numerals represent corresponding components in different views.

[0006] Figure 1 A system for practicing the teachings herein is shown.

[0007] Figure 2 An event log including tamper-resistant records is shown according to an embodiment.

[0008] Figure 3A An event record log including tamper-resistant records with multiple signatures is shown according to an embodiment.

[0009] Figure 3B An event log including tamper-resistant records with multiple signatures according to another embodiment is shown.

[0010] Figure 4 A method of generating a tamper-resistant record according to an exemplary embodiment is shown.

[0011] Figure 5 The enabling of tamper-resistant recording with multiple signatures according to an embodiment is shown.

[0012] Figure 6 The disabling of a tamper-resistant record with multiple signatures is shown according to an embodiment.

[0013] Additional features and advantages are achieved through the technical solutions, examples and various aspects of the technology described in detail herein. DETAILED DESCRIPTION

[0014] The present invention describes a technology for enhancing an existing event log system by an additional function of tamper resistance while retaining an existing workflow using log data generated by the event log system. The examples described throughout the document promote tamper resistance to log data without modifying the generated log data. The tamper resistance data generated for an event record is stored as another event record, and the tamper resistance data includes multiple signatures. In order to audit whether the event record has been tampered with, the content of the event record can be compared with other records. Other records can be bypassed during other operations. Therefore, the existing event log system can be improved to provide tamper resistance for regulatory compliance without incurring the cost of modifying the workflow using the existing workflow. In addition, the security level of the event log system can be improved by using multiple different signatures in the tamper resistance record. In an exemplary embodiment, the event log system is configured to manage signature data, and the signature data includes additional metadata associated with each signature and different payloads included in each signature. In addition, the event log system is configured to dynamically enable or disable individual signatures for data added to the event log, while maintaining the ability to verify the signed data using unaffected signatures.

[0015] Figure 1 An example system 100 is shown. The system 100 may be a computer, such as a server computer, etc. The system 100 may include a processor 110, a memory 120, a user interface 150, and a communication interface 170, among other components.

[0016] Processor 110 may be the central processor of system 100, responsible for executing the operating system, control instructions and applications installed on system 100. Processor 110 may be one or more devices operable to execute logic. Logic may include computer executable instructions or computer code embodied in memory 120 or other memory, which, when executed by processor 110, causes processor 110 to perform features implemented by the logic. Computer code may include instructions executable by processor 110. Computer code may include embedded logic. Computer code may be written in any computer language known now or developed later, such as C++, C#, Java, Pascal, Visual Basic, Perl, Hypertext Markup Language (HTML), JavaScript, assembly language, shell script or any combination thereof. Computer code may include source code and / or compiled code. Processor 110 may be a general purpose processor, a central processing unit, a server, an application specific integrated circuit (ASIC), a digital signal processor, a field programmable gate array (FPGA), a digital circuit, an analog circuit or a combination thereof. Processor 110 may communicate with memory 120 and other components of system 100. In one example, processor 110 may also communicate with additional elements such as user interface 150 and communication interface 170 .

[0017] The memory 120 may be a non-transitory computer storage medium. The memory 120 may be DRAM, SRAM, flash memory, or any other type of memory or combination thereof. The memory 120 may store an operating system 122 and applications 125 that may be executed by the processor 110. The operating system 122 and applications 125 may be stored on the memory 120 by a manufacturer, provider, or end user of the system 100. The memory 120 may include other data, such as images, videos, documents, spreadsheets, audio files, and other data that may be associated with the operation of the system 100. For example, the memory 120 may be used to store an event log 127.

[0018] The user interface 150 may include a display, a speaker, a keyboard, a mouse or any other component that is convenient for user interaction. The display may be touch screen enabled. The user interface 150 may alternatively or additionally be a microphone or any other component that may facilitate user interaction. The user interface 150 may be a circuit, such as a processor, a memory, a communication interface, an integrated circuit, an antenna, a resistor, a capacitor and any other hardware component. The user interface 150 may also relate to software. For example, the user interface 130 may include instructions and / or data that may be stored on a memory. Instructions and / or data may control the operation of the user interface 150. Instructions may be computer executable. Data may include parameters and / or preset conditions associated with the user interface 150.

[0019] The event record log 127 includes one or more event records 130a-130x. An event record is a data record that describes the operation of the system 100. The operating system 122 uses the processor 110 to record an event record in response to an operation being initiated and / or completed. For example, the event can be a startup event of the system 100, a file creation event, a file copy event, a user login event, or any other event that the operating system 122 can detect. The operating system 122 can be configured to detect events of a predetermined type. For example, the operating system 122 can be configured to detect "file" type events, such as file creation events, file copy events, file move events, file deletion events, file modification events, or any other file events. In addition or alternatively, the operating system 122 can be configured to detect "user" type events, such as user login events, user logout events, user profile change events, and other user events. Other event types are possible, and the above are just a few examples.

[0020] An event record is stored using a predetermined format. For example, an event record may include a header and a payload. The payload includes a description of the corresponding event. For example, if the corresponding event is a file event, the payload includes a file identifier, a file location, an indication of the operation performed, and other information describing the event. In an exemplary embodiment, the header includes metadata describing the payload, such as the length of the payload, a timestamp, etc. The event record may be a file. Alternatively, the event record may be an entry within a file or a stream (e.g., a log stream).

[0021] The event log 127 is used to verify the operation of the system 100. For example, the operating system 122 may include a system management tool (SMF). SMF companies can use the event log 127 to display compliance with regulations. For example, in order to comply with regulations, the system 100 may have to perform operations in a predetermined manner. SMF is convenient for querying the event log 127, such as via an application programming interface (API), to ensure that the system 100 complies with the predetermined operating mode. In this regard, the SMF or system auditor operates according to the predetermined format of the event record. Therefore, modifying the predetermined format can stop the current operation of the system auditor and SMF.

[0022] Regulatory compliance enables the SMF to ensure that the event records in the event log 127 have not been tampered with. It is critical. As described herein, adding such tamper-proof records may cause the SMF and system auditors to be modified, resulting in additional costs. The examples described throughout this document provide a technical solution to this technical problem.

[0023] Figure 2An example event record log 127 including a tamper-proof record 200 is shown. For example, the processor 110 may generate an event record 130a. In response, the operating system 122 may additionally generate metadata including tamper-proof information of the event record 130a. The operating system 122 may record or format the tamper-proof information as a separate event record, referred to in this document as tamper-proof record 200. The operating system 122 may then record the tamper-proof record 200 in the event record log 127. Thus, the processor may insert a separate record in the event record log containing the tamper-proof information of the event record 130a. The tamper-proof record 200 may use the same predetermined format of the event record.

[0024] For example, Figure 2 As shown, the tamper-proof record 200 includes a header 210, metadata 215, and a payload 220. In an exemplary embodiment, the payload 220 includes at least two digital signatures for the corresponding event record 130a. The digital signature proves the authenticity of the corresponding event record 130a. In one example, the digital signature is encrypted, such as using asymmetric cryptography or any other type of encryption technology. For example, each digital signature can be based on the content of the event record 130a, a private key, a public key, a timestamp, or other information of the event associated with the event record 130a. In an example, the content of the event record 130a can be hashed, such as using a hashing mechanism before encryption. In order to verify the event record 130a, the operating system 122 decrypts the digital signature in the payload 220 and compares the extracted data with the content of the event record 130a. The header 210 includes the length or timestamp of the payload 220. The metadata 215 includes an identifier indicating that the payload 220 contains tamper-proof information, which is different from the description of the event in the case of a typical event record. Additionally, metadata 215 includes information about the digital signature used in creating payload 220, such as the type of cryptography used for the digital signature.

[0025] In one example, the operating system 122 may associate the tamper-proof record 200 with a single event record, such as the event record 130a. For example, the header 210 may include a spatial reference to the event record 130a. The spatial reference may be a memory location of the event record 130a. Alternatively or additionally, the spatial reference may be a spatial relationship between the tamper-proof record 200 and the corresponding event record 130a. For example, the spatial relationship may be a predetermined relationship based on the memory locations of the records. In this case, the spatial reference of the first event record is implicitly identified based on the predetermined relationship and the memory location of the second event record, and therefore, the spatial reference is not avoided from being explicitly saved in the tamper-proof record.

[0026] Therefore, the spatial reference is either stored explicitly or can be implicit. If it is explicit, the location of the first event record 130a is stored in the tamper-proof record 200. The location can be the location of the first event record in a memory or in a file. When the spatial reference is implicit, it is related to the data in the memory or in the file. The system 100 can use a predetermined spatial relationship between the first event record 130a and the tamper-proof record 200. For example, according to the predetermined spatial relationship, the first event record 130a can be before the tamper-proof record 200, and there are no other records in between. Alternatively, the predetermined spatial relationship allows the presence of other event records of the same type as the first event record 130a between the first event record 130a and the tamper-proof record 200. In the example, other event records cannot be included in the tamper-proof data of the tamper-proof record 200 (which is the payload 200).

[0027] In an example, the operating system 122 may associate the tamper-proof record 200 with more than one event record in the event record log 127, such as with event records 130a to 130x. Thus, the header 210 may include a spatial reference to each event record associated with the tamper-proof record 200. In addition, the header 210 or metadata 215 may include the number of event records associated with the tamper-proof record 200 and the length of each corresponding digital signature included in the payload 220. In one example, the operating system 122 may associate the tamper-proof record 200 with a predetermined number of consecutive event records in the event log 127. For example, the tamper-proof record 200 may be associated with 5 consecutive event records, or 10 consecutive event records, or any other predetermined number of event records. Alternatively or additionally, the number of event records associated with the tamper-proof record 200 may be dynamically determined based on the number of event records stored in a predetermined memory range associated with the tamper-proof record 200. The spatial reference in the header 210 may identify the memory range associated with the tamper-proof record 200.

[0028] In another example, the operating system 122 may associate the tamper-proof record 200 with an event of a selected type, such as a file type event, a user type event, or any other type of event. For example, consider that the tamper-proof record 200 is associated with a file type event. If the operating system 122 generates an event record 130a in response to a file type event, the operating system 122 may associate the event record 130a with the tamper-proof record 200. In this case, the header 210 of the tamper-proof record 200 may indicate an identifier of the type of event record associated with the tamper-proof record 200. In the above example, the header 210 may include an identifier of the file type event. The operating system 122 may associate each file type event record with the tamper-proof record 200.

[0029] In yet another example, the operating system 122 may associate the tamper-proof record 200 with a group of continuous event records of the same type. The storage location of the event record in a group of continuous event records may be before the tamper-proof record 200, and vice versa. For example, in response to detecting two or more continuous events of the same type, the operating system 122 may generate a tamper-proof record 200 and associate the tamper-proof record 200 with the event records generated corresponding to the events. For example, the operating system 122 may generate a first event record 130a and a second event record 130b of the same type. In this case, the operating system 122 may generate a tamper-proof record 200 associated with the first event record 130a and the second event record 130b. In other examples, the tamper-proof record 200 may be associated with more than two event records of the same type.

[0030] In an exemplary embodiment, the digital signature in the tamper-proof record can be configured to cover only the event record data or to cover the data in the tamper-proof record (such as metadata or header). As used herein, the term coverage represents the data used to generate the digital signature. In other words, the data used to generate the signature is covered, while the data not used in the signature generation process is not covered or is not covered. When creating a second digital signature to be stored in the tamper-proof record, the data covered by both signatures or by only one of the signatures must be considered.

[0031] In one embodiment, for example Figure 3A The embodiment shown. The digital signature in the tamper-proof record only covers the event record data (i.e., the signature does not cover the tamper-proof information), there is no conflict between the data covered by the two digital signatures, and the signatures can be generated independently. In this embodiment, event records 1 to x are used to generate the two signatures in tamper-proof record 310, and for tamper-proof record 330, the same is true for records x+2 to x+y.

[0032] In other embodiments, for example Figure 3B In the embodiment shown in , the digital signature in the tamper-proof record covers the data in the current tamper-proof record, and the problem is more complicated. As shown in the tamper-proof record 310, there is usually metadata that needs to be covered as part of the signature (for example, the cryptographic method used to generate the signature).

[0033] In an exemplary embodiment, subsequent tamper-proof records will typically include information from previous tamper-proof records in their digital signatures so that the digital signatures are linked together to ensure that records have not been added or deleted (the tamper-proof record 330). Figure 3BAs shown, an example of a used data segment from a previous tamper-resistant record 330 is included in the new signature. In these embodiments, during record verification, verification of the first signature does not guarantee that tampering with the event log has not occurred because it does not cover the information required for the second signature. All signatures associated with the event log must be verified to verify that tampering has not occurred, although signatures can be verified individually.

[0034] Reference now Figure 3A , an event record log 300 including a tamper-resistant record with multiple signatures according to an embodiment is shown. As shown, the event log 300 includes multiple event records 302, a first tamper-resistant (TR) record 310, and a second tamper-resistant (TR) record 330. As shown, the first TR record 310 includes a header 312, metadata 314, a first signature 316, metadata 318, and a second signature 320. The header 312 includes a timestamp of the TR record 310. The metadata 314 includes information used to create the first signature 316, such as the type of cipher used, the spatial information of the event record 302 used, etc. The first signature 316 includes a digital signature created for the event record 302. Similarly, the metadata 318 includes information used to create the second signature 320, such as the type of cipher used, the spatial information of the event record 302 used, etc. The second signature 320 includes a digital signature created for the event record 302. In an exemplary embodiment, the cipher type used to create the first signature 316 and the second signature 320 are different.

[0035] The second TR record 330 includes a header 332, metadata 334, a first signature 336, metadata 338, and a second signature 340. The header 332 includes a timestamp of the TR record 330. The metadata 334 includes information used to create the first signature 336, such as the type of cipher used, spatial information of the event record 302 used, and the like. The first signature 336 includes a digital signature created for the event record 302. Likewise, the metadata 338 includes information used to create the second signature 340, such as the type of cipher used, spatial information of the event record 302 used, and the like. The second signature 340 includes a digital signature created for the event record 302. In an exemplary embodiment, the type of cipher used to create the first signature 316 and the first signature 336 is the same, and the type of cipher used to create the second signature 320 and the second signature 340 is the same.

[0036] Reference now Figure 3B , shows an event log 300 including tamper-proof records with multiple signatures according to an embodiment. Figure 3AThe event log 300 shown in FIG. 3 includes a plurality of event records 302, a first tamper-proof (TR) record 310, and a second tamper-proof (TR) record 330. Figure 3A In contrast to the illustrated embodiment, signatures 316, 320, 336, and 340 in the first TR record 310 and the second TR record 330 cover data other than the data in the event record 302. For example, as shown, signature 316 covers data in event records 1 through event records x, header 312, and metadata 314. Likewise, signature 320 covers data in event records 1 through event records x, header 312, metadata 314, signature 316, and metadata 318. As will be appreciated by one of ordinary skill in the art, various combinations of data fields to be covered by each signature may be used.

[0037] Figure 4 A method for generating a tamper-proof record according to an exemplary embodiment is shown. A processor implements the method. The method includes generating an event record by the processor in response to an event, as shown in block 405. The processor detects the occurrence of an event. For example, the processor can be configured to detect the occurrence of a predetermined event type. In response to the occurrence of an event of a predetermined type, the processor can generate an event record. The processor generates a tamper-proof record in response to the generation of the event record, as shown in block 410. Next, as shown in block 415, the processor adds a first signature and a second signature to the tamper-proof record. In an exemplary embodiment, the first signature and the second signature are created based at least in part on the event record, and different cryptographic functions are used to create the first signature and the second signature.

[0038] In an exemplary embodiment, the tamper-proof record also includes a spatial reference of the event record, the spatial reference identifying a memory location of the first event record. In these embodiments, a first signature is created based at least in part on the event record and the spatial reference of the event record. In an exemplary embodiment, a second signature is created based on the event record, the first signature, and the spatial reference of the event record. After the processor adds the signature to the tamper-proof record, the tamper-proof record is stored in an event record log, as shown in block 420. In response to a request to detect tampering of the first event record, the processor verifies the first event record based on the first signature and the second signature in the first tamper-proof record, as shown in block 425.

[0039] In an exemplary embodiment, the first tamper-proof record includes an identification of the type of cryptographic function used when creating the first signature and the second signature. The processor is further configured to generate a second event record in response to a second event being executed by a computer, and the second event occurs after the first tamper-proof record is generated. The processor then generates a second tamper-proof record in response to the second event record being generated. The second tamper-proof record includes a third signature created at least in part based on the second event record, and a fourth signature created at least in part based on the second event record, wherein the first signature and the third signature are created using the same cryptographic function, and the second signature and the fourth signature are created using the same cryptographic function. In an exemplary embodiment, the third signature is created at least in part based on at least a portion of the second event record and the first tamper-proof record. The fourth signature is created at least in part based on at least a portion of the second event record, the third signature, and the first tamper-proof record.

[0040] In an exemplary embodiment, the event logging system is configured so that the use of the second or third digital signature can be selectively enabled or disabled, i.e., turned on and off. In an exemplary embodiment, the enabling or disabling occurs at the boundary of the tamper-proof record by delaying the enabling or disabling until the tamper-proof record is written, or by immediately generating the tamper-proof record upon receiving an enabling or disabling request.

[0041] Figure 5 The enabling of a tamper-proof record with multiple signatures according to an embodiment is shown. In an exemplary embodiment, after creating a tamper-proof record 510 including a header 512, metadata 514 and a signature 516, a request for enabling the use of an additional signature is received. An indicator indicating the addition of a second signature is written to a metadata field 524 of a tamper-proof record 520 indicating that a signature change has occurred. The metadata 524 including the indicator will be overwritten by a signature 526 and optionally overwritten by a signature 530. Each digital signature metadata 524, 528 is stored in the tamper-proof record 520, and each signature 526 and 530 is generated, starting from the first signature until the tamper-proof record 520 is constructed. In the case of enabling, the second signature may not overwrite the previous tamper-proof record (i.e., not linked to the previous record), or may overwrite a portion of the previous record (e.g., the entire record or the same coverage as the primary signature). If a portion of the previous record is overwritten, it is sufficient not to overwrite the previous record with an additional signature because the first signature already overwrites the previous record.

[0042] Figure 6The disabling of a tamper-resistant record with multiple signatures according to an embodiment is shown. In an exemplary embodiment, after creating a tamper-resistant record 610 including a header 612, metadata 614, a signature 616, metadata 618, and a signature 620, a request to disable the use of an additional signature is received. An indicator indicating that the second signature was removed is written to a metadata field 634 of the tamper-resistant record 630, which indicates that a signature change occurred and that the tamper-resistant record 630 will only include a single signature 636. In an exemplary embodiment, when the signature option is enabled, disabled, or changed, a record link on a subsequent tamper-resistant record may or may not include the current tamper-resistant record.

[0043] Verification of tamper-evident records shall verify that the metadata for each signature is consistent (i.e., the previous record and the current record have the same metadata), unless the signature change indicator is also set. When enabled, the digital signature may be validated using the same overlay as used during record generation (i.e., verification may assume when computing the running hash if no secondary signature was used to overwrite the previous record.) This is in addition to any other testing performed during verification (time calculations, record counts, etc.).

[0044] In an exemplary embodiment, the processor may identify whether the event record is a tamper-proof record or a typical event record based on an identifier in the header 210 of the event record. The processor 110 may bypass or ignore the tamper-proof record 200, for example, unless the processor 110 performs a regulatory compliance audit of the event record log 127. During the audit, the processor 110 identifies the tamper-proof record 200 for each corresponding event record to be analyzed. The processor 110 determines whether the content of the event record has been modified or tampered by comparing the content of the event record with the digital signature in the payload 220 of the tamper-proof record 200. If the validity of the content of the event record is not confirmed based on the comparison, the processor marks the event record in the audit report or in any other way (such as by displaying an error, an audible annotation, or any other user notification). Alternatively, if the comparison confirms that the event record is tamper-free, the processor 110 continues to analyze the next event record and completes the audit report.

[0045] In the examples described throughout this article, the processor 110 can associate the tamper-proof record 200 with the corresponding event record without modifying the event record. Since the event record continues to use the predetermined event record format, any existing infrastructure and / or applications that read and analyze the event record log can continue to operate without any changes. Therefore, tamper-proofing for regulatory compliance can be added to existing infrastructure in an efficient manner without incurring the cost of modifying existing processes.

[0046] Therefore, the problem solved by the examples described throughout this application is to insert tamper-proofing into existing event log systems while retaining the ability of existing workflows and software that use existing log data. The example facilitates the transmission of digital signatures in log data as additional log data without modifying the data provided using the existing log API. Therefore, by providing tamper-proof metadata in the same format as other recorded event records, tamper-proof metadata can be directly integrated into the existing record log. This provides ease of use compatible with existing tools and portability when moving recorded event records. Tamper-proof information is transparently carried together with the recorded event records. By using the technical solutions described throughout this application, the logging platform can include tamper-proof data without affecting the core functions of the original platform.

[0047] The terms used herein are for the purpose of describing specific examples only and are not intended to be limiting. As used herein, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms "comprises" and / or "comprising" are used in this specification, the presence of stated features, integers, steps, operations, elements, and / or components is specified, but the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof is not excluded.

[0048] The corresponding structures, materials, actions, and equivalents of all means or step-plus-function elements in the following claims are intended to include any structure, material, or action for performing a function in combination with other claimed elements as specifically claimed. The examples in this document are presented for the purpose of illustration and description, and are not intended to be exhaustive or limited to those examples of the disclosed form. Many modifications and variations are apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. These examples are selected and described in order to best explain the principles and practical applications of the technical solution, and to enable other ordinary skill in the art to understand various examples with various modifications that are suitable for the specific purposes contemplated.

[0049] The technical solution can be implemented as a system, method and / or computer program product. The computer program product can include a computer-readable storage medium (or multiple media) having computer-readable program instructions thereon, and the computer-readable program instructions are used to cause a processor to perform various aspects of the technical solution.

[0050] A computer-readable storage medium may be a tangible device capable of retaining and storing instructions used by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device such as a raised structure in a groove with instructions recorded thereon or a punch card, and any suitable combination of the foregoing. As used herein, a computer-readable storage medium should not be interpreted as a temporary signal itself, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagated by a waveguide or other transmission medium (e.g., a light pulse by an optical fiber cable), or an electrical signal transmitted by a wire.

[0051] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device, or downloaded to an external computer or external storage device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network). The network can include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in a computer-readable storage medium in the corresponding computing / processing device.

[0052] The computer-readable program instructions for executing the operation of the technical solution can be assembly instructions, instruction set architecture (ISA) instructions, machine-related instructions, microcodes, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, programming languages ​​include object-oriented programming languages, such as Java, Smalltalk, C++, etc., and conventional procedural programming languages, such as "C" programming language or similar programming languages. The computer-readable program instructions can be executed completely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer and partially on a remote computer, or completely on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (for example, using an Internet service provider through the Internet). In some examples, the electronic circuit including, for example, a programmable logic circuit, a field programmable gate array (FPGA) or a programmable logic array (PLA) can execute the computer-readable program instructions to personalize the electronic circuit by utilizing the state information of the computer-readable program instructions, so as to perform the aspects described throughout the present application.

[0053] Aspects of the present application are described herein with reference to flowcharts and / or block diagrams of methods, devices (systems) and computer program products. It will be understood that each block of the flowchart and / or block diagram and the combination of blocks in the flowchart and / or block diagram can be implemented by computer-readable program instructions.

[0054] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device create a device for implementing the functions / actions specified in one or more boxes of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, which can guide the computer, programmable data processing device, and / or other equipment to work in a specific manner, so that the computer-readable storage medium having the instructions stored therein includes an article of manufacture, which includes instructions for implementing various aspects of the functions / actions specified in one or more boxes of the flowchart and / or block diagram.

[0055] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device, so that a series of operational steps are performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process, so that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / actions specified in one or more boxes of the flowchart and / or block diagram.

[0056] Flowchart and block diagram in the accompanying drawings show the possible architecture, function and operation of realizing according to the system, method and computer program product of various examples described herein.In this regard, each frame in flow chart or block diagram can represent the part, segment or module of instruction, and it comprises one or more executable instructions for realizing the logical function of appointment.In some alternative embodiments, the function mentioned in the frame may not occur in the order mentioned in the figure.For example, two frames shown continuously can actually be performed substantially at the same time, or these frames can sometimes be performed in reverse order, depending on the function involved.It will also be noted that the combination of each frame of block diagram and / or flow chart and frame in block diagram and / or flow chart can be realized by the dedicated hardware-based system of performing specified function or action or performing the combination of special hardware and computer instruction.

Claims

1. A computer-implemented method for protecting a log of one or more events by adding tamper resistance to the log, the method The following steps are involved: generating, by a processor, a first event record in response to an event executed by the computer; generating, by the processor in response to the first event record being generated, a first tamper-proof record, wherein the first tamper-proof record comprises: a first signature created based at least in part on the first event record; and a second signature created based at least in part on the first event record; and in response to a request to detect tampering of the first event record, verifying the first event record based on the first signature and the second signature in the first tamper-evident record; generating, by the processor, a second event record in response to a second event executed by the computer, the second event occurring after the first tamper-evident record is generated; In response to generating the second event record, the processor generates a second tamper-proof record, wherein the second tamper-proof record includes: a third signature created based at least in part on the second event record, wherein the third signature is created based at least in part on the second event record and at least a portion of the first tamper-evident record; and a fourth signature created based at least in part on the second event record, wherein the first signature and the third signature are created using a same cryptographic function and the second signature and the fourth signature are created using a same cryptographic function; and In response to the request to detect tampering of the second event record, the second event record is verified based on the third signature and the fourth signature in the second tamper-evident record.

2. The computer-implemented method of claim 1, in, The first tamper-evident record also includes an identification of a type of cryptographic function used in creating the first signature and the second signature.

3. The computer-implemented method of claim 1, in, The first tamper-evident record also includes a spatial reference of the first event record, the spatial reference identifying the first event record.

4. The computer-implemented method of claim 3, in, The second signature is created based at least in part on the first event record, the spatial reference of the first event record, and the first signature.

5. The computer-implemented method of claim 1, in, The fourth signature is created based at least in part on the second event record, the third signature, and at least a portion of the first tamper-evident record.

6. The computer-implemented method of claim 1, in, The first signature and the second signature are created using different cryptographic functions.

7. A system comprising means adapted to perform all the steps of the method according to any preceding method claim.

8. A computer program comprising instructions for performing all the steps of the method according to any preceding method claim when said computer program is executed on a computer system.

Images