Securing arbitrary communication services

[0001] The present invention relates in general to securing information in open communication systems, and more particularly to a method and a system for providing authentication, confidentiality and integrity protection of arbitrary communication services.

[0002] In open communication systems there is a need of securing the information. This includes authentication of the communication peers and confidentiality and integrity protection of the data. Authentication implies that some means has been provided to guarantee that the entities are who they claim to be, or that the information transmitted has not been manipulated by unauthorized parties. Confidentiality basically implies that no unauthorized entity is able to read our message and data integrity ensures that our message has not been altered and that the whole message stream comes from the same source and that the whole message stream goes to the same destination.

[0003] Solutions to these types of problems come from cryptographic research. Typically a cryptographic algorithm is a function that has one value that should be kept secret or should be protected as input and another secret value as input. The secret value is often called a secret key of the algorithm. Many modern secure communication systems uses well known cryptographic algorithms and the security is not based on the algorithm itself but on a secret key. The assumption that only the actual key is kept secret from the adversary is called Kerkhoff's assumption. The Kerkhoff's assumption is important in open communication systems like the Internet, where devices from many different vendors at many different locations needs to inter-operate. It is much easier to make the communication work if the methods of how to process the data is publicly known. Hence, all Internet communication security techniques are built on Kerkhoff's assumption i.e. well known cryptographic algorithms with the security based on secret key values.

[0004] In order to set up a secure communication channel there must be some predefined protocol that describes which messages that should be exchanged between the communication peers. A necessary step in securing a communication system is to provide authenticated key exchange. Typically a key exchange is done by using a public key algorithm, e.g. the Diffie-Hellman (DH) algorithm, used in e.g. the Internet Key Exchange Protocol (IKE), the Transport Layer Security protocol (TLS) and the Secure Shell Protocol (SSH), or the Rivest-Shamir-Adleman (RSA)-algorithm, used in e.g. TLS.

[0005] In open security protocols like SSH, TLS and Internet Protocol Security (IPsec)/IKE, public key algorithms are used to digitally sign data or to do key exchange. Several different public key signature methods as well as key exchange methods might be used. The basic protocol that is used to encrypt payload data and to add an integrity check tag is very similar in the protocols. However, the authentication procedure, the key exchange and the different symmetric algorithms supported in the protocols differ substantially. Hence, a problem is that at least one of the communication peers must support a very large number of different cryptographic algorithms and security options if two units without a predefined secure relation should be able to inter-operate securely. Furthermore, the large number of different options make the key negotiation protocols very large and complex, and simply hard to implement.

[0006] In U.S. Pat. No. 5,892,904 is described a method that ensures authenticity and integrity of a computer program, an executable file, or code received over a computer network, e.g. the Internet. In one embodiment the method involves determining a cryptographic digest or hash of the executable file and forming a publisher signature with the cryptographic digest. The publisher signature is formed with a public-private key signature algorithm such as the RSA (Rivest-Shamir-Adleman) public key algorithm, as is well known in the art. A publisher digital certificate is attached to the publisher signature to authenticate the identity of the publisher issuing the publisher signature. The digital certificate includes the software publisher's name, a public key corresponding to a private key used by the publisher to sign the file, an expiration date of the certificate, and a link or hyperlink to the certification agency.

[0007] WO 99/56428 describes another secure method of downloading a program into a processor from a device external to the processor. The program may be encrypted and have authentication information added to it. The processor decrypts and authenticates the program before allowing the program to be executed by the processor.

[0008] WO 99/33224 discloses a method and system ensuring that a data stream including e.g. video- or audio data only can be received by authorised receivers. The receivers can also prove the number of received video- or audio data packets. This is done by encrypting every data packet sent in the data stream and logging the number of decrypted packets in the receiver.

[0009] None of these documents describe how a secure communication channel is established between two communication peers not having a predefined security relation. This is a common situation in e.g. ad hoc networks, i.e. Bluetooth, Salutation, Jini etc. Thus, there is a need for a method and system showing how to establish secure communication between a client and an arbitrary communication service.

[0010] The present invention provides a solution to the problem of securing a communication channel between two communication peers not having a predefined secure relation.

[0011] In state-of-the art protocols at least one of the communication peers must support a very large number of different cryptographic algorithms and security options if two units should be able to inter-operate, making the key negotiation protocols large and complex.

[0012] One object of the invention is thus to provide a solution where the number of needed predefined cryptographic algorithms are as few as possible.

[0013] Another object of the invention is to reduce the complexity of the key negotiation protocols depending on the number of supported options and cryptographic algorithms.

[0014] Yet another object is to provide a solution where the problem of export restrictions is reduced.

[0015] The above mentioned objects are basically achieved by downloading from a particular service, that a communication client wants to communicate with, a signed computer program (e.g. a Jini Proxy) containing the necessary algorithms for doing authenticated key exchange with the server. Furthermore, the computer program contains the necessary algorithms needed to encrypt and protect all data sent between the client and the service in a secure service session.

[0016] More specifically the invention concerns a security communication situation where a communication client wants to communicate with a particular service. The service can be reached by the client using either a global network such as the

[0017] Internet, a local network or even an ad hoc network, i.e. a network created on the fly between entities that happen to be at the same physical location. It is also assumed that all units that utilises the service use a common computing platform, i.e. all units can download and execute a program written in a common language. An example of a widely deployed such computing platform and language is the Java virtual machine and the Java byte code computing language. The client is supposed to have only two pre-defined cryptographic capabilities; the ability to digitally sign arbitrary data and the ability to verify a digital signature of arbitrary data.

[0018] The server that wants to offer a secure communication service digitally signs a computer program containing the necessary algorithms for authenticated key exchange with the server using its private key in a public key pair. The server packs the signed code together with the signature and optionally also one or several certificates that certify the public key of the server. The server's public key can then be used to verify code signed by the server.

[0019] A client that wants to communicate with a service downloads over the network the package with the signed code and a possible certificate and checks the signature of the downloaded package. If the client holds a trusted public key that corresponds to the signature or the client trusts some of the public keys contained in the certificates included then the client treats the downloaded code as a trusted security code.

[0020] The security code is then executed on the common computing platform of the client and can ask the client to perform one security function if mutual authentication is desired. This function has as input some arbitrary data and as output a digital signature of the data plus a specific label added by the client. The client might also return a certificate containing the public key that can be used by the service to verify signatures made by the client. The service code performs authenticated key exchange with its origin server. If it succeeds it sets up a secure communication link with the server.

[0021] In a first embodiment of the invention the authenticated key exchange is made more efficient by taking advantage of that the key exchange code itself is signed and thereby saving one public key signature generation, one public key signature verification and one transmission between client and the server.

[0022] In a second embodiment of the invention the key exchange is separated from the protection of the communication. The benefit with that approach is that several different services can be protected using one master key, instead of that each service must perform a heavy public key exchange.

[0023] By allowing the security protocol code needed for key exchange and data communication protection to be downloaded the number of needed predefined security functions that a client or server need to support is limited. Instead the security is guaranteed by signing the security code itself. This also makes it much easier to update the communication protection with new algorithms, since when there appears to be security flaws in the protocol and the whole or parts of the protocol must be rewritten it is only the server program that needs to be updated.

[0024] Since the necessary cryptographic functions needed by the client are only signing and verification of signatures there is usually no problem with export regulations, since these functions are normally not restricted.

[0025] These and other objects and advantages of the invention will become more fully apparent from the following detailed description when read in conjunction with the accompanying drawings with like reference numerals indicating corresponding parts, and wherein:

[0026] FIG. 1 shows the basic communication scenario;

[0027] FIG. 2 shows a flowchart of an embodiment of the invention; and

[0028] FIG. 3 illustrates an alternative communication scenario using a key exchange server.

[0029] Referring now to FIG. 1, the present invention will be described in a security communication situation 100 where a communication client 110 wants to communicate with a server 120 providing particular services. The server 120 can be reached by the client 110 using a global network, e.g. the Internet, or a local communication network or even an ad hoc network 130. Furthermore, it is assumed that all units that utilises the services use a common computing platform 140, i.e. all units can download and execute a computing program written in a common language. An example of a widely deployed such computing platform and language is the Java virtual machine and the Java byte code computing language. The unit offering the service, i.e. the server 120, has full knowledge of the language and the common computing platform used by different clients 110 in the network.

[0030] The invention will now be described using the Java Jini technology as an example of a communication client wishing to connect to a communication service. The Java Jini technology makes computers and devices able to quickly form ad hoc networks without any planning, installation or human intervention. Each device provides services that other devices in the network may use. These devices also provide their own interfaces, which ensures reliability and compatibility. Each device and service is registered in a lookup service, and when new devices enter the network they go through an add-in protocol called discovery and join. To use a service a person or a program locates the service using the lookup service. The service's interface is copied from the lookup service to the requesting device where it will be used. The lookup service thus acts like a switchboard to connect a client looking for a service with that service. It doesn't matter where a service is implemented since compatibility is ensured because each service provides everything needed to interact with it in a downloadable Jini proxy.

[0031] In a wireless ad hoc network trust is one of the central problems. Since we cannot trust the medium, the only choice is to use cryptography. One of the main problems is that we cannot assume any pre-configured security relations between the ad hoc nodes. Given that all of the nodes in the ad hoc network have public key pairs, and that all of the nodes consider the public keys of others' good for creating secure connections within the ad hoc network any public key based authentication can be used.

[0032] Different from standard approaches it is in this invention not assumed that the client and server necessarily share a large set of different symmetric key encryption or Message Authentication Code (MAC) algorithms. Instead it is assumed that the client has only two predefined cryptographic capabilities:

[0033] The client can digitally sign arbitrary data by using a public key algorithm together with a one way hash function; and

[0034] The client can verify the correctness of a public key signature of arbitrary data. The algorithms used to sign the data are chosen among a quite small amount of possible algorithms.

[0035] The software program or hardware used for signing or verifying a signature of arbitrary data is physically located in the client such that it can not be changed or manipulated by a hostile person. The software or hardware used for signing or verifying signatures does not completely need to use the common computing platform, e.g. can APIs (Application Program Interfaces) defined in the computing platform be used instead.

[0036] Using the cryptographic capabilities described above, a client can securely download a Jini proxy, and use the Jini proxy to execute an authentication and key management protocol on its behalf. This gives a total freedom to utilise service dependent security solutions. Now a first embodiment of the invention will be described referring to the flowchart of FIG. 2.

[0037] Before any communications are started, the server prepares a Jini proxy that the clients can download. The server also signs the Jini proxy; thereby allowing the clients to verify the integrity and origin of the Jini proxy before the Jini proxy is executed. The Jini proxy code typically includes a public key corresponding to a private key held by the server and methods needed for doing authenticated key exchange with the server.

[0038] 1. A server that wants to offer secure communication holds a computer program written in the computer language of the common platform, i.e. Java. In Jini terms, the server holds a Jini proxy. The Jini proxy contains the necessary algorithms and methods needed for doing authenticated key exchange with the server. Furthermore, the proxy contains the necessary algorithms needed to encrypt and protect all data sent between a client and a server in a secure service session. However, the proxy does not necessarily contain all code needed to perform cryptographic computation.

[0039] Instead, the proxy might use APIs defined in the common platform, if feasible.

[0040] 2. The server digitally signs the Jini proxy using its private key. The signature is calculated using the predefined algorithms and formats described above. This ensures that the client will be able to verify the signature.

[0041] 3. The server packs the signed code together with the signature and optionally includes also one or more certificates that certify the public key of the server. The servers public key can be used to verify the authenticity of the server.

[0042] In Jini, and similar environments, a client looking for a service starts the communication. Once the service is found, the client downloads the service proxy for execution, with the difference that the authenticity of the service proxy is verified before starting its execution.

[0043] 4. A client search for a service using the Jini lookup service 200.

[0044] 5. When the client finds the service and wants to use it, the client downloads a proxy corresponding to the service, together with signatures and optional certificates 210.

[0045] 6. The client verifies the signature of the downloaded data package. If the client holds a trusted public key that corresponds to the signature, or the client trusts some of the public keys contained in the certificates included, then the client treats the downloaded code as a trusted code 220.

[0046] 7. If the verification of the proxy is correct, the client executes the downloaded code using the common computing platform. Runtime restrictions might be added as appropriate; especially, the downloaded code does not need to be able to communicate with any other server but the designated 230.

[0047] The downloaded code can ask the client to create a signed ticket if mutual authentication is required. The client may refuse to perform any other cryptographic functions. The ticket creation function takes some arbitrary data and outputs a ticket, which basically is a digital signature of the data plus a specific label added by the client. The label is needed in order to make sure that the resulting item is always recognised as a ticket. The client might also return a certificate containing a public key that can be used to verify signatures made by the client. The ticket label typically designates the service the client has requested the proxy for, and a time stamp. Before the client machine digitally signs the data and the label, the label should be displayed to the user of the client machine. The user might at that time refuse to sign the ticket. Thus the Jini proxy and the server can authenticate each other as follows.

[0048] 8. The proxy performs authenticated key exchange with its origin server 240. The actual protocol used can basically be any standard authentication and key exchange protocol, e.g. DH or RSA. The Jini proxy might request a certificate from the client certifying the public key for verifying the signature of ticket mentioned above. If the authentication succeeds, the proxy sets up a secure communication link with the server 250.

[0049] The service provider that writes the security code can implement the key exchange algorithm as it wishes, but should follow good cryptographic principles. The security level thus, depends on the algorithm used by the server.

[0050] In a first embodiment of the invention the fact that the key exchange code itself is signed by the server is used to save one public key signature generation and one public key signature verification and one transmission between the client and the server. This is possible since the signature of the key exchange code is checked prior to the real key exchange. Hence authenticated information about the server's public key is already available to the client. For example if Diffie-Heilman is used, the public key exchange value of the server can be contained in the service code. Hence the key exchange can be performed with one single transmission from the client to the server and we save one transmission.

[0051] In a second embodiment of the invention, illustrated in FIG. 3, the key exchange is separated from the pure communication protection. The benefit with this approach is that several different services can be protected using one group master key, instead of that each service must perform a heavy public key exchange. Thus, instead of searching for a service the client 300 searches for a key exchange server 310. The client 300 receives from the key exchange server 310 a group master key and an identifier for that key. Later when the client 300 wants to use a service in the same domain as the key exchange server was located, the client search for a server 320 providing a service, downloads a package from the server 320 and executes the package on the common computing platform 330. The downloaded security code can ask the client 300 to perform one security function, which has the group master key identifier as input and as output the group master key. When doing the key exchange the downloaded service code uses the group master key.

[0052] The invention has now been described using Jini technology as an example but the only requirement on the nodes is that they support a common computing platform, i.e. that all nodes in the ad hoc network can download and execute programs written in a common language and the ability to generate and verify signatures. The invention can e.g. also be used when setting up secure WAP (Wireless application protocol)-services, i.e. by downloading a program code defining the security algorithm.

[0053] The invention being thus described, it will be obvious that the same may be varied in many ways. Such variations are not to be regarded as a departure from the scope of the invention, and all such modifications as would be obvious to one skilled in the art are intended to be included within the scope of the following claims.