Patent Description:
Charging Data Records (CDRs) are designed as aids to the operation and maintenance of a mobile network. The CDRs have been traditionally used for evaluating data traffic quantity for the purpose of billing.

As can be seen in "Forensic Cell Site Analysis: A Validation & Error Mitigation Methodology", the CDRs have further been utilized for complementing information provided via the Legal Intercept interfaces of mobile networks for purposes such as forensic analysis for law enforcement. The CDRs are generated by the Charging Data Function (CDF) and the Charging Gateway Function (CGF) functions in a Third Generation Partnership Project (<NUM> GPP) network and made available outside a telecom operator domain via an interface attached to a Data Retention System (DRS) as outlined, for example, in <CIT> DATA RETENTION AND LAWFUL INTERCEPT FOR IP SERVICES.

Blockchain-based solutions exist for verifying the integrity of data captured during a Lawful Intercept (LI) session and for providing information regarding the validity and completeness of the data transferred to the legal entity in response to establishing the LI session, as can be seen in <CIT> VERIFICATION OF LAWFUL INTERCEPTION DATA. Such a solution, however, would translate into an infinitely long intercept session which cannot be characterized and stored in a blockchain, making the solution unrealizable in the context of CDRs.

Further, adopting a similar integrity protection mechanism as used in the LI interfaces, e.g. ETSI TS <NUM><NUM>-<NUM>, would enable only the communication between the CDF and the CGF and potentially the CGF and the Data Retention function to be protected, but the CDF and the CGF themselves could still be tampered with.

Security logs are based on chaining the log entries using a combination of Message Authentication Codes (MACs) and Digital Signatures (DAs). Each logger has a pair of signing keys that guarantee authenticity and non-repudiation. In "Distributed Immutabilization of secure logs", the security logger periodically issues a hash in a checkpoint. The information included in the checkpoint allows for the verification of the block of entries between the current and the previous checkpoints. The hash is published in the blockchain for every issued checkpoint. Further, each log in the blockchain will have a log identifier to distinguish it from other logs. Solutions such as these, cause a lot of false alarms for the processing, that is common in the CDF and the CGF, that actually transform the original log. Furthermore, traceability of log changes is not provided by this solution.

LI interfaces include integrity protection for the data transferred outside the telecom operator domain while the live signaling and user plane capture ensures that any malicious interference is extremely difficult to achieve. However, CDRs go through several processing steps before being stored in a DRS and sometimes the original data may be destroyed after each processing stage. This creates opportunities for attack by unauthorized users who may gain access to the system and may remove or alter the CDRs before being stored securely in the DRS. An additional problem with such solutions is the possibility to insert fake CDRs that may be used to falsely implicate a person or an organization during investigations by a Law Enforcement Agency (LEA).

While blockchain is known to being used for protecting files, as explained above, applying such solutions directly to CDRs would provide a suboptimal solution due to the following: Firstly, searching for a record in a blockchain is time and compute-power intensive. The power consumption is quite high for fulfilling the consensus protocols while performing the CDR search. Secondly, a new address is generated for every transaction. Thirdly it requires processing the log files in real time, and simultaneously, confirming authenticity and integrity of an entry in the log. Fourth, requiring the 3GPP CDF or CGF nodes to store the entire blockchain database would mean use of excessive amounts of memory storage.

Therefore, new solutions are needed to address the problem of providing integrity protection for CDRs.

<CIT> discloses methods, systems and program products which are directed to monitoring device usage and communications in order to enforce smart contracts that are verified with a distributed computing archi-tecture through a blockchain.

<CIT> discloses a method and system for improving construction integrity of phone bill and Charging Data Function (CDF) thereof to solve the technical problem that the loss of Accounting Request (ACR) messages for constructing phone bill may be caused during the CDF primary-to-backup switch, resulting in generating massive incomplete phone bills.

In order to overcome one or more problems described above, an object of the invention is to provide or enable integrity protection of a CDR. Further the invention provides many advantages, as can be seen below:.

To achieve said object, according to a first aspect, there is provided a Charging Data Function, CDF, device for providing integrity protection of a Charging Data Record, CDR, comprising a memory and one or more processors. The said memory comprises instructions which when executed on the said one or more processors, cause the CDF device to, firstly, receive, from a Charging Trigger Function, CTF, device the CDR. Secondly, compute a hash value of the CDR. Thirdly, to store the hash value and a CDR identifier of the CDR in a blockchain ledger. Further, to obtain an index for the hash value stored in the blockchain ledger, and finally, to send the index to a Charging Gateway Function, CGF device.

According to a second aspect, there is provided a CGF device for providing integrity protection of a CDR. The CGF device comprises a memory and one or more processors. The said memory comprises instructions which when executed on the said one or more processors, cause the CGF device to, receive, from a CDF device, a first index; obtain, from a blockchain ledger, a first hash value using the first index; compute a second hash value of the CDR and compare with the first hash value obtained from the blockchain ledger; perform processing of the CDR if the first hash value matches with the second hash value; compute a third hash value of the processed CDR; and store in the blockchain ledger, the third hash value and the first index of the first hash value.

According to a third aspect, there is provided a method performed by a CDF device for providing integrity protection of a CDR. The method comprises receiving, from a CTF device the CDR. The method further comprises computing a hash value of the CDR. the method further comprises storing the hash value and a CDR identifier of the CDR in a blockchain ledger. The method still further comprises obtaining an index for the hash value stored in the blockchain ledger. Finally, the method further comprises sending the index to a CGF device.

According to a fourth aspect, there is provided a method performed by a CGF device for providing integrity protection of a CDR. The method comprises receiving, from a CDF device, a first index. The method further comprises obtaining, from a blockchain ledger, a first hash value using the first index. The method further comprises computing a second hash value of the CDR and compare with the first hash value obtained from the blockchain ledger. The method further comprises performing processing of the CDR if the first hash value matches with the second hash value. The method further comprises computing a third hash value of the processed CDR. The method still further comprises storing in the blockchain ledger, the third hash value and the first index of the first hash value.

In an embodiment according to the first and third aspect, comprises storing the hash value and the CDR identifier at the same index.

In an embodiment according to the first and third aspect, the index comprises an indication of a position of the stored hash value and the CDR identifier in the blockchain ledger.

In an embodiment according to the first and third aspect, the index is any one of the following: a transaction ID or a block height identifier.

In an embodiment according to the first and third aspect, further comprises sending the CDR to the CGF device.

In an embodiment according to the first and third aspect, comprises sending the CDR via a Data Record Transfer Request message.

In an embodiment according to the first and third aspect, comprises sending the CDR and the index together using one or more Information Elements of a Data Record Packet.

In an embodiment according to the first and third aspect, comprises sending together the CDR and the index comprised in a list of indices using one or more fields of a Information Element of the Data Record Transfer Request.

In an embodiment according to the second and fourth aspect, the index is any one of the following: a transaction ID or a block height identifier.

In an embodiment according to the second and fourth aspect, the first index comprises an indication of a position of the first hash value and the CDR identifier in the blockchain ledger.

In an embodiment according to the second and fourth aspect, comprises receiving the CDR via a Data Record Transfer Request message.

In an embodiment according to the second and fourth aspect, comprises receiving the CDR and the index together via an Information Element of Data Record Packet.

In an embodiment according to the second and fourth aspect, comprises receiving the CDR and the index comprised in a list of indices via one or more fields of an Information Element of Data Record Transfer Request.

In an embodiment according to the second and fourth aspect, comprises obtaining a second index from the blockchain ledger where the third hash value and the first index of the first hash value are stored.

In an embodiment according to the second and fourth aspect, further comprises storing the CDR in a Data Retention System.

In an embodiment according to the second and fourth aspect, comprises storing the second index along with the CDR in the Data retention system.

In an embodiment according to the second and fourth aspect, storing in the blockchain ledger, the third hash value of the processed CDR and the first index of the first hash value, for a LEA device to verify the integrity of the CDR by obtaining the stored third hash value of the processed CDR.

According to a fifth aspect, there is provided a system adapted for providing integrity protection of a CDR, comprising a CDF device, a CGF device and a LEA device, the system being operative to: receive at the CDF device, from a CTF the CDR; compute at the CDF device, a first hash value of the CDR; store by the CDF device, the first hash value and a CDR identifier of the CDR in a blockchain ledger; obtain at the CDF device, a first index for the first hash value stored in the blockchain ledger; send from the CDF device to the CGF device the first index; receive at the CGF device, from the CDF device, the first index; obtain at the CGF device, from a blockchain ledger, the first hash value using the first index; compute at the CGF device, a second hash value of the CDR and compare with the first hash value obtained from the blockchain ledger; perform at the CGF device, processing of the CDR if the first hash value matches with the second hash value; compute at the CGF device, a third hash value of the processed CDR; store by the CGF device in the blockchain ledger, the third hash value and the first index of the first hash value; obtain at the LEA device from the blockchain ledger, the third hash value of the processed CDR; and verify at the LEA device, the integrity of the CDR or the processed CDR.

In an embodiment according to the fifth aspect, the system is further operative to store, by the CGF device at a Data Retention System, DRS, the processed CDR; obtain at the LEA device from the DRS, the processed CDR; and verify at the LEA device, the integrity of the CDR or the processed CDR using the processed CDR and the third hash value of the processed CDR.

One or more embodiments disclosed herein propose a solution that uses lightweight blockchain such as the blockchain ledger <NUM>, a Charging Data Function (CDF) such as the CDF device <NUM> and a Charging Gateway Function (CGF) such as the CGF device <NUM> to enable storing of a hash value associated with a Charging Data Record (CDR) in the blockchain ledger <NUM>. The CDF device <NUM> sends an index on the blockchain to the CGF via the Ga interface. The CGF device <NUM> accesses the blockchain ledger <NUM> based on the index that is received and extends its CDR validation process by computing a hash and comparing it with the data retrieved from the blockchain ledger <NUM>. If these values match, the CDR is further processed by the CGF device <NUM>, e.g. according to 3GPP specification. When the CGF device <NUM> finishes processing the CDR, it computes a new hash value and stores the new hash value in the blockchain along with the index of the original record that it received.

To further elaborate on the invention described herein, <FIG> illustrates different components used for providing integrity protection of a CDR. More specifically, the components include a Charging Transfer Function (CTF) device <NUM>, a CDF device <NUM>, a Blockchain ledger <NUM>, a CGF device <NUM>, a Data Retention System (DRS) <NUM> and a Law Enforcement Agency (LEA) <NUM> device. Further, the CTF device <NUM> and the CDF device <NUM> communicate via an interface with a reference point Rf, the CDF device <NUM> and the CGF device <NUM> communicate via an interface with a reference point Ga, the interface modified according to the invention disclosed herein, the blockchain ledger <NUM> and the LEA device <NUM> communicate via a Hi-B interface modified according to the invention disclosed herein. The LEA device <NUM> and the DRS <NUM> communicate via an interface such as the Handover Interface-A (Hi-A) or Handover Interface-B (Hi-B). Ga is a reference point between a CDF and the CGF for CDR transfer. Rf is a reference Point between the CTF within a network element and the CDF for offline charging. The Hi-A and Hi-B interfaces may be defined according to a standard e.g. ETSI TS <NUM><NUM>. The Hi-B interface may be modified or extended to include the blockchain index for the CDR in the data provided as part of a "Retained Data response" message, e.g. as defined in ETSI TS <NUM><NUM>.

The CTF, e.g. the CTF device <NUM>, is a node or an entity or a device which will generate charging events based on network resource consumption by a party or a subscriber.

The CDR is a formatted collection of information about the charging event, such as those generated by the CTF device <NUM>, e.g. time of call set-up, duration of the call, amount of data transferred, etc., for use in billing and accounting. For each party to be charged, for parts of or all charges of a chargeable event, a separate CDR shall be generated, i.e. more than one CDR may be generated for a single chargeable event, e.g. because of its long duration, or because more than one charged party is to be charged. GPRS protocol used for the CDR transport, henceforth referred to as GTP', is a protocol derived from GPRS Tunneling Protocol (GTP) with enhancements to improve transport reliability for the CDR. In other words, GTP' is the transport protocol associated to the Ga reference point, providing functions for transfer of CDRs from the CDF device <NUM> to the CGF device <NUM>.

The CDF device <NUM> and the CGF device <NUM> are entities or nodes or devices inside the core network domain, subsystem or service that are involved in charging for that domain, subsystem or service. The CDF - CGF communication is carried out using GTP' over UDP/TCP and IP. Each CDF, e.g. the CDF device <NUM>, has an Operation, Administration, Maintenance and Provisioning (OAM&P) configurable address list of CGFs, e.g. the CGF device <NUM>, to which it may send the CDRs. The list is organized according to CGF address priority order. If the primary CGF device <NUM> is not available, e.g. out of service, then the CDF device <NUM> may send the CDRs to the secondary CGF device <NUM> and so on.

The DRS <NUM> comprises an Administration Function 105a configured to exchange administrative, request and response information with the LEA device <NUM> via the interface Hi-A. Additionally, the DRS <NUM> includes a Mediation/Delivery Function 105b configured to retrieve retained data from storage means 105c of the DRS <NUM> and forward such data in a format according to the invention to the LEA device <NUM>, through the interface Hi-B.

Blockchain technology is based on maintaining a distributed ledger which keeps track of messages exchanged among different entities. A blockchain such as Blockchain ledger <NUM> comprises a continuously extendable list of records, so called blocks, which are linked using cryptographic techniques. Typically, each block contains a cryptographic hash of the previous block in the chain, a timestamp and data. The reading and writing of data on the blockchain may be performed through blockchain-specific libraries. For example, in the Ethereum blockchain, such libraries could be web3 or Metamask. Further, as an example, for Ethereum blockchain, the blockchain client may exchange application layer messages such as JavaScript Object Notation, JSON, over Hypertext Transfer Protocol, HTTP, POST. Further details on specific libraries are beyond the scope of the invention and as such, documentation of these libraries could be easily consulted by someone skilled in the art, for example, to identify the relevant calls to achieve the effect of sending a transaction to the ledger or reading the ledger values at a certain index. There might be several ways of actually storing of the data in the blockchain. For example, the data may be stored in a data field associated to a transaction, or as part of a smart contract. It may be appreciated by those skilled in the art that one could choose the implementation based on some additional criteria such as cost optimization.

In an embodiment, the data in a block of the blockchain ledger <NUM> comprises at least one of: a hash value of the CDR and a CDR identifier. In yet another embodiment, the data comprises an index of a block and a hash value of a CDR. The index of a block may, for instance, be the index at which the hash value or some other hash value is stored. In some embodiments, the data comprises a one or more CDR identifiers, one or more indices of a block and one or more hash values of a CDR.

For use as a distributed ledger, a blockchain is managed by a peer-to-peer network, i.e., the blockchain network, in which all nodes, for example, the CDF device <NUM>, the CGF device <NUM> and the LEA device <NUM>, collectively adhere to a protocol for validating new blocks. By design, a blockchain is inherently resistant to modification of the data, e.g. a CDR, the hash value of the CDR or the index of the stored hash of the CDR, because, once recorded, the data in any given block cannot be altered retroactively without alteration of all subsequent blocks, which would require consensus among the majority nodes in the network. The likelihood of malicious actors altering the data is, thus, very low.

<FIG> illustrates a flow diagram according to an embodiment of the invention. As illustrated by Arrow <NUM>, the procedure begins with the CTF device <NUM> sending a CDR to the CDF device <NUM>. The CDR may be sent over the Rf interface.

Arrow <NUM>: Upon receiving the CDR, the CDF device <NUM> computes a first hash value of the CDR. The first hash value may be computed by using any hash function that can be used to map data, e.g. the CDR, of arbitrary size to fixed-size values. It may be noted that this hash procedure of the CDR is independent of/in addition to the cryptographic hash procedure performed in the blockchain. Additionally, the CDF device <NUM> associates a CDR identifier with the CDR. The CDR identifier may be a random number, a name or a combination of both, that identifies a particular CDR.

Arrow <NUM>: As a preliminary step, a blockchain client, e.g. the blockchain client 102a, is set-up. The set-up of the blockchain client 102a may comprise a plurality of specific steps. However, such steps are known to the skilled person and are therefore not described in further detail herein. The CDF device <NUM> stores the computed first hash value and the CDR identifier in the blockchain ledger <NUM>. In other words, the CDF device <NUM> instructs a blockchain client such as the blockchain client 102a comprised in the CDF device <NUM>, to perform the storing of the first hash value and the CDR identifier in the blockchain ledger <NUM>. The blockchain ledger <NUM>, in this case, may be running on a separate blockchain network. This embodiment has an advantage that the CDF device <NUM> is not required to unnecessarily store large amounts of blockchain transaction data including the hash values or the CDR identifiers of the all previous and future CDRs.

Alternatively, in some embodiments the blockchain client 102a itself acts as the blockchain ledger <NUM>. In this case, the CDF device <NUM> stores, the computed first hash value and the CDR identifier in the blockchain ledger <NUM>, within the blockchain ledger <NUM>, i.e. the blockchain client 102a, comprised in the CDF device <NUM>. The CDF device <NUM> is, in this case, directly part of the blockchain network.

In view of both the embodiments above, it is not required to store the CDR itself in the blockchain ledger <NUM>, instead only the hash value of the CDR is stored. This has an advantage of consuming less memory space on the blockchain network, faster processing, less power consumption and increased security since the CDR itself is not stored.

In some embodiments, the first hash value and the CDR identifier are stored at the same index, e.g. a first index, in the blockchain ledger <NUM>. In some other embodiments, the first hash value and the CDR identifier are stored at different indices in the blockchain ledger <NUM>. In some embodiments, the first hash value and the CDR identifier are stored in the same transaction of a blockchain. Storing both the first hash value of the CDR and the CDR identifier simplifies the verification of integrity of the CDR, e.g. verifying that the CDR has not changed over a timeline which is important in e.g. criminal investigation. A further advantage is that storing, the hash value associated to the CDR in the blockchain ledger <NUM> by the CDF device <NUM> enables securing the CDR.

Arrow <NUM>: The CDF device <NUM> obtains a first index from the blockchain ledger <NUM>. The term 'obtain' may be construed to mean to first send a request, e.g. a request for a first index, and then to receive a response, e.g. receiving the first index. In some embodiments, the first index is the index in the blockchain ledger <NUM> at which at least the first hash value is stored. In some embodiments, the first index is a transaction ID. In some other embodiments, the first index is a block height identifier.

The CDF device <NUM> may obtain the first index from the blockchain ledger <NUM> via the blockchain client 102a. Alternatively the CDF device <NUM> obtains the first index from the blockchain client 103a when the blockchain client 103a itself is the ledger.

Arrow <NUM>: The CDF device <NUM> sends the first index to the CGF device <NUM>. The CGF device <NUM> may send the first index via the Ga interface. The Ga interface may be modified to include the first index in an information element of a message, e.g. Data Record Transfer Request. The Ga interface may employ the GTP' protocol to transfer the first index from the CDF device <NUM> to the CGF device <NUM>.

There could be different ways in which the first index could be sent. As exemplification, two such procedures are described herein as part of the invention, wherein the first index and the CDR are sent together from the CDF device <NUM> to the CGF device <NUM>.

A Data Record Transfer Request (DRTR) message is used to transmit at least a CDR from the CDF device <NUM> to the CGF device <NUM>. The DRTR message comprises Information Elements (IE) as shown below according to Table <NUM>.

As an example, a typical CDR transfer procedure is summarized below:.

<FIG> illustrates a Data Record Packet (DRP) IE. The DRP IE is present conditionally based on whether the Packet Transfer Command is 'Send Data Record Packet' or 'Send possibly duplicated Data Record Packet'. It may contain one or more CDRs. If an "empty packet" is to be sent, then the DRP IE contains only the Type, with value <NUM> in decimal, and the Length, with value <NUM>, fields.

According to <FIG>, there are two fields identifying the CDR format: Data Record Format and Data Record Format Version. The format of the CDRs may be ASN. <NUM> or some other format, as identified by the value of Data Record Format. The Data Record Format Version identifies the Technical Specification release and version numbers that were used for the CDR encoding. The fields Data Record <suffix> refer to the CDRs being sent.

As can be further seen from <FIG>, a new field has been introduced, namely the Blockchain index of CDR. Each Data Record, e.g. the CDR, is associated with its respective first index that is included in the field Blockchain index of CDR. The field Blockchain index of CDR comprising the first index occupies at least <NUM> octet in length in the DRP IE.

Thus, it is enabled by the invention, to send a first index, indicating a position at which the first hash value and the CDR identifier is stored in the Blockchain ledger <NUM>, from the CDF device <NUM> to the CGF device <NUM>.

The Private Extension (PE) IE is optional and typically contains network vendor or operator specific information. The PE IE may be used to send the first index. As can be seen from <FIG>, the PE IE comprises one or more indices, represented as Blockchain index <NUM>. n, and their corresponding CDRs, represented as CDR <NUM>. The blockchain index may, for example, be the first index as described above with respect to arrow <NUM>. In an embodiment, the one or more blockchain indices and their corresponding CDRs are comprised in a list. In some other embodiment, the one or more blockchain indices and their corresponding CDRs are comprised in a dictionary of key-value pairs. In some embodiments, each individual blockchain index and/or the CDR are included in a separate field.

Arrow <NUM>: The CGF device <NUM> receives the first index and the CDR from the CDF device <NUM>. Using the first index, the CDF device obtains the first hash value of the CDR and/or the CDR identifier from the blockchain ledger <NUM>. The term 'obtain' may be construed to mean to first send a request, e.g. a request for a first hash value, and then to receive a response, e.g. receiving the first hash. It is assumed that a blockchain client, e.g. the blockchain client 104a, is already set-up. The set-up of the blockchain client 104a may comprise a plurality of specific steps. However, such steps are known to the skilled person and are therefore not described in further detail herein. The CGF device <NUM> may instruct the blockchain client such as the blockchain client <NUM>, to obtain the first hash value and/or the CDR identifier from the blockchain ledger <NUM>. The blockchain ledger <NUM>, in this case, may be running on a separate blockchain network. In some other embodiments, the blockchain client 104a is itself the blockchain ledger <NUM> in which case the first hash value and the CDR identifier are retrieved from within the ledger stored in the CGF device <NUM>.

The large number of transactions stored in the blockchain ledger <NUM> makes it computationally expensive to search for a transaction that might contain a specific data value. The index, such as the first index, enables to quickly find where in the blockchain ledger <NUM> the hash value associated to a CDR entry was stored. Such reduction of compute resources is useful for securing the CDR integrity protection process because the CGF device <NUM> does not typically have large amounts of compute power at its disposal most of which is used to process the CDR in near real time. A second advantage of obtaining the index is to achieve easy traceability of the CDR using the CDR identifier stored at the index.

Arrow <NUM>: The CGF device <NUM> computes a second hash value of the CDR received from the CDF device <NUM>. The CGF device <NUM> may use a similar function as the CDF device <NUM> to compute the second hash value. The second hash value is then compared with the obtained first hash value to determine if there is a match. If the two hash values match, then the CDR is verified to be a correct and untampered CDR.

Arrow <NUM>: The CGF device then proceeds to process the CDR after evaluating that the first hash value and the second hash value match. Processing the CDR may refer to the CDR undergoing semantical and/or syntactical sanity checks. Further, the processing may include that the CGF device <NUM> determines that a CDR is not well formatted, or otherwise incorrect or corrupt. In such case when the CDR is determined to be not well formatted, incorrect or corrupt, the CGF device <NUM> may fill one or more defective CDR parameters with an appropriate "replacement" indicator within the limits of the syntax allowed for the parameter. If the error renders the CDR unusable, i.e. the above replacement of erroneous parameters is not possible, then no further action of the CGF device <NUM> may be performed regarding the CDR. An example of a case where the erroneous parameter cannot be replaced is when the "CDR type" attribute of the CDR received by the CGF device <NUM> is corrupted.

Arrow <NUM>: Once a processed CDR, i.e. CDR without errors or with corrected errors, is obtained or upon completion of the processing of the CDR, the CGF device <NUM> computes a third hash value on the processed CDR). Similar hash function as used in the case of computing the first hash value and/or the second hash value may be used.

Arrow <NUM>: The CGF device <NUM> then stores the third hash value of the processed CDR and the first index of the first hash value of the CDR in the blockchain ledger <NUM>. In other words, the CGF device <NUM> instructs a blockchain client such as the blockchain client 104a comprised in the CGF device <NUM>, to perform the storing of the third hash value and the first index of the first hash value in the blockchain ledger <NUM>. Both the third hash value and the first index may be stored at a second index in the blockchain ledger <NUM>. The blockchain ledger <NUM>, in this case, may be running on a separate blockchain network.

Alternatively, in some embodiments the blockchain client 104a itself acts as the blockchain ledger <NUM>. In this case, the CGF device <NUM> stores the computed third hash value and the first index in the blockchain ledger <NUM>, i.e. the blockchain client 102a, comprised in the CGF device <NUM>. The CGF device <NUM> is in this case directly part of the blockchain network.

By storing the first index of the first hash value together with the third hash value of the processed CDR, the CGF device <NUM> certifies that this processed CDR was obtained from the initial CDR, i.e. the CDR sent from the CDF device <NUM> before processing. This enables a provision for proof of origin of the processed CDR, even though the initial CDR may have been deleted.

A further advantage with this procedure is that it is made more difficult for an attacker to insert malicious CDR values at the CGF device <NUM>. For example, assume that an attacker manages to insert a malicious CDR when the CDR is received at the CGF device <NUM>. One or more embodiments according to the invention enable easy verification of whether all initial CDRs were processed or not, and as to which processed CDR is associated to which initial CDR. If the processed CDR cannot be traced to the initial CDR via the first index, the CDF could simply be discarded by a verifying entity e.g. the LEA device <NUM>.

The CGF device <NUM> then obtains the second index from the blockchain ledger <NUM>. The term 'obtain' may be construed to mean to first send a request, e.g. a request for the second index, and then to receive a response, e.g. receiving the second index.

An advantage of obtaining the second index is to enable a verifying entity e.g. the LEA device <NUM> to reduce the compute power consumption related to searching for the third hash value associated to the processed CDR in the blockchain ledger <NUM>. A further advantage is cost reduction in case of offline processing of the CDR at the LEA device <NUM>.

Arrow <NUM>: The CGF device <NUM> stores the processed CDR and the second index in the DRS <NUM>. In other words, the CGF device sends the processed CDR and the second index to the DRS <NUM> to store.

Arrows <NUM>-<NUM>: The LEA device <NUM> includes the LEA function i.e. a law enforcement agency that contains a LEA Monitoring Facility. The LEA device <NUM> receives from the DRS <NUM> a new CDR, e.g. the processed CDR, together with an index (e.g. the second index), that needs to be checked for validity, henceforth referred to as 'CDRv'. In order to perform the verification, the LEA device <NUM> first computes a hash value of the CDRv. The LEA device <NUM> then, using the index that was received with the CDRv, obtains the hash value stored in the blockchain ledger <NUM> at this index. The LEA device <NUM> may instruct a blockchain client e.g. the blockchain client 106a to obtain/retrieve the particular hash value. As a next step, the LEA device <NUM> compares the retrieved hash value with its own-computed hash value for verification. If the two hash value match, the LEA device <NUM> concludes that the CDRv is valid. If the own-computed hash value differs from the retrieved hash value stored in the blockchain, the LEA device <NUM> concludes that the CDR is invalid and takes necessary action, e.g. discard and log the occurrence, raise an alarm, etc..

Thus, an enhanced integrity protection of the CDR is achieved.

<FIG> illustrates a method performed by the CDF device <NUM> to provide integrity protection of the CDR. The method comprises.

In an embodiment, the hash value is the first hash value. In an embodiment, the index is the first index.

<FIG> illustrates a method performed by the CGF device <NUM> to provide integrity protection of the CDR. The method comprises.

In an embodiment, the method further comprises obtaining from the blockchain ledger <NUM> a second index at which the third hash value and the first index of the first hash value is stored.

<FIG> illustrates the CDF device <NUM> for providing integrity protection of the CDR comprising.

In general terms, each functional unit <NUM>-<NUM> i.e. the receive unit <NUM>, the compute unit <NUM>, the instruct unit <NUM>, the obtain unit <NUM> and the send unit <NUM>, may be implemented in hardware or in software. Preferably, one or more or all functional units <NUM>-<NUM> may be implemented by the one or more processors <NUM>, possibly in cooperation with the computer readable storage medium <NUM> or the memory <NUM>. The one or more processors <NUM> may thus be arranged to fetch instructions, from the computer readable storage medium <NUM> or the memory <NUM>, as provided by a functional unit <NUM>-<NUM> and to execute these instructions, thereby performing any steps of the CDF device <NUM> as disclosed herein.

The CDF device <NUM> according to <FIG> may have storage and/or processing capabilities. The CDF device <NUM> may be configured to control any of the methods and/or processes described herein and/or to cause such methods, and/or processes to be performed. Processor <NUM> corresponds to one or more processors <NUM> for performing CDF device <NUM> functions described herein. The CDF device <NUM> includes memory <NUM> or computer readable storage medium <NUM> that is configured to store data, programmatic software code and/or other information described herein. In particular, in addition to a traditional processor and memory, the CDF device <NUM> may comprise integrated circuitry for processing and/or control, e.g., one or more processors and/or processor cores and/or FPGAs (Field Programmable Gate Array) and/or ASICs (Application Specific Integrated Circuitry) adapted to execute instructions. The processor(s) <NUM> may be configured to access, e.g. write to and/or read from, the memory <NUM> or the computer readable storage medium <NUM>, which may comprise any kind of volatile and/or nonvolatile memory, e.g., cache and/or buffer memory and/or RAM (Random Access Memory) and/or ROM (Read-Only Memory) and/or optical memory and/or EPROM (Erasable Programmable Read-Only Memory).

The memory <NUM> or the computer readable storage medium <NUM> may include instructions which, when executed by the one or more processors <NUM>, cause the CDF device <NUM> perform the processes described herein with respect to the CDF device <NUM>, e.g. method(s) described in relation to <FIG>. The instructions may be software (SW) or computer program associated with the CDF device <NUM>.

Thus, the CDF device <NUM> may further comprise SW or computer program, which is stored in, for example, the memory <NUM> or the computer readable storage medium <NUM> at the CDF device <NUM>, or stored in external memory, e.g., database, accessible by the CDF device <NUM>. The SW or computer program may be executable by the one or more processors <NUM>.

<FIG> illustrates the CGF device <NUM> for providing integrity protection of the CDR comprising.

In an embodiment the compute unit <NUM> and the compare unit <NUM> are integrated together in a single compute and compare unit.

In general terms, each functional unit <NUM>-<NUM>, i.e. the receive unit <NUM>, the obtain unit <NUM>, the compute unit <NUM>, the compare unit <NUM>, the perform unit <NUM>, and the instruct unit <NUM>, may be implemented in hardware or in software. Preferably, one or more or all functional units <NUM>-<NUM> may be implemented by the one or more processors <NUM>, possibly in cooperation with the computer readable storage medium <NUM> or the memory <NUM>. The one or more processors <NUM> may thus be arranged to fetch instructions, from the computer readable storage medium <NUM> or the memory <NUM>, as provided by a functional unit <NUM>-<NUM> and to execute these instructions, thereby performing any steps of the CGF device <NUM> as disclosed herein.

The CGF device <NUM> according to <FIG> may have storage and/or processing capabilities. The CGF device <NUM> may be configured to control any of the methods and/or processes described herein and/or to cause such methods, and/or processes to be performed. Processor <NUM> corresponds to one or more processors <NUM> for performing CGF device <NUM> functions described herein. The CGF device <NUM> includes memory <NUM> or computer readable storage medium <NUM> that is configured to store data, programmatic software code and/or other information described herein. In particular, in addition to a traditional processor and memory, the CGF device <NUM> may comprise integrated circuitry for processing and/or control, e.g., one or more processors and/or processor cores and/or FPGAs (Field Programmable Gate Array) and/or ASICs (Application Specific Integrated Circuitry) adapted to execute instructions. The processor(s) <NUM> may be configured to access, e.g., write to and/or read from the memory <NUM> or the computer readable storage medium <NUM>, which may comprise any kind of volatile and/or nonvolatile memory, e.g., cache and/or buffer memory and/or RAM (Random Access Memory) and/or ROM (Read-Only Memory) and/or optical memory and/or EPROM (Erasable Programmable Read-Only Memory).

The memory <NUM> or the computer readable storage medium <NUM> may include instructions which, when executed by the one or more processors <NUM>, cause the CGF device <NUM> perform the processes described herein with respect to the CGF device <NUM>, e.g. method(s) described in relation to <FIG>. The instructions may be software (SW) or computer program associated with the CGF device <NUM>.

Thus, the CGF device <NUM> may further comprise SW or computer program, which is stored in, for example, the memory <NUM> or the computer readable storage medium <NUM> at the CGF device <NUM>, or stored in external memory, e.g., database, accessible by the CGF device <NUM>. The SW or computer program may be executable by the one or more processors <NUM>.

A computer program product in the form of a computer readable storage medium <NUM>, <NUM> may comprise any form of volatile or non-volatile computer readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media, for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD), and/or any other volatile or non-volatile, non-transitory device readable and/or computer-executable memory devices that store information, data, and/or instructions that may be used by one or more processors <NUM>, <NUM>.

Computer readable storage medium <NUM>, <NUM> may store any suitable instructions, data or information, including a computer program, software, an application including one or more of logic, rules, code, tables, etc. and/or other instructions capable of being executed by one or more processors <NUM>, <NUM>. Computer readable storage medium <NUM>, <NUM> may be used to store any calculations made by one or more processors <NUM>, <NUM>. In some embodiments, one or more processors <NUM>, <NUM> and computer readable storage medium <NUM>, <NUM> may be considered to be integrated.

<FIG> illustrates a system <NUM> comprising the CDF device <NUM>, the CGF device <NUM> and the LEA device <NUM> operative to perform any of the function(s)/method(s) described in relation to the devices <NUM>, <NUM>. The procedure is briefly described as follows: The CDR is received at the CDF device <NUM>, from the CTF device <NUM>. The CDF device <NUM> computes a first hash value of the CDR. The CDF device <NUM> then stores, the first hash value and a CDR identifier of the CDR in the blockchain ledger <NUM>. The CDF device <NUM> then obtains a first index for the first hash value stored in the blockchain ledger <NUM> and sends to the CGF device <NUM> the first index. The CGF device <NUM> obtains from the blockchain ledger <NUM>, the first hash value using the first index. The CGF device <NUM> then computes a second hash value of the CDR and compares with the first hash value obtained from the blockchain ledger <NUM>. The CGF device <NUM>, further performs processing of the CDR if the first hash value matches with the second hash value. The CGF device <NUM> computes a third hash value of the processed CDR and stores in the blockchain ledger <NUM>, the third hash value and the first index of the first hash value. A verifying entity such as the LEA device <NUM> obtains, from the blockchain ledger <NUM>, the third hash value of the processed CDR; and verifies the integrity of the CDR or the processed CDR.

In addition to the above steps, the CGF device <NUM> may store the processed CDR at the DRS <NUM>. Further, the LEA device <NUM> may obtain from the DRS <NUM>, the processed CDR and then verify at the LEA device <NUM>, the integrity of the CDR or the processed CDR using the processed CDR and the third hash value of the processed CDR.

Clearly, several modifications will be apparent to and can be readily made by those skilled in the art without departing from the scope of the present invention. Therefore, the scope of the invention shall not be limited by the illustrations or the preferred embodiments given in the description in the form of examples, but rather be defined by the following claims.

Claim 1:
A Charging Data Function, CDF, device (<NUM>) for providing integrity protection of a Charging Data Record, CDR, comprising a memory and one or more processors, said memory comprising instructions which when executed on the said one or more processors, cause the CDF device (<NUM>) to:
- receive, from a Charging Trigger Function, CTF, device (<NUM>) the CDR;
- compute a hash value of the CDR;
- store the hash value and a CDR identifier of the CDR in a blockchain ledger (<NUM>);
- obtain an index for the hash value stored in the blockchain ledger (<NUM>); and
- send the index to a Charging Gateway Function, CGF device (<NUM>).