GB2363948A - Communication method involving prior negotiation of parameters - Google Patents

Abstract

In a system providing communication betweene two devices having an encryption/decryption capability, negotiation takes place between the devices prior to communication to define parameters relating to access control (including means of distribution, cryptographic strength, acceptable cryptographic algorithms and hierarchical parent), information content (including bandwidth requirements and permitted latency) and means of verification of the information source and content. The encryption function may be embodied in a smart card or token.

Description

2363948 Communication Method This invention relates to a method of

carrying out secure and verifiable communication and in particular to a method for secure and verifiable communication through an electronic data network.

The value of electronic data communication networks to allow quick communication and rapid transfer of data is well known One problem is attempting to obtain the potential benefits of such systems is the risk that information may be intercepted by an authorised persons, allowing unauthorised access to or copying of the information.

Another related problem is the need to confirm that information genuinely originates from the purported sender and has not been altered in transit.

These problems are of course particularly severe where information is transmitted through a public communications infrastructure, for example, the Internet, where the ability of unauthorised third parties to physically intercept or alter information must be assumed However, even on dedicated communication systems where physical access to the system is limited or controlled, there is requirement to allow secure and verifiable communication.

Generally, it has been attempted to provide secure and variable communications by encrypting the information sent so that even if an encrypted message is intercepted or copied, the information it contains remains inaccessible In principle, such encryption will also provide verification as to the originator of the message and the accuracy of its contents because in the same way that only an authorised recipient of the message will know how to decrypt it, only the purported sender of the message will know how to encrypt it to allow correct decryption However, in order to verify the accuracy and origin of non-encrypted messages and to more definitely verify the origin and the content of encrypted messages, a digest or signature may be sent together with the message, the digest or signature being encrypted and derived from the message itself so that the decrypted signature or digest allows the origin and content of the message content to be verified whether the content itself was encrypted or not.

Such techniques are well understood, but there are considerable difficulties in using them in practice.

One problem is the difficulty of arranging the issue of appropriate encryption keys to allow encrypted communication to take place The issue of encrypting keys is generally a complex procedure to carry out and in practice the time and cost to issue keys is inconvenient and in some cases prohibitive A further problem which is encountered with public communications networks such as the Internet is that the physical communications path followed by messages may not be able to support the intended cryptographic techniques so that the attempt to provide secure or verified communications in fact results in no communication at all being possible.

This invention is intended to overcome these problems, at least in part.

In a first aspect, this invention provides a communications method for communicating between first and second encryption devices in which a distribution mechanism for each of three elements of a communications flow in each direction between the encryption devices is stored by the first encryption device, the three elements of the communications flow being an access control element, an information content element and a verification element and each distribution mechanism defining the following parameters:

means of distribution; minimum required bandwidth; maximum permitted bandwidth; maximum permitted latency; minimum cryptographic strength; acceptable cryptographic algorithms; hierarchical parent; source specification; destination specification; wherein, before communication can take place the first and second encryption devices negotiate to establish a set of parameters for the communications flow which can be supported between the devices and comply with the distribution mechanism stored by the first device and if a set of parameters is established the first device allows communication between the devices using the established set of parameters.

In a second aspect, this invention provides software able to carry out the above method.

In the present invention information is to be transferred from a source to a receiver with the information being encrypted or at least validated or verified regarding its source and content Note that in this application the terms validate and verify are used synonymously.

In the present invention the difficulties encountered in conventional cryptographically based communications are overcome primarily by the use of a smart token to allow the recipient to access or verify the received information.

Where information is to be sent from an originator or service provider to a client or user receiving the information, the originator employs a cryptographic encoder to encrypt the information and generate a message incorporating the encrypted information Similarly, -he client will require a software smart token able to decrypt the received message so that its information content can be accessed and/or verified In most cases, the software smart token will be held within or operated by a dedicated hardware device such as a plug in smart card carrying the smart token.

In any event, the smart token will be operating within some hardware which may or may not be dedicated.

The cryptographic encoder and the client hardware operating or containing the smart token will be connected to one another through an electronic communications network.

Communications over such a network will be controlled by a network communications protocol such as the Internetworking protocol (IP).

Where the communications method of the present invention is to be used to transfer information between an information originator and an end user this information transfer function is the service provided using the method.

In this application, the term originator is used to refer to the person setting the service specification which ultimately controls all services provided and whether the service is provided.

Although the operation of invention can be conveniently understood by considering the example of the situation where the originator is providing the information to which the end user requires access, and the discussion below often discusses the invention in these terms for clarity, it should be remembered that it is entirely possible that some or all of the information content to be transferred is actually generated by the end user and the service provided is the transfer of this information to the service originator.

Further, the references to an originator or service provider and an end user or client as being the parties involved in the service in no way implies any particular contractual relationship between them These terms are only used to indicate that the originator is the person who sets the service specification held by a cryptographic encoder supporting the service while the end user must negotiate with cryptographic decoder to show that the service specification can be met to allow the service to be provided.

In the description there are numerous references to information being unencrypted or decrypted It should be understood that this only refers to encryption in the course of carrying out the inventive method and indicates that the information has not been encrypted in carrying out the method or has been encrypted and subsequently decrypted in carrying out the method It is of course entirely possible in practice that this "unencrypted" or "decrypted" information is encrypted independently from the described method.

In general, when an originator wishes to provide a service using the invention, the originator must supply a service specification to a cryptographic encoder The service specification must contain specifications of all distribution mechanisms used to provide the service as will be explained below The service specification may also define the format of the received and delivered information and other management instructions and commands but these are not part or present invention.

In order to allow access to a service, a would be end user must first register using a smart token During this registration phase, negotiations will take place between the smart token and the cryptographic encoder to determine whether the service is to be provided and the communications parameters for provision of the service Subsequently, when the user wishes to access the service the user must make an access request using the smart token and the service will be provided The access request phase may include further negotiation between the smart token and the cryptographic encoder to confirm that the previously agreed parameters can still be supported Further, where a range of parameters is agreed in the registration step, negotiation can take place to decide which parameters of the range will be used.

In practice it will often be the case that the first access request will take place immediately after registration.

It is possible that a service to be provided by an originator to a client may just be the one off provision of a single piece of information However, normally a service will involve the provision of multiple items of information over a period of time.

The originator of information to be delivered by a service must define the distribution mechanisms which may be used by the service These must be specified for three elements of the service, the command flow, which comprises two protection structures, and the content flow Each of these elements may be bi-directional and the two directions of each element have separately definable distribution mechanisms As a result, the service definition must contain the specifications of six different distribution mechanisms.

The two protection structures are a first access control structure containing the necessary access keys to allow decoding and a second authentication structure containing any required signature.

The service specifications are the specifications required to take clear text information from one party (the originator), encrypt it, and subsequently deliver the decrypted clear text information to an end point(the client or end user).

Once the information content provided by the originator has been decrypted and delivered the client, the client is able to use the received information as they wish.

Each of the six defined distribution mechanisms which must be specified to fully define the service must have the following items specified:

1 Means of distribution 2 Minimum required bandwidth 3 Maximum permitted bandwidth 4 Maximum permitted latency Minimum cryptographic strength 6 Acceptable cryptography algorithms 7 Hierarchical parent 8 Cleartext Source Specification

9 Cleartext Destination Specification

Ciphertext Transport Specification

9 - Thus, in order to allow the information regarding service to be provided, the information originator must define the six distribution mechanisms of the service These definitions are provided to the cryptographic encoder.

Although, as explained above, each service has six distribution mechanisms, which must be specified to define the service, it may be that some of these distribution mechanisms are not actually required by a particular service.

These distribution mechanisms which are not required are given a "null" specification.

When a user or client wishes to access information through the service, the end user must contact the cryptographic encoder The cryptographic encoder will then negotiate with a smart token of the access equipment being employed by the end user to allow service registration to take place.

The items listed above which must be specified to define each distribution mechanism of the service will now be discussed in detail.

Generally, communications protocols will allow messages to be sent by several different means of distribution such as unicast (point to point connection), multicast or broadcast The originator must specify for each information providing service which of these means of distribution may be used for each of the distribution mechanisms making up the service Each distribution mechanism may allow one or more means of distribution to be used to distribute the information In order for registration to proceed, the end user access equipment must be able to support one of the specified means of distribution, and negotiation between the cryptographic encoder and the end user access equipment will select a specified and mutually supported means of distribution for each distribution mechanism.

During service registration the end user access equipment will establish the currently available bandwidth capability and the latency of the current end user access equipment by obtaining the parameter values facilitated by the current user access equipment from the support software of the access equipment For example, the support software may have the end user access equipment "ping" the remote cryptographic encoder so that that portion of the transport latency can be estimated.

It is to be understood that bandwidth and latency for the current user end user access equipment will depend not only on the hardware and software of the end user access equipment itself but also on the properties of the communication links between the cryptographic encoder and the end user access equipment.

The cryptographic encoder will take the current bandwidth capability and latency of the end user access equipment and compare these to the minimum and maximum bandwidths and maximum latency set in the distribution mechanism specifications.

For all of the specified items, if the parameters set for the distribution mechanism specifications of the service are satisfied, service registration can proceed If the service parameters are not satisfied, the cryptographic encoder will respond in one of three ways The cryptographic encoder may refuse to provide the service, the cryptographic encoder may provide the service together with a warning that satisfactory communication may not be possible or the cryptographic decoder may offer an alternative service.

Normally, where the cryptographic encoder refuses to provide the requested service, an appropriate warning method will be sent.

Which of these possible responses is made by the cryptographic encoder in each instance and the basis on the response is to be selected must be specified by the originator on a case-by-case basis and so will not be discussed in detail herein For example the possible responses may be selected based on which of the service parameters were not satisfied and by how much.

The entire service registration negotiation process takes place by way of a root dialogue between the cryptographic encoder and the end user which is as undemanding as possible in terms of the required bandwidth, but has the highest possible cryptographic strength for the end user equipment being employed Of course, if this negotiation root dialogue is not satisfactorily supported, negotiations will not be possible and no services will be available.

In practice, it is possible that a smart token may be used for service registration from one end user access device and that the same smart token may be used later with a different access device after registration to access the requested services If this occurs, the cryptographic registration process will have to be repeated to determine whether the new access device is capable of satisfying the negotiated service parameters.

The assessment of the cryptographic strength supported by end user device is largely subjective because it depends on the resources which are estimated to be necessary to determine the keys used for encryption This estimate is based on the assumption that the encryption algorithms used are themselves in the public domain, but this will normally be the case.

The parameters determining the cryptographic strength will be negotiated between the cryptographic encoder, based on the specification set by the service originator, and the user access device, using the smart token if required The necessary parameters may include whether the communication will be in clear or symmetrically or asymmetrically encrypted, the key length of the encryption key to be used and the validity period of the key used.

The acceptable cryptography algorithms is a listing of the algorithms deemed acceptable for providing the service by the originator This may be an exclusive list of algorithms making the use of one of the listed algorithms mandatory.

Alternatively, the identification of acceptable cryptographic algorithms may be left blank and selection of an appropriate algorithm left to negotiation between the cryptographic decoder and the user access device In this case, the cryptographic algorithm used will normally be first algorithm identified in the negotiation which both satisfies the cryptographic strength of the distribution mechanism specification and can be implemented by the cryptographic encoder and the end user device.

Clearly, the cryptographic encoder will itself have to maintain a listing of supported cryptographic algorithms independently of any list defined for specific services, and any algorithms to be defined in the specification of services will have to be algorithms supported by the cryptographic decoder.

In practice, it will normally be necessary to carry out negotiation regarding the cryptographic algorithm to be used to encrypt root dialogue for negotiation of service parameters in clear text as a first stage of the root dialogue between the cryptographic decoder and the end user device so that the selected algorithm can be used to encrypt subsequent root dialogue negotiation messages It is always necessary that a cryptographic algorithm be selected, but negotiation will not always be necessary because the root dialogue encryption algorithm may be preselected.

The cryptographic strength and acceptable algorithms for the distribution mechanisms of the service are separately specified because the cryptographic strength will depend upon the cryptographic algorithm used Accordingly, the judgement is to whether the cryptographic strength requirement is met is judged based upon the use of the weakest cryptographic algorithm which will be available for use If a stronger algorithm is used, it will automatically follow that the cryptographic strength requirement is met.

The separate specification of the distribution mechanism for all six of the possible distribution mechanisms for service provides great flexibility to tailor the degree of security provided as required One possibility is the situation where there is less concern to prevent unauthorised access to the transmitted information and a greater concern that the origin and content of information is authenticated.

In this case the information content itself may be transmitted with a relative weak but fast encryption or the information content itself may be transmitted in clear without any encryption at all A signature is also sent which validates the received information content to the user The signature will be encrypted and contain information derived from the accompanying information content so that the decrypted signature can be compared with information derived from the received information content to confirm that the received information content is correct.

Typically, the signature can be a cyclic redundancy check derived from the information content and asymmetrically encrypted within a public key encryption infrastructure.

This will require that the signature and the information content itself are treated differently and it is intended that the signature will be transmitted within the command flow element of the service while the information content is transmitted within the content flow of the service.

Where the information content is not encrypted, the specified distribution mechanism for the information content transmission part of the service will have a minimum cryptographic reference strength of none and acceptable cryptographic algorithms will be defined as clear.

Where signatures are used to validate information content, time stamping may be needed in order to ensure that the signature can be tagged to the content to which it applies For example, streaming video may be transmitted at variable bit rates which can cause difficulties in identifying when a certain amount of data has been generated.

This is only an example and there are other situations where time stamping may be required or desirable.

It might be assumed that the most recently received signature corresponds to the most recently received content, but ensuring that this is correct will impose computational constraints on the end equipment which may be unacceptable.

When this is the case, time stamping of signatures and content will be required.

Access keys to allow information content and any signature to be decrypted must be provided to a user before the information content or signature itself, while any authenticating signature authenticating a content will be transmitted after the content itself As a result, there will always be some non zero latency between the content and signature It is because of this consideration that the control element of the service has two protection structures, one protection structure for access control providing the necessary access keys and the other to carry signatures.

If no signature is required, the part of the service definition relating to the signature protection structure of the command flow can be defined as a null specification.

It is to be noted that even where the information content is encrypted to prevent unauthorised access, it may be still be desirable to provide a signature portion encrypted to higher level of cryptographic strength to provide verification Because the size of the signature section of the service will normally be significantly lower than the size of the information content itself, it will usually be found that even where the information content itself has been encrypted to the highest cryptographic strength which end users and the communications infrastructure will be able to handle it will still be possible to apply stronger and slower cryptography to the signature because of its smaller size.

It may appear that where the information content and any associated validation signature are to be similarly encrypted, there will be no requirement for a separate signature part of the service so that this will always be given a null specification in the service definition.

Although this may be the case, it is also possible that the originator may wish to maintain a separate information content and signature section in the service definition even though they are identically encrypted in order to allow for the possibility that their treatment may differ in other ways, or in order to have more commonality between the service definition structures for different services.

The hierarchical parent identifies for each distribution mechanism other service specifications which can be used to provide an encryption key for the distribution mechanism.

The hierarchical parent mechanism by which one service is able to provide an encryption key for another service having a different service specification is the mechanism by which encryption key distribution and ITSEC 6 traceability is provided.

Generally, asymmetric cryptography is used to carry out public key implementation (PKI) encryption schemes Normally such schemes require a trusted third party (TTP) or certification agency to offer a public key directory service.

Some companies, particularly in the banking sector, have decided against the use of TT Ps and instead operate their own key management operations However, many of these companies themselves offer TTP services to other parties so the distinction between dedicated public key directories services and TTP services are often unclear.

In the present invention, the private key will always be held within the smart token, while the necessary public keys are held in the cryptographic encoder The smart token and cryptographic encoder are themselves secure against cryptographic attack so that the keys they provide can be trusted by the originator and the end user so that the hierarchy used to issue the keys can be as flat or as tall as the originators and users require.

This allows the problem encountered in traditional PKI schemes, that the hierarchy for key issue and its management is so complex that the system is difficult and expensive to use, to be avoided.

Of course, absolute security of any device or information is impossible, so that in some instances the use of symmetric keys may still be preferred.

The use of DHM is particularly attractive for use in conjunction with a smart token This is because when the token is removed from an associated host interface device acting as user access device, the host interface device loses any ability to participate in the double ended key generation scheme However, as a result this is not suitable for unattended services where access to a service may be required when the smart token is absent.

The use of the hierarchical parent mechanism allows the encryption keys needed by a service to be provided by another more secure service For example, two way cryptography will normally be faster to apply than one way cryptography so that two way cryptography is normally more applicable to high bandwidth services However, there is a considerable problem of key distribution in such two way cryptography approaches.

However, by using the hierarchical parent mechanism, a high bandwidth service using two way cryptography can nominate a lower band width but more secure system such as a PKI scheme as its hierarchy parent This parent service can then be used to provide the necessary encryption keys to operate the two way cryptographic service.

When the hierarchical parent technique is used to provide encryption keys care must be taken that the parent system is capable of providing new encryption keys to the child system within the key validity period specified for the child system so that continued functioning of the child system can be guaranteed.

The decision as to what constitutes acceptable cryptography is a matter for the service originator and is not determined by the method of the invention.

The clear text source specification specifies the source IP number, or corresponding address under other communication protocols, from which the service is provided.

A single address or a number of addresses may be specified.

Only data from the specified address or addresses is considered to constitute the defined service Any external applications must send data to the specified addresses for this data to be carried by the service.

This allows the originator to supply the information for a service from servers remote from the cryptographic encoder without compromising security and also permits multiple client devices or user access devices to send back data with the same specification structure.

The clear text source specification of a distribution mechanism specification for the return part of a service, that is for a distribution mechanism returning from the end user to the originator may specify whether the initial unencrypted clear text data may originate only from a secure smart token interface or whether it may originate from other parts of the generally insecure user access device.

The clear text destination specification specifies the

IP port number, or equivalent address for other communication protocols, of the device to which the decrypted, clear text, data is to be sent In order to avoid compromising the security and integrity of the information this defined destination should have some private or secure connection to the decryption device, that is the cryptographic decoder or the smart token. Obviously, sending the decrypted clear text data through any switch,

router or other device which could be used to intercept the data will compromise the security of the system Accordingly, if any intermediate third party offering an anonymity service for customers is to be used it should be ensured that they employ back-to-back encoders to decrypt the data and immediately re-encrypt it before further transmission.

The decrypted clear text data _s not to intend to be routable further beyond the specified destination because this would compromise security In practice, this may require devices containing cryptographic encoders or smart tokens to be fitted with two network adaptors, one being a dedicated adaptor for cryptographic traffic and one for other traffic Such arrangements should be used only if the service originator and end user are satisfied that the encoder or smart token cannot be subject to cryptographic attach through the second adaptor.

The clear text destination specification also specifies whether or not the secured data must be retained by the decoding device, or by any further host device forming the user access device This allows the highest level of service security and permits secure caching of data by essentially providing a server within an encoder.

Where source and destination addresses are given in the clear text source specification and clear text destination specification, it may be necessary to identify the relevant network type as well as the actual address in order to allow the specified address to be used.

The decrypted information delivered by a service is sent to the destination IP port, or corresponding address for other communication protocols, specified in the clear text destination specification and the clear text source specification identifies the IP address and the port number, or corresponding address for other communication protocols, which should be used by the encoder as the source of the information to be encrypted.

The cipher text transport specification allows for the possibility of employing network diversity to increase security by taking sequential portions of the encrypted data and sending it by different network routes to a destination.

This is particularly useful when the routing is being carried out through the Internet because this supports such a large number of different routes.

The cipher text transport specification sets the number of different routes which should be nominated to carry the service The number of routes which may be nominated for a given service in the cipher text transport specification will generally be limited to some maximum number based on the capabilities of the cryptographic encoder and supporting hardware and software and the user access device Generally, any specified route may carry any number of services The distribution mechanism specifications will not normally have any control of the number of services carried over a particular route, but the number of services which are being carried by a particular route may be controlled by the cryptographic encoder or its supporting hardware and software in order to avoid more capacity being demanded from the route than it is able to support.

In operation the encrypting device will autonomously fragment the encrypted data and send it by the nominated routes The decrypting device must be equipped to support at least the number of network diversity channels employed by the encryption device, so determining the number of network diversity channels, that is number of different routes, which can be employed will be part of the initial service registration negotiations.

Conveniently, the number of routes can be set to be in the range 1 to 16 and the fragmentation is done by sending 16/N bits to each route in turn, with N = 1,2,4,8 or 16.

Some information originators may preset the network diversity to only make their services available at a specific diversity level This may be used to set the diversity of their services to one so that users of that originators services only need to be able to support a diversity of one and the information path connecting them only needs to support a single route.

The cipher text transport specification is not an essential part of the distribution mechanism specification.

It is preferred to incorporate the cipher text transport specification in the distribution mechanism specification so that network diversity can be supported if desired However, if limitation to use of only a single information route is acceptable, the cipher text transport specification can be omitted.

When using the information transfer method or protocol of the invention, when an end user wishes to subscribe to the service, the end user must carry out the service registration process as set out above to allow the cryptographic encoder and the user access device to negotiate a set of distribution mechanism specifications which they can both support and which are regarded as permissible by the service originator.

This negotiation may determine a single set of distribution mechanism specifications or a number of them The set of distribution mechanism specifications may include ranges of parameters.

At the start of a content transfer session the cryptographic encoder and the user access device again negotiate to use one of the permissible sets of distribution mechanism specifications which were determined in the subscription phase.

The user may subsequently attempt to access the service through a different access device to that used during subscription If so, the new access device must have suitable software so that it can report to the cryptographic encoder that the negotiated bandwidth and latency parameters can be satisfied If these parameters are not satisfied, or if software to allow this to be determined is not present, the cryptographic encoder may refuse to provide the service, offering a lower grade service or provide the service with a warning that satisfactory communication may not be possible as specified by the service provider instructions.

Once the parameters of the current user access device have been determined to be adequate for the set of distribution mechanisms negotiated for the service, information content transfer can take place Service specific user data and the user stored service parameters are available to the service originator if required.

It should be noted that both the reception and transmission processes require bandwidth and latency quantifying so that their part in the overall end to end information transfer chain can be taken into account.

The encrypted content transferred is then supplied to a user access decryption engine, preferably a smart token The description engine is regularly provided with decryption keys as specified in the service distribution mechanisms specification The decryption keys can be provided within the same user access device or from an external device.

Where the keys are provided by an external device, the service using the decryption engine must specify as a hierarchical parent service, the service which provides the keys to the external device.

The decrypted data is output by means specified in the service application code Typically, some interface means will be required to transfer data from the decryption engine to output at the specified port.

One example is the reception of variable data rate video where a software decryption engine within the user access device is provided with a decryption key held in an external smart card which must be physically inserted into a slot on the access device The smart card has been previously issued the key by a PKI exchange process Thus, the smart card enabled secure video service is a hierarchical child service to the smart card PKI conditional access and must identify the smart card PKI conditional access as a hierarchical parent authorised to provide it with encryption keys.

The service originator delivers data to an encryption engine incorporated within the cryptographic encoder.

Usually the cryptographic encoder has additional functions beyond those of the encryption engine Typically, the encryption engine will have both hardware and software elements but in some bidirectional services such as consumer auctions, lower cost software only encryption engines may be used However, it is expected that in the majority of applications the encryption engines will have at least some hardware support to ensure the security of the system.

In many situations, it is desirable for the parties to a service to be anonymous so that it is not possible to tell who is communicating with who or who is using a given service.

Cryptographic encoders employing the present invention are ideal third parties to provide anonymity If a first party sends messages to the encoder IP address and port identified as the clear text source in a service specification, it will not be possible for any third parties to identify the intended ultimate recipient of the message but only the fact that it is has been sent to the cryptographic encoder.

This requires the encoder IP address to be the destination for the first party transmission In order that the system as a whole is IP transparent, it is necessary that the second party which is the intended ultimate recipient to be identifiable even though the cryptographic encoder is the destination for the first party messages This can be achieved by the service provided by the cryptographic encoder being the forwarding of all messages received at the encoder IP address to the second party for decryption.

However, it is possible that the IP address and the port number used for a particular service or to communicate with a particular ultimate recipient could leak out so that the encoder address used would be sufficient to allow the person or service being communicated with to be entered.

In order to ensure true anonymity a macro service ca- be used The macro service carries the true second party/ultimate recipient address or the identity of the service to be accessed within the messages IP packets for the macro service should be all the same size.

An alternative approach is to encrypt the IP and port addresses themselves However, the use of a macro service is preferred to the encryption of IP port addresses because the encryption of IP port addresses will reduce service performance.

Macro services to provide anonymity can be set up using the present invention by allowing ring fenced application written in the protected language, for example JAVA, to run within the encoders so they appear as normal address destinations and sources.

References to IP addresses and ports relate to the use of the invention in the common situation where the Internetworking protocol is employed Where other communication protocols are employed analogous address information will be used.

The inventive method and protocol as explained above, allows the secure and verifiable transfer of information from one point to another with the protocol being highly flexible to allow the degree of security provided to be adapted to originator and user requirements and to allow the system operating parameters to be adapted to the available equipment and communications network.

The communications method and protocol does not place any limits on how this information transfer functionality is actually used by the service providers or originators and end users Considerations such as end user access rights, stored value and end user identifiers are application specific and are not addressed by the present invention These matters are data objects to be transported by the method and protocol of the invention or are derived therefrom.

Devices employed to carry the invention such as the cryptographic encoder will have their own addresses which will be IP port addresses, or corresponding addresses for other communication protocols These addresses will initially be configured locally and this configuration information must be manually provided to content or service originators so they know where to send the service specifications specifying the desired distribution mechanisms for their services.

It is expected that in practice for most applications, smart tokens will be used to enable user access to services, although the use of smart tokens is not an essential part of the present invention.

Further, it is anticipated that it will normally be convenient and advantageous for security reasons to have smart tokens embedded within dedicated physical carriers such as smart cards.

Where a smart token is used, this will provide the core of the end users' security A smart token will provide the highest level of the hierarchy for both encryption and decryption by the end user access device or devices That is to say, the smart token will provide the root key or keys for all cryptography algorithms employed whether these algorithms are executed within the smart token itself or elsewhere.

Normally, where only some or one cryptographic algorithm is executed within the smart token itself, this will be the slowest one of the algorithms used.

Where the smart token is contained within a smart card or other portable physical device, the physical device containing the smart token is required to allow the user access device to access secure services Thus, the other parts of the user access device cannot be used to access secure services when the smart card is physically removed.

This provides additional security that requests for access to a service are being made by the authorised end user rather than by someone illicitly employing the user access device.

This may be particular important to the user where a charge is made based on the amount of use rather than on a subscription basis.

The smart token will be supplied with at least one A Pl on it This A Pl will also confer access to hierarchically inferior applications Optionally, the smart token may support a number of parallel API's This allows the smart token to be implemented on a multi-application smart card which also carries out other applications which are not managed according to the present invention Usually, however, a multi-application smart card will have the AP Is of all applications accessible only via a single highest level API This is an analogous to applications running over a conventional operating system except that in this case the application is only accessible through the operating system, that is the alternative applications on the smart card are only accessible through the highest level API This approach permits other applications to be protected by the security of the highest level API.

Where a smart token is used in consumer applications, it will be necessary for the smart token to store the ISP telephone number and Internet URL of the service operator so that consumer products having their access to services controlled by the smart token such as set top boxes can be initialized prior to communication with the remote cryptographic encoder These details will be made available to the smart token through the highest level API.

When an end user registers for a service, it will normally be convenient for the end user to ask the service 31- provider the amount of data that the service will need to leave on the smart token The smart token will then reply indicating whether there is sufficient space on the smart token If there is a sufficient space, the service will send the data to the token.

If there is insufficient space in the smart token, and the service specification allows storage in the user access device outside the smart token, the service will be provided and the data stored in the user access device.

Alternatively, if this is not allowed in the service specification, the requested service will not be provided.

In order to prevent cryptographic attack on the smart token directly by altering software or indirectly by altering the software on an interface device linked to the smart token which forms part of the user access device, any changes to the software on the interface device or the smart token should only be accepted if validated by the highest level A Pl on the smart token.

This method of protecting the smart token from cryptographic attack is protected in its own right by a co- pending patent application.

In order to allow use of the inventive method to be monitored and controlled, each smart token contains a unique user identifier The smart token issuer provides unique identifiers for loading onto smart tokens to its customers.

The smart tokens are issued by the smart token issuer in a dormant form When a customer of the smart token issuer wishes to issue an item containing a smart token, for example a smart card, for use by an end user, the smart token holds a PKI conversation with a central cryptographic encoder administered by the customer This causes a unique end user identifier from those issued by the smart token issuer to the customer to be issued by the encoder to the card The encoder will report in encrypted form to the smart token issuer that this identifier has been issued and on which customers behalf this was done No other information needs to be passed to the smart token issuer.

Subsequently, during each information providing service start up, for registration or for access to an already registered service the end user identifier will need to be transferred from the smart token to the service originator.

Note that it is the service originator or provider that is the customer of the smart token issuer in this case and not the end user directly The smart token issuer is then sent the time and date of the usage in encrypted form by the cryptographic encoder.

A fixed period after a unique identifier is first activated, it will be disabled by the smart token A smart token with a disabled identifier must be reactivated by the smart token issuer to allow continued use Normally, the smart token will be re-licensed before the unique identifier is disabled and the fixed period reset to run from the re- licensing date To ensure that the smart token is able to disable the unique identifier when necessary, the smart token is supplied with the current date and time every time it starts up communication with a cryptographic encoder to begin registration or request information transfer.

The use of the unique user identifiers in smart tokens is intended primarily to allow the smart token issuer to ensure that its smart token technology is not being illicitly used Due to the encrypted nature of the communications supported on the inventive method, it would be difficult for the smart token issuer to keep track of usage of the smart tokens without this feature However, the issue of a unique identifier to each smart token also safeguards the service providers against unauthorised access to services using fake smart tokens because these will have unissued, duplicated or out of date user identities.

In order to carry out the present invention, cryptographic encoders and smart tokens will be used In addition to providing an encryption engine, the cryptographic encoder will also carry out the function of managing the PKI hierarchy used to issue keys to the smart tokens Further, the cryptographic encoder will report to the smart token issuer when a smart token is used to subscribe to a new service and when a smart token is used to access a service.

Further, the cryptographic encoder will report to the originator or service provider the user identity when the service is newly subscribed to or accessed The originator or service provider may themselves be operating the cryptographic encoder and in this case reporting is straightforward Where the originator or service provider are not themselves operating the cryptographic encoder the reporting of the user ID may made directly to the originator or to the cryptographic encoder operator for forwarding to the originator as desired by the parties involved.

Finally, the cryptographic encoder must be able to add certificates to data for delivery to users and be able to accept and process certificates on recei ed encrypted data.

This may require encrypted data to be received, decrypted and authenticated and then re-encrypted and sent out together with a new certificate.

In practice, it will normally be the case that a number of originators providing services throug a number of cryptographic encoders will be providing services to users using smart tokens issued by a single smart token provider.

As a result, the cryptographic encoder will normally need to be able to receive an encrypted message from a key server operated by the smart card issuer in order to allow the issue of the smart token user I Ds to be synchronised and controlled.

The cryptographic encoder may use an attached computer such as a standard PC for data storage i required However, any such computer used for data storage by the cryptographic encoder must be suitably protected against cryptographic attack to preserve the integrity of the cryptographic encoder, for example by providing and storing information on the PC only in encrypted form, having no network links to the PC except those going through the encoder and physically controlling access to the PC.

In order to allow the operations of the cryptographic encoder to be managed, services to be provided and service definitions to be supplied to the cryptographic encoder, it will normally be necessary to have the cryptographic encoder arranged to receive instructions and supply information through its operators or the service originators Such communication should be through cryptographically secured connections in order to maintain the integrity of the cryptographic encoders.

A smart token is a software device operating on the hardware of the end user access device Usually, the smart token will be operating within dedicated hardware such as a smart card which can be physically removed from the rest of the end user access device.

The smart token must be capable of storing the unique user identity and must be able to store the service permissions for the end user It must also be able to set the permission policy for a service through the customers register It is not essential that the smart token will be able to directly support the necessary scripting language to allow the permissions policy to be set, but if it cannot, it must expose an A Pl so that an intelligent user access device can set and interrogate the permissions.

In the above description of smart cards it is indicated that the smart card is only a part of the end user access device.

It is possible to have a "dumb" user access device which simply comprises a serial port adaptor to enable the smart card to connect to the communications network and supplies it with a reference clock Such an arrangement is not inherently secure because it enables direct interrogation of the smart card and the recording of interactions with the smart card including their timing, so allowing cryptographic attack on the smart card However, such arrangements may be suitable in applications where the information supplied is not encrypted at all and the smart token is used only to certify the received information or where the carried information is encrypted but its value is very low or transient so that cryptographic attack on the smart card to allow decryption of the received information would not be cost effective.

In order to protect the smart card against cryptographic attack, the user access device will normally include a smart interface device which prevents cryptographic attack on a smart card itself.

As is explained above, the information transfer method of the invention is a two-way process able to support information flowing in both directions Accordingly, it should be understood in the above description that, in general, references to the cryptographic encoder, encryption engine and smart tag should be understood as including the ability to both encrypt and decrypt information as required to support a bidirectional secure information flow Of course, in practice any specific service or the hardware used to provide or access the service may only support information flow in a single direction for some or all parts of the service.

It will be understood by the person skilled in the art that processes such as encryption, decryption, information management or information storage may be carried out using single or multiple units and the functional definitions and descriptions contained herein should not be understood as implying that any particular organisational or physical arrangement is required.

The above description relates to specific examples of invention and the person skilled in the art will understand that various modifications and changes can be made within the scope of the present invention.

Claims (14)

Claims

1 A communications method for communicating between first and second encryption devices in which a distribution mechanism for each of three elements of a communications flow in each direction between the encryption devices is stored by the first encryption device, the three elements of the communications flow being an access control element, an information content element and a verification element an-d each distribution mechanism defining the following parameters:

means of distribution; minimum required bandwidth; maximum permitted bandwidth; maximum permitted latency; minimum cryptographic strength; acceptable cryptographic algorithms; hierarchical parent; source specification; destination specification; wherein, before communication can take place the first and second encryption devices negotiate to establish a set oc parameters for the communications flow which can be supported between the devices and comply with the distribution mechanism stored by the first device and if a set of parameters is established the first device allows communication between the devices using the established set of parameters.

2 A communications method according to claim 1, in which the established set of parameters are stored by the firs:

39 - device and used for subsequent communications between the devices.

3 A communications method according to claim 2, in which before a subsequent communication takes place the devices negotiate to confirm that the established set of parameters can still be supported between them, and after this has been continued the first device allows communications between the devices using the stored established set of parameters.

4 A communications method according to claim 7, in which the some of the parameter values in the stored established set of parameters are ranges of parameters and before a subsequent communication takes place the devices negotiate to establish which parameter values in the ranges will be used for that communication.

A communications method according to claim 4, in which before a subsequent communication takes place the devices negotiate to confirm that communication according to the established set of parameter values can still be supported between them and to establish which parameter values in the ranges will be used for that communication.

6 A communications method according to any preceding claim, in which a distribution mechanism not required for a particular communication is assigned a null value and not further defined.

7 A communications method according to any preceding claim, in which the information content element is in an encrypted form during communication.

8 A communications method according to claim 7, in which the access control element includes at least one encryption key to allow decryption of the information content element.

9 A communications method according to any one of claims 1 to 7, in which the verification element includes encrypted information derived from the information content element.

A communications method according to claim 9, in which the access control element includes at least one encryption key to allow decryption of the verification element.

11 A communications method according to any preceding claim, in which a further parameter of each distribution mechanism is defined, this further parameter being the number of separate communications routes used for communications between the encoder and smart token.

12 A communications method according to any preceding claim, in which the first encryption device is a cryptographic encoder.

13 A communications method according to any preceding claim, in which the second encryption device is a smart token.

14 A communications method according to any preceding claim in which, instructions are stored by the first device as to what action should be taken if no set of parameters which can be supported between the devices and comply with the distribution mechanisms is established, and if no set of parameters is established, the first device carries out the instructions.

A communications method according to any preceding claim in which, if no set of parameters which can be supported between the devices and comply with the distribution mechanism is established the first device does not allow communications between the devices.