WO2005057842A1

WO2005057842A1 - A wireless lan system

Info

Publication number: WO2005057842A1
Application number: PCT/NZ2004/000313
Authority: WO
Inventors: Abbas Bigdeli; Ankit Sharma; Simon James Graham
Original assignee: Auckland Uniservices Limited
Priority date: 2003-12-11
Filing date: 2004-12-07
Publication date: 2005-06-23

Abstract

A wireless LAN system 10 comprises a wireless network 20 communicating with a wired network 12 via an access point 24. The system 10 includes an encryption/decryption bridge 26 arranged between the access point 24 and the wired network 12, the bridge 26 encrypting data transmitted from the wired network 12 to the wireless network 20 and decrypting data transmitted from the wireless network 20 to the wired network 12. A key management module ahs a first part arranged on terminals 22 of the wireless network 20 and a second part arranged on a server 14 of the wired network 12, the key management module generating and distributing keys to the terminals 22 on the wireless network 20 and to the bridge 26.

Description

"A wireless LAN system"

Cross-Reference to Related Applications The present application claims priority from Australian Provisional Patent Application No 2003906892 filed on 11 December 2003, the contents of which are incorporated herein by reference.

Field of the Invention This invention relates to a wireless LAN (WLAN) system. More particularly, the invention relates to a WLAN system and to a method of communicating securely on a WLAN.

Background to the Invention WLANs facilitate communication between computers connected to the network without the inconvenience and cost of hardwiring the computers which requires installation costs for cabling and related infrastructure. The computers connected to a

WLAN communicate in a wireless manner via radio waves. Such radio waves can

"leak" into insecure areas being able to be propagated freely through building walls etc. There is therefore a need to protect against unauthorised access to the network and to ensure the integrity and security of data transmitted over the WLAN. WLANs currently use the IEEE 802.11 family of standards which makes use of the Wired Equivalent Privacy (WEP) security protocol. The aim of WEP is to make WLANs as secure as wired LANs. WEP provides confidentiality and authentication only to a limited extent as a result of inadequate key size and incorrect implementation. The encryption algorithm (RC4) used in WEP has serious flaws allowing an attacker to decipher WEP. A further problem with WEP is that all the users use the same key at all times to communicate through the network. If an attacker discovers this key, the attacker has free access to the WLAN. Thus, due to inadequate key management, WEP lacks strong authentication. More recently, the IEEE has introduced revised standards like the IEEE 802. lx to address weaknesses in the older standards. This later standard only addresses authentication issues. A new IEEE standard known as the IEEE 802.1 li will, when introduced, address a large number of WLAN related issues but will require an entire re-purchase or rebuilding of the WLAN with the resultant significant costs which will be unacceptable to many operators of existing WLANS. There are other proprietary solutions which include virtual private networks that are used to provide secure communications on a wireless LAN but this is an extremely costly solution which may not be affordable to many enterprises. In this specification, the term "wireless network" is to be understood as a radio- based system by which individual computer terminals, or client terminals, communicate wirelessly with a server which forms part of a wired network, the wireless network accessing the wired network via an access point.

Summary of the Invention According to a first aspect of the invention, there is provided a WLAN system comprising a wireless network communicating with a wired network via an access point, the system including: an encryption/decryption bridge arranged between the access point and the wired network, the bridge encrypting data transmitted from the wired network to the wireless network and decrypting data transmitted from the wireless network to the wired network; and a key management module having a first part arranged on terminals of the wireless network and a second part arranged on a server of the wired network, the key management module generating and distributing keys to the terminals on the wireless network and to the bridge. The bridge may be arranged between the access point and the server. It will be appreciated that the wired network could include wired terminals. In that case, if encryption of data to the wired terminals is not required, the bridge may be arranged downstream of the wired terminals immediately prior to the access point. If, however, encrypted communication is required between the server and the wired terminals, the bridge may be arranged downstream of the server but upstream of the wired terminals. The encryption/decryption bridge may be implemented in software on the client terminals. An Advanced Encryption Standard (AES) may be used in the encryption/decryption bridge. The encryption/decryption bridge may be implemented as one of a Field

Programmable Gate Array (FPGA), an embedded personal computer, or any other suitable computing device. The bridge may serve to decrypt data received from the wireless network and to encrypt data to be transmitted to the wireless network to maintain network throughput from the server. The bridge may contain an encryption/decryption core interposed between strippers/restorers. Thus, upon receipt of a data frame, a header and trailer of the frame may be stripped off by the stripper, the data frame sent to the core for decryption whereafter, in the following stripper/restorer, the header and trailer may be reapplied for onward transmission to the server. Unencrypted data from the server may be encrypted in a similar fashion but in the reverse direction. The core may be in the form of a processor running alongside an encryption/decryption engine. The bridge may have a throughput of at least half the speed of the WLAN. Thus, for a 100Mbps network the bridge may have a throughput of at least 50Mbps. The wireless network and the wired network may communicate with each other via a security protocol to provide confidentiality of data transmission. The security protocol may use an appropriate encryption algorithm which converts cipher text from the wireless network into plain text on the wired network. The security protocol may be of a type offering a high level of user transparency so that the security protocol requires minimal, if any, user input and provides minimal interference with a user's tasks on any terminal communicating over the wireless network. Thus, the security protocol may be one of Crypto IP Encapsulation (CIPE) and Simple Encryption Packet Protocol Layer (SEPPL). SEPPL, while specifically designed for WLANs, does not generate keys, hence the need for the key management module. SEPPL also has the advantage that it makes use of an operating system firewall to filter IP packets. The key management module may be configured to fully automate start up of the security protocol, to generate secure keys at regular intervals of time and to distribute the keys to all terminals and to the bridge in a transparent manner. The secure keys may be AES128 bit keys. As indicated above, the key management module may comprise two parts or programs, one running on each terminal of the wireless network (each terminal being referred to as the "client") and the other part running on the server of the network or any computer on the wired LAN (referred to as the "server"). The two parts of the key management module may communicate with each other using sockets which are programmable interfaces for a network and run over a TCP/IP layer. In order for the programs to communicate with each other, the "client" may initiate connection by sending an initial message to the server using the server's IP address and the TCP port number of the server program. Messages may then be freely exchanged between the two programs. The key management module may be configured to activate automatically when any terminal, or client, logs on to the wireless network. When this occurs, that client may receive the latest encryption key automatically and start the security protocol on that client. An RSA asymmetric encryption technique may be used to encrypt an initial key only and may be used for an initial exchange of keys between the terminal and a server. According to a second aspect of the invention, there is provided a method of communicating data over a WLAN, the WLAN comprising a wireless network communicating with a wired network via an access point, the method including: interposing an encryption/decryption bridge between the access point and the wired network, the bridge encrypting data from the wired network to the wireless network and decrypting data transmitted from the wireless to the wired network; and automatically generating encryption keys via a key management module having a first part arranged on terminals of the wireless network and a second part arranged on a server of the wired network, the keys being distributed to the components of the wireless network and to the bridge. The method may include implementing the encryption/decryption bridge in software on the terminals. The method may therefore include using an Advanced Encryption Standard (AES) in the encryption/decryption bridge. Further, the method may include implementing the encryption/decryption bridge as one of a Field Programmable Gate Array (FPGA), an embedded personal computer or any other suitable computing device. The method may include using the bridge to decrypt data received from the wireless network and to encrypt data to be transmitted to the wireless network to maintain network throughput from the server. The method may include interposing an encryption decryption core of the bridge between strippers/restorers. Thus, upon receipt of a data frame, the method may include stripping off a header and a trailer of the frame by the stripper, sending the data frame to the core for decryption and, in the following stripper/restorer, reapplying the header and trailer for onward transmission to the server. Unencrypted data from the server may be encrypted in a similar fashion but in the reverse direction. The method may include causing the wireless network and the wired network to communicate with each other via a security protocol to provide confidentiality of data transmission. The method may include using an encryption algorithm of the security protocol to convert cipher text from the wireless network into plain text on the wired network. Further, the method may include selecting the security protocol to offer a high level of user transparency so that the security protocol requires minimal, if any, user input and provides minimal interference with a user's tasks on any terminal communicating over the wireless network. Thus, the method may include selecting the security protocol from one of Crypto IP Encapsulation (CIPE) and Simple Encryption Packet Protocol Layer (SEPPL). The method may include configuring the key management module to fully automate start up of the security protocol, to generate secure keys at regular intervals of time and to distribute the keys to all terminals and the bridge in a transparent manner. In addition, the method may include causing the two parts of the key management module to communicate with each other using sockets which are programmable interfaces for a network and run over a TCP/IP layer. In order for the programs to communicate with each other, the "client" may initiate connection from one of the terminals by sending an initial message to the server using an IP address of the server and a TCP port number of a program of the server. Messages may then be freely exchanged between the two programs. Then, the method may include automatically activating the key management module when the client terminal logs on to the wireless network and automatically providing the terminal with an updated encryption key and starting the security protocol on that terminal. The method may include using an RSA asymmetric encryption technique to encrypt an initial key only and for an initial exchange of keys between the terminal and the server. More particularly, the method may include, initially, generating a public-private key pair at both the terminal and the server and exchanging the public keys. When a public key is sent either from the terminal to the server or vice versa, the method may include also sending an authentication code in the form of a hash product of the public key and a 160 bit secret seed to authenticate the sender of the key. When the recipient receives the public key and the authentication code, the method may include causing the recipient to generate its own authentication code from the sender's public key that it has received and a corresponding secret seed stored on the server and, if the two authentication codes match, causing the recipient to generate its own public key and follow the same procedure with the sender. Once the public keys have been exchanged, the method may include causing the recipient to send the sender the encryption key and, upon receipt of the public key by the sender, enabling the sender to activate the security protocol and supply the security protocol with the latest key. If, while the server is servicing a client and another client logs on and requests the server for a key, the server may service the two clients simultaneously using threads. The method may include the server periodically sending each terminal currently using the security protocol new encryption keys at regular intervals, for example, every ten minutes. Each time the server sends a new encryption key to any client, the server may also update the encryption key at the bridge. The invention extends also to an encryption/decryption bridge for use in effecting data communication between a wireless network and a wired network, the bridge comprising: a soft core processor; and a hard core AES encryption/decryption engine. The invention extends still further to a key management system for use in data communication between a wireless network and a wired network, the key management system comprising: an asymmetric key encryption algorithm for initially exchanging public keys between a client on the wireless network and a server on the wired network; and a symmetric key encryption algorithm for use in exchanging private AES keys.

Brief Description of the Drawings The invention is now described by way of example with reference to the accompanying drawings in which:- Figure 1 shows a schematic representation of a WLAN system in accordance with an embodiment of the invention; Figure 2 shows a schematic representation of a data packet encrypted by a security protocol used on the system of Figure 1; Figure 3 shows a schematic representation of encryption of data by an encryption/decryption bridge of the system of Figure 1; Figure 4 shows a block diagram of the encryption/decryption bridge; Figure 5 shows a schematic representation of a key exchange and authentication carried out on the system; and Figure 6 shows a schematic representation of a key management module of the system. Detailed Description of the Preferred Embodiment Referring initially to Figure 1 of the drawings, reference numeral 10 generally designates a WLAN system, in accordance with an embodiment of the invention. The system 10 comprises a wired network 12 connected to a server 14 which, in turn, is connected to the internet 16. One or more terminals 18 are connected, in a hard wired manner, to the wired network 14. The system 10 further comprises a wireless network 20 via which terminals 22 communicate wirelessly with the server 14 over the wired network 12. The terminals 22 gain access to the server 14 over the wireless network via an access point 24. The system 10 includes an encryption/decryption bridge 26 arranged upstream of the access point 24, viewed from the server end of the wired network 12. The bridge 26 is arranged downstream of any of the wired terminals 18 if secure communication between the terminals 18 and the server 14 is not required. If, however, secure communication between the terminals 18 and the server 14 is required, the bridge 26 could be positioned between the wired terminals 18 and the server 14 as shown by 26' in Figure 1 of the drawings. The bridge 26 is employed for encryption/decryption purposes to facilitate secure communication and to authenticate communication between any wireless terminal 22 and the server 14. As will also be described in greater detail below, the system 10 incorporates a key management module for use with the security protocol used on the system 10. In this regard, the security protocol selected is the SEPPL protocol. This protocol does not have a key management system but has other benefits such as, for example, the use of firewalls provided by open source software, such as Linux, to filter IP packets. With the system 10, an encryption of data to or from the terminals 22 is effected to provide confidentiality and integrity of the data sent over the wireless network 20. The encryption is effected in software. The server 14 does not have encryption software installed on it because to encrypt and decrypt all messages coming from, and going to, the terminals 22 on the wireless network 20 would reduced the throughput of the server considerably, thereby reducing the throughput of the system 10 as a whole. With the provision of the separate bridge 26 for effecting encryption/decryption and which, therefore, contains the encryption algorithm, this problem is obviated. To provide authentication of data transmitted over the system 10, the key management module is provided. This key management module provides transparency to the user in the sense that it is automated and activates automatically when a terminal 22 logs on to the network 10 without requiring any user intervention. Key generation and distribution is, preferably, implemented on the server 14. However, provided the bridge 26 has sufficient computing power, key generation could, instead or in addition, be implemented on the bridge 26. The encryption algorithm used on the bridge 26 and the terminals 22 of the system 10 is that set by the Advanced Encryption Standard (AES). The AES is an industry standard and is widely used by commercial organisations. Ideally, the security protocol used on the system 10 should make use of a well recognised and accepted encryption algorithm. The protocol should also have a developed and thoroughly tested key management system and should be able to support multiple platforms so users using different operating systems can use the system 10. As indicated above, SEPPL has been selected as the security protocol for an initial implementation of the system 10 even though SEPPL does not have all the above attributes. In particular, SEPPL is only configured to operate on Linux operating systems and does not have the necessary key management system. As a result, the key management module of the system 10 was developed. SEPPL does have the advantage that it was specifically developed for WLANs. It also uses the AES encryption algorithm to provide authentication and confidentiality of data. Figure 2 shows a flow diagram of the encryption of an IP packet by SEPPL. A data frame 28 is associated with an IP header 30 to form a packet 32. To provide an encrypted data packet 36, the packet 32 is encrypted using the AES cipher as shown at 38. SEPPL then adds additional headers at step 40 to provide a frame 42 which is transmitted over the network 10. The frame 42 includes an initialisation vector 44, SEPPL headers 46 and a modified IP header 48. The initialisation vector 44 is used for AES encryption in the CBC (Cipher

Block Chain) mode, the CBC mode requiring the use of the initialisation vector 44. Ideally, the initialisation vector 44 is a random number equal in length to the relevant encryption key. Plain text, i.e. unencrypted data, is exclusively ORed with the initialisation vector 44. The AES encryption algorithm uses a 128-bit secret AES key to encrypt the value. The CBC mode increases the strength of the encryption algorithm and, therefore, the lifespan of the key because, when CBC is used, the relationship between the plain text and the cipher text is no longer the encryption algorithm. Scrambling caused by CBC makes the relationship more complex therefore increasing the strength of encryption which, in turn, results in a longer lifespan for the AES secret keys. This is advantageous because, the longer the lifespan of individual keys, the less frequent the need to generate and distribute keys which, as indicated above, uses computational resources and network bandwidth. The bridge 26 forms the communication connection between the wireless network 20 and the wired network 12 of the system 10. More particularly, the bridge 26 encrypts data transmitted from the wired network 12 to the wireless network 20 and decrypts data transmitted from the wireless network 20 to the wired network 12. Thus, the bridge 26 houses the network end of the AES encryption/decryption algorithm used on the system 10. The bridge 26 intercepts Ethernet frames travelling from the access point 24 to the server 12 as shown in greater detail in Figure 3 of the drawings. Hence, an Ethernet frame on a cable 50 is converted at 52 to a digital signal. In a stripper/restorer 54, Ethernet headers and trailers are stripped from the Ethernet frame. The stripped frame is then subjected to encryption/decryption by a core 56 of the bridge 26. Thus, the header and trailer are not decrypted but are stripped off at 54 because the aim of the bridge 26 is to have no encryption/decryption capabilities on the server 14. In the core 56, the TCP/IP frame is decrypted and passed to the second stripper/restorer 54 where the headers and trailers are recovered from memory and reapplied to the TCP/IP frame. The decrypted frame is then output on a second Ethernet cable 56 to the server 14. It will be appreciated that, for encrypting data from the server 14, the process is carried out in the bridge 26 in reverse. The bridge 26 is preferably implemented in a low cost format to minimise cost to users of the system 10. Ideally, the bridge 26 should cost less than that of an access point 24 of the system 10. Further, the bridge 26 is to be as small as possible to be accommodated alongside the access point 24. The throughput of the bridge 26 is designed to be at least half that of the network. Thus, for a 100Mbps network, the throughput of the bridge 26 should be at least 50Mbps per second. The bridge 26 is thus implemented as a field programmable gate away (FPGA), an embedded PC, or other similar computer device. As illustrated in Figure 4 of the drawings, the bridge 26 makes use of a soft core processor 56 running alongside the AES hard core encryption/decryption engine 58. The AES core 58 that is used is one which is capable of using a variety of key sizes and encryption modes like the CBC. This enables the system 10 to be customised in accordance with the user's security concerns. The core 58 is capable of providing up to 8 to 9 Mbps of throughput when using the 128-bit AES key. It is also capable of changing keys on the fly which is crucial for real-time applications. The key management module used in the system 10 is designed specifically for the SEPPL security protocol and, more particularly, fully automated SEPPL start up. The key management module is capable of generating AES 128-bit keys at regular time intervals and distributing the keys to all of the terminals 22 and the bridge 26 without any input of the users or the network administrator. The key management module developed for the system 10 is configured to perform the following tasks: 1. auto-start the program in the server, which is platform independent;

2. auto-start the client program on each terminal when a user logs on;

3. ensure that the server has the capability of handling multiple clients at the same time by use of "threads";

4. use 1024 bit RSA asymmetric keys for initial messages sent between the server and any terminal;

5. authenticate that the terminal is using a secret 160 bit seed available on the client terminals;

6. ensure that every message exchanged between the server and terminal is authenticated to preclude man-in-the-middle attacks; 7. preclude major denial of service attacks;

8. generate new 128 bit keys at regular time intervals to be sent to all terminals for encryption and decryption of messages sent over the network;

9. use different TCP port numbers to enable the bridge to differentiate which messages are to be encrypted/decrypted and which messages are for the bridge only;

10. provide fully dynamic IP address lists of clients to provide compatibility with different server settings; and

11. generate error logs by terminals and server in case of fatal errors. The key management module of the system 10 is implemented using two programs that are capable of communicating with each other over the network 12, 20. One of the programs, running on each of the terminals 22, is referred to as the "client". The other program which is installed either on the server 14 or any computer on the wired network 12 is called the "server". The two programs communicate with each other using sockets, being programmable interfaces to a network which run over the TCP/IP layers. The sockets are used to communicate between the programs as they are platform independent. In order for the programs to communicate with each other, the client 22 initiates contact with the server 14 by sending an initial message to the server using the IP address of the server and the TCP port number of the server program. Thereafter, messages can be freely exchanged between the two programs. The Python programming language was used to develop the key management module which is also a platform independent programming language. It requires a Python interpreter to be installed on the computer on which the Python program is run. Python has other advantages such as speed of operation and ease of programming due to the reduced number of lines that have to be written to develop socket programs. As indicated above, the key management module is activated automatically when a user logs on via a terminal 22. Further, once logged on, the terminal 22 receives the latest encryption key for the SEPPL security protocol automatically and starts SEPPL on the terminal 22. The key management module makes use of a public-private key combination. Initially, when the user logs on via a terminal 22, a public key is sent and encrypted using an RSA asymmetric encryption algorithm. This algorithm is also used for all other data exchanges between the terminal 22 and the server 14. Because of the computationally intensive nature of asymmetric encryption, the RSA asymmetric encryption algorithm is only used for the initial exchange of keys. A 1024 bit key is used to encrypt the messages sent between the client and the server 14. Referring in more detail to Figure 5 of the drawings, a public key 60/private key 62 pair is generated at both the terminal 22 and the server 14. The public key is only used to encrypt so that, if it is intercepted by an attacker, it cannot be used to decrypt the data encrypted using the same public key. It also provides no information of the private key and therefore the private key 62 cannot be determined from its corresponding public key 60. When the client sends the public key, as shown by arrow 64, to the server 14, a hash product 70 of the public key and a 160 bit secret seed 66 is also sent, as shown at 68, to authenticate the sender of the key 60. All clients have a 160 bit secret seed 66 which is shared by the server. This seed 66 forms the basis for authentication. A hash product is a program which takes a string of any length and generates a unique bit stream. Unlike encryption, there is no way to reverse this bit string to the original string. An SHA-1 hash function is used to produce the hash product 70 which is sent to the server 14. When the client 22 sends it public key 60 to the server 14, the client 22 also sends the hash product 70 of the public key 60 and the secret seed 66. Upon receiving the public key 60 and the hash product 70, the server 14 generates its own authentication hash product 72 from the client's public key 60 and the secret seed 66 maintained at the server 14. This is compared, as shown by arrow 74. If the two authentication hash products 70 and 72 match, then the server concludes that the client sent the public key 60 and the server generates its own public key and follows the same procedure with the client or terminal 22. If the authentication hash product 70 was different from the authentication hash product 72 of the server 14, the server 14 does not send its public key 60 but awaits a genuine public key from the terminal 22. Once the public keys 60 have been exchanged, the server 14 sends the client the latest 128-bit AES key. This is shown in greater detail in Figure 6 of the drawings. When the client receives that key, the terminal 22 is able to activate the SEPPL security protocol and supply it with the latest AES key. The server 14 is able to service more than one client at a time by use of threads. In addition, the server 14 sends all clients, i.e. terminals 22, that are logged on to the network 20, new AES 128-bit encryption keys at regular intervals, for example, every ten minutes. Every time a key is sent to one of the terminals 22, it is also made available to the bridge 26. The AES 128-bit encryption keys are encrypted using symmetric encryption. It is therefore advantageous to change the encryption keys at regular intervals to counteract reducing the strength of encryption due to the greater encryption data which is available to an attacker when symmetric encryption is used. In a variation of the invention, to avoid the time consuming nature of generating and installing a 160 bit seed on each client, digital certificates could be used instead. Referring now to Figure 6 of the drawings, upon boot up an initial AES key 76 is sent to the client as indicated by arrow 78. The initial AES key 76 is sent via TCP port number 10001, as indicated at 80, of the bridge 26 when the client initially logs on. During this mode, packets exchanged between the client and server programs are encrypted using the RSA encryption algorithm and occurs prior to the SEPPL security protocol being activated. When the bridge 26 receives packets on port number 10001, it does not encrypt or decrypt these packets but merely transmits the packets to the wireless network 20 for onward transmission to the client. Once the SEPPL security protocol has been activated on the client terminal 22, the server 14, at the regular intervals selected, sends new keys 82, as indicated by arrow

84, to the client via TCP port 10002 (and labelled 86 in Figure 6 of the drawings) of the bridge 26. A data packet containing the new key 82 is treated by the bridge 26 as any other ordinary packet and is encrypted or decrypted by the bridge 26 depending on the direction in which the packet is travelling. A third port, TCP port number 10003, is used for data packets, as indicated by arrow 88, that are designated for the bridge 26 only. These packets with TCP port number 10003 carry the latest key 82 for the bridge 26. It will be borne in mind that the encryption of the keys 82 is carried out by the bridge 26. It is an advantage of the invention that a WLAN system 10 is provided which can be implemented to provide secure communication without the need for major rebuilding or re-installation of an existing wireless network. The cost of providing the security is also insignificant. In addition, the system 10 operates in an entirely transparent manner requiring minimal user intervention when a client logs on to the wireless network 20 of the system 10. Thus, a system 10 is provided which enable secure, confidential and easily authenticated data to be communicated over a wireless network. It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

Claims

CLAIMS:

1. A WLAN system comprising a wireless network communicating with a wired network via an access point, the system including: an encryption/decryption bridge arranged between the access point and the wired network, the bridge encrypting data transmitted from the wired network to the wireless network and decrypting data transmitted from the wireless network to the wired network; and a key management module having a first part arranged on terminals of the wireless network and a second part arranged on a server of the wired network, the key management module generating and distributing keys to the terminals on the wireless network and to the bridge.

2. The system of claim 1 in which the bridge is arranged between the access point and the server.

3. The system of claim 1 or claim 2 in which the encryption decryption bridge is implemented in software on the terminals.

4. The system of any one of the preceding claims in which an Advanced Encryption Standard (AES) is used in the encryption decryption bridge.

5. The system of any one of the preceding claims in which the encryption decryption bridge is implemented as one of a Field Programmable Gate Array (FPGA) and an embedded personal computer.

6. The system of any one of the preceding claims in which the bridge contains an encryption decryption core interposed between strippers/restorers.

7. The system of claim 6 in which the core is in the form of a processor running alongside an encryption/decryption engine.

8. The system of any one of the preceding claims in which the bridge has a throughput of at least half the speed of the WLAN.

9. The system of any one of the preceding claims in which the wireless network and the wired network communicate with each other via a security protocol to provide confidentiality of data transmission.

10. The system of claim 9 in which the security protocol uses an encryption algorithm which converts cipher text from the wireless network into plain text on the wired network.

11. The system of claim 9 or claim 10 in which the security protocol is of a type offering a high level of user transparency so that the security protocol requires minimal, if any, user input and provides minimal interference with a user's tasks on any terminal communicating over the wireless network.

12. The system of any one of claims 9 to 11 in which the security protocol is one of Crypto IP Encapsulation (CIPE) and Simple Encryption Packet Protocol Layer

(SEPPL).

13. The system of any one of claims 9 to 12 in which the key management module is configured to fully automate start up of the security protocol, to generate secure keys at regular intervals of time and to distribute the keys to all terminals and to the bridge in a transparent manner.

14. The system of any one of the preceding claims in which the two parts of the key management module communicate with each other using sockets which are programmable interfaces for a network and run over a TCP/IP layer.

15. The system of any one of the preceding claims in which the key management module is configured to activate automatically when any terminal logs on to the wireless network.

16. The system of claim 15 in which an RSA asymmetric encryption technique is used to encrypt an initial key only and is used for an initial exchange of keys between the terminal and a server.

17. A method of communicating data over a WLAN, the WLAN comprising a wireless network communicating with a wired network via an access point, the method including: interposing an encryption/decryption bridge between the access point and the wired network, the bridge encrypting data from the wired network to the wireless network and decrypting data transmitted from the wireless to the wired network; and automatically generating encryption keys via a key management module having a first part arranged on terminals of the wireless network and a second part arranged on a server of the wired network, the keys being distributed to the terminals of the wireless network and to the bridge.

18. The method of claim 17 which includes implementing the encryption decryption bridge in software on the terminals.

19. The method of claim 17 or claim 18 which includes using an Advanced Encryption Standard (AES) in the encryption/decryption bridge.

20. The method of any one of claims 17 to 19 which includes implementing the encryption decryption bridge as one of a Field Programmable Gate Array (FPGA) and an embedded personal computer.

21. The method of claim 20 which includes using the bridge to decrypt data received from the wireless network and to encrypt data to be transmitted to the wireless network to maintain network throughput from the server.

22. The method of any one of claims 17 to 21 which includes interposing an encryption/decryption core of the bridge between strippers/restorers.

23. The method of claim 22 which includes, upon receipt of a data frame, stripping off a header and a trailer of the frame by the stripper, sending the data frame to the core for decryption and, in the following stripper/restorer, reapplying the header and trailer for onward transmission.

24. The method of any one of claims 17 to 23 which includes causing the wireless network and the wired network to communicate with each other via a security protocol to provide confidentiality of data transmission.

25. The method of claim 24 which includes using an encryption algorithm of the security protocol to convert cipher text from the wireless network into plain text on the wired network.

26. The method of claim 24 or claim 25 which includes selecting the security protocol to offer a high level of user transparency so that the security protocol requires minimal, if any, user input and provides minimal interference with a user's tasks on any terminal communicating over the wireless network.

10 27. The method of any one of claims 24 to 26 which includes selecting the security protocol from one of Crypto IP Encapsulation (CIPE) and Simple Encryption Packet Protocol Layer (SEPPL).

15 28. The method of any one of claims 24 to 27 which includes configuring the key management module to fully automate start up of the security protocol, to generate secure keys at regular intervals of time and to distribute the keys to all terminals and the bridge in a transparent manner. 0

29. The method of claim 28 which includes causing the two parts of the key management module to communicate with each other using sockets which are programmable interfaces for a network and run over a TCP/IP layer.

30. The method of claim 29 which includes initiating connection from one of the 5 terminals by sending an initial message to the server using an IP address of the server and a TCP port number of a program of the server.

31. The method of claim 30 which includes automatically activating the key management module when the terminal logs on to the wireless network and 0 automatically providing the terminal with an updated encryption key and starting the security protocol on that terminal.

32. The method of claim 31 which includes using an RSA asymmetric encryption technique to encrypt an initial key only and for an initial exchange of keys between the 5 terminal and the server.

33. The method of claim 32 which includes, initially, generating a public-private key pair at both the terminal and the server and exchanging the public keys.

34. The method of claim 33 which includes, when a public key is sent either from the terminal to the server or vice versa, also sending an authentication code to authenticate the sender of the key.

35. The method of claim 34 which includes, when the recipient receives the public key and the authentication code, causing the recipient to generate its own authentication code from the sender's public key that it has received and, if the two authentication codes match, causing the recipient to generate its own public key and follow the same procedure with the sender.

36. The method of claim 35 which includes, once the public keys have been exchanged, causing the recipient to send the sender the encryption key and, upon receipt of the public key by the sender, enabling the sender to activate the security protocol and supply the security protocol with the latest key.

37. The method of claim 36 which includes the server periodically sending each terminal currently using the security protocol new encryption keys.

38. The method of claim 37 which includes, each time the server sends a new encryption key to any terminal, also updating the encryption key at the bridge.

39. An encryption decryption bridge for use in effecting data communication between a wireless network and a wired network, the bridge comprising: a soft core processor; and a hard core AES encryption/decryption engine.

40. A key management system for use in data communication between a wireless network and a wired network, the key management system comprising: an asymmetric key encryption algorithm for initially exchanging public keys between a client on the wireless network and a server on the wired network; and a symmetric key encryption algorithm for use in exchanging private AES keys.