Method for obfuscating LLM generated code

Abstract

A method (10) for obfuscating program code (23) by means of a linguistic model (22) comprises the following steps:-obfuscating (11) the program code (23) by means of the linguistic model (22),-generating (12) an executable file (43) from the obfuscated program code (23),-dynamically de-obfuscating (13) the executable file (43) until the de-obfuscating (13) ends or no new result is generated,-storing (14) an indicator of the dynamic de-obfuscating (13),-generating (14) the dynamic de-obfuscating (13) by means of the linguistic model (22). -returning (15) the indicator of the dynamic de-obfuscation (13) and optionally the generated program code (23) to the language model (22) for further iterative obfuscation (11).

Description

Technical Field

[0001] The present invention relates to a method for obfuscating LLM generated code. Background Art

[0002] Program code is increasingly generated with the aid of language models, such as large language models (LLMs). This can occur, for example, within the scope of language translation or automatic program code translation or code refactoring.

[0003] Using a scheme for automatically generating code, for example from an LLM, always comes with challenges, so the correctness of the code cannot be guaranteed, and performance improvements cannot be guaranteed.

[0004] Obfuscation, obfuscation or code masking is understood as changing the code and the compiled executable files in such a way that the program is almost incomprehensible to a human, while the program remains functionally correct. The advantages of code masking are increased security against tampering and protection against reverse engineering, for example to protect the intellectual property of the algorithm. Especially when dealing with larger code bases, performing obfuscation quickly becomes complex. Summary of the invention

[0005] A first general aspect of the present disclosure relates to a method for obfuscating program code by means of a language model.

[0006] The method includes

[0007] - obfuscate program code with the help of language models,

[0008] - Generate executable files from obfuscated program code,

[0009] - Dynamically deobfuscate the executable until the deobfuscation ends or produces no new results,

[0010] -Store dynamic deobfuscation indicators,

[0011] - Returning dynamically deobfuscated metrics and optionally generated program code to the language model for further iterative obfuscation.

[0012] A second general aspect of the present disclosure relates to a method for training a language model for obfuscating program code.

[0013] The method includes

[0014] - generate program code,

[0015] - obfuscating a program code by means of a method according to the first general aspect of the present disclosure,

[0016] - generating a reward for the language model, wherein the reward is generated according to the stored indicator of dynamic deobfuscation and / or the stored indicator of code complexity,

[0017] -Update the language model weights with the value of the reward.

[0018] A third general aspect of the present disclosure relates to a computer system designed to execute the method according to the first and / or second general aspect (or embodiments thereof).

[0019] A fourth general aspect of the present disclosure relates to a computer program designed to perform the method according to the first general aspect (or its embodiments).

[0020] A fifth general aspect of the present disclosure relates to a computer-readable medium or signal storing and / or containing a computer program according to the fourth general aspect (or an embodiment thereof).

[0021] The techniques of the first, second, third, fourth and fifth general aspects may, in some cases, have one or more of the following advantages.

[0022] The present disclosure uses artificial intelligence methods, such as LLM, to generate obfuscated or masked code. The masked code is then inspected, dynamically de-masked, and statically analyzed for complexity. Feedback from the analysis is then fed back into code generation.

[0023] The present disclosure achieves: effective testing of code obfuscated with the aid of LLM, so that LLM can generate better concealed code. To this end, verification and validation (V&V) techniques can be used around the code to protect the results of the language model, i.e., to verify and validate its correctness. This powerful or complete automation improves efficiency. V&V techniques are used to: ensure that the results are (potentially) correct, provide feedback to the user on the correctness, confidence and / or quality of the translation, and make code obfuscation more reliable. In addition, the suitability of the generated code is measured dynamically and statically in the form of a concealment index. The more the code is concealed, i.e., the more difficult or time-consuming the reverse engineering is, the greater the obfuscation index of the code.

[0024] Typically, working with larger code bases often degrades the usefulness of static methods, such as abstract interpretation, because correctness guarantees cannot be computed within a reasonable time frame, or require approximations that introduce over-approximation errors. Furthermore, static methods are rarely suitable for measuring software performance, such as runtime. The present disclosure implements a dynamic approach, i.e., for the runtime of the code.

[0025] The present disclosure implements obfuscation of program code with non-deterministic characteristics because a language model such as LLM is used. The prior art usually relies on syntax to insert masking instructions. For each proposed tool, it is theoretically possible to develop a specific reverse engineering tool to reverse the syntax used. Using LLM provides non-deterministic characteristics, which makes reverse engineering difficult.

[0026] The present disclosure uses a language model such as LLM to generate masked code. Confusion feedback is provided to generate better input (cue words) to the language model, which generates better obfuscated code.

[0027] Code obfuscation is a reinforcement against reverse engineering. The present disclosure additionally enables tracking of unauthorized copies. Code obfuscation essentially inserts a "fingerprint" into the software, which acts like a security feature. For example, this allows tracking how, for example, an extracted firmware is further distributed.

[0028] The present disclosure relates to any product based on automated testing, especially dynamic testing methods, and any product with legacy code or performance issues.

[0029] Certain terms in this disclosure are used in the following manner.

[0030] A “language model” may in particular be a large language model (LLM), a neural network, a recurrent neural network (RNN), a transformer model or a code model, as a language model specifically for code, or even a completely general language model which also includes code. This also includes computer languages, such as program code of a computing device such as a computer. The language of the model may include not only natural languages ​​but also artificial languages ​​such as programming languages.

[0031] "Refactoring" of code means in software development: structural improvements to the code while maintaining observable program behavior, i.e., functionality. In this case, performance, i.e., runtime and / or storage requirements, should be improved primarily. In addition, readability, comprehensibility, maintainability, and / or scalability can be improved, for example, with the goal of reducing the corresponding expenditure for error analysis and / or functional expansion. Typical refactorings are, for example, renaming variables to self-explanatory names and / or extracting parts of the code into their own methods. Refactoring improves the quality of the code, thereby improving the quality of the software.

[0032] "Testing", "checking" or "comparing source program code and target program code" may include: formal checking of the source program code and the target program code for identical behavior, for example by means of bounded model checking, testing in the source language, contract testing in the source language and / or syntactic and stylistic testing, fuzz testing, mutation of test tool input, derivation of contracts in the source language and / or target language and / or derivation of language models.

[0033] A "Test-Harness" or test framework includes a collection of software and test data, which is used to systematically test programs in an automated manner under different environmental conditions. A test harness typically includes a test execution engine that handles the test logic and a test data repository or database that contains test scripts, test programs, and other test resources. Here, the test harness is automatically generated by, for example, adding differential tests to a database. The start of the test can be started with a given or pre-made test from a test database. The system can also automatically generate tests.

[0034] The data here can be software code, including test cases and test tools plus additional (natural language) descriptions of functional modes or validity ranges. In the case of language translation, C is described as the source language and Rust is described as the target language, but other combinations are also possible. Translating C into Rust is interesting because Rust provides features in the field of safety-critical systems, but there is a lot of legacy code in other languages ​​(especially C). In the case of refactoring, the source language and the target language are the same.

[0035] "Contracts" are an integral part of programming by contract or design by contract ("design by contract"). This is a software development concept that aims to optimize the cooperation of individual program modules by defining formal contracts that go beyond the use of statically defined interfaces.

[0036] The term "codebase" refers to the totality of the source text files belonging to a project and any configuration files belonging to it. A codebase can also contain various other files required for the compilation process, such as so-called Makefiles.

[0037] A "test case" is a specific input and a specific test pass from a test harness or fuzzer. To ensure reproducibility, interesting passes are stored (finding new code paths or crashes).

[0038] Instrumentation is used to make coverage metrics observable, for example during compilation. Instrumentation is the insertion of instructions into a program to obtain feedback about the execution. Instrumentation is mostly implemented by the compiler and can, for example, describe the code blocks reached during execution.

[0039] "Obfuscation", "obfuscation" or "code masking" is understood as: changing the representation and compiled executable files in such a way that the program is almost incomprehensible to a human, while the program remains functionally correct. The advantage of code masking is increased security against tampering and reverse engineering, for example to protect the intellectual property of the algorithm.

[0040] Think of "deobfuscation" as the effort to make obfuscated code or obfuscated files more readable and understandable. Deobfuscation is a tool for reverse engineering. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 is a flow chart illustrating the disclosed technique for obfuscating program code.

[0042] Figure 2 A system is schematically shown in which the disclosed technique for obfuscating program code may be used.

[0043] Figure 3 A system with a dynamic deobfuscator and a static complexity check is schematically shown in which the disclosed techniques for obfuscating program code may be used.

[0044] Figure 4 A system is schematically shown in which the disclosed technique for obfuscating program code may be used.

[0045] Figure 5 is a flow chart illustrating the disclosed technique for training a language model. DETAILED DESCRIPTION

[0046] Figure 1 1 is a flow chart showing a method 10 for obfuscating program code by means of a language model. The program code can be generated manually or also by means of a language model. For example, the code is generated in an automatic program code translation from a source language to a target language. Alternatively, the program code can be generated by code refactoring.

[0047] The method 10 proposed in the present disclosure aims at obfuscating program code by means of a language model. The software may be designed for: controlling, regulating and / or monitoring an engineering system, in particular a cyber-physical system, in particular at least one computing unit of a vehicle. In particular, the software may be embedded software designed for execution on an embedded (i.e., for example, task-specific) system.

[0048] In a first step, the program code is obfuscated with the aid of a language model 11. To this end, the program code is input into the prompt words of the language model together with the corresponding commands, so that the language model performs the obfuscation. Changing commands or inputs will produce variants in the output of the language model, which can be used to iteratively improve the language model.

[0049] Generate 12 executable files from the obfuscated program code.

[0050] The executable is then dynamically deobfuscated 13. If deobfuscation 13 ends or produces no new results, this stops. For example, if the deobfuscation indicator or the dynamic deobfuscation indicator shows an infinite loop or hang, that is, if the deobfuscation process is stuck, which causes the deobfuscation indicator to be high, no new results are expected. Dynamic deobfuscation can monitor the collection of program output and measure program behavior, such as traces at runtime. The deobfuscator attempts to deobfuscate the executable, such as by accessing an oracle, so that the results of the deobfuscation are always functionally correct for the obfuscated executable.

[0051] The metrics of the dynamic deobfuscation 13 are then stored 14. The two processes, dynamic deobfuscation and storage, can be performed dynamically in parallel or time-interleaved. The metrics of the dynamic deobfuscation 12 can include deobfuscation runtime, code traces, program output and / or program behavior such as runtime. The metrics are stored for comparison for subsequent improvement of the mask.

[0052] The static complexity check of the program code is performed 15 until the execution 15 ends or no new results are produced. For example, if the measurement shows an infinite loop or hang, that is, if the measurement is stuck, which leads to a high indicator of code complexity, no new results can be expected.

[0053] Then optionally, an indicator of code complexity is stored 16. These two processes, i.e., static complexity checking and storage, can be performed dynamically in parallel or time-interleaved. The indicator of code complexity can include components such as cyclomatic complexity, number of source code lines, number of executable code lines, coupling and / or inheritance depth, maintainability index, cognitive complexity, Halstead indicators (such as Halstead amount and / or rework rate). The indicators are also stored for comparison in order to subsequently improve the mask.

[0054] Dynamic deobfuscation 13 of the executable file and static complexity checking of execution 15 of the program code can be performed in parallel. Likewise, two stored procedures of the indicator can be executed in parallel. Here, the term "parallel" also includes the case where the procedures are started at the same point in time, where one of the procedures does not end faster. Here, the term "parallel" also includes the case where the procedures are executed in parallel only during a portion of their runtime.

[0055] Finally, optionally, the indicators of the dynamic deobfuscation 13 and optionally the generated program code and / or code complexity are fed back 17 to the language model for further iterative obfuscation 11. Thus, better input requests to the language model can be generated. All elements of the feedback can be fed back in whole or in part.

[0056] For the case where the program code is generated by a language model, the indicators of dynamic deobfuscation 13, the generated program code and / or the code complexity can be fed back to the language model to further iterate the generation of obfuscation by the language model. Therefore, better input requests to the language model can be generated. All elements of the feedback can be fed back in whole or in part.

[0057] Program code generation and obfuscation can be performed with the help of language models. This can be two different language models or a single language model.

[0058] Optionally, the generated codes can be stored in a database together with their metrics and compared later. For efficiency reasons, only the best performing codes, i.e. the codes with the highest metrics for dynamic deobfuscation, can be stored. Likewise, some of the best codes and their corresponding metrics can be stored.

[0059] After dynamic deobfuscation and static complexity checking or calculations are complete, verification and validation (V&V) techniques can be applied to the code to ensure functional correctness. V&V techniques can also be performed in parallel with the dynamic deobfuscator and static complexity calculations.

[0060] To this end, the quality of the program code may be evaluated according to an indicator, wherein the indicator includes, for example, a code quality indicator, a test quality indicator and / or a test quantity.

[0061] Optionally, the code generated by the LLM can also be fed back into the language model (LLM) as feedback to generate a new generation of source code. The idea is that the already adapted (or better) code can then be fine-tuned in terms of code masking using updated input requests containing new code. For example, if the good code already has only low masking values ​​at certain locations, said locations can be fed back into the LLM.

[0062] According to one embodiment, the method further comprises comparing the stored indicators of the dynamic deobfuscation 12 and / or the stored indicators of the code complexity of the differently obfuscated program codes to determine the best obfuscated program code.

[0063] Instead of the described translation, a reconfiguration of the program code may be provided. The reconfiguration of the program code may include or change the program code. The reconfigured program code may also be the code of the software, in particular the source code of the software.

[0064] Figure 2 A computer system 20 is schematically shown in which the disclosed technique for obfuscating program code by means of a language model can be used to obfuscate program code. The computer system 20 is designed to: execute Figure 1 Method 10 and according to Figure 5 The computer system 20 may be implemented in hardware and / or software. Figure 2 The system shown in can be viewed as designed to perform Figure 1 Method 10 and according to Figure 5 A computer program of the method 50.

[0065] Source code or original program code 21 is provided to a language model 22, such as a Large Language Model (LLM), for obfuscation. Language model 22 generates (target) program code 23 as an obfuscation of original program code 21. This area of ​​computer system 20 may be referred to as a generation area.

[0066] The language model is, for example, a large language model (LLM), into which data (for example, program code in this case) are fed via input (prompt words) together with a question (for example, a confusing request in this case).

[0067] Another input 24 into the system 20 is the test and optionally the test tool. The input is fed to the test tool 25. The test tool 25 records the function or test in the target language.

[0068] Optionally, static tests, quality assessments and / or contracts 26 can be fed to a static testing unit 27 , where they are administered for subsequent checking of program code 23 .

[0069] The input of the dynamic deobfuscator 28 for targeted fuzz testing is connected to the language model 22 for inputting the obfuscated program code 23 and to the test tool 25 for inputting the test routine. In the dynamic deobfuscator 28, an attempt is made to obfuscate the obfuscated program code 23. In this process, the code traces and outputs of the obfuscated program code 23 are monitored. Figure 3 The dynamic deobfuscator 28 and its functionality are described in more detail.

[0070] The generation of program code 23 from the language model 22 can be repeated under changing conditions, such as changing one or more hyperparameters, such as temperature parameters of the language model, transformation of the original program code, and / or changes in the input to the language model, such as changes in tasks or prompt words. Variables can also be renamed in the code.

[0071] The measures described generate variants. The variants allow verification and improved quality assessment of the generated obfuscation and also allow training of the language model with the aid of feedback. Within the scope of the improved quality assessment, it can be determined which of the generated program codes 23 are better or worse suited. The dynamic deobfuscator 28 then works with the variants of the program code 23.

[0072] The input of the static complexity check 29 is connected to the language model 22 for inputting the obfuscated program code 23 and to the static test unit 27 for inputting the static test, quality assessment and / or contract 26. In the static complexity check 29, the program code 21 is subjected to a static complexity check with the aid of the static test, quality assessment and / or contract 26. Figure 3 The static complexity check 29 and its functionality are described in more detail.

[0073] If the checks in the dynamic deobfuscator 28 and in the static complexity check 29 are successfully completed, a status message 30 is output that the program code 23 is normal. This area of ​​the computer system 20 may be referred to as a check area.

[0074] The quality of the target program code 31 can be evaluated according to indicators 32. Indicators 32 can include code quality indicators, test quality indicators and / or test quantity. If the evaluation is successful, the program code and its quality or quality are output as output 33. The area of ​​the computer system 20 can be called a quality evaluation area.

[0075] Based on the evaluation, the quality can be calculated. If multiple target program codes have been generated, the solutions can be provided to the user in order of quality.

[0076] For example, evaluation of program code may be performed based on code quality metrics such as source code length, number of loops and / or branch depth, test quality metrics such as branch coverage and / or number of available or executable tests.

[0077] Figure 3 The dynamic deobfuscator 28 and the static complexity check 29 are shown in detail, as well as the test tool 25 , the static test unit 27 and the obfuscated program code 23 as inputs to the dynamic deobfuscator 28 and the static complexity check 29 .

[0078] The dynamic deobfuscator 28 includes a compiled or executable file 40 generated from the program code 23. In other words, the dynamic deobfuscator 28 or another element of the system generates an executable file 40 from the obfuscated program code 23. The dynamic deobfuscator 28 can, for example, be equipped with the generated code 23 for further processing. To this end, the dynamic deobfuscator 28 is connected to the test tool 25.

[0079] The monitoring unit 41 measures or monitors the dynamic deobfuscation of the code during runtime. The monitoring unit 41 can monitor code traces, collect program output and measure program behavior, such as runtime. This can then be stored in the monitoring unit 41. All of this is fed back to the deobfuscator 42 to produce better deobfuscation attempts.

[0080] The deobfuscator 42 attempts to deobfuscate the executable file 40, for example by accessing an oracle of the deobfuscator 42, such that the result of the deobfuscation always remains functionally correct for the obfuscated executable file 40. Additionally or alternatively, the deobfuscator 42 uses feedback from the monitoring unit 41 to improve the deobfuscation.

[0081] Static complexity check 29 comprises a memory 43 or a storage library with source code. For this reason, memory 43 is connected to the program code 23 that has been obfuscated. In addition, memory 43 is connected to static test unit 27 to convey static test, quality assessment and / or contract 26. The static test, quality assessment and / or contract are applied to the program code 23 that has been obfuscated, so that the complexity of the program code 23 that has been obfuscated and the obfuscation that is particularly performed by a language model are identified and evaluated. The inspection produces an index of code complexity, such as cyclomatic complexity, source code lines, executable code lines, coupling and / or inheritance depth, maintainability index, cognitive complexity, Halstead index (such as Halstead amount and / or rework rate). The index can be stored in static complexity check 29 to compare for subsequent improvements that are concealed.

[0082] Figure 4 A computer system 20 is schematically shown in which the techniques for obfuscating program code of the present disclosure may be used. The computer system 20 may correspond to Figure 2 The computer system 20 in the embodiment of the present invention is designed to: execute the Figure 1 Method 10 and according to Figure 5 The method 50, in particular, Figure 3 The computer system 20 is designed to execute according to Figure 5 The computer system 20 may be implemented in hardware and / or software. Figure 4 The system shown in can be considered as designed to perform Figure 1 Method 10 and according to Figure 5 The following blocks of the system 20 not discussed below correspond to Figure 2 The corresponding blocks in and have corresponding functions.

[0083] The error handling mechanism of the computer system 20 is Figure 4If the program code 31 cannot be generated without errors, this leads to errors in the dynamic deobfuscator 28 and / or the static complexity check 29 .

[0084] Accordingly, a message 34 is output to reduce the confidence level of the obfuscation. In addition, the errors and the associated program code 31 are stored in an error module 35. For this purpose, the error module 35 is connected to the dynamic deobfuscator 28 and the static complexity check 29. Such errors can be derived from the indicators or they correspond to the indicators.

[0085] From the error module 35, the best program code to date with errors and / or indicators that are still present is fed back to the language model 22 as information 36 in order to generate a better, ideally error-free target program code. This further iteration reduces the reliability and is taken into account in the quality determination.

[0086] Optionally, this may not only concern errors in the inspection area, but similarly also errors in the quality assessment area.

[0087] Figure 5 is a flow chart illustrating a method 50 for training a language model. The language model is designed for automatically obfuscating program code.

[0088] In summary, the code generated by the language model is fed back to the language model as feedback in order to generate a new generation of source code. The idea is that the already adapted (or better) code can then be fine-tuned in terms of code masking with the help of updated input requests containing new code. For example, if the good code has runtime problems only at specific locations, then said locations can be fed back into the language model.

[0089] In the first step of the method, an original program code or source code is generated 51. This can be done manually or by means of a language model. The language model can be pre-trained and, if necessary, can also be fine-tuned. Alternatively, it is also possible to start with a new, untrained language model. In this case, the training is based on reinforcement learning. The training is carried out in a training environment, for example, with the help of PPO (Proximal Policy Optimization).

[0090] In addition, the program code is obtained by Figure 1 The described method 10 performs obfuscation 52. The obfuscation is performed by means of a language model. The language model can be pre-trained and, if necessary, can also be fine-tuned. Alternatively, it is also possible to start with a new, untrained language model. In this case, the training is based on reinforcement learning. The training is performed in a training environment, for example, with the aid of PPO (Proximal Policy Optimization).

[0091] Then, a reward is generated 53 for the language model, wherein the reward is generated according to the (stored) indicator of the dynamic deobfuscation and / or the (stored) indicator of the code complexity. Thus, if the deobfuscation lasts only briefly and / or if the code complexity indicator is low, a low score evaluation is achieved. A low indicator of code complexity indicates a fairly simple and thus more easily circumvented obfuscation. Correspondingly, if the deobfuscation lasts for a long time or fails and / or if the code complexity indicator is high, a high score evaluation is achieved. A high indicator of code complexity indicates a fairly complex and thus more difficult to circumvent obfuscation.

[0092] Finally, the weights of the language model are updated 54 using the value of the reward. The result of this method is a language model that is better trained with new, unlabeled data (here, for example, C code from a motor controller), ie, provides more reliable confusion.

[0093] According to one embodiment, the method further comprises: approximating the reward by performing only one of the tests of the automated check. This allows for accelerated training.

Claims

1. A method (10) for obfuscating a program code (23) by means of a language model (22), the method comprising the following steps: - obfuscating (11) the program code (23) by means of a language model (22), - generating (12) an executable file (43) from the obfuscated program code (23), - dynamically deobfuscating (13) the executable file (43) until the deobfuscation (13) is completed or no new results are produced, - storing (14) indicators of the dynamic deobfuscation (13), - returning (15) indicators of the dynamic deobfuscation (13) and optionally the generated program code (23) to the language model (22) for further iteration of the obfuscation (11).

2. The method (10) according to claim 1 further comprises the following steps: - performing a static complexity check (29) on the obfuscated program code (23) until the execution (15) ends or produces no new results, - storing an indicator of the complexity of said code, - returning the indicator of code complexity and optionally the generated program code (23) to the language model (22) for further iteration of the obfuscation (11).

3. The method (10) according to claim 1 or 2, wherein indicators of the dynamic deobfuscation (12) and the generated program code (23) are stored.

4. The method (10) according to any one of claims 1 to 3, wherein after the dynamic deobfuscation (12) and performing (14) a static complexity check (14), the quality of the program code (23) is evaluated according to indicators (32), wherein the indicators (32) include code quality indicators, test quality indicators and / or test quantity.

5. The method (10) according to any one of claims 1 to 4, wherein the indicators of the dynamic deobfuscation (12) include deobfuscation runtime, code traces, program output and / or program behavior such as runtime.

6. The method (10) according to any one of claims 1 to 5, wherein the indicators of code complexity include cyclomatic complexity, number of source code lines, number of executable code lines, coupling and / or inheritance depth, maintainability index, cognitive complexity, Halstead indicators, such as Halstead amount and / or rework rate.

7. The method (10) according to any one of claims 1 to 6, wherein the obfuscation (11) inserts security features into the program code (23).

8. The method (10) according to any one of claims 1 to 7, wherein stored indicators of the dynamic deobfuscation (12) and / or stored indicators of the code complexity of different obfuscated program codes (23) are compared in order to determine the best obfuscated program code (23).

9. The method (10) according to any one of claims 1 to 8, wherein the dynamic deobfuscation (13) of the executable file (43) and the execution (15) of the static complexity check (29) of the program code (23) are performed in parallel.

10. A method (50) for training a language model (22) designed to obfuscate program code (23), the method comprising the following steps: - generating (51) a program code (23), - obfuscating (52) the program code (23) by means of a method (10) according to any one of claims 1 to 9, - generating (53) a reward for the language model (22), wherein the reward is generated according to a stored indicator of the dynamic deobfuscation indicator (12) and / or a stored indicator of the code complexity, - Updating (54) the weights of the language model using the value of the reward.

11. The method (50) of claim 10, wherein the reward is approximated by performing verification only once.

12. A computer system (20) designed to carry out the method (10; 50) according to any one of claims 1 to 11.

13. A computer program designed to carry out the method (10; 50) according to any one of claims 1 to 11.

14. A computer readable medium or signal storing and / or containing a computer program according to claim 13.

Images