Method and system of generating immutable audit logs

ES 2 553 341 T3

DESCRIPTION

Method and system for generating immutable audit records

The state of the art today is based on the use of digital signatures (based on public key infrastructure) accompanied by a precise time and date indicator to provide authenticity to the data susceptible to an additional audit although the issues are not addressed following:

a) In systems with a significant transaction volume, the required action is not profitable or it is not even possible to implement it directly due to the lack of performance of digital signatures.

b) Digital signatures and time stamps do not by themselves provide the guarantee that there has been no erasure of records without notification, which in fact means that immutability is not a characteristic of such record records.

US 5978475, hereinafter referred to as D1, proposes a method that requires a trusted machine that stores the log entries from an untrusted machine that generates them. In practice this means that there should be a differentiation of roles when the management of machine U (untrusted) is different from machine T (trusted). In D1, the receiver function (prepared to decrypt log data) is distinguished from the auditor (intended to verify the integrity of log entries) although the auditor is also receiver (because the encryption / decryption key is derived from the key authentication). In D1, new authentication and therefore encryption keys are generated for each registry entry.

Document WO2005 / 098564A, hereinafter referred to as D2, discloses a method in which a new key is recursively generated from a previous one for each registry entry which means that each registry entry is encrypted with a different key. The protocol defined in D2 applies a digital signature to each registry entry (see page 11 lines 10-16 and page 12 lines 2230), meaning this is a limitation because it will not work in environments with data loading because the digital signature is a operation with a high computational cost. In D2, the functions of auditor (can verify log entry integrity) and receiver (can decrypt log data) are not differentiated.

Document EP 1 243 999 A, hereinafter referred to as D3, explains the use of a record chaining class, during an integrity check in which the direction of the repeated scanning or counting of cryptographic values ​​is backward. That is, to check a fixed number of log entries, the D3 protocol begins by checking from the most recent entry to a previous entry.

The D1, D2 or D3 protocols do not consider the addition of 'metronome inputs' at regular intervals to continue adding links to the chain even in the case of not receiving registry entries as considered by the protocol of this invention.

Also, documents D2 and D3 do not explain how the integrity of the registry is guaranteed in an untrusted environment because the private key used for digital signatures is stored on the machine that generates the registry so that a malicious intruder who gains access privileges Administrator can re-create part or all of the record while having access to the private key used for digital signatures.

The present invention addresses both issues, providing an inexpensive method and system even with significant transaction volumes that guarantee immutability. The use of both symmetric message authentication hash functions to create the links and digital signatures for link parts make it possible to generate immutable digital strings in an economical way using conventional industry hardware and software.

Summary of the invention

With the proposed invention no one can alter the audit information that is recorded, regardless of access privilege, without creating clear evidence of what happened and when it happened: that is, the records become truly immutable.

The invention proposes a centralized scalable immutable audit log server that can receive audit information from multiple sources in an information sharing environment. The immutable audit log server processes such audit information and stores it in a way that ensures the integrity of the marked recording. The information could also be encrypted to ensure confidentiality.

This invention uses digital signatures to provide authenticity to audit records and hash functions with

ES 2 553 341 T3 security key to create a digital chain in which all audit recordings are links. The proposed algorithm creates multiple parallel chains and digitally signs parts or sections of links instead of each of the links to achieve a high volume of transactions.

The symmetric session keys used in the hash functions to create the digital chain are stored encrypted using the public key of the authorized auditor. An auditing tool is presented to allow auditors to verify data integrity, decrypt information, and generate required audit reports. Using PKI (Public Key Infrastructure) ensures that only authorized auditors can access.

Brief description of the drawings

Figure 1 is an illustration of an exemplary embodiment of a system in which the invention may be implemented. There are several sources (310) of information that communicate with the IAL server through a network (410) of local area (LAN, Local Area Network) and / or a network (405) of wide area (WAN, Wide Area Network) .

Figure 2 is an illustration of a software architecture showing an exemplary implementation of the invention. There is a communications layer (505) that provides an API (705) to communicate with the sources (310) of information, a cryptographic layer (510) that generates the immutable audit chains and a persistent layer (515) that stores the chains immutable audit trails in a bulk data store that creates the immutable audit record (610).

Figure 3 shows how the immutable digital chain audit information links are generated. The audit information (125) mi is added to the link i, optionally encrypted (215), as E (mi) where E (mi) = mi if there is no encryption. Said audit information (125) mi added to the link number i is concatenated at the same time to the authentication label (105) h¡_1 obtained in the previous link i-1 and the type (110) and a function ( 210) MAC using a session key (120) K to obtain the authentication tag h, which is also added to the link i.

Detailed description

The present invention proposes to generate immutable audit records of audit information provided by one or more information sources. A separate unit is proposed, the Immutable Audit Log Server (IAL Server), which involves the following steps:

a) receive the audit information for storage. An API (application programming interface) is provided to allow communication with the different sources of audit information;

b) processing the audit information by applying cryptographic routines to generate one or more immutable digital strings containing at least the audit information divided between the links, optionally encrypted; only authorized auditors will be able to verify the integrity of the immutable digital chain and access the audit data; Y

c) storing said digital string (s) on a mass storage medium, such as a hard drive, WORM, storage area network (SAN), etc.

The system described herein is preferably implemented as a software program platform independent Java implementation running on a standard hardware independent server. However, the system can be implemented in various embodiments using other well-known implementations, such as, for example, Microsoft's .net technology or C ++. Executable applications, as described herein, are computer programs (software) stored in main memory or secondary memory on any suitable computer preferably running Linux or Windows. Such computer programs, when run, enable a processor to implement the features of the present invention. A programmer can implement the system as disclosed herein, using commercially available development tools. Obviously, as technology changes, other computers and / or operating systems may be preferable in the future. In a preferred embodiment, the use of an industry standard Hardware Security Module (HSM) to execute at least the software routines responsible for generating the immutable digital strings provides an even higher degree of security.

The system is proposed in a software architecture of three layers: 1) the client or communications layer, which is in charge of connecting with sources of audit data; 2) the business or cryptographic stratum / layer, which is in charge of generating the immutable digital chains; 3) and the persistent data storage stratum in charge of storing the data in a persistent storage, mainly a database, although said data could also be files on the server side or in any other storage of

ES 2 553 341 T3 legacy data.

Layered, or layered application design is useful for many different reasons. In a multi-layer design, each layer can be run on a separate machine, or machines, allowing for improved throughput. Depending on the design, multiprocessor machines, or many different standalone computers can be used to improve performance. Effective layering can lend structure to your application, promote scaling, and support long-term maintenance requirements for your code.

Connection to audit data sources

To receive the audit information to store, the IAL server provides an application programming interface. At least two levels of communication standards are defined:

a) The transport protocol to connect the audit information sources with the ITB. The invention proposes as a network transport protocol to use standard HTTPS TLS / SSL calls over TCP / IP in which both the IAL server and the authentication audit information sources authenticate node to node with trusted certificates. Other communication protocols such as syslog, secure syslog, etc. can also be used.

b) The format and content of messages sent / received with the audit information. Various known standard data communication protocols can be used to send / receive the information, such as SOAP, Burlap, Hessian, HTTP invoker, and RMI.

Generate Immutable Digital Strings

Definitions:

Messages m0 to mn: the audit data information provided in any beloved to the IAL server will be called a message in order to store it safely.

Input: tuple of values ​​such as a message, an indicator or timestamp, a link and the type of the message, and so on.

Registry: ordered set of inputs h: hash function

PAud: encryption with the auditor's public key

Sial: encryption with the private key of the IAL server

DSial: digital signature made by IAL, so that DSial (x) = SiAL (h (x)) ts: indicator or timestamp ||: concatenation

MAC: (Message Authentication Code) is an authentication label obtained by applying an authentication scheme, together with a secret key, to a message. Unlike digital signatures, MACs are computed and verified with the same key, so that only the intended recipient can verify them. There are four types of MAC: (1) unconditionally secure, (2) based on hash function, (3) based on stream encryption, or (4) based on block encryption.

Hash with security key: MAC based on hash function

HMAC: MAC based on hash function

The immutable digital strings according to this invention are generated following the cryptographic protocol defined below:

1. The IAL server establishes at least one session key (symmetric key) that will reach the auditor securely encrypted using public key cryptography:

1.1. The IAL server randomly generates a session key, K.

ES 2 553 341 T3

1.2. The IAL server securely destroys the old previous session key (if it exists).

1.3. The IAL server encrypts the new key with the auditor's public key (PAud), obtaining K '= PAud (K)

1.4. The IAL server produces a one-way hash of the encrypted key K ', obtaining H = h (K'), and encrypts the hash using its own Sial private key. In other words, digitally sign the encrypted K 'key obtaining K' '= Sial (H) = DSial (K')

1.5. The IAL server adds the K ', the K ”, an indicator or timestamp, the constant 1 and the digital signature of all previous data to the digital string. That is, the input0 = (m0, ts, DS0 = SiAL (h (m0 || ts || 1)), 1) where m0 = PAud (K)

two. The second input in the digital chain has type 3 of 'Metronome input' and is formed with a tuple of at least 4 values: m-ι, the indicator or timestamp ts, the link with the previous input formed as the result OF digitally signing said two elements m1 and ts together with the previous link digital signature DS0; and the type t1 (the constant 3) according to the formula input1 = (m1, ts, DS1 = SiAL [h (m1 || ts || DS0 || 3)), 3) where m1 is formed by at least one identifier of chain. The metronome inputs are added to the digital chain at regular predefined intervals, thus providing digital signatures to the parts of messages contained in the digital chain between a metronome input and the previous one in the chain.

3. Each mi message containing audit data is added to the digital string preserving the sequence order. Each added input is derived to form the string from the previous input, inputi-1, according to the formula: inputi = (mi, ts, hi = MACK (mi || ts || hi-1 || 4), 4 ) where the value 4 corresponds to the type of input ('message input').

Four. As can be seen, the session key is used to calculate a cryptographic Message Authentication Code (MAC) for the entry to be registered and the MAC of the previous entry each time an entry is added to the string. digital. You can change the session key after a predefined time or a predefined number of iterations and start using a new one as defined in stage 1, to provide another level of security.

5. The log would have no end being an infinite string if it never stopped (for example if the server needs maintenance). Then it closes safely by creating a special trailing entryN of the type 'closing entry worthy'. The IAL server forms this final entry with a tuple of at least four elements: mn, the timestamp ts, the link to previous N-1 entries by digitally signing said elements mN and ts together with the previous link hash hN-1; and the constant 2 as tN inputN = (mN, ts, hN = SiAL [h (mN || ts || hN-1 || 2)], 2) where mN contains at least the identifier of the string.

In a system that uses encryption, all incoming messages, from m1 to mn, are encrypted using a symmetric encryption algorithm with key K (message m0 will never be encrypted, because m0 is the key already encrypted with the public key of the auditor). In a preferred embodiment, AES is the encryption algorithm, but others can also be used, such as DES, 3DES, IDEA, etc.

When the auditor receives a record to audit, he can check its integrity and validate it using the session keys and verifying the digital signatures using the public key of the IAL server. The authorized auditor can obtain the used session keys by decrypting them using their private key, thereby verifying the entire audit trail.

All session keys for symmetric encryption have been encrypted under the auditor's public key and digitally signed using the private key of the IAL server (see section 3.1). The auditor can obtain the session keys by sequentially processing the record. Each time the auditor finds an entry of the type 'new key entry', he can obtain the session key and verify its integrity by verifying its digital signature.

The auditor verifies each entry according to its type and its position in the chain, recreating the same process followed during its generation and verifying the MACs and digital signatures. The entries are verified preserving the order of sequence.

If the system is compromised, the attacker has no way to recreate the MACs (the only way is to know the session key) so they cannot modify it without detection. The authorized auditor will then use the session keys to re-create the digital chain and check whether or not the inputs are still intact.

Consider what happens if an intruder chooses to simply delete or truncate a record rather than attempt to modify existing entries without detection. Of course, new valid entries cannot be added after a record has been truncated, as the intermediate links will be lost, and this will be detected during verification.

ES 2 553 341 T3

Now consider an intruder who deletes entries from the bottom of the registry; In this scenario, the lack of new entries could suggest to the authorized auditor that the system is still secure and that what is happening is that no data has been received recently. The use of metronome inputs prevents this type of attack: metronome inputs are special registry entries that are made at regular intervals. If an intruder deletes entries at the end he will delete the metronome inputs as well, or if he leaves the metronome inputs, their digital signatures will not match and the authorized auditor will be able to detect the situation (where the last valid entry indicates the earliest time that it could have been log truncated).

In the case of a rogue auditor, the session key provides the ability to falsify log entries, but since there are periodic digital signatures of the recordings, this type of attack will also be detected because even though the MAC verification shows no errors, the verification of the digital signature will.

An optional enhancement considers the same method but ensuring that multiple simultaneously contained digital strings reduce latency and benefit more from computational overhead. The IAL server will establish as many simultaneous different session keys as there are records. Each record is independent of the others and works independently. But, in order to detect the deletion of an entire record, all the records are securely linked in a chain at creation time. Thus, a record cannot be completely erased without detection. Additionally, metronome inputs are added to all current registers at the same time, so all registers should have the same number of metronome inputs. Metronome inputs added at the same time have the same identifier value (makes it easier to detect truncation). Subsequently, the authorized auditor can validate that these metronome inputs are present at the time of verification.

The use of an industry standard hardware security module (HSM) where at least the private and public key pair for digital signatures are generated, guarantees the immutability of the digital chain because no one can access the private key used to sign, even those privileged users such as system administrators.

The IAL server public key can be certified by a trusted third party or even by the auditor's organization to ensure that no one will impersonate the IAL server and generate falsified audit records.

An industry standard hardware security module (HSM) or smart card or USB token is used to generate at least one private key, keep it always secret, and use it to calculate and add digital signatures to at least one of said one or more immutable digital strings. .

Storage of the immutable digital string (s) on a mass storage medium

The persistent data layer is responsible for storing the immutable digital string (s) that are being generated. In a simple implementation, the immutable digital string (s) will be stored in files on the server hard drive but in a preferred implementation, the immutable digital string (s) (s) will be stored in a database that could use the same server hard drives but also external storage such as network storage (NAS, Network Attached Storage, usually a cabinet with hard drives attached directly to the server or via channel connection). fiber). The files and the database can also be stored on a WORM device, optionally.

The present invention can be carried out in other specific ways without departing from its basic characteristics and the described embodiments are to be considered in all respects only as illustrative and not limiting. The scope of the invention is therefore indicated by the appended claims.