« PreviousContinue »
INSTALLATION OF SOFTWARE ON REMOVABLE
CROSS REFERENCE TO RELATED
 This application claims the priority of PCT/ GB2005/001652 filed on Apr. 29, 2005, and, GB 0409633.5 filed on Apr. 29, 2004, the entire contents of which are hereby incorporated in total by reference.
 The present invention relates to a method of installing software, and in particular to a method of installing software on removable media.
 In the context of the present invention, the term computing device shall be construed to cover any form of electrical device and includes, data recording devices, such as digital still and movie cameras of any form factor, computers of any type or form, including hand held and personal computers, and communication devices of any form factor, including mobile phones, smart phones, communicators which combine communications, image recording and/or playback, and computing functionality within a single device, and other forms of wireless and wired information devices.
 It has become common practice in computing device operating systems for software installation to be handled through specific installation packages. Originally, these packages were simple file archives which used standard archival compression formats such as .zip or .tar, but they have grown much more sophisticated over time. Among the advantages that these packages now offer are:
 transparent decompression of compressed files on installation
 guarantees that files are installed in correct locations in the computing device
 checking of system requirements including software version and modules dependencies
 authentication and verification of the integrity of the software and the identity of the software producer
 Commonly used examples of systems for installing software packages include:
 For Windows, Microsoft's proprietary operating system, together with third party solutions such as Wise (http://www.wise.com) and InstallShield (http://www.installshield.com); although this latter package is now multi-platform.
 Various Linux distributions use package systems such as rpm (http://www.rpm.org) originally from Red Hat, and the dkpg and deb system (http://www.debian.org/doc/debian-policy/ch-binary.html) developed by Debian.
 Symbian OS operating system .sis files developed by Symbian Software Limited (http://www.symbian.com/developer/techlibly70docs/SDL_v7.0/doc_source/ToolsA ndUtilities/Installing-ref/ MakesisToolReference.guide.html)
 Java systems use jar Java archive files (http:// java.sun.com/docs/books/tutorial/postl .0/whatsnew/ jar.html), while J2ME midlets additionally use jad java
application description files (http://java.sun.com/j2me/
 All of the above installation packages allow for the inclusion of both files to be installed and also of the essential metadata relating to any or all of their size, target location, versioning, dependencies, certification and authentication.
 The above packages integrate the software delivery mechanism and the software installation mechanism with the software authentication mechanism. Though the reasons for this are largely historical, in that package systems started off as delivery mechanisms which then integrated more functionality (firstly installation and then authentication), there are no real problems in combining these three areas of functionality in situations where computing resources are plentiful. The most typical instance of this is the provision of software packages for desktop personal computers on CD ROM, where the amount of persistent internal memory storage (such as that on hard disk) is usually not an issue, mains power is effectively inexhaustible, and the cost of the CDs themselves is negligible.
 However, certain classes of computing devices are resource constrained and are generally operated in more pressured and cost-conscious resource environments. This class of devices includes personal digital assistants (PDAs) and mobile telephones using cellular wireless technology. These mobile computing devices have a more limited CPU bandwidth, generally run on battery power rather than mains power, and have relatively limited amounts of internal memory, in comparison to PC devices. Furthermore, the costs of the removable storage media used by these resource constrained devices, such as Multi Media Cards (MMC), compact flash (CF) cards and Memory Sticks, are quite unlike CD ROMs in that they are sufficiently expensive for users to limit their consumption on the grounds of cost.
 For software products of any size, distribution of software using standard PC package mechanisms is regarded as unsuitable for these resource constrained devices because whatever compression and decompression mechanisms are used in the package, it is likely that there will be some point at which both compressed and uncompressed versions of the same files will need to be present on the computing device at the same time. Furthermore, these mobile devices are unlike PCs in that they lack hard disk drive storage, having only internal RAM and 'flash' disks available. It is not unusual to find that the removable media memory on a mobile phone has a far bigger storage capacity than the internal device memory, in which case there is clearly no point in providing software on removable media in a compressed format in the first place.
 Simply providing the software pre-installed on removable media is not a good solution to this problem, because the user of the software really needs to follow an installation process in order to ensure that the software to be installed is authentic, and has not been tampered with or infected by a virus in such a way as to compromise either the security of the user's data or the operation of the device. For these mobile computing devices in particular, the security of user data is of paramount importance because the data, if acquired, could be used, in essence, to steal the user's money.
 The resource constraints of these mobile devices are also problematical to alternative methods of distributing
software, specifically software delivery over the internet. While fixed PCs can utilise broadband internet connections where high bandwidth with zero marginal cost makes download speeds fast and virtually free, the cellular-based internet connections used by wireless devices are at least an order of magnitude slower, are not always reliable, and are perceived by many users as being relatively expensive. Although techniques such as decompressing data 'on the fly' while it is being received can help to avoid some of the memory constraints mentioned above, the inconvenience and perceived cost involved with on-line software delivery renders this method impractical for software installations of any significant size.
 The only current method of delivering software for resource constrained devices with wireless connections, such as PDAs and mobile phones, which does not involve the inconvenience and costs outlined above is via a PC connectivity suite. This is a class of software which runs on a non-mobile PC but which is normally provided with the mobile device and allows software to be installed safely cheaply and conveniently on the device while it is connected to the PC. There are however numerous disadvantages for this method of software delivery. The most obvious of these are
 The owner of the mobile device requires access to a compatible PC, which is not necessarily the case.
 Owners of PCs can find that the connectivity software provided with a mobile device is not compatible with their personal computer.
 Software cannot be installed while the mobile device is actually mobile, but requires a fixed location.
 Thus, there is currently no satisfactory method of installing software on resource constrained mobile devices which combines the requirements of convenience, efficiency, reliability, speed and security.
 It is therefore an object of the present invention to provide an improved method for installing software onto a computing device.
 According to a first aspect of the present invention there is provided a method of installing software on a computing device, the method comprising a decision phase for deciding whether or not to install the software and an installation phase for installing the software, and in which information required by the decision phase comprises metadata having an integrity protected by digital signature and including a respective hash for files to be installed for verifying the integrity of the file data.
 According to a second aspect of the present invention there is a provided a computing device arranged to operate in accordance with a method of the first aspect.
 According to a third aspect of the present invention there is provided a computer software package for installing software on a computing device for causing the computing device to operate in accordance with a method according to the first aspect.
 An embodiment of the present invention will now be described, by way of further example only, with reference to the accompanying drawings, in which:—
 FIG. 1 illustrates schematically a software installation process in which the installation process and the installation file have each been split into two independent phases;
 FIG. 2 illustrates schematically a software installation file format in which new signature and certificate chains have been inserted at the end of metadata information in the file;
 FIG. 3 illustrates schematically a method of inserting one software installation file into another;
 FIG. 4 illustrates schematically a software installation file format designed to support signing using multiple certificate chains, with multiple signatures supported for each chain; and
 FIG. 5 illustrates schematically a software installation file having one data file embedded in another.
 This invention is predicated on the perception that when software is delivered on removable media for use with wireless devices, it makes more sense to provide software uncompressed and with files already placed in the correct location, together with a package system capable of providing the functionality for ensuring secure operation of the software. Specifically, with the present invention it is possible to check both system requirements and dependencies, and also to authenticate and verify the integrity of the software and the identity of the software developer, without having to decompress and install all the files contained in the package.
 A preferred embodiment of the present invention is described below with reference to SIS files for the Symbian OSTM operating system available from Symbian Software Limited of London, England, which includes a software install package. However, it is stressed that the method of the present invention can be used to equal advantage with other forms of software install packages, whether these are stand alone type packages or incorporated into other types of operating systems.
 Symbian SIS files of the Symbian OSTM operating system have historically been used to package any number or type of files for installation on a mobile computing device running this operating system. This operating system is provided with a utility software program known as 'makesis', which is responsible for the generation of SIS files, a separate software install program (referred to herein as software install) being used to perform the actual software installation. In the example described below the format of these SIS files and the installation procedure have been modified in order to implement the invention. This new format is referred to in the example below as SISX (extended SIS).
 With the present invention, the installation process and the installation file have each been split into two independent phases. The installation process phases are referred to as the Decision Phase and the Installation Phase. To support each phase, the SISX file is provided as two parts: a SISSignedController part and a SISData part, as shown in FIG. 1.
 The SISSignedController is the only part needed to complete the Decision Phase. This is a relatively small part of the SISX file (typically <10 kb) so that it can be read
entirely in memory. This part contains metadata needed to install the required software files on the computing device, such as authentication, capability; and so on. However, with the present invention, the metadata is arranged also to contain a respective hash for each file in the SISData part, and must be digitally signed using a standard certificate, such as a certificate conforming to the X.509 v.3 public key infrastructure, which is verifiable either at install time or at run time.
 The SISData part contains all the data that is not required in the Decision Phase. This mainly consists of the actual files to be installed on the computing device, together a very limited amount of control information.
 There are two very significant key commercial advantages of this format:
 a) When installing files onto a mobile smart phone 'over the air', the relatively small SlSSignedController part can be downloaded first and the decision phase can, therefore, proceed almost immediately. Should any failures occur during this phase, the user is saved the significantly extra time and expense associated with downloading the entire installation file because the relatively time consuming and therefore more costly installation phase only proceeds after the decision phase has been completed successfully.
 b) For data that comes on MMC cards and does not need to be installed, only the SISSignedController part need be provided on the card with the pre-installed software, enabling standard authentication and other security measures to proceed as normal even though the normal installation process is unnecessary.
 The first of these advantages is shared by the Java package system, in which JAD files contain the metadata for the decision phase of an installation and JAR files contain the remainder of the package data. In common with the SISX files of the present invention, software delivered using the Java JAD/JAR package system needs to download only the JAD file to know whether or not the software can safely be installed. However, in strict contrast to the present invention, with the Java system, the hashes which are needed to ensure the integrity of the software files to be installed are included with the content in the JAR file. Therefore, unlike the present invention, it is not possible with the Java JAD/JAR package system to ensure the authenticity of software for installation which is provided on removable media by providing a JAD file with pre-installed software.
 The SISX file format will now be described with reference to a device running the Symbian OSTM operating system. It will of course be readily apparent to one skilled in the art that many other implementations are possible, and it will also be apparent which parts of the description are not essential to the implementation of the invention. For example, the SISX file format in the embodiment described specifies that all metadata should be stored in little-endian format, but this is done for convenience and there is no reason why either a big-endian or an agnostic-endian implementation of the invention may be provided. Similarly, the fact that the SISX format specifies CRC-32 checks for verifying integrity does not exclude other methods of achieving the same result.
 The information in the SISX file is split into two separate parts. The first part is the metadata, describing the files that need to be installed. The second part of the SISX file contains all the actual file data. This enables software installation to be split into the decision and installation phases referred to above. During the decision phase, the SISX file is examined and security checks are carried out in order to verify the install. The installation phase is only carried out if the verification is successful and is the process of actually copying the required files to the device.
 The SISX file format supports signatures and certificates to enable a package to be signed. These signatures are verified during installation, and can also be re-verified after the package is installed on the device. In order to support the processing of the SISX file in two phases, only the metadata of the SISX file is signed. However, with the present invention, the metadata also contains a respective hash for each file in the package for installation, in order to ensure the integrity of the data in each such file. In this manner, the integrity of the entire SISX file is protected by the signed metadata. This means that during the installation phase, the software install process can verify for each file being installed, the respective hash for each file against the 'protected' hash included in the signed metadata, whilst using an untrusted component to perform installation decompression.
 Separate checksums for each of the metadata and the file data may also be present in the SISX file to enable any possible corrupt SISX files to be detected at the beginning of the installation process.
 Due to the effort involved in changing file formats, the SISX format is designed to be extensible, and uses a type-length-value format. Each field in the SISX file (SISField) has a specified length. Thus, when reading a SISX file the fields whose types are unknown can be skipped.
 In common with other types of installation packages, the compression scheme used in the SIS file format of the Symbian OSTM operating system is to compress the whole SIS file, and at install time decompress to a separate file and install from that decompressed file. This can be wasteful, especially in the case where large files can be installed as an option, since there needs to be space left in the memory in the device in order to decompress the whole of the original SIS package, including the optional files. The SISX file format of the present invention supports the separate compression of each of the files in the SISX file, and the SISController can also be compressed. This reduces the memory space needed to carry out file installation. Compression is supported by using a SISCompressed SISField which can contain another integral compressed SISField.
 In this embodiment of the present invention the SISX file format is designed to support almost all of the original features of the SIS file format. The only limitation imposed is that there should be no more than 8 levels of embedded SISX files. It is to be understood that this is not a limitation of the SISX file format itself but is one which has been imposed to limit the overall complexity of the install process.
 Since the SISX file format has no offsets which need to be changed it is easy to add a new signature and