WO2015128523A1

WO2015128523A1 - Device, system and method for the secure exchange of sensitive information over a communication network

Info

Publication number: WO2015128523A1
Application number: PCT/ES2015/070118
Authority: WO
Inventors: José Camacho Páez; Gabriel Maciá Fernández
Original assignee: Universidad De Granada
Priority date: 2014-02-26
Filing date: 2015-02-23
Publication date: 2015-09-03

Abstract

The invention ensures the secure transmission of sensitive information via the Internet, including by means of a non-reliable device (DNC). The invention relates to a reliable device (DC), to a system comprising said reliable device (DC), and to a method for the secure transmission of sensitive information by means of a system comprising the reliable device (DC).

Description

DEVICE, SYSTEM AND PROCEDURE FOR THE SECURE EXCHANGE OF SENSITIVE INFORMATION IN A COMMUNICATION NETWORK

OBJECT OF THE INVENTION

The present invention belongs to the field of communications, and more specifically to the field of security systems and procedures in the exchange of sensitive information through a communication network, such as the Internet. An object of the present invention is a new secure auxiliary device capable of communicating with a user's device to sign and encrypt the sensitive information that it will exchange with a destination server such that said information can only be decrypted on said server. . Sensitive information is not accessible or modifiable even for the user's own device, so that the possibility of malware residing on that device can access or modify it is avoided.

Another object of the present invention is directed to a system for the exchange of sensitive information comprising a secure auxiliary device such as that described.

A further object of the invention is directed to a method of operating a system for the exchange of sensitive information such as that mentioned. In addition, the invention also extends to computer programs configured to cause an electronic device to perform said procedure and to cloud applications based on said procedure.

BACKGROUND OF THE INVENTION

At present, the use of devices connected to communication networks, eminently the Internet, for the consultation and sending of information is widely extended. Many organizations make available to their customers purchasing, consultation, information storage, etc., through telematic services that make use of communication networks. A notable example of this type of services is the web service. This service allows a user, through the use of a navigation software (browser), to access certain web servers in which numerous and varied services are offered through different technologies (HTML, CSS, Scripting, etc.).

Given the sensitive and confidential nature of many of these services (access to bank data, health data, password delivery, etc.), and in order to guarantee their success, it has been necessary to develop parallel technologies. security that would allow the user to have the confidence necessary for its use. Numerous efforts have been made in this field, aimed at developing technologies that allow the secure sending of information without the possibility of it being accessed, modified or replicated by third parties. As a result of these efforts, the use of two secure protocols can now be highlighted: IPSec and TLS, the latter used in so-called secure web browsing (HTTPS).

The commented technologies seek to establish a secure tunnel between the connected end devices. In the case of secure web browsing, these devices correspond to the web browser and the web server. The secure tunnel is a cryptographic coating in the communications channel, this one comprising all the transmission means and intermediate devices whereby the information shared by the final devices passes. The cryptographic overlay prevents certain security attacks by intruders that might be located somewhere in the communications channel. First, it prevents the information exchanged (eavesdropping) from being heard. Secondly, it prevents the information exchanged (tampering) from being modified, falsified or replicated without this being perceived by the recipients. Finally, it also avoids the attack called Man in the Middle (MitM), which involves thinking about the two final entities that are communicating with each other, while in reality the communication is carried out in two parts: origin-intruder and intruder entity - destination entity.

Although the use of technologies such as HTTPS allows to reach a high degree of confidence in such a service, these technologies only focus on avoiding security threats or attacks in the communications channel. However, there is a high number of security threats located directly on the communication devices themselves.

Indeed, at present, the number of viruses and, in general, malicious software (malware) has increased exponentially, making the use of communication devices vulnerable. The presence of malware on a computer may allow an attacker steal the information that a user is entering when accessing a certain service, such as access password, checking account number, etc. The attackers have evolved the malware considerably to achieve very advanced functionality that allows for example to send to the attacker what the user of the computer types (keyloggers), or those pages through which he is browsing (spyware), etc. The malware can be independent software or be hidden as part of software previously installed on the system (Trojan). An important example related to the web service is the so-called Man in the Browser (MitB) attack, which is the equivalent of MitM when what the attacker has done is, in fact, modify the browser software.

Latest generation tools allow the design of new malware without requiring technical knowledge, which has led to an explosion in the number of malware variants developed per unit of time. This explosion questions the viability and effectiveness of traditional malware detection tools, the so-called antivirus, whose database can hardly be updated at sufficient speed to perform a successful detection. Additionally, the attackers design the malware with obfuscation or concealment mechanisms that allow in many cases to avoid detection by antivirus or antimalware.

This effect has been aggravated by the appearance and extension of the so-called smartphone, which allow access to many of the services that were traditionally accessed by PC, but in mobility. These terminals have received the attention of the attackers, who have designed a high percentage of malware for these types of platforms. Due to the battery limitations of these devices, the use of antivirus is usually limited to charging periods, which makes the proliferation of malware being drastic.

On the other hand, the current trend in corporate networks to the proliferation of access "Bring Your Own Device" (BYOD), where the worker accesses his job with a general purpose device, exposes the network security to compromised devices with malware

In summary, at present, despite the use of security technologies such as those provided in the HTTPS protocol, these technologies do not prevent access of sensitive information by malware on the user's device. DESCRIPTION OF THE INVENTION

While other solutions for secure communications have evolved along the lines of trying to ensure that the user's device remains secure (antivirus, antimalware), the solution proposed in this document assumes that it is not possible to maintain security on a device whose configuration and operation is very variable in time (installation of applications, modification of the configuration by the user, etc.), especially considering the current evolution in the development of malware code.

Therefore, the present invention is focused on extracting from the user device only those essential functions for sending and receiving sensitive information through the network and guaranteeing security in said functionalities. In addition, this invention provides the user with an additional perception of security by locating these functionalities in a separate and independent physical device.

Ultimately, the present invention solves the above problems by extending cryptographic coverage to the user's device, referred to herein as "untrusted device". To this end, it is proposed to introduce a new auxiliary device, called a "reliable device", which connects to the user's device and will run a very small software on which third-party software cannot be installed. This avoids the possibility of malware infection, since an attacker will not be able to take advantage of the existence of failures and vulnerabilities in the software of the "reliable device" to execute an attack and modify its operation.

Moreover, the installation or modification of software or firmware of this new "reliable device" by the user is not even allowed. This ensures that the operation of the device cannot be modified either by an attacker. As will be explained later in the detailed description of the invention, in any case only certain software updates aimed at eliminating potential security risks will be allowed, always under certain circumstances and in a very controlled environment, so that ensure that no malware installation occurs.

Additionally, the "reliable device" of the invention may establish a secure tunnel with a server, so that the user's device (eg smartphone, tablet, laptop), and therefore the malware installed therein, cannot access or modify the information sensitive so sent.

Throughout the present invention a series of terms will be used whose meaning is described below:

Sending information in a communications network: "Sending information in a communications network" means the sending of meaningful data using a particular communications technology. Reliable Device: "Reliable device", or DC, means a device that intervenes in the communication between two entities, allowing such information to be exchanged securely between the device and the destination entity, even through a non-originating entity. trustworthy. Untrusted Device: “Untrusted device,” or DNC, means a device on which there is no guarantee of safety. As an example, smartphones, tablets, PCs, etc. that communicate over the Internet are considered unreliable devices.

Entity: "entity" means any device that participates in a communication.

Origin Entity: "origin entity" means the one that initiates a communication.

Destination Entity: "Destination entity" means the one that responds to the communication request in a source entity.

Server: "Server" means that process, or device extension that executes said process, which offers some kind of telematic service in a communications network.

Telematic Service: "Telematic service" means any type of activity carried out in a communications network in response to a request from a client entity.

Client: "Client" means that process, or program or device extension that executes said process, which requests some kind of telematic service in a communications network. Proxy: "ProxV" means that process, or extension program or device that executes said process, which acts as an intermediary at the application level between a server and a client in some type of telematic service in a communications network. In particular, The proxy can be the server itself.

Security Server: "Security server" means a device that allows, with your participation, to establish secure communications between two other devices. Secure Communications: "Secure communications" means those that guarantee the integrity and privacy of the communication.

Digital Certificate: It will be understood as 'digit certificate!' that software document that includes the identification of an entity, the public key issued by that entity and that is signed by the digital signature of a Certificate Authority whose public key is publicly available.

Digital Signature: "Digital signature" of a software document shall be understood as the result of applying to said document a signature algorithm with a private key of an entity, and which can be checked using a verification algorithm with the public key of the same The "digital signature" is added to the software document so that it can be checked by the recipient.

Private key: An entity's "private key" means a software key generated by it in conjunction with the public key and kept secret for use in asymmetric encryption.

Public key: An entity's "public key" means a software key generated by it in conjunction with the private key and made public for use in asymmetric encryption.

Certification Authority: "Certifying authority", or AC, means that entity whose digital signature allows, without third party participation, to accept the validity of a software document.

Software Document: "Software document" means any digital file. Network: "Network" means any technology, including interconnection devices, which allows the communication of information between two or more entities, such as the Internet or GSM, UMTS, or other mobile communications networks.

The invention consists of a device (hereinafter "reliable device" or DC) that intervenes in the communication between a user device (hereinafter "unreliable device" or DNC) and a destination server (hereinafter "server" or S) when the information to be exchanged is sensitive, in such a way that it guarantees that said information is exchanged securely even in spite of carrying out the communication through the unreliable device (DNC). To do this, the trusted device (DC) signs and encrypts sensitive information using one or more unknown keys for the untrusted device (DNC), so that said untrusted device (DNC) cannot access or modify said sensitive information entered by the user. In this way, it is avoided that any malware resident in the untrusted device (DNC) can intervene or modify the information.

In addition, to avoid the possibility that the trusted device (DC) itself may be infected by malicious software or malware, the trusted device (DC) will have the installation of third-party software restricted.

A first aspect of the invention is directed to a reliable device (DC) for the secure exchange of information in a communication network between a user and a server (S), wherein said reliable device (DC) fundamentally comprises the following elements: ) Display medium (MV)

The display means allows the reliable device (DC) to show instructions or data to the user. In principle it can be implemented in different ways, although according to a particular embodiment, it can be an LCD screen or a touch screen. b) Data entry medium (MID) The data entry means allows the user to enter the sensitive information that he wishes to transmit in the reliable device (DC) for later sending. Preferably an alphanumeric keyboard or a touch screen is used. Obviously, if a touch screen is used, it will together constitute both the display medium (MV) and the data entry medium (MID). c) Cryptographic medium The cryptographic medium is responsible for signing and encrypting sensitive information entered by the user so that such sensitive information is not accessible or modifiable by the untrusted device (DNC). Similarly, this same medium will decrypt and authenticate the sensitive information that can be received in response from the server (S), and that is still not accessible to the untrusted device (DNC). Thus, although the reliable device (DC) always communicates through the untrusted device (DNC), the latter cannot access the encrypted sensitive information or modify it, and therefore any possible malware present in said untrusted device (DNC) is harmless. The way in which the signature and encryption is carried out will be described later with reference to the operating procedure of this communication system. d) Connection medium (MC)

It is a means of connection with said untrusted device (DNC) to communicate the signed and encrypted sensitive information to said untrusted device

(DNC) for transmission to the server (S) and receive information from it. The connection means can be wired or a wireless connection can be used. For example, according to preferred embodiments of the invention, a USB connection, a WiFi connection, or a Bluetooth connection can be used. e) Means of verification

The software verification medium verifies the legitimacy of a software running on the trusted device (DC) by verifying that a digital signature of the software issued by a certifying authority (CA) is valid. In addition, the reliable device (DC) of the invention is configured such that said software is either not modifiable, or is only modifiable if the new software is signed by an entity with a valid digital certificate. That is, the reliable device (DC) does not allow any software update except, in any case, software that is signed with a certificate issued by a certificate authority (AC) or by a secure server (SS) with a valid certificate. An example of a certificate authority (CA) is the National Currency and Stamp Factory. In the case of the invention, the certifying authority (CA) may be expressly created and, therefore, be only intended to sign the certificates and software of the constituent elements of the invention.

The reliable device (DC) can thus have an interface that allows the firmware or software update of the device to be controlled. In this update procedure, to prevent the installation of malicious software, a secure mechanism, implemented in hardware or firmware and not modifiable, may be enabled to verify that the new software is signed with the certificate of the certificate authority (AC) or by a secure server (SS) with a valid certificate.

The purpose of this design, as justified above, is to minimize the functionality of the reliable device (DC) to prevent its manipulation by some malicious software or malware. In this way, it can be ensured that it exclusively implements the functionalities for which it is designed.

The present invention is also directed to a system for the secure sending of sensitive information in a communication network comprising: a) Unreliable device (DNC)

This is the device that the user normally uses to exchange information with various servers through a communication network (RC), such as the Internet. For example, it may be a "smart" mobile phone, or smartphone, a tablet, a computer, etc. b) Server (S) It is a server (S) in communication with the untrusted device (DNC) through the communication network (RC). For example, it may be the server (S) where the website of the user's bank is hosted. c) Security server (SS)

The firewall (SS) is in communication with the server (S) to decrypt and authenticate the sensitive information that is sent to said server (S) by the trusted device (DC) or sign and encrypt the sensitive information in the reverse direction of the comunication. In this regard, note that there may be multiple security servers (SS) associated with different servers (S). d) Proxy (P) The proxy (P) is an intermediary device between the communication of the untrusted device (DNC) and the server (S) used to derive the information sensitive to the secure server (SS) for its signature and encryption or decryption and authentication. d) Reliable device (DC)

It is a reliable device (DC) according to the previous description that receives, signs and encrypts the sensitive information entered by a user for sending to a server (S), or receives, decrypts and authenticates the information from the server (S) to the user, using a key or keys (K ₂ ) shared exclusively by said reliable device (DC) and the firewall (SS). The reliable device

(DC) is in communication with the untrusted device (DNC) to transmit or receive such sensitive information. e) Certificate Authority (CA)

The certifying authority is responsible for signing the digital certificates of the security server (SS) and the trusted device (DC) to verify their legitimacy. You can also sign the firmware update code of the trusted device (DC), if applicable. In another embodiment, the secure server (SS) and the proxy (P) are implemented on the same physical machine. In another embodiment, the server (S) and the proxy (P) are implemented on the same physical machine. In another embodiment, the server (S), the secure server (SS) and the proxy (P) are implemented on the same physical machine.

A third aspect of the present invention is directed to a procedure for the secure exchange of sensitive information in a communication network by means of the system just described. Preferably, this procedure is executed when either the user or the server (S) determines that sensitive information will be exchanged during a conventional communication session between the two, and notify the DC as will be described in more detail later in this document. .

In one embodiment, the method is used for a user, typically a person, through a DC, to send private data securely to a server. This procedure is useful, for example, for sending passwords, PIN numbers, and the like in authentication in telematic access systems.

In another embodiment, the procedure is used for a server to send private information to a user through its DC. This case is useful, for example, for the confirmation of banking operations, as an alternative to the use of SMS as widespread in two-factor authentication.

In both embodiments, the following steps are performed: 1) The trusted device (DC) communicates, through the untrusted device

(DNC) and the communication network (RC), with the secure server (SS) and establish a secure communication session with said secure server (SS) to obtain one or more secure keys (K ₂ ) shared exclusively by said device reliable (DC) and said secure server (SS).

The establishment of the secure communication session between the trusted device (DC) and the secure server (SS) preferably includes the following previous steps:

- The untrusted device (DNC) verifies that it is connected to the reliable device (DC). - The untrusted device (DNC) verifies that the server (S) has an associated secure server (SS).

- The untrusted device (DNC) sends the secure server (SS) IP address to the trusted device (DC).

In addition, the establishment of a secure communication session between the trusted device (DC) and the secure server (SS) through the untrusted device (DNC) to obtain the secure key (s) (K ₂ ) is performed according to a second protocol (PROT ₂ ), preferably the TLS Handshake protocol.

From this point on, the steps followed depend on whether sensitive information is sent from the user to the server (S) or in reverse.

In the first case, in which it is the user who sends the sensitive information, the steps followed are:

2.a) A user enters sensitive information into the reliable device (DC) through the data entry medium (MID). 3.a) The trusted device (DC) sends to the untrusted device (DNC) the sensitive information signed and encrypted with K ₂ .

4.a) The untrusted device (DNC) sends, through the communication network (RC), the sensitive information signed and encrypted with K ₂ as part of a message to the proxy (P)

According to a preferred embodiment of the invention, prior to this shipment, the additional step of identifying, by the untrusted device (DNC), the sensitive information received from the reliable device (DC) by means of a label that is carried out is carried out Allows the proxy (P) to recognize such information within the message. Another option is that the reliable device (DC) itself has carried out this operation in one of the previous steps, so that sensitive information is already identified with a label when it reaches the untrusted device (DNC). On the other hand, preferably the communication between the untrusted device (DNC) and the proxy (P) through the communication network (RC) is carried out according to a first protocol (PROTi) that can be chosen from the following list : http, https, ftp, ssh and smtp.

5. a) The proxy (P) detects the existence of sensitive information and sends it to the secure server (SS).

6. a) The secure server (SS) decrypts and authenticates the sensitive information received and sends it decrypted to the proxy (P).

7. a) The proxy (P) sends the complete message to the server (S). Naturally, it is the server (S) that sends the sensitive information, the sound steps:

2.b) The server (S) sends to the proxy (P) a message that includes the sensitive information properly labeled. 3.b) The proxy (P) detects the existence of sensitive information and sends it to the secure server (SS).

4. b) The secure server (SS) sends to the proxy (P) the sensitive information signed and encrypted with the key or keys (K ₂ ) corresponding to the destination DC.

5. b) The proxy (P) sends, through the communication network (RC), the sensitive information signed and encrypted with K ₂ to the untrusted device (DNC).

6.b) The untrusted device (DNC) detects the existence of sensitive information and sends it to the trusted device (DC).

7.b) The reliable device (DC) decrypts and authenticates the sensitive information received and displays it on the display medium (MV). further preferred embodiment, the communication corresponding to steps 3.a, 4.a and steps 4.b, 5.b and 6.b between the trusted device (DC) and the secure server (SS) which is done through the untrusted device (DNC), the communication network (RC), and the proxy (P) for sending the signed and encrypted sensitive information with the key or secure keys (K ₂ ) is made of agreement with a third protocol (PROT ₃ ), such as the TLS Record Protocol.

In another embodiment, steps 6.a and 7.a are replaced by a direct communication between the secure server (SS) and the server (S). In another embodiment, steps 2.b and 3.b are replaced by a direct communication between the server (S) and the secure server (SS). It is easy to appreciate that with this procedure the transmitted sensitive information has never been accessible to the untrusted device (DNC), thus being safe from possible attacks related to malicious software present in said untrusted device (DNC). Later in this document this procedure is described in more detail with reference to the figures.

The described invention is directed to devices equipped with a functionality similar to that of a computer, including smartphones or smartphones, tablets, laptops, computers, servers, etc., as well as processes executed in such devices. However, the invention extends not only to such devices and processes, but also to computer programs adapted so that any such equipment can implement said processes. Such programs may have the form of source code, object code, an intermediate source of code and object code, for example, as in partially compiled form, or in any other form suitable for use in the implementation of the processes according to the invention . Computer programs also cover cloud applications based on that procedure.

In particular, the invention encompasses computer programs arranged on or within a carrier. The carrier can be any entity or device capable of supporting the program. When the program is incorporated into a signal that can be directly transported by a cable or other device or medium, the carrier may be constituted by said cable or other device or means. As a variant, the carrier could be an integrated circuit in which the program is included, the integrated circuit being adapted to execute, or to be used in the execution of, the corresponding processes. For example, programs could be built into a storage medium, such as a ROM, a CD ROM or a semiconductor ROM, a USB stick, or a magnetic recording media, for example, a floppy disk or a hard disk. Alternatively, the programs could be supported on a transmissible carrier signal. For example, it could be an electrical or optical signal that could be transported through an electrical or optical cable, by radio or by any other means.

BRIEF DESCRIPTION OF THE FIGURES

Fig. 1 shows a simplified scheme of a reliable device (DC) according to the invention.

Fig. 2 shows a general scheme of the system of the invention.

Fig. 3 schematically shows the communication protocols used to carry out the procedure according to the present invention.

Fig. 4 shows the protocol towers used in sending sensitive information between a reliable device (DC) and the secure server (SS). Fig. 5 shows a general scheme of the system of the invention when the server (S) and the proxy (P) are implemented in the same physical machine.

Fig. 6 schematically shows the communication protocols used to carry out the procedure according to the present invention when the server (S) and the proxy (P) are implemented in the same physical machine.

PREFERRED EMBODIMENT OF THE INVENTION An example of a method according to the present invention is described in greater detail with reference to the attached figures.

Fig. 1 schematically shows a reliable device (DC) where the display means (MV) or screen through which data is shown to the user and the data entry medium (MID) or keyboard for the user to be seen You can enter sensitive information. As previously mentioned, these two elements could be integrated into a single element in case a single touch screen is used, or even belong to different devices (for example, independent screen and keyboard). The means of communication (MC) with the unreliable device (DNC) is also appreciated. For example, it can be a USB or Bluetooth type connection.

The reliable device (DC) also comprises a cryptographic medium of the sensitive information to be sent and a software verification means. However, these means are not represented in Fig. 1 because they are implemented through processes governed by the software of the reliable device itself (DC). In addition, as previously described in this document, the reliable device (DC) is configured in such a way that it does not allow the modification of its internal software except in very particular cases.

Fig. 2 shows an example of a system for the secure delivery of sensitive information according to the present invention. It is appreciated how the reliable device (DC) is in communication with the untrusted device (DNC), which, in turn, can communicate with the proxy (P) through the communication network (RC). A secure server (SS) also connected to the communication network (RC) will decrypt and authenticate sensitive information sent from the trusted device (DC) and sign and encrypt sensitive information sent to the trusted device (DC). A server (S) also connected to the communication network (RC) will carry out the traditional telematic service. In yet another preferred embodiment, both the server (S) and the secure server (SS) connect to the communication network (RC) through the proxy (P), rather than directly. The trusted device (DC) can have a certificate (CERT _DC ) and the firewall (SS) can have a certificate (CERT _S s) - These certificates will allow their authentication and the establishment of a secure session between them. Fig. 2 also shows the certificate authority (CA) that will sign said certificates (CERT _DC ) and (CERT _S s) - The particular case in which the server (S) and the proxy (P) are implemented on the same machine It can be seen schematically in Figure 5.

Although the proxy (P), the server (S) and the secure server (SS) have been represented as different entities, it would be possible that all or some of them were hosted on the same machine, in which case they could be implemented by processes different. In the same way, there could be a secure server (SS) associated with each of the servers (S) of the same corporation, or there could be a secure server (SS) associated with a group of servers (S). Any alternative would be valid as long as the functionality described here is maintained.

Next, as shown schematically in Figure 3, the mechanisms and communication protocols between the described entities that make up the example of the system of the invention are described. Figure 6 schematically represents the particular case in which server (S) and proxy (P) are implemented in the same physical machine.

a) Unreliable device communication (DNC) - proxy (P).

It is a communication based on a traditional protocol (PROT _Í ) of communications, such as HTTP, HTTPS, FTP, SMTP, etc. In the case of using a secure protocol (such as HTTPS), the information transmitted on this connection is encrypted with a Ki key shared between the untrusted device (DNC) and the proxy (P), which has been generated securely following the rules of operation of a protocol like TLS.

The HTTPS secure protocol may require that the proxy (P) have a certificate conveniently signed by a certificate authority, which in principle will be different from the system's certificate authority (CA). This is so with the objective that the protocol (PROT ^ can follow the most widespread standards of use so that it is compatible with the largest possible number of devices and systems.

The embodiment of the invention requires including certain additional elements in PROTi. First, the proxy (P) must publish that it can make secure connections according to the present invention. To do this, when sending a request for information, for example a form, it will include a meta parameter (meta-tag) with the access information to the secure server (SS):

In order that the proxy (P) and / or the untrusted device (DNC) can distinguish the elements of sent sensitive information (referred to in continued as SEC), such information will be highlighted with a specific tag or "tacf for that purpose, for example:

Reliable device communication (DC) - server (S).

This communication constitutes the core of the invention, since it is the one that allows the sending of sensitive information through the reliable device (DC) path - untrusted device (DNC) - communication network (RC) -proxy (P) - server (S) without the untrusted device (DNC) being able to obtain any information about the transmitted sensitive data. Communication takes place in two phases, each controlled by a different protocol.

one . Establishment of a secure session between trusted device (DC) and secure server (SS) (PROT ₂ ).

Establishing a secure session between the trusted device (DC) and the firewall (SS) requires that at least three conditions be met:

i) that the trusted device (DC) is connected to the untrusted device (DNC),

ii) that the server (S) has an associated firewall (SS), and

¡Ü) that the trusted device (DC) can establish the location of the secure server (SS).

The first two conditions can be checked by the untrusted device (DNC), which can in turn send the required information to the trusted device (DC) to meet the third condition. This does not imply any vulnerability in the system that involves the risk of capturing sensitive data by the untrusted device (DNC): if the untrusted device (DNC) does not respond to communication with the trusted device (DC) or if does not confirm the existence of a secure server (SS), sensitive data will not be sent. The verification of the connection of the reliable device (DC) to the untrusted device (DNC), condition (i), can be carried out with the installation in the untrusted device (DNC) of a specific driver for the reliable device (DC) ) to notify when the latter has been inserted / connected to / with the first one.

The availability of a firewall (SS), condition (ii), can be transmitted by the proxy (P) to the untrusted device (DNC) as part of the communication between the two using the protocol (PROTi). For example, if the protocol (PROTi) is the HTTP protocol, the availability of a secure server (SS) can be published in the source code of the web page itself that contains any form with a request for sensitive data. For this, the domain name or the IP address of the secure server (SS) will be included in the web page sent with the form. If the domain name were included, it would be the untrusted device (DNC) responsible for converting it to an accessible IP address. Finally, the untrusted device (DNC) will send to the trusted device (DC) the IP address of the secure server (SS) so that the latter initiates the connection, condition (iii). This last step also does not imply a system vulnerability that could consist of sending by the unreliable device

(DNC) of a false IP that will redirect the communications of the trusted device (DC) to a false server controlled by a potential attacker, since secure communications ensure the identity of the two ends of the communication, or at least the secure server ( SS), with certificates signed by the certifying authority (CA).

From this moment on, the trusted device (DC) can start a secure session with the secure server (SS). Since the trusted device (DC) does not have its own network interface, you must use the untrusted device (DNC) as a bridge to establish that session. The untrusted device (DNC) must act in this case as a mere intermediary between the trustworthy device (DC) and the firewall (SS), by forwarding the messages between them. The secure session must ensure the confidentiality and integrity of the information as well as avoid repetition attacks. Additionally, the identity of at least the secure server (SS) must be verified, which will accredit it with the certificate (CERT _SS ), signed by the certifying authority (AC). Ideally, the identity of the trusted device (DC) will also be verified, if it has the certificate (CERToc), to avoid the potential proliferation of fraudulent replicas of the trusted device (DC) that make connections with third servers to steal sensitive information. This is the reason why, without loss of generality, the existence of a certificate authority (CA) that signs the certificates for both devices is conceived. The negotiation corresponding to the cryptographic algorithms to be used during the secure session, as well as the associated keys and the verification of authentication certificates, will be carried out during the connection establishment.

For (PROT ₂ ), which is a secure session establishment protocol, well-known standards can be used, such as the TLS Handshake Protocol (TLSHP, RFC 2246). This protocol allows two entities to negotiate a set of parameters in a secure way to establish a secure session. In particular, the algorithms of compression, integrity and encryption of the data used in both ends are negotiated, as well as the corresponding keys for use in both directions of communication. If TLSHP is used, the untrusted device (DNC) will act as a TLS proxy. Each secure session is identified with a secure session identifier (ISS), so that the secure server (SS) can identify the trusted device (DC) that sends the data and can decrypt and authenticate, or sign and encrypt, with the key or corresponding K ₂ keys. In short, as a final result of this protocol (PROT ₂ ) a secure session will be established between the trusted device (DC) and the secure server (SS), which will be identified by a secure session identifier (ISS, together with one or several keys shared between both entities (K ₂ ) with which to sign and encrypt the information exchanged.

2. Sending sensitive information through a tunnel between the trusted device (DC) and the secure server (SS) (PROT ₃ ).

Once the establishment of the secure session between the trusted device (DC) and the secure server (SS) to give K ₂ Key, sending sensitive information will be held as described below. Sending sensitive information from the user to the server (S). When sensitive information is sent from the user to the server (S), said information will be encapsulated in a secure tunnel that is established between the trusted device (DC) and the secure server (SS), and then sent to the server ( S). In this communication the following steps are followed:

First, the reliable device (DC) performs the necessary transformations on the information for safe delivery according to the negotiation at the beginning of the protocol session (PROT ₂ ). Specifically, this seráfirmada and encrypted information securely using the key or keys K ₂ obtained by the protocol (PROT ₂₎ so that it can not be interpreted in any intermediate point of communication, including the unreliable device (DNC). Additionally, it will incorporate the identifier of the secure session (ISS) with whose cryptographic material the information has been encrypted and signed (PROT ₃ ). - Second, the trusted device (DC) will forward the information to the untrusted device (DNC) using the protocol (PROT ₄ ), which will be described later.

The untrusted device (DNC) will incorporate the encrypted information received to the message it will send to the proxy (P), based on the protocol

(PROTi). To do this, you must identify the sensitive information sent, for example through a tag (eg <secret>). This tag could be incorporated by the untrusted device (DNC) in this step or by the trusted device (DC) in one of the previous steps.

The proxy (P), upon receiving the message, will detect the sensitive information badge (eg <secret>) and forward the sensitive information to the secure server (SS) using the protocol (PROT ₅ ), which will be described later. The secure server (SS) will check the ISS of the encrypted sensitive information received and, if it corresponds to any active session, will proceed to decrypt the information according to the parameters negotiated for it with the protocol (PROT ₂ ). If everything is correct, it will send the decrypted information to the proxy (P) using the protocol (PROT ₅ ), which will be described later.

The proxy (P) will replace the sensitive information encrypted with that received in the previous step and send it to the server using the protocol (PROT ₆ ), which will be described later.

The server will interpret the information in a conventional manner.

Sending sensitive information from the server (S) to the user. Alternatively, the sending of sensitive information may originate on the server (S) destined for the user. In this case, the following steps are followed:

The server (S) sends the message to the proxy (P) following the protocol (PROT ₆ ) described below. In it, you must identify the sensitive information sent, for example through a tag (eg <secret>).

The proxy (P), upon receiving the message, will detect the sensitive information badge (eg <secret>) and forward the sensitive information to the secure server (SS) using the protocol (PROT ₅ ), which will be described later.

The secure server (SS) performs the necessary transformations (encrypted and signed) on the information for secure sending, according to the negotiation at the beginning of the protocol session (PROT ₂ ). Specifically, such information will be signed and encrypted securely using the K ₂ key or keys obtained through the protocol (PROT ₂ ) so that it cannot be interpreted at any intermediate point of communication, including the untrusted device (DNC) . Additionally, it will incorporate the identifier of the secure session (ISS) with whose cryptographic material the information has been encrypted and signed.

The secure server (SS) will forward the information back to the proxy (P) using the protocol (PROT ₅ ), which will be described later.

The proxy (P) will incorporate the encrypted information received to the message it will send to the untrusted device (DNC), based on the protocol (PROT.

The untrusted device (DNC), upon receiving the information, will detect the sensitive information badge (eg <secret>) and forward said information to the reliable device (DC) using the protocol (PROT ₄ ), which will be described later.

The reliable device (DC) will check the ISS of the encrypted sensitive information received and, if it corresponds to any active session, will proceed to decrypt the information according to the parameters negotiated for it with the protocol (PROT ₂ ). If everything is correct, it will display the information in the display medium (MV).

It can be observed that sensitive information sent viajafirmada and encrypted with the key or keys K _2, shared between the trusted device (DC) and the secure server (SS) through the communication network (RC) and Unreliable device (DNC) without anyone being able to obtain any information about or modify the original information, as is intended in this invention. In Figure 4 the tower of protocols can be observed in the sending of the sensitive information and the tunnel that is built between DC and SS can be seen through the PROT ₃ .

Finally, it should also be noted that each sensitive value that the trusted device (DC) sends to the secure server (SS) or vice versa does not necessarily imply the creation of a new session with the secure server (SS), with its corresponding ISS value, but once a session is established, it could be reused for subsequent submission of new information. As a protocol (PROT ₃ ), the TLS Record Protocol (TLSRP, RFC 2246) can be used. In that case, the embodiment of the invention must incorporate some additional elements for the use of TLSRP, since communication between a reliable device (DC) and the secure server (SS) is not carried out through a single transport layer connection , as is common in TLS, but three connections are established (see Figure 4): between trusted device (DC) and untrusted device (DNC), between untrusted device (DNC) and proxy (P), and between the proxy (P) and the secure server (SS). However, the implementation of TLSRP can remain true to its specification. First, the trusted device (DC) performs the steps of the TLSRP client. First, a message authentication code (MAC) is calculated that includes the original text of the form and a sequence number within the connection. The sequence number prevents forwarding attacks. Subsequently, the original text along with the MAC is encrypted using the key for this purpose. The result is a secure TLS record, previously specified as SEC, that incorporates information from the secure session (ISS) to which it belongs and that will be sent to the untrusted device (DNC).

Reliable device communication (DC) - untrusted device (DNC) (PROT ₄ ):

Whenever you have to enter a data specified as sensitive in a form (for example, a web form, an authentication dialog in FTP, etc.), or sensitive information is received from the server, a dialogue between the trusted device will occur (DC) and the untrusted device (DNC). In this communication, different cases can be defined for the start of the aforementioned dialogue i. User initiated.

When accessing the service and sending a field with information, the user can decide that certain information is sensitive and use the reliable device (DC) to enter it. The user, therefore, must have a mechanism in the client itself (eg in the browser) that allows him to initiate this reliable device (DC) dialogue - untrusted device (DNC). This mechanism can be implemented, among others alternatives, by means of a plug-in installed in the client that allows the user to select a field as sensitive, and to initiate for that field the dialogue of reliable device (DC) - untrusted device (DNC). The plug-in would be installed together with the software (driver) of the trusted device (DC) in the operating system of the untrusted device (DNC).

I. Started by server (S).

It is also possible for the server (S) to decide that the value of an information field should be transmitted as sensitive information. To notify the untrusted device (DNC) of this fact, the server (S) may use scripting technologies (eg Javascript), so that when the user selects the field in question, the reliable device (DC) dialog automatically starts - untrusted device (DNC) if the trusted device (DC) is connected, or a request message from the trusted device (DC) emerges in the user interface of the untrusted device (DNC).

Once the scenarios in which the reliable device (DC) - untrusted device (DNC) communication would be clarified, the steps in which such communication could be developed will be described.

1) User confirmation request.

The start of the secure dialogue must be followed by a request to the user asking to confirm the use of the reliable device (DC). This confirmation can be considered done when the dialogue is initiated by the user. However, if the dialogue is initiated by the server (S) it will be mandatory, serving information to the user to connect and enter the data in the reliable device (DC).

2) Checking the connection of the reliable device (DC) with the untrusted device (DNC).

Next, there is a check that there is communication between the trusted device (DC) and the untrusted device (DNC). In case of If this does not exist or fails, the user will be notified of this event, giving the opportunity to retry the connection between both devices.

3) DNC notification of the transfer of control to the DC.

Once the connection verification has been carried out, the user will be notified that the control for entering and reading sensitive data has been passed to the reliable device (DC), making it impossible to enter other data in the browser resident on the device unreliable (DNC). For this, a notification will be used by means of a pop-up window or similar.

At this point, the steps in communicating sensitive information from or to the reliable device (DC) must be distinguished. In the first case, that is, when sensitive information is sent from the trusted device (DC) to the untrusted device (DNC):

4.a) Sending a sensitive data request message.

The untrusted device (DNC) will request the sending of the value for the field identified as sensitive. To do this, it will send a message with the following information.

- Name of the information field. This name will help the reliable device (DC) to display a message to the user requesting that field.

- Name of the firewall associated with the service. The untrusted device (DNC) will be able to obtain the associated security server (SS) following several possible mechanisms, for example, by indicating it in the script that initiates the dialogue by the server, or by means of a TAG in the information sent by the server ( S) or the proxy (P), or through a fixed extension of the domain in which the service is located (for example, serversecurity.mydomain.es). To avoid complexity in the reliable device (DC), which would make it possibly vulnerable, if necessary DNS resolution of the name of the firewall (SS), this would be done on the untrusted device (DNC). Introduction of sensitive data in the reliable device (DC).

The reliable device (DC) will present the user with a dialogue asking about the value of the requested information field. On the keyboard enabled on the reliable device (DC), the user will enter this information. Sending reply message with sensitive data.

Reliable device (DC) establish a session with the firewall following the protocol (PROT _2), sign and encrypt sensitive information with the key or keys K ₂ and send it encrypted to unreliable device (DNC). so that sensitive information is sent to the reliable device (DC): Message sending with sensitive data.

The untrusted device (DNC) will remit the value of a field identified as sensitive. To do this, it will send a message with the following information.

- Name of the information field. This name will help the reliable device (DC) to display a message to the user with that field.

TLS coded register (SEC), which includes the ISS, with the value of the signed and encrypted information field. Field decryption and authentication

The trusted device (DC) decrypts and authenticates the SEC record using the key or keys K ₂ associated with the ISS. visualization of sensitive data If the authentication was successful, the trusted device (DC) will send the decrypted information to the viewing medium (MV).

Proxy communication (P) - firewall (SS) (PROT ₅ ):

There must be a procedure from which the proxy (P) sends to the firewall (SS) sensitive information for decryption and authentication or, alternatively, for signing and encryption. The nature of such a procedure will depend particularly on the location of the firewall (SS). If the firewall (SS) is located on the same machine as the proxy (P), the communication will be based on interprocess communication procedures. If the firewall (SS) is located on a different machine but within a corporate network with a high level of security, communication can be based on unsecured network protocols. If the firewall (SS) is located on a different network, the communication must use cryptographic coatings, e.g. VPNs, to ensure that this information is not captured by intermediate elements in the network. Finally, there is always the possibility that the proxy (P) and the firewall (SS) are implemented by the same process, which would eliminate the need for the protocol (PROT ₅ ).

Each time the proxy (P) receives sensitive information encoded and identifiable by a tag (for example, the <secret> tag), it will forward the content to the secure server (SS) for decoding. Upon receiving the encrypted information, the secure server (SS) will check if there is an active session with the ISS identifier contained in the received record. If it exists, it will use the corresponding key or keys (K ₂ ) to check the integrity of the registry and decode its content. Decoded content will be sent to the proxy (P).

Each time the proxy (P) receives sensitive information for the trusted device (DC), it must first initiate a secure dialogue, as discussed above, notifying the untrusted device (DNC) of this fact, for example with scripting technologies (for example, Javascript). If the secure dialogue between the trusted device (DC) and the secure server (SS) has already been initiated, the proxy (P) will send the sensitive information that you want to send to the secure server (SS) with the associated ISS. The secure server (SS) will check if there is a active session with the ISS identifier. If it exists, it will use the corresponding key or keys (K ₂ ) to sign and encrypt information. The result will be sent to the proxy (P).

Proxy communication (P) - server (S) (PROT ₆ ):

There must be a communication procedure for the proxy (P) and the server (S). The nature of said procedure will depend particularly on the location of the server (S). If the server (S) is located on the same machine as the proxy (P), the communication will be based on interprocess communication procedures. If the server (S) is located on a different machine but within a corporate network with a high level of security, communication can be based on unsecured network protocols. If the server (S) is located on a different network, the communication must use cryptographic coatings, e.g. VPNs, to ensure that this information is not captured by intermediate elements in the network. Finally, there is always the possibility that the server (S) and the proxy (P) are implemented by the same process, which would eliminate the need for the protocol (PROT ₆ ).

Each time the server (S) wants to send sensitive information to the trusted device (DC), it will identify it with a tag (for example, the <secret> tag), and forward the content to the proxy (P) .If it is necessary to start A secure dialogue will notify the untrusted device (DNC) of this fact, for example with scripting technologies (for example, Javascript). Alternatively, as discussed above, this step can be done by the proxy (P).

The PROT ₆ can be the same protocol as the PROTi, so that the proxy is limited to replacing the sensitive information with its signed and encrypted version when the destination is the user, and replacing the sensitive information signed and encrypted with its decrypted version and authenticated when the destination is the server (S).

Secure server (SS) communication - server (S) (PROT ₇ ):

Some of the aforementioned steps can alternatively be solved using direct communication between secure server (SS) - server (S). Finally, a summary of the steps followed in a specific embodiment for sending sensitive information from a user to a server (S) according to the method of the present invention is first performed. In chronological order, the steps to follow are the following: a) First, either by the user, or by the server (S), a sensitive field is identified. As specified previously, the server (S) or the proxy (P) will publish the access information to the firewall (SS). The untrusted device (DNC) maintains a cache of secure servers (SS) connected, so that it is possible to identify if a new connection is necessary or a reliable device (DC) open connection already exists - firewall (SS) due to the previous sending of sensitive information. b) The connection between reliable device (DC) - firewall (SS), which passes control to reliable device (DC) is initiated. A warning message is sent to the user in the interface of the untrusted device (DNC) notifying said control step. Additionally, the untrusted device (DNC) sends the security server (SS) location information to the reliable device (DC), and whether or not it is necessary to initiate a new connection. c) If necessary, the establishment of a secure connection between the trusted device (DC) and the firewall (SS) is initiated, using TLSHP as the protocol (PROT ₃ ). In said establishment, the trusted device driver (DC) installed in the untrusted device (DNC) performs the retransmission of the corresponding messages using the network interface of the untrusted device

(DNC), which acts as a network proxy. Messages originating from the trusted device (DC) are forwarded through the network interface of the untrusted device (DNC) and destined for a firewall (SS). Messages sent by the firewall (SS) and received by the untrusted device (DNC) are forwarded to the trusted device (DC). d) The user writes the sensitive information in the interface of the reliable device (DC), which can be seen in the display medium (MV). e) The reliable device (DC), from the information entered, obtains the TLS SEC encoded record, which includes the ISS, integrity and order information in the session, and sends it to the untrusted device (DNC). f) The untrusted device (DNC) incorporates the SEC record between the <secret> and </ secret> tags and sends it as part of a message to the proxy (P). g) The proxy (P) detects that in some of the fields sent the labels <secret> and </ secret> appear, and sends the SEC record to the firewall (SS). h) The firewall (SS) receives the SEC record and extracts the ISS. If there is an active session with that identifier, use the associated keys to verify the integrity of the SEC record and proceed to decryption. If everything is correct, it sends the decrypted information to the proxy (P). i) The proxy (P) sends the complete message to the server (S) that interprets the information in the usual way.

Finally, a summary is made of the steps followed for sending sensitive information from a server (S) to a user, in accordance with a specific embodiment of the method of the present invention. In chronological order, the steps to follow are the following: a) First, the server (S) identifies a field as sensitive. Additionally, the server (S) will publish information on how to access the firewall

(H.H). The untrusted device (DNC) maintains a cache of secure servers (SS) connected, so that it is possible to identify if a new connection is necessary or a reliable device (DC) open connection already exists - firewall (SS) due to the previous sending of sensitive information. b) The connection between trusted device (DC) - firewall (SS) is initiated, which passes control to the trusted device (DC). A warning message is sent to the user in the interface of the untrusted device (DNC) notifying said control step. Additionally, the untrusted device (DNC) sends the security server (SS) location information to the reliable device (DC), and whether or not it is necessary to initiate a new connection. c) If necessary, the establishment of a secure connection between the trusted device (DC) and the firewall (SS) is initiated, using for example TLSHP as the protocol (PROT ₃ ). In said establishment, the trusted device driver (DC) installed in the untrusted device (DNC) performs the retransmission of the corresponding messages using the network interface of the untrusted device (DNC), which acts as a network proxy. Messages originating from the trusted device (DC) are forwarded through the network interface of the untrusted device (DNC) and destined for a firewall (SS). Messages sent by the firewall (SS) and received by the untrusted device (DNC) are forwarded to the trusted device (DC). d) The server (S) sends the complete message to the proxy (P) including the sensitive information between the <secret> and </ secret> tags. e) The proxy (P) sends sensitive information to the secure server (SS). f) The secure server (SS), from the information entered, obtains the encrypted TLS record (SEC), which includes the ISS, integrity and order information in the session, and forwards it to the proxy (P) g) proxy (P) incorporates the SEC register between the <secret> and </ secret> tags and sends it to the untrusted device (DNC) h) The untrusted device (DNC) detects that in any of the fields sent the labels <secret> and </ secret>, and forward the SEC record to the trusted device (DC), i) The trusted device (DC) receives the SEC record and extracts the ISS. If there is an active session with that identifier, use the associated keys to verify the integrity of the SEC record and proceed to decryption. If everything is correct, it sends the decrypted information to the display medium (MV).

Claims

one . Reliable device (DC) for the secure exchange of sensitive information in a communication network between a user and a server (S) through an untrusted device (DNC), characterized in that it comprises:

- a visualization means (MV) to display data or instructions to the user;

- a means of entering data (MID) so that the user can enter the sensitive information to be sent;

- a cryptographic means for signing and encrypting, or decrypting and authenticating, sensitive information such that said sensitive information is not accessible or modifiable by the untrusted device (DNC);

- a connection means (MC) with said untrusted device (DNC) for communicating the sensitive information to said untrusted device (DNC) for transmission to the server (S); Y

- a software verification means that verifies the legitimacy of software running on the reliable device (DC) by verifying that the digital signature of said software is valid, where the reliable device (DC) is configured in such a way that said software is not modifiable, or is only modifiable if the new software is signed by a valid digital certificate issued by a certificate authority (CA).

2. Reliable device (DC) according to claim 1, wherein the display means (MV) comprises an LCD screen or a touch screen.

3. Reliable device (DC) according to any of the preceding claims, wherein the data entry medium (MID) comprises an alphanumeric keypad or a touch screen.

4. Reliable device (DC) according to any of the preceding claims, wherein the connection means (MC) comprises a USB connection, a connection

WiFi or a Bluetooth connection.

5. System for the secure exchange of sensitive information in a communication network, comprising:

- an unreliable device (DNC); - a server (S) in communication with the untrusted device (DNC) through a communication network (RC);

- a proxy (P) acting as an intermediary in the communication between the untrusted device (DNC) and the server (S);

- a firewall (SS) in communication with the proxy (P) to decrypt and authenticate the sensitive information that is sent to the server (S) by the untrusted device (DNC), and to sign and encrypt the sensitive information that is refers to the user;

- a reliable device (DC) according to any of the preceding claims, which receives the sensitive information entered by a user, signs and encrypts said sensitive information using a key or keys (K ₂ ) shared exclusively by the reliable device (DC) and the firewall (SS), and which is in communication with the untrusted device (DNC) to transmit said sensitive information to it, and which receives the sensitive information sent by the server (S), decrypts and authenticates said sensitive information using a key or keys (K ₂ ) shared exclusively by the trusted device (DC) and the firewall (SS), which is in communication with the untrusted device (DNC) to receive such sensitive information and shows it to the user; Y

- a certificate authority (CA) responsible for signing digital certificates of the security server (SS) and the trusted device (DC) to verify their legitimacy.

6. System according to claim 5, wherein the firewall (SS) and the proxy (P) are implemented on the same physical machine.

7. System according to any of claims 5-6, wherein the server (S) and the proxy (P) are implemented in the same physical machine.

8. Procedure for the secure sending of sensitive information from a user to a server through a communication network using the system according to any of claims, 5-7, characterized in that it comprises the following steps:

- a user enters sensitive information in the reliable device (DC) through the data entry medium (MID);

- the reliable device (DC) communicates, through the untrusted device (DNC) and the communication network (RC), with the secure server (SS) and establishes a secure communication session with said secure server (SS) to obtain a secure key or keys (K ₂ ) shared exclusively by said reliable device (DC) and said secure server (SS); - the reliable device (DC) sends to the untrusted device (DNC) the sensitive information signed and encrypted with the key or keys (K ₂ );

- the untrusted device (DNC) sends, through the communication network (RC), the sensitive information signed and encrypted with the key or keys (K ₂ ) to the proxy (P);

- the proxy (P) detects the existence of sensitive information and sends it to the secure server (SS);

- the secure server (SS) decrypts and authenticates the sensitive information received and sends it decrypted to the proxy (P); Y

- the proxy (P) the information to the server (S).

9. Procedure for the secure sending of sensitive information from a server to a user through a communication network using the system according to any of claims 5-7, characterized in that it comprises the following steps:

- the server (S) notifies a trusted device (DC) of the start of a secure session, through the untrusted device (DNC).

- the reliable device (DC) communicates, through the untrusted device (DNC) and the communication network (RC), with the secure server (SS) and establishes a secure communication session with said secure server (SS) to obtain a secure key or keys (K ₂ ) shared exclusively by said reliable device (DC) and said secure server (SS);

- the server (S) sends the sensitive information to the proxy (P);

- the proxy (P) sends sensitive information to the secure server (SS);

- the secure server (SS) sends to the proxy (P) the sensitive information signed and encrypted with the key or keys (K ₂ );

- the proxy (P) sends, through the communication network (RC), the sensitive information signed and encrypted with the key or keys (K ₂ ) to the untrusted device (DNC);

- the untrusted device (DNC) detects the existence of sensitive information and sends it to the reliable device (DC); Y

- the reliable device (DC) decrypts and authenticates the sensitive information received and displays it through the display medium (MV).

10. Method according to any of claims 8-9, wherein the communication between the untrusted device (DNC) and the proxy (P) through the communication network (RC) is performed according to a first protocol ( PROTi) which is chosen from the following list: http, https, ftp, ssh, and smtp.

eleven . Method according to any of claims 8-10, wherein the communication through a secure communication session between the trusted device (DC) and the secure server (SS) through the untrusted device (DNC) to obtain the key o Secure keys (K ₂ ) is performed according to a second protocol (PROT ₂ ) such as the TLS Handshake Protocol.

12. Method according to any of claims 8-1 1, wherein the communication between the trusted device (DC) and the secure server (SS) through the trusted device (DC), of the communication network (RC), and the proxy (P) for sending the sensitive information signed and encrypted with the key or secure keys (K ₂ ) is performed in accordance with a third protocol (PROT ₃ ) such as the TLS Record Protocol.

13. Method according to any of claims 8-12, wherein the establishment of the secure communication session between the trusted device (DC) and the secure server (SS) according to the second protocol (PROT ₂ ) comprises the following previous steps :

- the untrusted device (DNC) verifies that it is connected to the reliable device (DC);

- the untrusted device (DNC) verifies that the server (S) has an associated secure server (SS); Y

- the untrusted device (DNC) sends the IP address of the secure server (SS) to the trusted device (DC).

14. Method according to any of claims 8-13, further comprising the intermediate step of identifying, by the untrusted device (DNC) or the trustworthy device (DC), the sensitive information received from the trustworthy device (DC) by means of a label that allows the proxy (P) to recognize said information and send it to the secure server (SS).

15. A method according to any of claims 8-14, further comprising the intermediate step of identifying, by the server (S), proxy (P) or secure server (SS), the sensitive information received from the secure server ( SS) by means of a label that allows the untrusted device (DNC) to recognize said information and send it to the reliable device (DC).

16. Method according to any of claims 8-15, which is executed when the user or the server (S) determines that sensitive information is to be exchanged during a browsing session between the two according to the first protocol (PROTi).

17. Computer program comprising program instructions for making a computer carry out the procedure according to any of claims 8-16.

18. Computer program according to claim 17, incorporated into storage media.

19. Computer program according to claim 18, supported on a carrier signal.