INDIVIDUAL ENCRYPTION OF CONTROL COMMANDS

Abstract

The present invention is directed to a method for efficiently and individually encrypting control commands, which makes it possible to encrypt supplied applications and to transmit them to an end device not only in an efficient but also in a particularly secure way.

Claims

1.-15. (canceled)

16. A method for efficiently and individually encrypting control commands for single end devices, comprising the steps of: supplying a set of control commands by means of a telecommunication network; identifying a subset of the control commands which supply a security-critical functionality; and encrypting merely the subset of control commands, wherein the encrypting is effected in dependence on an end device identifier.

17. The method according to claim 16, wherein encrypting is effected in dependence on the end device identifier of an end device which requests the set of control commands.

18. The method according to claim 16, wherein encrypting is effected in dependence on the end device identifier of an end device which supplies the set of control commands to a further end device.

19. The method according to claim 16, wherein encrypting is effected by means of obfuscating.

20. The method according to claim 16, wherein encrypting is effected in dependence on a random number.

21. The method according to claim 16, wherein at least the encrypted subset of control commands is provided with a signature.

22. The method according to claim 16, wherein the set of control commands comprising encrypted and unencrypted control commands is supplied to an end device by means of a telecommunication network.

23. The method according to claim 16, wherein identifying is effected in dependence on a textual marking.

24. The method according to claim 16, wherein identifying is effected in dependence on a memory structure of the control commands.

25. The method according to claim 16, wherein the set of control commands is present as source code.

26. The method according to claim 16, wherein the supplied control commands have parameters which are provided with values only upon request of an end device.

27. The method according to claim 16, wherein further control commands are provided which supply the set of control commands comprising encrypted and unencrypted control commands to an end device.

28. The method according to claim 27, wherein the further control commands add a signature to the set of control commands.

29. An encryption apparatus for efficiently and individually encrypting control commands for single end devices, comprising: an interface unit arranged to supply a set of control commands by means of a telecommunication network; an analyzing unit arranged to identify a subset of the control commands supplying a security-critical functionality; and an encryption unit arranged to encrypt merely the subset of control commands, wherein encrypting is effected in dependence on an end device identifier.

30. A computer program product having control commands which implement the method according to claim 16.

Description

[0040] The present invention will now be explained by means of exemplary figures. There are shown:

[0041] FIG. 1: a block diagram of an encryption arrangement according to one aspect of the present invention; and

[0042] FIG. 2: a method for individually encrypting control commands according to one aspect of the present invention.

[0043] FIG. 1 shows an arrangement in which a developer creates control commands and distributes these by means of a central server unit, for example an app store, to users who retrieve these control commands by means of their smartphones. If security-critical applications are distributed via such central distributors, an attacker can analyze the application and transmit the results of the analysis to all the users of the application. The attacker only needs to analyze the application once in order to attack all the users of the application.

[0044] For this, according to the invention, in the application, i.e. in the control commands, there can be stored information designating security-critical data by the developer. Only static parts of the applications are signed with a developer key. This is effected in a method step 1 as shown in FIG. 1.

[0045] Thereafter, in a further method step 2, a transmission of the application from the developer to the app store is effected. Thereupon, in method step 3, it is effected that upon a selection of the application in the app store it is checked by the customer which data are security-critical. The security-critical data are obfuscated individually for each customer and each device.

[0046] In a subsequent step 4, the dynamic parts of the application are signed with a key of the app store, and the signature is added to the developer's signature of point 1.

[0047] In method step 5, the application is then transmitted from the app store to the customer. In the following method step 6, the installer on the customer's smartphone checks the signature of the developer over static parts and the signature of the app store over the dynamic parts.

[0048] Thus, an attack on security-critical applications without secure element is made more difficult. Furthermore, the developer does not have to perform the obfuscation himself. The changes to the customer device therefore only affect the installer and are therefore minimal.

[0049] Obfuscation is understood to be the carrying out of a method by which a program or source code is put into a form that is difficult for humans to read or understand in order to make attacks or reverse engineering more difficult. However, the actual program still runs equivalent to the original program.

[0050] The term manifest refers to a metafile which includes (optional) descriptive properties of a program. This is present in various platforms, such as Windows or Java.

[0051] Security-critical parts in a program are all parts that contain keys or sensitive operations. This means that the calculation of the payment token based on the credit card data contains two security-critical aspects: credit card data and algorithmic calculations of the payment token.

[0052] Recognizing which parts are critical and which not is very difficult, as this is part of the application file or overall system.

[0053] Furthermore, obfuscating native code increases security compared to Java bitcode. Native code runs on the processor for a special architecture. This code is highly optimized, parallelized and machine-oriented, i.e. difficult to understand for a person. Java code is a so-called intermediate code for a virtual architecture. A virtual machine transforms the intermediate code into the actual machine language of the architecture. Since Java interprets the intermediate code, it is not possible to execute arbitrary obfuscations, otherwise the virtual machine cannot translate the code any more.

[0054] Static or dynamic parts of control commands can be defined, for example, as follows. Each application is static, i.e. the developer compiles the program and this is placed in the app store and downloaded by the end user statically, i.e. unchanged. Each user gets the same program. Dynamic means, however, that the app store may generate certain parts in the program, e.g. random numbers, RSA key pair, time/date, . . . , i.e. each user gets a different program.

[0055] If the control commands are static, the developer signs the application with his key and places it in the app store. This ensures that nothing was changed when the application was transferred. If parts of the application are dynamic and are only filled or generated by the app store when the end user downloads them, a signature cannot be calculated via the dynamic parts; this is effected by the app store instead. This signature of the app store is then appended to the entire application.

[0056] A static signature here is a signature over all parts of the application, code, images, strings, or the like, which are not changed after the compilation at the developer. A dynamic signature is a signature over all parts that have been created or generated in the app store user-specifically.

[0057] There are also cases in which the app store signs. This is up to the app store provider, whether or not this is provided. when applications contain dynamic segments, it may be necessary in order to trust this code or data regions.

[0058] According to the invention, it is particularly advantageous that the method steps cited in the prior art are extended according to the invention. At the outset, eight method steps have been described, via which standard app stores work. There is described the sequence from the developer up to the installation of the app on a device, i.e. smartphone, tablet, notebook, PC, of the end customer. These method steps are extended according to one aspect of the present invention, as follows.

Extension of step 1:

[0059] In the manifest file, the developer stores additional information that defines which of the executable files or code segments within the .apk-file are particularly security-critical. Preferably, the developer outsources the critical functions in separate executable files, so that the app and its runtime are not unnecessarily bloated by the obfuscation.

[0060] Preferably, the security-critical executable files are not present in Java bytecode, but in native code. This drastically increases the security of the obfuscation.

Extension of step 2:

[0061] Before the signature is generated, the manifest file of the .apk is checked to see whether an executable file in the .apk is marked as security-critical.

[0062] If this is the case, a signature is not calculated over the entire .apk, but merely over the still static parts. For apps without security-critical parts, the signature over the entire .apk is added, as usual.

Extension of step 6:

[0063] If the .apk does not have a complete signature, the manifest file of the .apk is checked to see which executable files are marked as security critical. These files are obfuscated individually per download, i.e. the .apk made available is obfuscated individually not only for each end customer, but also for every single device of the end customer. This additionally increases security. The necessary seed for carrying out the obfuscation is generated by means of a random number and discarded after the obfuscation because it is no longer needed.

[0064] Via the dynamized values within the APK, a signature is calculated with the key of the app store and this is added to the signature of the app developer. Subsequently, the .apk is transmitted to the end device of the end customer as usual.

Extension of step 7:

[0065] The installer on the end device examines the static signature of the developer as well as the optional signature of the app store on the dynamic content.

[0066] FIG. 2 shows a method for efficiently and individually encrypting control commands for single end devices. Provided are the steps of supplying 100 a set of control commands by means of a telecommunication network. Furthermore, there is effected an identifying 101 of a subset of the control commands which supply a security-critical functionality. In addition, there is effected an encrypting 102 of merely the subset of control commands, encrypting being effected in dependence on an end device identifier.

[0067] Not shown is a data carrier having a computer program product with control commands which implement the proposed method or operate the proposed apparatus.