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.