GB2411554A

GB2411554A - Selecting encryption methods for secure transmission

Info

Publication number: GB2411554A
Application number: GB0404114A
Authority: GB
Inventors: Russell John Haines
Original assignee: Toshiba Research Europe Ltd
Current assignee: Toshiba Europe Ltd
Priority date: 2004-02-24
Filing date: 2004-02-24
Publication date: 2005-08-31
Anticipated expiration: 2024-02-24
Also published as: GB0404114D0; GB2411554B

Abstract

The present invention provides a method of providing a secure communications link comprising receiving a request for a secure communications link, selecting one of a plurality of predetermined encryption methods for communicating over said link dependent on security level data, and establishing said communications link using said selected encryption method. The security level data may comprise information relating to the sensitivity of the data to be transmitted and the processing capability of the requesting unit and receiving unit. The security level data may alternatively comprise a parameter generated from this information. The information or parameter may be sent with the request, or sent later on request. Processing is carried out in security modules located in the transmitter and receiver, or at an intermediate node.

Description

241 1 554 Multi-rate Securitv

Field of the Invention

The present invention relates to communication devices and methods of establishing and transferring data over secure communication links within a network of such devices, and is particularly but not exclusively concerned with secure wireless communication links between such devices.

Background of the Invention

The problems of establishing a secure communications link between two devices or parties are well known. Typically encryption is used to render communications between the two devices unintelligible to anybody else having access to these. One of the difficulties however, is that the two devices will not know or share a common encryption key so that they must somehow establish an agreed encryption system first, before encrypting the exchange of messages. This initial exchange however is vulnerable to a third party listening, and could ultimately result in the third party obtaining the agreed key and therefore being able to interpret the encrypted messages.

A further difficulty is that some of the encryption methods used are not particularly strong such that even if a third party does not intercept the original handshaking messages to agree on the shared key, it may be subsequently possible for this third party to intercept encrypted messages and from this determine the shared key and therefore interpret the encrypted messages. To take this further, the third party may be more than merely passively listening to the messages but may pretend to be a member of the "secure" network established using this shared key and interfere with its operation. A well know encryption protocol used with wireless devices to form various "secure" wireless networks such as IEEE802. 11 wireless LANs for example, is the IEEE 802.11 WEP or Wireless Encryption Protocol. In this protocol the initialization vector or public key is too predictable and not sufficiently random, and the header information including the addresses of the terminals in the network is sent without encryption. As a result, after a minimal period of "sniffing" the network and intercepting packets, a good picture of the network can be built up with sufficient information to gain access.

Various alternative encryption protocols are also known for example using stronger public keys. Another alternative is to provide each device with a shared key but not over the easily monitored wireless network. For example using a smart card input to each device or keypad entry by a user. However such methods are often impractical and require significant user input which is counter to the automatic network establishment aims of many wireless network systems.

US Patent application no. 20020186846 describes a method for ensuring transmission security between two communication devices over a short range of wireless networks.

After a key exchange stage first and second check strings are formed, each string being based upon a short random number and on the generated encryption key. The security of the connection is supposedly confirmed by the correspondence of the check strings.

However, a third party can intercept the key during the key exchange, it will be able to impersonate one of the devices and return a check string, or simply eavesdrop on the communication.

US Patent no. 5241599 describes a cryptographic protocol for secure communications in which two parties sharing an insecure password bootstrap a secure system over an insecure network. The method involves generating a series of random challenges between the parties to verify the security of a randomly generated key. The method of this reference involves only two parties and one communication link. This single link may be compromised as described above.

US 2003005331 discloses a network which attempts to prevent unauthorised users from gaining access to confidential information. The network has various work stations and service connected by a common medium and through a router to the Internet. The network has two major components, a network security centre (NSC) and security network interface cards or devices. The NSC is an administrative work station through which the network security of ricer manages the network as a whole, as well as the individual security devices. The security devices are interposed between each work station, including the NSC, and the common medium can operate at a network layer (layer 3) of the protocol hierarchy. The network allows trusted users to access outside information, including the Internet, or stopping outside attackers at their point of entry.

At the same time, the network limits an unauthorized insider to information defined in their particular security profile. The user may select which virtual network to access at any given time. The result is trusted access to multiple secure virtual private networks (BPN), or from a single desktop machine.

WO 0045241 discloses consumer communications devices such as IP telephony adaptors to self generate public key pairs and certificates. This eliminates the need for such keys and certificates to be sent to the devices from an outside source so a single trust approach can be maintained. A manufacturer's certificate is installed into a device at the time of manufacture. The device only issues itself certificates based on a signed request from an external outside server. The device's self issued certificate incorporate information obtained from the server in a profile. This allows control by the server over a device's self issued certificate. In order to prevent tampering and breaking, of the self issued certificates, the certificate issuing process occurs within a secure microprocessor.

"Multi-modal Verification for Tele-services and Security Applications (M2VTS)" by Richard et. al. in Multimedia Computing and Systems, 1999, IEEE International Conference on 06/07/1999 - 06/11/1999 'Inspec Excession no: 6338548, addresses the issue of secured access to local and centralised services in a multimedia environment.

The aim is to extend the scope of application of network based services by adding novel and intelligent functionalities, enabled by automatic verification systems combining multi-modal strategies, secured access based on speech, image or other information.

The project aims to show that limitations of individual technologies (speaker verification, frontal phase authentication, profile identification, etc) can be overcome by relying on multi-modal decisions that is a combination or fusion of these technologies.

Summary of the Invention

In general terms in one aspect the present invention provides a method of establishing a secure communications link between two communications devices in which one of a number of encryption methods can be used. Which encryption method will be used will depend on a number of factors, including how secure the communications link needs to be, and the processing capabilities of the two devices. For example, the more secure an encryption method is typically the more processing power that is required by the devices using it. In addition, not all communications links will require a high level or degree of security and this will generally depend on the particular application the secure communications link is used for. For example, content streaming such as audio or data packets may not be considered particularly "secret" and in addition would suffer from the latency introduced by a high level or very secure encryption method. Therefore such applications may benefit from a low level of security. By contrast, system or network administration control instructions may require a high level of security so that these are not intercepted or "faked" by third parties. It is also likely that such commands would not suffer significantly from the high levels of latency introduced by utilising an encryption system with a high degree of security.

This method therefore provides a way of tailoring the security level of a secure communications link to the application that is using it. This has a number of advantages over known methods in which a one size fits all approach is taken with communications links between devices just having one level of security; for example the relatively low level of security of the WEP method which increases the risk of interception and interference by third parties on the network, or at the other extreme a quantum cryptography implementation which though very secure requires significant processing resources. Thus there is provided a much more efficient mechanism for establishing and transferring "secure" data across secure communications links between devices. This is particularly advantageous for secure wireless networks as such networks will typically serve a wide variety of applications having widely varying security requirements and additionally widely varying processing and power or battery resources.

In particular in a first aspect the present invention provides a method for providing a secure communications link to a first communications device, the method comprising receiving a request from a second communications device for a secure communications link, selecting one of a plurality of predetermined encryption methods for communicating further dependent on automatically determined security level data, and establishing the communications link with the second communications device using the selected encryption method.

The automatic means for determining the security level data includes sending this or a part of this from the second device to the first device with the request for a secure connection. Alternatively or additionally this could be determined by an agent associated with the first device which interrogates the second device, and in some implementations the first device as well.

The security level data comprises one or more of the following group: a minimum encryption level corresponding to the purpose of said link; the processing resources of one or both apparatus party to the link; the memory resources of one or both apparatus party to the link; the battery resources of one or both apparatus party to the link. In some embodiments this can then be used to generate a security level parameter, for example a numerical value or range. This can be achieved using the above data (which can itself be in the form of numerical values and ranges, and applying this to a predetermined algorithm. The parameter is then used to select an encryption level having a corresponding value or range. Alternatively, the security level data may simply comprise a security level parameter which can then be used directly in the selection.

The security level parameter is essentially a score derived from security related requirements and resources related information. The particular way in which such a score is calculated is very implementation specific. Similarly the way in which the security requirements and resources information is determined is very implementation specific.

However as an example a score out of 10 may be allocated to each of: application minimum security requirement; processing/memory resources of device A and device B; battery resources of device A and device B.; each applied in a predetermined known and agreed manner, and then applied to a predetermined algorithm to determine the security level used: Security level (1-7) = min.req. + f(proc A; proc B.; bait A; ball B) The function f may be one of a number used depending on the values of its input parameters, for example either halt A or ball B being below 2 may result in zero being added to min.req, and if below this may result in a negative number.

In a more sophisticated example an internet browser application intends to set up a secure "https" end-to-end connection (for example, to permit the user to perform online banking or to make a secure purchase from a website). Once the end-to-end https connection has been established, then the requirements for a secure link are reduced, as the traffic is encrypted at a higher level anyway. However, during establishment, there could be a requirement for enhanced security to protect the exchange of set-up information.

A means for calculating the security level parameter employs fuzzy sets as described in Zadeh, L. A., "Fuzzy Sets", Information & Control, Vol. 8, 1965, pp. 338-353. In this implementation the security requirements (of applications and any intervening layers) are expressed as a fuzzy value (i.e. given upper and lower bounds of acceptability), then standard fuzzy logic arithmetic can be used to combine these values to provide a value which can be used to index into a list of security levels. If the required level of security is unavailable (due to platform constraints), this is indicated to the application (which could choose to either continue with whatever is available, or to abandon the attempt and inform the user).

Note that with intermediate or intervening layers the application may not be the only "stakeholder"; for example, in addition to the internet browser there could be a VPN application in another layer encrypting the link to the far end. This actually reduces the encryption requirements compared to what the browser requires, because the VPN has already satisfied some or all of the security requirements. Also, there could be parallel applications (multiple browser windows; email clients; FTP sessions; file downloads) with different requirements, but these all have to go over one radio link, so need to be encrypted either differently on a packet-by- packet basis depending on the payload, or the link needs to cater for the most sensitive application.

Fuzzy logic is preferred rather than simple arithmetic because this is inherently a subjective and intangible calculation. In the above example of the internet browser, and assuming a unitary security level parameter (i.e. in the range 0 to 1) if an application gives it's security requirements as (0.6 0.8), this indicates a fairly high degree of security is required (between 60 and 80% of the highest level of security available).

Fuzzy logic also allows these upper and lower bounds to be given a degree of certainty, so as to indicate that the values given are not hard-andfast cut-off thresholds, so these example values could be further "fuzzified" to (0.6 (0.8 1.0) to indicate that the lowest requirement truly is 0.6, but the upper bound could be anywhere up to 100% of security.

The lower bound can also be further "fuzzified".

Once the "https" session has been established, the application could then indicate its revised security requirements, for example (0 0.3), which would cause the security manager to re-evaluate its configuration.

Preferably the predetermined encryption methods will include at least the IEEE 802.11 WEP method, as well as other more secure methods such as for example IEEE 802. 1X and IEEE 802. 111. Various other secure methods may be used such as elliptic curve cryptography and quantum cryptography for example.

The communications link is preferably a wireless network such as Bluetooth or an member of the IEEE 802.1 1 family of standards, such as a, b, g, e and n for example.

Various handshaking protocols could be used to implement the above methods, and examples of these will be described in more detail below.

In particular in a second aspect the present invention provides an apparatus for providing a secure communications link in a first communications device, the apparatus comprising: means for receiving a request from a second communications device for a secure communications link; means for selecting one of a plurality of predetermined encryption methods for communicating over the link depending on a security level parameter; and means for establishing the communications link with the second communications device using the selected encryption method.

In particular in a third aspect the present invention provides a method of providing a secure communications link for a first communications device, the method comprising: sending a request to a second communications device for a secure link; sending security level data in order to enable selection of one of a plurality of predetermined encryption methods dependent on said data; and establishing the communications link with the second device using the selected encryption method.

The security level data may be sent with the request or upon receipt of a specific request from the second communications device.

In particular in a further aspect the present invention provides a method of providing a secure communications link for a first communications device, the method comprising sending a request to a second communications device for a secure communications link; selecting one of a plurality of predetermined encryption methods for communicating over the link dependent on security level data; and establishing the communications link with the second communications device using the selected encryption method.

The security level data may include data relating to processing capabilities and battery status for example of the second communications device, as well as requirements of an application requesting the secure link and the capabilities and status of the first device.

In a further aspect the present invention provides a method of providing a secure communications link for a first communications device, the method comprising: receiving a request from a second communications device for a secure communications link; sending security level data in order to enable selection of one of a plurality of predetermined encryption methods dependent on said data; and establishing the communications link with the second communications device using the selected encryption method.

There are also provided computer programs for implementing the abovedefined methods on the first and second communications devices. In particular there is provided a computer program product containing said computer program. The computer program product may be a storage device such as a CD ROM or a transient signal supporting an Internet download for example.

The present invention also provides corresponding apparatus having means for implementing the various method steps defined above. Various means will be known to those skilled in the art and a wide variety of implementation options could be used, for example logic circuits, ASIC's, FPGA's, Micro controllers and Digital Signal Processors.

Brief Description of the Drawings

Embodiments will now be described in detail with reference to the following drawings, by way of example only and without intending to be limiting, in which: Figure 1 illustrates a known method of establishing a secure communications link over a Figure 2 shows a method of establishing a secure communications link over a wireless network according to an embodiment; Figure 3 shows a process for establishing an encryption method for use in establishing the secure communications link in Figure 2; Figure 4 illustrates a process for requesting a secure communications link according to an embodiment; Figure 5 illustrates an example of handshaking process according to an embodiment; Figure 6 illustrates a further example handshaking process according to an embodiment; Figure 7 illustrates a security controller according to an embodiment; and Figure 8 shows a process flow diagram for the security controller of Figure 7.

Detailed Description

Figure 1 shows a known method of establishing a secure communications link over a wireless network such as a Bluetooth personal area network (PAN). The network comprises a first and second communications device (A and B respectively), for example a Bluetooth enabled desktop computer A and a Bluetooth enabled mobile phone B. The second communications device B requests a secure communications link with the first communications device A using an unencrypted request message. In response, the first communications device A generates a public key KapU and a corresponding private key Kapr. The public key KapU is sent across the wireless network to the second communications device B which also generates its own private key Kbpr.

The second communication device also provides a secret message M comprising other data which it wishes to forward to the first communications device A over a secure encrypted communications link.

Upon receiving the public key Kapu from the first communication device A, the second communications device B encrypts its own private key Kbpr with the public key KapU to provide a first encrypted or secure message KapU(Kbpr). In addition the second communications device B encrypts the message M with its own private key Kbpr to produce the encrypted message Kbpr(M), which in turn is encrypted using the public key KapU to produce a second secure message KapU(Kbpr) which is sent with the first encrypted message KapU(Kbpr(M)) over the wireless communications link.

The first communications device A receives the two encrypted messages and de- encrypts them using its own private key Kapr to obtain the second communications device's private key Kbpr and the message encrypted with this key Kbpr(M). Having retrieved this key Kbpr, the message M can then be de-encrypted. Further messages M, can then be forwarded by the second communications device B to the first communications device A using these two keys - the public key Kapu and the second device's private key Kbpr. Depending on the protocol used, messages sent from the first communications device A to the second communication device B may also be encrypted using these two keys and sent across the wireless network.

In each case of key generation (KapU' Kapr and Kbpr), a predetermined encryption method will be used. For example this might be a level of security similar to the IEEE 802.11 WEP mechanism or the integral Bluetooth _ security mechanism using a hard coded value or user entered PIN, or a more robust method requiring additional processing and/or overhead.

It has been recognised that one encryption method is not well suited to all circumstances, and that a multilevel or multi-rate security provision is desirable.

Figure 2 shows a first embodiment comprising a first communications device A' having a selector 2, and a second communications device B' having a security level module 3.

The second communications device B' sends a request to the first communications device A' for a secure communications link. The request additionally includes a security level parameter generated by the security level module 3, this parameter may be based on a number of factors, including for example how securely the application wants the message to be protected, the type of message M to be sent across the secure link, as well as the processing power or resources available within the device B' to process the encryption algorithms. This last factor may be effected by the battery resources available in the second communications device B'. Other factors such as the latency required by the particular application requiring the transfer of the message M may also be considered as a factor. Also what the processor and memory resources currently are involved in, for example if the user is currently watching a video clip on the device, that could be hammering the resources, which would constrain what the terminal is capable of doing.

Different security level parameters may be associated with different types of applications such as content streaming, commands to interfere with the system and data controlling access to a system, volume level changes or game controller commands.

Thus the security level parameter provides information on how sensitive the content in the stream or message M to be sent across the network is, and preferably also includes information on the capabilities of the second communications device B' in terms of its ability to handle various encryption methods.

The request and security level parameter are received by the first communications device A', and the security level parameter is recognised by the selector 2, and utilised to determine which one of a number of encryption methods or protocols should be used for the secure link across the network. Based on this selection, a public key KapU and private key Kapr are generated as described with respect to figure 1. However the complexity of the keys Ka will be dependent on the encryption method selected by the selector 2. As with Figure 1, the public key KapU is forwarded across the network to the second communications device B' which uses this to encrypt its own private key Kbpr and a message M encrypted with this private key Kbpr(M) to produce encrypted messages Kapu(Kbpr(m)) and KapU(Kbpr) which are then sent securely across the network to the first communications device A'. The first communications device A' in turn de- encrypts the two received encrypted messages using its own private key Kapr to obtain the private key Kbpr of the second communication device B' and then using this to de- encrypt the message M. Figure 3 illustrates the method of the selector 2 which receives the security level parameter and from this determines an appropriate level of encryption protection 4.

Three levels of encryption protection are shown, IEEE 802.11 WEP (Level 1) , IEEE 802.1X (Level 2), and an elliptical curve based cryptography encryption method (Level 3). The selection of an encryption method 4 may be constrained by other information sent as part of the security level parameter such as the capabilities of the second communications device B', as well as the capabilities of the first communications device A'. Thus the selection preferably depends on both the level of sensitivity of the data M to be transferred across the secure link, as well as the capabilities of one or both of the communications devices A' and B'. For example in a low sensitivity stream from or to a simple device, a simple encryption technique such as the IEEE 802.1 I WEP standard with a short length key, or perhaps even no security at all might be used. By contrast for a highly confidential stream from and to a complex device, a more complex encryption technique might be implemented, such as those being promoted by the IEEE 802.1X and IEEE 802.111 working groups.

Therefore, rather than having to design the security of the system such that it caters for the lowest common denominator device (and thereby compromising security), or proposing a robust security system that precludes simple devices and leads to an incomplete system, the configurable embodiment approach enables this trade-off to be made on each individual case. The embodiment therefore more efficiently handles the potentially large different requirements regarding the value of data sent around the system, and the large differences in capabilities of the devices forming part of the system or network. For example simple remote controllers and speakers may form part of the same wireless LAN as complex computers and set-top boxes. This range of devices clearly having massively different capabilities and needs in terms of security transferring data.

The embodiment also permits the system to consider factors such as the battery life of the devices involved in the stream or data transfer such that the selection of an encryption scheme may be dependent on the battery level of one or both of the devices involved. Furthermore, the type of network used may also be a factor such that a relatively narrow band communications link may affect the choice of encryption algorithm.

The embodiment may also be enhanced to dynamically reconsider these factors, perhaps in order to downgrade the security level if battery life is below a threshold.

Figure 4 illustrates the process of the security level module 3 which intercepts the standard request for a secure connection and determines the security level parameter based on various factors as discussed above, for example including the sensitivity of the information to be transferred over the secure link and the capabilities and battery level of the second communications device B'. These sources of information are incorporatedinto the security level parameter in a predetermined way to generate a parameter according to a predetermined format which is recognisable by the selector 2 of the first communications device A'. The security level module 3 then forwards the intercepted request along with the security level parameter.

The security level parameter may simply be an additional packet formatted in a particular way to illustrate the information sensitivity level, the capabilities of the device B' and its current battery level. This may be according to a "score" out of 10 or some similar simple measure such as the (0 1) range in the fuzzy logic example earlier, or may comprise more sophisticated information such as a series of scores for each of a series of predetermined categories such as desired security by application, battery resources of first and second devices, processing capabilities of both devices and memory resources of both devices. These various weights can then be added together in a predetermined fashion (for example, using fuzzy arithmetic) to determine a final security level parameter which is used to select an encryption algorithm corresponding to this final score.

Figures 5, 6, 7 and 8 illustrate an alternative embodiment in which the security level parameter for the choice of encryption algorithm is determined by negotiation between the pair of communicating devices B' and A'. Figure 5 illustrates a handshaking protocol between two devices A' (a home entertainment system) and a second device B' (a television) both having high processing capabilities, a large amount of memory available, and a good battery status (perhaps equivalent to being mains power supplied).

Furthermore the application sensitivity of the data to be transferred is considered high.

The initial part of the protocol involves the requesting device B' requesting a secure link from the receiving device A' utilising standards IEEE 802.11 WEP authentication handshaking.

An overview of this will be similar to the process described with respect to Figure 1 above. The particulars of this authentication and handshaking procedure will be available to those skilled in the art from the IEEE 802. 11 standard specification. This part of the procedure results in a communications link secured using the IEEE 802.11 WEP standard. On establishment of this moderately secure link, an exchange of security requirements takes place between the two communications devices A' and B', which is used to select an appropriate encryption technique if a more secure communications link is required.

This exchange of security information may involve the transfer of a security level parameter as described with respect to the previous embodiment, or as described below in more detail may utilise a security controller which negotiates a suitable security level between the two devices A' and B'.

If the security level parameter is such that a high level of security is required, then the exchange of keys KapU and Kbpr generated by a higher level encryption method is performed as described with respect to Figure 2, but over the WEP protected secure link. Thus two levels of encryption are used. Further levels of encryption may also be used, the exchange of keys taking place over increasingly secure links. Alternatively there may be just one "jump" from the WEP protected link to a highly secure link, with the exchange of keys for that highly secure link taking place over the WEP secured communications link.

Figure 6 shows a second example in which a remote controller B' and a television A' form a secure wireless link. In this case the remote controller has low processing and memory capabilities and the information it transfers to the television is of low sensitivity such that WEP protection is sufficient for data exchange between the two devices A' and B'. In a further alternative, there may even be no need for WEP protection of the secure link, and an unsecured link may be deemed sufficient.

Similarly it may be deemed that the level of protection or security of the link requested by the requesting device B' is too high for its capabilities such that a lower level of security or encryption sophistication is used. In this case the requesting device B' may refuse to exchange its data over this less than the requested security level.

Figure 7 shows the architecture of a security controller 5 which negotiates with the two communicating devices A' and B' to determine an appropriate security algorithm 4a to 4x for securing a communications link between them over the network. The security controller 5 may be located in either device A' or B', or may be distributed in some fashion across the system illustrated in Figure 2 for example. The security controller 5 is analogous to the selector 2 and security level module 3 in Figure 2, but provides a more sophisticated level of determining a security level parameter which can be used to determine inappropriate security algorithm 4. Thus the security controller 5 may request and receive information relating to the sensitivity of the data to be exchanged, the capabilities of the communicating devices and their current battery status. On the basis of this information, the security controller 5 will be able to determine the complexity of the security algorithm 4 that the devices will be able to use. This may be achieved during device registration or as described above when an initial secure (e.g. WEP protected) link is established. The security controller 5 may determine that one or both of the devices is too constrained and/or that the data is of such low value that it is not worth protecting, such that no level of security protection is established and data exchange between the devices is not encrypted.

Figure 8 illustrates a process flow diagram for the security controller 5. The system could establish minimal security (e.g. 802.1 1 WEP) then go straight to the final level of security, or it could go through one or more intermediate levels. The later is more secure on the basis that any casual listener would not be able to monitor the key exchanges of the final security mode. In the first step, the security controller sends authentication and handshaking packets, for example both corresponding to the IEEE 802.1 1 authentication and WEP handshaking standards. The controller process 5 then awaits receipt of corresponding authentication and handshaking packets from the requesting device B', then sends a request for information on security requirements and capabilities such as the sensitivity level of the information to be exchanged in the processing and memory capabilities of the requesting device. This request is sent using a "weak" encryption protocol such as 802.1 1 WEP. This information is received by the controller and enables it to determine whether an increased level of security is required.

If this is the case, then the security requirements and capabilities received from the requesting device B' are used to determine an appropriate security algorithm. The controller 5 then determines whether the chosen algorithm is sufficiently secure for the intended application and if not warns the requesting device. This situation may occur where the data is highly sensitive but the distinct device has insufficient resources to process the required encryption algorithm. If the chosen algorithm is sufficient, the controller initiates an authentication handshake for the chosen algorithm which will involve generating the public and private keys and forwarding the public key to the requesting device for use in encrypting the data to be exchanged.

Whilst the embodiment has been described with respect to wireless networks, they are also suitable for use with other types of networks such as the Internet, LAN's, free space optical networks, as well as cable based networks.

The skilled person will recognise that the above-described apparatus and methods may be embodied as processor control code, for example on a carrier medium such as a disk, CD- or DVD-ROM, programmed memory such as read only memory (Firmware), or on a data carrier such as an optical or electrical signal carrier. For many applications embodiments of the invention will be implemented on a DSP (Digital Signal Processor), ASIC (Application Specific Integrated Circuit) or FPGA (Field Programmable Gate Array). Thus the code may comprise conventional programme code or microcode or, for example code for setting up or controlling an ASIC or FPGA. The code may also comprise code for dynamically configuring re-configurable apparatus such as re- programmable logic gate arrays. Similarly the code may comprise code for a hardware description language such as Verilog _ or VHDL (Very high speed integrated circuit Hardware Description Language). As the skilled person will appreciate, the code may be distributed between a plurality of coupled components in communication with one another. Where appropriate, the embodiments may also be implemented using code running on a field-(re)programmable analogue array or similar device in order to configure analogue hardware.

The skilled person will also appreciate that the various embodiments and specific features described with respect to them could be freely combined with the other embodiments or their specifically described features in general accordance with the above teaching. The skilled person will also recognise that various alterations and modifications can be made to specific examples described without departing from the scope of the appended claims.

Claims

CLAIMS: 1. A method of providing a secure communications link comprising:

receiving a request for a secure communications link; selecting one of a plurality of predetermined encryption methods for communicating over said link dependent on automatically determined security level data; establishing said communications link using said selected encryption method.
2. A method according to claim 1 wherein the security level data is sent with said request.
3. A method according to claim 1 wherein the security level data is requested and received following said request for a secure communications link.
4. A method according to any one preceding claim wherein said security level data comprises one or more of the following group: a minimum encryption level corresponding to the purpose of said link; the processing resources of one or both apparatus party to the link; the memory resources of one or both apparatus party to the link; the battery resources of one or both apparatus party to the link.
5. A method according to any one preceding claim wherein the security level data comprises a security level parameter having a value corresponding to the selected encryption method.
6 A method according to claim 4 wherein the security level data is expressed using arithmetic values which are then combined as a weightedsum to produce a security level parameter.
7 A method according to claim 5 wherein the security level data is expressed using fuzzy logic values which are then combined using fuzzy arithmetic to produce a security level parameter comprising a range.
8. A method according to any one preceding claim further comprising establishing a security level data link using an initial encryption method, and communicating at least some of said security level data over said link prior to said selecting.
9. A method according to claim 8 further establishing intermediate encryption methods in a cascade, exchanging data in order to establish a more secure encryption method until the selected encryption method is established.
10. A method according to any one preceding claim wherein said establishing comprises generating asymmetric private and public keys according to said selected encryption method and transmitted said public key.
11. A method according to any one preceding claim wherein said encryption methods comprises one or more of the following group: EKE 802.11 WEP; Bluetooth_ integral security scheme; IEEE 802.1X; EEE802.1 1I.
12. A method according to any one preceding claim wherein said communication link is a wireless Bluetooth TM or IEEE 802.11 link.
13. A program carrier comprising a program which when run on a processor is arranged to carry out a method according to any one preceding claim.
14. Apparatus for providing a secure communications link comprising: means for receiving a request for a secure communications link; means for automatically determining security level data and means for selecting one of a plurality of predetermined encryption methods for communicating over said link dependent on said security level data; means for establishing said communications link using said selected encryption method.
15. Apparatus according to claim 14 wherein the receiving means is arranged to receive the security level data with said request.
16. Apparatus according to claim 14 wherein the security level data determining means is arranged to request and receive said data following said request for a secure communications link.
17. Apparatus according to any one of claims 14 to 16 wherein said security level data comprises one or more of the following group: a minimum encryption level corresponding to the purpose of said link; the processing resources of one or both apparatus party to the link; the memory resources of one or both apparatus party to the link; the battery resources of one or both apparatus party to the link.
18. Apparatus according to any one of claims 14 to 17 wherein the security level data comprises a security level parameter having a value corresponding to the selected encryption method.
19. Apparatus according to any one of claims 14 to 18 further comprising means for establishing a security level data link using an initial encryption method, and means for communicating at least some of said security level data over said link prior to said selecting.
20. Apparatus according to claim 19 further comprising means for establishing intermediate encryption methods in a cascade in order to exchange data in order to establish a more secure encryption method until the selected encryption method is established.
21. Apparatus according to any one of claims 14 to 20 wherein said means for establishing said communications link using said selected encryption method comprises means for generating asymmetric private and public keys according to said selected encryption method and transmitted said public key.

21. Apparatus according to any one of claims 14 to 20 wherein said means for establishing said communications link using said selected encryption method comprises means for generating asymmetric private and public keys according to said selected encryption method and transmitted said public key.

Amendments to the claims have been filed as follows CLAIMS: 1. A method of providing a secure communications link between two apparatus, the method comprising: receiving a request for a secure communications link; selecting one of a plurality of predetermined encryption methods for communicating over said link dependent on security level data comprising a level of security for the communications link and the processing capabilities of a said apparatus; and; establishing said communications link using said selected encryption method.

2. A method according to claim 1 wherein the security level data is sent with said request. ' 3. A method according to claim 1 wherein the security level data is requested and received following said request for a secure communications link.

4. A method according to any one preceding claim wherein said processing, 4, capabilities comprises one or more of the following group: the processing resources of one or both apparatus party to the link; the memory resources of one or both apparatus party to the link; the battery resources of one or both apparatus party to the link.

5. A method according to any one preceding claim wherein the security level data comprises a security level parameter having a value corresponding to the selected encryption method.

6 A method according to claim 4 wherein the security level data is expressed using arithmetic values which are then combined as a weightedsum to produce a security level parameter.

7 A method according to claim 5 wherein the security level data is expressed using fuzzy logic values which are then combined using fuzzy arithmetic to produce a security level parameter comprising a range.

8. A method according to any one preceding claim further comprising establishing a security level data link using an initial encryption method, and communicating at least some of said security level data over said link prior to said selecting.

9. A method according to claim 8 further establishing intermediate encryption methods in a cascade, exchanging data in order to establish a more secure encryption method until the selected encryption method is established.

10. A method according to any one preceding claim wherein said establishing comprises generating asymmetric private and public keys according to said selected encryption method and transmitted said public key.

11. A method according to any one preceding claim wherein said encryption, methods comprises one or more of the following group: IEEE 802.11 WEP; . Bluetooth_ integral security scheme; IEEE 802.1X; EEE802. 111. ' 12. A method according to any one preceding claim wherein said communication, , link is a wireless Bluetooth _ or IEEE 802.1 1 link.

13. A program carrier comprising a program which when run on a processor is arranged to carry out a method according to any one preceding claim.

14. Apparatus for providing a secure communications link comprising: means for receiving a request for a secure communications link with another apparatus; means for selecting one of a plurality of predetermined encryption methods for communicating over said link dependent on security level data; means for establishing said communications link using said selected encryption method; and wherein the security level data comprises a level of security required for the communications link and the processing capabilities of a said apparatus.

15. Apparatus according to claim 14 wherein the receiving means is arranged to receive the security level data with said request.

16. Apparatus according to claim 14 wherein the security level data determining means is arranged to request and receive said data following said request for a secure communications link.

17. Apparatus according to any one of claims 14 to 16 wherein said comprises one or more of the following group: the processing resources of one or both apparatus party to the link; the memory resources of one or both apparatus party to the link; the battery resources of one or both apparatus party to the link.

18. Apparatus according to any one of claims 14 to 17 wherein the security level data comprises a security level parameter having a value corresponding to the selected encryption method.

19. Apparatus according to any one of claims 14 to 18 further comprising means for establishing a security level data link using an initial encryption method, and means for communicating at least some of said security level data over said link prior to said selecting.

20. Apparatus according to claim 19 further comprising means for establishing intermediate encryption methods in a cascade in order to exchange data in order to establish a more secure encryption method until the selected encryption method is established.