WO2004098121A2 - Delivering a software component - Google Patents

Delivering a software component Download PDF

Info

Publication number
WO2004098121A2
WO2004098121A2 PCT/GB2004/001888 GB2004001888W WO2004098121A2 WO 2004098121 A2 WO2004098121 A2 WO 2004098121A2 GB 2004001888 W GB2004001888 W GB 2004001888W WO 2004098121 A2 WO2004098121 A2 WO 2004098121A2
Authority
WO
WIPO (PCT)
Prior art keywords
data
encryption
software component
software
encryptable
Prior art date
Application number
PCT/GB2004/001888
Other languages
French (fr)
Other versions
WO2004098121A3 (en
Inventor
John Aram Safa
Original Assignee
Bitarts Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bitarts Limited filed Critical Bitarts Limited
Publication of WO2004098121A2 publication Critical patent/WO2004098121A2/en
Publication of WO2004098121A3 publication Critical patent/WO2004098121A3/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12Protecting executable software
    • G06F21/121Restricting unauthorised execution of programs
    • G06F21/125Restricting unauthorised execution of programs by manipulating the program code, e.g. source code, compiled code, interpreted code, machine code

Definitions

  • the present invention relates to a method of delivering a software component, and to apparatus associated therewith.
  • Java Virtual Machine which is itself a software component resident on the relevant physical machine, in principle, any Java application can be executed on any JVM and is thus platform independent.
  • JVM Java Virtual Machine
  • Each JVM is not platform independent, being required to translate between the platform independent Java code, and the necessary instructions to execute the Java instruction on the local physical machine.
  • the platform independence has led to Java being widely used in networks to which many users gain access by means of a range of different equipment, such as the internet and wireless communication networks.
  • the present invention provides a method of delivering a software component in protected form to a wireless device, in which: the software component is analysed in bytecode form to identify encryptable data contained therein; an encryption routine is executed on the encryptable data to produce encrypted data; and the software component is modified to replace the encryptable data by the encrypted data, to include a decryption routine corresponding with the encryption routine and to include one or more instructions associated with encrypted data and operable during execution to call the decryption routine to decrypt the associated encrypted data.
  • the software component is analysed for encryption in response to each request received from a wireless device.
  • Multiple encryption routines may be used for different identified encryptable data items.
  • the or each encryption routine is selected from a library of routines.
  • selection is a random or pseudo-random process.
  • the analysis step may be based on rules which prevent encryption of some data which is otherwise encryptable.
  • the rules may identify methods within which encryption of data is to be prevented.
  • the decryption routine preferably requires a decryption key, and the modified software component identifies a source from which the key is available.
  • the key may be contained within the modified software, or be available from a remote location by communication over a network to which the mobile device is connected.
  • the remote location may be operable to execute a payment step before releasing a decryption key.
  • the software component is a Java ClassFile.
  • the encryptable data may consist of strings or numbers within the Java ClassFile.
  • the invention also provides software protected for delivery in accordance with the method set out above.
  • the invention also provides a carrier medium carrying software as aforesaid.
  • the carrier medium may be a recording medium.
  • the carrier medium may be a transmission medium, the software being carried by a signal propagating on the transmission medium.
  • the present invention also provides apparatus for delivering a software component in protected form to a wireless device, comprising: analysis means operable to analyse the software component in bytecode form to identify encryptable data contained therein; encryption means operable on the encryptable data to produce encrypted data; and modifying means operable to modify the software component to replace the encryptable data by the encrypted data, to include a decryption routine corresponding with the encryption routine and to include one or more instructions associated with encrypted data and operable during execution to call the decryption routine to decrypt the associated encrypted data.
  • the software component is analysed by the analysis means in response to each request received from a wireless device.
  • Multiple encryption routines may be available to the encryption means for use with different identified encryptable data items.
  • the or each encryption routine is selected from a library of routines. Preferably selection is a random or pseudo-random process.
  • the analysis means may operate in accordance with rules which prevent encryption of some data which is otherwise encryptable.
  • the rules may identify methods within which encryption of data is to be prevented.
  • the decryption routine preferably requires a decryption key, and the modified software component identifies a source from which the key is available.
  • the key may be contained within the modified software or be available from a remote location by communication over a network to which the mobile device is connected.
  • the remote location may be operable to execute a payment step before releasing a decryption key.
  • the software component is a Java ClassFile.
  • the encryptable data may consist of strings or numbers within the Java ClassFile.
  • the invention also provides computer software which, when installed on one or more computer systems, is operable to provide apparatus as defined above.
  • the invention also provides a carrier medium carrying software as aforesaid.
  • the carrier medium may be a data storage device.
  • the carrier medium may be a transmission medium, the software being carried by a signal propagating on the medium.
  • the invention further provides a system comprising apparatus as defined above, at least one wireless device, and a network by means of which the wireless device may communicate with the apparatus, the wireless device being operable to request a software component from the apparatus, and the apparatus being operable as aforesaid to deliver the software component in protected form by means of the network, for execution by the wireless device.
  • Fig. 1 is a schematic view of a wireless communication network with which the present invention may be used;
  • Fig. 2 is a simplified schematic diagram of relevant parts of a wireless device of the network of Fig. 1 ;
  • Fig. 3 is a schematic diagram of apparatus for use in conjunction with the network of Fig. 1 , for implementing the present invention
  • Fig. 4 is a flow diagram of operation of the apparatus of Fig. 3, to provide protection for a software component
  • FIGs. 5A and 5B are simple diagrams of memory containing a software component before and after protection in accordance with the present invention.
  • Fig. 6 is a flow diagram of execution of the protected software.
  • Fig. 1 illustrates a communication system 10 which includes wireless devices 12 and a wireless communication network 14, by means of which the devices 12 may communicate with each other and with apparatus 16, in accordance with the invention.
  • the wireless devices 12 incorporate a JVM and are able to request Java applications to be delivered from the apparatus 16 for execution on the devices 12. These applications may be games, for example.
  • the Java applications are provided in a protected form, so that they will execute on the device 12 for which they are intended, but are protected against execution after copying onto an alternative device.
  • Fig. 2 illustrates one of the devices 12, in more detail.
  • the device 12 is based around a processor 18.
  • Memory 20 is associated with the processor 18.
  • a bus 22 provides communication between the processor 18 and input/output systems 24 (particularly a radio transceiver for wireless communication with the network 14), and with user facilities such as a display 26 and user controls 28.
  • the memory 20 is divided into permanent memory 20A, containing an operating system 30 and a JVM 32, and temporary memory 20B which may contain a Java application 34 or another application 36.
  • a user may use the device 12 to request a Java application 34 to be obtained from the apparatus 16, for execution within the device 12.
  • the Java application 34 may be a game to be played on the device 12.
  • Fig. 3 schematically illustrates those components within the apparatus 16, which contribute to the performance of the invention.
  • the apparatus 16 is based around a processor 38 having temporary memory 40 and permanent memory 42.
  • the processor 38 communicates with the permanent memory 42 by means of a bus 44 which also allows communication with input output systems at 46, for communication with the network 14 at 48.
  • the permanent memory 42 contains at least one Java application 50 which can be requested by a device 12.
  • Memory 42 also includes at least one and preferably a library of encryption routines ENC1 , ENC2 etc., and corresponding decryption routines DEC1 , DEC2, etc.
  • a software component 56 is operable, when loaded into the temporary memory 40 for execution, to identify encryptable data within the application 50, as will be described, and may also include rules 58, the significance of which will be described below.
  • the permanent memory 42 also records one or more decryption keys at 60.
  • Fig. 3 illustrates the state of the temporary memory 40, after the Java application 50 (stored temporarily at 62) has been modified to a protected form 64 by means of encryption and decryption routines 66, 68 loaded from the libraries 52, 54.
  • the modification is achieved by execution of the identifying software 56, loaded for execution at 70, and under the control of the operating system 71.
  • the process begins at 72 with the receipt of a request for delivery of the application 50 to a particular device 12.
  • the memory 42 may contain a library of available Java applications 50, in which case, a request will identify the application required. Requests are received at 48, over the network 14.
  • the Java applications 50 are stored in bytecode (compiled) form.
  • the application 50 (or the application identified in the request) is copied to the temporary memory 40, at 62. This is step 74.
  • the identifying software 56 is loaded to the memory 40, for execution.
  • the application at 62 will have a form illustratively shown in Fig. 5A.
  • Fig. 5A shows a memory section 76 allocated to a Java ClassFile forming all or part of the application 50, and in Java bytecode.
  • the ClassFile will include one or more methods 78 illustrated in Fig. 5A as bounded by broken lines 80.
  • method 78A includes a string 82, which may be a name identifying another class to be called, a command to be written to the screen, or other alphanumeric content.
  • Method 78B includes a number 84 which may, for example, be an operand for an opcode of the method 78B.
  • the identifying software 70 begins to execute by identifying at 78 encryptable data within the class 52, such as the string 82 and the number 84.
  • the software 70 may find all such instances of encryptable data or may stop after a specified number of occurrences have been identified.
  • the software 70 may be further controlled by the rules 58 contained within it which may, for example, identify particular methods which are not to be operated on, by the software 70.
  • the rules 58 it is desirable for the rules 58, to bar operation on the main engine of a class 62 which is a game, to prevent the execution of the game being slowed down, but it is desirable for the rules 58 to encourage further treatment of methods which relate to the authorisation of the application for the user.
  • one or more encryption routines is loaded at 87 from the library 52, together with the or each corresponding decryption routine at 88, from the library 54.
  • the choice of encryption routine is preferably by a random or pseudo-random process.
  • Execution of the software 70 then continues by an encryption loop 89 controlled by a counter first set at 90.
  • the next identified encryptable data is encrypted by the or one of the encryption routines.
  • the count is then incremented at 92 and the loop re-executed if the maximum count has not yet been reached at 94.
  • the data encrypted at 96 is re-inserted at 97 into the class 62 to replace the original encryptable data by the encrypted data. This is illustrated schematically in Fig. 5B, for example by replacing the string 82 with XXX at the corresponding memory location.
  • step 98 inserts the decryption routine corresponding with the chosen encryption routine, unless already present within the class 62.
  • FIG. 5B illustrates decryption routines being added to the end of the class, at 100.
  • Each block of encrypted data is prefaced by a call instruction 102 also inserted at 98 and pointing to the decryption routine appropriate to the encrypted data. If the decryption routine 100 requires a decryption key, this is inserted, preferably at the beginning of the class 62, and with the call instruction 102 identifying the location of the appropriate key, in the event that more than one key is inserted in the region 106.
  • the region 106 contains an executable routine which obtains the relevant key from the apparatus 16, by means of the network 14, as will be described.
  • the class 62 in a form similar to that shown in Fig. 5B, is in protected form and ready for delivery to the device 12, over the network 14.
  • the software protected in accordance with the invention is propagated over the network 14 as a signal travelling from the apparatus 16 to the device 12.
  • the device 12 is preferably required to obtain a decryption key from the apparatus 16, as mentioned above.
  • This provides further control of the application 50 by allowing the apparatus 16 to conduct a payment routine, such as to charge the account of the user, to check credit worthiness etc., before releasing the key, without which the application 50 cannot be decrypted to run successfully.
  • the key (or the appropriate key) is released from the collection at 60.
  • Authorisation may also require the user or user device to be identified, so that if the application has been copied to a different device, for example to circumvent the payment requirements of the provider, this will be identified by the operation of the decryption key arrangement 60, and no decryption key will be released. This renders the application unusable on another device.
  • the arrangements described have the effect of further improving security, as follows. Since the encryption of data is achieved by analysing the application at bytecode level, i.e. after compiling ready for execution on a JVM, changes made by the encryption process have the effect of rendering the application unintelligible to a decompiler. That is to say, by choosing to encrypt a sufficient number of data items within the application, a decompiler ceases to be able to decompile the application to a form which is meaningful to a person seeking to identify and circumvent the security provisions. Moreover, wireless devices 12 are not usually provided with sufficient processing power to run decompiler programs, thus introducing a further step into the process by requiring the application to be loaded from the wireless device to a more powerful computing device. Thus, while it may remain theoretically possible to decompile the encrypted application, and then to modify it to disable the security features, it is envisaged by the inventors that the effort involved in doing this will be sufficient to significantly reduce the likelihood of unacceptable levels of illicitly copied applications being used.
  • Java and Java-related terms are trade marks of Sun Microsystems.
  • .NET is a trade mark of Microsoft Corporation.
  • SYMBIAN is a trade mark of Symbian Ltd.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Java applications are protected before they are delivered in response to a request (72). Encryptable data within the Java application is identified (86). Encryptable data may be, for example, strings or numbers, which can be modified without the Java class being corrupted and becoming unable to execute. Encryptable data is encrypted (96) and re-inserted (97) to replace the original encryptable data. Encryption routines may be taken from a library. Execution of the Java class, including the encrypted data, requires a decryption key which is not made available until appropriate security checks have been completed.

Description

Delivering a Software Component
The present invention relates to a method of delivering a software component, and to apparatus associated therewith.
The present invention arises from the recent success of the Java programming language. A Java application is written for execution by a Java Virtual Machine (JVM), which is itself a software component resident on the relevant physical machine, in principle, any Java application can be executed on any JVM and is thus platform independent. Each JVM is not platform independent, being required to translate between the platform independent Java code, and the necessary instructions to execute the Java instruction on the local physical machine. The platform independence has led to Java being widely used in networks to which many users gain access by means of a range of different equipment, such as the internet and wireless communication networks.
As the range of uses for wireless communication devices has increased, it has been proposed to provide each device with a JVM to allow the user to execute more complex tasks, such as playing games. However, the platform independence of Java applications presents a problem for potential suppliers of commercial Java applications, which can readily be copied from one wireless device to another, thus preventing the supplier from achieving the appropriate level of income from the application.
The present invention provides a method of delivering a software component in protected form to a wireless device, in which: the software component is analysed in bytecode form to identify encryptable data contained therein; an encryption routine is executed on the encryptable data to produce encrypted data; and the software component is modified to replace the encryptable data by the encrypted data, to include a decryption routine corresponding with the encryption routine and to include one or more instructions associated with encrypted data and operable during execution to call the decryption routine to decrypt the associated encrypted data.
Preferably the software component is analysed for encryption in response to each request received from a wireless device. Multiple encryption routines may be used for different identified encryptable data items. Preferably the or each encryption routine is selected from a library of routines. Preferably selection is a random or pseudo-random process.
The analysis step may be based on rules which prevent encryption of some data which is otherwise encryptable. The rules may identify methods within which encryption of data is to be prevented.
The decryption routine preferably requires a decryption key, and the modified software component identifies a source from which the key is available. The key may be contained within the modified software, or be available from a remote location by communication over a network to which the mobile device is connected. The remote location may be operable to execute a payment step before releasing a decryption key.
Preferably the software component is a Java ClassFile. The encryptable data may consist of strings or numbers within the Java ClassFile.
The invention also provides software protected for delivery in accordance with the method set out above. The invention also provides a carrier medium carrying software as aforesaid. The carrier medium may be a recording medium. Alternatively, the carrier medium may be a transmission medium, the software being carried by a signal propagating on the transmission medium.
The present invention also provides apparatus for delivering a software component in protected form to a wireless device, comprising: analysis means operable to analyse the software component in bytecode form to identify encryptable data contained therein; encryption means operable on the encryptable data to produce encrypted data; and modifying means operable to modify the software component to replace the encryptable data by the encrypted data, to include a decryption routine corresponding with the encryption routine and to include one or more instructions associated with encrypted data and operable during execution to call the decryption routine to decrypt the associated encrypted data.
Preferably the software component is analysed by the analysis means in response to each request received from a wireless device. Multiple encryption routines may be available to the encryption means for use with different identified encryptable data items. Preferably the or each encryption routine is selected from a library of routines. Preferably selection is a random or pseudo-random process.
The analysis means may operate in accordance with rules which prevent encryption of some data which is otherwise encryptable. The rules may identify methods within which encryption of data is to be prevented.
The decryption routine preferably requires a decryption key, and the modified software component identifies a source from which the key is available. The key may be contained within the modified software or be available from a remote location by communication over a network to which the mobile device is connected. The remote location may be operable to execute a payment step before releasing a decryption key.
Preferably the software component is a Java ClassFile. The encryptable data may consist of strings or numbers within the Java ClassFile.
The invention also provides computer software which, when installed on one or more computer systems, is operable to provide apparatus as defined above. The invention also provides a carrier medium carrying software as aforesaid. The carrier medium may be a data storage device. Alternatively, the carrier medium may be a transmission medium, the software being carried by a signal propagating on the medium.
The invention further provides a system comprising apparatus as defined above, at least one wireless device, and a network by means of which the wireless device may communicate with the apparatus, the wireless device being operable to request a software component from the apparatus, and the apparatus being operable as aforesaid to deliver the software component in protected form by means of the network, for execution by the wireless device.
Examples of the present invention will now be described in more detail, by way of example only, and with reference to the accompanying drawings, in which:
Fig. 1 is a schematic view of a wireless communication network with which the present invention may be used;
Fig. 2 is a simplified schematic diagram of relevant parts of a wireless device of the network of Fig. 1 ;
Fig. 3 is a schematic diagram of apparatus for use in conjunction with the network of Fig. 1 , for implementing the present invention;
Fig. 4 is a flow diagram of operation of the apparatus of Fig. 3, to provide protection for a software component;
Figs. 5A and 5B are simple diagrams of memory containing a software component before and after protection in accordance with the present invention; and
Fig. 6 is a flow diagram of execution of the protected software. Fig. 1 illustrates a communication system 10 which includes wireless devices 12 and a wireless communication network 14, by means of which the devices 12 may communicate with each other and with apparatus 16, in accordance with the invention. In particular, the wireless devices 12 (to be described more fully below) incorporate a JVM and are able to request Java applications to be delivered from the apparatus 16 for execution on the devices 12. These applications may be games, for example. In accordance with the invention, the Java applications are provided in a protected form, so that they will execute on the device 12 for which they are intended, but are protected against execution after copying onto an alternative device.
Fig. 2 illustrates one of the devices 12, in more detail. The device 12 is based around a processor 18. Memory 20 is associated with the processor 18. A bus 22 provides communication between the processor 18 and input/output systems 24 (particularly a radio transceiver for wireless communication with the network 14), and with user facilities such as a display 26 and user controls 28.
The memory 20 is divided into permanent memory 20A, containing an operating system 30 and a JVM 32, and temporary memory 20B which may contain a Java application 34 or another application 36. During use, a user may use the device 12 to request a Java application 34 to be obtained from the apparatus 16, for execution within the device 12. For example, the Java application 34 may be a game to be played on the device 12.
Fig. 3 schematically illustrates those components within the apparatus 16, which contribute to the performance of the invention.
The apparatus 16 is based around a processor 38 having temporary memory 40 and permanent memory 42. The processor 38 communicates with the permanent memory 42 by means of a bus 44 which also allows communication with input output systems at 46, for communication with the network 14 at 48. The permanent memory 42 contains at least one Java application 50 which can be requested by a device 12. Memory 42 also includes at least one and preferably a library of encryption routines ENC1 , ENC2 etc., and corresponding decryption routines DEC1 , DEC2, etc. A software component 56 is operable, when loaded into the temporary memory 40 for execution, to identify encryptable data within the application 50, as will be described, and may also include rules 58, the significance of which will be described below.
The permanent memory 42 also records one or more decryption keys at 60.
Fig. 3 illustrates the state of the temporary memory 40, after the Java application 50 (stored temporarily at 62) has been modified to a protected form 64 by means of encryption and decryption routines 66, 68 loaded from the libraries 52, 54. The modification is achieved by execution of the identifying software 56, loaded for execution at 70, and under the control of the operating system 71.
The operations executed by the apparatus 16 for delivering the application 50 in protected form, in accordance with the invention, may now be described by reference to Fig. 3 in conjunction with the flow diagram of Fig. 4, showing the steps involved.
The process begins at 72 with the receipt of a request for delivery of the application 50 to a particular device 12. Naturally, in a practical situation, the memory 42 may contain a library of available Java applications 50, in which case, a request will identify the application required. Requests are received at 48, over the network 14.
The Java applications 50 are stored in bytecode (compiled) form. The application 50 (or the application identified in the request) is copied to the temporary memory 40, at 62. This is step 74. At 76, the identifying software 56 is loaded to the memory 40, for execution. At this stage, the application at 62 will have a form illustratively shown in Fig. 5A. Fig. 5A shows a memory section 76 allocated to a Java ClassFile forming all or part of the application 50, and in Java bytecode. The ClassFile will include one or more methods 78 illustrated in Fig. 5A as bounded by broken lines 80. As illustrated, method 78A includes a string 82, which may be a name identifying another class to be called, a command to be written to the screen, or other alphanumeric content. Method 78B includes a number 84 which may, for example, be an operand for an opcode of the method 78B.
Data within a Java application 62, such as strings and numbers, can be modified without the class being identifiable as corrupt beyond execution. The identifying software 70 begins to execute by identifying at 78 encryptable data within the class 52, such as the string 82 and the number 84. The software 70 may find all such instances of encryptable data or may stop after a specified number of occurrences have been identified. The software 70 may be further controlled by the rules 58 contained within it which may, for example, identify particular methods which are not to be operated on, by the software 70. For example, it is desirable for the rules 58, to bar operation on the main engine of a class 62 which is a game, to prevent the execution of the game being slowed down, but it is desirable for the rules 58 to encourage further treatment of methods which relate to the authorisation of the application for the user.
Once the or each occurrence of encryptable data has been identified at 86, one or more encryption routines is loaded at 87 from the library 52, together with the or each corresponding decryption routine at 88, from the library 54. The choice of encryption routine is preferably by a random or pseudo-random process.
Execution of the software 70 then continues by an encryption loop 89 controlled by a counter first set at 90. On each execution of the loop 89, the next identified encryptable data is encrypted by the or one of the encryption routines. The count is then incremented at 92 and the loop re-executed if the maximum count has not yet been reached at 94. The data encrypted at 96 is re-inserted at 97 into the class 62 to replace the original encryptable data by the encrypted data. This is illustrated schematically in Fig. 5B, for example by replacing the string 82 with XXX at the corresponding memory location. In addition, step 98 inserts the decryption routine corresponding with the chosen encryption routine, unless already present within the class 62. Fig. 5B illustrates decryption routines being added to the end of the class, at 100. Each block of encrypted data is prefaced by a call instruction 102 also inserted at 98 and pointing to the decryption routine appropriate to the encrypted data. If the decryption routine 100 requires a decryption key, this is inserted, preferably at the beginning of the class 62, and with the call instruction 102 identifying the location of the appropriate key, in the event that more than one key is inserted in the region 106.
However, it is preferred that the region 106 contains an executable routine which obtains the relevant key from the apparatus 16, by means of the network 14, as will be described.
After the loop 88 has been completed the requisite number of times, the class 62, in a form similar to that shown in Fig. 5B, is in protected form and ready for delivery to the device 12, over the network 14. Thus, the software protected in accordance with the invention is propagated over the network 14 as a signal travelling from the apparatus 16 to the device 12.
When the class 62 is received by the device 12 and put into the temporary memory 20B for execution by the JVM 32, execution proceeds as shown simply in Fig. 6. Normal execution proceeds at 108 until the first call instruction 102 is encountered at 110. This calls the appropriate decryption routine 100 which is executed at 112 to decrypt the encrypted data. After decryption, normal execution continues at 114.
In order to decrypt, the device 12 is preferably required to obtain a decryption key from the apparatus 16, as mentioned above. This provides further control of the application 50 by allowing the apparatus 16 to conduct a payment routine, such as to charge the account of the user, to check credit worthiness etc., before releasing the key, without which the application 50 cannot be decrypted to run successfully. Subject to authorisation, the key (or the appropriate key) is released from the collection at 60. Authorisation may also require the user or user device to be identified, so that if the application has been copied to a different device, for example to circumvent the payment requirements of the provider, this will be identified by the operation of the decryption key arrangement 60, and no decryption key will be released. This renders the application unusable on another device.
Furthermore, the arrangements described have the effect of further improving security, as follows. Since the encryption of data is achieved by analysing the application at bytecode level, i.e. after compiling ready for execution on a JVM, changes made by the encryption process have the effect of rendering the application unintelligible to a decompiler. That is to say, by choosing to encrypt a sufficient number of data items within the application, a decompiler ceases to be able to decompile the application to a form which is meaningful to a person seeking to identify and circumvent the security provisions. Moreover, wireless devices 12 are not usually provided with sufficient processing power to run decompiler programs, thus introducing a further step into the process by requiring the application to be loaded from the wireless device to a more powerful computing device. Thus, while it may remain theoretically possible to decompile the encrypted application, and then to modify it to disable the security features, it is envisaged by the inventors that the effort involved in doing this will be sufficient to significantly reduce the likelihood of unacceptable levels of illicitly copied applications being used.
The description set out above has referred solely to the Java language. However, it will be apparent to the skilled reader that the invention can be implemented in a similar manner in other development languages targeted for wireless devices, such as .NET and SYMBIAN. Java and Java-related terms are trade marks of Sun Microsystems. .NET is a trade mark of Microsoft Corporation. SYMBIAN is a trade mark of Symbian Ltd.
Various modifications can be made to the arrangements described above, without departing from the scope of the present invention.
Whilst endeavouring in the foregoing specification to draw attention to those features of the invention believed to be of particular importance it should be understood that the Applicant claims protection in respect of any patentable feature or combination of features hereinbefore referred to and/or shown in the drawings whether or not particular emphasis has been placed thereon.

Claims

1. A method of delivering a software component in protected form to a wireless device, in which: the software component is analysed in bytecode form to identify encryptable data contained therein; an encryption routine is executed on the encryptable data to produce encrypted data; and the software component is modified to replace the encryptable data by the encrypted data, to include a decryption routine corresponding with the encryption routine and to include one or more instructions associated with encrypted data and operable during execution to call the decryption routine to decrypt the associated encrypted data.
2. A method according to claim 1 , wherein the software component is analysed for encryption in response to each request received from a wireless device.
3. A method according to claim 1 or 2, wherein multiple encryption routines are used for different identified encryptable data items.
4. A method according to any preceding claim, wherein the or each encryption routine is selected from a library of routines.
5. A method according to claim 4, wherein selection is a random or pseudo-random process.
6. A method according to any preceding claim, wherein the analysis step is based on rules which prevent encryption of some data which is otherwise encryptable.
7. A method according to claim 6, wherein the rules identify methods within which encryption of data is to be prevented.
8. A method according to any preceding claim, wherein the decryption routine requires a decryption key, and the modified software component identifies a source from which the key is available.
9. A method according to claim 8, wherein the key is contained within the modified software.
10. A method according to claim 8, wherein the key is available from a remote location by communication over a network to which the mobile device is connected.
11. A method according to claim 10, wherein the remote location is operable to execute a payment step before releasing a decryption key.
12. A method according to any preceding claim, wherein the software component is a Java ClassFile.
13. A method according to claim 12, wherein the encryptable data consists of strings or numbers within the Java ClassFile.
14. Software protected for delivery in accordance with the method set out in any of claims 1 to 13.
15. A carrier medium carrying software as defined in claim 14.
16. A carrier medium according to claim 15, the carrier medium being a recording medium.
17. A carrier medium according to claim 15, wherein the carrier medium is a transmission medium, the software being carried by a signal propagating on the transmission medium.
18. Apparatus for delivering a software component in protected form to a wireless device, comprising: analysis means operable to analyse the software component in bytecode form to identify encryptable data contained therein; encryption means operable on the encryptable data to produce encrypted data; and modifying means operable to modify the software component to replace the encryptable data by the encrypted data, to include a decryption routine corresponding with the encryption routine and to include one or more instructions associated with encrypted data and operable during execution to call the decryption routine to decrypt the associated encrypted data.
19. Apparatus according to claim 18, wherein the software component is ( analysed by the analysis means in response to each request received from a wireless device.
20. Apparatus according to claim 18 or 19, wherein multiple encryption routines are available to the encryption means for use with different identified encryptable data items.
21. Apparatus according to claim 18, 19 or 20, wherein the or each encryption routine is selected from a library of routines.
22. Apparatus according to claim 21 , wherein selection is a random or pseudo-random process.
23. Apparatus according to any of claims 18 to 22, wherein the analysis means operates in accordance with rules which prevent encryption of some data which is otherwise encryptable.
24. Apparatus according to claim 23, wherein the rules identify methods within which encryption of data is to be prevented.
25. Apparatus according to any of claims 18 to 24, wherein the decryption routine requires a decryption key, and the modified software component identifies a source from which the key is available.
26. Apparatus according to claim 25, wherein the key is contained within the modified software.
27. Apparatus according to claim 25, wherein the key is available from a remote location by communication over a network to which the mobile device is connected.
28. Apparatus according to claim 27, wherein the remote location is operable to execute a payment step before releasing a decryption key.
29. Apparatus according to any of claims 18 to 28, wherein the software component is a Java ClassFile.
30. Apparatus according to claim 29, wherein the encryptable data consists of strings or numbers within the Java ClassFile.
31. Computer software which, when installed on one or more computer systems, is operable to provide apparatus as defined in any of claims 18 to 30.
32. A carrier medium carrying software as defined in claim 31.
33. A carrier medium according to claim 32, wherein the carrier medium is a data storage device.
34. A carrier medium according to claim 32, wherein the carrier medium is a transmission medium, the software being carried by a signal propagating on the medium.
35. A system comprising apparatus as defined above, at least one wireless device, and a network by means of which the wireless device may communicate with the apparatus, the wireless device being operable to request a software component from the apparatus, and the apparatus being
; operable as aforesaid to deliver the software component in protected form by means of the network, for execution by the wireless device.
36. A method of delivering software, substantially as described above, with reference to the accompanying drawings.
37. Software protected for delivery in accordance with the method of claim 36.
38. Apparatus for delivering a software component, substantially as described above, with reference to the accompanying drawings.
39. Any novel subject matter or combination including novel subject matter disclosed herein, whether or not within the scope of or relating to the same invention as any of the preceding claims.
PCT/GB2004/001888 2003-05-02 2004-04-30 Delivering a software component WO2004098121A2 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB0310142A GB0310142D0 (en) 2003-05-02 2003-05-02 Delivering a software component
GB0310142.5 2003-05-02

Publications (2)

Publication Number Publication Date
WO2004098121A2 true WO2004098121A2 (en) 2004-11-11
WO2004098121A3 WO2004098121A3 (en) 2004-12-29

Family

ID=9957395

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2004/001888 WO2004098121A2 (en) 2003-05-02 2004-04-30 Delivering a software component

Country Status (2)

Country Link
GB (1) GB0310142D0 (en)
WO (1) WO2004098121A2 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109325343A (en) * 2018-09-17 2019-02-12 北京深思数盾科技股份有限公司 Java applet executes method and device

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999041651A2 (en) * 1998-02-13 1999-08-19 National Computer Board, Acting Through Its R & D Division, The Information Technology Institute Method for protecting bytecode
GB2343022A (en) * 1998-10-19 2000-04-26 Ibm Encrypting of Java methods
WO2002031648A2 (en) * 2000-10-11 2002-04-18 Sealedmedia Limited Methods of providing java tamperproofing

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999041651A2 (en) * 1998-02-13 1999-08-19 National Computer Board, Acting Through Its R & D Division, The Information Technology Institute Method for protecting bytecode
GB2343022A (en) * 1998-10-19 2000-04-26 Ibm Encrypting of Java methods
WO2002031648A2 (en) * 2000-10-11 2002-04-18 Sealedmedia Limited Methods of providing java tamperproofing

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ITANI W, KAYSSI A I: "J2ME end-to-end security for M-commerce" WCNC 2003 - IEEE WIRELESS COMMUNICATIONS AND NETWORKING CONFERENCE, vol. 3, 16 March 2003 (2003-03-16), - 20 March 2003 (2003-03-20) pages 2015-2020, XP010640078 NEW ORLEANS, LA, USA ISBN: 0-7803-7700-1 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109325343A (en) * 2018-09-17 2019-02-12 北京深思数盾科技股份有限公司 Java applet executes method and device
CN109325343B (en) * 2018-09-17 2021-08-10 北京深思数盾科技股份有限公司 Java program execution method and device

Also Published As

Publication number Publication date
WO2004098121A3 (en) 2004-12-29
GB0310142D0 (en) 2003-06-04

Similar Documents

Publication Publication Date Title
US8938727B2 (en) Method for preventing software reverse engineering, unauthorized modification, and runtime data interception
US7322045B2 (en) Method of obfuscating computer instruction streams
US7111285B2 (en) Method and system for protecting software applications against static and dynamic software piracy techniques
US10255414B2 (en) Software self-defense systems and methods
US8090959B2 (en) Method and apparatus for protecting .net programs
US6779114B1 (en) Tamper resistant software-control flow encoding
KR101143154B1 (en) A method and system for enforcing a security policy via a security virtual machine
TW476914B (en) Using a high level programming language with a microcontroller
US8185918B2 (en) Method and system for managing access to add-on data files
US20160364707A1 (en) Potentate: A Cryptography-Obfuscating, Self-Policing, Pervasive Distribution System For Digital Content
US20180129794A1 (en) Method for Protecting Dex File from Decompilation in Android System
US20070074050A1 (en) System and method for software and data copy protection
US7865961B2 (en) Computer system, central unit, and program execution method
Ruan et al. Survey of return‐oriented programming defense mechanisms
WO1999041651A2 (en) Method for protecting bytecode
WO2004098121A2 (en) Delivering a software component
EP1481306A2 (en) Protecting computer software
WO2004097603A1 (en) Protecting a java application
Fedler et al. ISA R: Improving Software Attack and Analysis Resilience via Compiler-Level Software Diversity
AU2010202883B2 (en) Systems and Methods for Preventing Unauthorized Use of Digital Content
Aelterman Exploitation of synergies between software protections
Mundle Java byte code obfuscator

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DPEN Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed from 20040101)
122 Ep: pct application non-entry in european phase