WO2015128523A1 - Dispositivo, sistema y procedimiento para el intercambio seguro de información sensible en una red de comunicación - Google Patents

Dispositivo, sistema y procedimiento para el intercambio seguro de información sensible en una red de comunicación Download PDF

Info

Publication number
WO2015128523A1
WO2015128523A1 PCT/ES2015/070118 ES2015070118W WO2015128523A1 WO 2015128523 A1 WO2015128523 A1 WO 2015128523A1 ES 2015070118 W ES2015070118 W ES 2015070118W WO 2015128523 A1 WO2015128523 A1 WO 2015128523A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
sensitive information
dnc
secure
proxy
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/ES2015/070118
Other languages
English (en)
French (fr)
Inventor
José Camacho Páez
Gabriel Maciá Fernández
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Universidad de Granada
Original Assignee
Universidad de Granada
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from ES201430340A external-priority patent/ES2538188R2/es
Application filed by Universidad de Granada filed Critical Universidad de Granada
Publication of WO2015128523A1 publication Critical patent/WO2015128523A1/es
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements

Definitions

  • 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.
  • 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.
  • the commented technologies seek to establish a secure tunnel between the connected end devices.
  • 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.
  • Mitsubishi Man in the Middle
  • malware malicious software
  • 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.
  • MitB Man in the Browser
  • 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.
  • this invention provides the user with an additional perception of security by locating these functionalities in a separate and independent physical device.
  • the present invention solves the above problems by extending cryptographic coverage to the user's device, referred to herein as "untrusted device”.
  • 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.
  • 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.
  • the user's device eg smartphone, tablet, laptop
  • the malware installed therein cannot access or modify the information sensitive so sent.
  • 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 means any device that participates in a communication.
  • Origin Entity means the one that initiates a communication.
  • Destination entity means the one that responds to the communication request in a source entity.
  • Server means that process, or device extension that executes said process, which offers some kind of telematic service in a communications network.
  • Telematic service means any type of activity carried out in a communications network in response to a request from a client entity.
  • 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 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.
  • the proxy can be the server itself.
  • Security Server means a device that allows, with your participation, to establish secure communications between two other devices.
  • 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 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 means that entity whose digital signature allows, without third party participation, to accept the validity of a software document.
  • Software Document means any digital file.
  • 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).
  • the trusted device 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.
  • 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.
  • DC reliable device
  • it can be implemented in different ways, although according to a particular embodiment, it can be an LCD screen or a touch screen.
  • MID Data entry medium
  • 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.
  • an alphanumeric keyboard or a touch screen is used.
  • MV display medium
  • MID data entry medium
  • 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).
  • 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).
  • 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.
  • DNC untrusted device
  • connection means can be wired or a wireless connection can be used.
  • a USB connection for transmission to the server (S) and receive information from it.
  • a WiFi connection for transmission to the server (S) and receive information from it.
  • a Bluetooth connection can be used.
  • 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.
  • 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.
  • 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 can thus have an interface that allows the firmware or software update of the device to be controlled.
  • 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 present invention is also directed to a system for the secure sending of sensitive information in a communication network comprising: a) Unreliable device (DNC)
  • DNC Unreliable device
  • RC communication network
  • RC communication network
  • DNC untrusted device
  • RC communication network
  • SS Security server
  • 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.
  • 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.
  • DC Reliable device
  • DC untrusted device
  • DNC untrusted device
  • CA Certificate Authority
  • 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.
  • the secure server (SS) and the proxy (P) are implemented on the same physical machine.
  • the server (S) and the proxy (P) are implemented on the same physical machine.
  • 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.
  • 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. .
  • 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.
  • 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.
  • DNC device reliable
  • RC communication network
  • K 2 secure keys
  • 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 verifies that it is connected to the reliable device (DC).
  • the untrusted device verifies that the server (S) has an associated secure server (SS).
  • the untrusted device sends the secure server (SS) IP address to the trusted device (DC).
  • 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 2 ) is performed according to a second protocol (PROT 2 ), preferably the TLS Handshake protocol.
  • the untrusted device sends, through the communication network (RC), the sensitive information signed and encrypted with K 2 as part of a message to the proxy (P)
  • 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.
  • 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).
  • 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.
  • PROTi a first protocol
  • 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).
  • 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:
  • the server (S) sends to the proxy (P) a message that includes the sensitive information properly labeled.
  • the proxy (P) detects the existence of sensitive information and sends it 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 2 ) corresponding to the destination DC.
  • the proxy (P) sends, through the communication network (RC), the sensitive information signed and encrypted with K 2 to the untrusted device (DNC).
  • the untrusted device detects the existence of sensitive information and sends it to the trusted device (DC).
  • the reliable device (DC) decrypts and authenticates the sensitive information received and displays it on the display medium (MV).
  • 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 2 ) is made of agreement with a third protocol (PROT 3 ), such as the TLS Record Protocol.
  • a third protocol such as the TLS Record Protocol.
  • steps 6.a and 7.a are replaced by a direct communication between the secure server (SS) and the server (S).
  • steps 2.b and 3.b are replaced by a direct communication between the server (S) and the secure server (SS).
  • 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.
  • 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.
  • the invention encompasses computer programs arranged on or within a carrier.
  • the carrier can be any entity or device capable of supporting the program.
  • the carrier may be constituted by said cable or other device or means.
  • 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.
  • 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.
  • the programs could be supported on a transmissible carrier signal.
  • 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.
  • 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.
  • 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.
  • DC reliable device
  • MV display means
  • MID data entry medium
  • MC means of communication
  • DNC unreliable device
  • 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.
  • DC reliable device
  • DNC untrusted device
  • P proxy
  • RC communication network
  • 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.
  • 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.
  • 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.
  • Figure 6 schematically represents the particular case in which server (S) and proxy (P) are implemented in the same physical machine.
  • DNC Unreliable device communication
  • P P
  • 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 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):
  • SS secure server
  • 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:
  • DC Reliable device communication
  • S Reliable device communication
  • 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.
  • 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.
  • DNC untrusted device
  • DC trusted device
  • 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).
  • 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.
  • 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.
  • the untrusted device 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 trusted device
  • SS secure server
  • the trusted device 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).
  • CERT SS the certificate
  • AC certifying authority
  • 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.
  • CERToc certificate
  • CA certificate authority
  • TLSHP TLS Handshake Protocol
  • DNC untrusted device
  • ISS secure session identifier
  • DC trusted device
  • PROT 2 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 2 ) with which to sign and encrypt the information exchanged.
  • DC trusted device
  • SS secure server
  • K 2 keys shared between both entities
  • the reliable device performs the necessary transformations on the information for safe delivery according to the negotiation at the beginning of the protocol session (PROT 2 ). Specifically, this seráfirmada and encrypted information securely using the key or keys K 2 obtained by the protocol (PROT 2) 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 3 ). - Second, the trusted device (DC) will forward the information to the untrusted device (DNC) using the protocol (PROT 4 ), which will be described later.
  • the untrusted device 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.
  • DNC untrusted device
  • DC trusted device
  • 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 5 ), 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 2 ). If everything is correct, it will send the decrypted information to the proxy (P) using the protocol (PROT 5 ), 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 6 ), which will be described later.
  • the server will interpret the information in a conventional manner.
  • 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 6 ) 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 5 ), which will be described later.
  • the sensitive information badge eg ⁇ secret>
  • SS secure server
  • the secure server 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 2 ). Specifically, such information will be signed and encrypted securely using the K 2 key or keys obtained through the protocol (PROT 2 ) 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 5 ), 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 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 4 ), which will be described later.
  • the sensitive information badge eg ⁇ secret>
  • DC reliable device
  • the reliable device 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 2 ). If everything is correct, it will display the information in the display medium (MV).
  • 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.
  • a protocol PROT 3
  • TLS Record Protocol TLSRP, RFC 22436
  • 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).
  • DC trusted device
  • DNC untrusted device
  • P proxy
  • the implementation of TLSRP can remain true to its specification.
  • the trusted device (DC) performs the steps of the TLSRP client.
  • MAC message authentication code
  • 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).
  • SEC secure TLS record
  • DC Reliable device communication
  • DNC untrusted device
  • a dialogue between the trusted device will occur (DC) and the untrusted device (DNC).
  • DC trusted device
  • DNC untrusted device
  • 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).
  • the server (S) may decide that the value of an information field should be transmitted as sensitive information.
  • 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).
  • scripting technologies eg Javascript
  • 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).
  • DC trusted device
  • DNC untrusted device
  • 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.
  • DC reliable device
  • DNC device unreliable
  • the untrusted device 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.
  • This name will help the reliable device (DC) to display a message to the user requesting that field.
  • the untrusted device 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).
  • SS security server
  • the reliable device 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 establish a session with the firewall following the protocol (PROT 2), sign and encrypt sensitive information with the key or keys K 2 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 will remit the value of a field identified as sensitive. To do this, it will send a message with the following information.
  • This name will help the reliable device (DC) to display a message to the user with that field.
  • TLS coded register which includes the ISS, with the value of the signed and encrypted information field.
  • the trusted device (DC) decrypts and authenticates the SEC record using the key or keys K 2 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 5 ):
  • firewall (SS) 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 5 ).
  • the proxy (P) 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 2 ) to check the integrity of the registry and decode its content. Decoded content will be sent to the proxy (P).
  • a tag for example, the ⁇ secret> tag
  • 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 2 ) to sign and encrypt information. The result will be sent to the proxy (P).
  • DNC untrusted device
  • Proxy communication (P) - server (S) (PROT 6 ):
  • 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 6 ).
  • the server (S) 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).
  • a tag for example, the ⁇ secret> tag
  • DNC untrusted device
  • scripting technologies for example, Javascript
  • the PROT 6 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).
  • the untrusted device 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.
  • SS secure servers
  • 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.
  • 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.
  • the establishment of a secure connection between the trusted device (DC) and the firewall (SS) is initiated, using TLSHP as the protocol (PROT 3 ).
  • 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).
  • the untrusted device incorporates the SEC record between the ⁇ secret> and ⁇ / secret> tags and sends it as part of a message to the proxy (P).
  • 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).
  • 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).
  • the proxy (P) sends the complete message to the server (S) that interprets the information in the usual way.
  • 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.
  • 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
  • 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.
  • SS secure servers
  • 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.
  • 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.
  • 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 3 ).
  • 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).
  • the server (S) sends the complete message to the proxy (P) including the sensitive information between the ⁇ secret> and ⁇ / secret> tags.
  • the proxy (P) sends sensitive information to the secure server (SS).
  • 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)
  • proxy (P) incorporates the SEC register between the ⁇ secret> and ⁇ / secret> tags and sends it to the untrusted device (DNC)
  • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

La invención garantiza la seguridad al enviar información sensible por internet incluso mediante un dispositivo no confiable (DNC). Se describe un dispositivo confiable (DC), un sistema que comprende dicho dispositivo confiable (DC), y un procedimiento de envío seguro de información sensible mediante un sistema que comprende el dispositivo confiable (DC).

Description

DISPOSITIVO, SISTEMA Y PROCEDIMIENTO PARA EL INTERCAMBIO SEGURO DE INFORMACIÓN SENSIBLE EN UNA RED DE COMUNICACIÓN
OBJETO DE LA INVENCIÓN
La presente invención pertenece al campo de las comunicaciones, y más concretamente al campo de los sistemas y procedimientos de seguridad en el intercambio de información sensible a través de una red de comunicación, como por ejemplo Internet. Un objeto de la presente invención es un nuevo dispositivo auxiliar seguro capaz de comunicarse con un dispositivo del usuario para firmar y cifrar la información sensible que éste va a intercambiar con un servidor de destino de tal modo que dicha información sólo pueda ser descifrada en dicho servidor. La información sensible no es accesible o modificable ni siquiera para el propio dispositivo del usuario, de modo que se evita la posibilidad de que malware residente en dicho dispositivo pueda acceder a ella o modificarla.
Otro objeto de la presente invención está dirigido a un sistema para el intercambio de información sensible que comprende un dispositivo auxiliar seguro como el descrito.
Otro objeto más de la invención está dirigido a un procedimiento de operación de un sistema para el intercambio de información sensible como el mencionado. Además, la invención también se extiende a programas de ordenador configurados para hacer que un dispositivo electrónico lleve a cabo dicho procedimiento y a aplicaciones en la nube basadas en dicho procedimiento.
ANTECEDENTES DE LA INVENCIÓN
En la actualidad, la utilización de dispositivos conectados a redes de comunicación, eminentemente Internet, para la consulta y envío de información está ampliamente extendida. Numerosas organizaciones ponen a disposición de sus clientes servicios de compras, consulta, almacenamiento de información, etc., a través de servicios telemáticos que hacen uso de las redes de comunicación. Un ejemplo notorio de este tipo de servicios es el servicio web. Este servicio permite a un usuario, mediante la utilización de un software de navegación (navegador), acceder a determinados servidores web en los que se le ofrece numerosos y variados servicios a través de diferentes tecnologías (HTML, CSS, Scripting, etc.).
Dada la naturaleza sensible y confidencial de muchos de estos servicios (acceso a datos bancarios, datos de salud, envío de contraseñas, etc.), y con el objetivo de garantizar el éxito de los mismos, ha sido necesario el desarrollo paralelo de tecnologías de seguridad que permitieran al usuario tener la confianza necesaria para su utilización. En este campo se han realizado numerosos esfuerzos, encaminados a desarrollar tecnologías que permitan el envío seguro de información sin posibilidad de que ésta fuera accedida, modificada o replicada por terceras partes. Como resultado de estos esfuerzos, en la actualidad se puede destacar la utilización de dos protocolos seguros: IPSec y TLS, éste último utilizado en la denominada navegación web segura (HTTPS).
Las tecnologías comentadas persiguen establecer un túnel seguro entre los dispositivos finales conectados. En el caso de la navegación web segura, dichos dispositivos se corresponden con el navegador web y el servidor web. El túnel seguro es un recubrimiento criptográfico en el canal de comunicaciones, comprendiendo éste todos los medios de transmisión y dispositivos intermedios por lo que pasa la información compartida por los dispositivos finales. El recubrimiento criptográfico evita ciertos ataques a la seguridad por parte de intrusos que pudieran estar ubicados en algún punto del canal de comunicaciones. En primer lugar, evita que se pueda escuchar la información intercambiada (eavesdropping). En segundo lugar, evita que se pueda modificar, falsificar o replicar la información intercambiada (tampering) sin que este hecho se perciba por parte de los receptores. Finalmente, evita también el ataque denominado Man in the Middle (MitM), que consiste en hacer pensar a las dos entidades finales que se están comunicando entre sí, mientras que en realidad la comunicación se realiza en dos partes: entidad origen-intruso e intruso- entidad destino.
Aunque el uso de tecnologías tales como HTTPS permite alcanzar un grado de confianza alto en un servicio de este tipo, dichas tecnologías sólo se centran en evitar amenazas de seguridad o ataques en el canal de comunicaciones. Sin embargo, existe un elevado número de amenazas de seguridad localizadas directamente en los propios dispositivos de comunicación.
En efecto, en la actualidad, el número de virus y, en general, software malicioso (malware) se ha incrementado exponencialmente, haciendo vulnerable la utilización de los dispositivos de comunicación. La presencia de malware en un ordenador puede permitir a un atacante robar la información que un usuario está introduciendo cuando accede a un determinado servicio, como por ejemplo la contraseña de acceso, el número de cuenta corriente, etc. Los atacantes han hecho evolucionar el malware de forma considerable para conseguir una funcionalidad muy avanzada que permite por ejemplo enviar al atacante lo que el usuario del ordenador teclea (keyloggers), o aquellas páginas por las que está navegando (spyware), etc. El malware puede ser un software independiente o estar oculto como parte de un software previamente instalado en el sistema (troyano). Un ejemplo importante relativo al servicio web es el denominado ataque Man in the Browser (MitB), que es el equivalente al MitM cuando lo que ha hecho el atacante es, en realidad, modificar el software del navegador.
Herramientas de última generación permiten el diseño de nuevo malware sin requerir conocimientos técnicos, lo que ha llevado a una explosión en el número de variantes de malware desarrollados por unidad de tiempo. Esta explosión cuestiona la viabilidad y eficacia de las herramientas tradicionales de detección de malware, los llamados antivirus, cuya base de datos difícilmente puede ser actualizada a la suficiente velocidad para realizar una detección exitosa. Adicionalmente, los atacantes diseñan el malware con mecanismos de ofuscación u ocultamiento que permiten en numerosos casos evitar su detección por parte de antivirus o antimalware.
Este efecto se ha agravado con la aparición y extensión de los denominados smartphone, los cuales permiten el acceso a muchos de los servicios a los que tradicionalmente se accedía mediante PC, pero en movilidad. Estos terminales han recibido la atención de los atacantes, los cuales han diseñado un alto porcentaje del malware para este tipo de plataformas. Debido a las limitaciones de batería de estos dispositivos, se suele limitar el uso de antivirus a los períodos de carga, lo que hace que la proliferación de malware esté siendo drástica.
Por otro lado, la actual tendencia en redes corporativas a la proliferación de accesos "Bring Your Own Device" (BYOD), donde el trabajador accede a su puesto de trabajo con un dispositivo de uso general, expone la seguridad de la red a dispositivos comprometidos con malware.
En resumen, en la actualidad, a pesar de la utilización de tecnologías de seguridad tales como las que se proporcionan en el protocolo HTTPS, dichas tecnologías no evitan el acceso de información sensible por parte de malware en el dispositivo del usuario. DESCRIPCIÓN DE LA INVENCIÓN
Mientras que otras soluciones para conseguir comunicaciones seguras han evolucionado en la línea de tratar de asegurar que el dispositivo del usuario se mantenga seguro (antivirus, antimalware), la solución propuesta en este documento asume que no es posible mantener la seguridad en un dispositivo cuya configuración y funcionamiento es muy variable en el tiempo (instalación de aplicaciones, modificación de la configuración por el usuario, etc.), especialmente considerando la evolución actual en el desarrollo de código malware.
Por tanto, la presente invención se centra en extraer del dispositivo de usuario solamente aquellas funcionalidades imprescindibles para el envío y recepción de información sensible a través de la red y garantizar la seguridad en dichas funcionalidades. Además, esta invención aporta al usuario una percepción de seguridad adicional al ubicar estas funcionalidades en un dispositivo físico separado e independiente.
En definitiva, la presente invención resuelve los problemas anteriores gracias a que extiende la cobertura criptográfica al dispositivo del usuario, denominado aquí "dispositivo no confiable". Para ello, se propone la introducción de un nuevo dispositivo auxiliar,denominado "dispositivo confiable", que se conecta al dispositivo del usuario y que ejecutará un software muy reducido sobre el que no se podrá instalar software de terceros. Se evita así la posibilidad de infección por malware, ya que un atacante no podrá aprovechar la existencia de fallos y vulnerabilidades en el software del "dispositivo confiable" para ejecutar un ataque y modificar su funcionamiento.
Es más, ni siquiera se permite la instalación o modificación de software o firmware de este novedoso "dispositivo confiable" por parte del usuario. Esto garantiza que no se pueda modificar tampoco por parte de un atacante el funcionamiento del dispositivo. Como se explicará más adelante en la descripción detallada de la invención, en todo caso solamente se permitirá la realización de ciertas actualizaciones en el software orientadas a eliminar potenciales riesgos de seguridad, siempre bajo ciertas circunstancias y en un entorno muy controlado, de forma que se garantice que no se produce instalación alguna de malware.
Adicionalmente, el "dispositivo confiable" de la invención podrá establecer un túnel seguro con un servidor, de manera que el dispositivo del usuario (ej. smartphone, tablet, portátil), y por tanto el malware instalado en el mismo, no pueda acceder o modificar la información sensible así enviada.
A lo largo de la presente invención se utilizarán una serie de términos cuyo significado se describe a continuación:
Envío de información en una red de comunicaciones: Se entenderá por "envío de información en una red de comunicaciones" como el envío de datos con significado utilizando una determinada tecnología de comunicaciones. Dispositivo Confiable: Se entenderá por "dispositivo confiable", o DC, un dispositivo que interviene en la comunicación entre dos entidades, posibilitando que dicha información sea intercambiada de forma segura entre el dispositivo y la entidad destino, incluso a través de una entidad origen no confiable. Dispositivo No Confiable: Se entenderá por "dispositivo no confiable", o DNC, un dispositivo sobre el cual no hay garantía de seguridad. A modo de ejemplo, los smartphones, tablets, PCs, etc. que se comunican a través de Internet se consideran dispositivos no confiables.
Entidad: Se entenderá por "entidad' cualquier dispositivo que participe en una comunicación.
Entidad Origen: Se entenderá por "entidad origen" aquella que inicia una comunicación.
Entidad Destino: Se entenderá por "entidad destino" aquella que responde a la solicitud de comunicación en una entidad origen.
Servidor: Se entenderá por "servidor" aquel proceso, o por extensión dispositivo que ejecuta dicho proceso, que ofrece algún tipo de servicio telemático en una red de comunicaciones.
Servicio Telemático: Se entenderá por "servicio telemático" cualquier tipo de actividad realizada en una red de comunicaciones como respuesta a una solicitud de una entidad cliente.
Cliente: Se entenderá por "cliente" aquel proceso, o por extensión programa o dispositivo que ejecuta dicho proceso, que solicita algún tipo de servicio telemático en una red de comunicaciones. Proxy: Se entenderá por "proxV aquel proceso, o por extensión programa o dispositivo que ejecuta dicho proceso, que actúa como intermediario a nivel de aplicación entre un servidor y un cliente en algún tipo de servicio telemático en una red de comunicaciones. En particular, el proxy puede ser el propio servidor.
Servidor de Seguridad: Se entenderá por "servidor de seguridad' aquél dispositivo que permita, con su participación, establecer comunicaciones seguras entre otros dos dispositivos. Comunicaciones Seguras: Se entenderá por "comunicaciones seguras" aquellas que garanticen la integridad y privacidad de la comunicación.
Certificado Digital: Se entenderá por "certificado dígita!' aquél documento software que incluye la identificación de una entidad, la clave pública emitida por dicha entidad y que está firmado por la firma digital de una Autoridad Certificadora cuya clave pública está disponible públicamente.
Firma Digital: Se entenderá por "firma digital' de un documento software al resultado de aplicar a dicho documento un algoritmo de firma con una clave privada de una entidad, y que puede ser cotejado utilizando un algoritmo de comprobación con la clave pública de la misma. La "firma digital" se añade al documento software para que pueda ser cotejada por el receptor del mismo.
Clave privada: Se entenderá por "clave privada" de una entidad a una clave software generada por la misma conjuntamente con la clave pública y mantenida en secreto para su uso en cifrado asimétrico.
Clave pública: Se entenderá por "clave pública" de una entidad a una clave software generada por la misma conjuntamente con la clave privada y hecha pública para su uso en cifrado asimétrico.
Autoridad Certificadora: Se entenderá por "autoridad certificadora", o AC, aquella entidad cuya firma digital permite, sin participación de terceros, aceptar la validez de un documento software.
Documento Software: Se entenderá por "documento software" cualguier fichero digital. Red: Se entenderá por "red' cualquier tecnología, incluidos dispositivos de interconexión, que permita la comunicación de información entre dos o más entidades, como por ejemplo Internet o las redes de comunicaciones móviles GSM, UMTS, u otras.
La invención consiste en un dispositivo (en adelante "dispositivo confiable" o DC) que interviene en la comunicación entre un dispositivo de usuario (en adelante, "dispositivo no confiable" o DNC) y un servidor de destino (en adelante, "servidor" o S) cuando la información a intercambiar es sensible, de tal modo que garantiza que dicha información sea intercambiada de forma segura incluso a pesar de llevar a cabo la comunicación a través del dispositivo no confiable (DNC). Para ello, el dispositivo confiable (DC) firma y cifra la información sensible utilizando una o varias claves desconocidas para el dispositivo no confiable (DNC), de manera que dicho dispositivo no confiable (DNC)no pueda acceder a o modificar dicha información sensible introducida por el usuario. De esta forma, se evita que cualquier malware residente en el dispositivo no confiable (DNC) pueda intervenir o modificar la información.
Además, para evitar la posibilidad de que el propio dispositivo confiable (DC) pueda ser infectado por software malicioso o malware, el dispositivo confiable (DC)tendrá restringida la instalación de software de terceros.
Un primer aspecto de la invención está dirigido a un dispositivo confiable (DC) para el intercambio seguro de información en una red de comunicación entre un usuario y un servidor (S), donde dicho dispositivo confiable (DC) fundamentalmente comprende los siguientes elementos: a) Medio de visualización (MV)
El medio de visualización permite al dispositivo confiable (DC) mostrar instrucciones o datos al usuario. En principio puede implementarse de diferentes modos, aunque de acuerdo con una realización particular, puede tratarse de una pantalla LCD o una pantalla táctil. b) Medio de introducción de datos (MID) El medio de introducción de datos permite que el usuario pueda introducir la información sensible que desea transmitir en el dispositivo confiable (DC) para su posterior envío. Preferentemente se utiliza un teclado alfanumérico o una pantalla táctil. Evidentemente, en caso de utilizar una pantalla táctil ésta constituirá conjuntamente tanto el medio de visualización (MV) como el medio de introducción de datos (MID). c) Medio criptográfico El medio criptográfico se encarga de firmar y cifrarla información sensible introducida por el usuario de tal modo que dicha información sensible no sea accesible o modificable por el dispositivo no confiable (DNC). Similarmente, este mismo medio descifrará y autenticará la información sensible que pueda recibirse como respuesta desde el servidor (S), y que sigue sin ser accesible para el dispositivo no confiable (DNC). Así, a pesar de que el dispositivo confiable (DC) se comunica siempre a través del dispositivo no confiable (DNC), este último no puede acceder a la información sensible cifrada o modificarla, y por tanto cualquier posible malware presente en dicho dispositivo no confiable (DNC) resulta inocuo. El modo en que se realiza la firma y cifrado se describirá más adelante con referencia al procedimiento de operación de este sistema de comunicación. d) Medio de conexión (MC)
Se trata de un medio de conexión con dicho dispositivo no confiable (DNC) para comunicar la información sensible firmada y cifrada a dicho dispositivo no confiable
(DNC) para su transmisión al servidor (S) y recibir información del mismo. El medio de conexión puede ser cableado o bien puede utilizarse una conexión inalámbrica. Por ejemplo, de acuerdo con realizaciones preferidas de la invención, se puede utilizar una conexión USB, una conexión WiFi, o una conexión Bluetooth. e) Medio de comprobación
El medio de comprobación de software comprueba la legitimidad de un software que se ejecuta en el dispositivo confiable (DC) mediante la comprobación de que una firma digital del software emitida por una autoridad certificadora (AC) es válida. Además, el dispositivo confiable (DC) de la invención está configurado de tal modo que dicho software o bien no es modificable, o bien sólo es modificable si el nuevo software está firmado por una entidad con un certificado digital válido. Es decir, el dispositivo confiable (DC) nopermite ninguna actualización de software salvo, en todo caso, software que esté firmado con un certificado emitido por una autoridad certificadora (AC) o por un servidor seguro (SS) con certificado válido. Un ejemplo de autoridad certificadora (AC) es la Fábrica Nacional de Moneda y Timbre. En el caso de la invención, la autoridad certificadora (AC) podrá ser creada expresamente y, por tanto, estar únicamente destinada a firmar los certificados y el software de los elementos constituyentes de la invención.
El dispositivo confiable (DC) puede así tener una interfaz que permita la actualización del firmware o software del dispositivo de forma controlada. En este procedimiento de actualización, para evitar la instalación de software malicioso, se podrá habilitar un mecanismo seguro, implementado en hardware o firmware y no modificable, para comprobar que el nuevo software está firmado con el certificado de la autoridad certificadora (AC) o por un servidor seguro (SS) con certificado válido.
El objetivo de este diseño, tal y como se ha justificado anteriormente, es minimizar la funcionalidad del dispositivo confiable (DC) para evitar su manipulación por parte de algún software malicioso o malware. De ese modo, se puede asegurar que implementa exclusivamente las funcionalidades para las que está diseñado.
La presente invención también está dirigida a un sistema para el envío seguro de información sensible en una red de comunicación que comprende: a) Dispositivo no confiable (DNC)
Se trata del dispositivo que utiliza el usuario normalmente para intercambiar información con diversos servidores a través de una red de comunicación (RC), como Internet. Por ejemplo, puede tratarse de un teléfono móvil "inteligente", o smartphone, una tableta, un ordenador, etc. b) Servidor (S) Se trata de un servidor (S) en comunicación con el dispositivo no confiable (DNC) a través de la red de comunicación (RC). Por ejemplo, puede ser el servidor (S) donde se aloja la página web del banco del usuario. c) Servidor de seguridad (SS)
El servidor de seguridad (SS) está en comunicación con el servidor (S) para descifrar y autenticar la información sensible que se envía a dicho servidor (S) por el dispositivo confiable (DC) o firmar y cifrar la información sensible en el sentido inverso de la comunicación. A este respecto, nótese que pueden existir múltiples servidores de seguridad (SS) asociados a diferentes servidores (S). d) Proxy (P) El proxy (P) es un dispositivo intermediario entre la comunicación del dispositivo no confiable (DNC) y el servidor (S) que sirve para derivar la información sensible al servidor seguro (SS) para su firma y cifrado o descifrado y autenticación. d) Dispositivo confiable (DC)
Se trata de un dispositivo confiable (DC) según la descripción anterior que recibe, firma y cifra la información sensible introducida por un usuario para su envío a un servidor (S),o recibe, descifra y autentica la información desde el servidor (S) al usuario, utilizando una clave o claves (K2) compartida/s exclusivamente por dicho dispositivo confiable (DC) y el servidor de seguridad (SS). El dispositivo confiable
(DC) está en comunicación con el dispositivo no confiable (DNC) para transmitirle o recibir dicha información sensible. e) Autoridad certificadora (AC)
La autoridad certificadora se encarga de firmar los certificados digitales del servidor de seguridad (SS) y del dispositivo confiable (DC) para verificar su legitimidad. También podrá encargarse de firmar el código de actualización de firmware del dispositivo confiable (DC), en su caso. En otra realización, el servidor seguro (SS) y el proxy (P) están implementados en la misma máquina física. En otra realización, el servidor (S) y el proxy (P) están implementados en la misma máquina física. En otra realización, el servidor (S), el servidor seguro (SS) y el proxy (P) están implementados en la misma máquina física.
Un tercer aspecto de la presente invención está dirigido a un procedimiento para el intercambio seguro de información sensible en una red de comunicación por medio del sistema que se acaba de describir. Preferentemente, este procedimiento se ejecuta cuando bien el usuario o bien el servidor (S) determina que se va a intercambiar información sensible durante una sesión convencional de comunicación entre ambos, y lo notifican al DC como se describirá con mayor detalle más adelante en este documento.
En una realización, el procedimiento se emplea para que un usuario, típicamente una persona, a través de un DC, envíe datos privados de forma segura a un servidor. Este procedimiento es de utilidad, por ejemplo, para el envío de contraseñas, número PIN, y similares en la autenticación en sistemas de acceso telemático.
En otra realización, el procedimiento se emplea para que un servidor remita información privada a un usuario a través de su DC. Este caso es de utilidad, por ejemplo, para la confirmación de operaciones bancarias, como una alternativa al uso del SMS tan extendido en la autenticación en dos factores.
En ambas realizaciones, se llevan a cabo los siguientes pasos: 1 ) El dispositivo confiable (DC) se comunica, a través del dispositivo no confiable
(DNC) y de la red de comunicación (RC), con el servidor seguro (SS) y establece una sesión de comunicación segura con dicho servidor seguro (SS) para obtener una o varias claves (K2) seguras compartidas exclusivamente por dicho dispositivo confiable (DC) y dicho servidor seguro (SS).
El establecimiento de la sesión de comunicación segura entre el dispositivo confiable (DC) y el servidor seguro (SS) preferentemente comprende a su vez los siguientes pasos previos:
- El dispositivo no confiable (DNC) comprueba que está conectado con el dispositivo confiable (DC). - El dispositivo no confiable (DNC) comprueba que el servidor (S) dispone de un servidor seguro (SS) asociado.
- El dispositivo no confiable (DNC) envía al dispositivo confiable (DC) la dirección IP del servidor seguro (SS).
Además, el establecimiento de una sesión de comunicación segura entre el dispositivo confiable (DC) y el servidor seguro (SS) a través del dispositivo no confiable (DNC) para obtener la/s clave/s segura/s (K2) se realiza de acuerdo con un segundo protocolo (PROT2), preferentemente el protocolo TLS Handshake.
A partir de este punto, los pasos seguidos dependen de si la información sensible es enviada desde el usuario al servidor (S) o en sentido inverso.
En el primer caso, en el que es el usuario el que envía la información sensible, los pasos seguidos son:
2.a) Un usuario introduce información sensible en el dispositivo confiable (DC) a través del medio de introducción de datos (MID). 3.a) El dispositivo confiable (DC) envía al dispositivo no confiable (DNC) la información sensible firmada y cifrada con K2.
4.a) El dispositivo no confiable (DNC) envía, a través de la red de comunicación (RC), la información sensible firmada y cifrada con K2 como parte de un mensaje al proxy (P)
De acuerdo con una realización preferida de la invención, antes de este envío se lleva a cabo el paso adicional de identificar, por parte del dispositivo no confiable (DNC), la información sensible recibida del dispositivo confiable (DC) por medio de una etiqueta que permite al proxy (P) reconocer dicha información dentro del mensaje. Otra opción es que el propio dispositivo confiable (DC) haya llevado a cabo esta operación en alguno de los pasos anteriores, de modo que la información sensible ya esté identificada con una etiqueta cuando llega al dispositivo no confiable (DNC). Por otro lado, preferentemente la comunicación entre el dispositivo no confiable (DNC) y el proxy (P) a través de la red de comunicación (RC) se realiza de acuerdo con un primer protocolo (PROTi) que puede elegirse de entre la siguiente lista: http, https, ftp, ssh y smtp.
5. a) El proxy (P) detecta la existencia de información sensible y la envía al servidor seguro (SS).
6. a) El servidor seguro (SS) descifra y autentica la información sensible recibida y la envía descifrada al proxy (P).
7. a) El proxy (P) remite el mensaje completo al servidor (S). rnativamente, es el servidor (S) el que remite la información sensible, los pasos sonientes:
2.b) El servidor (S) remite al proxy (P) un mensaje que incluye la información sensible convenientemente etiquetada. 3.b) El proxy (P) detecta la existencia de información sensible y la envía al servidor seguro (SS).
4. b) El servidor seguro (SS) envía al proxy (P) la información sensible firmada y cifrada con la clave o claves (K2) correspondientes al DC destino.
5. b) El proxy (P) envía, a través de la red de comunicación (RC), la información sensible firmada y cifrada con K2 al dispositivo no confiable (DNC).
6.b) El dispositivo no confiable (DNC) detecta la existencia de información sensible y la envía al dispositivo confiable (DC).
7.b) El dispositivo confiable (DC) descifra y autentica la información sensible recibida y la muestra en el medio de visualización (MV). realización preferida más, la comunicación correspondiente a los pasos 3.a, 4.a y s pasos 4.b, 5.b y 6.b entre el dispositivo confiable (DC) y el servidor seguro (SS) que se realiza a través del dispositivo no confiable (DNC), la red de comunicación (RC), y el proxy (P) para el envío de la información sensible firmada y cifrada con la clave o claves seguras (K2) se realiza de acuerdo con un tercer protocolo (PROT3), como el TLS Record Protocol.
En otra realización, los pasos 6.a y 7.a se sustituyen por una comunicación directa entre el servidor seguro (SS) y el servidor (S). En otra realización, los pasos 2.b y 3.b se sustituyen por una comunicación directa entre el servidor (S) y el servidor seguro (SS). Es fácil apreciar que con este procedimiento la información sensible transmitida no ha sido nunca accesible para el dispositivo no confiable (DNC), quedando así a salvo de posibles ataques relacionados con software malicioso presente en dicho dispositivo no confiable (DNC). Más adelante en el presente documento se describe con mayor detalle este procedimiento con referencia a las figuras.
La invención descrita está dirigida a dispositivos dotados de una funcionalidad similar a la de un ordenador, incluyendo smartphones o teléfonos inteligentes, tabletas, portátiles, ordenadores, servidores, etc., así como a procesos ejecutados en tales dispositivos. Sin embargo, la invención se extiende no sólo a tales dispositivos y procesos, sino también a programas de ordenador adaptados para que cualquiera de tales equipos pueda llevar a la práctica dichos procesos. Tales programas pueden tener la forma de código fuente, código objeto, una fuente intermedia de código y código objeto, por ejemplo, como en forma parcialmente compilada, o en cualquier otra forma adecuada para uso en la puesta en práctica de los procesos según la invención. Los programas de ordenador también abarcan aplicaciones en la nube basadas en dicho procedimiento.
En particular, la invención abarca programas de ordenador dispuestos sobre o dentro de una portadora. La portadora puede ser cualquier entidad o dispositivo capaz de soportar el programa. Cuando el programa va incorporado en una señal que puede ser transportada directamente por un cable u otro dispositivo o medio, la portadora puede estar constituida por dicho cable u otro dispositivo o medio. Como variante, la portadora podría ser un circuito integrado en el que va incluido el programa, estando el circuito integrado adaptado para ejecutar, o para ser utilizado en la ejecución de, los procesos correspondientes. Por ejemplo, los programas podrían estar incorporados en un medio de almacenamiento, como una memoria ROM, una memoria CD ROM o una memoria ROM de semiconductor, una memoria USB, o un soporte de grabación magnética, por ejemplo, un disco flexible o un disco duro. Alternativamente, los programas podrían estar soportados en una señal portadora transmisible. Por ejemplo, podría tratarse de una señal eléctrica u óptica que podría transportarse a través de cable eléctrico u óptico, por radio o por cualesquiera otros medios.
BREVE DESCRIPCIÓN DE LAS FIGURAS
La Fig. 1 muestra un esquema simplificado de un dispositivo confiable (DC) de acuerdo con la invención.
La Fig. 2 muestra un esquema general del sistema de la invención.
La Fig. 3 muestra de manera esquemática los protocolos de comunicación empleados para llevar a cabo el procedimiento de acuerdo con la presente invención.
La Fig. 4 muestra las torres de protocolos utilizadas en el envío de información sensible entre dispositivo confiable (DC) y el servidor seguro (SS). La Fig. 5 muestra un esquema general del sistema de la invención cuando el servidor (S) y el proxy (P) están implementados en la misma máquina física.
La Fig. 6 muestra de manera esquemática los protocolos de comunicación empleados para llevar a cabo el procedimiento de acuerdo con la presente invención cuando el servidor (S) y el proxy (P) están implementados en la misma máquina física.
REALIZACIÓN PREFERENTE DE LA INVENCIÓN Se describe a continuación con mayor detalle un ejemplo de procedimiento de acuerdo con la presente invención haciendo referencia a las figuras adjuntas.
La Fig. 1 muestra esquemáticamente un dispositivo confiable (DC) donde se aprecia el medio de visualización (MV) o pantalla a través de la cual se muestran datos al usuario y el medio de introducción de datos (MID) o teclado para que el usuario pueda introducir la información sensible. Como se ha comentado anteriormente, estos dos elementos podrían estar integrados en un único elemento en caso de que se emplee una única pantalla táctil, o incluso pertenecer a dispositivos distintos (por ejemplo, pantalla y teclado independientes). Se aprecia también el medio de comunicación (MC) con el dispositivo no confiable (DNC). Por ejemplo, puede ser una conexión de tipo USB o Bluetooth.
El dispositivo confiable (DC) también comprende un medio criptográfico de la información sensible que se va a enviar y un medio de comprobación de software. Sin embargo, estos medios no aparecen representados en la Fig. 1 por estar implementados a través de procesos gobernados por el software del propio dispositivo confiable (DC). Además, como se ha descrito previamente en este documento, el dispositivo confiable (DC) está configurado de tal modo que no permite la modificación de su software interno excepto en casos muy particulares.
La Fig. 2 muestra un ejemplo de sistema para el envío seguro de información sensible según la presente invención. Se aprecia cómo el dispositivo confiable (DC) está en comunicación con el dispositivo no confiable (DNC), el cual, a su vez, se puede comunicar con el proxy (P) a través de la red de comunicación (RC). Un servidor seguro (SS) también conectado a la red de comunicación (RC) descifrará y autenticará la información sensible enviada desde el dispositivo confiable (DC) y firmará y cifrará la información sensible enviada hacia el dispositivo confiable (DC). Un servidor (S) también conectado a la red de comunicación (RC) llevará a cabo el servicio telemático tradicional. En otra realización preferida más, tanto el servidor (S) como el servidor seguro (SS) conectan a la red de comunicación (RC) a través del proxy (P), en lugar de directamente. El dispositivo confiable (DC) puede disponer de un certificado (CERTDC) y el servidor de seguridad (SS) puede disponer de un certificado (CERTSs)- Estos certificados permitirán su autenticación y el establecimiento de una sesión segura entre ambos. La Fig. 2 también muestra la autoridad certificadora (AC) que firmará dichos certificados (CERTDC) y (CERTSs)- El caso particular en el que el servidor (S) y el proxy (P) están implementados en la misma máquina se puede ver representado esquemáticamente en la Figura 5.
Aunque aquí se ha representado el proxy (P), el servidor (S) y el servidor seguro (SS) como entidades diferentes, sería posible que todos o algunos de ellos estuviesen alojados en la misma máquina, en cuyo caso podrían estar implementados por procesos diferentes. De la misma forma, podría existir un servidor seguro (SS) asociado a cada uno de los servidores (S) de una misma corporación, o bien existir un servidor seguro (SS) asociado a un grupo de servidores (S). Cualquier alternativa sería válida siempre que se mantenga la funcionalidad aquí descrita.
A continuación, según se ha representado esquemáticamente en la Figura 3, se describen los mecanismos y protocolos de comunicación entre las entidades descritas que componen el ejemplo de sistema de la invención. La Figura 6 representa esquemáticamente el caso particular en el que servidor (S) y el proxy (P) están implementados en la misma máquina física.
a) Comunicación dispositivo no confiable (DNC) - proxy (P).
Se trata de una comunicación basada en un protocolo tradicional (PROTÍ) de comunicaciones, como HTTP, HTTPS, FTP, SMTP, etc. En caso de utilizar un protocolo seguro (como HTTPS), la información transmitida en esta conexión va cifrada con una clave Ki compartida entre el dispositivo no confiable (DNC) y el proxy (P), que ha sido generada de forma segura siguiendo las reglas de funcionamiento de un protocolo como TLS.
El protocolo seguro HTTPS puede requerir que el proxy (P) disponga de un certificado convenientemente firmado por una autoridad certificadora, que en principio será distinta a la autoridad certificadora (AC) del sistema. Esto es así con el objetivo de que el protocolo (PROT^ pueda seguir los estándares de uso más extendidos de forma que sea compatible con el mayor número posible de dispositivos y sistemas.
La realización de la invención requiere incluir ciertos elementos adicionales en PROTi . En primer lugar, el proxy (P) debe publicar que puede realizar conexiones seguras de acuerdo a la presente invención. Para ello, al enviar una solicitud de información, por ejemplo un formulario, incluirá un meta parámetro (meta-tag) con la información de acceso al servidor seguro (SS):
<meta name="secure_ser er" contént="secs. midominio . es : port ">
Con objeto de que el proxy (P) y/o el dispositivo no confiable (DNC) puedan distinguir los elementos de información sensible remitida (a los que se hace referencia a continuación como SEC), dicha información será destacada con una etiqueta o "tacf específica para tal propósito, por ejemplo:
<secret> SEC </secret>
Comunicación dispositivo confiable (DC) - servidor (S).
Esta comunicación constituye el núcleo de la invención, ya que es la que permite el envío de la información sensible a través del trayecto dispositivo confiable (DC) - dispositivo no confiable (DNC) - red de comunicación (RC) -proxy (P) - servidor (S) sin que el dispositivo no confiable (DNC) pueda obtener información alguna sobre los datos sensibles transmitidos. La comunicación se realiza en dos fases, cada una controlada por un protocolo diferente.
1 . Establecimiento de una sesión segura entre dispositivo confiable (DC) y el servidor seguro (SS) (PROT2).
El establecimiento de una sesión segura entre el dispositivo confiable (DC) y el servidor de seguridad (SS) requiere que se cumplan, al menos, tres condiciones:
i) que el dispositivo confiable (DC) esté conectado al dispositivo no confiable (DNC),
ii) que el servidor (S) disponga de un servidor de seguridad (SS) asociado, y
¡ü) que el dispositivo confiable (DC) pueda establecer la localización del servidor seguro (SS).
Las dos primeras condiciones pueden ser comprobadas por parte del dispositivo no confiable (DNC), que puede a su vez remitir la información requerida al dispositivo confiable (DC) para cumplir la tercera condición. Este hecho no implica ninguna vulnerabilidad en el sistema que implique el riesgo de captación de los datos sensibles por el dispositivo no confiable (DNC): si el dispositivo no confiable (DNC) no responde a la comunicación con el dispositivo confiable (DC) o si no confirma la existencia de un servidor seguro (SS), no se remitirán los datos sensibles. La comprobación de la conexión del dispositivo confiable (DC) al dispositivo no confiable (DNC), condición (i), se puede llevar a cabo con la instalación en el dispositivo no confiable (DNC) de un driver específico para el dispositivo confiable (DC) que avise de cuándo se ha producido la inserción/conexión de este último en/con el primero.
La disponibilidad de un servidor de seguridad (SS), condición (ii), puede ser transmitida por el proxy (P) al dispositivo no confiable (DNC) como parte de la comunicación entre ambos usando el protocolo (PROTi). Por ejemplo, si el protocolo (PROTi) es el protocolo HTTP, la disponibilidad de un servidor seguro (SS) puede ser publicada en el código fuente de la propia página web que contenga cualquier formulario con solicitud de datos susceptibles de ser sensibles. Para ello, se incluirá en la página web remitida con el formulario el nombre de dominio o bien la dirección IP del servidor seguro (SS). Si se incluyera el nombre de dominio, sería el dispositivo no confiable (DNC) el encargado de convertirlo a una dirección IP accesible. Finalmente, el dispositivo no confiable (DNC) remitirá al dispositivo confiable (DC) la dirección IP del servidor seguro (SS) para que éste último inicie la conexión, condición (iii). Éste último paso tampoco implica una vulnerabilidad del sistema que pudiera consistir en el envío por parte del dispositivo no confiable
(DNC) de una IP falsa que redireccionara las comunicaciones del dispositivo confiable (DC) a un servidor falso controlado por un potencial atacante, ya que las comunicaciones seguras aseguran la identidad de los dos extremos de la comunicación, o al menos del servidor seguro (SS), con los certificados firmados por la autoridad certificadora (AC).
A partir de este momento, el dispositivo confiable (DC) podrá iniciar una sesión segura con el servidor seguro (SS). Dado que el dispositivo confiable (DC) no dispone de una interfaz de red propia, debe utilizar al dispositivo no confiable (DNC) como puente para establecer dicha sesión. El dispositivo no confiable (DNC) debe actuar en este caso como un mero intermediario entre el dispositivo confiable (DC) y el servidor de seguridad (SS), reenviando los mensajes entre uno y otro. La sesión segura debe asegurar la confidencialidad e integridad de la información así como evitar los ataques de repetición. Adicionalmente, se deberá comprobar la identidad de, al menos, el servidor seguro (SS), que la acreditará con el certificado (CERTSS), firmado por la autoridad certificadora (AC). Idealmente se comprobará también la identidad del dispositivo confiable (DC), si éste dispone del certificado (CERToc), para evitar la potencial proliferación de réplicas fraudulentas del dispositivo confiable (DC) que realicen conexiones con terceros servidores para robar la información sensible. Es ésta la razón por la que, sin pérdida de generalidad, se concibe la existencia de una autoridad certificadora (AC) que firma los certificados para ambos dispositivos. La negociación correspondiente a los algoritmos criptográficos a utilizar durante la sesión segura, así como las claves asociadas y la comprobación de certificados de autenticación, se llevará a cabo durante el establecimiento de la conexión.
Para el (PROT2), que es un protocolo de establecimiento de sesión segura, se puede recurrir a estándares bien conocidos, como por ejemplo el TLS Handshake Protocol (TLSHP, RFC 2246). Dicho protocolo permite que dos entidades negocien de forma segura un conjunto de parámetros para establecer una sesión segura. En particular, se negocian los algoritmos de compresión, integridad y cifrado de los datos utilizados en ambos finales, así como las correspondientes claves para su uso en ambas direcciones de la comunicación. Si se usa TLSHP, el dispositivo no confiable (DNC) actuará como proxy TLS. Cada sesión segura se identifica con un identificador de sesión segura (ISS), de forma que el servidor seguro (SS) pueda identificar al dispositivo confiable (DC) que envía los datos y pueda descifrar y autenticar, o firmar y cifrar, con la clave o claves K2 correspondiente. En definitiva, como resultado final de este protocolo (PROT2) se habrá establecido una sesión segura entre el dispositivo confiable (DC) y el servidor seguro (SS), que será identificada mediante un identificador de sesión segura (ISS , junto con una o varias claves compartidas entre ambas entidades (K2) con la que firmar y cifrar la información intercambiada.
2. Envío de la información sensible a través de un túnel entre el dispositivo confiable (DC) y el servidor seguro (SS) (PROT3).
Una vez realizado el establecimiento de la sesión segura entre el dispositivo confiable (DC) y el servidor seguro (SS), obteniéndose la clave K2, el envío de la información sensible se realizará como se describe a continuación. Envío de información sensible desde el usuario hacia el servidor (S). Cuando la información sensible se envía desde el usuario hacia el servidor(S), dicha información se encapsulará en un túnel seguro que se establece entre el dispositivo confiable (DC) y el servidor seguro (SS), para posteriormente ser enviada hacia el servidor (S). En esta comunicación se siguen los siguientes pasos:
En primer lugar, el dispositivo confiable (DC) realiza las transformaciones necesarias sobre la información para su envío seguro de acuerdo a la negociación en el inicio de la sesión del protocolo (PROT2). En concreto, dicha información seráfirmada y cifrada de forma segura utilizando la clave o claves K2 obtenida mediante el protocolo (PROT2)de forma que no pueda ser interpretada en ningún punto intermedio de la comunicación, incluido el dispositivo no confiable (DNC). Adicionalmente, incorporará el identificador de la sesión segura (ISS) con cuyo material criptográfico se ha cifrado y firmado la información (PROT3). - En segundo lugar, el dispositivo confiable (DC) remitirá la información al dispositivo no confiable (DNC) usando el protocolo (PROT4), que se describirá más adelante.
El dispositivo no confiable (DNC) incorporará la información cifrada recibida al mensaje que enviará al proxy (P), basado en el protocolo
(PROTi). Para ello, debe identificar la información sensible enviada, por ejemplo a través de una etiqueta (ej. <secret>). Dicha etiqueta podría ser incorporado por el dispositivo no confiable (DNC) en este paso o por el dispositivo confiable (DC) en uno de los pasos anteriores.
El proxy (P), al recibir el mensaje, detectará el distintivo de información sensible (ej. <secret>) y remitirá la información sensible al servidor seguro (SS) usando el protocolo (PROT5), que se describirá más adelante. El servidor seguro (SS) comprobará el ISS de la información sensible cifrada recibida y, si se corresponde con alguna sesión activa, procederá a descifrar la información de acuerdo los parámetros negociados para la misma con el protocolo (PROT2). Si todo es correcto, remitirá la información descifrada al proxy (P) usando el protocolo (PROT5), que se describirá más adelante.
El proxy (P) sustituirá la información sensible cifrada por la recibida en el paso anterior y la enviará al servidor usando el protocolo (PROT6), que se describirá más adelante.
El servidor interpretará la información de forma convencional.
Envío de información sensible desde el servidor (S) hacia el usuario. Alternativamente, el envío de información sensible se puede originar en el servidor (S) con destino al usuario. En este caso, se siguen los siguientes pasos:
El servidor (S) envía el mensaje al proxy (P) siguiendo el protocolo (PROT6) que se describe más adelante. En éste, debe identificar la información sensible enviada, por ejemplo a través de una etiqueta (ej. <secret>).
El proxy (P), al recibir el mensaje, detectará el distintivo de información sensible (ej. <secret>) y remitirá la información sensible al servidor seguro (SS) usando el protocolo (PROT5), que se describirá más adelante.
El servidor seguro (SS) realiza las transformaciones necesarias (cifrado y firmado) sobre la información para su envío seguro, de acuerdo a la negociación en el inicio de la sesión del protocolo (PROT2). En concreto, dicha información será firmada y cifrada de forma segura utilizando la clave o claves K2 obtenida mediante el protocolo (PROT2) de forma que no pueda ser interpretada en ningún punto intermedio de la comunicación, incluido el dispositivo no confiable (DNC). Adicionalmente, incorporará el identificador de la sesión segura (ISS) con cuyo material criptográfico se ha cifrado y firmado la información.
El servidor seguro (SS) remitirá la información de nuevo al proxy (P) usando el protocolo (PROT5), que se describirá más adelante.
El proxy (P) incorporará la información cifrada recibida al mensaje que enviará al dispositivo no confiable (DNC), basado en el protocolo (PROT .
El dispositivo no confiable (DNC), al recibir la información, detectará el distintivo de información sensible (ej. <secret>) y remitirá dicha información al dispositivo confiable (DC) usando el protocolo (PROT4), que se describirá más adelante.
El dispositivo confiable (DC) comprobará el ISS de la información sensible cifrada recibida y, si se corresponde con alguna sesión activa, procederá a descifrar la información de acuerdo los parámetros negociados para la misma con el protocolo (PROT2). Si todo es correcto, mostrará la información en el medio de visualización (MV).
Se puede observar que la información sensible enviada viajafirmada y cifrada con la clave o claves K2, compartida entre el dispositivo confiable (DC) y el servidor seguro (SS), a través de la red de comunicación (RC) y el dispositivo no confiable (DNC) sin que ninguno pueda obtener información alguna sobre la información original o modificarla, tal y como se pretende en esta invención. En la Figura 4 se puede observar la torre de protocolos en el envío de la información sensible y se aprecia el túnel que se construye entre DC y SS mediante el PROT3.
Finalmente, hay que hacer notar también que cada valor sensible que el dispositivo confiable (DC) envía al servidor seguro (SS) o viceversa no implica necesariamente la creación de una sesión nueva con el servidor seguro (SS), con su valor ISS correspondiente, sino que una vez establecida una sesión, se podría reutilizar para el envío subsecuente de nueva información. Como protocolo (PROT3) se puede utilizar el protocolo TLS Record Protocol (TLSRP, RFC 2246). En ese caso, la realización de la invención debe incorporar algunos elementos adicionales para el uso de TLSRP, ya que la comunicación entre dispositivo confiable(DC) y el servidor seguro(SS) no se realiza a través de una única conexión en capa de transporte, como es común en TLS, sino que se establecen tres conexiones (véase la Figura 4): entre dispositivo confiable (DC) y el dispositivo no confiable (DNC), entre el dispositivo no confiable (DNC) y el proxy (P), y entre el proxy (P) y el servidor seguro (SS). No obstante, la implementación de TLSRP puede mantenerse fiel a su especificación. En primer lugar, el dispositivo confiable (DC) realiza los pasos del cliente TLSRP. Primero se calcula un código de autenticación del mensaje (MAC por sus siglas en inglés) que incluye el texto original del formulario y un número de secuencia dentro de la conexión. El número de secuencia permite evitar ataques de reenvío. Posteriormente, el texto original junto con el MAC es encriptado usando la clave para tal efecto. El resultado es un registro seguro TLS, especificado anteriormente como SEC, que incorpora información de la sesión segura (ISS) a la que pertenece y que se enviará al dispositivo no confiable (DNC).
Comunicación dispositivo confiable (DC) - dispositivo no confiable (DNC) (PROT4):
Cada vez que hay que introducir un dato especificado como sensible en un formulario (por ejemplo, un formulario web, un diálogo de autenticación en FTP, etc.), o bien se recibe información sensible del servidor, se producirá un diálogo entre el dispositivo confiable (DC) y el dispositivo no confiable (DNC). En esta comunicación se pueden definir diferentes casos para el inicio del citado diálogo i. Iniciado por el usuario.
Cuando está accediendo al servicio y va a enviar un campo con información, el usuario puede decidir que cierta información es sensible y utilizar el dispositivo confiable (DC) para introducirla. El usuario, por tanto, debe disponer de un mecanismo en el propio cliente (por ej. en el navegador) que le permita iniciar este diálogo dispositivo confiable (DC) - dispositivo no confiable (DNC). Este mecanismo se puede implementar, entre otras alternativas, mediante un plug-in instalado en el cliente que permita al usuario seleccionar un campo como sensible, e iniciar para dicho campo el diálogo dispositivo confiable (DC) - dispositivo no confiable (DNC). El plug-in sería instalado junto con el software (driver) del dispositivo confiable (DC) en el sistema operativo del dispositivo no confiable (DNC).
¡i. Iniciado por el servidor (S).
Es también posible que el servidor (S) decida que el valor de un campo de información deba ser transmitido como información sensible. Para notificar al dispositivo no confiable (DNC) este hecho, el servidor (S) podrá usar tecnologías de scripting (ej. Javascript), de modo que cuando el usuario seleccione el campo en cuestión se inicie automáticamente el diálogo dispositivo confiable (DC) - dispositivo no confiable (DNC) si el dispositivo confiable (DC) está conectado, o bien emerja un mensaje de solicitud del dispositivo confiable (DC) en la interfaz de usuario del dispositivo no confiable (DNC).
Una vez clarificados los escenarios en los que se iniciaría la comunicación dispositivo confiable (DC) - dispositivo no confiable (DNC), se van a describir los pasos en los que se podría desarrollar dicha comunicación.
1 ) Solicitud de confirmación al usuario.
El inicio del diálogo seguro debe ir seguido de una petición al usuario en la que se le solicite confirmar el uso del dispositivo confiable (DC). Esta confirmación se puede considerar realizada cuando el diálogo esté iniciado por el usuario. Sin embargo, si el diálogo es iniciado por el servidor (S) será obligatoria, sirviendo de información al usuario para que conecte e introduzca los datos en el dispositivo confiable (DC).
2) Comprobación de la conexión dispositivo confiable (DC) con el dispositivo no confiable (DNC).
Seguidamente se produce la comprobación de que existe comunicación entre el dispositivo confiable (DC) y el dispositivo no confiable (DNC). En caso de que ésta no exista o falle, se notificará al usuario este evento, dando oportunidad a reintentar la conexión entre ambos dispositivos.
3) Notificación en DNC del traspaso de control al DC.
Una vez se ha realizado la comprobación de la conexión, se notificará al usuario que el control para la introducción y lectura de los datos sensibles se ha pasado al dispositivo confiable (DC), imposibilitando la introducción de otros datos en el navegador residente en el dispositivo no confiable (DNC). Para ello, se utilizará una notificación mediante ventana emergente o similar.
En este punto, se deben distinguir los pasos en la comunicación de información sensible desde o hacia el dispositivo confiable (DC). En el primer caso, esto es, cuando la información sensible se envía desde el dispositivo confiable (DC) al dispositivo no confiable (DNC):
4.a) Envío de mensaje de solicitud de dato sensible.
El dispositivo no confiable (DNC) solicitará el envío del valor para el campo identificado como sensible. Para ello, enviará un mensaje con la siguiente información.
- Nombre del campo de información. Este nombre servirá para que el dispositivo confiable (DC) pueda mostrar un mensaje al usuario solicitando dicho campo.
- Nombre del servidor de seguridad asociado al servicio. El dispositivo no confiable (DNC) podrá obtener el servidor de seguridad (SS) asociado siguiendo varios mecanismos posibles, como por ejemplo, indicándolo en el script que inicia el diálogo por el servidor, o mediante una TAG en la información remitida por el servidor (S) o el proxy (P), o mediante una extensión fija del dominio en el que está ubicado el servicio (por ejemplo, servidorseguridad.midominio.es). Para evitar complejidad en el dispositivo confiable (DC), lo que lo haría posiblemente vulnerable, si fuera necesario realizar una resolución DNS del nombre del servidor de seguridad (SS), ésta se realizaría en el dispositivo no confiable (DNC). Introducción de los datos sensibles en el dispositivo confiable (DC).
El dispositivo confiable (DC) presentará al usuario un diálogo preguntando por el valor del campo de información solicitado. En el teclado habilitado en el dispositivo confiable (DC), el usuario introducirá dicha información. Envío de mensaje de respuesta con datos sensibles.
El dispositivo confiable (DC) establecerá una sesión con el servidor de seguridad siguiendo el protocolo (PROT2), firmará y cifrará la información sensible con la clave o claves K2 y la enviará cifrada al dispositivo no confiable (DNC). so en que se envíe información sensible hacia el dispositivo confiable (DC): Envío de mensaje con dato sensible.
El dispositivo no confiable (DNC) remitirá el valor de un campo identificado como sensible. Para ello, enviará un mensaje con la siguiente información.
- Nombre del campo de información. Este nombre servirá para que el dispositivo confiable (DC) pueda mostrar un mensaje al usuario con dicho campo.
Registro TLS codificado (SEC), que incluye el ISS, con el valor del campo de información firmado y cifrado. Descifrado y autenticación del campo
El dispositivo confiable (DC) descifrará y autenticará el registro SEC utilizando la clave o claves K2 asociadas al ISS. isualización del dato sensible Si la autenticación ha sido correcta, el dispositivo confiable (DC)mandará la información descifrada al medio de visualización (MV).
Comunicación proxy (P) - servidor de seguridad (SS) (PROT5):
Debe existir un procedimiento a partir del cual el proxy (P) envíe al servidor de seguridad (SS) la información sensible para su desencriptación y autenticación o, alternativamente, para su firma y cifrado. La naturaleza de dicho procedimiento dependerá particularmente de la ubicación del servidor de seguridad (SS). Si el servidor de seguridad (SS) se ubica en la misma máquina que el proxy (P), la comunicación se basará en procedimientos de comunicación entre procesos. Si el servidor de seguridad (SS) se ubica en una máquina distinta pero dentro de una red corporativa con un elevado nivel de seguridad, la comunicación se puede basar en protocolos de red no seguros. Si el servidor de seguridad (SS) se ubica en una red distinta, la comunicación debe utilizar recubrimientos criptográficos, por ej. VPNs, para garantizar que esta información no es capturada por elementos intermedios en la red. Finalmente, siempre existe la posibilidad de que el proxy (P) y el servidor de seguridad (SS) estén implementados por el mismo proceso, lo que eliminaría la necesidad del protocolo (PROT5).
Cada vez que el proxy (P) recibe una información sensible codificada e identificable por una etiqueta (por ejemplo, la etiqueta <secret>), remitirá el contenido al servidor seguro (SS) para su decodificación. Al recibir la información codificada, el servidor seguro (SS) comprobará si existe una sesión activa con el identificador ISS contenido en el registro recibido. Si existe, utilizará la correspondiente clave o claves(K2) para comprobar la integridad del registro y decodificar su contenido. El contenido decodificado se remitirá al proxy (P).
Cada vez que el proxy (P) recibe una información sensible con destino al dispositivo confiable (DC), debe en primer lugar iniciar un diálogo seguro, como se ha comentado anteriormente, notificando al dispositivo no confiable (DNC) este hecho, por ejemplo con tecnologías de scripting (por ejemplo, Javascript). Si el diálogo seguro entre el dispositivo confiable (DC) y el servidor seguro (SS) ya ha sido iniciado, el proxy (P) mandará la información sensible que quiere remitir al servidor seguro (SS) con el ISS asociado. El servidor seguro (SS) comprobará si existe una sesión activa con el identificador ISS. Si existe, utilizará la correspondiente clave o claves (K2) para firmar y cifrarla información. El resultado se remitirá al proxy (P).
Comunicación proxy (P) - servidor (S) (PROT6):
Debe existir un procedimiento de comunicación del proxy (P) y el servidor (S). La naturaleza de dicho procedimiento dependerá particularmente de la ubicación del servidor (S). Si el servidor (S) se ubica en la misma máquina que el proxy (P), la comunicación se basará en procedimientos de comunicación entre procesos. Si el servidor (S) se ubica en una máquina distinta pero dentro de una red corporativa con un elevado nivel de seguridad, la comunicación se puede basar en protocolos de red no seguros. Si el servidor (S) se ubica en una red distinta, la comunicación debe utilizar recubrimientos criptográficos, por ej. VPNs, para garantizar que esta información no es capturada por elementos intermedios en la red. Finalmente, siempre existe la posibilidad de que el servidor (S) y el proxy (P) estén implementados por el mismo proceso, lo que eliminaría la necesidad del protocolo (PROT6).
Cada vez que el servidor (S) quiera remitir una información sensible al dispositivo confiable (DC), la identificará con una etiqueta (por ejemplo, la etiqueta <secret>), y remitirá el contenido al proxy (P).Si es necesario iniciar un diálogo seguro, notificará al dispositivo no confiable (DNC) este hecho, por ejemplo con tecnologías de scripting (por ejemplo, Javascript). Alternativamente, como se ha comentado anteriormente, este paso puede realizarlo el proxy (P).
El PROT6 puede ser el mismo protocolo que el PROTi , de forma que el proxy se limita a sustituir la información sensible por su versión firmada y cifrada cuando el destino es el usuario, y a sustituir la información sensible firmada y cifrada por su versión descifrada y autenticada cuando el destino es el servidor (S).
Comunicación servidor seguro (SS) - servidor (S) (PROT7):
Algunos de los pasos antes mencionados se pueden solucionar alternativamente usando una comunicación directa entre servidor seguro (SS) - servidor (S). Por último, se realiza en primer lugar un resumen de los pasos seguidos en una realización concreta para el envío de información sensible de un usuario a un servidor (S) de acuerdo con el procedimiento de la presente invención. En orden cronológico, los pasos a seguir son los siguientes: a) En primer lugar, bien por parte del usuario, bien por parte del servidor (S), se identifica un campo sensible. Como se ha especificado con anterioridad, el servidor (S) o el proxy (P) publicará la información de acceso a servidor de seguridad (SS). El dispositivo no confiable (DNC) mantiene una caché de servidores seguros (SS) conectados, de forma que le es posible identificar si es necesario establecer una nueva conexión o ya existe conexión abierta dispositivo confiable (DC) - servidor de seguridad (SS) debido al envío previo de información sensible. b) Se inicia la conexión entre dispositivo confiable (DC) - servidor de seguridad (SS), el cual pasa el control a dispositivo confiable (DC). Se remite un mensaje de aviso al usuario en la interfaz del dispositivo no confiable (DNC) avisando de dicho paso de control. Adicionalmente, el dispositivo no confiable (DNC) remite al dispositivo confiable (DC) la información del localización de servidor de seguridad (SS), y si es necesario o no iniciar una nueva conexión. c) Si fuera necesario, se inicia el establecimiento de conexión segura entre el dispositivo confiable (DC) y el servidor de seguridad (SS), utilizando TLSHP como protocolo (PROT3). En dicho establecimiento, el driver del dispositivo confiable (DC) instalado en el dispositivo no confiable (DNC) realiza la retransmisión de los mensajes correspondientes utilizando la interfaz de red del dispositivo no confiable
(DNC), que actúa como proxy de red. Los mensajes originados en el dispositivo confiable (DC) son reenviados a través de la interfaz de red del dispositivo no confiable (DNC) y con destino a servidor de seguridad (SS). Los mensajes enviados por el servidor de seguridad (SS) y recibidos por el dispositivo no confiable (DNC) son reenviados al dispositivo confiable (DC). d) El usuario escribe la información sensible en la interfaz del dispositivo confiable (DC), que puede ser contemplada en el medio de visualización (MV). e) El dispositivo confiable (DC), a partir de la información introducida, obtiene el registro TLS codificado SEC, que incluye el ISS, información de integridad y orden en la sesión, y lo remite al dispositivo no confiable (DNC). f) El dispositivo no confiable (DNC) incorpora el registro SEC entre las etiquetas <secret > y </ secret>y lo envía como parte de un mensaje al proxy (P). g) El proxy (P) detecta que en alguno de los campos remitidos aparecen las etiquetas <secret > y < / secret >, y remite el registro SEC al servidor de seguridad (SS). h) El servidor de seguridad (SS) recibe el registro SEC y extrae el ISS. Si existe una sesión activa con ese identificador, utiliza las claves asociadas para comprobar la integridad del registro SEC y proceder a su descifrado. Si todo es correcto, remite la información descifrada al proxy (P). i) El proxy (P) remite el mensaje completo al servidor (S) que interpreta la información en la forma habitual.
Finalmente, se realiza un resumen de los pasos seguidos para el envío de información sensible desde un servidor (S) a un usuario, de acuerdo con una realización concreta del procedimiento de la presente invención. En orden cronológico, los pasos a seguir son los siguientes: a) En primer lugar, el servidor (S) identifica un campo como sensible. Adicionalmente, el servidor (S) publicará la información sobre cómo acceder al servidor de seguridad
(SS). El dispositivo no confiable (DNC) mantiene una caché de servidores seguros (SS) conectados, de forma que le es posible identificar si es necesario establecer una nueva conexión o ya existe conexión abierta dispositivo confiable (DC) - servidor de seguridad (SS) debido al envío previo de información sensible. b) Se inicia la conexión entre dispositivo confiable (DC) - servidor de seguridad (SS), el cual pasa el control al dispositivo confiable (DC). Se remite un mensaje de aviso al usuario en la interfaz del dispositivo no confiable (DNC) avisando de dicho paso de control. Adicionalmente, el dispositivo no confiable (DNC) remite al dispositivo confiable (DC) la información del localización de servidor de seguridad (SS), y si es necesario o no iniciar una nueva conexión. c) Si fuera necesario, se inicia el establecimiento de conexión segura entre el dispositivo confiable (DC) y el servidor de seguridad (SS), utilizando por ejemplo TLSHP como protocolo (PROT3). En dicho establecimiento, el driver del dispositivo confiable (DC) instalado en el dispositivo no confiable (DNC) realiza la retransmisión de los mensajes correspondientes utilizando la interfaz de red del dispositivo no confiable (DNC), que actúa como proxy de red. Los mensajes originados en el dispositivo confiable (DC) son reenviados a través de la interfaz de red del dispositivo no confiable (DNC) y con destino a servidor de seguridad (SS). Los mensajes enviados por el servidor de seguridad (SS) y recibidos por el dispositivo no confiable (DNC) son reenviados al dispositivo confiable (DC). d) El servidor (S) remite el mensaje completo al proxy (P) incluyendo la información sensible entre las etiquetas < secret> y < / secret >. e) El proxy (P) remite la información sensible al servidor seguro (SS). f) El servidor seguro (SS), a partir de la información introducida, obtiene el registro TLS codificado (SEC), que incluye el ISS, información de integridad y orden en la sesión, y lo remite al proxy (P) g) El proxy (P) incorpora el registro SEC entre las etiquetas <secret > y < / secret>y lo envía al dispositivo no confiable (DNC) h) El dispositivo no confiable (DNC) detecta que en alguno de los campos remitidos aparecen las etiquetas <secret > y </ secret >, y remite el registro SEC al dispositivo confiable (DC), i) El dispositivo confiable (DC) recibe el registro SEC y extrae el ISS. Si existe una sesión activa con ese identificador, utiliza las claves asociadas para comprobar la integridad del registro SEC y proceder a su descifrado. Si todo es correcto, remite la información descifrada al medio de visualización (MV).

Claims

REIVINDICACIONES
1 . Dispositivo confiable (DC) para el intercambio seguro de información sensible en una red de comunicación entre un usuario y un servidor (S) a través de un dispositivo no confiable (DNC), caracterizado porque comprende:
- un medio de visualización (MV) para mostrar datos o instrucciones al usuario;
- un medio de introducción de datos (MID) para que el usuario pueda introducir la información sensible que se va a enviar;
- un medio criptográfico para firmar y cifrar, o descifrar y autenticar, la información sensible de tal modo que dicha información sensible no sea accesible o modificable por el dispositivo no confiable (DNC);
- un medio de conexión (MC) con dicho dispositivo no confiable (DNC) para comunicar la información sensible a dicho dispositivo no confiable (DNC) para su transmisión al servidor (S); y
- un medio de comprobación de software que comprueba la legitimidad de un software que se ejecuta en el dispositivo confiable (DC) mediante la comprobación de que la firma digital de dicho software es válida, donde el dispositivo confiable (DC) está configurado de tal modo que dicho software o bien no es modificable, o bien sólo es modificable si el nuevo software está firmado por un certificado digital válido emitido por una autoridad certificadora (AC).
2. Dispositivo confiable (DC) de acuerdo con la reivindicación 1 , donde el medio de visualización (MV) comprende una pantalla LCD o una pantalla táctil.
3. Dispositivo confiable (DC) de acuerdo con cualquiera de las reivindicaciones anteriores, donde el medio de introducción de datos (MID) comprende un teclado alfanumérico o una pantalla táctil.
4. Dispositivo confiable (DC) de acuerdo con cualquiera de las reivindicaciones anteriores, donde el medio de conexión (MC) comprende una conexión USB, una conexión
WiFi o una conexión Bluetooth.
5. Sistema para el intercambio seguro de información sensible en una red de comunicación, que comprende:
- un dispositivo no confiable (DNC); - un servidor (S) en comunicación con el dispositivo no confiable (DNC) a través de una red de comunicación (RC);
- un proxy (P) que actúa de intermediario en la comunicación entre el dispositivo no confiable (DNC) y el servidor (S);
- un servidor de seguridad (SS) en comunicación con el proxy (P)para descifrar y autenticar la información sensible que se envía al servidor (S) por el dispositivo no confiable (DNC), y para firmar y cifrar la información sensible que se remite al usuario;
- un dispositivo confiable (DC) de acuerdo con cualquiera de las reivindicaciones anteriores, que recibe la información sensible introducida por un usuario, firma y cifra dicha información sensible utilizando una clave o claves (K2) compartidas exclusivamente por el dispositivo confiable (DC) y el servidor de seguridad (SS), y que está en comunicación con el dispositivo no confiable (DNC) para transmitirle dicha información sensible, y que recibe la información sensible enviada por el servidor (S), descifra y autentica dicha información sensible utilizando una clave o claves (K2) compartidas exclusivamente por el dispositivo confiable (DC) y el servidor de seguridad (SS), que está en comunicación con el dispositivo no confiable (DNC) para recibir dicha información sensible y que la muestra al usuario; y
- una autoridad certificadora (AC) que se encarga de firmar unos certificados digitales del servidor de seguridad (SS) y del dispositivo confiable (DC) para verificar su legitimidad.
6. Sistema de acuerdo con la reivindicación 5, donde el servidor de seguridad (SS) y el proxy (P) están implementados en la misma máquina física.
7. Sistema de acuerdo con cualquiera de las reivindicaciones 5-6, donde el servidor (S) y el proxy (P) están implementados en la misma máquina física.
8. Procedimiento para el envío seguro de información sensible desde un usuario a un servidor a través de una red de comunicación que utiliza el sistema de acuerdo con cualquiera de las reivindicaciones, 5-7, caracterizado por que comprende los siguientes pasos:
- un usuario introduce información sensible en el dispositivo confiable (DC) a través del medio de introducción de datos (MID);
- el dispositivo confiable (DC) se comunica, a través del dispositivo no confiable (DNC) y de la red de comunicación (RC), con el servidor seguro (SS) y establece una sesión de comunicación segura con dicho servidor seguro (SS) para obtener una clave o claves (K2) seguras compartidas exclusivamente por dicho dispositivo confiable (DC) y dicho servidor seguro (SS); - el dispositivo confiable (DC) envía al dispositivo no confiable (DNC) la información sensible firmada y cifrada con la clave o claves (K2);
- el dispositivo no confiable (DNC) envía, a través de la red de comunicación (RC), la información sensible firmada y cifrada con la clave o claves (K2) al proxy (P);
- el proxy (P) detecta la existencia de información sensible y la envía al servidor seguro (SS);
- el servidor seguro (SS) descifra y autentica la información sensible recibida y la envía descifrada al proxy (P); y
- el proxy (P) la información al servidor (S).
9. Procedimiento para el envío seguro de información sensible desde un servidor a un usuario a través de una red de comunicación que utiliza el sistema de acuerdo con cualquiera de las reivindicaciones 5-7, caracterizado por que comprende los siguientes pasos:
- el servidor (S) notifica a un dispositivo confiable (DC) el inicio de una sesión segura, a través del dispositivo no confiable (DNC).
- el dispositivo confiable (DC) se comunica, a través del dispositivo no confiable (DNC) y de la red de comunicación (RC), con el servidor seguro (SS) y establece una sesión de comunicación segura con dicho servidor seguro (SS) para obtener una clave o claves (K2) seguras compartidas exclusivamente por dicho dispositivo confiable (DC) y dicho servidor seguro (SS);
- el servidor (S) envía al proxy (P) la información sensible;
- el proxy (P) envía al servidor seguro (SS) la información sensible;
- el servidor seguro (SS) envía al proxy (P) la información sensible firmada y cifrada con la clave o claves (K2);
- el proxy (P) envía, a través de la red de comunicación (RC), la información sensible firmada y cifrada con la clave o claves (K2) al dispositivo no confiable (DNC);
- el dispositivo no confiable (DNC) detecta la existencia de información sensible y la envía al dispositivo confiable (DC); y
- el dispositivo confiable (DC) descifra y autentica la información sensible recibida y la muestra por el medio de visualización (MV).
10. Procedimiento de acuerdo con cualquiera de las reivindicaciones 8-9, donde la comunicación entre el dispositivo no confiable (DNC) y el proxy (P) a través de la red de comunicación (RC) se realiza de acuerdo con un primer protocolo (PROTi) que se elige de entre la siguiente lista: http, https, ftp, ssh, y smtp.
1 1 . Procedimiento de acuerdo con cualquiera de las reivindicaciones 8-10, donde la comunicación a través de una sesión de comunicación segura entre el dispositivo confiable (DC) y el servidor seguro (SS) a través del dispositivo no confiable (DNC) para obtener la clave o claves seguras (K2) se realiza de acuerdo con un segundo protocolo (PROT2) como el TLS Handshake Protocol.
12. Procedimiento de acuerdo con cualquiera de las reivindicaciones 8-1 1 , donde la comunicación entre el dispositivo confiable (DC) y el servidor seguro (SS) a través del dispositivo confiable (DC), de la red de comunicación (RC), y del proxy (P) para el envío de la información sensible firmada y cifrada con la clave o claves seguras (K2) se realiza de acuerdo con un tercer protocolo (PROT3) como el TLS Record Protocol.
13. Procedimiento de acuerdo con cualquiera de las reivindicaciones 8-12, donde el establecimiento de la sesión de comunicación segura entre el dispositivo confiable (DC) y el servidor seguro (SS) según el segundo protocolo (PROT2) comprende los siguientes pasos previos:
- el dispositivo no confiable (DNC) comprueba que está conectado con el dispositivo confiable (DC);
- el dispositivo no confiable (DNC) comprueba que el servidor (S) dispone de un servidor seguro (SS) asociado; y
- el dispositivo no confiable (DNC) envía al dispositivo confiable (DC) la dirección IP del servidor seguro (SS).
14. Procedimiento de acuerdo con cualquiera de las reivindicaciones 8-13, que además comprende el paso intermedio de identificar, por parte del dispositivo no confiable (DNC) o el dispositivo confiable (DC), la información sensible recibida del dispositivo confiable (DC) por medio de una etiqueta que permite al proxy (P) reconocer dicha información y remitirla al servidor seguro (SS).
15. Procedimiento de acuerdo con cualquiera de las reivindicaciones 8-14, que además comprende el paso intermedio de identificar, por parte del servidor (S), proxy (P) o servidor seguro (SS), la información sensible recibida del servidor seguro (SS) por medio de una etiqueta que permite al dispositivo no confiable (DNC) reconocer dicha información y remitirla al dispositivo confiable (DC).
16. Procedimiento de acuerdo con cualquiera de las reivindicaciones 8-15, que se ejecuta cuando el usuario o el servidor (S) determinan que se va a intercambiar información sensible durante una sesión de navegación entre ambos según el primer protocolo (PROTi).
17. Programa de ordenador que comprende instrucciones de programa para hacer que un ordenador lleve a la práctica el procedimiento de acuerdo con cualquiera de las reivindicaciones 8-16.
18. Programa de ordenador según la reivindicación 17, incorporado en medios de almacenamiento.
19. Programa de ordenador según la reivindicación 18, soportado en una señal portadora.
PCT/ES2015/070118 2014-02-26 2015-02-23 Dispositivo, sistema y procedimiento para el intercambio seguro de información sensible en una red de comunicación Ceased WO2015128523A1 (es)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
ESP201430260 2014-02-26
ES201430260 2014-02-26
ES201430340A ES2538188R2 (es) 2014-03-13 2014-03-13 Dispositivo , sistema y procedimiento para el intercambio seguro de información sensible en una red de comunicación
ESP201430340 2014-03-13

Publications (1)

Publication Number Publication Date
WO2015128523A1 true WO2015128523A1 (es) 2015-09-03

Family

ID=54008219

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/ES2015/070118 Ceased WO2015128523A1 (es) 2014-02-26 2015-02-23 Dispositivo, sistema y procedimiento para el intercambio seguro de información sensible en una red de comunicación

Country Status (1)

Country Link
WO (1) WO2015128523A1 (es)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030079120A1 (en) * 1999-06-08 2003-04-24 Tina Hearn Web environment access control
US20030191970A1 (en) * 1997-09-26 2003-10-09 Worldcom, Inc. Secure server architecture for web based data management
US20100180120A1 (en) * 2007-09-06 2010-07-15 Human Interface Security Ltd Information protection device
US20110202427A1 (en) * 2010-02-17 2011-08-18 Carlos Garcia Jurado Suarez Device-Pairing by Reading an Address Provided in Device-Readable Form
US20130179685A1 (en) * 2012-01-09 2013-07-11 The Mitre Corporation Secure remote peripheral encryption tunnel

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030191970A1 (en) * 1997-09-26 2003-10-09 Worldcom, Inc. Secure server architecture for web based data management
US20030079120A1 (en) * 1999-06-08 2003-04-24 Tina Hearn Web environment access control
US20100180120A1 (en) * 2007-09-06 2010-07-15 Human Interface Security Ltd Information protection device
US20110202427A1 (en) * 2010-02-17 2011-08-18 Carlos Garcia Jurado Suarez Device-Pairing by Reading an Address Provided in Device-Readable Form
US20130179685A1 (en) * 2012-01-09 2013-07-11 The Mitre Corporation Secure remote peripheral encryption tunnel

Similar Documents

Publication Publication Date Title
ES2564128T3 (es) Un sistema implementado por ordenador para proporcionar a los usuarios acceso seguro a servidores de aplicaciones
US10027631B2 (en) Securing passwords against dictionary attacks
JP5688087B2 (ja) 信頼できる認証およびログオンのための方法および装置
US8881257B2 (en) Method and apparatus for trusted federated identity management and data access authorization
EP2632108B1 (en) Method and system for secure communication
Naik et al. Cyber security—iot
JP6612322B2 (ja) データ処理方法およびデータ処理装置
JP6896940B2 (ja) 第１のアプリケーションと第２のアプリケーションとの間の対称型相互認証方法
US20100031029A1 (en) Techniques to provide access point authentication for wireless network
WO2021113034A1 (en) Full-duplex password-less authentication
JP2017521934A (ja) クライアントとサーバとの間の相互検証の方法
CN103229452A (zh) 移动手持设备的识别和通信认证
US20210306306A1 (en) Method and system for secure communication
Chothia et al. Why banker Bob (still) can’t get TLS right: A Security Analysis of TLS in Leading UK Banking Apps
CN104767740A (zh) 用于来自用户平台的可信认证和接入的方法
JP5186648B2 (ja) 安全なオンライン取引を容易にするシステム及び方法
CN106576050B (zh) 三层安全和计算架构
JP2017139026A (ja) 信頼できる認証およびログオンのための方法および装置
JP2021179690A (ja) 通信システム、中継装置、通信方法、及びプログラム
WO2015128523A1 (es) Dispositivo, sistema y procedimiento para el intercambio seguro de información sensible en una red de comunicación
Yasin et al. Enhancing anti-phishing by a robust multi-level authentication technique (EARMAT).
JP2015111440A (ja) 信頼できる認証およびログオンのための方法および装置
US20250097038A1 (en) Full-Duplex Password-less Authentication
EP3051770A1 (en) User opt-in computer implemented method for monitoring network traffic data, network traffic controller and computer programs
Byrd et al. Secure open wireless networking

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15754577

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15754577

Country of ref document: EP

Kind code of ref document: A1