DE202020002785U1 - Cryptographic headset - Google Patents

Abstract

Headset (11) with an encryption and / or decryption module which encrypts an audio signal recorded via a microphone and forwards this encrypted signal via an interface to a device or network and / or receives an encrypted audio signal via an interface from another device or network , decrypts it and outputs it on a loudspeaker.

Description

The invention relates to a headset with integrated encryption or cryptographic capabilities.

State of the art

So far, communication participants have not been able to protect themselves from eavesdropping on their cell phone connection in a simple way. This is because they have no influence or trust in the devices or transport media used. The devices (e.g. smartphones) or the programs installed on them could be compromised, for example through interfaces that are expressly prescribed for connection eavesdropping (backdoor, federal Trojan).

Transfers are often protected by what is known as transport security / transport encryption. In this way, the Bluetooth connection between a headset and the smartphone is securely encrypted in all Bluetooth headsets on the market. However, the data is then decrypted on the smartphone and is susceptible to eavesdropping.

Devices or methods for secure transmission are, for example, from the document CN000105025404A known. There a Bluetooth headset is described, which should enable a secure connection between any number of conversation partners. To do this, the connection is established and the two headsets are recognized using Dual-Tone Multi-Frequency (DTMF).

On closer inspection, however, problems and a glaring security gap are revealed. Because if the DTMF tones are triggered via the keypad of the smartphone, the type of tone transmission depends on the cellular standard used, i.e. H. from the cellular network that a smartphone is currently logged into.

When transmitting via a GSM network, the DTMF tones are transmitted "inband", i. H. During the call, the smartphone sends a message to the telecommunications network that a DTMF tone should be transmitted. This tone is then generated within the network, integrated into the audio data stream and then transmitted on. At the receiver, these tones must be recognized by appropriate filters from the mix of speech and DTMF tones.

With UMTS and later standards, the DTMF tone transmission takes place "outband", i. H. the smartphone transmits the audio data stream and separates the DTMF tones. If both call participants are registered in the cellular network via UMTS, the transmission remains separate up to the recipient.

The document does not describe how the tones are intended to be produced. In principle, only two variants remain, one via the keyboard or an app that imitates the keyboard or the tones must be generated in the headset so that they can then be transmitted within the audio connection (as with the GSM network).

The first technical problem results from the fact that the integration and error-free extraction in or from the audio data cannot be guaranteed. The background to this lies in the way in which speech is coded and compressed over the cellular network and especially over the GSM network (keyword LPC - Linear Predictive Coding).

The second problem is the quantity of data that can be transmitted over DTMF tones. The specification of the European Telecommunications Standards Institute (ETSI) states that a maximum of six DTMF tones can be transmitted per second. For practical reasons, it is therefore impossible to establish a secure connection because either not enough data can be transmitted or the data cannot be transmitted in an appropriate / practicable time window.

The script states that it has disclosed a secure communication path using the Bluetooth headset. However, regardless of the technical problem, a security risk becomes apparent instead. Even if the encryption described works, it does not protect against a man-in-the-middle attack.

It is possible to listen in on a conversation via interfaces prescribed by law. Such an interface is suitable for bypassing the safety mechanism. To do this, an attacker uses the interface for eavesdropping and requires two devices, as suggested in the document. The first device is used for decoding and the second is used to encode again and then to connect with the conversation partner. The encryption between the two devices is canceled and neither of the call partners notice that they are being overheard.

The task now is to provide a headset that enables a secure connection with end-to-end encryption between two call partners who use the make calls to each other on the public mobile network with standard end devices (smartphones).

Disclosure of the invention

In contrast, the device or system according to the invention with the features of the independent claims has the advantage that eavesdropping is not possible either through a compromised smartphone or within the telecommunications network.

Here, a device contains or comprises a headset with an encryption and / or decryption module. This encrypts an audio signal recorded via a microphone. This or the headset forwards this encrypted signal to a device or network via an interface. Alternatively or additionally, the headset (or the decryption module) can receive an encrypted audio signal via an interface from another device or network, decrypt it and, if necessary, output it on a loudspeaker.

The encryption takes place independently of the digital representation (e.g. compressed or uncompressed) of the audio signal - the necessary information on the audio codec used is integrated into the encrypted data stream.

In a further embodiment, the headset comprises that the interface is a wireless interface and the forwarding or receiving of the signals or data is implemented by means of Bluetooth. The device is a user equipment (smartphone).

In a further embodiment, the headset divides the (digitized) audio signal for forwarding to a first and second data channel (audio multiplexing). Alternatively or additionally, the headset combines received data from a first and second data channel and combines / aggregates them to form an audio signal.

Furthermore, the system for carrying out a method for encrypting a voice connection includes a headset that encrypts an audio signal recorded via a microphone and forwards this encrypted signal to another device or network. Alternatively or additionally, the headset receives an encrypted audio signal from another device or network, decrypts this and outputs it on a loudspeaker.

In a further embodiment of the system, the audio signal is transmitted wirelessly. Bluetooth is used as the transmission protocol. The device is a user equipment (smartphone).

In a further embodiment of the system, the establishment of a connection is initiated by a program that is installed on the user equipment. To do this, it creates a secure connection to a server. It transmits a desired remote station (called party) to this. It receives an authentication token from the server, which the remote station also receives from the server. In this way, encryption is agreed with a program on the user equipment of the remote station. Correspondingly, it is also possible to integrate the invention described here into existing messenger and communication solutions and to process it using existing servers from third-party providers. However, this assumes that the headset can be clearly identified worldwide.

In a further embodiment of the system, the headset itself takes on the authentication functions described in the previous paragraph and / or going beyond this for the server (s) and other suitable remote stations. The headset can implement the FIDO2 standard and thus enable registration to any services that support this standard. To do this, the headset receives two things: the address (globally unique ID of the headset called or its IP address) and its public key.

In a further embodiment of the system, the headset establishes the connection to the headset of the counterpart by so-called Bluetooth tethering using the Internet access of the user equipment connected via Bluetooth. In a further embodiment of the system, the headset provides all of the aforementioned functionalities instead of Bluetooth using a wireless LAN connection. Other connection standards such as ZigBee can also be used. A person skilled in the art recognizes that the headset according to the invention can also have interfaces for a combination of different connection standards, for example WiFi and ZigBee. It goes without saying that headsets with different designs, for example a W-LAN-based and a USB-connected headset, can communicate with one another.
The following combinations are particularly relevant: Bluetooth with W-Lan, W-Lan with Zig-Bee, Bluetooth with USB tethering, W-Lan with USB tethering.

In a further embodiment of the system, the headset provides all of the functionalities mentioned before the last paragraph using USB tethering to the user equipment (which in this case is expanded to include the device classes laptop, tablet and PC).

In a further embodiment of the system, the program on the user equipment sends the information necessary for the encryption to the headset via Bluetooth via a secure connection.

In a further embodiment of the system, regardless of the underlying transmission technology, the headset offers an encrypted data stream enriched with addressing information in such a way that forwarding to the recipient is guaranteed (solely) by a so-called device driver in the user equipment.

In a further embodiment of the system, a first data channel (voice component) is established using the regular voice channel (5G / LTE / UMTS / GSM audio) of the cellular network between the headset and the headset of the remote station.

In a further embodiment of the system, the first data channel is established as part of the hands-free mode / profile of the Bluetooth standard.

In a further embodiment of the system, a second data channel (IP component) is established between the headset and the headset of the remote station by establishing a serial Bluetooth connection between the headsets and the user equipment. The user equipment is connected to one another via a backend server.

In a further embodiment of the system, a second data channel (IP component) is established between the headset and the headset of the remote station by establishing a serial Bluetooth connection between the headsets and backend server (s) via Internet gateways.

In a further embodiment of the system, the headset divides the (digitized) audio signal for forwarding to a first and second data channel (audio multiplexing). Alternatively or additionally, the headset receives data from a first and second data channel and combines them to form an audio signal. This audio signal can be output on the loudspeaker.

Furthermore, a device includes an adapter with a connection for at least one loudspeaker and at least one microphone, an encryption and / or decryption module and a connection to a device by means of a plug connector. The encryption module encrypts an audio signal received via the microphone connection and forwards this encrypted signal to the device via the connection using a connector.
Alternatively or additionally, the adapter receives an encrypted audio signal from the other device via the connector by means of a connector, decrypts it with the decryption module and outputs it to the connector for at least one loudspeaker.

In a further embodiment of the adapter, the connection for the at least one loudspeaker and the at least one microphone is implemented by means of a wireless interface using Bluetooth.

The terms user equipment and smartphone are used synonymously here. This device is assigned to a communication participant or his headset and can also include a tablet, computer or other device that can be connected to a network, cellular network, landline network or the Internet. In this respect, consumer equipment can also be included.

The terms program and app are also used synonymously. Both comprise executable code, designed to communicate with other devices or programs / apps installed on them, if necessary.

A loudspeaker is used to convert an electrical audio signal into an acoustic audio signal. This can e.g. B. include membrane headphones or in-ear headphones in a headset. Two speakers (or microphones) can provide stereo functionality, e.g. B. within a one-piece headset.

Further exemplary embodiments are described and explained in more detail below with reference to the accompanying figures.

• 1 eine Darstellung der verschlüsselten Verbindung mit bestehenden Komponenten;
• 2 Stufen des Verbindungsaufbaus;
• 3 eine Darstellung der Übertragung über zwei Kanäle;
• 4 einen Signalverlauf eines abhörsicheren aktiven Gesprächs;
• 5 einen USB-Adapter.

Show it:

• 1 a representation of the encrypted connection with existing components;
• 2 Stages of connection establishment;
• 3 a representation of the transmission over two channels;
• 4th a waveform of a secure active call;
• 5 a USB adapter.

As in 1 shown comprises a structure for establishing an encrypted end-to-end connection 19th at least two headsets according to the invention 11 , 12 in which the encryption / decryption takes place.

In a bidirectional communication, each headset comprises an encryption and a decryption module. The audio signal recorded via the respective microphone is converted into a digital signal and encrypted before it is transmitted to the respective smartphone 13 , 14th over a connection 15th , 16 z. B. via Bluetooth is passed. Conversely, an audio data signal received by the respective smartphone is in the headset 11 , 12 decrypted, converted into an analog audio signal if necessary and output acoustically on headphones / earphones.

In modifications, the headset can also comprise only headphones (with loudspeaker) or only a microphone if only a unidirectional connection is necessary / desired.

The smartphones 13 , 14th , establish a connection to each other via transmission masts 17th and the intervening telecommunications network 18th on. This creates a secure end-to-end connection (viewed at a higher level) 19th between the two headsets 11 , 12 manufactured.

There will now be a conversation at some point between the two headsets 11 , 12 , e.g. B. on the radio interface smartphone 13 , 14th to the transmitter mast 17th or within the telecommunications network 18th , tapped, then it is impossible to extract the original audio sequence due to the end-to-end encryption implemented on the headset.

In the present case, a communication connection is divided into two parts, a call setup and the active call.

In 2 shows how the call setup is characterized by the fact that the moment the connection is established by the smartphone 13 initiated, the installed app establishes a secure connection to the project server. This is used to prepare for the encryption.

In doing so, it is transmitted to the server which telephone number is called. The server now generates a single-use authentication token for the following call and sends it to the caller's app.

With the other party, the app on the smartphone is contacted by the server via a secure connection and informed of the upcoming call. The authentication token is also transmitted for mutual checking and to prevent any compromising situation. A so-called man-in-the-middle attack is thus also effectively prevented.

Alternatively, the secure connection can be established using session keys that are sent from the server for each voice connection 31 newly generated and z. B. by Diffie-Hellmann-Merkle key exchange from the server 31 to the communication partner 11 , 12 , 13 , 14th be transmitted. All communication between headset (s) and server is secured by TLS in the current version. The repeated generation of a session key each time a call is set up means that replay attacks are ineffective.

In addition, this procedure optionally also includes an authentication of the two call participants and thus ensures a complete cryptographic process.

The initial connection between the headset and the server (possibly initiated with the help of an app or directly from the headset) can be secured by certificates that confirm the authenticity of the server. In return, a certificate on the headset side ensures that no “counterfeit” products can be accessed on the server. The mutual authentication takes place without any action on the part of the user according to the same principle as it is e.g. B. is used in online banking. The server is then no longer involved in the effective data transfer. It only provides a secure - direct - connection between the interlocutors.

The encryption method depends on the implemented microcontroller. An AES-256 (bit key length) can be used. This method is approved in the USA for documents with the highest level of confidentiality. It is important that no more data is transmitted unencrypted during a call.

In the embodiment that supports the FIDO2 standard, the authentication and encryption methods defined there are used. The consistent use of asymmetrical encryption methods also ensures that only the receiving headset can decrypt the data stream.

In 3 the existing connection with its encrypted data streams is shown.

The apps on the respective smartphone 13 , 14th send the information required for encryption to the headset via a secure connection 11 , 12 via bluetooth. In the headset 11 , 12 the conversation is then encrypted or decrypted.

The controller in the headset 11 , 12 communicates with the app on the smartphone 13 , 14th and this in turn (via the Internet) with the server 31 .

During a phone call about user equipment 11 , 12 the speech is usually not only digitized and transmitted, but also compressed before transmission, e.g. B. by means of audio-acoustic methods. Therefore, if binary / digital data (not audio), as they are e.g. If, for example, an encrypted audio signal is present, transmitted via the audio channel (e.g. GSM voice channel), as in a telephone call, this compression would distort it in such a way that it could not be decoded.

The aim, however, is to implement binary / digital data transmission via the audio channel (e.g. GSM audio channel). A second data channel (IP component) should begin with a serial Bluetooth connection between the headset 11 and smartphone 13 Transfer data. The total bandwidth of both channels should meet all requirements for reliable data transmission.

Based on DTMF tones, it can be examined how much data (in bytes per second) can still be transmitted deterministically over the GSM audio channel despite the lossy compression. In this context, the maximum expected latency with which the GSM audio or data arrives at the receiver is also determined.

There are different audio codecs that can be used with different effects of LPC. Therefore, when connecting the headset via Bluetooth u. a. Information about the used / supported codecs transmitted by the headset. By restricting to one / a few codec (s) possible effects of the LPC are reduced / eliminated.

Due to its structure, the LPC can be precisely described mathematically and algorithmically. This means that the result of the LPC is predictable and can be determined in the headset by means of a corresponding calculation. This fact makes it possible to reliably transmit small amounts of data which, despite LPC in the second headset, are reliably reconstructed from the GSM voice data.

However, it may well be that the expected data transfer rate over this channel is only used to transmit checksums if the usable bandwidth is too low for completely encrypted data. In this case, this transmission path would remain an inherent part of the encrypted transmission.

In the unexpected event that it is not possible to guarantee an adequate transmission rate via the GSM channel, it is possible to shift the transmission completely to the IP channel and then to transmit "white noise" via the GSM channel.

In order to maintain encrypted communication in the event of a bad GSM connection, it would of course be useful to have the phone end the "normal" call and let everything run directly over the IP channel. It can, for. B. WLAN telephony can also be used.

Parallel to the hands-free mode, a serial Bluetooth data connection is established between the headset 11 , 12 and smartphone 13 , 14th built up. Particular attention is paid to the Bluetooth 4.X standard and higher, as this forms a basis for the second data channel.

Once conventional telephony functions have been ensured, the audio data is split into two different logical connections, which are in the headset, before transmission to the smartphone 14th of the communication partner are reassembled. The additional encryption of both channels then guarantees maximum security against eavesdropping.

1. a) bspw. nur der Datenstrom des Sprachkanals extrahiert und analysiert, um zu testen, ob hier ein Rückschluss auf den Inhalt möglich wird.
2. b) beide Datenströme aufgezeichnet werden und ebenfalls versucht, den ursprünglichen Inhalt wieder her zu stellen.

Proof of secure encryption can be e.g. B. be provided by a specially designed IMSI catcher. For this purpose, this is inserted into the communication path - as in a man-in-the-middle attack - and

1. a) For example, only the data stream of the voice channel is extracted and analyzed in order to test whether a conclusion about the content is possible here.
2. b) both data streams are recorded and an attempt is also made to restore the original content.

An even simpler verification can be achieved by installing an app that records the audio data stream. When playing, you should only hear the audio representation of the encrypted data.

The only point of attack for Bluetooth connections is the time of the first connection between the headset and mobile device - the pairing. To do this, however, the attacker must be within a ten-meter radius (Bluetooth range) around the Bluetooth device and take further precautions so that the smartphone does not detect and stop the attack. Notes placed prominently in the product packaging will raise awareness of this fact, so that the user can exercise appropriate caution.

In a more detailed representation in 4th it is suggested that the conversation or the audio signal be encrypted over two channels in parallel transfer. The encryption and decryption takes place directly in the headset 11 instead of before the data is sent to the smartphone via Bluetooth 13 be transmitted.

The smartphone 13 transmits the IP portion over the cellular network 18th to the server 31 and the voice portion over the regular communication channel of the cellular network 18th . (GSM or UMTS stands for every transmission path (e.g. also LTE and 5G) via which telephone calls are routed by the respective mobile phone provider.) First in the headset 12 on the other hand, the information is put back together and deciphered. This prevents the original communication from being intercepted at all interfaces.

In the first step, all functionalities of the hands-free profile (HFP) must be supported. After the pairing functionality has been implemented, the logical connection between the audio codec and the BT module is established. The implementation of the basic operating functions on / off and accept / hang up enable conventional Bluetooth telephony.

In parallel with the GSM audio, a second data connection (secondary channel) is established between the two headsets 11 , 12 built up. Data transmission on the secondary channel begins with audio multiplexing (splitting of the audio data between GSM audio and serial connection). Via a serial Bluetooth connection between the headset 11 and smartphone 13 the data is transmitted to the smartphone app. In the second headset 12 Finally, both channels are merged again ("audio joining"). The secondary channel is also encrypted.

The latency / asynchronicity between the 2 channels can be corrected / synchronized with the help of sequence numbers - analogous to TCP / IP. The principle is similar to that of channel bundling, which combines various physical connections (with different latencies) into one logical connection. The assembly of the data stream does not take place until the client has decrypted the data. The headset takes on both the division and the composition. Put simply, each data packet is given a sequence number before it is encrypted. This enables correct assembly after decryption.

A server that can be reached via Dyn-DNS, for example 31 provides the backend for the secondary data connection. With the client registration, the first connection between the smartphone app and the backend can be tested. Other typical server functions such as routing and load balancing round off the functionality of the backend.

This variant is especially intended for a prototype phase. Otherwise, a server can be rented from a trustworthy IT service provider, who guarantees the security of the server by taking suitable measures.

The app in the smartphone 13 should be with the backend before a phone call 31 authenticate and with its help establish a logical connection to the app of the called party. During a phone call, the encrypted audio data is transferred between the headset using the full duplex method 11 , 12 and smartphone 13 , 14th transfer.

First, the audio data must be tapped from the Bluetooth interface. The smartphone app is equipped with the necessary authorizations. The smartphone app registers with the backend via an encrypted online connection 31 and transmits the IMSI of the smartphone 13 and its phone number to authenticate the headset 11 to ensure. In the answer from the backend 31 contains the address of the app of the communication partner whose headset has previously authenticated and registered with a telephone number. With the received address it is now possible to establish a direct logical connection to the app of the called party. The encrypted audio data is transmitted via this.

A second variant is not shown in a figure, whereby in contrast to the previously presented one on the app in the smartphone 13 is waived. Instead, you can use the Bluetooth module in the headset 11 , which with the smartphone 13 connected, the Internet gateway can be accessed directly (alternatively with W-Lan via the W-Lan module, with USB tethering via the USB port). This makes it possible for the controller in the headset 11 to contact the server directly 31 via a secure connection. The rest of the process is otherwise identical to the first variant.

In a further variant, the server is no longer involved in the effective data transmission after the call has been set up. It only provides a secure - direct - connection between the interlocutors. The data of the second data channel is then transmitted by the headset 11 or smartphone 12 directly to the smartphone 14th or headset 12 transmitted to the remote station.

In 5 in a further variant, the functionality is generated by an adapter that has a hardware-based Encryption (Decrypt / Encrypt) of electronic correspondence enabled.

Loudspeaker and microphone can be connected to the adapter by means of a plug connection, e.g. B. be realized classic jack plugs. A plug for the headphones (audio-out) (preferably stereo) and another plug for the microphone (audio-in) can be provided. Also known are 4-pin jack plugs that make connections to both.

Alternatively, a wireless connection to a conventional Bluetooth headset can be established; the voice signal is protected by the Bluetooth intrinsic encryption between the headset and the adapter. In this case, the adapter would be a Bluetooth stick and instead of the jack plug connections in the figure, there would be a wireless Bluetooth connection.

The adapter can be connected to a device, which can preferably be user equipment, via a connection using a plug connector. This can preferably be implemented using a USB connector, via which the encrypted audio data is routed to the device and from there via a network.

In this way, existing headphones / microphones / headsets can advantageously continue to be used. Furthermore, the power supply for the encryption takes place stationary via the USB connection and not mobile (with battery change / charging). Communication can also be secured using non-secure apps (such as Skype).

List of reference symbols

11

Headset (caller)

12

Headset (called party)

13

User equipment (smartphone) (caller)

14th

User equipment (smartphone) (called party)

15th

Connection between headset and smartphone (caller)

16

Connection between headset and smartphone (called party)

17th

Transmission masts

18th

Telecommunication network / cellular network

19th

End-to-end connection

31

Server, backend

QUOTES INCLUDED IN THE DESCRIPTION

This list of the documents listed by the applicant was generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Patent literature cited

• CN 000105025404 A [0004]

Claims (18)

Headset (11) with an encryption and / or decryption module which encrypts an audio signal recorded via a microphone and forwards this encrypted signal via an interface to a device or network and / or receives an encrypted audio signal via an interface from another device or network , decrypts it and outputs it on a loudspeaker. Headset (11) according to Claim 1 , characterized in that the interface is a wireless interface and the forwarding or receiving of the signals or data is implemented by means of Bluetooth and the device is user equipment (13). Headset (11) according to one of the Claims 1 - 2 , characterized in that the headset (11) divides the (digitized) audio signal for forwarding to a first and second data channel (audio multiplexing) and / or the headset (11) receives data from a first and second data channel and into an audio signal connects. System for encrypting a voice connection, characterized in that a headset (11) is designed to encrypt an audio signal recorded via a microphone and to forward this encrypted signal to another device or network and / or an encrypted audio signal from another device or network to receive, to decrypt it and to output it on a loudspeaker. System according to Claim 4 , characterized in that the audio signal is transmitted wirelessly and Bluetooth is used as the transmission protocol and the device is a user equipment (13). System according to Claim 4 , characterized in that the audio signal is transmitted wirelessly and W-Lan is used as the transmission medium. System according to Claim 4 or 5 or 6th , characterized in that a connection can be initiated by a program that is installed on the user equipment (13) by establishing a secure connection to a server (31), transmitting a desired remote station to it from the server (31) receives an authentication token, which the remote station also receives from the server (31) and agrees on encryption with a program on the user equipment (14) of the remote station. System according to one of the Claims 4 - 7th , characterized in that the program on the user equipment (13) sends the information necessary for the encryption via a secure connection to the headset (11) via Bluetooth. System according to one of the Claims 4 - 8th , characterized in that a first data channel (voice component) is established between the headset (11) and the headset of the remote station (12) using the regular voice channel (UMTS / GSM audio) of the cellular network (18). System according to Claim 9 , characterized in that the first data channel is established as part of the hands-free mode / profile of the Bluetooth standard. System according to one of the Claims 4 - 10 , characterized in that a second data channel (IP component) is established between the headset (11) and the headset of the remote station (12) by establishing a serial Bluetooth connection between the headsets (11, 12) and the user equipment (13 , 14) is established and the user equipment (13, 14) are connected to one another via the backend server (31). System according to one of the Claims 4 - 10 , characterized in that a second data channel (IP component) is established between the headset (11) and the headset of the remote station (12) by establishing a serial Bluetooth connection between the headsets (11, 12) and the backend server (n ) (31) is established via Internet gateways. System according to one of the Claims 4 - 12 , characterized in that the headset (11) divides the (digitized) audio signal for forwarding to a first and second data channel (audio multiplexing) or the headset (12) receives data from a first and second data channel and combines them to form an audio signal. Adapter with: - a connection for at least one loudspeaker and at least one microphone, - an encryption and / or decryption module, - a connection by means of a connector to a device, the encryption module encrypting an audio signal received via the at least one microphone connection and this encrypted signal via forwards the connection to the device using a plug connector and / or the adapter receives an encrypted audio signal from the other device via the connection using a plug connector, this decrypted by the decryption module and outputs on the connection for at least one loudspeaker. Adapter according to Claim 14 , characterized in that the connection for the at least one loudspeaker and the at least one microphone is implemented by means of a wireless interface using Bluetooth. System according to one of the Claims 4 - 10 , characterized in that the headset carries out both the authentication and the connection to the headset of the remote station independently, then an encrypted, addressed data stream that is sent to the user equipment independently of the user equipment solely by using their transport functions in the OSI layer 3 + 4 Headset of the remote station is transmitted and can only be decrypted by this. System according to Claim 16 , characterized in that, in addition to encryption, the encrypted data is digitally signed in the headset and the authenticity of the sender is thus always guaranteed. System according to one of the Claims 4 - 13 or 16 - 17th , characterized in that in the absence of a similar remote station, conventional headset function is automatically ensured.

Images