GB2355819A - Authentication of data and software - Google Patents

Abstract

The invention provides a method of authenticating software and data in a computer network comprising a number of devices and servers (12, 18, 20) mutually communicating through a communication system. To improve security of the network, private keys and corresponding public keys are used, the public keys for decoding data and software encoded by corresponding private keys, thereby authenticating the data and software and distinguishing it from corrupt data and software provided by a hostile attacker. On initial supply of the device (12) by a supplying party to an operator of the network, the device (12) includes operating software (130) capable of interpreting security policy change instructions for revoking and substituting public keys initially programmed into the device (12), the instructions capable of being authenticated using public keys present in the device (12) prior to their revocation and substitution. Key revocation and substitution prevents the network from accepting software and data subsequently loaded thereinto by the supplying party if it becomes hostile. Alternatively, it relieves the party of suspicion if the network is subsequently disrupted by the hostile attacker.

Description

2355819 IMTHOD OF DATA AND SOFTWARE AUTHENTICATION The present invention

relates to a method of data and software authentication, in particular, but not exclusively, to a method of data and software authentication in a computer network. The invention also relates to a network operating according to the method.

A conventional computer network comprises a number of hardware devices, for example computers and associated devices such as printers and file servers, linked together by a conununication system. The system may, for example, comprise optical fibre communication channels and telephone lines. Such a network is potentially vulnerable to attack from hostile parties attempting to gain access thereto. Reasons for attacking the network include an intention to cause disruption, to eavesdrop or to gain unpaid access to facilities available on the network, for example access to databases.

One simple conventional approach to resist attack from hostile parties is for supplying parties to provide only hardware to an operator responsible for a network. The operator can install his own software onto the hardware, the software being unfamiliar to both the supplying parties and the hostile parties. As a result of this unfamiliarity, the supplying parties and the hostile parties are thereby hindered from attacking the network.

However, this approach is unsatisfactory where the supplying parties not only provide hardware to the network operator but also associated software for operating the hardware.

Contemporary computers and other network devices are frequently of such a complex nature that the operator must rely upon the supplying parties to supply software for operating their proprietary hardware. The simple approach described above is even more unsatisfactory where one supplying party supplies hardware to the network operator and a number of other supplying parties provide corresponding software and parameterising data for operating the hardware. There is a risk that defective software supplied by hostile parties becomes unintentionally loaded into the hardware thereby compromising its security and reliability.

A more elaborate conventional approach to improving security of the network is for each supplying party to generate a pair of complementary codes referred to as "keys". The codes are such that one code of the pair cannot reasonably be generated merely from knowledge of the other code of the pair. When each supplying party supplies software and associated data to the network operator, the supplying party "signs" the software and data using one of its keys, the supplying party retaining this key secret as its "private key" which it does not divulge it to the network operator. However, the supplying party divulges the other of its keys of the pair to the network operator, this being known as the supplying party's "public key". Thus, public keys provided by the supplying parties can be used by the network operator for verifying authenticity of software signed by private keys belonging to the supplying parties.

Generation of private and public keys is kriown from a US patent number 4 200 770 which is hereby incorporated by reference with regard to the generation of complementary keys.

The private and public keys are usually of about 200 bytes in length and can be generated using a mathematical transformation described in the US patent.

Conventional "signing" of software and data by using private keys will now be described in farther detail.

In a first approach, "signing" involves encoding software and data in its entirety using a private key to generate corresponding encoded software and data. The encoded software and data can be decoded using a corresponding public key to the private key. Other unrelated public keys will not be able to successfully decode the encoded software and hardware to generate viable software and data for use in the network. If the network operator discovers such unviable software and data when decoding, the operator will thereby determine that the software and data is not authentic and should not be loaded onto the network.

In a second approach, "signing" involves calculating a parity checksum. for software and data using a checksum. generation program known to both supplying parties and the network operator; known proprietary checksum generating programs include 'Message Digest 5" (MD5) and "Secure Hash Algoridud' (SHA). The checksum is relatively short, usually in a range of 30 to 40 bytes in length. Each supplying party can use its private key for encoding a checksurn generated using a public checksurn generation program for its software and data and then supply the software and data unencoded together the encoded checksum, sometimes referred to as a Method Authentication Code (MAC), to th6 network operator. When the network operator receives the software and data from the supplying party, the operator can apply the public checksurn generation program to generate an operator checksurn for the unencoded software and data. The operator can then decode the encoded checksurn provided by the supplying party using the supplying party's public key to generate a decoded cbecksurn which the operator then compares with its operator checksum If the decoded checksurn is identical to the operator checksum, the network operator will thereby have determined that the software and data are authentic. If the decoded checksum and the operator checksum are not identical, the network operator will have identified that the software and data are suspect.

The second approach to "signing" software and data is faster and involves less computation than the first approach because checksum generation is a computationally quick operation to perform and encoding a checksum of 30 to 40 bytes is easier than encoding software and data in its entirety which can be, for example, several tens of Megabytes in size. 10 When the term "signing" is used by the inventors to describe their invention, this is intended to refer to either signing by the first approach or signing according to the second approach as described above. 15 A hostile party attenipting to supply suspect software and data to the network operator will not have access to the private keys of bona fide supplying parties. The network operator will be able to detect that the suspect software and data are unauthentic because none of its public keys will be capable of authenticating the suspect software and data. This iniproves security of the network by preventing suspect software nmuipulating operation 20 of the network in favour of a hostile party supplying the suspect software.

The more elaborate approach described above suffers a number of problems which can compromise security of the network.

A first problem arises when a supplying party supplies software and data to the network operator together with a public key for authenticating the software and data. The supplying party subsequently changes to become hostile but the network operator becomes immediately aware of this change. Such a change can arise, for example, by an employee of the supplying party deciding to cause malicious damage to his employer's interests. The network operator will need to take action to prevent the hostile supplying party from being able to load software and data onto the network which could compromise the network or cause damage thereto.

A second problem arises when a hostile party succeeds in obtaining illegally a private key from a bona fide supplying party and the network operator becomes inunediately aware that security has been compromised by divulgation of the private key. The bona fide party wants to be free from suspicion and blame if the hostile party attempts to load software and data onto the network which wreaks costly damage to the network, for example corrupting a database of crucial financial records.

is These problems are ftirther complicated when new hardware is being added to an existing network and later upgrades of corresponding software from a number of suppliers are being installed onto the network.

The inventors have appreciated that conventional simple approaches to ensuring network security using complement ary private and public keys are inadequate for addressing the problems described above because they do not provide a mechanism for updating public keys in the network for use in authenticating signed software and data. Thus, the inventors have devised a method of data and software authentication which addresses the aforesaid problems.

According to a first aspect of the present invention, there is provided a method of data and software authentication in a network incorporating at least one device provided with at least one associated present security key for use in verifying data and software authenticity thereat, and key rnodifing means for issuing instructions to the at least one device for revoking its associated at least one present key and substituting it with at least one corresponding alternative security key, the method including the steps of- (a) receiving instructions from the modifing means at the at least one device interpretable thereat for revoking its at least one present key and substituting it with at least one corresponding alternative key, the instructions being authenticable using one or more of the at least one present key; and (b) designating the at least one alternative key as included in -the at least one present key for authenticating software and data and repeating step (a) as appropriate for ensuring network security. 15 The invention provides the advantage that an operator of the network is capable of revoking earlier keys and replacing them with later keys using the earlier keys to authenticate revocation, thereby inTroving network security.

Advantageously in the method, each device is operable to authenticate signed software and data loaded thereinto using its at least one present security key. Such authentication reduces an opportunity for a hostile party to download corrupted or suspect software and associated parameterising data into the device. Headers in the signed software and data are preferably included for identifying keys that can be used for authenticating the 25 software and data.

Beneficially to irnprove security, complementary private and public key pairs are used in the method. Thus, preferably, the at least one security key and at least one alternative key are public keys, the public keys having associated therewith corresponding private security keys, each public key having a complementary private key, each private key substantially incapable of being derived merely from knowledge of its corresponding public key, the data and software in the network signable using one or more private key and authenticable at the at least one device using one or more corresponding public key. Use of private and public keys enables suppliers to sign their software and data using private keys, and for the at least one device in the network to verify authenticity of the software and data and decode them using corresponding public keys.

Preferably in the method, a subset of the at least one present key in each device is reserved for authenticating key revocation and substitution instructions only. 'Me subset is not used for authenticating network software and data loaded into the device for execution therein.

Such a subset, referred to as 'master keys" in the following description, is capable of improving network security because its one or more keys are used infrequently on account of being reserved solely for authenticating key revocation and substitution instructions.

1 Conveniently, the instructions to revoke and substitute the at least one present key in the at least one device are issued from a file server included in the network, the file server operable to issue the instructions at initial boot-up of the at least one device. As a consequence, key change can be implemented promptly when new devices are connected to the network, thereby giving hostile parties less opportunity to interfere with the at least one devices.

Preferably, the method is adapted such that a supplier of each device installs associated at least one present key thereinto prior to delivery of the device for incorporation into the network, and also supplies corresponding instructions for inclusion in the rnodig means for revoking and substituting the at least one present key with at least one corresponding alternative key supplied by an operator of the network to the supplier for use in generating the instructions. Supplying each device with an associated at least one present key and instructions for its revocation and substitution with corresponding at least one alternative key provides the advantage that the network operator after revocation and substitution can sign software and data which the at least one device is capable of accepting, the supplier being relieved of suspicion if corrupt software becomes loaded and executed on the network.

Advantageously, the supplier is provided with at least one public key from the operator for generating the instructions, the supplier encoding the instructions using a private key generated by the supplier, the private key having a corresponding public key included by the supplier in the at least one device prior to delivery thereof for inclusion in the network. Such use of private and public keys provides the advantage that the operator can load the instructions into the moditing means so that the operator's public key is substituted into the at least one device thereby allowing software and data signed by th operator's private key to be executed on the at least one device.

Conveniently in the method, initial keys supplied in the at least one device when initially included in the network are stored in non-volatile memory, and subsequently substituted corresponding alternative keys are stored in volatile memory, the at least one device capable of reverting back to initial keys in an event of the at least one device being powered down and subsequently powered up agairL Such operation provides the advantage that the at least one device need not to be returned to its supplier in an event of an erroneous key substitution being made.

In a second aspect, the invention provides a broadcast network operable according to a method of the first aspect of the invention. In a third aspect, the invention provides a computer network operable according to a method of the first aspect of the invention. 10 In a fourth aspect, the invention provides a multiple application smart card operable according to a method of the first aspect of the invention. Embodiments of the invention will now be described with reference to the following 15 diagrams in which:

Figure 1 is a schematic diagram of a prior art computer network;

Figure 2 is a diagram illustrating software and data exchange in the computer network in Figure I operating to a inethod according to the invention; and Figure 3 is an illustration of TFTP file structures including headers for interpretation according to the method of the invention.

Referring now to Figure 1, there is a shown a prior art computer network indicated by 10.

The network 10 comprises a first network device 12, a second network device 14, a communication system 16, a boot file server 18 and a TFIT file server 20; TFTP is an abbreviation for "Trivial File Transfer Protocol." The devices 12, 14 and the servers 18, are mutually linked through the system 16 which comprises a mesh of communication channels linking the network 10 together. Other devices and servers (not shown) are also connected to the system 16; connection to them is indicated by dotted lines from the system 16.

The first device 12 incorporates non-volatile read only memory, for example in the form of fusible ROM or EPROM, which is programmed by its supplying party at manufacturer to include simple operating software and one or more public keys. The device 12 also incorporates volatile random access memory (RAM) into which programs and data for execution in the device 12 can be downloaded through the communication system 16.

Operation of the prior art network 10 when the first device 12 is booted up will now be described with reference to Figure 1. Initially, the network 10 is active and the first device 12 is then powered up. The first device 12 initializes itself from its operating software contained within its non-volatile memory. The operating software causes the device 12 to emit a "boot-me" request and an identification code indicative of the device 12 type onto the system 16. The request is subsequently received by the boot server 18 which recognises the identification code. The boot server 18 then sends a response onto the system 16 w1fich the device 12 subsequently receives, the response providing the address of the TFI? file server 20 which can supply the device 12 with network operating software and associated parameterising data. The device 12 then proceeds to download the network software and data from the TFrP server 20 into its volatile memory. The -to- network software and data are provided to the device 12 in packets of digits. Finally, the device 12 proceeds to authenticate the network software and data as being bona fide using its public key. If the software and data are found by the device 12 to be corrupted, the device 12 requests retransmission of packets from the TF17P server 20, or, alternatively, re-boots itself. If the software and data are authentic with regard to the one or more public keys, the device 12 proceeds to execute the network software and thereby becomes a participating device in the network 10.

Network software is provided from the TFI? server 20 so that software upgrades can be more easily entered into the network 10; in practice, many devices in the network 10 can access the WIT and boot servers 18, 20 hence it is more efficient to upgrade the software at these servers 18, 20 rather than at each individual device connected to the network 10.

In the network 10, servers and devices connected thereto can be geographically widely separated, for example in different countries or continents, hence data transmission errors can occasionally arise in practice, especially when the communication system uses error prone commercial telephone lines for example.

A hostile device 22 can interrupt operation of the device 12 in a nurnber of ways. In a first way, when the device 12 emits its "boot-me" request, the hostile device 22 can bombard the device 12 with fake boot server responses before the boot server 18 has an opportunity to respond. The fake responses may, for example, instruct the device 12 to seek its network software from another server connected to the system 16 other than the server 20. In a second way, when the device 12 is receiving data in packets from the WIT server 20, the hostile device 22 can present packets of software just prior to the server 20 such that the device 12 is fooled into receiving software from the hostile device 22 and ignoring at least part of that provided from the server 20. It is part of permitted TT7P protocol that duplicated packets of information can be transmitted hence this represents a security weakness of the network 10.

If the device 12 is modified to comprise operating software contained in a non-volatile memory which is capable of being overwritten, for example in EEPROM, the attacking device 22 can attempt to disable the device 12 by inserting instructions into the non volatile memory. This is serious because merely switching off the device 12 and then allowing it to reboot itself on reapplication of power will not correct such disruption to its operating software. In this scenario, the device 12 would need to be returned to its manufacturer for reprogramming which can incur disruption and expense.

The attacking device 22 can comprise a computer of the network 10 into w1fich has been loaded corrupted software, for example software incorporating software viruses.

It is thus a crucial issue to the operator of the network 10 that he can take effective action once network security is known to have been compromised to prevent unauthorised 1 devices and corrupt software from being used in the network 10. Theinvention is concerned with addressing this issue.

The inventors have appreciated that it is essential for the network operator to have a method by which public keys in te system can be revoked and substituted with new public keys in the event that network security is known to have been compromised. 25 Referring now to Figure 2, there is illustrated steps of a method of data and software authentication according to the invention; steps of the method are indicated by 100. In Figure 2, the device 12 incorporates a non-volatile ny--mory indicated by 110 and a random access memory (RAM) indicated by 120. The device 12 further includes a processor 125.

The no-n-volatile memory 110 is implemented as an EEPROM, namely its contents can be altered under software control but are retained in an event of power being interrupted to the device 12.

In brief overview, the device 12 in Figure 2 is modified at manufacture to include a security policy represented as data 140 in the memory 110 together with simple operating software 130 capable of authenticating software and data downloaded from the TFrP server 20 into the RAM 120 of the device 12. The downloaded software and data are each partitioned into one or more sections, each section including an associated header declaring which public keys can be used for authenticating the section; such partitioning is illustrated in Figure 3 where software and data files are indicated by 200, the files 200 including code sections 210a, 210b each having corresponding headers 220a, 220b respectively and data sections 230a, 230b each having corresponding headers 240a, 240b respectively. The sinTle operating software 130 is operable to interpret the headers, for example the headers 220a, 220b, check that they correspond to the security policy 140 stored in the meroory 110 and then act to authenticate sections 2 10a, 2 10b associated with the headers. If the headers 220a, 220b, 240a, 240b do not match with the security policy or the sections fail to authenticate correctly using public keys declared in the headers, the siniple operating software 130 determines there to be an error and raises an alarm or causes the device 12 to re-boot itself.

Operation of the device 12 when booting-up in the network 10 will now be described in more detail with reference to Figure 2. The security policy 140 (Policy 1) incorporated into the memory 110 is used to authenticate software and data downloaded from the TT-TP server 20. The policy 140 can be represented by a listing as follows: 5 Policy 1: Public keys Mp-b MKb [code xxx]mpi (data xxx]mpj 10 [change Mp,b to<any key>1mmPj In the policy 140, symbol "xx)C' corresponds to any digit sequence, syrnbol "code" corresponds to executable code, "datC corresponds to data associated with executable software and "change" corresponds to revoking a present public keyMpb stored in the 15 memory 110 and substituting it with an alternative specified public key, namely <any key>. A public key MMpub is used for authenticating instructions invoking a change of the public key Mp,,bin the memory 110. Thus, "public keys K,,b, MMPub" means that the manufacturer of the device 12 has programmed the public keysMpuband NApub into the memory 110, the manufacturer retaining the corresponding private keys Mpj and MMPj 20 secret. Moreover, [code xxx]mp. means that the device 12 is prepared to accept executable code from the = server 20 provided that it can be authenticated against the public key Mpubor any key substituted for Mpubby virtue of the "change" option in the policy 140. Furthermore, [data xxxjmp,bmeans that the device 12 is prepared to accept data from the TFrP server 20 provided that it can be authenticated against the public key Mpbor any 25 key substituted for Mp,, bby virtue of the "change" option in the policy 140. The private and public keys Mpub IMpri andMMpb,MMPi are generated in a manner as described in the aforementioned US patent.

The boot server 18 incorporates a non-volatile memory 150, for example a read/write opt ical disc memory, onto which is stored file data 154 specifying the TFIT server 20 capable of supplying executable software and data for controlling the device 12 when fully interacting within the network 10.

The TFrP server 20 incorporates a non-volatile memory 160, for example a read/write hard magnetic disc memory, into which is stored executable software 162 together with associated network configuration data 164. The executable software 162 and the data 164 are supplied by the manufacturer of the device 12 and signed using the manufacturer's private key Mpri.

In Step I of the method 100 in Figure 2, power is applied to the device 12 to bring it into function. The processor 125 commences by executing the operating software 130 that firstly perfonns a self diagnosis of the device 12 to ensure its correct operation. The processor 125 then proceeds under control of the operating software 130 to emit a "boot me" request (i) onto the system 16 which propagates therethrough and is subsequently received by the boot server 18. The boot server 18 responds to the request (i) by emitting TFTP server data (ii) specifying the server 20 which is received by the device 12.

The processor 125 under direction of the operating software 130 then proceeds to Step 2 of the method where it emits a TFTP file request (iii) to the system 16 which is subsequently received a the TFrP server 20. The server 20 responds by supplying the executable software 162 and the data 164 through the system 16 to the device 12. The processor 125 under control of the operating software 130 then isolates headers in the software 162 and the data 164, namely:

Headers 1: (code xxx)mpi (data xxx)mpi 10 and checks that they are consistent with the policy 140. If they are not consistent, the device 12 raises an alarm or re-boots itself. If the headers are consistent with the policy 140, the device proceeds to authenticate sections of code and data associated with the headers to ensure that they authenticate against the public key specified in the headers, 15 namely public key Mpub- If the sections cannot be authenticated correctly, the device 12 again raises an alarrn or re-boots itself. If a hostile party gains access to the manufacturer's private key NIP. illegally, the hostile party can potentially generate and sign corrupt software and data which the network 20 operator will find indistinguishable from bona fide software and data supplied by the manufacturer signed by its private key Mpri However, if the network operator becomes aware of the hostile party illegally obtaining the private key Kj, the network operator can take corrective action by approaching the manufacturer to generate a pair of new complementary keys, namely private and public keys Npri, Npubwhere the manufacturer 25 retains the private key N. secret, and also to generate a token instruction which is capable of revoking the public key Mp.b in the device 12 and substituting it with the new public key NP.. The token instruction is signed using the manufacturer's private key NDArj and is of the following form:

Token instruction 1: (change Kb Npb)MMpri The hostile party cannot generate such a token instruction without having knowledge of 10 the manufacturer's private key NPA, which the manufacturer keeps as a careftiRy guarded secret which is only invoked in the event of network security being compromised. The network operator then receives the token instruction from the manufacturer and loads it via the boot server 18 or the TFFP server 20 onto the device 12. The operating software 15 130 of the device 12 proceeds to check the token against its policy and finds that it is an instruction corresponding to the policy and authenticable using the public key NB4p,,b initially programmed by the manufacturer in the device 12. The software 130 then interprets the token instruction and substitutes its public key Kb 20 stored in the memory 110 with the newpublic key Np,,,, as provided by the token instruction, When this substitution is performed, the device 12 will thereafter not accept executable code and data signed by the private key K, but only that signed by the private key NP, Tlus substitution prevents the device 12 from accepting corrupt software that the corrupt party may attempt to load into the network 10 after the substitution has taken 25 place, the hostile party only capable of providing software signed by the private key K,,.

The method 100 depicted and described with reference to Figure 2 provides a number of advantages compared to prior art methods of software and data authentication. The method 100 provides a mechanism whereby public keys can be revoked and substituted in the event of network security being compromised, instructions for revocation and substitution being signed using special private master keys, for example NOAPfi, and being authenticable using corresponding special public master keys, for example NDAPub, already programmed into the device 12 during its manufacture.

If the hostile party gains knowledge of both the private keys Kj and MMPi, the network 10 becomes extremely vulnerable to hostile attack from the hostile party. Thus, it is important that the manufacturer keeps the private key MMPi as a closely guarded secret and only uses the key when security of the network 10 has been compromised. The private key M. is likely to be used more frequently as it is applied when signing software and data, for example when the manufacturer provides regular upgrades of software and data for the network operator.

The policy 140 (Policy 1) can be finther enhanced to revoke and substitute more than once a present public key used by the device 12 to authenticate software and data; each time a breach of security has been suspected or identified, token instructions can be interpreted repetitively by the operating software 130 to revoke and substitute public keys in the policy 140. To achieve this, the policy 140 (Policy 1) includes a policy statement:

[change <present key> to <any key>]mmpi The method of the invention can, for example, use a more complex new policy (Policy 2) instead of the policy 140 (Policy 1) to obtain different security characteristics, namely:

Policy 2:

Public keys Qpb, Cp.b, MQP.,,, MCPut, [code xxx]Qpri [data xxxlcpi [change Qpub to <any key>]mQpri [change C to <any key>]mcpri In this more complex new policy (Policy 2), the network operator generates two set of complementary private and public keys Cp., Cp,,b and MCP., MCP,,b according to the aforementioned US patent, the operator retaining the private keys MCPfil Cpfi secret and divulging the public keysMCpub, Cpub tOthe manufacturer of the device 12. Likewise, the manufacturer generates two sets of complementary private and public keys Q,j, Qpuh and MQ., MQ,.baccording to the aforementioned US patent, the manufacturer retaining the private keys Q MQPi secret and divulging the public keys Qp,,b, MQP.bto the operator P.

of the device 12, the manufacturer requiring the operator's public keys for generating the new policy for loading into the memory 110 of the device 12 and the manufacturer including its public keys Qpub, MQpub SO that the operator can authenticate software provided by the manufacturer and also authenticate key change tokens generated by the manufacturer or the netwok operator.

The manufacturer generates the new policy (Policy 2) and installs it into the device 12 during manufacturer. The new policy enables the device 12 to authenticate and execute software signed by the manufacturer using its private key Qpi. The policy does not enable the device 12 to accept data provided by the manufacturer; the operator retains its private key Cpi for signing data which is accepted by the device 12. The new policy (Policy 2) thereby relieves the manufacturer of any responsibility for data used by the device 12. In the event of the operator's private key Cpfi being accidentally divulged or illegally copied, 5 the operator can use its private master key MCPi to generate its own token instruction which the operating software 130 can authenticate and interpret to revoke the public key Cp.b in the new policy (Policy 2) and substitute it with an alternative public key generated by the operator. Likewise, if the manufacturer's private key QP6 is accidentally divulged or illegally copied, the manufacturer can generate for the operator a token instruction 10 which the operating software 130 can authenticate and interpret to revoke the public key Qpub and substitute it with an alterative public key generated by the manufacturer. The new policy (Policy 2) provides the advantage that software and data from different sources can be authenticated by the policy. 15 Yet more complex alternative policies are feasible for authenticating software supplied by a number of different supplying parties, for example an advanced policy (Policy 3) is as follows: 20 Poficy 3: Public keys Rlpub R2publ R3pub CPO [code XXX']Rlpi [[code xxx2]R2pi]Cpi [code xxx3]R3,,i 25 [data xxx]cp,i [change Rlp.b to 'anY keY>]Rlpi [change R2pub to<any key>IR2pi [change R3p.b to <any keY>IR3pi [change C to <any key>]cpi This advanced policy enables the device 12 to authenticate software supplied and signed by any of three supply parties corresponding to Rl, R2, R3, although for party R2, the operator must also sign the executable code [code xx21R2pfif6r it to be acceptable to the device 12. Moreover, the alternative policy also enables revocation and substitution of public keys Rlpb, R2p.b, R3p,,bby tokens signed by their corresponding private keys.

Furthermore, the alternatively policy (Policy 3) also enables the network operator to revoke and substitute its public key Cplbwith an altemative public key. None of the operator and the parties corresponding to R I, R2, R3 need to divulge their private keys to one another, thereby ensuring security. In the alternative policy (Policy 3), there are no master keys included which are specifically reserved for key revocation and substitution as in the policy 140 (Policy 1).

More complex policies are feasible which enable the device 12 to be very selective regarding software and data which it is prepared to accept. Token instructions can include what is known mathematically as Regular Expressions, for example alternatives, repetitions and optional elements which only revoke and substitute keys when certain conditions are Rilfilled.

In the network 10, it is possible to have identical policies in each of the devices 12, 14 or, alternatively, a number of different security policies customised for their respective devices 12, 14.

The method of the invention is distinguished from prior art in that key revocation is perfori-ned by token instructions wMch are interpreted by the operating software 130 loaded at manufacture into the device 12. An alternative approach when key security has been compromised is to load executable revocation software into the device 12 which simply overwrites the policy 140. Such an approach is inferior to the method of the invention described above because no authentication is carried out on the revocation software by the device. If the revocation software is supplied by a hostile party, the devices 12 is not provided with an opportunity of authenticating the software against a reliable key, for example NMP,,,,,. In the device 12, the operating software 130 is configured to prevent the policy 140 being directly overwritten and only modifiable by way of token instructions which the operating software 130 must first authenticate and interpret before acting to modify the policy 140.

In some cases, manufacturers of devices such as the device 12 are not in a position to provide corresponding policy files for its customers; the customers can, for example, be situated in a different continents and their security requirements will not be known in advance at time of manufacture. To cope with this situation, devices similar to the device 12 can be manufactured with a very simple security policy loaded into nonvolatile memory 110 thereof, namely (Policy 4):

Policy 4:

Public key Xp.b [code zzz]xpi The operating software 130 can be configured to interpret a public key Xp, ,b as a special unique key such that any executable code signed by the private key Xpi and authenticable using the public key Xp,,b is allowed by the operating software 130 to overwrite the policy (Policy 4) in the memory 110 and substitute it with a replacement policy. Such a unique option enables the manufacturer to produce standard devices with the initial security policy (Policy 4) installed into memory which is subsequently reconfigured by software signed by the manufacturer to meet customers individual security requirements.

The key Y.P. is thus a particularly valuable key which has to be guarded carefiffly because a hostile party gaining knowledge of the private key Xpi can corrupt security policies in devices such as the device 12. However, once the initial policy (Policy 4) is overwritten and replaced by a corresponding customized security policy, new keywords will be installed in the memory 110 which will prevent subsequent overwriting of the customized policy using code signed by the private key Xpi.

It will be appreciated by one skilled in the art that modifications can be made to the method of the invention without departing ftom the scope of the invention. Revocation and substitution of keys can be, for example, recorded in the random access memory 120.

Substituted keys can override keys stored in the non-volatile memory 110 but operable not to delete them. If the device 12 malfimctions on account of corrupt software being downloaded into it or an incorrect key revocation and substitution occurring, the device 12 can be switched off and then power reapplied causing the operating software 130 which interprets policy changes to commence operation using its original security policy as recorded in the non-volatile memory 110. Such a method counteracts a need for the network operator to return the device 12 to its manufacturer in the event of a revocation and substitution error occurring.

Although the method of the invention is described in the context of the computer network 10, it can be applied to other types of system where unauthenticable software and data provided thereto are not to be accepted and executed, for example in set top boxes for receiving cable broadcasts from a cable network operator. The method of the invention enables software and data loaded into set-top boxes to be authenticated therein, thereby 10 reassuring owners of the boxes that execution of the software and data supplied will not potentially cause malfunction and failure of their boxes. Likewise, the method also enables vendors supplying software and data to the set-top boxes to update public keys in the boxes in case their private keys are compromised and there is a risk of inferior fake software being loaded into customer's set-top boxes by hostile third parties. 15 Although application of the method of the invention to a set top box linked to a cable network is described above, the method is equally applicable to other types of network, for example radio networks and networks linked through satellites. The method is, for example, especially applicable to the Internet when loading new software and data from 20 the Internet into a personal computer connected thereto. The method of the invention can be further applied to multiple application smart cards, such cards giving access to multiple services from a plurality of vendors. Vendors conventionally supply their own proprietary cards to customers providing them with 25 access to the vendors' services. Such a practice results in customers often acquiring numerous cards which can be inconvenient, namely one card for each vendor. It is therefore desirable for customers to have fewer cards, each card providing access to more than one vendor's services.

Such multiple application smart cards provide access to multiple facilities, for example financial credit facilities. Each smart card incorporates a random access memory, a read only memory and a processor. Moreover, the smart cards need to be updated from time to thm as new vendor services become available. New software and data loaded into the smart cards needs to be checked to guarantee its authenticity otherwise, if defective 10 software and data are loaded into the cards, there is a risk that the defective software causes an unwanted transaction to occur, for example transferring ftmds from a card owners bank account into a criminal bank account. Each smart card can therefore advantageously apply the method of the invention to authenticate new software and data being loaded into it and only run the software or use the data if it authenticates correctly 15 against a security policy recorded within the card. In the event of a vendor's private key being copied by a hostile third party and it being discovered that the hostile party is about to download defective software or data into customers' smart cards, the vendor can use the method of the invention to revoke and 20 substitute public keys in the smart cards corresponding to the vendor so as to prevent the hostile third party from successftilly downloading defective software or data into the smart cards. The method of the invention is also applicable to other types of computer-based 25 communication apparatus, for example mobile telephones and computer-based radios, where software upgrades to improve functionality of such apparatus are provided by associated vendors from time to time. Owners of the apparatus desire reassurance that software and data downloaded to their apparatus will not cause malfunction thereof even if the vendors have had their private key security comprised and have taken corrective action according to the invention by revoking and substituting public keys in the apparatus.

Claims (15)

1. A method of data and software authentication in a network incorporating at least one device provided with at least one associated present security key for use in verifying data and software authenticity thereat, and key modifying means for issuing instructions to the at least one device for revoking its associated at least one present key and substituting it with at least one corresponding alternative security key, the method including the steps of- (a) receiving instructions from the modifying means at the at least one device interpretable thereat for revoking its at least one present key and substituting it with at least one corresponding alternative key, the instructions being authenticable using one or more of the at least one present key; and (b) designating the at least one alternative key as included in the at least one present key for authenticating software and data and repeating step (a) as appropriate for ensuring network security.

2. A rDethod according to Claim 1 wherein the at least one security key and at least one alternative key are public keys, the public keys having associated therewitli corresponding private.security keys, each public key having a complementary private key, each private key substantially incapable of being derived merely from knowledge of its corresponding public key, the data and software in the network signable using one or more private keys and authenticable at the at least one device using one or more corresponding public keys.

3. A method according to Claim 2 wherein the data and software include headers for identifying public keys which can be used for authenticating them

4. A niethod according to Claim 1, 2 or 3 wherein a subset of the at least one present key in each device is reserved for authenticating key revocation and substitution instructions only.

5. A n-&thod according to any one of Claims I to 4 wherein the instructions to revoke and substitute the at least one present key in the at least one device are issued from a file server included in the network.

6. A n-&thod according to any one of Claims 1 to 5 wherein a supplier of each device installsgjat least 6neresent key thereinto prior to delivery of the device for incorporation into the network, and also supplies corresponding instructions for inclusion in the modifing means for revoking and substituting the at least one present key with at least one corresponding alternative key supplied by an operator of the network to the supplier for use in generating the instructions.

7. A roethod according to Claim 6 wherein the supplier is provided with at least one. public key from the operator for generating the instructions, the supplier encoding the instructions using a private key generated by the supplier, the private key having a corresponding public key included by the supplier in the at least one device prior to delivery thereof for inclusion in the network.

8. A rnethod according to Claim 7 wherein interpretation of the instructions at the at least one device revokes at least one public key supplied by the supplier with at least one corresponding public key provided by the operator.

9. A method according to any preceding claims, wherein different keys are used in the at least one device for authenticating software and data provided by corresponding different suppliers to the network.

10. A method according to any preceding claim wherein the keys in the at least one device are stored in non-volatile memory therein.

11. A method according to any preceding claim wherein initial keys supplied in the at least one device when initially included in the network are stored in non-volatile memory, and subsequently substituted corresponding alternative keys are stored in volatile memory, the at least one device capable of reverting back to initial keys in an event of the at least one device being powered down and subsequently powered up again.

12. A broadcast network operable according to a method of any preceding claim for managing access to the network.

13. An multiple application smart card operable according to a method of any one or more of Claims 1 to 11.

14. A computer network operating according to a method of any one of Clainis 1 to 10.

15. A method substantially as herein before described with reference to one or more of Figures 1 to 3.