WO2015128523A1 - Dispositif, système et procédé pour l'échange sécurisé d'informations sensibles dans un réseau de communication - Google Patents

Dispositif, système et procédé pour l'échange sécurisé d'informations sensibles dans un réseau de communication 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
Application number
PCT/ES2015/070118
Other languages
English (en)
Spanish (es)
Inventor
José Camacho Páez
Gabriel Maciá Fernández
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/fr

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

L'invention garantit la sécurité d'envoi d'informations sensibles par Internet, y compris au moyen d'un dispositif non fiable (DNC). L'invention concerne un dispositif fiable (DC), un système comprenant ledit dispositif fiable (DC), et un procédé d'envoi sécurisé d'informations sensibles au moyen d'un système comprenant le dispositif fiable (DC).
PCT/ES2015/070118 2014-02-26 2015-02-23 Dispositif, système et procédé pour l'échange sécurisé d'informations sensibles dans un réseau de communication WO2015128523A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
ESP201430260 2014-02-26
ES201430260 2014-02-26
ESP201430340 2014-03-13
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

Publications (1)

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

Family

ID=54008219

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/ES2015/070118 WO2015128523A1 (fr) 2014-02-26 2015-02-23 Dispositif, système et procédé pour l'échange sécurisé d'informations sensibles dans un réseau de communication

Country Status (1)

Country Link
WO (1) WO2015128523A1 (fr)

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
JP6612322B2 (ja) データ処理方法およびデータ処理装置
EP2632108B1 (fr) Méthode et système pour des communications sécurisées
US8881257B2 (en) Method and apparatus for trusted federated identity management and data access authorization
JP5688087B2 (ja) 信頼できる認証およびログオンのための方法および装置
Naik et al. Cyber security—iot
JP6896940B2 (ja) 第１のアプリケーションと第２のアプリケーションとの間の対称型相互認証方法
US20100031029A1 (en) Techniques to provide access point authentication for wireless network
JP2017521934A (ja) クライアントとサーバとの間の相互検証の方法
WO2021113034A1 (fr) Authentification sans mot de passe en duplex intégral
US20220116385A1 (en) Full-Duplex Password-less Authentication
Chothia et al. Why banker Bob (still) can’t get TLS right: A Security Analysis of TLS in Leading UK Banking Apps
CN104767740A (zh) 用于来自用户平台的可信认证和接入的方法
KR100957044B1 (ko) 커버로스를 이용한 상호 인증 방법 및 그 시스템
JP5186648B2 (ja) 安全なオンライン取引を容易にするシステム及び方法
JP2017139026A (ja) 信頼できる認証およびログオンのための方法および装置
US20210306306A1 (en) Method and system for secure communication
Yasin et al. Enhancing anti-phishing by a robust multi-level authentication technique (EARMAT).
US8924706B2 (en) Systems and methods using one time pads during the exchange of cryptographic material
WO2015128523A1 (fr) Dispositif, système et procédé pour l'échange sécurisé d'informations sensibles dans un réseau de communication
JP2015111440A (ja) 信頼できる認証およびログオンのための方法および装置
Byrd et al. Secure open wireless networking
EP3051770A1 (fr) Procédé mis en oeuvre par ordinateur de participation de l'utilisateur pour la surveillance de données de trafic de réseau, contrôleur de trafic de réseau et programmes informatiques
Zhou et al. An enhanced sms-based otp scheme

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