WO2008004174A2

WO2008004174A2 - Establishing a secure authenticated channel

Info

Publication number: WO2008004174A2
Application number: PCT/IB2007/052565
Authority: WO
Inventors: Ventzislav Nikov
Original assignee: Koninklijke Philips Electronics N.V.
Priority date: 2006-07-06
Filing date: 2007-07-02
Publication date: 2008-01-10
Also published as: WO2008004174A3

Abstract

A communication system has at least two communication devices (10,20) each accommodating an application (12,22). Establishing a secure authenticated channel between applications is achieved by first executing a link layer protocol (81) for establishing, on a link layer, an unauthenticated secure channel between the communication devices by exchanging link layer protocol messages. Subsequently an authentication protocol (82) is executed for establishing, on an application layer, authentication between the applications. The authentication protocol includes transferring an authentication message from a first application, processing the authentication message into a secure authentication message, transferring the secure authentication message to the second communication device via the unauthenticated secure channel, verifying the secure authentication message, and transferring the secure authentication message to the second application.

Description

Establishing a secure authenticated channel

FIELD OF THE INVENTION

The invention relates to a method for establishing a secure authenticated channel between applications having authentication means via a medium in a communication system, which system comprises a first communication device accommodating a first application, and a second communication device accommodating a second application. The invention further relates to a computer program product and a communication device for use in the system.

The invention relates to the field of providing secure communication for applications, for example access control keys, user ID cards, multimedia or interactive applications in a user device. In particular the invention relates to secure key exchange schemes for authenticating applications which are communicating via an open medium, for example wireless near field communication or a network like internet.

BACKGROUND OF THE INVENTION

Secure Key Exchange schemes are a well-known part of information security/cryptography, and are used to provide a shared secret between two or more parties. Most of the key exchange schemes target the case where two parties are involved. The document [NIST] "NIST SP 800-56 A, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography, March, 2006" describes key establishment schemes using discrete logarithm cryptography. A key establishment scheme can be characterized as either a key agreement scheme or a key transport scheme. In [NIST] the asymmetric-key-based key agreement schemes are based on the Diffϊe-Hellman (DH) and Menezes-Qu-Vanstone (MQV) algorithms, and an asymmetric-key-based key transport scheme is specified. A key exchange scheme may be a component of a key exchange protocol, which in turn provides additional security properties not provided by the key exchange scheme when considered by itself.

Known key exchange protocols target the following case. Two parties are involved in the protocol. The parties are either not authenticated or one of them is authenticated or both of them are authenticated. Messages are exchanged via a network between the parties. In general in a system having applications at various locations such applications may require to securely access or transfer data to other applications, or receive data. For such secure communication the applications the application would like to have a secure authenticated channel (SAC) in order to communicate securely to a known and trusted party. Providing a secure authenticated channel between applications is discussed in the document [Krawczyk]: "H. Krawczyk, SIGMA: The 'SIGn-and-MAc' Approach to Authenticated Diffie-Hellman audits Use in the IKE-Protocols. CRYPTO'03, LNCS 2729, Springer 2003, pp. 400-425". SIGMA denotes a protocol based on cryptographical signature (SIGN) and message authentication (MAC). SIGMA is a family of cryptographic key- exchange protocols that provide forward secrecy via a Diffie-Hellman exchange authenticated with digital signatures. SIGMA combines the use of digital signatures and MAC functions to guarantee an authenticated binding between the Diffie-Hellman key and the identities of the parties to the exchange. The SIGMA protocols serve as the cryptographic basis for the signature-based modes of the standardized Internet Key Exchange (IKE) protocol, as defined in [IPSEC] "Internet Key Exchange (IKEv2) Protocol, RFC 4306, December, 2005".

In general applications can either directly establish a SAC or use underlying communication layers to provide for them such a channel. However, the first solution requires heavy resources if several applications try simultaneously to have SACs, and also in general such a solution will be more or less application specific. The second solution has the drawback that the corresponding layers (e.g. Transport or IP Layers) are authenticated (entity authentication) but not the applications. Thus when an application has to authenticate to another application they use the already established SAC (on the lower layers) and inside the established SAC perform the application level authentication, which results in a double authentication.

SUMMARY OF THE INVENTION

It is an object of the invention to provide a system for flexibly establishing secure authenticated channels reducing the required resources indicated above. For this purpose, according to a first aspect of the invention, the method, as described in the opening paragraph, further comprises first executing a link layer protocol for establishing, on a link layer, an unauthenticated secure channel between the first and second communication devices by exchanging link layer protocol messages, and subsequently executing an authentication protocol for establishing, on an application layer, authentication between the first and second application, the authentication protocol comprising transferring an authentication message from the first application to a first link unit in the first communication device, processing the authentication message into a secure authentication message by the first link unit, transferring the secure authentication message to a second link unit in the second communication device via the unauthenticated secure channel, and verifying the secure authentication message by the second link unit, and transferring the secure authentication message to the second application.

For this purpose, according to a second aspect of the invention, the communication device as described in the opening paragraph, is arranged for first executing a link layer protocol for establishing, on a link layer, an unauthenticated secure channel between the first and second communication devices by exchanging link layer protocol messages, and subsequently executing an authentication protocol for establishing, on an application layer, authentication between the first and second application, the authentication protocol comprising transferring an authentication message from the first application to a first link unit in the first communication device, processing the authentication message into a secure authentication message by the first link unit, transferring the secure authentication message to a second link unit in the second communication device via the unauthenticated secure channel, and verifying the secure authentication message by the second link unit, and transferring the secure authentication message to the second application. The measures have the effect that establishing the secure authenticated channel is set up in a two level approach. First a secure, but unauthenticated, channel is set up by the link layer protocol, based on appropriate key exchange protocols. Secondly, the applications are authenticated via the already established secure channel creating in this way their own authenticated channels. Advantageously flexibility is achieved, for example multiple authenticated channels can be created between different applications sharing the same unauthenticated, but secure, channel based on the key exchange protocol outcome.

The invention is also based on the following recognition. Traditionally, the authentication and key establishment problems have been located and solved at one level, e.g. the application level or the link level. However the inventors have seen that, from an architecture point of view a mixed approach is better namely, authentication may be provided by the application while the key establishment is provided by the link level. The new architecture requires a trust relation between the application and the lower link level. The measures according to the invention allow achieving the authentication based on a service provided by the link for authenticating two applications to each other through the link. In an embodiment of the method the authentication protocol comprises transferring, in response to the secure authentication message, a response message including second identity data from the second application to the second link unit, processing the response message into a secure response message by the second link unit, transferring the secure response message to the first link unit via the unauthenticated secure channel, and verifying the secure response message by the first link unit, and transferring the secure response message to the first application. This has the advantage that the identity data of the responding device is transferred using the secure link for the authentication.

In an embodiment of the method the authentication protocol comprises identity protection by said processing the message into the secure message including encrypting the message. The messages on the medium, e.g. a wireless transmission, are vulnerable to attack, i.e. interception or replay. Advantageously the encryption protects against such attacks. In particular one party in the protocol will detect an anomaly in the responses, or does not receive any response, before he is requested to transmit his identity data.

In an embodiment of the communication device the link unit comprises means for wireless near field communication, which near field communication constitutes the medium in the communication system. In practice the secure authenticated channel may advantageously used for wireless communication systems. In particular in near field communication, i.e. the user bringing the communication devices together at close range, the secure authenticated channel provides new opportunities for secure user functions, e.g. a user identity card; a network access card; an automobile lock key; a parking key; a hotel key. Further preferred embodiments of the device and method according to the invention are given in the appended claims, disclosure of which is incorporated herein by reference.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other aspects of the invention will be apparent from and elucidated further with reference to the embodiments described by way of example in the following description and with reference to the accompanying drawings, in which Fig. 1 shows a communication system, Fig. 2 shows a communication device,

Fig. 3 shows establishing a secure channel and trust relations, Fig. 4 shows establishing a secure channel and interfacing between layers, Fig. 5 shows a diagram of unauthenticated key exchange,

Fig. 6 shows a diagram of SIGMA key exchange,

Fig. 7 shows a diagram of SIGMA key exchange with Initiator Identity Protection, Fig. 8 shows a diagram of a setup of a Secure Authenticated Channel, and

Fig. 9 shows a diagram of a setup of a Secure Authenticated Channel with identity protection.

Corresponding elements in different Figures have identical reference numerals.

DETAILED DESCRIPTION OF EMBODIMENTS

Figure 1 shows a communication system. A first communication device 10 is shown to be in communication with a second communication device 20 via a medium 15. The first communication device 10 has a first link unit 11 and a processing unit 13, which accommodates a first application 12. The processing unit 13 further may accommodate one or more further applications 14. The second communication device 20 has a second link unit 21 and a processing unit 23, which accommodates a second application 22. The processing and link units may be implemented by software in a microprocessor system, or may be (in part) be constituted by hardware circuits such as logic arrays or state machine logic, for performing a link layer protocol 81 and authentication protocol 82 as described in detail below.

The first communication device and second communication device are arranged for establishing a secure authenticated channel between applications via the medium 15. Thereto at least one, but usually each, application has authentication functions, such as certificates, identity data, signature functions, options to request user names and corresponding passwords, etc. Hence an application can authenticate itself.

The communication system establishes a secure authenticated channel between the first and second applications as follows. First a link layer protocol 81 is executed for establishing, on a link layer, an unauthenticated secure channel between the first and second communication devices by exchanging link layer protocol messages. Subsequently an authentication protocol 82 is executed for establishing, on an application layer, authentication between the first and second application. The authentication protocol comprises transferring an authentication message from the first application to a first link unit in the first communication device, processing the authentication message into a secure authentication message by the first link unit, transferring the secure authentication message to a second link unit in the second communication device via the unauthenticated secure channel, and verifying the secure authentication message by the second link unit, and transferring the secure authentication message to the second application. After sending the authentication message to the other application the protocol may be complete, or may be continued by further steps.

The authentication protocol may comprise transferring, in response to the secure authentication message, a response message including second identity data from the second application to the second link unit, processing the response message into a secure response message by the second link unit, transferring the secure response message to the first link unit via the unauthenticated secure channel, verifying the secure response message by the first link unit, and transferring the secure response message to the first application. After receiving the secure response on the authentication message the protocol may be complete, or may be continued by further steps. The authentication protocol may further comprise transferring, in response to the secure response message, an initiator response message including first identity data from the first application to the first link unit, processing the initiator response message into a secure initiator response message by the first link unit, transferring the secure initiator response message to the second link unit via the unauthenticated secure channel, verifying the secure initiator response message by the second link unit, and transferring the secure initiator response message to the second application.

In an embodiment the authentication protocol comprises identity protection. Thereto the secure link applies encryption to the authentication messages, response messages and/or further identity data messages. Figure 2 shows a communication device. The communication device has a link unit 25 arranged for near field communication (NFC). Thereto the link unit has a front end 26, a near field communication wireless interface coupled to an antenna 24 for transmitting and receiving radio frequency energy. The front end 26 is coupled to a near field communication transceiver 27 via an interface 28. The transceiver 27 has a protocol processor 29 for executing a link layer protocol, i.e. an application independent secure protocol as described below. The link unit 25 is coupled to an application 30, which application executes an authentication protocol 32, e.g. an application dependent secure protocol or a middle ware dependent secure protocol. Figure 3 shows establishing a secure channel and trust relations. The Figure schematically illustrates the result of the link layer protocol, which results in an encrypted link 301 between a first link unit 35 and a second link unit 36. The link units may operate according to a predefined physical protocol, for example the near field communication interface protocol (NFC-IPl as defined by the NFC Forum). A key exchange 302 is part of the link layer protocol. The first link unit 35 may generate a key as illustrated by arrow 38, for example by a random generator, which is further used in the key exchange 302. Furthermore, for establishing a trust relation between the link unit 35 and an application on a higher layer 34, a key may optionally be provided from the link unit to the upper layer as illustrated by arrow 39, and/or further messages may be exchanged between the layers. The second link unit 36 may similarly establish a trust relation with a second application on higher layer 37.

In an embodiment the trust relation between the link and application layers may already be present by design, for example because both layers are physically implemented in a single processing unit and the combined software is cryptographically signed. Alternatively, the trust relation may be established once, for example during initialization or installation of the application.

Figure 4 shows establishing a secure channel and interfacing between layers. The Figure, like Figure 3, schematically illustrates the result of the link layer protocol. A key exchange 302 is part of the link layer protocol. In this example the first link unit 35 first generates a key as indicated by arrow 401, and further may receive a loaded key illustrated by arrow 402, e.g. from a secure and trusted third party source. Both keys are combined to constitute the key to be used in the key exchange 302 to establish the key used in the encrypted link 301. Furthermore the Figure shows that the higher layer 34 may access the functions of the lower layer 35 via an application program interface (API), which API is application independent and made availably to any application at the higher layers.

The following part of the description gives implementation details of the link layer protocol and authentication protocol according to the invention, which are illustrated by Figures 8 and 9. Various implementations of the link layer protocol and authentication protocol can be based on the examples of existing protocols, which are discussed with reference to Figures 5,6 and 7.

Figure 5 shows a diagram of unauthenticated key exchange. The Figures shows messages Ml, M2 and M3 being exchanged between party A (left side of the Figure) and party B (right side of the Figure). The content of each message is shown above the arrow giving the direction of the message. The notation is explained below.

Background information on key exchange is provided by the document [NIST] discussed in the introduction, and in the document [Shoup]: "V. Shoup, On formal models for secure key exchange (version 4), November

15, 1999 revision of IBM Research Report RZ 3120 (April 1999)" available from (http ://shoup .net/papers/skey.pdf) .

The example of Figure 5 is based on [NIST], and shows a modification of the Ephemeral DH - C(2,0) DHephem protocol with the key confirmation. An Ephemeral key is a key that is intended for a very short period of use. The key is ordinarily used in exactly one transaction of a cryptographic scheme; an exception to this is when the ephemeral key is used in multiple transactions for a key transport broadcast. An Ephemeral key contrasts with a static key, which is used for longer periods of time. The keys defined below in the protocols may be of either type according to the respective use. A hash function (HASH) maps a bit string of arbitrary length to a fixed length bit string. The HASH function may be used for providing an electronic, cryptographical signature. Approved hash functions satisfy the following properties:

1. (One-way) It is computationally infeasible to find any input that maps to any pre-specified output, and 2. (Collision resistant) It is computationally infeasible to find any two distinct inputs that map to the same output.

The notations and acronyms used in the protocol descriptions and in the Figures are:

KA - authentication key - K - session key g^x, g^y, g^xy - a secret known to x, y, or shared by x and y (DH values)

ID - identity code

T - data (any bit string)

NonceA, NonceB - random Nonces. A Nonce is a time-varying value that has at most a negligible chance of repeating, for example, a random value that is generated anew for each use, a timestamp, a sequence number, or some combination of these.

MAC_KA(T) represents a Message Authentication Code computed using a key KA over T. A MAC is data that allows an entity to verify the integrity of the corresponding message. A MAC function defines a family of one-way cryptographic functions that is parameterized by a symmetric key and produces a MAC on arbitrary data. A MAC function can be used to provide data origin authentication as well as data integrity.

SIGNχ(Y) represents a cryptographical Signature with private key X over Y

KDF represents a Key Derivation Function (as explained below) - T₁ = (g^x, g^y)

T₂ = (g^y, g^x)

KE = encryption key

ENC_KE(T) represents a symmetric encryption of T with a key KE The protocol of Figure 5 allows deriving the keys based on: (KA, K) = KDF 1 (Nonce_A, Nonce_B, g^xy)

Figure 6 shows a diagram of SIGMA key exchange. The diagram uses the same notation as Figure 1 , whereas the messages have a different content as indicated in the Figure. The identity ID_A and ID_B of the parties is exchanged also. SIGMA denotes a protocol based on cryptographical signature (SIGN) and message authentication (MAC) proposed in the document [Rrawczyk]. The protocol subsequently allows deriving the keys based on:

(KA, K) = KDFl (Nonce_A, Nonce_B, g^xy)

Figure 7 shows a diagram of SIGMA key exchange with Initiator Identity Protection. The diagram is similar to Figure 6, but now the identity of the initiator of the protocol (party A in the Figure) is not transferred in plain messages, but encrypted in M2. Hence, parties not having the key KE cannot derive the identity of party A. The protocol subsequently allows deriving the keys based on:

(KA, KE, K) = KDFl (Nonce_A, Nonce_B, g^xy)

The invention as further illustrated in the Figures 8,9 is an extension and modification of the above protocols, and uses generally the same notation, unless otherwise indicated. The setup of the secure authenticated channel is formally split into layers, and each entity involved is subdivided into two entities for respective layers. The entities on both layers are called Application and Link. Hence four entities (forming two pairs) are involved in a two phase protocol, wherein the following assumptions hold:

The Links are responsible for the execution of the key exchange protocol. - The Links have no identity data (ID) and hence no way to authenticate.

The Applications have an identity data ID and way(s) to authenticate itself.

The Links provide to the Applications information, which does not reveal anything related to the security of the key exchange protocol itself (e.g. the established shared secret g^xy). The Applications provide back to the Links Signatures over the provided information and their IDs.

The Applications do not provide their credentials to the Links. At the end, an authenticated secure channel is established between the Applications (via the Links), and

Shared secret key K is derived by the Links, which (the key) can be hidden or exposed to the Applications.

Note that this architecture is non-standard and the differences are crucial. For example trust relations are required between and the responsibilities of the Application and the Link. An embodiment of the invention is based on protocols which are combination of Shoup's Diffϊe-Hellman Key Exchange DHKE [Shoup] and the SIGMA protocols from [Rrawczyk], but are designed to fit to the assumptions made above. A common solution for practical situations is that the Applications give their credentials to the Links who establish the channel on their behalf impersonating the Applications in this way. Figures 8 and 9 give two solutions: authenticated and authenticated with initiator identity protection. As shown in [Krawczyk], the protocols with identity protection can protect passively both identities but against active attacker only one of the identities of the participants can be protected. Figure 9 shows to protect the identity of the initiator; the modification of the protocol for the other case is straightforward. Figure 8 shows a diagram of a setup of a Secure Authenticated Channel. The setup of the SAC is based on a two layer Authenticated key exchange scheme. In the Figure party A has two layers, a lower layer called Link A and an upper layer called Application A. Similarly, party B has two layers, a lower layer called Link B and an upper layer called Application B. In a first phase of the protocol a link layer protocol 81 establishes an unauthenticated link by the messages M1-M4. Subsequently in a second phase, as indicated by dashed line 80, the application layer executes an authentication protocol 82 via the lower layer unauthenticated link, via messages MA1-MA6 between the upper and lower layer A, messages M5-M8 via the link, and messages MB1-MB4 between the upper and lower layer B. The following notations have been used for the SAC setup via the two layer

Authenticated key exchange in the Figure: Signχ(Y) is:

MACcommonPreSharedSecret(Y) Or SIGNp_πvateKey(Y) Sign is performed by the application, which possesses either a Common Secret (e.g. Symmetric Key derived from PIN, Password, etc.) or Private Key.

IDχ is a public part of an identity code, corresponding to a private (secret) part of the ID, e.g. a certificate in the case of a private key, or a user name in the case of password. - T₃ could be Ti or HASH(Ti) or MAC_KA(T_I)

T4 could be T2 or HASH(T2) or MACKA(T2) HASH(T) represents a hash function computed over T KT - temporary key Appl X is the identity of application X - Req(U) is a request with parameter U is a request to establish a channel with U

Req_Signχ(Y) is a request to apply a signature Signχ(Y) Check_Signχ(Y) is a request to verify the signature Signχ(Y) The protocol allows to derive keys KA and KT from the shared secret g^xy:

(KA, KT) = KDFl(Nonce_A, Nonce_B, g^xy) and to derive K from KT, IDA and IDB

K = KDF2 (ID_A, ID_B, KT)

Figure 9 shows a diagram of a setup of a Secure Authenticated Channel with identity protection. The setup of the SAC is based on a two layer Authenticated key exchange with Initiator Identity Protection. In the Figure party A has two layers, a lower layer called Link A and an upper layer called Application A. Similarly, party B has two layers, a lower layer called Link B and an upper layer called Application B. In a first phase of the protocol the link layer protocol 91 establishes an unauthenticated link by the messages M1-M4. Subsequently, in a second phase, as indicated by dashed line 90, the application layer executes an authentication protocol 92 via the lower layer unauthenticated link, via messages MA1-MA6 between the upper and lower layer A, messages M5-M8 via the link, and messages MB1-MB4 between the upper and lower layer B.

The diagram of Figure 9 is similar to Figure 8, but now the identity of the initiator of the protocol (party A in the Figure) is not transferred in plain messages, but encrypted in M7. Note that first the Signature of party B has been verified as shown in message MA3. Hence, the identity of party A is only transmitted after knowing the identity of party B.

The notations of Figure 8 have been also used for the two layer Authenticated key exchange with Initiator Identity Protection of Figure 9. The protocol allows deriving the keys KA, KE and KT from the shared secret g^xy, as follows: (KA, KE, KT) = KDFl(Nonce_A, Nonce_B, g^xy)

In an embodiment the keys may be derived by a key derivation function KDF based on the document [IPSEC]. The Key Derivation Functions KDFl and KDF2 based on [IPSEC] are: - KDF 1 (Nonce_A, Nonce_B, g^xy) = PRF+( Nonce_A 11 Nonce_B, g^xy), where:

U Il V denotes the bit-string concatenation of U and V, and PRF = Pseudo Random Function KDF2(ID_A, IDB, KT) = PRF(KT, ID_A 11 ID_B) PRF+(K,T) = Ti Il T₂ 1) T₃ || ... - Ti = PRF(K, T Il OxOl)

- T₂ = PRF(K₅ Ti Il T Il 0x02) - T₃ = PRF(K, T₂ 1) T Il 0x03)

PRF(KJ) = MAC_K(T) The above protocols can be used in near field communication (for example as proposed by the NFC Forum, see http://www.nfc-forum.org/), wireless communication in networks (for example as proposed in the IEEE 802.11 Wireless Communications standards, see in particular IEEE 802.1 Ii regarding security), or any network or data communication which require a SAC between applications. An example is access control, where an NFC Forum Device is used instead of, but like, an ID card to enter a restricted area (physical or virtual). Practical cases include: a company ID card for entering buildings, a network access card, an automobile lock key (also for ignition which would probably need a separate section), a parking garage elevator key, a hotel elevator key, a hotel room lock key.

Further examples include PC sharing, file sharing, multimedia from various sources, such as rendering images, background video, games, gathering and storing viewing data and text reviews, etc. Commonly such applications may use content data, and require digital rights management technology.

A practical example is configuration of various user devices that are intended to communicate via a further communication interface, for example a wireless communication interface for constituting a mobile phone, a wireless communication interface for constituting a wireless network device, or a wireless communication interface for constituting a Bluetooth device. The user devices may first apply the SAC on a near field communication interface as described above for initialization or installation. Subsequently the devices communicate via a further connection based on data exchanged via the secure authenticated channel. Also an intermediate device (e.g. a small user ID card or tag) may be used to temporarily establish a SAC with each of the user devices.

For example, a user purchases a wireless network (WiFi) base station and needs to transfer its initial configuration (secure ID SSID, wireless keys WEP/WPA, etc) to client devices. Using near field communication he touches the base station to each device, and they configure themselves and switch to using WiFi for communication. Alternatively, the configuration is transferred to a separate tag or device that is used for the client configuration rather than the base station. In a further example, a user wishes to exchange initial Bluetooth configuration information between two devices such as a mobile phone and a headset or an audio player and set of external speakers. Doing so via a separate SAC might provide a more secure Bluetooth pairing, and could be an easier process for the user.

It is noted, that in this document the word 'comprising' does not exclude the presence of other elements or steps than those listed and the word 'a' or 'an' preceding an element does not exclude the presence of a plurality of such elements, that any reference signs do not limit the scope of the claims, that the invention may be implemented by means of both hardware and software, and that several 'means' may be represented by the same item of hardware. Further, the scope of the invention is not limited to the embodiments, and the invention lies in each and every novel feature or combination of features described above.

Claims

CLAIMS:

1. Method for establishing a secure authenticated channel between applications having authentication means via a medium in a communication system, which system comprises: a first communication device (10) accommodating a first application (12), and - a second communication device (20) accommodating a second application

(22), the method comprising: first executing a link layer protocol (81) for establishing, on a link layer, an unauthenticated secure channel between the first and second communication devices by exchanging link layer protocol messages, and subsequently executing an authentication protocol (82) for establishing, on an application layer, authentication between the first and second application, the authentication protocol comprising transferring an authentication message from the first application to a first link unit in the first communication device, processing the authentication message into a secure authentication message by the first link unit, transferring the secure authentication message to a second link unit in the second communication device via the unauthenticated secure channel, and - verifying the secure authentication message by the second link unit, and transferring the secure authentication message to the second application.

2. Method as claimed in claim 1, wherein the authentication protocol (82) comprises: - transferring, in response to the secure authentication message, a response message including second identity data from the second application to the second link unit, processing the response message into a secure response message by the second link unit, transferring the secure response message to the first link unit via the unauthenticated secure channel, verifying the secure response message by the first link unit, and transferring the secure response message to the first application.

3. Method as claimed in claim 2, wherein the authentication protocol (82) comprises: transferring, in response to the secure response message, an initiator response message including first identity data from the first application to the first link unit, processing the initiator response message into a secure initiator response message by the first link unit, transferring the secure initiator response message to the second link unit via the unauthenticated secure channel, verifying the secure initiator response message by the second link unit, and transferring the secure initiator response message to the second application.

4. Method as claimed in claim 1, wherein the authentication protocol (92) comprises identity protection by said processing the message into the secure message including encrypting the message.

5. Method as claimed in claim 1, wherein the method comprises: establishing a trust relation between the first application and the first link unit, and/or establishing a trust relation between the second application and the second link unit.

6. Communication device, which device comprises: a processing unit (13) accommodating a first application (12), the communication device constituting a first communication device being arranged for establishing a secure authenticated channel between applications having authentication means via a medium in a communication system, which system further comprises a second communication device accommodating a second application, the communication device being arranged for: first executing a link layer protocol (81) for establishing, on a link layer, an unauthenticated secure channel between the first and second communication devices by exchanging link layer protocol messages, and subsequently executing an authentication protocol (82) for establishing, on an application layer, authentication between the first and second application, the authentication protocol comprising: - transferring an authentication message from the first application to a first link unit (11) in the first communication device, processing the authentication message into a secure authentication message by the first link unit, transferring the secure authentication message to a second link unit in the second communication device via the unauthenticated secure channel, and verifying the secure authentication message by the second link unit, and transferring the secure authentication message to the second application.

7. Communication device as claimed in claim 6, wherein the link unit (25) comprises means (24,26) for wireless near field communication, which near field communication constitutes the medium in the communication system.

8. Communication device as claimed in claim 6, wherein the device constitutes at least one of the following: - a user identity card; a network access card; an automobile lock key; a parking key; a hotel key.

9. Communication device as claimed in claim 6, wherein the device comprises at least one of: a further wireless communication interface for constituting a mobile phone; a further wireless communication interface for constituting a wireless network device; a further wireless communication interface for constituting a Bluetooth device.

10. Computer program product for establishing a secure authenticated channel between applications having authentication means via a medium in a communication system, which program is operative to cause a processor to perform the method as claimed in claim 1.